text:
feat(GraphQL support): RFC for GraphQL support in datahub-frontend (Part 1/2) - Queries

This PR proposes extending the datahub-frontend service to implement the GraphQL spec. The graph_ql_frontend RFC outlines the first part of a 2-part proposal to migrate the existing frontend service to GraphQL. Subsequent RFCs will cover mutation, auth, search, browse & more.
I've created a reference branch to showcase the changes outlined in this document. A PR from that branch can be viewed here. Notice that the branch has evolved to contain both changes related to GraphQL Queries (RFC 1/2) and Mutations (RFC 2/2)
Checklist

[x] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[x] Docs related to the changes have been added/updated (if applicable)

I look forward to engaging with the community around the ideas outlined in the RFC!
John

Pretty comprehensive! Thanks for this great first time PR!
Added @keremsahin1  and @jplaisted as reviewers since they've been thinking about this.

This is a perfect contribution @jjoyce0510, thanks for this. GraphQL support is one of the items in our roadmap and this is a big and important feature and it's worth a RFC doc. I would appreciate if you can send a formal RFC PR by following our RFC guide https://github.com/linkedin/datahub/blob/master/docs/rfc.md.

Rendered: https://github.com/jjoyce0510/datahub-1/tree/master/docs/rfc/active/graph_ql_frontend

What are the pros and cons of supporting GraphQL using Play versus Node?

I think @mars-lan @igbopie and @cptran777 should also take a look :)

This isn't really an "RFC", at least in our terminology. "RFC" to us is basically a design doc / proposal.
I'm stilly happy to discuss over the code, but a if you feel a design doc is warranted, then check out that RFC process :)
https://github.com/linkedin/datahub/blob/master/docs/rfc.md

Thanks for the contribution, @jjoyce0510. This indeed will help modernize the mid-tier. Agree with @jplaisted that we should reach a consensus on the RFC before jumping into actual implementation.

Hi folks! Thanks for all the activity so far. I'll separate into a RFC PR and a corresponding PoC PR :) I want to call out that the code changes are not supposed to represent the final iteration, more as a tool of illustration for the concepts discussed in the doc.
A side note, I think it is useful to have code changes colocated with the RFC for easy reference, but maybe it's just me!
Will comment here with the new PRs.
John

Minor nit but for the OP it uses markdown and [ ] is a blank box, [x] is a checked box. More an FYI for future markdown :)

[ ] empty
[x] checked

Hi folks! Thanks for all the activity so far. I'll separate into a RFC PR and a corresponding PoC PR :) I want to call out that the code changes are not supposed to represent the final iteration, more as a tool of illustration for the concepts discussed in the doc.
A side note, I think it is convenient to have code changes colocated with the RFC for easy reference...
Will comment here with the new PRs.
John

I agree that seeing the proof-of-concept code actually helped me understand the proposal better. However, it is also true that we would want to just commit the rfc doc, and not the proof-of-concept code. I think it is worth supporting an RFC process where prototype code is available to review (to the extent that it helps with reviewing the rfc).
Later, after consensus on the RFC (which might lead to changes in the POC), we can ensure that the code gets split off into an implementation POC, which the author can further refine before making a future PR, while the main "design" RFC gets merged in.
Thoughts @mars-lan and @jplaisted ?

I don't think it hurts to have two PRs at the same time. One for the RFC and one for the PoC. It can help narrow the discussion on each and reduce some confusion (I initially didn't realize there was even an RFC doc here; I just saw code; granted the doc is too big and github won't show it by default). It also helps prevent accidentally submitting the PoC when the RFC is approved.

What are the pros and cons of supporting GraphQL using Play versus Node?

I'd seen somewhere that exploring a NodeJS frontend was on the DH roadmap. While I agree that it may be a reasonable direction in the longer term, it would require quite a bit of work just to spin up a NodeJS frontend that achieves functional parity with the existing Play frontend. Specifically, there'd be a lot of effort in simply implementing the DAOs that talk to GMA in Node (since we'd have no auto-generated client binding help from Pegasus). When I realized this, I considered alternate options. I found that we could quite easily extend the existing Play frontend to accommodate GQL via the addition of a single new endpoint.
The wonderful thing about adopting a GQL API is that our API layer becomes technology-agnostic. The client need not be aware of whether a Play server or a NodeJS server is serving the graph. Instead, the client can depend on an API contract and consider the fulfillment of that contract to be opaque, a responsibility of the server. By introducing the intermediate API layer, it becomes trivial to swap the frontend server implementation (so long as clients depend exclusively on the GQL API).
So I see GQL-on-play as a natural stepping stone toward migrating to NodeJS, making migration down the road that much easier! With this approach, we will avoid the need to coordinate a "big bang" migration of client side + frontend server logic in lockstep.

Oh jeez GitHub deleted a super long comment I had somehow. Great :( This one will be more brief as a result.
I'd also like us to consider server driven rendering. I'm not sure if that conflicts with GQL or not, I haven't thought about this too much, just at a high level. But I think what this shows is that A) we shouldn't dive head first into GQL yet because we should first have B) some high level vision planning / discussions around where we want the frontend to go, architecture wise. Maybe that ends up being GQL, SDR, something else, a mix of things, etc.
I'll chat within the team this week about getting this started. I'm not really on the DataHub team itself (I'm on the GMA team), so I want DataHub folks to lead this conversation. I can just start it. As part of this vision discussion stuff they can consider GQL and SDR as proposals.

Oh jeez GitHub deleted a super long comment I had somehow. Great :( This one will be more brief as a result.
I'd also like us to consider server driven rendering. I'm not sure if that conflicts with GQL or not, I haven't thought about this too much, just at a high level. But I think what this shows is that A) we shouldn't dive head first into GQL yet because we should first have B) some high level vision planning / discussions around where we want the frontend to go, architecture wise. Maybe that ends up being GQL, SDR, something else, a mix of things, etc.
I'll chat within the team this week about getting this started. I'm not really on the DataHub team itself (I'm on the GMA team), so I want DataHub folks to lead this conversation. I can just start it. As part of this vision discussion stuff they can consider GQL and SDR as proposals.

Quick update on my last post: I've set up a small meeting to help hand off this proposal as well as my SDR idea to the DataHub team. After that we should have more traction :)

Quick update on my last post: I've set up a small meeting to help hand off this proposal as well as my SDR idea to the DataHub team. After that we should have more traction :)

@jplaisted Thank you for all your time & effort!
On your points -- We did consider server-driven UI pattern a bit. I'll provide some general thoughts..
IMO, Server-Driven UI is particularly valuable in the following scenarios

You are building for multi-platform (eg. define the UI in a standardized format once and have implemented across web, iOS, android etc) - We are not.
You are building for platforms with challenging release story (eg. to achieve over the air updates for apps on Play / App store) - We are not. (Just web client can be refreshed instantly w/ smart cache-control)
You are building a UI that has many similar but not-quite-the-same experiences or pages (eg. repeated patterns in the component structure) - We may be, but I'd argue it's a bit soon for pattern recognition to be effective due to the limited number of entities / aspects available

It's important to remember that SDR does not come for free - it adds complexity by virtue of an additional layer of indirection.
I think it may make sense to leverage server driven UI for those particularly pluggable pieces of the experience, for example entity detail pages, but likely not for the more concrete pillars: search, authentication, browsing, account management. In this world, GQL + SDR definitely do not conflict; Server-Driven UI models would be part of our GraphQL schema. (Airbnb does this)
So while I think it's worthwhile to consider the possibility of pushing portions of the experience to the server when designing the UI + API layers, I'd prefer to err on the side of simplicity unless its quite evident that the benefits of server driven UI would outweigh the marginal cost.
I think it's most critical that we design the UI in a way that is conducive to moving toward the server-driven pattern in the event we find it compelling down the road. To me, this is a matter of clearly separating the UI from the data layer within the client app.
Interested to hear your thoughts. Are there additional benefits I'm be overlooking or cost I'm over-indexing on?
As for the frontend vision, I agree we should orient ourselves around some shared vision. Please keep me in the loop on what you folks are thinking! :)

@jplaisted Thank you for all your time & effort!
On your points -- We did consider server-driven UI pattern a bit. I'll provide some general thoughts..
IMO, Server-Driven UI is particularly valuable in the following scenarios

You are building for multi-platform (eg. define the UI in a standardized format once and have implemented across web, iOS, android etc) - We are not.
You are building for platforms with challenging release story (eg. to achieve over the air updates for apps on Play / App store) - We are not. (Just web client can be refreshed instantly w/ smart cache-control)
You are building a UI that has many similar but not-quite-the-same experiences or pages (eg. repeated patterns in the component structure) - We may be, but I'd argue it's a bit soon for pattern recognition to be effective due to the limited number of entities / aspects available

It's important to remember that SDR does not come for free - it adds complexity by virtue of an additional layer of indirection.
I think it may make sense to leverage server driven UI for those particularly pluggable pieces of the experience, for example entity detail pages, but likely not for the more concrete pillars: search, authentication, browsing, account management. In this world, GQL + SDR definitely do not conflict; Server-Driven UI models would be part of our GraphQL schema. (Airbnb does this)
So while I think it's worthwhile to consider the possibility of pushing portions of the experience to the server when designing the UI + API layers, I'd prefer to err on the side of simplicity unless its quite evident that the benefits of server driven UI would outweigh the marginal cost.
I think it's most critical that we design the UI in a way that is conducive to moving toward the server-driven pattern in the event we find it compelling down the road. To me, this is a matter of clearly separating the UI from the data layer within the client app.
Interested to hear your thoughts. Are there additional benefits I'm be overlooking or cost I'm over-indexing on?
As for the frontend vision, I agree we should orient ourselves around some shared vision. Please keep me in the loop on what you folks are thinking! :)

Good response, this is exactly the kind of thing I was looking for, thanks!
I'm not set on it either way, and would like to think through it. And to be clear I'm not looking to be a hard blocker on GQL here; mostly I want to present both of these things to DataHub team and once and have them guide things.

That's historically what SDR has been used for and marketed that way. I agree we won't use it that way and thus isn't maybe as appealing as it could be. But we do get another benefit that isn't touted: decoupling the frontend from all the business logic and data models.
I kind of want to use SDR for exactly the opposite of the "code can be reused on the server" point. Here eBay has a good diagram of how SDR allows them to cut down on copy and pasted code across multiple platforms. We only have web, so yeah, it isn't a win. But in web are many entities (datasets, charts, flows, users, etc). I want to think about sharding all that logic out to different microservices. The frontend seems like a bottleneck today.

Frontend is coupled to many services tightly. Adding a new entity means editing the frontend, and adding yet another tight coupling.

Decoupled frontend. Whoever owns the GMS can also own the "Frontend" for it by owning this additional service. Notice a FE can query multiple APIs, e.g. to display the datasets page, it may query the user service to get ownership details / icons.
It'll for sure be a gargantuan effort, but it'll make the frontend way more extensible, if all you have to do is spin up a GMS, a "GMS FE", and then magically DataHub can render a page for your entity without needing any rebuilds or redeployments.
Whether that's worth it, idk. I think its worth discussing, at the very least.
Again my main point was more I think these two proposals are pretty philosophical for the DataHub team and they should A) take them over and B) probably do some larger roadmap work to see if / how they fit in. GQL is 100% the lesser of the two projects effort wise.

makes the API less general-purpose, & tightly couples the client + server

Not true if you don't add the FE to the GMS and consider it a separate service instead (see above). You'd leave your API untouched. The FE would be some other API/service that really only DataHub would care about; the rest of your metadata backend wouldn't ever want to query it.

In this world, GQL + SDR definitely do not conflict; Server-Driven UI models would be part of our GraphQL schema. (Airbnb does this)

I'd be curious to see what this look like, since I don't really get what a query would look like here. The query really is just the URL; quite literally "what is the view model for this page" and the response would always be some list of generic Component or Node. Again, I wasn't sure if they'd conflict or not, but I can't envision it, at least of the top of my head.
I did see that AirBnB published Lona, but I haven't delved into it too deep, so I don't know if it uses GQL or not. Would be interesting to see.

I'd prefer to err on the side of simplicity unless its quite evident that the benefits of server driven UI outweigh the marginal cost.

Good point. I will say that the eventual pieces here eventually become more simple (web app only has super simple components; "frontend" servers just build view models; things follow SRP); but yes the system overall has way more complexity, sadly.

To me, this is a matter of clearly separating the UI from the data layer within the client app.

Agree, but how does GQL help with this? To be clear; here we're talking about not having a DatasetView, but a TableView, and then some other logic that can take a Dataset and make a TableView (logic which could one day be moved to some server), or something similar, right? I'm not super familiar with all our frontend code today, but if its all already tightly coupling presentation logic with models, aren't you just swapping out the query part of that and it all still stays tightly coupled?

Good response, this is exactly the kind of thing I was looking for, thanks!
I'm not set on it either way, and would like to think through it. And to be clear I'm not looking to be a hard blocker on GQL here; mostly I want to present both of these things to DataHub team and once and have them guide things.

That's historically what SDR has been used for and marketed that way. I agree we won't use it that way and thus isn't maybe as appealing as it could be. But we do get another benefit that isn't touted: decoupling the frontend from all the business logic and data models.
I kind of want to use SDR for exactly the opposite of the "code can be reused on the server" point. Here eBay has a good diagram of how SDR allows them to cut down on copy and pasted code across multiple platforms. We only have web, so yeah, it isn't a win. But in web are many entities (datasets, charts, flows, users, etc). I want to think about sharding all that logic out to different microservices. The frontend seems like a bottleneck today.

Frontend is coupled to many services tightly. Adding a new entity means editing the frontend, and adding yet another tight coupling.

Decoupled frontend. Whoever owns the GMS can also own the "Frontend" for it by owning this additional service. Notice a FE can query multiple APIs, e.g. to display the datasets page, it may query the user service to get ownership details / icons.
It'll for sure be a gargantuan effort, but it'll make the frontend way more extensible, if all you have to do is spin up a GMS, a "GMS FE", and then magically DataHub can render a page for your entity without needing any rebuilds or redeployments.
Whether that's worth it, idk. I think its worth discussing, at the very least.
Again my main point was more I think these two proposals are pretty philosophical for the DataHub team and they should A) take them over and B) probably do some larger roadmap work to see if / how they fit in. GQL is 100% the lesser of the two projects effort wise.

makes the API less general-purpose, & tightly couples the client + server

Not true if you don't add the FE to the GMS and consider it a separate service instead (see above). You'd leave your API untouched. The FE would be some other API/service that really only DataHub would care about; the rest of your metadata backend wouldn't ever want to query it.

In this world, GQL + SDR definitely do not conflict; Server-Driven UI models would be part of our GraphQL schema. (Airbnb does this)

I'd be curious to see what this look like, since I don't really get what a query would look like here. The query really is just the URL; quite literally "what is the view model for this page" and the response would always be some list of generic Component or Node. Again, I wasn't sure if they'd conflict or not, but I can't envision it, at least of the top of my head.
I did see that AirBnB published Lona, but I haven't delved into it too deep, so I don't know if it uses GQL or not. Would be interesting to see.

I'd prefer to err on the side of simplicity unless its quite evident that the benefits of server driven UI outweigh the marginal cost.

Good point. I will say that the eventual pieces here eventually become more simple (web app only has super simple components; "frontend" servers just build view models; things follow SRP); but yes the system overall has way more complexity, sadly.

To me, this is a matter of clearly separating the UI from the data layer within the client app.

Agree, but how does GQL help with this? To be clear; here we're talking about not having a DatasetView, but a TableView, and then some other logic that can take a Dataset and make a TableView (logic which could one day be moved to some server), or something similar, right? I'm not super familiar with all our frontend code today, but if its all already tightly coupling presentation logic with models, aren't you just swapping out the query part of that and it all still stays tightly coupled?

The "decoupled frontend" idea reminds me of the old Fizzy+Dust combo that was used heavy within LI once upon a time..

if all you have to do is spin up a GMS, a "GMS FE", and then magically DataHub can render a page for your entity without needing any rebuilds or redeployments.

Is speed of deployment really the metric we should be optimizing for? What about operational simplicity,  speed of development, debuggability concerns, UI flexibility / customizability, etc? It seems that we should work to more clearly understand the tradeoffs at hand.
I can understand the scalability benefits of the design - in particular how it facilitates distributed ownership & decouples the evolution of GMS verticals. But is this what the common deployment outside of LI really needs right now? Will the longer-term value introduced by vertical distribution of ownership be worth the complexity cost for DataHub operators in the near-term?

The FE would be some other API/service that really only DataHub would care about; the rest of your metadata backend wouldn't ever want to query it.

This is what I mean. Not only would they not want to query it, they wouldn't be able to derive any value from querying it because from the PoV of anyone outside of the UI federator the API is opaque.

The query really is just the URL; quite literally "what is the view model for this page" and the response would always be some list of generic Component or Node.

Not sure I'm following this -- Typically you'll have some single-page app acting as a harness to handle things like navigating routes, fetching JSON from the server, and rendering the response. You wouldn't necessarily render the entire app via push from the server. For example, the auth flow would likely make sense to be defined local to client. There can exist a hybrid, where some portions of your GQL schema are modeled to supply a renderer, while others are used for fetching data alone.

Agree, but how does GQL help with this?

It does not!

I'm not super familiar with all our frontend code today, but if its all already tightly coupling presentation logic with models, aren't you just swapping out the query part of that and it all still stays tightly coupled?

Yes indeed. Good observation. Precisely for this reason we do not intend to simply swap GQL in place of existing model layer. More to come on this theme :)
Great discussion! Let's find a dedicated forum to continue.

The "decoupled frontend" idea reminds me of the old Fizzy+Dust combo that was used heavy within LI once upon a time..

if all you have to do is spin up a GMS, a "GMS FE", and then magically DataHub can render a page for your entity without needing any rebuilds or redeployments.

Is speed of deployment really the metric we should be optimizing for? What about operational simplicity,  speed of development, debuggability concerns, UI flexibility / customizability, etc? It seems that we should work to more clearly understand the tradeoffs at hand.
I can understand the scalability benefits of the design - in particular how it facilitates distributed ownership & decouples the evolution of GMS verticals. But is this what the common deployment outside of LI really needs right now? Will the longer-term value introduced by vertical distribution of ownership be worth the complexity cost for DataHub operators in the near-term?

The FE would be some other API/service that really only DataHub would care about; the rest of your metadata backend wouldn't ever want to query it.

This is what I mean. Not only would they not want to query it, they wouldn't be able to derive any value from querying it because from the PoV of anyone outside of the UI federator the API is opaque.

The query really is just the URL; quite literally "what is the view model for this page" and the response would always be some list of generic Component or Node.

Not sure I'm following this -- Typically you'll have some single-page app acting as a harness to handle things like navigating routes, fetching JSON from the server, and rendering the response. You wouldn't necessarily render the entire app via push from the server. For example, the auth flow would likely make sense to be defined local to client. There can exist a hybrid, where some portions of your GQL schema are modeled to supply a renderer, while others are used for fetching data alone.

Agree, but how does GQL help with this?

It does not!

I'm not super familiar with all our frontend code today, but if its all already tightly coupling presentation logic with models, aren't you just swapping out the query part of that and it all still stays tightly coupled?

Yes indeed. Good observation. Precisely for this reason we do not intend to simply swap GQL in place of existing model layer. More to come on this theme :)
Great discussion! Let's find a dedicated forum to continue.

@jplaisted: Looks like consensus has been reached on the current shape of the proposal (as it relates to GraphQL) and it has been lingering for a while.
I will merge this PR by tomorrow if there are no objections.
We can take further conversations (e.g. server-driven UI) in a different rfc/conversation if needed.

@jplaisted: Looks like consensus has been reached on the current shape of the proposal (as it relates to GraphQL) and it has been lingering for a while.
I will merge this PR by tomorrow if there are no objections.
We can take further conversations (e.g. server-driven UI) in a different rfc/conversation if needed.

Looks like consensus has been reached on the current shape of the proposal (as it relates to GraphQL) and it has been lingering for a while.
I will merge this PR by tomorrow if there are no objections.

I am not an expert in GQL and do not have ownership of the frontend or midtier. Please get a team member from that team to do the review, and just so there's no ambiguity, get a Github "approval" from them. I met with the team Tuesday to hand this over, I am no longer sure what the status is.
Thanks.

We can take further conversations (e.g. server-driven UI) in a different rfc/conversation if needed.

Agree, I went off topic, apologies.

Looks like consensus has been reached on the current shape of the proposal (as it relates to GraphQL) and it has been lingering for a while.
I will merge this PR by tomorrow if there are no objections.

I am not an expert in GQL and do not have ownership of the frontend or midtier. Please get a team member from that team to do the review, and just so there's no ambiguity, get a Github "approval" from them. I met with the team Tuesday to hand this over, I am no longer sure what the status is.
Thanks.

We can take further conversations (e.g. server-driven UI) in a different rfc/conversation if needed.

Agree, I went off topic, apologies.

Also @keremsahin1 and @mars-lan may be good reviewers too (though I'd argue not ultimate approvers, that should be the DataHub (frontend/midtier) team). I know they were investigating GQL before.

Also @keremsahin1 and @mars-lan may be good reviewers too (though I'd argue not ultimate approvers, that should be the DataHub (frontend/midtier) team). I know they were investigating GQL before.

I am supportive of this proposal and think it will move DataHub in the right direction.
My suggestion is to proceed in the interest of time, we can always discuss finer details during implementation.

I am supportive of this proposal and think it will move DataHub in the right direction.
My suggestion is to proceed in the interest of time, we can always discuss finer details during implementation.

Also @keremsahin1 and @mars-lan may be good reviewers too (though I'd argue not ultimate approvers, that should be the DataHub (frontend/midtier) team). I know they were investigating GQL before.
Edit: @mars-lan has taken one pass, maybe an explicit LGTM would be nice? hint hint :)

I'm supportive of GQL in general but would also like to see explicit approval from LI side before merging this in.

Also @keremsahin1 and @mars-lan may be good reviewers too (though I'd argue not ultimate approvers, that should be the DataHub (frontend/midtier) team). I know they were investigating GQL before.
Edit: @mars-lan has taken one pass, maybe an explicit LGTM would be nice? hint hint :)

I'm supportive of GQL in general but would also like to see explicit approval from LI side before merging this in.


text:
enable jwt token decode (auth provider) in backend

add AuthProvider class to enable registry to decode JWT tokens
sample usage

jwks_uri = "https://login.microsoftonline.com/common/discovery/v2.0/keys"
client_id = ""
auth = rbac.AuthProvider(jwks_uri, client_id)

token = ""
decoded = auth.decode_token(token)
user = decoded.get('preferred_username').lower()

This class can also be used for id tokens from other cloud providers
detail usage will be added in RBAC specific PR AFTER SQL registry PR to avoid conflict.

Close this one and merge change into a new RBAC PR

source: gharchive/pull-request

repo: linkedin/feathr

license_type: permissive

license_source: github-api


text:
New entity layer for bean

Added new entity layer to support pojo
creates auxiliary table to maintain indexes

lgtm

authors: kishoreg puneetjaiswal

repo: linkedin/pinot

license_source: bigquery


text:
UnhandledPromiseRejectionWarning: Error: Node is either not visible or not an HTMLElement

LinkedIn has changed their layout to now have the See all button be a modal that displays the Interests (Companies, Groups, Schools).
This breaks scrapedin on puppeteer==3.3.0 and scrapedin==1.0.18.
Tested on my own profile:
const fs = require("fs");
const scrapedin = require("scrapedin");

async function main() {
  const linkedInUrl = "https://www.linkedin.com/in/gautier-dagan/";
  const cookies = fs.readFileSync("cookies.json");
  const options = {
    cookies: JSON.parse(cookies.toString()),
  };
  const profileScraper = await scrapedin(options);
  const linkedInProfile = await profileScraper(linkedInUrl);
  console.log(linkedInProfile);
}
main();

Returns:
UnhandledPromiseRejectionWarning: Error: Node is either not visible or not an HTMLElement
    at ElementHandle._clickablePoint (/Users/tmp/scrapedin/node_modules/scrapedin/node_modules/puppeteer/lib/JSHandle.js:196:13)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async ElementHandle.click (/Users/tmp/scrapedin/node_modules/scrapedin/node_modules/puppeteer/lib/JSHandle.js:248:20)
    at async scrapAccomplishmentPanel (/Users/tmp/scrapedin/node_modules/scrapedin/src/profile/scrapAccomplishmentPanel.js:10:5)
    at async module.exports (/Users/tmp/scrapedin/node_modules/scrapedin/src/profile/profile.js:50:19)
    at async main (/Users/tmp/scrapedin/index.js:14:27)
  -- ASYNC --
    at ElementHandle.<anonymous> (/Users/tmp/scrapedin/node_modules/scrapedin/node_modules/puppeteer/lib/helper.js:108:27)
    at scrapAccomplishmentPanel (/Users/tmp/scrapedin/node_modules/scrapedin/src/profile/scrapAccomplishmentPanel.js:10:25)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async module.exports (/Users/tmp/scrapedin/node_modules/scrapedin/src/profile/profile.js:50:19)
    at async main (/Users/tmp/scrapedin/index.js:14:27)

I am having the same issue. when turning the log messages on I get this issue:
scrapedin: 2020-06-07T08:14:54.277Z warn: [profile/seeMoreButtons.js] couldn't click on button.pv-profile-section__see-more-inline, it's probably invisible

I double checked the classes just to make sure the selectors are correct, and they are. I'm not sure why the buttons can't be clicked. I also had isHeadless turned off.

I found a fork of this repo that fixes the node element issue. @getwanted has it on his profile. Here's the link:
https://github.com/wanted-hr/scrapedin
Just use npm or yarn to install his package and you should be good.
npm i @getwanted/scrapedin
const scrapedin = require ("@getwanted/scrapedin")

and stuff like that. maybe this will be accepted as a pull request eventually.

@dgray0229 Thanks for pointing out that branch. I came back to it and isolated the bug to the .click in the scrapAccomplishmentsPanel.js which is not present in the scrapedin fork (hence why it works).
I've made a PR #108 that fixes the issue. Feel free to try it and comment if it also fixes the problem for you!

@dgray0229 Thanks for pointing out that branch. I came back to it and isolated the bug to the .click in the scrapAccomplishmentsPanel.js which is not present in the scrapedin fork (hence why it works).
I've made a PR #108 that fixes the issue. Feel free to try it and comment if it also fixes the problem for you!

I've tried out the repo that you've pulled in my project and the scrape works. No more errors. I can't wait for this to be pulled into the official module. Keep up the good work.

source: gharchive/issue

repo: linkedtales/scrapedin


text:
Missing Network Policy Guidelines

We use Linkerd in a cluster that pretty much blocks every INGRESS/EGRESS not white listed with NetworkPolicies or GlobalNetworkPolicies (via Calico's CRD).
After successfully upgrading Linkerd from 2.9.4 to 2.10.1 we can't figure out what the viz plugin need and the fact it's installed in its own namespace makes all our previous configuration useless...
Can anyone help with some guidelines on how to proceed? What ports are used to where? If a cluster-wide configuration is needed, what would it look like?

@davi5e off the top of my head, the only viz component that I can think of that should need egress access is the dashboard (i.e. the web deployment).  I believe that other than the dashboard, all of core viz functionality should work without egress access.  Does this match what you're seeing?  Are there specific failures you're encountering in your cluster?

@adleong  I'll try to install it again Wednesday and post back more information/answers.
As for what I'm seeing, our "problem" is that all traffic is blocked by default due to a GlobalNetworkPolicy. In doing so, we need to painstakingly open every port for every workload, which ensures our security standards.
Setting this up is a huge pain, though. For example, we need to open EGRESS to kubernetes.default:443 in case some pod needs to talk to the control plane. We need to configure every INGRESS port and corresponding EGRESS communication...
Not knowing where to start make the job all the more tedious since we'd rely on Calico's log report that tell us what packages are being dropped.
Anyhow, as I mentioned, I'll schedule some time to do this in 2 days.

Ah, I hadn't realized that talking to the Kubernetes control plane would count as egress traffic for these purposes.  Almost all Linkerd control plane components talk to the Kubernetes control plane.  Anyway, I'm looking forward to seeing your findings.

That's totally fair @davi5e.  I'm closing this issue now, but please reach out if we can be of assistance!

So, I finally had the time and refactored our Global network policy to what's shown below. Now viz works just fine!
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: allow-linkerd-traffic
spec:
  egress:
  # Allow all egress FROM linkerd
  - action: Allow
    source:
      namespaceSelector: app.kubernetes.io/name in { 'linkerd', 'linkerd-cni', 'linkerd-viz' }
  # Allow egress FROM any pod TO linkerd
  - action: Allow
    destination:
      namespaceSelector: app.kubernetes.io/name in { 'linkerd', 'linkerd-cni', 'linkerd-viz' }
  ingress:
  # Allow ingress TO any pod FROM linkerd
  - action: Allow
    source:
      namespaceSelector: app.kubernetes.io/name in { 'linkerd', 'linkerd-cni', 'linkerd-viz' }
  # Allow ingress TO linkerd FROM any pod
  - action: Allow
    destination:
      namespaceSelector: app.kubernetes.io/name in { 'linkerd', 'linkerd-cni', 'linkerd-viz' }
  # Needs to be lower than regular NetworkPolicies so it gets a priority (1000)
  order: 500
  types:
  - Ingress
  - Egress

p.s.: apiVersion may differ since we are using the GKE integration.

repo: linkerd/linkerd-viz


text:
V-Slot mode with search filter

Is there is any example for V-Slot mode with search filter ?

can you please add filter with v-slot mode ?

Is there is any example for V-Slot mode with search filter ?

Hi @prajit21
I am uploaded example on here. Check it.
https://github.com/linmasahiro/vue3-table-lite/blob/master/src/examples/FilterWithVSlotMode.vue

Thanks you so much for that :)

I have used same example but pagination, sorting not working any solution ?

I have used same example but pagination, sorting not working any solution ?

Hi, @prajit21
I am try to run my example again, and I sure it's work.
Maybe you can fork my repository and follow under step to run and check it.
1. Edit advance.ts and save.
  - import Filter from './examples/Filter.vue'
  + import Filter from './examples/FilterWithVSlotMode.vue'

2. $ npm run serve
3. Access `http://localhost:8080/advanced.html#filter`

Hello @linmasahiro
Actually I have implemented get product api and now we are using doSearch method so pagination is working perfectly but i am not able to implement search functionality.
so is there any way to use search and doSearch Method simultaneity ?

Hello @linmasahiro
so is there any way to use search and doSearch Method simultaneity ?

Hi @prajit21
You can refs https://github.com/linmasahiro/vue3-table-lite/blob/master/src/examples/Filter2.vue
and rewrite myRequest to implement get your api data like doSearch().

I am closing this issue. If you still have problem, reopen the issue.

license: MIT


text:
M3-482 - Remove cancel button red background

This PR fixes an issue on mobile devices where cancel button backgrounds turn red on click.

Nice, thanks for the fix @mchalet !
Not captured by the original ticket, but destructive buttons happen to be affected by this issue as well.

Could you update those as well in this PR? @mchalet

Nice catch, @patthiel. Updated!

@alioso can you review?

authors: mchalet patthiel rjstires

repo: linode/manager


text:
M3-4234: Implement "Actions" column of Linodes table

Description
This PR implements the new "Actions" column of the Linodes table.
Type of Change

Non breaking change ('update', 'change')

To-Do

[ ] Fix some styling issues (ellipsis icon hover color change, menu aligned to right edge of ellipsis icon)
[x] Add functionality for some of the new actions

In re the positioning of the popover, we need to use a portal so the portal's position will change depending on the user's location on the table/window in general. Because of this, Reach is determining the positioning automatically and is overriding our own. I am going to look further into this to see what we can do.


text:
jdk vendor=ibm version=17 will download azul JDK

https://github.com/bmarwell/jaxrs-test-showcase/pull/30
[INFO] --- toolchains-maven-plugin:4.2.0:toolchain (default) @ jaxrstesting-root ---
[INFO] Required toolchain: jdk [ vendor='ibm' version='17' ]
[INFO] Begin to install JDK 17
[INFO] Download zing22.07.0.0-3-jdk17.0.4-linux_x64.tar.gz from https://cdn.azul.com/zing-zvm/ZVM22.07.0.0/zing22.07.0.0-3-jdk17.0.4-linux_x64.tar.gz
[INFO] Extract zing22.07.0.0-3-jdk17.0.4-linux_x64.tar.gz
[INFO] JDK installed: /home/runner/.m2/jdks/zing22.07.0.0-3-jdk17.0.4-linux_x64

Actually, 'vendor' is a misnomer in this plugin. It should be 'dist' (the actual parameter which was called), a synonym to 'distribution'.
vendor=semeru will download dist=semeru. That works.

Just a little correction here, it should be distribution=semeru for example. distro also works but was from version 2.0. You should also use https://api.foojay.io/disco/v3.0 which is the latest version. 😁

@HanSolo I have upgraded to V3.    @bmarwell  could you try version 4.3.0?  https://repo1.maven.org/maven2/org/mvnsearch/toolchains-maven-plugin/4.3.0/

authors: HanSolo bmarwell linux-china

repo: linux-china/toolchains-maven-plugin


text:
gbp buildpackage errors (E) do not result in failure exit code in bin/deb-build-binary

As seen in https://github.com/linz/postgresql-dbpatch/pull/67/checks?check_run_id=692974606#step:4:641 an E line doesn't seem to result in a failure exit from package building script. I think it should...

To be reported upstream, if really worth it

repo: linz/linz-software-repository


text:
Auto play video in recycleview

How can i auto play video in recycleview like facebook.

you should custom jzvd, not ready-made.

repo: lipangit/JiaoZiVideoPlayer

license: mit


text:
How to fast forward slow speed like 20 second mediainterface.seekto(2000)

How to fast forward slow speed like 20 second mediainterface.seekto(2000)

just control mediainterface to seekto.
mediaInterface.seekTo(time);


text:
为什么minSdk需要16呢

为什么minSdk需要16呢

因为全屏的时候切换了surface，需要api是16的方法，比16低的话无法全屏了

authors: duanxifeng lipangit

repo: lipangit/JieCaoVideoPlayer


text:
[Fix] liqo on raspbain os

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes #(issue)
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

[ ] Test A
[ ] Test B

/build

/build

repo: liqotech/liqo


text:
Fix Multiple RoleBinding Creations

Description
This pr fixes an issue that can cause multiple RoleBinding creations over the same ClusterRole multiple times.
How Has This Been Tested?

[x] locally on KinD
[x] add unit test

/rebase

/rebase

/merge

authors: aleoli palexster


text:
Loading CSV file with loadData into Derby DB results in error "The data type '0' is not supported"

Environment
Liquibase Version:
4.8.0
Liquibase Integration & Version: <Pick one: CLI, maven, gradle, spring boot, servlet, etc.>
Maven
Liquibase Extension(s) & Version:
n.a.
Database Vendor & Version:
Apache Derby / 10.14.2.0
Operating System Type & Version:
Windows NT / Windows 10
Description
After updating Liquibase from version 4.3.2 to 4.8.0 our integration tests running with Apache Derby DB are failing with error message "The data type '0' is not supported".
Steps To Reproduce
Changelog:
	<property name="type.bigint" value="BIGINT" dbms="common,derby"/>
	<property name="type.partyid" value="VARCHAR(32)" dbms="common,derby" />
	<property name="type.unicode255" value="VARCHAR(255)" dbms="common,derby" />

	<changeSet  author="example_user" id="create-account-id-mapping">

   		<createTable tableName="example_table_name">
   			<column name="NEXTVERSION" type="${type.bigint}" />
			<column name="ACCOUNTID" type="${type.partyid}" />
			<column name="ACCOUNTNAME" type="${type.unicode255}" />
			<column name="CUSTOMERID" type="${type.partyid}" />
			<column name="CUSTOMER_NAME" type="${type.unicode255}" />
   		</createTable>

	</changeSet>

	<changeSet  author="example_user" id="load_account-id-mapping" runOnChange="true">
		<delete tableName="example_table_name" />

	 	<loadData tableName="example_table_name" file="example_file_path.csv" separator=";">
   			<column name="ACCOUNTID" index="0" />
			<column name="ACCOUNTNAME" index="1" />
			<column name="CUSTOMERID" index="2" />
			<column name="CUSTOMER_NAME" index="3" />
	    </loadData>

	</changeSet>

CSV file:
ACCOUNTID;ACCOUNTNAME;CUSTOMERID;CUSTOMER_NAME
14884;;CUSTOMER1;Customer 1
14885;;CUSTOMER2;Customer 2
14886;;CUSTOMER3;Customer 3

Actual Behavior
When trying to load a CSV file with empty columns into an Apache Derby DB we get the following error:
Log output:
Migration failed for change set com/.../db-changelog-x.y.xml::load_account-id-mapping::example_user:
Reason: liquibase.exception.DatabaseException: java.sql.SQLFeatureNotSupportedException: The data type '0' is not supported.
Caused by: liquibase.exception.DatabaseException: java.sql.SQLFeatureNotSupportedException: The data type '0' is not supported.
Caused by: java.sql.SQLFeatureNotSupportedException: The data type '0' is not supported.
Caused by: org.apache.derby.iapi.error.StandardException: The data type '0' is not supported.

Adding a type attribute to the column elements in the Liquibase change set to explicitly specify the data types of the columns has no effect.
It turned out that the issue is related to empty field values in the loaded CSV file, e.g. a row having no data between two consecutive semicolons (";;"). In this case Liquibase seems to set NULL as column type in method ExecutablePreparedStatementBase#applyColumnParameter:
private void applyColumnParameter(PreparedStatement stmt, int i, ColumnConfig col) throws SQLException, DatabaseException {
  [...]
  if (col.getType() == null) {
      stmt.setNull(i, java.sql.Types.NULL);
      return;
  }

This branch in applyColumnParameter is executed since all member attributes contained in parameter ColumnConfig col (except property name for the column name) are null. As a consequence an SQLFeatureNotSupportedException is thrown which causes the tests to fail.
Expected/Desired Behavior
We would expect that empty strings are supported, at least when specifying column types in loadData:
<column name="ACCOUNTNAME" type="${type.unicode255}" />

This still an issue for liquibase 4.15.

repo: liquibase/liquibase


text:
Add plugin to rewrite bare directory references with index.html

Overview
There's nothing in the current setup that supports the 'index.html' convention. This causes issues on the static sites.
Deliverables

[ ] create 'index.html rewriter' plugin
[ ] add logic to run function to determine whether to make plugin default or not
[ ] use new plugin default logic to make the index.html rewriter default for vanilla sites

Work for this issue will begin begin on branch work-liquid-labs/cloudsite/140.

repo: liquid-labs/cloudsite


text:
Yarnbox tracking issue

What
Yarnbox is going to be a mod enabling UnrealScript patching functionality.
Where to track progress

#4
#3
#2

PoC is done now, closing.

repo: liquidev/abit


text:
[BUG] list-table not supported inside needs

Describe the bug
A clear and concise description of what the bug is.
I am using the following extensions to build my documentation with sphinx

Sphinx v7.0.1
Sphinx-needs v1.2.2
sphinx-makrdown-buidler v0.6.6
sphinx-rtd-theme v1.3.0
When I try to have a table inside of the needs as shown below, the markdown builder does not format the table correctly for it to render.

======================
Test Image With Target
======================

.. image:: /static/markdown.png
   :target: https://github.com/liran-funaro/sphinx-markdown-builder

Download :download:`this example image </static/markdown.png>`.

.. req:: Some requirement
   :id: REQ_1

  .. list-table::
     :header-rows: 1
     :class: tight-table

     * - #
       - Action
       - Expected Result
       - Notes
       - Result
     * - 1
       - Start
       - Test should Start
       - More Notes
       - No result

The same works fine with the HTML builder.
Do I need to do something different for the markdown builder? How can I fix this?
EDIT:
I performed some tests in sphinx-markdown-builder to see how I can use the .. list-table:: in the .rst file. I tried it in two different approaches.

I had the .. list-table:: nested in one of the needs. I have attached the diff patch -
test_nested_list_table.PATCH
and the markdown file:
image-target.md

I had the .. list-table:: as an independent entity in the file (non-nested):

test_list_table.PATCH
and the markdown file:
image-target.md
This time I see the right table format.
To Reproduce
Create an rst file like above
Convert it to markdown with this plugin
See similar output in markdown
Expected behavior
The nested list-tablke should be displayed inside the table for the SWRQ_SYSTEM_MONITOR_422 requirement
Environment (please complete the following information):
OS: Ubuntu
Version: 22.04
Additional context
Add any other context about the problem here.
Expected behavior
A clear and concise description of what you expected to happen.
Environment (please complete the following information):

OS: [e.g. iOS]
Version [e.g. 22]

Additional context
Add any other context about the problem here.
I have also filed a similar issue with sphinx-needs https://github.com/useblocks/sphinx-needs/issues/1161

@revati-naik As sphinx-needs is not supported, this is a feature request.

authors: liran-funaro revati-naik

repo: liran-funaro/sphinx-markdown-builder


text:
Migrate to wext-manifest-loader

Now manifest.json contents is generated from a js file, I have tried to deprecate the package in favour of a webpack loader called wext-manifest-loader.
Both are my packages.
This now avoids the need for the js file and directly uses the manifest.json to generate browser specific json.
I will submit a PR for this.

submitted in #17
The new package keeps all the existing features like using the package.json version for the manifest.json(this can also be turned off, if you prefer that)

repo: lisongx/doubanIMDb


text:
[Fix] UnicodeEncodeError when automated downloading

I tried to run the just released Covsirphy  2.26.0
snr = cs.ODEScenario.auto_build(geo="Japan", model=cs.SIRFModel)
But it is giving an error
runfile('C:/Users/USER/.spyder-py3/temp.py', wdir='C:/Users/USER/.spyder-py3')
Retrieving COVID-19 dataset from https://github.com/lisphilar/covid19-sir/data/
Traceback (most recent call last):
  File ~\.spyder-py3\temp.py:3 in <module>
    snr = cs.ODEScenario.auto_build(geo="Japan", model=cs.SIRFModel)
  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\science\ode_scenario.py:154 in auto_build
    engineer.download(
  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\engineering\engineer.py:89 in download
    df = downloader.layer(**validator.kwargs(DataDownloader.layer, default=default_dict))
  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\downloader.py:110 in layer
    new_df = db.layer(country=country, province=province).convert_dtypes()
  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\db.py:65 in layer
    return self._country()
  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\db_cs_japan.py:61 in _country
    df = self._provide(url=self.URL_C, suffix="", columns=cols, date="Date", date_format="%Y-%m-%d")
  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\db.py:142 in _provide
    df = self._provider.latest(filename=filename, url=url, columns=columns, date=date, date_format=date_format)
  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\provider.py:52 in latest
    df = self.read_csv(url, columns, date=date, date_format=date_format)
  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\provider.py:106 in read_csv
    df = datatable.fread(path, header=True).to_pandas()
  File ~\anaconda3\envs\VC\lib\urllib\request.py:275 in urlretrieve
    reporthook(blocknum, bs, size)
  File ~\anaconda3\envs\VC\lib\encodings\cp1252.py:19 in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 11-13: character maps to <undefined>

Are you using covisirphy with Python 3.10 and dev version of datatable? Actually, I could not reproduce this error...

Does the following script cause error now?
import covsirphy as cs
dl = cs.DataDownloader()
dl.layer()

dl.layer()
Retrieving COVID-19 dataset from https://github.com/lisphilar/covid19-sir/data/
Traceback (most recent call last):

  Input In [4] in <cell line: 1>
    dl.layer()

  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\downloader.py:110 in layer
    new_df = db.layer(country=country, province=province).convert_dtypes()

  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\db.py:65 in layer
    return self._country()

  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\db_cs_japan.py:61 in _country
    df = self._provide(url=self.URL_C, suffix="", columns=cols, date="Date", date_format="%Y-%m-%d")

  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\db.py:142 in _provide
    df = self._provider.latest(filename=filename, url=url, columns=columns, date=date, date_format=date_format)

  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\provider.py:52 in latest
    df = self.read_csv(url, columns, date=date, date_format=date_format)

  File ~\anaconda3\envs\VC\lib\site-packages\covsirphy\downloading\provider.py:106 in read_csv
    df = datatable.fread(path, header=True).to_pandas()

  File ~\anaconda3\envs\VC\lib\urllib\request.py:275 in urlretrieve
    reporthook(blocknum, bs, size)

  File ~\anaconda3\envs\VC\lib\encodings\cp1252.py:19 in encode
    return codecs.charmap_encode(input,self.errors,encoding_table)[0]

UnicodeEncodeError: 'charmap' codec can't encode characters in position 11-13: character maps to <undefined>

The error persisted

Version numbering was incorrect and the correct version is 2.26.3-alpha after https://github.com/lisphilar/covid19-sir/commit/557b622f9d6a1636e0c33736979ab1a893df8fe4.

Bumped up to version 2.27.0-alpha, skipping 2.26.3 so that include dropping Python 3.7 support with #1146.

I will close this issue because the change will be included in 2.27.0 release today, but we can continue this discussion if necessary.

authors: lisphilar shik-design


text:
Add ContainerArchive operation

You listed container archive as an experimental Api here, but now in the recent versions I think it is part of the official Api:
https://docs.docker.com/engine/api/v1.44/#tag/Container/operation/ContainerArchive

this is for checkpoints which i believe is still experimental. the one you linked to is the archiving one which should've been there for a while.

I suppose the way the doc is written makes it a bit confusing i agree. Making that clearer now.

does this make it better?

Yes, thanks, is there an example of archive using the container operation?
If not,would nice to add as well, I will try use this afternoon and I can send an pr if you like só.

I don't believe there is an example of it in the docs and PRs are most welcome! Here is an example in a codebase which uses Podman but should very similar. Can use ContainerArchive instead of ContainerArchiveLibpod I think.

Something like this for writing files to an container right?
(c/invoke containers-docker
          {:op     :PutContainerArchive
           :params {:id container-name
                    :path "/usr/src/app"}
           :data (-> "src.tar.gz"
                     io/file
                     io/input-stream)
           :as     :stream
           :throw-exceptions true
           :throw-entire-message true})

authors: lispyclouds rafaeldelboni

repo: lispyclouds/contajners


text:
build issue on mips32 (big endian)

Hey,
I did some test builds with various compilers for various architectures.
On mips 32 be (gcc), the compiler halts with "invalid operands to binary % (have ‘u16 * {aka short unsigned int *}’ and ‘int’)".
I think what you meant to do at line 76, 100, 126 in binn.c is a modulo operation on a pointer address rather than a pointer.
Like:
if (psource % 2 == 0)
if ((uintptr_t)psource % 2 == 0)

Hi!
I updated the fix.
If you find any problem on big endian, please inform. I have no big endian processor here to test it.
Running the tests should be sufficient.
Thank you for your contribution!

repo: liteserver/binn


text:
ARM64 / AMD64

Appears to be no way to force AMD64 in the Dockerfile for the lithops runtime build command. The image pulled doesn't appear to support x86-64 architecture?

Is there any way to specify the use of ARM64 Lambda instances?

Tried:
FROM --platform=linux/amd64 python:buster as build-image

Fixed, I missed a reference in my DockerFile.

Actually, question 2 still stands. Any way to specify ARM64 lambda instances?

@vysecurity With #880  You can now set the architecture type in your config file, for example:
aws_lambda:
    architecture: arm64

You might consider using an AMR64 python base image for your dockerfile from: https://gallery.ecr.aws/lambda/python, IMAGE TAGS tab

Thanks! Let me give that a shot and feedback here.

I built a Docker based on ARM64, then tried to add that flag into config file and it ended up getting Python exec error on runtime which indicates an architecture issue.

@vysecurity Both the client and the runtime must run the same python version due a cloupickle  restriction.
According to the error message, your docker runtime has python3.8 and not python3.9. Try using python3.8 in your local machine, or review your dockerfile and ensure that python3.9 is included there.

Got it in the end thanks

@vysecurity So, is this solved? Have you been able to run lithops functions with an arm runtime at the end?

Solved! Sorry for late response :-)

Cool! thank you

authors: JosepSampe vysecurity

repo: lithops-cloud/lithops


text:
chore(workflow): adding workflow name and injection time

Signed-off-by: shubhamchaudhary shubham@chaosnative.com

Adding chaos-workflow name and chaos-injection time as labels inside litmuschaos_awaited_experiments and litmuschaos_experiment_verdict

On testing some extra events are coming up, needs some changes. @ispeakc0de

repo: litmuschaos/chaos-exporter


text:
chore(k8s-probe): enhancing k8s probe to support CRD operations

Signed-off-by: shubhamchaudhary shubham.chaudhary@mayadata.io

engine
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: probe1
spec:
  engineStatus: "active"
  auxiliaryAppInfo: "shubham:run=nginx"
  annotationCheck: 'false'
  components:
    runner:
      image: "shubh214/chaos-runner:ci"
      imagePullPolicy: "Always"
  jobCleanUpPolicy: 'retain'
  appinfo:
    appns: shubham
    applabel: "run=nginx"
    appkind: deployment
  chaosServiceAccount: litmus
  monitoring: false
  experiments:
    - name: pod-delete
      spec:
        k8sProbe:
        - name: "probe-k8s-1"
          inputs:
            command:
              group: ""
              version: "v1"
              resource: "persistentvolumeclaims"
              namespace: "shubham"
              fieldSelector: "metadata.name=percona-mysql-claim"
            expectedResult: ""
          mode: "SOT"
          operation: "create"
          data: |
            kind: PersistentVolumeClaim
            apiVersion: v1
            metadata:
              name: percona-mysql-claim
              labels:
                openebs.io/target-affinity: percona
            spec:
              storageClassName: standard
              accessModes:
              - ReadWriteOnce
              resources:
                requests:
                  storage: 100Mi
          runProperties:
            probeTimeout: 5
            interval: 5
            retry: 1
        - name: "probe-k8s-2"
          inputs:
            command:
              group: ""
              version: "v1"
              resource: "persistentvolumeclaims"
              namespace: "shubham" #labelselector, count
              fieldSelector: "metadata.name=percona-mysql-claim"
            expectedResult: ""
          mode: "SOT"
          operation: "present"
          runProperties:
            probeTimeout: 5
            interval: 5
            retry: 1
        - name: "probe-k8s-3"
          inputs:
            command:
              group: ""
              version: "v1"
              resource: "persistentvolumeclaims"
              namespace: "shubham"
              labelSelector: "openebs.io/target-affinity=percona"
              fieldSelector: ""
            expectedResult: ""
          mode: "EOT"
          operation: "delete"
          runProperties:
            probeTimeout: 5
            interval: 5
            retry: 1
        - name: "probe-k8s-4"
          inputs:
            command:
              group: ""
              version: "v1"
              resource: "persistentvolumeclaims"
              namespace: "shubham"
              fieldSelector: "metadata.name=percona-mysql-claim"
            expectedResult: ""
          mode: "EOT"
          operation: "absent"
          runProperties:
            probeTimeout: 5
            interval: 5
            retry: 1

logs
time="2020-09-25T06:04:50Z" level=info msg="[PreReq]: Getting the ENV for the  experiment"
time="2020-09-25T06:04:50Z" level=info msg="[PreReq]: Updating the chaos result of pod-delete experiment (SOT)"
time="2020-09-25T06:04:50Z" level=info msg="The application information is as follows" Namespace=shubham Label="run=nginx" Ramp Time=0
time="2020-09-25T06:04:50Z" level=info msg="[Status]: Verify that the AUT (Application Under Test) is running (pre-chaos)"
time="2020-09-25T06:04:50Z" level=info msg="[Status]: Checking whether application containers are in running state"
time="2020-09-25T06:04:50Z" level=info msg="The running status of container are as follows" container=nginx Pod=nginx-6c444d977f-5dbfl Status=Running
time="2020-09-25T06:04:50Z" level=info msg="The running status of container are as follows" container=nginx Pod=nginx-6c444d977f-7q6mn Status=Running
time="2020-09-25T06:04:50Z" level=info msg="The running status of container are as follows" container=nginx Pod=nginx-6c444d977f-sxjz6 Status=Running
time="2020-09-25T06:04:52Z" level=info msg="[Status]: Checking whether application pods are in running state"
time="2020-09-25T06:04:52Z" level=info msg="The running status of Pods are as follows" Status=Running Pod=nginx-6c444d977f-5dbfl
time="2020-09-25T06:04:52Z" level=info msg="The running status of Pods are as follows" Pod=nginx-6c444d977f-7q6mn Status=Running
time="2020-09-25T06:04:52Z" level=info msg="The running status of Pods are as follows" Pod=nginx-6c444d977f-sxjz6 Status=Running
time="2020-09-25T06:04:59Z" level=info msg="[Probe]: probe-k8s-1 probe has been Passed 😄 " ProbeName=probe-k8s-1 ProbeType=K8sProbe ProbeInstance=PreChaos ProbeStatus=Passed
time="2020-09-25T06:05:04Z" level=info msg="[Probe]: probe-k8s-2 probe has been Passed 😄 " ProbeType=K8sProbe ProbeInstance=PreChaos ProbeStatus=Passed ProbeName=probe-k8s-2
time="2020-09-25T06:05:04Z" level=info msg="[Probe]: The k8s probe information is as follows" Expected Result= Run Properties="{5 5 1 0}" Mode=EOT Name=probe-k8s-3 Command="{ v1 persistentvolumeclaims shubham  openebs.io/target-affinity=percona}"
time="2020-09-25T06:05:04Z" level=info msg="[Probe]: The k8s probe information is as follows" Name=probe-k8s-4 Command="{ v1 persistentvolumeclaims shubham metadata.name=percona-mysql-claim }" Expected Result= Run Properties="{5 5 1 0}" Mode=EOT
time="2020-09-25T06:05:04Z" level=info msg="[Chaos]:Number of pods targeted: 1"
time="2020-09-25T06:05:04Z" level=info msg="[Info]: Killing the following pods" PodName=nginx-6c444d977f-5dbfl
time="2020-09-25T06:05:04Z" level=info msg="[Wait]: Wait for the chaos interval 10s"
time="2020-09-25T06:05:14Z" level=info msg="[Status]: Verification for the recreation of application pod"
time="2020-09-25T06:05:14Z" level=info msg="[Status]: Checking whether application containers are in running state"
time="2020-09-25T06:05:14Z" level=info msg="The running status of container are as follows" Pod=nginx-6c444d977f-7q6mn Status=Running container=nginx
time="2020-09-25T06:05:14Z" level=info msg="The running status of container are as follows" Pod=nginx-6c444d977f-ndk42 Status=Running container=nginx
time="2020-09-25T06:05:14Z" level=info msg="The running status of container are as follows" container=nginx Pod=nginx-6c444d977f-sxjz6 Status=Running
time="2020-09-25T06:05:16Z" level=info msg="[Status]: Checking whether application pods are in running state"
time="2020-09-25T06:05:16Z" level=info msg="The running status of Pods are as follows" Pod=nginx-6c444d977f-7q6mn Status=Running
time="2020-09-25T06:05:16Z" level=info msg="The running status of Pods are as follows" Pod=nginx-6c444d977f-ndk42 Status=Running
time="2020-09-25T06:05:16Z" level=info msg="The running status of Pods are as follows" Status=Running Pod=nginx-6c444d977f-sxjz6
time="2020-09-25T06:05:18Z" level=info msg="[Chaos]:Number of pods targeted: 1"
time="2020-09-25T06:05:18Z" level=info msg="[Info]: Killing the following pods" PodName=nginx-6c444d977f-7q6mn
time="2020-09-25T06:05:18Z" level=info msg="[Wait]: Wait for the chaos interval 10s"
time="2020-09-25T06:05:28Z" level=info msg="[Status]: Verification for the recreation of application pod"
time="2020-09-25T06:05:28Z" level=info msg="[Status]: Checking whether application containers are in running state"
time="2020-09-25T06:05:28Z" level=info msg="The running status of container are as follows" Pod=nginx-6c444d977f-2hv2f Status=Running container=nginx
time="2020-09-25T06:05:28Z" level=info msg="The running status of container are as follows" Pod=nginx-6c444d977f-ndk42 Status=Running container=nginx
time="2020-09-25T06:05:28Z" level=info msg="The running status of container are as follows" Pod=nginx-6c444d977f-sxjz6 Status=Running container=nginx
time="2020-09-25T06:05:30Z" level=info msg="[Status]: Checking whether application pods are in running state"
time="2020-09-25T06:05:30Z" level=info msg="The running status of Pods are as follows" Pod=nginx-6c444d977f-2hv2f Status=Running
time="2020-09-25T06:05:30Z" level=info msg="The running status of Pods are as follows" Pod=nginx-6c444d977f-ndk42 Status=Running
time="2020-09-25T06:05:30Z" level=info msg="The running status of Pods are as follows" Status=Running Pod=nginx-6c444d977f-sxjz6
time="2020-09-25T06:05:32Z" level=info msg="[Chaos]: Time is up for experiment: pod-delete"
time="2020-09-25T06:05:32Z" level=info msg="[Completion]: pod-delete chaos is done"
time="2020-09-25T06:05:32Z" level=info msg="[Confirmation]: The application pod has been deleted successfully"
time="2020-09-25T06:05:32Z" level=info msg="[Status]: Verify that the AUT (Application Under Test) is running (post-chaos)"
time="2020-09-25T06:05:32Z" level=info msg="[Status]: Checking whether application containers are in running state"
time="2020-09-25T06:05:32Z" level=info msg="The running status of container are as follows" Pod=nginx-6c444d977f-2hv2f Status=Running container=nginx
time="2020-09-25T06:05:32Z" level=info msg="The running status of container are as follows" container=nginx Pod=nginx-6c444d977f-ndk42 Status=Running
time="2020-09-25T06:05:32Z" level=info msg="The running status of container are as follows" Pod=nginx-6c444d977f-sxjz6 Status=Running container=nginx
time="2020-09-25T06:05:34Z" level=info msg="[Status]: Checking whether application pods are in running state"
time="2020-09-25T06:05:34Z" level=info msg="The running status of Pods are as follows" Pod=nginx-6c444d977f-2hv2f Status=Running
time="2020-09-25T06:05:34Z" level=info msg="The running status of Pods are as follows" Pod=nginx-6c444d977f-ndk42 Status=Running
time="2020-09-25T06:05:34Z" level=info msg="The running status of Pods are as follows" Pod=nginx-6c444d977f-sxjz6 Status=Running
time="2020-09-25T06:05:36Z" level=info msg="[Probe]: The k8s probe information is as follows" Mode=SOT Name=probe-k8s-1 Command="{ v1 persistentvolumeclaims shubham metadata.name=percona-mysql-claim }" Expected Result= Run Properties="{5 5 1 0}"
time="2020-09-25T06:05:36Z" level=info msg="[Probe]: The k8s probe information is as follows" Command="{ v1 persistentvolumeclaims shubham metadata.name=percona-mysql-claim }" Expected Result= Run Properties="{5 5 1 0}" Mode=SOT Name=probe-k8s-2
time="2020-09-25T06:05:36Z" level=info msg="[Probe]: The k8s probe information is as follows" Run Properties="{5 5 1 0}" Mode=EOT Name=probe-k8s-3 Command="{ v1 persistentvolumeclaims shubham  openebs.io/target-affinity=percona}" Expected Result=
time="2020-09-25T06:05:41Z" level=info msg="[Probe]: probe-k8s-3 probe has been Passed 😄 " ProbeType=K8sProbe ProbeInstance=PostChaos ProbeStatus=Passed ProbeName=probe-k8s-3
time="2020-09-25T06:05:41Z" level=info msg="[Probe]: The k8s probe information is as follows" Mode=EOT Name=probe-k8s-4 Command="{ v1 persistentvolumeclaims shubham metadata.name=percona-mysql-claim }" Expected Result= Run Properties="{5 5 1 0}"
time="2020-09-25T06:05:46Z" level=info msg="[Probe]: probe-k8s-4 probe has been Passed 😄 " ProbeName=probe-k8s-4 ProbeType=K8sProbe ProbeInstance=PostChaos ProbeStatus=Passed
time="2020-09-25T06:05:46Z" level=info msg="[The End]: Updating the chaos result of pod-delete experiment (EOT)"

result
Name:         probe1-pod-delete
Namespace:    shubham
Labels:       name=probe1-pod-delete
Annotations:  <none>
API Version:  litmuschaos.io/v1alpha1
Kind:         ChaosResult
Metadata:
  Creation Timestamp:  2020-09-24T10:09:01Z
  Generation:          41
  Resource Version:    1305945
  Self Link:           /apis/litmuschaos.io/v1alpha1/namespaces/shubham/chaosresults/probe1-pod-delete
  UID:                 0ea90e5a-c059-4593-8c69-a47c0e3ec069
Spec:
  Engine:      probe1
  Experiment:  pod-delete
Status:
  Experimentstatus:
    Fail Step:                 N/A
    Phase:                     Completed
    Probe Success Percentage:  100
    Verdict:                   Pass
  Probe Status:
    Name:  probe-k8s-1
    Status:
      Pre Chaos:  Passed 👍
    Type:         K8sProbe
    Name:         probe-k8s-2
    Status:
      Pre Chaos:  Passed 👍
    Type:         K8sProbe
    Name:         probe-k8s-3
    Status:
      Post Chaos:  Passed 👍
    Type:          K8sProbe
    Name:          probe-k8s-4
    Status:
      Post Chaos:  Passed 👍
    Type:          K8sProbe
Events:
  Type    Reason   Age    From                     Message
  ----    ------   ----   ----                     -------
  Normal  Awaited  3m9s   pod-delete-fg2cj7-vgmdp  experiment: pod-delete, Result: Awaited
  Normal  Pass     2m13s  pod-delete-fg2cj7-vgmdp  experiment: pod-delete, Result: Pass

repo: litmuschaos/litmus-go


text:
Add docs for pod memory hog experiment

Add documentation for pod memory experiments which will contain the info about the experiment.

PR to fix the issue - https://github.com/litmuschaos/litmus-docs/pull/254

repo: litmuschaos/litmus


text:
关于下载附件的内容

测试过下载附件的语音，图片都没有问题。
但是下载的视频是个0kb大小的文件。
完全无法播放。
下面是下载代码
path = 'd:\wx_client\res_' + str(itchat.search_friends()['Uin'])
data['fileName'] = msg.fileName
isExists = os.path.exists(path)
print(isExists)
if isExists is False:
os.makedirs(path)
msg.download(path + '\' + msg.fileName)

@djjeng77 这是目前网页版的问题，网页版的视频下载接口有事就是不可用的。

repo: littlecodersh/ItChat


text:
🛑 USTC is down

In cb1263e, USTC (https://www.ustc.edu.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: USTC is back up in 44a0802.

repo: littlekud/sites-status


text:
Stubbing doesn't work with Hash#fetch

Soeh, it looks like Hash#fetch doesn't really call [] at all.
it "gets 'pokémanz' from WHATMON, not 'digimon'" do
  ENV["WHATMON"] = "digimon"
  stub_env "WHATMON", "pokémanz"
  expect(ENV.fetch("WHATMON")).to eq "pokémanz"
end

The result:
Failure/Error: expect(ENV.fetch("WHATMON")).to eq "pokémanz"

  expected: "pokémanz"
       got: "digimon"

  (compared using ==)

However, this passes as expected (notice I've changed fetch into [] syntax:
it "gets 'pokémanz' from WHATMON, not 'digimon'" do
  ENV["WHATMON"] = "digimon"
  stub_env "WHATMON", "pokémanz"
  expect(ENV["WHATMON"]).to eq "pokémanz"
end

Sorry, I missed this. Will get this fixed in the next couple of days.

Just sas you had made a pr. Looks good, will release new version in next couple of days. Thanks for reporting and for fixing :smiley_cat:

This is now merged and released in version 1.0.3. Thanks again.

Great, thanks, @littleowllabs. :grinning:

authors: littleowllabs sindrenm


text:
Discussion: BLE Example App

Hey All,
I intend to start a BLE Demo App for lvgl, this is a general discussion to collect ideas for what people would like to see in that App..
At the top level there are 2 parts to BLE, the Client and the Server:
The Client:
Essentially the Client scans for other BLE Devices and connects to a chosen device, so my intention is to have a list of available devices and it connects to the one chosen by the user.
Once connected, it will display a number of parameters, much like the Scanner Apps for Android etc.
The Server:
The Server "Advertises its presence, the contents of the Advertising packet can be dynamic at run time, such as the device name etc.
Then it can be connected to by another device, such as a phone or another ESP etc.
/discuss :D

Hi,
Sounds good!
It seems reasonable to create 2 separate apps (server and client).
BTW, on the highest level the roles are "Peripheral" ( Sends out advertisements to inform central devices that it is ready for connection.) and "Central" (Scans for advertisements from peripheral devices and initiates connections). IMO these names are more intuitive.

Hey All,
I intend to start a BLE Demo App for lvgl, this is a general discussion to collect ideas for what people would like to see in that App..
At the top level there are 2 parts to BLE, the Client and the Server:
The Client:
Essentially the Client scans for other BLE Devices and connects to a chosen device, so my intention is to have a list of available devices and it connects to the one chosen by the user.
Once connected, it will display a number of parameters, much like the Scanner Apps for Android etc.
The Server:
The Server "Advertises its presence, the contents of the Advertising packet can be dynamic at run time, such as the device name etc.
Then it can be connected to by another device, such as a phone or another ESP etc.
/discuss :D

Great!

authors: Aiouan kisvegabor ttxs1002004


text:
Cmake build

Hi!
These days CMake became a de-facto standard for building and distributing C/C++ projects. Also, like most C++ programmers, i hate autotools/automake and don't know anyone who uses clib in their development (not going to offend clib).
So i've add CMake build support for SOIL.
Cons:

clib and automake builds are probably slightly broken because of moving compile defs from actually compile defs to CMake-configured header file (passing string defs to compiler is broken on Windows).

Pros:

it's possible to build/install SOIL as static or shared libs and easlily discover with CMake
it works for *nix, Windows and Android (i personally use it for Android project) and will work (after i get mac device :) ) on iOs.
it's able to provide custom headers/libraries to SOIL build (needed since we have amount of different OpenGL versions these days)
doxygen documentation autogenerates while building if doxygen installed

Also i've added names to enums in SOIL.h just to slightly improve autodocs generation.
Thanx for your attention and criticism :)

unfortunately, I no longer have control of this repository so someone from littlstar will have to review, and merge. This repository should probably be archived as anyone who would maintain is no longer able to

Understood.
Thank You.

authors: Mezozoysky jwerle

repo: littlstar/soil


text:
为什么train文件训练出的pytorch模型，处理新闻后会出现乱码

请问作者，我用的项目给的处理后的数据集，在train文件里训练后，生成了checkpoint-0文件夹，我把这个模型放到generate.title文件里后，可以正常运行，但是处理输入的新闻后会出现乱码结果，不知道是哪里的情况，编码也是utf8正确的

另外那要处理自己数据集的话，该是什么格式呢，和train-data一样的格式可以吗

需要数据格式一致

谢谢回复，上周末解决了这个问题，是因为之前测试读取数据是否正常的时候生成的cached_train和cached_test缓存文件没有清除，改掉后就正常了
我想基于这个模型做一个对中文新闻的实例抽取和事件抽取模型，正在用gpt2medium预训练模型做训练，目前loss率还是比较高，预测效果还是不太好，我正在继续调整
wwdz
@.***
---原始邮件---
发件人: @.>
发送时间: 2023年4月7日(周五) 下午3:31
收件人: @.>;
抄送: @.@.>;
主题: Re: [liucongg/GPT2-NewsTitle] 为什么train文件训练出的pytorch模型，处理新闻后会出现乱码 (Issue #41)
需要数据格式一致
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


text:
Concatenating FASTQs

Hi authors,
Love the tool, super useful idea.
I'm working with some public data and (predictably) having some Qs about hoe it was processed. Each sample has lanes 1/2 (L1/2), but additionally the data seems to have gone through two sequencing runs (for a total of 4 "lanes" per individual biological sample).
My question is do you think I would be able to concatenate the FASTQ files together (a la this thread), in terms of the L1/2 and/or across the sequencing runs? I am basically being lazy and just want to run TRUST4 on each biological sample vs each set of FASTQs
Thanks, Kane

TRUST4 supports multiple fastq input files separated by commas or using wild card, so you can run TRUST4 like:
run-trust4 -f xxx --ref XXX -1 read_L*_1.fq -2 read_L*_2.fq -t XXX

aha I see, apologies I thought that was just a dummy placeholder for the benefit of the tutorial. Thanks very much

authors: kanefos mourisl


text:
It doesn't work for vite 4.0.0

[v0.0.7-beta.0] doesn't work for vite 4.0.0.
Rollback to ^0.0.5-beta.6 is OK

[v0.0.7-beta.0] doesn't work for vite 4.0.0. Rollback to ^0.0.5-beta.6 is OK

Thanks for your feedback, I'll take a look😉

@velly  Can you provide the Error info or a minimal reproduction,  thanks!

ok the issues was fixed.

ta.1 to resolve this issue.

Thank you liulinboyi, and take care of yourself.

authors: liulinboyi velly

repo: liulinboyi/unplugin-vue-import-props


text:
🛑 friends.worldofwarships.asia is down

In c742906, friends.worldofwarships.asia (https://friends.worldofwarships.asia/en/about) was down:

HTTP code: 502
Response time: 816 ms

Resolved: friends.worldofwarships.asia is back up in d20f669 after 56 minutes.


text:
Fix to make JsonObject type partial

This fixes the JsonObject type to recognize that keys could be validly undefined.
Wrong behavior:
const obj: JsonObject = ...;
obj.whatever;   // => Json ❌

New/correct behavior:
const obj: JsonObject = ...;
obj.whatever;   // => Json | undefined ✅

My initial thought was that we were supposed to do the opposite, but maybe I'm wrong 🤔
From what I understand, undefined is not serializable to json, so we shouldn't be able to set have undefined values on a LiveObject. UpdateObjectOp.data should be a JsonObject or a Record<string, Json> instead of a Partial<JsonObject>? Sorry about the confusion, I'm still not 100% of what's the correct type

My initial thought was that we were supposed to do the opposite, but maybe I'm wrong 🤔
From what I understand, undefined is not serializable to json, so we shouldn't be able to set have undefined values on a LiveObject. UpdateObjectOp.data should be a JsonObject or a Record<string, Json> instead of a Partial<JsonObject>? Sorry about the confusion, I'm still not 100% of what's the correct type

Yeah, its been confusing for sure. My wrong thinking before comes from the fact that undefined does not have a JSON representation, but you can still work with them in TypeScript land on the input and output side. I hope the following examples help to illustrate that.
On the serializing side, not allowing undefined in inputs was too restrictive. It’s okay to send in { a: 1, b: undefined }, which is the same as sending in { a: 1 }, because they both produce the same string when using JSON.stringify().
On the parsing side, { [key: string]: Json } means that all potential thinkable keys on an object are always going to be Json in TypeScript. They almost never are! For example: JSON.parse("{ a: 1 }").someRandomProperty is definitely going to be undefined.
The old/wrong way
const x: JsonObject = { a: 1, b: undefined };
//                            ^ ❌ Errors here
JSON.stringify(x);  // Even though this call is fine!

Also:
const y: JsonObject = JSON.parse("{ a: 1 }");
const a: Json = y.a;  // Correct
const b: Json = y.b;  // ❌ Incorrect! It’s actually `undefined`, but TypeScript misses that truth

The new/correct way
// ✅ Fine now
const x: JsonObject = { a: 1, b: undefined };
JSON.stringify(x);

Also:
const y: JsonObject = JSON.parse("{ a: 1 }");
const a = y.a;
const b = y.b;
//    ^ ✅ Now correctly infers that these could be Json | undefined

tl;dr undefined itself isn’t a legal Json value, but a JsonObject can still have implicitly-missing or explicitly-missing (through undefined) entries.

Tying this back to your UpdateObjectOp.data use case: I think from that perspective, we should simply ignore any keys with undefined values ourselves (skipping over them when looping). Because depending on where the JSON value is generated, it’s possible that there are explicit-undefined keys (and thus more entries to loop over), which should be treated as implicit-undefined keys (which would not pop up when looping all entries).
I hate the fact that implicit-missing and explicit-missing values are observable (e.g. when looping over entries), but this is the most honest reflection of the possible realities that are the consequence of JS’ language design.

Thank you for the detailed explanation! I now understand why you implemented the fix that way. The new JsonObject type is a better representation of a javascript object created by a JSON.parse.

I hate the fact that implicit-missing and explicit-missing values are observable (e.g. when looping over entries), but this is the most honest reflection of the possible realities that are the consequence of JS’ language design.

Yep, we're on the same page. "The looping over entries" is what I was thinking about when I mentioned serialization. My intuition is that if we allow LiveObject<{ x?: number }>, we might give the impression that the LiveObject keys will be the same on all clients after liveObject.set("x", undefined). But at the same time, it could help us refine the type of LiveObject.delete by allowing only keys where the value can be undefined?

My intuition is that if we allow LiveObject<{ x?: number }>, we might give the impression that the LiveObject keys will be the same on all clients after liveObject.set("x", undefined). But at the same time, it could help us refine the type of LiveObject.delete by allowing only keys where the value can be undefined?

Ohh... great point! I didn't even consider that use case yet, but I think that this now indeed naturally solves for that. In LiveObject.set(x, y), y should never be undefined (or better… it should implicitly translate to LiveObject.delete(x) instead), and indeed: not allowing .delete() on keys that aren't declared to be optional would be an amazing DX if you ask me :)

authors: GuillaumeSalles nvie

repo: liveblocks/liveblocks


text:
Couldn't start livebook on windows11

Environment

Elixir & Erlang/OTP versions (elixir --version):
Elixir 1.14.3 (compiled with Erlang/OTP 25)
Operating system:
Windows 11 pro
How have you started Livebook :
livebook windows
Livebook version:
latest exe file from the website

Current behavior
First time using livebook I run the setup ,picked D: drive as installation drive and when I tried to run it I got this error

tried to run it as administrator no luck either
Livebook.log
Expected behavior
Start livebook
Edit:
keeping the default installation path fixes this

Thank you for the report.
Could you check if installing to the default location (C:\Users\…) works on your system?

@wojtekmach yes keeping the default location works

Any chance you have a whitespace in your username ie, c:\users\john doe?

Thank you again for the report. We're fixing this in Elixir, https://github.com/elixir-lang/elixir/pull/13172.

@wojtekmach sorry for pinging, as far as i understand the patch has still not landed in Livebook. Therefore the last working version of Livebook on Windows 11 is v8.2.
Is there anything one can do to support landing the patch in Livebook?

We will likely have a release in one or two weeks. But we link to nightly builds in the README. Do they suffice for now?

Thanks a lot - i still have two issues which might be due to quirks in my specific Win11 installation. Finally installing nightly worked! Thanks a lot 🙏 🌻

authors: brahimABD98 florianb josevalim wojtekmach

repo: livebook-dev/livebook


text:
tag ingress streams as camera or screen share when no transcoding is specified

Currently, when we setup an ingress stream as WHIP source with not transcoding to avoid wasting server resources. But in that case the ingress interface does not allow us to tag the tracks in the ingress as screenshare or screenshare audio.
As application manage differently main video from screenshare, there are some use cases where it is needed to tag some ingress streams as screenshare.

This will require a small API change for setting up WHIP with bypass_transcoding.

Ok, don't worry, it was a suggestion to provide a more complete service. AS I said in another issue we needed to implement our own ingress where we manage this feature

authors: biglittlebigben slabajo

repo: livekit/ingress


text:
The configuration of parameters can't find the rule

When I see the code, I can't figure the fule of parameters, Can you explain??

s, n, c, ks represents the stride, number of repeated layers, network width and kernel sizes. The multiplication of c1 and c2 is the expansion between input channels to the hidden dimension. g1 and g2, g3 and g4 are basically the same parameters that represent the group number used in the macro-factorized convolution. The rest three parameters are used to decide whether the dynamic shift-max is used or not, while the last parameter is the hyperparameter contained in dynamic shift-max to adjust the reduction ratio.

你好，我在阅读源代码时，发现按照上图cfgs总共有12层，但是论文Table1中M3模型是1stem+11MicroBlock+1claaify，我想请问为什么论文中11MicroBlock和cfgs中的12层对应不上呢？

authors: elfpattern liyunsheng13 thgpddl


text:
pureftp添加了用户，却无法登陆，只能登陆 root

端口21 端口需要打开21 20000~30000端口


text:
Arch要用的话,会很麻烦吗?

本地一个Ubuntu一个Arch,Ubuntu为生产系统,想用arch作为测试系统,何解?

一键包主要应用于生产环境，所以一般不会考虑 Arch。
反正都已经能折腾安装好 Arch 了，不如自行再研究搭建 LNMP 环境

嗯，也是，只是对脚本比较好奇，感觉挺方便的，遇到麻烦再来提issue

全部都读一遍，肯定大致都知道了

authors: TIL-MICE ivmm


text:
🛑 까사미아 www.guud.com is down

In 0a56c0f, 까사미아 www.guud.com (http://www.guud.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 까사미아 www.guud.com is back up in 86fad22 after 27 minutes.

repo: lksjames/monitoring


text:
🛑 조선호텔 www.josunhotel.com is down

In c681f0b, 조선호텔 www.josunhotel.com (http://www.josunhotel.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 조선호텔 www.josunhotel.com is back up in 2d30214.


text:
[Bug] Infinity now ridiculously slow

Describe the bug
Yesterday I was able to use the repo fine, each output took circa 20 seconds. Today I have had to reinstall from scratch and it now takes 15 seconds PER STEP. To produce one image is going to take 12-15 minutes therefore sadly infinity is now broken for me. I use the vanilla install, no Taichi or other fixes and install the diffusers through a huggingface token.
To Reproduce
Steps to reproduce the behavior:
Delete the repo and environment then reinstall. As I have done many times before when things stopped working.
Expected behavior
It to work :D
Desktop (please complete the following information):

OS: Windows 11
Browser Firefox

Additional context
Feeling brave I uninstalled Anaconda3 and deleted the .cache subfolder to see if that would help. It didn't. I then uninstalled/reinstalled Automatic1111's repo to see if that had changed but that's the same as always, one image using the PLMS scheduler, 50 steps at 512x512 takes about 10 seconds. So sadly I give up :-)

I thought it was just me. installed infinity for the first time and each image takes about 15-20 minutes to generate - so uninstalled it. But keep to follow if there're any updates !

Same here.  Following

Ok, I think that I have sorted it! It looks as if Infinity was working off of the CPU rather GPU. Feel free to try the fix but obviously I guarantee nothing, nothing at all..!
Delete 'libiomp5md.dll' from within envs\sd-inf\Library\bin\
From anaconda avtivate the environment (conda activate sd-inf)
Then..
pip uninstall torch
pip3 install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu113
Now just run app.py as normal. The first time it ran it downloaded a couple of gigs of files again but after that everything is running smoothly.

I had this issue in Windows 10 as well. The pytorch channel does not have a latest (1.13.0) for python 3.10 and cuda 11.3. I was able to install a cuda version by setting the version "conda install pytorch=1.12.1 -c pytorch".

I also have this problem and did what you said, but at the moment Infinity still works on the CPU and the GPU doesn't work at all, is there any other solution?

yeah tip of the day: Yeah whenever it super slow check GPU/CPU is used.
Also sometimes i see a message about CPU enhanced instruction support and i know i am up a creek without my GPU-paddle.
@tanglangxia I just redo the repo, if it still fails i usually come to the repo ISSUEs and check for similar errors.
I usually end up pip/conda uninstall pytorch and google how to install pytorch with GPU support.
This repo been rock solid for me mostly though. Knock on wood. :P (Linux though. Is all just easier to get repos working i find,)

I followed the command:
conda install pytorch torchvision torchaudio cudatoolkit=11.3 -c pytorch
when installing, I found that the version directly given are cpu version, very strange
pytorch pytorch/win-64::pytorch-1.13.0-py3.10_cpu_0
pytorch-mutex pytorch/noarch::pytorch-mutex-1.0-cpu
torchaudio pytorch/win-64::torchaudio-0.13.0-py310_cpu
torchvision pytorch/win-64::torchvision-0.14.0-py310_cpu

I did uninstall pytorch first and I installed the cudatookit separately before installing pytorch. FWIW, I installed cudatoolkit=11.6 from the conda-forge channel instead of 11.3 from pytorch, but I doubt that part makes a big difference. I always got 1.13.0 cpu version until I specified pytorch=1.12.1.

Sure enough it was the cudatoolkit version, this time I used the following command：
               conda install pytorch=1.12.1 torchvision torchaudio cudatoolkit=11.6 -c pytorch

I successfully installed the cuda version of pytorch, thanks guys!

I tried the above command but it failed
conda install pytorch=1.12.1 torchvision torchaudio cudatoolkit=11.6 -c pytorch
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.

PackagesNotFoundError: The following packages are not available from current channels:

  - cudatoolkit=11.6

Current channels:

  - https://conda.anaconda.org/pytorch/win-64
  - https://conda.anaconda.org/pytorch/noarch
  - https://repo.anaconda.com/pkgs/main/win-64
  - https://repo.anaconda.com/pkgs/main/noarch
  - https://repo.anaconda.com/pkgs/r/win-64
  - https://repo.anaconda.com/pkgs/r/noarch
  - https://repo.anaconda.com/pkgs/msys2/win-64
  - https://repo.anaconda.com/pkgs/msys2/noarch

To search for alternate channels that may provide the conda package you're
looking for, navigate to

    https://anaconda.org

and use the search bar at the top of the page.

Closing as Windows install instrutions have been updated.

authors: Bill4321 abulka cryptobits magaspah somenewaccountthen supersonic13 tanglangxia


text:
Add Replicate demo and API support

Hey @lllyasviel team! 👋
This pull request integrates Replicate support into your IC-Light model, allowing users to run the model within a Docker environment using Cog.
Key features:

Replicate Demos:

IC-Light (2K+ runs already!)
IC-Light Background (newly added today)

Replicate API: Enables users to run the models directly from their code.

Example usage:
import replicate
output = replicate.run(
    "zsxkib/ic-light-background:60015df78a8a795470da6494822982140d57b150b9ef14354e79302ff89f69e3",
    input={
        ...
        "background_image": "https://replicate.delivery/pbxt/KxPIbJUjSmVBlvn0M3C8PAz6brN5Z0eyZSGcKIVw3XfJ6vNV/7.webp",
        "number_of_images": 1
    }
)
print(output)

In case you're wondering who I am, I'm from Replicate, where we're trying to make machine learning reproducible. We got frustrated that we couldn't run all the really interesting ML work being done. So, we're going round implementing models we like. 😊

Good luck. No API support is ridiculous, but hey, that's @lllyasviel . Drops something awesome that's half backed and then abandon it for the next

Good luck. No API support is ridiculous, but hey, that's @lllyasviel . Drops something awesome that's half backed and then abandon it for the next

@sanebg : Feel free to contribute !

authors: Tetsujinfr sanebg zsxkib

repo: lllyasviel/IC-Light


text:
Hugging face compat

Fixed hugging face transformer path errors for vicuna

The latest commit e04e9ee seems to change every lines of the scripts. I can't let it go through as is now. Would you make a PR for lines you are particularly working on?

repo: llm-attacks/llm-attacks


text:
2个问题

1 不能下载嵌套的M3U8 ，如
https://mudan.iii-kuyunzy.com/20191215/5702_46b0f018/index.m3u8
使用 curl 查看后
curl https://mudan.iii-kuyunzy.com/20191215/5702_46b0f018/index.m3u8
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=800000,RESOLUTION=1080x608
1000k/hls/index.m3u8

得到真实地址
https://mudan.iii-kuyunzy.com/20191215/5702_46b0f018/1000k/hls/index.m3u8
可下载
2 不能自定义下载文件名，恳请修改

好吧，追加第三个问题，合并后会出现一些未知的视频的合并错误，常常有视频会出现莫名其怪的卡顿，跳跃

1 不能下载嵌套的M3U8 ，如
https://mudan.iii-kuyunzy.com/20191215/5702_46b0f018/index.m3u8
使用 curl 查看后
curl https://mudan.iii-kuyunzy.com/20191215/5702_46b0f018/index.m3u8
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=800000,RESOLUTION=1080x608
1000k/hls/index.m3u8

得到真实地址
https://mudan.iii-kuyunzy.com/20191215/5702_46b0f018/1000k/hls/index.m3u8
可下载
2 不能自定义下载文件名，恳请修改

1.嵌套地址的暂不考虑支持
2.自定义下载名字 ：加上 -o="自定义名字"
3.合并的卡顿：我也遇到过此问题，目前怀疑有可能是视频资源问题。

借楼提个建议，加入自定义请求头，有些密钥需要cookie才能获取

收到------------------ 原始邮件 ------------------发件人: 香芋奶茶  notifications@github.com发送时间: 2021年3月3日 12:02收件人: llychao/m3u8-downloader m3u8-downloader@noreply.github.com抄送: 萌萌站起来 lychao_vip@163.com, Comment comment@noreply.github.com主题: 回复：[llychao/m3u8-downloader] 2个问题 (#3)
借楼提个建议，加入自定义请求头，有些密钥需要cookie才能获取
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/llychao/m3u8-downloader/issues/3#issuecomment-789410568",
"url": "https://github.com/llychao/m3u8-downloader/issues/3#issuecomment-789410568",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]

@llychao 合并的卡顿和跳跃，是一个 BUG，具体描述在 #16，解决方案已经提交 Pull Request #17

authors: Junyi-99 Kiritomo llychao vjsdhyygy


text:
LM Studio App crashes with following error message on launch.

Uncaught Exception:
Error: dlopen(/Applications/LM Studio.app/Contents/Resources/app/.webpack/main/build/Release/gguf/llm_engine.node, 0x0001): Symbol not found: _cblas_sgemm$NEWLAPACK$ILP64
Referenced from:  /Applications/LM Studio.app/Contents/Resources/app/.webpack/main/build/Release/gguf/libllama.dylib (built for macOS 14.0 which is newer than running OS)
Expected in:      /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
at process.func [as dlopen] (node:electron/js2c/asar_bundle:2:1822)
at Module._extensions..node (node:internal/modules/cjs/loader:1326:18)
at Object.func [as .node] (node:electron/js2c/asar_bundle:2:1822)
at Module.load (node:internal/modules/cjs/loader:1096:32)
at Module._load (node:internal/modules/cjs/loader:937:12)
at f._load (node:electron/js2c/asar_bundle:2:13330)
at Module.require (node:internal/modules/cjs/loader:1120:19)
at require (node:internal/modules/cjs/helpers:103:18)
at 4001 (/Applications/LM Studio.app/Contents/Resources/app/.webpack/main/index.js:2:943)
at r (/Applications/LM Studio.app/Contents/Resources/app/.webpack/main/index.js:8:3957
My Device configuration :

Similar error as well

и как решить эту проблему?

authors: cmirza kcinit32 nateshmbhat

repo: lmstudio-ai/model-catalog


text:
fix: README

Misc fixes

thank you very much! :heart:

authors: dni kilrau

repo: lnbits/boltz-extension


text:
Corrected example CURL requests in multiple extension API docs

The move to FastAPI changed the API URLs. This change updates the example URLs for LNbits extensions

Thank you for this painstaking PR!

authors: blackcoffeexbt callebtc

repo: lnbits/lnbits-legend


text:
Added William Lin's Youtube Channel

He is the most growing Youtube Channel in subject of cp . And also Google Kickstart round A 2020 winner .

Ah I've heard of William, despite the years I've been away from the scene.
Let me fix up the formatting. Thanks

authors: Atharva-k lnishan

repo: lnishan/awesome-competitive-programming


text:
Speakers' @ handles should be for twitter, not github

following discussion with @iancrowther  on gitter we agreed that in future these should be Twitter handles, and not as they have been the last two months, which is github handles.
Same goes for the newsletter.
cc. @jkbits1 @web-bert

Were the Twitter handles manually added previously?
We are just pulling in the data from the GitHub api atm.
Sent from my iPhone

On 26 Aug 2015, at 16:43, Adam Davis notifications@github.com wrote:
following discussion with @iancrowther on gitter we agreed that in future these should be Twitter handles, and not as they have been the last two months, which is github handles.
Same goes for the newsletter.
cc. @jkbits1 @web-bert
—
Reply to this email directly or view it on GitHub.

Added a new issue to speakers
https://github.com/lnug/speakers/issues/57
@admataz are you in a position to pick it up?

authors: admataz iancrowther simonmcmanus


text:
[Agent] 极简黑白插画

systemRole
你是谁
你是一个插画绘画大师，擅长各种风格的绘画与理解。
你要做什么

理解用户的输入，转化成一些简短、易于理解的英文单词
给定图像风格为：Notion头像、极简、黑白、抽象、简笔画、几笔完成

将上述用户的输入转换过来的单词与风格单词结合，然后转换为简洁、合理的英文单词，输入给【DALL.E3】插件，进行仅一幅图画的绘制。
identifier
white-black
avatar
⚪
title
极简黑白插画
description
擅长插画创作与风格转换
tags
插画, 艺术, 设计,
locale
zh-CN

preivew:

程序员走在路上
两人握手
小猫、睡觉、台子
阳光、沙滩，美女，长发

repo: lobehub/lobe-chat-agents


text:
stairs

cant get up to the floor above. this is same as top ramp action... could we generalize it without having to do custom things for everything
an achors neighbour lookup can check own level and one up and one down and if either up or down is much closer to own level or something then connect to that one
it is also possible to jump off stairs, while it should be blocked... the anchor sentinels now allows for blocking in their directions... so that would be good to use in general

ramps work like stairs
can get on and off at both ends
stairs don't respect lateral blocking for some reason

repo: local-minimum/lmcore


text:
How to do pagination?

How to realize paging query，thanks

localForage is a library for offline storage, not pagination. If you're looking to save paginated results in localForage, using the page number as part of your key would work.

authors: lwpassvoice tofumatt

repo: localForage/localForage