Complete rewrite of Tweens

EDIT: Scroll a bit further for interesting stuff.
This is meant to close https://github.com/godotengine/godot-proposals/issues/514
Note that THIS IS HEAVILY WIP. The implementation is incredibly hacked together for now, full of dead and commented out code. Also it's mostly unfinished. I wanted to open the PR early to make sure that this is going in the right direction.
In its current state you can do this:
var tween := get_tree().create_tween()
tween.tween_property($icon, "position", Vector2(340, 100), 4)
tween.tween_property($icon, "modulate", Color.red, 1)

which will result in

So onto details:
Tweens are no longer nodes. They are References, with very similar logic to SceneTreeTimers, designed in a "fire and forget" manner. You create a Tween with get_tree().create_tween(), which will result an empty Tween. To do something with it, you then call one of the tweening methods. These are:
tween_property - tweens a property between given values (equivalent of current interpolate property)
tween_interval - waits for given time (equivalent of a timer)
tween_callback - calls a method on an object (equivalent of current interpolate callback)
tween_method - calls a method on an object with a tweening argument that goes from initial to final value (equivalent of current interpolate method)
You can call as many tweening methods on the Tween as you want, they will be sequenced one after another, i.e. there's support for chaining out of the box. Parallel tweening will be done explicitly with a dedicated method.
As for the implementation, there two main classes: Tween and Tweener. Tween is basically a collection of Tweeners. When you call tweening method, it actually creates a Tweener. Tweeners are packed in a List. Tween will go through the list and process every Tweener and when it finishes, it goes onto another step in the sequence. The Lists of Tweeners for each step are contained in a Vector.
Internally, SceneTree calls _step() on all active Tweens. Each Tween then calls _step() on each current Tweener. _step() has a return value. When a Tweener returns false, it's considered finished (but doesn't get freed, in case you want to loop the Tween). If Tween returns false, it's removed from the list of tweens in SceneTree (and freed if you don't keep a reference). Tweener is also removed when the targeted object gets removed (whether this should happen silently or needs to be handled manually by user is up to discussion).
These are the basics. The new Tweens are going to work mostly like in the proposal (see the TweenSequence class linked in there). I yeeted the old Tween code, save for the interpolation (the _interpolate method in PropertyTweener, which is going to get cleaned up). The _calculate_interpolation method defined in easing_equations.cpp will stay there and since I need it in another class, there's a chance to expose it (I remember there was a request for it).
The thing that I'm the most unsure of is whether Tweens should be handled directly by SceneTree. But I don't have other idea how they could be handled, aside from maybe TweenServer.

EDIT:
Ok, the feature implementation is complete. What's left is error handling and documentation.
Here's a brief summary of the features:
(scroll below for actual usage examples)
Tween

Tweens are now Reference type handled by SceneTree, which makes them super cheap. They are intended for fire-and-forget use
You create a Tween by using get_tree().create_tween() or create_tween() inside Node (the latter will automatically bind the Tween, see below)
You can also use get_tree().get_processed_tweens() to get the list of all existing Tweens
Tweens have process mode and pause mode, so they can process either in idle frame or physics frame and can be paused
Tweens can also be bound to a Node, by using bind_node(node). The Tween will not process if the node is not inside tree and will be automatically removed when the node is freed
You can loop the Tween with set_loops(loops) and 0 will make infinite loop
You can stop (reset), pause, resume and kill a Tween
To actually Tween something, you need to use a tweening method (see below), which will return a Tweener
You can call as many tweening methods as you want and they will be executed in a sequence
If you want tweening method to run parallely, you can use tween.parallel()
Using Tween.set_parallel(true) will make all subsequent Tweeners parallel
You can also use Tween.set_ease() or Tween.set_trans() to set default easing and transition for a Tween
Alternatively, there's a method tween.interpolate_value(initial_value, delta_value, time, duration, transition, easing) which allows you to manually interpolate a value with easing (supersedes #36997)

There are 4 available Tweeners:
PropertyTweener

Created with tween.tween_property(object, property, final_value, duration)
By default, PropertyTweener starts from current value at the time it starts tweening
You can use from() to set a custom starting value
You can also use from_current() to assign it the value it has currently (i.e. when creating the Tween)
And finally, you can use as_relative() to make the final value be a relative value (so e.g. tweening position to Vector(100, 0) relatively will move it by 100 pixels instead of moving it to position (100, 0))
PropertyTweener inherits transition and ease types from the Tween. You can set them with set_ease(ease) or set_trans(trans)
You can also make the PropertyTweener delayed with set_delay(delay)

IntervalTweener

Created with tween.tween_interval(duration)
It just does nothing for given time, bruh

CallbackTweener

Created with tween.tween_callback(callback), where callback is a Callable
Calls the given method
To bind additional arguments to the method you can use Callable.bind(args)
You can use set_delay(delay) to have a delay before the callback

MethodTweener

Created with tween.tween_method(callback, from, to, duration)
This is like PropertyTweener, but instead of tweening an actual property, it tweens an internal variable and calls a method with this variable
To bind additional arguments to the method you can use Callable.bind(args)
You can set easing type and transition type like in PropertyTweener
You can also delay it
This is super cool to use with lambdas

Ok, so these are features. Now on the actual usage, it basically boils down to:
var tween = get_tree.create_tween()
tween.tween_something(something args)
tween.tween_something(different args).some_settings_etc()

which will execute the sequence of 2 given tweening operations.
Some samples:
var tween = get_tree().create_tween()
tween.tween_property($Sprite, "position", Vector2(300, 100), 1).set_trans(Tween.TRANS_SINE)
tween.tween_property($Sprite, "modulate:b", 0, 1)

var tween = get_tree().create_tween().set_trans(Tween.TRANS_ELASTIC).set_ease(Tween.EASE_OUT)
tween.tween_property($Sprite, "rotation", PI/2, 1)
tween.parallel().tween_property($Sprite, "position", Vector2(200, 200), 1).as_relative()
tween.tween_property($Sprite, "modulate", Color.red, 1)

var sprite = $Sprite
var tween = get_tree().create_tween().bind_node(sprite)
tween.tween_property(sprite, "position", Vector2(500, 0), 3).as_relative()

await get_tree().create_timer(1).timeout
remove_child(sprite)
await get_tree().create_timer(1).timeout
add_child(sprite)

Same as above but without bind

var tween = get_tree().create_tween().set_loops(2)
tween.tween_property($Sprite, "position", Vector2(200, 0), 0.5).as_relative()
tween.tween_interval(0.5)

var tween = get_tree().create_tween().set_loops() #-1 by default
tween.tween_interval(1)
tween.tween_callback($Sprite.hide)
tween.tween_interval(1)
tween.tween_callback($Sprite.show)

func _ready():
	var tween = get_tree().create_tween()
	tween.tween_method(set_label_text, 0, 10, 1)

func set_label_text(value: int):
	$Label.text = "Counting " + str(value)

Lambda version of the above:
var tween = get_tree().create_tween()
var label = $Label
tween.tween_method(func(value: int): label.text = "Counting " + str(value), 0, 10, 1)

If you have any questions or feature requests be sure to write them in the comments.

Nice to see it works out, see my previous comments revolving this kind of interface in https://github.com/godotengine/godot/issues/26529#issuecomment-564798612 supporting this on the high-level.

@Xrayez If you mean autostarting and handling pause, then it's already planned.
btw the code sample you given there will probably look like this:
var tween = get_tree().create_tween()
tween.tween_property($Godot, "modulate:a", 0, 5)
tween.tween_callback($Godot.queue_free) #alternative to connecting finished signal

Parallel tweening will be done explicitly with a dedicated method.

Maybe something like this:
var tween := get_tree().create_tween()

tween.tween_property($icon, "position", Vector2(340, 100), 4)

tween.group_begin()
tween.tween_property($icon, "modulate", Color.red, 1)
tween.tween_property($icon, "scale", Vector2(2, 2), 1)
tween.group_end()

Maybe something like this:

Nah, it will be simpler. It's not mentioned in the OP, but the Tweens will make heavy use of chaining (every Tween/Tweener method returns that Tween/Tweener to allow multiple calls).
That said, your code will look like this:
var tween := get_tree().create_tween()

tween.tween_property($icon, "position", Vector2(340, 100), 4)

tween.tween_property($icon, "modulate", Color.red, 1)
tween.join().tween_property($icon, "scale", Vector2(2, 2), 1)

Parallel Tweening is going to be achieved with parallel() and join() methods followed by a Tweener method. The difference between the two is that join() will result in an error if there was no previous tweening command.

We must try to make this not only simple, but also as versatile as possible. How to get the following using your way:

I had a thought about await:
await tween.tween_property( 1 )

tween.tween_property( 3 )
await tween.tween_property( 2 )

tween.tween_property( 4 )
await tween.tween_property( 5 )

tween.tween_property( 6 )

But this is too GDScript specific.

How to get the following using your way:

By using two Tweens. You'd need to add CallbackTweener 5b with a delay equal to duration of 5, which would create a new Tween that does 6. Tweens are cheap in the new implementation, so you don't have to worry about creating many of them.
Allowing asynchronous steps would make the implementation much more complicated. Although maybe I could add at least a finished signal for Tweeners to make your await code possible.

I got it. Something like this:
tween1.tween_property( 1 )
tween1.tween_property( 2 )
tween1.tween_property( 5 )
tween1.tween_property( 6 )

tween2.tween_interval( ... )
tween2.tween_property( 3 )
tween2.tween_interval( ... )
tween2.tween_property( 4 )

That is, you can always do without .join() if you add another Tween. But that's a little unintuitive

Ok, I completed the features. Check the added section in the OP.

var tween = get_tree().create_tween().set_loops(2)
tween.tween_property($Sprite, "position", Vector2(200, 0), 0.5).as_relative()
tween.tween_interval(0.5)

I don't think set_loops(n) should make tween execute n + 1 times. I find it unintuitive.

I don't think set_loops(n) should make tween execute n + 1 times. I find it unintuitive.

set_loop(n) means "loop n times". Maybe it should be called repeat?

While I agree tween should be a reference, I think it should be something created in Node, not in SceneTree (even though it is processed in SceneTree), so you simply use it like
tween("property",values)
# or
$node.tween("property",values)

I would do the same change for timers

Hi I just saw your rewrite on Twitter and I very much agree with the 'fire and forget' idea of tweens and many of the other changes and improvements you have made. In the past I found myself always creating tween objects on demand and never really figured out how to properly restart or reuse them.
Creating tweens
Is there a specific reason that the create_tween function must be on the SceneTree? I have the feeling it should be a function of Node with the tweens automatically binding to that node that "owns" them. Just throwing them at the tree without an "owner" probably works in 99% of the cases but it might be a source of confusing bugs where tweens run through pause or show unexpected behavour differing from the "owner" node because I forgot to bind the tween after creation. I would probably just bind them always to prevent this.
Also it fits a bit better into the composition philosophy of Godot when the tween is created on the current Node instead of the tree which feels a bit more global.
Auto start tweens
If I understand correctly tweens automatically start on the next frame after their creation? And if you want to delay the start you would add a delay with set_delay or inserting an interval tween in the front? I cannot remember if I ever actually wanted to not start a tween immediately after creation but preventing the auto start to start them manually at an arbitrary point could be useful in some scenarios?
Parallel tweens
Just creating multiple tweens to run at the same time will probably enough in most cases but you are right that there needs to be some sort of join mechanism for more complex tweening. Calling this process join is a good fit as the terminology and thought process behind this is similar to multithreading. Intuitively I would expect it to work something like this:
`
var tween := create_tween()
tween.tween_property(...) #A
var parallel := tween.join()
parallel.tween_property(...) # B
parallel.tween_property(...) # C
tween.tween_property(...) # D
`
This should run tween A, then B and C parallel and after that tween D. This underlines the idea that calling the tween_* functions on the tween chains them one after the other and a group of parallel tweens is just chained in.

I don't like it accessed via SceneTree, it makes the tween access a bit dirty, while it can use a Node like it is currently and expose configuration via inspector which would be great for many workflows and more godot-like.

Usually you would combine tweens with one or multiple AnimationPlayer to get most of the functionality in this pull request. I think it is overdoing it a little, trying to do too much with tweens alone.

The idea seems solid and very much an improvement, removing it from being a node and only accessible through the SceneTree just seems a bit....off.  It's probably just me.  I certainly like occasionally using "get_tree().create_timer" in an in-line way for yields but I will often pull that back into a node composed within a scene so it's a bit cleaner and self-contained.  I know it's handled now, so that in case a yield returns to a now dead node/scene it wont crash but this would have to be handled as well with tweens.
I'm well aware though that this could just be me, but I thought I would voice the concern in case what I'm talking about has any relevance.

Maybe it's just me, but I feel like the default behaviour of a tween should be to process in parallel, which is how it works currently. The join() function doesn't really make sense in terms of doing things in parallel. I'd probably do something like:
parallel:
tween.interpolate_property(blah)
tween.interpolate_property(other_blah)
tween.start()
sequence:
tween.interpolate_property(blah)
tween.chain().interpolate_property(other_blah)
tween.start()
(not sure if tween.start() is still a thing in this PR?)
Not sure if 'chain' is the best word, but I think something like that would better describe the idea of creating/adding to a sequence rather than 'join'

I have the feeling it should be a function of Node with the tweens automatically binding to that node that "owns" them.

I actually had this idea already. Seeing how some people requested it I'll add it as an alternative way of creating Tweens.

Auto start tweens [...]

If you don't want the Tween to start immediately, you can call stop() or pause() after it is created. This will be mentioned in the docs.

This should run tween A, then B and C parallel and after that tween D. This underlines the idea that calling the tween_* functions on the tween chains them one after the other and a group of parallel tweens is just chained in.

This can be already achieved with
var tween = get_tree().create_tween()
tween.tween_property(...) #A
tween.tween_property(...) # B
tween.join().tween_property(...) # C
tween.tween_property(...) # D

When you use join() or parallel() method, any tweening method called immediately after will run in parallel with the previous one. Tween will go to next step only when all parallel Tweeners have finished.

I think the names of the tween_* functions could be changed into something

In my prototype they were called append_*. I could rename this probably.

Usually you would combine tweens with one or multiple AnimationPlayer to get most of the functionality in this pull request. I think it is overdoing it a little, trying to do too much with tweens alone.

Long before the PR I made a prototype in GDScipt and have been using it in my project for few months. Tweens made this way are fun to abuse for lots of different things. I never needed to combine them with AnimationPlayer, this is only useful when you want to visually design some animation.

I know it's handled now, so that in case a yield returns to a now dead node/scene it wont crash but this would have to be handled as well with tweens.

This is irrelevant. You don't need to use yield/away with Tweens, you just tell them to animate something and they animate it. If the animated object is removed midway, the Tween will automatically stop and get deleted.

Maybe it's just me, but I feel like the default behaviour of a tween should be to process in parallel, which is how it works currently.

Dunno, Tween chaining was requested for ages. Personally I more often tween something sequentially than parallely. Maybe I could add a method that makes paralleling default? 🤔

set_loop(n) means "loop n times". Maybe it should be called repeat?

The main problem here is behaviour, not naming. I think the most common use case will be to make tween execute exactly n times in total and having to call set_loop(n - 1) (or however this method will be named) will be counterintuitive and simply annoying. It will be counterintuitive because in most programming languages when you want to execute some code exactly n times you use loop (like for) where you provide template (code block) and tell how many times it should be executed. In your current tween interface you're providing a template (tween) which will be executed once and you can additionally tell how many more times it should be executed. I think it's not what programmers are used to and a common sense is to change it. Of course it's just my opinion and I might be wrong.
So I suggest changing behaviour to set_loop(total_number_of_iterations/executions) (however this method will be named).
For current behaviour: yes, repeat is better name (but it still could be misunderstood because of analogy to standard loops).

set_loop(n) means "loop n times". Maybe it should be called repeat?

The main problem here is behaviour, not naming. I think the most common use case will be to make tween execute exactly n times in total and having to call set_loop(n - 1) (or however this method will be named) will be counterintuitive and simply annoying. It will be counterintuitive because in most programming languages when you want to execute some code exactly n times you use loop (like for) where you provide template (code block) and tell how many times it should be executed. In your current tween interface you're providing a template (tween) which will be executed once and you can additionally tell how many more times it should be executed. I think it's not what programmers are used to and a common sense is to change it. Of course it's just my opinion and I might be wrong.
So I suggest changing behaviour to set_loop(total_number_of_iterations/executions) (however this method will be named).
For current behaviour: yes, repeat is better name (but it still could be misunderstood because of analogy to standard loops).

Totally agree. Iterating n + 1 times is just confusing, makes it feel like a do loop. I feel like most poeple espect it to iterate n times and will have to go backa nd change their code.

I definitely support that chaining should be the default instead of parallel running but a good compromise would be to have two seperate functions to create the tween object: one creates a chaining one and the other creates one that runs all tweens at the same time.

If you don't want the Tween to start immediately, you can call stop() or pause() after it is created. This will be mentioned in the docs.

Fair enough then. If the documentation covers this all is well.

This can be already achieved with

var tween = get_tree().create_tween()
tween.tween_property(...) #A
tween.tween_property(...) # B
tween.join().tween_property(...) # C
tween.tween_property(...) # D

When you use join() or parallel() method, any tweening method called immediately after will run in parallel with the previous one. Tween will go to next step only when all parallel Tweeners have finished.

I don't know but something about doing it this way feels odd to me, maybe the empty join function that looks a bit out of place or useless. It might be just me but it would be good if the simultaneous execution of tweens B and C is not created by adding only tween C in a special way. Adding some empty lines for formatting obviously helps make B and C look like they belong together. Creating "tween-group" objects as I suggested makes it a bit easier  (for me) to conceptualize the sequence and parallel relations.

After some feedback, I added a create_tween() method in Node, which will create a Tween and automatically bind it to that node. Also Tween got a new append() method, which takes a Tweener. Node got an alternative tween_property method that returns PropertyTweener created for that object. With all this combined, you can now do:
create_tween().append(tween_property("position", Vector2(100, 100), 1)).append(tween_property("position", Vector2(100, 200), 1))

Consequently, tween_* methods in Tween were renamed to append_* to make it more obvious that the Tweener created this way is automatically appended to Tween.
From other changes, I added a pause mode called TWEEN_PAUSE_BOUND, which makes the Tween pause when the bound node is paused (without bound node it works like TWEEN_PAUSE_STOP).
I haven't touched set_loops and parallel yet. I'm not sure what to do with the latter. Maybe I should add a set_parallel() method which makes Tween parallel by default and then chain() method which chains the Tweeners when Tween is in parallel mode? (also parallel() would be removed as join() is enough, but it wouldn't have the error which is rather useless).
I yet have to update the OP.

The ability to use custom curves for both the ease and trans is sorely needed

It's great to have nodes ability to create local tweens, very similar API to my JavaScript port of Godot ;) I did the same thing for performance, but have made Tween a completely self contained class that developer can add to any node when they want (a little bit hard to use because you need to update the manager yourself, but anyway as far as I know I am the only developer using that engine).

Consequently, tween_* methods in Tween were renamed to append_* to make it more obvious that the Tweener created this way is automatically appended to Tween.

Not sure if I am a fan of this. If I understand this correctly I would have to use create_tween().append_property(...) to tween a property. My problem with this is that "append property" doesn't make it obvious for people who haven't read the docs that the appended property is being tweened. (Is tweened a word?)
In contrast I immediately understood your create_tween().tween_properties(...) examples even without reading your explanation.
tbh I would prefer it if this change was reverted.
I am also not a huge fan of parallel() and join(). Based on my understanding of the earlier comments the two of them both run the next command in the chain concurrently with the previous command(s).
Bering used to a fork/join workflow this confused me a LOT.
I would recommend parallel() being used to run the next tween concurrently, fork() telling the tweener to make parallel the default mode and join() being used to switch back to sequential mode.

The ability to use custom curves for both the ease and trans would be greatly appreciated

I also vote for custom curve support, but we may not need Godot's built in Curve because it may be better to use a Tween node with Curve and using the editor to do the editing. My suggestion is something like power based curves that may use a cubic spline for implementation, so developers can use cubic params to define the easing.

Ok, I think the code is mostly finished.
From recent changes:

set_loops(n) will make the Tween execute n times instead of n + 1
I added set_parallel(true/false) which will make the Tween parallel by default if set to true (true is also default argument here)
join() was removed. I originally added it, because DOTween calls this method join, but the name is rather confusing, so bye
added chain() method, which makes one Tween operation sequenced when set_parallel() is true
Tweens created outside SceneTree (i.e. with Tween.new()) and Tweens that have finished and got removed are now invalid
You can use invalid Tweens for manual interpolation via interpolate_value(), but attempting to append a Tweener will result in an error
Tweeners got a proper error message that points to correct usage when created manually (e.g. PropertyTweener.new())

Things to consider:

parallel() might need a new name, because it's too similar to set_paralell(). Or at least I imagine some people would say so.
maybe renaming the append_* methods yet again as suggested in https://github.com/godotengine/godot/pull/41794#issuecomment-688609551. Not sure what would be a better name

I can now move to writing documentation and the PR will be finished.

The ability to use custom curves for both the ease and trans would be greatly appreciated

This is a thing for another time. There are plans to rewrite existing interpolaters, see #22513

After considering this for a while, I have to propose the opposite of the current implementation: you simply instruct the tween to wait and finish the last tween before proceeding, or not:
tween.tween_property(...).wait() #A
tween.tween_property(...) #B
tween.tween_property(...) #C
tween.wait()
tween.tween_property(...) #D
...
There may be a better name than "wait" (wait_to_finish? kinda long, but totally clear, and we have autocomplete)
But I see this as having the following advantages over the current join/parallel method:

Superior readability. With the special call more visible at the end of the line, it's easier to see which sections are to run parallel. Sure, you could move parallel() to the end of the previous tween, but it makes a lot more sense to have that come immediately before what you're running in parallel, so I don't see that as an equally good option.

Does not needlessly change the current behavior of parallel = default. I'm all for changing behavior when it's justified, but I don't see a clear majority in favor in this case. Actually, I argue that having parallel as default is...

Way more intuitive. If my boss tells me to do x, y and z, I assume he means to do them in no particular order, in parallel if possible. Sequentiality is what requires explicit instruction: "Do x, THEN when you are finished, do y". You'd never tell someone "don't wait until you do the next task". It's kinda like a confusing double negative, it's just not natural.

Ok, finally finished this. The PR probably needs some testing (because I didn't test much yet).
@djrain I haven't mentioned it, but the parallel() call doesn't need to be followed immediately. Code like
var tween = create_tween()
tween.append_property(...)
tween.parallel()
tween.append_property(...)

will still work perfectly. For opposite behavior, you can use
var tween = create_tween().set_parallel()
tween.append_property(...)
tween.chain()
tween.append_property(...)

Tweens are sequential by default, because it's more often useful from my experience. Maybe eventually we could introduce global tweening options, like default paralleling, trans/ease types etc. but IMO having to add set_parallel() in case you want fully parallel tween is not that bad.

Is it possible to chain parallel tweens? i.e:
var tween = create_tween()
tween.parallel()
tween.append_property(...) # simultaneous
tween.append_property(...) # simultaneous
tween.chain()
tween.append_property(...) # this one happens after

Is it possible to chain parallel tweens? i.e:
var tween = create_tween()
tween.parallel()
tween.append_property(...) # simultaneous
tween.append_property(...) # simultaneous
tween.chain()
tween.append_property(...) # this one happens after

That's what set_parallel() is for. parallel()/chain() affect only the subsequent operation. You can do tween.set_parallel(true) (true is optional) to make all following operations parallel and then set_parallel(false) to make it sequential again.
In case of your snipped, you just have to change parallel() to set_parallel().

Ahh I understand now, good stuff :)

Looked through your PR, looks very good so far. Definitely an improvement when compared to what we currently have.
I am however not certain if I like how tweens are hardcode into scene_tree directly, imo there should be a modular layer between them. To be honest I am not familiar enough with godots internals to suggest a better solution, just feel like there should be a "SceneTreeExtensionsManager" or something like that between the scene_tree, an integral part of Godot, and tweens, which are, in comparison, not all that important.
Maybe someone more qualified could weigh in on this?
My other major problem are the renamed append_* methods. Does obj.append_property() create a new property and add it to some list? Does obj.append_method() append code to some method or append a method call to something?
I really preferred the initial tween_* names. That name made it perfectly clear that they were tweening a property/method call...
Not sure if anyone else agrees with me, but this is currently my biggest problem with this PR.

Looked through your PR, looks very good so far. Definitely an improvement when compared to what we currently have.
I am however not certain if I like how tweens are hardcode into scene_tree directly, imo there should be a modular layer between them. To be honest I am not familiar enough with godots internals to suggest a better solution, just feel like there should be a "SceneTreeExtensionsManager" or something like that between the scene_tree, an integral part of Godot, and tweens, which are, in comparison, not all that important.
Maybe someone more qualified could weigh in on this?
My other major problem are the renamed append_* methods. Does obj.append_property() create a new property and add it to some list? Does obj.append_method() append code to some method or append a method call to something?
I really preferred the initial tween_* names. That name made it perfectly clear that they were tweening a property/method call...
Not sure if anyone else agrees with me, but this is currently my biggest problem with this PR.

I agree with the names, the original tween names where better but some people dissagree. Maybe it would be best to create a poll to see what the majority would prefer.

tbh I also preferred the old names. I added a commit that reverts the rename and in another commit I removed the append method and Node.tween_property. It makes little sense to have single method that works differently. append could be interesting to use with something like CustomTweener, which can be coded by script, but the current Tweeners provide everything needed anyways. It's also easier to add something than remove it. In worst case, we can still do a small breakage before 4.0 stable is released.

We must try to make this not only simple, but also as versatile as possible. How to get the following using your way:

I'd like to be able to create something like this with a single tween. All the other major tweening libraries let you do this.
var tween := create_tween()
tween.tween_property(...) # 1

var first_parallel := tween.parallel()
first_parallel.tween_property(...) # 2
first_parallel.tween_property(...) # 3

var second_parallel := tween.parallel()
second_parallel.tween_property(...) # 4

var inner_sequence = second_parallel.sequence()
inner_sequence.tween_property(...) # 5
inner_sequence.tween_property(...) # 6

tween.tween_property(...) # This runs after everything else is done.

This is now a self-contained animation that doesn't need to spawn other tweens and is way more flexible.
This comes with the cost of being a bit more complex to write, but only very complex behaviours are going to be like this, leaving the rest simple enough.

How about all tween_* function return new reference hold the new start time.
var tween := create_tween()

# run in sequence
tween = tween.tween_property(...)
tween = tween.tween_property(...)
or
tween.tween_property(...).tween_property(...)

# run in parallel
tween.tween_property(...)
tween.tween_property(...)

# mix
var t1 := tween.tween_property(...)
var t2 := tween.tween_property(...)
tween.tween_property(...)
var t3 := tween.wait(t1) or tween.wait_all(t1, t2) or tween.wait_any(t1, t2)
t3.tween_property(...)

@Kinwailo Seems like a good idea.
Would be perfect if returned references could support some sort of comparisons to know which one ends first/last, and if functions like max(twens...) and min(tweens...) could be provided as a quality of life.
I'm a little concerned about the effective sequentiality of tweens concatenated this way, there may be a few corner cases in which a tween intended to play after another bunch of tweens starts playing when one of them is still in its last frame.
Oh, aside that, I'd very like the ability to:

Manually update a tween, something like:
tween.update(delta)
to fast forward the tween by an arbitrary amount of time.
Have a tween in a mode in which only manual updates make it work.

@Kinwailo Sorry, but I don't see what the advantage of your suggestion would be. It is possible to do the same thing with the current implementation just by using set_parallel().
Plus, changing the returned object in such a way would probably break quite a few assumptions that developer experienced with method chaining might have.
@samdz I like your update suggestion, though I would probably call it set_delta(delta) instead.
Assuming we get a set_delta method it should be possible to only allow manual updates by simply pausing the tween.

I like your update suggestion, though I would probably call it set_delta(delta) instead.
Assuming we get a set_delta method it should be possible to only allow manual updates by simply pausing the tween.

This is a matter of exposing the step(delta) method to GDScript and modifying it to allow manual stepping of paused Tweens. Name set_delta suggests something completely different.
Alternatively, this is already possible by using pause(), play() and set_time_scale() in a clever way 🙃

Well, step would only allow changing the progress based on the current state of the tween. A setter would make it possible to track the progress outside of the tween and would make it easier to jump around. Useful if you want to skip forward/backward to a specific part of the animation or if you want to reset the tween manually.
Based on his request I assumed he wanted to have a setter to directly control the current state of the tween.

would it be any trouble to also add a custom_set_time() method?

The problem is that progressing the tween interpolates the new value. To set the time to an arbitrary point backwards, some reverse interpolation would be needed (not sure if simply interpolating with negative delta would work). Also the Tween would need to keep track of current time and total time (right now only Tweeners keep track of time). This would make the code more complicated overall.
For arbitrary seeking in an animation, you should either use the Animation resource or implement it yourself. This is not common enough use-case for Tweens to add it.

Oh, I assumed that tweens would store the starting values of all modified variables until the transition was done. Now that I am thinking about it I can see the problems this approach would have. Negative delta might work for some transition types but definitely not all.
Yeah, I can see how implementing and maintaining this would be more trouble than it is worth.

Uhm, I often rely on tweens having the ability to go backwards in other engines and I find it very very useful...

is it still ok to leave suggestions here or is there a better place to do this?
get_processed_tweens — why not just get_tweens?

get_processed_tweens — why not just get_tweens?

Because there might exist Tweens outside SceneTree and they are not returned by this method. This name makes it more clear.

Rebased with changes from #42683. binds/params were removed, you can now use Callable.bind (it's mentioned in the doc too). It was a bit sad to remove argument called p_arams xd
Unfortunately Callable.bind seems to be broken right now and returns null, so the changes are untested yet. Also not sure how to handle the additional arguments when printing error.

Are there any planned features that haven't been implmented or will this be merged soon?

The PR has a very good base of features and there's nothing planned anymore for now, but hard to say when will it be merged (someone needs to review it and it's big).
tl;dr no/no

I just pushed another commit that changes how time is processed in Tweens. Previously (I mean in my PR), the steps were basically deferred. E.g. if there were two steps with duration of 0.01 and the delta was 0.016, the Tween was doing full 2 steps on span of 2 frames. Now it will do 1 full step and 0.006 seconds of second step. So the Tween will step Tweeners until the cumulative delta is exhausted.
To explain it better, here's a code to test:
var tween = create_tween().set_speed_scale(100)
tween.tween_property($Sprite, "modulate", Color.red, 0.01)
tween.tween_property($Sprite, "modulate", Color.red, 0.01)
tween.tween_property($Sprite, "modulate", Color.red, 0.01)
tween.tween_property($Sprite, "modulate", Color.red, 0.01)
tween.tween_property($Sprite, "modulate", Color.red, 0.01)
tween.tween_property($Sprite, "modulate", Color.blue, 0.01)
await get_tree().idle_frame
await get_tree().idle_frame
print($Sprite.modulate)

Before my last commit, this prints red color. Now it prints blue, because speed scale of 100 means a delta of 1,6 and all Tweeners are done in one frame, instead of 6 frames. This also means that CallbackTweeners with no delay are effectively parallel by default, because they execute all on the same frame.

Rebased and fixed some bugs (the GIFs in the OP are a nice test suite 🙃).

I so want this. Hope it gets merged soon!

I really like this. Hope the creator of Anima take a look at this.

I had to squash the commits to make rebasing easier. Technically it might be ready to merge 😏

Seems like you need to rebase to fix the Reference -> RefCounted change.

We discussed this in a PR review meeting today and decided that it should be good to merge and YOLO-test it in the master branch.
I'd like to see an amend of the commit message to add more details about what the rewrite actually changes in the body of the commit message.

@akien-mga Done.

Thanks!

I would sell my family to see that in 3.x :stuck_out_tongue_closed_eyes:

3.x version was done long ago: https://github.com/godot-extended-libraries/godot-next/pull/50
It's worse, but I've been using it successfully in many projects.

3.x version was done long ago: godot-extended-libraries/godot-next#50

Eh, it's a shame it's non-native version though :disappointed: and lacks a lot of awesomeness from the PR.
I try to keep my project(s) as clean as possible and not mix-in other languages (I use mainly C#).
But thanks anyway! :)

Would you please add a complete callback for a Tweener?
Something like
tween.tween_property($Sprite, "position", Vector2(200, 0), 0.5).on_complete(callable)

@alexzheng You can just do tween_callback(callable), not sure why would you need a signal. Also, for feature requests, please open a proposal.

it would be much easier for parallel tweezers.
For example
tween.parallel().tween_property($Sprite, "position", Vector2(200, 0), 0.5).on_ finished(callable)
tween.parallel().tween_property($Sprite2, "position", Vector2(200, 0), 1).on_ finished(callable2)

I just checked and Tweeners do already have finished signal. So you can do
tween.parallel().tween_property($Sprite, "position", Vector2(200, 0), 0.5).finished.connect(callable)

It's not possible right now. Also get_processed_tweens() returns all Tweens and you can't get the bound node from a Tween, so the best way to have a list of Tweens bound to a node is make one yourself (i.e. put any created Tween in an Array variable).
If you think Tweens should support that normally, open a proposal.

Hello @KoBeWi I don't know if it is a bug or not so I am posting this comment. I tried to queue_free() my node when there was tween in the scene looping. When I tried to do it whole game just crashed without errors or anything.  Maybe there is some way to auto free tween when someone free node?

@seppoday The Tween should auto-kill when the object gets deleted, so it sounds like a bug. Open a new issue with some minimal project

@KoBeWi

@seppoday The Tween should auto-kill when the object gets deleted, so it sounds like a bug. Open a new issue with some minimal project

i guess it's a bug, because when i use a tween in a button for a menu, then close and free that menu i get this warning :
W 0:00:09:0746   start: Target object freed before starting, aborting Tweener.
  <C++ Source>   scene/animation/tween.cpp:702 @ start()

This is expected, if you free an object before animation starts, you get this warning. Although maybe it's not useful, idk 🤔

This is expected, if you free an object before animation starts, you get this warning. Although maybe it's not useful, idk thinking

But the animation is already started and finished, but for some reasons i still get this warning
var ButtonTween : Tween = get_tree().create_tween()
ButtonTween.set_pause_mode(Tween.TWEEN_PAUSE_PROCESS)
ButtonTween.tween_property($BackgroundFocus, "rect_size", Vector2(0, self.rect_size.y), 0.15).set_trans(Tween.TRANS_LINEAR)

This code i used it in a button for a Pause menu to animate the button, but if i change the level or go to the main menu or close the game i get the warning

I tried your code and I don't get this warning. Can you share some minimal project? Also you could open a new issue.

Just a bit of clarification (that maybe could be added somewhere?): What about tweens that are used over and over again, when the node doesn't get removed? I tested this, and the object count in the debugger continues to shoot up. Do those eventually get removed, or does the node need to be free'd?

All Tweens are removed automatically when not used anymore, but there is a known issue when it doesn't work: #52699

Tween changes so much that the documentation is not yet sufficient to cover all use cases. I found a problem when using it that tween cannot be created outside the function, if this is not a bug, then it should be noted.
`
var tween
func _ready() -> void:
tween = create_tween()
func transition()->void:
tween.tween_property($Sprite, "modulate", Color.red, 1)
`

Tween changes so much that the documentation is not yet sufficient to cover all use cases. I found a problem when using it that tween cannot be created outside the function, if this is not a bug, then it should be noted.
var tween
func _ready() -> void:
	tween = create_tween()

func transition()->void:
      tween.tween_property($Sprite, "modulate", Color.red, 1)

Can confirm I had strange issues when using a tween created outside a function. The error wasn't exactly clear of what was going wrong, either

The documentation has countless examples where Tween animation is defined right after its creation, discourages re-use and tells you that you should use stop() when doing it.
But maybe the error should tell that too.

I am using tweens extensively in code. The key lines in the documentation are these:
Note: All Tweens will automatically start by default. To prevent a Tween from autostarting, you can call stop() immediately after it is created.

Note: Tweens are processing after all of nodes in the current frame, i.e. after Node._process() or Node._physics_process() (depending on TweenProcessMode).

That means you created an empty tween in ready, the tween begins that frame and continues looping indefinitely, then later on a subsequent frame, you're adding additional properties to change. The docs don't say what is supposed to happen when you add tweens while its running. Create it and set it up in the same frame you want it to run, or stop it upon creation for set up later as KoBeWi wrote.

How are Tweens supposed to be created when continuously tweening something in _process()? Or is that a bad use case for them?

Generally, new devs should not create tweens in process. You don't want to create tweens 300 times per second. However, you can do it if you are manually checking the frequency and ensuring you're only creating them one every X seconds where X is less than or equal to your tween time.


LDAP: authentication user is broken

Original approach of the LDAP implantation is that you first need to setup the LDAP server. For the authentication you need to create the same group in OPNsense and LDAP. The permissions in auth.inc are read correctly but they are broken in OPNsense\Core\ACL.php as there are only local users processed. This results in an empty system menu.
Better approach would be to create the user with linking to LDAP in OPNsense. And group permissions should be handled locally.

commit https://github.com/opnsense/core/commit/b4845e6270bf5e885b953800d6a3e9b8323f9316 contains the "final" part of the rewrite.
You can import ldap users now in system_usermanager.php and change the permissions afterwards.

Note that this commit is not part of 15.7.5's opnsense-devel package, but will be available in 15.7.6's *opnsense-devel. Whether or not this code will go into the stable 15.7.6 needs to be decided...

@AdSchellevis @chrisch1974 close this then?

yes, let's close it.


Testing the API auth.

Should we maybe add a test which tries to authorize with the api and fail if it's not able to do  so?

Not a priority currently so closing this.


Error while importing getRequestParams

I am running the app like this:-
node --experimental-modules index.mjs
and this is line is giving error
import TikTokAPI, { getRequestParams } from 'tiktok-api';
error:-
(node:5872) ExperimentalWarning: The ESM module loader is experimental.
TypeError: getRequestParams is not a function
    at file:///D:/Node.js/FirstTry/index.mjs:14:16
    at ModuleJob.run (internal/loader/ModuleJob.js:97:14)
    at <anonymous>

P.S I am new to node.js.

Hi, @shashank0708
How dow you fix this? We meet the same issue.

@lijuanliu2018 ECMAScript Modules are still experimental so I'm not inclined to invest into resolving this.  Use Babel, TypeScript, etc. if you want this functionality now.
Alternatively, you are able to work around this by simply using the default export:
import TikTokAPI from 'tiktok-api';

const requestParams = TikTokAPI.getRequestParams({...});


Update LICENSE

updated year 2018 -> 2019 in license file

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Problem with handleEvents option in makeServicePlugin method

I have a problem, that is described there: https://github.com/feathersjs-ecosystem/feathers-vuex/issues/397
so I thought, that for now I would refresh other services by using handleEvents property, but it seems to not appear in the state of the model (I don't know if it is supposed to), but also it's not working (I put console.log there, and it's not called).
Steps to reproduce
This is what I did:
// store/services/roles.js
const servicePlugin = makeServicePlugin({
  Model: Role,
  service: feathersClient.service(servicePath),
  servicePath,
  handleEvents: {
    created: (item, { model, models }) => {
      console.log("roles: created event");
      return true;
    },
    ... // Same with the rest of handlers
  }
});

When it wasn't working, I also added this part:
// plugins/feathers.js
const {
  makeServicePlugin,
  makeAuthPlugin,
  BaseModel,
  models,
  FeathersVuex
} = feathersVuex(feathersClient, {
  serverAlias: "api"
  idField: "id" // Using sequelize
  debug: true,
  whitelist: ["$regex", "$options"],
  enableEvents: true,
  handleEvents: {
    created: () => true,
    updated: () => true,
    patched: () => true,
    removed: () => true
  }
});

Is there something I am doing wrong? It seems straightforward, but no luck so far.
If you will need more details, I will try to create a bigger example
Expected behavior
Handlers are called when I create an object.
Actual behavior
Handlers are not called.
System configuration
Module versions
"feathers-vuex": "^3.9.4",
"@feathersjs/feathers": "^4.5.3",
"@feathersjs/socketio-client": "^4.5.4",
"@vue/composition-api": "^0.5.0",
"feathers-hooks-common": "^5.0.3",
"nuxt": "^2.12.2",
"socket.io-client": "^2.3.0",

NodeJS version: v13.13.0
Operating System: Ubuntu 19.10
Browser Version: Mozilla 75.0

Can you please check in your network panel if you are receiving the events ?
I don't see how it couldn't works...

I don't see anything in my network panel, but when I create a role on one browser, it shows on the other one, so I assume, that sockets work.
I've also added a code from this section: https://vuex.feathersjs.com/model-classes.html#model-events - this one works (I can see logs in the console).
Can it be because I'm using nuxt? Maybe there is some additional configuration required?

I think the offending code is in make-service-plugin.ts.
    const options = Object.assign({}, defaults, globalOptions, config)
    const {
      Model,
      service,
      namespace,
      nameStyle,
      instanceDefaults,
      setupInstance,
      preferUpdate
    } = options

    events.forEach(eventName => {
      if (options.handleEvents[eventName])
        options.handleEvents[eventName] = () => options.enableEvents || true
    })

The handlers passed in are being overridden. I think just negating the if statement would do the trick. (if(!options.handleEvents[eventName]))

It might be caused by Nuxt, have you followed the Nuxt chapter in the docs ?

Um, I've did like the @hamiltoes said, and voila! It works!

Good catch @hamiltoes ! This bug must be addressed.

I'm happy to put together a PR. I was thinking expected (and desired) behavior would be to fall back to any global option handleEvent method if one is defined.

This bug was introduced in this commit .
Before that, the default event handlers were added before the options where merged.
I think this is a good idea, thank you for your help, feel free to submit a PR !

The fix for this is available in<EMAIL_ADDRESS>


⚠ Bofrost.be has degraded performance

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

HTTP code: 200
Response time: 2199 ms

Resolved: Bofrost.be performance has improved in a20fb2a.


[2.x] Bump to 2.7.0 version

Description
Bump version to 2.7.0 in 2.x branch
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #356 (e45a64a) into 2.x (0907756) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##              2.x     #356   +/-   ##
=======================================
  Coverage   84.26%   84.26%
=======================================
  Files          18       18
  Lines         464      464
  Branches       73       73
=======================================
  Hits          391      391
  Misses         51       51
  Partials       22       22

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Implement -n option for pipe mode.

Improve the way for separating standard input strings.
Introducing same tokenization logic as xargs, we can implement -n option as same as xargs like this.
$ command  | xpanes -n 2 -I@ seq @

Fixed with v2.1.0.


Add support for importing declared types in version index file

This PR requires types defined in the service config in the version index file (Ruby only).
This was motivated by using custom exception types. Importing them in the index makes it more likely they will be included when an exception is raised.

Codecov Report

Merging #1850 into master will increase coverage by <.01%.
The diff coverage is 91.3%.

@@             Coverage Diff              @@
##             master    #1850      +/-   ##
============================================
+ Coverage     84.73%   84.74%   +<.01%
- Complexity     4605     4610       +5
============================================
  Files           438      438
  Lines         18294    18316      +22
  Branches       1932     1936       +4
============================================
+ Hits          15501    15521      +20
- Misses         2126     2127       +1
- Partials        667      668       +1

Impacted Files
Coverage Δ
Complexity Δ

...i/codegen/viewmodel/metadata/VersionIndexView.java
100% <ø> (ø)
5 <0> (ø)
:arrow_down:

...a/com/google/api/codegen/config/DiscoApiModel.java
66.66% <0%> (-2.09%)
10 <0> (ø)

...a/com/google/api/codegen/config/ProtoApiModel.java
94.44% <100%> (+0.89%)
18 <2> (+2)
:arrow_up:

...ain/java/com/google/api/codegen/InterfaceView.java
100% <100%> (ø)
5 <4> (+2)
:arrow_up:

.../transformer/ruby/RubyGapicSurfaceTransformer.java
99.59% <90.9%> (-0.41%)
31 <0> (+1)

Continue to review full report at Codecov.

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


fix(exports): replace const with var

What:
Replaces 'const' with 'var'.

Why:
To not break apps loading in environments without const support (since the code doesn't get transpiled).

Checklist:

[ ] Documentation N/A
[ ] Tests N/A — they pass
[ ] Code complete N/A
[ ] Added myself to contributors table
[x] Followed the commit message format

Codecov Report

Merging #143 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #143   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          10     10
  Lines         134    134
  Branches       34     34
=====================================
  Hits          134    134

Continue to review full report at Codecov.

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

Thanks!


Share and Send feature not working

Added the Share and Feedback feature in the LandActivity.java

This PR must be followed by the two more PR's I made by the name Updating strings.xml as they are a part of the same issue...


Siconos crash when using MLCP_Direct_Enum instead of MLCP_Enum (MCS simulation)

Hello,
I have some problems simulating an mixed complementarity system (1st order) with some non-linearities in the dynamic, and input function. The one-step problem is given by a fully implicit Euler discretization. I then solve it using a MLCP solver (I do not use a MCP/NCP formulation for reasons I will not detail here). The PATH and ENUM solvers provide the correct results with respect to my reference.
However, when using the the DIRECT_ENUM solver I have a died with <Signals.SIGSEGV: 11>  error at the definition of the ONSP
( see line SP::MLCP osnspb(new MLCP(SICONOS_MLCP_DIRECT_ENUM)); in the joined .cpp file).
It seems something is not correctly initialized and this raises a exception, do you have an idea ?
Example_MLCP_DIRECT_ENUM_Crash.zip

After recent update and a complete reinstallation of Siconos with openblas and lapacke I do not have this error anymore. I guess it was coming from a wrong install.


How can I get the highest memory usage for a given period of time for container?

I used the
max_over_time(container_memory_usage_bytes{container_name="kibana-logging"}[1h]) like this;
but "[1h]" mean  an hour before the current time and I get the highest container_memory_usage_bytes for last one hour;
I want to specifiy time period,such as 2017-05-03T12:42:00.781Z to 2017-05-03T23:42:00.781Z or other time period like this,I just want to get the data at the time period I have specified.
Is there any method can sovle my problem?
Thanks a lot!

Please ask usage questions on the mailing list, as I see you already did at https://groups.google.com/forum/#!topic/prometheus-users/8D32g1mTmv4.
Closing.


Documentation: CloudkickHandler

As far as I know Cloudkick was integrated into Rackspace some years ago and while it doesn't really matter, it's still used as an example in the Readme.

Documentation has been updated on the website and in this cookbook. Thanks for pointing this out.


feat: Create CRUD utils to work with company evaluations

Type of PR

[x] Feature

Merge strategy

[x] Squash (default)

Purpose

Create the function to allow us

-[x] Create a company evaluation
-[x] Get a company_evaluation by id
-[ ] Get all company evaluations by the company_id

Relevant tickets

#12

Related PR's

Paste here the links to related PR's

I need to modify the utility to get all company evaluations by company_id 💥 👀

Done 👍🏼


Speed telegraph changes speed but lever doesn't move

When I change the speed with the telegraph, the speed of the ship does change but the lever stays in the 'stop' position

i have the same problem

in version 10.0 this bug don't occurs

Someone should close this, it seems to be fixed.

Someone should close this, it seems to be fixed.

You got it chief!


Portability: add support for big endian and need-aligned-load-store architectures

tracking issue for supporting more architectures
#24 #25

Just a little factoid to create additional motivation to fix this issue: I just noticed that you have become a dependency of git-annex, which is a popular tool on little NAS devices which often run arm or mips.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796800
for a patch.

I applied that patch to the Debian directory, and it seems to help on arm64, armel, kfreebsd-i386, ppc64el; compare https://buildd.debian.org/status/logs.php?pkg=haskell-cryptonite&ver=0.6-1&suite=experimental with https://buildd.debian.org/status/logs.php?pkg=haskell-cryptonite&ver=0.6-2&suite=experimental
It still fails for the big-endian architectures: powerpc, s390x, ppc64.
It also uncovered a bug that quickcheck seems to find only occasionally and that seems to be independent of this patch, I opened issue #29 for it.

@egrimley: the intent of the arch section detecting the endianness, if for endian-constant architecture like x86/amd64 to not have to go through any 'if byteOrder then x else y' branching code. Sadly, with some personal experiments in, an unrelated, but similar case, ghc was not able to optimise endianness away. For non-endian-const architecture like mips/arm, the goal was to do this if byteorder then .. else .. business (not to autodetect/hardcode the endianness of the arch)
Also one more thing, cryptonite shouldn't depends on any extra packages.

If I understand correctly, you're suggesting that the cabal file distinguish three cases (little-endian arch, big-endian arch, variable-endian arch) and then the Haskell code, likewise, have three implementations. That sounds rather complex and difficult to maintain. It might be worth checking if you can, somehow, get GHC to optimise away the endianness test, and then include the appropriate part of the byteorder package (which is tiny) if you don't want the additional dependency.
The funny thing is that when I write C I don't use preprocessor endianness tests at all. I just write stuff like
static inline uint32_t read32le(unsigned char *b) { return b[0] | (uint32_t)b[1] << 8 | (uint32_t)b[2] << 16 | (uint32_t)b[3] << 24; }
and expect the compiler to do the right thing. GCC 5.2.1 does, in fact, turn that code into a single load instruction on (little-endian) AArch64.

Also one more thing, cryptonite shouldn't depends on any extra packages.

It seems that the functionality is also available in your memory package that you depend on anyways: http://hackage.haskell.org/package/memory-0.8/docs/Data-Memory-Endian.html#v:getSystemEndianness
And looking at that implementation, with getSystemEndianness = LittleEndian set depending on CPP flags, I sincerly expect GHC to optimize a pattern match on that away. This is different from the byteorder package, where byteorder is always defined in terms of some unsafePerformIO.

Sincerely expecting and reality often mismatch in the case of GHC (specially considering the broad versions supported); I've seen some pretty horrible stuff happening, so I've learned to be paranoid/careful.

From https://github.com/vincenthz/hs-memory/blob/master/memory.cabal I get the impression that memory might have the same problems as cryptonite.
If there is an easy way of getting GHC to optimise away endianness tests then it doesn't seem to be widely known. This page only suggests template Haskell:
http://stackoverflow.com/questions/29349835/conditionally-compiling-based-on-endianness
So perhaps a good approach would be to use an inefficient but portable run-time endianness test but push the test up the call tree so that it doesn't hurt performance (much). So instead of having be32Prim test for endianness you'd get mutableArray32FromAddrBE to test for endianness and select between two implementations, with and without byteswapping.

@egrimley I've never seen the unoptimised 8 bit access, optimised in 32 bits access before in the case of gcc, but I haven't done any benchmark of that sort of optimisation in many years ;). also by default, I would just write the optimised case without thinking about it really.
GHC is much more archaic in those low-level machine optimisation

Sincerely expecting and reality often mismatch in the case of GHC (specially considering the broad versions supported); I've seen some pretty horrible stuff happening, so I've learned to be paranoid/careful.
Ok, I checked: This code
foo = case getSystemEndianness of
    LittleEndian -> "le"
    BigEndian -> "be"

main = putStrLn foo

optimizes the check away, leaving Main.main2 = GHC.CString.unpackCString# "le"# in the simplified Core.

@vincenthz I hope you realise that the "optimised" C code you're referring to is probably incorrect and that a grumpy C compiler could do something very nasty with it, like assume that the bad code is unreachable and optimise the entire program on that assumption, along the lines of
if (x) *(uint32_t *)p = ...
"That memory access would be illegal, so now we know that x must be zero, so..."
A few years ago you wouldn't have to worry about that but modern C compilers really do stuff like that.

@nomeata So Data.Memory.Endian does the job, and it seems to do it by #including "MachDeps.h", which is supplied by GHC. That's the quick and easy solution, then. Thanks.

@egrimley: it's incorrect to use {,double,quad}word memory access ? Can you point me to relevant informations ?

In general you're not allowed to dereference a pointer unless the pointer value was obtained by taking the address of an object with a compatible type. So I was thinking of a situation in which the compiler can see that p was not obtained thus. You're pretty safe, in practice, if p is an argument passed from code that was generated separately, though if you have char *p and you use both *(int *)p and *(int *)(p + 15) then the compiler can deduce that one of those is unaligned and therefore undefined (regardless of whether the hardware allows unaligned memory access). Undefined behaviour invalidates the entire execution, which is why the compiler can assume that x is zero not just after the if (x) *(uint32_t *)p = ... but beforehand, too. By the way, I'm not an expert language lawyer, so I might be erring on the side of caution here...

unaligned access is never undefined. the compiler could maybe decide to change the access method (switch to instructions that uses bytes), but I don't really see the compiler removing instructions because it thinks they are invalid.

@nomeata I think most issues should be fixed, any chance you can check that the latest version work properly for second tier archs ?

cryptonite-v0.7 seems to require memory >=0.8 (for B.snoc and
Base64OpenBSD) while Debian only has haskell-memory 0.7-3 in experimental
so it might be easier to wait a bit.


openEBS ISCSI Error

RancherOS Version: (ros os version)
1.4.0
Where are you running RancherOS? (docker-machine, AWS, GCE, baremetal, etc.)
vsphere 6.5
Running rancher2
OpenEBS from helm
I got this error
MountVolume.WaitForAttach failed for volume "pvc-5cc527d9-9a71-11e8-88ab-005056a69a74" : failed to get any path for iscsi disk, last err seen: iscsi: failed to sendtargets to portal <IP_ADDRESS>:3260 output: iscsiadm: Could not open /run/lock/iscsi: No such file or directory iscsiadm: Could not open /run/lock/iscsi: No such file or directory iscsiadm: Could not open /run/lock/iscsi: No such file or directory iscsiadm: Could not add new discovery record. , err exit status 6	2 minutes ago
yes I executed ros service up open-iscsi
if I open a ssh connection to the VM and I execute  command iscsid automatically openEBS volumes work
but If I execute ps aux | grep iscsid the new process apear as detached
Before / After
root@isaac-master1:/home/rancher# ps aux | grep iscsi root      6337  0.0  0.0      0     0 ?        I<   Aug06   0:00 [iscsi_eh] root     21170  0.0  0.0  24984   284 ?        Ss   18:50   0:00 /sbin/iscsid root     21171  0.0  0.1  33928  5308 ?        S<Ls 18:50   0:00 /sbin/iscsid root     25273  0.0  0.0  11284   964 pts/0    S+   18:56   0:00 grep --color=auto iscsi root@isaac-master1:/home/rancher# iscsid root@isaac-master1:/home/rancher# ps aux | grep iscsi root      6337  0.0  0.0      0     0 ?        I<   Aug06   0:00 [iscsi_eh] root     21170  0.0  0.0  24984   284 ?        Ss   18:50   0:00 /sbin/iscsid root     21171  0.0  0.1  33928  5308 ?        S<Ls 18:50   0:00 /sbin/iscsid root     25331  0.0  0.0      0     0 ?        Zs   18:56   0:00 [iscsid] <defunct> root     25332  0.0  0.0      0     0 ?        Z    18:56   0:00 [iscsid] <defunct> root     25387  0.0  0.0  11284   976 pts/0    S+   18:56   0:00 grep --color=auto iscsi

Can I add the apt install --no-install-recommends open-iscsi inside  the /opt/rancher/bin/start.sh?
runcmd is executed before or after /etc/rc.local and before or after /opt/rancher/bin/start.sh?
thank you!

runcmd ---> /opt/rancher/bin/start.sh ----> /etc/rc.local

It seems the error is gone but now appears another
`
MountVolume.WaitForAttach failed for volume "pvc-e36b99e9-9cd8-11e8-b3c0-005056a61abf" : failed to get any path for iscsi disk, last err seen: iscsi: failed to sendtargets to portal <IP_ADDRESS>:3260 output: iscsiadm: connect to <IP_ADDRESS> timed out iscsiadm: connect to <IP_ADDRESS> timed out iscsiadm: connect to <IP_ADDRESS> timed out iscsiadm: connect to <IP_ADDRESS> timed out iscsiadm: connect to <IP_ADDRESS> timed out iscsiadm: connect to <IP_ADDRESS> timed out iscsiadm: connection login retries (reopen_max) 5 exceeded iscsiadm: No portals found , err exit status 21
`

Ubuntu OS works fine with your case, I will check it out if there a problem with RancherOS.
Otherwise, I am not sure if it is a problem with RancherOS or a problem with setup configuration.

@rootwuj Please help to confirm this issue when you have time. It's better to confirm if openebs(from rancher catalog) can work on Ubuntu.
ping @kingsd041

I added RKE cluster of Ubuntu OS on Rancher2 (the network is flannel), Then deploy openEBS from rancher catalog, and finally created the PVC using the storage class of the openebs. PVC was created successfully.

well the problem is related with rancherOS not Ubuntu

I came here from google...
$ kubectl describe pod dbench-2knzm --namespace dbench-openebs
...
Events:
  Type     Reason                  Age               From                      Message
  ----     ------                  ----              ----                      -------
  Normal   Scheduled               57s               default-scheduler         Successfully assigned dbench-openebs/dbench-2knzm to node10173119244
  Normal   SuccessfulAttachVolume  57s               attachdetach-controller   AttachVolume.Attach succeeded for volume "pvc-524e1b80-dbd6-11e8-b0b9-12ad5e99cc8f"
  Warning  FailedMount             8s (x7 over 40s)  kubelet, node10173119244  MountVolume.WaitForAttach failed for volume "pvc-524e1b80-dbd6-11e8-b0b9-12ad5e99cc8f" : failed to get any path for iscsi disk, last err seen:
iscsi: failed to sendtargets to portal <IP_ADDRESS>:3260 output: iscsiadm: Could not open /run/lock/iscsi: No such file or directory
iscsiadm: Could not open /run/lock/iscsi: No such file or directory
iscsiadm: Could not open /run/lock/iscsi: No such file or directory
iscsiadm: Could not add new discovery record.
, err exit status 6

But I don't know how to fix it. Stop using rancherOS?

I will make dir /run/lock automatically in the console so that you don't have to configure runcmd.
If someone is running kubelet in a container, one thing to note： https://docs.openebs.io/docs/next/tsgiscsi.html
Rancher uses RKE to build the k8s cluster, and RKE runs kubelet in a container.


Don't depend on the Android support library in google_maps_flutter.

It was used for permission checking, I just included equivalent
permisison checking code and avoided the support library dependency.


JK

Firstly, thanks for making this amazing plugin! I am using the NvChad distro, and I have installed hardtime.nvim using Lazy and set lazy = false so the plugin is enabled on startup. I have run into a odd situation where it hardtime.nvim does not pick up J/K repeating. I can fix this issue by running ":Hardtime toggle" twice ( or ":Hardtime enable" and then ":Hardtime disable") in order to switch hardtime.nvim off/on. Any thoughts on why this might occurring would be appreciated!

Could you try to remove the lazy = false and see whether it works?

Does hardtime.nvim not pick up only j/k repeating? How about other keys?

Also running NvChad and am having this issue. I am wondering if it is due to NvChad's j/k mapping https://github.com/NvChad/NvChad/blob/v2.0/lua/core/mappings.lua#L40

Thank you!


Update error.go

#51  implement ErrorDlrNotFound

You will also add ErrorDlrNotFound to

var ERRORS []error = []error{

	ErrorNone,

	ErrorUserNotFound,

}

here

And you have to returnt ERRORS


when creat new project with wizard , it will  report file not found , I use the version  23.0.0

Describe the bug
when creat new project with wizard , it will  report file not found .  I use the version  23.0.0 and the labview is 2020 .
The report version is below:
LabVIEW: (Hex 0x7) File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct.
VI Path: C:\Program Files (x86)\National Instruments\LabVIEW 2020\project_Compiled HTML Menu Tool\Wizard\Copy Template Files.vi
_Compiled HTML Menu Tool folder seem that didn't  generation by install step .

@wangwei357 That directory should be created when you install the VeriStand Custom Device Development Tools. Have you installed the ni-veristand-custom-device-development-tools-2020-support_<version>_windows_x64.nipkg from that repository?
You will also need to install the HTML Workshop as noted in the README.

@buckd  Thanks. You are so kindy.   It's my mistake . I had reinstall them and all is OK now.


Error thrown when installing plugins using snap-installed Insomnia

Expected Behavior
Install a plugin is not resulting to an error and successfully install the desired plugin
Actual Behavior
When I'm trying to install a plugin from Preferences -> Plugins I get this error message:

Reproduction Steps

Go to 'Preferences-Plugins'
Enter "insomnia-plugin-usage-logger" (for example)
Click on 'Install Plugin'

Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
2021.7.2
What operating system are you using?
Ubuntu
Operating System Version
20.04.1
Installation method
snap
Last Known Working Insomnia version
No response

@Ankhas thank you for reporting this issue!
I was able to reproduce it as well on Kubuntu 21.10, example screenshot:

I was unable to reproduce it using Insomnia installed from .deb package on the same name, so perhaps @Ankhas  you can try that as an alternative.
Leaving some more notes on how to reproduce:
(In my case, Kubuntu, which is Ubuntu)

Run snap find insomnia (optional)
Run sudo snap install insomnia, wait for installation to finish
Run snap run insomnia
Open up preferences, switch to plugins tab
Try to install insomnia-plugin-usage-logger

You should see an error like the one reported by @Ankhas:
Error: Yarn error /snap/insomnia/166/insomnia: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory

    at file:///snap/insomnia/166/resources/app.asar/bundle.js:117470:16
    at ChildProcess.exithandler (child_process.js:319:5)
    at ChildProcess.emit (events.js:315:20)
    at maybeClose (internal/child_process.js:1021:16)
    at Socket.<anonymous> (internal/child_process.js:443:11)
    at Socket.emit (events.js:315:20)
    at Pipe.<anonymous> (net.js:674:12)

Wasn't able to reproduce on other systems, both on 2021.7.2 and previous 2021.6.0.

@warrenc5 Yes you are right. From my understanding snap seems to have isolated environments and when you clean it, everything is purged. Perhaps taking backup may be the solution.

hi, I checked on the bug in the issue linked above.
Here is my last comment with the root cause:

I do not know much about snap packages. It looks like the library is already contained. There is already one in the snap directory.
find /snap/insomnia/196/ | grep libnss3
/snap/insomnia/196/usr/lib/x86_64-linux-gnu/libnss3.so
I can see that the insomnia binary is looking in the wrong location. ldd gives me the following
ldd /snap/insomnia/196/insomnia | grep nss
libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x00007f8977434000)
libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so (0x00007f8977403000)
My libnss3.so is in usr/lib/x86_64-linux-gnu/libnss3.so and the snap one is in /snap/insomnia/196/usr/lib/x86_64-linux-gnu/libnss3.so. So the build process is messing up something.

What is even stranger is that libnss3.so is found when I call insomnia directly.
So, calling /snap/bin/insomnia in a terminal gives the this error. If i call /snap/insomnia/196/insomnia , I can install the plug-in without problems.


RenderToLayer: removed touchstart events, to prevent double call for …

onRequestClose callback listens for two events, touchstart and click.
On touch device both events actually fired, so the callback called twice, which brings errors in application, so its better to remove it rather handle double call in the application

@midan888 I like the idea but it might broke the nested menu feature. To verify.

@oliviertassinari had you time to test this one, does it break anything ?

@midan888 Works great for me - Thanks! 👍

@hai-cea Cool thanks!


nginx: add defaultPort and defaultSSLPort options

Description of changes
These 2 new options allow you to specify the default ports for Nginx for all the vhosts - allowing for example to use openvpn's portshare feature.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

Please squash the commits and remove the examples.

superseded by #198529


[otbn] Fix multiple increment signals from decoder

When an instruction attempted to do multiple increments with indirect
register addressing (which produces an illegal instruction error),
multiple increment signals got set violating a unique constrait for the
case statement used to mux the possible increments.
Fixes #7884
Signed-off-by: Greg Chadwick<EMAIL_ADDRESS>

@ctopal I did manage to reproduce the issue and check this fixed it but I'd be grateful if you could confirm everything works.


Problem while updating user avatar manually

Version information

Laravel: v5.6.*
Voyager: v1.1.*
PHP: 7.2
Database: [MySQL] [version] (e.g. MySQL 8.0)

Description
How can i update the user avatar manually and store the avatar in default location and remove the old avatar ??

Just place the new file in place of the old one with the same name.
if that's not possible (i.e. different file extensions), then you'll need to tell us what you did and how it's not working (error message/stacktrace?)

@fletch3555 I have a different form which is used to update the user info. When updating the user avatar i am just confused how to store the image in the default avatar location and remove the old ones.
The code is written below
if($request->hasfile('avatar')){
$file = $request->avatar;
$name = time() . $file->getClientOriginalName();
$file->move('UserImage',$name);
if($user->avatar){
unlink(public_path().$user->avatar);
}
$data['avatar'] = $name;
}
$user->update($data);
return redirect()->back()->with('success','User successfully updated.');
}

@fletch3555 Can you solve my problem ?? I am stuck in this from 3 days??

Closing due to inactivity.
Please ask questions and how-to's in our Slack group.


Displays filename in UI before loading file

This shortens the delay between selecting the .ibf file and seeing it in the Uploader UI.

 <0:ux, 2:dev, 1:tst> [uploader] OmniPod bundle of small tasks

Ping @jebeck for review.

Maybe remove the setting of the filename again in line 567, inside reader.onloadend? Unnecessary now.
Otherwise LGTM, and verified that it improves speed from my OmniPod from 6.9s to negligible. :)

Great! OK, not setting filename twice anymore. Merging.


proposal: Import local package using ./[moduleName]

[this is not a bug report, it's a feature suggestion]
Currently you cannot import go modules in the same folder as another go file.
For example doing this:
import "./myPackage.go"

Causes an error. This would be a great feature for larger-scale applications & libraries.
Thanks for your consideration.

This can be fixed by just using the main package throughout the files of your application.


guess_protocol() falls back to Halfblocks on Windows Terminal (Preview)

Windows Terminal (Preview) supports Sixel as of 1.22 (https://github.com/microsoft/terminal/releases).
When running code inside WSL it does actually display images using Sixel but outside of WSL it falls back to Halfblocks.

Windows Terminal (Preview) without WSL
Windows Terminal (Preview) with WSL

My guess is that the guess_protocol() function is not testing for Sixel support under Windows. Not sure if there is a way to do it yet but would be great if it could be added.

FYI, there is a bug in the latest Windows Terminal preview that affects VT reports in applications that don't enable VT input mode (see https://github.com/microsoft/terminal/issues/17813). It's possible that might be why it's not working outside WSL. VT input mode is set automatically in WSL, but that isn't the case for regular Windows console applications, unless they set the mode themselves, and I don't think the crossterm library does that.

Seems like Sixel is working in Windows Terminal (Preview) even without WSL when you manually cycle through the protocols (like in the demo example).

Just showing some weird behaviour when resizing (not fully clearing the area) but that might be a problem on the Windows Terminal part.

@matthias-buttgereit the weird behaviour is most likely an incorrect font-size, which should now be guessed correctly on WSL on master.

@matthias-buttgereit this should work on master now.


Add min aggregator.

A model PR that shows how to add a new TSDB style aggregator method to scotty.

Perhaps follow up with some documentation about how this works and that it's a good example to follow?

Will do
On Friday, 16 September 2016, rgooch<EMAIL_ADDRESS>wrote:

Merged #144 https://github.com/Symantec/scotty/pull/144.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Symantec/scotty/pull/144#event-792444364, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABrhchorwheZL1nWvy5CxAR1av0aGd9Zks5qqtXhgaJpZM4J_FGA
.


Deprecated message

Hello!
Awesome module! I've noticed the following message coming up in the console every time I mouse over a token. Figured it was something that should be noted.

The same....

Thanks, this shouldn't of caused any actual issues. The newest release (V2.0.0) should be compatible with Foundry VTT v9 if you wish to update.


Completion of error handling

Would you like to add more error handling for return values from functions like the following?

pthread_mutex_init ⇒ xheap::initialize
sigaction ⇒ watchpoint::installWatchpoints

Hi @elfring,
The first one is not an issue - the only way pthread_mutex_init can fail is if you ask for unwindable mutexes.
We probably should check the result of sigaction.
How did you find these issues?
yours,
Bobby

The web search interface by GitHub can also be a tool for static source code analysis to some degree.
I suggest to avoid ignorance of return values a bit more.
Would you like to detect every error situation as early as possible?

How do you think about to improve static source code analysis also for this software?

@elfring Can you either share the analysis you are looking at, or explain in more detail what your question is?

Under which circumstances are you going to care for the remaining unchecked function return values?

@elfring ideally, when I can see the results of a tool showing me that I should care.  So for the case of pthread_mutex_*, can your tool (using static analysis) show me that it is even possible for those return values to be non-zero?
Additionally - can your tool ignore pthread_mutex_* functions, and tell me about other missing return values?  It isn't that I don't care in general - just that I am skeptical about some of the cases you have brought up (although I did add an assert for the sigaction you mentioned above).

It is easy sometimes to find more update candidates while it can be harder to agree on the complete software solution.
On which way would you like to continue?

@elfring:
1 - Please tell us more about the tool you are running.
2 - Please post the full report of your tools output somewhere, for an example, see Coveralls: https://coveralls.io/builds/4446686/source?filename=mdl.c
3 - Allow us to hide false-positives.
4 - Allow us to re-run the tool when we push new commits to GitHub.
That would be 1000x more useful than you running a tool, once, in private, and opening up a trickle of issues related to code you don't understand deeply.  That would turn me into an advocate for your tool!

Some tools should be usable to check calls of functions with a non-void return type. Please choose one for your needs.

@elfring can you please tell us more about the tool you ran on DoubleTake?

I suggest to reuse the following tools for finding more update candidates depending on your preferences for factors like freedom, licence costs and programming language support.

AspectC++
Secure Programming Lint
Coccinelle
Coverity Scan
GitHub

Hi @elfring - are your responses to my questions completely automated?

No. - I admit that I dare to repeat variations of previous answers for recurring issues.


When the language is set to lua and sql, some lua syntax highlighting is invalid.

highlightAuto(code, ['lua', 'sql']).value
Some lua syntax highlighting is invalid.

Closing this issue because no specific examples are provided (when means we couldn't really even look into it even if we wanted to).  Also: Auto-detection is "best effort" only. It won't always be correct, and that's expected.
If you have a PR or specific ideas of how to improve the auto-detection for these two languages we'd love to hear them, but otherwise we can't do much with this type of issue.
If you need 100% correct highlighting in all cases, you need to manually tell Highlight.js the proper language for each block of code as documented in the docs.


Logout command

Add a logout command. This should probably communicate to the original process to kill the X process.

This can be done with Unix sockets:
http://kmdouglass.github.io/posts/a-simple-unix-socket-listener-in-rust/

This is redundant since we can just use systemctl restart lemurs


Make linked lines more obvious

@Olafurw on Slack suggests that the linked assembly is hard to notice for the hover functionality.
And he is right!
We can either:

Change how we highlight the code (Maybe highlight the whole line instead of only the margin?)

Revealing the first line of the linked code would be too distracting, but it's an option nontheless

or...

Display the linked code either on a tooltip or on a custom modal.

The downside of this option would be, as I see it, that it would bloat the view too much

I had this idea: https://github.com/mattgodbolt/compiler-explorer/commit/a1b98b7dfef25f34e3011e4460e039988c9a992a but I don't know if it's a good thing to do. It surely helps, but maybe it leaves the code too unreadeable? Any suggestions on this then?


Request: Support "option_selections" when adding item to cart

duplicate https://github.com/bigcommerce/storefront-data-hooks/issues/2

@ronanmorris I've created a PR for this

It has been solved in #15


fix: displayName is not set for the component of "@yamada-ui/progress"

Closes #2893
Description

Current behavior (updates)

New behavior

Is this a breaking change (Yes/No):

Additional Information

Thank you for your review. I believed I had applied all components of PROGRESS under packages/components/progress/src, but is there still something missing? If I have misunderstood anything, please let me know.

Thank you for your review. I believed I had applied all components of PROGRESS under packages/components/progress/src, but is there still something missing? If I have misunderstood anything, please let me know.

@mei28

Shape
Circle
CircleProgressLabel
ProgressFilledTrack

These are also components.

I have added the remaining components.
However, I failed the Prettier check in CI. Could you please help me understand how to resolve it?


Add sorting in order.

I' like order to have the same the member sort rule that sort-imports have.
import {hashHistory} from 'react-router';
import {syncHistoryWithStore} from 'react-router-redux';

VS
import {syncHistoryWithStore} from 'react-router-redux';
import {hashHistory} from 'react-router'; // error

Duplicate of #389; fix pending #629

Closing as a duplicate of #389.


fix: fixes reversed decay rate

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Azure Service Bus Topic/Subscription in React App

I am using service bus with Topic/Subscription with the following sample in React.
https://github.com/Azure/azure-sdk-for-js/blob/master/sdk/servicebus/service-bus/samples/javascript/gettingStarted/receiveMessagesStreaming.js
Can I listen service bus subscription with socket by using only this library in React or should I use socket.io kind of dependencies?
I do get the following errors when I utilize the "useEffect" loop in React.
Error occurred:  OperationTimeoutError: Unable to create the amqp sender 06453daa-e5ef-f84d-92ab-0343d31bad7c due to operation timeout.
ws.js:78 WebSocket connection to 'wss://apm-dev-notify.servicebus.windows.net/$servicebus/websocket' failed: Error in connection establishment: net::ERR_NETWORK_IO_SUSPENDED
Error occurred:  ServiceCommunicationError: Websocket connection failed.
ws.js:46 WebSocket is already in CLOSING or CLOSED state.
Uncaught (in promise) Error: Unable to close the amqp connection "connection-30" due to operation timeout.
at connection.js:225

Thanks for reporting @askeroglu
Can you share a small sample app where we can try and replicate this issue?

I have App.js and Receive.js in React. This code mimics what I am trying to do
import React, { useEffect, useState, useRef } from "react"
import {
Route,
Switch,
Redirect
} from "react-router-dom"
// Service Bus
import recieveServiceBusMessages from './serviceBus/recieve'
function App(props) {
const [ notificationsState, setNotificationsState ] = useState([])
// userId from Redux
const { userId } = props
// Listen to notifications from ServiceBus
useEffect(() => {
async function tryRecieveMessages() {
if(userId !== null) {
const NotificationRecieved = await recieveServiceBusMessages(userId)
setNotificationsState(NotificationRecieved)
if(NotificationRecieved.length > 0) {
dispatchRef.current(storeUserNotifications(NotificationRecieved))
}
}
}
// This is the listener for SB Notifications
if(notificationsState) {
tryRecieveMessages()
}
// console.count('I am service bus')
}, [userId, notificationsState])
return (

{/* // Routing Logic */}

)
}
export default App
Receive.js
============================================
const { ServiceBusClient, ReceiveMode, delay } = require("@azure/service-bus");
const connectionString = process.env.REACT_APP_SERVICE_BUS;
// Name of the event hub. For example: myeventhub
const topicName = "users";
const recieveServiceBusMessages = async (userId) => {
let notifications = []
const sbClient = ServiceBusClient.createFromConnectionString(connectionString);
const subscription = sbClient.createSubscriptionClient(topicName, userId)
.createReceiver(ReceiveMode.peakLock)
const onMessageHandler = async (brokeredMessage) => {
console.log(Received message: ${brokeredMessage.body});
notifications.push(brokeredMessage.body)
await brokeredMessage.complete();
};
const onErrorHandler = (err) => {
console.log("Error occurred: ", err);
};
try {
subscription.registerMessageHandler(onMessageHandler, onErrorHandler, { autoComplete: false })
await delay(3000);
await subscription.close();
}
finally {
await sbClient.close();
}
return notifications
}
export default recieveServiceBusMessages

@askeroglu
Do you see the OperationTimeoutError every time you attempt to get messages, or are you able to receive some?
I tried reproducing by creating a new app with create-react-app and doing something similar to what you do:
App.js
import React, { useEffect } from 'react';
import logo from './logo.svg';
import './App.css';
import { receiveMessages } from './receive';

function App() {
  return (

        <Test />

          Edit src/App.js and save to reload.

          Learn React

  );
}

function Test(props) {

  useEffect(() => {
    (async () => {
      const notifications = await receiveMessages();
      console.log(notifications);
    })();
  }, []);

  return (

      Test component.

  )
}

export default App;

receive.js
const { ServiceBusClient, ReceiveMode } = require('@azure/service-bus');

const connectionString = "CONNECTION-STRING";
const topic = 'TOPIC';
const subscriptionName = 'SUBSCRIPTION';

export async function receiveMessages() {
  const notifications = [];

  const client = ServiceBusClient.createFromConnectionString(connectionString);
  const subscription = client.createSubscriptionClient(topic, subscriptionName);
  const receiver = subscription.createReceiver(ReceiveMode.peekLock);

  const messageHandler = async (brokeredMessage) => {
    console.log(`Received message: ${brokeredMessage.body}`);
    notifications.push(brokeredMessage.body);
    await brokeredMessage.complete();
  };

  const onErrorHandler = (err) => {
    console.log(`Error occurred: `, err);
  };

  try {
    receiver.registerMessageHandler(messageHandler, onErrorHandler, {autoComplete: false});
    await new Promise(r => setTimeout(r, 3000));
    await receiver.close();
  } finally {
    await client.close();
  }
  return notifications;
}

With this code I receive the messages after the 3 second timeout. Can you share how often your useEffects method is being triggered?  I'm wondering if maybe it's causing an issue with trying to create too many connections at once.

@askeroglu We have to close this issue as we havent heard back from you on this issue. If you continue to see this issue, please drop in a comment and we can re-open the issue for further investigation.


Fix causal impact calculation error in synthetic control and interrupted time series

Closes #294
Also re-ran the affected notebooks
Only need one review, but I tagged a few people because this fixes a consequential bug

I'll cut a point release when this is merged.


Broken on Mac OS X 12.6.6

I get the following error when cmake tries to configure via VSCode:
[main] Configuring project: pirack
[proc] Executing command: /usr/local/bin/cmake --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE:STRING=/Users/feral/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-g++ -S/Users/feral/Projects/DIY/pico/pirack -B/Users/feral/Projects/DIY/pico/pirack/build -G Ninja
[cmake] PICO_SDK_PATH is /Users/feral/Projects/DIY/pico/LIBRARIES/pico-sdk
[cmake] Not searching for unused variables given on the command line.
[cmake] PICO platform is rp2040.
[cmake] -- The CXX compiler identification is GNU 10.3.1
[cmake] -- The C compiler identification is GNU 10.3.1
[cmake] -- The ASM compiler identification is GNU
[cmake] -- Found assembler: /usr/local/bin/arm-none-eabi-gcc
[cmake] -- Checking whether CXX compiler has -isysroot
[cmake] -- Checking whether CXX compiler has -isysroot - yes
[cmake] -- Checking whether CXX compiler supports OSX deployment target flag
[cmake] -- Checking whether CXX compiler supports OSX deployment target flag - no
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - failed
[cmake] -- Check for working CXX compiler: /usr/local/bin/arm-none-eabi-g++
[cmake] -- Check for working CXX compiler: /usr/local/bin/arm-none-eabi-g++ - broken
[cmake] CMake Error at /usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/CMakeTestCXXCompiler.cmake:60 (message):
[cmake]   The C++ compiler
[cmake]
[cmake]     "/usr/local/bin/arm-none-eabi-g++"
[cmake]
[cmake]   is not able to compile a simple test program.
[cmake]
[cmake]   It fails with the following output:
[cmake]
[cmake]     Change Dir: /Users/feral/Projects/DIY/pico/pirack/build/CMakeFiles/CMakeScratch/TryCompile-MEMGpa
[cmake]
[cmake]     Run Build Command(s):/usr/local/bin/ninja -v cmTC_90f11 && [1/2] /usr/local/bin/arm-none-eabi-g++   -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -o CMakeFiles/cmTC_90f11.dir/testCXXCompiler.cxx.o -c /Users/feral/Projects/DIY/pico/pirack/build/CMakeFiles/CMakeScratch/TryCompile-MEMGpa/testCXXCompiler.cxx
[cmake]     [2/2] : && /usr/local/bin/arm-none-eabi-g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/opt/opencv@2/lib CMakeFiles/cmTC_90f11.dir/testCXXCompiler.cxx.o -o cmTC_90f11   && :
[cmake]     FAILED: cmTC_90f11
[cmake]     : && /usr/local/bin/arm-none-eabi-g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/opt/opencv@2/lib CMakeFiles/cmTC_90f11.dir/testCXXCompiler.cxx.o -o cmTC_90f11   && :
[cmake]     /usr/local/Cellar/arm-none-eabi-gcc/10.3-2021.07/gcc/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: Error: unable to disambiguate: -search_paths_first (did you mean --search_paths_first ?)
[cmake]     collect2: error: ld returned 1 exit status
[cmake]     ninja: build stopped: subcommand failed.
[cmake]
[cmake]
[cmake]
[cmake]
[cmake]
[cmake]   CMake will not be able to correctly generate this project.
[cmake] Call Stack (most recent call first):
[cmake]   CMakeLists.txt:9 (project)
[cmake]
[cmake]
[cmake] -- Configuring incomplete, errors occurred!
[proc] The command: /usr/local/bin/cmake --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE:STRING=/Users/feral/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-g++ -S/Users/feral/Projects/DIY/pico/pirack -B/Users/feral/Projects/DIY/pico/pirack/build -G Ninja exited with code: 1

Is this on an Intel Mac or a Apple Silicon Mac? Have you followed the instructions in section 9.1 of https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf ?

Intel Mac, I just upgraded to Ventura 13.4 and the issue persists. Yes, I've got arm-none-eabi-gcc installed via homebrew.

first thing, try deleteing your build directory if you have upgraded macOS

also -DCMAKE_TOOLCHAIN_FILE:STRING=/Users/feral/vcpkg/scripts/buildsystems/vcpkg.cmake looks suspicious
anyways, better discussed on the forums https://forums.raspberrypi.com/viewforum.php?f=143