Hover documentation getting cut off

When A/B'ing rls and rust-analyzer I noticed the following issue:
rls:
rust-analyzer:
As you can see, the inline doc ouptut of rust-analyzer is cut off right before the [ of [vec!]
Info:

rustc 1.53.0-nightly (42816d61e 2021-04-24)
rust-analyzer eb741e895 2021-05-03 stable
Sublime Text 4

For me it looks fine:

That's a link, maybe there's an issue with ST's rendering of Markdown?

Since links render fine in the popups, the only issue I can think of is links that are also inline code blocks like this. Will do some investigating and close if this is indeed invalid.

Related:
https://github.com/rust-analyzer/rust-analyzer/issues/6655

Update: This is indeed an issue with inline code links.
Courtesy of rwols over at the LSP channel from Sublimes Discord:

Also related #6332.

Looks like we just keep intra doc links in the output if we can't resolve them? We should probably strip them in that case instead

Looks like we just keep intra doc links in the output if we can't resolve them? We should probably strip them in that case instead

Yes, that would be the ideal solution.


performance of getChildrenByTagName() and other DOM methods

Initial results of etc/benchmarks.raku is slower than expected:
$ raku -I . etc/benchmark.raku
Benchmark:
Timing 10 iterations of 00-load.hybrid, 00-load.libxml, 00-load.xml, 01-elems.libxml, 01-elems.libxml-local, 01-elems.libxml-native, 01-elems.xml, 02-attribs.libxml, 02-attribs.libxml-native, 02-attribs.xml...
00-load.hybrid: 52.165 wallclock secs (51.819 usr 0.359 sys 52.178 cpu) @ 0.192/s (n=10)
               (warning: too few iterations for a reliable count)
00-load.libxml: 1.449 wallclock secs (0.537 usr 0.188 sys 0.724 cpu) @ 6.899/s (n=10)
               (warning: too few iterations for a reliable count)
00-load.xml: 213.002 wallclock secs (170.017 usr 0.752 sys 170.769 cpu) @ 0.047/s (n=10)
               (warning: too few iterations for a reliable count)
01-elems.libxml: 9.742 wallclock secs (7.482 usr 0.060 sys 7.542 cpu) @ 1.026/s (n=10)
               (warning: too few iterations for a reliable count)
01-elems.libxml-local: 7.124 wallclock secs (7.106 usr 0.004 sys 7.110 cpu) @ 1.404/s (n=10)
               (warning: too few iterations for a reliable count)
01-elems.libxml-native: 6.231 wallclock secs (6.218 usr 0.004 sys 6.222 cpu) @ 1.605/s (n=10)
               (warning: too few iterations for a reliable count)
01-elems.xml: 0.422 wallclock secs (0.143 usr 0.000 sys 0.143 cpu) @ 23.701/s (n=10)
               (warning: too few iterations for a reliable count)
02-attribs.libxml: 1.531 wallclock secs (1.397 usr 0.004 sys 1.401 cpu) @ 6.531/s (n=10)
               (warning: too few iterations for a reliable count)
02-attribs.libxml-native: 0.951 wallclock secs (0.954 usr 0.000 sys 0.954 cpu) @ 10.513/s (n=10)
               (warning: too few iterations for a reliable count)
02-attribs.xml: 0.010 wallclock secs (0.014 usr 0.000 sys 0.014 cpu) @ 997.407/s (n=10)
               (warning: too few iterations for a reliable count)

I would expect that LibXML might have some advantage over XML with when loading and XML might then win out with simple navigation.
But these are pretty big margins, in particular wrt to 01-elems.xml vs 01-elems.libxml.
Investigation/optimisation needed.

There's a slowdown at the native level as demonstrated by:
02-children.libxml-native: 0.154 wallclock secs (0.166 usr 0.002 sys 0.168 cpu) @ 6489.672/s (n=1000)
02-elems.libxml-native: 11.327 wallclock secs (11.287 usr 0.008 sys 11.295 cpu) @ 88.283/s (n=1000)

Both are broadly similar, but getElementsByTagName() is vastly  slower than children(). children() is a simple attribute, getElementsByTagName() is an evalued xpath expression; but why such a big difference?

Calling of box method is on the hot-path and showing as a performance bottleneck in profile results.
Some room for tuning, but the need to constantly create objects adds enough of an overhead that this API navigation is unlikely to ever fly by pure Raku implementations such as XML.
I'm experimentally attempting to convert wrapping classes to native representation, so that the box method can stantiate them via nativecast rather than new. Initial profiling shows this is likely to be much faster with lower allocations and memory usages.
Work underway on native-box branch.

Branch merged into master. Latest benchmark showing an average 4-5x improvement in DOM methods.


[PE-D][Tester D] Inability to specify area code for company's contacts

By restricting phone numbers to purely just numbers, it restricts the ability of users to add dial codes to international companies' contact numbers.
This can be a problem if the user needs to contact the company, but the company is based overseas, so a dial code is needed.

Labels: severity.Low type.FeatureFlaw
original: ZShunRen/ped#6

FUTURE ENHANCEMENT


Button names do not match the official ones.

Godot version
v3.6.beta2.official [68c507f59]
System information
w10 64
Issue description
This image is from the official documentation.

Where is the "Menu" button?
What is the "Menu" button supposed to be?

Steps to reproduce
...
Minimal reproduction project
...

The Menu button is the Start button. In practice, I rarely ever see anyone calling it a menu button on Xbox controllers.

There's only so many variations on names that we can include, and note that on the 360 the button was officially called "Start"

PS: Can you link to the page that you took a screenshot of (the one with a description of the Xbox controller buttons)?

https://support.xbox.com/en-US/help/hardware-network/controller/get-to-know-your-xbox-series-x-s-controller
Well, my case was that I don't have an XBOX controller but I wanted to refer to that button, so I had to find out the name of the button (menu) and then I searched in the godot button list and the button didn't appear there and I didn't know what button should select.


[tests-only] Bump core commit id for tests

Rebased - ready for review and merge.

Rebased - ready for review and merge.


reading files directly

in lld-nfs.py, why do you call a sub process rather than reading files directly? this is a very weird script, sort of a bash script half converted to python!

@speculatrix Thank you for your feedback.
I changed the specification to read the file directly.

Much nicer, thanks


Docs to Evidence

Description

Inlined Evidence app into monorepo
All pages work in dev
does not build yet due to anchor link issue (below)

Outstanding Features

[x] Sidebar ordering for top level pages (e.g. "/cli")
[x] Anchor links do not work (numeric not text based)
[x] h3 level not visible in ToC

Outstanding Todos

[ ] Fix Algolia search
[x] Pinned version of Evidence rather than workspace link?
[ ] Markdown tables format poorly

may need row stripes
code snippets and URLS are wrong font size

[x] replace docusaurus admonitions with <Alert> components
[ ] HTML tables unstyled
[ ] Style Request Invite buttons
[ ] Use Evidence Details component for FAQ
[x] Remove or replace footnotes in environments page
[ ] Put "All Components" in Grid
[ ] check SEO

Nits

Spacing between paragraphs feels "wrong" - a bit of a wall of text - needs more space above headers?
No syntax highlighting (as per Evidence)
3rd level not visible in sidebar
No ability to collapse sections in sidebar by default
Padding above map too small so overlaps code snippet fence above
Code in headers is formatted wrong

Hacks

replaced unescaped { with escaped versions for partials, raw text
replaced <script> tags in HTML code blocks with {script/}

Checklist

[x] I have added to the docs where applicable

Later

Replace all component images with live components

Gif

Screenshots

closing in favour of #1808


Add considerations/notes to an application

User Story
As an analyst
I want to read and write notes for an application,
So that all the analysts can take them into consideration when doing their assessment
Acceptance Criteria

[ ] By default on the application page there is a large text area input field and a save button
[ ] When there are 1+ notes, they are displayed in a list in order of creation date (earliest to latest), and there is an "add note" button
[ ] When the user clicks "add note" button, then a large text area and a save button will appear in place of it
[ ] Note shows the name of the person and the date/time.
[ ] note can be deleted by any admin :  Clicking delete shows modal that says 'Are you sure you want to delete this note?  This can't be undone'  Delete or cancel.
[ ] No history of notes - hard deletes.  Don't keep it in the database anywhere.
[ ] no edit button
[ ] Notes show at the top of the Application page
[ ]  If analyst can't delete- they don't get a delete button
[ ]  Character limit of notes - 1000 each
[ ] No limit on the number of notes that can be added

Ultra refinement

ACL - Access Control List
[ ] Does this introduce ACL
DB:
[ ] .
Frontend:
[ ] .
Integration/API:
[ ] .
Tests:
[ ] .
Documentation:
[ ] .

De-prioritizing this to the backlog as it is not necessary with all the notes in the assessment templates, and state change reasons.


Docker-Compose Environment variables must be strings or numbers, not booleans

Description
Very small fix to our docker-compose.  In recent versions of Docker, env variables cannot have boolean values.  This error occurs on main:
ERROR: The Compose file 'docker/docker-compose.yml' is invalid because:
services.dspace-angular.environment.DSPACE_UI_SSL contains false, which is an invalid type, it should be a string, number, or a null

This tiny PR fixes the issue by ensuring booleans are strings.

NOTE: This is such a very tiny fix (literally just adding quotes around a boolean value), that I plan to merge it as soon as the CI succeeds...that way the error no longer occurs on main.


Changing docs for trivial issues

There's this open issue right now on British vs American spelling:
https://github.com/python/cpython/issues/82221

In the past, there's been some merged PRs on similar smallish consistency/grammar issues:
https://github.com/python/cpython/pull/2787
https://github.com/python/cpython/pull/25985

However, there are also these other comments that seem to resist against trivial changes:
https://github.com/python/cpython/issues/58372#issuecomment-1093572060
https://github.com/python/cpython/issues/62480#issuecomment-1093619748

The sense that I'm getting is that trivial / minor grammatical / consistency issues are generally not considered if it's either unreported, too large such that it'll take more core dev reviewing time than it's worth in improvement, or touches on somewhat historical docs. Would this be an accurate summary on whether to consider committing small changes?

(Minor sidenote: Just FYI, to make it easier for others to review the cases you mentioned, can you make them actual inline Markdown links, or at least just inline text or in a bulletted list, which would get linked automatically, instead of code blocks? And to note, you can automatically create inline links to other GitHub issues with helpful popup summaries just by writing /#NNNN , e.g. python/cpython#82221 , python/cpython#2787 python/cpython#25985 , etc.)

Yep, I can swap them no problem, I just didn't want auto references in the linked PRs/issues since I felt that these aren't directly related to the issues/PRs, and I'm just grabbing them as an example for the question I had

I see; I thought it wouldn't cross reference if you provide a full link, but maybe you know better than I, heh.

I think small improvements are OK, but they do really need to be improvements. If it's unclear whether the change really improves things, I'd rather stick to the status quo.
My thoughts on your examples:

writeable vs writable: the conclusion was that both are valid spellings, so we should just stick with the one we already use
color vs colour on IDLE: I think we should follow Wikipedia's rule (https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#National_varieties_of_English), which is that the original author of a document gets to pick the variety of English used, and then we stick with that. So I would not have approved a wholesale change of "colour" to "color".
uppercase vs upper-case: didn't look too closely but seems fine to improve the spelling

I agree with @JelleZijlstra's approach re: the examples.
It would probably make sense to update the devguide's docs sections or use that to create a docs style guide. It would be helpful so that people would know the preferred style.

color vs colour on IDLE: I think we should follow Wikipedia's rule, which is that the original author of a document gets to pick the variety of English used, and then we stick with that. So I would not have approved a wholesale change of "colour" to "color".

This is the rule we generally follow on the PEPs repo as well, since we have both AmE and BrE natives, along with avoiding verbiage specific to one or the other that could potentially impede clear understanding by all.

It would probably make sense to update the devguide's docs sections or use that to create a docs style guide. It would be helpful so that people would know the preferred style.

So long as there's some consensus on what the style should be (or at least that should be one), I'd be happy to help with such effort, given I have some experience with various docs style guides, and writing our own detailed one for the Spyder documentation projects.

Hi @slateny, Thank you for your interest and effort in contributing to CPython and its docs. I appreciate your effort. Would you like triage privileges on this repo?

Hi @slateny, Thank you for your interest and effort in contributing to CPython and its docs. I appreciate your effort. Would you like triage privileges on this repo?

Thanks Carol, Irit's actually opened a request for me here already :)

I'm not sure whether or not becoming a CPython triager grants those same permissions on this repo? I think I'd have to be an admin to check...

I'm not sure whether or not becoming a CPython triager grants those same permissions on this repo? I think I'd have to be an admin to check...

I'm a CPython triager and I appear to have no special privileges on this repo, so, seems like it doesn't :)

@CAM-Gerlach added the CPython triagers to this repo too.

@AlexWaygood I just added all of the cpython triagers to this repo. Could you please see if you now have triage privileges? Thanks.

I do! How exciting :D

Would it be fair to say that these are generally true?

if there's two near identical spellings / grammar quirks (hyphenation, AmE/BrE), then the current majority in the article should be applied, otherwise if there's a rough split then the older spelling holds. However, there doesn't need to be consistency between different articles
changes that don't greatly affect readability (maybe wording changes like, 'a file that's not standard' vs 'a non-standard file') are unneeded unless to fix consistency as above

I think maybe some justification on why certain rules are in place would be nice as well, if a style guide is made, something like 'spelling consistency within an article is encouraged as it's easier to do a keyword search on a page'

changes that don't greatly affect readability (maybe wording changes like, 'a file that's not standard' vs 'a non-standard file') are unneeded unless to fix consistency as above

Maybe I'm being a little too nitpicky with your example, but it would really depend on the context and if something was already being changed on that line or nearby. To me, there's a potential distinction in implied meaning that could affect readability and interpretation, depending on the context.
More broadly, I wouldn't expect someone to make such a change unless there was some motivation, and each instance can be evaluated on its own merits with the benefit of context, rather than trying to make detailed, prescriptive rules to cover every possible case and exceptions thereof. Rather, any rule should focus more on the high-level bottom-line—does this change improve the overall quality (clarity, readability, correctness and comprehensiveness) of the documentation?

My two (three?) cents on this:

If something is wrong, it should be fixed.

This includes typos, should of instead of should have, e.g. instead of i.e. (and vice versa), and similar issues -- even if they are one-character fixes.
In general, the fix should also be backported to all applicable branches[^1].
The fix could also span multiple documents if a similar error has been spot elsewhere.

If something is inconsistent or ambiguous, it could be changed.

This includes things like AE vs BE, title-case vs sentence-case, rewording a single sentence, etc..
In general, the change could be backported[^1].
The change should be limited to a single document (or a single package).
If the change adds too much churn (e.g. rewrapping long paragraphs, adding double spaces at the end of each sentence), it can be rejected[^2].

If something is not clearly wrong or inconsistent, it should be left alone.

This include things like hyphenations or certain style changes (e.g. adding Oxford commas).

A few more things to keep in mind:

Users that create trivial PRs with the sole goal of becoming contributors and/or gaining badges, should be discouraged to do so by rejecting their PRs and/or by explaining them why.  This should also be documented so that we could point them to the docs.
Valid PRs (even if trivial), shouldn't be closed/rejected or not backported just because they waste developers' time -- some devs don't mind a bit of simple busywork here and there.

[^1]: There are two arguments in favor of this: people often read old docs online and it makes other backports easier.
[^2]: This kind of changes interfere with git blame, however they can be hidden.

Valid PRs (even if trivial), shouldn't be closed/rejected or not backported just because they waste developers' time

I think it was a comment that Ned made that the simple fixes for documentation are worth doing as they affect the millions who read the docs, rather than the few hundred people who regularly read Python's source code. (I agree wholeheartedly.)
A

I fully agree with @ezio-melotti 's comprehensive and well-articulated reasoning above, FWIW.

I think it was a comment that Ned made that the simple fixes for documentation are worth doing as they affect the millions who read the docs, rather than the few hundred people who regularly read Python's source code. (I agree wholeheartedly.)

Yes, indeed, though one critical distinction here (and one I haven't always been diligent about in the past) to keep in mind is changes that just affect the style/formatting of the source code, which is only seen by a few hundred people, versus those that meaningfully impact the final output—and further, for source-code only modifications, both changes and strategies/patterns of changes that increase vs. decrease the cost of present and future maintenance and improvements.

Regarding this:

If the change adds too much churn (e.g. rewrapping long paragraphs, adding double spaces at the end of each sentence), it can be rejected[2]
2. This kind of changes interfere with git blame, however they can be hidden

They still affect other ways people browse history, like git diff.  Further, if you do this, the reformatting-to-be-ignored should be in a change which only reformats, and does not also add other changes, or ignoring the revision is a bad thing to do.  I'd be cautious with these - one bulk reformat (like people do on the code parts by running a formatter on the whole codebase) can usually be tolerated, but otherwise it does get rather messy - so leaving a maintainer the ability to reject-because-of-churn-without-getting-unreasonable-flamed indeed seems a good thing to account for.

so leaving a maintainer the ability to reject-because-of-churn-without-getting-unreasonably-flamed indeed seems a good thing to account for

I might be misunderstanding you & Cam, but I'm not sure I fully see this argument. The documentation is fundamentally for the end user or programmer who reads the rendered HTML rather than the reST sources. Whilst making developers go through an extra step in git for tracking when changes were introduced isn't ideal, I think it is still worth it to fix the documentation in most cases.
So a legitimate reason to close trivial PRs occasionally perhaps, but I would hope it isn't used as a crutch for rejecting change.
A

Mostly agree with Ezio, except that I’d make a difference between wrong or ambiguous (which should get fixed, with backports) and inconsistent (which is less strong and should be judged case by case).

so leaving a maintainer the ability to reject-because-of-churn-without-getting-unreasonably-flamed indeed seems a good thing to account for

I might be misunderstanding you & Cam, but I'm not sure I fully see this argument. The documentation is fundamentally for the end user or programmer who reads the rendered HTML rather than the reST sources. Whilst making developers go through an extra step in git for tracking when changes were introduced isn't ideal, I think it is still worth it to fix the documentation in most cases.

I don't think there's a disagreement here: a change which reformats the layout of the doc source doesn't provide any visible benefit to the person reading the rendered output, and might make life harder for a future dev trying to sort out when changes were made.  Yes I know there have been other threads on whether or not to reflow the rst sources on changes, but just want to keep in mind that maintainer time to merge PRs is a valuable and limited resource.

Mostly agree with Ezio, except that I’d make a difference between wrong or ambiguous

To clarify, "ambiguous" was referring to the rules to be applied, not to the meaning of the sentence.  For example the meaning of "This tool has a command line interface." is clear, but whether "command line" should be hyphenated or not is ambiguous (I thought it should, but Wiktionary seems to allow both forms).

I might be misunderstanding you & Cam, but I'm not sure I fully see this argument. The documentation is fundamentally for the end user or programmer who reads the rendered HTML rather than the reST sources. Whilst making developers go through an extra step in git for tracking when changes were introduced isn't ideal, I think it is still worth it to fix the documentation in most cases.

@mwichmann said it perfectly, much better than I did—the contrast here is between changes that simply reformat the reST source (e.g. trailing white space, spaces between sentence, line breaks, etc) versus those that make a meaningful difference to the rendered HTML (e.g. better organization, clearer phrasing, avoiding ambiguity, etc). This is also a discussion we've had before among ourselves on the PEPs repo when it comes to issues of arbitrary conventions versus things that impair understanding (e.g. AmE vs BrE spellings, versus avoiding words specific to one of the dialects that could potentially confuse the other; and respecting the author's convention in existing code where there wasn't a ),
This leads right into a related item worth mentioning here, which this discussion helped motivate my ideas for: the Discourse thread on preferring a more structured format for sections of the stdlib docs that are essentially the API reference. In that case, making it easier for users to quickly find the key information they need would appear to have a clear benefit to readers, even if the individual changes are fairly straightforward and mechanical, and require touching a fair number of lines.

For example the meaning of "This tool has a command line interface." is clear, but whether "command line" should be hyphenated or not is ambiguous

Yeah, In this case, it would certainly be ideal if we could be at least locally consistent with one or the other, something so small is IMO not worth simply for consistency's sake, never mind preferring one or the other, when something like that makes little to no practical difference to the reader (if the notice at all).

Maybe, but at least for myself I'm not 100% sure how (or perhaps even whether) we should actually codify our consensus, since this is more of a high-level conceptual issue than the concrete guidance I'm used to dealing with in style guides.

IMO the style guide is the best place we have for this, and it's a part of the devguide where this kind of info fits even better.

Ah, looking more carefully, it seems devguide's "style guide" is devoted primarily to high-level conceptual issues like this, while the "Markup Guide" deals with the nitty gritty that I'm more used to seeing in style guides.


Can I mark $translate as "not ready until I say it is"?

I have a use case where the preferred language shouldn't be set by the browser setting, but rather by a setting on the server. To accomplish this, I have something like this in my application config:
var app = angular.module('myApp');
app.run(chooseLanguage);

chooseLanguage.$inject = ['$http', '$translate'];
function chooseLanguage($http, $translate) {
    $http.get('/api/localization/preferred-culture').success(function (language) {
        $translate.use(language);
    });
}

I've also defined a fallback language, using
app.run(configure);
configure.$inject = ['$translateProvider']; // and a bunch of other stuff
function configure($translateProvider) {
    $translateProvider.useLoader('translationLoader', {}); // My own translation loader
    $translateProvider.fallbackLanguage('en-GB');

    // ...and configure other stuff
}

What happens when I load the page is that all resources that are translated through the $translate service (which, unfortunately, are quite a few) before the HTTP request returns, are translated into the fallback language even if the key exists in the preferred dictionary (since I haven't told angular-translate that I want that dictionary yet).
Is there some way I can tell the library that "hey, wait a minute; we're not ready configuring you until this promise resolves". It's completely OK to cloak all translated content until then, but I'd rather not block the JS thread waiting for an asynchronous call...

Hello, @tlycken. As far as I know, there are no such settings. But you can try:

Generate a JS file on the server, which will set up a language during configuration phase instead of making an ajax request (I'd prefer this approach)
Move language selection logic to the client
Replace angular-translate's run method with your own (adds ability to start the module by yourself, but makes it harder to update the module)
Maybe it is possible to control this stuff by a custom loader somehow

Is there some way I can tell the library that

No. It is simple like that: asap the AngularJS is starting itself, all config()'s, all run()'s and so on will be invoked. Your suggestion would also result into an issue: what translation definition does you app have if your xhr would fail? No translations? Never? Maybe a (system) fallback is not a bad choice after fall.
Anyway: A global delay intercepted in a custom loader would be possible. At the moment we are not planning for such stuff.


Spawn the child only when the tracing is ready

When we have fast program to trace it can finish before
we setup the probes and we get no hits, like:
cat ex.c
int krava(int a)
{
return 0;
}
int main(int argc, char **argv)
{
return krava(1);
}
bpftrace -e 'uprobe:/home/jolsa/bpftrace/bugs/469/ex:krava { printf("%d\n", arg0); }' -c ./ex
Attaching 1 probe...
Using pipe to synchronize child with the parent and
executing it only when the probe are attached.
bpftrace -e 'uprobe:/home/jolsa/bpftrace/bugs/469/ex:krava { printf("%d\n", arg0); }' -c ./ex
Attaching 1 probe...
1

ok, will resubmit


Does it work with expo?

Hi there, does your code support react native projects built using Expo?

I do not currently have plans to support Expo. If you can do that, the Expo user and I will be very grateful to you.

This library works flawlessly on expo using a custom dev client. I just installed it a couple of minutes ago.
Just had to make sure to add some permissions using the app.config.js and call expo prebuild.


added kuttl tests

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@53ef2b9). Click here to learn what that means.
Patch has no changes to coverable lines.

: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       #1   +/-   ##
=======================================
  Coverage        ?   50.90%
=======================================
  Files           ?        3
  Lines           ?      444
  Branches        ?        0
=======================================
  Hits            ?      226
  Misses          ?      202
  Partials        ?       16

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.


Adding a shortcut reference to this in the render function

Basically this would be a convenience feature.  Instead of
render:function(h){
  var vm=this;
  return h('div',vm.text)
}

you would have
render:function(h,vm){
  return h('div',vm.text)
}

Which reduces the code (at least a little) the programmer has to write for each render function.
One other thing it would help with, is keeping track of the right this in anonymous functions. Again this would be a convenience feature, but this can be hard to deal with if you're not paying attention.
render:function(h,vm){
  return h('div',{on{keyup:function(e){if(e.keycode==13)vm.text='success'}}},vm.text)
}

I don't think this is necessary. h is there because const h = this.$createElement can be tedious to type, but this is fine, especially if you use arrow functions.


Possibility to run cargo from trunk with -Z build-std

I have app with threading, and to use it in wasm I need target-feature=+simd128,+atomics,+bulk-memory,+mutable-globals
But for this I need to rebuild std, and only for web target. So trunk can make this, if add some cargoflags config entry.

https://github.com/rust-lang/cargo/issues/8733
For some additional context

@github-actions[bot] Not stale, still an issue


Backpacks are partly invisible when a slime is wearing them

Description

Title! Because slimes are see through you should be able to see the back of the backpack but you can't. I'm not sure how to fix this exactly because I think the clothing layer is above the entity layer so it might be difficult...
Reproduction

Equip a backpack as a slime!
Screenshots

it's hidden on purpose because if it was visible the backpack would layer over your entire outfit

would need every backpack to have 2 layers for front and back side

would need every backpack to have 2 layers for front and back side

Yeah its probably not worth it it just annoyed me so I made the issue 😆


Better temporal representation

It is my belief that a temporal attention block which has a finer time resolution for most recent images and coarser time resolution for the oldest may help the model in achieving better time domain representation, longer video generation, and/or be more compute efficient.
The theory is that as more frames are generated, the older frames become more and more coarse, dropping more frames the further back in the sequence they are, so that we focus the context of the model on the most recent frames as those are most important for noticeable temporal coherency, but still maintain some temporal information no matter the length of generation in order to maintain some form of global context.
Whilst it may require reworking the architecture somewhat due to the notion of dropping older frames, I believe such a process could be highly valuable.
Something else that should help if you are not doing so already, is holding a cache of the sine and cosine embeddings that are used in RoPE for each sequence length encountered (a key may be used for accessing the correct cache), as the creation of these for each time the forward pass is called is a considerable slow down for long sequence lengths.
I have an implementation if you don't already have one and would like to use it.
On a last note, I was wondering if any experiments have been taken in transitioning feedforward and/or attention linear layers from fp16/32 to that from the 1.58bits paper (https://arxiv.org/abs/2402.17764) and as to what activation function you are currently utilising?
I would love to hear your thoughts on my ideas.
Many thanks,
-Elliott

My apologies, I could have (and have now) easily checked what activation function you are using an approximation of GELU using the hyperbolic tangent function.
May I suggest the usage of Mish(), as it has the same benefits of GELU (non monatomic, derivative at 0, close to linear above 0, totally continuous), except it is also more computationally efficient, and even closer to linear above 0 than even GELU.
You may have also heard of the Swish function, but I have found Mish to be more performant, and from the paper at least, better than Swish for the datasets they used to test the LLM they used with it. I have had very good experience with the function on audio data classification tasks too, so it certainly isn't limited to language tasks (which should be expected, but I thought it was worth pointing out).
So I believe it at the very least is worth investigating. I do understand however that you are currently waiting on more funding.

hey did you do this on windows system or linux??

hey did you do this on windows system or linux??

Both


Panel should hide when maximized and an editor is opened

Type: Bug
Activating an editor view causes the panel view to reset to default (i.e. editor/panel view) and fails to honor Opens Maximized (my prefered setting is preserve).
Steps:
Maximize Panel
Click on file in "Open Editors"
Panel resizes
Alternative steps:
Maximize Panel
Open file from command line "code file"
Panel resizes
My expected behavior is that the panel hides when the editor is activated. I have added a personal keybinding to toggle the maximize and I am always having to use it, even though the preserve option is available.
VS Code version: Code 1.85.1 (Universal) (0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2, 2023-12-13T09:48:06.308Z)
OS version: Darwin arm64 23.2.0
Modes:
Remote OS version: Linux x64 4.18.0-477.15.1.el8_8.x86_64

System Info

Item
Value

CPUs
Apple M2 Pro (12 x 24)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
1, 1, 2

Memory (System)
32.00GB (2.45GB free)

Process Argv
--crash-reporter-id 096bb959-2a2a-485e-813f-e68a50c850a6

Screen Reader
no

VM
0%

Item
Value

Remote
SSH: omega_proxy

OS
Linux x64 4.18.0-477.15.1.el8_8.x86_64

CPUs
Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz (40 x 3621)

Memory (System)
754.10GB (700.82GB free)

VM
0%

Extensions (36)

Extension
Author (truncated)
Version

better-comments
aar
3.0.2

Bookmarks
ale
13.4.2

project-manager
ale
12.7.0

troff
ban
1.0.24

vscode-gmsh
Ber
0.1.2

sidebar-project-links
cod
1.0.4

flask-snippets
cst
0.1.3

auto-dark-mode-windows
dan
1.0.11

vsc-material-theme
Equ
34.3.1

vsc-material-theme-icons
equ
3.3.1

output-colorizer
IBM
0.1.2

vscode-edge-devtools
ms-
2.1.3

jupyter-keymap
ms-
1.1.2

remote-ssh
ms-
0.107.1

remote-ssh-edit
ms-
0.86.0

remote-wsl
ms-
0.81.8

vscode-remote-extensionpack
ms-
0.25.0

remote-explorer
ms-
0.4.1

remote-server
ms-
1.5.0

colorful-comments
Par
1.0.0

material-icon-theme
PKi
4.33.0

remote-x11-ssh
spa
1.5.0

ayu
tea
1.0.5

vscode-djaneiro
the
1.4.2

pdf
tom
1.2.2

latex-support
tor
3.10.0

vscode-icons
vsc
12.6.0

jsoncrack-vscode
Ayk
2.0.2

html-preview-vscode
geo
0.2.5

custom-local-formatters
jki
0.0.6

conditional-format
KMR
1.3.0

json
Mee
0.1.2

vscode-html-format
moh
0.1.6

vscode-json-editor
nic
0.3.0

lua
sum
3.7.4

prettier-plus
svi
4.2.2

(7 theme extensions excluded)

A/B Experiments
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:30899288
vsclangdc:30486549
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30933248
pythongtdpath:30769146
i26e3531:30792625
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
h48ei257:30885898
pythontbext0:30879054
accentitlementsc:30887149
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
dsvsc019acf:30933242

The setting does not control what happens to the panel when the editor is opened and the panel is maximized, it controls what happens to the panel when it is opened. The setting is being honored but this seems like a feature request to control what happens to the panel when it is forced out of the maximized state.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Add 2-factor authentication to JS UI

Is your feature request related to a problem? Please describe.
The z-wave JS UI is incredibly useful for z-wave security devices, like locks and motion sensors. It would significantly improve the security of the server if 2FA could be implemented for user authentication into the UI, similar to that in HA or Homebridge.
Describe the solution you'd like*
Have a 2-factor authentication option for UI users.
Describe alternatives you've considered
Home assistant has this option, but for those of us running HA not as an OS a separate installation of z-wave JS is required. It would help a lot if z-wave JS had a 2fa as well.

Hi @MistyMoose. Thanks for your issue, this is interesting and I can implement it, will also change the base auth method to a better one using cookies. Follow the updates on this issue

Hi @MistyMoose. Thanks for your issue, this is interesting and I can implement it, will also change the base auth method to a better one using cookies. Follow the updates on this issue

I assume this would also make it possible to pass an authentication cookie from a third party auth provider? If so, that would be great! I use Authelia to handle SSO for most of my hosted apps. Would love to be able to use it with zwave-js-ui.

@geekifier I'm not sure I understand what you mean, I never did that

Sorry, don't mean to be derailing this issue. But I can give you an example of how I have it set up.
Long story short, you can have a reverse proxy with some sort of authentication provider that handles the authentication of the user. I use Traefik and Authelia for this, but you can use Ngingx, HAproxy, Caddy or whatever else.
The reverse proxy redirects unauthenticated user requests to your identity provider, which you can have authenticate against LDAP, OpenID, local DB etc.
Once authenticated, the reverse proxy sets a set of cookies, such as Remote-User, Remote-Email, Remote-Groups.
I use this for Grafana and other software, but I think Kanboard has a decent description on this.
The target app checks to see if the Remote-User cookie is set, and uses it to authorize the session depending on the software config. You can configure it to automatically create user accounts, or to just map Remote-User against the value of its internal auth DB.
The value here is rather than setting a bunch of "local" accounts and passwords across many apps, you log on with a single set of centrally managed credentials.
Sorry if this is OT, I saw you mentioning switching to cookie auth and was wondering if something like that header check would be possible as part of those changes.

@geekifier No worries, thanks for pointing this out, seems interesting and I never heard of such kind of auth method! I will dig into this and let you know in case I will be able to add that support. Thanks 🙏🏼


sbt 1.0.0-RC3, 0.13.16

https://github.com/thesamet/sbt-protoc/issues/32

Hi @thesamet. When you get a chance could you cut a release of sbt-protoc with this? We'd like to be able to upgrade the build in sbt/zinc, but unfortunately we're blocked on the issue this PR fixed.

Released 0.99.12-rc5

Thank you!


is CRF available?

Having looked into your code, I found that Conditional Random Field is also contained, but was not mentioned in your ISBI paper. And the function crfrnn3d is absent. Does CRF work? How is it implemented?

Having looked into your code, I found that Conditional Random Field is also contained, but was not mentioned in your ISBI paper. And the function crfrnn3d is absent. Does CRF work?

Yes, it worked, but in our experiments, we didn't get significant improvement from that. The crfrnn3d was implemented by following the https://github.com/sadeepj/crfasrnn_keras. Basically modify the files to accept the 3D inputs.


Remove registry command from top level commands

What type of PR is this:
/kind cleanup
What does this PR do / why we need it:
Which issue(s) this PR fixes:
Fixes #5402
PR acceptance criteria:

[ ] Unit test

[ ] Integration test

[ ] Documentation

How to test changes / Special notes to the reviewer:

/approve


[native] Switch C++ standard to C++23

Whenever size_t or ssize_t types are used and an integer literal is
involved, use the uz or z literal suffix.  This is to make the
intent explicit as well as to avoid hidden type conversions.  Despite
being more verbose, this makes the code more type-safe.

The MAUI integration tests appear to fail in other PRs

/azp run


Stream does not support typeHandlers option

Hello,
I'm currently using the version 3.2.0 with the stream mode and apparently it's not possible to pass the typeHandlers options.
I checked a bit the code and I think the issue is located here : https://github.com/kaue/jsonexport/blob/4a498777bab79dac88d32515b7ebd2086d8c6f41/lib/index.js#L56

A recommendation for more details as to what you are trying to accomplish and how you are trying to accomplish that.
I'm not able to connect enough dots with the information provided. I do assume you are trying to pass in individual typeHandlers but I can't related that to the coded provided.
If you do perhaps understand there is an issue and room for improvement, perhaps make a PR to better illustrate what's wrong and needing fixed

Yes, sorry for that.
I'm getting a stream of json data from a database and I want to transform a bit the CSV output.
I tried this to check how it was working :
esStream.pipe(
    jsonexport({
      typeHandlers: {
        Object: (value) => {
          return 'test';
        }
      },
      rename: schema.list.displayed.map(
        (property) => property[language] || property.en
      )
    })
  )
    .pipe(res);

But I got this error TypeError: dest.on is not a function.
I tried the version 2.5.2 and everything is working fine.

I get this error just for passing options to jsonexport when using stream. Doesn't matter which options you have.


add --cluster-name and --disable-cluster-name-verification

Fixes #7649.
Also adds --cluster-name and --disable-cluster-name-verification to cockroach start. They didn't appear to be documented previously.
@knz Not sure if I covered all of the relevant CLI commands. This change should cover:
Through the include:

cockroach init
cockroach quit
cockroach node

Separately:

cockroach start
cockroach debug ballast
cockroach debug zip
cockroach debug merge logs
cockroach debug encryption active key

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/4b2854887b0244d98bb70acaf187559fbf49214e/
Edited pages:

v20.2/cockroach-debug-ballast.md
v20.2/cockroach-debug-encryption-active-key.md
v20.2/cockroach-debug-merge-logs.md
v20.2/cockroach-debug-zip.md
v20.2/cockroach-start.md

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/ae9eb003957c4255a12cb232cdfd4b9b896f6285/
Edited pages:

v20.2/cockroach-debug-zip.md
v20.2/cockroach-init.md
v20.2/cockroach-node.md
v20.2/cockroach-quit.md
v20.2/cockroach-start.md

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/451a27cdcf74222253faa46cbaa5f3d87c6010f3/
Edited pages:

v20.2/cockroach-debug-zip.md
v20.2/cockroach-gen.md
v20.2/cockroach-init.md
v20.2/cockroach-node.md
v20.2/cockroach-quit.md
v20.2/cockroach-start.md


Any.Do Alternative

With Wunderlist being shutdown in the near future can you setup Any.Do as an alternative please.  I would like to label this as an idea but can't find out where to do that.

Thanks Brian! Dupe of #454, closing and adding reference to that issue.


fix: zsh integration to work with powerlevel10k / themes

Closes #174 by adding isterm special characters on the precmd hook instead of just on initial shell init.

It work only for the first command. From second command, the suggestion does not appear.

It work only for the first command. From second command, the suggestion does not appear.

Have you tried using version 0.0.1-rc.16?


tests: Fix signals sent to wrong parent process

The tests were sending signals to /bin/sh, which often didn't make it to the children processes.

Thanks for noticing the problem :)


[!] AES256_CBC_decrypt Failed (main.c:219)

Hi. I've got an error [!] AES256_CBC_decrypt Failed (main.c:219)
Generating PayloadConfig.pc:
`PayloadBuilder.exe demon.dll
[i] Reading "demon.dll" ... [+] DONE
>>> Read Payload Size : 65536
[i] The Generate Key Bytes: [ 6A 6F 73 60 1A 15 9A DB 1A 01 53 7D 12 CD 1C DA 0E DE 16 A5 C8 9A 63 81 2A D4 D2 14 0F 8B BE 5D ]
[i] The Generate Iv Bytes: [ 90 2B D2 23 52 93 D2 BD F6 93 53 F9 44 DE 0B 46 ]
[+] Payload Encrypted At : 0x000001441C053FB0
>>> The Encrypted Key Bytes: [ 6D 96 92 9F E9 EC 69 2A E9 00 B2 84 F1 34 E3 29 F5 25 ED 5C 37 69 A2 80 D9 2B 31 EB F6 7A 45 A4 ]
>>> The Encrypted Iv Bytes: [ FD 44 BB 4C 3B FC BB DA 9F FC 3C 96 31 B7 64 2F ]
[i] Writing "PayloadConfig.pc" ... [+] DONE
[+] File "PayloadConfig.pc" Is Successfully Written Under : C:\Users\User\Documents\AtomLdr\x64\Release`
Debug output of rundll32.exe .\AtomLdr.dll Atom:
`[#] AtomLdr.dll Is Called Via Command Line Tool, Running "ActualMain" From The Exported Function "Atom"
[+] Payload Is At 0x00007FFEEE1CA090 Of Size 47

Searching in "win32u.dll" ...
[+] Found "syscall; ret" gadget At - 0x00007FFEFA9E1042
Searching in "win32u.dll" ...
[+] Found "syscall; ret" gadget At - 0x00007FFEFA9E1042
Searching in "win32u.dll" ...
[+] Found "syscall; ret" gadget At - 0x00007FFEFA9E1042
Searching in "win32u.dll" ...
[+] Found "syscall; ret" gadget At - 0x00007FFEFA9E1042
Searching in "win32u.dll" ...
[+] Found "syscall; ret" gadget At - 0x00007FFEFA9E1042
Searching in "win32u.dll" ...
[+] Found "syscall; ret" gadget At - 0x00007FFEFA9E1042
Searching in "win32u.dll" ...
[+] Found "syscall; ret" gadget At - 0x00007FFEFA9E1042
Searching in "win32u.dll" ...
[+] Found "syscall; ret" gadget At - 0x00007FFEFA9E1042
Searching in "win32u.dll" ...
[+] Found "syscall; ret" gadget At - 0x00007FFEFA9E1042

            >>> Suspending Thread Of Id : 7304 ... [+] DONE
            >>> Suspending Thread Of Id : 7880 ... [+] DONE

[i] Replacing .txt of ntdll.dll ...
> pLocalTxtAddress : 0x00007FFEFCB11000
> pRemoteTxtAddress : 0x000002286A871000
[+] DONE
[i] Replacing .txt of KERNEL32.DLL ...
> pLocalTxtAddress : 0x00007FFEFC041000
> pRemoteTxtAddress : 0x0000022868191000
[+] DONE
[i] Replacing .txt of KERNELBASE.dll ...
> pLocalTxtAddress : 0x00007FFEFA431000
> pRemoteTxtAddress : 0x000002286A871000
[+] DONE
[i] Replacing .txt of msvcrt.dll ...
> pLocalTxtAddress : 0x00007FFEFBE61000
> pRemoteTxtAddress : 0x0000022868191000
[+] DONE
[i] Replacing .txt of combase.dll ...
> pLocalTxtAddress : 0x00007FFEFC271000
> pRemoteTxtAddress : 0x000002286A871000
[+] DONE
[i] Replacing .txt of ucrtbase.dll ...
> pLocalTxtAddress : 0x00007FFEFAA61000
> pRemoteTxtAddress : 0x0000022869A21000
[+] DONE
[i] Replacing .txt of RPCRT4.dll ...
> pLocalTxtAddress : 0x00007FFEFBBF1000
> pRemoteTxtAddress : 0x000002286A871000
[+] DONE
[i] Replacing .txt of shcore.dll ...
> pLocalTxtAddress : 0x00007FFEFBF71000
> pRemoteTxtAddress : 0x0000022868191000
[+] DONE
[i] Replacing .txt of imagehlp.dll ...
> pLocalTxtAddress : 0x00007FFEFC021000
> pRemoteTxtAddress : 0x0000022868061000
[+] DONE
[!] NtOpenSection Failed For "\KnownDlls\AtomLdr.dll" With Status : 0xC0000034 [THAT'S PROB OK]
[i] Replacing .txt of USER32.dll ...
> pLocalTxtAddress : 0x00007FFEFC891000
> pRemoteTxtAddress : 0x000002286A871000
[+] DONE
[i] Replacing .txt of GDI32.dll ...
> pLocalTxtAddress : 0x00007FFEFCAA1000
> pRemoteTxtAddress : 0x0000022868061000
[+] DONE
[i] Replacing .txt of gdi32full.dll ...
> pLocalTxtAddress : 0x00007FFEFA821000
> pRemoteTxtAddress : 0x000002286A871000
[+] DONE
[i] Replacing .txt of msvcp_win.dll ...
> pLocalTxtAddress : 0x00007FFEFA781000
> pRemoteTxtAddress : 0x0000022868191000
[+] DONE
[i] Replacing .txt of SHELL32.dll ...
> pLocalTxtAddress : 0x00007FFEFB2B1000
> pRemoteTxtAddress : 0x000002286A871000
[+] DONE
[i] Replacing .txt of IMM32.DLL ...
> pLocalTxtAddress : 0x00007FFEFBA01000
> pRemoteTxtAddress : 0x0000022868191000
[+] DONE
[!] NtOpenSection Failed For "\KnownDlls\uxtheme.dll" With Status : 0xC0000034 [THAT'S PROB OK]
[i] Replacing .txt of MSCTF.dll ...
> pLocalTxtAddress : 0x00007FFEFB191000
> pRemoteTxtAddress : 0x000002286A871000
[+] DONE
[i] Replacing .txt of OLEAUT32.dll ...
> pLocalTxtAddress : 0x00007FFEFC691000
> pRemoteTxtAddress : 0x0000022868191000
[+] DONE
[i] Replacing .txt of sechost.dll ...
> pLocalTxtAddress : 0x00007FFEFC1D1000
> pRemoteTxtAddress : 0x0000022868191000
[+] DONE
[i] Replacing .txt of advapi32.dll ...
> pLocalTxtAddress : 0x00007FFEFC5D1000
> pRemoteTxtAddress : 0x0000022868191000
[+] DONE
[i] Replacing .txt of shlwapi.dll ...
> pLocalTxtAddress : 0x00007FFEFBD21000
> pRemoteTxtAddress : 0x0000022868191000
[+] DONE
            >>> Resuming Thread Of Id : 7304 ... [+] DONE
            >>> Resuming Thread Of Id : 7880 ... [+] DONE

The Decrypted Key Bytes: [ 71 21 22 34 59 27 22 2D 26 59 34 21 28 36 2D 25 59 1B 26 59 2B 26 29 2D 1A 24 26 25 59 30 22 35 ]
The Decrypted Iv Bytes: [ 14 6C 00 14 13 6C 55 3C 2F 07 18 1D 2F 10 31 1D ]
[!] AES256_CBC_decrypt Failed (main.c:219)`

Could you please help?
Thanks

first of all, this only work with position-independent code, meaning the DLL file won't run already.
the second issue I noticed, is that the loader isn't detecting the payload;
[+] Payload Is At 0x00007FFEEE1CA090 Of Size 47

I suppose the DLL file is not 47 bytes only, so are you making sure to replace the generated PayloadConfig file with this one?
if not do as the usage suggest, and let me know the results

Oh shit... You are right. I forgot to replace PayloadConfig before compiling. Thank you


doc-reorg: Update intro section

Revised intro and related material (learn more, FAQ) for docs reorg.
To do: flesh out the different personas in the "what to read next" section. This should probably wait until we've added more of the sections.

@davisagli - Is there a reason we're keeping this in draft, or is it ready to merge?

@Br4nd0R Mostly that I wanted to give Liane and Melissa a way to see it rendered so they can review.


EON appears to have panic'd during the middle of drive

Sorry not sure where else to address this besides github issues.
Yesterday, was cruising like 75mph on highway.
 Which was weird because EON Was still green.
But actually I realized EON froze (and later rebooted itself)
https://my.comma.ai/cabana/?route=cb38ea752c72da81|2019-07-30--10-10-47&max=16&url=https%3A%2F%2Fchffrprivate.blob.core.windows.net%2Fchffrprivate3%2Fv2%2Fcb38ea752c72da81%2Ffd2cb58b6d81c4f0b71167bc3b6b5a66_2019-07-30--10-10-47
This is the link I found from Cabana that shares data from the drive. Time of interest would be at the end when the system disengaged itself.
Let me know if need more information or there's a better place to post this issue.
Been using openpilot for like 6 months without any hiccups until this happened.
Thanks.
Build: 6.1 dev
Car: 2017 Toyota Corolla
Pedal: Yes

I've ran into this issue once before, OpenPilot 0.6 was running at the time, Toyota Prius 2018

Any chance your EONs are overheating?

I'm sure everyone has had an issue at some point, but considering there've been several NEOS revisions in the last few months, please upgrade to the latest... and we'll go from there if your issues persist.

Any chance your EONs are overheating?

No, it's bloody cold here in victoria😂


G2UpdateProject needs to use pathlib

G2CreateProject.py has already been updated to use pathlib. G2UpdateProject.py needs to be updated in the same way.

Should be an issue in https://github.com/Senzing/g2updateproject rather than this repository.

Moved to https://github.com/Senzing/g2updateproject/issues/17


No Option to add package with TVOS project

using Xcode Version 15.0.1 (15A507), with a TVOS project.
I installed aws-sdk-ios-spm , when I click on [add package] I see a list of packages to choose BUT there is no select box on the left side for me to  checkmark .
looking at source for Package I see
let package = Package(
name: "AWSiOSSDKV2",
platforms: [
.iOS(.v9)
],
products: products,
targets: targets
)

Thanks for opening this @neal3000.
AWS SDK for iOS only supports iOS applications.
We recommend using Amplify Swift, which supports iOS, macOS, tvOS, and watchOS.


A request to much?

Description
Could it be runway is doing two requests?
One is without the columns and the other one is with the columns?
Screenshot: https://cln.sh/LhjQHZW2F0wfXPSZkxqS
Also the request fith the fields also fetches all the columns: https://cln.sh/rbbxdnL7JS9z8J8SXGBr
Steps to reproduce
See xhr requests in console.
Environment
Environment
Application Name
Laravel Version: 9.52.5
PHP Version: 8.1.17
Composer Version: 2.2.18
Environment: local
Debug Mode: ENABLED
URL: garagevanhulle.test
Maintenance Mode: OFF
Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED
Drivers
Broadcasting: log
Cache: statamic
Database: mysql
Logs: stack / single
Mail: smtp
Queue: sync
Session: file
Statamic
Addons: 5
Antlers: runtime
Stache Watcher: Enabled
Static Caching: Disabled
Version: 3.4.7 PRO
Statamic Addons
doublethreedigital/runway: 4.2.2
studio1902/statamic-peak-browser-appearance: 1.0
studio1902/statamic-peak-commands: 1.27
studio1902/statamic-peak-seo: 1.7
studio1902/statamic-peak-tools: 2.5

Yes, we shouldn't need to be doing more than one request here. I'll take a look whenever I have some time - I'd also accept a PR that fixes it.


Remove c++ clang argument from bindgen, because it was preventing export fn's from being generated in bindings.rs output file

fixes issue:
https://github.com/ccouzens/leptonica-plumbing/issues/10

Thank you for your contribution :)


Preserve the order of non-grouped nested parameters

This resolves issue #43. Nested parameters that are not grouped are now inserted to the parameter list according to definition order. Grouped parameters remain at the bottom of the parameter list.

@robbert-vdh seems like the Windows disk space issue is back 🙈

Haven't had any time yet, I'll take a look at this in a bit! I think if the order is preserved then it should probably do this for every parameter regardless of whether they're grouped or not so it's consistent. And that Windows disk space issue should be gone again with c92c2a189b01804df39bdb917a29578bf8145851. I messed up the conditional.

I think if the order is preserved then it should probably do this for every parameter regardless of whether they're grouped or not so it's consistent.

I cannot make that fit together with your statements from #43:

This is indeed expected and intended behavior as this is the same order the parameters will appear in when the DAW uses a tree view (which in DAWs usually seem to display parameters above other subgroups).

non-grouped nested parameters (unlike the ones from the example above) would not have to be moved to the bottom, right?

They would not, no. This is just how the macro is implemented now.

So, I guess I was misunderstanding you either here or there. 😅 Could you explain your approach again?

And that Windows disk space issue should be gone again with https://github.com/robbert-vdh/nih-plug/commit/c92c2a189b01804df39bdb917a29578bf8145851.

Very nice, I rebased the branch to the latest master 👍🏻

Sorry for taking this long to merge this! Thanks a lot for all the work, and especially also for adding tests! I fixed the order for grouped parameters, added some more tests to also cover grouped grouped parameters and to check whether the groups are handled correctly, and fixed the persistent fields for nested but not grouped parameters: 6036db45e5c7d3d0d9f8c83bf2bebf4e7da05a89...2cddd7089f06243ddf81d40948a2fe5bfe4c9b7e.

So, I guess I was misunderstanding you either here or there. sweat_smile Could you explain your approach again?

Listing non-nested fields first and nested fields seconds mimics one of the two common ways to show tries (directories before files, or directories after files). In the case of parameters having the flat list be in the order of the declarations also makes sense. But a halfway approach where some nested parameters (those without group attributes) are use the declaration order and other nested parameters (those with a group set) are listed last feels even more inconsistent to me. So my preference is to either follow the declaration order exactly or to do the individual-params-before-nested-params thing, but not something in between.


Possible CSS carry forward/powerless  issues

Reference: https://github.com/w3c/csswg-drafts/issues/9224
From the beginning, undefined values have been resolved at interpolation time. This occurred post-hue fix-up (longer, shorter, etc.). We had confirmed this behavior with the color.js that was meant to represent the CSS spec. We've seen other libraries implement this in the same manner, for instance, culori.

color.js
> new Color("hsl(90deg 50% 50%)").mix('hsl(none 50% 50%)', {space: 'hsl', hue: 'longer'});
Color {
  space: <ref *1> ColorSpace {
    id: 'hsl',
    name: 'HSL',
    base: RGBColorSpace {
      id: 'srgb',
      name: 'sRGB',
      base: [RGBColorSpace],
      aliases: undefined,
      fromBase: [Function: fromBase],
      toBase: [Function: toBase],
      coords: [Object],
      white: [Array],
      formats: [Object],
      referred: 'display',
      path: [Array]
    },
    aliases: undefined,
    fromBase: [Function: fromBase],
    toBase: [Function: toBase],
    coords: { h: [Object], s: [Object], l: [Object] },
    white: [ 0.9504559270516716, 1, 1.0890577507598784 ],
    formats: { hsl: [Object], hsla: [Object] },
    referred: undefined,
    path: [ [ColorSpace], [RGBColorSpace], [RGBColorSpace], [Circular *1] ]
  },
  coords: [ 90, 50, 50 ],
  alpha: 1
}

culori.js
> culori.interpolate(["hsl(90deg 50% 50%)", "hsl(none 50% 50%)"], 'hsl', {h: {fixup: culori.fixupHueLonger}})(0.5)
{ mode: 'hsl', h: 90, s: 0.5, l: 0.5 }

The above CSS issue seems to claim that such a case should resolve as  270deg for a 50% mix. This is because undefined values are resolved prior to hue fix-up, which is quite surprising.
It appears that CSS handling of carry forward / powerless is likely more complicated than originally thought, so much so that implementing it properly may disrupt interpolation flow as it currently stands if we attempt to implement them as the CSSWG is currently advocating for.
It sounds like during carrying forward, undefined values are resolved before powerless resolution, but then alpha must be retained as undefined for premultiplication but then resolved as normal for interpolation. This is more complicated and would require us to rethink our flow if we want to mimic them. This seems unnecessarily complicated and a deviation from the simplicity of interpolation prior to these CSS carryforward and powerless steps.
If this truly is the way they expect things, and we want to mimic their approach, it is likely we may not allow these options to be globally enabled. Instead, we may only allow these during simple linear interpolation mode as undefined handling in bspline and continuous cases are much more complicated that the overly simplistic CSS linear case.
Or maybe we will instead have to implement a CSS interpolation mode along with a refactoring of when and how hue interpolation is handled.

What the most recent CSS is doing really doesn't make sense the more I think about it.
If we are interpolating between a hue and an undefined hue, we would expect that no hue interpolation would take place. So if we mix 90deg and none, the resolution of any percentage of mixing should result in 90deg.  This is because when we interpolate, we have no choice assume the first hue as the second, and interpolating between the two would give you the exact same value. This is the same as thinking that since we have no second value to interpolate, we have no choice but to accept the first as the resolution of interpolation. As this is exactly what they implemented in their own library from the beginning, this makes sense.  So whether you are doing 'longer', 'shorter, etc. the result is the same, interpolation between 90degandnoneis90deg`.
But with all the new confusing additions with carrying forward and such, they are now resolving the hue before interpolation and such that now we are not evaluating 90deg and none, but 90deg and none. During carry forward, we decided to have the undefined hue accept the value of the defined hue, then we do hue fix up, is backwards from the previous logic. By time we actually interpolate, we are assuming that both colors are 90deg hues, and if interpolating with 'longer', we interpolate around the wheel giving a rainbow of colors. This fundamentally changes how we think about undefined hues. What was once intuitive is now not. There is this magic happening now that I think is still ill defined.
While before, the interpolation logic had no choice but to return the only defined hue during interpolation as there was nothing to interpolate against, CSS is now implying, "no, by time you interpolate, both hues are actually defined implicitly" (due to magic of now inheriting the opposing hue during carry forward), so we are interpolating between two real hues.

The good news is that we clearly state both of these implementations (carryforward/powerless) are experimental as I was certain we were going to run into something like this. We have no obligation to provide a stable implementation if we do not want to, and we can remove the experimental implementation if we so choose.
If we want to support whatever CSS is doing, we have to restructure how steps are handled in the interpolation plugin. As mentioned earlier, we would most likely push CSS handling into a css-linear plugin or something. This means hue fixup logic may be performed in each plugin.
As far as I can tell, the impact may only affect longer. In most other cases, the outcome would probably be identical to what we already do as the interpolation in almost every case between 90deg and 90deg is 90deg. Only with 'longer' do we go around the color wheel.
If I'm being honest, I don't really like how CSS does this. It causes interpolation between a hue that simply does not exist, but if that is what they want to do, and if we want to provide some compatibility for it, we'll have to adapt. If we don't want to provide a bridge, that is fine as well.

After thinking about this a little more, I think CSS is going in a confusing direction that I'm not willing to follow. If I'm interpolating between red and black, if I set the hue to "longer", it should not give me a rainbow of colors that slowly blends into black. Black has no hue, it just doesn't make sense.
This may be unpopular for anyone who wants to directly replicate CSS interpolation, but I think they've made a mistake.
If we are not mimicking CSS in this regard, I wonder if it makes sense to provide the carry forward and powerless options to mimic CSS as we are no longer mimicking them. We would have to decide if there is value in keeping what we have and rebrand it such that it isn't "targeting CSS compatibility".

In the end, I now have clarification via https://github.com/w3c/csswg-drafts/issues/9436. CSS treats achromatic interpolation as having an arc when using longer.
This will likely be where we deviate, but we will document why as I think this is a confusing direction.
I think we might be able to have the interpolation plugins absorb the logic of hue fix-up. If I can cleanly do this, then we may be able to provide a CSS interpolation that provides this logic, but this is not a requirement or a priority, it would be an extra if we do expose CSS compatible interpolation. And even then, we would document why we have relegated it to a separate implementation.

I've looked into this and we are able to push hue handling safely into the interpolation plugin. This allows us to provide a CSS-specific interpolation mode.
As you can see, here is the behavior of interpolation in HSL with red and an achromatic gray using longer with what we call normal interpolation and then CSS interpolation:

I can't quite understand how this would be useful behavior, but I do recognize that some people may want to have parity with CSS.
We can see that we now get what CSS specifies (a hue of 270) as mentioned in the OP:
>>> Color("hsl(90deg 50% 50%)").mix('hsl(none 50% 50%)', space='hsl', hue='longer', method='css-linear')
color(--hsl 270 0.5 0.5 / 1)


Avoid musl build

There are performance issues:
https://news.ycombinator.com/item?id=23080290
Not sure they still exist or not but seems better to avoid musl.

I only did that because it's on your instructions on how to build rustybgp: https://github.com/osrg/rustybgp/blob/master/BUILD.md. I don't know enough rust to be useful, I just copied.


Tweak linux install.

Adding cla: yes label, as the PR author is a googler at the time of this PR was created.


Save button doesn't save consistently and changes are lost :/

I press the Save button and a message of "Autosaving..." or "All Changes Saved" displays. Sometimes, my changes were indeed saved after I refresh.
And other times, my changes did not save at all after refreshing (and despite clicking Save and this message displaying). This error happens constantly, and I have lost my changes in different occasions.
As a result, I have to copy and paste my code into a word doc, then open a new playground to copy my code over and click save again (hoping it would work). This indeed works, but then I encounter the same problem again when clicking the Save button to keep saving my progress.

the cadence version is upgraded to 0.24.3. closing this issue now

This should be fixed in the latest build


Console Transport not output to terminal window

Please tell us about your environment:

winston version?

[ ] winston@2
[x] winston@3

node -v outputs: 10.15.1
Operating System? macOS
Language? TypeScript 3.3

What is the problem?
What do you expect to happen instead?
The Console transport is not output to terminal window. This occurs in VSCode, iTerm, Default terminal
Code that creates the logger:
createLogger({
            level: logLevel,
            defaultMeta: {
                name: name
            },
            levels: config.npm.levels,
            transports: [
                new transports.Console(),
                new transports.File({
                    filename: "combined.log",
                    level: "info"
                })
            ]
        })

Other information
The File Transport works fine
From what I can tell from debugging is that the transsports/Console.js Log method is never called.

Not sure about default terminal (that should work?!) but for vscode sounds like a duplicate of https://github.com/winstonjs/winston/issues/1544

Also suffering that on WSL 2 (Debian)

Also suffering that on WSL 2 (Debian)


simple log api

Description
simple api wrapper.
General Checklist

[x] Tests added for this feature/bug
if it was a bug, test must cover it.
[x] Conform by the style guides, by using formatter
[ ] Documentation updated
[x] (optional) Please add a label to your PR

Pull Request Test Coverage Report for Build 988592130

13 of 13 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 79.954%

Totals

Change from base Build 987124317:
0.04%

Covered Lines:
3362

Relevant Lines:
4035

💛  - Coveralls


Remove InstantRFC3339Module from messaging lib

And use the one we have in izettle-jackson

Sweet!
Waiting for TC


Make change in sign up,login ,reset

Describe the feature you'd like
Certain verification is implemented there. We need to make those changes in the website accordingly.
Additional context
List of probable changes:
Require user passwords to have at least 8 characters and at least one special character, one number and text characters
Add Recaptcha for second log-in attempts
Add Recaptcha for password resets (forgot password)
Username less than or equal to 51 characters.
Add Recaptcha for SignUp
Recaptcha needs to be validated both on frontend and backend
Would you like to work on the issue?
No, this is for GCI STUDENTS

I guess you have already made an issue regarding the Recaptcha thing #573

Agreed,but I have added some more enhancement in this
On Sun, Nov 10, 2019, 12:17 AM Aayush Gupta<EMAIL_ADDRESS>wrote:

I guess you have already made an issue regarding the Recaptcha thing #573
https://github.com/CircuitVerse/CircuitVerse/issues/573
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/CircuitVerse/CircuitVerse/issues/596?email_source=notifications&email_token=ALC3ZGJM7TFU3NT6JIQNDQTQS4ATDA5CNFSM4JLI7QN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUMQSY#issuecomment-552126539,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALC3ZGKGRMA3A2XJZ7BAHRTQS4ATDANCNFSM4JLI7QNQ
.

You can edit #573 and close this one

I just closed #573
On Thu, Nov 14, 2019, 2:21 PM Shreya Prasad<EMAIL_ADDRESS>wrote:

You can edit #573
https://github.com/CircuitVerse/CircuitVerse/issues/573 and close this
one
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/CircuitVerse/CircuitVerse/issues/596?email_source=notifications&email_token=ALC3ZGKHVR22VZ6CROANAC3QTUGPNA5CNFSM4JLI7QN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEBCCGI#issuecomment-553787673,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALC3ZGLHYYMHPOOKN6Q4Y7LQTUGPNANCNFSM4JLI7QNQ
.


PageTransitionsTheme needs to account for transition duration as well

Currently MaterialPageRoute is just hardcoded to have a transition duration of 300ms and CupertinoPageRoute, 400ms. A MaterialPageRoute using CupertinoPageTransitionsBuilder via PageTransitionsTheme uses the wrong time duration.
cc @HansMuller

I was able to reproduce this in 1.21.0-1.0.pre.

 flutter doctor -v
[✓] Flutter (Channel dev, 1.21.0-1.0.pre, on Mac OS X 10.15.5 19F101, locale en-AO)
    • Flutter version 1.21.0-1.0.pre at /Users/pedro/dev/SDKs/flutter_dev
    • Framework revision f25bd9c55c (2 days ago), 2020-07-14 20:26:01 -0400
    • Engine revision 99c2b3a245
    • Dart version 2.9.0 (build 2.9.0-21.0.dev 20bf2fcf56)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/pedro/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Users/pedro/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/193.6514223/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 11.5)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 11.5, Build version 11E608c
    • CocoaPods version 1.9.3

[✓] Chrome - develop for the web
    • CHROME_EXECUTABLE = /Applications/Google Chrome.app/Contents/MacOS/google-chrome-unsafe

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] Android Studio (version 4.0)
    • Android Studio at /Users/pedro/Library/Application Support/JetBrains/Toolbox/apps/AndroidStudio/ch-0/193.6514223/Android Studio.app/Contents
    • Flutter plugin version 47.1.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.47.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.12.1

[✓] Connected device (4 available)
    • AOSP on IA Emulator (mobile) • emulator-5554 • android-x86    • Android 9 (API 28) (emulator)
    • macOS (desktop)              • macos         • darwin-x64     • Mac OS X 10.15.5 19F101
    • Web Server (web)             • web-server    • web-javascript • Flutter Tools
    • Chrome (web)                 • chrome        • web-javascript • Google Chrome 83.0.4103.116

• No issues found!

The code hasn't changed since this issue was filed
https://github.com/flutter/flutter/blob/1840b7121a6a721484afca300265c7866e82dc77/packages/flutter/lib/src/material/page_transitions_theme.dart#L563-L570


Unreleased Features

Hi Team,
I recently created two pull requests which you allready merged and wanted to ask when they might be released?
https://github.com/kubermatic/machine-controller/pull/1476
https://github.com/kubermatic/machine-controller/pull/1471
Additionaly I wanted to ask if there is an easier way to contact you, as we are planning to use machine-controller and might have some features and ideas we would like to discuss with you.
Thanks & Best Regards
Luca

Hi Luca,
We are planning to cut machine-controller releases soon (before end of February). You can join the Kubermatic Community Slack (there's a link in our docs) if you want to reach out in a setting that's less formal than GitHub issues/discussions.

These features were released on 15th Feb as part of https://github.com/kubermatic/machine-controller/releases/tag/v1.56.0


tagged files are missing after each update

Description
Files are missing from the tags section on the home screen after each update

but if you go to the folder with the missing files you can see that they are still tagged correctly

Steps To Reproduce

tag some files of your choosing
update the files app
open it and see the tagged files gone

Additional Information:

most of the tagged files are in a OneDrive folder synced with a PC with the same tagged files and naming scheme
sometime after an restart missing tagged files reappear under "unknown tag"

Requirements

tagged files should not disappear after updating

Files Version
<IP_ADDRESS>
Windows Version
10.0.22631.4249
User ID
files-community
Log File
debug.log

A fix for this issue was added in v3.7.7. Unfortunately, the fix only helps for updates following v3.7.7. However, you can be assured that the issue has been resolved and should not occur again.


Create landing page

Include:

[ ] Hero section
[ ] Login/apply button

[ ] Show "applications have closed popup" when applications close
[ ] Switch from apply to login button when event begins?
[ ] Restrict user from accessing dashboard (aka login) before event

[ ] About section
[ ] FAQs
[ ] Sponsors
[ ] Footer

Note issue #16


Fixed navbar broken links on dashboard page

Signed-off-by: Yash Kamboj<EMAIL_ADDRESS>Description
Fixed navbar broken links on dashboard page
This PR fixes #
Notes for Reviewers
Signed commits

[ ] Yes, I signed my commits.

@leecalcote  review??


error: postgres:9.6-alpine - exited with code 127

If you use the online image: postgres:9.6-alpine
it works fine but if I use the dockerfile with the entry point it exits with code 127
...
': No such file or directoryute 'bash
cms_posgres_1 exited with code 127

Looks like a duplicate of #347.


can't play any song after install

I can't play a song anymore due to MusicKit error: "NO DRM".
This happens after installing the plugin and works again after uninstalling

Hi, what version of Cider are you using?

Hi, what version of Cider are you using?

latest, 1.5.8 - beta 40

I don't seem to be able to reproduce this issue. Are you sure the plugin is causing it? Could you attach the logs?

@UnbreakCode have you tried reinstalling widevinecdm? (Settings > Advanced > Experimental > Reinstall WidevineCDM)
also please keep in mind that beta version aren't intended for production usage as they are expected to break (as also stated by cider devs)

was musickit issue at this time


Allow disconnected peers to reconnect

We should expect peers will temporarily disconnect (e.g. for upgrades or network outages) from consensus.  In order to reconnect and catch up to consensus, we need to:

We save a signed epoch history to the DB in a hashlist (so if peers don't contribute sigs we ban them but can verify via the hashes)
Upon restart we request the next_epoch from all peers (including our own)

If a threshold 2f+1 respond with the same epoch, go with that (this is the case when we are all restarting)
If not, then consensus is on-going so peers may be on different epochs, wait for them all to respond with a timeout of 1min, then take the max(next_epoch) so long as it falls within bounds of the last signed history (within f+3 epochs) to prevent malicious peers from delaying us too long
If that doesn't work then manual intervention is required to determine what to do with the epoch that was only partially saved by consensus

Download all the epochs we've missed and process them as we can validate their signatures

Remaining tasks:

[x] Allow downloading consensus history
[x] Allows peers to resync up to consensus
[x] Handle consensus restarts
[ ] Defend consensus history API against malicious peers (see #449)
[ ] Handle rejoining with only 2f peers
[ ] Prevent send buffers from stopping consensus

Should we delete consensus history from the DB once everyone has it?

Should we delete consensus history from the DB once everyone has it?

It might be useful to have a signed record of the history that others can download, maybe there could be a configurable history size limit.
We could detect whether everyone has a past epoch once they contribute to consensus, so it would be probabilistically cleaned up.  Or we'd have to periodically make requests to all other peers.

After chatting with @elsirion we will not delete the history for now.  Long-term we should sign the entire state of the database in order to checkpoint the history for nodes that need to join.

@jkitman What's the status on this one?

I think we can close since we are tracking the remaining network issues separately.


Update Testing

Overview
The purpose of this pull request is to increase testing coverage in order to cover the recent features added to the classifier.
Implementation
Implementation included creating more unit tests to cover new methods added to classes as well as increasing testing data for testing the variety of cases present in the classifier.
Testing
Coverage was computed for the implementation of new tests in which we saw an increase in code coverage to around 93%.
Addition of New Tests:

Added unit tests for each new method introduced to classifier classes.
Expanded existing test suite to cover edge cases and diverse scenarios.
Ensured tests validate the interaction between new methods and other components.
Verified coverage metrics to confirm the effectiveness of added tests.

Problems Faced
N/A
Notes
After the new test implementation, we achieved around 93% code coverage, an almost 10% increase.

Here is the full coverage details:
Name                                         Stmts   Miss  Cover   Missing
--------------------------------------------------------------------------
src/dcm_classifier/dicom_config.py               4      0   100%
src/dcm_classifier/dicom_series.py              75      1    99%   134
src/dcm_classifier/dicom_validator.py           27      0   100%
src/dcm_classifier/dicom_volume.py             143      6    96%   182, 355, 451-453, 513
src/dcm_classifier/image_type_inference.py     142     16    89%   115, 177, 204, 226, 254, 277-280, 305, 411, 416, 422-428
src/dcm_classifier/study_processing.py          72      4    94%   312, 370-371, 373
src/dcm_classifier/utility_functions.py        372     34    91%   171, 181-187, 195-203, 208-213, 264, 275, 283-287, 295, 316, 387-389, 416-419, 699-700
--------------------------------------------------------------------------
TOTAL                                          835     61    93%


Change the config test to remove NamedTemporaryFile

https://github.com/huge-success/sanic/pull/1342

Codecov Report

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

@@            Coverage Diff            @@
##             master    #1358   +/-   ##
=========================================
  Coverage          ?   81.49%
=========================================
  Files             ?       17
  Lines             ?     1681
  Branches          ?      320
=========================================
  Hits              ?     1370
  Misses            ?      244
  Partials          ?       67

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 6778f4d...9a26030. Read the comment docs.


Fix fast path

WIP

@JohnNiang Thanks a lot for your testing.
This PR was wrong solution.
fyi, currently, @mobidick1969 is on the issue.


Dark red is really bright?

Is it meant to be more like the maroon from http://clrs.cc/ ? (currently is only a small bit darker than normal red)

I'll look into it. I think I didn't want it too dark. 'darkest red' is probably more chill

Is there a darkest-red somewhere?
@mrms Could you weight in on this, please: https://github.com/tachyons-css/react-native-style-tachyons/issues/11

Tachyons v5 will become a monorepo so this issue is being closed, if the issue is still relevant please open an issue with the main repo https://github.com/tachyons-css/tachyons/issues/new & link to this one


How to use multiple-GPU in training?

I saw the solve in close issue
python -m torch.distributed.launch --nproc_per_node 2 -m vall_e.train yaml=config/your_data/ar.yml
use this command can use double gpus
but the speed didn't fast than the one gpu

I know this was completed but I found that while the speed seems the same or a little slower, it converges a lot faster.
Here's what I'm testing on:
dev-clean of LibriTTS
kaggle 2x T4 GPUs

@coddiw0mple
thanks for your reply. Can i ask for your setting and the result?
I use the Libritts-360 hr and setting the param quarter for training. But the result is not good enough


BUG: the text from dialog box is not copying to the mail

Description:

In Contact Us section, when we try to send a mail then the entered text from dialog box is not copying into the text.

Demo of problem :
https://user-images.githubusercontent.com/76570320/135729278-56e4a340-880e-428c-b270-9857642deb6a.mp4
PR Instruction:

Issue will be assigned on a first come first serve basis.
If you are thinking to make a pr then at first be sure to get assigned.
before pushing your PR please make sure to fetch upstream.
your pr should be pushed on the develop branch only.
try to complete your assigned task within 3 to 5 days and if you need more time then please let me know. As the program has limited time only so please try to complete as fast as you can.

Hi! Could I work on this issue? 😊

Sure go for it.

Is this still open?


defaultworld: store the last world you were connected to

store the last world you were connected to and apply on startup.

This should probably be part of default world plugin, it is pretty unrelated to world hopper.

ping

This seems fine. I would probably name it Use Last World instead of Use Last Connected World since the phrasing there would probably confuse most people.


Sitemap

https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview
You might not need a sitemap if:
Your site is "small". By small, we mean about 500 pages or fewer on your site. (Only pages that you think need to be in search results count toward this total.)
Your site is comprehensively linked internally. This means that Google can find all the important pages on your site by following links starting from the home page.
You don't have many media files (video, image) or news pages that you want to show in search results. Sitemaps can help Google find and understand video and image files, or news articles, on your site. If you don't need these results to appear in Search you might not need a sitemap.


Add test suite for all routes

This fixes #2

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

Comparison is base (8a664c7) 46.80% compared to head (e4062c9) 75.88%.

Additional details and impacted files
@@             Coverage Diff             @@
##             main       #6       +/-   ##
===========================================
+ Coverage   46.80%   75.88%   +29.07%
===========================================
  Files           3        3
  Lines         141      141
===========================================
+ Hits           66      107       +41
+ Misses         75       34       -41

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


Add security samples - Tokens

Update the 10.2.7 ArcGIS Token security samples for Quartz (known user and challenge).

[x] WPF (CS)
[x] WPF (VB)
[x] UWP (CS)
[x] UWP (VB)

Incorporated comments from @macca400 and merged. Closing


chore: remove unnecessary deferred func on decoder

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

Project coverage is 100.00%. Comparing base (752d0ac) to head (9604b7b).

Additional details and impacted files
@@            Coverage Diff            @@
##            master      #296   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           42        42
  Lines         3675      3672    -3
=========================================
- Hits          3675      3672    -3

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


Accept MySQL's 'utf8mb4' as a kind of UTF-8 for CSV export

MySQL's default UTF-8 encoding is limited to 3-byte characters and
the encoding it uses and reports for full 4-byte Unicode is called
'utf8mb4' but if the database reports this encoding, the CSV export
module would try to convert string encodings utf8mb4 -> utf8,
causing an error.
Obviously the former is not a valid encoding name in Ruby, but is
actually going to be UTF-8, so this change assumes it's already
UTF-8.

Thanks!


feat: add bottleneck function

[!TIP]
The owner of this PR can publish a preview release by commenting /publish in this PR. Afterwards, anyone can try it out by running pnpm add radashi@pr<PR_NUMBER>.

Summary

Limit how many times a function can be called per time interval (in milliseconds). Optionally set a concurrency limit.
Most useful for rate limiting.
Related issue, if any:

https://github.com/lodash/lodash/issues/2102 (cc @not-an-aardvark from there)
For any code change,

[ ] Related documentation has been updated, if needed
[x] Related tests have been added or updated, if needed
[ ] Related benchmarks have been added or updated, if needed

Does this PR introduce a breaking change?

No

Bundle impact

Calculating...

What do you think about 'ratelimit' name to make it more explicit?

What do you think about 'ratelimit' name to make it more explicit?

Not against the idea. The name bottleneck is a nod to bottleneck on NPM.
Claude Sonnet 3.5 seemed to like both names 😄

I think rateLimit feels “higher level”, which could invite scope creep for more rate-limiting features. With enough tweaking, a rateLimit function could conceivably reimplement throttle and debounce. Maybe such potential is a good thing? Don't know.
The name "bottleneck" implies that every call will eventually execute, like emptying water from a bottle in real life. That seems to imply it wouldn't be possible to bloat bottleneck with additional options related to throttling or debouncing (that is, without grossly conflating the term "bottleneck").
But perhaps discoverability is most important here. 🤔

Delaying this until @hugo082 submits his withSemaphore PR, so we can re-evaluate the requirements of this function and possibly use withSemaphore to implement it.


[Task]: Oracle plugin: introduce feature flag

Is there an existing issue for this?

[X] I have searched the existing issues

Summary

add feature flag for Oracle plugin.

Why should this be worked on?
.
How to test
(1) Check that the plugin is visible only when logged in via the feature flag email

Plugin is visible only when we login through<EMAIL_ADDRESS>It is not visible when logged in through other users.


chore: Release wasm strip

Summary
wasm blobs are generally slow to load and it is preferably if these are lightweight
Stripping is usually not done by default nor by wasm-opt so
Test plan (required)
$ yarn playwright test :heavy_check_mark: 56 passed, 1 fail
One test seems broken ?
  Slow test file: [safari] › private.spec.ts (10m)
  Slow test file: [firefox] › private.spec.ts (31s)
  Consider splitting slow test files to speed up parallel execution

  1 failed
    [safari] › private.spec.ts:194:7 › PrivateDirectory › basicMv can move content between directories
  59 passed (11m)

Before:
release [optimized] target(s) in 18.08s
Done in 19.38s
740K	pkg/wnfs_wasm_bg.wasm`

After:
release [optimized] target(s) in 18.22s
Done in 19.08s
572K	pkg/wnfs_wasm_bg.wasm

Sheds ~200 kB
1 Failing Test
  1) [safari] › private.spec.ts:194:7 › PrivateDirectory › basicMv can move content between directories

    Test timeout of 600000ms exceeded.

    page.evaluate: Target closed

      193 |
      194 |   test("basicMv can move content between directories", async ({ page }) => {
    > 195 |     const [imagesContent, picturesContent] = await page.evaluate(async () => {
          |                                                         ^
      196 |       const {
      197 |         wnfs: { PrivateDirectory, PrivateForest, Namefilter },
      198 |         mock: { MemoryBlockStore, Rng },

        at /home/foobar/cc/rs-wnfs/wnfs-wasm/tests/private.spec.ts:195:57

    Pending operations:
      - page.evaluate at tests/private.spec.ts:195:57

@pinkforest to focus this on wasm builds, should we override just that package: https://doc.rust-lang.org/cargo/reference/profiles.html#overrides? It may not be what we want for the rust-only package: https://nnethercote.github.io/perf-book/build-configuration.html.

The release profile would be here only for us in the workspace to test the .wasm codesize out -
Given this when the library gets used people have their own release profiles thus we should maybe test them all given tradeoffs ? One for code size and one for the performance.
Further to that We can adopt cfg's for desired performance priorities - I will do as separate write-up on that.

1 Failing Test

Hm. That doesn't seem to fail in CI, so should be ok. I wonder what's happening on your end.

The release profile would be here only for us in the workspace to test the .wasm codesize out -

Not only that - we prepare the .wasm and ship it when we bundle the npm package. So it practically reduces our npm package size :raised_hands:
I do wonder whether we should have separate "debug" and "release" .wasms though. That all depends on how well Wasm can be debugged in browsers. For now it's pretty bad, so let's optimize the size :P

About the benchmark being 2x slower: I really don't know what that's about unfortunately. I recently re-ran the benchmarking action on another PR where it also was 2x slower, and I think re-running didn't show the issue anymore, so it's flakey. I'll do the same on this PR :crossed_fingers:

Awesome. Thanks for this fix. Right now the workspace level profile change affects wnfs as a rust dep. Since cargo does not support target-specific profile settings and simply moving the settings into wnfs-wasm doesn't work, we should probably move these settings to .cargo/config.toml.
We should also have it in mind that we are optimizing wasm for build size as the default behaviour if that is what we really want.

Reached similar file size with a config that targets just wasm32 arch.
https://github.com/wnfs-wg/rs-wnfs/compare/appcypher/chore-strip-flags.