chore(litmus-portal): Code refactoring

What this PR does / why we need it: Code refactoring and Code quality improvements
Fixed: Maps, Login page and minor changes in other components and linting rules
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Checklist

[ ] Does this PR have a corresponding GitHub issue?
[ ] Have you included relevant README for the chaoslib/experiment with details?
[ ] Have you added debug messages where necessary?
[ ] Have you added task comments where necessary?
[ ] Have you tested the changes for possible failure conditions?
[ ] Have you provided the positive & negative test logs for the litmusbook execution?
[ ] Does the litmusbook ensure idempotency of cluster state?, i.e., is cluster restored to original state?
[ ] Have you used non-shell/command modules for Kubernetes tasks?
[ ] Have you (jinja) templatized custom scripts that is run by the litmusbook, if any?
[ ] Have you (jinja) templatized Kubernetes deployment manifests used by the litmusbook, if any?
[ ] Have you reused/created util functions instead of repeating tasks in the litmusbook?
[ ] Do the artifacts follow the appropriate directory structure?
[ ] Have you isolated storage (eg: OpenEBS) specific implementations, checks?
[ ] Have you isolated platform (eg: baremetal kubeadm/openshift/aws/gcloud) specific implementations, checks?
[ ] Are the ansible facts well defined? Is the scope explicitly set for playbook & included utils?
[ ] Have you ensured minimum/careful usage of shell utilities (awk, grep, sed, cut, xargs etc.,)?
[ ] Can the limtusbook be executed both from within & outside a container (configurable paths, no hardcode)?
[ ] Can you suggest the minimal resource requirements for the litmusbook execution?
[ ] Does the litmusbook job artifact carry comments/default options/range for the ENV tunables?
[ ] Has the litmusbooks been linted?

Special notes for your reviewer:

/preview

./preview

/preview 20

/preview 20

/preview

/preview

/preview 10

/preview 20

/preview 20

/preview 10

/preview 10


Decrease Frame Size and quality

need to decrease the frame size and quality
so we could send the image to the server efficent

yea this is done in the camera application side
in the android folder and its changeable, means we will be able to decide the size
of the image and the quality so its will be also small in size but yet detecble
cus right now image is something like 80kb and its alot its must be atmost 1kb and even this is alot i think

#34


More socket API improvements

unit tests broke :\

Erk! Sorry :/

fixed as of https://github.com/majestrate/i2p.socket/commit/6da35a66a2291d0eee7acf178accc05e5e8f8fb2
make sure to run tox :^)


Add LFG to Token List

https://dexscreener.com/avalanche/0x13dd08cd226c11da0939d0d94a807a8f1a3ee8ab

No pre sales
Contract renounced
No taxes
Liquidity burned

doesnt meet liquidity requirements, will close for now

Hey @Unsehrtain - When would be a good time to reopen this PR? We have 128K liquidity with a 453k market cap.


Fake PR to fix metal3-dev-env CI

This is a fake PR to test metal3-dev-env integration CI.

/test-v1a1-integration


Add Hackfoldr by @superbil

[x] Update contents.json instead of README
[x] One project per pull request
[x] Project added at the end of the list (a script sorts projects automatically)
[x] Avoid iOS or open-source in description as it is assumed
[x] Use approved format for your entry

Hi, could you update the itunes link to this instead:
https://itunes.apple.com/app/hackfoldr/id919010837
thx

@dkhamsing I just fix it

thx!


Process requests in parallel

This is an attempt to fix https://github.com/clojure-lsp/clojure-lsp/issues/1240, where the failure to run requests in parallel leads to small freezes while typing in Emacs. In other editors it manifests differently. In Calva, we've noticed that diagnostics and semantic tokens are delivered more slowly.
This commit changes lsp4clj to allow language servers to process and respond to up to 4 requests in parallel. This is a departure from the spec, which says "Responses to requests should be sent in roughly the same order as the requests appear". However, it is closer to what lsp4j and cloure-lsp were doing before the migration away from lsp4j.
In the original implementation, lsp4j consumed messages one at a time, handing them off to the language server. The language server processed each message serially.
lsp4j fully processed each notification before it moved on to the next message.
But requests were a little different. Like notifications, requests were handed to the language server in series. But the language server returned a CompletableFuture which could, at the server's option, be incomplete. lsp4j would arrange for the result of that future, whenever it was done being calculated, to be sent back to the client as the response. This let the language server decide how much of the response to calculate (if any) while blocking other requests and notifications, and how much to calculate in another thread, allowing other requests and notifications to be processed in parallel.
If the response creation was wrapped in CompletableFuture/supplyAsync, as was the case for almost all of clojure-lsp's requests, then the response would be calculated in the "common" ForkJoin thread pool. This thread pool has a configurable parallelism (on my machine it's 3). The end result is that clojure-lsp processed most of its requests in parallel—up to 3 at a time in my case.
I didn't understand this arrangement as I was migrating lsp4clj away from lsp4j. I thought that lsp4j processed every request in series, so that it could follow the spec's guidance. I followed that pattern, making all the requests and notifications serial. (Actually I started with an implementation that distributed both requests and notifications to the server in parallel. That meant the server processed requests in parallel but also that it received message out of order. That parallelism was removed in 6996fdbaefe743431994839db07676a24052cd25.)
Technically, the strictly serial implementation works, but it causes the lagginess and delays observed in #1240. So, this patch is an attempt to restore the earlier behavior, though with a different implementation.
In this implementation lsp4clj continues to read notifications and requests in series, and passes them to the language server with lsp4clj.server/receive-notification and lsp4clj.server/receive-request. The bodies of these functions are executed serially. Before this commit (though after the migration), the return value of receive-request was used as the response, which meant that each response was fully calculated serially. But now the language server can, optionally, return a deref-able object from receive-request. If it does, the deref-able will be derefed in a thread pool of size 4. So, a language server can indicate to lsp4clj that it would like a request to be processed in parallel with other requests by, for example, returning a delay. Of course, if it wants a request to block other requests, it can still do that by calculating the full response synchronously in receive-request. Or it can do some of both, calculating part of a response, then wrapping the rest of the calculation in a delay.
There were four places where clojure-lsp processed responses synchronously (by using CompletableFuture/completedFuture instead of CompletableFuture/supplyAsync): initialize, shutdown, rangeFormatting and executeCommand. I think it's important that clojure-lsp continues to process the initialize request before it allows others through. But the others could be re-considered someday:

executeCommand. On the clojure-lsp side, executeCommand starts a future and returns nil. The only difference that I see from using supplyAsync (or now delay) is that the client sees a nil response before the command is finished executing. If this isn't important—if the client would be content with the command executing asynchronously, but getting a nil only after it had finished—then executeCommand could use delay.
rangeFormatting. On the clojure-lsp side, rangeFormatting is an anomaly. It calculates its response synchronously, at the exclusion of other requests. On top of this, unlike every other request, it sets and releases a global lock, presumably as a way to double-check that if multiple rangeFormatting requests come in, the later ones are dropped. I'm not sure why this happens—it seems like a bug fix from long ago, though I haven't tracked down which bug it was. It seems odd though—by blocking other requests, there can't be other simultaneous rangeFormatting requests so isn't the lock useless? Anyway, I don't currently see any reason why this couldn't be asynchronous (especially since it already uses process-after-changes) though it would need more research.
shutdown. The clients aren't likely to send requests or notifications after sending shutdown, so I don't see a good reason for it to be synchronous, though it probably doesn't hurt.

I've tested this with clojure-lsp, wrapping most of its requests in delays. This does fix #1240, so I think it should be merged. However, in the long run I'm not sure mimicking the old behavior is an ideal solution. Part of the reason we're seeing these delays is because we're processing every request fully, even if it's become out of date. The client is capable of indicating that it no longer needs a response by sending a $/cancelRequest, but we're ignoring those. We also don't stop an in-progress analysis if we've learned that the text of a file has changed since the analysis was started. Fixing that kind of thing might make these spec-bending compromises less necessary.

@mainej
lsp has a concept of document version, did that come into play with the parallelism at all? From the consumption side, it seemed to always increase but that seems unlikely if it was using this pool approach.
Can you walk through how you would expect these two async commands to be processed? Is the client expected to queue requests?
(def a 1) (def x |a)

rename 0,17, 'bee'
rename 0,17, 'c'

Thanks for the research and good explanation

executeCommand

I think we could change to return nil only after executing, needs a little bit of testing if that affects clients in any way though.

rangeFormatting

yeah, it was certainly related to bugs, but I can't recall what exactly. I know we had issues in the past where rangeFormatting take a long time and we block the editor with a simple paredit slurp, even so, it doesn't seem related to locking or not, I do think we could think about removing it but would be good to research indeed.

shutdown

Yeah, I'd keep sync

However, in the long run I'm not sure mimicking the old behavior is an ideal solution. Part of the reason we're seeing these delays is because we're processing every request fully, even if it's become out of date. The client is capable of indicating that it no longer needs a response by sending a $/cancelRequest, but we're ignoring those. We also don't stop an in-progress analysis if we've learned that the text of a file has changed since the analysis was started. Fixing that kind of thing might make these spec-bending compromises less necessary.

Totally agreed, we never had fully support for cancelRequest but is something we should consider it indeed, canceling kondo calls may help a lot as you mentioned.
I'm ok with this PR as we weren't aware of any big concurrency issues, so it's ok to rollback to this behavior for now IMO.

@mainej I gave a try with clojure-lsp and it does feel fasterthe  than latest release, but still blocking emacs lsp-mode, I know the block on the editor is another issue to be solved probably on lsp-mode, but my point is that it doesn't block at all on previous release (lsp4j), so maybe we are not handling that parallel as before?
One thing to notice is that I do get diagnostics a little bit faster than lsp4j clojure-lsp, but the tradeoff probably is not worth it.
How I am testing:

clone squint-cljs/squint
open compiler.cljc
add a (def x 1) anywhere on top level
write at top level (str xxxxxxxxxx) where each x you take some milliseconds to write.

Comparassion
Previous release (using lsp4j)
my input is never blocked, I on purpose stop typing x 3 times to see how much time it takes for diagnostics appear:

latest release (master)
I never stopped inputting x, it's really lagging, I only stop at the last x to wait for last diagnostics to finish.

This branch
Same as the latest release, but a little bit faster

I do think this PR improves but not as before lsp4clj v1, I know the client should not block, but I wonder what we are doing differently that lsp4j was processing "faster"? I'm ok merging this PR too as an improvement, LMK what you think and thanks for the help, LMK if you need any help with any more testing/debugging!

Thanks for testing @ericdallo. The improvement you're seeing is so small that IMO this PR isn't worth merging yet.
Thanks for making the videos. They illustrate the problem well. Unfortunately, I can't reproduce anything like what you're seeing, despite having fewer cores than you. I started making videos to show you, but they all look like your first video. So, to continue making progress, I think I'll need assistance debugging. Would you help me with that?
I've pushed updates to both repos that will enable tracing. Will you make a build with those, then send me the logs created from the moment you start typing xs until whenever the logs settle down after you stop? If possible, a video of the same typing session might be helpful too. I'll start with that, but we might have to enable tracing on an old build too eventually.

lsp has a concept of document version, did that come into play with the lsp4j parallelism at all? From the consumption side, version seemed to always increase but that seems unlikely if it was using this pool approach.

@snoe as you're aware, version is synced with the client in didChange. When a client sends many didChange notifications in a row, lsp4j would process each one in series, not parallel. It processed all notifications in series, and in fact all requests too. Parallelism was only introduced at the behest of clojure-lsp. So, assuming clients sent monotonically increasing version numbers in the didChange notifications (which I believe they all do), then the clojure-lsp db would contain monotonically increasing versions too.
The new code does the same thing—both notifications and requests are processed in series, and parallelism is only introduced if clojure-lsp requests it. I tried to explain the reasons why and the mechanics of how this works in the PR description, the code comments, and the README. Please let me know if you have suggestions for how to re-word things to make it clearer.

Can you walk through how you would expect these two async commands to be processed? rename rename

Renames are and always have been difficult to analyze, IMO. Quickly doing two renames in a row has always been buggy. The bugginess is unrelated to any parallelism at the lsp4clj level—it has to do with the fact that prepareRename doesn't process-after-changes, a parallelism problem in the clojure-lsp level. That is, even in the current release, which has no parallelism from lsp4clj, the bug is still present.
So, I'm not sure what we're going to get out of studying rename as an example. It's going to be too hard to reason about whether we've fixed, introduced, or are continuing to see buggy behavior.
I think your point though is this: Suppose a client issues two commands that would both change a document. If we process them in parallel, isn't there a race condition where they could both use the same "initial" state, then clobber the document as they each suggest different edits? The answer is, yes, in theory. But, I'm not worried for two reasons:

Even with lsp4j this was a risk. You seem doubtful that lsp4j was actually processing commands in parallel, but the code I'm looking at and the logs I'm seeing convinces me it was. If you have evidence otherwise, please share.
Humans initiate commands, which cause document edits. Most of the refactorings are fast enough that a human simply doesn't have time to submit two in quick enough succession for them to conflict with each other.

Together these make me think this is a hypothetical problem, but not a practical one.

Is the client expected to queue requests?

No, we can't demand or expect any changes from the clients.

@mainej sorry for the huge log, I tried to keep as minimal possible getting only logs after inputting x. I didn't record the gif but it's exactly as my previous gif, so don't know if that would make any difference
clojure-lsp-branch-log.txt
One thing I noticed is that the slowness doesn't happen with small buffers, so it's like the issue would be related with didChange/analysis with clj-kondo locking the uri? not sure.

@ericdallo, yes, I have semantic tokens—and code lens—enabled.

The new code does the same thing—both notifications and requests are processed in series, and parallelism is only introduced if clojure-lsp requests it. I tried to explain the reasons why and the mechanics of how this works in the PR description, the code comments, and the README. Please let me know if you have suggestions for how to re-word things to make it clearer.

If the response creation was wrapped in CompletableFuture/supplyAsync, as was the case for almost all of clojure-lsp's requests, then the response would be calculated in the "common" ForkJoin thread pool. This thread pool has a configurable parallelism (on my machine it's 3). The end result is that clojure-lsp processed most of its requests in parallel—up to 3 at a time in my case.

I guess I'm trying to figure out how lsp4j behaved in this way but didn't seem to exhibit this parallelism and make sure that some sequencing wasn't missed.  My experience, and it sounds like you thought the same, was that CompletableFuture/supplyAsync at least started execution of the futures in sequence. My worry is that if we don't sequence things exactly as lsp4j did, we'll introduce a number of hard to see bugs.  Where in lsp4j is the forkjoin thread pool created?

Where in lsp4j is the forkjoin thread pool created?

@snoe here

CompletableFuture/supplyAsync at least started execution of the futures in sequence

You may be right, but I'm not 100% sure that's true. clojure-lsp gave supplyAsync a Supplier. That always happened in the same thread. But the documentation for supplyAsync doesn't say whether it's obligated to call Supplier/get in any particular order. In fact, I suspect that it passes the Supplier off to the common ForkJoinPool, which gets to decide when and in what order to call Supplier/get.

Where in lsp4j is the forkjoin thread pool created?

@snoe here

@ericdallo as I read the lsp4j code, that's not correct. That executor service you linked to is used for something else—starting the input stream reader thread. It's passed to a ConcurrentMessageProcessor, which uses it to start one and only one thread that reads from the input stream.
In fact, to answer your question @snoe, lsp4j doesn't arrange to use a forkjoin thread pool at all. Instead, it was lsp4clj that put the request processing in a forkjoin pool via supplyAsync—the common pool, which is the default when you use supplyAsync. That is, lsp4j uses the CompletableFuture api to configure things so that whether or not the future is executed in a separate thread, then the result is put on the output.
But lsp4j doesn't manage any request-processing threads itself, or even require that any asynchronous facilities be used at all. As far as it is concerned, its users have complete control over whether anything is run asynchronously. Its users can return everything in a CompletableFuture/completedFuture, in which case everything will be synchronous. Or they can use supplyAsync or any of the many other CompletableFuture facilities to calculate a value asynchronously. lsp4clj chose to use supplyAsync, which is what was introducing the asynchrony.
Does that make sense how by using supplyAsync the asynchrony is our "fault", and lsp4j was only allowing that to happen?
@ericdallo thanks for the logs. From them I realized that you have lsp-modeline-code-actions-enable on, which I didn't. So that's another process-after-changes request that your editor sends much more regularly than mine. Looking at your dotfies, you also have lsp-idle-delay set to 0.2, instead of the default of 0.5. Changing both of those things, I'm able to get lagginess more easily, though still not as much as your videos.
I added more logging to see where lsp4clj v1 is spending time. It appears that with the lower lsp-idle-delay, the editor floods clojure-lsp with requests. When enough of them use process-after-changes the threadpool that writes to the output gets completely blocked, meaning other requests that are usually very short-lived end up waiting for a turn to start. I tried solving this switching the delays that I added to clojure-lsp to be futures. That way a request can at least do all of its processing while it's waiting for a turn to put the response on the output.
To be honest I don't understand why didn't have theses same problems before. The common ForkJoinPool has a limited amount of threads, so it seems like it would have had the same problem of the pool filling up with process-after-changes threads. Understanding this better is one possible path forward, but not one I'm excited to follow.
I pushed the logging and delay->future changes, so you can experiment with them by pulling the two branches and making another build. I'd be curious to hear the outcome, but I think it's important to consider one of your points @snoe:

My worry is that if we don't sequence things exactly as lsp4j did, we'll introduce a number of hard to see bugs.

I'm feeling this way too. From one perspective this PR is an attempt to replicate the CompletableFuture behavior using core.async. But it doesn't seem to be going very well, and my patience for it is waning.
CompletableFuture has an interesting property which I don't know how to replicate in "pure" Clojure. When you create a CompletableFuture whose value will be calculated in another thread, you can also attach other code (via .then, and others) that will also run in that thread. So, if you have a bunch of CompletableFutures that are processing requests, you can ask their threads to put their results on the output using .then. I don't know how to replicate that in Clojure. Tools like future don't have facilities to attach extra code to them. Instead, if you want to deref them in parallel, you need another thread pool to do that.
Or at least that's my current thought about why the new code isn't behaving like the CompletableFuture code. My attempts to fix that seem like adding threads on top of threads on top of threads, trying to match the sequencing and asynchrony we had before.
So, I think I'll experiment with making lsp4clj v1 use CompletableFutures. That is, I want clojure-lsp to create and return CompletableFutures to lsp4clj, so that lsp4clj can do that lsp4 was doing. That'll remove one big difference between the current code and how lsp4j was doing things. It may not be exactly equivalent, but it'll at least get us a lot closer. How does that sound?
Note that I'm not saying I want to remove core.async entirely. It's still a fine model for reading-from-input and writing-to-output.
@ericdallo I've suggested the possibility of using promesa before, since it uses CompletableFutures under the hood. You've been hesitant about that. I think your hesitation was mostly that you were curious if we could find another way to do it. But if you have other concerns, please let me know.

In fact, to answer your question @snoe, lsp4j doesn't arrange to use a forkjoin thread pool at all. Instead, it was lsp4clj that put the request processing in a forkjoin pool via supplyAsync—the common pool, which is the default when you use supplyAsync. That is, lsp4j uses the CompletableFuture api to configure things so that whether or not the future is executed in a separate thread, then the result is put on the output.

Oh, you are right, that code is tricky, but makes sense!

Does that make sense how by using supplyAsync the asynchrony is our "fault", and lsp4j was only allowing that to happen?

Yes, good catch!

@ericdallo thanks for the logs. From them I realized that you have lsp-modeline-code-actions-enable on, which I didn't. So that's another process-after-changes request that your editor sends much more regularly than mine. Looking at your dotfies, you also have lsp-idle-delay set to 0.2, instead of the default of 0.5. Changing both of those things, I'm able to get lagginess more easily, though still not as much as your videos.

Good point, those settings are a tradeoff of smooth UI vs performance, but that used to work very well with old clojure-lsp and other LSPs

I pushed the logging and delay->future changes, so you can experiment with them by pulling the two branches and making another build. I'd be curious to hear the outcome, but I think it's important to consider one of your points @snoe:

Sounds good, I'll test it and let you know!

So, I think I'll experiment with making lsp4clj v1 use CompletableFutures. That is, I want clojure-lsp to create and return CompletableFutures to lsp4clj, so that lsp4clj can do that lsp4 was doing. That'll remove one big difference between the current code and how lsp4j was doing things. It may not be exactly equivalent, but it'll at least get us a lot closer. How does that sound?

It'd be really good to know if that difference would really "fix" the problem, so if you wanna try that, please do, it's a pity we would stop using core.async for that, but I'm fine too, promesa should help things become "more clojure" though

@ericdallo I've suggested the possibility of using promesa before, since it uses CompletableFutures under the hood. You've been hesitant about that. I think your hesitation was mostly that you were curious if we could find another way to do it. But if you have other concerns, please let me know.

Yeah, I think it's clear now to me how it'd help us, so I'm ok giving it a try :)

I'd also vote for promesa, since it gets us closer to a possible cljs version, where core.async can be problematic.

@ericdallo I've pushed updates to both branches. The current code tries to stay more faithful to lsp4j. Please let me know how performance is for you.
Since your last test I switched over to using CompletableFuture. It worked as I had planned, but the performance was (in hindsight, predictably) terrible, even worse than what you and @borkdude were seeing originally. After you stopped typing it would usually be a few seconds before lint and semantic tokens caught up.
Eventually I figured out the slow down. When you start typing, the client sends a did-change. A moment after that, it sends several other requests, including several process-after-changes requests. Those process-after-changes requests fill up the common pool.  If you keep typing, entering characters at a certain perfect pace, the client keeps sending did-change, which keeps resetting the server's debounce timer (for seconds potentially). At the same time, the client keeps sending other requests—mostly completion and code-lens, but some others. During this, the process-after-changes requests are still siting in the pool, sleeping in a loop, waiting for A) the debounce timer to expire so that B) the clj-kondo analysis can be run, so that C) the processing-changes flag can be released. When that finally happens, the process-after-changes requests can be processed. Then all the other requests that have backed up behind them can too. But there are a lot of them, and they take awhile to finish.
I knew lsp4j must be doing something to avoid this, but it took awhile to figure out what. I was surprised to realize that lsp4j does handle $/cancelRequest notifications from the client. In these long-running scenarios the client decides that either A) it no longer needs a response, for example because the text has changed since a completion request was placed, or B) the server has taken too long and the client should give up. In the long-typing scenario from your videos, sometimes the client cancels the process-after-changes requests, meaning there are fewer things filling the pool. But mostly the client cancels requests that are waiting for a turn in the pool. When the pool finally empties out, there are only a few queued requests, and they can be processed quickly.
lsp4j handles the $/cancelRequest notification by cancelling the CompletableFuture. After adding that into lsp4clj in 20568af, I think we're finally on par with lsp4j. The performance seems a lot better after that.
For me there are still times that the pool fills up (because my common pool has only 3 threads). This manifests as a non-process-after-changes request whose trace is a lot longer than its logged duration. I can imagine a few ways to fix that. We could create a separate pool for the process-after-changes requests, so they only block each other. Or, perhaps, we could change process-after-changes to use something besides the sleep-in-a-loop pattern, so that it doesn't consume a thread.
I'm hopeful you'll see the same improvements I have. Let me know how it goes.

Amazing deep dive @mainej, I'm quite surprised about cancelRequest as well and I can see how that was happening indeed, everything makes sense now, I tested the latest changes and I can confirm it's working the same as was with lsp4j, really nice debugging and explanation! 🎉

I can imagine a few ways to fix this extra delay though. We could create a separate pool for the process-after-changes requests, so they only block each other. Or, perhaps, we could change process-after-changes to use something besides the sleep-in-a-loop pattern, so that it doesn't consume a thread.

Sounds great, it seems process-after-changes current implementation could be improved indeed, sounds like a good high priority for a future release.
I will review both PRs, thank you very much for the huge help on this!

That's great @ericdallo! This PR needed one small change to restore some tracing, which I just pushed. The clojure-lsp PR will need a bit more work. It'll have to be pinned to a release of lsp4clj, and I'll need to update the integration test client.

@ericdallo merged. I have to sign off for the night, so no rush on making a release.

Promesa rules! Let me know when/if I can test a binary locally and where I can get it.


Great start on the design!

I see the user stories and use case sketches, but don't forget to define the components including inputs and outputs and their data types, etc.

A rough sketch for 3 components has been added to the design specification doc, alongside a project plan timeline. We'll continue to iterate on these items in the coming week – thanks!


[dv] Remove duplicate lowrisc:constants:top_pkg

The core file and SV package were copied in here, which breaks the
OpenTitan build. The constants file is provided there too, but a
recent builds will pick up this one here. This is incorrect.
As the core file seems to be unused anyways, remove it from here along
with the package.
Added the, as far as I can see, only used constant here for
simplicity, alternatively it is an option to properly depend on the
other core.
Not tested because of tool availability.

Can we do this a different way? Add a vendoring rule on the import into OpenTitan that throws away these files (and possibly a much bigger subtree?)
In the reasonably near future, I hope that this code (which was copied from OpenTitan) will be vendored properly. In which case, it will be in a vendor subdirectory in Ibex, which will be easy to exclude when pulling things in in the other direction.
See issue #840 for me grumbling and https://github.com/lowRISC/opentitan/pull/2141 for the work on the OpenTitan side needed for this to happen. Modulo stalled reviews, I'd hope this will be sorted in the next week.

I guess we can close this one; OpenTitan doesn't vendor this file in any more, so there's only one copy around in OT.


Use host-environment if available to look up zone

Description
This change updates the vpcinfo library to get the current AZ from /etc/host-environment if the latter file is available. We need this for onebox deployments because we're blocking container access to the ec2 metadata endpoints in onebox cells.

That's a good idea. I like the idea of totally removing the need for the metadata.

Actually we still need to fallback on the ec2 metadata. I'm planning to use this to instrument segmentio/stats and since many of our services are still running in ecs/bridge the IP will not be in the subnets.

Yes, but in these environments we whitelist the endpoint for accessing availability zone via EC2 metadata, so we should have both models covered.

Totally

Took a quick stab at it : https://github.com/segmentio/vpcinfo/pull/4. Just an example. Feel free to discard if that's not what you are thinking about :)

@achille-roussel @Pryz any more feedback on this change? I think I addressed all of your suggestions. Thanks!


[pt] Deep learning, Linear Algebra

Thanks Gabriel for your awesome work! Now, let's wait for reviewers before merge.

Hi @leportella can you please help me reviewing the portuguese translation of this file? I am not 100% sure about it. Thanks.

Hi @gabriel19913 of course! No problem :)

@gabriel19913 I made some comments but feel free to discuss them. Some things I added a discussion because I used different terms on the other translation I did. I think it would be better for us to define some things so we can have a pattern.
Another thing, you should add the percentage you translated on README and your name in the file of contributors. :)

Thanks for your help @leportella. I reviewed the file as you indicated. I would be grateful if could also review the refresher-linear-algebra.md file when you have time. Thanks for your support.

@shervinea this seems good to go! :)

There is one more thing -- our first iteration showed that we needed a few more fields in the Linear Algebra refresher. Could you please also take a look at the [new entries]
@shervinea I just did it!

@leportella Could you please review my Linear Algebra Refresher translation?
Thanks!

@leportella Could you please review my Linear Algebra Refresher translation?
Thanks!
https://github.com/shervinea/cheatsheet-translation/blob/473b3ef85a92bdb3e62df476927d870a21926638/pt/refresher-linear-algebra.md

Thank you both @leportella @gabriel19913, great to see your dedication!
After hearing back from @leportella regarding the last part of the Linear Algebra refresher, we will move forward with the merge.

@gabriel19913 just two small things and we're good to go!

@leportella I made the first correction. But I yet have a doubt in the second one.

@shervinea I think now it's ready!

Thanks @shervinea.
Thank you @leportella for the review :)


codec2: 0.9.2 -> 1.0.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/codec2/versions.
meta.description for codec2 is: "Speech codec designed for communications quality speech at low data rates"
meta.homepage for codec2 is: "http://www.rowetel.com/blog/?page_id=452"
meta.changelog for codec2 is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.0.0 with grep in /nix/store/1dld3y22drz4cy1nfhb6fmwxxwvsbn9d-codec2-1.0.0

found 1.0.0 in filename of file in /nix/store/1dld3y22drz4cy1nfhb6fmwxxwvsbn9d-codec2-1.0.0

directory tree listing: https://gist.github.com/39b92be72caa4f677c90d8bc00009dc9

du listing: https://gist.github.com/97663eb6b239ab967cc12f653b557d11

Rebuild report (if merged into master) (click to expand)

96 total rebuild path(s)

26 package rebuild(s)

26 x86_64-linux rebuild(s)
26 i686-linux rebuild(s)
18 x86_64-darwin rebuild(s)
26 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
codec2
gnss-sdr
gnuradio
gnuradio3_7
gnuradio3_7Minimal
gnuradio3_7Packages.ais
gnuradio3_7Packages.gnuradio
gnuradio3_7Packages.gsm
gnuradio3_7Packages.limesdr
gnuradio3_7Packages.nacl
gnuradio3_7Packages.osmosdr
gnuradio3_7Packages.rds
gnuradio3_8
gnuradio3_8Minimal
gnuradio3_8Packages.ais
gnuradio3_8Packages.gnuradio
gnuradio3_8Packages.limesdr
gnuradio3_8Packages.osmosdr
gnuradio3_8Packages.rds
gnuradioMinimal
gnuradioPackages.gnuradio
gqrx
haskellPackages.bindings-codec2
inspectrum
qradiolink
sdrangel

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/1dld3y22drz4cy1nfhb6fmwxxwvsbn9d-codec2-1.0.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A codec2 https://github.com/r-ryantm/nixpkgs/archive/35dc1fc50326bda37d156b926824ae54421ae547.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/1dld3y22drz4cy1nfhb6fmwxxwvsbn9d-codec2-1.0.0
ls -la /nix/store/1dld3y22drz4cy1nfhb6fmwxxwvsbn9d-codec2-1.0.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review took longer than 45m and timed out

Maintainer pings
cc @markuskowa for testing.

Result of nixpkgs-review pr 135016 at 35dc1fc5 run on aarch64-linux 1

8 packages marked as broken and skipped:

gnuradio3_7
gnuradio3_7Packages.ais
gnuradio3_7Packages.gnuradio
gnuradio3_7Packages.gsm
gnuradio3_7Packages.limesdr
gnuradio3_7Packages.nacl
gnuradio3_7Packages.osmosdr
gnuradio3_7Packages.rds

14 packages skipped due to time constraints:

gnss-sdr
gnuradio3_7Minimal
gnuradio3_8
gnuradio3_8Minimal
gnuradio3_8Packages.ais
gnuradio3_8Packages.gnuradio
gnuradio3_8Packages.limesdr
gnuradio3_8Packages.osmosdr
gnuradio3_8Packages.rds
gnuradioMinimal
...

4 packages built successfully:

codec2
gnuradio
gnuradioPackages.gnuradio
haskellPackages.bindings-codec2


Username does not default to Wercker

In the slack notification the username does not default to Wercker. It looks like environment variable WERCKER_PRETTY_SLACK_NOTIFY_USERNAME is not being defined in script/run, but I am not exactly sure if that is the issue

@drewfranklin Thank you for reporting.
Could you show me your wercker.yml ? I might be able to help you.

For sure
box: zdfs/docker-suit build:   steps:     - npm-install     - script:         name: create empty 'public' and 'deploy' directories         code: |-           mkdir 'public'           mkdir 'deploy'     - grunt:         tasks: predeploy     - grunt:         tasks: deploy     - script:         name: copy documentation for deployment         code: |-           cp --recursive deploy/* "$WERCKER_OUTPUT_DIR"     - script:         name: echo nodejs information         code: |           echo "node version $(node -v) running"           echo "npm version $(npm -v) running"   after-steps:     - wantedly/pretty-slack-notify:         webhook_url: $SLACK_WEBHOOK_URL         channel: suit         notify_on: "failed" deploy:   steps:     - duleorlovic/ftp-deploy:         destination: ftp://$HOSTNAME/$FTP_TARGET         username: $FTP_USERNAME         password: $FTP_PASSWORD   after-steps:     - wantedly/pretty-slack-notify:         webhook_url: $SLACK_WEBHOOK_URL         channel: suit deploy-release:   steps:     - duleorlovic/ftp-deploy:         destination: ftp://$HOSTNAME/$WERCKER_GIT_BRANCH         username: $FTP_USERNAME         password: $FTP_PASSWORD   after-steps:     - wantedly/pretty-slack-notify:         webhook_url: $SLACK_WEBHOOK_URL         channel: suit

@drewfranklin Thank you for sharing it to me.
At first, you might be able to work around by specifying username option like this:
        - wantedly/pretty-slack-notify:
            webhook_url: $SLACK_WEBHOOK_URL
            channel: suit
            username: Wercker

To find the root cause, could you show me  "wantedly/pretty-slack-notify" step's log on wercker?

Awesome thanks for the quick fix
Here is my log

@drewfranklin Thanks! I could find the root cause from your log ❗
This is a bug that empty username is set as default. And this bug will be fixed in next release 😃
So please use username option to workaround until next version released.

@drewfranklin step-pretty-slack-notify v0.3.4 including the fix of this issue was just released. Please try it.

Yep it worked thanks so much everyone!


Rejected by Apple 4 times while employed at Harvard

Apple interviewed me 4 times for 3 positions, all while I was employed at Harvard University. I even had to talk through designing the "iStove" for Steve Jobs and explain how Google Maps worked using a whiteboard. They never hired me and I left Harvard to work for myself a year later.
Patrick Haney, @notasausage

Great story! Thanks so much for sharing it!


Use error chain for deriving errors

Error chain is a very common errors handling crate that has a good ecosystem going for it. This library could benefit from being a friendly actor in that ecosystem

Consider the new crate failure too.

We talked about error handling crates in #242 and concluded on not using an error helper lib. I'll therefore close this now.


Port tests for JsonOutputFormatter

Talk to @kichalla as he is fixing the issue with calling the formatter multiple times. #1836


Print errors  to console when exporting

Fixes #1757 (at least I hope so).
Also exit and print a list of valid export platforms when
the supplied platform was not found.

Addresses part of #1964 too, the rest will be wiki improvement.

@est31 changed the title from Print errors when exporting to console to Print errors to console when exporting an hour ago

Owww... and I was so sure you were working on an ASCII export template for roguelikes :D


Update index.html.erb

add on of exchange secureshift

This PR is incomplete and doesn't include the graphic required.

Hello i created the new pull request with  include the graphic required.
Kindly check.

Sorry we are unable to add this site at this time.

Thanks for responding is there any issues over our exchange let us know
On Sat, 16 Nov 2024 at 12:21 PM, Josh Ellithorpe @.***>
wrote:

Sorry we are unable to add this site at this time.
—
Reply to this email directly, view it on GitHub
https://github.com/zquestz/bitcoincash/pull/149#issuecomment-2480454268,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BEAPDZ7EA7B3WTJV56STUIT2A3TPHAVCNFSM6AAAAABLR3SBWGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBQGQ2TIMRWHA
.
You are receiving this because you authored the thread.Message ID:
@.***>


Release Version 2.0.0 (RC1)

This is a component issue for release 2.0.0 (RC1).
Coming from https://github.com/opensearch-project/opensearch-build/issues/1624, please refer to the dates in that post.
Please also follow the following checklist.
How to use this component issue

This Component Issue
This component issue captures the state of the OpenSearch release, on component/plugin level, its assignee is responsible for driving the release of the component.  Please contact them or @mention them on this issue for help.
Release Steps
There are several steps to the release process, components that are behind present risk to the release.  Component owners resolve tasks on this ticket to communicate with the overall release owner.
Steps have completion dates for coordinating efforts between the components of a release; components can start as soon as they are ready far in advance of a future release.
You can find all the corresponding dates of each step in the release issue above.
What should I do if my plugin isn't making any changes?
If including changes in this release, increment the version on 2.0 branch to 2.0.0 for Min/Core, and <IP_ADDRESS> for components. Otherwise, keep the version number unchanged for both.

You can find all the date in above issue
Preparation

[x] Assign this issue to a release owner.
[x] Finalize scope and feature set and update the Public Roadmap.
[x] All the tasks in this issue have been reviewed by the release owner.
[x] Create, update, triage and label all features and issues targeted for this release with v2.0.0.

CI/CD

[x] All code changes for 2.0.0 are complete.
[ ] Ensure working and passing CI.
[x] Re(add) this repo to the (if not exist) opensearch input manifest, opensearch-dashboards input manifest.

Pre-Release

[x] Update your branch in the opensearch input manifest, opensearch-dashboards input manifest.
[x] Confirm that all changes for 2.0.0 have been merged.
[x] Complete integration tests, and update results in the comment, example.
[x] Find/fix bugs using latest tarball and docker image provided in meta issue.
[x] Completed release candidate testing build #TBD.
[x] All intermittent test failures have issues filed.

Release

[x] Complete documentation.
[x] Gather, review and publish release notes.
[ ] Verify all issued labeled for this release are closed or labelled for the next release.

Post Release

[ ] Create a release tag.
[ ] Suggest improvements to this template.
[ ] Conduct a retrospect, and publish its results.

Release Notes PR: https://github.com/opensearch-project/notifications/pull/431

this has been merged, closing the issue


(#735) Fix sensu-server-enterprise Vagrant VM

Without this patch the sensu-enterprise server is quickly crashing with a JVM
out of memory error when started inside the sensu-server-enterprise VM.
This patch addresses the problem by bumping up the allocated RAM for the VM
from 512m to 768m while also bringing down the JVM heap size from 2GB to 256m.
The API has been tested with the following commands, with no other VM's
running:
vagrant up sensu-server-enterprise
curl -s http://admin:secret@<IP_ADDRESS>:4567/clients \
  | jq -r 'map(.name | split(".") | .[0]) | sort | .[]'

Resolves #735

Released in v2.22.0


changes needed to update router from 0.9.x api to 0.10.x

this all seems to work on my projects, just need to update docs to move config from app.view into the args like:
Router([['/',
hello
]])

Thanks @andyrj. Fixed things with #12. 🙇


[Bug]: Failed to revoke privileges to add for IMPORTED PRIVILEGES on SNOWFLAKE database

Terraform CLI Version
1.3.8
Terraform Provider Version
0.89
Terraform Configuration
locals {
  SNOWFLAKE_DATABASE_ACCESS_ROLES = [
    "SNOWFLAKE_INSPECTION"
  ]
}

# grant IMPORTED PRIVILEGES on SNOWFLAKE application
resource "snowflake_grant_privileges_to_account_role" "this" {
  for_each          = toset(local.SNOWFLAKE_DATABASE_ACCESS_ROLES)
  account_role_name = each.key
  privileges        = ["IMPORTED PRIVILEGES"]
  on_account_object {
    object_type = "DATABASE"
    object_name = "SNOWFLAKE"
  }
  with_grant_option = false
}

Category
category:resource
Object type(s)
No response
Expected Behavior
Use snowflake_grant_privileges_to_account_role to grant IMPORTED PRIVILEGES on the SNOWFLAKE database to some roles with with_grant_option = false.
Actual Behavior
It gives an error when revoking the privilege.
Error: Failed to revoke privileges to add
│
│   with module.custom.snowflake_grant_privileges_to_account_role.this["SNOWFLAKE_INSPECTION"],
│   on ../../../../modules/snowflake/custom/snowflake_database_usage.tf line 17, in resource "snowflake_grant_privileges_to_account_role" "this":
│   17: resource "snowflake_grant_privileges_to_account_role" "this" {
│
│ Id: "SNOWFLAKE_INSPECTION"|false|false|IMPORTED PRIVILEGES|OnAccountObject|DATABASE|"SNOWFLAKE"
│ Privileges to add: [IMPORTED PRIVILEGES]
│ Error: 001003 (42000): SQL compilation error:
│ syntax error line 1 at position 24 unexpected 'IMPORTED'.

The SQL produced indeed is not valid, it produces:
REVOKE GRANT OPTION FOR IMPORTED PRIVILEGES ON DATABASE "SNOWFLAKE" FROM ROLE "SNOWFLAKE_INSPECTION"
instead what is correct is
REVOKE IMPORTED PRIVILEGES ON DATABASE "SNOWFLAKE" FROM ROLE "SNOWFLAKE_INSPECTION"
Steps to Reproduce
run terraform apply on this, replacing the "SNOWFLAKE_INSPECTION" role with one that you have on your Snowflake account:
locals {
  SNOWFLAKE_DATABASE_ACCESS_ROLES = [
    "SNOWFLAKE_INSPECTION"
  ]
}

resource "snowflake_grant_privileges_to_account_role" "this" {
  for_each          = toset(local.SNOWFLAKE_DATABASE_ACCESS_ROLES)
  account_role_name = each.key
  privileges        = ["IMPORTED PRIVILEGES"]
  on_account_object {
    object_type = "DATABASE"
    object_name = "SNOWFLAKE"
  }
  with_grant_option = false
}

How much impact is this issue causing?
Low
Logs
No response
Additional Information
No response
Would you like to implement a fix?

[ ] Yeah, I'll take it 😎

I'm wondering whether you can give grant_options for IMPORTED PRIVILEGES?

It seems like the concept of grant options is not relevant for IMPORTED PRIVILEGES ?
Just in Snowflake, if I run
GRANT IMPORTED PRIVILEGES ON DATABASE "SNOWFLAKE" TO ROLE "MY_ROLE" WITH GRANT OPTION;
It gives me
Syntax error: unexpected 'WITH'. (line 6)
While
GRANT IMPORTED PRIVILEGES ON DATABASE "SNOWFLAKE" TO ROLE "MY_ROLE" ;
works fine.
On another (non-shared) database, that syntax does actually work and sets the grant_option to true.

Hey @RobbertDM 👋
I believe the configuration should work with object_type = "APPLICATION" because Snowflake for show grants will return it as APPLICATION and not DATABASE. Regarding grant options, it's documented here(scroll to the WITH GRANT OPTION in the optional parameters section) and it says it's not possible to run with IMPORTED PRIVILEGES.

Thanks for the quick answer @sfc-gh-jcieslak
However, then it gives me
│ Error: expected on_account_object.0.object_type to be one of ["USER" "RESOURCE MONITOR" "WAREHOUSE" "COMPUTE POOL" "DATABASE" "INTEGRATION" "FAILOVER GROUP" "REPLICATION GROUP" "EXTERNAL VOLUME"], got APPLICATION
│
│   with module.custom.snowflake_grant_privileges_to_account_role.this,
│   on ../../../../modules/snowflake/custom/snowflake_database_usage.tf line 22, in resource "snowflake_grant_privileges_to_account_role" "this":
│   22:     object_type = "APPLICATION"

I am on Snowflake terraform provider 0.89, is this introduced later?
Also, we might want to update the main docs then, they mention object_type = DATABASE:
https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/docs/resources/grant_privileges_to_account_role.md?plain=1#L99

Possibly relevant comment in the code:
https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/319ddc3df2f0a73c1f6258632de0e42c04532551/pkg/resources/grant_privileges_to_account_role.go#L812

Ah, I think I found the one causing trouble:
https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/319ddc3df2f0a73c1f6258632de0e42c04532551/pkg/resources/grant_privileges_to_account_role.go#L529-L532
and specifically, line 531 sets GrantOptionFor to true.
As you mentioned before, IMPORTED PRIVILEGES does not have grant options.
So I think updates will always fail.

Yeah, so my bad. The resource should be working with object_type = "DATABASE", but it shouldn't have grant option enabled. I tested the following config with v0.89.0 and it worked and was created as well as destroyed without any errors:
resource "snowflake_grant_privileges_to_account_role" "test" {
  account_role_name = "TEST_ROLE"
  privileges = [ "IMPORTED PRIVILEGES" ]
  on_account_object {
    object_type = "DATABASE"
    object_name = "SNOWFLAKE"
  }
  with_grant_option = false
}

It ran REVOKE IMPORTED PRIVILEGES ON DATABASE "SNOWFLAKE" FROM ROLE "TEST_ROLE"

Hey @RobbertDM 👋
Closing due to long inactivity and because similar issues (like this one) were already handled and confirmed the solution works in newer provider versions.

Actually this is not yet solved.
We are encountering the same issue and the provider version is 0.92.0
╷
│ Error: Failed to revoke privileges to add
│
│   with module.snowflake.snowflake_grant_privileges_to_account_role.grant_on_snowflake_database_to_datadog,
│   on modules/snowflake/grant_privileges_to_account_role.tf line 9, in resource "snowflake_grant_privileges_to_account_role" "grant_on_snowflake_database_to_datadog":
│    9: resource "snowflake_grant_privileges_to_account_role" "grant_on_snowflake_database_to_datadog" {
│
│ Id: "PROD_DATADOG"|false|false|IMPORTED
│ PRIVILEGES|OnAccountObject|DATABASE|"SNOWFLAKE"
│ Privileges to add: [IMPORTED PRIVILEGES]
│ Error: 001003 (42000): SQL compilation error:
│ syntax error line 1 at position 24 unexpected 'IMPORTED'.

This is our code definition:
resource "snowflake_grant_privileges_to_account_role" "grant_on_snowflake_database_to_datadog" {
  account_role_name = snowflake_role.datadog.name
  privileges        = ["IMPORTED PRIVILEGES"]
  on_account_object {
    object_type = "DATABASE"
    object_name = "SNOWFLAKE"
  }
  with_grant_option = false
}

The code is applied successfully the first time, but then every time terraform runs again, the issue presents.

Interesting, I'll reproduce the issue and get back to you.

I started seeing this issue in 0.92.0 as well, then upgraded to 0.95.0, where it was still happening.
I ended up manually running the revoke/grant statements for imported privileges which seems to have resolved it.

Hey 👋
I'm sorry, but I couldn't reproduce this error in any of the Terraform Provider versions. Maybe that's more connected to Snowflake than the provider itself. Please run the terraform apply with the TF_LOG=DEBUG environment variable set for more logging and post it here so I can check what SQLs are run (please be careful with sensitive data).

Here is the query being run that fails. My terraform is identical to the above.
REVOKE GRANT OPTION FOR IMPORTED PRIVILEGES ON DATABASE "DBNAME" FROM ROLE "DBNAME_READONLY"

I started seeing this issue in 0.92.0 as well, then upgraded to 0.95.0, where it was still happening.
I ended up manually running the revoke/grant statements for imported privileges which seems to have resolved it.

what statements worked?

Hi @martingehrke 👋
I assume this happens during terraform destroy. I just tested @sfc-gh-jcieslak's configuration, and it works correctly on my side (apply, plan, destroy). What error do you get? Could you share logs with TF_LOG=DEBUG?


Rapid prototyping templates are outdated

📚 Documentation
The Rapid prototyping templates page is highly outdated. There are only two examples and both of them use API from < PL 1.2. For example Trainer(automatic_optimization=False). They are hosted in Colab and therefore we can't update them automatically.

Does this section belong into the side menu?
How do we update the Colab notebook?

cc @borda

we can update and add them to pl_examples/templates and link it with colab/github?


Documentation about query_param auth bundle configuration

https://travis-ci.org/php-http/documentation/builds/398139588#L689
How do you use anchor with this format? :thinking:

i changed to an anchor and merged in #239. thanks for the param contribution @Soullivaneuh . even though its generally bad practice, as an api consumer you sometimes don't have the choice, so its good to have this.


Implement x86 simd rounding instructions

Implement f32x4 and f64x2 ceil, floor, trunc, nearest.

Rebased the patch to main branch.

Since the code is in the main branch now, I cannot land the patch alone anymore.

Could you rebase the patch? That should enable ci testing.


first pass at descriptive authenticate error?

Not certain if this is the best way to handle it, but a first pass to start discussion. regarding issue #110
thoughts?

looks like I just should just use the server and client - sorry for the spam!


Transaction component

Description
Updated the Transaction and TransactionList components to have some basic styles, alongside with their Storybook counterparts.
Issues fixed
#38 and #39
Checklist

[x] npm test returns a single error on the TransactionList container, but it was like that when I got here.

Please rebase onto master, then 👍


Chromedriver version 114.0.5735.133

Shouldn't the latest-patch-versions-per-build-with-downloads.json be used for version 115 and above, as well as 114.0.5735.133?
The file "https://chromedriver.storage.googleapis.com/114.0.5735.133/chromedriver_〇〇.zip" does not exist!

Hi @nao-riku,
unfortunately, the Chromedriver for major version 114 is nowhere to be found. If you have a closer look at the mentioned latest-patch-versions-per-build-with-downloads.json file, you will notice that for 114.x releases only Chrome but not Chromedriver downloads are listed:

Whereas for 115.x both are available:

Because the download is neither available on the old location nor the new, I decided to use the new JSON endpoints starting with version 115 as it is mentioned here:

Starting with M115 the latest Chrome + ChromeDriver releases per release channel (Stable, Beta, Dev, Canary) are available at the Chrome for Testing availability dashboard. For automated version downloading one can use the convenient JSON endpoints.

I have no choice but to update to version 115......
Thank you so much!


Backup App Settings

Describe your suggested feature
Enabling the option to backup the settings of the app (like the preferences, reading mode, appearance, etc.) would be extremely useful in case of a fresh installation.
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I will fill out all of the requested information in this form.

This has been fixed/added in the preview
https://github.com/aniyomiorg/aniyomi-preview
Steps to shift to this build:-

Create a backup from "Backup and Restore"
Download the preview apk and install it
Restore the backup you created before in the same tab "Backup and Restore"


improve Device Tree file type support

Add indent definitions for .dts and .dtsi files, because the default autoindent behaviour wrongly unindents properties starting with #, e.g. #address-cells and #size-cells, or labels ending in :.
cc @zonque: Improve syntax highlighting for .dts and .dtsi files to include support for label-relative path references, which were introduced in dtc 1.7. Currently this syntax is matched by the dtsKeyword element, so make that more specific to only match directives like /dtc-v1/, /delete-node/ and the like. Screenshots below show before and after states, with an additional hi link dtsReference Identifier to distinguish them from other similarly-colored syntax elements.

Before:

After:

Where would I add a test for indent files?

Ahh, I found runtime/indent/testdir/README.txt, that explains it!

Ahh good thing you told me to write tests, I actually found an error… 😅 Also added a @ in dtsReference to match addresses in node names, like in indent/testdir/dts.in.

I'll leave the syntax file changes to  @zonque
I'll include the indent file and test.

Thanks, I'll include it then.  I'll update the date in the header.


Achimcc/arkworks integration remove affine hostcalls

We remove the host calls for Affine mul's. Instead, we convert Affine mul's to Projective points first in ark-subtrate and call then into the host call's for Projective mul's.

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2713704

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2713754

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-check-benches
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2713755


GE: wait for link to be present

@metaodi I think the last change was not really working well. This one seems to work at least locally.

@maekke thank you! I had troubles to setup selenium locally so I was never able to test this properly.


requireSpacesInAnonymousFunctionExpression breaks ES6 classes

I use the following configuration:
"requireSpacesInAnonymousFunctionExpression": {
	"beforeOpeningRoundBrace": true,
	"beforeOpeningCurlyBrace": true
}

And it breaks in a simple ES6 class on each declared method. Saying for example (in verbose mode):
requireSpacesInAnonymousFunctionExpression: Missing space before opening round brace at lib/MyWriter.js :
     7 |class MyWriter extends Transform {
     8 |
     9 | constructor() {
---------------------^
    10 |  super({ writableObjectMode: true });
    11 |

The ES6 code:
class MyWriter extends Transform {
  constructor() {
    super({ writableObjectMode: true });
  }
}

These are ES6 class methods, I have "esnext": true set, so I don't expect my methods to be considered anonymous functions.
PS: If this is all because of Babel turning these methods into anonymously assigned prototype functions, sure it makes sense why this happens. But it's not obvious and while perhaps by spec these are anonymous functions assigned to the prototype, I think they deserve their own rule or perhaps some exception value.
PS2: Wow, even adding a space before the opening brace (ie: constructor () {) gives the same error. Mind blown.

I think they deserve their own rule or perhaps some exception value.

Yeah, it might be a good thing, would you like to create one? Should be pretty similar to requireSpacesInAnonymousFunctionExpression

PS2: Wow, even adding a space before the opening brace (ie: constructor () {) gives the same error. Mind blown.

Oh, god, No! There is so much blood!
...
Anyway, that is bug and that is a fix for it.

I think they deserve their own rule or perhaps some exception value.

https://github.com/jscs-dev/node-jscs/issues/1513 btw :-)

You work fast, awesome job :)

So we need to make the changes (and previous ones) for inNamedFunctionExpression and inFunction right

I just tried out 2.1.0, and the problem persists...
requireSpacesInAnonymousFunctionExpression: Missing space before opening round brace at lib/Foo.js :
     7 | }
     8 |
     9 | add(chunk) {
------------^

This fix was intended for the

PS2: Wow, even adding a space before the opening brace (ie: constructor () {) gives the same error. Mind blown.

issue, everything else is https://github.com/jscs-dev/node-jscs/issues/1513

btw, would you like to implement such value?

I'm currently not too familiar with the internals, Esprima, and I don't have much time. I'll live if I can't have this now and we put it on the backburner. But I don't think this issue should be closed, should it?

@markelog is saying the issue is in #1513 so follow that for the new option


Improve/fix packed data API (3.2)

Enhance directory API
Fix FileAccess::exists() not checking for PackedData being disabled
Fix moving to the parent directory (..)
Allow absolute paths in existence checks

NOTE: Separate PR submitted for master (#40748).

This code is generously donated by IMVU.

Thanks!


feat: how does stable diffusion work

Not only needing to read new articles but also correct the previous blogs.
https://huggingface.co/blog/stable_diffusion#how-does-stable-diffusion-work

It is necessary to finish the rest of the part, checking below https://huggingface.co/blog/stable_diffusion#writing-your-own-inference-pipeline

https://github.com/hololandscape/notebooks/commit/babefa2262f442d93115ea585e28d4b3a4278bb2


Switch workflows to not use intel channel.

[X] Have you provided a meaningful PR description?
Changes existing github workflows based on https://github.com/IntelPython/numba-dpex/issues/1480#issuecomment-2230025965

Fixes #1481

coverage: 86.608% (+0.1%) from 86.48%
when pulling 5cc320df03927415368920da7a6a223f0932500b on fix/github-workflows
into e80fdd07003280494bdc21122ee1712acaffd51e on main.

@oleksandr-pavlyk @diptorupd if we decide it is good to go with just dppy/label/dev and conda-forge dependency - we need to squash the PR. It's too many commits per small change.


Invisible tables rendered with blue lines in reader view on 6.0a1

Unexpected behavior:
NNW6 renders tables with a border thickness of 0 when it shouldn't.
More info:
There was a discussion about not rendering table borders with a thickness of 0 in the Slack (link to part of the conversation: https://netnewswire.slack.com/archives/CC4LQ2D8R/p1602196503109400). This change was successfully made in NNW 6.0 in the regular mode but it looks like it wasn't applied to the reader mode.
Images:
The first image shows the article without reader view, the latter with it enabled.

@momenabdelkarim Do you have the URL of this feed that you can give me?

@momenabdelkarim I can't recreate this if you don't give me a feed URL that you are seeing this bug on.

Sorry got busy. It's a URL private to me (created by "kill the newsletter") so I can't post it publicly, but I shared it with you over Slack. Direct link to the DM: https://netnewswire.slack.com/archives/D01CF17CV5J/p1602189288000200

Thanks for the links. They are www.kill-the-newsletter.com links for the curious.
When you use reader view to retrieve the newsletter from Kill The Newsletter, our Mercury reader service strips out the outer most table that specifies border=0. Kill The Newsletter is also using border-collapse to make the formatting of the tables used in newsletters look nicer. Because we don't get the styles or the border=0 from Mercury, we don't have any way of knowing that they intended to hide the borders.

I don’t think this is a thing we can do anything about, so I’m closing it. Reopen it if I’m wrong.


chore(main): release 2.0.1

:robot: I have created a release beep boop
2.0.1 (2024-12-26)
Bug Fixes

nil check file open (#14) (b5ee7cf)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/benlubas/neorg-interim-ls/releases/tag/v2.0.1 :sunflower:


Unregister watches on the parent scope

Several watches are registered on the parent scope in the datepicker.js. Those watches are going to be unregistered the moment the parent scope will be destroyed. Wouldn't it be wiser to unregister them when the directive's scope is being destroyed?
  angular.forEach(['minDate', 'maxDate'], function(key) {
    if ($attrs[key]) {
      $scope.$parent.$watch($attrs[key], function(value) {
        self[key] = value ? angular.isDate(value) ? dateParser.fromTimezone(new Date(value), ngModelOptions.timezone) : new Date(dateFilter(value, 'medium')) : null;
        self.refreshView();
      });
    } else {
      self[key] = datepickerConfig[key] ? dateParser.fromTimezone(new Date(datepickerConfig[key]), ngModelOptions.timezone) : null;
    }
  });

I was wondering about watchers on the parent throughout several components - they probably should be garbage collected on $destroy.
Should be an easy PR (or few PRs for the other components where this is happening) if you'd like to try your hand at it.

I will try to get to this tonight or tomorrow.

thanks!


Add support for Qwen 2 VL 2B.

With the release of Qwen2 VL 2B, I thought that it could be a good fit for the ColPali Engine for document retrieval since it is a small model and also provides support for controlling the maximum and minimum amount of vision tokens that are generated. This can be done by setting the min_pixels and max_pixels in the yml file.
I couldn't get a budget for the the GPU to train the model as these col like models require high VRAM. So if someone gets an opportunity to try training a complete model, it would be nice to see how it performs compared to the PaliGemma model. Given that Qwen is an Apache 2.0 license it will be great if it can perform comparable to PaliGemma model.
NOTE: This requires to install and build the transformer from source. pip install git+https://github.com/huggingface/transformers.

Awesome ! It was on my roadmap alongside idefics3 and phi3 but was particularly interested in this one as it has the controllable seq length. The llava-one vision is also based on Qwen2 and is released with a 0.5b checkpoint if I am not mistaken ?
I'll try to look into it on Thursday and see if I can debug and train it, thanks !

@ManuelFay I have also implemented phi3-vision-128k. But it was hard to integrate it with the rest of the codebase without changing too many things as there are a few details like the processor cannot handle batches (https://huggingface.co/microsoft/Phi-3-vision-128k-instruct/discussions/29). I did make a workaround for this by looping through the examples but found that the number of vision tokens are quite high (over 2000) and cannot be controlled so this results in very high VRAM requirement for a high batch size.
Let me know if you are interested in this. I will put some more effort in integrating it with the codebase. Shouldn't take very long.

Yeah I had started doing phi3 but there's a lot of tokens ! I have a few ideas to see if we can stack some of them together !
I'll probably open a new PR to integrate Qwen2 since we refactored a bit since your fork, but will use your work ! I'll probably have a few questions !

https://github.com/illuin-tech/colpali/pull/56
Here have a look !
I recoded everything without looking at your code too much, in order not to be biased in case there were abitrary  choices !
I'm curious into how you would deal with the resolution ?

Ok my branch works !
Closing this one, there were some crazy hard debugging to do to make all the final fixes ahah but we will merge once transformers updates with qwen2-vl support


Fix Parsing Response Data in Content App Command Delegate

Problem
FormatResponseData inside ContentAppCommandDelegate is missing the actual parsing of the response data.
Solution
Add back the parsing logic that was accidentally removed in previous PR #34895
Tested on Prime Video casting from Android and iOS. Commissioning and casting control were successful.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.tinnaliu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


powerdevil: hash mismatch

Describe the bug
Rebuidling the system on nixos unstable small fails because of powerdevil patch hash mismatch:
To Reproduce
Steps to reproduce the behavior:

Use Powerdevil
Set to nixos-unstable small
Rebuild

building '/nix/store/zh01731y5g39plzwfklr9p0cls64jgvi-unit-script-docker-prune-start.drv'...

trying https://invent.kde.org/plasma/powerdevil/-/commit/c7590f9065ec9547b7fabad77a548bbc0c693113.patch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  8903    0  8903    0     0  45891      0 --:--:-- --:--:-- --:--:-- 45891
building '/nix/store/anslprwnf3rhp6vwbaz1zl5zwrzjj7x7-set-environment.drv'...
hash mismatch in fixed-output derivation '/nix/store/cw5wy5s1xbjn5gsx89dgqz12xq0hgchp-c7590f9065ec9547b7fabad77a548bbc0c693113.patch':
  wanted: sha256:0vj70mhx6qhvbh4vn9qk9ir5w4s2m76hw2lsxmh3ibgsydz4yilz
  got:    sha256:077whhi0jrb3bajx357k7n66hv7nchis8jix0nfc1zjvi9fm6pi2
cannot build derivation '/nix/store/2fvpxgsj9wq03p3y9ia2wix8hh52cqpx-powerdevil-5.18.5.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/qid6assapg1qdi06dvpd4s7hp9qkhn8x-system-path.drv': 1 dependencies couldn't be built

Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

system: "x86_64-linux"
host os: Linux 5.4.60, NixOS, 20.09pre239987.27ff76db67e (Nightingale)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3.7
channels(hyper): "nixos-19.09pre185402.5eac339829b"
channels(root): "nixos-20.09pre241861.1965a241fc2"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

@ttuegel caused by 24ebfb1e021b60ffa7ccb9970e5d9f0f664faa10

Fixed in c5dcb9682ebb7b586601beb65267a9241df156f8 - not yet in nixos-unstable-small.

…and it's in nixos-unstable-small.


Cairo problems and alternatives

Besides this issue (https://github.com/igagis/svgren/issues/51) I bumped into crash because of absence of thread-safe in cairo. I wanted to render some svg assets asynchronously and failed.
Skia (https://skia.org/) looks like a good alternative to cairo library. At least they state that it is thread-safe and has better performance...
Any chances to taste it?

I suppose you tried to call svgren::render() from two different threads? I.e. render two different SVGs in parallel?

According to this SO thread  the cairo should be reentrant...

Transition to SKIA is effort-wise expensive... so I'd like to avoid that.

By the way, can you share the images you tried to render in parallel? I could try to make a test app which does parallel rendering and try to analysi the problem, maybe it is easily fixable...

I cannot share them for public access, so will be ok to send them for you by email?

Ok, I received the files, thanks. One more question: which OS did you run? Windows/Android/Somethingelse?

I tried on android and osx and got crashes on both platforms in multithread rendering case

Locking of entire render function helps but it is quite expensive...
It would be nice if you could enter lock somewhere inside lib more precisely.

Nope, I'm not sure
Last available stacktrace:
lib/arm/libsvgren.so (fast_composite_over_8888_8888+432)
lib/arm/libsvgren.so (pixman_image_composite32+1432)
lib/arm/libsvgren.so (_inplace_spans+648)
lib/arm/libsvgren.so (blit_a8+442)
lib/arm/libsvgren.so (glitter_scan_converter_render+552)
lib/arm/libsvgren.so (_cairo_tor_scan_converter_generate+104)
lib/arm/libsvgren.so (composite_polygon+722)
lib/arm/libsvgren.so (clip_and_composite_polygon+442)
lib/arm/libsvgren.so (_cairo_spans_compositor_fill+600)
lib/arm/libsvgren.so (_cairo_compositor_fill+162)
lib/arm/libsvgren.so (_cairo_image_surface_fill+54)
lib/arm/libsvgren.so (_cairo_surface_fill+170)
lib/arm/libsvgren.so (_cairo_gstate_fill+548)
lib/arm/libsvgren.so (_cairo_default_context_fill_preserve+26)
lib/arm/libsvgren.so (cairo_fill_preserve+28)
lib/arm/libsvgren.so (_ZN6svgren8Renderer18renderCurrentShapeEb+380)
lib/arm/libsvgren.so (_ZN6svgren8Renderer5visitERKN6svgdom11PathElementE+3046)
lib/arm/libsvgren.so (_ZNK6svgdom11PathElement6acceptERNS_12ConstVisitorE+36)
lib/arm/libsvgren.so (_ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE+388)
lib/arm/libsvgren.so (_ZN6svgren8Renderer5visitERKN6svgdom8GElementE+132)
lib/arm/libsvgren.so (_ZNK6svgdom8GElement6acceptERNS_12ConstVisitorE+36)
lib/arm/libsvgren.so (_ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE+388)
lib/arm/libsvgren.so (_ZN6svgren8Renderer5visitERKN6svgdom8GElementE+132)
lib/arm/libsvgren.so (_ZNK6svgdom8GElement6acceptERNS_12ConstVisitorE+36)
lib/arm/libsvgren.so (_ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE+388)
lib/arm/libsvgren.so (_ZN6svgren8Renderer5visitERKN6svgdom8GElementE+132)
lib/arm/libsvgren.so (_ZNK6svgdom8GElement6acceptERNS_12ConstVisitorE+36)
lib/arm/libsvgren.so (_ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE+388)
lib/arm/libsvgren.so (_ZN6svgren8Renderer5visitERKN6svgdom8GElementE+132)
lib/arm/libsvgren.so (_ZNK6svgdom8GElement6acceptERNS_12ConstVisitorE+36)
lib/arm/libsvgren.so (_ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE+388)
lib/arm/libsvgren.so (_ZN6svgren8Renderer5visitERKN6svgdom8GElementE+132)
lib/arm/libsvgren.so (_ZNK6svgdom8GElement6acceptERNS_12ConstVisitorE+36)
lib/arm/libsvgren.so (_ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE+388)
lib/arm/libsvgren.so (_ZN6svgren8Renderer5visitERKN6svgdom8GElementE+132)
lib/arm/libsvgren.so (_ZNK6svgdom8GElement6acceptERNS_12ConstVisitorE+36)
lib/arm/libsvgren.so (_ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE+388)
lib/arm/libsvgren.so (ZN6svgren8Renderer16renderSvgElementERKN6svgdom9ContainerERKNS1_9StyleableERKNS1_9ViewBoxedERKNS1_13AspectRatioedERKNS1_6LengthESG_SG_SG+406)
lib/arm/libsvgren.so (_ZN6svgren8Renderer5visitERKN6svgdom10SvgElementE+50)
lib/arm/libsvgren.so (_ZNK6svgdom10SvgElement6acceptERNS_12ConstVisitorE+36)
lib/arm/libsvgren.so (Render+346)

Ok. I reproduced the crash on linux and it seems because of that cairo_debug_reset_static_data(). I removed call to cairo_debug_reset_static_data() in version 0.4.52. Please try if it fixes your crash.
The version should be release soon:
https://travis-ci.org/igagis/svgren/builds/371127896
https://ci.appveyor.com/project/igagis/svgren/build/master-511

No, it doesn't help. Still crashes.
Native tracestack:
...
2   libsvgren.dylib                     0x0000000118ef445d fast_composite_over_8888_8888 + 128
3   libsvgren.dylib                     0x0000000118ee712f pixman_image_composite32 + 999
4   libsvgren.dylib                     0x0000000118f5f8a6 _inplace_spans + 272
5   libsvgren.dylib                     0x0000000118f34470 _cairo_tor_scan_converter_generate + 3338
6   libsvgren.dylib                     0x0000000118f3dac5 composite_polygon + 328
7   libsvgren.dylib                     0x0000000118f3d830 clip_and_composite_polygon + 343
8   libsvgren.dylib                     0x0000000118f3c9a6 _cairo_spans_compositor_fill + 508
9   libsvgren.dylib                     0x0000000118f36b71 _cairo_compositor_fill + 110
10  libsvgren.dylib                     0x0000000118f38d2b _cairo_image_surface_fill + 41
11  libsvgren.dylib                     0x0000000118f64edc _cairo_surface_fill + 174
12  libsvgren.dylib                     0x0000000118f43aff _cairo_gstate_fill + 377
13  libsvgren.dylib                     0x0000000118f3fc4d cairo_fill_preserve + 28
14  libsvgren.dylib                     0x0000000118ecc3d7 _ZN6svgren8Renderer18renderCurrentShapeEb + 539
15  libsvgren.dylib                     0x0000000118ecd9e0 _ZN6svgren8Renderer5visitERKN6svgdom11PathElementE + 2578
16  libsvgren.dylib                     0x0000000118f853fb _ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE + 35
17  libsvgren.dylib                     0x0000000118eccb64 _ZN6svgren8Renderer5visitERKN6svgdom8GElementE + 162
18  libsvgren.dylib                     0x0000000118f853fb _ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE + 35
19  libsvgren.dylib                     0x0000000118eccb64 _ZN6svgren8Renderer5visitERKN6svgdom8GElementE + 162
20  libsvgren.dylib                     0x0000000118f853fb _ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE + 35
21  libsvgren.dylib                     0x0000000118eccb64 _ZN6svgren8Renderer5visitERKN6svgdom8GElementE + 162
22  libsvgren.dylib                     0x0000000118f853fb _ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE + 35
23  libsvgren.dylib                     0x0000000118eccb64 _ZN6svgren8Renderer5visitERKN6svgdom8GElementE + 162
24  libsvgren.dylib                     0x0000000118f853fb _ZN6svgdom12ConstVisitor11relayAcceptERKNS_9ContainerE + 35
25  libsvgren.dylib                     0x0000000118ecc851 ZN6svgren8Renderer16renderSvgElementERKN6svgdom9ContainerERKNS1_9StyleableERKNS1_9ViewBoxedERKNS1_13AspectRatioedERKNS1_6LengthESG_SG_SG + 543
26  libsvgren.dylib                     0x0000000118eccf77 _ZN6svgren8Renderer5visitERKN6svgdom10SvgElementE + 55
27  libsvgren.dylib                     0x0000000118ed568b Render + 521

I made a simple test app: https://github.com/igagis/svgren/tree/master/tests/async
Can you try running it in your environment, just to check if same issue can be reproduced with this app or it needs something more than taht?

You can just clone svgren git repo and run make test

Ok, I improved the test app, now it renders many files. And I could not reproduce the crash anymore on Linux.
I tried your set of files, but since I cannot add those to the repo right now the test takes samples from samples test app. No crash reproduced on both sets of files.
Could you try that test app in your environment? I also will try it on Mac this evening when I have access to it.
Note, that it was clearly a bug that there was that call to cairo_debug_reset_static_data(), but since it is gone now, I see no crash.
So, now I need a test app which reproduces the crash, so could you try it in your environment?

And by the way, test has passed on CI machine (Mac): https://travis-ci.org/igagis/svgren/jobs/371511824

Alas, I cannot try your test app in my environment because it is too complicated.
I wrap your library and all its dependcies into dynamic library in order to be used from managed C# code )
Well, will perform further investigations.

I see. One more thing to check is which version of cairo are you using? I think in some older version they had these multithreading issues, but I think in versions >=1.14.x it should be fixed.

So, as I understand you use C# threads, or tasks?

Task.Run but I can suppose it doesn't matter

Also, reading this thread: https://www.experts-exchange.com/questions/23069706/Calling-unmanaged-code-with-dllimport-from-a-multithreaded-app.html
there is a reply there saying this:

Did you know the .NET threads don't represent distinct Win32 threads.  If you are using thread-local storage in your DLL, this may cause the issue.
Try using the Thread.BeginThreadAffinity method to force the managed thread to a particular Win32 thread id.  You should do this on all threads that use the DLL so long as it is needed.
See http://msdn2.microsoft.com/en-us/library/system.threading.thread.beginthreadaffinity.aspx.

so, maybe you should try using threads instead of Task.Run and try this Thread.BeginThreadAffinity

Thank you for the start point for investigation.
Will do this a bit later.

I'm closing this issue for now, since multithreading was testd and works in Linux now.
@Papirosnik
If you find problems with your C# bindings to be a problem in svgren code, please open a new bug.


Adding HaluEval to the list of tasks

Now doing some unit tests to check whether everything is in order
Repo: https://github.com/RUCAIBox/HaluEval Paper: https://arxiv.org/abs/2305.11747 (EMNLP 2023)

Thanks very much for the PR!! would you be willing to add a short README to the task subdir following the template used in other tasks?
Else, this can be good to go if you’ve either reproduced a number from the paper or if the authors okay the implementation!

Thanks very much for the PR!! would you be willing to add a short README to the task subdir following the template used in other tasks?
Else, this can be good to go if you’ve either reproduced a number from the paper or if the authors okay the implementation!

Hey Hailey! I've asked the authors to chime in and double-check, and I've launched some jobs to check if we can reproduce some numbers!

Set to "in progress" under the assumption that we are holding off on reviewing until we see some attempts to reproduce scores from other papers.

Set to "in progress" under the assumption that we are holding off on reviewing until we see some attempts to reproduce scores from other papers.

Running the jobs in this very moment! I should be able to report some results later this week.


Add overview over all available serde_as conversions

The conversion view is part of the guide.
Remove the migration part of the guide. Instead document for each type
how it can be replaced using serde_as.
Add the derive macros to the guide.

bors r+


Tests project does not build in Xamarin Studio / OSX

This is because it does not understand PushStreamContent

What would you suggest? Copy source of it locally? (was it already opensourced?)

I'm not sure where the class comes from so not sure what I can suggest

It is this one:
https://msdn.microsoft.com/en-us/library/system.net.http.pushstreamcontent(v=vs.118).aspx
<Reference Include="System.Net.Http.Formatting, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />


How to run the file to work on problem, and which file?

I am totally new to C++ so pardon my ignorance. The instructions here are not clear: https://exercism.io/tracks/cpp/tests
I'm using Atom to open/edit the exercise files, it is my understanding that the changes I need to make would be in the hello_world.cpp file for this first problem, but how do I run it?
I can run other cpp files from Atom using the gpp-compiler package, but that doesn't work for the hello_world.cpp file and I get the following error:
Undefined symbols for architecture x86_64:
"_main", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Also is that the correct file that i'm supposed to be working on and submitting? again the instructions are very vague regarding this. It seems they make some big assumptions about the level of familiarity with C++ that people have coming into this.
Anyway, I appreciate your help!

Until an experienced Atom user can help you, you could use the command line. Open the terminal, go to the directory of the exercise and type cmake . and then make

Thank you for that. It would be helpful to have that information in the docs. I did not find anything that explains how to run the program ¯_(ツ)_/¯

When you run make, your solution and the tests will be compiled, linked and then the tests will be executed automatically.
It should looks similar to this:
[ 25%] Building CXX object CMakeFiles/hello-world.dir/hello_world_test.cpp.o
[ 50%] Building CXX object CMakeFiles/hello-world.dir/hello_world.cpp.o
[ 75%] Building CXX object CMakeFiles/hello-world.dir/test/tests-main.cpp.o
[100%] Linking CXX executable hello-world
[100%] Built target hello-world
===============================================================================
All tests passed (1 assertion in 1 test case)

[100%] Built target test_hello-world

OH maybe it is there in the doc about tests, but i totally missed it. It's not very clear to me that make runs the program.
Thank you, @siebenschlaefer


Added COVID-19 Blog site

Description 📜
Successfully Resolved issue https://github.com/khushi-purwar/WebDev-ProjectKart/issues/861 by adding online education site . I have also added working photos in the project folder and also provided hosted link here.
A project which describes the precautions, causes , effects and many more related to COVID-19.
LINK : https://covid19-62a79c.netlify.app/
Fixes #861

Type of change 📝
Please delete options that are not relevant. And in order to tick the check box just put x inside them for example [x] like this

[x] Add a new project
[x] Modified or enhanced the existing projects
[x] Improve the readme of any project

Domain of Contribution 📊
Please delete options that are not relevant. And in order to tick the check box just put x inside them for example [x] like this

[x] Project using HTML, CSS & JS

Checklist ✅
Please delete options that are not relevant.And in order to tick the check box just but x inside them for example [x] like this

[x] I have performed a self-review of my own code or work.
[x] My changes generates no new warnings.
[x] I'm GSSoC'22 contributor

Screenshots / Gif (Recommended) 📸

Kindly review and merge the PR.
Thank You !


Add IDLE_COAST signal to PCM_CRUISE for SecOC cars

This is unique to SecOC cars, including Sienna, but also RAV4 Prime; and hence I believe deserves it's own PR.
Sourced from: https://github.com/commaai/opendbc/pull/1344/commits/8e5887635aaf6fc3212f657892c1a832539aaeed

Bringing additional SecOC updates into master branch for PR.


Create Scan a Product Screen

Hi, Can I get this issue assigned to me?

Hi, Can I get this issue assigned to me?

Hi @Sarvaswa-Mohata When will you be concluding this task?


Request uses incorrect body instead of asQuery

Hi, I'm working on a library for DeepL (it's amazing to see the capabilities of CreateAPI) and while doing so I encountered a bug that even seams to be present in the tests (https://github.com/CreateAPI/CreateAPI/blob/da8730b23dab769414229bb386b3dcc2a77d6e42/Tests/Support/Snapshots/edgecases-change-access-control/Sources/Paths/PathsFake.swift).
The problem is that CreateAPI generates a POST request using URLQueryEncoder.encode(body).percentEncodedQuery as the body, but it should be using the asQuery property instead. This causes the request to be incorrect because URLQueryEncoder.encode(body).percentEncodedQuery uses camelCase for the property names, but the expected format is snake_case, which asQuery correctly uses.
In the test the property pattern_without_delimiter incorrectly would be called patternWithoutDelimiter in the POST request.
So instead of https://github.com/CreateAPI/CreateAPI/blob/da8730b23dab769414229bb386b3dcc2a77d6e42/Tests/Support/Snapshots/edgecases-change-access-control/Sources/Paths/PathsFake.swift#L57
I would expect:
 Request(path: path, method: "POST", query: body?.asQuery, id: "testEndpointParameters")

Same issue here.

+1


feat(keys): add keybinding to refresh all sections

Summary
How did you test this change?
Images/Videos

Current dependencies on/for this PR:

main

PR #202   👈

This comment was auto-generated by Graphite.


New cloud category

Describe the solution you'd like
Hi @mBouamama.
Firstly, thanks again for your great tool.
I wanted to inform you I added a cloud category in the Tools section.
It may require some modifications.

hi @noraj long time ago,
Normally new category will be availabe on the fly without new release.
You can try: rawsec-cli list tools cloud or rawsec-cli search pacu.


Too few arguments to function {closure}(), 0 passed and exactly 1 expected

Too few arguments to function {closure}(), 0 passed and exactly 1 expected

So why am I getting the error for this? I've checked a few tickets but couldn't really figure out why this won't work for me. We are using version 3.2.
use League\Container\Container;

$container = new Container();
$container->add('app.database.connection.default', function () {
	return new \PDO('mysql:dbname=test', '', '');
});
$container->add(\App\Infrastructure\Authentication\ServiceProvider::class, function($container) {
	return new \App\Infrastructure\Authentication\ServiceProvider($container->get('app.database.connection.default'));
});
$container->add(\Phauthentic\Authentication\AuthenticationServiceProviderInterface::class, \App\Infrastructure\Authentication\ServiceProvider::class);
$container->get(\App\Infrastructure\Authentication\ServiceProvider::class);

Hi, when resolving definitions via a closure you're in control about what is passed to the closure as you won't always need the container.
If you change the code above to this it should work fine.
$container->add(\App\Infrastructure\Authentication\ServiceProvider::class, function($container) {
	return new \App\Infrastructure\Authentication\ServiceProvider($container->get('app.database.connection.default'));
})->addArgument($container);


gnu(9120)=7702

This took 26720.670 seconds to compute.

gnu(9120)=7702
GAP      4.8.3
GrpConst 2.5
Runtime: 22959483 ms
Isomorphic groups eliminated
Validated on Linux server (AMD Opteron 6376 1400 MHz processor, 512 GB RAM)


C# 7.x §15.15.1 task type must not have multiple type arguments

Describe the bug
In the C# 7.x draft, §15.15.1 (Async functions / General) restricts the genericity of a task type:

For an async method that returns a value, a task type shall be generic. For an async method that does not return a value, a task type shall not be generic.

This allows a constructed task type with more than one type argument, but Roslyn does not support that.
Example
The standard should not allow:
using System;
using System.Runtime.CompilerServices;

class C {
    // «TaskType»<T> is CustomTask<int, int>.
    // «TaskBuilderType»<T> is not clear, but not outright disallowed either.
    async CustomTask<int, int> M() => 1; // error CS1983
}

[AsyncMethodBuilder(typeof(CustomTaskBuilder<>))]
public struct CustomTask<T1, T2> {}

public struct CustomTaskBuilder<TResult> {
    public static CustomTaskBuilder<TResult> Create() => default;
    public void Start<TStateMachine>(
        ref TStateMachine stateMachine)
        where TStateMachine : IAsyncStateMachine {}
    public void SetStateMachine(
        IAsyncStateMachine stateMachine) {}
    public void SetException(
        Exception exception) {}
    public void SetResult(TResult result) {}
    public void AwaitOnCompleted<TAwaiter,TStateMachine>(
        ref TAwaiter awaiter,
        ref TStateMachine stateMachine)
        where TAwaiter : INotifyCompletion
        where TStateMachine : IAsyncStateMachine {}
    public void AwaitUnsafeOnCompleted<TAwaiter,TStateMachine>(
        ref TAwaiter awaiter,
        ref TStateMachine stateMachine)
        where TAwaiter : INotifyCompletion
        where TStateMachine : IAsyncStateMachine {}
    public CustomTask<TResult, TResult> Task => default;
}

Expected behavior
Declare that the task type shall not have more than one type argument.
(Use "type argument" rather than "type parameter", because task types are constructed types.)
Additional context
Unlike a task builder type, a task type can be nested in a generic type.  Example:
using System;
using System.Runtime.CompilerServices;

class C {
    // «TaskType»<T> is Outer<char>.CustomTask<int>.
    // «TaskBuilderType»<T> is CustomTaskBuilder<int>; the type argument in Outer<char> does not affect this.
    async Outer<char>.CustomTask<int> M() => 1;
}

public class Outer<T1> {
    [AsyncMethodBuilder(typeof(CustomTaskBuilder<>))]
    public struct CustomTask<T2> {}
}

public struct CustomTaskBuilder<TResult> {
    public static CustomTaskBuilder<TResult> Create() => default;
    public void Start<TStateMachine>(
        ref TStateMachine stateMachine)
        where TStateMachine : IAsyncStateMachine {}
    public void SetStateMachine(
        IAsyncStateMachine stateMachine) {}
    public void SetException(
        Exception exception) {}
    public void SetResult(TResult result) {}
    public void AwaitOnCompleted<TAwaiter,TStateMachine>(
        ref TAwaiter awaiter,
        ref TStateMachine stateMachine)
        where TAwaiter : INotifyCompletion
        where TStateMachine : IAsyncStateMachine {}
    public void AwaitUnsafeOnCompleted<TAwaiter,TStateMachine>(
        ref TAwaiter awaiter,
        ref TStateMachine stateMachine)
        where TAwaiter : INotifyCompletion
        where TStateMachine : IAsyncStateMachine {}
    public Outer<char>.CustomTask<TResult> Task => default;
}

Thinking about this in the context of #875, I think I'll make a change to prohibit generic containing types entirely. It makes everything much simpler... I think we can leave any laxness on Roslyn's side as an extension for now.

Closed by #875.


fix for broken alter-table statements when default column values cont…

The problem
When a column defaultValue contains a semicolon (;) the generated alter-table statement is broken.
<column name="attachement_allowed_extensions" phpName="AttachementAllowedExtensions"
type="VARCHAR" size="250" required="true" defaultValue="pdf;jpg;png;doc;docx;xls;xlsx;txt"/>

the reason for that can be found in file /src/Propel/Generator/Platform/DefaultPlatform.php line 818ff
if ($columnChanges) {
    //merge column changes into one command. This is more compatible especially with PK constraints.

    $changes = explode(';', $columnChanges);

the already generated sql string consists of multiple alter table statements and shall be split into single alter table statements to merge. If the generated statement
ALTER TABLE `newsletter_sets`  CHANGE `attachement_allowed_extensions` `attachement_allowed_extensions` VARCHAR(250) DEFAULT 'pdf;jpg;png;doc;docx;xls;xlsx;txt' NOT NULL;

contains multiple semicolons so the splitting goes wrong.
The solution
propel already contains a sql statement parser that can be used as a drop-in replacement here.
$sqlParser = new SqlParser();
$sqlParser->setSQL($columnChanges);
$changes = $sqlParser->explodeIntoStatements();

We now have master almost green ( https://travis-ci.org/github/propelorm/Propel2 )
Please try to rebase yours against that one, that will make it easier to verify your changes.
Do you happen to have a test case along with your change request?

i rebased it against the current master - i will try to build a testcase

i see that some testCases are failing now due to some different newlines. What would you recommend me to do?
1) Propel\Tests\Generator\Platform\OraclePlatformMigrationTest::testGetModifyDatabaseDDL with data set #0 (Propel\Generator\Model\Diff\DatabaseDiff Object (...))
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
 \n
 CREATE SEQUENCE foo5_SEQ\n
     INCREMENT BY 1 START WITH 1 NOMAXVALUE NOCYCLE NOCACHE ORDER;\n
-\n
 ALTER TABLE foo2 RENAME COLUMN bar TO bar1;\n
 \n
 ALTER TABLE foo2\n
/home/travis/build/propelorm/Propel2/tests/Propel/Tests/Generator/Platform/OraclePlatformMigrationTest.php:73

https://travis-ci.org/github/propelorm/Propel2/jobs/700959913

Before, if (!trim($change)) continue; took care of empty rows
You might want to check what your changed method returns here instead.

ping @hevengo

Merged in https://github.com/propelorm/Propel2/pull/1997


Add wasm to precache manifest

Addresses #3319
I'm not familiar with workbox's codebase, so I may have forgotten to appropriately change something

I think this deserves a bump, this looks like an easy merge.

Agreed. Merged now.

Sorry I didn't reply any chance you can create a PR  adding .wasm file example to the affected tests for the package? Right now as expected all the tests use .js, .css and .html and I'd like the tests to match updated default.

sure, i can soon take a look at that