Test crash/hangs - Catalyst Instance has already disappeared

What happened?
The same error happens sporadically. So far around 4-5 out of 25-ish runs. (Always the same spec)
Small piece of the logs:
11-21 04:30:45.164  2439  2756 I ReactNative: [GESTURE HANDLER] Tearing down gesture handler registered for root view com.facebook.react.ReactRootView{fdb8e31 V.E...... ......ID 0,0-1080,2028}
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: Unhandled SoftException
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by DeviceInfo
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:66)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at com.facebook.react.modules.deviceinfo.DeviceInfoModule.invalidate(DeviceInfoModule.java:114)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at com.facebook.react.bridge.ModuleHolder.destroy(ModuleHolder.java:110)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at com.facebook.react.bridge.NativeModuleRegistry.notifyJSInstanceDestroy(NativeModuleRegistry.java:108)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at com.facebook.react.bridge.CatalystInstanceImpl$1.run(CatalystInstanceImpl.java:368)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at android.os.Handler.handleCallback(Handler.java:883)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at android.os.Handler.dispatchMessage(Handler.java:100)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at androidx.test.espresso.base.Interrogator.loopAndInterrogate(Interrogator.java:14)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at androidx.test.espresso.base.LooperIdlingResourceInterrogationHandler$2.run(LooperIdlingResourceInterrogationHandler.java:3)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at android.os.Handler.handleCallback(Handler.java:883)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at android.os.Handler.dispatchMessage(Handler.java:100)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at android.os.Looper.loop(Looper.java:214)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:228)
11-21 04:30:45.164  2439  2756 E unknown:ReactContextBaseJavaModule: 	at java.lang.Thread.run(Thread.java:919)
11-21 04:30:45.165  2439  2756 E unknown:ReactContextBaseJavaModule: Unhandled SoftException
11-21 04:30:45.165  2439  2756 E unknown:ReactContextBaseJavaModule: java.lang.RuntimeException: Catalyst Instance has already disappeared: requested by NativeAnimatedModule
11-21 04:30:45.165  2439  2756 E unknown:ReactContextBaseJavaModule: 	at com.facebook.react.bridge.ReactContextBaseJavaModule.getReactApplicationContextIfActiveOrWarn(ReactContextBaseJavaModule.java:66)
11-21 04:30:45.165  2439  2756 E unknown:ReactContextBaseJavaModule: 	at com.facebook.react.animated.NativeAnimatedModule.invalidate(NativeAnimatedModule.java:1012)

What was the expected behaviour?
To pass.
We do not ever experience this crash when developing on the emulator, nor on real test devices. ONLY in e2e + detox.
Google results didn't help so much.. Some older RN issues only.
Was it tested on latest Detox?

[X] I have tested this issue on the latest Detox release and it still reproduces.

Did your test throw out a timeout?

[x] ~I have followed the instructions under Identifying which synchronization mechanism causes us to wait too much~ not a timeout.

Help us reproduce this issue!
No response
In what environment did this happen?
Detox version: 20.0.1
React Native version: 0.70.4
Node version:
Device model: Pixel 3 Emulator
Android version: 29
Detox logs
https://gist.github.com/kg-currenxie/3af61f109303a2e7acedb9e8b8c941ee
Device logs
https://gist.github.com/kg-currenxie/925fd5694232fdebfb0341fc10611110
More data, please!
Just hangs after 21s:
https://user-images.githubusercontent.com/48229166/203095438-9838b318-b86d-438f-80bc-3d22f5d764ec.mp4

Hey, so I've cross checked the video, logs and trace artifacts from both here and #2655. I don't believe Catalyst Instance has already disappeared is your problem.

Thx for the time and research :) Interesting.. will have to dig deeper
The screen seems "simple" to me.. not sure what would hang it.

No problem. You might want to dig into that useNativeDriver log, and enable useNativeDriver explicitly as it says.

Also, congrats on the new image and alias 😄

Also, congrats on the new image and alias 😄

private / work accounts :)

Thx for the time and research :) Interesting.. will have to dig deeper The screen seems "simple" to me.. not sure what would make the tap busy.

This could be the obvious but try mimicking this behavior without Detox. You might end up reproducing the same behavior manually...


Fix VirtualBox extension pack checksum

Hello,
the checksum of Oracle_VM_VirtualBox_Extension_Pack-7.0.6 have change.
I did the tests on virustotal and its good : https://www.virustotal.com/gui/url/a1342649aec9824c23bfccb5b93c511c6a7e1d3727df4844441be70eb88b2ab0?nocache=1
Can you accept the correction ?
Best regard
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[ ] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[x] I have updated the package description and it is less than 4000 characters.
[x] All files are up to date with the latest Contributing Guidelines
[x] The added/modified package passed install/uninstall in the chocolatey test environment.
[x] The changes only affect a single package (not including meta package).

:white_check_mark: Package verification completed without issues. PR is now pending human review

The checksum_ep is calculated by the update script. I think all that is required here is a package fix version submitted.
In the meantime it can be installed using the --ignore-checksum switch, but note this will also ignore the checksum for the Virtualbox installer too.

Ok, I understand you prefer to use the auto-update script cause it's the best way ;) So can you rebuild the package to correct the checksum?
Thanks
Best regards

Thanks for the fix :)


[App Configuration] Add troubleshooting guide

Packages impacted by this PR
Issues associated with this PR
Describe the problem that is addressed by this PR
Add troubleshooting guide
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


Parallize Python Unit tests

End-user friendly description of the problem this fixes or functionality that this introduces

[ ] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

Give a summary of what the PR does, explaining any non-trivial design decisions
Python Unit Tests take a pretty long time to execute. This will use all the cores on the github actions worker to try to accelerate tests by parallelizing.
==== Before this PR
Example run: https://github.com/All-Hands-AI/OpenHands/actions/runs/12248390242/job/34167909826?pr=5488
397 passed in 320.14s (0:05:20)

==== After this PR
Example run: https://github.com/All-Hands-AI/OpenHands/actions/runs/12249262896/job/34170279872?pr=5499
397 passed in 193.19s (0:03:13)

To run this PR locally, use the following command:
docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:fac9b78-nikolaik   --name openhands-app-fac9b78   docker.all-hands.dev/all-hands-ai/openhands:fac9b78

Nice! 2m saved per run.


Create estimated-subsidence-minimum.yml

Issue: #3
Service for querying the estimated subsidence minimum number from Statistics Estonia.
Always makes a query for the current year or the closest possible year with available statistics.
Requires the setting "stopInCaseOfException: false" in Ruuter's configuration so as to avoid a premature stop in the service process. This is necessary as because stat.ee returns 400 Bad Request for querying any statistics that are not yet created.

Close as obsolete by now


proposal: spec: binary integer literals

Currently, Go supports octal and hexadecimal integer literals in addition to the standard decimal literals you'd expect. In an effort to round out this group, I propose adding binary integer literals as well. They would come in the form as a new prefix to integer literals: 0b or 0B.
Initial Disclaimer
This was my first dive into the Go source code and primarily a learning experience for me to get my feet wet submitting changes and what-not. That being said, I appreciate any and all criticism, comments, and suggestions.
The "Why": Prior Art
Binary literals exist or have appeared in mainstream languages as well, including:

C++14
D
Java 7
Python 3
Ruby

All of the above cases have settled on a convention of using 0b or 0B to prefix binary literals, suggesting that this would be a fairly comfortable and sensible choice for Go as well, avoiding needless invention and providing similarity for programmers coming from these other aforementioned languages.
The "Why": Continued
I managed to find some earlier discussions relating to this, albeit this was after I had already implemented the feature and it has more to do with changing the octal syntax than specifically relating to binary literals. But https://github.com/golang/go/issues/12711#issuecomment-142338246 from @griesemer does mention that "both the 'o' for octal and 'b' for binary notation were also discussed in the design of Go. It's simply not enough bang for the buck." However, I don't see this as a good argument against adding something so simple to the language. Especially considering the fact that nowadays more and more languages have adopted the syntax for binary literals, it seems the earlier Go design decisions might need to be looked at under new light.
Example usage
const (
    SOME_MASK   = 0b00001111
    SOME_FLAG_A = 0b00000001
    SOME_FLAG_B = 0b00000010
    SOME_FLAG_C = 0b00000100
    SOME_FLAG_D = 0b00001000
)

Implementation
As I stated this was more of a learning experience for me, I already have changes that implement this feature ready:
CL-37502 spec: specify syntax for binary integer literals
CL-37503 cmd/compile/internal/syntax: scan binary literals
CL-37504 go/scanner: scan binary integer literals
CL-37505 strconv: support parsing binary integer literals
CL-37506 test: extend int_lit with binary literal usages

This has come up before. There is a significant amount of work involved in rolling this out, making the compiler and spec changes is trivial. But there's a lot of libraries that should also be made consistent (strconv, math/big, etc.).
If we make a change in this direction, it should be more thorough and support arbitrary bases. I am against this as is.

@griesemer Yes, the changes I'm about to submit also modifies strconv (to my understanding, it's actually required to support this change).

@griesemer I disagree however that any change should support arbitrary bases or otherwise no change be made at all. From prior reading, it sounds like that would be a good goal for Go2; this is simply polishing Go1 with syntax developers of other languages might expect when using Go. (i.e. Base-2 is a common enough case, probably more common than octal; base-14 or what-have-you is less-so.)

I rather like this.

However, I don't see this as a good argument against adding something so simple to the language.

It's not a particularly strong argument in favour of adding them, either.
IMHO you'll need to expand the "why" section explaining exactly what advantages supporting binary literals will bring to people writing go code.
I don't find them particularly useful; hex is a much more readable and compact format for literals that have a "bit-level meaning", IMO.
You gave an 'usage example', but it's not very compelling.

@EddieRingle This proposal has not been discussed widely nor has it been accepted. Please do not spam us with code reviews. The Go Team has enough to do with work that's actually important.
It is clear to everybody that adding a simple feature to the language is trivial. It's also clear that plenty of people would like this feature (I myself would have liked it sometime). But that said, just because one can, is not an argument that one should. Any however small and simple addition to a language has long-term costs. If we accept this, it will become even more difficult in the future to have a more general mechanism, and we need to remain backward compatible.
Let's wait and see what other people say before jumping the gun. Thanks.

Reminder of our no-me-too policy: https://golang.org/wiki/NoMeToo
Opinions without constructive content can be expressed using Github's emoji reactions.

@ALTree

IMHO you'll need to expand the "why" section explaining exactly what advantages supporting binary literals will bring to people writing go code.
I don't find them particularly useful; hex is a much more readable and compact format for literals that have a "bit-level meaning", IMO.

I'd argue the opposite, actually. Hex is more compact in many cases, yes, but binary literals would be an exact "bit-level" representation and therefore as readable as you could get.
@griesemer

This proposal has not been discussed widely nor has it been accepted. Please do not spam us with code reviews. The Go Team has enough to do with work that's actually important.

Apologies. It was originally a single change but since it seems like the Go policy is to break up commits based on the area of codebase affected, that's how I ended up splitting them up. I wasn't aware the bot would make individual comments here for every change. I wouldn't be so cold as to call it spamming you, however, nor imply that any effort I put in using my free time is unimportant.

Any however small and simple addition to a language has long-term costs. If we accept this, it will become even more difficult in the future to have a more general mechanism, and we need to remain backward compatible.

Like was mentioned before, the general-purpose route (which I would prefer, as well) would also encourage the deprecation/removal of the existing (confusing) octal syntax, no? The feeling I got was that the general-purpose syntax (2r0010 or 2x0010 for base-2, for example) was invention meant for Go2, where breaking changes would be welcome anyway.
Putting a potential Go2 aside, to address the statement that "if we accept this, it will become even more difficult in the future to have a more general mechanism": I just don't see how this is true. Adding the binary literal prefix would be orthogonal to an alternative, general-purpose syntax, especially the one you described in #12711 (in fact, that syntax conflicts directly with hexadecimal literals, but would not with this proposed binary literal syntax). They would exist side-by-side just as the general-purpose syntax would with the existing octal, hex, and decimal literals.

Apologies. It was originally a single change but since it seems like the Go policy is to break up commits based on the area of codebase affected, that's how I ended up splitting them up. I wasn't aware the bot would make individual comments here for every change. I wouldn't be so cold as to call it spamming you, however, nor imply that any effort I put in using my free time is unimportant.

It's not just that the bot sends mail about CLs, it's that each mailed CL is a request for a Go reviewer to spend time reviewing it.

The 0b syntax is nice because it's familiar but if the true goal is simply to add binary literals to the language, I would much prefer the generic solution over the familiar.
Is there any technical reason the generic option can't be implemented prior to 2.0? I've had a number of cases lately where binary literals would have been preferred over hex and it would be nice to have that option in 1.9 or 1.10 instead of waiting (possibly many years) until 2.0.

@wedow I think it would help to see specific real cases where binary literals are useful.  Please share the cases where binary literals would be helpful.  Thanks.

I don't see "should support arbitrary bases" as a worthwhile objection.  It adds complexity/cost for little or not additional benefit.  Over all the years I've been hacking, the would-be-useful bases I've heard of people wanting to use are 2, 8, 10, 12, and 16, and possibly 64 (we have base64 encoding, after all).

Let's look at why the aforementioned languages have moved forward and added support for binary literals. Let's start with C++14 as it is the first one on the list. What were the points James Dennett, then Google employee, brought forward?

Use of an 0b/0B prefix for binary literals is an existing GCC extension (also supported by Clang), and is the same syntax as Java 7, Python, and D.

Why would this particular point benefit Go?
Familiarity with the language.
Many developers move from programming language to programming language. Correct me if I'm wrong, but we all try what we know from one language in another one. You could in a way say that Go's familiarity with C and C++ attracted those kinds of developers who wanted a particular feature like GC, but didn't like other languages. This is one of the reason's the company I currently intern for has chosen to move to Go.
Besides experienced developers, let's also have a look what the benefit is of familiarity for beginner developers. Let's also take the use case of flags that @eddieringle mentioned. Explaining to a complete beginner how flags work is a lot harder when you have to explain it in octal or hexadecimal as it requires the person to learn those as well.
Lastly I would like to add here that the purpose of every language (at least that's what I hope) is to write clean code. And I think that is something we all agree on regardless. When looking over someone else's code, it is immediately clear without any explanation that when having a list of binary literal constants, that those are flags. That same thing is a lot less straightforward when using hexadecimal or octal. Below is a comparison.
// Hexadecimal
const (
    MASK          = 0x1E
    DEFAULT_COLOR = 0x00
    BOLD          = 0x01
    UNDERLINE     = 0x02
    FLASHING_TEXT = 0x04
    NO_CHANGE     = 0x08
)

// Octal
const (
    MASK          = 036
    DEFAULT_COLOR = 00
    BOLD          = 01
    UNDERLINE     = 02
    FLASHING_TEXT = 04
    NO_CHANGE     = 010
)

// Binary
const (
    MASK          = 0b11110
    DEFAULT_COLOR = 0b00000
    BOLD          = 0b00001
    UNDERLINE     = 0b00010
    FLASHING_TEXT = 0b00100
    NO_CHANGE     = 0b01000
)

I do think that no thought needs to be given to the fact that the last constants are used for flags. These are also very few flags, so keep in mind that this definitely adds up when having more flags. The first constant 0x1E can definitely turn some heads when it's declared without context. Using binary literals alone may indicate that a variable might be used as a flag.
The referred C++ PDF further refers to the aforementioned languages for support. So let's look at those next. I have found the (original?) proposal by Derek Foster in 2009 for binary literals in JDK. Source
The first thing it questions, which I completely agree with, is why there is an octal representation in the JDK, but there is no binary representation in the JDK. In the past few years I have never thought to myself: "Oh, octals would make my code cleaner!" This however refers to the previous point I made: familiarity. There is one thing it however adds to my previously made point:

When the data being dealt with is fundamentally bit-oriented, however, using hexadecimal to represent ranges of bits requires an extra degree of translation for the programmer, and this can often become a source of errors. [...] then a programmer coding to that specification must translate each such value from its binary representation into hexadecimal. [...] In most cases, programmers do these translations in their heads, and HOPEFULLY get them right. however, errors can easily creep in, and re-verifying the results is not straightforward enough to be done frequently.

Hexadecimal and octal notation used primarily in hardware instead of binary can result in human errors. In the comparison I gave previously, I checked what I did with my head by entering what I thought was octal into Google which confirmed my answers. I am automatically sure of my case when I write it in binary, but am not when I write it in hexadecimal or octal. And not matter how many times you do this a day, it makes it harder to write code because you have to think of the binary form in your head and while doing so it is possible to make errors.
To dig deeper into the question to why there is an octal notation, but no binary notation I have another question to ask which was also asked by Derek Foster, the author of the binary literal proposal for the JDK: "Why did Go chose to use the 0 prefix for octal notations?" @griesemer commented that we should not jump the gun when implementing new features:

Let's wait and see what other people say before jumping the gun. Thanks.

But hasn't Go jumped the gun when implementing the octal notation? If its argument was "because other languages do it", then why can't that argument not be used for binary literals? If it wasn't, then what was the reason that the 0 prefix for octal notations made it into the language when it confuses people?

Someone might incorrectly think that "0b1" represented the same value as hexadecimal number "0xB1". However, note that this problem has existed for octal/decimal for many years (confusion between "050" and "50") and does not seem to be a major issue.

- Derek Foster
There don't seem to be more points in favour of binary literals because it is something we all refer to in our heads. This is why I feel proposals for other languages have been brief like this one. It however is not a reason to shut it down so quickly.

Here's another option, which seems clearer to me than any of the integer constants.
// Shifts
const (
    MASK          = 0x1e
    DEFAULT_COLOR = 0
    BOLD          = 1<<0
    UNDERLINE     = 1<<1
    FLASHING_TEXT = 1<<2
    NO_CHANGE     = 1<<3
)

(And shouldn't mask be 0xf, not 0x1e?)
I'm mildly against adding binary constants, at least in Go 1.  I'd be for adding them in Go 2, though.  The reason for the difference is that if for whatever reason someone is stuck at Go 1.8, when Go 1.9 comes out with binary constants, if one of the (transitive) imports of that person's code uses binary constants, then they can no longer build their project using Go 1.8.  They would have to vendor or upgrade.  There's a definite cost to adding a forward-incompatible feature which should weigh against its utility.
I do agree that I don't see any need for bases not in {2,8,10,16}.  The case for octal seems particularly shaky, I'd be for removing octal in Go 2.

@randall77 I disagree that shifting looks cleaner. In my head I'm still representing them as binary numbers and probably always will. It would make it easier to remove that calculation I do in my head.

(And shouldn't mask be 0xf, not 0x1e?)

The name MASK was merely taken from the JDK proposal and is not really in line with the other constants. But it does show that 0x1E and hexadecimals already cause confusion.
I can understand the point you're trying to make wanting to move it to Go 2. But I disagree that we should have to support projects that downgrade their Go version from 1.9 to 1.8. It would make languages changes a nightmare to deal with. I do however not know how Go looks at this, it would be most wise to follow what compatibility Go has in mind.
I wholeheartedly support your position on removing octal in Go 2.

I just reread my previous comment (specifically, "The Go Team has enough to do with work that's actually important."). I want to apologize for this statement which was a rather offensive formulation of what I actually meant to say. So let me try again, elaborating a bit more and hopefully finding the right tone this time:
We do appreciate proposals that are well substantiated and, if necessary, come with prototype implementations. That said, the Go proposal process is light-weight on purpose, and no extra work is required by the proposer unless requested or necessary to understand the proposal. Sending change lists that are not requested and/or don't fix an issue is counter-productive since somebody will have to take the time and look at them (if only to postpone or close them). A better approach, if one does want to prototype/write the code ahead of time, is to link to the changes elsewhere (for instance, a private GitHub commit). This will leave the Go Team and external contributors the choice: They can decide to look at that code if they want to, or otherwise focus on higher-priority items. Thanks.

@griesemer Gotcha, I understand and that makes sense. I assumed the Go team treated their Gerrit like AOSP does theirs, and figured my changes could exist there while this was discussed. Linking to a branch here on GitHub is less work anyway, so it's a win-win, I guess. :)
I actually did the work first since my main goal was to hack on the compiler. It was after the fact that I decided to submit it as a proposal.

@AndreasBackx The leading 0 for octal in Go was discussed in issue #151.  See also #12711.

When defining 1-set-bit constants, shifting is more readable than 0b00001000..00 for the simple reason that in the shift version you don't need to count a bunch of zeros on the screen just to understand which bit is set.

As far as real world usage goes, a common variable length integer encoding method is to use the high bit for "read more". I've had to use it to extract git packfiles. Here's the code to extract the lower bits in various bases:
b & 127
b & 0x1f
b & 0177
b & 0b01111111
I personally think that the binary version more clearly shows the intent.

You still have the shift option mentioned previously
If you think it's not readable, use an helper function
b & ^(^0 << 7)
b & mask(7)

@AndreasBackx, 1<<12 is more clear than 0b0001000000000000 because I don't have to count all those zeroes. It's apparent it's a mask because the 12 falls between 11 and 13, or uses iota. When having to match an arbitrary pattern, e.g. masking bits from an instruction word, then hex is better because a programmer used to dealing with bits can read 0xae and "see" 10101110 by virtue of knowing 0xa, ten, is 1010, mnemonic ten-ten, just as one learns times tables, 65 is ASCII A, etc. Hex is a more dense representation that's easier to parse for the human reader.
@randall77, aren't 0644, 02775, etc., a bit tedious without octal? That's why it's still kicking about.

@RalphCorderoy : yes, it seems to me that octal survives for the sole reason of constructing an os.FileMode.
0664 = 6<<6 + 6<<3 + 4, which isn't too tedious.  It would be better if os provided symbolic constants to make this easier, or at least clearer.

I actually did the work first since my main goal was to hack on the compiler.

Excellent. If you'd like some ideas for places to continue to hack on the compiler while this gets discussed, feel free to drop me an email--@gmail.

@RalphCorderoy 1<<12 is more clear than 0b0001000000000000 because I don't have to count all those zeroes.

A solution to this problem would be to allow for some kind of separation. Java allows for underscores in numeric literals. It has been shortly discussed in #42, but there weren't many arguments against it, if there were any comments on that issue in the first place.

It's apparent it's a mask because the 12 falls between 11 and 13, or uses iota.

I'm sorry, but this perhaps is the case for you. But not for everyone else.

When having to match an arbitrary pattern, e.g. masking bits from an instruction word, then hex is better because a programmer used to dealing with bits can read 0xae and "see" 10101110 by virtue of knowing 0xa, ten, is 1010, mnemonic ten-ten, just as one learns times tables, 65 is ASCII A, etc.

This leaves room for error in the code as has been previously stated by me and proposals made for other languages that found it a valid reason.  You might work with a lot of hardware, but most people don't. Definitely beginners would prefer the binary literals over the hexadecimal representation.

Hex is a more dense representation that's easier to parse for the human reader.

Does dense mean that it is cleaner? No it doesn't. People write one-liners all the time for crazy things and the reason that those are somewhat impressive is because that code is so dense and unreadable that we all wonder what witchcraft lies hidden behind the meaning of each character.

1 << 10 is much clearer than 0b1e10.
I find binary literals difficult to read. Very often what you need rounds up to three or four bits segments, which are much easier and less error prone to read and write in octal or hexadecimal. When things don't round out to such even boundaries, a shift is also much easier to read and write, and less error prone.
Some form of concatenation would make binary literals easier to read and write, at the cost of inconsistency. Why can binary literals be concatenated, but no other type of numeric literals? Why not hex? At this point, this discussion becomes boundless.
Personally, I would prefer some sort of generic radix mechanism. I do not think binary literals bring enough to the table (and I only write low-level code).

It's a bit surprising to me to see so many personal opinions being given as arguments about a change to a language. I'm unsure how to quantify comments related to how useful you would find it personally.
If some reason personal feelings have merit points, I'll arbitrarily say that I use binary literals in Java and I can validate my opinion on this by saying I've been programing for 100 years and I own a car.
Next, debating if it's easier to use shifting to define masks is like arguing that Gregorian calendars are easier to use than Chinese calendars. Just because you find it easier to use does not mean everyone does. The fact that binary literals exist in other languages should probably be an indication that someone found them useful furthering that the shifting argument is not much of an argument as it is just simply an alternative.

This has come up before. There is a significant amount of work involved in rolling this out, making the compiler and spec changes is trivial. But there's a lot of libraries that should also be made consistent (strconv, math/big, etc.).

This is a solid argument against this proposal and I would completely understand hesitation in making changes that create a significant amount of work.

I'd argue the opposite, actually. Hex is more compact in many cases, yes, but binary literals would be an exact "bit-level" representation and therefore as readable as you could get.

Funny thing about learning binary is that you have to actually read and write binary and then perform math on it. Writing in hex or decimal or octal or base64 (lul) can indirectly aid in learning binary but I heard that just learning the thing you want to learn directly is useful (probably just an opinion though).

Personally, I would prefer some sort of generic radix mechanism.

I wish every language had this in a literal form.

@randall77: As #151 stated, there are several reasons for keeping octal. Yes, one is the setting of file modes, but that's the last important. The other two are the change of semantics it would be to an integer literal that starts with 0, and the importance of safety porting code from every other C-like language, in which octal constants have this syntax. It's true that no one of these is compelling but taken together they meet the bar. Anyway the issue is decided, at least for Go 1.
As for binary constants, I don't think they carry their weight. Very few programs would benefit from them, and even then the benefit is small.

@robpike It would be safe to just fail to compile anything that looked like an octal constant (starts with 0 but not "0").

Let's leave this for Go 2.

Why wait? It doesn't break anything.
On Mon, Mar 6, 2017 at 15:19 Russ Cox<EMAIL_ADDRESS>wrote:

Let's leave this for Go 2.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/19308#issuecomment-284535766, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABLfW7bN2NicSthvEvMeGEhqExg2et-qks5rjHhtgaJpZM4MNgUY
.

@DocMerlin, because Go isn't a language that keeps accreting features just because it can. All language changes are basically on hold for now until they can be evaluated together as a group, so they look and feel and work together like a cohesive whole. That is why this is labeled Go2.

@DocMerlin I like to add to @bradfitz 's comment that we've made exceptions in the past when there's pressing needs. There is clearly no pressing need here.

These are also very few flags, so keep in mind that this definitely adds up when having more flags.
SOME_FLAG_D = 0b0000000001000000000000000000000

At a quick glance is this 2^19 or 2^20? See the problem?

Thanks @davecheney, I've caught up with the thread. I hadn't considered that there could be a massive effort involved in making the standard library support binary integer literals.
It's obvious that there are no use cases where a routine that handles bit manipulation on integers can't be correctly expressed due to the lack of binary literals, and nothing is gained performance-wise by expressing integer data in one base over another.
However, there are plenty of binary encoding situations  (video codecs, data compression, binary network protocols, etc.) where bit masks, binary constants, and other bitmapped data can be made more legible in source code if data is expressed in base 2.
It's a matter of legibility and style for people who handle bitmapped data.
Legibility and style is are the same reasons why octal integer literal notation has been supported by Go on day one. The inclusion of support for octal integer literals is most likely a decision that has to do with the handling of Unix file permissions.  It's hard to imagine on this day an age many practical uses of octal notation other than legacy support of Unix-style permissions and the readability of this data in code.
Octal support is nonetheless helpful to show that there are only two simple functions in strconv tasked with the handling of octal strings.
archive/tar/strconv.go:func (p *parser) parseOctal(b []byte) int64
archive/tar/strconv.go:func (f *formatter) formatOctal(b []byte, x int64)
To very roughly assess the change impact of adding binary integrals support, one possible method is to check the code footprint of equivalent support for octal, a trivial thing because octal is so rarely used that it's easy to identify the places and situations in which base 8 is supported.
In my local copy right now, a rough search shows that most of these are parse and format operations.
vxv@vxs:/gosource$ grep -i -r octal *  | wc -l
73
vxv@vxs:/gosource$ grep -i -r octal * | grep "func " | wc -l
2
Granted that this is trivial and simpleminded search, but the proportions of the problem don't seem to present an unsurmountable task.

No worries. For the record I don’t have a dog in this race, I’m just here to garden the issues. It’s up to others to decide on the fate of this proposal for go 2

However, there are plenty of binary encoding situations (video codecs, data compression, binary network protocols, etc.) where bit masks, binary constants, and other bitmapped data can be made more legible in source code if data is expressed in base 2.

I've used all of the above, and I've never imagined base 2 could have any benefits for these. Would you point to a concrete example to convince me otherwise?

Readability should be a main reason for implementing binary literals. I'm currently writing a engine that takes advantages of bit positioning, and I use uint16, uint32 for several use cases and each slice/section of those uints represents different info.
In chess we use encoded moves by adding flags, from and to position into a uint16. It would be nice to see a binary literal implementation so the code can show, only by itself, which sections relates to which info.
...
constexpr uint_fast16_t FLAG_SPECIAL1  {0b0010000000000000};
constexpr uint_fast16_t FLAG_SPECIAL0  {0b0001000000000000};
constexpr uint_fast16_t RANGE_FLAG     {0b1111000000000000};
constexpr uint_fast16_t RANGE_FROM     {0b0000111111000000};
constexpr uint_fast16_t RANGE_TO       {0b0000000000111111};

This is my code example from C++17. In Go however, it will look like this:
const FlagSpecial1 uint16 = 8192
const FlagSpecial2 uint16 = 4096
const RangeFlag uint16 = 61440
const FromFlag uint16 = 4032
const ToFlag uint16 = 63

Essentially useful for writing clean and simple code for anyone that works with bits and masks.
 Since after all it's astethics (in my eyes).

Which bit is set in (c++)
constexpr uint_fast16_t FLAG_SPECIAL0  {0b0001000000000000};

vs
which bit is set in (Go)
const FlagSpecial0 = 0x10000

I'm probably not the only one who can tell immediately in the later case only.

With the 0b00.. approach you can see it, without having to know hex numbers. It's easier to read when you have a large list of uint16. Understanding that the set bit is at the 13 position, since the size is listed, in the example you gave is easier than using hex. 1<<13, would be much better than hex as well as you don't have to look up values, you can just look at it and know which bits are targeted. But for a range or multiple set bits, it can be easier to just use a binary literal.
Looking at the later cases like 61440 I'm impressed you can tell immediately, and you think that it's easier to know which bits are set using decimals than a binary literal, but not everyone sees this.
But you just ignored the other cases like 0b0000111111000000 which is 0xfe0 or 4064 in decimal. In my opinion that is cleaner using binary literal. 16 bits is a larger number, but look at bytes:
0b11101010 vs 0xea. You don't even have to think what is being targeted, you just know it as soon as you take a look.

@andersfylling, If you're programming bit masks then you really need to be able to read hex: RangeFlag wouldn't be 61440 but 0xf000 which makes instantly obvious it's the top nibble of the 16 bits.
For those thinking they have novel insight on this issue, can you please wade through all comments from the top, taking particular note of Brad's reference to the NoMeToo policy, before waking the rest of us from our slumber.

Another example that just burned me was defining addresses in the embedded protocols (I2C, SPI, CAN, etc...) where there is often an address defined as a binary constant in the data sheet shifted that has some sort of read / write bit as part of the value.  Converting them to hex adds one more layer of translation the human brain has to do, thus one more thing to question when debugging.

Yet another user here wanting to clearly define bitwise flags in a readable manner.

Another user here advocating for this feature just for the sake of readability. Putting something like x&0x80 tells me nothing whereas if it was x&0b10000000 I would instantly know what's happening.

IMO it's exactly the opposite. 0x80 says it's bit 7 directly without thinking, while getting that information from 0b10000000 requires to stop and count the zeros one by one because only few people are immediately sure how many zeros are there once the number of them is not really small. Allowing some separated form, like '0b1000_0000' fixes that, but then it's essentially the same as the hex format, only longer without a good reason.

Hi @tapir, Please read my earlier comment https://github.com/golang/go/issues/19308#issuecomment-352290337 especially https://github.com/golang/go/wiki/NoPlusOne as NoMeToo is now called.

Comment  #19308 is still wrong.  Please @tapir read the entire thread, this is not a settled matter.

Here's a counter-proposal which permits arbitrary radix notation at about the same (or less) cost: #28256 . I proposes a notation I have alluded to directly or indirectly in various discussions, but never formally written down.

See #28493 (independent proposal) discussing the use of _ as separator between digits.

If you're revisiting this old/shelved discussion for Go 2, then I would suggest looking at octal at the same time. Obviously, you can't remove the 0123 notation (for compatibility reasons - not without a deprecation period at least), but you can add 0o123 at the same time as you add 0bXXX. This would enable a more consistent set of number-base identifiers, promoting Go's nice uniformity of syntax and programmer expectation.
But, on its own, the binary proposal would still be worthwhile.

Would strconv.ParseInt support the 0b010 syntax when base is 0?

@nathany Yes, if we decide to support the 0b prefix in the language we should also support it in the library. For instance, the compiler currently relies on math/big.Int's SetString method to convert constant literals into big.Ints - so one would expect SetString (and friends, such as strconv.ParseInt) to understand 0b as well.
Perhaps less obvious is whether ParseInt should also filter _ separators if we accept this together with #28493. It would be easy as a separate path (replace _ with ``) but for error handling (e.g.; do we allow _ anywhere, or not) and performance we might need to handle it in the ParseInt (and all other ParseXXX routines for numbers).

@nathany I'd suggest a separate issue. I agree that if we decide to permit 0b it might make sense to also allow 0o for consistency (and then we may want gofmt to auto-rewrite 0-prefix octals into 0o prefix octals so that the former could be slowly phased out from the code base). But this proposal is about binary integer literals; let's keep it on that.

My original question did not receive a response, so I read the entire thread again to see why a thread
with so many thumbs up has so little discussion.
So far the proposal asks for binary literals for the following reasons:
other languages have them
The proposal goes into meticulous detail about how other languages have them and how others are used to them. Has this ever been a good enough reason before?
they are "more readable"
I disagree. They're a dastardly pattern of ones and zeroes that have no easy pronunciation without a
conversion to base16.

You just know

0b11101010 vs 0xea. You don't even have to think what is being targeted, you just
know it as soon as you take a look.

The first low order bit, and the third low order bit, and the fifth low order bit are off, but not the rest of them. And there are [counts the total amount of bits twice to make sure the number is right] eight
bits total.
I know what the pattern is, and I will probably remember it for a few seconds. How is that knowledge
inherently useful?

Go vs C++

Some arguments misrepresent their benefit, perhaps unintentionally. In one particular example in
this thread, the following snippet was posted comparing go and c++.
constexpr uint_fast16_t FLAG_SPECIAL1  {0b0010000000000000};
constexpr uint_fast16_t FLAG_SPECIAL0  {0b0001000000000000};
constexpr uint_fast16_t RANGE_FLAG     {0b1111000000000000};
constexpr uint_fast16_t RANGE_FROM     {0b0000111111000000};
constexpr uint_fast16_t RANGE_TO       {0b0000000000111111};

This is my code example from C++17. In Go however, it will look like this:

const FlagSpecial1 uint16 = 8192
const FlagSpecial2 uint16 = 4096
const RangeFlag uint16 = 61440
const RangeFrom uint16 = 4032
const RangeTo uint16 = 63

The problem is the C++ is meticulously aligned while the Go is unformatted, lacks a const block and incorrectly uses decimal instead of hex (which you can't easily convert to binary by splitting each hex digit into four binary ones).
const (
	FlagSpecial1 uint16 = 0x2000
	FlagSpecial2 uint16 = 0x1000
	RangeFlag    uint16 = 0xf000
	RangeFrom    uint16 = 0x0fc0
	RangeTo      uint16 = 0x003f
)

protocols specifications publish binary sometimes

Another example that just burned me was defining addresses in the embedded protocols
(I2C, SPI, > CAN, etc...) where there is often an address defined as a binary constant in the
data sheet shifted > that has some sort of read / write bit as part of the value. Converting
them to hex adds one more layer of translation the human brain has to do, thus one more
thing to question when debugging.

The problem is the human brain shouldn't be doing this for you in the first place. |
Consider your debugging experience again. Are going to dump binary integer literals to stderr or
and grep for them later? Will you be sharing these numbers with colleagues by saying each 1
and 0 out loud? Odds are you rather output and transmit them in hex, and if that is true, it is
also true that the source code should express those digits in hex in order to remove the need
for the the human brain (or program) to do even more work for the reader.
Many specifications express 1010 to mean a bitstream consisting of those ordered states. This doesn't map to the byte-wise notion of binary integer literals, and will surely burn someone expecting
to implement a bitstream reader. (I would rather have go implement a bitstream reader in the standard library than support binary integer literals).

I just ran into this lack of feature today. In my example use case, I'm using the integer day-of-week
field of a date (0..6 to mean Sunday..Saturday) and checking it against a preference bitmask.
Because the source of the integer is programmatic, I don't define a set of constants for each day
of the week (my code has no reason to ever talk about SUNDAY specifically), so 1 << 3 syntax
isn't useful here. However, I want a default value for the preference bitmask, which would be
perhaps 0b0111110. Obviously it's easy to write this default as decimal (126) or hex (0x7e), but
it's considerably clearer to write it in binary.

@as Thanks for your comment. It has been recorded.
Clearly we don't need binary integer literals; we have a reasonably close way to express such numbers using hexadecimal literals (and I have pointed out as much in my blog post). But at the same time they seem to address a pain point for many programmers, and this is something we could easily fix here without adding much complexity to speak of to the language.
Perhaps a better way to think about this issue is whether we want to bring Go up to par with most other programming languages in this respect and complete the set of integer literal representations by supporting all relevant bases (2, 8, 10, 16).
That is a question that's separate from personal sentiment about the usefulness of binary literals and may be easier to answer.

See https://golang.org/cl/152338 for the spec changes pertinent to this proposal (ignoring _ separators in this first step).

I was looking for benchmark for various sort algos where pseudorandom was set as 0xff & (i ^ 0xab) If it were 0b10101011 instead of 0xab it  would be more readable. I am surprised there is no binary literals in Go, not even a proposal...

@andrewmed This is the proposal for binary integer literals.

Got it, thanks

As a reminder, we introduced a new process for these Go 2-related language changes in our blog post blog.golang.org/go2-here-we-come. The Go 1.13 development cycle is now over and it’s time for the final decision.
The feedback on the Go 2 number literal changes has been strongly positive, with very few negative voices. These changes modernize and harmonize Go’s number literal syntax without adding significant complexity to the language: There is now a uniform prefix notation for the three common non-decimal number bases, which matches the notation used in other modern programming languages. The introduction of hexadecimal floating-point literals addresses a pain point for people concerning themselves with numeric code. The suffix “i” may now be used with any (non-imaginary) number literal to create an imaginary constant in a uniform way. And finally, underscores may be used to split longer literals into groups of digits for improved readability.
Proposal accepted for Go 1.13. Closing because the changes have landed.

rsc for proposal review


Ver 0.4.0 Unable to load DLL 'onnxruntime-genai' or one of its dependencies: The specified module could not be found. (0x8007007E)'

I have installed CUDA11.8, as well as cudnn-windows-x86_64-<IP_ADDRESS>_cuda11
I can use 0.3.0 to load Phi3mini(Phi-3-mini-4k-instruct-onnx\cuda\cuda-int4-awq-block-128)
As soon as I upgrade to 0.4.0, an exception is thrown
Unable to load DLL 'onnxruntime-genai' or one of its dependencies: The specified module could not be found. (0x8007007E)'
VS2022 17.11.5
Windows 11 23H2 22631.4169
Consolapp with .NET 8
Package Microsoft.ML.OnnxRuntimeGenAI.Cuda Version="0.4.0"

[ ]


41 updating agent configuration

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-10-28T14:42:48.664+0000

Duration: 3 min 4 sec

:robot: GitHub comments
Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.

run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)


A guarantee that the same URL won't be downloaded several times?

The same URL will  be downloaded several times,because it dosn't equeal the URL

Look at SDWebImageDownloader and the way it uses then URL as a key for URLOperations.


Can't install 2.0.0 from npm

The new v2.0.0 is properly tagged and listed on the npm website, yet it fails to install:
$ npm install<EMAIL_ADDRESS>
npm ERR! Darwin 15.5.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install"<EMAIL_ADDRESS>npm ERR! node v4.4.5
npm ERR! npm  v3.9.5

npm ERR! No compatible version found<EMAIL_ADDRESS>npm ERR! Valid install targets:
npm ERR! 1.1.2, 1.1.1, 1.1.0, 1.0.2, 1.0.1, 1.0.0, 0.1.0, 0.0.3, 0.0.2, 0.0.1
npm ERR!
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

looks like you have just typed in the wrong package name: gulp-jsonlint rather than gulp-lesshint

I'm sinking into the floor, out of sight. Sorry!


logback-gelf fails if gson is not in classpath

I am using https://github.com/downloads/Moocar/logback-gelf/logback-gelf-0.9.6.jar in a fresh Java maven project. I had to upload the jar in my own maven repository (nexus), because the jar is not available in any public maven repository yet.
On startup, I get the following error:
Failed to instantiate [ch.qos.logback.classic.LoggerContext]
Reported exception:
java.lang.NoClassDefFoundError: com/google/gson/GsonBuilder
at me.moocar.logbackgelf.GelfConverter.(GelfConverter.java:42)
at me.moocar.logbackgelf.GelfAppender.initExecutor(GelfAppender.java:86)
at me.moocar.logbackgelf.GelfAppender.start(GelfAppender.java:60)
In order to solve this, I had to add the following dependency to my pom.xml:
<dependency>
	<groupId>com.google.code.gson</groupId>
	<artifactId>gson</artifactId>
	<version>2.1</version>
</dependency>

Ahh whoops, I forgot to assemble the jar with dependencies. fixing now...

Ok, I've added a "with-dependencies" jar to the downloads page.


IotEdge 1.5 LTS for Scarthgap

IoT Edge Recipes for 1.5 LTS for Scrathgap.

@microsoft-github-policy-service agree

/azp run

/azp run

@jolting Thank you so much for your contribution. We highly appreciate this effort. We are considering this PR to be a release candidate. Have you tried this recipe and it works? We need more volunteers to try this recipe and test the scenarios as well

@Dvergatal  @sindelar-fr  can we get you both as volunteers for trying the recipes out?

@maskimthedog Would you be interested in trying this recipe?

@maskimthedog Would you be interested in trying this recipe?

Sure.  I’ll kick a build off here in a bit.

@ggjjj The aziot-keys lib file doesn't get installed in the lib directory, so it can't be found at runtime. Adding a symbolic link to point to the Rust lib directory where it's installed fixes the problem for me. I'm not sure if the symbolic link is the best way to go. Besides that everything seems to work for me.

I added an rpath to aziotd. Works now.

@maskimthedog Would you be interested in trying this recipe?

Sure. I’ll kick a build off here in a bit.

ERROR: aziotctl-1.5.0.AUTOINC+0f93f7a544-r0 do_patch: Applying patch '0001-Change-panic-strategy-to-unwind.patch' on target directory '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/git'
CmdError('quilt --quiltrc /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: Applying patch 0001-Change-panic-strategy-to-unwind.patch
patching file Cargo.toml
Hunk #1 FAILED at 54.
1 out of 1 hunk FAILED -- rejects in file Cargo.toml
Patch 0001-Change-panic-strategy-to-unwind.patch does not apply (enforce with -f)
stderr: ')
ERROR: Logfile of failure stored in: /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/temp/log.do_patch.549831
ERROR: Task (/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-iotedge/recipes-core/aziotctl/aziotctl_1.5.0.bb:do_patch) failed with exit code '1'

@maskimthedog Would you be interested in trying this recipe?

Sure. I’ll kick a build off here in a bit.

ERROR: aziotctl-1.5.0.AUTOINC+0f93f7a544-r0 do_patch: Applying patch '0001-Change-panic-strategy-to-unwind.patch' on target directory '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/git' CmdError('quilt --quiltrc /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: Applying patch 0001-Change-panic-strategy-to-unwind.patch patching file Cargo.toml Hunk #1 FAILED at 54. 1 out of 1 hunk FAILED -- rejects in file Cargo.toml Patch 0001-Change-panic-strategy-to-unwind.patch does not apply (enforce with -f)
stderr: ') ERROR: Logfile of failure stored in: /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/temp/log.do_patch.549831 ERROR: Task (/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-iotedge/recipes-core/aziotctl/aziotctl_1.5.0.bb:do_patch) failed with exit code '1'

the patch files have been removed.. Why does it apply it?

@maskimthedog Would you be interested in trying this recipe?

Sure. I’ll kick a build off here in a bit.

ERROR: aziotctl-1.5.0.AUTOINC+0f93f7a544-r0 do_patch: Applying patch '0001-Change-panic-strategy-to-unwind.patch' on target directory '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/git' CmdError('quilt --quiltrc /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: Applying patch 0001-Change-panic-strategy-to-unwind.patch patching file Cargo.toml Hunk #1 FAILED at 54. 1 out of 1 hunk FAILED -- rejects in file Cargo.toml Patch 0001-Change-panic-strategy-to-unwind.patch does not apply (enforce with -f)
stderr: ') ERROR: Logfile of failure stored in: /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/temp/log.do_patch.549831 ERROR: Task (/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-iotedge/recipes-core/aziotctl/aziotctl_1.5.0.bb:do_patch) failed with exit code '1'

the patch files have been removed.. Why does it apply it?

Interesting…I’ll poke around a bit

@maskimthedog Would you be interested in trying this recipe?

Sure. I’ll kick a build off here in a bit.

ERROR: aziotctl-1.5.0.AUTOINC+0f93f7a544-r0 do_patch: Applying patch '0001-Change-panic-strategy-to-unwind.patch' on target directory '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/git' CmdError('quilt --quiltrc /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: Applying patch 0001-Change-panic-strategy-to-unwind.patch patching file Cargo.toml Hunk #1 FAILED at 54. 1 out of 1 hunk FAILED -- rejects in file Cargo.toml Patch 0001-Change-panic-strategy-to-unwind.patch does not apply (enforce with -f)

stderr: ') ERROR: Logfile of failure stored in: /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0.AUTOINC+0f93f7a544-r0/temp/log.do_patch.549831 ERROR: Task (/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-iotedge/recipes-core/aziotctl/aziotctl_1.5.0.bb:do_patch) failed with exit code '1'

the patch files have been removed.. Why does it apply it?

Interesting…I’ll poke around a bit

@ggjjj I am working with the Kirkstone branch.  None of our projects have moved beyond it yet.

@ggjjj did not see that this recipe was on a fork.  I pulled it, modified layer.conf to add kirkstone but unfortunately had an issue...
rkrakora@DvYoctoVm2204:~/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build$ cat /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky
-linux/aziotctl/1.5.0-r0/temp/log.do_install.2804029
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are ['/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-rust/recipes-devtools/rust/libstd-rs_1.73.0.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-rust/recipes-devtools/rust/rust-cross_1.73.0.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-virtualization/recipes-containers/docker/docker-ce_git.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-connectivity/openssl/openssl_3.0.12.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-core/glibc/glibc_2.35.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/gcc/gcc-cross_11.4.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/gcc/gcc-runtime_11.4.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-rust/recipes-devtools/cargo/cargo_1.73.0.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/python/python3_3.10.13.bb:do_populate_sysroot']
NOTE: Installed into sysroot: []
NOTE: Skipping as already exists in sysroot: ['libstd-rs', 'rust-cross-corei7-64-glibc', 'docker-ce', 'openssl', 'glibc', 'gcc-cross-x86_64', 'gcc-runtime', 'quilt-native', 'cargo-native', 'patch-native', 'pseudo-native', 'python3-native', 'attr-native', 'libtool-native', 'linux-libc-headers', 'libgcc', 'update-rc.d', 'notary', 'libseccomp', 'libtool', 'sqlite3', 'grpc-go', 'base-files', 'go-mux', 'go-fsnotify', 'go-connections', 'go-capability', 'go-systemd', 'compose-file', 'shadow', 'go-patricia', 'shadow-sysroot', 'go-cli', 'initscripts', 'shadow-native', 'go-logrus', 'go-pty', 'lvm2', 'go-distribution', 'go-runtime', 'go-context', 'base-passwd', 'go-dbus', 'btrfs-tools', 'rust-native', 'xz-native', 'ca-certificates-native', 'openssl-native', 'curl-native', 'zlib-native', 'libssh2-native', 'opkg-utils', 'gnu-config-native', 'gmp-native', 'texinfo-dummy-native', 'binutils-cross-x86_64', 'zstd-native', 'mpfr-native', 'libmpc-native', 'flex-native', 'gdbm-native', 'libffi-native', 'bzip2-native', 'util-linux-libuuid-native', 'sqlite3-native', 'readline-native', 'ncurses-native', 'libtirpc-native', 'libnsl2-native', 'rust-llvm-native', 'gettext-minimal-native', 'libxcrypt', 'attr', 'libaio', 'util-linux', 'systemd', 'e2fsprogs', 'lzo', 'python3', 'zlib', 'perl-native', 'm4-native', 'cmake-native', 'ncurses', 'util-linux-libuuid', 'bash-completion', 'libcap-ng', 'libxkbcommon', 'acl', 'kmod', 'libcap', 'zstd', 'autoconf-archive', 'libffi', 'gdbm', 'xz', 'libtirpc', 'libnsl2', 'bzip2', 'readline', 'make-native', 'libxcb', 'xkeyboard-config', 'libxml2', 'wayland-protocols', 'wayland', 'libpthread-stubs', 'xorgproto', 'xcb-proto', 'libxau', 'libxdmcp', 'util-macros', 'expat']
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing shell function do_install
install: cannot stat '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0-r0/build/target/x86_64-unknown-linux-gnu/release/aziotctl': No such file or directory
WARNING: exit code 1 from a shell command.
rkrakora@DvYoctoVm2204:~/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build$

Looks like it failed during install because of a path issue...seemed to build...
rkrakora@DvYoctoVm2204:~/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build$ ls -l /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0-r0/build/target/x86_64-unknown-linux-gnu/release/aziotctl
ls: cannot access '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0-r0/build/target/x86_64-unknown-linux-gnu/release/aziotctl': No such file or directory
rkrakora@DvYoctoVm2204:~/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build$ ls -l /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0-r0/build/target/x86_64-poky-linux/release/
total 125476
-rwxr-xr-x  2 rkrakora rkrakora 128410632 Jul 24 15:15 aziotctl
-rw-r--r--  1 rkrakora rkrakora     14880 Jul 24 15:15 aziotctl.d
drwxr-xr-x 37 rkrakora rkrakora      4096 Jul 24 15:14 build
drwxr-xr-x  2 rkrakora rkrakora     40960 Jul 24 15:15 deps
drwxr-xr-x  2 rkrakora rkrakora      4096 Jul 24 15:14 examples
drwxr-xr-x  2 rkrakora rkrakora      4096 Jul 24 15:14 incremental
rkrakora@DvYoctoVm2204:~/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build$

@ggjjj` did not see that this recipe was on a fork. I pulled it, modified layer.conf to add kirkstone but unfortunately had an issue...
rkrakora@DvYoctoVm2204:~/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build$` cat /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky
-linux/aziotctl/1.5.0-r0/temp/log.do_install.2804029
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are ['/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-rust/recipes-devtools/rust/libstd-rs_1.73.0.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-rust/recipes-devtools/rust/rust-cross_1.73.0.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-virtualization/recipes-containers/docker/docker-ce_git.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-connectivity/openssl/openssl_3.0.12.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-core/glibc/glibc_2.35.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/gcc/gcc-cross_11.4.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/gcc/gcc-runtime_11.4.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-rust/recipes-devtools/cargo/cargo_1.73.0.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/python/python3_3.10.13.bb:do_populate_sysroot']
NOTE: Installed into sysroot: []
NOTE: Skipping as already exists in sysroot: ['libstd-rs', 'rust-cross-corei7-64-glibc', 'docker-ce', 'openssl', 'glibc', 'gcc-cross-x86_64', 'gcc-runtime', 'quilt-native', 'cargo-native', 'patch-native', 'pseudo-native', 'python3-native', 'attr-native', 'libtool-native', 'linux-libc-headers', 'libgcc', 'update-rc.d', 'notary', 'libseccomp', 'libtool', 'sqlite3', 'grpc-go', 'base-files', 'go-mux', 'go-fsnotify', 'go-connections', 'go-capability', 'go-systemd', 'compose-file', 'shadow', 'go-patricia', 'shadow-sysroot', 'go-cli', 'initscripts', 'shadow-native', 'go-logrus', 'go-pty', 'lvm2', 'go-distribution', 'go-runtime', 'go-context', 'base-passwd', 'go-dbus', 'btrfs-tools', 'rust-native', 'xz-native', 'ca-certificates-native', 'openssl-native', 'curl-native', 'zlib-native', 'libssh2-native', 'opkg-utils', 'gnu-config-native', 'gmp-native', 'texinfo-dummy-native', 'binutils-cross-x86_64', 'zstd-native', 'mpfr-native', 'libmpc-native', 'flex-native', 'gdbm-native', 'libffi-native', 'bzip2-native', 'util-linux-libuuid-native', 'sqlite3-native', 'readline-native', 'ncurses-native', 'libtirpc-native', 'libnsl2-native', 'rust-llvm-native', 'gettext-minimal-native', 'libxcrypt', 'attr', 'libaio', 'util-linux', 'systemd', 'e2fsprogs', 'lzo', 'python3', 'zlib', 'perl-native', 'm4-native', 'cmake-native', 'ncurses', 'util-linux-libuuid', 'bash-completion', 'libcap-ng', 'libxkbcommon', 'acl', 'kmod', 'libcap', 'zstd', 'autoconf-archive', 'libffi', 'gdbm', 'xz', 'libtirpc', 'libnsl2', 'bzip2', 'readline', 'make-native', 'libxcb', 'xkeyboard-config', 'libxml2', 'wayland-protocols', 'wayland', 'libpthread-stubs', 'xorgproto', 'xcb-proto', 'libxau', 'libxdmcp', 'util-macros', 'expat']
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing shell function do_install
install: cannot stat '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0-r0/build/target/x86_64-unknown-linux-gnu/release/aziotctl': No such file or directory
WARNING: exit code 1 from a shell command.
rkrakora@DvYoctoVm2204:~/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build$

This recipe is for Scrathgap only. How did you manage it for kirkstone?

@ggjjj` did not see that this recipe was on a fork. I pulled it, modified layer.conf to add kirkstone but unfortunately had an issue...
rkrakora@DvYoctoVm2204:~/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build$` cat /home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky
-linux/aziotctl/1.5.0-r0/temp/log.do_install.2804029
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are ['/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-rust/recipes-devtools/rust/libstd-rs_1.73.0.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-rust/recipes-devtools/rust/rust-cross_1.73.0.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-virtualization/recipes-containers/docker/docker-ce_git.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-connectivity/openssl/openssl_3.0.12.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-core/glibc/glibc_2.35.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/gcc/gcc-cross_11.4.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/gcc/gcc-runtime_11.4.bb:do_populate_sysroot', '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/quilt/quilt-native_0.67.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/../meta-rust/recipes-devtools/cargo/cargo_1.73.0.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/patch/patch_2.7.6.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', 'virtual:native:/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/meta/recipes-devtools/python/python3_3.10.13.bb:do_populate_sysroot']
NOTE: Installed into sysroot: []
NOTE: Skipping as already exists in sysroot: ['libstd-rs', 'rust-cross-corei7-64-glibc', 'docker-ce', 'openssl', 'glibc', 'gcc-cross-x86_64', 'gcc-runtime', 'quilt-native', 'cargo-native', 'patch-native', 'pseudo-native', 'python3-native', 'attr-native', 'libtool-native', 'linux-libc-headers', 'libgcc', 'update-rc.d', 'notary', 'libseccomp', 'libtool', 'sqlite3', 'grpc-go', 'base-files', 'go-mux', 'go-fsnotify', 'go-connections', 'go-capability', 'go-systemd', 'compose-file', 'shadow', 'go-patricia', 'shadow-sysroot', 'go-cli', 'initscripts', 'shadow-native', 'go-logrus', 'go-pty', 'lvm2', 'go-distribution', 'go-runtime', 'go-context', 'base-passwd', 'go-dbus', 'btrfs-tools', 'rust-native', 'xz-native', 'ca-certificates-native', 'openssl-native', 'curl-native', 'zlib-native', 'libssh2-native', 'opkg-utils', 'gnu-config-native', 'gmp-native', 'texinfo-dummy-native', 'binutils-cross-x86_64', 'zstd-native', 'mpfr-native', 'libmpc-native', 'flex-native', 'gdbm-native', 'libffi-native', 'bzip2-native', 'util-linux-libuuid-native', 'sqlite3-native', 'readline-native', 'ncurses-native', 'libtirpc-native', 'libnsl2-native', 'rust-llvm-native', 'gettext-minimal-native', 'libxcrypt', 'attr', 'libaio', 'util-linux', 'systemd', 'e2fsprogs', 'lzo', 'python3', 'zlib', 'perl-native', 'm4-native', 'cmake-native', 'ncurses', 'util-linux-libuuid', 'bash-completion', 'libcap-ng', 'libxkbcommon', 'acl', 'kmod', 'libcap', 'zstd', 'autoconf-archive', 'libffi', 'gdbm', 'xz', 'libtirpc', 'libnsl2', 'bzip2', 'readline', 'make-native', 'libxcb', 'xkeyboard-config', 'libxml2', 'wayland-protocols', 'wayland', 'libpthread-stubs', 'xorgproto', 'xcb-proto', 'libxau', 'libxdmcp', 'util-macros', 'expat']
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing shell function do_install
install: cannot stat '/home/rkrakora/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build/tmp/work/corei7-64-poky-linux/aziotctl/1.5.0-r0/build/target/x86_64-unknown-linux-gnu/release/aziotctl': No such file or directory
WARNING: exit code 1 from a shell command.
rkrakora@DvYoctoVm2204:~/_Src/Prod/KraftHeinz.Remix.Yocto/poky/build$

This recipe is for Scrathgap only. How did you manage it for kirkstone?

I cloned the scarthgap-1.5.5  branch from _https://github.com/jolting/meta-iotedge.git_ and replaced RUST_TARGET_SYS with TARGET_SYS in three .inc files.  I cloned meta-rust and checked out hash f6a80656953678f17de7d41343107112d99492d9 setting RUSTVERSION to 1.73.0.  I tried cloning meta-rust from the tip of main and it always yielded several compilation errors regardless to what version RUSTVERSION was set.  The build succeeds but I have yet to check how it runs on my target.

@ggjjj  @jolting I am not so sure meta-rust is incompatible with Scarthgap as the tip of main does not build for Kirkstone  either.  I had to go back to a commit on meta-rust on which we ran our last successful production build and then the build errors went away and it successfully built against @jolting Scarthgap-1.5.5 branch on his fork (with slight mods mentioned above).

This variable has been in meta-rust for about a decade, so it's not knew. I suspect that oe made some changes to avoid issues in canadian builds where target, host and build are all different.

This may be the patch that changed it.
<EMAIL_ADDRESS>

This may be the patch that changed it<EMAIL_ADDRESS>
Thanks.  On Kirkstone, it's usage in meta-iotedge breaks the build.  Had to revert to TARGET_SYS.  Not sure if TARGET_SYS breaks Scarthgap.  Trying to avoid separate recipes for each.  Clearly though, meta-rust does not support Scarthgap.  Sorry, I know very little about meta-rust.

@maskimthedog
There are issues with poky container for kirkstone as it ships with 1.59 Rust. This prevents it update the recipes for Kirkstone for both 1.4 and 1.5 LTS for IoT edge.  So the current recipe in this PR works for scrathgap as we do not have such dependencies with meta-rust

@maskimthedog
There are issues with poky container for kirkstone as it ships with 1.59 Rust. This prevents it update the recipes for Kirkstone for both 1.4 and 1.5 LTS for IoT edge. So the current recipe in this PR works for scrathgap as we do not have such dependencies with meta-rust

Yes, I know.  I used meta-rust at hash f6a80656953678f17de7d41343107112d99492d9  with 1.73% as preferred version of Rust as I mentioned above with the mod described above replacing RUST_TARGET_SYS with TARGET_SYS in the meta-iotedge .inc files.  @jolting mentions a repo for each Kirkstone and Scarthgap will have maintained since Kirkstone uses meta-rust and Scarthgap does not.

We need IoT Edge 1.5.x for Kirkstone and @jolting needs for Scarthgap.

@maskimthedog Do you mind trying to replace the first part of do_install with do_install::append?
The cargo_do_install pretty much does the install for us, so I think we can just leverage the existing install function.
- do_install () {
-     # Binaries
-     install -d ${D}${bindir}
-     install -m 755 ${WORKDIR}/build/target/${RUST_TARGET_SYS}/release/aziot-edged ${D}${bindir}/aziot-edged
+ do_install:append() {

- do_install () {
-     # Binaries
-     install -d ${D}${bindir}
-     install -m 755 ${WORKDIR}/build/target/${RUST_TARGET_SYS}/release/aziotd ${D}${bindir}/aziotd
+ do_install:append() {

Just delete this
do_install () {
    # Binaries
    install -d  "${D}${bindir}"
    install -m 755 "${WORKDIR}/build/target/${RUST_TARGET_SYS}/release/iotedge" ${D}${bindir}/iotedge
}

https://github.com/meta-rust/meta-rust/blob/a5136be2ba408af1cc8afcde1c8e3d787dadd934/classes/cargo.bbclass#L98
https://github.com/yoctoproject/poky/blob/7c1de3118fef96fa899ae5365f80ea8ccb1a5876/meta/classes-recipe/cargo.bbclass#L81
CARGO_TARGET_SUBDIR is computed differently for the two rust layers.

@maskimthedog Do you mind trying to replace the first part of do_install with do_install::append?
The cargo_do_install pretty much does the install for us, so I think we can just leverage the existing install function.
- do_install () {
-     # Binaries
-     install -d ${D}${bindir}
-     install -m 755 ${WORKDIR}/build/target/${RUST_TARGET_SYS}/release/aziot-edged ${D}${bindir}/aziot-edged
+ do_install:append() {

- do_install () {
-     # Binaries
-     install -d ${D}${bindir}
-     install -m 755 ${WORKDIR}/build/target/${RUST_TARGET_SYS}/release/aziotd ${D}${bindir}/aziotd
+ do_install:append() {

Just delete this
do_install () {
    # Binaries
    install -d  "${D}${bindir}"
    install -m 755 "${WORKDIR}/build/target/${RUST_TARGET_SYS}/release/iotedge" ${D}${bindir}/iotedge
}

https://github.com/meta-rust/meta-rust/blob/a5136be2ba408af1cc8afcde1c8e3d787dadd934/classes/cargo.bbclass#L98 https://github.com/yoctoproject/poky/blob/7c1de3118fef96fa899ae5365f80ea8ccb1a5876/meta/classes-recipe/cargo.bbclass#L81
CARGO_TARGET_SUBDIR is computed differently for the two rust layers.

Yes, I will give it a go.

@maskimthedog I pushed these changes. Let me know if that works for you.

@maskimthedog I pushed these changes. Let me know if that works for you.

Will do.

@maskimthedog I pushed these changes. Let me know if that works for you.

Will do.

@jolting your changes work great for Kirkstone.  I take it they build for Scarthgap?
@ggjjj just has to be made known that Kirkstone needs meta-rust at f6a80656953678f17de7d41343107112d99492d9  with preferred version set to 1.73% and Scarthgap uses Poky Rust.  When I tried to grab the tip of meta-rust and use it for Kirkstone, the build encountered all kinds of Rust compile errors for some reason.  So, I went back the the hash above from our last production build, set the preferred version to the latest Rust version available at that hash and hoped for the best.  Worked.

The install step changes do not break the scarthgap build.

@maskimthedog what were those errors with the latest meta-rust on kirkstone? Maybe a bug should be reported for meta-rust.

I’ll kick off another build with the meta-rust tip and post the errors here.

@maskimthedog what were those errors with the latest meta-rust on kirkstone? Maybe a bug should be reported for meta-rust.

Here is an excerpt:
ve_gdk_pixbuf --cfg system_deps_have_gio --cfg system_deps_have_glib --cfg system_deps_have_harfbuzz --cfg system_deps_have_libxml2 --cfg system_deps_have_pangocairo --cfg system_deps_have_pangoft2
| warning: method fixed_eq_cairo is never used
|    --> src/float_eq_cairo.rs:32:8
|     |
| 31  | pub trait FixedEqCairo {
|     |           ------------ method in this trait
| 32  |     fn fixed_eq_cairo(&self, other: &Self) -> bool;
|     |        ^^^^^^^^^^^^^^
|     |
| note: the lint level is defined here
|    --> src/lib.rs:145:46
|     |
| 145 | #![warn(nonstandard_style, rust_2018_idioms, unused)]
|     |                                              ^^^^^^
|     = note: #[warn(dead_code)] implied by #[warn(unused)]
|
| error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused
|    --> src/surface_utils/mod.rs:154:13
|     |
| 153 |             let p: *mut u8 = &mut self[y as usize * stride + x as usize * 4];
|     |                                   ------------------------------------------ backing allocation comes from here
| 154 |             *(p as *mut u32) = value;
|     |             ^^^^^^^^^^^^^^^^^^^^^^^^
|     |
|     = note: casting from u8 (1 bytes) to u32 (4 bytes)
|     = note: #[deny(invalid_reference_casting)] on by default
|
| warning: unused return value of Box::<T>::from_raw that must be used
|    --> src/xml/xml2_load.rs:371:5
|     |
| 371 |     Box::from_raw(ctx);
|     |     ^^^^^^^^^^^^^^^^^^
|     |
|     = note: call drop(Box::from_raw(ptr)) if you intend to drop the Box
|     = note: #[warn(unused_must_use)] implied by #[warn(unused)]
| help: use let _ = ... to ignore the resulting value
|     |
| 371 |     let _ = Box::from_raw(ctx);
|     |     +++++++
|
| warning: librsvg (lib) generated 5 warnings (3 duplicates)
| error: could not compile librsvg (lib) due to 1 previous error; 5 warnings emitted
|
| Caused by:
|   process didn't exit successfully: rustc --crate-name librsvg --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type staticlib --crate-type rlib --emit=dep-info,link -C opt-level=3 -C embed-bitcode=no -C metadata=cb75f0c24bd386f3 -C extra-filename=-cb75f0c24bd386f3 --out-dir /home/rkrakora/_Src

@maskimthedog what were those errors with the latest meta-rust on kirkstone? Maybe a bug should be reported for meta-rust.

I reported bug to meta-rust.

rebased.

I don't think iotedge uses librsvg. Where is that dependency coming from?

@maskimthedog I think librsvg in kirkstone is too old for the new rust compiler. However this dependency is part of gnome, not iotedge. If you can turn off gnome or backport the librsvg recipe in your build then it will be fine. Either way I don't see this as a blocker given the known workaround is to use an older meta-rust.

@maskimthedog I think librsvg in kirkstone is too old for the new rust compiler. However this dependency is part of gnome, not iotedge. If you can turn off gnome or backport the librsvg recipe in your build then it will be fine. Either way I don't see this as a blocker given the known workaround is to use an older meta-rust.

Ah, thanks for looking at this.

@maskimthedog I think librsvg in kirkstone is too old for the new rust compiler. However this dependency is part of gnome, not iotedge. If you can turn off gnome or backport the librsvg recipe in your build then it will be fine. Either way I don't see this as a blocker given the known workaround is to use an older meta-rust.

Ah, thanks for looking at this.

I will look at updating librsvg for our Kirkstone build and see what happens.

@maskimthedog The head of meta-rust gets further on 1.78. 1.73, 1.75 breaks during the rust compiler build. 1.78 breaks in iotedge.

@maskimthedog The head of meta-rust gets further on 1.78. 1.73, 1.75 breaks during the rust compiler build. 1.78 breaks in iotedge.

Yep, that is what I noticed as well.  I ended up checking out at the hash I previously mentioned and set Rust version to 1.73.

@maskimthedog The head of meta-rust gets further on 1.78. 1.73, 1.75 breaks during the rust compiler build. 1.78 breaks in iotedge.

@jolting yep, that is what I noticed as well. I ended up checking out at the hash I previously mentioned and set Rust version to 1.73.

@jolting upgrading librsvg on Kirkstone is a bit of a rabbit hole and not recommended IMHO.

@maskimthedog The head of meta-rust gets further on 1.78. 1.73, 1.75 breaks during the rust compiler build. 1.78 breaks in iotedge.

@jolting yep, that is what I noticed as well. I ended up checking out at the hash I previously mentioned and set Rust version to 1.73.

@jolting upgrading librsvg on Kirkstone is a bit of a rabbit hole and not recommended IMHO.

@jolting what next?  Just add something to README about meta-rust at 1.73 and hash I mentioned previously for Kirkstone or do we investigate further and get running off of head of meta-rust with librsvg update plus whatever else is needed?

This is Kirkstone without upgrading librsvg?

Forget it.  It's part of Gnome.  Upgrading it (somewhat challenging) or omitting Gnome fixes.

Forget it. It's part of Gnome. Upgrading it (somewhat challenging) or omitting Gnome fixes.

Was just told we need Gnome…so librsvg issue is somewhat unique to us.

@maskimthedog
Yep. run
scripts/fetch.sh kirkstone
scripts/build.sh kirkstone

Dead code warnings were broken in 1.78.
https://github.com/rust-lang/rust/issues/120770
The workaround is to avoid treating warnings as errors.
Patch
edgelet/iotedge/src/lib.rs#L3
-#![deny(rust_2018_idioms, warnings)]
+#![deny(rust_2018_idioms)]

Then everything builds with rust 1.78 on kirkstone. I'll see about adding that patch to the recipe later.

@maskimthedog see here:
https://github.com/meta-rust/meta-rust/issues/450

Interesting

@ggjjj This should work for kirkstone and scarthgap now.

@ggjjj This should work for kirkstone and scarthgap now.

Builds fine for me for Kirkstone if librsvg from Gnome is dropped with meta-rust tip and RUSTVERSION set to 1.78%.  We need Gnome, so we build from meta-rust f6a80656953678f17de7d41343107112d99492d9 with RUSTVERSION set to 1.73% and that too builds fine.  Nice job @jolting.  Really appreciate your hard work and diligence on bringing this all together.

/azp run

Here are some feedback to get this PR merged. @jolting

Can you please move the export commands in the .bb files to .inc files
Please remove kirkstone templates and the handling of the templates in scripts as we keep them separately in kirkstone branch as a part of our branching strategy.
We are planning to release 1.5.7 so might need an update to bitbake files for the new version (probably early next week - 8/19)

Hi @ggjjj, the build has passed on our CI with tests so from my point of view it can be merged.


Use old row format for test to fix CI (#1356)

cherry-pick #1356 to release-2.1

/run-all-tests

/run-all-tests


go/adbc/driver/snowflake: add public/private SSH key authentication

I believe this is Snowflake's authentication option using public/private RSA generated keys..
// AuthTypeTokenAccessor is to use the provided token accessor and bypass authentication
AuthTypeTokenAccessor

https://github.com/apache/arrow-adbc/blob/cf3b5c0ec6279d2c3f8d48328cfe6dd92e250116/go/adbc/driver/snowflake/driver.go
	OptionValueAuthOkta:            gosnowflake.AuthTypeOkta,
	OptionValueAuthJwt:             gosnowflake.AuthTypeJwt,
	OptionValueAuthUserPassMFA:     gosnowflake.AuthTypeUsernamePasswordMFA,

https://github.com/snowflakedb/gosnowflake/blob/master/auth.go

const (
    // AuthTypeSnowflake is the general username password authentication
    AuthTypeSnowflake AuthType = iota
    // AuthTypeOAuth is the OAuth authentication
    AuthTypeOAuth
    // AuthTypeExternalBrowser is to use a browser to access an Fed and perform SSO authentication
    AuthTypeExternalBrowser
    // AuthTypeOkta is to use a native okta URL to perform SSO authentication on Okta
    AuthTypeOkta
    // AuthTypeJwt is to use Jwt to perform authentication
    AuthTypeJwt
    // AuthTypeTokenAccessor is to use the provided token accessor and bypass authentication
    AuthTypeTokenAccessor
    // AuthTypeUsernamePasswordMFA is to use username and password with mfa
    AuthTypeUsernamePasswordMFA
)

Going to close this. I think JWT covers private/public keys..
https://github.com/snowflakedb/gosnowflake/blob/master/cmd/keypair/keypair.go

Going to close this. I think JWT covers private/public keys..
https://github.com/snowflakedb/gosnowflake/blob/master/cmd/keypair/keypair.go


How to Integrate Ruby on Rails with React to Create Responsive Apps

Proposed title of article
How to Integrate Ruby on Rails with React to Create Responsive Apps
Proposed article introduction
In this article, will discuss the  two most frequent techniques to integrate ReactJS and Ruby on Rails in this article. You will be able to construct functional, seamless apps using this combination of technologies. The advantages of the React and Rails backends will be realized, namely their speed, dependability, lightweight, and limitless documentation. Most importantly, these technologies will increase the efficiency of your workforce.
ReactJS and Ruby on Rails make a great framework combination since both of them are widely known in web development
Article quality
This article is unique in that it offers good description of how to integrate ruby on rails .with the inclusion of React. The learners will get familiarized with the use of react and how it will help them in setting up their application.
References
N/A

Good afternoon and thank you for submitting your topic suggestion.
Your topic form has been entered into our queue and should be reviewed (for approval) as soon as a content moderator is finished reviewing the ones in the queue before it.

Thank you for submitting your topic @kymomolly.
However, after some careful consideration, it struck us that this topic may be a bit over-saturated throughout other blog sites and official documentation.
We typically refrain from publishing content that is covered widely on the net or other blogs. As we're more interested in original, practitioner-focused content that takes a deeper dive into programming-centric concepts.
Please feel free to suggest an alternative topic.


Add foolproof steps/script for SIX publishing

Accidentally published CoilDev-****

The UI doesn't update to match updated apks straight away. There's some lag.
Need to force close Samsung Internet, delete the preferences via adb, then restart to be sure.
The dev builds were originally suffixed with times for that very reason.

Added in #2056

Add steps/notes to release-checklist

#2057


Upgrade script fixes

Forward-port of https://github.com/crowbar/crowbar/pull/2264

+1

+1 this is port of already merged PR...

+1


Faster execution to enable all executable tests in apple/swift

Currently we filter out 2 test cases in Swift's CI due to poor performance issue of WasmKit  https://github.com/apple/swift/blob/d6f9401c28b7588b98b72bcf36bfcdac420e2425/utils/swift_build_support/swift_build_support/products/wasmstdlib.py#L140-L142

Measured benchmark on test/Concurrency/Runtime/clock.swift
0.0.8
./.build/release/wasmkit-cli run   313.22s user 0.05s system 99% cpu 5:13.28 total

a4ad4946561a28c0f048d59478ba8457463334a1
./.build/release/wasmkit-cli run   72.55s user 0.03s system 99% cpu 1:12.58 total

I think it's enough fast for our use case.


Required to install MongoDB operator to achieve High Availability of MongoDB

Currently, the MongoDB instance is not HA, we can install the MongoDB operator along with mongo to achieve HA. This MongoDB CRD allows for specifying the desired size and version as well as several other advanced options.

How do we add persistence to the MongoDB?

Hi @jnsrikanth, We need MongoDB's k8s operator to achieve high availability. Along with the Mongodb operator, we will use the MongoDB sts with PV to add the persistency.

My major question : What is mongo is used for ?!
Do I need to battle test its setup ? (probably....?)

@andre-taveira mongodb is used to store all the chaos-center specific details starting from users and projects to workflow runs and results. Everything is stored in mongo.


Add DEX support for Cryptopower btc wallet

Closes #337
EDIT: This PR uses github.com/ukane-philemon/dcrdex/add-custom-wallet-constructor  as a temp replacement of decred/dcrdex

Unsure if this matters at this point but posting bond with btc it never shows the tx is confirmed:

Testing on #353? Most fixes on the dex bonding page have been handled there. This PR only focuses on btc.

Testing on https://github.com/crypto-power/cryptopower/pull/353? Most fixes on the dex bonding page have been handled there. This PR only focuses on btc.

No here. I'll try again there. Feel free to ignore here.


[Proof] Change AccumulatorConsistencyProof to use the new format

Motivation
In https://github.com/libra/libra/pull/828 we decided to use this new format. Now change the code accordingly.
Have you read the Contributing Guidelines on pull requests?
Y.
Test Plan
CI.
Related PRs
None.

LGTM
@bors-libra delegate+

:v: @wqfish can now approve this pull request

@bors-libra r=zamsden

:pushpin: Commit b4b5bd0 has been approved by zamsden

:hourglass: Testing commit b4b5bd0247dde16838b88df6766dbeccc43c8097 with merge 05bde329c3c9aa662375e714face925af6cc40a0...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: zamsden
Pushing 05bde329c3c9aa662375e714face925af6cc40a0 to master...


Out of the box Istio install in AKS blocks internal traffic between services

Is this the right place to submit this?

[X] This is not a security vulnerability or a crashing bug
[X] This is not a question about how to use Istio

Bug Description
I'm assuming there's some default behaviour here, as I'm still experiencing this in 2024. Have tried many of the above solutions.
I have a vanilla AKS cluster with Istio enabled via the menu. I have made a new NS called bendev which has istio injection enabled via the label istio.io/rev: asm-1-20
The sidecars are injecting ok, but no matter which combination of the above solutions I try my internal services can't communicate.
I notice that by default there is no "catch-all" listener on <IP_ADDRESS>:443 for TLS traffic. This may be why I can't communicate to the API service without excludeIPs (this is the 1 solution that works). I don't really want to start moving traffic out of the mesh, however. I would rather figure out why this is happening.
I created some basic services, such as an nginx-deployment consisting of 3 replicas, behind a simple ClusterIP service.
I also created a long lived process pod which curls a bunch of internal service endpoints, then sleeps, to allow me the chance to exec into it. I'll call this netshoot
When using exec into the terminal, I can curl everything quite happily using the exact .  I am assuming this sidesteps Istio somehow.
However, when relying on the script, all of the curls fail (unless using excludeIPs) including the curl to the internal svc, nginx-deploy.bendev.svc.cluster.local:80
I can see a route for this does exist in the proxy config for the netshoot pod out of the box, due to this deployment having been created "on the watch" of istio
I have tried making a service entry to cover the kubernetes API, using location EXTERNAL/INTERNAL and resolution DNS/STATIC/NONE whilst switching the address to the local address for the kubernetes.default.svc server within the cluster (for me it is <IP_ADDRESS>)
I have tried to make a custom sidecar but I couldn't get it to inject, as per
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: default
namespace: aks-istio-system
spec:
egress:
- hosts:
- ./*
- default/kubernetes.default.svc.cluster.local
- default/etcd.default.svc.cluster.local
- aks-istio-system/*
I have also tried a virtual service in addition to the service-entry above, to create a listener on <IP_ADDRESS>/443 and a route
None of these things worked, and the script itself always fails
There are no authorization policies or peerauthentication requirements across the cluster.
I am also not getting any logs inside Envoy in the istio-proxy sidecar. Seems like my requests aren't even getting that far.
Version
$ istioctl version
client version: 1.22.2
control plane version: 1.22.2
data plane version: 1.22.2
$ kubectl version
Client Version: v1.29.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.28.10

Additional Information
No response

What url are you curling when trying to access mesh services (from inside a meshed pod of course)?

hello, for example http://nginx-deploy.bendev.svc:80

What url are you curling when trying to access mesh services (from inside a meshed pod of course)?

If you can curl your meshed service from a meshed pod, then istio is working as expected. Does NGINX have errors?

But that's what I'm saying, I can't - the curl doesn't work when running from the script.
It only works when you manually exec in and run the same commands.  It doesn't work when running directly from the pod in an automated/scripted fashion.  This suggests to me that doing manual commands is somehow circumventing Istio.
When running from the script

"Couldn't connect to server"
When running manually

I had thought maybe it is to do with some authentication issue - like it doesn't like the fact the user agent has less permissions than me, but like I say there's no AuthorizationPolicies in the cluster from Istio.
Any further advice?

Ok, so it seems it was a pod authorization issue. Using runAsUser: 1000 in the security context works. I also realised I didn't have logs turned on so having turned these on, I can see Envoy is working as expected. Thanks for the help


Fix Humboldt County, CA

Broken:
http://results.openaddresses.io/sources/us/ca/humboldt
New:
https://webgis.co.humboldt.ca.us/arcgis/rest/services/Parcels/MapServer

My home county!

On Apr 17, 2020, at 05:41, Justin Meyers<EMAIL_ADDRESS>wrote:

Broken:
http://results.openaddresses.io/sources/us/ca/humboldt
New:
https://webgis.co.humboldt.ca.us/arcgis/rest/services/Parcels/MapServer
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

humboldt_county_parcels_shapefile.zip
They disable the services for all, the link for them is https://webgis.co.humboldt.ca.us/arcgis/rest/services/Parcels/MapServer/0
Attached shapefile if machine will not work. Let me know if you need anything else from me. Thanks!


Naver en kr dictionary

Naver English-Korean dictionary

Closing: Please submit pull requests as source files, not as zipped extensions.
I'm sorry for the very long delay getting to this pull request, and for this copy-and-pasted message:
Thanks for your contribution! To get through my backlog, I'm now merging all reasonable pull requests.
Once done, I'm going to move all user-contributed extensions into a new contrib directory in the repo, so you will eventually find it there. After that, in due course, I will move some contributions back over to the main directory to be published.
Please bear with while I am working though a lot of pull requests at the moment.


WXWork: add an example for python

Please make sure you have read the Wechaty Puppet Service: WXWork from Wechaty Official Website before you continue writting this issue.
Question

there is no python example in your link

@sir1st  wxwork已经停止服务了，请确认使用的token。


Support efficient streaming BLS batch verification

We've implemented a single batch call for now, pending better answers about managing the memory of an FFI context/accumulator and the performance of many cgo calls.


CHEBI:74298, please add synonym

Hello ChEBI Team,
CHEBI:74298 (4Z,7Z,10Z,13Z,16Z,19Z)-docosahexaenoyl-CoA(4-)
may have maybe synonym 'cervonyl CoA', see
https://hmdb.ca/metabolites/HMDB0060198
There is also https://hmdb.ca/metabolites/HMDB0060199 but with an issue on the CoA structure I guess: the 3′-phosphoadenosine part is not in the canonical form
IUPAC Name
(2S)-4-({({[(2R,3S,4R,5R)-5-(6-amino-9H-purin-9-yl)-4-hydroxy-3-(phosphonooxy)oxolan-2-yl]methoxy}(hydroxy)phosphoryl)oxyphosphoryl}oxy)-N-[2-({2-[(4Z,7Z,10Z,13Z,16Z,19Z)-docosa-4,7,10,13,16,19-hexaenoylsulfanyl]ethyl}-C-hydroxycarbonimidoyl)ethyl]-2-hydroxy-3,3-dimethylbutanimidic acid
Thank very much, and of course open to discussion, should you have comments about this request
Anne

synonym now added. Thanks


⚠ Bofrost.de has degraded performance

In d58a4a2, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1202 ms

Resolved: Bofrost.de performance has improved in 18570cc.