Make browserify recognize its own bundles

Summary

It's a pain in the neck to use a browserify bundle in a subsequent bundling operation.
Wouldn't it be nice if you could just require() a browserify bundle in another bundle?
Pragma: prepend on output, detect on input
Demo

I think this is pretty light-weight and useful, but it seems like the kind of thing I should get some thumbs up on before going ahead with.
This involves changes to browserify and several dependencies, so the branch this points to is just a placeholder. The real commits are here:

https://github.com/substack/node-browserify/compare/9.0.3...jmm:pragma
https://github.com/substack/browser-pack/compare/4.0.1...jmm:pragma
https://github.com/substack/module-deps/compare/3.7.2...jmm:pragma

Tests pass except for one on browserify that I think will be remedied easily enough.
My anecdotal testing suggests this would have a negligible impact on performance, but I welcome suggestions on how it should be tested.
Details
Currently it's kind of a pain in the neck to bundle a browserify bundle A in a new browserify bundle B, e.g.:
browserify('./entry.js')

entry.js
// bundle-a is a browserify bundle
require('./bundle-a');

If you just do that it's highly prone to failure. There are at least 2 failure modes:

Bundle operation B errors out because it attempts to resolve paths in require() calls in bundle A and doesn't find them. It's unnecessary and undesirable to even do this because bundle A already contains all of the files referenced by require() calls that it needs to contain.
Bundle operation B resolves paths from require() calls in bundle A to files that don't have anything to do with anything and includes them in the bundle even though they're not referenced by anything.

I've seen confusion about how to consume a bundle in a subsequent bundling operation a number of times here and on stackoverflow1. Generally it can be cured by:

Setting noParse for bundle A in the bundle B operation; or
Running the standalone bundle through derequire; or
Minifying the bundle

But each of those approaches requires that you and / or consumers of the module keep track of which modules are browserify bundles and / or modify them or do extra work to use them, instead of being able to just require them like any other module.
And to boot, noParse currently suffers from path mis-matching issues that are affecting a lot of things in browserify right now (e.g. it's sensitive to including / omitting file extension for one thing).
And a lot of users don't even know about doing those things. Neither the noParse documentation nor the notes about derequire even mention that use case. Also, standalone bundles used to be processed through derequire on creation and that was discontinued. I don't think it's obvious, especially to users used to the former behavior, that it won't work to:
just require() a browserify bundle in another bundle.
Wouldn't it be nice if you could do that, without breaking anything else? I think there might be a way. This PR is a proof of concept of a method for doing that.
In a nutshell, when bundling:

On output, prepend a pragma kind of thing, similar to the ECMAScript use strict directive. The current format I'm testing is: ({"compiler": "browserify", "version": "1.23.456"});
On input check the beginning of each bundled file for the pragma. When found, noParse the file. Probably omit transforms as well (but that could be an option).

I'm guessing that the pragma format(s) I'm testing wouldnt wouldn't break one bundle in a million in the wild, but if that doesn't seem safe enough then a (bit) longer, more arbitrary value could be added, like b1c2247fb27f6c8ffb66871b1cfbd30e, which I expect would reduce the likelihood of breakage to one in a trillion.
These are the ideas I've iterated through for the format of the pragma (chronological order):

"BROWSERIFIED"; (or with ')
<EMAIL_ADDRESS>(or with ')
<EMAIL_ADDRESS>(or with ')
'{"compiler": "browserify", "version": "1.23.456"}';
({"compiler": "browserify", "version": "1.23.456"}); (current)
More compact possible alternative: ({"browserify": "1.23.456"});

Another option could be to apply special handling by file extension(s), like .bify.js, .browserify.js, or .browserified.js, but I favor the pragma approach if it's one or the other.
Thoughts?
1.

http://stackoverflow.com/q/28266540/1034448
http://stackoverflow.com/q/28078425/1034448
https://github.com/substack/node-browserify/issues/374

This seems pretty good and can avoid the huge slowness of derequire.  Pragma-wise, I like the simple compact strings but that decision should be up to you since you're taking the initiative here. Great work!

Great, thanks for the consideration!

Pragma-wise, I like the simple compact strings but that decision should be up to you since you're taking the initiative here.

Ok, thanks. I'm leaning a bit towards one of the later formats like (JSON object);, because it leaves the door open to most readily embed more data in these things in a structured way in the future without changing the basic format, if that were to become desirable. (And to my mind the byte length it adds to the bundle is not unreasonable.) But I'm not married to any of them and I'm open to suggestion about what would be the wisest format.
Thanks for your feedback. For the string versions do you have an opinion on with / without version #? I just thought it might be a nice piece of metadata for debugging, but it's probably not essential. I'll mull this over more, and I'd love to hear comments from anyone else who has an opinion too. It would obviously be ideal to get it "right" the first time. @thlorenz @defunctzombie @hughsk @domenic @calvinmetcalf @feross @zertosh @dominictarr do you have an opinion?

If there are no other concerns from anyone else, just publish browserify-pragma to npm and I'll merge the changes into browser-pack and module-deps.

For now I've published<EMAIL_ADDRESS>to npm, utilizing the pragma format listed as "current" above. Needless to say I need to write some tests for this package.

Sounds interesting. Just as an FYI, I recently made some improvements to derequire that cut it's run time by more than 50% (see https://github.com/calvinmetcalf/derequire/pull/23). There are still more improvements that can be made there.

@zertosh That's good to know. I wonder how desirable / necessary it is to avoid running transforms on an existing bundle.

@zertosh Do you have any idea how much more the performance could be improved? I'd have to double check, but I think I remember seeing an issue comment describing browserify as being slower by a factor of 10 due to derequire. If that's at all accurate then even a 50%+ faster derequire could still result in a significant slowdown in browserify.

@jmm: The test suite runs in ~780ms. I just quickly switched it from esprima-fb to acorn and it ran in ~720ms. So that's another easy win (I'll put in a PR for that later). I have to see what it is exactly that esrefactor is doing, maybe that can be improved.
Sigh, I dream of a world where build tools passed around ASTs instead of raw source. I have high hopes for estree, then maybe that'll happen.

@jmm @calvinmetcalf, I managed to really improve derequire, there is a little bit more I can squeeze out of it, but I'll do that tomorrow (see https://github.com/calvinmetcalf/derequire/pull/26). The tests went from ~780ms to ~300ms, and derequiring react-with-addons.js went from 7.2s to 0.4s - yes a 95% drop.

@jmm https://github.com/calvinmetcalf/derequire/pull/26 is "done" if you want to give it a try. The final perf metrics are: To derequire react-with-addon.js for two tokens it took ~9387ms before, and now ~242ms.
@substack After https://github.com/calvinmetcalf/derequire/pull/26 gets merged, I think it might be worth exploring bringing back derequire into browserify. It would be awesome if you could tell browser-pack what function name to use for require. This way, you could implement derequire as a plugin that ran after label on a per row basis so it can cache the results when doing incremental rebuilds.

confirmed, with @zertosh's changes the perf test went from 42127ms (aka 42 secconds) to 742ms

@zertosh

I managed to really improve derequire...yes a 95% drop.

Wow! Nice work.

This diff dramatically increases the speed of derequire by: (1) eliminating an unnecessary ast parse
...
Sigh, I dream of a world where build tools passed around ASTs instead of raw source. I have high hopes for estree, then maybe that'll happen.
...
This way, you could implement derequire as a plugin that ran after label on a per row basis so it can cache the results when doing incremental rebuilds.

To your point, if derequire is integrated directly with browserify, could you conceivably have detective return an AST and have derequire consume it, saving an additional 1 small parse per row or 1 big parse per bundle?

@jmm  we could go one farther actually and since detective is finding all of the requires detective could also change the function name as it finds it and then in the latter step when browserify wraps in in the function (require, exports, module){} it could use the modified name for require.  This would likely be the most performant version possible but would have some issues with people not wanting their code mangled like that.

@calvinmetcalf Yeah, I considered that too. I haven't thought it all the way through yet, but I figured if derequire performance is now acceptable it might be a cleaner separation of concerns to leave detective doing what it does (but return the AST) and let derequire do its mangling thing. As everyone has noted, either way it requires integration with browser-pack (which I don't think will be hard to implement).
Are there any good use cases for people to care about this and not want the mangling? browser-unpack'ing a bundle to do something with it is one I guess. So either way, whether detective or derequire does mangling maybe there should be an option to enable / disable it. In that case maybe the pragma proposal this PR is about would still make sense so that browserify will recognize its own unmangled bundles.

@jmm @calvinmetcalf

could you conceivably have detective return an AST and have derequire consume it

Yeah, this would be a small change in derequire. In detective, we'd have to make sure to pass ranges as true, and have it return the AST to module-deps, which then returns it to browserify.

Are there any good use cases for people to care about this and not want the mangling?

Oh yeah, as you noted, browser-unpack is one - so bundle-collapser too. Which makes this all really tricky because that's a really important tool. I'm not sure what's the right path here.

@zertosh

and have it return the AST to module-deps, which then returns it to browserify

Yeah, I was thinking that if this were implemented in the plugin fashion you suggested, module-deps could just populate row.ast.

@zertosh

Oh yeah, as you noted, browser-unpack is one - so bundle-collapser too. Which makes this all really tricky because that's a really important tool. I'm not sure what's the right path here.

How feasible would it be to bless something, _dereq_ or whatever it needs to be, as a reserved function name that gets special treatment in browserify like require does and make the necessary tools aware of it so that they're both handled the same?

How feasible would it be to bless something, dereq or whatever it needs to be, as a reserved function name that gets special treatment in browserify like require does and make the necessary tools aware of it so that they're both handled the same?

ok so the issue there is that the output of browserify isn't the only place derequrie is used, ember uses it BEFORE it gets sent to browserify because they locally define a function called require that screws up browserifying.
more generally
originally derequire modified the ast and then used that to recreate the code.  This lead to people complaining that it was messing up their white space and inappropriately adding/remove semicolons, so I switched to modifying the code as a string instead of using the AST to recreate the code.  This is in line with what browserify does where it creates AST to find the requires but it does not use that to create the final output , so solution might be to pass the code and ast to derequire and then return modified code.

@jmm: I included an undocumented browserify plugin that runs after the pack step. When you use bundle-collapser as a plugin, it runs after label (so before pack). So it's fine to run both as plugins. It does add time to rebuilds - but not that much. Do you think the added complexity of having "blessed" functions is worth it?

@zertosh

I included an undocumented browserify plugin that runs after the pack step....

Ok, so if / when derequire is integrated with browserify that'd probably be the way.

Do you think the added complexity of having "blessed" functions is worth it?

I was just wondering if that might be a feasible way to run derequire when browserifying and still be able to use tools like browser-unpack / bundle-collapser later (by making them treat _dereq_() like require()). As @calvinmetcalf pointed out it's not as simple as being able to give that kind of special treatment to _dereq_. I guess browserify could designate it's own replacement (something other than _dereq_) as special and related tools could handle that specially.
What are your opinions @zertosh @calvinmetcalf on these issues:

Should users get to care about what's in the output, specifically whether it contains the original require() calls or has them replaced with _dereq_() or something else? For example, to later run bundle-collapser, or browser-unpack to roundtrip a bundle back to the original source files.

To that point, if derequire is integrated with browserify do you see it being mandatory or optional? (And enabled / disabled by default?)

I'm trying to figure out if integrating derequire with browserify would consistently solve the use case of re-bundling a bundle. Was that the main reason it was integrated previously, or was it for the sake of AMD loaders?

so previously when derequrie was included in browserify it was only run with the standalone option was passed, the idea being that standalone creates a self contained bundle you can use anywhere and thus changing the requires makes sense

@calvinmetcalf Right, understood. My understanding is that derequire has at least 3 use cases / results in connection with browserify:

Feed derequire's output to browserify as input (as in your ember example).

Feed browserify's output to it to accomodate AMD loaders.

Feed browserify's output to it to prevent browserify from parsing require() calls when the bundle becomes input to a new bundle.

Was # 3 the / a reason for incorporating derequire into browserify before, or was it just a side effect of incorporating it to achieve # 2?
 My
understanding is that derequire has at least 3 use cases / results in
connection with browserify:

Feed derequire's output to browserify as input (as in your ember
example).

Feed browserify's output to it to accomodate AMD loaders.

Feed browserify's output to it to prevent browserify from parsing
require() calls when the bundle becomes input to a new bundle.

Was # 3 the / a reason for incorporating derequire into browserify before,
or was it just a side effect of incorporating it to achieve # 2?
I just checked and browser-unpack will unpack a standalone bundle, so that
brings me back to the questions in my previous post.
—
Reply to this email directly or view it on GitHub
https://github.com/substack/node-browserify/pull/1151#issuecomment-78315732
.

No. 3 is my only use.

To that point, if derequire is integrated with browserify do you see it being mandatory or optional?

I'm cool with it being optional - could just be a boolean called "derequire", if you need more options, then use the plugin. I'm not sure what the use case would be, but just as an FYI, it's perfectly ok to use derequire on a bundle with exports (so non-standalone).  If you could give me your feedback on the questions here when you get the chance that'd help me wrap my head around the situation. When I opened this PR I didn't think derequire was even an option for solving the rebundling use case I was trying to address, so I'm trying to figure out if with the performance improvements it's the best way to accomplish that, or if potentially re-integrating derequire into browserify and solving that use case are separate issues.

@zertosh

No. 3 is my only use.

Ok, thanks for the feedback

I'm not sure what the use case would be, but just as an FYI, it's perfectly ok to use derequire on a bundle with exports (so non-standalone). Regardless of the name given in externalRequireName, that variable won't get renamed since it's a global and not created in any scope.

Ok, thanks. I wasn't worried about that, but I actually have a PR on browser-pack (#51) proposing to allow users to export a global require() from standalone bundles. So that'd be a use case for using derequire on a bundle that exports require().

I'm cool with it being optional - could just be a boolean called "derequire", if you need more options, then use the plugin.

I hope that @substack and / or some other people who are more familiar with the previous go around will have a chance at some point to comment on the idea of re-integrating derequire into browserify. If the outcome is that it either doesn't happen or it's optional then I think my proposal still makes sense (either on all bundles or just those where derequire is not enabled) to enable browserify to consume its own bundles without choking on them either way (with or without derequire). If derequire is re-integrated non-optionally, then I think it would obviate the need for this PR.

@jmm Sounds good. Thank you for taking charge of all this! I hope I didn't derail your work by coming out of nowhere with the derequire improvements.

Thanks @zertosh. I think that's a definite possibility in the sense that my proposal may become obsolete, but I certainly can't fault you for awesome work improving derequire. I admit it will be a bit of a bummer if my effort on this was for naught, but if that happens it's because a better solution emerged. I also realize in hindsight that I should've checked in on what's been happening with derequire before working on a new solution :) I failed to adhere to one of the prime virtues of programming: laziness.

so my vote was that if we wanted to include derequire, just have it enabled when standalone is enabled, having a --externalizable (or better name) which also does it could work too.

@calvinmetcalf Ok, thanks for clarifying. I think it would be ideal to have the option to get back out what you put in (meaning your original source after going through whatever transforms / plugins you configure), but I'm not sure if it's compelling to provide that.

Ok so to summarize:

When you do a standalone build, you automatically get your bundle derequire'd.

When you don't do a standalone build, you can enable derequire'ing via some flag (e.g. externalizable or whatever idc).

To keep it logically consistent: If you do a standalone build, and you explicitly pass externalizable as false, it should cancel out the automatic derequire from No.1.

Next steps:

browserify PR that:

Adds derequire as dependency.
Handles standalone/externalizable and adding derquire to the pipeline.

derequire PR that:

Adds a test to the plugin :disappointed: (i gotz lazy)
Documents the plugin.

Bump watchify's browserify version when this comes out - pretty please.

Sound good @jmm @calvinmetcalf ?

@zertosh @calvinmetcalf FYI, at this point in time it's not my place to merge something of this scope. Wanted to let you know before you work on a PR and related efforts in case you'd rather get a thumbs up from @substack first.
FWIW, I don't love externalizable. Is there any reason to not just use --derequire / opts.derequire or --dereq / opts.dereq?

@jmm Makes sense to wait for @substack. As for the name, I don't feel strongly towards any one in particular. derequire, dereq, externalizable, zertoshIsAwesome, whatever. You guys decide.

externalizable was not intended as a name  I'd actually want in browserify, I'd be against --derequrie just because

my tool might get replaced
other changes might make sense to be applied
we'd want the process to be named in terms of the outcome not the process

so --bundle could work but that might be confusing as that word is used in other ways in the JavaScript api --pacakge could work but has other conitations as well.
We could invent a word for the idea of a group of browserified modules that may be required as a group and then the modules within requireable. How about we call that a crate and thus have the --crate and -c option.

@calvinmetcalf

my tool might get replaced

I considered that, but if that were the only concern I don't think it would be a problem, because "derequire" also serves as a generic description of what's being done.

we'd want the process to be named in terms of the outcome not the process

I'm all for an abstraction that doesn't say too much about the implementation details.

other changes might make sense to be applied
...
We could invent a word for the idea of a group of browserified modules that may be required as a group and then the modules within requireable.

Ok, so help me understand here what concepts you see this option encapsulating. standalone already somewhat encapsulates the concept of "a self contained bundle you can use anywhere". A derequire option would further that "use anywhere" part. Can you think of any other conceivable changes that wouldn't go under one of those? Just wondering if there are any concrete examples we can consider right now.

We could invent a word for the idea of a group of browserified modules that may be required as a group and then the modules within requireable.

When you say "group of browserified modules" do you mean a bundle (by which I mean the output of browserify().bundle() of course), or multiple bundles?

browserify already has a plugin setup, it doesn't really make that much sense to add a special option just for this plugin even if it makes it faster.  One of the great things about browserify is that it is powerful with a simple core, but it didn't get this way by accedent it was hard work and a lot if it having to be the asshole library that says no to your feature even though it's incredibly useful and makes you go outside do it as a transform/plugin.  Sure browserify could just be all touchy feally like webpack and solve every single problems in core, but then you'd have to maintain that all in core.
Browserify creates a few different types of bundles:
by default browserify creates an application, it doesn't go out of it's wait to add external hooks to start it as it's assumed it will self start
the standalone option is for creating libraries that work in as many environments as possible, this is why it uses a umd to allow it to be used with AMD and adds itself to the global if possible, it would make sense for these to be derequired
the missing case we were trying to solve here is wanting groups of libraries that an be shared between apps, one of the ways to make this easier would be to use derequire, it also might make sense for this type of bundle to more explicitly declare what libraries it provides, etc.

@calvinmetcalf

browserify already has a plugin setup, it doesn't really make that much sense to add a special option just for this plugin even if it makes it faster.

I thought that the option was about making it easier rather than faster, but maybe you mean "faster" in terms of developer setup time rather than bundling speed.
Forgive me if I've misunderstood anything, but I think you're saying that users should have to explicitly invoke derequire when bundling if they want it?, e.g.:
browserify({standalone: 'whatever'})
  .plugin(require('derequire/plugin'))
  .bundle()

Browserify creates a few different types of bundles:

Right, understood.

the missing case we were trying to solve here is wanting groups of libraries that an be shared between apps

The case I was trying to solve when I opened the PR is perhaps more limited: allow browserify to consume it's own bundles.

it also might make sense for this type of bundle to more explicitly declare what libraries it provides, etc.

Do you have anything specific in mind, or it's just a general idea at this point?

Forgive me if I've misunderstood anything, but I think you're saying that users should have to explicitly invoke derequire when bundling if they want it?, e.g.:

the case of standalone I thought it might make sense to have it do derequire then, having a --derequire option would be way out of scope I think

Do you have anything specific in mind, or it's just a general idea at this point?

nope, and if all it was really needed was derequiring then just let people use the plugin if they need it

the case of standalone I thought it might make sense to have it do derequire then, having a --derequire option would be way out of scope I think

Ok, I think I understand your meaning now. It boils down to whether the user should be able to opt-out of derequire for standalone bundles, and if they should you think the option name should be an abstraction that doesn't reference derequire (the library or the operation) specifically. I'm still not too sure what other operations might be part of this abstraction though, and therefore what would be a suitable name.

nope, and if all it was really needed was derequiring then just let people use the plugin if they need it

My understanding is that that's the only concrete thing that can be considered right now.

then for now we probably don't need to add a command that just uses derequire, we might want to consider the question of adding derequire back to standalone a seperate issue

then for now we probably don't need to add a command that just uses derequire, we might want to consider the question of adding derequire back to standalone a seperate issue

I think you and @zertosh both have in mind to add it back to standalone by default (i.e. no option required), the question is then can the user opt-out and how (e.g. what's the option called).

I think you and @zertosh both have in mind to add it back to standalone by default (i.e. no option required), the question is then can the user opt-out and how (e.g. what's the option called).

That's what I want... but that's yours (@jmm) and @calvinmetcalf's call. (Remember, derequire is @calvinmetcalf's - I just made some fixes, that's all)

when it comes down to it it's really @substack and whoever makes the pull's call

If derequire is cheap now, I can't imagine a case where you'd want a bundle but would also want to opt-out of derequiring in the standalone step. If there is a good use case for wanting to opt-out of derequire, we should probably keep it out of core altogether since it's easy enough to browserify main.js --standalone Main | derequire > bundle.js on your own. However, if there is no longer a reason why --standalone wouldn't work with derequire, we can just add it back to core but not expose a configuration option. Does derequire have an affect on source maps?

that s a good question, probably not since it explicitly won't rename identifiers to a name with a different length

wrt sourcemaps: Like @calvinmetcalf said, because the identifiers are the same length, everything continues to be in the same position. However, because the identifier gets a new name, things like hovering over the require in the Chrome DevTools is broken:

^ that doesn't work after a derequire - but everything else does.
wrt opt-out: Although derequiring is now cheap, it's not free. Not being able to opt-out is going to add more friction to the write-refresh-test development cycle. IMHO, it should be turned on by default with standalone, but there should be a way to opt-out. Kinda like detectGlobals - most people want it on, but sometimes, you need to turn it off.

@substack

If derequire is cheap now, I can't imagine a case where you'd want a bundle but would also want to opt-out of derequiring in the standalone step.

I think the only concrete ideas that came up in this issue (other than what @zertosh just mentioned) were 1) running bundle collapser later or 2) browser-unpack'ing to get back to source files ("source" meaning after any transforms that were configured). # 2 was my idea and just hypothetical -- I haven't done it and I don't know if anyone does it.

I think it's worth just making this something we always do whenever --standalone is enabled.  Even if we don't, I disagree that it is sufficient to tell people to do it as a separate step as people will forget derequire which will hurt users.  At the very least, the default needs to be to derequire whenever --standalone is enabled.

I've just arrived at this issue by being terribly confused why my --standalone-built browserify libraries could not be required() into another project without throwing weird "cannot find module" errors. As a result, I'm definitely in the "include it by default into --standalone" camp, from a brief reading of the issues involved.
Has support for derequire-ing shipped in any form yet?

Another +1 for "include by default in standalone"; this is very unintuitive behavior. I would expect a standalone module to be, in fact, standalone; i.e., to be used as-is in any of the UMD-supported delivery mechanisms.

@calvinmetcalf re: your comment, what makes it so terrible? Does it do regex matching or something? Any idea how many widely used AMD loaders there are? (Or CJS bundlers for that matter?)
The slickest thing, of course, would be to use scope tracking  on input to ignore require() calls in scopes that define a require, but...performance. As an experiment, I made an adaptation of Detective that does that. It may not yield the best performance, but for convenience I did it using Babel, since it provides scope tracking for "free" (as in effort, not performance). I don't know that doing it any other way would yield acceptable performance either.

So the issue with dojo was it tried to load via http every require call in the package even though they were local ones. I think you're the issue was just that dojo wasn't written with interoperability with other loaders in mind so it assumed all require calls were for it.
Derequire btw works exactly like you suggested looking for require calls by scope and the current version isn't too bad performance wise.

@calvinmetcalf

So the issue with dojo was[...]

Ok, I see, thanks for clarifying. So that'd be the same deal with any AMD loader, right? Unless there are some that scan for them with scope tracking.

I think you're the issue was just that dojo wasn't written with interoperability with other loaders in mind so it assumed all require calls were for it.

Yeah, I mean, essentially the same deal here right?

Derequire btw works exactly like you suggested looking for require calls by scope and the current version isn't too bad performance wise.

Yeah, I know from this thread that the performance was way improved. I haven't tested it myself, but from what was discussed here it sounds like that's no longer a blocker. I just meant that it would be slickest if the require()s could be detected with scope awareness on input because then it wouldn't be necessary to mangle them on output or add anything to the output.
From what's been discussed here it sounds to me like restoring Derequire by default on standalone bundles would be a reasonable thing to try in a major. I've also wondered if it makes sense to pursue this pragma idea further because it wouldn't be necessary to mangle the require() calls (but maybe no one cares) and I suspect it would have lower performance overhead, but to be effective for interop between Browserify and other stuff would require other module loaders / bundlers to adopt it as well (so something generic like "standalone-bundle";). That's why I was wondering how many widely used ones there are. That wouldn't help with versions of whatever lib from before they became aware of the pragma though. And I don't know if the performance difference between that and where Derequire is now would be meaningful even if it is lower.

The only thing that will realistically work across all the package managers we want to support is to either restore derequire or use remove-require as shown in substack/browser-pack#53. Right now I would say this is probably browserify's most urgent issue.

Any 2016-like updates on this issue?

@alundiak
Just use derequire cli as demonstrated in the docs:
browserify main.js --standalone Foo | derequire > bundle.js

Would the two failure modes described in the OP be fixed by "simply" (quotes because I have no idea how simple it would be) fixing https://github.com/substack/node-detective/issues/22?

This PR makes detective ignore require() calls inside browserified bundles: https://github.com/browserify/detective/pull/79
It doesn't do full scope analysis because that would be really slow; instead it only checks for the browserify pattern where the inner require is a parameter to the module factory function, and skips walking functions with a require parameter entirely.
Would be cool to get some thoughts on that from folks here!


Logger does not use process_host.display_name when setting hostname in the logs

The logger does not use process_host.display_name when setting hostname in the logs. Instead it uses Socket.gethostname via a call to NewRelic::Agent::Hostname.get.
I believe it is a bug. (In another issue, a New Relic developer assumes the feature already acts this way when she says  "Alternatively, we have the ability to set the app name (entity.name in the default attributes) and hostname by configuration in either the newrelic.yml file or by environment variable"). https://github.com/newrelic/newrelic-ruby-agent/issues/1141
You can see the offending code here:
https://github.com/newrelic/newrelic-ruby-agent/blob/74737a46a141d1d7e251c06f8db157743b02f3d8/lib/new_relic/agent/logging.rb#L51
I think the fix is to just replace with:
Agent.config[:'process_host.display_name']
I can create a PR if that would be helpful.
Thanks!

Hi @flivni! Thanks for calling attention to this and providing a suggested fix. process_host.display_name isn’t being applied to log events. This is a change we’d like to make!
The features for log events need to be consistent across all New Relic’s agents. Since this is a new feature, we will need to bring this back to our team before making updates as there are a few other changes that need to take place and processes to go through. We will follow up with updates.
Thanks again for reporting this!

Thanks @hannahramadan. I look forward to the updates.


[MLS Spec change] Add new new_proposal_member SenderType (#716)

Link to the exact changes
https://github.com/mlswg/mls-protocol/pull/716
Description of the changes

Add new new_proposal_member SenderType and rename new_member to new_commit_member.
This restores the External Proposal Add functionality which was present in the protocol for some years but clarifies how the authorization and signing takes place in this case.

@beltram is working on this


Migrating Seattle To Terraform Deployment

Tracking task to manage child tasks

[x] https://github.com/civiform/civiform/issues/4684
[x] https://github.com/civiform/civiform/issues/4683
[x] https://github.com/civiform/civiform/issues/4676
[x] https://github.com/civiform/civiform/issues/4675
[x] Migrate Seattle staging to TF Deploy System
[x] Create new Seattle prod environment to TF Deploy System
[ ] Migrate Seattle prod to new environment

Change failed, rolled back to original instance. Investigating cause of failure before trying again.

Cause is auth related environment variable config issue.


Lose metadata when the process oom

Yesterday, I came across a problem that when the gitbucket process(tomcat) oom,  some metadata such as user info, repositories is lose!!!
It is such a big problem, but i have no idea what happened.
There are some screenshots of error log, i hope it can help.

Did you restart Tomcat after OOM?

yes.

Close all questions. If you have any questions about GitBucket, please send them to the gitter room instead of issue according to the Guideline for Issues.


changed phase from discovery to discover

This is good to go, so i'm gonna merge it, i've removed the tabs from the home page for now but we can always bring them back really easily,


Switch hosting from DigitalOcean to Hetzner

DigitalOcean bad money to performance ratio :cry:

finished epically today in just 5 hours :sunglasses: (but certbot still pain, took like half of the time :cry:)


Protractor 5.4.2 does not work with Chrome 74+ combine with webdriver-manager 12.1.4, mime-types 2.1.24, and mime-db 1.40.0 (ubuntu:16.04  node:6.x)

Since google-chrome-stable released 74.0.3729.157-1, my Protractor test script fails for a set of test cases.  At first, I can get it work by installation of 73.0.3683.103-1, this was when webdriver-manager was in 12.1.1.  However, after the webdriver-manager upgraded to 12.1.4, neither 74.0.3729.157-1 or 73.0.3683.103-1.
This is running on docker of ubuntu 16.04, the docker is running on ubuntu 4.4.0-34-generic #53
Node Version: 6.x
Protractor Version: 5.4.2
Angular Version: 1.5.8
Browser(s): Chrome
To try to get it work, I forced installation of webdriver-manager 12.1.1 by command:
RUN npm install -g<EMAIL_ADDRESS>However, 12.1.4 was installed (please see the log below):
Step 11 : RUN npm install -g<EMAIL_ADDRESS>---> Running in<PHONE_NUMBER>e3 /usr/bin/webdriver-manager -> /usr/lib/node_modules/webdriver-manager/bin/webdriver-manager /usr/lib    --<EMAIL_ADDRESS> +--<EMAIL_ADDRESS> +--<EMAIL_ADDRESS>Question 1. How can I install webdriver-manager 12.1.1 on my docker?
Question 2. How can I get my test cases work again?
The failed case is to create a new record by

Click a button or use a url link to open a web form so that I can enter data of the record.
Fill the web form and click a button to save.
I haven't find anything special in angular code with this failed form. But the server code involve more error handling, At one time, when I make sure the server doesn't give any error or timeout, the passed, but two days later, the same failure occurs again.

And these test cases still pass in an old chrome 73.0.3683.103-1<EMAIL_ADDRESS>environment.  So I believe if I can install<EMAIL_ADDRESS>it will work.

reference case https://github.com/angular/protractor/issues/5225

Ok, this is what happened, Last Friday, May 10, I found a work around by clearing cache to avoid an harmless error in my application.  I tested for two days to make sure it worked.  But Tuesday, May 14,  google-chrome-stable moved to 74.0.3729.157-1 and my work around no longer work.
Fortunately, I created a base docker which including every 3rd party packages except things with
webdriver-manager update,
so I changed it to
sudo webdriver-manager update --versions.chrome 74.0.3729.6
This at least make my work around work.
But I still need fix that allow me not to use the work around, which will cause the test miss any caching errors and also prevent testing in case we do need to use cache.
Version combination that work for me with the "clear cache" work around:
Chrome: 74.0.3729.131-1
Protractor: 5.4.2
webdriver-manager: 12.1.4
node: 6.17
chromedriver: 74.0.3729.6
Version combination that does not work for me:
Chrome: 74.0.3729.157-1
Protractor: 5.4.2
webdriver-manager: 12.1.4
node: 6.17
chromedriver: seems to be 75.0.3770.8
Version combination that work for me
(but no longer work because I can no longer install webdriver-manager: 12.1.1 ):
Chrome: 73.0.3683.103-1
Protractor: 5.4.2
webdriver-manager: 12.1.1
node: 6.17
chromedriver: 73.0.3683.68


Create node build action

plus let's follow the convention that we try to use for all branch names
feature/*
chore/*
fix/*


feat: updates mods table access

What
feat: updates mods table access

:tada: This PR is included in version 1.39.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.39.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Any sample about how to use it to parse CSS?

Hi,
Any sample about how to use it to parse CSS?
Im the creator of ezored (https://ezored.com) and i want make a mobile library in C++ that parse CSS files (but more simple CSS style) and back to mobile platform objects. Example:
File: sample.css

button1 {
    font: "Roboto", 12
    textColor: "#FF0000"
    borderColor: "#000000"
}

And on iOS and Android i will do:
libX.parse("sample.css")
libX.applyButtonStyle(myButton, "button1")

// internally it will do something like this
// myButton.font = getFontProperty["font"]
// myButton.textColor = getColorProperty["textColor"]
// ...

There is a sample to parse CSS with key/value?
Can you help me understand how to parse using library?
Thanks.

We currently do not have an implementation of the CSS grammar as example, and there is no short answer as to how this can be achieved. The latest CSS syntax is defined here and should presumably be used as a guide and reference for a CSS parser.
Some of the example grammars in include/tao/pegtl/contrib/ and src/example/pegtl might be useful for getting started, however the CSS grammar description uses a separate tokenisation and parsing phases and therefore requires some adaptation to the PEG formalism where both are usually combined.
As you can see for example with the Lua 5.3 grammar, the result of combining the two phases can be quite large, though in this case the large apparent size is also due to the incorporation of the operator precedence rules, and I would expect CSS to be less of a hassle.
What the PEGTL does nicely is separate syntactical grammar from semantical actions, wherefore the first step towards a CSS parser is the actual grammar, ignoring anything that needs to be done during parsing, which can and should be added later (even though it might again require some tweaks to the grammar).
Implementing a non-trivial grammar can be a bit of a grind, we can help you by answering any questions here, and please let us know how thing progress.

I'll close this issue for now, but feel free to ask any further questions here...


Problem when viewing tiles

I import raster file to geopackage but i can see the tiles on android. However if i use geopackage viewer, the raster tile visible correctly. I have check the zoom level, and the coverage of the image on my emulator, all went well. No error at debugging console. here is the geopackage

Sorry, it was my mistake

I'm sorry it a little bit messy. My question is i can open it both from geopackage viewer and android map but qgis. Just want to know if it problem with qgis or i did a mistake when importing the raster?

It appears to work fine in Android.

And if I enable tile scaling on the tile layer, you can see the level 15 tiles without zooming as far in.

I did not try it on qgis but didn't see any obvious errors from visible database inspection.
If your problem is that qgis will not display a valid GeoPackage, you could submit them a bug.

I was able to get the rasters to display in QGIS 3.2 on my Mac.  First, find the Browser panel, which for me is located in the upper left corner of the window by default.  If not, click the View menu > Panels > Browser to display it.  I right-clicked the GeoPackage node in the Browser panel, then New Connection..., then browse to and select demo-2.gpkg.  I zoomed the QGIS canvas to the area where your tiles are.  I expanded the demo-2.gpkg node in the Browser panel and double-clicked the PETADASAR node to add the layer Layers panel and to the canvas.
All that being said, before I actually knew where your tiles were located, I simply tried to drag-and-drop demo-2.gpkg into the QGIS Layers panel, then right-click the layer node and Zoom to Layer.  That action just about melted my laptop because QGIS (and GDAL under the hood) seem to have a hard time with your GeoPackage.  Then QGIS finally zoomed out to the bounds of the whole world.  When I modified the PETADASAR row in the gpkg_contents such that the min_x, min_y, max_x, max_y column values matched those in the gpkg_tile_matrix_set table, I was able to drag-and-drop the GeoPackage file to the QGIS Layers panel and Zoom to Layer without trouble.
So, as @bosborn said, I believe the issue is a combination of QGIS/GDAL and the values I referenced above in your gpkg_contents table.


chore(deps): update jest monorepo to v25.2.3

This PR contains the following updates:

Package
Type
Update
Change

jest (source)
devDependencies
patch
25.2.2 -> 25.2.3

jest-cli (source)
devDependencies
patch
25.2.2 -> 25.2.3

Release Notes

facebook/jest
v25.2.3
Compare Source
Fixes

[*] Verify all packages are properly downleveled for older versions of TypeScript (#9715)

Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about these updates again.

[ ] If you want to rebase/retry this PR, check this box

Available now for Enterprise: Renovate Pro with real-time webhook handling and priority job queue.

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

v3.2.6
GitHub release

Your semantic-release bot :package::rocket:


按Enter的时候老是会自动跳行 没有办法对齐

VSCode Version: Code - Insiders 1.17.0-insider (f7962f0682a76516df51de4856f8ccc5d8ad578a, 2017-09-20T05:24:33.599Z)
OS Version: Windows_NT x64 10.0.14393
Extensions:

Extension
Author (truncated)
Version

html-snippets
abu
0.1.0

vscode-caniuse
aka
0.5.3

stylus
Ala
0.0.4

project-manager
ale
0.21.1

html-class-suggestions
And
1.0.7

alignment
ann
0.3.0

px2rem
art
0.0.1

npm-intellisense
chr
1.3.0

path-intellisense
chr
1.4.2

bracket-pair-colorizer
Coe
0.10.9

ivue
dai
0.1.0

vscode-eslint
dba
1.3.2

githistory
don
0.2.3

Vue2
duc
0.1.3

gitlens
eam
5.1.0

vscode-html-css
ecm
0.1.8

vscode-npm-script
eg2
0.2.1

vscode-element-helper
Ele
0.4.2

auto-close-tag
for
0.5.0

auto-rename-tag
for
0.0.14

terminal
for
0.0.10

vue-snippets
hol
0.1.5

search-node-modules
jas
1.2.0

docthis
joe
0.4.8

vue
liu
0.1.5

HTMLHint
mka
0.4.0

vscode-filesize
mkx
1.0.0

debugger-for-chrome
msj
3.3.0

vuejs-extension-pack
mub
0.1.9

vetur
oct
0.9.9

vuehelper
oys
0.1.0

material-icon-theme
PKi
2.2.1

vscode-icons
rob
7.13.0

vue-vscode-snippets
sdr
1.0.2

git-autoconfig
shy
0.0.1

language-stylus
sys
1.7.3

vscode-jss-snippets
vis
0.2.2

JavaScriptSnippets
xab
1.4.1

(2 theme extensions excluded)

Steps to Reproduce:
1.在编辑HTML标签时按enter会自动换行 需要ctrl+z取消然后标签才会对齐
2.

Reproduces without extensions: Yes/No

Please share screenshots or gif or video

As shown in the diagram, if I press enter when I edit the code, I
automatically run to the next line to align with the parent element

2017-09-23 2:11 GMT+08:00 Ramya Rao<EMAIL_ADDRESS>
Please share screenshots or gif or video
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/34825#issuecomment-331521243,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Acfznn1kc0alKe5r_TNswd7BVT9VUmiqks5sk_hEgaJpZM4Pgi0i
.

@dengmowen I dont see any screenshots or diagrams

As shown in the diagram, if I press enter when I edit the code, I automatically run to the next line to align with the parent element

look github,I edited the question
2017-09-23 3:27 GMT+08:00 Ramya Rao<EMAIL_ADDRESS>
@dengmowen https://github.com/dengmowen I dont see any screenshots or
diagrams
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/34825#issuecomment-331538787,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AcfznhwC1x1032hcI-J_lqhmPeuhwQMwks5slAoNgaJpZM4Pgi0i
.

Can you run code-insiders --disable-extensions and see if you still see the issue?
This is to ensure that none of your installed extensions are causing this issue

Ramya Rao<EMAIL_ADDRESS>周六05:02写道：

Can you run code-insiders --disable-extensions and see if you still see
the issue?
This is to ensure that none of your installed extensions are causing this
issue
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/34825#issuecomment-331559679,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Acfznv24sMZCmSGRIy44-3D7MdmteQvjks5slCBwgaJpZM4Pgi0i
.

OK I try  thanks

https://github.com/vuejs/vetur/issues/448
https://github.com/vuejs/vetur/pull/450
Either turn off formatOnType or wait until I publish next version of Vetur, which should be soon.


Support Redis Cluster

This PR implements support for Redis Clusters, resolves: #660

Will be resolved by #1040


Comment on: Folder

FolderClass.md

Enter your comment here:
In 4D.Folder files or 4D.Folder folder

>  fk recursive
1
The collection contains files or folders of the specified folder and its subfolders

The collection contains files  (not folders)  for 4D.Folder files
The collection contains folders  (not files)  for 4D.Folder folders
but maybe it's due to doc generation and a common description of fk recursive constant at only one place

Yes we use a single description for fk recursive constant but it come from the previous system; in this case we can have a more accurate description, we'll fix this thanks;


Playing sound freezes/slows down my game

This is probably not a bug with soloud-rs but with my lack of understanding of how sound works and muilthreading. Does anyone have guidance on what I need to learn to fix this?

Hi
Soloud plays sound on a different thread so it doesn’t block the main thread. The examples here explicitly block the main thread so the application waits for the sound to finish before terminating. If you’re using something like the examples here, this would block your main thread.
In a long running app like a game or a gui, you shouldn’t need to block the main thread.
You can also delegate launching sound in a threadpool to get better control at launching and stopping sound using messages/channels or something.

     let mut sl = Soloud::default()?;
     let mut wav = audio::Wav::default();

    wav.load(&std::path::Path::new("sample.wav"))?;

    sl.play(&wav); // calls to play are non-blocking, so we put the thread to sleep
    while sl.voice_count() > 0 {
        std::thread::sleep(std::time::Duration::from_millis(100));
    }

I'm confused as what you mean about that the examples "explicitly block the main thread" since the comment says its non-blocking unless I'm misunderstanding something. As in the while loop and the std::thread::sleep() are blocking . If I run s1.play() without the while loop or sleep, there will be no sound

Yes the while and std::thread::sleep blocks the main thread since not doing so in a terminal application would just terminate the app even before playing any sound (which happens in a different thread, so that part is non-blocking).
I’m currently away for a pc, but here is an example from the soloud repo:
https://github.com/jarikomppa/soloud/blob/master/demos/env/main.cpp

If I call .play() nothing happens unless I sleep or block.... so I have to spawn a thread in order for it to play and not freeze?
   thread::spawn(|| {
     let mut sl = Soloud::default()?;
     let mut wav = audio::Wav::default();

    wav.load(&std::path::Path::new("sample.wav"))?;

    sl.play(&wav); // calls to play are non-blocking, so we put the thread to sleep
    while sl.voice_count() > 0 {
        std::thread::sleep(std::time::Duration::from_millis(100));
    }
    });

So I have to wrap inside a thread::spawn?

No need. For example this is a long-living application:
use soloud::*;

fn main() {
    let sl = Soloud::default().unwrap();

    let mut wav = audio::Wav::default();
    wav.load("music.mp3").unwrap();
    wav.set_looping(true);
    sl.play(&wav);

    loop { // Imagine this is a game loop where events are handled
        std::thread::sleep(std::time::Duration::from_millis(30));
    }
}

Of course you can use std::thread::spawn to get finer control if for example you have multiple sound sources which you want to control.


Opacity on icons

Hello, as I was browsing on the icon sets iconify proposes, I crossed upon logos with an opacity option, like ph:question-duotone. It seems like currently we can't change opacity on the Icon component (I am using svelte iconify). Is it going to be added in the future ? I have cases where such option could be very interesting and I don't want to use a raw svg for that...
Thanks in advance for any response !

Sorry, I have no plans to add that.
Opacity is just one of properties that can be changed. For some icons it is as simple as changing fill-opacity="0.3" string, for some icons that use masks it requires parsing mask and changing grayscale color. Also there are options for stroke width, animation duration and option to completely remove animation. All of that are part of same parser.
Adding parser to component would increase its size by a lot. Considering that icon component is bundled and sent to visitors, increasing size for feature that will be rarely used is not a good idea.


[Doc][Module Name] Documentation bug or improvement

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
dinky plugin should be added specific version
I recently used dolphin scheduler with dinky v0.7.3, but failed. log below:
[LOG-PATH]: /opt/dolphinscheduler/logs/20230720/10280823947712_10-53-59.log, [HOST]:  Host{address='dolphinscheduler-worker-0.dolphinscheduler-worker-headless:1234', ip='dolphinscheduler-worker-0.dolphinscheduler-worker-headless', port=1234}
...
[INFO] 2023-07-20 14:48:59.012 +0800 - access url: http://<IP_ADDRESS>:8888/openapi/getJobInstance?id=null
[INFO] 2023-07-20 14:48:59.018 +0800 - dinky task succeed with results: {"datas":null,"code":1,"msg":"Failed to convert value of type 'java.lang.String' to required type 'java.lang.Integer'; nested exception is java.lang.NumberFormatException: For input string: \"null\"","time":"2023-07-20 14:48:59"}
...

I  found dinky has changed its api uri
curl http://<IP_ADDRESS>:8888/openapi/getJobInstanceByTaskId?id=5
uri be changed from /openapi/getJobInstance to /openapi/getJobInstanceByTaskId
Documentation Links
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

why the jobInstanceId  is null

Why the jobInstanceId is null
I use mysql as datasource in dinky not flink ,I don't know if it's related @CallMeKingsley97

Anyway, jobInstanceId should't be "null". Could you post more logs ?
By the way, i found nothing from dinky(v0.7.3) about "/openapi/getJobInstanceByTaskId" .😂

I found /openapi/getJobInstanceByTaskId in dinky :

But I notice /openapi/getJobInstance and /openapi/getJobInstanceByTaskId both exist.
I submit task in dinky and log is below , it doesn't contain JobId

Could you submit a new task for using different sql?,  and watch the return data, take a closer look at the fields called "jobInstanceId".
After you submit a task, the program will try to get jobInstanceInfo.

Are there any questions? @wangjc0216

I use flink as dinky param , and I will get expected value(different from dinky-mysql):

I think there should be something wrong in dinky plugin.  I am not familiar about Java and Dolphin Scheduler, so I may spend some times to find out  what is the real reason.


[WIP] matrix_includes.json: Add Fedora 37, and drop Fedora 34.

See https://ask.fedoraproject.org/t/fedora-37-released-fedora-35-reaches-end-of-life-in-december-22/28538.
--
I am seeing the error below on Fedora 37, when I executed. Any idea how to fix?
https://github.com/junaruga/rpm-py-installer/actions/runs/3507961554/jobs/5876036926#step:10:360
E               install.CmdError: CMD: [/work/.tox/py310-cov/bin/python setup.py -q build], Return Code: [1] at [/tmp/tmpifmn6s4t-rpm-py-installer/rpm-rpm-4.18.0-release/python] Stderr: [/work/.tox/py310-cov/lib64/python3.10/site-packages/coverage/inorout.py:472: CoverageWarning: --include is ignored because --source is set (include-ignored)
E                 self.warn("--include is ignored because --source is set", slug="include-ignored")
E               In file included from header-py.c:1:
E               rpmsystem-py.h:9:10: fatal error: Python.h: No such file or directory
E                   9 | #include <Python.h>
E                     |          ^~~~~~~~~~
E               compilation terminated.
E               error: command '/usr/bin/gcc' failed with exit code 1
E               ]

You have to switch to py311, or install python3.10-devel.

Ah I see! Thanks for finding the issue.


How to set up the correct combination of shift_div and frame_count?

Thanks for sharing this great resources.  I am trying to play with different frame rates for TSM.
I noticed there are 3 important attributes here:  frame_count,  num_segments and shift_div.
For example,  if I reduced frame_count from 8 to 4 (which means the video is split into 4 segments this time, so the equivalent frame rate is reduced),  should I also adjust "shift_div" and "num_segments"?   Am I right to say "shift_div" should always be equal or smaller than "frame_count"?

I don't know if you are still looking for an answer. I was also looking at the code to get an answer for this question, and I end up to this part of code which I believe answers the question.
    @staticmethod
    def shift(x, n_segment, fold_div=3, inplace=False):
        nt, c, h, w = x.size()
        n_batch = nt // n_segment
        x = x.view(n_batch, n_segment, c, h, w)

        fold = c // fold_div
        if inplace:
            # Due to some out of order error when performing parallel computing.
            # May need to write a CUDA kernel.
            raise NotImplementedError
            # out = InplaceShift.apply(x, fold)
        else:
            out = torch.zeros_like(x)
            out[:, :-1, :fold] = x[:, 1:, :fold]  # shift left
            out[:, 1:, fold: 2 * fold] = x[:, :-1, fold: 2 * fold]  # shift right
            out[:, :, 2 * fold:] = x[:, :, 2 * fold:]  # not shift

        return out.view(nt, c, h, w)

fold_div is equal to shift_div. If it is set to 3, then 2 / 3 of the channels will be shifted. If set to 8, then 2 / 8. I am studying this code as well, so please take this with a grain of salt 😄


Reapp new Error

Running reapp new projectname causes the following error:

Desktop :> reapp new myapp
Creating new reapp folder for: myapp...
Running git clone --depth=1 https://github.com/reapp/starter-default /Users/lyu/Desktop/myapp...
Running git init...
Inserting your name...
Running npm install...
Error
{ [Error: stderr maxBuffer exceeded.] cmd: '/bin/sh -c npm install' }

It still creates the folder and whatnot but I was not able to run the default reapp home page until I updated the reapp-kit version from 1.2.0 to 1.2.15

Resolved with new version of reapp.
Do:
npm uninstall -g reapp
npm install -g reapp
reapp new test-reapp
cd test-reapp
reapp run


Add access request logging to Nuxt

Problem

We have no server request access logging set up for Nuxt, which makes investigating frontend incidents very difficult.
Description

Add access request logging using a middleware. This one-log-per-request middleware should match what Django provides out of the box: timestamps, request path etc.
Additional context

This is a hot-fix before we implement a full-fledged Nuxt server logging solution.

A potentially low-effort approach to this would be adding Nginx as a reverse proxy to the frontend and copying the request log configuration we use in the API: https://github.com/WordPress/openverse/blob/b2e9989a8574ba1c5b36e1ea509683f632008a39/api/nginx.conf.template#L10-L24
This would probably be easier than adding a new Nuxt module or writing one ourselves, especially if we want to minimise the amount of special configuration needed to parse the log lines: https://github.com/WordPress/openverse-infrastructure/blob/b2e9989a8574ba1c5b36e1ea509683f632008a39/next/modules/concrete/api/main.tf#L210-L214. It may even be possible to copy the API's nginx configuration entirely, with few changes other than to remove location definitions that do not apply to the Nuxt service. We would, however, need to add a new nginx target to frontend/Dockerfile and publish the image to GHCR. Then the ECS configuration can also be copied from the API, with changes to adapt the relevant aspects to the frontend.
JSON logs are automatically parsed by Logs Insights, and we have plenty of examples of querying Nginx logs from the API when we've debugged API incidents.
If there's a trivial or simple way to just add a Nuxt module to accomplish this that is easy to configure request logging (with timing) for, then Nginx could be more effort. However, getting request timing is critical to the usefulness of the logs from a debugging perspective, so if that is not included in the Nuxt logging module and is hard to add for some reason, then Nginx would be better.


Inspect.BitString.escape no longer exists

https://github.com/elixir-lang/elixir/commit/0b0ab9f8ef420ea07878e3156386ddad10bb3ea8#diff-6fd830f891dc229cc43bbeb19b95acd9L119 broke poison@master because it removed Inspect.BitString.escape:
==> poison
Compiling 4 files (.ex)
warning: function Inspect.BitString.escape/2 is undefined or private
  lib/poison/parser.ex:20

Fixed in v4.0.0.


server is not a function

/Users/dzakh/.vscode/extensions/chenglou92.rescript-vscode-1.29.10/server/out/cli.js:20
            return server(false);
                   ^

TypeError: server is not a function
    at /Users/dzakh/.vscode/extensions/chenglou92.rescript-vscode-1.29.10/server/out/cli.js:20:20
    at Object.<anonymous> (/Users/dzakh/.vscode/extensions/chenglou92.rescript-vscode-1.29.10/server/out/cli.js:33:3)
    at Module._compile (node:internal/modules/cjs/loader:1316:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1371:10)
    at Module.load (node:internal/modules/cjs/loader:1171:32)
    at Module._load (node:internal/modules/cjs/loader:1012:12)
    at f._load (node:electron/js2c/asar_bundle:2:13377)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:96:12)
    at node:internal/main/run_main_module:23:47

Node.js v18.15.0
[Error - 6:26:45 PM] Server initialization failed.
  Message: Pending response rejected since connection got disposed
  Code: -32097
[Info  - 6:26:45 PM] Connection to server got closed. Server will restart.
true
[Error - 6:26:45 PM] ReScript Language Server client: couldn't create connection to server.
  Message: Pending response rejected since connection got disposed
  Code: -32097
/Users/dzakh/.vscode/extensions/chenglou92.rescript-vscode-1.29.10/server/out/cli.js:20
            return server(false);

I'll try to reproduce, but there's nothing special in the project

Seems this recent commit broke it: https://github.com/rescript-lang/rescript-vscode/commit/e54c067fdadd59c81dfe7660ee5f295c610345f6
Wish that was something tests could catch. Anyway, @aspeddro looks like we need another solution for the version stuff.

Works after revert.

Wish that was something tests could catch

Probably a single e2e test spawning the process like here https://github.com/rescript-lang/rescript-compiler/blob/master/jscomp/build_tests/cli_help/input.js would prevent it.


:sparkles: protect branch

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Client side query generation is not working when custom requiremens are supplied

We are generating queries by default supporting only level 2.
Adding manually level 3 or removing level works but changes will be overridden silently later making it hard to work with client side generated content.
We need to come up with the best way to do it.
AWS AppSync generates client-side queries - we can check how they doing it

Actually I have more into that.
If we add more crud capabilities entire client side generation will basically stop making sense as there will be so many variation of the queries that they will need to be expressed by hand.
I think that we might have 2 modes:

Generate fragments only and let people use them
Generate full crud queries (with some way to specify level per model (annotation?)

@Eunovo Would it be possible to see if we can control the instability of the queries?

Actually I have more into that.
If we add more crud capabilities entire client side generation will basically stop making sense as there will be so many variation of the queries that they will need to be expressed by hand.
I think that we might have 2 modes:

Generate fragments only and let people use them
Generate full crud queries (with some way to specify level per model (annotation?)

What do you @wtrocki mean by "more crud capabilities"?

Hi
We are extending CRUD by adding Pagination etc.

@Eunovo Would it be possible to see if we can control the nesting of the queries?
I would love to see your opinion on how we can improve client side generator

We can indeed use per model annotations to specify nest levels but we can also add "include" or "skip" directives controlled by automatically generated variables to modify the structure of the query. Take a look at this example from https://graphql.org/learn/queries/
query Hero($episode: Episode, $withFriends: Boolean!) {   hero(episode: $episode) {     name     friends @include(if: $withFriends) {       name     }   } }

So, we can use both techniques or we just use the second one and allow users to specify how deep they want to go. I'm worried about how big the query definitions will become though.

Is include supported by graphql-tag?

I conducted an experiment with @include directive

Is include supported by graphql-tag?
yes
Would this work on fragments?
yes
If yes then sounds like good thing to try on.
Great! I'm also looking into the possibility of using a custom directive that accepts a variable that specifies query structure
Our current approach is to generate 2 fragments one with no nested level and second with nested. We can ignore fragments and use inline defitionions but then it will not give much benefits for situations when you want to write queries yourself - we support fragment only mode as well. What will be the most flexible way to do so from your point of view? Let's think about it
The @include directive works on fragments. This allowed me to do this

fragment NoteExpandedFields on Note {
   id
   title
   description
   comments @include(if: $withComments) {
      id
      text
      description
   }
}

query findAllNotes($limit: Int, $offset: Int, $withComments: Boolean!) {
    findAllNotes(limit: $limit, offset: $offset, withComments: $withComments) {
      ...NoteExpandedFields
    }
 }

With this, I could query only notes or notes and comments with this
allNotes.variables.withComments = true;
The same thing could be done for custom queries, although they would have to add $withComments to their query definition.

@craicoverflow Any prefference on this. Include actually looks like amazing way to reduce amount of the code we will generate but it will require extra parameters when querying.

In a realistic situation developers will probably write their own fragments anyway, because they will want some very specific fields. We can't cater for every possible combination when they will only end up using a subset of what gets generated.
Would it be possible to only generate single-level fragments and let users combine them as they they wish fore their requirements if they need go N levels deep?
query findAllNotes($limit: Int, $offset: Int) {
  findAllNotes(limit: $limit, offset: $offset) {
    ...NoteFields
    comments {
      ...CommentFields
    }
  }
}

What about something like this
allNotes.variables.structure.withComments = { comments: true, someNestedModel: { anotherModel: true } };

This way query definition will look like this
query someQuery($structure: NoteQuery) @customInclude {}

Doing this would require more generated types like NoteQuery and a custom directive.
Also, some fragments could be included by default whichever system we use. For example withComments can be true by default.
@wtrocki What do you think?

There are a couple of things here.
Generated fragments are actually the most useful here as they giving developers the ability to get quite lengthy queries under control. Sure you can change or remove fields that you do not need later.
The problem here is the level of the relationships nesting and having ability to use generated client in some cases.
I'm kinda going outside this issue, but there are couple issues with client side code in general:

If you made any change then next generate will silently wipe them out
Fragments are useful, queries when generic could be also quite useful (with the ability to make them more specialized later

If we use include we could technically give some of this out of the box by giving developers ability to include changes (not sure how we going to handle actual filtering for this data then as every relation would also gets paginated etc.
When we expose that in one single generic find(...tons of arguments here like withUser, withAddress.. tons of filters for those relations that are parametrized.
We know the capabilities, now it is just matter of what will be actually useful for people.

We know the capabilities, now it is just matter of what will be actually useful for people.

We can anticipate the most common use cases and use defaults. For example, fields are currently extended to level 2; this will cover a lot of use cases. Using include we can include certain levels by default and make other non-essential parameters (pagination, filter, etc.) optional.

When we expose that in one single generic find(...tons of arguments here like withUser, withAddress.. tons of filters for those relations that are parametrized.

Are we ruling this format out?
allNotes.variables.params = {
    comments: {
        offset?: Int, limit?: Int,  filter...
    }
};

Are we ruling this format out?

This looks like operating on compiled doc. This format will work with app but we providing framework and all we inject into client app are documents

So, what is the conclusion? Should I update the Client CRUD query generator to use include with all associated parameters in query definition?

Lets think about this over the weekend. I will ping you on other issues related to client side code and we will see how we can resolve that the best way

I think we need to approach it basing on crud methods.
Create, update and delete will be easy to generate. For find we can generate fairly generic findBy based on fragments.

https://github.com/aerogear/graphback/pull/1235

Looks like this is closed, but feel free to reopen if I am wrong


Add support for bootstrapping workshops via eduk8s

See https://docs.eduk8s.io/en/latest/getting-started/installing-eduk8s.html.
We could use k14s kapp to deploy 1-n workshop definitions then deploy a portal for 1-n participants.
Later on, and more aspirationally, we could turn this repo into a workshop itself.

Might also want to consider a pay-for-use hosted platform like https://strigo.io


Expose interface returned by createClient

I don't know if it is available yet, but after experimenting I was unable to access the type for the createClient method.
It would be nice if the type returned by createClient could be accessed for storing it.
Example:
// Client is currently not exported
import { createClient, Client } from "@polkadot-api/client";
import { getChain } from "@polkadot-api/node-polkadot-provider";
import { WebSocketProvider } from "@polkadot-api/ws-provider/node";

// We currently can not do this
let client: Client;

beforeEach(() => {
  client = createClient(
    getChain({
      provider: WebSocketProvider("wss://rpc.polkadot.io"),
      keyring: [],
    }),
  );
});

test(("A") => {
 // we test something
});

afterEach(() => {
  client.destroy()
});

If it is already available, I apologize for the unnecessary request.

Yeah! We are aware of this issue, and we are currently working on this. Thanks for raising it, though. So, yeah, there are a bunch of public interfaces that are not being exported, then there are others that are being exported that they shouldn't be exported, and then there are others that are exported with names that are not the "best" ones.
We are hopping to have addressed in the next couple of days. So, I'm leaving this issue opened.
In the meanwhile you can do this, though:
let client: ReturnType<typeof createClient>

In the meanwhile you can do this, though:
let client: ReturnType<typeof createClient>

I can use this as a workaround 😄. Thanks!

Closing this, as this was fixed on #325


Multiple subviews extending a master template only works once.

This issue is essentially a duplicate of this SO post I managed to find: http://stackoverflow.com/questions/25093731/blade-extending-a-template-in-multiple-subviews
Basically, I have a template called cards.card:

        @yield('heading')

        @yield('body')

        @yield('footer')

And I have several templates extending it:
//cards.files
@extends('cards.card')

@section('heading')
    Files
@stop

@section('body')
    ...
@stop

@section('footer')
    <button class="btn btn-primary">Submit</button>
@stop

//cards.register
@extends('cards.card')

@section('heading')
    Register
@endsection

@section('body')
        @include('forms.register')
@endsection

@section('footer')
        <button class="btn btn-primary">Submit</button>
@endsection

//more templates, but you get the picture

And then I'm using them as such:
@extends('layouts.master')

@section('content')

        @include('cards.register')

        @include('cards.upload')

        @include('cards.packages')

        @include('cards.files')

@endsection

The problem is, then, that all of the templates are showing as the cards.register template, as you can see here:

Now, to me, it seems intuitive that each time I @include a view, it would have its own scope/instance/whatever instead of being immutable after the first one. But that doesn't seem to be the case here. I've also tried using {!! view('cards.upload') !!} in case that ran differently, but to no avail.
Am I missing something obvious?

Please ask on the forums.

@GrahamCampbell I've been in larachat talking about it. I'm wanting clarification if it's a bug or an undocumented "feature" and if it's the former, I'd like to have it queued to get fixed.

I mean, if you really want, I can make a forum post, and then come back tomorrow and make the same exact issue again. Would you prefer that?

Well, our issues are only here for the community to ask each other about bugs and fix them, and are not used by Taylor. If you want clarification, you'd have to ask him directly.

Would you mind telling me how I should have worded it to indicate that I
was asking about this bug? I didn't think Taylor was the only person who
could provide clarification.
Regardless, I have created a forum post here:
http://laravel.io/forum/08-26-2015-multiple-subviews-extending-a-master-template-only-works-once
and in 24 hours when I either get no replies or, like in larachat, I get
people who have had the same issue and not had the bug get fixed, I will
create the issue again. Perhaps with less information about what exactly is
going on and less politeness since that seems to have caused some confusion
as to whether I was reporting a bug or not.
On Wed, Aug 26, 2015 at 5:21 PM, Graham Campbell<EMAIL_ADDRESS>wrote:

Well, our issues are only here for the community to ask each other about
bugs and fix them, and are not used by Taylor. If you want clarification,
you'd have to ask him directly.
—
Reply to this email directly or view it on GitHub
https://github.com/laravel/framework/issues/10052#issuecomment-135173606
.


Fixes uploading a multi-files issue

When we validate uploading ONLY one file, will be no validation error, like so
<input type="file" name="image" class="form-control">

$request->validate([
    'image' => ['mimes:png'],
]);

Before this PR gets merged
When we try to upload multi-files that fit validation, the validation will fail, for instance
<input type="file" name="images[]" class="form-control" multiple>

$request->validate([
    'images' => ['mimes:png'],
]);

After this PR gets merged
The issue has been solved 🎉

@mahmoudmohamedramadan please take a look at.
https://laravel.com/docs/9.x/validation#validating-arrays
I believe this should be closed.

Adding up to @morloderex comment:
@mahmoudmohamedramadan multi-file validation is already supported, try this:
$request->validate([
    'images.*' => ['mimes:png'],
]);

And read the docs linked by @morloderex

@morloderex This differs from what I talking about. The link that you provide is talking about Validating Arrays. As docs say the array rule accepts a list of allowed array keys. If any additional keys are present within the array, validation will fail, which means, if the given array doesn't have these values then trigger a validation error, and I don't mean that.

Adding up to @morloderex comment:
@mahmoudmohamedramadan multi-file validation is already supported, try this:
$request->validate([
    'images.*' => ['mimes:png'],
]);

And read the docs linked by @morloderex

This does not work perfectly when trying to upload .png with .txt whereas works perfectly with my PR.

Well it won't work as it is validating only for PNG. If in your it is also accepting TXT files, then there is an implementation problem.
Look, see the code regarding validating arrays, it basically does what yours does, iterate over the input array and apply the same rules individually.
But it also takes care of other stuff:

allows to specify the item index in the validation message
allow validating minimum and maximum array items (see example below)
will keep the same index order when sending validation error messages, so a developer can easily iterate over individual error messages
allows nested array items
and other details that have been added since Laravel 5.3, when input array validation was first introduced.

Are you planning on handling those too?
It seems you faced this problem, wasn't aware Laravel already had this feature, and tried to solve your particular problem with an implementation that in the end is less capable compared to what we currently have.
Don´t take me wrong, I see you've been contributing a lot lately with some degree of success. And that is great, Laravel is a framework built from contributions like yours.
But unless you detail what new problem this PR solves that is not already handled by the framework, or what is the new issue the current feature set does not cover, I guess this is very likely not to be merged.
Also, if someone points out there is a similar feature already in place, and you believe it is still not covering the issue you want to handle, why not trying to fix the current feature to solve your issue instead of insisting on introducing new code to new places based "my solution works, current code does not"?
Imagine if someone is not aware of queue batches and then they introduced a half-baked solution to an particular queue driver that only encompasses their single use-case, and when told to use the built-in feature they insist their approach is better? If the framework accepts all new submitted code for each individual use case it would become a nightmare to maintain it.
I am not trying to let you down, on the contrary, I am suggesting you to be more open-minded and see responses like the ones you got here as an incentive and not just critical.
This is the snippet with array size validation, I mentioned above.
$request->validate([
    'images' => ['array', 'min:1', 'max:3'],
    'images.*' => ['mimes:png'],
]);

"If in your solution it is also accepting TXT files, then there is an implementation problem"
nope, my PR solves that issue with a correct validation message error as exists in the gif in addition, this PR can support all features that you mentioned easily by including the next check in validateMin and validateMax as you have just said.
if(is_array($value)) {
    return $this->checkMultiValues(__FUNCTION__, $attribute, $value, $parameters);
}

"Don´t take me wrong, I see you've been contributing a lot lately with some degree of success. And that is great, Laravel is a framework built from contributions like yours."
Thanks ❤

@mahmoudmohamedramadan I guess you didn't get what I meant by individual validation messages.
Take this HTML:
<input type="file" name="images[]" class="form-control">
{{-- error message for first input only --}}

<input type="file" name="images[]" class="form-control">
{{-- error message for second input only --}}

<input type="file" name="images[]" class="form-control">
{{-- error message for third input only --}}

Instead of using the multiple attribute, a developer lists individual inputs. This is very common when a developer wants to outline the allowed maximum input.
How, in your solution, would each individual error message be displayed?
For example, if only the second input exceeds the maximum file sizes, how, in your solution, a developer would display that the user only needs to fix the second file?

his PR can support all features that you mentioned easily by including the next check in validateMin and validateMax as you have just said.

That is what I meant when I said you were only targeting your use case. A PR should consider the global impacts to the framework and not only look at an individual issue.
Imagine one issue being opened every time an user realizes their preferred validation rule is not yet array-aware? It would surely be a nice way to increase merged PR counts.

this PR can support all features that you mentioned easily by including the next check in validateMin and validateMax as you have just said.

If you add the same code to validateMin and validateMax how you'd allow a developer to developer max/min file sizes and max/min items in the array (for example a post can have at most 5 images).
For a single file upload max/min are usually coerced to its file size. How to allow restricting file count?

@mahmoudmohamedramadan I guess you didn't get what I meant by individual validation messages.
Take this HTML:
<input type="file" name="images[]" class="form-control">
{{-- error message for first input only --}}

<input type="file" name="images[]" class="form-control">
{{-- error message for second input only --}}

<input type="file" name="images[]" class="form-control">
{{-- error message for third input only --}}

Instead of using the multiple attribute, a developer lists individual inputs. This is very common when a developer wants to outline the allowed maximum input.
How, in your solution, would each individual error message be displayed?
For example, if only the second input exceeds the maximum file sizes, how, in your solution, a developer would display that the user only needs to fix the second file?

I've tested this and it has worked successfully.
Show validation message error for the first input with a correct index

Show validation message error for the second input with a correct index

@mahmoudmohamedramadan and when the user uploads no files, and both are required?
Do both messages are shown?

"The avatar.0 must be a file of type jpeg"
"The avatar.1 must be a file of type jpeg"

This is currently possible with existing array validation feature.

yup, still working perfectly 😃

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


New report scan of licenses and violations

[x] All tests passed. If this feature is not already covered by the tests, I added new tests.
[x] All static analysis checks passed.
[ ] This pull request is on the dev branch.
[ ] I used gofmt for formatting the code before submitting the pull request.

CLA Assistant Lite bot: Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.
I have read the CLA Document and I hereby sign the CLA
You can retrigger this bot by commenting recheck in this Pull Request

I have read the CLA Document and I hereby sign the CLA

recheck

@talarian1 @eyalbe4
Can you Please review and merge this PR

recehck

recheck

@talarian1 @eyalbe4 can you please take a look at this? The CLA acceptance is not being re-checked.

I have read the CLA Document and I hereby sign the CLA. Recheck

I have read the CLA Document and I hereby sign the CLA. recheck

I have read the CLA Document and I hereby sign the CLA

Thanks for this contribution, @ns-dsinghal!
Could you please document this change in the README? Regarding the CLA assistant - it expects a comment containing exactly "I have read the CLA Document and I hereby sign the CLA". Could you please add such a comment?
Thanks.
Sure. CLA assistant worked now. let me add this change to README

Thanks for this contribution, @ns-dsinghal!
Could you please document this change in the README? Regarding the CLA assistant - it expects a comment containing exactly "I have read the CLA Document and I hereby sign the CLA". Could you please add such a comment?
Thanks.

README updated about this change

Thanks for this contribution, @ns-dsinghal!
Could you please document this change in the README? Regarding the CLA assistant - it expects a comment containing exactly "I have read the CLA Document and I hereby sign the CLA". Could you please add such a comment?
Thanks.

Done

@ns-dsinghal many thanks for your contributions!.
@yahavi please review. Looking forward to your review. If all is good, then looking forward to this available via a new release. Thanks!

@yahavi could you please review

@ns-dsinghal it looks like the static analysis failed. Would you like to take a look?

recheck

@ns-dsinghal it looks like the static analysis failed. Would you like to take a look?

I have fixed the issue can you re-run static analysis job

@ns-dsinghal it looks like the static analysis failed. Would you like to take a look?

I have fixed the issue can you re-run static analysis job

@yahavi need your attention here... looking forward to get this merged, thanks!

@ns-dsinghal it looks like the static analysis failed. Would you like to take a look?

I have fixed the issue can you re-run static analysis job

@yahavi need your attention here... looking forward to get this merged, thanks!

@yahavi @eyalbe4 please review this.

@ns-dsinghal it looks like the static analysis is still failing

@ns-dsinghal it appears adding the safe-to-test label initiates the static analysis.
Please try that label on your changes and see if that helps get early feedback.

@ns-dsinghal it appears adding the safe-to-test label initiates the static analysis.
Please try that label on your changes and see if that helps get early feedback.

label is getting removed by github-actions bot
I have run static check locally using same command it give no error after my changes.
@yahavi you can review now

@yahavi @eyalbe4 could you please review and merge this?

@ns-kbhat @ns-dsinghal - could you please fix the static code analysis issues?

@ns-kbhat @ns-dsinghal - could you please fix the static code analysis issues?

Fixed and checked locally.

cc @yahavi @eyalbe4

@yahavi what is the next step here?

Thanks for your contribution, @ns-dsinghal & @ns-kbhat!
I merged the PR.
Please inform us if everything is functioning correctly.

@ns-dsinghal did all the work, so kudos to him.
@yahavi when can we expect this change to be rolled into a release?


Issues with Select all and filter options in 4.1.13

I found 2 issues with the component
1)Filter option is executing everytime the option is selected which is not ideal.
Especially while performing async calls, because it will cause multiple api calls eventhough the search text is not changed
2)Select all is not selecting all the available options codesandbox

Any updates on the issues?

@anilkumarmr thanks for reporting this but this could take a while since I don't have much time to work on this due to personal reasons but PR is always welcome :)


⚠ Cioos National CKAN has degraded performance

In ac6b50c, Cioos National CKAN (https://catalogue.cioos.ca/) experienced degraded performance:

HTTP code: 200
Response time: 13232 ms

Resolved: Cioos National CKAN performance has improved in 56d6945 after 5 minutes.


AST100 warning on asserts in Docstring

I got the following error:

Version: 1.4.2

Wow, I didn't know it would inspect docstrings!
This is an interesting use case...

This is a configuration setting in PyCharm

Available in 1.11.0


set ID for selectize control based on the ID of the original input

Not sure if you need this. In my case I selectize some hidden (display:none) input elements. And having an ID for the selectize wrapper it's much easier to show/hide the control on demand.

Please please please can we have this. Right now automated testing is very painful/brittle and for me that was one of the primary reasons for moving away from select2.


OneFuzz fails to identify duplicates despite having the same top-level function and same OneFuzz Signature

Information
Despite different callers, the final signature is exactly the same and OneFuzz reports them as separate issues.
See internal ADO work item number 42647486 for specific examples (12 Duplicates as of the filing of this bug report)
The function names are obfuscated here, but this should give an example of the bug with OneFuzz
OneFuzz Signature seen in all the stack traces which have a common set of lines :
0x7ff779fa9ffe is located 64 bytes to the right of global variable 'my_global_variable' defined in 'stdint.h:6' (0x7ff7f09f40) of size 128
SUMMARY: AddressSanitizer: global-buffer-overflow my_header.h:239 in my_class::do_some_work(unsigned __int64)
I could probably come up with regex in perl or python to catch this.  Just a simple Hash (checksum) of the call stack seems not the best way to prevent DUPs.

For Example :Function foo() can be invoked by bar1(), bar2(), bar3().

The kind of exception/violation is the same, this would be 3 different stack traces, yet hitting the same fuzzer issue

Might I recommend comparing the top of the stack trace routine, the exception type, any other unique info

Comparator(bar1()->foo(), Exception Type_N,   bar2()->foo(), Exception_Type_M) and if M == N, we can avoid DUP

Onefuzz version: Whatever the Windows OS internal builds live off

OS: Windows Latest

Provide detailed reproduction steps (if any)

See internal ADO work item
Ping bug filer internally within teams chat
Video Codec One Fuzz channel on Teams

Expected result
What is the expected result of the above steps?
OneFuzz should NOT file DUPLICATES
Actual result
What is the actual result of the above steps?
One Fuzz goes overboard and files duplicate bugs, with currently as many as 12 Duplicates.
AB#35886

Related #3335. Currently the top stack frame is often ASAN code, we are looking to change/improve this.


Introduce RFC mdBook web page

Closes https://github.com/polkadot-fellows/RFCs/issues/53
Preview available here.

What it does

The workflow gathers the source markdown files of RFCs - approved ones, and proposed ones (from open PRs).
The proposed RFCs are separated into new (<7 days since PR created) and stale (>30 days since PR updated).
The RFCs are extended with a table of contents, and a link to the source.
The RFCs are build into a web page using mdBook.
The built web page gets pushed to gh-pages branch - to be published in Github Pages.
The workflow is triggered on merge to main, and periodically once a day.

Is this the final URL https://paritytech.github.io/RFCs/ ?
Then we should probably mention it in the README or even link it in the GitHub repo.

The final URL is: https://polkadot-fellows.github.io/RFCs/
The paritytech one has served as a preview, before it was configured in polkadot-fellows.

Hey @wirednkod, I didn't know about this dashboard 👍

merge the 2 and build the "cargo book" and then release it with the site

Do you have an idea on how we could do it in details?
I don't think the output of mdBook is gonna work properly inside a Vite SPA application, even forgetting about the design incosistency.
I see that the dashboard is fetching the PRs dynamically from Github. What if it fetched the RFC data from the mdBook Github branch instead? The branch is gh-pages, which gets published to Github Pages. I'm thinking I could add a json file with the data, so it would be a single fetch.
That way, the dashboard would operate on the same raw data, but present it with its own front-end design.
What do you think about this approach?
Unless we want to simply go with a link and keep only one site with full details - that seems reasonable too.

@rzadp mdBook is nothing more than generated html pages. If an iFrame (yuk) is added inside the fellowship site, then this would work. The point here is that the data on the mdbook are really detailed and nice - and I think, its better to add a link (to a new tab) towards the RFCs page that you creaed, instead of re-inventing the wheel.
This way the mdbook would be part of the main page and still keep its own design and the work you have done.
I would like to suggest some changes to what you have if we agreed to go with the aforrementioned direction:

remove introduction page
Move Newly Proposed and Proposed categories above the Approved ones

I can add those as issues at https://github.com/polkadot-fellows/RFCs/

Sounds good, I agree with you.

Move Newly Proposed and Proposed categories above the Approved ones

Makes total sense, no need to create an issue, I will do it right away.

remove introduction page

It doesn't seem right for me, for a user who stumbles upon this link to not have any kind of description of what he's looking at. Are you sure about it? If the problem is that it's too short (a single sentence at the moment), we could add more to it.

@rzadp I have integrated now the RFC-book inside the dashboard (see sceenshot):