[Documentation] Node 5.x may be recommended?

There is a huge performance difference between node 4.x and 5.x and I think it should be mentioned in the documents. Node.js site says 4.4.0 is an LTS release which made me prefer it. But 5.x release use a newer npm that flattens dependencies. Which results to:

Packager start times 200 seconds vs. 50 seconds.
node_modules directory size 1200 MB vs 200 MB.

For guys like me, who are not familiar with node.js, it is hard to figure out.
Platform: Win 7
Didn't submit a PR on the grounds that I may be talking sh.t because packager starts in 3 seconds on my mac.

@taypo the flatter node_modules is due to npm 3, so we could recommend that people use npm 3 with Node 4 or 5 (or upcoming Node 6).
cc @bestander I saw you put out a PR recently to move Travis to npm 2 but what do you think about using npm 3 everywhere? npm 3 has gotten a lot faster recently too.

Pretty interesting, and just poking in here, what kind of performance differences are you seeing?

@ide Circle CI is npm 3. So we run flow, jest and Android tests using node 5.6 and npm 3.x.
I've left Travis at npm 2 to make sure we still get it compiling.
Personally I would prefer node 5 and npm 3.
My colleagues are hesitant because installing node_modules with npm 3 takes ages compared to npm 2.
Although we are experimenting on an laternative npm client that will bring both worlds together.
Stay tuned.

@peterp just to be clear, performance differences are not in the resulting application. Just the items I listed before. The time it takes the packager to start and the size of the node_modules directory (which indicates react-native init is downloading too much)

@bestander npm 3 used to be very, very slow, but it's gotten better. I recommend setting npm set progress false and then comparing it to npm 2 -- npm 3 is still slower but not horribly slow anymore. That said, both npm 2 and 3 are ultra-slow and make it so hard to bisect compared to something like git-lock so your new npm client is very welcome :)

I'm using Node 4 and npm 2 locally and very happy with it.
I'll close this as it's a discussion rather than a bug (we'd like to use the GitHub bug tracker for bugs, and GitHub really needs to implement a Discussions tab) but feel free to continue discussing here.

I wish the whole project used gradle. npm is several steps back for a package manager IMHO.

Gradle is pretty crazy and slow, and doesn't really address iOS. Moving forward the right thing might be to use Buck for builds instead of Gradle and CocoaPods, and npm for distribution.


UnexpectedValueException Invalid route action: [Connections] to all routes

I can't access, all routes don't work!
Instalattion Windows
PHP 7.4.28
Laravel 8
LdapRecord 2.15
Connections was not found.
Controller class Connections for one of your routes was not found. Are you sure this controller exists and is imported correctly?

Hi @adoniasovidio,
Can you post your routes/web.php file?

Forgive me if you don't understand your instructions in "readme.md"
But wherever I put these routes, the same error appears

Hi @adoniasovidio,
You do not need to register those 3 routes, you only need to call Browser::routes():
+ Route::prefix('/ldap')->group(function () {
+    \LdapRecord\Browser\Browser::routes();
+ });

- Route::get('/', Connections::class)->name('ldap::connections');
- Route::get('/{connection}', Browse::class)->name('ldap::browse');
- Route::get('/{connection}/{guid}', Browse::class)->name('ldap::show');

@stevebauman
Thanks for your help, so fast!
I believe there is a step missing, after installing with composer, there is no controller in the app/http or app/http/Controllers path


ci: reduce node_versions we test against

on PRs/commits to main or dev, we'll test against the "latest" version of node, but for releases (nightlies, experimental, pre-releases, stable) we'll test against v14, v16, and v18
i've also moved the reusable workflows into a sub directory of the workflow directory to more easily tell that aren't run on their own.
Signed-off-by: Logan McAnsh<EMAIL_ADDRESS>
Closes: #

[ ] Docs
[ ] Tests

Testing Strategy:

dang it https://github.com/remix-run/remix/actions/runs/2551054712


UndoManager

Clear UndoManager on page change or switch UndoManager per page

A pageManager API is currently in development in the core grapesjs library which likely provide a more efficient way to manage this.


Module specific queues.

In gitlab by @A-Lawrence on Sep 2, 2016, 15:17
Would be be providing ourselves with better control over what gets processed first, by having module specific queues?
As Core grows, we're going to have a lot of services producing jobs - I don't think low, med, high, emails are going to quite cut it when we want to clear a backlog of VT jobs etc.
Do we go for:

visittransfer
emails
mship
sys
teamspeak

Or even:

visittransfer & visittransfer-priority
emails & emails-priority
mship & mship-priority
sys & sys-priority
teamspeak & teampseak-priority

With a view to phasing out:
low, med, high, default
?

In gitlab by @NFarrington on Sep 8, 2016, 03:35
@A-Lawrence I don't see a problem with keeping the current queues. The whole point is that they're prioritised, so the important jobs (of which there are few) are processed first.
If a certain module is going to impact on this, we can define a module-specific queue just for that module (but not all modules by default), but I don't see this being necessary.


Form_Validation - "required" not working in arrays

Old version form validation good work in CI 3. New version have problem in validate. I expect the problem to "Run" function

If this is a bug, explain it better, please.
If this is a support issue, those should be raised on forum.codeigniter.com, not here, which is for code fixes.


Uploads

Create a straightforward way to upload images (or other attachments).

Create a "slug" for each web log; this is the path under which uploads will be stored.
Default to storing uploaded images in the database. (This will need an endpoint to return the data as well.)
Allow images to be written to the filesystem. (The static file middleware will serve these assets.)
Add database-stored images to the backup and restore processes.

This is complete; will be part of beta 3


migrate from 4.0.0-alpha.6 to beta and navbar totally broken - docs dont show what has changed

seems the beta broke the navbar that works fine in alpha 6.
the new change log docs dont highlight what has changed.
Can someone provide new docs to show how to convert  form old to new?  Argh.  Have to revert to alpha until this is solved.  Boss is so mad.
Thank you.

Everything you're using is pre-release. We've rewritten plenty in every alpha release and haven't provided upgrade paths for any of them for good reason—it's far too much change. Please consult the hosted docs and go from there.


Generating the kitty without parents

Generating the kitty without the parent when the user inserts the new key in the wallet (basically, 1 kitty is provided for free as an onboarding process).
This was in the proposal.

This also 2 parts ;
Implemented both in bc side and ci-wallet side as below:
Blockchain side implementation : https://github.com/mlabs-haskell/Tuxedo/blob/4caa90a2cc88b70973427c55c154f5af224118b8/wardrobe/kitties/src/lib.rs#L576-L596
Wallet side implementation : https://github.com/mlabs-haskell/Tuxedo/blob/4caa90a2cc88b70973427c55c154f5af224118b8/wallet/src/kitty.rs#L309-L356
Now JS side implementation is pending.

Blockchain side and cli-wallet side implementation is done.
JS side implementation is pending. No blocking.

Since blockchain-side implementation is done I moving to Done as it is already submitted in the https://github.com/mlabs-haskell/Tuxedo


Change usage of “blacklist” to “blocklist”

The upcoming WordPress 5.5 release replaces all instances of the term “blacklist” to the more inclusive “blocklist”. This includes changing of blacklist_keys to blocklist_keys.
Accordingly, I will be changing the name of my Comment Blacklist for WordPress project to the more inclusive “Comment Blocklist for WordPress” and renaming the repo. Fortunately, it appears that links to the old repo URLs will automatically redirect to the new paths. Documentation and related screenshots will also need to be updated.
Ticket:
https://core.trac.wordpress.org/ticket/50413
Changeset:
https://core.trac.wordpress.org/changeset/48121

The name of the option has changed in the final version of WordPress 5.5 to disallowed_keys.
https://make.wordpress.org/core/2020/07/23/codebase-language-improvements-in-5-5/


Minecraft 1.12 Support

1.12 (also Spigot 1.12 with BUILD_FROM_SOURCE=true) will always end with a JsonParseException:
[19:21:05 ERROR]: Encountered an unexpected exception com.google.gson.JsonParseException: java.io.EOFException: End of input at line 2 column 1 path $ 	at net.minecraft.server.v1_12_R1.ChatDeserializer.a(SourceFile:506) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.ChatDeserializer.a(SourceFile:522) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.JsonList.load(JsonList.java:174) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.DedicatedPlayerList.A(SourceFile:99) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.DedicatedPlayerList.<init>(SourceFile:25) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.DedicatedServer.init(DedicatedServer.java:183) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.MinecraftServer.run(MinecraftServer.java:544) [spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121] Caused by: java.io.EOFException: End of input at line 2 column 1 path $ 	at com.google.gson.stream.JsonReader.nextNonWhitespace(JsonReader.java:1393) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:549) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at com.google.gson.stream.JsonReader.peek(JsonReader.java:425) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:74) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:61) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.ChatDeserializer.a(SourceFile:504) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	... 7 more [19:21:05 ERROR]: 	Cause of unexpected exception was java.io.EOFException: End of input at line 2 column 1 path $ 	at com.google.gson.stream.JsonReader.nextNonWhitespace(JsonReader.java:1393) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:549) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at com.google.gson.stream.JsonReader.peek(JsonReader.java:425) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:74) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:61) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.ChatDeserializer.a(SourceFile:504) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.ChatDeserializer.a(SourceFile:522) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.JsonList.load(JsonList.java:174) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.DedicatedPlayerList.A(SourceFile:99) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.DedicatedPlayerList.<init>(SourceFile:25) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.DedicatedServer.init(DedicatedServer.java:183) ~[spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at net.minecraft.server.v1_12_R1.MinecraftServer.run(MinecraftServer.java:544) [spigot_server.jar:git-Spigot-cd6ba67-f7d14f1] 	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121] [19:21:05 ERROR]: This crash report has been saved to: /data/./crash-reports/crash-2017-06-14_19.21.05-server.txt [19:21:05 INFO]: Stopping server

I had to make this fix for vanilla 1.12
https://github.com/itzg/dockerfiles/commit/e509563b109695a61d1bf43b6a5fa0c9440e37f6#diff-1b75c648f95c688de936b9c07a9b0008
I'll look if something additional is needed down the Spigot path.

I am having a similar issue using a QNAP NAS with a docker compatible container station. Upon first launch of a new container I see this in console. 1.11.2 worked perfectly.
[20:47:19] [Server thread/INFO]: Stopping server
Switching to user 'minecraft'
Checking version information.
Checking type information.
Setting initial memory to 1G and max to 1G
+ [[ VANILLA == \F\E\E\D\-\T\H\E\-\B\E\A\S\T ]]
+ '[' -f /data/bootstrap.txt ']'
+ exec java -XX:+UseG1GC -Xms1G -Xmx1G -jar minecraft_server.1.12.jar
[20:48:20] [Server thread/INFO]: Starting minecraft server version 1.12
[20:48:20] [Server thread/INFO]: Loading properties
[20:48:20] [Server thread/INFO]: Default game type: SURVIVAL
[20:48:20] [Server thread/INFO]: Generating keypair
[20:48:21] [Server thread/INFO]: Starting Minecraft server on *:25565
[20:48:21] [Server thread/INFO]: Using default channel type
[20:48:21] [Server thread/ERROR]: Encountered an unexpected exception
com.google.gson.JsonParseException: java.io.EOFException: End of input at line 2 column 1 path $
     at ra.a(SourceFile:506) ~[minecraft_server.1.12.jar:?]
   at ra.a(SourceFile:522) ~[minecraft_server.1.12.jar:?]
   at pn.g(SourceFile:141) ~[minecraft_server.1.12.jar:?]
   at nw.A(SourceFile:99) ~[minecraft_server.1.12.jar:?]
   at nw.<init>(SourceFile:25) ~[minecraft_server.1.12.jar:?]
   at nx.j(SourceFile:188) ~[minecraft_server.1.12.jar:?]
   at net.minecraft.server.MinecraftServer.run(SourceFile:434) [minecraft_server.1.12.jar:?]
   at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]
Caused by: java.io.EOFException: End of input at line 2 column 1 path $
      at com.google.gson.stream.JsonReader.nextNonWhitespace(JsonReader.java:1393) ~[minecraft_server.1.12.jar:?]
    at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:549) ~[minecraft_server.1.12.jar:?]
   at com.google.gson.stream.JsonReader.peek(JsonReader.java:425) ~[minecraft_server.1.12.jar:?]
   at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:74) ~[minecraft_server.1.12.jar:?]
 at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:61) ~[minecraft_server.1.12.jar:?]
   at ra.a(SourceFile:504) ~[minecraft_server.1.12.jar:?]
... 7 more
[20:48:21] [Server thread/ERROR]: This crash report has been saved to: /data/./crash-reports/crash-2017-06-17_20.48.21-server.txt
[20:48:21] [Server thread/INFO]: Stopping server
[20:48:21] [Server Shutdown Thread/INFO]: Stopping server

@matthewguenther at least in your case it appears to be retaining the prior /data content, specifically the "malformed" JSON files. Starting a new container purposely with no attached volume, I can see the additional startup messages I would expect, such as "Creating server.properties" (below). One way to solve this is to docker exec mc rm banned-players.json banned-ips.json into the container and then on the next container start it'll re-initialize those files.
> docker run -it --rm -p 25565:25565 -e EULA=TRUE itzg/minecraft-server
Switching to user 'minecraft'
Checking version information.
Checking type information.
Downloading minecraft_server.1.12.jar ...
Creating server.properties
Setting motd to A Minecraft Server Powered by Docker
Setting enable-rcon to true
Setting rcon.password to minecraft
Setting rcon.port to 25575
Setting level-name to world
Setting pvp to true
Setting online-mode to TRUE
Setting level type to DEFAULT
Setting difficulty to 1
Setting initial memory to 1G and max to 1G
[22:16:51] [Server thread/INFO]: Starting minecraft server version 1.12
[22:16:51] [Server thread/INFO]: Loading properties
[22:16:51] [Server thread/INFO]: Default game type: SURVIVAL
[22:16:51] [Server thread/INFO]: Generating keypair
[22:16:51] [Server thread/INFO]: Starting Minecraft server on *:25565
[22:16:51] [Server thread/INFO]: Using epoll channel type
[22:16:51] [Server thread/INFO]: Preparing level "world"
[22:16:53] [Server thread/INFO]: Loaded 488 advancements
[22:16:54] [Server thread/INFO]: Preparing start region for level 0
[22:16:55] [Server thread/INFO]: Preparing spawn area: 5%
[22:16:56] [Server thread/INFO]: Preparing spawn area: 8%
[22:16:57] [Server thread/INFO]: Preparing spawn area: 13%
[22:16:58] [Server thread/INFO]: Preparing spawn area: 17%
[22:16:59] [Server thread/INFO]: Preparing spawn area: 22%
[22:17:00] [Server thread/INFO]: Preparing spawn area: 28%
[22:17:01] [Server thread/INFO]: Preparing spawn area: 34%
[22:17:02] [Server thread/INFO]: Preparing spawn area: 40%
[22:17:03] [Server thread/INFO]: Preparing spawn area: 44%
[22:17:04] [Server thread/INFO]: Preparing spawn area: 48%
[22:17:05] [Server thread/INFO]: Preparing spawn area: 48%
[22:17:06] [Server thread/INFO]: Preparing spawn area: 52%
[22:17:07] [Server thread/INFO]: Preparing spawn area: 58%
[22:17:08] [Server thread/INFO]: Preparing spawn area: 65%
[22:17:09] [Server thread/INFO]: Preparing spawn area: 72%
[22:17:10] [Server thread/INFO]: Preparing spawn area: 80%
[22:17:11] [Server thread/INFO]: Preparing spawn area: 84%
[22:17:12] [Server thread/INFO]: Preparing spawn area: 89%
[22:17:13] [Server thread/INFO]: Preparing spawn area: 92%
[22:17:15] [Server thread/INFO]: Preparing spawn area: 97%
[22:17:15] [Server thread/INFO]: Done (23.649s)! For help, type "help" or "?"
[22:17:15] [Server thread/INFO]: Starting remote control listener
[22:17:15] [RCON Listener #1/INFO]: RCON running on <IP_ADDRESS>:25575

My particular server does not have a command like for boot arguments, how would I go about this using the file system?

@matthewguenther hmm, that's hard to say since I'm used to direct access to the docker CLI. The alternative, that is likely easier, is to double check that a new 1.12 container is using a distinct volume attachment for /data.

I ran into this issue earlier when starting a new container in a new folder. Wouldn't start properly until I copied over the .json configurations from a previous save.
[20:15:14] [Server thread/INFO]: Starting minecraft server version 1.12 [20:15:14] [Server thread/INFO]: Loading properties [20:15:14] [Server thread/INFO]: Default game type: SURVIVAL [20:15:14] [Server thread/INFO]: Generating keypair [20:15:14] [Server thread/INFO]: Starting Minecraft server on *:25565 [20:15:14] [Server thread/INFO]: Using epoll channel type [20:15:15] [Server thread/ERROR]: Encountered an unexpected exception com.google.gson.JsonParseException: java.io.EOFException: End of input at line 2 column 1 path $ 	at ra.a(SourceFile:506) ~[minecraft_server.1.12.jar:?] 	at ra.a(SourceFile:522) ~[minecraft_server.1.12.jar:?] 	at pn.g(SourceFile:141) ~[minecraft_server.1.12.jar:?] 	at nw.A(SourceFile:99) ~[minecraft_server.1.12.jar:?] 	at nw.<init>(SourceFile:25) ~[minecraft_server.1.12.jar:?] 	at nx.j(SourceFile:188) ~[minecraft_server.1.12.jar:?] 	at net.minecraft.server.MinecraftServer.run(SourceFile:434) [minecraft_server.1.12.jar:?] 	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_72-internal] Caused by: java.io.EOFException: End of input at line 2 column 1 path $ 	at com.google.gson.stream.JsonReader.nextNonWhitespace(JsonReader.java:1393) ~[minecraft_server.1.12.jar:?] 	at com.google.gson.stream.JsonReader.doPeek(JsonReader.java:549) ~[minecraft_server.1.12.jar:?] 	at com.google.gson.stream.JsonReader.peek(JsonReader.java:425) ~[minecraft_server.1.12.jar:?] 	at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:74) ~[minecraft_server.1.12.jar:?] 	at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:61) ~[minecraft_server.1.12.jar:?] 	at ra.a(SourceFile:504) ~[minecraft_server.1.12.jar:?] 	... 7 more [20:15:15] [Server thread/ERROR]: This crash report has been saved to: /data/./crash-reports/crash-2017-07-02_20.15.15-server.txt [20:15:15] [Server thread/INFO]: Stopping server [20:15:15] [Server Shutdown Thread/INFO]: Stopping server
Here's the argument I used to start the container:
docker run -e 'JVM_OPTS=-Xmx4096M -Xms1024M' -d -v /media/ramdisk/servers/minecraft/v3:/data -p 25565:25565 -e DIFFICULTY=hard -e EULA=TRUE --restart=unless-stopped --name mc_v_l itzg/minecraft-server

@dereekb and @kitzu even though's a manual way to fix up the empty JSON files, I'll work on a start-time fixer-upper in the script. Stay tuned...

@dereekb, @kitzu , please do a pull of the latest and see if that fix will get your server running.

Worked for me. Started a new container in a new directory without any issues. 👍

Just an update from my end after a bit of fiddling. When creating a new container, I still get the same errors and fail to start. The problem does indeed seem to be to be with the JSON files. Currently, my container only creates the following JSON files: banned-ips, banned-players, and usercache. Missing are ops, and whitelist. Deleting all the JSON from the container and copying over the JSON from a functioning 1.11.2 container fixes the issue.

Perhaps I should have the start script scrub all five of those json files.

Sorry for the delay on this. I should be able to get to this today or so.

I have pushed an update that will check and fix all json files. Give that a try, please.


[Removal]:

Hotspot Name
Large Emerald Armadillo
Hotspot b58 Address
112b1v7hR47hrMsofacfEtRpDD5E1Wd7eXKrsjR9tD3SvbY5n8a3
Discord Handle
No response
Hotspot Manufacturer
panther
Removal Reason
I just bought an old machine from someone else. Why is it on the Denylist? Please remove him. Thank you very much.
Modifications
No
Extra forwarders
No
Extra antennas
No
Additional Information
No response

you should to ask the seller to remove it for you. you made mistake that no one else can help you correct it.

you should to ask the seller to remove it for you. you made mistake that no one else can help you correct it.

Nothing is always the same. You shouldn't hurt the kind-hearted people who trust helium in this way. Stop hatred, you villain.

chill bro. it is a simple truth. you are cheated by bad people, so you need to find the bad guy.

i just realized cowboy1144, rabies555, shutup1231, and vpn1314 are indirectly and directly related to the same wallets 14cFuwuwmawgRy8NeteiWLkawrPoomRtjteRLqoBgaubXurnqWP and 13181UjYjUZ4HfLBRHveQorcpGwz1121HyxTf3tJgD4Bg6dXoT8.
gonna be really interesting for helium to look into it.

It means they all bought from the same seller. What's strange about that?

It means they all bought from the same seller. What's strange about that?

an interesting seller that sold the miners on the denylist to five 'different people'. since they knew each other and all got cheated by him, they should have evidence of the cheater and file a police report against him.

We have taken into account this removal request in the next iteration of the denylist. It may take some time before it's processed. This is an automated comment due to the volume of addition and removal requests. A future tool is in the works to provide more insight into the analysis approach made by the Helium team and community members that maintain this list.


Intern more kinds of things

Cargo sometimes makes a lot of copies of data structures. For example the string "serde", was copied for the name of each dependency on that crate, as the name of each version of that package, and for each feature that enables that package. This got fixed by adding a InternedString data type that deduplicates the data and leaks it into a &'static reference. We have other data structures which use Arc/Rc to make cloning cheaper.
We should experiment with Interning them to see if it is a Speed or Memory or Ergonomic win.
Off the top of my head:

[ ] PackageId is already using Arc, is copied and hashed and compared all over the place in hot code.
[ ] SourceId is already using Arc, has a manual cache for crates.io and will probably be leaked anyway by caching PackageId.
[ ] semver::Version/semver::VersionReq are used a lot, probably often with the same value, and are bigger structures then they seem.

Note that {Package,Source}Id internally using Arc already was a "poor man's" form of interning early on. I definitely agree we should switch to an InternedString style approach, and in doing so it should be fine to remove the internal Arc

There is interning infrastructure used in the html5ever crate. Might be useful here - you can pre-intern anything you want at compile-time

For semver::Version and semver::VersionReq should we find a cargo-local solution (I'm thinking of wrapping all the Version::parse calls), or should we request this support upstream?

I think we find a cargo-local solution. I was thinking of making an InternedVersion{Req} to make sure we are always interning it, but if we only have a few constructors then maybe that is overkill.

Agreed this should probably be Cargo-specific for now, we can always upstream later if it's useful!

I was thinking of making an InternedVersion{Req} to make sure we are always interning it, but if we only have a few constructors then maybe that is overkill.

I think the box-leaking, interning solution only gives us access to a &'static Version{Req} so we'd have to change all the instances of owned values to borrows.  At that point I'm not sure if it's best to use:

&'static Version{Req},
InternedVersion{Req}, or a
InternedVersion{Req} which is a type alias of &'static Version{Req}.

Either way, I'll try and finish up this ticket on Sunday.

@alexcrichton if you get a chance could you write down those hashing shenanigans you were explaining to me are happening with package id and source id?  The part I'm most interested in is the ideal setup we'd like to be in, in terms of interned values and their hashes.

Sure thing! I think you ended up finding it on the SourceId PR. The Hash for SourceId leaves out many fields and canonicalizes others, but the actual instances are still distinct and have different fields. Now that I think about it I think PackageId is pretty bland, it's just SourceId that can be "equal" yet have different values for each field.

Follow-up task: remove all the no longer necessary .clone() calls to all the Copy-able interned typed.

#6468 implements the last bit about semver, but there were some uncertainty on whether it's a desired change which halted the PR.  So I'm going to consider this done for the time being.


Extension breaks folding in Python

This extension breaks the folding buttons in VSCode in Python. Please fix, thank you very much.

?

Have you tried disabling folding in the extension? I had a similar issue in #13

@DeltaRazero I suggested the same thing in #61 ... disabling editor folding for Comment Anchors in User Settings seems to solve the issue (of course, then you won't be able to fold your anchors).

Fixed as of 1.7.0 due to the removal of editor folding.


Fix Particles2D weird behaviour with scale randomisation and curve #15497

Fix #15497
Video for demonstrate result:
https://www.youtube.com/watch?v=KfzCmnmqAXA

Could you squash the two commits? See PR workflow.

@akien-mga I did squash two commits but now it failed in AppVeyor build. I didn't change anything in the code.

It's ok, the Appveyor error is independent of your PR, it was due to a mistake in 65fd37c1.

Moving to 3.2 milestone as we're about to enter the beta stage and release freeze for Godot 3.1. Only bug fixes against issues of the 3.1 milestone (or enhancements to core features of the 3.1 roadmap) will be considered until 3.1-stable is released.
Note: If it's merged after 3.1-stable is released, this change may be considered for cherry-picking into a later 3.1.x release.

It's hard to see in the videos in issue #15497 if this is the same issue that I am having when using a curve on Particles that has Size Randomization set to seomthing higher than "0", so here is a gif that should show the issue very clearly if it's indeed the same issue?
in the gif below it's very clear that the individual particles are not scaling to "0" even though the curve should set it to scale from 1 to 0 over the particles life time.

Tested the issue that @jesperkondrup explains above, and this PR fixed it :+1:

Is a similar fix needed for CPUParticles and CPUParticles2D?
@jesperkondrup Isn't it expected though with a Scale Random of 1 (i.e. 100% random) that particles will have their scale affected by the Curve by a percentage between 0 and 100%?

@akien-mga Yes the issue is also present in the CPUparticles.
To me at least it makes more sense that when you set sizerandom to 1 this will only affect the start size of the Particle. If you then chose to have a curve affecting the life time as well, then the start size is affected by a percentage over life time (defined in the curve). This also gives you the freedom to have random sized particles scaled down to "0" so they can fade out nicely without having to fade them out using a gradient.

@akien-mga Yes the issue is also present in the CPU Particles.
I am not sure about your question but this fix is how I would expect it to work. That you set a random Start size and then the curve affects the life time of that start size in a percentage. So you can scale particles to "0" for example which was not possible before.

Ah you're right, the Scale Random should indeed only impact the main Scale method, which should then be the start size for the curve.

Superseded by #32309, but thanks for the contribution!


Send Interval

Driver settings send interval does not appear to queue properly either based on reply or a set time interval.

on reply - there needs to be a field for a reply string to trigger the send. If this field is left blank then the response construction should be used to decide what is considered a reply to send on.

No matter how quickly commands are triggered they should be queued & only sent at the Interval entered. I quickly tested this by setting interval to 3000 ms and sending 4-5 commands very quickly. I could see the responses to these commands came back immediately and not close to the interval entered.

can't reproduce this, wednesday.

set interval to 5000 ms. Then select command and press R 4 times quickly.
You should see responses coming back approx. 5 secs apart right?
Tim Ogletree
Systems Engineering
MediaMerge, Inc.
205.678.0588
www.mediamerge.com
On Sun, Jun 12, 2016 at 4:44 PM, gbaumgart<EMAIL_ADDRESS>wrote:

can't reproduce this, wednesday.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/net-commander/windows-dist/issues/25#issuecomment-225462358,
or mute the thread
https://github.com/notifications/unsubscribe/AJxHmIKfpJb7RAtfxubWjWhShrGDWPZXks5qLH3IgaJpZM4Izs1W
.

calling commands from the interface will by pass such settings for many reasons (not just the interval settings).

found a tiny bug, fixed and closing now


Feature Request: Load Balancer Backend annotation for MaxConnections setting.

FEATURE REQUEST
Title: Load Balancer Annotation should support setting MaxConnections for Backend for overload protection.
Current LoadBalancer Annotations do not support setting MaxConnections to backends. This is a critical setting required for overload protection of services. Hence this annotation should be supported and is critical to add for overload protection of services.
OCI load balancer backend details: https://registry.terraform.io/providers/oracle/oci/latest/docs/resources/load_balancer_backend
Required variable: max_connections
<!--
If this is a BUG REPORT, please:
  - Fill in as much of the template below as you can.  If you leave out information, we can't help you as well.

If this is a FEATURE REQUEST, please:
  - Describe *in detail* the feature/behaviour/change you'd like to see.
  - Current LoadBalancer Annotations do not support setting MaxConnections to backends. This is a critical setting required for overload protection of services. Hence this annotation should be supported and is critical to add for overload protection of services.

OCI load balancer backend details: https://registry.terraform.io/providers/oracle/oci/latest/docs/resources/load_balancer_backend
Required variable: max_connections

Are you looking for backend level configuration or a common maxConnections for all backends of the LB?

Are you looking for backend level configuration or a common maxConnections for all backends of the LB?

Hi @AkarshES , Thanks for your response.
OCI Load balancer only supports a common maxConnections for all backends of the LB. Hence, this request is to add support for the same i.e Annotation to allow setting a common maxConnections for all backends of the LB. Thanks.

Each backend can have custom maxConnections, but thanks for confirming LB level config is good enough for your use case.
https://docs.oracle.com/en-us/iaas/api/#/en/loadbalancer/20170115/datatypes/BackendDetails


Why is this verification necessary?

https://github.com/MuckRock/squarelet-auth/blob/10fc535f1c207dc80ddc4892aa0601a02771b2f2/squarelet_auth/views.py#L40-L45

The timestamp comparison is to prevent replay attacks


How do I give the specified table name  to "tracking_column"?

For all general issues, please provide the following details for fast resolution:

Version: logstash 5.6.14
Operating System: centos 7
Config File:

jdbc {
    jdbc_driver_library => "/home/logstashtest/lib/mysql-connector-java-5.1.47/mysql-connector-java-5.1.47-bin.jar"
    jdbc_driver_class => "com.mysql.jdbc.Driver"
    jdbc_connection_string => "jdbc:mysql://<IP_ADDRESS>/test"
    jdbc_user => "username"
    jdbc_password => "password"
    schedule => "* * * * *"
    record_last_run => true
    use_column_value => true
    tracking_column => "clock"
    tracking_column_type => numeric
    last_run_metadata_path => "/home/logstashtest/clock"
    statement => "select from_unixtime(history.clock) as timestamp,hosts.hostid as hostid,hosts.host as host,items.key_ as keyword ,history.value as value  from history,items,hosts where items.itemid=history.itemid and items.hostid=hosts.hostid and clock  > :sql_last_value"

The history table include clock(numeric) column,when i run logstash ,I get the following warn message:
[2019-01-28T17:08:00,058][WARN ][logstash.inputs.jdbc     ] tracking_column not found in dataset. {:tracking_column=>"clock"}
and the "/home/logstashtest/clock" not update,The logs has been repeated
I made the following attempt:
tracking_column => "clock"
tracking_column => "history.clock"
tracking_column => "[history][clock]"
so, how do I give the specified table name  to "tracking_column"?

tracking_column use the field that return from your query. So I think you should use "timestamp", referred to this statement select from_unixtime(history.clock) as **timestamp**

I have the same issue in my script :(
Asked all over around and can't find a way to specify table name to tracking_column


how to get image's shape using tf.data map

my dataset is large and the image is irregular. I need to pad the image according to different width and length, but I can't get the image's shape using image.shape. The shape is [None, None, 3].

Have you applied any image resizing/altering functions using tf.image operations? Namely, from here: https://www.tensorflow.org/api_docs/python/tf/image
You can chain together such operations in a separate function then pass it to a tf.data.Dataset.map function. For instance,
def preprocess_image(image):
    # .. define your desired operations here
    return preprocessed_image

ds = tf.data.Dataset.from_tensor_slices(...)
ds = ds.map(preprocess_image)

@colorful-ocean
Please update as per above comment.

@iobtl
def process_image(image, hw_dst=416):
h_src, w_src = image.shape[:2]
if h_src>w_src:
    scales = hw_dst/h_src
    h_resize = hw_dst
    w_resize = int(w_src*scales)
else:
    scales = hw_dst/w_src
    h_resize = int(h_src*scales)
    w_resize = hw_dst

image = tf.image.convert_image_dtype(image, dtype=tf.float32)#/255.
image = tf.image.resize(image, [h_resize, w_resize])
#image = tf.math.divide(image, 255.)
image = tf.image.pad_to_bounding_box(image, 0, 0, hw_dst, hw_dst)
return image, scales

I need to pad the image according to different width and length, like the function above. use map method can't work, because the image.shape is (None,None,3)

How are you forming your tf.data.Dataset object? Could you try generating the output from the following code:
ds = tf.data.Dataset.from_tensor_slices(image_paths)
ds = ds.map(tf.io.read_file)
ds = ds.map(tf.image.decode_jpeg)

for image in ds.take(5):
    print(image.shape)

To verify your image shapes. Using tf.data.Dataset.map is not an issue even if you have different image shapes. The image.shape is (None, None, 3) because you have different image shapes for every image.

@iobtl
yes，but I need divide the img's h and w. This will get error, because it is None.
    hr_image = tf.io.read_file(image_path)
    hr_image = tf.io.decode_png(hr_image, channels=3)

    h_src, w_src = hr_image.shape[:2]
    inp_h, inp_w = input_shape

    lr_h, lr_w = h_src//downscale+1, w_src//downscale+1
    hr_h, hr_w = lr_h*downscale, lr_w*downscale

    <ipython-input-2-1c8a4b52a1ec>:21 make_dataset  *
        lr_h, lr_w = h_src//downscale+1, w_src//downscale+1

    TypeError: unsupported operand type(s) for //: 'NoneType' and 'int'

This problem has been bothering me

@iobtl
I found the solution!
fail
    h_src, w_src = hr_image.shape[:2]

fail
    h_src, w_src = tf.shape(hr_image)[:2]

success
    h_src = tf.shape(hr_image)[0]
    w_src = tf.shape(hr_image)[1]

finally!

h_src = tf.shape(hr_image)[0]; w_src = tf.shape(hr_image)[1]
Le mar. 23 juin 2020 à 15:01, colorful-ocean<EMAIL_ADDRESS>a
écrit :

@iobtl https://github.com/iobtl
I found the solution!
fail
h_src, w_src = hr_image.shape[:2]

fail
h_src, w_src = tf.shape(hr_image)[:2]

success
h_src = tf.shape(hr_image)[0]
w_src = tf.shape(hr_image)[1]

finally!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/40541#issuecomment-648164466,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHD3NAE4CGBWIAHVJM5H3NTRYCYTNANCNFSM4OAQAOMA
.

using tf.shape does not seems to work depending on which method will use the image shape. For instance:
working
def rnd_crop(img):
    w = tf.shape(img)[0]
    h = tf.shape(img)[1]
    c = tf.shape(img)[2]
    crop_size = (w,h,c)
    img_crop = tf.reshape(img, crop_size)
    return img_crop

not working
def rnd_crop(img):
    w = tf.shape(img)[0]
    h = tf.shape(img)[1]
    c = tf.shape(img)[2]
    crop_size = (w,h,c)
    img_crop = tf.image.random_crop(img,  crop_size)
    return img_crop

I am getting the folloring error

ValueError: Dimensions must be equal, but are 4 and 3 for '{{node random_crop/GreaterEqual}} = GreaterEqual[T=DT_INT32](random_crop/Shape, random_crop/size)' with input shapes: [4], [3].

it seems that the shape of the image in tf.image.random.crop does not has the same rank as the one returned by tf.shape...


More visual help to tell different folder levels in explorer

Folders of different levels are hard to tell from one another.
Currently, the only visual clues are:

Directions of the arrow icon
Different indent levels.

Of the two, the arrow offers more visual help to tell parents and subfolders but is still hard to tell at a glance.
The Indent levels are not very distinguishable from each other unless one looks closely, and this minimal difference will disappear when is a vertical distance between two indent levels (you lost the point of reference).
In short, I feel there is a need for settings to add more visual aid to:

tell parent from child
tell two expanded folders from each other.

Possible aids:

Divider between different folders
Different shapes or background colors for subfolders of the same parent and for different folders on the same level.

Comparison with some other IDEs (with the same set of folders expanded as the above example)

You may like to adjust your workbench.tree.indent setting, and perhaps try other values for workbench.tree.renderIndentGuides

Thank you for the detailed issue. Sorry at this time we have no plan to change the explorer indentation logic as we already allow some configuration here. If this issue shows a large community ask we may decide to re-open and revisit it in the future.

Understandable! Thanks for the replies.

@boan-anbo you might also like to try a different File Icon Theme such as https://marketplace.visualstudio.com/items?itemName=PKief.material-icon-theme

@boan-anbo you might also like to try a different File Icon Theme such as https://marketplace.visualstudio.com/items?itemName=PKief.material-icon-theme

Thanks so much! Didn't know there is File Icon. Will try it out.
As I adjusted workbench.tree.indent, I found my indent setting is only 2 (the min is 4). Perhaps my setting was touched by some plugin or theme. Having more indent made it so much better now.


KeywordDensityApp Integration

Integrate KeywordDensityApp with daytona

@Tryxns Thanks for the PR. Please sign off your commit so the check passes


Getting Error in async_security_handler_factory.py

Concerning: https://github.com/spec-first/connexion/blob/895d3d475aec60d6dbb5d62fdc833895559f32af/connexion/security/async_security_handler_factory.py#L88
It appears that when a security verification function in the server code throws an exception, we get the following error.
server  | 20220406 05:42:33.044 172 aiohttp_api:ERROR>Error handling request
server  | Traceback (most recent call last):
server  |   File "/usr/local/lib/python3.8/dist-packages/connexion/apis/aiohttp_api.py", line 55, in problems_middleware
server  |     response = await handler(request)
server  |   File "/usr/local/lib/python3.8/dist-packages/aiohttp/web_middlewares.py", line 110, in impl
server  |     return await handler(request)
server  |   File "/usr/local/lib/python3.8/dist-packages/connexion/decorators/decorator.py", line 55, in wrapper
server  |     connexion_response = await connexion_response
server  |   File "/usr/local/lib/python3.8/dist-packages/connexion/security/async_security_handler_factory.py", line 88, in wrapper
server  |     request.context['user'] = token_info.get('sub', token_info.get('uid'))
server  | AttributeError: 'coroutine' object has no attribute 'get'

If that make instance sense, then FYI, else I'll try to repro specifically.

Hi @ddurham2 , thanks for the report. The exception from the security verification function should be propagated further.
Are you on the latest version of connexion and does it occur as well on version 2.12? If so, it might be a regression introduced by #1474

It's happening in 2.13 for me.  I can check back the last two releases if you like.  I'm pretty sure prior to 2.12 it was not happening as this is a changed result in my unit test, and it looks like the whole file is pretty new.

Alright, thanks for checking! It would be great if you have a reproducible example.
Just the line where the exception is thrown in the security function and the corresponding OpenAPI security scheme could already be enough to start with.

In the code below, if an error is thrown in the line token_info = await token_info, the loop can be exited with token_info still being a coroutine, preventing the if token_info is cls.no_value: block from being triggered.
https://github.com/spec-first/connexion/blob/895d3d475aec60d6dbb5d62fdc833895559f32af/connexion/security/async_security_handler_factory.py#L68-L88
I think we can solve it by adding token_info = cls.no_value in the except block.

Or replace the token_info = cls.no_value with an else block from the for loop.

I take it that the problem is well understood enough that I don't need to create an example?

This is released in 2.13.1


build: add AC_PROG_LIBTOOL to configure.ac

It should fix the following build error with old autoconf/automake
versions:
Makefile.am:24: Libtool library used but `LIBTOOL' is undefined
Makefile.am:24: The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
Makefile.am:24: to `configure.ac' and run `aclocal' and `autoconf'
again.

Fixes: libuv#111
R=@rvagg

LGTM, FWIW. I was looking into it just now :-)

:+1: seems to work
semi-related: there are 4 test failures on EL5: https://jenkins-iojs.nodesource.com/job/libuv+any-pr+multi/23/ this is with gcc 4.8. I'll get a 4.4 build slave set up soon.


az cosmosdb throws exception trying to show throughput value

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az cosmosdb mongodb database throughput show
Errors:
Operation failed with status: 'NotFound'. Details: Entity with the specified id does not exist in the system.

ActivityId: 27fcdbe6-1b33-11ea-8a50-00155d72bc93, Microsoft.Azure.Documents.Common/2.7.0

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az cosmosdb mongodb database throughput show -g {} -a {} -n {}

Expected Behavior
Show throughput value
Environment Summary
Windows-10-10.0.19035-SP0
Python 3.6.6
Shell: cmd.exe

azure-cli 2.0.76 *

Extensions:
azure-devops 0.15.0

Additional Context

Hi @vinnytheviking thank you for opening this issue. It appears from the command that you are trying to get the offer at a database level. Is this a shared throughput database? If not, then there will be no offer at the database level. Try getting the throughput at the collection level.
az cosmosdb mongodb collection throughput show -g {} -a {} -d {} -n {}


Revert Powertoys run design

Description of the new feature / enhancement
The new design is boxy and annoying. I don't need hints every time I open it, it should just show me the search bar and nothing else. Having the results and search bar seperate was really nice too.
The old design was really good, please go back to it
Scenario when this would be used?
It would be used always
Supporting information
No response

@galaxynz On what version of PowerToys are you? Make sure to update to 0.77 so you can disable the plugin hints in settings:

The changes introduced in 0.77 allows Run to follow the Windows design guidelines. The ask here is pretty broad, so if you have any specific thoughts on what you'd like to see changes and why that would be helpful.


Exception 'undefined is not an object (evaluating 't.params.status=e.status')' on iOS Safari 16.5

Description
I have a copy/paste installation of browser-agent in my spa root-config app.
After debugging this inline-script I've just found the place where exception was thrown, but have no opportunity to debug on Safari for now.
Exception was thrown inside function stored at key 16 in the object passed to __nr_require function as the first argument.
Maybe I need to update inline script?
Steps to Reproduce
Expected Behavior
Browser-agent isn't throwing exceptions.
Relevant Logs / Console output
Source code of exception
16: [function(t, e, n) {
                  function r(t) {
                      var e = this.params
                        , n = this.metrics;
                      if (!this.ended) {
                          this.ended = !0;
                          for (var r = 0; r < d; r++)
                              t.removeEventListener(f[r], this.listener, !1);
                          e.aborted || (n.duration = i.now() - this.startTime,
                          this.loadCaptureCalled || 4 !== t.readyState ? null == e.status && (e.status = 0) : o(this, t),
                          n.cbTime = this.cbTime,
                          u.emit("xhr-done", [t], t),
                          a("xhr", [e, n, this.startTime]))
                      }
                  }
                  function o(t, e) {
                      t.params.status = e.status; <- here, e: XMLHttpRequest
                      var n = m(e, t.lastSize);
                      if (n && (t.metrics.rxSize = n),
                      t.sameOrigin) {
                          var r = e.getResponseHeader("X-NewRelic-App-Data");
                          r && (t.params.cat = r.split(", ").pop())
                      }
                      t.loadCaptureCalled = !0
                  }
                  ...
              , {}],
...

Your Environment
Browser: Safari 16.5
OS: iOS
New Relic Agent: js-agent.newrelic.com/nr-spa-1208.min.js as per page source

@paulonev Thanks for reporting this issue. Please update your copy/paste snippet from the New Relic dashboard so you have the latest version of the agent. Let me know if this resolves or not your issue. Thanks.

@paulonev Were you able to update your agent and check if the issue is still present?

@patrickhousley, script is not yet updated( It may take weeks


Audio L1 tests profile improvements

Modified Audio L1 code as per the yaml file and getting the platform specific configurations.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: thanushreevani:white_check_mark: hari22yuva:x: ishthiyaqahmedishthiyaqahmed 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.

cla issue.


Invariant Violation: OPSQLite could not be found

Description
When I attempt to use the op-sqlite to perform any operation, such as opening a connection to a db, it fails with this error:
 ERROR  Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'OPSQLite' could not be found. Verify that a module by this name is registered in the native binary., js engine: hermes

This problem may be something that I am doing wrong, or a quirk of my dev env. It seems to be saying that something went wrong in the native binary.
Versions:

MacOS Sonoma 14.3.1 on a MacBook Pro M1 Max (ARM)
Simulator iOS version: 17.0
op-sqlite version: 2.0.18
RN version: 0.72.7

Reproducible example
When I import this code sample into my app.tsx file it causes the error.
import { open } from "@op-engineering/op-sqlite"
const db = open({ name: 'myDb.sqlite' })

I'm still missing some data. It looks you might be using the new arch, which might be causing some issues. You need to create a minimal reproducible example for me to take a look at.

I got this working in my environment, and this may help others in my situation.
The version of React Native I am using, 0.72.7 is a "new arch" version but support in the native build processes is not enabled by default, there are additional steps.
As described on a separate page in the the React Native docs, to enable the the New Architecture on iOS:
RCT_NEW_ARCH_ENABLED=1 npx pod-install
npm run ios

(If first time running pod install then you will want to do this first:)
RCT_NEW_ARCH_ENABLED=1 npx expo prebuild

And for Android as described in the React Native docs, edit android/gradle.properties:
newArchEnabled=true

And then run the app to build:
npm run android
And then I am able to use op-sqlite without errors.
Perhaps this should be added to the documentation so that other people dont have the same problem.

Enabling the new arch is a general procedure for RN and does not affect op-sqlite. The module correctly links if you have enabled it and ran pod install correctly, so nothing to do here.


fixes watchos "cannot read entitlement data" build issue

documented a bit here
the only other guy I know doing watchos is not running into this issue, but I cannot build without this patch. Given that it's inert - the fix is to expand paths so they are not relative to the watch directory - I think it should be passable either way.

After updated Rake to v11.0.1, I also see same error with app which bundles Extension (Watch App, Today Extension, etc)
If build with rake v10.5.0 (or below), the app can be built without error.
I doubt this error was introduced by rake


Fix: ignore case for pre

This PR makes the prefix matching logic ignore the prefix case.
In the long run, it would be nice to support user-overrides for TAGS_METADATA_BASE instead of hard-coding to a particular set of prefixes.
I also note that the documentation mentions https://keepachangelog.com/en/1.0.0/ but the prefixes used there seem fairly different to the ones that we are currently using.

For posterity, this was a half-baked idea, and I didn't finish the PR :face_with_spiral_eyes:


Update Crossplane to v1.7.1

Updating both the chart and crossplane itself to v1.7.1. Starting from version v1.2 the CRDs are managed by the operator and not by the helm chart. Moreover, starting from version v1.6 most of the CRDs passed from v1beta1 to v1 without any changes to the CRD themselves so it is simple and safe to update them.
Checklist

[x] PR contains a single logical change (to build a better changelog).
[x] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking, dependency
as they show up in the changelog.

About the labels: Please use one of the labels as listed in the PR template checklist. Only those are recognized and included in the changelog

@ZuGao Did you actually test the upgrade? Can you say that in confidence and there's no race condition between ArgoCD removing the existing CRDs and then Crossplane re-installing it without data loss?
If ArgoCD deletes the CRDs then all deployed resources of those CRDs in Kubernetes are going to be deleted. (I didn't look if there's a CRD deletion protection mechanism enabled).

To add to that: did you check that there's no breaking changes in Crossplane between v1.1.1 and v1.7.1? Also, do we need a migration guide, or do resources which use the v1beta1 API still work?

To add to that: did you check that there's no breaking changes in Crossplane between v1.1.1 and v1.7.1? Also, do we need a migration guide, or do resources which use the v1beta1 API still work?

According the the release notes there are no breaking changes. There are version upgrades from v1beta1 or v1alpha1 to v1 for various CRDs but they are identical (check v1.5.0 and v1.6.0). Also from the release notes all v1beta1 and v1alpha1 are not supported anymore and I also checked during testing v1.7 that the providers v1beta1 are not being installed if Crossplane had the newest version.

To add to that: did you check that there's no breaking changes in Crossplane between v1.1.1 and v1.7.1? Also, do we need a migration guide, or do resources which use the v1beta1 API still work?

According the the release notes there are no breaking changes. There are version upgrades from v1beta1 or v1alpha1 to v1 for various CRDs but they are identical (check v1.5.0 and v1.6.0). Also from the release notes all v1beta1 and v1alpha1 are not supported anymore and I also checked during testing v1.7 that the providers v1beta1 are not being installed if Crossplane had the newest version.

Well, removing the v1beta1 APIs (cf. https://github.com/crossplane/crossplane/releases/tag/v1.6.0) is clearly a breaking change, as users must make sure all their custom resources are updated to use the new API version before the old version is removed.

Did you actually test the upgrade? Can you say that in confidence and there's no race condition between ArgoCD removing the existing CRDs and then Crossplane re-installing it without data loss?
If ArgoCD deletes the CRDs then all deployed resources of those CRDs in Kubernetes are going to be deleted. (I didn't look if there's a CRD deletion protection mechanism enabled).

I will have to test that. Aren't we disabling ArgoCD when there are apiVersion upgrades?

To add to that: did you check that there's no breaking changes in Crossplane between v1.1.1 and v1.7.1? Also, do we need a migration guide, or do resources which use the v1beta1 API still work?

According the the release notes there are no breaking changes. There are version upgrades from v1beta1 or v1alpha1 to v1 for various CRDs but they are identical (check v1.5.0 and v1.6.0). Also from the release notes all v1beta1 and v1alpha1 are not supported anymore and I also checked during testing v1.7 that the providers v1beta1 are not being installed if Crossplane had the newest version.

Well, removing the v1beta1 APIs (cf. https://github.com/crossplane/crossplane/releases/tag/v1.6.0) is clearly a breaking change, as users must make sure all their custom resources are updated to use the new API version before the old version is removed.

Well it seems my definition of breaking change was wrong. Nevertheless the API changes were specified in the main comment. Also I thought that we already have some kind of migration guide of API version with identical CRDs.

Aren't we disabling ArgoCD when there are apiVersion upgrades?

I guess only when you mention it explicitly in the Upgrade how-to page.


Work pool

I'm using sentry on top of tornado.
I notice that in old sdk (raven), the action of sending http request to sentry server is a coroutine that could be put in tornado.ioloop.
However, in the new sdk, the implementation is using multi-threading to send request.
Is this a intended design?
I'm concerning that multi-threading is heavier than coroutine when do context-switch.

@SEKIRO-J We wanted to avoid making the SDK depend on the code that it monitors (if tornado crashes before the ioloop starts, the old SDK will not send any data), and also because one implementation of the transport is easier to debug and maintain than multiple. The assumption is that the average application does not send so many errors.
We're not 100% convinced by this decision but it was a conscious one.

To clarify, if this slows down your application performance it's unacceptable.

Thanks, that explains my questions.

That's great to hear!


Improvement: option to remove inline-svg style block

Inserting a style block for inline-svg mode, even when
mermaidConfig: {
   theme: "null" | null,
}

is set requires additional transformer for removing the style block.

I don’t understand what you mean. Can you elaborate?

I updated the initial post.

@Caellian  hey 👋 . I have a question - do you intend to inline SVGs in HTML and later style them with your own styles? And if yes, does it mean it would be possible to create styles for light and dark themes in CSS (without changing HTML contents)?

@Caellian hey 👋 . I have a question - do you intend to inline SVGs in HTML and later style them with your own styles? And if yes, does it mean it would be possible to create styles for light and dark themes in CSS (without changing HTML contents)?

Yes, yes, depends.
Styles in mermaid are defined in /packages/mermaid/src/diagrams/class/styles.js files. I'm running a rehype from a static context in Node so I can (worst case) glob diagram types, append /styles.js and then use dynamic imports.
Diagram types can be detected using detectors in /packages/mermaid/src/diagrams/sankey/sankeyDetector.ts.
Now, it's questionable whether I'll be able to use mermaid directly or I'll have to handle these on a case-by-case basis (which is fine; 5min of work per diagram type).
I have a [data-scheme="dark"] on my document body so I can run all detectors until I find which diagram I'm visiting, replace the id with a class ("diagram flowchart-v2") and then generate selectors for each.
My use case can't break in "production" as the page won't get published if my logic fails because some diagram isn't properly handled (i.e. got updated), I don't suggest this approach to be used when running unified dynamically though because it will silently fail - in my case, all the content that's ever processed acts as a conformance test so I know about edge cases up front.

There is no such thing as a null theme. The theme affects layout the generated diagram, including colors, font, borders, spacing, etc.
If I understand correctly, you are asking for an option that removes the <style> element in the diagram after processing. However, this relies on an implementation detail. Mermaid adds some styling via the <style> tag. Some style is inlined in style attributes. Other styling happens via attributes.
I don’t want to add an option to postprocess the SVG. It has proven to be fragile in the past. If you really need to, you can use a custom rehype plugin to do so.
If I don’t understand correctly and you want something else, please elaborate with an example showing input and output, for example based on one of the test fixtures in this repository.

Inlined styles are only used by layouting and generator and shouldn't be changed, i.e. styling (as in colors, fonts, backgrounds, ...) is done entirely through the css. The only information that's inserted directly into attributes is stuff like "stroke-dasharray" where it's important for semantics of the drawn graph that the stroke is dashed (for instance).
In other words, it's entirely possible to recolor the graph by replacing the old <style> with a new one.
If you run the graph through svgo (like you said you did), then svgo will likely break things, but generating a <style> should be lossless and work AFAICT.
It's possibly (probably) out of scope though and should be submitted to mermaid.js directly though.


Organization rename to stolostron

https://github.com/stolostron/backlog/issues/18780

/cherry-pick release-2.4

/cherry-pick release-2.3


Remove the rule that replaces a union of literal types with the base type when comparing equality to a type that isn't a union of literal types.

The rule is redundant because a primitive type is already directed-
comparable to a value of that primitive type, and it causes errors to be
missed when comparing a type parameter constrained by a union of
literal types to another union of literal types.
The baseline changes look like improvements to me.
Fixes #26758.

Updated to master.


Limit "View graph" depth in the Catalog Graph Card

Hey, I just made a Pull Request!
Closes #10524

I added "viewGraphDepth" as an optional prop to CatalogGraphCard which value is then embedded into the query string in the "View graph" buttons destination URL.
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[x] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Closes #10524

Thanks for this! Just a though on Wondering if it would be good to still support having the ability to view all, but basically limit what you can see until you click on CTA which is like Collapsed some nodes as it looks like there's a lot, click here to view all?

Thought I would chime in as I'm working on the same team as @weid-h.
So this doesn't actually limit view depth of the graph on entity overview page but on the CatalogGraphPage where user is taken when "View graph" link is clicked. For limiting view depth of the graph on entity page there's already maxDepth prop that can be passed to EntityCatalogGraphCard. That being said, would it be better to use this existing prop and pass it also as a query parameter instead of creating a new prop?
What comes to displaying the full graph, CatalogGraphPage already provides pretty fine grained control how the graph is visualized including limiting the depth of it. Creating a CTA for expanding the graph on entity page sounds like a good addition but is out of this PR's scope in my opinion.

Hey! This seems to have hit a conflict. Rebasing on latest master should get rid of the odd build error too.
So how do we proceed? Is the new prop needed or can the old max depth be leveraged?

fix up conflicts?


Letterbox background issue

Hi guys,
I'm having an issue.
See: http://prntscr.com/jyokzp
This is the image I am processing.
https://images.weserv.nl/?url=production-eu01-omodaschoenenbv.demandware.net/dw/image/v2/BCCT_PRD/on/demandware.static/-/Sites-omoda-master/default/dw257aebd2/21/P37921/80171_2_02.png&output=jpg&w=1200&h=800&bg=white&t=letterbox
So now the size, the format and quality are okay but it fills the image with black background instead of white.
Is there a way to combine these functions as to get a 1200 x 800 image with white background all over?
Thanks in advance.
Olaf van Gessel

@kleisauke is working on this as we speak, the problem has been located, he will try to push a fix today!
Nice job in finding this issue, as it's quite specific 👍

Lol, thx. It was not my intention ;-) Groet, Olaf-------- Oorspronkelijk bericht --------Onderwerp: Re: [weserv/images] Letterbox background issue (#137)Van: Andries Louw Wolthuizen Aan: weserv/images Cc: ogessel ,Author @kleisauke is working on this as we speak, the problem has been located, he will try to push a fix today!
Nice job in finding this issue, as it's quite specific 👍
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.
{"@context":"http://schema.org","@type":"EmailMessage","potentialAction":{"@type":"ViewAction","target":"https://github.com/weserv/images/issues/137#issuecomment-399751905","url":"https://github.com/weserv/images/issues/137#issuecomment-399751905","name":"View Issue"},"description":"View this Issue on GitHub","publisher":{"@type":"Organization","name":"GitHub","url":"https://github.com"}}
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/weserv/images","title":"weserv/images","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/weserv/images"}},"updates":{"snippets":[{"icon":"PERSON","message":"@andrieslouw in #137: @kleisauke is working on this as we speak, the problem has been located, he will try to push a fix today!\r\nNice job in finding this issue, as it's quite specific 👍"}],"action":{"name":"View Issue","url":"https://github.com/weserv/images/issues/137#issuecomment-399751905"}}}
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [weserv/images] Letterbox background issue (#137)",
"sections": [
{
"text": "",
"activityTitle": "Andries Louw Wolthuizen",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@andrieslouw",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "IssueComment",\n"repositoryFullName": "weserv/images",\n"issueId": 137,\n"IssueComment": "{{IssueComment.value}}"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "IssueClose",\n"repositoryFullName": "weserv/images",\n"issueId": 137\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/weserv/images/issues/137#issuecomment-399751905"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "MuteNotification",\n"threadId": 349468214\n}"
}
],
"themeColor": "26292E"
}

Fix (2e9b847) has been rolled out to production.
Cache has been invalidated for the particular image. If you want, you can send us an email with the images that are affected by this bug and need to be purged from cache.
Thanks for reporting!

Top!
Dank voor de snelle actie, super 😊
Groet,
Olaf
Van: Kleis Auke Wolthuizen<EMAIL_ADDRESS>Verzonden: zondag 24 juni 2018 20:03
Aan: weserv/images<EMAIL_ADDRESS>CC: ogessel<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Onderwerp: Re: [weserv/images] Letterbox background issue (#137)
Fix ( https://github.com/weserv/images/commit/2e9b84753e3c5172c5e95d74d9f53553f7304632 2e9b847) has been rolled out to production.
Cache has been invalidated for the particular image https://images.weserv.nl/?url=production-eu01-omodaschoenenbv.demandware.net/dw/image/v2/BCCT_PRD/on/demandware.static/-/Sites-omoda-master/default/dw257aebd2/21/P37921/80171_2_02.png&output=jpg&w=1200&h=800&bg=white&t=letterbox . If you want, you can send us an email<EMAIL_ADDRESS>with the images that are affected by this bug and need to be purged from cache.
Thanks for reporting!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/weserv/images/issues/137#issuecomment-399775334 , or mute the thread https://github.com/notifications/unsubscribe-auth/AbnRWH-vmX1bMA7FsSWtrEfbIyke1vunks5t_9RvgaJpZM4U1HY2 .  https://github.com/notifications/beacon/AbnRWESrFGbRscDz2cFG9L19A2M6AQCcks5t_9RvgaJpZM4U1HY2.gif

Servers receives HTTP 403:
   Der Zugriff auf den Shop wurde automatisch eingeschränkt, da die maximale Anzahl von aktiven Shop Usern bereits erreicht
   wurde. Sobald die aktiven Shop User ihren Checkout abgeschlossen haben, lässt der Server automatisch neue Zugriffe auf den
   Onlineshop zu. Wir bitten dich daher, den Shop zu einem späteren Zeitpunkt erneut zu besuchen.

   Danke für dein Verständnis - BSTN salutes you!

   Unfortunately our online shop has reached the maximum number of active shop users. As soon as active shop users complete their
   checkout, the server will grant access to new shop users. We kindly ask you to visit the website at a later date.

   Thanks for your understanding - BSTN salutes you!

PS: ik zal ook aan BSTN vragen of ze jullie kunnen whitelisten.
Groet,
Olaf
Van: Olaf van Gessel<EMAIL_ADDRESS>Verzonden: dinsdag 27 november 2018 11:28
Aan: 'weserv/images'<EMAIL_ADDRESS>'weserv/images'<EMAIL_ADDRESS>CC: 'Author'<EMAIL_ADDRESS>Onderwerp: RE: [weserv/images] Letterbox background issue (#137)
Hoi Andries,
Dank voor de toelichting.
Maar hoe kan het dan dat de gewone url en de site het wel doen? https://www.bstn.com/files/image/id/67765/fixed/1/w/1000/h/1000/n/67765.jpg en https://www.bstn.com/nl
Blijkbaar sluit ie WeServ uit maar andere browsers/IP’s niet?
Ik heb dit soort meldingen wel eerder gezien van webshops (Nike vooral), maar meestal is dat omdat ze vinden dat een partij te vaak een query doet en is jullie IP/url geband.
Cookies weggooien kan nog wel eens helpen maar dat is geen duurzame oplossing natuurlijk. Met andere headers e.d. is eea soms wel op te lossen heb ik begrepen.
Maar goed, ik ga er dus vanuit dat dit niet gaat werken via WeServ?
Groet,
Olaf
Van: Andries Louw Wolthuizen<EMAIL_ADDRESS><EMAIL_ADDRESS>>
Verzonden: dinsdag 27 november 2018 11:15
Aan: weserv/images<EMAIL_ADDRESS><EMAIL_ADDRESS>>
CC: ogessel<EMAIL_ADDRESS><EMAIL_ADDRESS>>; Author<EMAIL_ADDRESS><EMAIL_ADDRESS>>
Onderwerp: Re: [weserv/images] Letterbox background issue (#137)
Servers receives HTTP 403:
Der Zugriff auf den Shop wurde automatisch eingeschränkt, da die maximale Anzahl von aktiven Shop Usern bereits erreicht
wurde. Sobald die aktiven Shop User ihren Checkout abgeschlossen haben, lässt der Server automatisch neue Zugriffe auf den
Onlineshop zu. Wir bitten dich daher, den Shop zu einem späteren Zeitpunkt erneut zu besuchen.
Danke für dein Verständnis - BSTN salutes you!
Unfortunately our online shop has reached the maximum number of active shop users. As soon as active shop users complete their
checkout, the server will grant access to new shop users. We kindly ask you to visit the website at a later date.
Thanks for your understanding - BSTN salutes you!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/weserv/images/issues/137#issuecomment-442003576 , or mute the thread https://github.com/notifications/unsubscribe-auth/AbnRWF5RfDRsPIRBLN1QgEMlWJ6iyWRcks5uzRC3gaJpZM4U1HY2 .  https://github.com/notifications/beacon/AbnRWPBzFQj_PtqI9bc5Z25cpqu4VBvPks5uzRC3gaJpZM4U1HY2.gif

Dag Olaf, even in het Engels, zodat ook anderen iets hebben aan de info;
By default our proxy ignores all cookies, it doesn't send referrers, ignores robots.txt, uses an identifiable user-agent (ImageFetcher) and always origins from the same IP-address (<IP_ADDRESS> / 2001:bc8:2bd3:100::).
For this particular case I checked if BSTN will reply by using a different user-agent, or accepting cookies/referrers. Unfortunately it looks like there is a ban/traffic-rule on the origin IP-address.

Hoi Andries,
Thanks.
Ik ga ze vragen om jullie IP te whitelisten.
Groet,
Olaf
Van: Andries Louw Wolthuizen<EMAIL_ADDRESS>Verzonden: dinsdag 27 november 2018 12:07
Aan: weserv/images<EMAIL_ADDRESS>CC: ogessel<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Onderwerp: Re: [weserv/images] Letterbox background issue (#137)
Dag Olaf, even in het Engels, zodat ook anderen iets hebben aan de info;
By default our proxy ignores all cookies, it doesn't send referrers, ignores robots.txt, uses an identifiable user-agent (ImageFetcher https://udger.com/resources/ua-list/bot-detail?bot=ImageFetcher ) and always origins from the same IP-address (<IP_ADDRESS> / 2001:bc8:2bd3:100::).
For this particular case I checked if BSTN will reply by using a different user-agent, or accepting cookies/referrers. Unfortunately it looks like there is a ban/traffic-rule on the origin IP-address.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/weserv/images/issues/137#issuecomment-442019145 , or mute the thread https://github.com/notifications/unsubscribe-auth/AbnRWDoe8NWQCFssN0r5Tj74gckMjXJAks5uzRzSgaJpZM4U1HY2 .  https://github.com/notifications/beacon/AbnRWFSLbJlPbZMC_O33qajVj1t934rBks5uzRzSgaJpZM4U1HY2.gif


Best way to stop server

I'm using Springboot and as shutdown hook I have the following:
    @PreDestroy
    fun stopIO() {
        server.stop()
    }

but when I restart the server I get that the address is in use for about 30s which makes the developing experience very frustrating.
How can I properly shutdown the server so everything closes before the app exits?
Full implementation:
@Service
class SocketIO constructor(
        @Value("\${server.port}") val port: Int
) {

    lateinit var server: SocketIOServer

    @PostConstruct
    fun serverBean() {
        val configuration = com.corundumstudio.socketio.Configuration()
        configuration.port = port + 1
        configuration.hostname = "localhost"
        configuration.origin = "http://localhost:8080"

        server = SocketIOServer(configuration)
        server.start()
    }

    @PreDestroy
    fun stopIO() {
        server.stop()
    }
}

@Component
@Slf4j
public class ServerRunner implements CommandLineRunner, ApplicationListener<ContextClosedEvent> {

    @Bean
    public SocketIOServer socketIOServer() {
        Configuration config = new Configuration();
        config.setPort(port);
        server = new SocketIOServer(config);
        return server;
    }

    @Override
    public void run(String... args) {
        server.start();
    }
    @Override
    public void onApplicationEvent(ContextClosedEvent event) {
        server.stop();
    }
}

You can implement ApplicationListener interface and when the container stoped , a ContextClosedEvent event will be published.

@PreDestroy
private void autoStop() {
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
stop();
}));
}

@PreDestroy
private void autoStop() {
Runtime.getRuntime().addShutdownHook(new Thread(() -> {
stop();
}));
}

None of the proposed answers seem to work. Does stop() actually blocks execution and frees the port?

None of the proposed answers seem to work. Does stop() actually blocks execution and frees the port?

None of the proposed answers seem to work. Does stop() actually blocks execution and frees the port?
Which netty-socketio' version you  use?
You can upgrade netty-socketin,
e.g.

com.corundumstudio.socketio
netty-socketio
1.7.18

No change your code, No problem, Older version may be have bug.

None of the proposed answers seem to work. Does stop() actually blocks execution and frees the port?
Which netty-socketio' version you  use?
You can upgrade netty-socketin,
e.g.

com.corundumstudio.socketio
netty-socketio
1.7.18

No change your code, No problem, Older version may be have bug.

You can try to use, netty-socketio, 1.7.18,  older version maybe has bug

You can try to use, netty-socketio, 1.7.18,  older version maybe has bug

You can try to use, netty-socketio, 1.7.18, older version maybe has bug

Using version 1.7.19, the log prints SocketIO server stopped,but the port have not been freed

Hi there :)
Any updates on it?
We're using version 2.0.2 and still have this issue...


Excel changes not reflected when clicking preview

Excel is lazy in saving changes made in the UI back to SharePoint before users click preview, most of the time they won't see their latest changes reflected. One way to work around this would be to always refresh the window before fetching the content.

:tada: This issue has been resolved in version 6.16.0 :tada:
The release is available on:

GitHub release
v6.16.0

Your semantic-release bot :package::rocket:


[CU-86b2hy974] promoted commandss out of alpha

Task linked: CU-86b2hy974 Promote Instrument integration commands out of alpha


Hebrew words are cut in the bottom of last line

In my app I have sentence with full screen width on a welcome screen.
When text is in a Hebrew language the words are cut in the bottom of last line.
Adding bottom padding or setting clipToPadding/clipChildren don't help.
Can't use the Google autosizing TextView because it still has a "breaking the words issue".

Yes, I know it has issues, and that Google has even worse issues.
Sadly I'm not familiar anymore with the code I've put here.
If you know how to fix it, please show a sample that shows the issue, and that indeed you solved it.
Also, please consider writing about auto-resizing of font size of Google in its own issue tracker:
https://issuetracker.google.com/issues
BTW, I also know Hebrew (my main language), and I know it's even more problematic :(


Users able to export pdf and echo assembly instructions

Hi @hainesm6 would it be possible to update basicsynbio to 0.2.0 with the pdf and echo functionality included, this would help me complete this task, thanks

Here's v0.3.0 @Benedict-Carling 🎆 🍾

Thanks @hainesm6 I have the export echo instructions working, however I have ran into another issue on exporting pdfs in the backend, its because the latest PyPI version 0.3.0 doesn't contain csv_xlsx_files/clip_master_mix.csv which is needed when
COMPONENTS = pd.read_csv("csv_xlsx_files/clip_master_mix.csv")

we could add csv files to out manifest.ini by adding
include ./csv_xlsx_files/*.csv

I think everything included might need to be inside the basicsynbio folder in which case
include ./basicsynbio/csv_xlsx_files/*.csv

another option would be to include the contents of the csv as a pandas array directly In the code
COMPONENTS = pd.array([
        'Component','Volume per clip (µL)',
        'Promega T4 DNA Ligase 10x Buffer','3',
        'Water','15.5',
        'NEB BsaI-HFv2','1',
        'Promega T4 DNA Ligase','0.5'
], dtype=str)

Im happy to work on this and make a pull request into basicsynbio with the solution but let me know which one you think is best, I think the final idea is the simplest.

Hi @Benedict-Carling! I think the second solution where we just hard code the COMPONENTS constant makes the most sense. It's not much data and it won't change so no need for a seperate csv file. I'll keep an eye out for the pull-request 😁

Ok we've now got v0.4.0 🎆

Completed


Show tab values with WHERE clause doesn't accept double quotes

NOTE: This bug is now at least 3 1/2 years old.

System info:
Raspberry Pi, Rasbian Stretch. Arm v7.
InfluxDB v1.7.7
Steps to reproduce:
Note that this bug is referenced in two closed previous issues but nothing has been done to fix it:
https://github.com/influxdata/influxdb/issues/5245
https://github.com/influxdata/influxdb/issues/10493

Create database with values and tags
Attempt to show tag values but exclude a specific value
Try with the tag value wrapped in single and double quotes

Expected behavior:
Result should be the same whether using single or double quotes.
Actual behavior:
Using double quotes fails to exclude the entry.
 Wrapping the WHERE clause test value in double quotes causes the clause to be ignored.

Come on guys, surely this can't be that hard to fix? It is a pain that causes much user confusion.


Add design doc for supporting private terraform modules

Doc : https://github.com/radius-project/design-notes/blob/81030c213f17235258545ccada73ae728ae07782/recipe/2024-01-support-private-terraform-repository.md

Notes : 01/09/2024

We decided that option 3 of using Application.Core/secretStores is the better approach to store git credentials but since today its application scoped we may need to make few changes to the secret store implementation.
Next steps is to investigate on the design for secret store changes.
Verify the public repo url as module source works while running terraform init on the cluster.


Update dependency version

Reduce vulnerability, also update tap version and test script.

Sorry for waste your time...my mistake.
But, I thought other dependency need to update if CI build pass, let dependency update progressively..


cmd/compile: misleading PC <> line number with "for {}"

What version of Go are you using (go version)?

$ go version
go1.12beta2

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/pwaller/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/pwaller/.local"
GOPROXY=""
GORACE=""
GOROOT="/home/pwaller/.local/src/go"
GOTMPDIR=""
GOTOOLDIR="/home/pwaller/.local/src/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build478432202=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Compiled the following program:
package main

func main() {
	go func() {}()

	for {}
}

What did you expect to see?
I expected the infinite for loop in the binary to be correctly mapped to the source.
What did you see instead?
The for loop is on line 6 in the source, but in the binary at 0x44f0d5, where there is a "jmp-to-self", it is shown by go tool objdump at main.go:4.
$ go1.12beta2 build && go tool objdump -s main.main misleading-debuginfo

TEXT main.main(SB) .../misleading-debuginfo/main.go
  main.go:3		0x44f0a0		64488b0c25f8ffffff	MOVQ FS:0xfffffff8, CX
  main.go:3		0x44f0a9		483b6110		CMPQ 0x10(CX), SP
  main.go:3		0x44f0ad		7628			JBE 0x44f0d7
  main.go:3		0x44f0af		4883ec18		SUBQ $0x18, SP
  main.go:3		0x44f0b3		48896c2410		MOVQ BP, 0x10(SP)
  main.go:3		0x44f0b8		488d6c2410		LEAQ 0x10(SP), BP
  main.go:4		0x44f0bd		c7042400000000		MOVL $0x0, 0(SP)
  main.go:4		0x44f0c4		488d05fd420200		LEAQ 0x242fd(IP), AX
  main.go:4		0x44f0cb<PHONE_NUMBER>		MOVQ AX, 0x8(SP)
  main.go:4		0x44f0d0		e82bd1fdff		CALL runtime.newproc(SB)
  main.go:4		0x44f0d5		ebfe			JMP 0x44f0d5
  main.go:3		0x44f0d7		e8d47effff		CALL runtime.morestack_noctxt(SB)
  main.go:3		0x44f0dc		ebc2			JMP main.main(SB)

Additional thinking
I encountered this while diagnosing https://github.com/golang/tools/pull/74 - an issue causing 100% CPU usage unnecessarily. Because the mapping was incorrect, I did not immediately discover the for {} (I wasn't expecting it).
In the example above, the "infinite for" is not far away from its correct location, but it is easy to imagine them being quite distant (for example if the goroutine had a substantial chunk of code in it).
I realize that a precise PC <> line number in general might be too much to ask for. But it seems worth asking, and if it is too much, at least this issue serves to document some discussion.
@gopherbot please add label Debugging.
/cc @ianlancetaylor who likely knows about these things.

$ go build -gcflags=-K
# .../faulty-debuginfo
./main.go:6:2: prog: unknown position (line 0)

Interesting. I'm taking a closer look. Added some tracing to the compiler at it seems like the correct position is known, and then later lost.

I had a look, and learned a little, but haven't solved it.

The line number shown in the unknown position warning (which is correct) is: https://github.com/golang/go/blob/e1b49ad608c0b51acf75f8248e1167acbbcb5d30/src/cmd/compile/internal/gc/lex.go#L17
If I do b.pp.pos = lineno in the "unknown position if-block" (source immediately below), then I get what I expected in the binary. I'm guessing there is a good reason this value isn't used, but I'm not sure why not. I guess lineno is meant to go away eventually. https://github.com/golang/go/blob/e1b49ad608c0b51acf75f8248e1167acbbcb5d30/src/cmd/compile/internal/gc/gsubr.go#L133-L135

I looked into the numberlines pass. The block in question isn't being assigned to. I guess the problem is that since the block doesn't have any values, there isn't an obvious place to grab a pos from during numberlines. So the for block falls through this continue here: https://github.com/golang/go/blob/e1b49ad608c0b51acf75f8248e1167acbbcb5d30/src/cmd/compile/internal/ssa/numberlines.go#L134

If I assign the for loop body pos to the node pos (bBody.Pos = n.Pos) in ssa.go func (s *state) stmt(n *Node), I get the right result in the output. Is this a reasonable thing to do? https://github.com/golang/go/blob/e1b49ad608c0b51acf75f8248e1167acbbcb5d30/src/cmd/compile/internal/gc/ssa.go#L1069

/cc @dr2chase from the git log. Is option (3) a reasonable thing to do? If so, I'll send a CL. If not, if you point me in the right direction I'd attempt to fix it.

Option (3) is worth a look.
To see how stuff proceeds through the sausage factory, set environment variable GOSSAFUNC=main before building, and look at ssa.html in a (Javascript-enabled) browser.
Our current and inadequate test for line assignment is in cmd/compile/internal/ssa/debug_test.go
gdb: go test -v debug_test.go -args -f
dlv: go test -v debug_test.go -args -f -d
(If you're on a Mac, you need -f, assuming you have gdb or ggdb on you path).
It's fragile, sometimes it hangs, I'm supposed to be working on that.
The "golden" files are more like brass, so you need to review any differences, they might be better.

I considered testing along the lines of the existing tests, but of course we can't step a debugger through an infinite for loop until it completes. I'd be tempted to inspect the output of go tool objdump in this case, but I have no idea whether that is appropriate as part of the compiler test suite, given that it would be relatively expensive.
The following patch fixes the issue. I'll leave it here for now and I'll submit it once the tree opens.

Patch
commit 5cfec30c9b2e1f52321ce94b93a111a0b25ee23c (HEAD -> issue-30167)
Author: Peter Waller<EMAIL_ADDRESS>Date:   Mon Feb 11 15:09:24 2019 +0000

    cmd/compile/internal/ssa: set OFOR bBody.Pos to AST Pos

    Assign SSA OFOR's bBody.Pos to AST (*Node).Pos as it is created.

    An empty for loop has no other information which may be used to give
    correct position information in the resulting executable. Such a for
    loop may compile to a single `JMP *self` and it is important that the
    location of this is in the right place.

    Fixes #30167.

diff --git a/src/cmd/compile/internal/gc/ssa.go b/src/cmd/compile/internal/gc/ssa.go
index 6ddc9fba7a..d399752782 100644
--- a/src/cmd/compile/internal/gc/ssa.go
+++ b/src/cmd/compile/internal/gc/ssa.go
@@ -1071,6 +1071,9 @@ func (s *state) stmt(n *Node) {
                bIncr := s.f.NewBlock(ssa.BlockPlain)
                bEnd := s.f.NewBlock(ssa.BlockPlain)

+               // ensure empty for loops have correct position; issue #30167
+               bBody.Pos = n.Pos
+
                // first, jump to condition test (OFOR) or body (OFORUNTIL)
                b := s.endBlock()
                if n.Op == OFOR {


Closure compiler chokes on LitElement

When I try to use Closure Compiler on code that uses LitElement, I get the error The class in an extends clause must be a qualified name. It looks like this is a known issue for Closure: https://github.com/google/closure-compiler/issues/2650 but unclear if/when they are planning to address it.

Hey @sorvell et al - any updates on this? Thanks!

Cross-posting from #93: this appears to be a limitation of Closure https://github.com/google/closure-compiler/issues/1876#issuecomment-231138616

Closing this per the above comment. Sadly we are not able to fix this issue 😢


Make report propagation more reliable

Fixes #458, fixes #467

Make scope push the reports asynchronously
Backoff when report push fails

The problem was we were pushing reports on the main probe thread, one-by-one.  If one of the ips was unreachable, it would block the pushing of all others, and the probe would stall and the UI go blank.  And tcp connection time out is quite long.

When full, this seems to attempt to throw away new reports, and keep retrying the original one which failed. Don't we really only care about the latest report?

We don't retry the sending of any reports - why do you think it does?

You are right, misread the backoff waiting bit.

Aside from making the http handler cancel the existing request (if that is important), LGTM.


feat: support for Kubernetes-based deployment

This is the first version of Kubernetes based deployment.  This PR contains kubernetes YAML configuration files.   If this work is in alignment with the owners, I can go ahead and create Helm chart for easy installation of Datahub on Kubernetes.  Open for feedback.  Thank you.

This PR contains the basic Kubernetes YAML files.  In the next PR (currently working), I'll provide the helm charts and update the README accordingly.  If everything is good, can this PR be merged?


prithul data add

Added data and avatar image for Prithul

👷 Deploy Preview for bsa-unr processing.

Name
Link

🔨 Latest commit
cb557bdb59abf07a560f98efc047490b4dcdef2d

🔍 Latest deploy log
https://app.netlify.com/sites/bsa-unr/deploys/62787cdc07e40000081e7a81


remove support for python36

ref #59

Codecov Report

Merging #60 (9d622b6) into master (afc38d9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #60   +/-   ##
=======================================
  Coverage   99.11%   99.11%
=======================================
  Files          30       30
  Lines         679      679
=======================================
  Hits          673      673
  Misses          6        6

Flag
Coverage Δ

unittests
99.11% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update afc38d9...9d622b6. Read the comment docs.


Feature Python 2 Compatibility

Resolves: #5

Please note, that the travis build now includes python 2.7: https://travis-ci.org/target/matrixprofile-ts/jobs/475402825


config:push > This action could not be completed due to a conflict.

At first, I thought this was a bug, but then I noticed the error only showed up if the local config file was the same as the remote config.
It would be nice if the error was a bit more descriptive.

Can you paste the error here?
The controller returns a "nothing changed" message. https://github.com/deis/controller/blob/master/rootfs/api/models/release.py#L495 So I want to verify. Suspecting the CLI might munge it

Yep: https://github.com/deis/controller-sdk-go/blob/b269b5ed0f744b8c5f97898272fdeb43dea8af66/errors.go#L54

Yep, that's indeed the error returned, thanks for looking into this. I'll close this one, since there's an issue in place at the correct repository 👍


Used colors of output is unusable with dark mode

I run 'tmt' command in main directory of this git repo and it was very hard to read the output because the red color is too dark for terminal in dark mode (screenshot attached).

I believe that when tmt uses click (and click uses colorama), it's not using 256 color or truecolor, it uses the base 16 colors. I mean, it doesn't instruct the terminal to output stuff in this particular dark shade of red, it just uses a base 'red' color, which is effectively picked up from your terminal settings. And these are supposed to be readable on your background, and if they are not, it's a terminal misconfiguration.
That being said, configurable color support or at least a way to disable it would be nice.

Yes, agree with @t184256. It should be possible to fine-tune color in your terminal to make them more readable. Coloring is disabled by default when not attached to a terminal, so tmt | cat can be used as a quick workaround. We should also make this easily configurable.

Hello. Do we have any idea how to configure tmt via config file or something similar?
If is still free, I would like to take it and maybe search for another similar issues which needs some type of configuration on tmt side.

Ok. Looks like config approach is described here:
https://github.com/psss/tmt/issues/84

I mean, it doesn't instruct the terminal to output stuff in this particular dark shade of red, it just uses a base 'red' color, which is effectively picked up from your terminal settings. And these are supposed to be readable on your background, and if they are not, it's a terminal misconfiguration.

This is a very good point. @schidlo, can you confirm that adjusting your terminal color palette fixes the issue?

That being said, configurable color support or at least a way to disable it would be nice.

Color disabling can be done using the NO_COLOR variable. See man tmt for more info.

Hi.
@schidlo just pinging around. Is your issue solved?


Arrow keys don't work

After clean installing alwsl I found that the arrow keys don't work in Arch. For example, I can't use left/right to move the text edit location on the command line.
This was found when using bash in ConEmu. Note that the same issue didn't exist when using the standard Ubuntu WSL in ConEmu.

I have the same issue as well. It also means I am unable to use up/down to traverse command history as well.

This was found when using bash in ConEmu. Note that the same issue didn't exist when using the standard Ubuntu WSL in ConEmu.

Yes it does. This is not related to alwsl, but how bash.exe hosts the console. ConEmu does not integrate this mode, it simply fakes the window (the same thing happens if you use PuTTY in ConEmu). See #25 .


⚠ Bofrost.be has degraded performance

In 7e304fd, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1656 ms

Resolved: Bofrost.be performance has improved in 2969187.


asyncio.Queue does not take loop Argument with python >=3.11

The AMQPLogHandler inits an asyncio.Queue with an loop argument which is not accepted  from python 3.11 onwards

closed by e6e1f2a


Fix avatar cutoff on update stories

Before:

After:

Why border-radius: 100% over border-radius: 999em? The latter is superior iirc.