Update fail (12.47.1 -> 12.50.0)

💡 Summary
I wanted to update my public instance but impossible, the installation stops.
I did the same update on my other server which is exactly the same (Hetzner server), with 2go of RAM and no problem. I don't understand, I'm not an expert either ...
☹ Actual Behavior
yarn run v1.22.5
$ webpack && gulp build
37% building 1/2 entries 2458/2518 dependencies 449/1400 modulesBrowserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
92% sealing asset processing TerserPlugin
<--- Last few GCs --->

[2436:0x62ff840]   205035 ms: Mark-sweep 932.3 (985.4) -> 924.4 (985.6) MB, 2424.6 / 0.0 ms  (average mu = 0.102, current mu = 0.027) allocation failure scavenge might not succeed
[2436:0x62ff840]   207863 ms: Mark-sweep 933.0 (986.0) -> 925.1 (986.1) MB, 2746.9 / 0.0 ms  (average mu = 0.064, current mu = 0.029) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xa03520 node::Abort() [webpack]
 2: 0x94e471 node::FatalError(char const*, char const*) [webpack]
 3: 0xb7763e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [webpack]
 4: 0xb779b7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [webpack]
 5: 0xd32245  [webpack]
 6: 0xd32dcf  [webpack]
 7: 0xd40e5b v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [webpack]
 8: 0xd44a1c v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [webpack]
 9: 0xd130fb v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [webpack]
10: 0x105909f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [webpack]
11: 0x13ff079  [webpack]
Aborted
error Command failed with exit code 134.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I also typed the command: npx browserslist@latest --update-db and restarted the update but this message still appears.
📌 Environment

Debian 10
NodeJS 14.x ( tested with NodjS 12.x, same error)
Yarn 1.22.5

@kazukyakayashi try running NODE_OPTIONS=--max_old_space_size=2048 and then go through the entire update process again

I tested but without any result, I tried to put this option everywhere it was possible to put it, and even putting even less than 2048.
So I increased the server's RAM, and it works, but I still don't understand why on one of the two servers I don't have this problem.
Thanks for the help


CI/CD pipeline to deploy govwifi-dev-docs to PaaS

See individual commits.
And https://cd.gds-reliability.engineering/teams/govwifi/pipelines/dev-docs/jobs/build/builds/9 for a successful run and see status in this PR

Looks good. The pipeline fails for two reasons though.

It's not on master, so self updating pipeline doesn't know where to look - that's fine, safe to be ignored.
Not all of the credentials are not being fed into concourse. Meaning the deploy job cannot succeed.

Would be good to see the thing run, before merging :)

Oh, I thought these were shared between pipelines. Fixing it

They can be, but the path to the secret will need to be like */govwifi not */govwifi/pipeline.


Coverity 1534725: Uninitialized scalar variable

Coverity complaining col._row_size not initialized but that's only when col._type hits default case (which comment implies shouldn't happen). Can also add col._row_size = 0 to just default case

Cherry-picked to v10.0.x


Possibility to reset initial pristine values

I reuse the same Formsy Form for multiple entities. Depends on which entity is selected the form should populated with different data. It works almost fine, one problem I see is that when the user reset form it reset's to the values which was populated to the form at very first.

hm no idea?

I have the same need but for a different use case. I'd like to reset the pristine values after the user saves the data to the server. In this scenario, the pristine state is the last saved state, not the initial state.


Test failing due to wrong test file path

Test are failing locally for me for the PadTargetsIntegrationTest. The "targets.bed" file directory is wrong... it should be .../broadinstitute/hellbender/tools/exome/targets.bed but currently the "hellbender" subdirectory is omitted. Please don't add an additional targets.bed file, just use the one in existence (I am assuming that the content would be the same).

@vruano Fixed in the ACS Model pull request that was just merged a minute ago.

Cool thanks.


Missing reference in "Create an invoices list page" section

Create an invoices list page

Go to the account management landing page (My Account) that you created earlier.
In the properties pane for the Account invoices tile module, under Links, configure a link to the invoices list page that you just created.
Select Save, select Finish editing to check in the page, and then select Publish to publish it.

The above part of these instructions are referencing a module that wasn't added to the account management landing page in the earlier steps. It should probably be added to the earlier steps?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

Closed as won't fix.


Deprecation Warning: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0.

Recommendation: math.div($spacing-padding-1, 2) or calc($spacing-padding-1 / 2)

More info and automated migrator: https://sass-lang.com/d/slash-div

    ╷
121 │       margin-left: px-to-rem($spacing-padding-1 / 2);
    │                              ^^^^^^^^^^^^^^^^^^^^^^
    ╵
    ../styles/scss/components/_formcontrol.scss 121:30  @use
    ../styles/scss/components/index.scss 16:1           @use
    ../styles/scss/monorepo.scss 13:1                   @import
    .storybook/styles.scss 2:9                          root stylesheet

@Shashika6 do you still see this when building the project? I think it may have been fixed and that may be we can close this.

Just built the project @justintemps this issue seems to be fixed.


Please add an option to disable tree-shaking.

Feature request

What is the expected behavior?
I want to a option can disable tree-shaking. I cant find related option in official doc.
What is motivation or use case for adding/changing the behavior?
Home
example.html
function navigateTo() { }
example.js
the navigateTo function which not used by other function will be remove after tree-shaking but I dont want this happen.
How should this be implemented in your opinion?
Add a treeShaking:false option in webpack config file.
Are you willing to work on this yourself?
no

@huyaxiong were you able to find a solution for this? I'm currently having the same issue

I have the exact same problem with JS simple router, I wrote a code like navigateTo() and this code disappear on bundle.js minified file.
The workaround I found was send to window scope all declared functions.
function navigateTo(){ ... }

window.navigateTo = navigateTo;

Which resolve another problem: when you minified and uglify this functions, they lose the global scope, and onclick="navigateTo()" will fail because navigateTo was send to another scope.
using window.navigateTo = navigateTo makes the function be used and the function send to window scope (which allows html onEvent attributes be used)

You should not do it


Fixup ColorRect and TextureRect renames

See https://github.com/godotengine/godot/commit/da477b76a98ee7ca4ac16773d3baf1299e053da7.
Stumbled upon this while researching stuff around godotengine/godot-proposals#1687.
AudioStreamEditorPlugin depends on ColorRect.

Thanks!


__esModule is not getting set in the built output

Due to some particulars of how your project is built,
Object.defineProperty(exports, "__esModule", { value: true });
is not getting set in the built output. exports is being overwritten with the variable fetch.
This create some problems with systems that inspect the __esModule property.

I believe we are currently doing the right thing: where lib/index.js, the transpiled version, contains the __esModule property.
Do let us know if I am missing something :)

However, this line
module.exports = exports = fetch; also gets set which overrides
the previous line Object.defineProperty(exports, '__esModule', { value: true });


Support for --tags to include/exclude tests based on some optional tagging

:warning:  Before you read
the suggested tagging API has changed since the initial proposal, see new comments further down

As discussed in #928, this is a tentative PR for tagging support in the bdd interface. I hope this is not against the guidelines (PR for a new feature), but it will be easier to discuss what's feasible with some visibility on the code changes.

you can optionally pass an array of tags as the first argument to describe and it
by default, all tests always run
you can specify --tags to run a subset of the tests
tests that don't match the filter are marked as pending

describe('my service', function() {
  it('test 1', function() {});
  describe(['integration'], 'backend connectivity', function() {
    describe(['fast'], 'quick tests', function() {
      it('test 2', function() {});
    });
    it(['slow'], 'test 3', function() {});
  });
});

mocha runs everything
mocha --tags "not:integration" runs test 1
mocha --tags "is:integration" runs tests 2 and 3
mocha --tags "is:integration not:slow" runs test 2

You can also programmatically update the filter with
if (/* out of business hours */) {
  require('mocha').options.tags.add('not:backend');
}

If this looks good, happy to look into how to unit test & document it.
Cheers

Hi, any news about this?
It also ties in with other PRs in progress (e.g. #1591) because it puts all the filtering logic together, which is nice IMHO, but might need rework since it's been ~5 months.

Hi @boneskull, what's your thoughts? I think this PR will help, refactoring all the filtering to be done in 1 place. Also just keen to get some feedback to know if I should get my hopes up about tagging tests :smile: (which I still believe adds a lot of value on large projects that need to reliably run selected tests on different environments).

I'm very interested to see where this goes and would like to see it merged.
I'm implementing a REST testing framework which invokes mocha programmatically under node/io, and I was going to inject my own runner/interface to implement real tagging in mocha anyway, but now that the work has already been done for me and has hopes of becoming official, I'll wait to see what happens.
--grep is definitely not enough in massive corporate environments, where my work is happening.

Hi @noorus, curious to hear about your REST framework when it's available!
Since you also looked at tagging, does the current suggestion of --tags "unit,integration" --skip-tags "redis,ie8,slow" make sense to you? Or do you see a need for the more complex + syntax described in #1475? Both suggestions would be exposed on the runner.filter object anyway, so you should be able to use them programmatically.

I don't really have strong feelings about the CLI in that regard, but I kinda want to think that if you find yourself needing the complex +-, syntax just to run the right tests, then you might have been overcomplicating your tags in the first place :stuck_out_tongue:
So I think I'd personally go with the simpler syntax which is more intuitive, and might even encourage good tagging practices as such.

Good point :+1: I'm happy to rebase this on master, if there's a chance of it being merged.

I really hope the maintainers choose to do the right thing and adopt it soon, since the neato this.tags syntax won't even introduce any breaking changes. :+1:

@boneskull @travisjeffery did a quick review, and afaik am concerned this would make a nice feature. I'd understand if you consider the bloat and overlap with grep to be a reason not to merge though, but let's at least make decision after all the work @rprieto put in ;)

Thanks @jbnicolai :)

Sooo.. About this lil' PR here, how about we just slip it into ol' master trunk over there? Any naysayers?

I'll need to look at this again, but I'm gonna catch some zzz's

Hey guys, still very much hoping for this merge to happen in master!
Is there anything I could do to further this particular development?

I'm a big supporter of this, but I was wondering:  Will the reporters output the tags in the desired space?
For example, with the XUnit reporter, in the  element, having an attribute of "flags='x,y,z'"

I don't see why not :) The tags are a property of a Suite's context so reporters should be able to query/process/report them.

:+1: for unambiguously splitting tests up with tags

Quick update to say I ran into this: http://engineering.sharethrough.com/blog/2013/08/10/greater-test-control-with-rspecs-tag-filters/. It seems RSpec uses a very similar system to what's being proposed here, for what it's worth :)

@rprieto Did you finish implementing the tagging for all interfaces? Or do you need help cleaning up the merge conflicts, etc?
I'm really interested in making this inherent. Let me know if I can help at all.

Hi @davidpaulhunt! In this PR tagging is implemented as part of the core, mostly in mocha.js, context.js and a new filter.js. I've only done the BDD interface, but it's really just a few lines of code to call into the core, so I believe other interfaces would be very easy.
However you're right that it's been over a year and it would need a massive rebasing. I'm happy to put in the work to rebase/cleanup, if there's an indication it will be merged. Hope that doesn't come across badly, I just think we can already see the API / usage / implementation before going through any rebase. Maybe an update from @boneskull / @danielstjules / @jbnicolai?

@rprieto Thanks for responding. I'm also willing to put in any work that's needed of me. It'd be great to have this feature out of the box and not as a hack locally.
@danielstjules seems to be more interested if the functionality is successfully implemented across all interfaces. I think at that point, it's safe to assume we could get complete consideration for merging. Of course, I don't want to speak for him, that's just my impression from his response to my PR.
If we get an update or at least a couple of us committed to the feature, we should do as you suggested and work from #1830 via @noorus (again thanks!). I have my fingers crossed we can get momentum!

Any hope of this going through? I'd be happy to help test if needed. We're at a point in our project where the ability to run specific subsets of tests will be very valuable (e.g. has X tag but not Y tag)

+1
I just spent ages trying to work out why seemingly random extra tests were being run outside a .only before I discovered #1481. Tags would completely sidestep that issue.

+1, getting this in would be a huge benefit to my testing suite!

+1

Do we have a way in this configuration to run all the tests without a tag and all the tests with a particular tag?
I could run multiple passes of Mocha but that could potentially change the test behavior (it shouldn't, but that's very different from "it won't")

to run all the tests without a tag

If you mean tests without a particular tag, then yes you can do --tags this --skip-tags that. If you mean tests without any tags, then unfortunately the PR as it stands doesn't support it. There's no way to refer to untagged tests specifically for the moment.

Besides things like 'slow', 'fast', 'phantomjs-broken', the next logical place to need tags is for feature toggles.
Feature toggles are not particularly interesting until you have at least 1 of them, and to have one toggle you need to mark your tests as unaffected by the toggle, only working when disabled, or only working when enabled.
To run a full tests suite you need to run all of the unaffected tests and the affected tests that apply to the current configuration.  That would be group A and B, or A and C depending on which way it's configured at present.
Now add a second flag, and you see the --skip-tags flag doesn't scale very well without the catchall.  In order to run all of the unaffected tests you have to update your --skip-tags arguments to include all feature toggles in the project.
If there were a special case for 'none' (empty string perhaps?) then you could run mocha twice to get any combination of tests to run.  That may be good enough, but as hard as we try, tests do tend to behave differently when executed in a different order.

I'd love to see this.

@MatthewRalston please use the thumbs up emoji reaction rather than spamming people with a message like that

Hi @jcrben, any thoughts about this PR? Or more specifically, what do you think is missing so there can be a merge/close decision?

@rprieto I'm not a team member. It looks like @dasilvacontin who is a member gave me a reaction, tho, so maybe we should ask him 😉
looks like he was waiting on word from @boneskull who never got around to it. @travisjeffery wanted to stick with grep but grep really doesn't handle this in a truly clean way

Please rebase since we added a linter to CI recently. 👌

Also, since we are now under the JS Foundation, you'll need to sign the JS Foundation CLA before this gets merged. Just pointing it out, in case it's missed between the other CI checks. :)

Hey folks,
I'm just a regular Mocha user, and I don't feel strongly one way or the other about this feature.
I just wanted to understand: it seems all the mentions of --grep here are talking about fuzzy searching over titles, which I agree is imprecise. But what we do — which we learned straight from the Mocha wiki — is include tags (by convention) in the title, and search for exactly those tags.
E.g. examples from our real-world code:
// This test suite relies on hitting third-party services,
// so skip it if we're running offline.
describe('Foo bar #skipoffline', function () {

    // This individual test can be pretty slow,
    // because we have to wait for yada yada,
    // so skip it if we're running fast tests only.
    it('lorem ipsum #skipfast', ...);

});

Then we can do e.g. --grep '#skipoffline' --invert, and combine multiple tags just like normal regex, e.g. --grep '#skipoffline|#skipfast' --invert. We have ~5 such tags, including #skipci (modeled after Travis's [skip ci] commit message syntax).
Is the difference between --grep like this, and this PR, that the filtering is more powerful? E.g. I can run tests tagged "X and Y", or "X or Y", or "X but not Y"? I think --grep can only do the middle one.
Thanks!

Funny story: I added a feature today where I found it much easier to use a conditional everywhere (with this.pending = true if the conditional was true) rather than any #skipfoo tag.
Specifically, I could have done --grep '#skipfoo' --invert, but this is a cross-cutting concern, and doing this in a generic way, while still allowing helpers/wrappers around Mocha for business concerns, would have been challenging and error-prone.
So +1 to this feature now. =) Thanks!

I wonder if there is an opportunity to do something more along the lines of RSpec's "User-defined metadata" tooling: https://www.relishapp.com/rspec/rspec-core/docs/metadata/user-defined-metadata. It seems like tags provide a fair amount of power, but have some limitations:

Tags seem to be additive only - that is, a nested context can add a tag, but can't remove one that was applied by its parent. While this may seem convoluted, I can imagine scenarios where (for instance) shared behaviors may want to remove a "slow" tag.

Allowing more structured metadata opens up new extension options. As an example, writing tests for an API requiring an API key to authenticate could make use of something like this:
// common test suite setup
beforeEach(function () {
  let auth = this.test.meta.authenticatedWith || {};
  if (auth.apiKey) {
    httpClient.defaults({ headers: {'Authorization': 'APIKEY ' + auth.apiKey }});
  }
});

// tests:
describe("POST /widgets", function () {
  it("fails(401 unauthorized)", ...);
  context("logged in", { authenticatedWith: { apiKey: '123' }}, function () {
    it('succeeds', ...)
  });
});

that could be useful, but rspec doesn't seem to have any filtering functionality w the metadata (though i only skimmed). "tags" are absolutely for filtering, and expanding that to user-defined metadata isn't too bad--except we'd need to get clever on the CLI end.

wrong button. anyway this is on hold until we hammer down the roadmap. we will have a forum for discussion about what goes in the roadmap.

+1

this would be a really nice feature to have, we are in need to run tests based on inverted form factor '@not_mobile', '@not_tablet' for test that don't support all form factors and also other tags, like slow/fast etc.
I have tried to use grep but can't find any good solution to achieve what I wan't to do above.


Full Screen Lyrics.

How you think the new feature/improvement would be helpful, or what problem you think it would solve

Sometimes I want to read the lyrics better, show other person, do karaoke etc I want to make it bigger without touching my configuration.
Double click on empty space of foo_openlyrics plugin should trigger this. And have option to open in Full Screen or Windowed by default. Also remember window size.
Use F11 to switch between FullScreen and Windowed mode.

This sounds like a job for a separate UI plugin ("Temporarily fullscreen any panel" which, off the top of my head, sounds entirely feasible) than for openlyrics specifically, and since you do always have the option of editing your layout to achieve this (meaning it would only be a quality-of-life improvement for a niche use-case), I don't think so.
Another alternative to modifying the layout would be to have your primary layout saved to file, along with a layout will lyrics fullscreen, and then just load that when you want to have them on display (for karaoke or whatever). Obviously this is more effort than if openlyrics could do it for you, but its an alternative.

Double click to full screen is a common behavior in foobar2000 components

@Rexadev As you implied in the other ticket, this is effectively an extension of #41. The changes you want are much less likely to be implemented if you try to motivate them with an unsubstantiated claim on an issue that's been closed for months. If you think fullscreening is an important part of the feature, then I suggest mentioning it in that issue. :)

My use case is karaeoke-ing
@jacquesh


update python 3 image to python 3.7

The current python version in the python3action runtime is 3.6.

@csantanapr @sciabarra should we do this or adopt action loop which I think is 3.7 already?

actionloop all the things !!

done since a while


Puppeteer saved PNG is NOT transparent

Steps to reproduce
Tell us about your environment:

Puppeteer version: 1.13.0
Platform / OS version:  macOS Mojave
URLs (if applicable):
Node.js version: v8.4.0

What steps will reproduce the problem?
I am using Puppeteer to screen capture an HTML element with ID name.
The HTML element is with border-radius: 50px and I set Puppeteer with omitBackground: true.
 // bacgrkound normal defult white

I am the element!!!

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('http://localhost:3000', {"waitUntil" : "networkidle0"});
  const elements = await page.$('#element');
  await elements.screenshot({path: 'example.png', omitBackground: true});

  await browser.close();
})();

What is the expected result?
Transparent Rounded PNG
What happens instead?
The Saved PNG result gave me is a WHITE background, looks like it captured the BODY default WHITE background.
Thanks!

update:
ADDING page.evaluate before screenshot could work, but how we just have one STRING feature to turn it ON & OFF.
await page.evaluate(() => document.body.style.background = 'transparent');
await elements.screenshot({path: 'example.png', omitBackground: true});

credit to Thomas Dondorf: https://stackoverflow.com/questions/55105958/puppeteer-saved-png-is-not-transparent/#answer-55107065

@weilinzung It's hard to determine what's an element's background: it might be some other element that casts wrong color.
The omitBackground option omits default browser background rather than the background of the "element" - so this works as expected.

In my case, it's bootstrap specifying background of body to be white, so omitBackground didn't work.

I could only get my background to be transparent by using the !important override in my css:
body {
  background: transparent !important;
}

Once I'd done this, I just captured a screenshot with:
await elements.screenshot({ path: 'example.png', omitBackground: true });


Add an extension for Clapeyron support

Adding a Substance is a pain in the ... since it requires a lot of information. Clapeyron.jl has a database, internally, for a lot of substances and also has a robust system for modeling all the things a gas dispersion model would need.
Instead of making Clapeyron a strict requirement, it would probably be better to just make a package extension that extends Substance so that it can take a Clapeyron model as an input, and extends PropertyCorrelation so that the methods for retrieving substance properties point at the corresponding Clapeyron method.
I don't imagine this will be difficult other than I don't really know how to create a package extension :sweat_smile:

I opted to create an AbstractSubstance type instead, which is much cleaner.
In a Package Extension, any new type of substance is a subtype of AbstractSubstance and overloads the internal property getters, like GasDispersion._vapor_pressure(). That should be pretty much it.
Dispersion models should not be referring to the internals of a Substance basically ever, they should be using those property functions instead.


Escola Prof Magdalena Sanseverino Grosso

@viinynunes I have to close this request without merging, because you requested to add a non-existent domain to this repository: Host magdalena.sp.gov.br not found: 3(NXDOMAIN) Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for understanding!


Add Older Documentation Version Websites for Released Branches

What would you like to be added:
part of #215
Why is this needed:
Currently, we are considering implementing a version menu in our documentation to enable users to switch to their desired document version.
The method for adding a version menu is detailed in the Docsy documentation on versioning:
(see https://www.docsy.dev/docs/adding-content/versioning/)

version_menu = "Releases"

# Add your release versions here
[[params.versions]]
  version = "master"
  url = "https://kurator.dev"

[[params.versions]]
  version = "v0.5"
  url = "https://v0-5.kurator.dev"

[[params.versions]]
  version = "v0.4"
  url = "https://v0-4.kurator.dev"

However, we face a challenge as the older version websites (such as https://v0-4.kurator.dev/) do not currently exist. Therefore, it is necessary to create and add websites for the older documentation versions, aligning with each released branch.
This concept is inspired by the versioning system used on the  https://github.com/kubeflow/website

So if we add subdomain like https://v0-4.kurator.dev/, then it works?

So if we add subdomain like https://v0-4.kurator.dev/, then it works?

I think so.
This version menu just offer a button to switch to another subdomain. If we already have the orlder version site,  user can switch to their desired document version in this way.


[ aws-xray-sdk-fastify] Typo of FastityLoggerInstance AND aws-sdk dependency absent

After installing aws-xray-sdk-fastify^3.5.0 and using it as plugin, I got a few errors and below are my queries for the same

There's no attribute FastityLoggerInstance in fastify instead it should have been FastifyLoggerInstance [ aws-xray-sdk-fastify/lib/plugin.d.ts ]?

aws-sdk dependency is not present [ aws-xray-sdk-fastify/lib/private/configure-aws-x-ray-sync.js ]

Hi @vaibhavgupta-bst, thank you for creating this issue and bringing this to our attention! I have created a PR (#589) to fix the typo you pointed out in FastifyLoggerInstance.
Regarding the second issue you mentioned, we take a direct dependency on the aws-sdk package in the root package.json, but not in the sub-packages contained within this SDK. Since the direct dependency is in the root package.json, all packages contained within this monorepo will pull their dependencies from there and add on the dependencies in their respective package.json. You'll notice that's also the case for the aws-xray-sdk-core package, which contains all the AWS SDK and HTTP instrumentation logic (AWSXRay.captureAWS function).


Don't label every cross section

XS should be labeled every 10th xs on the XS Longitudinal Profile Plot.

Here is an example of the problem:

Added a label_freq parameter to all level 1 and 2 graphs and maps.


Getting reference to the handsontable object

Hi.
If I use the standard handsontable library using the below code
var handsontable_object = new Handsontable(.....)
I get a reference to the handontable object.
The advantage is that I can call a lot of utility function on this object like
handsontable_object.selectCell(row,column)
How to achieve the same with react-handsontable wrapper. as I could not get anyway of getting reference to the handsontable object.

+1

ref={hot => this.refHotTable}

ref={ht => this.refHotTable = ht}


Distributed Partd

Problem
I was chatting with some RAPIDS devs today (@kkraus14 @quasiben @randerzander @jakirkham @madsbk @pentschev and others ) and they were generally concerned about the scheduling overhead of dataframe merges/set_index operations (anything that uses shuffle).  There is an effort to improve scheduling performance generally, but there is also an option to try to rethink how we handle shuffling in dataframes, and maybe other similar operations in the future as well (like array rechunking in extreme situations).
The currrent "tasks" based shuffling method uses  O(n log(n)) tasks and log(n) full-dataset communications.  This is fine for ~100 partitions, but becomes challenging once you get to 1000 partition datasets.  We also have a separate solution around partd, which does things in O(n) tasks, by buffering small shards of the data and using disk as a global communication store.  Partd as written doesn't work in a distributed fashion, but we might think about how to do some similar approach in a distributed fashion.
DHT
In principle, building some sort of distributed hash table (DHT) like thing out of Dask parts isn't hard (actors, pubsub, etc, are all good examples of similar systems that took a couple of days to build).  What is hard is making it resilient.  For this we might look to a mixture solution between some peer-to-peer system, and a centralized SchedulerPlugin.  Here is a rough design.
We run tasks on each partition of the to-be-shuffled dataframe that split that partition into pieces, and put into some local splitting service.  The first task on a machine probably creates the service (we use a local thread-based-lock to coordinate between multiple tasks on the same machine).  That service splits things apart, stores them in local buffers, and periodically sends batches them to peers.
How does it learn what peers it should send things to?  Probably it has to check in with the scheduler, which will still act as centralized control here, but won't track every individual piece of data. Maybe these things check in with the scheduler, the scheduler alerts everyone else about what is going on, and the things push data around in a way similar to a distributed hash table (DHT).  (there is lots of prior art here and algorithms to steal).
  There is some excess communication here because we aren't thinking about locality for the Dask-DHT nodes, but for now let's just allow that as an allowable cost (my apologies).
So great, we get by with 2*n tasks, and probably two full communications.  Not great, but it's probably better than what we have now for large shuffle computations.
What can go wrong
So what happens if a worker goes down during execution?  We haven't replicated data, and the task that created that chunk of data is gone, so we've lost some things.  We can still recreate and rerun that task though, we just need to tell the scheduler to do so.  So in order to get resilience, we register a SchedulerPlugin that calls some custom code whenever a worker goes down.  We know which workers processed which tasks, so we rerun those tasks.  The other DHT nodes will get some duplicate data unfortunately, so they'll probably have to track which tasks they've seen, and know to discard any message that comes from the same task twice.
Nice things
So we get a nice combination here of resilience provided by the centralized scheduler, as well as low overhead provided by decentralized execution.
If we can create this as a more general purpose DHT solution then I suspect that people will find other uses for it other than just dataframe all-to-all shuffling.

For dataframes in particular, we would make another shuffle method around this (alongside "disk" and "tasks") that we would only use with the distributed scheduler.  It would be opt-in at first but if it performs well and robustly then it might take over as default in the future.

@mrocklin thanks for taking the time to write this up. It's much appreciated. I've made sure to circulate this to all of the relevant individuals within NVIDIA to make sure people read this and chime in their thoughts and concerns.

To be clear, this is a pretty early dump of some thoughts.  It's intended
to be the start of a conversation, not a finished proposal.
On Fri, May 1, 2020, 8:37 PM Keith Kraus<EMAIL_ADDRESS>wrote:

@mrocklin https://github.com/mrocklin thanks for taking the time to
write this up. It's much appreciated. I've made sure to circulate this to
all of the relevant individuals within NVIDIA to make sure people read this
and chime in their thoughts and concerns.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/6164#issuecomment-622662653, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKZTCVYRNJ5EYYWCNSRCLRPOIOPANCNFSM4MXPXLOQ
.

@mrocklin, the O(n log(n)) tasks and log(n) full-dataset communications is when using stages right? Without staging, it is O(n**2) tasks and 1 full-dataset communications right?
Also, can we avoid the barrier somehow? One of the lessons we learned when implementing dataframe merges using explicts-comms was that the implicit barrier killed the overall performance and increased the memory usage significantly even thought the merge itself was much faster (@rjzamora please correct me if I am wrong).
Which is something we also have to keep in mind when exploring approaches that uses external communication libraries.

the O(n log(n)) tasks and log(n) full-dataset communications is when using stages right? Without staging, it is O(n**2) tasks and 1 full-dataset communications right?

Correct, up to about n==32 I think.  After that I think we start staging.  (I could have the numbers wrong here.  So when we get to partition counts like 1000 we end up with task counts in the 10000's to 100,000, but not 1,000,000

Also, can we avoid the barrier somehow? One of the lessons we learned when implementing dataframe merges using explicts-comms was that the implicit barrier killed the overall performance and increased the memory usage significantly even thought the merge itself was much faster (@rjzamora please correct me if I am wrong).

The all-to-all nature means, I think, that computation after the merge is unlikely to start until 90% of the merge computation is done no matter what we do.  However, we can certainly do data movement during that time.  I don't think that I've seen a solution that allows for shuffling as part of a streaming workflow.
I could be wrong here though.  It sounds like you have real-world experience that says otherwise.

The all-to-all nature means, I think, that computation after the merge is unlikely to start until 90% of the merge computation is done no matter what we do.

Right, the merge itself is a loose barrier. In  explicts-comms we have to do a barrier initially before the merge can begin, which makes it a big problem.

Right, in the approach proposed above there isn't an actuall barrier() call in order to start.  We have tasks that look like the following:
def start_shuffle(df: pandas/cudf.DataFrame) -> None:
    shuffler = get_worker().get_shuffler()
    shuffler.put(df)
    return None

def end_shuffle(_, out_partition: int) -> pandas.cudf.DataFrame:
    shuffler = get_worker().get_shuffler()
    df = shuffler.get(out_partition)
    return df

x = ddf.map_partitions(start_shuffle)
y = some_sort_of_reduction_to_a_single_task(x)
z = expand_back_out_with(end_shuffle, ...)

(sorry for being very informal above.  I hope that that gets the point across)

The currrent "tasks" based shuffling method uses O(n log(n)) tasks and log(n) full-dataset communications. This is fine for ~100 partitions, but becomes challenging once you get to 1000 partition datasets. We also have a separate solution around partd, which does things in O(n) tasks, by buffering small shards of the data and using disk as a global communication store. Partd as written doesn't work in a distributed fashion, but we might think about how to do some similar approach in a distributed fashion.

 There is some excess communication here because we aren't thinking about locality for the Dask-DHT nodes, but for now let's just allow that as an allowable cost (my apologies).

So great, we get by with 2*n tasks, and probably two full communications. Not great, but it's probably better than what we have now for large shuffle computations.

Trading off communication complexity for task graph complexity is not a good architecture decision from my perspective. We (NVIDIA) have been pushing on things hard as we have very high performance hardware, but many people don't have this hardware. I.E. on a cloud system where networking isn't nearly as high performance as these machines we're using for benchmarking, the communication overhead is almost always significantly higher than the task graph overhead, even when we get to thousands of input partitions.
If there wasn't the task graph performance challenges we have today, we wouldn't be having this conversation as to how to shuffle data more efficiently. We'd likely be bottlenecked by our communication layer / interconnect bandwidth, which is a good bottleneck to have.

Yeah, so maybe we need to dynamically add worker location restrictions to
tasks based on the dht locations.  This would be the work of the scheduler
plugin. I would do this in a next stage of work, but maybe it's critical to
do at the outset.
On Sat, May 2, 2020, 10:59 AM Keith Kraus<EMAIL_ADDRESS>wrote:

The currrent "tasks" based shuffling method uses O(n log(n)) tasks and
log(n) full-dataset communications. This is fine for ~100 partitions, but
becomes challenging once you get to 1000 partition datasets. We also have a
separate solution around partd, which does things in O(n) tasks, by
buffering small shards of the data and using disk as a global communication
store. Partd as written doesn't work in a distributed fashion, but we might
think about how to do some similar approach in a distributed fashion.
 There
is some excess communication here because we aren't thinking about locality
for the Dask-DHT nodes, but for now let's just allow that as an allowable
cost (my apologies).
So great, we get by with 2*n tasks, and probably two full communications.
Not great, but it's probably better than what we have now for large shuffle
computations.
Trading off communication complexity for task graph complexity is not a
good architecture decision from my perspective. We (NVIDIA) have been
pushing on things hard as we have very high performance hardware, but many
people don't have this hardware. I.E. on a cloud system where networking
isn't nearly as high performance as these machines we're using for
benchmarking, the communication overhead is almost always significantly
higher than the task graph overhead, even when we get to thousands of input
partitions.
If there wasn't the task graph performance challenges we have today, we
wouldn't be having this conversation as to how to shuffle data more
efficiently. We'd likely be bottlenecked by our communication layer /
interconnect bandwidth, which is a good bottleneck to have.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/6164#issuecomment-622991643, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKZTCMXVTBNEDDB4JVDVTRPRNRNANCNFSM4MXPXLOQ
.

cc @fjetter in case this interests you

If there wasn't the task graph performance challenges we have today, we wouldn't be having this conversation as to how to shuffle data more efficiently. We'd likely be bottlenecked by our communication layer / interconnect bandwidth, which is a good bottleneck to have.

Indeed, we (Blue Yonder) are currently bottlenecked by available memory and available network bandwidth but rarely by scheduler overhead. For this we created #6259.
We're usually only hit by scheduler overhead if the input data is partitioned to granularly which is when we repartition (and optimize/fuse) before we start shuffling.
@crepererum made a good point there about out-of-band communication of the payload data which may tie in quite well with this approach of using a DHT (if the complexity this introduces is something we'd consider feasible)
However, pragmatically speaking, I don't think we're actually trading in communication complexity but for most scenarios keep it as is or improve it. Currently we have one full communication per stage. The number of stages we need for the reshuffling scales with log(N) but just to make it very clear, the number of stages is calculated using ceil(log(N) / log(max_branch)). To illustrate this I'll keep the constant at the default value (max_branch=32) which is probably true for most users and spell out the critical points:

N (partitions)
stages / full comms

10
1

33
2

1025
3

So only for relatively small dataframes with 32 partitions or less we do get away with only one data submission and this case is handled with it's dedicated code path by now (see here) which is something we could still allow in the future, if need be.
For everything else, a constant two is either as bad as before or a significant improvement.

I would like to point to Dask-CUDA's implementation of shuffle, which is basically a shuffle service that perform the all-to-all communication in a single stage without the involvement of the scheduler. It works with both CUDA and regular Dataframes such as Pandas and cuDF.
In order to enable it, simply import dask_cuda and set DASK_EXPLICIT_COMMS=True or set the "explicit-comms" key in the Dask configuration and Dask will automatically use the shuffle service.

Interesting.  Have you seen substantial performance gains?
On Wed, May 12, 2021 at 5:28 AM Mads R. B. Kristensen <
@.***> wrote:

I would like to point to Dask-CUDA's implementation of shuffle
https://github.com/rapidsai/dask-cuda/blob/1d71749c6eed12ec60e175183c40300dcad914f3/dask_cuda/explicit_comms/dataframe/shuffle.py#L207,
which is basically a shuffle service that performs the all-to-all
communication in a single stage without the involvement of the scheduler.
It works with both CUDA and regular Dataframes such as Pandas and cuDF.
In order to enable it, simply import dask_cuda and set
DASK_EXPLICIT_COMMS=True or set the "explicit-comms" key in the Dask
configuration and Dask will automatically use the shuffle service.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/6164#issuecomment-839661790, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AACKZTEOUMSRMQ2KI56HPJLTNJJ6BANCNFSM4MXPXLOQ
.

I spend 20m and put together a very rough prototype of a decentralized shuffle service using actors.
from distributed.utils_test import gen_cluster

@gen_cluster(client=True)
async def test_actor_shuffle(c, s, a, b):
    import dask
    import dask.dataframe as dd
    import pandas as pd
    df = await dask.datasets.timeseries().persist()

    class Holder:
        """
        Holds shards of dataframes and then returns their accumulation

        We create one of these per output partition, and then have all of the
        input partitions send messages to them.
        """
        def __init__(self):
            self.shards = []

        def put(self, shard: pd.DataFrame) -> None:
            self.shards.append(shard)

        def get(self) -> pd.DataFrame:
            return pd.concat(self.shards, axis=0)

    holders = {char: c.submit(Holder, actor=True) for char in "abcdefghijklmnopqrstuvwxyz"}
    holders = {k: await v for k, v in holders.items()}

    def split(part: pd.DataFrame, holders=None) -> None:
        groups = part.groupby("name")
        futures = []
        for name, group in groups:
            first_letter = name.lower()[0]
            future = holders[first_letter].put(group)
            futures.append(future)
        for future in futures:
            future.result()
        return part.head(0)

    await c.compute(df.map_partitions(split, holders=holders, meta=df))

    @dask.delayed
    def get_partition(holder):
        return holder.get().result()

    out = dd.from_delayed(map(get_partition, holders.values()), meta=df).persist()

    x, y = c.compute([df, out])
    x = await x
    y = await y

    assert x.x.sum() - y.x.sum() < 1e-9

It works, although there are some problems

It's not robust.  We may want some sort of gang scheduling (this would be useful for the xgboost work as well)
Is passes around one actor per output partition, when we probably want one connection point per worker
It uses rpc, rather than something more fine-grained like batched comms (although that need may go away if we switch to one thing per worker rather than one thing per partition
This example isn't at all general, I've baked in that we're partitioning on the first letter of the name column

Still, I thought that this might be educational.  It shows that it doesn't have to be that hard to experiment in this space.


Possible bug in lickCalc

When using the online lickcalc GUI (http://jaimemcc.pythonanywhere.com/) sometimes there is a mismatch between number of licks and (licks per burst x number of bursts). This has been noted specifically with the following file, 03_W.med (from arbeidskrav).
This may point to a deeper issue with how this calculator is functioning which should probably be investigated.

resolved with v0.15.2


Test the conversions

While I was adding support for conversion of Groovy's array syntax [items...] to Kotlin's listOf(items...), the resultant output didn't look nice because of the later steps.
We should do proper testing of each and every function separately and also as a whole.

I am open to ideas. I think no one has ever tested kotlin scripts. Should we give up and start using gradle?

We now have tests! https://github.com/bernaferrari/GradleKotlinConverter/actions/runs/58248489
It basically is the same as
kotlinc -script gradlekotlinconverter.kts test_build_gradle skipintro && diff test_build_gradle.kts expected_build_gradle.kts

Thanks for the tests! I will try to fix the tasks conversion. These tests will surely help me :)

I still need to figure out how to test the methods individually, but I got so happy already. Even github actions is working.


Does not work with server-side rendering

The below error is being thrown:
import parse from 'posthtml-parser';
       ^^^^^
SyntaxError: Unexpected identifier

I was digging around a little bit and... why the server.js file is not being published in CommonJS format? I guess that this might be the problem here.

Transforming all the files to cjs format does resolve the issue.
What do you think about providing a cjs version of this library? Publishing an ES6+ version to npm is IMO not a good idea, as in most projects you exclude your node_modules from passing it via babel.

Hi @sarneeh thanks for the report. Could you try using v0.7.x and check if it works. There's should be no code change with v0.8 (only bundle & publish change)

@pveyes 0.7.0 works fine. Also the bundle looks good. It crashes on 0.8.x.

What node version are you using?
I'm using HTMR 0.8.1 with Gatsby no problem on my machine. (Node 10.15.3)

@Arcath 10.15.1. Also, I'm using HTMR with NextJS which compiles the client and also server code. Now I realised that I'm actually not sure if this is a client or a server failure :smile:

posthtml-parser is only used in the server.js not browser.js.
That being said NextJS will be bundling the server side code for use in the browser as your importing convert from htmr not htmr/lib/browser
I'm looking rewriting the browser bundle to use the server-side parsing anyway to clear up a bug I am having on my site.

 Thanks for solving this little mystery to me :smile:

Hi! I'm getting the same error - independently of using html or htmr/lib/browser when I build my productive code with React Static. I've downgraded to 0.7 and it works fine.
So there might be a bug. Or am I'm getting something wrong?

@IOIO72 I admit that I actually did not test the suggestion from @Arcath as it did sound like a logic cause of this issue. I'll check it out in my project today.

@Arcath @IOIO72 Is right. I'm getting the same issue while using htmr/lib/browser, but from different thing. The problem is that the code is not transpiled to cjs.
import React from 'react';
    ^^^^^
SyntaxError: Unexpected identifier


cli package bug

➜ corral --help=false
ERRR: Error: missing subcommand at: 'corral'

and yet...
Options:
   -g, --debug=0             Configure debug output: 0=off, 1=err, 2=warn, 3=info, 4=fine.
   -n, --nothing=false       Don't actually apply changes.
   -h, --help=false

according to the options, that should work.
Options shouldn't have "=false" as the default displayed really.
N.B
corral --help=true

works correctly.
This impacts on any OptionSpec.bool. And also appears in ponyup and any other programming using the cli library.
The problem is that corral --help=false is effectively saying corral. But.... that's just a bad experience.

Something to explore. If you set true as the default for a boolean option and then try to pass false, what do happens?

@SeanTAllen just getting my feet wet with pony but would love to submit a fix here! I am wondering if it should even be possible to set a default value for a bool option? In reality, setting the default value currently does not make a difference in behavior. Demonstrating with corral:
Default value for --quiet is false:
$ corral version
version: 0.3.6
$ corral version --quiet
$ corral version --quiet=true
$ corral version --quiet=false
version: 0.3.6

Default value for --quiet is true:
$ corral version
version: 0.3.6
$ corral version --quiet
$ corral version --quiet=true
$ corral version --quiet=false
version: 0.3.6

So the default for a bool would always be "off", correct @hasheddan ?

@SeanTAllen yep! That’s what I was thinking

Sounds good to me. If that would be a breaking change (which I think it would be probably), it would need to go through the RFC process.
https://github.com/ponylang/rfcs


Can't change date preview input labels if no default value

Can't change date preview input labels if no default value
If preview date is enabled and there's no default value to the date range. Labels are showing
"Early" and "Continuous".
[BUG] Bug Reproduce Steps
Use a date range picker, provide a ranges props like the one below.
<DateRangePicker 			ranges={[{ 				startDate: null, 				endDate: null, 				key: 'selection' 			}]} 		/>
[BUG] Expected behaviour
Can pass custom labels to input date preview. Something like:
<DateRangePicker 			ranges={[{ startDateLabel: 'Start Date', 				startDate: null, endDateLabel: 'End Date', 				endDate: null, 				key: 'selection' 			}]} 		/>
Environment
Package Version: ~1.0.0-beta
React version: ~16.8.6
Node version: v10.15.3
Browser: Google Chrome 73.0.3683.103

+1 for being able to change labels of "Early" and "Continuous".

FYI: You can set custom placeholder for labels Early and Continuous via props now.
    /** default: `Early` */
    startDatePlaceholder?: string | undefined;
    /** default: `Continuous` */
    endDatePlaceholder?: string | undefined;


Fix typo in character remaining warning message and add fixed table layout to classic blue and blue scroll theme.

Fix a dumb typo in character remaining warning text.

Thanks!


Interactive Python Window doesn't accept input commands

Issue Type: Bug
Periodically, but very frequently, the Interactive Python window stops accepting any inputs.  Typing commands just stops working.  Even if the Interactive window has focus.
Extension version: 2020.11.358366026
VS Code version: Code 1.51.1 (e5a624b788d92b8d34d1392e4c4d9789406efe8f, 2020-11-10T23:34:32.027Z)
OS version: Windows_NT x64 10.0.18363

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz (12 x 2904)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offopengl: enabled_onprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
63.81GB (53.89GB free)

Process Argv
--crash-reporter-id 0f21024a-5b34-49b8-93e8-c6b889335192

Screen Reader
no

VM
25%

Run current cell does not work, Run current cell and Advance does not work (Nothing happens), I am stuck executing selection in Notebook (selecting + shift enter). VSCode became unusable for me. How can I revert to an earlier Python extension version?  Interestingly, run all cells works, but run all cells above does not work again.

Extensions:
Jupyter: v2020.11.358541065
Python: v2020.11.358366026

Same here. Interactive window does not accept any input commands, with some very rare exceptions.
What can I do to fix that?

It seems that VSCode is ignoring cells altogether. Now I figured out that run all cells actually runs everything at once.

Similar issue here. Run cell works but I couldn't type interactive command

Issue moved to microsoft/vscode-jupyter #3924 via ZenHub


Low Confidence Scores for High IoU Segments in THUMOS14 Predictions

Hello,
Thank you very much for your outstanding work！
Now I encountered an issue while working with your codebase on the THUMOS14 dataset. For example, in video_test_0000004, I noticed that the predicted segment overlaps well with the ground truth segment, achieving a high IoU (e.g., 0.616060). However, the confidence score for this prediction is unexpectedly low (e.g., 0.06995).
This issue is not limited to this video; I observed similar behavior in other videos as well.
Could you please provide insights into why this might happen? Have you analyzed this phenomenon before? I’d also like to invite the community to discuss potential reasons and solutions for this.
Thank you for your time and support!

a video will have multiple groundtruth actions, what you see in the table is that the predictions may have low IoU with specific actions [0.2, 1.1], but it may have high overlap with other groundtruth actions.

Thank you very much for your response.
However, you might have misunderstood my point. What I meant is that the predicted segments have relatively high IoU values with the ground-truth labels, but their classification scores are relatively low (as shown in the red box). I would like to ask if this is normal. Theoretically, if the IoU score is high, the classification score should also be relatively high.


http referer replacement should use request.get_host() instead of request.META['HTTP_HOST']

On the following line of code in CorsMiddleware, the http host used for replacing referer is set as follows:
https://github.com/ottoyiu/django-cors-headers/blob/b7e401273cdc05ef7ce3fc20390c977bf46ab3be/corsheaders/middleware.py#L62
The problem is that if you use a reverse proxy and set settings.USE_X_FORWARDED_HOST, then the CsrfViewMiddleware fails on referer checking because it checks against request.get_host() which will use the forwarded host name.
The solution would be for CorsMiddleware to also use request.get_host(). Will you make this change please? Thanks!

Seems straightforward. Sure you don't want to make a PR yourself?

Hi Adam, Sure I can do that. Thanks.

Great, now you'll win some open source points!

Hi @adamchainz. Any change you can merge my pull request? Thanks!

No longer relevant as #536 has removed the associated middleware.


e2e: Make ginkgo default to verbose mode

It is usually helpful to get the verbose information provided by ginkgo. For example, it lets the user know when provisioning is stuck on downloading an image, instead of providing no feedback for non-verbose mode.
This PR forces ginkgo to run in verbose mode by default (-v flag). But it skips enforcement in a few cases:

If -succinct is provided.
If the new option -cilium.noVerbose=true is provided. [removed]

The second commit updates the documentation accordingly.

test-me-please

test-runtime

This PR forces ginkgo to run in verbose mode by default (-v flag). But it skips enforcement in a few cases:
* If -succinct is provided.
* If the new option -cilium.noVerbose=true is provided.

Do we need cilium.noVerbose if we have -succinct? Is there a difference between the two?

Do we need cilium.noVerbose if we have -succinct? Is there a difference between the two?

There are three modes: verbose, “default”, and succinct. Succinct is more quiet than the default mode: If set, default reporter prints out a very succinct report. The cilium.noVerbose is for using the default mode.
I don't know how strong we need it, but I didn't feel comfortable disabling this default mode entirely.

test-1.20-4.9

This is always a balancing act between verbosity and noise :-)

There are three modes: verbose, “default”, and succinct. Succinct is more quiet than the default mode: If set, default reporter prints out a very succinct report. The cilium.noVerbose is for using the default mode.
I don't know how strong we need it, but I didn't feel comfortable disabling this default mode entirely.

For some context, a long time ago (in a galaxy yada yada..), I had added the "succinct" mode because for my personal usage I found that the default was too noisy. For example if I really just wanted to see whether various tests passed/failed when running locally. But a lot has changed since then, including changes to the default verbosity and even the way we do testing as a project. I don't have any local shell shortcuts that use succinct, my guess is that noone still uses it.
I interpret the PR in its current state to be saying two things:

The default options are not providing you with enough information to debug an issue with the individual test run
The three existing options for debug output are not enough, let's add a fourth.

Overall though I think there's only really two use cases:

Running all of the tests where you expect everything to pass and you just want a short summary of each test that you run

In the past it was far more common for developers to run all tests locally. Printing all --verbose output would be counterproductive here because there's just so much irrelevant information if you don't expect many tests to fail.
These days we are far more reliant on the CI to provide these checks so maybe this use case is not as common. Between Github and Jenkins, if there are any failures, the red failure icons will be pretty obvious and you know where to focus.

Running in a way that gathers as much information as possible about the build

Behind the scenes in CI (eg in the full jenkins log), we actually want this by defualt so that we don't have to run the test twice just to start getting debug information.
When running locally, if you know the test is likely to fail then you probably just want to set this flag and get as much info as possible.

Going based off the above, I think at this point it's quite reasonable to switch the default to verbose, then allow developers to specify either --succinct or --quiet or however we want the flag to be called if they really want less output. :+1:  Then if we implement this and developers start complaining, let's discuss more about what info is useful and what is too much info to again rebalance the verbosity/noise equation.

The -succinct is a ginkgo option, not something we can remove cleanly (we could probably disable it the way we enforce verbose, but there's probably no need). Talking with Joe on Slack - It transpires that you share Paul's concern about too-many-options. So after all, I removed the -cilium.noVerbose option. In this new revision we have verbose by default, or -succinct to get a very quiet output.

test-me-please

A quick grep for ginkgo in the jenkinsfiles seems to indicate that all invocations already use the -v (verbose) flag, so I don't believe there will be an issue. But you're correct on announcing on #development, I'll do that. Thanks!

test-1.20-4.9

@glibsm I don't see any conflict, and the files touched by this PR do not appear to have been modified in the master branch since the creation of the PR. I believe you set the label by mistake? Did you intend to add it to another PR instead?
I'm swapping back to ready-to-merge, let me know if I missed something.


Add BlackboardBehavior and initial AcquireFood tree

Description

Adds class behaviors.BlackboardBehavior, which exposes a concise way to map blackboard keys to local strings.
Adds and hooks up the AcquireFood tree to the AcquireFood action server
Creates the behavior ComputeFoodFrame which, given the goal, outputs the food reference frame. It also (optionally) publishes this frame to the TF tree for debugging purposes.
Adds ComputeFoodFrame to the AcquireFoodTree
Uses send_goal to write specific goal arguments to the local blackboard.

Proposal:
In general, I think goal and result variables should be read from / written to the current tree blackboard namespace. This better enables subtree inclusion, where previous nodes explicitly write subtree inputs to that subtree's local blackboard and read subtree outputs from that subtree's local blackboard namespace.
For right now, I think it's okay for feedback to utilize the tree root blackboard. However, I think it would be better going forward for us to attach a FeedbackVisitor to construct it every tick instead. Feedback in theory should ideally only be dependent on:

The currently running Behavior
The blackboard attached to the currently running Behavior
The previous Feedback

Note that, for subtrees, get_feedback will never be called, so get_feedback, get_result, send_goal should be free to assume that they are running on the main tree and act accordingly.
The upshot of all of this is that tree_root_name becomes deprecated, and all trees can treat their own self.blackboard as the root scope.
Testing procedure

Use https://github.com/personalrobotics/feeding_web_interface/pull/89 (if not merged)
Run the Mock FT Sensor: ros2 run ada_feeding dummy_ft_sensor.py
Run the action servers: ros2 launch ada_feeding ada_feeding_launch.xml use_estop:=false
Run MoveIt in sim: ros2 launch ada_moveit demo.launch.py sim:=mock
Run this code with the default dummy carrot (oriented horizontally in the camera frame): ros2 launch feeding_web_app_ros2_test feeding_dummy_acquirefood_launch.py
Verify the Goal Succeeds (status=0). Open RViz and add an Axis Frame "food"  (rescale to 0.1 for visibility), verify that +Z is against gravity and +X is horizontal relative to the camera.
Run this code with the dummy carrot 2 (oriented ~vertically in the camera frame): ros2 launch feeding_web_app_ros2_test feeding_dummy_acquirefood_launch.py request:=above_plate_2_carrot_request.pkl
Verify the Goal Succeeds (status=0). Open RViz and add an Axis Frame "food" (rescale to 0.1 for visibility), verify that +Z is against gravity and +X is vertical relative to the camera and to the "lower right" in the camera frame.

[x] Run your code through pylint and address all warnings/errors. The only warnings that are acceptable to not address is TODOs that should be addressed in a future PR. From the top-level ada_feeding directory, run: pylint --recursive=y --rcfile=.pylintrc ..

Before Merging

[ ] Squash & Merge

Re. your idea of writing goals in local namespace as opposed to the tree root namespace, I think the only scenario in which that matters is if we use a tree within another tree, and I'm not sure how we would percolate the goal down into every subtree's blackboard. We should discuss more asynch (e.g., on a GitHub issue). For Feedback and Result, I agree that we can create a visitor for those.

We can discuss offline, though I want to flag that we shouldn't conceive of the input of the tree being the action goal specifically. Instead, we can consider a tree to have a set of inputs, like a function, that are implemented as expected variables written to the local blackboard prior to tree execution.
For the root tree, send_goal takes the goal object and writes those variables.
For sub-trees, it is up to the parent tree to write to those variables (by having the keys be the outputs of other nodes or written directly).


Alternate initials undetected for initialize-with

This is a followup to #392. If there are more than two unspaced initials, it seems that pandoc-citeproc <IP_ADDRESS> is only detecting every other one:
pandoc -F pandoc-citeproc -t plain << EOT

---
references:
- id: 'barnish'
  author:
    - family: Barnish
      given: S.J.B.
- id: 'james'
  author:
    - family: James
      given: M.R.C.E.L.
csl: vancouver.csl
---

@barnish; @james

EOT

Output
1. Barnish SJ.

2. James MRE.

Expected output
1. Barnish SJB.

2. James MRCEL.

That was quick; thank you very much!


3.x: Add yaml profile support for application.yaml

Adds support for yaml profile support using the mp.config.profile system property.
Possible fix for: #5159

I'm an Oracle employee, I think I don't need to sign the OCA.

Closed as   #5585 add this enhancement


Bug when counting with vars in fractions

Steps to reproduce:

case: Enter: k/6 to the engine: https://mathematicator.com/search/k/6
case: Enter: (1 - 1/6)^k * 1/6 https://mathematicator.com/search/(1-1/6)^k*1/6

Current behavior:

case: Interpretation is: k * k/6
case: Result is: (5/6)^k * k/6

Expected behavior:

case: Interpretation should be: k/6
case: Result should be: (5/6)^k * 1/6

After investigating, this issue should be transferred to https://github.com/mathematicator-core/calculator


cannot GET /extracted/.zip

Hi,
Not everything works as expected. I have two questions:
(1) I somehow I get the following error message when I try to extract a translated model:

The contents of the directory /data/ gets cleaned up during the download of the viewer files at this point:

After that, this happens again for a few more times. What is causing this?
(2) The model I upload is a model with another model as dependency. But in the viewer I only see one of the models. Why doesn't it show both of the models?
I used the following models: testing models.zip
Thanks in advance!
Gerard

Hi everyone,
Somehow I got this fixed installing bower again. Now everything works as expected.
Gerard

Hi,
ok cool - thx for letting me know


Sometimes not all subs are unsubscribed.

Error:
All subs should be closed: Test Failed at /home/runner/work/NATS.jl/NATS.jl/test/runtests.jl:50
  Expression: isempty(nc.subs)
   Evaluated: isempty(Dict{String, Sub}("wJYV0C" => Sub("inbox.JrGP8wt6uH", nothing, "wJYV0C")))

Testsets that is not closing subs may be:

"Request multiple replies"
"4K requests"
"4K requests external"

Probably some multithreading issue or cleanup task in request fails to unsubscribe.
Example job.
https://github.com/jakubwro/NATS.jl/actions/runs/7174471783/job/19535987543

This is clearly multithreading problem with unsubscribe. Review locking of internal dicts.
https://github.com/jakubwro/NATS.jl/actions/runs/7371966961/job/20059849118

Should be fixed in https://github.com/jakubwro/NATS.jl/pull/8


Connection optimization for JBOSS Consumers.

Currently, we are seeing a high number of connections on the Broker so see if you can optimize.
We would like to have a way to control the number of connections or sessions using MaxSessions.

How any MDBs you have ?
for each MDS (endPoint) we try to re-use the same PulsarConnectionFactory.
The PulsarConnectionFactory holds an instance of the Java Pulsar Client, that maintains the pool of connections.
https://github.com/datastax/pulsar-jms/blob/e59d6d0fb682eb741e8ad84705aedc81730303eb/resource-adapter/src/main/java/com/datastax/oss/pulsar/jms/rar/PulsarResourceAdapter.java#L97
Are you configuring the MDBs with the same "Configuration" ?
if you have the same configuration and you simply change the destination I would expect that you have only one PulsarClient.
Each PulsarClient opens only 1 connection to each broker
se connectionsPerBroker configuration

I do not see anything logged for below line
log.info( "Activate endpoint {} {} configuration {}",
Is there a way we can log - number of Connectionfactories/Sessions and other metrics in resource adapter to collect the meterics
?

There are around 990 MDBs


Pulls/4.0/i18n reorganise

Oh, we need to merge https://github.com/silverstripe/silverstripe-cms/pull/1814 to get this working.

Nice tests running.


How to use the dropdown sub menu?

In v3 bootstrap It was easy to make dropdown submenu,
but in v4 I don't know how to do it.
for example, I want to make dropdown sub menu.
when I click the Dropdown2 menu, I want to see popup the dorpdown sub menu like one, two, three
.. Is it possible?
+div class="dropdown open">
+button class="btn btn-secondary dropdown-toggle" type="button" id="dropdownMenu1" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
Dropdown
+/button>
+div class="dropdown-menu" aria-labelledby="dropdownMenu1">
+a class="dropdown-item" href="#">Action+/a>
+a class="dropdown-item" href="#">Another action+/a>
+a class="dropdown-item" href="#">Something else here+/a>
+a class="btn btn-secondary dropdown-toggle" type="button" id="dropdownMenu2" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
Dropdown2
+/a>
+/div>
+div class="dropdown-menu" aria-labelledby="dropdownMenu2">
+a class="dropdown-item" href="#">one+/a>
+a class="dropdown-item" href="#">two+/a>
+a class="dropdown-item" href="#">three+/a>
+/div>

dropdowns with submenus are not supported in bootstrap. please ask these sorts of "how to" questions on stackoverflow or similar. see https://github.com/twbs/bootstrap/blob/master/CONTRIBUTING.md#using-the-issue-tracker

Thank you for your reply.


[SPARK-45764][FOLLOWUP][BUILD] Use latest sphinx-copybutton from CI

What changes were proposed in this pull request?
This PR proposes to use latest sphinx-copybutton from CI.
Why are the changes needed?
We removed upper bound from https://github.com/apache/spark/pull/43861, but CI is still using pinned version. We might need to use latest version in CI as well.
Does this PR introduce any user-facing change?
No, test-only.
How was this patch tested?
The existing CI should pass.
Was this patch authored or co-authored using generative AI tooling?
No.

cc @HyukjinKwon @dongjoon-hyun FYI

Thanks for the review!

Merged to master.


Way geometry can have duplicate (pillar) nodes

I encountered some cases where the way geometry contained duplicate points (so basically 'loops' within the geometry of an edge). I could work around this somehow, but at the same time I am wondering whether or not this should even be allowed. Maybe make sure this does not happen during import already ?

Do you mean this is a bug or an OSM data problem and do you have an example? Is this related to #1353?

Yes I think this is an OSM data problem and I was wondering if this should be considered a GH bug or if it is ok. Using berlin-140101.osm.pbf from Geofabrik: http://download.geofabrik.de/europe/germany/berlin-140101.osm.pbf and adding this code at the end of GraphHopper#importOrLoad:
AllEdgesIterator iter = ghStorage.getAllEdges();
int numWith2 = 0;
int numWithMoreThan2 = 0;
while (iter.next()) {
      if (iter.getBaseNode() == iter.getAdjNode()) {
         System.out.println("this is a loop");
      }
      PointList geometry = iter.fetchWayGeometry(3);
      for (int i = 1; i < geometry.size(); i++) {
          if (PointList.equalsEps(geometry.getLat(i-1), geometry.getLat(i)) && PointList.equalsEps(geometry.getLon(i-1), geometry.getLon(i))) {
          if (geometry.size() > 2) {
                numWithMoreThan2++;
                System.out.println(geometry);
           } else {
                numWith2++;
           }
       }
  }
}
System.out.println("Found " + numWith2 + " with two points");
System.out.println("Found " + numWithMoreThan2 + " with more than two points");

I am getting this output:
at end
(52.476454581539066,13.30634795068982), (52.47596396079579,13.30637868433547), (52.47569331844956,13.306412770742464), (52.47541354914189,13.306483923788754), (52.47541336287737,13.306484296317793)
at end
(52.50342754654797,13.373002522580382), (52.503383588121466,13.372910507907953), (52.503166962485764,13.372685500368897), (52.50316621742769,13.37268494157534)
at end
(52.53548441534082,13.46005045160764), (52.53523649726591,13.461802083145129), (52.53523593847236,13.461802828203204)
at base
(52.48337188698437,13.375550434936965), (52.48337170071986,13.375550807466004), (52.4833798963587,13.375753649527288)
at base
(52.45093727374682,13.59829579140907), (52.45093727374682,13.59829597767359), (52.45092293137885,13.598419098520706), (52.450935969895184,13.598492486741225)
at end
(52.42476841266681,13.573765685567983), (52.42490047421084,13.573678327508532), (52.42519179191869,13.57467558774372), (52.42519197818321,13.574676146537277)
at base
(52.56125355276287,13.36488623242571), (52.56125448408547,13.364887163748305), (52.561264169840456,13.364885487367633)
at base
(52.51816852058847,13.441084066951664), (52.51816852058847,13.441084253216182), (52.518056948141535,13.442171106685052), (52.518036831573475,13.442367429488169)
at base
(52.548136432799765,13.258880114381316), (52.5481368053288,13.25888104570391), (52.548243162369204,13.26015565380802), (52.54824297610468,13.260159192833882)
at end
(52.40361844905358,13.581324672281548), (52.404047416241035,13.582530176249076), (52.404047975034594,13.582531107571672)
at base
(52.42031669066064,13.553802413205856), (52.42031687692516,13.5538018544123), (52.420658672317686,13.55312254771119), (52.420889454056834,13.552670483723368)
at base
(52.55131298790827,13.405728639790311), (52.55131298790827,13.405728639790311), (52.5514577154396,13.403715679132544)
at base
(52.50141495841924,13.435063438901233), (52.5014145858902,13.435062880107676), (52.50065853820723,13.434184456635665)
Found 2501 with two points
Found 13 with more than two points

So in summary:

there are quite a few cases where the coordinates of base and adj nodes are equal (within the 1.e-6 precision we are using). these are 'loops' in the real world but not really loops in the graph because the node ids are different, otherwise they would be excluded because of #1531. Not sure if anything can/should be done about these cases, but either way this would be for another issue.

there are some (not many) cases where the geometry contains duplicate consecutive points ('loops in the geometry'). these are the ones I was concerned about here. in all of these cases a pillar node has the same coordinates as either the base or adj tower node (as also mentioned in #1353). there were no cases where the inter-tower-node geometry (pillar nodes only) has a loop. probably we can get rid of these cases when we apply DouglasPeucker to the whole geometry (including tower) as suggested in #1353.

there are quite a few cases where the coordinates of base and adj nodes are equal (within the 1.e-6 precision we are using). these are 'loops' in the real world

I think they are not loops but barriers, right? Where a barrier node (like a gate) is exploded to a blocked edge.
Loops should, on the contrary, should be fixed by inserting an artificial extra graph node. I think this works.

Where a barrier node (like a gate) is exploded to a blocked edge.

Is this some OSM convention or do we do this somewhere ?

Loops should, on the contrary, should be fixed by inserting an artificial extra graph node, and not lead to coincident nodes. I think this works.

We do this already (#1531). The problem here seems to be that we do Douglas-Peucker for the inner geometry only, but then the first/last pillar node can still be equal to the first/last tower node.

Is this some OSM convention or do we do this somewhere ?

We do it.

Search for "addBarrierNode" in OSMReader

I think they are not loops but barriers, right? Where a barrier node (like a gate) is exploded to a blocked edge.

Outch! Thanks @michaz for reminding me about this workaround. This is indeed a bit ugly.

Hmm, do you have a better idea? I stared at it for an hour and didn't. ,-)

ok good to know, but so far I had no problems with these barrier edges (maybe we need to include them in the random graph tests though).


Fetch twitter usernames from GitHub API

We need to fetch the twitter usernames from GitHub's API: https://docs.github.com/en/rest/users
We'll need to add a column called twitter_username to users.
We could create UserSyncWorker — similar to the existent RepoSyncWorker.
This will be useful for https://github.com/notesclub/notesclub/issues/77

@hectorperez I'd love to tackle this if possible! You're mainly just looking to add a call to github's API for a user's twitter_username correct?

@DuldR sure, all yours, thanks!
By the way, could you also add the name of the user?
That API endpoint returns both twitter_username and name.
So you'll need to create two columns in the table users. You could call them twitter_username and name too.
If you prefer to do only twitter_username, that's ok too, thanks!


Update README and UserGuide

Coverage remained the same at 91.435% when pulling ce15823ca523111881f8c46c67029fc0eea3f2cb on johnweikangong:Documentation into e6f59e73e30c62d628d7f0612d2f8e6bce2aed01 on CS2103AUG2017-T16-B3:master.


MSID: 87729 Version: 2 DOI: 2<IP_ADDRESS>2583

[PLACE MANUSCRIPT AND EDITOR DETAILS HERE WHEN AVAILABLE] See step 3
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=87729)

Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/87729/v2)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews and QC
Who can help: Production team

[ ] QC passed or QC not needed

Who can help: Editorial team

[x] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>2583)
[ ] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[ ] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/87729/v2/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/87729)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/87729

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/87729

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/87729/v2/87729-v2.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/87729)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

Wrong version imported; according to eJP  it should be https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>2583v4, we have the v3.

version 4 is loaded, now ready to check


Allow passing additional arguments to git-semver-tags

Preamble
The current implementation of git-semver-tags uses git log to retrieve information about git tags. This works fine for any workflow where one tags the default branch. Other workflows such as version branches, where additional tags are created, are not supported.
Problem
My usecase, version branches, is not fully supported, because tags on commits only live on their corresponding version branch:
tags 1.4.0, 1.4.1, ... live on branch 1.4
tags 1.5.0, 1.5.1, ... live on branch 1.5

The commits never reach the default branch and are therefore missing from the result of git-semver-tags.
Possible Solution
I have tried to use git tag instead of git log here. But to no avail.
There however is a possible solution that involves passing --all to git-semver-tags. This solves the issue where git-semver-tags only finds tags on the current branch.
There should be an option (always optional) for passing additional arguments to git-semver-tags:
https://github.com/absolute-version/commit-and-tag-version/blob/fabd8cd0525db0fc2f4c7d6aea1d39a764f3dfcc/lib/latest-semver-tag.js#L6

Should i propose a solution?

Would be good if #98 can be merged prior to any of this.

I'm not sure I follow your use case - can you not just tag the commit when you cut the branch?
Are you making new commits on the version branches? That sounds like it could very quickly become non-trivial to reason about.
I'm not sure that passing --all would help - it would detect all the tags, sure, but it might lead to surprising or incorrect results.

Are you making new commits on the version branches? That sounds like it could very quickly become non-trivial to reason about.

Yes, there could be. There might be a constellation where the default branch is way ahead of a version branch (lets say a feature was refactored and a bug ruled out), but there still is a bug on a version branch that needs fixing. Cherry picking is not a solution here, because there might be unwanted changes coming with it.
For us the default branch is always labeled as unstable.
Passing --all would help us in this case, because we only support 1 "legacy" version. There will never be 1/multiple higher version(s) when creating a changelog for an older version.
It might be that we do something weird and unusual. Would you recommend any change? :)

@TimothyJones do you have any updates?

Apologies, I haven’t had a chance to look at a fix for this yet. I can get to it in a couple of weeks, or alternatively I’d be happy to review a PR if you’re able to raise one

Yeah, i can give it a go :)

Would you recommend any change? :)

My experience is that it's better to roll forward if possible - where you try to keep all deployments / installations on the latest version with a linear history. This means you don't have to reason about whether changes in one version affect another, and you know that 2.3.x has all fixes that were in 2.2.x, etc.
This assumption is baked in to the way that commit-and-tag-version reasons about version bumps, so I think if you did pull all tags you might end up in a situation where you have surprising or conflicting results.

Even ignoring which tool you use to track versions, I'm not sure how you'd communicate the implication of version changes to users - I don't think what you're doing is strictly against the letter of semver, but it might be against the spirit:

Semantic Versioning is all about conveying meaning by how the version number changes.

One improvement i immediately see is that prior to creating a version branch we can just tag the version on the default branch.
This will resolve any major or minor version bumps.

This means you don't have to reason about whether changes in one version affect another, and you know that 2.3.x has all fixes that were in 2.2.x, etc.

Once we bump/tag a major/minor version the default branch has technically the same code as the version branch. Only once changes, that should not make it into the current release, have been pushed to the default branch they differ.


Unable to pull confluentinc/confluent-local Docker image

Error:
    at makeNetworkError (node:internal/deps/undici/undici:9166:35)
    at httpNetworkOrCacheFetch (node:internal/deps/undici/undici:10835:18)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at httpFetch (node:internal/deps/undici/undici:10648:37)
    at node:internal/deps/undici/undici:10410:20
    at mainFetch (node:internal/deps/undici/undici:10400:20)

update: only seems to be affecting my MacOS (14.7.2 (23H311)) machine; Windows 11 machine with the same Docker Desktop version doesn't have the same issues

This seems to be a combination issue between the Docker version (>=4.36.0) and Registry Access Management being enabled. We'll need to try and handle looking up Docker credentials and adding them as a X-Registry-Auth: {username: USERNAME, password: PASSWORD, serveraddress: https://index.docker.io/v1/} header