[Develop] Support all BK/Travis cases in Submodule Regression Script

Problems:

When manually running a forked PR using pull/7924/head:develop-submodule-regression-fix, the script will fail to use the merged commit for that forked PR.
git log logic wasn't working and throwing exit 1

Solutions:

Support if the PR slug exists (it's a forked PR) by doing git fetch/checkout of the ghost/merged commit.
Added no-pager and changed the logic to wrap in test

Travis

Manual branch (no PR):

Same branches: https://travis-ci.com/EOSIO/eos/jobs/236233124

PR branch:

Doesn't run...

Manual PR branch:

Same branches: https://travis-ci.com/EOSIO/eos/jobs/236236441

Forked PR branch https://github.com/EOSIO/eos/pull/7924:

PASS: https://travis-ci.com/EOSIO/eos/jobs/236230376
FAIL: https://travis-ci.com/EOSIO/eos/jobs/236218853

Manual Forked PR branch https://github.com/EOSIO/eos/pull/7924:

Can't run?

Buildkite

Manual branch (no PR):

Same branches: https://buildkite.com/EOSIO/eosio/builds/17592#554e460e-0dd1-4ef7-9301-ec9fa5e0e48c

PR branch: https://github.com/EOSIO/eos/pull/7932:

PASS: https://buildkite.com/EOSIO/eosio/builds/17588#87634f70-3e0b-43e5-b438-3c4895999d59
FAIL: https://buildkite.com/EOSIO/eosio/builds/17596#f736a9ae-976b-4dc3-8fe2-af19aad1892a

Manual PR branch https://github.com/EOSIO/eos/pull/7932:

Same branches: https://buildkite.com/EOSIO/eosio/builds/17593#a9a9cecd-001c-43e9-bb3b-b07b3309c14e

Forked PR branch https://github.com/EOSIO/eos/pull/7924:

Doesn't run...

Manual Forked PR branch https://github.com/EOSIO/eos/pull/7924:

Same branches: https://buildkite.com/EOSIO/eosio/builds/17599

1.8.x: https://github.com/EOSIO/eos/pull/7936
1.7.x: https://github.com/EOSIO/eos/pull/7938

Submodule running in travis (with if at end) works: https://travis-ci.com/EOSIO/eos/jobs/236503103


Update index.html - Issue Add links

Index.html with added links and wrapping rest of the buttons into element

Awesome!!! Looks good, thanks so much for your contribution to the project :100:


gitstatus: also colorize other projects

Hello,
I'm trying to make gitstatus colorize other projects than the first one.
For instance, here, only the first project "www" is colorized but not the ones below it (triage/chronos):

I can try to implement that but I'm not sure how the projects are handled at app and treeview level. Would someone be able to do that or explain what I would need to do to make it work?
Thank you.

I think you could just iterate over core.project_directories here:
https://github.com/lite-xl/lite-xl-plugins/blob/f02ce208852d5682c4a088e40ad9958bfb6180a4/plugins/gitstatus.lua#L85-L105
I don't think you'd need to change anything else.

Ah well seen... I'm not familiar (yet) with all the core functions. Seems good, I'll experiment. Thanks a lot!


guide: new Overview page

OP
Per https://github.com/iterative/dvc.org/issues/144#issuecomment-1206648437:

Index page: remove?
What is DVC: dissolve into some page outside the user guide (and maybe in the home page/outside of docs).

Note that clicking the UG nav entry will now open directly in https://dvc.org/doc/user-guide/project-structure (for now).
UPDATE:

Per https://github.com/iterative/dvc.org/issues/144#issuecomment-1261716474:

turn it into an Overview instead, which would combine its existing Core Features section as well as Related Technologies (which also addresses "Related Technologies: dissolve into some page" from the OP).

Also moves/reinforces other sections of What is DVC? in other existing docs.
Updates links and redirects accordingly .

In review app: https://dvc-org-guide-break-up--bvcwlb.herokuapp.com/doc/user-guide

This is starting to grow more than I imagined. Requesting review to make sure our plan was good ☝🏼

UPDATE: Actually, per https://github.com/iterative/dvc.org/issues/144#issuecomment-1261716474 I'm going to transform the Core Features section of What is DVC? as well as the Related Technologies page into an overview for the UG. For now it will be the first sub-page (no index page) but it could also be the index page itself. WDYT @dberenbaum ?

Sounds good! There's a separate task to combine Core Features and Feature pages (both rel https://github.com/iterative/dvc.org/issues/144#issuecomment-1206648437 and https://github.com/iterative/dvc.org/issues/3833) so I suppose we can merge this indeed 🙂

Cc @dberenbaum just FYI on this change (review no longer needed but if there's any feedback feel free to leave it).

Note that Studio docs have a similar page called How it works, so this may be a bit of a pattern.


Update colour palette and add logo

Closes #816 once merged.

The favicon is too small :)

Updated with all color="secondary" I can find + larger favicon


moved and rewrote rolldice() into a function.

Not super confident in the bug freeness of this all.  Maybe have an experimental branch i can PR?


Units

Apologies if this information is available somewhere and I missed it. What are the units of various quantities in this data set?
My best guesses are:

coordinates: Bohr
energy: Hartree
force: Hartree/Bohr
charge/density: a.u.
dipole: debye

i believe the coordinates are in units of Angstrom, along with the forces. @isayev  could you correct me if I am wrong?


fix: x server access

the latest changes added an additional check to the call to xhost, this prevented the container from being able to access xserver on my host.
also, the screensaver inhibit code was lost in https://github.com/netbrain/zwift/pull/108, I returned it here

@perrin4869 - I did change it to use XAUTHORITY, can you tell me what XAUTHORITY is on your host, also what OS/ Display manager (Gnome/ X11 etc) .
@netbrain - don't see any issue with this push request it seems that X is different on different systems so might need that setting.

@sHedC I'm running i3wm on slackware64-current, ~/.Xauthority exists but I am not familiar with X server permissions settings enough to know why this change is required on my system 😅

Me either :).  Basically the XAUTHORITY Environment variable is used to identify access to the Xhost.  However it seems different distributions/ WM's change it.
I think that it seems safer to run the xhost regardless I see you can also run it in wayland so relaxing that it runs as long as you are not trying experimental wayland.
I love slackware used to build it if I remember with about 15 floppy disks in the 90's.  Not used it since 2000.

ok, so I looked a bit into this topic, and I think the issue is that the cookie listed by xauth depends on the hostname. In my case, I have:
$ xauth list
landau.julian.dotcore.co.il/unix:0  MIT-MAGIC-COOKIE-1  57652db05ffc7b47d182bfd8b2987260
$ hostname
landau.julian.dotcore.co.il

I think that when the container tries to connect using this cookie, it gets rejected due to the different hostname.
According to the internet, it is possible to create a cookie in such a way that the hostname does not matter
XAUTH=~/.xauth.docker
touch $XAUTH
xauth nlist :0 | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -

And then use ~/.xauth.docker instead of ~/.Xauthority (or whatever file $XAUTHORITY is pointing to in your system) and should be good to go? but haven't properly tested this. The nice thing about this approach, if it works, is that it doesn't depend on the container hostname, and can be setup before the container is run.

Why not just set the container hostname to be equal to host machine?

Seems this is only an option for docker there is no option for this in podman.

Really? https://docs.podman.io/en/latest/markdown/podman-run.1.html#hostname-h-name
Docs says it's possible.

actually, never mind, the hostname wasn't the problem at all ^^;;
turns out that XAUTHORITY was only being set for wayland...

Stopped worrying :)
I think XAUTHORITY is supposed be the way forward however would prefer to have a method that works for the majority of people and not break it as its the least important thing to the program actually working :)
I will probably install Slack and try it, need to work oout if I can automate this with Proxmox as this is now my daily driver if I can automate will make it a lot easier.

Since slack or gentoo ship rather unmodified builds, if you pair that with a simple desktop manager such as i3wm, it's a good platform to test software like this, since you are almost guaranteed not to be fighting with the WM for control over the X server, power settings, dbus, etc :)


how to use key keypoints detection

Thank you for sharing, Can this library be used for keypoints detection?

Currently not.


MATLAB     ImportError: numpy.core.multiarray failed to import

ImportError: numpy.core.multiarray failed to import
/home/tango/usr/local/torch/install/bin/luajit: ...ngo/usr/local/torch/install/share/lua/5.1/trepl/init.lua:389: ...ngo/usr/local/torch/install/share/lua/5.1/trepl/init.lua:389: ...ngo/usr/local/torch/install/share/lua/5.1/trepl/init.lua:389: Python error: import numpy array module
ImportError: numpy.core.multiarray failed to import
Could you please help me @AaronJackson

Have tried installing

pip install -U numpy
pip install numpy

None of the options work

Which version of Python are you using?

python 2.7

Every package is installed perfectly as per your instructions

but this issue is from @BabuTango, i need to know what he/she is using. you have a different issue

I too have the same issue

I also have the same issue particularly in MATLAB,
I have Python 2.7 and numpy installed

@AaronJackson As you referred, Python 2.7

I'm able run the code in Python, but the color texture is not there for the generated images and the output image is really bad.
Thats the reason I want to run in MATLAB, but unfortunately the above error occurs

I have also tried to install npy4th using luarocks install npy4th.
But installing this throws me,
fatal error: zlib.h: No such file or directory
#include<zlib.h>
So I ended up installing "sudo apt-get install libz-dev".
After installing libz-dev also, it says fatal error: zlib.h: No such file or directory


TIM-114 fix: Mobile layout

#57  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tamrivera05 and the rest of your teammates on  Graphite


JNI: align shared files copyright/comments to bitcoinj's

align to https://github.com/bitcoinj/bitcoinj/pull/1233

@TheBlueMatt I believe you wrote the older version of this code; does this
look right to you?

All looks reasonable to me...I'm assuming @greenaddress tested the build instructions in the comments?

@TheBlueMatt yes tested build instructions and run from java both on OracleJDK/OpenJDK/Android. PR is more re: alignment license/copyright as per PR to Bitcoinj.
The bindings are already part of bitcoinj 0.14.1


Reduce iOS scroll damping for lists with differently sized items

Description
On iOS, lists with differently sized items have bigger damping than lists with equally sized items.
During a fling the maxScrollExtent continuously changes (slightly) when the items aren't equally sized. This causes a new simulation to be created. The FastBouncingScrollPhysics used for iOS, decreases the velocity by 9% every time it is created.
This problem wasn't tested in the existing scroll_overlay platform test. All items there have the same size causing the simulation to only be created once.
This PR removes the velocity change when creating the simulation and tweaks the friction of the FrictionSimulation to match the native iOS behavior closely for both scenarios.
The new damping isn't pixel-perfect (if that's even possible) but close. The focus of this PR is that lists with equally and unequally sized cells now behave the same on iOS.

Before (damped)
After

Related Issues
Related #11772
Fixes #32448
Tests
For testing, I updated the scroll_overlay PR#2 test project to use different sized cells.
I tested with iPhone XR, iPhone SE and Pixel 4
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change

[x] Yes, this PR changes the iOS scrolling behavior, to be closer to the iOS platform.
Some tests, which expected a fling to travel an explicit distance, failed. I adjusted them. None of them changed their meaning.

[x] No, this PR doesn't change the public or internal API.

(PR triage) @LongCatIsLooong @passsy What is the status of this PR? Should it be closed in favor of https://github.com/flutter/flutter/pull/60501?

@LongCatIsLooong I reverted the drag from FrictionSimulation back to 0.135. This only resolves the excessive damping when list items have different sizes. It now scrolls - faster - like lists with equally sized items.

Before (damped)
WIP drag=0.07
After drag=0.135

#60501 does not fix the issue here where recreating the simulation reduces the scroll speed. Both PRs improve different parts of the iOS scrolling behaviour.

@goderbauer @passsy I didn't add tests in #60501 to cover the case where the viewport needs to apply a new content dimension. I was hoping that we can wait for both PRs to be reviewed and then merge them together.


an enum + object for doing the casing automatically.

From a user setting options, they should not need to set functions, only enums that will then call those functions.

This has been started, and mostly being utilized by the code base.


Small changes to reduce peak memory.

LLaMA 7B is very close to the limit for sharding across 4x40GB cards, and recently several library changes have put it over the limit and it now OOMs when run. (Notably, it turns out we were cheating and using a bit less memory than the correct implementation.) This PR introduces two small changes which prevent Shakespeare pretraining from OOMing and greatly improve its performance:

foreach=False Some PyTorch optimizers have the ability to group updates, which generally improves performance by reducing the number of kernel launches and consequently the amount of host latency. However this grouping has an increased peak memory footprint. Instead of allocating and freeing a size X Tensor k times, you allocate and free a k * X sized Tensor once.

limit_all_gathers=True Breaking up the optimizer step will bring the logical memory down below the OOM threshold, but if we look at memory statistics we still see reserved memory maxing out. The reason is FSDP is overzealous in launching all gathers in an attempt to overlap as much communication and compute as possible. The trouble is all of those concurrent in-flight requests take up memory; more specifically the CUDACachingAllocator caches per stream, so it's not straightforward for it to reclaim memory from the communication stream and use it in the compute stream. By restricting the number of in-flight gathers we get about a 3x performance improvement. (6-8 seconds / step -> 1.5-3 seconds / step)

This is actually really nice @robieta ! Peak memory is one of the big issues in practice when finetuning LLaMA 65B / Falcon 40B as well.
Once this is merged, we should also apply this to lit-parrot!

Whoa I just ran those and I'm seeing a huge speedup (95% !) by setting limit_all_gathers for adapter too. So we should totally do it.

The finetune scripts in this repo are using DeepSpeed, unlike in lit-gpt where I switched it for FSDP: https://github.com/Lightning-AI/lit-gpt/pull/118. So we can merge this.


README example screenshot broken

Happily opening the first issue :)

haha. Appreciate the report. Still working on putting this repo together. Should be good to go in a few days :)


[WIP] Behavior Tree rework

This is by no means ready, as it will be breaking on many levels related to behavior, and it'll probably get merged in only when done.
The PR is here mainly for review within GSoC, with some code unfinished and some removed (for now) - e.g. Gooey's  Quests behaviors, Work related stuff (used in Light&Shadow), etc.
What works, at the point of writing this: the new behavior tree implementation.
What doesn't: most of the 'meat'. Refer to the kanban board and blog:
Project board:
https://github.com/orgs/Terasology/projects/7
Blog:
https://dkambersky.github.io/tera/
This PR is accompanied by these PRs in related repos:

Behaviors
Pathfinding
WildAnimals

Outstanding before merging
Phase 1:

[ ] Interruption / event handling
[ ] Unified Entity / Actuator interface - or Actions that fit that purpose
[ ] NUI editor fix-up (mainly the realtime display and saves

Then Phase 2 and Phase 3 - outline at the links above

Can one of the admins please verify this patch?

@GooeyHub: add to whitelist
@dkambersky: awesome!
Pinged some people for review, also poking @kaen who hasn't accepted the team invite yet so I can't assign review :-)

Uh oh, something went wrong with the build. Need to check on that

Belated follow-up: the failing check is 10 unit tests that seemingly break - probably need updates or replacements to fit the new approach: http://jenkins.terasology.org/job/TerasologyPRs/1648/testReport/

Uh oh, something went wrong with the build. Need to check on that

Hooray Jenkins reported success with all tests good!

Hooray Jenkins reported success with all tests good!


Bug: Arabic Support

Hey!
I have tested Maze section of the game, in the Arabic mode, and the translation is kinda literal. As this game specified for kids, I'd recommend to provide an accurate Arabic version of the game.

The translations of Blockly and Blockly Games are handled by Translatewiki.  Here are the instructions for contributing translations.  We are always delighted to receive better translations:
https://developers.google.com/blockly/guides/contribute/core/translating


Perhaps it is worth swapping verified and received files when comparing?

It would be much more logical, now there is an inversion compared to a change.

is this what you want ? https://github.com/VerifyTests/DiffEngine/blob/main/docs/diff-tool.md#leftright-diff-behavior

Yes, thank you.


Loses information when parsing large JavaScript numbers

var x =<PHONE_NUMBER>99999000034;
console.log(x); //<PHONE_NUMBER>99999000000
console.log(x % 10000000); // 8951424

Throughout this example code, the value of x is precisely<PHONE_NUMBER>99998951424, since this is the nearest available float to the number which was asked for by the source code. We see at the second line that, when printing x out, JavaScript only supplies the bare minumum number of decimal places required to uniquely specify a float with the same value, however, this is a big mislead. At the third line, we demonstrate that, for arithmetical purposes, which is what we care about, x is<PHONE_NUMBER>99998951424.
I think big-integer should likewise favour the arithmetical meaning of a number, but:
var y = bigInt(x);
console.log(y.toString()); // '999999999999999000000'
console.log(y.mod(10000000).toString()); // '9000000'

It looks as if we favour the lossy JavaScript string representation over the actual number which x represents.
[some stuff removed here]
The resolution would be to inspect x more carefully to determine its IEEE754 radix and mantissa, then use these to construct a big-integer object from it.
Of course, this would be a change from existing behaviour, which possibly is already expected by users...

JavaScript numbers are allowed as inputs to bigInt primarily for convenience when using small numbers. I can't think of any reasonable use case for a user wanting to pass in a number too large to be represented by Number.
In JavaScript the numbers<PHONE_NUMBER>99999000000,<PHONE_NUMBER>99999000034, and<PHONE_NUMBER>99998951424 are indistinguishable. For example<PHONE_NUMBER>99998951424 ===<PHONE_NUMBER>99999000034 returns true. Once they're passed into bigInteger it's impossible to recover the original form, so any one of these (among thousands of other options) is an equally valid interpretation.
In general, this library tries to maintain parity with the behavior of JavaScript to avoid unexpected inconsistencies, so matching the behavior of toString seems to make the most sense to me.

In general I believe that if Number.isInteger(x) is true, bigInt(x).toJSNumber() === x should also be true, since the big integers are a superset of the little ones.

Can you give an example where this does not hold? Using the example you gave, bigInt(999999999999999000034).toJSNumber() ===<PHONE_NUMBER>99999000034 evaluates to true.

Ah, so bringing up that last assertion about things which should be true was a mistake on my part. It doesn't relate to the problem I'm describing, I shouldn't have brought it up. I have removed it from what I originally wrote. Sorry!
Anyway, my use case was that I wanted to know what the exact value of Number.MAX_VALUE was, and maybe do some arithmetic with it, so I did bigInt(Number.MAX_VALUE).toString() and what I got was

'179769313486231570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'

The actual value of Number.MAX_VALUE is 21024 - 2971:

179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368

This discrepancy caused some later calculations to fail.
I discovered this because I am putting together an API which accepts both JavaScript numbers and bigIntegers. When a user supplies me with a JavaScript number, I convert it to a bigInteger, under the assumption that the value that the user has provided is exact. However, big-integer introduces an error at this stage.
When you say "In JavaScript the numbers<PHONE_NUMBER>99999000000,<PHONE_NUMBER>99999000034, and<PHONE_NUMBER>99998951424 are indistinguishable", I would argue that JavaScript simply does not have the numbers<PHONE_NUMBER>99999000000 or<PHONE_NUMBER>99999000034. It only has<PHONE_NUMBER>99998951424. Arithmetic using<PHONE_NUMBER>99998951424 should behave as such, including big-integer arithmetic.

I understand what you're getting at, but I'm hesitant to make this change for a number of reasons.

As I said before, it breaks the parity between bigInt(x).toString() and x.toString().
When you do bigInt(999999999999999000034).toString() and see the result "999999999999999000000", it's straightforward to understand what's going on behind the scenes and realize that the number passed in was truncated because it's too large to be represented accurately with a native JavaScript number.
After seeing bigInt(999999999999999000000).toString() result in "999999999999998951424", most people would think "wtf is going on?!".
I haven't thought very hard yet about how you would implement this, but I suspect that this would be more computationally expensive than the current toString method which typically just redirects to the native JavaScript toString. Performance considerations are relatively important for toString since it is one of the most commonly called methods.

This would be a change at bigInt construction time rather than at stringification time. Does that change the performance considerations?


Add option to suppress or override RUBYOPT environment variable

I encountered a situation where this was useful, and I'm hoping others might find that as well.  Important when you want to run ocran with one RUBYOPT argument list but you'd like the final executable to run with a different set of options (or in my case, no options).

Thanks for the approval @Largo - can you merge as I don't have write access?