[RFC] cli: specify endpoints in a SSH-like way

This is a rather proof of concept implementation of a simple command line interface based on SSH. It allows the invoker to specify binding commands on the command line and these then get executed right after the connection is established. It is still possible to specify more bindings via JSON commands afterwards.
One weak spot might be that it assumes the format of the arguments to be proto:port:proto:address:port, while I believe that the JSON way allows for more formats. This was done to preserve the similarity to SSH, however it will probably make more sense to twist the format away from it, for instance by separating the endpoints by some other character than colon or by splitting these into two CLI flags in parallel with what the JSON interface does. Once this is resolved, it would be nice not to forget to add help and format hints to the CLI options.

Thanks!
Quick additional idea as I'm thinking about it: this could be structured as a separate CLI space (i.e. to keep these options from "polluting" invite/accept) and simply start the underlying fowl invite (or fowl accept) and feed it JSON commands. Maybe "fowlssh" or something? Another possible advantage here: the "forwarding" options will be the same whether you're "invite"-ing or "accept"-ing
Overall, I like the idea a lot: opens it up for direct human use. (The reason I wrote this was for a GUI piece I'm working on, so was concentrating on this as being used via "some other software" by subprocess).

Thank you for your feedback!

Quick additional idea as I'm thinking about it: this could be structured as a separate CLI space (i.e. to keep these options from "polluting" invite/accept) and simply start the underlying fowl invite (or fowl accept) and feed it JSON commands. Maybe "fowlssh" or something?

That was somewhat my original idea, the "feed it the JSON commands"
part. What I did was the next simplest thing after having to run fowl
as a subprocess (I definitely didn't want to do any hacks like have it
send the commands to itself via stdin). It did not really occur to me
that running it as a subprocess is an option.
I understand your point about polluting the CLI space, but I am thinking
that perhaps it might then be good to first decide, how the program
should be structured. This is just an idea, but if you wanted to have a
separate executable for the user interface (such as these SSH-like
flags, so for instance fowlssh as you suggest), then perhaps it would
make sense to move the other options there as well and have the fowl
command communicate exclusively via the JSON commands - no? So even for
allocating the code and other operations.
I was also thinking that it might be good to drop the the accept/invite
distinction altogether as you have mentioned elsewhere that it's really
a symmetric operation and you have only defined these commands because
it may be more intuitive to the user (the code is really the same
anyway). It would then be possible to just run fowl and specify the
code via the JSON interface or request its allocation.
If this hard split was indeed to happen, then it might also be worth
considering whether you want to ship any human-use wrappers or just
concentrate on the JSON interface and let the users to write wrappers
fitting their needs (possibly collecting some common ones in say
contrib subdirectory - fowlssh should really be just a few lines of
shell script) - this would definitely require the documentation to be
updated first.
My thoughts were also in the direction that there may be a flag
disabling the "machine" (JSON) interface and making fowl behave like a
more human-friendly application (you are even mentioning a TUI in your
blog post) and vice-versa. But that would definitely complicate the
program a lot I think, so the "wrappers" way seems more sensible to me
now.

Another possible advantage here: the "forwarding" options will be the same whether you're "invite"-ing or "accept"-ing

Are they not already?

Overall, I like the idea a lot: opens it up for direct human use. (The reason I wrote this was for a GUI piece I'm working on, so was concentrating on this as being used via "some other software" by subprocess).

Yes, my motivation was that I still struggle to put together the correct
JSON command :D. But really, your feedback got me thinking, whether this
really belongs here and whether writing wrappers should rather be left
to the users or at least whether they should be shipped separately from
the main program.

It's totally possible to ship two (or more) CLI programs/commands in one binary.
Your points above are good, too (i.e. perhaps only having "fowl" + JSON, or the "nicer" front-end).
It could still be "one" command (e.g. a fowl daemon is the JSON-accepting subcommand, maybe).
Let me think about this a little further and sketch out a skeleton? I'm not concerned with "backwards compatibility" at this point. I do think it makes some sense to ship the "nice" CLI with this program (although a TUI is probably a separate codebase?). I did actually start a TUI (as well as a GUI) in Haskell.
So, if you're happy to keep sketching in this PR I will merge something-like-it, the only question being how exactly it's spelled (i.e. where the options live, and if there's two entry-points in this codebase or just one).
To clarify:

Another possible advantage here: the "forwarding" options will be the same whether you're "invite"-ing or "accept"-ing

Are they not already?

Yes. All I mean was that this to me means the flags should live at the "top level" fowl -L ... accept instead of like fowl accept -L ...
(I'm leaning towards making fowl the "user-friendly" program, and putting the JSON-accepting thing into like fowl-daemon or something? But, will think more on it today ... thanks!)

regarding fowl accept vs. fowl invite that's already really a "human" thing too (so I do like your suggestion to move that to a JSON command for the command-accepting thing).

It could still be "one" command (e.g. a fowl daemon is the JSON-accepting subcommand, maybe).

Yes, that's what I meant with the CLI flag, but I guess a subcommand
would be cleaner as it would be a major behavioral change.

Let me think about this a little further and sketch out a skeleton? I'm not concerned with "backwards compatibility" at this point. I do think it makes some sense to ship the "nice" CLI with this program (although a TUI is probably a separate codebase?). I did actually start a TUI (as well as a GUI) in Haskell.

Sure, I will be happy to discuss it if you want to. I really opened this
PR more to open a discussion rather than use the code as is, although
for my needs it's currently sufficient.
Ad the TUI: I am not sure that I perceive it as necessary (I haven't
looked at your Haskell code yet though). However what is next on my
wishlist is some permissions system in context of which I believe you
originally proposed the TUI in your blog post. On the other hand, this
should be doable using the plain JSON interface as well, no? And
probably even necessary if the TUI would not be part of the program.

So, if you're happy to keep sketching in this PR I will merge something-like-it, the only question being how exactly it's spelled (i.e. where the options live, and if there's two entry-points in this codebase or just one).

Of course, please feel free to edit this PR as you see fit.

To clarify:

Another possible advantage here: the "forwarding" options will be the same whether you're "invite"-ing or "accept"-ing

Are they not already?

Yes. All I mean was that this to me means the flags should live at the "top level" fowl -L ... accept instead of like fowl accept -L ...

Sorry, I'm still unsure whether you were talking about your idea or my
proposal. In my proposal, the flags already live at top level, so are
the same for accept and invite.

(I'm leaning towards making fowl the "user-friendly" program, and putting the JSON-accepting thing into like fowl-daemon or something? But, will think more on it today ... thanks!)

I still rather have the idea with wrappers in mind and fowl being just
the JSON "daemon". And personally I currently prefer having this named
fowl and using different names for the wrappers, as the "daemon" would
still be the heart of the project. But it's completely up to you of
course.
Speaking of daemons, IPC via socket might also be a nice future feature.

regarding fowl accept vs. fowl invite that's already really a "human" thing too (so I do like your suggestion to move that to a JSON command for the command-accepting thing).

I will try to sketch some of my ideas regarding this into another PRs if
I can find the time. But basically what I originally imagined is that
you could either run just fowl, optionally with the --code-length
flag, which would allocate a free code, or you could run fowl <code>,
which would allocate this code or try to establish connection if the
nameplate was already in use. So here I wasn't really thinking about
doing it completely via JSON, because it's something, that you would
only do once - when running the program. Of course, if you wanted to
have the ability to use multiple wormhole codes for multiple connections
(with different hosts), then it might make sense to make it part of the
JSON interface. But really, even in this case, I would prefer just
running fowl multiple times, else it might get complicated really soon.

However what is next on my wishlist is some permissions system [..]

Yes, I'd like permissions, and yes I imagine it would be some additional JSON messages (because if there is a GUI in front, it will likely want to interact with the user, like "X wants to listen locally on TCP:8080, okay?" or whatever).
For the CLI-based thing I would imagine that one side would include relevant arguments to set  up a listener, while the other side could have args specifying what's allowed there (e.g. "--allow-listen 8080" or similar ... or even "--allow-all" which is what the situation is now).

Speaking of daemons, IPC via socket might also be a nice future feature.

Yes ... although there's some weird security considerations there, and the "mission" of fowl is to let programmers from any language easily play with wormhole + Dilation (so I figured that "stdin + stdout" is easier than opening sockets). The "weird security considerations" are that it's easier to think about the permissions of stdin/out for a subprocess -- if fowl opened a localhost:1234 listener (for example), malicious local programs could race it (i.e. listen on 1234 first, possibly tricking the "parent' program).
That said, a unix-socket could work well here. (and just speak the same JSON protocol).

if you wanted to have the ability to use multiple wormhole codes for multiple connections (with different hosts), then it might make sense to make it part of the JSON interface. But really, even in this case, I would prefer just running fowl multiple times, else it might get complicated really soon.

Yes, :100:, on the same page here: I do have use-cases for multiple connections, but would launch multiple fowl instances. One program, one connection is easy to think about :)
p.s. if you have specific use-cases it would be great to write them down!

Hopefully https://meejah.ca/blog/wizard-gardens-vision puts this in somewhat more context?

Interesting blog post -- do you have an RSS feed set up for the blog?

For the CLI-based thing I would imagine that one side would include relevant arguments to set  up a listener, while the other side could have args specifying what's allowed there (e.g. "--allow-listen 8080" or similar ... or even "--allow-all" which is what the situation is now).

Hmm, so for the CLI app you would need to know all allowed ports
beforehand? If so, it might be another argument for sockets: instead of
keeping fowl as a subprocess, it could print it's socket path and live
on its own. CLI might the just need to be invoked with the path to the
socket (which could be made into enviroment variable, à la ssh-add) and
it could be run multiple times, each time connecting to the same socket.

Yes ... although there's some weird security considerations there, and the "mission" of fowl is to let programmers from any language easily play with wormhole + Dilation (so I figured that "stdin + stdout" is easier than opening sockets). The "weird security considerations" are that it's easier to think about the permissions of stdin/out for a subprocess -- if fowl opened a localhost:1234 listener (for example), malicious local programs could race it (i.e. listen on 1234 first, possibly tricking the "parent' program).
That said, a unix-socket could work well here. (and just speak the same JSON protocol).

I in no way meant a network socket -- that I would be paranoid about
too. I really meant just an unix socket. And indeed, that it would speak
the same JSON protocol was also what I had in mind. It would solve for
instance what I mentioned above, plus it's way more natural to have a
wrapper translating the socket communication to stdin/out if needed than
the other way around.
On the other hand, this could introduce some portability restrictions
which would not be desirable. Does fowl run on Windows at the moment,
actually?

p.s. if you have specific use-cases it would be great to write them down!

I would eventually like to use fowl to interconnect my devices which do
not have a public IP and some of them are constantly on the move. In
particular, I would mainly like to tunnel SSH through fowl. I am hoping
that some NAT traversal/hole punching might be implemented into Magic
Wormhole eventually, as SSH trafficked through the transit relay does
not perform optimally even with compression enabled. At the same time, I
used the Rust implementation (for file transfer, not port forwarding)
which does this and it was really successful in getting a direct
connection.

Interesting blog post -- do you have an RSS feed set up for the blog?

Yes, https://meejah.ca/atom.xml  -- should link it somewhere! (When I did that, Firefox would show an RSS icon in the url-bar .. sadly that is gone now).

Hmm, so for the CLI app you would need to know all allowed ports beforehand

Yeah, in my mind there it was like "human CLI runs the daemon" (and communicates via stdin / stdout).
I don't particularly care about Windows myself, but it would be best if it worked on more systems -- so that points to having the daemon as the "lowest level", with a unix-socket wrapper on top. (This could instead simply be an option to the daemon: listen on unix-socket, or on stdin/stdout -- most general for unix-y OSes I guess would be to enable passing filedescriptors to it).
So, I actually like both of these ideas!
Let's think out loud, then, and assign some provisional names:
fowl: aka "the daemon", the thing we have now basically that "does" the wormhole stuff and speaks a JSON protocol on stdin/stdout
fowl-daemon: runs fowl as a subprocess and listens itself on a unix socket.
fowl-tunnel: accepts a --daemon /path/to/unix/socket option, in which case it speaks through a copy of fowl-daemon. Otherwise, it runs its own fowl. This is where the "ssh-style" port options and stuff that you're interested in live. So, if you give it "--daemon ..." then you can have the "oops, I changed my mind and want another port opened" features. If you don't, then it's one-shot (and yes, you'd have to decide which ports are okay to open etc).
Off the top of my head, I don't have a good way to do the "permissions" side for a CLI like this. I suppose a naive take would be to simply ask "y/n" style questions on the fowl-tunnel stdin (e.g. "other side wants to listen on TCP port 8080, okay (y/n)?"
What about GUI support? Originally I was thinking a GUI would just run "fowl" and interact via stdin/out -- but with the above tools, it could instead be given the path to the unix socket --- which of course opens up a bit of a can of worms we glossed over above: if you have a socket, more than one client can connect (which isn't really true of stdin/out).
For most commands, that's fine. Maybe it's also fine for "permissions" (you basically are just racing then: whichever client answers the question first "wins"?) Still, may take some thinking when finalizing the JSON API if it can have >1 clients.

Use-case: "I would eventually like to use fowl to interconnect my devices which do
not have a public IP and some of them are constantly on the move. "
This sounds like a great concrete use-case! Want to highlight it here, so it's not lost in the noise as much :)

NAT traversal/hole punching ...

I would certainly take PRs attempting this! (Fun fact: I actually used to work on a VoIP appliance that did this -- we thought IPv6 would be long here at this point, making it obsolete -- sadly not the case!)
It seems like the 'state of the art' here is maybe WebRTC .. although unfortunately that suffers from being pretty browser+js specific (and complex, overall: several RFCs worth!). That said, for simple cone NATs there's some easy tricks that work well (I believe this is what the Rust implementation does?)
Anyway, definitely punching NAT pinholes to increase the chances of a peer-to-peer connection would be a good "win" for users (when it works) -- they can always fall back to transit-relay so no worse than currently!

NAT traversal/hole punching ...

I would certainly take PRs attempting this! (Fun fact: I actually used to work on a VoIP appliance that did this -- we thought IPv6 would be long here at this point, making it obsolete -- sadly not the case!)

It's on my mind that I would like to try to implement it some time, but
sadly I don't think it will be any time soon.

It seems like the 'state of the art' here is maybe WebRTC .. although unfortunately that suffers from being pretty browser+js specific (and complex, overall: several RFCs worth!). That said, for simple cone NATs there's some easy tricks that work well (I believe this is what the Rust implementation does?)

I would definitely want to avoid WebRTC for the reasons that you
mention. I believe that indeed the Rust implementation does something
simpler (there is even some discussion in the MW docs) and I would like
to follow its lead if I was to implement it.

Anyway, definitely punching NAT pinholes to increase the chances of a peer-to-peer connection would be a good "win" for users (when it works) -- they can always fall back to transit-relay so no worse than currently!

Definitely. Plus less load on the relay and higher transfer speeds.

I don't particularly care about Windows myself, but it would be best if it worked on more systems -- so that points to having the daemon as the "lowest level", with a unix-socket wrapper on top. (This could instead simply be an option to the daemon: listen on unix-socket, or on stdin/stdout -- most general for unix-y OSes I guess would be to enable passing filedescriptors to it).

I pretty much only care about Windows for the situations, where the
durability fails, which has been the case for me almost always so far,
because then I could ask someone to patch me back through for at least
enough time to re-run fowl. This is also the reason why would like to
implement at least some basic permissions soon.

Let's think out loud, then, and assign some provisional names:
fowl: aka "the daemon", the thing we have now basically that "does" the wormhole stuff and speaks a JSON protocol on stdin/stdout
fowl-daemon: runs fowl as a subprocess and listens itself on a unix socket.
fowl-tunnel: accepts a --daemon /path/to/unix/socket option, in which case it speaks through a copy of fowl-daemon. Otherwise, it runs its own fowl. This is where the "ssh-style" port options and stuff that you're interested in live. So, if you give it "--daemon ..." then you can have the "oops, I changed my mind and want another port opened" features. If you don't, then it's one-shot (and yes, you'd have to decide which ports are okay to open etc).

Personally, I would probably go the flags way for enabling the socket,
rather than different command, simply because I don't like having
multiple executables for similar things. But the way you suggest it may
be way more straightforward to implement with the way fowl is built (i.
e. feeding it stdio rather then propagating CLI options to the program's
core, as we have already discussed above).
I agree with fowl-tunnel, but I think we should focus on the other two
for now as this anybody can throw together rather quickly to fit their
specific needs (at least once the documentation is updated) -- I myself
plan to write a bash wrapper around fowl to emulate the SSH options
suggested in this PR (I will then probably change this PR to adding this
wrapper to contrib, if you agree).

Off the top of my head, I don't have a good way to do the "permissions" side for a CLI like this. I suppose a naive take would be to simply ask "y/n" style questions on the fowl-tunnel stdin (e.g. "other side wants to listen on TCP port 8080, okay (y/n)?"

Yes, that's something along the lines of what I was thinking for now and
I will probably try to do a proof of concept of that.

What about GUI support? Originally I was thinking a GUI would just run "fowl" and interact via stdin/out -- but with the above tools, it could instead be given the path to the unix socket --- which of course opens up a bit of a can of worms we glossed over above: if you have a socket, more than one client can connect (which isn't really true of stdin/out).
For most commands, that's fine. Maybe it's also fine for "permissions" (you basically are just racing then: whichever client answers the question first "wins"?) Still, may take some thinking when finalizing the JSON API if it can have >1 clients.

I think GUI could behave in the same way that you mention for
fowl-tunnel.
Regarding the multiple connections to the socket, it also ocurred to me
whether that might be a problem and my thoughts are exactly what you
write.
Do you imagine one fowl instance could be used my multiple users? Like
say a system daemon to which users of a given machine could connect via
a shared socket and request forwards to some other machine? I do not
consider that a good idea, it seems way beter if, again, everybody just
runs their own instance. In that case, I think we would not necessarily
have to try to generalize the JSON API for more clients and could
probably even rely on the user not attempting to make multiple
connections and if so then that they know what they are doing and what
implications it has (good to mention this in the docs). Better even, we
could try to somehow ensure that there is only one connection at a time
(which could add some unrelated (to fowl's main purpose) complexity
which would then point in the direction of having the socket-stdio
translation in a separate codebase, as you suggest).

Use-case: "I would eventually like to use fowl to interconnect my devices which do
not have a public IP and some of them are constantly on the move. "
This sounds like a great concrete use-case! Want to highlight it here, so it's not lost in the noise as much :)

Let me add that being able to reboot the devices in the meantime (or
carry two of them offline for some time during which the mailbox server
would drop the session) would be a very welcome addition as well, so I'm
really looking forward to Seeds.

Do you imagine one fowl instance could be used my multiple users?

Yes, but moreso by "multiple softwares run by one user" [*].
I brought this up in the context of "why not listen on a socket?" and one reason is "because then multiple things can connect" (you could always reject >1 connections, I suppose, but ... then what if the "intended" software is out-raced by some other). Anyway, lots more issues to consider here -- even if it's a user-owned Unix socket.
[*] -- (To expand on the above) per https://meejah.ca/blog/wizard-gardens-vision it would make sense to have "something like" fowl running (once) by a user, and other applications ("the glue code" from the blog post) use it to set up (or tear down) forwarded streams.
That is, there's ONE "trusted" application that "knows how to wormhole" (including Seeds) and other things can integrate with it via local connections (unix, tcp, whatever) so that the user can place their "connect to peers" trust in this one software. Maybe this model isn't perfect, but I think it's a step better than having every application try to integrate magic-wormhole (for example).

Sorry for the giant delay, I'm taking a stab here https://github.com/meejah/fowl/pull/16 and starting from the "other side", i.e. writing the documentation first...

Sorry for the giant delay

No problem!

I'm taking a stab here https://github.com/meejah/fowl/pull/16

I will take a look.

and starting from the "other side", i.e. writing the documentation first...

I think this is a great approach -- I was initially quite confused by
the documentation when I first started experimenting with this project
as it matched the actual code (such as the JSON messages) very little.

okay, i believe this is represented in the latest release via the --local / -L and --remote / -R options for the human version.
Thanks for the discussion and ideas!

Thanks for the discussion and ideas!

It was my pleasure, thank you too :-)


confirm button doesn't work on iPad iOS 14

Environment
System:
OS: macOS 11.4
CPU: (8) arm64 Apple M1
Memory: 71.36 MB / 8.00 GB
Shell: 5.8 - /bin/zsh
Binaries:
Node: 16.5.0 - ~/.nvm/versions/node/v16.5.0/bin/node
Yarn: 1.22.11 - ~/.nvm/versions/node/v16.5.0/bin/yarn
npm: 7.20.5 - ~/.nvm/versions/node/v16.5.0/bin/npm
Watchman: 4.7.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 14.5, DriverKit 20.4, macOS 11.3, tvOS 14.5, watchOS 7.4
Android SDK:
API Levels: 28, 29, 30
Build Tools: 28.0.3, 29.0.2, 30.0.2, 30.0.3
System Images: android-29 | Google APIs Intel x86 Atom_64, android-30 | Google APIs ARM 64 v8a
IDEs:
Android Studio: 2020.3 AI-203.7717.56.2031.7583922
Xcode: 12.5/12E262 - /usr/bin/xcodebuild
npmPackages:
react: 16.9.0 => 16.9.0
react-native: 0.61.4 => 0.61.4
npmGlobalPackages:
react-native-clean-project: 3.6.4
react-native-cli: 2.0.1
Platforms

issue takes place on ipad, ios 14.6, 14.7, 14.7.1
Versions

Android:
iOS 14.6, 14.7, 14.7.1
react-native-modal-datetime-picker:  6.0.8 and the latest one
react-native-community/datetimepicker:
react-native: 0.61.4
react: 16.9.8

Description
when testing on ipad with ios versions that are mentioned above, confirm button doesn't work after picking the date/time, on iphone it does work but not on ipad.
https://user-images.githubusercontent.com/85952669/131488321-432a04af-21a1-4e4c-a480-4890ce44b302.mp4
Reproducible Demo
<DateTimePicker
          mode="datetime"
          isVisible={visible}
          onConfirm={this._onDateTimeConfirmed}
          onCancel={this._onDateTimeCancelled}
        />

this is the sample code of how I have it in my project, nothing special, and it works everywhere except on iPad. I have tested it with  iOS 14.6, 14.7, 14.7.1, on emulator (ipad pro (12,9 inch) 4th gen, ios 14.0.1) and in browserstack, same result for all of them

@Mariam-K-code-care could you please provide the entire code? We can't help with a single snippet.


CON-4978: fixed count for connect items in export window

before we fired the whole query with 5 joins and get the rowCount
now we use a proper Count-Query
increases loading speed for ExportList from >30s to <300ms for 1M products

Coverage increased (+0.006%) to 41.591% when pulling eef289da552afefdb0e37b478b2f485b38c2bd73 on CON-4978 into 8513365ac55dff21d92f93f29888c5cdd2e26aa4 on master.

Coverage increased (+0.006%) to 41.591% when pulling 59b5d84a0bacdb174e4b4b772a2988f0b0e34bd7 on CON-4978 into 8513365ac55dff21d92f93f29888c5cdd2e26aa4 on master.


move seed increment to low-level functions in feed module

As discussed in #212, moving the seed state increment process to low level functions will allow us to 1) silo issues that arrise due to inter-trial seeding discrepancies to the hnn_core.feed module and 2) design better unit tests that control for this.

Is there any aspect of this issue that is still relevant? cc @jasmainak?

probably not, let's close


don't drop blocks table

this allows running multiple block_writers
in parallel without interference.
changed --tolerate-errors semantics: writer
retries indefinitely during initialization.
Fixes #26.

LGTM


Remove collection content mirroring (PP-415)

Description
We are not using the collection content mirroring functionality anywhere in our production CMs and the settings to support this add additional complexity to collection configuration screens.
Motivation and Context
This was done as part of the work for PP-95.
How Has This Been Tested?

Running tests in CI

Checklist

[X] I have updated the documentation accordingly.
[X] All new and existing tests passed.

Rebased against main, resolved conflicts and added a commit to update this PR to reflect the changes that came in with https://github.com/ThePalaceProject/circulation/pull/1308. Planning to merge if all the tests are green when CI runs.


Can we "tag" images retrieved by the image picker ?

Our app needs to allow a user to pick X photos and/or take photos, and then 'assign' them to a Note.
Is it possible to "tag" a selected image on iOS and Droid via this library, so that later we can query via that tag to display the required images for a given Note ?

This library does not modify image content or meta data. If the image is already in the library you can try matching the url or file name.


Adding I2C component BH1750

#116
Hi, I'd like to try to implement the BH1750 requested in the issue above. I added the component definition, but I'm just starting to implement the driver. I didn't know if I should open the PR here first, and then implement the driver, or if I needed both before opening any PR.
This PR adds the component definition to the Wippersnapper Component library for the BH1750 Light Sensor.
Product Url: https://www.adafruit.com/product/4681

Well shucks, I just realized the sensor I have on hand is the BH1750 and not the BH1745 requested in #116. When I started reading the datasheet, I realized my error. I think if it's reasonable I'd like to finish implementing the BH1750, and then if I can get my hands on a BH1745, I can take a look at implementing that one.

@whatisbyandby  Sure, I agree, let's do what's possible for now.
I am going to close out this PR for now. When you are ready to implement, you may re-open it.


On a mobile phone - can type alphabets in the SRN box (should only be numbers)

Also, in mobile phone, entering something like lajksdalns(10 alphabets) in the SRN box keeps the button inactive but entering something like asdqwe12345 (10 characters, but at least one is letter) makes the button active, which should not be the case

So, Pritam had wanted me to include letters too for future use. Should I restrict to ONLY numbers?


SAA-1086 small change which sorts the endpoints/controllers alphabetically when viewing the Swagger UI.

Snippet below:

Codecov Report
Patch and project coverage have no change.

Comparison is base (225a425) 85.34% compared to head (798353e) 85.34%.

Additional details and impacted files
@@            Coverage Diff            @@
##               main     #513   +/-   ##
=========================================
  Coverage     85.34%   85.34%
  Complexity     2397     2397
=========================================
  Files           295      295
  Lines          8686     8686
  Branches        553      553
=========================================
  Hits           7413     7413
  Misses          992      992
  Partials        281      281

see 1 file with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fix: update endpoint url

Description
Provide description of this PR and changes, if linked Jira ticket doesn't cover it in full.
Checklist

[ ] Tests added and all succeed
[ ] Linted
[ ] README.md updated, if user-facing
[ ] License file updated, if new 3rd-party dependency is introduced

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: bastiandoetsch:x: andrewrobinsonhodges-snykYou have signed the CLA already but the status is still pending? Let us recheck it.


Add options feature from i3wsr

I want to preface this by saying that this project is amazing. Anyway, since i3wsr got some fancy new changes like removing duplicate icons, I decided to mirror the changes to the sway port. The following things have changed:

Refactored the struct Options to Config to add the options:

Default icons
Removing duplicates

Added short aliases for new options
Bumped up the dependencies to latest and cargo package to 1.1.0.
The main README file has been updated to present the new changes.

I have tested the new config settings on my Ubuntu 20.10 laptop and they all seem to be working as expected! That's probably because I pretty much copy pasted @roosta's hard work 😅.

Thanks for the PR! I'm away from my laptop this week so I'll only be able to test on Sunday or Monday. It looks good so I'll probably merge it right away :).


this one is just "completely garbage"

http://xml.web.cern.ch/XML/lgc2/xetexmain.pdf

It seems to render all the wrong characters, and does so with them all overlapping each other.

fixed by #717


UPnP does not honor NAT reflection settings

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
When UPnP adds a port forwarding rule, it does not add a rule for NAT reflection. It does not matter how the system default is set.
To Reproduce

Install UPnP.
Check "Reflection for port forwards", "Reflection for 1:1", and "Automatic outbound NAT for Reflection" under Firewall > Settings > Advanced
Install a Plex server on the LAN. Configure it to allow remote access. Do not check "Manually specify port"
From a browser on the same network the server will show an indirect connection
The created nat rule will not have reflection

# pfctl -sn -a miniupnpd
rdr quick on igb0 inet proto tcp from any to any port = 12345 keep state label "Plex Media Server" rtable 0 -> <IP_ADDRESS> port 32400

Expected behavior
Local clients should have a direct connection to the server.
NAT rules should exist for all interfaces to support reflection, eg:
rdr on igb0 inet proto tcp from any to (igb0) port = 12345 -> <IP_ADDRESS> port 32400
rdr on igb1 inet proto tcp from any to (igb0) port = 12345 -> <IP_ADDRESS> port 32400
rdr on lo0 inet proto tcp from any to (igb0) port = 12345 -> <IP_ADDRESS> port 32400
rdr on wg0 inet proto tcp from any to (igb0) port = 12345 -> <IP_ADDRESS> port 32400

Describe alternatives you considered
Manual creation of a port forwarding rule.
Environment
Software version used and hardware type if relevant, e.g.:
OPNsense 21.1.7_1-amd64
FreeBSD 12.1-RELEASE-p18-HBSD
OpenSSL 1.1.1k 25 Mar 2021

Miniupnpd creates rules within its anchors itself at runtime so it really cannot know about our core settings. The plugin doesn't create rules at all as well.
Cheers,
Franco


fix: Adjust evaluation business logic

Motivation

We want to use the real_last_timestamp (start of next training interval - 1 --> marking end of current training interval) only for plotting the boxes in the heatmap plot. For decisions w.r.t. currently active models this doesn't for. E.g. if the next year in a dataset has no data at the year start, our training interval would extend into this next year and therefore it's model won't be considered for the current evaluation interval.
timetriggers should allow starting a statically defined start point (and not with the first sample), otherwise, the whole schedule is off a couple of days.

Note
Independently of the bug we fix with the start_timestamp in timetrigger, this setting allows us to effectively do pre-training with the first trigger (e.g. in the continous arxiv dataset we have sparse data from 1988 - ~2005). We could simply start the schedule in year 2005, then the first trigger trains on all previous data.

i will wait for integrationtests to run through for this one and then merge

LGTM. I guess in most cases one should set the start timestamp to 0, if they want a neat triggering boundary. But I guess finding the correct setting here is the task of the user.

For continuous datasets with periodic evaluation not necessarily. There you don't really care where it starts and what the exact bounds are, you just care about time proximity.

@MaxiBoether could you kick off a cglm pipeline after merging this? I need a pipeline log file with correct training intervals (not affected by the first sample)


Stratford sub Castle WIL

There are two duplicate entries for Stratford sub Castle.
Please move all search links to the original entry and delete this entry.
Geoff

Done


Master vs Manual

Hi
Is there some reason to keep the two branches mentioned in the title separate?
The A+ official documentation page, https://apluslms.github.io/, points to the master branch of this repo which seems confusing.
BR
Pietari

Removed other branches and master contains now files for liekovarpio (January 2019) release.


Is there a members functionality in grav?

Hi! How do you create members / users in grav. Cant seem to find a create user from the admin page. Is this function not yet available right now?

Creating a User
With Grav , you can now create a user account with the CLI:
$ bin/grav newuser
See: http://learn.getgrav.org/admin-panel/introduction

yes. i have seen the documentation but what if i am creating a web app and i want to create a user from the frontend? like a registration form of some sort.

That kind of functionality is the realm of a plugin. As far as I know there's no such plugin yet. I'll add to my queue to write one core plugin soon.
P.s. for the next time, the best place for questions is the forum http://getgrav.org/forum, issues are best to be used for bug reports.


Turn off the LED

The PowerMate Bluetooth leaves the LED on at low brightness unless it's turned off, also it will automatically disconnect after about 5 minutes.
To fix this, a delay after the connect is needed, to allow the PowerMate Bluetooth to send a Connection Parameter Update Request, after that the LED_VAL_HND (0x29) should be written to 0.
Writing LED_VAL_HND (0x29) before that does not work for some reason.

Discovered this doesn't work good enough yet, it still disconnects after 20 minutes or so, after which you have to wait 10 seconds before it works again.


Binding context

When memoized a function used 'This' word inside this it work correctly and binding memoized function context

Added binding context feature with 93035bd320e3046e45fb004167aec34d402b98da

Added binding context feature with 93035bd320e3046e45fb004167aec34d402b98da


fix(package): upgrade to<EMAIL_ADDRESS>to resolve dep issues

@bromanko @bijanvakili @aowola

Looks like this fixes it.


Text Extractor: Copy text directly instead of running OCR.

Description of the new feature / enhancement
If text selection is enabled in the GUI, opt to perform direct text copying rather than resorting to OCR. This approach is preferable as it mitigates a majority of potential issues including smaller font size and to some specific font styles.
Scenario when this would be used?
In my current screen config, the text is being displayed in Calibri Light 9px height, and remains legible even at 100% scaling. However, OCR continues to yield incorrect results which is unacceptable for a ClearType font.
Supporting information
No response

If you can select the text, then why would you use Text Extractor. Are you unable to copy/paste for some reason? /needinfo


Client fail to upload license file to BrainFrame server running on VM

This is a problem reported by a customer. He has BrainFrame server in a VM running on a Windows machine, and Windows BrainFrame client running on the same Windows machine.
When he attempted to upload the license file through the client, he has an error "Error occered when communicating with the server"

However, he can talk to the server through curl on the same Windows machine.

Then he ran a Ubuntu client on the VM, successfully connected to the BrainFrame server, and uploaded the license file. After the license file is uploaded, the Windows client can also communicate with the server.

Can you have him share his server configuration settings within the BrainFrame client?


Blink effect

Blink effect when new item is added in ngFor array.
It is look like that all items in carousel are reloads and then appears

Yes there is blink effect. This is because on adding items to the array the owl.carousel needs to be reinitialized.

Yeah, it appears that not only they "blink" as mentioned, but also the carousel is being reset back to the first slide.
So even if not considering any Angular here, Owl carousel itself must be initialized anytime a slide is added thus blinking and losing the current active slide index?

so can we add transition when the carousel is reinitialized????

+1 For the transition.. has anybody figured it out so far? Thanks


[FEA] Generalized Adjustment Criterion

Relates to feature https://github.com/py-why/dowhy/issues/402
This PR adds support for identifying generalized (non-backdoor) adjustment sets. Currently it only supports finding a single such minimal adjustment set, but ongoing work to enumerate all m-separating sets in causal graphs will unlock the ability to enumerate all generalized adjustment sets.
The PR roughly adds the following

A new field to the IdentifiedEstimand class to store general adjustment sets (given how ubiquitous the backdoor criterion is I left the backdoor fields alone and created new fields for these general sets)
Support in the auto_identifier.py file's identify_ate_effect() method to compute a general adjustment set to return in an IdentifiedEstimand  object

Finding the adjustment set is all handled in a new identify_generalized_adjustment_set() method

Refactoring to share various utility functions between the backdoor adjustment sets and the general adjustment sets
Unit tests to test a few cases of the generalized adjustment criterion (specifically cases where the backdoor criterion is not met)

If it would be appropriate, I also think it would make sense to add to causal_models estimate_effect() method to support the new estimand, but have not added that in this PR.
References:
Benito van der Zander, Maciej Liśkiewicz, and Johannes Textor. "Constructing Separators and
Adjustment Sets in Ancestral Graphs." In Proceedings of UAI 2014, pages 907–916,
2014.

This PR needs to bump the networkx dependency since the  algorithm wasnt added until release 3.0 (see this PR)

Converting to a draft since it seems some tests are failing, I will reopen once I resolve


Envoy must expose health probes of underlying service

When an Envoy sidecar is injected, the Envoy must preserve the existing health probes configured on the Pod.
Currently - when a Pod w/ health probes is injected w/ OSM Envoy, health probes fail.
Related:

[ ] https://github.com/openservicemesh/osm/issues/2097 Program ip:port combinations as possible host headers in virtual_host.domains for HTTP routes
[ ] https://github.com/openservicemesh/osm/issues/1420 Not working with dapr
[ ] https://github.com/openservicemesh/osm/issues/1975 Failing local service cluster with target port of service

Status Update:  The health probes are merged and will be released with v0.7
There needs to be an extensive test written for this functionality. This will come with: https://github.com/openservicemesh/osm/pull/2269

Status Update:  The health probes are merged and will be released with v0.7
There needs to be an extensive test written for this functionality. This will come with: https://github.com/openservicemesh/osm/pull/2269

@draychev we should also note that this only support HTTP/HTTPS probes, and not TCP probes.

@draychev we should also note that this only support HTTP/HTTPS probes, and not TCP probes.

New (similar) issue: Support for TCP and gRPC readiness, liveness and startup probes #2543

With  #3122  done - we can close this.


Links: Azure PowerShell - Conceptual 5.1.0

@mikefrobbins Looks like all the links were FQDN --> Site Relative, so I can probably run it on all the docs-conceptual folders.  Let me know after looking at this.

Docs Build status updates of commit 5c348c7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-conceptual/azps-5.1.0/release-notes-azureps.md
:bulb:Suggestion
View (azps-5.1.0)
Details

docs-conceptual/azps-5.1.0/migrate-az-2.0.0.md
:white_check_mark:Succeeded
View (azps-5.1.0)

docs-conceptual/azps-5.1.0/new-azureps-module-az.md
:white_check_mark:Succeeded
View (azps-5.1.0)

docs-conceptual/azps-5.1.0/quickstart-migrate-azurerm-to-az-automatically.md
:white_check_mark:Succeeded
View (azps-5.1.0)

docs-conceptual/azps-5.1.0/toc.yml
:white_check_mark:Succeeded
View (azps-5.1.0)

docs-conceptual/azps-5.1.0/release-notes-azureps.md

Line 2583, Column 1: [Suggestion-code-block-indented] Indented code blocks aren't allowed. Use a Markdown code block surrounded by triple backticks (```). NOTE: This Suggestion will become a Warning on 1/29/21.
Line 3823, Column 0: [Suggestion-sensitive-language] Term 'whitelist' is sensitive and should not be used in content or code. Usage: '* Added new sizes to the whitelist of VM sizes for which accelerated networking will be turned on when using the simple param set for '

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

#sign-off


Add pyproject.toml for Custom Node Registry

We are working with dr.lt.data and comfyanon to build a global registry for custom nodes (similar to PyPI). Eventually, the registry will be used as a backend for the UI-manager. All nodes go through a verification process before being published to users.
The main benefits are that authors can

publish nodes by version and users can safely update nodes knowing ahead of time if their workflows will break or not
automate testing against new commits in the comfy repo and existing workflows through our CI/CD dashboard

Action Required:

[ ] Go to the registry. Login and create a publisher id (everything after the @ sign on your registry profile).
[ ] Add the publisher id into the pyproject.toml file.
[ ] Merge the separate Github Actions PR, then merge this PR.

If you want to publish the node manually, install the cli by running pip install comfy-cli, then run comfy node publish
Check out our docs if you want to know more about the registry. Otherwise, feel free to message me on discord at haohao_81202 or join our server if you have any questions!

hey @fexploit, wanted to send a small nudge and ask if you had any questions!

@fexploit, wondering if there's any way we can support you on this PR!


REQ not ACKed

I am trying to send REQ messages in a while loop to a receiver who receives the message and responds with some content. The REQs are not ACKed in my code.
My requester is
while True:
    if received_payload != None:
        print(received_payload)
    payload = "Node,3"
    print('[Sending]', payload)
    lora.send(dst_id=1, msg=payload, pkt_type=lora.PKT_TYPE['REQ']) # Sender's lora_id is 1 and receiver's is 0
    #Check and resend the message
    resend_count = 0
    print(lora.seq_num)
    while (int(lora.seq_num) != 0) and resend_count < 7:
        lora.send(dst_id=1, msg=payload, pkt_type=lora.PKT_TYPE['REQ'])
        print("Resending packet..."+str(resend_count))
        resend_count += 1
    time.sleep(0.05)

The receiver is
while True:
    lora.mode = 'RXCONTINUOUS'

    if received_payload != None:
        count = 0
        resend_count = 0

        try:
            if str((received_payload), 'UTF-8').startswith("Node"):
                print("REQ Message starts with a 'Node'")
                if len(message_list) > 0:
                    print("Sending this node's messages")
                    send_message = "Table,"  + str(message_JSON)
                    print(send_message)
                    lora.send(dst_id=3, msg=send_message, pkt_type=lora.PKT_TYPE['REQ'])
                    print(lora.seq_num)
                    while (int(lora.seq_num) != 0) and resend_count < 7:
                        lora.send(dst_id=3, msg=send_message, pkt_type=lora.PKT_TYPE['REQ'])
                        print("Resending Message..."+str(resend_count))
                        resend_count += 1
                        print(lora.seq_num)

                    if (int(lora.seq_num) != 0) and resend_count >= 7:
                        print("Message sending failed!")
                    else:
                        print("Message sent!")
                else:
                    print("This node's message list contains no entries. Sending nothing back.")

        except:
            print("REQ Message Received But Payload Decode Error")

    sleep(0.03)

The receiver is receiving the REQ messages and is also sending the content. But somehow, the ACKs are not working.
What I found from the debug prints is that the REQ sender does not receive the ACK messages.

I am vacationing, will look after the problem this weekend. Happy Holidays.

I am vacationing, will look after the problem this weekend. Happy Holidays.

Ok. Thank you.

I am implementing the "Retry" mechanism. Will finish it ASAP. Do you mind share the whole send/receive scripts?

I am vacationing, will look after the problem this weekend. Happy Holidays.

Ok. Thank you. Happy holidays.

I have implemented retry mechanism in the library and you can use the new parameter in send function to specify how many times you want the sender to retry if it doesn't hear an ACK packet from the receiver. The new send function has been used in the new sender.py

I am closing this issue because of inactivity.


Update README.md

Per the instructor of How to Code - Simple Data, the course is based on the second edition.

cool

Shouldn't we just link to the site's main page and have people click to get the latest version of the textbook?

The First edition is linked because at the time of writing the second edition did not provide solutions to the problems. Has that changed?

The First edition is linked because at the time of writing the second edition did not provide solutions to the problems. Has that changed?

It does not. Given that’s the entire point of using the older book, should I just close the pull?

Yeah, I think that's the best option. At some point we'll come up with a format that is a little richer and can give more context to each course. At that time we should be able to point out the differences between first and second edition and let students choose. Given space to recommend just one, I lean to the option that gives students feedback.

After getting feedback I am going to withdraw the pull request

Maybe the link should be changed so it's linking from the words "the first edition"?


lines are skipped if the file does not grow for a while

It prints some empty lines after the log file stops growing for a while.

Hey @maolcay,
could you provide more info (frontail version, os) and steps to reproduce.


Can't import ADMX on Intune

Microsoft PowerToys version
0.64.0
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
General
Steps to reproduce

Extract GPO objects
Try to import the ADMX and ADML on Intune

✔ Expected Behavior
ADMX gets ingested properly
❌ Actual Behavior
Error Details
ADMX file referenced not found NamespaceMissing:Microsoft.Policies.Windows. Please upload it first.
If I injest the Windows.admx that is huge, it works, is this behavior intended ?
Other Software
No response

Just checked, that doesn't seem to be used anywhere.
If you remove this line from the admx: https://github.com/microsoft/PowerToys/blob/d234536cf723714a94eb5839abbc97ca38a5c714/doc/gpo/assets/PowerToys.admx#L7
Does it work?

/needinfo

Just checked, that doesn't seem to be used anywhere.
If you remove this line from the admx: https://github.com/microsoft/PowerToys/blob/d234536cf723714a94eb5839abbc97ca38a5c714/doc/gpo/assets/PowerToys.admx#L7
Does it work?

This is a leftover from the first implemtation of version description when we had the windows version.

Will try tomorrow morning and report back.

That indeed fixes it

Fixed in the latest version. Please update PowerToys.


docs(README.md): fix the type of unique

[ ] This is a metadata update

For Bugs and Features; did you add new tests?
x
Motivation / Use-Case
To help other people avoid mistakes.
Breaking Changes
x
Additional Info
x

Please accept CLA, thanks!

@evilebottnawi signed :)


Adding the Stone Paper Scissors Game

Assign it to me

I would like to contribute to this issue.Please assign it to me under jwoc.
@Priyanshi662

there is a similar issue opened #46


KL divergence usage

Hello,
I wanted to test different metrics, but there is something not clear in the documentation and I have not found a working example. For example, the Kullback-Leibler divergence:
import pandas as pd
from qolmat.benchmark.metrics import  kl_divergence
# Create two example Pandas Series
series1 = pd.Series([0.1, 0.2, 0.3, 0.4], colu=['A', 'B', 'C', 'D'])
series2 = pd.Series([0.15, 0.25, 0.35, 0.25], index=['A', 'B', 'C', 'D'])

# Assuming df_mask is a DataFrame with the same index as the Series
df_mask = pd.Series([True,True, True, True])

# Compute KL divergence between the two Series
kl_div = kl_divergence(series1, series2, df_mask)

print("KL Divergence:", kl_div)

This is returning an error, I am not sure what it is meaning mask in this case
Thank your for your help

Hi,
it did work, I have just few additional questions.

The mask represents where there are NA values? Or it is indicating the indexes that have to be taken into account?
It works also with np.arrays?

Thank you very much

Hello, great! The mask represents the values you want to compute the KL divergence on. In our case these are the additional nans which are added during the validation process. If you want to use this function independently of our setting you can adapt the source code, which is rather simple and relies on scipy.stats.entropy.


Bluetooth: Mesh: Missed IV update cannot be captured

It seems that if the IV update is missed, a node cannot
recover it until the IV index has increased to a value
greater than Node's Last known IV + 1.
Signed-off-by: Ingar Kulbrandstad<EMAIL_ADDRESS>

Marked with DNM and Enhancement, as this functionality isn't currently broken, and the change needs some more discussion and work.
The current implementation does not break the spec for the IV update procedure, but it's not very user friendly. The spec is deliberately vague on this point, essentially leaving the IV+1 scenario up to the implementation.
The options permitted by the spec are:

Ignore all non-update IV+1 beacons (current implementation). This ensures that the network will never start galloping through IV indexes because of some broken implementations, but devices that miss out on IV updates because of a power loss will be unable to receive messages from others until the next IV update is triggered by someone else on the network.
Treat this as IV recovery, and just adopt the new IV index, skipping update mode and ignoring the 96H timer altogether. This is the implementation initially proposed in this PR, but this opens up the network to start bumping IV index with no timing limitations, allowing broken implementations to exhaust the IV indexes, bricking the network.
Adopt the IV index if the 96H limit has been met. This prevents IV index galloping, but we'll still have devices being blocked from participating in the network for up to 96H, like in option 1.
Treat this as IV recovery, and just adopt the new IV index, but start enforcing the 192H limit on IV recovery described in section 3.11.6.  This should prevent IV index galloping, and would allow devices to recover immediately in most scenarios. The implementation for this is a bit more complex though, and we have to decide whether the 192H limit be stored persistently, or be reset between power cycles, so devices with frequent power loss could always get back into the network.

After a call between @Balaklaka, @alxelax, @omkar3141 and @trond-snekvik, we figured that option 4 is likely the most usable interpretation, but the implementation details aren't quite clear. Since the current implementation is passing qualification, and not breaking the specification, we decided to not push this into 2.7, and instead revisit after code freeze is lifted, so we can do a proper implementation.
cc @LingaoM and @jhedberg

@trond-snekvik - are you able to review?

Should this also be stored persistently? Devices that keep power cycling will not be able to keep track of this limit with this implementation. If this can be made into a flag, it might be pretty cheap to store

This should not be stored persistently that is the central point here. We discussed this in detail in the past. The point is to allow the device which has missed the IV update and got rebooted (i.e. went offline for several hours) to recover IV. The device which reboots quickly will not fall into this condition because its last known IV will be in sync with the network.


Transfer encoding headers not used

@dimrozakis raised the following issue:
chunked_headers isn't being used, the subsequent request uses the original headers. Also, according to requests' documentation on chunk-encoded requests, passing an iterator is all that's required so it seems like Transfer-Encoding: chunked is taken care of automatically by requests.

chunked_headers isn't being used, the subsequent request uses the original headers

Addressed with a8426098bf10c893366be9043bc3366a47c22b48

Also, according to requests' documentation on chunk-encoded requests, passing an iterator is all that's required so it seems like Transfer-Encoding: chunked is taken care of automatically by requests.

I prefer the headers to be specified explicitly.


Flatten json output for tcp-outlet delete command

Current behavior
The json output format for tcp-outlet delete is not correct because it has an unnecessary nested level.
Desired behavior
The tcp-outlet key should be removed so that the command outputs a flat object.
Implementation details
The following line should be modified to produce the described output:
https://github.com/build-trust/ockam/blob/751d8d9ca9a615214518d0cf935c22de37627416/implementations/rust/ockam/ockam_command/src/tcp/outlet/delete.rs#L74

Some tips for newcomers:

Create a new branch for the issue you are working on (don't push directly to your fork's develop branch)
Run cargo fmt. You can configure the editor to run it automatically everytime a file is saved
Run cargo clippy to make sure the code compiles + follows rust standards/best practices
You don't need to keep your branch updated with develop until there is a merge conflict. If you still want to update it, use git rebase develop instead of gir merge develop

We love helping new contributors! ❤
If you have questions or need help as you explore, please join us on Discord. If you're looking for other issues to contribute to, please checkout our good first issues.

@adrianbenavides, I would like to work on this, kindly assign this issue to me.

@nabeel001 That's awesome, this is all yours. Please let us know if you have any questions as you explore. You can also ask questions on the contributors discord https://discord.gg/RAbjRr3kds

@nazmulidris I have raised the PR for this issue through #6602 and also added my name to CONTRIBUTORS.md through #6616


Change class components to functional components

Changing some simpler components

Hey @Andre-rsfc, thanks for you contributing!
To maintain code standardization, I think this partial migration is not the best way.
Would you like to work on migrating all other components or would you rather close this PR?

👍


[Storage] Support container soft delete

Description

Support container soft delete, which is supported in storage-blob-preview extension before
Testing Guide

az storage container list with --include-deleted
az storage container restore
History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change.
[Component Name 2] az command b: Add some customer-facing feature.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Storage


Radix Sort | C++

Title - Radix Sort
what will change -
Type of Issue -
Please add/delete options that are not relevant.

[x] Adding New Code
[ ] Improving Code
[ ] Improving Documentation
[ ] Bug Fix

Programming Language
Please add/delete options that are not relevant.

[ ] Python
[x] C++
[ ] Java
[ ] C
[ ] Go
[ ] Other language

Self Check

Ask for issue assignment before making Pull Request.
Add your file in the proper folder
Clean Code and Documentation for better readability
Add Title and Description of the program in the file

:star2: Star it :fork_and_knife:Fork it :handshake: Contribute to it!
Happy Coding,

I am interested in implementing this. Can you please assign it to me?

Hi, I can implement this in a couple of hours. Let me know if it is up for grabs.


TST: add more tests for new query_items

Another follow-up on https://github.com/Toblerity/Shapely/pull/1112. Some aspects of the new query_items were not yet covered in the tests:

constructing the STRtree with explicit items sequence + using query_items without providing explicit items (so using a default enumeration index then)
testing that the returned item is still correct if some geometries were dropped before constructing the GEOS tree

Coverage remained the same at 85.286% when pulling 10a5553958bff80f72a21a7ee42828c6224696fc on jorisvandenbossche:strtree-tests into a2288360b5b4664f645199a7a605c3a062e426eb on Toblerity:master.


Test merge maint 1.8 master

Tests pass on my macbook but it looks like I have some appveyor and travis work to do.

@sgillies If it is ok for you, I should have some time to look at it tomorrow.


SyntaxError crash

Hi, I'm getting a SyntaxError crash when running vtop, the error message is as follows:
evalmachine.<anonymous>:2
<EMAIL_ADDRESS>| MIT | deps: 10 | versions: 47
^

SyntaxError: Invalid or unexpected token
    at new Script (vm.js:74:7)
    at createScript (vm.js:246:10)
    at Object.runInNewContext (vm.js:291:10)
    at safeEval (/usr/lib/node_modules/vtop/node_modules/safe-eval/index.js:13:6)
    at /usr/lib/node_modules/vtop/upgrade.js:25:24
    at ChildProcess.exithandler (child_process.js:273:7)
    at ChildProcess.emit (events.js:182:13)
    at maybeClose (internal/child_process.js:947:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:236:5)

This is caused by breaking changes in npm@6 CLI API.

Last night I was able to reproduce this with the same setup as @vinkla, but I upgraded both Node and npm, and now everything works.
macOS 10.13.4
node v10.1.0
npm v6.1.0

Getting the same error message on a new iMac. Worked fine yesterday when I installed it, but not today.
evalmachine.<anonymous>:2
<EMAIL_ADDRESS>| MIT | deps: 10 | versions: 47
^

SyntaxError: Invalid or unexpected token
    at new Script (vm.js:74:7)
    at createScript (vm.js:246:10)
    at Object.runInNewContext (vm.js:291:10)
    at safeEval (/Users/me/.config/yarn/global/node_modules/safe-eval/index.js:13:6)
    at /Users/me/.config/yarn/global/node_modules/vtop/upgrade.js:25:24
    at ChildProcess.exithandler (child_process.js:282:7)
    at ChildProcess.emit (events.js:182:13)
    at maybeClose (internal/child_process.js:961:16)
    at Socket.stream.socket.on (internal/child_process.js:380:11)
    at Socket.emit (events.js:182:13)

System details:
macOS 10.13.4
node 10.3.0
yarn 1.7.0

Last night I was able to reproduce this with the same setup as @vinkla, but I upgraded both Node and npm, and now everything works.

Did you happen to be offline when it worked? Random guess: the child process didn't exit because npm info never resolved due to being offline, meaning the erroneous code never executed.

Nope, online the entire time. Plugged in to the office network.
On Wed, May 30, 2018 at 9:17 AM William Boman<EMAIL_ADDRESS>wrote:

Last night I was able to reproduce this with the same setup as @vinkla
https://github.com/vinkla, but I upgraded both Node and npm, and now
everything works.
Did you happen to be offline when it worked? Random guess: the child
process didn't exit because npm info never resolved due to being offline,
meaning the erroneous code never executed.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MrRio/vtop/issues/121#issuecomment-393157771, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACX2oLMw7a5Rv23XWORjFec_-SZc1YUwks5t3pvhgaJpZM4TsKMD
.

Are you behind a corporate web proxy then? It is not uncommon that corp proxies block npm traffic.

Nope, no proxies set up. Never had any issues before with accessing npm or
anything else. It's a small company and I'm the IT manager here, and I try
to keep things simple for myself because I don't have anyone else to help
if things break..
On Wed, May 30, 2018 at 9:29 AM William Boman<EMAIL_ADDRESS>wrote:

Are you behind a corporate web proxy then? It is not uncommon that corp
proxies block npm traffic.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MrRio/vtop/issues/121#issuecomment-393161564, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACX2oArVgFT2vYtXt-xVKJL3w4-tKa-wks5t3p6lgaJpZM4TsKMD
.

🤔..
Anyways, for now I've published vtop-node10 which includes #123 and thus support for node@10/npm@6. To install:
$ npm uninstall -g vtop
$ npm install -g vtop-node10
$ vtop

That worked, thanks!
On Wed, May 30, 2018 at 9:46 AM William Boman<EMAIL_ADDRESS>wrote:

🤔..
Anyways, for now I've published vtop-node10 which includes #123
https://github.com/MrRio/vtop/pull/123 and thus support for node@10
/npm@6. To install:
$ npm uninstall -g vtop
$ npm install -g vtop-node10
$ vtop
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MrRio/vtop/issues/121#issuecomment-393167816, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACX2oHMDgs43WKX3xqvm1c-6ICBsln6tks5t3qK8gaJpZM4TsKMD
.

@williamboman you sir are a genius!

This is now fixed in v0.6.0. Thanks for your patience! :)

Still failing for me.

I'm having the same issue in 0.6.1

I'm having the same issue in 0.6.1

Same. I'm going to try the above vtop-node10 version, will report back on how that goes.


[5.7] Disable test Interpreter/convenience_init_peer_delegation.swift

Disable test in optimized mode. It fails on some bots.
rdar://92102119

@swift-ci test


CCT measure-table-structure-accuracy-command doesn't drop index

Describe the bug
The CCT command measure-table-structure-accuracy-command doesn't drop the extra index when it doesn't find a table to process (i.e. the documents have the wrong format).
To Reproduce
PYTHONPATH=. python unstructured/ingest/evaluate.py measure-table-structure-accuracy-command --output_dir ground_truth_text_as_html --source_dir predicted_text_as_html --output_dir output_metrics

Expected behavior

Screenshots
Error
  File "/Users/mallori/unstructured/unstructured/ingest/evaluate.py", line 276, in <module>
    main()
  File "/Users/mallori/opt/anaconda3/lib/python3.9/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
  File "/Users/mallori/opt/anaconda3/lib/python3.9/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
  File "/Users/mallori/opt/anaconda3/lib/python3.9/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/mallori/opt/anaconda3/lib/python3.9/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/mallori/opt/anaconda3/lib/python3.9/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
  File "/Users/mallori/unstructured/unstructured/ingest/evaluate.py", line 236, in measure_table_structure_accuracy_command
    return measure_table_structure_accuracy(
  File "/Users/mallori/unstructured/unstructured/metrics/evaluate.py", line 375, in measure_table_structure_accuracy
    agg_df.columns = agg_headers
  File "/Users/mallori/opt/anaconda3/lib/python3.9/site-packages/pandas/core/generic.py", line 5915, in __setattr__
    return object.__setattr__(self, name, value)
  File "pandas/_libs/properties.pyx", line 69, in pandas._libs.properties.AxisProperty.__set__
  File "/Users/mallori/opt/anaconda3/lib/python3.9/site-packages/pandas/core/generic.py", line 823, in _set_axis
    self._mgr.set_axis(axis, labels)
  File "/Users/mallori/opt/anaconda3/lib/python3.9/site-packages/pandas/core/internals/managers.py", line 230, in set_axis
    self._validate_set_axis(axis, new_labels)
  File "/Users/mallori/opt/anaconda3/lib/python3.9/site-packages/pandas/core/internals/base.py", line 70, in _validate_set_axis
    raise ValueError(
ValueError: Length mismatch: Expected axis has 6 elements, new values have 5 elements

Environment Info
Python version:  3.9.13
unstructured version:  0.13.3
unstructured-inference version:  0.7.23
pytesseract version:  0.3.10
Torch version:  2.1.0
Detectron2 version:  0.6
PaddleOCR is not installed
Libmagic version:  ==> libmagic: stable 5.45

Additional context
Add any other context about the problem here.

prediction_table_0_0.png.txt
ground_truth_table_0_0.png.txt


Animated Textures Aren't Loading

As the title says, when I try to load animated textures with this they sometimes won't load. They never seem to load the first time the page is loaded but when the canvas is refreshed they seem to have a chance of working after that, you can see a live example of this if needed.

Looks like you're right! It's been a really long time since I touched any of this code, but I remember that the code for loading images was extremely sloppy. I think the issue was that I started to write these huge synchronous functions and when it came to loading the images, I couldn't just use an onload callback since I was doing everything synchronously. Using dataurls seemed to make the attributes of the image immediately available so I went with that, but it looks like it doesn't work for larger images in general (like animated textures).
Yeah I know this is horrible, I was reaaally new to everything web-related. I'm glad people find this project useful but newbie code has its limitations :/
I'm planning to do a full rewrite, to replace this mess with a proper library. I just didn't get to do it yet.
I'm leaving the issue open so people can see it if they run into the same problem.

I would really love to use this so I look forward to what you do!!

@DevScyu Just letting you know, I finally started working on a complete rewrite. Not usable yet but it's going pretty well so far. I'm currently building a clean lower level library that will be able to create three.js geometry, materials and meshes from minecraft models :point_right: https://github.com/vberlier/three-mcmodel.

Okay thanks for letting me know! I'm looking forward to using it. I might
even see if I can contribute towards it.
On Thu, 18 Oct 2018, 11:46 pm Valentin Berlier<EMAIL_ADDRESS>wrote:

@DevScyu https://github.com/DevScyu Just letting you know, I finally
started working on a complete rewrite. Not usable yet but it's going pretty
well so far. I'm currently building a clean lower level library that will
be able to create three.js geometry, materials and meshes from minecraft
models 👉 https://github.com/vberlier/three-mcmodel.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vberlier/json-model-viewer/issues/2#issuecomment-431189115,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOh1btySCavM0uq4zErA5n4-dhFa3DaQks5umQS5gaJpZM4Vf8QJ
.


Conflicting types for _Block_release

I started getting this error trying to compile Objective-C recently:
In file included from /usr/GNUstep/Local/Library/Headers/Foundation/Foundation.h:33:
In file included from /usr/GNUstep/Local/Library/Headers/Foundation/FoundationErrors.h:29:
In file included from /usr/GNUstep/Local/Library/Headers/Foundation/NSObject.h:30:
In file included from /usr/GNUstep/Local/Library/Headers/Foundation/NSObjCRuntime.h:41:
/usr/GNUstep/Local/Library/Headers/GNUstepBase/GSBlocks.h:123:7: error: conflicting types for '_Block_copy'
void *_Block_copy(void *) __attribute__((weak));
      ^
/usr/GNUstep/Local/Library/Headers/objc/blocks_runtime.h:16:21: note: previous declaration is here
BLOCKS_EXPORT void *_Block_copy(const void *);

Most likely caused by this https://github.com/gnustep/libobjc2/commit/5f01917a498951e883a91c86d02d7d201b05a0bd commit.

Should be fixed as a result of the -base PR.


🚀 iDynTree 1.0 Released

iDynTree 1.0.0 was released today and is now available for download at: https://github.com/robotology/idyntree/releases/tag/v1.0.0 .
This is the first major release of iDynTree, and from now on iDynTree will adheres to Semantic Versioning, meaning that from now on  all releases of the iDynTree 1.x series will be API and ABI backward compatible.
In particular, iDynTree 2.0 will remove support for parts of iDynTree that have been deprecated for a long time such as anything that is enabled by the IDYNTREE_ENABLE_KDL CMake option, the iDynTree::DynamicsComputations class and the semantics support.
Release Highlights
Some major additions to the library with respect to iDynTree 0.11 are:

Several attitude estimation algorithms were added in the iDynTree estimation library.
Support for exporting iDynTree::Model as URDF files as been added, via the the iDynTree::ModelExporter class.
Support for using OSQP as a QP solver been added in the iDynTree optimalcontrol library.
The iDynTree::ModelLoader class has been modified to ensure that URDF models of serial robots load the joint in "normalized order", i.e. having joint closer to the fixed base come before joints that are closer to the end effector.

For more details on these and the other changes of iDynTree 1.0, check the "Detailed ChangeLog" section at the end of this release notes.
Acknowledgements
Thanks to the contributors (either as code authors or code reviewers) of this version of iDynTree:

Francisco Andrade (@fjandrad)
Stefano Dafarra (@S-Dafarra)
Diego Ferigo (@diegoferigo)
Nuno Guedelha (@nunoguedelha)
Antoine Hoarau (@ahoarau)
Gabriele Nava (@gabrielenava)
Prajval Kumar (@prajval10)
Ugo Pattacini (@pattacini)
Prashanth Ramadoss (@prashanthr05)
Alberto Remus (@AlbertoRemusIIT)
Angelo Rendiniello (@AngeloRendiniello)
Francesco Romano (@francesco-romano)
Giulio Romualdi (@GiulioRomualdi)
Ines Sorrentino (@isorrentino)
Yeshasvi Tirupachuri (@Yeshasvitvs)
Silvio Traversaro (@traversaro)

iDynTree first major release is dedicated to Angelina.
Detailed ChangeLog
Added

Added method to compute the inverse dynamics inertial parameters regressor in KinDynComputations ( https://github.com/robotology/idyntree/pull/480 ).
KinDynComputations finally reached feature parity with respect to DynamicsComputations, that will finally be removed in one of the future iDynTree feature releases.
Added method to return the convex hull of the constraint on the projection of the center of mass (https://github.com/robotology/idyntree/pull/478).
Added objects to deal with linear optimal control problems in the optimalcontrol library.
Added OSQP interface via osqp-eigen in the optimalcontrol library.
Fixed bugs in MultipleShooting solver in the optimalcontrol library.
Added few lines of documentation in the optimalcontrol library.
Added interface for ALGLIB and WORHP in the optimalcontrol library.
Multiple shooting solvers can use hessians of costs and constraints in the optimalcontrol library.
Taking into account also the sparsity pattern of constraints and dynamical system (both in jacobians and hessians) in the optimalcontrol library.
Added visualization of vectors in the visualization library.
Added a SolidShape helper library. This library is part of iDynTree, and is meant
to contain all the algorithms that use in some form the visual and collision geometries of the model,
and so they depend on the Assimp library to load meshes.
Added an helper function that provides rough estimates of the inertial parameters (mass, first moments of mass,
3d inertia matrix elements) of a robot given the total mass of the robot, and its collisions shapes. While the estimates
provided are quite rough, they can be quite useful at least to provide an expected order of magnitude of the parameters,
to normalize errors or as initial points of a nonlinear optimization procedure.
Added attitude estimator interface to estimate the orientation of an IMU, given the IMU measurements (https://github.com/robotology/idyntree/pull/516).
Added DiscreteExtendedKalmanFilterHelper base class (https://github.com/robotology/idyntree/pull/516).
Added AttitudeMahonyFilter implementation of an explicit formulation of passive complementary filter over quaternion groups (https://github.com/robotology/idyntree/pull/516).
Added AttitudeQuaternionEKF implementation (https://github.com/robotology/idyntree/pull/516).
Added getWorldFrameTransform implementation in SimpleLeggedOdometry class
Added a new version of changeFixedFrame in SimpleLeggedOdometryclass. This can be used to set a desired homogeneous transformation for the fixed frame
Added bindings for AttitudeMahonyFilter, AttitudeQuaternionEKF, DiscreteExtendedKalmanFilterHelper (https://github.com/robotology/idyntree/pull/522)
Added basic tests for the Attitude Estimator classes (https://github.com/robotology/idyntree/pull/522)
Added DiscreteKalmanFilterHelper class for an implementation of a discrete, linear time-invariant Kalman Filter  (https://github.com/robotology/idyntree/pull/559)
Added dynamic reset functionality to DiscreteExtendedKalmanFilterHelper class (https://github.com/robotology/idyntree/pull/553)
Added high-level Matlab/Octave wrappers of the iDyntree bindings (https://github.com/robotology/idyntree/pull/530)
Added bindings for the class Span with the name DynamicSpan (https://github.com/robotology/idyntree/pull/522)
Implement RPYRightTrivializedDerivativeRateOfChange() and RPYRightTrivializedDerivativeInverseRateOfChange() into Rotation class
Implement left Jacobian and left Jacobian inverse of SO(3) in Rotation class (https://github.com/robotology/idyntree/pull/562)
Add nameIsValid attribute to iDynTree::SolidShape class.
Add operator[] method to iDynTree::VectorDynSize (https://github.com/robotology/idyntree/pull/596)
Add operator[] method to iDynTree::VectorFixSize (https://github.com/robotology/idyntree/pull/596)
Implement getTotalMass() method for Model class
Enable the installation of the ModelTestUtils.h file (https://github.com/robotology/idyntree/pull/607)
Added iDynTree::ModelExporter class to export iDynTree::Model instances to URDF files (https://github.com/robotology/idyntree/pull/554).
Added support in the URDF parser to correctly parse the optional name parameter of visual and collision elements.
Added iDynTree::ModelCalibrationHelper to simplify loading a model from file, update its inertial parameters and exporting again to file (https://github.com/robotology/idyntree/pull/576).
In yarprobotstatepublisher, add tf-prefix and jointstates-topic options for the tf prefixes and ROS topic.

In yarprobotstatepublisher, add reduced-model optional parameter to stream only the link transformations to transform server. By default, tranformations from all the frames are streamed to the transform server.

Changed

The changelog has been migrated to the format described in https://keepachangelog.com/en/1.0.0/ .
If the IDYNTREE_USES_YARP option is enabled, the minimum required version of YARP is 3.3 .
The CMake config files are now installed in ${CMAKE_INSTALL_PREFIX}/lib/cmake/iDynTree also in Windows.
Updated iDynTree::ModelLoader class to load by default models with normalized joint ordering (https://github.com/robotology/idyntree/issues/491).
In yarprobotstatepublisher the model joint positions values are initialized to zero and the joint positions values are updadted in run time if the values are available in ROS topic given through jointstates-topic parameter.
In yarprobotstatepublisher, joint size check between model joints and joints in ROS topic given through jointstates-topic parameter have been removed.

Deprecated

All the classes and methods that end in Semantics are deprecated, and will be removed in iDynTree 2.0, see https://github.com/robotology/idyntree/pull/622 for more info.
The CMake option IDYNTREE_USES_KDL and all the classes available when enabling it are deprecated, and will be removed in iDynTree 2.0 .
In yarprobotstatepublisher, the robot option is deprecated, and replaced by name-prefix.

Fixed

Fixed missing DOF_ACCELLERATION data in dynamic variable cache ordering
(https://github.com/robotology/idyntree/pull/587)
Fixed compatibility of Span with SWIG bindings compilation (https://github.com/robotology/idyntree/pull/522)
Fixed implementation of Transform::log() method (https://github.com/robotology/idyntree/pull/562)
Fixed implementation of SpatialMotionVector::exp() method (https://github.com/robotology/idyntree/pull/562)

A regression that caused all the project that used the CMake command find_package(iDynTree <version>) to fail was discovered today, and iDynTree 1.0.1 was released at https://github.com/robotology/idyntree/releases/tag/v1.0.1 .
Detailed ChangeLog
Fixed

Change CMake version compatibility from SameMajorVersion to AnyNewerVersion, as API breakage between major version will be limited, and to avoid breaking the compatibility of any downstream project that request a minimum version of iDynTree as in find_package(iDynTree 0.11 REQUIRED) (https://github.com/robotology/idyntree/pull/629).


potential child process deadlock

@toddlipcon points out that if the parent process is holding a lock in another thread at the time a child process gets forked, that child won't be able to get the lock and could be blocked on it forever. LogCabin forks a child process to take a snapshot, and there aren't many locks on that path but:

What would happen if the child process deadlocked? Ideally we'd detect this, kill it, increment a ServerStats counter, and eventually start a new child process.
What locks does the child process grab? Some that might not be obvious include those in glibc (such as malloc, which should use pthread_atfork() for this) and the lock on stderr in Core/Debug.cc.

Before what would happen is the snapshotting process would wedge forever, and no more snapshots would be taken. 7c46a0d adds a new watchdog thread that runs in the parent process to watch the child, and kills it if it hasn't written anything for 10 seconds (by default).
I don't think the child process grabs many locks. The flockfile() in Core/Debug.cc is still a bit of a concern, but the child process doesn't usually log anything. Given that plus the watchdog plus the tiny window of vulnerability here, I'd prefer to wait and see if this is an actual problem before spending any time on it.

This issue seemed interesting so I researched it a little. If there is an "actual" problem some day, looks like maybe pthread_atfork is worth looking at. The "Rationale" section seems to describe this situation exactly.

@nhardt Yep, I think pthread_atfork is probably the way you're supposed to deal with this issue, although I guess you can get the same behavior if you are in control of all the fork calls. I used it in 83f19f5.

What is the gain that comes from forking rather than just doing the IO in a separate thread?

Not having to implement copy-on-write or any locking or reference counting for the state machine state (p54, 56).

It looks like if a process forks that uses the log cabin client, the above mentioned deadlock can occur. Here's a stack:
[root@xxx ~ 19:16:31 ]# pstack [forked process of daemon with embedded logcabin client]
#0  0x00007fc8681d6264 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x00007fc8681d1508 in _L_lock_854 () from /lib64/libpthread.so.0
#2  0x00007fc8681d13d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x0000000000d7c300 in __gthread_mutex_lock(pthread_mutex_t*) ()
#4  0x0000000000d7ecb6 in std::mutex::lock() ()
#5  0x0000000000d7f53a in std::lock_guardstd::mutex::lock_guard(std::mutex&) ()
#6  0x0000000000e20778 in LogCabin::Core::Random::(anonymous namespace)::RandomState::reset() ()
#7  0x0000000000e209a0 in LogCabin::Core::Random::(anonymous namespace)::resetRandomState() ()
#8  0x00007fc867ee0c36 in fork () from /lib64/libc.so.6
Looking at possible solutions.

Looking at possible solutions.

In case anyone else stumbles on this and is wondering what happened, see PR #187.


Compliance with PEP 8

Giving a first glance at this library, i can already give some suggestions to make library layout and code compatible with PEP 8 and similar widely spread python style guides;

snake_case function naming
all-lowercase library naming (PyArr -> pyarr)
function argument typing
(specific case) using named defaulted (def func(id = null)) arguments instead of *args like here, which is non-pythonic and confuses auto-documentation and typing tools

@marksie1988 i'm seeing you work on this, thank you a bunch for doing that, but instead of pep8, i recommend flake8, from my experience, flake8 gives much richer errors than pep8, and is much more consise.
pep8's last update was also in 2017, when i was referring to PEP 8, i meant the Python Enhancement Proposal, not the package


fix: fixing canrager SAEs in SAEs table docs

Description
This PR fixes docs/generate_sae_table.py to support canrager SAEs, which is breaking when building docs. Currently, the code to load the config file for building the SAEs table re-implements the converter loading code, I think because the converters also download the full SAEs which is not necessary for building the table.
This PR also removes docs/sae_table.md from git and adds it to .gitignore since this is auto-generated by CI anyway and the file in the repo is ignored.
Longer-term, we should refactor the converters to allow loading only the config and not the full SAE so we don't have to remember to implement new converters in 2 places.
Type of change
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I have not rewritten tests relating to key interfaces which would affect backward compatibility

You have tested formatting, typing and unit tests (acceptance tests not currently in use)

[x] I have run make check-ci to check format and linting. (you can run make format to format code if needed.)

thanks for the fix!


OpenX: Added support for schain

https://github.com/prebid/Prebid.js/pull/4194

confirmed released with 2.33


Failure Code

We've been trying to configure our front-end app to be able to relay mail through postal (running on an EC2 AWS instance).  The SMTP authentication seems to be inconsistent.  For many recipients, the logging shows error:
"530 Authentication required"
However, there are some recipients for which the connection is accepted and the message processed:
"334 PGYzZTE5N2MyZDEyNDE0NjEyY2I5QG10YS5taWdvMDEubmV0Pg=="
"235 Granted for ..."
(after the DATA command) "354 Go ahead"
Has anyone else experienced this?  If so, how did you solve the issue?
Thx!

Are you able to provide the full SMTP server log for the connection where this occurs?

Does this help?
[34m[smtp.1:32384] [2017-05-12T08:53:03.430] DEBUG -- : [T0QRKN] => 250 OK
[smtp.1:32384] [2017-05-12T08:53:03.530] DEBUG -- : [T0QRKN] <= MAIL<EMAIL_ADDRESS>[smtp.1:32384] [2017-05-12T08:53:03.531] DEBUG -- : [T0QRKN] => 250 OK
[smtp.1:32384] [2017-05-12T08:53:03.615] DEBUG -- : [T0QRKN] <= RCPT<EMAIL_ADDRESS>[smtp.1:32384] [2017-05-12T08:53:03.623] DEBUG -- : [T0QRKN] => 530 Authentication required
[smtp.1:32384] [2017-05-12T08:53:03.709] DEBUG -- : [T0QRKN] <= RSET
[smtp.1:32384] [2017-05-12T08:53:03.709] DEBUG -- : [T0QRKN] => 250 OK
[smtp.1:32384] [2017-05-12T08:53:03.807] DEBUG -- : [T0QRKN] <= MAIL<EMAIL_ADDRESS>[smtp.1:32384] [2017-05-12T08:53:03.808] DEBUG -- : [T0QRKN] => 250 OK
[smtp.1:32384] [2017-05-12T08:53:03.893] DEBUG -- : [T0QRKN] <= RCPT<EMAIL_ADDRESS>[smtp.1:32384] [2017-05-12T08:53:03.901] DEBUG -- : [T0QRKN] => 530 Authentication required
[smtp.1:32384] [2017-05-12T08:53:03.986] DEBUG -- : [T0QRKN] <= RSET

Yes, that is very helpful. Can you confirm what revision of the software you are running? Some changes were made very recently that may already fix this bug.

release-0
On Fri, May 19, 2017 at 5:15 PM, Charlie Smurthwaite <
<EMAIL_ADDRESS>wrote:

Yes, that is very helpful. Can you confirm what revision of the software
you are running? Some changes were made very recently that may already fix
this bug.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atech/postal/issues/175#issuecomment-302812909, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAIKmIqH2Oi_6zYu0J2bbnZ-g45mV7erks5r7gZZgaJpZM4NgsRW
.

release-0 isn't a commit ref, tag name or version number of Postal.

Looking again at the log, I see you are using the RSET command. There was a bug where RSET un-authenticated a connection, so it's very likely this is your problem. This bug was fixed in dacddb4d8e32ed78de25278109e8d711f1a397fe so it's extremely likely that if you upgrade, this will be resolved.
If the problem persists, could you perhaps get the full log of an SMTP session so that we can see whether this session was authenticated or not.

Just wanted to report that the update did the trick.  Thanks for your help!


Simplify bconv test

What do these changes do?
This updates the unittests to only use bitpacked input, to be merged into #457.
It further simplifies the tests by making the builtin op always use float in/output instead of sometimes float and sometimes int8.

The only thing I'm unsure about is splitting off the same-zero padding tests into a separate test group. Is the fact that so many test cases (with 'same-zero' padding) are skipped with the existing 'big' test group a problem?

After thinking some more about it, I think you're right, I'll revert that commit.


fix(webpack): use .babelrc to compile build to ES5

I think that specifying the preset option in the webpack config will override whatever we have in the .babelrc, which was causing ES6 code to end up in the themeable target (the "env" preset compiles down to ES6 stuff by default).

Coverage remained the same at 99.579% when pulling 47dac8f5267d92f6f1fbfdaf07171200b59d6ce4 on thallada/babelrc-fix into 50b9519282f3f04e418dc4f591e129259867781d on master.

Coverage remained the same at 99.579% when pulling 47dac8f5267d92f6f1fbfdaf07171200b59d6ce4 on thallada/babelrc-fix into 50b9519282f3f04e418dc4f591e129259867781d on master.

I think env compiles down to ES5

A Babel preset that compiles ES2015+ down to ES5 by automatically determining the Babel plugins and polyfills you need based on your targeted browser or runtime environments.

babel-preset-env

That being said, it could be useful to move all our babeling to one place.

@thallada if you can confirm that everything was compiling down to ES5 in the first place can you change this to a non-release triggering commit message (build, refactor, maybe even style) since there's nothing here that should theoretically generate a different release (right?).
Additionally, (and I'm sorry I'm a nit about this), do you mind changing the PR name and commit message to reflect that this change?

@jaebradley I changed to a build commit. I'm going to merge this now.


Add async load for fused mma convert_layout and transpose (ldmatrix.sync.aligned.m8n8.x4.trans.shared.b16)

Currently, there is no async load op (insert_slice_async) generated for this scenario, as documented in https://github.com/openai/triton/blob/13189bfe60e135d3e7e624f8a6d5e953951c1b5e/lib/Dialect/TritonGPU/Transforms/Pipeline.cpp#L448

Maybe related: Reported issues with transpose (both perf and correctness) - https://github.com/openai/triton/issues/1806, https://github.com/openai/triton/issues/2150, https://github.com/openai/triton/issues/1714

Let me try to create a simple regression testcase where this (load + transpose + convert_layout<#mma> + dot) fails to generate insert_slice_async.

Have some evidence that main no longer has this perf issue. However, let me add a regression anyway to confirm it.


[Minor][Core] Fix display wrong free memory size in the log

What changes were proposed in this pull request?
Free memory size displayed in the log is wrong (used memory), fix to make it correct.
How was this patch tested?
N/A

Test build #60921 has started for PR 13804 at commit ffbc588.

Test build #60921 has finished for PR 13804 at commit ffbc588.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/60921/
Test FAILed.

Jenkins, retest this please.

Test build #60931 has started for PR 13804 at commit ffbc588.

Certainly looks more correct

Test build #60931 has finished for PR 13804 at commit ffbc588.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/60931/
Test PASSed.

Merged build finished. Test PASSed.

Any further comments @srowen , from my understanding it worth fixing.

Merged to master/2.0

Thanks a lot @srowen .

hi @jerryshao, let's also back-port this into 1.6.x (MemoryStore.scala#L395) maybe?

OK, let me do it.


Fix clippy on generated code & add a deny for warnings

This gets rid of the clippy warnings on code generated for protos by allowing all on an intermediate module declaration, as well as makes it a requirement for clippy to successfully finish w/o warnings for the Dockerfile build

For some reason I didn't consider this strategy yesterday but remembered while working on an unrelated PR -- we're finally going to have a clean PR review view 🥳


Storing image in our documentation in MinIO

What
The image we store in #1 , will be stored in MinIO.
Why
The old approach sometime return broken images. And it's hard to organized the images because they are posted in comments and you can't group them.
How
We can store the image in the MinIO, and retrieve them when needed. We normally build documentation in the following cases:

during development, documentation part needs to be modified and previewed
doc pipeline is run

The solution should be able retrieve pictures in abovementioned cases and make sure that documentation can be built with the pictures

This is useful https://github.com/minio/minio/issues/1508


Update dogecoin.cpp

Clearly this was what was meant in this comment.

Nice meme, but better keep the other version ;)


Identify unhappy paths

Describe the task
Brainstorm with developers and BA what could be potential unhappy paths, and come up with workflows (if applicable) to help users navigate them.
Acceptance Criteria

[ ] set up a brainstorming workshop to identify what unhappy paths could potentially happen with devs and BA
[ ] conduct session
[ ] identify takeaways
[ ] ?

Additional context

Add any other context about the task here.
Or here

Ongoing notes for unhappy path


Nokogiri 1.6 Segmentation Fault with irb under verbose and debug flags.

Minimal steps
$ bundle exec irb
$VERBOSE = true
$DEBUG = true

require 'nokogiri'

Nokogiri::HTML::parse ''
# segmentation fault or SystemStackError
# often both.

Machine 1
Ubuntu Linux 12.04 with RVM
$ bundle exec nokogiri -v
# Nokogiri (1.6.0)
    ---
    warnings: []
    nokogiri: 1.6.0
    ruby:
      version: 1.9.3
      platform: x86_64-linux
      description: ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
      engine: ruby
    libxml:
      binding: extension
      source: packaged
      libxml2_path: /home/ubuntu/.rvm/gems/ruby-1.9.3-p484/gems/nokogiri-1.6.0/ports/x86_64-linux-gnu/libxml2/2.8.0
      libxslt_path: /home/ubuntu/.rvm/gems/ruby-1.9.3-p484/gems/nokogiri-1.6.0/ports/x86_64-linux-gnu/libxslt/1.1.26
      compiled: 2.8.0
      loaded: 2.8.0

Machine 2
Arch Linux with anyenv/rbenv
$ bundle exec ruby nokogiri -v
# Nokogiri (1.6.1)
    ---
    warnings: []
    nokogiri: 1.6.1
    ruby:
      version: 1.9.2
      platform: x86_64-linux
      description: ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]
      engine: ruby
    libxml:
      binding: extension
      source: system
      compiled: 2.9.1
      loaded: 2.9.1

Hi,
Sorry for not responding much sooner. I can't reproduce this issue using Ruby 2.3 and Nokogiri <IP_ADDRESS>.
After all this time, I doubt it's still a problem, but if so please comment and I'll re-open.