The plugin for Nuxt 3 seems to slower than the plugin for Nuxt 2

Versions

nuxt: 3.0.0
@nuxtjs/prismic: 3.0.0-rc.2
node: 16.17

Reproduction
Both projects are here :
https://gitlab.com/maltcommunity/public/singapore-prototypes/-/tree/master/prismic-nuxt-2
https://gitlab.com/maltcommunity/public/singapore-prototypes/-/blob/master/prismic-nuxt-3
Steps to reproduce
We encountered performance issues since our migration to Nuxt3 and we suspect the prismic module.
When running the projects above, we log the time on both version to query a prismic document
To reproduce, just checkout the projects, run npm install and then npm dev
What is Expected?
Time should be equivalent in both version
What is actually happening?
Time are quite different

With nuxt3, the time is significatively slower

I'm not sure this is related to nuxt so I'll post an issue on prismic client also

Hey there, thanks for opening an issue, and thank you so much for the comprehensive reproduction, I was able to reproduce it!
Indeed, with this setup, it appears that @prismicio/client version 5 is *faster* than @prismicio/client version 7. However, when turning on the modern option on Nuxt 2 module, we now see comparable results:

So why the modern option on Nuxt 2?
When not using this option, @prismicio/client version 5 gets inited using an old, deprecated, and not feature-full method that can cause issues with previews namely. The modern option initializes the client in a more modern way/feature-full way.
With all of that in mind, maybe you can try running your Nuxt 2 application with the modern option turned on so that you can maybe confirm if Prismic is indeed your performance bottleneck?
While biased, I think 100ms is a decent API response time that shouldn't represent a bottleneck in such application(?)

Our current application is using nuxt 3, not nuxt 2 and I'm not looking for the same performance penalty :) I'd like on the contrary the have the performance I used to have in the previous app.
In this example, it vary within the range 100/200ms. But on real use case with more complex slices the variation is more in the range 500/900ms. With our old version, it was in the range 30/70ms. The difference is quite huge
I don't seen the parameter "modern" in the nuxt 3 plugin https://v3.prismic.nuxtjs.org/configuration
Do you confirm it does not exist anymore ?

Our current application is using nuxt 3, not nuxt 2 and I'm not looking for the same performance penalty :) I'd like on the contrary the have the performance I used to have in the previous app.

Yes, my suggestion was to confirm that turning on modern in the old application resulted in the same performance issues that you experience in the new application.

In this example, it vary within the range 100/200ms. But on real use case with more complex slices the variation is more in the range 500/900ms. With our old version, it was in the range 30/70ms. The difference is quite huge.

Interesting, are you able to provide a more performance-heavy call example (just the query, I can update it manually in the reproduction). It might help exacerbate the less-performant part of the code for further troubleshooting.

I don't seen the parameter "modern" in the nuxt 3 plugin v3.prismic.nuxtjs.org/configuration

Indeed, the modern option is for Nuxt 2 only (the Nuxt 3 module is only "modern" so to say, not legacy)

To summarize.
Here is the result with the original setup in the repository
Nuxt 3

Nuxt 2

It's approximatively 334% of performance degradation.
With Nuxt 2 and modern option activated, indeed we have the same degradation :

In "real" conditions within our application the performance of prismic is quite different as you can see in this flamegraph :

I don't know exactly how to isolate the problem in the public repository because I still don't know what's causing this.
In the flamegraph (made with datadog) there is not details in the green line about prismic

We will try to create the same flamegraph on the old application
Currently, I can only time the whole response time from the server
With nuxt 3

With nuxt 2

The time is, in average, 2x slower.
The website content is exactly the same, slices are identicals.
Calls to prismic are already parallelize as we can see in this flamegraphs, they don't sum up

We continue to investigate

OK, thanks again for sharing the details! Let me know if you happen to find anything else.
I'll check internally on our end if we can find anything tied to your specific project.

Hi,
For previews, we still use the standard client. We may use webhooks  to evict the cache.
About the API, yes I really don't know why I have those differences in both versions. You're right, it's the same API, the same content. It's really weird and I don't understand.
Even if, maybe we would have had the same performance in our previous app with modern:true. We tested that on the small project but we didn't tried on the old app. I'll test it today.

Closing this one as I think it has been overall answered
tl;dr; client seems to be working as expected when it comes to timing between Nuxt 2 and Nuxt 3 versions, or it is an upstream issue.

@hlassiege Hi! We also encountered the same problem. Did you find another solution?

@OlgaLookina we had to create a proxy to cache the answer from prismic.
We never found a good builtin solution with prismic itself.


Endpoint crashes, RC 137: IO fails when download, upload operation using same bucket

Environment info

NooBaa Version: master-20210701
Platform: OCP 4.6.16

Actual behavior

IO failing when multiple downloads / download and upload from same bucket is attempted

Expected behavior

IO should not fail

Steps to reproduce

Created 3 users. Attempted to read same file from all 3 users. IO started for few minutes but immediately failed for all 3 users.

I have done 3 instances of runs. Please find all logs captured from the crashed endpoints.

In 2nd run, I attempted upload + download for 3 users
In 3rd run, attempted upload from user 1 + download from user2

Various errors come on App-server CLI:
download failed: s3://bucket-1/file_30gb to ./file_30gb_u1 An error occurred (503) when calling the GetObject operation (reached max retries: 2): Service Unavailable

fatal error: An error occurred (503) when calling the HeadObject operation (reached max retries: 2): Service Unavailable

upload failed: ./big_file_2 to s3://bucket-1/big_file_2 An error occurred (503) when calling the UploadPart operation: Service Unavailable

2021-07-02 07:32:45.904032 [PID-8/TID-16] Jul-2 7:32:45.904 [Endpoint/8]    [L0] core.sdk.namespace_fs:: NamespaceFS: read_object_stream completed { num_bytes: 8388608, num_buffers: 1, avg_buffer: 8388608, log2_size_histogram: { '23': 1 } }
[L1] FS::FSWorker::Execute: FileClose _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb _wrap->_fd=422 _uid=5001 _gid=8002021-07-02 07:32:45.904129 [PID-8/TID-17]  _backend=GPFS
[L1] FS::FSWorker::Execute: FileClose _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb _wrap->_fd=411  took: 2021-07-02 07:32:45.904135 [PID-8/TID-8] 0.072662 ms
[L1] FS::FSWorker::Begin: FileClose _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb _wrap->_fd=39
2021-07-02 07:32:45.904306 [PID-8/TID-16] [L1] FS::FSWorker::Execute: FileClose _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb _wrap->_fd=422  took: 0.01196 ms
2021-07-02 07:32:45.904341 [PID-8/TID-16] [L1] FS::FSWorker::Execute: FileClose _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb _wrap->_fd=39 _uid=5001 _gid=800 _backend=GPFS
[L1] FS::FSWorker::Execute: 2021-07-02 07:32:45.904420 [PID-8/TID-16] [L1] FS::FSWorker::Execute: FileClose _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb _wrap->_fd=39  took: FileClose _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb _wrap->_fd=416 _uid=0.053281 ms
5001 _gid=800 _backend=GPFS
2021-07-02 07:32:45.904484 [PID-8/TID-15] [L1] FS::FSWorker::Execute: FileClose _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb _wrap->_fd=416  took: 0.011611 ms
2021-07-02 07:32:45.905523 [PID-8/TID-8] [L1] FS::FSWorker::OnOK: FileRead _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb
2021-07-02 07:32:45.916572 [PID-8/TID-8] [L1] FS::FSWorker::OnOK: FileRead _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb
2021-07-02 07:32:45.926365 [PID-8/TID-8] [L1] FS::FSWorker::OnOK: FileRead _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb
2021-07-02 07:32:45.935788 [PID-8/TID-8] [L1] FS::FSWorker::OnOK: FileRead _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb
2021-07-02 07:32:45.944345 [PID-8/TID-8] [L1] FS::FSWorker::OnOK: FileRead _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb
2021-07-02 07:32:45.951363 [PID-8/TID-8] [L1] FS::FSWorker::OnOK: FileRead _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb
2021-07-02 07:32:45.986753 [PID-8/TID-8] [L1] FS::FSWorker::OnOK: FileRead _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb
2021-07-02 07:32:46.008458 [PID-8/TID-8] [L1] FS::FSWorker::OnOK: FileRead _wrap->_path=/nsfs/nsfs-nsr-1/bucket-1/file_30gb
/noobaa_init_files/noobaa_init.sh: line 74:     8 Killed                  $*

######################################################################
Fri Jul  2 07:32:46 UTC 2021 NooBaa: Process exited RIP (RC=137)
######################################################################

More information - Screenshots / Logs / Other output

all_runs.tar.gz

I have taken build master-20210718 and IO errors are still happening. Uploading must-gather logs.

noobaa_diagnostics_1626670154.tar.gz

@akmithal With the new resources requests, does it still reproduced?

With the resources defined as "CPU:2" and "Memory:3GB" for noobaa endpoint pods, this bug is resolved.
It is mandatory to have all configurations defined this way for HPO runs.


ARTEMIS-2103 - use the full openwire consumer queue for the mapped vi…

…rtual topic queue binding, fix and test

going to try again, the tests that fails is lease.tryAquire/renew which seems to be b/c it happens in the same millisecond. Will work on a fix for that.

I've locally built Artemis from this branch and it's looks, that with this fix virtual topics are working as expected.


onclick - copy to clipboard

when I click on a point on the chart (like in the example below) I want to automatically copy the result's value into my clipboard.

Note: this feature will be ON by default, but we can switch it off in the config
new KeenDataviz({
// some props

utils: {
  clickToCopyToClipboard: false,
}
})

released in v.3.11.0


Can't Detect Person when person walk too fast

hi, thanks for sharing this code. its really useful for me. but i have problem. when i try walking fast sometimes the application not detect the person. what make that happen?
is there any settings to prevent that?

Hi, Could you share more details?

What camera are you using? e.g., Webcam, IP cam etc
What position/angle is your camera setup? e.g., Is the position similar to the test video file/demo?
Did you try/test threading? https://github.com/saimj7/People-Counting-in-Real-Time?tab=readme-ov-file#threading


Is there a way to install this on real hardware instead of running it from a external medium?

This is a serious question and I'm planning to do it

Do you mean install it on your hdd/ssd rather than run it from a flash drive?
I that case, I have no idea. You could dd it on the partition like you would on a flash drive probably.
Maybe it'd work. If you want to be reckless, enjoy :) Don't forget to back up and all.

I have already gived it a try on a Pentium 3 - 933Hz real vintage hard ware. Finally It works ! It is a tetris game on 80x25 text display . It's interesting! But,

Because there isn't floppy drive (and nether floppy), i try it with grub to boot the floppy image file - Tetos.img . But it failed to boot ( and display "Disk read error ! ") , even i recompiled to get new image the error still the same. I think its boot code seems not compatible with grub.
I rewrote a protected mode boot loader floppy image (originally by John Fine http://wiki.osdev.org/bootf ) and put the ./tetris/kernel/kernel.bin into the image.  And boot with grub again finally it works. Bare matel without any OS , merely tetris.

Dude. Nice.


fix: Correct image path to resolve 404 error

Description
This PR fixes a minor typo in  the image filename "margherita_pizza.png." The typo caused a 404 error when the image is accessed through its absolute path. This commit addresses the issue by renaming the image file to "margherita-pizza.png" to match the correct filename. The issue was identified during testing and reported by @bdougie.
What type of PR is this? (check all applicable)

[ ] 🍕 Feature
[#11 ] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Related Tickets & Documents

Mobile & Desktop Screenshots/Recordings

Added tests?

[ ] 👍 yes
[ ] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[ ] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?


Can you share your weights files?

Hi jkjung,
I have also train my custom yolov4 on this dataset, but can not achieve with good performance. Could you share your weights files for 608x608? I would like to continue my training on your works, thanks a lot in advance!

Please provide a place (say, Google Drive) for me to upload the weights.  It's about 245MB in size.

Please provide a place (say, Google Drive) for me to upload the weights. It's about 245MB in size.

Yep, Google Drive would be fine. thank you so much for such quick reply :) :+1:

Nope, my Google Drive doesn't have much space left.  I need you to provide a place for me to upload the file.

Nope, my Google Drive doesn't have much space left. I need you to provide a place for me to upload the file.

Sorry i didn't get it. I have create a share folder on my Google Drive and there should be more than 1GB space. You could use it with the link here

Done.  I have just uploaded "yolov4-crowdhuman-608x608_best.weights".

Done. I have just uploaded "yolov4-crowdhuman-608x608_best.weights".

@Tsings04 Could you share the  weights files for 608x608？ Thanks~


Refactor access log for server.HttpProtocol

Extract a single logging function to:

remove code duplication,
allow customization of the access_log(response) method if one needs additional parameters logged (transaction IDs, etc...).

@piotrbulinski thanks for the PR! Can you resolve the conflicts?

@r0fls done


Proposal: add INSTALL/EXPORT commands to Dockerfile

With #31257 and #32063 it has become possible to declare more complicated build flows using Dockerfiles. Resources can be built as part of one image and reused in the next build stage.
For example, let's say I need golang in my image. I could use golang official image but I need other things in the image as well, golang is only one dependency.
With #32063 I can write:
FROM debian:jessie AS install-golang
ARG GO_VERSION 1.7.5
ARG GO_PKG_URL https://golang.org/dl/go${GO_VERSION}.linux-amd64.tar.gz
RUN apt-get update && apt-get install -y curl
RUN curl -fsSL $GO_PKG_URL | tar -xzC /usr/local

FROM debian:jessie
...
# install golang
COPY --from=install-golang /usr/local/go /usr/local/go
ENV GOPATH /go
ENV PATH /go/bin:/usr/local/go/bin:$PATH
# install other stuff
....

The benefit of writing it like this is that the only time the cache for golang installation block would get reevaluated is if some instruction changes in that block, go version args get changed or the base image has been updated.
This is great! But. If your image gets more complicated it becomes harder to see what happens when golang is installed. Some instructions are in install-golang stage but in the main stage you still need to know what directory  you need to copy and what environment variables need to be defined. It would be better if all these instructions could be in the same place. install-golang stage describes how golang is supposed to be installed and anything else can just reuse that description.
Proposed syntax that does the same thing as previous example:
FROM debian:jessie AS install-golang
ARG GO_VERSION 1.7.5
ARG GO_PKG_URL https://golang.org/dl/go${GO_VERSION}.linux-amd64.tar.gz
WORKDIR src
RUN apt-get update && apt-get install -y curl
RUN curl -fsSL $GO_PKG_URL | tar -xzC /usr/local
EXPORT COPY --from=% /usr/local/go /usr/local/go
EXPORT ENV GOPATH /go
EXPORT ENV PATH /go/bin:/usr/local/go/bin:$PATH

FROM debian:jessie
...
# install golang
INSTALL install-golang
# install other stuff
....
#

EXPORT would behave similarly to current ONBUILD instruction. But if ONBUILD runs the commands when something is inherited from the current image, EXPORT commands would execute when the current image is being included inside another. Every Dockerfile command could be used as subcommand except FROM/ONBUILD/EXPORT.
Exports are committed into the image in the same way as current onbuild rules. By the name override rules in #32063, if a build stage with a specific name can't be found an image with that name is attempted to be used instead.
That means that you can push install-golang image and everyone would be able to INSTALL it. Image author can define if their image can be installed and default rules that make sense to be executed on install time.
That means that everyone can use the same code for installing dependencies and benefit from each other's contributions.
For example, we could put export rules inside some official images. If you would try to do the example above on top of alpine it would be quite a bit more complicated. But with the exports defined in the offical image all you need to get golang installed(with best practices and patches) is this:
FROM alpine
INSTALL golang:alpine
...

@tiborvass @dnephin @vdemeester @icecrime @dmcgowan @simonferquel @alexellis

Ping @tianon because this could be YUGE for official images (e.g., the dual purpose of golang for both inheritance and composition).
I really like this design :+1:

My following question is not meant to imply I'm against this idea - it actually sounds kind of cool.  But, I do wonder about something.... my first reaction when I saw this was that people will view this as a way to install more than one thing into their image. For example:
INSTALL mysql
INSTALL httpd
...
CMD mystart.sh

where mystart.sh will start both mysql and httpd. So, with this are we encouraging people to actually run more than one main process in their container?  Granted people can do this today, no doubt, but this seems to move this option to be a first class (and endorsed) idea - which would kind of go against some of the basic ideas behind how we tell people to use containers today.
Another question... what's the main usecase behind INSTALL?  Is it to just make the files from another image available or is it to (sort of) merge build outputs/images?  The other PRs felt like they were there to make files available - this feels more like we're merging build outputs and I'm not sure how conflicting CMD/ENTRYPOINT cmds in the INSTALL'd images would behave.
I say we're merging build outputs since I suspect people will add EXPORT cmds to copy over the key bits of data (meaning the outputs).  Or even just do EXPORT COPY --from=% * /, or something like that  :-)
Changing the order would influence the end result.  If the main usecase is to just make files available we may want to consider banning CMD/ENTRYPOINT (perhaps others?) being EXPORT'd since I'd prefer for the order of INSTALL's to be (as much as possible) irrelevant.  Plus, if people really want to pick-up the CMD/ENTRYPOINT from another image they really should consider using FROM instead of INSTALL. This would also enforce the idea that this is just for making files available, not merging of build outputs.
And, this would require people to examine the INSTALL'd image's Dockerfiles to see what commands are going to be done in their image - perhaps install untrusted users? I guess a lot of these same concerns were there for ONBUILD too.

So, with this are we encouraging people to actually run more than one main process in their container?

No, that is not the intent. The intent is to enable sharing of optimized build definitions between build targets and projects, and between Docker users. If you need to run a mysql server you should still use a mysql image for that. But if you need a specific set of dependencies in the image for a program that you run in RUN or CMD this would help you with that.
Maybe it's a term thing and INSTALL has a hint of installing a specific service? We could try something different like IMPORT/INCLUDE.

Another question... what's the main usecase behind INSTALL? Is it to just make the files from another image available or is it to (sort of) merge build outputs/images?

INSTALL lets you define logical separation points for the different parts of your build definition. By defining them correctly user gets several benefits like better cache, efficient execution, better readability and sharing features. Making files from another image available was the use case for #31257

The other PRs felt like they were there to make files available - this feels more like we're merging build outputs and I'm not sure how conflicting CMD/ENTRYPOINT cmds in the INSTALL'd images would behave.

Like ONBUILD this would just execute all the steps defined in EXPORT in place. So RUN would create a layer, ENV has merge semantics, CMD replaces previous value.

I say we're merging build outputs since I suspect people will add EXPORT cmds to copy over the key bits of data (meaning the outputs). Or even just do EXPORT COPY --from=% * /, or something like that :-)

I'm not sure one would do COPY --from=% * / as that would try to start merging 2 full rootfs and that isn't very useful(unless one of them is based on scratch). If you are defining EXPORTs for golang they should contain a minimal set of things to make golang available, you don't want any extra bloat.

Changing the order would influence the end result. If the main usecase is to just make files available we may want to consider banning CMD/ENTRYPOINT (perhaps others?) being EXPORT'd since I'd prefer for the order of INSTALL's to be (as much as possible) irrelevant.

The use case for this is not only to include definitions from existing images. If you have a complicated build case(take docker's own Dockerfile for example) you would want to define these composition points for your dependencies and never push the temporary build stages themselves. I don't see why we should make it complicated and deny some commands just because the are probably less useful(we would deny commands that just don't make sense like FROM/ONBUILD).
I do agree that if you want to put EXPORT in a public image it would be very bad practice to export CMD/ENTRYPOINT in it. Good public EXPORT definitions should make an attempt to be least disruptive for the main build stage and only add the needed bits without colliding anything else if possible.
I forgot to mention in the first post(added now) that when using scratch as a base this can be used like a macro, for generic code sharing between build stages. CMD/ENTRYPOINT could be useful for these cases.
FROM scratch AS setup-env
EXPORT ENV FOO bar
EXPORT VOLUME /foobar

FROM debian
INSTALL setup-env

FROM alpine
INSTALL setup-env

And, this would require people to examine the INSTALL'd image's Dockerfiles to see what commands are going to be done in their image - perhaps install untrusted users? I guess a lot of these same concerns were there for ONBUILD too.

Yes, INSTALL has the same properties as FROM or ONBUILD. You are trusting the definition from the source image into your own image. The source image author has set up a definition that should be used on inclusion to make their software work. If a user wants to make their own decision they can inspect the source image and use COPY --from= or redefine the image metadata manually.
We would not make an attempt to hide the commands that are actually executed behind INSTALL, they should be visible in the build output.

Hmm.... This is a bit complicated.  I very much like the previous two PRs as they are the minimum to do multi stage builds.  I feel this PR might go one step beyond what is needed.  I'd rather see the other two PRs bake for a bit with users and then decide to do a follow on like this.

I think that export and install do not feel related enough. I'd prefer export/import or even better, oninstall/install as oninstall's syntax would be pretty close to the existing onbuild one

I'd prefer export/import

+1, I also think that install is not a good term for the actual behaviour of this feature. The behaviour is much closer to an import.
(personally I've always felt that onbuild was confusing and hard to explain. export/import is a lot more obvious, so would rather avoid adding oninstall)

This is a great idea, and would make things much cleaner for us - we distribute C++ libraries via Docker which themselves often depend on many dynamically-linked libraries and external data files, and all of those dependencies need to be installed correctly in downstream images.
One thing that's not clear to me: is there precedent for the % syntax in EXPORT COPY --from=% /usr/local/go /usr/local/go? If that's new, I'd personally prefer a more descriptive name like THIS or SELF over a sigil like %.

My opinion on this is in line with what @duglin and @ibuildthecloud have already said -- this reminds me a lot of ONBUILD, which is an OK feature, but we're actually looking to remove all onbuild variants from the official images (https://github.com/docker-library/official-images/issues/2076) since they don't offer enough flexibility and end up having a huge maintenance burden in terms of user education.
I definitely agree that multi-stage builds seem to solve this problem better IMO, since just including certain files from another image can be more concretely controlled through that method (and just including a set of pre-defined images from some base image isn't necessarily going to provide everything necessary).

I'd like to separate the discussion about the feature from the question if we would actually want to put the exports in the official images. The use case is to provide logical separation points between build stages. As build stages map to images it wouldn't make sense to not support images directly as there are some powerful use cases there.
I don't know if having the exports in official images is worth the maintenance cost or if it should only be left for 3rd parties or if there should be a community org that would manage these "importable images". If I would just like to use this feature that question doesn't look very critical.

There is also one potential issue:
if you have an image foo built like that:
FROM scratch
EXPORT ENV path /foo

and a bar like that:
FROM scratch
EXPORT ENV path /bar

Their would be some kind of conflict in this dockerfile:
FROM scratch
INSTALL foo
INSTALL bar

This might be recoverable on install site with this syntax though:
FROM scratch
INSTALL foo
INSTALL --env-prefix=bar_ bar
ENV path $path:$bar_path

s/INSTALL/IMPORT/

There is also one potential issue

I guess that's not only an issue for ENV, it's also an issue for files when two images export the same path.
You can always fall back to the old method of just setting ENV and COPY without the IMPORT.

@simonferquel @dnephin The exported commands are executed in order so if imported resource conflicts, the last one will win.
FROM scratch
EXPORT ENV path /foo

FROM scratch
EXPORT ENV path /bar

FROM scratch
INSTALL foo
INSTALL bar

is same as
FROM scratch

@simonferquel @dnephin The exported commands are executed in order so if imported resource conflicts, the last one will win.
FROM scratch
EXPORT ENV path /foo

FROM scratch
EXPORT ENV path /bar

FROM scratch
INSTALL foo
INSTALL bar

is same as
FROM scratch
ENV path /foo
ENV path /bar

The imported stage should make an effort not to run anything that can conflict. For the example above these stages should instead use
FROM scratch
EXPORT ENV PATH $PATH:/foo

so that the import only appends to path and doesn't override it.

Hmm, then we would have to change the way we parse dockerfiles to make variable references parsing behavior depend on the current command.

@simonferquel If we do EXPORT as ONBUILD is currently implemented then the command would not even be parsed(not sure if this is actually good, looking at buildkit). The unparsed command is moved from image to the final stage and executed there.

We discussed this proposal in the maintainers meeting. The feedback here and from the base multi-stage feature has been positive so far and no issues were raised at the meeting as well. We'll give it 2 more weeks to make sure everyone has time to see this and if no significant problems appear the proposal will be accepted after that and someone can start implementing it.

The feedback here and from the base multi-stage feature has been positive so far and no issues were raised at the meeting as well.

I imagine most feedback concerning multi-stage feature has been positive and although I've been a proponent for an implementation involving multiple FROMs, I've documented my concerns regarding its current encoding, specifically the ability of COPY --from and RUN --mount to reference build stages or other images.  In a nutshell, should COPY embody the concerns of both mounting a file system and copying files or be strictly limited to simply copying files as in the case of its *nix cousin cp?   Read #33206 for a more detailed discussion concerning this and other issues.

EXPORT COPY --from=% /usr/local/go /usr/local/go

Since IMPORT doesn't support a mapping mechanism, to redirect the destination file path: /usr/local/go to a different path, every need to import golang to a different target directory would require replicating almost the entire body of the FROM just to change the destination path /usr/local/go to match the necessary one.
Think of file paths as purely parameters that when invoked are bound to their arguments.   In the snippet above /usr/local/go represents a parameter that with a flexible mapping mechanism could be redirected, at the instant it must be bound, to /usr/go.

EXPORT COPY /bin/go    /usr/local/go
In the example above, what does /bin/go bind to?

The file system defined by its associated FROM?
The Dockerfile Build Context?

In a nutshell, should COPY embody the concerns of both mounting a file system and copying files or be strictly limited to simply copying files

COPY only copies files between source and destination, --from lets you pick another source location. It doesn't modify any behavior of COPY.

every need to import golang to a different target directory would require replicating almost the entire body of the FROM just to change the destination path

If the user wants to modify the path they will never use IMPORT. If they want to copy resources to a specific path, then this problem is already solved today with plain multi-stage builds. IMPORT is for specifically the case where a user wants to trust the defaults provided by the author of the imported stage instead of customizing it themselves. Exports do support arguments so what you are describing can be actually done. But a good export should not depend on an argument being defined so it really should only be used with addition pattern like PATH var in the example above.

In the example above, what does /bin/go bind to

Files sent by the user.

COPY only copies files between source and destination, --from lets you pick another source location. It doesn't modify any behavior of COPY.

In an abstract sense, we agree on COPY's semantics but disagree on its implementation.  Must COPY's interface be changed by incorporating --from, in order to introduce new sources?  COPY's <src> argument encodes one or more file paths.  Each file path reference is implicitly and concretely bound to the Build Context "source location".  Incorporating --from adds yet another notion: the image "source location" that exposes its contents via file path references just like the Build Context "source location".  Therefore, why not extend the Build Context to include other "source location"s, like an image's file system, enabling COPY's file paths specified by <src> to ultimately bind themselves to the desired image(s) ("source location"s)?
As in *nix, the Build Context could be extended using a mechanism similar to mount.  mount unifies "source location" types, like a network drive, so it resembles a local file path.  By doing so, it extends the local file system with content from a network resource without exposing the network drive abstraction enabling processes to bind to network resources using simple, local file paths.  mount's ability to unify "source location" types by reforging them as local file paths eliminated the necessity to encode an analogous option like --from for cp maintaining not only cp's behavior but also its interface.
As mentioned in a prior post, I noticed that you had at least considered mount as #31067 introduced docker build docker://image-reference[::/subdir] enabling an image's file system to be mounted as the Build Context.  However, this approach seems to have been replaced by COPY --from.
Some benefits of implementing Build Context mount separate from COPY --from:

Maintains the Build Context as the principle Dockerfile abstraction supplying source artifacts to a FROM.  Since mount extends this abstraction to include other "sources" this unification simplifies both thinking about Dockerfiles and its syntax to support current or future sources.  Additionally, any future operators added to manipulate the Build Context automatically apply to any other source that's mounted (treated) as a Build Context.
ONBUILD COPY <src> ... source file path can ultimately refer to an image without being explicitly bound to a specific one improving the reusablility of ONBUILD.
Improves Dockerfile orthogonality by decoupling the primitive of mounting a source from the primitive of copying its files.  A separate mount mechanism would simplify both COPY and RUN Dockerfile commands returning their syntax to their pre-multistage form.
Permits a developer to define a static interface using COPY's source file paths that can be rebound via a mount operation to a different source.  This enables reusing the same COPY operation in different execution contexts because it remains exactly the same independent of the source.
Reduces the number of COPY statements, as a single one can incorporate multiple "sources".
Leverages existing *nix cp and mount experience to accelerate Dockerfile coding.

If the user wants to modify the path they will never use IMPORT.

Ok.

Exports do support arguments so what you are describing can be actually done. But a good export should not depend on an argument being defined so it really...

Since EXPORTed instructions of an IMPORT share the same namespace of their enclosing Dockerfile, an EXPORTed arg utilized by some FROM that happens to share the same arg name as one defined within an IMPORT can overlap.  This overlap can either be considered as intentional or conflicting.  Intentional overlap enables coupling of identical arg names that by design share the same lexical values and semantics.  Meanwhile, a conflicting overlap occurs when the arg values for shared arg names fail to match either lexically or semantically.  For example, an arg named PORT used by an IMPORT might semantically refer to a host port number whose values are lexically represented by integers, while PORT within the consuming Dockerfile semantically refers to the name of a shipping harbor with a lexical value, such as the "Port of NY".  Unfortunately, a conflict currently requires changing the implementation of the Dockerfile, changing an IMPORT's definition and any other Dockerfile that references this IMPORT, or copying the IMPORT's definition within a Dockerfile and changing its statements to bind to the Build Context file paths and arg names used by the enclosing Dockerfile in order to reconcile a conflict.
This inability to resolve a namespace conflict without resorting to one of methods mentioned above (that alter implementation) is a symptom of a more fundamental issue: the omission of both argument scoping and argument to parameter mapping mechanisms.  Without these mechanisms, arg names intimately (pathologically) couple to any code that includes them. Therefore, attempts to change an arg used in an EXPORT rapidly becomes daunting, as this change will either loudly or silently break code in Dockerfiles that include it via an IMPORT.  In fact, given the difficulty in assessing the impact of a changed EXPORTed arg name on all the Dockerfiles employing its IMPORTed image, developers will be encouraged to define IMPORTed images local to a single Dockerfile.  This limits IMPORT's usage to the same Dockerfile that it's defined in, diminishing IMPORT reusability while promoting its replication via copy'n paste to other Dockerfiles, instead of referencing a single shared instance of it.
In addition to IMPORT's stated purpose, the binding concerns mentioned above suggest one should ardently avoid using args in an EXPORTed instruction not only when employing args as a means to define the binding of COPY <src> <dst>'s destination file path but also in other cases, such as defining the value for an ENV.

Files sent by the user.

I'll interpret this reply as the source /bin/go in COPY /bin/go ... binds to the Dockerfile Build Context.
Given the stated purpose of IMPORT: "IMPORT is for specifically the case where a user wants to trust the defaults provided by the author of the imported stage instead of customizing it themselves." why not limit the binding of all <src> in EXPORT COPY <src> ... to the file paths of the image being EXPORTed?  The current EXPORT behavior of binding simple file paths, like /bin/go, to the Dockerfile Build Context allows Build Context artifacts to customize the ones contributed by the EXPORTed image.  Since this behavior opposes IMPORT's purpose, shouldn't binding file paths be scoped to the image being EXPORTed?
If file path binding for EXPORT becomes limited to the file system of its associated FROM then COPY's --from option is no longer necessary when encoding EXPORT(s).  Therefore, the added complexity of specifying --from with a special binding operator: % becomes a concern implemented by builder instead of one solved by developer coding, thereby improving the developer's experience.
Finally, allowing file path binding outside the file system defined by the EXPORTed FROM can induce the same namespace conflict when resolving EXPORT COPY source file paths as cited by the arg discussion above with all the same pathologies.

+1

It is a very nice example of the

ABSOLUTELY NEEDED
very trivial, easy-to-implement
very obvious

developments, what

won't be ever developed,
you won't ever know, why.


Unpin NetCDF4

Description

Unpin netcdf4 to free since we have repo patched iris with <1.6.1

Closes #2907 #2924

Before you get started

[x] ☝ Create an issue to discuss what you are going to do

Checklist
It is the responsibility of the author to make sure the pull request is ready to review. The icons indicate whether the item will be subject to the 🛠 Technical or 🧪 Scientific review.

[x] 🛠 This pull request has a descriptive title
[x] 🛠 Any changed dependencies have been added or removed correctly
[x] 🛠 All checks below this pull request were successful

Hi @valeriupredoi,
Looks good to me! I simplified the title of the pull request because it feels more readable to me (in the changelog) to have the explanation in the description rather than in the title. Is that OK with you?

sure thanks @bouweandela :beer: @ESMValGroup/technical-lead-development-team can one of you pls merge :beers:


Can it be extended with markdown-it plugins?

Hi there,
i would like to know whether, resp. how, the editor can be extended with existing markdown-it addons. I'm especially missing the following two features:

Using tables (don't know why they don't work, but they aren't rendered in the demo)
Admonitions

Any Ideas how i can make them work? :)
Thanks :)

* Using tables (don't know why they don't work, but they aren't rendered in the demo)

* [Admonitions](https://www.npmjs.com/package/markdown-it-admonition)

Any Ideas how i can make them work? :)
Thanks :)

* Using tables (don't know why they don't work, but they aren't rendered in the demo)

In the settings of the plugin EsayMDE you can add "table" to the field "Toolbar".

* [Admonitions](https://www.npmjs.com/package/markdown-it-admonition)

Here is the documentation of the editor EasyMDE:
https://github.com/Ionaru/easy-markdown-editor

@Ionaru any ideas on this? :)

The default renderer can be competely overridden with the previewRender option. You can use any renderer instead of the default marked package.

Thanks for your answer. So you mean, it's not a question of extending your editor, but about how to extend the marked library?

Yes, you can extend marked, but you can also just grab markdown-it, extend it with the plugins you want and use it in the previewRender function. :)
For example:
const md = window.markdownit()
    .use(plugin1)
    .use(plugin2);

const easyMDE = new EasyMDE({
    previewRender: (text) => {
        return md.render(text)
    },
});

Ah, thank you :) I'll try it :)


Process network data in platform-input-support

Platform input support has a new step called "interactions".
Interactions step generates/gets the data from strings and intact and transform them in order to be used by ETL.
Moreover, this step generates/gets the mapping files. Eg. protein mapping, ensembl human mapping.

Deployed first release for this resource.
*) Platform-input-support: step interactions with two modules: Intact and String Interaction
To do:
move string threshold to ETL
use the json schema that Daniel wrote
*) ETL: step interactions.

A first release of "network" that was recalled "interactions" was already deployed for the alpha and beta-release.
PIS is generating the input file for the ETL.

Done.


Peering Request

Full Name
serve-u Buchholz & Sünderhauf GbR
ASN
13058
PeeringDB Integration

[X] My PeeringDB Entries are current
[ ] Peer at ALL EXCHANGES (and skip the Peer Address(es) field below)

Peer Address(es)
2a0c:7286:2736::66
<IP_ADDRESS>
Greetings to hak from csch! 😉
Multihop

[X] Multihop Peering Request

Code of Conduct (TODO)

[X] I agree to follow this project's code of conduct

Our side is up:
    Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
    <IP_ADDRESS>   4      13058         0         0        0    0    0    never       Active        0 serve-u - Buchholz
    Neighbor                              V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
    2a0c:7286:2736::66                    4      13058         0         0        0    0    0    never       Active        0 iserve-u - Buchholz

Our details
  ip4:  <IP_ADDRESS>
  ip6: 2001:468:d01:33::80df:3369
  asn: 6447
  fqdn: route-views5.routeviews.org

Please filter out default route, null routes, RFC1918 routes,
and note that we currently do not allow add-path as a
capability during connect.
Thanks for peering with RouteViews!


Inconsistent Output between LightLLM and Transformers Inference Library

When specifying 'max new tokens', LightLLM's output consistently matches this maximum value. However, Transformers sometimes adjust according to the model itself, resulting in outputs shorter than the specified 'max new tokens'. I believe Transformers is correct in this approach. It's implausible to always generate output exactly matching the maximum 'max new tokens' value, as this would only lead to repetitive outputs.

@Lvjinhong You can specify the stop token ID by setting the --eos_id xxx argument when starting the server or by using the stop_sequences parameter in the request parameters

@Lvjinhong You can also check  if your input is spliced with the correct prompt. lightllm doesn't splice prompts on inputs, while transformers usually splice prompts on inputs in their chat functions.


docfix: "cals" -> "calls"

fix spelng.

Unfortunately we don't accept changes to the service models as we pull these documents from upstream.


QCSpec table migration on procedure tables(optimization_procedure, grid_optimization_procedure, torsiondrive_procedure)

Description
The biggest change comes in the alembic migration file while sqlalchemy_socket.py has also seen some small changes due to the new migration. A new table qc_spec and its corresponding ORM class QCSpecORM have been created and the qc_spec json column in the procedure tables have been switched to an integer column pointing to the specification in the qc_spec table. A new private function _add_spec is added to as well to help the addition of specifications. The test files test_sqlalchemy.py also had to receive minor changes since the construction of procedure ORM class requires construction of a QCSpecORM object - since its id will be used- beforehand.
Warning: Two of the changes on test_collections.py are not related to the changes done in this PR, and are only done to reflect the master changes.
Important: Since get_procedures had to be changed to accompany the ease of getting and updating a procedure in two lines, some performance testing might be good to check if we can observe heavy query costs or not.
Changelog description
This is a large change due to the volume of the migrations ready to be exectued. Briefly, a new table qc_spec has been created, the qc_spec column of the procedure tables have changed to reference columns to point to a specific row in qc_spec and also some inevitable changes to the test had to be performed accordingly.
Benchmarks

add/get procedure
Before(total / avg)
After (total / avg)
Num trials

add
17.689 / 17.689
25.122 / 25.122
1

get
4.936 / 4.936
5.984 / 5.984
1

add
103.831/ 10.383
125.761/ 12.576
10

get
7.038 / 0.704
8.986 /  0.899
10

add
1057.561/ 10.576
1162.054/ 11.621
100

get
30.550/  0.306
35.585 / 0.356
100

add
5483.121/ 10.966
5938.493 / 11.877
500

get
148.964 / 0.298
164.594/  0.329
500

add
11144.793/ 11.145
11877.745/ 11.878
1000

get
239.103/  0.239
296.329/  0.296
1000

All the numbers are in milliseconds.
Status

[X] Code base linted
[x] Tests for QCSpecORM class(esp. _add_spec)
[x]  Benchmark for the new get_procedures function
[x] Commenting and cleaning up
[x] Ready to go

This is being a bit subsumed by a big refactor  happening in next. I have a local copy of this branch so will be rebasing/cherry picking these changes into there at some point. So closing this PR.


feat: app version header - react

Available at:
https://c6af-2001-56a-f900-a100-5db2-dac-bf9d-d389.ngrok.io/?path=/story/experimental-components-appversionheader--app-version-header

:tada: This PR is included in version 1.0.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 4.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Is is possible to dynamically add a Layer object?

Hello!
I have a Geosuggestion searchbox that returns a set of coordinates. I'd like to be able to press a button, and add a marker at those coordinates to an already instantiated map. However, I'm not seeing addLayer() defined in the docs. Is there a workaround?
Cheers!

Hey, addLayer is abstracted by The Layer component, you will need to mount a Layer component with a Feature component for each marker. Have a look at the London cycle example.

Hey, thanks for the quick reply!
I guess I'm not seeing it. When I read through the London cycle example I see the Layer and Feature components are static. They're instantiated with the map. What I'm trying to do is have a button that when clicked, adds a marker at a set of coordinates to an already instantiated map.
The worst, hackiest way I can see doing this is to re-instantiate the map every time  a user adds a marker. However, that feels wrong.
Sorry if I'm not seeing it. But thank you for your help!

you can have a loop inside your component (that houses the Map component instance) that renders out layers inside of your Map component instance in a loop.

Excellent! Thank you guys!

Hey @chrabyrd !
I am currently building an open-source tool using the react-mapbox-gl library and I have to dynamically add a Layer object along with its Feature object to the map. The context is that users add themself to an array and their default location are set on the fly, meaning that a movable* marker as to be placed on the map.
I see that you closed this issue a while ago. Is there any chance you have some snippets for me to achieve my goal quickly? Deliverable is for next week :smile:
Thank you for your time!
* movable : the user can drag and drop the marker on the map to update their coordinates
_____
As this issue is quite old and the library keeps getting updates, I am also mentioning @alex3165 for any appreciated input!


Can't harvest the old repo

I've tried harvesting http://lindat.mff.cuni.cz/repository/oai/request first with DIM see #1035 for the result; then just the simple dublin core
Feb 20 10:55:13 repository-new env[19763]: 10:55:13.211 [dspaceRunnableThreadExecutor-1] ERROR org.dspace.harvest.OAIHarvester - Error occurred while generating an OAI response: Index 0 out of bounds for length 0 null
Feb 20 10:55:13 repository-new env[19763]: java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
Feb 20 10:55:13 repository-new env[19763]:         at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) ~[?:?]
Feb 20 10:55:13 repository-new env[19763]:         at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) ~[?:?]
Feb 20 10:55:13 repository-new env[19763]:         at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) ~[?:?]
Feb 20 10:55:13 repository-new env[19763]:         at java.util.Objects.checkIndex(Objects.java:359) ~[?:?]
Feb 20 10:55:13 repository-new env[19763]:         at java.util.ArrayList.get(ArrayList.java:427) ~[?:?]
Feb 20 10:55:13 repository-new env[19763]:         at org.dspace.content.DSpaceObjectServiceImpl.addMetadata(DSpaceObjectServiceImpl.java:328) ~[dspace-api-7.2.1.jar:7.2.1]
Feb 20 10:55:13 repository-new env[19763]:         at org.dspace.content.crosswalk.OAIDCIngestionCrosswalk.ingest(OAIDCIngestionCrosswalk.java:72) ~[dspace-api-7.2.1.jar:7.2.1]
Feb 20 10:55:13 repository-new env[19763]:         at org.dspace.harvest.OAIHarvester.processRecord(OAIHarvester.java:588) ~[dspace-api-7.2.1.jar:7.2.1]
Feb 20 10:55:13 repository-new env[19763]:         at org.dspace.harvest.OAIHarvester.runHarvest(OAIHarvester.java:395) [dspace-api-7.2.1.jar:7.2.1]
Feb 20 10:55:13 repository-new env[19763]:         at org.dspace.app.harvest.Harvest.runHarvest(Harvest.java:390) [dspace-api-7.2.1.jar:7.2.1]
Feb 20 10:55:13 repository-new env[19763]:         at org.dspace.app.harvest.Harvest.internalRun(Harvest.java:208) [dspace-api-7.2.1.jar:7.2.1]
Feb 20 10:55:13 repository-new env[19763]:         at org.dspace.scripts.DSpaceRunnable.run(DSpaceRunnable.java:104) [dspace-api-7.2.1.jar:7.2.1]
Feb 20 10:55:13 repository-new env[19763]:         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
Feb 20 10:55:13 repository-new env[19763]:         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
Feb 20 10:55:13 repository-new env[19763]:         at java.lang.Thread.run(Thread.java:833) [?:?]

This seemed the easiest way of getting some items into the new installation...

Here is the example how we was able to harvest from the old repo: https://github.com/dataquest-dev/DSpace/wiki/Developing-backend#harvesting

you must have a collection where you want to harvest the data
set the collection as harvestable
harvest to that collection

And how many items do you get that way? The full set (some 2160 items) or just a few (I've got 115 before it died...)
I was setting it up and starting it through the UI...

Seems that I'm getting the same error when following the wiki*
root@fa6521c9efd6:/dspace/bin# ./dspace harvest -r -c 123456789/2 -a http://lindat.mff.cuni.cz/repository/oai/request -i hdl_11234_3430 -m dc -t 1 -e<EMAIL_ADDRESS>The script has started
Running: a harvest cycle on 123456789/2
Initializing the harvester...
Initialized the harvester successfully
Harvest started...
Harvest complete.
The script has completed

that seems ok but the dspace log has:
tail -n 500 ../log/dspace.log | more
2023-03-03 12:16:40,228 ERROR unknown unknown org.dspace.harvest.OAIHarvester @ Error occurred while generating an OAI response: Index 0 out of bounds for length 0 null
java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
        at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) ~[?:?]
        at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) ~[?:?]
        at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:266) ~[?:?]
        at java.util.Objects.checkIndex(Objects.java:359) ~[?:?]
        at java.util.ArrayList.get(ArrayList.java:427) ~[?:?]
        at org.dspace.content.DSpaceObjectServiceImpl.addMetadata(DSpaceObjectServiceImpl.java:328) ~[dspace-api-7.2.1.jar:7.2.1]
        at org.dspace.content.crosswalk.OAIDCIngestionCrosswalk.ingest(OAIDCIngestionCrosswalk.java:72) ~[dspace-api-7.2.1.jar:7.2.1]
        at org.dspace.harvest.OAIHarvester.processRecord(OAIHarvester.java:588) ~[dspace-api-7.2.1.jar:7.2.1]
        at org.dspace.harvest.OAIHarvester.runHarvest(OAIHarvester.java:395) [dspace-api-7.2.1.jar:7.2.1]
        at org.dspace.app.harvest.Harvest.runHarvest(Harvest.java:390) [dspace-api-7.2.1.jar:7.2.1]
        at org.dspace.app.harvest.Harvest.internalRun(Harvest.java:168) [dspace-api-7.2.1.jar:7.2.1]
        at org.dspace.scripts.DSpaceRunnable.run(DSpaceRunnable.java:104) [dspace-api-7.2.1.jar:7.2.1]
        at org.dspace.app.launcher.ScriptLauncher.executeScript(ScriptLauncher.java:149) [dspace-api-7.2.1.jar:7.2.1]
        at org.dspace.app.launcher.ScriptLauncher.handleScript(ScriptLauncher.java:131) [dspace-api-7.2.1.jar:7.2.1]
        at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:98) [dspace-api-7.2.1.jar:7.2.1]

and there are only 115 items harvested
*note I've built my own docker images based on the latest commits

I don't know where is the problem. I tried to harvest the data into a new collection and it has harvested 1243 records. I guess it's not 1720 because of some deleted records in that collection e.g., 11372/LRT-263.
My procedure:
C:\dspace\bin
λ dspace harvest -s -c 123456789/10 -a http://lindat.mff.cuni.cz/repository/oai/request -i hdl_11234_3430 -m dc -t 1 -e<EMAIL_ADDRESS>Using DSpace installation in: C:\dspace
The script has started
Running: configure collection
d8d6833e-ab41-4f8f-987a-e21b66d4fcf2
The script has completed

C:\dspace\bin
λ dspace harvest -r -c 123456789/10 -a http://lindat.mff.cuni.cz/repository/oai/request -i hdl_11234_3430 -m dc -t 1 -e<EMAIL_ADDRESS>Using DSpace installation in: C:\dspace
The script has started
Running: a harvest cycle on 123456789/10
Initializing the harvester...
Initialized the harvester successfully
Harvest started...
Harvest complete.
The script has completed

123456789/10 is a handle of the collection where the records are harvested.

@milanmajchrak thanks for the numbers. Yesterday, it did finish successfully for me too 🤷♂. I'm not sure what has changed and where...
I'll reopen this if it appears again...


zimg: 2.9.2 -> 2.9.3

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://github.com/sekrit-twc/zimg/releases.
meta.description for zimg is: "Scaling, colorspace conversion and dithering library"
meta.homepage for zimg is: "https://github.com/sekrit-twc/zimg"

Quoted meta.homepage for RFC 45

Release on GitHub
Compare changes on GitHub

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 2.9.3 with grep in /nix/store/p8c236s3z2y5cvgvxs8dfcb9354hi6af-zimg-2.9.3

directory tree listing: https://gist.github.com/4c62ad20eca9d1398c06cd974e43c01d

du listing: https://gist.github.com/4be8caa3a78bfd1b5ab2a375ed5c46eb

Rebuild report (if merged into master) (click to expand)

51 total rebuild path(s)
17 package rebuild(s)
17 x86_64-linux rebuild(s)
13 i686-linux rebuild(s)
8 x86_64-darwin rebuild(s)
13 aarch64-linux rebuild(s)
First fifty rebuilds by attrpath
celluloid
curseradio
deepin.dde-file-manager
deepin.deepin-movie-reborn
deepin.startdde
jftui
minitube
mpc-qt
mpv
mpv-with-scripts
plex-media-player
python37Packages.mpv
python38Packages.mpv
vapoursynth
vapoursynth-editor
vapoursynth-mvtools
zimg

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/p8c236s3z2y5cvgvxs8dfcb9354hi6af-zimg-2.9.3 \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A zimg https://github.com/r-ryantm/nixpkgs/archive/2c9cc36b390963905e29f76d9fedcb3a77bd1907.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/p8c236s3z2y5cvgvxs8dfcb9354hi6af-zimg-2.9.3
ls -la /nix/store/p8c236s3z2y5cvgvxs8dfcb9354hi6af-zimg-2.9.3/bin

cc @rnhmjoj for testing.

@GrahamcOfBorg build vapoursynth


ops: add PR template

Description
Share context and information in pull requests (aka PRs) to facilitate and expedite code reviews.
Summary of changes

Added .github/pull_request_template.md

How to review

Any additional sections or checklists to add?
Copy edits to reduce length are welcome

Notes
While PR Templates can be (and often are) ignored, this change is meant to encourage contributors to add more details to their changes.

Tagging @stucka for feedback

Working example here. Works for me. https://github.com/biglocalnews/clean-scraper/pull/71


Create es.json

Spanish translation for your delight and delectation.

Thanks for the translation! Could you please make it independent from others PR and just translate the actual en.json file? I'd like to avoid mixing stuff together ^^

Hi @Anrolosia ! My bad! I was getting ahead of myself. The PR is corrected. If you now accept this, I can include an update to the file in #13


Specify the functionalAccounts.json path for be-next container

Changes from our zoom meeting last Friday.

I am sorry, I must have missed this. Thanks for the change!


Unable to import duckduckgo-search error

INFO:     connection open
ERROR:    Exception in ASGI application
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/uvicorn/protocols/websockets/websockets_impl.py", line 244, in run_asgi
    result = await self.app(self.scope, self.asgi_receive, self.asgi_send)  # type: ignore[func-returns-value]
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/uvicorn/middleware/proxy_headers.py", line 70, in __call__
    return await self.app(scope, receive, send)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/fastapi/applications.py", line 1054, in __call__
    await super().__call__(scope, receive, send)
  File "/usr/local/lib/python3.11/site-packages/starlette/applications.py", line 123, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/usr/local/lib/python3.11/site-packages/starlette/middleware/errors.py", line 151, in __call__
    await self.app(scope, receive, send)
  File "/usr/local/lib/python3.11/site-packages/starlette/middleware/cors.py", line 77, in __call__
    await self.app(scope, receive, send)
  File "/usr/local/lib/python3.11/site-packages/starlette/middleware/exceptions.py", line 65, in __call__
    await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
  File "/usr/local/lib/python3.11/site-packages/starlette/_exception_handler.py", line 64, in wrapped_app
    raise exc
  File "/usr/local/lib/python3.11/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
    await app(scope, receive, sender)
  File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 754, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 774, in app
    await route.handle(scope, receive, send)
  File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 371, in handle
    await self.app(scope, receive, send)
  File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 96, in app
    await wrap_app_handling_exceptions(app, session)(scope, receive, send)
  File "/usr/local/lib/python3.11/site-packages/starlette/_exception_handler.py", line 64, in wrapped_app
    raise exc
  File "/usr/local/lib/python3.11/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
    await app(scope, receive, sender)
  File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 94, in app
    await func(session)
  File "/usr/local/lib/python3.11/site-packages/fastapi/routing.py", line 348, in app
    await dependant.call(**values)
  File "/usr/src/app/backend/server.py", line 89, in websocket_endpoint
    report = await manager.start_streaming(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/app/backend/websocket_manager.py", line 60, in start_streaming
    report = await run_agent(task, report_type, report_source, source_urls, tone, websocket, headers)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/app/backend/websocket_manager.py", line 97, in run_agent
    report = await researcher.run()
             ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/app/backend/report_type/basic_report/basic_report.py", line 41, in run
    await researcher.conduct_research()
  File "/usr/src/app/gpt_researcher/master/agent.py", line 147, in conduct_research
    self.context = await self.__get_context_by_search(self.query)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/app/gpt_researcher/master/agent.py", line 271, in __get_context_by_search
    context = await asyncio.gather(
              ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/app/gpt_researcher/master/agent.py", line 298, in __process_sub_query
    scraped_data = await self.__scrape_data_by_query(sub_query)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/app/gpt_researcher/master/agent.py", line 353, in __scrape_data_by_query
    retriever = retriever_class(sub_query)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/app/gpt_researcher/retrievers/duckduckgo/duckduckgo.py", line 10, in __init__
    check_pkg('duckduckgo_search')
  File "/usr/src/app/gpt_researcher/retrievers/utils.py", line 7, in check_pkg
    raise ImportError(
ImportError: Unable to import duckduckgo-search. Please install with `pip install -U duckduckgo-search`
INFO:     connection closed

Hey it literally says what to do. Please install it with ‘pip install duckduckgo-search‘


Refactor Xarray Backend Tests

Refactored the tests to work with xarray dataset samples and set to_tiledb and then open_dataset with our engine for roundtrip to compare expected and result datasets. I also added a test for comparing results from indexing tdb arrays to indexing the xarray dataset. Still needs work on fixtures and edit domain settings and to be built out a bit in general.

Adding a roundtrip test is blocked by having a "canonical"  DataArray writer that can fully recover a TileDB array.


Program doesn't return running exe filepath correctly during initial setup

It just stores "R" as a folder name in the config. Probably related to encoding/locale or something. I used the latest release
Writing filepath to exe in the config manually works though

which windows version are you using? win7?

yes

fixed and updated, check release section

Works. Thanks
At last the game can be played comfortably :)


[5.6] rename bcrypt to hasher and allow null value

the helper, like the Facade, should be implementation agnostic. while we currently do use Bcrypt as our hashing algorithm, it is possibly it will switch to a more updated algo in the future.
also allow passing a null value to get the Hasher instance back. this pattern is used in many of the other helpers.  this was originally sent as a separate PR to 5.5, but after a discussion with @Dylan-DPC it was determined this was a BC break.

Reference: Add a str_hash helper, Return hasher when value is null, Rename bcrypt helper and Bcrypt changed to Hash::make and renamed to str_hash :D .

Can we keep the previous bcrypt helper method and mark it as deprecated in the spirit of https://github.com/laravel/internals/issues/383 ?

It doesn't make sense to pass a string to a function named hasher.

And that brings us again to the name problem...

definitely open to other names. I just don't think bcrypt is appropriate.

Yeah i would prefer if bycrpt() gets deprecated first before being removed.

even though I'm targeting Master?
BTW, I'll fix the tests if and when we get this discussion sorted out.

To me there is no need to replace it with anything as we have Hash::make. If we were going to add any other I would think it would be something like Str::hash?

I mean, if we just want to go with the Facade, and drop the helper completely, I'm okay with that. Personally I use the helpers over the Facades, but that's me.  I don't think adding Str::hash is necessary.
As long as we get rid of (or deprecate) the bcrypt helper, because technically the Hasher could be set up to use any different algorithm.  Especially with all the new things in 7.2, I'm guessing password hashing will see a little bit of a shakeup soon.

Given that the PHP itself have the password_hash() method and password digest is a synonym to password hash I think that password_digest would be a good name. 😄

@paulofreitas If you name the helper like that, you're implying it'll be used to hash a password, which could not be the case... Same with PasswordHasher.
If we're going to keep the helper, I'd suggest str_hash or hash_make.

@m1guelpf PHP itself use the password_hash() and password_verify() names. Actually it's using password_hash() internally and the whole point of the hashing functionality is to create strong password digests. To just hash things we have the PHP hash() method. 😄

I don't think we really need a Str::hash and we'll evaluate removing or deprecating this when we actually do have an alternative hasher out of the box.


Update Composer dependencies (2021-06-26-00-08)

Visual regression test passed!
View the visual regression test report


Non-ASCII data in the robo copy logs throws an error

For example:
07-26 07:05:05 main         ERROR    Unexpected exception processing log file: E:\XDrive\Logs\2019-07-25_18-00-02-YUGA-update-x-drive.log, exception: 'ascii' codec can't decode byte 0x82 in position 82: ordinal not in range(128)
This happens when there is a non-ASCII character in a file system path

We haven't had this problem before because everything in the robocopied volume has simple filenames.  However, data on the extras drive does have a few non-ASCII names.

https://github.com/AKROGIS/Robo-Website/issues/1


Support for Yarn

So Travis now supports Yarn officially, and I thought it would be great to add another fantastic tool here which is relevant to the needs to the NodeJs community.
All is looking well which can be found in the branch feature-yarn at the moment, but I'm wondering if this should be cut off into it's own role. The role would be lightweight - it carries essentially no ties to anything used in the nodejs role... Once tests pass I'll decide what to do - but I am hesitant to PR it because this tool is basically optional and not really connected to node.

See travis for passing tests: https://travis-ci.org/fubarhouse/ansible-role-nodejs/builds/177827833

So Yarn has been cut off and weaved into a new role over here: https://github.com/fubarhouse/ansible-role-yarn
I'll close this one after I kill the branch.

Branch is deleted, issue completed.


When using p_tqdm in a Jupyter session and the cell is killed, the processes continue.

p_tqdm is the easiest and most beautiful way to parallelize computations.
I use it often but sometimes I need to cancel some calculation. When this happens, I need to restart the kernel.
I thought that encapsulating the usage of the Pool in a with ... as ... clause could solve this problem.
I am presenting a PR implementing this small change to demonstrate it.

This is now solved by https://github.com/swansonk14/p_tqdm/pull/47. Thank you @r-menezes!


License fix

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy
[ ] Ensured the license file is being packaged.

This PR changes the package's license format to comply with the SPDX specification (see here).

Is that something that should be fixed upstream in https://github.com/ipython/ipython_genutils ?

I've tried to re-add pins, but >=2.7


Shape Card (Quarry) - RFTools

Recipe seems off, takes 3 Industrial diamonds and 1 ore Dict diamond.

yeah they should all be industrial diamonds, will update this script


OrientDb don't release memory

I do to insert about ~8000000 records into my OrientDb, But I have got one problem that java's memory allocated increase once inserting. Therefore I want to release this memory after insert every record.
#My Code:
var dbConn = [];
var dbNext = 0;
var dbMax = 25;

for (var i = 0; i <= dbMax; i++) {
  var db = new ODatabase({
      host: orientdb.host,
      port: 2424,
      username: 'root',
      password: orientdb.password,
      name: 'test',
  });
  dbConn.push(db);
}
//Start loop
record["@class"] = "table";
var db = nextDB();
db.open().then(function () {
    return db.record.create(record);
}).then(function (res) {
    db.close().then(function () {
             //----resume loop
  });
  }).error(function (err) {
          //------
  });

function nextDB() {
  if (++dbNext >= dbMax) {
      dbNext -= dbMax;
  }
  return dbConn[dbNext];
}

memory befor start: 1.2g
memory after 4hours: 4.7g

OrientDB Version [latest]
NodeJS
Windows 10

@hosseinGanjyar Java does not have a method to release direct memory once it is allocated.
You may only limit usage of direct memory but do not release it.

Ok, But when I select / insert into OrientDb database, increase memory. What to do release this memory after select / insert into OrientDb?

@hosseinGanjyar Java can not release memory, we can not do it programmatically. We can only limit its usage.

Hi @hosseinGanjyar after internal discussion we decided that we will implement clean of memory using proprietary Oracle API. But please note that in such case requests processing will be slow and eventually DB will consume the same amount of memory. Is it OK for you ?

 I has problem with Massive Insertion using NodeJS into OrientDB that take very much times of me, and I don't get any result, yet.

@hosseinGanjyar
i've already sent you the code.
What do you mean by OrientJS isn't good for data transport?
What do you mean by does not support streaming?
I've written for you a code that import 8000000~ in more/less 25 min

@hosseinGanjyar i'm not agree . orientdb is a modern distributed nosql multimodel database and is smart too . but if don't know the concepts of using NOSQL or orientdb please read the documentation  more and more .
i suggest , if you want to have more control to memory management use the  orientdb java api .

Hi, we need to understand , whether this feature needs to be implemented. It requires a lot of coding so if it is not needed I prefer rather to close it.

Hi,
Looking at this specific discussion i don't see enough information to start any implementation, there is just a generic blaming of high memory usage, so if you don't have any other profiling/measuring that show that the issue is the closing of byte buffers i wouldn't suggest to start any huge coding task, especially based on this issue.
This issue should instead trigger a profiling of the general memory usage of the whole system to figured out if the issue is from disc cache or high memory retained on heap, or just "normal lazyness" on releasing memory of java after allocation of a lot of objecs.
Hope this help.
Regards

Close issue because of no reply. If you reproduce given issue and have information which is requested in issue feel free to reopen it.

@tglman see this issue:
https://github.com/orientechnologies/orientdb/issues/7090


Clarify why rdf:type and some predicates are "empty"

in case of pdf:type it may be omitted completely.
https://spex.zazuko.com/#/?sparqlEndpoint=https://ld.admin.ch/query&forceIntrospection=false&namedGraph=https://lindas.admin.ch/sbb/nova&prefixes=slac:https://schema.ld.admin.ch/&prefixes=ea:http://example.org/ea/&prefixes=flux:https://ld.flux.zazuko.com/&prefixes=table:http://schema.table.org/&prefixes=http:http://www.w3.org/2006/http%23&prefixes=cube:https://cube.link/

rdf:type is gone now
the other empties are ok because it's not part of the graph


potential fix: bin/console error

This is a potential fix for the bin/console error (issue #62)
The error mentions an uninitialized Rails constant.
Steps I took to resolve this issue:

the Rails constant is initialized
the Ruby versions in the Gemfile and Container are aligned (3.1.3)

@johnmal-dev looks to work for me too. Not exactly sure how we broke it in the first place ... but thanks for tackling this!


Noob Question: Use materialize's jQuery plugin with Webpack

Hi Guys! Nice to meet you! Here is my noob question:
I'm working on a demo with Materialize, Vue.js, and Webpack. Here is a vue file:
<template>

        <select multiple>
          <option value="" disabled selected>Choose your option</option>
          <option value="tea">Tea</option>
          <option value="coffee">Coffee</option>
          <option value="juice">Juice</option>
        </select>
        Materialize Multiple Select

</template>

And Select component doesn't show up. Here is the message returns by the console:
Uncaught TypeError: $(...).material_select is not a function

But when I enter these command in the console manually:
$('select').material_select()

It works! The Select component shows up!
Can anybody help me to correct the code? Many thanks!
And here is my webpack.config.js:
var webpack = require('webpack');

module.exports = {
  // entry point of our application
  entry: './main.js',
  // where to place the compiled bundle
  output: {
    path: __dirname,
    filename: 'build.js'
  },
  module: {
    // `loaders` is an array of loaders to use.
    // here we are only configuring vue-loader
    loaders: [
      {
        test: /\.vue$/, // a regex for matching all files that end in `.vue`
        loader: 'vue'   // loader to use for matched files
      },
      {
        test: /\.css$/,
        loader: 'style-loader!css-loader'
      },
      {
        test: /\.png$/,
        loader: 'url-loader?limit=100000'
      },
      {
        test: /\.jpg$/,
        loader: 'file-loader'
      },
      {
        test: /\.(woff|woff2)(\?v=\d+\.\d+\.\d+)?$/,
        loader: 'url?limit=10000&mimetype=application/font-woff'
      },
      {
        test: /\.ttf(\?v=\d+\.\d+\.\d+)?$/,
        loader: 'url?limit=10000&mimetype=application/octet-stream'
      },
      {
        test: /\.eot(\?v=\d+\.\d+\.\d+)?$/,
        loader: 'file'
      },
      {
        test: /\.svg(\?v=\d+\.\d+\.\d+)?$/,
        loader: 'url?limit=10000&mimetype=image/svg+xml'
      }
    ]
  }
};

This is because materialize-css lists jquery and hammerjs as its dependencies instead of peer dependencies. The result is that materialize-css gets its own private copy of jquery independent from what the rest of your project uses. I would say that it's a serious bug.

See #3707 for a related issue. A temporary workaround is to force all jquery references to resolve to the same file in your webpack.config.js:
  resolve: {
    alias: {
      'jquery': path.resolve(__dirname, '/jquery/dist/jquery.js')
    }
  },

duplicate of #3707


Memory errors in sherlock too

The memory errors we were having in LS5 also happen in sherlock too, but in a far more complicated manner.
Since the overcommit policy of sherlock is set to 0, the processes are allowed to allocate virtual memory beyond the physical memory limit, and more fmriprep instances will succeed without being killed. However, some of them still die more silently.
 My guess is that, since the task did not end gracefully (successful or captured exception, like the OSError ... could not allocate memory), nipype is unaware that the task stopped running and keeps polling endlessly. Apparently, the tasks die leaving a futex open that prevents the worker to continue. I'll keep digging that up.
For now I'll try running fmriprep with only 8 threads (or less). I hope that prevents from overcommiting memory.
On the nipype end, we could check on the multiprocessing Pool (eg. every 10 polling intervals) to identify this situation and mark the task as failed.
WDYT @satra, @chrisfilo, @effigies ?
Thanks @rwblair for the debugging hints :)

If there's a way to check for that case, why not do it every interval?

Just not to steal too many cycles from workers, I don't think it is a biggie. We can start checking every interval.

@oesteban - checking every interval sounds reasonable. especially since we do use different intervals in different configurations.


Typo in SQLInsertClause.executeWithKey(Path) Javadoc

There is a missing period between the first and missing sentences.
"[...] type of the given path [period missing here] If no rows were created, null is returned [...]"

Thanks for all your efforts to improve our documentation. It is highly appreciated!

You're welcome :)

not yet closed, because it has not yet been released

Released in 2.2.5


ts-pip-plugin doesn't support TrustSource API version 2

It seems this library is not maintained anymore and since it not compatitable with TrustSource API version 2, I created new tool TrustSource-pip-scan which supports API version 2 and also add evaluation of TrustSource analysis results(useful in CI/CD pipelines)

Hi Joe, yes, your observation is correct. Due to several reasons - user comfort, maintenance efforts, etc. - we decided to merge the different scanners stepwise into one. Our new swiss-army-knife for scanning is called ts-scan and can be found in the corresponding repository. Python has been moved as one of the first languages. We will indicate this accordingly in the repo. Thanks for the hint.


tests: fix problem with running tests when not root

In cli.spec.ts, it was doing an npm link even though in the docs is says not to do that. This means the tests were failing if you weren't running as an account that could modify the global node_modules. I've changed this to use npx link instead.

/easycla


[HW] Karthik Ravi

Name: Karthik Ravi
Email<EMAIL_ADDRESS>Linkedin Profile: https://www.linkedin.com/in/karthik-ravi-a2036316/
Attach the homework step I screenshots below:

Attach the homework step 2 screenshots below:

Attach the homework step 3 screenshots below:

Attach the homework step 5 screenshots below:

Attach the homework step 6 screenshots below:

Attach the homework step 7 screenshots below:

Attach the homework step 8 screenshots below:

Attach the homework step 9 screenshots below:

Attach the homework step 10 screenshots below:

Attach the homework step 11 screenshots below:

Attach the homework step 12 screenshots below:

Attach the homework step 13 screenshots below:

Hey Karthik Ravi, great job! Congrats!  Please delete your token from the Astra UI so there are no security issues.


Update IOTA App 0.8.4

Update for IOTA with Stardust protocol upgrade
New Flows

Includes changes from #7

Linked to B2CA-1190


Ensure re-assessments recognize Request a Change assessments as the relevant baseline

User Story
As a student, I want to ensure that any re-assessments occuring within the system recognize the changes I have made to my application through the Request a Change process.
Current Behaviour
Currently, a re-assessment will be conducted against the original assessment or the latest re-assessment, but will not recognize and incorproate any inputs which were replaced as a result of the Request a Change process.
Acceptance Criteria

[ ] Ensure any re-assessments (offering change, scholastic standing, automatic re-assessment, etc...) recognizes the values from the latest Request a Change re-assessment.

@CarlyCotton @Joshua-Lakusta
I'm not really sure what other detail I can add here. I think this is just technical implications and AC's but please add anything you think could help the lather discussion


Abbreviations

Rs. (or rs.) is standard abbreviation for currency Rupees (INR).

https://github.com/diasks2/pragmatic_segmenter/commit/9f3750da1b5e010b840dc06a766e811f4503a871


i2c: nrf_twi: Add cast to const buffer pointers

A warning was issued in the build as the rtio tx and tiny_tx buffer pointers are now labeled const. The internal API expects mutable buffers so an explicit cast is needed here to avoid the warning.
Fixes #77853

Can this be updated to ensure the drivers are actually built by CI?
This is the reason it wasn't caught in the original PR


add shuttle.rs

Add shuttle to the crates list

Thanks a lot! Looks like a pretty interesting tool


ELE-740 - paginate upload of source freshness data

This solves issue ELE-740
I am not really sure about what the best way to determine the chunk_size for the upload of the source data is. What I did:

Looked up what the MAX_ARG for Linux systems is and according to some stackoverflow threads it's generally something between 100k and 200k characters - it's bigger for MacOS (this also finally explains why I wasn't getting the error locally, but it kept appearing in the GH action), but since we are running it in a Github instance and to go on the safe side, it obviously makes sense to go with the lesser value
Looking at the sources.json file from our project we have:

~ 320k chars
~ 470 sources

Using this as a reference the chunk size for each upload segment could be around 140 sources. To go on the super safe side, i determined it to be 100 sources.
I normally don't like the idea of hard coding it. We also could:
Take the max argument size of the specific system (e.g.:getconf ARG_MAX on unix based systems)
calculate the chunk sizes based on that
but IMO this would let the code hard to read and over engineered.
That said, if you have other suggestions, I'd be happy to hear them.

Then, I am simply running a for loop to call the command uploading the sources multiple times. Is there a better way to do this?
Testing
I didn't find any testing guidelines for the cli (justo for the dbt-package). What I did to test it, was to install the altered package and run the command on our dbt project. It's working as expected. Let me know how I can better test it.
Comments
From what I see the Elementary code isn't over commented, so I also didn't comment the steps in the code.
Please let me know what I could do better or am doing wrong.

Thanks a lot for contributing!


Write initial config file

So far we use a python config file config.py in the pyveg dir. Maybe this needs to be changed in future.


Add CredentialsManagement public key options and other missing bits

Date- and spec-wise this seems to all jive w/ the original feature, no baseline changes.
The only weird bit is that Caniuse seems incorrect here, unless they're only counting "support" as also supporting some of the optional parameters (unlikely, and would be strange): https://caniuse.com/credential-management. But that doesn't change this PR, just a side note.

In the spirit of "small patches for higher velocity", not going to blow this up into larger Credentials patch. Instead will do it in series of smaller chunks+refactors.

Hrm, I did not search BCD keyspace first... yeah this set of features is sprinkled all over. Moved these to the right home at first glance, but need to look more, flipping back to draft.

Ok, checked spec, and reviewed the various versions these additions shipped in - these do not justify a separate feature, and don't change baseline status of either webauthn or fedcm. Requesting review from @nsatragno as well, per the original feature addition.


Update solidity-scripting.md

Instructions imply that the startBroadcast function takes a uint256 rather than an address
    // Has all subsequent calls (at this call depth only) create transactions that can later be signed and sent onchain
    function startBroadcast(address) external;

hmm, there are functions for both:
https://github.com/foundry-rs/forge-std/blob/master/src/Vm.sol#L113-L116
but should probably be mentioned here

Looks like my version is out of date so I don't have that function signature.
   add41d3..2a2ce36  master                -> origin/master


Problem with binding

Hi, i am facing a problem to load html from a database and put it in an element through <content> and use that element in dom-repeat, i tried using your element to do this because passing the string to content doesn't work, but i ran into this problem:
if i try to use binding to set the value of content, the element displays nothing
the data in {{item.type}} is:
"<paper-button raised class='dragging white'>BUTTON</paper-button>"
here is the code:
https://jsbin.com/buvigiw/edit?html,output

The JSBin code fails because of reasons not related to juicy-html. I can see that Polymer is not loaded at all in this bin. See the screenshot below.
This is the trick that we use to load Polymer in JSBin: http://jsbin.com/qezozor/1/edit?html,output
Can you please fix the JSBin? We will be glad to investigate.

As it seems to be a problem with loading Polymer itself. I'm closing this issue. Feel free to re-open if you still have some problems.


Bug: exceptions are swallowed by exit

Description
By returning a truthy value from __exit__, exceptions thrown when using Halo as a context manager are swallowed, and execution continues.
System settings

Python version: 3.6
Halo version: 0.0.18

Expected behaviour
✖ Doing the thing ...
Traceback (most recent call last):
  File "example.py", line 1337, in example
    raise Exception('stuff')
Exception: stuff

Steps to recreate
from halo import Halo

with Halo('Doing the thing ... '):
    # No exception seen
    raise Exception('stuff')

from halo import Halo

class TransparentHalo(Halo):
    def __exit__(self, exc_type, exc_value, traceback):
        super().__exit__(exc_type, exc_value, traceback)
        # no return

with TransparentHalo('Doing the thing ... '):
    raise Exception('stuff')

@theY4Kman Thanks for raising this issue! It makes sense to raise an exception after stopping the spinner. Would you like to raise a PR for this?

Haha! Yeah, might be tonight or tomorrow.

I tried running tox yesterday and had some issues. I tried again tonight and found the same (go figure :P though, I was missing py34 yesterday, so I tried again with it installed, just to be thorough): https://gist.github.com/theY4Kman/c9dbeffe44fce618f3fa402079073568
Though the main change in the PR would prolly be one-line — even if I really want to add an __init__ kwarg to allow exception swallowing — I ain't gonna submit shit without tests. And to be totally honest, I ran those tests and am writing this in between development I've been told not to do so much of at this hour...
In any case, man, thank you for some sexy-ass spinners. tqdm is really fuckin complicated, and after I figured out enough to appease me... I learned it didn't support indefinite progress at all :P
Cheers!

@theY4Kman Strange! The test cases should pass just fine locally. Since only animation tests are failing, I think this might be because of terminal size issues. Maybe you can check if it is because of the same. Please raise a PR/share the code and let me also evaluate.
 I'm trying my best to make this project complete and easy to develop with.

@theY4Kman I just merged #99 which should fix this issue for you.

Aww yiss! That did it! Thank you :) The linter fails with this guy I haven't had time to diagnose, yet, but with an interesting traceback like that, I'm dying to know what the hell it's doing
lint recreate: /Users/they4kman/programming/third-party/halo/.tox/lint
lint installdeps: -r/Users/they4kman/programming/third-party/halo/requirements.txt, -r/Users/they4kman/programming/third-party/halo/requirements-dev.txt
lint inst: /Users/they4kman/programming/third-party/halo/.tox/dist/halo-0.0.18.zip
lint installed: appnope==0.1.0,astroid==2.0.4,bleach==3.0.2,colorama==0.3.9,coverage==4.4.1,cursor==1.2.0,decorator==4.3.0,defusedxml==0.5.0,entrypoints==0.2.3,enum34==1.1.6,halo==0.0.18,ipykernel==5.1.0,ipython==5.7.0,ipython-genutils==0.2.0,ipywidgets==7.1.0,isort==4.3.4,Jinja2==2.10,jsonschema==2.6.0,jupyter-client==5.2.3,jupyter-core==4.4.0,lazy-object-proxy==1.3.1,log-symbols==0.0.11,MarkupSafe==1.0,mccabe==0.6.1,mistune==0.8.4,nbconvert==5.4.0,nbformat==4.4.0,nose==1.3.7,notebook==5.7.0,pandocfilters==1.4.2,pexpect==4.6.0,pickleshare==0.7.5,pluggy==0.8.0,prometheus-client==0.4.2,prompt-toolkit==1.0.15,ptyprocess==0.6.0,py==1.7.0,Pygments==2.2.0,pylint==1.7.2,python-dateutil==2.7.3,pyzmq==17.1.2,Send2Trash==1.5.0,simplegeneric==0.8.1,six==1.11.0,spinners==0.0.23,termcolor==1.1.0,terminado==0.8.1,testpath==0.4.2,tornado==5.1.1,tox==2.8.2,traitlets==4.3.2,virtualenv==16.0.0,wcwidth==0.1.7,webencodings==0.5.1,widgetsnbextension==3.1.4,wrapt==1.10.11
lint runtests: PYTHONHASHSEED='3195813463'
lint runtests: commands[0] | pylint --errors-only --rcfile=/Users/they4kman/programming/third-party/halo/.pylintrc --output-format=colorized halo
Traceback (most recent call last):
  File "/Users/they4kman/programming/third-party/halo/.tox/lint/bin/pylint", line 11, in <module>
    sys.exit(run_pylint())
  File "/Users/they4kman/programming/third-party/halo/.tox/lint/lib/python3.7/site-packages/pylint/__init__.py", line 13, in run_pylint
    Run(sys.argv[1:])
  File "/Users/they4kman/programming/third-party/halo/.tox/lint/lib/python3.7/site-packages/pylint/lint.py", line 1260, in __init__
    'init-hook')))
  File "/Users/they4kman/programming/third-party/halo/.tox/lint/lib/python3.7/site-packages/pylint/lint.py", line 1361, in cb_init_hook
    exec(value) # pylint: disable=exec-used
  File "<string>", line 8
    ZGljdChfX2ZpbGVfXz1hY3RpdmF0ZV90aGlzKSkK'.decode('base64')
                                            ^
SyntaxError: invalid syntax
ERROR: InvocationError: '/Users/they4kman/programming/third-party/halo/.tox/lint/bin/pylint --errors-only --rcfile=/Users/they4kman/programming/third-party/halo/.pylintrc --output-format=colorized halo'

It's been a volcano at work for a hot minute — I'm hoping it'll die down, and I'll have Happy Fun Free Time™ again. I dig your motives, and you've been hella helpful; I'd love to contribute back.

@theY4Kman Yes, that is because linter works on Python 2.7 which this project is mostly written in. It breaks on init-hook for Python 3. Since we can lint only for a particular Python version, I don't think there is a workaround for it but to install Python 2.7.

just encountered this myself.  if anyone is unclear how to move forward in the meantime, here's a quick shim:
import contextlib

@contextlib.contextmanager
def halo_shim(text):
    spinner = halo.Halo(text)
    spinner.start()
    try:
        yield spinner
    finally:
        spinner.stop()


Creating new wallet with Ledger Nano X won't continue

Issue description
in firefly the process wont continue after the ledger nano x is recognized and the iota app is opend. firefly confirms the connection to the hardware wallet, but won't do anything after i click "continue".
the firefly application and the iota app (v. 0.5.5) on the nano ledger x are both new installed and reinstalled after some tries. everything is up-to-date. all applications were closed on the last try. computer was rebooted before.
it should create a new firefly wallet with the nano ledger x stick.
Firefly version
1.2.0
OS details
Windows 10 Home 21H2 19044.1387
Can the issue be reliably reproduced?
Yes
Steps to reproduce the issue

open firefly
continue (language dialog)
accept policy & terms of service
use dark theme
set profilename
"create new wallet"
"i want a hardware wallet"
set pin-code
connect hardware wallet
unlock hardware wallet
open iota app on hardware wallet
click continue

Expected behaviour
the application should go forward in the dialog
Actual behaviour
the continue button shortly shows a message about connecting or processing (not sure) and then back to "continue"
no error message dialog or change on the hardware wallet
Errors
LedgerMiscError: ledger transport error

Hello,
it seems that you use an outdatet firmware version of your ledger device. For ledger nano x the firmware version should at least be 1.3. If there is no hint in Ledger Live to update the firmware version you need to manually download it from the Ledger Live website and install it again. After you updated the firmware version and the IOTA app it should be good.

I'll check it and try it again and let you know. thank you so far.

it worked. ledger had a problem with the automatic update function of ledger live. this also prevented the newest update of the ledger nano x software. although it said its updated to the newest, there was a even newer version available after the manual update of ledger live via their support website. thanks for the help.


WIP: Add workaround for Ruby SDK and Nginx

Facts:

Ruby SDK uses the Expect header in Signature
Nginx manage itself the Expect header and by default
drop it before passing the request to proxy.

It will raises Invalid Signature.
If nginx is configured to let pass the Expect header,
nginx doesn't manage the expect behavior as is send data
without waiting 100-continue and will raise timeout.

Proper fix has been merged into aws-sdk-ruby as https://github.com/aws/aws-sdk-ruby/pull/2316


update unifi logo

it looks like there's a logo url in the unifi.yaml file that's overriding your change here.

@anita-trimbur yup, i opened a pr over there to remove the url they are using.
https://github.com/pulumiverse/pulumi-unifi/pull/76


Add dependencies between tasks in the GitHub Actions

Adding dependencies between tasks (for fix errors here and here)
Maybe add to templates or specified workflow
https://docs.github.com/en/actions/using-jobs/using-jobs-in-a-workflow#defining-prerequisite-jobs
name: Create GitHub Release

on:
  push:
    branches: [main]
    paths: ['vault/**']

jobs:
  create-release:
    uses<EMAIL_ADDRESS>    needs: [pylint, verify-package, verify-changelog, pytest]

done
https://github.com/obervinov/users-package/pull/9/commits/ca7be9e4a85604a72d2c40cbe02f499d17a41982


WSL displaying wrong disk space.

Windows Version
Microsoft Windows [Version 10.0.22621.2715]
WSL Version
<IP_ADDRESS>
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>-1
Distro Version
Ubuntu 22.04
Other Software
No response
Repro Steps

Open your distro's terminal
Run the df -h command
Check the /dev/sdc device vs the /mnt/c device

Expected Behavior
Normally it should display 512gb because that is my actual SSD size.
Actual Behavior
You can see in the screenshot bellow that the /dev/sdc device that is mounted on / says it has 1000gb while the /mnt/c says the actual disk space.

Diagnostic Logs
No response

Alright as I found out from here it seems like this is the expected behavior.