Automatic features.

Rendered

This proposal originates from the conversation in this thread, about how to make the orphan rules less of a bummer.
This specifically solves the problem of "I want to implement some traits for my type, but I don't want my users to have to add this dependency / have to fiddle with features" problem. It does not solve the "this type in a library I'm using should implement this trait, but the author didn't provide that implementation" problem, which is much trickier.
The idea behind this RFC was mine, and I think it is the best solution to a problem that is happening right now, but I don't feel super motivated to drive this problem to completion, so if someone else wanted to "co-sponsor" this RFC and be really active about it, I would be stoked about it.
cc @nikomatsakis @aturon @wycats @sgrif all of whom have talked about issues in this area.

A concern I have with this are incidental dependencies.
For example, a crate I'm working on at the moment can optionally use regex for some parsing.  However, using regex also means using lazy_static.  Thus, I couldn't use this: Cargo doesn't allow one dependency to trigger the inclusion of another dependency.
A more general design might be to allow features to have an optional activate-if-available that lists dependencies that, if they're all already being used somewhere else in the dependency graph, cause the feature to be activated by default.
... of course, this same crate also wouldn't be able to use that because it'd be too easy to end up with multiple parsing implementations enabled.  At least, not without having to explicitly control activation order everywhere in the code... I really wish Cargo would let us define mutually exclusive features...
I suppose my position is: "I'd like this feature, but I don't think this specific design would work in practice."

@DanielKeep This doesn't seem different from having multiple dependencies on the cfg: #[cfg(depedency=regex, lazy_static)].

I like it, especially the part about cargo doc documenting all the optional dependencies. I've just written a crate with a few features and really wishing that cargo doc would just auto-generate something letting users know what different features activate.  In fact I'm just about to add a serde feature to that crate for conditional deserialization support so if you get this implemented in the next couple of days I'll use it instead 😜

if a matching source for a conditional dependency (e.g. a matching version number) is already present in the graph

I think this could warrant some extra warning information added to cargo, e.g. assuming you have a dependency foo with a conditional implementation for serde 0.8.0 which you are currently using everything will work fine, if at some point in the future you update to serde 0.9.0 in the root crate it will no longer match and you'll start getting build errors like foo::Bar does not implement serde::Deserialize.
If cargo detects this it would be nice to have it suggest that the reason is the non-matching dependency versions. In this case it would probably be easy to detect why it happened, but if it's related to interaction between dependencies of dependencies it might be harder. I think this can only happen with breaking updates (assuming all crates are following semver around publicly exposed dependencies properly), but there might be some case I haven't thought of that would allow a non-breaking dependency update to break this.

Also, what about conditional implementations for multiple versions of a dependency? It might be nice to have something like
#[cfg(dependency = "foobar:1.0.0")]
mod foobar {
    extern crate foobar;
    impl foobar::Bar for MyType {
        ...
    }
}
#[cfg(dependency = "foobar:2.0.0")]
mod foobar {
    extern crate foobar;
    impl foobar::SuperBar for MyType {
        ...
    }
}

although I have no idea how you would specify that in the Cargo.toml 😕

@withoutboats #[cfg(dependency=regex, lazy_static)] would be #[cfg(all(dependency = "regex", dependency = "lazy_static"))]

So I'd really like to enforce that all uses of these conditional dependencies are propoerly guarded by a cfg attribute. As I argued in the internals thread for scenarios, features + a similar cfg-check probably cover scenarios, so now we have two uses for such a thing.

This is a great proposal, and I like the overall idea. This can potentially let us sidestep a lot of issues with Cargo's version resolution if done properly. Having rustdoc include conditional dependencies by default is a nice touch as well. I strongly disagree with the notion that this solves the problems created by the orphan rule, as this still requires a crate to care about every other crate in the ecosystem, or for every other crate in the ecosystem to care about that crate. However, this does greatly improve ergonomics for the end user without having to address the orphan rule directly.

So I'd really like to enforce that all uses of these conditional dependencies are propoerly guarded by a cfg attribute.

What we need are two compilation modes - one with the crate under compilation's conditional dependencies turned on, one with them turned off.

I strongly disagree with the notion that this solves the problems created by the orphan rule

Definitely didn't mean to imply that this solves all of the negative consequences of the orphan rules.

So I think the actual issue that isn't solved by this scheme is not a situation where want to include some code if both (e.g.) regex and lazy_static are in the graph, but where you want to include some code if regex is in the graph, but that requires adding lazy_static.
How often is this desirable? If its something you usually need, it seems like we can do it, but it introduces other questions - if my dependency adds lazy_static while resolving a conditional dependency for regex, and another dependency has a conditional dependency on lazy_static, do we do another round of conditional dependency checking? If that second round adds some more new dependencies, do we continue doing this indefinitely? So on.
The syntax for doing that which is consistent with the syntax in this proposal seems to be accepting a string for the conditional member of a dependency, which indicates that it is conditional on another crate being in scope. As in:
[dependencies.regex]
version = "1.0.0"
conditional = true

[dependencies.lazy_static]
version = "1.0.0"
condiitonal = "regex"

@withoutboats

What we need are two compilation modes - one with the crate under compilation's conditional dependencies turned on, one with them turned off.

Actually that wouldn't cut it. For example, it erroneously allows:
#[cfg(dependency=foo)]
extern bar;
#[cfg(dependency=bar)]
extern foo;

My originally rambling post is https://internals.rust-lang.org/t/fleshing-out-libstd-scenarios/4206/9?u=ericson2314, the tl;dr is we need to do SAT (and when we take into account upstream restrictions, perhaps easier to thank of as as SMT).

The syntax for doing that which is consistent with the syntax in this proposal seems to be accepting a string for the conditional member of a dependency, which indicates that it is conditional on another crate being in scope.

Could we make this still tie-in with features (so that there is no distinction between cfg(feature) and cfg(conditional))? In your specific syntax I think just requiring people to define a regex feature (the way optional=true works right now) would be enough. However, I'd prefer marking the feature as magic/conditional rather than the dependencies.
Your new proposal still misses one use case, where you have two partially overlapping sets of conditional dependencies. Sounds pretty rare, but that and more complicated overlappings are cleanly handled by the magic feature proposal.
Regarding having to re-resolve indefinitely, it's not indefinite -- there is a finite number of dependencies and the conditional resolution algorithm is monotonic.

@Manishearth I imagine making this a 'property of features' would look something like this:
[features.serde]
dependencies = [serde]
automatic = true

And then the feature would be opted into automatically if the dependencies listed are already present. You could also imagine that automatic (or whatever) can take a list of dependencies separate from the dependencies listed as members of this feature, and the feature is opted into if the dependencies in automatic are listed.
These syntaxes seem equally capable to me. I'll list this as an alternative when I revise this RFC. I personally prefer the syntax in the RFC right now because it creates a distance between this and features. I don't see this as a system for making features easier to opt into, but as a system for ergonomically solving a problem that is being solved unergonomically with features right now. Maybe my view of it is limited though. I will admit I have a bias against feature systems in general, including ours. Because of their generality, they are always sort of frustrating to use in my experience.

Your new proposal still misses one use case, where you have two partially overlapping sets of conditional dependencies.

I do not know what you mean by this.

These syntaxes seem equally capable to me.

More or less yeah. The main difference is that this creates a second config system independent of features, whereas I'd prefer to work within the same framework. I really want to avoid a system where you have both cfg(feature=) and cfg(conditional=). If using features, you get interoperability with features, easy upgrades without breaking changes (folks can make their features automatic, and users won't be forced to change their cargo files to upgrade, nor do maintainers have to keep both a feature and a conditional alive in parallel till the next breaking change), and the same ability to pick and choose features in deps that we already have (instead of including conditional deps that match the ). This especially matters for conditional deps that need more than one crate to work (serde+serde_derive, for example). As a library I may not be using serde_derive, but I would like to trigger the serde conditional in a dependency of mine. I can't without including serde_derive (which means I have to go back to the dependency's cargo.toml and pick up all the conditional deps). However, if it has a "serialize" feature I can easily specify features = "serialize" for the dependency and it will work. Furthermore, the dependency can add more deps to the feature and I don't have to change anything.

I do not know what you mean by this.

I was wrong. Thought about it more.

If using features, you get ... easy upgrades without breaking changes

This is pretty compelling!

Another reason I like the "automatic features" design is that I can imagine having features which some clients want to explicitly enable without caring exactly what set of (conditional) dependencies you use to implement those features.
If I use serde for everything, I'd like all my dependencies to automagically compile their serde impls. But if there's only one or two libraries I want to serialize types from, and I don't care whether Foo.serialize() uses serde or rustc-serialize or whatever, I'd prefer to turn on "the serialize feature" rather than pretend I depend directly on serde.

FWIW, I prefer going through features for this.

Based on feedback for the past three weeks I've intended to rewrite this from "Conditional dependencies" to "automatic features," but I have trouble finding the time. If anyone wants to rewrite the proposal to work as @Manishearth suggested, I would happily accept the PR into this branch.

I will ... try, but I'm not sure if I have time. (So if someone else can pick it up that would be great!)

Rewrote proposal at https://github.com/withoutboats/rfcs/pull/1

RFC has been updated with @Manishearth's edits. There's still more things to disagree about on it. :-)

I completely agree with the new version. Obviously.

It would be fantastic if this interacted with #1133 to allow #![no_std] crates to automatically enable std functionality when its being pulled in.

Reading over this the RFC looks pretty good to me, along with the underlying idea.
I have a number of questions here, but lots of them boil down to clarifying this statement.

It will then look for features (in all crates in the graph) that only need dependencies which are already part of the graph.

More formally, any feature in a manifest can be expanded to a list of dependencies in the [dependencies] section plus a list of other features. Both of these lists could be empty. If the feature were enabled, then these two lists would also be enabled. My assumption is that this RFC is basically saying that if all of the dependencies are enabled, then the feature itself is enabled (as everything it wants is already there).
If that's true, which I'm not 100% sure if it is, then I think it would be good to clarify at least that dependency matching is still performed on dependencies. For example if I have an automatic, optional dependency on serde 0.7 then if serde 0.8 is in the dependency graph then my serde dep shouldn't be activated.
Additionally, if the set of feature-dependencies of a feature is not empty, I don't quite understand the semantics of how that's automatically enabled. For example, if we have:
[dependencies]
serde = { version = "0.8", optional = true }

[features]
serialize = { dependencies = ["serde", "other"], automatic = true }
other = []

Is it possible for the serialize feature to ever get automatically enabled? It'd require at least serde 0.8 to be enabled in the dependency graph but would it also require the other feature to be activated by some other dependency? The wording in this RFC makes it sound like serialize is activated if serde 0.8 is included (regardless of other), but this seems slightly odd to me.

Along those lines, I think a more rigorous specification would then also assist in clarifying edge cases like:
[features]
foo = { automatic = true }

Is that an error? Always activated? Never activated?
Similarly it'd help clarify:
[features]
foo = { automatic = true, dependencies = ["bar"] }
bar = []

Does enabling bar enable foo through automatic features? Is this an error? (etc)

My assumption is that this RFC is basically saying that if all of the dependencies are enabled, then the feature itself is enabled (as everything it wants is already there).

correct

Is it possible for the serialize feature to ever get automatically enabled?

Not unless the other crate is pulled in by someone else.

The wording in this RFC makes it sound like serialize is activated if serde 0.8 is included (regardless of other), but this seems slightly odd to me.

Which part of the wording makes this feel that way?

Is that an error?

Error I'd say.

Does enabling bar enable foo through automatic features?

Yes.
@withoutboats do you have time to make these clarifications?

@alexcrichton I don't know much (anything, really) about the dependency resolution algorithm that cargo uses. How hard do you think it would be to integrate this into that code?

Oh, and my assumption was that if you had an automatic feature tied to serde-0.7, then indeed serde-0.8 would not trigger it (but presumably one could have other semver operators too).

@nikomatsakis I think it sort of depends on the precise meaning of the RFC, but my current belief is that given my own personal interpretation of this RFC it should be very easy to add to Cargo. It would look something like:

For all automatic features, it depends on a list of dependencies, a list of local features, and lists of features in each dependency.
Dependency resolution is performed as-is today, afterwards considering automatic features
Automatic features are then activated if they meet the following criteria:

All dependencies of an automatic feature are satisfied with an existing node in the dependency graph
All feature dependencies of an automatic feature are already activated for the crate in question
All features enabled in dependencies are also already activated

If that's all true then the automatic feature is activated, new dependency edges are drawn, and the set of activated features for a crate is updated to include the automatic feature. I think this would need to be an iterative process run until the graph is stable to handle automatic features depending on automatic features, but it shouldn't take more than O(n) time where n is the number of nodes.

Yeah, your interpretation is correct. With serde-0.7/0.8 an automatic feature won't be activated unless the crates that it depends on up to the precise version ranges are already in there.

Yes, the key rule is new edges, not new nodes. Since nothing currently can depend on a feature being disabled, we have a single unique solution that all possible traces of the iterative process will arrive at. Note that if we did have mutually-exclusive features or similar, then there may not be a unique solution.

Hmm, I think I found another issue.
An important part of package management is adjusting one's dependencies should never in itself be a breaking change of one's own interface. But if a crate relies on some transitive dep triggering an automatic feature of an immediate dep, and that transitive dep disappears, then our crate will break because its intermediate dep has to rely on less.
There is two compatible solutions here, i.e. any crate in the ecosystem can adopt either, Cargo doesn't need to pick up front:

Crates don't, in fact, rely on the optional features. Instead, they condition any code that does on the dependency's feature (or equivalently declare their own optional feature wrapping the dependency's feature and cfg on that).

Optional dependencies are only exposed considering "sibling" dependencies: Our crate only gets access to its dependency's optional features if its own other dependencies [hence they both have the same parent, our crate, and are siblings]. If "half-siblings" from another crate would trigger the optional feature, then our crate should not be privy to this (in the bright scenario's future where non-requested things in general aren't leaked). Furthemore, if only non-siblings would cause the optional feature to be enabled under the old rules, then no one gets to use it, and there's not point compiling the dependency with the optional dependency enabled at all.
If we wish to require more opt-in from the user (though this doesn't affect soundness), instead of looking at all sibling deps, crates could specify which sibblings should be aware of each others existance, e.g. { spin = ..., lazy_static = { knows about = ["spin"], ... } }.

Besides soundness, I believe that this also has the benefit of cheapening optional dependency resolution. I think it can now be performed in parallel for every interior node, and the results aggregated at the end.

Meta comment: So far, I haven't seen very much effort put into formalizing Cargo and considering whether it upholds certain properties we care about, or even what those properties are. I get that, in the absence of enforcing users to package their code properly (or be able to automatically blacklist crates that aren't packaged properly), the soundness is Cargo won't be practically put to the test. But I'd hope that this RFC and https://github.com/rust-lang/rfcs/pull/1841 indicate that getting Cargo sound is very subtle---potentially as subtle as getting Rust itself sound. At the very least, I'd hope we'd be able to exhaustively document everything users need to worry about to type-check their crates' Cargo.tomls and !#[cfg(..)]s by hand.

The point about transitive dependencies is a good one. Scenarios would help here since we could prevent you from using those features unless you had the direct dependency even if another crate already was using it.

@hvr, a Cabal developer, just told me that Cabal's "automatic flags" (basically this) are not intended to affect a package's interface. This means it is sound to use the global algorithm, which can discover optional edges the local one won't.
I think both are useful---for example I suppose if optional features don't affect the public API, they probably improve performance, in which case the more the merrier! [At least in release builds, more edges do reduce build parallelism.] The global algorithm's disadvantage---enabling more non-trivial edges---becomes and advantage in this case.

@sfackler Well, the other thing I've been thinking is "scenarios" need not be a whole new feature of Cargo, but rather a reformation of features/cfg. [Apologies for using the word "feature" in two different senses.]

Crates don't, in fact, rely on the optional features.

Except for toplevel crates.
But this doesn't solve the original problem then. Let's say I have a crate which needs serialization to work. It wants to enable serde in all of its transitive dependencies. I want to be able to do this easily, so it just specifies a serde dep in the top level and the automatic features pull it in in its dependencies. If there is a version mismatch that's not a different situation than what we'd be in previously, and you have that kind of problem with non-optional dependencies anyway.
Not relying on optional features brings us back to the status quo.

Optional dependencies are only exposed

How would you gate that? Remember that an optional dependency is more than just an extra rlib; there will be cfgs in the parent crate that compile differently. You cannot control access to things affected by the cfgs.

Most of this is nicely solved by the fact that if you're relying on an optional dependency like serde you'll need to pull the crate in anyway to use it. It's not perfect, but basically we can declare that if a crate wish to forcibly trigger an optional dependency of its dependenc(ies) to be pulled in, you must specify its constituent crates/features in the crate that needs the dependency to be triggered. This can be a rule that is not enforced; I'm not sure if it can be enforced.

Except for toplevel crates.

I'm not sure what's special about them here? Moreover making the top ones of a DAG special is IMO a smell. Inductively, the leaf nodes are the base case and the roots are just more interior nodes.

Let's say I have a crate which needs serialization to work. It wants to enable serde in all of its transitive dependencies....

Good point. Heh, oh the joys of trying to find something both sound and useful! One possible solution (possibly sound, in that I just thought of it :)) is feeding in crates to all their siblings' descendants. In your example, since serde is a dependency of the root crate, everything gets built with serde-deps enabled, but only the root crate gets to see those optional features enabled by serde.
Maybe that's good enough, or maybe the intermediate crates needs to know their deps also use serde so they can write the relevant instances. In that case, they would need their own optional dependencies anyways for their serde usage. I forgot about routing optional sibling crates in my previous post, but that would allow the serde optional dep to be propagated without the change from the previous paragraph. [This removes the embarrassingly parallel aspect, but keeps the algorithm "weakly inductive" (I think that's the term) where you only consider a node and its immediate children rather than all descendants.]
Say there is a "gap" in the dag, with some crates using serde not reachable via the root crate following edges between serde-caring crates (which is using serde). Does it matter? I'm not sure. If it does, then we need both ideas---propagating optional features and propagating siblings to siblings' children.

If there is a version mismatch that's not a different situation than what we'd be in previously, and you have that kind of problem with non-optional dependencies anyway.

Ah! Let me add a detail I forgot in my previous paragraph (and which I am not adding there retroactively for the sake of information density). Each serde-aware crate should have have an optional automatic feature on serde, and that optional dependency should require (not merely allow to be enabled) the optional dependency of its immediate dependencies. Then, inductively, all the crates will be required to use serde together, and we, erm, somewhat side step your concern about whether versions should be resolved entirely before automatic features.

How would you gate that? Remember that an optional dependency is more than just an extra rlib; there will be cfgs in the parent crate that compile differently. You cannot control access to things affected by the cfgs.

This is the hard crux of what I think is already proposed as part of scenarios. We need to mask the interface of crates to match these hypothethetical other resolutions. The "Additivity" rule from https://github.com/rust-lang/rfcs/pull/1841 is essential to make sure this is always upcasting and thus possible.

Each serde-aware crate should have have an optional automatic feature on serde, and that optional dependency should require (not merely allow to be enabled) the optional dependency of its immediate dependencies.

No. That's my entire point. This is the status quo, this is exactly what you do when you want to use features. This has always been problematic, because you need to thread features through a million different Cargo.toml files. This is exactly what this RFC is trying to avoid.

One possible solution (possibly sound, in that I just thought of it :)) is feeding in crates to all their siblings' descendants.

Breaks down in the presence of generic types being pulled in from a different part of the dag.

No. That's my entire point...

Well then at least we need to require that no two automatic features are triggered by different version of the same crate. Still thinking about the rest.

That restriction feels strange, but I don't see any actual issues with it.

Yeah its weird to me too. Very global, very not inductive

If there is a version mismatch that's not a different situation than what we'd be in previously, and you have that kind of problem with non-optional dependencies anyway.

Oh, do you mean the sketchy fact that we already allow multiple versions of the same crate in build plans?

Oh, do you mean the sketchy fact that we already allow multiple versions of the same crate in build plans?

Yeah.

Breaks down in the presence of generic types being pulled in from a different part of the dag.

You mean generics + traits? I'd think generics alone would be fine.

Based on discussion at the most recent Cargo team meeting, I'm going to close this as postponed.
While this still seems like a very promising idea, there are some more pressing revisions for the feature system (and in general bigger fish to fry with Cargo right now). Let's plan to revisit in 2018!

Sorry, that was a bit terse -- I'm trying to push on a bunch of RFCs and went too quickly. In more detail, Cargo folks are definitely fans of this idea. But:

There are some significant issues with the feature system right now, which we intend to revise as part of the build system integration work. We're generally holding off on extensions to the feature system until we've successfully rationalized what's there.

Our hands are going to be extremely full with some of the tasks on deck (the build system work alone could easily take the rest of the year).

Put together, it seemed wisest to delay finalizing the design here until the dust settled in other parts of Cargo.

Has the dust already settled?
"Include tokio/async-specific features" seem to be a good example of an automatic feature. Otherwise either tokio/futures would suddenly appear unless default-features = false; or all async users need to write the curly brackets.

Having vendored perl packages which have been doing this since forever, I can only say that in practice its a terrible idea.
The last thing you want when trying to build a reliable system is having to think about the possibility you will incur a functional change as an incidental side effect of something simply having been present, where it previously was not.
Clarity in dependencies and explicitly requiring things when you need them is worth the extra tiny amount of developmental pain.
I'd hate to ever update one of my dependencies, which in turn, pulls in a new dependency, and have it turn on a feature in a different dependency which changes how my code behaves.
That's right in "spooky action at a distance" territory, and can be a nightmare to work out where the breaking change was introduced.
(Isn't that part of why we like use as opposed to a great big global share of everything like C has? ... 'automatically visible functions'. )


Sharp image processing without in-memory buffering using stream

I need to create a /api/lqip route to create base64 encoded image placeholders. Also, the question concerns normal image resizing.
I came across a technique for image processing without in-memory buffering using PassThrough while exploring the Remix image resizing example (https://github.com/remix-run/examples/blob/main/image-resize/app/routes/assets/resize/$.ts).
I'm not an expert in the backend, so I'm wondering should I use the sharp processing as regular or with stream.
Thanks.

If the input is already held in memory as a Buffer and the output also needs to be a Buffer then I recommend Buffer-based input and output. As your examples demonstrate, it's much simpler and probably faster.
(The example you linked to appears to require Stream-based output, so that's probably why Streams are used. It looks like the input is already present on the local filesystem, so I suspect it could be further optimised to use filesystem-based input whilst keeping the Stream-based output.)


Return proper exception when group by is used on count(distinct)

Codecov Report

Merging #5701 into master will decrease coverage by 0.09%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##             master    #5701     +/-   ##
===========================================
- Coverage     83.04%   82.94%   -0.1%
+ Complexity    11814    11796     -18
===========================================
  Files          1394     1394
  Lines         45347    45350      +3
  Branches       5605     5606      +1
===========================================
- Hits          37657    37616     -41
- Misses         5088     5128     +40
- Partials       2602     2606      +4

Impacted Files
Coverage Δ
Complexity Δ

...rate/analyze/validator/GroupBySymbolValidator.java
83.33% <100%> (+2.38%)
4 <0> (ø)
:arrow_down:

...in/java/io/crate/lucene/match/CrateRegexQuery.java
43.47% <0%> (-39.14%)
4% <0%> (-5%)

...arch/indices/recovery/BlobStartPrefixResponse.java
66.66% <0%> (-33.34%)
3% <0%> (-2%)

...rc/main/java/io/crate/analyze/UnboundAnalyzer.java
70% <0%> (-25%)
2% <0%> (ø)

...in/java/io/crate/data/CollectingBatchConsumer.java
69.23% <0%> (-15.39%)
4% <0%> (-1%)

...ration/reference/doc/lucene/IpColumnReference.java
72.72% <0%> (-13.64%)
5% <0%> (ø)

core/src/main/java/io/crate/types/ShortType.java
80.76% <0%> (-11.54%)
16% <0%> (-3%)

...ticsearch/indices/recovery/BlobRecoveryStatus.java
63.63% <0%> (-9.1%)
3% <0%> (-1%)

...rate/action/sql/BatchConsumerToResultReceiver.java
83.67% <0%> (-6.13%)
15% <0%> (-1%)

.../java/io/crate/analyze/symbol/ParameterSymbol.java
82.35% <0%> (-5.89%)
6% <0%> (-1%)

... and 13 more

Continue to review full report at Codecov.

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


Modify VariableSource from subscription

Figure out what to do when a source is modified from within a callback, when there's still more callbacks to process.

A first version to prevent this from creating time consuming bugs could be:

When we start to call the handlers set a flag, unset the flag when all handlers are called
If the value is modified while the flag is set, fatalError

I think a fatalError is appropriate since it currently gives unpredictable behaviour and therefore is unsupported by this library.


Add framework for adding Languages

Prepare 8Vim for adding new languages.
Here's a few to-do's:

Add the possibilities of having multiple layouts in one app

Add menu-options in the settings for switching layouts.

Make it possible to have two layouts of the same language in the app (for example: New English layout & Old English layout for people who don't want to switch)

Give the layouts name-tags and display a description. (for example, describe what the old/new layout is)

(Also add an option for custom Layouts)

This is something I suggest working on soon, to prevent having to wait for a long time, once the language-specific Layouts arrive.

If you start to implement different language layouts you could also consider to add a framework to localize the settings screen for supported languages and maybe the texts used in app-stores.
I know this is actually of minor importance but it adds a lot to the look and feel of the app.
Cheers,
Gecko

@GeckoClimber Yea, that would also come up as time passes, for now I won't be able to setup localization.

@sslater11 @Glitchy-Tozier, The basic framework is almost ready for the layout selection.
If you guys are interested, I can setup alternate English by sslater11 and German by Glitchy-Tozier for this first draft.
This will allow me to test the multiple language setup and multiple layouts within a language setup properly.

That sounds great. Let's make a temporary layout!
(Personally, i haven't used 8vim much, so I need some experience to know what movements flow well)

Also, @flide, does this already include some diacritics-movement?

no diacritics yet, that is the reason I wanted this first draft with all
german characters included.
Give me your best draft and one with all character, I will try to make
diacritcs work for german language only.
On Wed, 23 Dec 2020, 13:01 Glitchy-Tozier<EMAIL_ADDRESS>wrote:

Also, @flide https://github.com/flide, does this already include some
diacritics-movement?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flide/8VIM/issues/144#issuecomment-749986376, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABX5WR7USLNSMTOOBEUKZPLSWGMFNANCNFSM4U7W5RXA
.

Sure thing, give me a few hours!

Damn it, I forgot about ß.
I guess

Swap , and ?
Then exchange ? for ß

Give me your best draft and one with all character, I will try to make
diacritcs work for german language only.

That means that you'll implement those layouts in iteration 7, right?
(Of course, they should clearly be labeled as Temporary layouts, for testing purposes only! or something of the likes)

Yea, I am trying to.
On Tue, 29 Dec 2020, 22:49 Glitchy-Tozier<EMAIL_ADDRESS>wrote:

Give me your best draft and one with all character, I will try to make
diacritcs work for german language only.
That means that you'll implement those layouts in iteration 7, right?
(Of course, they should clearly be labeled as Temporary layouts, for
testing purposes only! or something of the likes)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flide/8VIM/issues/144#issuecomment-752170059, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABX5WR6V27CGA35YXHWZBK3SXIFS3ANCNFSM4U7W5RXA
.

Sorry, moved to iteration 8

I have published a version with @Glitchy-Tozier's layouts: https://github.com/adamschmalhofer/8VIM/releases/tag/devel-1
As we now have diacritics, I'm kind of curious how the optimal layout once that is considered.

@adamschmalhofer If you're curious: Pretty sure i wanted the layout rotated because of the diacritics gesture that was considered at the time (which I still think would be one of the best options)

Hi All,
With the help of @adamschmalhofer 's contribution, I have been able to setup a framework for adding layouts easily.
To add a new layout following needs to be done:
Develop a keyboard-data xml file.
Name the file with following format [{language-iso-code}_{font-code}_{layout-name}]
Place the file in the raw folder

Language code is the 2 character code for the language as per ISO standard
Font code is one of the following strings, and as of now only "regular" is going to function properly : "regular", "bold", "italic", "underline"
Layout name is the display name of the layout

In the settings menu the layout would be presented as "Layout name (Language)"
The characters for the layout are now part of the keyboard-data file itself.
Please check the "he_regular_hebrew" file in the raw folder for reference.
I will request all to open one PR per layout.


Fix outstanding broken links

Here is a Google Sheet with remaining broken links. We should fix these soon.

#1618 is probably in the list but referencing the issue to make sure.

Hi, I don't think you have these which I found in the showcase tutorial
http://holoviews.org/Tutorials/Introduction.ipynb
http://holoviews.org/Tutorials/Exploring_Data.ipynb
http://holoviews.org/Tutorials/Options.ipynb
http://holoviews.org/Tutorials/Elements.ipynb
http://holoviews.org/Tutorials/Containers.ipynb
Thanks for making a great tool.

Closing this since the list is outdated.


feat(history): Add new flag to allow custom output format

Fixes #619
Hey, that's an easy one to implement but I'm not sure what's the best way to display it, here's a few examples:
❯ cargo run history list 2>/dev/null | tail -n1
2023-01-11 20:35:26     < /home/baptiste/github.com/BapRx/atuin >       cargo run history list 2>/dev/null | tail -n1   0s
❯ cargo run history list 2>/dev/null | tail -n1
2023-01-11 20:35:44     === /home/baptiste/github.com/BapRx/atuin ===   cargo run history list 2>/dev/null | tail -n1   0s
❯ cargo run history list 2>/dev/null | tail -n1
2023-01-11 20:36:00     (/home/baptiste/github.com/BapRx/atuin) cargo run history list 2>/dev/null | tail -n1   0s
❯ cargo run history list 2>/dev/null | tail -n1
2023-01-11 20:36:17     [/home/baptiste/github.com/BapRx/atuin] cargo run history list 2>/dev/null | tail -n1   0s
❯ cargo run history list 2>/dev/null | tail -n1
2023-01-11 20:37:10     /home/baptiste/github.com/BapRx/atuin$  cargo run history list 2>/dev/null | tail -n1   0s

If we want this to be optional I can add a flag like --show-cwd

I wonder at what point we should provide a formatting flag.
I think at this point I'd be hesitant to change the current format since some users might be piping it into other scripts and that might break (eg cut + fzf)

Yes that's what I thought, a flag is definitely required to avoid breaking anything.
The format flag is a good idea! I have no idea how to code this but I'll give it a try. Thanks for your input 👍

Hey @conradludgate, I implemented a new --format flag to allow custom output format. Is that what you had in mind? The default behavior is to use the current format (human or regular).
Here's a few examples:
❯ atuin history last -h
Get the last command ran

Usage: atuin history last [OPTIONS]

Options:
      --human
      --cmd-only         Show only the text of the command
  -f, --format <FORMAT>  Output format, you can use the special variables {command}, {directory}, {duration} and {time}. Example: --format "{time} - [{duration}] - {directory}$\t{command}"
  -h, --help             Print help information

❯ # Use default formatting
❯ atuin history last
2023-01-12 16:31:26     atuin history last -h   250ms

❯ # Use custom format
❯ atuin history last -f "{time} - [{duration}] - {directory}$\t{command}"
2023-01-12 16:31:52 - [265ms] - /home/baptiste/github.com/BapRx/atuin$  atuin history last

❯ # Exit on format error
❯ atuin history last -f "{time} - [{duration}] - {this_variable_doesnt_exist} - {directory}$\t{command}"
ERROR: History formatting failed with the following error: KeyError(Invalid key: this_variable_doesnt_exist)
If your formatting string contains curly braces (eg: {var}) you need to escape them this way: {{var}}.

❯ atuin history last -f "{time} - [{duration}] - {{this_variable_doesnt_exist}} - {directory}$\t{command}"
2023-01-12 16:33:27 - [278ms] - {this_variable_doesnt_exist} - /home/baptiste/github.com/BapRx/atuin$   atuin history last -f "{time} - [{duration}] - {this_variable_doesnt_exist} - {directory}$\t{command}"

Wow that was quick! It looks exactly how I had in mind, thanks!
I'll review the code when I have some spare time. @ellie what do you think of this idea before we continue any further?

I really like this! Thank you for the effort 🚀
I'll leave it to @conradludgate to handle the review heh

Thanks for this, I made a few changes for performance, and I've added the user/host field as @tuxruffian pointed out. I've tested this quite a bit and it works well. Thanks for taking the time to design this :D


Getting accurate data from the MEA2100 device in Python

Hello,
We intend to use the MEA2100 system to record from and stimulate cultured neuron cells. We have managed to successfully set up the device (with noise testing and signal acquisition with the provided generator), and now we intend to use Python to write our own codes for the device. We tried using the Python examples provided by your company on GitHub, and while the code runs without any issues, we were unable to gain the proper signals from it. We are currently trying to read the sinusoidal signals generated using the signal generator provided along with the system. When we use the MEA data experimenter, we can clearly see the sinusoidal signals as seen in the picture below:

When we try to do it using MATLAB, we run into some issues regarding communication with the device, but we can still obtain the sinusoidal signal as intended.
Unfortunately, when we try using the Python code provided as an example, we do not get any intelligible signal from the device. We are getting something like this:

We would have been worried if there were some issues with the device or our computer, but both the experimenter and even MATLAB can read the sinusoidal signal. However, we would like to perform some additional data processing which is much more convenient in Python, so we would like to write our codes in Python if possible.
We also tried to reduce the number of channels in the block to 1 by changing the number of electrodes to 1 and disabling the checksum channel reading to see where the issue was, but it did not solve the problem. We also tried to implement the MATLAB code for data acquisition (run_mea.m) in Python since it could read the sinusoidal signal (we disabled the OnChannelData handler to do it), but again we did not get any sinusoidal signal. I have added the full code in the comments for your reference.
It is to be noted that the computer we are using for this has Windows 10 (64-bit) with a .NET version of 7.0.302. We tried installing an instance of version 4.7.2, but the OS did not let us do it as there is a higher version already installed. The documentation also says that higher versions would work so we did not try doing anything further. We also thought about whether our computer is properly interpreting the “clr_array_to_numpy.py” script, but it seems unlikely to have any issues.
We greatly look forward to your response.

import time
import os
from pythonnet import load ### Without this, the *.dll file was not loading due to belonging to a lower .NET version
load("coreclr")
import clr
import ctypes
import numpy as np
import matplotlib.pyplot as plt
from System import *
clr.AddReference('System.Collections')
from System.Collections.Generic import List
from clr_array_to_numpy import asNumpyArray
clr.AddReference(os.getcwd() + '\..\..\McsUsbNet\x64\\McsUsbNet.dll')
from Mcs.Usb import CMcsUsbListNet
from Mcs.Usb import DeviceEnumNet
from Mcs.Usb import CMeaDeviceNet
from Mcs.Usb import McsBusTypeEnumNet
from Mcs.Usb import DataModeEnumNet
from Mcs.Usb import SampleSizeNet
from Mcs.Usb import SampleDstSizeNet
#%%
def OnChannelData(x, cbHandle, numSamples):
if dataMode == DataModeEnumNet.Unsigned_16bit:
data, frames_ret = device.ChannelBlock.ReadFramesUI16(0, 0, callbackThreshold, Int32(0));
np_data = asNumpyArray(data, ctypes.c_uint16)
print(".Net numSamples: %d frames_ret: %d size: %d" % (numSamples, frames_ret, len(np_data)))
else: # dataMode == DataModeEnumNet.Signed_32bit
data, frames_ret = device.ChannelBlock.ReadFramesI32(0, 0, callbackThreshold, Int32(0));
np_data = asNumpyArray(data, ctypes.c_int32)
print(".Net numSamples: %d frames_ret: %d size: %d" % (numSamples, frames_ret, len(np_data)))
if len(np_data)<1000:
    return

plt.figure()
plt.plot(np_data)

def OnError(msg, info):
print(msg, info)
#%%
deviceList = CMcsUsbListNet(DeviceEnumNet.MCS_DEVICE_USB)
DataModeToSampleSizeDict = {
DataModeEnumNet.Unsigned_16bit : SampleSizeNet.SampleSize16Unsigned,
DataModeEnumNet.Signed_32bit :  SampleSizeNet.SampleSize32Signed
}
DataModeToSampleDstSizeDict = {
DataModeEnumNet.Unsigned_16bit: SampleDstSizeNet.SampleDstSize16,
DataModeEnumNet.Signed_32bit:  SampleDstSizeNet.SampleDstSize32
}
#%%
print("found %d devices" % (deviceList.Count))
for i in range(deviceList.Count):
listEntry = deviceList.GetUsbListEntry(i)
print("Device: %s   Serial: %s" % (listEntry.DeviceName,listEntry.SerialNumber))
#%%
dataMode = DataModeEnumNet.Unsigned_16bit;
#dataMode = DataModeEnumNet.Signed_32bit;
device = CMeaDeviceNet(McsBusTypeEnumNet.MCS_USB_BUS);
device.ChannelDataEvent += OnChannelData
device.ErrorEvent += OnError
#%%
device.Connect(deviceList.GetUsbListEntry(0))
Samplingrate = 10000;
device.SetSamplerate(Samplingrate, 1, 0);
#%%
miliGain = device.GetGain();
voltageRanges = device.HWInfo.GetAvailableVoltageRangesInMicroVoltAndStringsInMilliVolt(miliGain);
for i in range(0, len(voltageRanges)):
print("(" + str(i) + ") " + voltageRanges[i].VoltageRangeDisplayStringMilliVolt);
#%%
device.SetVoltageRangeByIndex(0, 0);
device.SetDataMode(dataMode, 0)
device.SetNumberOfChannels(1) ### Here the number of channels is changed from 2 to 1
device.EnableDigitalIn(Boolean(False), UInt32(0))
device.EnableChecksum(False, 0) ### For now, we disabled the acquisition for checksum channels
block = device.GetChannelsInBlock(0);
print("Channels in Block: ", block)
callbackThreshold = Samplingrate // 10
#%%
if dataMode == DataModeEnumNet.Unsigned_16bit:
mChannels = device.GetChannelsInBlock(0)
else: # dataMode == DataModeEnumNet.Signed_32bit
mChannels = device.GetChannelsInBlock(0) // 2;
print("Number of Channels: ", mChannels)
device.ChannelBlock.SetSelectedChannels(mChannels, callbackThreshold * 10, callbackThreshold, DataModeToSampleSizeDict[dataMode], DataModeToSampleDstSizeDict[dataMode], block)
analogChannels,digitalChannels,checksumChannels,timestampChannels,mChannels=0,0,0,0,0
analogChannels,digitalChannels,checksumChannels,timestampChannels,mChannels=device.GetChannelLayout(analogChannels,digitalChannels,checksumChannels,
timestampChannels,mChannels,0)
print(analogChannels,digitalChannels,checksumChannels,timestampChannels,mChannels)
#%%
device.StartDacq()
time.sleep(0.99)
The code below is copied from the MATLAB example and converted to suit Python
x=0
while True:
for i in range(1):
while device.ChannelBlock.AvailFrames(i, -1)<1000:
time.sleep(0.01)
number = device.ChannelBlock.AvailFrames(i, -1)
print('Number: ',number)
#wait until at least 5000 samples are available
if number >= 1000:
print('Bingo')
#read 5000 samples
data, frames_ret = device.ChannelBlock.ReadFramesUI16(i, 0, 1000, Int32(0));
        if i == 0:
           #Because the data is acquired in 16 Bit unsigned format, we need to subtract 2^15 to center it around Zero.
           y = asNumpyArray(data, ctypes.c_uint16)
           # mask = bitshift(1, 15); # Create a mask with the 16th bit set to 1
           # y = bitxor(y, mask); # XOR the variable with the mask
           y = y-32768;
           plt.figure()
           plt.plot(y[0:100]);

time.sleep(0.1);
x = x + 1;
print("x: ",x)
if (x == 5):
    break # stop after 500 data packets (~ 5 seconds)

device.StopDacq()
#%%
device.Disconnect()

@happypanda94 Did you have any success with your problem?


PEP 517 & pyproject.toml

I've got round to looking at this again, and trying to update it for the provisionally accepted version of PEP 517.

Thanks Brett. I think it's a matter of me taking the time to satisfy myself
that I'm happy with it all and prepare for a new release soon after
merging. I'm at pycon UK for the next few days, so it's not going to happen
immediately.
So there's nothing concrete, but if you have time to read code or test with
this branch, it can't hurt to have more eyes on it.
On 27 Oct 2017 6:16 p.m., "Brett Cannon"<EMAIL_ADDRESS>wrote:

Do you need any help in moving this forward?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/takluyver/flit/pull/137#issuecomment-340031498, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUA9ROPgFVxtcA55NnD-JYD7TF6oY4vks5swg_UgaJpZM4PxyeW
.

Thanks for the update! I just wanted to make sure there wasn't anything blocking you that I could help with unblocking. I'll see if I can find time to do a code review.


Standalone command-line tool follow-up

Continuation of https://github.com/iterative/terraform-provider-iterative/pull/610

[x] https://github.com/iterative/terraform-provider-iterative/issues/638
[x] #652
[x] #655

[x] Provide sensible logger output for TTY and non-TTY formats
[x] Separate commands to list logs & general status[^2]

[^1]: Unlike in Terraform HCL, values must not contain arithmetic expressions (e.g. 60*60*24 is not valid, but 86400 is valid). Also, declaring multiple resource blocks produces undefined behavior; i.e. defined behavior, but too contrived to explain in a footnote; definitely not what users expect.
[^2]: With a special case for $parallelism > 1$ where users can filter logs for a single task.

after a "Provide sensible logger output for TTY and non-TTY formats" I think an attach type command would be helpful to "live" monitor a task.

Part of “Separate commands to list logs & general status” to my mind. It could be log --follow or similar?

Closing in favor of https://github.com/iterative/terraform-provider-iterative/issues/666, which holds the remaining items 😈


Add missing Ranks and Tiers + Larger Icon format

I really appreciate your help with this, but I went with #7 as it had slightly better details on each icon and I believe each icon is sufficiently large in good detail to not need the another standard for tiers, with even bigger icons.


Enable discussions for this repository

It would be nice to have Github discussions enabled for this repository to be able to ask questions, clarify behavior, etc.

Good idea. Let's try it out...


Repackaging Microsoft defender for office 365 solution

Required items, please complete
Change(s):

updating changes coming from PR #8295

Reason for Change(s):

See guidance below

Version Updated:

Required only for Detections/Analytic Rule templates
See guidance below

Testing Completed:

See guidance below

Checked that the validations are passing and have addressed any issues that are present:

See guidance below

Hello @v-vdixit we are still in this issue.


New (?) transformations in graspit

Hello Jennifer,
I am not sure if this is the right place for this issue or the official graspit repo, but I will try here first, since this repository's response rate is much better!
I have developed and now maintaining this repo: https://github.com/gstavrinos/ez_pick_and_place, which uses graspit-pkgs as a basis to offer a friendly way to create pick and place tasks.
When I saw that you updated from household and manipulation msgs to moveit_msgs I did so with my package, to maintain compatibility.
The problem is that after some months of not using my package, something else seems to be completely broken, making the package unusable. There seems to be a change in the transformation system of graspit (or graspit-pkgs), and now the grasping poses do not correspond to the same poses in ROS. Hence, even though the grasping poses seem fine in the graspit world, they are rotated in the ROS coordinate world, resulting in infeasible planning.
I have tried to dig into both graspit and graspit-pkgs for a striking change on transformation systems, but have not found anything too obvious.
Did you make such a change on graspit-pkgs or notice something like that in the graspit code base?
Thank you in advance, and sorry if I am spamming the wrong repo.
George

As an example, check out this image:

The expected candidate pose, should have the z axis (blue) pointing towards the object and not the y axis (green).

Hi George,
I haven't changed anything in the coordinate system.. And the new moveit_msgs are pretty much the same, so I doubt it's got to do with that.
But I can look into it, at the moment I'm on holidays though, so I can't promise when I'll get around to try it out.
Meanwhile, if I understand it correctly, the output from graspit (specifically the grasp pose) is just rotated around the x axis by 90 degrees? A quick fix would be to correct that rotation right after it is returned from graspit. That would work until the actual reason this happens has been investigated.
Thanks for reporting this. Let me know when there is any update on this, I'll post here as well once I get around to look at it.
Cheers
Jennifer

Hey Jennifer,
Thanks for the answer. There is a chance that there is a problem with a urdf and a gazebo plugin that causes the problem, so please don't bother with the it. At least not yet. I will keep you updated.
Thanks again,
George

Hi George,
Ok, let me know as soon as there's an update on this.
Cheers
Jennifer

Hey Jennifer,
It is definitely not a problem with your repo or graspit. I have cornered the issue to some urdf changes on parent repositories and kinematics libraries. I am closing this issue since it is not relevant.
Thanks for your time,
George

Ok, thanks for letting me know :)


Documentation should include behavior for Diagnostic Settings behavior

Diagnostics Settings are currently orphaned when deleting resources because they are considered extension proxies (and not managed by ARM). So if you delete a parent object, diagnostic settings do not get deleted.  Microsoft recommends deleting these manually - however, if you do this via automation it's prevented by lock on the parent object.
The lock documentation doesn't cover any of the behavior in regards to diagnostic settings - but they do seem to be in effect for this type of resource (as extension proxies).  It would be helpful to cover this kind of scenario in the documentation so customers don't have to figure this out through trial, error, and support cases.

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

ID: 4e7af209-7240-dd2a-7130-e7fb3143986a
Version Independent ID: a653b0d1-877d-09f7-17fa-11bf06c37cc9
Content: Lock resources to prevent changes - Azure Resource Manager
Content Source: articles/azure-resource-manager/management/lock-resources.md
Service: azure-resource-manager
Sub-service: management
GitHub Login: @tfitzmac
Microsoft Alias: tomfitz

Hello @breakpoint7 , Thanks for providing your useful feedback. I understand that the documentation should be more clear and should talk about the above-mentioned scenario. We will look further into this to see how we can improve our documentation, and provide and update.

@breakpoint7 - thanks for this feedback. I have added information about extension resource types inheriting the lock from the resource they are applied to. The update should get published later today.
#please-close


fix license header

Coverage remained the same at 75.198% when pulling 3c0acdd8f70b498045fe17e0e41bdbec955a7f2c on fix-license-header into d9db4acaefc1a7bb52110a05ba89030386c59f99 on master.


Error while installing Typescript using npm

Related Issues:

When I am trying to install typescript using the following command I am getting error
npm -g install typescript@latest.
Thanks in advance

Not clear what we can do - I would check with npm support if it's the case that you're able to install other packages.


Documentation forget to mention req.method

I tried it and it works. It's value is GET, POST ...etc.
http://expressjs.com/en/4x/api.html

Indeed, req.method is even mentioned in a code sample for router.use() (http://expressjs.com/en/4x/api.html#router.use). This seems like an oversight to me.

Thanks for reporting this.
I opened https://github.com/strongloop/expressjs.com/issues/544 to address this.  In general, please open doc issues in the expressjs.com repo, since that's where the docs live.  I'm going to close this issue, and we'll work on the above instead.


Normalize a missing body for raw actions to JsString.empty.

Proposed fix for https://github.com/apache/incubator-openwhisk/issues/3321.
I partially confirmed the reported issue. The code and previous test confirms a missing body is an instance of JsObject, not JsArray. I'm not sure yet where the JsArray comes from; it may be PHP actions specific. A node test shows the type is not an array.
@akrabat FYI for node and python below.

Ohhhh ofcourse. It's an array in PHP because PHP has associative arrays 🤦♂. Good one!

pg3/1912 🔵

Ohhhh ofcourse. It's an array in PHP because PHP has associative arrays 🤦♂. Good one!

To follow up on this so for completeness, PHP's JSON decoder can decode to associative arrays (dictionaries) or to objects (PHP's stdClass). However, PHP's associative array handling is so strong that decoding JSON to associated arrays is more common and so that's what I made PHP Runtime do.
As this came up, I've doubled checked by looking at a few major PHP frameworks and they all decode JSON to associative arrays. I also asked a few PHP developers that I know about what they would expect JSON decoding to look like on the PHP side and they all confirmed that associative arrays is what they would expect rather than stdClass objects.
i.e. we're doing it right for PHP, even though it's not necessarily what other languages would do.

Thanks Rob for the investigation 👍

@akrabat sure, I didn't meant to say that this is the wrong thing to do. I just completely forgot that PHP has this thing so I was wondering how on earth it could become an empty array 😂 No offense at all.

Oh, I wasn't offended :) It wasn't until this came up that I thought about it properly, so wanted to double check I wasn't an outlier in the PHP world on this point!


cookbook item for 'using dat with git to distribute large files'

A simple tutorial and example project on the docs.datproject.org cookbook section that shows how one can use github to distribute small files along with dat to distribute large files.

Now that we support dat.json url, we can get going on this! It'd be great to have a replace git lfs tutorial.
Some example papers + code we could draw from or PR (todo: find more using git lfs):

https://github.com/cpbl/osm-completeness (uses wget)
... more

This is what I think we need for the complete workflow:
Replace git lfs storage
Goal: Publish data to datproject.org/jhand/my-dat and easily clone from inside a git repo.

dat create (in git repo)
commit dat.json to git
dat publish (we'll rehost data for researchers that want to try it)
git push
dat push (push to our host)

Right now we are missing:

dat push
Automatic rehosting for specific users in registry

done


Possibility of using fzf action + shell commands on the --bind flag?

[x] I have read through the manual page (man fzf)
[x] I have the latest version of fzf
[x] I have searched through the existing issues

Info

OS

[x] Linux
[ ] Mac OS X
[ ] Windows
[ ] Etc.

Shell

[x] bash
[ ] zsh
[ ] fish

Problem / Steps to reproduce
I know how to chain/use multiple shell commands on the --bind flag, but i'm wondering if there a way to do this for fzf action + shell command combination too? Example:
echo '' | fzf --bind:"alt-q:abort ; echo 'hello'"
something along that? just curious to know.

yes but as far as I can tell not with the example provided however
 fzf --bind='alt-b:toggle+replace-query+execute(echo '{q}' >> ./somefile)+execute(cat ./somefile)'

works just fine so it really depends on what your goal is (based on the example given you want to print your output to the command line to use again?


HSEARCH-2749 Make sure every SearchIntegrator built in test is closed properly

https://hibernate.atlassian.net//browse/HSEARCH-2749

Jenkins, retest this please

rather extreme :D
but ok, merging..


Mouseover cursor isnt the same as non mouseover anymore

Please give option to change this, it is really annoying to have a different cursor when mouse over, really bad design decision. I just want to change the color not the complete cursor, especially not into a circle one.

youd need to take the original game mouse cursor and modify it yourself and
add it as a custom cursor to YM. its too tricky to automatically change
existing game cursors to some new color.
otherwise im not entirely sure what youre asking :)
On Sun, Jan 24, 2016 at 5:38 AM, makedir<EMAIL_ADDRESS>wrote:

Please give option to change this, it is really annoying to have a
different cursor when mouse over, really bad design decision I just want to
change the color not the complete cursor, especially not into a circle one
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3.

No... you did not understand. Since I updated to 0.6.1beta you changed the mouseover cursor to always being the round annoying way too big circle. Before 0.6.1 the default behavior was pink/blue: http://i.imgur.com/jqNOQmK.png => http://i.imgur.com/g9MUxBq.png or vice versa, switching the color when mouseover. Now it switches from: http://i.imgur.com/g9MUxBq.png to http://i.imgur.com/ODGdYmI.png . Please give an option to change this behavior back.

oh that, the new behavior is hitting "ctrl alt shift 1" repeatedly cycles
through 10 different arrow cursors, "ctrl alt shift 2" cycles through the
circles, etc. this was a necessary change to handle way more cursors.
On Mon, Jan 25, 2016 at 3:48 AM, makedir<EMAIL_ADDRESS>wrote:

No... you did not understand. Since I updated to 0.6.1beta you changed the
mouseover cursor to always being the round annoying way too big circle.
Before 0.6.1 the default behavior was pink/blue:
http://i.imgur.com/jqNOQmK.png => http://i.imgur.com/g9MUxBq.png or vice
versa, switching the color when mouseover. Now it switches from:
http://i.imgur.com/g9MUxBq.png to http://i.imgur.com/ODGdYmI.png . Please
give an option to change this behavior back.
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3#issuecomment-174482848.

What? No... O_0 you still didnt get it. IT IS ALWAYS A CIRCLE WHEN MOUSEOVER, this is terrible. Please change it back or give option to change it. It wasnt before 0.6.1. that way. I want the cursor to change colors not change always into a circle.

yes, just use CTRL ALT SHIFT 1 multiple times for all different arrow
cursors.... 2 is for circles 3 is for cross
you may have to change existing cursors when upgrading, including mouseover.
it has to be this way to handle many cursors, you can still download old
version.
On Mon, Jan 25, 2016 at 3:23 PM, makedir<EMAIL_ADDRESS>wrote:

What? No... O_0 you still didnt get it. IT IS ALWAYS A CIRCLE WHEN
MOUSEOVER, this is terrible. Please change it back or give option to change
it. It wasnt before 0.6.1. that way. I want the cursor to change colors not
change always into a circle.
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3#issuecomment-174727747.

DUDE. Are you serious??

Dont you understand, do I need to record a video with my phone dammit??
 Did you understand now the two issues?

here was reply....

theres no concept of mouseover in YM. its just whatever cursor you see you
change with hotkey.
maybe you should specify the game youre talking about. some games, like d3,
change the mouseover cursor to something else while you hold down SHIFT or
ALT preventing YM from changing the intended cursor.
On Tue, Feb 2, 2016 at 8:45 AM, makedir<EMAIL_ADDRESS>wrote:

Respond please? Did you understand now the two issues?
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3#issuecomment-178681884.

https://dl.dropboxusercontent.com/u/14937594/yolo.mp4

if you cant reassign that mouseover cursor (using YM hotkeys) i think itd
easiest for you to just delete the ...diablo3... file in
C:\Users...\AppData\Local\YoloMouse\
then restart yolomouse and d3. this will clear all assigned cursors and let
you reassign everything.
On Wed, Feb 3, 2016 at 5:01 PM, makedir<EMAIL_ADDRESS>wrote:

https://dl.dropboxusercontent.com/u/14937594/yolo.mp4
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3#issuecomment-179557915.

Could you for a moment please stop being so ignorant, I know it is hard as a developer and maker of a program, I tend to do it myself and listen to me maybe for one second.
 Look at the damn video.

regardless of the assigned MAIN cursor, whenever you mouseover over a monster in Diablo 3, YoloMouse changes the cursor to a CIRCLE, ALWAYS A CIRCLE.

the ALWAYS CIRCLE IS ALWAYS THE SAME SIZE, hotkey size is IGNORED FOR THE MOUSEOVER CURSOR.

if hotkeys dont change mouseover cursor then its a bug. but its working for
everyone else so its probably specific to your setup. clearing old settings
and redoing it should clear it as stated in last email.
On Wed, Feb 3, 2016 at 5:47 PM, makedir<EMAIL_ADDRESS>wrote:

Could you for a moment please stop being so ignorant, I know it is hard as
a developer and maker of a program, I tend to do it myself and listen to me
maybe for one second.
 Look at the damn video.

regardless of the assigned MAIN cursor, whenever you mouseover over a
monster in Diablo 3, YoloMouse changes the cursor to a CIRCLE, ALWAYS A
CIRCLE.
2.
the ALWAYS CIRCLE IS ALWAYS THE SAME SIZE, hotkey size is IGNORED FOR
THE MOUSEOVER CURSOR.
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3#issuecomment-179568992.

... How do I deactivate all hotkeys, it seems there is no option for this in the ini file. There need to be some setting like allhotkeysoff.

theres no point to this, just delete the diablo3 ini file and restart d3/ym
On Thu, Feb 4, 2016 at 6:23 AM, makedir<EMAIL_ADDRESS>wrote:

... How do I deactivate all hotkeys, it seems there is no option for this
in the ini file. There need to be some setting like allhotkeysoff.
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3#issuecomment-179867014.

I am not asking without a reason. Could you just answer to my damn questions, yes. If I ask something there is a reason for. Please give an option to disable any hotkeys or give a hotkey to toggle them on/off.

you can just remove hotkey bindings in settings.ini effectively disabling
them
On Thu, Feb 4, 2016 at 2:07 PM, makedir<EMAIL_ADDRESS>wrote:

I am not asking without a reason. Could you just answer to my damn
questions, yes. If I ask something there is a reason for. Please give an
option to disable any hotkeys or give a hotkey to toggle them on/off.
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3#issuecomment-180072914.

So if I change them to
CursorKey2=
it will already work / disable them?

yes, but theres little reason to do this
On Thu, Feb 4, 2016 at 3:07 PM, makedir<EMAIL_ADDRESS>wrote:

So if I change them to
CursorKey2=
it will already work / disable them?
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3#issuecomment-180095870.

Yes there is big reason to do that. I know from a developers point of view there is "always no reason" or "always a reason" to do something or to not give any options/settings at all. I am a developer myself and I know how hard it is to step away from something you created and look at it from a users point of view, or from a objective point of view.  Developers tend to change something they think is a total improvement whre it is not and worse, never give any simple options to turn those changes off or back.

well im just saying disabling hotkeys doesnt really change anything, but
the option does exist by editing settings.ini. i may make a more friendly
UI for this later though.
hopefully wiping the d3 ini fixed your problem of the stuck circle binding.
On Thu, Feb 4, 2016 at 3:51 PM, makedir<EMAIL_ADDRESS>wrote:

Yes there is big reason to do that. I know from a developers point of view
there is "always no reason" or "always a reason" to do something or to not
give any options/settings at all. I am a developer myself and I know how
hard it is to step away from something you created and look at it from a
users point of view, or from a objective point of view.  Developers tend to change something they think is
a total improvement whre it is not and worse, never give any simple options
to turn those changes off or back.
—
Reply to this email directly or view it on GitHub
https://github.com/PandaTeemo/YoloMouse/issues/3#issuecomment-180108971.


feat:  support giscus

Adapted to the giscus comment system, beacuse the current comment (gitalk, utterances) system has been inactive.

Hi，is anybody deal with it？

😂 nobody


Align Search Bar

Search Bar needs to align in the center of the page underneath header text
-Also need to ensure the search bar fits correctly on a mobile version of the app

Search Bar now aligned underneath the "Find Food Near You" text and cascades in a mobile format


"Giurgița" "Curmătura" "Filaret" are listed in the drop-down menu

Description:
When user writes "Giurgița" "Curmătura" "Filaret" the locations appear in the drop-down menu next to the comune and the county which is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Giurgița"

Expected results
The location appears in the drop-down menu as "Sat Giurgița, DOLJ (Giurgița)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Filaret"

Expected results
The location appears in the drop-down menu as "Sat Filaret, DOLJ (Giurgița)".


Fix startup on macOS

The "Wi-FI", "Ethernet" and "en1" interfaces don't exist on macOS, at least not on my side on macOS Ventura 13.4.1.

This returns an error every time the application is started.

This PR corrects this problem by also supporting "en0", which returns the local IP of the computer on the local network.

Thank you!


master->conway-era align

Context
Just keeping things in sync
Proposed Solution
Important Changes Introduced

wrong merge direction


csc_matmat_pass1 and pass2 and csc_matvec are slow, appear not to use MKL/threading.

My code solves a sparse matrix equation using sparse lgmres. A pre-conditioner is computed for this purpose. Matrices are in csc format. Profiling code shows that matrix-matrix and matrix-vector multiplication takes a significant time, much more so than one would expect as compared to solving the matrix equation, especially given the use of MKL and the potential for threading the matmat and matvec operations. Matrices are ~ 100,000 x 100,000.
The isolated code in GetResidualAndJacobian() below, shows a cumulative time of 33 seconds. Contributions are from the csc_matvec, csc_matmat_pass1 and csc_matmat_pass2. This is roughly the same time as the factorization step for the pre-conditioner and double the time of the lgmres solve. From what I can see, these matmat and matvec methods are implemented in c++ and are not threaded.
This is an enhancement request to take advantage of multi-core processors for these operations, potentially by directly using MKL and OpenBlas library routines.

         6443555 function calls (6442384 primitive calls) in 130.136 seconds

   Ordered by: internal time
   List reduced from 1262 to 50 due to restriction <50>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)

       30    0.842    0.028   32.847    1.095 matrixeqn.py:1204(GetResidualAndJacobian)
       64   29.197    0.456   29.197    0.456 {built-in method scipy.sparse.linalg.dsolve._superlu.gstrf}
       30    0.447    0.015   28.618    0.954 matrixeqn.py:1243(SetPreconditioner)
      175   19.659    0.112   19.659    0.112 {built-in method scipy.sparse._sparsetools.csc_matmat_pass2}
       30    0.211    0.007   14.785    0.493 lgmres.py:18(lgmres)
      858    8.201    0.010    8.201    0.010 {built-in method scipy.sparse._sparsetools.csc_matvec}
      238    7.834    0.033    7.834    0.033 {method 'solve' of 'SuperLU' objects}
      175    5.460    0.031    5.460    0.031 {built-in method scipy.sparse._sparsetools.csc_matmat_pass1}

Code example:
def GetResidualAndJacobian(self):

    F = self.GN * (self.N * self.x - self.constRHS - self.nonLinRHS) - self.ON * self.A * self.X
    dF = self.GN * self.dF * self.GNm1 - self.ON * self.A

    return F, dF

Scipy/Numpy/Python version information:

spicy 1.1.0
numpy 1.14.3
python 3.6.4
mkl 2018.3.22 linux, 2018.3.185 OSX

No response

I looked into this further, using MKL's inspector-executor routines.

Thanks for the benchmarks with MKL!

I get 3x speed up for my (150k*150k) matrices, which appears to be achieved by vectorization over multiple cores (looking at the cpu monitor) and perhaps more Intel low-level tricks.

Multithreading these functions in scipy with OpenMP would likely be challenging if only because of packaging concerns https://github.com/scipy/scipy/issues/10239
I wonder if there is a way improve singe core performance, for sparse matrix multiplication, say by improving CPU cache locality in the implementation etc. More benchmarks with OSS sparse libraries would be useful. For instance, maybe eigen or sprs (a more detailed list here).

@chrisgmorton Thanks for your awesome solution.
I was using the simple way of wrapping the Sparse BLAS MKL routines in Python (the one by Intel here) until I ran into issue of defining the foreign data type sparse_matrix_t. Do you know if there's any simpler way that allow me to introduce sparse_matrix_t in Python so that I could continue to use the method in the link above?

Learned a lot from this repo regarding my question above


Add David Greenwald to Contributors list

Thanks for doing this!

@davidegreenwald, I'm quite elated about your pull request. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a pull request and learned that I merged it?
We’ve recently added Facebook share and tweet feature to our web app. Could you please go to https://roshanjossey.github.io/first-contributions/#social-share and share your first contribution to open source?
Also, check out projects with easy issues while you’re there.


"Find in selection" changes scroll location after performing a string replace

After using the 'replace all' option with the 'Find in selection' option toggled on, then clearing the 'Find in selection' option by toggling off, the page scrolls to a different random selection.  It would be ideal if the page position did not change.
Version: 1.35.1 (system setup)
Commit: c7d83e57cd18f18026a8162d042843bda1bcf21f
Date: 2019-06-12T14:30:02.622Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

@kuhlaid can you share a gif or screen recording to help understand what's going on?

The behavior seems to be if there are other occurrences of the 'find' string outside of the 'find in selection' block then toggling the 'Find in selection' option will move the page scroll to another occurrence of the 'find' string (whether you perform a replace or not).
Replace.pptx

The find widget always automatically researches what's in the find input box when either the document changes or the search range changes. To disallow the automatic search (and also position revealing), you can disable editor.find.cursorMoveOnType.


Socket disconnects 30 seconds after connecting

Hello!
This package does exactly what I need, however, it disconnects after 30 seconds, even though the server received it's connection. The event that the server sends back is very hit or miss, sometimes it works, sometimes it doesn't. Also, I have no clue how the error events work and if there are any parameter's, so I can't really debug.
Here's my client code (c#):

And here's my server code (Node):

Here's the log:
2020-10-21 14:36:10 100 [1] -:#0 - ignoring socket cache for http://domain.com:63053/
2020-10-21 14:36:10 102 [1] -:#0 - Init Manager: http://domain.com:63053/
2020-10-21 14:36:10 104 [1] -:#0 - readyState CLOSED
2020-10-21 14:36:10 104 [1] -:#0 - opening http://domain.com:63053/
2020-10-21 14:36:10 117 [1] -:#0 - SetTransport setting transport 'polling'
2020-10-21 14:36:10 117 [150] -:#0 - Task.Run Open start
2020-10-21 14:36:10 118 [150] -:#0 - xhr DoPoll
2020-10-21 14:36:10 121 [150] -:#0 - xhr open GET: http://domain.com:63053/socket.io/?EIO=3&transport=polling&t=637388877701192200-0&b64=1
2020-10-21 14:36:10 122 [139] -:#0 - Task.Run Create start
2020-10-21 14:36:10 152 [139] -:#0 - Xhr.GetResponse
2020-10-21 14:36:10 156 [139] -:#0 - OnData string = 96:0{"sid":"T5tRCN0GDOEQL33BAAAF","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":5000}2:40
2020-10-21 14:36:10 157 [139] -:#0 - polling got data 96:0{"sid":"T5tRCN0GDOEQL33BAAAF","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":5000}2:40
2020-10-21 14:36:10 164 [139] -:#0 - Writable: True sid=
2020-10-21 14:36:10 165 [139] -:#0 - socket received: type 'open', data '{"sid":"T5tRCN0GDOEQL33BAAAF","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":5000}'
2020-10-21 14:36:10 185 [139] -:#0 - OnHandshake
2020-10-21 14:36:10 188 [139] -:#0 - ReadyState=OPEN Transport.Writeable=True Upgrading=False WriteBuffer.Count=0
2020-10-21 14:36:10 188 [139] -:#0 - Flush Not Send
2020-10-21 14:36:10 189 [139] -:#0 - open
2020-10-21 14:36:10 191 [139] -:#0 - OnOpen starting upgrade probes
2020-10-21 14:36:10 192 [139] -:#0 - Probe probing transport 'websocket'
2020-10-21 14:36:10 195 [139] -:#0 - DoOpen uri =ws://domain.com:63053/socket.io/?EIO=3&transport=websocket&sid=T5tRCN0GDOEQL33BAAAF&t=637388877701956110-1
2020-10-21 14:36:10 204 [139] -:#0 - socket received: type 'message', data '0'
2020-10-21 14:36:10 205 [139] -:#0 - decoded 0 as Type:0 Id:-1 Nsp:/ Data: Attachments:0
2020-10-21 14:36:10 215 [139] -:#0 - writing packet Type:2 Id:-1 Nsp:/ Data:[
  "link",
  "213a186c-b716-4189-bd64-057c903dcd49"
] Attachments:0
2020-10-21 14:36:10 215 [139] -:#0 - encoding packet Type:2 Id:-1 Nsp:/ Data:[
  "link",
  "213a186c-b716-4189-bd64-057c903dcd49"
] Attachments:0
2020-10-21 14:36:10 215 [139] -:#0 - encoded Type:2 Id:-1 Nsp:/ Data:[
  "link",
  "213a186c-b716-4189-bd64-057c903dcd49"
] Attachments:0 as 2[
  "link",
  "213a186c-b716-4189-bd64-057c903dcd49"
]
2020-10-21 14:36:10 216 [139] -:#0 - ReadyState=OPEN Transport.Writeable=True Upgrading=False WriteBuffer.Count=1
2020-10-21 14:36:10 216 [139] -:#0 - Flush 1 packets in socket
2020-10-21 14:36:10 216 [139] -:#0 - Send called with packets.Count: 1
2020-10-21 14:36:10 216 [139] -:#0 - Write packets.Count = 1
2020-10-21 14:36:10 216 [139] -:#0 - Writable: False sid=T5tRCN0GDOEQL33BAAAF
2020-10-21 14:36:10 222 [139] -:#0 - DoWrite data = System.Byte[]
2020-10-21 14:36:10 222 [139] -:#0 - xhr open POST: http://domain.com:63053/socket.io/?EIO=3&transport=polling&sid=T5tRCN0GDOEQL33BAAAF&t=637388877702224860-3&b64=1
2020-10-21 14:36:10 229 [154] -:#0 - Task.Run Create start
2020-10-21 14:36:10 254 [154] -:#0 - Xhr.GetResponse
2020-10-21 14:36:10 255 [154] -:#0 - OnData string = ok
2020-10-21 14:36:10 255 [155] -:#0 - ws_Opened True
2020-10-21 14:36:10 255 [155] -:#0 - Writable: True sid=T5tRCN0GDOEQL33BAAAF
2020-10-21 14:36:10 255 [154] -:#0 - Writable: True sid=T5tRCN0GDOEQL33BAAAF
2020-10-21 14:36:10 256 [155] -:#0 - Send called with packets.Count: 1
2020-10-21 14:36:10 257 [155] -:#0 - Writable: False sid=T5tRCN0GDOEQL33BAAAF
2020-10-21 14:36:10 257 [154] -:#0 - Task.Run Create finish
2020-10-21 14:36:10 258 [139] -:#0 - ReadyState != ReadyStateEnum.CLOSED
2020-10-21 14:36:10 258 [139] -:#0 - xhr DoPoll
2020-10-21 14:36:10 258 [155] -:#0 - Writable: True sid=T5tRCN0GDOEQL33BAAAF
2020-10-21 14:36:10 258 [139] -:#0 - xhr open GET: http://domain.com:63053/socket.io/?EIO=3&transport=polling&sid=T5tRCN0GDOEQL33BAAAF&t=637388877702583480-4&b64=1
2020-10-21 14:36:10 258 [118] -:#0 - Task.Run Create start
2020-10-21 14:36:10 273 [119] -:#0 - ws_MessageReceived e.Message= 3probe
2020-10-21 14:36:10 280 [118] -:#0 - Xhr.GetResponse
2020-10-21 14:36:10 280 [118] -:#0 - OnData string = 11:42["start"]
2020-10-21 14:36:10 280 [118] -:#0 - polling got data 11:42["start"]
2020-10-21 14:36:10 280 [118] -:#0 - socket received: type 'message', data '2["start"]'
2020-10-21 14:36:10 280 [118] -:#0 - decoded 2["start"] as Type:2 Id:-1 Nsp:/ Data:["start"] Attachments:0
2020-10-21 14:36:10 281 [118] -:#0 - emitting event System.Collections.Generic.List`1[System.Object]
2020-10-21 14:36:20 329 [119] -:#0 - ws_Closed
2020-10-21 14:36:20 330 [119] -:#0 - Transport.OnClose()
2020-10-21 14:36:20 331 [119] -:#0 - probe transport "websocket" failed because of error: transport closed
2020-10-21 14:36:35 207 [149] -:#0 - writing ping packet - expecting pong within 5000ms, ReadyState = OPEN
2020-10-21 14:36:35 209 [149] -:#0 - ReadyState=OPEN Transport.Writeable=True Upgrading=True WriteBuffer.Count=1
2020-10-21 14:36:35 209 [149] -:#0 - Flush Not Send
2020-10-21 14:36:40 212 [149] -:#0 - EasyTimer OnHeartbeat start
2020-10-21 14:36:40 214 [149] -:#0 - OnClose socket close with reason: ping timeout
2020-10-21 14:36:40 215 [149] -:#0 - Socket.ReadyState = CLOSE
2020-10-21 14:36:40 216 [149] -:#0 - start
2020-10-21 14:36:40 217 [149] -:#0 - close (ping timeout)

Also, I'm using Unity 2020.1.4f1 and Node 14.9.0

It's been a month, it looked promising but I shall move on and find another package or make my own.

managed to find any other, friend?

Yeah I did, I used https://github.com/doghappy/socket.io-client-csharp.


Fix default installation paths on mingw [1.1.0]

[This is a port of #9400 to 1.1.0]
Mingw config targets assumed that resulting programs and libraries are
installed in a Unix-like environment and the default installation
prefix was therefore set to '/usr/local'.
However, mingw programs are installed in a Windows environment, and
the installation directories should therefore have Windows defaults,
i.e. the same kind of defaults as the VC config targets.
A difficulty is, however, that a "cross compiled" build can't figure
out the system defaults from environment the same way it's done when
building "natively", so we have to fall back to hard coded defaults in
that case.
Tests can still be performed when cross compiled on a non-Windows
platform, since all tests only depend on the source and build
directory, and otherwise relies on normal local paths.
CVE-2019-1552

Merged.
e32bc855a81a2d48d215c506bdeb4f598045f7e9 Fix default installation paths on mingw


OSError: [Errno 19] ENODEV on WeMos D1 Mini

Thanks for the library! I'm going to use to to upgrade an old RC car with an ESP8266 and use this as the controller.
I am getting consistent OSError: [Errno 19] ENODEV errors when I use your library with MicroPython v1.8.6-172 on a WeMos D1 Mini v2.1.0
>>> from machine import Pin, I2C
>>> import time
>>> import nunchuck
>>> i2c = I2C(scl=Pin(5),sda=Pin(4),freq=100000)
>>> i2c.scan()
[82]
>>> nun = nunchuck.Nunchuck(i2c)
>>> print(nun.joystick_x(), nun.joystick_y())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "nunchuck.py", line 103, in joystick_y
  File "nunchuck.py", line 47, in __poll
  File "nunchuck.py", line 42, in update
OSError: [Errno 19] ENODEV

In def update(self):, I added a small delay, and now it's working reliably for me now.
def update(self):
    self.i2c.writeto(self.address, b'\x00')
    time.sleep_us(10)
    self.i2c.readfrom_into(self.address, self.buffer)

time.sleep_us(3) OSError 19s after 2-10 calls.
time.sleep_us(5) OSError 19s after 10-50 calls.
time.sleep_us(10) works consistently.

I am using one of these little Wiichuck adapters:

https://littlebirdelectronics.com.au/products/wiichuck-adapter

TBH i have not yet had time to test this on my ESPs.
Thanks for this report and possible solution. 10 µs should not really harm in any way with I2C communication. i will try to dig for the dependency for your delay in the datasheet of the Nunchuck chip.
We hopefully will find a report including photos of your project on the µPy forum!?

Tested on two of my WeMos D1 Minis, V2 and V2.1.0 boards, also upgraded to MicroPython v1.8.6-183-ge8f2db7
I forgot the Nunchuk had an accelerometer. Win!
I'll be sure to document the build on the forum and share the code on my GitHub.

Tested this code on an ESP-12E, and found out it was working only intermittently. Sometimes I could get readings, sometimes couldn't, and nunchuck_test was totally unusable. Then, I switched the I2C-bus to other pins than 4 and 5, and it worked like a charm! Pins 4 & 5 seem to be ok otherwise, haven't shown them to my scope yet...
Anyway, thank you fo the code!

ESP-01 running MicroPython v1.9.4, also had the 'OSError: [Errno 19] ENODEV' bug. I tried sleep_us values of 10 and 20 with no success. 50 makes it work, but I'm sure I can find a smaller number.


nginx module

Contributing an nginx OpenTelemetry module. For usage refer to README.md.
Supported features:

Exporter: OTLP
Propagation: W3C, b3
Modules: http, fastcgi

Platforms: Linux with nginx 1.18 (need to add tests for more versions)
I would like to get CI working in this contrib repository as well - at the moment I just copied the CI files here, but I guess they have to live in the repo root?
I'd like to keep working on and maintain the module, adding additional platform support, configuration options, and so on. How can we make this happen? Would it be a PR against this repo from a fork each time?
Ideas for changes welcome! :slightly_smiling_face:

I would like to get CI working in this contrib repository as well - at the moment I just copied the CI files here, but I guess they have to live in the repo root?

I think it should be fine to keep component level CI scripts inside their specific folders ( instead of root of repo ), and the workflow jobs referring them from within that.

I'd like to keep working on and maintain the module, adding additional platform support, configuration options, and so on. How can we make this happen? Would it be a PR against this repo from a fork each time?

My initial thoughts are to have codeowners based approach, with codeowners for each of the components responsible for approval/merger, and the current repo approvers / maintainers been added in PR to facilitate the process. At the same time it shouldn't add to extra delay in merges. Would like to hear other views ( @open-telemetry/cpp-approvers  @open-telemetry/cpp-maintainers  ) and we can further discuss in our community meeting to finalize the approach.

I would like to get CI working in this contrib repository as well - at the moment I just copied the CI files here, but I guess they have to live in the repo root?

I think it should be fine to keep component level CI scripts inside their specific folders ( instead of root of repo ), and the workflow jobs referring them from within that.

I'd like to keep working on and maintain the module, adding additional platform support, configuration options, and so on. How can we make this happen? Would it be a PR against this repo from a fork each time?

My initial thoughts are to have codeowners based approach, with codeowners for each of the components responsible for approval/merger, and the current repo approvers / maintainers been added in PR to facilitate the process. At the same time it shouldn't add to extra delay in merges. Would like to hear other views ( @open-telemetry/cpp-approvers @open-telemetry/cpp-maintainers ) and we can further discuss in our community meeting to finalize the approach.

As for CI I put the workflow file into the root dir .github/workflows/nginx.yml which references the CI scripts inside the nginx subdirectory - should be quite clutter free like this.
To get this reviewed and approved, is there anyone I can ping? Thanks :slightly_smiling_face:

To get this reviewed and approved, is there anyone I can ping? Thanks 🙂

I would like to get it approved after adding you ( and other you would like to add ) as CODEOWNERS. Was actually waiting for this week SIG community meeting to finalize the approach, as this would be then valid for all future components added in contrib repo. Sorry for long wait for this PR, this should have been decided last week had there been SIG meeting.

To get this reviewed and approved, is there anyone I can ping? Thanks slightly_smiling_face

I would like to get it approved after adding you ( and other you would like to add ) as CODEOWNERS. Was actually waiting for this week SIG community meeting to finalize the approach, as this would be then valid for all future components added in contrib repo. Sorry for long wait for this PR, this should have been decided last week had there been SIG meeting.

Sure, no problem. I'll try to join this week as well.

FYI I don't have the rights to merge once approved.

FYI I don't have the rights to merge once approved.

I will merge the PR for now. Going forward, we need to have different maintainers and approvers for this repo, as I know not all approvers/maintainers for opentelemetry-cpp will like to own same role for contrib repo. Let me check on our slack channel for volunteers.
Also, had some concern with "MIT License" and non-opentelemery copyright code going in CNCF managed repo ( as here but I think that should be fine as clarified in below CNCF link:
https://github.com/cncf/foundation/blob/master/copyright-notices.md#what-about-third-party-code
If a file only contains code that originates from a third party source who didn't contribute it themselves, then you would not want to add the notices above. (In a similar vein, you wouldn't add a notice identifying you as the copyright holder either, if you didn't own it.) Just preserve the existing copyright and license notices as they are.


Issue with image alignment

I've been playing around with your theme and it's overall really nice, just having a couple of problems:

When I insert an image I can't seem to override the default alignment (center), and there are times that I want to insert in-line images. This includes when I insert an image into a header line. I've tried using style="!important in HTML image tags, rather than Markdown, to no avail.
I cannot seem to override the favicon, even though as far as I can tell I'm putting the favicon set I made in the correct directory and even have one just named favicon.ico...?

Hi @quintessence, thank you for your interest in this theme and I'm sorry for the late reply, here are some things you can try:

To avoid using !important simply use a more specific CSS selector, like this:

<style type="text/css">
  .content .post .post-content img {
    display: inline;
    padding: 0;
    left: 0;
    -webkit-transform: none;
    transform: none;
  }
</style>

You can try adding the above code to your post's code injection section:

That will produce the following result:
Before:

After:

This will work with markup, and you can also add inline images to headings:
Before:

After:

To update your favicon in Ghost 1.0 and later you can simply go to your admin panel >Settings > General, and you'll see the option to do this in the "Publication identity" section:

In previous versions of Ghost each theme could override the favicon but now the only option seems to be uploading it using this interface.
Please let me know if it helped, cheers!

Ah I didn't realize they moved the favicon to be in the UI only. That explains so much. Thank you! Also, the CSS code injection worked :) Again, greatly appreciate :)

Awesome!


Update SigninAttemptsByIPviaDisabledAccounts.yaml

Added Account entityType.
-JH
Required items, please complete
Change(s):

See guidance below

Reason for Change(s):

See guidance below

Version Updated:

Required only for Detections/Analytic Rule templates
See guidance below

Testing Completed:

See guidance below

Checked that the validations are passing and have addressed any issues that are present:

See guidance below

Guidance <- remove section before submitting

Before submitting this PR please ensure that you have read the following sections and filled out the changes, reason for change and testing complete sections:
Thank you for your contribution to the Microsoft Sentinel Github repo.

Details of the code changes in your submitted PR.  Providing descriptions for pull requests ensures there is context to changes being made and greatly enhances the code review process.  Providing associated Issues that this resolves also easily connects the reason.

Change(s):

Updated syntax for XYZ.yaml

Reason for Change(s):

New schema used for XYZ.yaml
Resolves ISSUE #1234

Version updated:

Yes
Detections/Analytic Rule templates are required to have the version updated

The code should have been tested in a Microsoft Sentinel environment that does not have any custom parsers, functions or tables, so that you validate no incorrect syntax and execution functions properly.  If your submission requires a custom parser or function, it must be submitted with the PR.

Testing Completed:

Yes/No/Need Help

Note: If updating a detection, you must update the version field.

Before the submission has been made, please look at running the KQL and Yaml Validation Checks locally.
https://github.com/Azure/Azure-Sentinel#run-kql-validation-locally

Checked that the validations are passing and have addressed any issues that are present:

Yes/No/Need Help

Note: Let us know if you have tried fixing the validation error and need help.

References:

Guidance for Detection checks
General contribution guidance
PR validation troubleshooting

The entity mapping engine expects a unique value. IT seems like disabledAccountSet might have multiple values in it and hence adding these in entity mapping as is might not be the best approach.


Missing Debian/Ubuntu dependency

Hi there. This plugin won't work on Debian/Ubuntu based systems without xclip, which is not installed by default. So pleased add this to the readme file. Thanks for your great plugin. 👍

Thank you too!
This is already documented in the README, under the "Optional dependencies" section.
I assume you just installed the plugin and tried to use it. I suppose I should add some sort of notification or error message if no adapter could be found.
Did I understand the problem correctly?

You're right. But I only looked at this part, where the xclip dependency is missing:
Compile from source

rofi-emoji uses autotools as build system. On Debian/Ubuntu based systems you will need to install the packages first:

    rofi-dev
    autoconf
    automake
    libtool-bin
    libtool

Download the source and run the following to install it:

autoreconf -i
mkdir build
cd build/
../configure
make
sudo make install

Yeah, xclip isn't a build dependency and it's optional, so it's not under that section.
Did you get a visible error message when you tried the tool for the first time, or did it silenty fail?
Thank you.

No I got the clipboard error. But it didn't mention xclip. I just figured it was xclip, and I was right.

Added a reminder in 78a98f28c69c69ec3bfc08392290e96b9d19e03c.


cmakelists

should be
install(PROGRAMS
  scripts/pick_place_tutorial.py
  DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}

@zhangyiian Thanks for letting me know. 😄 Feel free to create a PR, and I will merge it into the main branch.

@zhangyiian I just fixes this in https://github.com/rickstaa/moveit-tutorials-python-examples/releases/tag/v1.0.5.


CDK Toolkit bucket URL is wrong for large template files

When a stack getting big, the cloudformation template gets deployed to cdk toolkit bucket and then the url used for cloudformation. AWS-CDK-local does not work under this circumstance, as the bucket URL is not constructed correctly.
Previously that was addressed by the following piece of code
Object.defineProperty(ToolkitInfo.prototype, 'bucketUrl', {
  get() {
    const bucket = this.requireOutput(BUCKET_NAME_OUTPUT);
    const domain = this.requireOutput(BUCKET_DOMAIN_NAME_OUTPUT) || getLocalHost();
    return `https://${domain.replace(`${bucket}.`, '')}/${bucket}`
  }
});

But the newer version of CDK has changed the implementation of "ToolkitInfo" class to be an abstract class which has been implemented by "ExistingToolkitInfo". see
Unfortunately "ExistingToolkitInfo" is not a exported class and it is not accessible to be overriden like the above example.
Another issue is the bucketUrl should include the port number (4566) for it to work.

Thanks for reporting @AminFazlMondo - do you think you can share a small example that helps us replicate this issue?
Taking a first look at the implementation, it seems that we may be able to patch ToolkitInfo.lookup and ToolkitInfo.fromStack which are each returning an instance of ExistingToolkitInfo.
Do you think you could help out with an initial PR to patch this functionality - that would be highly appreciated! Thanks for your help.