Full page screenshot

Hey, thanks for the awesome tool. 🎉
One of the greates features so far in chrome is fullscreen screenshots. Before, we have to scroll and combine different parts of a page for visual regression.
So, I would like to implement somehow option, which will say chromless to take full page screenshot without scrollbar. Any thoughts so far? 🤔
If it's technically posiible, I think passing options to .screenshot() will be ok.
const screenshot = await chromeless
  .goto('https://google.com/')
  .screenshot({fullpage: true, scrollbar: false})

and save current defaults
screenshot({fullpage = false, scrollbar = true}) {
...
}

Could probably solve this once https://github.com/graphcool/chromeless/issues/41 is implemented

#41 done in #137?
Can't quite tell...

@mattcanty That looks to be correct. The following is taking a screenshot of the whole page for me:
let screenshot = await chromeless.screenshot('body');

@joelgriffith This could possibly be closed now?


Update Screenshots to ShenYu in README.md.

Task

[ ] Update Screenshots to ShenYu in README.md.

May it is not nessary to add these Screenshots.


Drop code which was only used by <=2023.1

AppMapIndexableFilesContributor was only sed with 2023.1 and earlier versions, but we've dropped compatibility with 2023.1 and earlier.
AppMapIndexedRootsSetContributor is the implementation in use with 2023.2 and later.

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

v0.65.0
GitHub release

Your semantic-release bot :package::rocket:


[Feature Request] CreateAuthCodeURL - adding state & challenge

Is your feature request related to a problem? Please describe.
When using CreateAuthCodeURL I can't set a challenge or state, so I have to manually add it to the URL.
Describe the solution you'd like
Allow CreateAuthCodeURL to use a challenge, and set a custom state. You would get the code verifier back, to set it when you get a token from the auth code.
Describe alternatives you've considered
Manipulating the URL after it has been generated by CreateAuthCodeURL but the functionality to generate the code verifier and so on is already present in the package so why not do this automatically?
Additional context
N/A.

As I see such library not supported by Microsoft? Why then recommend to use MSAL only then in docs?

It has been a year and a half since this issue was being created. I have the same request for allowing custom session_state and code_challenge.

Session State: In the current implementation, we can only get a random session_state from AAD. Allowing custom state in GenerateAuthCodeURL() provides feature parity to other MSAL libraries such as MSAL.js.

Code Challenge: If I understand correctly, MSAL for Golang does support PKCE when using the AcquireTokenBy...() methods, which completes the second half of the workflow. But there is no documentation/example/support on the first half.

Using CodeLogin as an example, the challenge must be set when generating the auth code URL, then being verified in AcquireTokenByAuthCode(). The first part is missing in this library.

These should be essential for something to be using in production.


Rewrite function to await

tell me how rewrite this function with the expectation?
    var titles = GetTitles();
    ///....
    function GetTitles() {
    var titles;
    connection.query('SELECT * FROM titles', function (err, rows) {
        titles = rows;
    });
     return titles;
}

I would like to wait for the result  C#
var titles = await GetTitles();
///....
function async GetTitles() { ///.... }

Does connection.query also return a promise? If not, you'll have to make a version that does return a promise first. I don't know what DB library you are using so I'll assume it doesn't return promises. knex.js returns Promises so if you can use that I recommend it, as the code will interoperate much more easily with async/await style.
Anyhow, if your connection.query method only takes callbacks, then do something like this first:
// NB: if you are using iojs, Promise is already defined as a global
var Promise = require('bluebird');

function getTitles() {
    return new Promise(function (resolve, reject) {
        connection.query('SELECT * FROM titles', function (err, rows) {
            if (err) return reject(err);
            resolve(rows);
        });
    });
}

Then you can write some other async function that calls getTitles like this:

var doStuffAsync = async (function () {
    ...
    var titles = await (getTitles());
    ...
    var result = someOtherFunc(titles);
    return result;
});

When called, doStuffAsync will return a promise of its result.
On the other hand, if connection.query returned a promise directly, you wouldn't need getTitles at all, you could just do:
var doStuffAsync = async (function () {
    ...
    var titles = await (connection.query('SELECT * FROM titles'));
    ...
    var result = someOtherFunc(titles);
    return result;
});

Thanks! tomorrow, as will certainly try and describe the time.
ps its mysql connection https://www.npmjs.com/package/mysql

FYI, there are some promise-oriented wrappers for the mysql library:

mysql-promise
promise-mysql

I suggest using one of these, since they will work directly with async/await.

I get to set the old python. I liked more your way, but tell me if I can call a doStuffAsync func in addition? Why it again operates asynchronously, and I do not get the desired result (

doStuffAsync() is an ordinary (but asynchronous) function that returns a promise. The promise instance is what you can see in your screenshot above.
You need to await the asynchronous function call to suspend the caller until the promise resolves - ie titles = await (doStuffAsync()).
It's important to understand that to use await you need to be inside the definition of another async function. That is because suspending a function requires some kind of coroutine support, which normal functions do not provide, hence the async wrapper function.
That means that your outermost layer of functionality (perhaps the API you expose to your module's consumers) would still expose promise-returning functions.
So if doStuffAsync() was some public method, consumers would use it like a normal promise-returning function, ie doStuffAsync().then(function (result) { ... }).

Closing this as there seems no further action to be taken. Feel free to open another issue if you have more questions.


python38: 3.8.14 -> 3.8.15; python37: 3.7.14 -> 3.7.15

http://docs.python.org/release/3.8.15/whatsnew/changelog.html
http://docs.python.org/release/3.7.15/whatsnew/changelog.html
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

And python37.tests won't pass since there is an infinite recursion between setuptools_scm and importlib-metadata.


Remove Python 2.7 support

This gets rid of all mentions of legacy Python in gala, as well as all Python 2->3 compatibility fixes.

There is still a py 2.7 mention in the readme :-)


Transfer Twitter login token?

I'm not sure if this is possible using this plugin, but I'm trying to log users in on my website using the access tokens (inside a react native app, obviously).
I got it working for Facebook. So I get a token from Facebook > use the same token in my Facebook PHP SDK and get the user's info.
But I can't get this to work with the twitteroauth PHP library I'm using. I tried a bunch of different ways, but in most cases you need a token and token_secret. Simple-auth only returns one token.
Should this be possible using the token I get?
Basically I'm trying to do $connection->get('account/verify_credentials'); in PHP with the token I get in JS, but it won't allow me..

in most cases you need a token and token_secret. Simple-auth only returns one token.

Yep - this is an issue with react-native-simple-auth, it should return you an additional secret token for Twitter. @ethul has a branch that supports this: https://github.com/adamjmcgrath/react-native-simple-auth/compare/master...ethul:topic/credentials I'll take a look at adding it this weekend.
@ethul - feel free to raise a PR for that branch if you want.

PR #29 has been submitted.

Thank you very much!

Released 0.3.0


Remove dependency on libm

I'm just wondering if we could remove the dependency on libm.
Just a few changes to do this, but I could be wrong.

Thanks a bunch. This looks got to merge, but it'll have to way a bit longer because I want to make sure this won't break something, but I don't have the time for that just now.


Add basic authentication layer to ASReview (#1046)

Work by @terrymyc and @cskaandorp.
Other relevant resources.

Previous development branch https://github.com/asreview/asreview/tree/auth-layer
#639
#648
#606

Check https://github.com/asreview/asreview/pull/1317#discussion_r1108925622 before merging.


Failed to install on Windows

Hello you have an intresting project that would be awesome for me to contribute. Though I am having trouble installing it or installing it correctly as seen here:
26980 verbose stack Error: ENOENT, open 'C:\Program Files\nodejs\?.cmd'
26980 verbose stack     at Error (native)
26981 verbose cwd C:\WINDOWS\system32
26982 error Windows_NT 6.3.9600
26983 error argv "C:\\Program Files\\nodejs\\\\node.exe" "C:\\Program           Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "-g" "wat"
26984 error node v0.12.7
26985 error npm  v3.2.2
26986 error path C:\Program Files\nodejs\?.cmd
26987 error code ENOENT
26988 error errno -4058
26989 error enoent ENOENT, open 'C:\Program Files\nodejs\?.cmd'
26989 error enoent This is most likely not a problem with npm itself
26989 error enoent and is related to npm not being able to find a file.
26990 verbose exit [ -4058, true ]

Any ideas of why I am receiving these errors? Would it be more appropriate to put this issue on npm?

This doesn't look like a wat problem. Try re-installing NPM.

Yeah, I'd have to agree with @Qix- haven't seen that before. Let me know if you still have trouble after reinstalling NPM and maybe node.

No, it's wat. Happens because you cant use a question mark in Windows filenames. So this binary name is the problem:
"bin": {
    "?": "./bin/index.js",
    "wat": "./bin/index.js"
  }

aha! good catch

Oh ok so basically just that the file name in the binary somehow needs to be fixed.

that's just my package.json I thought i'd be fancy and make '?' a binary command. I felt like I was cheating somehow, and I was right!

You could instead advise *nix users who want the "?" name to create an alias.

Aha, yes definitely cheating. That's going to be pretty standard across systems.
Alternatively, suggest making an alias on *nix systems:
alias ?=wut

:kimono:

Okay this is fixed - Windows build show work now. @Toltar  @vweevers if you want to try it out.


Wip 345 add datasets metadata with file

Coverage report

This PR does not seem to contain any modification to coverable code.


JSON.parse will lead to loss of precision for large integers and interop issues

I have noticed several places in Rust code using U128 and U256 for "amount" type fields these are not compatible with MAX_SAFE_INTEGER and on the rust side they'll serialize fine but on the javascript side they will become floats (number) during JSON.parse leading to loss of precision.
We must do something to address the deserialization of large integers that is better than JSON.parse.
Javascript now has a built in bigint class that is perfect for this kind of thing but no real way of integrating that into JSON.parse yet. We may need to write the json tokenizer/parser or re-use some such existing package such as this one.
https://github.com/sidorares/json-bigint
Another alternative is to always serialize integers as strings across the entire ecosystem but that seems unmanageable

Good point! Recently, bigint serialization is added by @petarvujovic98 in #228. test-bigint-serialization.ava.js is a proof of that.


Encrypt workflow code in the indexify server

I see currently indexify encodes the workflow code into the server as discussed with @diptanu , can we enable encrypting instead so companies can secure their workflow code as IP ?

Doesnt' object stores do at rest encryption?

Closing this as you can encrypt workflow code at rest on S3. no support on the OSS project is necessary. We encrypt everything in Tensorlake.


Map not loading in Jupyterlab

geemap version: 0.8.0
Python version: 3.8.6
Operating System: macOS Catalina, version: 10.15.6

Description
I have installed geemap using pip. I have also installed the required Jupyterlab extensions and enabled them.

The map is not displayed in the Jypyterlab output. I ran the following basic script:
import geemap
m = geemap.Map()
m
output: Map(center=[40, -100], controls=(WidgetControl(options=['position'], widget=HBox(children=(ToggleButton(value=…
What I Did
For Jypyterlab extensions, I also used:

 jupyter nbextension install --py --symlink --sys-prefix ipyleaflet
jupyter nbextension enable --py --sys-prefix ipyleaflet

There might be some dependency version conflict. Did you create a fresh conda env to install geemap?
conda create -n gee python=3.8
conda activate gee
conda install mamba -c conda-forge
mamba install geemap -c conda-forge

Thanks. I am not using conda. I have installed the geemap using pip. I will try using conda install.


Cleanup mavlink header parsing

The parsing of mavlink header was intended to be contained in a single function, when we are reading the message from the associated buffer. Due to the addition of logging a long time ago and continuous use of the header fields to properly route the packets to the appropriate endpoint we ended up adding the same parsing to the log endpoints, including the check for different struct on mavlink1 vs mavlink2 wire format.
This is a cleanup aiming to stop doing that and rather just adding the appropriate fields in struct buffer. This also makes it much closer to be able to implement #39 since now we keep the msgid and could check for it against a set of msg ids in the correspondent accept_msg().
This still needs to go through proper test and bench test, but apparently it's working (hey, it passes the testsuite).

humn... CI fails due to old gcc. I'll probably have to change the designated initializers

@bkueng @zehortigoza  ping

I just need to review with more calm 'logendpoint: move checks from write_msg to accept_msg()' other patches looks good to me, with the s/src_sysid/src_compid pointed out.

Yep, logging stopped working, I need to debug that. At least it triggered my fixes on #145. Thanks @bkueng

Are there any updates on this?

I'm dropping this commit: "logendpoint: move checks from write_msg to accept_msg()". The rest is re-implemented on current master branch.

Reducing the number of method arguments is always appreciated. Looks quite nice now.
I'm not quite happy with the name "buffer", but also have no better name for it right now.


Remove functionality to run unified-fides without redis/database

Is your feature request related to a specific problem?
It adds complexity for, in my opinion, very little value that the fides webserver can be run without redis and a database. However I also assume I'm missing some background info here as to why those features were added in the first place.
Describe the solution you'd like
Remove enabled fields for redis and the database. Remove all checks for those components. Fides should have a database and redis as hard requirements to run. For context, currently fidesops is unable to process DSRs without redis.
Describe alternatives you've considered, if any
Leaving as-is, or setting up the masking-engine as its own service within the codebase that can be run individually.
Additional context
From a slack conversation with @adamsachs it sounds like this was added as a POC for a client to use the masking engine as a stand-alone service, but this isn't actually currently being deployed or utilized. I guess an important question here is, how many users would use the masking engine in this way, without any other part of fidesops running?

@NevilleS do you have more context here? Curious if there were any other clients this might be important for?

That's the exact reason, yup. We wanted a way to run fides as a stateless masking engine with the dependencies removed, and exclusively use the utility APIs like /api/v1/masking/mask.

@NevilleS what do you think about starting up the server in a specific masking engine mode?
The startup/running of the unified webserver is inherently complex, and by adding conditional checks everywhere we are increasing that complexity. Fides, as a webserver, can't actually run without redis and a database so to me it feels wrong that they share a code path.
Instead, we could define a separate FastAPI application that has a really streamlined and light startup/feature-set that matches exactly what the masking engine needs, and add a fides masking-engine command to the CLI so that users can spin that up specifically in a very lightweight manner. This feels much much better to me than our current solution

@adamsachs would be curious to hear your opinion on my above suggestion as well ^^

@ThomasLaPiana i like the idea - the masking engine-only usage pattern is so different from the general fides webserver/app functionality that splitting it out into its own application does seem cleaner than trying to stuff it into the same app. i say this with the caveat that i don't know exactly how this would be done, but i can imagine it :)
looping in @pattisdr as well, who has picked up work on the next iteration of the masking engine

@adamsachs Thanks for confirming! I think the solution would be a masking_engine.py module that defines its own FastAPI application (app = FastAPI(title="masking_engine")) and then only adds the routers/middleware that it needs to run
on the CLI side it looks like from fides.api.masking_engine import start_masking_engine and 'start_masking_engine()`

Hey @ThomasLaPiana — what's the best way to test this?


cob_control: 0.7.0-0 in 'kinetic/distribution.yaml' [bloom]

Increasing version of package(s) in repository cob_control to 0.7.0-0:

upstream repository: https://github.com/ipa320/cob_control.git
release repository: https://github.com/ipa320/cob_control-release.git
distro file: kinetic/distribution.yaml
bloom version: 0.5.26
previous version for package: null

cob_base_velocity_smoother

No changes

cob_cartesian_controller

No changes

cob_collision_velocity_filter

No changes

cob_control

No changes

cob_control_mode_adapter

No changes

cob_control_msgs

No changes

cob_footprint_observer

No changes

cob_frame_tracker

No changes

cob_model_identifier
* Merge branch 'indigo_dev' of github.com:ipa320/cob_control into multi_distro_travis_kinetic
  Conflicts:
  .travis.yml
  README.md
* Added Eigen3 Indigo/Kinetic compatibility
* Contributors: Denis Štogl, ipa-fxm

cob_obstacle_distance
* Merge branch 'indigo_release_candidate' into kinetic_release_candidate
* Merge branch 'indigo_dev' of github.com:ipa320/cob_control into multi_distro_travis_kinetic
  Conflicts:
  .travis.yml
  README.md
* [kinetic] migration (#115 <https://github.com/ipa320/cob_control/issues/115>)
  * [kinetic] find package Eigen3 instead of Eigen
  * [kinetic] switched from fcl to libfcl-dev dependency
  * ignore cob_obstacle_distance for now
  * [kinetic] use industrial_ci for travis
  * [kinetic] use industrial_cis ipa320 fork & notify on_success only on change
  * fixed fcl dependency
  * new fcl version switched from boost::shared to std::shared
  * whitelist package
  * use ros-industrials fork
  * cleaned up travis.yml
* Added Eigen3 Indigo/Kinetic compatibility
* Contributors: Benjamin Maidel, Denis Štogl, Richard Bormann, ipa-fxm

cob_omni_drive_controller

No changes

cob_trajectory_controller

No changes

cob_twist_controller
* Merge branch 'indigo_dev' of https://github.com/ipa320/cob_control into kinetic_dev
* [kinetic] migration (#115 <https://github.com/ipa320/cob_control/issues/115>)
  * [kinetic] find package Eigen3 instead of Eigen
  * [kinetic] switched from fcl to libfcl-dev dependency
  * ignore cob_obstacle_distance for now
  * [kinetic] use industrial_ci for travis
  * [kinetic] use industrial_cis ipa320 fork & notify on_success only on change
  * fixed fcl dependency
  * new fcl version switched from boost::shared to std::shared
  * whitelist package
  * use ros-industrials fork
  * cleaned up travis.yml
* Contributors: Benjamin Maidel, ipa-fxm

cob_undercarriage_ctrl_node

No changes

This branch has conflicts that must be resolved.

Thanks for the notification. We resolved the merge conflict.


Update SandboxTest.ps1

Added "--accept-package-agreements".
It will fail if tested manifest depend on a package with an EULA.
Checklist for Pull Requests

[x] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@Trenly it's a trivial change, but I wanted you to take a quick peek.

It looks fine to me; The only real question I have is if theres any value in being able to test that the agreements flow works as expected and shows the information as expected. Having this parameter absent doesn’t cause the script or install to fail, it just means that whomever is testing has to interact with the sandbox and agree to the package agreements

It looks fine to me; The only real question I have is if theres any value in being able to test that the agreements flow works as expected and shows the information as expected. Having this parameter absent doesn’t cause the script or install to fail, it just means that whomever is testing has to interact with the sandbox and agree to the package agreements

Not exactly, you can't accept eulas on dependencies, it will just fail in those cases.

It looks fine to me; The only real question I have is if theres any value in being able to test that the agreements flow works as expected and shows the information as expected. Having this parameter absent doesn’t cause the script or install to fail, it just means that whomever is testing has to interact with the sandbox and agree to the package agreements

Not exactly, you can't accept eulas on dependencies, it will just fail in those cases.

A switch would also work, but that's a bigger change.

It looks fine to me; The only real question I have is if theres any value in being able to test that the agreements flow works as expected and shows the information as expected. Having this parameter absent doesn’t cause the script or install to fail, it just means that whomever is testing has to interact with the sandbox and agree to the package agreements

Not exactly, you can't accept eulas on dependencies, it will just fail in those cases.

This will be resolved in WinGet-1.9

It looks fine to me; The only real question I have is if theres any value in being able to test that the agreements flow works as expected and shows the information as expected. Having this parameter absent doesn’t cause the script or install to fail, it just means that whomever is testing has to interact with the sandbox and agree to the package agreements

Not exactly, you can't accept eulas on dependencies, it will just fail in those cases.

This will be resolved in WinGet-1.9

When will it be released?

We're planning to release WinGet 1.9 on the 29th of October.

@denelon - This can be merged

[Policy] Needs-Manual-Merge


_torchtext.so: undefined symbol

Any one met this problem?
My environment python 3.7, torch1.6, torchtext 0.7.0 .
I think it is sort of version incompatibility. But I dont think this bug happening due to above libs.
Could you share your docker mirror if possible? I appreciate your endeavor.

It seems that this bug happens when python==3.7. I fix this by create a py36 based enviroment.


Fixed undefined macro error in ARM compiler build

@cmonr - sorry for last delivery issue, I fixed the undefined macro build problems

@cmonr - I've re verified the build and ran the example successfully - Is there an additional step I need to do before Merging? thanks.


Support for other budo command line args?

Our Elm app happens also to be a PWA with a service worker.
I notice that Budo supports SSL and HTTPS and I wondered how easy it would be to pass through, e.g. the --ssl flag, --cert and --key options to the underlying server

We no longer use budo so I am closing this PR. If you are very interested in these feature I would love to hear about it on: https://github.com/wking-io/elm-serve and we can bubble it up to here


Fix GH#177

Closes #177

subscription from QL are -10 priority, given that you can (and should)
actually use orion for that.


migrate the code change about network CRD to master

It was found that turning off the multi-tenancy network CRD feature ( as it has not completed) helps improve the scalability. This PR turns off this feature in master branch.
This feature was turned on/off per the setting of feature gate value of "MandatoryArktosNetwork".
Verification:
It is verified that by default setting, the kubelet does not send out request like "tenant/aaa/networks/default" to apiserver.

/assign @XiaoningDing

/assign @XiaoningDing

/assign @h-w-chen

/assign @h-w-chen

@assign @pdgetrf

@assign @pdgetrf

/assign @yb01

/assign @yb01

/assign @vinaykul

/assign @vinaykul

/lgtm

/lgtm

/approve

/approve


Does not work for Bell Email website.

Website for Bell Email; https://webmail.bell.net/
Worked for a time but does not any longer. Using latest version of Firefox (89.0.1). Cleared cache & cookies; no change. Turned off/on add-on; no change. Works outside of the Bell Email website.
Using Windows 10 with the latest updates installed (21H1).

@Patricialongo I don't have access to it. Perhaps if you can find out what the HTML field (p,span,textbox etc) is, I may be able to replicate it.

Please do not remove had very busy month and need time to dedicate to it and call for help will be getting to it soon. Please do not remove
Sent from my iPhone

On Aug 3, 2021, at 10:10 PM, github-actions[bot] @.***> wrote:
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.


[ja] Added kubernetes-cluster-architecture.svg in content/ja/docs/concepts…

Description:
Updated /docs/ja/concepts/architecture/_index.md and added kubernetes-cluster-architecture.svg in /static/images/docs.
Page to Update:
https://kubernetes.io/docs/ja/concepts/architecture/

Hi @sftim, @t-inu, Please review this PR.

We shouldn't make this change, because we're adding a new English diagram and changing Japanese content.
SIG Docs strongly prefers PRs that can be reviewed by reviewers who speak a single language.

/hold
Feel free to unhold when PR #42272 is merged.

/unhold

The SVG file has been added in #42272, so it no longer needs to be included in this PR.

Hi @utkarsh-singh1, please take a look at my comments about SVG file and caption.

We will continue this work at #44917. Thank you.
/close

Sorry @t-inu, was busy with other issues.


Documentation formatting and update

Update the documentation for 0.0.6 release.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

:exclamation: No coverage uploaded for pull request base (dev@1052b2e). Click here to learn what that means.

Additional details and impacted files
@@          Coverage Diff           @@
##             dev      #99   +/-   ##
======================================
  Coverage       ?   75.85%
======================================
  Files          ?       22
  Lines          ?     1404
  Branches       ?        0
======================================
  Hits           ?     1065
  Misses         ?      339
  Partials       ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Upgrade CustomCodable to handle optional values using encodeIfPresent

The LSP spec requires us to omit keys for nil values rather than using
the JSON null constant in most places. This change to CustomCodable
allows us to do it automatically using CustomCodable, removing one of
the limitations of the property wrapper.
The idea for the adding overloads of encode and decode came from
https://forums.swift.org/t/pre-pitch-codable-customization-using-propertywrappers/30244/

@swift-ci please test


macports support in autojump plugin

I contributed this before but it was lost with the latest changesets to the autojump plugin.

oops, sorry, only wanted that one changeset to go in the pull request... will try again


Fix on helpful and suggestEdits spacing on mobile

This PR fixes some visual regressions on the helpful and suggestEdits components on mobile, caused by the refactoring that's currently happening.
Before:

After:

@imjuangarcia Can this PR be merged, or are we waiting for further refactoring of helpful and suggestEdits components?

@imjuangarcia Can this PR be merged, or are we waiting for further refactoring of helpful and suggestEdits components?

Can be merged now!


Deployment rotation does not match with desired rotation

Hello,
I am currently testing the use of testing of static cameras to record some traffic scenes in CARLA 0.99, both in Linux and Windows.
In concrete, I have a wide range of combinations of positions and rotations.
However, when I set the camera with a pitch of -90 degrees (bird's eye point of view), I am facing the problem that the yaw is combined with the roll once the camera is deployed so I do not get the desired values for both components.
An reproducible example is the following:
# connect to the server and world before this
spectator: carla.Actor = world.get_actors().filter('spectator')[0]
spectator.set_transform(
    carla.Transform(
        carla.Location(0., 0., 50.),
        carla.Rotation(-90., 90., 0.)
    ))
# running loop
try:
    while True:
        print(f'The location of the spectator is {spectator.get_transform()}.')
        world.wait_for_tick()
except KeyboardInterrupt:
    logger.info('Exit')

In my case the result of the print statement is:
The location of the spectator is Transform(Location(x=0.000000, y=0.000000, z=50.000000), Rotation(pitch=-88.992432, yaw=89.993004, roll=-179.999710))
So, when I retrieve the yaw, it is 90 degrees and, the roll, -180.
However, I was expecting -90 degrees for the yaw and 0 degrees for the roll.
This case is handling the spectator camera, nonetheless, the same is achieved using cameras and the deploy command.
I know that the result in the image is the same and it is correct, as I have tested it.
Yet, I also perform operations with respect the yaw of the camera and the objects, being those incorrect.

@Axel1092 could you provide some guidance?

Hi @adrigrillo this behavior is due to the way the Unreal Engine handles rotations. The spectator is a special camera as it is restricted to a range of yaw and pitch values and may have unwanted effects to the final rotation.
I suggest not using the spectator and instead spawn a Camera to do the recording as it will not be subject to such limitations.

Hi @Axel1092, the same problem is produced when spanning cameras. The solution I adopted was to use -89 degrees for the pitch. If it is an Unreal Engine I guess you could do little to change this, so the issue can be closed.

Is there any way to go around this limitation @Axel1092 ?

After some experimentation it seems that around 90 degrees Unreal will change the values to keep them within certain ranges. I guess the only thing you can do is to try to keep track of the rotations yourself.


cargo metadata: provide an option not to collect data about dev-dependencies

Problem
In certain environments that tightly control dependencies (e.g. for the purposes of supply-chain security) the dev-dependencies are not present when code is compiled. But cargo metadata always tries to collect data for the entire dependency tree, including dev-dependencies. It errors out and reports no info if dev-dependencies are missing.
In practical terms this blocks the deployment of cargo auditable (which relies on cargo metadata) within Debian (which does not package dev-dependencies).
This is similar to #10718, but this isn't just a problem with feature unification - the dev-dependency packages are not present at all.
Proposed Solution
Adding a new flag, --no-dev-deps (following the precedent of the existing --no-deps flag) so that cargo metadata wouldn't attempt to query dev-dependencies would resolve this.
Cargo generating a SBOM natively would also solve this by letting cargo auditable bypass cargo metadata completely. But that's going to take a long time to reach stable. That feature isn't even on nightly yet, since the reviews of the RFC and the implementation PR seem to have stalled.
Making it possible to query cargo metadata without requiring dev-dependencies to be present seems like a simpler and more straightforward change that shouldn't require as much design and stabilization work.
Notes
cargo auditable got a lot of uptake from Linux distributions. 5 distros, including Alpine and NixOS, are already building all their Rust packages with it. There is also interest from Debian, but this issue makes adopting cargo auditable a non-starter in their environment.

Correct me if I'm wrong.
This proposal, underneath the hood, is more like asking Cargo to resolve dependencies as if no dev-dependencies are present in Cargo.toml.

In certain environments that tightly control dependencies (e.g. for the purposes of supply-chain security) the dev-dependencies are not present when code is compiled. But cargo metadata always tries to collect data for the entire dependency tree, including dev-dependencies. It errors out and reports no info if dev-dependencies are missing.

In those situations, it isn't only cargo metadata that would fail but every cargo command.  That seems like a highly specialized use case and I would be worried about exposing those kind of knobs.
Also, the dependency resolver can skip dev dependencies today but I'm unsure if that is hard requirement for the use cases that use it or if we could move that to a later stage which would have a lot of other benefits for Cargo.  However, that would be a no-Cargo.lock mode which would be non-obvious and we've tried to avoid doing that in other situations because it has problems (#10096).
I have been toying with how we could construct an alternative set of plumbing commands that could give more control or be swapped out with custom logic in different situations.  We'd need a lot of experimentation in third party code before we could have a good feel for for whether these would meet people's needs and not overly restrict Cargo.

This proposal, underneath the hood, is more like asking Cargo to resolve dependencies as if no dev-dependencies are present in Cargo.toml.

Ideally, yes. That would also take care of #10718.
But really, anything that doesn't require the contents of the .crate files for dev-dependencies to be present would do. cargo metadata  --ignore-missing so that it wouldn't error out when it cannot find something would also work.
I'm not familiar with Cargo internals, so I cannot really tell what the best "under the hood" mechanism would be.

In those situations, it isn't only cargo metadata that would fail but every cargo command.

Well, cargo build works, and I'm trying to get cargo auditable build to work whenever cargo build works.

I have been toying with how we could construct an alternative set of plumbing commands that could give more control or be swapped out with custom logic in different situations.

A machine-readable output for cargo tree would be a nearly perfect match for cargo auditable. The way cargo metadata works has some fundamental limitations such as #7754 and #10718. Although I don't know if cargo tree's dependency type filtering would work when dependencies are vendored and .crate files for dev-dependencies aren't present.
For cargo auditable and similar tools like cargo cyclonedx #13709 would be the best solution, if only on nightly in the foreseeable future. All the review comments on the PR have been addressed by the author, but then the review has stalled?

Well, cargo build works, and I'm trying to get cargo auditable build to work whenever cargo build works.

Oh, right.  If you are using the registry and not vendored dependencies, the Index will be used for dependency resolution so .crate files aren't needed.  When we do feature resolution, we only do it for the selected targets and don't need the .crate files.
The problem comes in when we get the extended information for including in the metadata output that we need the .crate files.
However, this is Debian.  I would assume a registry is not being used.  Are the .crate files being referenced in a way that still has an index to make this work?

@alexanderkjall since you worked on the integration into Debian, could you explain to Cargo developers how the Debian build process for Rust packages works and how it avoids using the dev-dependencies?

I tried to write something, I'm not really sure if I hit the correct abstraction level here at all, so please ask more questions if needed:
How does building binaries from rust source work in Debian:
Debian does not allow the build servers to fetch source code from the internet while building, instead all source code that generates a binary must be already packaged and part of Debian before the build of the binary can happen.
There is also a concept of source packages and binary packages in Debian, with rust this gets a tad complicated. For rust-libraries the debian-binary package contains the source code of the library (for C it would contain the .so file), but for rust-binaries the debian-binary package contains the binary.
Here is an example of the content of a Debian-binary package built from rust:
https://packages.debian.org/sid/amd64/lsd/filelist
And here is the Debian-source package for that:
https://packages.debian.org/source/sid/rust-lsd
For libraries this looks like this:
https://packages.debian.org/sid/amd64/librust-futures-channel-dev/filelist
https://packages.debian.org/source/sid/rust-futures-channel
This means that Debian mirrors the dependency resolution system in cargo in it's own package system. The build then first does the dependency resolution on the Debian side, and installs librust--dev packages, these packages only contain rust source code that gets placed into /usr/share/cargo/registry/ .
Of note is also that the dependency resolution on Debians side is recursive, we read the content of Cargo.toml and only insert those entries into the dependency list, and then the apt dependency resolution will walk the tree and pull in what is needed.
Debian do not respect/care about the Cargo.lock file.
Testing of the source code is also slightly involved, tests in Debian are run in a separate section from the normal build, called autopkgtest, and we run those per feature plus all-features and no-features.
The dev-dependencies gets added as to the Depends: row for the autopkgtest section, but not the build section. One important aspect of why this is loops in the dependency tree, it's quite common that a -derive package dev-depends on the main package in rust and if those dev-dependencies got added to the build Depends in Debian we would end up with a loop in the build system that it can't handle.

adding some more bits:
there's actually two different ways we test crate sources in Debian packaging:

as part of the build using cargo test, if there are no dev-dependencies
as part of autopkgtests, also using cargo test, if there are dev-dependencies

in both cases, the dev-dependencies are not used as part of the regular build, but just for the (decoupled, running after packages are built) autopkgtests.
for regular package building, we use a cargo wrapper that (among other things) injects -Z avoid-dev-deps for "build", "rustc", "doc", "test", "bench", "install" invocations, which means that the lack of dev-dependencies at package building time is not an issue. it can be an issue for other commands, especially those related to generating the source packages that get later build. for example, debcargo, our tool that translates Cargo.toml into debian packaging metadata, has support for packaging from a local crate source tree (in addition to the default mode, which uses a downloaded .crate archive from crates.io). in order to support such local crate sources, debcargo basically does the equivalent of cargo package, which in turn requires all dependencies to exist in the registry. if "the registry" is the local dir of packaged crates, then this requires all dependencies (including dev dependencies) to be installed, even though they are not used in any fashion at that point. similarly, other tools using/extending cargo might be unhappy if there is a cargo config pointing at the packaged crate "registry", as opposed to crates.io, since the former only offers an "incomplete" view.
so in summary, it would be great if cargo could be taught to ignore referenced crates not existing for various actions - it would make our packaging life easier. it's not required to build and test packages though, as that part is already handled by the existing options in cargo.
(similarly, it would be great to be able to tell cargo to ignore the non-existence of dependencies for targets that are not currently being looked at/built for/.., as we have to patch such things out, and it causes a lot of meaningless patch churn when pulling in updates - but that is probably a separate issue ;))

So it sounds like Debian is working around this via #5133 and what they really are wanting is some staiblized form of that that would then be used by all of the third-party commands.  In that case, would the appropriate thing to do is to shift the conversation over to #5133 or is there something distinct about this request?

From the cargo auditable standpoint, the short-term solution would be supporting -Z avoid-dev-deps in cargo metadata (this doesn't even have to be stabilized to allow use in Debian) and the long-term solution is #13709.

From the cargo auditable standpoint, the short-term solution would be supporting -Z avoid-dev-deps in cargo metadata (this doesn't even have to be stabilized to allow use in Debian) a

What is missing from it?

Both cargo +nightly metadata -Z avoid-dev-deps and cargo +nightly -Z avoid-dev-deps metadata still include dev-dependencies in the output as of cargo 1.84.0-nightly (031049782 2024-11-01). At least when run with unrestricted access to the internet.
I've tried it both with and without the Cargo.lock file present.

So this should be treated more as a bug report against cargo metadata?
The name just says to "avoid" not to exclude.  This matches some of the long form descriptions like for the feature

When running commands such as cargo install or cargo build, Cargo currently requires dev-dependencies to be downloaded, even if they are not used. The -Z avoid-dev-deps flag allows Cargo to avoid downloading dev-dependencies if they are not needed. The Cargo.lock file will not be generated if dev-dependencies are skipped.

However, the summary is different

Prevents the resolver from including dev-dependencies during resolution.

(and then there is the -Zhelp description that uses a npm-style use of the word "install")
This came up because the flag -Zavoid-dev-deps maps to
    /// `true` if this workspace should enforce optional dependencies even when
    /// not needed; false if this workspace should only enforce dependencies
    /// needed by the current configuration (such as in cargo install). In some
    /// cases `false` also results in the non-enforcement of dev-dependencies.
    require_optional_deps: bool,

Without -Zavoid-dev-deps, we load the lockfile unconditionally with HasDevUnits::Yes.  With it, we rely on the callers value for HasDevUnits which is always Yes for metadata.
With this meaning, I can see either keeping the hard coded HasDevUnits::Yes (because the metadata was requested and so no nothing to avoid much like cargo check -Zavoid-dev-deps --all-targets) or making it conditional on -Zavoid-dev-deps (the user wants to avoid them, be sloppier).
As this is an unstable feature without a clear path to stabilization and not much feedback on people want, I lean towards the latter.  If we do that, we need to call it out in the tracking issue so we keep it in mind if we ever get around to stabilization.

We talked about this in the last Cargo team meeting.  We are fine with this moving forward.  As there isn't a clear path to stabilizing -Zavoid-dev-deps, there isn't anything to align to and we can experiment with changing the behavior here.


Move to Ubuntu 24.04

This moves from clang-format-12 to clang-format-18 which comes with Ubuntu 24.04.
Also, let's try to add Ubuntu 24.04 to CI as well while I'm at it.


Fix: Mkdir before symlink in copyFiles in dev mode

symlink was failing when the file to be copied resided in a directory. as directory was not being created properly beforehand

This issue is a major blocker. It prevents us from using data and config files during dev.

Let me ping again.


Font width and height are optional

For example:
^AC
is valid. But currently it would set size to 0.
I am not sure if it would be better to use -1 as placeholder for "no change". This would need a change to the command parser.
Maybe it would be nicer to split the font and sizes.

@M-Mommsen I would like to improve this special case with the new protocol then and not include it at the moment.

@tinohager merge this now?

Reverted due to https://github.com/BinaryKits/BinaryKits.Zpl/issues/98


what is this

hi kinda new to this what is this is it just the building or can we interact with them I don't see anywhere I can interact with them

Hi, this plugin just adds teleports to the buildings mentioned in the README.
Since the buildings are added by other plugins, they need to be configured in the corresponding plugin (see #6 for details).
To interact with things in the added buildings other plugins are needed.
For example to interact with alcohol bottles in the bikers clubhouse you could use something like esx_liquor, find out the coordinates of the bottles and add them to the corresponding config section.

ok I got you so need to build a script or something to make these feel more real got it thanks

Exactly.
If you decide to write such a script please consider publishing it so others can benefit from it.
If you instead find such a script, feel free to reply to this issue so I can list it in the README.


Elastic Cloud Operator is unable to start

I followed the instructions to install the Operator Lifecycle Manager and the Elastic Search Operator. The Lifecycle Manager ist running and I see a operator-pod in the operators-namespace but the startup fails.
It seems that some CRDs are missing. In this file, that is mentioned on the Elastic-Homepage: https://download.elastic.co/downloads/eck/0.8.0/all-in-one.yaml there are these CRDs defined:
name: apmservers.apm.k8s.elastic.co
name: clusterlicenses.elasticsearch.k8s.elastic.co
name: elasticsearches.elasticsearch.k8s.elastic.co
name: enterpriselicenses.elasticsearch.k8s.elastic.co
name: remoteclusters.elasticsearch.k8s.elastic.co
name: trustrelationships.elasticsearch.k8s.elastic.co
name: users.elasticsearch.k8s.elastic.co
name: kibanas.kibana.k8s.elastic.co
but if the operator is installed via the Operator Lifecycle Manager, I can only find these CRDs:
[RBGOOE\lrzgmar_p@ocpjump5101 local_git_repo]$ oc get crd --all-namespaces | grep elastic
elasticsearches.elasticsearch.k8s.elastic.co   2019-06-07T12:47:30Z
kibanas.kibana.k8s.elastic.co                  2019-06-07T12:47:30Z
The test was executed on OpenShift 3.11. Please find attached the errors that were available in the operator-pod.
logs-operator.2019-06-07.txt
BR,
Matthias

@Marki4711 I don't think this Operator has been tested on OpenShift to be honest - that's probably the reason why it is not also in the community-operators folder in this repo.
That said, I tested installing it with OLM install from OperatorHub.io (which is not supported by the way) and tried to use it. The Operator comes up correctly for me and all it's CRDs are registered:
$ k get crds
NAME                                                                     CREATED AT
apmservers.apm.k8s.elastic.co                                            2019-07-19T15:51:18Z
catalogsources.operators.coreos.com                                      2019-07-19T15:49:15Z
clusterlicenses.elasticsearch.k8s.elastic.co                             2019-07-19T15:51:18Z
clusterserviceversions.operators.coreos.com                              2019-07-19T15:49:15Z
elasticsearches.elasticsearch.k8s.elastic.co                             2019-07-19T15:51:18Z
enterpriselicenses.elasticsearch.k8s.elastic.co                          2019-07-19T15:51:18Z
installplans.operators.coreos.com                                        2019-07-19T15:49:15Z
kibanas.kibana.k8s.elastic.co                                            2019-07-19T15:51:18Z
openshiftwebconsoleconfigs.webconsole.operator.openshift.io              2019-07-19T15:09:31Z
operatorgroups.operators.coreos.com                                      2019-07-19T15:49:15Z
remoteclusters.elasticsearch.k8s.elastic.co                              2019-07-19T15:51:18Z
servicecertsigneroperatorconfigs.servicecertsigner.config.openshift.io   2019-07-19T15:07:56Z
subscriptions.operators.coreos.com                                       2019-07-19T15:49:15Z
trustrelationships.elasticsearch.k8s.elastic.co                          2019-07-19T15:51:18Z
users.elasticsearch.k8s.elastic.co                                       2019-07-19T15:51:18Z


Synchronous rendering on Metal when annotation views are visible

Implement conditional synchronous rendering on Metal backend when annotation views are visible, that is waiting for frames to fully complete by invoking [commandBuffer waitUntilCompleted]; in the swap method of the MLNMapViewMetalRenderableResource.
This is needed because the map transformation is set as soon as the camera is mutated, and annotations are positioned on the screen according to that in MLNMapView::renderSync -> updateAnnotationViews, while the frame rendering is completing asynchronously on Metal - which causes desynchronization.
ref: #2082
Fixes #2053

Thank you so much, it looks much better now! ❤


pipeline_mapping & pipeline_rnaseqtranscripts - Fasta references

In several places the pipelines refer to the bowtie_index_file location for fasta and index files - this is fine if bowtie genome was used to generate files, however often these have been prefiltered to only contain standard chromosome (excluding ChrUn and _random, chrM) - if you have used a different genome to map to (e.g. that includes these other contigs) tasks such as PicardStats will fail. The ini files contain sections that imply you can filter the genome references to contain what you like, however these options don't work if the fast has already been filtered at an earlier step.

Once upon a time, the index directory would contain the fa file used to generate the index. But i've noticed that something is deleting them from at least the star directory (its not the Makefile as far as I can tell).

Which particular file?

hg19.fa in the star indexes. Its really odd. I ran the Makefile, hg.fa was created from the faidx directory, and the index made. The next time I looked in the directory the hg19.fa was gone. As are all the other fasta files.

The index directory is fairly new. I did rearrange the .fa files to remove duplication, please see the CGAT-README file.
I have recreated them (using make h19.fa), let us see if they stay.

Sorry, I just twigged something. When I said the 'indexes' directory, I didn't mean /ifs/mirror/genomes/indexes, whose existance I wasn't aware of, but rather /ifs/mirror/genomes/star. I now see that there is now a hg19.fa in there which is linked to /indexes. My confusion came about because I was building star indexes in the /star/star_2.4.2_indexes directory. The Makefile in that directory doesn't link the indexes directory, but rather regenerates the .fa file.
So,

Should these Makefiles be altered to link the indexes directory
Should I be building new indexes in the /star/star_2.4.2_indexes directory
Why do the .fa files generated in the /star/star_2.4.2 directory disappear?

Yes, please link to the .fa files in the indexes directory. It is important to work from one .fa file across mappers and fasta files in order to have the exact number of chromosomes. Otherwise, tools like Picard complain.

To keep with bwa convention, use the directory /ifs/mirror/genomes/star-2.4.2, rename the old one to start-X.Y.Z and create a link of "star" to the most recent directory. This way, everybody will automatically pick up the most recent indices (appropriate for the latest version of star). If somebody needs to go back, they can specify the old version directly.

Possibility: Make deletes intermediate files once the target has been successfully build. To keep intermediate files, they need to explicitely be part of the target list or dependencies of the .PRECIOUS target.

Hmm... Looks like STAR recommends keeping ChrUN and _random, while bowtie recommends removing them. What do people think about this?

Personally, I'm in favour of keeping the ChrUN and _random contigs in the index. Leaving them out risks "forcing" reads originating from these contigs to align to the proerly assembled contigs erroneously. I take it that's the rationale behind STAR's recommendation too?

From: Ian Sudbery<EMAIL_ADDRESS>Sent: 12 August 2015 10:52
To: CGATOxford/CGATPipelines
Subject: Re: [CGATPipelines] pipeline_mapping & pipeline_rnaseqtranscripts - Fasta references (#59)
Hmm... Looks like STAR recommends keeping ChrUN and _random, while bowtie recommends removing them. What do people think about this?
—
Reply to this email directly or view it on GitHubhttps://github.com/CGATOxford/CGATPipelines/issues/59#issuecomment-130242591.

I found the following comment here
I also tend to remove the "*_random.fa" chromosomes.  These often contain part of the canonical chromosomes in addition to regions that cannot be placed in the assembly.  The problem with these regions is that the part shared with the canonical chromosome will be present twice, making it difficult to map the reads to a unique location.

It might also be application specific. For shorter reads such as ChIP-seq it might be better to keep them out, but for long-reads like in RNA-seq better to keep them in.

Umm... I hadn't considered that. The canonical sequence is contained in the "_random.fa" chromosome by accident of misassembly I take it?

From: Andreas Heger<EMAIL_ADDRESS>Sent: 12 August 2015 14:00
To: CGATOxford/CGATPipelines
Cc: Thomas Smith
Subject: Re: [CGATPipelines] pipeline_mapping & pipeline_rnaseqtranscripts - Fasta references (#59)
I found the following comment herehttp://homer.salk.edu/homer/basicTutorial/mapping.html
I also tend to remove the "*_random.fa" chromosomes.  These often contain part of the canonical chromosomes in addition to regions that cannot be placed in the assembly.  The problem with these regions is that the part shared with the canonical chromosome will be present twice, making it difficult to map the reads to a unique location.
It might also be application specific. For shorter reads such as ChIP-seq it might be better to keep them out, but for long-reads like in RNA-seq better to keep them in.
—
Reply to this email directly or view it on GitHubhttps://github.com/CGATOxford/CGATPipelines/issues/59#issuecomment-130293387.

I am not sure, and I am not sure if this is true and to what extent, how large the regions are, etc. I did not find any more references to this. Might be worth looking at dotter to get a feel for this.


fix: restore ability to create status change documents

Fixes #5962

As a purely stylistic matter, I tend to prefer "truthy" tests

I've been getting pressure to make more explicit checks when the real point of consideration is whether the thing is None or not. In this particular case, I don't think it makes a difference, but if someone configured an AD with a str that returned "", there are other kinds of conditionals or use of {{ ad }} that would likely do the wrong thing.

I've been getting pressure to make more explicit checks, particularly in templates, when the real point of consideration is whether the thing is None or not.

As a source of this pressure, I prefer it because it distinguishes the absence of value from the possible presence of a value that happens to evaluate as False. It's largely stylistic, but anecdotally I've run into more bugs caused by a surprising False value than by inappropriately testing for is None.
It's a little tricky in templates sometimes - Django represents the absence of a value in some of its fields (like CharField) as an empty string rather than None, so it's impractical to be too dogmatic.

In #5962, you said

The tests have not exposed this, so they need to be inspected across the entire status-change workflow.

Are you satisfied with having looked over that for this PR or should we plan that inspection separately?

Are you satisfied with having looked over (the tests) or should we plan that inspection separately?

I'm not really satisfied, but I did make a quick pass through looking for case-sensitivity troubles. I think this particular fail was a late surprise because of the way we test forms (poking hand-written POST values in that may not actually reflect what a browser would have provided exercising the defined form).  So I think it's enough of an edge that we move on, and watch for a framework that works that would allow more of an integrated test of the use of the form.


I should be able to enable automated backups of channel state data to Dropbox

Detailed Description
I should be able to enable automated backups of channel state data to Dropbox so that I can more easily recover channel state data in the event of needing to restore.
Context
Static Channel Backups (new lnd feature)
Possible Implementation
Build out Dropbox integration and provide an easy way for users to enable automated, realtime backups of channel state data to a designated Dropbox account.

Backing up to your local file system would be a better choice. You can just dump the backup into the Dropbox folder, this way you could also dump into other cloud syncing apps like google drive etc. Since 0.6.0 now support backup/restore it shouldn't be to trivial. Encryption would be nice.

Closed via https://github.com/LN-Zap/zap-desktop/pull/2233


Implement test: create a promotion

As a developer
I need test for promotion creation to function properly in test-driven development
So that then I can work on implementing promotion creation API
Details & Assumptions:

...

Acceptance Criteria:
When I run `nosetests`
Then I should expect the tests to run, including this promotion creation test

Do not need testing stories


Update useParticipants to listen for any Participant's info changes

Issue
This is my first contribution! I’d love any advice on how to contribute to the repo. While working with the useParticipants hook, I expected it to keep the participants list updated with their names. However, I found that useParticipants only listens to metadata changes by default and does not react to updates in names or attributes.
To ensure the participants list updates correctly, I called the hook as follows:
const participants = useParticipants({
  updateOnlyOn: [
    RoomEvent.ParticipantNameChanged,
    ...allParticipantRoomEvents,
  ],
});

Additionally, I noticed that the term updateOnlyOn could be misleading, as it always includes three events. While the documentation clarifies this, it may cause confusion when reading the code.
Solution
I found the previous implementation a bit convoluted. I propose that useParticipants should update on all room events that trigger state changes for a participant, as originally intended by @Ocupe. Additionally, please note that a few events related to end-to-end encryption and permissions are still missing from the current setup.

what do you think @lukasIO?

@lebaudantoine feel free to open a subsequent PRs for the other missing events, we'd definitely want them to be part of allRemoteParticipantEvents as well!


add cURL-style -u for username/password entry to the get command

It can be hard to specify modern passwords generated by password managers into the url format given the restrictions on characters. It is much easier to do so only concerning bash escaping rather than worrying about url escaping too. To this end, this PR implements a -u flag (much like) what cURL provides.


Missing id column in default favorites table migration

Missing column id in default favorites table migration
when i try to add some model to favorites it generates following query, which requires id column
SQL: insert into "favorites" ("user_id", "favoriteable_id", "favoriteable_type", "updated_at", "created_at") values (1, 2, App\Models\Institution\Institution, 2021-04-19 06:19:59, 2021-04-19 06:19:59) returning "id"
i dont really realize why and where this is happening, i guess it has something to do with relationtship registration
Possible implementation
add id column to default migration, or figure out why eloquent adds requiring "id" to its query and get rid of it
My environment

php 7.4
laravel 8.36.2

im not the only one who has this issue, see #13

ok so I found out those code in eloquent:
// If the model has an incrementing key, we can use the "insertGetId" method on
// the query builder, which will give us back the final inserted ID for this
// table from the database. Not all tables have to be incrementing though.
$attributes = $this->getAttributes();

if ($this->getIncrementing()) {
    $this->insertAndSetId($query, $attributes);
}

seems like we need to add this code to Favorite model
public function getIncrementing()
{
    return null;
}

ill add pr shortly

App\Models\Course::isFavorited must return a relationship instance. (View: E:\laragon\www\Courses\resources\views\admin\courses\show.blade.php)
What is the solution to this error?

Hey, have you resolved your problem?


support tag categories

There is a good chance we will want tags to be viewed in categories, so that things can be tagged both as 'compression' for compression machine and 'compression' as compression process.
Suggest we first get some mockups of what the output might look like to pick tags from a list and then build out existing components

Not sure if this is still relevant, will depend on current plans for tag and filter systems (I think now there is a separate section for categories independent of tags)


Instantiated API for Spark

Hi again!
#167 was out of date and I've created a new fork from the latest base code with the same changes. The goal here is to be able to use Spark with its default static API and by instantiating a SparkAPI instance.

This is definitely a move in the right direction, but I wonder if it might be better to do some real cleanup along with this, and release it as spark 3.0.  In particular, it would be really great to separate the pre-route pieces from the route-based pieces, and make both of the pieces immutable, so that the complicated synchronization/latch management could go away altogether.

+1
I also agree with the suggestion from @jkwatson about separate immutable pre-route and route-based pieces.

Tx, will have a look at this after my vacation (the week after next)

This is a very timely PR. We are currently considering moving away from Spark due to the overhead and coupling introduced by maintaining our own fork for a non-static interface. This would be a shame as other than that Spark fits our needs very well.
The non-static interface is more in line with our general practice, but the killer requirement is to be able to run multiple independent Spark-driven webapps in a single external Resin instance (i.e. a single JVM) without them trampling one another.
Please consider merging this sooner rather than later!

@benhyland I'll look at this ASAP. The pros and cons of an Instance API of Spark has been discussed a lot before and I'm still unsure of what is the best way to get this in Spark. I need to figure out if this is the best way or a more "sparkish" code style of running multiple web-apps is possible. The only thing holding back this is that I'm very protective of the Spark programming paradigm (which of course is based on static methods/imports)

@perwendel thanks very much!

@ggalmazor @jkwatson @heuermh @benhyland
I've had a look at the code and the implementation looks good. Why I'm not merging this is since I'm not at all sure that I think an open non-instance API is a good thing. Let me try to explain:
I do know the limitations that a static API creates and I know that a lot of people think static APIs are, almost always, wrong. The thing is, Spark is not designed just to be small and simple. A big reason, perhaps the biggest, was to design the API to be as declarative as possible and not imperative. To achieve and enforce this the API have to be static. To introduce an instance API would be a step in the wrong direction.
I try not be dogmatic when developing software but when it comes to APIs in general and specifically Spark I'm of the very strong opinion that there should only be ONE way of doing things. Not two ways of achieving the same thing. I do believe this consistency combined with the declarative API is a very big reason to Spark being as succesful as it is and also makes it differ from the other frameworks.
Adding functionality for allowing multiple Spark web apps in a single instance is another thing. This is functionality I think is good and plan to have. It's harder to achieve a good way of doing this in a static API but this I am working on. I will probably use parts of this PR to achieve this.

I'm not sure I understand how the static API makes for a less imperative style since it pretty much excludes any functional style of programming given that one, in essence, ends up manipulating global, mutable state.
The biggest problem we have on my project right now is that we can't do proper unit testing unless we hobble the unit testing system severely by firing up a new JVM for each test to guarantee sufficient predictability and separation.  That's the price of global state.  And that's extremely slow and it imposes lots of problems down the line if someone were to re-use our code as part of another project.

@borud
The fact that a global state is altered under the hood does not, at lest to me,  make the API imperative. When routes are defined the code is clearly declarative.
I don't know if we have the same understanding about what's declarative/imperative and what's not but I'll try to explain how I see it:
get("/hello", (req, res) -> "Hello World");

is a lot more declarative than:
SparkAPI spark = new SparkAPI();
spark.get("/hello", (req, res) -> "Hello World");

The first snippet just describes what the user wants, add a get route for /hello, hence declarative. The second snippet introduces the 'spark' instance which has no declarative function at all and introduces the imperative part that describes the SparkAPI being instantiated and that instance is later used for adding routes.
I do understand that a static API poses some difficulties regarding unit testing, but that is the cost that has to be taken for keeping a clean and declarative API.
If I want unit tests for my business logic I would create "handlers", extending Route, that holds the business logic and pass them as parameter to my route definition, e.g:
post("/books", new BooksCreateHandler());

Those handlers should be easy to unit test. There's also a tutorial on Spark and unit testing: https://sparktutorials.github.io/2015/07/30/spark-testing-unit.html

Per, your overall line of argument is as people have suggested to replace the static api for an instance ditto, when in fact we want to have both. Just wrap the static api around a singleton and it will be unaffected, keeping the nice and easy api we all like.
However, it is when we have written all kickoff spark apps and start using it for serious applications, demands for a more elaborated api arises. Such as being able to extend or override/replace certain parts, launch several servers in the same jvm listening on different ports and more.

@ribomation then you have missed what I wrote in a previous comment: "I try not be dogmatic when developing software but when it comes to APIs in general and specifically Spark I'm of the very strong opinion that there should only be ONE way of doing things."
I don't know how to address the extension/override part since I don't know what parts you mean you'd like to override replace? If it's your business logic, the example in my last post should be sufficient (BooksCreateHandler). If it's extending/overriding Spark itself I would not use it that way (if there was an instance API, I would probably make the class final to enforce consistency)
As I said before, launch several servers is a functionality that I plan to integrate in the future, however not via an instance API.
This is what it boils down to. When I created Spark, I basically put all the time into the API/programming paradigm. What I was trying to create was a paradigm that I saw was missing in java. I had to break tons of java conventions and recommendations to achieve what I was aiming for. I have since then been extremely protective of the API because I'm fairly sure that it's the biggest attraction of Spark, not that it's small etc. The whole idea with Spark was creating a declarative API with a strict paradigm on doing things, and just have one way of doing this. To introduce an alternative would be to go against the core idea of Spark. The idea I believe is the single biggest reason to Spark being a success.
I might sound stubborn about this, and in a sense I am. It's just that I think it would be bad for Spark in the long run to introduce an instance API.

@perwendel We are talking about slightly different things I think.  You are talking about syntax while I'm talking about semantics.  The more compact syntax of the static API "looks" more declarative, but when executed it mutates global state which makes it tricky to say much about the state of the system at any given time while mutating it without resorting to external coordination.  It also comes with all the problems of global state.  This isn't unlike programming with global variables in any programming language, with all the problems this entails.
In a truly declarative system there are no intermediary states before the object is exposed.  The declaration is parsed and the object it describes is instantiated in its final form before being exposed to the calling code.  The programming equivalent to a declarative description would be an immutable object.
I think the lengths one has to go to in unit tests is a clear illustration of how awkward messing with global, mutable state is.  And I don't see a solution for performing proper tests that verify that the routing is correct.  (For instance let's say you have an important before() and you want tests in several locations that your application will behave correctly if the before() is accidentally dropped -- even that becomes tricky since you will have to be very careful about the sequencing and concurrency of those tests -- meaning they will be slower, more error prone, harder to implement and much harder for newcomers to understand)
Having an instance based core API does not mean you have to sacrifice your preferred API.   It just means that you can have both.  You can make a wrapper class that contains a singleton Spark instance, and if you call the wrapper class Spark you should be able to run all existing code without any changes.
And for an instance-based API, you will essentially only have 2-3 more lines of code.  That will more than make up for having to write many orders of magnitude more lines of unit test code, loss of performance and increased complexity:
Spark spark = Spark.newBuilder()
    .get("/hello", (req, res) -> "Hello World")
    .post("/somewhere"), (req, res) -> "Got post")
    .port(8080)
    .build()
    .start();

If, in the above example, you imagine that Spark instances are immutable and that you provide a SparkBuilder class to help you build a Spark instance, you get much closer to the semantics of a declarative system in that no intermediate states are exposed.  The Spark instance either exists or it doesn't.  It is also clearly defined where the instance comes into existence and where you start it.  You also have the option of ensuring that inconsistent instances are not allowed to be instantiated.

@borud
I agree that we're talking about two different things. I am 100% focusing on the API, Not the implementation. I still hold the position that the static API is the most declarative API. I will soon change the underlying implementation to work with instances for different reasons.
However, as I said in previous comments, the API has highest priority. Being as easy to unit test as possible has not. Having two APIs for achieving the same thing isn't an option, I've explained in previous comments why.
The syntax:
Spark spark = Spark.newBuilder()
    .get("/hello", (req, res) -> "Hello World")
    .post("/somewhere"), (req, res) -> "Got post")
    .port(8080)
    .build()
    .start();

does not attract me, at least if I am looking for a Sinatra like framework. A fluent interface has its perks and there are definitely areas when it's preferable, but when it comes to adding routes, I prefer the static approach anyday.
One thing I haven't explained before is that I see Spark as part of a movement to "rejuvenate" java and free it from certain dogmas I believe is holding it back. The view that "static is bad" is one of those dogmas. Static can be very bad, but when it comes to designing declarative APIs (just the APIs) I think it's perfect (combined with static imports).
To be extra clear, I do believe the current limitation of one spark server per JVM instance is a problem and is the next thing I'll work on.

@perwendel looks like there is enough interest from the community (myself included) to move to a instance based API for spark.  I believe there have been a few attempts in this direction and contributing their time but their efforts haven't really lined up to what you think is best for the project.
Would it be possible for you to layout what your plans are somewhere (Google doc, wiki, etc) and have the community contribute their thoughts? It would also be great to capture some sort of immutable philosophy about the project (for example, the API should come first, keeping the framework micro, etc)

I would be really happy to use instantiated API in some form. Spark is a really elegant solution to a lot of my needs, I used it a few times, but testing is very cumbersome, and polluting global state in unpredictable way is a big no-no for me.

@i386
There is interest from parts of the community. I think it's a smaller part than this "thread" makes it look like. I've also explained it a couple of times why an instance based API is not currently an option. The idea of laying out the plans is very good. Even better is the idea of explaining the immutable philosophy behind the project. I've been meaning to have the explanation for the static API somewhere but capturing the philosophy would be even better. Thanks!

@AleksanderGrzybowski
As shown in both Spark tutorials and other forums testing is not very cumbersome, it's more a matter of how you design you code.
"polluting global state in unpredictable way" kind of sums up what I reject with a lot of the arguments for an instance API. If coded correctly, as Spark is, this is not a problem, at least not from my perspective.
IMHO there is a irrational fear of static in the java world that arose with the advent of DI, test with mocks, etc. As I see it, those design rules/conventions holds Java back.
Static (where fit) + lambdas + method references + breaking conventions combined can make modern , functional and really cool Java APIs.
As per my last comment, I will try to summarize and capture the "immutable" philosophy behind Spark so people can read and understand, agree or disagree, the decisions for the project.

@perwendel that's great stuff - I look forward to your write ups! 👏

Well... I can't say that I agree with your decision here.
The reality is that this PR (and the previous one) didn't get much traction from the community (just 5-10 people interested on going this way) but I'm disappointed that after working on this and trying to make a better Spark, the decision is made unilaterally claiming some hard to believe claims about rejuvenating the JVM.
I use Spark personally and professionally since before version 1.0 and this PR comes from my experience designing complex apps. Spark is very difficult if you're designing uncoupled software (with hexagonal architecture, in my case) and I think that this should be Spark's concern if it has the vocation of becoming a major player on Java's modern stack of frameworks and libs.

Agree, very disappointed and won't be introducing Spark anywhere new as a
result.
On 19 Oct 2015 22:57, "Guillermo Gutérrez"<EMAIL_ADDRESS>wrote:

Well... I can't say that I agree with your decision here.
The reality is that this PR (and the previous one) didn't get much
traction from the community (just 5-10 people interested on going this way)
but I'm disappointed that after working on this and trying to make a better
Spark, the decision is made unilaterally claiming some hard to believe
claims about rejuvenating the JVM.
I use Spark personally and professionally since before version 1.0 and
this PR comes from my experience designing complex apps. Spark is very
difficult if you're designing uncoupled software (with hexagonal
architecture, in my case) and I think that this should be Spark's concern
if it has the vocation of becoming a major player on Java's modern stack of
frameworks and libs.
—
Reply to this email directly or view it on GitHub
https://github.com/perwendel/spark/pull/308#issuecomment-149359604.

Hi @mread. I wrote that comment before realizing that some of this PR has been merged in #344
I think that this is a step in the right direction (still disappointed, though).

@perwendel thanks for explaining your approach further. I certainly appreciate your points about the deleterious effect on program design that mocks, IoC and so on have had in the past.
I want to point out that a lot of design patterns in the Java ecosystem originate from a time well before reasonable functional approaches were sufficiently succinct, and in many cases also from before parametric polymorphism entered the language. We shouldn't judge folks too harshly for using what they had available at the time :)
I am still not really seeing an advantage to shared mutable state in this instance but you have clearly made a decision, and that in itself is valuable for everyone concerned with this issue.
Can you provide similar clarity on the problem I mentioned before? Do you have any more info on whether or when Spark might be able to support multiple webapps defined in separate compilation units being run safely in the same JVM, in the multithreaded environment of a servlet container? You mentioned that you plan to support several servers but without more detail I'm not sure we are talking about the same thing. Thanks.


web-tooling-benchmark error

https://github.com/quickjs-ng/web-tooling-benchmark no longer runs with master:
$ ../quickjs/build/release/qjs --script dist/cli.js
Running Web Tooling Benchmark v0.5.3…
-------------------------------------
         acorn:  0.42 runs/s
         babel:  1.07 runs/s
  babel-minify:  1.05 runs/s
       babylon:  0.77 runs/s
         buble:  1.39 runs/s
          chai:  2.07 runs/s
        espree:  0.30 runs/s
Encountered error running benchmark esprima, aborting…
    at <anonymous> (dist/cli.js:147221:27)
    at <anonymous> (dist/cli.js:145250:30)
    at call (native)
    at <anonymous> (dist/cli.js:145221:37)
    at <anonymous> (dist/cli.js:145835:51)
    at call (native)
    at <anonymous> (dist/cli.js:145221:37)
    at <anonymous> (dist/cli.js:145940:26)
    at <anonymous> (dist/cli.js:145984:26)
    at call (native)
    at <anonymous> (dist/cli.js:145221:37)
    at <anonymous> (dist/cli.js:145990:26)
    at call (native)
    at <anonymous> (dist/cli.js:145221:37)
    at <anonymous> (dist/cli.js:146025:26)
    at call (native)

It's unclear to me why that happens, or when it started, but it definitely ran to completion in the past. web-tooling-benchmark hasn't changed so it must be something on quickjs-ng's side.

Passes with --stack-size 2048:
$ ../quickjs/build/release/qjs --stack-size 2048 --script dist/cli.js
Running Web Tooling Benchmark v0.5.3…
-------------------------------------
         acorn:  0.40 runs/s
         babel:  1.06 runs/s
  babel-minify:  1.06 runs/s
       babylon:  0.76 runs/s
         buble:  1.37 runs/s
          chai:  2.07 runs/s
        espree:  0.30 runs/s
       esprima:  0.53 runs/s
        jshint:  1.20 runs/s
         lebab:  1.09 runs/s
       postcss:  0.65 runs/s
       prepack:  1.25 runs/s
      prettier:  0.72 runs/s
    source-map:  0.73 runs/s
        terser:  3.14 runs/s
    typescript:  0.81 runs/s
     uglify-js:  0.84 runs/s
-------------------------------------
Geometric mean:  0.91 runs/s

I'm chalking this one up to "worked by accident before" for now.

Perhaps is a side-effect of the change in the stack size unit? At any rate, does it make sense to revisit the current default stack size of 256Kb?

V8 defaults to ~900k and that's sufficient to run web-tooling-benchmark in qjs, so, one the one hand, yes, good idea; on the other hand, maybe that breaks existing users? I can't really come up with a credible example though.
On a side note: with glibc, you can:
pthread_attr_t attr;
void *stack_top;
size_t stack_size;
pthread_attr_np(pthread_self(), &attr);
pthread_attr_getstack(&attr, &stack_top, &stack_size);

Where stack_top is in fact the lowest possible address because stacks grow downward.
That's a fairly reliable way of detecting how much stack space is available in JS_Eval but it's not very portable and means taking on a dependency on pthreads in quickjs.c, which not everyone will appreciate.
(No real conclusion here, just me musing out aloud.)

We could try and bump it, not sure what would break TBH.
I'm wondering why 900k? 1M is right there and is a nice power of 2 😅

I'm wondering why 900k? 1M is right there and is a nice power of 2

That's exactly what the Windows kernel team thought and is why the main stack is a nice round 1 MiB :)
For V8/Chromium, it's actually quite a bit more complicated than that. The default is 984k but they drop down to 864k on 32 bits Windows because of parasitic third-party integration software that gobbles up ~100k stack space, the kind of closed-source trash oldnewthing's Raymond Chen regularly writes about.
WASM is another environment where the stack is (usually) exactly 1 MiB.

Here is a PR: https://github.com/quickjs-ng/quickjs/pull/756


App overview locking mechanism

Currently the app overview allows the locking of the config applications. This locks all applications to not be editable. When I have defined my own applications, these will still show, even with "configsLocked": true'. Should that be possible?
I think, if we lock down our configs, we should not show custom added applications, even locked.
e.g.
Config has the following:
"configsLocked": true,
"serverConfigs": [
  {
    "baseUrl": "",
    "appName": "demo",
    "username": "",
    "password": "",
  }
],

Should I theoretically see a self defined app called "myApp" when configsLocked is true? It does currently, it just locks it the same way it locks the predefined config applications.

For the following paragraph:

Custom app: An app created by the user in the app overview or via a QR-Code
Config app: A pre defined app by the config.json.

The following parameters exist in the config (default if parameter does not exist):
"customAppsAllowed" (false) : If custom apps can be created, edited, deleted and started by the user. If false, then custom apps can only be deleted. Not started, not edited, not created. QR-Code scanner is hidden. (Dont auto delete to avoid confusing the user why all apps are now gone) -> Maybe explain why they can't be started when the user tries to start one that this app is configured to forbid them and the only reason we didn't delete them is so they can still save them somewhere before deleting them themselves. If this property is false, "clear apps" menu entry should still be visible if there still exists one custom app.
"serverConfigsLocked" (true): If config apps can be edited. If false, they can't be edited. Config apps can never be deleted or created by the user.
"serverConfigsParametersHidden" (true): If the appname and the baseurl of config apps is hidden. Title is always visible. If this is true, then serverConfigsLocked is implicitely true!
The following parameters exist in the server configs:
"locked" (false) : same as serverConfigsLocked but only for this config app.
"parametersHidden" (false) : same as serverConfigsParametersHidden but only for this config app.

Further notes:
forceSingleAppMode forces single app mode.
The "Manage single application" switch is hidden when either customAppsAllowed is false or forceSingleAppMode  is true.


Entry point plugins

Builds on top of @benbovy's work in building router factories in https://github.com/xarray-contrib/xpublish/pull/89 to build a plugin system, to try to implement some of my thoughts in https://github.com/xarray-contrib/xpublish/discussions/139
The plugin system uses entry points, which are most commonly used for console or GUI scripts. The entry_point group is xpublish.plugin. Right now plugins can provide dataset specific and general (app) routes, with default prefixes and tags for both.
Xpublish will by default load plugins via the entry point. Additionally, plugins can also be loaded directly via the init, as well as being disabled, or configured. The existing dataset router pattern also still works, so that folks aren't forced into using plugins as the only way to extend functionality.
It runs against the existing test suite, but I haven't implemented any new tests or docs yet.
Entry point reference:

https://setuptools.pypa.io/en/latest/userguide/entry_point.html
https://packaging.python.org/en/latest/specifications/entry-points/
https://amir.rachum.com/amp/blog/2017/07/28/python-entry-points.html

https://github.com/gulfofmaine/xpublish-edr/pull/8 Is an example of how a plugin can register itself via entry points.

This is great @abkfenris!
I'm wondering whether we should keep or deprecate routers. It is kind of duplicate of plugins and it is pretty easy to create small plugins.

Thanks @benbovy!
Right now I'm leaving towards leaving routers in. While routers and plugins have a lot of overlap in my PR, I bet we will continue to grow the amount of things that plugins can do increasing their complexity.
With routers a new user can go from 0-something really cool in very few lines of code, and without much additional understanding. I think that helps sell the story of why to use xpublish.
From there to building a plugin is a much smaller jump in understanding than getting someone to build a plugin in the first place. 'what's this register_routes() method I need to define, and where does self.dataset_router come from?'
What do you think about renaming routers? We could use dataset_routers or similar to help standardize the API and clarify where the routers are acting.

I had gotten a start on a new draft with some of things we discussed here, but then life happened and got in the way. Hopefully I can get it cleaned up and shareable this weekend.

Continuing plugin exploration in #145

Using Pluggy for plugin management in #146 to reduce the amount of things we need to invent.

Plugins are now implemented via #146!


Btmg redux

Incorporating the changes that were suggested in #50 after I closed it too early. Plus two other things.

That is, I've "unzipped", for each algorithm, (1) the setup/oracle and (2) the test. This is nice because we can generate the oracles once, noisily (it's noisy because they are all --save commands and turnt warns us with not ok ... # missing each time). This basically gets us into expect-testing land. We can now run the slow-odgi-all-tests target repeatedly against the same expect files. Any not oks here are meaningful.
One problem I'm having here is that make is not behaving as I understand it should. I would have thought that, if I had
slow-odgi-all-tests: slow-odgi-all-oracles

and I made all-tests repeatedly without touching the oracles, the all-oracles script would not be run after the first time: the dependency would be satisfied for free based on which files were newer. This does not seem to be happening; the all-oracles stuff is run every time.
No more load-bearing strings in flip
Important background: odgi really does add "_inv" to the name of a path if it flips it. That bit wasn't made up by me...
My previous system was:

For each path, check if it needs to be flipped. If it does, add "_inv" to its name and flip its segments. The dict containing these paths, whether flipped just now or not, is the new paths.
For each path in the dict that has "_inv" in its name, generate new links that make this path valid.

My new system is:

For each path, check if it needs to be flipped. If it does, add "_inv" to its name and flip its segments. The dict of these paths, whether flipped just now or not, plus a bool saying whether we just flipped it, is paths_dec. The dec is for "decorated".
For each path in the dict that is decorated with an "I was just flipped" bool, generate new links that make this path valid.
Strip paths_dec of its bools to create the new paths, which is now as before.

The point is that, earlier, an input graph that already had "_inv" in a path name would have led to link-generation, regardless of whether the path required flipping and therefore link-generation. Indeed, I think iterated calls to flip would have been unnecessarily complex (and eventually, after dedup, no-ops) instead of just being simple no-ops. I think the new style fixes that.

I've got a more complete review in my queue, but for now:

I would have thought that, if I had
slow-odgi-all-tests: slow-odgi-all-oracles

and I made all-tests repeatedly without touching the oracles, the all-oracles script would not be run after the first time: the dependency would be satisfied for free based on which files were newer. This does not seem to be happening; the all-oracles stuff is run every time.

Classic Make only does this "redo work only if something has changed" based on files. That is, it knows it needs to rebuild foo.o based on foo.c if the filesystem modification time for the foo.c file is newer than the foo.o file. So for "phony" targets like test-* that don't correspond to files, Make just assumes everything needs to be done every time.