Rethinking ordering API and use cases

TL;DR - Summary
The way ordering is configured and handled in RSpec is far from intuitive and the use cases aren't compelling or practical IMHO, even though they're potentially extremely useful if properly understood and conveniently implemented.
Goal
Ideally, learning from experiences with existing/previous API and current potential use cases would help design a flexible, maintainable, clear, configurable, extensible and simple new API.
So first I'd like to just collect all the issues and useful use cases in one place, so that any new API proposal would have to take all or most into account.
Earlier discussions
I started with a need to run specs in a different order than "alphabetical":
Then I unintentionally started a long discussion in the wrong place (PR comments) here: https://github.com/rspec/rspec-core/pull/2248#discussion_r65132326
List of issues with current/past issues with ordering API
1. Invisible algorithms.
It's not clear to the user (no output, insufficient docs) how things are being ordered within RSpec and why. E.g. it's not clear files are sorted alphabetically for the sake of providing consistent input for seeding. There's no doc describing even how the ordering works, e.g. that:

Files are always sorted alphabetically and duplicate entries are removed
Groups (?) are sorted by given ordering algorithm (random by seed).
Items within a group are somehow sorted by metadata (?)

2. Cmdline order of files not respected.
This is counter-intuitive, because it's alphabetical, even if the order mode is :random. Even if it "makes sense" to make randomized orders deterministic, that's already too much "know how".
3. Not out-of-the-box support for unit+acceptance testing
No useful, intuitive example for a folder named 'spec/acceptance` where the user expects tests there to be run last.
4. Actual options aren't intuitive in how they work.
E.g. Random with same seed is not random. Files are sorted alphabetically (though this isn't mentioned anywher). :global order strategy probably does some magic, depending on whether individual examples have an :order tag or not. Strategy is reused for sorting both groups and their examples, except by default. (files are alphabetical, examples are randomized).
5. Bad practice supported by default.
It seems like the basic theme behind ordering is to avoid having order-dependent examples. This feels like more of a half-baked CI feature - as opposed to running each example in isolation. The drawback of fully isolated examples (e.g. one per RSpec process) is: they're extremely slow. But on a CI, a fast build time is less of a priority than avoiding bugs.
The only "order related" issues I've ever run into were with:

Threads/objects leaking between specs.
Forgetting a require.

The first needs threads to be joined/killed before the next tests runs, so ordering can't help here much, since it's not deterministic anyway. The second needs running each spec in isolation, for which random ordering also isn't a good replacement for.
I personally think the idea of randomizing tests if overemphasized so much, it's been only detrimental with little pay-off. Rerunning tests simply in normal and then reverse order would likely catch even more issues than a "random" set.
So I'd argue that "reverse" would actually be more useful in practice than "random".
6. Ordering gets in the way of workflows.
This is my biggest issue. A "workflow" can mean e.g. "running files in the order I want". E.g. I want to run just the unit test, then the functional test, then the acceptance test for one given feature/bug. I don't have the confidence I can achieve this quickly and without making mistakes. It's actually easier to just run 3 separate RSpec processes in sequence, which pretty much means ordering is useless. (Because there's no "ordering" if you have only one object).
Also, with randomizing, fail-fast will return a different result every time. Too many times I thought I fixed something, only to realize it's still buggy a few rspec runs later (once I've forgotten the context already). The "workaround" is to set a fixed seed in .rspec-local, but if you forget to remove it afterwards, it renders the order randomizing feature useless.
It's like the only convenient "choice" I have is: "specific random order" and "random random order". Not very good for any intelligent/useful workflow.
7. Ordering strategy doesn't protect from removing/duplicating entries.
The idea of passing a list to a sorting strategy (and expecting a sorted list to be returned) seems flawed. It's should be sufficient to have a compare method that takes either two groups or two examples and returns the result of comparing, much like <=>. Kind of like Ruby's sort works.
This would make configuration simpler, because reverse alphabetical sorting of groups can be done by just switching arguments, e.g. when using sort:
%w( x z y ).sort { |a,b| b <=> a } # reverse alphabetical order

And the resulting array is guaranteed to have the same count of items as the input array. Meanwhile, accidentally modifying the given list can have all sorts of hard-to-debug side effects.
It's also much easier to reason about whether one example should come before another - than to work with partitions or use sort a whole list anyway with a custom compare method (lots more code in configuration).
And there's a lot less testing too (as opposed to having lists to work with).
Additionally, if examples define a custom order themselves, then the compare would be skipped for those, so custom :order metadata would always work, regardless of the sorting strategy. (So the strategy wouldn't need to take those into account at all and tests would be safe from breakage).
8. Reusing the same strategy for sorting examples vs groups.
Previously, these were separate and ordering become example-specific. This doesn't make sense semantically, because examples and groups are different types and potentially need different sorting strategies.
So with a custom strategy, it's easy to mess up one set (e.g. examples) while tweaking the sorting of another (e.g. groups). It heavily blurs the distinction between files, example groups and examples.
E.g. I'm less likely to have "acceptance examples" within a group. I'm more likely to have "acceptance test" defined on groups.
9. I understand SQL, but I don't understand RSpec.
It should be easier to relate one to the other. I mentioned in another post that RSpec is much like a database client app, because you can expect needs like those that can be expressed in pseudo-SQL, e.g:
select * from examples
join groups on example.group_id = group.id
where example.slow == true and group.type != 'acceptance' # filtering
order by example.order asc, example.line_number desc # ordering

There's no reason why selecting and filtering in RSpec shouldn't be as understandable, simple and flexible with the right API. A simple custom compare method (or block) with 2 arguments would handle ordering, and a simple match? method with 1 argument would handle filtering.
There's also no reason why filtering couldn't be as generic as well. More filtering options could be handled with just one command-line option, e.g.:
rspec -include 'example.tag==slow && example.filename.matches(unit/**/*_spec.rb) && example.name.includes('foo') && example.failed_previously`

Of course the goal isn't to implement SQL or Arel in RSpec, but just to allow an internal API where this can be implemented reliably and usefully if needed - with minimal trade-offs.

Thanks for the feedback.  It's going to take me a while to respond to all of it, so I'm going to start responding in this first comment, and circle back around in later comments for other bits.
First off, it's important to realize that RSpec generally has no concept of files as it relates to ordering.  RSpec's ordering logic operates only on example groups and examples.  RSpec interacts with your spec files only to load the specs, but the order the files are loaded is not necessarily the order the specs run in.  RSpec uses a multi-pass approach:

First it loads all your spec files (executing the describe and context blocks, so that all examples and hooks are defined but not yet run)
Then it orders the top-level example groups using the global ordering strategy, and begins running those groups one by one
Each group in turn orders its examples using the group's ordering strategy (which defaults to global but can be overridden using :order => :ordering_strategy_name metadata) and runs each example.  Then group then orders its sub-groups (again using the :order metadata strategy or global if metadata has not been set) and asks them to run (which recursively repeats this step).

So the order that RSpec loads your files doesn't directly determine the order your specs run in.  However, if you use the --defined order, then the order the spec files load is the order the top-level example groups will get run in, because the load order determines the definition order.  (That said, I never use --defined order and generally advise against it's use: I find random ordering to be too valuable to ever consider not using it).
As for the reason we sort the files before loading them...there's an interesting history here (part of which I had forgotten until digging into it just now).

It originated in #660.  You can read the PR but the TL;DR is that file globbing using Dir[] has no defined ordering behavior, and in practice varies between OS X and Linux (and perhaps even on multiple invocations on Linux, though I'm not sure about that), which introduces non-determinism into running your specs (e.g. a specific command on CI might fail but might not be reproducible locally due to different glob ordering).  #660 did not cause the entire list of files to be sorted.
Later #715 was reported, and an attempted fix was implemented in #717.  #717 is the point when the entire file list was sorted before loading spec files.  In practice, I don't believe the issue reported in #715 actually fixed #717 because the underlying problem has to do with the fact that Array#shuffle (which we used to use for random ordering) does not guarantee consistent subset ordering.  We fixed this in 3.3 with the introduction of example ids and stable random ordering more info.

So, I think we can revert the "sort the entire list of files" change from #717.  What I'd like to do is only apply alphabetical sorting to the file glob calls (to ensure determinism) while respecting the list of file/directory arguments you pass at the command line, so that if you run rspec spec/unit/foo_spec.rb spec/integration it'll load spec/unit/foo_spec.rb followed by the spec/integration files in alphabetical order.  That in turn would allow you to pick an order from the command line by passing files and directories in the order you want them along with --order defined.
@e2, if we implement that, would it go most of the way towards meeting your needs?

Not out-of-the-box support for unit+acceptance testing

I'm not sure what out-of-the-box support for unit+acceptance testing would look like, or what you even mean by this.  Is it just wanting to run unit specs before acceptance specs?

E.g. Random with same seed is not random.

I don't understand this point at all.  In every programming language I've ever used, "random" is really just pseudo-random, with a seed that fixes the randomness.  In what way do you find it unintuitive that the seed makes it reproducible instead of truly random?
Also, the entire point of the seed system is to have a way to reproduce a particular ordering -- which would be impossible if not for the fact that the seed fixes the ordering.

:global order strategy probably does some magic, depending on whether individual examples have an :order tag or not.

I don't understand what seems magical about this.  The idea is that you may have needs for a particular example group to be ordered differently from the overall ordering you are using for the suite.  This is commonly the case when you are converting an existing suite from defined ordering (the old standard) to random ordering (what we recommend now).  When you are converting it can be useful to go piece meal and to convert one group at a time to random ordering and/or to enable random ordering overall but configure particular groups to still run in defined order until you fix the issue.
Is the name "global" part of the confusion?  FWIW, we discussed the name at length in #1025.  We were going to call it "default" (as it is the ordering strategy that is used by default, unless you set :order metadata on a group) but we realized there are multiple senses of "default" at play:

The ordering strategy that is used for groups that do not specify :order metadata
The default ordering strategy used as the global strategy if you do not configure RSpec otherwise (e.g. defined ordering)
At the time of #1025, we called "defined" ordering "default", which further added to the confusion.

Strategy is reused for sorting both groups and their examples, except by default.

Can you explain this point more?  I don't understand what you mean.

Bad practice supported by default.

I completely disagree with this entire bullet point.  Random ordering has proven useful to me (and teams I've worked on) on many occasions.  The feedback I've gotten from the community (particularly about the --bisect feature, which builds upon random ordering) has been extremely positive.
The point of random ordering is to surface ordering dependencies as soon as possible (ideally while you are developing the code changes that caused them, while it is cheap to fix).  Random ordering only on CI doesn't work very well to quickly surface ordering dependencies because you need many runs to have a high likelihood of exposing the issue.  Locally, you may run the suite 10s or 100s of times as part of preparing a PR, but on CI it may just once.

The only "order related" issues I've ever run into were with:

It sounds like you use RSpec for very different types of projects than the ones I've seen it used on, because I have seen many, many situations where there are ordering dependencies:

Database writes that leak between examples (e.g. per-example transactions haven't been implemented)
Database writes that leak even when you are using per-example transactions (e.g. due to creating a record outside the scope of an example -- such as in a context hook or in a support file that is only loaded sometimes).
Mutations to global config
Changes to files on the file system

Random ordering was definitely the impetus for us supporting ordering strategies at all.

Reusing the same strategy for sorting examples vs groups.

FWIW, we originally had separate APIs for sorting examples and groups (see #547 and some of the attached commits for what we originally added).  However, in #1025 we decided to consolidate on one strategy instead of 2 after a bunch of discussion (including involving some people who had used RSpec 2's ordering API).  Please read #1025 for background on this.
Given that we used to have separate ordering strategy for examples vs groups, and then simplified to a single API based on open feedback and discussion (at which time no one voiced an opinion in favor of keeping it separate), I think it's unlikely we'd go back to splitting them again, without a number of voices from the community explaining why they'd like to see it change back.

First off, it's important to realize that RSpec generally has no concept of files as it relates to ordering.

I wish I knew that sooner. Thinking about RSpec like a "database" really helps.

I find random ordering to be too valuable to ever consider not using it.

For a CI, yes. For a development workflow, it can be really annoying. And for me, "alphabetical" is pretty much the same as "deterministically random" anyway.
I agree users shouldn't attempt to order tests, except for workflow convenience. You can change the order using an ordering strategy, though many use cases just need "temporary storting". I mean that 3-5 files need to be tested in some order when making changes across files. Once that works, that order is never again needed. So using it as a configuration option doesn't make sense, since that order isn't something you'd commit into a repository.

Is it just wanting to run unit specs before acceptance specs?

Basically yes. Unless running multiple RSpec processes is recommended instead (via commandline or via multiple runners through configuration).
Thanks for the explanation - I'm definitely going to need it. Recursion is a bit of a surprise, but it makes sense because it fits into how things are processed. It explains the sorting calls as well.

file globbing using Dir[] has no defined ordering behavior

That's interesting. I was rather convinced it had something to do with shell argument expansion. E.g. if I pass files in a given order, I expect that order to be respected, even if the files in the dirs (e.g. spec) are then randomized. So I'd expect something like:
files = runner_args.map do |arg|
  arg.dir? ? Dir["#{arg}/**/*_spec.rb"].sort.uniq : arg
end.flatten # don't sort the whole result

Which would sort files when globs are used, but preserve the overall order I'd pass on the command-line. Parameters have to be consistent anyway for a seed to produce deterministic results.
Files are usually independent, so there's little gain in sorting them unless they use global variables or some common resource. (Though that might happen).
It should be up to the Random strategy to shuffle files according to the seed. There's no need to do that on a full list, though.
E.g. rspec --seed 123 spec/foo/ and rspec --seed 123 spec/foo spec/bar should produce the same sequence and failures, even if "bar comes before foo".
Most was mentioned in the links you gave so, so thanks.
The idea of not naming it "alphabetical" make sense, since "alphabetical" is simply just a "hashing" algorithm where each file obviously has a unique name where it can be sorted/shuffled consistently.
I see 3 types of "ordering" being used/mixed here:

Original order of files given on command line - should be preserved since it's a user-specified sequence (e.g. rspec foo bar baz - assuming foo bar baz are dirs)
Sorting for consistency - should be done separately for every command-line argument (dir) passed to rspec, so that original order is preserved (foo bar baz). Directory contents would be sorted (so foo/bar_spec.rb always comes before/after foo/foo_spec.rb). This is needed so during development failures appear in the same order. (There's no point in randomizing if failures are expected).
Shuffling each dir based on seed (which only randomizer should do), where every dir uses the same seed but independently from each other (so same dir produces same shuffled results, no matter where it appears on the command-line)

This way the only time you might get a different failure is when you both leave out a parameter and have tests that are order-dependent.
The drawback is that this would introduce a "file group", where each parameter (foo bar baz) is a "file group". This is like running RSpec multiple times for each parameter, which would do the same thing I guess.
The problem with Array#shuffle is: it doesn't do what the intention of using it needed. It should be encapsulated in a method that sorts the input before shuffling it. That way you don't have to sort file lists anywhere else in RSpec. That way the whole "alphabetical" concept would be buried deep inside this shuffle implementation, where it should be. (As an implementation detail).
To be clear, yes, I'd revert #717 change, except I'd sort directory contents instead:
File.directory?(path) ? gather_directories(path, patterns).sort : extract_location(path)

in here:
paths.map do |path|
  files = paths.map do |path|
  # (...)
    File.directory?(path) ? gather_directories(path, patterns) : extract_location(path)
  end.flatten # no sorting here
end

This way you keep consistency stays within the argument/directory instead of being global across all files found. I'm not sure about distinguishing between user-supplied arguments and e.g. configuration.
An array of files/dirs should be preserved I think.

@e2, if we implement that, would it go most of the way towards meeting your needs?

Yes, absolutely! That would help a lot, because randomizing pretty much gets in the way if the user supplies custom paths. If I run the full tests, expecting them to pass, I don't care whether the order is random or not (so random order is useful when full suite is run).
I'm guessing a lot of users are expecting custom-supplied arguments to be honored with their order. Especially if failures are expected.

Is it just wanting to run unit specs before acceptance specs?

Yes. It's about knowing how to achieve that in a recommended way. If test order randomizing is important, there should be a common setup available for describing this. I'm thinking rspec --init with at least a comment about how to run groups of tests in a given order (even if it just mentions "slow").
Order randomizing is recommended, but there's no "official recommendation" about how to design a workflow (e.g. slow/acceptance tests last). It's a "common" use case with no easily available cheatsheet to reference to achieve it.
That's what I mean by "out of the box support" - even an "official recommendation" with a complex custom sort strategy is better than "guessing" how to achieve such a setup. (Or wasting time setting up scripts to run multiple invocations of RSpec).
rspec --init generated spec_helper.rb seems like the right place, though honoring the user-provided argument order would make it superfluous.

We'd only every not want to sort the files if a specific list of files is passed in, the Rake task and other runners use glob patterns passed to rspec to load files and those would suffer the same non-deterministic issue as Dir[]. POSIX doesn't guarantee file order.

It's unreasonable for RSpec to specially treat a :slow tag for example - but showing how to reorder tests based on such a tag would help bootstrap a lot of projects faster. (Instead of just configuring filtering + multiple RSpec runs).
I mentioned somewhere that likely many people are using RSpec + Cucumber simply as an alternative to not knowing how to achieve unit tests + acceptances tests within one process. rspec-rails is a lot less useful when integration and unit tests are mixed up together. Running each manually is no fun either.

The point of random ordering is to surface ordering dependencies as soon as possible (ideally while you are developing the code changes that caused them, while it is cheap to fix).

I agree. It is best to "deal with it as soon as possible". But it also should be possible to "opt-out" of it you're dealing with failures across a whole stack (unit <-> functional <-> acceptance).
That's also what a seed is for: reproducing errors. And if I have multiple errors, I expect to get the same failures in the same order. If there's a order dependency issue, sure I want to fix that immediately. But if there are no dependency issues, I don't want to get a different order of failures every time.
I can set the seed to a fixed value. But then I'll most likely forget, effectively turning off the dependency order checking anyway.
In short, it's like I want the ordering fixed, but not by a seed+alphabetical combination. Sometimes my custom order will be permanent (unit vs acceptance), sometimes it's temporary (particular bug across layers in a stack). I don't want to reproduce dependency order failures in this case. I want to reproduce my own set of failures.
During TDD I'm mostly dealing with fixing failures. On a CI, I want failures to occur. Before a push, I don't mind even running tests 3 times: once in defined order, second in reverse, and a bonus "random" order too.
I'm a bit torn here, because my needs are tied to a specific workflow, and not something generic. But defining such a workflow within a single order strategy definition in a configuration spec ... that seems like a stack of hacks using ordering for something it wasn't designed for.

I don't understand this point at all. In every programming language I've ever used, "random" is really just pseudo-random, with a seed that fixes the randomness. In what way do you find it unintuitive that the seed makes it reproducible instead of truly random?

I've always understood the concept of random and seeds in the context of RSpec. What I never understood was: why am I getting different failures in a different order every time? I can set the seed, but then the order is "fixed" in technical terms, but as a software developer looking at the screen, it's still looks random every time. If tests were always ordered, I'd get a "feel" for which failure maps to which file. With the progress formatter, I could "learn" that "the fifth dot" is spec/foo_spec.rb. And that if I see about 30 lines of document formatter output, I know that the failure is at 3/4 of the spec file.
But with shuffled examples, it's a bit like I'm working a slightly different project every time. It might make sense to have 2 rspec instances running. One "ordered" for development and one for "finding order dependency problems" - which can work in the background while I'm fixing the development issues. But of course RSpec has no way of distinguishing dependency order failures from everything else.
I'm just saying there's a perception/focus cost to having tests randomized. Especially when failures occur.

Locally, you may run the suite 10s or 100s of times as part of preparing a PR, but on CI it may just once.

I agree, but there may simply be better ways of shuffling examples to increase the likelyhood of detecting issues. e.g. If you have foo_spec.rb with example A and B and bar_spec.rb with C, D and E, the probability of A and C sharing resources is small, while combinations C+D, C+E, D+E, D+C, E+D and E+C cover all the likely combinations of bar_spec.rb reusing let blocks incorrectly. Especially if they're in the same group.

Random ordering was definitely the impetus for us supporting ordering strategies at all.

The examples seem right. It's also probably why I use mocking a lot more extensively - and it's also why I rely on acceptance/integration tests to prevent the issue of mocking "too much". That's why I want to always get the mocking working first - until then, acceptance tests are broken by definition. Mocks isolate so much already, that randomizing just gets in the way.
Still, databases are hard to mock without them hiding bugs, and filesystem touching tests are notoriously time-consuming to get right.
Instead of "testing for order dependency issues" I'd much rather be "protected" by them in some way.
I agree that detecting them early is crucial though. Sadly, that doesn't come free.
The best thing I can think of right now - to get the best of both worlds - is: "turning ordering off for selected tests". E.g. unit tests with mocks (which are independent by default) probably aren't going to benefit from test shuffling. Integration tests are probably going to benefit the most.
I'm more trending towards simply avoiding dependencies rather than trying to detect them. A poorly written test doesn't mean the code is going to fail in production, while running each acceptance test in e.g. Docker for guaranteed isolation. Kind of like mocks, because they don't use host resources either.
So probably there are some niche cases like mine where shuffling is just cost, overhead and little gain.

but showing how to reorder tests based on such a tag would help bootstrap a lot of projects faster.

Cargo culting is one of the biggest problems in Ruby development, it helps no-one; our aim should be to educate users how to use our APIs, not give them copy and pasteble snippets to bootstap faster.

That's also what a seed is for: reproducing errors. And if I have multiple errors, I expect to get the same failures in the same order. If there's a order dependency issue, sure I want to fix that immediately. But if there are no dependency issues, I don't want to get a different order of failures every time.

You should get the same failures in the same order with --seed that's what its for, it's not for fixing the order but for reproducing the failures from a specific order.

I've always understood the concept of random and seeds in the context of RSpec. What I never understood was: why am I getting different failures in a different order every time?

Then you've not understood the concept of random.

I'm just saying there's a perception/focus cost to having tests randomized.

For you, I've certainly never found this to be the case, where the failures occur in the test run is usually unimportant, after finding failures most people will run just the failures until they're fixed. This is why we introduced --only-failures and --next-failure to make this easier.

Mocks isolate so much already, that randomizing just gets in the way.

Randomisation is a way to check you're isolated.

"turning ordering off for selected tests".

You can set ordering per example group, and given it's just ruby you could even turn that on and off as you saw fit. e.g. RSpec.describe order: (ENV['ORDERED'] ? :defined : nil)

I'm more trending towards simply avoiding dependencies rather than trying to detect them. A poorly written test doesn't mean the code is going to fail in production, while running each acceptance test in e.g. Docker for guaranteed isolation. Kind of like mocks, because they don't use host resources either.

If you successfully avoid dependencies randomisation causes you no issues, but running each test truely isolated is beyond the scope of RSpec.

If I could travel through time (to 2012), I'd suggest a few things:

Merging the sorting strategies for both examples and groups into one has maybe no technical downside, except that is obfuscates how RSpec works. An API's method names are effectively "documentation". So if I don't have a separate "sorted_examples" and "sorted_groups" I'm left guessing which one (or both?) is handled by the method. I wouldn't personally mind, since I'd abstract out the configuration of sorting strategies anyway, so even if I had to use hacks for distinguishing between examples and groups, it would be hidden anyway. Using alias would've been sufficient though, since I wouldn't care if they both resolved to the same method or not. But it still would be confusing to get examples going through both. (I have one flat directory with 5 files. Why is this sorting methods called 30 times?).

Not passing an array. I would've agreed with you that it's a bad idea. I'd suggest passing a class name, just like -f takes a class name for formatting. The initializer for the class would take a seed, and so based on the strategy people could decide if they want to even show the seed or not in the output. It would be up to the person writing a strategy to decide whether they want to reuse the same sorting method for examples and groups or not. If it was a class, loading a database/file into memory would be cleaner. Blocks are nice as long as the calls are stateless. Classes can hold data where blocks are too tricky. Yes, passing an array does seem more powerful with the "partition" thing. But a class is much easier to test and can be tested independently from RSpec. (Just like you can define RSpec formatters without inheritance). With a comparison block (like for sort), you can have a case statement to even warn about unexpected values. And returning "0" would revert to default sort order.

If you ever invent a time machine, let me know... ;)
As for the :global parameter, it doesn't fit in well with the fact that examples and groups share the same shuffling method. The term :global is just as amorphous as the term :default (which luckily was replaced with :defined, which is an awesome alternative).
:global. Global what? As opposed to :local? What is it called with? When is it skipped? I just have lots of questions and doubts. Why :global? Is it special? Has the meaning changed between RSpec versions? Will the behavior change if I name it to something else? RandomOrder has a meaning. So has DefinedOrder. But GlobalOrder doesn't imply anything meaningful.
To summarize, I just want to run some tests before others. Ideally in a generic way that doesn't require adding a complex, brittle block to every project. Ideally something I can unit test, so even if the behavior ever changes (RSpec 4?), I can update it in one place, without going through multiple projects and spec_helper files to fix it.
My options until now have been:

Run multiple RSpec processes (takes writing scripts and hacking other tools/frameworks, messes up coverage, multiple output files, etc.)
Run multiple RSpec processes using runner config (I didn't know about this)
Rename my files/directories so they alphabetically sort in the order I want (lame idea, I know)
Use a custom sort strategy (though coming up with a working solution would've been tough to figure out, given the shared shuffling algorithm, passing a list, a :global name, wondering how to pass a class and how to use that class (will the -r option work for this?) and ending up with writing a custom plugin anyway, since I'll need to unit test. I'll actually probably decide to write a whole "RSpec configuration manager" just to avoid working out how to "inject" what I want into a project in a robust way. (e.g. if there's a stray "order" option, my plugin probably will have no way of even issuing a warning).

Preserving the file argument order would be awesome, because it's intuitive and at least gives me some execution consistency - especially during "one-off" situations.
The discussions linked were enlightening - thanks for looking for them. I never would've thought many of the ideas would've been recurring today still.
I appreciate the work and thought that was put into this more.
Actually it's part of the reason I struggled with this - I assumed I was doing something wrong, since RSpec has such a long history and widespread usage.

Blocks are nice as long as the calls are stateless. Classes can hold data where blocks are too tricky. Yes, passing an array does seem more powerful with the "partition" thing. But a class is much easier to test and can be tested independently from RSpec.

You can pass any instance of any object that responds to call(examples), so you are free to do this should you rather not use a block. e.g.
config.order :global, MyOrderingStratergy.new(config.seed)

:global. Global what? As opposed to :local? What is it called with? When is it skipped? I just have lots of questions and doubts. Why :global? Is it special? Has the meaning changed between RSpec versions? Will the behavior change if I name it to something else? RandomOrder has a meaning. So has DefinedOrder. But GlobalOrder doesn't imply anything meaningful.

Suggestions for "applies globally as the default ordering strategy" then, remembering that we have no control of the implementation. The name :global is better than :default IMO.

To summarize, I just want to run some tests before others. Ideally in a generic way that doesn't require adding a complex, brittle block to every project. Ideally something I can unit test, so even if the behavior ever changes (RSpec 4?), I can update it in one place, without going through multiple projects and spec_helper files to fix it.

If your block is more complex than you'd like write a gem to do this and pass in as a callable object, or delegate to it within the block. Your gem is free to register this as a specific named ordering strategy so you can use config.order :my_gems_ordering etc in your projects.

Cargo culting is one of the biggest problems in Ruby development, it helps no-one; our aim should be to educate users how to use our APIs, not give them copy and pasteble snippets to bootstap faster.

The problem with the sorting strategy was that an example would be much better education for me. It's not obvious that the shuffling was shared - I would've needed to dive into the codebase or issue archives to find that out. I'm not into remembering methods or trying to recall if :global had a specific meaning or not.
It's not like typing a few hundreds of characters from memory every time is a win, either. The idea to copy (for me at least) is not to avoid reading, but to avoid making mistakes and spending lots of time figuring out what I got wrong.
Ideally though, I wouldn't have to paste anything and I'd just get the order I want in some intuitive way. Like changing one setting from x to y. (And not registering a whole custom strategy for something I believe is "typical").

You should get the same failures in the same order with --seed that's what its for, it's not for fixing the order but for reproducing the failures from a specific order.

Yes, but this has 2 problems:

If is set the seed manually (e.g. in .rspec-local), I'll forget about it. If I recall the command from shell history, I might accidentally use an earlier seed.
 I'm probably not going to try "random seeds" until I get an order I can work with. If I fix the issue with the next 3 minutes, I'm not ever going to need that same seed number ever again.

Then you've not understood the concept of random.

I meant that the failures in the same files with different seeds results in a different order of failures. Yes, this is how it works, but it's annoying to be debugging and getting the same failures in a different order every time.

For you, I've certainly never found this to be the case, where the failures occur in the test run is usually unimportant, after finding failures most people will run just the failures until they're fixed. This is why we introduced --only-failures and --next-failure to make this easier.

Yes, but the actual order of those failures is randomized based on seed. E.g. what if I'd like to first see the failures in the Rails models first? I can set the seed to a fixed value, but then I've gotten rid of randomizing altogether. (Until I remember to unset it or after a fresh checkout). This kind of shows how useless the randomization is. If it gets in the way I can disable it.
I don't want to manually have to set the seed and select a different set of files every time there's a failure during refactoring. If I was to do that, I might as well just create a script to run each file one by one in a separate process with the order I want. But that would negate using RSpec as a runner.

Randomisation is a way to check you're isolated.

I don't want to "check" if I'm isolated. I know I'm isolated when using mocks. That's how mocks work. If I don't use instance variables or globals or include modules, it's not like Ruby scope will leak by accident. The point is that randomization is so hard-backed in, I can't seem to have a sane way of avoiding it if I write fully isolated tests.

You can set ordering per example group, and given it's just ruby you could even turn that on and off as you saw fit. e.g. RSpec.describe order: (ENV['ORDERED'] ? :defined : nil)

By "tests" I meant "groups", not examples. Having examples shuffled is annoying too (when my using doc formatter to check if I've covered all the edge cases), but much less so.

If you successfully avoid dependencies randomisation causes you no issues, but running each test truely isolated is beyond the scope of RSpec.

For such isolated tests in the past I've used something like for $i in **/*_spec.rb; do rspec $k (....). I could do the same with each example, though that might be quite slow on large projects. But if "slow" makes it less beneficial, then I'm questioning the benefit to begin with.
My point here: if isolation is important, there are more robust and powerful ways. If it's just an "addon bonus", it would be nice to be able to opt-out if I'm not interested. A custom sort strategy doesn't help unless I work out how to access the list of specs/spec dirs passed to RSpec, partition examples by those file/dir arguments and sort examples by the order defined, while possibly including any example-specific ordering defined by metadata. That's an extremely complex way of "run these tests in the order I pass on the command-line".
A multi-process approach is the best I can do now until command-line argument order is honored. (It would be AMAZING if it was!).

I never even got through responding to your initial comment, and now there are like 4 pages more to read through.  I'm sorry, but I don't have the time to read through everything you've posted.  If you could ask for one specific thing it would be easier to respond and hopefully meet your needs than when you have multiple comments that are hundreds or thousands of words each.
Anyhow, I've started working on a fix locally (and will hopefully have a PR up in the next day or two) to respect the ordering of the files/directories passed at the CLI when RSpec loads spec files.  I hope this will meet your needs.

I'm sorry, but I don't have the time to read through everything you've posted.

No problem. Respecting the ordering solves everything for me. I'd much rather not take your focus away.
Thanks for everything you do!

BTW, I will respond to one thing: "why global?"
Individual example groups can choose how to order themselves via :order metadata.  (That's the "local" ordering for an example group).  The "global" ordering globally applies to the suite as a whole.  We were going to call it "default" but that would create more confusion: the global ordering can be set to random or defined but defaults to defined.  So if we called it "default", then we'd have to talk about there being a default default ordering, which would overload the term "default".  "global" was the best term we were able to come up with so that "default" wasn't overloaded.
Sorry if it's confusing.

@JonRowe -

You can pass any instance of any object that responds to call(examples), so you are free to do this should you rather not use a block. e.g.

That should be documented somewhere. I thought you could only pass a symbol. Looks like a great starting point to insert a plugin. Thanks!

If your block is more complex than you'd like write a gem to do this and pass in as a callable object, or delegate to it within the block. Your gem is free to register this as a specific named ordering strategy so you can use config.order :my_gems_ordering etc in your projects.

There really should be separate examples for:

How to override sorting of examples and groups with a custom block.
How to override sorting of examples and groups with a custom class.
How to override sorting of examples and groups from a custom gem.

But I'm glad I've gathered all this info, so thanks.

BTW, I will respond to one thing: "why global?"

The best short explanation I can think of is "not-from-metadata" or "sort regardless of metadata".
But I do wonder if explicit ordering in example metadata should even be overridable.
What I feel I'm doing here that's "weird" is: I'm considering using ordering for defining a custom workflow with RSpec. E.g. I'd like failures to impact which tests are run and possibly detect dependencies between files to impact the order of failures.
I'm saying "weird" here, because according to the discussions, ordering was supposed to be only used for outdated order-dependent tests. And not for "workflow optimizing" like I feel I need.
Timeout for me. I hope I can repay you guys for the attention, answers and insights.

...according to the discussions, ordering was supposed to be only used for outdated order-dependent tests. And not for "workflow optimizing" like I feel I need.

I wouldn't say that's accurate at all.  The main use cases we were solving was supporting random ordering, and being able to control ordering on a per-example group level with metadata, but we did not want to limit ordering to just those use cases -- so we exposed an API that allows you to configure ordering with a block of arbitrary logic.

@e2 -- I think my fix in #2253 will help meet your needs.  Care to take a look?

@myronmarston - works great.
One issue though is: if you pass the file multiple times on the command-line, it's run multiple times.
E.g. rspec spec/foo_spec.rb spec runs spec/foo_spec.rb twice.
So uniq would have to be "called across arguments" to get the first match and discard the remaining duplicates.
But it works beautifully otherwise.
If I don't specify an order, it works and also doesn't shuffle examples (no seed shown).
If I set the order to :random in the config, it shuffles everything.

Is that an observed result? The uniq should take care of that issue already

s that an observed result? The uniq should take care of that issue already

I tested it locally and observed that the spec file is loaded twice.  The problem is that spec files from the dir glob get expanded but the files passed as CLI were left as is, so the uniq didn't de-dup properly.
I've fixed it with my latest push.

One really cool thing is: putting a slow failing integration feature first with fail-fast ... and if it passes the rest of the suit is run minus that already-passing spec. No need to "rerun everything" after a fix makes things green.
Others may complain that this is all file/dir based, but as is it couldn't make me happier :)

Sounds like your use case has been addressed so I'm going to close this.


always send responses back as utf8

@lukechurch, make sure we always send responses back as utf8. This makes non-ascii responses happy.

Luke, when you get a chance, can you patch this in and re-push to appengine? Thanks!

Pushing, it just takes a few minutes


Compute API: NPE in StorageImageConfiguration

Steps to reproduce:

Execute compute.listImages().iterateAll()

It throws the following exception:
java.lang.NullPointerException
        at com.google.cloud.compute.StorageImageConfiguration$Builder.<init>(StorageImageConfiguration.java:69)
        at com.google.cloud.compute.StorageImageConfiguration$Builder.<init>(StorageImageConfiguration.java:49)
        at com.google.cloud.compute.StorageImageConfiguration.fromPb(StorageImageConfiguration.java:202)
        at com.google.cloud.compute.ImageConfiguration.fromPb(ImageConfiguration.java:188)
        at com.google.cloud.compute.ImageInfo$BuilderImpl.<init>(ImageInfo.java:172)
        at com.google.cloud.compute.Image.fromPb(Image.java:212)
        at com.google.cloud.compute.ComputeImpl$40.apply(ComputeImpl.java:1259)
        at com.google.cloud.compute.ComputeImpl$40.apply(ComputeImpl.java:1256)
        at com.google.common.collect.Iterators$7.transform(Iterators.java:750)
        at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:47)
        at com.google.cloud.PageImpl$PageIterator.computeNext(PageImpl.java:72)
        at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:145)
        at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:140)
        at jetbrains.buildServer.clouds.google.connector.GoogleApiConnectorImpl$getImagesAsync$1.doResume(GoogleApiConnectorImpl.kt:312)

According to java docs com.google.api.services.compute.model.Image#getRawDisk could return null, so it's not safe to execute imagePb.getRawDisk().getContainerType() != null:
https://github.com/GoogleCloudPlatform/google-cloud-java/blob/master/google-cloud-compute/src/main/java/com/google/cloud/compute/deprecated/StorageImageConfiguration.java#L69-L73
Originally from: https://youtrack.jetbrains.com/issue/TW-53938

According to this compute doc compute now supports creating images from four sources: rawDisk.source, sourceDisk, sourceImage and sourceSnapshot. IIUC the compute client library does not support the latter two for the moment. From the conversation in here it seems the user is using sourceImage to create an image.
We should probably make it a feature request since it's relatively non-granular work. @garrettjonesgoogle @pongad Any thoughts?

We shouldn't do any feature work on this client since it's going to be replaced by a new auto-generated client soon.

I cannot seem to open the linked page. If the work is non-granular, I agree with @garrettjonesgoogle that we should wait for this to be replaced by auto-generated client.

Thanks @garrettjonesgoogle @pongad let's leave this issue open until the client is replaced by the new auto-generated client.
BTW the link is the same as the last link in @dtretyakov 's comment. It seems down.

The new compute library is generated.


add Java snippets for creating, listing, and deleting queues

Environment Variables need to be set:

GOOGLE_CLOUD_PROJECT to the project id

Do you need to update the README.md to mention these?
Also, I don't see any RegionTags -- You'll eventually want to add those.

I'll update the README, and I believe there are region tags starting above the imports, no?
Also, what would be the best way to resolve the static analysis error? Making the snippet methods private means they can't be called in the testing classes.

It's not required (or sometimes possible) to get all the static analysis errors.  You can google them spotBugs to see if any of them are easy to fix.  It's to get you to think about writing better code.
Yea - I just checked two files and didn't see them in the PR, but they were there.  Just tell me when you'd like me to merge.


Filter existing restlet headers when building restlet request

at line 199, i think i previously (earlier PR)  tried to pull the restlet headers from the request (which will always be empty) instead of the exchange headers.  fixed that as well.

What ticket is this related to, and can you comment more on why you think this PR is correct / should be merged?

https://issues.apache.org/jira/browse/CAMEL-10155
When sending 2 restlet request are sent back to back, the restlet headers from the first response are sent in the headers of the 2nd request (which is what normally happens)  But there are some headers we ALWAYS filter out before sending a restlet request such as “transfer-encoding”.
These do not get filtered out because they are nestled away in the “org.restlet.http.headers” header.  So we need to loop through these headers and filter out the junk before sending a restlet request.


lodash dependency

Looking through the code, the majority of lodash usage is extremely basic, most of it is just things like isFunction and isObject. I'm curious if there has been any discussion about dropping the lodash dependency entirely? Seems like a pretty large burden just for basic type checking functions.

So why should it be an issue? Using these functions gives us safety that they just work.

Size of bundle and depedency management is my most "scientific" reason. The large project I'm working on now does not use lodash anywhere, but it's included in our bundle because this library uses it.
On a personal level, I don't think this project really needs lodash as all of the used lodash features are basically one-liners; especially since you're using babel so have access to all the fancy ES6 features.

We are only cherry-picking the functions we need with the slash import, so in the end, only required functions are in the bundle and not the whole lodash library.
Indeed there are some functions like isArray we could replace with their ES5/ES6 equivalent, but not all (for example camelCase).
We might rewrite some stuff to drop some unnecessary lodash functions.

It's true that doing the slash import keeps the amount of lodash code to a smaller amount, those requires STILL bring with them a fair amount of common lodash code so that those imports need.

I've just seen that Redux is also using lodash. So lodash will be installed and bundled anyway if you are using Redux in your project.
Imo lodash has also become a standard library and as I said above, it gives us safety that things are working. It is also known to be performant out of the box and makes the code more readable, so I don't think that we are dropping lodash completely except for the things that can also be written natively.

I didn't realize redux was using it; bummer. Well with that in mind it would make sense to leave lodash in since it's already sort of part of the ecosystem.


how to reproduce the result for cityscapes

Thanks for the valuable contribution!
I am trying to reproduce the results for cityscapes, I used the  configuration file  cityscapes_spnet101.yaml
The validation mIoU can only reach to ~73.x %.
my experiment runs on 4 GPUs, sync_bn is enabled.
The only thing I changed is the batchsize, i am using 12 sample in a batch.
Could you give me some hints?

Thanks for your interests in this paper. I have tried spnet50 on Cityscapes
and the mAP score is 79.5 on the validation set (w/o hard example mining).
Please check your configuration.
BTW, I have updated some code. So, you can reclone it.
Kind regards,
Qibin (Andrew)
On Wed, Jul 8, 2020 at 5:23 AM SHMCU<EMAIL_ADDRESS>wrote:

Thanks for the valuable contribution!
I am trying to reproduce the results for cityscapes, I used the
configuration file cityscapes_spnet101.yaml
The validation mIoU can only reach to ~73.x %.
my experiment runs on 4 GPUs, sync_bn is enabled.
The only thing I changed is the batchsize, i am using 12 sample in a batch.
Could you give me some hints?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Andrew-Qibin/SPNet/issues/13, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADNCN42ZBE3RWSPFTT3HOFLR2OG65ANCNFSM4OTU57GQ
.

In your configuration, do you set use_apex=True ?
Thanks,
SHMCU

Hi Qibin,
Could you share your configuration file for this spnet50 achieving mIoU 79.5 on Cityscapes val set?
Thanks,
Hai

you can follow the setting that the author provide ,and don't change anything ,and try again , you have four gpus, it's impossible that you just get 73.x,

i can get 73 with one gpu,and the batchsize is 4

I have the similar question.

Thanks for the valuable contribution! I am trying to reproduce the results for cityscapes, I used the configuration file cityscapes_spnet101.yaml The validation mIoU can only reach to ~73.x %. my experiment runs on 4 GPUs, sync_bn is enabled.
The only thing I changed is the batchsize, i am using 12 sample in a batch.
Could you give me some hints?

I have the same problem ,can u give me your wechat number  so we can discuss the problem, my wechat is  lz_609492668

If it is trained on multiple GPUs, did you enable the sync_batchnorm ?
On Sunday, November 14, 2021, 06:11:28 AM PST, cm0561 @.***> wrote:
Thanks for the valuable contribution! I am trying to reproduce the results for cityscapes, I used the configuration file cityscapes_spnet101.yaml The validation mIoU can only reach to ~73.x %. my experiment runs on 4 GPUs, sync_bn is enabled.
The only thing I changed is the batchsize, i am using 12 sample in a batch.
Could you give me some hints?
I have the same problem ,can u give me your wechat number so we can discuss the problem, my wechat is lz_609492668
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Thanks for your repaly , now I train the model with only one gpu and later I will train the moel with multiple GPUs. can u give me some other advice, thanks anyway!
------------------ 原始邮件 ------------------
发件人:                                                                                "Andrew-Qibin/SPNet"                                                                                @.>;
发送时间: 2021年11月15日(星期一) 凌晨3:38
@.>;
<EMAIL_ADDRESS>主题: Re: [Andrew-Qibin/SPNet] how to reproduce the result for cityscapes (#13)
If it is trained on multiple GPUs, did you enable the sync_batchnorm ?
On Sunday, November 14, 2021, 06:11:28 AM PST, cm0561 @.***> wrote:
Thanks for the valuable contribution! I am trying to reproduce the results for cityscapes, I used the configuration file cityscapes_spnet101.yaml The validation mIoU can only reach to ~73.x %. my experiment runs on 4 GPUs, sync_bn is enabled.
The only thing I changed is the batchsize, i am using 12 sample in a batch.
Could you give me some hints?
I have the same problem ,can u give me your wechat number so we can discuss the problem, my wechat is lz_609492668
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Do u  have a wechat,can i have your wechat so we can discuss the model in  other  problem,my wechat number is lz_609492668
------------------ 原始邮件 ------------------
发件人:                                                                                "Andrew-Qibin/SPNet"                                                                                @.>;
发送时间: 2021年11月15日(星期一) 凌晨3:38
@.>;
<EMAIL_ADDRESS>主题: Re: [Andrew-Qibin/SPNet] how to reproduce the result for cityscapes (#13)
If it is trained on multiple GPUs, did you enable the sync_batchnorm ?
On Sunday, November 14, 2021, 06:11:28 AM PST, cm0561 @.***> wrote:
Thanks for the valuable contribution! I am trying to reproduce the results for cityscapes, I used the configuration file cityscapes_spnet101.yaml The validation mIoU can only reach to ~73.x %. my experiment runs on 4 GPUs, sync_bn is enabled.
The only thing I changed is the batchsize, i am using 12 sample in a batch.
Could you give me some hints?
I have the same problem ,can u give me your wechat number so we can discuss the problem, my wechat is lz_609492668
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

What is the batchsize if you are training on one GPU. If it is larger than 12, then it should be fine.
On Sunday, November 14, 2021, 05:31:38 PM PST, cm0561 @.***> wrote:
Thanks for your repaly , now I train the model with only one gpu and later I will train the moel with multiple GPUs. can u give me some other advice, thanks anyway!
------------------ 原始邮件 ------------------
发件人: "Andrew-Qibin/SPNet" @.>;
发送时间: 2021年11月15日(星期一) 凌晨3:38
@.>;
<EMAIL_ADDRESS>主题: Re: [Andrew-Qibin/SPNet] how to reproduce the result for cityscapes (#13)
If it is trained on multiple GPUs, did you enable the sync_batchnorm ?
On Sunday, November 14, 2021, 06:11:28 AM PST, cm0561 @.***> wrote:
Thanks for the valuable contribution! I am trying to reproduce the results for cityscapes, I used the configuration file cityscapes_spnet101.yaml The validation mIoU can only reach to ~73.x %. my experiment runs on 4 GPUs, sync_bn is enabled.
The only thing I changed is the batchsize, i am using 12 sample in a batch.
Could you give me some hints?
I have the same problem ,can u give me your wechat number so we can discuss the problem, my wechat is lz_609492668
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

I train with only  one gpu  and the batchsize can only be 1 , it will be an error of "cuda out of memory" if I set it 2,  and I have a another problem even i set the batchsize 1 , when the model procress the eval it  still have the error of "cuda out of memory",  my gpu is 1080ti which have 11G memory!
------------------ 原始邮件 ------------------
发件人:                                                                                "Andrew-Qibin/SPNet"                                                                                @.>;
发送时间: 2021年11月15日(星期一) 上午10:46
@.>;
<EMAIL_ADDRESS>主题: Re: [Andrew-Qibin/SPNet] how to reproduce the result for cityscapes (#13)
What is the batchsize if you are training on one GPU. If it is larger than 12, then it should be fine.
On Sunday, November 14, 2021, 05:31:38 PM PST, cm0561 @.***> wrote:
Thanks for your repaly , now I train the model with only one gpu and later I will train the moel with multiple GPUs. can u give me some other advice, thanks anyway!
------------------ 原始邮件 ------------------
发件人: "Andrew-Qibin/SPNet" @.>;
发送时间: 2021年11月15日(星期一) 凌晨3:38
@.>;
@.@.>;
主题: Re: [Andrew-Qibin/SPNet] how to reproduce the result for cityscapes (#13)
If it is trained on multiple GPUs, did you enable the sync_batchnorm ?
On Sunday, November 14, 2021, 06:11:28 AM PST, cm0561 @.***> wrote:
Thanks for the valuable contribution! I am trying to reproduce the results for cityscapes, I used the configuration file cityscapes_spnet101.yaml The validation mIoU can only reach to ~73.x %. my experiment runs on 4 GPUs, sync_bn is enabled.
The only thing I changed is the batchsize, i am using 12 sample in a batch.
Could you give me some hints?
I have the same problem ,can u give me your wechat number so we can discuss the problem, my wechat is lz_609492668
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Okay, try to train with batchsize larger than 12. You can either choose to shrink  the width of the layers or train at lower resolution or change to a smaller backbone.11G memory is not enough to play with segmentation models. You can try some other CV tasks but not these dense prediction task.Batch size 1 will definitely not work. Cause it makes the batchnorm layer fails. Think about how to compute variance if there is only one sample.
On Sunday, November 14, 2021, 10:21:02 PM PST, cm0561 @.***> wrote:
I train with only  one gpu  and the batchsize can only be 1 , it will be an error of "cuda out of memory" if I set it 2,  and I have a another problem even i set the batchsize 1 , when the model procress the eval it  still have the error of "cuda out of memory",  my gpu is 1080ti which have 11G memory!
------------------ 原始邮件 ------------------
发件人: "Andrew-Qibin/SPNet" @.>;
发送时间: 2021年11月15日(星期一) 上午10:46
@.>;
<EMAIL_ADDRESS>主题: Re: [Andrew-Qibin/SPNet] how to reproduce the result for cityscapes (#13)
What is the batchsize if you are training on one GPU. If it is larger than 12, then it should be fine.
On Sunday, November 14, 2021, 05:31:38 PM PST, cm0561 @.***> wrote:
Thanks for your repaly , now I train the model with only one gpu and later I will train the moel with multiple GPUs. can u give me some other advice, thanks anyway!
------------------ 原始邮件 ------------------
发件人: "Andrew-Qibin/SPNet" @.>;
发送时间: 2021年11月15日(星期一) 凌晨3:38
@.>;
@.@.>;
主题: Re: [Andrew-Qibin/SPNet] how to reproduce the result for cityscapes (#13)
If it is trained on multiple GPUs, did you enable the sync_batchnorm ?
On Sunday, November 14, 2021, 06:11:28 AM PST, cm0561 @.***> wrote:
Thanks for the valuable contribution! I am trying to reproduce the results for cityscapes, I used the configuration file cityscapes_spnet101.yaml The validation mIoU can only reach to ~73.x %. my experiment runs on 4 GPUs, sync_bn is enabled.
The only thing I changed is the batchsize, i am using 12 sample in a batch.
Could you give me some hints?
I have the same problem ,can u give me your wechat number so we can discuss the problem, my wechat is lz_609492668
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.


Security enhancement: enable Validating Admission Policy for EKS-A clusters

What would you like to be added:
Validating Admission Policy has been alpha since 1.26 and it graduated to beta in Kubernetes 1.28.
We would like to start to use it on our EKS-A clusters.
Why is this needed:
To be able to use a Kubernetes native feature for admission controller. While there are existing 3rd party solutions like Kyverno, OPA/Gatekeeper, Datree, these tools need to be maintained by the platform admins and some of them have very steep learning curve (rego).
While Validating Admission Policy may not be a fit for all use cases (no external context during decision making) it is definitely provides enough flexibility to cover most of the use cases that a kubernetes platform require.

Hi, any updates or plans on this?  Since this KEP has graduated to GA in 1.30 we would like to use it as native OPA/Gatekeeper alternative


Added gradio example to docs

cc @osanseviero

Also ping @yvrjsharma

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

@osanseviero I replaced screenshots with LLaMA 2 chat since the model is more suitable for chat UI. I also added the Space embedding.


crashes when providing an existing path, because this is == and not !=

https://github.com/prisma/prisma-client-go/blob/7cd44d572f0fdc1e43c9a071ee1f9ee253dd76e7/engine/lifecycle.go#L98

Oh.. thanks! I added a fix via #767
Can you please check if it works?
go get github.com/prisma/prisma-client-go@steebchen-patch-2
# re-generate client
# re-try

This issue is fixed, however it still can't start.

After looking at the code, I think I found the proble. https://github.com/prisma/prisma-client-go/blob/f022062736fdd652f06336082e07bcaaf8838eb5/engine/lifecycle.go#L114 This check runs every time and it overwrites the query engine path.

Thanks for looking into this, this wasn't tested at all after the initial version and I broke it probably quite early along the way.. Lacking tests as well unfortunately
I pushed another update to fix what you said in the previous version, can you please try again?

I does work.

Nice. Thanks for testing :D

released in v0.16.2


Concept code<PHONE_NUMBER>000104 maps to wrong concept id in cohort JSON

I'm not sure, if this related to the reported scientific notation issue https://github.com/ohdsi-studies/Covid19CharacterizationCharybdis/issues/68.
In cohorts 126-141 there is a concept

"concept" : {
"CONCEPT_ID" : 3.731028e+07,
"CONCEPT_NAME" : "2019 novel coronavirus detected",
"STANDARD_CONCEPT" : "N",
"STANDARD_CONCEPT_CAPTION" : "Non-Standard",
"INVALID_REASON" : "V",
"INVALID_REASON_CAPTION" : "Valid",
"CONCEPT_CODE" : "1240581000000104",
"DOMAIN_ID" : "Measurement",
"VOCABULARY_ID" : "SNOMED",
"CONCEPT_CLASS_ID" : "Clinical Finding"
},

When importing these cohorts in Atlas, the concept ID is mapped to 37310280, which is actually the concept "High priority for SARS-CoV-2 (severe acute respiratory syndrome coronavirus 2) vaccination" not "2019 novel coronavirus detected". The correct concept ID would be 37310282.
Similar issue is with

"concept" : {
"CONCEPT_ID" : 3.731028e+07,
"CONCEPT_NAME" : "2019 novel coronavirus not detected",
"STANDARD_CONCEPT" : "N",
"STANDARD_CONCEPT_CAPTION" : "Non-Standard",
"INVALID_REASON" : "V",
"INVALID_REASON_CAPTION" : "Valid",
"CONCEPT_CODE" : "1240591000000102",
"DOMAIN_ID" : "Measurement",
"VOCABULARY_ID" : "SNOMED",
"CONCEPT_CLASS_ID" : "Clinical Finding"
},

Hi @ellisille - you have it right. This is the same issue as described in #68. I'll keep this issue open and close it out when I've updated the JSON accordingly. Thanks!


Decode .tar.gz archives using liblzma (via WebAssembly)

Fixes https://github.com/bazel-contrib/publish-to-bcr/issues/169

Tested locally with this script:
import fs from "node:fs";
import tar from "tar";

import { decompress } from "./dist/publish-to-bcr/infrastructure/xzdec/xzdec.js";

async function main() {
	fs.mkdirSync("../../extracted-m4", {recursive: true });
	let reader = fs.createReadStream("../../rules_m4-v0.2.3.tar.xz");
	let writer = tar.x({
		cwd: "../../extracted-m4"
	});
	decompress(reader, writer);
	return;
}

main()

curl -L -O https://github.com/jmillikin/rules_m4/releases/download/v0.2.3/rules_m4-v0.2.3.tar.xz
node18 tools/clean-dist-files.js && node18 node_modules/typescript/bin/tsc && node18 tools/copy-dist-files.js && (cd dist/publish-to-bcr/ && node18 ../../testxz.js )

Locally I get this error when I try to build.
dyld[37073]: Library not loaded: /opt/homebrew/opt/zstd/lib/libzstd.1.dylib
  Referenced from: <4C4C4449-5555-3144-A1D4-18BC03AC1DFB> /private/var/tmp/_bazel_derek/3b365bd722e54dd93dde1a0e900c70d0/external/toolchains_llvm~~llvm~llvm_toolchain_llvm/bin/clang-19
  Reason: tried: '/opt/homebrew/opt/zstd/lib/libzstd.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/zstd/lib/libzstd.1.dylib' (no such file), '/opt/homebrew/opt/zstd/lib/libzstd.1.dylib' (no such file)

Is there a way to bring in libzstd hermetically under Bazel?

Are you able to add a brief README in the xzdec folder that explains what this does?

Tested locally with this script:
import fs from "node:fs";
import tar from "tar";

import { decompress } from "./dist/publish-to-bcr/infrastructure/xzdec/xzdec.js";

async function main() {
	fs.mkdirSync("../../extracted-m4", {recursive: true });
	let reader = fs.createReadStream("../../rules_m4-v0.2.3.tar.xz");
	let writer = tar.x({
		cwd: "../../extracted-m4"
	});
	decompress(reader, writer);
	return;
}

main()

curl -L -O https://github.com/jmillikin/rules_m4/releases/download/v0.2.3/rules_m4-v0.2.3.tar.xz
node18 tools/clean-dist-files.js && node18 node_modules/typescript/bin/tsc && node18 tools/copy-dist-files.js && (cd dist/publish-to-bcr/ && node18 ../../testxz.js )

Once this is ready I can deploy and we can test a release of your ruleset. It would be nice if there was an e2e for this but I'm not expecting you to also write a compression function.

Looks some of the macOS builds of LLVM have a known packaging problem where they pick up a stray libzstd dynamic dependency from the build machine: https://github.com/llvm/llvm-project/issues/110070
% otool -L bazel-xzdec/external/toolchains_llvm~~llvm~llvm_toolchain_llvm/bin/clang-19
bazel-xzdec/external/toolchains_llvm~~llvm~llvm_toolchain_llvm/bin/clang-19:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.120.2)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)
	/opt/homebrew/opt/zstd/lib/libzstd.1.dylib (compatibility version 1.0.0, current version 1.5.6)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1700.255.5)

LLVM v18.1.8 and v19.1.2 both seem to be packaged correctly, but bazel-contrib/toolchains_llvm doesn't have checksums recorded for v19.1.2 yet, so I'll go with v18.

Are you able to add a brief README in the xzdec folder that explains what this does?

Done.


feat(deps-dev)!: upgrade @carbon/icons 11.10 -> 11.16

Bumps @carbon/icons to the latest minor version (net +68 icons).
This is a breaking change since<EMAIL_ADDRESS>renamed UndefinedGlyph to DiamondFillGlyph.

Nice catch. Dug into this; the generated build-info.json is inconsistent. The logic used to determine if an icon is a glyph is currently if it has "Glyph" in the module name. However, it seems that an icon may be categorized as a glyph, even if it doesn't have it in its name.


Suggestion: Adding FR Locale

I would to add french language to FlagWar.

Thank you for your submission! #83 has been merged, and will be available in the next release.


Make it easier to work with numbered and bulleted lists

A formatting button below the compose box can format the selected text
by bulleting or unbulleting the selected (partially or completely)
lines. The behaviour is modelled closely after how GitHub's bullet
list format button works.
A formatting button below the compose box can format the selected text
by numbering or unnumbering the selected (partially or completely)
lines. The behaviour is modelled closely after how GitHub's numbered
list format button works.
When the user is typing a numbered / bulleted list in the compose box,
on pressing Enter the list syntax will be inserted automatically on
a new line, and removed if Enter is pressed after an empty line.
Fixes: #20305.
Screenshots and screen captures:
Formatting buttons:
https://www.loom.com/share/e476156ec1cf4bac8ef641faaad8af92
Automatic insertion / removal of bulleting / numbering:
https://www.loom.com/share/a63aebbb2d9c464eb5b7a1140fcc364b
Self-review checklist

[X] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[X] Explains differences from previous plans (e.g., issue description).
[X] Highlights technical choices and bugs encountered.
[X] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[X] Each commit is a coherent idea.
[X] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[X] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[X] End-to-end functionality of buttons, interactions and flows.
[X] Corner cases, error conditions, and easily imagined bugs.

When i have nothing selected, and i click on one of the buttons it inserts a first bullet point or number, but it also selects it. This makes this feature hard to use, since i then can't just start typing, but instead first have to unselect the bullet point/number.

Unselecting is not that hard since one can just press the forward arrow and continue typing the point, but I do see how this is not ideal. Will try to fix this, thanks for pointing it out!

If i have already written some text, have the curser in a new line, and the click one of the buttons, it also inserts a new line before the bullet point/number (is this intended?)

Yes, adding a line before and after to separate the list from any text before and after is intended. This is identical to how markdown behaves in GitHub (you can try it here in the comments)

if i have a numbered list, select this and then click on the bullet points button, it inserts the bullet point, but does not remove the numbers, i think it would be cleaner and more useful, if this would be different (same with the other way around)

That would be a cool nice-to-have type of feature, but one can first click the numbering button to remove the numbers, then click the bulleting one to add bullets. GitHub too works this way, but I do see this as something we can improve as you suggested later, as it's not that necessary right now, in my opinion.

when i manually insert a bullet point by using a star (*) and then press enter, it inserts a dash (-) as a next bullet point. This is fine once the message is sent, but i think that this difference could confuse some users that don't know that there are multiple symbols that can be used to create bullet points

I agree. However, since we currently allow the user to use any of the 3 bullet symbols (-, *, +) together, this is not practically possible to implement until we enforce consistent usage of a single symbol in a list.

if i have multiple lines that are already formatted in some other way, and i want to convert this to a list by selecting it and pressing on one of the buttons it breaks the bold formatting (same with italic or both together). i think it would be good, if that would still work.

Again, I feel this is a nice-to-have feature that we might want to add later, but isn't crucial right now. Also as all this is modelled after GitHub (at least for an initial system), I tried to just emulate that as closely as possible and leave possible improvements for later.

I think that it could be nice if this would automatically indent the selected lines if the user presses on the tab button, so that they could create sub-lists like this

I really like this idea! Thanks for bringing it up, we can probably create an issue for this or new thread on CZO (don't need to wait for this to get merged as this issue is applicable nonetheless)

@juliaBichler01 Have incorporated your 1st suggestion: when cursor is on a blank line (and so obviously nothing is selected) and either button is clicked, the newly added bullet / numbering will not be selected but have the cursor after it.

The code looks alright to me, I also tested locally everything works as excepted (also tested the new change you added).
As @juliaBichler01 has covered almost all the various frontend edge cases, I don't think I have anything to add to it.

@alya This has been code buddy reviewed, and is ready for a look from you now!

This is awesome, thanks @N-Shar-ma !

For some reason I still see the highlighting behavior @juliaBichler01 mentioned in the first comment above, and I agree that we should get it fixed. I also noticed that when I press the bulleted/numbered list button on a line that already has a bullet/number, the bullet/number is correctly removed, but we also get the text highlighting issue.

I agree. However, since we currently allow the user to use any of the 3 bullet symbols (-, *, +) together, this is not practically possible to implement until we enforce consistent usage of a single symbol in a list.

Hm, I didn't quite follow that response. Could we insert the same type of bullet as the user put in the line above? I agree with the discussion above that this would be a better user experience.
Looks good otherwise!

For some reason I still see the highlighting behavior @juliaBichler01 mentioned in the first comment above, and I agree that we should get it fixed. I also noticed that when I press the bulleted/numbered list button on a line that already has a bullet/number, the bullet/number is correctly removed, but we also get the text highlighting issue.

Have completely fixed this now... So unless the user selects some text before using the formatting buttons, nothing is going to get selected after insertion / removal of the bullet / numbering.

Hm, I didn't quite follow that response.

What I meant by the response was, that a user is allowed to type out a list like the following using more than 1 kind of bullet symbols:

And it renders as one list with uniform bullets even though the symbols typed were different:

Because such a multi symbol bullet list is allowed, it may not be possible to guess which bullet symbol the user might have used next. This is what I meant by my previous response.
However, now I realise this point is mostly inconsequential, as it is not likely at all for a user to use multiple symbols in 1 list when the rendering isn't altered

Could we insert the same type of bullet as the user put in the line above?

Yes it is possible to detect the symbol used in the previous line and use that, and I've just added this feature!
@alya This should be ready for another look now that both your suggestions have been implemented!

Nice, looks good to me!
@amanagr it would be great if you could review this one.

@amanagr Have implemented your suggested changes, please let me know if there is anything else I can improve!

LGTM!

@timabbott This should be ready for a review from you now!

@juliaBichler01 , @amanagr and I have approved this PR.
@timabbott  please take a look!

I pushed back here with the following changes, largely commented on above:
diff --git a/web/src/compose_ui.js b/web/src/compose_ui.js
index<PHONE_NUMBER>..02e1b376d5 100644
--- a/web/src/compose_ui.js
+++ b/web/src/compose_ui.js
@@ -5,7 +5,7 @@ import autosize from "autosize";
 import $ from "jquery";
 import {insert, replace, set, wrapSelection} from "text-field-edit";

-import * as list_util from "./bulleted_numbered_list_util";
+import * as bulleted_numbered_list_util from "./bulleted_numbered_list_util";
 import * as common from "./common";
 import {$t} from "./i18n";
 import * as loading from "./loading";
@@ -412,13 +412,13 @@ export function format_text($textarea, type, inserted_content) {
         let mark;
         let strip_marking;
         if (type === "bulleted") {
-            is_marked = list_util.is_bulleted;
+            is_marked = bulleted_numbered_list_util.is_bulleted;
             mark = (line) => "- " + line;
-            strip_marking = list_util.strip_bullet;
+            strip_marking = bulleted_numbered_list_util.strip_bullet;
         } else {
-            is_marked = list_util.is_numbered;
+            is_marked = bulleted_numbered_list_util.is_numbered;
             mark = (line, i) => i + 1 + ". " + line;
-            strip_marking = list_util.strip_numbering;
+            strip_marking = bulleted_numbered_list_util.strip_numbering;
         }
         // Following behaviour is inspired from GitHub
         let {before_lines, selected_lines, after_lines} = section_off_selected_lines();
diff --git a/web/templates/compose_control_buttons_in_popover.hbs b/web/templates/compose_control_buttons_in_popover.hbs
index 6978105aac..0287c2e762 100644
--- a/web/templates/compose_control_buttons_in_popover.hbs
+++ b/web/templates/compose_control_buttons_in_popover.hbs
@@ -1,8 +1,8 @@

-
-
+
+

|

diff --git a/web/tests/compose_ui.test.js b/web/tests/compose_ui.test.js
index d4a626879d..f2918d1f7c 100644
--- a/web/tests/compose_ui.test.js
+++ b/web/tests/compose_ui.test.js
@@ -636,6 +636,92 @@ run_test("format_text", ({override}) => {
     compose_ui.format_text($textarea, "italic");
     assert.equal(set_text, "**abc**");
     assert.equal(wrap_selection_called, false);
+
+    // Test bulleted list addition
+    reset_state();
+    init_textarea("first_item\nsecond_item", {
+        start: 0,
+        end: 22,
+        text: "first_item\nsecond_item",
+        length: 22,
+    });
+    compose_ui.format_text($textarea, "bulleted");
+    assert.equal(set_text, "- first_item\n- second_item");
+    assert.equal(wrap_selection_called, false);
+
+    // Test bulleted list addition with newline at end
+    // TODO: It's not clear whether this is correct behavior.
+    reset_state();
+    init_textarea("first_item\nsecond_item\n", {
+        start: 0,
+        end: 23,
+        text: "first_item\nsecond_item\n",
+        length: 23,
+    });
+    compose_ui.format_text($textarea, "bulleted");
+    assert.equal(set_text, "- first_item\n- second_item\n- ");
+    assert.equal(wrap_selection_called, false);
+
+    // Test bulleted list removal
+    reset_state();
+    init_textarea("- first_item\n- second_item", {
+        start: 0,
+        end: 26,
+        text: "- first_item\n- second_item",
+        length: 26,
+    });
+    compose_ui.format_text($textarea, "bulleted");
+    assert.equal(set_text, "first_item\nsecond_item");
+    assert.equal(wrap_selection_called, false);
+
+    // Test bulleted list removal with *s
+    reset_state();
+    init_textarea("* first_item\n* second_item", {
+        start: 0,
+        end: 26,
+        text: "* first_item\n* second_item",
+        length: 26,
+    });
+    compose_ui.format_text($textarea, "bulleted");
+    assert.equal(set_text, "first_item\nsecond_item");
+    assert.equal(wrap_selection_called, false);
+
+    // Test numbered list toggling on
+    reset_state();
+    init_textarea("first_item\nsecond_item", {
+        start: 0,
+        end: 22,
+        text: "first_item\nsecond_item",
+        length: 22,
+    });
+    compose_ui.format_text($textarea, "numbered");
+    assert.equal(set_text, "1. first_item\n2. second_item");
+    assert.equal(wrap_selection_called, false);
+
+    // Test numbered list toggling off
+    reset_state();
+    init_textarea("1. first_item\n2. second_item", {
+        start: 0,
+        end: 28,
+        text: "1. first_item\n2. second_item",
+        length: 28,
+    });
+    compose_ui.format_text($textarea, "numbered");
+    assert.equal(set_text, "first_item\nsecond_item");
+    assert.equal(wrap_selection_called, false);
+
+    // Test numbered list toggling with newline at end
+    // TODO: It seems like this might be incorrect behavior
+    reset_state();
+    init_textarea("first_item\nsecond_item\n", {
+        start: 0,
+        end: 22,
+        text: "first_item\nsecond_item\n",
+        length: 22,
+    });
+    compose_ui.format_text($textarea, "numbered");
+    assert.equal(set_text, "1. first_item\n2. second_item\n3. ");
+    assert.equal(wrap_selection_called, false);
 });

 run_test("markdown_shortcuts", ({override_rewire}) => {

@N-Shar-ma thanks for all the work on this! I think the core logic works (though note a few TODOs in the tests I added that illustrate what I think are bugs worth fixing -- basically cases where your highlight of the end of a line incorrectly causes a bonus line to be created), but the undo-breaking behavior and breakpoints issues need attention before this can be integrated.

@timabbott I'll get to fixing the breakpoint issue in a bit, but have addressed all other comments, and wanted to clarify that formatting the last (or 1st) empty line when selected is intentional, as that is what GitHub does too (I just re-tested too here in the comments).
However, if we think this behaviour seems unintuitive, it should be easily fixable by trimming the selected text 1st, like we do for all other formatting except lists. @alya You might like to weigh in here

Hm, I would suggest adding a bullet on the first line, but not the last, perhaps? My motivation is that the first line has some highlighting even when no characters are selected (at least in my browser), but the last line does not.

That logic seems very sound to me! I think its a generally accepted convention to depict a newline character with a little highlight at the end of the 1st line, and not the start of the next line. Visually then, it makes sense to consider only the line before.
I'll change the code to trim the end but not the start of the selection to be formatted.

@timabbott Do you suggest writing tests for the last commit (automatic bulleting / numbering) as well?

I think I found a bug that this can add extra newlines when toggling on and off from this state:

Pushed a commit that you can squash in if you agree. I wasn't sure how to write a good test for it; in general I'm not sure the start/end/length parameters in the node tests are working correctly.
I think the only other outstanding issue is the issue  here: https://github.com/zulip/zulip/pull/22445#discussion_r1335256680. @karlstolley can you help figure out a path forward here? It would be nice to be able to integrate this but we can't merge a thing that leaves broken-looking breakpoints.

@timabbott Yet to look at the code changes you pushed, but wanted to let you know that always ensuring a blank line before and (especially after) a list was a conscious decision. Reason being that when there's any content after a list without a blank line in between, its rendered as a part of the last list item.

OK, that seems like a good reason -- can you drop my commit, and add a comment (and also a test with a comment documenting this detail in the test)?

@timabbott Done! Also squashed the tests into their respective feature commits.

OK so I think this is done except that it's blocked on https://github.com/zulip/zulip/pull/22445#discussion_r1335259881 -- i.e. avoiding there being a breakpoint where the compose "send" button runs off the edge of the compose area.

Looks good to me following d0b00bdeb01c7d0f66efb773eaff26b12d6f82c4, which fixes the blocker with fitting the buttons across all viewports. Nice work, @N-Shar-ma!
There's a test failure here in CI, but I can't reproduce in dev.

I added a few comments on the inline comments. All but one are tiny nits; the other needs a bit of a rewrite for clarity.

@karlstolley Have fixed all the comments!
By the way, the failing node coverage test is unrelated to this PR -- it originates from f7b633f5111f3152f94745736d587824dc9ac6a6 which moved a function into a file with previously 100% coverage, but didn't add a test for the new addition to it (FYI @amanagr)

There's definitely a narrow range of widths where it looks a bit off, especially in the message editing variant:

(Notice the "Send" button is sticking out to the right a bit).
I think given that this is to some extent a temporary solution (we are merging other formatting buttons and we've been actively working on redoing the message edit form), it's probably OK to merge this version and plan to address that in follow-ups.

It's interesting that while I do observe the problems in the editing mode, the send button is never even slightly displaced in the compose area for me :thinking: And I have all the same buttons visible as in the screenshot above


#2610: update useMenuTrigger.mdx to pass menuProps directly to MenuPo…

This change updates useMenuTrigger.mdx to resolve warning aria related errors.
Closes
#2610
✅ Pull Request Checklist:

[x] Included link to corresponding React Spectrum GitHub Issue.
[x] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[x] Filled out test instructions.
[x] Updated documentation (if it already exists for this component).
[x] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

Open the useMenuTrigger documentation page: http://localhost:1234/react-aria/useMenuTrigger.html
Scroll down to the example
Open dev tools console
Click the example to open the menu dropdown. Confirm that no warnings are sent to console.

🧢 Your Project:
N/A

retest

@frdclav see this comment to get the CLA working https://github.com/adobe/react-spectrum/pull/2648#issuecomment-988136589

Thanks for sticking with it @frdclav !


ping is not possible

i tried your fork because i need to ping tailscale devices from the HomeAssistantOS (I want to use remote home-assistant and i installed tailscale fork from you on both of my HassOS devices. but i cant ping one from the other.)
Can you help?

Please add to the config:
userspace_networking: false

By default there is no tailscale0 interface to route traffic outward, because it can cause problems, though there are solutions in this add-on to fix those problems, and they are working, so maybe the default will be false in the future.

this worked! thank you <3

I've also added a warning in the log when userspace networking is used. It will be part of the next version.

bashio::log.warning "The add-on uses userspace networking mode."
bashio::log.warning "If you need to access other clients on your tailnet from your Home Assistant instance,"
bashio::log.warning "disable userspace networking mode, that will create a "tailscale0" network interface on your host."
bashio::log.warning "Please check your configuration based on the add-on's Documentation under "Option: userspace_networking""

It is really good to see first time users' problems to find these weak points in the docs/code.


Website not working

Unfortunately, http://trilogy.js.org/ is not working.

Thanks - unfortunately it's due to JS.org having not accepted my domain request dns.js.org/#1003 quite yet. Once that PR merges the site should be online. I didn't expect there to be such a delay without a response.
Sorry for the inconvenience. In the meantime check out the docs folder in the repo for the raw markdown files. Just be aware that links to other parts of the docs won't work.

I guess it's working now, thanks ;)

Yep - it's been merged so we have go for liftoff! :rocket: Thanks for reporting!


Canvas installation failure

Hi all!
my npm installation fails when trying to add canvas dependency.
I get the following error:
<EMAIL_ADDRESS>install /Users/....
node-gyp rebuild

./util/has_lib.sh: line 31: pkg-config: command not found
gyp: Call to './util/has_lib.sh freetype' returned exit status 0 while in binding.gyp. while trying to load binding.gyp

Any clue?
Thanks a lot!

pls try https://github.com/HuddleEng/Resemble.js

Many thanks!


Ready for production build tests

Updated Package.json and webpack.config to optimize production build and bundle size.

Change looks good.

Change looks good.


Gha improvements

-Tests are only run, when needed on PR's.
The status check job needs to be added as the gateway for the PR's.
-Image Tag format has been updated.
-GHA Updates because of Node.js 12 deprecation in GHA

I think the branch protection and status checks needs to be updated before merging.

@mgmgwi @pSchlarb @Echsecutor please review

@Echsecutor @mgmgwi please review


Question : Hal to use RF on STM32WB55

Hello
I am starting a new project, I investigate to find the most adequat Hal crate for the MCU (STM32WB55).  I would to start an application that send data via USB on a first time, and send data by BLE in a second time thanks to stm32wb55 MCU. I am using the STM32WB55 Nucleo board.
Unfortunatly I am a litlle bit frustrated because hals seems be incomplete or incompatible each together. The hal stm32-hal2 seems to me written pretty good, with examples and the repository is very often updated, but this hal doesn’t contains any RF part of stm32WB55. I follow the hal advised for RF usage « stm32wb_hal » but some examples for periph usages are out of dated, so it is a little bit difficult to me to use this crate.
It’s not a good idea to try to use the two hal in the same time because type mismatch or borroing data like RCC are difficult to manage.
Do you have any advise ? Rust hal are not mature enought for the mcu stm32wb55 ?
Thank you by advance for yours answsers

Hi! Unfortunately, I think I'm providing the answer you don't want to hear: This library has no RF functionality. :( I understand that this places a severe limit on its utility on that MCU. It will work for most of the non-RF functionality on your MCU. I suspect you're correct that there are no mature rust HALs that handle the WB's RF functionality. In general, Rust has poor support for RF.
I'm not sure what the best path is: Perhaps the Rubble library can help? Perhaps this HAL (or the other one you looked at) could be patched to better use the hardware semaphores ST provides to communicate between the cores? I believe you need to flash proprietary ST firmware to the RF core. Then you would (somehow?) communicate between the main core running Rust with the other core; I'm not sure how though.

Update: Apparently I tried writing HSEM and IPCC modules at some point: https://github.com/David-OConnor/stm32-hal/blob/main/src/hsem.rs https://github.com/David-OConnor/stm32-hal/blob/main/src/ipcc.rs
These are the hardware periphs for communicating between cores. They are incomplete and untested.

Hi David,
Thank you for your quick reply.
Yes I haven’t notice that your crate have already ipcc and mailbox implementation (I was looking for in examples when I search how implement a new peripheral)
Your peripherals seems be interesting, may be it could be possible to integrate the some content of RF functionality from repo stm32wb55-hal (https://github.com/eupn/stm32wb-hal) into this crate if necessary. I don’t know RF stacks, on BLE side I only want/need an API to open an serial communication over BLE.
I was asking which hal use to begin project to avoid to change hal in middle of developpement, that is very auwfull.
First, I will start my project with your hal, I will see how to integrate RF BLE functionnality , if I am able to do it.
Thank you for your time


Add news source for some reputable Android news and other providers via RSS

eg. Android Police (http://feeds.feedburner.com/AndroidPolice)
medium.com is also a good place to get feed.
Note: Since its a blogging platform, use atom or RSS feed.
This depends on #7 & #48

Looks like https://github.com/Pkmmte/PkRSS is a good library and used in https://github.com/Pkmmte/TechDissected
Will investigate this lib further.


Compile error with SASS Lists and Maps (node-sass 3.13.0)

See http://stackoverflow.com/questions/41096961/ember-cli-scss-compile-error-with-sass-lists-and-maps please.
Can someone help?

Seems like libsass can't compile MDBootstrap at all ...


Permanently disable Mauve subtest gnu.testlet.java.lang.Math.sin

Resolves https://github.com/AdoptOpenJDK/openjdk-systemtest/issues/272
Signed-off-by<EMAIL_ADDRESS><EMAIL_ADDRESS>

Any reason for permanently instead of temporarily disable the test?

The goal is to make the mauve load tests stable. It was decided a few months ago that we should disable the any sub-tests that intermittently fail from the mauve load as we are not interested in fixing sub-test failures but want to focus on the stress testing performed by the Mauve load.
This exclude is just another one of a series of Mauve sub-test excludes done in the previous weeks.

Great, thanks for details.


remove aws cli zip in same layer as install

Remove the layer where aws cli zip is removed and include that in the aws install layer.

exactly.
it will decrease the image size


Arm machines do not have /etc/system-release use /etc/os-release

Arm machines do not have /etc/system-release, but do have /etc/os-release, default to NAME & VERSION from that if no system-release
Signed-off-by: Andrew Leonard<EMAIL_ADDRESS>

run tests