Split Solo5 into multiple packages

This is a general issue to work out two things:

Split out tools (solo5-elftool, solo5-virtio-mkimage, solo5-virtio-run) and headers (include/*) into separate packages.
Do this in a way that will pave the way for OS/distribution-friendly packages of Solo5.

The motivation for 1 are the Mirage 4 cross-compilation improvements (PoC by @TheLortex #486, mirage/ocaml-freestanding#90), the motivation for 2 is to be able to distribute binary unikernels (/cc @hannesm).

Currently we have multiple solo5-bindings-* packages, each conflicting with one another in OPAM, which install various combinations of the following, depending on the actual target XXX:

Header files:

Public and private Solo5 headers: include/solo5/* AS $PREFIX/include/solo5-bindings-XXX/solo5/*.
Base C compiler headers appropriated from the host C compiler toolchain at configure time: include/crt/* AS $PREFIX/include/solo5-bindings-XXX/crt/*.

Tools:

ELF manifest/ABI tool: solo5-elftool AS $PREFIX/bin/solo5-elftool
Various scripts: solo5-virtio-mkimage.sh, solo5-virtio-run.sh AS $PREFIX/bin/solo5-YYY.

Bindings:

Compiled bindings as an object file for linking: solo5_XXX.o AS $PREFIX/lib/solo5-bindings-XXX/solo5_XXX.o.
Linker script: solo5_XXX.lds AS $PREFIX/lib/solo5-bindings-XXX/solo5_XXX.lds.
Pkg-config information solo5-bindings-XXX.pc AS $PREFIX/lib/pkgconfig/solo5-bindings-XXX.pc.

Tender (hvt and spt only):

Compiled tender binary: solo5-XXX AS $PREFIX/bin/solo5-XXX.

#486 gets us part of the way there, but since we're splitting out packages and thus also incompatibly breaking the build system downstream, we should take this opportunity to go as far as we can given what we know about current and future requirements.
What I think we want to get to is something like:

A solo5-headers package, which installs (1.i) AS $PREFIX/include/solo5/* and (1.ii) AS $PREFIX/include/solo5/crt/* (note the latter is now one level deeper).
A solo5-tools package, which installs (2.i) and (2.ii) AS $PREFIX/bin/* (i.e. all "tools" are now in one package).
Co-installable solo5-bindings-XXX packages, which install (3.i) and (3.ii) AS $PREFIX/lib/solo5/* (note the directory change) and (3.iii) and (4.i) AS before.

In all of the above cases, $PREFIX is currently the OPAM prefix, i.e. opam config var prefix.
Now, in the OS/distribution package case, imagine that it will be just /usr/local, or even /usr (eventually in e.g. upstream Debian).
Questions, mainly in the OS/distro packaging context:

@hannesm: Do the above paths work for FreeBSD ports?
@mato: (Note to self) Do the above paths work for Debian (including upstream, i.e. policy)?
The above paths don't allow for co-installation of packages from multiple archs, which may be useful for some cross-compilation/build scenarios. It's possible we don't care, but if we do then arch-dependent parts need to go in arch-specific directories, e.g. $PREFIX/lib/solo5/x86_64/....
The above doesn't allow for a co-installation of multiple versions of bindings, tenders or headers. Do we care?
Should we also split out the tenders into separate packages? I can see this being useful in the context of shipping binary unikernels, where a user/operator will want a trusted source of e.g. solo5-hvt version XXX.

If so, what should these be called?
If so, shouldn't solo5-bindings be called libsolo5-bindings in an OS/distro (not OPAM) context.

Maybe the tenders should go in /usr/libexec/solo5/... and a solo5-common package depending on them should install some kind of generic solo5-run script, but it may be too early to engineer this properly, so just mentioning it for completeness.

Thanks for writing this up. The paths ($PREFIX/include/solo5 for headers, $PREFIX/lib/solo5/ for bindings, $PREFIX/bin for tools) sound reasonable (pc files from ports on FreeBSD are kept in $PREFIX/libdata/pkgconfig/).
"3 co-installation for multiple archs" tbh I'd skip this for now until we need it. In my experience that is either kept under a custom PREFIX (e.g. $PREFIX/arm64-solo5/ - and then lib / include etc.) or all binaries have the cross-architecture as part of their name.
"4. multiple versions of bindings, tenders, and headers" I'd as well skip this until the need arises. I remember from earlier discussion that there is version information in manifest, which could be used for selecting the tender - one way to get there would be to install ., and for convenience also provide a symlink where  links to ..
"5. tenders into separate packages" indeed this is from my point of view important -- the main (only?) user of bindings and headers is opam - and they have to be available on the system you want to compile the unikernel/guest image for. The tender (+eventually the solo5-elftool) is required to execute the unikernel (and independent of opam / pkg-config / ...). So I'm keen on having the tenders as separate package(s). Indeed, I already build FreeBSD solo5 packages (binary package http://<IP_ADDRESS>:8080/packages/builder-default/All/solo5-0.6.7.txz) with the attached patch (to only build tools and tenders) and Makefile (I'm not too keen on that patch since it adds more clutter to the existing build system).
Makefile.txt
patch-only-tools-and-tenders.txt
I'd be in favour of having different Make targets instead -- make solo5-elftool / make solo5-hvt / .. / make test .. instead of having to plumb different uses through configure options, and make compiling and testing everything. Different OS vendors have different packaging practises: separate headers+libraries needed for development from binaries to run it, etc.
From my point of view, the most useful solo5 packages atm would be tenders and elftool - since that's what is needed to execute any unikernel (via a systemd script, an rc script, or albatross).
"6. tenders + solo5-common package" I'm not sure about this.

@hannesm:

The paths ($PREFIX/include/solo5 for headers, $PREFIX/lib/solo5/ for bindings, $PREFIX/bin for tools) sound reasonable (pc files from ports on FreeBSD are kept in $PREFIX/libdata/pkgconfig/).

Right, I expected that, so we'll need some extra configurable variables for e.g. PCFILEDIR.

co-installation for multiple archs" tbh I'd skip this for now until we need it.

Ok, but see below.

multiple versions of bindings, tenders, and headers" I'd as well skip this

I'd be in favour of having different Make targets instead -- make solo5-elftool / make solo5-hvt / .. / make test .. instead of having to plumb different uses through configure options, and make compiling and testing everything. Different OS vendors have different packaging practises: separate headers+libraries needed for development from binaries to run it, etc.

Indeed. The actual split between what gets specified at configure vs. selected by make targets is a bit unclear to me, depends on the actual implementation.
One thing we should do is standardise on the "usual" use of PREFIX and DESTDIR in these kinds of packages:

PREFIX is the path used from the point of view of a "root" somewhere, i.e.in a system-wide install would usually default to /usr/local and in an OPAM install to $(opam config var prefix).
DESTDIR is the path used mainly by (binary) packaging scripts to specify an "staging location" during an install phase. This normally defaults to "" and is prepended to PREFIX for installation only. For example, PREFIX=/usr/local DESTDIR=/tmp/pkgresults in a hypotheticalmake installinstalling to/tmp/pkg/usr/local/...`.

I'll try a few experiments for both PREFIX, DESTDIR and a headers / tools / bindings / tenders split of some form and see what I come up with.

DESTDIR / PREFIX

I currently have MAKE_ARGS=	"PREFIX=${STAGEDIR}${PREFIX}" in the FreeBSD port Makefile to install this into STAGEDIR.

@TheLortex @hannesm:
Okay, I have a work in progress in #488.  TL;DR 90% of the way there but it won't actually work.
Differences between #488 and #486:

configure.sh gets an --enable-targets option, so opam files no longer need to muck with CONFIG_. --enable-targets=none is what is used for the "common" OPAM package build.
The Makefiles allow to pick and choose which of { tools, headers, bindings, tenders } you want to build and install, within reason.
Instead of solo5-headers, there is just a "common" solo5 OPAM package, which installs headers and tools.
The solo5-bindings-xxx OPAM package contains the bindings and tenders, if any.
OS/distribution packagers can (and probably will) make their own choices about package splits (e.g. have a separate -tenders package, or have the tenders in the "common" package, or even split headers into a "dev" package, etc.)

This gets us 90% of the way there, but:
The way @TheLortex does things in mirage/ocaml-freestanding#90, FREESTANDING_CFLAGS is picked up from  solo5-headers.pc, which would in this setup be installed by the "common" OPAM package. This is understandable since ocaml-freestanding needs to get some common CFLAGS from somewhere, except that in reality it won't work:

genode uses a different set of CFLAGS including -fPIC.
ASLR (planned for next year) will require -fPIE for the targets that get it (hvt, spt), but not for the others.

Now what?

Either: we mandate that all targets MUST have the same CFLAGS (forever). This implies genode will be removed and once ASLR lands all targets will be compiled with -fPIE, which may or may not work. It also implies that we are stuck if we want to vary CFLAGS for a future target.
Or: We figure out some other way to make things work while allowing variations in per-target CFLAGS.

Note that option (2) does not need to be done within the constraints of pkg-config; I've wanted to get rid of that for some time, so it could, for example, be replaced with a solo5-config script that is more intelligent, generated at configure time and installed as part of the "common" (OPAM) or "dev" (OS) package. However, I still don't see a way to make it work.

Thanks for your work and testing. For me, this read as: CFLAGS (such as -fPIE) are (mirage) target-dependent.
Could the ocaml-freestanding cross-compiler be done without respecting any of these flags - instead put them into the dune workspace context (as it already happens!?), and compile the ocaml runtime (+libm+nolibc) at the time of building the unikernel (when the target is already selected)? I have not looked into the ocaml-freestanding PR to understand whether there are blocking things for such an approach. Also not clear to me what the purpose of the ocam-freestanding cross-compiler would then be.

Agreed with @hannesm. Rather than struggling to get a homogenous set of CFLAGS, compiling the runtime with the dune workspace CFLAGS is actually pretty fast, so I'd be in favour of that.
@hannesm then wrote:

Also not clear to me what the purpose of the ocam-freestanding cross-compiler would then be.
That's the ideal situation :-) As upstream OCaml supports cross-compilation better and better, we should be retiring ocaml-freestanding. This particular approach would get the runtime compiled within a dune workspace, and @dra27 is working steadily on "pure" cross-compilation within the OCaml compiler itself to target native binaries.  Hopefully in a few OCaml releases we won't need freestanding any more.

Could the ocaml-freestanding cross-compiler be done without respecting any of these flags - instead put them into the dune workspace context (as it already happens!?), and compile the ocaml runtime (+libm+nolibc) at the time of building the unikernel (when the target is already selected)? I have not looked into the ocaml-freestanding PR to understand whether there are blocking things for such an approach. Also not clear to me what the purpose of the ocam-freestanding cross-compiler would then be.

I'm not sure that it is currently possible to compile the runtime with some specific (and different) flags. I agree that we should not enforce a set of flags for any target (and loose genode or use -fPIE which may not work).
The current choice about the ocaml-freestanding cross-compiler is to compile it and install it only one time (regardless the target choosen by the user) and then use it to compile any MirageOS projects. This choice was made comparing to some others possibilities:

a 2-step build: building a locally-installed cross-compiler using duniverse sources and then building the unikernel
improve dune to perform a single step unikernel build where it takes care of building both the cross-toolchain and the unikernel

These possibilities imply a compilation of the compiler for each MirageOS project - even if it's not really sustainable or scalable, it allows to us to control C flags according to the target choosen by the user.
For my point-of-view, we highlight some limitations and we have these choices:

we can consider the work of @dra27 and post-pone/synchronize his work, our ecosystem and ASLR - so nothing change at this time but we will be aware about an other deep change on our stack
try to compile the runtime with the dune workspace but I let @TheLortex to confirm that it is possible
experiment the possibility to compile locally the compiler for each MirageOS project (but I'm not confident with this solution - I'm not sure that we can use dune-cache for example to speed-up the compilation)

Indeed, the cross-compilation story makes sense only if one set of flags is used. As of today, OCaml does not support having multiple targets built-in (like clang) so we have to find something else. But let's keep in mind that in the future, thanks to @dra27's work, we should have a better workflow for cross-compilation.
I agree with what has been said above : we can't enforce an homogeneous set of flags. I don't think it's a good idea to locally build compilers for each project (quite heavy and not cache-able because the installation prefix changes for each project). So I see two solutions:

Evaluate a closed list of flag sets that we need to support all targets (PIC / no-PIC for starters), write these sets of flags as conflicting configuration packages (ocaml-freestanding-config-PIC, ocaml-freestanding-config-no-PIC), add dependencies to bindings, corresponding to which sets of flags they support (solo5-bindings-hvt ->   ...-PIC | ...-PIC, solo5-bindings-genode -> ...-PIC). Then ocaml-freestanding would depend on the union of the configuration packages, only one being selected as they all conflict, and would be built with the chosen set of flags. This reduces co-installability, but allows to support a pre-determined set of flags. This requires very small changes in ocaml-freestanding and libc's to fetch the flags from installed configuration packages, but everything else works the same.

As suggested by @dinosaure, build libasmrun.a in the dune workspace, meaning that ocaml-freestanding, nolibc and openlibm need to be packaged with dune. I've just checked and it's possible to go this way. The changes would consist in adding a dune wrapper that would run the corresponding Makefiles and export libraries. With regards to mirage, ocaml-freestanding should be locally fetched by opam-monorepo (ex duniverse) and not installed by opam anymore. This way the bindings would all be co-installable and in control of the flags.

Evaluate a closed list of flag sets that we need to support all targets (PIC / no-PIC for starters), write these sets of flags as conflicting configuration packages (ocaml-freestanding-config-PIC, ocaml-freestanding-config-no-PIC), add dependencies to bindings, [...]

I'm strongly in favour of this option, since it lets us make this work with the existing Mirage 3.x codebase. This means that we can release a split Solo5 and compatible ocaml-freestanding earlier rather than later, and don't have to maintain the older versions in any way. I'm also happy to implement the changes required to get Mirage 3.x to work with this model, since it'd already be much better than what we have today.
Note that genode is no longer updated in OPAM since April (see #446). That doesn't change the motivation for being able have different sets of CFLAGS, it just means that at the moment there will be only one. However, for the purposes of this discussion, let's keep using more than one as an example.
Should these "config" OPAM packages be part of ocaml-freestanding or part of solo5? I'm not sure, but it feels like the "ocaml-freestanding toolchain to select" is a property of the bindings / Solo5 release, and not the other way round.
How about the following, including a whole Mirage 3.x style picture here for clarity:
Binding                 Depends on                      Rdepends                Rdepends        Rdepends

solo5-bindings-hvt      solo5-config-ocaml-static
solo5-bindings-spt
solo5-bindings-virtio
solo5-bindings-muen                                     ocaml-freestanding      mirage-solo5    (mirage-generated .opam)
solo5-bindings-xen                                                              mirage-xen

solo5-bindings-genode   solo5-config-ocaml-pic

This means that, when e.g. solo5-bindings-hvt gets ASLR support, it changes to depend on a new solo5-config-ocaml-pie, and so on.
The remaining question in my mind is, what does solo5-config-* actually install? A .pc file with just some Cflags in it? Something else? See my discussion above about replacing pkg-config entirely in this stack with some form of custom solo5-config script(s).

(For the benefit of those reading e-mail notifications: Edited the previous comment to note that gmp-freestanding and zarith-freestanding also depend on ocaml-freestanding, i.e. will get re-built if the "config" gets switched.)

Here is an example of what such a solo5-config script could look like. This would be generated by make from values determined by configure.sh and installed as part of the "common" or "dev" Solo5 OPAM/OS package, whatever that may be.
So you can do things like:
$ ./solo5-config.sh --target=hvt --cflags
-ffreestanding -fstack-protector-strong -nostdinc -mstack-protector-guard=global -isystem /usr/local/include/solo5/crt -I/usr/local/include/solo5

OR
$ ./solo5-config.sh --ocaml=static --cflags
-ffreestanding -fstack-protector-strong -nostdinc -mstack-protector-guard=global -isystem /usr/local/include/solo5/crt -I/usr/local/include/solo5

It does mean that the script contains PREFIX in it, but that's fine, that just means --prefix= becomes a parameter to configure.sh, which is not unlike what autotools does.
Thoughts?

Thoughts?

As long as you find a realistic solution with @TheLortex, I'm happy with your solution :+1:.

Downstream, ocaml-freestanding can then EITHER generate its existing .pc file using solo5-config, OR gain a similar ocaml-freestanding-config script and we get to kill pkg-config entirely ❤

May be we can take this opportunity to delete pkg-config, yes.

I really like the idea of solo5-config. Something I'm wondering is how to manage target-specific CFLAGS that are not mandatory to build ocaml-freestanding ?
I'm thinking of the xen target, which installs additional headers that should be made available using an additional -I flag. This flag is not necessary to build ocaml-freestanding but useful for all xen-specific dependencies.

I'm wondering about solo5-config.sh: isn't this just data (cflags, ldflags) determined completely at (solo5-config) installation time? if this is the case, I don't see a reason to use a shell script (and would use a text file or sexp or rfc822 instead). WDYT? (same comment about ocaml-freestanding.sh).

@TheLortex

I'm thinking of the xen target, which installs additional headers that should be made available using an additional -I flag. This flag is not necessary to build ocaml-freestanding but useful for all xen-specific dependencies.

The only other package in the Mirage stack that uses the xen headers is mirage-xen, and that ships its own identical copy of the Xen headers. Now, I can understand that having two copies of these around in our stack is suboptimal, but if we want to install them, then:

They should not be installed AS $PREFIX/include/xen/* since in an OS package scenario this would conflict with the "normal" Xen headers (e.g. libxen-dev).
They should not be installed by the Solo5 "common" or "dev" package, as they are only useful to consumers of Solo5/Xen.

...so, that leads me to conclude that the Xen headers should be installed as part of solo5-bindings-xen, AS $PREFIX/include/solo5/xen/*, which means anyone using solo5-config --cflags will be able to include these as <xen/*> with no extra steps since -I$PREFIX/include/solo5 will be passed to the compiler.
Right?
@hannesm

I'm wondering about solo5-config.sh: isn't this just data (cflags, ldflags) determined completely at (solo5-config) installation time? if this is the case, I don't see a reason to use a shell script (and would use a text file or sexp or rfc822 instead). WDYT? (same comment about ocaml-freestanding.sh).

Please, no. I want to be able to call out to it sanely from Makefiles or other arbitrary build systems, and not have to parse stuff.

I'm wondering about solo5-config.sh: isn't this just data (cflags, ldflags) determined completely at (solo5-config) installation time? if this is the case, I don't see a reason to use a shell script (and would use a text file or sexp or rfc822 instead). WDYT? (same comment about ocaml-freestanding.sh).

Please, no. I want to be able to call out to it sanely from Makefiles or other arbitrary build systems, and not have to parse stuff.

And I'm not confident to use RFC822 format.

The only other package in the Mirage stack that uses the xen headers is mirage-xen

Yes it is, however it's currently an illusion: all packages that have C stubs (cstruct, io-page, ...) have them implemented in mirage-xen (and mirage-solo5).
I think a proper way to do it would be to have portable C stubs directly in the corresponding packages (cstruct, io-page) and remove them from mirage-<target>. This way mirage-<target> base layers wouldn't need to know about C stubs from the whole mirage universe, and it's the job of each package with C stubs to support the mirage targets. Mirage support would be tested within each package repository, thus making them more self-contained.
In this case we might need to add a -DMIRAGE_<target> flag to allow developers to add target-specific C stubs implementations.

...so, that leads me to conclude that the Xen headers should be installed as part of solo5-bindings-xen, AS $PREFIX/include/solo5/xen/*, which means anyone using solo5-config --cflags will be able to include these as <xen/*> with no extra steps since -I$PREFIX/include/solo5 will be passed to the compiler.
Right?

This looks good to me. But I think we need a -DMIRAGE_XEN additional flag for downstream packages that would need a xen-specific implementation, as seen above.
What do you think ?

Yes it is, however it's currently an illusion: all packages that have C stubs (cstruct, io-page, ...) have them implemented in mirage-xen (and mirage-solo5).

Yes, I know. This is partly a historical accident (back from the old mirage-platform days), and partly laziness.

I think a proper way to do it would be to have portable C stubs directly in the corresponding packages (...)

I've proposed something like this myself previously, but today I'm not so sure. The current arrangement with mirage-{solo5,xen} OPAM package containing the stubs is practical, and not a huge maintenance burden. Also, I think we all agree, that we don't particularly want to encourage more packages with C stubs in them.
If we do go down that route it'll be a lot of juggling of dependencies across several more packages. Before we do that, I'd like to see a proper table of what stubs we have in mirage-{xen,solo5} today, and where they would live in the new model.

This looks good to me. But I think we need a -DMIRAGE_XEN additional flag for downstream packages that would need a xen-specific implementation, as seen above.

This is actually orthogonal to "which OPAM package the stubs live in", and is something I'd like to avoid unless we find that we actually need it, on the basis that "No is temporary but yes is forever". Xen is the only Solo5 target which is "special", and I think that the only downstream that needs to know about that is mirage-xen, which is self-evident and doesn't require a -DMIRAGE_XEN to achieve.
Thoughts? /cc @avsm @samoht

Also, I think we all agree, that we don't particularly want to encourage more packages with C stubs in them.

If we want to focus on the IoT perspective (which is not mine), the question behind C stubs becomes more important. I agree that, currently, we have only few packages with C stubs (mostly crypto packages where performance matters). But for IoT, I suspect that the law of rewrite our world only OCaml does not scale up 😕 - and we need to integrate more C code.

@TheLortex

Yes it is, however it's currently an illusion: all packages that have C stubs (cstruct, io-page, ...) have them implemented in mirage-xen (and mirage-solo5).

@mato

Yes, I know. This is partly a historical accident (back from the old mirage-platform days), and partly laziness.

There are counterexamples: digestif, mirage-crypto, hacl, fiat, bigstringaf...
@TheLortex

I think a proper way to do it would be to have portable C stubs directly in the corresponding packages (...)

@mato

I've proposed something like this myself previously, but today I'm not so sure. The current arrangement with mirage-{solo5,xen} OPAM package containing the stubs is practical, and not a huge maintenance burden. Also, I think we all agree, that we don't particularly want to encourage more packages with C stubs in them.

I worked on this topic several years back, and in MirageOS 3.x days this turns out to be complicated (due to the need of some more rules and hacks in the build system).
@mato

If we do go down that route it'll be a lot of juggling of dependencies across several more packages. Before we do that, I'd like to see a proper table of what stubs we have in mirage-{xen,solo5} today, and where they would live in the new model.

As a release manager of MirageOS 3.x I'd as well prefer to keep the "split solo5 into multiple packages" as the first goal -- which is AFAICS completely MirageOS 3.x compatible. Designing the dependency hierarchy (and who installs the xen headers) should IMHO be done subsequently in a different PR series.

As a release manager of MirageOS 3.x I'd as well prefer to keep the "split solo5 into multiple packages" as the first goal -- which is AFAICS completely MirageOS 3.x compatible. Designing the dependency hierarchy (and who installs the xen headers) should IMHO be done subsequently in a different PR series.

Agreed.
To summarize, next steps:

Let's defer discussion of "what to do with C stubs that live in mirage-{solo5,xen}", as that is orthogonal to the core changes being discussed here.
I'll work on updating #488 on the basis of what has been agreed so far:

Overall design, "config" packages to deal with CFLAGS (https://github.com/Solo5/solo5/issues/487#issuecomment-742537414)
Install a solo5-config script instead of pkgconfig
Xen headers get installed by solo5-bindings-xen (https://github.com/Solo5/solo5/issues/487#issuecomment-743245284)

@TheLortex then updates mirage/ocaml-freestanding#90 to match.
I'll put together Mirage 3.x PR(s) to match.

This should get us to a point where we can release Solo5 0.7.0 and ocaml-freestanding 0.7.0, both of which will work with Mirage 3.x and master.
Please speak up if I've missed anything.

Following up on today's video discussion, I'd like to remove the Genode bindings entirely as part of this work as it's adding unnecessary complexity. We can always re-instate it at a later date once the OCaml cross-compilation situation improves and we have proper support for external toolchains. @ehmry Any objections? Are you (or anyone in the Genode community) actively using the Solo5/MirageOS support?

Removing Genode support is fine by me, it should be easy enough to add
again later.

As per our discussion, there are now new solo5 and solo5-config-ocaml-static OPAM packages, and the bindings depend on both. The pkg-config stuff is gone, and there is now a solo5-config:
$ solo5-config --help
usage: solo5-config --target=TARGET | --toolchain=TOOLCHAIN [ OPTIONS ]

Queries Solo5 toolchain parameters.

The Solo5 target to use must be selected using --target=TARGET, where TARGET is
one of 'hvt,spt,virtio,muen,xen'.

Alternatively, if you are configuring an ocaml-freestanding toolchain,
compile-time (but not link-time) parameters may be queried by selecting it with
--toolchain=TOOLCHAIN, where TOOLCHAIN is currently 'static'.

Options:
    --cc
    --ld
    --cflags
    --ldflags
    --lddeps

... which should be self-explanatory.
Please take a look, and let me know how you get on.

This looks good, thank you. So when configuring ocaml-freestanding I should call solo5-config --toolchain=static to get the correct flags to build libasmrun.a. This means that I need to find which solo5-config-ocaml-... is installed to perform the correct call to solo5-config.
I'm not sure what's the best way to have that:

probing with opam list to find the installed package.
add a way to list configured toolchains in solo5-config.
have a solo5-config --toolchain command which fails if multiple toolchains are possible.

@TheLortex Good point. Looking through the OPAM manual a bit, I think we could do this with flags to ocaml-freestanding's configure.sh and per-package variables. That feels cleaner than having solo5-config "know" about co-installability of toolchains, since that's an ocaml-specific thing, at least for the moment.
How about this:

Add a required --toolchain=TOOLCHAIN flag to ocaml-freestanding's configure.sh, where the only currently accepted TOOLCHAIN is static. (Feel free to swipe the option parsing code from the Solo5 configure.sh or solo5-config.sh.)
Adapt the ocaml-freestanding build to require running configure.sh before make. (Again, see how Solo5 does this.)
In the ocaml-freestanding opam file, use something like:

build: [ "./configure.sh" "--toolchain=static" { solo5-config-ocaml-static:installed } ]

While you're at it, you could add a --prefix= to ocaml-freestanding's configure.sh for consistency, rather than passing it down through make variables as we do right now.

... if I understand the OPAM manual correctly, following the above, when we have multiple toolchains (and solo5-config-ocaml-X) packages, we could then do:
build: [ "./configure.sh" "--toolchain=static" { solo5-config-ocaml-static:installed } "--toolchain=pie" { solo5-config-ocaml-pie:installed } ]

which effectively means the presence of the solo5-config-ocaml-X package selects which --toolchain= flag is passed to ocaml-freestanding. This looks like an elegant solution.
Side note: Currently solo5-bindings-* conflict with the old solo5-bindings-* { < "0.7.0" } packages, I think I can simplify this and make just the solo5-config-ocaml-static package contain the conflicts. Easier to maintain that way and less duplication.

Over the last couple of weeks after discussion with @TheLortex I've come to the conclusion that the solution proposed here, and implemented in #488 and mirage/ocaml-freestanding#90, is fundamentally wrong and not thought through. This has become more obvious in the presence of @TheLortex's and my experiments with enabling cross-architecture compilation in both Solo5 and ocaml-freestanding.
How we got here:

Solo5, when compiled on a supported host system, builds and installs common headers and host tools_, some bindings and some or none tenders.
#488 introduces the concept of a Solo5 toolchain, exposed via a solo5-config script, and also defines make install targets using a well-defined filesystem hierarchy, allowing some bindings to be co-installed in OPAM.
#488 splits Solo5 into several OPAM packages: solo5 (common headers and host tools), solo5-bindings-XXX (one for each of some bindings, may include a tender) and solo5-config-ocaml-static (used by ocaml-freestanding to select the toolchain).

I believe that the fundamental issue with the above is that the package split in point (3) is wrong, more so in the context of the availability of a Solo5 cross toolchain. To explain why, we need to define what a Solo5 toolchain actually consists of:

Common headers.
Suitable host compiler (not part of Solo5) and flags to compile freestanding code, detected at Solo5 build time.
host tools.
some bindings, compiled for host.
Metadata to expose all of the above downstream via solo5-config, so that consumers can compile C code with (2)  and link against (4).

In the case of a Solo5 cross toolchain for a target, this becomes:

Common headers.
Suitable cross compiler from host to target (not part of Solo5) and flags to compile freestanding code, detected at Solo5 build time.
host tools.
some bindings, cross-compiled for target.
Metadata to expose all of the above downstream via solo5-config, so that consumers can compile C code with (7)  and link against (9).

It follows from the above that (1) and (6) and (3) and (8) are equivalent, i.e. host tools and headers should be built from the same OPAM package only once. It also follows that (2) determines (4) and (5) for a simple toolchain, while (7) determines (9) and (10) for a cross toolchain.
Fundamentally, the way #488 does things it is trying to express the above in terms of dependency and availability relationships between both the wrong set of, and too many different OPAM packages. With a cross toolchain, this would result in an explosion of yet more packages, e.g. solo5-bindings-XXX-aarch64.
Therefore, I believe we need a different, simpler, package split for OPAM. The following is a proposal which could work:

solo5: Installs host tools, common headers, some bindings (as available for host), some or none tenders (as available for host). Installs metadata describing a static toolchain. Availability: Union of all current solo5-bindings-XXX constraints.
solo5-config-ocaml-static: Depends on solo5 {=version}, selects static toolchain for ocaml-freestanding. Conflicts with (4).
solo5-aarch64: Depends on solo5 {=version} (for host tools, common headers), additionally installs some bindings cross-compiled for target (aarch64). Installs metadata describing a static-aarch64 cross toolchain. Availability: TBD, e.g. on Debian this would need a depext on gcc-aarch64-linux-gnu.
solo5-config-ocaml-static-aarch64: Depends on solo5-aarch64 {=version}, selects static-aarch64 toolchain for ocaml-freestanding. Conflicts with (2).
ocaml-freestanding: Depends on solo5_config_ocaml_static | solo5_config_ocaml_static_aarch64.
mirage-solo5, mirage-xen: Depend on solo5 and ocaml-freestanding.
Unikernel: Depends on mirage-solo5 or mirage-xen only, but see below.

Pros (compared to the current setup):

Less OPAM packages.
solo5 is installable as a single package, installs all bindings, tenders and toolchains available on host.
solo5-TARGET is installable as a single package, installs all bindngs and cross toolchains available on host for target.
cross-architecture compilation is possible.

Cons (compared to the current setup):

The mirage workflow would need to change. Currently, mirage configure -t <any solo5 TARGET> always works, and the following make depend step either "installs Solo5" (via a solo5-bindings-TARGET dependency in the generated opam file) or fails if solo5-bindings-TARGET is not installable on the host. With this proposal, OPAM only knows that "Solo5 is installable", which means that some bindings are available. I can think of the following alternative workflow:

mirage configure -t <any solo5 TARGET> --toolchain TOOLCHAIN (where toolchain defaults to static) causes the mirage tool to a) check that solo5-config-ocaml-TOOLCHAIN is installed, and if not, prompt the user and install it if confirmed.
if the above succeeds, mirage then calls out to the now installed solo5-config to verify that the combination of --toolchain=TOOLCHAIN --target=TARGET is actually available on the host. If this fails then a friendly error is presented to the user.
If the above succeeds, mirage configures the unikernel to build for TARGET and TOOLCHAIN. Given that both the correct solo5-config-ocaml-TOOLCHAIN and solo5-TARGET package are already installed, make depend will proceed to install ocaml-freestanding and mirage-solo5 or mirage-xen appropriately.

gmp-freestanding and zarith-freestanding need to be updated to understand/work with a cross toolchain; this is the case for any proposal that allows for cross-architecture compilation.

Hi, I agree with you that something is wrong in the current proposal.
However I don't think we should drop the solo5-bindings-XXX packages.
They are still useful as they allow to describe the availability of the bindings.
I propose the following package split:

solo5-config-ocaml-static | solo5-config-ocaml-pie: conf packages describing conflicting sets of flags.
solo5-config-host | solo5-config-cross-aarch64 conf packages describing eventual cross-arch compilation.
solo5-config: depends on (solo5-config-host | solo5-config-cross-aarch64) & (solo5-config-ocaml-static | solo5-config-ocaml-pie)
configures solo5 with the selected options. Only installs solo5-config, which should contain all the information needed to build solo5 tools, bindings and tenders.
solo5: depends on solo5-config: installs host tools and common headers.
solo5-bindings-XXX: depends on solo5-config: installs bindings and tenders.
ocaml-freestanding: depends on solo5 (and solo5-config).

Configuration is done by selecting solo5-config-* packages, which can be done manually or generated by the mirage tool. Moreover it should be easy to express availability:

solo5-config-cross-aarch64: depends on conf-gcc-linux-gnu-aarch64.
solo5-config-host: available on (arch = "x86_64" | arch = "arm64") & (os = "linux" | os = "freebsd" | os = "openbsd")
solo5-bindings-(muen|xen|virtio): depends on solo5-config-host. available on arch = "x86_64".
solo5-bindings-genode: depends on solo5-config-ocaml-pie.

In comparison to @mato's proposal, this allows to select a solo5 target and let the opam solver find a configuration that builds that target.

Together with @TheLortex, after more discussion and iteration on both our proposals we have a third proposal of the Solo5 and ocaml-freestanding OPAM packaging split that we have decided to go for.
Basically we have three cursors to move:

quantity of opam packages
compilation time
co-installability

This proposal is  a trade-off between quantity of packages and compilation time, while maximizing co-installability.
Goals

support multiple combinations of Solo5 toolchains (host or cross-ARCH)
each Solo5 toolchain provides some set of bindings
least amount of maintenance going forward, with flexibility to add/remove Solo5 toolchains and bindings
non-goal: no support for cross-arch compilation with Mirage 3

OPAM package split
solo5: Installs all of Solo5 needed to build and run unikernels on the host:

common:
- headers
- tools for host
- tenders for host
toolchain(s) for host:
- some bindings for host architecture
- i.e. currently a single toolchain called static

solo5-cross-ARCH: Installs a Solo5 cross toolchain targetting ARCH:

cross toolchain(s) for ARCH:
- some bindings cross-built for ARCH
- i.e., using aarch64 as an example, currently a single toolchain called static-cross-aarch64.
depends on {solo5 =version} (for "common" components)
depext or dependency on conf-gcc-cross-ARCH, or some similar way to pull in the appropriate C cross compiler.

ocaml-freestanding: Installs all OCaml toolchains for installed Solo5 host toolchains:

builds and installs a separate freestanding sysroot for each Solo5 host toolchain
depends on solo5

ocaml-freestanding-cross-ARCH: Installs all OCaml toolchains for installed Solo5 cross toolchains targetting ARCH:

builds and installs a separate freestanding sysroot for each Solo5 cross toolchain for ARCH
depends on solo5-cross-ARCH

Mirage tool workflows
Mirage 4:

at configure time:
- User: mirage configure -t hvt [ --cross=ARCH ]
- tool queries via solo5-config, asking "is hvt available [ for cross-compilation to ARCH ]"?
possible outcomes:
- no solo5-config -> prompt user to install Solo5
- not available -> error
- available -> returns Solo5 toolchain / ocaml-freestanding sysroot to use
no more use of pkg-config at all (updates to gmp-freestanding, zarith-freestanding for Mirage 4 to make this work have already been done by @TheLortex)

Mirage 3:

as for Mirage 4, but no support for multiple toolchains or cross toolchains.
i.e. fail if the toolchain returned by solo5-config for any Solo5 target is not static
still uses pkg-config to get the single toolchain's flags from ocaml-freestanding (gmp-freestanding, zarith-freestanding do not change)
generated unikernel opam file depends on:
- ocaml-freestanding (i.e. host toolchain support only)
- mirage-solo5 OR mirage-xen.

Advantages

Solo5 (solo5-config) is the single "source of truth" for "which toolchains and bindings are available"
No need to maintain the answer to the above as a complex web of OPAM packages and interdependencies
Least amount of OPAM packages
All toolchain and bindings combinations are co-installable (though installing "everything" will substantially increase build time of ocaml-freestanding).
Mirage user gets immediate feedback at configure time on validity of target / cross-arch options.

#494 was merged via #506. I'm closing this issue.


setup done

fixes #1

fixes #1

@bethheal you can add reviewers, labels, and the issue it fixes just like I did in the description above. Great job.


Can't find node on windows

Using ST3 on Windows, I'm getting Error: Couldn't find "node" in "/usr/local/bin/node".
I already changed "node_path": "node.exe", in both Packages\Import Cost\import-cost.sublime-settings and Packages\User\import-cost.sublime-settings.
Even if the setting wouldn't work (does for other plugins), I would have expected to see a different error message than the one I get.
Is the value maybe still hardcoded somewhere?

Sorry for the late response. Hm, there shouldn't be anything hardcoded, maybe its not reading the settings file correctly 🤔 Does it give any additional error message in the "console"?
Could you try to change the error messages in https://github.com/julianburr/sublime-import-cost/blob/master/import-cost.py#L123 and https://github.com/julianburr/sublime-import-cost/blob/master/import-cost.py#L136 to be different to see where it actually errors out?

Hi. No worries about the delay, this is somewhat a luxury feature anyways :)
I'll check after my vacation, so it'll take even longer :)

The same issue. I've changed "node_path" to the right one, but it trying to look it in the default path.
Console output:

Error: Couldn't find "node" in "/usr/local/bin/node"
Traceback (most recent call last):
File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 514, in on_load
attach_view(v)
File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 365, in attach_view
check_view_event_listeners(view)
File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 359, in check_view_event_listeners
listeners.append(cls(view))
File "C:\Users\Username\AppData\Roaming\Sublime Text 3\Packages\Import Cost\import-cost.py", line 26, in init
self.update_phantoms()
File "C:\Users\Username\AppData\Roaming\Sublime Text 3\Packages\Import Cost\import-cost.py", line 39, in update_phantoms
self.calc_imports(imports)
File "C:\Users\Username\AppData\Roaming\Sublime Text 3\Packages\Import Cost\import-cost.py", line 77, in calc_imports
json_data = json.loads(data)
File "./python3.3/json/init.py", line 316, in loads
File "./python3.3/json/decoder.py", line 351, in decode
TypeError: expected string or buffer


Feedback Hub forum.

Due to the absence of a GitHub Discussions tab in this repository, there should be an official Feedback Hub forum. Not everyone is a developer, so many take to there by default rather than GitHub. As it is, despite the absence of an official forum, they post in there anyway, just in the wrong forums - https://feedbackportal.microsoft.com/feedback/idea/f9f21007-4200-ee11-a81c-000d3ae5b6f4?q=visual+studio+code+forum

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!

https://github.com/microsoft/vscode/issues/188576#event-11057121715

@isidorn, where best would this be requested? Or is there a reason for this being deliberately undesirable (such as the existence of https://github.com/microsoft/vscode/issues)?

This is a good place to request it, but it is right now out of scope. We might reconsider in the future. THanks for understanding.


doc(coder-server): code-server module does not have offline attribute

Doc mention offline suport
module "code-server" {
  source         = "registry.coder.com/modules/code-server/coder"
  version        = "1.0.7"
  agent_id       = coder_agent.main.id
  folder         = "/workspace/${local.folder_name}"
  install_prefix = "/workspace/.coder-server"
  offline = true
  settings = {
    "workbench.colorTheme" : "Visual Studio Dark"
    "workbench.startupEditor" : "readme"
  }
  extensions = [
    "ms-python.python",
    "hashicorp.terraform",
    "ms-azuretools.vscode-docker"
  ]
}

However there is no filed for this
Error: Unsupported argument
on main.tf line 219, in module "code-server":
  219:   offline = true
An argument named "offline" is not expected here.

closes #181

Thoughts on adding the missing attribute instead of removing the example in docs? This can be useful for installations where code-server is baked into the image.

Thoughts on adding the missing attribute instead of removing the example in docs? This can be useful for installations where code-server is baked into the image.

It would be nice to have this feature (which i mention in the github issue), but currently the docs are misleading.


Moving of NavigationBar

In Preparation for Refactoring

Pull Request Test Coverage Report for Build 4918

0 of 9 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.02%) to 28.405%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/feature/navigationBar/NavigationBar.tsx
0
9
0.0%

Totals

Change from base Build 4916:
-0.02%

Covered Lines:
3205

Relevant Lines:
9994

💛  - Coveralls


how to respond to the request after the preflight?

When I make a POST via axios, it first sends an OPTIONS preflight request, then the regular request. Both are returned as successful to the browser with code 200. However, the .then only intercepts the response for the preflight request. How can I respond to the second, actual POST request's response? There are no errors. This is a client application (VueJS).
I don't think it matters, but the payload is {path: filePathOnServer} where filePathOnServer is a string of a UNC.
this.$axios.post('/inpatientPDFs/snr/download', payload, { responseType: 'blob'
          /* headers: {
            'Content-Type': 'application/x-www-form-urlencoded',
            'Access-Control-Allow-Origin': '*'
          } */
        }).then(res => {
          console.log('am i downloading?', res)
          const blob = new Blob([res.data], { type: res.data.type })
          const url = window.URL.createObjectURL(blob)
          const link = document.createElement('a')
          link.href = url
          const contentDisposition = res.headers['content-disposition']
          let fileName = 'unknown'
          if (contentDisposition) {
            const fileNameMatch = contentDisposition.match(/filename="(.+)"/)
            if (fileNameMatch.length === 2) {
              fileName = fileNameMatch[1]
            }
          }
          link.setAttribute('download', fileName)
          document.body.appendChild(link)
          link.click()
          link.remove()
          window.URL.revokeObjectURL(url)
        }).catch(err => {
          console.log('or do i have an error?', err)
        })

Any ideas? My other POST requests all get caught by the .then section, even though they too have OPTIONS/POST double requests. The others are all JSON form entry results. This is the first and only PDF I'm sending from the server. Still stumped on why the .then isn't handling it since it doesn't seem there should be a difference.
To reiterate, I understand why the OPTIONS request gets sent. I don't want to avoid sending it. I have a lot of axios.post calls that work just fine, but they all just send JSON and get JSON back. In this case, I'm sending JSON, which contains the name of the PDF file to return, but it isn't handled in the .then this time. I'm out of ideas to try. Help!

I got it working half way. Not sure what I did. The data of the POST is making it through, but the headers are incomplete. My popup window which is just supposed to initiate a download of the PDF is working and is downloading the right file. The only part not working is the part checking the Content-Disposition.
So I may be more confused. Content-Disposition of the POST isn't in res.headers.
Res.headers shows this when console logged from .then:
cache-control: "public, max-age=0"
content-type: "application/pdf; charset=utf-8"
last-modified: "Wed, 24 Jul 2019 23:19:49 GMT"

But when I inspect the headers in the dev tools on chrome, I see these:
Accept-Ranges: bytes
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://pharmacyinformatics.local
Cache-Control: public, max-age=0
Connection: keep-alive
Content-Disposition: attachment; filename="antibiotics_active^CVLB^2019-07-24T16%19.pdf"; filename*=UTF-8''antibiotics_active%5ECVLB%5E2019-07-24T16%2519.pdf
Content-Length: 21019
Content-Type: application/pdf; charset=utf-8
Date: Wed, 24 Jul 2019 23:20:16 GMT
ETag: W/"521b-16c26489f9b"
Last-Modified: Wed, 24 Jul 2019 23:19:49 GMT
Strict-Transport-Security: max-age=15552000; includeSubDomains
Vary: Origin
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Powered-By: Express
X-XSS-Protection: 1; mode=block

Where are the rest of these?

Hi @rconstantine, since it appears that only one question in this is related to Express, I will answer that.  The rest I would recommend posting on Stack Overflow.

Where are the rest of these?

There are many headers which express will set (X-Powered-By for example).  In the case you posted above it appears that you are responding with a file download.  So some of the headers are the ones required to do that.  My guess is that you also have some other http server in front of express, because express will not by default set things like Strict-Transport-Security and X-DNS-Prefetch-Control.

Thanks. Somehow I thought I posted this to the axios issue queue. I must have had them both open and entered the wrong one. Thanks for the help anyway. I'll also ask on SO.


Implement rocket booking - Actions

Issue Requirements

When a user clicks the "Reserve rocket" button, action needs to be dispatched to update the store. You need to get the ID of the reserved rocket and update the state. Remember you mustn't mutate the state. Instead, you need to return a new state object with all rockets, but the selected rocket will have an extra key reserved with its value set to true. You could use a JS filter() or map() to set the value of the new state

Regardless of which method you choose, make sure you place all your logic in the reducer. In the React view file, you should only dispatch the action with the correct rocket ID as an argument.

STATUS: APPROVED :green_circle:
Hi @Estete9    :wave: :wave:,
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉

Highlights

Cleanly written code :white_check_mark:
App runs well and functions as expected ✅
Great teamwork ✅

Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers, and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Save steps on field being edited even if unchanged on the server.

Easy way to demonstrate this is edit an incident summary without hitting return or exiting the summary text field (in Cocoa nerd: "avoid invoking the action"), then save.  The changes get wiped out.

Actually I think the real problem here is that we don't capture that edit when we do save, not that we clear it out when the incident comes back from the server.

Same cause as #56.  Same fix works.


Fix: notify expiration only if the latest expire time is changed when getItem or SetWithTTL

If the latest expire time is changed, no need to notify expiration.
Benchmark Result

BenchmarkName
Before
After

BenchmarkCacheSetWithoutTTL-8
1140 ns/op
297.1 ns/op

BenchmarkCacheSetWithGlobalTTL-8
1508 ns/op
772.2 ns/op

BenchmarkCacheSetWithTTL-8
1648 ns/op
808.6 ns/op

According the benchmark result, it has 2~3 times performance improvement

By the way, can we get a release version later at your convenience? I need recent commits for my project.


Replace Boostrap Star Rating

As I saw in the docs https://docs.simplcommerce.com/en/latest/how-to-add-new-languages/ adding one language is a headache little bit, because there're many places I should add a localization for.
IMHO we can replace the current star rating with something like https://codepen.io/alisuarez/pen/RWGNLm so no localization is required, FYI I tweaked the sample to cover disable case too
If sound is good I will push a PR for it

Now I'm fine to close this after PR #802


Bottom left branch name should show current file's branch

Issue Type: Bug
Open a file from one repository that is in your open folder;
Open a file from another repository that is in your open folter;
Bottom left branch name should be referring to the current file's repository branch name, but it is not.
VS Code version: Code 1.22.1 (950b8b0d37a9b7061b6f0d291837ccc4015f5ecd, 2018-04-06T02:26:57.615Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (8 x 2592)

Memory (System)
31.86GB (24.55GB free)

Process Argv
C:\Program Files\Microsoft VS Code\Code.exe

Screen Reader
no

VM
50%

Extensions: none

/findDuplicates

I suggest to enable this as a setting.

@joaomoreno is it worth PRing this?

If there's anything I can do to fix the bug and someone can explain the work to be done, I'd be happy to.

@joaomoreno this is so awesome. This bug kept me from using VS Code for the longest time. Any idea about which version this fix would become available in? Please and thank you for fixing this!

1.28 should be available around the first week of October. Don't thank me, thank @egamma and @kieferrm for planning an issue reduction milestone!


Stack overflow

I'm writing benchmark.
	sol::state state;
	state.script("lua_function=function(i)return i;end");
	sol::function f = state["lua_function"];
	std::string teststring = "testtext";
	for (int i = 0; i < 1000000; ++i)
	{
		std::string result = f(teststring);
		if (result != teststring) { throw std::logic_error(""); }
	}

this code crashed at gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)　with '-O3 -DNDEBUG -std=c++14'
error message:
terminate called after throwing an instance of 'sol::error'
  what():  lua: error: stack overflow

Do you know what's bad?

Yeah, I had messed up a bit of math in function when I refactored it between protected_function and function: just fixed it right now. Do another pull and you should be all set.

Also, I'm interested in the results of the benchmarks: please do share! I'm going to be writing some of my own benchmarks using kaguya here when I'm done doing some template stuff for overloading.

wow , you already had project.
I has created two days ago, because don't knew
https://github.com/satoren/lua_binding_benchmark


feat: support self minted 5-byte wide BRC-20 tokens

This PR implements the proposal as specified in https://l1f.discourse.group/t/brc-20-proposal-for-issuance-and-burn-enhancements-brc20-ip-1/621/1

:tada: This PR is included in version 3.1.0-beta.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


3.5.2: pytest fails

I'm packaging your module as an rpm package so I'm using the typical PEP517 based build, install and test cycle used on building packages from non-root account.

python3 -sBm build -w --no-isolation
because I'm calling build with --no-isolation I'm using during all processes only locally installed modules
install .whl file in </install/prefix> using 'installer` module
run pytest with $PYTHONPATH pointing to sitearch and sitelib inside </install/prefix>
build is performed in env which is cut off from access to the public network (pytest is executed with -m "not network")

Here is pytest output:
r/lib/python3.8/site-packages
+ /usr/bin/pytest -ra -m 'not network'
==================================================================================== test session starts ====================================================================================
platform linux -- Python 3.8.18, pytest-7.4.4, pluggy-1.3.0
rootdir: /home/tkloczko/rpmbuild/BUILD/markdown-3.5.2
collected 1111 items / 1 error

========================================================================================== ERRORS ===========================================================================================
_____________________________________________________________ ERROR collecting tests/test_syntax/extensions/test_md_in_html.py ______________________________________________________________
/usr/lib/python3.8/site-packages/_pytest/runner.py:341: in from_call
    result: Optional[TResult] = func()
/usr/lib/python3.8/site-packages/_pytest/runner.py:372: in <lambda>
    call = CallInfo.from_call(lambda: list(collector.collect()), "collect")
/usr/lib/python3.8/site-packages/_pytest/python.py:814: in collect
    self.warn(
/usr/lib/python3.8/site-packages/_pytest/nodes.py:304: in warn
    warnings.warn_explicit(
E   pytest.PytestCollectionWarning: cannot collect test class 'TestSuite' because it has a __init__ constructor (from: tests/test_syntax/extensions/test_md_in_html.py)
================================================================================== short test summary info ==================================================================================
ERROR tests/test_syntax/extensions/test_md_in_html.py::TestSuite - pytest.PytestCollectionWarning: cannot collect test class 'TestSuite' because it has a __init__ constructor (from: tests/test_syntax/extensions/test_md_in_html.py)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
===================================================================================== 1 error in 0.54s ======================================================================================

List of installed modules in build env:
Package            Version
------------------ -------
build              1.0.3
cppclean           0.13
distro             1.8.0
dnf                4.18.2
exceptiongroup     1.1.3
gpg                1.23.2
importlib-metadata 7.0.1
iniconfig          2.0.0
installer          0.7.0
libdnf             0.72.0
packaging          23.2
pluggy             1.3.0
pyproject_hooks    1.0.0
pytest             7.4.4
python-dateutil    2.8.2
PyYAML             6.0.1
setuptools         69.0.3
six                1.16.0
tomli              2.0.1
wheel              0.42.0
zipp               3.17.0

Try using plain unittest instead of pytest:
python -m unittest discover -v

Correctly written unittest based test suite can be correctly handled by pytest.

It appears that Pytest is tripping over our use of the load_tests Protocol here:
https://github.com/Python-Markdown/markdown/blob/08dacae618775831243f6bbab47d9be590d511f2/tests/test_syntax/extensions/test_md_in_html.py#L1210-L1216
In this module, we import the TestHTMLBlocks unittest class and in a subclass override the extensions to include the md_in_html extension. In that way those tests get run a second time with the extension enabled, ensuring that the extension does not alter the default behavior. The problem is that unittest discover would then run the tests 3 times, once in their original location, once imported here, and once for the subclass. Therefore, we make use of unittest's load_tests Protocol which involves defining a load_tests  function which returns an instance of a TestSuite class which explicitly sets which tests to run from that module.
Your error message suggests that PyTest does not like the TestSuite class our load_tests function returns. However, we are using an instance of a standard TestSuite class. I don't know enough about PyTest to know if it even can work with the load_tests protocol and/or TestSuite or if there is something special one would need to do to get it to work.
And, quite frankly, we don't need it to work with PyTest. That said if you can get it to work while at the same time keep things working as they are for us, then you are free to submit a PR. I'm willing to review a PR so long as the solution continues to use the standard lib only (PyTest is not in the standard lib so we are not interested in using it here). However, I am not interested in spending any more time on this than that.

Oh and by the way, this report suggests that this error was introduced in the latest release (3.5.2). However, this code has been in place since version 3.3 (released in 2020). If this just stopped working for you now, then the issue is elsewhere. Maybe you are using a newer version of PyTest which introduced a bug or dropped support or something???

And, quite frankly, we don't need it to work with PyTest. That said if you can get it to work while at the same time keep things working as they are for us, then you are free to submit a PR. I'm willing to review a PR so long as the solution continues to use the standard lib only (PyTest is not in the standard lib so we are not interested in using it here). However, I am not interested in spending any more time on this than that.

That is OK however as I wrote "correctly written unittext based test suite can be correctly handled by pytest".
Try to think as well that your module when it is integrated into whole distribution when it is packaged test suite execution is part not only your modules testing but any other package installed in build env as well.
In other words such test suite has use case wider than only your needs ..
pytest is far more advanced and pluggable. This framework testing can alter testing process by simple install pytest extensions.
Just in case .. I'm not trying to suggest switching to pytest. I'm only trying to tell that what you've wrote is 100% correct however this is not whole picture 😋

But our tests are fine. It is the load_tests protocol that Pytest is tripping on and our code matches almost exactly with the documented way to support the protocol. My assumption is that the problem is with PyTest's support (or lack thereof) of the load_tests protocol. Until you can prove to me that the problem is with our code, I'm not spending any more time on this.

I would suggest you open an issue over at Pytest regarding load_tests protocol and see what they say. While I can understand your desire to unify all the distributions you are managing with pytest, it is not explicitly necessary, and I don't think it is appropriate to suggest projects drop fully supported approaches to unittests just to unify pytest usage. Pytest advertises that it works with unittests, if this is not the case, they should fix that.

I just did a quick search and turned up pytest-dev/pytest#992 which acknowledges that Pytest does not support the load_tests protocol and has no plans to. Although, someone could write a plugin which does support it (maybe one exists, I didn't check). As the load_tests protocol is part of the standard feature set of the unittest lib, which we are using in its standard form, then this is completely on pytest, not us. I am closing this.


[need help] cannot build the software in vs code

I installed vs code and load the repo folder. If I press ctrl+shift+B to build the software, I get directly the error:
> Executing task: bash apollo_docker.sh build <

bash: ./apollo.sh: Permission denied
The terminal process terminated with exit code: 126

Terminal will be reused by tasks, press any key to close it.

btw, I start vscode as root user to avoid any permission issues and building from following user/group:
root@PC:/media/root/WD/Work/ApolloRepo#
Thanks for any advice.

You shouldn't start vscode from as root. It works another way. I think you have similar issue #5259

Hｉ， gladijos, I still get following error:
> Executing task: bash apollo_docker.sh build <

Error response from daemon: Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority
docker: Error response from daemon: Conflict. The container name "/apollo_map_volume-sunnyvale_big_loop" is alreadyin use by container "1afb560ec21360a5a6c0861e30ed9371afbcdae40343672a51dc7248ece33d1a". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.
Error response from daemon: Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority
0f6f9c9923c341ed2c962fe0f8d59149f66404540e960ba658331c8a133ba101
[INFO] Start docker container based on local image : apolloauto/apollo:local_dev
modprobe: FATAL: Module nvidia not found.
modprobe: FATAL: Module nvidia-uvm not found.
Error response from daemon: Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority
8114b12f25ea124ea7359728d6e68e8317135064dd1b160e935e0d844619a528
Error response from daemon: Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority
857e78b54c03bf517e3090b208a2b860933cb81de1710cc7f041da023a694b21
[INFO] Starting docker container "apollo_dev" ...
Unable to find image 'apolloauto/apollo:local_dev' locally
docker: Error response from daemon: Get https://registry-1.docker.io/v2/: x509: certificate signed by unknown authority.
See 'docker run --help'.
[ERROR] Failed to start docker container "apollo_dev" based on image: apolloauto/apollo:local_dev
Error: No such container: apollo_dev
The terminal process terminated with exit code: 1

Terminal will be reused by tasks, press any key to close it.

@ironsuperdev Probably you have issues with certificates. I'm not close with certificates. Can you pull another docker images?
Also check https://docs.docker.com/install/linux/docker-ce/ubuntu/#set-up-the-repository and https://docs.docker.com/registry/insecure/#troubleshoot-insecure-registry. I think it isn't apollo's problem but docker one.
P.S. For remove first issue you can remove image manually docker rmi

Looks like you cannot pull the docker image due to some certificate issue. We haven't done any test in VS Code. Please explore and search the Internet to see if there's any solution to your issue.


Fix SSL and specs for 0.18

Tuple literals are now declared with the old syntax for hash literals, breaking several specs. SSL has also been moved around a bit and renamed.

Beat me to it! 👍

Thanks 👍


bump deps

Can one of the admins verify this patch?

@lucasponce  or @jotak - take a look at the build failure here. I do NOT see this locally - builds fine for me and the server works. But travis is producing the following error:
23:57:41,181 ERROR [org.jboss.as.ejb3.invocation] (ServerService Thread Pool -- 64) WFLYEJB0034: EJB Invocation failed on component InventoryConfig for method public java.nio.file.Path org.hawkular.inventory.service.InventoryConfig.getConfigPath(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 <IP_ADDRESS>.1 concurrent access timeout on InventoryConfig - could not obtain lock within 5000MILLISECONDS

ok, I take this

Marking DNM because I'm not sure the labeling is working correctly with these src-deps.  This has nothing to do with the build failure reported above.  A travis restart resulted in green.

@jshaughn started to look at it.
Locally, it passes, so probably as @jshaughn says, travis error is not related due a problem in the code.

I didn't look at it.  I just hit the restart build button to see if it pass.  @lucasponce do we need to now add comments whenever we restart a travis build?

removing DNM label. My issue is because I wasn't starting P with the correct config to get the 'feed_id' label applied server-side.


Playback streamed audio buffer

I have an arrayBuffer which I want to playback as a stream. Is this possible?

you can use this as a ref on android
https://github.com/google/ExoPlayer/issues/7228


Fix: Fix external links

Hi everyone,
We have several issues with external links:
First, from the tagline, instead of pushing a route with the push() method, we used go() thus clearing the history.
Second, due to bugs, we now force the external browser on non-Android platforms, as it's broken otherwise.
Third, with external links, we may have no history (due to the go() method) -> in that case, we go back to the homepage.
Fourth, external links with multiple levels (eg: cgi/reset_password.pl) were ignored by GoRouter
It will fix #5750 and #5753

Codecov Report
Attention: Patch coverage is 0% with 12 lines in your changes missing coverage. Please review.

Project coverage is 7.01%. Comparing base (4d9c7fc) to head (8f46a08).
Report is 400 commits behind head on develop.

Files with missing lines
Patch %
Lines

.../smooth_app/lib/pages/navigator/app_navigator.dart
0.00%
6 Missing :warning:

...ages/smooth_app/lib/helpers/launch_url_helper.dart
0.00%
3 Missing :warning:

.../smooth_app/lib/pages/navigator/external_page.dart
0.00%
3 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           develop   #5754      +/-   ##
==========================================
- Coverage     9.54%   7.01%   -2.54%
==========================================
  Files          325     407      +82
  Lines        16411   21816    +5405
==========================================
- Hits          1567    1530      -37
- Misses       14844   20286    +5442

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


Add this library to conda-forge recipes

Hello, I'm currently trying to upload a package that my company is writing to conda-forge, which depends on dirhash. It doesn't seem like this package is uploaded to conda-forge, so would it be possible to also host it there alongside PyPI? I'm more than happy to take care of it myself (all it involves is adding a .yaml file in the right place), but I wanted to run this by the maintainers here to see if this is something y'all would be okay with. Thanks!

Can you still do this?

Can't find this on conda-forge.


Optimize slow test TriggerInstanceProcessorTest#testProcessTermination

Squashing the lowest hanging fruit from https://github.com/azkaban/azkaban/issues/2114.
1st commit: Prove that sendEmailLatch is not incremented in testProcessTermination

Adding this assertion makes the test fail

2nd commit: Fix mocking of overloaded method -> test passes quickly now
It's actually best to leave the new assertion on CountdownLatch in place even though the problem was fixed. Because it will make the test fail instead of just being slow & succeeding, if the bug with skipping CountdownLatch is ever introduced again.

@juhoautio why would this fix optimize the test slowness by adding the assert??

@burgerkingeater assert doesn't optimize the test, but:

It's actually best to leave the new assertion on CountdownLatch in place even though the problem was fixed. Because it will make the test fail instead of just being slow & succeeding, if the bug with skipping CountdownLatch is ever introduced again.

@burgerkingeater anything else?

@juhoautio 2nd commit: Fix mocking of overloaded method -> test passes quickly now do you know how much time save this fix brings and why?

@burgerkingeater usually it saves 9-10 seconds. Without this fix the test was always blocking the full 10 seconds on the countdown latch. Now it's only blocking until the latch triggers, which usually takes less than a second.


All files of the System

Hi Team,
How to add all the folders and sub-folders of the system on graphite?
Thanks,
Siddharth

Hello,
Could you please elaborate your question a bit? It’s not clear tbh what you
mean
On Mon, 8 Apr 2019 at 11:19, N SIDDHARTH<EMAIL_ADDRESS>wrote:

Hi Team,
How to add all the folders and sub-folders of the system on graphite?
Thanks,
Siddharth
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/graphite-project/graphite-web/issues/2438, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABK51hTVPsn2bDFfowXifUmqYuxmcCfRks5vewmUgaJpZM4chsZ6
.

Yes, I want to see all the folders and sub folders on the particular users account when they log in.
I have integrated Graphite with Grafana.

Could you please be more specific?

I can only see a single folder on each server, My requirement is to see all the folders in each server,

I can only see a single folder on each server, My requirement is to see all the folders in each server,

Are you sending the data you want to see to Graphite?
Please note that Graphite is "just" a database, it does not collect data, it can only show you data which you send it.

Okay. So which tool should I install to see all files of my PC through graphite?

If you want help from others it helps by explaining exactly what you want to achieve and be specific about it. I still have no clue what you are asking.

Okay. So we have many folders residing in my machine. For example, you see nciwin folder on above photo right? Like that I've folder called energy, drive1 etc. inside the servers. But it's displaying only nciwin folder.
I want to list all the folders, That's my aim. @piotr1212

Your answer just raises more questions to me. I'm sorry can't help you.


dts: stm32f103: add missing dts binding for port G

STM32F103 micros starting from 64-pin (xE) packages upward have
available port G. This patch defines a dts binding for them.
Signed-off-by: Pavel Kral<EMAIL_ADDRESS>

Codecov Report

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

@@           Coverage Diff           @@
##           master   #11256   +/-   ##
=======================================
  Coverage    53.1%    53.1%
=======================================
  Files         218      218
  Lines       26887    26887
  Branches     5954     5954
=======================================
  Hits        14277    14277
  Misses      10174    10174
  Partials     2436     2436

Continue to review full report at Codecov.

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


feature request: Support FriendlyName  CurrentResolution

The current display name is not easy to read, it would be more friendly if the exact device name could be displayed. When using a 4k screen with a scale of 1.5, it seems that the information is not accurate. Ideally, add CurrentHorizontalResolution and CurrentVerticalResolution or get the correct scale property to calculate the display resolution
name: "\\\\.\\DISPLAY1",
width: 2560,
height: 1440,
scale_factor: 1.0

name: "\\\\.\\DISPLAY1",
width: 3840,
height: 2160,
friendly_name: "LG ULTRAGEAR" ,
CurrentHorizontalResolution: 2560,
CurrentVerticalResolution:  1440,
scale_factor: 1.5

Hello! Will friendly_name be added?

I'm also having an issue where my width and height is incorrect because my scale on Wayland KDE is set to 1.25 and my application requires the correct width and height of a user's monitor.
I hope this is looked into.


created endpoint for getting all user Urls and added middleware to access token

This PR solves issue #17

@abhijeetnishal all changes mage that you told , as well as middleware is implemented

Hey @atharvarekhawar, i have added comments regarding your doubts on previous PR.
I request you to go through the basics of API and backend concepts with Node.js (express) so that you can do it easily as fundamentals are important. Focus more on learning rather than completing task open source is mainly for this.

sure @abhijeetnishal

Hey @atharvarekhawar, could you push the changes to same PR #65, don't create separate PR until it's necessary.

Once done close this PR

hey , @abhijeetnishal I had pushed changes to both the PR at the time , you can check #65 , changes are already present.
I will be closing this PR now.

hey , @abhijeetnishal I had pushed changes to both the PR at the time , you can check #65 , changes are already present.
I will be closing this PR now.

hey , @abhijeetnishal I had pushed changes to both the PR at the time , you can check #65 , changes are already present.
I will be closing this PR now.

Great @atharvarekhawar, I will review today


Show "Move up"/"Move down" context menu items on folder nodes in the Solution Explorer

Fixes #2050

Just realised we should also have "Add Above" and "Add Below" on the folder context menu - I'm investigating now.

@saul does it work as expected?

@vasily-kirichenko yes, see #2050 for what the problem was

@saul This is great!

@saul, when we get CPS this will need to be ported to the CPS based project system.

@saul
Thanks for this
Kevin


CreateMenu is not always called.

Is it possible to force CreateMenu to be called after every CanShowMenu call? I need to customize the context menu for each file selected but CreateMenu is only being called after the first file selected.

@gair I wanted to the exact same thing, after a little struggle I figured out a way to do it, I just added an example and made a pull request, I have written an article to explaining this. (links below)
Article:
http://www.codeproject.com/Articles/1035998/NET-Shell-Extensions-Adding-submenus-to-Shell-Con
Pull request:
https://github.com/dwmkerr/sharpshell/pull/94

Looks like this can be closed, but please re-open if needed.


Crash when using the mod

I'm unable to use this mod

java.lang.RuntimeException: Could not execute entrypoint stage 'main' due to errors, provided by 'way2wayfabric'!
	at net.fabricmc.loader.impl.FabricLoaderImpl.lambda$invokeEntrypoints$2(FabricLoaderImpl.java:388)
	at net.fabricmc.loader.impl.util.ExceptionUtil.gatherExceptions(ExceptionUtil.java:33)
	at net.fabricmc.loader.impl.FabricLoaderImpl.invokeEntrypoints(FabricLoaderImpl.java:386)
	at net.fabricmc.loader.impl.game.minecraft.Hooks.startClient(Hooks.java:52)
	at net.minecraft.class_310.<init>(class_310.java:487)
	at net.minecraft.client.main.Main.main(Main.java:223)
	at net.fabricmc.loader.impl.game.minecraft.MinecraftGameProvider.launch(MinecraftGameProvider.java:470)
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:74)
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23)
	at org.prismlauncher.launcher.impl.StandardLauncher.launch(StandardLauncher.java:87)
	at org.prismlauncher.EntryPoint.listen(EntryPoint.java:130)
	at org.prismlauncher.EntryPoint.main(EntryPoint.java:70)
Caused by: java.lang.NoClassDefFoundError: net/blay09/mods/waystones/api/KnownWaystonesEvent
	at com.jimramsay.way2wayfabric.BlayWaystones.register(BlayWaystones.kt:22)
	at com.jimramsay.way2wayfabric.Way2WayFabric.onInitialize(Way2WayFabric.kt:228)
	at net.fabricmc.loader.impl.FabricLoaderImpl.invokeEntrypoints(FabricLoaderImpl.java:384)
	... 9 more
Caused by: java.lang.ClassNotFoundException: net.blay09.mods.waystones.api.KnownWaystonesEvent
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
	at net.fabricmc.loader.impl.launch.knot.KnotClassDelegate.loadClass(KnotClassDelegate.java:226)
	at net.fabricmc.loader.impl.launch.knot.KnotClassLoader.loadClass(KnotClassLoader.java:119)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
	... 12 more

with the latest version of minecraft, fabric, and waystones

Same here - v0.0.6 says it supports 1.20.4 but it seems to be using the old Waypoints API events.
I looked at the source (way2wayfabric-0.0.6.zip) and it doesn't seem to be the 1.20.4 branch version (it still uses KnownWaystonesEvent instead of WaystonesListReceivedEvent in BlayWaystones.kt).
Would it be possible to build the 1.20.4 branch as a jar and upload that as a release? The issue should be fixed by doing that.

Same here - v0.0.6 says it supports 1.20.4 but it seems to be using the old Waypoints API events.
I looked at the source (way2wayfabric-0.0.6.zip) and it doesn't seem to be the 1.20.4 branch version (it still uses KnownWaystonesEvent instead of WaystonesListReceivedEvent in BlayWaystones.kt).
Would it be possible to build the 1.20.4 branch as a jar and upload that as a release? The issue should be fixed by doing that.

You might want to send a PR to fix that when you have the time
I might do that if no one did

I generated the 1.20.4 branch and published as a release in my forked repo.
The game now is able to launch but it crashes for me when I try to place a waystone in the world

I checked in the Waystones repo and the API does indeed have getPos() as a function (https://github.com/TwelveIterationMods/Waystones/blob/1.20.x/shared/src/main/java/net/blay09/mods/waystones/api/Waystone.java) - not sure how to resolve this crash. Any ideas?

I generated the 1.20.4 branch and published as a release in my forked repo.
The game now is able to launch but it crashes for me when I try to place a waystone in the world

I checked in the Waystones repo and the API does indeed have getPos() as a function (https://github.com/TwelveIterationMods/Waystones/blob/1.20.x/shared/src/main/java/net/blay09/mods/waystones/api/Waystone.java) - not sure how to resolve this crash. Any ideas?

Unfortunately, I'm not familiar with minecraft api nor fabric
Yes, I can read any code written in java, but I do not necessarily understand it
Believe me I know less than you
You might want to create an issue in this repo for that exception

Thanks for the reminder...  I was part-way through the new implementation, but then hit some issues; I'll try to revive that soon!

Same here.
Worked find on 1.19.4 but now crashes every startup.

hullo, just to add that I have the same issue/version/error as original comment, in case this got lost and is an easy fix. No worries if not - already appreciate the open source efforts. Thanks to the previous commenters for troubleshooting too, wish I knew more about Java to make a PR myself.


Negative range with 3 anchors

I am implementing TWR with 3 anchors (DW1000Ranging_ANCHOR.ino). The ranges are accurate until the 3rd anchor is introduced at which point the anchor that connected 3rd gives negative distances.
Has anyone come across this issue and have a fix?

This issue seems to have gone after starting the anchors with non-random short addresses. I'm not going to close the issue in case the problem reemerges and this is just a coincidence.

Hey @christoshadjiaslanis ,
I've seen negative values at the beginning of my work with DW1000. It occured when the distance between devices was small (under 1m). I can honestly say that DW1000 are not working properly in small range (under 2m).

duplicate #121


[issue #400] enhance genesis usage instructions

Based on issue #400 :

Removed obsolete commands
Left the most used commands
Added reference to genesis help

The genesis readme and other documentation needs a complete rewrite, and will be done after v2.7.6 release.  Will incorporate these in where applicable.


Test: Screencast mode - Customize keyboard overlay timeout period

Refs: #105160

[ ] anyOS @aeschli
[x] anyOS @dbaeumer

Complexity: 2
Create Issue

We've added settings to customize the timeout period (screencastMode.keyboardOverlayTimeout) of the keyboard overlay in screencast mode. Enable Screencast Mode using the command palette and use the following steps to validate the two new settings:

Open the Screencast Mode settings and locate the Keyboard Overlay Timeout setting
Validate that the default value of the setting is 800.
Validate that you can only specify numbers for the setting.
Validate that you cannot set values outside the range of [500, 5000].
Change the setting value and confirm that the keyboard overlay timeout updates.

Works as advertised. Only question: why do we limit it to 5 seconds?

Thanks! No real reason other than I wanted to pick a reasonable upper limit.


Claims challenges

Core Library
MSAL.js v2 (@azure/msal-browser)
Core Library Version
2.32.2
Wrapper Library
Not Applicable
Wrapper Library Version
@azure/msal-browser": "2.32.2"
Public or Confidential Client?
Public
Description
When an endpoint invokes a claims challenge, does MSAL invalidate the current token? I noticed that when doing an MFA to satisfy the claims challenge and I deny the request, my current token becomes invalid and I have to re-authenticate.
Is this the expected behavior?
MSAL Configuration
{
auth: {
    clientId,
    clientCapabilities: ['CP1']
  },
  cache: {
    cacheLocation: 'localStorage',
    storeAuthStateInCookie: true
  }
}

Relevant Code Snippets
No response
Identity Provider
Azure AD / MSA
Source
Internal (Microsoft)

No, MSAL does not and cannot invalidate tokens. Can you please describe what exactly is the behavior you're seeing when you say the "current token becomes invalid"?

The issue was my code.
When I canceled the login popup for the claims challenge, I was still making an acquireTokenSilent call with a claims parameter even though the claims challenge was not fulfilled. So I was getting a 401 and my app was trying to re-authenticate.


fix merge_async_iterators usage for vLLM>0.5.4

merge_async_iterators now has an additional is_cancelled kwarg:
https://github.com/vllm-project/vllm/blob/main/vllm/utils.py#L405-L417

Codecov Report
Attention: Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.

Project coverage is 61.19%. Comparing base (8a7c5a2) to head (70877b3).

Files
Patch %
Lines

src/vllm_tgis_adapter/grpc/grpc_server.py
77.77%
1 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #86      +/-   ##
==========================================
+ Coverage   61.13%   61.19%   +0.06%
==========================================
  Files          20       20
  Lines        1181     1188       +7
  Branches      209      210       +1
==========================================
+ Hits          722      727       +5
- Misses        383      384       +1
- Partials       76       77       +1

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

I'm not sure that this is correct. It should return False if the client has cancelled/closed their connection.

I tested this and this is not the case.

I think that's a python grpc bug.

maybe I'll make a quick upstream PR for that.

Now done and it's merged upstream https://github.com/vllm-project/vllm/pull/7282, so maybe we can revert this change now...


Update Docker file to ADD to curl, build issue

Clean version of suggested https://github.com/BCDevOps/backup-container/pull/45
Resolves the following issue:
STEP 7: ARG GOCROND_VERSION=0.6.3
e55ddcc18af7ee9b5dea5822e3b9172f85bcee5eef6afb272e09d61d2013cdb8
STEP 8: ADD https://github.com/$SOURCE_REPO/go-crond/releases/download/$GOCROND_VERSION/go-crond-64-linux /usr/bin/go-crond
error: build error: error building at STEP "ADD https://github.com/$SOURCE_REPO/go-crond/releases/download/$GOCROND_VERSION/go-crond-64-linux /usr/bin/go-crond": source can't be a URL for COPY

Best practices may have changed, they currently suggest curl:
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#add-or-copy
I also had to move this operation, installing go-crond, after switching to ROOT so that curl had the permissions required to write to /usr/bin/

I've tested this by blowing away the entire deployment and repeating init through genBuild.sh a handful of times.
Pod backup-1-build consistently builds without issue now.


minor Add debug info in operators

Proposed changes
Issue Number: close #xxx

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

run buildall


Add ViewAreProhibited and ExternalKeyVault FLE tests.

Evergreen: https://evergreen.mongodb.com/version/5d9666762fbabe1c34b04830
Prose tests:
https://github.com/mongodb/specifications/blob/master/source/client-side-encryption/tests/README.rst#external-key-vault-test
https://github.com/mongodb/specifications/blob/master/source/client-side-encryption/tests/README.rst#views-are-prohibited
Kevin's repo: https://github.com/kevinAlbs/JavaFLEProsePoC/tree/master/src/main/java

Latest evergreen:  https://evergreen.mongodb.com/version/5d9dc94530661568ece216ba

Do you plan to merge this soon?

Do you mean merging into my fork? Probably I don't have rights to push changes in the upstream.

I squashed changes and rebased my branch on the latest upstream master: https://github.com/DmitryLukyanov/mongo-java-driver/commit/6539b570134b9f791d127eab56f51e7c7b742291

OK, I will merge them

Merged to master.


IE11 "Unable to get property 'value' of undefined or null reference"

🐛 Bug Report
We're seeing a bunch of breakage in production for IE11 users on this line in shallowCopy:
https://github.com/immerjs/immer/blob/master/src/common.js#L62
ownKeys(base).forEach(key => {
    if (key === DRAFT_STATE) {
        return // Never copy over draft state.
    }
    const desc = Object.getOwnPropertyDescriptor(base, key)
    let {value} = desc       // <- BREAKS: Unable to get property 'value' of undefined or null reference

On the micro level, one of the keys that gets returned from Object.getOwnPropertyNames (I don't know which one) appears to return undefined when calling Object.getOwnPropertyDescriptor with it, immediately after.
On the macro level, this is happening the moment we try to access an Immer draft, which is a plain object, like this:
  return produce(state, draft => {
    // ...
    const draftUserInfo = draft.userInfo   // this line blows up

Unfortunately, I can't get a repro, so this is more a call for help than a bug report. Any idea why this might be happening? Could Immer potentially be more defensive here, skipping over keys that don't have a property descriptor?
Environment

Immer version:
[ ] Occurs with setUseProxies(true)
[x] Occurs with setUseProxies(false) (ES5 only)

Duplicate of #336

In particular, see this comment: https://github.com/immerjs/immer/issues/336#issuecomment-473884546

Thanks so much for the pointer, @aleclarson. How about implementing the proposed workaround in #336 into Immer? It seems unlikely to hurt performance, and could benefit a lot of people who are going to run into this problem when they adopt Immer.

Someone could send a PR or open an issue for babel-preset-env to see if this bug could be polyfilled for those environments. Always be sure to test IE11 before shipping if your product wants to support it.

So you have a philosophical objection to fixing it?
I guess I'm a little confused because @mweststrate wrote:

if:

A work around is small (code wise)
Doesn't impact performance for non affected environments
Behaves semantically entirely the same as non affected environments (replacing exceptions with non-throwing deviating behavior is worse, not better)

Then we can be pragmatic and include a work around, clearly commented.

which seems clearly the case.

So you have a philosophical objection to fixing it?

No, but if IE11 is affected, babel-preset-env seems like a better place to fix it.

Note that the work around is also technically incorrect, as in, it makes
assumptions which might be false.
On Sat, May 11, 2019 at 2:12 PM Alec Larson<EMAIL_ADDRESS>wrote:

So you have a philosophical objection to fixing it?
No, but if IE11 is affected, babel-preset-env seems like a better place
to fix it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/issues/362#issuecomment-491505968, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAN4NBGP5LDFX7KLSE7MPN3PU2Z3XANCNFSM4HMG76LA
.

Turns out that workaround doesn't fix IE11. I'm unable to reproduce the issue, even in a Win7/IE11 session on Browserstack, but the website I work on is seeing hundreds of IE11 users affected by this issue in Immer.
For whatever reason, Immer's assumption that if it obtains an object key from getOwnPropertyNames or getOwnPropertySymbols, it can then retrieve a non-null descriptor for that key, isn't true in practice in some situation affecting IE11 users.
One workaround might be to make Immer more robust to this situation, by, say, skipping over properties that do not have a property descriptor when making a shallow copy. It would make the issue less fatal to us. But I understand you may not want to do that because it would be arguably incorrect behavior.
Continuing to debug this would exceed the time and effort that Immer is saving us to begin with, so regrettably, we're going to stop using Immer. I'm sorry I was unable to help track this down and resolve the root issue.

@graue You could always maintain a fork. :)
@mweststrate WDYT? Should we check for an undefined descriptor just to be safe?

What does skipping mean? That the entire property is suddenly gone in the
copy? I gladly see a small reproduction first to discover what this means
or in what circumstances this happens.
Op di 14 mei 2019 02:27 schreef Alec Larson<EMAIL_ADDRESS>
@graue https://github.com/graue You could always maintain a fork. :)
@mweststrate https://github.com/mweststrate WDYT? Should we check for
an undefined descriptor just to be safe?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/issues/362?email_source=notifications&email_token=AAN4NBAQRMEVLW4G5H2UZLTPVIBOVA5CNFSM4HMG76LKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVJ5LLA#issuecomment-492033452,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN4NBAYSI773EJX2U6P4ALPVIBOVANCNFSM4HMG76LA
.

@graue would you mind opening a fresh issue with reproduction, rather than replying to an old closed one The reason is that this is quite an generic error, that can be caused by Immer, but also by your own code (since the work around doesn't work for example), the HTML document mode (from what I've seen when googling for the error) etc.
So without small reproduction project in which we can analyze both the cause and the impact of an solution, we can't mean much for you. Probably you might need to find out what specific IE 11 version your users are using that are affected by this

@mweststrate, as I said, I'm going off widespread error logs in production (we use https://sentry.io/) and unfortunately cannot reproduce the issue myself. Not in Browserstack nor on my colleague's Windows machine that is running IE11 natively.
If I learn more I will certainly share, though.

The issue arise when js/jquery is not able to refer to the element. It is because at the time of rendering the page(view),  object is null or undefined - which means that there is no instance of a class in the variable. If you are getting data for object from an async call(api's), these kind of problems will arise. So you should always check the object whether it is null or undefined then if it is not, you can access its properties.
The standard way to catch null and undefined simultaneously is this:
if (variable == null) {
// your code here.
}
Because null == undefined is true, the above code will catch both null and undefined.
Also you can write equivalent to more explicit but less concise:
if (variable === undefined  variable === null) {
     // your code here.
}

This should work for any variable that is either undeclared or declared and explicitly set to null or undefined.
In most cases it is related to getElementById(). So getting a value from an input could look like this:
var value = document.getElementById("frm_new_user_request").value
Also you can use some JavaScript framework, e.g. jQuery, which simplifies operations with DOM (Document Object Model) and also hides differences between various browsers from you.
Getting a value from an input using jQuery would look like this:
input with ID "element": var value = $("#element).value
input with class "element": var value = $(".element).value


Receiving bad packages when sending requests very fast

I need some help. I'm sending a lot of packages in a very short time to create a smooth changing. Somehow, I receive a bad package after every correct package. I'm not sending this kind of packages. The values are all black which creates a flickering, not a smooth transition. Does anyone of you had this issue in the past?

Hi, i would need more information in order to help you. Please note that this library is not yet finished, but basic functionality should work.
Could you provide a code example using which i can reproduce this issue? You state you are sending values 'very fast', but how fast is 'very fast'?