Weird dependency error

Some time ago I start getting the error on initial import of the StatisticalRethinking. It happens only if Turing is imported first:
using Turing
using StatisticalRethinking

The error message is
┌ Warning: Error requiring `MCMCChains` from `StatisticalRethinking`
│   exception = (ErrorException("cannot assign a value to variable MCMCChains.MCMCChains from module StatisticalRethinking"), Union{Ptr{Nothing}, Base.InterpreterIP}[Ptr{Nothing} @0x00007fa4d6c81a7f, Ptr{Nothing} @0x00007fa4d6d101df, Ptr{Nothing} @0x00007fa4d6d31b3d, Ptr{Nothing} @0x00007fa4d6d14968, Ptr{Nothing} @0x00007fa4d6d15297, Base.InterpreterIP in top-level CodeInfo for StatisticalRethinking at statement 0, Ptr{Nothing} @0x00007fa4d6d30b31, Ptr{Nothing} @0x00007fa4d6d32949, Ptr{Nothing} @0x00007fa48e9a7f01, Ptr{Nothing} @0x00007fa48e9a7f2c, Ptr{Nothing} @0x00007fa4d6cf7769, Ptr{Nothing} @0x00007fa4d6d13f15, Ptr{Nothing} @0x00007fa4d6d13bce, Ptr{Nothing} @0x00007fa4d6d14811, Ptr{Nothing} @0x00007fa4d6d14b90, Ptr{Nothing} @0x00007fa4d6d1504a, Base.InterpreterIP in MethodInstance for err(::Any, ::Module, ::String) at statement 2, Ptr{Nothing} @0x00007fa48e9a7e77, Ptr{Nothing} @0x00007fa48e9a7e8c, Ptr{Nothing} @0x00007fa4d6cf7769, Ptr{Nothing} @0x00007fa4d6d13f15, Ptr{Nothing} @0x00007fa4d6d13bce, Ptr{Nothing} @0x00007fa4d6d148a5, Ptr{Nothing} @0x00007fa4d6d14b90, Ptr{Nothing} @0x00007fa4d6d1504a, Base.InterpreterIP in MethodInstance for withpath(::Any, ::String) at statement 10, Ptr{Nothing} @0x00007fa48e9a7df3, Ptr{Nothing} @0x00007fa48e9a7e1c, Ptr{Nothing} @0x00007fa4d6cf7769, Ptr{Nothing} @0x00007fa4d6d13f15, Ptr{Nothing} @0x00007fa4d6d13bce, Ptr{Nothing} @0x00007fa4d6d14811, Ptr{Nothing} @0x00007fa4d6d1504a, Base.InterpreterIP in MethodInstance for listenpkg(::Any, ::Base.PkgId) at statement 3, Ptr{Nothing} @0x00007fa48e9a7475, Ptr{Nothing} @0x00007fa48e9a75fc, Ptr{Nothing} @0x00007fa4d6cf7769, Ptr{Nothing} @0x00007fa4d6d304b5, Ptr{Nothing} @0x00007fa4d6d2617c, Ptr{Nothing} @0x00007fa499a24389, Ptr{Nothing} @0x00007fa499aaf62f, Ptr{Nothing} @0x00007fa499ab18a0, Ptr{Nothing} @0x00007fa499ab3c1d, Ptr{Nothing} @0x00007fa499ac3cec, Ptr{Nothing} @0x00007fa4d6cf7769, Ptr{Nothing} @0x00007fa4d6d2fcd1, Ptr{Nothing} @0x00007fa4d6d31d97, Ptr{Nothing} @0x00007fa4d6d30d7c, Ptr{Nothing} @0x00007fa4d6d32949, Ptr{Nothing} @0x00007fa499a9faec, Ptr{Nothing} @0x00007fa499a9fe89, Ptr{Nothing} @0x00007fa4d6cf7769, Ptr{Nothing} @0x00007fa499a9c9e3, Ptr{Nothing} @0x00007fa4d6cf7769, Ptr{Nothing} @0x00007fa4d6d08546, Ptr{Nothing} @0x00007fa499a6c7ee, Ptr{Nothing} @0x00007fa499a6ca1e, Ptr{Nothing} @0x00007fa499a6ca3c, Ptr{Nothing} @0x00007fa4d6cf7769, Ptr{Nothing} @0x00007fa4d6d18c9a, Ptr{Nothing} @0x0000000000000000])
└ @ Requires /home/shmuma/.julia/packages/Requires/7Ncym/src/require.jl:49

This appears only on initial import, if I restart the cell, it works without warnings and works properly.
If I add Optim import, the message changes:
using Optim
using Turing
using StatisticalRethinking

┌ Warning: Package StatisticalRethinking does not have Optim in its dependencies:
│ - If you have StatisticalRethinking checked out for development and have
│   added Optim as a dependency but haven't updated your primary
│   environment's manifest file, try `Pkg.resolve()`.
│ - Otherwise you may need to report an issue with StatisticalRethinking
│ Loading Optim into StatisticalRethinking from project dependency, future warnings for StatisticalRethinking are suppressed.
└ @ nothing nothing:910
┌ Warning: Error requiring `MCMCChains` from `StatisticalRethinking`
│   exception = (ErrorException("cannot assign a value to variable MCMCChains.MCMCChains from module StatisticalRethinking"), Union{Ptr{Nothing}, Base.InterpreterIP}[Ptr{Nothing} @0x00007f36d181da7f, Ptr{Nothing} @0x00007f36d18ac1df, Ptr{Nothing} @0x00007f36d18cdb3d, Ptr{Nothing} @0x00007f36d18b0968, Ptr{Nothing} @0x00007f36d18b1297, Base.InterpreterIP in top-level CodeInfo for StatisticalRethinking at statement 0, Ptr{Nothing} @0x00007f36d18ccb31, Ptr{Nothing} @0x00007f36d18ce949, Ptr{Nothing} @0x00007f3689566731, Ptr{Nothing} @0x00007f368956675c, Ptr{Nothing} @0x00007f36d1893769, Ptr{Nothing} @0x00007f36d18aff15, Ptr{Nothing} @0x00007f36d18afbce, Ptr{Nothing} @0x00007f36d18b0811, Ptr{Nothing} @0x00007f36d18b0b90, Ptr{Nothing} @0x00007f36d18b104a, Base.InterpreterIP in MethodInstance for err(::Any, ::Module, ::String) at statement 2, Ptr{Nothing} @0x00007f36895666a7, Ptr{Nothing} @0x00007f36895666bc, Ptr{Nothing} @0x00007f36d1893769, Ptr{Nothing} @0x00007f36d18aff15, Ptr{Nothing} @0x00007f36d18afbce, Ptr{Nothing} @0x00007f36d18b08a5, Ptr{Nothing} @0x00007f36d18b0b90, Ptr{Nothing} @0x00007f36d18b104a, Base.InterpreterIP in MethodInstance for withpath(::Any, ::String) at statement 10, Ptr{Nothing} @0x00007f3689566623, Ptr{Nothing} @0x00007f368956664c, Ptr{Nothing} @0x00007f36d1893769, Ptr{Nothing} @0x00007f36d18aff15, Ptr{Nothing} @0x00007f36d18afbce, Ptr{Nothing} @0x00007f36d18b0811, Ptr{Nothing} @0x00007f36d18b104a, Base.InterpreterIP in MethodInstance for listenpkg(::Any, ::Base.PkgId) at statement 3, Ptr{Nothing} @0x00007f3689564225, Ptr{Nothing} @0x00007f36895643ac, Ptr{Nothing} @0x00007f36d1893769, Ptr{Nothing} @0x00007f36d18cc4b5, Ptr{Nothing} @0x00007f36d18c217c, Ptr{Nothing} @0x00007f369453b389, Ptr{Nothing} @0x00007f36945c628f, Ptr{Nothing} @0x00007f36945c8500, Ptr{Nothing} @0x00007f36945ca87d, Ptr{Nothing} @0x00007f36945d077c, Ptr{Nothing} @0x00007f36d1893769, Ptr{Nothing} @0x00007f36d18cbcd1, Ptr{Nothing} @0x00007f36d18cdd97, Ptr{Nothing} @0x00007f36d18ccd7c, Ptr{Nothing} @0x00007f36d18ce949, Ptr{Nothing} @0x00007f36945b6aec, Ptr{Nothing} @0x00007f36945b6e89, Ptr{Nothing} @0x00007f36d1893769, Ptr{Nothing} @0x00007f36945b39e3, Ptr{Nothing} @0x00007f36d1893769, Ptr{Nothing} @0x00007f36d18a4546, Ptr{Nothing} @0x00007f36945837ee, Ptr{Nothing} @0x00007f3694583a1e, Ptr{Nothing} @0x00007f3694583a3c, Ptr{Nothing} @0x00007f36d1893769, Ptr{Nothing} @0x00007f36d18b4c9a, Ptr{Nothing} @0x0000000000000000])
└ @ Requires /home/shmuma/.julia/packages/Requires/7Ncym/src/require.jl:49

My dependencies are
      Status `~/work/rethinking/rethinking-2ed-julia/Project.toml`
  [488c2830] BSplines v0.3.2
  [336ed68f] CSV v0.9.6
  [d56128e0] Dagitty v0.0.1 `https://github.com/Shmuma/Dagitty.jl#main`
  [a93c6f00] DataFrames v1.2.2
  [31c24e10] Distributions v0.25.20
  [38e38edf] GLM v1.5.1
  [7073ff75] IJulia v1.23.2
  [5ab0869b] KernelDensity v0.6.3
  [b964fa9f] LaTeXStrings v1.2.1
  [429524aa] Optim v1.4.1
  [a68b5a21] ParetoSmooth v0.6.6
  [91a5bcdd] Plots v1.22.6
  [49802e3a] ProgressBars v1.4.0
  [2d09df54] StatisticalRethinking v4.3.0 `https://github.com/StatisticalRethinkingJulia/StatisticalRethinking.jl#master`
  [e1a513d0] StatisticalRethinkingPlots v0.9.3 `https://github.com/StatisticalRethinkingJulia/StatisticalRethinkingPlots.jl#master`
  [2913bbd2] StatsBase v0.33.11
  [4c63d2b9] StatsFuns v0.9.12
  [f3b207a7] StatsPlots v0.14.28
  [fce5fe82] Turing v0.18.0

Hi Max (@Shmuma),
Not sure if you had fixed it in your repo, but SR v4.4.2 should fix this. Partially it was a circular. If Optim.jl was present it required code that contained using Optim.
Let me know if you still see this.
Rob

Hi Rob,
Yes, the issue has gone. Thanks a lot!


Improve go docs

Resolves #154

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-03-31T11:39:02.907+0000

Duration: 8 min 53 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
240

Skipped
6

Total
246

:robot: GitHub comments
To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.

run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)


Automatic PR from RestAPI-PR719

Generated from RestAPI PR: https://github.com/Azure/azure-rest-api-specs/pull/719

Unreleased SDK, merging


license

Ⅰ. Describe what this PR does
This pr is to add a standardized license in the head of file  ./pkg/controllers/namespace_test.go

look good to me

/approve

/lgtm


Fix test badge in README.md

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 94.197%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
698

Relevant Lines:
741

💛  - Coveralls


[CRX] Respect download requests in main frame

When the URL contains "=download", respect the Content-Disposition header in the Chrome extension.
Steps to verify:

node make chromium
Load the extension at chrome://extensions
Visit  https://drive.google.com/a/notable.ac/file/d/0B6YhVF9p-y2AbUJlcEI5ZGZ5Z2c/view?pli=1
Click on the download button.
Verify that the PDF is downloaded instead of being opened in the PDF.js Chrome extension.

Fixes half of #6106 (the printing part is still a todo, which I'll address after #6190 gets merged)

Works fine, thank you!


[NOMERGE] Objective-C Date Support

[x] Make date inference opt-in
[x] Support marshaling NSDate
[ ] Add tests

cc @davidhodge

Hurray!

@davidhodge would you mind testing this branch?

@davidhodge here's a web preview: https://app2.quicktype.io/#l=objc

Yes! If my in-flight WiFi works. About to take off.
Sent from my iPhone

On Feb 1, 2018, at 8:37 AM, David Siegel<EMAIL_ADDRESS>wrote:
@davidhodge here's a web preview: https://app2.quicktype.io/#l=objc
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@davidhodge good thing quicktype's website works offline 😎

Closing until I have time to wrap this up.


#324 workaround camunda rest cannot parse full iso8601 dates

Description
The camunda rest api can only pass a subpart of iso8601 and so dates with colcon in the timezone part can not be parsed. (i.E. working: 2023-05-17T09:02:58.387+0000, not working: 2023-05-17T09:02:58.387+00:00)
With this mr the format of the datetime is overwritten to support the full iso8601.
References:

https://github.com/camunda/camunda-docs-manual/blob/master/content/reference/rest/overview/date-format.md
https://github.com/camunda/camunda-bpm-platform/blob/master/engine-rest/engine-rest/src/main/java/org/camunda/bpm/engine/rest/mapper/JacksonConfigurator.java#L37

Reference
Issues #324

@zambrovski we found an old post where you probably had the same or a similar problem: https://forum.camunda.io/t/engine-rest-date-format-bug/6105/14
Do you remember if you came over a better idea to solve this?


Fragmentation of metadata and data

Was going through the previous tickets related to fragmentation (https://github.com/ReactiveSocket/reactivesocket/issues?utf8=✓&q=is%3Aissue is%3Aclosed fragmentation) and noticed that most of them seem a bit outdated given that we currently have the F flag available on both requests and responses today.
I'd like to understand where we currently stand on this because during my work on the Go implementation I came across some scenarios that required assumptions about how metadata and data are fragmented.
For instance, the sender side of a Fire-N-Forget that has 1MB of metadata and 20MB of data would do the following (according to my assumptions):
Frame 1: header (F,M), metadata(1MB), data(~16MB)
Frame 2: header, data(~4MB)
Now if we consider a scenario where we had 20MB of metadata and 1MB of data, it'd look like this:
Frame 1: header (F,M), metadata(~16MB)
Frame 2: header (M), metadata(~4MB), data(1MB)
Is it correct to assume that in cases where either metadata or data should be fragmented the consumer side would always see metadata first? If this is true, then it makes it much easier for higher level APIs to implement proper streams as opposed to having to deal with fragmentation at the user level API.

This would definitely be a good thing to clarify. I don't think the framing itself needs anything new, but a section describing the rules would eliminate different interpretations.
@tmontgomery Do you have guidance on how this should best be done?

Yes, this needs clarification. And an example sounds very good.
For clarity and ease, I think the way it should work is that the implementation should send metadata first. Any comments?

I agree with metadata first. As far as the example goes, perhaps we could start with my example above unless someone else has a better idea. Would be a good addition to the Fragmentation and Reassembly section.

The difficulty as I see it for implementors is that naturally you end up with some Stream API for both producers and consumers if your payloads start getting into MB sizes.  Every Web framework does this for chunked encoding.
Nothing in the spec seems to disallow any of

metadata first
data first
interleaved

At this point whoever writes the application code is in control of the ordering.  e.g. I might read both metadata and data from files off disk concurrently with different threads, this would effectively interleave the metadata and data.
Are you going to change the spec to say that metadata always comes first and must complete before any data is sent?
If an implementation gets this API wrong, you end up with the issue that plagues using the java Process API, you must concurrently read both stderr and stdout to avoid blocking the producing process.

That's a very good point about the Java Process API, and how things can get ugly especially with payloads of multiple MBs of metadata and data.
Despite that, I have no plans to change the spec until we're all on the same page with the idea that metadata must come first - which is nothing new given how frames are formatted anyway.

To me this feels like an arbitrary decision.  Much like HTTP/1.1 headers come before the response. So we get to
Allowed

metadata and data provided in a single frame
metadata completes before or in the first frame containing data

Not allowed

metadata starts or continues past the first frame containing data.

It's interesting that HTTP/2 specifically broken from this model
https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230.html#chunked.trailer.part

A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message's header section.

I think the tradeoff here is this: if we're willing to have high level APIs that handle fragmentation and  reassembly transparently we need clear rules for how to fragment and reassembly metadata and data. If don't have those rules we may have to always expose the bare bones API and let users implement fragmentation in any way they want - which can lead to very different implementations and decrease adoption since users would have to learn the wire protocol even for writing simple applications.
As far as comparing it with HTTP/2, we only have a generic "metadata" type that today cannot be differentiated between headers and trailers. Our current metadata (as per the frame format) looks more like headers than trailers IMO.

The reason I mentioned metadata first is to be similar to HTTP. And also to make implementation simpler.
In general, I would rather have metadata and normal data proceed in any order. i.e. fragmentation can have both data and metadata proceeding as necessary. That is easy for the spec. But it is hard for implementations to handle. So, picking metadata first is simply for ease of implementation.
However, if I am mistaken or if we feel it is not a huge burden for implementations to allow both metadata and data in the same fragments, I am OK with that.

For a protocol I'm very strongly in favour of allowing the data to proceed in any order.  So I'm actually against suggesting the implementations should just consume metadata first in case that is not the case.
I'd rather the 95% case be that you don't use fragmentation/streaming APIs.
The 5% can be complicated, but I'm also not clear on what that means for RxJava integrations etc.

Assuming that 95% of the cases don't use fragmentation implies that users of any library understand the protocol's frame size limitations (of metadata and data) and also understand how fragmentation works, should they ever need it.
Allowing metadata and data to proceed in any order makes it much harder to provide higher level APIs, and can lead to the aforementioned problem of the Java Process API.
Both cases above could lower the adoption of the protocol by users that only care about shipping data upstream and downstream without knowing the nitty gritty of fragmentation and reassembly.
This is just my 2c, and I'm the new guy here, so please correct me if I'm wrong.

I'd personally want to switch to some streaming mode before I hit the 16MB protocol frame size limits.  But I'd also want to be able to configure my server to reject clients trying to send me 16MB pills the swallow also :)

@benjchristensen (and others) do we have a preference?

specify that data and metadata can be fragmented in any order as well as mixed. Easiest for spec and gives more freedom.

strict adherence to metadata (or data) fragmented first, then the other. Easier for implementations (maybe).

Honestly, I would prefer the former so that the spec is very lenient and I don't think that it is that onerous on implementations. But would like to know others opinions.

When I implemented this for the Java version long ago (it never landed, but I implemented it!) ... I didn't treat either as special. I took a single Payload with data/metadata as the application wished to send, fragmented it over the wire, reassembled on the other end, and delivered a single combined frame with  the entire Payload.
Why not just retain that simple approach so that it's purely a network level thing and doesn't change the API or behaviors?
In other words:

sender writes Frame with Data/Metadata to ReactiveSocket
ReactiveSocket fragments into multiple frames over the wire
receiving ReactiveSocket reassembles into a single Frame
receiver receives Frame with Data/Metadata

I think that is punting the issue down the road, which I'm actually ok with if we are clear.  It works well for current use cases but doesn't clarify how to correctly and safely implement the protocol.  If we want to go down this route, we should just say in protocol version 1.0 that fragmentation is any order and is implementation and/or use case defined (prior arrangement).
Longer term:
My guess is the ample payload size (16MB) of the protocol means that the majority of users of the implementations won't even benefit from fragmentation, except for if you do it specifically to allow avoiding head of line blocking from a selfish producer.
It seems to me more likely that you would want to chunk the payloads well before the 16MB to enable certain use cases like

an efficient router of opaque RS frames, e.g. reverse proxy.
immediate use of incoming streams, e.g. start writing to disk as stream comes in.
stream producers e.g. stream of objects piped through streaming JSON library to an output stream.
large response payload followed by a signature of the content.

If I needed to come up with a reactivesocket-api for now, I'd go for something like
public interface StreamedPayload extends Payload {
  Optional<InputStream> getDataStream();
  Optional<InputStream> getMetadataStream();
}

A counter argument to mine from the HTTP/2 world - https://github.com/quicwg/base-drafts/issues/76#issuecomment-281226785

I think routing is a higher level concern than the protocol can effectively address. While metadata is a great spot to place routing information, it is by no means the only location. Nor the best location.

In all honesty, I believe that metadata should be kept small. Something is very wrong if metadata needs to be fragmented, IMO.
Having said that, I do know that a user will want/need to have a lot of metadata for some reason (good or bad). Given that, fragmentation of metadata will need to be proscribed and allowed. Whether it is a good idea or not is immaterial.
One possible solution is to allow metadata and data to be fragmented however the application desires. I.e. payloads with fragments of metadata as well as data. And let higher level protocols determine if there is a strong priority to fragment metadata over data first or last in the stream.
This isn't really kicking the can down the road. This is placing a boundary between what is a concern for RS and what is a higher level concern.

My concerns of not addressing this sooner rather than later are similar to what @yschimke describes wrt correctly and safely implementing the protocol.
When I read the spec and found that frames can have metadata, and the actual length of metadata is even longer than the frame length itself, I thought that metadata not only would be expected but also expected to be potentially large. The protocol allows metadata to be large. That's probably not common in most places but in many other places metadata will be large and fragmented.
The reason I opened this issue is because while implementing the spec I could not figure out the rules for fragmenting and reassembling metadata and data. We probably don't want to leave it open to interpretation.
As far as allowing metadata and data in any other, I have to disagree, because the worst case scenario is somewhere in the Java Process API land. Having fragments of the same stream with mixed metadata and data in no specific order will make streaming APIs more difficult and complex, probably requiring to either allocating memory to reassemble multiple frames, or spawning threads to stream the distinct metadata and data "concurrently". I can't see a cheap implementation coming out of this.
Anyway, I am fine with either approach so long it is clear in the spec.

I don't understand what the correctness and safety issues are for this, so I must be missing something.
Application API
Sender
BigData d; (25MB of data)
BigMetadata m; (20MB of metadata)
Payload p(d, m);
write(p);

Receiver
void receive(Payload p) {
  BigData d = p.d;
  BigMetadata m = p.m;
}

Frames (possible delivery with metadata first)

PAYLOAD frame

Frame length = 16MB
(M)etadata present = 1
(F)ollows = 1 (fragments coming)
Metadata Length = 16MB
16MB of METADATA
0MB of Data

PAYLOAD frame

Frame length = 16MB
(M)etadata present = 1
(F)ollows = 1 (fragments coming)
Metadata Length = 4MB
4MB of METADATA
12MB of Data

PAYLOAD frame

Frame length = 13MB
(M)etadata present = 0
(F)ollows = 0
0MB of METADATA
13MB of Data
Frames (possible delivery with data first)

PAYLOAD frame

Frame length = 16MB
(M)etadata present = 0
(F)ollows = 1 (fragments coming)
0MB of METADATA
16MB of Data

PAYLOAD frame

Frame length = 16MB
(M)etadata present = 1
(F)ollows = 1 (fragments coming)
Metadata Length = 7MB
7MB of METADATA
9MB of Data

PAYLOAD frame

Frame length = 13MB
(M)etadata present = 1
(F)ollows = 0
Metadata Length = 13MB
13MB of METADATA
0MB of Data
Frames (possible delivery with mixed)

PAYLOAD frame

Frame length = 16MB
(M)etadata present = 1
(F)ollows = 1 (fragments coming)
Metadata Length = 8MB
8MB of METADATA
8MB of Data

PAYLOAD frame

Frame length = 16MB
(M)etadata present = 1
(F)ollows = 1 (fragments coming)
Metadata Length = 8MB
8MB of METADATA
8MB of Data

PAYLOAD frame

Frame length = 13MB
(M)etadata present = 1
(F)ollows = 0
Metadata Length = 4MB
4MB of METADATA
9MB of Data
Interpreting the frames
In all three of these scenarios, the sender and client do not need to pre-arrange which one they are doing, the frames communicate all the information needed. They communicate how many bytes are present for either metadata or data, and if fragments follow. The receiving implementation keeps receiving the bytes until no further fragments.
If an implementation wished to parse the bytes in a streaming fashion, instead of waiting for the entire payload, it is possible on all three of the above approaches to keep emitting bytes as they come in for either metadata or data across frames.
What am I missing that would make this not just work?

Your API is simple and unambiguous for the protocol.
But inherently unsafe for the systems built using these APIs.  They need to buffer and collect each fragment of the payload until it is complete.  They are vulnerable to a DOS attack by sending 100MBs of data and then dribbling through small additional fragments. It is also very innefficient as I can't start consuming the first byte of the data until the last byte is complete.
As an implementor if I try to implement a streaming API on top of this I then I open up the issues that  we raised above.
We should be able to learn from every Web framework out there that streaming APIs are critical for anything that looks like chunked encoding.

+1

I think we can defer a streaming RSocket API if the wire format still supports it, which it sounds like it does. Not enforcing ordering of Data/Metadata allows applications to send some metadata after they've written the (possibly large) data. @yschimke example here was a signature/hash of the data that could be computed on the fly.
That said, we should still work on clarifying the wording in the spec and add examples, I think @benjchristensen examples look pretty good.

@lexs We don't have to discuss streaming APIs in depth here. Instead, we're trying to make sure they can be safely implemented based on what the spec describes, and today with unordered metadata and data (in fragmented streams) it does not make it easy for implementations to do so, at least on the consumer side.

It's not clear to me why interleaved data/metadata complicates any API, you still have to have either an API with one interleaved stream delivering Data/Metadata or two separate streams with complicated requirements.
Say we define metadata to come before data, how would the API look (in broad terms)?

We can use the one posted by @yschimke as an example for a consumer API:
public interface StreamedPayload extends Payload {
  Optional<InputStream> getDataStream();
  Optional<InputStream> getMetadataStream();
}

With ordered metadata and data you can always consume/pipe one at a time. With mixed/interleaved you'd have to consume from both concurrently or reassemble their entire payloads before pumping bytes out to the streamer.

They are vulnerable to a DOS attack by sending 100MBs of data and then dribbling through small additional fragments.

How does adding rules to the spec prevent someone from doing a DOS attack?

So if I understand correctly, @fiorix and @yschimke, you'd prefer just having a rule that says "When a Payload is fragmented, Metadata MUST be completely transmitted before Data"?
In other words, only allow the first option of my examples above?

PAYLOAD frame

Frame length = 16MB
(M)etadata present = 1
(F)ollows = 1 (fragments coming)
Metadata Length = 16MB
16MB of METADATA
0MB of Data

PAYLOAD frame

Frame length = 16MB
(M)etadata present = 1
(F)ollows = 1 (fragments coming)
Metadata Length = 4MB
4MB of METADATA
12MB of Data

PAYLOAD frame

Frame length = 13MB
(M)etadata present = 0
(F)ollows = 0
0MB of METADATA
13MB of Data

I do prefer that for the long term, aiming at safe implementations that easily allow for streaming APIs. But I can live with the current mix so long it is clear in the spec.
What I still don't understand is what's the use case for having mixed metadata and data in fragmented streams.

What I still don't understand is what's the use case for having mixed metadata and data in fragmented streams.

@fiorix: @yschimke mentioned http2 header/trailers. Say some headers can be delivered before you've sent the data but some can only efficiently be delivered after the whole payload has been written, like a checksum.
Regarding using InputStreams I'm not sure that's the correct abstraction here given that else is very pushy I think the API should be pushy too. I see us delivering two Flowables, one for metadata and one for data.

What I still don't understand is what's the use case for having mixed metadata and data in fragmented streams.

Fragmented streams is the exception to the point of this protocol. The point of this protocol is streams, the requestStream and requestChannel interactions. Having requestResponse and fireAndForget are just side-effects, performance optimizations of "stream of one" or "stream of none" when I already have a connection established and don't need streams for some use cases.
Having metadata associated with each payload is useful on streams.

Example of metadata to deliver with message payloads:

infrastructure metadata about network routes, latency, health associated with a particular message
compression dictionary updates in the middle of a stream
dictionary updates required for a particular message

So yeah, the point for this whole issue is only about fragmentation and rules. I get that if you're using streams and channels it's quite common to have interleaved frames with metadata and data (or even only one or the other) but those are single units that are part of a stream or channel.
When it comes to fragmented messages the rules should be slightly different IMO, to effectively allow cheap reassembly on the consumer side.

@lexs http2 trailers (which are just special headers) can only be sent after data, not interleaved.

So is the proposed rule in https://github.com/ReactiveSocket/reactivesocket/issues/170#issuecomment-281731534 sufficient?

Not quite, @benjchristensen.
What I expected in the beginning is this: whenever frames with the same Stream ID and the M,F flags set, metadata must be fully transmitted first, no matter the size of it.
This is not to be confused with the Stream and Channel flow control of RequestN and their continuation by another RequestN, or termination by a PAYLOAD with COMPLETE.
If we take the request/response flow, for example:
1. RQ -> RS: REQUEST_RESPONSE
2. RS -> RQ: PAYLOAD with COMPLETE

If the request must be fragmented because either data or metadata won't fit in 1 frame, it must always transmit all the metadata first, then the data. It's possible that at least 1 frame in the sequence with the same Stream ID will contain both metadata and data.
Now in a channel or stream, this also apply, but only as a fragmentation rule:
1. RQ -> RS: REQUEST_STREAM (REQUEST_N=3)
2. RS -> RQ: PAYLOAD
3. RS -> RQ: PAYLOAD
4. RS -> RQ: PAYLOAD
5. RS needs to wait for a new REQUEST_N at that point
6. RQ -> RS: REQUEST_N (N=3)
7. RS -> RQ: PAYLOAD
8. RS -> RQ: PAYLOAD with COMPLETE

Let's say that PAYLOAD 2 must be fragmented, which is, containing the F flag. First, I would assume that multiple fragmented frames count as 1 delivery (from the RequestN). If a single frame must be fragmented, then its metadata must be transmitted first.
This still allows for the same stream in the example above to have frame 3 with only data and frame 4 with only metadata.
Does this make more sense?

@fiorix It was just an example of something we couldn't easily support if we send metadata first.

What I expected in the beginning is this: whenever frames with the same Stream ID and the M,F flags set, metadata must be fully transmitted first, no matter the size of it.

I think that describes the example I provided, so I must not be communicating clearly enough :-)
I'll attempt a pull request to the protocol spec to clarify this and we can iterate on exact wording there.

I think there are multiple things being collapsed here that I think might be good to tease apart.

A Streaming API is possible without having metadata delivered first. This is orthogonal to the order of M,F frames being sent. Data and Metadata can be individual streams as has been pointed out.
Opening implementations up to attacks is still just as possible with metadata first. Someone sends 100GB of metadata will block non-streaming APIs until it is delivered and complete and consume memory. While having no order preference allows a duplicate attack vector, it doesn't change the attack surface. It just means that data AND/OR metadata can be used.

My preference is to make metadata practices "better" and to think of using little metadata. So, I am quite fine with it being prioritized in the implementation. But I don't think we should choose that because we think we are gaining anything from streaming APIs and/or reducing the attack surface, because I don't think we are.

Opening implementations up to attacks is still just as possible with metadata first

I raised this in the context of an API that only delivers a complete Buffer (~byte[]) to clients. You have to buffer the data in memory within the implementation code even if its a slow client sending large payloads. An API that supports streaming can error the stream once it gets to X MB of unconsumed data.

Yes, but that is an API choice and not the protocol. I totally agree on the API (nee implementation) being the vulnerability here. Not the protocol.
My concern is that we make a choice based on the correct impact. i.e. not picking to prioritize metadata over data because of a perception that it will lead to fewer attack vectors.

I honestly think this is a flaw in the protocol though, because of the inconsistency between the format of a single frame and a frame that needs to be split in multiple fragments to accommodate its larger payload.
IMO multiple fragments should have the same layout of a single frame, but split in fragments looking like one giant frame, so it can be easily streamed and reassembled just like a single frame would.
Having fragmented frames with interleaved metadata and data will force implementations to either reassembly them concurrently in memory, or stream them concurrently to distinct consumer processes.
Despite all this, like I said before, I'm happy to move on and leave v1 the way it is. I can close this issue in a couple of days if everyone agrees with moving on.

Proposed a change here: https://github.com/ReactiveSocket/reactivesocket/pull/194

💯


makeTraverse for non-last type-argument

Take some data Foo a b c, and i'd like to derive traverse like function for second argument. How hard would it be to parametrise makeTraverse to do that, i.e.
traverseFooB :: Applicative f => (b -> f b') -> Foo a b c -> f (Foo a b' c)
traverseFooB = $(makeTraverse ...)

Even more generally, would be even greater to have unified deriving mechanism for Bitraversable and futher kind-variations. (I had uses for tritraverse), maybe something like
traverseFooAB f g = makeTraversal ''Foo [Use 'f, Use 'g, Skip]

I'll answer your second question first: in principle, it's not hard to generalize the TH machinery to work on classes of higher arities. In fact, we're already doing so for Eq{1,2} and friends. The only reason that deriving-compat limits itself to Traversable and not Bitraversable is because the bifunctors library already included a way to derive Bitraversable with TH before deriving-compat was created, so I decided that Bitraversable was out of scope for deriving-compat. (Not by coincidence, the code in deriving-compat and bifunctors share many similarities.)
As for the first question, it may be possible to derive traversals for arbitrary type variables, but it would likely need to work in a rather different way than deriving-compat currently works. Here is a first example to set the stage:
data T1 a = MkT1 (T2 a)
$(deriveTraversable ''T1)

When deriving a Traversable instance for T1, we have to "recurse" into T2 in some fashion. The way that deriving-compat does this is by assuming T2 has a Traversable instance and traverse-ing into it. As a result, you'd end up with this code:
instance Traversable T1 where
  traverse f (MkT1 x) = MkT1 <$> traverse f x

Now let's consider a modified example where we only want to traverse over a single type parameter:
data S1 a b = MkS1 (S2 a b)

traverseFirstParamOfS1 :: Applicative f => (a -> f a') -> S1 a b -> f (S1 a' b)
traverseFirstParamOfS1 = $(makeTraverseForFirstParam ...) -- I'm not yet sure what the API would be for this

Similarly, we must also "recurse" into S2 when generating code. However, the situation is a bit different this time, since a simple traverse won't suffice. I can think of two ways to make this work:

Assume S2 is an instance of Bitraversable:
traverseFirstParamOfS1 = \f (MkS1 x) -> MkS1 <$> bitraverse f id x

The problem with this approach is that it's limited to the last two type variables in a data type. If we wanted to traverse over, say, the third-to-last type variable, we'd have to invent a new type class like Tritraversable. Similarly if we wanted the fourth-to-last type variable (Quadrifunctor), or the fifth-to-last type variable (Quinquefunctor), etc.

In the implementation of traverseFirstParamOfS1, pattern-match on the value of type S1 and recurse into its fields. I didn't define what S2 is above, but for the sake of this example, let's assume S2 is defined like so:
data S2 a b = MkS2A a | MkS2B b

Then one could generate code for traverseFirstParamOfS1 like this:
traverseFirstParamOfS1 = \f (MkS1 x) -> MkS1 <$> (case x of { MkS2A y -> MkS2A <$> f y ; MkS2B z -> MkS2B z })

This also works, but it breaks abstraction a little bit, as it requires knowing what the definition of S2 is. This isn't technically a problem for Template Haskell, as it can always reify the definition of a data type, even if the data type is abstract. Still, it's a rather different approach than what deriving-compat uses, and I'm somewhat hesistant to go down this route.
By the way, if this option is what you want, you might consider using the genifunctors library, as it uses exactly this approach to define traversals for arity-3-or-greater data types.

One other downside of option (2) that I forgot to mention above is that it assumes you can case on the value on the first place. If you have something like this, however:
data V1 f a b c = MkV1 (f a b c)

Then you're out of luck, since case-ing on something of type f a b c isn't possible in general.

I think it's fine to give up when recursion is needed and there is no class for that kind-pattern. That's what DeriveFunctor etc does anyway when it encounters an argument in non-last position. That makes machinery less general, and would be nice to have a solution, but it can be found later.

OK. What API would you propose for this new functionality? Presumably, all of the existing make*2 functions would need variants that allow controlling which type variable(s) you care about. I'm not sure how many variants we'd need or what to name them, however.
Also, there's still an annoying hiccup in that deriving-compat has no knowledge of Bitraversable and friends. I suppose we could put similar functionality in the bifunctors library as well if we wanted to. I'm not sure.

possible options are from top of my head:

kind-generic traversable class (difficult)
type's Name kind argument -> Name of that traversal
generating "full-traversals" (needs naming still)

the second would work with
data S1 a b = MkS1 (S2 a b)

by generating
traverseS1a f (MkS1 s2) = MkS2 <$> traverseS2a f s2

where the naming scheme could be provided by a user.
This won't work with
data V1 f a b c = MkV1 (f a b c)

as there we could only generate "full-traversals", i.e.
traverseAll
    :: Applicative m
    => (forall a1 a2 b1 b2 c1 c2. (a1 -> m a2) -> (b1 -> m b2) -> (c1 -> m c2) -> f a1 b1 c1 -> m (f a2 b2 c2))
    -> (a -> m a')
    -> (b -> m b')
    -> (c -> m c')
    -> V1 f a b c
    -> m (V1 f a' b' c')
traverseAll f a b c (V1 x) = V1 <$> f a b c x


stack_config.md not exist and delete it in other files

stack_config.md not exist and delete it in other files, and re-order the stack files.

LGTM 🐻


Support for TRV modules

It would be nice to add support for more module types. I have some TRV modules used to control my screens. I could automate them based on wind and sun conditions.

I have no TRV modules in my installation. If you are interested and have some python knowledge I can assist on developing this part by yourself.

I saw somebody else created a pull request for cover support and it seems there is already support in the python library as well. I am a developer, but not Python, but always eager to learn new things.

Yep, I approved the pull request.  The code looks ok. Would be great if you can test the cover support.

Now I need to figure out how to setup my home assistant to use this new cover functionality. (there is no documentation).
I tried to configure a cover like I define lights, but that does not seem to work. (here I am trying to register the TRV model.channel to control one of my shades.
cover:
  - platform: domintell
    devices:
      - type: TRV
        module: 239b
        channel: 3
        name: Screen Zolder

When I try to access it in Homekit I get an error:
Failed to call service cover/open_cover. 'DTRV01Module' object has no attribute 'open_cover'
I guess this is not how I am supposed to control a cover ?

haven't tested it yet.

OK, it works with the latest release. If did find a small glitch in that the initial state of a cover is always "closed".


DX improvements for 2.0 (e.g. tooling)

NOTE: This issue is WIP

Effect eslint rules

[ ] Enforce restrictions of Do(($) => { ... })

[ ] Prevent branching
[ ] Make sure yield / $ is called

[ ] ... what else?

[ ] prevent === on things implementing Equal
[ ] Help catch duplicate context tag symbols which should be globally unique

Codegen-driven

[ ] Help with derived -> opaque type boilerplate @@opaque

VSC Extension
Refactor workflows

[x] wrap/unwrap pipe - e.g. myFn <> pipe(myFn)
[ ] Curry/uncurry definition site - e.g. const x = 1 <> const x = () => 1
[x] Curry/uncurry call site - e.g T.tap(_ => T.log(_)) <> T.tap(T.log)
[ ] Refactor from/to T.succeed and T.sync
[ ] .pipe() <> pipe()
[x] "Update" explicit type signature / see diff

Improve error messages

[ ] Environment dependency mismatch error messages should be improved

Fiber-aware debugger

closing as outdated


Undefined symbols: _cmd_otcli_init, referenced from: _main in chip-sh…

…ell.main.cpp.o
Problem
./gn_build.sh throws.
Summary of Changes

Add extern "C" around the cmd_otcli_init definition

extern "C" not needed at the definition if the declaration is in scope
We should make sure to include the declaration, otherwise there's no guarantee the signature will match


PR: Add Python 2 support

Fixes #75
I used Microsoft Visual Studio 14.0 to build the Python 2.7 version.   See #75 for explanation.

Well, the incompatibilities are related to the conda build system, i.e., To compile Py2.7 packages, MSVC 2010 is required. However, to compile winpty, 2013 version or later is requiered. Therefore, you cannot install on conda a package compiled with MSVC 2010 that depends on another package compiled on 2013 version. Unless we compile the packages manually ourselves, we cannot provide Python 2.7 supporr

@mingwandroid

Why can't the build recipe effectively do what is done on appveyor to build it?

i.e., use the precompiled winpty from conda forge.

Then all you need to build is the cython wrapper.

PyWinpty needs to be compiled with msvc 2008 (not 2010) for it to work with py27 (but it needs 2013 or higher)
https://wiki.python.org/moin/WindowsCompilers
One can try to use pywinpty compiled with MSVC 2015 which is what is required for both py35 and py36 and it might look like it works... until it does not since they will not be binary compatible. But @mingwandroid can explain all the intrincancies of this much better than I can that is why I summoned him ;-)

Ah, gotcha.

Steve, the main problem is that Winpty requires a compiler with C++11 support:
https://github.com/rprichard/winpty#prerequisites
The first MSVC with full support for it is the 2013 one, so it can't be compiled for Python 2.7 using that toolchain.
The alternative is using MSYS2, which is the route modern C++ projects with Python bindings take to support Python 2.
I think that shouldn't be hard using conda: you just need to require the posix package, then you need to run the usual configure && make. Then you need to use MSYS2 to compile our Cython bindings too.
However, we don't have the resources to tackle this right now.

Thanks for the pointers!

I took a crack at it using the winpty-feedstock and tried both mingwpy and m2w64-toolchain but quickly realized I was out of my depth.

An update on this: I got most of the way there using the libs below, but we need sys/select.h and the libs that it includes, which are not natively available or provided by any of the posix or m2* packages as far as I can tell.
    - posix
    - m2-bash
    - m2-make
    - m2w64-toolchain

I'm going to test this locally on Py2.7 against terminado.

LGTM:
(py27) builder: /c/users/builder/workspace/terminado (winpty) 1
$ py.test
============================= test session starts =============================
platform win32 -- Python 2.7.14, pytest-3.2.5, py-1.5.2, pluggy-0.4.0
rootdir: C:\users\builder\workspace\terminado, inifile:
plugins: flaky-3.4.0
collected 8 items

terminado\tests\basic_test.py ........
===Flaky Test Report===

===End Flaky Test Report===

============================== warnings summary ===============================
terminado/tests/basic_test.py::TestTermClient
  cannot collect test class 'TestTermClient' because it has a __init__ constructor

-- Docs: http://doc.pytest.org/en/latest/warnings.html
==================== 8 passed, 1 warnings in 50.18 seconds ====================

builder: /c/users/builder/workspace/terminado (winpty) 1
$ py.test --pdb
============================= test session starts =============================
platform win32 -- Python 3.6.3, pytest-3.2.1, py-1.4.34, pluggy-0.4.0
rootdir: C:\users\builder\workspace\terminado, inifile:
plugins: flaky-3.4.0
collected 8 items

terminado\tests\basic_test.py ........
===Flaky Test Report===

===End Flaky Test Report===

============================== warnings summary ===============================
terminado/tests/basic_test.py::TestTermClient
  cannot collect test class 'TestTermClient' because it has a __init__ constructor

-- Docs: http://doc.pytest.org/en/latest/warnings.html
==================== 8 passed, 1 warnings in 56.55 seconds ====================

@blink1073 could you update the conda.recipe on conda-forge, then ?

I was planning to use this approach that consumes the pre-built wheels: https://github.com/conda-forge/mingwpy-feedstock/blob/master/recipe/meta.yaml

@blink1073  why not use the normal approach and build the recipe, did  not you use msys2 at all?

No, as I said above I ran into a brick wall with msys2 and a lack of appropriate header files.  I don't have a good example of building against vc 14, unless @SylvainCorlay can point me to one.

Attempt in progress: https://github.com/conda-forge/pywinpty-feedstock/pull/7

Okay, the build itself is succeeding there, we just need this release to pick up the handling of backports.shutil_which.

cf https://ci.appveyor.com/project/conda-forge/pywinpty-feedstock/build/1.0.24/job/1eur4266240cym2c#L476

Steve, I think you also need to remove the pin we added to Python 3 in
the winpty feedstock. Or is that not necessary?
El 27/11/17 a las 13:34, Steven Silvester escribió:

cf
https://ci.appveyor.com/project/conda-forge/pywinpty-feedstock/build/1.0.24/job/1eur4266240cym2c#L476
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/pywinpty/pull/66#issuecomment-347279852,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWS7T4pT4op1hmyoJE5nNje-Yh3U8DIks5s6wCtgaJpZM4QjXOH.

I'm not entirely sure on that one, but worth doing to be sure.

Ready when you are, @ccordoba12  :wink:

I'd like @andfoy to take a last look at this one and merge it. I've barely been involved with this package.
@andfoy, I couldn't modify coveralls settings, so please do it yourself. You just need to change the minimum amount to report failures from 0% (the default) to 5% or something.

Fair enough, I had to ask :smile:

Jeje, no worries ;-)

LGTM! Thanks for the great additions to pywinpty @blink1073 !

More goodies coming pending pexpect integration!

Merging then!

:boom:

@ccordoba12 I will give @blink1073 write permissions for this repo. Do you agree?

Sure, please go ahead!
Steve, we finally managed to bring you back to work with us again ;-)
El 27/11/17 a las 17:46, Edgar Andrés Margffoy Tuay escribió:

@ccordoba12 https://github.com/ccordoba12 I will give @blink1073
https://github.com/blink1073 write permissions for this repo. Do you
agree?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/pywinpty/pull/66#issuecomment-347354566,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWS7YW1R1QLQMm1jWbio1-Wq5zHy8tAks5s6zvWgaJpZM4QjXOH.


Merge - Import and Export

This change is

Coverage decreased (-2.4%) to 83.341% when pulling f592fce76fbcc2899c7cfe43d678975c4527c486 on ImportnExportcmd into 67447ade038ddf70ef8b29491556d2bbdde2520b on master.


feat(trajecotry_follower,trajecotry_follower_nodes): add constant vel…

Description

add contant velocity controller for psim testing

Related links

Tests performed
by psim
because psim doesn't have any limitation for velocity or acceleration this will keeps accelerating
https://user-images.githubusercontent.com/65527974/195523927-aff283ed-2659-43cb-991b-3c69839a796b.mp4
Notes for reviewers
Dont merge this
this PR needs this change and set option constant
https://github.com/tier4/autoware_launch/pull/514
    # longitudinal controller mode
    add_launch_arg(
        "longitudinal_controller_mode",
        "constant",
        "longitudinal controller mode: `pid` or `constant`",
    )

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

Codecov Report

:exclamation: No coverage uploaded for pull request base (beta/v0.5.3@aee2610). Click here to learn what that means.
Patch has no changes to coverable lines.

Additional details and impacted files
@@              Coverage Diff               @@
##             beta/v0.5.3     #149   +/-   ##
==============================================
  Coverage               ?   42.29%
==============================================
  Files                  ?       54
  Lines                  ?     3769
  Branches               ?     1918
==============================================
  Hits                   ?     1594
  Misses                 ?      679
  Partials               ?     1496

Flag
Coverage Δ

differential
42.23% <0.00%> (?)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


GRU implementation

Hi,
I want to do some optimization for this model using mkldnn backend library.
But I find that GRU.py  seems not implemented as standardized one. The difference is that Batch Norm for i2h is used in this model after indata*weight+bias.
Can you kindly show the reference paper ?
Thanks very much.

I referenced deep speech 2 paper and following link may help, the author of deep speech 2 wrote a comment on batch normalization. https://www.reddit.com/r/MachineLearning/comments/4082yn/rnn_batch_normalization_for_grulstm/?st=JBEAKSUQ&sh=14046726


Implementing debounce for Button interrupts (sync & async)

Implementing debounce

Adds Debounced wrapper struct for Button to allow calling of sync/async interrupt functions with software debouncing
Adds Debounce trait to extend Button with debounce() method (returns Debounced wrapper struct)
When waiting for press, check the Debounced::last_trigger field and make sure at least the debounce Duration has passed

Tested with a simple program using a relatively high debounce (500ms):
use std::time::{Duration, Instant};

use rust_gpiozero::{Button, LED};

fn main() {
    let mut button = Button::new(4).debounce(Duration::from_millis(500));
    let mut led = LED::new(17);
    led.set_blink_count(1);
    let mut last_press = Instant::now();

    println!("Waiting for press...");
    loop {
        button.wait_for_press(None);
        println!("{}ms since last press", last_press.elapsed().as_millis());
        last_press = Instant::now();
        led.blink(0.5, 0.1);
    }
}

Which produces the following results when I press the button as fast as possible:
Waiting for press...
2074ms since last press
598ms since last press
513ms since last press
561ms since last press
566ms since last press
508ms since last press

@dcroote perhaps you can help test this?

@dcroote  Thank you for the feedback! Sorry for the seconds/millis mixup, it's much clearer with the correct units :) Also I'm not sure why my clippy wasn't showing the same warnings, hope this has a clean result.

thanks both @thepacketgeek @dcroote 👍


Adding short names for the GCS nomenclature instead of the complete region

#227 Added the local variable for location_prefix for regional buckets which changes us-central1 to usc1 and likewise using terraform-google-modules/terraform-google-utils and retaining the original logic if the bucket is multi-regional.

Hey, thanks for the PR. Submodules are really, really an antipattern, and one of our main tenets is having no external dependencies in the core modules. I also don't see a reason to use short names, especially since most times you already have proper region names used for GCE; etc.

Yeah no that makes complete sense. My idea was to beautify the nomenclature by sort of shortening the names as they appear. But yeah introducing an external dependency does complicate things. Thanks for the clarification!


LUCENE-10111: Missing calculating the bytes used of DocsWithFieldSet in NormValuesWriter

Basing on the implement of updateBytesUsed() in SortedDocValuesWriter and the other DocValuesWriters, it seems to lack of calculating the BytesUsed of DocsWithFieldSet in NormValuesWriter？

Hi, @jpountz this issue was put under Improvements (version 8.11)


Using parse() fails on strings.

Consider:
std::string valid_toml("foo = 32\nbar = 3");
std::istringstream is(valid_toml, std::ios_base::binary | std::ios_base::in);
auto table = toml::parse(is, path.string());

This is when you need to pass not a file, but a string to be parsed.  The parse step creates an invalid line error.  I suspect it is because it doesn't check for the end of the string correctly, but I'm not sure.  I tried various combinations of line endings, but maybe there is a simpler way to parse a string?

When I tried your simple test it worked for me too; but inside my app I got:
[error] toml::parse_table: invalid line format
....
1 | foo = 32
If I passed the same string to cpptoml it worked as well (I was previously using cpptoml but moved to toml11)
After debugging I narrowed it down.
What appears to be happening is that my std::string is 0 terminated (probably because it was loaded previously from a file).  But the checks in toml11 do loc.iter() != loc.end().  The problem is that for a null terminated string, the end iterator points to the location after the terminator, so this check is no good for determining the 'end'.
If you modify your test and do this:
std::string valid_toml("foo = 32\nbar = 3");
valid_toml.push_back(0);
You will get the exception.
You might argue that the correct fix is not to pass 0 terminated strings.  I'm not sure.
BTW, I'm on Windows, VC2019.

Thank you, I reproduced it. It makes sense.
Actually there is already an error message to show the character that causes a problem (https://github.com/ToruNiina/toml11/blob/master/toml/parser.hpp#L1809), but the error message after the line that causes the error is terminated because of \0 at the end of the line.
Anyway, I can fix this. After loading istream content, I can check whether the last character and remove it if it is the null character. Although it is not helpful if a string has a null character at the middle, but I can assume such a case is exceptional.


Feature/home page text

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: robertjf sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Does not work with Microsoft ISA Firewall Client for ISA Server

Requests does not work if I try to use it in a corporate network with Microsoft ISA Server when I use ISA Firewal Clent. I do not set any proxy settings, but requests despite it have looked proxy. This behavior has been defined by default for trust_env in the module sessions in the line range 423-427 (https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L423).
proxies = proxies or {}

        # Gather clues from the surrounding environment.
        if self.trust_env:
            # Set environment's proxies.
            env_proxies = get_environ_proxies(url) or {}
            for (k, v) in env_proxies.items():
                proxies.setdefault(k, v)

In my network function get_environ_proxies returns a list of proxy servers, and it does not work for me. For correct work via ISA Firewal Clent, dict of proxies must be empty always.
For example, this behavior prevents to use pip (see https://github.com/pypa/pip/issues/1182#issuecomment-41282819).

@espdev Hi, I've been reading all posts about this problems by you. Followed your instructions but anyhow couldn't make pip install work behind NTLM. :(


Responses not visible

hi Filip, I'm not able to see the responses to the requests in browser

I haven’t been able to reproduce this using the same endpoint:

Can you please tell me which version of the plugin you are running? Do you get any errors to the console? If so, can you please provide them? Thanks!

chrome in 106
  "dependencies": {
    "@bahmutov/cy-api": "^2.2.1",
    "cypress": "^10.9.0",
    "cypress-plugin-api": "^1.2.2"
  }

in the console there are no errors

hmm I am wondering if there may be some conflict between my plugin and @bahmutov/cy-api. I used the same command name and some of Gleb’s tricks. Can you try to uninstall (or simply remove it from support file) and try again?

I just reproduced it. If you have @bahmutov/cy-api plugin installed, it creates a conflict. Is there any reason you want to keep both?

No reason, I removed @bahmutov/cy-api and it worked perfectly, thank you very much Filip :)


add "--include pattern" "--exclude pattern" to libdoc

The use case is more or less the same as in #430
Adding these arguments libdoc should be much more straightforward that the implementation discussed in #430.
Usage:

for example all private keywords start with an underscore e.g. _my_private_kw
run python -m robot.libdoc --exclude _* my_resource.txt my_resource_doc.html
my_resource_doc.html contains documentation for all KWs except the ones starting with "_"

The problem with this approach would be that those keywords would still be usable. I'd rather limit keyword visibility for real than just hide them from docs.
Notice that now when we have keyword tags, actually implementing #430 shouldn't be that hard anymore. We could, for example, use a tag like robot:private to mark keywords private. Better continue this discussion in #430, though.


Add support for outputting integers as hexadecimal

When using serde to serialize a data structure containing integers (u32, i16, etc) to TOML format, I would like the fields to be written in the generated TOML file in hexadecimal format. TOML format supports hexadecimal numbers, and this feature would make it easier to read fields such as 32-bit addresses. This may could be an option such as #[serde_with_format = "{:0X}"] above integer-type fields.

Some prior discussion at #781.
I don't see us supporting customization of formatting through serde.  Serde doesn't natively support it.  To support this, we'd need a newtype that serializes to a struct that toml recognizes as an integer with formatting.  We'd support deserializing from either the struct or a number.  This has some odd cases in serde, particularly that its not compatible with any other serialization format.  Not just that the formatting gets ignored but that the number won't be sererialized correctly.
We can support this in toml_edit and people could deserialize to a DocumentMut and then apply a custom formatter.  We'd just need to work out the API for customizing an integer's repr.


covalent modification?

Hi,
Thanks a lot for the wonderful work. I noticed that 'covalent modification' is possible to predict using chai and I know there isn't any example yet, but is there a place (or places) where I might be able to add code so that I can use the feature?

We currently support specifying covalently modified residues by specifying their CCD code. For example, if you had some sequence ...RKSDE.. where the S is actually a covalently modified phosphoserine (https://www.rcsb.org/ligand/SEP), you can specify as input ...RK(SEP)DE.. where SEP is the CCD code for the modified residue.
Let us know if you have further questions!

That's great! Any plan to add something like covalent docking?

"Another notable limitation is that Chai-1 can be highly sensitive to modified residues. Removing modified residues from a sequence that natively posses them or replacing modified amino acids with their standard amino acid analogs can cause large changes in predicted structures. We hypothesize that this is because Chai-1 has been trained explicitly on structures with modifications and relies on this information to accurately predict structures. More plainly, those same amino acid sequences without modifications might be considered to be entirely different inputs."
Is this paragraph referring to post-translational modification? Have you tried to benchmark with structures in PDB for the same protein with and without PTM?
In this paper from 2012: Post-translational modifications induce significant yet not extreme changes to protein structure, they showed that for structures solved with phosphorylation and acetylation in PDB, there seem to be not much conformational change. Thus, I thought the model would be biased towards not predicting conformational change induced by PTM consider the PDB database is biased towards that.

Yes, this paragraph is referring primarily to post-translational modifications. We saw during model development and debugging that many of the more significant errors stemmed from lack of post translational modifications being specified; however, we have not done thorough, comprehensive profiling of this phenomenon. It's possible that given a more thorough evaluation, we might see changes on a similar scale as those you are describing.
Hope that helps clear things up!

Dear Sir, could u give me an example about using the constraint_context.py to simulate a covalent docking ?

While we don't have a fully worked out code example for these, generating such constraints should be fairly straightforward with a bit of light digging in the code.
For example, if you wanted to ContactConstraint which specifies that a pair of tokens in a complex are within a specific distance threshold, you can provide the following fields in the corresponding constraint, supply that constraint to the ConstraintContext object, and pass that through the example folding code.
https://github.com/chaidiscovery/chai-lab/blob/1ce5045f1a927c748df090ff1abd0ba58699c6b5/chai_lab/data/features/generators/token_dist_restraint.py#L25-L36

Regarding the use of CCD code - If I understand correctly, simulating a covalently bound ligand of choice is only possible if this ligand is already included in some PDB entry, and has a CCD ID. Is this correct? Is there no support at the moment for explicit attachment of a user-defined small molecule to a specific residue? Thanks!

Regarding the use of CCD code - If I understand correctly, simulating a covalently bound ligand of choice is only possible if this ligand is already included in some PDB entry, and has a CCD ID. Is this correct? Is there no support at the moment for explicit attachment of a user-defined small molecule to a specific residue? Thanks!

We just added support for specifying bonds between a residue an an arbitrary small molecule here: https://github.com/chaidiscovery/chai-lab/pull/205. We should be cutting a release soon, or you can install from main to get the feature early!

Great, thanks a lot for the update!
On Wed, Dec 4, 2024 at 7:39 PM Kevin Wu @.***> wrote:

Regarding the use of CCD code - If I understand correctly, simulating a
covalently bound ligand of choice is only possible if this ligand is
already included in some PDB entry, and has a CCD ID. Is this correct? Is
there no support at the moment for explicit attachment of a user-defined
small molecule to a specific residue? Thanks!
We just added support for specifying bonds between a residue an an
arbitrary small molecule here: #205
https://github.com/chaidiscovery/chai-lab/pull/205. We should be
cutting a release soon, or you can install from main to get the feature
early!
—
Reply to this email directly, view it on GitHub
https://github.com/chaidiscovery/chai-lab/issues/110#issuecomment-2518117112,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJJ5NAKTJNEM45JXQS2P4IT2D445HAVCNFSM6AAAAABQAVVTDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJYGEYTOMJRGI
.
You are receiving this because you commented.Message ID:
@.***>


Logic App get Cosmos Collection and Send email

Hi,
I need to use Azure logic app to Query DocumentDB to get the collection details to send email.
However I don't see Input and Output setup under the Query Document.

Any guidance on this?
Thank you

@singloudly90 Is there a specific document that you are referring to here? If so, could you please share it?
Also, please do note that this repository is primarily to address documentation related issues. For all other queries, feel free to open a thread on MSDN or StackOverflow instead.

Hi Pramod, I have solved it, Thanks.


[GLES2] Repeated textures look blurry in HTML5 builds

Godot version:
3.2.3.stable.official
OS/device including version:

The issue happens on HTML5 with GLES2 backend. Tested on Arch Linux with Firefox 83 and Chromium 87.0.4280.88.
Tested on two different computers, one has Intel i5-3320M and the other has NVIDIA GTX 1650 SUPER.
Issue description:
If you set "Repeat" to enabled in texture import settings, the texture will look blurry in HTML5 build, like it has been scaled with aliasing. This causes semitransparent edges and generally blurry look for pixel art.
The issue happens with GLES2 backend, it's not present on GLES3.
How it's supposed to look:

How it looks instead:

Steps to reproduce:

Add any pixel art texture to you project and make sure that you can see it up close.
Disable filtering and enable repeat in import settings and click "Reimport".

Export the project using HTML5 preset.
Run it in your browser. You will likely need to start a local HTTP server like this: python -m http.server --bind <IP_ADDRESS>

Minimal reproduction project: blurred_repeated_pixels.zip
There's already an HTML5 build in the build/ directory.

I can confirm this on Firefox 84 and Chromium 86 (Fedora 33, GeForce GTX 1080).

Can either of you try with high precision floats enabled?
https://docs.godotengine.org/en/stable/classes/class_projectsettings.html#class-projectsettings-property-rendering-gles2-compatibility-enable-high-float-android

@clayjohn Just tried it, it doesn't fix the issue.

Always try this kind of thing with and without batching BTW as that can help pin it down. It is probably due to wrapping with a non power of two texture. Top tip, use POT textures on HTML5 / mobile, especially when using any kind of wrapping.
I'll see if I can reproduce. :+1:

@lawnjelly Can confirm that using a power of two texture fixes the problem! Ironically, all textures in my project were power of two except for repeated ones. :man_facepalming:

@larsonjj Is it a driver issue or can it be fixed within the engine? GLES3 doesn't have this problem.

GLES3 mandates non POT texture support, GLES2 does not. Hence hacky workarounds are used on GLES2 which may look bad and run like a dog. But you can avoid this problem by just using POT textures.

I wonder if our POT codepath accidentally forces texture filtering.
@theogen-ratkin can you compare the texture displaying the issue with filter on and off?

@lawnjelly Oh I see. I agree that it's better to just adhere to the standard, but I think it would be nice if Godot had some fallback option. Maybe resize textures at export time?
@clayjohn No, with filtering the texture looks completely blurry. But you can see that the situation is the same: original image is consistent in color, the second one has semitransparent edges.

What you are seeing is the fallback option

Fair enough! I just think that it can really hurt Godot's adoption, since people coming from, say, Unity, expect things to "just work" the same on all platforms, no matter what you throw at it. And even though there's Vulkan, GLES2 is not going away anytime soon.

Hence hacky workarounds are used on GLES2 which may look bad and run like a dog.

What kind of workarounds? Are they really so bad? If so, we could make those workarounds optional, so that developers could decide for themselves if they want them.

We do resize the texture at load time https://github.com/godotengine/godot/blob/6956b01cb55a082440df044211c2e86427b6c62c/drivers/gles2/rasterizer_storage_gles2.cpp#L677-L686
I'm guessing that the blurriness is actually caused by the resize rather than the custom repeat shader code.

@clayjohn If that's the case then it's great! I thought that it looked like it just has been resized with filtering.

This can be solved by passing in the textures filter setting to the resize_to_po2 code. We just need to add an optional boolean p_filter to resize_to_po2.

I might do this and send a PR request, I wanted to contribute to Godot for some time now.

I wonder if our POT codepath accidentally forces texture filtering.

This is possible. It sets the conditional CanvasShaderGLES2::USE_FORCE_REPEAT which may be causing a rebind and losing a filtering state. A graphics debugger would show this if we faked lack of non-pot support on desktop.

What kind of workarounds? Are they really so bad? If so, we could make those workarounds optional, so that developers could decide for themselves if they want them.

Wrapping in the fragment shader. Yes, depending on the hardware. You can't really make them optional, unless you mean crash, display garbage, or display a black texture or something, if you are asking the hardware to do something it can't do. A GPU isn't like a general purpose computer (at least not GLES2), it has a limited set of functions.
It's kind of like asking a car to fly. Maybe you'd seen Elon Musk with a flying car, but you want to try it on your car. It can't fly, so it fakes it by displaying some sky on the windscreen as a workaround. You're not satisfied with the workaround, you turn it off and insist on it flying, you drive it off a cliff, and that won't go so well. :scream:
What you can do is display a warning to the user to tell them they are doing something that could be problematic. This hasn't been implemented. So you try and put your car in fly mode, and it bleeps at you and puts up a message saying WARNING! can't fly etc. :smile:

We do resize the texture at load time

Ah that does explain it. But then there is no need to do the wrapping in the fragment shader. So the current arrangement is not good. Resizing the texture is preferable to the fragment shader approach imo.

We just need to add an optional boolean p_filter to resize_to_po2.

@clayjohn Wouldn't it be better to add a p_interpolation parameter like in resize() so that we could choose from all Interpolation members?
void resize_to_po2(bool p_square = false, Interpolation p_interpolation = INTERPOLATE_NEAREST);
void resize(int p_width, int p_height, Interpolation p_interpolation = INTERPOLATE_BILINEAR);

I tested resize_to_po2 with INTERPOLATE_NEAREST and it's noticeably better, almost perfect, but you can see that it's stretched vertically a bit (since the image is resized from 512x104 to 512x128). Maybe this could be fixed by adding empty spaces to image, so that its aspect ratio is preserved?

@theogen-ratkin

Wouldn't it be better to add a p_interpolation parameter like in resize() so that we could choose from all Interpolation members?

Yep. Good suggestion.
Also, when calling from rasterizer_storage don't forget that it will always have to be nearest. I was wrong to say you should switch between linear and nearest.
Regarding adding padding. I think stretching is a better result. Sure, it won't be good for pixel-perfect assets, but when using pixel perfect assets you need to be more careful designing them anyway. The majority of assets will be better off with a bit of stretching. And as you rightly point out, you would introduce space on wrapping and black bars.

@clayjohn
Yes, good point about stretching, I guess it should be up to developers to make sure that textures are sized properly.
I have just sent pull request #44445 with my changes to resize_to_po2().

Fixed by #44460.

Awesome! Thanks for letting me make my first contribution to Godot!


Update Spark dynamicAllocation.maxExecutors to use a proper node attribute

Builds on #747
Also fixes 4 space issue and conveniently ignores other Foodcritic/Rubocop issues.

Luckily for us, we run an ancient version of Chef, so the dotted notation still works. I'm closing this, since the original requirement was met by the first PR.


Unable to pass limit as parameter for oracledb

Please first make sure you have looked at:

Documentation: https://github.com/mkleehammer/pyodbc/wiki
Other issues

Environment
To diagnose, we usually need to know the following, including version numbers.  On Windows, be
sure to specify 32-bit Python or 64-bit:

Python: 3.8 (64bit)
pyodbc: 4.0.32
OS: Windows
DB: Oracle
driver: NatezzaSQL

Issue
Often it is easiest to describe your issue as "expected behavior" and "observed behavior".
I'm unable to pass limit as a parameter.
cursor.execute('select * from students where name=? limit 10','ash') works.
But both
cursor.execute('select * from students where name=? limit ?,'ash',10)  and
cursor.execute('select * from students where name=? limit ?',('ash',10))
do not work, what gets executed is 'select * from students where name=NULL limit NULL'.
I've tried passing 10 as a string and float to no avail.

Could you post an ODBC trace?
This seems like it might be an ODBC driver limitation. It's not unusual for a driver to not support parameterising arbitrary parts of queries.


[SILGen] In gen'd handlers, open optionals first.

When synthesizing completion handlers passed to ObjC methods which are called-as-async of the form
- (void)performWithCompletionHandler:(void (^)(void (^ _Nullable)(void), NSError * _Nullable, BOOL))completionHandler  __attribute__((swift_async_error(zero_argument, 3)));

on the success path, the first argument is unwrapped.
Previously, that unwrapping was done after the bridging from ObjC to Swift.  For simpler values like NSString *, that worked fine.  However for more complex values like block types as here, bridging from the optional ObjC type to the non-optional Swift type failed.
Here, the order of operations is reversed and the unwrapping is performed first.
rdar://81590807

@swift-ci please test

@swift-ci please test

Hm, does this defeat the special handling of null bridging for types like NSString, where we intentionally map nil to empty "" String in this case?

@swift-ci please test

@swift-ci please test

(For cross-referencing purposes, the behavior was changed in a force-push to preserve the behavior and is tested at https://github.com/apple/swift/pull/38773/files#diff-154a8dcf6adb593e4e77f29be44041d0ccc9ef9546fd0ef6bdb56dcb51119d87R34 .)


Why not allow upload object by file name

When i upload new object that http://localhost:3000/object/test.tng
The reponse show
{
"error": "id is not valid"
}
I think we should allow create object by file name and path ( prefix ) like s3

@thino-dev Hey! Thanks for your comment. Indeed, an objectID can only contain alphanumeric characters as of now.

name and path

When it comes to "path", it's tricky in terms of consistency. How would you expect the objects with the same prefix to be stored? Shall they be distributed across the cluster, or shall they be stored in "atomically": a single directory (prefix) = single storage instance?


Unable to connect to remote server:

Unable to connect to remote server: com.vecsight.dragonite.sdk.exception.ConnectionNotAliveException: Connection is not alive

Are you using proxy or forwarder? What is your configuration? Did you install any firewall? Please provide more details.


Training steps.

Hello,
Thanks for sharing the code, i wonder if there is a documentation for how to train and use qtrader,
i used source/setup.sh and got things installed but i don't know how to go any further
Regards

Wondering the same. How do you train and use qtrader ? All i see is a couple of tests . Second question, Where is the Online nature of Qtrader ? it looks to me that its basically trained offline and tested offline . Is there an actual real-time online training of incoming real-time data  which is then trained?

Thanks for your excellent work. I have the same concern. This seems no script or codes training the dqn agent. there is dqm.yaml  however it seems no script use it


Upgrade to Babel 6

Babel must be upgraded ASAP to 6 as every single example using Babel fails with TypeError: (0 , _typeof3.default) is not a function (see https://phabricator.babeljs.io/T6644). The fly-babel package requires * version, so it requires Babel 6, and it seems there is a conflict between babel-runtime and fly-babel not being the same Babel version. Or maybe I don't get a thing?

Nevermind, fly itself from npm is broken because of Babel 6. Just clean install from npm, and try to run fly -h. It fails with:
node_modules/fly/node_modules/babel-runtime/helpers/typeof.js:14
  return obj && typeof _symbol2.default !== "undefined" && obj.constructor === _symbol2.default ? "symbol" : typeof obj === "undefined" ? "undefined" : (0, _typeof3.default)(obj);
                                                                                ^

TypeError: (0 , _typeof3.default) is not a function

Same as my comment above, the package.json of the latest npm version requires Babel 6. @bucaran, maybe it's time to push a newer version to the registry, as the package.json in this repo explicitely uses Babel 5, it would fix the issue.

I will try to do that to fix the build ASAP and concentrate on upgrading to Babel 6 later on then.

Yup, by the way, thanks for this great tool! Let me know if you want me to test anything.

fafd2a2fbd192fc1c82edf004da47399fab5d558
Still need to upgrade to Babel 6.

Great, it works now. I can upgrade to Babel 6, I just did on my side. Will submit a PR soon.

Thanks! Can't wait to merge that :smile:

I think we can close this.
@marvinroger @iamstarkov

Everything is upgraded, so yes. :+1:


Question regarding permissions

I want to use Nadeko as a way for my Discord Moderators to assign ranks to people, that way I have log of the Nadeko bot saying that X assigned Y rank to Z. But, it requires the Manage Roles rank, is there a way around it?
Else this command would be useless, as they can give the rank anyway

I don't think so... It is meant that commands like these suppose to follow server specific permissions, otherwise it's not that it will get useless, but it will get over-abused a lot by anyone on any server.

I was hoping there's an "add mod" command somewhere and I've missed that checks if user is part of X group, and if so unlocks the specific command.
Perhaps for future implementation? For now I sadly will have to find another bot to do this. :/

This is the one "flaw" with the permissions system. In what situation would
you give someone manage roles on discord but deny them the command in
nadeko. I really wish there was a nadeko permission mode to ignore server
perms so I can explicitly allow moderation commands ignoring discord perms.
This would be more auditable and controllable until discord audits come
out. currentyl I see no use for createrole, addrole, assign role, kick,
ban, or other such command through nadeko.
On Fri, Apr 21, 2017 at 9:38 AM Konkz<EMAIL_ADDRESS>wrote:

I was hoping there's an "add mod" command somewhere and I've missed that
checks if user is part of X group, and if so unlocks the specific command.
Perhaps for future implementation? For now I sadly will have to find
another bot to do this. :/
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Kwoth/NadekoBot/issues/1191#issuecomment-296192979,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABGad1ulY9RZ3qXvGS5h9yxgtsdi0zCAks5ryLFpgaJpZM4NETru
.

And while we're at it. if .logserver is enabled it should log use of
administration commands in the log rather than just the fact someone
received a role or other kind of thing.
On Fri, Apr 21, 2017 at 11:14 AM jon donigian<EMAIL_ADDRESS>wrote:

This is the one "flaw" with the permissions system. In what situation
would you give someone manage roles on discord but deny them the command in
nadeko. I really wish there was a nadeko permission mode to ignore server
perms so I can explicitly allow moderation commands ignoring discord perms.
This would be more auditable and controllable until discord audits come
out. currentyl I see no use for createrole, addrole, assign role, kick,
ban, or other such command through nadeko.
On Fri, Apr 21, 2017 at 9:38 AM Konkz<EMAIL_ADDRESS>wrote:

I was hoping there's an "add mod" command somewhere and I've missed that
checks if user is part of X group, and if so unlocks the specific command.
Perhaps for future implementation? For now I sadly will have to find
another bot to do this. :/
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Kwoth/NadekoBot/issues/1191#issuecomment-296192979,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABGad1ulY9RZ3qXvGS5h9yxgtsdi0zCAks5ryLFpgaJpZM4NETru
.

I am for the moderation by bot (I use a different tool which does that for moderation and fully disable the moderation commands essentially on Nadeko personally), and yes it was discussed a lot, but it requires a very large rewrite of the system as it is.
Then pushing that to users is a challenge afterwords. There is too much right now on the plate to do that this moment, unfortunately. And yes, logs don't store the information like who banned who because, in order to strictly do that, the permissions would have to be rewritten as mentioned above and make users utilize the bot for moderation (kick, ban, etc.) - otherwise if a user has regular kick/ban privileges they don't have to use the bot and the bot can't record who did what actions if it's done by the user directly via. Discord.

"otherwise if a user has regular kick/ban privileges they don't have to use
the bot and the bot can't record who did what actions if it's done by the
user directly via. Discord."
which is why the kick and ban commands are pretty useless.
On Fri, Apr 21, 2017 at 11:22 AM Shikhir Arora<EMAIL_ADDRESS>wrote:

I am for the moderation by bot (I use a different tool which does that for
moderation and fully disable the moderation commands essentially on Nadeko
personally), and yes it was discussed a lot, but it requires a very
large rewrite of the system as it is.
Then pushing that to users is a challenge afterwords. There is too much
right now on the plate to do that this moment, unfortunately. And yes, logs
don't store the information like who banned who because, in order to
strictly do that, the permissions would have to be rewritten as
mentioned above and make users utilize the bot for moderation (kick, ban,
etc.) - otherwise if a user has regular kick/ban privileges they don't have
to use the bot and the bot can't record who did what actions if it's done
by the user directly via. Discord.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Kwoth/NadekoBot/issues/1191#issuecomment-296220942,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABGadwz6QDCa34Lx_zYdY1QDF30Z8Btgks5ryMmagaJpZM4NETru
.


Split up usage_example.ipynb into more sub-divisions; improve clarity

I feel like usage_example notebook has grown a bit too long and may be overwhelming for the reader, so it could be split into multiple notebooks - maybe one for colormaps, one for apc.setup + basic example plots, and one for the CVD utils.

Resolved by #30 !


fix: Empty organizer section in Ticket Details (#1308)

Fixes #1308
Changes: hide organizer label when there is no information about the organizer
Screenshots for the change:

No wildcard imports

No wildcard imports

removed wildcard import, please review @iamareebjamal

Please revert unnecessary changes.

done :)


Java version should be bumped to 21

Java was just bumped from 17 to 19 by default in the Nix shell, and from 17 to 19 in the Docker image, but 19 is not a long-term support (LTS) version. We should adopt 21 once it's available as a stable Ubuntu package. For now it's not.

[ ] bump default in shell.nix from jdk19_headless to jdk21_headless (already available in nixpkgs)
[ ] bump Ubuntu package declared in Dockerfile from openjdk-19-jre-headless to openjdk-21-jre-headless

Actually this is necessary since 19 isn't available for Ubuntu 20 in the standard repos


Suggest passing false for disallowed domains, not erroring

The example here to provide a function to allow dynamic origins doesn't behave the same way as when you pass strings, arrays of strings, arrays of regexps etc as the allowed origin.
If you pass an origin function that calls back with an error, the error propagates onwards preventing the route handler that would otherwise be called from being called, and you get an unsuccessful HTTP response.
This has other undesirable side effects like preventing non-browser access to a server (#142 updated the docs to suggest a workaround for this), and preventing same-origin access to a server using the CORS middleware (which there is no workaround for, unless you count including the domains intending to do same-origin requests in the allowed cross-origin list)
If you provide a string domain as the allowed origin, though, and you try to do a cross-origin request from a disallowed origin, the request goes ahead as normal. The access-control-allow-origin header is not included in the response as expected (which prevents the response leaking to scripts on the disallowed origin), but there is no impact on same-origin requests or non-browser access when the module is configured this way.
Which behaviour is the expected one? What I'm getting from the spec is that it's probably the second one, that CORS alone should not be relied on to prevent request side-effects, and a CSRF token should be passed in these cases.
This pull request updates the documentation to suggest calling back with (null, false) instead of an error, to bring the behaviours between the different configurations more in line, and remove the need for cases like non-browser access to need special workarounds.

@AbhishekBiswal since this PR is removing the section you added, can you review this for your use-case?

Here is a more complicated example. In my case I need to allow:

Requests without an origin (i.e. non-browser requests)
Requests from the specified origin(s)
In the development environment, requests from localhost (on any port).

  const corsOptions = {
    origin: (origin: string | undefined, callback: (err: Error | null, allow?: boolean) => void) => {
      const allowed =
        !origin ||
        config.http.corsAllowOrigins.indexOf(origin) !== -1 ||
        (config.http.corsAllowLocalhost && origin.startsWith('http://localhost'));

      callback(null, allowed);
    },
  };

is this still being looked at? It is probably a bit undesired for the example code to cause a 500 on a blocked origin.

@lucaspiller origin.startsWith('http://localhost') is insecure, since it also allows origins like http://localhost.attacker.com.


Support for YOLOv8 based models

Using the ultralytics library directly.
Use case for me is a custom model that I trained based on the YOLOv8 model and only afterwards realized that thats not supported (yet) in doods2.
In my hands, this is working locally using the web UI. End goal would be to expose it to home assistant through your fantastic hassio add-on, which obviously is much easier if this gets to "mainline"...

Wow, just yesterday I coincidentally started to build something similar to doods2 for YOLOv8, but then today noticed there's a PR here already!  How convenient 😄
I did notice this commit over in @turley 's repository though and wanted to ask:

You've labeled this detector as YOLOv8 versus turley's Ultralytics.  Is there actually anything YOLOv8-specific about this detector, or could I use it to test out e.g. YOLO-NAS or YOLOv9?  If it's not v8-specific, would it be reasonable to rename yours to Ultralytics?
I don't understand the code as well as the two of you since I haven't been working with it, but as far as I can tell your changes are functionally equivalent with the exception of the inclusion of halfPrecision for "old AMD GPUs".  Is it reasonable to try to include that config just in case?  I'm not trying to PR-snipe turley or anything, but your changes are more up-to-date and active.

(My end goal is to add a doods2 detector type to Frigate so I can use doods2 as a backend for object detection there since it has better model support)

Alright, I'm having some trouble getting this to run.  I needed to add:
import odrpc
import logging
import torch

to yolov8.py to get it to start trying to load the detector.  But I'm trying to load a local model like this:
detectors:
    - name: yolov8s
      type: yolov8
      modelFile: models/yolov8s-oiv7_full_integer_quant_edgetpu.tflite
      labelFile: models/oiv7_labels.txt

And it's not working.  First because it seems to be trying to load the file from Torch Hub (and doesn't support local files), so I modified that and now it's having some issues with the labels.
How is your config set up that it's working?

Do you think it should just be called yolo instead?

They technically have other models available as well (like FastSAM and RT-DETR): https://docs.ultralytics.com/models/
Since this detector is specifically using the ultralytics library (module?) to load/interact with the models, I think it should probably end up having support for anything that library supports.
If there ends up being yolo-specific optimizations at some point though, maybe yolo is a better name.  I guess it'll still support non-yolo models even if that's it's name.

Oh, also, thanks for the merge!  I'll probably have a PR tonight if I can get it to work on my machine.

I did notice this commit over in @turley 's repository though and wanted to ask:

I wasnt aware of @turley 's work on this.

You've labeled this detector as YOLOv8 versus turley's Ultralytics.  Is there actually anything YOLOv8-specific about this detector, or could I use it to test out e.g. YOLO-NAS or YOLOv9?  If it's not v8-specific, would it be reasonable to rename yours to Ultralytics?

Sure, my intention was to separate it from the YOLOv5 support through pytorch, but YOLO or Ultralytics make sense to me too...

I don't understand the code as well as the two of you since I haven't been working with it, but as far as I can tell your changes are functionally equivalent with the exception of the inclusion of halfPrecision for "old AMD GPUs".  Is it reasonable to try to include that config just in case?  I'm not trying to PR-snipe turley or anything, but your changes are more up-to-date and active.

I went with a MVP approach to get the functionality in place that I needed for my usecase. Aditional functionality and improvements are great!

Alright, I'm having some trouble getting this to run. I needed to add:
import odrpc
import logging
import torch

to yolov8.py to get it to start trying to load the detector. But I'm trying to load a local model like this:

Thats odd, could it be that you are not using the last commit? I had pushed a version on my repo that did not import odrpc and had some usage of torch left, but the final version in this PR imports odrpc and logging and does not need the torch import...

detectors:
    - name: yolov8s
      type: yolov8
      modelFile: models/yolov8s-oiv7_full_integer_quant_edgetpu.tflite
      labelFile: models/oiv7_labels.txt

This is the config I used:
detectors:
    - name: yolov8
      type: yolov8
      modelFile: /share/best_20240721.pt

i.e. a local .pt file and no separate labels file

I may switch it to Yolo

Whatever makes most sense to you!

I had pushed a version on my repo that did not import odrpc and had some usage of torch left

That must have been it, because I checked out the code after the merge and it runs just as expected!  Thanks for your work on this!
(I made some changes to add tflite support, but my Internet went out while I was writing up the PR...  Hopefully in the morning.)

I rebuilt the latest docker images... I just called the detector YOLO.

Great! will test. Is there any convenient way to force the hassio addon to be rebuild based on the new doods image?

Ok... On the plugin page in home assistant, there is a very convenient "Rebuild" button...
That I found after fiddling around with the commandline and pruning 30 GB of old docker images and its cache...
Now my custom YOLOv8 works flawlessly with doods2 in home assistant.
Thanks for the quick response and for making the doods2 framework available!


Router context for composables

Hey,
Thanks for this library this is just what I was after.
One of my composables uses useRouter() to navigate after processing the logic:
const router = useRouter()
router.push(...)
When I run the unit tests I get the error:
 Cannot read property 'push' of undefined
How can I make the test aware of the router?
Thanks!

Hey James, i've managed to test vue-router inside composables using this approach.:
import { mount } from 'vue-composable-tester';
import { useRouter } from 'vue-router';
import useMyComposable from '@/use/useMyComposable';

jest.mock('vue-router', () => ({
  useRouter: jest.fn(),
}));

describe('useMyComposable', () => {
  it('should navigate to myPage', () => {
    // create a mock function
    const pushMock = jest.fn();
    // add a mock implementation for push() to useRouter
    useRouter.mockImplementation(() => ({ push: pushMock }));
    // mount your composable
    const { result } = mount(() => useMyComposable());
    // execute the method you want to test
    result.mySuperAdvancedMethodThatUsesVueRouter();
    // test if push() has been called
    expect(pushMock).toHaveBeenCalledWith({name: 'myPage'});
  });
});


pvl

Hi!
Just wondered why you had your own pvl implementation implemented? Possibly because the old one in the planetarypy GH org wasn't really Python 3 ready? or kinda-half baked? I think thanks to Ross' upgrades, that should be better now. maybe worth checking, if it's possible to remove a big bunch of code of your repo.

I don't remember why I did that. I think that it was simpler for me, for some reason, and that maybe I also wanted to fiddle with the PVL code, particularly how the output data with structured. I ended up writing a wrapper to PVL that converts the output to a dict() if desired. I didn't realize, at first, that this breaks pretty often because PDS3 allowed duplicate label names at the same level of nesting. I also did not know, at the time, that PVL was being revised.


Can we make changes on the Client side?

Hi
A very cool project and kudos to your skills.
Do you know how can I make changes at the user side  /mail is where the user side login page opens. Do you know the location of the source file?
Thanks

Hi and thanks! Not sure I'm following, what changes do you want to make?

https://<IP_ADDRESS>/mail/ ,
How can I make changes to this HTML file. Do you have an Idea about the source file
Thanks

That is the roundcube web interface and entirely unrelated to this project. This project is a reskin of the mailinabox admin, not the roundcube interface.