[RC] Changes to zuse not propagated into userspace

On the release-candidate branch, updating zuse reloads the vanes, but not userspace.
Say you add the following arm into top-level zuse:
++  ohno  5

This builds fine, but then trying to do ohno in dojo gives a -find error. Similarly, modifying an existing arm in zuse still gives the old value when inspected from dojo.
Also, when trying to run tests (ie :test [%cores /]) after modifying zuse causes those changes not te be taken into account, resulting in errors if a library uses, say, the newly added ++ohno.
I did work on jael earlier (#795) that touched zuse, and didn't notice this at all. It's obvious vanes are getting rebuilt properly, but userspace applications continue running on old zuse. Probably not intended behavior?

This is a bug, but not a new bug.  Our update logic (kiln) could use a tuneup...
Sent from my iPhone

On Aug 30, 2018, at 6:46 AM, Fang<EMAIL_ADDRESS>wrote:
On the release-candidate branch, updating zuse reloads the vanes, but not userspace.
Say you add the following arm into top-level zuse:
++  ohno  5
This builds fine, but then trying to do ohno in dojo gives a -find error. Similarly, modifying an existing arm in zuse still gives the old value when inspected from dojo.
Also, when trying to run tests (ie :test [%cores /]) after modifying zuse causes those changes not te be taken into account, resulting in errors if a library uses, say, the newly added ++ohno.
I did work on jael earlier (#795) that touched zuse, and didn't notice this at all. It's obvious vanes are getting rebuilt properly, but userspace applications continue running on old zuse. Probably not intended behavior?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Userspace applications not reloading is an old bug; fresh ford requests
however, as you get from dojo expressions or :test, would totally see the
new  pit
On Thursday, 30 August 2018, cgyarvin<EMAIL_ADDRESS>wrote:

This is a bug, but not a new bug. Our update logic (kiln) could use a
tuneup...
Sent from my iPhone

On Aug 30, 2018, at 6:46 AM, Fang<EMAIL_ADDRESS>wrote:
On the release-candidate branch, updating zuse reloads the vanes, but
not userspace.
Say you add the following arm into top-level zuse:
++ ohno 5
This builds fine, but then trying to do ohno in dojo gives a -find
error. Similarly, modifying an existing arm in zuse still gives the old
value when inspected from dojo.
Also, when trying to run tests (ie :test [%cores /]) after modifying
zuse causes those changes not te be taken into account, resulting in errors
if a library uses, say, the newly added ++ohno.
I did work on jael earlier (#795) that touched zuse, and didn't notice
this at all. It's obvious vanes are getting rebuilt properly, but userspace
applications continue running on old zuse. Probably not intended behavior?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417340148, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt
.

To work around this, try echoing a newline into the dojo source. That
should cause a recompilation against new zuse.
@eglaysher I would think new Ford would rebuild all of its nontrivial live
builds when Zuse updates, though, since even using the %reef short-circuit
logic, they should still have live dependencies on Zuse.
—
~rovnys-ricfer
https://urbit.org
On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin<EMAIL_ADDRESS>wrote:

Userspace applications not reloading is an old bug; fresh ford requests
however, as you get from dojo expressions or :test, would totally see the
new pit
On Thursday, 30 August 2018, cgyarvin<EMAIL_ADDRESS>wrote:

This is a bug, but not a new bug. Our update logic (kiln) could use a
tuneup...
Sent from my iPhone

On Aug 30, 2018, at 6:46 AM, Fang<EMAIL_ADDRESS>wrote:
On the release-candidate branch, updating zuse reloads the vanes, but
not userspace.
Say you add the following arm into top-level zuse:
++ ohno 5
This builds fine, but then trying to do ohno in dojo gives a -find
error. Similarly, modifying an existing arm in zuse still gives the old
value when inspected from dojo.
Also, when trying to run tests (ie :test [%cores /]) after modifying
zuse causes those changes not te be taken into account, resulting in
errors
if a library uses, say, the newly added ++ohno.
I did work on jael earlier (#795) that touched zuse, and didn't notice
this at all. It's obvious vanes are getting rebuilt properly, but
userspace
applications continue running on old zuse. Probably not intended
behavior?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417340148, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417368205, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA1Y9Y-NLrX-iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt
.

This is talking about dojo expressions, right? Those are run against [%plan
he-rail ~ scaffold[he-rail zuse sur lib ~ ~], where  he-rail  is  now
and  zuse  is iirc a non-binding version number.
On Thursday, 30 August 2018, Ted Blackman<EMAIL_ADDRESS>wrote:

To work around this, try echoing a newline into the dojo source. That
should cause a recompilation against new zuse.
@eglaysher I would think new Ford would rebuild all of its nontrivial live
builds when Zuse updates, though, since even using the %reef short-circuit
logic, they should still have live dependencies on Zuse.
—
~rovnys-ricfer
https://urbit.org
On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin<EMAIL_ADDRESS>wrote:

Userspace applications not reloading is an old bug; fresh ford requests
however, as you get from dojo expressions or :test, would totally see the
new pit
On Thursday, 30 August 2018, cgyarvin<EMAIL_ADDRESS>wrote:

This is a bug, but not a new bug. Our update logic (kiln) could use a
tuneup...
Sent from my iPhone

On Aug 30, 2018, at 6:46 AM, Fang<EMAIL_ADDRESS>wrote:
On the release-candidate branch, updating zuse reloads the vanes, but
not userspace.
Say you add the following arm into top-level zuse:
++ ohno 5
This builds fine, but then trying to do ohno in dojo gives a -find
error. Similarly, modifying an existing arm in zuse still gives the old
value when inspected from dojo.
Also, when trying to run tests (ie :test [%cores /]) after modifying
zuse causes those changes not te be taken into account, resulting in
errors
if a library uses, say, the newly added ++ohno.
I did work on jael earlier (#795) that touched zuse, and didn't
notice
this at all. It's obvious vanes are getting rebuilt properly, but
userspace
applications continue running on old zuse. Probably not intended
behavior?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417340148, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417368205, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA1Y9Y-NLrX-
iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417402265, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhl6ic5PLdchCigwcwDMb4p41iRmlks5uWCFPgaJpZM4WTglt
.

(Which should in fact reduce to %reef among other things)
On Thursday, 30 August 2018, Anton Dyudin<EMAIL_ADDRESS>wrote:

This is talking about dojo expressions, right? Those are run against
[%plan he-rail ~ scaffold[he-rail zuse sur lib ~ ~], where  he-rail  is
now  and  zuse  is iirc a non-binding version number.
On Thursday, 30 August 2018, Ted Blackman<EMAIL_ADDRESS>wrote:

To work around this, try echoing a newline into the dojo source. That
should cause a recompilation against new zuse.
@eglaysher I would think new Ford would rebuild all of its nontrivial live
builds when Zuse updates, though, since even using the %reef short-circuit
logic, they should still have live dependencies on Zuse.
—
~rovnys-ricfer
https://urbit.org
On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin<EMAIL_ADDRESS>wrote:

Userspace applications not reloading is an old bug; fresh ford
requests
however, as you get from dojo expressions or :test, would totally see
the
new pit
On Thursday, 30 August 2018, cgyarvin<EMAIL_ADDRESS>wrote:

This is a bug, but not a new bug. Our update logic (kiln) could use a
tuneup...
Sent from my iPhone

On Aug 30, 2018, at 6:46 AM, Fang<EMAIL_ADDRESS>wrote:
On the release-candidate branch, updating zuse reloads the vanes,
but
not userspace.
Say you add the following arm into top-level zuse:
++ ohno 5
This builds fine, but then trying to do ohno in dojo gives a -find
error. Similarly, modifying an existing arm in zuse still gives the
old
value when inspected from dojo.
Also, when trying to run tests (ie :test [%cores /]) after modifying
zuse causes those changes not te be taken into account, resulting in
errors
if a library uses, say, the newly added ++ohno.
I did work on jael earlier (#795) that touched zuse, and didn't
notice
this at all. It's obvious vanes are getting rebuilt properly, but
userspace
applications continue running on old zuse. Probably not intended
behavior?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417340148, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417368205, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA1Y9Y-
NLrX-iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417402265, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhl6ic5PLdchCigwcwDMb4p41iRmlks5uWCFPgaJpZM4WTglt
.

New Ford only uses the Zuse version number as an assertion. It builds the
reef based on beak. Ford will "short-circuit" a %reef build by using the
pit if the build is at the current date on the %home or %base desks. This
arrangement is designed to maintain referential transparency unless you
turn off |autoload.
Looks like Ford lost some code in the merge. @eglaysher had added code to
+make-reef to ensure we register dependencies on hoon, arvo, and zuse even
if we short-circuit using the pit. That code is now gone ... We'll dig that
up and reinstate it, and then maybe apps will reload. I just looked through
the reload and autoload code in helm and kiln, and I don't see how any of
that logic could cause this issue.
If fixing this in Ford doesn't fix the bug, then I suspect the ultimate
cause of the bug might be Clay not sending a notification about updates to
system files. I had thought maybe Gall's +load arm could be the culprit,
but it just keeps the old state wholesale, so I don't think that's it.
On Thu, Aug 30, 2018 at 10:47 AM Anton Dyudin<EMAIL_ADDRESS>wrote:

(Which should in fact reduce to %reef among other things)
On Thursday, 30 August 2018, Anton Dyudin<EMAIL_ADDRESS>wrote:

This is talking about dojo expressions, right? Those are run against
[%plan he-rail ~ scaffold[he-rail zuse sur lib ~ ~], where he-rail is
now and zuse is iirc a non-binding version number.
On Thursday, 30 August 2018, Ted Blackman<EMAIL_ADDRESS>wrote:

To work around this, try echoing a newline into the dojo source. That
should cause a recompilation against new zuse.
@eglaysher I would think new Ford would rebuild all of its nontrivial
live
builds when Zuse updates, though, since even using the %reef
short-circuit
logic, they should still have live dependencies on Zuse.
—
~rovnys-ricfer
https://urbit.org
On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin<EMAIL_ADDRESS>

wrote:

Userspace applications not reloading is an old bug; fresh ford
requests
however, as you get from dojo expressions or :test, would totally see
the
new pit
On Thursday, 30 August 2018, cgyarvin<EMAIL_ADDRESS>wrote:

This is a bug, but not a new bug. Our update logic (kiln) could use
a
tuneup...
Sent from my iPhone

On Aug 30, 2018, at 6:46 AM, Fang<EMAIL_ADDRESS>wrote:
On the release-candidate branch, updating zuse reloads the vanes,
but
not userspace.
Say you add the following arm into top-level zuse:
++ ohno 5
This builds fine, but then trying to do ohno in dojo gives a -find
error. Similarly, modifying an existing arm in zuse still gives the
old
value when inspected from dojo.
Also, when trying to run tests (ie :test [%cores /]) after
modifying
zuse causes those changes not te be taken into account, resulting in
errors
if a library uses, say, the newly added ++ohno.
I did work on jael earlier (#795) that touched zuse, and didn't
notice
this at all. It's obvious vanes are getting rebuilt properly, but
userspace
applications continue running on old zuse. Probably not intended
behavior?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the
thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417340148,
or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417368205, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA1Y9Y-
NLrX-iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417402265, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
ABxXhl6ic5PLdchCigwcwDMb4p41iRmlks5uWCFPgaJpZM4WTglt>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417407754, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA1Y9enAV6lKMyBu3YfKfRKXxFeFAO3cks5uWCUdgaJpZM4WTglt
.

On Thursday, 30 August 2018, Ted Blackman<EMAIL_ADDRESS>wrote:

New Ford only uses the Zuse version number as an assertion. It builds the
reef based on beak. Ford will "short-circuit" a %reef build by using the
pit if the build is at the current date on the %home or %base desks. This
arrangement is designed to maintain referential transparency unless you
turn off |autoload.

+1, this is also how I remember old ford working, which is why the bug is
likely new.

Looks like Ford lost some code in the merge. @eglaysher had added code to
+make-reef to ensure we register dependencies on hoon, arvo, and zuse even
if we short-circuit using the pit. That code is now gone ... We'll dig that
up and reinstate it, and then maybe apps will reload. I just looked through
the reload and autoload code in helm and kiln, and I don't see how any of
that logic could cause this issue.

esp since you seem to have found a plausible mechanism, nice!

If fixing this in Ford doesn't fix the bug, then I suspect the ultimate
cause of the bug might be Clay not sending a notification about updates to
system files. I had thought maybe Gall's +load arm could be the culprit,
but it just keeps the old state wholesale, so I don't think that's it.
On Thu, Aug 30, 2018 at 10:47 AM Anton Dyudin<EMAIL_ADDRESS>wrote:

(Which should in fact reduce to %reef among other things)
On Thursday, 30 August 2018, Anton Dyudin<EMAIL_ADDRESS>wrote:

This is talking about dojo expressions, right? Those are run against
[%plan he-rail ~ scaffold[he-rail zuse sur lib ~ ~], where he-rail is
now and zuse is iirc a non-binding version number.
On Thursday, 30 August 2018, Ted Blackman<EMAIL_ADDRESS>wrote:

To work around this, try echoing a newline into the dojo source. That
should cause a recompilation against new zuse.
@eglaysher I would think new Ford would rebuild all of its nontrivial
live
builds when Zuse updates, though, since even using the %reef
short-circuit
logic, they should still have live dependencies on Zuse.
—
~rovnys-ricfer
https://urbit.org
On Thu, Aug 30, 2018 at 8:48 AM, Anton Dyudin <
<EMAIL_ADDRESS>

wrote:

Userspace applications not reloading is an old bug; fresh ford
requests
however, as you get from dojo expressions or :test, would totally
see
the
new pit
On Thursday, 30 August 2018, cgyarvin<EMAIL_ADDRESS>wrote:

This is a bug, but not a new bug. Our update logic (kiln) could
use
a
tuneup...
Sent from my iPhone

On Aug 30, 2018, at 6:46 AM, Fang<EMAIL_ADDRESS>wrote:
On the release-candidate branch, updating zuse reloads the
vanes,
but
not userspace.
Say you add the following arm into top-level zuse:
++ ohno 5
This builds fine, but then trying to do ohno in dojo gives a
-find
error. Similarly, modifying an existing arm in zuse still gives
the
old
value when inspected from dojo.
Also, when trying to run tests (ie :test [%cores /]) after
modifying
zuse causes those changes not te be taken into account, resulting
in
errors
if a library uses, say, the newly added ++ohno.
I did work on jael earlier (#795) that touched zuse, and didn't
notice
this at all. It's obvious vanes are getting rebuilt properly, but
userspace
applications continue running on old zuse. Probably not intended
behavior?
—
You are receiving this because you are subscribed to this
thread.
Reply to this email directly, view it on GitHub, or mute the
thread.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/urbit/arvo/issues/796#issuecomment-417340148
,
or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
ABxXhpqK1PkYLrryMXHmmBT9WZgYkN3cks5uV_blgaJpZM4WTglt>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417368205,
or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA1Y9Y-
NLrX-iekTnmtsdgv9xiFKYtEMks5uWAk1gaJpZM4WTglt>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417402265, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
ABxXhl6ic5PLdchCigwcwDMb4p41iRmlks5uWCFPgaJpZM4WTglt>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417407754, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AA1Y9enAV6lKMyBu3YfKfRKXxFeFAO3cks5uWCUdgaJpZM4WTglt>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/issues/796#issuecomment-417421736, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABxXhtM4XpI2qOdFFCuUY1UDl36XI61qks5uWC85gaJpZM4WTglt
.

For the record, the code in +make-reef should look like this:
https://github.com/belisarius222/arvo/blob/ford-turbo-wip-integration/sys/vane/turbo.hoon#L5016-#L5102

This appears to be fixed by https://github.com/urbit/arvo/pull/800. Closing.

@belisarius222 this doesn't actually seem to be fixed? Running off a pill that includes both #800 and #802. Adding an arbitrary arm into zuse still doesn't make it accessible in dojo/userspace without booting from a new pill.

Oh ... I guess I didn't conduct my test properly. I'll look into it.

Well, I'll look into this after fixing the Clay referential transparency bug.

I'm not able to reproduce this bug on latest release-candidate. When I sync in new arms to zuse, they're immediately available in the dojo.

Also no longer able to reproduce. This seems fixed!


Handle array outputs correctly

Use n+1 | as the separator, with n being the highest number of consecutively occurring |. See https://github.com/babe-project/babe-project/issues/54#issuecomment-482939225

Or there might be some libraries which already handle this issue.


Do you have a graph_def file for the models ?

I am trying out https://github.com/IntelAI/tools/tree/master/tensorflow_quantization#steps-for-fp32-optimized-frozen-graph  and I would like to know if you have any .pb or .pbtxt files along with the checkpoint files which you provided in the ./models

I don't have them, but you have the code that builds the graph so you should be able to write the graph to disk.

@tomhosking may I know where exactly it is?

The model is built here, and you can then access the graph with self.model.graph, eg
tf.train.write_graph(self.model.graph, path_to_model_pb,                      'saved_model.pb', as_text=False)
(see this stackoverflow post)

@tomhosking Thanks


Nested component using string error

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
#[component(inline_props)]
fn T<G:Html>(cx:Scope,title: String, level: i32) -> View {
let tt = title.clone();
view!{
    cx,
    (
        if level<5 {
            view!{
                cx,
                T(
                    title=tt,
                    level=level+1
                )
            }
        } else {
            view!{
                cx,
                p{
                    (tt)
                }
            }
        }
    )
}

}
error info：
cannot move out of tt_clone, a captured variable in an FnMut closure
tt_clone is moved hererustcClick for full compiler diagnostic
main.rs(25, 9): captured outer variable
main.rs(26, 5): captured by this FnMut closure
main.rs(33, 31): variable moved due to use in closure
main.rs(33, 31): move occurs because tt_clone has type String, which does not implement the Copy trait
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment

Sycamore: [e.g. 0.8.2, master]
Browser: [e.g. chrome, safari, if applicable]
OS: [e.g. Windows, if applicable]

Additional context
Add any other context about the problem here.

Where is tt_clone? I believe what you want is title.clone() inside the inner view. Please reopen if this doesn't solve your issue.


fix: add require polyfill when needed in schema for esm compatibility

Current dependencies on/for this PR:

main

PR #110   👈

This comment was auto-generated by Graphite.


Window crashes when remote file becomes unavailable.

Issue Type: Bug
When editing a file located on a network share, if the network share becomes unavailable (i.e., the share goes offline), the window will crash.
VS Code version: Code 1.48.2 (a0479759d6e9ea56afa657e454193f72aef85bd0, 2020-08-25T10:09:08.021Z)
OS version: Darwin x64 19.6.0

Can you please follow the steps in https://github.com/Microsoft/vscode/wiki/Native-Crash-Issues to get at more details around the crash and attach the result here? Thanks!


[CLI] Support --create-branch option in huggingface-cli upload

Originally requested by @TheBloke on slack (private)

It'd be nice if it would also create a branch that didn't exist, or if there was a --create-branch boolean as it seems currently a branch (revision) has to exist before it can be uploaded to?

Q.: would we create it from latest or orphan. Might not be useful if https://github.com/huggingface/huggingface_hub/issues/1655 is implemented as well.

HI @Wauplin
Would also want to have such a feature that I can upload to a specific new branch in the hf-repo. This will typically be useful when I have a project but want to store different implementation's model ckpt.

@kxhit thanks for letting us know! @martinbrose started to work on the CLI to manage branches in https://github.com/huggingface/huggingface_hub/pull/1672. I think that if we have this, we'll keep the branch creation separated from the upload. You would have to launch 2 separate CLI commands, WDYT? Otherwise we could implement this one just after :)

Hi @kxhit thanks for letting us know. As I see it, it would require to:

add a --create-branch argument here and here
add a check in __init__ that --create-branch and --create-pr are not used at the same time (print message otherwise + exit(1)). Also same for --every that is a particular case that we don't want to handle (yet?) IMO
add a check in __init__ that both --create-branch and --revision are used at the same time
add a create_branch(..., exists_ok=True) call just after repo creation here
add a unit test for that

Would you like to open a PR for it?

Hi, thanks for your guidance. I will take a look but I'm currently busy on my diffusion/diffusers project. It would be great if someone could contribute to it!

In the end we went for a simpler solution where branch is automatically create if it doesn't exist. Discussed in https://github.com/huggingface/huggingface_hub/issues/1841 and implemented in https://github.com/huggingface/huggingface_hub/pull/1857.
Therefore closing this issue as "wont fix".


String exercise 1.1.1 needs clarification

The use of single quote marks and backslash (with an apostrophe included in the string) may need to be more obvious to the user. Currently not very clear when moving on to exercise 1.1.2.

Maybe also worth mentioning that the following works: "Single 'quotes' can be used within double quotes." and 'Double "quotes" can be used within single quotes.'

Ok so this all got me thinking, can you do an f-string with single quotes inside of an f-string with double quotes... the answer is yes :laughing:
b = 3
f"{f'{b*2}'} pi"

is valid python!
Yeah maybe we don't get this crazy though...

lol
It can actually be useful with pd.DataFrames: f"foo = df[f'{bar}']"


Updates to pokemon bag display on the map

Short Description:
Updates to pokemon bag display on the map
Fixes:

Added CP and IV to caught pokemon on map
Improved layout for pokemon bag display on map

Nice work, though all those ??? on the eggs makes it look bad. Maybe work out a way to remove the display of those field for eggs?

Good idea. I'm also looking into a way to sort the pokemon by name or CP level, will add that soon.

How about both? ;) Add sorting options mate.

Sorting is coming up.

Screenshots for UI changes are helpful

sorting would be really nice :) im running this code atm

Sorting has been added and the eggs in your bag are now displayed below your pokemon as "You have x eggs".

Nice work, one more thing though.
Line 366 - 375 Change to
 if (menu == 2) {
    document.getElementById('subtitle').innerHTML = "Items in Bag";
    out = '

' + users[0] + '

';
    for (var i = 0; i < bagItems.length; i++) {
      out += '
	Item: ' + itemsArray[bagItems[i].inventory_item_data.item.item_id] +
      '
Count: ' + (bagItems[i].inventory_item_data.item.count || 0) + '
';
    }
    out += '

';
    document.getElementById('subcontent').innerHTML = out;
  }

@RedSparr0w Added.

Improved responsiveness, items in bag layout and restyled the menu options

I'm going to rebase and create a new PR, this is starting to become a mess :D

Coming along nicely.
One more thing if you think it would work/have the time.
Could you add a little pokeball icon next to each pokemon in your bag showing which pokeball it was caught with?
snippets of code:
pkmPokeball = obj[i].inventory_item_data.pokemon_data.pokeball || 0;

.pokeball {
	width: 30px;
	height: auto;
}

if it is a starter pokemon it will show:  (0.png)
not sure about eggs though as haven't hatched one yet.

@RedSparr0w I've merged my sorting code with the design Sniok created in the new repository.
You can see the PR here : https://github.com/OpenPoGo/OpenPoGoWeb/pull/17 along with a screenshot.
I'll add the pokeball tomorrow.


Insomnia unable to render Okta login page

Expected Behavior
Expected to see the Okta login page when being re-directed to Okta to logon.
Actual Behavior
Insomnia shows a 200 but doesn't render the page.

Reproduction Steps
Visit an URL that re-directs to Okta to logon with Insomnia.
Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
2022.4.0-beta.0
What operating system are you using?
macOS
Operating System Version
12.3.1
Installation method
insomnia.rest
Last Known Working Insomnia version
No response

Looks like this is caused by javascript on the page setting cookies and failing. Allowing that causes various issues. So this is actually working as designed. Would recommend getting a session/token through your browser and then doing what you need. If you need an Okta token, you can use the Bearer auth method for the API requests.


Ability to parse time string with custom layout

The issue
Currently there is no way to parse date string(s) with custom layout, like the French one DD/MM/YYYY, the Spanish one DD-MM-YY, the Finnish one DD.MM.YYYY.
Proposal
A hugo time method to parse date string with a provided layout like this:
{{ time.ParseWithFormat FORMAT INPUT [TIMEZONE] }}

{{ time.ParseWithFormat "02/01/2006" "15/03/2021" }} → "2021-03-15T00:00:00Z"

How to
Internally this would use the Go time function ParseInLocation like this:
time.ParseInLocation("02/01/2006", "15/03/2021", loc)

Go Playground example: https://go.dev/play/p/gsSIgLgAYLL

Currently there is no way to parse date string(s) with custom layout,

That's not entirely true. time.Format uses the location as defined per language in your site config.
We could consider adding a timeZone to time.Format, though. Would that work for you?

Currently I cannot use time.Format with date input string like 15/03/2021.
If I want to convert a French date string to ISO 8601 format with time.Format, like this:
{{ time.Format "2006-01-02" "15/03/2021" }}
I get:
error calling Format: unable to parse date: 15/03/2021
Even if in my config file I have set:
languageCode: "fr-FR"
defaultContentLanguage: "fr"
timeZone: "Europe/Paris"

This is why if we had the ability to pass the custom layout used by the date string we have, we could parse and convert it to ISO 8601 format.

Idea: Maybe we could have an optional parameter to time.Format:
time.Format OUTPUT_LAYOUT INPUT [INPUT_LAYOUT]

then we could do:
{{ time.Format "2006-01-02" "15/03/2021" "02/01/2006" }} → "2021-03-15"


fix: fix v2 error that can happen when writing list<struct<...>> with many empty lists

If the list offsets are bigger than the struct items (easy if there are many lists) and there are multiple pages of offsets then the list encoding needs to force a page from the items page.  This causes flush to be called multiple times which the struct encoder wasn't expecting.  This would lead the struct header column to have multiple pages which, while not technically a problem, causes an assertion to fail on read.
We could relax the assertion but it is simpler to just not write that kind of file in the first place.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 79.20%. Comparing base (18fbd7a) to head (e6f93bd).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2762      +/-   ##
==========================================
+ Coverage   79.18%   79.20%   +0.02%
==========================================
  Files         227      227
  Lines       67733    67727       -6
  Branches    67733    67727       -6
==========================================
+ Hits        53631    53644      +13
- Misses      10977    10978       +1
+ Partials     3125     3105      -20

Flag
Coverage Δ

unittests
79.20% <100.00%> (+0.02%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

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


[Windows desktop] Console error

1. While app is force reload

2. This error occurs rarely while navigating through app

Are we going to enable hot reload (refresh) on the production application? I don't think that sounds like a good idea and you can only do that when enabling dev tools. Is the 'toggledevtools' option going to be enabled in the final version?

I could try to take a look at the second error.  Seems like you need a "wait for mount" before you call the useEffect function.

Can anyone link to merged PR addressing this issue and account for payment

Can anyone link to merged PR addressing this issue and account for payment


185357011 all teachers can see comments

Fulfills two tickets
All Teachers can see Comments
[CLUEAI] Comments on this class Student Workspaces View - Group View commenting

@scytacki  let me know if you'd like me to also write tests for this.

Fixing the branch conflict atm.

New functionality requests are documented in this new PT Story
 [CLUEAI] All Teachers Can See Co-Teacher's comments + Restrict students To Comment(?)

Thanks @kswenson.
As for merging, it's still blocked because of requested changes from @scytacki

As for merging, it's still blocked because of requested changes from @scytacki , which I resolved so I just re-requested review.

@scytacki is unavailable this week and we agreed to put off addressing his remaining concerns to later, so you shouldn't wait for his review.

@kswenson Got it, just dismissed his review and merged into master.


Add tolerance to dragpan

Do not merge, this is just a demo

result won't be visible until we fix gestures clobbering each other

Ok, ready to merge now


Fermion partitioning

Fermionic partitioning schemes as per https://arxiv.org/abs/1908.05628, with some new additions.

Type annotations make code easier to read. Note: https://github.com/quantumlib/OpenFermion/pull/570 has not been merged yet so we won't be checking for now.

This PR has gone stale - I'll restart it now.


Modal Directives are not working

Hi Guys,
I am trying it out this plugin but the directives are being specified but are not working.
For example set animation to true and the modal will not be introduced with animation, even the backdrop.
<modal #modal [keyboard]="false" [backdrop]="'static'">
    <modal-header [show-close]="true">

I'm a modal!

    </modal-header>
    <modal-body>
        Hello World!
    </modal-body>
</modal>

Any help will be much appreciated. Thanks

Ok solved.
I forgot the bootstrap Css file.
Cheers


Fix footer at bottom

Issue Description:
When there are minimal or no restaurants found in the app, the footer is mispositioned and appears in the middle of the page. This issue affects the overall user experience and layout of the application. check out Footer.js component for the code
Expected Behaviuor:
The footer should maintain its proper position at the bottom of the page, regardless of the number of restaurants found in the app. It should not move to the middle of the page when there are few or no search results.

@Ravina-Deogadkar yeah sure, go for it
assigning it to you 🚀

hey @Anandsg  can i work on this issue

Hey there, @Rohit-Sharmaa! It's fantastic to see your enthusiasm. However, it seems that user @Ravina-Deogadkar has already forked the repo and started tackling on this issue. could you please check out the issue #4  and leave a comment? That way, I can assign it to you if you're up for the challenge. else you can explore the app and raise a new issue. Thanks!

@Anandsg No problem

@Rohit-Sharmaa Would you like to work on this issue?


EDGEX_SECURITY_SECRET_STORE is ignored while running in docker

I am trying to run core-keeper in non secure mode. I can run in non-docker mode by setting the above env on terminal. But in docker mode the value set to false in yml file is being ignored. Can you help?

this service hasn't been officially released.
We please to release it with v3.2 in the middle of this year.
However, you can still write down your question.  I don't understand what issue you are encountering.


[terra-menu] Add section headers

Feature Request
OCS requests the ability to render section headers within terra-menu.

Gathering multiple enhancements items for terra-menu into one combined issue: #1883


fix: Enable, instead of Configure, conflict detection

Customers often struggle quite a bit to figure out how to enable/disable conflict detection with the CLI.   They can do it via the top level "Enable DataStore for entire API" or "Disable DataStore for entire API" options, but if they choose to walk through all options, they are forced to explicit decide if conflict detection should be enabled or not.  I've been confused by this myself.  Initially I thought that the "Configure conflict detection?" step was just a question asking if I wanted to make a change to the current value.  That's not the case.  If you answer "y", it enables conflict detection.  If you answer "n", it disables conflict detection.  This PR changes the wording so that customers know that this is causing an action.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Approved, contingent upon verifying there aren't any scripts or ancillary processes that rely on this wording.

Yes, it would be great if someone from the CLI team can confirm this change.   I just did a simple find and replace, and am not familiar with the codebase at all.

Do we need to make doc updates as well? I believe our DataStore docs have references to conflict detection in the CLI.

Good call!  Here's a PR to update the docs: https://github.com/aws-amplify/docs/pull/2981/

Thanks @jhockett!  Please go ahead and merge this if you can, as I don't have write permissions to do so.


Drop support for QUIC 32

When Chrome stable drops support.

@lucas-clemente: I created a drop-32 branch, and removed all occurrences of Version32 throughout the code, except for the crypto package. It's used a couple of times in the key_derivation_test.go and crypto_setup_test.go, can you please take care of that?


socket.timeout: timed out

Hi,how can I set timeout in thriftpy?
I whrite like:
with client_context(dd_thrift.DingService, '<IP_ADDRESS>', 9090, proto_factory=dd_factory,
    socket_timeout=5000,connect_timeout=5000) as c:

But error:
UserWarning: `timeout` deprecated, use `socket_timeout` and `connect_timeout` instead.
warnings.warn("`timeout` deprecated, use `socket_timeout` and "
..........
..........
File "/usr/local/lib/python2.7/dist-packages/thriftpy/transport/socket.py", line 108, in read
buff = self.sock.recv(sz)
socket.timeout: timed out

Thanks!

Of course you can.
It seems like your service down..

@MrKiven
I am not sure set timeout in my server or client or both?

client

@MrKiven
My server is fine,but client set socket_timeout=5000 or 5000+ does not work, it is also default 3000.
When I count 3s, time out error come out.

server side default timeout is 3s, @lxyu

@MrKiven
When I use param like “timeout”,works!, but I notice warning:
UserWarning: `timeout` deprecated, use `socket_timeout` and `connect_timeout` instead.

timeout really deprecated?

yes, will use socket_timeout and connect_timeout, but if you set timeout, it also works

@MrKiven
thriftpy 0.3.8

I changed the default client_timeout in thriftpy/transport/socket.py from 3000 to None and now my server is working as expected, just like Apache implementation.
from:
class TServerSocket(object):
    """Socket implementation for server side."""

    def __init__(self, host=None, port=None, unix_socket=None,
                 socket_family=socket.AF_INET, client_timeout=3000,
                 backlog=128):

to:
class TServerSocket(object):
    """Socket implementation for server side."""

    def __init__(self, host=None, port=None, unix_socket=None,
                 socket_family=socket.AF_INET, client_timeout=None,
                 backlog=128):

I see I have the option to pass the timeout when creating a service manually. But the function make_server in thriftpy/rpc.py uses the default parameter for this. I didn't read all the source to figure out where to fix this. One option is passing explicitly client_timeout=None when creating the TServerSocket in make_server function. But It seems to me that the correct approach is setting the default timeout in the TServerSocket class initialization.

These 2 commits fixed it to me.
https://github.com/AllanDaemon/thriftpy/commit/6a4b118ab324b404bccf6358a7f0607ce805ef01
https://github.com/AllanDaemon/thriftpy/commit/0944247a8211f806c185472638dc411d43a14931
I running tests and I will write some tests for it latter before I make pull request. Does this solutions sounds ok?

Sorry for the late reply, the issue is because the client_timeout default set to 3000ms and the setting was not exposed in make_server helper function.
You may now pass the client_timeout=None to force the server side never timeout a client socket.
If it doesn't resolve your issue, feel free to reopen this thread.

Hello. I have thriftpy version 0.3.9 and collided with bug like @AllanDaemon report. As advised above, I replaced the value of client_timeout to None. And it worked. In this regard, I have a question. Maybe it makes sense to initially set the value to None? Thank you for attention.


A ConfigDict setting to infer a field type is optional if the default is None

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
In v1 giving a field a default of None implied the field was nullable (can be None), but in v2 this was changed.
I'm not sure why this was changed. If a field can be None by default, then this must mean it should be able to be None.
class Foo(BaseModel):
    f1: str  # required, cannot be None
    f2: str | None  # required, can be None - same as str | None
    f3: str | None = None  # not required, can be None
    f4: str = 'Foobar'  # not required, but cannot be None
    f5: str = None # <-- not really possible

Technically, the specification of required and nullable could be separate, agreed. But I can't imagine a possible use-case of f5. Maybe I'm missing one. Perhaps you are trying to reduce user-errors. Either way, I will of course excuse you for being (ehem) pedantic here.
So I propose a setting in ConfigDict that lets me opt in to implied optional. This will also make many migrations to Pydantic V2 much easier.
class Foo(BaseModel):
    model_config = ConfigDict(infer_optional=True)

    f1: str  # required, cannot be None
    f2: str | None  # required, can be None - same as str | None
    f3: str | None = None  # not required, can be None
    f4: str = 'Foobar'  # not required, but cannot be None
    f5: str = None # not required, implies can be None

Thank you so much for your hard work!
Affected Components

[X] Compatibility between releases
[ ] Data validation/parsing
[ ] Data serialization - .model_dump() and .model_dump_json()
[ ] JSON Schema
[ ] Dataclasses
[X] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

Selected Assignee: @adriangb

Originally from this tweet.
Personally I'd be okay with this. :+1:

I'm a little uneasy with this because it seems like a violation of the type system to assign None to a str field.
Do you want the schema to be nullable? If not, your problem may be resolved by disabling mypy's strict_optional configuration flag without needing any changes in pydantic. (I haven't verified this.)
If you want the schema to be nullable (i.e. the type of f5 should be considered str | None), it sounds a lot like mypy's implicit_optional configuration flag which does the same for function arguments. Maybe we should name the flag the same?

Interesting. I have to admit I don’t exactly understand how mypy works with pydantic.
This is definitely a runtime issue, pydantic will not allow the field to be None and I want it to specifically make it Optional/Nullable. If I set implicit_optional in mypy, I still wouldn’t be able to do it.
It looks to me as this was done in mypy specifically because some libraries would not do the implicit optional. So this seems to be a case of mypy being more restrictive because the lax version was not widely supported. Pydantic then followed suit, but, imo the runtime checker should be more lax (accepting of input) than the type checker.

You are fighting a losing battle here. The Python community, including MyPy, Pyright, etc. have decided that foo: str = None should not be allowed. I'll look into making this work in Pydantic but I don't think we should do it unless it's foolproof and easy to maintain.

Yes, but again, I think it’s probably right for the type checker to suggest that because the underlying schema system could require it. But pydantic is the underlying schema system so it shouldn’t.
Or at least let me make it optional like in mypy.
Thank you for considering it, I know you have a lot of trade offs to weigh.

This caught me by surprise as well.  After converting a large code base I still missed a few fields.
At the very least it would be nice to call it out in the Migration guide, something like:

State
Field Defintion

Required, cannot be None
f1: str

Not required, cannot be None, is 'abc' by default
f2: str = 'abc'

Required, can be None
f3: Optional[str]

Not required, can be None, is None by default
f4: Optional[str] = None

Not required, can be None, is 'abc' by default
f5: Optional[str] = 'abc'

Required, can be any type (including None)
f6: Any

Not required, can be any type (including None)
f7: Any = None

Not required, but cannot be explicitly set to None.  No longer works in V2. Consider switch to f8: Optional[str] = None
f8: str = None


Existing place or intermediate stops are lost after using “Directions to here”

Steps to reproduce:

Starting with a fresh instance of https://openrouteservice.org/map
Open the left sidebar
Type & find a place (e.g. Bismarckplatz Heidelberg)
Right-click on the map and select “Directions to here”
Existing Place is lost

Something similar:

Starting with a fresh instance of https://openrouteservice.org/map
Create any route with intermediate stops
Right-click on the map and select “Direct to here”
Intermediate Stops are lost

Thanks for open, but I is intentional.
The app has some states: place, directions, isochrones and roundtrip. There are ways to switch from an state to another, like by clicking on the directions button, for example.
When first loaded, the app starts in the place mode. You can find a place and see its location and detailsor even share it. If desired, you can switch to the directions mode and use the already selected place as a target destination, by clicking on the directions button. But if you just find a place and don't change to directions, then when you start directions mode following another path, then the previously focused place will be discarded. You could also jump from a selected place to isochrones, for example, and the place would be also lost.
I will close the issue for now. If any other aspect is added we may consider reopening it.

Just to be clear: You are saying it is intended that the intermediate stops are lost, when I just change the destination?

Currently there is no "Directions to here" option in the right click menu when a route is calculated and displayed.
the options are:
Append as destination -> add the selected point to the end of the route (not stop is lost)
directions from here -> change the initial point of the route (no stop is lost)
Add stop here -> a stop is added (no stop is lost)
Direct to here -> calculate a route that goes directly to the selected point (as the name says, stops will be lostand the origin kept)


Task referencing

Partially blocked by #9,  #10 and #11.
Add task function that allows referencing tasks.
The function would only take an uid as a reference and automatically generate the correct area reference for a task defined in the document.

Implemented in be12392a7a68bbff4f675b2b7a9b0c3c5bd06ad7


README.md calls for an in-source build

A recent commit (b0edb4b4826510f9d0bdd136d51100d5d73d75f3) added code that causes the build to fail if CMake detects an in-source build.
The ccmake directions in the README unambiguously tell you to run the configuration in the source directory, not the build directory. I tried following these directions, and they trigger a fatal error due to the in-source build. I think the documentation needs to be updated so that it doesn't guide new users directly into this fatal error.

Fixed in cac3864273c55e45950b859e4173dde9a402cbc6


Is this gem still maintained?

Just wanted to check if this Gem is still maintained and updated? I've attempted to use it and noticed that some of the dependencies are fairly obsolete. Wanted to check before attempting to get a working fork or if this gem is abandoned creating a new one based on this.
Thanks.

It's not being actively developed (or used by me at the moment), but I do try to review and merge PRs as they come up. Which dependencies in particular are you having problems with?

Thanks for responding. looks like hirb (which possibly isn't well maintained) produces warnings that trickle down to reports. Some details are here https://github.com/cldwalker/hirb/issues/103 (there is an open PR to fix that but it has been open for about 10 months without any activity)
The reason why I checked is that I was thinking about using another table generating gem for the output and wanted to check with you if this repo is still active before starting to implement it.

Gotcha. I'm happy to merge if you open the PR. Should be easy enough to swap out for another library.

Had some time so I went ahead and implemented this using terminal-table. v0.5 is up on rubygems now. Let me know if you see any issues still.

Thanks for updating it.


Uppercase PREVIEW should be used for .swift-version

As of https://github.com/kylef/swiftenv-api/pull/2.

Thanks for this and the other related PRs, glad we got this fixed.

Thank you very much! 🙏


Add allowClientClassCreation option

Implemented an existing feature of Parse API
Good for security

Wow thanks a lot, this PR looks awesome!


Failed to run test after recent upgrade.

neotest-rust: ...uzhiping/.local/share/nvim/lazy/neotest/lua/nio/init.lua:105: The coroutine failed with this message:
...share/nvim/lazy/neotest-rust/lua/neotest-rust/errors.lua:7: attempt to index local 'output' (a nil value)
stack traceback:
        ...share/nvim/lazy/neotest-rust/lua/neotest-rust/errors.lua: in function 'parse_errors'
        ...l/share/nvim/lazy/neotest-rust/lua/neotest-rust/init.lua:380: in function 'results'
        ...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:131: in function '_run_spec'
        ...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:89: in function <...al/share/nvim/lazy/neotest/lua/neotest/client/runner.lua:88>
Press ENTER or type command to continue

Can you provide an example that triggers this?

I was running this simple code:
#[cfg(test)]
mod tests {
    #[test]
    fn test() {
        let mut i: u8 = 255;
        i += 1;
    }
}

For some reason, it works now.

Sorry for the last post, this test fails:
#[cfg(test)]
mod tests {
    #[test]
    fn test() {
        let mut i: u8 = 255;
        i = i.wrapping_add(1);
        assert_eq!(i, 0);
    }
}

Seems to work for me, running neotest on this main.rs:
fn main() {
    println!("Hello, world!");
}

#[cfg(test)]
mod tests {
    #[test]
    fn test() {
        let mut i: u8 = 255;
        i = i.wrapping_add(1);
        assert_eq!(i, 0);
    }
}

@tubzby , did you try installing cargo-nextest with  cargo install cargo-nextest --locked? I was getting the same error but that fixed it.

It works now, I'm not sure what happened, sometimes when I run a test with key bindings, nothing happens, I have to switch to vs code to run the unit test.
Are there any logs that I can look into?

@rouge8  Same here

It seems the right command is cargo test not cargo nextest

@rouge8 Same here
It seems the right command should be cargo test not cargo nextest

No, that's not correct. As it says in the README, this plugin works with cargo-nextest.

yes thank you, doing cargo install nextest seems to do the trick

@rouge8 Hello!
I'v faced the same problem, at least the error I receive is the same as OP, but in my case I found out the reason.
I copied args for initialization from example:
require("neotest").setup({
  adapters = {
    require("neotest-rust") {
        args = { "--no-capture" },
    }
  }
})

That lead to cargo launches with args like
cargo nextest run --no-fail-fast --config-file /var/folders/0y/gvl9x07x341fhm6zq23ps9480000gn/T/nvim.coin/ROMNaO/0.nextest.toml --profile neotest --no-capture -E 'test(/^tests::/)'

And --no-capture lead to empty system-out/system-err nodes in xml result:
        <testcase name="tests::test_ref" classname="lobster-proxy::bin/lobster-proxy" timestamp="2023-08-12T22:26:57.410+00:00" time="0.004">
            <failure type="test failure"/>
            <system-out></system-out>
            <system-err></system-err>
        </testcase>

so the input to parse_errors method become nil.
I guarded with simple precheck for nil in local version like:
function M.parse_errors(output)
    if output == nil then
        return {}
    end
    local message, line = output:match("thread '[^']+' panicked at '([^']+)', [^:]+:(%d+):%d+")
<...>

It really took me a while, cause at the beginning I did know nothing about lua.
PS May be OP has another source of the problem, but i smashed my head a bit, before figuring out. Should I make a PR or it works like that by design?


Minor FR: URI to update current Theme

Analogue to the URI to update plugins, there could also be an URI to update the currently used theme.

I don't want to break anything, so I only want to click on the existing buttons. (A part of updating is handled in the button onClick function, which I cannot really call without pressing the button). In addition, I don't know how to find the proper button, because there are several buttons. All in all, I don't think I will add this feature.  I think once a week is enough. And I doubt that a URI is necessary.

Ah, I see, you are simulating button presses.
Well I was thinking about simply unifying the updates of plugins and theme. But its really not a necessary feature, indeed. Thanks for the explanation and all the other super quick updates!


Closing time sheet handed in by HiWi?

Once a time sheet is handed in, should it still be closable? what is the semantic of that?

When I get a physical signature while the time sheet is pending I don't need an accept anymore --> TS can be closed

Wouldn't accepting a handed in time sheet without adding a signature be basically the same as closing it?

Tested in spec/features/time_sheet/close_reopen_spec.rb


feat: make graphql-java-extended-scalars dependency optional

The dependency is no longer included automatically. Instead, the user of the library can decide whether this is needed or not.
Application startup will fail if com.graphql-java:graphql-java-extended-scalars is missing and there are extended scalars specified in the graphql.extended-scalars configuration property.
The primary incentive for this change was that com.graphql-java:graphql-java-extended-scalars 16.0.0 is not available from Maven Central (https://github.com/graphql-java/graphql-java-extended-scalars/issues/38), and including it automatically would enforce users of this library to use JCenter too.
An additional benefit is that if not used, it is not added to the classpath unnecessarily.

@BlasiusSecundus - some good news, v16.0.1 is now available in maven central.

The this PR is no longer essential.

Moved back to draft becaues in its current form this is essentially a workaround for an issue that was already solved.


Exception doc strings

https://github.com/lmichel/pyvo/blob/feature_mivot/pyvo/mivot/utils/exceptions.py

add a class docstring for each exception class telling in which case it is meant to be used

Docstring for exceptions is added


Review test coverage for composite builds configuration caching

@bot-gradle test QF

OK, I've already triggered QuickFeedback build for you.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test RFN

OK, I've already triggered ReadyForNightly build for you.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test RFN

OK, I've already triggered ReadyForNightly build for you.


published messages not seen by some tools

A very simple publisher, such as the chatter example in the readme, publishes messages that don't seem to be seen by all tools. rostopic echo /chatter sees them, but rostopic hz /chatter and rosbag record /chatter do not. I noticed this while investigating that a LabView node also does not observe the messages. Publishing the same with rostopic pub or a Python publisher and all tools observe the messages. Tried with Ubuntu 16 Mate/kinetic on a raspberry Pi, Ubuntu 18 Mate/melodic on x64, and even with RosOnWindows/melodic, same result everywhere.

Turns out it's tools that upon requesting a topic request a wildcard message type, instead of a fixed message type.

The wip branch should have that fixed now.

Thank you. I will test it on my systems.


3 probs: libusb in InitialSetup_X bat; ServerLog.h prevent Cmake config. SDL2/libusb require manual building

Libusb spits out erros like the following via the InitialSetup scripts. The thirdparty\libusb\msvc\libusb_2015.sln project is not plagued by this. I don't understand what the problem is. It's like it thinks there is more than one definition file:
  libusb-1.0.lib(core.obj) : error LNK2005: libusb_get_version already defined in libusb-1.0.lib(libusb-1.0.dll)
I think that just looks bad. FYI libusb has a strerror.c file that causes nightmares for people with multibyte locales. Maybe a wiki should mention it.
Unrelated: The CMake script appears to not locate thirdparty\SDL2. But really it just has to be built. I think -DHAVE_LIBC may have prevented it from building. I had to remove it due to 3 errors to get the current SDL2 code to build.
Lastly Cmake won't finish configuring because "src\psvrservice\Service\ServerLog.h" is missing it says. I added a blank file.
I don't know if https://github.com/HipsterSloth/PSVRTracker/wiki/Building-from-source has instructions for libusb and sdl because they are difficult or what, but it came in handy in my case.
Luckily Visual Studio seemed to download/setup OpenCV. Which was pretty cool. I didn't realize it was missing up to that stage. Some output lines suggest it used Vcpkg for that purpose:
3>  VcpkgTripletSelection:
3>    Using triplet "x64-windows" from "C:\vcpkg\installed\x64-windows\"
(OpenCV seems unnecessarily large. Maybe it's all necessary. I'm skeptical.)
I want to be of help. I hope I can be. Or at least, I hope I can get tracking working very well. And I hope I don't get in the way.

We've discussed this some here (https://github.com/HipsterSloth/PSVRTracker/issues/14) including some solutions.
I just want to reiterate that I feel the goto failure should be done away with file wide. I think the only reason I had to build SDL manually is probably that it came after libusb in the script. Had it been able to build after libusb failed, it would've saved me a lot of trouble.
I also want to stress that I believe there's something seriously wrong with building libusb with this script on my system. I don't understand what it is though. I think the command-line for it must be missing something that its generated project provides. (Example link error output is in the top-post details. I think using MSBuild that way is likely the problem. I have a feeling it's not equivalent to opening the SLN file and building it from within VS.)

GOOD NEWS.
I got stuck on the new OpenCV somehow. Trying to understand what it was doing... it was linking (somehow) against two different versions of OpenCV. One was 330d, and the other 320d.
Just barely I saw this in the output: /LIBPATH:"C:\vcpkg\installed\x64-windows\debug\lib"
Even though it's not in the projects listed directories, nor in its command-line. It's somehow injected by VS. I've also confirmed this is the libusb problem described here...
Basically, VS injects vcpkg. It somehow finds the library dependencies, even though they are not in the linker inputs. What's weird is it does this on the commandline, but not inside VS (opened to solution file.) Whereas with OpenCV it does happen inside VS.
Anyway, the problem is with vcpkg. But honestly, if it's picking up on vcpkg somehow, it would really be better if PSVRTracker were using the vcpkg system on Windows, and using packages on other systems too.
I installed these two packages via vcpkg in anticipation to link against them, only to find that I needed the other thirdparty externals, which also included these. Unfortunately, I did spend some time trying to get the CMake scripts to find the packages inside vcpkg without any success. It's broken going forward and backward... two different ways. The only fix seems to be to abandon vcpkg for the time being :(
E.g. 'vcpkg remove opencv libusb`

Oh! That is super interesting. Well for what it's worth, Chad Boulay (the
other maintainer of PSMoveService) is in the process of upgrading
PSMoveService to vcpkg literally this week. This means I need to get vcpkg
working on my machine anyway. So as part of this process I'll just switch
over to using vcpkg for PSVRTracker as well. Which I guess will be nice
because that would completely remove the need for the InitialSetup.bat
script correct (since the packages are pre-compiled)?
On Mon, Mar 11, 2019 at 9:40 PM Mick Pearson<EMAIL_ADDRESS>wrote:

GOOD NEWS.
I got stuck on the new OpenCV somehow. Trying to understand what it was
doing... it was linking (somehow) against two different versions of OpenCV.
One was 330d, and the other 320d.
Just barely I saw this in the output:
/LIBPATH:"C:\vcpkg\installed\x64-windows\debug\lib"
Even though it's not in the projects listed directories, nor in its
command-line. It's somehow injected by VS. I've also confirmed this is the
libusb problem described here...
Basically, VS injects vcpkg. It somehow finds the library dependencies,
even though they are not in the linker inputs. What's weird is it does this
on the commandline, but not inside VS (opened to solution file.) Whereas
with OpenCV it does happen inside VS.
Anyway, the problem is with vcpkg. But honestly, if it's picking up on
vcpkg somehow, it would really be better if PSVRTracker were using the
vcpkg system on Windows, and using packages on other systems too.
I installed these two packages via vcpkg in anticipation to link against
them, only to find that I needed the other thirdparty externals, which
also included these. Unfortunately, I did spend some time trying to get the
CMake scripts to find the packages inside vcpkg without any success. It's
broken going forward and backward... two different ways. The only fix seems
to be to abandon vcpkg for the time being :(
E.g. 'vcpkg remove opencv libusb`
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/HipsterSloth/PSVRTracker/issues/13#issuecomment-471854687,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQBA_UatRJQ_8E10dMktMEq0QgrGgQr6ks5vVy_BgaJpZM4baAD8
.

The benefit of vcpkg is it is a shared source, like most open-source operating systems have. It's meant to emulate Linux package systems on Windows. VS has a "NuGet" system, but I've never used it, and I don't know if it was unpopular with devs or what. So they made Vcpkg. Or someone in Microsoft did. It's still kind of new. Only popular libraries are on it.
From this experiment it seems like you are stuck with whatever version you have installed... since VS couldn't seem to understand that the 320d builds were not what was appropriate to the link command-line. The problem is, I have yet to see it used with CMake. There are a lot of articles, but what they recommend seems to not work. So it may be hard to mix with CMake. I will look at your scripts after you do it, and try to replicate them for some of my own projects :)

Note (see above reference to https://github.com/Microsoft/vcpkg/issues/4562) I took this to vcpkg. It's a near criminal design flaw/bug. I still don't understand how /LIBPATH:"C:\vcpkg\installed\x64-windows\debug\lib" is able to recruit *320d.lib when linking to *330d.lib. I think there must be more too it. Maybe there is a symlink like system in vckpg's lib folder.

Yeah that is pretty crazy. Isn't there a MSVC option for see more detailed output about how where it's pulling libraries from? Maybe I'm just thinking of the flag that generates the compiler intermediate files (header + cpp smoshed together).
In any event, thanks for writing up that detailed bug. Hopefully they can get that fixed soon. Sorry you had to do all that troubleshooting.

There are two options (I kind of remembered one) in the Project's Linker settings. I tried it with a vanilla library and it spat out the same output 6 times. I'm not sure how to interpret it. I guess it prints libraries when it opens them to try to find definitions.
A second option says it prints progress when linking... that sounds like a good option, especially when linking takes minutes. Or more. You can see how slowly my brain works. I had to get a nights rest to realize I should look into the status of that bug in the Vcpkg issue tracker. It's like my brain only works when I'm sleeping. The rest of the time I'm a mindless automaton.

Eureka! After a (second) night's rest, it occurred to me what's really happening here, is VS2015 doesn't have automatic vcpkg integration. VS2017 does. And running MSBuild.exe on the command-line must be using 2017 with the 2015 build C++ build chain.
That has to be why libusb failed on the command-line build. It occurred to me it's unlikely that the CMake script changed from 320d to 330d; that there is probably another explanation. The reason being, that OpenCV linked before because it wasn't using vcpkg.


Add model level tutorial notebook

Add new tutorial notebook showing how to convert ERA5 model level data to pressure levels. The met data is then used in the Cocip model.
GitHub rendering of notebook

One thing I think we should discuss is whether we're getting full value out of model-level data if we interpolate to pressure levels before feeding it to CoCiP. That's beyond the scope of this notebook, though, and I can elaborate elsewhere.

Interesting -- I could imagine a CoCiP implementation that runs natively on model levels. Is this what you're thinking?


Vertical scanner in portrait screen mode

I'm using custom scanner through DecoratedBarcodeView in my Fragment (like in example of Activity Custom Scanner).
Everything works perfect, but if phone in portrait mode - scanner line and detection are horizontal.
Could you help me please, how can I make it vertical (just for giving scanner mode data to scan), if phone will be only in portrait mode (it's locked to portrait mode)?
Like this:

Thanks in advance!

There is no built-in way to do this, so you'll have to dig into the source.
There are two parts to this:

The UI. This means changing / overriding ViewfinderView.

The decoding. For some barcodes (e.g. QR codes), the orientation doesn't matter. For others such as 1D barcodes, the TRY_HARDER hint may cause it to scan in both directions. Alternatively, you can rotate the image before decoding (may require changing the library source). You can do this by creating a custom Decoder and DecoderFactory.

Well, I'm ready to deal with diggin' into source, but I need some help with that.

ViewfinderView - which parameters depends on screen orienation (like with and height which we can swap, for example)?

I want to decode QR-codes and 1D also, you're right. Thanks for the hint - I'll try it. But I want to rotate scanner because my 1D also vertical - sounds strange but its special product barcode. And I want to give user more comfortable experience - avoid rotation of screen just to read code.
I thought that libraries decoder and viewfinder are connected with camera orientation, isn't it?

For ViewfinderView it's mostly just the red line that will have to be changed to vertical: https://github.com/journeyapps/zxing-android-embedded/blob/master/zxing-android-embedded/src/com/journeyapps/barcodescanner/ViewfinderView.java#L160
The result points may also be displayed in the incorrect location if the image is rotated for decoding.
The library always rotates the camera preview to match the current screen orientation. The easiest way to get it to work in vertical is to just rotate it by 90 degrees again, or to use the TRY_HARDER hint to make it decode in both directions.

Well, if I want to rotate camera just to make it scan vertical - which instance should I rotate by 90 degrees?
I tried to work with CameraInstance through the DisplayConfiguration (I swapped width and height counted in previewSized() of StateListener) - but it didn't get any result.
Could you help me, please? Which instance should I rotate? And how (like just rotation(int degrees) or smth else)?

You should not change the camera preview itself - that has to match the current screen orientation. You should rotate the image data just before decoding. If you are modifying the library directly, the easiest will be to change it here:
https://github.com/journeyapps/zxing-android-embedded/blob/master/zxing-android-embedded/src/com/journeyapps/barcodescanner/SourceData.java#L101
Alternatively you can create a custom Decoder and rotate it at this point: https://github.com/journeyapps/zxing-android-embedded/blob/master/zxing-android-embedded/src/com/journeyapps/barcodescanner/Decoder.java#L61

Am I right when thinking that if I try to rotate in SourceData perfomance will decrease very much? Or user won't match that?
And I need just to hardcode rotation in constructor, am I right?
Sorry for the silly as f*ck questions))

SourceData normally does the rotation anyway, so it won't make a significant difference.

And one more question. If I rotate sourceData will scanning area increase?
For example - in horizontal mode scanning area has width equal to width of screen. But in landscape mope it equals to screen height.
This is one more realon why I want to set it landscape - get more data for scanner (tested, that in landscape it scans better).
So, will scanning area increase or not?

That's up to you. Rotating will of course swap the width and height, but you can change the crop rectangle however you want.

Well, seems to be the best way - but which lib-classes I need to remake in my project for rotation SourceData? Try to find link between SourceData and BarcodeView

I used  <com.journeyapps.barcodescanner.DecoratedBarcodeView         android:id="@+id/zxing_barcode_scanner"         android:layout_width="match_parent"         android:layout_height="0dp"         android:layout_alignParentBottom="true"         android:layout_below="@+id/txt_scan"         app:zxing_preview_scaling_strategy="centerCrop"         app:zxing_use_texture_view="true" />
In java
barcodeScannerView.decodeContinuous(callback);
And got it working.

Moving discussion to #211.


Unix-style sockets - error 11, Resource temporarily unavailable

Hi guys,
If You have a moment pls look at this comment of mine. We tracked a possible issue with unix-style sockets (I merged ready pull request there). You will find there a small example to reproduce the issue.
The issue occurs when using unix socket with a lot of processes trying to connect in the same moment (starting 1 master instance and 100 slaves). Problem does not occur with TCP socket and TCPConnector.

Thanks for your report.
It looks like this is not related to this component at all. Is this the SocketClient that reports this error? If so, this is expected behavior, if your system reports that the resource may temporarily be unavailable. You will likely want to implement some higher-level protocol logic in this such, such as a back-off timer and re-trying etc.
I hope this helps :+1:
I'm closing this for now, please feel free to come back with more details if this problem persists and we can reopen this :+1:


DISTX-137 Cloud Storage Enhancements

Multi cluster zeppelin hangs if same cloud storage location is used, to overcome include cluster name in storage location config.
Unlike HDP, spark in CDH does not require any cloud storage.

Relates to #5235.


docs: Update ssmPrefix doc

Update ssmPrefix example to reflect the current behaviour https://github.com/serverless-stack/sst/commit/2f16a73daf77c800dc2b65bb2ebfe4d29a0e76fb

Thanks @hoangnd25!


Add support for enums in error message

Attempt to resolve https://github.com/webmozarts/assert/issues/289

God yes. I just bumped into this with Assert::nullOrOneOf($type, self::$allowedCarbonTypes)
Big +1

@gordinskiy recognizing that it has been a year... 😅 would you please rebase this?

@shadowhand done

@gordinskiy will you please add a test for this? It will need to be restricted to PHP versions that support Enum, of course.

Added test case for error message with enum in it.

Ok, it fails on old versions.
I can wrap enum declaration inside eval.
Would this be an acceptable solution or maybe you have a better one?
if (PHP_VERSION_ID >= ENUM_INTRODUCTION_VERSION_ID) {
    eval("
        enum TestEnum
        {
            case CaseName;
        }
    ");
}

Rather than doing an eval, I think it can be placed into a separate file and included. I don't want to use eval, even in a test.


Invalid syntax error on paper size with units

    "Invalid form data: form field 'paperWidth' is invalid (got '21cm', resulting to strconv.ParseFloat: parsing "21cm": invalid syntax); form field 'paperHeight' is invalid (got '29.7cm', resulting to strconv.ParseFloat: parsing "29.7cm": invalid syntax)"

Version: gotenberg/gotenberg:8
Error 400 Bad request when using units with paperHeight and paperWidth.

What’s the exact version you’re using? Try updating with:
docker pull gotenberg/gotenberg:8

okay I had an old version, I didn't check thanks


FSharpSymbol.ImplementationLocation points to definition in FSI file

File1.fsi
namespace Lib2
type TypeWithSignature =
    { Field1: int }

File1.fs
namespace Lib2
type TypeWithSignature =
    { Field1: int }

Library1.fs in different project
open Lib2
let x = { Field1 = 1 }

FSharpSymbolUse.Symbol for Field1 in Library1.fs has identical DeclarationLocation, ImplementationLocation and SignatureLocation:

This bug makes it very hard to implement this VFPT feature: https://github.com/fsprojects/VisualFSharpPowerTools/issues/1351

Yeah Ive got annoyed by that at times, jumping to the fsi is annoying

@dsyme could you please take a look at it? Maybe it's a 5-minutes fix for you.

Added a fix - next time you could probably have got this one :)

I tried it and the bug is still here:

Ah, I hadn't tried the multi-project case.  Well, the PR fixed a real bug in any case :)
The cross-project case may not be that easily fixable, since the F# metadata propagated between projects has only space for one range, see https://github.com/fsharp/FSharp.Compiler.Service/blob/master/src/fsharp/TastPickle.fs#L1975 for example.
When compiling a set of related projects using FCS in a single multi-project graph it's possible that we can propagate the extra information in a lookaside table of some kind.

It does not work for all cases even within single project.
Symbol returned in fs file (ok):

Symbol returned for the same symbol in fsi file (wrong):

Thanks
I believe it works correctly for results from whole project analysis using ParseAndCheckProject - at least that is under test and appears to work.
I assume the above signature symbols are just from checking a single signature file using ParseAndCheckFileInProject?  That case is also tricky, since as things are done now the corresponding matching implementation file is not checked for the single file, so the matching implementation location is not even known.  I'm not sure what to do about this, it feels like it needs an API addition.
The locations should be correct for results from GetBackgroundCheckResultsForFileInProject if you first ask for the results for the implementation file, and then the signature file.

Thanks.
OK, I wrote this code:
let (|SignatureFile|_|) file =
    if Path.GetExtension file = ".fsi" then
        let implFile = Path.ChangeExtension(file, ".fs")
        if File.Exists implFile then Some implFile else None
    else None

let! results =
    match currentFile with
    // it's signature file and the impl file presents
    | SignatureFile implementationFile ->
        async {
            let source =
                openDocumentsTracker.TryGetDocumentText implementationFile
                |> Option.getOrTry (fun _ -> File.ReadAllText implemen
            // check impl file
            let! _ = instance.ParseAndCheckFileInProject(opts, implementationFile, source, stale)
            // check sig file
            let! _ = instance.ParseAndCheckFileInProject(opts, currentFile, source, stale)
            // get background check results for sig file
            return! instance.GetBackgroundCheckResultsForFileInProject(opts, currentFile)
        }
    // this is how it previously works
    | _ -> instance.ParseAndCheckFileInProject(opts, currentFile, source, stale)
    |> liftAsync

When I try results.GetSymbolUseAtLocation, it returns None. However, results.GetAllUsesOfAllSymbolsInFile returns the proper symbol use:

Maybe GetSymbolUseAtLocation uses ImplementationLocation hence None?

Perhaps this:
             let! _ = instance.GetBackgroundCheckResultsForFileInProject(opts, implementationFile)
           // get background check results for sig file
            return! instance.GetBackgroundCheckResultsForFileInProject(opts, currentFile)

However, if this works at all, it will only work for the contents of the signature and implementation files as reported by the IFileSystem - not for a source text passed as a parameter.
Calls to ParseAndCheckFileInProject on a signature file will currently always return symbols where the ImplementationLocation is None.  We really need a way to check both the updated signature and implementation together (or else you save the files - or have IFileSystem report updated results - and use the above techniques)


When system image name cache, alias latest

To identify system containers, we look for images containing our system label and we add those images to a cache that can be used on every 5 second ping where we report images.
This had a bug where in a container would say its image was 'rancher/agent' but the image reported by docker when list images was 'rancher/agent:latest'
To fix, when building the image cache, we'll rop ':latest' so that both 'rancher/agent:latest' and 'rancher/agent' are in the name cache.

This bug was causing out of memory because the container was continually being reported to rancher during ping and a container event was being created for it every 5 seconds.

LGTM


Feature Request: Specify Python version in Pack Metadata

SUMMARY
Let packs specify their required Python version (python2 or python3) in pack.yaml.
Then when ST2 installs those packs, it should use the specified Python version.
This will let packs be installed from Web UI, and ensure that appropriate Python version is used, avoiding confusion when actions do not work as expected.
ISSUE TYPE

Feature Idea

DETAILS
The default Python version used for virtualenv setup is python2. Users can install packs using --python3 to change this.
There is no way for a pack to signal that it needs python3. We should have something like python_version=3 in pack.yaml. This value can also be made available via the StackStorm Exchange index.json.
If set to 3, ST2 should automatically use Python3 when installing the pack. Otherwise it should default to 2.
In future, we could make the default version 3, unless otherwise specified (Obviously this requires updates to Exchange packs, and GA Py3 support across ST2).

+1 i like this idea! I also like the forward thinking approach is switching to Python 3 as the default in the future.

Recommend requiring SemVer for the version description, and it would be nice to support the ~= style of "I can use any 3.x" or "I can use any 3.6.x".

I agree with @jeking3 - we should use semver which we already use for stackstorm_version attribute.
In fact, I think we should follow the same format as we use for stackstorm_version.
For backward and forward compatibility reasons, we should assume it works with any Python release if that attribute is not specified (we handle stackstorm_version in the same way).
It's also worth noting that python3 parameter is only there as a short term solution and "mixed Python version" deployments have multiple issues / edge cases and going forward (once Python 3 is officially supported) we won't advertise mixed versions support anymore.


boats show in garage with the cars

boats show in garage with the cars
and markers are blinking

i dont know how the user manages to get boats in the garage; perhaps your setup reuses the same database table with another plugin.
First Issue helpers:
A simple filter is all that is required while listing. More advance feature however would be to configure garages as valid for boats, planes, helicopters, or vehicles.

i dont know how the user manages to get boats in the garage; perhaps your setup reuses the same database table with another plugin.
blinking marker seems like FiveM may have updated. If you can record a gif of it and create a new issue that would be awesome.
First Issue helpers: A simple filter is all that is required while listing. More advance feature however would be to configure garages as valid for boats, planes, helicopters, or vehicles.

really thanks for so fas replying i ll try to find away to create a gif (sorry for my eglish)

i dont know how the user manages to get boats in the garage; perhaps your setup reuses the same database table with another plugin.
blinking marker seems like FiveM may have updated. If you can record a gif of it and create a new issue that would be awesome.
First Issue helpers: A simple filter is all that is required while listing. More advance feature however would be to configure garages as valid for boats, planes, helicopters, or vehicles.

https://youtu.be/1M9OfgaG3oE   tis is a video with the blink issue

i dont know if that helps but i noticed that this blink issue does not happens to all parking spots, but in some of them...


ReadMee Copy

WIP
What does this PR do?

Description of Task to be completed?

How should this be manually tested?

What are the relevant Trello Card stories?  Trello Card Item

Pull Request Type (check one)

[ ] Feature
[ ] Bug Fixes
[ ] Chore

Developer Checklist

[ ] New code has been scanned for ESlint issues
[ ] I have tested my code locally
[ ] I made sure that there are no other pull requests that solve for this issue
[ ] My code follows the same structure within the guidelines

Screenshots (if appropriate)

@Easybuoy  Yeah, that would totally help clear some of the issues we currently have and those we'll be having later. I'll create an issue to this effect and work on it. Cool?

@Easybuoy Yeah, that would totally help clear some of the issues we currently have and those we'll be having later. I'll create an issue to this effect and work on it. Cool?

Let's get @Bedrock02 thought on this, maybe he might want to do it as part of this PR

ya this makes sense @Easybuoy I like how #ios has it.
@samakintunde37 feel free to push those changes to this branch I can review later. Feel free to ping me as well.

I'll get on it right away.

I reckon we'll have to decide on a specific package manager since having generated lockfiles from both yarn and npm could cause issues. I get warnings from this in the terminal when I do it but I haven't any experience with such issues.

@Easybuoy @Bedrock02 Wanna take a look at what we've got?

warnings from

I reckon we'll have to decide on a specific package manager since having generated lockfiles from both yarn and npm could cause issues. I get warnings from this in the terminal when I do it but I haven't any experience with such issues.

Yeah true, what we can do to solve this is to delete both lock files and add them to the .gitgnore file

@Easybuoy @Bedrock02 Wanna take a look at what we've got?

Looks good, we need to add a link from the README to the CONTRIBUTIONS, because the README is the first sort of documentation people would see when they first get on the repository

I'll update the Readme. While I'm doing that...

delete both lock files

...shall I handle this or we do it in a separate PR?

I'll update the Readme. While I'm doing that...

delete both lock files

...shall I handle this or we do it in a separate PR?

You can do it on this PR

Looks good

If you're done, remove the WIP label @samakintunde37

Great. I'm done.

great work @samakintunde37 thanks


Fix broken BasisTranslator translation error link

Summary
Fixed broken link present in TranspilerError exception's message
Details and comments

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
22 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.03%) to 89.565%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
4
91.86%

crates/qasm2/src/parse.rs
18
96.69%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
62435

Relevant Lines:
69709

💛  - Coveralls


[UNDERTOW-2036][UNDERTOW-2034][UNDERTOW-2035][UNDERTOW-2060][UNDERTOW-2066][UNDERTOW-2067][UNDERTOW-2068][UNDERTOW-1945][UNDERTOW-2079][UNDERTOW-2080][UNDERTOW-2074]Port fixes to 2.2.x branch

Jiras:
https://issues.redhat.com/browse/UNDERTOW-2036
https://issues.redhat.com/browse/UNDERTOW-2034
https://issues.redhat.com/browse/UNDERTOW-2035
https://issues.redhat.com/browse/UNDERTOW-2060
https://issues.redhat.com/browse/UNDERTOW-2066
https://issues.redhat.com/browse/UNDERTOW-2067
https://issues.redhat.com/browse/UNDERTOW-2068
https://issues.redhat.com/browse/UNDERTOW-1945
https://issues.redhat.com/browse/UNDERTOW-2079
https://issues.redhat.com/browse/UNDERTOW-2080
https://issues.redhat.com/browse/UNDERTOW-2074

I reviewed THIS PR successfully and I confirm it is allright @fl4via


revisit github code on master

see
https://github.com/Jumpscale/jumpscale_core8/blob/master/lib/JumpScale/clients/github/Github.py

there is a serious conflict between master & branch ays_consume
code got moved into github client which

is not specific to github, is for all git
is now 90+% duplicate code with install tools
was trying to fix something which was not broken at first place

we need to check

do we need this change, if yes why
the executor in installtools is indeed a hack, but is it OK to leave ? what are downsides?

We could move the github work to git.
But we shouldn't just revert the changes
Having the executor in InstallTools:

Logically doesn't make sense. This is supposed to be only for bootstrapping.
The executor that gets set as self here is wrong in every possible way
This breaks JS installation, because having set executor to self, instead of an executor object (which isn't even available at this time), the executor doesn't have cuisine, which is referenced here

there are more items in install tools using cuisine, potentially argument can be made that this is still better than duplication
executor to None should be better but then again its lots of extra work, someone should look into this
it should not break js installation, it didn't before so something changed then?

lets discuss but for now we need something working for

install
for cuisine

and needs to be working NOW
without breaking all kinds of other things like we did before

We already have a lot of duplication, especially in FS.
So far the executors are only in the git methods. If we're going to add executors to InstallTools methods, we might as well do it right.
For now, I'll do a quick fix to keep the installation working, but we need to take a conscious decision regarding which approach we'll take.


OOM crash on ./gzemnid.js depsdb

(16:09:40) jamie@woody ~/Desktop/node-threadpool-use/Gzemnid $ tail -30 /tmp/gzemnid_debsdb
Read 510000...
Read 520000...
Read 530000...
Read 540000...
Read 550000...
Read 560000...
Read 570000...

<--- Last few GCs --->

[16616:0x3643a30]   480457 ms: Mark-sweep 1403.2 (1483.9) -> 1403.2 (1452.9) MB, 1703.3 / 0.0 ms  (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1724 ms) last resort GC in old space requested
[16616:0x3643a30]   482227 ms: Mark-sweep 1403.2 (1452.9) -> 1403.2 (1452.9) MB, 1769.0 / 0.0 ms  last resort GC in old space requested

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x28e0da6a5ee1 <JSObject>
    1: /* anonymous */ [/home/jamie/Desktop/node-threadpool-use/Gzemnid/node_modules/jsonparse/jsonparse.js:~342] [pc=0x2093e9cad6f4](this=0x3b7c97682449 <Parser map = 0x1c2a26b5bb71>,token=1,value=0x285bb0f65161 <String[1]: {>)
    2: /* anonymous */ [/home/jamie/Desktop/node-threadpool-use/Gzemnid/node_modules/jsonparse/jsonparse.js:~127] [pc=0x2093e9c9db63](this=0x3b7c97682449 <Parser map = 0...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x121a7ac [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [node]
 6: v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) [node]
 7: 0x2093e9b0463d

This happens during the resolved stage; it happened again when I ran
./gzemnid.js debsdb resolved.
just after "Read 560K".

Possibly addressed by --max-old-space-size as noted at the top of the README.

Yes, it should be run with --max-old-space-size=2000 or above.
Perhaps this needs a wrapper script that sets that flag and/or a check that prints a warning if specific commands (including depsdb) are executed without increased memory limit.
Could you confirm that it works with --max-old-space-size=2000?

Could you confirm that it works with --max-old-space-size=2000?

It works!

Perhaps this needs a wrapper script that sets that flag and/or a check that prints a warning if specific commands (including depsdb) are executed without increased memory limit.

Good idea.

@davisjam
This is now fixed by d85854a880d5a3acdc6e10df628db5695234ac39 and d85854a880d5a3acdc6e10df628db5695234ac39, which significantly reduce the memory usage of depsdb so it now fits in the default limit.
Automatic re-launching with --max-old-space-size could be done later if/when required.


"zoogrpahy" is a mispelling of zoography which is already in the table

Please remove "zoogrpahy" from the list since it's not a word.

@Borthralla thanks for reporting this typo. 👍
If you have time, please remove the incorrect word via Pull Request.
Thank you!

Made a PR:
https://github.com/dwyl/english-words/pull/61

@Borthralla thanks again for fixing it so quickly. 👍


feat: support v1-style BuildPipelineSelector pipelineRef

Description
The name+bundle pipelineRef style is deprecated, Tekton API v1 will support only the resolver+params style 1. Build-service added v1 support in https://github.com/redhat-appstudio/build-service/pull/205.
Add support for v1-style pipelineRefs by taking the bundle reference either from the 'bundle' attribute or from the 'params'.
Issue ticket number and link
STONEBLD-1772
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Via branch pairing in https://github.com/redhat-appstudio/infra-deployments/pull/2709
Checklist:

[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added meaningful description with JIRA/GitHub issue key(if applicable), for example HASSuiteDescribe("STONE-123456789 devfile source")
[ ] I have updated labels (if needed)

/lgtm

/approve

/lgtm
/approve

/retest


iFrame not supported for interactive requests.

We need to document that for non-silent requests aka interactive requests, iFrames are not supported. Sign-in requests should be done from the top level window. This needs to be documented in both the OAuth2/OIDC and SAML docs.

@willfiddes
Could you elaborate you query. So, it can be helpful to redirect to particular service area and we can help you.
It would be great if you could add a link to the documentation you are following for these steps? This would help us redirect the issue to the appropriate team. Thanks!!


Node-RED Server Crashes with JSON Syntax Error When Controlling Meross MSS310 Plugs

I installed the meross node to control some MSS310 plugs. I followed all instructions and got the token and IP of the plug (which is connected, pings fine, and is controlled well by the app). Issue is, when try to send msg.payload TRUE to the node, the node-red server crashes and restarts with this error log:
''''
13 Jan 01:08:55 - [red] Uncaught Exception:
13 Jan 01:08:55 - [error] SyntaxError: Unexpected token P in JSON at position 0
at JSON.parse ()
at Request._callback (/home/pi/.node-red/node_modules/node-red-contrib-meross/meross/smartplug-control.js:68:19)
at self.callback (/home/pi/.node-red/node_modules/request/request.js:185:22)
at Request.emit (node:events:517:28)
at Request.emit (node:domain:489:12)
at Request. (/home/pi/.node-red/node_modules/request/request.js:1154:10)
at Request.emit (node:events:517:28)
at Request.emit (node:domain:489:12)
at IncomingMessage. (/home/pi/.node-red/node_modules/request/request.js:1076:12)
at Object.onceWrapper (node:events:631:28)
at IncomingMessage.emit (node:events:529:35)
at IncomingMessage.emit (node:domain:489:12)
at endReadableNT (node:internal/streams/readable:1400:12)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
nodered.service: Main process exited, code=exited, status=1/FAILURE
nodered.service: Failed with result 'exit-code'.
''''
node-red version 3.1.3
node-red-contrib-meross 2.2.1
Node.js v18.19.0
Running on a Raspberry Pi 4B with OS Debian GNU/Linux 12 (bookworm)
Any help appreciated

@zoppolig is TRUE sent as string or as boolean? Did you try sending 1 (number) instead of true?


feat: add layout component Wrap

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

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

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


Add a space

I think the last section:

Additional Resources

ASP.NET MVC Facebook Birthday App

should be removed (and from the toc as well!) because the tutorial is retired and It's kinda confusing to click the link and redirected to the get started!

@badersur Thank you for adding the space. Are you interested in submitting a PR to remove the retired tutorial? I agree it shouldn't be there.

You're welcome! and yes I'm!