Cache searches for default config files during FAR

It's not unusual for FAR to find more than one result in a given file, but the work of searching the file system for the associated tsconfig.json will only be cached if the file is open (which is frequently not the case for FAR).

There are so many layers of caching (in this case, the tsconfig-existence cache seems to be the main one) that this has no effect in practice.


[Components] Support for IntelliSense on components and their parameters

I am trying to consume a third-party component in my project. However, it (apparently) currently has no way of exposing IntelliSense/XML documentation:

for the component itself, there simply is no obvious syntax. You never explicitly specify the class name (it is inferred from the file name); therefore, the typical approach of annotating that name with documentation doesn't work.

for its parameters inside a @functions block, normal C# syntax will work. However, parameters aren't designed to be public, so this doesn't get exported to XML documentation either. The .cshtml.g.cs files do not appear to retain XML comments.

Describe the solution you'd like

there should be syntax for declaring a component's documentation. For example, a new @doc directive would do the trick:

@inherits ComponentBase

@doc {
/// <summary>
/// This is an exciting example Razor Component!
/// </summary>
}

as part of the components build process, XML should be emitted

the Razor parser should pick these up on the consuming side:

<MyExampleComponent />
<!-- hovering over the above should show "This is an exciting example Razor Component!" -->

Describe alternatives you've considered
To avoid introducing new syntax, the documentation could perhaps also be placed inside a separate partial class.
However, this would be more cumbersome, and it appears the tooling still wouldn't pick this up anyway.
Additional context
One concrete example is BlazorStrap, a Bootstrap port to Razor Components. Consuming the components would feel more natural if additional documentation were provided as part of IntelliSense.

The documentation here says that non-public methods can still have documentation. If this isn't correct in practice when we should fix that.
Even if generated documentation requires public I don't think we should take any specific here because the guidance is that component parameters should not have a public SET method. It's fine to use a public getter.
Lastly for classes, it's our plan to generate component classes as partial so that you can have a code-behind file. This should be a fine place for class-level documentation.


DMX Input from Enttec USB Pro MK2 does not work.

After updating to 4.10.4 to 4.10.5a, DMX input from my Enttec DMX USB Pro MK2 no longer works. I have also tested with both the Qt4 and Qt5 Git builds and this issue is present on all current builds after 4.10.4. QLC+ reports that the device is operating correctly, even while this issue is occurring, and that the driver in use is libftdi. DMX output works but is not particularly reliable, with the lights/interface occasionally no longer responding to QLC+ after it has been running for some time. I am running Ubuntu 16.04, fully updated at the time of opening this issue. Downgrading back to 4.10.4 fixes both issues, therefore this appears to be a regression in 4.10.5a. Also, I have removed the ~/.config/qlcplus folder when switching between versions as well.

I understand you might have encounter an issue, but I don't quite understand why everybody is ignoring the message that is displayed when opening a new issue.
Where is the related forum discussion to your issue report ?
Where are the debug messages supposed to help us resolving the issue ?
Saying "does not work" doesn't help much, does it ?
Same goes for "is not particularly reliable". Doing what ? After how long ? How many channels ? How many universes ? Debug messages ?


Migrate file watch tests to new harness #3584

This one is just a move, it should not interfere with other tests. Let's see what happen in the platform on next release.


sort list of indices in a snapshot

to ease the restore process of just some indices, sort the indices by their name.
this pull request fixes #419

This was solved in https://github.com/lmenezes/cerebro/commit/5317ddd54de574708dbf02e713b5e2d0865441e0
Thanks for contributing!

I just updated Cerebro to Docker v0.9.2 and the snapshot indices list is still unsorted. I can see that the | orderBy:i is missing on that element. How could that happen?


Anti-Aliasing

First, thank you for a very useful utility.
Have you thought about anti-aliasing the plot.  It may, in some circumstances, make the plots easier to interpret?

Let's try cool-retro-term!
I really like this terminal emulator. Fantastic anti-aliasing.

Joking aside, I don't think anti-aliasing is a issue that can be controlled by UnicodePlot. That's the job of the terminal emulator. Please find your favorite terminal emulator that allows anti-aliasing and set it up.

@obromios What did you mean by "anti-aliasing" in this context?  I couldn't imagine what the result you want because UnicodePlot just makes a plot result by filling Unicode characters while anti-aliasing is a technique for altering a bitmap image.
Could you describe it by illustrating both before and after outcomes if the "anti-aliasing" were supported?

@mrkn, anti-aliasing is a general term referring to correction of signals being reconstructed at too low a sampling rate. You are correct that in image processing, the most common way to do this is altering the bit map image.  However, I was wondering whether anyone had done some thinking about this for this gem. In particular with the full unicode character set, you have characters like the spacing modifier letters, that might allow you to do some rough anti-aliasing.  It may well be an up hill task, but I will put this on my list of things to think about.

@obromios I'm interested in how to perform anti-aliasing with spacing modifier letters. UnicodePlot is designed for using monospace characters to build rectangle canvas to show in a terminal so I consider surrogate pairs etc. are not usable. I would like to see more detail example. Could you illustrate how to use such special letters?
By the way, if you want to get more higher resolution plots, you can specify a larger canvas size by passing width and height parameter like:
UnicodePlot.lineplot(x, y_sin, name: "sin(x)", width: 200, height: 50)


StoreApiSeoResolver and auth_required=false lead to TypeError

Description:
This issue is about two bugs, one leading the way to the other. Both occur in a headless Shopware 6 installation, with version <IP_ADDRESS>, but the same code responsible for the problem remains unchanged in the current latest version (<IP_ADDRESS> & trunk).
Environment:
Local & Platform.sh (Shopware PaaS) Dedicated.
Using Shopware Composable Frontends as frontend for a headless backend.
Steps to reproduce:

Create a new store-api route (as shown in the docs).
Under defaults in the #[Route] attribute, add the auth_required option with value false, to disable authentication (undocumented?). This option is used in the Shopware Core code.
Then request that route with header sw-include-seo-urls set to true or 1 (any non-empty value). This is done by the shopware-pwa library by default, a normal request would not fail.

Expected result:
The route response is returned. Same as it would be with authentication enabled and an access-key provided in the header.
Actual result:
A PHP \TypeError is thrown, because in StoreApiSeoResolver::addSeoInformation(), the sw-sales-channel-context attribute (usually set to the SalesChannelContext object) is passed to enrich() as second argument.
It turns out said attribute is only set if a sales-channel could be determined, which is not possible with auth_required being set to false.

The option turns off the resolution of an access-key to a sales-channel ID, which is saved as attribute, in SalesChannelAuthenticationListener::validateRequest() (priority -2).
Another listener after that checks if the sales-channel ID is available as attribute and would normally create the SalesChannelContext as attribute. Since the ID is missing, because of a check for auth_required in the previous subscriber, this does not happen.
No problem thus far.
The response is a StoreApiResponse instance, so the StoreApiSeoResolver is triggered, to enrich the response content. As described, the context is accessed from the attributes, but at this point null, and passed to a non-nullable argument.

A "normal" request without the sw-include-seo-urls header set would not fail here, as the resolver logic is not executed without such header present.

But there is more... Working around this problem with a decorator of that latter listener still doesn't solve the problem. As it turns out:

The StoreApiSeoResolver has the same event listener priority as the StoreApiResponseListener, which usually encodes the response properly (i.e. replaces the custom response object with a JsonResponse and encoded JSON).
Both of them have priority 10_000 set for the event. Consequential to that, the resolver logic was never called, when the encoder was first in line.
To avoid that problem, setting a higher priority on the StoreApiSeoResolver did the trick.

IMHO the absence of the context object is something that should be handled gracefully in the resolver, as well as clearly separating the steps of SEO enrichment and response struct encoding.

Best regards
Marcel

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-36924
[created from NEXT-36924, comment 494506]


I have added the linear search file .

Please star this repository to show your support in the meantime I will review this PR.


New name & first exercise

Are we able to add a ``` formatted version of the code into these pages? It would be good for accessibility to have a text representation - but otherwise looks great to me!

That is a good idea! Let me add that.


Error after 'npm install dotenv'. (Pronounce by yourself:

#5  I've referred to it, but the error hasn't been resolved.
I have replaced line 68 in main.js with
try {
fs.unlinkSync('path/to/output.wav');
} catch (err) {
console.log('No previous file to delete');
}
Also change ffmpeg_path to a valid path
But still the same problem
’
listening on localhost:8000
Pronounce by yourself: [21:37] error: Reconnecting in 2 seconds..
Unable to connect.
[21:38] error: Reconnecting in 2 seconds..
[21:38] error: Unable to connect.
‘

hey that is an issue not with dotenv but with twitch please refer to my install docs on my repo to get a better understanding of the installation you can also reference my code for a better tts system. https://github.com/InsanityLabs/AIVTuber/blob/main/INSTALL.md


Tagged unions/product types for results

seq provides a convenient way to return a nicely structured result (and close enough, if not exactly what you want most of the time), namely by using it with kwargs.
e.g.
>>> seq(a=any_char, b=any_char).parse("ab")
{'a': 'a', 'b': 'b'}

This is basically an encoding of a product type.
It would be nice if there was a similarly convenient way to return something analogous for alternatives (i.e. alt or the | operator), the result of which is encodable as a tagged union/is an encoding of a sum type.
Example pseudocode:
>>> alt(a=any_char, b=any_char).parse("a")
{'a': 'a'}
>>> alt(a=any_char, b=any_char).parse("b")
{'b': 'b'}

I don't see a way to use this together with an operator without hacks like passing it tuples or something (like (name, parser) | (name,parser)), but i think this would still be nice to have for the alt() form.

A thrown together example, based on seq:
def alt(*parsers, **kw_parsers):
    if not parsers and not kw_parsers:
        return fail('<empty alt>')

    if parsers and kw_parsers:
        raise ValueError("Use either positional arguments or keyword arguments with alt, not both")

    if parsers:
        @Parser
        def alt_parser(stream, index):
            result = None
            for parser in parsers:
                result = parser(stream, index).aggregate(result)
                if result.status:
                    return result

            return result

        return alt_parser

    else:
        @Parser
        def alt_kwarg_parser(stream, index):
            result = None
            for name, parser in kw_parsers.items():
                result = parser(stream, index).aggregate(result)
                if result.status:
                    #I'm not actually sure if this is the correct way to use aggregate here, I haven't looked at how it's supposed to work
                    return Result.success(result.index, { name: result.value }).aggregate(result)

            return result

        return alt_kwarg_parser

(also needs the >= 3.6 check)

I would prefer (name, value) for this, but it seems reasonable to me!

Reason being: you could follow it up with combine, like alt(a=..., b=...).combine(Node) and would receive Node(type, value)

I'm making this up as I go and use parsy more.
What you said sounds reasonable.
I happen to have been using(/my rationale for using) dicts (was) because it's lets me directly address the component of the result that I want.
I don't know right now which should be done, or if it's possible to have both.

@deliciouslytyped Could you give a full example of what you are thinking of? The kind of thing that could potentially go in our docs? For me at least that would help assess whether this would fit into the existing patterns we are encouraging in parsy.

if i understand correctly, it's something like:
letters = regex(r'\w+')
numbers = regex(r'\d+')
atom = alt(word=letters, int=numbers.map(int))

atom.parse('abcd') # => ('word', 'abcd')
atom.parse('1234') # => ('int', 1234)

without pattern matching, it's difficult for python to actually make use of those tuple values, but those seem more correct in general.

i mean, something hacky like this would work, though.
match = lambda fs: lambda v: fs[v[0]](v[1])

atom.map(match(word=lambda w: ..., int=lambda i: ...))

Thanks @jneen  for the explanation.
Currently we have the tag method that can do something very similar:
letters = regex(r'\w+')
numbers = regex(r'\d+')
atom = letters.tag('word') | numbers.tag('int')

One of the purposes of this is to be able to pass to combine/combine_dict - see docs - as you suggest.
Regarding building this into alt, I'm wondering whether is particular value in having another way to do the same thing? Without proper sum types in Python, it's difficult to know exactly what pattern to encourage for building something that emulates them.

Sorry, I'm super tired right now, I think my use of dicts might have been minimally analogous to pattern matching, but I'm not sure.

Ok tag looks quite relevant. On the other hand you can choose to not tag some elements of the alternative. I'm not sure if that's desirable.
seq does force using one or the other of positional/kwargs, but not mixing.


EEG channel type inconsistency

Some channel types have counts in the .eeg JSON files and others do not. Newly declared channel types GSR, RESP, and TEMP do not have counts
GSRChannelCount
RESPChannelCount
TEMPChannelCount
While EOG, EMG, ECG do. Worse, when the fields above are defined, the BIDS validator fails. This is made even worse by the fact that EOGChannelCount, EMGChannelCount, and ECGChannelCount are mandatory fields. The error from the validator is not informative when trying to add these fields (failed because of badly formated .eeg file). I have tried to look at the JS code but it is too convoluted. I beg whoever is able to change this code to return meaningful errors.
Overall, I would remove this redundant information of channel count (except for EEG and non-EEG channel counts). One can simply look at the channel file to see what type of channels are there. This is a source of potential error and inconsistency. Big choice obviously.

This is made even worse by the fact that EOGChannelCount, EMGChannelCount, and ECGChannelCount are mandatory fields

what makes you think that these are mandatory? to my knowledge and this JSON schema, they aren't :thinking:

The error from the validator is not informative when trying to add these fields (failed because of badly formated .eeg file).

the error you get there is because you want to add fields to the *eeg.json file that are not defined in the specification. To me this makes sense, but others have said that it's problematic, see: https://github.com/bids-standard/bids-validator/issues/1044 and https://github.com/bids-standard/bids-specification/issues/637

I have tried to look at the JS code but it is too convoluted.

The JSON files are getting evaluated using https://json-schema.org/ --> and the schemas for the validator are all located here. I agree that it's very difficult to find and improvements of the documentation are really needed.

Overall, I would remove this redundant information of channel count (except for EEG and non-EEG channel counts). One can simply look at the channel file to see what type of channels are there.

I tend to agree with you. However, given that the channel counts are only "RECOMMENDED" it'd be fair enough for us (BIDS) to not add some new fields like GSRChannelCount, RESPChannelCount, etc. to the specification and just leave the state as it is. In BIDS 2.0 we could then (potentially, up to discussion) completely remove all ChannelCount fields, but not before that - because it'd be a backwards incompatible change.
cc @bids-standard/raw-electrophys-eeg

what makes you think that these are mandatory? to my knowledge and this JSON schema, they aren't 🤔

You are right. https://github.com/bids-standard/bids-specification/blob/master/src/04-modality-specific-files/03-electroencephalography.md
Sorry about that. They used to be mandatory I think.

The JSON files are getting evaluated using https://json-schema.org/ --> and the schemas for the validator are all located here. I agree that it's very difficult to find and improvements of the documentation are really needed.

It would be great for the validator to indicate which part of the file create problem.

Overall, I would remove this redundant information of channel count (except for EEG and non-EEG channel counts). One can simply look at the channel file to see what type of channels are there.

I tend to agree with you. However, given that the channel counts are only "RECOMMENDED" it'd be fair enough for us (BIDS) to not add some new fields like GSRChannelCount, RESPChannelCount, etc. to the specification and just leave the state as it is. In BIDS 2.0 we could then (potentially, up to discussion) completely remove all ChannelCount fields, but not before that - because it'd be a backward-incompatible change.

Yes, you would want to preserve backward compatibility of course.


How-to update the pipeline flowchart

Description of feature
We have a in-progress flowchart for the pipeline: https://docs.google.com/drawings/d/1QZsgxM4zuArI-N2kuWzwJB5PpjwOu8XxJ3-DInlNYEk/edit
To encourage everyone to contribute to it, we should write a "how-to".

Not applicable anymore.


Add dynamic expiry message to service registry table

Thanks for making this update, @suyash-naithani!
This this storybook example matches the behavior I'd expect to see here, in that the message changes from "{x} months {y} days" to "{y} days {z} hours" depending on the expiration date/time.
But just to confirm, does that storybook example reflect the behavior we'd see in the SR UI?

Thanks for making this update, @suyash-naithani!
This this storybook example matches the behavior I'd expect to see here, in that the message changes from "{x} months {y} days" to "{y} days {z} hours" depending on the expiration date/time.
But just to confirm, does that storybook example reflect the behavior we'd see in the SR UI?

Yes, you're right. When the time left is less than a month, it would change to days and hours


Abstract stage 2 tape writing into JsonWriter interface

This implements #439, decouples stage 2 validation and parsing from tape / iterator production using a ParsedJsonWriter class with the following interface:
struct ParsedJsonWriter {
  ErrorValues on_error(ErrorValues error_code);
  ErrorValues on_success(ErrorValues success_code);

  bool on_start_document(uint32_t depth);
  bool on_end_document(uint32_t depth);
  bool on_start_object(uint32_t depth);
  bool on_end_object(uint32_t depth);
  bool on_start_array(uint32_t depth);
  bool on_end_array(uint32_t depth);

  bool on_true_atom();
  bool on_false_atom();
  bool on_null_atom();

  // Returns the destination address where the parser should put parsed strings
  uint8_t *on_start_string();
  // Takes in the final destination pointer so if the parsed json wants, it can calculate length
  bool on_end_string(uint8_t *dst);

  bool on_number_s64(int64_t value);
  bool on_number_u64(uint64_t value);
  bool on_number_double(double value);
};

I did this in a series of commits so I could isolate performance dips. on_start/end_string actually increases performance somewhat. I'll squash them into one before merging, as it's really not useful in pieces.
This should support all the various tape experiments we have going on. It isn't flexible enough to support the crazy stage 2 decomposition experiment, but I don't think we should optimize for that--we'll solve it as it comes.
This does not eliminate ParsedJson references from the structural parser, and that will be needed before we can truly make new tapes. Some things, like ret_address, which are really part of the structural validator algorithm--no matter what tape we use, we'll still have that--so should be moved elsewhere. Some things, like structural_indexes, only exist as input from stage 1.
This differs from #463 a bit in naming, and in that it creates a separate ParsedJsonWriter class (which I'd like to move more code to!). I'm not particular about the naming. I kind of want to see ParsedJson only expose user-facing methods (or at least, I'd like to present such a class to the user even if it's not ParsedJson), which is why I made the writer class. It also seems like a natural place to move current_loc and current_string_buffer_loc, but my first attempts to do so led to performance degradation (see the visitor-members branch), so I've left them in ParsedJson for now.
Performance Learnings
A few performance things I noted during this:

switch case goto is sensitive to changes
One of the modifications that can kill perf in stage 2 is using a dynamic goto like goto pj.ret_address[depth] directly from inside the switch case. You'll note that even though I moved most of the other logic out of scope_end and into the actual } and ] branches, we still jump to the label and then immediately jump away. Doing the jump away directly in the switch led to a significant (> 10%) performance hit for stage 2.
My hypothesis is that g++ is generating a static goto jump_table[c] for the switch, and stops doing that when you mix in something dynamic.

Sub-switches can be better
I attempted to make true, false and null separate arms of the parse_value switch, and it made things a little slower. My hypothesis is that atoms are so rare that the decoding cost of more instructions outweighs the speedup for individual atoms. Which probably implies that switches should be ordered in descending order of likelihood ... but I don't know how the decoder and branch predictor interact. Might not actually be a factor.
It's also possible this is related to the previous point; all three atoms jump to the same place, so it could be that increasing by 2 cases crossed some threshold that increased the switch/goto cost.

Templatizing interferes with optimizations
Templatizing parse_number--even without making any other change--takes a performance hit. The templatizing commit makes stage 2 3% slower than the previous commit on my machine.
I'd love to know why this is. I'd rather go with the template solution than the current "rely on people
hooking up the right names to the namespace" solution for implementation switching (the one we use for utf8).

unified_machine continues to resist refactoring
I made another desperate attempt to unify the normal parser and the streaming parser, because I'm tired of making the same change in both places ... but performance drops happened. The frustrating bit is that literally the only differences are three if statements outside the main loop: one at the beginning (in start()) and two at the end (in finish()). (And the fact that next_json starts at non-zero and gets updated at the end.) start and finish shouldn't take much of the parse time, yet the drop is significant (I think I got it down to a 5% loss on my best attempt).
This time my attempt was to make a templatized structural_parser<bool streaming> with if (streaming) in the two places that matter. I even went and factored out those bits, leaving structural_parser un-templatized, and having a unified_machine<bool streaming>(structural_parser parser) do the different bits). In both cases, performance of the main parser dropped--IIRC, the second one was the better attempt at 5%.

@lemite I don't believe the use of the ParsedJsonWriter intermediary has anything to do with a performance loss: if I hang the on_* methods off ParsedJson, as you do in #463, performance does not recover: the jkeiser/visitor2 branch does that.

I'd like to have more discussion, and maybe we'll make more changes, but I'm comfortable with removing the templatization for this checkin and adding a stable way to pick a visitor in a future patch.

I'm also not opposed to fixing up #463 instead ... I forgot that existed when I sat down to do this, sorry for repeating it :/

ARM issues are fixed.

Looks brilliant.

Just updated with a clean rebase (I had a duplicate of the commit we just merged from master). Code is source-identical except some dates in the amalgamated source.

I see a very small regression, but well under 1%, so it is fine.

Weird! I actually saw a very small speedup. I'll check this on the Skylakes and ampere.
I'd like to bisect and find out which commit caused the regression. I'm also ok with a tiny regression to get in a maintainable state, but it's worth at least seeing what we can do first.
Though I guess we can merge and do the investigation in parallel.
Do let me know if you'd prefer different naming. I built the patch on my naming intuitions having forgotten you had already made a proposed patch.

@jkeiser Please don't investigate.
But if you must...
All around, for input files with numbers, we see the number of instructions slightly up. And it can lead to higher times...
Here are the results on ARM Skylark...
Before this PR:
$ ./parsemaster jsonexamples/numbers.json
number of iterations 200

jsonexamples/numbers.json
=========================
     2345 blocks -     150124 bytes - 20003 structurals ( 13.3 %)
special blocks with: utf8         0 (  0.0 %) - escape         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals      2346 (100.0 %) - 8+ structurals      2345 (100.0 %) - 16+ structurals         0 (  0.0 %)
special block flips: utf8         0 (  0.0 %) - escape         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals         0 (  0.0 %) - 8+ structurals         1 (  0.0 %) - 16+ structurals         0 (  0.0 %)

All Stages
|    Speed        : 210.5311 ns per block ( 45.16%) -   3.2900 ns per byte -  24.6916 ns per structural -    0.304 GB/s
|    Cycles       : 632.9565 per block    ( 98.19%) -   9.8913 per byte    -  74.2347 per structural    -    3.006 GHz est. frequency
|    Instructions : 790.2945 per block    (100.00%) -  12.3500 per byte    -  92.6876 per structural    -    1.249 per cycle
|    Misses       :    3192 branch misses ( 99.52%) - 6027 cache misses ( 99.99%) - 272497.00 cache references
|- Stage 1
|    Speed        :  83.1100 ns per block ( 17.83%) -   1.2988 ns per byte -   9.7473 ns per structural -    0.770 GB/s
|    Cycles       : 249.5959 per block    ( 38.72%) -   3.9005 per byte    -  29.2732 per structural    -    3.003 GHz est. frequency
|    Instructions : 196.6266 per block    ( 24.88%) -   3.0727 per byte    -  23.0608 per structural    -    0.788 per cycle
|    Misses       :     610 branch misses ( 19.02%) - 2372 cache misses ( 39.35%) - 46651.00 cache references
|- Stage 2
|    Speed        : 126.2276 ns per block ( 27.07%) -   1.9726 ns per byte -  14.8043 ns per structural -    0.507 GB/s
|    Cycles       : 379.3129 per block    ( 58.84%) -   5.9276 per byte    -  44.4867 per structural    -    3.005 GHz est. frequency
|    Instructions : 593.0644 per block    ( 75.04%) -   9.2679 per byte    -  69.5560 per structural    -    1.564 per cycle
|    Misses       :    2523 branch misses ( 78.66%) - 3633 cache misses ( 60.27%) - 225181.00 cache references

After this PR:
$ ./parse jsonexamples/numbers.json
number of iterations 200

jsonexamples/numbers.json
=========================
     2345 blocks -     150124 bytes - 20003 structurals ( 13.3 %)
special blocks with: utf8         0 (  0.0 %) - escape         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals      2346 (100.0 %) - 8+ structurals      2345 (100.0 %) - 16+ structurals         0 (  0.0 %)
special block flips: utf8         0 (  0.0 %) - escape         0 (  0.0 %) - 0 structurals         0 (  0.0 %) - 1+ structurals         0 (  0.0 %) - 8+ structurals         1 (  0.0 %) - 16+ structurals         0 (  0.0 %)

All Stages
|    Speed        : 216.7822 ns per block ( 46.21%) -   3.3877 ns per byte -  25.4247 ns per structural -    0.295 GB/s
|    Cycles       : 651.9919 per block    ( 99.49%) -  10.1887 per byte    -  76.4672 per structural    -    3.008 GHz est. frequency
|    Instructions : 794.5580 per block    (100.00%) -  12.4166 per byte    -  93.1877 per structural    -    1.219 per cycle
|    Misses       :    3382 branch misses (100.97%) - 6044 cache misses ( 99.95%) - 272816.00 cache references
|- Stage 1
|    Speed        :  83.0814 ns per block ( 17.71%) -   1.2983 ns per byte -   9.7440 ns per structural -    0.770 GB/s
|    Cycles       : 249.5482 per block    ( 38.08%) -   3.8997 per byte    -  29.2676 per structural    -    3.004 GHz est. frequency
|    Instructions : 196.6266 per block    ( 24.75%) -   3.0727 per byte    -  23.0608 per structural    -    0.788 per cycle
|    Misses       :     617 branch misses ( 18.42%) - 2373 cache misses ( 39.24%) - 46627.00 cache references
|- Stage 2
|    Speed        : 132.9241 ns per block ( 28.33%) -   2.0772 ns per byte -  15.5897 ns per structural -    0.481 GB/s
|    Cycles       : 399.4753 per block    ( 60.96%) -   6.2426 per byte    -  46.8514 per structural    -    3.005 GHz est. frequency
|    Instructions : 597.3278 per block    ( 75.18%) -   9.3345 per byte    -  70.0560 per structural    -    1.495 per cycle
|    Misses       :    2697 branch misses ( 80.52%) - 3651 cache misses ( 60.37%) - 225513.00 cache references

So in stage 2, we go from 379.3129 cycles per block to  399.4753 cycles  per block (so a 5% increase). This translates into a 3% regression overall. But it is a small core.
On x64, I was only able to see sub-1% regressions.
It is fine. Don't worry.

Which probably implies that switches should be ordered in descending order of likelihood

The compiler has two ways to implement a switch/case (two main ways). One is as a series of compare/jump. The other one is to use a jump table. I guess it can mix and match.
If you have a jump table, then the order of entries is irrelevant.
If you have many entries in the switch case, you better hope that your switch case is not implemented as a series of compare/jump if the last entries are frequent, for obvious reasons.

I'm also not opposed to fixing up #463 instead ... I forgot that existed when I sat down to do this, sorry for repeating it :/

Do not apologize. I throw away most of my code, often by design.

Sure, I won't make investigation a prereq to merge.
But that's a big enough jump I'd like to at least see what's up! The nice thing is I can just go to the patch that added the number visitor (assuming that's where the regression is) and try a few different things to see if I can bring it back down.

Do not apologize. I throw away most of my code, often by design.

Me too. It's more about respecting another person's work and incorporating their thoughts, for me, than the code itself.

It's more about respecting another person's work

I think you will have to work really hard to insult me by coding around me.

Which probably implies that switches should be ordered in descending order of likelihood

Interestingly, it does not appear that compile abides by the order you provide the cases in!

Same code, different compiler, different order!!!

My results show speedups (which I frankly have trouble explaining ...) on numbers.json:

Computer
Master Stage 2
PR Stage 2
Speedup

skylake
1.434 GB/s
1.469 GB/s
+2.5%

skylake-x
0.930 GB/s
0.997 GB/s
+7.2%

Methodology:
git checkout master; git pull; make parse; ./parse -n 10000 jsonexamples/numbers.json; ./parse -n 10000 jsonexamples/numbers.json
git checkout jkeiser/visitor; git pull; make parse; ./parse -n 10000 jsonexamples/numbers.json; ./parse -n 10000 jsonexamples/numbers.json

I ran each twice to make sure the number was stable (that's a habit these days).

There's a lot of variation on ampere today, which I don't normally see ... dockerd seems to be doing some work, maybe I'm conflicting with you?

One of the modifications that can kill perf in stage 2 is using a dynamic goto like goto pj.ret_address[depth] directly from inside the switch case. You'll note that even though I moved most of the other logic out of scope_end and into the actual } and ] branches, we still jump to the label and then immediately jump away. Doing the jump away directly in the switch led to a significant (> 10%) performance hit for stage 2. My hypothesis is that g++ is generating a static goto jump_table[c] for the switch, and stops doing that when you mix in something dynamic.

I'd be surprised if it got compiled to a jump table given that it is only a switch between two states. I cannot see a good reason not to do a sequence of two branches.
Also...
Why would you not expect the compiler to compile this...
...
        case '}':
            goto final;
..
    final:
        goto *table[x];

to roughly the same as
...
        case '}':
             goto *table[x];

Why would the compiler jump and then jump again? It seems like a basic optimization to avoid the unnecessary jump.
Now compiling with LLVM clang 6.0, I see no performance difference. So I think we are hitting the quirks of the compiler... not something fundamental.

I think I'm going to leave it alone as suggested. I did run the numbers, and what I found is strange:
The break point for ARM on numbers.json appears to be [the string visitor](https://g
ithub.com/lemire/simdjson/pull/477/commits/7a200dddfb05e8e04c8ea8ec92accc152c875bfd) patch. Number parsing is unchanged until two commits later. Given that this file has no strings, I am befuddled by this result.
Note: I don't trust these numbers 100%, but I did run a crapton. Out of a million iterations or so on various commits after the string patch (and over 500K iterations on the string patch itself) I was unable to get a number higher than 5.29 GB/s. Commits before that (including the one immediately before) were easily able to get 5.36-5.39 GB/s within 100K iterations or so. Weirder still, twitter.json, which has a lot of strings, is basically unaffected!
This means a patch for strings caused a 1% overall performance drop on files that only have numbers.
The good news, I suppose, is that this particular commit has a lot of possible variations that could be tried. It's definitely a little different from the code we had before (hence the speedup on Intel). I'm spooked, but I don't think I'm going to continue. I want to change where/how strings get parsed anyway.

@jkeiser My only criticism has been expressed as a PR:
https://github.com/lemire/simdjson/pull/483

I'd be surprised if it got compiled to a jump table given that it is only a switch between two states. I cannot see a good reason not to do a sequence of two branches.

Yeah, two branches should be enough (it's 3 states including error). I don't know what pushes the compiler to decide between branches and jump tables. Note that my hypothesis about the jump table is unverified in assembly because I was tossing out ideas based on the change that fixed the problem, and just kinda moved on to make the next commit, having fixed the issue.

Also...
Why would you not expect the compiler to compile this...
...
        case '}':
            goto final;
...
    final:
        goto *table[x];

to roughly the same as
...
        case '}':
             goto *table[x];

Well, I understand how a series of statically known addresses can compile to a jump table:
  switch(c) {
    case '"': goto A;
    case '}': goto B;
    default: goto C;
  }
B:
  goto ret_address;

<compiles to jump table>
static const void* jump_table = { ... &&B, ... };
goto jump_table[c];
C:
   goto ret_address;

I could totally see this nixing the optimization:
  switch(c) {
    case '"': goto A;
    case '}': goto B;
    default: goto ret_address;
  }
<jump table>
static const void* jump_table = { ... <??? can't put ret_address here, it's not const static> ... }

Now compiling with LLVM clang 6.0, I see no performance difference. So I think we are hitting the quirks of the compiler... not something fundamental.

Oh, I agree with that for sure. It's just that this explains at least some of the performance drops that have vexed me when trying to change stage 2 :)

I don't know what pushes the compiler to decide between branches and jump tables.

Possibly some simple heuristics. A table is simple and fast, but it has non-trivial latency... like... 4 cycles or so plus a few cycles to adjust the range and do the validation... and it is still subject to mispredictions... meanwhile, quite a few predicted branches, with instruction fusion, can easily fit inside 4 cycles.
Of course, you also don't want the table to be too large. So that's another consideration.
My guess is that the compiler takes into account the range of values and the number of cases...

I am almost certain that this won't get compiled as a jump table:
 switch(c) {
    case '"': goto A;
    case '}': goto B;
    default: goto ret_address;
  }

Ok. So let us see how many jmp we have currently...
$ grep jmp stage2_build_tape.s|wc
    603    1206    7363

So 603...
Let me remove all of the goto scope_end...
$ grep jmp stage2_build_tape.s|wc
    617    1234    7506

So 617...
So 14 more jumps. I think we have two stage 2 (sse and avx), so that's 7 more jumps per stage 2.
Please read carefully: by removing the goto scope_end, I created more jmp in the assembly.
It is the opposite of what you might expect.
Looking at the assembly, it does look like it sometimes "inline" the "goto scope_end" (it does the dynamic goto right there without a prior jump) and sometimes it does not (it does some work and then jump to a location where the jump happens). So two times it will inline and two times it does not inline.
The switch at object_continue and array_continue have an "inlined" goto (there is no intermediate jump). However the jumps at object_begin and array_begin are to an intermediate location where the actual jump happens.
Oddly enough, by replacing just one goto scope_end, I can get the number of jmp even higher (to 620).
Take into account that we have one gigantic function with lots and lots of jumps... like hundreds of them...
For now I conclude that it is hard to reason about this code at this level.

Merge at will.

The switch at object_continue and array_continue have an "inlined" goto (there is no intermediate jump). However the jumps at object_begin and array_begin are to an intermediate location where the actual jump happens.

Notice how convenient this is... The branches are at object_begin and array_begin are never taken (only for empty arrays and objects). We don't care about them. The branches at object_continue and array_continue are commonly taken and they are inlined.

That does work out nicely :)

Let me remove all of the goto scope_end...

Did you remove them or replace them with the dynamic jump from scope_end itself?

Please read carefully: by removing the goto scope_end, I created more jmp in the assembly.

I actually sort of expect that based on the hypothesis: if it's jumptabling when scope_end is in the picture, and you remove scope_end or replace it with the dynamic jump, it'll probably stop jumptabling and switch to branches. Thus more jmps.
I totally get your point that it ought to already be doing branches, but it's still consistent with that hypothesis. Anyway, it'll be assembly-readin' time next time. This will come up again :)

When I wrote that I removed the gotos, I mean that I replaced them with the dynamic jump.
I did not check how the switch were compiled per se. It is not hard, but I assumed that they are sequences of branches.


Localized URL for root pages seems broken

Hi there 👋
I seem to have hit a bug, using this package.
When a rootnode has multiple hostnames assigned, each with their own language, getting their URL doesn't work correctly...
Example

One root node with two languages, English (US) and Danish
One has example.com set as hostname, the other has example.com/da - each with their own language

When trying to render a language picker, we no longer get the correct URLs for the root node; e.g. Model.Root().Url("da") and Model.Root().Url("en-us") returns the same URL (/ or https://example.com/ if using UrlMode.Absolute)
If I uninstall InvisibleNodes, the URLs are correctly rendered.

[!NOTE]
The URLs render correctly in the Links area on Umbraco's Info tab

I'm using Umbraco v13.3.1 and your latest (at time of writing) package release, v2.0.1
Thanks 🙌

Another note after some more testing - if the hostnames are different (e.g. by TLD or otherwise) it does seem to work correctly; so only when using the "one-level paths" version does your package seem to get the wrong idea.

Hey @greystate, thanks for taking the time to raise this issue! You're certainly putting the package through its paces. Sorry I haven't been able to get round to this sooner.
I think I might have an idea what's going on here, will take a look and hopefully report back with some good news.

Hey @greystate, I have just released v2.0.2 of the package.
Are you able to try that out and let me know if this resolves the issue?

Hi @ljfio — I don't think it does; I get an error when I try to publish the root node when I've added the current domain and one more using the subdirectory approach - e.g.:

English (US): https://localhost:12345
Danish: https://localhost:12345/da

Using different domains seems to work as expected (i.e. example.org and example.dk)
/Chriztian

I released a new version v2.0.3 which I think resolves this exception being thrown. It wasn't something I had picked up in testing. Can you give that version a go and let me know?
If not would you be able to tell me if there's any additional information about the root node I might find useful (e.g. "varies by culture", have renamed the node previously, has a URL redirect).

@ljfio It looks like that did the trick 👍 Thanks again for sticking with it 🙌

Hey @greystate, sorry I hadn't followed up on this sooner. Did you get a chance to pull together some details around what you were seeing after the latest release?

Sorry @ljfio - never got around to it, and now it's vacation time, so will be a few weeks probably...

@greystate There's a new version 2.0.6 which I think fixes a number of issues with the URL generation for multi domains / cultures. Are you able to take a look at the package again and see if it resolves your issue?

Hey @ljfio — yes, I should be able to test it over the weekend - thanks! 🙌


TENSORFLOW 1.14 STYLEAGN 2 PERFORMANCE ISSUE ON RTX 3090 MULTIPLE GPU

I am running Stylegan 2 model on 4x RTX 3090 and it is taking a long time to start up the training than as in 1x RTX 3090. Although, as training starts, it gets finished up earlier in 4x than in 1x. I am using CUDA 11.1 and TensorFlow 1.14 in both the GPUs.
Secondly, When I am using 1x RTX 2080ti, with CUDA 10.2 and TensorFlow 1.14, it is taking less amount to start the training as compared to 1x RTX 3090 with 11.1 CUDA and Tensorflow 1.14. Tentatively, it is taking 5 min in 1x RTX 2080ti, 30-35 minutes in 1x RTX 3090, and 1.5 hrs in 4x RTX 3090 to start the training for one of the dataset.
I'll be grateful if anyone can help me to resolve this issue.
I am using Ubuntu 16.04, Core™ i9-10980XE CPU, and 32 GB ram both in 2080ti and 3090 machines.

@Thunder003
Can you please share the standalone code to reproduce the issue in our environment.It helps us in localizing the issue faster. Thanks!

@ravikyram check the code here:- https://github.com/NVlabs/stylegan2

@Thunder003
Can you please share the standalone code to reproduce the issue in our environment.It helps us in localizing the issue faster. Thanks!

Are you the building TensorFlow from source against those cuda versions (10.2 and 11.1)?
If you are you using pre built pip packages then I your gpu is not being utilized for computing. Reason being that currently we ship TF (2.3) packages that support cuda 10.1.
See tested build configurations to know more.
On a side note TF 1.14 is out of the support window, you may want to try latest TF versions such as 2.3 which offers much better performance. Thanks!

@ymodak as mentioned on Stylegan 2 GitHub (https://github.com/NVlabs/stylegan2) it is compatible with TF 1.14 and 1.15 only and 1.15 is not working for CUDA 11.1. As I am using Nvidia RTX 3090 which has Ampere GPU with CUDA 11.1 so the one possible issue could be as mentioned in https://www.tensorflow.org/install/gpu, can you please confirm whether this is the main problem and if, then can you suggest any solution for it?

You should switch to TF 2.x. We no longer fix code on TF 1.x.

@Thunder003 That's correct. Your configuration  is not using gpu computing power due incompatible cuda versions. We do not provide TF binaries that support cuda 11.1 at the moment.
For this you may try building TF from source yourself.
On a side note - Current tf-nightly version supports cuda 11.0
If you are okay with unstable version (tf-nightly) you can give it a try or wait for upcoming stable TF 2.4 release.

Thanks, @ymodak for your answer. I'm trying to build from source but getting an issue:-
Could not find any cudnn.h matching version '8' in any subdirectory:
''
'include'
'include/cuda'
'include/*-linux-gnu'
'extras/CUPTI/include'
'include/cuda/CUPTI'
of:
'/lib'
'/lib/x86_64-linux-gnu'
'/usr'
'/usr/include/'
'/usr/include/cudnn.h'
'/usr/local/cuda'
'/usr/local/cuda-11.1'
'/usr/local/cuda-11.1/targets/x86_64-linux/lib'
Asking for detailed CUDA configuration...
I have checked that CUDNN has properly installed on /usr/include/cudnn.h path. Following this , I have copy-pasted a cudnn.h file to /usr/local/cuda/ and libcudnn*  CUDNN installation file to /usr/local/cuda.  Can you please tell me a solution for it.
I am building TF 1.14 with CUDA 11.1 & CUDNN 8.0.4

Note that code might also need to change to support newer versions of CUDA.

Oh, I have the same problem.
I have one RTX 3090 with CUDA version of 11.1 on Windows 10. Conda was used to install the cudatoolkit which provides CUDA 10.1 and cudnn 7.6, and I have tensorflow 1.14 installed. Tensorflow recognized my RTX 3090 well, but it spent a long time to begin or finish (I had to go to sleep ...) the training process.
My question is if I build the tensorflow1.14 (yes, I need this old version) from source combines with CUDA 11.1 and cudnn 7.6, can I use the RTX 3090 well. Thanks to all of you.

@mihaimaruseac, yes, it might need to be changed. To get assured I'm trying to build from source, but got stuck in another problem( As mentioned in the quote). Can you take a look at that? Or if you think it's off-topic then I can raise another issue for this.
@psycho2012 have you got any good images with TF 1.14 on RTX 3090? I'm just getting black images with RTX 3090 installed with CUDA 11.1, TF 1.14 ( This is probably a compatibility issue of TF with CUDA version). If you are getting good images with stylegan then can you tell me which version of CUDA, CUDNN, and TF are you using with RTX 3090?

Thanks, @ymodak for your answer. I'm trying to build from source but getting an issue:-
Could not find any cudnn.h matching version '8' in any subdirectory:
''
'include'
'include/cuda'
'include/*-linux-gnu'
'extras/CUPTI/include'
'include/cuda/CUPTI'
of:
'/lib'
'/lib/x86_64-linux-gnu'
'/usr'
'/usr/include/'
'/usr/include/cudnn.h'
'/usr/local/cuda'
'/usr/local/cuda-11.1'
'/usr/local/cuda-11.1/targets/x86_64-linux/lib'
Asking for detailed CUDA configuration...
I have checked that CUDNN has properly installed on /usr/include/cudnn.h path. Following this , I have copy-pasted a cudnn.h file to /usr/local/cuda/ and libcudnn* CUDNN installation file to /usr/local/cuda. Can you please tell me a solution for it.
I am building TF 1.14 with CUDA 11.1 & CUDNN 8.0.4

@Thunder003 I didn't get any good results.

@psycho2012 can you tell me the version of CUDA, CUDNN you used with TF 1.14 in RTX 3090?

@Thunder003 CUDA 11.1 and cuDNN 8.04, but I failed to run it on GPU for TF 1.14. I have tried to build it from source with TF 1.14, but failed.  According to the experiment, I think the current version of TF 1.14 can not support CUDA11.1.

@psycho2012 thanks for your answer. It seems like TF 1.14 is incompatible with CUDA 11.1. One thing that is scratching my head is the type of issue I'm getting, pls check the image. I have checked the path and files, they are proper. Are you getting stuck at the same step?

I have added more paths for Libcudnn files also, but the error persists.

@Thunder003 I just tried on Windows but also failed on the step of the configuration. Maybe TF 1.14 is not supported by CUDA 11.1.

@psycho2012 thanks for your answer. I have checked from another source also that TF 1.14 is incompatible with CUDA 11.1. and probably the error popped-up due to that only.
I'm closing the issue now.

@psycho2012 thanks for your answer. I have checked from another source also that TF 1.14 is incompatible with CUDA 11.1. and probably the error popped-up due to that only.
I'm closing the issue now.

Can I know how do you solve the problem?because i have the same trouble.

@C-SJK for start-up time you can increase the cache size. But still, you may not get a good result. I'm not getting a black screen only in the resulting image. I assumed that there is an incompatibility issue between TF 1.14 & CUDA 11.1.
I saw NGC is using TF 1.15.4 & CUDA 11.1. But with me, TF 1.15 is not able to detect the GPU

@C-SJK for start-up time you can increase the cache size. But still, you may not get a good result. I'm getting a black screen only in the resulting image. I assumed that there is an incompatibility issue between TF 1.14 & CUDA 11.1.
I saw NGC is using TF 1.15.4 & CUDA 11.1. But with me, TF 1.15 is not able to detect the GPU

NGC? I know it , but i don`t know how to use it. Do you know how to use it??

@C-SJK for start-up time you can increase the cache size. But still, you may not get a good result. I'm getting a black screen only in the resulting image. I assumed that there is an incompatibility issue between TF 1.14 & CUDA 11.1.
I saw NGC is using TF 1.15.4 & CUDA 11.1. But with me, TF 1.15 is not able to detect the GPU

NGC, I know it.
Do you know how to use it?

@psycho2012 thanks for your answer. I have checked from another source also that TF 1.14 is incompatible with CUDA 11.1. and probably the error popped-up due to that only.
I'm closing the issue now.

thanks，i get it!

Oh, I have the same problem.
I have one RTX 3090 with CUDA version of 11.1 on Windows 10. Conda was used to install the cudatoolkit which provides CUDA 10.1 and cudnn 7.6, and I have tensorflow 1.14 installed. Tensorflow recognized my RTX 3090 well, but it spent a long time to begin or finish (I had to go to sleep ...) the training process.
I wonder if I build the tensorflow1.14 (yes, I need this old version) from source combines with CUDA 11 and cudnn 8, I can use the RTX 3090 well. Thanks.

Did you manage to build tf 1.14 and maybe run stylegan2 on top of it?

as stylegan2 doesn't have an issues tracker - I overloaded the issue into this git commit
related - https://github.com/NVlabs/stylegan2/commit/23f8bed55f4b220c69cff98139a000d4c77cd558
there is a script we can run to upgrade stylegan2 to use tensorflow 2 - automagically.
tf_upgrade_v2
--intree stylegan2/
--outtree stylegan2-tf2/
--reportfile report.txt
however - we need to address the follow failed conversions
I beseech Nvidia to create an "UNSUPPORTED" tensorflow2 branch which we can all fix.
tf.contrib. tf.contrib.memory_stats.MaxBytesInUse
Using member tf.contrib in deprecated module tf.contrib. tf.contrib cannot be converted automatically.
tf.contrib. tf.contrib.opt.ScipyOptimizerInterface cannot be converted automatically. tf.contrib
tf.contrib. tf.contrib.opt.GGTOptimizer cannot be converted automatically
probably would help if someone from tensorflow could also guide support in getting this over the line. the nvidia labs don't wont to support tensorflow 2. but it seems like push comes to shove here. Unless we're holding out for a stylegan3 to drop -  fyi @tkarras


[rom-e2e] rom_e2e_alert_config

Test point name
rom_e2e_alert_config
Host side component
Unknown
OpenTitanTool infrastructure implemented
Unknown
Contact person
@alphan
Checklist
Please fill out this checklist as items are completed. Link to PRs and issues as appropriate.

[ ] Check if existing test covers most or all of this testpoint (if so, either extend said test to cover all points, or skip the next 3 checkboxes)
[ ] Device-side (C) component developed
[ ] Bazel build rules developed
[ ] Host-side component developed
[ ] HJSON test plan updated with test name (so it shows up in the dashboard)

Verify that ROM configures the alert handler correctly.

Disabled in TEST.
Read from OTP in DEV, PROD, PROD_END, and RMA. Checksum of config registers must match
the OTP value.

@jon-flatley I think this would be a good issue to work on next since it checks the alert handler config values that you handled in #14368.


No "web server" listed as instructions say to expect

In step 4 (Prepare the Firebase and Flutter CLI) it says: "In your IDE under the devices pulldown, or at the command line using flutter devices, you should now see Chrome and Web server listed."  I see Chrome and "Edge" but no "Web server".
PS C:...\friendlyeats-flutter> flutter devices
Downloading Material fonts...                                      796ms
Downloading Gradle Wrapper...                                       47ms
Downloading package sky_engine...                                  363ms
Downloading flutter_patched_sdk tools...                         1,176ms
Downloading flutter_patched_sdk_product tools...                   797ms
Downloading windows-x64 tools...                                 1,600ms
Downloading windows-x64/font-subset tools...                       387ms
2 connected devices:
Chrome (web) • chrome • web-javascript • Google Chrome 89.0.4389.114
Edge (web)   • edge   • web-javascript • Microsoft Edge 89.0.774.68

This is correct, the web-server device was hidden recently (to be used mainly for testing purposes).
For the web-server device to show up, and be usable, the flutter command needs to be called with the --show-web-server-device flag, like so:
$ flutter --show-web-server-device devices
2 connected devices:

Web Server (web) • web-server • web-javascript • Flutter Tools
Chrome (web)     • chrome     • web-javascript • Google Chrome 90.0.4430.70 beta


Additional attrubute to the upcoming sensor

Request
Is it possible to add the 'Days_until' attribute to the upcoming ('eerst_volgende') sensor?
Additional information
I would like to use it in automations.

Done

It is actually ;). I've created a pre-release which you can test.


Fixed #5848 - Map drags correctly when in disabled FieldSet

Dragging functionality was setting the eventHandler on the document object (which must've not been responding to events due to the disabled tag.
I changed it to assign the eventHandler directly to the relevant object (and interestingly enough the object specified when actually setting the mousedown (_dragStartTarget) clickhandler!)

Suggest to fix #5848


error handled at unknown error handler

express version : 4.15,
node version: 8.1.4
im currently experiencing an odd behavior within my application, I have nested routes and im defining my routes like this
const router = require('express').Router();
const m = require('../modules/index').v1;

router.route('/')
  .post(m.create)
  .get(m.list)
  .all(m.transformer);

router.route('/:id')
  .all(m.middlewareById)
  .put(m.editById)
  .delete(m.deleteById)
  .get(m.getById)
  .all(m.transformer);
module.exports = router;

Im currently developing m.create API controller, and when and error occurs that is not handled sends me a response of HTML page with error object.
<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>Error</title>
    </head>
    <body>
        <pre>[object Object]</pre>
    </body>
</html>

I want to eliminate this behavior and response with JSON only, but somehow its by passing my defined request handlers, and instead of getting handled at a middle ware that I specify, or the one at app.js
its is being handled somewhere else mysteriously, i've been express user for 3 or more years and this is the first time im facing such behavior.
has something changed in new Express version?
app.js
const express = require('express');
const path = require('path');
// const favicon = require('serve-favicon');
const logger = require('morgan');
const cookieParser = require('cookie-parser');
...

app.use('/', index);
app.use('/systemadmin', systemAdminRoutes);

// catch 404 and forward to error handler
app.use((req, res, next) => {
  const err = new Error('Not Found');
  err.status = 404;
  next(err);
});

// error handler
app.use((err, req, res) => {
  // next is the last argument in above function
  // set locals, only providing error in development
  // res.locals.message = err.message;
  // res.locals.error = req.app.get('env') === 'development' ? err : {};
  debug(err); // nothing logs here
  debug(err.message);
  debug(err.name);
  debug(err.errorCode);
  debug(err.stack);
  // render the error page
  res.status(err.status || 500);
  res.send({error: err.message}); //this never gets called
});

module.exports = app;

Maybe you ran a linter on your coderecently? Your code above you have
app.use((err, req, res) => {

But (which has always been in the case), it MUST have 4 arguments in order to work:
app.use((err, req, res, next) => {

@dougwilson this is insane !
Thanks by the way :)
It did work.


Copilot does not work on a continous basis

Hi there!
First and foremost, thanks a lot for this! copilot.el rocks!!
I downloaded and configured copilot.el under doomemacs and it runs perfectly. I can login and also enable it in any buffer. I have tried it using different langs and I'm very satisfied with the result.
However, a key difference with copilot running in other IDEs is that it provides assistance there as the user is typing in. Here, I have to M-x copilot-complete every time I want a suggestion to pop up.
I carefully followed the instructions given for doom emacs in the Installation paragraph, and I also verified that copilot-idle-delay is set to 0. I also updated my working copy of copilot.el and I'm currently running the very last changeset.
A typical view of copilot events after completing once follows (in case this helps):
[client-request] (id:6) Sun Oct 16 00:05:32 2022:
(:jsonrpc "2.0" :id 6 :method "notifyAccepted" :params
(:uuid "d9ea9773-be62-4bf2-828c-8017b2c62de5"))
[client-request] (id:7) Sun Oct 16 00:05:32 2022:
(:jsonrpc "2.0" :id 7 :method "notifyRejected" :params
(:uuids
["d9ea9773-be62-4bf2-828c-8017b2c62de5"]))
[server-reply] (id:6) Sun Oct 16 00:05:32 2022:
(:jsonrpc "2.0" :id 6 :result "OK")
[server-reply] (id:7) Sun Oct 16 00:05:32 2022:
(:jsonrpc "2.0" :id 7 :result "OK")
There is no stderr buffer so I guess this is all the information I can provide but if other is necessary I would be more than happy to provide it.
Thanks a lot!

Do you use any autosave-related plugins?
Also, please make sure copilot-mode is enabled.

Hey zerolfx! Thanks a lot for the prompt reply!
I forgot to mention that, yeap, copilot is enabled in the buffer with copilot-mode and also M-x copilot-diagnose returns Ok.
As for the first question, well, I have no option given in my init.el/config.el so that I assume that I have nothing out of extraordinary in doom emacs. Truth is that it seems that auto-save-mode is enabled by default in my buffer. However toggling it with M-x auto-save-mode does not help either and still copilot does not provide suggestions on the fly as I'm typing. I get'em only after M-x copilot-complete
I would not mind to run any tests of your interest or to provide additional information if needed ...
Thanks a lot"!

Can you check if copilot--post-command is in the buffer's post-command-hook?
Does setting copilot-enable-predicates to nil help?
The problem mostly likely comes from copilot--post-command or copilot--post-command-debounce.

copilot--post-command appears indeed in the buffer's post-command-hook.
On the other hand, setting copilot-enable-predicates to nil absolutely helps. Everything works perfectly all of a sudden.
Is setq'ing copilot-enable-predicates to nil in my config.el the only way to circumvent this? The only reason I'm asking this is to better understand what I lose by dropping the usage of copilot-enable-predicates
zeroflx, thanks a lot really!! Truly appreciated!

copilot-enable-predicates prevent Copilot from auto-completing in the following two cases:

Evil is enabled, and the current buffer is in normal mode.
The buffer is not modified. It's mainly for vanilla Emacs users to prevent Copilot from generating suggestions when navigating the code.

I guess the culprit is the second one.

Oh! I see, thanks a lot again!
That entirely closes the thread I guess

@clinaresl Would you mind pushing any latest commits that you may have for your Doom Emacs config to your repo? I can't even get this package to work in a fresh Doom Emacs config without any changes using the config code in the Doom Emacs section of this repo's README.
https://github.com/clinaresl/doom-emacs-conf
I'm about 20 hours in trying to get this to work, but I see you're on Doom Emacs and have apparently got it to work, but I can't seem to make sense of what I'm reading in this thread.

@ryankhart Sure thing Ryan!
I do not use that repo anymore as I have now a dotfiles (private) that contains the entire configuration of my arch box. However, I just pushed the latest version of my doom config to:
https://github.com/clinaresl/doom-emacs-conf
When using my conf files please be aware that they might require some extra installations from melpa (thought it might be easier just commenting those lines from init.el)
Hope this helps! copilot.el works pretty nicely on doom emacs
Cheers,

@clinaresl Thanks so much! At first glance, I seem to have done what you have done already with the Copilot config. It's helpful to know that you're not having issues with it right now because this may help me pinpoint how to reproduce the bug I've been experiencing so I can report it here on a new issue thread.
It currently works great, so long as my typing cursor is not on the inside of any surrounding symbols like (), [], {}, "", '', and ``. If it is inside one of those, about half the time, hitting  does an indent instead of copilot-accept-completion but not randomly. It seems to change and resolve itself half the time when I'm making seemingly unrelated changes to my init.el, config.el, or package.el files, not sure which.
I'm on MacOS, by the way.

Hi there Ryan, same behaviour observed in my archlinux. Close the buffer, open it again and you'll see the cursor locates in the same point it was before. Also, github copilot will provide the same suggestion then  works ... after a while it will fail again so closing the buffer again ...
This is a bug, that I think the developers are already aware of ... If not, we should open a ticket

Oh that's a relief! I thought it was just me. For things like this that have a lot of config options and moving parts, I tend to assume that I'm not doing something right even if it could be considered a lack of user fault tolerance.
I am finding another workaround that may be a little more convenient than closing and reopening the buffer. And that is pressing <esc> to exit into normal mode, l to move right by 1 character, and then <tab> to copilot-accept-completion
My theory is that this may not be getting as much attention because this might not affect other language besides Elisp as much because in Elisp, it seems that literally everthing is wrapped in parentheses. And perhaps a lot of people who are trying out this package, may already have their Emacs configs settled in the way they like it.
I'll have another search through the open issues on this repo using some of the potential new terms used in this thread, and if I don't see anything, I'll open a new issue and reference this issue.
Thanks for helping with this!

Ah found it! This seems to be the exact issue I've been having.
electric-pair and smartparens break copilot-completion-map
Once I disabled smartparens-mode it immediately allowed Copilot to work again.
I'll continue the discussion over in that issue's thread from now on.

Cool!!!
It was me at the beginning helping you and it finally happened that you helped me ! :)
Thanks a lot Ryan!


MAINT: merge _validate_bounds from optimize and qmc to _util

Follow up of #17679 where we added a bound validation to scipy.optimize. Since we already have similar code in scipy.stats.qmc, this PR merges both.

Azure failing is unrelated. Some of their services seem to be down...

What do you think about making this a private method of Bounds?

That could work if we move Bounds to _lib. Otherwise it will create dependency cycles in QMC (shgo is using QMC).
This is also why I did not use a Bounds object for the function as you had.

I don't think this is exactly the right thing for optimize. Here are related thoughts:

I'm not convinced that Bounds should move to _lib.
I think that Bounds should have these sorts of abilities.

Agreed. I can repurpose this PR for that.

So in the meantime, I've suggested changes that would leave optimize unaffected by this PR. if you'd still like to pursue it without the optimize changes, I can take another look. I'm a little hesitant to add two new files and typing for a private function in _lib that is used only by one function in _qmc, though.

Agreed, if we don't do anything for optimize then it does not make much sense.
Hence I can move this code into Bounds and revert the changes on QMC. Or I use Bounds in QMC but I need to have the import within the scale function to avoid circular imports. Is that ok? (IIRC, I read that Python will be more resilient with such cycles in the future, so might not be that of an issue.)

As discussed, closing this for now. We might revisit to add the check capabilities to Bounds itself. Thanks all 😃


Update README.md

Update wiki link and mailing list info
What type of PR is this?
Add one of the following kinds:

bug
correction
enhancement/feature
cleanup
documentation
subproject management
tests

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for reviewers:
Changelog input
 release-note

Additional documentation
This section can be blank.
docs

@wrathwolf / @hdamker I had a few days off and am catching up on a few tasks.  Should the mailing list be prefixed by the family (hd)?

@wrathwolf / @hdamker I had a few days off and am catching up on a few tasks. Should the mailing list be prefixed by the family (hd)?

@caubut-charter the mailing list is currently specific to this sub project here, and I proposed deliberately to use the old naming style for mailing list (an three-letter-abbreviation) which not necessarily need to match the name exactly.
As soon as your clarification with Home Devices QoS (about a common mailing list) and/or the name your Sub Project is done, we can do changes to adapt the mailing list and even the repository name (https://docs.github.com/en/repositories/creating-and-managing-repositories/renaming-a-repository isn't a dangerous thing).


Weird unknown issues with killing deployments under knative-eventing

Describe the bug
The reconcile loops kills the non-eventing deployments under the ns knative-eventing.
Expected behavior
Operator should not touch on the non-eventing deployments under the knative-eventing.
To Reproduce
Create the ns, knative-eventing.
create a deployment under this namespace.
Install eventing with the operator.
Kick off the reconcile loop by any means, then the non-eventing deployment is killed.
Knative release version
ALL
Additional context
Add any other context about the problem here such as proposed priority

This is resolved in 1.9.


About key_padding_mask in multihead self attention

Hi!
Thank you for your implementation!
I would like to know if there are particular reasons why https://github.com/pmixer/SASRec.pytorch/blob/master/model.py#L83 this line for key_padding_mask is commented? It seems that this mask is necessary to prevent from attending to paddings?
Thanks again,
Sincerely
Yuchen

Hi!
Thank you for your implementation!
I would like to know if there are particular reasons why https://github.com/pmixer/SASRec.pytorch/blob/master/model.py#L83 this line for key_padding_mask is commented? It seems that this mask is necessary to prevent from attending to paddings?
Thanks again,
Sincerely
Yuchen

Thx for the question, I could hardly recall the exact details in short time, well, generally:
As padding item is 0, corresponding to all 0 embeddings as initialized in https://github.com/pmixer/SASRec.pytorch/blob/master/model.py#L36, attending to 0 would not effect the output
Also, for pytorch api, there's the statement If both attn_mask and key_padding_mask are supplied, their types should match. currently, I may encountered the issue when there was the statement attn_mask and key_padding_mask can not be used at the same time when using pytorch 1.16 for implementation about 3 years ago, thus had one of them commented.
Pls feel free to uncomment the line to check how would key mask affect model training and inference.

Thanks for your prompt reply!
Oh ok I see, I will try!  After careful consideration, I think, conceptuallly, that even letting all paddings to 0 (what the code does now) will still influence the attention mechanism, since before attention softmax, the original attention score could be negative, 0 or positive. Therefore zero does not mean sth special for softmax function (should be -inf).
Thanks again!
Yuchen

attention

Thx, for attention score, yes, -inf is required as you described. Well, here I mean attending to 0 equals attending to nothing actually, I didn't mean attention score being zero in former reply. When someone used K dot Q to get attention scores, then use attention scores to do the weighted sum of V, V=0 will not cause the effect the final output theoritically.
BTW, some of the lectures by Prof. Lee may help further clarifying these details about multi-head attention, pls consider checking https://www.youtube.com/@HungyiLeeNTU/search?query=attention if you are interested.


Feature suggestion: Integrate library configuration with deployment of secrets values.

F.ex. in the case of a cosmos. The deployed library needs to know what the database is called, needs to know its endpoint and its key. The developer has to select where to store the key, the endpoint, how to pass the two between the deployment pipeline and the deployed library.
suggestion:

Add a configuration the CosmosDb item that states its parent resource group, and a default generated name and scope for getting the key and endpoint.
Add a feature to atc-dataplatform-tools that reads this same information form your local library and makes the necessary azyre calls to get the values and afterwards makes the calls to databricks secrets to set the values.

Result:
Configure your cosmos once in your library, and deploy, connect and use it directly.

This needs a lot more though. Maybe biceps can be used? I will close this issue for now. Reopen it if you have more thoughts on this.


Modernize MSVC runtime library code

This commit is in response to this issue:
https://github.com/glfw/glfw/issues/1783

Any update on this?

Is there anything I need to do to make this change more palatable @elmindreda ?

@hdf89shfdfs Sorry, my arm stopped working for a month. I like this solution a lot, except possibly that half of the logic is in a separate, new file.

@elmindreda hope you feel better.
I understand what you mean but I'm not really a fan of having all the logic inside the main CMakeLists.txt since I think it makes reading the cmake harder.
Generally in my projects I like having a generic helper module but I didn't see one that already existed and looking in your cmake modules folder they all seem to be single purpose so I thought it fit the mold.
What about having a cmake module glfw.cmake? And put helper functions/macros inside there instead?

I've created a new commit showing what a more general cmake helper module would look like.

Please let me know what you think @elmindreda

Hey @elmindreda  do you have any idea why the linux builds would be failing? I'm struggling to figure it out.

@elmindreda let me know if this change is acceptable.
I really think it helps the readability quite a lot :)
But that's an opinion. The main thing is to fix the problem.
If the new cmake module isn't acceptable I can move all of this logic into the main Cmakelists.txt

@elmindreda let me know if this change is acceptable.
I really think it helps the readability quite a lot :)
But that's an opinion. The main thing is to fix the problem.
If the new cmake module isn't acceptable I can move all of this logic into the main Cmakelists.txt

Any update on this?

I have found this PR, while having the problem, that the current "regex replace" based method does not work anymore when using modern CMAKE_MSVC_RUNTIME_LIBRARY in a top level project. I think it is a nice start, but also I see a few problems with the current implementation of this PR.

Please don't force a user to globally set CMAKE_MSVC_RUNTIME_LIBRARY by throwing a warning. I think it should be perfectly fine if a user set CMAKE_MSVC_RUNTIME_LIBRARY as target property instead of globally.
Please don't force static linking in the standalone case. The standalone case may be used to build GLFW standalone to later use find_package from another project. Therefore the user should be able to select linkage type.

I would suggest to keep the USE_MSVC_RUNTIME_LIBRARY_DLL option for all CMake versions, but for CMake 3.15+, instead of changing the CMAKE_C_FLAGS the CMAKE_MSVC_RUNTIME_LIBRARY property can be set on the glfw target.

@moritz-h Agreed, that seems to be the better solution. I've also added a warning for when the USE_MSVC_RUNTIME_LIBRARY_DLL option has no effect.


Fix Replicate llm response to handle iterator / multiple outputs

One of our users noticed a bug when calling streaming models. This is because those models return an iterator. So, I've updated the Replicate _call code to join together the output. The other advantage of this fix is that if you requested multiple outputs you would get them all – previously I was just returning output[0].
I also adjusted the demo docs to use dolly, because we're featuring that model right now and it's always hot, so people won't have to wait for the model to boot up.
The error that this fixes:
> llm = Replicate(model=“replicate/flan-t5-xl:eec2f71c986dfa3b7a5d842d22e1130550f015720966bec48beaae059b19ef4c”)
>  llm(“hello”)
> Traceback (most recent call last):
  File "/Users/charlieholtz/workspace/dev/python/main.py", line 15, in <module>
    print(llm(prompt))
  File "/opt/homebrew/lib/python3.10/site-packages/langchain/llms/base.py", line 246, in __call__
    return self.generate([prompt], stop=stop).generations[0][0].text
  File "/opt/homebrew/lib/python3.10/site-packages/langchain/llms/base.py", line 140, in generate
    raise e
  File "/opt/homebrew/lib/python3.10/site-packages/langchain/llms/base.py", line 137, in generate
    output = self._generate(prompts, stop=stop)
  File "/opt/homebrew/lib/python3.10/site-packages/langchain/llms/base.py", line 324, in _generate
    text = self._call(prompt, stop=stop)
  File "/opt/homebrew/lib/python3.10/site-packages/langchain/llms/replicate.py", line 108, in _call
    return outputs[0]
TypeError: 'generator' object is not subscriptable

This happens to any model on replicate. I try dolly, vicuna, same problem
langchain/llms/replicate.py", line 108, in _call
return outputs[0]
TypeError: 'generator' object is not subscriptable


PR Testing Trigger

Please Ignore. Testing PR Triggers

Codecov Report

Merging #131 into Dev will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              Dev     #131   +/-   ##
=======================================
  Coverage   90.67%   90.67%
=======================================
  Files          42       42
  Lines        3496     3496
  Branches       13       13
=======================================
  Hits         3170     3170
  Misses        313      313
  Partials       13       13

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 f594863...b4ef653. Read the comment docs.


Dose the latest version support transaction message or any kind of transaction functions?

Dose the latest version support transaction message or any kind of transaction functions?

Actually, it's on the way.


Failes to start if ED journals are absent

The Observatory fails to start if ED journal files are located at non-standard path

Will be fixed in next release.
Workarounds for now:

Create the path (it can be empty) then set the journal path to where your journals really are in the settings
Hand edit %localappdata%\ObservatoryCore\{version}\ObservatoryCore_Url_{location hash}\user.config with the location of your journals in the JournalFolder value element.


Allow user to choose which links they wish to share

User must be able to customize which social media pages they would like to share
For example, a user can choose to share either casual social media pages like Instagram or Twitter, or more professional alternatives such as LinkedIn.
There could also just simply be an option to allow them to manually toggle what they want to share.

This issue should also implement the front-end functionality for toggling all professional and casual accounts at a time using the buttons at the top of the home page. The toggles will need to be visually toggled, as well as the ids for each row stored in the toggled array as is already done in the main.js file.


ROX-26720: Reduce read lock scope

Description
Reduces the scope the read lock is held by the lazy registry to reduce contention.
Routines waiting for the write lock were not given priority over routines waiting for the read lock as expected.  Instead what was observed was routines were occasionally 'alternating' such that after the write lock was released the read lock was obtained even when other routines were waiting for the write lock.
The .Metadata call behind the read lock was taking ~2 seconds, the read/write lock alternating would eventually trigger the non-release build mutex timeout because the routines waiting for the write lock would have to wait for multiple Metadata calls before they were allowed to enter the write protected block.  Over time this would have self corrected, but this change should reduce that contention.
User-facing documentation

[x] CHANGELOG is updated OR update is not needed
[x] documentation PR is created and is linked above OR is not needed

Testing and quality

[x] the change is production ready: the change is GA or otherwise the functionality is gated by a feature flag
[x] CI results are inspected

Automated testing
Existing tests cover the use case
How I validated my change
CI

/test ocp-4-17-nongroovy-e2e-tests


[DS-6655][fix] remove zkmonitor

delete zkmonitor ui

Codecov Report

Merging #6785 (6e83474) into dev (1184441) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev    #6785      +/-   ##
============================================
- Coverage     41.82%   41.82%   -0.01%
  Complexity     3616     3616
============================================
  Files           641      641
  Lines         25895    25895
  Branches       2795     2795
============================================
- Hits          10831    10830       -1
- Misses        14084    14086       +2
+ Partials        980      979       -1

Impacted Files
Coverage Δ

...org/apache/dolphinscheduler/alert/AlertServer.java
55.00% <0.00%> (-5.00%)
:arrow_down:

...er/master/dispatch/host/assign/RandomSelector.java
83.33% <0.00%> (+5.55%)
:arrow_up:

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 1184441...6e83474. Read the comment docs.


release(wallet mobile): v5.2.0

QA Summary
Changes

[x] Bug fixes
[x] Tx Review

Regression & others

[ ] Test iOS
[ ] Test Android
[ ] Copy check
[ ] Metrics check

5.2.0-rc.1 (iOS nightly: 🟡 620, Android nightly: 🟡 733)

[x] #3754
[x] #3753
[x] #3752
[x] #3750
[x] #3747
[x] #3749
[x] #3748
[x] #3746
[x] #3745
[x] #3739
[x] #3737
[x] #3734
[x] #3733
[x] #3732
[x] #3730
[x] #3729
[x] #3728
[x] #3724
[x] #3723
[x] #3725
[x] #3722
[x] #3720
[x] #3719
[x] #3717
[x] #3715
[x] #3714
[x] #3713
[x] #3712
[x] #3711
[x] #3707
[x] #3685
[x] #3626
[x] #3697
[x] #3696
[x] #3695
[x] #3693
[x] #3694
[x] #3692
[x] #3691
[x] #3663
[x] #3690
[x] #3689
[x] #3688
[x] #3664
[x] #3687
[x] #3686
[x] #3658
[x] #3683
[x] #3672
[x] #3643

@crypto-titan can you update the password in the pipeline https://github.com/Emurgo/yoroi/actions/runs/12181703570/job/33978958353#step:17:131

@rahulnr7 I brought 5.0.2 unreleased changes into 5.2.0


Added gradle configuration to override assets

Description
Allows overriding the assets folder as we did with the resources folder
Reviewers
If you've been tagged for review, please "Start a review" with the GitHub GUI.

Code review: @miankhalid @1zaman

Current coverage is 18.89% (diff: 100%)

Merging #888 into master will decrease coverage by 0.07%

@@             master       #888   diff @@
==========================================
  Files           470        470
  Lines         19978      19992    +14
  Methods           0          0
  Messages          0          0
  Branches       2922       2926     +4
==========================================
- Hits           3789       3777    -12
- Misses        15738      15766    +28
+ Partials        451        449     -2

Powered by Codecov. Last update b8d9bd8...5b239f4

@1zaman Added documentation. Merge if happy.


Realtime subdomain output

Add disowned inotifywait in reconftw.sh to output subdomain realtime
POC:
docker run -it --entrypoint="" six2dez/reconftw:main bash -c "./reconftw.sh -d testfire.net -s & apt install -y inotify-tools;  inotifywait -q -m -e create '/root/Tools/reconftw/Recon/testfire.net/.tmp/' | while read -r i1 i2 filename; do cat /root/Tools/reconftw/Recon/testfire.net/.tmp/\$filename; done"

I can try to come up with a pull request if this feature looks good

I like the idea, but note that reconFTW already uses notify tool to send you messages via chat apps, it also prints the results and the status of the steps on the screen, anyway, if you want to add the feature to the dev branch, I'd be happy to give it a try and add it to main if I find it useful :) Thanks!


OwnedSliceSpec::inner_as_slice_inner should be unsafe

https://github.com/lo48576/validated-slice/blob/ae44f252b6964bccf9731aa6bebdc25e1d383469/src/lib.rs#L191-L192
This method allows user to convert a slice type into another slice type, but they are not guaranteed to be compatible.
It can be called with inputs which fails to validate, so I think it should be marked unsafe.
Consider struct Len8Str(str); and struct Len8String([u8; 8]);.
To validate [u8; 8] content by <Len8Str as SliceSpec>::validate(), the validated-slice crate could convert &[u8; 8] into &str without checking validity as utf-8 string.
Forcing pre-validation in inner_as_slice_inner() is not an option, because it would make the program panic rather than returning error for invalid input.
For example, if fn inner_as_slice_inner(v: &[u8; 8]) -> &str is implemented as std::str::from_utf8(&v[..]).unwrap(), <Len8String as TryFrom<[u8; 8]>>::try_from([0xff; 8]) would panic rather than returning error, because of the .unwrap().

This won't cause UB when &<OwnedSliceSpec::SliceSpec as SliceSpec>::Inner can represent any possible value of OwnedSliceSpec::Inner.
Using usual pairs such as str-String and [u8]-Vec<u8> would be safe for the current version.

Ah... no, making inner_as_slice_inner unsafe is not enough.
The real problem is that Slice::Inner could be non-subset of Owned::Inner, and that validate() is expecting Slice::Inner rather than common subset of inner types.
To fix this problem, signature for validate() should also be changed.


implementing function for frequency count

PR Checklist:

[x] My submission is formatted according to the guidelines in the contributing guide
[x] My addition is on refer on the language README.md file
[x] My addition does not have a spelling problem
[x] My submission has a proper and user-friendly description of the algorithm
[x] My submission has the time complexity of the algorithm
[x] My submission has sample input-output of the program (NOT FOR PYTHON)

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[x] New algorithm
[ ] Optimization in previous algorithms
[ ] Code style update
[ ] Refactor
[ ] Documentation
[ ] Other, please describe:

Briefly describe the changes in this PR

Other information:

code for frequency count of the given number in an array


Delete user

Hello,
I use the tools for an alliance and would like to know if it would be possible to have a cron that removes the characters who are no longer in the alliance?

:star2: Feature request accepted
Great feature request! I really like your idea.
Please, keep in mind that new features need some time to be implemented. New requests are always prioritized by their cost/benefit for all users.
:information_source: Feel free to ask for the current route map in our dev-chat: #Slack

Auto-generated response


Expense - Unable to save report title for workspace expense

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4-36.0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
Action Performed:

Go to staging.new.expensify.com
Go to any workspace
Create a manual request
Go to expense report
Click Title row
Change to a new title and save it

Expected Result:
The new report title is saved
Actual Result:
The new report title is not saved. This issue is only reproducible for workspace expense
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/09d43e83-eaa0-4764-bf10-43bf545e87b1
View all open jobs on GitHub

We think that this bug might be related to #wave5
CC @dylanexpensify

I was able to reproduce this on web. After digging through the code, it looks like it was most recently touched in this PR https://github.com/Expensify/App/pull/34483.

Checking.

@thienlnam The backend is not letting the report being renamed. It throws the following:
You can't rename the report of a free plan

We can do one of the following:

Allow rename from the backend for the free plan users.
Disable ONLY the title field for free plan users.
Disable ALL report fields for the free plan users.

Let me know what we want to do here.

You shouldn't be able to set report fields for free workspaces - this should be a control / collect policy only. How are you setting report fields for free plan users?

Will take this over since I have context - we don't need to block on this since it's behind a beta and you shouldn't be able to set report fields on a free plan

For free workspaces, we're always sending a title report field attached to the policy. That is why people from free workspaces are able to see the option to edit the title.

By default, there might be the text_title for free workspaces. If that's the case, I will update the BE so that it does not return for free workspaces

Yep, that's exactly what is the issue.

Ah I see, yeah I'll handle this via the BE then

Working on it this week, moving to a weekly since this is still behind beta

This is handled by https://github.com/Expensify/App/pull/36044


add analytics

actually, would rather not have analytics, would rather have twitter as a source for that


Making class code only visible for instructor.

Please make the class code only visible to teacher/instructor
In a class card in class code is accessible by everyone who join the class, please make it visible for only class instructor

In the server, I can add an extra key as a role for the instructor and students, then on the front-end, We can easily validate that one, and as per that, we can render.

Hello, @Rishi-121 are you still working on this issue ?
Please create a pull request if you need any help, or if you are not interested then we can assign this issues to someone else.
This issue will be reassigned to you, whenever you create a pull request regarding this issue.

Hello, @Rishi-121 are you still working on this issue ?
Please create a pull request if you need any help, or if you are not interested then we can assign this issues to someone else.
This issue will be reassigned to you, whenever you create a pull request regarding this issue.

Hey, Can I work on this?

Yes, I am assigning this you @deepthiteki.


some kind of address don´t open

One is dlink ip cam
http://admin@xxxxxxx.dyndns.org:8129/image.jpg
rtsp://admin:12345@xxxxxxx.dyndns.org:554/H264?ch=2-4&subtype=1
thise ones i´ve tested and is working ok but dont open

please try the 2.0.3 version


Add status badges to the readme

This pull request adds GHA workflow and codecov.io status badge to the readme.
It also removes codecov token from the workflow - this token is not needed anymore for integration now that this repo is public.

I also pushed a change so code quality workflow now also triggers for pull requests and also runs on a daily basis as part of a cron trigger.

@martin-majlis-s1 code coverage step is failing, not sure why - https://github.com/scalyr/dataset-go/actions/runs/4665731080/jobs/8259472292?pr=3

Codecov Report

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

@@           Coverage Diff           @@
##             main       #3   +/-   ##
=======================================
  Coverage        ?   60.93%
=======================================
  Files           ?        9
  Lines           ?      901
  Branches        ?        0
=======================================
  Hits            ?      549
  Misses          ?      300
  Partials        ?       52

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Per our discussion on Slack - I think it's fine to run it on push to any branch, but only run it for prs against main branch (which is the most common workflow).
I don't think it should run twice though. We use similar triggers in other repos and it only runs once.


macos/grpc_basictests_opt failing a lot lately

https://source.cloud.google.com/results/invocations/573d390a-7504-40a6-9315-1a5e61986e1f/targets
Both run_tests_objc_macos_opt_native and run_tests_csharp_macos_opt_native seem to be failing a lot lately, each for what looks like different reasons.

Obj-C tests should be fixed. Still working on a fix for C#
cc @jtattermusch

C# tests should be fixed by #15138. Waiting for green builds on master before closing this issue.

Both dbg and opt have had 2 green builds each, closing issue.


FantasticFiasco MVVM Dialogs and Stepper issue

Hi!
I always use FantasticFiasco's mvvm dialog (https://github.com/FantasticFiasco/mvvm-dialogs) for my apps, but now I got an issue when I tried to open a new dialog window from a viewmodel of a Stepper's step.
The strangest thing is that the error occurs only if the stepper's layout is vertical.
I attached a sample project, please take a look.
MaterialDesignStepperIssue.zip

Hi!
I don't known what the exact problem is but it seems to be caused by an ItemsControl. Only the vertical Stepper uses one in its template. It seems that the view of the step is not registered by FantasticFiasco's mvvm dialog.
I changed your code to let it be more like the stepper demo. The dialog is working now and can't tell why. Lets have a look to the changes:

StepViewModel does not inherit from Step, because it should only be the content of a step.
MainViewModel adds a step this way: new Step() { Header = "Step", Content = new StepViewModel() }
The XAML of MainWindow adds a DataTemplate to its resources, to define StepView as the view for StepViewModel.
StepView do not need to set a DataContext, because this will be done automatically by WPF via the data template.

MaterialDesignStepperIssue_fix.zip


Fixes URL polyfill check for MS Edge.

Fixes #6927

/botio test

Windows bot seemed to have crashed or was restarted.
/botio-windows test


Cqm parsers integration

This PR uses cqm-parsers for measure loading and switched to the new measure model.
It also unifies the api vs api_v1 measure loading code.
It also adds some fixture loading and creation stuff.
Submitter:

[x] This pull request describes why these changes were made.
[x] This PR is into the correct branch.
[x] JIRA ticket for this PR: https://jira.mitre.org/browse/BONNIE-1915
[x] JIRA ticket links to this PR
[x] Code diff has been done and been reviewed (it does not contain: additional white space, not applicable code changes, debug statements, etc.)
[x] If UI changes have been made, google WAVE plug-in has been executed to ensure no 508 issues were introduced.
[x] Tests are included and test edge cases
[x] Tests have been run locally and pass (remember to update Gemfile when applicable)
[x] Test fixtures updated and documented as necessary ( see internal wiki )
[x] Code coverage has not gone down and all code touched or added is covered.

In rare situations, this may not be possible or applicable to a PR. In those situations:

Note why this could not be done or is not applicable here: The rake tasks need to be rebuilt to use the new model
Add TODOs in the code noting that it requires a test
Add a JIRA task to add the test and link it here: https://jira.mitre.org/browse/BONNIE-1888

[x] Automated regression test(s) pass N/A

Reviewer 1:
Name: @losborne

[x] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[x] The tests appropriately test the new code, including edge cases
[x] You have tried to break the code

Reviewer 2:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

I know some tests are skipped for work that will be done in the future. If this hasn't been done already, would it be helpful add references to these skipped test to the description of those relevant tasks? That way the person completing the task knows to go back and update those specific tests.


fix: remove 'git add ./css' from precommit stage

closes #97 (for real doe 🎉)

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


made the Chatbot

Use your own Gemini api key for the chatbot to work.
Resolved Issue  #460

there is a conflict resolve it