Fix bug in extract_app_in_dir when getting remote

Sometimes, heroku client cannot find the remote app even when it's been added to git config. This fixes it.
Case:
git remote add heroku git@heroku.com:yourapp.git

# OR
heroku git:remote -a yourapp

# .git/config
[remote "heroku"]
	url = https://git.heroku.com/yourapp.git
	fetch = +refs/heads/*:refs/remotes/heroku/*

$ heroku logs
!    No app specified.
!    Run this command from an app folder or specify which app to use with --app APP.

closing since this was resolved in #1357


Fix webAPI CORS

With this fix you should be able to use HORNET nodes within Trinity (together with a reverse proxy like nginx)

Related to #3


Google Analytics Code found outside of  tag

The google analytics tracking code in FreeCen2 is placed outside head tag. Could we place it inside the  ?

@benwbrum ok to push to live?

I've verified this on test2 and it works.


Couldn't locate libffmpegsumo.so during installation. Audio notifications will be disabled

I'm using Debian Jessie amd64.  I installed plaidchat with npm and got the error:
Couldn't locate libffmpegsumo.so during installation. Audio notifications will be disabled
However I already have chromium installed and the libffmpegsumo file is here:
/usr/lib/chromium/libffmpegsumo.so

The current solution only looks for /opt/google/chrome. Can you try updating postinstall.sh to attempt to resolve/copy from /usr/lib/chromium, verify that audio notifications work, and then submit a PR?
https://github.com/plaidchat/plaidchat/blob/v2.5.1/postinstall.sh#L7-L8

please also test for /opt/google/chrome-unstable (chrome-dev builds)

:+1: for chrome-unstable.  People also use chrome-beta, so we need to account for all of those.

done a pr :-)

The original requested Chromium fix has been landed in 2.10.0. I will be submitting a follow up PR to take care of the straggling chrome-beta and chrome-unstable

As promised, we have added support for chrome-beta and chrome-unstable and it has been released in 2.11.0. Thanks everyone for their contributions to this issue =)

it looks like neither chrome-stable nor chrome-beta/chrome-unstable are shipping with libffmpegsumo.so any more (i double-checked, this isn't an arch-linux thing, google isn't shipping it within their official packages). i tried to use the .so from some other nw.js apps, however while plaidchat's setup-script does accept them, audio doesn't work with it. do you have any idea where to get a working .so for plaidchat, and would it be possible to implement audio without using it?

it looks like neither chrome-stable nor chrome-beta/chrome-unstable are shipping with libffmpegsumo.so any more (i double-checked, this isn't an arch-linux thing, google isn't shipping it within their official packages). i tried to use the .so from some other nw.js apps, however while plaidchat's setup-script does accept them, audio doesn't work with it. do you have any idea where to get a working .so for plaidchat, and would it be possible to implement audio without using it?
sry for double-posting, was logged in with wrong account ;-)

If Chrome is no longer shipping libffmpegsumo.so, then they won't be able to play mp3's. Can you verify that you can play mp3's from this test page in Chrome?
http://hpr.dogphilosophy.net/test/

well i am able to play the mp3-file from the page you mentioned, however i think this is done differently in chrome now. cause i do not have a libffmpegsumo.so inside /opt/google/chrome-unstable/ for an example, and i'm pretty sure this is the only place chrome libs are placed (at least in arch)

Hmmm, damn. For my sanity, can you run the following?
find / -name '*ffmpegsumo.so*' 2> /dev/null

/opt/Gitter/linux64/libffmpegsumo.so
/opt/MessengerForDesktop/libffmpegsumo.so
/opt/nw.js/libffmpegsumo.so
/opt/visual-studio-code/libffmpegsumo.so
/usr/share/atom/libffmpegsumo.so
/usr/share/spotify/libffmpegsumo.so
/usr/lib/node-webkit/libffmpegsumo.so
/usr/lib/node_modules/plaidchat/node_modules/nw/nwjs/libffmpegsumo.so
/usr/lib/node_modules/electron-prebuilt/dist/libffmpegsumo.so
if you wonder, the current non working libffmpegsumo.so plaidchat is using, was copied into a /opt/google/chrome/ directory before i installed plaidchat, so it is caught by the install-script, i removed the dummy directory afterwards

Ah, damn. Unfortunately, the beta of the latest nw.js isn't out on npm-installer yet either so we prob can't trust it.
Thankfully, the libffmpegsumo.so in electron-prebuilt peaked my interest. After some reseearch, I found a node module that offers prebuilt binaries of libffmpegsumo.so. We should explore using that module over copying from Google Chrome/Chromium:
https://github.com/eugeneware/ffmpeg-static

Damn, never mind. The module seems to be an executable itself, not the shared object library we want =(

After downloading the 0.13 alpha of nw.js, I discovered a libffmpegsumo.so in its bundle so it looks like this step is on its way out. Unfortunately, the beta seems unstable and I am having trouble running plaidchat.
https://github.com/nwjs/nw.js/tree/69daf184db463c060709299129d79d36c4afbb65#downloads
For now, I think our recommendation should be to wait to see when the next 0.13 stable release is coming out. It seems to be every 3 months based on the release tags, which means we are coming up shortly as the last minor release was March 4th.
https://github.com/nwjs/nw.js/releases

It looks like waiting has paid off<EMAIL_ADDRESS>was released yesterday and seems like it's bundled with libffmpegsumo.so
https://groups.google.com/forum/#!msg/nwjs-general/hhXCS4aXGV0/TUQmcu5XDwAJ
http://dl.nwjs.io/v0.12.3/chromedriver-nw-v0.12.3-linux-x64.tar.gz
However, there is no release on npm-installer yet so I will open a new issue.

https://github.com/aprilorange/nwjs
would this help?

That works as well but the maintainers of npm-installer have a reasonable response time so we are probably fine sitting tight for now.
http://issuestats.com/github/nwjs/npm-installer

npm-installer released its latest version but it looks like the bundled libffmpegsumo.so is failing to play audio notifications in plaidchat. When I copy over my libffmpegsumo.so from electron-prebuilt, it starts working.
I am going to file an issue so this is properly resolved for everyone rather than us working around it.

For reference, my work on using the new nw.js can be found here:
https://github.com/twolfson/plaidchat/tree/c5ad7ae0fb35a0b8ee9199777481849addfda5e4

@twolfson: Further to our discussion in: nwjs/nw.js#3723 -- Unless you're willing to mess with something like HTTPFS, I don't think there's much you can do without downloading the entire set of pre-built binaries (in a single ZIP), either directly or via electron-prebuilt and then cherry-picking your shared objects.
Alternatively, you can create a secondary project on GitHub, for example: plaidchat-dep, and use the Releases feature to store shared objects for each platform/architecture you support. The master branch should contain:

A basic readme stating that this is a support repo and is not meant for direct user consumption.
A basic file registry, in JSON, for example.

plaidchat-dep (master)
├── index.json
└── readme.md

The index.json file registry is responsible for mapping your local dependencies to their remote counterparts, for example:
{
  "v1.0.0":
  {
    "linux-x86":
    [
      {
        "filename": "libffmpegsumo.so",
        "binary": "https://github.com/plaidchat/plaidchat-dep/releases/download/v1.0.0/libffmpegsumo-x86.so",
        "sha256": "421c76d77563afa1914846b010bd164f395bd34c2102e5e99e0cb9cf173c1d87",
        "installPath": "./"
      }
    ],

    "linux-x64":
    [
      {
        "filename": "libffmpegsumo.so",
        "binary": "https://github.com/plaidchat/plaidchat-dep/releases/download/v1.0.0/libffmpegsumo-x64.so",
        "sha256": "6c855792af732daf809592e38920c58a886e3df741bac7bbde98a2e6c1c0925c",
        "installPath": "./"
      }
    ]
  }
}

The actual binary assets are hosted in the project's Releases section, for example:

Next, on postinstall, run a script that consumes https://raw.githubusercontent.com/plaidchat/plaidchat-dep/master/index.json and downloads the required NW.js dependencies for the current platform if they don't already exist or if their hash differs from what's in the remote registry.
Seems to me like the entire process can be automated without much trouble. Before publishing to NPM, your script should:

Fetch all relevant copies of Electron's binaries in ZIP format.
Decompress and save the relevant shared object files.
Update the JSON registry.
Upload the shared objects as a Release assets via GitHub's API.
Commit and push the file registry to GitHub.

Also, to quote NW's wiki again:

Consult a lawyer if you do not understand the licensing constraints and require patented media formats in your application.

I am not sure why this discussion is being brought back to plaidchat. Our problem isn't specific to plaidchat; it's generic to all mp3 support on nw.js projects.
Building a plaidchat-dep repository is short sighted because it is specific to plaidchat. It is inevitable that there will be another project which runs into the same problem of not being able to use a prebuilt libffmpegsumo.so from Google Chrome (which is still documented in the nw.js wiki). Hence, it's more of a platform problem and this should be discussed in nw.js.
We are already aware of the GPL copyleft required by Google Chrome's libffmpegsumo.so and document it in our README.
https://github.com/plaidchat/plaidchat/tree/v2.11.0#license

@twolfson: You are right. I was under the impression that you were looking for a project-specific solution. I'll go back to: nwjs/nw.js#3723

I am reopening this issue since it now exists in the form of Google Chrome not having the binary. I am going to close it shortly again with an electron's libffmpegsumo.so copy. But for now, it should be open.

The patch PR was landed in #129. Closing this issue


OIDC support

Jfrog announced OIDC support for Artifactory this year and there is API for it. And that's a really good news! OIDC looks really promising thing in case of secure authentication in Artifactory for GitHub Actions.
Describe the solution you'd like
It will be great if there is support for OIDC in Terraform provider for Artifactory as well. It should be helpful especially for companies with many projects. As a reference we can look on same feature in the Vault Terraform provider.

@oxdef Thanks for the suggestion. This has been suggested by others before but I moved them to the JFrog Platform provider repo. I'll leave this here so others will see where the resource will be implemented.

Dup of https://github.com/jfrog/terraform-provider-platform/issues/26

See https://github.com/jfrog/terraform-provider-platform/pull/47


Config doesnt save

When i "save" a config, it doesnt save and i know that because when i tried to load my legit config it didnt load, if you could, bring an update or tell me a fix if theres any
(yes i got another injector)

Create new config.

Create new config.

I create a new config, with all the settings but when i want to load it the next day, it doesnt load...

You pressed save, after create config?

yup


Apollo-LiveData-Support

Apollo-LiveData module

LiveDataResponse
The LiveDataResponse class maps Response to LiveDataResponse.
There are Success, Failure, UnsuccessfulResponse, Complete sealed type classes.
RxJava can handle the state of response about onNext, onError, onComplete.
But live data cannot handle and emit values about the many kinds of response.
So I think LiveData need some wrapper class about the response.

LiveDataApollo
The LiveDataApollo class provides methods for converting ApolloCall, ApolloPrefetch and ApolloWatcher types to LiveData sources.

AplloExtension
The ApolloExtension class provides extensions for converting ApolloCall, ApolloPrefetch and ApolloWatcher types to LiveData sources. It based on LiveDataApollo class.

LiveDataApollo & AplloExtension use case.
// LiveDataApollo
LiveDataApollo.
        from(apolloClient.query(EpisodeHeroNameQuery(Input.fromNullable(Episode.EMPIRE))))
        .observe(this, Observer {
        // do something
    })

// AplloExtension
apolloClient.query(EpisodeHeroNameQuery(Input.fromNullable(Episode.EMPIRE))).asLiveData()
       .observe(this, Observer {
      // do something
       })

AplloExtension and LiveDataResponse use case.
val liveData = apolloClient.mutate(FacebookSignInMutation.builder()
            .facebookToken(facebookToken).build()).asLiveData()

liveData.value.let {
     when(it) {
         is ApiResponse.Success -> signInLiveData.postValue(it.data)
         is ApiResponse.Failure -> messageLiveData.postValue(it.errorMessage)
      }
 }

@sav007
Please review the latest commits

One more rebase and I feel this is good to go. Great job!!

Closing this since it is superseeded by #1320


Request for a Jupyter file with step-by-step explanation or simple example

Dear Florent,
I hope this message finds you well. I have been actively using your repository, for my project, and I must say it has been a valuable resource. However, as I dive deeper into the codebase, I find myself in need of additional guidance to fully understand the implementation details.

I'm unable to reproduce the results you get

Dear Nahom,
Sorry for the delay, I was on long leave during the summer. Do you still need a notebook to guide you or at least a Readme explaining how to run the different scripts and in which order? I know I must provide such a Readme when I will have a little time to do so.
Thanks for your interest in this library,
Florent

Hi Florent, thank you for your reply.
I am able to the run the code. However transferring multi mode RCPSP instead of single mode RCPSP in to the code does not seem to work as I tried multiple options and routes to make a proper graph representation. Perhaps If you can make guide or jupyter file to implement that, it would be very useful!
Kind regards,
Nahom

I'm glad to hear that you could finally find your way in our scripts despite the lack of documentation!
Multi-Mode RCPSPs are quite different in nature to Single Mode RCPSPs (the only ones that are handled in our code at the moment). It is not obvious which GNN architecture can properly capture their structure. We identified it as a future line of research. We would happy to collaborate with you on this if you have some ideas you'd like share with us :-)
Kind regards,
Florent


Postfix: Smart host data validation & relayhost value generation improvement

Hi,
referring to this merge, I would like to suggest to adjust the data input validator for the smart host.
It should also accept an optional port and square brackets for the hostname, so all of the following should be possible to enter:
# DNS records: MX, CNAME, A, AAAA
example.com
example.com:25
example.com:587

# DNS records: CNAME, A, AAAA
[smtprelay.example.com]
[smtprelay.example.com]:25
[smtprelay.example.com]:587

# DNS records: none
<IP_ADDRESS> # --> implicitly transformed to [<IP_ADDRESS>]
[<IP_ADDRESS>]
[<IP_ADDRESS>]:25
[<IP_ADDRESS>]:587
2001:db8::1 # --> implicitly transformed to [2001:db8::1]
[2001:db8::1]
[2001:db8::1]:25
[2001:db8::1]:587

Ports are just examples, every port shall be possible to use.
Basically the address schema for Postfix parameter relayhost shall be respected.
For IP4 and IP6 addresses, square brackets shall only be optionally provided and implicitly added for the config file, which is currently not the case.
It is quite common that you don't want Postfix to resolve MX record but purely rely on the CNAME/A/AAAA records instead. Also, it is not unusual that a smart host requires SMTP auth and only offers this on port 587 instead of 25.
Having control for the way Postfix resolves hosts can very often be important for many scenarios so it would be good to have those options.

@fichtner relay_host is currently a HostnameField, to manage this I have to change to TextField and add a mask.
Is model bump ok for current installations or is there a migration script needed?


Feature/validation psc exists

IDVA3-555
Validation to check existence of a PSC
Ceases validation chain if PSC does not exist

CI: Security warnings found!

CI: Security warnings found!

CI: Security warnings found!

CI: Security warnings found!


Add TP, TN, FP, FNs to the metrics

Outputs cm values at recall % in json file (currently default values are [0.1, 0.25, 0.5, 0.75, 0.8, 0.85, 0.9, 0.95, 1] )

Very nice!!


Quarantine queue name should be more explicit

https://github.com/ONSdigital/sdx-receipt-rrm/blob/develop/app/settings.py#L15
Should be more like 'receipt_quarantine_queue' (receipt_rrm_quarantine?) than 'rabbit_quarantine'

Think this is done as part of another tidy up


update how we generate /meta_knowledge_graph endpoints

Issues:

The nodes section doesn't seem to match the actual smartapi edges / x-bte annotations (ID prefixes and biolink semantic types) for each kind of endpoint (general, api-specific, team-specific).

Maybe we want this to instead be specific to the smartapi edges (IDs / semantic types) available to each endpoint
Maybe the ID prefixes don't have to match what's in the smartapi edges...maybe it can match what's in the Node Normalizer? (but that seems riskier since Node Normalizer won't necessarily have the cross-mappings)

Maybe review: is the edges section accurate to the actual smartAPI edges for each kind of endpoint?

Quick code check:
The meta_knowledge_graph endpoint (using by-api but this applies to all 3 types) seems to use this controller, which uses this hard-coded file. I think this hard-coded file is outdated (based on the old way of doing ID resolution, before using Node Normalizer).
Note that I have a spreadsheet that might make comparing x-bte annotation to the /meta_knowledge_graph easier: https://docs.google.com/spreadsheets/d/1XY4RzytqKT2prJ4UYSsW4FlFGmGmhs_NrjMkmvoAYSE/edit?usp=sharing

Example:
MyVariant through BTE. Make a GET request to http://localhost:3000/v1/smartapi/09c8782d9f4027712e65b95424adba79/meta_knowledge_graph
The nodes section does not match the actual x-bte annotation (which becomes smartAPI edges). There are no operations to Transcripts, SmallMolecules, Drugs, etc. Also no operations use "name" or "SYMBOL" as the ID prefix
Listing the node semantic types / ID prefixes based on the x-bte annotation:

Gene: NCBIGene, ENSEMBL
Disease: DOID, OMIM
SequenceVariant: DBSNP

Listing the edges based on the x-bte annotation:

Gene affects Disease
Disease affected_by Gene
SequenceVariant affects Disease
Disease affected_by SequenceVariant
SequenceVariant is_sequence_variant_of Gene
Gene has_sequence_variant SequenceVariant
Gene related_to Disease
Disease related_to Gene
SequenceVariant related_to Disease
Disease related_to SequenceVariant

note:

/meta_knowledge_graph nodes section seems to be the same between endpoints (and between different teams / apis in those specific endpoints). This is a sign that something "hard-coded" is going on.
larger issue: are we still using "old biomedical id resolver stuff" like this ids.js file in this repo? Are we still using "old biomedical id resolver stuff" in other repos? does the actual biomedical-id-resolver module use any of the old code?
larger issue: the by-apis and by-team endpoints have been refactored....but it's not clear if they're fully updated (threading?). Mentioned by @tokebe

@tokebe the following /meta_knowledge_graph endpoints can kinda hang...

v1/meta_knowledge_graph: currently it might have all of the metaEdges that BTE has access to with its v1/query endpoint (so the API_LIST - which includes TRAPI and x-bte annotation stuff).

note the TRAPI policy here https://github.com/NCATSTranslator/ReasonerAPI/pull/320/files

v1/team/Service Provider/meta_knowledge_graph: basically all the x-bte annotation stuff

@tokebe perhaps this can be an issue for the interns (Listing the node semantic types / ID prefixes correctly based off the MetaEdge info  - from x-bte annotation in most cases, but also from TRAPI stuff for the v1/query endpoint)...

Right now it is using ids.js for the nodes section. I suppose the intended behavior is that the nodes correspond to all nodes that are contained in the MetaKG operations?

yeah....the idea is for it to do something else (not the ids.js...)

From what I understand, for TRAPI APIs, the metakg edges are derived from predicates.json (in the Sync/AsyncOperationsBuilder), which currently contains no information on the ID prefixes. I was thinking of changing predicates.json to include this info, but that would also require changing the operation builders in smartapi-kg. Is there some better way of getting this info or should I go with this course of action?

Should be fixed with the new commits/PRs. Also, just a note I found out there were a few ID prefixes which were the same except for some numbers, is this expected?
"FDBN00034",
"FDBN00002",
"FDBN00020",
"FDBN00014",
"FDBN00013",
"FDBN00021",
"FDBN00006",
"FDBN00024",
"FDBN00031",

@rjawesome @tokebe I haven't tested yet, since I made some posts in the bte-trapi PR asking for discussion.
For the post above, it looks like some APIs putting incorrect information in those sections (those look like some kind of food database's IDs...). We don't want to remove all id-prefixes that don't quite fit the biolink-model (since even our KPs have some that aren't in the biolink-model yet), but we probably would want to remove stuff like that (pending the discussion stuff I've brought up...)

Coping text from here:

Summarizing the discussion around sub-querying TRAPI KPs:
Current: uses the primary ID for QNode entities (from Node Normalizer output).
    The assumption: TRAPI KPs have some ID-cross-mapping ability (using Node Normalizer or some internal tool), so BTE can give the TRAPI KPs the primary ID (highest priority in the id_prefixes list for that semantic type, according to Node Normalizer and biolink-model).
Was proposed in discussion https://github.com/biothings/BioThings_Explorer_TRAPI/pull/471#issuecomment-1200087282: when generating MetaEdges/operations for the TRAPI KPs, take the subject/input semantic type or each MetaEdge and assign the ID prefix. The ID prefix would be the first element of the semantic type's id_prefix list in the nodes section of TRAPI-KP's /meta_knowledge_graph response.
    The assumption: TRAPI KPs maybe need specific ID-namespaces for their queries. They advertise their preferences (which may not follow the biolink-model's ordering and may prefixes that aren't in the biolink-model id_prefixes lists) in the nodes section of their /meta_knowledge_graph response

However, Andrew and I decided today that the proposed change wouldn't change the final sub-queries that much (right now) and the benefits of this change are unclear / not much.
CHP would likely benefit, since it may not be handling ID cross-mapping internally (with Node Normalizer or another tool). However, it has other issues (like requests to /meta_knowledge_graph endpoint timing out half-the-time...)
COHD seems to match the biolink-model id_prefixes lists
Automat APIs likely use Node Normalizer (or have some internal tool for ID cross-mapping)

So we decided that the proposed change doesn't have to be a separate issue right now. The discussion here can be revisited if it's useful...

also addressed by https://github.com/biothings/smartapi-kg.js/pull/56


Refactor pushforward functions, adjust typing errors, add docstrings and api documentation.

This pull request contains:

a modular pushforward setup, that works with explicit pushforward states and shares more code between mc and linearized push-forward (cf. Issue #21 ).
disables F722 globally (Source: jaxtyping) as pointed out by @Thomas-Christie and adds a workaround for F821.

Pytest and pyright passes.

This pull request also contains now:

Docstrings
API pages, there might be some rendering problems, I only checked every page quickly.


Do not run playbook when node filter empty

My Rundeck detail

Rundeck version: 2.8.4-1
install type: (rpm,deb,war,launcher?) RPM
OS Name/version: CentOS Linux release 7.3.1611 (Core)
DB Type/version: mysql? postgres? h2?.. MySQL

Expected Behavior
When no nodes are selected by filter ie. it is empty, I'd like the job to not execute.
Actual Behavior
When no nodes are selected by filter, job execution runs playbook against all nodes. Is this a problem with "hosts: all" in the playbook itself? A warning is present: "Warning: The Node filters specified for this Job do not match any nodes, execution may fail." but it runs on all nodes anyway.
If this is a problem with the playbook, how do I correct this problem without workarounds like environment variables?
How to reproduce Behavior

Create a simple playbook
Create job with said playbook (yaml details below)
Run job without selecting any nodes
Go to the log section

job details:
- description: Testing
  executionEnabled: true
  group: '*'
  id: f8fe978e-8393-4c14-baaf-b3b084ec72c8
  loglevel: INFO
  name: TestPlaybook
  nodeFilterEditable: true
  nodefilters:
    dispatch:
      excludePrecedence: true
      keepgoing: true
      rankOrder: ascending
      threadcount: 2
    filter: 'name: NONE'
  nodesSelectedByDefault: false
  scheduleEnabled: false
  sequence:
    commands:
    - configuration:
        ansible-become: 'false'
        ansible-playbook: /var/lib/jenkins/workspace/DevOps-Repo/playbooks/Empty.yaml
        ansible-ssh-auth-type: privateKey
        ansible-ssh-timeout: '10'
      nodeStep: false
      type: com.batix.rundeck.plugins.AnsiblePlaybookWorkflowStep
    keepgoing: false
    strategy: parallel
  uuid: f8fe978e-8393-4c14-baaf-b3b084ec72c8

playbook details:
---
- hosts: all
  gather_facts: False
  tasks:
  - name: Message
    debug: msg=asd

How would you go about setting this up?

@pawadski Can you retry with the latest version please? If the task is configured to run locally then it will by default pass --limit localhost otherwise it will pass a list of nodes that you specify.

Hello,
It still does it when my playbook has - hosts: all. The playbook has "dispatch to nodes" set. If I set it to run locally I can't supply a node filter to it?
There's a risk of playbooks doing unexpected things on hosts when someone makes a typo in the node filter. In our use case, the hosts need to be sent to the playbook by Rundeck.
Did I miss some configuration option or am I trying to do something that is not supported?

Hello,
Empty node filter commandline:
[ansible-playbook, /var/lib/jenkins/workspace/DevOps-Repo/playbooks/Empty.yaml, -vvv, --private-key=/tmp/rundeck/ansible-runner334590983460587723id_rsa, --user=root, --timeout=10, --become-method=su, --become-user=root]
This expectedly runs on all hosts because the playbook has "hosts: all" set. How should I setup the playbook so that this would fail? Use a custom variable?
Not matching node filter commandline (no nodes matched):
[ansible-playbook, /var/lib/jenkins/workspace/DevOps-Repo/playbooks/Empty.yaml, -vvv, --private-key=/tmp/rundeck/ansible-runner6743025305482220409id_rsa, --user=root, --timeout=10, --become-method=su, --become-user=root]

The way I'm reading the Rundeck documentation suggests that the job should fail because no nodes were matched before it even starts. Can I ask you to raise an issue with the Rundeck project and close this issue please? If the job doesn't fail because this is a workflow step, then I'm happy for you to re-open this issue.


Dynamics Build for Testing

2 things I would like to clarify.

I understand that Dynamics 365 in Docker image, which is technically the same as Cloud version, can be used for the testing, but when the build is updated so frequently, how soon do we have to go through the validation after a certain build becomes available?  One month?  3 months?
Japanese YEN is one of the very few currencies without any decimals, but is there any CRONUS set up as such?

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

ID: 936119a1-4f7e-ed69-f72e-44e41464f964
Version Independent ID: c30741c6-9408-775a-5ce0-3f6986445447
Content: Testing your Extension - Business Central
Content Source: dev-itpro/compliance/apptest-testingyourextension.md
Service: dynamics365-business-central
GitHub Login: @SusanneWindfeldPedersen
Microsoft Alias: rweigel

Hello, you have reached the repo for documentation issues. Please contact your usual support channel to get help with these questions. Thanks.


Out of combat visibility

SAOs could be slightly less visible when out of combat.
This is especially useful for buffs that are active for much longer than 10 seconds e.g., Killing Machine (30 secs).
Many combat addons simply implement this feature with a reduced alpha, so it may be a good place to start.
Ideally, there would be fadeIn/fadeOut animations as well.

Implemented in #35


Move Calculations from CalendarScreen to Enhance Modularity

Issue Description
Currently, various calculations (next expected period, next expected ovulation, averages and stuff like that) are performed within the CalendarScreen file. To improve the modularity, maintainability, and ease of development of the application, these calculations should be relocated to a separate file. Namesuggestion is; Calculations (or come up with something better)
Proposed Solution
Identify all calculations currently residing in the CalendarScreen file.
Create a new file dedicated to handling these calculations.
Refactor the CalendarScreen file to call functions from the new calculations file as needed.
Benefits
Enhanced modularity of the codebase.
Improved maintainability, making it easier to manage and update the code.
Facilitated development, allowing for clearer separation of concerns and more straightforward debugging.

Started working on this

Im going to look at if we can move follicleGrowthDays and some more stuff. Working on it.

follicleGrowthDays is calculated in CalendarScreen to be used with calculation of next ovulation. So because of this we can continue to send this variable to statistics, unnecessary to re-calculate it in statistics again.


Enable basic auth for kafka connect cluster

[ ] Breaking change? (if so, please describe the impact and migration path for existing application instances)
There wont be any breaking changes

What changes did you make? (Give an overview)
Enable to connect to Kafka-connect-cluster which has basic auth enabled
Is there anything you'd like reviewers to focus on?
I have updated the swagger doc for connect, it will be nice if someone can have a look at it
How Has This Been Tested? (put an "x" (case-sensitive!) next to an item)

[ ] No need to
[ x] Manually (please, describe, if necessary)
We are using kafka-ui in our local environment where we connect to kafka-connect-cluster which has basic auth enabled
[x] Unit checks
[x] Integration checks
[x] Covered by existing automation

Checklist (put an "x" (case-sensitive!) next to all the items, otherwise the build will fail)

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation (e.g. ENVIRONMENT VARIABLES)
[x] My changes generate no new warnings (e.g. Sonar is happy)
[x] I have added tests that prove my fix is effective or that my feature works (I couldn't add new tests because the way the abstract test class is used)
[x ] New and existing unit tests pass locally with my changes
[ x] Any dependent changes have been merged

Check out Contributing and Code of Conduct
A picture of a cute animal (not mandatory but encouraged)

@gaddam1987 you've probably not pushed at all considering the history :) feel free to ask any questions regarding that

@Haarolean
I tried to update but for some reason i don't know it didn't reflect, you can see the change in commit hash from previous pull request.
New commit hash: 4705bfacbb96f5a82692c495c2e869e61a07e1b1
Old commit hash: 72b36c89789347f84b6818ef85f7e8f92a0b3b9b
Steps i followed:
I need to remove 2 files from the commit 72b36c89789347f84b6818ef85f7e8f92a0b3b9b as i have accidentally added some new lines.
kafka-ui-api/src/main/java/com/provectus/kafka/ui/util/ClusterUtil.java
kafka-ui-api/src/main/java/com/provectus/kafka/ui/serde/schemaregistry/SchemaRegistryAwareRecordSerDe.java
And pushed that changes with force push: git add . && git commit --amend --no-edit && git push -f  (This change didnt reflect in the pull request)
Then i did a rebase to remove the conflict: git rebase origin/master and pushed using git push -f which didn't reflect any changes in the pull request too.
I could be missing something :)

@gaddam1987 dunno what you've done actually, any forced push is clearly visible in PR history anyway, but there were none.

@gaddam1987 please document new env variables somewhere (env params list at the end of README, corresponding docker-compose examples)

@Haarolean Hi, i have updated the doc can you please check it once

@gaddam1987 thanks! But please don't squash commits in the future if that's not necessary, otherwise we have to review all the files over and over again (they're not marked as viewed)

Sorry for that, i am used to this flow in my org but will remember next time not to squash commits. Thanks for merging the change :)


🐛 BUG: Unable to create Hyperdrive from Wrangler CLI

Which Cloudflare product(s) does this pertain to?
Other (Hyperdrive)
What version(s) of the tool(s) are you using?
3.18.0 [Wrangler]
What version of Node are you using?
20.10.0
What operating system are you using?
Windows
Describe the Bug
I'm unable to create a Hyperdrive for my database hosted on Neon due to a not_entitled [code: 10000] error.
I tried both using the default wrangler login and manually creating an API token with Hyperdrive: Edit permissions, but neither seems to work.
Please provide a link to a minimal reproduction
No response
Please provide any relevant error logs
...\project>npx wrangler hyperdrive create test --connection-string="postgresql://cloudflare:********@********-pooler.us-east-2.aws.neon.tech/****?sslmode=require"
🚧 Creating 'test'

X [ERROR] A request to the Cloudflare API (/accounts/********/hyperdrive/configs) failed.

  not_entitled [code: 10000]

You may have set a system env variable. If it exists, you can delete it and clear the cloudflare cookie. then try again
npx wrangler login
npx wrangler hyperdrive...

Sorry for the delayed reply.
I get the same error when trying to create a Hyperdrive.
For what it's worth, I don't actually see the Hyperdrive scope in the list of scopes requested.

not_entitled means your account is not entitled to use the Hyperdrive product. This could mean that you do not have a paid Workers subscription. If you in fact have a paid Workers subscription, please contact support.

That was the issue! I didn't realize that Hyperdrive required a Workers subscription. After I signed up, it showed up in wrangler. Thank you for your help!


Namespace for EnumerableExtensions causes conflicts

Similar to https://github.com/aloneguid/support/issues/8

The issue has no description

Sorry, I thought the one linked was sufficient since this is essentially the exact same problem.
Essentially, if I were to use this library, its dependency on Netbox introduces extension methods into the System.Collections.Generic namespace that conflict with my own extension methods. There is no way to work around this since those files often depend on other System.Collections.Generic types.
Of course, it is possible to disambiguate like so:
PathToOwnImplementation.ForEach(someList, item => item.DoSomething());

But that's a bit painful.

Hey we have no dependency anymore, if you're upgrading this needs to be removed manually from NuGet

Awesome, thanks :)


GitHub actions

Describe the problem
I want to have a GitHub action for the people that have a slow PC (like me).
Yesterday to run a easy app It took 2 hours
Describe the solution you'd like
Create a builder on GitHub actions
Alternatives considered
No response
Additional context
No response

https://github.com/tauri-apps/tauri-action/


[test] Current behavior when disabling components variants

[x] I have followed (at least) the PR section of the contributing guide.

fixes #27162

Thanks @noviicee!


Have no horizontal scroll bar in many windows under IDA 6.95 & Black theme

Will have a pull request later.
Besides, considering its reason, i think this bug also exists under other IDA 6.x versions.

Pull request committed.

The problem seems happened again.
I've checked the history and seems commit 027c646 and commit 292090d is broken by commit 057fd69, which is referenced in p.r. #17 which imported a new skin.
Since I'm unfamiliar with Qt, it might be a good idea to check new style sheets and see if something wrong.
Thanks.
@athre0z

We just haven't pushed a new version for many months, thus these changes aren't yet available in the release version. I might push a new version if I find time in the coming few days.

Oops, just found it.
I've cloned and applied the new skin from repo. The scroll bar come back again and everything is fine now.
Sorry for such a bother...


Report feature request

Daily or weekly report like widget "Problem hosts" by cron

@zappbrannigan34 so what's the problem? Create the report and send it via the script.

example?

./report.sh > /tmp/report.txt
zbxtg.py @username "Report" "$(cat /tmp/report.txt)"

zabbix report is graphics

https://www.zabbix.com/integrations/pdf

So? Create by yourself.
I'm not "I want something, do it for free for me" guy.

its feature request, not pr

It will never be implemented here


Use the latest ruspiro-crate versions

Use the latest versions and fix some dependency settings regarding forwarding features.
Now ruspiro_pi3 and with_uart are also default features.

lgtm


How can I make this?

Question
Hello,I am very thinkful to use this project.Now,I have a question,how can I make this plot by lightweight-charts-python。I read the TUTORIALS but I didn't find how to make it.Can you show me a demo ?Thinks very much!!!

Code example
No response

Hey @95ge,
Please read the docs on Synced Line Charts for info on how to implement MACD.
Louis

hello!,I read the Link,But I still can not understand it ,can show make a example code in the examples florder? thank you!


build: remove the use of arc in favor of pre-commit

https://pre-commit.com/  available via apt install pre-commit
By default the checks which run a formatter will only verify that the formatter wouldn't change anything. Running the checks manually via: pre-commit run --hook-stage manual will actually run the formatters (and staticcheck).  I've also fixed all of the warnings produced via pre-commit run --all-files with the exception of the staticcheck issues.
Buildbot has been updated, but new images have not been built or pushed yet.

Note: running setup_hooks.sh again will keep the previous script, you may need to run pre-commit install -t pre-push -f manually to overwrite the previous script.

Buildbot managed to push a new, backward-incompatible release today (v3.0.0, so new even the documentation thinks it isn't out yet), which has complicated this a bit.  I think I have it fixed, but ugh.


[5.1.2] Progress message shows separate percentages when exporting multiple configurations

Bug report
What is the current behavior?
When exporting multiple configurations the percentage of the progress message does not show a combined value but rather switches between the individual sub projects.
If the current behavior is a bug, please provide the steps to reproduce.
module.exports = [{
  output: {
    filename: './dist-amd.js',
    libraryTarget: 'amd'
  },
  name: 'amd',
  entry: './app.js',
  mode: 'production',
}, {
  output: {
    filename: './dist-commonjs.js',
    libraryTarget: 'commonjs'
  },
  name: 'commonjs',
  entry: './app.js',
  mode: 'production',
}];

What is the expected behavior?
It would be great, if a combined (based on on the totals or the minimum) percentage could be shown.
Other relevant information:
webpack version:  5.1.2
Node.js version: 14.13.0
Operating System: 10.15.7
Additional tools:

Please provide more information what you expected

You ignore **If the current behavior is a bug, please provide the steps to reproduce.** section, I will reopen this after you fix it

I do absolutely respect the time of others developers and actually filled out the If the current behavior is a bug, please provide the steps to reproduce. with the example from the webpack documentation to explain that this is a generic problem and not specific to a unique configuration.
I'm not sure on how to better describe the expected behavior:

imagine a configuration with several (quite different) configurations
currently the progress message shows a percentage that flips between each individual configuration (10%, 11%, 2%, 15%, 3%, ...) because it seems (just an educated guess) to flip between the different configurations
it would be more useful, if the percentage wold be either calculated based on the total numbers from all configurations or (if this is not possible) at least always only show the minimum of the the individual configurations

@doberkofler expected, different configurations === different builds

If this is really expected I will just have to accept it, but I really don't understand why someone would expect a percentage that just flips between builds?

@doberkofler because each bundling knows nothing about the other bundling, and combining them is a difficult task, also it reduces readability

I understand! Thank you!


electrum: 4.0.6 -> 4.0.7

Version update - release notes: https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES
This release also fixes compatibility with dnspython 2.x, so we can drop the overrides
Also cryptography is required instead of pycryptodomex (which is required only for tests now) and ecdsa dependency is dropped completely

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 106459 run on x86_64-linux 1

1 package built:

electrum

Fails on darwin with:
                    except OSError as err:                                                                                >                       raise OSError(err.errno, 'error while attempting '                                                                                'to bind on address %r: %s'                                                                                % (sa, err.strerror.lower())) from None                                                                                E                                     PermissionError: [Errno 1] error while attempting to bind on address ('<IP_ADDRESS>', 42898): operation not permitted                                                                                /nix/store/cwrsy4lr71pbs89krkfcwb3s4amc3rjg-python3-3.8.6/lib/python3.8/asyncio/base_events.py:1463: PermissionError                                                                        --------------------------- Captured stderr teardown --------------------------

....

electrum/tests/test_network.py::TestNetwork::test_can_connect_during_backward
electrum/tests/test_network.py::TestNetwork::test_chain_false_during_binary
electrum/tests/test_network.py::TestNetwork::test_fork_conflict
electrum/tests/test_network.py::TestNetwork::test_fork_noconflict
  /nix/store/cwrsy4lr71pbs89krkfcwb3s4amc3rjg-python3-3.8.6/lib/python3.8/asyncio/events.py:81: RuntimeWarning: coroutine 'ignore_exceptions.<locals>.wrapper' was never awaited
    self._context.run(self._callback, *self._args)

-- Docs: https://docs.pytest.org/en/stable/warnings.html
=========================== short test summary info ============================
FAILED electrum/tests/test_lntransport.py::TestLNTransport::test_loop - Permi...
============ 1 failed, 502 passed, 3 skipped, 4 warnings in 39.40s =============
--- Logging error ---
Traceback (most recent call last):
  File "/nix/store/cwrsy4lr71pbs89krkfcwb3s4amc3rjg-python3-3.8.6/lib/python3.8/logging/__init__.py", line 1084, in emit
    stream.write(msg + self.terminator)
ValueError: I/O operation on closed file.
Call stack:
  File "/nix/store/cwrsy4lr71pbs89krkfcwb3s4amc3rjg-python3-3.8.6/lib/python3.8/threading.py", line 890, in _bootstrap
    self._bootstrap_inner()
  File "/nix/store/cwrsy4lr71pbs89krkfcwb3s4amc3rjg-python3-3.8.6/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/private/tmp/nix-build-electrum-4.0.7.drv-0/Electrum-4.0.7/electrum/plugin.py", line 214, in run
    self.on_stop()
  File "/private/tmp/nix-build-electrum-4.0.7.drv-0/Electrum-4.0.7/electrum/util.py", line 357, in on_stop
    self.logger.info("stopped")
Message: 'stopped'
Arguments: ()

Fails on darwin with:

Disabled the offending test in 16b38b07821de532b33aedaf85b45dbbc0a38e39


Cannot login with github even tho my account still exists

Describe the bug
I signed up with my Github account, I've now changed my email adress in Github and I'm now unable to login to codewars. I'm getting redirected to the main page but still not logged in.
To Reproduce
Go to login page, press on login with GitHub
Expected behavior
Login should happen
Browser
Chrome

OS: Windows
Browser: Chrome
Version: 101.0.4951.54

Changing your email in GitHub shouldn't change anything on Codewars side because we use the user id to find the associated user.
Is https://www.codewars.com/users/charliearaya your account? No GitHub account is not linked to it at the moment.
To log in with GitHub again, you can sign in to Codewars by using password reset, and link your GitHub from Account Settings.

The password reset is not working, I'm getting an error that no account is linked with my email. Is it possible you can trigger that for me?


Build for Python 3.8 & 3.9

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender.

@conda-forge-admin, please rerender.

@conda-forge-admin, please rerender.

@isuruf could you comment on whether this is the right thing to do here? We have some downstream packages that use surface-dynamics in their CI and it would be nice to test with different versions of SageMath there. Is it reasonable to blow up the build matrix like this here or is there a better way?

@conda-forge-admin, please rerender.

@conda-forge-admin, please rerender.

Is it reasonable to blow up the build matrix like this here or is there a better way?

Yeah, that's fine.


Motion forwarding: enhance dialog options

Description: The current motion forwarding dialog should be enhanced in several aspects. In general the aim is to provide a broader range of different options which the user can choose from.
What do we need?
The forwarding dialog needs to be enhanced with new options where the user can choose which content (version of motion), which submitter, which identifier and in which meeting the motion should be forwarded. Below is a list of the new dialog options:
Motion version:

Orginal motion text with amendments/change recommendations
Final version (note: if Editorial final version is available, use this one)

Submitter:

original submitter name
committee name

Identifier:

original identifier
without identifier

Meeting selection
Here an example image, how this forward dialog should look like

There's a backend PR for this: https://github.com/OpenSlides/openslides-client/issues/3527
Please look into if this works for you

The backend PR for this is https://github.com/OpenSlides/openslides-backend/pull/2399
It allows to set use_original_submitter and use_original_number. I include the two options in my pull request.
What should be done with Motion version?

Use the text the client generates for the named version and write it into motion.create_forwarded's text argument

Given issue #3609:
If the committee is selected as submitter in the new dialog then no new User should be created but the committee name should be written into the extension text field for submitters
What should happen if the 'original submitter name' is selected?
What I expect:

no new user is created
extensions are written into the extension
If a User exists in the forwarded to meeting, then the User is assigned as a submitter
If a User does not exist in the forwarded to meeting, then the User's name is written into the extension
[the order of names in the extension should be the same as it was in the original motion, at least as much as possible ]


License?

Hi. Cool article, and code :)  Dont suppose... possible to add a license to the code please? (e.g. MIT for example?)

Hi, thanks! Apologies for not seeing this sooner, a license has been added now.


cleanup: make godot warnings fixed in our source repo

Signed-off-by: Humble Chirammal<EMAIL_ADDRESS>

@Madhu-1  @nixpanic  @Yuggupta27 ptal

Were these godot warnings reported by golangci? Afaik, only Top level comments should end in a period. Comments inside a block don't need to satisfy this condition.

Were these godot warnings reported by golangci? Afaik, only Top level comments should end in a period. Comments inside a block don't need to satisfy this condition.
For reference see: b7e4794
True.. let me correct it .. Thanks :+1:

we don't need this one, just verified it with godot tool.


instanceOf ignores subclassing

I'm confused as to why you would make instanceOf so specific:
function instanceOf (instance, model) {
    return instance.constructor === model;
}

Because you use this (rather than the native browser's instanceof), many subclasses will not work. Example:
var cancan = require('cancan')
var Liquor = Backbone.Collection.extend({})
var Beer = Liquor.extend({})
var User = function() {}

cancan.configure(User, function(user) {
  this.can('buy', Liquor)
})

var user = new User()
var liquor = new Liquor()
var beer = new Beer()

cancan.can(user, 'buy', liquor) // returns true
cancan.can(user, 'buy', beer) // returns false

I would expect subclasses to work, such that I don't have to configure every single subclass in cancan.configure.

Good point, would you be interested in making a PR?

Made this check more loose in v3.0.0. Check out the new v3's readme ;)


how to control keyboard when user selected something

Operating system: CentOS 7.1
PHP version: 7.1
Update Method: Webhook
Self-signed certificate: No

hi everyone
i already have the keyboard.
i want to do something when user selected one of the keys
and i want to find out which key selected, and then i want to run an Method for every individual key when selected.
for example:
i want to give a phone number from user, i have two keys in my keyboard: 1. auto send my number 2. enter manually
so, how i can control them? i mean i want to do something when user selected one of them , and then do something with the next thing that user sends to bot,
but i've no idea how to do it

first of all, thanks to @noplanman for helping me.
for this purpose that i've, i should use conversion and for using that. i needed to rewrite my Command class in new format! what format? this format
also i needed to create new mysql db and connect it to the script using root/hook.php file
and there you go!
it works so well

Well done!


Bug: Fullwidth in english not found

Come and Join us！
The microphone or camera is occupied，Please check and re-record the video。
Exchange’s only SPAC securities trading.
Your current input amount has exceeded the “Convertible Amount”

Done in https://github.com/huacnlee/autocorrect/commit/6c4a7832377f66a7833451436e0dbdb47871db2c


feature request: optional list options

Hi @pforret,
bashew is a really great template and it saves me a lot of time!
I was wondering if you could add support for optional list options.
As an example I can present the -f option of the docker-compose CLI command.
It is optional but you can pass it multiple times to source different docker-compose-files:
docker-compose [-f <arg>...] [options] [COMMAND] [ARGS...]
docker-compose up # works!
docker-compose -f docker-compose.yml -f docker-compose.admin.yml up # works too!

I can achieve something similar using bashew when I pass the options as a single string:
bashew-compose -f "docker-compose.yml docker-compose.admin.yml" up

However, doing it this way I lose the benefit of filename completion by my shell.
Do you think this would be a useful feature?
Is there an easy way to add this to bashew?

Hi Sven,
what you want, is options that can be called > 1. This is not easy because of the way the options are parsed in bashew:
--config [value] is parsed into a $config variable, not an array.
A possible solution would be to allow --config:1 [value] --config:2 [value] syntax which would then be parsed into an array.
Me, I currently use comma-separated values e.g. --effect dark,blur,grain in pforret/splashmark, but you're right that it doesn't work well for file names.
It's a good suggestion, let me think on that one!

First off, kudos to you, @pforret, for creating such a wonderful project! The amount of effort you've put in really shines through.
Secondly, I'm quite possibly showing my own ignorance here as I don't know the intricacies of how Bashew does parameter parsing, but why, in this case, it isn't possible to simply define an array variable for a given parameter and append to it while going over the parameters?
Here's a simple working example outside of Bashew that on the face of it seems to work:
#!/usr/bin/env bash

script_name=$(basename "${BASH_SOURCE[0]}")
script_ver='0.0.1'

usage() {
  cat << EOF
Usage: ${script_name} [-h | --help] [-v | --verbose] [-V | --version]

Example script to demonstrate for optional list options.

Available options:

-h, --help           Print this help and exit
-v, --verbose        Print script debug info
-V, --version        Print version number and exit
-c, --config-file    Configuration file(s) to be consumed

Example: ${script_name} -c file1.yml -c file2.yml
Example: ${script_name} --config-file file1.yml --config-file file2.yml

EOF
  exit
}

config_files=()

while :; do
  case "$1" in
  -h | --help) usage ;;
  -v | --verbose)
    set -x
    export SHELLOPTS
    ;;
  -V | --version) echo "$script_ver" && exit ;;
  -c | --config-file)
    config_files+=("$2")
    shift
    ;;
  ?*)
    echo "Unexpected parameter: '${1}'"
    usage
    ;;
  *) break ;;
  esac
  shift
done

for file in "${config_files[@]}"; do
  echo "Working with file: ${file}"
done

First off, kudos to you, @pforret, for creating such a wonderful project! The amount of effort you've put in really shines through.
Secondly, I'm quite possibly showing my own ignorance here as I don't know the intricacies of how Bashew does parameter parsing, but why, in this case, it isn't possible to simply define an array variable for a given parameter and append to it while going over the parameters?
Here's a simple working example outside of Bashew that on the face of it seems to work:
#!/usr/bin/env bash

script_name=$(basename "${BASH_SOURCE[0]}")
script_ver='0.0.1'

usage() {
  cat << EOF
Usage: ${script_name} [-h | --help] [-v | --verbose] [-V | --version]

Example script to demonstrate for optional list options.

Available options:

-h, --help           Print this help and exit
-v, --verbose        Print script debug info
-V, --version        Print version number and exit
-c, --config-file    Configuration file(s) to be consumed

Example: ${script_name} -c file1.yml -c file2.yml
Example: ${script_name} --config-file file1.yml --config-file file2.yml

EOF
  exit
}

config_files=()

while :; do
  case "$1" in
  -h | --help) usage ;;
  -v | --verbose)
    set -x
    export SHELLOPTS
    ;;
  -V | --version) echo "$script_ver" && exit ;;
  -c | --config-file)
    config_files+=("$2")
    shift
    ;;
  ?*)
    echo "Unexpected parameter: '${1}'"
    usage
    ;;
  *) break ;;
  esac
  shift
done

for file in "${config_files[@]}"; do
  echo "Working with file: ${file}"
done

Hi @usrme ,
you are exactly right that the implementation should be done with bash arrays - config_files+=("$2")
It's a bit more involved in bashew because I use just 1 function list_options() to define all flags/options/parameters and all usage info/variable initialisation/parsing is derived from there. I just implemented this in bashew version 1.13.0 (the 'normal' template)
Hi @spalberg ,
I did it the following way: there is now an option type 'list' that is by default an empty array and that you can call multiple times: --file /path/file1 --file /path/file2 and that you can use after automatic parsing as an bash array ${file[@]}
Thanks for the suggestion and I hope this makes bashew even better for your usage!
Peter

Hi @usrme ,
you are exactly right that the implementation should be done with bash arrays - config_files+=("$2")
It's a bit more involved in bashew because I use just 1 function list_options() to define all flags/options/parameters and all usage info/variable initialisation/parsing is derived from there. I just implemented this in bashew version 1.13.0 (the 'normal' template)
Hi @spalberg ,
I did it the following way: there is now an option type 'list' that is by default an empty array and that you can call multiple times: --file /path/file1 --file /path/file2 and that you can use after automatic parsing as an bash array ${file[@]}
Thanks for the suggestion and I hope this makes bashew even better for your usage!
Peter


[📑 Docs]:

What Dev Docs changes are you proposing?
Marco
Code of Conduct

[X] I agree to follow this project's Code of Conduct

@Marco1553 can you please elaborate this issue???

Closing as incomplete


Provide better/real changelog

Current Implementation
An update was released this morning. Unfortunately the changelog was not very meaningful. "Minor adjustments" (German: "Kleinere Anpassungen")
Suggested Enhancement
This might be fine for the Play Store (in my opinion it's not), but there should at least be a detailed changelog on Github.
How can we handle this in the future?
Expected Benefits
More transparency for users and developers

I'm with you on that, but v1.0.1 and v1.0.2 where literally minor adjustments.
#447
#470

Okay, so the changelog for the Play Store might fit here. Nevertheless, the changes should be more visible via "Releases" or a "Changelog.md".

Thanks for your proposal. We already have an issue open for that #511

Release Notes provided in https://github.com/corona-warn-app/cwa-app-android/releases/tag/1.0.3


AppearanceKeys are empty in some checkboxes

Hi Benoit,
It's me again :) I've almost filled all the CERFA "avis d'arrêt de travail" forms, but I'm still having an issue with some checkboxes.
Before explaining further, I need to mention that this problem only affects certain types of checkboxes. Most of them work flawlessly.
When I target a field and try to get its appearance keys, they are empty:
appearanceKeys := originalFields[key].Field.AppearanceKeys()

You can see this issue with the "INI" field in the attached file.
If you have any ideas, I'm interested. I will also try to check your library and submit a PR.
Thank you!
CERFA_SL.pdf
NB: I've tried using both "INI" and "INI." (since both names exist), but neither made a difference.

Hi Christophe,
This PDF file definitively makes strange choices regarding the AcroForm. In this case, the fields under the "INI" parent actually have empty names.
I had not expected such behavior : to fix the issue, I now also use the index in the parent slice to identify a field. More precisely, a field with no name uses its (0-based) index as replacement.
In your case, for the "INI" field, you are then actually looking at "INI.4" and "INI.5". Could you try that using b3aaaf6 ?

Hi Benoit,
Thank you for the feedback and library improvement!
Yes, I noticed that too :) and it's an official document from the French administration... I hope it doesn't cause too much trouble for your library.
I've tried with the b3aaf6 commit, but I still don't get any keys. Is there something wrong with this snippet?

func (f Filler) Fill(values map[string]any) error {
    originalFields := f.Templater.Document.Catalog.AcroForm.Flatten()
    fields := make([]formfill.FDFField, 0, len(values))
    for key, value := range values {
        f := formfill.Values{}
        switch as := value.(type) {
        case string:
            f.V = formfill.FDFText(as)
        case []string:
            f.V = formfill.FDFChoices(as)
        case time.Time:
            f.V = formfill.FDFText(as.Format(DefaultFrenchFormatDate))
        case bool:
            if !as {
                continue
            }

            var appearanceKeys []model.ObjName
            if field, ok := originalFields[key]; ok {
                appearanceKeys = field.Field.AppearanceKeys()
            }
            if len(appearanceKeys) == 0 {
                continue
            }
            f.V = formfill.FDFName(appearanceKeys[len(appearanceKeys)-1])
        default:
            return referrors.NewInternal(context.TODO(), "invalid type for value")
        }

        fields = append(fields, formfill.FDFField{
            Values: f,
            T:      key,
        })
    }

    return formfill.FillForm(&f.Templater.Document, formfill.FDFDict{
        Fields: fields,
    }, false)
}

Thank you!

I succeed to check  "INI" checkboxes (INI.1/INI.2/INI.4) so I think it works for me !
I close the issue, you did (again) some great job ! Thank you !


Rewrite xml.etree.cElementTree to xml.etree.ElementTree

Another check for #827

@squiddy good catch with adding in all tests, I found a couple issues in this PR. Everything is fixed now.


npm: update dependencies

https://github.com/GoogleChromeLabs/chromium-bidi/pull/636 fixed the time out issue but there's still an issue with E2E tests when trying to test something that imports the crypto library:

FAILED tests/test_preload_script.py::test_addPreloadScript_loadedInMultipleContexts[True] - Exception: {'error': 'unknown error', 'message': '_e.default.randomUUID is not a function'}

...via % python3 -m pytest tests/test_preload_script.py -k test_addPreloadScript_loadedInMultipleContexts.
I am trying to see if it's related to dependencies, hence updating all of them (esp. rollup).

The issue above was a missing dependencies entry for crypto. It has nothing to do with npm modules. It is now incorporated on https://github.com/GoogleChromeLabs/chromium-bidi/pull/635.
That said, I'll go ahead with this PR anyway. Leaving auto submit enabled.


Fix baseline with NewTools-Tests

This PR tries to fix the CI broken since https://github.com/moosetechnology/Midas/commit/db5ba1e931a4dc03d2c088769fd09760d2eef729

I don't know how one can break the CI by using the PR with security checks. We have to verify that

It is maybe a problem with a cyclic dependency (Moose try to load the last version of Midas that is not this PR)
Do you think we can try a merge @ClotildeToullec?
It fixes the problem on my computer

I think we should merge. This is necessary anyway

Ok, this merge is kinda successful: it fixes the previous problem.
Now we have a new issue: Glamour is being removed from Pharo 9 and old browsers still depend on it. I'll try to fix this.
Good thing we started to remove our Glamour dependencies.
Thanks @badetitou

Yes, my commit broke the CI, sorry...

No pb, it's fixed.
I'm working on fixing the Glamour-Tools dependency, we don't want it.


Rewrite POD parser and Markdown converter

This PR is made mainly in order to address issue #134, but goes beyond that and also addresses a bunch of other things in one go.
In essence, this PR rewrites the entire POD parsing and POD-to-Markdown conversion logic, trying to stay as compliant to the POD specification^1 as possible. Compliance is however broken in certain places in order to not over-complicate things. More on that below.
Furthermore, the conversion of POD inline formatting codes (e.g. B<foobar>) to their respective Markdown equivalents is also improved. The server-side escaping of HTML is removed, as it's generally the client's decision whether to sanitize HTML within markdown or not.
The last commit of this PR also adds a lot of unit tests that have aided me in writing all of this; they're added as a separate commit in case they're undesired. Though, I highly suggest keeping them, as they also test for certain quirks that this implementation allows.
The unit tests are not automatically executed however; they must be run manually in the server/ directory via npm test (requires npm ci to be called first).
For all of the above, it's best to read the commit messages for further details.
Highlights

Sub-sections, lists, etc. are now included when looking up the hover documentation for subroutines and methods.

This means that for a subroutine named foo, all POD content from =head3 foo until the next =head3 (or =head2 or =head1) will be included and converted to Markdown.
Previously, only the ordinary and verbatim paragraphs directly after =head3 foo were included.

Nested lists (=over ... =back) and data regions (=begin ... =end) are now supported and rendered according to their contents.

Headers now correspond to their markdown equivalents.

Subroutine and method lookup is now more precise.

Previews
These previews have been made in Neovim and might look different depending on your editor.
WWW::Mechanize - Before

WWW::Mechanize - After

WWW::Mechanize::new - Before

WWW::Mechanize::new - After

Regarding Spec Conformity
While the new parser is much more spec-compliant than the old one, there are still a couple of cases where conforming to the spec was deemed too complicated or having too little ROI.
The spec^1 for example does not explicitly specify whether =item commands may also exist outside of an =over ... =back region, so the new parser just supports it (as it doesn't really make much of a difference in terms of the implementation's logic).
Furthermore, =over ... =back regions have a couple of different "flavours"^2, each having different requirements. For simplicity's sake, none of these flavours are accounted for; instead, all content inside =over ... =back regions is treated in the same manner (except =head1 etc. commands, these are not allowed and will raise an error).
This means that mixed list types like the following are valid POD:
=pod

=over

=item * Foo

=item 42. Bar

=back

=cut

The above is equivalent to:
=pod

=over 4

=item *

Foo

=item 42.

Bar

=back

=cut

.. and is converted to the following Markdown:
- Foo
42. Bar

Closing Thoughts
Any feedback is highly appreciated! I've tested this implementation via WWW::Mechanize (as you can see above) and also via the provided unit tests; there could always be edge cases I missed though, however, because POD isn't a necessarily... straightforward format.

Oh, one thing I appear to have missed is including =items when looking up a symbol's name -- it seems that some docs out there in the wild group and enumerate their subroutines in =over ... =back lists.
Will see it I can support this gracefully somehow. I guess it's best to just include all content starting from the matched =item until another =item (on the same nesting level) is encountered. Shouldn't be too hard.
Apart from that, let me know what you think! I'm happy to answer any questions, of course.

Looks great, thanks! Working through it now as it's a large commit. Some comments:
I think being more error tolerant would be helpful, especially as POD doesn't always follow the POD standard. Generally, as long as it looks like pod, we should probably show it. Some examples that now break:
File::Basename and File::Compare are core modules that break entirely because they don't end with a =cut. It throws the error: message: '"=pod ... =cut" region beginning at line 400 was never closed (missing "=cut")'
File::Fetch errors with   message: 'unexpected end of paragraphs while processing "=over ... =back" block'. This is because it doesn't have a =back line, only a =cut to end the list.
File::Temp throws an uncaught error on this line:
let contents = matchResult.groups?.contents.trim() || "";
Although this fixes it:
let contents = (matchResult.groups?.contents || "").trim();
I found the above examples by flipping through autocompletion results on use File::, which is also a nice way to quickly spot check a large number of modules.
And as you mentioned, the lookup from item needs to be added back: use File::Copy qw(move), the move doesn't work anymore.
Also, for translating =head\d into markdown, I see that it now does  "#".repeat(headerPara.level). The prior version started at 3 levels down instead which I found was a better use of space. The enormous display of =head1 would waste substantial amounts of vertical space. See the comparison is below. I also previously had it remove the NAME: title as it felt unneccessary,.
Before:

After:

Overall though, this is great. Rearchitecting this is definitely helpful and I appreciate you diving in here. POD parsing is very painful.

Thank you for the feedback!
Regarding fault-tolerance: Interesting, I didn't know POD was interpreted so "liberally" across the ecosystem (but alas, I should've figured, it's Perl after all). I'll definitely address your points and make it more forgiving; as forgiving as possible. Perhaps I'll just make it ignore errors completely, if possible.
Regarding headers: I did not know that VSCode would actually display them so prominently; I agree that it looks way too large! I'll use a level of 3 as the starting level again.
I'll also address the uncaught error, of course.
Besides that, I recently also found two small issues:

Nested lists aren't correctly indented; the last indentation level is always skipped in order to unindent the list in Markdown. Instead, the first indentation level should be skipped.
Multiple headings belonging to the same subroutine aren't rendered correctly, as the symbol lookup function will just consider everything from the first to the succeeding heading, without checking if the heading also belongs to the subroutine.

In other words, if there's =head3 foo(bar => \%baz) followed by =head3 foo(bar => \@baz) (because the author wants to show that keys can have either array refs or hash refs as values), only the content starting from the former up until and excluding the latter header is included. This means that the actual docs are lost when rendered as Markdown.

I'll also correct those.
So in total, the following things need to be addressed:

[ ] Use a level of 3 as starting level for headers (So, a =head1 becomes ### in MD)
[ ] Make the parser more tolerant regarding errors, as the exact spec isn't upheld in the wild

If possible, just ignore errors entirely (kind of done in some places already)

[ ] Fix indentation of nested lists
[ ] Fix consecutive headers belonging to the same subroutine being ignored, leading to the rendered docs missing content
[ ] Fix =item commands not being taken into account when looking up a symbol's name

Note that I'll probably not stay on spec here and only consider =item foo, =item * foo and =item N. foo, because being spec-compliant in this case is a huge hassle -- e.g. =item *\n\nfoo\n\n is painful to handle, because foo is now an ordinary paragraph

[ ] Fix uncaught error (shows up with File::Temp)

If there's anything else you find, let me know! I'll add it to the list above and address it.

Alright, I managed to churn through all this today, which was quicker than I expected.
All new commits address the points I listed above; I tried to be as granular as possible, so reviewing is a little easier.
I did run a quick format over the file and fixed up some minor code formatting things here and there; this did affect a couple existing commits, but the contents of those commits aren't changed otherwise. All new or altered behaviour is added through new commits. Sorry for the noise there! (I blame git absorb).
For good measure I also added a little formatting feature -- see the last commit.
If you notice any other issues, please let me know! I'm always happy to help.

Hmm, on second thought, I might revisit the symbol lookup behaviour regarding =item paragraphs... There do seem to be some packages that document their subroutines like this:

=over

=item *

$object->foo()

[...]

=item *

$object->bar()

[...]

=back

=cut

This is genuinely annoying to handle though, because you can't really parse it all at once; e.g. it might seem logical to just include the next paragraph in the item if there's a plain =item or =item * without any additional text, but that opens a can of worms of additional cases that ought to be handled.
I'll see if I can revisit the data model in that regard to just make handling =items much easier overall, or perhaps I'll cook up some sort of "peekable" or "rewindable" iterator, or something like that.
So overall, I'm not 100% satisfied with the =item handling -- so if you consider this fine to merge, please don't do so yet. I really want to make this proper and implement something that's maintainable.


Something I want to ask.

During inference, I notice that you first resize the picture as input, but the annotations used in counting mAP doesn't change, is it right, or do I miss something?

The annation is tranferred as percent of the image. So the resize operation will not change the gt


Visual/block editor: hitting enter twice does not create a new paragraph

The video tutorial found in the Writers page of the docs notes that hitting enter twice will cause the block to be saved and that a new paragraph will automatically be opened below. In my testing with 2.0.3 in both Firefox and Opera, only the first of those things happens (the block is saved, but a new paragraph is not automatically opened).

I'm a little unsure if the docs are current and this is a bug, or if it is a new feature of 2.0.3. If the latter, and what I'm seeing is expected, is there a keyboard shortcut that can be used to select what the next block should be?
I think opening a new paragraph automatically is probably what most people would want and expect, but it would also be kind of nifty if the content-type selector bar (I'm sure that's not the correct name, but adding a screenshot of the UI I'm referring to below 😄) received the focus and one could select the next content type using arrow keys and hitting space/enter.

Sorry for late answer and thank you for the report. Yes, you are right, I will try to add this behavior again in the next release. New paragraph-block should open if you are at the end of the page.

Great, thanks!

this has been added to version 2.2.2

Thanks!

Ok, I tested it and it looks like this was already fixed in march and has been confirmed that it works. See screencast.
Note, that this only works at the end of the article, it does not work if you insert new blocks somewhere in the middle of the page.
Screencast-editor-hitting-twice.webm


Tronbox init on Mac not working

Running tronbox init after installing and getting
λ › tronbox init
Downloading...
Error: write EPROTO 0021FEDB01000000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:355:

    at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:95:16)
    ```

It seems to be a network problem.


evm: modernize upgrade path

This PR modernizes the upgrade logic in both the EVM TokenRouter and MatchingEngine implementations.

Implementation.sol is what @kcsongor  wrote for NTT, no? Still no code sharing?
Also, from what I can tell, the modernization added a ton of code:
TokenRouter size went from 13.846 to 16.012 bytes
I've done a similar simplification in the swap-layer repo that reduced bytecode size from 13.015 to 12.172 (this is based on a commit from ~mid January - I think this one).
I know that Csongor was trying to dot all i-s and cross all t-s with his implementation, but if these numbers are representative, I think that my much more light-weight implementation is highly preferable. Spending 10 % of the available contract size purely on the upgrade mechanism strikes me as excessive.

@nonergodic This is the implementation that @kcsongor wrote for NTT, with one minor difference (allowing initData in initialize). @djb15 and I chatted about whether we should use your lightweight implementation instead, but ultimately decided against it since the NTT version is well tested and has already been audited twice. Although I'm open to discussing this with a wider group given the decrease is byte code. @djb15 and @a5-pickle thoughts?

From my analysis last week, the NTT proxy base is ~1kB and the slimmed down proxy base is ~0.37kB. Most of the increase in bytecode in this PR comes from checking the immutables since each immutable you want to check needs a public getter.
Out of interest I added the immutable checking logic to the slimmed down ProxyBase today and that increased the bytecode to ~0.52kB. In my opinion the immutable checking is a nice feature that reduces the risk of misconfigurations on an upgrade so I'd like to see that used if possible. Do other folks think it's a waste of space?
I had a look at how we could reduce the bytecode of the NTT proxy base and from some probably poor deduction I think around 0.4kB of the bytecode of the NTT proxy base comes from the OZ Initializable.sol contract. This code is used by so many projects writing upgradeable contracts that I'm hesitant to throw that out the window to optimise for bytecode. So I actually take back what I said in the previous comment about removing dependencies.

(no OZ dependency, only a single external function with a very high selector, ...)

@nonergodic why are both of these important? In my mind having battle-tested OZ code is a positive and having a high selector isn't important for infrequently called methods like contract upgrades?
I think it's pretty awesome how small the slimmed down ProxyBase is, but when we've got 8kB of space left in the bank on the TokenRouter I'm struggling to see why we'd want to optimise for bytecode by switching to an un-audited proxy base?
Happy to change my mind here, just erring on the side of caution.

Awesome, thank you for looking at the numbers in more detail @djb15!
I personally think the Initializable contract, like a whole bunch of things in OZ, is an abomination. I think it introduces way too much complexity and people's eyes glaze over when they are forced to look at it, and so they generally don't. This gives rise to a cargo-cult style of programming where you do things the way everyone else does them without having much of a grasp on the rationale, giving rise to e.g. double "Upgraded" events like snuck into the code here (see one of the latest commits) along with the reason why this PR exists in the first place.
I do understand that in a security critical field there's a much higher utility to being conservative and doing things in a proven way, even if it seems antiquated or suboptimal. Being afraid of unknown unknowns is very much legitimate and reasonable people can disagree on what constitutes being properly conservative vs. being paranoid bordering on superstition. I guess I personally don't like the "Nobody has ever been fired for using OZ." mentality and would prefer to lean more on simplicity and my own understanding.
Besides the meta/temperamental/philosophical considerations, my main concern regarding size is not about the liquidity layer itself at all (as you rightfully point out, there's more than enough space left, so why not use it?). Rather it's about the swap layer and setting precedents more generally.
The swap layer currently stands at 18 kb (down from 22 after ripping out the timelocks etc. as we discussed a few months back) and is not yet feature complete. I've already been rather meticulously optimizing contract size but I expect I'll get pretty close to max size before everything is said and done, hence I can't really afford taking on excess weight like this (especially if I want to leave some breathing room to add another AMM or two later on), which raises the question: If our default proxy implementation is heavier than it needs to be, what do we do in cases where the trade-off is relevant (like the swap layer)?
I think this is my main complaint about OZ in general: It's just unnecessarily heavy and complex and thus reduces both the readability and the amount of usable space with every additional feature/base class you introduce. As a C++ dinosaur who loves the zero overhead principle (you only pay for what you use), I recoil from this sort of thing in horror. If we "seed" our own solidity sdk (because this is really where this stuff should live) with a similar approach, we'll either start heading down the same path, or we continue on our old ways where everyone uses whatever the hell they feel like and we keep reinventing the wheel over and over with minor differences... ("ProxyBase is used by the swap layer but Implementation is used by NTT and a slightly modified form by liquidity layer. Of course the legacy contracts use something else altogether...")
Final point in this long rant:

having a high selector isn't important for infrequently called methods like contract upgrades

That's precisely the point (see my dispergtation on slack from last November)! Infrequently called functions should have high selectors because they are called infrequently. Every selector that is low but not called frequently introduces an overhead 22 gas each!
Implementation introduces 3 external functions:
439fab91 - initialize(bytes)
689f90c3 - getMigratesImmutables()
8fd3ab80 - migrate()
so in expectation, the average function call will become about 39 gas more expensive when this base class is used (only 26 % of functions will not incur any extra cost, 40-26=14 % will incur 22 gas extra, 56-40=16 % will incur 44 gas, and the remaining 44 % will incur an additional cost of 66 gas).
For the curios, this is the complete external interface of the liquidity layer sorted by selector:
016ca178 cancelOwnershipTransferRequest()
038c0b66 confirmOwnershipTransferRequest()
05d20528 getInitialAuctionFee()
070043bf getOwnerAssistant()
07ff8a2e getRouter(uint16)
0a14f7c1 matchingEngineChain()
0fef8c5f updateFastTransferParameters((bool,uint64,uint64,uint64))
15e812ad getBaseFee()
1c6336d4 matchingEngineDomain()
256e4b42 getRouterEndpoint(uint16)
2a2d7e21 placeFastMarketOrder(uint64,uint16,bytes32,bytes,uint64,uint32)
3ce9f518 redeemFill((bytes,bytes,bytes))
439fab91 initialize(bytes)
5005c175 matchingEngineAddress()
52139372 placeFastMarketOrder(uint64,uint64,uint16,bytes32,bytes,address,uint64,uint32)
58de7fb4 getDomain(uint16)
5cf34bcf getMinFee()
6380b620 updateOwnerAssistant(address)
6606cbf1 getFastTransferParameters()
689f90c3 getMigratesImmutables()
69a85fcc addRouterEndpoint(uint16,(bytes32,bytes32),uint32)
6f621428 getMintRecipient(uint16)
722a21d4 updateRouterEndpoint(uint16,(bytes32,bytes32),uint32)
72630531 getDeployer()
84acd1bb wormhole()
85d18917 orderToken()
893d20e8 getOwner()
89485ac6 matchingEngineMintRecipient()
8d976a76 disableRouterEndpoint(uint16)
8fd3ab80 migrate()
93596c7b getPendingOwner()
a020df85 submitOwnershipTransferRequest(address)
afff4c13 getMaxFastTransferAmount()
b187bd26 isPaused()
b77b58d3 getMinFastTransferAmount()
bda392b2 setCctpAllowance(uint256)
bedb86fb setPause(bool)
c0054ae5 placeMarketOrder(uint64,uint64,uint16,bytes32,bytes,address)
d1bbb5a6 placeMarketOrder(uint64,uint16,bytes32,bytes)
d32e91ad enableFastTransfers(bool)
d8d5470d fastTransfersEnabled()
eb2c0223 upgradeContract(address)

i.e. for the unfortunately placed placeMarketOrder functions, the gas overhead on every call is 814 and 836 gas respectively.
For comparison, this is the totality of all public functions on the swap layer (saving both size and gas).
I'll leave it up to everyone else to judge whether this is "supreme autistic pedantry" or "the eye for detail that makes the difference in whether something becomes a great product or another mediocre, inefficient quagmire".

Nice, thanks for the detailed reply!! Will have a think about this some more tomorrow.
Ah by "high selector" I was thinking "high up on the list" which is why I was confused...but this makes more sense now!
What's your opinion on the immutable checking during upgrades btw?

I don't think it should be done on-chain, rather they should be fetched and checked in e.g. an upgrade script if you want to ensure that you are using the same values as you are upgrading the various peer contracts on the various chains. What if a contract upgrade is supposed to remove or change one of the immutables? Right now, since the old implementation dictates what immutables must exist on the new contract and that they must equal their current values, this sort of change is now not possible in a single upgrade (unless you introduce a bunch of garbage code that's purely there to safisfy this requirement).
Another point on OZ intializable makes everyone's eyes glaze over: we now have migrate() and reinitalize both serving the same purpose, no? And has anyone ever even seen a contract upgrade with migration code? In my experience this is all optimizing for stuff that's exceedingly rare, just like protecting against problems that can only arise if the contract contains a self-destruct opcode in the first place.
As another more philosophical/ranty point, I have high trust in myself and I don't like it when things try to dictate what I can or can't do ("Computer says no."). E.g. I carry appendix with one in the chamber and no manual safety and I feel perfectly comfortable doing so. Or put another way, as a C++ dinosaur, I'm used to wielding powerful tools that will blow up when misused (see the old joke: "If you want to shoot yourself in the foot, use C. If you want to take the whole leg off, use C++."). So my creed is "We don't need better guardrails, we need more virtuous devs."
When it comes to contract upgrades, the only thing I really worry about is accidental bricking of the contract (one-way door errors). Deploying with the wrong immutables might cause some amount of pain/damage but can be fixed by just doing another upgrade (two-way door). Ofc, if you use OZ's reinitalizer you'll have to bump the version and suddenly you have a different version number on the chain that had the deployment mishap...
If I had to personify OZ, I'd say it's the sort of guy who read the CIA handbook on how to hobble an otherwise productive organization by demanding that everything is done "by the book" and via committee, making sure that he'll never run out of work while also creating so many bureaucratic routines that nobody will ever be able to replace him and the ever expanding Rube-goldbergesque machinery he's put in place.

Another point for "OZ intializable makes everyone's eyes glaze over": We now have migrate() and reinitialize both serving the same purpose, no?

Just realized that was a mistake on my part. No reinitialize function, only a reinitializer modifier. So nevermind that, my eyes were glazing over.

Though just programmatically increasing the version by 1 (as we are doing) seems like a "I'm doing this because I have to" sort of move. I don't see it serving any actual purpose. I originally hallucinated a reinitialize function that takes a version number and ensures that you execute upgrades correctly in case you skip versions, but now I realize it's even sillier than that

This is spot on, working with the OZ Initializable logic was definitely an uphill battle.

And has anyone ever even seen a contract upgrade with migration code? In my experience this is all optimizing for stuff that's exceedingly rare, just like protecting against problems that can only arise if the contract contains a self-destruct opcode in the first place.

I have seen (and written) many of those. It's always scary, and because it's relatively rare (to the point where two consecutive upgrades might be implemented/deployed by entirely different sets of people, with fresh opportunities to make mistakes), guardrails are important IMO.

"We don't need better guardrails, we need more virtuous devs."

We don't need airbags, we need more careful drivers. Imagine the fuel savings with all that excess weight removed!

FWIW I think it should be possible to cut out a lot of OZ crap without compromising on the desired guarantees of the upgrade logic (since OZ doesn't really buy us that much)

I've had a play with this again and it's not a trivial change to just cut out OZ stuff without rewriting portions of the implementation. Just copy/pasting the bits we need out of the OZ contracts has a trivial impact on the total bytecode size (~0.1kB). Not saying it's not doable, but it's not a freebie like I was hoping.
Also another data point on the immutable checking...the 5 immutable checks in the TokenRouter add 0.75kB to the bytecode so it's not a cheap guardrail by any means. But If we have the bytecode available I do still think it's a nice safety check given upgrades are probably the most risky operation that an admin ever needs to do.
I think we all agree OZ isn't exactly lightweight (that's putting it lightly) so there is absolutely a better variant that exists of what we have here. Priority for this codebase right now is security imo so I'm going to review this as is since we get the extra security checks.
If it can be prioritised we should definitely continue this discussion elsewhere though. We should agree on a proxy base variant that we can use everywhere that makes tradeoffs that the majority are comfortable with. This one definitely isn't perfect by any means but I do like it.

We don't need airbags, we need more careful drivers. Imagine the fuel savings with all that excess weight removed!

Absolutely, though the excesss weight comes from all the careless self-selecting themselves off the street (the driving analogy is ofc a lot less compelling).
As the saying goes "I tried to make it idiot-proof but they keep making better idiots!"
Or alternatively: "It's time to take the warning labels off and let the problem of pervasive stupidity solve itself!"
But snark aside, the weight is important and also helpful because it's an objective factor, but my main point remains one about safety through simplicity, readability, and ease of use. If something is simple, elegant, and easy to use, you'll be happy to look at it and understand it.  As the author of your code you should make it compelling for the reader, not repelling.

I added #95 so that the discussion can take place there. If this conversation does continue, please move it there.
The purpose of this PR was to update the existing upgrade logic taken from older EVM examples to something that a more recent example (NTT) has used.


Fix Any to AnyObject cast for linux environment

The issue: On non-darwin platofrms Any is not castable to AnyObject, while on darwin platform conditional cast of Any to AnyObject produces warning.

Thank you for catching the problem for Linux👍 I also saw newValue as AnyObject? generates the error on Linux, and newValue.flatMap { $0 as? AnyObject } generates the warning on Mac. It is inconsistency of Swift lang implementation between Linux and Mac.

AFAIK Any is castable to AnyObject only because of objC interoperability, so it makes sense that it does not work on non-darwin systems. From what I gather it is recommended not to use such features in multi-platform code, but here it cannot be avoided.


perf: shard directories when they get too big

Transform directories into hamt-sharded directories when the number of DAGLinks reaches a certain point, otherwise reading them from the block store becomes too expensive.
License: MIT
Signed-off-by: achingbrain<EMAIL_ADDRESS>

Has basically involved rewriting most of MFS to remove the custom node traversal stuff and use the unixfs importer/exporters instead.