Count run action finish to call final finish when two run actions are…

Describe your changes
Hi,
After migrating from Cocos2d, I discovered that transition animations were not working properly, like TransitionSlideInB for example. The slide made was going more than the max it should.
After digging into this and compare with Cocos2d; I found out that the the inScene/outScene run actions were done in the opposite order leading to override the position.
When there is 2 run actions performed in parallel, the order should not matter (maybe that why there is a warning about issues at top of the files by Cocos2d authors)
This is my proposal to fix this issue: call the finish only when both actions are done.

Instead of hardcoding _finishedRunActionCount == 2 and having two finishing methods, I think a better design would be to:

Remove addFinish() to leave a single finish().
Add int _waitForFinishCount = 1; field and setWaitForFinishCount(int count).
Before running the actions call setWaitForFinishCount(2) if required.
Decrement _waitForFinishCount in finish() until it reaches 0 to trigger the finish logic.

both in scene and out scene actions are done on the same single thread right? but not in sequential order? or different idle threads pick up and execute those actions?

both in scene and out scene actions are done on the same single thread right? but not in sequential order? or different idle threads might pick up and execute those actions?

Scene transitions simply use actions, and they run on the main thread, so no multi-threading involved.

both in scene and out scene actions are done on the same single thread right? but not in sequential order? or different idle threads might pick up and execute those actions?

Scene transitions simply use actions, and they run on the main thread, so no multi-threading involved.

So they should be executed sequentially right?

both in scene and out scene actions are done on the same single thread right? but not in sequential order? or different idle threads might pick up and execute those actions?

Scene transitions simply use actions, and they run on the main thread, so no multi-threading involved.

So they should be executed sequentially right?

I’m not sure how the transitions are stacked and processed but somehow the outScene one was done before the inScene one, leading to position override.

Instead of hardcoding _finishedRunActionCount == 2 and having two finishing methods, I think a better design would be to:

Remove addFinish() to leave a single finish().
Add int _waitForFinishCount = 1; field and setWaitForFinishCount(int count).
Before running the actions call setWaitForFinishCount(2) if required.
Decrement _waitForFinishCount in finish() until it reaches 0 to trigger the finish logic.

I thought about adding a method like setWaitForFinishCount(int count) but in fact 2 is also hard coded. In fact we will always call your method with 2 as parameters, so maybe setWaitForTwoFinishCount() or similar and set _waitForFinishCount = 2;` in

I’m not sure how the transitions are stacked and processed but somehow the outScene one was done before the inScene one, leading to position override. It’s strange no one saw this issue before 🤔

hmm weird those actions are stored in ax::Vector which uses std::vector under the hood, in scene and out scene both should be part of the same node too, weird can u provide some simplified example how you're using the Transition*(s)?

I’m not sure how the transitions are stacked and processed but somehow the outScene one was done before the inScene one, leading to position override. It’s strange no one saw this issue before 🤔

hmm weird those actions are stored in ax::Vector which uses std::vector under the hood, in scene and out scene both should be part of the same node too, weird can u provide some simplified example how you're using the Transition*(s)?

Yeah it’s strange

I’m not sure how the transitions are stacked and processed but somehow the outScene one was done before the inScene one, leading to position override. It’s strange no one saw this issue before 🤔

hmm weird those actions are stored in ax::Vector which uses std::vector under the hood, in scene and out scene both should be part of the same node too, weird can u provide some simplified example how you're using the Transition*(s)?

Yeah the finish was called by the outScene action because it is/was supposed to be the last of the 2 actions called (for all transitions kind) but it’s not the case anymore compared to Cocos2dx, and I don’t know the reason.
my code is quite simple, being in the MainScene, I just create a GameScene (subclass of ax::Scene) and pushing it using a TransitionSlideInB
GameScene *scene = GameScene::create();
scene->loadLevel(last);
Director::getInstance()->pushScene(ax::TransitionSlideInB::create(0.3f, scene));

I thought about adding a method like setWaitForFinishCount(int count) but in fact 2 is also hard coded. In fact we will always call your method with 2 as parameters, so maybe setWaitForTwoFinish() or similar and set _waitForFinishCount = 2; in

It would be not hardcoded, but parameterized, generalizing the logic and allowing users to specify the finish() call count. With addFinish() and finish() you're splitting the logic into two separate paths, while setWaitForFinishCount() keeps the logic same for all cases.

So they should be executed sequentially right?

I think I understand where you're coming from, but that's not quite how it works.  As mentioned earlier, scene transitions use actions.  Multiple actions can run at the same time, in parallel, but not in the scene of being parallel threaded, but rather in that they are executing within the same update loop.
In the case of scene transitions, whatever operation is being applied to the in and out scenes are happening in parallel, and the scene visit() method is called on both in and out scenes to just render them to the screen.
If you want to learn more about how actions work, then browse through the Action.cpp/ActionInterval.cpp etc..

When there is 2 run actions performed in parallel, the order should not matter (maybe that why there is a warning about issues at top of the files by Cocos2d authors)

What warning are you referring to?

Just FYI, the reason this scene transition bug has appeared in Axmol is because of a few reasons:
1 - ActionManager was updated in Axmol to use a std::unordered_map to store the nodes, so now the order is based on the hash value, and not based on the insertion order (which I assume is how it was working previously). You can see the change here: https://github.com/axmolengine/axmol/commit/c2847f892ec29249ad42a4845b64b3314ae59a24
2 - The scene transition implementations were never correct to begin with, and the only reason they worked in Cocos2d-x was purely by chance.  When running actions on two separate nodes, there is no way to sync those actions, and if the final result is dependent on unrelated node action sequences, then there needs to be some mechanism in place to detect that, which is what this PR is addressing.

What warning are you referring to?

This comment in Transaction.cpp, about the "other issue". I think they faced what we encountered but never discovered why.
//
// SlideInL
//

// The adjust factor is needed to prevent issue #442
// One solution is to use DONT_RENDER_IN_SUBPIXELS images, but NO
// The other issue is that in some transitions (and I don't know why)
// the order should be reversed (In in top of Out or vice-versa).

The actions applied on the scenes end at a specific duration, and since the order of completion is causing an issue, a possible alternative fix would bet to add a DelayTime action of 0 duration to the action sequence that is responsible for calling the finish() method. In the case of TransitionSlideInB, it would force the out scene to finish on the next update, after both the in scene and out scene primary actions are complete. This is assuming both primary actions applied to the in and out scenes are exactly the same duration (which should be the case on all such transitions).

Adding a 0 delay is not the best to me as it would mean -as you said- that it would trigger at next update, so the transition delay would not be exactly what the user asked for.

Just FYI, the reason this scene transition bug has appeared in Axmol is because of a few reasons:
1 - ActionManager was updated in Axmol to use a std::unordered_map to store the nodes, so now the order is based on the hash value, and not based on the insertion order (which I assume is how it was working previously). You can see the change here: c2847f8 2 - The scene transition implementations were never correct to begin with, and the only reason they worked in Cocos2d-x was purely by chance. When running actions on two separate nodes, there is no way to sync those actions, and if the final result is dependent on unrelated node action sequences, then there needs to be some mechanism in place to detect that, which is what this PR is addressing.

Yeah it sounded like that when I looked at how it was done, the issue was already there but it worked by chance. The unordered map explains the order, thanks for info!
BTW i updated the PR to have the setWaitForFinishCount()

Just FYI, the reason this scene transition bug has appeared in Axmol is because of a few reasons:
1 - ActionManager was updated in Axmol to use a std::unordered_map to store the nodes, so now the order is based on the hash value, and not based on the insertion order (which I assume is how it was working previously). You can see the change here: c2847f8 2 - The scene transition implementations were never correct to begin with, and the only reason they worked in Cocos2d-x was purely by chance. When running actions on two separate nodes, there is no way to sync those actions, and if the final result is dependent on unrelated node action sequences, then there needs to be some mechanism in place to detect that, which is what this PR is addressing.

ah right now makes sense why for some reason i thought the in scene and out scene would be part of the same node

Just FYI, the reason this scene transition bug has appeared in Axmol is because of a few reasons:
1 - ActionManager was updated in Axmol to use a std::unordered_map to store the nodes, so now the order is based on the hash value, and not based on the insertion order (which I assume is how it was working previously). You can see the change here: c2847f8 2 - The scene transition implementations were never correct to begin with, and the only reason they worked in Cocos2d-x was purely by chance. When running actions on two separate nodes, there is no way to sync those actions, and if the final result is dependent on unrelated node action sequences, then there needs to be some mechanism in place to detect that, which is what this PR is addressing.

ah right now makes sense why for some reason i thought the in scene and out scene would be part of the same node. may be we somehow tell the ActionManager to treat them as part of the same node?

A more useful element would be to add a new object something like ParallelActions which would be an action running several actions (which could be sequences) and then run a final action (which can be a callback) when the previous actions are all done

may be we somehow tell the ActionManager to treat them as part of the same node?

That is not possible, and it wouldn't make sense since the actions are in fact not actually operating on the same node.  This really has nothing to do with the ActionManager.

A more useful element would be to add a new object something like ParallelActions which would be an action running several actions (which could be sequences) and then run a final action (which can be a callback) when the previous actions are all done

From what I have seen in the action system, it is not easily adaptable to support this.  If you go through the different types of actions, especially ones inheriting from FiniteTimeAction, and how action sequences actually work, then you will see why.

may be we somehow tell the ActionManager to treat them as part of the same node?

That is not possible, and it wouldn't make sense since the actions are in fact not actually operating on the same node. This really has nothing to do with the ActionManager.

hmm so i guess the whole Transition system should really introduce some sort of state system, it might be even make life easy to implement newer sequence action dependant Transition types, and it makes sense to have each Transition to save their current state too.

hmm so i guess the whole Transition system should really introduce some sort of state system

That's exactly what _waitForFinishCount is for. I don't think any more complicated systems are necessary, and they would just complicate things instead of solving real problems.
That being said, if there was WaitForAction action which waits for another action's completion, then transitions could be refactored to use that instead of _waitForFinishCount. That would also open up some other possibilities.

That's exactly what _waitForFinishCount is for. I don't think any more complicated systems are necessary, and they would just complicate things instead of solving real problems.
That being said, if there was WaitForAction action which waits for another action's completion, then transitions could be refactored to use that instead of _waitForFinishCount. That would also open up some other possibilities.

I guess it just makes sense for current situation, and waiting for 2 actions kinda feels arbitary, doesn't feel like a general solution, it doesn't answer what type of action we're waiting for to be finished, what if some other unexpected actions finishes after calling setWaitForFinishCount(2) if we just want to fix the "out scene" getting finished first before "in scene" then we could just hard code it some other way without introducing general function like setWaitForFinishCount, I am just saying instead of waiting for 2 tasks kinda really feels hard coded solution but yet it's trying to be a general type of solution.

That's exactly what _waitForFinishCount is for. I don't think any more complicated systems are necessary, and they would just complicate things instead of solving real problems.
That being said, if there was WaitForAction action which waits for another action's completion, then transitions could be refactored to use that instead of _waitForFinishCount. That would also open up some other possibilities.

I guess it just makes sense for current situation, and waiting for 2 actions kinda feels arbitary, doesn't feel like a general solution, it doesn't answer what type of action we're waiting for to be finished, what if some other unexpected actions finishes after calling setWaitForFinishCount(2) (even tho nothing else seems to be calling Tansition::finish). so, if we just want to fix the "out scene" getting finished first before "in scene" situation then we could just hard code it some other way without introducing functions like setWaitForFinishCount, I am just saying waiting for 2 tasks/actions kinda really feels hard coded solution/solution of a specific problem, but yet it's trying to be a general type of solution.

It is not arbitrary: each transition can override the value to set up the necessary one

I am just saying waiting for 2 tasks/actions kinda really feels hard coded solution/solution of a specific problem, but yet it's trying to be a general type of solution.

I agree. I just disagreed that the solution should be to complicate the transition system itself by adding specialized synchronization system to it. So my proposal was to extend the existing action system by introducing an action that can wait for other action completion. This solution would allow to synchronize actions on different nodes.

Another solution would be to create a special CallFunc Action that will be added to both sequences and that will manage the count

I think WaitForAction would be more flexible, because it's an action and composes easily, something like:
Sequence::create(
    SomeAction::create(),
    WaitForAction::create(actionOnAnotherNode1, actionOnAnotherNode2, ...);
    SomeOtherAction::create()
);

With a CallFunc like thing you'd have to do this inside its callback.

Another solution would be to create a special CallFunc Action that will be added to both sequences and that will manage the count

I believe the current solution provided by @AlexandreK38 does that, it calls the "special" version of the finish function at the end of both in and out scene actions to maintain the "count"

It is not arbitrary: each transition can override the value to set up the necessary one

The 2 is just a lucky number here, that only two node(s) will call the finisth function which maintains the count by chance, this is probably alright for most of the Transition but assuming that only 2 or 3 number of actions will run is not a good solution, at least you should be able to detect or choose which actions were ran

I am just saying waiting for 2 tasks/actions kinda really feels hard coded solution/solution of a specific problem, but yet it's trying to be a general type of solution.

I agree. I just disagreed that the solution should be to complicate the transition system itself by adding specialized synchronization system to it. So my proposal was to extend the existing action system by introducing an action that can wait for other action completion. This solution would allow to synchronize actions on different nodes.

Another solution would be to create a special CallFunc Action that will be added to both sequences and that will manage the count

I think WaitForAction would be more flexible, because it's an action and composes easily, something like:
Sequence::create(
    SomeAction::create(),
    WaitForAction::create(actionOnAnotherNode1, actionOnAnotherNode2, ...);
    SomeOtherAction::create()
);

With a CallFunc like thing you'd have to do this inside its callback. Also it would require inserting something into the action list and it would not work in situations when you can only get a pointer to an action like calling some Action* getSomeAction() method.

Ye that will be also a good solution overall and by adding some state to Transition i meant usually when you think about Transition, it should have an update function which should first check if State1(may be moving to x, y position) is finished if not do that task and save State1 finished then continue with State2(which may be decreases opacity over time) if State1 is finished. I didn't check how axmol/cocos2dx manges this kind state of each transition, but it appears they kind of don't and instead these states are converted into actions and the ActionManager kind of works as the state manager. But I think this action approach kind of makes easier to implement different kinds of Transition without writing huge if/else/switch block, but then again it suffers from some overhead execution and the syncronization issue too.

I guess it just makes sense for current situation, and waiting for 2 actions kinda feels arbitary, doesn't feel like a general solution, it doesn't answer what type of action we're waiting for to be finished, what if some other unexpected actions finishes after calling setWaitForFinishCount(2) (even tho nothing else seems to be calling Tansition::finish). so, if we just want to fix the "out scene" getting finished first before "in scene" situation then we could just hard code it some other way without introducing functions like setWaitForFinishCount, I am just saying waiting for 2 tasks/actions kinda really feels hard coded solution/solution of a specific problem, but yet it's trying to be a general type of solution.

Just to clarify a few things. Firstly, there is nothing arbitrary about waiting for 2 unconnected actions (action sequences) to finish, because in the case of scene transitions, there are 2 scenes that each have their own actions applied.  There can be no more than 2 scenes.
Now, transitions have nothing to do with actions per se.  A transition is not an action, it just uses an action.
For a lack of a better way to describe this, imagine 2 racing cars that are heading towards a finish line.  A celebration even does not start until both cars have crossed the finish line.  Those cars not in any way connected to each other, and each has its own action, being to move towards the finish line.  There is only one way to determine that both cars have crossed the finish line, and that is by an external observer, not connected to the cars in any way.  The racing car itself is not an action, the movement is, and one racing car crossing the finish line has nothing to do with another car crossing it, or what external event happens after they both cross.
Does that make sense?

I think WaitForAction would be more flexible, because it's an action and composes easily, something like:
Sequence::create(
    SomeAction::create(),
    WaitForAction::create(actionOnAnotherNode1, actionOnAnotherNode2, ...);
    SomeOtherAction::create()
);

With a CallFunc like thing you'd have to do this inside its callback. Also it would require inserting something into the action list and it would not work in situations when you can only get a pointer to an action like calling some Action* getSomeAction() method.

I strongly feel that everyone involved in this thread, and unfamiliar with the implementation of Action and sub-classes (particularly Sequence and FiniteTimeAction), should go through the code if you haven't already done so.
What is being suggested is not possible in the Sequence action, because it is not implemented how you may think it is; I had the wrong idea about it too until I went through the implementation to see how it was done, because I needed functionality somewhat similar to this quite a while back.

Just to clarify a few things. Firstly, there is nothing arbitrary about waiting for 2 unconnected actions (or action sequences) to finish, because in the case of scene transitions, there are only 2 scenes that each have their own actions applied. There can be no more than 2 scenes. These scenes are not connected in any way, and neither are there actions.
Now, transitions have nothing to do with actions per se. A transition is not an action, it just uses an action.
For a lack of a better way to describe this, imagine 2 racing cars that are heading towards a finish line. A celebration even does not start until both cars have crossed the finish line. Those cars not in any way connected to each other, and each has its own action, being to move towards the finish line. There is only one way to determine that both cars have crossed the finish line, and that is by an external observer, not connected to the cars in any way. The racing car itself is not an action, the movement is, and one racing car crossing the finish line has nothing to do with another car crossing it, or what external event happens after they both cross.
Does that make sense?

i get it why it 2 is the number, it makes sense only through these discussion, i am saying the code isn't self explenatory we should make comments for future users or may be we could just do something else like:
// Transition.h
// private enum class
enum FinishingScenes {
    None,
    InScene,
    OutScene,
    Other
}
FinishingScenes _lastFinishedScene;

// Transition.cpp
void finish(FinishingScenes currentFinishing = FinishingScenes::Other)
{
    if (_lastFinishedScene == FinishingScenes::InScene || _lastFinishedScene == FinishingScenes::OutScene)
    {
        // cleanup
    }
    _lastFinishedScene = currentFinishing;
}

//child transitions
_outScene->runAction(
        Sequence::create(/* custom params */, CallFunc::create(AX_CALLBACK_1(TransitionScene::finish, this, FinishingScenes::OutScene)), nullptr));
_inScene->runAction(
        Sequence::create(/* custom params */, CallFunc::create(AX_CALLBACK_1(TransitionScene::finish, this, FinishingScenes::InScene)), nullptr));

i am just saying if we only care about current situation where the finish function will only be called by two actions, then setWaitForFinishCount(2) feels unncessary

What is being suggested is not possible in the Sequence action, because it is not implemented how you may think it is

Oh right, I totally forgot that. :(

@AlexandreK38 Is this PR complete?

Not OP, but I think it is ready to be merged.
@IamSanjid: your example does not work, because finish() must detect when all relevant actions are complete, and not just one of in/out scene's.

@rh101 for me it is complete 🙏
At first IamSanjid idea may be better to explain what we do, but adding the scene param (and for example null when we don’t need to wait for several actions to finish or an enum using bitwise for flags and a setter similar to the setWaitFinishCount) isn’t simplifying what we do now

At first IamSanjid idea may be better to explain what we do, but adding the scene param (and for example null when we don’t need to wait for several actions to finish or an enum using bitwise for flags and a setter similar to the setWaitFinishCount) isn’t simplifying what we do now

The current changes in the PR are all that is required to fix the issue, and there is no need to over-engineer it, as the implementation is both simple and very clear as to its purpose.

@IamSanjid: your example does not work, because finish() must detect when all relevant actions are complete, and not just one of in/out scene's. So you either need a counter, or some kind of flags for each finish signal.

if the actions are executed sequentially,
say _outScene actions gets finished first then calls finish
_lastFinishedScene is default set to FinishingScenes::None  so the cleanup block never reaches,
_lastFinishedScene gets set to FinishingScenes::OutScene,
Now _inScene actions gets finished then calls finish this time cleanup block should reach

At first IamSanjid idea may be better to explain what we do, but adding the scene param (and for example null when we don’t need to wait for several actions to finish or an enum using bitwise for flags and a setter similar to the setWaitFinishCount) isn’t simplifying what we do now

i think it's fine no need to redo something unncessary it's just i think nothing else will be using setWaitFinishCount so moving state check directly inside of finish just made more sense to me otherwise my whole idea is really just based of your idea, just gave those 2,1 numbers some names xD

if the actions are executed sequentially,
say _outScene actions gets finished first then calls finish
_lastFinishedScene is default set to FinishingScenes::None so the cleanup block never reaches,
_lastFinishedScene gets set to FinishingScenes::OutScene,
Now _inScene actions gets finished then calls finish this time cleanup block should reach

That is not correct, and there seems to be some misunderstanding regarding how the scene transitions work.
There are 2 separate nodes, each with their own actions applied.  If you read through the code, you will quickly see that the actions are applied to the nodes at the same time, so the actions are running at the same time.  They actions on one node are in no way linked to the actions of the other node.
The finish condition is when the actions on both nodes are complete.  The problem, and the initial reason for this PR by the OP, is that there is no way to control the order of the completion of the actions, and there is no way for the order of completion to be determined.

if the actions are executed sequentially,
say _outScene actions gets finished first then calls finish
_lastFinishedScene is default set to FinishingScenes::None so the cleanup block never reaches,
_lastFinishedScene gets set to FinishingScenes::OutScene,
Now _inScene actions gets finished then calls finish this time cleanup block should reach

That is not correct, and there seems to be some misunderstanding regarding how the scene transitions work.
There are 2 separate nodes, each with their own actions applied. If you read through the code, you will quickly see that the actions are applied to the nodes at the same time, so the actions are running at the same time. They actions on one node are in no way linked to the actions of the other node. The order of actions is in not sequential between the 2 nodes (in and out scenes).
The finish condition is when the actions on both nodes are complete. The problem, and the initial reason for this PR by the OP, is that there is no way to control the order of completion of the actions, and there is no way for the order of completion to be determined. All that can be done is for the end of each action to somehow flag that it is complete, and once both are complete, then the finish condition is met. There is absolutely nothing wrong or confusing about the implementation made in this PR; it's quite literally a simple counter to track the completion of the transition sequence, and quite frankly, I do not see how it can be any simpler than that.

I don't get it what my example is doing wrong part? actions are executed simultaneously but not by different thread, my example doesn't care about order, it doesn't matter whether out scene first calls the finish function or in scene, it's always checks if the _lastFinishedScene is whether set to OutScene or InScene variant, when finish is first called by any of "in scene" or "out scene" Sequence the intial value _lastFinishedScene is always set to Other variant so the first finish always should ignore it's first call.

I don't get it what my example is doing wrong part? actions are executed simultaneously but not by different thread, my example doesn't care about order, it doesn't matter whether out scene first calls the finish function or in scene, it's always checks if the _lastFinishedScene is whether set to OutScene or InScene variant, when finish is first called by any of "in scene" or "out scene" Sequence the intial value _lastFinishedScene is always set to Other variant so the first finish always should ignore it's first call.

Sorry, you're correct, I went through the code sample you provided again, and now I understand what it is doing.  Yes, that would work, but, and this is just my opinion, it is not a simpler solution, nor is it easier to understand, than the solution implemented in this PR.

I don't get it what my example is doing wrong part? actions are executed simultaneously but not by different thread, my example doesn't care about order, it doesn't matter whether out scene first calls the finish function or in scene, it's always checks if the _lastFinishedScene is whether set to OutScene or InScene variant, when finish is first called by any of "in scene" or "out scene" Sequence the intial value _lastFinishedScene is always set to Other variant so the first finish always should ignore it's first call.

Sorry, you're correct, I went through the code sample you provided again, and now I understand what it is doing. Yes, that would work, but, and this is just my opinion, it is not a simpler solution, nor is it easier to understand, than the solution implemented in this PR.

yeah the first misunderstanding by both @smilediver and you made it clear it's really not, i don't know i just like to write code in more verbose way i guess, whenever i see something like setWaitForFinishCount(2) it's just feels like why the 2 shouldn't we be declaring what here 2 really means that's kind of stuff but may be that's just me.

@rh101 for me it is complete 🙏
At first IamSanjid idea may be better to explain what we do, but adding the scene param (and for example null when we don’t need to wait for several actions to finish or an enum using bitwise for flags and a setter similar to the setWaitFinishCount) isn’t simplifying what we do now

btw for the null part just asking a question for future AX_CALLBACK_* macros automatically works with default arguments of a function right? so if finish had default value of it's argument we could still use it like AX_CALLBACK_0(TransitionScene::finish, this) right? or it won't going to work as if AX_CALLBACK_* are not aware of default function arguments?

@rh101 for me it is complete 🙏
At first IamSanjid idea may be better to explain what we do, but adding the scene param (and for example null when we don’t need to wait for several actions to finish or an enum using bitwise for flags and a setter similar to the setWaitFinishCount) isn’t simplifying what we do now

btw about the null part just asking a question for future, do AX_CALLBACK_* macros automatically works with default arguments of a function right? so if finish had default value of it's argument we could still use it like AX_CALLBACK_0(TransitionScene::finish, this) right? or it won't going to work as if AX_CALLBACK_* are not aware of default function arguments? okay, this is getting too long and not worth anymore hope this gets merged after the answer peace.

I never tried tbh, but we could give nullptr as param anyway. That was just an idea, I’m not gonna do this 🙂
About having many setWaitForFinishCount(2) we could replace by waitForSeveralFinishRequired() and set the count to 2 in the method as it’s always 2.

About having many setWaitForFinishCount(2) we could replace by waitForSeveralFinishRequired() and set the count to 2 in the method as it’s always 2.

That is not always the case.  It can be 1 as well, such as for TransitionPageTurn.

I think we're getting too fixated on this issue. We all agree that the fix could be improved with the right tools, but the tools are not available right now and current fix is ok. Let's just merge it. :)

About having many setWaitForFinishCount(2) we could replace by waitForSeveralFinishRequired() and set the count to 2 in the method as it’s always 2.

That is not always the case. It can be 1 as well, such as for TransitionPageTurn.
EDIT: Never-mind, I see that _waitForFinishCount is initialized to 1, so the only time a method like setWaitForFinishCount(2) or waitForSeveralFinishRequired() would be called is if there are 2 scenes with actions. I propose that you leave it as is, with setWaitForFinishCount(), since it's very clear as to its purpose.

Yeah let’s merge then 👍

Huh, our custom scene transition class that we wrote for our game inherits from axmol::TransitionScene, but we've never run into this issue with ordering (or if we have the issues have been so minor that we never noticed anything wrong).
Though now that I'm looking at the code I can see why. We only ever use a single action for the custom TransitionScene class itself, as well as a Spine Skeleton with some animations.

@halx99 sorry but did you forget to merge?


docs: update install code for MacOS

Update docs as this can now be installed with brew install hoverfly by https://github.com/Homebrew/homebrew-core/pull/136714 .
Created PR without creating an issue because of the minor changes.

You might want to revisit this. That new brew formula doesn't appear to make the hoverctl utility available, which is at odds with the rest of the hoverfly documentation.

@aejay that's unfortunate, I will revert this doc update until the official brew formula is fixed.


let custom properties pass

This is in response to Bonobos' request to allow us to let custom properties pass for Completed Order events because right now we are whitelisting properties.
I've done end to end testing and confirmed with Klaviyo UI that data shows up properly and also got green light from their engineer.
Updated timestamps of tests as well and some credentials that helped me with the end to end testing.
@segment-integrations/core
TODO:

[x] get client side PR ready

LGTM!


Begin constructing V1 of website

@PhillipChaffee
This is an example of what the games page might look like.
There should be a directive for the games. I expect you'll have a service call our api and ask it to return a game list. With the game list you would render out a screenshot or a quick clip of gameplay (whatever we decide to return to the call). Then, when the user's mouse enters a game, a blue screen should fade over the clip and display the game's name and a short description.

Verison 1 is just going to conatin the working ui router, game, and some styling.

Finished with commit b3f6f5c17a44b08f2723effd539d125db420b544


Cache charmcraft pack container, skip unstable tests except on schedule

Ported from https://github.com/canonical/mysql-k8s-operator/pull/146

@marceloneppel Are the CI test failures expected?

Looks to me that we are pulling an old revision for the tls-certificates-operator and setting its series to focal. Looking at its charmhub page, it has a stable channel now and has switched to jammy.

@marceloneppel Are the CI test failures expected?

Thanks to Dragomir finding the errors were fixed. I'm still checking the instability in the bundle test job.


Added some setup instructions

This repo is great for us Python users! I just added some basic setup instructions to hopefully reduce the barrier for people to adopt this.
Thanks so much for making it!

I'd mention that it's a good idea to install it into a virtualenv.

Sure thing. I'll add instructions for that and resubmit.

Hey, no need to close it - simply amend your commit and force-push.

Ah, gotcha. I updated the readme and pushed!

Doesn't just a "pip install" do the same job as these steps ?

Yes. pip install is the way to go. Or maybe even pipx nowadays...


fix: make mobile navbar prettier

Fixes issue #34 .
Changes made:

[x] light blurred (glass-like) background

Color of the background depends on the theme.

[x] height needs to be for the full screen
[x] more space between links
[x] link text needs to be dark

Link text is dark in the light theme and light in the dark theme.

[x] link font size needs to be bigger

Thank you! Looks good to me :)


[Bug report] Filter rules with duplicate format name lines may cause empty history file on disk

Depending on order of rules, in CLCL ver.2.1.1 eng.
Case 1:

Add (memory and disk) + size limit.
Add (only memory) + no limit.

Result:
Data under limit is saved to memory and disk, as rule 1 says. Good.
Data over limit is ignored, rule 2 is disregarded. Bad, but may be reasonable, because setting duplicate formats is bad.
Case 2:

Add (only memory) + no limit.
Add (memory and disk) + size limit.

Result:
Data under and over limit is saved only to memory, as rule 1 says. Good, although rule 2 is disregarded.
But history file is always empty - 0 bytes, with any size of data. Bug!
As soon as duplicate format name filter settings are removed, history file is resaved normally, using history items in memory.
Even if #4 or some other feature will be implemented and duplicate format names are never needed, I think this bug may be worth investigating.

P.S. Also over the years I encountered CLCL hangs or silent crashes, but I have no helpful info about them. Possibly due to lock-ups in external programs.

Filters take precedence over those in the top position. And if duplicates of the same format are registered, only the one processed first is valid and subsequent formats are ignored.
Therefore, in case 2, only the filter in the top position that is not saved is valid, which is the correct behaviour.

only the filter in the top position that is not saved is valid, which is the correct behaviour.

Yes, I thought so.
The real bug here is entirely overwritten empty history file in some conditions.
Maybe there are more conditions than found here.
All dynamic history (not templates) will be lost after restarting prorgram.


How to get MTU of an dpdk interface?

I'm built an async high level network stack that supports websocket based on capsule(customized, runtime independent)/rawsocket and smoltcp.
Currently the mtu of rawsocket is fetched by pnet, mtu of dpdk device is hard coded. I would like to play around jumbo frames with multiple interfaces at the same time.
This requires getting MTU of a dpdk interface.
How to get MTU of an dpdk interface?
I can use ip a to get ena devices' MTU, but not igb_uio.

Okay, I got it. Unfunately port_id is not publicly visible
impl PortQueue {
    pub fn get_mtu(&self) -> std::io::Result<u16> {
        let mut result = MaybeUninit::uninit();
        unsafe {
            let errno = ffi::rte_eth_dev_get_mtu(self.port_id.raw(), result.as_mut_ptr());
            if errno == 0 {
                Ok(result.assume_init())
            } else {
                Err(std::io::Error::from_raw_os_error(errno))
            }
        }
    }
}

Hi @qiujiangkun, (I'm a capsule noobie, but know a little about DPDK.. so this answer is mostly from DPDK knowledge.)
Indeed the rte_eth_dev_get_mtu function will get the MTU for the device, however I believe there is a limitation in Capsule at the moment that "multi-segment mbufs" are not supported, which means that the maximum size of any single frame must fit into the DPDK mbuf size (controlled by RTE_MBUF_DEFAULT_DATAROOM).
This is documented in the capsule source in mbuf.rs here; https://github.com/capsule-rs/capsule/blob/master/core/src/dpdk/mbuf.rs#L104
Hope this helps, -Harry


Add an option to have title bar container disabled within the mica/acrylic mode

Hello, I have Firefox without title bar container, because I have MinMaxClose button from Firefox Scripts by xiaoxiaoflood, but if I've applied the windows_11_10.css then there already are title bar container buttons, which I don't like. So I want an option in about:config which would disable the title bar container (minimize, maximize, close buttons) with enabled mica/acrylic mode within the windows_11_10.css.
Thank you for understanding my issue!
Oh, and if you implement it, then tell me how is that option named.

Sorry, that I changed the title too often, but the title is now completed.

I don't support third party styles or modifications so I won't make a separate key for that. But if you just need to disable the window control buttons, just use the code below. It doesn't disable the buttons, it hides them.

.titlebar-buttonbox-container
{
    pointer-events: none !important;
    /* or */
    z-index: -1 !important;
}

No! This issue is unrelated to xiaoxiaoflood's MinMaxClose, I only said, that I have it installed.

Also, I added this code to windows_11_10.css and nothing have changed.

I must remove windows_11_10.css from my userChrome.css, because it causes problems with status bar.

My code disables window control buttons. I thought you were talking about it. Can you clarify what you want to do? Preferably with screenshots.

I read your message again. If you need to disable not the window control buttons, but the block in which they are located, then the code below should handle this.
.titlebar-buttonbox-container
{
    display: none !important;
}

Add this code here. You can delete lines from 61 to 135.


Update solana-sdk dependency

This updates the solana-sdk dependency. The currently used version is already quite old and dependabot cannot automatically update it to the most recent version.

Updated to use the newest v1.17.x.

Do we need the dependency on solana-sdk. As far as I can see we are only using it for creating ed25519 keys. Thats a big dependency for a relatively small task. We could use a smaller library like https://github.com/dalek-cryptography/curve25519-dalek, wdyt?


security vulnerability found

Hi,
I would like to report a security vulnerability in this project. Can you please create a security advisory and add me as a collaborator?

Done.

Fixed in 4b3e639d64c55f91152ffb51a4af35a8845c95a3 and published in https://github.com/mohammed90/caddy-ssh/security/advisories/GHSA-gmhj-xjfh-cf6m


atomWithCache debugLabel issue

Summary
I'm getting this error when I use atomWithCache in NextJs 14
Error: Cannot set properties of undefined (setting 'debugLabel')
NextJs setup
experimental: {
    swcPlugins: [
      ['@swc-jotai/react-refresh', { }],
      ['@swc-jotai/debug-label', {}],
    ],
  },

Link to reproduction
Check List
Please do not ask questions in issues.

[x] I've already opened a discussion before opening this issue, or already discussed in other media.

Please include a minimal reproduction.

[ ] I've added a link to a typescript playground or codesandbox with a minimal reproduction.

Also when subscribe value by useAtomValue(selectAtom(...)).

Hi there!
Thanks for reporting.
Can you provide a reproduction?

Closing due to inactivity.


Show pod resource request/usage/limit

What would you like to be added:
In the pod view, show the resource numbers:

requests
limits
usage

I am not looking for graphs, just the most recent number (in the case of usage) and what is configured for requests/limits.
I see this information is already in the Deployment view (for example) for each pod.  It would be helpful if it was also part of the pod view itself.
Why is this needed:
Environment you are Lens application on:

Kubernetes distribution: [EKS, AKS, GKE, Rancher, ...]
Desktop OS:

@DanTulovsky where do you see this information in the UI?


Is it normal that Python lib version 1.3.26 is documented in READMEs, in init.py, but isn't available on pypi ?

Is your problem described in the documentation? If so, please describe
I am quite interested in the latest "history data" feature described here: https://github.com/JeanExtreme002/FlightRadarAPI/tree/main/python#downloading-flight-data
However when pip installing the (obviously Python) library, I see that this functionality is missing in the Api class (checked the source code to confirm), and that the latest version accessible on Pypi is 1.3.25, despite 1.3.26 being apparently released as per https://github.com/JeanExtreme002/FlightRadarAPI/blob/main/python/FlightRadar24/init.py
Describe your question
Considering the recent commits timestamps I was wondering whether it is normal that 1.3.26 is not installable via Pypi yet despite its functionalities being documented ?
Steps to reproduce the behavior:

Create a new Python virtualenv
Activate newly created virtualenv
Run pip install FlightRadarAPI==1.3.26

Yes. Unfortunately, I didn't have the time to do some tests on the new feature. Next week I can release it to Pypi.

Thanks for the reply ! :) do you need any help with contributions ? I have some spare time these days

Thanks for the reply ! :) do you need any help with contributions ? I have some spare time these days

If you have knowledge in NodeJS, I would be glad if you could take a look at the return of method getHistoryData(). I marked the problem with a comment TODO.


Color Gradient with divergence

[It would be better if we can accomodate multiple divergence colors, instead of only 1 in settings. So, that it will be help full to show the visual for top 10 CUstomer reports, there may be five diverging colors and it would be help full to highlight the values more predominant]

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3066fc06-cbb2-def8-1505-cccbb818c147
Version Independent ID: aedfaa65-1253-f7f0-c0bd-2c89bc0a21f5
Content: Tips and tricks for color formatting in Power BI - Power BI
Content Source: powerbi-docs/visuals/service-tips-and-tricks-for-color-formatting.md
Service: powerbi
Sub-service: powerbi-desktop
GitHub Login: @mihart
Microsoft Alias: mihart

Thanks for your comment, @sarava8304.
This looks like product feedback or a product question, rather than documentation feedback. You can submit product feedback or feature ideas by going to Power BI Ideas.
You can also engage with the Power BI engineering team by being active in the Power BI Community.


Are there plans to support dynamic parameters

Creating styles that are more real-time can feel incongruous! It is not known if Griffel has any plans to support dynamic parameters. Similar to:
`
const useClasses= makeStyles((color)=>({fontColor:{color}}))
const classes = useClasses('red')
`

@layershifter I do not think that this is a solution that is maintainable in the long run. I tested this on a small scale project and it was wonky at best. On one hand, it requires a lot of additional work from the user which can be faulty and can lead to mixing style with logic. On the other hand it is not possible to typecheck which makes early detection of mistakes during development even harder.
If I could choose an API, it would probably look something like this:
const useClasses = makeStyles((attr1: string) => {
  root: { color: attr1,
})

function App(props) {
  const classes = useClasses(props.color) // same parameter types as the function passed to makeStyles

  return

}

Then the makeStyles function injects some hashes into the parameters and the useClasses function handles provision of the variables via those hashes. This effectively reduces the amount of work needed to be done for an update while still allowing for changing props to influence the style. However, the work for the creation and injection of the hashes could be a bit more involved, since it would be useful to be able to pass deep objects. But since this work can be done on load it might not be as bad.
There is also the possibility to encourage the current API whilst providing an additional API like the one mentioned for the cases where it is needed.

Looking at the simpler Problem first, does anything speak against injecting in into a style bucket sheet with sheet.insertRule(":root{--<hash>: <value>}"); then obtaining a reference to that style rule and modifying the rule.style.cssText on prop change? Then you would not need to pass any styles around by hand.
It seems to me that the hash could be generated from the encoded style object by injecting placeholder into the variables. However, in corner cases this would create collisions.

sorry for coming back to you so late. Corona got me.
Now assuming there is a good solution for creating a hash one could create a helper class with each call of useClasses that is passed around with the classes. This helper class then gets all the variables for the instance of useClasses.
function Foo() {
  const classes1 = useClasses({ color: 'red' }) // produces something like { root: ["abc123", "h3lp3r"], helpers: ["h3lp3r"] }
  const classes2 = useClasses({ color: 'blue })  // produces something like { root: ["abc123", "r3pl3h"], helpers: ["r3pl3h"] }

  return (
     <>

     </>
  )
}

where the previous still holds true that the helper classes get updated when the props object is updated. However this looks like it would make the problem of finding hashes even worse.


Add a builder for signing HTTP request

Motivation and Context
https://github.com/smithy-lang/smithy-rs/pull/3388#discussion_r1480722375
Description
This PR attempts to provide more ergonomic API for request signing. As documented in aws_sigv4, customers need to follow these steps after creating an Identity and a SigningParams:
// Convert the HTTP request into a signable request
let signable_request = SignableRequest::new(
    "GET",
    "https://some-endpoint.some-region.amazonaws.com",
    std::iter::empty(),
    SignableBody::Bytes(&[])
).expect("signable request");

let mut my_req = http::Request::new("...");
// Sign and then apply the signature to the request
let (signing_instructions, _signature) = sign(signable_request, &signing_params)?.into_parts();
signing_instructions.apply_to_request_http1x(&mut my_req);

This PR allows them to call SignWith::sign_with trait method with SigningPackage instead:
let signing_package = SigningPackage::builder()
    .signing_params(&signing_params)
    .build()
    .expect("required fields have been set");
my_req.sign_with(&signing_package);

Testing
Relied on existing tests in CI
A semver failure in CI can be ignored; A public API SigV4Signer::sign_http_request has been removed that only existed in my feature branch.
Checklist

[ ] I have updated CHANGELOG.next.toml if I made changes to the AWS SDK, generated SDK code, or SDK runtime crates

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

SigningApplication is definitely an improvement, but still seems a little non-intuitive since it is a builder pattern that has a side effect.
What do you think about creating a trait, maybe SignWith, that has a sign_with method taking the identity/settings args, and then implementing that trait for http::Request?

That's an interesting approach 💡  Let's discuss further. I'm curious.

should this target main instead? Is this related to S3 express?

should this target main instead? Is this related to S3 express?

It's just so happens that the S3 express feature branch was a convenient segue for this. But targeting main is actually better, since the S3 express feature branch doesn't need to hold onto these code changes. Will cherry-pick commits and create a different PR that targets main.

Replaced by #3455


Hi Ankraft,

Hi Ankraft,
There seems to be a potential breaking change with the MQTT- Paho have updated to 2.0 and the MQTT client init now requires an extra parameter specifying Apicallback version
https://github.com/eclipse/paho.mqtt.python/releases/tag/v2.0.0
I resolved this by downgrading the mqtt packages on my system
python3 -m pip install paho-mqtt==1.6.1
Originally posted by @name-taken23 in https://github.com/ankraft/ACME-oneM2M-CSE/discussions/131#discussioncomment-8901146

Thanks for reporting. Indeed I didn't noticed that during the final release tests.
I will provide a patch later today to support Paho 2.x .

This should be fixed now. Please use paho version 2.0.


Extra white space in after apply  any functionality into   module

Initially Screen looks like

After applied any functionality

as we see in the second screen there is extra white space after Edit Client as a comparison to the above screen.
Also check it into another module once.

@rathorevaibhav can we close this?


SSL Reverse Proxy

Hi Jason,
First off I would like to thank you for this great product you have created. This has made my life very easy. I have a little issue getting the SSL working and was wondering if you can give me some hints as to where I have gone wrong.
My Setup

jwilder/nginx-proxy => 80:80 & 443:443 traffic
container 1 w/ 3 sites => :80 & :443 traffic, mysqld, httpd, postfix
container 2 w/ 4 sites => :80 traffic, mysqld, httpd postfix
postfix => 25:25 traffic

NGINX SCRIPT
docker run -d -it
--name nginx
-h nginx
-p 80:80
-p 443:443
-v $HOME/nginx/certs:/etc/nginx/certs:ro
-v $HOME/nginx/vhost.d:/etc/nginx/vhost.d:ro
-v $HOME/nginx/passwords:/etc/nginx/passwords:ro
-v $HOME/nginx/log:/var/log/nginx
-v /var/run/docker.sock:/tmp/docker.sock:ro
jwilder/nginx-proxy \
I am able to get traffic on 80 working perfectly. I expose the env $VIRTUAL_HOST and everything works as expected. The trouble I am faced with is making my https:// sites working within container 1.
Questions

Is there an env variable I have to expose for ssl to work?
My certificates are in the form of .cer but nginx requires .crt to work. I have googled and found how to convert to .pem but not to .crt. Can you kindly advise?
Do I need to specify a vhost.d value?

.crt is usually PEM encoded and just named w/ .crt.
I'd suggest running docker logs nginx and see what errors you get as well as examining the client errors you get from connecting to nginx-proxy via SSL.  It's hard to say if your nginx-proxy can't find certs, if they are in the wrong format, or some other issues without an actual error messages indicating what the problem might be.

I was unable to get SSL working. I was playing around and renamed my .cer file to .crt and touched a file in $HOME/nginx/vhost.d. The file created was . This is how I got the SSL working. I feel this is just by lucky everything worked. I read something that .cer and .crt are one in the same DER certs?
The problem I have with troubleshooting within the nginx container is all the logs and request are live. What I mean is the minute I "docker attach nginx" the screen will show live log consistently. Is there a way to suppress it? I apologize for my novice request as I am only 2 month into docker and really excited.

Hi Jason,
I managed to get the SSL working but now I have a different issue. Initially I tested it on port 80 to make sure everything is working (it did). Then after moving everything over to 443 I have a redirect loop error message. My settings are as follows:
<VirtualHost *:80>
ServerName
Redirect permanent / https:///

<VirtualHost *:443>
ServerName :443
ServerAlias www.
ErrorLog /var/log/httpd/-error-log
DocumentRoot  /home//public_html/
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/httpd/conf/certificates/.cer
SSLCertificateKeyFile /etc/httpd/conf/certificates/.key
SSLCACertificateFile /etc/httpd/conf/certificates/Intermediate.cer
<Files ~ ".(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars

SetEnvIf User-Agent ".MSIE."
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x "%r" %b"

I read that if there is a reverse proxy in front of the containers then there is a possibility that it might go into an inifinite loop. I would like to do something with the headers. Can you kindly provide some expertise.

Error Message;
This web page has a redirect loop
ERR_TOO_MANY_REDIRECTS

@gajeevan , how did you solve the problem ? I have similar problem now

Me too !

@juanluisbaptiste, seems like now I understood what was the problem.
I disabled HTTP proxy in DNS server settings on my CloudFlare account and now nginx-proxy is working fine!

@jwilder and anyone who participate in this issue, please confirm that enabling Cloudflare CDN affects on normal work of nginx-proxy

@pavelsr thanks, I also fixed it with answer found here. Basically it says to add the following options to the nginx config:
on your main config (ie: my_proxy.conf):
fastcgi_param HTTPS on; -> to prevent errors while you would loading assets via HTTP while you establish an HTTPS connection
On the virtual host config file on vhost.d:
proxy_set_header X-Forwarded-Proto https; -> for SSL endpoint termination
This options fixed the redirect for me.


Add morcodes snapshot table fixing contribution for snapshot 5

Here are our contributions:

[x] Fix broken snapshot 1-4 tables (https://github.com/MorpheusAIs/Docs/pull/269)
[x] Publish normalized CSV files for data analyst to analyze the weight data easily (https://github.com/mor-codes/Morpheus-Code-Contribution-CSV)
[x] Incorporate new snapshot data with MRI to https://mor.codes
[x] Cross-check with the original version of the snapshot table to hunt for missing weight records

Note: A report was received about a missing weight record (missing before our fix). We will cross-check with the original version of the snapshot table.
We also discovered one record without an MRI in snapshot 2 for wallet address 0x8b194B58B47ff0008ac89a99e54cFdB3ca2f4a5F about translating Whitepaper to Vietnamese.
Fixing the broken snapshot tables required considerable effort due to numerous corner cases and corrupted records that needed manual corrections.
Having a broken snapshot and an unstable table structure is obviously a blocker for the fully functional development of mor.codes!
We believe that fixing the snapshot tables and identifying missing records will have a significant impact on Morpheus. This effort also opens up opportunities for future analytics on code contribution weight to determine the best weight allocation guidelines.
Identifying a 2.7M weights printed due to error should worth 50k weight. These weights can be allocated to new contributors for months

Here is the weight comparison, cross-checked with the original version of the snapshot table, to identify missing weight records. This data was parsed using both automated tools and manual filtering, then categorized into Missing and Printed categories.
https://docs.google.com/spreadsheets/d/14VeA4fOqBGIjFynrLYeOhVdKaFGdb1Frtp2ltOIuNm4/edit?usp=sharing

Source code: https://colab.research.google.com/drive/1OJrzOtF8Jg8OLee03NJH63pj_xowS7M6?usp=sharing
Raw output: weight_comparison.csv
Highlights

A total of 10,453,581 weights are MISSING from 56 wallets.
A total of 12,536,920 weights are PRINTED out of thin air to 47 wallets.

These discrepancies highlight the inaccuracy and transparency issues of the new contribution data. For instance, one such issue was reported in Discord but went unacknowledged.

For the most added weight (2.7M weight) it's a single entry without explaination of DecentralizeAI/MRC

Below screenshot show that this 2.7M weight actually exists

0xfe17147301888fBEEc36be3a8e6E4f883496ed33 with 660 original weight do get weight reduction but it can't be as much as 2.7M weight
It appear to be a rounding error (It have been multiplied by 10, it should be ~0.27M)

Weight for https://github.com/DecentralizeAI/MRC related contributions

Original: 1,110 * 2,000 = 2,220,000
New: 4,493,120
Difference: -2,273,120

Without this extra 2.7M weight, new weight will be reduced to 4,493,120 - 2,747,680 = 1,745,440, resulting in a -474,560 weight different

I appreciate you've spent time on this but there isn't 50000 weights budgeted in MRI 8 for this snapshot.  Where was the request for this accounting and what was the result?

You received weights for mor.codes in the last snapshot, new weights aren't given for maintenance.  Pleas fix this and address the questions above.

Reduced to 20000 weights, removed mor.codes and break down to two contributions

10000 weights - Fix the broken snapshot 1-4 tables and publish normalized CSV files for the data analyst to analyze the weight data easily - https://github.com/MorpheusAIs/Docs/pull/269
10000 weights - Cross-check the original version of the snapshot table to hunt for missing and additional weight records, detecting an additional 2,083,339 weights added to the new snapshot files

For cross-checking with the original version of snapshot you can see above for the result

A total of 10,453,581 weights are missed from 56 wallets.
A total of 12,536,920 weights are added to 47 wallets.
Additional 2,083,339 (12,536,920 - 10,453,581) is being added in new snapshot files

One obvious case is a 2.7M weight highlighted above, which is a significant amount and only exists in the new snapshot file. Since this case isn't resolved yet, the weight for this case can be moved to the next snapshot.
Would you like me to continue checking all missing and added weights in the upcoming snapshot?

Already have been many reviews and audits of the contributions.
The observations above are incorrect and inaccurate as they lack the context of the contributions.
Due to Anon contributions there isn't a perfect tic and tie for everything and there won't be. So its not a valuable use of time to continue this analysis.
These weights requests are very high. Closing this PR.

But your auditor not even noticed this case reported on the Discord


Fabric: Fix various includes

Summary
This pull request fixes a few #includes in the Fabric source:

Changes <Glog/logging.h> to <glog/logging.h> in two files, which was an issue for case-sensitive file systems
In ParagraphProps.cpp, changes the include of attributedstring/primitives.h from a relative style to a more absolute style.

Changelog
[Internal] [Fixed] - Fabric: Fix various includes
Test Plan
Fabric compiles perfectly, and the Fabric test suite passes.

https://takmaps.com/login/?ur_token=85ofMfWpo9nSGKLmHmceIvFLyxW9zmao6jtqTzCAVbZRDTqKVfVklXb2JhZ0xHVnYxUG5KR09leHc0QT09


luci-app-https_dns_proxy: bugfix: subnet address datatype, add DNS.SB provider

This addresses the issue mentioned in #3148.
Signed-off-by: Stan Grishin<EMAIL_ADDRESS>

Could we split the commit into smaller peaces?
Also is it necessary that we check in code comments?

You want me to separate commits for bugfix and adding new DoH providers?

See it as a suggestion and improvement from my side. It is easier for the reviewer to have small commits. Your change makes a fix and a improvement in one commit. So if we move this in the future to a stable branch it es easier to have small commits because we only want to cherrry-pick the bugfix and not a new feature.

It would make it easier for those willing to experiment with other DoH servers to do so. I'm waiting for feedback from @aarond10 on support on the main package.

A normal user without coding experience will not edit this file. So maybe we should read the values from a json file. So we do not have to edit the source file in the future. See https://github.com/openwrt/luci/tree/master/applications/luci-app-statistics/luasrc/statistics/plugins
return {
	value = "https://dns.adguard.com/dns-query?",
	i18n = _(AdGuard (Standard))
}

But this is only a suggestion from my side. How I would make this.

Your change makes a fix and a improvement in one commit. So if we move this in the future to a stable branch it es easier to have small commits because we only want to cherrry-pick the bugfix and not a new feature.

I agree with the advice about separate commits. But I feel that on non-core apps it makes sense to pick up also the (small) improvements to stable branches. We do not need to be quite that strict there.  (Especially 19.07 has not yet seen any rc builds, so there is no locked-down feature set or anything like that)
For package maintainers it makes sense to keep branches in sync if possible, of course without breaking things in release branches.

Your change makes a fix and a improvement in one commit. So if we move this in the future to a stable branch it es easier to have small commits because we only want to cherrry-pick the bugfix and not a new feature.

I agree with the advice about separate commits. But I feel that on non-core apps it makes sense to pick up also the (small) improvements to stable branches. We do not need to be quite that strict there. (Especially 19.07 has not yet seen any rc builds, so there is no locked-down feature set or anything like that)

This was only an advice from my side.
So please go ahead
@hnyman @stangri if this is ok for you I will merge this and close https://github.com/openwrt/luci/pull/3148 because this fixes the same issue.

But this is only a suggestion from my side. How I would make this.

Thanks, I'll look into this for the future updates.


[BUG]MissingMethodException calling Get-PnPWebPart (SP2016 OnPrem)

Notice
Many bugs reported are actually related to the PnP Framework which is used behind the scenes. Consider carefully where to report an issue:

Are you using Invoke-PnPSiteTemplate or Get-PnPSiteTemplate? No.
Is the issue related to the cmdlet itself, its parameters, the syntax, or do you suspect it is the code of the cmdlet that is causing the issue? No.
If you think that the functionality might be related to the underlying libraries that the cmdlet is calling (We realize that might be difficult to determine), please first double check the code of the cmdlet, which can be found here: https://github.com/pnp/powershell/tree/master/src/Commands. If related to the cmdlet, continue reporting the issue here, otherwise report the issue at https://github.com/pnp/pnpframework/issues

Reporting an Issue or Missing Feature
Missing Method Exception
Expected behavior
Diplsay Webparts
Actual behavior
get-pnpwebpart : Method not found: 'System.String Microsoft.SharePoint.Client.WebParts.WebPartDefinition.get_ZoneId()'.
At line:1 char:1

get-pnpwebpart

Steps to reproduce behavior
Get-PnPWebPart -ServerRelativePageUrl "/sites/demo/sitepages/home.aspx"
What is the version of the Cmdlet module you are running?
Microsoft.SharePoint2016.CSOM  16.0.4690.1000
Install-Module SharePointPnPPowerShell2016
Which operating system/environment are you running PnP PowerShell on?

[ ] Windows

Are you by any change running this -on- the server? Or from a remote machine? It sounds like PnP PowerShell is using a different version (e.g. older) of CSOM.

Are you by any change running this -on- the server? Or from a remote machine? It sounds like PnP PowerShell is using a different version (e.g. older) of CSOM.

Hello,
Thanks for your prompt reply.
This is from a remote machine.

Hello,
Thanks for your prompt reply.
This is from a remote machine.

FYI:
PS C:\WINDOWS\system32> Get-Module SharePointPnPPowerShell* -ListAvailable | Select-Object Name,Version | Sort-Object Version -Descending
Name                        Version

SharePointPnPPowerShell2016 3.29.2101.0

FYI:
PS C:\WINDOWS\system32> Get-Module SharePointPnPPowerShell* -ListAvailable | Select-Object Name,Version | Sort-Object Version -Descending
Name                        Version

SharePointPnPPowerShell2016 3.29.2101.0

Can you run this PowerShell snippet?
[AppDomain]::CurrentDomain.GetAssemblies() | ?{$_.Location -like "*Microsoft.SharePoint.Client.dll"} | %{Get-Item  $_.Location | select -ExpandProperty VersionInfo}

It should return one entry, and show a file version and product version stating: 16.0.4690.1000.

Can you run this PowerShell snippet?
[AppDomain]::CurrentDomain.GetAssemblies() | ?{$_.Location -like "*Microsoft.SharePoint.Client.dll"} | %{Get-Item  $_.Location | select -ExpandProperty VersionInfo}

It should return one entry, and show a file version and product version stating: 16.0.4690.1000.

Yes, her is the result:
ProductVersion   FileVersion      FileName

16.0.4321.1000   16.0.4321.1000   C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.SharePoint.Client\v4.0_16.0.0...

Yes, her is the result:
ProductVersion   FileVersion      FileName

16.0.4321.1000   16.0.4321.1000   C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.SharePoint.Client\v4.0_16.0.0...

Also: is the page you're trying to access a modern page or a classic webpart page?

Also: is the page you're trying to access a modern page or a classic webpart page?

It's a classic webpart page.

It's a classic webpart page.

I have the same issue using SP2019 intranet.

I have the same issue using SP2019 intranet.

Okay, so the version number I posted is the one we include with the PnP PowerShell installation, but it seems there is some other tool running on your computer that actually loads/uses an older version. That's the reason you see the error message. It's a limitation of PowerShell (nothing specific to PnP PowerShell) that only one version of an assembly can be loaded at the same time. The one that is loaded in your case is older and causes the issue, as we require a newer version.
So in short: something else is installed on your computer that uses an older version. A typical reason for this is that the application installed the older version in the Global Assembly Cache. Assemblies in the GAC always 'win' over locally available ones. E.g. if a program finds a version in the GAC it will use that one, even if it is also available in the same folder of the application. In your case you see that the path listed is pointing to the GAC.
A typical 'offender' of this problem is Visual Studio if you have the SharePoint development extensions installed. They took the liberty to assume that you only want one version of the CSOM assemblies on your machine, which is usually not the case...
There is unfortunately nothing we can do about this, other than you check if there is an updated version available for Visual Studio (-if- you have Visual Studio installed)

Okay, so the version number I posted is the one we include with the PnP PowerShell installation, but it seems there is some other tool running on your computer that actually loads/uses an older version. That's the reason you see the error message. It's a limitation of PowerShell (nothing specific to PnP PowerShell) that only one version of an assembly can be loaded at the same time. The one that is loaded in your case is older and causes the issue, as we require a newer version.
So in short: something else is installed on your computer that uses an older version. A typical reason for this is that the application installed the older version in the Global Assembly Cache. Assemblies in the GAC always 'win' over locally available ones. E.g. if a program finds a version in the GAC it will use that one, even if it is also available in the same folder of the application. In your case you see that the path listed is pointing to the GAC.
A typical 'offender' of this problem is Visual Studio if you have the SharePoint development extensions installed. They took the liberty to assume that you only want one version of the CSOM assemblies on your machine, which is usually not the case...
There is unfortunately nothing we can do about this, other than you check if there is an updated version available for Visual Studio (-if- you have Visual Studio installed)

I have the latest Nuget package installed with Visual Studio: 16.0.4690.1000

I have the latest Nuget package installed with Visual Studio: 16.0.4690.1000

I've also check on GAC there is nothing!

I've also check on GAC there is nothing!

The path returned by the ps snippet you ran says something different though:
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.SharePoint.Client\v4.0_16.0.0...

That's pointing straight to the GAC on your machine.

The path returned by the ps snippet you ran says something different though:
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.SharePoint.Client\v4.0_16.0.0...

That's pointing straight to the GAC on your machine.

Yes, I agree with you.
But do you think that this issue is related to this SPClientDLL's version?

Yes, I agree with you.
But do you think that this issue is related to this SPClientDLL's version?

Very likely. The ZoneId property has been introduced in a later version of the Microsoft.SharePoint.Client.dll assembly, it wasn't available from day one however the SharePoint extensions for Visual Studio are not very often updated and most likely run an older version. An easy test could be to try it on a computer (or virtual machine) which does not have Visual Studio installed.

Very likely. The ZoneId property has been introduced in a later version of the Microsoft.SharePoint.Client.dll assembly, it wasn't available from day one however the SharePoint extensions for Visual Studio are not very often updated and most likely run an older version. An easy test could be to try it on a computer (or virtual machine) which does not have Visual Studio installed.


Portuguese not output on frontend

I added pt_PT (portugal) in my config file, and everything works fine as usual. The problem is, that "portuguese" is not being output on the frontend, by the $LanguageNative variable. I had to do a custom If statements, manually outputting it.
This problem does not occur with any other language I tried.
Is it a bug?

Hm, it should output perfectly fine.
Can you please attach your YML config for me? The language name comes from i18n::$common_locales which has an entry for pt_PT and should appear as português (Portugal)

Hey sorry for the late response.
Here is my YML config, unfortunately Github wouldnt let me just attach the file.
---
Name: myfluentconfig
After: '#fluentconfig'
---
Fluent:
  default_locale: da_DK
  locales:
    - da_DK
    - en_US
    - de_DE
    - fr_FR
    - cs_CZ
    - pl_PL
    - ru_RU
    - sk_SK
    - pt_PT
    - es_ES
  aliases:
    da_DK: da
    en_US: en
    de_DE: de
    fr_FR: fr
    cs_CZ: cs
    pl_PL: pl
    ru_RU: ru
    sk_SK: sk
    pt_PT: pt
    es_ES: es
  domains: []
    #  www.example.com.au:
    #    locales:
    #      - en_AU
    #      - en_US
    #    default_locale: en_AU
    #  www.example.co.nz:
    #    locales:
    #      - en_NZ
  detect_locale: false
  remember_locale: false
---
Name: myfluenti18nconfig
After: '#fluenti18nconfig'
---
i18n:
  default_locale: da_DK


API Catalog

This issue tracks the APICatalog epic which aims at providing a catalog of APIExports for users to be able to bind. More details on the design and approach can be found in the documentation: https://hackmd.io/5KcilJjjSfm24v3QWyjfBQ?view
Initial Prototype work:

[ ] Finalize the design for CatalogEntry API (v1alpha). - https://github.com/kcp-dev/catalog/pull/3
[ ] Design catalog controller which watches CEs, and validates whether the referenced APIExport exist. - https://github.com/kcp-dev/catalog/pull/5
[ ] Design cli commands that allow users to bind to catalogs, list APIExports present in the catalog (based on hierarchy of workspaces), create CEs. - https://github.com/kcp-dev/catalog/pull/6

Future TODOs:

[ ] Design and finalize lifecycle of CatalogEntry.
[ ] Fix the permission structure required to allow users bind to catalog.

cc: @dinhxuanvu

@varshaprasad96 @dinhxuanvu Does this need a review on the breakdown of remaining tasks?  What is left to close out the MVP for an API Catalog?  Thanks!

@pweil- Have updated the tasks with the open PRs which are being worked on.

Thanks @varshaprasad96. 🥇  I'm assuming that Design and finalize lifecycle of CatalogEntry represents a fairly significant portion of work and needs discussion.  A few questions:

Does this tie in at all with @ncdc 's API evolution R&D?
Should we begin coordinating this topic at the community calls now if it's part of MVP?

@gallettilance - FYI, relevant to your interests
cc @stevekuznetsov and @nrb who have been thinking about developer experience topics as well 👍

@pweil- Yes, the lifecycle of Catalog Entry is an extended task which needs more discussion. For now, we are trying to implement and close out the other 3 tasks to get the basic feature out of the door and get more user reviews on it. The design doc for the first phase as discussed is here: https://hackmd.io/5KcilJjjSfm24v3QWyjfBQ?view


broadcast_reduce_op BroadcastAxesShape does not handle negative axes

Description
Consider
import mxnet as mx
a = mx.nd.ones((1, 1, 1, 1, 1, 1, 1))
print(mx.nd.broadcast_axes(a, -4, 10).shape)

Results in
Traceback (most recent call last):
  File "mxnet_test.py", line 3, in <module>
    print(mx.nd.broadcast_axes(a, -4, 10).shape)
  File "<string>", line 56, in broadcast_axes
  File "/Users/lllausen/anaconda3/envs/py36/lib/python3.6/site-packages/mxnet/_ctypes/ndarray.py", line 92, in _imperative_invoke
    ctypes.byref(out_stypes)))
  File "/Users/lllausen/anaconda3/envs/py36/lib/python3.6/site-packages/mxnet/base.py", line 210, in check_call
    raise MXNetError(py_str(_LIB.MXGetLastError()))
mxnet.base.MXNetError: [00:40:51] src/operator/tensor/./broadcast_reduce_op.h:306: Check failed: oshape[param.axis[i]] == 1U<PHONE_NUMBER>559351923 vs. 1) Broadcasting axis must have size 1

Stack trace returned 8 entries:
[bt] (0) 0   libmxnet.so                         0x000000011000c3b4 libmxnet.so + 21428
[bt] (1) 1   libmxnet.so                         0x000000011000c16f libmxnet.so + 20847
[bt] (2) 2   libmxnet.so                         0x0000000110359431 libmxnet.so + 3482673
[bt] (3) 3   libmxnet.so                         0x000000011113d47a MXNDListFree + 497978
[bt] (4) 4   libmxnet.so                         0x000000011113c099 MXNDListFree + 492889
[bt] (5) 5   libmxnet.so                         0x000000011109d40a MXCustomFunctionRecord + 20666
[bt] (6) 6   libmxnet.so                         0x000000011109e4b0 MXImperativeInvokeEx + 176
[bt] (7) 7   libffi.6.dylib                      0x000000010f0f7884 ffi_call_unix64 + 76

The expected behavior is to either check and report that negative axes are invalid or to wrap around.

Looks like unsigned type being used in axis.


Issue #6: Add Shields to README

Added architecture and contributor shields to README. Could not add license shield because the license has not been specified.
Signed-off-by: Julian Chen<EMAIL_ADDRESS>

I added LICENSE and License shield.


IMPROVE: Markdown Syntax and Fix #10

This PR IMPROVES: Markdown Syntax and Fix #10 as per our discussion in the meetup.

Great! 🙌 Thanks.

Thank you @ahmadawais I just completed my Hacktoberfest challenge. Awesome!

Thank you for guiding us.


librsvg: 2.54.4 → 2.55.1

Description of changes
Now following the new GNOME version policy (no more odd-unstable).
https://github.com/GNOME/librsvg/compare/2.54.4...2.55.1
Cherry-picked from https://github.com/NixOS/nixpkgs/pull/182618

Things done

Built on platform(s)

[x] 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

[x] Fits CONTRIBUTING.md.

Decided to merge it as a part of #182618.


Constant errors in TypeScript files

I noticed that several errors appeared in my TypeScript files. Initially, I thought they were TypeScript or WebStorm errors, but after some tests, I identified that the problem was with Biome.
It seems that Biome doesn't trigger some action after the last user action (last character typed), causing the error.
Common declaration without any errors in the file:

I added a simple "export" and the error appeared:

More about the error:

When I restart the Biome service, the error disappears. I can also solve the problem by closing and reopening the file:

To rule out configuration issues, Biome, or the plugin, I tested the same code in VSCode:

When typing, it shows an error, which is expected because I haven't added the necessary space yet:

And after adding the space, no errors appear, meaning it's not a configuration or Biome library issue, but a problem with the WebStorm plugin:

This issue is quite frustrating as it mixes real problems with this bug, making the work harder.

While I was gathering evidence, I noticed that I didn't have a tsconfig in the project. I thought this might be a dependency of the plugin, but it wasn't. I added the tsconfig, and unfortunately, the problem persists.

Ah, congratulations on the excellent tool, Biome, and this plugin! I'm sure they will soon become an industry standard :)

MacBook 16" 2019 (Intel) - Mac Sequoia
WebStorm 2024.2.3

Hi @rodrigojcmello
Thank you for the report. Could you please provide a minimal reproducible example?


Ensure backwards compatibility with old templates suite

Issue description
The templates restructure (see PR #195 ) has two minor feature-breaking changes:

CVNeuralNet is replaced by CVNeuralNetLayers, which takes arguments differently
StronglyEntanglingLayer(s) argument 'periodic' is dropped

We should make these backwards compatible. I have the changes locally, but not tested.

Do the feature-breaking changes lead to better usability? If so, I would argue that we have the freedom (since version number is <1) to make a breaking change without ensuring backwards compatibility.

Yes, I'd say they do lead to more consistency and better usability of pytorch integration...

In which case, I would suggest it's fine to close this issue (@co9olguy?)


Fix FOUC with injected CSS files

Thanks! Give me a bit and I'll try it out tomorrow!

Sure thing :)

I've tried it out and it appears to work, thanks for this!

Glad it worked out!


Show notification when a newer version of the web-console is available

When the Inmanta server is upgraded to a new version that contains a newer version of the web-console, the user must do a force reload of the application in the browser to actually use that new version. This issue should make sure that the user gets notified when he/she is using an old version of the web-console while a new version is available on the server.
The status page already contains the commit hash, it could be used to detect a different available version as well:

Notification, as in a toast/popup, or a banner that remains visible?

Okay! An orange one I assume?

The orange seems to be pretty in your face. I like the design in this screenshot:

Any reason why you would use orange?

Orange is typically used for more or less important warnings. If the fact that the user is using an older version is problematic, from a UI-UX point of view, orange is the right choice. If the update of the version is not critical/that important, blue would do as it is then more an information than a warning.

lets do orange then

Okay, if it still feels too strong for the eye, we can still change the color later. That's a minor adjustment to do.

Hey team! Please add your planning poker estimate with Zenhub @LauraStordeur @matborowczyk

Status update :

currently the commitHash is being stored in the application when it is deployed. It is a configuration in webpack.

The problem is that it is a saved image, and hasn't any awareness of what's happening further in the repo.

Ideally, we would need an api-call to retrieve this information to be able to know if the app is outdated.
Question : How do we proceed when this kind of situation occurs? @bartv


Inconsistency in the docs and the examples

PR #3172 updated the docs to include the new .resolves and .rejects keywords for running assertions on Promises.
I noticed that this PR introduced some inconsistencies in the updated Error Handling section of https://github.com/facebook/jest/blob/master/docs/TutorialAsync.md. There is a screenshot of this section below:

The comments at the top of the test still refer to try-catch, this is inconsistent with the code contained in the code snippets.
The PR only shows an example with .rejects which will only be available in Jest 20+. This should be mentioned in the docs to avoid confusion.
People using older versions of Jest will not be able to use this documentation. I think we should add back the explanation about using try-catch to catch Promise rejection (that was removed in PR #3172) for people using Jest 19 and below. This can live alongside the current docs using .rejects.
The example contained in the link examples/async links to testing examples like this. These examples still use the try-catch mechanism, this is inconsistent with the code examples currently contained in the docs. This is another reasons why we should add back the explanation of using try-catch to this section of the docs.

Is it possible to try out jest 20.0.0+ for those new keywords?

I am not sure when jest 20 will be released but I hope soon:)

I think this is now resolved with #3201. If you think there is more we can do here, please send a PR :)


Docker Image security concerns

Hello,

The docker image is based on rubylang/ruby-3.2-jammy.
This image is 5 months old and never seems to receive recent ubuntu security updates.
Consider putting a "apt upgrade" in the dockerfile

The docker image uses mysql.com mysql packages for ubuntu 18.04
-- Why using ubuntu 18.04 packages when we are on 22.04
-- According to https://www.mysql.com/support/eol-notice.html the ubuntu 18.04 repo is EOL since 1st May 2023 and does not longer receive updates
Consider using a current mysql (or mariadb?), preferably from repos of the used operatingsystem and not from additional sources.

Feel free to PR, answer to "why" is because no one cared, show them you do.


New release

Could you please prepare a new release with the latest commits?

Done, the release is available here: https://github.com/radekg/terraform-provisioner-ansible/releases/tag/v2.1.2.