Fix #8858: Allow decimal places for pCO2, pO2,. Fix #8859: Add additional unit of measure for pCO2 and pO2.

Proposed Changes
Fix #8858: Allowed decimal places for pCO2, pO2, and pH, enabling more precise input values.
Fix #8859: Added the option to switch units for pCO2 and pO2 between kPa and mmHg on ABG analysis fields.
@ohcnetwork/care-fe-code-reviewers
Merge Checklist

[ ] Add specs that demonstrate bug / test a new feature.
[ ] Update product documentation.
[ ] Ensure that UI text is kept in I18n files.
[ ] Prep screenshot or demo video for changelog entry, and attach it to issue.
[ ] Request for Peer Reviews
[ ] Completion of QA

Summary by CodeRabbit

New Features

Introduced functions for converting pressure measurements between mmHg and kPa.
Enhanced the ABGAnalysis component to support multiple unit options and conversion functions.

Improvements

Adjusted field properties in the ABGAnalysis component for better flexibility and usability.
Made the PropsWithUnits type publicly accessible for broader use in other components.

Bug Fixes

Updated min/max values and step values for specific fields to ensure accurate data entry.

[ ] Decimal places are autocompleting.
eg: when I type 96 and decimal as 2 it automatically completes to 20. not able to enter second place decimal.

[ ] not able to clear input if decimal places are typed in

[ ] max unit mentioned on wrong input message should be proper

[ ] cannot increase or decrease decimal values using upward and downward arrows in the field box.

[ ] the values are not being accepted at all

[ ] if you are adding additional units, along with reflection of the data in events, view details page of the log update and abg section, the units are also shown along with the data

@abhip161 what is the status on this PR

@abhip161 what is the status on this PR

Since abhi hasn't replied in 3 weeks, I'm gonna go ahead and take over 👍


suggestion: auto unload and messagle only prompt

First of all, thankyou for making these nodes and share for us, it's  great!!!!
Since the llama3.1 occupy very much of vram, could you add a choice of unloading model after generating prompts. Loading the models, could cause lowvraw mode or even out of cuda memory.
Another suggestion is, beside giving captions, it could be some other way we could make use of the LLM.
But the image input is complusory to link with. It is not free to use by this limitation.
Looking forwards for you reply :-)

I tried getting rid of the bespoke caching and using Comfy's memory management instead. It seems to be working well main...DrJKL:Comfyui_CXH_joy_caption:drjkl/devices

how do i fix this? it happens always after using the model a second time.

I tried getting rid of the bespoke caching and using Comfy's memory management instead. It seems to be working well main...DrJKL:Comfyui_CXH_joy_caption:drjkl/devices

how do i fix this? it happens always after using the model a second time.

I guess if you are out of vram memory, try  to unload all the model (comfyui has built in this function, at the top bar, there is an icon to do so)
well technically, joy_caption is too memory demanding, you could modify the code of the plugin to replace the llama3.1 (offical/ uncensored version) to a int4 version, I think, the result is more or less the same.
For the flux model,  actually use gguf version with a cpu loading node to make all the clip models running on cpu, and keep the gguf checkpoint to run in gpu.
It's just talk a loading model time at first, 20 sec more. But you could save at least 3gb vram for buffer.


feat(sourcemap): add "rayon" feature

#3198  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Boshen and the rest of your teammates on  Graphite


Reduce uploader lag while vehicle being driven and controlsd process -20 niceness

Recently a few of us have been having random occurrences of openpilot disengage steering while remaining fully active and without any errors on Arne's branch. The bzip2 command in uploader is known to cause a bit of lag, and usually is one of the biggest causes for these disengagements.
This sets the priority of controlsd to -20 and changes when openpilot compresses videos to only when the user is on a Wi-Fi connection at home or allow_cellular is true.
https://streamable.com/272mu

Could you please PM me the route you think that zip is causing controlsd lag?
We have a fix coming out soon that will help some cases of controlsd lag causing random disengagements.

Also, could you explain what you found to think that bzip2 is causing controlsd to lag? I'd like to verify this finding.

We did some testing on Arne's branch and he found that whenever we were experiencing lag spikes causing these random steering disengagements, bzip2 was the top process. It happens about every 5 to 10 minutes on a highway. Because his fork has so many custom additions, I'm guessing the bzip2 process is just the last thing to add enough lag to the processes to cause openpilot to lose control of steering for a few seconds while it catches up.
If I'm wrong about bzip2, it would still be a good idea to set the priority of controlsd higher.


I'm a student, but i'm mainly using go from the first day I started programming and now I'm using
it for 3 years. I coded a bunch of libraries, some targeting specific needs for different
OSes, the largest one is a TCP/HTTPs server library (Server v2).
What other languages do you have experience with?
I use regularly Javascript, Java, SQL databases (HTML and CSS if you consider them programming languages).

Related proposals

Has this idea, or one like it, been proposed before?
Yes, there have been a lot of proposals related to this topic.

If so, how does this proposal differ?
First of all, this proposal matches the official guidelines related to this topic.
Then it will be completely backwards compatible and will not introduce any weird
constructs that will preserve the readability and simplicity of the Go code.

Does this affect error handling?
Yes, the topic is the error handling.

If so, how does this differ from previous error handling proposals?
This does not to implement anything like a try-catch, considering that this is already
too similar to the panic-recover already present.
This proposal has more of a macro-like behaviour, reducing the possibility of overworking
on a new mechanic, with the risk of diverging from the Go principle of "error checking".

Error Handling Proposal
This proposal addresses the problem that affects every project written in Go
that has to deal with a lot of error handling, resulting in a very verbose
code, without removing the principle that you should always handle every
error returned by a function in the best way.
This would benefit every go programmer, considering it's about error handling, and
is a widely discussed topic among every programmer, even non-go ones.
Changes
The proposal, by adding only a new keyword to the language, the catch one, will add
to the language 2 new strictly related construct (more like 1 construct and 1 prefix):

the definition of an error-handler function that is relevant only for
the function it's declared in; this construct will be presented below
the explicit statement that you want to trigger the previously-declared function above;
this prefix will be presented below

The backwards compatibility will be discussed below along with code snippets showing the changes.
We will discuss also interaction between other language features, like goroutine functions ran with
the go keyword (this proposal has a similar concept, that is adding a prefix to a function call to
explicitly say that you want to tread that function differently from normal).
This proposal is not about performance improvements, but (with my knowledge) should not even affect it
in a bad way.
Introduction
Here is a good example of a code that would benefit from the introduction
of this concept:
package myPackage

import (
	"encoding/json"
	"fmt"
	"io"
	"os"
	"time"
)

type MyStruct struct {
	Message string    `json:"message"`
	Time    time.Time `json:"time"`
}

func LoadJSONFile(filePath string) (*MyStruct, error) {
	f, err := os.Open(filePath)
	if err != nil {
		return nil, fmt.Errorf("could not load json file <%s>: %w", filePath, err)
	}
        defer f.Close()

	data, err := io.ReadAll(f)
	if err != nil {
		return nil, fmt.Errorf("could not load json file <%s>: %w", filePath, err)
	}

	var result *MyStruct
	err = json.Unmarshal(data, result)
	if err != nil {
		return nil, fmt.Errorf("could not load json file <%s>: %w", filePath, err)
	}

	return result, nil
}

It's obvious that there is a lot of code that is redundant and verbose: this could be
fixed if we could tell the compiler what to do every time a function returns as the
last return-value an error and it is not nil, like a macro. Here is an example:
func LoadJSONFile2(filePath string) (*MyStruct, error) {
	// declaration of the `catch function`
	catch (err error) {
		// the return statement (if present) must match the calling function signature
		return nil, fmt.Errorf("could not load json file <%s>: %w", filePath, err)
	}

	f := catch os.Open(filePath)
        defer f.Close()

	data := catch io.ReadAll(f)

	var result *MyStruct
	catch json.Unmarshal(data, result)

	return result, nil
}

Note: in this proposal there are two different usage of the catch
keyword:

one is the declaration of the macro function, I will refer to
it as catch function
the other one is the request to handle an error with the catch function,
I will refer to it as catch prefix in the context of a function call

First Usage
The first usage of the catch keyword is to tell the compiler that from
this point until the end of the function, without inheritance
from other function calls inside, if you call other functions
with the catch prefix, it should implicitly call the catch function
only if err != nil.
To set the catch function you must use this syntax only:

catch (<variable_name> error) { ... }

without using func() { ... } or any pre-declared function (like with defer or go)
to underline that this catch function should be explicitly made
for this function errors and should not be handled by a function
that is used for every error in the program/package.
However once inside the catch function body, it's always possible
to call other functions as a normal function.
The catch function must not have a return signature (like a 'void'
function) because in reality it's implicitly matching the one
of the calling function (in this case (*MyStruct, error)).
This is also why the catch function must be declared inline.
Second Usage
The second use case of the catch keyword is by placing it
in front of a function call that has as the last return type an error.
By doing this you can avoid taking this last error and
tell the compiler to handle it automatically with the catch
function if the error is not nil (removing the need constantly use of the
construct if err != nil { ... }).
Function with named parameters in the return statement
The catch argument can have whatever name you desire, but it
must be an error. In this case if you named it err, the
one declared in the function signature would be shadowed.
func LoadJSONFile3(filePath string) (result *MyStruct, err error) {
	catch (catchErr error) {
		// This is what the catch function can be if the return
		// signature has variable names
		err = fmt.Errorf("could not load json file: %w", catchErr)
		return

		// Or directly
		return nil, fmt.Errorf("could not load json file: %w", err)
		// It has all the possible return statements that you
		// would have in a normal function body
	}

	// Same stuff ...

	return
}

Illegal Usage and Skip error check
func LoadJSONFile4(filePath string) (*MyStruct, error) {
	// This is illegal, because the `catch function` is not
	// declared at this point (like accessing a non-already
	// declared variable)
	fileStats := catch os.Stat()   // ILLEGAL

	catch (err error) {
		return nil, fmt.Errorf("could not load json file: %w", err)
	}

	// this is obviously illegal because i have not used the catch
	// prefix on the function call, preserving backwards compatibility
	f := os.Open(filePath)   // ILLEGAL
        defer f.Close()

	// This is how we already explicitly ignore returned errors and
	// this will be the only way to really ignore them
	data, _ := io.ReadAll(f)

	// also this is how we already ignore returned errors if the
	// function only returns one error. Not the absence of the
	// `catch` keyword before the function
	json.Unmarshal(data, result)
	return
}

Manually trigger the catch function
From now we are going to change the context a little bit
for the next sections
We will be using the same MyStruct with a message and a timestamp
and two functions, one private and one public with different
arguments but the same return signature, both used to create a new
instance of the struct.
This is widely used in packages that has a private method that exposes
more options and a public one that has less arguments and maybe also
does some sanity check first
The private method just checks if the message is not empty and asks
for an explicit timestamp that will be directly injected in the returned
struct.
The public method instead only asks for a message, the time will be
time.Now(), and also checks that the message is not on multiple lines.
var (
	MultilineError = errors.New("message is multiline")
)

func NewMyStruct(message string) (*MyStruct, error) {
	catch (err error) {
		return nil, fmt.Errorf("could not create MyStruct: %w", err)
	}

	if strings.Contains(message, "\n") {
		catch errors.New("message is multiline")
		// or
		catch MultilineError
		// or (similar)
		catch fmt.Errorf("message of length %d is multiline", len(message))
	}

	//... will be continued in the next code snippet
}

The catch function can be manually triggered by using the
catch keyword followed by an error value, this being the only
returned value of a function or a pre-existing variable.
In reality this is no so much different from what we have already
discussed above, but has a slightly different purpose, so here it is.
In fact the only thing that is doing is calling a function that returns only
an error (like the json.Unmarshal(...) before), but we surely know that the
returned error will not be nil.
Discussion
Functions returning other functions
Now let's see when a function returns in the end another function
with the same return signature. Here is the original code snippet:
func newMyStruct(message string, t time.Time) (*MyStruct, error) {
	if message == "" {
		return nil, errors.New("message can't be empty")
	}

	return &MyStruct{ Message: message, Time: t }, nil
}

func NewMyStruct(message string) (*MyStruct, error) {
	// previous stuff ...

	result, err := newMyStruct(message, time.Now())
	if err != nil {
		return nil, fmt.Errorf("could not create MyStruct: %w", err)
	}
	return result, err
}

In this case this is what the last return statement
will be equal to with the catch:
func newMyStruct(message string, t time.Time) (*MyStruct, error) {
	// Same as above ...
}

func NewMyStruct(message string) (*MyStruct, error) {
	catch (err error) {
		return nil, fmt.Errorf("could not create MyStruct: %w", err)
	}

	if strings.Contains(message, "\n") {
		catch errors.New("message is multiline")
	}

	return catch newMyStruct(message, time.Now())
}

And if you think that you should not modify the returned
values, you can always directly use
return newMyStruct(message, time.Now())

without the catch prefix: the compiler will know that you do not want
to execute the catch function on the error.
Inheritance
As previously mentioned, this is not like a defer-recover construct:
any error, even in the function called, is not handled by the most
recent version of the catch version, but only by the one inside the same
function body. In this way it be easier for an LSP (go vet, staticcheck
or others similar) to detect an improper use of the catch function.
One thing to be pointed out is that the catch function should not
be treated as a function variable, because there could be problems with
inline-declared function, especially used with goroutines:
A function like that does not have to match the "parent" function return
statement in which is declared, and normally doesn't (goroutines
function usually does not return anything): this breaks the principle behind the catch macro style and also goes against the reason why the
catch function must be declared for each distinct function,
that is to discourage the usage of a universal function handler for every
function in the program/package.
So:
func Foo() error {
	catch (err error) {
		return nil, fmt.Errorf("could not load json file: %w", err)
	}

	// Some stuff with error handling with the catch ...

	wg := new(sync.WaitGroup)
	wg.Add(2)

	go func() {
		defer wg.Done()
		value1, value2 := catch SomeFunctionThatReturnsAnError() // This is invalid

		// Use of the values ...
	}()

	f2 := func() {
		defer wg.Done()

		catch (err error) {
			log.Printf("error occurred in the second goroutine: %v\n", err)
			return
		}

		value1, value2 := catch SomeFunctionThatReturnsAnError() // This is completely valid

		// Use of the values ...
	}
	go f2()

	wg.Wait()
	return nil
}

The return statement inside the catch function
It was not previously mentioned, but the return statement
inside the catch function is not mandatory, in fact if you
would not use the return statement, the catch function will
be executed normally, doing everything it contains, and then
continuing the function execution.
Again, one thing is what the language lets you do, one thing
is what is actually correct to do in a program.
An example that demonstrates that this kind of logic is already
possible is the following:
func LoadJSONFileWithLogging(filePath string) *MyStruct {
	f, err := os.Open(filePath)
	if err != nil {
		log.Printf("could not load json file: %v", err)
	}
        defer f.Close()

	data, err := io.ReadAll(f)
	if err != nil {
		log.Printf("could not load json file: %v", err)
	}

	var result *MyStruct
	err = json.Unmarshal(data, result)
	if err != nil {
		log.Printf("could not load json file: %v", err)
	}

	return result
}
func LoadJSONFileWithCatchLogging(filePath string) *MyStruct {
	catch (err error) {
		log.Printf("could not load json file: %v", err)
	}

	f := catch os.Open(filePath)
        defer f.Close()

	data := catch io.ReadAll(f)

	var result *MyStruct
	catch json.Unmarshal(data, result)

	return result
}

Note: both functions do not return any error

Change of the catch function
One last thing that can be discussed is the possibility to change the
catch function behaviour inside the same function: honestly, I thing this
would be kind of overkill, if you have the need to constantly changing the
catch function, you would probably be better controlling each error
like we are used to. But an example would be like this:
func LoadJSONFile5(filePath string) (*MyStruct, error) {
	catch (err error) {
		return nil, fmt.Errorf("could not load json file: %w", err)
	}

	f := catch os.Open(filePath)
        defer f.Close()

	// Other stuff with more error handling with the first catch function ...

	catch (err error) {
		return nil, fmt.Errorf("another error while loading json file: %w", err)
	}
	// From now, every catch prefix will use this second catch function

	data := catch io.ReadAll(f)

	var result *MyStruct
	catch json.Unmarshal(data, result)

	return result, nil
}

How the compiler should behave (conceptually)
At compile time, considering the catch function is valid, the compiler should
literally insert that function's code in the right places as can be evinced from
the differences between the old and the new code.
Conclusions
I really think that this would make people save a lot of lines of code,
while not compromising readability of the code and backwards
compatibility. I think this could be even implemented, without considering
development time, in a go v1.21 or go v1.22.
This change will not make Go easier to learn, but not even harder. This should
make writing Go code, both for production and for personal use, more pleasing
and less tedious.
As stated before, this should not have any performance impact on programs, thanks
to the nature of this feature, that is being a like a macro. This obviously will
put more strain on the compiler and any LSP, but I don't think this will be huge.
This is my first proposal I do in my life so sorry if I missed some
aspects and I remain available for discussions.
Hope you like this idea. Thanks for the time dedicated to this proposal

The introduction of a new keyword makes this not backwards compatible.
This looks (almost?) identical to the error handling draft, feedback.
What's new from that?

Okay, genuinely I did not know anything about this draft and I feel bad about this. However, after reading it, the only things that differ are:

the handlers chaining possibility, obviously a nice to have
the existence of a default handler which is a return statement with zero values and the error, which makes impossible to handle errors and continue the execution of the function normally

For the first difference, I am sure that the chaining possibility has more value than being able to change the handler, considering that it is still possible by adding to the chain an handler with a return statement, essentially shadowing every previous handler.
But for the second difference, I think that would be sort of a limitation to have to return at the end of the chain:
Maybe a good way of dealing with this would be to have a default handler that is used when a catch statement is called without having explicitly declared any handler in scope, but as soon as you declare the first handler in the chain, the default handler is ignored.
One last thing, and it is for my better understanding: i thought that "being backwards compatible" meant that in the new version, every type of code written in previous versions would just work without any difference, but obviously any newer code written with the new statements and constructs would not work on older versions. So, if I am right, why adding a keyword would break backwards compatibility? (I'm also thinking about Generics).
I'm again sorry for not being aware of this draft.
Thanks for the time

Yes, as you say, adding a keyword is pretty much always incompatible, because it breaks code that has variables/types/functions/constants whose name is that keyword.
That doesn't mean that we can never add a new keyword.  After all, it's not hard to automatically rename all such objects.  But it does impose a significant cost.  All language changes have costs and benefits, and whether to adopt the language change requires weighing those costs and benefits.

Thanks for the insight.
But going back to the error handling, I am curious about the reasons why the catch statement would result in the enclosing function to exit (if the error is not nil), without having the possibility to handle the error in some way (maybe, like in my proposal, just by logging it) and let the function continue.
I also think that having a built-in implicit default handler is a really "nice to have", but maybe would encourage people to not handle errors in the most reasonable why. Normally is just enough to wrap that error inside a new error with additional description of the context: in fact, I don't think that this code
handle err {
    err = fmt.Errorf("this is the context: %w", err)
}

is so different and more verbose than
handle err {
    return zero_value_1, ..., zero_value_n-1, fmt.Errorf("this is the context: %w", err)
}

also because you have circumstances where the zero value for an operation is different from the zero value of the type (I am thinking about searching the index of something in a string, array, slice, ecc.)

@nixpare My take on your proposal.
Merit

Won't have performance issues due to inlining.

Demerit

Reduced Readability due to generalization and blocks in scopes

catch (err error) {
		return nil, fmt.Errorf("could not load json file: %w", err)
	}

I can see this has inspirations from JS, but it only works well cuz the functions raises error . In go rarely panic functions are return. Mostly they return err . It doesn't look better nor extensible that the current approach of if err!=nil.
My Proposition is that

If there could be someway replace if err!=nil{} with catch err{} or if err[if with generic support of error along with bool] as its very common for typos like err==nil.

No okay, as @seankhliao pointed out, now we are talking about changes that, at least for me, should be made to the original draft about error handling. Maybe this proposal should have a different title now and I should add at the top of my proposal a note that guides to what we are talking about now, leaving the rest of the message intact to keep the entire context.

This looks (almost?) identical to the error handling draft, feedback. What's new from that?

So, given that we take everything as it is in the draft mentioned above, that has all the same principle as mine (just more polished and with some syntax differences), the only problem that I have with the original draft is that if you call a function with a check, the enclosing function at the end will always return, there is no way you can keep the function alive (quote taken from the draft:)

For non-nil values, check calls the handler chain with this value, sets the return values, if any, with the results, and returns from the enclosing function.

For dealing with this problem, in my previous post, I proposed the fact that the default handler (which is the cause for inevitable return statement) should be there until the first handle statement was declared in the function explicitly.
Maybe another way to handle this (sorry for the word) is to add the possibility to control the chain flow with continue and break statements, where the first one would jump the execution to the next handler directly, and the second one would instead exit the handler chain.

I all of these examples in this proposal are leaking a file descriptor by not closing the opened file on error. I might have missed it, but I don't see a way to register cleanup functions, to be executed upon error.

All of these examples in this proposal are leaking a file descriptor, by not closing a file on error. I might have missed it, but I don't see a way to register cleanup functions, which could have helped here.

I you are talking about the examples in my code, you kind of right, I missed the f.close(), but that's not the point of this discussion (defer function would still work without problems).
However, for the sake of correctness, I will update the code snippets.

defer function would still work without problems

No, it won't. For a simple cases, yes. But for some resources you want to close them as soon as you are done with them. Defering every close by default would make you to double-close such resources. Defer is not a solution for the problem I mentioned.

However, for the sake of correctness, I will update the code snippets.

It would be greatly appreciated, a proposal should have if not real-world use-cases, then at least correct examples.

I think to have understood what you mean and you are completely right. I'll try to explain with some
prototype code:
Old and wrong way to do it:
func heavyWorkload() error {
	resource, err := loadHeavyResource()
	if err != nil {
		return err
	}
	defer resource.release()

	data, err := resource.useResource()
	if err != nil {
		return err
	}

	// some other long procedures that use data

	return nil
}

In this case the heavy resource will be released only at the end of the enclosing function.
Old and right way to do it:
func heavyWorkload() error {
	resource, err := loadHeavyResource()
	if err != nil {
		return err
	}

	data, err := useResource(resource)
	resource.release()
	if err != nil {
		return err
	}

	// some other long procedures that use data from the resource

	return nil
}

One way to handle this would be to wrap a portion of the code in another function
(maybe an anonymous one) like so:
func heavyWorkload() error {
	handle err {
		return fmt.Errorf("heavy workload error: %w", err)
	}

	data := catch func() ([]byte, error) {
		resource, err := loadHeavyResource()
		if err != nil {
			return nil, err
		}
		defer resource.release()

		return useResource(resource)
	}()

	// some other long procedures that use data from the resource

	return nil
}

In this case, I admit, it's a little bit clunky, but would also add the benefit
of releasing the resource if a panic occurs in the function useResource(resource).
Or another way of addressing this would be to use the catch <error_value> statement:
func heavyWorkload() error {
	handle err {
		return fmt.Errorf("heavy workload error: %w", err)
	}

	resource := catch loadHeavyResource()

	data, err := useResource(resource)
	resource.release()
	catch err

	// some other long procedures that use data from the resource

	return nil
}

Probably a lot more readable, but would not work if you have to use the resource more
than one time and the are more point of "failure". For dealing with that you just could use a flag:
func heavyWorkload() error {
	handle err {
		return fmt.Errorf("heavy workload error: %w", err)
	}

	resource := catch loadHeavyResource()

	var resourceReleased bool // set to false
	releaseResourceFunc := func() {
		if !resourceReleased {
			resource.release()
			resourceReleased = true
		}
	}

	handle err {
		releaseResourceFunc()
	}

	data1 := catch useResourceFirstTime(resource)

	// use data1 ...

	data2 := catch useResourceSecondTime(resource)
	releaseResourceFunc()

	// some other long procedures that use data2 from the resource

	return nil
}

Again, not a huge fan of this implementation ...
Maybe the best way to handle this is:

have the resource aware of its state and allow for multiple
calls of the method resource.release()
create a function in some ways that manipulates the resource in the best
way and returns to the enclosing function as soon as the resource is not
needed anymore
in this sensitive case, maybe handle the resource without any handle - catch
construct

I think sometimes one feature can't be used for every use case, and will only
affect some people in not every scenario.
One last thing I did not have understoop from your comment (and don't get me wrong ...
you are completely right): do you think this is a problem that only my proposal erases or
you find it also in the Official Draft for Go 2 mentioned above?

@rjeczalik, I just thought about a less clunky way to handle the cleanup with a flag that would extend to other use cases (not only flags).
This is a soluzion that should replace the last code snippet in the previous post:
func heavyWorkload() error {
	handle err {
		return fmt.Errorf("heavy workload error: %w", err)
	}

	resource := catch loadHeavyResource()

	var resourceReleased bool
	handle err if !resourceReleased {
		resource.release()
	}

	data1 := catch useResourceFirstTime(resource)

	// use data1 ...

	data2 := catch useResourceSecondTime(resource)

        resourceReleased = true
	resource.release()

	// some other long procedures that use data2 from the resource

	return nil
}

So after the second handle declaration, when a function is called with the check statement, the resulting control statement underneath would be if err != nil && (<boolean_expression>) { ... }

This hurts readability too much, and holds too much overlap with just using a function in my opinion.
func LoadJSONFile(filePath string) (*MyStruct, error) {
	var err error
	errf := func() (*MyStruct, error) {
		return nil, fmt.Errorf("could not load json file <%s>: %w", filePath, err)
	}

	f, err := os.Open(filePath)
	if err != nil {
		return errf()
	}
        defer f.Close()

	data, err := io.ReadAll(f)
	if err != nil {
		return errf()
	}

	var result *MyStruct
	err = json.Unmarshal(data, result)
	if err != nil {
		return errf()
	}

	return result, nil
}

Thanks for the effort you've put into this proposal!
Considering your first example using catch, I can imagine a quite similar structure that works in today's Go:
func LoadJSONFile2(filePath string) (result *MyStruct, err error) {
	defer func() {
		if err != nil {
			err = fmt.Errorf("could not load json file <%s>: %w", filePath, err)
		}
	}()

	f, err := os.Open(filePath)
	if err != nil {
		return err
	}
        defer f.Close()

	data := io.ReadAll(f)
	if err != nil {
		return err
	}

	err = json.Unmarshal(data, result)
	if err != nil {
		return err
	}

	return result, nil
}

This variant preserves your goal of writing the error-wrapping call with its common prefix only once, but it does still require an if statement for each fallible call. In previous discussions it's been quite contentious whether removing the explicit error handling control flow is an advantage of a disadvantage, so of course it's debatable whether that aspect of my alternative above is an improvement or a drawback relative to what you showed.
The other notable drawback of my variant is that it requires naming the return values so that it's possible for the defer to mutate err while returning. Some argue that named return values should be avoided unless they are helpful for documentation, so this would appear to be a drawback for those people.
I don't really have a strong opinion on this proposal yet, but when thinking about proposals I like to try to imagine ways to achieve something as similar as possible using the current language, because that helps to consider what value the new language features are bringing. To me the above seems like a reasonable solution to the problem as stated, but I must admit I would be unlikely to actually write code like this because I tend not to make functions generate errors with information that the caller of the function already knows, and instead focus on describing the aspects of the problem that the caller cannot determine from its own context about what it was calling and what it passed in. The problem statement therefore doesn't really match a problem I have, but I acknowledge that others have different preferences for error message content.

hi, I also have a proposal for Go 2: Error-Handling, can you also comment it? thanks for your see
https://github.com/golang/go/issues/60779

Can go  support no if err != nil by default
func LoadJSONFile(filePath string) (*MyStruct, error) {//error must define
	f := os.Open(filePath)
        defer f.Close()
	data:= io.ReadAll(f)
	var result *MyStruct
	json.Unmarshal(data, result)
	return result, nil
}

This hurts readability too much, and holds too much overlap with just using a function in my opinion.

@webbongithub, thanks for your opinion. Personally, I know this is a subjective topic don' get me wrong, I don't think if hurts readability that much. I agree that there is a significant overlap with the alternative solution you proposed, but adding a new way to do the same things with a slightly different syntax it's not always a bad thing.
I see a relation like this behing the one between the standard for loop and the for range, let me explain:

they technically do the same things (the for range just let you avoid using the v[i] syntax;
the for range (over an array, e.g.) does not even let you modify the value stored persistently (expect using the standard syntax with the index);
the for range does not even reduce the number of lines to write and the readability (personally) is quite the same;
If someone told me that they would remove for ranges in Go 2, I would be really mad.

func LoadJSONFile(filePath string) (*MyStruct, error) {
	handle err {
		return nil, fmt.Errorf("could not load json file <%s>: %w", filePath, err)
	}

	f := catch os.Open(filePath)
        defer f.Close()

	data := catch io.ReadAll(f)

	var result *MyStruct
	catch json.Unmarshal(data, result)

	return result, nil
}

I honestly don't see why this would be so much unreadable. Just my honest opinion.
The thing is that nobody will prevent you from writing more "legacy" code.
Tell me what you think.

Can go support no if err != nil by default

@y1rn, The problem with this is that you are actually ignoring the error, and this is really a bad practice, in general.
It is not clear if you are ignoring a potential error from the function or if the function really never returns an error.
Instead if you wrote f, _ := os.Open(filePath), everyone would know that you are ignoring something, without having to
look at the documentation.
This is why the proposal has the catch statement, so that it is clear that you are handling an error returned in a "standard" way (has declared by the handle statement)

Can go support no if err != nil by default

@y1rn, The problem with this is that you are actually ignoring the error, and this is really a bad practice, in general. It is not clear if you are ignoring a potential error from the function or if the function really never returns an error. Instead if you wrote f, _ := os.Open(filePath), everyone would know that you are ignoring something, without having to look at the documentation. This is why the proposal has the catch statement, so that it is clear that you are handling an error returned in a "standard" way (has declared by the handle statement)

I mean f := os.Open(filePath) still pass err to caller for somewhere doesn't want to handle error if err != nil {return nil,err}, or do unified handle with defer

func LoadJSONFile(filePath string) (myStruct *MyStruct, err error) {//error must define
       defer func(){
         if errors.Is(err, BaseErr) {
           //...
         }
        }
	f := os.Open(filePath)
        defer f.Close()
	data:= io.ReadAll(f)
	var result *MyStruct
	json.Unmarshal(data, result)
	return result, nil
}

This looks do not need to change go syntax and good to write code, Problem is reviewer doesn't know where may return err.

@y1rn sorry but I can't understand if you are proposing another feature or if you are providing an example that would do the job in the current version of Go. Because if this is the second case, this code will never compile.
Instead if this is a proposal, I would be completely against it because you can't be sure about what the fuction called in the code you are reviewing really returns, maybe who wrote the program decided to ignore some return values, but this is not explicit anymore.

@apparentlymart I completely understand your approach on things and, as I also replied to another person, I understand that there are already ways to do the same thing with nothing more, nothing less.
But sometimes a feature does not exist just to implement a new concept not doable before, but to polish some already established ways of doing things that could make the language more enjoyable for someone else, especially if it comes from another language.
I think is a known fact that people that come from a try catch kind of language hate the verbosity of the error handling in Go, this would make the language more inviting (maybe).
Tell me what do you think

Thanks for the proposal and discussion.  As pointed out above, this is fairly similar to the earlier try/handle design draft, that was not adopted.  This direction seems to run into a lot of resistance.  Sorry.
Therefore, this is a likely decline.  Leaving open for three weeks for final comments.

I am not sure that i understand what you mean by macro.
It's like a  macro in which language?
I personally think this is verbose and doesn't fix things much.
Go should add the question mark operator, like Rust to automatically return errors.
func heavyWorkload() error {
	res1 := somethingThatCanFail()?
        res2 := somethingThatCanFail2()?

	return nil
}

@peter7891  Please see #32437. It was spelled try(), but basically the same idea. It was not well received.

@peter7891 Please see #32437. It was spelled try(), but basically the same idea. It was not well received.

i don't see any better solution than this.
Perhaps, the majority of the Go community doesn't see this as a problem.
In my opinion, the noise from error handling has a much more negative impact than adding this slightly more complicated Rust-like feature.
It is true that a lot of the people won't anotate errors, by implementing the interface.
While anotating errors is important for debugging, what is even more important is small code you can quickly understand.

How about something like this:
func LoadJSONFile(filePath string) (*MyStruct, error) {

    f := os.Open(filePath) catch ("could not open json file")
    defer f.Close()

    data := io.ReadAll(f) catch ("could not read json file") {
        // This is an optional code block to close something if needed.
        // After running this block it jumps to the catcher label below.
    }

    var result *MyStruct
    json.Unmarshal(data, result) catch ("could not unmarshal json file")

    return result, nil

catcher(err error, msg string):
    return nil, fmt.Errorf("%s <%s>: %w", msg, filePath, err)
}

catch catches the error then jumps to catcher label to handle the error. It would allow passing any number of arguments to catcher. Also catch can have an optional execution block that runs when an error occurrs, then jumps to catcher after that.

The catcher should be defined in the same scope of where it's called. just like goto calls
The real question is that whether multiple definitions of catcher in the same scope is allowed.
Also catcher is quite long.
How about break, raise, except, jmp??

Or even '?' name of catcher...

No change in consensus.


Changed the version support to ES6

Since ES6 is widely being used. I think it makes sense to change the version to ES6

Coverage remained the same at 98.755% when pulling 5b6d0ddbe33aa2361edb9eea724a3bcbf6259968 on nkgokul:master into 578575d0af7b71dc3e6071ac31915b8d28f989c5 on jshint:master.


emoji: Fix sort order of emoji choices

emoji_choices is an object of type OrderedDict and is sorted alphabetically when converted to JSON object, using Jinja's tojson template filter. So I disabled Jinja's sort_keys setting to fix this and prevent future sort issues in page_params object.
#13220
Testing Plan:
In templates/zerver/app/base.html we can simply add one temporary element to use for debugging:
<div hidden data-params='{{ page_params['emojiset_choices']|tojson }}'></div>
then change sort_keys setting to True|False in zproject/jinja2/__init__.py

I don't think sorting the keys in the JSON dump can be a correct fix, without adding a sort order field, because I don't think the browser is guaranteed to preserve the ordering of a dict. So I think the right fix here is still to add an explicit sort key to what we send to the server, and sort using that key in the frontend logic.
Though it's possible this happens to work and that's why this regressed recently (when we started sorting page_params in JSON dumping).  @andersk FYI.

ES6 does guarantee the preservation of object property order, but IE 11 does not, and it’s still considered bad form to rely on it even in modern browsers.

@timabbott @andersk Roger that. Reverted sort_keys and did a fix, using explicit order field.

I squashed your commits and pushed back to this PR to make it easier to review.

@timabbott ready

This looks great!  Merged as 16c9d63056b92828041c2467d0e6a31b9571f294, after squashing and fixing the commit message.  Please read that to see how commit messages should be written.
Check out the Zulip commit message guidelines for more details: https://zulip.readthedocs.io/en/latest/contributing/version-control.html#commit-messages
Thanks @fwyh!


HTML Entity Encoding in PlainTextErrorRenderer

Description
The PlainTextErrorRenderer in Slim Framework applies HTML entity encoding to exception messages via the htmlentities function. This behavior leads to the encoding of special characters in log messages and other plain text outputs, which might not be desired in all contexts.
Slim Framework Version
4
Steps to Reproduce

Use the PlainTextErrorRenderer to handle exceptions.
Trigger an exception with a message that includes characters that are typically encoded by htmlentities (like double quotes).
Observe the output (in logs, terminal, etc.) and notice that characters are HTML entity encoded (e.g., double quotes are converted to ").

Expected Behavior
In a plain text context, one would expect the error message to be rendered as-is, without HTML entity encoding. The use of htmlentities might be more appropriate for HTML-specific renderers.
Actual Behavior
The error message is HTML entity encoded, leading to representations like " in place of double quotes in plain text outputs.
Possible Solution
Consider removing the htmlentities call from the PlainTextErrorRenderer, or provide an option to disable HTML entity encoding based on the context in which the renderer is used.
Context
This encoding issue affects logging, CLI outputs, and other scenarios where HTML entity encoding is not desirable in error messages.
https://github.com/slimphp/Slim/blob/fdb6d614700a4e9390c3b08dde96e1f9147ec3fc/Slim/Error/Renderers/PlainTextErrorRenderer.php#L49

The easy solution to this is to create your own renderer. You can copy paste the plain text error render and modify it to your liking.
Feel free to propose an alternate solution. Being able to customize the renderer while keeping the existing behavior would be necessary in this case.

To my mind, this is a bug as we don't call htmlentities() on the JSON or XML error renderers. PR #3319 raised.


Patched instructions

Added instructions for reanimated and gesture handler.

Thank you for submitting a PR! I'm closing this PR because this issue was fixed in https://github.com/react-navigation/react-navigation.github.io/commit/1c5de7dd596638bc30b44fb5b48829bd87512c86


Any update on the code release?

I asked my mentor when shall I release the code just now and she said she'll discuss with me tomorrow.


Displaying of goals using APIs

I had to adjust a file so it is going to give conflicts. The original workflow stated that if the API fetching was successful but with no goals, It should display no goals component and if it has goals, It should display those goals. The workflow is also meant to show for loading if the api is loading and for error as well.
I had to tweak the goalItem file to accomodate the functionality stated above.
I have tested it and it is working. Here is a photo of it

There are some conflicting flies still. Please resolve them.

I have resolved the conflict now


Please Update To Latest Build

Need update to openwrt 23.05.3 latest update, your repo is amazing for me

i just changed the rules of some packages in ao-R4S-full.seed.orig and ao-R4S-full.seed but i want to build for R2S because in the repo there are no rules for changing R2S packages so i changed in R4S, but it always fails like picture, can you help me?

The kernel config needs some refresh too because the build does not have info about NET_SCH_CBQ
You need to add the line
# CONFIG_NET_SCH_CBQ is not set

in openwrt-23.05/steps/03_patch_openwrt.sh at line 55

build has completed, I will try it on my router tonight

I also tried it and succeeded, thank you

please read openwrt documentation first or ask in the openwrt forum.
you would find easily that you just need to add this line to /etc/opkg/customfeeds.conf

understand, I mean is there an additional script line for the custom feed before the build is run, maybe there is a script that needs to be added to the bottom line for the custom feed, I understand that this is vanilla openwrt if you want to add a custom feed line can you add the bottom line? and how should the script be executed?

The url you show contains .ipk files, already compiled packages.
So flash the cart and afterwards add "src/gz openwrt_kiddin9 https://dl.openwrt.ai/latest/packages/aarch64_generic/kiddin9" to /etc/opkg/customfeeds.conf
then run opkg update
and opkg install your extra packages.
If you want to add source packages to the build and build them, the way to do it is totally different, check how I integrate the stangri repository from source into my build.

I'm sorry, I have followed as far as I can but when the script makes me confused then that's where I have to stop because there is a lot I don't know about the build script but thank you for responding to all my complaints

I want to report an issue, after the first time I finished burning, Docker didn't work and couldn't display the web UI, for example Jellyfin

Do you have a desire to make immortalwrt the same as openwrt r2s? with the latest version of vanilla immortalwrt?


Unable to get satisfied records with condition

Hi,
Unable to get satisfied records that met the condition.
My array is,
$customer = [
0 => [
"customer_id" =><PHONE_NUMBER>042
],
1 => [
"customer_id" =><PHONE_NUMBER>810
],
2 => [
"customer_id" =><PHONE_NUMBER>578
],
3 => [
"customer_id" =><PHONE_NUMBER>346
],
4 => [
"customer_id" => null
],
];
Any my validation
final class Customer
{
public function __construct(
public readonly int $customer_id,
) {
//
}
}
$result = (new \CuyZ\Valinor\MapperBuilder)
->mapper()
->map(
'array<' . Customer::class . '>',
$customer
);
How can i get first four record those satisfied with the condition.
Please help anyone.

Hi @vinithanv, because the 5th row from the input contains an invalid value null, the whole mapping fails. You can get more insight about errors, read documention for more information.
Please note that this is an intended behaviour, if any value is invalid in the whole input, the whole mapping will fail and there is no way to get any data from it.


Optional is not properly managed in organization controller

Updating organizations when organization doesn't exist result in doing a get on a not set optional (see updateOrganizations in OrganizationController:255)

Only occurs when first findById worked but not the second due to another bug.


Test fail on module_test

System information

Operating system:  ubuntu 16.04 server
Compiler version:g++ (Ubuntu 5.4.0-6ubuntu1~16.04.6) 5.4.0 20160609
CMake version:cmake version 3.5.1
Relevant libraries/versions (e.g. CUDA): Cuda 9.1, CuDNN 7, one gtx1070

Test Fail
98% tests passed, 1 tests failed out of 57

Total Test time (real) =  50.74 sec

The following tests FAILED:
         14 - module_test (Failed)
Errors while running CTest
Makefile:83: recipe for target 'test' failed
make: *** [test] Error 8

Then, run module_test
$ ./module_test
Running main() from gtest_main.cc
[==========] Running 2 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 2 tests from ModuleTest
[ RUN      ] ModuleTest.StaticModule
[       OK ] ModuleTest.StaticModule (1 ms)
[ RUN      ] ModuleTest.DynamicModule
WARNING: Logging before InitGoogleLogging() is written to STDERR
E0201 12:26:02.470057 13045 operator.cc:130] Cannot find operator schema for Caffe2ModuleTestDynamicDummy. Will skip schema checking.
unknown file: Failure
C++ exception with description "[enforce fail at module.cc:103] handle != nullptr. Cannot load module caffe2_module_test_dynamic (with inferred filename libcaffe2_module_test_dynamic.so), are you sure it is in the dynamic linker search path? " thrown in the test body.
[  FAILED  ] ModuleTest.DynamicModule (0 ms)
[----------] 2 tests from ModuleTest (1 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 1 test case ran. (1 ms total)
[  PASSED  ] 1 test.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] ModuleTest.DynamicModule

 1 FAILED TEST

@xwzy
Have you solved this issue?


[Bug]: Custom fee too low required "5 bitcoin/vbyte" is not a useful suggestion

Describe the bug
When sending an onchain transaction with custom low sats/vbyte (e.g. 1) I see a "Fee is potentially too low" "current network conditions require that your fee should be greater than 5 bitcoin/vbyte" message.
Two issues here:

"5 bitcoin/vbyte" means something different to 5 sats/vB
6 sats/vB is still way too low for current network conditions, would need at least 60 sats/vB (right now). Is this hard coded?

Reproduce

Go to '...'
Click on '....'
Scroll down to '....'
See error

Screenshots / Recording

Operating system
Android 13 TKQ1.220829.002
Bitkit version
114
Log output
No response

@coreyphillips can you please change the bitcoin/vbyte for sats/vbyte, please?

Looks like it was already adjusted:
https://github.com/synonymdev/bitkit/blob/0eb32fa15728c888fab03d4b915f56ac1061ed45/src/utils/i18n/locales/en/wallet.json#L33


user stays permanently online

I often see users online for days, without being logged in to the system.
In the usersSession collection, there are still entries for session, which do not exist anymore...
I do experience that issue with Rocket.Chat, but I did not manage to find out, under which circumstances this happens.

This happens to us too.
From what I've been able to debug this condition here evaluates to false and the record is never removed.
I will had more details as soon as i found out more. Anyone has any idea?

This happens to us too.

ok, in our case it was an old version of this package. The commit solving #31 seems to fix everything.

Just wondering whether you needed to backport the meteor-user-presence, as this fix was already merged with RC 0.69.

Our team also noticed this same issue and unfortunately we had to add a batch job to regularly clean up some stale connections to instances that are no longer around after a deploy, etc.
Somewhat tangentially related I also added a PR here to fix a duplicate connection issue we noticed where Accounts.onLogin was sometimes triggered more than once resulting in two connections to the same instance:
https://github.com/Konecty/meteor-user-presence/pull/54


[Request] Redownload game background feature

Is your feature request related to a problem? Please describe.
My game updated the background and it seems to have failed midway. It looks like this:

Describe the solution you'd like
A button that lets you redownload the image.
Describe alternatives you've considered
I can delete the image in AppData\LocalLow\CollapseLauncher\GameFolder\_img\bg and restart the launcher, and it redownloads it.
Additional context
N/A

Thank you for reporting the issue. Actually we are already aware of this issue and if memory doesn't fail me somewhere there is a commit that handles that scenario in the background without having you click any button. It just wasn't pushed yet to any release build (stable/preview)

Fix proposal:
Implement a check in the background (after the BG has been displayed) if the downloaded BG is not downloaded correctly (has less size than the remote response). When true, delete the image on close (deleteOnClose) so it will be redownloaded on next restart or region load.

Fixed as of next stable release.


Fix asynchronous testing of signatures

The previous implementation mixed promises and callbacks in a way that was incompatible with mocha. This patch removes the callback and uses promises only. If the test failed, an "unhandled promise rejection warning" was emitted in recent Node.js versions.

This is much cleaner, thanks!


Allow build as framework using 'Framework' subspec

When the CocoaPods !use_framework option is enabled errors related to missing CocoaLumberjack arise.  This PR simply makes a subspec (and organizes appropriately) to allow building as a framework by specifying 'FLAnimatedImage/Framework'.
All the subspec currently does is include the CocoaLumberjack library as a dependency.

+1 for this. please merge

+1 please merge!

:+1: please merge this :)

A workaround while we wait for this to be merged in is to pass in the flag to disable lumberjack in this pod - add this to your podfile
post_install do |installer|
    installer.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            s = config.build_settings['GCC_PREPROCESSOR_DEFINITIONS']
            s = [ '$(inherited)' ] if s == nil;
            s.push('FLLumberjackIntegrationEnabled=0')
            config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = s
        end
    end
end

and run pod install

Please merge, please

Will look into this.

Hey @kdubb, I've removed FLAnimatedImage's dependency on CocoaLumberjack in https://github.com/Flipboard/FLAnimatedImage/commit/ca8a630232640935fa30f8a11c5c694388c57fce. Is this change still needed in light of that or can this PR be closed?

@timonus Sad to see it go but if you are going to yank it then I don't see a need for this PR.


Getting the address of a varnode (aka instruction operand)

(rephrased to better match sleigh terminology)
I'm working on a processor description for VAX and would need to get the address of an instruction operand.
VAX has one-byte opcodes followed by operands with variable (1 to 5 bytes) length.
Examples (not exact mnemonics)

one-byte opcode, two one-byte operands

00000000:   90 01 50                            -      MOVE.B S^1, R0

one-byte opcode, one two-byte operand, one four-byte operand

00000000:   90 CF 34 12 E0 78 56 34 12  -  MOVE.B (PC+0x1234), (R0 + 0x12345678)
Example 2 is the problem. The first operand ("CF 34 12") is PC-relative, it computes PC+0x1234, where PC is right after the final "12" value. In the example above, that would result in 0x1238.
Problem
To compute PC-relative offsets correctly, I need to know the operands memory address. However, neither inst_start, nor inst_next are usable here:

I can't use inst_start because the operand might be second and I don't know the size of the first operand.

I can't use inst_next because the operand might be first and I don't know the size of the second operand.

Are there any other options ?

Wow! Implementing the VAX instruction set in Ghidra sounds like a very large task., certainly well beyond my level. But as a longtime VMS user and hobbyist, I'd sure love to see the end product.
(Likewise for the PDP-11, if anyone is interested in taking up that architecture.)

Since this is static within the instruction, I think context might work well here. Use something like op_addr = (0,3) noflow
For the opcode, use [ op_addr = 1; ]
hen for each operand, you know how big it is, so you can increment op_addr each time. [ rel_addr = inst_start+op_addr; op_addr = op_addr + bytes; ] with bytes being however many bytes are consumed by the currend operand.

Thanks, something similar was my initial attempt.
During parsing, the op_addr was computed correctly but it seems as if the final computation is done after the instruction is completely matched. So ever operand came out with the same (set by the last operand) op_addr.
However, I didn't specify noflow - need to check this out.
Thanks again ! Will report here :wink:

You may need to add a globalsetas well? There's possibly some other shenanigans that may need to be employed, but I'm pretty confident this can be done with just context.

Were you able to get this to work?

Sorry, I was out last week.

For the opcode, use [ op_addr = 1; ]

Not clear where to use this, as the opcode is a field (and I can't add disassembly actions to it, can I ? 🤔)
I tried setting the offset (aka op_addr) for each instruction in a branch. Resetting the op_addr for each instruction works that way, but makes disassembly like 10 times slower :-(

For the opcode, use [ op_addr = 1; ]

Not clear where to use this, as the opcode is a field (and I can't add disassembly actions to it, can I ? thinking)

Solved this with a non-visible operand
op_code: epsilon is epsilon [ op_addr = 1; ] { export epsilon; }

Works nicely, as the op_addr value gets reset when I add ..; op_code; .. to the bit pattern section.
However, when computing operands, every operand gets the final op_addr value (after all operands are parsed) instead of the value at the respective operand position.

I now created a minified VAX processor description to visualize the problem better.
I use lifting-bits disassembler with this binary:
81 af 00 af 00 af 00

It should disassemble to
ADDB3 B^0x3, B^0x5, B^0x7

but doesn't.
Each operand disassembles to the same value. 😞

I've now tried all kind of combinations of context, noflow, globalset etc. All give the same result: When exporting the result, I get the final value (after all operand have been processed) and not the intermediate ones.
This doesn't come as a surprise to me since ghidra has to process all operands twice. Once for computing inst_next and then again for computing the disassembled values (which might include inst_next).

I've solved it now by introducing an operand_offset variable.
(Adding _printf_s to Ghidra pointed me to the right places, esp. showing that ParserWalker's value retrieval functions where called twice - once reading 4-byte-value to match against the disassembler spec and once reading correctly-sized values to compute the correct disassembly values)
See https://github.com/NationalSecurityAgency/ghidra/commit/f9a87889c24cfb6f677493cfdbe2685e302fe2f5 for the C++ part and https://github.com/NationalSecurityAgency/ghidra/commit/ecc24c7c9e73ee4f448b277bdbe15898cfab5de4 for the Java part.
operand_offset is modeled like inst_start but with a different getValue() implementation:
inst_start has
Address addr = walker.getAddr();
return addr.getAddressableWordOffset();

operand_offset has
return walker.getOffset(-1);

This works nicely and fixes the issue at hand.

Will #4812 be considered now ? 🥺

Sorry, I didn't realize this was tied to those PR's.

I found this issue because I searched for "VAX". I'm interested in this! However, I don't yet have any clue about Ghidra or Java. Is there any way to help with VAX support?
Just to add a comment: The VAX ISA does have one-byte and two-byte opcodes. So relying on them as one-byte long would be wrong. And then there's a ton of addressing modes. Plus the oddity of the CASE* instructions. Alas... I really would love to help here. It would be great to have something that helps to dissect machine ROMs or system binaries.

Hey @jbglaw , Ghidra VAX support is (mostly) done - except for #4812 😞 .
If you want to build from source, check out the vintage branch at https://github.com/kkaempf/ghidra-vintage
I'm also maintaining RPM packages for iopenSUSE Tumbleweed

I found this issue because I searched for "VAX". I'm interested in this! However, I don't yet have any clue about Ghidra or Java. Is there any way to help with VAX support?

Please check out and contribute to https://github.com/kkaempf/ghidra-vax 😉

Just to add a comment: The VAX ISA does have one-byte and two-byte opcodes. So relying on them as one-byte long would be wrong. And then there's a ton of addressing modes. Plus the oddity of the CASE* instructions.

This all should be working in ghidra.vax

Alas... I really would love to help here. It would be great to have something that helps to dissect machine ROMs

I'm already working on ROMs and I'd be happy to collaborate on http://ghidra-server.org/

Well, I just requested an account on ghidra-server.org. Let's see.
OTOH, as I'm a 100% newbie to Ghidra, my first step should be to get it running. Source builds seem to be not too trivial with Debian as it's missing build tools (at least in the requested version.)  And then there's that one outstanding patch. Are there chances those will be merged? At least it doesn't look as if it would break anything else.

Well, I just requested an account on ghidra-server.org. Let's see.

🤞🏻

OTOH, as I'm a 100% newbie to Ghidra, my first step should be to get it running. Source builds seem to be not too trivial with Debian as it's missing build tools (at least in the requested version.)

If you're not afraid of downloading binaries (like gradle) on your machine, building should be as simple as
gradle \
  -Dfile.encoding=UTF-8 \
  --project-prop finalRelease=true \
  buildNatives_linux64

This will give you a .tar file which you can extract locally and start ghidra from there.

And then there's that one outstanding patch. Are there chances those will be merged?

Ghidra (the project) is generally slow in merging outside contributions :-/

At least it doesn't look as if it would break anything else.

Certainly not. It's just exposing a value that is already tracked internally.

gradle is the issue here. But I think I'll give it a try in a Docker container. Maybe wrap a script around it to have a nice receipt for getting the final tarball.

So let's hope that this other PR is merged, and thereafter maybe the VAX CPU description. I'll try to get it working locally. :)

Successfully built Ghidra (plain upstream sources, though with buildGhidra instead of buildNatives_linux64. The resulting ZIP file contains a working Ghidra afterwards. Next step is to pull in your patch and the VAX CPU description.


Improve list-format handling, especially for union-list subtypes

This PR cleans up the handling of the "list-variant" flag of the format type by replacing the magic number with an internal constant and adding another helper.
It also enforces that the union-types of a union-list are automatically converted to list-types.

magic number improvement looks good, would like a simple test on that.  can that be in separate MR
there is a rogue change for reflection in there.  if intentional, that would need to be separated out into new MR with test as well
newValue,  it already knows result is a list, why would need bool to force anything.  a test would help me see where there is a failing

1/2 You are right, this needs to be splitup further... and I have to check where the change in "reflection" is coming from.

the problem happens when using the IETF "ip address" union in a leaf-list field... from the perspective of the yang-file, its a union-type with two pattern-matching string types... putting it into a leaf-list makes it a union-list with two string types (but not string lists), which means the wrong conversion is called when reading the field content from string representation. Thats why its (in my opinion) necessary to convert the subtypes of a union-list forcefully to list-types.

Magic number improvement has been put into its own PR: #91
I will have to look into your own fix for the union-list problem (I think you solution is correct) and have to dive into the "PUT on root element" thing again.

I tested the current master with my code and it still produce an error when writing the the UnionList... but I have a bit of trouble reproducing it in a limited testcase... hopefully have one this week.

Okay, finally got it... this is a test for nodeutil/json_rdr_test.go, which fails in the current master... it does NOT fail if the "ip-prefix" type is inlined (instead of using the typedef).
My "fix" for it is definitely at the wrong place, I (now) expect some detail is missing in the YANG parser.
func TestJsonRdrTypedefUnionList(t *testing.T) {
	mstr := `
    module x {
        revision 0;
        typedef ip-prefix {
            type union {
                type ipv4-prefix;
            }
        }

        typedef ipv4-prefix {
            type string;
        }

        container y {
            list node {
                leaf-list ip {
                    type ip-prefix;
                }
            }
        }
    }
        `
	m, err := parser.LoadModuleFromString(nil, mstr)
	if err != nil {
		t.Fatal(err)
	}
	tests := []struct {
		in  string
		out string
	}{
		{
			in:  `{"y":{"node":[{"ip":["<IP_ADDRESS>","<IP_ADDRESS>"]}]}}`,
			out: `{"y":{"node":[{"ip":["<IP_ADDRESS>","<IP_ADDRESS>"]}]}}`,
		},
	}
	for _, json := range tests {
		t.Log(json.in)
		actual, err := WriteJSON(node.NewBrowser(m, ReadJSON(json.in)).Root())
		if err != nil {
			t.Error(err)
		}
		fc.AssertEqual(t, json.out, actual)
	}
}

To explain the problem I see with my code a little bit more... when I use the typdef (that contains a union) with a leaf-list, the format-value of the types inside the unionlist type are NOT list-types... which causes the issue the testcase detects.

I managed to trim down the testcase even more:
func TestJsonRdrTypedefUnionList(t *testing.T) {
	mstr := `
    module x {
        revision 0;
        typedef ip-prefix {
            type union {
                type string;
            }
        }
		leaf-list ip {
			type ip-prefix;
		}
    }
        `
	m, err := parser.LoadModuleFromString(nil, mstr)
	if err != nil {
		t.Fatal(err)
	}
	tests := []struct {
		in  string
		out string
	}{
		{
			in:  `{"ip":["<IP_ADDRESS>","<IP_ADDRESS>"]}`,
			out: `{"ip":["<IP_ADDRESS>","<IP_ADDRESS>"]}`,
		},
	}
	for _, json := range tests {
		t.Log(json.in)
		actual, err := WriteJSON(node.NewBrowser(m, ReadJSON(json.in)).Root())
		if err != nil {
			t.Error(err)
		}
		fc.AssertEqual(t, json.out, actual)
	}
}

I think #93 is the right way to fix the problem with the unionlist subtypes.


about custom dataset

Hi,Sir. How to use custom Dataset? For example,how to modify the config  for the VOCDataset.

Hi @kwuliang , thanks for your question.
I am not sure that you want the cfg of pretraining the model on VOC or say finetuning the trained model on VOC detection. If pretraining, just prepare a txt file containing the filenames of the whole set and modify the data path in the cfg. Otherwise, you could refer to the cfg in MoCo to finetune the trained models.

I am confused about how to train InstanceLoc with my dataset. The type of mine is VOC. So Should I rewrite the Dataset(ImageNetDataset)? or how can I modify the condfig? em,The struct of my dataset is bellow:
|VOC2007
├── Annotations 进行 detection 任务时的标签文件，xml 形式，文件名与图片名一一对应
├── ImageSets 包含子文件夹 Main，其中 Main 存放检测的数据集分割文件
├── JPEGImages 存放 .jpg 格式的图片文件
├── Main
│   ├── train.txt 写着用于训练的图片名称，
│   ├── val.txt 写着用于验证的图片名称，
│   ├── trainval.txt train与val的合集。
│   ├── test.txt 写着用于测试的图片名称，

Could you prTraceback (most recent call last):
File "./tools/train.py", line 204, in
main()
File "./tools/train.py", line 192, in main
meta=meta)
File "/home/wuliang/cvprojects/InstanceLoc/mmdet/apis/train.py", line 111, in train_detector
runner.run(data_loaders, cfg.workflow, cfg.total_epochs)
File "/home/wuliang/anaconda3/envs/mmdetec2/lib/python3.7/site-packages/mmcv/runner/epoch_based_runner.py", line 122, in run
epoch_runner(data_loaders[i], **kwargs)
File "/home/wuliang/anaconda3/envs/mmdetec2/lib/python3.7/site-packages/mmcv/runner/epoch_based_runner.py", line 32, in train
**kwargs)
File "/home/wuliang/anaconda3/envs/mmdetec2/lib/python3.7/site-packages/mmcv/parallel/data_parallel.py", line 31, in train_step
return self.module.train_step(*inputs[0], **kwargs[0])
File "/home/wuliang/cvprojects/InstanceLoc/mmdet/models/detectors/base.py", line 202, in train_step
losses = self(**data)
File "/home/wuliang/anaconda3/envs/mmdetec2/lib/python3.7/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
result = self.forward(*input, **kwargs)
File "/home/wuliang/cvprojects/InstanceLoc/mmdet/models/detectors/base.py", line 137, in forward
return self.forward_train(img, img_metas, **kwargs)
File "/home/wuliang/cvprojects/InstanceLoc/mmdet/models/detectors/insloc_fpn.py", line 309, in forward_train
gt_bboxes_k if shuffle_bbox else None)
File "/home/wuliang/anaconda3/envs/mmdetec2/lib/python3.7/site-packages/torch/autograd/grad_mode.py", line 15, in decorate_context
return func(*args, **kwargs)
File "/home/wuliang/cvprojects/InstanceLoc/mmdet/models/detectors/insloc_fpn.py", line 409, in _batch_shuffle_ddp
x_gather = concat_all_gather(x)
File "/home/wuliang/anaconda3/envs/mmdetec2/lib/python3.7/site-packages/torch/autograd/grad_mode.py", line 15, in decorate_context
return func(*args, **kwargs)
File "/home/wuliang/cvprojects/InstanceLoc/mmdet/models/detectors/insloc_fpn.py", line 24, in concat_all_gather
for _ in range(torch.distributed.get_world_size())
File "/home/wuliang/anaconda3/envs/mmdetec2/lib/python3.7/site-packages/torch/distributed/distributed_c10d.py", line 620, in get_world_size
return _get_group_size(group)
File "/home/wuliang/anaconda3/envs/mmdetec2/lib/python3.7/site-packages/torch/distributed/distributed_c10d.py", line 219, in _get_group_size
_check_default_pg()
File "/home/wuliang/anaconda3/envs/mmdetec2/lib/python3.7/site-packages/torch/distributed/distributed_c10d.py", line 210, in _check_default_pg
"Default process group is not initialized"
AssertionError: Default process group is not initialized
ovide

I think you could use the train.txt which contains the filenames.

thanks


Building a Docker Image for Deployment

Resolves
Fixes #303
Partially #304
Description
Generates a docker image for a model and copies over the model.zip

Next steps are:

Force docker registry running in container to use password and username
Add these to integration test
Run docker login on docker push
Assert that an image is pushed to a repo
Spin up a service container for these tests in GitHub
Add more integration and unit tests

@Brett-Parker  / @AnoojNair  / @willvelida - I realized I started going into #304  so I' going to stop this PR here so it doesn't get too big. #303 should be covered here. There are a couple of outstanding issues that will be added once support is there which is e.g. copying over the schema.
For #304 which will be a separate PR, what remains is docker login before docker push and more integration tests (e.g. we could start the pushed container and make sure a prediction works with a dummy model or something).
Anyhow this PR is ready for review as is!

Okay, I'm hands-off on this PR now... 😄

Thanks @Brett-Parker! docker image rm is the command used to remove an image. Great comment and I expanded on the comment to clarify that


PlayRun task should make working dir configurable

Expected Behavior

PlayRun task is the task type to launch the play server for local development and hot reload. Currently this task support changing HTTP port, etc., but it does not support changing the working directory of the server process. The working directory is hard coded to be the project directory.
Current Behavior

However, sometimes users may want the server process to run in rootDir instead of projectDir if there is a nested structure.
Furthermore, the Play server testing task, namely "testPlayBinary", actually allows users to configure the working directory. This makes many Play users confused since there is an asymmetry between local dev and testing functions provided.
In addition, for SBT (the native build tool for Play), the working directory is configurable. So Gradle should have this feature parity.
Context

Play users in my company often have to use workarounds to bridge this working directory gap by adding symlinks, changing Play configurations, etc. But it will be much more straightforward if the working directory can be configured directly.
Steps to Reproduce (for bugs)

N/A. We've discussed this issue with Gradle Inc offline @big-guy @bigdaz
Your Environment

Build scan URL:

Both Mac and Linux have this issue.

@big-guy @bigdaz
I think it is hard-coded here:
https://github.com/gradle/gradle/blob/f5a2a8a861a1803c662bd7632d1f94689dc46968/subprojects/platform-play/src/main/java/org/gradle/play/tasks/PlayRun.java#L89
"getProject().getProjectDir()" is the hard-coded path.

@big-guy @bigdaz
Please let me know if the pull request makes sense. Locally it fixes the issue on some of the play projects we work on. Thanks!

Merged, thanks @ymwang1984 !

Thanks @bigdaz


Count the appearance of keywords in the filter mode

show which keyword in which files was found. Do this only for like 50 files.
I don't really see a use case, because if the user want's to have more information he should rather use grep.


How to get all related objects for a given tag

I want all the related model objects for a particular Tag.
For ex : Tag.objects.filter('sometag').prefetch_related('related_model')

Same thing. Didn't find in the docs how to do it.

We have Tag, TaggedItem and various models M, N, O, P. But we might also have custom tags, and multiple tag managers on M or N, etc.... it's not very trivial to do this kind of lookup by default in a meaningful way IMO. I think it would make more sense to work offf of TaggedItem itself (the through table), and there you could sort by tag/content type or something and build up a result.
So I'm not sure what the function here looks like, but I'm not sure that querying off off of Tag gives useful results in most systems....


itkwidgets requires python <3.9.0

Since itkwidgets supports in limited to python=3.10, for pyiron/continuum image, I have downgraded python to python=3.8.
I thought it would be best that I document it here.  Then we can later on remove the downgrade of python continuum/environment.yaml.

itkwidgets is no longer needed, so this is no longer an issue.


Should provide a warning when keys are in a service file don't exist or are not a valid key

Currently, if you put an invalid key (due to a typo or lack of understanding of what's supported in rancher-compose), we should display a warning to the user so they know that the key wasn't used/read.

Are you saying that if the syntax of rancher-compose file is wrong for a service, the user should be warned?

Yes, this is what @ibuildthecloud had suggested when he used export instead of expose for a test case. Since export is not a valid key.

Pre-duplicate of https://github.com/rancherio/rancher-compose/issues/32


Couldn't read 'Object List' count on YABE

Hello, thank you very much for your tools.
I have a problem when I make the flow by default:

I get this error when I try to access the objects on YABE:

I modified the line :
https://github.com/bitpool/edge-bacnet/blob/d01ffdb897768fb27a83cbd55d8e1e026f6cacef/bacnet_server.js#L158
by :
that.bacnetClient.client.readPropertyResponse(data.address, data.invokeId, data.request.objectId, data.request.property, responseObj);
And on YABE I have no more problems... How can we fix this?

Hello, thank you very much for your tools. I have a problem when I make the flow by default:
I get this error when I try to access the objects on YABE:
I modified the line :
https://github.com/bitpool/edge-bacnet/blob/d01ffdb897768fb27a83cbd55d8e1e026f6cacef/bacnet_server.js#L158
by :
that.bacnetClient.client.readPropertyResponse(data.address, data.invokeId, data.request.objectId, data.request.property, responseObj);
And on YABE I have no more problems... How can we fix this?
Translated with DeepL.com (free version)

hi there

Hi There,
We are doing a major release tommorow that fixs many issues with this node along many perfromance improvments. This issue is resolved in tommrows release

Oh great thank you so much !!!!

Hello, I've updated your node but I'm getting a new error when I try to collect my items 😅

Hi @UnCanard14  - that is a bit odd. I can discover the bacnet node and see the points in Yabe on my end. Are you able to provide me with some additional information?
OS: [e.g. iOS]
Node-RED version:
NodeJS version:
Are you running Node-RED in a docker container or directly on the operating system or virtual machine?
Also finally a Wireshark Capture for this error would be very helpful if possible.

Yes sure :
Os : Ubuntu 22.04.4 LTS
Node-red : 3.1.9
Node-js : v18.20.2
Node red is directly on the operating system with this setup : https://nodered.org/docs/getting-started/raspberrypi

I @UnCanard14 I have the same problem as you, have you found a solution?

Hello @debraysimon sorry not yet but I contacted @dblanchie and he told me that there would be an update soon. 😉

hey @UnCanard14 @debraysimon  - Can you update to version 1.3.1 and please try again ?
Turns out I was using an older version of YABE that was compatible. Ive since updated the code and is working with latest version of YABE on my end.

Great, it works for me ! Thank you !

Hello, it works for me too, thanks a lot !!


adding some grids to events:id

Summary by CodeRabbit

Refactor

Improved readability of event details by restructuring them into a definition list.
Enhanced the formatting of event attributes such as location, date, description, BTC value, stacks, levels, and game type.

Style

Updated styles to better align with the new definition list format for event details.

@bitcoinbrisbane


google_sign_in — renderButton is unclickable on mobile deployed release

What package does this bug report belong to?
google_sign_in
What target platforms are you seeing this bug on?

Yes
Dependency versions
pubspec.lock
# Generated by pub
# See https://dart.dev/tools/pub/glossary#lockfile
packages:
  async:
    dependency: transitive
    description:
      name: async
      sha256: "947bfcf187f74dbc5e146c9eb9c0f10c9f8b30743e341481c1e2ed3ecc18c20c"
      url: "https://pub.dev"
    source: hosted
    version: "2.11.0"
  boolean_selector:
    dependency: transitive
    description:
      name: boolean_selector
      sha256: "6cfb5af12253eaf2b368f07bacc5a80d1301a071c73360d746b7f2e32d762c66"
      url: "https://pub.dev"
    source: hosted
    version: "2.1.1"
  characters:
    dependency: transitive
    description:
      name: characters
      sha256: "04a925763edad70e8443c99234dc3328f442e811f1d8fd1a72f1c8ad0f69a605"
      url: "https://pub.dev"
    source: hosted
    version: "1.3.0"
  clock:
    dependency: transitive
    description:
      name: clock
      sha256: cb6d7f03e1de671e34607e909a7213e31d7752be4fb66a86d29fe1eb14bfb5cf
      url: "https://pub.dev"
    source: hosted
    version: "1.1.1"
  collection:
    dependency: transitive
    description:
      name: collection
      sha256: ee67cb0715911d28db6bf4af1026078bd6f0128b07a5f66fb2ed94ec6783c09a
      url: "https://pub.dev"
    source: hosted
    version: "1.18.0"
  fake_async:
    dependency: transitive
    description:
      name: fake_async
      sha256: "511392330127add0b769b75a987850d136345d9227c6b94c96a04cf4a391bf78"
      url: "https://pub.dev"
    source: hosted
    version: "1.3.1"
  flutter:
    dependency: "direct main"
    description: flutter
    source: sdk
    version: "0.0.0"
  flutter_lints:
    dependency: "direct dev"
    description:
      name: flutter_lints
      sha256: "9e8c3858111da373efc5aa341de011d9bd23e2c5c5e0c62bccf32438e192d7b1"
      url: "https://pub.dev"
    source: hosted
    version: "3.0.2"
  flutter_test:
    dependency: "direct dev"
    description: flutter
    source: sdk
    version: "0.0.0"
  flutter_web_plugins:
    dependency: transitive
    description: flutter
    source: sdk
    version: "0.0.0"
  google_identity_services_web:
    dependency: transitive
    description:
      name: google_identity_services_web
      sha256: "9482364c9f8b7bd36902572ebc3a7c2b5c8ee57a9c93e6eb5099c1a9ec5265d8"
      url: "https://pub.dev"
    source: hosted
    version: "0.3.1+1"
  google_sign_in:
    dependency: "direct main"
    description:
      name: google_sign_in
      sha256: "0b8787cb9c1a68ad398e8010e8c8766bfa33556d2ab97c439fb4137756d7308f"
      url: "https://pub.dev"
    source: hosted
    version: "6.2.1"
  google_sign_in_android:
    dependency: transitive
    description:
      name: google_sign_in_android
      sha256: d30fb34b659679ea74397e9748b4ab5d720720d57dcc79538f1b3c4a68654cb3
      url: "https://pub.dev"
    source: hosted
    version: "6.1.27"
  google_sign_in_ios:
    dependency: transitive
    description:
      name: google_sign_in_ios
      sha256: a058c9880be456f21e2e8571c1126eaacd570bdc5b6c6d9d15aea4bdf22ca9fe
      url: "https://pub.dev"
    source: hosted
    version: "5.7.6"
  google_sign_in_platform_interface:
    dependency: "direct main"
    description:
      name: google_sign_in_platform_interface
      sha256: "1f6e5787d7a120cc0359ddf315c92309069171306242e181c09472d1b00a2971"
      url: "https://pub.dev"
    source: hosted
    version: "2.4.5"
  google_sign_in_web:
    dependency: "direct main"
    description:
      name: google_sign_in_web
      sha256: d606264c7a1a526a3aa79d938b85a601d8589731a478bd4a3dcbdeb14a572228
      url: "https://pub.dev"
    source: hosted
    version: "0.12.4+1"
  http:
    dependency: transitive
    description:
      name: http
      sha256: "761a297c042deedc1ffbb156d6e2af13886bb305c2a343a4d972504cd67dd938"
      url: "https://pub.dev"
    source: hosted
    version: "1.2.1"
  http_parser:
    dependency: transitive
    description:
      name: http_parser
      sha256: "2aa08ce0341cc9b354a498388e30986515406668dbcc4f7c950c3e715496693b"
      url: "https://pub.dev"
    source: hosted
    version: "4.0.2"
  leak_tracker:
    dependency: transitive
    description:
      name: leak_tracker
      sha256: "7f0df31977cb2c0b88585095d168e689669a2cc9b97c309665e3386f3e9d341a"
      url: "https://pub.dev"
    source: hosted
    version: "10.0.4"
  leak_tracker_flutter_testing:
    dependency: transitive
    description:
      name: leak_tracker_flutter_testing
      sha256: "06e98f569d004c1315b991ded39924b21af84cf14cc94791b8aea337d25b57f8"
      url: "https://pub.dev"
    source: hosted
    version: "3.0.3"
  leak_tracker_testing:
    dependency: transitive
    description:
      name: leak_tracker_testing
      sha256: "6ba465d5d76e67ddf503e1161d1f4a6bc42306f9d66ca1e8f079a47290fb06d3"
      url: "https://pub.dev"
    source: hosted
    version: "3.0.1"
  lints:
    dependency: transitive
    description:
      name: lints
      sha256: cbf8d4b858bb0134ef3ef87841abdf8d63bfc255c266b7bf6b39daa1085c4290
      url: "https://pub.dev"
    source: hosted
    version: "3.0.0"
  matcher:
    dependency: transitive
    description:
      name: matcher
      sha256: d2323aa2060500f906aa31a895b4030b6da3ebdcc5619d14ce1aada65cd161cb
      url: "https://pub.dev"
    source: hosted
    version: "0.12.16+1"
  material_color_utilities:
    dependency: transitive
    description:
      name: material_color_utilities
      sha256: "0e0a020085b65b6083975e499759762399b4475f766c21668c4ecca34ea74e5a"
      url: "https://pub.dev"
    source: hosted
    version: "0.8.0"
  meta:
    dependency: transitive
    description:
      name: meta
      sha256: "7687075e408b093f36e6bbf6c91878cc0d4cd10f409506f7bc996f68220b9136"
      url: "https://pub.dev"
    source: hosted
    version: "1.12.0"
  path:
    dependency: transitive
    description:
      name: path
      sha256: "087ce49c3f0dc39180befefc60fdb4acd8f8620e5682fe2476afd0b3688bb4af"
      url: "https://pub.dev"
    source: hosted
    version: "1.9.0"
  plugin_platform_interface:
    dependency: transitive
    description:
      name: plugin_platform_interface
      sha256: "4820fbfdb9478b1ebae27888254d445073732dae3d6ea81f0b7e06d5dedc3f02"
      url: "https://pub.dev"
    source: hosted
    version: "2.1.8"
  sky_engine:
    dependency: transitive
    description: flutter
    source: sdk
    version: "0.0.99"
  source_span:
    dependency: transitive
    description:
      name: source_span
      sha256: "53e943d4206a5e30df338fd4c6e7a077e02254531b138a15aec3bd143c1a8b3c"
      url: "https://pub.dev"
    source: hosted
    version: "1.10.0"
  stack_trace:
    dependency: transitive
    description:
      name: stack_trace
      sha256: "73713990125a6d93122541237550ee3352a2d84baad52d375a4cad2eb9b7ce0b"
      url: "https://pub.dev"
    source: hosted
    version: "1.11.1"
  stream_channel:
    dependency: transitive
    description:
      name: stream_channel
      sha256: ba2aa5d8cc609d96bbb2899c28934f9e1af5cddbd60a827822ea467161eb54e7
      url: "https://pub.dev"
    source: hosted
    version: "2.1.2"
  string_scanner:
    dependency: transitive
    description:
      name: string_scanner
      sha256: "556692adab6cfa87322a115640c11f13cb77b3f076ddcc5d6ae3c20242bedcde"
      url: "https://pub.dev"
    source: hosted
    version: "1.2.0"
  term_glyph:
    dependency: transitive
    description:
      name: term_glyph
      sha256: a29248a84fbb7c79282b40b8c72a1209db169a2e0542bce341da992fe1bc7e84
      url: "https://pub.dev"
    source: hosted
    version: "1.2.1"
  test_api:
    dependency: transitive
    description:
      name: test_api
      sha256: "9955ae474176f7ac8ee4e989dadfb411a58c30415bcfb648fa04b2b8a03afa7f"
      url: "https://pub.dev"
    source: hosted
    version: "0.7.0"
  typed_data:
    dependency: transitive
    description:
      name: typed_data
      sha256: facc8d6582f16042dd49f2463ff1bd6e2c9ef9f3d5da3d9b087e244a7b564b3c
      url: "https://pub.dev"
    source: hosted
    version: "1.3.2"
  vector_math:
    dependency: transitive
    description:
      name: vector_math
      sha256: "80b3257d1492ce4d091729e3a67a60407d227c27241d6927be0130c98e741803"
      url: "https://pub.dev"
    source: hosted
    version: "2.1.4"
  vm_service:
    dependency: transitive
    description:
      name: vm_service
      sha256: "3923c89304b715fb1eb6423f017651664a03bf5f4b29983627c4da791f74a4ec"
      url: "https://pub.dev"
    source: hosted
    version: "14.2.1"
  web:
    dependency: transitive
    description:
      name: web
      sha256: "97da13628db363c635202ad97068d47c5b8aa555808e7a9411963c533b449b27"
      url: "https://pub.dev"
    source: hosted
    version: "0.5.1"
sdks:
  dart: ">=3.4.3 <4.0.0"
  flutter: ">=3.22.0"

Steps to reproduce

Run the code in my repository locally

flutter build web --web-renderer canvaskit --release
Serve the files python3 -m http.server --cgi 8080
Open the app in mobile iOS Safari browser
Everything works fine, the button is clickable

Deploy the same code anywhere (see build.sh)

flutter build web --web-renderer canvaskit --release
Serve with GitHub pages / cloudflare pages
Access that site on mobile iOS Safari browser and it is no longer clickable
Demo: https://coocoofroggy.github.io/render_button_bug/

I have ensured that the necessary domains are added to Google Cloud Console project > APIs & Services > Credentials > Authorized JavaScript origins.
Expected results
The button is clickable.
Actual results
The button does not click.
Code sample
Code sample
Full repo: https://github.com/CoocooFroggy/render_button_bug
import 'package:flutter/material.dart';
import 'package:google_sign_in_platform_interface/google_sign_in_platform_interface.dart';
import 'package:google_sign_in_web/google_sign_in_web.dart';

final googleSignInPlugin =
(GoogleSignInPlatform.instance as GoogleSignInPlugin);

Future<void> main() async {
  await googleSignInPlugin.initWithParams(
      const SignInInitParameters(
          clientId:
          'googleClientId'));
  runApp(const MainApp());
}

class MainApp extends StatelessWidget {
  const MainApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        body: Center(
          child: googleSignInPlugin.renderButton(
              configuration: GSIButtonConfiguration(minimumWidth: 400)),
        ),
      ),
    );
  }
}

Screenshots or Videos

Screenshots / Video demonstration
Video:
https://github.com/flutter/flutter/assets/45371102/972ab7a8-cb29-4d2d-9404-ff25c56877b4

Logs
Logs
Compiling lib/main.dart for the Web...                             713ms
✓ Built build/web

Flutter Doctor output
Doctor output
[!] Flutter (Channel stable, 3.22.2, on macOS 14.5 23F79 darwin-arm64, locale en-US)
    • Flutter version 3.22.2 on channel stable at /Users/coocoofroggy/flutter
    ! Warning: `dart` on your path resolves to /opt/homebrew/Cellar/dart/3.4.4/libexec/bin/dart, which is not inside your current Flutter
      SDK checkout at /Users/coocoofroggy/flutter. Consider adding /Users/coocoofroggy/flutter/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 761747bfc5 (5 weeks ago), 2024-06-05 22:15:13 +0200
    • Engine revision edd8546116
    • Dart version 3.4.3
    • DevTools version 2.34.3
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update
      checks and upgrades.

[✗] Android toolchain - develop for Android devices
    ✗ Unable to locate Android SDK.
      Install Android Studio from: https://developer.android.com/studio/index.html
      On first launch it will assist you in installing the Android SDK components.
      (or visit https://flutter.dev/docs/get-started/install/macos#android-setup for detailed instructions).
      If the Android SDK has been installed to a custom location, please use
      `flutter config --android-sdk` to update to that location.

[✓] Xcode - develop for iOS and macOS (Xcode 15.4)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15F31d
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/macos#android-setup for detailed instructions).

[✓] IntelliJ IDEA Ultimate Edition (version 2024.1.4)
    • IntelliJ at /Users/coocoofroggy/Applications/IntelliJ IDEA Ultimate.app
    • Flutter plugin version 80.0.2
    • Dart plugin version 241.17890.8

[✓] VS Code (version 1.90.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.90.0

[✓] Connected device (4 available)
    • Froggy One (mobile)             • 00008120-XXXXXXXXXXXXXX • ios            • iOS 17.5.1 21F90
    • macOS (desktop)                 • macos                     • darwin-arm64   • macOS 14.5 23F79 darwin-arm64
    • Mac Designed for iPad (desktop) • mac-designed-for-ipad     • darwin         • macOS 14.5 23F79 darwin-arm64
    • Chrome (web)                    • chrome                    • web-javascript • Google Chrome 126.0.6478.115
    ! Error: Froggy’s Apple Watch has recently restarted. To use Froggy’s Apple Watch with Xcode, unlock it and its companion iPhone (code 19)

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 3 categories.

Hi @CoocooFroggy
I see you haven't passed clientId to dart code or HTML code with google-signin-client_id. Does the issue persist if you pass it with your client id?
I checked this issue using package example and see the button is clickable on my deployed site (on iOS Safari browser)

Hi @huycozy, thanks for the swift reply!
I do pass clientId in my production app, and thus sign-in works perfectly on desktop!
I tried running the package example you linked, and the button is not clickable on my deployed site, iOS 17.5.1 Safari browser. I added a clientId just to confirm that was not the issue.
You may try it here and let me know if it is clickable: https://coocoofroggy.github.io/google_example/. You can also try it on desktop and ensure everything works as expected.

Do note that the "Sign in silently" triggers a modal that appears the first time you visit the site—this modal works on iOS web. But if you ignore the modal, the "Sign in with Google" button itself is not clickable.

Well, I open your site above and the login button is indeed not clickable. You can try my deployed site here, it's clickable as expected (I deployed it with Firebase Hosting).
I took a look at your sample code google_example I see there is only one thing different than mine in HTML body. Can you try with code below to see if it works? (this is a new from project template when you are on newer Flutter version)
<body>
  <script src="flutter_bootstrap.js" async></script>
</body>

Edited, redeployed, no dice. I actually initially deployed with a completely fresh web/index.html generated from the latest Flutter at first, but I reverted to the one shown in the example to see if that was an issue with regression. Seems like it doesn't work either way. Not sure how yours is deployed differently.
I also would like to rule out base-href being an issue, as my production app is on an sub.domain.tld with no base path and the button is still unclickable.

My production site is built on CloudFlare pages so we can rule out it being specific to GitHub pages maybe. The build script is basically the same for both minus the --base-href.

I also deploy Web with GitHub page here: https://huycozy.github.io/repro_ggsignin and it works normally as well (follow Andrea article here). Tried with default renderer which falls to HTML on mobile browser and also canvaskit (requested explicitly) but they both work without issue.

Build command:

flutter build web --base-href $(BASE_HREF) --web-renderer canvaskit --release

With $(BASE_HREF) = /repro_ggsignin/

On the output index.html:

<base href="/repro_ggsignin/">
...

Thanks for your help. I followed the above steps and it worked.
I wanted to troubleshoot why that worked so I could replicate the solution in the CI. It was because the above steps run flutter build on my local machine. My CI clones the Flutter SDK on the master branch, not the stable branch, which has issues regarding the button.
Thus my solution was to add -b stable to my clone command in my build.sh.
Thank you for your help once again!


Unit test reporting

conversation

Failing on permissions, for context
https://docs.github.com/en/actions/reference/authentication-in-a-workflow#using-the-github_token-in-a-workflow
https://docs.github.com/en/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token

closing for now, will revisit.


Suppress "IPv4 forwarding" warning for --net=none

There's no need to warn that "ip-forwarding" is disabled if a container doesn't use networking.
see https://github.com/docker/docker/issues/22805#issuecomment-220636773 for reference
To test;
echo 0 > /proc/sys/net/ipv4/ip_forward
dockerd -D --ip-forward=false &

should give no warning:
docker run -dit --net=host alpine sh
docker run -dit --net=none alpine sh

should give a warning:
docker run -dit alpine sh
WARNING: IPv4 forwarding is disabled. Networking will not work.

Seems sensible.

Flaky test in gccgo?

Created an issue, just in case; https://github.com/docker/docker/issues/22879

LGTM

LGTM


Use systemd cgroup driver for Kubernetes e2e tests with cgroupsv2

Set systemdCgroup for cgroupv2 Kuberentes e2e tests.
Signed-off-by: Aditi Sharma<EMAIL_ADDRESS>

/ok-to-test


Channel matching in commands is case sensitive

This is essentially a rehash of #213, looks to be caused by the switch from basic string matching to use of the wildcard matching function.
Usage of WildCmp does not lend itself to making that whole function case insensitive, so I think the solution would have to be in the CIRCNetwork::Find* methods (the nick matching ones probably ought to be case insensitive too).

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/19762616-channel-matching-in-commands-is-case-sensitive?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

Fixed by https://github.com/znc/znc/commit/7345a6ee3ac8547da46e6906843937f8e43aed80