Update kernel package-linux to v6.6.40

Update Garden Linux builds to use latest released 6.6 kernel (6.6.40)
Required by:

https://github.com/gardenlinux/gardenlinux/issues/2213

Done in https://github.com/gardenlinux/package-linux/commit/777036f215f401a69525a31fd61840984143d1ce
In collaboration with @nkraetzschmar and @Vincinator 💯


Add support for analyzing GopherJS artifact size.

When --analyze_size flag is passed to GopherJS, an additional
${packagename}.js.svg file is creates with a TreeMap diagram that
visualizes which packages contributed to the artifact size and how much.
The data is obtained by counting bytes written for each section of the
file including GopherJS's own prelude and works accurately both in
minified and default modes.
Most of diagram-related logic is isolated to the build/analysis package
with minimal changes to the rest of the code base.

fix and update workflows action and please merge master

Synced with the master branch, but I'm not sure what workflow action fix you mean.

@visualfc could you please clarify what else needs to be fixed in this PR or whether you are interested in merging it?

@visualfc could you please clarify what else needs to be fixed in this PR or whether you are interested in merging it?

It's cool, but users may just need a simple text display.

First of all, apologies for taking so long to respond, december was a busy month.
Adding text output option makes sense. I've experimented with it a bit before going on to implement SVG rendering and found that for any real-life project it is very difficult to understand, even when printed in a tree-like form. That said, I could still see how it could be useful to track artifact size changes in a CI system or something like that.
Example output:
  $artifact — 0 B own size, 1.2 MiB with children
  | playground/cmd — 1.5 KiB own size, 1.1 MiB with children
  | | fmt — 122 KiB own size, 1.1 MiB with children
  | | | os — 76 KiB own size, 453 KiB with children
  | | | | time — 161 KiB own size, 164 KiB with children
  | | | | | github.com/gopherjs/gopherjs/nosync — 2.3 KiB own size, 2.3 KiB with children
  | | | | internal/poll — 104 KiB own size, 104 KiB with children
  | | | | syscall — 93 KiB own size, 93 KiB with children
  | | | | runtime — 8.0 KiB own size, 8.5 KiB with children
  | | | | | runtime/internal/sys — 454 B own size, 454 B with children
  | | | | sync/atomic — 2.9 KiB own size, 2.9 KiB with children
  | | | | internal/testlog — 2.1 KiB own size, 2.1 KiB with children
  | | | | internal/syscall/unix — 1.5 KiB own size, 1.5 KiB with children
  | | | | internal/oserror — 890 B own size, 890 B with children
  | | | | internal/syscall/execenv — 631 B own size, 631 B with children
  | | | reflect — 266 KiB own size, 268 KiB with children
  | | | | internal/unsafeheader — 1.0 KiB own size, 1.0 KiB with children
  | | | | unicode — 441 B own size, 441 B with children
  | | | errors — 1.6 KiB own size, 118 KiB with children
  | | | | internal/reflectlite — 116 KiB own size, 116 KiB with children
  | | | strconv — 91 KiB own size, 93 KiB with children
  | | | | internal/bytealg — 879 B own size, 1.3 KiB with children
  | | | | | internal/cpu — 446 B own size, 446 B with children
  | | | sync — 37 KiB own size, 38 KiB with children
  | | | | internal/race — 1017 B own size, 1017 B with children
  | | | internal/fmtsort — 18 KiB own size, 30 KiB with children
  | | | | sort — 12 KiB own size, 12 KiB with children
  | | | unicode/utf8 — 15 KiB own size, 15 KiB with children
  | | | math — 2.1 KiB own size, 13 KiB with children
  | | | | github.com/gopherjs/gopherjs/js — 6.8 KiB own size, 6.8 KiB with children
  | | | | math/bits — 4.6 KiB own size, 4.6 KiB with children
  | | | io — 9.6 KiB own size, 9.6 KiB with children
  | $prelude — 56 KiB own size, 56 KiB with children

Moving SVG rendering into a separate tool is not very practical because it would need the dependency tree and a lot of meta information that are only available to the gopherjs compiler (in particular differences due to build tags and stdlib augmentation). It will require a much more complicated format to pass that on, which won't be human-readable.
As a middle ground I could offer to move most of the size analysis and/or SVG rendering logic into a separate package which I'd maintain myself, and import that from GopherJS codebase.

First of all, apologies for taking so long to respond, december was a busy month.
Adding text output option makes sense. I've experimented with it a bit before going on to implement SVG rendering and found that for any real-life project it is very difficult to understand, even when printed in a tree-like form. That said, I could still see how it could be useful to track artifact size changes in a CI system or something like that.
Example output:
  $artifact — 0 B own size, 1.2 MiB with children
  | playground/cmd — 1.5 KiB own size, 1.1 MiB with children
  | | fmt — 122 KiB own size, 1.1 MiB with children
  | | | os — 76 KiB own size, 453 KiB with children
  | | | | time — 161 KiB own size, 164 KiB with children
  | | | | | github.com/gopherjs/gopherjs/nosync — 2.3 KiB own size, 2.3 KiB with children
  | | | | internal/poll — 104 KiB own size, 104 KiB with children
  | | | | syscall — 93 KiB own size, 93 KiB with children
  | | | | runtime — 8.0 KiB own size, 8.5 KiB with children
  | | | | | runtime/internal/sys — 454 B own size, 454 B with children
  | | | | sync/atomic — 2.9 KiB own size, 2.9 KiB with children
  | | | | internal/testlog — 2.1 KiB own size, 2.1 KiB with children
  | | | | internal/syscall/unix — 1.5 KiB own size, 1.5 KiB with children
  | | | | internal/oserror — 890 B own size, 890 B with children
  | | | | internal/syscall/execenv — 631 B own size, 631 B with children
  | | | reflect — 266 KiB own size, 268 KiB with children
  | | | | internal/unsafeheader — 1.0 KiB own size, 1.0 KiB with children
  | | | | unicode — 441 B own size, 441 B with children
  | | | errors — 1.6 KiB own size, 118 KiB with children
  | | | | internal/reflectlite — 116 KiB own size, 116 KiB with children
  | | | strconv — 91 KiB own size, 93 KiB with children
  | | | | internal/bytealg — 879 B own size, 1.3 KiB with children
  | | | | | internal/cpu — 446 B own size, 446 B with children
  | | | sync — 37 KiB own size, 38 KiB with children
  | | | | internal/race — 1017 B own size, 1017 B with children
  | | | internal/fmtsort — 18 KiB own size, 30 KiB with children
  | | | | sort — 12 KiB own size, 12 KiB with children
  | | | unicode/utf8 — 15 KiB own size, 15 KiB with children
  | | | math — 2.1 KiB own size, 13 KiB with children
  | | | | github.com/gopherjs/gopherjs/js — 6.8 KiB own size, 6.8 KiB with children
  | | | | math/bits — 4.6 KiB own size, 4.6 KiB with children
  | | | io — 9.6 KiB own size, 9.6 KiB with children
  | $prelude — 56 KiB own size, 56 KiB with children

Moving SVG rendering into a separate tool is not very practical because it would need the dependency tree and a lot of meta information that are only available to the gopherjs compiler (in particular differences due to build tags and stdlib augmentation). It will require a much more complicated format to pass that on, which won't be human-readable.
As a middle ground I could offer to move most of the size analysis and/or SVG rendering logic into a separate package which I'd maintain myself, and import that from GopherJS codebase.

@nevkontakte
I'm try --anylize for dump pkgs json infos https://github.com/goplusjs/gopherjs/pull/25


rename ZSON spec to ZNG and rework a few things

These changes update the zson spectification so it's now
called ZNG and reworked a few things. First, while originally
motivated to maintain backward compatibility with the zeek
log format, we decided to forego this constraints and
instead describe how zeek logs can be easily converted into
and out of ZNG format while preserving all of the original
zeek structure.
Also, we furhter developed the binary protocol and adopted
native machine data types a la protobufs and avro.  We also
developed the type system further so all types are represented
with a single integer type code and composite types are
built up from previous type code bindings.
The specifcation now "leads with" a description of the binary
format (called BZNG) and then describes the text format (ZNG)
in terms of the BZNG definitions.

This is still a bit drafty and I was hoping to put up the code with the spec changes but realized it would be much better for all to review the spec first...

This is orthogonal to the immediate changes, but should we change the name of this file from spec.md to README.md so GitHub can do its thing of rendering this page whenever someone browses to this directory in the repo? I know we have lots of other markdown in the directory but this one probably does the best job of answering the question "What is ZNG, anyway?"

Also, I think this README.md should go in pkg/zng instead of pkg/zng/docs.  I will put up these changes in a subsequent PR.


Logs are not sent after socket reset.

The underlying socket in UDP class can get reset after a power cycle, or WiiFi toggle.
We need to check the status of the socket before sending and re-initialize it is the socket is dead. But since there's no API to check the status of a UDP object, we might need to resort to initializing the UDP object if the UDP.send... failed.

This has been fixed in master, but still hasn't been published due to technical difficulties.

This is confirmed to be fixed on master (0.0.5).


fix(ipfs-coord): Updating to v6.5.0

:tada: This PR is included in version 1.4.10 :tada:
Your semantic-release bot :package::rocket:


research

Research

5x $5,000 in SOV for a total of $25k in research rewards.
All winners eligible for post-hackathon grants for continuing to develop the project for deployment.

Challenge Description
For those who are good at research to provide possible ideas for:

Increasing TVL.
Incentivizing Stakers in Governance.
New Business that want to launch tokens on our Origins Platform
Anything positive using Sovryn Protocol and associated smart contracts.

Submission Requirements

Participants need to be at least 18 years old by June 4th, 2021.
Participants from everywhere can participate in this online event
You need to register online as a team or as an individual.
You can submit individually, or as a team. Teams should include no more than ten people.
All of your team participants will need to register here
Partners and their affiliates are not eligible for participation in Sovrython.

What makes a submission complete?

Link to a public Github repository containing the team members, presentations, documentation
The submission must be released under a GPLv3 compatible license
Projects cannot be edited after submission.

Judging Criteria
Submissions will be judged by a panel of experts based on their technical merits as well as the likelihood of implementation in a manner adding to the functionality of the Sovryn Protocol / Platform.
Winner Announcement Date
Sunday, July 18th
Useful Links:
Sovryn Code Repo

Under: 'What makes a submission complete?' section:

Link to a public Github repository containing the code, team members, presentations, demo and documentation

From my understanding of the project, this research is not requiring code/examples of code, but that would merely be supplemental. Is this correct? Or am I wrong in my understanding?
Thanks!

@Jpcostan good point, will edit!

@exiledsurfer I did up a submission but Gitcoin is having issues with creating an account. I’m new to blockchain and I came across Sovryn because of its amazing UI and I really like what you're doing!
Could you please consider my submission here: https://github.com/kkknives/Sovryn-Improvement-Proposal-Incentivising-Governance-for-Stakers
It’s currently 4AM in my country and I’m afraid Gitcoin might not be able to fix the problem before the deadline. If it is still not fixed, I might get my friend to submit on my behalf as he introduced me to this hackathon a month ago, but he will put my Sovryn address instead: 0xBb75a8042a0A12ea99052CB88fe5cFa778525Fe7
I spent two weeks working on this researching the blockchain ecosystem because I'm really interested in the intersection between technology and power dynamics!

@exiledsurfer Same here! I think it is just gitcoin bot being slow updating bounty details and by the time you see this our submissions will register correctly.
Anyways, I don't think it should be an issue as correct details of ALL submissions are recorded on gitcoin website: https://gitcoin.co/issue/SovrynBTC/sovrython-2021-bounties/19/100025827

A notice came in asking you to report that the work is done. . .
Work was completed before the delivery deadline and sent before the delivery deadline.

I reloaded the project I got an email from Gitcoin saying I had to finish the job

Hello Guys,
Out of curiosity I noticed the SOV token is not listed on trustwallet.
What happens if a contributor who had linked his Trustwallet address to his gitcoin account gets rewarded with the SOV token?
And what's the solution for such complications if it'll lead to wasted or lost payment?

Also what would be the easiest way to keep tabs on work openings at the Sovryn Protocol.
Would be nice to take this beyond gitcoin

Hi @Creative-Ed , sorry for the late response.
regarding issues with trust wallet, the best thing is for the user to raise the issue in the technical support channel in discord, and one of our mods will assist in sorting the issue. https://discord.gg/s8kWH5rc
Job openings you can track here! https://wiki.sovryn.app/en/open-positions/contribute-developing-sovryn

Hi @Creative-Ed , sorry for the late response.
regarding issues with trust wallet, the best thing is for the user to raise the issue in the technical support channel in discord, and one of our mods will assist in sorting the issue. https://discord.gg/s8kWH5rc
Job openings you can track here! https://wiki.sovryn.app/en/open-positions/contribute-developing-sovryn

This was very helpful, thanks a-crypto

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

The funding of 409.8361 SOV (4372.95 USD @ $10.67/SOV)  attached to this issue has been approved & issued to @fishbiscuit.

Learn more on the Gitcoin Issue Details page
Questions? Checkout Gitcoin Help or the Gitcoin's Discord
$3,920,813.96 more funded OSS Work available on the Gitcoin Issue Explorer

Also, the bounty description said 5 contributors will be rewarded, is there a reason only one contributor was rewarded?
Just need closure

@Creative-Ed Only one submission met the judges criteria, the rest had very low scores... unfortunately.

@Creative-Ed Only one submission met the judges criteria, the rest had very low scores... unfortunately.

Oh... Alright boss, makes sense now!
Would have been nice to tip a couple other contributors for their efforts though, the hours invested should have counted for something
But in all, you followed the manual of justice


perf: sequence models, speed up feedback loop (filter on __get_item__?)

Avoids long waits filtering the dataset before starting training. This is a really-nice-to-have, but of course not mandatory.
Filter in __getitem__
The __getitem__ method of the dataset returns values at a given index. It seems iffy to filter at that step, because how do we handle the item at the index being filtered? Return a random item? Return None? And how does the pl.Trainer handle that?
We could return a random item, but that seems incredibly hacky.
I considered a pytorch IterableDataset, but then a DataLoader cannot shuffle it natively, we would have to implement that ourselves.

We could, of course, just shuffle before adding it to the dataloader, which seems like a reasonable choice?

Move the mapping outside of the DataLoader
Mapping and filtering large amounts of data is exactly what Polars is really good at. Perhaps we want to move it somewhere before the PatientSlice is initialised instead? Current flow is roughly:
CohortDefiner --PolarsFrame-->
CohortToPredictionTimes --PredictionTime[PatientSlice, Label]-->
model.filter_and_reformat --PatientSlice-->
embedder

Perhaps we can move the heavy lifting to a subclass of CohortToPredictionTimes, and then have the embedder validate the input (e.g. that all tokens are within its vocabulary)?

@KennethEnevoldsen What do you think? Feel free to just read through it, and then we can talk about it tomorrow.

I believe before any of this we should probably look at whether we can simply speed up the filtering that is there, but to address some of the major points:

We could, of course, just shuffle before adding it to the dataloader, which seems like a reasonable choice?

Not possible as this would lead to the same shuffling every epoch. If we train for multiple epochs this becomes a problem. We could fix that, but would much rather not have to do that.

Move the mapping outside of the DataLoader

I don't believe it is a problem that the mapping is in the dataloader. It is the filtering before and I def. feel like that should work on patient slices.

let us talk about this one


step backwards from neovim?

Seems like one of neovim's original goals was to go from sync key handling to async key handling to improve performance. This takes a step back, back to sync handling.
Will this have the issues that Neovim solved (namely vim plugins that slow the user experience down, f.e. long wait times to process key press actions, especially movement actions), once we start adding various Vim plugins?

Our Onivim v2 design doc talks about why we moved from asynchronous to synchronous key handling: https://onivim.github.io/docs/other/motivation#reduced-rpc-calls


Quick fix for issue-95. Command buffer output not being cleared.

Seems to work. Hopefully it is correct. Not sure if this fixes all cases, as I just started using lilly :)

I've waited about a month since that's how long it took me to notice these PRs in the first place. In about a week's time I'm intending to implement the tests on these PRs for you and then merge them, unless you:

remove the PR entirely (hopefully not, but up to you)
inform me you would like to do this work

I added a test for this, but have no idea if it is correct or sufficient. Hopefully it is ok.

I seem to have signed commits turned on as a requirement for master branch protection, let me disable that for your convenience.


EVM blockchain tests - Cancun tests

Describe your changes and provide context
Get Cancun Blockchain tests to run/pass
Testing performed to validate your change
N/A

Codecov Report
Attention: Patch coverage is 0% with 4 lines in your changes are missing coverage. Please review.

:exclamation: No coverage uploaded for pull request base (seiv2@ba91e59). Click here to learn what that means.
 Consider uploading reports for the commit 76f409c to get more accurate results

Additional details and impacted files

@@           Coverage Diff            @@
##             seiv2    #1473   +/-   ##
========================================
  Coverage         ?   61.85%
========================================
  Files            ?      352
  Lines            ?    24542
  Branches         ?        0
========================================
  Hits             ?    15181
  Misses           ?     8489
  Partials         ?      872

Files
Coverage Δ

x/evm/keeper/replay.go
0.00% <0.00%> (ø)


The property stampId of HardwareSecurityModule should be enum

After tested, I found the property stampId of HardwareSecurityModule only allows stamp1 and stamp2. So I think this property should be enum. Otherwise, user cannot know what value could be passed?

Hi @neil-yechenwei , can you comment which RP this issue for?


Update AssignCulture.cs

dd

@vsnreddyy Was this sent by accident? Can you describe what you were hoping to do?


Prepublish

Coverage remained the same at 90.483% when pulling c09571b046c0fa081f0c904b759f09d18aace434 on aaronshaf:prepublish into 91890d175acc8827e730802db9badff5063263d5 on mzabriskie:master.


Go to symbol not working

Refs: #8229

Any browser, goto https://microsoft.github.io/monaco-editor/index.html
Open typescript sample, goto symbol from context menu is not working
Notice errors in console

Moved to Microsoft/monaco-editor#145
Due to so many issues being opened straight in Microsoft/monaco-editor let's also move this one over there


update dependency typescript to v5.2.2

Hey @mitesh-gupta! We appreciate the PR, but for TypeScript migrations we're going to be a bit more conservative. We'll make that migration when we're ready to make sure that we don't accidentally trigger other issues.


Automatically create small group and large group meetings

Every Tuesday and Friday within a semester

We can use scheduled celery tasks for this 🧠

We should add a field to Meeting like is_large_group_room OR a field to Semester large_group_room to aid in this.


docs (notifications pattern): guidance for Callout

Closes https://github.com/carbon-design-system/carbon/issues/17182
Usage & style document for Notification component has been updated to include guidance for  Callout.
Changelog
New

A new section for Callout has been included similar to other variant types

Changed

Notification status table has been updated to reflect changes made to it on the component page. This also addresses the reduced statuses for callout.
Image for notification types has been updated to include Callout.

Removed

A line that generalised all notifications to be dismissible.

PR ready to merge.
Waiting for devs to make the required name changes to storybook, before merging this PR.


idk i think this is old

@yeeteeyt This doesn't break anything, does it?

yeah lemme review it

no it doesn't

Great!


store: implement "store-verify", save tar and compression information

Rocket should store the compression and tar headers along with the original filesystem in the store. This way the user can verify the crypto hash at anytime. Desired example use case:
$ rkt store-verify
example.com/foobar expected ID c830f... got a839f...

Store the raw tar headers @vbatts has started to implement a library to do this: https://github.com/vbatts/tar-split
Store the compression headers, this will be part of the work that @pbx0 is doing with gzip

As a bonus we should store the original signatures and verify against those too.

@philips @vbatts I think this should be useful also for #332. This is quite different as the tree store represents a rendered aci, so there isn't a starting tar. Now it's implemented computing an hash that tries to be consistent but in an adhoc way that can be improved.

For tar-split, I'm targeting having a Packer/Unpacker that will operate on io.Writer/io.Reader respectively. With an initial json implementation. Since they're interfaces, perhaps msgpack or something can be later. As it is, compress/gzip on the streams works nicely. And is would be per tar archive.
Thoughts on where these (un)pack data files would be arranged? or is that enough of a later thought to just defer for now?

this needs to tie back into https://github.com/coreos/rocket/pull/332 which was just merged.


mixitup failed on initialization

Hi, why is mixItUp always fail when i just instantiated it?
here's my code

One

Two

Three

Four

Five

Six

$('#wow').mixItUp();
// fails, and also when i tried to filter one item
$('#wow').mixItUp('filter', '.One');
// not working also,

can you help me how to properly use this? i dont know what cause mixItUp not to work properly.
thanks!

Hi,
Your syntax all looks good but your target elements (in your case the
s), need to have the class "mix" in addition to your other classes for MixItUp to index them correctly.

@patrickkunka thanks, it worked,
just a question, is there a way i can filter mixItUp without using id or class selectors?
can i use my custom data-attribute ?

Yes - you can use any valid selector you want.
A data attribute would look like this:
$('[data-foo="bar"]').mixItUp();
Or if you have multiple values in your attribute:
$('[data-foo~="bar"]').mixItUp();

@patrickkunka i'm sorry, i think you didnt get my question.
what i mean is, if i can use data-attribute in my filter search?
like this.
instead of using
$('#Container').mixItUp('filter', '.category1');

can i use
$('#Container').mixItUp('filter', '[data-category1=1][data-category2=5]');

Ah OK,
Yes - just make sure you're using the correct syntax which is:
$('#Container').mixItUp('filter', '[data-foo="bar"]');
I believe the double quotes around the attribute value are necessary for it to be a valid attribute selector. You can also filter on the presence of an attribute alone (regardless of value) like this:
$('#Container').mixItUp('filter', '[data-foo]');
And as per your example above, you can also combine attribute selectors to create AND or OR logic:
$('#Container').mixItUp('filter', '[data-foo][data-bar]'); // AND logic
$('#Container').mixItUp('filter', '[data-foo], [data-bar]'); // OR logic

thank you @patrickkunka !
i dont want to mess up my class="" attr :smile:
also, just thinking, it would be nice if mixItUp has a function that will filter search through a json string like this

so we dont have to mess up our mix item,
what do you think? :smile:
btw, :+1: for your mixItUp
thanks!


The project doesn't compile when both libraries ('DS18B20' and 'Bridge') are used.

The issue is reproduced when developing for an "Arduino Yun" board. Arduino Yun embeds two platforms:

regular Arduino (probably Leonardo AFAIK)
OpenWrt Linux

It is possible to "call" some linux mechanisms from inside regular Arduino code. To make that possible there is a native "Bridge" library available in Arduino IDE. The Arduino project doesn't compile when using both libraries: DS18B20 and Bridge. There is a naming conflict as DS18B20 library defines the variable with the same name as some private variable inside Bridge library:
DS18B20.h
...
#define CRC          8
...

Bridge.h

class BridgeClass {

private:
   ...
    uint16_t CRC;
};

I have the feeling that the CRC variable in BridgeClass should/could be written in a lowercase. On the other hand I feel that providing a fix in DS18B20 library will also do the trick and we don;t have to wait until next Arduino IDE release.

Awesome! Thanks a lot. I've merged your pull request.


chore(main): release butler-sheet-icons 3.7.0

:robot: I have created a release beep boop
3.7.0 (2024-11-10)
Features

Add possibility to blur sheet thumbnails (c6bd4f4), closes #227

Miscellaneous

deps: Update dependencies (e261aa5)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

butler-sheet-icons-v3.7.0
:sunflower:


Dependencies in Cargo.toml are local

I'm chasing down an error that requires me to compile this crate separately and I can't build this crate without reverting before this commit.
I'm guessing that you're working on stuff locally so it's not a big deal, but it would be nice if references to local dependencies were in a separate fork before being merged with the master.

Ah right, I forgot that strategy breaks git dependencies dangit. I can push another alpha version later today if you'd like!

Whenever you have time! Like I said it's not a huge deal, I'm guessing you're working on some big changes so it makes sense why it's there.

Yeah :) Most of the major changes are already done, the rest is mostly just filling in some more APIs, but I've just published all of the latest versions to crates.io now if you'd like to try them!

Hi! Any update on this? I'd like to extend some of the API, but I'm not sure how to handle the dependencies.


Bugfix: S3 time precision issue fixed

As per amazon s3's documentation, they are not storing time with milliseconds precision.
While in moto it was storing it in milliseconds. Which was causing s3 sync command with --exact-timestamp to download the files everytime when syncing data from s3 to local.
This fix solved the bug.

Coverage increased (+0.004%) to 94.321% when pulling 13f98f7805322bfd44339179d17c29c7049c08df on macnev2013:master into 936c7c80f193ca5c7662a2b25742ac142bac5419 on spulec:master.

Coverage increased (+0.004%) to 94.321% when pulling 13f98f7805322bfd44339179d17c29c7049c08df on macnev2013:master into 936c7c80f193ca5c7662a2b25742ac142bac5419 on spulec:master.

Coverage increased (+0.004%) to 94.321% when pulling 13f98f7805322bfd44339179d17c29c7049c08df on macnev2013:master into 936c7c80f193ca5c7662a2b25742ac142bac5419 on spulec:master.

Thanks for the PR, @macnev2013!
Looks like the tests are now failing with these changes: https://travis-ci.org/github/spulec/moto/builds/711887910

Thanks for a quick response.
I changed was making change in core util function which was used by other services. So it was breaking.
As a fix i created a separate function for S3 which is used only from S3 module.


release-2024.6.1-hotfix:

Short description
Gold cards can not be activated since expirationDate = 0 isBefore today and will be validated as expired
Proposed changes

return false if expirationDate = 0 for isExpired()

Side effects

none

Resolved issues

Fixes: #1517
Testing

Create a gold card
Try to activate the gold card
card should not be expired anymore and can be activated

As I mentioned in the other pr, this is not the root of the cause.
ExpirationDay should be null for the golden card.
Please fix it in the card mutation service, and then add a migration script that sets those entries to null that have the value 0.


[OP] 3d conv + 3d pool

Important changes:

Pooling shape: Need to manually change pooling pad to work with old models.
C++11 flags: Break support of CUDA 7.0, 6.5

breaking all previous models seems really bad...

Only break Inception family. I have fixed symbols and pretrained model.

does it affect vgg?

I think vgg is ok

@tqchen @piiswrong please check this. If it is ok we can merge this first because it fix travis.

what is the status on this PR?

Will do pairtest with Torch today

please let me know if it is ready to merg

@tqchen looks like dmlc/any.h broke windows build

I am working on CUDNN tuning. Will be finished very soon.

@piiswrong @tqchen It is done. There is a possible refactor, but I need we can refactor it after we fix deepmark

@antinucleon I have updated dmlc-core so that any should be compatible with windows build

any updates?

Wait me 1 hour,
On Fri, Jul 8, 2016 at 10:49 Tianqi Chen<EMAIL_ADDRESS>wrote:

any updates?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dmlc/mxnet/pull/2585#issuecomment-231426441, or mute
the thread
https://github.com/notifications/unsubscribe/ABM13vRAd8Yx-313y7egViruPunq_tDRks5qTo2TgaJpZM4JCfHe
.

--
Sent from mobile phone

@tqchen If it is OK, merge it then I will update pretrained model

It still cant work well  with inception-BN model. COULD anyone fix this? It really cause me headache... Thanks a lot!

Sorry for that. I am fixing now

@Lorrainexun I have fixed the pretrained model symbol. It is because change of pooling shape.

Hi,all. I compiled the latest mxnet with cudnn 5 and thus can use 3D conv. The vgg and alexnet in deepmark are ok. However, when I try to run c3d.py I met a problem:
mxnet.base.MXNetError: Error in operator pooling4: [11:50:48] src/operator/./pooling-inl.h:232: Check failed: param_.kernel[0] < dshape[2] + 2 * param_.pad[
0] (2 vs. 2) kernel size exceeds input
This can be seen whenever I want to collapse the last two frames into one in other C3D models.
Any suggestions? Thanks!


WinAppDriver not detecting element but Inspect.exe is detecting

I am trying to automate the Local Group Policy editor functionality. I am able to automate the following path all the way up to the point where I have to select a value from a drop down. Please review to screen shot attached. The drop down list is populated in Inspect.exe, however, WinAppDriver is not loading that element in the page source and hence I am not able to take any action on it.
I am also dumping the page source, see it attached.
source.txt

My script is failing to detect the following xpath:
//Window[@Name='Local Group Policy Editor']/Window[@Name='Manage preview builds']/Pane[@AutomationId='tableLayoutFullForm']/Pane[@AutomationId='splitContainer']/Pane[starts-with(@ClassName,'WindowsForms10')]/Pane[@Name='Options:'][@AutomationId='flowLayoutPanelDynamic']/Pane[@Name='Options:'][@AutomationId='flowLayoutPanelSet the behavior for receiving preview builds:']/ComboBox[@Name='Set the behavior for receiving preview builds:'][@AutomationId='dropDownListSet the behavior for receiving preview builds:']/List[@Name='Set the behavior for receiving preview builds:']/ListItem[@Name='Enable preview builds']

@YouWhy,
I believe Inspect generates the Tree structure in a different way compared to WinAppDriver & UI Recorder. My personal recommendation is to use the XPath / Tree structure represented by UI Recorder since we developed that to be consistent with WinAppDriver.
I'm marking this issue as closed due to resolution.


Feature request: access to styles of month view cell

Do you want to request a feature or report a bug?
Feature
What's the current behavior?
I'm not able to style cells with my own classes.
What's the expected behavior?
I need to have access to cells so i can style concrete day cell with my own styles.
The classes i need to style are .rbc-day-bg and .rbc-date-cell to show user unavailabilities in calendar.

It would be helpful to have something like eventPropGetter to inject my own classes.

You can use a custom DateCellWrapper like so
coloredDateCellWrapper({ children, value }) {
	const style = {
		// Add your styles here
	};
	return React.cloneElement(Children.only(children), {
		style
	});
}

You can use the value argument above for the date in this date cell.
Then, add in Calendar like so
<BigCalendar
	// ...
	components={{
		dateCellWrapper: this.coloredDateCellWrapper,
	}}
	// ...
/>


[ALLUXIO-2252] Fix master fault tolerance integration test

https://alluxio.atlassian.net/browse/ALLUXIO-2252

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11632/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11634/
Test PASSed.

LGTM


CanvasItem.draw_polyline does not draw 1px lines when width<=1.0

Godot version:

4.0 7195f6b973
OS/device including version:

Vulkan
Issue description:

Following changes in https://github.com/godotengine/godot/commit/3ec972fc95f3d9fb308af0fded69fc7e53940f78, support for drawing thin lines with draw_polyline seems to have been removed. I believe this is in error.
Using the code:
func _draw():
	draw_arc(Vector2(0, 0), 50, 0, PI * 0.75, 25, Color.white)

when zoomed in, the line should be 1px wide, but it looks like this:

Steps to reproduce:
See above
Minimal reproduction project:

@Chaosus

This may actually be intended, see https://github.com/godotengine/godot-proposals/issues/1363.
We should support both use cases but we probably have to find another way to do that. I think scaling 1-pixel lines by default is a better idea, but there should still be a way to draw "hairline" width lines.

I do agree that width=1 shouldn't create pixel-thin lines and I generally prefer the behavior demonstrated in this issue. Hairline width should be supported with width=0, not 1. However, right now this function is inconsistent with other line drawing functions and behaves unexpectedly.

I think adding the add_thin_polyline method family is not a bad idea. So instead of draw_arc, you would write draw_thin_arc.


Web development skill refreshner plan

I decided to use this month of solitude for learning and weight loss. Need a concrete plan. Web development is one out of many interests, with the most high priority.  Looking for MOOC courses on class-central.com:

x JavaScript Basics via Udacity: Bad reviews made me worry. 3 weeks completion is nice but maybe too rapid.
oo  Interactivity with JavaScript University of Michigan via Coursera: Good reviews. This is a part of 5-course series of larger subject (as Coursera calls it as "Specialization"), which I formerly had a good experience with.

Decided to take the one from Coursera by U. Michigan.

Gone out of scope. Removed milestone.


Library release removal request

Library name
ConfigPortal8266
Version to remove
0.1.0

Hi @yhur. There never was a 1.0 release of the library:

Did you intend to request the removal of the 0.1.0 release?

Yes, you're right. That's what I wanted to remove.
Sorry for the confusion and I appreciate your insight here.

Thanks for the clarification. I am confirming your request.
Unlike submissions, this type of request is still handled manually. The Library Manager index maintainer occasionally comes through to clear all the outstanding requests. They will close this issue when it is done. You will get a notification from GitHub at that time.

Great! Thanks

Done:
2024/02/08 16:46:31 Loaded 6631 libraries from DB
Removing<EMAIL_ADDRESS>Success!


Not an issue: Thanks alot for your work mate

Having youtube import makes using SLAM way easier thanks for your work

Glad you liked it @tankirules , I planning to release a better version, with the feature that you can resume the audio you played the previous time, since currently the audio starts from beginning each time. I hope you would like it. I will tag you here once it is ready.


More backgrounds

Add ping script to validate workflow (wont fail build, just for debug)
Add batch of backgrounds

We've already uploaded a background for Warzone.


Editing Readme - Add Table Of Contents

normally it should look like this

Thank you for the PR. At this time we prefer to stay with the more minimalistic table of content already offered in the README:

Really appreciate you opening the PR!

For this purpose GitHub already offers the built in table of contents.

if you look at the work I have done there are many more points than what is provided by default.
and it's not for nothing
but if you don't want to improve the readability of your readme.
nor validate minor changes of contributor who does it for you.
what do you want me to tell you :/
it's sad


Add RPC defaults for cinder

This change overrides OSA defaults for cinder's thread_pool_size and
response_time. The defaults are now set to rpc_thread_pool_size and
rpc_response_timeout.
Connects #1360
(cherry picked from commit 016425a2032ff8369be089b310802f46af91072f)

LGTM 👍


Updates the Constant for meta header used in elasticsearch-transport

Related to #145
PR on elasticsearch-ruby:
https://github.com/elastic/elasticsearch-ruby/pull/1301

The failing spec is green when using elasticsearch-transport from https://github.com/elastic/elasticsearch-ruby/pull/1301


⚠ ClamAV has degraded performance

In d065ccd, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 240 ms

Resolved: ClamAV performance has improved in dd93f59 after 5 minutes.


Critical Pods (nginx-ingress, calico-node...) fail readiness checks under CPU pressure

Hi,
With the configuration provided in this repo, when a (user-scheduled) Pod without CPU limits puts a lot of CPU pressure on a node, critical pods are denied the CPU shares required to correctly pass readiness or even liveliness checks (I've observed this in production, this is reproducible).
This results in nginx-ingress, calico-node and kiam not receiving traffic, or even restarting.
I've noticed that

calico-node
kiam
nginx-ingress

do not have CPU requests set. I guess that's the reason why the health checks timeout under CPU pressure.
Should we add CPU requests for all these Pods? Is there a better way to fix this issue?
Thanks!

@Neki Yes we could add a sensible default in the helm chart defaults values


Creative search does not contain the flesh blocks/items

FabricItemSettings has to have the group appended ALWAYS when registering


Only show video, but not image after first scan

Before you create an issue make sure that:

Your issue is strictly related to LibrePhotos itself. Questions about setting up a reverse proxy belong in what ever reverse proxy you are using.
You have read the documentation thoroughly.
You have searched for a similar issue among all the former issues (even closed ones).
You have tried to replicate the issue with a clean install of the project.

When asking general "how to" questions:

Please do not open an issue here join us on the Discord server  LibrePhotos

When Submitting please remove every thing above this line
🐛 Bug Report

[ ] I am including my log files in zip format.
[x ] I have looked for similar issues among all the former issues including closed ones.

What Operating system and version is LibrePhotos running on:
Ubuntu 20.04
What architecture is LibrePhotos running on:
x64
How is LibrePhotos installed:
Docker compose
If running via Docker or Kubernetes please list version including docker-compose:
v2.0.1
Are you running LibrePhotos on a virtual machine if so please list:
not in VM
How is you picture library mounted on the host (or in the virtual machine):
Local file system (Type), NFS, or SMB
SMB mount
Description of issue:
This is the first time I use the app. After scan finished, seems all photos/videos are processed, but from UI, I can only see video, all pictures only have place holder like

I check the librephotos/media/thumbnail folders, all thumbnails are created correctly. When I copy the url from dev tool of browser, got 403 forbidden error.
# curl -vv 'http://<IP_ADDRESS>:3000/media/square_thumbnails/a6f34751bebff0b6c65bdfc63de912852'
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 3000 (#0)
> GET /media/square_thumbnails/a6f34751bebff0b6c65bdfc63de912852 HTTP/1.1
> Host: <IP_ADDRESS>:3000
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Server: nginx/1.21.1
< Date: Wed, 03 Nov 2021 18:13:05 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< Vary: Accept, Origin, Cookie
< Allow: GET, HEAD, OPTIONS
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< Referrer-Policy: same-origin
<
* Connection #0 to host <IP_ADDRESS> left intact
* Closing connection 0

How can we reproduce it:

Start from scratch
Create new user
Set scan folder
After scan, check the UI

Additional Information:

Include a ZIP file containing your log files.
Provide pictures or links to videos that clearly demonstrate the issue.

The problem seems happened on Safari browser only


Cannot install with pods

No specification found for SPPermission

Please, take screenshoot if you podfile

https://www.dropbox.com/s/ewdv37urmx2eki4/Screenshot 2019-03-04 11.30.23.png?dl=0

You try ‘pod update’?

No

should I?

Yes))) pod install allow use if you download pod local. Before install new pod you need call pod update.


Device not imported in the jest.setup.ts file

I might be wrong but there seems to be omission of the device import in the Jest setup file in the e2e folder
the code in there is
beforeAll(async () => {
  await device.launchApp();
});

beforeEach(async () => {
  await device.reloadReactNative();
});

and adding
import { device } from 'detox';
seems to fix it

Thank you for sharing the issue and thank you for contributing. I was also creating the PR: https://github.com/ixartz/React-Native-Boilerplate/pull/7 after your issue. Anyway, I'll merge your PR.
In VSCode, without the import it works perfectly. I think Detox handle correctly without the import. But, I think it's also better to be more explicit.

Your fix has been merged. Thank you for your contribution.

I use vs code and Typescript flagged the issue that is why i created a PR. amazing boilerplate by the way. Thank you very much

It's very strange I don't have the issue. Anyway, it's better to be more explicit.


linkage_checker: add libquadmath

[ ] Have you followed the guidelines in our Contributing document?
[ ] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[ ] Have you successfully run brew style with your changes locally?
[ ] Have you successfully run brew typecheck with your changes locally?
[ ] Have you successfully run brew tests with your changes locally?

We have noticed in https://github.com/Homebrew/homebrew-core/pull/123264 that libquadmath.so.0 is also provided by GCC.  This is primarily used by Fortran applications (in which case libquadmath.so.0 is provided by brewed GCC), but on occasion C or C++ programs link to this as well and brew audit should allow linkage to the system version of this library.

Review period will end on 2023-02-17 at 03:22:02 UTC.

Is it commonly installed by default by the system though? We keep our system dependencies fairly minimal in that they are provided by default in virtually all distributions (glibc, libstdc++, libgcc_s, etc.).
If the system version of library wasn't found, it's not like brew will auto install GCC - it will try to build from source instead.

We ask our users to have gcc installed on Linux as part of the build essentials or development tools.

We might suggest it in places but we do not require the full GCC toolchain to be installed anymore.
It's not been required for a while, but it was only cleaned up from documentation last year: https://github.com/Homebrew/brew/commit/1882ae4f6e7bbfaf9d19e2e2dc87616ae43fef8d

For some reason I actually misread this PR as libgfortran at first, which definitely isn't always installed as standard but is a part of the full GCC toolchain we provide.

algol68g will need a Linux bottle dispatched when this is merged.

On Debian/Ubuntu, libquadmath0 is pulled in via https://packages.debian.org/sid/libgcc-11-dev
What is required minimal packages to install on Fedora? I don't think the 64-bit library (libquadmath) is automatically pulled in with gcc.
For example, Fedora's algol68g package has a direct dependency on libquadmath - https://packages.fedoraproject.org/pkgs/algol68g/algol68g/fedora-rawhide.html#dependencies

Review period ended.


compressDART() doesn't re-assign to nodes

I'd need to dig into this a tad more, but adding an Issue as a reminder.
When using compressDART() recently, observations were not re-assigned to nodes provided in configuration when the node differed from the site_code. For example, after using buildConfig(node_assign = "array", array_suffix = "UD") each of my two-pass array sites were split into downstream "_D" and upstream "_U" nodes and that configuration was provided to compressDART(); however, my results assigned observations only to site_code, not node.
In looking at compressDART(), which uses queryObsDART(), observations are downloaded from "http://www.cbr.washington.edu/dart/cs/data/nezperce/. In looking at one of the downloads
(nptspawn_GRA_2019_1.csv),
it appears that the information is there to assign observations to nodes (config and antennagroupname columns).
Is it worth modifying compress() or compressDART()` so that it can re-assign detections to nodes when desired? I need to dig into the order-of-operations and functions more, not certain how big of a lift this might be.

@mackerman44 , check out the develop branch of PITcleanr. I just updated the compressDART function: turns out it wasn't making use of the configuration file at all. I think that's fixed the issue, but want to get your confirmation before I close this.

Looks like whatever you did worked! Thanks @KevinSee , I'll close this issue now.


Can not select alibaba component in start.spring.io

start.spring.io 网站中无法选择 nacos 等alibaba的组件

we are working it and it will come soon.

https://start.aliyun.com/bootstrap.html


Update Refinery's Rails version in its description

[x] verified that the CMS I'm adding is still maintained.
[x] read CONTRIBUTING.md.
[x] did not generate README.md.

thanks again, @bbenno!


Move app to dev

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.2%) to 83.099%

Files with Coverage Reduction
New Missed Lines
%

src/Discovery/DiscoveryDiscovery.php
2
72.73%

src/Bootstraps/DiscoveryBootstrap.php
2
93.1%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
2124

Relevant Lines:
2556

💛  - Coveralls


Backpack recipe doesn't work

Using the recipe as displayed in JEI doesn't actually create a backpack.  For some reason, it doesn't show that you need a metal ingot in the center postion.

It looks like there are a lot of recipes which are affected, each of them using the ZenScript | operator. They all work correctly on a single-player world, but any recipe ingredient which uses the | operator simply doesn't show up at all on the server. I've checked everything I can think of, and nothing seems to make any sense to me. So, I've posted a question on the official CraftTweaker Discord channel. We'll see if anything helpful comes from it.

Naturally, there are quite a few recipes affected by this problem: iron tools, arms, and armor; backpacks; shields, and quite a few others. I would expect them all to be resolved by the same fix.


Introduced option maxTilesPerFrame

Introduced option maxTilesPerFrame to let OSD update multiple tiles in each frame (default = 1).
Solves issue #2384

@iangilman , not sure what is happening here, the JS code compiles and I did not change any grunt package or so.

All checks passed. PR is ready now I guess.

@iangilman If I'm understanding right, currently only 1 image is added to the image loader per frame right now (which this PR would change). Would it make sense to have the ImageLoader handle the logic of making the tile requests? It seems like the imageLoaderLimit option is already intended for this purpose (but is thwarted by the 1 tile per frame thing). The docs for that option read as follows:

The maximum number of image requests to make concurrently. By default it is set to 0 allowing the browser to make the maximum number of image requests in parallel as allowed by the browsers policy.

Maybe all tiles that make up the current frame, sorted by goodness, could be passed to the image loader and the decision of how many to request should be implemented there?
Or am I missing something?

An interesting point.. the max number of concurrent connections/request eg., in Chrome is 6 per default. I guess we can limit this down with that imageLoaderLimit (but not increase over 6, this would have to be done in Chrome settings).
However, the number of tilesPerFrame can in theory be n (for n = all tiles of the current frame).
So, these numbers are somehow connected, but not really the same. E.g., if you have a low frame rate, but still want to load the image quickly, you need multiple tiles per frame, as the image loader will only get the tiles to load from the frames.
Another thought: I’m not sure if the imageLoaderLimit is still needed, as for http/2.0, there is no direct limit anymore for concurrent connections.
Am 22.07.2023 um 01:15 schrieb pearcetm @.***>:

https://github.com/iangilman @iangilman If I'm understanding right, currently only 1 image is added to the image loader per frame right now (which this PR would change). Would it make sense to have the ImageLoader handle the logic of making the tile requests? It seems like the imageLoaderLimit option is already intended for this purpose (but is thwarted by the 1 tile per frame thing). The docs for that option read as follows:
The maximum number of image requests to make concurrently. By default it is set to 0 allowing the browser to make the maximum number of image requests in parallel as allowed by the browsers policy.
Maybe all tiles that make up the current frame, sorted by goodness, could be passed to the image loader and the decision of how many to request should be implemented there?
Or am I missing something?
—
Reply to this email directly,  https://github.com/openseadragon/openseadragon/pull/2387#issuecomment-1646329215 view it on GitHub, or  https://github.com/notifications/unsubscribe-auth/ACVEAL3LQDPMYEFJV6DKBMTXRMESFANCNFSM6AAAAAA2RMIO5E unsubscribe.
You are receiving this because you authored the thread.  https://github.com/notifications/beacon/ACVEALYN6YIISQP4GHS52RDXRMESFA5CNFSM6AAAAAA2RMIO5GWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTCED6X6.gif Message ID: @.***>

However, the number of tilesPerFrame can in theory be n (for n = all tiles of the current frame). So, these numbers are somehow connected, but not really the same. E.g., if you have a low frame rate, but still want to load the image quickly, you need multiple tiles per frame, as the image loader will only get the tiles to load from the frames.

The way I am thinking about it is this. Currently, there are two different places where tile requests are throttled. My proposal would be for TiledImage to ask for all N tiles per frame and let ImageLoader deal with how many to actually request over the network. Requests that weren't initiated before the next frame could be discarded in order to not bog down the pipeline. That way, the logic about image requests is funneled through one place and would be potentially easier to handle via settings.

Another thought: I’m not sure if the imageLoaderLimit is still needed, as for http/2.0, there is no direct limit anymore for concurrent connections.

Since not all sites use http/2.0 we'd probably still need this for compatibility.

Yeah, I am still not sure, what the rationale behind the ImageLoader’s limit of requests is (as this is usually limited by the browser itself).
Currently, the TiledImage just selects which tile to be loaded for a frame. This PR is just about extending this to multiple best tiles.
To outsource the tile selection to the ImageLoader might probably work (although the ImageLoader might not know much about visibility, distance and level of a tile). But I guess this would be a bit more of a design change then.
Von: pearcetm @.>
Gesendet: Montag, 24. Juli 2023 18:40
An: openseadragon/openseadragon @.>
Cc: P. Schueffler @.>; Author @.>
Betreff: Re: [openseadragon/openseadragon] Introduced option maxTilesPerFrame (PR #2387)
However, the number of tilesPerFrame can in theory be n (for n = all tiles of the current frame). So, these numbers are somehow connected, but not really the same. E.g., if you have a low frame rate, but still want to load the image quickly, you need multiple tiles per frame, as the image loader will only get the tiles to load from the frames.
The way I am thinking about it is this. Currently, there are two different places where tile requests are throttled. My proposal would be for TiledImage to ask for all N tiles per frame and let ImageLoader deal with how many to actually request over the network. Requests that weren't initiated before the next frame could be discarded in order to not bog down the pipeline. That way, the logic about image requests is funneled through one place and would be potentially easier to handle via settings.
Another thought: I’m not sure if the imageLoaderLimit is still needed, as for http/2.0, there is no direct limit anymore for concurrent connections.
Since not all sites use http/2.0 we'd probably still need this for compatibility.
—
Reply to this email directly, view it on GitHub https://github.com/openseadragon/openseadragon/pull/2387#issuecomment-1648250414 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVEALZTPZGHAPCUE5FFCTLXR2QPDANCNFSM6AAAAAA2RMIO5E .
You are receiving this because you authored the thread.  https://github.com/notifications/beacon/ACVEAL5LDAWWBW46SHCMF3LXR2QPDA5CNFSM6AAAAAA2RMIO5GWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTCHZHC4.gif Message ID: @.*** @.***> >

I guess the point is that the number of concurrent downloads and number of selected tiles to download is indeed not the same. While the number of concurrent downloads could be high for high bandwidth, the number of best tiles should be low (only one or two per frame). If the number of best tiles would be as high as the number of concurrent connections (one number for both), then OSD would load many tiles per frame even if the frame is already outdated. Having said this, even this PR is not a perfect solution, as for 50 frames per second, OSD is theoretically already loading 50 tiles per second (with 1 best tile, N=1) and distributes them over a six concurrent requests, leading to 3-4s of tiling for the FOV. N=2 does not help a lot here. It helps queueing the tiles to be displayed faster, but the actual download is still distributed over the connections. The real bottleneck seems to be somewhere else. Am 24.07.2023 um 19:13 schrieb @.***:
@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Calibri; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; }
a:link, span.MsoHyperlink { color: blue; text-decoration: underline; }
code { font-family: "Courier New"; }
span.E-MailFormatvorlage21 { font-family: Calibri, sans-serif; color: windowtext; }
.MsoChpDefault { font-family: Calibri, sans-serif; }
@page WordSection1 { size: 612pt 792pt; margin: 70.85pt 70.85pt 2cm; }
div.WordSection1 { page: WordSection1; }Yeah, I am still not sure, what the rationale behind the ImageLoader’s limit of requests is (as this is usually limited by the browser itself). Currently, the TiledImage just selects which tile to be loaded for a frame. This PR is just about extending this to multiple best tiles. To outsource the tile selection to the ImageLoader might probably work (although the ImageLoader might not know much about visibility, distance and level of a tile). But I guess this would be a bit more of a design change then. Von: pearcetm @.> Gesendet: Montag, 24. Juli 2023 18:40An: openseadragon/openseadragon @.>Cc: P. Schueffler @.>; Author @.>Betreff: Re: [openseadragon/openseadragon] Introduced option maxTilesPerFrame (PR #2387) However, the number of tilesPerFrame can in theory be n (for n = all tiles of the current frame). So, these numbers are somehow connected, but not really the same. E.g., if you have a low frame rate, but still want to load the image quickly, you need multiple tiles per frame, as the image loader will only get the tiles to load from the frames.The way I am thinking about it is this. Currently, there are two different places where tile requests are throttled. My proposal would be for TiledImage to ask for all N tiles per frame and let ImageLoader deal with how many to actually request over the network. Requests that weren't initiated before the next frame could be discarded in order to not bog down the pipeline. That way, the logic about image requests is funneled through one place and would be potentially easier to handle via settings.Another thought: I’m not sure if the imageLoaderLimit is still needed, as for http/2.0, there is no direct limit anymore for concurrent connections.Since not all sites use http/2.0 we'd probably still need this for compatibility.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

This PR is just about extending this to multiple best tiles. To outsource the tile selection to the ImageLoader might probably work (although the ImageLoader might not know much about visibility, distance and level of a tile). But I guess this would be a bit more of a design change then.

I don't object to this PR - it seems like a reasonable first step. I was just thinking about whether addressing the issue from both perspectives might be useful.

I think it's worth stepping back here for a moment and thinking about the big picture. I don't want to derail this PR by turning it into a giant project, but I do feel it's worth thinking through how it fits into everything.
So, what are we trying to manage here? On the one hand, we want all the tiles as soon as possible, and on the other hand, we don't want to load unnecessary tiles. To the extent that loading tiles can't happen all at once, we also want to prioritize the tiles that will have the most visual impact.
If the user is just sitting in one location, it would make sense to fire off requests for every single tile simultaneously and let the browser do whatever throttling it needs to. We'd want to send the requests in priority order, in the hopes the browser takes the hint and gets us the tiles in that order.
On the other hand, if the user is panning quickly across the page, we don't want to fire off a ton of tile requests while we're moving, because while those tiles may have been important for a few frames during the pan, they are no longer necessary by the time we get to the destination. Our current system of only requesting one tile per frame helps deal with this issue, but it's a popular complaint that we still load more tiles during pans than people think we should.
We have to manage the tension between these things, because (as far as I know) once we request a tile, there's no good way to tell the browser/server "nevermind" and free up that bit of bandwidth.
I think ideally we would just somehow do the right thing in all circumstances, but if we can't, then we provide options for the dev to tune things to their scenario.
At the moment, the main option in this realm is imageLoaderLimit, but even its "unlimited" setting keeps us to just one tile request per frame. What we're talking about now is being able to go even more unlimited, so to speak.
Various thoughts:

It would be great if this change can improve things even for people who don't change a setting. Like maybe by default things just load faster. Of course, if we do that, we'll want to make sure there aren't negative consequences.
In particular, we don't want the new functionality to make the "queuing too many images during pan so things take a while to load once you get to your destination" problem worse.
I don't mind adding a new option (maxTilesPerFrame), but it would be nice if we can just "do the right thing" given the existing options available.
Again, I don't want to hold up a partial improvement with dreams of some giant improvement. But ideally, to the extent we add to the API with our partial improvement, it won't make it more difficult for us to do the giant improvement in the future.

Regarding having TiledImage just send all tiles it needs to ImageLoader so ImageLoader can deal with them, that has some appeal, but I'm concerned it could make the "queuing too many images" issue worse. I also want us to be conscious of if there are any performance implications doing all of the extra array manipulation that might be necessary.
So... There are some thoughts. Sorry no brilliant insights yet, but I figured I should at least get this much out. What do you think, @jetic83, @pearcetm?

@iangilman those are all great points and I agree with your concerns. On the one hand, this PR adds another level of control for developers which could be beneficial. On the other, additions to the API would need to be maintained (to some extent) moving forward even if another strategy is adopted in a future PR.
I think much of the tension comes down to two competing scenarios:

In high-bandwidth (low latency) settings, the one-tile-per-frame throttling is quite noticeable.
In low-bandwidth (high latency) settings, the tiles requested during animation delay the final viewport loading which becomes noticeable.

I'm just thinking out loud here and I don't know how to go about implementing this yet, but here's what seems like an ideal conceptual strategy to me:

Estimate how long average tile loading times are for a given TileSource, +/- depending on how many concurrent requests are in the pipeline already
When animating, calculate which tiles would be best to load, taking into account the estimated time to load (i.e. where the viewport will be when tiles are expected to become available). Ideally this would automatically take care of prioritizing tiles in the target viewport at the appropriate time.
Since requests aren't cancelable once initiated by the browser, don't request all tiles for the current (or predicted) viewport at once, but rather do some degree of throttling (depending on tile latency perhaps?).

Again, this is not straightforward to implement and I'm not necessarily advocating for trying to do so as part of this PR. Just keeping the ideas flowing...

I also agree on both of your comments. And I have two thoughts:

The current PR does not change much if people to not do anything. Since the default value of maxTilesPerFrame is 1, this is the same behaviour as now. However, dev people are able to tweak the app a bit and adjust them to frame rate and bandwidth. So, the PR can only help (but it does not worsen the queue of loading tiles).

Above comments try to optimize the number of loaded tiles during navigation, which is of course reasonable. But I think this is not the only big gain we can get. When considering my extreme example from issue #2384 , it loads the 95 tiles in 4 seconds. However, when I create a test html page with the same 95 tiles being  elements, the 95 tiles are loaded in below a second (0.9s), four times faster. This also includes loading and jpeg decompression (see screenshot below). So, OSD does a lot of things besides loading and decompression, hindering further tiles being loaded. So what we need is of course a low number of optimal tiles, but also an efficient tile display, close to putting just image elements on a webpage.

2. When considering my extreme example from issue Performance question / issue with frame rate when tiling on 4K displays #2384 , it loads the 95 tiles in 4 seconds. However, when I create a test html page with the same 95 tiles being simple image elements, the 95 tiles are loaded in below a second (0.9s), four times faster. This also includes loading and jpeg decompression (see screenshot below). So, OSD does a lot of things besides loading and decompression, hindering further tiles being loaded.

@jetic83 I've played around with the implementation in this PR and it seems like it works as intended - if I set maxTilesPerFrame = 1000 and then load an image, all the tiles downloads are initiated immediately, and only the browser throttles the requests. If you do the same with your 95 tile viewport, how long do the images take to load? I'd imagine it would be similar to the 95 raw image elements (0.9s), because under the hood the images actually are downloaded by image elements.
From my work and testing related to the webgl drawer, I can tell you that the current drawer can handle drawing upwards of 1000 tiles in a single viewport before performance starts to drop below 60fps, at least on my machine. So, this extra work shouldn't bog down appreciably on just 95 tiles... I feel like there must still be something going on with the download process here.

@pearcetm , yes, I thought the same, but there is more going on than just loading images.
With the above PR, the time to load a FOV indeed reduced.

most optimal with a low number of N tiles (3, e.g. for me), since the tiles are still sorted to be those of the actual FOV.
with a high number of N, 1000, the FOV takes again similar long as N = 1 (most probably since the tiles are loaded in a suboptimal order, and not the best Tiles per frame are prioritized).

@jetic83 Are you seeing this after navigation with animation, or loading just a single FOV? Can you put a demo page into the PR that demonstrates this behavior? That would probably help track down the underlying issue(s). I am interested in making this more optimal as well (also for pathology viewers).

sure, here:
https://slides.path.med.tum.de/

Looks like your page requires a login. If you can add a stripped down version of this page to the demo directory in the project instead, it would make it easier to test out different potential fixes in OSD and/or viewer settings.

Well, it uses magic links, pretty much every email works (no password required). However, I can try to setup a demo as well (but not sure if I can find a DZI in the demo)

It should work to point the demo page at the same tile source URL as your existing app, I would think. The image data itself doesn't need to be included in the PR.

This wouldn't work as the whole tilesource requires authorization via the login. But I can use the duomo tilesource. It's in the demo folder now.

@jetic83 Using your demo page, I set the N to different values, comparing 1 vs 3 vs 300 (which allowed making all the requests at once). Looking at the network tab, I get the following:
Cache disabled

N=1: ~1500 ms to load all images
N=3: ~850 ms.
N=300: ~1050 ms (longer than N = 3!)

Cache enabled

N=1: ~1450 ms
N=3: ~450 ms.
N=300: ~100 ms

Making 100s of requests at once does bog down the network which is less optimal than doing additional per-frame throttling - at least, on my network and retrieving images from the demo image server.  When images are in the browser cache, there's huge benefit to making all the requests up front (for obvious reasons).
I'm still not seeing what you're describing where performance at N=1000 is as slow as N=1, but maybe that's due to differences in number of tiles/number of concurrent network requests. On my setup it really is the network that takes all the time though either way.

Yes, i see similar things… the multiple tiles per frame have indeed effect. Am 31.07.2023 um 23:50 schrieb pearcetm @.***>:
@jetic83 Using your demo page, I set the N to different values, comparing 1 vs 3 vs 300 (which allowed making all the requests at once). Looking at the network tab, I get the following:
Cache disabled
N=1: ~1500 ms to load all images
N=3: ~850 ms.
N=300: ~1050 ms (longer than N = 3!)
Cache enabled
N=1: ~1450 ms
N=3: ~450 ms.
N=300: ~100 ms
Making 100s of requests at once does bog down the network which is less optimal than doing additional per-frame throttling - at least, on my network and retrieving images from the demo image server.  When images are in the browser cache, there's huge benefit to making all the requests up front (for obvious reasons).
I'm still not seeing what you're describing where performance at N=1000 is as slow as N=1, but maybe that's due to differences in number of tiles/number of concurrent network requests. On my setup it really is the network that takes all the time though either way.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

@iangilman pearcetm and me both found improvements using this PR. Should I remove the html page in the demo folder again before merging, or do you want to include this?

@jetic83 I think we should keep the HTML file. Sounds like you're feeling ready to merge this? It looks good to me. I think there are definitely additional things we could do down this path, but this feels like a meaningful step.
@pearcetm What do you think? Shall we merge it?

I agree this is a nice option for developers to have. I was just playing around with the demo page a bit. I set maxTilesPerFrame: 1000 and imageLoaderLimit: 3 to see how it would work to have the image loader do the throttling (rather than loading a fixed number per frame). I haven't figured out the performance implications yet in terms of network traffic. However, I noticed what I think is a bug in the current implementation:

Tiles load left-to-right and top-to-bottom rather than center-out
Lower-res tiles are not loaded first

This definitely makes the tiling process more noticeable. The issue, at least for the order of tiles within a level, is that _sortTiles is only called when the maxTilesPerFrame is exceeded - if it isn't, the tiles don't get sorted at all, and the tiles are requested in a suboptimal order. I'm not entirely sure why lower-res tiles aren't being prioritized.

It was by design.. in a previous commit, we had the sorter sort the best tiles always, even if all of them are loaded (when there are less tiles to load than N). This was to save time sorting.. but I am happy to change it back, sorting the whole array always.

This might make sense, but in a future PR. The N tiles are just put into a job queue in the image loader, and sorting the whole job queue seems to raise a few new questions (when to sort the queue exactly, what to do with previous tiles in the queue)
Also, wouldn't it make more sense rather than resorting the job queue to reduce the job queue in the first place? So adding tiles from a new frame should remove the tiles from the old frame? I guess this is what OSD does anyway? @iangilman any insight here?
So it would require a bit more diving into the details, which I would suggest to do as a follow up. This discussion for the 6 lines of code shows already that there is a lot more to do ;)

I still propose to load the N tiles always, as this contributes to a good look and feel

I agree with only sending the N best tiles to the image loader - I just meant that rather than sorting the array every time a tile is processed (called from _updateTile), it could just be sorted once right before starting to load tiles. I wasn't suggesting sorting the entire image loader queue - rather, immediately before sending N tiles to the image loader.

So adding tiles from a new frame should remove the tiles from the old frame? I guess this is what OSD does anyway?

I think this is what happens already:
https://github.com/openseadragon/openseadragon/blob/4a3fc5b3259c6f8317779b8d16e791afa7a510cc/src/viewer.js#L3795-L3796

I just looked at tue image loader. In a regular setting with no job limit (this is the other parameter), there is no job queue actually, but all jobs are immediately started.
So these jobs cannot be resorted again. I guess this is a larger thing to investigate when one wants to optimize the image loading process further.
Therefore, I propose to see this PR as a starting point.

Thanks, @pearcetm , I changed it to sort it only once instead of when tiles are added.

@pearcetm Thank you for catching the sorting issue! I agree we want to be as efficient as possible, but not at the expense of visual quality.
@jetic83 Thank you for cleaning it up. Looks like we could go a little further. Right now the sort happens in _updateLevel, but it seems it could happen just once before the _loadTile call in _updateLevelsForViewport. Also, there's still a sort happening in _compareTiles. Presumably it would be more efficient to not do that and just rely on the one before _loadTile.

Also, there's still a sort happening in _compareTiles. Presumably it would be more efficient to not do that and just rely on the one before _loadTile.

I agree. Thanks for describing it in this way @iangilman, you've said what I was trying to say above. In fact, unless I'm missing something, _compareTiles shouldn't even be necessary with this approach, since selecting the best tiles to load will be handled at the very end.

@iangilman , @pearcetm , it is possible to sort the tiles only once in the end. But then we need to collect all tiles in the array first, und then after sorting shrink down to N tiles.
Now, the _compareTiles function only really sorts the array if there are too many tiles, in order to know which one to pop.
If you prefer the first approach I'm fine to change it.

I think we always want the set of tiles that get sent to the loader to be sorted, so they load in priority order.
As for whether doing a lot of little sorts vs one big sort is faster, I guess I don't know for sure. If we have 100 candidate tiles and we want to load 2 tiles per frame, that means either 98 sorts of 3 tiles or 1 sort of 100 tiles (I think). I guess we could do some speed testing, but that might be overkill.

Not sure if we even can test this difference, as this depends very much on the N used, and the screen size of the user influencing the tile number when navigating.
Most people will keep that N unset, defaulting to N=1. Then, for k tiles loaded in a navigation event, we would do k single comparisons vs. one sorting of k tiles. Not sure which sorting algorithm javascript uses? Google says, its complexity is O(klogk), meaning the current solution is faster.

Yeah, over the weekend I was thinking about just that... For the default case of N = 1, I think it'll be faster to do 100 sorts of 2 items than 1 sort of 100 items. Let's stick with that.
I think that means removing the _sortTiles in _updateLevel and also moving the other _sortTiles outside of the if (previousBest.length > maxNTiles) (so the tiles are always sorted, even when there are less than the max, so they show up in priority order).
Other than that, I think this is ready to go. Thank you for sticking through all this conversation! It's good for us to think these things through.

@iangilman  done.

@jetic83 @iangilman I agree with having an optimization for the default use-case, as has now been implemented - e.g. sorting 2 tiles 100 times, rather than 100 tiles once - when the default N = 1. However, I am concerned that the other end of the spectrum will now be quite inefficient: sort(2 items), sort(3 items) ... sort(99 items), sort(100 items) is a lot more sorting than just sorting 100 items once!
On the other hand, it probably honestly doesn't matter either way. In the demo page for this PR, I just did some performance testing. In my browser, sorting 140 tiles using _sortTiles() takes ~0.0022 milliseconds (averaged over 10,000 and 100,000 operations, measured with performance.now()). So, even repeating this 100 times adds only a fraction of a millisecond to the frame calculations.


Add metadata to payload

add metaData to the payload to send arbitrary data to bugsnag per the open issue.

re #14


Pull Request Issue checker workflow🚀

Description: We need to create a GitHub Actions workflow that automates the validation of pull requests (PRs). This workflow will ensure that all PRs meet the following criteria before being merged:
PR Description Check: Every PR must have a description. If the description is missing, the PR should fail the check.
Acceptance Criteria:
A GitHub Action workflow is triggered on PR events (opened, edited).
The workflow checks the PR body for:
A non-empty description.
The presence of Fixes # or Fixes #NEW.
If the criteria are not met:
The workflow should fail and return clear error messages.
If the checks pass:
A confirmation message is outputted.
please @vanshchauhan21 assign this with level 3 label

can you please @vanshchauhan21 assign me this issue

can you please @vanshchauhan21 assign me this issue

Done bro 👍


Loads xhdpi instead of hdpi on iPad

Single column streams on screens 768pts or wider now load the xhdpi asset url instead of the hdpi one. This gets us most of the way to full-width images on iPad. Further explorations in scaling are needed. They've been captured in the roadmap card https://trello.com/c/8SU0XRnV/263-improve-the-ios-app-experience-on-ipad.
Finishes #140426449

Executed 2576 tests, with 0 failures (0 unexpected) in 242.655 (244.169) seconds


Jitter ?

https://rust-embedded.github.io/book/concurrency/index.html

which comes at a cost to overhead and interrupt latency and jitter.

I don't really understand what the consequences are from disabled interrupts. Is it not so that interrupts will just be ignored ? But latency indicates they will be delayed? And what about jitter?

I think explaining interrupt latency and jitter is out of scope for the book (and especially for the concurrency section); the introduction says we assume familiarity with interrupts in an embedded context.

Is it not so that interrupts will just be ignored ? But latency indicates they will be delayed? And what about jitter?

When interrupt handling is disabled in a critical section, interrupts are left pending, and will be serviced once interrupt handling is re-enabled (hence the additional latency and jitter).


branch: 0.1

Left open for the first version of Scenery.

@jonathanolson can this be closed and branch deleted?

See https://github.com/phetsims/joist/issues/233#issuecomment-348924015.
I can't see how this would be worth the effort.

On hold until discussion in https://github.com/phetsims/joist/issues/233#issuecomment-348924015 is complete


Cron timing

[ ] Catch the war_block update time
[ ] Try: 5:30 UTC (8:30 Europe/KIEV)

Merge when ready: https://github.com/andriilive/russia-casualties-ukraine-war-parser/pull/14


Vulnerable dependency

Describe the bug
SAST scanning of our app detected vulnerable dependency:
Description: `handlebars` before 4.7.7 are vulnerable to Remote Code Execution (RCE) when selecting certain compiling options to compile templates coming from an untrusted source.
OS

[x] ios
[x] android

Packages

version of react-native: 0.64.2
version of react-native-ultimate-config: 3.2.3

Additional context
It's critical for us since we can't move to PROD with this issue.

hi @tr3v3r I'll fix this but FYI: my library has open range dependency spec for handlebars: "^4" and exact version is likely to be determined by your lockfile. I recommend you to review lockfiles in your application and consider upgrading this transitive dependency on your side via npm update or yarn upgrade without changing anything in react-native-ultimate-config.
thanks for the report!

published as part of 3.4.0

@maxkomarychev thanks for the response, but issue was resolved by updating to the last version of your package ( handlebars also updated ). We can close the issue


Which script to use for 3D FNO and missing normalizer

Congratulations on your nice paper and the stunning results. My team and I want to use your technique and thus had a closer look into your implementation. We have two questions:

We have a hunch that the script in scripts/fourier_3d_time.py is the one we should use for the 3D FNO rather than the one linked in the README: fourier_3d.py. The latter seems to apply the Fourier transformation to the time grid points rather than the values at each timestep.

However, in scripts/fourier_3d_time.py there is no normalizer (actually there is one in line 315 but it is commented) and we are wondering if there is a reason why no normalizer is used?

Thanks for your help:)

Thanks for the kind words : )
In our setting, we use 3D FNO for the 2D Navier-Stokes problem and treated the time dimension as the third dimension to do convolution. In fourier_3d.py we input the first 10 time steps and output the next 40 time steps. In scripts/fourier_3d_time.py, we still do time-convolution, input the first 10 time steps, but output the next 10 time steps, and iterate four times to reach the 40 time steps.
Do you want to apply FNO on 3D Navier-Stokes problems?

Thanks for the prompt reply. There seems to be a misconception on our side. We indeed try to apply the script to the 2D Navier-Stokes data and it took us some time to understand the data preparation for the 3D case. We ended with this snippet which should implement the same logic:
import torch

ntrain = 1
S = 3
T_in = 2
T = 4

train_a = torch.arange(ntrain * S * S * T_in)
train_a = train_a.reshape(ntrain, S, S, 1, T_in)
# T_in = 0    T_in = 1
# ┌──┬──┬──┐  ┌──┬──┬──┐
# | 0| 2| 4|  | 1| 3| 5|
# ├──┼──┼──┤  ├──┼──┼──┤
# | 6| 8|10|  | 7| 9|11|
# ├──┼──┼──┤  ├──┼──┼──┤
# |12|14|16|  |13|15|17|
# └──┴──┴──┘  └──┴──┴──┘
train_a = train_a.repeat([1, 1, 1, T, 1])

gridx = torch.linspace(0, 1, S, dtype=torch.float)
gridx = gridx.reshape(1, S, 1, 1, 1).repeat([1, 1, S, T, 1])
gridy = torch.linspace(0, 1, S, dtype=torch.float)
gridy = gridy.reshape(1, 1, S, 1, 1).repeat([1, S, 1, T, 1])
gridt = torch.linspace(0, 1, T + 1, dtype=torch.float)[1:]
gridt = gridt.reshape(1, 1, 1, T, 1).repeat([1, S, S, 1, 1])

train_a = torch.cat(
    (
        gridx.repeat([ntrain, 1, 1, 1, 1]),
        gridy.repeat([ntrain, 1, 1, 1, 1]),
        gridt.repeat([ntrain, 1, 1, 1, 1]),
        train_a,
    ),
    dim=-1,
)

As far as we understand the application of Fourier transformation, you apply a 3D Fourier transformation in x, y and t for each channel, i.e., 1D Fourier transformations for each y and t in x, then for each Fx and t in y and finally for each Fx and Fy in t (or in a different sequence which shouldn't effect the result).
Let's look at the transformation sequence in x:
print("\nx @ y=0, t=0")
print(train_a[0, :, 0, 0])

print("\nx @ y=0, t=1")
print(train_a[0, :, 0, 1])

print("\nx @ y=0, t=2")
print(train_a[0, :, 0, 2])

print("\nx @ y=1, t=0")
print(train_a[0, :, 1, 0])

print("\nx @ y=1, t=1")
print(train_a[0, :, 1, 1])

print("\nx @ y=1, t=2")
print(train_a[0, :, 1, 2])

>>> x @ y=0, t=0
>>> tensor([[ 0.0000,  0.0000,  0.2500,  0.0000,  1.0000],
>>>         [ 0.5000,  0.0000,  0.2500,  6.0000,  7.0000],
>>>         [ 1.0000,  0.0000,  0.2500, 12.0000, 13.0000]])
>>>
>>> x @ y=0, t=1
>>> tensor([[ 0.0000,  0.0000,  0.5000,  0.0000,  1.0000],
>>>         [ 0.5000,  0.0000,  0.5000,  6.0000,  7.0000],
>>>         [ 1.0000,  0.0000,  0.5000, 12.0000, 13.0000]])
>>>
>>> x @ y=0, t=2
>>> tensor([[ 0.0000,  0.0000,  0.7500,  0.0000,  1.0000],
>>>         [ 0.5000,  0.0000,  0.7500,  6.0000,  7.0000],
>>>         [ 1.0000,  0.0000,  0.7500, 12.0000, 13.0000]])
>>>
>>> x @ y=1, t=0
>>> tensor([[ 0.0000,  0.5000,  0.2500,  2.0000,  3.0000],
>>>         [ 0.5000,  0.5000,  0.2500,  8.0000,  9.0000],
>>>         [ 1.0000,  0.5000,  0.2500, 14.0000, 15.0000]])
>>>
>>> x @ y=1, t=1
>>> tensor([[ 0.0000,  0.5000,  0.5000,  2.0000,  3.0000],
>>>         [ 0.5000,  0.5000,  0.5000,  8.0000,  9.0000],
>>>         [ 1.0000,  0.5000,  0.5000, 14.0000, 15.0000]])
>>>
>>> x @ y=1, t=2
>>> tensor([[ 0.0000,  0.5000,  0.7500,  2.0000,  3.0000],
>>>         [ 0.5000,  0.5000,  0.7500,  8.0000,  9.0000],
>>>         [ 1.0000,  0.5000,  0.7500, 14.0000, 15.0000]])

In this example the first three values are augmented grid positions x, y, t and the last two are the values at T_in=0 and T_in=1. To be honest, we don't understand why a Fourier transformation of the grid, e.g.,
train_a[0, :, 0, 0, 0]
>>> tensor([0.0000, 0.5000, 1.0000])

could yield useful information. To be fair, the Fourier transformation is carried out after the fully connected layer self.fc0 but there is still a lot of redundant information?
Secondly, as far as we understand the code, the temporal Fourier transformation is not evaluated in T_in which we would naively expect but instead in copies of the same data, e.g.,
train_a[0, :, 0, 0, 3]
train_a[0, :, 0, 1, 3]
>>> tensor([ 0.,  6., 12.])
>>> tensor([ 0.,  6., 12.])

The example in scripts/fourier_3d_time looks more like as what we would expect: Here the Fourier transformation is evaluated in T_in where at each channel, i.e., for a fixed point in space and time, the value is a 4D vector: (x, y, t, v) where v is the vorticity. The missing piece here is the normalization though.
We might be utterly wrong here and hope that you can enlighten us:)

The input has the shape (x, y, T_in); the output has the shape (x, y, T). In fourier_3d.py we treat T_in as the channel dimension and repeat the input in T's dimension, (x, y, T_in) -> (x, y, T, T_in) = (x, y, t, channel). Then we do FFT on x,y,t.
train_a = train_a.reshape(ntrain,S,S,1,T_in).repeat([1,1,1,T,1])
test_a = test_a.reshape(ntest,S,S,1,T_in).repeat([1,1,1,T,1])

We do FFT in T's dimension instead of T_in's dimension, because in many cases T_in=1 (we only have the initial condition), so it won't make sense to do FFT in T_in's dimension.
The prepared input now has the shape  (x, y, T, T_in) = (x, y, t, channel), and it's constant in t-dimension, we add the grid to break the symmetry. Otherwise, the output will still be constant in t. On a higher level, it also helps to capture grid-related information (considering self.fc0).
Besides, we want to avoid using normalization. In many cases, it can be quite helpful, but if one wants to extrapolate to unseen time periods, normalization may not be applicable.

Thanks for your help. Much appreciated!
I think we are almost on the same page. But, assuming that our snippet above is correct, the FFT in t for channels beyond the grid information, e.g, i=3, is based on a vector that is uniform before self.fc0:
# t @ x=0...2, y=0, channel=3
train_a[0, 0, 0, :, 3]
train_a[0, 1, 0, :, 3]
train_a[0, 2, 0, :, 3]
>>> tensor([0., 0., 0., 0.])
>>> tensor([6., 6., 6., 6.])
>>> tensor([12., 12., 12., 12.])

Do you see that self.fc0 significantly breaks this uniform distribution?

Hmm, probably self.fc0 along won't change it much. But after several layers of self.w0 ... self.w3 and F.relu, it may be something useful.

Ok. I understand your point and your great results also speak for themselves.
Returning to my original questions this means:

You use fourier_3d.py to produce the results in Sec. 5.3 and scripts/fourier_3d_time.py is not referred to in the paper (?)
You use feature normalization in fourier_3d.py but not in scripts/fourier_3d_time.py which makes line 315 in the latter a copy & paste remnant (?)

Thanking you again:)

Hi Nis, It was nice to talk to you this week. For your question

Yes, we use fourier_3d.py to produce the results in Sec. 5.3, not scripts/fourier_3d_time.py.
Yes, that's right.

The input has the shape (x, y, T_in); the output has the shape (x, y, T). In fourier_3d.py we treat T_in as the channel dimension and repeat the input in T's dimension, (x, y, T_in) -> (x, y, T, T_in) = (x, y, t, channel). Then we do FFT on x,y,t.
train_a = train_a.reshape(ntrain,S,S,1,T_in).repeat([1,1,1,T,1])
test_a = test_a.reshape(ntest,S,S,1,T_in).repeat([1,1,1,T,1])

We do FFT in T's dimension instead of T_in's dimension, because in many cases T_in=1 (we only have the initial condition), so it won't make sense to do FFT in T_in's dimension.
The prepared input now has the shape (x, y, T, T_in) = (x, y, t, channel), and it's constant in t-dimension, we add the grid to break the symmetry. Otherwise, the output will still be constant in t. On a higher level, it also helps to capture grid-related information (considering self.fc0).
Besides, we want to avoid using normalization. In many cases, it can be quite helpful, but if one wants to extrapolate to unseen time periods, normalization may not be applicable.

Can you explain why are you are doing this a bit more? What exactly is a channel?


Request for new release

I would love to use the system prompt feature that's not yet included in any release.
Would you consider dropping one? (Please feel free to point me at the release management doco if this question is already answered somewhere)
Cheers for a great tool!

Hey, thanks for the nudge. It's definitely on our to do list to have more consistent releases. Will bring this up with the team and aim to get one out asap :)

@HaleTom Just released a new version. Thanks again :)
https://github.com/charmbracelet/mods/releases/tag/v1.2.2


Issues with now playing

Hi Sorry i'm a noob. I got the software running paid for the pro version and setup the overlay in obs and  the plugin for my twitch channel. I have a prime 4 connected with xlr splitter to single 3.5 into the onboard  audio in. I feel like i'm missing a step somewhere because it does not pickup the live tracks. I think i'm missing a step? Do I need to connect the prime 4 to my computer another way for this to work? Thanks in advance and do you have a discord channel? I have questions about adding some features that I would be happy to donate for if possible. Thanks

I'm guessing this only works in computer mode but I want to use it in standalone. I might have to rethink this.

I'm guessing this only works in computer mode but I want to use it in standalone. I might have to rethink this.


fix Fix Arrow Flight SQL regression-test

What problem does this PR solve?
Problem Summary:
Fix Arrow Flight SQL profile
Fix regression-test frametwork
Check List (For Author)

Test

[ ] Regression test
[ ] Unit Test
[ ] Manual test (add detailed scripts or steps below)
[ ] No need to test or manual test. Explain why:

[ ] This is a refactor/code format and no logic has been changed.
[ ] Previous test can cover this change.
[ ] No code files have been changed.
[ ] Other reason

Behavior changed:

[ ] No.
[ ] Yes.

Does this need documentation?

[ ] No.
[ ] Yes.

Check List (For Reviewer who merge this PR)

[ ] Confirm the release note
[ ] Confirm test cases
[ ] Confirm document
[ ] Add branch pick label

run buildall

run buildall


branch-solution fails with Ubuntu runners

Running with an ubuntu-latest runner, the branch-solution action fails with the message:
Error: failed: Error: Cannot determine HEAD from remote: ...

On Windows runners, the results of git remote show log are returned as a single line, whereas on Ubuntu the results are returned as multiple lines. This causes the map() function to return an array with multiple elements in, which then fails the check for a single element.

We added these logging statements to debug it:
  const remotes = yield git.run(["remote", "show", "origin"]);
  logger.info(`remotes: ${remotes}`);
  const head = remotes.map((line) => {
    logger.info(`line: ${line}`);
    const branch = line.match(/HEAD branch:\s*(\S+)/);
    if (branch && branch.length >= 2) {
      logger.info(`branch: ${branch}`);
      return branch[1];
    }
  });
  logger.info(`head: ${head}`);
  if (!head || head.length < 1 || head.length > 1 || !head[0]) {
    throw new Error(`Cannot determine HEAD from remote: ${repoUrl}`);
  }

Here's the output from the different runners:
windows-latest Runner
  remotes: * remote origin
    Fetch URL: https://github.com/hud-govt-nz/ppm
    Push  URL: https://github.com/hud-govt-nz/ppm
    HEAD branch: main
    Remote branches:
      AzureDevOps-20220821-2245                                  tracked
      AzureDevOps-20220822-0131                                  tracked
      build2                                                     tracked
      capgemini_port                                             tracked
      dependabot/nuget/PPMUnitTestProject/Newtonsoft.Json-13.0.1 tracked
      install-git-lfs                                            tracked
      main                                                       tracked
      specflow                                                   tracked
      specflow-powerapps-bindings                                tracked

 line: * remote origin
    Fetch URL: https://github.com/hud-govt-nz/ppm
    Push  URL: https://github.com/hud-govt-nz/ppm
    HEAD branch: main
    Remote branches:
      AzureDevOps-20220821-2245                                  tracked
      AzureDevOps-20220822-0131                                  tracked
      build2                                                     tracked
      capgemini_port                                             tracked
      dependabot/nuget/PPMUnitTestProject/Newtonsoft.Json-13.0.1 tracked
      install-git-lfs                                            tracked
      main                                                       tracked
      specflow                                                   tracked
      specflow-powerapps-bindings                                tracked

  branch: HEAD branch: main,main
  head: main

ubuntu-latest Runner
  remotes: * remote origin,  Fetch URL: https://github.com/hud-govt-nz/ppm,  Push  URL: https://github.com/hud-govt-nz/ppm,  HEAD branch: main,  Remote branches:,    AzureDevOps-20220821-2245                                  tracked,    AzureDevOps-20220822-0131                                  tracked,    AzureDevOps-20220822-0153                                  tracked,    build2                                                     tracked,    capgemini_port                                             tracked,    dependabot/nuget/PPMUnitTestProject/Newtonsoft.Json-13.0.1 tracked,    install-git-lfs                                            tracked,    main                                                       tracked,    specflow                                                   tracked,    specflow-powerapps-bindings                                tracked,

  line: * remote origin
  line:   Fetch URL: https://github.com/hud-govt-nz/ppm
  line:   Push  URL: https://github.com/hud-govt-nz/ppm
  line:   HEAD branch: main
  branch: HEAD branch: main,main
  line:   Remote branches:
  line:     AzureDevOps-20220821-2245                                  tracked
  line:     AzureDevOps-20220822-0131                                  tracked
  line:     AzureDevOps-20220822-0153                                  tracked
  line:     build2                                                     tracked
  line:     capgemini_port                                             tracked
  line:     dependabot/nuget/PPMUnitTestProject/Newtonsoft.Json-13.0.1 tracked
  line:     install-git-lfs                                            tracked
  line:     main                                                       tracked
  line:     specflow                                                   tracked
  line:     specflow-powerapps-bindings                                tracked
  line:
  head: ,,,main,,,,,,,,,,,,
  Error: failed: Error: Cannot determine HEAD from remote: https://github.com/hud-govt-nz/ppm

This issue is still occurring for me on ubuntu-latest with the "current" @v0 tag, commit https://github.com/microsoft/powerplatform-actions/commit/cf1fafbec1a01093a470b346d35d94d1cfa5ef3a
Error: failed: Error: Cannot determine HEAD from remote: xxx/yyyy


RFC: frameLogger

I'd like to be able to customise how to deal with frame events.  But logging to string is a bit restrictive.
Putting this up as a dreadful strawman to see if there is any prevailing thoughts here?

We’ve used internal as a lousy SPI for the file system. That’s ugly, but workable. Doing similarly for analytics events might be a good way to help that interface to mature.
What if the interface took frame data and was responsible for calling into the logger - or not? That'd be interesting at least.

What if the interface took frame data and was responsible for calling into the logger - or not? That'd be interesting at least.

I'm happy to put up a PR for discussion following that approach, and leave the logging implementation as the default.  I'd put the interface and the set method behind the internal packages.

@yschimke SGTM!

I’ll close this. Please open a separate PR when your FrameLogger is ready.


[ci] add mypy to as a part of qa

Changes:

Adds mypy step to QA checks

TO BE MERGED AFTER: https://github.com/usdigitalresponse/cpf-reporter/pull/506

Thanks for the feedback! I believe I addressed all the comments, but let me know if I missed anything 😄


Bug: you can subscribe to yourself

I managed to subscribe to myself from one of my articles

😱 😄
I'll fix it!

I already have 😅 there's a PR open

Ha, sorry 😄 Thank you Isaac 🙏