Installation error

ComfyUI-Manager: EXECUTE => ['C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe', '-m', 'pip', 'install', 'basicsr==1.3.5']
Execute install/(de)activation script for 'C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\ComfyUI\custom_nodes\deforum-comfy-nodes'
Collecting basicsr==1.3.5
Downloading basicsr-1.3.5.tar.gz (161 kB)
------------------------------------ 161.4/161.4 kB 744.4 kB/s eta 0:00:00
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'done'
Requirement already satisfied: addict in c:\comfyui_blyat\comfyui_windows_portable_nvidia_cu121_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from basicsr==1.3.5) (2.4.0)
Collecting future (from basicsr==1.3.5)
Downloading future-0.18.3.tar.gz (840 kB)
-------------------------------------- 840.9/840.9 kB 3.8 MB/s eta 0:00:00
Preparing metadata (setup.py): started
Preparing metadata (setup.py): finished with status 'error'
[!]   error: subprocess-exited-with-error
[!]
[!]   python setup.py egg_info did not run successfully.
[!]   exit code: 1
[!]
[!]   [6 lines of output]
[!]   Traceback (most recent call last):
[!]     File "", line 2, in
[!]     File "", line 34, in
[!]     File "C:\Users\USER01\AppData\Local\Temp\pip-install-4qdn0ljs\future_38f2d17a6881404ab51fc93aa7015518\setup.py", line 86, in
[!]       import src.future
[!]   ModuleNotFoundError: No module named 'src'
[!]   [end of output]
[!]
[!]   note: This error originates from a subprocess, and is likely not a problem with pip.
[!] error: metadata-generation-failed
[!]
[!] Encountered error while generating package metadata.
[!]
[!] See above for output.
[!]
[!] note: This is an issue with the package mentioned above, not pip.
[!] hint: See above for details.
install/(de)activation script failed: C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\ComfyUI\custom_nodes\deforum-comfy-nodes

Issue is with the embedded python of your installation, suggested fix:
Install comfy from source in a venv created manually, then reinstall the node package.

Are you planning on making it comfy-portable friendly or..? Most users do use portable versions, so this might be a good idea (if there’s no restrictions to complete it)

Sure, I'll look into it, but it's about installing basicsr and future in a venv, which is normally very straightforward, so the embedded python implementation has some issue. You can just recreate the venv in your portable comfy using windows's built in python, and keep using the same 'portable' version.

Will look into it, thanks.

Reopening the issue to indicate that this was fixed by removing basicsr from the requirements, and by bumping pandas requirement version. You can now install Deforum Nodes to a portable ComfyUI installation as well.

Have you checked if it works? I've just uninstalled and installed once again via manager and here I am again with
Traceback (most recent call last):
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\ComfyUI\nodes.py", line 1893, in load_custom_node
module_spec.loader.exec_module(module)
File "", line 940, in exec_module
File "", line 241, in call_with_frames_removed
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\ComfyUI\custom_nodes\deforum-comfy-nodes_init.py", line 1, in
from .deforum_nodes.deforum_node import NODE_CLASS_MAPPINGS, NODE_DISPLAY_NAME_MAPPINGS
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\ComfyUI\custom_nodes\deforum-comfy-nodes\deforum_nodes\deforum_node.py", line 34, in
from deforum import DeforumAnimationPipeline, ImageRNGNoise
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\python_embeded\Lib\site-packages\deforum_init_.py", line 4, in
from .generators import (ComfyDeforumGenerator,
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\python_embeded\Lib\site-packages\deforum\generators_init_.py", line 2, in
from .film_interp_generator import FILMInterpolator
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\python_embeded\Lib\site-packages\deforum\generators\film_interp_generator.py", line 4, in
from ..models.FILM.inference import FilmModel
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\python_embeded\Lib\site-packages\deforum\models_init_.py", line 3, in
from .depth_models.depth import DepthModel
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\python_embeded\Lib\site-packages\deforum\models\depth_models\depth.py", line 16, in
from .depth_midas import MidasDepth
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\python_embeded\Lib\site-packages\deforum\models\depth_models\depth_midas.py", line 10, in
from ...utils.file_dl_util import download_file_with_checksum
File "C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\python_embeded\Lib\site-packages\deforum\utils\file_dl_util.py", line 6, in
from basicsr.utils.download_util import load_file_from_url
ModuleNotFoundError: No module named 'basicsr'
Cannot import C:\ComfyUI_BLYAT\ComfyUI_windows_portable_nvidia_cu121_or_cpu\ComfyUI_windows_portable\ComfyUI\custom_nodes\deforum-comfy-nodes module for custom nodes: No module named 'basicsr'

Yes, the solution is to uninstall your deforum package from the portable virtual environment. I'll work on an uninstall/reinstall script that makes sure this purge happens, in the meanwhile you can navigate to your comfy_portable_folder/python_embeded/Lib/site-packages and delete both deforum and deforum-0.1.8.dev1.dist-info folders. Then click "Try fix" in ComfyUI Manager on Deforum Nodes. It should reinstall the backend requirement, not needing basicsr anymore, and also bumping the used pandas version to work woth python 3.11.

Thanks! It did work, will try to play with it now)


Two packages for one formula

I am attempting to write a cask for ScanSnap Manager for the S300M scanner. If you look at the "Update" tab of that page, you can see that for OS X 10.8+ you need to install V2.2L11 and then V2.2L16.
Do you have any ideas how to create a cask for this?
I plan to put it in homebrew-cask-versions, but I thought the question was applicable for any cask.

depends_on :cask is functional, so we can close this. Thank you, @saulshanabrook.


Simplify some request specs

Maybe at some intermediate stage of development it was necessary to
specify a type name on entry creation here. By now, we can do without
that, so these specs can be simplified.
REDMINE-17508

I think this change misses the point of the spec. The whole spec is about defining a frontend_app for a custom entry type called test and then testing how the published entry HTTP endpoint behaves for entries of that type. Some requests might not actually make it all the way to the custom app since they are blocked by authorization logic etc. early on, but still each spec should be about interacting with an entry of the defined entry type. Removing the entry type, will still make most of the specs work (as this PR shows), but risks to test something completely different, namely that the frontend app defined by the default paged entry type has the desired behavior. But we want to test that this behavior can be achieved with any custom frontend app.

Interesting. I had never tried to understand what that frontend_app parameter is for, but reading the documentation, I now understand what that is. Indeed, this 'simplification' makes things a little too simple


[Register flow] Register with a mail address fails

Steps to reproduce:

start Riot
press register
provide a mail address, a user name, a password
press register
check your mailer and press the registration link
on Riot app, acknowledge the captcha verification step
riot app displays "missing password"

Seems like a regression due to server API modification.
Fix candidate:
Once the result of the captacha is received (onActivityResult() in LoginActivity), contrary to what was done before, it seems the client needs to send the username, the password and the bind_email (Cf. RegistrationParams class in SDK)

On webclient the same flow succeeds


Days are not updated when the day ends

If you keep the view turned on during the night and startingDay is set to today (or not set at all), the first day shown the next morning is yesterday.
When fetching the events there should be a check if startDay is still the correct start day.

This has been fixed in the dev branch and will be included in the release of version 1.6.0


Avoid serializing objects that shouldn't be part of oidc well-known endpoint

Adding the @Getter lombok annotation made is so Jackson tried to dump the entire cas config to JSON, it didn't get all the way through but it dumped part of the config to the browser before it got an exception and stopped.

Coverage increased (+0.003%) to 47.825% when pulling<PHONE_NUMBER>81745d54d44fa91c24061c3abdbb27 on hdeadman:oidc into 8f861336f134e72d69cd76d16c6d2d574041affd on apereo:master.


DX Tool Failed

Hola,
Having an issue building my project for Android. I can build for iOS no problem, but any time I run "Package Android [debug|release]" I get:

Adobe AIR code signing password:
dx tool failed:
The terminal process terminated with exit code: 17

Right after entering my password.
I know the password is right as entering a wrong password (or invalid path to a .p12 file) will throw an error as such.
I am using AIR 31 with a .p12 file that works fine if I try to build the same project via FLA in Adobe Animate. JDK version is 1.8.0_111
I've googled a bit and see some issues from years past with older 32bit certs, but this is def a 64 bit cert, and as I mentioned, it works fine in Animate. Sadly, as it just says failed with no text after, I don't have much to go on.
Any ideas?

This thread seems to indicate that using a newer Java 1.8 update may help:
https://forums.adobe.com/thread/2281743
Also, if you have multiple Java versions installed, it may be a good idea to try the setting that tells vscode-as3mxml to use a specific Java path (just to be sure that it isn't trying to use an unexpected version).

That same thread mentions that the 32-bit and 64-bit builds of the same JVM may behave differently, so it might be worth noting whether your Java version is 64-bit or not.

Thanks Josh,
Neglected to mention I did try setting the java path in my settings for the workspace to what AIR should be using.
That adobe thread is similar to the others I found which seems to point to the java version, but the odd thing is that it works fine in animate.
Thought I’d post in case I was kissing something obvious, but will continue to tinker and share if I find a solution.
Thanks!

Solved. Unsure why, but the "as3mxml.java.path" setting was being ignored, so I set the 64 bit version in path and restarted VSCode


Latest master fails to build with rust 1.38.0

Following upgrade from rust 1.37.0 to 1.38.0, latest master fails to build with the following error and lots of warnings:

   Compiling env_logger v0.6.1
   Compiling rustc_version v0.2.3
error: proc-macro derive panicked
  --> /home/neil/.cargo/registry/src/github.com-1ecc6299db9ec823/grin_secp256k1zkp-0.7.7/src/key.rs:32:10
   |
32 | #[derive(Zeroize)]
   |          ^^^^^^^
   |
   = help: message: unknown zeroize attribute: (drop)
error: aborting due to previous error
The following warnings were emitted during compilation:

Thanks for reporting, its fixed now. You will get some warning regarding missing dyn keywords but you can safely ignore them, they will be addressed in a future PR.


RFC: Stabilize the #![no_std] attribute

Stabilize the #![no_std] attribute while also improving the ergonomics of
using libcore by default. Additionally add a new #![no_core] attribute to opt
out of linking to libcore.
rendered

Can we avoid stabilizing the lang items but do the rest? That will mean libcore is only stable to use when std is also linked, but I don't think that is a problem (for now). We still get the benefits of making the macros use core, and anybody actually writing kernel code will need unstable core features anyways.
There is a lot of jank in some those lang items as the RFC admits, and eh_personality is somewhat tied to libcompiler/libgcc. Also the fact that the undefined items problem in core and alloc are being defined in two different ways is worrysome---crate level "functors" a la the MLs that any library could use or define or instantiate would be better.

I propose that extern crate core; should be injected regardless of #![no_std]. This would make it easier to write #![no_std] libraries that contain macros which will work regardless of if the consumer crate is no_std or not.

Proposal: don't stabilize any lang items at all, due to the aforementioned arguments.
One of the current major problems of no_std is that writing libraries that work across both settings is very tedious - it currently involves maintaining a tangled mess of #[cfg] attributes which is rarely tested before release. Stabilizing lang items do nothing to improve this situation anyways.

I agree about not stabilizing any language items here, if this is just for allowing no_std library crates.
However - if stabilizing these language items will allow compilation of no_std binaries (using an externally defined entrypoint, instead of #[start]) then maybe.

Overall, I'm convinced over the long haul we can reduce the complexity of these implementation details (w.g.. with crate functors, stabilized rust without exceptions), so I rather leave them unstable as long as possible. Complexity is worse than instability for the foreseeable future.

@Tobba I thought $crate solved core/std selection issues in macros.

@eddyb As far as I know it only works for referencing the current crate.

@Ericson2314, @Tobba, @thepowersgang

Can we avoid stabilizing the lang items but do the rest?

This is certainly an alternative! (which I have now added) The consequence of this decision is there will be no stable method of producing a staticlib or dylib which uses #![no_std] everywhere. I would personally like to enable this use case as having #![no_std] doesn't seem too useful without it. We can avoid stabilizing the exact signatures with the #![lang_items_abort] alternative mentioned, but there may be other ways to enable the use case of producing a final artifact without defining the precise signatures.

@Tobba

I propose that extern crate core; should be injected regardless of #![no_std].

Unfortunately I think this is not backwards compatible.

This would make it easier to write #![no_std] libraries that contain macros which will work regardless of if the consumer crate is no_std or not.

That's a good point, I've added a drawback to this RFC.

What's the point of stabilizing #![no_core]?  It's not like it would actually be usable in stable Rust.
It makes zero sense to require users to provide an implementation of eh_personality. Assuming users don't do something weird, if you're not linking to libstd, there's no way to unwind, and therefore the eh_personality implementation will never be called.  (Weird things here include manually calling _Unwind_RaiseException and unwinding through rust code by accident.)
A variant of the #[lang_items_abort] proposal: define an #[abort] attribute, as an alternative to all three lang-items.  Say it has the signature fn abort(msg: &core::fmt::Arguments)->!, we call it whenever we hit any unrecoverable condition.  It isn't allowed to unwind.

@eefriedman libcore can panic (and thus unwind), that's why this weak lang item contraption exists in the first place.

@eddyb libcore can panic, sure, but without libstd's implementation of panic_fmt, it isn't possible to actually unwind.

@eefriedman As a practical matter, I think rustc demands eh_personality to generate pads assuming panic_fmt is defined to unwind. But certainly I agree this is not an ideal situation, and a great reason why even the existence of eh_personality, not just its signature, shouldn't be stabilized.
@alexcrichton

I would personally like to enable this use case as having #![no_std] doesn't seem too useful without it

Again, I don't think instability around Rust in the kernel is a problem, now or in the foreseeable future.

#[no_std] makes sense as an attribute, it's fairly easy to tell what it's doing - #[no_core] however seems counterintuitive - it isn't exactly clear that it's also assuming #[no_std].
Would it be possible to add a separate attribute, something like #[prelude()]? It would be used like #![prelude(core)] or #![prelude(none)], and #![prelude(std)] would be assumed if it isn't declared. I wouldn't be sure about the name "prelude", but I think it would make more sense to have using std, core or no injected dependency/prelude should all be under one attribute, rather than multiple ones.

@daboross #![no_std] #[prelude] extern crate core; is actually what I expected the future direction to be.
Maybe we can still generalize prelude injection to custom and/or multiple crates.
That said, we also need to replace #[prelude_import]'s order-based glob priority with something proper, e.g. prelude glob imports can be overridden by glob imports which, in turn, can be overridden by explicit imports.

All crates (including libstd) should be treated equally. There should be nothing that libstd can do that any other crate can't.
Firstly, I'd agree with @eddyb: introduce #[prelude] to manually use the prelude of the marked crate. This removes the special treatment of libstd's prelude. And we don't want to treat libcore's prelude special either, so let's not do #![no_core] and instead require #[prelude] extern crate core for users that want to use libcore and its prelude.
Then  for at least eh_personality and stack_exhausted I'd add stub implementations that can be overridden by the user. Most users using #![no_std] don't need any special behavior here. However, overriding these stubs would be unstable, such that their signatures may change in the future. Libstd is just another crate overriding these stubs, and not special in that regard.
Finally, by default any Rust crate would implicitly include #[prelude] extern crate std; unless #![no_std] is specified. Then #![no_std] would mean no defaults instead of no libstd and prelude, which I think is more logical.

@Virtlink

Firstly, I'd agree with @eddyb: introduce #[prelude] to manually use the prelude of the marked crate

The question about what to do with preludes is somewhat orthogonal to the #![no_std] story, there's a separate RFC for dealing with custom preludes.

let's not do #![no_core] and instead require #[prelude] extern crate core for users that want to use libcore and its prelude.

The problem with this is that Rust isn't very useful without extern crate core because of the lang items that it defines, and we ideally want the #![no_std] case to be just as ergonomic as the normal use case, and we wouldn't necessarily expect all users to write extern crate std;

My first priority is not stabilizing those lang items, but I'd prefer @eddyb's end goal too. Treating all crates as equally as possible an admirable goal, and one #[prelude] extern cate core; is but a tiny decrease in ergonomics.
In fact if we had proper glob-import priority like @eddyb requests, we could just do something like:
extern crate core;
use core::prelude_v1::*;

Even simpler!

I believe the story of custom preludes or how we treat the prelude of core/std is firmly orthogonal to this PR. Whatever system we have for custom preludes will have some form of desugaring, but it's not related to #![no_std].
The #![no_std] attribute disables only the injection of std. This attribute instead switches the injection to be the core crate. The purpose of this is that #![no_std] is basically useless without extern crate core, so having it imply extern crate core seems quite useful.
What this means is that connecting #![no_std] and #![no_core] to prelude injection is a little bit of a red herring. You can think of the injection as the package "inject prelude and name" mechanism and these attributes are just switching what's injected.

@alexcrichton While implicit extern crate and implicit #[prelude] are technically orthogonal, I don't see how #![no_std] still linking libcore is anything but a workaround the fact that we don't have a better prelude story. Do you think #[prelude] extern cate core; is sufficiently inconvenient to motivate adding another attribute #![no_core] to the language and treating libcore (more) specially?

@Ericson2314

Do you think #[prelude] extern cate core; is sufficiently inconvenient to motivate adding another attribute #![no_core] to the language and treating libcore (more) specially?

Yes
--
I've now updated this RFC to recommend #![lang_items_abort] as a crate attribute instead of stabilizing the lang items instead.

Alternatively, instead of trying to specify what we don't want to use (#![no_std], #![no_core]), might we specify what we do want to use? And if not specified, default to libstd.
Something like #![runtime(core)] if you want to use libcore, #![runtime(none)] if you want none of that, and #![runtime(std)] would be the implicit default. Such that if this is too inconvenient:
#![no_std]
#[prelude] extern crate core;

then surely this is nicely concise:
#![runtime(core)]

@Virtlink yeah the precise name of the attribute is up for grabs, but I'd be somewhat wary of runtime(foo) as it looks like you can pass an arbitrary value in when in fact only three will suffice. I do think that having to write extern crate core is inconvenient as it's basically required by all Rust programs in existence so it doesn't make much sense to omit. It also establishes a clear convention with core being at the top of every #![no_std] crate of how items are idiomatically imported.

Indeed, it may look like #![runtime(foo)] accepts any arbitrary value, but that may not be that much of an issue. If a user ventures into no-std-land, I might hope they know what they're doing. On the other hand, an advantage of it is that, if ever, Rust ships with an alternative libstd's (e.g. for embedded devices with limited I/O and no threading), then you'd easily add another option #![runtime(embedded_std)]. It's extensible!

Today, however #![no_std] and #![no_core] are both extensible already, I don't think we want to invent too many ways to auto-inject a crate. For example we currently inject extern crate std into all Rust programs because requiring this annotation for every Rust program in existence is seen as too onerous. Similarly if you decide to opt out of std it's required for all those programs to link to core, so I believe it's too onerous to require that you actually declare you link to core.
I don't know why we would want to have another option for this runtime attribute, because at that level of customization it's not something we're expecting all Rust program in existence to have to worry about. That's the case where you just use extern crate and whatever custom prelude mechanism we have.

Okay, imaginary future runtimes aside, there are just three options: libstd, libcore, and neither. With #![no_std] and #![no_core], there are four combinations, one of which doesn't make sense.
When encountering such a situation in my programs, I'd put those three options in an enum, which is what my #![runtime(core)] idea meant to illustrate.

I've now updated this RFC to recommend #![lang_items_abort] as a crate attribute instead of stabilizing the lang items instead.

Cool!

Yes

Well..,
Another thing to keep in mind that affects both #![no_core] and #![runtime(???)] is that different environments use different subsets of the crates behind the facade. For example, core + alloc may be pretty standard for some applications. If/when things like libfs and libnet and made (the needs discussed in https://github.com/rust-lang/rfcs/pull/185 are often still unaddressed), the practical subsets won't be identifiable by on unique library(e.g. core -> {core}, alloc -> {core, alloc}.

This attribute will behave the same as #[lang] in terms of uniqueness, two crates declaring #![lang_items_abort] cannot be linked together and an upstream crate declaring this attribute means that no downstream crate has to worry about it.

This is kind of uncomfortable since its easy to write code that can't be linked downstream. Who is expected to write this attribute?

Who is expected to write this attribute?

I would expect end users creating a staticlib, dylib, or executable to define this attribute. If you're just working on an intermediate rlib then there shouldn't be a need to define these attributes.

This RFC is now entering its week-long final comment period.

Will #![lang_items_abort] be stabilized? I am unsure from the current wording of the RFC.

@Ericson2314 it'll probably follow the standard "introduce as unstable and stabilize later" pattern, so it will likely not be immediately stabilized but it will be on track to be stabilized soon.

I'm unclear exactly what this stabilization immediately enables. Are the lang items necessary to build a library?

Glad they will be unstable to begin with.

I'm concerned about iteratively stabilizing nostd without a clear path forward. I feel that we run the risk of closing off options in the future with little immediate gain. There are still outstanding problems with no clear solution - e.g. it's very ugly to write libraries that work in both nostd and std environments.
Do we have any sense of how many crates would be stabilized by this? Can we in some way quantify the immediate gain here?

@dschatzberg

There are still outstanding problems with no clear solution

This RFC is intended to solve both of these statements, do you have further outstanding problems or do you think that this RFC doesn't suffice?

it's very ugly to write libraries that work in both nostd and std environments

Do you think this will still be the case after this RFC is implemented?

Do we have any sense of how many crates would be stabilized by this?

Unfortunately, no. The use case of "write a library which only depend on core" is not possible to do so in a stable fashion today, but that will become stable after this RFC is implemented.

it's very ugly to write libraries that work in both nostd and std environments

Do you think this will still be the case after this RFC is implemented?

Perhaps I'm not understanding. Suppose I have a crate which exports a macro which references core (because the crate is intended for nostd usage). If I use this macro in a regular (not nostd) binary will it build?
Another pain point is that there are a number of crates out there which do not have dependencies on std, just core but nonetheless do not use nostd. I'm not sure that stabilizing the nostd attribute will be sufficient - many developers may just not know about their dependencies.
Additionally, cross-compiling using cargo requires pretty ugly hacks (https://github.com/rust-lang/cargo/issues/1606) because the core crate is treated specially.

Suppose I have a crate which exports a macro which references core (because the crate is intended for nostd usage). If I use this macro in a regular (not nostd) binary will it build?

This is an explicit drawback listed in this RFC. It doesn't appear like a solution to this problem will fundamentally change the design of this RFC, so I don't personally see a reason to block on something like this.

Another pain point is that there are a number of crates out there which do not have dependencies on std, just core but nonetheless do not use nostd. I'm not sure that stabilizing the nostd attribute will be sufficient - many developers may just not know about their dependencies.

I'm not sure what you mean by this? If a crate doesn't declare #![no_std] then it's pretty easily to silently depend on it as many std-only types (e.g. Vec/String) are in the prelude. If you opt in to #![no_std] then you don't have access to any of these.
Do you want the compiler to automatically infer whether std is depended on or not?

Additionally, cross-compiling using cargo requires pretty ugly hacks (rust-lang/cargo#1606) because the core crate is treated specially.

This also seems fairly orthogonal to this RFC. That primarily has to do with cross compilation and new targets the compiler wasn't originally configured for and that is a separate matter from stabilizing no_std.

I'm not sure what you mean by this?
My viewpoint is as someone who writes nostd binaries. I often see crates that I could use, if only they had declared #![nostd]. I don't see stabilizing the attribute as solving this problem. On the other hand, when I write similar code in C++ - as long as the libraries I include and link to don't rely on the standard library, then I'm all set (and the authors of those libraries never had to have my intention in mind).

I'm not arguing for a particular solution to this or any of the raised concerns - but I see this RFC as taking a step down a path I'm not sure we want to head down and for very limited value. To be clear - the only immediate advantage we get out of this is that, once implemented, developers can write nostd libraries so long as they do not use libcore, and these libraries cannot be used to produce a nostd binary, right?

I don't see stabilizing the attribute as solving this problem. On the other hand, when I write similar code in C++ - as long as the libraries I include and link to don't rely on the standard library, then I'm all set (and the authors of those libraries never had to have my intention in mind).

I'm not sure what you're arguing for here; is the issue just that core and std have different names/APIs?  That's probably worth discussing: if it's too much work to convert a library to be usable on no_std mode, there will never be any substantial number of no_std libraries available on crates.io.

@dschatzberg

I often see crates that I could use, if only they had declared #![nostd]. I don't see stabilizing the attribute as solving this problem.

Right, but I don't think that anything we do will "solve" this problem per se. It needs to be an explicit decision to not use the standard library, and it's not one the compiler can really make automatically for you. Moving to no_std is a backwards-compatible decision so I suspect that many crate authors would be quite amenable to PRs or issues reporting that they can work with std.

and the authors of those libraries never had to have my intention in mind

While this may work sometimes, it's a very dangerous thing to rely on. An author may decide to all of a sudden start using the standard library in a minor version bump, breaking any code you may have that relied on it not using the standard library. It's much clearer if authors have to explicitly opt-in to this behavior as it's often a major design decision.

To be clear - the only immediate advantage we get out of this is that, once implemented, developers can write nostd libraries so long as they do not use libcore, and these libraries cannot be used to produce a nostd binary, right?

Authors can most certainly use libcore! Because the standard library links to libcore the two can interoperate seamlessly. The libcore Option type is the same as the standard library's Option type, so a no_std library can certainly work with another crate that's using the standard library. These libraries can also be used to all produce a binary so long as the #![lang_items_abort] tag is present.
Could you clarify on why you think that nostd libraries can't use libcore, or why you think they can't be used to produce a binary?

@eefriedman

Is the issue just that core and std have different names/APIs? That's probably worth discussing: if it's too much work to convert a library to be usable in no_std mode, there will never be any substantial number of no_std libraries available on crates.io.

Yeah it's definitely the intention that libraries written with no_std can work with libraries that are not no_std. The naming of the APIs doesn't matter because it's all just reexports in the standard library.
The hierarchy of core may be slightly different than the standard library, but overall it should largely be basically the same.

@dschatzberg and @eefriedman I think the best part about about this RFC is that #![lang_items_abort] provides a path for how we can eventually stabilize enough of core to make it worthwhile to use in stable code, even if some hooks needed to use core without std aren't stable. Then libraries like bitflags can be written against core, and we won't need to go around forking them.
I too would love a future where people write libraries that incidentally work in a freestanding context without the original authors knowing or caring. I think the best way to get there would be to get rid of std altogether and just have the crates behind the facade (cleaned up for public consumption, of course), but due to stability at the very least, that won't happen any time soon.

@alexcrichton

Right, but I don't think that anything we do will "solve" this problem per se
...
It's much clearer if authors have to explicitly opt-in to this behavior as it's often a major design decision.
I tend to agree with you. But my fear is that this RFC closes off options to resolving these problems in the future. This is why I'm so keen to understand what exactly we're enabling here.

My understanding is that libcore is not being stabilized by this RFC. To me, this means that, with this RFC implemented, I cannot write no_std libraries which use libcore in stable Rust. Furthermore, I cannot create nostd binaries in stable Rust. Is this correct?
My primary objection to the RFC isn't so much the content as it is the approach of bit-by-bit stabilizing no_std. I'd be happier with a larger RFC which actually mapped out how all the pieces fit together so we can debate whether or not it's worth committing to stabilizing all of it. My fear is that each smaller piece we stabilize is still committing us without any of the necessary debate about the larger picture.

@dschatzberg

My primary objection to the RFC isn't so much the content as it is the approach of bit-by-bit stabilizing no_std.

The vision in this RFC is:

Tweak #![no_std] and add #![no_core]
Add #![lang_items_abort]
Start stabilizing libcore
Start stabilizing various attributes.

This follows our normal process of not insta-stabilizing a large number of new features all at once but rather taking more conservative steps. The designs in this RFC are likely to become stable after some time, however. That being said there is certainly a vision for building no_std binaries on stable Rust. Do you think this is not the right path? Would you like to see other changes?

I feel that this RFC commits us to stabilizing a large number of features (at some point) without knowing what exactly those are. I'd agree with a conservative approach but only in so far as each step actually buys us something we can gain experience from. This proposal stabilizes functionality which doesn't really change the status quo - no_std practically requires unstable Rust.

@alexcrichton
To be clear, I'm fine with making changes (and the particular changes this RFC proposes) and making them conservatively. What I object to is piece-wise stabilization in this case. The only upside I could see for stabilizing a portion is that it would give us more experience to stabilize the rest - but I don't believe that's true in this case because (nearly) all the use cases will still require unstable Rust just like today. The downside is that we stabilize something that we regret in the future - I don't think this will happen in this case, but I'm accepting that it is a possibility.
I rather see us iterate on no_std in unstable Rust until we're happy with stabilizing a more significant portion with which we can gain the experience to do the rest.

I assume we're basically stabilizing the stuff in core that is verbatim re-exported in std. (Option, Iterator, ops, ptr, etc...). Maybe shuffling around the locations to look more like std does today.

@alexcrichton So I spend an inordinate amount of time working with no_std via working on the facade libraries, and I have to say my absolute biggest pain point is that code doesn't cleanly migrate from no_std to std. I would be very happy if a std library/program saw core::BLAH and interpretted it correctly without having to specify extern core or be no_std.
This would enable pulling code out much more easily.
I understand this may be too magic.

@dschatzberg

I feel that this RFC commits us to stabilizing a large number of features (at some point) without knowing what exactly those are.

Can you be a little more specific? I'm having a hard time understanding what these "unknown features to be stabilized" are. The path I laid out doesn't have any unknown parts of it.

What I object to is piece-wise stabilization in this case.

I think there's a disconnect happening here. These aren't being stabilized in a pipeline because they're dependent on each other (e.g. one informs the next), they're being stabilized as part of the standard stabilization pipeline. No feature goes from RFC to insta-stable, and this RFC is a reflection of that. The pieces in this RFC are all pretty much orthogonal.
Overall I think it'd be helpful if you put your concerns in a bit more concrete terms for me. You mention that this is piece-wise stabilization, but I've mentioned before that this is just our process, it's not intentionally waiting on lots of dependencies. You also mention that this RFC doesn't know what features it will stabilize, but I'm under the impression that it's pretty clear on what exactly will be stabilized, so it'd help to hear more about which pieces of the RFC you think are too vague or could use clarification.

@Gankro

I assume we're basically stabilizing the stuff in core that is verbatim re-exported in std. (Option, Iterator, ops, ptr, etc...). Maybe shuffling around the locations to look more like std does today.

Yeah, core is basically ready for stabilization today, it just largely needs an auditing pass.

I have to say my absolute biggest pain point is that code doesn't cleanly migrate from no_std to std

Can you elaborate on what these pain points are? I'm under the impression that adding extern crate core to any std program will basically allow no_std code to be dropped in in-place. There's also the macro case but that seems relatively minor and is listed in the drawbacks section of this RFC.

I would be very happy if a std library/program saw core::BLAH and interpretted it correctly without having to specify extern core or be no_std.

I personally think this is too much magic, I believe an annotation to explicitly opt-in to no_std is a pretty important declaration of a crate and accidentally using String to silently start using std seems pretty bad.

To clarify I don't want a crate to be magically no_std (although that would be kinda cool...) I just want code from a no_std crate to work verbatim in a std context.
If extern crate core works in conjuction with a std library, that might be acceptable (I was under the impression that might unlock a vortex to hell or something.

@alexcrichton

I'm having a hard time understanding what these "unknown features to be stabilized" are.

The RFC states that it does not attempt to stabilize lang items because

The exact set of these lang items is somewhat nebulous and may change over time.

I'm starting to wonder if the idea is that #[lang_items_abort] will be the only way to define them in stable Rust rather than this just being a step on the way to stabilizing these language items. Is this where our disconnect lies?

You mention that this is piece-wise stabilization, but I've mentioned before that this is just our process.

What is the upside of stabilizing a portion of the language/libraries that doesn't immediately enable more code to be written in stable Rust? Also, I couldn't find this process documented anywhere, do you have a link?

(Sorry, sorry...)

Yeah, core is basically ready for stabilization today, it just largely needs an auditing pass.

Well, it definitely needs an auditing pass; see https://github.com/rust-lang/rust/issues/27200 .

@steveklabnik But de-referencing never de-references!
Or in less confusing terms, de-referencing creates an lvalue from a pointer, but only using that lvalue (or some sub-component thereof) as an rvalue actually reads from it.
That is, if the value is not zero-sized. Pointers to zero-sized values can have any value (except null if they're references, Box, Vec, etc.).
Unless the zero-sized type in question is uninhabited. Now that can be implemented as injecting unreachable aka UB.
enum Hell {}
fn open(vortex: &Hell) {
    *vortex; // Don't try this at home.
}

@Gankro

If extern crate core works in conjuction with a std library, that might be acceptable (I was under the impression that might unlock a vortex to hell or something).

Yeah that works just fine today, you can write extern crate core in any program and nothing bad should happen.

@dschatzberg

I'm starting to wonder if the idea is that #[lang_items_abort] will be the only way to define them in stable Rust rather than this just being a step on the way to stabilizing these language items. Is this where our disconnect lies?

For now, yes, but there's not much of a use case for actually defining any of these lang items. The personality/stack exhausted functions will never actually be called and the panic function is the only one that may want to really be overridden. The questions there are the precise signature and how one might define it, and it doesn't seem like this RFC should be totally blocked on answering these questions.
If you'd prefer to stay on unstable Rust then this attribute can be avoided and the lang items can be defined manually. I don't really consider this an unknown feature to be stabilized because we know precisely what this is as well as why we aren't stabilizing it. I mention that the exact set is nebulous because it may shrink over time, it's highly unlikely to never grow. Defining #![lang_items_abort] is the conservative route for now to allow this on stable Rust soon-ish. This attribute will not land insta-stable so if it turns out no one needs it stabilized then we can avoid stabilizing it.

What is the upside of stabilizing a portion of the language/libraries that doesn't immediately enable more code to be written in stable Rust?

I'm not sure I understand this question in the context of this RFC. By stabilizing no_std and the core library then it is indeed immediately enabling more code to be written in stable Rust. We can start having a whole #![no_std] ecosystem of libraries to choose from. The end users may have to run on nightly for a brief period of time, but in the meantime we can prepare the ecosystem and libraries for doing all kinds of operations at this layer.

Also, I couldn't find this process documented anywhere, do you have a link?

@Gankro has written an excellent RFC on this topic.

@alexcrichton

By stabilizing no_std and the core library then it is indeed immediately enabling more code to be written in stable Rust.

Doesn't this RFC explicitly state that it is not stabilizing the core library?
I don't see anything in the linked RFC that implies that the RFC process prefers piecewise-stabilization or a feature. Could you point to the specific language?

Doesn't this RFC explicitly state that it is not stabilizing the core library?

Ah by that all I meant is that this is not explicitly debating the details of how to stabilize core. That will all happen naturally with the standard library stabilization process (it's orthogonal to this RFC).

I don't see anything in the linked RFC that implies that the RFC process prefers piecewise-stabilization of a feature. Could you point to the specific language?

This is implied by the fact that there's a pipeline for every new feature. Some features of the no_std story (like no_std and libcore) are already in the pipeline. Others like #![lang_items_abort] and #![no_core] have yet to enter the pipeline.

Reading @Gankro's RFC, I'm thinking that we are doing the wrong thing by changing the meaning of no_std and immediately stabilizing it. I interpret that RFC as saying APIs must be introduced in their final form for at least 1 cycle. It would be good for that RFC to be clarified either way.

APIs need not be in their final form before being stabilized. They just need to go through an FCP, at the end of which it is reasonable to make a minor tweak (as is the case for RFCs). The beta-period ensures that they will be in their final form for a whole period before hitting stable.

That will all happen naturally with the standard library stabilization process (it's orthogonal to this RFC).

I disagree that it is orthogonal. I don't see how we can get value out of this RFC without also stabilizing libcore. Therefore, I object to doing one without the other. You'll understand if "that's just the way we do it" isn't a satisfying response.

No one proposes not stabilize libcore.
On Jul 22, 2015 07:38, "Dan Schatzberg"<EMAIL_ADDRESS>wrote:

That will all happen naturally with the standard library stabilization
process (it's orthogonal to this RFC).

I disagree that it is orthogonal. I don't see how we can get value out of
this RFC without also stabilizing libcore. Therefore, I object to doing one
without the other. You'll understand if "that's just the way we do it"
isn't a satisfying response.
—
Reply to this email directly or view it on GitHub.

I understand that - my issue is that this proposal asks us to implicitly accept a future proposal stabilizing some parts of libcore. If that's the case then it should be one RFC that proposes both so we can debate its merit.

The #![lang_items_abort] crate attribute seems backwards to me. When would you not want to use that attribute and at the same time not have any implementation for the lang items panic_fmt, stack_exhausted and eh_personality? I can't think of any reason.
Instead, I think the default lang items implementation should be "as if it called the intrinsics::abort function", unless overridden in a crate. Two crates that both override the same lang item cannot be linked together, and downstream crates never have to worry about the lang items. They are either implemented by an upstream crate (often libstd), or use the default intrinsics::abort implementation. This allows a crate to implement just panic_fmt without caring about the rest (which is something I use in my kernel to display a blue screen on kernel panic), and there's no need for the #![lang_items_abort] crate attribute.
Additionally, defaulting to intrinsics::abort is future-proof and reduces breaking changes. For example, when a new lang item is added for some platform or backend, your proposal breaks all creates that override one lang item and don't care about the rest. With the default intrinsics::abort implementation, those crates don't break. And if a lang item's signature is changed, or the lang item is removed, then it breaks only those crates that override the lang item and actually care about it, and other crates remain unaffected.

When would you not want to use that attribute and at the same time not have any implementation for the lang items panic_fmt, stack_exhausted and eh_personality?

All no_std rlibs want this. If I'm writing a library I don't want to have to worry about the implementation of these lang items, so I don't want to write an implementation and I don't want to use the attribute.

Instead, I think the default lang items implementation should be "as if it called the intrinsics::abort function", unless overridden in a crate. Two crates that both override the same lang item cannot be linked together, and downstream crates never have to worry about the lang items.

This is basically what this RFC proposes (it's how lang items work). The only difference is that this RFC does not propose the compiler silently filling in these definitions (but rather requiring an explicit annotation to opt-in).
The reason that the items aren't being stabilized at this time is that there's extra debate to have about the signatures and it's unclear to what degree they need to be stabilized.

Additionally, defaulting to intrinsics::abort is future-proof and reduces breaking changes. For example, when a new lang item is added for some platform or backend, your proposal breaks all creates that override one lang item and don't care about the rest.

Right, but this is why lang items are unstable. This RFC enables this use case because the attribute is a placeholder for all required lang items. If we find ourselves needing to add a new one then it'll just become aborting if the attribute is present.

The only difference is that this RFC does not propose the compiler silently filling in these definitions (but rather requiring an explicit annotation to opt-in).

What's the advantage of an explicit opt-in compared to implicitly filling the definitions with abort implementations unless overridden? Rlibs would never use the attribute, and all bin, staticlib and dylib need some implementation for the lang items anyway.

An explicit opt-in forces you to acknowledge that these items exist and if they're called then they'll just panic. If the compiler implicitly defined them then programs would silently abort whenever they panicked without any indication of why.

I don't expect the lang items ever to be stabilized, since they may differ from platform to platform, from backend to backend, from version to version.
Therefore, IMHO, the explicit opt-in only makes you acknowledge that there exists some unstable set of lang items, for which no stable documentation specifies when they might be called. So all you're acknowledging is that there are situations where the program might silently abort from under you without indication.
And if any crate you depend on uses #![lang_items_abort] your code might still silently abort without any indication.

Actually, #![lang_items_abort] isn't really opt-in: you either won't use it (in an rlib), can't use it (because another crate uses it or implements the lang items), or must use it (or your code will not link). There isn't really a choice here. People will just copy the #![no_std] #![lang_items_abort] sequence to their code without really understanding what lang_items_abort does, as without it their kernel won't link.

Maybe call it #[errors_abort] or something, and specify that it is only responsible for compiler-generated errors? Of course, because of how linking works, at most one crate in an executable can define that attribute.

@Virtlink
I think it's helpful to take a step back and consider what we mean when we're talking about these lang items. Today there are three that are defined by #![lang_items_abort]:

panic_fmt
eh_personality
stack_exhausted

Of these three, eh_personality and stack_exhausted will literally never be called in the context of projects like kernels. They're just here to make everything link correctly. In that sense I think we can discount these entirely. I'd love to not actually require them to exist, but it would require:

Fleshing out the story of no unwinding in Rust. This would alleviate the need for eh_personality in the first place.
Fleshing out the story of stack probes, alleviating the need for stack_exhausted.

In the meantime #![lang_items_abort] is a placeholder meaning that "if these are needed they'll abort and be here for linkage".
The panic_fmt may be reasonably wish to be overwritten. For example a kernel may want to print the message to a serial port or even the screen. This is not being stabilized due to concerns about its signature, but that can always happen later.

I don't expect the lang items ever to be stabilized, since they may differ from platform to platform, from backend to backend, from version to version.

Perhaps not the full set, no, but stabilizing panic_fmt in one form or another seems plausible.

So all you're acknowledging is that there are situations where the program might silently abort from under you without indication.

This seems quite important to me. Let's also remember that we're talking about two useless functions (eh_personality and stack_exhausted) and one function which is already aborting (panic_fmt). The compiler isn't going to inject random silent aborts in your program, this is a very small set of functionality and it's incredibly unlikely to grow larger.

There isn't really a choice here, unless you go into unstable territory and implement the lang items yourself.

I feel like this is actually a pretty important choice here. It's going to take some time for no_std development to basically 100% move onto stable Rust, and I suspect that crates in the meantime may sit in the middle of your stack to enable defining these lang items (specifically panic_fmt).
Again, though, it's important to keep this in perspective and understand that we're not talking about a set of all-important set of functions that all of Rust will eventually call at some point. In that sense I don't want to belabor this point too much as this attribute is primarily just the compiler ensuring that you get a better error message than "your crate didn't link"

@alexcrichton, I had this whole argument typed up, rereading your posts, when I suddenly realized what you're trying to achieve. Please correct me if I'm wrong.
I was under the impression that the user who wrote #![no_std] also consciously chose to not implement panic_fmt, thereby acknowledging any default implementation Rust may have provided. In that case #![lang_items_abort] would be redundant (i.e. not really opt-in).
However, you assume the user might not know about the missing lang items when they write #![no_std]. In that sense, not implementing panic_fmt wasn't a user's choice, but an oversight. The compiler will error to the user that the lang items are missing, and the user has to respond by either explicitly implementing them, or by explicitly not implementing them (through #![lang_items_abort]).

I just recently wrote some FreeBSD kernel code in Rust.  Building for a kernel requires recompiling all imported Rust crates -- including libcore itself -- with custom compiler settings (no redzone, no SSE, no stack checking, etc.).  The automatic import of core and the prelude is a welcome change since it eliminates boilerplate, but I'll still need nightly rustc.  Given that, I'm not sure adding lang_items_abort buys much.

It seems to me that lang_items_abort is almost suitable for a second RFC. Leaving this RFC as opening the way for stable no_std libraries on crates.io.

Could we force rustc to regenerate the machine code in a crate from the bytecode if the codegen options don't match?

@Virtlink

I was under the impression that the user who wrote #![no_std] also consciously chose to not implement panic_fmt, thereby acknowledging any default implementation Rust may have provided. In that case #![lang_items_abort] would be redundant (i.e. not really opt-in).
However, you assume the user might not know about the missing lang items when they write #![no_std]. In that sense, not implementing panic_fmt wasn't a user's choice, but an oversight. The compiler will error to the user that the lang items are missing, and the user has to respond by either explicitly implementing them, or by explicitly not implementing them (through #![lang_items_abort]).

I'm not sure I 100% follow this, but it sounds like it's on the right track. You can write a #![no_std] library which doesn't define these lang items (if that's what you're getting at). Specifically, though, when you write #![no_std] you're not automatically implementing panic_fmt, nor are you required to. Also the only implementation we'll ship is in libstd currently. It's also not necessarily an oversight to not implement panic_fmt because you may want a downstream crate to define it, not yourself. If you try to generate a staticlib, dylib, or executable the compiler will error if these items aren't defined.

@bkoropoff, @thepowersgang

Given that, I'm not sure adding lang_items_abort buys much.

This is discussed in the RFC, but the gist of this is that without this piece it may not be too useful to have no_std because all you can really do is write an rlib. (no executables, staticlibs, etc).

Could we force rustc to regenerate the machine code in a crate from the bytecode if the codegen options don't match?

Possibly? This seems fairly unrelated to this though?

I've been re-reading the RFC and catching up on the thread, and I think perhaps one point of confusion is that the RFC proposes several changes, including some stabilization. @dschatzberg at least has been arguing that the stabilization of no_std etc should happen in conjunction with the stabilization of (some portion of) libcore.
Note that libcore is almost entirely re-exported in libstd, and largely as stable APIs. The stabilization plan there is thus pretty straightforward: correct the few places where there is a mismatch in module hierarchy between core and std, and mark stable those APIs in core that are already stable in std.
I would suggest this RFC be implemented by first making the changes to the semantics of no_std (and introducing no_core), while keeping both unstable. A follow-up PR can be introduced that stabilizes both no_std and a substantial portion of libcore -- which (as with any stabilization PR) would undergo a separate discussion and final comment period. @dschatzberg, would that address your concerns?
Personally, I agree with some others that lang_items_abort doesn't seem to carry its weight. The main reason for its existence seems to be to "force you to acknowledge that these items exist and if they're called then they'll just panic" (should have said "abort"). @alexcrichton, can you expand on why you think it's important to force such an acknowledgement? As others have said, those using no_std likely are, or can easily be made aware, of this issue.
Otherwise, I'm broadly in favor of this proposal, which has been the folklore plan for quite a while.

@aturon
I think that would address my concerns completely. I'm unclear on some of your terminology - what is the distinction between an RFC, an RFC implementation, and a PR? I've read the Life and Death of an API but it hasn't cleared things up. My understanding was that this RFC proposes to stabilize some API - therefore this is the venue to discuss whether or not that is a good idea. Is this correct? Or is a future PR which actually implements the stabilization the correct venue?
My objection is to stabilizing no_std without also stabilizing some portion of libcore simultaneously which you seem to have understood.

@dschatzberg Sorry for the additional confusion.
Basically, I'm proposing to nix the stabilization part of this RFC, and focus on the functional changes only. That's normally how things go with RFCs -- the implementation lands as unstable, and then the feature is stabilized later on, in a "stabilization" PR, which is widely announced and gives the community a chance to raise any final concerns.

@dschatzberg I should also ask: do you have any particular concerns about libcore stabilization?
It seems to me part of the disconnect here is that most others are taking it for granted that libcore will be stabilized, largely as-is (modulo bringing the organization into perfect alignment with libstd), regardless of this RFC. (Note that libcore was introduced in a separate RFC.)
If that sounds reasonable to you as well, then I think the only question is the relative timing of the stabilizations, and I expect everyone would be on board with stabilizing simultaneously.

@aturon

That all makes sense. What is the reason that stabilization will be a future PR and not a future RFC?

I've raised my current issues with nostd programming here: https://github.com/rust-lang/rfcs/pull/1184#issuecomment-123085324. I just can't tell whether stabilizing either #[nostd] or libcore will make it harder to address these issues in the future (if they are to be addressed at all). Either these are issues that we will live with or we can see some path to resolving them in the future where stabilization of #[nostd] and libcore will not be a hindrance.

Answer of 1: because that's an easy and straightforward one, as aturon said
already. We have many precedents in the past too.
On Jul 29, 2015 05:30, "Dan Schatzberg"<EMAIL_ADDRESS>wrote:

@aturon https://github.com/aturon

That all makes sense. What is the reason that stabilization will be a
future PR and not a future RFC?
2.
I've raised my current issues with nostd programming here: #1184
(comment)
https://github.com/rust-lang/rfcs/pull/1184#issuecomment-123085324.
I just can't tell whether stabilizing either #[nostd] or libcore will
make it harder to address these issues in the future (if they are to be
addressed at all). Either these are issues that we will live with or we can
see some path to resolving them in the future where stabilization of
#[nostd] and libcore will not be a hindrance.
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/pull/1184#issuecomment-125759016.

The libs team is in consensus to merge this RFC after the changes that I have just pushed up. This RFC no longer mentions stabilizing any lang items or the #![lang_items_abort] attribute, the only proposed changes are tweaking #![no_std] (without stabilizing it), adding #![no_core], and starting to consider the name "core" stable.
r? @aturon

I don't see any text or discussion about the impact on --test. Right now --test non-hygienically injects std paths. If no_std is stabilized and people try to build with --test this implementation detail will be exposed. I think the codegen for --test needs to be addressed as part of this RFC before no_std can happen.

Hm, I guess this RFC isn't proposing to stabilize even no_std so it's not pressing.

Right now --test non-hygienically injects std paths.

I forgot about that. Unit tests depend on some stuff in libstd, so they need a libstd dependency. Adding the conditional libstd dependency (#[cfg(test)] extern crate std;) to a no_std crate that use a custom target breaks the test build. I believe the issue was that the libstd dependency in turn depends on its own libcore which conflicts with the libcore compiled for the custom target. Back then I made this issue for it.

@brson yeah this isn't stabilizing #![no_std] so it's not super pressing, but that module is largely because of the standard library itself. The test runner injects some ::std:: paths which means that testing a #![no_std] crate will need to have extern crate std at the top.
We can probably patch over this before actually stabilizing #![no_std]. There's a few things I can think of.

As @alexcrichton already mentioned, there was subteam consensus to merge this after scaling it back slightly (as per discussion with @dschatzberg and others).
Tracking issue


Viewer - FB Command is not rendered correctly

The ZPL command FB (Field Block) command is not rendered correctly. I use the currently newest nuget package Zpl.Previewer 1.0.3.
The official doc says that:

The ^FB command allows you to print text into a defined block type format.

The picture below ilustrate how FB affects the printed label.

In the Zpl.Previewer, however, the FB command won't affect the renderend image. It doesn't make difference whether I use the FB command or not.

The viewer is still under development and is not a 100% preview. However, you are welcome to participate in improving it.

Hi, I made a PR solving this issue, I put images in the PR  #113


Add Paack on Geartrack website

Hi! Amazon Spain is now shipping products through Paack (https://paack.co/pt-pt/) too. Could you add it on the website, please?

Hi @diogocnunes, can you send us a tracking id for testing?
Via email (carlosmflorencio at gmail.com) or a Facebook message (Geartrack Page).

Hi, @carlosflorencio
I sent to you by e-mail and Messenger.
Thanks!

Paack now works on Geartrack 🎉.


after tearDownRender, render does not happen

Cause
after tearDownRender, render does not happen, because this and control is different
Fix
reverted ENYO-2744 only HTMLStringDelgate.js
Enyo-DCO-1.1-Signed-off-by: Suhyung Lee<EMAIL_ADDRESS>

Thanks, @suhlee!
I'm going to close this in favor of a different approach. The changes to HTMLStringDelegate were actually required to fix the original issue ENYO-2744, so simply reverting them won't help.
The more specific problem was that the cache argument to teardownChildren() was not being preserved in the new flow between HTMLStringDelegate and Control. One way to fix it would have been to simply make sure we passed the argument properly between the two of them, but I opted instead for a different option -- rather than promote the overriding of teardownChildren(), we'll provide an explicit beforeTeardown() lifecycle hook that Controls can implement as needed.


spring.cloud.gcp.credentials.encoded-key Not working

HI,
Am trying to pass the credentials via the spring.cloud.gcp.credentials.encoded-key property,
and this is command am using to convert the key file to an base64 encoded value as suggested in this blog https://cloud.google.com/kms/base64-encoding
base64 key_file.json -w 0
key_file.json contents:
{
  "type": "service_account",
  "project_id": "xxxxx",
  "private_key_id": "xxxxxxxxxxxxxxxx",
  "private_key": "-----BEGIN PRIVATE KEY-----xxxxxxxxxxx\n-----END PRIVATE KEY-----\n",
  "client_email"<EMAIL_ADDRESS>  "client_id": "xxxx",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/spring-sleuth%xxxxx.iam.gserviceaccount.com"
}

And my Application is crashing always with the below error, any Idea what could be the reason for this issue, and do i need to encode the entire service account JSON file or the JSON with only private_key property ?
[com.google.api.gax.core.CredentialsProvider]: Factory method 'googleCredentials' threw exception; nested exception is java.lang.IllegalArgumentException: Illegal base64 character 7b at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:769) at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:509) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1288) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1127) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:538) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:498) at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:320) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:204) at org.springframework.boot.web.servlet.ServletContextInitializerBeans.getOrderedBeansOfType(ServletContextInitializerBeans.java:235) at org.springframework.boot.web.servlet.ServletContextInitializerBeans.getOrderedBeansOfType(ServletContextInitializerBeans.java:226) at

If I mount the same key as a file through SPRING_CLOUD_GCP_CREDENTIALS_LOCATION it's working fine but when I set the same key through spring.cloud.gcp.credentials.encoded-key so that mounting isn't required and testing locally will also become easy
But it's not working and throwing the above exception posted

@rajivml As I understand, SPRING_CLOUD_GCP_CREDENTIALS_LOCATION is equivalent to spring.cloud.gcp.credentials.location. Have you tried using that instead of spring.cloud.gcp.credentials.encoded-key?

When I am passing the key file through SPRING_CLOUD_GCP_CREDENTIALS_LOCATION  and SPRING_CLOUD_GCP_TRACE_CREDENTIALS_LOCATION, it's working fine, but I need to create a volume and mount that volume to the container for it to work.
And if am testing the app locally I need to make sure that I have the key file on my local system and my SPRING_CLOUD_GCP_CREDENTIALS_LOCATION  environment variable should point to that key file locally
That's why I am keen on using  spring.cloud.gcp.credentials.encoded-key property where I  converting the JSON key file into base64 encoded string but it was throwing the exception which I have mentioned.

You need the full contents of the JSON file to be base-64 encoded.
This is the code that decodes it and creates the credentials:
GoogleCredentials.fromStream(
   new ByteArrayInputStream(Base64.getDecoder().decode(encodedKey)))
        .createScoped(scopes));

See: https://googleapis.github.io/google-auth-library-java/releases/latest/apidocs/com/google/auth/oauth2/GoogleCredentials.html#fromStream-java.io.InputStream-

I have encoded the complete JSON file itself... will check what the below piece is returning and get back
Base64.getDecoder().decode(encodedKey)))
.createScoped(scopes)

@rajivml I just tried using base64 [file] -w 0 and setting the ecoded-key. It worked for me.

Closing, since we're unable to reproduce. Please let us know if you find out what was wrong.

if using multiple profiles, in the same application.yml in particular, make sure the profile that you are running locally has the credentials configured

@meltsufin
Hello, seems like the issue is still there.
The example of my setup doesn't works correctly:
1st of all I've created a key for gcp storage and encoded it using (macOS):
base64 -i key.json -b -
After that I've passed the encoded key into profile:
Encoded key sample:
eAiLS0tLS1CRUdJT.....SQBSFIJ!N KF!LJA=
My application.yaml:
`server:
port: 8081
undertow:
threads:
io: 2
worker: 16
max-http-post-size: -1B
buffer-size: 16KB
direct-buffers: on
shutdown: graceful
servlet:
session:
timeout: 60m
cookie:
http-only: true
application-display-name: api
error:
whitelabel:
enabled: false
spring:
application:
name: api
main:
lazy-initialization: true
web-application-type: servlet
banner-mode: off
jackson:
time-zone: UTC
locale: en_US
datasource:
driverClassName: org.postgresql.Driver
url: ${DB_URL}
username: ${DB_USER}
password: ${DB_PASSWORD}
hikari:
connection-timeout: 1000
pool-name: "hikari-pool"
flyway:
enabled: true
locations: classpath:db/migration
url: ${DB_FLYWAY_URL}
user: ${DB_USER}
password: ${DB_PASSWORD}
connect-retries: 3
schemas: "api"
data:
jpa:
repositories:
bootstrap-mode: deferred
jpa:
open-in-view: false
hibernate:
ddl-auto: none
generate-ddl: false
database-platform: org.hibernate.dialect.PostgreSQL95Dialect
properties:
hibernate:
default_schema: ${DB_SCHEMA}
show-sql: true
mvc:
format:
date: iso
date-time: iso
lifecycle:
timeout-per-shutdown-phase: 30s
autoconfigure:
exclude: org.springframework.boot.autoconfigure.security.servlet.SecurityAutoConfiguration
servlet:
multipart:
enabled: true
max-file-size: -1
max-request-size: -1
resolve-lazily: true
cloud:
gcp:
storage:
enabled: false
management:
health:
livenessstate:
enabled: true
readinessstate:
enabled: true
endpoint:
health:
enabled: true
probes:
enabled: true
show-components: never
show-details: never
group:
readiness:
include: readinessState, db
metrics.enabled: true
prometheus.enabled: true
endpoints.web.exposure.include: "*"
metrics.export.prometheus.enabled: true
logging.level:
ROOT: info
by.vk.api: info
org.springframework: info
springdoc:
show-actuator: true
api-docs:
enabled: true
groups:
enabled: true

spring:
config:
activate:
on-profile: prod
datasource:
url: ${DB_PROD_URL}
username: ${DB_PROD_USER}
password: ${DB_PROD_PASSWORD}
flyway:
enabled: true
url: ${DB_PROD_FLYWAY_URL}
user: ${DB_PROD_USER}
password: ${DB_PROD_PASSWORD}
jpa:
show-sql: false
cloud:
gcp:
storage:
enabled: true
project-id: ${GCP_PROJECT_ID}
auto-create-files: true
credentials:
encoded-key: eAiLS0tLS1CRUdJT.....SQBSFIJ!N KF!LJA=`
If I replace encoded-key with key.json location: key.json it works the same way incorrect.
The exception:
Failed to instantiate [com.google.cloud.storage.Storage]: Factory method 'googleCloudStorage' threw exception; nested exception is java.io.IOException: The Application Default Credentials are not available. They are available if running in Google Compute Engine. Otherwise, the environment variable GOOGLE_APPLICATION_CREDENTIALS must be defined pointing to a file defining the credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
The configuration class that is not able to instantiate credentials:
`@Profile("prod")
@Configuration
public class GoogleCloudStorageConfiguration {
@Bean
@ConditionalOnProperty("spring.cloud.gcp.storage.enabled")
public GoogleCloudStorageProperties googleCloudStorageProperties() {
return new GoogleCloudStorageProperties();
}
@Bean
@ConditionalOnBean(GoogleCloudStorageProperties.class)
public Storage googleCloudStorage(CredentialsProvider credentials, GcpProjectIdProvider project) throws IOException {
return StorageOptions.newBuilder()
.setCredentials(credentials.getCredentials())
.setProjectId(project.getProjectId())
.setRetrySettings(RetrySettings.newBuilder().setMaxAttempts(3).build())
.build()
.getService();
}
}`
The part of service layer I use to read blobs:
  public Resource get(String name) {     var location = forFile(properties.bucket, name);     var blob = new GoogleStorageResource(storage, location, false);     LOGGER.info("[BLOB] Blob with [${}] successfully found.", name);     try(var is = blob.getInputStream()) {       return new InputStreamResource(is);     } catch (IOException exception) {       throw new UnexpectedException(exception.getMessage());     }   }


Implement NSQ Pub/Sub component

Describe the feature

Implement NSQ PubSub (https://nsq.io/overview/design.html)
I'd like to add NSQ as an option for Pub/Sub.
Release Note

RELEASE NOTE:
ADD Pub/Sub component added - NSQ.

/assign

Not stale

Still planned

Still planned

/keep-alive

/keep-alive

/keepalive


NullReferenceException when linking Vimeo Player with AVPro Video

Working on a project in Unity 2017.4.16f1 (macOS Mojave 10.14) with both Vimeo Player and AVPro Video, I have set up the MediaPlayer such that I can play local files or files from Google Drive just fine, but I get a NullReferenceException when I run in-editor with the Vimeo Player added, which prevents the URL from being set on the AVPro MediaPlayer.
The VimeoPlayer component has been set up as per the documentation, with the MediaPlayer linked, logged into a Pro account and with a video selected from the drop-downs in the editor. The error occurs regardless of the resolution setting, with only the line numbers in the error changing.
The full error:
NullReferenceException: Object reference not set to an instance of an object
Vimeo.VimeoVideo.GetVideoFileByResolution (StreamingResolution resolution) (at Assets/Vimeo/Scripts/Config/VimeoVideo.cs:148)
Vimeo.VimeoVideo.GetVideoFileUrlByResolution (StreamingResolution resolution) (at Assets/Vimeo/Scripts/Config/VimeoVideo.cs:136)
Vimeo.Player.VimeoPlayer.VideoControllerPlayVideo () (at Assets/Vimeo/Scripts/Player/VimeoPlayer.cs:221)
Vimeo.Player.VimeoPlayer.Play () (at Assets/Vimeo/Scripts/Player/VimeoPlayer.cs:199)
Vimeo.Player.VimeoPlayer.VideoMetadataLoad (System.String response) (at Assets/Vimeo/Scripts/Player/VimeoPlayer.cs:354)
Vimeo.VimeoApi.ResponseHandler (UnityEngine.Networking.UnityWebRequest request) (at Assets/Vimeo/Scripts/Services/VimeoApi.cs:219)
Vimeo.VimeoApi+c__Iterator3.MoveNext () (at Assets/Vimeo/Scripts/Services/VimeoApi.cs:238)
UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) (at /Users/builduser/buildslave/unity/build/Runtime/Export/Coroutines.cs:17)
Steps to Reproduce:
1- Set up new Unity Project and scene.
2- Import AVPro Video and set up a MediaPlayer, either custom-built or using one of the provided prefabs.
3- Add a Vimeo Player to the scene, get token, set to use AVPro Video player.
4- Assign the MediaPlayer to the AVPro Media Player field on the Vimeo Player.
5- Assign a video using either the Vimeo URL or using the drop-downs to select an uploaded video.
6-Set the Resolution option to any of the options available.
7-Click Play to run the scene in-editor.
Two errors will appear in the console: One from AVPro stating that no file path has been provided and the other as detailed above.

Further to the above, I have tested the issue using Unity 2017.4.15f1 on Windows x64 and on Unity 2017.4.10f1 on macOS Mojave, using different forms of the player (including editing all the demo scenes that come with AVPro Video to use a Vimeo Player), but the same bug occurs in all instances.

Hi @MZNX-AlCampbell  thanks for the details!
I am having a hard time replicating this issue. I am using the same Unity version on Windows 10 (x64) and it seems to be working on my end. Did you add an Apply To Material component to the screen GameObject?
To get rid of the first file path error that AVPro throws try checking off the Auto Play and Auto Open options

And your Screen GameObject should look something like

@MZNX-AlCampbell I am closing this issue since I couldn't replicate your problem. If the above doesn't solve the issue feel free to re-open / open a new issue


Filter demos page is crashed

Get this error =>
compileProgram.js:19 Uncaught TypeError: Failed to execute 'attachShader' on 'WebGLRenderingContext': parameter 2 is not of type 'WebGLShader'.
Was working fine last week.

This error happens when a shader fails to compile. You should see log output of the compile errors above this error.
I think the new lodBias parameter that got introduced may be causing this error but I haven't had time to build locally yet.

Caused by #5120

Fixed

I didn't look into why this happens yet but maybe #3929 is a better alternative to what I was trying to accomplish with my PR.


Add mail queue

Add mail queue to avoid user error and to resend mail on failure

check if delay between mail sending would be appropriate

I measured how long the mail sending takes

Results: (1 mail ~200ms ~0.2s | 5 mails per second)
25.11.2023 23:55:01
Working mail queue ...
Successfully sent mail 557 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>2864 milliseconds.

25.11.2023 23:56:01
Working mail queue ...
Successfully sent mail 558 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>5769 milliseconds.
Successfully sent mail 559 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>7468 milliseconds.
Successfully sent mail 560 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>8792 milliseconds.
Successfully sent mail 561 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>1323 milliseconds.
Successfully sent mail 562 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>1301 milliseconds.
Successfully sent mail 563 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>8811 milliseconds.
Successfully sent mail 564 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>9792 milliseconds.
Successfully sent mail 565 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>9463 milliseconds.
Successfully sent mail 566 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>5188 milliseconds.
Successfully sent mail 567 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>5042 milliseconds.
Successfully sent mail 568 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>2183 milliseconds.
Successfully sent mail 569 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>9558 milliseconds.
Successfully sent mail 570 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>259 milliseconds.
Successfully sent mail 571 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>0747 milliseconds.
Successfully sent mail 572 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>626 milliseconds.
Successfully sent mail 573 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>4026 milliseconds.
Successfully sent mail 574 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>4084 milliseconds.

This means in the above case for example (new user accepted, sending 20 mails to all global admins), the system would be burdened for 2 seconds.
The Apache will still be able to handle user requests in that time, since it handles multiple requests in parallel. How big will the load be, is it noticeable? Idk...
But having the mail-sending thread sleep for a bit, could definitely distribute the load, so it becomes even less noticeable.
We'd just have to care that (1) the mails may never pile up and (2) we don't delay too much, because people rather don't want to wait more than a minute for their mail to come.
-> So just a little delay. Maybe just 100 milliseconds?
This way there could still be 100 mails sent in 30 seconds (200/s).
We should definitely keep mailling power up, since mails stack up fast when operations happen that notify all global admins.
I'm in for 100ms or at most 200ms delay.
And when we want to optimize on that, we get a separate mail server and use its asynchronous API. That's would be the best solution anyway.

Awesome research! I'd also say that that 100ms would be appropriate.

Before implementing this, I want to see how much changes when reusing the $mailer object:

Results (1 mail ~160ms ~0.16s | 6.25 mails per second)Performance gains: 25% | 1 mail ~40ms less | 1.25 more mails per second | 75 more mails per minute
26.11.2023 13:04:01
Working mail queue ...
Successfully sent mail 612 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>5972.

26.11.2023 13:08:02
Working mail queue ...
Successfully sent mail 613 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>4636.

26.11.2023 13:09:01
Working mail queue ...
Successfully sent mail 614 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>8303.
Successfully sent mail 615 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>9089.
Successfully sent mail 616 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>5415.
Successfully sent mail 617 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>9819.
Successfully sent mail 618 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>7659.
Successfully sent mail 619 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>688.
Successfully sent mail 620 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>8708.
Successfully sent mail 621 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>0896.
Successfully sent mail 622 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>5957.
Successfully sent mail 623 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>7822.
Successfully sent mail 624 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>0903.
Successfully sent mail 625 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>0483.
Successfully sent mail 626 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>2024.
Successfully sent mail 627 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>012.
Successfully sent mail 628 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>3423.
Successfully sent mail 629 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>3899.
Successfully sent mail 630 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>7673.
Successfully sent mail 631 to<EMAIL_ADDRESS>Mail sending took<PHONE_NUMBER>6409.

Based on above discussion and measurements, I will implement:

a 100ms sleep with usleep() after sending a mail. This should use the OS' sleep making the thread take almost no CPU time and letting other threads have it.
the re-usage of the $mailer object.


document missing

I get GitHub 404 for this link
https://github.com/clara-genomics/ClaraGenomicsAnalysis/blob/master/docs/annotated.html
from this page
https://github.com/clara-genomics/ClaraGenomicsAnalysis/blob/master/docs/README-SDK.md
I guess the generated HTML is not checked in?

@cschin Indeed, they're not checked in. This README slipped through unfortunately. The best way to get docs would be to generate them as described in https://github.com/clara-genomics/ClaraGenomicsAnalysis/blob/master/README.md#enable-doc-generation
We'll take a look at checking the documentation in as well so it's ready for use

Pushed #34 to make the setup less confusing. No more README in the docs folder. API documentation still not checked in though, but will add it to our feature list

Closing as docs have been available in https://clara-parabricks.github.io/GenomeWorks/


[Enhancement] Add a command for packing (cpack)

This should take in the nuspec file if specified.


What does "wb_" mean?

What is the means of "wb_" in the begining in dataset name?

wb = waist band =)

Thank you!


[FLOC-1477] [FLOC-1478] Deployer deletion

https://clusterhq.atlassian.net/browse/FLOC-1477
https://clusterhq.atlassian.net/browse/FLOC-1478
This should finish off https://clusterhq.atlassian.net/browse/FLOC-1467

I will have fix for failing acceptance test shortly.

Thanks.  Looks good overall.  Please address minor inline comments to your satisfaction, verify buildbot is green, and then merge.


[WIP] Fractal store implementation

First cut at some tools to make fractal-stores easier.
The idea is that a component can call
constructor(ngRedux: NgRedux<IAppState>) {
  this.store = ngRedux.createSubStore<IComponentState>(['path', 'too', 'some', 'location'], localReducer);
}

And then use this.store as if it were an isolated redux store rooted at ['path', 'too', 'some', 'location'].
The local reducer passed in to createSubStore will only know about the sub-state at that path.  Any actions dispatched by this.store.dispatch() will only be passed to localReducer.  This way, you can have multiple isolated instances of the same component working on their own slices of the store and having their own isolated actions:
ngOnInit() {
  this.store = ngRedux.createSubStore<IComponentState>(['my', 'component', this.instanceId], localReducer);
}

Also note that a side effect of this is the ability to register localReducers dynamically, which could be handy for code splitting.
Right now this only works for subStore.select and subStore.dispatch, not for @select or @dispatch. I'll think about a decorator interface for this in a second pass, if you think it's worthwhile.

[ ] adjust NgRedux.configureStore and NgRedux.provideStore to enable the rootFractalReducer logic.
[ ] think about what a decorator interface for this would look like
[ ] docs
[ ] tests

@e-schultz @smithad15 @danielfigueiredo @rpdasilva comments appreciated

Test it out at<EMAIL_ADDRESS>


Transactions and optimistic concurrency control

Hi I am working on a project that is using your library, the project requires that we handle some form of Transactions or optimistic concurrency control on the data. Essentially I need to read the data and change contents within the document and write it back.
What I want to avoid is when writing back to have a newer version in the database and my data ends up overwriting the current document.
Microsoft has already something that handles such situations (https://docs.microsoft.com/en-us/azure/cosmos-db/database-transactions-optimistic-concurrency#optimistic-concurrency-control) is this implemented within your library?

I have seen this demo https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos.Samples/Usage/ItemManagement/Program.cs#L676-L772 linked at the bottom of that document, it certainly sounds like something we should be looking into. It would be interesting to better understand how the native client supports this and what our API should look like to neatly wrap up this feature.

@andrcami going to look at implementing this would you expect to see if just for upserts?

I concur with andrcami, it is a much needed feature....I am currently stuck in my project due to overwrite issues.

I concur with andrcami, it is a much needed feature....I am currently stuck in my project due to overwrite issues.

Hi @lappy4711 - to be clear, I want to make sure that you're using this SDK - is that correct? Or are you using the official Cosmos DB SDK?

I concur with andrcami, it is a much needed feature....I am currently stuck in my project due to overwrite issues.

Hi @lappy4711 - to be clear, I want to make sure that you're using this SDK - is that correct? Or are you using the official Cosmos DB SDK?

Yes, I am using the SDK....really like the simplicity.

I am going to look at it next week currently away 🇵🇹. My only concern is having to store the 'etag' on the 'Item' may result in a breaking change 🤔

I am going to look at it next week currently away 🇵🇹. My only concern is having to store the 'etag' on the 'Item' may result in a breaking change 🤔

Why would you have to to that? You already have the _etag.

I am going to look at it next week currently away 🇵🇹. My only concern is having to store the 'etag' on the 'Item' may result in a breaking change 🤔

Why would you have to do that? You already have the _etag. Can't you just use that for whatever cool strategy you come up with? Personally, I would just need an exception that indicates that I'm attempting to overwrite data that is newer than the one I currently have. I could then fetch the data and try again. Or similar.

Yes we would probably keep with the same exception that the SDK that cosmos throws can't remember the status code off the top of my head.
What I meant by the etag was we would need a field on our base class 'Item' and also on our interface 'IItem' which could result in a breaking change. We would need this as we would have to use the etag when we are upsetting a document.

Hi @andrcami we are on with this, see #147 😄

Hi @andrcami @lappy4711 closing this issue now, the PR has been merged and we are waiting on #79 & #92 before we cut a release @robertbennett1998 is working on this and should be done soon 😃


beets: fix broken aarch64 build due to missing plugin test

The absubmit plugin for beets has no respective plugin test that is named after the default plugin test schema defined in common.nix ^1, so not explicitly declaring that the plugin has no tests (i.e. the respective test list is empty), mkPlugin will try to disable the non-existant test test/test_absubmit.py), breaking beet's build.
Description of changes
Explicitly flag absubmit plugin as having no tests.

Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.
Result of nixpkgs-review run on aarch64-linux 1

18 packages built:

beets
beets-unstable
beets-unstable.dist
beets-unstable.doc
beets-unstable.man
beets.dist
beets.doc
beets.man
beetsPackages.alternatives
beetsPackages.alternatives.dist
beetsPackages.beets-minimal
beetsPackages.beets-minimal.dist
beetsPackages.beets-minimal.doc
beetsPackages.beets-minimal.man
beetsPackages.copyartifacts
beetsPackages.copyartifacts.dist
beetsPackages.extrafiles
beetsPackages.extrafiles.dist

Example of a failing Hydra build: https://hydra.nixos.org/build/244648745
Hydra log: https://hydra.nixos.org/build/244648745/nixlog/1
Relevant log excerpt:
build succeeded.

The manual pages are in .sphinx/man/man.
Running phase: installSphinxPhase
Executing installSphinxPhase
Running phase: pytestCheckPhase
Executing pytestCheckPhase
Disabled tests path "test/test_absubmit.py" does not exist. Aborting

What I was unable to determine from reading the Nix expressions for beets so far is why without this change, only aarch64 builds seem to fail (my x86_64 box doesn't complain if I run nix-build -A pkgs.beets from current master). If anyone knows the reason for this, I'd be glad to learn why :)

@aszlig @doronbehar  @lovesegfault  @pjones
I just realized that ofborg didn't assign this PR to anyone (I assume that's because there are multiple instances of this package?), so I thought I'd better tag you directly.

What I was unable to determine from reading the Nix expressions for beets so far is why without this change, only aarch64 builds seem to fail (my x86_64 box doesn't complain if I run nix-build -A pkgs.beets from current master). If anyone knows the reason for this, I'd be glad to learn why :)

Hmm, I think that the line:
https://github.com/NixOS/nixpkgs/blob/526a39a14012ec0ea3e3addd77e9d3364a084d5f/pkgs/tools/audio/beets/builtin-plugins.nix#L15
Together with:
https://github.com/NixOS/nixpkgs/blob/526a39a14012ec0ea3e3addd77e9d3364a084d5f/pkgs/tools/audio/essentia-extractor/default.nix#L37
Makes beets' aarch64-linux build disable the absubmit plugin, and hence try to disable the tests for it, via the following line:
https://github.com/NixOS/nixpkgs/blob/526a39a14012ec0ea3e3addd77e9d3364a084d5f/pkgs/tools/audio/beets/common.nix#L105
However, I'm a bit surprised that the architecture i686-linux isn't equal to aarch64-linux...
I too experienced issues with the testPaths when I enable and disable plugins in my personal overlay. I tried to raise a discussion about this in https://github.com/NixOS/nixpkgs/pull/268598#issuecomment-1837532382 - the PR where beets' plugins' Nix API, added support for disabling tests automatically for plugins that are disabled via the like that.
Another issue, is that beets-unstable had it's default testPaths changed. Meaning that now this line:
https://github.com/NixOS/nixpkgs/blob/526a39a14012ec0ea3e3addd77e9d3364a084d5f/pkgs/tools/audio/beets/common.nix#L39
Should use test/plugins/test_${name}.py for beets-unstable.

Sorry for this taking so long...
Regarding my proposal for changing pluginOverrides API, I reached the conclusion after reading more thoroughly the beets' expression, that the current design is not so bad, but the unstable flavor needs maintenance that may be conditioned on the version. Some fixes for the unstable version are available in https://github.com/NixOS/nixpkgs/pull/282042 .