Installation fails at calling libtool when install dir contains space

Building this on Cygwin using ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-cygwin].
Note the user directory contains a space: "Space Space"
Below is the full output, but the issue is that quotes are no longer around the path when libtool is called:
 /bin/sh ./libtool   --mode=install /usr/bin/install -c   libxml2.la '/home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/ports/x86_64-unknown-cygwin/libxml2/2.9.2/lib'
libtool: install: /usr/bin/install -c .libs/libxml2.lai /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/ports/x86_64-unknown-cygwin/libxml2/2.9.2/lib/libxml2.la

Full output:
Installing nokogiri 1.6.7 with native extensions

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    /usr/bin/ruby.exe -r ./siteconf20160108-3592-twtqs6.rb extconf.rb
checking if the C compiler accepts ... yes
Building nokogiri using packaged libraries.
Using mini_portile version 2.0.0
checking for gzdopen() in -lz... yes
checking for iconv... yes
************************************************************************
IMPORTANT NOTICE:

Building Nokogiri with a packaged version of libxml2-2.9.2
with the following patches applied:
        - 0001-Revert-Missing-initialization-for-the-catalog-module.patch
        - 0002-Fix-missing-entities-after-CVE-2014-3660-fix.patch
        - 0003-Stop-parsing-on-entities-boundaries-errors.patch
        - 0004-Cleanup-conditional-section-error-handling.patch
        - 0005-CVE-2015-1819-Enforce-the-reader-to-run-in-constant-.patch
        - 0006-Another-variation-of-overflow-in-Conditional-section.patch
        - 0007-Fix-an-error-in-previous-Conditional-section-patch.patch
        - 0008-CVE-2015-8035-Fix-XZ-compression-support-loop.patch
        - 0009-Updated-config.guess.patch
        - 0010-Fix-parsering-short-unclosed-comment-uninitialized-access.patch

Team Nokogiri will keep on doing their best to provide security
updates in a timely manner, but if this is a concern for you and want
to use the system library instead; abort this installation process and
reinstall nokogiri as follows:

    gem install nokogiri -- --use-system-libraries
        [--with-xml2-config=/path/to/xml2-config]
        [--with-xslt-config=/path/to/xslt-config]

If you are using Bundler, tell it to use the option:

    bundle config build.nokogiri --use-system-libraries
    bundle install

Note, however, that nokogiri is not fully compatible with arbitrary
versions of libxml2 provided by OS/package vendors.
************************************************************************
Extracting libxml2-2.9.2.tar.gz into tmp/x86_64-unknown-cygwin/ports/libxml2/2.9.2... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0001-Revert-Missing-initialization-for-the-catalog-module.patch... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0002-Fix-missing-entities-after-CVE-2014-3660-fix.patch... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0003-Stop-parsing-on-entities-boundaries-errors.patch... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0004-Cleanup-conditional-section-error-handling.patch... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0005-CVE-2015-1819-Enforce-the-reader-to-run-in-constant-.patch... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0006-Another-variation-of-overflow-in-Conditional-section.patch... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0007-Fix-an-error-in-previous-Conditional-section-patch.patch... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0008-CVE-2015-8035-Fix-XZ-compression-support-loop.patch... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0009-Updated-config.guess.patch... OK
Running git apply with /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/patches/libxml2/0010-Fix-parsering-short-unclosed-comment-uninitialized-access.patch... OK
Running 'configure' for libxml2 2.9.2... OK
Running 'compile' for libxml2 2.9.2... OK
Running 'install' for libxml2 2.9.2... ERROR, review '/home/Space Space/.gem/ruby/gems/nokogiri-1.6.7/ext/nokogiri/tmp/x86_64-unknown-cygwin/ports/libxml2/2.9.2/install.log' to see what happened.   Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/usr/bin/$(RUBY_BASE_NAME)
        --help
        --clean
        --use-system-libraries
        --enable-static
        --disable-static
        --with-zlib-dir
        --without-zlib-dir
        --with-zlib-include
        --without-zlib-include=${zlib-dir}/include
        --with-zlib-lib
        --without-zlib-lib=${zlib-dir}/lib
        --enable-cross-build
        --disable-cross-build
/home/Space Space/.gem/ruby/gems/mini_portile2-2.0.0/lib/mini_portile2/mini_portile.rb:366:in `block in execute': Failed to complete install task (RuntimeError)
        from /home/Space Space/.gem/ruby/gems/mini_portile2-2.0.0/lib/mini_portile2/mini_portile.rb:337:in `chdir'
        from /home/Space Space/.gem/ruby/gems/mini_portile2-2.0.0/lib/mini_portile2/mini_portile.rb:337:in `execute'
        from /home/Space Space/.gem/ruby/gems/mini_portile2-2.0.0/lib/mini_portile2/mini_portile.rb:116:in `install'
        from /home/Space Space/.gem/ruby/gems/mini_portile2-2.0.0/lib/mini_portile2/mini_portile.rb:151:in `cook'
        from extconf.rb:289:in `block (2 levels) in process_recipe'
        from extconf.rb:182:in `block in chdir_for_build'
        from extconf.rb:181:in `chdir'
        from extconf.rb:181:in `chdir_for_build'
        from extconf.rb:288:in `block in process_recipe'
        from extconf.rb:187:in `tap'
        from extconf.rb:187:in `process_recipe'
        from extconf.rb:478:in `<main>'

extconf failed, exit code 1

Gem files will remain installed in /home/Space Space/.gem/ruby/gems/nokogiri-1.6.7 for inspection.
Results logged to /home/Space Space/.gem/ruby/extensions/x86_64-cygwin/nokogiri-1.6.7/gem_make.out

Worked around it by temporarily renaming the directory with spaces and overriding some environment variables to point to the new location instead.

Hi!
I believe that the Makefile that libxml2 generates does contain a properly-quoted directory in the command. Can you double-check what it looks like on your system?
I imagine that this might be an issue with the version of libtool you have on your machine? It doesn't look like an issue that Nokogiri or even mini_portile can address.

Sorry, I don't have the project anymore, so I cannot test this without recreating everything. Since I posted the workaround and you rightly so indicated this is not a Nokogiri issue, I am closing this  issue.


Replaces UBI with Stream9-minimal image

UBI is not a redistributable image, and should only be used on RHEL machines. Therefore, we should use the CentOS Stream image.
However, the centos quay repo does not tag their images with anything more granular than stream9-minimal. This image does look to be updated regularly, though, which may or may not be an issue.
I've built and used this image locally for a few days now without issue on my M1 MBP.
I've opened this PR for further discussion, and do not have an opinion one way or the other on whether this gets merged or not.
Migrating to stream9-minmal puts us under the "letter of the rule", however since this is an internal tool really used only by RH SREs on CSBs - we are still following the "spirit of the rule".

:fry-not-sure: - I was told by other engineers on slack that UBI was non-redistributable (and then eventually made this PR), but when I decided to go find a source for that claim somewhere after submitting this PR and googled for it I found the UBI landing page which explicitly calls out UBI as freely-redistributable...
We can still have the discussion on whether or not to use UBI/stream-9; however I'm perfectly fine with closing this with this new information.... 🤦🏼

More Information:
From another slack thread - the general consensus is that if the container running UBI as a base is built on a RHEL system it's only allowed to run on that RHEL system. If we built via UBI locally this is fine, as UBI won't have access to any of the RHEL repos, but if being built on a RHEL system it will have the RHEL repos enabled by default, and therefore may not be freely redistributable.
It might just be safer at this point to run Stream9 - though I'm still open to have a discussion.


Julia v1.0 support: Add option to specify julia version in REQUIRE

This PR adds the option to specify a julia version in the REQUIRE file, and updates the JuliaBuildPack to support julia v0.7 and v1.0.
It also bumps the default julia version from v0.6.0 to v0.6.4 (the latest release for v0.6).
Adds tests for specifying a custom version, both for a julia 0.6.3 and julia 1.

Fixes #392.

@KristofferC could you maybe take a look at this to verify that i've handled the REQUIRE file acceptably in julia 0.7/1.0? I think it works, but it seems like there might've been a more elegant way for me to do this?
Thanks so much!! :)

Would be a lot simpler if you have a Project + Manifest, which in case the whole thing would just be a Pkg.instantiate() to download all the packages at the versions specified in the Manifest.
Otherwise doing something like a Pkg.add("path/to/repo") on the path of the package itself should install all the required dependencies even if it has a REQUIRE file.

Would be a lot simpler if you have a Project + Manifest
I was under the impression that we're really not supposed to be using these yet, until the Great Migration moves everything from REQUIRE to Project+Manifest. Am I getting that wrong? Is it that you're supposed to use Project+Manifest in your local projects (or notebook repo in this case), but still use REQUIRE files in packages that you submit to METADATA?

Thanks, and sorry for my confusion!
In that case, how do you recommend proceeding for this code? Should we simply say we don't support REQUIRE files in your notebook repo if you're using julia v0.7+?

Otherwise doing something like a Pkg.add("path/to/repo") on the path of the package itself should install all the required dependencies even if it has a REQUIRE file.

Sorry, I don't think I understand what you mean. If it helps explain better, the repo being built in this case usually isn't a Package. Rather, it's a Project that contains .ipynb files, and the REQUIRE file is used to specify dependencies needed to run those notebooks. Here's an example repo:
https://github.com/binder-examples/julia-python
So I don't think Pkg.add is what we want, since there's no package there at all. Something like Pkg.resolve("path/to/repo") would be excellent though! :)

Nice work and thanks for helping us get better Julia support.
For Python and R we use runtime.txt to let users choose versions. So from a uniformity point of view it would be good to use that for Julia as well. However from one of your comments it sounds like the Julia community uses the REQUIRE file for this? What do you think is the best option?

I was under the impression that we're really not supposed to be using these yet, until the Great Migration moves everything from REQUIRE to Project+Manifest. Am I getting that wrong? Is it that you're supposed to use Project+Manifest in your local projects (or notebook repo in this case), but still use REQUIRE files in packages that you submit to METADATA?

You can use Project + Manifest now, it is just that the way things are registered in METADATA right now is using REQUIRE files. For notebooks, I am not sure what the point of a REQUIRE file would be on 1.0. There's no Pkg.resolve(".../REQUIRE") in Pkg3.

If it helps explain better, the repo being built in this case usually isn't a Package.

Yeah, I haven't really checked what this repo is doing heh.

Slightly related: JuliaLang/IJulia.jl#673.

Oh cool, thanks, yes i think that's a related conversation. Thanks for the pointer!

Yeah, I haven't really checked what this repo is doing heh.

hehe. :) Np. This repo is used by MyBinder (and probably other parts of the jupyter universe?) to instantiate a docker container for a given directory (repo) that contains .ipynb files. They currently allow you to specify dependencies that should be loaded while building the docker image -- so that you don't need to re-install them every time you run a notebook. This is done via a top-level REQUIRE for julia, an environment.yml for python, etc.
After reading the conversation you linked, I think this process is used to solve some of the issues discussed in that thread!

You can use Project + Manifest now, it is just that the way things are registered in METADATA right now is using REQUIRE files. For notebooks, I am not sure what the point of a REQUIRE file would be on 1.0. There's no Pkg.resolve(".../REQUIRE") in Pkg3.

Gotcha. Okay! It seems like a reasonable answer here is just to say: Sorry, if you're using v0.7+ you can't use REQUIRE files and instead have to use Project+Manifest! that seems reasonable to me. Thanks! :)

But also, the other thing I was hoping to change in this PR is allowing you to specify the julia version in the REQUIRE file. Currently, the way this tool works is it only allows you to pull down julia 0.6.0, and so I think allowing the user to specify which version of julia to install would be preferable.
So I think maybe the logic for this PR should instead be:

If there's a REQUIRE, assume the julia version to be 0.6.4. If it contains a julia version string, read the version out of it. If the listed version is >0.7, error out or something?

Then, copy the REQUIRE to ~/.julia/version/and do Pkg.resolve()

If there's a Project.toml, assume the julia version to be 1.0.0. If it contains a [compat] section with a julia version string, read the version out of it. If < 0.7, error out or something.

Then, copy  Project.toml and possible Manifest.toml to ~/.julia/environments/version/ and do Pkg.instantiate().

Does that sound reasonable? Thanks for your help!

Although (sorry for the post-spam), I do think it would be reasonable to also support REQUIRE files for 0.7, at least for now, since they're still a part of the julia package ecosystem (for METADATA). So it seems reasonable to me to support both for now?

The "correct" thing would be to record the julia version in the Manifest but we don't currently do that. So next best thing:
Note that julia = "1.0" defines a range of intervals in Pkg3 ([1.0 - 2.0)). So I think the way to do it is if there is no [compat] for julia use the latest, otherwise use the latest version such that it is within the range (which can be tested as):
julia> v"1.0" in Pkg.Types.semver_spec("1.0")
true

julia> v"1.3" in Pkg.Types.semver_spec("1.0")
true

julia> v"2.0" in Pkg.Types.semver_spec("1.0")
false

So if the julia versions [1.0, 1.2, 1.3, 2.0] existed and julia = 1.0 was in [compat] then use 1.3.
With this, the julia version used will change as new versions get released (but that is not any different from what Pkg.resolve did on 0.6 when new package version was released though).

Oh, cool, yeah that makes sense. That should be an easy change. So how does this behavior sound:

If there's a Project.toml:

If it contains a [compat] section with a julia version string, read the version out of it. If < 0.7, error out or print or warning or something.

Install the latest version of julia that satisfies the provided semver specification. (e.g if julia versions [1.0, 1.2, 1.3, 2.0] existed, and julia = 1.0 in [compat], install 1.3.)

Otherwise, just install the latest version of julia.
Then, copy the Project.toml and possible Manifest.toml to ~/.julia/environments/version/, open julia, and run Pkg.instantiate().

If there's a REQUIRE file (and no Project.toml):

If it contains a julia version string, install the latest version that matches the prefix. (e.g. julia 0.6 installs v0.6.4, julia 0.7 installs v0.7.0 and julia 0.6.3 installs v0.6.3.)
Otherwise, install the latest 0.6 (v0.6.4).
Then, if version < 0.7, copy the REQUIRE to ~/.julia/version/ and do Pkg.resolve()
Else (version >0.7), call Pkg.add() on each line of the REQUIRE, using the code I've currently implemented in this PR, here.

I think this sounds like a good approach that is the most permissive of user behavior. But it's seems reasonable to say it's too permissive, and that we should disallow using REQUIRE if you're going to use julia 0.7. I'm open to your suggestions there! :)
Thanks again for your help!

Then, copy the Project.toml and possible Manifest.toml to ~/.julia/environments/version/, open julia, and run Pkg.instantiate().

There is no need to copy. You can set the JULIA_PROJECT env variable to the project path, start julia with julia --project=/path/to/project or after starting julia runPkg.activate("path/to/project") and then that will be the active project. If the Project is in the pwd() then julia --project is enough (implies pwd).

There is no need to copy. You can set the JULIA_PROJECT env variable to the project path, start julia with julia --project=/path/to/project or after starting julia runPkg.activate("path/to/project") and then that will be the active project. If the Project is in the pwd() then julia --project is enough (implies pwd).

Hmm, yeah I know about that, but I am wondering if that will work correctly with the jupyter notebook kernels... Maybe it will? Basically, the goal is that whenever the user opens a .ipynb and starts the Julia kernel, that it gets an environment with all the right packages installed.
If I start julia with the JULIA_PROJECT env variable set when I first install IJulia, will it set things up so that the kernel it installs will always point to the right environment? Am I understanding that correctly?

I don't know what configuration options you have over the kernel file from here but if you can do zero configuration then you would indeed have to put the Project + Manifest in the default place (environments/...).

Okay cool, that makes sense. thanks.
Alright, well, let's leave aside this issue, since it's relatively minor. Would you mind giving me your thoughts on the overall pseudocode behavior above? I appreciate your help!! :) :)

I would just not bother with 0.6 but if you really want to then that pseudo code seems ok. REQUIRE files however have no implicit upper bounds like the Pkg3 compat has, so julia 0.6 means julia [0.6, 99999999...)  so it is a bit tricky to know what Julia version to install. But as a heuristic, the latest 0.6 version is probably the right thing to do.

@betatim we should probably use whatever is canonical in the language for specifying version, falling back to runtime.txt only when there is no canonical way. environment.yml for example has a canonical way.
@NHDaly @KristofferC <3 for working on this! Have you run repo2docker locally to verify that IJulia works as intended?

@betatim we should probably use whatever is canonical in the language for specifying version, falling back to runtime.txt only when there is no canonical way. environment.yml for example has a canonical way.

Oh yeah, I forgot about runtime.txt... So that should be added as a fallback mechanism? Right now, without this PR, is that already a thing? Could I have just specified the Julia version via runtime.txt?

@NHDaly @KristofferC <3 for working on this! Have you run repo2docker locally to verify that IJulia works as intended?

haha <3 thanks!! :) I'll be happy to get it updated!
Yes, I have run it locally to verify that the tests (including those I added) all pass, and I launched a jupyter notebook in one of the images it created, and it worked correctly with different julia versions!
(That said, the contributing guide doesn't explicitly say how to actually launch a notebook after creating the docker image, it only covers tests. I just did a docker container ls to find one of the ones created by the tests, and then launched that one.)

I'm going to put in some work in the next couple days to update the logic to what Kristoffer and I discussed above. Do I also need to add in logic to handle falling back to runtime.txt, or does that behavior come automatically for free? Thanks!

@KristofferC: One more question, should we require people use JuliaProject.toml here, since the whole point of this file is to tell repo2docker "Hey this repo needs Julia installed! Plz install this version and these deps."? Or should we support either Project.toml or JuliaProject.toml?
What other languages use Project.toml, and is there an easy way to read the file and tell if it's intended for julia or some other language?

@NHDaly awesome. I would recommend against adding any runtime.txt logic right now. Let us know when this is ready for review again!

Pkg and code loading in Julia Base support both names. FWIW, I personally argued that only using JuliaProject.toml was the way to go but oh well. For now, I think it is easiest to use JuliaProject.toml if it exists and otherwise use Project.toml

Haha yeah, i mean, I can see why you argued for that. :/ oh well indeed.
Okay great, thanks for the guidance, that makes sense to me as well. :)

All tests pass, some small nits, merge after those?
What is the new default Julia version going to be when the user does not specify anything? Should we bump it to 1.0 or leave it at the (now quite old) 0.6 that has been the default?

All tests pass, some small nits, merge after those?

Ah, actually, this still needs some pretty major changes: adding support for the Project.toml files per this comment:
https://github.com/jupyter/repo2docker/pull/393#issuecomment-419558127
I started working on it again yesterday, but it's actually been a bit tough. The hardest part was trying to handle the "semver" logic in python that the .toml files use for specifying a julia version. (Needs to be done in python, since it's deciding which version of julia to install!)
But actually, I think maybe you're right that we could just merge this PR as-is, and I could fork the changes I've been working on into a second PR. That might actually make more sense, just to allow getting something working sooner rather than later! What do you think? Should I split that into a separate PR?

What is the new default Julia version going to be when the user does not specify anything? Should we bump it to 1.0 or leave it at the (now quite old) 0.6 that has been the default?

I had kept it at 0.6 so as not to break anyone currently using the system. I think it is perfectly reasonable (and probably preferable) to bump it, but I assume we'd want to publish that somewhere first? Like, HEY default julia versions are going to bump in a week, please use a REQUIRE file to keep yourself at 0.6 if that's what you really want?
As for which version, no I think we should go to 0.7, since a lot of packages still aren't yet 1.0 compatible. I think we could probably bump to 1.0 in a month or two.

As for which version, no I think we should go to 0.7, since a lot of packages still aren't yet 1.0 compatible. I think we could probably bump to 1.0 in a month or two.

Ok, maybe we stick with the current default and use our "one chance" to annoy people by bumping straight to 1.0.

What do you think? Should I split that into a separate PR?

So now we can choose the version via the first line in REQUIRE and the second PR would add support for {Julia}Project.toml? If the answer is yes I'd vote to merge now and make a second PR. (Smaller PRs are the better PRs 😄)

Smaller PRs are the better PRs 😄

Haha yes agreed, 100%. :)

So now we can choose the version via the first line in REQUIRE and the second PR would add support for {Julia}Project.toml? If the answer is yes I'd vote to merge now and make a second PR.

Yes the answer is yes! :)
Okay, then, before you merge, allow me the chance to address these remaining nits. I'll have something pushed up in a few hours! :)

Ok, maybe we stick with the current default and use our "one chance" to annoy people by bumping straight to 1.0.

Haha okay yeah I think that could make sense.. The one interesting and weird thing to note about this version change is that 0.7 is closer to 1.0 than to 0.6. 0.7 is basically "1.0 with deprecations", or a backwards-compatible 1.0.
So given that, I think I agree that the 1.0 bump definitely should be announced, but actually that we could probably silently bump the default to 0.7 and people would on the whole be glad, not sad. There are fewer and fewer existing use cases where people would prefer 0.6 over 0.7.
So maybe we submit this, send a silent PR to bump to 0.7, and then eventually do an announced PR to bump to 1.0?

One more thing to do: I realized while playing with Project.toml that some of the environment variables needed by julia have changed between 0.6 and 0.7/1.0.
Do you think it's safe to just always define all of them as a simple solution? (for example, JULIA_HOME is now renamed to JULIA_BINDIR, so can we just define both?)

Do you think it's safe to just always define all of them as a simple solution? (for example, JULIA_HOME is now renamed to JULIA_BINDIR, so can we just define both?)

From a repo2docker point of view: sure. Though it sounds like it would be more of a question for Julia people? Maybe add specific comments to the ones that we can remove at some point when we remove 0.6 support? As a form of forward looking house keeping.

Maybe add specific comments to the ones that we can remove at some point when we remove 0.6 support? As a form of forward looking house keeping.

Done!
Alright, I think this is all set to be merged! I'm sorry for the delay on just that last piece.
This PR adds unit tests for specifying a specific old julia version (v0.6.3) and for specifying using the new julia version, v1.0.0, as well as testing that the environment variables are set correctly for both julia <=0.6 and >=0.7.
I have also verified manually that the julia notebooks run correctly from the docker image created by each of the unit tests! :)
So merge away! :)

Merged!
Do you want to deploy these changes to mybinder.org directly? If yes we have instructions for deploying that should explain how to deploy the new revision of repo2docker.

wahooooo! Way to go!

Hooray! Thanks Tim! :)

Do you want to deploy these changes to mybinder.org directly?
Yes, I think so! Is there anything I should consider as to why I might not want to do that? Thanks!

Yes, I think so! Is there anything I should consider as to why I might not want to do that? Thanks!

I don't think so. We can always revert it when we notice a bug (or fix the bug and deploy the fix). Beware the feeling of responsibility and excitement from deploying a change you made to production where lots of people will use it straight away can be addictive 😄.
I'd suggest you drop by https://gitter.im/jupyterhub/mybinder.org-deploy and give people a short heads up about the deploy when you are ready. We use the chat as a kind of log book and source of "what has been going on". We try and group deploys to Tuesdays and Thursdays, mostly so that people can plan a bit to be available in case follow up is needed (luckily tomorrow is Tuesday!)

Thanks for the explanation!

beware: the feeling of responsibility and excitement from deploying a change you made to production where lots of people will use it straight away can be addictive 😄

Haha 😋 I will beware, indeed!
Ah, sorry i missed today! Actually, if you don't mind, would you be able to deploy this? Or just allow it to be deployed the next time you have something to deploy? I'm a bit busy this week. :) No problem if you can't; i'll look at it this weekend!

This has been deployed: https://github.com/jupyterhub/mybinder.org-deploy/pull/758

Thanks a lot Tim!! :)


fix autoload dir when installed via composer

Ping @lyrixx
The autoload dir wasn't correct (I tested it using composer global require and composer require inside a 2.* Symfony project).

yeah, this was missing when removing the usage of target-dir.
👍

Good catch, thanks Quentin.

I just released v1.3.1


Add gog.js gameID cache (and/or other store_module files?)

After first run / saving config with new GOG URL save gameID until URL is changed.
Check for faster method (https://www.quora.com/How-is-SQLite-faster-than-writing-to-a-normal-file ; https://healeycodes.com/saving-data-in-javascript-without-a-database):

better-sqlite3
saving to file (fs) <- seems to be faster

Benchmarks:
Setup:

Linux Fedora VM (6 cores 12GB RAM)
Performed creation of db, reading and deletion

Results:

TODO

[ ] benchmark speeds
[ ] optimize JSON structure
[ ] optimize updating values
[ ] add cache implementation to:

[ ]  epic.js
[ ]  steam.js
[ ]  microsoft.js

Benchmarks:
Setup:

Linux Fedora VM (6 cores 12GB RAM)
no EPIC request
Performed:

noCache = no cache (getting data with puppeteer)
firstRun = getting data with puppeteer and creating cache.json file
secondRun = getting data from cache.json file

Results:


Log collector name when it times out

I have tested this manually and via testcase. unfortunately getting the testcase exactly right requires much big refactor of scheduler - which I am going to avoid.

+1

If you do it the name I mentioned then the log file will automatically show the collector's name there

I have changed the code to use collector.log.warn !

+1


Any way to setMaxStackSize ?

I've been trying to set ItemStacks with >64 amount in the inventories, but with no effort. Is there any way to allow oversized stacks in smartinvs?

I don't think that's different from the vanilla Spigot. I'll check, but, if I remember correctly, you need to use NMS in order to achieve this.


Update iot-hub-mqtt-support.md

@kdotchkoff,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

#sign-off


How to update existing container from image with new version of container?

I download image and create container.
Then i create new image with new version of the container, and i want to update all my containers to the new version.
I update the image to the new version of the container from tarball:
lxc image import /backup/new.version.tar.bz2  --alias my-image

How to update existing container from new image?
The command
lxc launch my-container my-image

give error: The container already exists

I can do this by the script https://github.com/vistoyn/lxd_backup with command:
lxc-stop {container_name}
lxc-restore {container_name} /backup/new.version.tar.bz2

But I think this is strange way.
I can't use LXD private server and snapshots system because I haven't second server. I use Amazon S3 as backup storage of the my containers, and sometimes download container's backups by FTP.

Right so there isn't a way to just replace the rootfs of a container from an image. You're expected to create a new container from it, so deleting the old one.
If you care about the container configuration, which is the only thing that would be lost if you were to just delete the container before launching it again, then something like this would do the trick:
lxc config show my-container > old-config
lxc delete my-container
lxc init my-image my-container
lxc config edit my-container < old-config
lxc start my-container

Alternatively, you could just have any relevant container config in a profile and just use the -p argument of launch to apply that to the new container, saving the show/edit steps.
We don't see this as a far common use case since folks usually care about the data in the container and so don't really feel the need to wipe it all clean to replace with a new image, without also wanting to modify the config.

I think that all the users data should be mounted in a container so that they do not accidentally remove the removal of the container.
For example:
$ lxc config device add disk_name test disk path=/folder source=/data/test/folder

And update command should replace old container on new container by rsync.

lxc config show my-container > old-config
lxc delete my-container
lxc init my-image my-container
lxc config edit my-container < old-config
lxc start my-container

It's too long. Maybe should make a single command?

I don't believe this is a common enough case that it warrants its own command.
If it is something you have to very commonly do, writing a short shell script for your environment should be easy enough.
If other people need this, please comment in this issue and we may re-consider.

@stgraber The command described in https://github.com/lxc/lxd/issues/2303#issuecomment-241753846 does not works anymore.
Old Container has this entries in dnsmasq:
I'm using the latest 2.12 ppa packages.
Here is the test
# lxc init images:ubuntu/xenial test
# lxc start test
# grep test /var/lib/lxd/networks/br1/dnsmasq.leases
0 00:16:3e:7c:9b:4b <IP_ADDRESS> test *
1490578933<PHONE_NUMBER> 2a01: test 00:01:00:01:20:6b:0d:29:00:16:3e:c0:c7:32
# lxc config show test
architecture: x86_64
config:
  boot.autostart: "false"
  image.architecture: amd64
  image.description: Ubuntu xenial amd64 (20170326_03:49)
  image.os: Ubuntu
  image.release: xenial
  image.serial: "20170326_03:49"
  limits.cpu: "2"
  limits.memory: 512MB
  volatile.base_image: 9d9604bcf7cb52ced1d2133398014c22c5acc7c22986d426bc6cfb055c865090
  volatile.eth0.hwaddr: 00:16:3e:7c:9b:4b
  volatile.eth0.name: eth0
  volatile.idmap.base: "2328224"
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":2328224,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":23$
8224,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":2328224,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Host$
d":2328224,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: RUNNING
devices: {}
ephemeral: false
profiles:
- default
# lxc config show test > /tmp/test
# lxc delete --force test

# lxc init images:ubuntu/xenial test
# lxc config edit test < /tmp/test

# egrep 'test|179 ' /var/lib/lxd/networks/br1/dnsmasq.leases
0 00:16:3e:7c:9b:4b <IP_ADDRESS> test *
1490578933<PHONE_NUMBER> 2a01: test 00:01:00:01:20:6b:0d:29:00:16:3e:c0:c7:32

# lxc start test

# egrep 'test|179 ' /var/lib/lxd/networks/br1/dnsmasq.leases
0 00:16:3e:7c:9b:4b <IP_ADDRESS> LXC_NAME *
1490578933<PHONE_NUMBER> 2a01: test 00:01:00:01:20:6b:0d:29:00:16:3e:c0:c7:32
# lxc exec test hostname
LXC_NAME

Looks like a missing variables expression, not?
My Network config:

# lxc network show br1
config:
  ipv4.address: <IP_ADDRESS>/24
  ipv4.dhcp: "true"
  ipv4.dhcp.expiry: infinite
  ipv4.dhcp.ranges: <IP_ADDRESS>-<IP_ADDRESS>
  ipv4.firewall: "false"
  ipv4.nat: "false"
  ipv4.routing: "true"
  ipv6.address: 2a01:../64
  ipv6.dhcp: "true"
  ipv6.dhcp.expiry: infinite
  ipv6.dhcp.stateful: "true"
  ipv6.firewall: "false"
  ipv6.nat: "false"
  ipv6.routing: "true"

@jkroepke still works fine here on 2.12, so I suspect it may be a storage backend specific issue.
Can you post the output of "lxc info" (no argument)?

Here we go:
~$ lxc info
config:
  core.https_address: <IP_ADDRESS>:9000
  core.https_allowed_credentials: "true"
  core.https_allowed_headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
  core.https_allowed_methods: GET, POST, PUT, DELETE, OPTIONS
  core.trust_password: true
api_extensions:
- storage_zfs_remove_snapshots
- container_host_shutdown_timeout
- container_syscall_filtering
- auth_pki
- container_last_used_at
- etag
- patch
- usb_devices
- https_allowed_credentials
- image_compression_algorithm
- directory_manipulation
- container_cpu_time
- storage_zfs_use_refquota
- storage_lvm_mount_options
- network
- profile_usedby
- container_push
- container_exec_recording
- certificate_update
- container_exec_signal_handling
- gpu_devices
- container_image_properties
- migration_progress
- id_map
- network_firewall_filtering
- network_routes
- storage
- file_delete
- file_append
- network_dhcp_expiry
- storage_lvm_vg_rename
- storage_lvm_thinpool_rename
- network_vlan
- image_create_aliases
- container_stateless_copy
api_status: stable
api_version: "1.0"
auth: trusted
public: false
environment:
  addresses:
  - <IP_ADDRESS>:9000
  architectures:
  - x86_64
  - i686
  certificate:
  certificate_fingerprint: 4901bf6b0ba138e5aa96595b5a3a5ce50cc414350a21488a07d81384e38ed3aa
  driver: lxc
  driver_version: 2.0.7
  kernel: Linux
  kernel_architecture: x86_64
  kernel_version: 4.4.0-66-generic
  server: lxd
  server_pid: 9333
  server_version: "2.12"
  storage: btrfs
  storage_version: "4.4"

@stgraber Why is the storage backend related with dnsmasq/network?

@jkroepke because your issue doesn't have anything to do with dnsmasq/network, /etc/hostname isn't modified as a result of DHCP or other network events but is instead set as the result of a file template which is applied the first time the container starts and sets it to the container's name.

@stgraber I thought this behaivor was only on cloud-init. You are right.

@jkroepke oh, actually, this all makes sense :)
Your instructions above will clear the "volatile.apply_template: create" config entry when you do "lxc config edit test < /tmp/test". That volatile property is what causes LXD to apply the templates for files like /etc/hostname.
So clearing it is what causes /etc/hostname to contain LXC_NAME rather than the hostname. The dhcp client in the container then uses /etc/hostname as its hostname field, resulting in it landing in dnsmasq's lease table.

To clarify the handling of volatile.apply_template:

"lxc init images:ubuntu/xenial test" creates the container and sets "volatile.apply_template" to "create"
"lxc start test" then detects that "volatile.apply_template" is set, applies all the templates listed for the "create" target and then unsets the volatile key (as "create" templates are a one-time thing).
"lxc config show" at that point doesn't include the "volatile.apply_template" key anymore, so your saved config doesn't have it

The next time you create and restore the container config, this effectively removes the "volatile.apply_template" key from the container's config, so when it starts, the templates aren't applied and /etc/hostname remains untouched.

@stgraber Thanks! Rebasing Container on newer images works fine now.


Python3 not working

Please follow the general troubleshooting steps first:

[Yes ] Ran brew update and retried your prior step?
[ Yes] Ran brew doctor, fixed as many issues as possible and retried your prior step?

Bug reports:
I have a version of python 2 from miniconda, today I try to use python 3 on my mac, I tried to install from 'brew install python3', but when I start the python3 shell, I got an error:

It seems python3 get access to the python 2 site-packages. Not sure if this is the problem due to the homebrew install version of the python3, or some other issues. Thanks!

Do you have PYTHONPATH set? Python 3 uses it too, so it would see your miniconda Python 2 site-packages if so.

Great, thanks for the quick response! It does seem the problem comes from the PYTHONPATH! After I modify it, everything works fine now. Thanks!


Remove entry for Canarias

Thanks for creating this comprehensive CSV.
I'd have one suggestion for improvement: Having an extra entry for Canarias (additionaly to mainland Spain) seems wrong as there's no such thing for other countries with disconnected areas, and it's also not in line with this statement in the README:

Version 1.0 has been updated to use the centroid of the largest land mass. This way large countries with many disparate areas (like USA, New Zealand, Chile, Portugal) have more rational center points.

Hi, thanks for asking. I sortof agree with you, but the data source I'm using does include Canarias as a unique country and I do not want to be the arbiter of country disputes here in this repo.

Hm, yeah in our data source we're using the "COUNTRY" attribute. It seems like if we use "COUNTRYAFF" attribute it may be more correct


Update requirements.txt

alembic upgrade head fails - downgrade to Werkzeug====0.16.1

@yossich6 this is the commit I made at the time


ImportError: No module named 'agnez'

I can't find this module in here:
https://github.com/AgnezIO/agnez.git@55657e5148ce58493f1847a
would u uploAD it again pls?

Agnez hasn't change much since then. You can just use master.


Reproduce Hierarchical Attention Networks for Document Classification for German

German NLP is a curated list of German NLP resources including datasets.
P.S. This paper is one of the first to work on Embed, encode, attend, predict.

Hey @the-ethan-hunt are these new issues for the Recipe work we are doing with KWOC?
If yes, we should also label NLP Recipes or something similar.

Yes, @NirantK . I will add the Recipes tag. My bad forgot it.

@the-ethan-hunt is there anyone going to be working on the Recipe related projects? If not, let's close these out and reduce some clutter.

.@the-ethan-hunt closing these recipe issues for now.


fix(all): Add macOS Privacy Manifests

Description
This PR is to add privacy manifests to macOS.
Related Issues

Fix #3250

Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I titled the PR using Conventional Commits.
[X] I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
[ ] All existing and new tests are passing.
[X] The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
[x] No, this is not a breaking change.

Thank you! The failing CI jobs are unrelated to this change, so this should be good to go


Tokio-uring design proposal

Rendered
The RFC proposes a new asynchronous Rust runtime backed by io-uring as a new crate: tokio-uring. The API aims to be as close to idiomatic Tokio, but will deviate when necessary to provide full access to io-uring's capabilities. It also will be compatible with existing Tokio libraries. The runtime will use an isolated thread-per-core model, and many types will be !Send.
The repo contains a proof-of-concept implementation.

I feel like keeping io_uring and IOCP runtimes separate would be the best choice. There's no question about a thread per core architecture being a better fit for io_uring, and while IOCP can be used that way too (and pretty efficiently afaik if you create the completion port with a concurrency value of one), it would still be a bunch of additional code to maintain and logic to generalise. Note that IOCP is also typically used with the threadpool provided by the Windows kernel itself, as illustrated by the .NET TPL (even though that will change in .NET 6).
The way I see it, "vanilla" tokio already does an amazing job at being an efficient and portable runtime. If you're willing to pay the complexity cost of using a thread per core architecture and dealing with completion based IO for the extra performance, your probably already know where that code is going to run. Separate, targeted runtimes seem like the obvious choice in that scenario, especially since depending on io_uring itself isn't particularly portable (a portable runtime without support for BSD and Darwin, and 90% of Linux machines out there (just throwing random numbers here), doesn't sound like the best way to build portable stuff).

The way I see it, "vanilla" tokio already does an amazing job at being an efficient and portable runtime. If you're willing to pay the complexity cost of using a thread per core architecture and dealing with completion based IO for the extra performance, you probably already know where that code is going to run. Separate, targeted runtimes seem like the obvious choice in that scenario, especially since depending on io_uring itself isn't particularly portable (a portable runtime without support for BSD and Darwin, and 90% of Linux machines out there (just throwing random numbers here), doesn't sound like the best way to build portable stuff).

I think there's a very common use case where you have a client-server architecture and want to leverage io_uring on the server-side.
Unless I am missing something, having separate runtimes in this case would make it really hard to share code between client and server.


Add Ebook Laravel For Beginner

What does this PR do?
Add Resource(s) | Remove Resource(s) | Add info | Improve Repo
For resources
Description
Why is this valuable (or not)
How do we know it's really free?
For book lists, is it a book?
Checklist:

[x] Not a duplicate
[ ] Included author(s) if appropriate
[x] Lists are in alphabetical order
[ ] Needed indications added (PDF, access notes, under construction)

check travis-ci output from linter


Include Cases for Cities

I would like to see an option to view the cases from cities of states/countries.
Overall good program.
Thank you
Kitty

I can take a look @ahmadawais. If the data is available. Btw, great project!


Manage multiple charts of account.

The project that I'm working on at the moment requires transactions in multiple currencies.
I'd made some changes to make my tests pass when using a currency other than Money.default_currency (https://github.com/danelowe/double_double/commit/99ab2fd3c4734a4aaf269640c6eab11b41372ee9), but then as I was committing I realised that the solution would actually be to create a form of multi-tenancy, where accounts could (but wouldn't have to) belong to a chart of accounts.
Each chart of accounts could then have their own base currency, and all amounts in any of it's accounts would be forced to use that currency.
What are your thoughts on this? I'll get started on it as soon as I come to that stage in the project.

would it be ChartOfAccounts, or AccountSet, or?

I see three potential features here.
A.  Supporting multi tenancy.
B.  Accounts of mixed currencies.
C.  Enforcing a base currency.
If multi tenancy is the goal (A): I agree that creating an abstraction of a new ChartOfAccounts model and then assigning accounts to a particular COA would be proper.  If your project is a SAAS offering and there's the potential for users to define their own accounts, sandboxing each user to their own COA would be smart.
If multi currency support is the goal (B): stay the course with your revision (danelowe@99ab2fd).  It's a solid path.  If your project just needs to support multiple currencies, it really should exist in the same Chart.
Thinking further, I also like your idea of a forced base currency (C), but store that attribute on the Account.  I would advocate that it's up to the implementing developer to choose how much restriction to place on their accounts.
Where the account is forced to a specific currency if the currency is defined on the account.  Otherwise the account is potentially a mixed currency account.
e.g.  Imagine a contrived wallet app.  I would think it should be possible to have strict asset accounts, but to not require strict expense or liability accounts.
DoubleDouble::Asset.create! name: 'Cash', number: 1, currency: :aus
DoubleDouble::Asset.create! name: 'Bitcoins', number: 2, currency: :btc
DoubleDouble::Expense.create! name: 'Spending', number: 3

I'm rambling a bit, but at this point I'm game for any combination of the three features, above.
Are we on the same page?

After sitting on this for a day-- I would gladly merge your multi currency work.  I think there's also an opportunity to write a balance method that doesn't simplify down to one currency.
i.e. add a method balance_without_conversion that returns a hash with each respective currency amount.  {usd: 500, aus: 800}
But you need a ChartOfAccounts abstraction for your project, let's do it.

Hi Mike,
I have to run soon.
My project isn't actually SaaS, but will require operating accounts in a couple of different regions and currencies. At the moment I'm working on implementing the multiple Charts of Accounts options, because:
a) It's more flexible, and
b) To the best of my understanding, it makes more sense from an accounting perspective, as I don't think multiple currencies should be used in the same chart of accounts, and it causes a number of issues, and
c) For my use case at least, I don't see any downsides to having multiple charts of accounts. It will be easy to set up the same accounts under multiple charts.
Basically, at this point I am probably going to work on it in order of A, C, then B. And B would have to be specifically enabled for those who don't care too much about things lining up correctly.
I will come back later with more details, but just thought I would let you know where I am heading at the moment.

I hear you, Dane.  While we may not currently agree on the use-case solution, we appear to agree on the features, themselves.
I'm closing this issue, and its place, creating three new issues to track each proposed feature.


🐛 Bug Report: TypeError: unsupported operand type(s) for +=: 'async_generator_asend' and 'async_generator_asend'

Which component is this bug for?
Langchain Instrumentation
📜 Description
When using LangChain instrumentation on an AgentExecutor, the error specified in the title occurs.
👟 Reproduction steps

Add LangChain Instrumentation to application, either manually or through automated instrumentation.
Make a call to any LangChain AgentExecutor, e.g. in the following LangServe context for a simple chat app:

agent = create_tool_calling_agent(model, tools, agent_prompt)

agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
)

add_routes(
    app,
    agent_executor.with_types(input_type=Input, output_type=Output),
    path="/chat",
)

By default, stream_runnable is set to True, which then throws the error in the title. Setting stream_runnable to False allows the agent executor to run without issue.

👍 Expected behavior
No error - AgentExecutor chain should complete without issue, traces should be available at destination specified in instrumentation.
👎 Actual Behavior with Screenshots

chat-app-langchain  |   File "/usr/local/lib/python3.11/site-packages/langchain/agents/agent.py", line 560, in aplan
chat-app-langchain  |     final_output += chunk
chat-app-langchain  | TypeError: unsupported operand type(s) for +=: 'async_generator_asend' and 'async_generator_asend'

Which links to the following LangChain agent code: https://github.com/langchain-ai/langchain/blob/master/libs/langchain/langchain/agents/agent.py#L560C18-L561C14
🤖 Python Version
Tried with both 3.11 and 3.12
📃 Provide any additional context for the Bug.
Tried with opentelemetry-instrumentation==0.46b0 and both langchain==0.2.1 and langchain==0.2.2.
Exception is thrown across multiple agent types.
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

Are you willing to submit PR?
Yes I am willing to submit a PR!

Thanks @audols! Which instrumentation version were you using?

@nirga Thanks for the quick reply, just updated to opentelemetry-instrumentation-langchain==0.25.3 and was able to confirm the same; initially tried on 0.21.3.

Hey @audols I've tried reproducing it, but didn't get any error. Wondering if you can provide a full snippet of what caused that error? (you can share it privately with me over e-mail / slack if you prefer)

The good thing is that when trying to reproduce it I found a small issue with tools & agents so we'll fix that as well now


visual feedback

Priority: pulsing LED. requires solving many problems on the max side and how we channel that data. Not part of OT, a separate channel (doesn't represent change in the definition to the system). like the stderr stream or max console, they aren't part of the max patch, but they are still linked.
possible method is output from gen~: as an [out] or as writing into a [buffer~]?
possible uses:
possible implementation:

a blinking LED near its related output
the output itself blinks

Creating a blinking LED would be more of how the data will come in and how it would pulse. From the Javascript side it really only would be any shape (preferably something that looks like a light) and just have the emission or material color change based on values coming. Should be pretty simple to implement.

That's great to hear. We'll need to set up this secondary communication channel between the server and the client (as it will be useful for other things as well).
What if what the client received was an update on the blink rate value and the length of the blink (aka pulse-width). Pros and cons:
Pro:

Only sending rate/pulse-width messages means fewer messages

Con:

The blink and its source waveform will likely drift out of sync since they have different clock sources -- a JS Timeout(?) function and MSP/gen~ respectively

I see three milestones for the LED design:

An LED which is either fully on or fully off. This would represent square waves, gates, triggers. Its pulse-width could also be controlled.
An LED which has a variable amount of 'ON'. This would represent waveforms like triangle waves, sawtooths, etc. (in other words, would represent amplitude values between 0. and 1.
An 2-colour LED, where one colour represents amplitude between 0. 1. (positive) and the other colour between 0. and -1. (negative). would represent Sine waves, noise (maybe), etc.

I'd vote for getting the simplest case working first: the LED displays the last value it received, and this value is clamped in the range -1..1, and either it displays absolute value or it shows a different colour for negative signals.
I don't think we need to send rate/pulse-width data packets just now. The socket latency on a localhost should be low enough that just displaying the most recent value would work well enough for triggers and LFOs, and these are about the only ones where the representation can be fully unambiguous. A LED in VR can flicker at most at around 45hz (because Nyquist), meaning it can only really show sub-audio waveforms (and special cases like white noise and DC, which happen to look the same at all frequencies).
For other kinds of signal there are a lot of things we can do, but it is a hard problem -- part of the general difficulty of representing the important features of high-resolution data (audio signals) with a low-resolution output (visuals). We could show analysis of higher frequencies (like average envelope, spectral centre, etc.) as these analyses are also low frequency. But that might get expensive and I'd rather save it for later. Even then, the problem is hard, as you don't know in advance what kind of signal you might be receiving, and thus what kinds of features make sense. It might be a unipolar signal (in which case, envelope tracking the average value might make sense) or it might be bipolar (in which case, the average will not represent it well, but RMS average would, so long as the signal has no DC offset... and so long as representing envelope is more important than representing the sign). It might have hard edges like a square (in which case averages might wrongly soften the edges). Also, it might be oscillating between +4 and +5, in which case clamping at +/-1 makes no sense. We dealt with some of this in working out the streamline visualisations in Gibberwocky, which is a very similar problem, and we solved it by adapting the range to the signal. We show a kind of rolling oscilloscope of the most recent N values (a hundred or so) for any signals generated. We track the average min & max value of a signal to work out the vertical range of the streamline graph, and extend the graph if the signal goes beyond those boundaries, and periodically shrink it if it has stayed in a smaller range for a while. (The values themselves are sent as a single snapshot of all active signals every 33ms, and the renderer takes care of storing them in a list to make the graph.) So I would imagine in the long run that we could do something similar for MSVR: to adapt to the kind of signal received where we can, and show multiple properties (instantaneous value, RMS-smoothed envelope, spectral balance etc.) in mini-oscilloscopes.
For now, Max will need to take a periodic snapshot every 10ms or so of all visualized LEDs, and send them as an array to the renderer. We could use a buffer~ in Max to capture these snapshots out of gen~, just giving each LED a unique index in the buffer~. Then we'd send the buffer~ contents over a websocket directly to the renderer, as a separate channel of communication. (At this stage, I don't think it even needs to go through the server -- we only need to know what the unique indices are.) I believe the [ws] object in the @worldmaking/Max_Worldmaking_Package can send jitter matrices as Float32Array buffers, and we can use [jit.buffer~] to wrap a buffer~. Or I could add support to [ws] for sending a buffer~ directly.

This is an example of the adaptive streamlines (oscilloscopes) in Gibberwocky, FYI.

[ ] get the paths of all module outputs.

[ ] create lookup table to map output paths to a buffer channel.

[ ] script each module outlet to a [poke] gen op. assign a [constant nn] op, where nn is the buffer channel

[ ] send an update of the lookup table containing outlet paths and channel assignments to clients each time this table is modified.

@grrrwaaa I've managed to script poke objects into [gen~ msvr_world] but the jit.buffer object creates a new matrix plane for each buffer channel. This means that with a patch of say 5 nodes, could require between 5-20 channels and as many matrix planes. You could see how this will very quickly get quite expensive on the jitter side. Not sure how to overcome this.

@zodsmar I've merged your work on instancing and my work on the max client into a new branch called merge. You could continue working on instancing if you wanted... but the 'merge' branch is up to date with both of our work. I did this so that you could run the max patch to get the data from gen for outlet visualizations. ALSO, and this is important, there were some errors in the scene JSONs that I fixed (particularly scene_rich.json and scene_simple.json)

[ ] outlet colour & leading-end of cable (the end of the cable that would be plugged into an inlet) will pulse their colour.

Receiving data directly from max to the server using port 8084 (Port subject to change). Data comes in -1...1 and is being clamped to 0...255 for RGBA values. Depending on how we do colors and emissions might need to change the clamping values but for now this works. I get path plus value clamped. Just need to put the value to outlets. Will do this once Project Ghost is finished being restructured.

@Zodsmar heres the current spec:
{\"lfo_1__sine\":-0.7605468034744263\,\"lfo_1__phasor\":0.6140456795692444\,\"lfo_1__pulse\":1\,\"lfo_2__sine\":-0.7223623394966125\,\"lfo_2__phasor\":0.6223999857902527\,\"lfo_2__pulse\":1\,\"ffmvco_1__vco_1\":0.3347249925136566\,\"ffmvco_1__vco_2\":-0.3240717351436615\,\"ffmvco_1__master\":0.9353091716766357\,\"vca_1__output\":0\,\"comparator_1__max\":0\,\"comparator_1__min\":0\,\"outs_1__left\":0\,\"outs_1__right\":0}

this is nearly ready: just need to change the outlet colour, since the viz data is ready.

nearly ready.


Lighthouse - accessibility & SEO enhancements

https://github.com/prosopo/captcha/issues/882 etc.

Closing since all issues RE this are on prosopo-website repo
Additionally, not an epic since this is an ongoing piece of work when new changes occur


List soukai as peer dependency instead of dependency

As discussed in #4

Fixed in v0.4.1.

Fixed in v0.4.1.


Add codecov and npm badges

Description
Added badges for npm and codecov
Resources

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@7426036). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             master       #35   +/-   ##
==========================================
  Coverage          ?   100.00%
==========================================
  Files             ?        10
  Lines             ?       121
  Branches          ?        14
==========================================
  Hits              ?       121
  Misses            ?         0
  Partials          ?         0

Continue to review full report at Codecov.

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

The codecov warning is because there isn't a base master commit to compare


MWPW-125711 | Fixing the indentation of question and answer in accordion

Before: https://main--dc--adobecom.hlx.page/acrobat/online/crop-pdf
After: https://mwpw-125711--dc--adobecom.hlx.page/acrobat/online/crop-pdf

Holly reviewed and approved! merging this one now.


fix: symbol upload fails for large numbers of files

Description
Updates symbol-upload to v9.1.1 with this fix https://github.com/BugSplat-Git/symbol-upload/issues/119
Checklist

[x] Tested manually
[x] Unit tests pass with no errors or warnings
[x] Documentation updated (if applicable)
[ ] Reviewed by at least 1 other contributor

@daveplunkett is on the road and will comment when he is back at a keyboard

We're getting this warning from symbol-upload that's throwing off our automated build systems. Symbols seem to be uploading fine(?) Anyway to silence the warning?
(node:1660) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time (Use symbol-upload-windows --trace-warnings ...to show where the warning was created)

We're getting this warning from symbol-upload that's throwing off our automated build systems. Symbols seem to be uploading fine(?) Anyway to silence the warning?
(node:1660) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time (Use symbol-upload-windows --trace-warnings ...to show where the warning was created)

Hi @fuzzybotcg the issue you mentioned is fixed in the v1.3.4 release, available for download here. It will also be available via the Unreal Marketplace soon.


Add a loading icon for the comments section

This is harder to add a picture of! The icon consists of rotating dots.

This is harder to add a picture of! The icon consists of rotating dots.

Can you please share a link to the HTML Preview?

Preview:
https://htmlpreview.github.io/?https://github.com/Anthony-Fiddes/portfolio/blob/loading/portfolio/src/main/webapp/index.html


Scheduled notifications

Is it possible to sendMessages on job procedure ?

I also complain about the same problem. How do I fix this problem on my Schedule Builder website?


How to provide angular core injection tokens

Type of Issue
[ ] Bug Report
[ ] Feature Request
[X] Documentation

Description
No provider for InjectionToken Platform ID! when I run ng serve

How To Reproduce
1. import platfrom id injection token:
import { PLATFORM_ID } from '@angular/core'
2. inject it in the constructor of a service & console log it:
constructor(@Inject(PLATFORM_ID) private platformId) {
console.log(platformId);
}

Expected Behaviour
platformId get's printed to the console without a dependency error.
Version Information
ng-packagr: ^2.0.0-rc.2 and ^1.6.0 gives the same error

have to close this as it turns out to be happening only when you use npm link during development. have to push a new version to npm every few minutes now to test the lib but at least it everything works now.

have to close this as it turns out to be happening only when you use npm link during development. have to push a new version to npm every few minutes now to test the lib but at least it everything works now.

I also ran into this error, and don't understand it. Why would linking of a library have any side effects on providers for a project. Especially providers from @angular/core?
Publishing just to get around the error is not an acceptable work around. What I don't understand is the nature of the problem. I've been debugging the core.js trying to figure out why this is happening, but so far no luck.

Anyone find a solution, other than rebuilding the library every time you want to run your code?


EXSWHTEC-383 - Implement tests for hipGraphAddNode API

Implement positive and negative tests for hipGraphAddNode API

PR has been merged into develop branch via commit 1e15bfca2317bc7893c9e4a134ced61485bbe3ef.


update m365 status condition check. Closes #298

Closes #298
Here I updated the commonly used 'm365 status' condition check from
$m365Status -eq "Logged Out"

to the following
$m365Status -match "Logged Out"

@pkbullock, should I also update the updateDateTime variables within the sample.json files?

once again thanks @Jwaegebaert for fixing this 👍👍👍

Ill keep the PR on the queue as its a bigger one, but I'd like to add your recognition so I will add the metadata :-)

Ive been going through al the changes, if its ok, not going to update the metadata with the credit, it may distort the samples authors, instead, ill credit via a different method. Its a great change and sorry it took so long to review.


Question about Masked Scene Contrast evaluation

Hi @Gofinge, thanks for your great work! I have some questions regarding the evaluation of Masked Scene Contrast.

If I understand correctly, in tab. 2(a) first row, MSC represents the results of pretraining on ScanNet + ARKitScenes and finetuning on ScanNet for semantic segmentation. SC denotes train from scratch. I wonder does SC denotes train from scratch only on ScanNet?
Tab. 1 shows the results of the model pretrained only on ScanNet. Did you compare this model with model training from scratch on ScanNet?

Thank you in advance!

If I understand correctly, in tab. 2(a) first row, MSC represents the results of pretraining on ScanNet + ARKitScenes and finetuning on ScanNet for semantic segmentation. SC denotes train from scratch. I wonder does SC denotes train from scratch only on ScanNet?

Yes, sc only on ScanNet. No semantic label for ArkitScene

Tab. 1 shows the results of the model pretrained only on ScanNet. Did you compare this model with model training from scratch on ScanNet?

Maybe needs our reader to manually compare with the SC result on ScanNet, it is the same as the one in the main result table.


First anchor click doesn't scroll smooth

I have a problem i can reproduce in any browser.
I have a navigation and i have anchor points.
If i reload the website and click directly on an anchor so the anchor moves to the top, only the fist time the anchor doesn't scroll. After that everything behaves live it should.
If you want you can test it here: https://986fans.de/
For example scoll down and click on "BEISPIELE SCHÄDEN" when its in the middle of the screen (from top and bottom) to move it to the top.
If you have questions about the issue, please let me know.
Thanks

I'm actually unable to see that happening on my end. Hmmm...

Hi, thanks for your feedback. I've made a video. You can see the effect at 0:05 when i click on the anchor "FAQ / GENERELLE HINWEISE" the side doesn't scroll:
https://youtu.be/ClB5YppLsAs
If i click the second time, the page scrolls smoothely.
To get this effect, the browser cache needs to be empty.
Let me know if you need some more infos or how i can help to solve the problem.
Thank you!

OK, did some more research.
If the URL in the browser says https://986fans.de/ and i click on an anchor, the site doesn't scroll smooth to that anchor the first time i click on that anchor.
If the URL in the browser says https://986fans.de/index.html and i click on an anchor, the site scrolls smoothely to the anchor i have clicked on.
So it maybe the problem is that the browser doesn't know where he is if there is no index.html appendix. Sorry, hard to describe. English is not my mother language. ;)
Thanks and regards

OK, solved the problem by renaming the anchors from
anchorname</a
to
anchorname.
Now everything works fine.

Aha! Glad you got it figured out. 😀


calling Fiber#resume directly from C causes error

When Fiber#resume is called directly from C, the method returns the argument passed, without running any code on the fiber context.
Looking at the source code, it seems like that the fiber implementation is not handling such case.
In the current implementation, fiber_switch (called by mrb_fiber_resume) replaces the content (i.e. mrb->c) and returns, hoping that the VM will continue running the operations on the changed context.  This works fine if mrb_context_run is the caller of mrb_fiber_resume.
However in case Fiber#resume is called directly from C code, mrb_fiber_resume returns directly to mrb_funcall_with_block and then to the C code, without running the operations on the changed context.
Originally discussed in this tweet.  Sorry for the lack of code for reproducing the issue.

Can you show us your code snippet?  It doesn't have to be reproducible.
I just want to know how you called #resume.

@matz Thank you for looking into the issue.
The diff is https://github.com/h2o/h2o/commit/3152e4c.  The commit removes the wrapper used to call Fiber#resume, and calls the method directly.
With the change, the mruby handler of H2O stops working correctly; when called for the first time, it returns the argument passed to Fiber#resume, succeeding calls end up in exceptions that say: FiberError: can't cross C function boundary.

Have you tried https://github.com/mruby/mruby/blob/master/mrbgems/mruby-fiber/src/fiber.c#L231 yet?

mrb_fiber_resume should work from C functions, but it currently does not.  I consider it's a bug, but it requires huge API change. Please use proc workaround for a while.

@matz Thank you for the answer.  Will use the proc workaround.
@Asmod4n Thank you for the suggestion.  Unfortunately as stated by @matz calling mrb_fiber_resume directly does not solve the issue.

fiber_switch protects from calling Fiber#resume via mrb_funcall:

FWIW, to be precise, the code does not protect Fiber#resume from being called through mrb_funcall; the guard exists to prevent fiber switches that involve a C stack.  For example if the call stack is C -> mruby -> C* -> ... Fiber#resume, it is impossible to swap the stack of mruby since the second call stack of C (marked with *) cannot be swapped.
A fiber switch should not be deterred unless when a C function is called from mruby; fiber_switch is implement correctly in that respect.


settings: Fix duplicate logging from zulip.auth logger.

The logger defines a full list of handlers, meaning propagate=False is
needed, to avoid the log line propagating further up the logging tree
and getting logged multiple times by the duplicated handlers.

Merged, thanks @mateuszmandera!


Inverse buttons hard to read when hovering in dark mode

The Issue
On dark mode, inverse buttons are hard to read when hovering. They are missing some css.
.btn--inverse should use the color $lbry-white when hovering (in dark mode).
Steps to Reproduce

Hover over the refresh button on the transactions list
Look

Hey Sean, I'll take this one.


API that fully update the robot's data

Hello,
First of all, I appreciate your effort to maintain this nice repo.
I have a quick question about how Pinocchio updates the robot's properties.
It looks like Pinocchio has multiple steps to update the robots quantities given q, qdot.
For instance, forwardKinematics does not update the frames' placement, and therefore updateFramePlacements should be called afterward.
Also, ccrba separately update centroidal quantities.
I am wondering is there any function where I could update all the robot's quantities at once and save results at Dataclass?
If not, could you kindly explain what kind of APIs should be called in which order to correctly update the quantities?

There is the function computeAllTerms that does everything, except centroidal quantities. I will update it accordingly.

There is the function computeAllTerms that does everything, except centroidal quantities. I will update it accordingly.

There is the function computeAllTerms that does everything, except centroidal quantities

Since @junhyeokahn mentioned frames, I will mention that computeAllTerms does not update frame placements either
BTW, of you just want to call forwardKinematics(model, data, q); and updateFramePlacements(model, data); all in one call and nothing else, there's framesForwardKinematics(model, data, q); doing it

There is the function computeAllTerms that does everything, except centroidal quantities

Since @junhyeokahn mentioned frames, I will mention that computeAllTerms does not update frame placements either
BTW, of you just want to call forwardKinematics(model, data, q); and updateFramePlacements(model, data); all in one call and nothing else, there's framesForwardKinematics(model, data, q); doing it

Indeed, but it is easy to call updateFramePlacements(model, data) after calling computeAllTerms without additional burden. At this stage, there is no need to add updateFramePlacements in computeAllTerms

Indeed, but it is easy to call updateFramePlacements(model, data) after calling computeAllTerms without additional burden. At this stage, there is no need to add updateFramePlacements in computeAllTerms

Indeed, but it is easy to call updateFramePlacements(model, data) after calling computeAllTerms without additional burden. At this stage, there is no need to add updateFramePlacements in computeAllTerms

There isn't of course, I was just said it so that it would be clear to @junhyeokahn since he explicitly mentioned this

Indeed, but it is easy to call updateFramePlacements(model, data) after calling computeAllTerms without additional burden. At this stage, there is no need to add updateFramePlacements in computeAllTerms

There isn't of course, I was just said it so that it would be clear to @junhyeokahn since he explicitly mentioned this

@jcarpent @gabrielebndn Thanks for the reply.
So, after #1378 incorporated,  I could probably call computeAllTerms and then updateFramePlacements, which will update all quantities.
Then, I might be able to access (correct me if I am wrong)

centroidal quantities from data.hg, data.Ag, data.Ig without explicitly calling ccrba,
com quantities from data.com[0], data.vcom[0] without explicitly calling centerOfMass,
com jacobian from data.Jcom instead of calling jacobianCenterOfMass```,
nonlinear term from data.nle instead of calling nonLinearEffects,
gravity term from data.g instead of calling computeGeneralizedGraivity,
mass matrix from data.M instead of calling crba,
frame placement from data.oMf instead of calling updateFramePlacement.

Follow up question is then,
is there any way I can access the following quantities from data as well

frame velocities in world frame (velocity version of data.oMf),
frame jacobian in world frame (so frame velocities = jacobian * qodt),
frame jacobian time derivative in world frame (so that frame acc = jacobian_dot * qdot + jacobian*qddot),
centroidal map time derivative in world frame (so that its top 3 quantity can represent com jacobian dot * total_robot_mass?

I saw in the robot_wrapper these quantities are achieved from

getFrameVelocity(model, data, frame_id),
getFrameJacobian(model, data, frame_id, pin.ReferenceFrame.LOCAL_WORLD_ALIGNED),
getFrameJacobianTimeVariation(model, data, frame_id, pin.ReferenceFrame.LOCAL_WORLD_ALIGNED),
computeCentroidalMapTimeVariation(model, data, q, qdot),
but just wondering if I could access these quantities from data I as do for the other quantities.

One quick last question is how quickly conda (python bindings) reflects the changes in the master branch?

@jcarpent @gabrielebndn Thanks for the reply.
So, after #1378 incorporated,  I could probably call computeAllTerms and then updateFramePlacements, which will update all quantities.
Then, I might be able to access (correct me if I am wrong)

centroidal quantities from data.hg, data.Ag, data.Ig without explicitly calling ccrba,
com quantities from data.com[0], data.vcom[0] without explicitly calling centerOfMass,
com jacobian from data.Jcom instead of calling jacobianCenterOfMass```,
nonlinear term from data.nle instead of calling nonLinearEffects,
gravity term from data.g instead of calling computeGeneralizedGraivity,
mass matrix from data.M instead of calling crba,
frame placement from data.oMf instead of calling updateFramePlacement.

Follow up question is then,
is there any way I can access the following quantities from data as well

frame velocities in world frame (velocity version of data.oMf),
frame jacobian in world frame (so frame velocities = jacobian * qodt),
frame jacobian time derivative in world frame (so that frame acc = jacobian_dot * qdot + jacobian*qddot),
centroidal map time derivative in world frame (so that its top 3 quantity can represent com jacobian dot * total_robot_mass?

I saw in the robot_wrapper these quantities are achieved from

getFrameVelocity(model, data, frame_id),
getFrameJacobian(model, data, frame_id, pin.ReferenceFrame.LOCAL_WORLD_ALIGNED),
getFrameJacobianTimeVariation(model, data, frame_id, pin.ReferenceFrame.LOCAL_WORLD_ALIGNED),
computeCentroidalMapTimeVariation(model, data, q, qdot),
but just wondering if I could access these quantities from data I as do for the other quantities.

One quick last question is how quickly conda (python bindings) reflects the changes in the master branch?

I saw in the robot_wrapper these quantities are achieved from
* `getFrameVelocity(model, data, frame_id)`,

* `getFrameJacobian(model, data, frame_id, pin.ReferenceFrame.LOCAL_WORLD_ALIGNED)`,

* `getFrameJacobianTimeVariation(model, data, frame_id, pin.ReferenceFrame.LOCAL_WORLD_ALIGNED)`,

* `computeCentroidalMapTimeVariation(model, data, q, qdot)`,
  but just wondering if I could access these quantities from `data` I as do for the other quantities.

Those are exactly the functions you need. Frame velocities, accelerations and Jacobians are not stored anywhere in data but they are computed on the fly (the same is true for joint Jacobians BTW).
The result of computeCentroidalMapTimeVariation is stored is data.dAg (you can check the online doc for that) and it is also computed by dccorba (the two algorithms seem to be equivalent, at least in terms of output)

I saw in the robot_wrapper these quantities are achieved from
* `getFrameVelocity(model, data, frame_id)`,

* `getFrameJacobian(model, data, frame_id, pin.ReferenceFrame.LOCAL_WORLD_ALIGNED)`,

* `getFrameJacobianTimeVariation(model, data, frame_id, pin.ReferenceFrame.LOCAL_WORLD_ALIGNED)`,

* `computeCentroidalMapTimeVariation(model, data, q, qdot)`,
  but just wondering if I could access these quantities from `data` I as do for the other quantities.

Those are exactly the functions you need. Frame velocities, accelerations and Jacobians are not stored anywhere in data but they are computed on the fly (the same is true for joint Jacobians BTW).
The result of computeCentroidalMapTimeVariation is stored is data.dAg (you can check the online doc for that) and it is also computed by dccorba (the two algorithms seem to be equivalent, at least in terms of output)

Then, I might be able to access (correct me if I am wrong)
* centroidal quantities from `data.hg`, `data.Ag`, `data.Ig` without explicitly calling `ccrba`, YES

* com quantities from `data.com[0]`, `data.vcom[0]` without explicitly calling `centerOfMass`, YES

* com jacobian from `data.Jcom` instead of calling jacobianCenterOfMass```, YES

* nonlinear term from `data.nle` instead of calling `nonLinearEffects`, YES

* gravity term from `data.g` instead of calling `computeGeneralizedGraivity`, YES

* mass matrix from `data.M` instead of calling `crba`, YES

* frame placement from `data.oMf` instead of calling `updateFramePlacement`. NO!!!

You should still call updateFramePlacements(model,data) which pretty much easy.

Then, I might be able to access (correct me if I am wrong)
* centroidal quantities from `data.hg`, `data.Ag`, `data.Ig` without explicitly calling `ccrba`, YES

* com quantities from `data.com[0]`, `data.vcom[0]` without explicitly calling `centerOfMass`, YES

* com jacobian from `data.Jcom` instead of calling jacobianCenterOfMass```, YES

* nonlinear term from `data.nle` instead of calling `nonLinearEffects`, YES

* gravity term from `data.g` instead of calling `computeGeneralizedGraivity`, YES

* mass matrix from `data.M` instead of calling `crba`, YES

* frame placement from `data.oMf` instead of calling `updateFramePlacement`. NO!!!

You should still call updateFramePlacements(model,data) which pretty much easy.

The question is why do you need dJ/dt or dAg/dt?

The question is why do you need dJ/dt or dAg/dt?

One quick last question is how quickly conda (python bindings) reflects the changes in the master branch?

For each new release, conda is compiling and making it available to anyone on conda-forge. What is your timeline?
In any cases, it is very easy to install Pinocchio from sources under a conda environment.

One quick last question is how quickly conda (python bindings) reflects the changes in the master branch?

For each new release, conda is compiling and making it available to anyone on conda-forge. What is your timeline?
In any cases, it is very easy to install Pinocchio from sources under a conda environment.

@gabrielebndn @jcarpent Thanks for clarifying all the questions
It resolves all of my questions!

What is your timeline?

I don't have a strict timeline but I was just wondering.
I use dJ/dt to control operational space task in acceleration level (using the equation xddot = dJ/dT * qdot + J * qddot).

@gabrielebndn @jcarpent Thanks for clarifying all the questions
It resolves all of my questions!

What is your timeline?

I don't have a strict timeline but I was just wondering.
I use dJ/dt to control operational space task in acceleration level (using the equation xddot = dJ/dT * qdot + J * qddot).

This is a drift term, so you don't need to compute this term at all. Assuming qddot == 0, you get your quantity for free from forward kinematics.
Just call computeAllTerms, it is all what you need!

This is a drift term, so you don't need to compute this term at all. Assuming qddot == 0, you get your quantity for free from forward kinematics.
Just call computeAllTerms, it is all what you need!

Solved by #1378.

Solved by #1378.


CAPI v1.6.0-beta.0 has been released and is ready for testing

CAPI v1.6.0-beta.0 has been released and is ready for testing.
Looking forward to your feedback before v1.6.0 release!
For quick reference

CAPI v1.6.0-beta.0 release notes
Shortcut to CAPI git issues

Following are the planned dates for the upcoming releases
CAPI v1.6.0 will be released on Tuesday, 28th November 2023.
More details of the upcoming schedule can be seen at CAPI v1.6.0 release timeline.

thanks for the update @willie-yao , we need to get on the ball with 1.5 still XD

i'm working on the 1.6 update now
/remove-lifecycle stale

#102 brings us up to date with 1.6 capi, i would like to plan a release but for now i will close this issue.
/close


panic on nil access on getting statefulset status

When a StatefulSet is unable to initialize an initial deployment because of some reason like resource quota it never gets an observed generation. The check at resourceKinds.go:212 gets a nil dereference.
ts=2018-05-01T01:20:23.152400197Z caller=main.go:422 addr=:3030
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xf85f1a]

goroutine 82 [running]:
github.com/weaveworks/flux/cluster/kubernetes.makeStatefulSetPodController(0xc421549900, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /go/src/github.com/weaveworks/flux/cluster/kubernetes/resourcekinds.go:212 +0xea
github.com/weaveworks/flux/cluster/kubernetes.(*statefulSetKind).getPodControllers(0x1b6fbb0, 0xc420226960, 0xc4201670a0, 0x14, 0x1, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/weaveworks/flux/cluster/kubernetes/resourcekinds.go:203 +0x13d
github.com/weaveworks/flux/cluster/kubernetes.(*Cluster).ImagesToFetch(0xc420226960, 0xc42004e380)
        /go/src/github.com/weaveworks/flux/cluster/kubernetes/kubernetes.go:390 +0x248
github.com/weaveworks/flux/cluster/kubernetes.(*Cluster).ImagesToFetch-fm(0xdf8475800)
        /go/src/github.com/weaveworks/flux/cmd/fluxd/main.go:242 +0x2a
github.com/weaveworks/flux/registry/cache.(*Warmer).Loop(0xc4203a9f00, 0x1ad49e0, 0xc4203fe0c0, 0xc42012ee40, 0xc4203cc590, 0xc4203cc110)
        /go/src/github.com/weaveworks/flux/registry/cache/warming.go:55 +0x89
created by main.main
        /go/src/github.com/weaveworks/flux/cmd/fluxd/main.go:415 +0x423e

The statefulset in question that is crashing flux looks like has a status section like:
    "status": {
      "replicas": 0
    }

It is currently stuck since the user has used all of their current quota.

Thanks for reporting this :star: -- I've merged a fix, which should appear in the next release (as well as the CI builds).


Passing objects & arrays to Components

There should be a way to pass data (that is more complex than a string, boolean, or number) to tinybind's implementation of Custom Elements.
In rivets.js, components had an initialize function where you could pass bound data this way:
initialize: (data) => { return new Controller(data.blah, data.bleh); }
Maybe the Component object could implement a constructor with a data parameter (that references the data bound via keypaths on the page) so that these objects referenced by keypath can be used within the Component itself? Maybe a method could also be implemented for when that data changes or is updated?
<custom-element rv-keypath-banana="boundObject.banana"></custom-element>
class CustomElement extends tinybind.Component {
constructor(data) {
this.banana = data.banana;

...
etc
...
}

Or maybe, there's already a way to do these things, and I'm crazy?

i just tested it...... works like this.......
constructor() {
super();
var self = this;
self.moo =function (a ,b, c){
alert(a + b + c);
};
self.model = {
name: "Base",
push(event, data) {
alert(data.item.name);
===== model is for tinybinding=====
alert(appid.model.name); Javascript call
==== now will run a moo function =====
appid.moo("moo", " moo" ," moo");
no errors...... its not in tinybind model
now add your moo  data to self.model  for tinybind
push(event, data) {
self.moo(data.item.1, data.item.2, data.item.3)
"moo", " moo" ," moo"
should work.... your in the class

Hi,
Please look at jskick https://github.com/RADKick/jskick as well, not ready for full scale components yet but has some extra functionality and would love someone help me on components, specifically have issue with nested components like tree view as component constructor calls itself late before observers are ready.

it takes time to review .......
Added font size style
not good css offers binding services that work in tangent with DOM tree at the C level
css variable loaded into C
root:{
---myfontSize: 12px;
---myfontColor: red;
}
 fontsize: var(---myfontSize);
Javascipt  vs C code
css is allot memory <-fast injected to C engine
dom is allotted memory <-fast array elements injected to C engine
JavaScript is allotted memory for its engine a text interpreter <-slow
dom runs css first its in charge then JavaScript
css runs dom binding first.

Please look at jskick https://github.com/RADKick/jskick

Nice work
Please note that https://github.com/RADKick/jskick#differences-from-rivetsjs--tinybindjs section mislead because those are the difference from tinybind to rivets and not from tinybind to jskick

passing array data test ........
1000x30 = 30,000 items on 2gig ram
your way takes time:9098  and the component is + 1000
my way took time:73 ..lol
i strip out the component to cut the down the code......
and on 100,000x30 = 300.000
my time:5098   and you got busted in wait time dialog s
i created shadow dom component
i call gettable[1000] from the tinbind tempate as an embedded function
to run 2 way bindings.... as you can see its supper fast..
way way way faster then knockout.....

Thank you 😊.  Sure will update the readme.
On Jun 12, 2020, at 9:33 AM, Luiz Américo<EMAIL_ADDRESS>wrote:

Please look at jskick https://github.com/RADKick/jskick
Nice work
Please note that https://github.com/RADKick/jskick#differences-from-rivetsjs--tinybindjs section mislead because those are the difference from tinybind to rivets and not from tinybind to jskick
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/blikblum/tinybind/issues/25#issuecomment-643273054, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIMS635BD3LVDGN5EB7PQHTRWIVDZANCNFSM4KXJMJTA.

i tested  out loading 30,000 items at a time to tinybind
it ran out memory at 277999 x 30
8.339.970   lol  8 million   items
time was 5 to 77 super fast binding on each 30,000 entry that tinybind could bind to in a flash on any item on 2gig ram
i run a push button to inject 30,000 and and view the last entry at time 6....
milliseconds   6

Thank you . Sure will update the readme. On Jun 12, 2020, at 9:33 AM, Luiz Américo<EMAIL_ADDRESS>wrote:  Please look at jskick https://github.com/RADKick/jskick Nice work Please note that https://github.com/RADKick/jskick#differences-from-rivetsjs--tinybindjs section mislead because those are the difference from tinybind to rivets and not from tinybind to jskick — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#25 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIMS635BD3LVDGN5EB7PQHTRWIVDZANCNFSM4KXJMJTA.

i did check it out your code .. you use regex  and will cause problems with memory leaks...... your accessing a C object lib  to mix with JavaScript .... tinybind did not.....
i like readable code  and shrink it down too far offers nothing in speed but debugging problems  when scanning for syntax  errors on templates

new test.... master slave components at 100,000 records......
it feeds the last entry from a tinybind function to a clone....
time 6 milliseconds

new test....... this one is about 2 way binding and loading a template to the clone
on 155,000 records

new test.... will monitor the memory  and at about 90% memory the app will start to have problems
2gig ram  is the best way to test and build code with it fores you to think out side the box
with a nice 8gig  your code may not work with 2gig or less....
100,000 rec at 3milion items and we still have lots of memory left......

@RADKick  would love to see how we can re-incorporate some of your ideas back into tinybind. Can you create some use cases for review and a possible fork of tinybind with test cases for review via pull request?

Sure @karneaud  we can

And everyone just look at https://github.com/RADKick/jskick what @karneaud is referring to. I will love to see if anyone is interested to take this idea to next level for database less website like https://github.com/RADKick/serverlesssite and also if we can extend the kickjs ( or tinybind) to low code platform where we can build drag drop interface for complex screens.

Hi changed some of tinybind
I took out the template code and the text scan found it to be a breach where one could type text and have it replace with model variable..
I also fix the sort array stack calls...
I also remove the TEMPLATE class because i use shadow dom tag element registry to build objects. Its just better because you can load them as TAG and create them on demand better.
new-tag id= 'newtage'
newtage.nodel.runfunction();
I check your your version out but found the syntax unreadable or hard to keep in memory the space saved is not worth the time....
YES i'm able in code to load transfer model data correctly
Your best to drop me an email<EMAIL_ADDRESS>


QT 3.3.1 Stuck at 85%

I upgraded my wallet to version 3.3.1 last week. It synced to 85% and now is stuck. I have tried with/without anti-virus on and have checked to ensure that the firewall is open for the app. Can you address this bug?

@jaybeezy first I've heard of it. Could be peers related to be entirely honest; if you look at getpeerinfo (via the debug console) you can see the height of the connected peers, if some of them aren't synced that could be an issue otherwise I'm not sure off the top of my head. I'll try to sync a node for a test though.

I am curious though; if this is an "upgrade" why are you resynching it (there was no reason to wipe your chain data it should have simply kept working with the new wallet)?

@jaybeezy I left a node running over not it synced fully from 0 blocks. I expect your issue as I mentioned before is more related to your connected peers than the wallet itself.

@IngCr3at1on  - You are correct, it was a peer issue. I reset the application and it finally synced after 48 hours. Issue is now resolved!


add additional systemd_unit actions

Description
MOAR ACTIONS FOR THE ACTION GOD
adds support for additional systemd_unit actions supported by systemctl:

preset: restore enable/disable status based on preset files
revert: remove any non-vendor overrides (drop-ins, same-name user-provided units, etc)
reenable: disable then enable (alias regenerator)

Issues Resolved
https://github.com/chef/chef/issues/6823
Check List

[x] New functionality includes tests
[x] All tests pass
[x] RELEASE_NOTES.md, has been updated if required (not required for bugfixes, required for API changes)
[x] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco

Thanks @nathwill !


Fixed compile error: ‘uint64_t’ does not name a type

In Manjaro distro, building from source requires this change, it wouldn't compile otherwise.

I'm fine with merging either PR; I wouldn't think this one requires additional changes


Added react-hot-loader

This doesn't actually do anything, there's no accepting a hot reload so what happens is just a page refresh. However, integrating react-hot-loader properly doesn't work either anyway. Most updates will give an error in the console like this:
React-hot-loader: reconciliation failed could not dive into [ Hello world! ] while some elements are still present in the tree.

Updates are still happening though, however I am not sure what is happening with those messages.
Updating the <GlobalStyle /> object does not work: See proper implementation (from what I could gather from the docs) here: https://github.com/Dinoshauer/react-styled-components-hmr/tree/react-hot-loader