Deprecate $broadcast() and $dispatch()

Problem
The event system seemed like a useful idea when I first implemented it. It is still very useful internally, but I've found that I almost never use it in my application code because the accidental complexity $broadcast() and $dispatch() can introduce. Here are some issues:

Their behavior relies on the structure of the component tree. On the surface it decouples the components, but in fact it still couples them quite tightly. Once a event relationship is set up, your components need to stick to that structure; you can accidentally break your event chain by moving the components around.

Namespacing. When you listen to an event, you have no idea if a child component somewhere might dispatch an event with that name and screw things up. You just can't prevent that.

Events are often (ab)used to trigger state changes, but their propagation inside the component tree is very abstract and implicit. Because the events can go both ways, the events flow inside a large application quickly gets very hard to wrap your head around, and it becomes even harder to understand where your app state to change originated from. A lot of times, a simple global event bus can make things centralized and thus a lot easier to understand. (You can even adopt Flux if you want to go further)

Proposal

Deprecate $broadcast() and $dispatch(). Other event methods still remain, which means Vue isntances are still event emitters.

Expose a global utility so users can construct their own event bus. Something like new Vue.Emitter().

(Outside of core) Investigate official recommendation for state management. You can use libraries like vuex or Redux.

I'm sure you've read all my code and are trying to break everything I've written :) I currently use a dispatch event on a component to tell it's parent that it's now selected (Which is bound to the main app), this then broadcasts to all the other components a message to say that a new component is selected. Works exactly as I thought it should and made sense. I could change this to use a 2 way prop, but when you start going through multiple layers it gets a bit messy IMO.
If your still using them internally then why not let them live and add a new global emitter that people can use if the current system doesn't work for them?

I use both heavily, but am more then willing to rewrite everything as its really starting to feel messy.

but when you start going through multiple layers it gets a bit messy IMO

That's why I wrote about something like $context earlier, but this probably won't come soon :)
As for events, I use them sometimes and global utility would be useful. For me, there were some interesting cases for events while dev, it's not about only centralizing app data and state.

Adding global would be nice but please don't remove the current ones.  I
find it useful to know the intent.  It improves readability.  I use all
three heavily.
On Mon, Aug 17, 2015 at 11:06 AM, Azamat<EMAIL_ADDRESS>wrote:

but when you start going through multiple layers it gets a bit messy IMO
That's why I wrote about something like $context earlier, but this
probably won't come soon :)
As for events, I use them sometimes and global utility would be useful.
For me, there were some interesting cases for events while dev, it's not
about only centralizing app data and state.
—
Reply to this email directly or view it on GitHub
https://github.com/yyx990803/vue/issues/1175#issuecomment-131911704.

I also heavily rely (relied) on the Event Bus in some (now finished) projects. It really felt a bit messy and eventually what I did 90% of the time, was sending events to a controller instance at the top, where they were handled and sometimes another event was broadcast down the chain. So I sort of globalized a localized system.
If you implement something like Vue.Emitter (I really love the Idea), please make sure that it can be switched out with custom modules from the node ecosystem like wolfy87.
One thing to consider. Most of us will use some sort of modularisation like webpack or browserify. Does it really make sense to implement an EventBus when you can have an instance of an existing EventBus on your fingertip by writing require("myFavouriteEventEmitter")?

@mark-hahn 1.0.0-alpha will not remove anything, you have plenty of time to migrate. I honestly think the benefits of decoupling the event system from the view structure outweighs the express of intent of $broadcast and $dispatch. For example, with a global event bus, when you grep for .emit('event') and .on('event') you know the former will trigger the latter, but when the event propagation depends on how your components are structured, you can't be so sure.
@Nirazul currently, all Vue instances implement the emitter interface already. So it's just a matter of exposing some internals that's already there. It's totally optional, you sure can use whatever external event library you want. Since without $broadcast and $dispatch a global emitter would be a common pattern, it's good to make sure users not using certain build tools still have access to the same functionality.

I honestly think the benefits of decoupling the event system from the
view structure outweighs the express of intent of $broadcast and $dispatch.

I just realized that I was arguing strongly about simplicity and removing
things so now I agree these can be removed.
On Mon, Aug 17, 2015 at 12:49 PM, Evan You<EMAIL_ADDRESS>wrote:

@mark-hahn https://github.com/mark-hahn 1.0.0-alpha will not remove
anything, you have plenty of time to migrate. I honestly think the benefits
of decoupling the event system from the view structure outweighs the
express of intent of $broadcast and $dispatch. For example, with a global
event bus, when you grep for .emit('event') and .on('event') you know the
former will trigger the latter, but when the event propagation depends
on how your components are structured, you can't be so sure.
@Nirazul https://github.com/Nirazul currently, all Vue instances
implement the emitter interface already. So it's just a matter of exposing
some internals that's already there. It's totally optional, you sure can
use whatever external event library you want. Since without $broadcast
and $dispatch a global emitter would be a common pattern, it's good to
make sure users not using certain build tools still have access to the same
functionality.
—
Reply to this email directly or view it on GitHub
https://github.com/yyx990803/vue/issues/1175#issuecomment-131941355.

For building an application, the global event bus pattern will lead the app to more easier to manage, I think.
But for building common UI components, I think the $broadcast and $dispatch are useful to communicate between some relative components like menu, menu-item and submenu because the structure are intend to be coupled and the structure information should be also carried by the events (implicit by the $broadcast and $dispatch). For example, when the menu closes, it should also let all submenus close too, it is easy to do this by $broadcast an menuclose event.

when the menu closes, it should also let all submenus close too, it is
easy to do this by $broadcast an menuclose event.

And this event can have only one name without namespace problems, where a
global bus would require some awkward namespacing code.
On Tue, Aug 18, 2015 at 10:32 PM, terencez<EMAIL_ADDRESS>wrote:

For building an application, the global event bus pattern will lead the
app to more easier to manage, I think.
But for building common UI components, I think the $broadcast and
$dispatch are useful to communicate between some relative components like
menu, menu-item and submenu because the structure are intend to be
coupled and the structure information should be also carried by the events
(implicit by the $broadcast and $dispatch). For example, when the menu
closes, it should also let all submenus close too, it is easy to do this
by $broadcast an menuclose event.
—
Reply to this email directly or view it on GitHub
https://github.com/yyx990803/vue/issues/1175#issuecomment-132451404.

@TerenceZ @mark-hahn I can see the use case here, but how do we control of boundary of these events? Right now to prevent the event dispatched by a menu-item to go outside menu, we'd have to remember to return false in menu's corresponding event handler. Same for $boardcast if menu-item can contain inserted content. If we don't do this we have the same implicit namespace problem, but having to remember to manually do this is a fragile pattern. This is the part that I am most unhappy about with the current implementation, and I'd love to see if there's a way to solve this problem while keeping the usefulness.

how do we control of boundary of these events?

I'm confused.  A global bus has no boundaries at all, right?  I must be
misunderstanding your meaning of boundary.
On Wed, Aug 19, 2015 at 10:56 AM, Evan You<EMAIL_ADDRESS>wrote:

@TerenceZ https://github.com/TerenceZ @mark-hahn
https://github.com/mark-hahn I can see the use case here, but how do we
control of boundary of these events? Right now to prevent the event
dispatched by a menu-item to go outside menu, we'd have to remember to return
false in menu's corresponding event handler. Same for $boardcast if
menu-item can contain inserted content. If we don't do this we have the
same implicit namespace problem, but having to remember to manually do this
is a fragile pattern. This is the part that I am most unhappy about with
the current implementation, and I'd love to see if there's a way to solve
this problem while keeping the usefulness.
—
Reply to this email directly or view it on GitHub
https://github.com/yyx990803/vue/issues/1175#issuecomment-132721491.

@mark-hahn yeah, that's true. I do agree that the global event bus has its own issues. Maybe what I want is for event listeners to return false by default - i.e. when a $broadcasted / $dispatched event is handled, it just stops, unless the handler explicitly pass it on with return true.

I would prefer to keep it the way it is, but that's clearly just a personal
preference (and I'm lazy).  Arguments can be made for either default
return.  Good coding would make every return explicit.  (grin)
On Wed, Aug 19, 2015 at 12:08 PM, Evan You<EMAIL_ADDRESS>wrote:

@mark-hahn https://github.com/mark-hahn yeah, that's true. I do agree
that the global event bus has its own issues. Maybe what I want is for
event listeners to return false by default - i.e. when a $broadcasted /
$dispatched event is handled, it just stops, unless the handler explicitly
pass it on with return true.
—
Reply to this email directly or view it on GitHub
https://github.com/yyx990803/vue/issues/1175#issuecomment-132745809.

@yyx990803 I like the idea of defaulting off and specifying that an event should propagate further, but  return true;—despite it's simplicity—it's not very semantic.
What about providing the handler a callback that should be executed if they want the event to propagate?  Something like this:

// this handler will not propagate
this.$on('eventA', function(data, propagate) {
   // ... do something with data
});

// this handler will propagate
this.$on('eventB', function(data, propagate) {
   // ... do something with data
  propagate();
});

@young-steveo agreed, that's definitely worth considering.

import Vue from 'vue';

Vue.extend({
    emitters: {
        dispatch: Vue.DispatchBus,
    },
    components: {...},
    created: function() {
        this.$on(dispatch, function(data, bus, propagate) {...}
    }
    methods: {
        theThing: function() {
        }
    }
});

A couple of thoughts on deprecating the existing emitters, while providing an easy migration path.

Different buses provide different behaviors of how events are propagated throughout the vue hierarchy.

Just a thought: the current $dispatch emitter is similar to dom event bubbling. Whether or not that's a good thing, I don't know, but it's a familiar mental model to regular DOM event handlers.
Maybe a solution is to separate each emitter behavior into it's own bus, and vues would register multiple buses. Some possiblities:

dispatch bus: vue hierarchy aware, only sends events up the vue hierarchy.
broadcast bus: vue hierarchy aware, only sends events down the vue hierarchy.
global bus: vue hierarchy agnostic, broadcasts events to all vues in its registry.
local bus: like the current $emit. It could maybe be a default or required bus?

Other thoughts:

$emit could take an optional bus name to specify which bus to emit the message onto (defaults to the local bus otherwise).
Existing $dispatch and $broadcast methods would be provided by their respective buses as shortcuts to calling $emit('<bus name>').
Child vues/components automatically register

return true;—despite it's simplicity—it's not very semantic.

It's a standard used everywhere.  If everyone know what it means then it
is semantic.

while providing an easy migration path.

It may seem easy to you but to me it looks like a lot of unneeded
complexity to me.  Why does everyone want to change something that works?
Can someone show me an example where the current methods don't work or they
break something?
On Wed, Aug 19, 2015 at 2:23 PM, Ryan P Kilby<EMAIL_ADDRESS>wrote:

import Vue from 'vue';
Vue.extend({
emitters: {
dispatch: Vue.DispatchBus,
},
components: {...},
created: function() {
this.$on(dispatch, function(data, bus, propagate) {...}
}
methods: {
theThing: function() {
}
}
});
A couple of thoughts on deprecating the existing emitters, while providing
an easy migration path.

Different buses provide different behaviors of how events are propagated
throughout the vue hierarchy.

Just a thought: the current $dispatch emitter is similar to dom event
bubbling. Whether or not that's a good thing, I don't know, but it's a
familiar mental model to regular DOM event handlers.
Maybe a solution is to separate each emitter behavior into it's own bus,
and vues would register multiple buses. Some possiblities:

dispatch bus: vue hierarchy aware, only sends events up the vue
hierarchy.
broadcast bus: vue hierarchy aware, only sends events down the vue
hierarchy.
global bus: vue hierarchy agnostic, broadcasts events to all vues
in its registry.
local bus: like the current $emit. It could maybe be a default or
required bus?

Other thoughts:

$emit could take an optional bus name to specify which bus to emit
the message onto (defaults to the local bus otherwise).
Existing $dispatch and $broadcast methods would be provided by their
respective buses as shortcuts to calling $emit('').
Child vues/components automatically register

—
Reply to this email directly or view it on GitHub
https://github.com/yyx990803/vue/issues/1175#issuecomment-132790055.

Sorry - prematurely submitted the comment while hashing out my thoughts. Thought I was able to delete it before it sent out an email.

@mark-hahn imagine you have a component, say menu, which includes a private child component, menu-item, and the menu-item communicates to menu by dispatching an event, e.g. closed.
Now if you want to make this component reusable, you don't want the closed events dispatched from the child to leak outside of menu, and potentially affect the higher-up component that also happens to listen for a closed event. Sure you can avoid this by namespacing all the events, but that's when you have full control over the whole application. If the component is used by someone else in an unknown environment, you have no guarantee that the dispatched event won't accidentally trigger some unwanted handler up the tree.
To ensure the event doesn't leak, you have to "intercept" it at the menu level, and with the current API you have to explicitly return false, which probably very few people do.

That is a good example.  I understand now.
Then I'll argue to reverse the return true/false default.  I will continue
to argue against anything more complex.
On Wed, Aug 19, 2015 at 3:30 PM, Evan You<EMAIL_ADDRESS>wrote:

@mark-hahn https://github.com/mark-hahn imagine you have a component,
say menu, which includes a private child component, menu-item, and the
menu-item communicates to menu by dispatching an event, e.g. closed.
Now if you want to make this component reusable, you don't want the closed
events dispatched from the child to leak outside of menu, and potentially
affect the higher-up component that also happens to listen for a closed
event. Sure you can avoid this by namespacing all the events, but that's
when you have full control over the whole application. If the component is
used by someone else in an unknown environment, you have no guarantee that
the dispatched event won't accidentally trigger some unwanted handler up
the tree.
To ensure the event doesn't leak, you have to "intercept" it at the menu
level, and with the current API you have to explicitly return false,
which probably very few people do.
—
Reply to this email directly or view it on GitHub
https://github.com/yyx990803/vue/issues/1175#issuecomment-132808272.

@mark-hahn In my opinion, literal booleans can easily become anti-patterns when used as function parameters or return values (unless the function name semantically indicates that you are expecting a boolean, like this.isReady() or something like that).
Here's an example where boolean parameters make the code less semantic:
this.save({ id : 5, value : 'foo' }, false, true);

In that example, it looks like the function is saving an object...   but what is the third param true?  What is false doing in the second param?  You would have to look up the function definition to find out what those params are doing.  A better API would be something like:
this.save({ id : 5, value : 'foo' }, { log : false, upsert : true });

Now you can pretty much reason out that you are saving an object, and you want the upsert option to be true, and you don't want to log anything.  This is more semantic.
Now, regarding return true;, we can make the same analogies.  Returning true does not indicate what true really means.
function handleEvent() {
  // do stuff with backend, then...
  return true;
}

What does return true mean here?  Does it mean that an event was successfully handled?  Does it mean that the event should propagate? Does it mean that the backend operation was successful?

If everyone know what it means then it is semantic.

That's not really true (pun intended? j/k).  If everyone knows what it means, then it is expected.  It is intrinsic.  But it is not semantic, or explicit.

I agree with everything you've pointed out, although using return false is less ambiguous than your call example this.save({ id : 5, value : 'foo' }, false, true);.
I've always seen return false to mean to stop propagating but here we are talking about reversing it, which now that I think about it would be really bad because it would be the opposite of the standard.  That would really confuse everyone.  So maybe having a simple stopPropagation() or continuePropagation()  or passEvent() call would be unambiguous and semantic. I still argue that return false meaning to stop propagation would be fine.
I know my opinion is flip-flopping all over the place.  I will try to think things out better before typing.  At least I'm stimulating thinking (I hope).
BTW, googling "semantic" results in "relating to meaning in language or logic."  The meaning of return false in events is clearly to stop propagating, so how is that not semantic?  this.zxy(true, false) is not semantic.

@mark-hahn I completely agree that using return false in an event handler to stop propagation is very common.  However, I firmly reject that it is semantic.

The meaning of return false in events is clearly to stop propagating, so how is that not semantic?

Knowing a thing does not make it explicit.  You subjectively know the meaning of return false because you are applying context and experience.  But if you look at return false objectively, it's just a boolean.  It has no further context beyond true or false.  I would argue that return "stop propagating" would be a much more semantic—albiet ugly and brittle—pattern.
All that said, I guess return false gets the job done at the end of the day.

When I first started working with components in Vue I assumed the event propagation stopped after the first component listening to it got hit. Thats what made sense to me - of course after carefully reading the docs I was aware of the return false;
If I want to propagate it further i'll just do something like propagate().

It is necessary to make $.on("*") for listening all events from $.dispatch (or check that the event is dispatched in the handler). If event with attribute "all" (optional) in the root component then call $.broadcast(...)
Stop propagation by default :+1:

Couple of thoughts:

You could fix the namespace issue by using reverse domain naming. For instance, "com.example.closed". Kind of verbose, but it would work.

What if a ViewModel could declare that it terminates the event hierarchy above it (as a leaf node) and starts a new event hierarchy from that point down. Events don't propagate across it. $broadcast sends an event down on the new hierarchy and $dispatch sends an event up the "parent" event hierarchy.

While the "propagate" call would work, it has to be used consistently in any $on handler. With 2. it would be just a declarative setting on a ViewModel and $on handlers wouldn't need to worry about it.

@davidkhess interesting ideas, but there's one problem with the what I call "event root" solution: it only defines the upper-bound of the events, but for lower-bound it relies on a child component to also declare itself as event root, which is not a strong guarantee.

True enough – i.e. an opt-in mechanism for event forwarding so that the default behavior is safer. I can't think of a way to do that in Option 3 declaratively without creating a lot of extra declarative setup. At least propagate is isolated to the event handlers themselves.
+1 for propagate

Ok, so the problem with the extra propagate argument is that events may emit with unknown length of arguments:
this.$emit('a', 1, 2, 3)
this.$emit('a', 2, 3)

If we simply append propagate to the end of the argument list, the handler don't really know which one it is, because the arguments length can be different.
I guess we'll have to go with return true here - although less explicit, it seems a straightforward solution.

Implemented in alpha branch.


React-based form action loading indicator doesn't animate in IE

See svg rule in admin/javascript/src/components/form-action/styles.scss.
Will be merged in shortly to master via https://github.com/silverstripe/silverstripe-framework/pull/5278/
/cc @scott1702 @flashbackzoo

Is this fixed with #5278 now?

Sorry, my description was a bit misleading there: This problem is caused by new code I've merged in with #5278, rather than fixed through it. So it's not fixed yet. @scott1702 any chance you could have a look?

Yep, it's at the top of my open-source todo list.

Possibly replace with #7 http://tobiasahlin.com/spinkit/ but test in IE10 first.


DINOv2 for image feature extraction

Hello, I have a question. I didn't find the reference of 'src->model->dinov2.py'. So, in which file did you import dinov2 model? Haven't you provided the training file?

This work uses hydra and the src.model.dinov2.py was imported through this config and this line in run_inference.py. If you run exactly the same commands in README, it should work.

This work uses hydra and the src.model.dinov2.py was imported through this config and this line in run_inference.py. If you run exactly the same commands in README, it should work.

Ok, cool, I found it, thanks.


Running "move _ steps" followed by "play sound _ until done" never completes

Expected behavior
Please describe what should happen
The stack should un-highlight after running
Actual behavior
Describe what actually happens
The stack stays highlighted after the sound has completed
Steps to reproduce
Explain what someone needs to do in order to see what's described in Actual behavior above
At https://llk.github.io/scratch-gui/ drag out a "move 10 steps" and attach "play sound meow until done" to it.
Run the stack
The cat moves 10 steps and "meow" plays, however the stack remains highlighted after playing
Operating system and browser
Chrome 57, macOS 10.12

It looks like this was caused by our updating to Tone js version 9, which has a new wrapper for the onended callback of bufferSource that doesn't have the behavior we expect. I should be able to use the native audioBufferSourceNode instead.


Miration From AlmaLinux 8.10 failed

Can`t migrate from AlmaLinux 8.10
see attach

https://github.com/oracle/centos2ol/issues/135
-> Add almalinux-release*) ;; to L131
-> Commande : sed -i '131a\    almalinux-release*) ;;' centos2ol.sh


Gate decomposition

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.
Right now, the Amazon Braket provider translates gates from Qiskit to Braket with a hardcoded dicts. This limits the Qiskit operations that can be used in Braket. For example, the circuit
circuit = QuantumCircuit(1)
circuit.prepare_state([1/np.sqrt(2), -1/np.sqrt(2)], 0)

cannot run because StatePreparation is not explicitly in the dict. Likewise,
operator = (Z ^ Z) - 0.1 * (X ^ I)
evo = PauliEvolutionGate(operator, time=0.2)
circuit = SuzukiTrotter().synthesize(evo)

cannot run because of the absence of exponential operators. These circuits can run on Braket provided they are sufficiently decomposed.
Another example of an unsupported gate is the U gate;
circuit = QuantumCircuit(1)
circuit.u(np.pi/2, np.pi/3, np.pi/4, 0)

cannot run, regardless of how many times decompose() is called, because U is the final step of the decomposition; for gates such as these, the decomposition needs to be handled directly.
What is the expected behavior?
Gats should be automatically decomposed to be compatible with Amazon Braket devices, and gates that cannot be made compatible with (built-in) decomposition should be converted in the provider.
Acceptance criteria
A circuit with any standard gate (aside from global phase) should run successfully, as well as each of the circuits described above; these should all be included as test cases.

I am also interested in working on this issue.

Hello, I would also like to be assigned to this project @speller26

I am also interested in this issue @speller26

Since multiple people (@s-aldaihan , @Gmontes01 , @AbdullahKazi500 )  have volunteered for this issue, I will assign it to all of you.
Here are the rules: you can either
A) Work together on this issue and split the bounty (very reasonable idea for a project of this size!)
B) Each work independently and race to the finish line. The first person to submit a working PR (including tests) will win the full bounty.
Please let me know what you each prefer by reacting to to this message with an 🅰 or 🅱 :)
If a subset of hackers react A, I will take that to mean they are forming a team to work on this issue, and if anyone else reacts B, I will take that to mean that hacker is working independently.

I'm happy to collaborate

🅰 I am happy to collaborate as well

@speller26 Hi! Since my fellow Qbrainiacs have already started working on this issue collaboratively, i'd like to work independently on this and race them to the finish line. Can you assign it to me?

@speller26 I ended up working alone to build my code and feel confident in racing towards the end on my own. Can I switch back to working on this on my own?

I don't really want to participate in a race, so happy to tap out.

@Gmontes01 Hm, this is a tough one. Generally we don't want to encourage switching from a team to solo partway through the hackathon.
@AbdullahKazi500 and @s-aldaihan, can you tell me how far along you are in working on this issue? Were you counting on working with a team, or are you okay with doing a race?

Looks like we got the team finally rolling @JordanAWS. I'm happy to join y'all and split the work. Join my discord @s-aldaihan  and @AbdullahKazi500 and we can get started!
Gate Decomp Group
Hopefully this link works!

A couple questions @JordanAWS and @speller26

the decompose() method is found in the qiskit terra source code, so I understand that I will not be able to alter its functionality through a pull request in this branch. Should I focus more on implementing and working around the limitations of the given decompose() method as a step in translating from qiskit to braket?
My handling of my state_preparation() gate relies on the assumption that a qubit is initially in a zero state and I cannot think of any way to properly preparing a known state without first being in a known state. Is there any braket equivalent to qiskit's .reset() operator and if not can we make adding that functionality a different task given that .reset() is a standard operation and not a standard gate so its outside the scope of this branch?
I noticed that global phase is allowed to shift during the handling of other qiskit operations, mainly 'u3' and the new 'u'. Should I be worried about having the proper global phase shift, specifically for my handling of state_preparation() and u()?
I currently plan to test the handling of the state_preparation() gate through translating a 1 qubit gate to braket then running the braket gate on a simulator and confirming the final state vector of the braket gate. Should I take a similar approach to testing the u gate or should something else be taken?

Yes, that is correct.
There isn't a reset operator in Braket today, but from what I can see here, it seems like qiskit.extensions.Initialize requires a reset instruction but StatePreparation doesn't. Are there cases where it is still needed?
What issues do you run into if you try to handle the global phase?
That sounds like a reasonable approach to me.

The main concern that I have about not using a reset instruction is the case where someone alters a qubit's state and then applies the .prepare_state(state_vec) and converts that circuit into a braket circuit. The conversion of this circuit would not prepare the desired state_vec because the braket equivalent of the prepare_state() method applies its transformations to a starting state which is not zero. Thus the adapter would be able to successfully adapt the code

circuit = QuantumCircuit(1)
circuit.prepare_state([1/np.sqrt(2), -1/np.sqrt(2)], 0)

into a braket circuit which prepares the desired state but would fail to produce the desired state from the code
circuit = QuantumCircuit(1)
circuit..x(0).prepare_state([1/np.sqrt(2), -1/np.sqrt(2)], 0)

because the starting position of the qubit 0 would not be in the zero position when the qubit has the transformations associated to prepare_state() applied to it.

I actually have no issues when I handle the global phase. I run into issues when I do not handle the global phase and I am unsure if my handling of the global phase might be extraneous or cause errors somewhere else

Hi!
I have given this issue a try #103 and I would appreciate any guidance or feedback from the maintainers on my approach :). Thank you

@Gmontes01
2. I think it is reasonable to assume that the prepare_state() method if invoked on a circuit with other operations already applied, doesn't yield a circuit with final state as the one specified in prepare_state.
3. Ok, let's try to implement handling global phase for now then and see how we can handle any issues which might arise.

@kshitijc
2. I read up on the qiskit implementation of the prepare_state() method our handling will be consistent with the way qiskit handles the gate so despite there still being a slight problem with the lack of a reset operation I am content having the translated circuit be consistent with qiskit.
3. I implemented global phase handling. Perhaps the phase handling can be done more elloquently with a build in gate for transforming global phase but the issue shows up infrequently enough that I am content just writing it out the two time a global phase shift is needed.
@JordanAWS @speller26
Please let me know how this recent pull request looks and if there is anything I may be missing to earn the UnitaryFund bounty! I'm still fairly new to contributing to open source so I am happy to accept any criticism you may have about my code.

Also ,despite the fact that I was looking to work in a team with @AbdullahKazi500 and @s-aldaihan I ended up doing this whole project alone and feel it is fair that I ask for the whole of the bounty. If you want to talk about the situation we can do so in the team discord that I linked earlier in the chat(which is empty)

Hi @Gmontes01 we did a review of the PR and added comments. If you are able to make the requested modifications to the code, you will win the bounty! Totally fine that you ended up working alone.

@JordanAWS see how this works. I am submitting this before the end of 6/13 AoE time so hopefully I am still eligible for the bounty. I made the requested modifications and expanded the scope of the tests along with highlighting a new bug which would have gone otherwise unnoticed in the previous PR.

Thanks @Gmontes01 ! Yes, since you submitted a PR with the main functionality before the June 13 deadline, you are indeed eligible for the bounty. We will likely do a few more review cycles between now and June 20th (the deadline to get the PRs from UnitaryHACK merged) :)

Now https://github.com/qiskit-community/qiskit-braket-provider/pull/111 has been merged. Thank you so much for your contribution @Gmontes01!


q_lvq

Why:
Closes [issue link]

What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

On 7 May 2022, at 9:53 am, github-actions[bot] @.***> wrote:

Automatically generated comment ℹ
This comment is automatically generated and will be overwritten every time changes are committed to this branch.
The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.
Content directory changes
You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.
Source	Preview	Production	What Changed
codespaces/overview.md
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.


Default dirname to file name

The default filename is "slides.md" (or similar) and the default target directory is "slides".
When you choose a different file name "myslides.md", it would be nice to change the default directory name to "myslides.md".
The implementation is only a few lines of change. But I like having the default directory name display as slides. My implementation got rid of the display of the default directory. Was hoping you'd have a better suggestion.
Thanks

I like the idea of:

slides.md -> slides/
google-talk.md -> google-talk/

That makes good sense to me.
I'll take a look shortly.

:wrench: I also want support for multiple files, so that may modify this a bit (will bring in pr shortly)

issue handled by 54


Add 'reload scene' button in the mini-map menu button

As the connection status panel will be hidden for the beta client the reload scene action will turn inaccessible for users.
The solution is to finally develop the menu of the scene which can be opened from the mini-map.

Disclaimers:
For the moment, adding the reload scene option is enough.
The menu button UI already exist in the mini-map prefab.
The context menu of a scene already exist in the explorer project. It is called SideMenu.
Figma file

This panel should be disabled in non debug build for favour of the context menu


Get role id by name

Suggestion: you're missing the standard name of the branches, we are following the next convention
e.x:
feat/[ticket number or whatever we're doing]
feat/EX-1 // ticket number"
feat/get-id-role


Fix drop of const qualifier

The parameter got "const" in 9fdcc21fdc9 but that was not added
to cast. So this throws a -Wcast-qual in user code.
error: cast from 'const DUMMY *' to 'ASN1_VALUE_st *' drops const qualifier [-Werror,-Wcast-qual]
CLA: trivial

This pull request is ready to merge

Merged to master.  Thanks for the fix.


Edge API Migration

Edge Migration Plan
SDK v2
All SDKs will point to edge.api.flagsmith.com by default. We then need to do some coordination around when we release them. Basically release the v2 SDKs when all the edge stuff below is done and in place.
For New Customers
Default to write all identities and environments to DynamoDB from the outset.
For Existing Customers
Write a Lambda that copies Identities from Core to Edge API
Create a new button in the Project level settings page that triggers a copy of all their Identity data from Core API to Edge API using above Lambda.
Don't let the user press the button again.
Dealing with requests to Core API when they have been migrated to Edge
Have a period of time (3 months?) where we copy all Core API Identity writes through to the Edge API. This will be the time that customers can redirect their apps to edge

Tasks

Write code to migrate individual identities to dynamo on requests to /identities (and /traits?) if migration has been completed
Add button to dashboard to allow users to migrate a project's identities to dynamo

@gagantrivedi working on items 3 & 4 in list above today. These involve changing project metadata structure. Once this is done, we can look at migrating larger clients.


Add a readme about feature metered for sp-utils

This PR adds a readme about feature metered for sp-utils.

As these readmes are generated from the lib.rs files

How? Where is the script?

At least it was done once. I would assume that this is done for every release. Nevertheless, it is still good to also have this in the official docs of the crate.

cargo-readme geterates the previous version of readme. I will fix it. However there is no CI job to check readmes...

bot merge


[Bug]: Digital Voucher problem posting sale & purchase

Describe the issue
Microsoft implemented new functionality in connection with the new bookkeeping act in Denmark in Business Central version 24.2.
In connection with this, companies were stopped in posting sales & purchase if no incoming documents are attached.
Sales
It is possible to setup, that the system have to generate a document automatically and then it is possible to post.
The problem is that the normal invoice attachment is attached + a corresponding attachment called DigitalVoucher.
Can you please make an adjustment that makes it possible to avoid this?
Purchase
You are forced to attach incoming document when posting purchase order/invoice/credit memo or posting general journal with account type "Vendor". I know it will be a requirement, but as you see at the link below described by "Erhvervsstyrelsen" not all companies forced to do so yet (as I understand it).
Can you please tell me why it is required for all companies now or if it is possible to disable until it will be required?
https://erhvervsstyrelsen.dk/tidsplan-for-virksomheders-digitale-bogfoering

Thank you in advance.
Expected behavior
Not possible to post sale & purchase
Steps to reproduce

Open "Sales order", "Purchase Order" or "General Journal with account type Vendor".
Post document.
If no incoming document has been attached you will get an error.

Additional context
No response
I will provide a fix for a bug

[X] I will provide a fix for a bug

Thank you very much for the detailed report and your suggestion to address the issue. However, I am happy to tell you that we've already hotfixed the issue and that you should receive a fix in the near future. You can get more details here: https://www.yammer.com/dynamicsnavdev/#/threads/show?threadId=2869519068225536


Bump alertmanager to v0.25.0

https://github.com/prometheus/alertmanager/releases/tag/v0.25.0

Thanks for contribution!


added missing function db._transactions(), and equivalent REST API route GET /_api/transaction

Scope & Purpose
Added missing function db._transactions() plus REST route GET /_api/transaction

[x] Bug-Fix for devel-branch (i.e. no need for backports?)
[x] The behaviour change can only be verified via automatic tests

Related Information

[x] There is an internal planning ticket: https://github.com/arangodb/release-3.5/issues/83

Testing & Verification
This PR adds tests that were used to verify all changes:

[x] Added new integration tests (i.e. in shell_server / shell_server_aql)

https://jenkins01.arangodb.biz/view/PR/job/arangodb-matrix-pr/5419/
Documentation

[x] Added a new section in the http API
[x] Added Swagger examples for the http API

https://jenkins01.arangodb.biz/view/PR/job/arangodb-matrix-pr/5430/

https://jenkins01.arangodb.biz/view/PR/job/arangodb-matrix-pr/5433/

https://jenkins01.arangodb.biz/view/PR/job/arangodb-matrix-pr/5436/

https://jenkins01.arangodb.biz/view/PR/job/arangodb-matrix-pr/5438/

Fixed MMFiles dead lock:
https://jenkins01.arangodb.biz/view/PR/job/arangodb-matrix-pr/5445/


Romanian Translation

Added the translation and the resource line in appxmanifest file. The first two commits was accidental as it's the first time I created a folder in the fork.

Thanks for the contribution.


Not making slug unique

Sql throw error for duplicate slug in slug field that means it didn't make slug unique. If there exists the same slug it should have use suffix right? but it didn't ... in sluggable.php  I have made true for includetrahsed also.
Note: Although I have created my own slug creation method (function) ... Should I write code to check unique slug on database or it will do that part itself?

Can you post your config file, and the relevant parts of your model and/or slug creation function?

config/sluggable.php
return [
/**
 * What attributes do we use to build the slug?
 * This can be a single field, like "name" which will build a slug from:
 *
 *     $model->name;
 *
 * Or it can be an array of fields, like ["name", "company"], which builds a slug from:
 *
 *     $model->name . ' ' . $model->company;
 *
 * If you've defined custom getters in your model, you can use those too,
 * since Eloquent will call them when you request a custom attribute.
 *
 * Defaults to null, which uses the toString() method on your model.
 */

'source' => null,

/**
 * The maximum length of a generated slug.  Defaults to "null", which means
 * no length restrictions are enforced.  Set it to a positive integer if you
 * want to make sure your slugs aren't too long.
 */

'maxLength' => null,

/**
 * If you are setting a maximum length on your slugs, you may not want the
 * truncated string to split a word in half.  The default setting of "true"
 * will ensure this, e.g. with a maxLength of 12:
 *
 *   "my source string" -> "my-source"
 *
 * Setting it to "false" will simply truncate the generated slug at the
 * desired length, e.g.:
 *
 *   "my source string" -> "my-source-st"
 */

'maxLengthKeepWords' => true,

/**
 * If left to "null", then use the cocur/slugify package to generate the slug
 * (with the separator defined below).
 *
 * Set this to a closure that accepts two parameters (string and separator)
 * to define a custom slugger.  e.g.:
 *
 *    'method' => function( $string, $sep ) {
 *       return preg_replace('/[^a-z]+/i', $sep, $string);
 *    },
 *
 * Otherwise, this will be treated as a callable to be used.  e.g.:
 *
 *    'method' => array('Str','slug'),
 */

'method' => function( $string, $sep ) {
    return make_slug($string);
},

/**
 * Separator to use when generating slugs.  Defaults to a hyphen.
 */

'separator' => '-',

/**
 * Enforce uniqueness of slugs?  Defaults to true.
 * If a generated slug already exists, an incremental numeric
 * value will be appended to the end until a unique slug is found.  e.g.:
 *
 *     my-slug
 *     my-slug-1
 *     my-slug-2
 */

'unique' => true,

/**
 * If you are enforcing unique slugs, the default is to add an
 * incremental value to the end of the base slug.  Alternatively, you
 * can change this value to a closure that accepts three parameters:
 * the base slug, the separator, and a Collection of the other
 * "similar" slugs.  The closure should return the new unique
 * suffix to append to the slug.
 */

'uniqueSuffix' => null,

/**
 * What is the first suffix to add to a slug to make it unique?
 * For the default method of adding incremental integers, we start
 * counting at 2, so the list of slugs would be, e.g.:
 *
 *   - my-post
 *   - my-post-2
 *   - my-post-3
 */
'firstUniqueSuffix' => 2,

/**
 * Should we include the trashed items when generating a unique slug?
 * This only applies if the softDelete property is set for the Eloquent model.
 * If set to "false", then a new slug could duplicate one that exists on a trashed model.
 * If set to "true", then uniqueness is enforced across trashed and existing models.
 */

'includeTrashed' => false,

/**
 * An array of slug names that can never be used for this model,
 * e.g. to prevent collisions with existing routes or controller methods, etc..
 * Defaults to null (i.e. no reserved names).
 * Can be a static array, e.g.:
 *
 *    'reserved' => array('add', 'delete'),
 *
 * or a closure that returns an array of reserved names.
 * If using a closure, it will accept one parameter: the model itself, and should
 * return an array of reserved names, or null. e.g.
 *
 *    'reserved' => function( Model $model) {
 *      return $model->some_method_that_returns_an_array();
 *    }
 *
 * In the case of a slug that gets generated with one of these reserved names,
 * we will do:
 *
 *    $slug .= $separator + "1"
 *
 * and continue from there.
 */

'reserved' => null,

/**
 * Whether to update the slug value when a model is being
 * re-saved (i.e. already exists).  Defaults to false, which
 * means slugs are not updated.
 *
 * Be careful! If you are using slugs to generate URLs, then
 * updating your slug automatically might change your URLs which
 * is probably not a good idea from an SEO point of view.
 * Only set this to true if you understand the possible consequences.
 */

'onUpdate' => false,

/**
 * If the default slug engine of cocur/slugify is used, this array of
 * configuration options will be used when instantiating the engine.
 */
'slugEngineOptions' => [],

];
my custom function
function make_slug($string,$sep='-'){
$a = ['@','`','~','^','&','*','_','&','%','#','$',];
$string = str_replace(' ',$sep,str_replace('\',$sep,str_replace($a,'',trim($string))));
$a=[',',':',';','.','(',')','!','[',']','?','/',''','"','','','',];
$string = str_replace($a,$sep,$string);
$string = str_replace($sep.$sep,$sep,$string);
$string = str_replace($sep.$sep,$sep,$string);
$string = str_replace($sep.$sep,$sep,$string);
$string = trim($string,$sep.$sep);
$string = trim($string,$sep);
$string = trim($string,$sep);
return $string;
}

@cviebrock  Please help

A few things I notice:

In your config:

'source' => null,

So you have no explicit source string for your model's slugs.  It will then use the toString() method on your model.  Is that defined anywhere?  In general, I suggest you be explicit about the fields you want to use for the slug, e.g.
'source' => 'title'

Your custom function is:

function make_slug($string,$sep='-'){

but your config says:
 'method' => function( $string, $sep ) {
        return make_slug($string);
    },

I think you forgot to add the $sep parameter to that call.

For 'source' I have mentioned in Model.
& make_slug function has default '-' in $sep so it is ok I think. Again I found error for duplicate slug :(

I found the reason :) it is because of lower and upper case issue.

For my case I had 'static' keyword in model event callback like following.
static::saving(static function(Post $post) {}
When I removed 'static' keyword then SlugService::createSlug() was able to generate and save unique slug.
Thanks


Restarting kills forked processes, even if they are detached

In node you can spawn processes and detach them so that they keep running when the parent dies, or when the parent restarts. I have a package which does this to keep IRC clients running if their parent processes need to restart.
You can do it by setting the detached boolean to true in the child_process.spawn function and then calling child.unref() see: http://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_options
In a normal use case my process doesn't need to restart any child processes when the main one dies or restarts, however when running it with forever, the children die when the main process is restarted even if it's detached.
I'll try to offer a means to replicate this problem because my current stack is quite large, however the package is at https://github.com/ircanywhere/irc-factory, cloning the repo and running node examples/persistent.js will prove that a child process can be disconnected from the main even if it dies (you'll have to go to freenode and /whois the irc client made). But if you run it with forever start examples/persistent.js and try a forever restartall it'll restart both processes.
This is not really ideal, I'm guessing it's something to do with forever taking a note of the children it's spawned and restarting them aswell, unless there is a setting to avoid this happening?

By default forever-monitor has killTree set to true which will use the ps-tree module to kill all child processes spawned by the any process forever spawns regardless of the detached state.
You can disable this behavior by running:
forever start --no-killTree ./my-script-that-spins-up-detached-child-procs.js


dbsnp reference file download fails

Hi,
I'm installing bcbio_nextgen using the "Isolated installations" instructions (https://bcbio-nextgen.readthedocs.org/en/latest/contents/installation.html#isolated-installations).
The genome installation for either GRCh37 or hg19 produces the following error:
[localhost] local: mkdir -p /home/people/nikossi/software/bcbio_nextgen/genomes/Hsapiens/hg19/variation
[localhost] local: pwd
[localhost] local: echo $HOME
[localhost] local: mkdir -p '/home/people/nikossi/tmp/cloudbiolinux/6621947b-0955-3422-a9da-44e4cd2046d9'
[localhost] local: wget --continue --no-check-certificate -O dbsnp_138.hg19.vcf.gz<EMAIL_ADDRESS>--2015-10-19 15:55:40--<EMAIL_ADDRESS>=> 'dbsnp_138.hg19.vcf.gz'
Resolving ftp.broadinstitute.org (ftp.broadinstitute.org)... <IP_ADDRESS>
Connecting to ftp.broadinstitute.org (ftp.broadinstitute.org)|<IP_ADDRESS>|:21... connected.
Logging in as gsapubftp-anonymous ...
Login incorrect.
Warning: local() encountered an error (return code 6) while executing 'wget --continue --no-check-certificate -O dbsnp_138.hg19.vcf.gz<EMAIL_ADDRESS>Happens both when I ran:
python bcbio_nextgen_install.py /path_to_bcbio --tooldir=/path_to_bcbio --isolate
--genomes GRCh37 --aligners bwa --aligners bowtie2 --aligners rtg --distribution centos
and later when I installed without the '--genomes' parameter:
bcbio_nextgen.py upgrade --genomes hg19 (or GRCh37)
Do you have any ideas on how to work around it?
Bests,
Nikos

Nikos;
Sorry about the problem. The download is trying to retrieve files from the Broad GATK server and it looks like right now it has too many users. Unfortunately the FTP only allows 25 concurrent users. You can see more details here:
http://gatkforums.broadinstitute.org/discussion/1215/how-can-i-access-the-gsa-public-ftp-server
My best suggestion is to wait a bit and retry and hopefully it'll be available. You can just retry the wget command (or click on the link on the GATK page above) to test, and then re-run the install command whenever it works again. Sorry to not have a better solution than waiting and checking but hope this helps.

It is very helpful indeed, I wouldn't have guessed it otherwise.
Thank you!


Setting CUDA function attributes

RawKernel is very useful, but currently there appears to be no interface to set the CUDA function attributes.
This is necessary in order to use more than 48KB of shared memory per block in newer GPUs, or to specify the ratio of shared memory to L1 cache (ie, the shared memory "carveout").
Overview of shared memory configuration:
https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#shared-memory-7-x
cudaFuncSetAttribute documentation:
https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__HIGHLEVEL.html#group__CUDART__HIGHLEVEL_1g422642bfa0c035a590e4c43ff7c11f8d

If the attributes are settable, then they can also be read via PR #1874 (not merged yet). In fact I think a PR for this feature request is possible based on #1874.

Yeah, this would be a good followup to #1874.
It looks like there are currently only two attributes that can be assigned:
cudaFuncAttributeMaxDynamicSharedMemorySize
cudaFuncAttributePreferredSharedMemoryCarveout
The range for these needs to be constrained to cudaDevAttrMaxSharedMemoryPerBlockOptin and cudaDevAttrMaxSharedMemoryPerMultiprocessor, respectively. In current master, it is now possible to query these device attributes via code such as:
import cupy
d = cupy.cuda.device.Device()
d.attributes['MaxSharedMemoryPerBlockOptin']
d.attributes['MaxSharedMemoryPerMultiprocessor']

Thank you for tagging the related issue, that gave me a huge head start!
Maybe it is more pythonic for the CUDA function attributes to be properties of the object returned by RawKernel.attributes (or properties of RawKernel itself)?
The writeable attributes could have setters for the corresponding properties.
I followed this approach starting with the pull request from @grlee77 and now have something that works for me. Will submit a pull request later today so you can take a look.

Example usage:
op.fun.attributes.preferred_shared_memory_carveout = 75
op.fun.attributes.max_dynamic_shared_size_bytes = 48*1024

print('num_regs', op.fun.attributes.num_regs)
print('max_dynamic_shared_size_bytes', op.fun.attributes.max_dynamic_shared_size_bytes)
print('preferred_shared_memory_carveout', op.fun.attributes.preferred_shared_memory_carveout

The implementation is simpler still using descriptors:
class FunctionAttributes:

    class Read:
        def __init__(self, func_attribute):
            self.func_attribute = func_attribute

        def __get__(self, instance, owner):
            return driver.funcGetAttribute(self.func_attribute, instance.kern.ptr)

    class ReadWrite(Read):
        def __set__(self, instance, value):
            driver.funcSetAttribute(instance.kern.ptr, self.func_attribute, value)

    shared_size_bytes = Read(driver.CU_FUNC_ATTRIBUTE_SHARED_SIZE_BYTES)
    const_size_bytes = Read(driver.CU_FUNC_ATTRIBUTE_CONST_SIZE_BYTES)
    local_size_bytes = Read(driver.CU_FUNC_ATTRIBUTE_LOCAL_SIZE_BYTES)
    max_threads_per_block = Read(driver.CU_FUNC_ATTRIBUTE_MAX_THREADS_PER_BLOCK)
    num_regs = Read(driver.CU_FUNC_ATTRIBUTE_NUM_REGS)
    ptx_version = Read(driver.CU_FUNC_ATTRIBUTE_PTX_VERSION)
    binary_version = Read(driver.CU_FUNC_ATTRIBUTE_BINARY_VERSION)
    cache_mode_ca = Read(driver.CU_FUNC_ATTRIBUTE_CACHE_MODE_CA)
    max_dynamic_shared_size_bytes = ReadWrite(driver.CU_FUNC_ATTRIBUTE_MAX_DYNAMIC_SHARED_SIZE_BYTES)
    preferred_shared_memory_carveout = ReadWrite(driver.CU_FUNC_ATTRIBUTE_PREFERRED_SHARED_MEMORY_CARVEOUT)

    def __init__(self, kern):
        self.kern = kern

Maybe it is more pythonic for the CUDA function attributes to be properties of the object returned by RawKernel.attributes (or properties of RawKernel itself)?

@andravin, It was request by a core dev to return a dict instead of attributes: https://github.com/cupy/cupy/pull/1874#discussion_r260107783

Well I thought I would just check in the code that works for me to see if it is useful to somebody else. You can do whatever you want with it.
One obvious advantage that properties have is that they can be set. If you return attributes as a dictionary, then you will also need a different interface for setting attributes. Makes sense just to use the standard python design pattern for getting and setting attributes instead.
Also, returning a dictionary is less efficient, because the whole dictionary is populated by calling driver.funcGetAttribute repeatedly, even if the user only wanted a single attribute. Using properties, you just pay for what you use.
While I am commenting on it, I don't think it makes sense for cuda.device.attributes to return a dictionary either.  That function dynamically populates the list of attributes, which is nice, but you could do that with properties and descriptors too, and it could be done at module import time instead of every time attributes is called for a new device. Basically a lot of extra work is being done to provide a less pythonic interface.
Anyway feel free to use any of my commits in any way they are useful. I might make some more changes in my fork to see how I like them. I suspect one way to clean up all this attributes stuff without breaking backwards compatibility is to add the "properties" directly to the RawKernel and Device classes. It makes literal sense that function-attributes should be properties of the RawKernel class, and device-attributes should be properties of the Device class.
Then the attributes property could be deprecated.
By the way, here is the best documentation I have found on python descriptors: https://docs.python.org/3/howto/descriptor.html
Anyway I hope this is useful.

Just to add a bit more background: without the proposed solution (#2120) we are unable to request full shared memory that newer devices can provide (in my case it's 96 KB=98304 bytes):
In [38]: add_kernel((5,), (5,), (x1, x2, y, 25), shared_mem=98304)
---------------------------------------------------------------------------
CUDADriverError                           Traceback (most recent call last)
<ipython-input-38-a21f3e428b68> in <module>()
----> 1 add_kernel((5,), (5,), (x1, x2, y, 25), shared_mem=98304)

/home/leofang/test/cupy2/cupy/core/raw.pyx in cupy.core.raw.RawKernel.__call__()

/home/leofang/test/cupy2/cupy/cuda/function.pyx in cupy.cuda.function.Function.__call__()

/home/leofang/test/cupy2/cupy/cuda/function.pyx in cupy.cuda.function._launch()

/home/leofang/test/cupy2/cupy/cuda/driver.pyx in cupy.cuda.driver.launchKernel()

/home/leofang/test/cupy2/cupy/cuda/driver.pyx in cupy.cuda.driver.check_status()

CUDADriverError: CUDA_ERROR_INVALID_VALUE: invalid argument

Closing due to lack of interest.

This issue is addressed, see #2369.


misc: Docstring updates

Started updating the docstrings for the website. Just want to check I am doing it correctly before I finish them...

Looks all good to me.
FYI, if you clone the website repo, you can render it locally to check if it looks like what you want

@ZoeLeibowitz do you plan on making more change or should this be merged?

Ok thanks, let us know when it's ready

Ok thanks, let us know when it's ready

Hi, since I am not 100% sure, I will not make more changes

ah yes there are now some conflicts in dense.py

Ah yes, I think it should be fixed now but could you trigger the CI to check please?

Thanks, landing!


[Exoplayer] DownloadHelper.createMediaSource not supporting MP4 file

Media3 Version
ExoPlayer 2.18.4
Devices that reproduce the issue
Pixel 6
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
No
Reproduction steps
You can find my module here https://github.com/yoobi/exoplayer-kotlin/tree/master/downloadvideo

Download the MP4 file (latest one in the list)
Click on the floating button once download is complete
Click on the downloaded video
Get the error in logs

This issue only appears when trying to play downloaded MP4 video, if you download an M3U8 video and then do the same steps above it does play.
To create the mediaSource of the downloaded video I use:
DownloadHelper.createMediaSource(downloadRequest, DownloadUtil.getReadOnlyDataSourceFactory(this)) which I thought was the standard way of playing downloaded video.
Expected result
Downloaded video to play.
Actual result
E/ExoPlayerImplInternal: Playback error
      com.google.android.exoplayer2.ExoPlaybackException: Source error
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleIoException(ExoPlayerImplInternal.java:644)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:614)
        at android.os.Handler.dispatchMessage(Handler.java:102)
        at android.os.Looper.loopOnce(Looper.java:201)
        at android.os.Looper.loop(Looper.java:288)
        at android.os.HandlerThread.run(HandlerThread.java:67)
     Caused by: com.google.android.exoplayer2.source.UnrecognizedInputFormatException: None of the available extractors () could read the stream.
        at com.google.android.exoplayer2.source.BundledExtractorsAdapter.init(BundledExtractorsAdapter.java:92)
        at com.google.android.exoplayer2.source.ProgressiveMediaPeriod$ExtractingLoadable.load(ProgressiveMediaPeriod.java:1017)
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:412)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
        at java.lang.Thread.run(Thread.java:1012)

Media
https://storage.googleapis.com/exoplayer-test-media-0/BigBuckBunny_320x180.mp4
Bug Report

[ ] You will email the zip file produced by adb bugreport to<EMAIL_ADDRESS>after filing this issue.

Any updates ?


[2.5] skip remove nodes for non-custom cluster

We should skip deleting k8s cluster node for non-custom cluster. We add a formatter function to remove delete node actions for non-custom cluster here but not skip it in node controller.
https://github.com/rancher/rancher/issues/32284

wait for fix


Emit error or authstate on logout?

Hello there,
angularfire.auth.subscribe does not emit any events on logout. Is this the way it's suppoused to work?

Yes it does, it emits null.

Closed per @aguzubiaga answer.
We are considering adding a .exists() method onto snapshots and authData objects.


fix build for i386

Here's the message, wasn't sure the best way to fix it:
crystal $ make FLAGS='--cross-compile --target=i386-linux-gnu'
Using /usr/bin/llvm-config-7 [version= 7.0.0]
CRYSTAL_CONFIG_BUILD_COMMIT="0fac5d5b0" CRYSTAL_CONFIG_PATH='$ORIGIN/../share/crystal/src' SOURCE_DATE_EPOCH="1665770035"  CRYSTAL_CONFIG_LIBRARY_PATH='$ORIGIN/../lib/crystal' ./bin/crystal build --cross-compile --target=i386-linux-gnu -D strict_multi_assign -Dwithout_interpreter  -o .build/crystal src/compiler/crystal.cr -D without_openssl -D without_zlib
Showing last frame. Use --error-trace for full trace.

In src/gc/boehm.cr:217:11

 217 | Stats.new(
             ^--
Error: no overload matches 'GC::Stats.new', heap_size: UInt32, free_bytes: UInt32, unmapped_bytes: UInt32, bytes_since_gc: UInt32, total_bytes: UInt32

Overloads are:
 - GC::Stats.new(heap_size : UInt64, free_bytes : UInt64, unmapped_bytes : UInt64, bytes_since_gc : UInt64, total_bytes : UInt64)
Makefile:187: recipe for target '.build/crystal' failed
make: *** [.build/crystal] Error 1

I think it's better to cast to 64-bit integers in order to keep a stable interface of GC::Stat.

To add some context: GC::Stats must not change, but LibGC::Stats should (as it does already with a platform-dependent field type), and GC.stats should call the integer conversion methods to extend the lib struct values so that it could work with -Dno_number_autocast.
Also GC::ProfStats needs the same treatment.


Support overriding of build dir

At this time in this lib we can override only dir where store golden images throw outputDirectoryPath param of RoborazziRule.Options, but reports/test-results and outputs of comparing every time save in {app_module}/build/. As example in my project with multi modules we have single point of build dirs in root of project like build/module_build/{module}/{outputs/reports/test_results/} where store all building artefacts. I wanna saved files from robarazzi in this folder too. Now implementation is hardcode with constants dirs. My suggest make this more flexible and support override root of build dir for lib. What do  you think about this?

Thank you for your proposal. I believe it's a convenient idea; however, it may present some difficulties. This is because the reports/test-results/roborazzi/results/ files are utilized for creating a summary file, and merging the folder would prevent us from making a summary file for the module. We could consider making the summary file path customizable. Would that solution work for you?

Got it, we need to make the path in RoborazziReportConst flexible, based on Gradle's build directory settings. This means we'll adjust the paths for test results to match the Gradle configuration, like build/module_build/{module_name}/test-results/roborazzi/results-summary.json. To do this, we need to pass the build directory from Gradle to our tests. I'll explore how we can implement this effectively.


save button appears only when user edits record

Closes #92
🛠 Fixes Issue : "#92"
👨💻 Changes proposed:
Button was being created whenever user creates a report, Implemented a new function that is only called when user edits a report

[x] My code follows the code style of this project.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.
[x] I am a participant of Hacktoberfest 2023.

📷 Screenshots

Thank you for the contribution.✨


add subnet/ippool terminating phase check for auto-created IPPool

Describe the bug
In current Spidepool-controller we don't check terminating phase SpiderSubnet or SpiderIPPool, so we may still try to scale the IPPool.

{"level":"ERROR","ts":"2022-10-27T01:40:49.488Z","logger":"SpiderIPPool-Informer","caller":"ippoolmanager/ippool_informer.go:83","msg":"leader lost, SpiderIPPool informer broken"}
{"level":"ERROR","ts":"2022-10-27T01:40:49.681Z","logger":"Subnet-Manager","caller":"subnetmanager/subnet_controller.go:67","msg":"subnet manager controllers broken"}


.image.label in .list > .item loses right padding

There lots of easy custom fix to this, but wanted to point it out anyway.
I wanted to stack labels with images in a list ... but because of this declaration
if I do something like this

            @{{username}}
            {{#if userCanRemove _id}}

            {{/if}}

```

Then my `.ui.image.blue.label` will inherit `padding-right: 0em`

![screen shot 2015-07-21 at 4 26 58 pm](https://cloud.githubusercontent.com/assets/3354585/8811655/5570b814-2fc5-11e5-9d40-177e4f4804c8.png)

Thanks this is clear


Sentence correction in README

Related Issue(required)
Very small spell correction so no issue is required

Description(required)
Just replace This package is converted -> This package converts

Review Procedure(required)
Just look at it

Related PR(optional)

Pre-Review Checklist for the PR Author
PR Author should check the checkboxes below when creating the PR.

[ ] Read commit-guidelines
[x] Assign PR to reviewer

If you are adding new package following items are required:

[ ] Documentation with description of the package is available
[ ] A sample launch file and parameter file are available if the package contains executable nodes

Checklist for the PR Reviewer
Reviewers should check the checkboxes below before approval.

[ ] Commits are properly organized and messages are according to the guideline
[ ] PR title describes the changes

Post-Review Checklist for the PR Author
PR Author should check the checkboxes below before merging.

[ ] All open points are addressed and tracked via issues or tickets

CI Checks

Build and test for PR / build-and-test-pr: Required to pass before the merge.
Build and test for PR / clang-tidy-pr: NOT required to pass before the merge. It is up to the reviewer(s). Found false positives? See the [guidelines][clang-tidy-guidelines].
Check spelling: NOT required to pass before the merge. It is up to the reviewer(s). See here if you want to add some words to the spell check dictionary.

Please change the title to follow https://www.conventionalcommits.org/.


Consider not overriding foreground color for the region face

For comparison:

We were working in parallel here. Fixed in https://github.com/cpaulik/emacs-material-theme/commit/22872e31585f168370b3ca737865553a04f8fc23

Fastest fix ever.


Typo fix

Typo fix
Typo fix in code, the dot should be inside the string.
Suggested Reviewers
@BillWagner

Thank you for correcting this typo, @B3zo0. We'll merge your PR now. Changes should appear live on docs.microsoft.com in the next day or two.


tuning as searchprocess still does not have a good schematic graphic

it is not super-bad, but it could be better
maybe even with an animation

which graphic does this refer to? what is bad about it? what should be better?

we have this now, see also tuning paper


✨ [New Demo Request]: Intersection Observer API

Please include the request by answering these questions.
What is the Example and Demo Topic?
Intersection Observer API
Any Links, Reads?
https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API
If you are picking up this request to implement, PLEASE READ THIS

HOW TO ADD A DEMO

assign me this


ISPN-11282 CLI: site command isn't working properly

https://issues.redhat.com/browse/ISPN-11282
It was using CliCommand.NAME instead of Site.NAME. I changed Site.NAME => Site.SITE_NAME to avoid confusion.
Updated the help message.

Thanks @pruivo


Error in qr_painter (assigning Future to Image)

First of all, I want to thank you @lukef for this great library.
I got the following error while trying to use the 1.1.6 version

Compiler message:
file:///C:/src/flutter/.pub-cache/hosted/pub.dartlang.org/qr_flutter-1.1.6/lib/src/qr_painter.dart:101:25: Error: A value of type 'Future' can't be assigned to a variable of type 'Image'.
'Future' is from 'dart:async'.
'Image' is from 'dart:ui'.
Try changing the type of the left hand side, or casting the right hand side to 'Image'.
toPicture(size).toImage(size.toInt(), size.toInt());

Trying 1.1.5 gives another error that toByteData method doesn't exist.

Please read the docs


"MouseDriver" class might cause the touchpad driver of a laptop to freeze or crash

Generally,
big parts of the program were rewritten which means the bug probably disappeared but there is no guarantee at all.

I close this issue as it didn't appear anymore for weeks..
I don't know the reason but in the last weeks I actually completely rewrote essential parts of the API.

I close this issue as it didn't appear anymore for weeks..
I don't know the reason but in the last weeks I actually completely rewrote essential parts of the API.


Bring back Codecov

What is making it safer than before?

The Codecov action now has a checksum verification, so it should not create problems anymore.


Update for Wagtail 3.0

Update for Wagtail v3.0
Following the release of Wagtail 3.0 this work implements the changes required for 3.0 compatibility and also maintains backwards compatibility to >= 2.15

Testing

[x] CI passes
[x] If necessary, tests are added for new or fixed behaviour
[x] These changes do not reduce test coverage

Documentation.

[x] This PR adds or updates documentation
[ ] Documentation changes are not necessary because:

I will be testing this on a live setup as well and will update here.

Codecov Report

Merging #157 (34e875d) into main (9b07de5) will increase coverage by 0.57%.
The diff coverage is 79.54%.

@@            Coverage Diff             @@
##             main     #157      +/-   ##
==========================================
+ Coverage   65.05%   65.63%   +0.57%
==========================================
  Files          32       32
  Lines        1265     1289      +24
  Branches      228      228
==========================================
+ Hits          823      846      +23
- Misses        400      401       +1
  Partials       42       42

Impacted Files
Coverage Δ

wagtail_wordpress_import/apps.py
100.00% <ø> (ø)

wagtail_wordpress_import/block_builder_defaults.py
84.47% <ø> (ø)

...gtail_wordpress_import/handle_inline_shortcodes.py
88.23% <ø> (ø)

wagtail_wordpress_import/importers/apps.py
0.00% <ø> (ø)

...import/management/commands/analyze_html_content.py
0.00% <ø> (ø)

..._import/management/commands/analyze_xml_content.py
0.00% <0.00%> (ø)

...mport/management/commands/delete_imported_pages.py
0.00% <0.00%> (ø)

...wordpress_import/management/commands/import_xml.py
93.75% <ø> (ø)

...wordpress_import/management/commands/reduce_xml.py
32.30% <0.00%> (ø)

...gtail_wordpress_import/prefilters/bleach_filter.py
66.66% <ø> (-1.52%)
:arrow_down:

... and 11 more

Continue to review full report at Codecov.

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

Hey @nimasmi Hope you don't mind me nudging about the review here. I'm thinking we'll need to get an update for Wagtail 4 soon 😄 Cheers

Thanks @nimasmi for the code review.
I'll get this merged and release as soon as I can.


Wrong icon. Wrong .desktop file.

This happens with any program that has multiple .desktop files, including Thunar and emacs. I'll explain on Thunar example.
Thunar file manager has 4 different .desktop files:
> ls /usr/share/applications | grep -i thunar
thunar-bulk-rename.desktop
thunar-settings.desktop
thunar-volman-settings.desktop
thunar.desktop

When I start thunar.desktop, which contains Exec=thunar %U, regular Thunar is started, but (probably due to the same bug I am describing), icon already differs from what nwg-drawer is showing.
If I pin this dock icon, it is stored in .cache/nwg-dock-pinned as 'thunar'. When I click on this icon to start Thunar, first .desktop file (partial match?) is executed, so it starts Exec=thunar --bulk-rename %F as defined in thunar-bulk-rename.desktop, probably because it is alphabetically first to find.
I am aware it may be tricky to figure out what .desktop file is most adequate for the pinned dock icon or running program, but current matching makes dock unusable -- resulting in wrong icon and wrong .desktop file being run.

Partial solution for the launcher problem would be to be able to pin exact .desktop file in .cache/nwg-dock-pinned but that doesn't solve the problem of showing the wrong icon. I am not sure what is possible here, if I can help with something just let me know.

What the dock only knows about running clients are their class names, as reported by Hyprland. In the case of thunar, thunar-bulk-rename and thunar-settings, it's exactly the same string: "Thunar".
❯ hyprctl clients
Window 5a31020b4740 -> piotr - Thunar:
	mapped: 1
	hidden: 0
	at: 2484,965
	size: 1272,682
	workspace: 4 (4)
	floating: 0
	monitor: 1
	class: Thunar
	title: piotr - Thunar
	initialClass: Thunar
	initialTitle: piotr - Thunar
	pid: 47246
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenmode: 0
	fakefullscreen: 0
	grouped: 0
	swallowing: 0
	focusHistoryID: 3

Window 5a310215ebe0 -> Wsadowe zmienianie nazw:
	mapped: 1
	hidden: 0
	at: 2484,275
	size: 1272,682
	workspace: 4 (4)
	floating: 0
	monitor: 1
	class: Thunar
	title: Wsadowe zmienianie nazw
	initialClass: Thunar
	initialTitle: Wsadowe zmienianie nazw
	pid: 47246
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenmode: 0
	fakefullscreen: 0
	grouped: 0
	swallowing: 0
	focusHistoryID: 1

Window 5a310208e7c0 -> Preferencje:
	mapped: 1
	hidden: 0
	at: 2676,581
	size: 798,586
	workspace: 4 (4)
	floating: 1
	monitor: 1
	class: Thunar
	title: Preferencje
	initialClass: Thunar
	initialTitle: Preferencje
	pid: 47246
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenmode: 0
	fakefullscreen: 0
	grouped: 0
	swallowing: 0
	focusHistoryID: 2

I can't think of a way resolve the issue. IMO the problem is on the Thunar side.

I understand the problem and could ignore Thunar but same happens with emacs, which is something I wouldn't avoid.
From one angle they are not separate programs so there is nothing wrong with app class, it is the same Thunar executable with different parameters. But in my tests, nwg-dock-hyprland doesn't select thunar.desktop (which exists and exactly matches class name), it selects  thunar-bulk-rename.desktop (as first thunar*.desktop match?) which is wrong.
Same thunar* matching is the reason why pinning Thunar executes wrong .desktop file.
If nwg-dock-hyprland would match class exactly then it would show main app class icon and execute main app class .desktop file, right?

If I understand well, this would be a partial solution. Let me make some experiments.

Could you clone and make run from the hyprdir branch?

Well, I'll merge and release this branch one way or another, as the current 0.1.7 version won't work on Hyprland 0.40. Let me know how it behaves on your side.

Could you clone and make run from the hyprdir branch? Kill the resident dock instance first, if you're running one.

Thank you, I'll test today and report back.

D'oh it is merged in master. So launchers are perfec with this update, icon still looks wrong for Thunar. They don't go both trough the same code?

What's wrong about Thunar icons? I have 2 different ones.

WhiteSur-dark icon theme (and others),
First image shows dock without Thunar, with nwg-drawer showing proper Thunar icon for this theme (looking like Mac finder, highlighted):

Second image is when I click on "Thunar File Manager" in nwg-drawer that actually points to regular thunar.desktop, executing Thunar:

As you can see Thunar is 5th icon from the left, showing folder icon instead of Thunar icon.
At all times nwg-drawer shows proper theme icon, which should be also visible in dock after starting the app, but it is not.
I tested with few more themes and it seems it is not theme dependent, WhiteSur only being good for showing the problem.

thunar.desktop contains only one Icon definition:
Icon=org.xfce.thunar where org.xfce.thunar translates to /usr/share/icons/WhiteSur/apps/scalable/org.xfce.thunar.svg (it is the only org.xfce.thunar I have), which looks exactly as on first screenshot (as shown in nwg-drawer). I can't figure out from where did icon in dock arrive, makes no sense.

On my machine org.xfce.thunar looks like a foldr icon (theme: WhiteSur-nord-dark).

I see this certain icon in the dock, but a different one in the drawer.

I'll install nwg-icon-picker and try but I am 99% certain that drawer picks the right icon, when I manually follow the paths, finder like icon is the only one named org.xfce.thunar. Let me test and I'll report back.

Just an idea: you could copy your thunar*.desktop files to ~/.local/share/applications/ and edit them to point to whatever icon you want.

This is super odd, with this test theme I am using https://aur.archlinux.org/packages/whitesur-icon-theme, org.xfce.thunar icon looks exactly as it should, same as in drawer, but it doesn't show that icon in dock:

Re copying .desktop, I will try but this finder icon is already the only one I have with org.xfce.thunar, even if I copy it it will stay the same. I can try changing to something else but I suspect that's not the solution.

Wait, why nwg-icon-picker shows finder like icon in the list (the highlighted line) but right above title shows same wrong folder icon as in dock?! Please see my screenshot.

No idea. It must wait at least till the evening, as I'll have to leave in 15 minutes. For now I only know that thunar icons are a mess.

I'll try figuring something out, thanks. nwg-icon-picker is a great tool btw, I was almost ready to write something similar. I bet the current problem is something in the line of dock matching icon with class instead of with what .desktop file says. No rush, I'll give it a try too, bit rusty in go but I can manage.

I bet the current problem is something in the line of dock matching icon with class instead of with what .desktop file says.

Most probably. Nwg-drawer just reads all the .desktop files, while the dock only knows the class value.

In conclusion, wrong icon seems to be deeper problem on the GTK level. Experimenting with nwg-icon-picker, loading icon to pixbuf with gtk_icon_theme.load_icon(name, 24,... results in loading correct icon, setting same name with icon_info.update(name) and wrong icon may be loaded. I stopped digging at this moment as it shows inconsistency across GTK.
Solution: make dang .desktop copy in ~/.local/share/applications/ and select icon that doesnt.have.stupid.name that could confuse GTK. Closing.


Codeunit 13 "Gen. Jnl.-Post Batch" - OnProcessLinesOnAfterPostGenJnlLines

Any chance of getting PreviewMode bool added to the parameters of this existing publisher?
[IntegrationEvent(false, false)]
    local procedure OnProcessLinesOnAfterPostGenJnlLines(GenJournalLine: Record "Gen. Journal Line"; GLRegister: Record "G/L Register"; var GLRegNo: Integer)
    begin
    end;

Cheers
t

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


python311Packages.parsedmarc: add missing input

refactor

Description of changes
Fix build (https://hydra.nixos.org/build/239143068)

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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/)
23.11 Release Notes (or backporting 23.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

[ ] Fits CONTRIBUTING.md.

Refactoring in the same commit makes it difficult to see what the missing input was. publicsuffixlist? Is there a reason this keeps the old one around?


Update works count

Fixes
Fixes #4480 by @dhruvkb
Description
I updated the values from 700 to 800 and created new snapshots.
Checklist

[x] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[x] I added or updated tests for the changes I made (if applicable).
[x] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.
[x] I ran the DAG documentation generator (just catalog/generate-docs for catalog
PRs) or the media properties generator (just catalog/generate-docs media-props
for the catalog or just api/generate-docs for the API) where applicable.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

I've updated the missing number it was a separate variable in meta.ts file. Does anyone know why it's a separate variable? It looks like it's not used aside from that description variable


Add GTFS-to-Chart library

 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.


Error on Android TV

W/MediaPlayer(15169): Couldn't open {network url} java.io.FileNotFoundException: No content provider:
No Network Security Config specified, using platform default
even the url to be played is a web url

Could this be helpful:

https://stackoverflow.com/questions/49395774/mediaplayer-no-content-provider-error-w-mediaplayer-couldnt-open-https-yout

@albemala
Same problem:
Everything is not working.
I tried VideoSourceType.[network, file, asset]

network: https://cdn.videvo.net/videvo_files/video/free/2017-12/large_watermarked/171124_B1_HD_001_preview.mp4
assets: assets/video/myvideo.mp4
file: /data/data/com.abcxyz.myapp/cache/normal/myvideo.mp4

@leanhro2812 are you running the example app, or your app?
Please provide:

Android version
flutter doctor output

Also, try running your app on a real device

@albemala
I tried it on a real device:
Fire TV: => Video is still working properly but still appearing
Couldn't open /data/user/0/com.myapp.development/cache/normal/videoplayback.mp4: java.io.FileNotFoundException: No content provider: /data/user/0/com.myapp.development/cache/ normal/videoplayback.mp4
By the way:
_controller?.onError.removeListener(_onPlaybackError);
Doesn't work, I can't listen to anything when something goes wrong. I tried adding a url that doesn't exist. but received nothing.

are you running the example app, or your app?
Please provide:
Android version
flutter doctor output

If you removeListener , you won't receive any event

@albemala
Sorry I was missing, the removeListener part in dispose and the addListener part when ready.
_controller?.onPlaybackReady.addListener(_onPlaybackError);
Dispose:
_controller?.onError.removeListener(_onPlaybackError);


Feature/seab 3472/jdbc statements

Description
Attempted to only update the version if the commit id is different, but that seems to fail many tests. The only change right now is to avoid a single workflowVersionDAO.getWorkflowVersionByWorkflowIdAndVersionName per workflow in the .dockstore.yml which is kind of underwhelming in performance gain. Will likely need to modify the JDBC alerts to something higher.
JDBC statements using testGithubDirDockstoreYml with an additional handleGitHubRelease call:
Before: 3 + 92 + 3 + 8 + 3 + 65
After: 3 + 83 + 3 + 8 + 3 +59
Need to look further into it but the addition of only updating the version if commit id changed only results in the number of statements being decreased by 1/4 which is odd because that should be the bulk of the statements.
Issue
SEAB-3472

So running results in 4 sets of statements (3 92 3 65) :
CommonTestUtilities.cleanStatePrivate2(SUPPORT, false);
        final ApiClient webClient = getWebClient(BasicIT.USER_2_USERNAME, testingPostgres);
        WorkflowsApi client = new WorkflowsApi(webClient);

        client.handleGitHubRelease(githubFiltersRepo, BasicIT.USER_2_USERNAME, "refs/tags/1.0", installationId);
        client.handleGitHubRelease(githubFiltersRepo, BasicIT.USER_2_USERNAME, "refs/tags/1.0", installationId);

For the rest of the stats, i'm going to ignore the two 3 statements because it's not interesting (i.e. 92 and 65 statements)

https://github.com/dockstore/dockstore/blob/develop/dockstore-webservice/src/main/java/io/dockstore/webservice/resources/AbstractWorkflowResource.java#L354 is responsible for 87 statements and 60 statements, which represents majority of the 92 and 65. the rest can be attributed to lambda create (2 2 statements) and other things. Going to focus on that one function.
within that one function, https://github.com/dockstore/dockstore/blob/develop/dockstore-webservice/src/main/java/io/dockstore/webservice/resources/AbstractWorkflowResource.java#L480 is responsible for 15 and 24 statements and https://github.com/dockstore/dockstore/blob/develop/dockstore-webservice/src/main/java/io/dockstore/webservice/resources/AbstractWorkflowResource.java#L481 is responsible for 72 and 36,  statements which combined is of 87 and 60 statements. only looking at the latter because it's the majority
within the latter function above, it's split up into 3 parts: https://github.com/dockstore/dockstore/blob/develop/dockstore-webservice/src/main/java/io/dockstore/webservice/resources/AbstractWorkflowResource.java#L615 (3 3), https://github.com/dockstore/dockstore/blob/develop/dockstore-webservice/src/main/java/io/dockstore/webservice/resources/AbstractWorkflowResource.java#L617-L637 (57 27), and https://github.com/dockstore/dockstore/blob/develop/dockstore-webservice/src/main/java/io/dockstore/webservice/resources/AbstractWorkflowResource.java#L639-L655 ( 12 6)


"Măceșu de Jos" is listed in the drop-down menu

Description:
"Măceșu de Jos" is listed in the drop-down menu alongside its corresponding county and commune, according to the law.
Precondition:
The website is up an running.

Step 1
Type "Măceșu de Jos" in the search bar.

Expected results
The location is listed in the drop-down menu as "Comuna Măceșu de Jos, DOLJ".


Set Content Type for JSON responses

Currently, Content-Type →text/html; charset=utf-8 using being used for the JSON response rather than application/json.

Modified content-type in commit 5a91c2490e77fef1ba6bc9447f9456712215ab1a


Define the data model.

The data model defines the structure and relationships of the data that an application uses and stores. It specifies how data is organized, stored, and accessed within a database or storage system. In the context of a blog project using Node.js and PostgreSQL, defining the data model involves:

Tables and Fields: Identifying the tables or collections that will store the project's data and defining the fields (columns) within each table to represent the different types of information. For example, in a blog project, you might have tables for users, posts, comments, and categories/tags.

Data Types: Specifying the data types for each field, such as VARCHAR for text, INT for integers, TIMESTAMP for date and time, and others, based on the nature of the data.

Primary Keys: Designating primary keys for each table to ensure that each row has a unique identifier.

Foreign Keys: Establishing relationships between tables using foreign keys. For instance, linking a user to their blog posts through the user's ID.

Indexes: Identifying fields that should be indexed to optimize query performance.

Constraints: Defining constraints to enforce data integrity, such as unique constraints to prevent duplicate data.

Default Values: Specifying default values for fields, which can be useful for ensuring consistency in the data.

Validation Rules: Implementing validation rules to ensure data quality, for instance, ensuring that email addresses are in the correct format.

Security Considerations: Ensuring that sensitive data is stored securely, including hashing and salting passwords.

Documentation: Thoroughly documenting the data model, including table descriptions, field descriptions, and relationships, to aid in development and maintenance. Here is a great tool to help you to document your data models https://mermaid.js.org/syntax/entityRelationshipDiagram.html

The data model serves as the foundation for your blog project, influencing how data is stored, retrieved, and manipulated within your application. It's essential to carefully design and document the data model to ensure the project's functionality, performance, and maintainability.

https://www.mermaidchart.com/app/projects/dbfbaab4-dc64-48da-bf0f-84863989127c/diagrams/ffa3fb73-c8e0-4ed2-8c1a-bdb0779ac490/version/v0.1/edit


"Allow full 40 char fingerprints to be passed"

Looks like the failing tests are due to a bundle install issue on 1.8.7, but the other rspec tests pass.

Agreed, this would be nice, especially if keys are being retrieved from a keyserver where there could be carefully crafted collisions also present. Also since the expected use case for this Puppet module is that you're not going to be typing these commands by hand over and over, there's no real excuse not to have a longer, safer identifier in your manifest (short of just directly passing the entire key, which is how we end up using it anyway because keyserver integration seems unnecessary if you already know the key you want and can simply host a copy in your config management).

Is there any update on this? I would also like to have full fingerprint support.


findToken API throws Illegal argument exception

Description:
Consider the following code snippet
import ls_org1/module1;

function testFunction() {
}

public type TestRecord1 record {
    int field1 = 1;
    int field2 = 2;
};

<cursor>

Steps to reproduce:
Try to invoke the findToken API given the position as the position of the cursor as shown. Doing that will throw java.lang.IllegalArgumentException
Affected Versions:
Swan Lake Preview1

This is fixed with the following PR.
https://github.com/ballerina-platform/ballerina-lang/pull/24965


[improvement](create table) add backend details to creating table failed msg #41463

cherry pick from #41463

run buildall


feat: WASM UDF MVP

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
To test it, just run:
./src/udf/wit_example/create.sh

TODO

[ ] user friendly SDK (proc macro)

More crazily, what about let user upload Rust, and let us compile it ...?

[ ] consider a upgrade procedure if breaking changes happens
[ ] schema check
[ ] memory/CPU limitation

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[x] My PR contains user-facing changes.

Types of user-facing changes

SQL commands, functions, and operators

Release note
Support WebAssembly UDF.

Note
Powered by WebAssembly Component Model, which is still work in progress, although already usable. Therefore, RisingWave Wasm UDF is also highly experimental, and thus we cannot provide stability guarantee.

Usage
Users can create a WASM component with the WIT file src/udf/wit/udf.wit and Apache Arrow. They can use different programming languages (rust and golang are provided examples).
To create a function with the compiled WASM component,
-- $encoded is base64-encoded WASM component
CREATE FUNCTION foo(...) RETURNS ... LANGUAGE wasm_v1 USING BASE64 '$encoded';

See src/udf/wit_example for example code & required tools.
Configuration
One additional system parameter wasm_storage_url is added (defaults to fs://@/tmp/risingwave, which is used to store the user-uploaded WASM file, and intermediate compilation artifacts.

Next I'm going to review the code and begin to learn wasm. 🤡

I will also need to relearn it 🤡


Fix: import the name 'std::cin' into src/dev_mode/main.cpp

The cin is missing when I building the latest code, just a tiny fixing.

Thanks


Improving UI for Nursing Care

Currently, the Nursing Care UI is not represented in an easily understandable manner.
Make the Nursing Care section similar to the Routine Section by switching to a table layout.

Steps to Reproduce:

Go to a consultation
Create a log update (ensure bed is assigned) of type "Community Nurses Log"
Fill routine and nursing care section
Once submitted, check the Nursing Tab in the consultation dashboard

Originally posted by @aparnacoronasafe in https://github.com/ohcnetwork/care_fe/issues/8557

Closing as merged with #8562