new service reference landing page for azure networking

Docs Build status updates of commit 8d017be:
:clock10: Full build: the average full build time is 7 min(s) 54 sec(s), this is based on the last 767 build(s) for this repository.

Docs Build status updates of commit 8d017be:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 1fa5376:
:clock10: Full build: the average full build time is 7 min(s) 58 sec(s), this is based on the last 782 build(s) for this repository.

Docs Build status updates of commit 1fa5376:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit efbcfcf:
:clock10: Full build: the average full build time is 7 min(s) 58 sec(s), this is based on the last 783 build(s) for this repository.

Docs Build status updates of commit efbcfcf:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 913af05:
:clock10: Full build: the average full build time is 7 min(s) 58 sec(s), this is based on the last 784 build(s) for this repository.

Docs Build status updates of commit 913af05:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 684f9a4:
:clock10: Full build: the average full build time is 7 min(s) 59 sec(s), this is based on the last 785 build(s) for this repository.

Docs Build status updates of commit 684f9a4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 2172df5:
:clock10: Full build: the average full build time is 7 min(s) 59 sec(s), this is based on the last 787 build(s) for this repository.

Docs Build status updates of commit 2172df5:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit aea7992:
:clock10: Full build: the average full build time is 8 min(s), this is based on the last 790 build(s) for this repository.

Docs Build status updates of commit aea7992:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit fa2a812:
:clock10: Full build: the average full build time is 8 min(s), this is based on the last 791 build(s) for this repository.

Docs Build status updates of commit fa2a812:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 8fce1d7:
:clock10: Full build: the average full build time is 8 min(s), this is based on the last 793 build(s) for this repository.

Docs Build status updates of commit 8fce1d7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 8ffa6d4:
:clock10: Full build: the average full build time is 8 min(s), this is based on the last 796 build(s) for this repository.

Docs Build status updates of commit 8ffa6d4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 130b878:
:clock10: Full build: the average full build time is 8 min(s) 1 sec(s), this is based on the last 797 build(s) for this repository.

Docs Build status updates of commit 130b878:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-conceptual/TOC.yml
:warning:Warning
View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid) View (azure-cli-latest)
Details

docs-ref-conceptual/azure-cli-reference-for-networking.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

docs-ref-conceptual/TOC.yml

Line 0: [Warning-InvalidFileLink] Invalid file link:(~/docs-ref-conceptual/azure-cli-reference-for-network.md).
Line 0: [Warning-InvalidFileLink] Invalid file link:(~/docs-ref-conceptual/azure-cli-reference-for-network.md).
Line 0: [Warning-InvalidFileLink] Invalid file link:(~/docs-ref-conceptual/azure-cli-reference-for-network.md).

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 8916f86:
:clock10: Full build: the average full build time is 8 min(s) 1 sec(s), this is based on the last 798 build(s) for this repository.

Docs Build status updates of commit 8916f86:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/TOC.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid) View (azure-cli-latest)

docs-ref-conceptual/azure-cli-reference-for-network.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 405ad4d:
:clock10: Full build: the average full build time is 8 min(s) 1 sec(s), this is based on the last 799 build(s) for this repository.

Docs Build status updates of commit 405ad4d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/TOC.yml
:white_check_mark:Succeeded
View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid) View (azure-cli-latest)

docs-ref-conceptual/azure-cli-reference-for-network.md
:white_check_mark:Succeeded
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


re-implement Stand-Alone Self-Attention model

Hi, @csrhddlam
As we discussed before, I am trying to re-implement the baseline "Conv-stem+Attention" in Stand-Alone Self-Attention in Vision Models, which is referred in your paper.
Could you please help check the correctness? It will be better if you could provide further optimization of this implementation. Thanks!

Hi, @d-li14
Thanks for contributing. It looks correct to me, but the unfolding implementation could take a lot of memory. Could you check if the model really runs on 224x224 images and if it can reproduce the results in the paper?
Thanks!

Yes, it is very memory-consuming, a simple test shows more than 7G memory is used with 8 images per GPU.
I will try to verify the accuracy of this model.


Move to core?

There are places it would be useful, as we could eliminate the need for FFI usage in exists, for example. /cc @paf31

:+1: if @hdgarrood is ok with it.

Oops, of course, sorry @hdgarrood I didn't mean to leave you out of it! :smile:

I'm watching anyway :) :+1: from me too.

Thanks!


Libbulletjme is missing natives for macos arm

First reported on the discord here, with a crashlog being provided. It seems like there's a workaround available, if you launch the modpack with an x86_64 version of java then java will run inside of Rosetta. Libbullet does have x86_64 macos natives

The natives that crash are part of rayon, which are a dependency of the gravity gun mod. It appears like worldshell also includes natives. It seems like Rayon uses the libbulletjme wrapper for bullet, whilst worldshell uses bullet directly.


Clarify EventTime msgpack extension

msgpack has 2 extension mechanisms:

fixext for fixed length extension data where len(data) in (1,2,4,8,16), and
ext for variable length extensions

Wiki (https://github.com/fluent/fluentd/wiki/Forward-Protocol-Specification-v1#eventtime-ext-format) specifies extension starting byte C7, however:
example seems wrong: variable-length extensions need a size byte, thus message would be c7 08 00 <8 bytes data> (notice extra 08 byte after c7).
payload is 8 bytes, thus msgpack uses fixext format, and thus message becomes d7 00 <8 bytes data> (notice d7 instead of c7).
Python sample:
In [21]: binascii.b2a_hex(msgpack.packb(msgpack.ExtType(code=0,  data=b'w'*8)))
Out[21]: b'd7007777777777777777'

References:
https://github.com/msgpack/msgpack/blob/master/spec.md#ext-format-family

I see what you mean. It's mistake of documentation.
IMO EventTime can be represented by fixext8(d7), or ext8(c8) (or larger).
There's no matter whether d7 or c8 is used.
I'll fix it later.

I updated the spec.
Diff: https://github.com/fluent/fluentd/wiki/Forward-Protocol-Specification-v1/_compare/d201bfe951d240e92b27705dc8d1af071bad0a39...0bac7c47d3852e45f3ec93c4b3a03cb96c9392f2
Thank you to let me know about it!

I think it's c7 08 00 (tag, length, type code) per https://github.com/msgpack/msgpack/blob/master/spec.md#ext-format-family

Oops, you're right...

Done :P


Fix bad method call

The signature of this method was changed, but this particular call was never updated to use the new signature.

👍


Bluesky logo

Icon name
bluesky
Use cases
Bluesky social icon for blogs and sharing
Design ideas
Reference https://blueskyweb.xyz/blog/12-21-2023-butterfly
Checklist

[X] I have searched if someone has submitted a similar issue before and there weren't any. (Please make sure to also search closed issues, as this issue might already have been resolved.)
[X] I have searched existing icons to make sure it does not already exist and I didn't find any.
[X] I am not requesting a brand logo and the art is not protected by copyright.
[X] I am not requesting an icon that includes religious, political imagery or hate symbols.
[X] I have provided appropriate use cases for the icon(s) requested.

Brand icon

Oh, why?

Oh, why?

When submitting this issue you should've seen the notice explaining why:

Important note: No new brand logos are allowed, see https://github.com/lucide-icons/lucide/issues/670.
Existing brand icons will also be phased out. For brand icons, consider using https://simpleicons.org/, which offers purpose-built SVGs that are also on a 24×24px grid.

Super, tnx!


Github Actions: Updates rubies and rails

Updates actions
Updates ubuntu version

Feel free to take over, otherwise I might have some time later tonight.

Seems to be failing on Rails 7.1 and Ruby 3.1
`check_for_activated_spec!': You have already activated error_highlight 0.3.0, but your Gemfile requires error_highlight 0.6.0. Since error_highlight is a default gem, you can either remove your dependency on it or try updating to a newer version of bundler that supports error_highlight as a default gem.

@deivid-rodriguez Do you have any suggestion on what to do about it?
https://github.com/davidwessman/formtastic/actions/runs/8168787148/job/22331544896?pr=1


[feat] Improve smart mode to reduce unnesessary work

At the moment, if a list of applications is explicitly defined, by a user or via the Smart Mode, myks processes applications from the list for all specified or discovered environments. This is not a problem for the use case when a user selects what to process, because, usually, there is no need to process at the same time different applications in different environments. However, it is not optimal in the case of the Smart Mode, as it can precisely define what needs to be processed. Instead, if one application in a single environment requires processing, it will be processed in all discovered environments even if this is not required.

This requires refactoring the data structures used to pass environment and application names around. In a nutshell, instead of two lists of strings, we need to combine envs and apps into a map.


Add paid-for endpoints?

Would you consider expanding the API to cover non-free bits of the service as well? And/or accept PRs to do so?

I would accept PRs for sure. I did include most paid endpoints but only for standard subscription which is what I can pay for as an individual. I wasn’t sure how to test the professional endpoints. I can just assume the same response format.

I think that's reasonable - you could just note it's untested and let users report any issues.

Thanks a lot for your feedback! I can probably implement these changes quickly. Mind if I tag you as a PR reviewer when ready?

Not at all.


OWNERS: Add Barakmor1 as sig-compute-reviewer

After reviewing the checklist requirements:

[x] I’ve been a member of the project for over 3 months.
[x] I’ve acted as the primary reviewer for at least 5 PRs: Involvement in code reviews.
[x] I’ve reviewed or merged more than 20 substantial PRs: Authored and merged PRs.
[x] I have knowledge of the project’s architecture, particularly around CPU topology and node labeller.

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

NONE

Thank you @Barakmor1 for your many contributions!
/lgtm
Will approve in a few days if there are no objections :+1:
/cc @jean-edouard

/lgtm

/lgtm

/approve
Absolutely, Thanks @Barakmor1 !


Does an Agent using FastDDS have Discovery QoS Configuration?

Issue
I tried applying the Discovery configuration from the link, but it doesn't seem to be working. Can an agent using FastDDS apply the QoS settings provided in the link when sending information via DDS?
Fast-DDS link
https://fast-dds.docs.eprosima.com/en/latest/fastdds/discovery/static.html#static-edp

Yes, you can configure Fast DDS profiles using the environment variable FASTRTPS_DEFAULT_PROFILES_FILE as explained here: https://fast-dds.docs.eprosima.com/en/latest/fastdds/xml_configuration/xml_configuration.html

Yes, you can configure Fast DDS profiles using the environment variable FASTRTPS_DEFAULT_PROFILES_FILE as explained here: https://fast-dds.docs.eprosima.com/en/latest/fastdds/xml_configuration/xml_configuration.html

Thank you for your Answer.
I've reviewed the document you provided and attempted to run a simple simulation. however, it seems that Static Discovery is not functioning in the Agent
If Static Discovery is possible to the Agent, please let me know the method.
Simulate Task

Create an XML including <EDP>STATIC<EDP> and check the Discovery Change (Attachment 1)

FASTRTPS_DEFAULT_PROFILES_FILE="XML location"
run ros2 demos
<IP_ADDRESS> is apply the Static(fast-dds), 0.4 is normal Fast-dds

Apply the same XML file to the Agent and verify the Discovery Change (Attachment 2)

FASTRTPS_DEFAULT_PROFILES_FILE="XML location"
run "MicroXRCEAgent udp4 -p 8888"
<IP_ADDRESS> is apply the Static(agent), 0.4 is normal Fast-dds  and 0.2(agent) remained the same packet length regardless of the Discovery setting

Discovery changes were observed in FAST-DDS, but it seems that there were no changes in the Agent.
Attachment1

Attachment2


clarify "is an object or function"

In "2.3.3. Otherwise, if x is an object or function",
it's not clear what "is an object or function" means.
My first guess was this:
(1) `x instanceof Object || x instanceof Function`

which seems to give the correct answer on values I tested it with.
However, apparently x instanceof Function implies x instanceof Object
(at least on values I tested it with), so the following seemed sufficient:
(2) `x instanceof Object`

However, the compliance test flunked that, complaining that my implementation
didn't examine x.then in some cases when it should have
(namely when "x is an object with null prototype").
So I tried switching from instanceof to typeof,
and after some experimenting came up with this:
(3) `typeof(x) === 'object' || typeof(x) === 'function'`

But the compliance test flunked that too, complaining that my implementation
behaved wrongly on x=null.
Finally I tried this:
(4) `x!==null && (typeof(x)==='object' || typeof(x)==='function')`

And finally the compliance test passes.
I don't think this was time well spent,
nor do I think it's tenable for the compliance test
to be the arbiter of what the spec means.
If the spec means exactly (4), it would be better if it would say that.

It means "If Type(x) is Object", as we are talking about spec-level semantics here. There is no other meaning of "object" that could be relevant in this context.
The "or function" addendum was put there as a gentle reminder that all functions are objects as well, i.e. that the callability of x doesn't matter.
Your (4) expression is an implementation of the predicate, but not more than that. There are many other possible implementations, and none should be used in the specification.

@bergus, thanks for your reply and helpful links.
I know your wikipedia link was at least half-joking, but I do want to point out in seriousness that there are at least 3 different meanings of "object" in the context of javascript, and it doesn't look to me like the ECMAScript 2105 spec is very successful at sorting them out.

It means "If Type(x) is Object", as we are talking about spec-level semantics here. There is no other meaning of "object" that could be relevant in this context.

Perhaps that's true, but it's not at all obvious to me, even after you pointed it out and after I've gone over sections 4 and 6 of the ECMAScript spec to which you referred.  In particular, my (1) and (2) still look like pretty good guesses to me, aside from the fact that the compliance test suite flunks them (which could actually be a bug in the test suite, for all I know).
I doubt I'm alone in this, among your intended audience of promise implementers.

Your (4) expression is an implementation of the predicate, but not more than that. There are many other possible implementations,

I'd be interested to see some of the "many other possible implementations" you have in mind, if you care to share.  I only know of (4), and I got that by fumbling around in the dark til the test passed.

and none should be used in the specification.

Can you say more about why you feel that none of them should be mentioned?  From my point of view, spelling out one of them for definiteness sure sounds like a good thing-- it would have saved me a substantial amount of time and aggravation.

Actually, my reading of Table 35 is that my (4) is not a valid test for the Object type after all, despite the fact that the compliance test suite passes it.  The reason I believe (4) isn't valid is that, according to the last line of that table, if x is an "Object (non-standard exotic and does not implement [[Call]])" it might be that typeof(x) is "foobar".  In that case (4) will wrongly conclude x is not an Object.
Please confirm.

In fact, it looks to me like Table 35 completely nails down the relationship between Object-ness and the typeof operator.
This appears to be more solid than I previously thought.
So, it looks to me like the following is a (the?) correct test for Object-ness:
x !== null &&
typeof x !== "undefined" &&
typeof x !== "boolean" &&
typeof x !== "number" &&
typeof x !== "symbol" &&
typeof x !== "string"

Assuming I have that right so far,
this is the only correct test for Object-ness that I know of at this time: my (1),(2),(3),(4) are all wrong, the compliance test suite's characterization is wrong,  and I'll go out on a limb and say that I suspect some or all of the other "many possible implementations" that @bergus has in mind are wrong too.  Of course I'm willing to be proven wrong :-)
It may be that there is an alternative implementation that uses instanceof in some way;
I don't know since I got lost trying to follow the discussion of instanceof in the ECMAScript spec.

I had Object(o) === o in mind, which is the other (next to 4) idiomatic test for object-ness in JavaScript. That they differ about special host objects doesn't really matter, because host objects which overwrite their typeof behaviour don't want to be recognised as objects.

@bergus thanks for the example.  Yes, it looks to me like Object(o)===o is a correct test, according to the MDN doc:
The Object constructor creates an object wrapper for the given value.
If the value is null or undefined, it will create and return an empty object,
otherwise, it will return an object of a Type that corresponds to the given value.
If the value is an object already, it will return the value.

More material here: http://stackoverflow.com/questions/8511281/check-if-a-value-is-an-object-in-javascript .  In particular, Oriol correctly points out that my proposed test using instanceof from above (2 comments ago), while correct, isn't as good as your Object(o)===o since mine will break if a future standard introduces a new primitive type.
Idiomatic (I guess that means "commonly used"?) or not, (4) is simply wrong according to the ECMAScript spec that you claim to be following.
Since you're insisting that promise/A+ spec's object means ECMAscript spec's notion of Object from part 6, and that's the only thing it could possibly mean, don't you think you should actually adhere to that definition?  Otherwise it keeps looking like you're making up rules and exceptions as you go along
and then expecting people to read your mind.

That they differ about special host objects doesn't really matter, because host objects which overwrite their typeof behaviour don't want to be recognised as objects.

That sentence really doesn't hold up very well at all.
Two immediate objections:
(I) Such objects don't want that?  Really? All of them?  That's a bold thing to say, isn't it?  I admit I'm not familiar with the context we're talking about, but it seems really odd to be making a claim about the wants of every object fitting this description that anyone might ever write, so I'm skeptical.
(II) If indeed you're right that some/most/all such objects don't want to be recognized as objects (which I read as "want to be treated as non-objects" per common English usage), then won't they be disappointed when your test Object(x)===x correctly identifies them as objects?  Especially ones that also happen to be thenables, which will find that different promise libraries actually treat them differently.
Don't you think it would be better to actually follow and enforce the definition of Object that you're citing, instead of coming up with reasons to do some other thing based on presumptions of what all pathological objects want and shaky logic?  The definition is actually looking fairly clear to me now, to my surprise.
I believe it's clear at this point that (4) simply fails to comply with the promises/A+ spec,
while the compliance suite lets it pass.
This inconsistency could be resolved in one of two ways:
(A) fix the compliance suite so that it correctly flunks (4), as required by the spec,
or,
(B) change the spec to allow (4), so that it will agree with the compliance suite.
I don't have a preference.
In any case, I'd also strongly recommend addressing the original issue, as follows:

Mention (perhaps even recommend) Object(x)===x.  There are evidently lots of ways to do it right and lots of ways to do it wrong; mentioning this simple right way would be significantly helpful in guiding implementers toward success.
Also mention that "object" is being used as in the ECMAscript spec section 6.  That's nowhere near as obvious as you've made it out to be, to many of the people of varying levels of javascript expertise who make up your audience.  Referring to the ECMAscript spec would go a long way towards clearing the fog, as it did when you linked to it in this thread.

These objects you are talking about are ignored because they're basically non-existent. They are absolutely non-standard, and while the ES spec does permit them it explicitly discourages implementations from using them.
This is also the reason why the compliance suite doesn't test them: there's no way to create such an object in node.js.
The only examples that come to my mind are document.all and some host objects from the IE7 era (like ActiveX), which were also known for not returning "function" despite being callable. Nobody gives a f*** about them.
The other reason why x != null && (typeof x == "object" || typeof x == "function") is commonly used over Object(x) === x is that it is significantly faster, not involving a global function call.

@bergus, thanks, good to know all these things.
Well, I guess flunking (4) isn't really an option then.  In that case it would be great if the spec could be changed to match the suite.   Not that I give a f*** about those objects, it's just that if there wasn't this apparent hole in the logic, it would have saved me from worrying or thinking much about it; likewise for others in my position in the future, and people out on the web who are trying to make sense of the spec.
In chrome: document.all.then = function(){}.  Now it's a thenable. :-)  Whatever.
Yeah, the lack of any efficient bulltetproof way to ask is-an-object is pretty bizarre.
And, isn't Object(x) more than just a function call-- it actually creates a new object in memory (in the case x wasn't an object), right?   That sounds like quite a big deal for something that should be a lightweight check; but maybe it's not as big a deal in javascript as it is in C++, I'm not sure.  On the other hand I suppose a javascript compiler/interpreter could optimize Object(x)===x into something that's even more efficient than x != null && (typeof x == "object" || typeof x == "function"), couldn't it?

Actually... it looks like document.all isn't an example of the last line of Table 35 for which typeof doesn't return "object".
From typeof doc on MDN:
All current browsers expose a non-standard host object document.all with type Undefined.
    typeof document.all === 'undefined';
Although the specification allows custom type tags for non-standard exotic objects,
it requires those type tags to be different from the predefined ones.
The case of document.all having type tag 'undefined' must be classified as an
exceptional violation of the rules.

So, as far as I know, neither nodejs nor chrome has any way of creating an object whose behavior is described by the last line of Table 35 and whose typeof doesn't return "object".  Basically non-existent, as you say.


Strange water age results across pumps operated by simple control.

WestMeadePark.inp.zip
The attached is a small section of a larger network where a pumping station operated by simple controls delivers water to a small pressure zone containing a tank. Running this for 168:00 duration, the age at the suction of the pump station (junction 113-027) is a little weird - the 50 hours from the upstream reservoir connected by a short pipe, but I can't explain the fluctuation observed. The water in the pipe from the reservoir is stagnant much of the time, punctuated by short duration pumping periods of 1-3 hours.
But it's the discharge water age from the pump station (PS32) that has me scratching my head. It starts from zero and increases one hour for every simulation hour, as though water were stagnant with nothing coming out of the pump station. Yet there are the periodic flows through the station as described above - driven by simple control statements.
Has anyone seen odd water age behavior before, perhaps in conjunction with a pump station controlled in a similar manner? I can investigate but wanted the benefit of your experience before doing that.

Hi Jim,
For the first issue, you have an initial quality value of 50 at the reservoir, which explains the jump to 50 hours at the first junction once "fresh" water reaches it.
As for the water age at PS32, fresh water from the reservoir did not reach it after one week. The pumps' flow is low but the main thing is that the suction and discharge pipes are huge 99". The main pipe coming out of the station is only 8" so try similar values.

Thanks Elad! Internally, I knew it had to be user error.


WIP: xrdesktop packages & gnome-shell xrdesktop

Motivation for this change
Let's have some XR in nixOS
Todo:

[x] gxr
[x] gulkan
[x] xrdesktop
[x] gnome-shell patches for xrdesktop + script to make them
[x] libinputsynth
[x] gnome-shell-extension xrdesktop
[ ] testing on HP reverb

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Not sure what XR is (¿extended reality?) but we definitely should not patch GNOME Shell with random patches.

@mkg20001 What you could do is make a variant of those packages with XR. Or maybe nixpkgs isn't the best place for those things, will the patches be sent upstream to gnome-shell proper ever? I think that is the only questionable thing, the xrdesktop packages are fine for nixpkgs.

I also have an overlay here for these packages:
https://github.com/danielfullmer/xrdesktop-overlay
My understanding is that the authors are working to upstream their gnome changes. The version for KDE does not require any invasive patching, and could (in principle) be included in nixpkgs. However, I have not been able to get KDE to work yet with their latest version of xrdesktop.
@mkg20001  I noticed your gxr doesn't include openvr as a dependency? I think for it to be useful, you'd need to include at least one of the two backends, openvr or openxr, as dependencies. The openxr support for gxr is new, and I haven't yet added openxr/monado to my overlay.

This would still be very nice to have.

On a related note: https://github.com/NixOS/nixpkgs/pull/107001
@mkg20001 How were you testing this? What OpenXR runtime were you using?


Add host to batch

Ports https://github.com/spulec/moto/pull/4658 to batch

Codecov Report

Merging #4801 (c09f823) into master (bcf2eeb) will decrease coverage by 0.00%.
The diff coverage is 81.81%.

@@            Coverage Diff             @@
##           master    #4801      +/-   ##
==========================================
- Coverage   95.09%   95.09%   -0.01%
==========================================
  Files         586      586
  Lines       62189    62200      +11
==========================================
+ Hits        59138    59147       +9
- Misses       3051     3053       +2

Flag
Coverage Δ

servertests
36.19% <9.09%> (-0.02%)
:arrow_down:

unittests
95.02% <81.81%> (-0.01%)
:arrow_down:

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

Impacted Files
Coverage Δ

moto/batch/models.py
89.32% <81.81%> (-0.12%)
:arrow_down:

Continue to review full report at Codecov.

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


English version

It would be helpful to have an English version. If not, what is the reason for the english repo name and description?

A english repo name  is required in github.

node-mianshi 2333333

mianshi - -

Will there be a fontend-interview in the future ? I Admire ElemeFE. ^_^

@mmoaay @Leopoldthecoder

This is an excellent program, I had learned a lot from it, and I hope the author can keep serializing

@sofish 感觉可以由 @mmoaay 的团队先翻译，如果对 JS 的一些内容有疑问，我可以校对。

哦可，可以按照 element 的规范来，上次杨老师已经给了很好的示例了

I would love an english version too.

@cinwell.li  docsify 来解决这个问题就很赞啊。本身这个库就很赞了。替广大 markdown 程序猿感谢你 👍

Hello all,
Asking this I'm unclear. Is an English version coming anytime soon?

@arjunmayilvaganan  We'd accomplish the Chinese version in a week, and after the adjustment, English version will get in plan (maybe 2~3 week after), and the process & date detail will come with it.

@Lellansin thanks for the clarification.

English version plan has been started. feel free to reopen this issue.


unify name and id attribute when referring to module identification

Codecov Report
Base: 81.80% // Head: 81.80% // No change to project coverage :thumbsup:

Coverage data is based on head (707eb6c) compared to base (208cf61).
 Consider uploading reports for the commit 86f6c46 to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #655   +/-   ##
=======================================
  Coverage   81.80%   81.80%
=======================================
  Files          27       27
  Lines         654      654
  Branches      119      119
=======================================
  Hits          535      535
  Partials      119      119

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Catch space before module in title

A number of people have done [<type>: <module>] where then we throw a generic looking error. We should instead catch this possible error condition and report on it to the user more exactly.

Done in c30e75d5c1c77190c05c0fed749210604456c5aa


[Feature] Non-blocking fastAPI server

Issues:
The server is currently blocking, which means that it only took another input after it has finished generated one api call, this is not expected from an api server.
Suggestion:
Maybe enable multi-processing since this is CPU bound.

Need an example of multiple works using uvicorn

This is possible but would require the user to load multiple copies of same model (could share cache though), will look into this.

This is possible but would require the user to load multiple copies of same model (could share cache though), will look into this.

I were able to make it do async with specifying multiple workers, will this reuse the same copies of the model under the hood ? I'm not good with low-level stuff

With memory mapping multiple llama.cpp instances are able to share the same weights. Should be possible for multiple parallel api requests too.Am 11.05.2023 um 05:27 schrieb Andrei @.***>:
This is possible but would require the user to load multiple copies of same model (could share cache though), will look into this.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

With memory mapping multiple llama.cpp instances are able to share the same weights. Should be possible for multiple parallel api requests too.Am 11.05.2023 um 05:27 schrieb Andrei @.>: This is possible but would require the user to load multiple copies of same model (could share cache though), will look into this. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.>

hi what do you mean, so is this process automatically? like if you specify the same weight (ggml bin file) between each process it will automatically recognize that it is the same?

I use a simple server like this
from llama_cpp.server.app import create_app, Settings

import tomllib

import tomllib

with open("config.toml", "rb") as f:
    settings = tomllib.load(f)

settings = Settings(**settings)

app = create_app(settings=settings)

with settings are just n_ctx and model name
and run using uvicorn with this settings
uvicorn main:app --host <IP_ADDRESS> --port 3000 --workers 2

I do not see significant increase in RAM usage and it can handle concurrently

I use a simple server like this
from llama_cpp.server.app import create_app, Settings

import tomllib

import tomllib

with open("config.toml", "rb") as f:
    settings = tomllib.load(f)

settings = Settings(**settings)

app = create_app(settings=settings)

with settings are just n_ctx and model name
and run using uvicorn with this settings
uvicorn main:app --host <IP_ADDRESS> --port 3000 --workers 2

I do not see significant increase in RAM usage and it can handle concurrently

@jmtatsch and @gjmulder are correct about the mmap behaviour, what doesn't work with this approach and will need some extra thought is the caching behaviour. While the weights are the same the state internal to the llama.cpp context object is not and neither is the cache shared between processes. Ideally we would have a shared prompt cache for multiple copies of the same model and (probably much more difficult) a way to match to the best available model to minimize token processing.

@abetlen GPT-4 suggested:

Using multiprocessing: The multiprocessing module has a Manager class that can be used to create a server process which holds Python objects and allows other processes to manipulate them using proxies. This can serve as a shared memory object store, but it's not as efficient as Memcached.
Using shelve: shelve is a simple yet powerful tool for storing Python objects persistently
Using sqlite3 with :memory: database

I use a simple server like this
from llama_cpp.server.app import create_app, Settings

import tomllib

import tomllib

with open("config.toml", "rb") as f:
    settings = tomllib.load(f)

settings = Settings(**settings)

app = create_app(settings=settings)

with settings are just n_ctx and model name
and run using uvicorn with this settings
uvicorn main:app --host <IP_ADDRESS> --port 3000 --workers 2

I do not see significant increase in RAM usage and it can handle concurrently

@jmtatsch and @gjmulder are correct about the mmap behaviour, what doesn't work with this approach and will need some extra thought is the caching behaviour. While the weights are the same the state internal to the llama.cpp context object is not and neither is the cache shared between processes. Ideally we would have a shared prompt cache for multiple copies of the same model and (probably much more difficult) a way to match to the best available model to minimize token processing.

Hi so what i understand here is that the weight itself will be loaded one, but the cache of the inference will be duplicated? So in a sense this temporary approach will still be somewhat usable, just not optimal?

@tikikun yup that's correct

@tikikun yup that's correct

So if we have proper cache method for multi-processes the server would be very usable and even production ready, very interesting.

I know this issue is a couple weeks old, but some way to handle parallel requests would help a lot.
For example, if your query returns a large number of tokens, but you want to stop generating, you have to wait for the previous generation to finish. A way to "cancel" inference would be fantastic, maybe even automatically if >1 request comes in and a special flag is set.

I've converted the route handlers to async for the server, this handles disconnects slightly better, the server still can't process multiple requests concurrently unless you set --workers > 1 however this will multiply your RAM / VRAM requirements as each worker spawns another process with it's own memory space.
@oceanplexian I've looked into this, unfortunately I don't think there's a way for uvicorn to cancel running requests like this.

however this will multiply your RAM / VRAM requirements as each worker spawns another process with it's own memory space.

mmap won't allow the sharing of at least CPU RAM?

@gjmulder you're probably right actually, so yeah that's not a bad solution, additionally #279 should allow multiple processes to easily share a cache via the filesystem

additionally #279 should allow multiple processes to easily share a cache via the filesystem

That would be sweet. Can we make the KV cache persistent on disk?
So we'd have:

mmap shared CPU RAM models
KV cache shared via disk

With a 7B model and sufficient VRAM (e.g. 11GB) you could run multiple instances on the GPU. You'd just have to tune n_gpu_layers so that they all don't run out of total VRAM.
With the 3B Open Llama model this is doable even with say 6GB of VRAM. :thinking:

@gjmulder that's the idea, diskcache can keep the LlamaState stored on disk and then the server loads the state when there's a prefix match.

Are you planning any updates in the near future? I am very interested in the ability to use this API as drop-in replacement. With multiple concurrent connections. With falcon LLM we can probably scale that to production

What makes falcon LLM special?

What makes falcon LLM special?

Apache 2.0

Intercepter token output. how to solve this problem current? who can give a sota idea.


Cash Register solution in guide fails for floating numbers error

the solution given in the guide here https://www.freecodecamp.org/forum/t/freecodecamp-challenge-guide-cash-register/16012
fails in a situation like
const cid = [["PENNY",1], ["NICKEL", 0], ["DIME", 0], ["QUARTER", 1], ["ONE", 1], ["FIVE", 5], ["TEN", 10], ["TWENTY", 20], ["ONE HUNDRED", 0]];
checkCashRegister(3, 3.01, cid);

the change due is calculated as 3.01-3, which results in a 0.009999999999999787
this number is too small for the various checks, and no penny is ever given
We need a solution that starts with the conversion to cents, and maybe an explanation, or a source to where one can read about what's going on with the numbers and why it is needed in the guide somewhere

Hi @leahleen I would like to solve this issue. can you assign it to me. thanks

@ankurprasad711 no, I can't assign things myself

@ankurprasad711 we don't generally assign issues, but you're more than welcome to work on it!  Take a look at the contributing guide if you'd like to see the reasoning.

why it is needed in the guide somewhere

There is no longer a Guide.

@RandellDawson there is the guide in the forum where there is a solution, and there are articles and news of disparate topics

There is no reason to do double conversion to cents and then back to dollars in this example. You can wrap every operation with something like this:
function currencify(amount) {
  return +(+amount).toFixed(2);
}

This apparently has to do with how Javascript's implementation of float.h will somehow read the exponent wrong and mix up its interpretation of the significand - in which case the problem which needs to be fixed lies deep in the roots of your Node.js.   If (and only if) you want more info I will forward a bit more about the barebones of it

I am closing this to triage, as the solution in question has been modified, and passes the test conditions.


Executors (kibana) shuts down due to unknown error

The kibana executors failed 6 times over the course of a weekend (and were restarted, yay mesos!). All other services are running (i.e. ES hasn't shut down over the weekend).
Investigate attached logs to find out why.
stderr.txt
stdout.txt

Executor is being shut, when it reaches cgroup memory limits. Basically, Kibana runs out of memory. This can be seen from dmesg -T
[2016-02-02 07:09:26]  Task in /system.slice/docker-50c016035226708bbb3e86c24f3e5e5a7f7a0b9448ca16b74b7e62781045e91a.scope killed as a result of limit of /system.slice/docker-50c016035226708bbb3e86c24f3e5e5a7f7a0b9448ca16b74b7e62781045e91a.scope
[2016-02-02 07:09:26]  memory: usage 1048576kB, limit 1048576kB, failcnt 78
[2016-02-02 07:09:26]  memory+swap: usage 1048576kB, limit<PHONE_NUMBER>740991kB, failcnt 0
[2016-02-02 07:09:26]  kmem: usage 0kB, limit<PHONE_NUMBER>740991kB, failcnt 0
[2016-02-02 07:09:26]  Memory cgroup stats for /system.slice/docker-50c016035226708bbb3e86c24f3e5e5a7f7a0b9448ca16b74b7e62781045e91a.scope: cache:0KB rss:1048576KB rss_huge:38912KB mapped_file:0KB swap:0KB inactive_anon:0KB active_anon:1048572KB inactive_file:0KB active_file:0KB unevictable:0KB
[2016-02-02 07:09:26]  [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
[2016-02-02 07:09:26]  [ 1946]   999  1946   491442   264248    1039        0             0 node
[2016-02-02 07:09:26]  Memory cgroup out of memory: Kill process 1975 (node) score 1011 or sacrifice child

Based on https://github.com/elastic/kibana/issues/5170#issuecomment-163042525 and https://github.com/elastic/kibana/pull/5451, code changes in the framework required to set NODE_OPTIONS environment variable for executors... and we need to move to version 4.4

currently being tested on Alpha Cluster

It's fixed in 0.3.1


Behavior with environment variables defined "outside of" cross-env

While trying to find a solution to write npm scripts command lines using npm variables (e.g. npm_package_name), I found that cross-env doesn't see to recognize them, as if only variables defined using cross-env would be recognized.
For instance, with a package.json file containing:
"name": "my-nice-app",
scripts: {
    "cross_env": "cross-env echo $npm_package_name"
}

This results in the following on Windows (with Windows cmd, CygWin bash or VSCode bash):
$ npm run cross_env
%npm_package_name%

where I would expect it to echo my-nice-app.
Is it a known and accepted limitation or a bug?

This is definitely a bug. Any chance you could create a repository that reproduces this issue? Thanks!

Actually a single package.json file with the following content would make it:
{
  "name": "my-nice-app",
  "version": "1.0.0",
  "scripts": {
    "echo_name": "cross-env echo $npm_package_name"
  },
  "devDependencies": {
    "cross-env": "^3.2.4"
  }
}

and then run npm run echo_name in Windows cmd, Cygwin or VSCode bash.
I would expect this to display my-nice-app instead of %npm_package_name%
Additional info:
$ node -v
v6.9.1
$ npm -v
4.2.0

Sorry, I was unable to reproduce. This works just fine:
~/Desktop
🍔  $ git clone https://github.com/kentcdodds/cross-env-npm-env-vars.git
Cloning into 'cross-env-npm-env-vars'...
remote: Counting objects: 88, done.
remote: Compressing objects: 100% (69/69), done.
remote: Total 88 (delta 9), reused 88 (delta 9), pack-reused 0
Unpacking objects: 100% (88/88), done.
~/Desktop
🍔  $ cd cross-env-npm-env-vars/
/Users/kdodds/Desktop/cross-env-npm-env-vars
~/Desktop/cross-env-npm-env-vars (master)
🍔  $ npm install
<EMAIL_ADDRESS>/Users/kdodds/Desktop/cross-env-npm-env-vars
└─┬<EMAIL_ADDRESS>  ├─┬<EMAIL_ADDRESS>  │ ├─┬<EMAIL_ADDRESS>  │ │ ├──<EMAIL_ADDRESS>  │ │ └──<EMAIL_ADDRESS>  │ ├─┬<EMAIL_ADDRESS>  │ │ └──<EMAIL_ADDRESS>  │ └─┬<EMAIL_ADDRESS>  │   └──<EMAIL_ADDRESS>  └──<EMAIL_ADDRESS>
~/Desktop/cross-env-npm-env-vars (master)
🍔  $ npm run echo_name

><EMAIL_ADDRESS>echo_name /Users/kdodds/Desktop/cross-env-npm-env-vars
> cross-env echo $npm_package_name

cross-env-npm-env-vars
~/Desktop/cross-env-npm-env-vars (master)
🍔  $

Try it yourself:
git clone https://github.com/kentcdodds/cross-env-npm-env-vars.git
cd cross-env-npm-env-vars/
npm install
npm run echo_name

Note: This is why I ask for a repository that reproduces the issue. Because more often than not you'll find out that it's not related to cross-env at all, but is something else entirely. Good luck figuring out what it is! :)

Quick close... Your example (no more than just a package.json file) is failing on my side

Your example (no more than just a package.json file) is failing on my side

Ok, thanks for letting me know. Unfortunately that doesn't really help us know how to solve the issue. Could you please dig a little deeper and get more information (or try to fix the issue)?

I have encountered this same issue just now. @kentcdodds, I can confirm that your reproduction is also failing for me. I am running Windows 10, NPM 3.10.8, and NodeJS 6.8.1. I can reproduce the problem from both Git Bash and the Windows CMD.exe.
$ git clone https://github.com/kentcdodds/cross-env-npm-env-vars
Cloning into 'cross-env-npm-env-vars'...
remote: Counting objects: 88, done.
remote: Compressing objects: 100% (69/69), done.
remote: Total 88 (delta 9), reused 88 (delta 9), pack-reused 0
Unpacking objects: 100% (88/88), done.
Checking connectivity... done.
$ cd cross-env-npm-env-vars/
$ npm i
<EMAIL_ADDRESS>C:\Users\wfaust\Documents\Development\cross-env-npm-env-vars
`--<EMAIL_ADDRESS>  +--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | +--<EMAIL_ADDRESS>  | | `--<EMAIL_ADDRESS>  | `--<EMAIL_ADDRESS>  |   `--<EMAIL_ADDRESS>  `--<EMAIL_ADDRESS>$ npm run echo_name

><EMAIL_ADDRESS>echo_name C:\Users\wfaust\Documents\Development\cross-env-npm-env-vars
> cross-env echo $npm_package_name

%npm_package_name%

I will investigate further and see if I can determine why this is happening.

Thanks for the added confirmation @wolfgang42. Reopening.

@cvillerm, you're also on Windows correct? This appears to be a windows-only issue.

Actually, it seems to be any environment variable, not just ones defined outside of cross-env. I see the same problem with this script:
"scripts": {
    "echo_name": "cross-env testvar=foo echo $testvar"
  }

which results in %testvar% instead of the expected foo.
This looks like it might be a bug in the cross-spawn package, perhaps? The variable syntax is being converted by commandConvert(), but I'm not sure at what point variable substitution is supposed to be happening.

Happens here. Unfortunately it's not super simple, but the basic idea is that cross-env simply removes all instances of setting environment variables and adds them to envVars which is then used in the spawn call. In the case of npm_package_name however, that variable should be pre-loaded into process.env when cross-spawn starts, so it should already be included here.
Could you verify that it is included at that point and if it's not try to figure out why it's not in process.env when cross-env starts out. Because npm run should be setting that.

Yes, @cvillerm is on Windows.

This results in the following on Windows (with Windows cmd, CygWin bash or VSCode bash)...

I have verified that process.env.npm_package_name is set, and that the correct value is in the env variable by index.js:11.

Actually...
> cross-env A=1 echo $A
%A%
> cross-env A=1 node -e "console.log(process.env.A)"
1
> echo echo %A% > echo.bat
> cross-env A=1 echo.bat
1

I'm not sure echo can be trusted here.

@hgwood You're looking at the wrong thing—the environment variable is set, but not substituted in the arguments. Instead of process.env you should be looking at process.argv. Similarly, in your echo.bat it's cmd.exe doing the argument substitution from the environment variables.

cross-env does not substitue variables for their value, it only converts the syntax from $a to %a%.

Is something else supposed to be performing this substitution, then? It
seems a bit silly to do the conversion if nothing uses the converted values.

--
The views expressed above are exclusively mine, if anyone's.

You are right. It does not make much sense. I have only been a contributor for a few days so I have looked at the history. cross-env was made to handle setting env vars, not reading them. Some support for reading them was introduced in https://github.com/kentcdodds/cross-env/pull/32, but it only works in very specific scenarios (I don't know which).
I have recently been working on improving this. See #86, #89, #90. I would assume #89 fixes the problem we are discussing, but I have just run a few test and it looks like it does not. The first solution discussed in #90 would though.

I've update the reproduction repo to use node -e instead of echo which is unreliable as noted :)
So, we all need to remember that cross-env was never intended to replace environment variable references in the command with the value. Neither is cross-var for that matter. Their job is to simply change the script to use the syntax compatible for the platform on which they run. Then spawn that script. From there, the OS takes care of things.
So now if you run this you should get the correct output:
git clone https://github.com/kentcdodds/cross-env-npm-env-vars.git
cd cross-env-npm-env-vars/
npm install
npm run echo_name

cross-env is working as designed and supporting the use cases you should use it for.

Thanks both for looking deeper into that. Obviously, this wasn't the result I was looking for and this confirms that this seems to be an acceptable limitation of this command for environment variables defined "outside of" cross-env in Windows, as this issue was about.
Although cross-var is much less used than cross-env, it worked fine with such npm package-based variable. I may have to look at that direction.
Thanks again

Hmmm... I'm pretty confident that even without cross-env you would see the same result. This is just how things work unless I'm missing something...

Ah, after looking more closely at the cross-var implementation it appears that it's actually replacing the string values with the actual values rather than spawning the command with the values set in process.env. I guess it's just a difference in perspective. Do you want to execute a script that would behave exactly the same as echo %npm_package_name% or do you want to execute a script that replaces the value first? Ultimately, you should get the exact same result in any real-world scenario.

The way I would like to use environment variables would be to use them as part of an npm script definition, not only within the executed script, for instance to create a docker image with a tag based on the name as defined in the package.json file, e.g.:
"build_docker": "docker build -t $npm_package_name ."

Yes, that should work with cross-env. Have you tried it?

It doesn't work (in Windows) as cross-env docker build -t $npm_package_name . as it doesn't with the simpler example I provided in this issue with cross-env echo $npm_package_name

At https://github.com/kentcdodds/cross-env/blob/master/src/command.js#L18, what about replacing:
 command = isWin ? `%${match[1]}%` : `$${match[1]}`

by
 command = process.env[match[1]];

This would work for environment variables set before cross-env is called. Being able to replace locally set variables would require using envVars instead

And by the way, using parent/child scripts can be a workaround to make it work without an update:
  "scripts": {
    "echo_name": "cross-env echo $npm_package_name",
    "echo_name_parent": "cross-env npm run echo_name"
  },

npm run echo_name_parent will then work as expected. The same is true for more complex commands.

Yeah, this is pretty odd. I definitely want to solve this issue. However I don't want to go with your proposed solution due to the unintended side-effects that could cause (there's no guarantee that replacing the variable with its value will even result in valid syntax). But let's figure out how to solve this issue.

Yes, I agree that this needs to be fixed in a cleaner way ... and without breaking current unit tests

By the way, reproducing this on Linux-based environments is also possible by using something like %npm_package_name%. This is also replaced by $npm_package_name, but not evaluated.

@edm00se has discovered that this is resolved when setting {shell: true} in the options, which we do in next. This means that as soon as this lands, this issue will be fixed!

Great ! Thanks for following this up.

@cvillerm could you checkout next and confirm it is fixed there? I have done a few test and it looks like it is not fixed, but I might be doing something wrong.

@hgwood This looks to be working from my cloned copy of the next branch. Is there a better test to run?

Right. It does work now. I probably forgot to build or something.

I had to do the same. 😄

Thank you for verifying! I'm so glad this will be fixed soon!

Sorry if I didn't answer before, but it takes me ages to run npm install on a clone of cross-env and trying to run it locally doesn't work for me (src/bin/cross-env.js ...). I am not sure what's wrong with it.

Sorry, it's not the most straightforward thing to do to be honest. But I've updated the reproduction repo and it should work. Just do this (again):
git clone https://github.com/kentcdodds/cross-env-npm-env-vars.git
cd cross-env-npm-env-vars/
npm install
npm run echo_name

And hopefully it will work!

I was referring to cloning the cross-env repository, checking out its "next" branch and running npm install to install its own dependencies to test it locally (without referring to it from another test repo).
I anyway also have a problem installing your cross-env-npm-env-vars example, as referring to cross-env as kentcdodds/cross-env#next as devDependency doesn't seem to work in my environment, while referring to the published version works fine. I am behind a proxy, but my environment is normally configured fine to work behind a proxy and I am used to it. Adding that I am developing in Windows is likely adding other constraints.
I am giving up but I am trusting that this will work when the next version is published.

Could you try this out with cross-env@beta in your project and let us know if it fixes things? I'm most uncertain about this issue, so I want to make sure it's resolved before officially releasing beta. Thanks!

@kentcdodds , I tested this beta version on Windows (git bash and WIndows cmd) with your test project (cross-env-npm-env-vars) and with one of my projects and this worked fine.
$ npm run echo_name

><EMAIL_ADDRESS>echo_name D:\Tmp\cross-env-npm-env-vars
> node node_modules/cross-env/dist/bin/cross-env.js echo $npm_package_name

cross-env-npm-env-vars

Thanks!

It seems your version 5.0.1 is still  published, with a number upper that beta 5.0.0-beta.0.
Is it possible to publish your fix on 5.0.1-beta.0 ? or to publish it without beta if it works correctly ?
Thanks

Hmmm... 5.0.1 should have the fix. That's the latest version

Problem is still present on my side
Le 12 juil. 2017 16:32, "Kent C. Dodds"<EMAIL_ADDRESS>a écrit :
Hmmm... 5.0.1 should have the fix. That's the latest version
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kentcdodds/cross-env/issues/91#issuecomment-314787774,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFCmMbWW9WOng0cW7G05LmznZNWfvCxLks5sNNjWgaJpZM4MibX2
.

Ok. Thanks for bringing it up. Could you dig a little further to see where the problem is and suggest a solution to fix it?

In fact it only works if you define use shell option, because command in exec by node spawn and not a shell.
I've test the command
> cross-env echo $npm_package_name $npm_package_version
%npm_package_name% %npm_package_version%

I see in the code you send it to cross-swpan, that just do a child_process.spawn. And here, if your directly test cross-spwan like this:
const { spawn } = require('cross-spawn');
var child = spawn('echo', ['%PATH%'], { stdio: 'inherit' });

it returns only %PATH% without translation
and same for
const { spawn } = require('child_process');
spawn('echo', ['%PATH%']).on('error', function( err ){ throw err }

The reason it works when we do on a linux
> cross-env echo $npm_package_name $npm_package_version
PACKAGE-NAME 1.0.0

or on window
> cross-env echo %npm_package_name% %npm_package_version%
PACKAGE-NAME 1.0.0

is because the OS replace the value directly becore accession to your function. You can see it by logging commandArgs var inside index.js and you will see the value are already transformed.
For me the only way to resolve it is commandConvert function to replace $xxx by its value if available instead of %xxx% in windows case.
In this case you may need also to pass the getEnvVars as parameter to see the newly added env vars, because they willl be available only new spawn.

Ok, so, to make sure I understand, you're saying that if you use cross-env-shell it works, but it doesn't work with cross-env?

Yes that's it
Le 13 juil. 2017 01:09, "Kent C. Dodds"<EMAIL_ADDRESS>a écrit :

Ok, so, to make sure I understand, you're saying that if you use
cross-env-shell it works, but it doesn't work with cross-env?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kentcdodds/cross-env/issues/91#issuecomment-314923457,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFCmMZf_3eH2UqAfiPRS3afo9UrpHo1aks5sNVI_gaJpZM4MibX2
.

@paztis Problem solved then?

Yeah, I'm pretty sure this is part of why cross-env-shell was created in the first place. Please use that. Thanks!

hey, sorry to crash the party, but there's still a problem with using cross-env-shell, namely that slashes seem to always be replaced with backslashes on windows.
E.g.: cross-env-shell "echo /" outputs \.
Is there a way to tell cross-env-shell not to replace slashes or to escape certain slashes?
Using<EMAIL_ADDRESS>on Windows 10 with node 8.4.0 and npm 5.3.0

There is not I'm afraid. I'm not sure how to solve the problem honestly. Suggestions and pull requests are welcome.

Note that cross-env-shell and actual substitution of variable only works with the $var syntax, not the %var% syntax, which only gets substituted on Windows.


Encourage people to upvote, rather than react

Upvotes surface a post higher, rather than the :+1: reaction, which is more of a social feature.

good morning

Upvotes surface a post higher, rather than the  reaction, which is more of a social feature.

SLTM

good morning

See you soon!

See Yahweh!

I AM DAY LASCANO - 2022 REPUBLIC OF THE PHILIPPINES PRESIDENT - IN THE BODY OF BONG BONG MARCOS

LOOK WHERE TO HIDE BUT I HAVE INFINITE ABUNDANT GIFTS TO YOU ALL, EVILS!


The Column Resize Selection Area Is Too Narrow On The Markdown Dashboard Widget

Within the edit mode of a dashboard, hovering over the far right edge of the Markdown widget only shows the “move” cursor, not the “resize” cursor. This is inconsistent with the other types of charts, as for the rest of them, the "resize" cursor appears when one hovers over the far right edge.
The screenshot below is what you see when you try to adjust the width of a Markdown widget (you see the "move" cursor and not the "resize" cursor).

How to reproduce the bug

Go to a dashboard which contains a Markdown widget, or add a Markdown widget to a new or existing dashboard.
Select the "Edit dashboard" button (pencil icon in the top right of the page).
Try to adjust the width of the markdown widget.
You will notice that it is not easy to get the "resize" cursor to appear.

Expected results
When you go to adjust the width of the Markdown widget, the "resize" cursor should appear and thus allow you to make the widget larger or smaller.
Actual results
When you try to find the area that gives you the "resize" cursor, it does not seem to exist, or it is so small that it takes a while to get your cursor lined up with it.
Screenshots
Please see the main summary for a screenshot
Environment
(please complete the following information):

browser type and version: Google Chrome (Version 100.0.4896.127)
superset version: Master
python version: Python 3.8.10
node.js version: v16.9.1
any feature flags active: N/A

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[X] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[X] I have reproduced the issue with at least the latest released version of superset.
[X] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Also, since discovering this bug, I have created a fix for it on my local fork. I will create a corresponding PR that fixes this bug (and link it to this issue).

https://github.com/apache/superset/pull/19839

Closing this issue as the associated PR which fixes the bug has been merged into master.


Milestone: 1.0

This issue exists to track features, fixes, and changes required for dbt to hit version 1.0. All of the issues enumerated here should be labeled with the 1.0.0 issue label. When all of the issues attached here have been completed, we can cut a 1.0.0 release of dbt.
Changes

[x] Reconcile the SourceConfig (https://github.com/fishtown-analytics/dbt/issues/2273)
[ ] Add blocks for all resources

[ ] ~Model blocks (https://github.com/fishtown-analytics/dbt/issues/184)~
[ ] ~Custom data test blocks (https://github.com/fishtown-analytics/dbt/issues/2274)~
[x] Schema test definition blocks (https://github.com/fishtown-analytics/dbt/issues/1173)
[ ] ~Analysis blocks (https://github.com/fishtown-analytics/dbt/issues/2275)~
[ ] ~Seed blocks (https://github.com/fishtown-analytics/dbt/issues/2276)~

[x] Rationalize test selection (#2203)
[ ] ~Make materializations return complete/compiled SQL output~
[x] Reconcile paths (#1607, #2659)
[x] Move plugins out of dbt core and into separate repos (#3361)
... + more issues to come ....

Suggested additions from when I've been writing docs:

[ ] Rationalize use of tags config / property (e.g. sometimes it's a config, sometimes it's in a schema.yml file which I'm calling a property henceforth).
[ ] Make data and schema tests configurable from dbt_project.yml. Lack of support for configs in the dbt_project.yml makes it impossible to "turn off" a test in a package (I think?)

Currently you can't configure a data test from dbt_project.yml, though it can be from a {{ config() }} block.
You can't do either for a schema test.

[ ] Make return type of custom schema tests and data tests consistent (number 0 versus 0 records)
[ ] Allow data tests to be documented (everything else can, why not these?)

Closing now that v1.0.0rc1 is out in the world. We got to most of this, not all. If an idea is good enough, I trust it will have its time in the sun post-v1.


Update adding-a-modern-web-and-mobile-frontend-to-a-legacy-claims-pro…

…cessing-application.md
Removed a typo - Quotes after the Components header.

@EdPrice-MSFT : Thanks for your contribution! The author(s) have been notified to review your proposed change.


libevent Not Found

when building doris with sh build.sh
===== Downloading thirdparty archives...
Downloading libevent-20180622-24236aed01798303745470e6c498bf606e88724a.zip from https://doris-incubating-repo.bj.bcebos.com/thirdparty/libevent-20180622-24236aed01798303745470e6c498bf606e88724a.zip to /home/darion.wang/work/apache-doris-0.13.0-incubating-src/thirdparty/src
--2021-03-13 20:22:36--  https://doris-incubating-repo.bj.bcebos.com/thirdparty/libevent-20180622-24236aed01798303745470e6c498bf606e88724a.zip
Resolving doris-incubating-repo.bj.bcebos.com (doris-incubating-repo.bj.bcebos.com)... <IP_ADDRESS>, <IP_ADDRESS>
Connecting to doris-incubating-repo.bj.bcebos.com (doris-incubating-repo.bj.bcebos.com)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-03-13 20:22:37 ERROR 404: Not Found.

which version?

apache-doris-0.13.0

Please change the libevent info in thirdpary/vars.sh to the info in trunk code, especially the download url and md5.
And we recommended to use docker dev image to compile the Doris source code, which already contains all thirdparties.

{"code":"NoSuchBucket","message":"The specified bucket does not exist.","requestId":"b7ad5805-5476-4b26-ba05-3035527a1dcd"}  It doesn't seem to exist. Can I submit a PR to fix this link?


DOCUMENTATION_ICON and DOCUMENTATION_TEXT not supported

A clear and concise description of what the bug is.
Expected results
When user sets the  DOCUMENTATION_ICON and DOCUMENTATION_TEXT it should be visible on top of the page
Actual results
DOCUMENTATION_URL is working fine, but not able to set DOCUMENTATION_ICON and DOCUMENTATION_TEXT, i guess this code needs to be fixed https://github.com/apache/superset/blob/6df822438121b02bdcb26108f41df0ad290703a4/superset-frontend/src/components/Menu/Menu.tsx#L247
Screenshots
If applicable, add screenshots to help explain your problem.
Checklist
Make sure to follow these steps before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[ ] I have reproduced the issue with at least the latest released version of superset.
[ ] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Add any other context about the problem here.

You're right... I didn't even realize this was there! This seems like a bit of a vestigial feature. If it hasn't worked for a long time, and nobody is barking about it, I'm wondering if we should remove it or fix it.
CC @yousoph @kasiazjc @jess-dillard for context, and CC @betodealmeida since they wrote the feature in the first place and may have feelings on the fix vs remove question.

Unless someone feels otherwise, I think we should remove this in 5.0. Closing this issue as stale, but adding it to that project board.

Working fine for me ! @rusackas
And I like the feature,

BUG_REPORT_ICON and DOCUMENTATION_ICON are expected to be class icon.
In my case I use icons imported from my design system.
Excerpt of superset_config_docker.py:
# Send user to a link where they can read more about Superset
DOCUMENTATION_URL = "https://numerique-gouv.github.io/chartsgouv/blog/"
DOCUMENTATION_TEXT = "Documentation ChartsGouv"
DOCUMENTATION_ICON = "fr-icon-question-answer-fill"  # Recommended size: 16x16

 # Send user to a link where they can report bugs
BUG_REPORT_URL = "https://github.com/numerique-gouv/chartsgouv/"
BUG_REPORT_TEXT = "Signaler un bug"
BUG_REPORT_ICON = "fr-icon-github-fill"  # Recommended size: 16x16

Thanks @qleroy! I'll take it off the chopping block, then : )


Audit SSL security

upgrade current cacert bundle
implement a rake task / test suite that goes through each gateway and verifies that each contained endpoint can be connected to with VERIFY_PEER mode. (requires a consistent setter/accessor for the gateway's URLs)
check all gateways that are using ssl_strict = false and ensure that we can change them to ssl_strict = true
logger.warn any use of ssl_strict = false in the connection lib

Any progress on this? Would love to see it happen.

I started on this a while ago, but won't be able to finish it.
https://github.com/titanous/active_merchant/tree/ssl_cleanup

Sweet - thanks for the pointer to the branch. Will be super handy if I get a chance to work on it.


bug fix on containers pointing to the same image id

The bug is where two containers are pointing to different tags ('latest', 'v1'), which are in turn pointing to the same image id.
After an update ('latest' now points to a new image id), BOTH containers would be updated, instead of only the one ('latest').
the fact that two containers are using the same image id right now does not mean they use the same image tag.

@circa10a been a while so i want a second pair of eyes - The logic makes sense, does the code reflect the logic?

@DirtyCajunRice I think it does, but I have no idea what the purpose of the list comprehension was
 shared_image = [uct for uct in updateable if uct[1].id == current_image.id]

@DirtyCajunRice I think it does, but I have no idea what the purpose of the list comprehension was

 shared_image = [uct for uct in updateable if uct[1].id == current_image.id]

@circa10a iirc that was to reduce image pulls by checking to see if any other image was the same id and only pulling once.
I would be remiss to not state that i do find it odd that someone would deploy 2 separate tags with different update cycles that just happened to start on the same tag and were both updatable, since the one that was not updatable would, in theory, be on a stringent tag and not flagged for update in the first place.
That said it is possible in theory and I cannot discount that.

@DirtyCajunRice I think it does, but I have no idea what the purpose of the list comprehension was
 shared_image = [uct for uct in updateable if uct[1].id == current_image.id]

@circa10a iirc that was to reduce image pulls by checking to see if any other image was the same id and only pulling once.
I would be remiss to not state that i do find it odd that someone would deploy 2 separate tags with different update cycles that just happened to start on the same tag and were both updatable, since the one that was not updatable would, in theory, be on a stringent tag and not flagged for update in the first place.
That said it is possible in theory and I cannot discount that.

I've been experiencing this bug since I'm deploying a "prod", "staging", and "dev" containers on the same host. This is a web app, and each container uses a different port. Each container uses a different image tag, but frequently these tags coincide and point at the same image id (for example, when "staging" moves into "prod"). From that point on ouroboros loses the tag distinction.

I can definitely see the use case and point made above.
LGTM


Match Publish Form UX to odysee.com

Make description field multiline.
Remove generate random URL button.
Indicate channel that content will be published as in URL.
Load known tags from Predefined.
Add release time setting.

PR Checklist

Please check all that apply to this PR using "x":

[x] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
[x] I have checked that this PR does not introduce a breaking change

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[x] Feature

Fixes
Issue Number: #93 (Partially)

Diff 2491b8c...8d24ffb:
Rename view variables to match naming convention

Diff 8d24ffb...2c45e66:
Remove setting claim release time from metadata. In claim editing PR release time will be loaded from metadata on fragment initialize.


Don’t depreciate GOPATH

What version of Go are you using (go version)?

$ go version
Version go1.16.6 Darwin/amd64

Does this issue reproduce with the latest release?
This issue is threatened for the next issue.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=“off”
GOPATH=“~/go”

What did you do?

What did you expect to see?
The Go package system was fundamental to the ease an elegance of the go programming language development experience. Please don’t destroy it. With it we can mirror local and remote packages. All the information is in the source files. No extra configuration files required. These are all well documented design decisions that made Go a wonderfully elegant programming experience.
Source versioning could be managed purely with subdirectory naming conventions.
The Module system as implemented now is too complex and broken and suggests the the 3 original designers were not involved with its design, or their views were not given enough weight. I would suggest you discuss this with those 3 designers.
At the moment local Modules cannot be easily imported without manually writing their path in the go.mod file. This contradicts the original design element of no configuration files. This is a poor decision and suggests it’s design was not thought out throughly.
By being able to uses GOPATH we are able to mirror local and remote packages. With out it we have manually edit every go.mod file to reflect the location of every local package we use.  If this statement is incorrect then it still reflects the complexity introduced to the Go programming environment with Modules, something the 3 designers went to a lot of trouble to eliminate.
Complexity is introduced when the problem is not well understood. Rob Pike stated this when he says “simplicity is hard”. I suggest the Module system could be redesigned to remove this unnecessary complexity.
In the mean time keep the original GOPATH design and don’t depreciate it. It’s elegant and simple, key design features that make Go the wonderful language that it is.
What did you see instead?

Duplicate of #37755


fixed spelling mistake in line 21 of CONTRIBUTING.md

just added the letter y...

Well someone did not proof-read their own text :o
Thank you for fixing it, it will be merged now.


Screen support?

Has anyone made this work with screen?
tmux may not be available on the target machine, screen is more often.

I had a first quick stab at doing this
screenrc() {
    local SCREENDIR=/tmp/russellscreenserver
    if ! [ -d $SCREENDIR ]; then
        rm -rf $SCREENDIR
        mkdir -p $SCREENDIR
    fi
    rm -rf $SCREENDIR/.sshrc.d
    cp -r $SSHHOME/.sshrc $SSHHOME/bashsshrc $SSHHOME/sshrc $SSHHOME/.sshrc.d $SCREENDIR
    SSHHOME=$SCREENDIR /usr/bin/screen -c $SCREENDIR/.sshrc.d/.screenrc -l -s $SCREENDIR/bashsshrc $@
}

not completely good yet, works only for all subsequently opened windows (C-a), not the first one

any news on this? do I have to start using tmux? XD

symlink your .screenrc into .sshrc.d/
add this to your .screenrc:

function screen () { /usr/bin/screen -c "$SSHHOME/.sshrc.d/.screenrc"; }


Error copying vendor and/or third party libraries.

OSX El Capitan (10.11.6)
Creating an app and trying to start a server:
$node -v
v5.12.0

$ng2 -V
0.2.3

$ng2 create TestApp
App created.

$cd TestApp

$ng2 init
Installed npm packages. (49 sec)

$ng2 serve
Clean successful.
Error copying vendor and/or third party libraries.
Unhandled rejection undefined

same for ng2 serve --dev, ng2 serve --prod, ng2 build...
Looks like issue is in angular-build.js file
module.exports = {
vendorNpmFiles: [
// these will be copied to dist/vendor
'@angular',
'rxjs', <-- after fresh installation this package is named as rx in node_modules
'systemjs',
'zone.js',
'reflect-metadata'
],
otherFiles: [
// add any files that needs to be copied to dist or any given path
// valid values
//   'src/CNAME'                        -> this copies file to dist folder
//   { src: 'src/CNAME', dest: 'dist'}  -> this copies file to the given location
'src/CNAME'
]
};
npm install<EMAIL_ADDRESS>--save did the job for me

Can you list the dependencies from package.json and npm version.

That's fresh package.json content after ng2 init:
{
"name": "TestApp",
"version": "0.0.0",
"license": "MIT",
"private": true,
"readme": "README.md",
"keywords": [
"angular",
"angular2-cli"
],
"angular2-cli": {},
"scripts": {
"lint": "tslint "src/**/*.ts"",
"test": "karma start karma.conf.js"
},
"dependencies": {
"@angular/common": "^2.0.0-rc.4",
"@angular/compiler": "^2.0.0-rc.4",
"@angular/core": "^2.0.0-rc.4",
"@angular/http": "^2.0.0-rc.4",
"@angular/platform-browser": "^2.0.0-rc.4",
"@angular/platform-browser-dynamic": "^2.0.0-rc.4",
"@angular/router": "^0.2.0",
"reflect-metadata": "0.1.3",
"systemjs": "^0.19.36",
"zone.js": "^0.6.12"
},
"devDependencies": {
"angular2-cli": "^0.2.3",
"codelyzer": "0.0.26",
"jasmine-core": "^2.4.1",
"jasmine-spec-reporter": "^2.5.0",
"karma": "^1.1.2",
"karma-chrome-launcher": "^1.0.1",
"karma-jasmine": "^1.0.2",
"tslint": "^3.14.0"
}
}

Issue observed with npm 3. Also there are many performance issues have been observed with npm 3.
will be working on these.
@expleosoftware try with npm 2.15 to start working with cli.

#9

fix is made in<EMAIL_ADDRESS>


An error occurred when Aves was restarted

Describe the bug
When I leave Aves in the background (not killed), and restart it by clicking the icon of Aves on the Desktop, it will get a bug just as the screenshot (it seems to re-scan the mediastore). This may last for about three seconds, and then become normal. This bug can be reproduced 100% successfully.
To Reproduce
Steps to reproduce the behavior:

Start Aves
Back to Desktop
Click the icon of Aves on the Desktop
See error

Screenshots

Additional context
The version of Aves is 1.10.8, and this bug appeared just after I updated to this version.
My phone is Huawei M40P, HarmonyOS <IP_ADDRESS>. I've turned off battery optimization to prevent the OS from killing this app, but it did not work.

Since v1.10.8, reopening Aves via the launcher icon is different from reopening it via the recent apps.
It's on purpose that opening it via the launcher icon shows the home page (even if the app hasn't been killed), but it's true that the store initialization is likely superfluous and should be skipped in this case.


Loading custom clip

from fashion_clip.fashion_clip import FashionCLIP
fclip = FashionCLIP('/content/clip.pth')

NameError                                 Traceback (most recent call last)
[<ipython-input-3-ca60ff7e5359>](https://localhost:8080/#) in <cell line: 3>()
      1 from fashion_clip.fashion_clip import FashionCLIP
      2
----> 3 fclip = FashionCLIP('/content/finetuned_clip.pt')

1 frames
[/usr/local/lib/python3.10/dist-packages/fashion_clip/fashion_clip.py](https://localhost:8080/#) in _load_model(self, name, device, auth_token)
    170                 raise RuntimeError(f"Model {name} not found or not valid; available models = {list(_MODELS.keys())}")
    171
--> 172             model, preprocessing = clip.load(model_path, device=device, download_root=_CACHE_DIR)
    173             hash = file_sha256(model_path)
    174

NameError: name 'clip' is not defined

Unable to load custom /openai clip. (https://github.com/openai/CLIP)
Is it possible to load open_clip models also (https://github.com/mlfoundations/open_clip)?

Hi!
FashionCLIP mainly uses the HuggingFace interface for models, so it would be better to use.
FashionCLIP('openai/clip-vit-base-patch32')

or a model saved in that form.
If you want to use CLIP-format you need to install the clip package form openai

# else it doesn't use HF, assume using OpenAI CLiP
        else:
            if os.path.isfile(name):
                model_path = name
            elif validators.url(name):
                # generic url or S3 path
                model_path = _download(_MODELS[name], _CACHE_DIR)
            else:
                raise RuntimeError(f"Model {name} not found or not valid; available models = {list(_MODELS.keys())}")

            model, preprocessing = clip.load(model_path, device=device, download_root=_CACHE_DIR)

Ok, in the codebase it there was a file path reference in  '_load_model'.

sorry, do you mind giving me additional details regarding your request?

Can we load a model from  a path to a local checkpoint(pytorch)?

Yes, but it needs to be in the correct format, best if it is an HF checkpoint


Add index to contributing.md

Lets add an index/Table of content to Contributing.md as the file is contains a quite a bit of content making it difficult to skim read.
Please make sure you do read CONTRIBUTING.MD as we have changed a few things and made it a lot simpler for people to contribute.

We can use https://github.com/thlorenz/doctoc

I would like to work on this.

@majidmazin Sure go ahead. I will list few steps you can follow and use https://github.com/thlorenz/doctoc to generate TOC easily

Fork this repo as mentioned here (First 3 steps) https://github.com/coderplex/coderplex/blob/develop/.github/CONTRIBUTING.md#running-locally
Install doctoc using NPMnpm install -g doctoc

Inside coderplex project run below command to generate TOC for Contributing.md filedoctoc ./.github/CONTRIBUTING.md

Finally commit these changes and submit your PR


Bump bootstrap from 4.6.1 to 5.3.3

Fixes #4602
Successor PR of #5117
@tachyons pls review when you get time, i have tested the site end-to-end, and made sure the UI is stable and congruent with that of production.

Summary by CodeRabbit

New Features

Enhanced styling and accessibility for various modal components.
Improved user interaction with updated JavaScript functionality for the simulator's listener module.

Bug Fixes

Resolved issues with modal close buttons and updated attributes for Bootstrap 5 compliance.

Documentation

Updated package.json to reflect dependency upgrades for Bootstrap and Popper.js.

Refactor

Standardized Bootstrap column classes across multiple views for better responsiveness.
Updated form styling by replacing form-group with mb-3 for consistent spacing.

Chores

Excluded certain files from ESLint linting process to streamline checks.
Specified minimum version requirement for the rexml gem in the Gemfile.

@tachyons
I have implemented all the changes suggested by the automated bots. Additionally, I have updated REXML to address the identified vulnerabilities. I ran the test suite locally without encountering any errors and performed end-to-end testing to ensure that all features are functioning as expected. If you have any further suggestions or require additional changes, please let me know. I am happy to make any necessary updates.

@abhisek vet CI is failing with Error: Head is not ahead of Base: diverged

@abhisek vet CI is failing with Error: Head is not ahead of Base: diverged

@tachyons Thanks for the tag. Tracking this as an issue: https://github.com/safedep/vet-action/issues/85
This is a problem with GitHub Action especially GitHub compare commits API that throws the error. Will get it resolved.

@tachyons The issue should be fixed. Please tag if you see this again.


[* Currency] Expanded recognition of currency value when using [currencyname]$ (e.g. USD$) (#2711)

Fix to issue #2711 in English.
Expanded CurrencyPrefixList by combining CurrencyNameToIsoCodeMap with symbol '$'.
Test cases added to CurrencyModel.

Was there any issue propagating to ES/PT/FR?

Was there any issue propagating to ES/PT/FR?

They use localized currency names in some cases and English names in others (e.g. in French, 'FJD' corresponds to 'Dollar de Fidji' in CurrencyPrefixList and to 'Fijian dollar' in CurrencyNameToIsoCodeMap), this raises an error because the system tries to generate a dictionary with multiple entries with the same key.
The lists of currencies should be reviewed and modified in a consistent way.

Was there any issue propagating to ES/PT/FR?

They use localized currency names in some cases and English names in others (e.g. in French, 'FJD' corresponds to 'Dollar de Fidji' in CurrencyPrefixList and to 'Fijian dollar' in CurrencyNameToIsoCodeMap), this raises an error because the system tries to generate a dictionary with multiple entries with the same key.
The lists of currencies should be reviewed and modified in a consistent way.

Can you list such issues? Yes, all currency lists should be consistent. Please open an issue with your findings. Thanks!
@nawanas, this is related to the canonical outputs we've discussed previosuly. Like some languages having the type names translated, which should no longer happen in vNext.

Can you list such issues? Yes, all currency lists should be consistent. Please open an issue with your findings. Thanks!

ok, will do.

Can you list such issues? Yes, all currency lists should be consistent. Please open an issue with your findings. Thanks!

ok, will do.

@tellarin, since the list of affected units was shorter than anticipated, I pushed directly a fix for FR, PT and ES.


Better Error Handler

Global Error Handler to handle Instant Reply with Error
Local Error Handler to handle Recoverable Error
Aim to provide better error-handler pattern and omitting the noisy try-catch
Sample code, without try-catch:
const RESET_PWD_REQUEST = async (req, res) => {
  const SamePwdRequestError = { code: 404, message: 'New password cannot be the same as old password' }
  const WrongEmailError = { code: 406, message: 'Something went wrong' }

  const { email, password, token } = req.body
  const user = await db.User.findOne({ email })
  ShouldThrow(!user, UserNotFoundError)
  ShouldThrow(!token, TokenNotFoundError)

  const validation = await user.tokenDecoding(token)
  const isResetLinkExpired = validation.error || token === user.latestResetToken
  ShouldThrow(isResetLinkExpired, ResetLinkExpiredError)

  const authenticateWithNewPwd = await user.authenticate(password)
  ShouldThrow(authenticateWithNewPwd, SamePwdRequestError)

  ShouldThrow(validation.email !== email, WrongEmailError)
  const hashedPwd = await user.encryptPassword(password)
  await db.User.update({ email }, { $set: { password: hashedPwd, latestResetToken: token } })

  const emailService = new EmailService()
  emailService.resetEmailComfirmation(user)
  return res.status(200).json({ message: 'Password successfuly changed' })
}

AuthController.post('/reset-password', globalErrorHandler(RESET_PWD_REQUEST))

Uhm, look OK, but we have a lot of ShouldThrow
compare to one try ... catch
not much improvement

I think a little bit more about this issue. We should postpone the implementation. There are a lot of high priority tasks out there.

no plan to implement it for now