Library module images not rendering

Problem Description
I have created a module which uses images which works as expected when the module is created on the intended website. If I create a module on one website (local server), save it as a library item, export and import to a different website (live), the image doesn't render because it is still pointing at the original source (local server). The media library doesn't get updated like it does with the ET image module. Any advice would be gratefully received or a point in the right direction to any documentation.
Thank you.

Looks like a bug in the export from the library. A possible workaround would be: add the module on an new empty page, export the page layout, import the page layout on the live site, save the module to the library and delete the site.

Thanks Jan, I’ve tried various methods of exporting and importing modules and page layouts including this idea. Unfortunately, the original image url remains unchanged and the image doesn’t get imported into the Wordpress media library like it does with the ET image module.
Also thanks for replying to issue #235. I found an acceptable solution for this.
Simon

On 4 Mar 2019, at 18:04, Jan Thielemann<EMAIL_ADDRESS>wrote:
Looks like a bug in the export from the library. A possible workaround would be: add the module on an new empty page, export the page layout, import the page layout on the live site, save the module to the library and delete the site.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/elegantthemes/create-divi-extension/issues/238#issuecomment-469354059, or mute the thread https://github.com/notifications/unsubscribe-auth/Apwy3jiijR243XRD1pRvimlBZA0dgpiBks5vTWArgaJpZM4baiRd.

Can you post your field config?

Couldn't post the whole config but the part that relates to the image is here (unsure if that's what you need)
//Image Upload
'dwic_image_upload' => array(
'type'               => 'upload',
'option_category'    => 'basic_option',
'upload_button_text' => esc_attr__( 'Upload an image', 'dwci_image_clip' ),
'choose_text'        => esc_attr__( 'Choose an Image', 'dwci_image_clip' ),
'update_text'        => esc_attr__( 'Set As Image', 'dwci_image_clip' ),
'hide_metadata'      => false,
'affects'            => array(
'dwic_alt',
'dwic_title_text',
'dwic_clipping_shapes',
'dwic_image_opacity',
'dwic_image_horizontal',
'dwic_image_vertical'
),
'description'        => esc_html__( 'Upload your desired image, or type in the URL to the image you would like to display.', 'dwci_image_clip' ),
//'toggle_slug'        => 'image',
'option_category' => 'basic_option',
'toggle_slug'     => 'settings',
'sub_toggle'      => 'image',
),

Hmm only difference to my image fields is the hide_metadata which I don't really think is necessary but thats surely only personal preference.
Strangely though for me both cases work. Exporting a layout via the library works just as well as via a page.
Besides that, you should move forward from the old affects functionality to the new show_if functionality.
Oh an you defined option_category twice which will have no effect but it looks odd :P

Is there probably a mismatch between Divi versions on those systems? Can you check the exported layout if it contains the encoded image in the json. Something like: my-image.jpg":{"encoded":"/9j/7gAOQW...

Both sites running version 3.19.15
Nothing in the json file which states 'encoded'
When you export and import a non-ET image module, does it update the Wordpress media library?

Yep

Okay, thanks for looking at it for me Jan. It's obviously something I've done wrong somewhere if you're able to get it to work without adding anything special. I'll try to unpick it!
Thanks again.

Just send me the module (preferably without the nodes_module folder) via mail and I'll have a look

Hehe I found out whats the issue is. I also found a lot of familiar code in your plugin. Please make sure to remove it so your plugin doesn't cause side effects to mine. You can simply search for "dss_" ;)
So the issue here is that apparently Divi only exports images from upload fields if the name of the field ends with image. All you need to do is remove the "_upload" and make sure the field is named "something_image" and you should be good to go.

Thanks Jan. I'll try it tomorrow when I've got a bit more time. Hopefully, that will solve it. Yeah, learnt a fair bit from just looking through your code even though much of it is still above me. I'll strip it all out before release.  I'm sure there will be a lot in there that will help me out. Any chance of a good discount ? :-)
Thank you so much for your time.

Ahh too bad. :) I have so many ideas for little free modules and only so
much time. I can offer you a 50% discount though:
https://www.udemy.com/divi-dojo/learn/v4/?couponCode=SIMON50
Am Mo., 4. März 2019 um 22:08 Uhr schrieb snewsh<EMAIL_ADDRESS>
Thanks Jan. I'll try it tomorrow when I've got a bit more time. Hopefully,
that will solve it. Yeah, learnt a fair bit from just looking through your
code even though much of it is still above me. I'll strip it all out before
release.  I'm
sure there will be a lot in there that will help me out. Any chance of a
good discount ? :-)
Thank you so much for your time.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/elegantthemes/create-divi-extension/issues/238#issuecomment-469422298,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC3J6CwPjEgYM3llyD4_oghXNAn1uFVlks5vTYtRgaJpZM4baiRd
.


Fixing bootstap for RHEL/Centos 8

Fixing bootstap for RHEL/Centos 8

When VERSION_ID is less than 8, installing the python packages, otherwise installing the python2 packages.
When we are using the python2-virtualenv, we will run virtualenv-2.
Making sure we have which installed

Fixes #318

@alimaredia Please review.


Cannot build with GCC6

Noticed this problem on Arch Linux after a recent update. luarocks install gives a giant log of errors that look like:

nvidia's nvcc does not support anything more than gcc 4.9 (yet).

Ah ok, my mistake!


There is a small pause added in between tracks

Describe the bug
There is a small pause added in between tracks. It is hearable on albums that have songs that flow from one song to the other with no  silence. These pauses are not present in the official app.
To Reproduce
Steps to reproduce the behaviour:

Go to any album that has songs that flows from one to the next with no pause.
Start the first song in the High Hell Soundtrack album and skip toward the last 10 seconds of the song.
Wait until the song end and the next one starts, and you will notice an unnecessary pause. If you do the same in your web browser or the official app, you will notice the next song was supposed to immediately start playing.

Expected behaviour
For the annoying pauses to not be present and for the next track to start playing immediately like on the official app so that I can enjoy my music the way the artist intended.
General information:

Distribution: Fedora 35
Installation method: Flathub
Version: 0.3.1
Device used: Laptop

Stack trace:
The only thing here was the same unrelated GTK warning that showed up over and over again.
(spot:2): Gtk-WARNING **: 16:19:13.332: GtkGizmo 0x55e775aadc00 (highlight) reported min width -2, but sizes must be >= 0

Duplicate of https://github.com/xou816/spot/issues/193

fixed by #532  possibly :) feel free to reopen if needed


On Sugestion List put the table columns on first options

SQL Operations Studio Version:
Version 0.28.4-insider
Commit 3d6fb7a8fa8e941306109f69bc094e307b9ff8c2
Date 2018-04-23T05:43:47.587Z
Shell 1.7.11
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64
Steps to Reproduce:

When open the sugestion list (CTRL+SPACE), on a SELECT/UPDATE/Etc. put the table columns on the first options.

We depend on VS Code editor for our intellisense implementation.  Currently they only support providing completions alphabetically.  This would be a great candidate to fix upstream.

+1
No news ? An extension can do this ?


cherry-pick clarin v7 into dtq dev

cherry-pick recent changes from clarin-v7

update related to datacite
filedownloader script
expose resource_id in the handle api
findEpersonByNetid fix

@milanmajchrak  what is filedownloader used for?

@milanmajchrak what is filedownloader used for?

It is for downloading a file from a specific URL and assigning it to a Item. It is done by CLI.


File changes not reflected

Issue Type: Bug
When files are added to VS Code project from other resources its not reflecting in VS Code editor. I have tried increasing the watches as per the microsoft documentation. still getting error like unbale to watch for file changes.
VS Code version: Code 1.31.0 (7c66f58312b48ed8ca4e387ebd9ffe9605332caa, 2019-02-06T08:51:24.856Z)
OS version: Linux x64 4.15.0-46-generic

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz (4 x 1769)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: disabled_softwaresurface_synchronization: enabled_onvideo_decode: unavailable_offwebgl: enabledwebgl2: enabled

Load (avg)
0, 0, 0

Memory (System)
7.67GB (1.67GB free)

Process Argv
--unity-launch

Screen Reader
no

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

vscode-eclipse-keybindings
alp
0.10.0

vscode-icons
rob
8.2.0

Please describe the issue with exact steps. Also please try updating to 1.32.


Errors thrown importing requirements.txt

Attempting to create a new pipenv context for an existing project fails. Seems the syntax in requirements.txt is not fully handled by pipenv.
FYI (note this is MacOS with Python installed via brew):
$ python -m pipenv.help
<EMAIL_ADDRESS>No module named pipenv
$ which python
/usr/local/bin/python

Expected result
Either ingest the requirements.txt file, or report the file cannot be handled (in concise/clear form).
Actual result
Stack trace of thrown error(s). Fails to import requirements.txt.
Steps to replicate
git clone https://github.com/kliment/Printrun.git
cd Printrun
pipenv --two

This throws a rather noisy error:
$ pipenv --two
Virtualenv already exists!
Removing existing virtualenv…
Creating a virtualenv for this project…
Using /usr/local/bin/python2 (2.7.14) to create virtualenv…
⠋Running virtualenv with interpreter /usr/local/bin/python2
New python executable in /Users/preston/.local/share/virtualenvs/Printrun-uVIhZWEA/bin/python2.7
Also creating executable in /Users/preston/.local/share/virtualenvs/Printrun-uVIhZWEA/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/preston/.local/share/virtualenvs/Printrun-uVIhZWEA
requirements.txt found, instead of Pipfile! Converting…
Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", line 92, in __init__
    req = REQUIREMENT.parseString(requirement_string)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1617, in parseString
    raise exc
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1607, in parseString
    loc, tokens = self._parse( instring, 0 )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1379, in _parseNoCache
    loc,tokens = self.parseImpl( instring, preloc, doActions )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 3376, in parseImpl
    loc, exprtokens = e._parse( instring, loc, doActions )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1383, in _parseNoCache
    loc,tokens = self.parseImpl( instring, preloc, doActions )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 3164, in parseImpl
    raise ParseException(instring, loc, self.errmsg, self)
pip9._vendor.pyparsing.ParseException: Expected stringEnd (at char 9), (line:1, col:10)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", line 82, in __init__
    req = Requirement(req)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", line 96, in __init__
    requirement_string[e.loc:e.loc + 8]))
pip9._vendor.packaging.requirements.InvalidRequirement: Invalid requirement, parse error at "'(>= 2.8,'"

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/bin/pipenv", line 11, in <module>
    load_entry_point('pipenv==11.8.3', 'console_scripts', 'pipenv')()
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 1043, in invoke
    return Command.invoke(self, ctx)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/cli.py", line 235, in cli
    three=three, python=python, warn=True, site_packages=site_packages
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/core.py", line 635, in ensure_project
    ensure_pipfile(validate=validate, skip_requirements=skip_requirements)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/core.py", line 268, in ensure_pipfile
    import_requirements()
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/core.py", line 204, in import_requirements
    reqs = [f for f in parse_requirements(r, session=pip9._vendor.requests)]
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/core.py", line 204, in <listcomp>
    reqs = [f for f in parse_requirements(r, session=pip9._vendor.requests)]
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", line 93, in parse_requirements
    for req in req_iter:
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_file.py", line 158, in process_line
    isolated=isolated, options=req_options, wheel_cache=wheel_cache
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", line 235, in from_line
    wheel_cache=wheel_cache, constraint=constraint)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", line 91, in __init__
    "Invalid requirement: '%s'\n%s" % (req, add_msg))
pip9.exceptions.InstallationError: Invalid requirement: 'wxPython (>= 2.8, << 4.0)'
Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", line 92, in __init__
    req = REQUIREMENT.parseString(requirement_string)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1617, in parseString
    raise exc
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1607, in parseString
    loc, tokens = self._parse( instring, 0 )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1379, in _parseNoCache
    loc,tokens = self.parseImpl( instring, preloc, doActions )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 3376, in parseImpl
    loc, exprtokens = e._parse( instring, loc, doActions )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1383, in _parseNoCache
    loc,tokens = self.parseImpl( instring, preloc, doActions )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 3164, in parseImpl
    raise ParseException(instring, loc, self.errmsg, self)
pip9._vendor.pyparsing.ParseException: Expected stringEnd (at char 9), (line:1, col:10)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", line 82, in __init__
    req = Requirement(req)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", line 96, in __init__
    requirement_string[e.loc:e.loc + 8]))
pip9._vendor.packaging.requirements.InvalidRequirement: Invalid requirement, parse error at "'(>= 2.8,'"

You might want the requirements.txt
python (>= 2.7, << 3)
pyreadline
pyserial (>= 2.6)
wxPython (>= 2.8, << 4.0)
numpy (>= 1.8.2)
pyglet (>= 1.1)
pycairo (>= 1.8.8)
cairosvg (>= 1.0.9, << 2)
psutil (>= 2.1)
dbus-python (>= 1.2.0)
pygobject (>= 3.14.0)
libxml2 (>= 2.9.1)
appdirs (>= 1.4.0)

The created Pipfile is not very interesting:
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"

[packages]

[dev-packages]

[requires]
python_version = "2.7"

Just for grins, tried importing requirements.txt again:
$ pipenv shell
Spawning environment shell (/bin/bash). Use 'exit' to leave.
bash-3.2$ . /Users/preston/.local/share/virtualenvs/Printrun-uVIhZWEA/bin/activate

(Printrun-uVIhZWEA) bash-3.2$ pipenv install -r requirements.txt
Requirements file provided! Importing into Pipfile…
Unexpected syntax in /Users/preston/sources/Printrun/requirements.txt. Are you sure this is a requirements.txt style file?
Invalid requirement: 'wxPython (>= 2.8, << 4.0)'
Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", line 92, in __init__
    req = REQUIREMENT.parseString(requirement_string)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1617, in parseString
    raise exc
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1607, in parseString
    loc, tokens = self._parse( instring, 0 )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1379, in _parseNoCache
    loc,tokens = self.parseImpl( instring, preloc, doActions )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 3376, in parseImpl
    loc, exprtokens = e._parse( instring, loc, doActions )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 1383, in _parseNoCache
    loc,tokens = self.parseImpl( instring, preloc, doActions )
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/pyparsing.py", line 3164, in parseImpl
    raise ParseException(instring, loc, self.errmsg, self)
pip9._vendor.pyparsing.ParseException: Expected stringEnd (at char 9), (line:1, col:10)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/req/req_install.py", line 82, in __init__
    req = Requirement(req)
  File "/usr/local/Cellar/pipenv/11.8.3/libexec/lib/python3.6/site-packages/pipenv/vendor/pip9/_vendor/packaging/requirements.py", line 96, in __init__
    requirement_string[e.loc:e.loc + 8]))
pip9._vendor.packaging.requirements.InvalidRequirement: Invalid requirement, parse error at "'(>= 2.8,'"

Seems the requirements.txt file has syntax not (yet?) handled by pipenv.

This is not a valid requirements.txt. You should create one with pip freeze, not pip list.

See https://pip.pypa.io/en/stable/reference/pip_install/#requirements-file-format

@hinnerk Your error is completely different from this one, and is covered by #1791.


Term enrichment through AmiGO errors out on too much input (500 for overloading forward)

Due to the changes necessary to forward to PANTHER in #171, very large inputs can cause the header to be incomplete when forwarding, causing a 500 error.
 Error message:
malformed header from script. Bad header=0ADDB_G0291952%0ADDB_G0272781%: rte

This particular issue will be considered fixed with either:

a catch of the error, an explanation, and an offer to send the user to PANTHER
a count of the input on the AmiGO side with an arbitrary and reported limit

It should be noted that there is no way around this issue completely until we no longer forward--forwards cannot contain POSTy data, and large GETs can get truncated, sometimes destroying the header (as in this case).
We got this from: http://jira.geneontology.org/browse/GO-841

@cmungall Another question to answer is which is worse: the lack of interface offered by #171 or this issue? I'm beginning to think that reverting with a better explanation may be preferable to the current state.

Okay, taking a more serious look at this again, I now remember the trade-offs that were made to get here. IIRC, forwards were chosen to preserve the bulk of the RTE/TERP mechanism in AmiGO, without realizing the typical size profile of users.
If we abandon all of the previous mechanism, we can probably do cross posting fine (if I remeber about the PANTHER API correctly--will check on that next).

Just wondering if there are any updates on this please? We keep getting GO helpdesk queries about that error :-}
Thanks.

Unfortunately, there has been very little development time to be given to AmiGO recently. All things being equal, "fixing" #171 was probably a bad idea.

It would be great to add a hyperlink towards the FAQ so users running into the issue may not have to email the helpdesk and wait for answers, see #223

I believe I have a possible fix in for the main irritants here. If somebody else can confirm that this works, I'll ping production to get it out:
http://nakama.berkeleybop.org (2.2.x)
http://tomodachi.berkeleybop.org (2.3.x)

I tried with the list we received yesterday at http://jira.geneontology.org/browse/GO-921 (list is in body of text) and it seems to work (I tried both servers). Pinging @paolaroncaglia in case she has other lists from users in her inbox for additional test.

Excellent--if it works out, we'll cut a quick release before the meeting.

I tried a list of ~650 genes (from an old paper of mine, http://www.ncbi.nlm.nih.gov/pubmed/19887551) on both servers and it worked fine. More relevantly, I tried the expanded list of ~2000 genes from the same study (i.e. without fold-change cut-off) and it also worked, on the nakama server though. The tomodachi server resulted in an empty result page, showing that all submitted IDs are unmapped. But I tried a second time and it worked.
Super!!
Thanks,
Paola

Sounds like a winner then. Thank you for testing.


compiler.version not set for conan package with MSVC

Xmake Version
2.9.5
Operating System Version and Architecture
Windows 11
Describe Bug
The conan profile is not setting compiler.version in xmake 2.9.5 for MSVC 2022. I'm running Conan 2.7.1, and vcvars.bat has been called so MSVC is in the PATH.
Trying the example from the docs:
add_requires("conan::zlib/1.2.11", {alias = "zlib"})

Results in:
zlib/1.2.11: Invalid: 'settings.compiler.version' value not defined

Explicitly specifying compiler.version works:
add_requires("conan::zlib/1.2.11", {
    alias = "zlib",
    configs = {
        settings = {
            "compiler.version=194"
        }
    }
})

Expected Behavior
XMake should be setting compiler.version.
Project Configuration
add_requires("conan::zlib/1.2.11", {alias = "zlib"})

target("deps", function ()
    set_kind("phony")
    add_packages("zlib")
end)

Additional Information and Error Logs
Failure output (directly from the docs):
======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=static
compiler.runtime_type=Release
os=Windows

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=static
compiler.runtime_type=Release
os=Windows

======== Computing dependency graph ========
zlib/1.2.11: Not found in local cache, looking in remotes...
zlib/1.2.11: Checking remote: conancenter
zlib/1.2.11: Downloaded recipe revision fca992a7d96a1b92bd956caa8a97d18f
Graph root
    conanfile.txt: D:\dev\build-sys-eval\foobar\src\build\.conan\zlib\1.2.11\conanfile.txt
Requirements
    zlib/1.2.11#fca992a7d96a1b92bd956caa8a97d18f - Downloaded (conancenter)

======== Computing necessary packages ========
Requirements
    zlib/1.2.11#fca992a7d96a1b92bd956caa8a97d18f:9477f26cffb0bf802e63e917b7e915e0dae68b91 - Invalid
ERROR: There are invalid packages:
zlib/1.2.11: Invalid: 'settings.compiler.version' value not defined
error: execv(conan install . -g XmakeGenerator --profile:build=profile_build.txt --profile:host=profile_host.txt --build=missing) failed(6)
  => install conan::zlib/1.2.11 latest .. failed
error: install failed!

Successful output (manually specifying compiler.version):
======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=static
compiler.runtime_type=Release
compiler.version=194
os=Windows

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=static
compiler.runtime_type=Release
os=Windows

======== Computing dependency graph ========
Graph root
    conanfile.txt: D:\dev\build-sys-eval\foobar\src\build\.conan\zlib\1.2.11\conanfile.txt
Requirements
    zlib/1.2.11#fca992a7d96a1b92bd956caa8a97d18f - Cache

======== Computing necessary packages ========
zlib/1.2.11: Main binary package '805d40acaa2400bcd79bfb1b96f313f2713000a5' missing
zlib/1.2.11: Checking 1 compatible configurations
zlib/1.2.11: Compatible configurations not found in cache, checking servers
zlib/1.2.11: '04a6c37bc15f9f5fab59d7085ff6c17c75bc552d': compiler.version=193
Requirements
    zlib/1.2.11#fca992a7d96a1b92bd956caa8a97d18f:805d40acaa2400bcd79bfb1b96f313f2713000a5 - Build

you can debug here https://github.com/xmake-io/xmake/blob/583f8e6944130e157ec85b8a975a76733b3eb775/xmake/modules/package/manager/conan/v2/install_package.lua#L184-L187
then open a pr to fix it.

Thanks for the reply. I'll try and take a look, but I am unfamiliar with both lua and xmake - I'm just starting to evaluate it for a new project (which is why I'm going through the docs trying things out).

and please use add_requires("zlib") as much as possible.

It works for me.
compiler.runtime=static
compiler.runtime_type=Release
compiler.version=194
os=Windows

PS C:\Users\wangrunqing\Downloads\test91> xmake f -cvD
checking for platform ... windows
checking for architecture ... x64
checking for cl.exe ... C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.41.33923\bin\HostX64\x64\cl.exe
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.41.33923
checkinfo: cannot runv(zig.exe version), No such file or directory
checking for zig ... no
checkinfo: cannot runv(zig.exe version), No such file or directory
checking for zig ... no
checkinfo: cannot runv(nim.exe --version), No such file or directory
checking for nim ... no
checkinfo: cannot runv(nim.exe --version), No such file or directory
checking for nim ... no
checking for git ... ok
checkinfo: cannot runv(gzip.exe --version), No such file or directory
checking for gzip ... no
checking for 7z ... D:\projects\personal\xmake\xmake\winenv\bin\7z
finding zlib/1.2.11 from conan ..
checking for conan::zlib/1.2.11 ... no
note: install or modify (m) these packages (pass -y to skip confirm)?
in conan:
  -> conan::zlib/1.2.11 latest [runtimes:"MT"]
please input: y (y/n/m)

installing zlib/1.2.11 from conan ..
checking for conan ... ok
conan config install D:\projects\personal\xmake\xmake\scripts\conan
Copying file xmake_generator.py to C:\Users\wangrunqing\.conan2\extensions\generators
generate C:\Users\wangrunqing\Downloads\test91\build\.conan\zlib\1.2.11\conanfile.txt ..
conan install . -g XmakeGenerator --profile:build=profile_build.txt --profile:host=profile_host.txt --build=missing

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=static
compiler.runtime_type=Release
compiler.version=194
os=Windows

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.cppstd=14
compiler.runtime=static
compiler.runtime_type=Release
compiler.version=194
os=Windows

======== Computing dependency graph ========
Graph root
    conanfile.txt: C:\Users\wangrunqing\Downloads\test91\build\.conan\zlib\1.2.11\conanfile.txt
Requirements
    zlib/1.2.11#fca992a7d96a1b92bd956caa8a97d18f - Cache

======== Computing necessary packages ========
zlib/1.2.11: Checking 1 compatible configurations
zlib/1.2.11: Compatible configurations not found in cache, checking servers
zlib/1.2.11: '04a6c37bc15f9f5fab59d7085ff6c17c75bc552d': compiler.version=193
Requirements
    zlib/1.2.11#fca992a7d96a1b92bd956caa8a97d18f:805d40acaa2400bcd79bfb1b96f313f2713000a5 - Build

======== Installing packages ========

-------- Installing package zlib/1.2.11 (1 of 1) --------
zlib/1.2.11: Building from source
zlib/1.2.11: Package zlib/1.2.11:805d40acaa2400bcd79bfb1b96f313f2713000a5
zlib/1.2.11: Copying sources to build folder
zlib/1.2.11: Building your package in C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b
zlib/1.2.11: Calling generate()
zlib/1.2.11: Generators folder: C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\build\generators
zlib/1.2.11: CMakeToolchain generated: conan_toolchain.cmake
zlib/1.2.11: CMakeToolchain generated: C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\build\generators\CMakePresets.json
zlib/1.2.11: CMakeToolchain generated: C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\src\CMakeUserPresets.json
zlib/1.2.11: Generating aggregated env files
zlib/1.2.11: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
zlib/1.2.11: Calling build()
zlib/1.2.11: Apply patch (conan): separate static/shared builds, disable debug suffix, disable building examples
zlib/1.2.11: Apply patch (portability): fix condition for WIDECHAR usage
zlib/1.2.11: Running CMake.configure()
zlib/1.2.11: RUN: cmake -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE="generators/conan_toolchain.cmake" -DCMAKE_INSTALL_PREFIX="C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" "C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/b/src"
CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

-- Using Conan toolchain: C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/b/build/generators/conan_toolchain.cmake
-- Conan toolchain: CMAKE_GENERATOR_TOOLSET=v143
-- Conan toolchain: Setting CMAKE_MSVC_RUNTIME_LIBRARY=$<$<CONFIG:Release>:MultiThreaded>
-- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19044.
-- The C compiler identification is MSVC 19.41.33923.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Preview/VC/Tools/MSVC/14.41.33923/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of off64_t
-- Check size of off64_t - failed
-- Looking for fseeko
-- Looking for fseeko - not found
-- Looking for unistd.h
-- Looking for unistd.h - not found
-- Renaming
--     C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/b/src/zconf.h
-- to 'zconf.h.included' because this file is included with zlib
-- but CMake generates it automatically in the build directory.
-- Configuring done (16.3s)
-- Generating done (0.1s)
-- Build files have been written to: C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/b/build

zlib/1.2.11: Running CMake.build()
zlib/1.2.11: RUN: cmake --build "C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\build" --config Release
适用于 .NET Framework MSBuild 版本 17.11.0-preview-24279-02+b963c24ef

  1>Checking Build System
  Building Custom Rule C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/b/src/CMakeLists.txt
  adler32.c
  compress.c
  crc32.c
  deflate.c
  gzclose.c
  gzlib.c
  gzread.c
  gzwrite.c
C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\src\gzread.c(319,17): warning C4267: “=”: 从“size_t”转换到“unsigned int”，可能丢失数据 [C:\Users\wangrunqing\.con
an2\p\b\zlibe89ffb4a04318\b\build\zlib.vcxproj]
  inflate.c
  infback.c
C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\src\gzread.c(400,11): warning C4267: “=”: 从“size_t”转换到“unsigned int”，可能丢失数据 [C:\Users\wangrunqing\.con
an2\p\b\zlibe89ffb4a04318\b\build\zlib.vcxproj]
  inftrees.c
  inffast.c
  trees.c
  uncompr.c
  zutil.c
C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\src\gzread.c(472,11): warning C4267: “=”: 从“size_t”转换到“int”，可能丢失数据 [C:\Users\wangrunqing\.conan2\p\b\z
libe89ffb4a04318\b\build\zlib.vcxproj]
C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\src\gzwrite.c(212,24): warning C4267: “=”: 从“size_t”转换到“unsigned int”，可能丢失数据 [C:\Users\wangrunqing\.co
nan2\p\b\zlibe89ffb4a04318\b\build\zlib.vcxproj]
C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\src\gzwrite.c(232,21): warning C4267: “=”: 从“size_t”转换到“unsigned int”，可能丢失数据 [C:\Users\wangrunqing\.co
nan2\p\b\zlibe89ffb4a04318\b\build\zlib.vcxproj]
C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\src\gzwrite.c(371,11): warning C4267: “=”: 从“size_t”转换到“int”，可能丢失数据 [C:\Users\wangrunqing\.conan2\p\b\
zlibe89ffb4a04318\b\build\zlib.vcxproj]
  zlib.vcxproj -> C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\build\Release\zlib.lib
  Building Custom Rule C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/b/src/CMakeLists.txt

zlib/1.2.11: Package '805d40acaa2400bcd79bfb1b96f313f2713000a5' built
zlib/1.2.11: Build folder C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\build
zlib/1.2.11: Generating the package
zlib/1.2.11: Packaging in folder C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\p
zlib/1.2.11: Calling package()
zlib/1.2.11: Running CMake.install()
zlib/1.2.11: RUN: cmake --install "C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\b\build" --config Release --prefix "C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p"
-- Installing: C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/lib/zlib.lib
-- Installing: C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/include/zconf.h
-- Installing: C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/include/zlib.h

zlib/1.2.11: package(): Packaged 2 '.h' files: zconf.h, zlib.h
zlib/1.2.11: package(): Packaged 1 '.lib' file: zlib.lib
zlib/1.2.11: package(): Packaged 1 file: LICENSE
zlib/1.2.11: Created package revision f639919251869e1d221cb98443860ba8
zlib/1.2.11: Package '805d40acaa2400bcd79bfb1b96f313f2713000a5' created
zlib/1.2.11: Full package reference: zlib/1.2.11#fca992a7d96a1b92bd956caa8a97d18f:805d40acaa2400bcd79bfb1b96f313f2713000a5#f639919251869e1d221cb98443860ba8
zlib/1.2.11: Package folder C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\p
WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated:     'cpp_info.names' used in: zlib/1.2.11

======== Finalizing install (deploy, generators) ========
conanfile.txt: Writing generators to C:\Users\wangrunqing\Downloads\test91\build\.conan\zlib\1.2.11
conanfile.txt: Generator 'XmakeGenerator' calling 'generate()'
XmakeGenerator: generating build info ..
zlib {
  Windows_x86_64_Release =
  {
    includedirs    = {"C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/include"},
    linkdirs       = {"C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/lib"},
    links          = {"zlib"},
    frameworkdirs  = {},
    frameworks     = {},
    syslinks       = {},
    defines        = {},
    cxxflags       = {},
    cflags         = {},
    shflags        = {},
    ldflags        = {},
    __bindirs      = {"C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/bin"},
    __resdirs      = {},
    __srcdirs      = {}
  }
}
{
  Windows_x86_64_Release =
  {
    includedirs    = {"C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/include"},
    linkdirs       = {"C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/lib"},
    links          = {"zlib"},
    frameworkdirs  = {},
    frameworks     = {},
    syslinks       = {},
    defines        = {},
    cxxflags       = {},
    cflags         = {},
    shflags        = {},
    ldflags        = {},
    __bindirs      = {"C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/bin"},
    __resdirs      = {},
    __srcdirs      = {},
    __dep_names    = {}
  }
}
conanfile.txt: Generating aggregated env files
conanfile.txt: Generated aggregated env files: ['conanbuild.bat', 'conanrun.bat']
Install finished successfully
finding zlib/1.2.11 from conan ..
checking for conan::zlib/1.2.11 ... zlib/1.2.11
{
  linkdirs = "C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/lib",
  sysincludedirs = "C:/Users/wangrunqing/.conan2/p/b/zlibe89ffb4a04318/p/include",
  libfiles = "C:\Users\wangrunqing\.conan2\p\b\zlibe89ffb4a04318\p\lib\zlib.lib",
  links = "zlib",
  static = true
}

  => install conan::zlib/1.2.11 latest .. ok
checking for link.exe ... C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.41.33923\bin\HostX64\x64\link.exe
checking for the linker (ld) ... link.exe
configure
{
    vs = 2022
    kind = static
    buildir = build
    host = windows
    proxy_pac = pac.lua
    mode = release
    theme = default
    clean = true
    arch = x64
    network = public
    plat = windows
    ndk_stdcxx = true
    ccache = true
}


Google cloud credential not available on v2.5

What kind of request is this (question/bug/enhancement/feature request): Bug
Steps to reproduce (least amount of steps as possible):
From v2.5-head, navigate to Cloud Credentials -> Add Cloud Credential -> Cloud Credential Type
Result:
Google is not on the list.
Other details that may be helpful:
On master, Google is an available cloud credential type:

But not so on v2.5:

Even though googleCredentialConfig is part of the cloudcredential API schema:

Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): v2.5-dev
Installation option (single install/HA): single

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):
Machine type (cloud/VM/metal) and specifications (CPU/memory):
Kubernetes version (use kubectl version):

(paste the output here)

Docker version (use docker version):

(paste the output here)

Haven't merged into 2.5 yet, will be soon.
https://github.com/rancher/ui/pull/4505

In latest2 and will be in rc3+.

I was able to create CC on 2.5-head-7426ba83e using UI and checked the created secret using kubectl


Problems with appearance after removal layout.

I work with a demo. Added to the VerticalLayout components. After removing any changes appear to have been below components my not drawn layer (including Gantt).
P.S. such problem occurs only when the chart displayed Predecessors line

Try with version 0.9.4. It has few fixes to bugs that might have caused this kind of behaviour.

In version 0.9.4 the same problem

Could you please give a simple test code how to reproduce this issue. Thanks.


AutoStruct does not respect type definitions for associations

When using auto_struct and a module definition, ROM is not respecting the configured types for an association.
schema(:articles, infer: true) do
  associations do
    belongs_to :profiles, as: :author, foreign_key: :author_id
  end
end

class Entities::Article < Entity      # entity itself inherits from ROM::Struct
  attribute :author,   ::Entities::Profile
end

ArticleRepository.new(rom).first.author.class
# => Entities::Author ... expect an Entities::Profile

reproduction script:  https://gist.github.com/cflipse/947447e4c656b35d351ffb518df38d65
Directly mapping to the class via map_to will coerce the author field correctly.

@cflipse Adding struct_namespace Entities to the ArticleRepository solved the issue for me:
class Articles < ROM::Repository[:articles]
  struct_namespace Entities

  def list
    articles.combine(:author)
  end
end


Add plain text version of Zen of Python

Which issues are addressed?
I was hoping that curl http://pep20.org would give me a plain text version, but it didn't.
I realized that this isn't possible currently because this is hosted on Netlify.
What's implemented?
A single file with the plain text version of PEP 20.
Why this implementation?
So I can curl http://pep20.org/txt (I hope this works at least...) to get the plain text of PEP 20.
Any caveats?
I don't actually know whether this will work.
https://pep20.org/README.rst worked but https://pep20.org/.editorconfig did not. I'm hoping Netlify is just disallowing dotfiles from being accessed and not checking file extensions specifically (since txt doesn't even have an extension).
Any additional notes?
If you feel this should be renamed to zen.txt or something else (shorter is preferable in my opinion) feel free to do so.
Checklist

[ ] Everything works.
[ ] Test are present and pass.
[ ] Documentation has been updated.

👆 I didn't do any of the above steps 😅

Ah hah the deploy preview worked! https://deploy-preview-1--pep20.netlify.app/txt
I'd say this works now.
I saw no tests, so I'll mark those as passing 🤷
As for documentation, the README and/or the footer of the website could note that https://pep20.org/txt can be accessed for plain text... or this could be left as an easter egg (like the original zen). 🥚 I'll leave that decision up to you, @nkantar.

Not gonna lie, I kinda love this! :joy:

The only potential issue I see is that https seems to be required: curl https://pep20.org/txt

The only potential issue I see is that https seems to be required: curl https://pep20.org/txt

I think that's fine 👍
Thanks for meeting so quick 🙌

You’re welcome and thanks for the contribution!


Inconsistencies in model fine-tuning

Hello, thanks for the amazing work!
I want to execute the script examples/02_finetune_new_observation_action.py obtain a fine tuned version of octo to test in the aloha gym environment. I started the training on an A100 but I'm noticing some differences with what it is written in the report:

The script trains the model for 5k steps instead of 50k steps
The fine-tuning process is currently taking 77GB of VRAM while it should be able to run on 24GB
The current estimate to get to 5k steps is 80h instead of 5h

Also, I'm doing the finetuning on octo-small and the 24GB and 5h fine-tuning refers to octo-base so I was expecting it to take even less.
I was wondering whether fine-tuning on the aloha benchmark requires different hyperparameters which results in the inconsistencies or there is an error in the finetuning script.
The only modifications I've done to the code are:
flags.DEFINE_string(
    "pretrained_path", 'hf://rail-berkeley/octo-small', "Path to pre-trained Octo checkpoint directory."
)
flags.DEFINE_string("data_dir", '.', "Path to finetuning dataset, in RLDS format.")
flags.DEFINE_string("save_dir", './aloha_octo', "Directory for saving finetuning checkpoints.")

As all the values were previously set to None.
Do you have any idea what the issue might be?
Thanks in advance 🐙

did you find the problem with the memory. Mine is taking more the 70 GB for the base model


azure-storage-blob 12.0.0

Which service(blob, file, queue) does this issue concern?
Blob
Which version of the SDK was used? Please provide the output of pip freeze.
azure-storage-blob 12.0.0
What problem was encountered?
cannot import name 'BlockBlobService' from 'azure.storage.blob'
Have you found a mitigation/solution?
Revert back to v2.1.0
I just want to add that in pypi the documentation mentions to use from azure.storage.blob import BlobServiceClient. However the documentation found in https://azure-storage.readthedocs.io/index.html still mentions using BlockBlobService instead. So can I clarify which package are we expected to import going forward?

azure-storage-blob 12.x is being developed over at https://github.com/Azure/azure-sdk-for-python/tree/master/sdk/storage/azure-storage-blob , it seems.
The PyPI metadata hasn't been updated to reflect this though.

Hi @jialutu
Thanks for reaching out!
The pypi says the correct thing, you should import BlobServiceClient if you plan to use azure-storage-blob version 12.0.0
Here is the doc for reference.
https://azuresdkdocs.blob.core.windows.net/$web/python/azure-storage-blob/12.0.0b5/index.html
The doc you were looking at is for version 2.0.0.
Let me know if you need other help!

Thanks @akx for the heads-up!
@xiafu-msft It appears that the project home link should be updated.

Sure, the pr is there, https://github.com/Azure/azure-sdk-for-python/pull/8358 probably it will not be in prod until next release?

I have to say though this is quite disappointing in that there has been no deprecation warnings for the BlockBlobService, where a new version has been released getting rid BlockBlobService entirely, which we rely on for our production services.
If this is the case going forward for Azure python libraries, I am starting to question our long term strategy of using Azure.

I have to say though this is quite disappointing in that there has been no deprecation warnings for the BlockBlobService, where a new version has been released getting rid BlockBlobService entirely, which we rely on for our production services.

This was a very major version bump (azure-storage-blob==2.1.0 -> azure-storage-blob==12.0.0) – I don't know if Azure SDKs follow Semver, but if they do, that alone should be a big ol' warning sign that APIs will have changed.
In my opinion, you should not be running production services without having pinned/locked your dependencies in a way that ensures you can test that exactly the versions of all dependencies you install have a fighting chance to work in your production environment, too. My tool of choice for pinning Python dependencies is pip-tools.

@jialutu @xiafu-msft  @zezha-msft . I am also facing similar issue. This is very strange.
There should be some kind of backward compatibility.I have many services running on production and all are impacted. Such drastic changes are worry-some and making me reconsider azure as cloud provider.
We understand azure is in development phase but you have to give backward compatibility otherwise people will prefer AWS at-least they are stable and don't make drastic changes in their sdk's.

Hi @jialutu @akshitjain, thanks for sharing your concerns, and sorry for the inconvenience.
To clarify, the SDK follows semantic versioning, and all major version updates are breaking by definition. As @akx has pointed out, it is best practice to pin to a specific version for your dependencies that you have tested with, to avoid having a brittle production environment.
All the Storage SDKs were re-designed in version 12.0.0 and provide better usability. The official announcement will come soon.

FYI @jialutu the Pypi page has links to the samples and reference docs.

@zezha-msft please update the project homepage link on PyPI. It currently links here, however, it should point to https://github.com/Azure/azure-sdk-for-python (or, as the source code link does, to: https://github.com/Azure/azure-sdk-for-python/tree/master/sdk/storage/azure-storage-blob/azure/storage/blob). It's confusing that the project has been re-parented, but this repository continues to exist.

Hi, is the official announcement still in the works? This change broke my project and it'd be useful to have a bit of context as to what's going on.


runner-container-hooks doesn't handle shared-workflow (actions/checkout@v3)

Hi.
I'm creating a new package for another container runtime. I can't disclose which container runtime is due to legal reasons.
we've written runner-container-hooks for that runtime, and it manages to spawn and destroy the container successfully.
the problem we're facing is when the workflow use shared-workflow.
in this picture, we're using actions/checkout@v3, and the container we've spawn does not have proper application installed for this action to run.
from what I understand, actions/checkout@v3 are required to run on a different container (node16).
I am expecting that runner-container-hooks will get comand=prepare_job AND command=run_script_step. But from my debugging, I only receive command=run_script_step
any advice on what I can do here?
I should be able to start a secondary container if I can detect which container the shared-workflow wants to use

oh wow, this is useful information.
it does makes sense that checkout step should only trigger run_script_step 👍
it also means that we can check what the step is trying to do, and choose which container we want to run it on.
wonderful. 😄
I think we can run a few additional steps to start containers to run checkout if we can detect them.
any suggestion/documentation on hooks/API that can help us to detect what workflow is trying to run?
we can git clone those actions in a temp directory and scan for action.yml

The runner already downloads the action that needs to be executed so you can avoid the git clone :relaxed:.

The entrypoint can inform you what type of actions is it based on the executable it needs to run (node, bash, ...), and the entrypoint argument is the directory where the action is stored. So you can distinguish between a step that is trying to execute the action (it will have a script at the path starting with /__w/_actions), and the job step (/__w/_temp/...)

wonderful. I think we got all the information that we need.
thanks for your time 😄


add Grégoire's paper to landing page

Since their dataset is now available in our interface, we need to put their publication describing the data there too.

Fixed by commit 5946ecaa455a3b1d1a7f9c6c8946bd865a5bd3f0


Added missing PromptTextNode in the example.

I added a node that was missing from the workflow example.

UtilNodes-ComfyUI

Where is UtilNodes-ComfyUI?

Here is the link
https://github.com/AIFSH/UtilNodes-ComfyUI

Is this really the solution though? I feel that the OmniGen node just needs to take a regular string, then it can be used with the large number of already existing textbox nodes

Is this really the solution though? I feel that the OmniGen node just needs to take a regular string, then it can be used with the large number of already existing textbox nodes

100%. I don't think it should include any nodes as well. There are too many multi-string nodes as-is.


There should be a method named version() to get the current version of installed ffmpeg

There should be a method command::check_current_version() in the command.rs , that will return the version string, that can be matched against download::check_latest_version() . So, that the user can decide to download the updated versions, if exists..
If there is a existing way to solve this problem, then please give code examples

There is a function that does this called ffmpeg_version:
https://docs.rs/ffmpeg-sidecar/1.1.2/ffmpeg_sidecar/version/fn.ffmpeg_version.html
There's also a variant where you can pass a path to a specific binary.

Yaa, thanks.. My Bad. You can close the issue now


[WIP] find cause and fix for heisenbug in test for 4 year limit on embargo dates

Purpose
OSF-6477 describes a bug that we're seeing intermittently during testing at Travis. This PR is exploratory, to find a root cause and a fix.
Status
Root cause identified. Surrounding area mostly excavated, and now comparing it to what validation is supposed to look like. PRs:

[ ] Lightly refactor registration modal (#6025)
[ ] Clean up Knockout-Validation usage (#6050)

Changes
n/a
Side effects
n/a
Ticket
OSF-6477

Blam: subsecond differences when UTF offset is zero. I surmise that the occasional successful test is due to the clock precision only going to three places, with the moments sometimes being the same to three places.

Alright, so what's the right fix?

@brianjgeiger at https://github.com/CenterForOpenScience/osf.io/pull/5708#issuecomment-221261771 articulates some confusion about UTC vs. local time in this code: a sentiment I share. Let's look into that ...

It's also smelly that embargoLocalDateTime is undefined. Is that simply a test knob? I think so.

And what's up with todayM{ini,axi}mum part of the validation tests? What's the purpose of that

Seems (be77d53c98276c8cf2d8ed05ca1f73bd6e85e252) that that's designed to prevent the "load the page and leave it open for three days" issue mentioned in https://github.com/CenterForOpenScience/osf.io/pull/5708#issuecomment-221261771.

But wait, that's precisely backwards. We want to validate the embargo date against the moment when the user selects the date, not the date when the page loads. Hmm ...
Ultimately we should also have a server-side check on the date. Do we?

Fix issue where Embargos could be made in the past if time is changed

If time is changed then we've all got bigger problems. ;-)

Do we?

Yes. Do we use it? :)

Yes, during submit_draft_for_review.

Hitting a Chrome DevTools bug ...

... back on track.

Yes, during submit_draft_for_review.

However, I'm not seeing where that route is hit. When I click "Continue" on the registration modal (it is the registration modal, correct?), I see a POST to this route instead:
http://localhost:5000/api/v1/project/f39dm/drafts/5789352a250c776b3c57d5cd/register/

Alright, so it looks like server-side validation of the embargo date doesn't happen until the draft registration is submitted for approval. I haven't fully traced the flow for this, but for our purposes here we shouldn't need to. The point here is that we don't need to ... well, hmm ...
I'm trying to understand the relationship between the client-side validation and the server-side validation. Are they targeting the same conditions? This sentence-ish piece of documentation is tantalizing on this point:

If an embargo end_date that is within that window is at risk of causing validation errors down the line if the draft is approved and registered.

How to interpret ... ?

I'm excavating to find a good point at which to begin fixing the presenting issue with the test.

I now find an _is_embargo_date_valid method on the Node class. I believe the call chains look like this:
registrationModal.js
  /api/v1/project/<pid>/drafts/<draft_id>/register/
    website.project.views.drafts.register_draft_registration
      website.project.model.Node.embargo_registration
        website.project.model.Node._is_embargo_date_valid
???
  /api/v1/project/<pid>/drafts/<draft_id>/submit/
    website.project.views.drafts.submit_draft_for_review
      website.project.views.drafts.validate_embargo_end_date
        website.project.model.Node._is_embargo_date_valid

My general impression is that the client-side and (both) server-side validations are supposed to be the same. It'd be clearer if they used the config setting consistently.

This reminds me of when we looked at the comment length validation at https://github.com/leb2dg/osf.io/pull/14#discussion_r61798316. I suppose this is where Node.js gets to say, "Told ya so!"

Why are we using timestamps at all? The input is a date picker. Why aren't we validating based on date alone, without reference to time of day?

I find a call to a seemingly vestigial isEmbargoEndDateValid function.

... unless it's a magic name from Knockout-Validation?

Why aren't we validating based on date alone, without reference to time of day?

http://momentjs.com/docs/#/manipulating/start-of/
moment().startOf('day')

(via)

I'm having trouble triggering the onSelect for pikaday. Is it because of a blockage in my assets pipeline? Or because the code is, in fact, never called?

Open Questions

[ ] What is the validation intention?
[ ] How do client and server sides relate?
[ ] How do local and UTC time relate?
[ ] Is isEmbargoEndDateValid vestigial?
[ ] What is this sentence supposed to say?

In restricted Flowdock, @abought seconds the opinion that the isEmbargeEndDateValid call is vestigial.

isEmbargoEndDateValid entered in c711f60 (no PR?) (h/t)

It was a computed observable. Okay! Vestigial code!

Relevant. :-)

Hitting that Chrome bug again. 😞

Turns out that the entire picker object was vestigial. PR to remove it in #6025.

Gosh. Alright, now for the validation intent ...

the validation intent ...

What's the workflow for a registration? What role does the embargo end date play?

There's a draft registration approval period which should be more than the minimum embargo end date.

That's confusing to me. I was about to think that the registration approval phase wanted to always complete before the embargo started.

http://help.osf.io/m/registrations may be useful.

First I've seen of our user-facing help docs—I was actually about to ask for design docs or some such. Thanks, @brianjgeiger! :-)

First I've seen of our user-facing help docs

(That may not be strictly true. :)

When a project is registered, all administrators on the project are notified via email and given the opportunity to approve or disapprove the registration by clicking the appropriate link in the email. The registration goes into effect when all administrators have approved the registration or 48 hours have passed, whichever comes first. If one administrator disapproves the registration, it is cancelled. You will be notified via email if an administrator disapproves the registration.

Embargoed registrations undergo the same contributor approval process as immediate registrations. The registration will enter the embargo period when all project administrators approve the registration or 48 hours pass, whichever comes first.

http://help.osf.io/m/registrations/l/524207-embargoes

I find an additional validator for the case where the meta-schema of the draft registration requires approval (the configured timeouts are to be kept manually in sync(!) between Python and JavaScript). On the one hand, that makes it sound like there's a case that doesn't require approval, which the help docs don't seem to mention. On the other, I don't believe I've yet been able to trigger the additional validator in the UI ...

It's weird to have two minimum date validations:

one: 'Embargo end date must be at least three days in the future.'
two: 'Embargo end date must be at least ' + DRAFT_REGISTRATION_MIN_EMBARGO_DAYS + ' days      in the future.'

If I'm reading this code right, both messages could be shown at the same time. No? That'd just be weird.

Is draft registration approval different than (non-draft) registration approval?

Coincidentally(?), I'm seeing this in my inv server console:
    return func(this, *args, **kwargs)
  File "/Users/whit537/workbench/cos/osf.io/env/lib/python2.7/site-packages/modularodm/storedobject.py", line 935, in __getattr__
    raise AttributeError(errmsg)
AttributeError: DraftRegistration object has no attribute requires_approval

I'm beginning to wonder whether requiresApproval is also vestigial. O.O

I find a metaschema collection. I haven't traced the connection from the db out to the UI, but it seems likely that this collection is the source for e.g., self.metaSchema. I don't find a requires{A,_a}pproval key in any of the documents in this collection (I'd want to wipe my db and retry with a fully updated develop to be sure). It's possible that this key is inserted somewhere between the db and the UI (computed how?). Perhaps a missing requiresApproval in the db results in a false value in the JavaScript. But why is the key missing from all documents? None have a truthy requires_approval.

It appears that draft in the Mako context is upstream of metaSchema; draft comes from serialize_draft_registration.

The draft argument to serialize_draft_registration is a DraftRegistration instance (created and injected, with impressive gymnastics, by autoload).

DraftRegistration has a requires_approval computed property, which delegates to MetaSchema. The meta-schema in turn dynamically computes its requires_approval property, from the .schema.config.requiresApproval key in the Mongo document.

Okay! Looks like requiresApproval is for the pre-reg challenge.

... and only for the Prereg Challenge, at this point.

Okay, so I predict that if I try to submit a registration for the Prereg Challenge that has a date that's less than 3 days in the future, I'll get two error messages:

Embargo end date must be at least three days in the future.
Embargo end date must be at least 10 days in the future.

False! I get only one message, the 10 days one:

Why?

Looks like Knockout-Validation bails after the first validation failure; if I change unshift to push I get the "three days" message.
Okay!

... so requiresApproval is not vestigial. How does it interact with the requirement for approval in non-prereg-challenge cases?

Alright, I'm pretty sure this is the basic workflow:

It seems that the complication here is in the variability of the approval step: ideally the end of the embargo would be expressed in terms of the end of the approval process, but ...

approval time varies from seconds (there is one admin, they approve immediately), to 48 hours; and
approval for the Prereg Challenge seems to want up to 10 days instead of only three.

Therefore, we validate the embargo end date when the draft is submitted, and, as a proxy, when the embargo end date is selected in the registration modal.

The correct behavior is to work with local time in the UI, and store UTC. I don't know yet what our actual behavior is, but I note that the server-side validation on submit will (I expect) have UTC to look at, while the client-side validation will need to present local time to the user.
Again, on my read, the time component is actually irrelevant, and should be removed from the equation. We only care to compare the date component.

Since the server-side validation on registration submission is the actual validation that counts, I'm thinking we should start by cleaning that up: making sure it is using UTC properly, and only using the date part. Perhaps that could introduce some discrepancy with the client-side, though I wouldn't be surprised if such a discrepancy already exists. On the client side, I think we should clean up the two validators in registrationModal.js first, and then refactor the third validator as well: it should use moment.js instead of Date(), and it should be clearer that it's replacing the minimum validation instead of augmenting it.
That's a first outline of a work plan, anyway ...

approval for the Prereg Challenge seems to want up to 10 days instead of only three.

I think I have this wrong. DRAFT_REGISTRATION_APPROVAL_PERIOD is where the 10 days is defined, and it' used in validate_embargo_end_date, so let's see about resolving the ??? in https://github.com/CenterForOpenScience/osf.io/pull/5977#issuecomment-233406232 ...

I find a "Submit for review" button that promises (eventually) to post to /submit/ (...). How do I see it in the UI?
Sounds like this is another difference with the Prereg Challenge.

When you're ready to preregister, select Submit for review if you would like to submit your preregistration to the Preregistration Challenge. If you would like to preregister without entering the Challenge, select Register without review.

A preregistration submitted for review is not immediately registered. A member of the COS review team will check your submission to assure completeness and adherence to the competition’s terms and contact you within 10 business days (typical review time is 1-3 business days).

Registering without review will preregister your project right away. Your preregistration may be made public immediately or embargoed for up to 4 years.
http://help.osf.io/m/registrations/l/546603-preregistrations

Alright, so the Prereg Challenge adds an additional step: review by COS staff. Hmm ...

Confirmed. I get "Submit for review" for the Prereg Challenge, and a POST to /submit/. 👍

Alright, staring at registrationModal.js, trying to rein this back in.

It's also smelly that embargoLocalDateTime is undefined. Is that simply a test knob? I think so.

The docs say that validator functions take two args: the value to validate, and an otherValue to check it against. Our third argument is a hack to make testing easier. It seems we're not using Knockout-Validation as designed.

Why do we need a minimum embargo length? What's wrong with an embargo that lasts one day and an approval process that takes 10 days, as long as we check both conditions before displaying a registration?

(For that matter, who cares if an embargo lasts longer than four years? What's the harm in a 100-year embargo?)

I've added some commits to #6025, and started a second PR to clean up our Knockout-Validation usage: #6050.

I pushed another couple commits to #6050, and rebased #6025 along the way. I'm now thinking through todayM{in,ax}imum.

todayMinimum is the moment two days out from when the page loads. Since min is calculated in the same way (.add(2, 'days')) at validation-time, it is necessarily after todayMinimum. The test end.isSameOrAfter(todayMinimum) is therefore redundant with the test end.isSameOrAfter(min), and the todayMinimum test can be safely removed.
(I suppose it's possible that the test min and todayMinimum tests are supposed to differ: the max tests do, one testing 4 years, the other 4 years - 1 day.)

On the other hand, the computation of todayMinimum as four years does differ from that of max, which is four years less a day, so it's not necessary that end precede the latter when it precedes the former. There is a one day window after loading the page during which end.isSameOrBefore(max) can be false while end.isSameOrBefore(todayMaximum) is true. In this case, the todayMaximum check prevents a user from loading the page, leaving it open for a few days, and then selecting a date that is more than four years in the future from when they first loaded the page. However, this is trivially worked around by simply reloading the page. The todayMaximum check is, afaict, pointless.

Fix issue where Embargos could be made in the past if time is changed

Okay, I now find a comment in restricted Jira that seems to make sense of be77d53c98276c8cf2d8ed05ca1f73bd6e85e252:

When I manually change my date and time, I am able to register less than 3 days into the future. Is this an issue?

This also means that if I manually change my date, I can set embargoes to end in the past.

Here's what to do to make an embargo in the past:

Make an Open-Ended registration on staging.osf.io
Click continue all the way until you hit the modal that gives you the option of either making it public immediately or setting an embargo.
Choose to make an embargo. Click on the bar to select the end date so that the calendar shows up.
Go to your date and time preferences and change your date to a date in the past, such as June 1st.
Make sure that on the calendar on OSF, it shows that it has registered the fact that your date is now June 1st.
Now select June 4th. It will let you do so.

However, be77d53c98276c8cf2d8ed05ca1f73bd6e85e252 doesn't actually fix this issue, because it's possible to change one's operating system clock before loading the registration modal.
It's always going to be possible for a sufficiently motivated user to bypass the date validation on the client-side, because of the high degree of control they have in that environment. We have (or should have, if what have isn't sufficient) server-side validation to prevent gaming the system. What we should be thinking about on the client-side is not so much preventing abuse and preventing confusion. Validating against the date at which the user actually selects a value is less confusing than validating against the date when the page loaded.

I'm still able to reproduce the bug locally after refactoring (I'm using a slightly modified version of 6acc411501dbd3aa4a780ce5b047442f921bd7fa from #6050). 👍

The crucial clue here is that the test consistently fails when UTC offset is zero or positive, and consistently passes when UTC offset is negative.
I note that our timezone tests are rather U.S.-centric. Perhaps a test or two for a truly Eastern timezone would help us out here. ;-)

Well, one thing to notice is that max is local time, while end is UTC (though converting a moment to UTC by subtracting moment().utcOffset() minutes seems weird; why not use moment.utc()?). Returning local time from embargoEndDate's function corrects for that, but then we're always in essentially the same case as we've been in with a UTC offset of zero. Now what?

This is where subtracting a day from the four years starts to look weird. Did we kludge that just to line up with the non-moment construction in the test?

Right, well ... adding a millisecond to the value in the test makes it pass for me here. If there truly are some subsecond differences going on then a millisecond may not be enough, but surely a second or two would be. A day or two would satisfy the test.

Rebased on develop and fix pushed. Previous head was e62cf7a0d19323c920f12844c9d28d2a334a8383.
Let's see what Travis has to say ...

Alright, I've rebased #6025 and #6050 on the latest here (9b46822332409beb646b65d7f6485f08c1b947e2). I'm gonna let Travis churn, maybe tomorrow I'll be able to submit this for code review. 💛

D'oh! 🐭

TEST_BUILD="else" got clipped at two hours.
TEST_BUILD="varnish" hit what could be another heisenbug.

I don't find any immediately helpful error message in the failed build log, though I do recognize it from last night. I see some tracebacks during license and schema loading, but I'm not sure they're not part of normal operation. More research required.
The build for 9b46822332409beb646b65d7f6485f08c1b947e2 looks better—no failure on "varnish"—but this time it errored out not on a timeout but ... what? Now even the Chrome tabs for these Travis builds are erroring out on me. 😩
It appears that 6fb954f6a981290469c09d72cabeb2383e32af7e on #6050 also timed out on "else" ... can't say for sure without loading the detail page.
The build in the middle, for a52b9ab0aff65b0dcbd71388964fa95d00ccfe9b on #6025, failed on both else and varnish.

The 9b46822332409beb646b65d7f6485f08c1b947e2 build errored with "The log length has exceeded the limit of 4 Megabytes (this usually means that test suite is raising the same exception over and over)." Click at your own risk; you'll be loading four megs.

It appears to have been an elasticsearch failure, though in other news I don't see tracebacks loading licenses or schemas, so maybe that is a clue to the other failure after all.

Here's the first elasticsearch failure. I believe what we're seeing is urllib3 time out after 10 seconds, which somehow leaves the connection in a bad state. Line 4097 seems to indicate that elasticsearch is no longer blocking on the timed-out request, but it appears that all subsequent requests to elasticsearch are failing with ProtocolError: ('Connection aborted.', BadStatusLine("''",)). Elasticsearch is reporting response times in the milliseconds in these cases.
For our purposes here we can probably chalk this one up to "Travis was busy," as with the builds hitting Travis's two-hour cap. It would be nice to find a better failure mode before we hit the urllib3/elasticsearch problem in production.

can't say for sure without loading the detail page.

Confirmed

The build in the middle, for a52b9ab0aff65b0dcbd71388964fa95d00ccfe9b on #6025, failed on both else and varnish osf.

The "osf" build exhibits the elasticsearch timeout and subsequent bad status line, but seems to recover somewhat so it doesn't hit the four meg log limit.
The "else" build failed with ... our heisenbug! 😄  While the familiarity is comforting, it seems to mean that the fix is wrong. 😞
Hmm ...

Hmm ...

Walking through the build results again, to make sure I read them right.

Build Results

step
bugfix (eafdfa53b8aeff900c61af7a3ea3b07a77500729)
etc. (9b46822332409beb646b65d7f6485f08c1b947e2)

osf
✅
✅

else
❗(timeout)
❗(spaceout)

varnish
❌  (license-loading issue(?))
✅

Gosh. How did I come to believe that I was seeing the heisenbug again?

Ah, yes: it wasn't on this PR, but rather on #6025. Hmm ...

(Results table updated.)

Does a52b9ab0aff65b0dcbd71388964fa95d00ccfe9b indeed contain the fix, or did that get gunked up in rebasing?

Looks like it does indeed contain the fix (one, two). Hmm ... I guess we're back to the drawing board! 🐉

Closing and reopening this PR to trigger a rebuild at Travis should surface the bug again on this PR (assuming the other Travis issues don't continue to afflict us).

Did the same with #6025 and #6050. Let's see if we can dodge the issues apparently related to Travis slowness and get a clean picture of where we stand.

Clear enough. :)
Build Results

buildstep
bugfixeafdfa53b8aeff900c61af7a3ea3b07a77500729
#6025a52b9ab0aff65b0dcbd71388964fa95d00ccfe9b
#60502aef3b57416f89c639202fb2a2ee3e13ad92bc1b

osf
✅
✅
✅

else
❌ (heisenbug)
❌ (heisenbug)
❌ (heisenbug)

varnish
✅
✅
✅

Ooooh! I think I just fixed the wrong test ...

Yup. Tee-hee! 😊

New fix pushed. Let's see if this 🐶  can hunt ...

Wherefore art thou, Travis?

https://travis-ci.org/CenterForOpenScience/osf.io/builds/148970448 ...

Woo-hoo! Green! Reproducible? :)

Running at Travis again.
Hmm ... in the mean time, I'm looking at this second test, which seems at first blush to duplicate the first. Does it? Does it fail when the first does? If not, why?

I added some logging to maximumTimeValidation and captured the following results.
console.log('loc:', moment(embargoLocalDateTime).format('YYYY-MM-DD HH:mm:ss.SSSSS'));
console.log('max:', moment(maxEmbargoMoment).format('YYYY-MM-DD HH:mm:ss.SSSSS'));
console.log('end:', moment(endEmbargoMoment).format('YYYY-MM-DD HH:mm:ss.SSSSS'));
console.log()

"returns false for date more than 4 years in the future":
LOG LOG: 'loc:', '2016-08-01 17:18:10.18600'
LOG LOG: 'max:', '2020-07-31 17:18:10.18600'
LOG LOG: 'end:', '2020-07-31 21:18:10.18500'
LOG LOG:
LOG LOG: 'loc:', '2016-08-01 17:18:10.18700'
LOG LOG: 'max:', '2020-07-31 17:18:10.18700'
LOG LOG: 'end:', '2020-07-31 21:18:10.18500'

"returns false for date at least 4 years in the future":
LOG LOG: 'loc:', '2016-08-01 16:56:31.72300'
LOG LOG: 'max:', '2020-07-31 16:56:31.72300'
LOG LOG: 'end:', '2020-07-31 16:56:31.72200'
LOG LOG:
LOG LOG: 'loc:', '2016-08-01 16:56:31.72300'
LOG LOG: 'max:', '2020-07-31 16:56:31.72300'
LOG LOG: 'end:', '2020-07-31 16:56:31.72200'
LOG LOG:
LOG LOG: 'loc:', '2016-08-01 16:56:31.72200'
LOG LOG: 'max:', '2020-07-31 16:56:31.72200'
LOG LOG: 'end:', '2020-07-31 16:56:31.72200'
LOG LOG:

The heisenbug is in a test for #pikaday.isValid. The second test is in the suite for #timeValidation, and it calls maximumTimeValidation directly rather than going through isValid.

Analyzing the results, I take it that the last call to maximumTimeValidation is the relevant one. I see a subsecond difference between max and end in the heisenbug case, but in the second case they're exactly the same. Predictably so?

Predictably so?

Yes.
In the pikaday case, embargoLocalDateTime is undefined coming into maximumTimeValidation, and therefore going into getMaximumDate, such that a new Date is constructed under getMaximumDate (inside Moment.js). The endEmbargoMoment, however, is coming from the pikaday, which was populated just prior in the test with invalidFutureDate, a Date created at the start of the test. Therefore, in the heisenbuggy test case (modulo the UTC gaffe), endEmbargoMoment is necessarily earlier in time than maxEmbargoMoment. That it was occasionally not seems likely to be due to clock imprecision: they sometimes appeared to be the same.
In the timeValidation case, embargoLocalDateTime is not undefined , but rather a Date that becomes the basis of a moment four years (less one day?!) hence: maxEmbargoMoment. Now, the self-same Date had already been used to compute a Date four years hence to populate the pikaday, which is where endEmbargoMoment comes from. Therefore, endEmbargoMoment and maxEmbargoMoment are guaranteed to be the same—as long as Moment's computation syncs with ours (perhaps leap years (cf. private Jira) could throw this off?).
I've modified the logging above to show the variance in embargoLocalDateTime (I'm running inv karma --single with it.only for each test).
console.log('loc:', embargoLocalDateTime === undefined ? 'undefined' : moment(embargoLocalDateTime).format('YYYY-MM-DD HH:mm:ss.SSSSS'));
console.log('max:', moment(maxEmbargoMoment).format('YYYY-MM-DD HH:mm:ss.SSSSS'));
console.log('end:', moment(endEmbargoMoment).format('YYYY-MM-DD HH:mm:ss.SSSSS'));
console.log()

pikaday:
LOG LOG: 'loc:', 'undefined'
LOG LOG: 'max:', '2020-08-01 10:16:48.28300'
LOG LOG: 'end:', '2020-08-03 10:16:48.28200'

timeValidation:
LOG LOG: 'loc:', '2016-08-02 10:19:02.84900'
LOG LOG: 'max:', '2020-08-01 10:19:02.84900'
LOG LOG: 'end:', '2020-08-01 10:19:02.84900'

(The pikaday case there is showing a two day offset because I ran with the fix, a6efbb4739bc476ee8a01deeba37228aedfed1dc. However, the subseconds are the relevant bit.)

Ready for review! :-)

Pulitzer worthy no doubt.
Changes lgtm; 🚢


libwacom: 0.26 -> 0.28

Semi-automatic update. These checks were performed:

built on NixOS
ran /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28/bin/libwacom-list-local-devices -h got 0 exit code
ran /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28/bin/libwacom-list-local-devices --help got 0 exit code
ran /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28/bin/libwacom-list-local-devices help got 0 exit code
found 0.28 with grep in /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28
found 0.28 in filename of file in /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28

Success on x86_64-linux (full log)
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28
shrinking /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28/bin/libwacom-list-local-devices
shrinking /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28/lib/libwacom.so.2.6.1
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
/nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28
stripping (with command strip and flags -S) in /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28/lib  /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28/bin
patching script interpreter paths in /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28
checking for references to /tmp/nix-build-libwacom-0.28.drv-0 in /nix/store/yi7myg1fay4my7dl64nbj0mlv2qdma6z-libwacom-0.28...

Failure on x86_64-darwin (full log)
Partial log (click to expand)
Package ‘libwacom-0.28’ in /private/var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/lnl7-mac/pkgs/development/libraries/libwacom/default.nix:18 is not supported on ‘x86_64-darwin’, refusing to evaluate.

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowBroken = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowBroken = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/05b7z8ylxn0aczql93l2kghmic6yvasw-libwacom-0.28
shrinking /nix/store/05b7z8ylxn0aczql93l2kghmic6yvasw-libwacom-0.28/bin/libwacom-list-local-devices
shrinking /nix/store/05b7z8ylxn0aczql93l2kghmic6yvasw-libwacom-0.28/lib/libwacom.so.2.6.1
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/05b7z8ylxn0aczql93l2kghmic6yvasw-libwacom-0.28/lib  /nix/store/05b7z8ylxn0aczql93l2kghmic6yvasw-libwacom-0.28/bin
patching script interpreter paths in /nix/store/05b7z8ylxn0aczql93l2kghmic6yvasw-libwacom-0.28
checking for references to /build in /nix/store/05b7z8ylxn0aczql93l2kghmic6yvasw-libwacom-0.28...
/nix/store/05b7z8ylxn0aczql93l2kghmic6yvasw-libwacom-0.28


How to get rid of double quoting in v0.8?

In this case:
fade-in="'slow'"
it looks very weird but works.
In some sample I found that this works:
fade-in=`slow`

but it needs v0.9
Is there some trick for v0.8?

I thiiink... this isn't a bug. Arguments for transitions (and decorators) are comma-separated expressions. This means the string has to have quotes around it, otherwise it's treated as a variable.
iirc, the backticks syntax was a 0.9 addition by @evs-chris .

Found the PR https://github.com/ractivejs/ractive/pull/2868

Yes, I'm not saying it's a bug, I understand the behavior, and thank you for all additional related information.
I'm just looking if there is some trick in v0.8…
Here is some option http://jsfiddle.net/Inversion/cvq1ku8f/ (I know, it is not good…)

This can be closed. I personally do not need it anymore, maybe no one else needed it )


Fix assert issue

see original PR that I accidentally merged here: https://github.com/whereby/browser-sdk/pull/79
and the revert here: https://github.com/whereby/browser-sdk/pull/80
🤦
Description
We are having some funny module resolution problems with rollup, so this pr aims to replace it with esbuild
Adds build steps for individual react/embed builds as well
Gotchas
Esbuild can't emit typescript declarations, so we have to do it with tsc
Unfortunately, tsc can't generate es6 concatenated declarations so we include the full directory structure... is this a problem?
To Test

yarn to install the stuff
yarn build to generate the builds and types
import it into a demo project

Screenshots
Here's me importing just the react bundle like import { useRoomConnection } from<EMAIL_ADDRESS>
and using the embed bundle in a script tag like
<script type="module"<EMAIL_ADDRESS>

@havardholvik oops sorry

@havardholvik re. the /react and /embed imports, what do you think about moving that to a different PR considering everything else seems to be working here?

@havardholvik re. the /react and /embed imports, what do you think about moving that to a different PR considering everything else seems to be working here?

Im fine with that, as long as we see an improvement (and no regressions) with what we have today 👍

Ah I lied, CRA still doesn't work..

OK this finally works on CRA and Vite as an import and a script tag referencing the bundled embed.esm.js file (unless I'm mistaken)

@havardholvik wanna compare configs?
vite 4.4.5
react 18.2
typescript 5.02
// vite.config.js
export default defineConfig({
    plugins: [react()],
    define: {
        "process.env": {},
    },
    build: {
        minify: false,
    },
    server: {
        port: 6006,
    },
});

//tsconfig
{
    "compilerOptions": {
        "target": "es2016",
        "useDefineForClassFields": true,
        "lib": ["esnext", "DOM", "DOM.Iterable"],
        "module": "esnext",
        "skipLibCheck": true,

        /* Bundler mode */
        "moduleResolution": "bundler",
        "allowImportingTsExtensions": true,
        "resolveJsonModule": true,
        "isolatedModules": true,
        "noEmit": true,
        "jsx": "react-jsx",

        /* Linting */
        "strict": true,
        "noUnusedLocals": true,
        "noUnusedParameters": true,
        "noFallthroughCasesInSwitch": true
    },
    "include": ["src"],
    "references": [{ "path": "./tsconfig.node.json" }]
}


Balance eligibility previous+1 vs current epoch

In get_eligible_validator_indices the previous epoch is used, then "converted" (not strictly the same for genesis epoch) back to current epoch:
previous_epoch + 1 < v.withdrawable_epoch

Now the rewards and penalties, the only place where get_eligible_validator_indices is used, we don't run anything for genesis epoch:
def process_rewards_and_penalties(state: BeaconState) -> None:
    if get_current_epoch(state) == GENESIS_EPOCH:
        return

Does this mean the previous_epoch + 1 could just have been a current_epoch, as there shouldn't be any effective difference?
Context: @terencechain is comparing Prysm and spec/zrnt balances code, upgrading to v0.12, and after discussing the inclusion delay part (which seems to be a subset of eligible validators regardless of the eligibility check, although a tricky/awkward edge case), this difference showed up.
If there is any special reason to use previous_epoch + 1 instead of current_epoch I'd like to know, and we should add a comment as part of the spec function descriptions PR.

Found some previous discussion: https://github.com/ethereum/eth2.0-specs/pull/949#discussion_r277380008
It seems fine to me to use current_epoch.

Closing this issue, previous_epoch is used in the same variable scope already, so it seems ok to just use that, instead of getting the current epoch as well.


Fork a dot

User requirement
As a dotmesh user, I want read-only and read-write collaborators to be able to fork my dots and branches so that they can build on my work.
Key acceptance criteria

[ ] It should be possible to Fork a dot or a branch of a dot via the Dotmesh API as long as I have at least read-only access to a dot.
[ ] It should be possible
[ ] It should not be possible for the original owner of the dot to delete my fork.
[ ] It should be possible for the original owner to delete their original dot and have the dot disappear from their view, however it should still be maintained in the system as the origin of the fork.
[ ] Space accounting should include the size of the fork and its origin for all users, so that owners of forks are not surprised by the owners deleting origins otherwise causing their accounting to spike.

Implementation
Forks are just branches with a different owner. They should show up in the list of top level filesystems for the forker though, and not be visible to the forkee.

Depends on https://github.com/dotmesh-io/dotmesh/issues/575

Thanks @Godley, clarified!

@rusenask it will appear as a "top level" dot in e.g. the output of dm list for the forker and not the forkee, yes.


Api "onMovement" event

Hello, can you make an event to trigg a function when the viewer ison movement? I actually got this monitoring the compass style changes... I use this because i have 2 viewers, side by side, with the same panorama, but in different dates. It's for engineering purposes, to compare the two structures and see the changes along the timeline, but with the compass solution, i can't detect vertical-only movement, causing a little shake.

The addition of a render event is tracked in #310. I'm closing this as a duplicate.


Can you recommend the flash of this switching board

Hello, could you recommend the specific models of 128MB and 256MB flash for gamewatch? thank you

Hi,
You can find the 128GB and 256GB chip model numbers as well as links to retailers here:
https://www.reddit.com/r/GameAndWatchMods/wiki/flash-upgrade/

thank you:)


Update Layout and Style image gallery

top of page: https://screenshot.googleplex.com/tVYjx72cXNB
bottom of page: https://screenshot.googleplex.com/vJAe6UPr6FK.png

Please wait for Fola to accept the change.


Moodles can't find icon ids (Probably known?)

Just updated moodles and i am just filling a report here that no moodles are working, since moodles fails to find the given icons and id's with the following error.

but that might be a known issue? Reporting anyways, just in case
EDIT: Oh okay, the icons just shifted, it seems and that old moodles are no longer working?
EDIT 2: Okay, just searching for the old Icon ID shows the icon and the new ID. Phew...

Yes, it appears that buff icons (at least, those I've been using) have added a leading "2" in their icon IDs.

This should be fixed in update <IP_ADDRESS>


Marketplace

Mockups
Debug agent

Clicking Debug button will open a new page in which the user will be able to test the script for an agent

Install agent

Clicking in Install option will open a confirmation popup with a link to download Reconess docker file

Docker link: https://raw.githubusercontent.com/reconness/reconness-agents/master/Dockerfile

Note: If an agent is installed the Install link will change to Uninstall
Uninstall agent

Clicking in uninstall will open a confirmation popup

Once user confirm the unistall, the text in the Uninstall link will change to Install again.

Details agent in Marketplace

Clicking Details option will open or close an small popup with more description about the agent in the marketplace

Debug agent is working as expected

Intall agent is working as expected

Agent details in marketplace

Debug agent is working as expected

Intall agent is working as expected

Agent details in marketplace


Add twitter feed to Life at the Ridge section

Redesign the Life at the Ridge section to accomodate pictures and/or a twitter feed.

https://dev.twitter.com/web/embedded-timelines#customization


How to forward  low level grpc headers  for a  grpc to grpc spring gateway

I'm opening this issue as I could not find any documentation or samples on how to forward grpc headers as I'm getting Unauthorized error even after doing authentication.
Bug report
Using spring cloud gateway version 3.1.0
server:
  port: 9443
  http2:
    enabled: true
  ssl:
    key-store-type: PKCS12
    key-store: classpath:tls.p12
    key-store-password: ****
    #key-password: password
    key-alias: servercert
    enabled: true

spring:
  cloud:
    gateway:
      routes:
        - id: grpc
          uri: https://<hostname>:443
          predicates:
            - Path=/**
          filters:
            - AddResponseHeader=X-Request-header, header-value
      httpclient:
        ssl:
          useInsecureTrustManager: true
~

Closing this issue, as I got it working.


New blocks drawer: Block names are cut-off

Bug Report

On certain screen sizes (which happened to be the size of my macbook+browser, rip), the block names in the new block drawer are cut-off. Those should always be readable, especially for sensible names (my names aren't too long)
Payload version: 1.6.22

I agree. Cards could likely be bigger too, we will address.

Hi! @JarrodMFlesch and @AlessioGr
I just created a very small PR to improve the UI/UX of this specific problem. I suggest that on larger screens, instead of fitting 8 columns per row, maybe 6 columns is a better size.
But even in such cases when the block name is too long that it gets cut off, I added the title attribute to the card so that when you hover it gives you the full name regardless of size.
I hope that's good enough!


vpp_unittest: implement unittest for ProAmp

mplement unittest for ProAmp, testing hue, saturation, brightness
and contrast.
unittest for #629
Signed-off-by: wudping<EMAIL_ADDRESS>

updated according comments, please help review.

this patch is based on pull-request 681

lgtm +1


Need Azure AD MFA login support

SQL Operations Studio Version: sqlops 0.23.6 (8a3011756318a2ded1e6e84332230a2b2bf9c544, 2017-11-06T21:51:43.232Z)
OS Version: Windows_NT x64 10.0.16299

Steps to Reproduce:

Launch SQL Ops Studio
Try to login to an Azure SQL DB that uses Azure AD MFA for authentication
Notice the option is not available.
Close SOS and return to SSMS.

@paschott  Let's use https://github.com/Microsoft/sqlopsstudio/issues/13 as the tracking issue.


fix: display all deployed contracts

The result was constrained to only those contracts returned by the module. It now returns all contracts and contractAts that have been deployed in this run and previous runs.
The ignition-helper now takes the responsibility of resolving the modules results to contracts (and only the result contracts).
Note the types have not been altered.
Resolves #480.

I am unsure of this change. Currently deploy returns a deployment result. That deployment result type encodes the return results of the module passed in.
That misled us, I think the deployed contracts should include the contracts, librarys and contractsAts that are deployed in the module and its submodules.
This PR expands the returned results to include those contracts in submodules. However, I have not changed the type.
I think there are two approaches we can consider:

return all the contracts (but don't change the type) - as this PR does
change the type of the deploy result to not encode the module return, but insist on encoding it for the deploy function of the ignition-helper