Add onScroll callback for iOS & Android

This code was mostly extracted from https://github.com/react-native-community/react-native-webview/pull/202
I tried and tried to make it work with Animated.event's useNativeDriver, but I was unsuccessful 😢 that'll have to be done later once I understand better how Animated's native stuff is hooked up.

I'm a bit worried that we will overload the bridge with such behavior. This should only trigger event if onScroll is defined right? We might also want to implement https://facebook.github.io/react-native/docs/scrollview#scrolleventthrottle

Yeah it should only happen if onScroll is passed in. I agree supporting scrollEventThrottle would be nice too

scrollEventThrottle can be a separate PR if there's a noticeable performance bottleneck. I'd be fine with merging this. 👍

When is this going to merge?

Failed to build with RN 0.59.8, seems like ScrollEventType.SCROLL.getJSEventName() should be ScrollEventType.getJSEventName(ScrollEventType.SCROLL) ?

Fixed in 6.0.1 @ouabing

@Titozzz  @jaredly this is 5 years ago, but has there been progress on how to update the implementation to support useNativeDriver: true?

Got iOS working with
<AnimatedWebView
 onScroll={Animated.event([{ nativeEvent: { contentOffset: { y: animatedScrollYRef.current } } }], {
   useNativeDriver: true, // only false worked
})} />

In RNCWebViewManager.m add
RCT_REMAP_VIEW_PROPERTY(contentOffset, scrollView.contentOffset, CGPoint)

I struggled with Animated.createAnimatedComponent(WebView), because the exported component is a fn component, but a simple class wrapper seem to loose the ref... (getNode isn't working).
I updated WebView.ios.tsx
const RNCWebView = Animated.createAnimatedComponent(_RNCWebView);

useNativeDriver: true then started working


Add comment about inspect output

Signed-off-by: Qiang Huang<EMAIL_ADDRESS>

Related to #13508
ping @thaJeztah @duglin

LGTM

Thanks! LGTM (after the builds pass)

LGTM thanks


Not an issue Happy Holidays

This is just a sincere thank you for an awesome/ much needed module that should be part of coffeelint by default. Thanks again.

Thanks for the well-wishes! Great to hear something I built is actually useful to people


Section 3 CFG paper correction and question

I think the subtracted error estimate e_φ(x_t, t, ∅) should be written as e_φ(x_t; ∅, t) to match the other quantities in the expression.
Can you explain why e_φ(x_t; y, t) is added twice in the classifier free guidance?

Hi, thanks for pointing that out. It is a typo, and please refer to #2


const_fn: feature has been removed

I'm getting
$HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/ruspiro-arch-aarch64-0.1.4/src/lib.rs:10:22
|
10 | #![feature(llvm_asm, const_fn)]
|                      ^^^^^^^^ feature has been removed
|
= note: split into finer-grained feature gates
when compiling using:
rustc 1.55.0-nightly (7a16cfcff 2021-07-11)
same happens in ruspiro-mmio-register-0.1.2, so i don't double-post it there ... HTH

Hi,
thanks for raising this issue. It happens that I'm kind of behind the actual release schedule of the rust programming language 😊. However, I'll take a look and provide a fix as soon as possible.


Cranelift: add stack_switch CLIF instruction

This PR adds a new CLIF instruction for switching stacks. While the primary motivation is to support the Wasm stack switching proposal currently under development, the CLIF instruction here is lower level and thus intended to be useful for general-purpose stackful context switching (such as implementing coroutines, fibers, etc independently from the Wasm stack switching proposal).
This PR only adds support for the instruction on x64 Linux, but I'm planning to add support for more platforms over time. The design of the instruction should be sufficiently abstract to support all the other platforms.
While work is currently under way to implement Wasm stack switching in Wasmtime here and indeed uses the CLIF instruction introduced by this PR successfully, it seems worthwhile just upstreaming the CLIF instruction by itself. The proposal is not fully finalized yet, and this CLIF instruction seems useful on its own and independent from the remainder of the Wasm proposal.
Concretely, the CLIF instruction looks as follows:
out_payload = stack_switch(store_context_ptr, load_context_ptr, in_payload)

This causes the following to happen:

The current execution context is saved: The current frame pointer, stack pointer and PC after the stack_switch instruction are stored at store_context_ptr. All other registers are marked as clobbered and thus spilled by regalloc as needed.
We load a new (SP, FP, PC) triple from load_context_ptr, indicating the stack/context to switch to. We assume that we are either switching to a stack that was either previously switched away from by another stack_switch, or it's a newly initialized stack.
The value in_payload is passed over to the other stack. In other words, if the instruction above switches from some stack A to another stack B, then the return value of the stack_switch instruction previously executed on B will be in_payload.
Execution continues on stack B.
If we ever switch back to stack A, the value out_payload above (i.e., the return value of the stack_switch executed when leaving stack A) is the payload argument passed to the corresponding switch.

A few additional notes:

store_context_ptr and load_context_ptr can be seen as pointers to what is conceptually a three-element struct, containing SP, FP, PC.
The pointers store_context_ptr and load_context_ptr are allowed to be equal. In particular, in steps 1 and 2 above, we ensure to actually load all required data from load_context_ptr before storing to store_context_ptr.
As mentioned above, there are two cases in step 2: We either switch to code where a matching stack_switch was executed, or to a new stack

If we switch back to (right behind) a previous stack_switch instruction, then regalloc has spilled all subsequently needed SSA values for us, no need to manually restore any context besides SP, FP, PC.
If we are executing on a new stack, we assume that execution starts inside a stack-switch aware trampoline

Payloads are currently hard-coded to be a single, word-sized value. That may seem arbitrary, but it's simply what's needed for our current implementation of Wasm stack switching on top of this CLIF instruction. It could later be extended to more general cases, if necessary.
The stack switching implemented here is "one-shot": If you execute a stack_switch to switch from a stack A to a stack B, we can only switch back to A once (unless we subsequently execute another stack_switch on A again).
This is different from setjmp/longjmp, where we may store the context once using setjmp and then return to it multiple times using longjmp without needing to call setjmp again.

I'm marking this as "ready for review" now, but I have a few questions about things that will probably require additional fixes before this is actually ready:

Currently, the instruction is lowered by very simple rules in codegen/src/isa/x64/lower.isle. However, the emitted code is only valid for x64 Linux, not x64 Windows.
This means that I should probably do something similar to function calls, where my instruction is lowered using an external gen_stack_switch function. What's the cleanest way to simply refuse lowering on x64 Windows for the time being?
The layout of the data read and written by the instruction is described in the new file codegen/src/isa/x64/inst/stack_switch.rs, given that the information in that file is platform-specific. However, I'm not sure if that's the right place for that file. I imagine that the content of that file will either be split up in the future, or move somewhere else to collect the layout information for all platforms.
When emitting code for the new instruction on x64, we need two temporary registers. Currently, this is done without regalloc (see my comment in emit.rs): If I try to add any early def to my StackSwitch MInst to get temporary registers, regalloc2 fails with TooManyLiveRegs. I suspect this is just a result of the rather unique set of constraints on StackSwitch. I'm curious if there's an existing issue I could mention, a more elegant workaround than what I'm currently doing, or if I should open a new issue regarding this in the regalloc2 repo.
In instructions.rs, I'm giving stack_switch all kinds of scary side effects (namely, .other_side_effects(), .can_load(), .can_store()), given that it continues execution elsewhere, where arbitrary things may happen.
I'm wondering what a more accurate description of the side effects would be. The .call() side effect seems related, but I was unsure if using that would have unintended consequences.
I've added a filetest for the new instruction but it turned out quite monstrous: It uses stack_switch in two functions where we create enough SSA values to exceed the number of available registers before the switch, and then use all of them after the stack switch. I've manually verified the generated assembly, but I'm wondering if people prefer having a shorter test case that makes it easier to verify the assembly for the stack switching itself.
My StackSwitch MInst takes its inputs as Gprs. These values all end up in registers during code emission anyway, but I was wondering if it would be more idiomatic to make the MInst use GprMem or RegMem, then deal with moving things into registers during emission.

Super excited for this! Haven't taken a look at the actual code yet, but here are some answers to the questions in your comment above.

However, the emitted code is only valid for x64 Linux, not x64 Windows. ... What's the cleanest way to simply refuse lowering on x64 Windows for the time being?

Will the lowering work for all posix right now or only Linux? Will macos work, for example? We should be precise about the correctness condition here.
Cranelift doesn't generally care what OS it is targeting beyond calling conventions and a few other ABI details here and there, and AFAIK we've never needed OS-specific lowering rules before, so this is sort of untrodded ground.
A TargetIsa does have a triple method, which returns a target_lexicon::Triple, which in turn has an operating_system member. You could try plumbing that stuff through to an external partial constructor for use in ISLE if-lets.

The layout of the data read and written by the instruction is described in the new file codegen/src/isa/x64/inst/stack_switch.rs, given that the information in that file is platform-specific. However, I'm not sure if that's the right place for that file. I imagine that the content of that file will either be split up in the future, or move somewhere else to collect the layout information for all platforms.

I think describing the layout of that data would be best done in the documentation for the new instruction itself.
I haven't looked at the actual code in this PR, but I'd expect that the only platform-specific bits would be pointer size, and otherwise we are always saving SP, optionally FP when frame pointers are enabled, and PC. Is that assumption incorrect? Are we, or will we be, saving more/fewer values on different platforms?
I also would expect that we wouldn't actually need to explicitly define all the details of this data and its layout. I'd imagine we would only say that it has a given size and alignment, and is otherwise only valid to be manipulated via the stack_switch instruction. That is, it should be opaque to the host.
But maybe something like stack walking means that the runtime needs to be able to peek inside this data, and we can't keep it opaque to the host?

When emitting code for the new instruction on x64, we need two temporary registers. Currently, this is done without regalloc (see my comment in emit.rs): If I try to add any early def to my StackSwitch MInst to get temporary registers, regalloc2 fails with TooManyLiveRegs. I suspect this is just a result of the rather unique set of constraints on StackSwitch. I'm curious if there's an existing issue I could mention, a more elegant workaround than what I'm currently doing, or if I should open a new issue regarding this in the regalloc2 repo.

I think we've had similar-ish issues opened in the past for regalloc2. None the less, I'd recommend opening an issue there and we can dedupe it if necessary. That will also get eyes on the problem from folks who are more familiar with our register allocator than I am.

In instructions.rs, I'm giving stack_switch all kinds of scary side effects (namely, .other_side_effects(), .can_load(), .can_store()), given that it continues execution elsewhere, where arbitrary things may happen.
I'm wondering what a more accurate description of the side effects would be. The .call() side effect seems related, but I was unsure if using that would have unintended consequences.

I think we also want to have the call() side effect because, for these instructions, we will want to do call-related things like

clear all memory aliasing info, assuming that external code we "call" could alias anything
treat the instruction as a GC safepoint, spill GC refs to the stack, and emit a stack map for this location
etc...

I've added a filetest for the new instruction but it turned out quite monstrous: It uses stack_switch in two functions where we create enough SSA values to exceed the number of available registers before the switch, and then use all of them after the stack switch. I've manually verified the generated assembly, but I'm wondering if people prefer having a shorter test case that makes it easier to verify the assembly for the stack switching itself.

I don't think having a big filetest is a problem in itself per se, but I think we should also have a very basic filetest that is effectively just the stack_switch instruction and its disassembly. Basically, a function that takes all the stack_switch operands as arguments and returns the out_payload, and is just a single basic block with a single stack_switch instruction. This gives us a smoke test for the basic lowering and its disassembly.

My StackSwitch MInst takes its inputs as Gprs. These values all end up in registers during code emission anyway, but I was wondering if it would be more idiomatic to make the MInst use GprMem or RegMem, then deal with moving things into registers during emission.

Things like GprMem are useful for x64 instructions like add where one of the operands can naturally be either in memory or a register. When we are lowering an add with a memory operand, we don't force the memory into a register during emission, we emit an instruction that operates directly on the memory. It wouldn't make sense to take a GprMem operand for add if the x64 instruction(s) we emit can't operate directly on memory.
So for the x64 MInst.StackSwitch instruction, my questions would be:

Can the instruction sequence it emits operate directly on memory, or must they have the operand in a register?
Is the emitted instruction sequence accessing the value once or multiple times?

If the answer to these questions are "can operate directly on memory" and "accessing the value once" then I'd say a GprMem makes sense. Otherwise, I think a Gpr is the way to go.
FWIW, it is also fine to start with just Gpr operands and then investigate whether it makes sense to upgrade to a GprMem in follow up PRs.

Thanks for your answers and looking at the code! I'll look into the things you suggested.
In the meantime, some more thoughts regarding the layout of the contexts: On most platforms, the context can indeed look like this:
pub struct ControlContext {
    pub stack_pointer: *mut u8,
    pub frame_pointer: *mut u8,
    pub instruction_pointer: *mut u8,
}

However, there are two reasons for why the layout may be different somewhere:
1. Additional info needed on Windows
On Windows, I think we would have to update data inside the "Thread Information Block" (the stuff we briefly talked about with Ryan Hunt at the Pittsburgh CG meeting). I haven't looked too deeply into it, but it looks like it contains pointers to the beginning and end of the currently active stack, which we would need to update when switching. That means that I suspect we would have to add these to the ControlContext on Windows.
In any case, it looks like we would need Windows-specific lowering rules for x64, just to emit the logic for updating the Thread Information Block.
2. Frame pointer walking
There's another issue that I've briefly mentioned in a comment in the new file stack_switch.rs, but haven't provided much detail on (mostly because it requires dumping a bunch of extra info on you, sorry!):
I made sure that the ControlContext above is laid out in a way so that it can appear inside a frame pointer chain. This is so that for stack switching approaches where you do have parent-child relationships between stacks, these are reflected in the stack trace you get just from frame pointer walking, by creating a single continuous chain crossing stacks. In other words, tools like lldb show you the frames of the active stack, but also the frames in its parent.
(There's been a recent development in the Wasm stack switching subgroup making it very likely that at least for Wasm stack switching, we will end up with a proposal where there are parent-child relationships between all the active stacks.)
Concretely, in our implementation of Wasm stack switching, this is achieved like this:
Imagine we have allocated memory from 0x1000 to 0xB000 which we want to use for a new stack S. We store a ControlContext at the very top of that allocation at 0xAFE8, with the actual stack space starting below it. When starting execution in the new stack, we will then have RSP = 0xAFE0 in the trampoline that kicks off execution inside stack S (e.g., the trampoline calls the Wasm function that we actually want to run inside that stack).
The main idea is now that we make sure that the ControlContext at 0xAFE8 always contains the information about the parent of stack S, meaning that whenever we switch from some other stack X to S, we write information about stack X (which then becomes the parent of S) into the ControlContext at 0xAFE8.
The last missing ingredient for creating the frame pointer chain is that when  we are running the trampoline that kicks of execution inside stack S, we set RBP to 0xAFF0, which is the address of the frame pointer field inside the control context.
This means that while the trampoline is the bottom-most stack frame inside S, when passing the trampoline while walking the frame pointer chain we actually get to where X stack_switch-ed to S: At 0xAFF0 we stored the frame pointer of X, and the layout of ControlContext puts the PC saved for X right next to it, exactly where lldb and friends would expect it.
Long story short: It's quite neat to make sure that ControlContext has just the right layout to enable this trick. It allows users of the stack_switch instruction to get frame pointer walking across stacks entirely for free "simply" by carefully laying out where the contexts are actually stored and setting RBP correctly. If they don't care  or implement a stack switching approach where there are no parents, nothing is lost. But to make this possible, the layout of the ControlContext suddenly depends on not just the ISA, but whatever your platform dictates about stack layout (in particular, where to find the return address relative to the frame pointer).
Luckily, the layout above (i.e., frame pointer right next to PC) works on all platforms supported by Cranelift, except s390x: On the latter, there's an offset of 14 words between where the FP and PC are stored.
So on that platform my plan was to make the ControlContext look like this:
pub struct S390XControlContext {
    pub frame_pointer: *mut u8,
    pub stack_pointer: *mut u8,
    padding: [*mut u8; 12],
    pub instruction_pointer: *mut u8,
}

(Or just give up on frame pointer walking there)
So at least it seems that within the same ISA, all OSes sufficiently agree on the stack layout so that the frame pointer walking causes no extra hassle.
Documenting the layout

I also would expect that we wouldn't actually need to explicitly define all the details of this data and its layout. I'd imagine we would only say that it has a given size and alignment, and is otherwise only valid to be manipulated via the stack_switch instruction. That is, it should be opaque to the host.
But maybe something like stack walking means that the runtime needs to be able to peek inside this data, and we can't keep it opaque to the host?

Yes, the layout of the ControlContext can be kept mostly opaque, except for stack creation. As long as you only create and consume these contexts with stack_switch, you really don't need to know anything about them besides their size and (boring) alignment requirements.
The only situation where you do need to know about the layout is when initializing a new stack:  You need to create a corresponding ControlContext that when stack_switch-ed to executes the right trampoline on the new stack. That's why my idea was basically to leave details about the layout of the context out of the documentation of the instruction in instruction.rs, but at least have some platform-specific documentation elsewhere.
Alternatively, we could add a stack_init instruction, or instructions that act like getters and setters on the context.

I've implemented the restriction to only lower stack_switch on Linux now: Strictly speaking, it's each individual OS rather than the ISA that may require additional things needing to be done when switching stacks (see my remarks on Windows in my huge previous comment). I do believe that my current implementation would actually work on x64 macOS, but haven't tested it. So I would just stay on the safe side and make the support OS-dependent (instead of, say, allowing anything Unix-like), with the only allowed one being Linux for now.
I've implemented this using a partial constructor on_linux. The controversial bit may be that I'm now copying the Triple into every machinst::Callee. Is that acceptable?

only allowed one being Linux for now.

SGTM

The controversial bit may be that I'm now copying the Triple into every machinst::Callee. Is that acceptable?

It doesn't seem ideal. Do we not already have access to a &dyn TargetIsa in the LowerContext?

Do we not already have access to a &dyn TargetIsa in the LowerContext?

The IsleContext contains a B: LowerBackend which for x64 is a X64Backend which contains a Triple already, and all the other LowerBackend implementations also contain a Triple. I think we could add a fn triple(&self) -> &Triple trait method to LowerBackend and then reuse that in the IsleContext's implementation of the partial constructor.

I've reworked the platform dependence logic based now, inspired by what happens for TLS:
There's a new enum StackSwitchModel with values None, Basic, and UpdateWindowsTib. A value of that is saved in the backend Flags.
This value is then used when lowering a stack_switch CLIF instruction: If None, we cannot lower them. If Basic, we lower to stack_switch_basic. In the future, it will be the case that  UpdateWindowsTib causes lowering to a new dedicated MInst (like StackSwitchUpdateWindowsTib), but currently this will behave like None (i.e., we fail to lower).

@alexcrichton For some reason the automated reviewer assignment was triggered again, maybe because this PR is now touching a non-Cranelift file.

Do others have more thoughts on this? This all looks reaosnable enough to me to land, but I'd want to be sure to run by others too.

I think this is in a good enough place that we can land it and then continue with any further improvements in follow ups. Thanks @frank-emrich!

Oops, it looks like I responded to your comment and added a new commit in parallel to you approving things. But I think it should be uncontroversial, I kept None and made stack_switch_model total.

Yeah, LGTM


StaleBot configuration

I want to use https://probot.github.io/apps/stale to post reminders when pull requests haven't seen activity in a week.

@charlierudolph this PR is a good example for how StaleBot could be useful  😃
Can you please approve?


Update MessageGotServerVersion.java

In new version, need pre-init, so i added pre-init

why dont they merge it

why dont they merge it

Because i deleted my branch :v


Update Spanish WotD app to use SpanishDict

What does this MR do?
Updates the Spanish Word of the Day app to use the Word of the Day from SpanishDict.com rather than using the English word of the day from Merriam Webster and showing a translation of it.  Also makes it so it displays: [Spanish word]: [English Translation] rather than [English word]: [Spanish Translation]
Why?
I love @logancornelius 's Spanish WotD app! But, fetching an English word of the day, and then showing it's Spanish translation doesn't really feel like a true "Spanish Word of the Day" app. The English words from Merriam Webster also tended to be quite obscure, so not great for learning useful Spanish vocabulary.
This MR takes a bit of a different approach to getting a Spanish WotD. Instead of fetching an English word and then translating it to Spanish, it takes the Spanish Word of the Day from spanishdict.com and then displays the English translation from the page. I also made it so the primary display is the word in Spanish, and then the English translation is displayed below it, rather than the reverse how it is today (this is the Spanish WotD after all, right?)
This is a significant change to @logancornelius 's original app - so may have made more sense to submit as a new app rather than as a PR to this one. But, I wanted to avoid putting duplicate apps on the marketplace, so I figured I'd first submit it as an update and see how it goes. I'd love to get @logancornelius opinion before merging!
Notes
One thing to note is that SpanishDict does not have an official API, so I'm fetching the WotD by scraping the page. It looks like it's largely JS-rendered, but the data was available as JSON which made the scraping pretty easy.
Before

After

I have read the CLA Document and I hereby sign the CLA

recheck

@logancornelius any thoughts on this change? Would be happy to create a new app for this, if you want to preserve how it works today

I'm all for it! At the time I didn't find a good api for a Spanish dictionary to pull from wit a word of the day so just used the English word of the day to run off of, I like this a lot more! Great stuff

I realize you're just scraping which is great, no issue with that I just didn't set up for scraping before so this is good and fixes the issues with the app as it stands. Just to confirm I believe tidbyte has to merge this, correct, I don't think I have write access to the repo

Excellent! Glad you like the change @logancornelius! Thanks for taking a look. And yea, Tidbyt has the merge it, although approval from the original author was recommended for changes to existing apps.
@matslina Now that we have the original author's sign off, could you take a look at merging this?


Tweak the contributing guide

Our contributing guide needs some polishing after migration on sbt-typelevel-site.

@armanbilge Thanks for your valuable comments!


[Swift] Get list of DynamicObject

Hey @jpsim -- this pull request implements #2685
Wasn't sure what style you all wanted for documentation/testing so I just guestimated based on code elsewhere (sorta shooting from the hip!)
As a user I can already get this functionality myself by using an unsafeBitCast on the result of KVC, but it's nice to wrap away these types of casts so the user doesn't feel like they're doing something wrong.
Let me know what you think!

Thanks for the PR :sparkles:! It always feels awesome to see users contributing. Here are a few points of feedback:

All Swift changes should generally be applied to both Swift 1.2 and Swift 2.0 (there are two versioned RealmSwift directories in the root of the repo).
Tests should access members of the List rather than just check the empty case, since that's not comprehensive enough.

Thanks again.

Added in change to the Swift 1.2 branch and added in more robust testing -- let me know if you want more than that!
Also can't see what the failing checks are so if there are compile errors or test errors let me know so I can fix them.  I assumed there's no way for me to compile the repo to check myself because Core isn't open source, but if there's a way to compile without it I missed let me know so I can save you reading time.

We use an internal Jenkins setup for our CI, so we unfortunately can't easily share that for external contributors :cry:. This is something I'd love to address, but simply don't have the time.
But you can run the same gamut of tests we do by running sh build.sh verify assuming you have Xcode 6.4 (with iOS 7 simulators) and Xcode 7.0.1 installed on your system.
The whole set of tests take a really long time to run (we parallelize them on ~12 CI workers!), but you can usually get a good sense of whether or not things are broken by running the following small(er) tests:
./build.sh verify-osx
export REALM_SWIFT_VERSION=1.2
./build.sh verify-osx-swift
export REALM_SWIFT_VERSION=2.0
./build.sh verify-osx-swift

In your case, the Swift 1.2 tests are failing:
Testing failed:
	Consecutive statements on a line must be separated by ';'
	Consecutive statements on a line must be separated by ';'
	Use of unresolved identifier 'try'
	'List<SwiftStringObject>' does not have a member named 'appendContentsOf'
	Use of unresolved identifier 'try'

Ah great!  That's at least better than no testing at all.  Both my local tests (for swift 1.2 and swift 2.0) passed so I'll have to rely on you all again to paste errors :disappointed:

Thanks for the PR fixes, @tom-sparo! I think this could be merged after you address my last round of (nitpicky) feedback.
Our CI jobs are seeing some device test failures at the moment because we're adding some additional iOS devices and still working out some kinks, so we may merged this despite GitHub showing a red 'x'.

Fixed all feedback!

This looks all good to me, how about for you @bigfish24?

:+1: thanks for the contribution @tom-sparo!


[stable/rabbitmq] Add LDAP support to RabbitMQ

What this PR does / why we need it:
Add LDAP support to RabbitMQ
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test
/lgtm


Request to host package

This issue was originally filed by<EMAIL_ADDRESS>
https://github.com/eee-c/hipster-mvc

This issue has been moved to dart-lang/pub#253.


Added First JpaStorageProvider implementation

JPA Storage Provider
This provider materializes states in relational databases.
Requirements

The states cant be inner classes
The states must extend JpaState.class
The states must have the @Entity annotation
States classes should not be shared between Actors, each one must have its own

Note: All requirements dont affect others storage providers.
Tables
Tables are automatically created, and the jpa ddl strategy at the persistence.xml defines if the tables will be updated when a new field is created.

Thanks for your contribution @quilombodigital.

Hi @quilombodigital. Would you mind helping us configure the travis-ci build to test your contribution?
I think enabling mysql, creating a database, and using the right password are all that's necessary.
It's possible to do that in your fork and then create a pull request for travis.yml

ok. I´ll do later at night.


Unify trajectory state checks for service handlers.

Some service handlers need to check if a trajectory is in a valid
state for the requested operation. If it's not, they return an error
response.
Node::CheckTrajectoryState removes code duplication in handlers.
It generates a human-readable response message and sets the
status code depending on whether the trajectory is in one of the
valid_states.

Currently only cleans up the /finish_trajectory code, but can be used in #1245 and potential future handlers.


Update repo using new version of generator

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes: #103, #110
Summary:
Please summarize the scope of the changes you have submitted, what the intent of the work is and anything that describes the before/after state of the project.

Update repo to support Node 18+ and other modernized standards using the new version of the WC-Generator.
Add csspart to the fieldset element of auro-radio-group.

Type of change:
Please delete options that are not relevant.

[x] New capability
[x] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

Please also see this update https://github.com/AlaskaAirlines/auro-radio/pull/109/files and add to this PR.

New file requested by Dale .npmrc in an earlier comment was not addressed.
The the demoPublish workflow needs to be added.

.npmrc has already been added in a previous commit, publishDemo.yml now added.

:tada: This PR is included in version 1.7.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix relative path in custom_css & includes

/::
custom_css: ../common/assets/custom.css
::/
!include(../common/slides/common.sdf)
generates a crash

Assets management too

change path for assets


Move the collapsible 'Online' users list to the right and beautify it

Currently, the collapsible 'online' users list is on the top of the chatApp, and all messages are appended under it. The chatApp would look better with the 'online' users list on the right, collapsible or not.

I would like to work on the issue.

Great! Assigning this issue to you @aryanploxxx.

Hi @osBins, I've fixed this issue, my pull request is here: https://github.com/osBins/chatApp/pull/46
Sorry for not commenting earlier, thought I might as well share what I worked on.


OpenCL Typemaps

This is a showcase draft for the fully-typemapped OpenCL bindings.
Open issues:
It's very breaking
Includes struct type move that we've discussed and concluded that it's unwanted (necessary due to strongly typed struct fields)

This all looks really good! Obviously we can't incorporate it as is for breaking change reasons, and there's stuff we've commented on before like the struct package moves, but I think if your type mapping changes could somehow be implemented in addition to the existing code we'd have a solid update on our hands!
Obviously that's now how the TypeMapper, works, but perhaps:

Adding some state (or a dictionary of state, idk) into Profile (I know, horrible place) containing data about OpenCL typemappings. Unless proven otherwise, this can be JSON ignored.
Creating simple overloaders that inspects the extra state and the native name
Overloading accordingly

I think the way I currently feel is I'll accept this PR as is and change anything I feel necessary at update time. Won't merge until update week though as I'll forget to change BuildTools otherwise.


feat: migrate permission data

Signed-off-by: Yixiang Zhao<EMAIL_ADDRESS>

@seriouszyx resolve:


Laravel 10.x Compatibility

This is an automated pull request from Shift to update your package code and dependencies to be compatible with Laravel 10.x.
Before merging, you need to:

Checkout the l10-compatibility branch
Review all comments for additional changes
Thoroughly test your package

If you do find an issue, please report it by commenting on this PR to help improve future automation.

:warning: Shift updated your build matrix for Laravel 10. However, since you are supporting older versions of Laravel, you need to add the following exclusions:
exclude:
  - laravel: 10.*
    php-versions: 8.0

:warning: Shift updated your build matrix for Laravel 10. However, since you are supporting older versions of Laravel, you need to add the following exclusions:
exclude:
  - laravel: 10.*
    php-versions: 8.0

:warning: Shift detected GitHub Actions which run jobs using a version matrix. Shift attempted to update your configuration for Laravel 10. However, you should review these changes to ensure the desired combination of versions are built for your package.

:alembic: Using this package? If you would like to help test these changes or believe them to be compatible, you may update your project to reference this branch.
To do so, temporarily add Shift's fork to the repositories property of your composer.json:
{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/laravel-shift/laravel-messenger.git"
        }
    ]
}

Then update your dependency constraint to reference this branch:
{
    "require": {
        "cmgmyr/messenger": "dev-l10-compatibility",
    }
}

Finally, run: composer update


Implement Google Authentication for browser extension

Like shown in https://developer.chrome.com/extensions/tut_oauth

Done!


HV-1494 hibernate validator error when @NotEmpty used on return type

https://hibernate.atlassian.net/browse/HV-1494

Previous implementation were not giving a chance for composite constraints to execute if they were placed on a method with non void return type and parameters - as for those both hasGenericValidators and hasCrossParameterValidator where false and there's no way to set validationAppliesTo so ConstraintDescriptorImpl#determineConstraintType was just skipping to:
// Now we are out of luck
if ( constraintType == null ) {
  throw LOG.getImplicitConstraintTargetInAmbiguousConfigurationException( annotationType );
}

hence there was no way to use them on methods with both return value and parameters....
Let me know what you think about these changes :)

@gsmet sooo you were asking about this one in JIRA. Here's what I have atm.

closing this one in favor of https://github.com/hibernate/hibernate-validator/pull/863


Newsletters: add 63 (2019-09-11)

Edits pushed for feedback so far.  Thanks all!

Pushed edits for @jnewbery second-round feedback (thanks!).  I actually read the PR comments for block-relay-connections, rather than just the merge commit summary, and substantially rewrote this item.  John: given that we're on even more different than usual timezones and  busy with Scaling Bitcoin stuff, please feel free to edit yourself or drop this item from this week's newsletter (we can cover it next week).

tACK https://github.com/bitcoinops/bitcoinops.github.io/pull/222/commits/56822ff78520e09f4b9791a057bcfbdd7c11d729

I've pushed a commit that slightly changes the wording on the PR 15759 description.
Thanks @harding . Great newsletter.
ACK a48dfe51e839c598717f67a1172ab977d23e92f8

Edit a48dfe51e839c598717f67a1172ab977d23e92f8 LGTM.  Thanks!

A demo of eltoo from Richard Myers
BOLT11 indicates what your node requires
Our longest list of notable changes to date
On LN gossip Rusty says: "you must limit the rate!"
@harding thanks for another educational newsletter! @jnewbery @jonatack @kanzure thanks for the review input. @practicalswift thanks for volunteering to write the miniscript section! :P


Update self_reported_ethnicity_term_id

Status
See Add parent classes for ethnicity and ancestry terms for background. This update to the ontology model simplifies the schema requirements and validator.
The latest HANCESTRO release includes simplified modeling which demonstrates progress, but there are still missing terms in the ethnicity category under review.
Design
self_reported_ethnicity_ontology_term_id

Key
self_reported_ethnicity_ontology_term_id

Annotator
Curator MUST annotate.

Value

        categorical with str categories.If organism_ontolology_term_id is NOT
        "NCBITaxon:9606" for Homo sapiens, then the
        value MUST be "na".If
        organism_ontolology_term_id is
        "NCBITaxon:9606" for Homo sapiens, the value MUST be "unknown" if unavailable; otherwise, the value MUST meet the following requirements:

            The value MUST be formatted as one or more comma-separated (with no leading or trailing spaces) HANCESTRO
        terms in ascending lexical order with no duplication of terms.

            Each HANCESTRO term MUST be a descendant of "HANCESTRO:0601" for ethnicity category.

            For example, if the terms are "HANCESTRO:0590 and HANCESTRO:0580" then the value of self_reported_ethnicity_ontology_term_id MUST be "HANCESTRO:0580,HANCESTRO:0590".

URL is broken. This one works: https://www.ebi.ac.uk/ols4/ontologies/hancestro/classes/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FHANCESTRO_0601
Not sure how else to review in the absence of a plan for the existing data in the corpus that would violate the update.

I must have a github page open somewhere with an uncommitted change, because I know that I fixed that broken URL. Doh. Updated. Thanks.


toCamelCase method should handle more case

Hi, thanks to support css.module.localsConvention setting in this plugin, but i found your toCamelCase function only can handle some common case, so i fixed this function to handle more case

Thank you.


As a student who always lends money to people, I want to be able to send receipt to my loanee

... so that they will not think that I have scammed them.

This feature violates the constraints of our application NFR which allows our app to work for a single user only.


ONNX export.py

torch.onnx.errors.SymbolicValueError: Unsupported: ONNX export of instance_norm for unknown channel size.  [Caused by the value 'input.411 defined in (%input.411 : Float(*, *, *, *, strides=[3276800, 25600, 160, 1], requires_grad=0, device=cpu) = onnx::Conv[dilations=[1, 1], group=128, kernel_shape=[5, 5], pads=[2, 2, 2, 2], strides=[1, 1]](%input.407, %decode_head.neck_layer.flow_make.0.weight, %decode_head.neck_layer.flow_make.0.bias), scope: opencd.models.change_detectors.dual_input_encoder_decoder.DIEncoderDecoder::/opencd.models.decode_heads.changer.FDAF::neck_layer/mmengine.model.base_module.Sequential::flow_make/torch.nn.modules.conv.Conv2d::flow_make.0 # /data/ohsung/anaconda3/envs/changer/lib/python3.8/site-packages/torch/nn/modules/conv.py:456:0
)' (type 'Tensor') in the TorchScript graph. The containing node has kind 'onnx::Conv'.]

python tools/export.py -c configs/changer/changer_ex_r18_512x512_40k_levircd.py
-m /data/ohsung/repos/open-cd/321_S/best_mIoU_iter_800.pth
-i "1,3,640,640" "1,3,640,640"
-mn changer.onnx

I tried to run the export.py but the error came out as the abvoe one
i can't figure it out what the problem is
Can I get a help?

The error you're encountering is related to the ONNX export of the instance_norm operation with an unknown channel size in the Conv layer of your model. This is a known limitation in the current state of ONNX export for certain PyTorch operations.

torch.onnx.errors.SymbolicValueError: Unsupported: ONNX export of instance_norm for unknown channel size. [Caused by the value 'input.411 defined in (%input.411 : Float(*, *, *, *, strides=[3276800, 25600, 160, 1], requires_grad=0, device=cpu) = onnx::Conv[dilations=[1, 1], group=128, kernel_shape=[5, 5], pads=[2, 2, 2, 2], strides=[1, 1]](%input.407, %decode_head.neck_layer.flow_make.0.weight, %decode_head.neck_layer.flow_make.0.bias), scope: opencd.models.change_detectors.dual_input_encoder_decoder.DIEncoderDecoder::/opencd.models.decode_heads.changer.FDAF::neck_layer/mmengine.model.base_module.Sequential::flow_make/torch.nn.modules.conv.Conv2d::flow_make.0 # /data/ohsung/anaconda3/envs/changer/lib/python3.8/site-packages/torch/nn/modules/conv.py:456:0 )' (type 'Tensor') in the TorchScript graph. The containing node has kind 'onnx::Conv'.]
python tools/export.py -c configs/changer/changer_ex_r18_512x512_40k_levircd.py -m /data/ohsung/repos/open-cd/321_S/best_mIoU_iter_800.pth -i "1,3,640,640" "1,3,640,640" -mn changer.onnx
I tried to run the export.py but the error came out as the abvoe one
i can't figure it out what the problem is
Can I get a help?

您好, 遇到了一样的问题，请问后面如何解决呢？


Roll engine eec74e5c9231..8ae84ec3da6d (5 commits)

https://github.com/flutter/engine/compare/eec74e5c9231...8ae84ec3da6d
git log eec74e5c92313f01a28dfbeb78d96e81231edab7..8ae84ec3da6d592a741c1dcc46607ea5f45b7165 --no-merges --oneline
8ae84ec3d Roll src/third_party/skia de8362c6f212..10bf7020aa15 (5 commits) (flutter/engine#8522)
2dbd981d3 Roll src/third_party/dart 06ed3f598c..1490a90bc1 (8 commits)
527913268 Android Embedding PR27: Fix SurfaceView flicker in Fragment transactions (flutter/engine#8504)
86ab45cd5 Remove the unused EnableBlink flag. (flutter/engine#8518)
d5880a609 Roll src/third_party/skia b5d8c634f95b..de8362c6f212 (14 commits) (flutter/engine#8519)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (jsimmons@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/4712130262597632

Commit queue failed; closing this roll.


Void-Extend blocks handling ASTC

Looking at the ASTC Decompressor, I did not find where you handle void-extent blocks.
Looking at the specifications, I see that void-extent blocks do not have the same layout as "normal" blocks. Can you use your decompressor on normal maps ? because a lot of them have some void-extent blocks, and I am wondering whether you handle it in another way or not.

Currently it doesn't handle it mostly because the test images I used didn't have any. Certainly a good thing to do (although it shouldn't be very difficult -- void extent blocks are pretty easy to decode).


Having connections in workspace settings causes duplicate connections in the connection tree

Azure Data Studio Version:
1.38.0
Steps to Reproduce:

add a SQL connection to the workspace setting and one different one to user setting
open the workspace in ADS and see the connections correctly show up in the tree
connect to the workspace connection

Expected: The tree should still have two connections
Actual: the workspace connection gets added to user settings with different Id and will show up as duplicate in the tree

I hope this bug would be addressed, as it severely impacts keeping settings.json under version control.
I only put general preferences in user settings. All database connections/groups go into workspace settings. This is already supported and works perfectly; servers show up when I open ADS and it's all good... until I need to connect. When I do, ADS then adds the connection to my user settings, and I constantly have revert this change. It's rather annoying.

I totally agree.
We want to keep distinct connections by workspace. We don't want to recopy "datasource.connections" in user settings.
Simply add a flag to remove that automatic recopy. That should not take 3 years to do.

I notice that it will recopy the connection in user settings only when we left click the connection in the Servers side bar. If we right click and select Manage it will not recopy the setting.


Fix editing test page

TODO

https://github.com/jsperf/jsperf.com/issues/153
[x] Verify test ownership by page author email <-> GitHub email
https://github.com/jsperf/jsperf.com/issues/236
[x] Edit page does not send through the test id properly
[ ] Edit saving code does not handle ownership right (create/update tests)  https://github.com/LeZuse/jsperf.com/blob/patch1-fix-editing/server/services/pages.js#L66
https://github.com/LeZuse/jsperf.com/blob/patch1-fix-editing/server/repositories/tests.js#L41

Merged upstream per https://github.com/jsperf/jsperf.com/pull/311


Add user confirmation before refreshing file content after changes from outside vs code

I'd really apprechiate if there was a user confirmation or any indication before vs code refreshes contents of an open file when some other editor or git-checkout changes the file outside of vs code.

/duplicate https://github.com/microsoft/vscode/issues/23107


Add support for context specific types

See https://github.com/huysentruitw/pem-utils/pull/9

From https://docs.ldap.com/ldap-sdk/docs/ldap-wire-protocol-reference/asn1-ber.html, http://luca.ntop.org/Teaching/Appunti/asn1.html and others, I've learned that the current implemented ASN.1 types (Boolean, Integer, Null, etc) are only valid within the universal class range and not for the application or context-specific class, where the tag identifier has a different meaning.
Will probably have to refactor the DerAsnType base class and additionally add the possibility to register class-specific parsers.

00 — This is the universal class. BER types in the universal class always mean the same thing, regardless of where you see it. For example, if you see a BER element with a type of 00000010 binary (0x02 hex, which means universal class, primitive, tag number two), then the value of that element will always be an integer.

10 — This is the context-specific class. BER types in the context-specific class can have different meanings from one element to another, and you need to have an understanding of how it’s being used to be able to determine what it means. For example, if you see a BER element in an LDAP message with a type of 10100011 binary (0xa3 hex, which means context-specific class, constructed, tag number three), then it could represent a set of referral URLs if it appears in an LDAPResult sequence, or it could represent an equality filter component in a search request, or it could mean something completely different somewhere else in some other context.

And later:

The Universal BER Types Used in LDAP

cc @qmfrederik

Refactor finished (v3.0)

Hi and thanks for your efforts. Is there an example for how todo this?
I have case where I am creating a DerAsnIa5String and serializes perfectly!
var contextSpesificId = new DerAsnIdentifier(DerAsnTagClass.ContextSpecific, DerAsnEncodingType.Primitive, DerAsnKnownTypeTags.Primitive.ObjectIdentifier);
var location = new DerAsnIa5String(contextSpesificId, uri.ToString());
// etc....

But cant seem to get the value out. I tried to hack my way through by doing Encoding.ASCII.GetString(objectIdentifier.Value.Select(x => (byte)x).ToArray()) which gives me almost the string I wanted with missing one character plus two control characters at the begining. Did not like this approach anyway.
What i am trying to figure out is how to tell the default decoder not to parse this into DerAsnObjectIdentifier if it sees the DerAsnTagClass.ContextSpecific but instead parse it into DerAsnIa5String. Can it be done?


"_interopRequireDefault" is not wrapping 'default' keyword in quotes anymore

I have updated webpack from 1.12.2 to 1.12.4 (and now also tried the latest 1.12.9), and I have noticed an issue in IE8 since the update, causing "Expected identifier, string, or number" errors to be thrown by IE8. The function _interopRequireDefault is not wrapping the default keyword in quotes anymore.
This is what 1.12.2 did output:
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { 'default': obj }; }
And this is what 1.12.4 and 1.12.9 outputs:
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }
Only difference are the missing quotes.

Looks like quotes are missing everywhere where a default export is being imported.
For example my cookie utility function used to get compiled to this:
if (_utilsCookies2['default'].hasCookie(COOKIE_NAME)) {
	state = JSON.parse(_utilsCookies2['default'].getCookie(COOKIE_NAME));
}

but now it looks like this:
if (_cookies2.default.hasCookie(COOKIE_NAME)) {
	state = JSON.parse(_cookies2.default.getCookie(COOKIE_NAME));
}

That's babel, not webpack. You probably upgraded to babel 6, or a dep did

Ah I see, thanks for letting me know! I thought this function is related to the other __webpack_* functions. I will report it in the babel repository then, thanks!

For completeness, this is the plugin you want

Just in case you still needed this or anyone else like I did.
The plugin you are looking for is:
http://babeljs.io/docs/plugins/transform-es3-property-literals/

The transform for member expression literals doesn't seem to be working.
var _foo = __webpack_require__(1);
var _foo2 = _interopRequireDefault(_foo);
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { 'default': obj }; }

new _foo2.default();

The default property is protected in the generated interopRequireDefault function but not in the generated accessing code.

Known bug. https://phabricator.babeljs.io/T2817

And similarly: https://phabricator.babeljs.io/T6863
Thanks.

1


Files not found?

I really hope I'm missing something, because after following the install and configuration docs to the letter, I couldn't get pipeline to work under Django 2.2. Static collection worked and files were minimized and placed in my root static directory, but all requests for files returned a 404 error.
Per the install instructions, I have the default Django filesystem and app finders, as well as Pipeline's custom finder in my settings like:
STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
    'pipeline.finders.PipelineFinder',
)

So I dug into all the finders and added breakpoints, and I found something curious in PipelineFinder. The file system finder finds nothing because I have no custom static directories (other than my STATIC_ROOT, which Django's FileSystemFinder doesn't check). The app finder finds nothing because Pipeline's generated files go into the STATIC_ROOT, which doesn't belong to any app. Then it gets to PipelineFinder. On line 15 of pipeline/finders.py is:
def find(self, path, all=False):
    if not settings.PIPELINE_ENABLED:
        return super(PipelineFinder, self).find(path, all)
    else:
        return []

If I'm reading this correctly, this is saying "If pipeline is enabled then find no files that pipeline generates". Is that correct? Because if so, that explains why pipeline's broken in Django 2.2. If I modify this to:
def find(self, path, all=False):
        return super(PipelineFinder, self).find(path, all)

then Pipeline works perfectly, and all the minified files generated by collectstatic are correctly found and served. However, I have to assume I'm missing something or misconfigured something, because I can't believe the default finder would purposely not find Pipeline's own minified files.

Can we close this issue if the support was been done for Django 2.2?

+1


[Draft] Make applications and requests sorting process pluggable

Discussion:  https://issues.apache.org/jira/browse/YUNIKORN-1?focusedCommentId=17260177&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17260177

hi @TaoYang526 thanks for the draft PR. At the first glance, I wasn't able to fully understand some of the places. After reading more info from the previous design doc in https://issues.apache.org/jira/browse/YUNIKORN-1. They start to make sense. I pretty like interfaces defined in this PR, the confusion part is queue_request_manager_plugin.go. I feel we can somehow optimize this to make it simpler. I will look into more details and get back to you. Thanks.

hi @TaoYang526 thanks for the draft PR. At the first glance, I wasn't able to fully understand some of the places. After reading more info from the previous design doc in https://issues.apache.org/jira/browse/YUNIKORN-1. They start to make sense. I pretty like interfaces defined in this PR, the confusion part is queue_request_manager_plugin.go. I feel we can somehow optimize this to make it simpler. I will look into more details and get back to you. Thanks.

Thanks @yangwwei for your suggestion.
I agree that queue_request_manager_plugin is not easy to be understood, so I have refactored that plugin in latest commit: add applications plugin and let applications/requests plugins have their own sorting methods.
I hope now it can be simple as expected and please feel free to share your thoughts. Thanks.

Thanks @yangwwei for your suggestion.
I agree that queue_request_manager_plugin is not easy to be understood, so I have refactored that plugin in latest commit: add applications plugin and let applications/requests plugins have their own sorting methods.
I hope now it can be simple as expected and please feel free to share your thoughts. Thanks.

hi @TaoYang526 the structure now looks much better. Overall it looks good, some high-level changes might be needed:

can we remove interface QueueRequestManager? I think it is no longer needed
For interface Application, I think we can further simplify the interface by removing the following methods such as CurrentState(), IsStarting(), IsAccepted(), IsNew().. etc. I understand now there are needed before the App state is an internal struct in cache package, we need to think about move them to the common package, or SI package.
Nit about the package naming. plugins/defaults/ looks like a better name for default implementations for apps/requests.

@wilfred-s pls take a look at the latest changes and let us know your opinion about this. Thanks

hi @TaoYang526 the structure now looks much better. Overall it looks good, some high-level changes might be needed:

can we remove interface QueueRequestManager? I think it is no longer needed
For interface Application, I think we can further simplify the interface by removing the following methods such as CurrentState(), IsStarting(), IsAccepted(), IsNew().. etc. I understand now there are needed before the App state is an internal struct in cache package, we need to think about move them to the common package, or SI package.
Nit about the package naming. plugins/defaults/ looks like a better name for default implementations for apps/requests.

@wilfred-s pls take a look at the latest changes and let us know your opinion about this. Thanks

Thanks @yangwwei for the review.
I have addressed your comments in the latest commit, only one point need to be discussed is that we should check the state of an application when the sort policy is StateAwarePolicy, so I still leave CurrentState() in application interface but removed other check methods like IsStarting() etc, and check the state via string comparison in pkg/plugins/defaults/sorters.go#StateAwareFilter. Is that ok?

Thanks @yangwwei for the review.
I have addressed your comments in the latest commit, only one point need to be discussed is that we should check the state of an application when the sort policy is StateAwarePolicy, so I still leave CurrentState() in application interface but removed other check methods like IsStarting() etc, and check the state via string comparison in pkg/plugins/defaults/sorters.go#StateAwareFilter. Is that ok?

I had a sync up with @wilfred-s about this, I think in general the interfaces are looking good.
He had some concern about how plugins got initialized, he thinks the plugin package currently is mostly used by core-shim communication that may be only used by the K8shim. He suggested looking at the direction of moving the init logic to a separate package, just for scheduling policies (which is a pure core side thing). @TaoYang526 , what's your thought about this?

I had a sync up with @wilfred-s about this, I think in general the interfaces are looking good.
He had some concern about how plugins got initialized, he thinks the plugin package currently is mostly used by core-shim communication that may be only used by the K8shim. He suggested looking at the direction of moving the init logic to a separate package, just for scheduling policies (which is a pure core side thing). @TaoYang526 , what's your thought about this?

Thanks @yangwwei and @wilfred-s for the review.
That makes sense to me, perhaps we can move plugins into scheduler/policies package and rename XXXPlugin to XXXPolicyPlugin which means the policy plugin of managing and scheduling for applications/requests/nodes(in future) ?
Another thing is that I want to update Requests#AddRequest to Requests#AddOrUpdateRequest and that should also be called when updating the pending repeat, so that the Requests instance can be notified in time which can be useful in a custom RequestsPlugin. Is that ok for you?
Hope to hear your thoughts about these.

Thanks @yangwwei and @wilfred-s for the review.
That makes sense to me, perhaps we can move plugins into scheduler/policies package and rename XXXPlugin to XXXPolicyPlugin which means the policy plugin of managing and scheduling for applications/requests/nodes(in future) ?
Another thing is that I want to update Requests#AddRequest to Requests#AddOrUpdateRequest and that should also be called when updating the pending repeat, so that the Requests instance can be notified in time which can be useful in a custom RequestsPlugin. Is that ok for you?
Hope to hear your thoughts about these.

@yangwwei   I have moved scheduling plugins which are only used in core scheduling process into a dependent package (scheduler/plugins) and make it configurable in the latest commit. For now there is no entry-point for updating those plugins, but we can easily call plugins#Init(registry, pluginsConfig) to refresh those plugins when plugins can be configured in future.  Please help to review it again. Thanks.

@yangwwei   I have moved scheduling plugins which are only used in core scheduling process into a dependent package (scheduler/plugins) and make it configurable in the latest commit. For now there is no entry-point for updating those plugins, but we can easily call plugins#Init(registry, pluginsConfig) to refresh those plugins when plugins can be configured in future.  Please help to review it again. Thanks.

This PR has been in the same state for 2 years. Lots has changed in the YuniKorn code.
If this is still something that needs to be implemented please open a jira to go through the design.


Button to deploy to Azure

Deploying the project into API apps should be as simple as possible.
There should be Deploy to Azure button that would deploy this project.

Good suggestion @Tapanila, I'll look into it!

Reference on how to implement:

https://deploy.azure.com
Using custom ARM templates with the Deploy to Azure button
Git Repo

Deploy to Azure button is now available.


Implement Ed25519VerificationKey2018 Linked Data Signature Suite

In #241 we create an interface for a generic pluggable Linked Data Signature Suite. Here we create an implementation of the Ed25519 2018 signature suite, so Sign and Verify can be done using Ed25519VerificationKey2018.
Part of #96

Depends on #241


PDF Preview fails silently sometimes upon startup

Appears to be something inherently wrong in pdfjs when something isn't loaded properly.
This might be related to the hack that replaces the default PDF URL as per https://github.com/tomoki1207/vscode-pdfviewer.
Also appears in tomoki1207's extension--will investigate soon.

The temporary workaround is to reopen the PDF, but I really don't like things failing silently.
What could possibly be done is a very small fake PDF to supplant the default PDF to let it load something, then quickly load the actual PDF. Should have no problems.

FIxed in 0.2.1 #31 with retry logic, seems to work robustly.


Fix bug type mismatch when apply using ObjectUtils.fromMap

Fix bug type mismatch when apply using ObjectUtils.fromMap

Pull Request Test Coverage Report for Build 267

5 of 14 (35.71%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.06%) to 52.457%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

commons/gridgo-utils/src/main/java/io/gridgo/utils/ObjectUtils.java
1
2
50.0%

commons/gridgo-utils/src/main/java/io/gridgo/utils/exception/TypeMismatchException.java
0
8
0.0%

Totals

Change from base Build 263:
-0.06%

Covered Lines:
2551

Relevant Lines:
4863

💛  - Coveralls


Minor glitch in documentation

Missing closing parenthesis in https://flask.palletsprojects.com/en/2.0.x/deploying/uwsgi/#starting-your-app-with-uwsgi.

Please do not open issues for minor issues like this but go straight for the PR. Having an issue as well just adds noise...

Oh sorry, I just wanted to strictly follow contibuting instructions.

The point is that people do not waste time making a large PR of something we don't need/want. Maybe we should clarify that this doesn't apply to typos etc..


Remove unused Pin methods, optimize GPIO interrupt handler

Thank you!
Thank you for your contribution.
Please make sure that your submission includes the following:
Must

[x] The code compiles without errors or warnings.
[x] All examples work.
[x] cargo fmt was run.
[x] Your changes were added to the CHANGELOG.md in the proper section.
[x] You updated existing examples or added examples (if applicable).
[x] Added examples are checked in CI

Nice to have

[x] You add a description of your work to this PR.
[x] You added proper docs for your newly added features and code.

This PR optimizes the GPIO interrupt handler for devices that have multiple GPIO banks:

First commit is some cleanup, with the baseline of 105 instructions
Second commit removes two RSR instructions, 103
Third commit reduces instruction count to 95
Last commit removes the last RSR instruction for a final count of 94

Unfortunately it looks like get_core can't be optimized away by the compiler even if the read core ID isn't used, so I've removed the calls from the GPIO interrupt handler. If there is a way to make the compiler understand that RSR isn't supposed to be a volatile read, the log calls can be added back, but I don't consider this to be a big deal.
There is still an unnecessary bounds check (and panic) present in the generated code, because the compiler doesn't understand (even if masked) that the Bank1 interrupt status does not have more bits than NUM_PINS-32.
There's also a 16-byte stack reduction but I don't really know why.

cc @MabezDev in case you are interested but missed this


Deep copy a DomainAwareNet after fitting

After fitting a DomainAwareNet, it's not possible to deep copy it.
Strangely it works before the fitting.
Error raised:
AttributeError: Can't pickle local object '_get_intermediate_layers.<locals>.hook'
It's necessary to be able to deep copy it to use the CircularValidation scorer.
To reproduce:
import torch
import numpy as np
from skada.deep.base import DomainAwareCriterion, DomainAwareModule, DomainAwareNet, DomainBalancedDataLoader, BaseDALoss
from skada.metrics import (
    ImportanceWeightedScorer,
    PredictionEntropyScorer,
    SoftNeighborhoodDensity,
    DeepEmbeddedValidation,
    CircularValidation,
)
from skada.deep.modules import ToyModule2D
from skada import make_da_pipeline
from sklearn.model_selection import ShuffleSplit, cross_validate
from skada.datasets import make_shifted_datasets
from copy import deepcopy

class TestLoss(BaseDALoss):
    """Test Loss to check the deep API"""

    def __init__(
        self,
    ):
        super().__init__()

    def forward(
        self,
        *args,
    ):
        """Compute the domain adaptation loss"""
        return 0

da_dataset = make_shifted_datasets(
        n_samples_source=20,
        n_samples_target=20,
        shift="concept_drift",
        noise=0.1,
        random_state=42,
        return_dataset=True,
    )

X, y, sample_domain = da_dataset.pack_train(as_sources=["s"], as_targets=["t"])
X_test, y_test, sample_domain_test = da_dataset.pack_test(as_targets=["t"])

module = ToyModule2D()

estimator = DomainAwareNet(
	DomainAwareModule(module, "dropout"),
	iterator_train=DomainBalancedDataLoader,
	criterion=DomainAwareCriterion(torch.nn.CrossEntropyLoss(), TestLoss()),
	batch_size=10,
	max_epochs=2,
	train_split=None,
)

X = X.astype(np.float32)
X_test = X_test.astype(np.float32)

estimator_copy = deepcopy(estimator) # Doesn't raise errors

estimator.fit(X, y, sample_domain=sample_domain)

estimator_copy_after_fit = deepcopy(estimator) # Raises AttributeError

We had a brief discussion of this problem in the Slack chat. It also makes behavior of selectors somewhat unpredictable, as they perform clone of the base estimator before fitting. The reasons for copy to fail is that torch blocks copying of the tensor that is attached to the gradients graph. It should be possible to define own cloning hook by taking parameters of the module and calling constructor  (not sure if it works for deepcopy as well, but I would rather say it's better to switch splitter to sklearn clone).

Linked to #163 and fixed by #169


[Bug]: datetime with local timezone throws OSError when converting file

What happened?
I'm making a converter for Caiman, and one step is auto-adding a datetime if it isn't specified. I've run into some errors when I use tz.local() and have reproduced them when using the neuroconv interface. Specifically, if you don't set a time zone, or set it to tzlocal() an exception is thrown.
More in the weeds: if you don't have a timezone, pynb.file._add_missing_timezone()  tries to add tzlocal(), but downstream functions throw an OSError. I switched to tz.UTC to fix it.
This may be Windows specific 😬 I'm on Windows 10, Python 3.10. Haven't tested on Linux.
Related to #599 .
Steps to Reproduce
from datetime import datetime
from dateutil import tz
from neuroconv.datainterfaces import CaimanSegmentationInterface

caiman_file = 'cnmf.hdf5'
nwb_file = 'cnmf_converted.nwb'

interface = CaimanSegmentationInterface(file_path=caiman_data_path, verbose=True)
metadata = interface.get_metadata()
session_start_time = datetime.min.replace(tzinfo=tz.tzlocal())
metadata["NWBFile"].update(session_start_time=session_start_time)
interface.run_conversion(nwbfile_path=nwb_filepath_new, metadata=metadata)

Traceback
---------------------------------------------------------------------------
OSError                                   Traceback (most recent call last)
Cell In[30], line 2
      1 # Choose a path for saving the nwb file and run the conversion
----> 2 interface.run_conversion(nwbfile_path=nwb_filepath_new, metadata=metadata)

File ~\miniconda3\envs\caiman_nwb_python\lib\site-packages\neuroconv\basedatainterface.py:92, in BaseDataInterface.run_conversion(self, nwbfile_path, nwbfile, metadata, overwrite, **conversion_options)
     89 if metadata is None:
     90     metadata = self.get_metadata()
---> 92 with make_or_load_nwbfile(
     93     nwbfile_path=nwbfile_path,
     94     nwbfile=nwbfile,
     95     metadata=metadata,
     96     overwrite=overwrite,
     97     verbose=getattr(self, "verbose", False),
     98 ) as nwbfile_out:
     99     self.add_to_nwbfile(nwbfile_out, metadata=metadata, **conversion_options)

File ~\miniconda3\envs\caiman_nwb_python\lib\contextlib.py:135, in _GeneratorContextManager.__enter__(self)
    133 del self.args, self.kwds, self.func
    134 try:
--> 135     return next(self.gen)
    136 except StopIteration:
    137     raise RuntimeError("generator didn't yield") from None

File ~\miniconda3\envs\caiman_nwb_python\lib\site-packages\neuroconv\tools\nwb_helpers\_metadata_and_file_helpers.py:184, in make_or_load_nwbfile(nwbfile_path, nwbfile, metadata, overwrite, verbose)
    182 except Exception as e:
    183     success = False
--> 184     raise e
    185 finally:
    186     if nwbfile_path_in:

File ~\miniconda3\envs\caiman_nwb_python\lib\site-packages\neuroconv\tools\nwb_helpers\_metadata_and_file_helpers.py:180, in make_or_load_nwbfile(nwbfile_path, nwbfile, metadata, overwrite, verbose)
    178         nwbfile = io.read()
    179     elif nwbfile is None:
--> 180         nwbfile = make_nwbfile_from_metadata(metadata=metadata)
    181     yield nwbfile
    182 except Exception as e:

File ~\miniconda3\envs\caiman_nwb_python\lib\site-packages\neuroconv\tools\nwb_helpers\_metadata_and_file_helpers.py:56, in make_nwbfile_from_metadata(metadata)
     54 schema_path = Path(__file__).resolve().parent.parent.parent / "schemas" / "base_metadata_schema.json"
     55 base_metadata_schema = load_dict_from_file(file_path=schema_path)
---> 56 validate_metadata(metadata=metadata, schema=base_metadata_schema)
     58 nwbfile_kwargs = deepcopy(metadata["NWBFile"])
     59 # convert ISO 8601 string to datetime

File ~\miniconda3\envs\caiman_nwb_python\lib\site-packages\neuroconv\utils\json_schema.py:330, in validate_metadata(metadata, schema, verbose)
    327 encoder = NWBMetaDataEncoder()
    328 # The encoder produces a serialized object so we deserialized it for comparison
--> 330 serialized_metadata = encoder.encode(metadata)
    331 decoded_metadata = json.loads(serialized_metadata)
    332 validate(instance=decoded_metadata, schema=schema)

File ~\miniconda3\envs\caiman_nwb_python\lib\json\encoder.py:199, in JSONEncoder.encode(self, o)
    195         return encode_basestring(o)
    196 # This doesn't pass the iterator directly to ''.join() because the
    197 # exceptions aren't as detailed.  The list call should be roughly
    198 # equivalent to the PySequence_Fast that ''.join() would do.
--> 199 chunks = self.iterencode(o, _one_shot=True)
    200 if not isinstance(chunks, (list, tuple)):
    201     chunks = list(chunks)

File ~\miniconda3\envs\caiman_nwb_python\lib\json\encoder.py:257, in JSONEncoder.iterencode(self, o, _one_shot)
    252 else:
    253     _iterencode = _make_iterencode(
    254         markers, self.default, _encoder, self.indent, floatstr,
    255         self.key_separator, self.item_separator, self.sort_keys,
    256         self.skipkeys, _one_shot)
--> 257 return _iterencode(o, 0)

File ~\miniconda3\envs\caiman_nwb_python\lib\site-packages\neuroconv\utils\json_schema.py:22, in NWBMetaDataEncoder.default(self, obj)
     19 def default(self, obj):
     20     # Over-write behaviors for datetime object
     21     if isinstance(obj, datetime):
---> 22         return obj.isoformat()
     24     # Transform numpy generic integers and floats to python ints floats
     25     if isinstance(obj, np.generic):

File ~\miniconda3\envs\caiman_nwb_python\lib\site-packages\dateutil\tz\tz.py:222, in tzlocal.utcoffset(self, dt)
    219 if dt is None and self._hasdst:
    220     return None
--> 222 if self._isdst(dt):
    223     return self._dst_offset
    224 else:

File ~\miniconda3\envs\caiman_nwb_python\lib\site-packages\dateutil\tz\tz.py:291, in tzlocal._isdst(self, dt, fold_naive)
    288     return False
    290 # Check for ambiguous times:
--> 291 dstval = self._naive_is_dst(dt)
    292 fold = getattr(dt, 'fold', None)
    294 if self.is_ambiguous(dt):

File ~\miniconda3\envs\caiman_nwb_python\lib\site-packages\dateutil\tz\tz.py:260, in tzlocal._naive_is_dst(self, dt)
    258 def _naive_is_dst(self, dt):
    259     timestamp = _datetime_to_timestamp(dt)
--> 260     return time.localtime(timestamp + time.timezone).tm_isdst

OSError: [Errno 22] Invalid argument

Operating System
Windows
Python Executable
Conda
Python Version
3.9
Package Versions
environment_for_issue.txt
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] Have you ensured this bug was not already reported?

and one step is auto-adding a datetime if it isn't specified

This seems dangerous; you mean to say setting the session_start_time to something like datetime.now()? That is incorrect, which is why we generally require the user to input this information manually. It could be an argument to the function call to write the NWB file in your case. Dates should also be accepted if exact timestamp isn't known (which is fine)

More in the weeds: if you don't have a timezone, pynb.file._add_missing_timezone() tries to add tzlocal(), but downstream functions throw an OSError. I switched to tz.UTC to fix it.
This may be Windows specific 😬 I'm on Windows 10, Python 3.10. Haven't tested on Linux.

As for the actual error here, I can reproduce minimally with pure datetime/dateutil
from datetime import datetime
from dateutil import tz

now = datetime.now()
now_with_local_timezone = now.min.replace(tzinfo=tz.tzlocal())

now_with_local_timezone_as_iso = now_with_local_timezone.isoformat()
> OSError

So it seems to me a more fundamental error with dateutil to not resolve the tzlocal() to something explicit.
We don't recommend relying on local timezone anyway since it can easily be incorrect (the behavior of PyNWB to infer it has been a long-time point of internal discussion that may be removed some day; apologies about that), hence why in the conversion gallery we always recommend setting it explicitly

While we're at it, a kind reminder that if you intend your Caiman output NWB files to  be uploadable to DANDI, they will also need to collect basic subject information as well (again, I'd recommend as required inputs)
These are: subject_id, subject_age (as ISO duration), sex (M/F/O/U), and species (latin binomial, e.g., Mus musculus)

Good call with the error, indeed it's the iso conversion. The following throws the same:
datetime.min.replace(tzinfo=tz.tzlocal()).isoformat()
For context: I am currently working with a demo dataset where the session start time is unknown, so I'm setting it to something arbitrary so the conversion doesn't throw an error -- in this case the earliest possible datetime.min -- I want to use this as an indicator that it was not set, and throwing a warning. I didn't try with a date and no timestamp: I'll give that a shot.
Making things required, versus setting defaults and issuing warnings if they haven't changed them, is something we'll have to discuss internally as a Caiman design question. At the very least, it will be good to get users to think about what minimal information they will wish they had access to in ten months when they open elsa_reaching_task_day10.nwb.

For context: I am currently working with a demo dataset where the session start time is unknown, so I'm setting it to something arbitrary so the conversion doesn't throw an error -- in this case the earliest possible datetime.min -- I want to use this as an indicator that it was not set, and throwing a warning.

I see - for a demo I would still suggest to explicitly type out the placeholder datetime while emphasizing they should enter the correct information for their experiment when using it in practice.
Experience has taught us that more often than not, first time users will in those situations simply copy and paste implicit code-based approaches without understanding what exactly something like a datetime.min does

Making things required, versus setting defaults and issuing warnings if they haven't changed them, is something we'll have to discuss internally as a Caiman design question.

I can tell you from seeing the results of downstream outputs from these types of decisions, I strongly recommend not have a default for something as important as this (or the other subject info for that matter). Users will almost always in those situations rely on the defaults, even when they end up being incorrect, and that just produces NWB files that might go to DANDI with incorrect metadata.

I appreciate your feedback here! Especially as someone with little experience with NWB I will weight it very heavily!  I'm closing this issue as it was based on me misusing a pattern from _add_missing_timezone() (and the warning was there in the leading underscore that I should have been more careful 😄 ).

Just following up: to add top-level metadata like Subject information, it's as simple as adding a new key to the metadata dict from the interface, so something like:
metadata = interface.get_metadata()
metadata["Subject"] = {k:v}

where {k:v} is a stand in for the key/values we want like subject_id, etc?

@EricThomson Yep, that should work
We also use a special type of dictionary that allows you to specify keys at any level, so you can optionally do
metadata["Subject"]["subject_id"] = ...
metadata["Subject"]["age"] = "P10W"  # For example; must be ISO 8601
metadata["Subject"]["sex"] = ...
metadata["Subject"]["species"] = ...

directly


Second step of improving API to return event and design slugs and ids

This is a continuation of #662, and has to be done in a followup release:

[x] Replace id with actual_id once dependent apps have been updated to use actual_id correctly
[x] Remove actual_id

Closed by 76c21d731ce0d5696ab0036bf0b0821968fc2b98.


LGPL license makes it impossible to use uadetector in a Apache project

Hello,
We are having an issue using uadetector in an Apache project, because it uses a class that has a LGPL license. This type of license is not allowed in an official Apache project.
I saw that we the AlphanumComparator LGPL class is used in the VersionNumber.compareTo method, and I was wondering if it was really uses because when debugging on a parsing of a user agent string it doesn't seem to be called. If that is the case and this is dead code maybe just removing it could be a way to fix this ?
Otherwise I did a little research and it seems they have alternatives here :
http://stackoverflow.com/questions/1262239/natural-sort-order-string-comparison-in-java-is-one-built-in
Notably this one : https://github.com/paour/natorder that seems to have an acceptable license (based on zlib). See https://en.wikipedia.org/wiki/Zlib_License and https://www.apache.org/legal/resolved.html
Fixing this problem would be a great help for us, and highly appreciated.

Noting that CC-BY-SA is also going to affect the licensing of uadetector.
If of value, I have this implementation under BSD:
https://github.com/hen/osjava/blob/master/genjava/gj-core/src/java/com/generationjava/compare/NumericStringComparator.java
Old code that didn't make it into Apache Commons. I'm happy to relicense that Apache-2.0 for this project. Or there is the zlib code that Serge pointed to.


implement two sample one sided ks test

Updates ks_2samp to work with one sided alternative hypotheses

looks good to me. The one-sided alternative needs to be better explained and show in which direction the one-sided test goes, i.e. one greater than two or two greater than one.
Is there a reference for the p-value approximation, e.g. Stephens, or is it taken from the two-sided case.
Adding a reference would be useful.

This should be checked against the mstats version, which already has an alternative option.
https://github.com/MarvinT/scipy/blob/a5e46e9b0f84bd3016055055bbc1fca6b52f7c07/scipy/stats/mstats_basic.py#L1074
(I don't remember that I ever looked at the details of it.)
(especially confusing for this type of statistics: "larger" cdf means "smaller" values are observed.)

Hmm, I wasn't aware of the mstats version. Had I known about it I probably would have just used that... which would have been troubling since it doesn't agree with the sp.stats version (which does agree with the matlab version)
x1 = [1, 1, 2, 2, 1, 3, 2]
x2 = [4, 5, 7, 2, 5, 2, 4]
print sp.stats.mstats.ks_twosamp(x1, x2, alternative='two-sided')
print sp.stats.ks_2samp(x1, x2)
>>> (0.71428571428571419, 0.056230069748064229)
>>> Ks_2sampResult(statistic=0.7142857142857143, pvalue=0.027500341091743086)

and in Matlab
>> [H,P,KSSTAT] = kstest2(x1, x2)
H =
     1
P =
    0.0275
KSSTAT =
    0.7143

You're definitely right about the one sided needing better explanation on which side it compares to.  I actually seem to have it backwards from kstest and Matlab's kstest2 since I interpreted less and greater to refer to the values, not the CDF. I'll definitely fix that. I'm not sure what to do about the discrepancy with the mstats version?

I was looking for a reference and haven't been able to find anything.
I've looked at this and this but neither seem to be the method I used.
I just took the calculation done by the Matlab function kstest2 and translated it into python.

I just took the calculation done by the Matlab function kstest2 and translated it into python.

@MarvinT unfortunately that's a problem - you're saying that your implementation is based on Matlab code, and that Matlab code doesn't have a license that is compatible with the BSD license we ship Matlab with.

Closing, we cannot take translations of license-incompatible codes.


docs: Reorganize Storybook sidebar nav to better reflect USWDS docs

Summary
In the interest of making components easier to find and match to their USWDS counterparts, this PR organizes components in Storybook under groups:

Design tokens: stories that illustrate or exemplify USWDS design tokens, utility classes, or other plain HTML that is not part of an exported React component
Components: stories for exported USWDS components and sub-components
Page templates: stories that illustrate USWDS page templates
Other: everything else, such as Truss-designed components. This group may not be long for this world.

Related Issues or PRs
Closes #784
How To Test

Start Storybook (yarn storybook)
Review the ordering and grouping of sidebar navigation

Screenshots (optional)

Warnings

:warning:
This PR does not include changes to tests, even though it affects source code.

  Generated by :no_entry_sign: dangerJS against e7607d4c4563b11d38713b6ccc3edbeea1ee7c5f

Warnings

:warning:
This PR does not include changes to tests, even though it affects source code.

  Generated by :no_entry_sign: dangerJS against e7607d4c4563b11d38713b6ccc3edbeea1ee7c5f


Add support for dwave-cloud-client 0.9.x

Codecov Report

Merging #425 (5412509) into master (8272705) will decrease coverage by 1.38%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #425      +/-   ##
==========================================
- Coverage   91.82%   90.43%   -1.39%
==========================================
  Files          22       22
  Lines        1370     1370
==========================================
- Hits         1258     1239      -19
- Misses        112      131      +19

Impacted Files
Coverage Δ

dwave/system/samplers/clique.py
77.35% <0.00%> (-5.04%)
:arrow_down:

dwave/system/samplers/dwave_sampler.py
84.37% <0.00%> (-3.13%)
:arrow_down:

dwave/system/samplers/leap_hybrid_sampler.py
75.71% <0.00%> (-2.86%)
:arrow_down:

dwave/system/composites/embedding.py
95.85% <0.00%> (-1.19%)
:arrow_down:

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 8272705...5412509. Read the comment docs.


Referenced docker revision in 4.0.0 no longer in github

Seems like docker changed their history.
version cd27f179f2c10c5d300e6d09025b538c475b0d51 is no longer in their history. this is breaking me trying to use glide to import client-go.

@JackQuincy Could you provide more input ? On which project is that happening ? What is your dependency tree (glide.yaml, glide.lock) ?
kubernetes/client-go doesn't depend on docker/docker and as far as I know, we never rewrite history on github.com/docker/docker (and I hope it is true !!).

That commit looks to be a commit from the https://github.com/docker/distribution repository, but GitHub can do "magic things", like showing commits on any other repository 😞 - which can be super confusing.
It looks as if the commit is in the moby/moby repository; https://github.com/moby/moby/commit/cd27f179f2c10c5d300e6d09025b538c475b0d51
But the actual commit is in the https://github.com/docker/distribution repository https://github.com/docker/distribution/commit/cd27f179f2c10c5d300e6d09025b538c475b0d51, where it's merged as part of this pull-request; https://github.com/docker/distribution/pull/1635

hmm seems I misdiagnosed. This is the error I'm seeing in glide: [INFO]  --> Setting version for github.com/docker/distribution to cd27f179f2c10c5d300e6d09025b538c475b0d51.
[ERROR] Failed to set version on github.com/docker/distribution to cd27f179f2c10c5d300e6d09025b538c475b0d51: Unable to update checked out version
[ERROR] Failed to set references: Unable to update checked out version (Skip to cleanup).
I'm running windows. I wonder if this is something that doesn't work correctly in windows. I'll try in a docker container to see if it behaves differently.

yep seems to be something with my dev enviroment as running in a dev container enviroment fixed it. I'll close the issue.

Great! Thanks for reporting though! And good luck debugging :sweat_smile:

Might of figured out the issue. 4.0.0 depends on an old version of github.com/docker/distribution before this PR https://github.com/docker/distribution/pull/1716 was merged. And that has paths in it which are invalid in windows.


Fix/remove asserts

Why are these changes needed?
This PR gets rid of the use of assert in non-test code, as these statements will be removed by CPython if interpreter is run with optimizations see the assert statement and -O
Related issue number
Checks

[x] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[x] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[ ] I've made sure all auto checks have passed.

@microsoft-github-policy-service agree

Codecov Report

Merging #80 (2637e83) into main (3b5e627) will decrease coverage by 0.96%.
The diff coverage is 7.89%.

:exclamation: Current head 2637e83 differs from pull request most recent head 802423e. Consider uploading reports for the commit 802423e to get more accurate results

@@            Coverage Diff             @@
##             main      #80      +/-   ##
==========================================
- Coverage   40.06%   39.11%   -0.96%
==========================================
  Files          17       17
  Lines        2004     2035      +31
  Branches      440      453      +13
==========================================
- Hits          803      796       -7
- Misses       1128     1162      +34
- Partials       73       77       +4

Flag
Coverage Δ

unittests
39.11% <7.89%> (-0.86%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files
Coverage Δ

autogen/agentchat/conversable_agent.py
67.49% <100.00%> (-1.24%)
:arrow_down:

autogen/retrieve_utils.py
62.27% <0.00%> (-0.98%)
:arrow_down:

autogen/code_utils.py
44.05% <16.66%> (-3.93%)
:arrow_down:

autogen/math_utils.py
9.28% <0.00%> (-0.16%)
:arrow_down:

autogen/oai/completion.py
18.86% <0.00%> (-0.55%)
:arrow_down:


Resizing dev tools should (maybe) trigger a window resize event?

Some layouts in an app I'm working on rely on the window resize event to recalculate some sizing and positioning (I know, I know, it should be CSS). When I shrink the dev tools I end up with some extra whitespace below my app and it looks broken until I resize the whole window.
If not the default, maybe there could be a triggerEventOnResize prop or something like that.

This should be fixed in v3

This should be fixed in v3


feat(dev/startNewSprintFix): Fixed some bugs in Create-new-sprint

Functionality:
Fixed bugs in create new sprint component.
Solution:

The data in now being updated correctly when the team changes
TeamId is displayed on top
Blocked the dates before the current date

Risk level:

[ ] high
[x] medium
[ ] low

How to test:
ng serve
firebase emulators:start
Check the start new Sprint Page.

Please resolve merge conflict and check my older comment for this PR


Missing feature: add a way to remove previous installation unlock password on desktop (windows)

Last month, I installed the self-hosted Alby Hub on my Windows 10 desktop. I used it, tested it, and then removed it by erasing the unzipped folder with Alby Hub files in it.
Today, I re-downloaded the app and unzipped the files of this new downloaded Alby Hub to a new directory. When I double clicked on the .exe file, I expected to create a new unlock password, but to my surprise, Windows somehow "remembers" that I had a Hub before with a previous password and the brand new downloaded file of Alby Hub for windows is asking me for an unlock password that was set up last month with an already erased Alby Hub, and I can't find a way to reset or erase this password from Windows 10 in order to start a brand new Hub for desktop installation.

This is intentional for this very reason (so the user doesn't accidentally delete it, and have to copy files around when they update). Maybe we just need a guide for how a user can find the Alby Hub working directory.
We use the XDG_DATA_HOME/albyhub directory (see https://github.com/adrg/xdg)

So in windows,  XDG_DATA_HOME	-> %LOCALAPPDATA% -> C:\Users<YourUsername>\AppData\Local
I found it. I'm not sure if it is worth doing a guide right now, it's enough knowing where it is. I have not heard of users requiring this so far, only myself.

@jpl-btc actually, could you add it to this guide? https://guides.getalby.com/user-guide/alby-account-and-browser-extension/alby-hub/backups
It would be good for users who do not connect their Alby Account to know how to find their data directory to back it up.

Done.
Info added to  https://guides.getalby.com/user-guide/alby-account-and-browser-extension/alby-hub/backups

@jpl-btc thanks. But it would be also good to have this for mac and linux too. Maybe there could be a section which explains where the work directory is, based on your operating system?

Added short paragraph, thought I can't really verify it since I don't have a macOS


Issue with custom logger in swift 3

I have a custom logger in swift. Everything was working fine, but I updated the pods and now I see this error message:
Type of 'logFormatter' has different optionality than required by protocol 'DDLogger'
This is how the logFormatter property is written:
 public var logFormatter: DDLogFormatter?
This protocol is written in Objective-C, and the var is supposed to be optional according to the comments, but there is no nullability specifiers, so for some reason swift is interpreting that this shouldn't be null. Any ideas how to solve this?

This doesn't happen on version 3.0, so it's related to some changes in 3.1

@buscarini does this issue still apply to Swift 4? I haven't seen anything similar in my Swift projects that use CocoaLumberjack. Also make sure you are using the latest version

I haven't seen this in recent projects, so I think it's safe to close it


PF2e difficult terrain should be +5 / +10 per square

https://2e.aonprd.com/Rules.aspx?ID=2366

Can confirm this also isn't working correctly for D&D5e if the "Diagonal Movement Rule" is set to Alternating (which is identical to the +5/+10 rule from PF2e).

Agreed, the same this is happening to me for the alternating ruleset in DnD5e. Using Version 3.2.1 DnD and Foundry V12 (328)

I added options in v0.10.6 to impose a flat penalty for movement through tokens and movement through drawings. You probably also want make sure the new "Use Grid for Movement Penalties" setting in v0.10.6 is enabled.
Note the current flat penalty is imposed per grid square. If you want the penalty to be larger if you are using alternating movement (i.e. impose +5 for a grid square for a "5" move but impose +10 for a grid square for a "10" move) please open a new issue. (That would be an entirely different option that I have not attempted to implement yet.)


Not working in PCL/UWP

Hello,
I tried to install the Nuget package for this in a PCL and in a UWP project, but was unable to in both cases.
Here's the Output screen for when I tried to install the Nuget package in the PCL.

Attempting to gather dependency information for package 'WpfBindingErrors.1.0.0' with respect to project 'ShowValue', targeting '.NETPortable,Version=v4.5,Profile=Profile259'
Attempting to resolve dependencies for package 'WpfBindingErrors.1.0.0' with DependencyBehavior 'Lowest'
Resolving actions to install package 'WpfBindingErrors.1.0.0'
Resolved actions to install package 'WpfBindingErrors.1.0.0'
Install failed. Rolling back...
Package 'WpfBindingErrors.1.0.0' does not exist in project 'ShowValue'
Package 'WpfBindingErrors.1.0.0' does not exist in folder 'C:\Users\elibl\Documents\Visual Studio 2015\Projects\svcapture3-git\packages'
Could not install package 'WpfBindingErrors 1.0.0'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile259', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
========== Finished ==========

And for the UWP project:

Restoring packages for 'SVCapture3.UWP'.
Restoring packages for C:\Users\elibl\Documents\Visual Studio 2015\Projects\svcapture3-git\SVCapture3\SVCapture3.UWP\project.json...
WpfBindingErrors 1.0.0 is not compatible with UAP,Version=v10.0.
Some packages are not compatible with UAP,Version=v10.0.
WpfBindingErrors 1.0.0 is not compatible with UAP,Version=v10.0 (win10-arm).
Some packages are not compatible with UAP,Version=v10.0 (win10-arm).
WpfBindingErrors 1.0.0 is not compatible with UAP,Version=v10.0 (win10-arm-aot).
Some packages are not compatible with UAP,Version=v10.0 (win10-arm-aot).
WpfBindingErrors 1.0.0 is not compatible with UAP,Version=v10.0 (win10-x64).
Some packages are not compatible with UAP,Version=v10.0 (win10-x64).
WpfBindingErrors 1.0.0 is not compatible with UAP,Version=v10.0 (win10-x64-aot).
Some packages are not compatible with UAP,Version=v10.0 (win10-x64-aot).
WpfBindingErrors 1.0.0 is not compatible with UAP,Version=v10.0 (win10-x86).
Some packages are not compatible with UAP,Version=v10.0 (win10-x86).
WpfBindingErrors 1.0.0 is not compatible with UAP,Version=v10.0 (win10-x86-aot).
Some packages are not compatible with UAP,Version=v10.0 (win10-x86-aot).
Package restore failed for 'SVCapture3.UWP'.
Package restore failed. Rolling back package changes for 'SVCapture3.UWP'.
========== Finished ==========

Any chance that you would be interested in making this project work in PCL's/UWP, too? :)

Never mind -- for Windows 10, it appears that you can use {x:Bind} to accomplish similar things.
Would you be okay with adding a note to this project's page about {x:Bind}?

@neoncube2, I'm sorry, I missed your message two years ago.
Is this still relevant?
What should I include in the README?
Could you open a PR?


MDX components are not working correctly with next-remote-mdx

Probably migrating to ContentLayer for this.

Closed in #124