Adopt standard convention of SCT

It would be great if P# (and P) followed a certain standard convention of SCT work; scheduling decisions should be made immediately before each visible operation (send, receive, etc.).
Most SCT work models concurrent execution as a sequence of transitions/steps. Each transition represents one visible operation (e.g. send, receive) by a thread (machine/actor) followed by invisible (internal) operations performed by the same thread (which are influenced by the result of the visible operation) up until immediately before the next visible operation.
Thus, the P# SCT runtime should take control immediately before visible operations, not after (as I believe it does now), passing the details of the next visible operation to the scheduling strategy. This is the standard convention. This allows the runtime to inspect the next transition (whether it is enabled and what it will access) and may be helpful for certain reduction techniques (see below). The reduction where only the order of send operations matter can still be applied with this approach (see below). In fact, work on optimal reduction strategies also use this convention, so it should never be a limitation.
I believe the visible operations are: start (dummy operation that each machine "blocks" at before it has been "created"), create, send, receive. You may also need yield. Note that the trace of operations can be used in data race detection; create enables some start operation, send enables some receive operation; no extra information needs to be collected (as long as the operations contain sufficient information to causally link them, as they should).
Only the order of sends matters. Here is an approach to reduce the search space based on this: always execute a non-send operation (if possible; it does not matter which machine is chosen; yield may need special attention) until all enabled machines are about to execute sends; at this point, make a choice about which send operation to execute next. I believe this gives even more reduction than the current approach of making scheduling decisions after send operations (because the scheduler will still often choose between send operations and receive operations that become unblocked). As mentioned above, this also opens up future reduction opportunities e.g. that consider which machine a send operation is sending to. This will also ensure that other SCT scheduling algorithms can be integrated into P# (and vice-versa).
I believe it is probably best to leave the reduction approach (e.g. always choose a non-send operation) to the individual scheduling algorithms, rather than trying to apply an approach to all scheduling algorithms. This may seem counter-intuitive, but I believe the scheduling algorithm informs the reduction technique that can be used, and the scheduling algorithm may prefer to "see" all operations, even those that seem to be redundant (e.g. dynamic partial order reduction and data race detection code will want to "see" all operations). Also, the reduction approach will probably be trivial in most cases.
It would be great to make this change before it is too late!

Thank you Paul. You are correct that we currently do scheduling after a "visible operation". You make a good case for doing it before (and also while conveying information on the type of the next operation).
In P# we don't have a yield (I suppose you want this for custom synchronization) but we have a "choice" operation (for non-deterministic choices). A choice operation commutes with all other operations but we still need to record it.
Do you have more information on "only send matters"? Why is it complete?
In the world of randomized scheduling, do you see reduction opportunities if we adopt this convention that you're proposing? That is, how can I make testing find bugs faster? I understand the argument for systematic testing, where the total number of schedules is reduced, but what about randomized testing?

Regarding why only send matters: I believe every other operation (except maybe yield or nondet choice), when enabled, is a "partial-order operation" (or, from the state, there is a persistent set containing only this operation at the given state). In other words, if you were to synthetically disable this operation, there is no other reachable operation that conflicts with it. Thus, if you were to execute it at a later point, you could always commute it backwards so that it was executed immediately, without changing the state that is reached. Thus, you should execute it immediately to achieve reduction. You could essentially remove these operations from the recorded schedule entirely, but this is probably unnecessarily complicated for replay.
For example, consider a receive operation. Once it is enabled, no other operation can change what it will do. The same applies to start and create.
Regarding randomized scheduling: yes, I believe there are opportunities. In fact, the algorithm/approach I described in the first post (but assuming a random choice when choosing between sends) is an example of this. It has more reduction than the current random scheduler, which may end up "using a choice" to decide between send and non-send operations, which is redundantly increasing the "choice space". Similarly, when doing a PCT-like algorithm, only the send operations need to be regarded as steps; thus, the schedule length (and "choice space") is decreased.
For some more powerful reduction ideas: a random algorithm could use the ideas of DPOR as a heuristic. E.g. detect send operations from different machines that were sent to the same machine and try reversing that order, instead of redundantly exploring different orders of all sends; e.g. if you have two timer machines that "ping" two different machines, there is no need to explore the different orders of the send operations from the timers machines, as they are independent.

Paul,
I am not convinced. Lets chat about this offline.
Akash
Sent from my iPhone

On 07-Mar-2017, at 11:40 PM, Paul Thomson<EMAIL_ADDRESS>wrote:
Regarding why only send matters: I believe every other operation (except maybe yield or nondet choice), when enabled, is a "partial-order operation" (or, from the state, there is a persistent set containing only this operation at the given state). In other words, if you were to synthetically disable this operation, there is no other reachable operation that conflicts with it. Thus, if you were to execute it at a later point, you could always commute it backwards so that it was executed immediately, without changing the state that is reached. Thus, you should execute it immediately to achieve reduction. You could essentially remove these operations from the recorded schedule entirely, but this is probably unnecessarily complicated for replay.
For example, consider a receive operation. Once it is enabled, no other operation can change what it will do. The same applies to start and create.
Regarding randomized scheduling: yes, I believe there are opportunities. In fact, the algorithm/approach I described in the first post (but assuming a random choice when choosing between sends) is an example of this. It has more reduction than the current random scheduler, which may end up "using a choice" to decide between send and non-send operations, which is redundantly increasing the "choice space". Similarly, when doing a PCT-like algorithm, only the send operations need to be regarded as steps; thus, the schedule length (and "choice space") is decreased.
For some more powerful reduction ideas: a random algorithm could use the ideas of DPOR as a heuristic. E.g. detect send operations from different machines that were sent to the same machine and try reversing that order, instead of redundantly exploring different orders of all sends; e.g. if you have two timer machines that "ping" two different machines, there is no need to explore the different orders of the send operations from the timers machines, as they are independent.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

In P, there are three kinds of "receive" and two kinds of "send" operations.  The three kinds of receives are:

The initial "receive" executed by a state machine that starts execution right after it was created.  This operation is a right mover.
A receive operation that dequeues an event from the input buffer.  This operation is a right mover.
A receive operation that "dequeues" the null event; this happens only if there is a handler for "null" and it is not possible to dequeuer a real event from the input buffer based on the current control state.  This operation is a non mover.

The two kinds of "send" operations are:

An actual send operation. This operation is a non mover.
A new operation. This operation is a left mover but we chose to model it as a non mover to keep the introduction of scheduling points simple.

P uses Lipton's reduction to justify its scheduling points.  For each state machine, it introduces one scheduling point at the very beginning of its execution, one scheduling point right after each "send" (i.e., send or new), one scheduling point after each receive that "dequeues" null, and one scheduling point when it blocks because it cannot dequeue any event.  This strategy guarantees that the sequence of operations in each state machine from scheduling point to the next looks like RNL; in fact, it looks like R*N since all left movers (essentially local operations) are right movers as well.  Notice that monitors are executed atomically with send statements but that does not affect the analysis above because send statements are non movers.
Finally, P also has a statement called "announce":
announce e, v;
This statement broadcasts event e to all monitors that observe e (similar to a send statement).  It offers extra expressiveness in case the programmers wants to write safety specifications that cannot be expressed with the events used for normal execution.  P does not add a scheduling point before or after the announce statement.  I justified this approach by saying that the announce instrumentation is being done on the reduced semantics and that the programmer is expected to be aware of this distinction.
I did not use DPOR terminology in my justification above because I find that terminology difficult to understand.  Lipton's reduction is far easier and seemed adequate for my reduction needs at the time.
If we choose to move scheduling points before send operations, we will have to revisit the algorithm described above for inserting scheduling points.

Thanks Shaz.
Update: Pantazis and I are currently working on making these changes in P#.
Pantazis told me about the default handler last week;  how important/used is this feature? I feel like it might remove a lot of reduction opportunity.
More motivation below:
I believe the approach I am suggesting is used by every other SCT tool I know of, excluding P/P# and including CHESS, if that helps.
A visible operation may block. As such, you must (at some point) place a scheduling point immediately before a visible operation. There is no need to ever split up a visible operation from the invisible operations that follow it (this is proven; just execute them immediately). Thus, there is no need to place a scheduling point anywhere else. Also, putting a scheduling point at any other location means you don't know what the next visible operation is; why would you not want to have this information, since you can provably continue executing until you reach it? It is typically useful to know, especially for reduction techniques. It is also inconsistent, as you will have to have a scheduling point before some visible operations. Thus, each transition is: a visible operation followed by the invisible operations. A schedule is just an interleaving of these transitions; i.e., path in this transition system.
I think the representation of transitions/operations (or, the "model of a concurrency program") can (and should) be orthogonal to the reduction strategy. Thus, the scheduling strategy should see all visible operations. Thus, you must place a scheduling point immediately before every visible operation, even if you think it will never be used. The scheduling strategy can do the reduction, or the strategy can be wrapped in another strategy that does the reduction.

Is it fair to say that Paul is looking at program steps as either a non mover (visible) or a both mover (invisible)? Then the scheduling only needs to happen before a non mover.
Akash
Sent from my iPhone

On 23-May-2017, at 9:11 PM, Paul Thomson<EMAIL_ADDRESS>wrote:
Thanks Shaz.
Update: Pantazis and I are currently working on making these changes in P#.
Pantazis told me about the default handler last week; how important/used is this feature? I feel like it might remove a lot of reduction opportunity.
More motivation below:
I believe the approach I am suggesting is used by every other SCT tool I know of, excluding P/P# and including CHESS, if that helps.
A visible operation may block. As such, you must (at some point) place a scheduling point immediately before a visible operation. There is no need to ever split up a visible operation from the invisible operations that follow it (this is proven; just execute them immediately). Thus, there is no need to place a scheduling point anywhere else. Also, putting a scheduling point at any other location means you don't know what the next visible operation is; why would you not want to have this information, since you can provably continue executing until you reach it? It is typically useful to know, especially for reduction techniques. It is also inconsistent, as you will have to have a scheduling point before some visible operations. Thus, each transition is: a visible operation followed by the invisible operations. A schedule is just an interleaving of these transitions; i.e., path in this transition system.
I think the representation of transitions/operations (or, the "model of a concurrency program") can (and should) be orthogonal to the reduction strategy. Thus, the scheduling strategy should see all visible operations. Thus, you must place a scheduling point immediately before every visible operation, even if you think it will never be used. The scheduling strategy can do the reduction, or the strategy can be wrapped in another strategy that does the reduction.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Sounds like it.  Putting a scheduling point before every receive and every send would also be sound, provided there is no infinite execution of invisible operations or there is a way of detecting and failing an infinite sequence of invisible operations.
In the scheme I had outlined, I was avoiding putting scheduling either before or after each successful dequeue.  It is correct though that if the dequeue blocks, a scheduling point has to be inserted.

I should clarify that scheduling only before visible (and not invisible) operations does achieve some reduction, but more reduction should be achieved by even the most trivial scheduling strategies. E.g. even though a scheduling point will always be placed in front of every create, start, send, receive, and default receive, most scheduling strategies will only need to consider sends and default receives. Thus, in PCT, the "number of steps" will be the number of sends and default receives; a priority change point will only every occur at these points. A delay (in delay bounding) would only ever occur after a send or default receive.

Actually, delay bounding is an exception, so ignore that. Instead: a depth first search would only consider sends and default receives.

@paulthomson: Are you claiming that a non-default receive is a left mover, i.e., we can soundly remove scheduling points before a non-default receive?

@paulthomson: I think you are and I am beginning to agree with you.  It looks like an alternative sound strategy for scheduling points is just before every send and every non-default receive. Of course, in addition, there is a forced scheduling point at each point where a machine blocks and at the beginning of each machine.
Perhaps the forced scheduling point at the beginning of each machine can be avoided also but it is beginning to look complicated.

Here is the approach in more detail with some examples, as soon to be implemented in P# (hopefully).
When the P# testing runtime executes a schedule, it will repeatedly invoke the Schedule method at each scheduling point. The Schedule method is implemented by the scheduling strategy; e.g. PCT, DFS, Random, etc. The Schedule method receives a list of process infos, which we will show as a triple of the form:
(ProcessId, OperationType, Target).
The operation type and target represent the next visible operation and its target. An example for a scheduling point in a multithreaded program before thread 0 is about to lock mutex m is:
(0, mutex_lock, m).
The Schedule method returns an index specifying which machine from the list should be scheduled.
Thus, the calls to Schedule for a P# program that is executing from the start will be similar to the following. I will use * to indicate that a machine is disabled.
Schedule([ (m0, start,   m0)                       ]) = 0
Schedule([ (m0, receive, m0)                       ]) = 0
Schedule([ (m0, create,  m1)                       ]) = 0
Schedule([ (m0, send,    m1), (m1, start,   m1)    ]) = 1
Schedule([ (m0, send,    m1), (m1, receive, m1)*   ]) = 0

Note that the first two calls to schedule could be omitted; it does not really matter. The key point is that the scheduling strategies will be notified about ALL scheduling points and it is up to the scheduling strategies to achieve reduction.
Consider the following extract from a trace of calls to Schedule:
Schedule([ (m0, receive, m0), (m1, send, m0), (m2, receive, m2)    ]) = 0 (forced)
Schedule([ (m0, send,    m1), (m1, send, m0), (m2, receive, m2)    ]) = 2 (forced)
Schedule([ (m0, send,    m1), (m1, send, m0), (m2, receive, m2)    ]) = 2 (forced)
Schedule([ (m0, send,    m1), (m1, send, m0), (m2, send, m2)       ]) = (make a choice)

Most scheduling strategies will use the following rule: FORCE schedule the first enabled machine that is not about to do a send or default receive. Thus, all of the above scheduling points, except the last, are "forced". Then, the scheduling strategy will actually do whatever algorithm it wants to pick between the sends.
Note that this is better than the "decide when we can context switch" approach (i.e. don't context switch away from a machine unless we are about to execute operation type X). For example, if a machine gets blocked due to a receive, the context switch approach would now potentially have to choose between several machines that are about to execute receive and some that are about to execute send; but this is redundant; the best simple strategy is to execute all the receives (create, start, etc.) and ONLY THEN make a choice. But there is no one-size fits-all approach. DPOR (or randomized DPOR-like techniques) will use different techniques to achieve even greater reduction.

Done in #198.

It turns out this is not done. We are missing scheduling points before each Receive operation. A Receive operation dequeues/receives an event and processes it. A Receive operation is only enabled when an event is about to be processed; a Receive operation should not necessarily become enabled when an event is added to the Inbox because the event may be deferred or ignored.
I think the following change will be key to make this possible. In bug finding mode, when machineA sends to machineB, machineA should execute machineB.GetNextEvent() (or a similar method) so that machineA knows whether to enable machineB. In production, this will not happen; instead, a task is created for machineB which may end up completing without processing any events (as is currently the case for both production and bug finding modes).

We normally do not have DEQUEUE scheduling points as these are not required: as long as you schedule at a SEND its enough to explore all possible interleavings. However, I understand that for a DPOR-based scheduler we want to introduce a DEQUEUE scheduling point. Non-DPOR schedulers can simply ignore this scheduling point (by returning the same scheduling choice as the previous one).
I am not very sure about the last part, we should discuss this.

Notes:
Add scheduling point after call to GetNextEvent (possibly in NotifyDequeuedEvent) but before handling the event.
Handling a Raise should not be a scheduling point. (Already OK)
The initial event should not cause a Receive scheduling point. (Already OK)
Problem 1: When an event handler exits, it will hit a Receive scheduling point. When the event handler is recreated, it must not hit another Receive scheduling point before processing an event.
Solution: Flag to skip receive if the last receive was exiting event handler (a receive where we are disabled).
Problem 2: Only enable a machine when it can actually handle an event.
Solution: Change GetNextEvent so that it can be called from the sender machine. It will now return an index to the next event (without removing it). It will also put a raised event or a default event in the Inbox if needed. The sender machine will now know whether to enable the receiving machine.

I am not sure if I want to have all these guys be a Receive scheduling point. In the above discussion there are (at least) the following Receive points:

Receive when an ISchedulable dequeues an event from its inbox.
Receive when the event handler of an ISchedulable exits because the inbox is empty (or there is nothing that can be dequeued, e.g. all remaining events are deferred).
Receive when an ISchedulable asynchronously "blocks" its handler until it receives an event its waiting for.

I understand that in non-P-based SCT frameworks all the above receives might be treated the same (well mostly because the third one does not exist), however I don't think this is easy in our case. The problem is that regular schedulers in P# need to differentiate between all the above receive points.
For example, I don't want the naïve random scheduler to schedule at a dequeue, because this is not required (scheduling at all sends is enough to expose all bugs). However, a regular scheduler still needs to schedule at the end of a handler or at a receive statement, else the program will deadlock. For this reason, I want to add an extra operation called Wait, and the last two Receive points above, are essentially a Wait. I think this is a useful optimization in general (even for third-party actor-based SCT frameworks), since sends and receives commute -- and most schedulers can safely ignore receives.
A Wait operation denotes that you are waiting for some arbitrary trigger to happen (scheduler does not need to know, can be agnostic). DPOR can process Receive though to perform partial-order reduction, and can essentially treat Receive and Wait the same.
Another option would be to treat Receive differently depending on the machine being enabled or not (in dequeue the machine is enabled, in the last 2 points its disabled), however, I quite like to know about this just by querying the operation, rather than having to check both the operation and the enabled status of the machine. But I am happy to debate about this.
Btw, beyond what has been discussed, there is a potential problem because an extra scheduling point can currently trigger the liveness checker to assert liveness / capture a state, making it inefficient (and potentially buggy with the current implementation). Need to be careful there because its very easy to introduce bugs. I know that the liveness checker could be implemented as a strategy, which could make solving these problems much easier, but that requires some heavy refactoring which we don't have the time to do right now. So we might want to initially disable the liveness checker for DPOR (and receive operations) until this is investigated/resolved properly.
@paulthomson we can discuss :-)

Problem 1 above solved. @paulthomson we can code review together.

I think you are saying you want to add a new OperationType, Wait, and some of the receive scheduling points will use this new operation type. I see no downside to this, except the second receive operation type must remain as a receive (see below for an example). Also note that I think the third receive operation type (a receive statement) should, in some cases, not block at all (mentioned below---the required event may already be in the Inbox, right?).

The problem is that regular schedulers in P# need to differentiate between all the above receive points.

I don't see why, but it doesn't hurt to differentiate the async receive statement (the third case).

For example, I don't want the naïve random scheduler to schedule at a dequeue, because this is not required

Indeed, the random scheduler does not need to (as explained in my example in the first comment), but I don't know why differentiating is needed. In fact, "not scheduling at a dequeue" is not enough; more can be done, as I explained in my second comment.

However, a regular scheduler still needs to schedule at the end of a handler or at a receive statement, else the program will deadlock.

Essentially: if a machine blocks, another machine must be scheduled. I agree. But I still don't see why differentiating is needed.

...the last two Receive points above, are essentially a Wait

I think the second one really must be a receive, not a wait, because the wait will sometimes replace a receive (because they are actually the same operation!). Consider the following schedule:
M1      M2

send
send
        receive
        receive

M1's first send is received by M2's first receive, and M1's second send is received by M2's second receive. M1's second send and M2's first receive are independent, so can be commuted without changing the state reached. Let's look at this schedule now:
M1      M2

send
        receive
send
        wait

M2's second receive has changed to a wait! Thus, these schedules are no longer equivalent. Thus, the use of wait is incorrect.

I think this is a useful optimization in general

I see no optimization (indeed, the current approach of not scheduling before a dequeue is nonoptimal), but again I think it is fine to differentiate the async receive statement, if you want.

since sends and receives commute

I don't agree with this in general.

and most schedulers can safely ignore receives

They can do this with a scheduling point before every receive and without differentiating the different receive types; they should force execution of all enabled receive operations before making a choice. In fact, this is more efficient than the current approach of not scheduling before a dequeue.

A Wait operation denotes that you are waiting for some arbitrary trigger to happen (scheduler does not need to know, can be agnostic).

A receive also denotes this. The DPOR scheduler does need to know which send eventually enables the operation, regardless of whether the operation was initially disabled.

Another option would be to treat Receive differently depending on the machine being enabled or not (in dequeue the machine is enabled, in the last 2 points its disabled), however, I quite like to know about this just by querying the operation, rather than having to check both the operation and the enabled status of the machine. But I am happy to debate about this.

Actually, a receive statement could also be initially enabled if the required event already happens to be in the Inbox, right? Thus, I think you would still need to differentiate the receive statement (although I still don't know why this would be useful). As I have argued above, the second receive operation really is a receive operation.

Btw, beyond what has been discussed, there is a potential problem because an extra scheduling point can currently trigger the liveness checker to assert liveness / capture a state, making it inefficient. ...So we might want to initially disable the liveness checker for ... receive operations ...

I think that is a good solution and so there is no problem. By the way, I think you should also disable it for create, start, halt, as well, which I assume you don't currently do (and so I hope this can motivate further why efficiency/reduction vs. correctly having a scheduling point before each visible operation are orthogonal). In other words, you should only consider send, as I mentioned in the first comment of this issue. There are exceptions and it depends on the scheduler. E.g. preemption bounding and delay bounding (which are not compatible with the live checker anyway, right?) must consider create; a machine that infinitely creates machines without issuing any sends would be an issue, but you could detect this.
For me, the takeaway is that these are all receive operations: a receive operation is enabled by a send operation, and the send operation may or may not have already occurred. The async receive statement is exactly the same (it may or may not be blocked initially, I hope), but it is fine to give it a different name.

Lets discuss in person as its much easier. I think I can understand clearer what you have in mind now (and I start to agree with some of your points).
Just to quickly say:

If a machine uses the receive statement, and the event waiting to receive is already in the inbox, then the scheduling point is not inserted there currently. I believe that is fine for our existing schedulers (similar to how we do not schedule at a dequeue), but I just realised that we need to add it for DPOR to work, right? Your comments regarding IsEnabled above are correct!

In general, this part of the code is really complicated, this is why I want to be 100% convinced before I make any big changes. I don't disagree with your points (and I think I start getting convinced why we only need Receive and not Wait, although this requires some refactoring and doing what you said with forcing the Receive operations execute in current schedulers), but we need to discuss more so that I can fully understand this.
I think we should work on two branches: (1) where we try to convert the liveness checker into a strategy which can sit on top (or below) any other fair strategy, and (2) the changes you mention in this thread that are needed by DPOR so that I can also better understand them. (2) will most likely conflict with existing liveness implementation until (1) is done, so I don't want to merge them to master before (1). If we are satisfied with all this exercise, we can then merge (1) and then (2). But meanwhile, we can do DPOR experiments in (2), without liveness initially (which is though really important for the applications we are targeting, so we need to support it).
We should try to also discuss with @akashlal when we meetup on Tuesday.

Yeah in person is easier!

If a machine uses the receive statement, and the event waiting to receive is already in the inbox, then the scheduling point is not inserted there currently. ..  I just realised that we need to add it for DPOR to work, right?

A receive statement is indeed a visible operation and so a scheduling point is required. I think a nice argument that I probably should have come up with much earlier is that:

A visible operation is an operation that changes the shared state (including e.g. the state of an Inbox) and/or can become enabled/disabled and/or can enable/disable another operation.
Visible operations are essentially scheduling points.
Where you put scheduling points can (and should) be orthogonal to any optimisation/reduction. This is especially important since some reduction techniques only work with certain schedulers.

Thus, I think of this change as not simply being necessary for DPOR, but instead being consistent with the rest of the scheduling points and with other SCT work.
Perhaps the liveness checker could continue to work while we add scheduling points, as long as we carefully update when the liveness checker is triggered. But your approach sounds good too.

I just want to document a change I have made in the dpor3 branch (in case this branch gets lost).
The scheduling point for send should be inserted before the check for whether the send will "fail" because the target machine has halted. One way to reason about this is that whether the send fails or not depends on when we schedule the send, so we should have a scheduling point to ensure we explore both possible outcomes.
Another way of looking at it is that a send to a machine should potentially be independent with the final operation of the target machine. E.g.:
m0					m1
					send (to m0)
send (to m1)
[halt]

The two sends should be independent and so can be swapped without changing the state reached (assuming conceptually that, when halted, m0 will clear its mailbox and not add further messages to its mailbox, or that m0 does not clear its mailbox and does add all future messages to its mailbox). If we try to execute this schedule:
m0					m1
send (not to m1)
[halt]
					[send has gone]

...m1's send has now vanished and so we would have to treat these sends as dependent, even though they aren't really.

I think what you say makes sense. Btw, I just merged the liveness strategy refactoring, so we might want to rebase master to dpor branch!

Thanks! I have rebased!
I am bit confused as to what PrepareForNextChoice is for. Couldn't all that code just go in GetNext? They are called one after the other in BugFindingScheduler.Schedule, so it seems like PrepareForNextChoice serves no purpose. It sounds like you want to do something just before the next scheduling choice, which is precisely what GetNext provides you, right?

Scheduling strategies have now been separated in Microsoft.TestingServices.SchedulingStrategies.dll here. We can rebase dpor3 now on top of this. We should also add an IContract (i.e. asserter interface) similar to ILogger (here) and IRandomNumberGenerator (here) that can assert the implementation of scheduling strategies (only used in DPOR right now).
I removed the PrepareForNextChoice!

@paulthomson btw, I am not 100% sure about the name of the new dll, but I wanted to emphasize that these scheduling strategies are specifically for controlled/systematic testing, that's why I decided to not just use Microsoft.SchedulingStrategies.dll :-)
Another idea would be to rename it to Microsoft.PSharp.TestingServices.SchedulingStrategies.dll. Because, TestingServices can mean many different things ... to emphasize its about P#-style SCT (other SCT tools shouldn't really care).
If you think of any better ideas please say of course!

@paulthomson I was reviewing the code and I am a bit confused why we are using a scheduling point inside NotifyDefaultEventHandlerCheck. What if the default handler never triggers? We have just done an extra scheduler, unless I am missing something (which could be the case)!
I wonder if we can remove default all together ... not sure if this is even used really. Lets chat with @akashlal next time.

See #206. If the machine does not have a default state handler or the machine never gets into a state with a default state handler, there will be no extra scheduling point. Otherwise, I feel it is (unfortunately) needed. But if you don't use the feature, then there is no penalty anyway.

Cool, I will check it out and let you know! Btw, the rest of the changes look awesome :-) I just did some refactoring and rebased (primarily all DPOR stuff are now internal and in their own namespace to keep things more tidy).
Need to fix the failing tests now (3 integration need to get new seeds, and the one unit test not sure what is happening, might have to do that we have extra steps now so need to change test parameters, will investigate).
Then we also need to take some measurements with random+pct+fairpct using the extra scheduling points, and also the other strategy that we discussed (all operations forced, until only sends).

If we are happy with the randomized strategies bug-finding performance we are good-to-merge, and then can move to some interesting experiments :-)

Closing this issue, as it has been inactive, and we had already addressed (I think) most of the points above in various PRs 2 years ago. If we need to discuss/address SCT modifications can do so in another thread, or reopen this one.


HMR chunck styles

Only main.scss is currenly being hmr, if you change style on a chuncked component there is no hmr.
My curreny "hack" is to replace ExtractCssChunks.loader with style-loader (https://www.npmjs.com/package/style-loader) in webpack.cliend.dev. However server styles gets a bit weird but at least there is hmr so you wont have to refresh the page to see the style changes. In the past i used isomorphic-style-loader on the server, but it doesn't seem to work that good anymore when i upgraded to webpack 4 and upgraded the universal stuff.
However, it would be nice to make it work with hmr and sass the way the universal demo works with .styl.
Im subscribing to this in the meantime if you happen to find a better working way :). Keep up the good work!

Solution [https://github.com/faceyspacey/extract-css-chunks-webpack-plugin/issues/111]
Add:
new ExtractCssChunks({ reloadAll: true }),
to webpack.client.dev


Fix issue with bucket creation in us-east-1

Signed-off-by: Brian Donohue<EMAIL_ADDRESS>

@Donohue Thanks for the PR.
Can you provide some descriptions on the issue you are fixing here?

Hey Brian thanks so much for the PR -- does us-east-1 have different bucket creation semantics? @ooq we should probably run our CI in multiple regions to make sure we don't have these bugs.

Hey @ericmjonas and @ooq this ticket describes the issue in detail: https://github.com/boto/boto3/issues/125
Here's the relevant comment for convenience:

This is an artifact of the underlying S3 API and the fact that it doesn't accept us-east-1. To create an S3 bucket in us-east-1 you can just not specify any CreateBucketConfiguration: s3.create_bucket(Bucket='foo').

There was an error creating the bucket in us-east-1 during setup and I verified that this resolves it.

@Donohue Indeed! I just tried and verified this as well.
I'm surprised that they haven't fixed it after all this time.
We'll merge your PR after fixing our Travis build. Thanks again.

Cool 😎


DM server owner to activate after bot addition

If the bot gets added to a server but not activated after a set amount of time, dm the server owner to tell them about activation (if they are not already in the control server).
We can use a couple of checks to make this not invasive nor annoying.

Example code which could be put into a loop to run every 5 minutes ( or any interval ) similar to the ScamGuard.PeriodicBackup
from datetime import datetime, timedelta

.....

unactivatedServers = self.Database.GetAllDeactivatedServers()

for server in unactivatedServers:
    currentTime = datetime.utcnow()
    rangeStart = server.created_at + timedelta(days=1, minutes=4)
    rangeEnd = server.created_at + timedelta(days=1, minutes=9, seconds=1)
    if ((currentTime > rangeStart) & (currentTime < rangeEnd)):
        # run discord message function

With this code, the "notification" would be send out 1 day after the server entry has been made into the database.
The chosen timedelta is an offset 5 minute with an additional 1 second interval as a safety check to not occur at the same time frequency as the actual task loop to ensure no check will occur outside of the range on accident due to slow execution, nor inside of it twice as the likely hood of the interval matching the extra 1 second grace interval should be small.
Additional messages can be sent by duplicating the code inside the for loop (to reduce iterations) and changing the timedelta interval day period (or any period)

Note: This code is using the create_at timestamp from my code in #45, and not the updated_at timestamp to ensure the notifications are only sent out on the initial entry of the database, and not due to subsequent changes which have occurred to the server for any of the variety of reasons the entry would be updated.

Another longer term alternative which may allow for more configurability would be to create a notifications table and record attempted communications there.

Closing this issue, we're going to add slash commands instead, as this will be easier to use than having the bot directly message an user.


test against nodejs 4, 6, 8 and 9

thanks.

Thank you! I also removed tests against node 0.10 and 0.12 in df01b1b920b8c06af8563ee9d5bf7b51ab7e7abe.

:)


Reviews please :)

thx @jona-sassenhagen

Thanks!


Power consumption & missing deep sleep

Currently if one wants to run the HEG on batteries, it has really high power consumption and the batteries need to be exchanged very frequently. It's down to the HW (e.g. the voltage regulator is inefficient - there are (much) more efficient ones on the market) but also SW (e.g. there seems to be no deep sleep in case of inactivity between wifi beacons and other wifi requests).
Are there any plans to improve on this?

 There is a deep sleep mode but it doesn't trigger unless the sensor routine is off if you leave it sitting, and I'm adding some switches to the board for this one to make it a bit easier to swap modes.
Current plans are to move to my own design with a BLE5.2 and 8 channel 24bit ADC (ADS131M08). This is radically power efficient (like 20mA running at full ADC speed w/ BLE5.2) and will be my first custom solution. I have already tested the ADC and for about 5 bucks I get quality EEG data (noise levels near the FreeEEG32). The impedance at the higher gain is good enough for EEG, and then of course this is overkill for optical signals so hopefully this gets me the FNIRS-DOT working too.

Current plans are to move to my own design with a BLE5.2 and 8 channel 24bit ADC (ADS131M08). This is radically power efficient (like 20mA running at full ADC speed w/ BLE5.2) and will be my first custom solution.

Hm, will you want to change the "HEG board is the web server" architecture then (e.g. to run a server on the client and make the HEG board only a "dumb" provider of data - i.e. client which just gathers and pre-filters data)?
Or will the current architecture stay (I'd say ESP32's wifi is very low-performant and might be a bottleneck if one wanted to connect more than one client to the wifi or even use the ESP32 wifi AP as a "normal" beefier AP to connect e.g. notebooks together in a LAN and send some data between these notebooks)?
Will the new architecture (if any) also support more than one HEG user in the same room (each having their own HEG device on their head)?
Sorry for so many questions - it all just popped in my head immediately after I read your paragraph :wink:.

@dumblob  The web server is super cool but there are a lot of tradeoffs. This next device will be doing EEG and I can't isolate well enough to not pollute the signal if running a wifi server.   I'll keep the current esp32 architecture for the Delobotomizer because it's easy and keeps costs low, but I'm trying to move into a more legitimate standard, though may find a better ESP32 breakout if one pops out at me.

So this next device is will not provide any HEG functionality, but only EEG?
I hope this next device's architecture will alow multiple next devices in one room :wink: (i.e. no AP name clashes, no interference and thus loss of samples, etc.).

Its going to be multimodal, HEG and EEG, built on a generic sensor frontend. As far as access points, one task on the list while building this next round of assemblies is having the devices create random Ids the first time they start, thats just a firmware oversight. Also testing the BLE updater


Quick fix for #58

Quick fix for #58

Thanks for this! While I can't actually reproduce your issue, I'm happy with this fix, as it seems rather harmless. Cheers!

Thanks! I suspect it has something to do with the order the background tasks are being run after adding a locale. In my case "resaving products" runs before "resaving supertable elements". Not sure though


Multiple arguments of the same argument role

Hi. I'm dealing with a dataset that has several argument roles, and each role might have multiple arguments. For example, '<arg1>, <arg2>, <arg3>, <arg4>, <arg5> has participate in an military activity on <arg6> ... ' In this sentence, arg1 to arg5 is the same role but different arguments, they are all the role 'countries'. And the problem is, each data in my dataset might have different number of 'countries'. In my example there are five countries which is arg1 to arg5, while in other data it might be just 3 countries which is arg1 to arg3 or just 1 countries. And I tried to use template like '<arg1>, <arg2>, <arg3>, <arg4>, <arg5> has participate in an military activity on <arg6> ... ', but I got pretty bad result, because it seems to be predicting a lot of '<arg> <arg> <arg>' and the result sentence looks absurd. If I use use template like '<arg1> has participate in an military activity on <arg2> ... ', the result is normal and acceptable, but in this way I can only predict a single one countries(arg1). Is there a way to deal with this? Thanks.

Are there also many cases of multiple argument values for the same role in your training dataset?
I would suggest that you experiment with different templates. What worked for me is to keep  1  placeholder in the empty template and use all arguments for the filled template during training.
Assuming that A, B, C all on take the country role, for training you would have:

Input:  participated in an military activity.  Output: A, B and C participated in an military activity ...
Input: The countries that participated in military activity include .  Output: The countries that participated in military activity include A, B and C.


License ?

Hello, under what license is this project released under ? Thank-you.

Hi! MIT license has been added.


Replaced MRM related API calls in notebooks with corresponding SDK functions

Issue : https://github.ibm.com/aiopenscale/tracker/issues/29076

@Hari-Krishnan3 - Did you ran notebooks against latest SDK code?

@Hari-Krishnan3 - Did you ran notebooks against latest SDK code?

I validated the mrm function related change by running the depended cells with 3.0.30 version of ibm-watson-openscale.  Have not ran the notebooks end to end.

@Hari-Krishnan3 - Can we atleast run one E2E MRM notebook? Try running https://github.com/IBM/watson-openscale-samples/blob/main/Cloud Pak for Data/WML/notebooks/model risk management/MRM E2E with Openpages on CP4D.ipynb

As discussed over call. Since this change updates software specification to spark-mllib_3.3 We will deliver this change along with 4.7 release.

Issue 2: https://github.ibm.com/aiopenscale/tracker/issues/31135

@kishore-patel I have updated this PR by modifying the software spec in other notebooks also. Please review.

Looks good.  We will not merge this PR until the date of 4.7 release

@Hari-Krishnan3 - Can we go ahead and merge this PR?


The file or directory to be published does not exist: .../backend/vendor/bower/bootstrap/dist

After composer update i have this problem with advanced template:
[error][yii\base\InvalidParamException] exception 'yii\base\InvalidParamException' with message 'The file or directory to be published does not exist: /var/www/vhosts/*********/httpdocs/backend/vendor/bower/bootstrap/dist'
My composer.json:
{
  "name": "yiisoft/yii2-app-advanced",
  "description": "Yii 2 Advanced Application Template",
  "keywords": [
    "yii2",
    "framework",
    "advanced",
    "application template"
  ],
  "homepage": "http://www.yiiframework.com/",
  "type": "project",
  "license": "BSD-3-Clause",
  "support": {
    "issues": "https://github.com/yiisoft/yii2/issues?state=open",
    "forum": "http://www.yiiframework.com/forum/",
    "wiki": "http://www.yiiframework.com/wiki/",
    "irc": "irc://irc.freenode.net/yii",
    "source": "https://github.com/yiisoft/yii2"
  },
  "minimum-stability": "stable",
  "require": {
    "php": ">=5.4.0",
    "yiisoft/yii2": "*",
    "yiisoft/yii2-bootstrap": "*",
    "yiisoft/yii2-swiftmailer": "*",
    "kartik-v/yii2-icons": "*",
    "kartik-v/yii2-datecontrol": "*",
    "kartik-v/yii2-widget-select2": "*",
    "kartik-v/yii2-widget-fileinput": "*",
    "kartik-v/yii2-editable": "*",
    "kartik-v/yii2-grid": "*",
    "kartik-v/yii2-mpdf": "*",
    "kartik-v/yii2-money": "*",
    "wbraganca/yii2-dynamicform": "*",
    "philippfrenzel/yii2fullcalendar":"*",
    "uran1980/yii2-scroll-to-top": "*",
    "2amigos/yii2-ckeditor-widget" : "*",
    "alexgx/yii2-phpexcel": "dev-master",
    "bedezign/yii2-audit": "dev-master",
    "ercling/yii2-pace": "dev-master",
    "miloschuman/yii2-highcharts-widget": "dev-master"
  },
  "require-dev": {
    "yiisoft/yii2-codeception": "*",
    "yiisoft/yii2-debug": "*",
    "yiisoft/yii2-gii": "*",
    "yiisoft/yii2-faker": "*"
  },
  "config": {
    "process-timeout": 1800
  },
  "extra": {
    "asset-installer-paths": {
      "npm-asset-library": "vendor/npm",
      "bower-asset-library": "vendor/bower"
    }
  }
}

I try:

delete vendor folder;
delete composer.lock
composer self-update
composer global require "fxp/composer-asset-plugin:1.1.1"
composer global show -i

fxp/composer-asset-plugin v1.1.1 NPM/Bower Dependency Manager for Composer

composer global update
composer global clear-cache
composer update

Any ideas?

Composer version:
'''
[root@s17789639 httpdocs]# composer -V
Composer version 1.0-dev (03299ff075236be27be356498d6c64def973fe41) 2016-01-10 20:34:53
'''
Works fine on my local machine Widows 10,  not working on production server Linux...

php -v

PHP 5.4.44 (cli)

Does composer update complete without any errors?

Composer complete without errors, vendor was update correctly.
[root@s17789639 httpdocs]# ls -l vendor/bower/bootstrap
total 60
-rwxrwxrwx 1 root root   640 Jun 16  2015 bower.json
drwxrwxrwx 5 root root  4096 Jun 16  2015 dist
drwxrwxrwx 2 root root  4096 Jun 16  2015 fonts
drwxrwxrwx 2 root root  4096 Jan 11 03:50 grunt
-rwxrwxrwx 1 root root 14881 Jun 16  2015 Gruntfile.js
drwxrwxrwx 2 root root  4096 Jan 11 03:50 js
drwxrwxrwx 3 root root  4096 Jan 11 03:50 less
-rwxrwxrwx 1 root root  1084 Jun 16  2015 LICENSE
-rwxrwxrwx 1 root root   813 Jun 16  2015 package.js
-rwxrwxrwx 1 root root  2073 Jun 16  2015 package.json
-rwxrwxrwx 1 root root  6994 Jun 16  2015 README.md

Make sure you have fxp plugin installed globally: http://www.yiiframework.com/doc-2.0/guide-start-installation.html#installing-via-composer

Does web server have permissions to read the files?
@samdark it is

composer global show -i
fxp/composer-asset-plugin v1.1.1 NPM/Bower Dependency Manager for Composer

@samdark , i hope this can help.
[root@s17789639 ~]# composer global require "fxp/composer-asset-plugin:~1.1.1"
Changed current directory to /root/.composer
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload file

If you've tried w/o it before, try cleaning up composer cache and deleting vendor dir before re-trying.

And kill composer.lock as well.

@samdark , i did that steps:

composer global clear-cache

Changed current directory to /root/.composer
Clearing cache (cache-dir): /root/.composer/cache
Clearing cache (cache-files-dir): /root/.composer/cache/files
Clearing cache (cache-repo-dir): /root/.composer/cache/repo
Cache directory does not exist (cache-vcs-dir):
All caches cleared.

rm -Rf vendor/
rm -f composer.lock
composer update (
composer_update_output.txt
)

Result is the same:
2016-01-11 11:39:29 [XX.XX.XX.XX][1][-][error][yii\base\InvalidParamException] exception 'yii\base\InvalidParamException' with message 'The file or directory to be published does not exist: /var/www/vhosts/XXXXXXXXXXXXXXXXXXX/httpdocs/backend/vendor/bower/bootstrap/dist' in /var/www/vhosts/XXXXXXXXXXXXXXXXXXX/httpdocs/vendor/yiisoft/yii2/web/AssetManager.php:452
Stack trace:
#0 /var/www/vhosts/XXXXXXXXXXXXXXXXXXX/httpdocs/vendor/yiisoft/yii2/web/AssetBundle.php(163): yii\web\AssetManager->publish('/var/www/vhosts...', Array)
#1 /var/www/vhosts/XXXXXXXXXXXXXXXXXXX/httpdocs/vendor/yiisoft/yii2/web/AssetManager.php(266): yii\web\AssetBundle->publish(Object(yii\web\AssetManager))
#2 /var/www/vhosts/XXXXXXXXXXXXXXXXXXX/httpdocs/vendor/yiisoft/yii2/web/AssetManager.php(237): yii\web\AssetManager->loadBundle('yii\\bootstrap\\B...', Array, true)
#3 /var/www/vhosts/XXXXXXXXXXXXXXXXXXX/httpdocs/vendor/yiisoft/yii2/web/View.php(284): yii\web\AssetManager->getBundle('yii\\bootstrap\\B...')

Before creating this issue, i read https://github.com/yiisoft/yii2/issues/6402 and https://github.com/yiisoft/yii2/issues/10198...
What am I forgetting??
Composer was updated correcly after deleting cache, fxp plugin is installed globally on the last version..
As described before, i have 2 environments :
1 . Local Windows 10, php 5.5.11 (cli) -  WORKS FINE
2 . Production Centos 6.6, php 5.4.44 (cli) - STILL NOT WORKING

Are you running all composer-related commands via same user?

@samdark yes.. i run all command with root user, is it wrong?

If all commands are run with it, it should be kinda OK. Make sure he has home dir and that .composer is there.

.composer is under home root dir :(
cd /root/
ls -als
total 676
..................
  4 drwxr-xr-x  4 root root   4096 Jan 11 01:50 .composer
..................

I try to create a new project.
For basic application
..
composer self-update.
composer clear-cache.
composer create-project --prefer-dist yiisoft/yii2-app-basic test

and also for advanced
...
composer self-update.
composer clear-cache.
composer create-project --prefer-dist yiisoft/yii2-app-advanced test

Both projects works fine...
So i upload my files project, and:
...
rm -Rf vendor/
rm -f composer.lock
composer update

All works now... but why?

When you're running install or update w/o prior installing fxp it writes to .lock, vendor and cache. So installing fxp afterwards doesn't help. You need to clean all these. We're aware that it's a huge mess and for 2.1 we plan to do it w/o any global plugins required. For 2.0 it will stay as is...

@samdark thank you for the explanation, the important thing is solve the problem ;)
Not being so skilled with composer's dynamics, i tried other ways!
Actually i have not understood why on my local machine it works perfectly, without creating new project..!

rm -Rf vendor/
rm -f composer.lock
composer update

Fixed this issue for me.

Is there any  solution without
rm -Rf vendor/
rm -f composer.lock

@pptyasar no, there is no other known solution.

None of the mentioned solutions work. You can wipe vendor, clear composer cache, remove the lock file, reinstall composer, wipe the global .composer folder, walk on your hands while juggling watermelons. The project wants the vendor folder to be inside backend or frontend no matter what you do.
What is causing this?

Looks like this is happening due to the following line:
'vendorPath' => dirname(dirname(__DIR__)) . '/vendor',
missing from the generated common main.php config file. No amount of reinstalling will bring it back. Looks like it only gets added when calling create-project.


Add Thermonuclear Turbines from SpaceDock

This pull request was automatically generated by SpaceDock on behalf of Eskandare, to add Thermonuclear Turbines to CKAN.
Mod details:
name = /mod/521/Thermonuclear%20Turbines
author = Eskandare
description = A new hot way to get into orbit!
This is a small engine mod that adds nuclear turbine aircraft engines based off of this concept, Aircraft Nuclear Propulsion, Project Pluto and the similar Soviet program Tupolev Tu-95LAL, also with a little influence from the Choujikuu Yousai Macross anime series and sequels to give two of the engines space capability.
The concept behind the engine is that thermal energy is transferred through a heat exchanger into the "can" (combustion section of a turbine) instead of using combustion to rapidly heat up gasses to turn the turbine and provide thrust.
Features:
Four Engines: M.A.S.A.M.U.N.E., Back Draft, Fire Storm, and Fire Whirl.
Example Crafts
Custom Sounds
Custom FX
Current Issues
Disclaimer: This is released for 1.1 Prerelease, the packaged plugins and components may not be stable and are subject to change pending 1.1 release.
abstract = Nuclear Aircraft and Space Plane Engines
license = Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License
Homepage =
Please direct questions about this pull request to Eskandare.

Waiting on Firespitter and SmokeScreen to update

Looks good, merging with my thanks.


Error 524 (Timeout) when using apitally-js on AWS instance

Hello guys,
I'm using you library to track metrics on my API.
When I'm working on local everything works correctly, but when I deploy my app in a AWS instance I have an issue.
My app (dev) is detected and active but I can't get any data.

Here is the issue from my sentry :

It seems that it can't reach the apitally endpoint (524).
Do you have an idea why ?
Let me know if you need more details

Hey Charlie, is this an ongoing issue or was there just a couple of these events over the last 24 hours? I did an infrastructure upgrade earlier today, which could've caused some hub requests to time out, but the client library is designed to handle that gracefully and retry later, so no data should be lost.
Either way I don't think this is a problem with the client library, but I'm happy to help you get to the bottom of this. Would you mind jumping into our Slack channel and chat there?


change the "click here text" to a specific text in Articles and Talks and conferences section

The "click here" written inside the circle in the Article and Talks and conferences section makes for a bad User Experience.
So the text inside should be the name of the website it redirects to.

I want the Article and Talks and conference section look like the organizations section so that the user know what they will be redirected to once they click the circle button..
Please assign me this issue under #Gssoc'24

hello please assign this issue too me. I have made corrections in it

I would like to work on this issue , please assign me this issue.


About page - get text from the API and display

Cooler Communities logo (not linked): Text "Cooler Communities is a joint project of MassEnergize and Ener-G-Save, for the purpose of teaching residents and businesses ways to save energy and reduce emissions.  2.  MassEnergize logo (link to massenergize.org, on new tab) : MassEnergize, Inc is a charitable non-profit dedicated to the mission of helping communities and their residents take action to lower emission.  3.  Ener-G-Save logo (link to ener-g-save.com on new tab) : Ener-G-Save is a project of the Harold Grinspoon Foundation, to help homeowners cut energy lost and make their homes more comfortable and affordable.

Decided the information should come from the database.
API issue to define the route for obtaining the information
Implement the call to the API to fetch the information, and display on the about page.


Enable Snapshots and change domain

https://github.com/creek-service/creek-test/issues/30
https://github.com/creek-service/creek-test/issues/24
Reviewer checklist

[ ] Ensure relevant issues are linked (description should include text like "Fixes #")
[ ] Ensure any appropriate documentation has been added or amended

Coverage remained the same at 100.0% when pulling 2a5e7f980fe41d61374c619e3c795f96d63c6d2b on version into 9c7008b34e8e5cf897fd148c6cb71e0993378fce on main.


Fix Bloom filters with vData length >255

Currently, the Bloom filter deserialization code assumes the length data segment is a uint8 value, when it should be a varint. This has let the implementation pass the tests and work for small filters, but for filters larger than 255, the code will break.
This PR fixes the problem by using varint length for the Bloom filter deserialzation, and also adds a test for serialization/deserialization of large filters to catch this case.

ACK


grammar.md: fix typos, reduce some language

Sorry to be a dork, but these were bothering me :).
fwiw, therefore is an adverb that means “as a consequence,” “as a result,” or “hence.” Therefor is an adverb that means “for that,” or “for it.”
and with that, i will show myself out.

Excellent! More please ;)


[draft] Update postgresql to new module system

close #2013

 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.

Thanks a lot for your contribution @antarus !
Happy to see you back ;-)
@DamnClin : I'm very short on time the last day, so I'll let you review, don't hesitate to ping me as soon as you approve this PR plz

/!\· following https://github.com/jhipster/jhipster-lite/pull/2060 you'll have a breaking change to handle for the docker part (hopefully for the best)

Looks good to me. After using this mechanism do you have any improvement ideas?

For the moment no, it's quite simple.
Moreover, with the other modules that migrate, it will be faster to draw inspiration from what has already been done.

so this one is ready? Can I remove draft mode and merge it @antarus ?

Ok for me

@antarus You missed some sql common properties.
You can check in https://github.com/jhipster/jhipster-lite/pull/2154

@DanielFran I must have all the properties you have add?

Yes, the ones coming from SQL common


H_s and H_d not defined in BLS ciphersuite

The terminology section says that the H_s and H_d generators are defined by each ciphersuite, but they are not defined in the BLS12-381 Ciphersuite section.

Agree this is confusing, currently we have blind_value_generator_seed and signature_dst_generator_seed which are intended to be used with the CreateGenerators operation to derive H_s and H_d, but this needs to be clarified further


The line which declares listContainer could be assigned null

The line:
const listContainer: Element = this.domElement.querySelector('#spListContainer');
should have the non-null assertion operator at the end as we know that '#spListContainer' will always be present:
const listContainer: Element = this.domElement.querySelector('#spListContainer')!;
Without the non-null assertion operator the code returns an error in VSCode 1.57.1

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

ID: 71e8ee66-fe7c-a46e-eeec-fb199962042c
Version Independent ID: f78aef17-5aa2-8807-73d4-509faecbd153
Content: Connect your client-side web part to SharePoint (Hello World part 2)
Content Source: docs/spfx/web-parts/get-started/connect-to-sharepoint.md
Service: sharepoint
Sub-service: sharepoint-framework
GitHub Login: @VesaJuvonen
Microsoft Alias: vesaj

How do you prevent Lint from throwing the no non-null exception when packaging?


Investigate Sha2::Sha384 hashes not matching Sha384 driver hashes

Found that this is due to endianness - the sha384 driver, and the sha2 library return bytes in different endianness.


Update init.py

Use open context manager. (Pythonic)

Use yaml.safe_load().
(From Codacy)

Use of unsafe yaml load. Allows instantiation of arbitrary objects. Consider yaml.safe_load().

Thanks!


        Assumes that iterator items (the last two) are represented as lists
        as per pickler implementation.
        """
        proxy = _Proxy()
        self._mkref(proxy)
        reduce_val = list(map(self._restore, obj[tags.REDUCE]))
        if len(reduce_val) < 5:
            reduce_val.extend([None] * (5 - len(reduce_val)))
        f, args, state, listitems, dictitems = reduce_val

        if f == tags.NEWOBJ or getattr(f, '__name__', '') == '__newobj__':
            # mandated special case
            cls = args[0]
            if not isinstance(cls, type):
                cls = self._restore(cls)
            stage1 = cls.__new__(cls, *args[1:])
        else:
>           stage1 = f(*args)
E           TypeError: 'dict' object is not callable

jsonpickle/unpickler.py:472: TypeError

This is affecting Linux distributions that are building their packages against Cython 3.0.0. To reproduce in a venv:
pip install Cython versioneer
pip install --force --no-build-isolation --no-binary pandas pandas
python -m pytest -vv tests/pandas_test.py::test_timedelta_index_roundtrip

Got it. I'll try and fix it tonight but I can't guarantee it'll be done. Is there a deadline by which any Linux distros need a working version? Also, is pinning Cython to <3 a feasible temporary solution?

Is there a deadline by which any Linux distros need a working version?

Not really but numpy released an RC yesterday that requires Cython>=3.0, so it would be nice to fix it sooner than later. That said, I don't think this functionality is really critical right now, so there's no explicit hurry.

Also, is pinning Cython to <3 a feasible temporary solution?

We'd actually have to pin pandas on our end. Please don't add pins to jsonpickle because that won't affect pandas at all.

I've been investigating this, and it seems like it could be related to this commit (though I'm not 100% sure). The dict in the error you got is {'py/object': '_cython_3_0_2.cython_function_or_method'}, and it's added here. I'm not entirely sure how to fix it, but I'm going to start by trying to detect cython functions when encoding.

We'd actually have to pin pandas on our end. Please don't add pins to jsonpickle because that won't affect pandas at all.

Pandas upstream actually still pins to Cython <3 in its released/tagged versions, but has moved on to Cython 3 in the development branch.

I just got the tests passing locally. @Theelx I suspect you're busy but if you have a moment to review it'd be much appreciated. @QuLogic if you could test #477 on your side that'd be much appreciated.
https://github.com/jsonpickle/jsonpickle/pull/477
I split the proposed changes up into 2 commits. The first one is kinda hacky but then the 2nd one makes things simpler again.


use css with this?

Is it possible in it's current form to have a css file linked to it?
im using this in my app because i needed more control over each of the formatting for each page but still simple enough they can all use the same xaml page, so using this to allow html formatting in each of the text blocks from my database is the only solution i could think of but without a css file i may have created a whole lot more work just so a couple pages could have an extra flair.

@daedric1991 that might/should work, but I didn't build it with that in mind and haven't tested that.


Paket sln broken in VS 2019

https://user-images.githubusercontent.com/57396/57126853-b9b5e500-6d8e-11e9-958a-f65b79925614.png
I can't build anymore inside of VS 2019. Building from cmd line is fine. This is rather critical for me since I need to support paket ecosystem

I think this is expected, as it's using FSharp.Compiler.Tools and probably getting some collision since that package uses older bits that have not been tested nor expected to work with VS 2019.

I don't think we should close it. I consider it a bug in VS that it can't work with older FCT. The build works fine in cmd and former VS worked as well. We should not need to update FCT. The whole point of the FCT was to allow users to pin the compiler version

We don't support nor test against the package (nor have we ever). That is akin to having some arbitrary older F# compiler work with an arbitrary newer VS version, which we also neither support nor test.

It is going to start being a problem now with 2019 uptake increasing. It highlights the need to get a merged and updated FCT to unblock folks, or else have then reevaluate the need for it. As I understand it, the last remaining need (aside from the version-pinning that @forki mentioned) is to allow use of old, unuodated TPs, right?

@cartermp it's really unfortunate since this is very common and IMHO important use case.

I don't think the use of FCT is particularly common, nor important. Perhaps it was more useful years ago when there was no .NET SDK and VS had a very slow update cadence that prohibited the use of a more up to date compiler.


[1d] Compile for darwin via goreleaser

Goal: Have 3 binaries compiled via goreleaser

https://github.com/newrelic/infrastructure-agent/pull/571


Reduce the amount of repeating code in CT

Pure refactoring, no behavioral change.

should we give the ICMPV6_PKT_TOOBIG part the same treatment then?

Good idea, I didn't notice IPv6 had a similar flow, because I mainly worked on IPv4 code for my bugfix. Let me do that too.
BTW, why don't we have ICMPV6_PKT_TOOBIG in snat_v6_nat, but only have it in revNAT?

Good question, I don't see it being discussed in https://github.com/cilium/cilium/pull/25054.

Ah! The read-to-merge label was added by mlh. /cc @julianwiedmann Not sure if you all your review comments were addressed (looks that way), please double check.

Ah! The read-to-merge label was added by mlh. /cc @julianwiedmann Not sure if you all your review comments were addressed (looks that way), please double check.

All good, thanks! If it's green, merge we must.


feat(operator): adapt TaskDefinition validation webhook to consider python and deno runtime

Fixes #1527 Added logic to the validation webhook to accommodate the new fields for python-runtime and deno functionality.
Signed-off-by: geoffrey1330<EMAIL_ADDRESS>

Nice work! Can you please add some integration tests and also adapt the failing unit tests ? Thank you!

Alright I will do that

Hello @geoffrey1330 nice work! The PR looks good, can you just please check why the integration tests are failing? Thank you

Thank you for your contribution @geoffrey1330 :)


Multiple invocations of AppServiceProvider boot() method on Inertia Render

Is there a way to prevent Inertia::render from call AppServiceProvider boot() method multiple times in a request?
When invoking from  a simple controller method , adding traces to AppServiceProvider boot() shows the method called 2x during the request.
Route::get('/welcome',function() {
   return Inertia::render('Welcome');
}

If you modify the route, with the following , you will only see one invocation of the boot() method.
Route::get('/welcome',function() {
   return response()->json(['status' => 'success']);
}

Multiple invocations of the boot method may not be a huge deal except in a modules environment where all the modules boot methods are invoked multiple times.

Sounds like something else is happening in your app as Inertia does not call the boot method of your service providers. Are you sure these calls happen in the same request?
In the past I've had similar issues like this and it turned out to be a combination of a catch-all route and a missing favicon.

Roj -
Missing favicon was the culprit.
Thanks!
Ron
On Fri, May 6, 2022 at 8:08 AM Roj Vroemen @.***> wrote:

Sounds like something else is happening in your app as Inertia does not
call the boot method of your service providers. Are you sure these calls
happen in the same request?
In the past I've had similar issues like this and it turned out to be a
combination of a catch-all route and a missing favicon.
—
Reply to this email directly, view it on GitHub
https://github.com/inertiajs/inertia-laravel/issues/393#issuecomment-1119722434,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACKOT5JIATUPTWOIIT22XP3VIUYWBANCNFSM5VC7O5CA
.
You are receiving this because you authored the thread.Message ID:
@.***>

@reinink looks like this has been resolved and can be closed 👍


Avoid unintentional config matches

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fixes #189
Test URLs:

Original: https://www.sunstar-foundation.org/en/awards/world-perio/videos

Before: https://main--sunstar-foundation--hlxsites.hlx.live/en/awards/world-perio/videos

After: https://embed-config--sunstar-foundation--hlxsites.hlx.live/en/awards/world-perio/videos

[ ] New Blocks introduced in this PR
If yes, please provide details below

Block Name
Documentation

For e.g. cards
doc-link

[ ] New variations introduced in this PR

Variation Name
Documentation

For e.g. cards (grid)
doc-link

The low PSI seems to be pre-existing with this page. Opened #195


Moving buttons is bothersome

Fallout of reorganising the SceneNode hierarchy: ButtonAssets are now a SceneNode and have no standard methods to reposition them. You have to match on the sub-type and move that. 😒

This can be improved. The position of the assets is set on draw based on the bounds. So basic commands like moveTo can be added and work on the bounds field.

I've run into this as well. Currently making use of a helper method to get around this.


invoke fakeSetInterval callback multiple times if possible

This commit is addressing issue #6627. By recording interval
timer's next invoking time, the callback of fakeSetInterval
now will be invoked multiple by advanceClock()

What I do in this PR may look a little bit overkill since this bug does not cause any problem for now.  I am just trying to hack around so feel free to give me feedback or reject this ^_^.

Bug has been closed by alternate means.


Fixing #404, which prevented connection reuse.

Does any of our generated code have this bug?

Looks like yes :I

I'll investigate what it'll take to fix the generated stuff before I close #404. Though depending on the fix, it may be that it makes more sense to file a bug on the generator or in Azure/go-autorest instead of tying this issue.

Agreed fixing the generator should be tracked with a separate issue.

I think we'll need to add a ByReading() RespondDecorator. I think it is not needed in funcs that use ByUnmarshallingJSON().

Agreed, I took particular care to never apply the readBody() (now readAndCloseBody()) to any function that has its own use for the response body.

I just tinkered around a little (and copied my experiment here.) I verified that there is no harm in reading something that has already been read to completion, but hasn't yet been closed. For that reason, I believe the correct fix for other parts of the repository is to update the ByClosing() decorator to first read and discard the contents of response.Body.

Once I actually started playing around, I decided it may fit the pattern better to create a new decorator called ByDiscardingBody(). Thoughts, @mcardosos ?

I like it. I would prefer not to modify ByClosing().


Cannot use linked Failure UI dump

Description
Cannot use linked Failure UI dump
Steps to reproduce
If you have some failed test in test report (Android mobile)
There's a link to download UI dump

But only one file is downloaded meanwhile to build an element tree 2 files are required

Environment
ui v.1.32 | server v.4.1.84 | client v.4.1.65

already fixed. zip archive contains sreen and uix file


Spare parts

While reflashing one of our robots we snapped the threaded stud of one of the black colums (Standard Edition). How can we purchase a couple of these colums and also suitable screws for mounting the top plate?

Please email our customer support at<EMAIL_ADDRESS>They will provide you with replacement parts.


Kotlin Coroutines Support

This is an initial PR for supporting another template to generate Kotlin-coroutines code.
I'd love to get some early feedback from @macisamuele before I continue working on this to decide how we want to setup the project.
I'm not a big fan of copying all the .mustache files over, so we should probably re-organize them in subfolders?
What's missing:

[ ] Tests
[ ] Updated the readme
[ ] Add a kotlin-coroutines to the samples

@cortinico we already discussed about the PR in person, but it would be better to keep a trace over here as well.
I do like the idea of having a new "template" that allows generation of coroutine based code.
Duplicating code and templates as provided in this PR could be a possibility but I do expect higher maintenance costs.
What if we do have a generic KotlinGenerator that will be extended by two independent generators (ie: KotlinRxJavaGenerator and KotlinCoroutineGenerator)?
By doing so we can ensure that all the kotlin specific details are defined once and reused.
The needed additions would be:

having a method that given the output type generates the appropriate string (ie. Type -> Single<Type>|Completable|Defer<Type>|Type according to the case)
templating the method modifiers to allow injection of suspend  keyword in the API methods generation

NOTE: Doing something like this will then require a major release as the original currently existing template would not be usable anymore

After some discussion with @macisamuele we feel more comfortable pushing this to a future release

@cortinico are you planning to release this sooner?

@cortinico are you planning to release this sooner?

I'm currently looking for feedback on this. I would be interested in understanding if you're planning to use this modified template.
Adding coroutines support is quite straightforward, but it's yet another template that we have to maintain. Having active users that are the template is a valid reason to spend effort on it.
Regarding the timeline, ideally we can manage to have this merged and have a new release by the end of November.

I would love to use this, but I need it ASAP. Currently I'm using Swagger Codegen which has Kotlin coroutine support already.
I can't, however, force it to use ThreeTenABP LocalDate type instead of string for date fields. And it seems it will not be resolved in the foreseeable future :(
Is there a way to generate code with this pull request? I don't know how to download entire repository, patched with a specific PR out of GitHub. Also this codegen is used through Gradle I noticed. That makes it even more difficult for me then. At least a believe so. I'm new to Android Studio, Gradle and all, sorry.
Thanks

Hi all, please find a production-ready version of the coroutines support. Other than @macisamuele 's feedback I'd love to get an ack from either @redwarp or @filipemp.
I've took a different approach from the first commit. We now don't need to clone the entire .mustache file hierarchy.

@cortinico are you planning to release this sooner?

This will be in the upcoming release @chathudan, unless we find a major blocker during the review.

I would love to use this, but I need it ASAP.

@StevenKek apologize for the delay but I took a 2 months sabbatical and I haven't really checked my Github notifications :/  Ideally we're going to ship this soon and you'll have it bundled in the upcoming release.

Is there a way to generate code with this pull request?

You could checkout the fork and install the gradle plugin inside your maven local. It's doable but a bit complicated to setup. If you're not in a hurry, I advice you wait for the upcoming release.

Very nice approach to the problem.
Reduce template duplication while preserving consistency and expandability!

Awesome! Thanks for the approval.
Let's wait for an ack from either @redwarp or @filipemp


Unable to write in any types

Hi,
I'm trying to create a database following the field-manual, but when I try to add data in any type of databases I'm always getting the error:
Error: Could not append entry, key "...790e06f" is not allowed to write to the log.
I was looking some old issues and my code looks like this solutions, but still fails
The databases are created as follow:
        this.node = await this.IPFS.create({
            preload: { enabled: false },
            repo: './ipfs',
            EXPERIMENTAL: { pubsub: true },
            config: {
                Bootstrap: [],
                Addresses: { Swarm: [] }
            }
        })
        this.orbitdb = await this.OrbitDB.createInstance(this.node)
        this.defaultOptions = { accessController: { type: 'ipfs', write: ['*'] } }
        const docStoreOptions = {
            ...this.defaultOptions
        }
        this.products = await this.orbitdb.keyvalue('products', docStoreOptions)
        this.steps = await this.orbitdb.eventlog('steps', docStoreOptions)
        await this.products.load()
        await this.steps.load()

And saving the data with this function:
    async addProduct(productId, product) {
        const hash = await this.products.put(productId, product)
        return hash
    }

    const hash = await orbit.addProduct(1, {
        property1: 1,
        property2: 2,
        property3: 3,
        property4: 4,
    })

Database is created but always gives the same error on save data.
Im using     "ipfs": "^0.47.0" and  "orbit-db": "^0.24.2" versions.
Thanks

Hi @ialberquilla, this is a bug documented in here: https://github.com/orbitdb/orbit-db-keystore/issues/45 .
It will say how you can patch this manually until a new version is released.

Thanks @tabcat I changed the secp256k1 version on my project to 3.8.0, and added as dependency and It's working now.
Thanks!

downgrade<EMAIL_ADDRESS>@ialberquilla https://github.com/orbitdb/orbit-db/issues/813

hi again @ialberquilla :wave: is this resolved?

hey @tabcat, yes it's resolved


Span opportunities

Check the opportunities with the new Span<T>
see http://adamsitnik.com/Span/
@snakefoot any thoughts on this?

Not sure if iteration of string-chars will be faster when AsSpan from https://www.nuget.org/packages/System.Memory/.
But I guess if you need to do some logic on sub-string, then it will be faster to operate on the Span instead of allocating the sub-string. But I have not found many places where SubString is used, where one doesn't want the string-allocation.
For normal arrays, then we already have ArraySegment as a non-allocating way to operate on a sub-array.

The TemplateEnumerator uses SubString ;)

The TemplateEnumerator uses SubString()

Do you mean the SubString() in ParseFormat() ? If so then you want the string-allocation for the format-string.
I guess you could avoid the string-allocation of common format-strings, but again this could mean caching (similar to string-intern) and Span cannot be used as cache-key.

was thinking you could making the "new string" lazy until needed. (as in at rendering).
But have to read more about Span<T> first

was thinking you could making the "new string" lazy until needed

Span<T> can only be on the stack (Cannot be stored on a class-object). If you want lazy-handling, then you need something like this:
struct HoleName
{
     string MessageTemplate;
     int HoleNameStartIndex;
     int HoleNameLength;
}

But then the PropertiesDictionary is going to be even more funky (unreadable).
One could consider having an MruCache of Hole-names as the dictionary-lookup will be faster than string-allocation (And the same hole-names will be very frequent). The problem is that very few caches are super concurrent, and will instead introduce a penalty when multi-threaded.

Thanks for the input @snakefoot
Closing this, as there isn't something to do here


handle cases where filetype icon highlight is not set

fixes #587 ?

Yup, just tested it and the error #587 is gone.


Installation error - Mac OSX 10.12.02

Command "/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5 -u -c "import setuptools, tokenize;file='/private/var/folders/7l/wb6q7lsx05s7j7bdrcl41__00000gn/T/pip-build-t6arf64t/kivy/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /var/folders/7l/wb6q7lsx05s7j7bdrcl41__00000gn/T/pip-vdyc2685-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /private/var/folders/7l/wb6q7lsx05s7j7bdrcl41__00000gn/T/pip-build-t6arf64t/kivy/
Using Python 3.5 I receive the above error when running:
USE_OSX_FRAMEWORKS=0 pip3 install kivy

@bagonzalo are you also @yiyongooi?
If not please see Issue #4936 . We need out put from either you or the other user in a more complete and readable manor; before either of your issues can be addressed.
@dessant I recommend closing this issue; and that we track it in #4936 .


Update Readme.md

Updated the Readme.md to have better info.

Note: this is my first ever pull request, so sorry if I did something wrong.

Note: this is my first ever pull request, so sorry if I did something wrong.

no issues


keep getting "Original error: Cannot read properties of undefined (reading 'match')" when i try to use flutter driver

Hi!
I am able to run appium with uiautomator2 driver, but when i change to flutter driver i get this error and the apk (AUT) is not open on the emulator.
I want to use the flutter driver so i will be able to communicate with all the elements.
this is the JSON created from the Desired Capabilities in appium:
{
"platformName": "Android",
"appium:platformVersion": "12.0",
"appium:deviceName": "Pixel 5",
"appium:automationName": "flutter",
"appium:app": "C:\Users\**************************************.apk",
"appium:noReset": "false",
"appium:maxRetryCount": "20",
"appium:retryBackoffTime": "500"
}
this is the error i get:
"Failed to create session. An unknown server-side error occurred while processing the command. Original error: Cannot read properties of undefined (reading 'match')"
Thanks for any help!

Could you share the full server log as GIST?
I'd use the latest one out if you haven't tried it yet. Please use Appium 2 to use the latest one.

https://gist.github.com/Ben171717/78ff132069183487858b387edea0f135
and yes, i use appium 2.
Thanks!

Could you try out the latest flutter driver?

Thanks @KazuCocoa
I had the same issue with Flutter driver version 1.0.1 while the app side uses Flutter framework 3.0.
When I upgrade to latest Flutter driver, it worked well.
appium driver update flutter
✔ Checking if driver 'flutter' is updatable
✔ Checking if driver 'flutter' needs an update
✔ Installing 'flutter' using NPM install spec<EMAIL_ADDRESS>✔ Updating driver 'flutter' from 1.0.1 to 1.6.0

im using appium flutter driver version 1.5.0

It seems no, your local env used 1.0.1.
C:\Users\msbit>appium -p 4723
[Appium] Welcome to Appium v2.0.0-beta.35
[Appium] Attempting to load driver xcuitest...
[debug] [Appium] Requiring driver at C:\Users\msbit\.appium\node_modules\appium-xcuitest-driver
[Appium] Attempting to load driver uiautomator2...
[debug] [Appium] Requiring driver at C:\Users\msbit\.appium\node_modules\appium-uiautomator2-driver
[Appium] Attempting to load driver flutter...
[debug] [Appium] Requiring driver at C:\Users\msbit\.appium\node_modules\appium-flutter-driver
(node:18660) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)
[Appium] Appium REST http interface listener started on <IP_ADDRESS>:4723
[Appium] Available drivers:
[Appium]   -<EMAIL_ADDRESS>(automationName 'XCUITest')
[Appium]   -<EMAIL_ADDRESS>(automationName 'UiAutomator2')
[Appium]   -<EMAIL_ADDRESS>(automationName 'Flutter')
[Appium] No plugins have been installed. Use the "appium plugin" command to install the one(s) you want to use.
[HTTP] --> POST /session

maybe this is the reason.
when i run appium server it says that flutter is 1.0.1 version.
but in my packege.json i see 1.5.0.
should i downgrade to 1.0.1?

so i updated flutter driver to 1.6.0 but still get the same error.
[Appium] Available drivers:
[Appium]   -<EMAIL_ADDRESS>(automationName 'XCUITest')
[Appium]   -<EMAIL_ADDRESS>(automationName 'UiAutomator2')
[Appium]   -<EMAIL_ADDRESS>(automationName 'Flutter')
[Appium] No plugins have been installed. Use the "appium plugin" command to install the one(s) you want to use.

ok we are making some progress. now i see this in cmd:
[FlutterDriver] "ext.flutter.driver" is not found in "extensionRPCs" ["ext.ui.window.scheduleFrame","ext.dart.io.getHttpEnableTimelineLogging","ext.dart.io.setHttpEnableTimelineLogging","ext.dart.io.httpEnableTimelineLogging","ext.dart.io.getSocketProfile","ext.dart.io.startSocketProfiling","ext.dart.io.pauseSocketProfiling","ext.dart.io.socketProfilingEnabled","ext.dart.io.clearSocketProfile","ext.dart.io.getVersion","ext.dart.io.getHttpProfile","ext.dart.io.getHttpProfileRequest","ext.dart.io.clearHttpProfile","ext.flutter.reassemble","ext.flutter.exit","ext.flutter.connectedVmServiceUri","ext.flutter.activeDevToolsServerAddress","ext.flutter.platformOverride","ext.flutter.brightnessOverride","ext.flutter.timeDilation","ext.flutter.evict","ext.flutter.invertOversizedImages","ext.flutter.debugPaint","ext.flutter.debugPaintBaselinesEnabled","ext.flutter.repaintRainbow","ext.flutter.debugDumpLayerTree","ext.flutter.debugDisableClipLayers","ext.flutter.debugDisablePhysicalShapeLayers","ext.flutter.debugDisableOpacityLayers","ext.flutter.debugDumpRenderTree","ext.flutter.debugDumpSemanticsTreeInTraversalOrder","ext.flutter.debugDumpSemanticsTreeInInverseHitTestOrder","ext.flutter.profileRenderObjectPaints","ext.flutter.profileRenderObjectLayouts","ext.flutter.debugDumpApp","ext.flutter.showPerformanceOverlay","ext.flutter.didSendFirstFrameEvent","ext.flutter.didSendFirstFrameRasterizedEvent","ext.flutter.fastReassemble","ext.flutter.profileWidgetBuilds","ext.flutter.debugAllowBanner","ext.flutter.debugWidgetInspector","ext.flutter.inspector.structuredErrors","ext.flutter.inspector.show","ext.flutter.inspector.trackRebuildDirtyWidgets","ext.flutter.inspector.trackRepaintWidgets","ext.flutter.inspector.disposeAllGroups","ext.flutter.inspector.disposeGroup","ext.flutter.inspector.isWidgetTreeReady","ext.flutter.inspector.disposeId","ext.flutter.inspector.setPubRootDirectories","ext.flutter.inspector.setSelectionById","ext.flutter.inspector.getParentChain","ext.flutter.inspector.getProperties","ext.flutter.inspector.getChildren","ext.flutter.inspector.getChildrenSummaryTree","ext.flutter.inspector.getChildrenDetailsSubtree","ext.flutter.inspector.getRootWidget","ext.flutter.inspector.getRootRenderObject","ext.flutter.inspector.getRootWidgetSummaryTree","ext.flutter.inspector.getDetailsSubtree","ext.flutter.inspector.getSelectedRenderObject","ext.flutter.inspector.getSelectedWidget","ext.flutter.inspector.getSelectedSummaryWidget","ext.flutter.inspector.isWidgetCreationTracked","ext.flutter.inspector.screenshot"]
[FlutterDriver] Waiting 3 seconds before trying...

@Ben171717 PLease check this: https://github.com/appium-userland/appium-flutter-driver#usage

Your Flutter app-under-test (AUT) must be compiled in debug or profile mode
Your app should have enableFlutterDriverExtension() before runApp

Potentially your project does not have flutter_driver dependency in the dev dependencies, too.
  flutter_driver:
    sdk: flutter

i already ask the dev to do those actions and the sent me the following screenshots:

is there something wrong?

hm, then I have no good idea for now.. The app under test package did not load the ext.flutter.driver. I observed the loading took a few seconds on my env sometimes, but then the module load completed a few retry in current logic.

now i get this error.
after i updated flutter driver in both CMD and VSCode(package.json) to 1.6.0

No idea right now. We should figure out why ext.flutter.driver is not in your package. The typical reason is https://github.com/appium-userland/appium-flutter-driver/issues/317#issuecomment-1208877630, but your case succeeded in attaching to the ws://<IP_ADDRESS>:44409/Ql8v3pcZceE=/ws. It means the comment thing should be ok.

I get this error if the app isn't closed. The reason this happened to me is because driver.deleteSession() doesn't actually close the app for some reason. I have to close the app manually between each test run or else I get this .match error

Hey! Having the same issue yesterday, just updated to appium 2 and now it works

face the same issue with appium 2 and the latest flutter driver 1.9

Did your logcat (Android) or sytemlog (iOS) have observatory URL matched with https://github.com/appium-userland/appium-flutter-driver/blob/338765cfe4786f233ef83692100eaf982fffafb8/driver/lib/sessions/observatory.ts#L178-L184 ?

The latest version has another error message.
https://github.com/appium-userland/appium-flutter-driver/blob/main/driver/lib/sessions/observatory.ts#L190-L193
Close this ticket to separate newer version's issue or old one (which should try out the latest one first)


Updated documentation to cover Enumeration mock

Codecov Report

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

@@           Coverage Diff            @@
##             master     #24   +/-   ##
========================================
  Coverage      80.6%   80.6%
  Complexity      506     506
========================================
  Files            61      61
  Lines          1346    1346
  Branches        212     212
========================================
  Hits           1085    1085
  Misses          165     165
  Partials         96      96

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 063055b...e5be45a. Read the comment docs.

Thanks!


Sara new sim

added in simulated data.

Still need to add in mapping code to map cell types from matrices to others.

Closes #133.


[Doc] OS Installation Requirements

Doris operating system requirements before installation
Proposed changes
Issue Number: close #xxx
Problem Summary:
Describe the overview of changes.
Checklist(Required)

Does it affect the original behavior: (No)
Has unit tests been added: (No)
Has document been added or modified: (No)
Does it need to update dependencies: (No)
Are there any changes that cannot be rolled back: (No)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

LGTM


Add additional tests

Current dependencies on/for this PR:

main

PR #137   👈

This comment was auto-generated by Graphite.


Allow backdoor login for admins as a user for diagnostic and migration purposes

We are using a less manual migration process. @dtarb do you still want to implement this backdoor?

@ironfroggy this has been inactive for a long time.  I think it is not needed.  Please either close or re-motivate the need for this with specifics you had in mind.


Tanx16 add s3 upload image feature

This implements https://github.com/mandatoryprogrammer/TrustTrees/issues/22.
Users can now use -u [prefix],[bucket] to specify an s3 bucket to upload the graph to.

Missed this email, I will 👀


Possible Config issue on netcoreapp 2.0

Dictionary Enumerator is a bit weird as it can be two types; depending on what interface it is accessed on
Environment variables can also return a HashSet which is why it needs DictionaryEntry rather than KeyValuePair
Previously this code would work fine aspnet/Configuration
internal void Load(IDictionary envVariables)
{
    Data = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);

    var filteredEnvVariables = envVariables
        .Cast<DictionaryEntry>() // Errors
        .SelectMany(AzureEnvToAppEnv)
        .Where(entry => ((string)entry.Key).StartsWith(_prefix, StringComparison.OrdinalIgnoreCase));

    foreach (var envVariable in filteredEnvVariables)
    {
        var key = ((string)envVariable.Key).Substring(_prefix.Length);
        Data[key] = (string)envVariable.Value;
    }
}

However trying to use it with latest netcoreapp errors as follows
Unable to cast object of type
'System.Collections.Generic.KeyValuePair`2[System.String,System.String]'
to type 'System.Collections.DictionaryEntry'.

Unhandled Exception: System.InvalidCastException: Unable to cast object of type 'System.Collections.Generic.KeyValuePair`2[System.String,System.String]' to type 'System.Collections.DictionaryEntry'.
   at System.Linq.Enumerable.<CastIterator>d__35`1.MoveNext()
   at System.Linq.Enumerable.<SelectManyIterator>d__159`2.MoveNext()
   at System.Linq.Enumerable.WhereEnumerableIterator`1.MoveNext()
   at Microsoft.Extensions.Configuration.EnvironmentVariables.EnvironmentVariablesConfigurationProvider.Load(IDictionary envVariables)
   at Microsoft.Extensions.Configuration.ConfigurationRoot..ctor(IList`1 providers)
   at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
   at Microsoft.AspNetCore.Hosting.WebHostBuilder..ctor()
   at LargeResponseApp.Startup.Main(String[] args)

Not sure if is typeforwarding issue (e.g. don't have everything in sync); 2.0 api changes, jit change, Linq optimization, eviorment vars change etc
https://github.com/dotnet/corefx/issues/16713

Closing as external since the corefx issue has been resolved.


Why not render to the document.body?

With the advent of new tech comes new opportunities, so I'm just wondering, if all gets modernized and re-invented, why not make the DOM faster by rendering/mounting directly into the document.body. Why not FIX this, IMO, broken pattern for good.
What I mean is: instead of having
<!-- the current output markup -->
<html>
  <head />
  <body>
    <div id="root">
      <header />
      <main />
      <footer />
    </div>
  </body>
</html>

with mounting directive render(App, document.getElementById('root'))...
We should have
<!-- the desired output markup -->
<html>
  <head />
  <body>
    <header />
    <main />
    <footer />
  </body>
</html>

with mounting directive render(App, document.body).
Wouldn't this make more sense for a faster and more modern things to come with say... SolidStart or Vite examples?
PS: I've asked you Ryan during your last stream but you ignored it, probably for good reason.

It honestly doesn't matter a ton except it reduces diffing top level. If we render to body we end up diffing the other script tags and things added to the body and because Solid doesn't know about them we end up possibly removing them. This was just ensure things were cleaner. I believe current start uses document.body but I changed it because I was I think getting annoyed at hydration scripts disappearing.


Potential bug with mapped types and type guards

Not sure if this is a bug or the intended behavior, but typeguards don't seem to be working on a mapped type value.
TypeScript Version:  2.1.5
Code
function fun<T>(item: { [P in keyof T]: T[P] }) {
    const strings: string[] = [];
    for (const key in item) {
        const value = item[key];
        if (typeof value === "string") {
            strings.push(value);
        }
    }
}

Expected behavior:
value should be assignable to string
Actual behavior:
error TS2345: Argument of type 'T[keyof T]' is not assignable to parameter of type 'string'.

This ought to work given that T[P] has no constraint and could be a string.


conda-suggest-conda-forge 2020.9.16

Merge only after success.
This pull request was auto-generated by rever

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.