Add del btn to workspace overview

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/35855
PROPOSAL: https://github.com/Expensify/App/issues/35855#issuecomment-1934944721
Tests

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Login as user A and add workspace.
Go to workspace profile page and verify the 'Delete' button shows for workspace owner.
Logged in as user A, invite user B to workspace.
Log in as user B and go to invited workspace profile page and verify the 'Delete' button does not show for user B.
From Account Preferences, set language to Spanish. Verify the Spanish text for the delete button.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@aimane-chnaif PR is ready for review. The share button does not have any icon so I have removed the icon from the delete button.

@aimane-chnaif I am ready to put screenshots without the icons.


Update vs-key-vault-add-connected-service.md

@dasanagu : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Of course, thanks!

#sign-off


WP 8 (Silverlight) doesn't work

Last working version for Windows Phone 8.0 (Silverlight) was 2.2.3. Versions 4.1.1 and above don't send crashes.

@Syn-McJ Please check @MatkovIvan comment on the #122 above. I'm closing this issue for now.


Issue #31 test expansion

Added test to ensure that a step may not be executed twice on restart of a job
The changes are clean, just spread out over 3 commits. for just one, use PR #56

This request has been improved by #59


snapshot release to camunda-bpm-community-extensions-snapshots

currently, I see only 1.5.0-SNAPSHOT, not 2.0.0 ...
why?

Please check again. There was an issue on the old machine which used an old incompatible maven version.

thanks!

I think this issue has come back. Adding the dependency to 2.0.0-SNAPSHOT results in a missing artifact error... am I missing something?


Question: Is it possible to have Validator and keep field optional?

I have a field that should contain only numbers, I use Validators.number for that, but the whole form is not valid if I don't input that field with number validator. So is it possible to have that validator and keep number field optional?

Hi @leonidlist,
Thanks for using Reactive Forms and for the issue. You are right, the Validators.number validates that the control is not null and complies with a sequence of digits.
A solution is to create a composition of validators (i.e: control can be null or number):
final control = FormControl<String>(
    validators: [
        Validators.composeOR([
            Validators.composeOR([Validators.equals(''), Validators.equals(null)]),
            Validators.number,
        ]),
    ],
);

Let me know if this solution solves your issue.

Thanks to you for your kind words @leonidlist, Have a nice day.

final control = FormControl<String>(
    validators: [
        Validators.composeOR([
            Validators.composeOR([Validators.equals(''), Validators.equals(null)]),
            Validators.number,
        ]),
    ],
);

@joanpablo But this only works when i use FormControl<String>. If I want to use FormControl<double> it failed to work. Do you have any idea?


Update the package on conda-forge

🚀 Feature
Update the version of PL on conda-forge to the recent tagged release. Conda-forge has 0.9.0
Motivation
Keep the package up to date on important channels. Conda-forge is the default channel so it qualifies.
Pitch
When making a new environment and conda install-ing PL, you want the most recently tagged version.
Alternatives
Not keep conda-forge up to date and requiring users to clone this repo to get the most recently tagged version.

on its way :] https://github.com/conda-forge/pytorch-lightning-feedstock/pull/11

This is done.

Thanks!


Lack of error handling

Proposed Method: Error handling statements
Description
I have identified a potential vulnerability:
Lack of Error Handling: The code uses a try-except block to catch exceptions during the scraping process. However, the except block does not specify the specific exception being caught. This can make it difficult to handle specific errors and troubleshoot issues. It is generally recommended to catch specific exceptions or at least the base Exception class to provide more accurate error handling.
To what class it belongs?: Instgram module in scrape_up folder

Sounds good @okaditya84, go ahead :))


Error: AttributeError: 'dict' object has no attribute 'answer'

I installed the ari-py from source with sudo ./setup.py install on a raspberry pi 2.
I use example.py and just added logging in order to see the error:
import logging
logging.basicConfig()

The client registers with asterisk and then receives an event. But then i get the error message:
ERROR:ari.client:Event listener threw exception
Traceback (most recent call last):
  File "build/bdist.linux-armv7l/egg/ari/client.py", line 100, in __run
    callback(msg_json, *args, **kwargs)
  File "build/bdist.linux-armv7l/egg/ari/client.py", line 198, in extract_objects
    event_cb(obj, event, *args, **kwargs)
  File "<stdin>", line 2, in on_start
AttributeError: 'dict' object has no attribute 'answer'

Same result with release 0.1.3
when I print the channel type and object i get:
{u'channel': Channel(1445097806.30)}
{u'timestamp': u'2015-10-17T18:03:26.842+0200', u'args': [], u'type': u'StasisStart', u'channel': {u'accountcode': u'', u'name': u'SIP/softphone-0000000f', u'language': u'en', u'caller': {u'name': u'softphone', u'number': u'+41790000003'}, u'creationtime': u'2015-10-17T18:03:26.837+0200', u'state': u'Ring', u'connected': {u'name': u'', u'number': u''}, u'dialplan': {u'priority': 3, u'exten': u'100', u'context': u'incoming'}, u'id': u'1445097806.30'}, u'application': u'hello'}

Thanks

The following example works: https://github.com/asterisk/ari-examples/blob/master/channel-playback-monkeys/example.py
there you also unwrap the channel before using:
    channel = channel_obj.get('channel')

maybe you have to update your examples in this repo?


Fix: "hit" event now sends UTM tags

Fixes #16

Thanks! Published as 2.5.0

Thanks! Published as 2.5.0

@viatsko I know it's been a while, but it doesn't seem to be published as 2.5.0
https://www.npmjs.com/package/gatsby-plugin-yandex-metrika/v/2.5.0?activeTab=code
created #28


Version detection on Libigot fails

Apparently Libigot gives an "unknown version" API version string, which the Gringotts API detection interprets as pre-1.3 version. Create a workaround.

Libigot seems dead, so closing this.


Send CORs headers for browser applications

It would really simplify things for users of applications served through the browser that need to print documents if some sort of CORs configuration could be enabled via CUPs.
If you aren't familiar with CORs - this is solved simply by adding a few HTTP headers.  Ideally, headers are only allowed for a set of trusted domains which can be enabled in some fashion by the user (i.e. the user needs to allow prints from "fancyprintjobs.example.com").  This page does a better job describing it than I could do here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
If it is helpful, I can go into more detail about the specific header key/values required to facilitate communication between the application running inside the browser and CUPs.  However, know it is simply adding a couple of http headers to the response based on the domain requests are made from.
The browser respects a CORs policy when allowing http requests from an application (i.e. javascript code) to endpoints served from a different domain than the application.  When CORs is enabled, javascript applications are able to print directly to CUPs.  Without CORs, browsers disallow the ability to submit IPP jobs to CUPs from an application running in the browser context.
Currently, users have two options - they can manually print each document by downloading it via the browser and using a local program to print.  This is slow and requires the user to set the print settings for each type of job.  Since the remote application already knows how it should be printed (and can set these settings automatically via IPP, it is frustrating for - and confusing to many - users to configure the printer correctly for different types of documents.
The better option is to allow the application to print directly via IPP.  However, CORs restrictions make this difficult since they are not considered by CUPs.
Since CUPs does not allow CORs configuration, the user must do one of the following at present:

(easiest approach from a user perspective) place the printer on the public internet.  This allows the server component of the browser application to submit print jobs. Hopefully the user exposes their printer securely - however - considering most people cannot configure a router, it is unlikely that the average person working from home is sharing their printer over the internet securely. This seems worse than exposing CORs to the LAN.  There is a little more to this as most users have dynamic ip addresses, but that is ignored for the sake of discussion.
place a reverse proxy in front of CUPs and apply CORs headers there.  This method allows the Javascript application running in the browser to print via their local network without exposing the printer over the public internet.

Of the two choices - CORs is safer and simpler for the end user. However there is a large barrier to entry here due to the configuration of a reverse proxy - this really isn't feasible for the average user who just expects printing to work.
Since there are ways to side step the issue - people are doing it.  However, since the steps are complicated, it isn't being done well and users are unknowingly creating risk.
Please consider adding CORs support to CUPs in any fashion.  It would be very useful to the end users.

Current Fetch Specification from the W3C
Adding support for CORS will require some libcups changes as well as cupsd changes. Basic list:

[ ] Add Access-Control-xxx and Origin headers to HTTP field enumeration and header list
[ ] Add cups-files.conf (not cupsd.conf for security reasons) directives to enable remote JavaScript access
[ ] Document changes and how to use/configure
[ ] Add test file with simple IPP request to test suite

I've added the HTTP headers to CUPS 2.4 to enable some experimentation for this and some related security things:
[master bccf2f995] Add support for CORS/HSTS/OSCORE/Interative Client security headers (Issue #266)
Implementation of the rest of this will have to wait for a later CUPS feature release...


hamming - two confusing test remove

fix #61

The tests.toml file should be updated to show these tests are no longer included.

Never mind, I already marked the tests not included in the toml.


Fix automatic baseline profile gen

Codecov Report

Merging #587 (0517042) into main (07ff522) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #587   +/-   ##
=======================================
  Coverage   70.67%   70.67%
=======================================
  Files         109      109
  Lines        5460     5460
  Branches     1084     1084
=======================================
  Hits         3859     3859
  Misses        862      862
  Partials      739      739

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


comments before a directive

Describe the bug
comments before a directive are not reflected on the AST.
To Reproduce
String to test '# a comment\n%TAG !yaml! tag:yaml.org,2002:\n---test: test'

The comment is not lost, it's misplaced. Which is a bug:
const src = '# a comment\n%TAG !yaml! tag:yaml.org,2002:\n---test: test'
const doc = YAML.parseDocument(src)
doc.contents.items[0].key.commentBefore === ' a comment'

Actually, the real bug here was that the original input is not marked as an error, due to a missing directives-end/doc-start marker. If you add a newline after the --- the comment is correctly positioned:
const src = '# a comment\n%TAG !yaml! tag:yaml.org,2002:\n---\ntest: test'
const doc = YAML.parseDocument(src)
doc.commentBefore === ' a comment'

Without a directive or a document marker, a comment needs an empty line after it to be considered a comment on the document, rather than the first content node:
const src = '# a comment\n\ntest: test'
const doc = YAML.parseDocument(src)
doc.commentBefore === ' a comment'

What if we only have comment # a comment? Even when I add the new lines I do not get a document in that case.

Could you post the exact calls that are giving you output different from your expectations?

Here is a test case .


unable to parse valid Bibtex

@Article{pmid31201394,
Author="Raza, S.  and Bangash, A. A.  and Ahmad, T. I.  and Khan, M. S. ",
Title="{{P}ulmonary health risks of working at a cement plant in {K}hyber {P}akhtunkhwa province of {P}akistan}",
Journal="J Pak Med Assoc",
Year="2019",
Volume="69",
Number="6",
Pages="869--873",
Month="Jun",
Abstract={To examine the risk and preventive factors of working in a cement plant.\ The cross-sectional study was conducted from July to September, 2016, at a leading cement manufacturing plant in the Khyber Pakhtunkhwa province of Pakistan. An interviewer-administered questionnaire was used to collect data about the characteristics of exposed and unexposed subjects. The characteristics and occupational illnesses were compared between exposed and unexposed workers. Logistic regression was applied to estimate the odds ratio for risk and preventive factors associated with pulmonary illnesses linked with the profession.\ Of the 550 workers contacted, 260(47.3%) agreed to participate. The mean age of the sample was 30.48}6.13 years. Of the total, 80(31%) were exposed and 180(69%) were unexposed. Overall, 96(37%) workers had medical coverage facility, while 114(63%) reported very good health. All socioeconomic and working characteristics were highly significant between exposed and unexposed workers (p<0.05). There were 67(25.7%) workers with pulmonary illnesses and the difference between the exposed and unexposed groups were significant (p<0.05).\ Pulmonary health among workers could be improved by implementing occupational health improving strategies..},
Note={[PubMed:\href{https://www.ncbi.nlm.nih.gov/pubmed/31201394}{31201394}] }
}
Throws error when tries to parse "30.48" expects command and right braces

Please see the pull request.

Please see the pull request with the issues fixed

Abstract={To examine the risk and preventive factors of working in a cement plant.\ The cross-sectional study was conducted from July to September, 2016, at a leading cement manufacturing plant in the Khyber Pakhtunkhwa province of Pakistan. An interviewer-administered questionnaire was used to collect data about the characteristics of exposed and unexposed subjects. The characteristics and occupational illnesses were compared between exposed and unexposed workers. Logistic regression was applied to estimate the odds ratio for risk and preventive factors associated with pulmonary illnesses linked with the profession.\ Of the 550 workers contacted, 260(47.3%) agreed to participate. The mean age of the sample was 30.48}6.13 years. Of the total, 80(31%) were exposed and 180(69%) were unexposed. Overall, 96(37%) workers had medical coverage facility, while 114(63%) reported very good health. All socioeconomic and working characteristics were highly significant between exposed and unexposed workers (p<0.05). There were 67(25.7%) workers with pulmonary illnesses and the difference between the exposed and unexposed groups were significant (p<0.05).\ Pulmonary health among workers could be improved by implementing occupational health improving strategies..}

There are one { and two } which cause the braces cannot be closed.


Support for ARM64

The sse flags are not supported by ARM64 (this was a potential issue also for new macs, but I don't have a way to test it). I suggest disabling them.
This should improve the situation (or even fix) https://github.com/owlbarn/owl/issues/569 and should fix (at least for now) https://github.com/owlbarn/owl/issues/568
I also added ARM to the tests, to double-check...

How much does -sse impact the performance? Did @jzstark evaluate this before?
Can this switch be conditioned on the arch?

How much does -sse impact the performance? Did @jzstark evaluate this before?
Can this switch be conditioned on the arch?

How much does -sse impact the performance? Did @jzstark evaluate this before?
No idea, that is why I also added him as reviewer. In any case I think this is not supported on ARM-based macs, so I think we will need to find a solution.
We don't use sse on eigen or AEON either by the way, so that may need to be revisited and adjusted as well.

Can this switch be conditioned on the arch?
I think it must be possible, but I don't know how to check the ARCH. Unfortunately I don't have the time to study that right now.
If this PR works, anybody can pick it up and add the feature before merging.

How much does -sse impact the performance? Did @jzstark evaluate this before?
No idea, that is why I also added him as reviewer. In any case I think this is not supported on ARM-based macs, so I think we will need to find a solution.
We don't use sse on eigen or AEON either by the way, so that may need to be revisited and adjusted as well.

Can this switch be conditioned on the arch?
I think it must be possible, but I don't know how to check the ARCH. Unfortunately I don't have the time to study that right now.
If this PR works, anybody can pick it up and add the feature before merging.

Looking at gcc documentation it seems to me that this should make a difference only on i386 and maybe old compilers, all of -mfpmath=sse -msse -msse2 should be enabled by default on x86_64

Looking at gcc documentation it seems to me that this should make a difference only on i386 and maybe old compilers, all of -mfpmath=sse -msse -msse2 should be enabled by default on x86_64

I have not done evaluation about the sse flag, but I think this StackOverflow post shows that it does have an impact on the code performance in general. Personally I'm in no hurry to remove this flag before we can make sure that removing this flag definitely have no impact on the performance of Owl. As Marcello pointed out, making clear how this flag is used by default and how it interacts with other flags on various platforms should be helpful.
We have some code to detecting the cpu architecture at C code level, but I think we need something at the OCaml level here. I don't know about that, but perhaps some similar method as we use in configure.ml to detect different OS could potentially be utilised.

I have not done evaluation about the sse flag, but I think this StackOverflow post shows that it does have an impact on the code performance in general. Personally I'm in no hurry to remove this flag before we can make sure that removing this flag definitely have no impact on the performance of Owl. As Marcello pointed out, making clear how this flag is used by default and how it interacts with other flags on various platforms should be helpful.
We have some code to detecting the cpu architecture at C code level, but I think we need something at the OCaml level here. I don't know about that, but perhaps some similar method as we use in configure.ml to detect different OS could potentially be utilised.

The post you link confirms what I was saying though: “ -msse -msse2 -mfpmath=sse is already the default for x86-64, but not for 32-bit i386”. Owl has tests failing on i386. I think we should aim to add arm64 and maybe add a remark on i386

The post you link confirms what I was saying though: “ -msse -msse2 -mfpmath=sse is already the default for x86-64, but not for 32-bit i386”. Owl has tests failing on i386. I think we should aim to add arm64 and maybe add a remark on i386

This is how we can add arch specificatie flats in configurator: https://github.com/mirage/mirage-crypto/blob/master/config/cfg.ml#L5-L16

This is how we can add arch specificatie flats in configurator: https://github.com/mirage/mirage-crypto/blob/master/config/cfg.ml#L5-L16

I know it is not a proper benchmark but I did run all the owl examples and simulations that I have running around with and without this code (all 64 bits machines, ubuntu and macos), and there is no apparent difference in the running time (measured with time), confirming what the documentation says (i.e., these flags should be redundant in 64bit systems).

Greetings. I am building owl for the M1 chip on macOS. I have effectively applied this patch as I was starting the basic port. It stops when we get to an assembly call for cpuid, which ARM64 lacks.
The caller is trying to determine the cache size available.
⌁ [jhg:~/Work/owl] mseri-patch-1 ± make
dune external-lib-deps --missing @install @runtest
dune build @install
          cc src/owl/owl_ndarray_contract_stub.o
In file included from src/owl/core/owl_ndarray_contract_stub.c:17:
src/owl/core/owl_ndarray_contract_impl.h:88:9: warning: incompatible pointer types assigning to 'int64_t *' (aka 'long long *') from 'intnat []' [-Wincompatible-pointer-types]
  cp->n = X->dim;
        ^ ~~~~~~
In file included from src/owl/core/owl_ndarray_contract_stub.c:26:
src/owl/core/owl_ndarray_contract_impl.h:88:9: warning: incompatible pointer types assigning to 'int64_t *' (aka 'long long *') from 'intnat []' [-Wincompatible-pointer-types]
  cp->n = X->dim;
        ^ ~~~~~~
In file included from src/owl/core/owl_ndarray_contract_stub.c:35:
src/owl/core/owl_ndarray_contract_impl.h:88:9: warning: incompatible pointer types assigning to 'int64_t *' (aka 'long long *') from 'intnat []' [-Wincompatible-pointer-types]
  cp->n = X->dim;
        ^ ~~~~~~
In file included from src/owl/core/owl_ndarray_contract_stub.c:44:
src/owl/core/owl_ndarray_contract_impl.h:88:9: warning: incompatible pointer types assigning to 'int64_t *' (aka 'long long *') from 'intnat []' [-Wincompatible-pointer-types]
  cp->n = X->dim;
        ^ ~~~~~~
4 warnings generated.
          cc src/owl/owl_core_utils.o (exit 1)
(cd _build/default/src/owl && /usr/bin/cc -O2 -fno-strict-aliasing -fwrapv -pthread -D_FILE_OFFSET_BITS=64 -O2 -fno-strict-aliasing -fwrapv -pthread -I/opt/homebrew/Cellar/openblas/0.3.19/include -g -O3 -Ofast -mcpu=apple-m1 -funroll-loops -ffast-math -DSFMT_MEXP=19937 -fno-strict-aliasing -Wno-tautological-constant-out-of-range-compare -Wno-logical-op-parentheses -g -I /Users/jhg/.opam/default/lib/ocaml -I /Users/jhg/.opam/default/lib/bigarray-compat -I /Users/jhg/.opam/default/lib/bytes -I /Users/jhg/.opam/default/lib/camlzip -I /Users/jhg/.opam/default/lib/ctypes -I /Users/jhg/.opam/default/lib/eigen -I /Users/jhg/.opam/default/lib/eigen/cpp -I /Users/jhg/.opam/default/lib/integers -I /Users/jhg/.opam/default/lib/npy -I /Users/jhg/.opam/default/lib/zip -I ../base -o owl_core_utils.o -c owl_core_utils.c)
src/owl/core/owl_core_utils.c:218:5: error: invalid output constraint '=a' in asm
    CPUID(cpuinfo, 0x4, cache_id);
    ^
src/owl/core/owl_macros.h:97:36: note: expanded from macro 'CPUID'
    __asm__ __volatile__ ("cpuid": "=a" (cpuinfo[0]), "=b" (cpuinfo[1]), "=c" (cpuinfo[2]), "=d" (cpuinfo[3]) : "0" (func), "2" (id) );
                                   ^
src/owl/core/owl_core_utils.c:252:3: error: invalid output constraint '=a' in asm
  CPUID(cpuinfo, 0x80000005, 0);
  ^
src/owl/core/owl_macros.h:97:36: note: expanded from macro 'CPUID'
    __asm__ __volatile__ ("cpuid": "=a" (cpuinfo[0]), "=b" (cpuinfo[1]), "=c" (cpuinfo[2]), "=d" (cpuinfo[3]) : "0" (func), "2" (id) );
                                   ^
src/owl/core/owl_core_utils.c:255:3: error: invalid output constraint '=a' in asm
  CPUID(cpuinfo, 0x80000006, 0);
  ^
src/owl/core/owl_macros.h:97:36: note: expanded from macro 'CPUID'
    __asm__ __volatile__ ("cpuid": "=a" (cpuinfo[0]), "=b" (cpuinfo[1]), "=c" (cpuinfo[2]), "=d" (cpuinfo[3]) : "0" (func), "2" (id) );
                                   ^
src/owl/core/owl_core_utils.c:277:5: error: invalid output constraint '=a' in asm
    CPUID(cpuinfo, 0x0, 0);
    ^
src/owl/core/owl_macros.h:97:36: note: expanded from macro 'CPUID'
    __asm__ __volatile__ ("cpuid": "=a" (cpuinfo[0]), "=b" (cpuinfo[1]), "=c" (cpuinfo[2]), "=d" (cpuinfo[3]) : "0" (func), "2" (id) );
                                   ^
4 errors generated.
File "src/base/dense/owl_base_dense_ndarray_generic.ml", line 432, characters 20-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/base/dense/owl_base_dense_ndarray_generic.ml", line 432, characters 17-18:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/base/dense/owl_base_dense_ndarray_generic.ml", line 483, characters 17-18:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/base/dense/owl_base_dense_ndarray_generic.ml", line 483, characters 14-15:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/base/dense/owl_base_dense_ndarray_generic.ml", line 509, characters 17-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/base/dense/owl_base_dense_ndarray_generic.ml", line 535, characters 19-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/base/dense/owl_base_dense_ndarray_generic.ml", line 535, characters 15-17:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 53, characters 58-62:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 53, characters 51-56:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 53, characters 40-48:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 53, characters 28-36:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 53, characters 11-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 75, characters 58-62:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 75, characters 51-56:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 75, characters 40-48:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 75, characters 28-36:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 75, characters 11-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 100, characters 53-57:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 100, characters 46-51:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 100, characters 29-43:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 100, characters 11-25:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 139, characters 59-63:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 139, characters 52-57:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 139, characters 32-49:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 139, characters 11-28:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 173, characters 55-59:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 173, characters 48-53:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 173, characters 32-45:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 173, characters 11-28:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 203, characters 56-60:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 203, characters 49-54:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 203, characters 33-46:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 203, characters 12-29:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 247, characters 5-10:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 246, characters 6-18:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 245, characters 6-20:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 244, characters 6-23:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 243, characters 6-23:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 281, characters 5-10:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 280, characters 6-18:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 279, characters 6-20:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 278, characters 6-23:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 277, characters 6-23:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 310, characters 59-63:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 310, characters 52-57:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 310, characters 32-49:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 310, characters 11-28:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 341, characters 55-59:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 341, characters 48-53:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 341, characters 32-45:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 341, characters 11-28:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 371, characters 56-60:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 371, characters 49-54:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 371, characters 33-46:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/cblas/owl_cblas.ml", line 371, characters 12-29:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/dense/owl_dense_matrix_generic.ml", line 1369, characters 9-10:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/dense/owl_dense_ndarray_generic.ml", line 1360, characters 17-18:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/dense/owl_dense_ndarray_generic.ml", line 1360, characters 14-15:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/dense/owl_dense_ndarray_generic.ml", line 1391, characters 19-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/dense/owl_dense_ndarray_generic.ml", line 1391, characters 15-17:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/dense/owl_dense_ndarray_generic.ml", line 1445, characters 17-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/dense/owl_dense_ndarray_generic.ml", line 1484, characters 20-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/dense/owl_dense_ndarray_generic.ml", line 1484, characters 17-18:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 154, characters 7-16:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 390, characters 6-10:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 1162, characters 7-17:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 1230, characters 21-32:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 1230, characters 7-17:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 1380, characters 35-45:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 1380, characters 21-31:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 1380, characters 7-17:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 2111, characters 6-7:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 2143, characters 6-7:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 2173, characters 6-7:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 2205, characters 6-7:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 2235, characters 6-7:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 2265, characters 6-7:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/lapacke/owl_lapacke.ml", line 2686, characters 6-10:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.
File "src/owl/working/owl_parallel.ml", line 280, characters 18-49:
Error (warning 5 [ignored-partial-application]): this function application is partial,
maybe some arguments are missing.
make: *** [build] Error 1

@jhgorse  Thanks for reporting this problem. When thus cache size function was introduced, it was mainly for the optimization of convolution operations. I vaguely recall that if non-compatible architectures are used, it is supposed returns some default values, but apparently M1 was not covered.  Unfortunately currently I lack hardware and time to revise the code base and add extra architectures on the whitelist. If you could propose a solution and make a PR, it would be really appreciated!

Okay, I got past that. The compiler doesn't like the potential to need that object code so it dies. The preprocessor needs to filter out that intel or amd code for cpuid.
Now we fail on link with:
⌁ ⌂6.43 [jhg:~/Work/owl] mseri-patch-1(+0/-82) 12.s 2 ± make
dune external-lib-deps --missing @install @runtest
dune build @install
  ocamlmklib src/owl/dllowl_stubs.so,src/owl/libowl_stubs.a (exit 2)
(cd _build/default && /Users/jhg/.opam/default/bin/ocamlmklib.opt -g -o src/owl/owl_stubs src/owl/SFMT.o src/owl/airy.o src/owl/airyf.o src/owl/bdtr.o src/owl/beta.o src/owl/btdtr.o src/owl/cbrt.o src/owl/chbevl.o src/owl/chbevlf.o src/owl/chdtr.o src/owl/const.o src/owl/constf.o src/owl/dawsn.o src/owl/dawsnf.o src/owl/ellie.o src/owl/ellik.o src/owl/ellpe.o src/owl/ellpj.o src/owl/ellpk.o src/owl/exp10.o src/owl/exp2.o src/owl/expn.o src/owl/fdtr.o src/owl/fresnl.o src/owl/gamma.o src/owl/gammaf.o src/owl/gdtr.o src/owl/gels.o src/owl/hyp2f1.o src/owl/hyperg.o src/owl/hypergf.o src/owl/i0.o src/owl/i0f.o src/owl/i1.o src/owl/i1f.o src/owl/igam.o src/owl/igami.o src/owl/incbet.o src/owl/incbi.o src/owl/ivf.o src/owl/j0.o src/owl/j0f.o src/owl/j1.o src/owl/j1f.o src/owl/jnf.o src/owl/jv.o src/owl/jvf.o src/owl/k0.o src/owl/k0f.o src/owl/k1.o src/owl/k1f.o src/owl/kn.o src/owl/kolmogorov.o src/owl/lanczos.o src/owl/mtherr.o src/owl/nbdtr.o src/owl/ndtr.o src/owl/ndtri.o src/owl/owl_cblas_generated_stub.o src/owl/owl_core_utils.o src/owl/owl_dcdflib.o src/owl/owl_distribution_common_c.o src/owl/owl_fftpack_float32.o src/owl/owl_fftpack_float64.o src/owl/owl_ipmpar.o src/owl/owl_lapacke_generated_stub.o src/owl/owl_maths_special_gamma.o src/owl/owl_maths_special_impl.o src/owl/owl_maths_special_stub.o src/owl/owl_matrix_check_stub.o src/owl/owl_matrix_swap_stub.o src/owl/owl_ndarray_contract_stub.o src/owl/owl_ndarray_conv_stub.o src/owl/owl_ndarray_fma_stub.o src/owl/owl_ndarray_maths_stub.o src/owl/owl_ndarray_pool_stub.o src/owl/owl_ndarray_repeat_stub.o src/owl/owl_ndarray_slide_stub.o src/owl/owl_ndarray_sort_stub.o src/owl/owl_ndarray_transpose_stub.o src/owl/owl_ndarray_upsampling_stub.o src/owl/owl_ndarray_utils_stub.o src/owl/owl_slicing_basic_stub.o src/owl/owl_slicing_fancy_stub.o src/owl/owl_stats_dist_beta.o src/owl/owl_stats_dist_binomial.o src/owl/owl_stats_dist_cauchy.o src/owl/owl_stats_dist_chi2.o src/owl/owl_stats_dist_dirichlet.o src/owl/owl_stats_dist_exponential.o src/owl/owl_stats_dist_exponpow.o src/owl/owl_stats_dist_f.o src/owl/owl_stats_dist_gamma.o src/owl/owl_stats_dist_gaussian.o src/owl/owl_stats_dist_gennorm.o src/owl/owl_stats_dist_geometric.o src/owl/owl_stats_dist_gumbel1.o src/owl/owl_stats_dist_gumbel2.o src/owl/owl_stats_dist_hypergeometric.o src/owl/owl_stats_dist_laplace.o src/owl/owl_stats_dist_logistic.o src/owl/owl_stats_dist_lognormal.o src/owl/owl_stats_dist_logseries.o src/owl/owl_stats_dist_lomax.o src/owl/owl_stats_dist_multinomial.o src/owl/owl_stats_dist_negative_binomial.o src/owl/owl_stats_dist_noncentral_chi2.o src/owl/owl_stats_dist_noncentral_f.o src/owl/owl_stats_dist_poisson.o src/owl/owl_stats_dist_power.o src/owl/owl_stats_dist_rayleigh.o src/owl/owl_stats_dist_stub.o src/owl/owl_stats_dist_t.o src/owl/owl_stats_dist_triangular.o src/owl/owl_stats_dist_uniform.o src/owl/owl_stats_dist_vonmises.o src/owl/owl_stats_dist_wald.o src/owl/owl_stats_dist_weibull.o src/owl/owl_stats_dist_zipf.o src/owl/owl_stats_extend_misc.o src/owl/owl_stats_extend_shuffle.o src/owl/owl_stats_extend_stub.o src/owl/owl_stats_prng_stub.o src/owl/owl_stats_ziggurat.o src/owl/pdtr.o src/owl/polevlf.o src/owl/psi.o src/owl/rgamma.o src/owl/round.o src/owl/scipy_iv.o src/owl/sf_error.o src/owl/shichi.o src/owl/sici.o src/owl/sincos.o src/owl/sindg.o src/owl/spence.o src/owl/sqrtf.o src/owl/stdtr.o src/owl/struve.o src/owl/struvef.o src/owl/tandg.o src/owl/tukey.o src/owl/unity.o src/owl/yn.o src/owl/ynf.o src/owl/zeta.o src/owl/zetac.o -L/opt/homebrew/Cellar/openblas/0.3.19/lib -lopenblas -lm)
ld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
File "src/base/dense/owl_base_dense_ndarray_generic.ml", line 432, characters 20-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.

rpath/libgcc_s.1.1.dylib not found? That's odd. I thought I was using clang.

@jhgorse Thanks for reporting this problem. When thus cache size function was introduced, it was mainly for the optimization of convolution operations. I vaguely recall that if non-compatible architectures are used, it is supposed returns some default values, but apparently M1 was not covered. Unfortunately currently I lack hardware and time to revise the code base and add extra architectures on the whitelist. If you could propose a solution and make a PR, it would be really appreciated!

Would be happy to add a commit or two off of your PR here once we get things ship shape. =)

~/.opam/default/bin/ocamlmklib.opt will need updated to handle .tbd files, which are ascii text-based stub library files.
xref: https://github.com/ziglang/zig/issues/8935
Digging into the generated outputs with -v, I see cc:
cc -shared                    -flat_namespace -undefined suppress -Wl,-no_compact_unwind                     -g -o src/owl/dllowl_stubs.so src/owl/SFMT.o src/owl/airy.o src/owl/airyf.o src/owl/bdtr.o src/owl/beta.o src/owl/btdtr.o src/owl/cbrt.o src/owl/chbevl.o src/owl/chbevlf.o src/owl/chdtr.o src/owl/const.o src/owl/constf.o src/owl/dawsn.o src/owl/dawsnf.o src/owl/ellie.o src/owl/ellik.o src/owl/ellpe.o src/owl/ellpj.o src/owl/ellpk.o src/owl/exp10.o src/owl/exp2.o src/owl/expn.o src/owl/fdtr.o src/owl/fresnl.o src/owl/gamma.o src/owl/gammaf.o src/owl/gdtr.o src/owl/gels.o src/owl/hyp2f1.o src/owl/hyperg.o src/owl/hypergf.o src/owl/i0.o src/owl/i0f.o src/owl/i1.o src/owl/i1f.o src/owl/igam.o src/owl/igami.o src/owl/incbet.o src/owl/incbi.o src/owl/ivf.o src/owl/j0.o src/owl/j0f.o src/owl/j1.o src/owl/j1f.o src/owl/jnf.o src/owl/jv.o src/owl/jvf.o src/owl/k0.o src/owl/k0f.o src/owl/k1.o src/owl/k1f.o src/owl/kn.o src/owl/kolmogorov.o src/owl/lanczos.o src/owl/mtherr.o src/owl/nbdtr.o src/owl/ndtr.o src/owl/ndtri.o src/owl/owl_cblas_generated_stub.o src/owl/owl_core_utils.o src/owl/owl_dcdflib.o src/owl/owl_distribution_common_c.o src/owl/owl_fftpack_float32.o src/owl/owl_fftpack_float64.o src/owl/owl_ipmpar.o src/owl/owl_lapacke_generated_stub.o src/owl/owl_maths_special_gamma.o src/owl/owl_maths_special_impl.o src/owl/owl_maths_special_stub.o src/owl/owl_matrix_check_stub.o src/owl/owl_matrix_swap_stub.o src/owl/owl_ndarray_contract_stub.o src/owl/owl_ndarray_conv_stub.o src/owl/owl_ndarray_fma_stub.o src/owl/owl_ndarray_maths_stub.o src/owl/owl_ndarray_pool_stub.o src/owl/owl_ndarray_repeat_stub.o src/owl/owl_ndarray_slide_stub.o src/owl/owl_ndarray_sort_stub.o src/owl/owl_ndarray_transpose_stub.o src/owl/owl_ndarray_upsampling_stub.o src/owl/owl_ndarray_utils_stub.o src/owl/owl_slicing_basic_stub.o src/owl/owl_slicing_fancy_stub.o src/owl/owl_stats_dist_beta.o src/owl/owl_stats_dist_binomial.o src/owl/owl_stats_dist_cauchy.o src/owl/owl_stats_dist_chi2.o src/owl/owl_stats_dist_dirichlet.o src/owl/owl_stats_dist_exponential.o src/owl/owl_stats_dist_exponpow.o src/owl/owl_stats_dist_f.o src/owl/owl_stats_dist_gamma.o src/owl/owl_stats_dist_gaussian.o src/owl/owl_stats_dist_gennorm.o src/owl/owl_stats_dist_geometric.o src/owl/owl_stats_dist_gumbel1.o src/owl/owl_stats_dist_gumbel2.o src/owl/owl_stats_dist_hypergeometric.o src/owl/owl_stats_dist_laplace.o src/owl/owl_stats_dist_logistic.o src/owl/owl_stats_dist_lognormal.o src/owl/owl_stats_dist_logseries.o src/owl/owl_stats_dist_lomax.o src/owl/owl_stats_dist_multinomial.o src/owl/owl_stats_dist_negative_binomial.o src/owl/owl_stats_dist_noncentral_chi2.o src/owl/owl_stats_dist_noncentral_f.o src/owl/owl_stats_dist_poisson.o src/owl/owl_stats_dist_power.o src/owl/owl_stats_dist_rayleigh.o src/owl/owl_stats_dist_stub.o src/owl/owl_stats_dist_t.o src/owl/owl_stats_dist_triangular.o src/owl/owl_stats_dist_uniform.o src/owl/owl_stats_dist_vonmises.o src/owl/owl_stats_dist_wald.o src/owl/owl_stats_dist_weibull.o src/owl/owl_stats_dist_zipf.o src/owl/owl_stats_extend_misc.o src/owl/owl_stats_extend_shuffle.o src/owl/owl_stats_extend_stub.o src/owl/owl_stats_prng_stub.o src/owl/owl_stats_ziggurat.o src/owl/pdtr.o src/owl/polevlf.o src/owl/psi.o src/owl/rgamma.o src/owl/round.o src/owl/scipy_iv.o src/owl/sf_error.o src/owl/shichi.o src/owl/sici.o src/owl/sincos.o src/owl/sindg.o src/owl/spence.o src/owl/sqrtf.o src/owl/stdtr.o src/owl/struve.o src/owl/struvef.o src/owl/tandg.o src/owl/tukey.o src/owl/unity.o src/owl/yn.o src/owl/ynf.o src/owl/zeta.o src/owl/zetac.o    -L/opt/homebrew/Cellar/openblas/0.3.19/lib -lopenblas -lm

Then finally the ld command:
Apple clang version 13.0.0 (clang-13<IP_ADDRESS>)
Target: arm64-apple-darwin21.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -dylib -arch arm64 -flat_namespace -platform_version macos 12.0.0 12.1 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -undefined suppress -undefined suppress -o src/owl/dllowl_stubs.so -L/opt/homebrew/Cellar/openblas/0.3.19/lib -L/usr/local/lib -no_compact_unwind src/owl/SFMT.o src/owl/airy.o src/owl/airyf.o src/owl/bdtr.o src/owl/beta.o src/owl/btdtr.o src/owl/cbrt.o src/owl/chbevl.o src/owl/chbevlf.o src/owl/chdtr.o src/owl/const.o src/owl/constf.o src/owl/dawsn.o src/owl/dawsnf.o src/owl/ellie.o src/owl/ellik.o src/owl/ellpe.o src/owl/ellpj.o src/owl/ellpk.o src/owl/exp10.o src/owl/exp2.o src/owl/expn.o src/owl/fdtr.o src/owl/fresnl.o src/owl/gamma.o src/owl/gammaf.o src/owl/gdtr.o src/owl/gels.o src/owl/hyp2f1.o src/owl/hyperg.o src/owl/hypergf.o src/owl/i0.o src/owl/i0f.o src/owl/i1.o src/owl/i1f.o src/owl/igam.o src/owl/igami.o src/owl/incbet.o src/owl/incbi.o src/owl/ivf.o src/owl/j0.o src/owl/j0f.o src/owl/j1.o src/owl/j1f.o src/owl/jnf.o src/owl/jv.o src/owl/jvf.o src/owl/k0.o src/owl/k0f.o src/owl/k1.o src/owl/k1f.o src/owl/kn.o src/owl/kolmogorov.o src/owl/lanczos.o src/owl/mtherr.o src/owl/nbdtr.o src/owl/ndtr.o src/owl/ndtri.o src/owl/owl_cblas_generated_stub.o src/owl/owl_core_utils.o src/owl/owl_dcdflib.o src/owl/owl_distribution_common_c.o src/owl/owl_fftpack_float32.o src/owl/owl_fftpack_float64.o src/owl/owl_ipmpar.o src/owl/owl_lapacke_generated_stub.o src/owl/owl_maths_special_gamma.o src/owl/owl_maths_special_impl.o src/owl/owl_maths_special_stub.o src/owl/owl_matrix_check_stub.o src/owl/owl_matrix_swap_stub.o src/owl/owl_ndarray_contract_stub.o src/owl/owl_ndarray_conv_stub.o src/owl/owl_ndarray_fma_stub.o src/owl/owl_ndarray_maths_stub.o src/owl/owl_ndarray_pool_stub.o src/owl/owl_ndarray_repeat_stub.o src/owl/owl_ndarray_slide_stub.o src/owl/owl_ndarray_sort_stub.o src/owl/owl_ndarray_transpose_stub.o src/owl/owl_ndarray_upsampling_stub.o src/owl/owl_ndarray_utils_stub.o src/owl/owl_slicing_basic_stub.o src/owl/owl_slicing_fancy_stub.o src/owl/owl_stats_dist_beta.o src/owl/owl_stats_dist_binomial.o src/owl/owl_stats_dist_cauchy.o src/owl/owl_stats_dist_chi2.o src/owl/owl_stats_dist_dirichlet.o src/owl/owl_stats_dist_exponential.o src/owl/owl_stats_dist_exponpow.o src/owl/owl_stats_dist_f.o src/owl/owl_stats_dist_gamma.o src/owl/owl_stats_dist_gaussian.o src/owl/owl_stats_dist_gennorm.o src/owl/owl_stats_dist_geometric.o src/owl/owl_stats_dist_gumbel1.o src/owl/owl_stats_dist_gumbel2.o src/owl/owl_stats_dist_hypergeometric.o src/owl/owl_stats_dist_laplace.o src/owl/owl_stats_dist_logistic.o src/owl/owl_stats_dist_lognormal.o src/owl/owl_stats_dist_logseries.o src/owl/owl_stats_dist_lomax.o src/owl/owl_stats_dist_multinomial.o src/owl/owl_stats_dist_negative_binomial.o src/owl/owl_stats_dist_noncentral_chi2.o src/owl/owl_stats_dist_noncentral_f.o src/owl/owl_stats_dist_poisson.o src/owl/owl_stats_dist_power.o src/owl/owl_stats_dist_rayleigh.o src/owl/owl_stats_dist_stub.o src/owl/owl_stats_dist_t.o src/owl/owl_stats_dist_triangular.o src/owl/owl_stats_dist_uniform.o src/owl/owl_stats_dist_vonmises.o src/owl/owl_stats_dist_wald.o src/owl/owl_stats_dist_weibull.o src/owl/owl_stats_dist_zipf.o src/owl/owl_stats_extend_misc.o src/owl/owl_stats_extend_shuffle.o src/owl/owl_stats_extend_stub.o src/owl/owl_stats_prng_stub.o src/owl/owl_stats_ziggurat.o src/owl/pdtr.o src/owl/polevlf.o src/owl/psi.o src/owl/rgamma.o src/owl/round.o src/owl/scipy_iv.o src/owl/sf_error.o src/owl/shichi.o src/owl/sici.o src/owl/sincos.o src/owl/sindg.o src/owl/spence.o src/owl/sqrtf.o src/owl/stdtr.o src/owl/struve.o src/owl/struvef.o src/owl/tandg.o src/owl/tukey.o src/owl/unity.o src/owl/yn.o src/owl/ynf.o src/owl/zeta.o src/owl/zetac.o -lopenblas -lm -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/lib/darwin/libclang_rt.osx.a
ld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
...
@(#)PROGRAM:ld  PROJECT:ld64-711
BUILD 21:57:24 Nov 17 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
	/opt/homebrew/Cellar/openblas/0.3.19/lib
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/
ld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64

libgcc_s.dylib is implicitly getting included due to libopenblas, specifically liblapacke. Something which likely shouldn't be grabbing libgcc is pulling it in the LAPACKE build.
LAPACKE, which we appear to sometimes bundle in OpenBLAS, depends on fortran, which requires gfortran, or a commercial compiler, or potentially flang llvm for the apple-m1.
x86_64 emulation through Rosetta2 is a stop-gap which may suffice while a better solution is designed and implemented. It requires a separate homebrew install, e.g. /usr/local/homebrew, using arch -x86_64 $(echo $SHELL).
Apple has their own port of LAPACK https://developer.apple.com/documentation/accelerate/solving_systems_of_linear_equations_with_lapack
And BLAS via vecLIB
https://developer.apple.com/documentation/accelerate/veclib
What would it take to use these to satisfy the dependency? What is lost in these libraries that are not in the latest open source?
Cheers,
Joe

I built LAPACK natively and statically linked the libraries and their included BLAS rather than OpenBLAS. This works and gets us past the libgcc_s requirement from before. Now I am probably breaking some glue that is in OpenBLAS.
Build fails with:
dune external-lib-deps --missing @install @runtest
dune build @install
File "src/base/dense/owl_base_dense_ndarray_generic.ml", line 432, characters 20-24:
Error (warning 16 [unerasable-optional-argument]): this optional argument cannot be erased.

Here is the build log at the break in full: https://termbin.com/8hrr
Next steps are to either get the Owl build to work from here:
https://github.com/jhgorse/owl/tree/mseri-patch-1
or patch up OpenBLAS to make me some static LAPACK libs as they do by default, which avoids implicit inclusion of libgcc_s.
@mseri @jzstark Which path should I take? What have I broken by not using OpenBLAS?

Fantastic. I don't think you are breaking anything, those errors are actually warnings from recent ocaml versions. It is just compiled with too restrictive flags.
If you add --profile=release to the dune invocation it should work fine.
PA Are you working on my branch or on owl master? In the first case, the warning should disappear if you rebase it on the current owl master. At least I though the warning was silenced recently

@mseri Great! Got a little further. We are trying to link now. =)
Undefined symbols for architecture arm64:
  "_LAPACKE_clagge", referenced from:
      _owl_stub_393_LAPACKE_clagge in libowl_stubs.a(owl_lapacke_generated_stub.o)
      _owl_stub_393_LAPACKE_clagge_byte9 in libowl_stubs.a(owl_lapacke_generated_stub.o)
     (maybe you meant: _owl_stub_393_LAPACKE_clagge_byte9, _owl_stub_393_LAPACKE_clagge )

Thoughts on this guy? Seems like I may have unbalanced the owl stub generator.

@mseri

PA Are you working on my branch or on owl master? In the first case, the warning should disappear if you rebase it on the current owl master. At least I though the warning was silenced recently

Off of your branch, which seems rebased. The first warning did disappear after rebasing to master. My fork and branch live here:
https://github.com/jhgorse/owl/tree/mseri-patch-1

@jhgorse jhgorse im working off your repo, I'm using the new clang-15 compiler that came out last week it seems like everything builds but the new clang has an issue that the stdlibc++ is not longer supported on apple devices, so it seems like the linker is getting into issues there. I'm using just dune build without any custom flags.
I tried running it using Xcode's clang there is a symbol not found in architecture arm64 error. I'm not sure how we can fix this but apparently the new clang update enables -march=native which is the error i was facing on making eigen, to be fixed. I'm not sure how to fix the linker error perhaps a native version of the stdlib might work?

@xinslu what is the linker error?

Standard Library for c and cpp are not found linker is not able to connect -lm and -lSystem. I understand this has nothing to do with owl but i think its the furthest I gotten with the the base config and build. All the other files compile without an error I have errors when I reach the linker stage.

@jhgorse
❯ dune build --profile=release
File "src/aeos/config/dune", line 2, characters 7-16:
2 |  (name configure)
           ^^^^^^^^^
ld: library not found for -lm
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
File "caml_startup", line 1:
Error: Error during linking (exit code 1)
File "src/owl/config/dune", line 2, characters 7-16:
2 |  (name configure)
           ^^^^^^^^^
ld: library not found for -lm
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
File "caml_startup", line 1:
Error: Error during linking (exit code 1)
File "src/base/dune", line 23, characters 0-89:
23 | (library
24 |  (name owl_base)
25 |  (public_name owl-base)
26 |  (wrapped false)
27 |  (libraries bigarray))
ld: library not found for -lSystem
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
File "caml_startup", line 1:

As you see, I cannot link to the Standard Library. I tried using different stdlib defs by invoking a simple program using math.h and running -v. To check the path invocation, I've tried many different CFLAG combinations but none work. Any help is appreciated.

@xinslu try the dune command with --verbose
https://dune.readthedocs.io/en/stable/usage.html
We need to drill down and see what -L library paths are being used. Then we can add things like  /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks and such.

I tried use the verbose flag nothing much related to clang linker invocation came out of it so i reverted to using a simple program using <math.h>. Here is the result of clang -XLinker -v
@(#)PROGRAM:ld  PROJECT:ld64-762
BUILD 06:28:58 Feb 18 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
ld: warning: directory not found for option '-L/Applications/Xcode.app/Content'
ld: warning: directory not found for option '-L/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include'
Library search paths:
	/usr/local/include
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1
	/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/include
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
	/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
	/usr/lib
	/usr/local/lib
Framework search paths:
	/Library/Frameworks/
	/System/Library/Frameworks/

I will planning to clean up the code and migrate to ocaml 4.14 in the following months. Is this patch still relevant? Should we merge or drop this? @mseri @jzstark @tachukao

This is independent of 4.14 and I believe is still relevant if you want to support arm64. It is only a preliminary step though

This is independent of 4.14 and I believe is still relevant if you want to support arm64. It is only a preliminary step though

OK, thanks. Let's come back to this and find a solution after I clean up the code. Looks like changing from master to main automatically closed the PR somewhow.

@xinslu and team,
I have built owl for the m1 successfully. Here are the steps to reproduce:
brew install opam ocaml openblas eigen

#pkg-conflig
export PKG_CONFIG_PATH=/opt/homebrew/opt/openblas/lib/pkgconfig

#eigen cflags
export EIGEN_FLAGS="-O3 -Ofast -mcpu=apple-m1 -funroll-loops -ffast-math"
export EIGENCPP_OPTFLAGS="-Ofast -mcpu=apple-m1 -funroll-loops -ffast-math"

#owl cflags

export OWL_CFLAGS="-g -O3 -Ofast -mcpu=apple-m1 -funroll-loops -ffast-math -DSFMT_MEXP=19937 -fno-strict-aliasing -Wno-tautological-constant-out-of-range-compare"; export OWL_AEOS_CFLAGS="-g -O3 -Ofast -mcpu=apple-m1 -funroll-loops -ffast-math -DSFMT_MEXP=19937 -fno-strict-aliasing"

mkdir ~/Work && cd ~/Work
# src/owl/core/owl_core_utils.c issues
# removed x86 code that does not compile on arm64
# see offending code here: https://github.com/jhgorse/owl/commit/bab252a413db946560eb11e3cd54a94100a46a69
# note: somehow need to exclude this code when we are arm64 arch.
git clone https://github.com/jhgorse/owl
opam pin owl ~/Work/owl

dune test fails on warnings, though:
% dune test
In file included from src/owl/core/owl_ndarray_contract_stub.c:17:
src/owl/core/owl_ndarray_contract_impl.h:88:9: warning: incompatible pointer types assigning to 'int64_t *' (aka 'long long *') from 'intnat []' [-Wincompatible-pointer-types]
  cp->n = X->dim;
        ^ ~~~~~~
In file included from src/owl/core/owl_ndarray_contract_stub.c:26:
src/owl/core/owl_ndarray_contract_impl.h:88:9: warning: incompatible pointer types assigning to 'int64_t *' (aka 'long long *') from 'intnat []' [-Wincompatible-pointer-types]
  cp->n = X->dim;
        ^ ~~~~~~
In file included from src/owl/core/owl_ndarray_contract_stub.c:35:
src/owl/core/owl_ndarray_contract_impl.h:88:9: warning: incompatible pointer types assigning to 'int64_t *' (aka 'long long *') from 'intnat []' [-Wincompatible-pointer-types]
  cp->n = X->dim;
        ^ ~~~~~~
In file included from src/owl/core/owl_ndarray_contract_stub.c:44:
src/owl/core/owl_ndarray_contract_impl.h:88:9: warning: incompatible pointer types assigning to 'int64_t *' (aka 'long long *') from 'intnat []' [-Wincompatible-pointer-types]
  cp->n = X->dim;
        ^ ~~~~~~
4 warnings generated.
File "test/unit_signal.ml", line 78, characters 14-15:
78 |       |> fun (a, b) -> b
                   ^
Error (warning 27 [unused-var-strict]): unused variable a.

@jhgorse if you merge my arm branch into your changes, you can avoid deleting the x86 tweak. I added some macros to disable that only on ARM


Seems transfer needs fix

I guess it requires Math.trunc() to round number
https://kodadot.xyz/transfer/
tried transfer 0.54

i'd like to fix it


Maximum update depth exceeded error

Got this error while heading into the mist. Got the same error before that when fighting an ogre and couldnt attack but had to flee. This started once i had created a second adventurer and played with it.
States "Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops."

Oh and environment mac book air, apple silicon and using chrome + braavos wallet

Have seen what now causes this error and recent upgrades should have made it obsolete.


Allow installing tension globally

TODO

[ ] Test to install and use tension globally
[ ] Maybe we must include tension global dependencies in webpack config (thought the resolve.modules property) to avoid Cannot find module errors
[ ] If that works: update the default webpack configuration factory (lib/wcf.js) or add this hook in the AbstractBundler._createWebpackConfig() method (preference for the second choice because in that way tension node modules will be the last resolve rule).

Definitively a bad thing because we need to be able to access to webpack or other dependencies locally. It's like installing webpack globally (so a bad idea).


Translating documents.

Greetings, and good afternoon. I was wondering if it is possible, to translate the documents in different languages. From what I have seen in some projects, inside the wiki folder, one would create one with the language folder, but what I don't understand, is in what way, then the wiki, could detect the different languages, and offer them. To begin with, I would have to create something in the url, where I add the different languages: /en/, /es/, /it/. Thank you in advance for any information in this regard.

This issue was resolved. Thank you.


Clarification on encoding format of attachment data in Delivery message of  RFC-0685-pickup-v2

Is the last line here (emphasis mine), meant to imply that only base64 encoding is valid in delivery message attachments (as opposed to json/links defined in attachment rfc)?
It is unclear if the final line there implies a recommendation/compulsion of the protocol RFC to use the shown encoding, or is simply a comment for the particular example.
Source partially quoted below for convenience.

The ONLY valid type of attachment for this message is a DIDComm Message in encrypted form.

The recipient_key attribute is only included when responding to a delivery-request message that indicates a recipient_key.

{
    "@id": "123456781",
    "~thread": {
        "thid": "<message id of delivery-request message>"
      },
    "@type": "https://didcomm.org/messagepickup/2.0/delivery",
    "recipient_key": "<key for messages>",
    "~attach": [{
    	"@id": "<messageid>",
    	"data": {
    		"base64": ""
    	}
    }]
}

This method of delivery does incur an encoding cost, but is much simpler to implement and a more robust interaction.

My understanding is that both base64 and json forms are valid (links are theoretically valid as well, but I don't see any meaningful use case for them). In Credo we are sending them in json format, but we accept receiving them also in base64.
To my kowledge, the line:

This method of delivery does incur an encoding cost, but is much simpler to implement and a more robust interaction.

Refers to the fact that wrapping Forward messages in a Delivery message is more costly than simply sending them 'naked' through the transport.
@TelegramSam considering that we are going to add some clarifications on this spec, I think it's worth to also add a note here.


Investigate making a brainglobe metapackage on conda-forge

from a conversation with @willGraham01:
right now when creating a conda environment, we need to install hdf5 manually for pip install brainglobe to work (tables requires it). In conda, we should be able to add hdf5 explicitly to the recipe.

@sfmig is this only on macOS though? I assumed it was only a problem when there aren't pre-compiled tables wheels, i.e. only on Apple Silicon.
See discussion at https://github.com/brainglobe/brainglobe-segmentation/issues/145. Hopefully this will be fixed with pip installs sometime soon.

Thought I'd revive this thread now that we're over the majority of the reorganisation of BrainGlobe version 1 and our packages have stable releases on PyPI.
This issue is currently blocked by:

Merging atlasapi and atlasgen, renaming in the process: https://github.com/brainglobe/BrainGlobe/issues/43
Replacing tensorflow with keras in our cellfinder dependency. (Although we can get quite far ignoring this actually).
morphapi is currently a) broken and b) needs a particularly tricky conda-forge recipe.

Packages currently on conda-forge:

brainglobe-utils
brainglobe-napari-io
brainglobe-segmentation
bg-space OUTDATED, replace with brainglobe-space
bg-atlasapi
imio
brainreg

Of these, we can retain the utils, napari-io, and segmentation feedstocks, but they will need updating to the latest version as we carry out the process of updating our packages. To that point:

bg-atlasapi will need to be marked as deprecated. We'll need a new conda recipe for brainglobe-atlasapi, as per https://github.com/brainglobe/BrainGlobe/issues/43
bg-space will also need to be marked as deprecated, since we'll be needing the new brainglobe-space package instead.

Otherwise, we can follow the dependency tree to upload packages in a sensible order. conda-forge is able to add multiple packages at once - even with interdependencies - so long as all packages can be installed through conda channels.
The Plan
Presented in the order that should be attempted due to dependency issues, etc.
However some tasks can be done in parallel.

[ ] Upload brainglobe-space
[ ] Upload brainglobe-atlasapi | BLOCKED by https://github.com/brainglobe/BrainGlobe/issues/43

From here, we can split into two parallel streams:
morphapi and dependencies

Upload morphapi, brainrender, and brainglobe-heatmap in one PR

BLOCKED by morphapi problems.
Depends on brainglobe-altasapi being available on conda-forge.
[ ] morphapi
[ ] brainrender
[ ] brainglobe-heatmap

Building up to brainreg

[ ] Upload brainrender-napari
[ ] Update brainglobe-utils-feedstock to ship a brainglobe-utils version that depends on brainglobe-space and brainglobe-atlasapi rather than the bg-named packages.
Upload brainglobe-napari-io and cellfinder

Can be done simultaneously
[ ] brainglobe-napari-io
[ ] cellfinder

Update imio-feedstock
Update brainglobe-segment-feedstock if necessary
Update brainreg-feedsotck

Meta-package
Once both streams are complete, we can upload the meta-package to conda-forge.
Note: we might be able to do this sooner if we want to forgo the morphapi-dependencies, but this would be a manual conda-forge exclusion for the time being.

Upload brainglobe-meta and brainglobe-workflows

Can be done simultaneously
[ ] brainglobe-meta
[ ] brainglobe-workflows

brainglobe-atlasapi depends on pymcubes, which is not on conda-forge.
I've asked the creator of pymcubes if they're OK with us uploading it to conda-forge, and if they want to be added as a maintainer.

If this doesn't work, we don't necessarily need all the atlasgen code in the package, so it might be better to either move it out, or just add some optional atlas generation dependencies.

If this doesn't work, we don't necessarily need all the atlasgen code in the package, so it might be better to either move it out, or just add some optional atlas generation dependencies.

Recipe seems to work - had to suppress the Windows build tests because vtk is broken on conda-forge (doesn't show up in pip check but is there).

brainglobe-atlasapi is now available on conda-forge :partying_face: So the rest of the plan can start to be enacted.


Connecting to dapp's not working - forever loading after selecting account

I am getting multiple reports that users are having trouble connecting to dapps with their wallet. After selecting the account to connect with. It loads forever and never logs in on the dapp.
When doing the same on a ledger enabled wallet extension their is no issue.
On Firefox I see this:
https://user-images.githubusercontent.com/33360391/232696153-7c3b8bda-49af-45ad-a64c-50ff56cd37c2.mp4
Chrome shows this in console:

It looks like this is the underlying issue, already resolved:

@kyranjamie should we reduce or remove our Gaia dependency further here so future outages aren't breaking?

@markmhx Gaia dependency is part of auth protocol. You want to change the protocol?

Can you elaborate on that @friedger? Where does it say this?

@kyranjamie We store app meta data in the profile and we use the gaia protocol for storage. See also (https://github.com/stacksgov/sips/blob/58aae536637ad9236365d0873f07d8d831b4add1/sips/sip-x/sip-x-authentication-protocol.md#public-profile)
To remove dependency we either need to remove the app meta data and public profiles or find a different storage solution.
For a different storage solution, we need to add support for users to update their zonefile.

Update from diwaker
diwaker — Today 10 minutes ago
Hey all, appreciate the pings -- I'm in EST so appreciate your patience while our team comes online. We're looking into the Gaia hub issue, I don't see anything obviously wrong on our end -- it's likely something with Azure. Please bear with us, we'll update as soon as we have something to share.

https://status.hiro.so/
to keep an eye on the current status

https://status.hiro.so/ to keep an eye on the current status

Resolved as of an hour ago.

To remove dependency we either
A) need to remove the app meta data and public profiles (like for ledger users) or
B) find a different storage solution.

@friedger my sense here is that it'd be most expedient to implement option A only for when the wallet detects that Gaia is down, defaulting to a degraded yet unblocked experience a la the one Ledger users have?

I agree in the hope that some resources re available to make gaia usable and configurable so that Hiro carries all the load. See forum post about gaia at home.

Apparently this error can also be caused by an ad blocker sometimes. Having a solution so that the user can proceed, in degraded state, rather than being blocked completely seems like a good idea. hz.btc agrees ;-)

Is gaia always out these days? Seeing this a lot and it prevents the user from connecting to dapps

This comment related (the rest of the issue seems different, although I am not entirely sure): https://github.com/leather-io/extension/issues/5919#issuecomment-2497548908


cmd/go: go build either looks for go.mod in the directory specified by -C or doesn't depending on where -C appears relative to -gcflags

$ go version
go version devel go1.21-40bdc56180 Tue May 23 13:22:25 2023 +0000 linux/amd64

but also reproduces with 1.20. Reproducer:
$ mkdir example
$ cd example
$ go mod init example
$ cat - > main.go
package main
func main() { println("hello world") }
^D
$ cd ..
$ go build -C example -gcflags=""
(succeeds)
$ go build -gcflags="" -C example
go: go.mod file not found in current directory or any parent directory; see 'go help modules'

Originally reported at https://github.com/go-delve/delve/pull/3380#issuecomment-1560400825

cc @bcmills

both -C and the build flags are processed as they are set, doesn't seem like an easy fix
https://github.com/golang/go/blob/7ad92e95b56019083824492fbec5bb07926d8ebd/src/cmd/go/internal/base/flag.go#L65
https://github.com/golang/go/blob/7ad92e95b56019083824492fbec5bb07926d8ebd/src/cmd/go/internal/work/build.go#L313
https://github.com/golang/go/blob/7ad92e95b56019083824492fbec5bb07926d8ebd/src/cmd/go/internal/load/flag.go#L38

The documentation for go build currently states:

If used, [the -C] flag must be the first one in the command line.

That restriction was added in https://go.dev/cl/500915 for #57001.
Closing as probably fixed, but please let us know if you can still reproduce similar problems using Go 1.21 or higher.


nixos/archisteamfarm: fix crash when web-ui is disabled

Description of changes
Closes #312242
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg eval

Next time report upstream :slightly_smiling_face:
https://github.com/JustArchiNET/ArchiSteamFarm/commit/b9beb6ec16ac849ece68e4abb337c328e2bc0eb9


Renamed state_context Entry to TpStateEntry

The change makes the Entry message consistently named with the TpState- prefix that the rest of the messages in state_context

Rebased from master.


Fixed Suffix for Completion on Mapping

This pull request fixes completion mapping with suffix
:fireworks:  Fixes #1408 :fireworks:
Please review

[ ] @Mpdreamz / @gmarz

:disappointed: We are still getting this CLA error, lets try to fix this early this week :smile:

closing this in favor of the continued discussion on #1408


Incorrect test values in accumulator unit test

The test values in the accumulator unit test seem to be incorrect. This test breaks the whole build so I've commented out the incorrect section of the test for now, but that test needs to be fixed as soon as possible.

That test should really use:
 clock = sinon.useFakeTimers(Date.now(),
  'Date', 'setTimeout', 'clearTimeout', 'setInterval', 'clearInterval');

to control the passing of time during the execution of the test and make it deterministic.

That would help simplify the test logic simpler as IMO it's way too complicated right now.

Actually fixed in 6a92c41.


Add too far in future time window to Receives

This is done through an upgrade to the observatorium-deployment jsonnet dependency.

/lgtm


added offline app page

fixes #760
fixes #792

Added Miscellaneous Index Page (could be added as a child of homepage)
Added Offline App Page (reduced version of Article) (could be added as a child of miscellaneous index page)

Added offline app button block
it will be rendered if cache setting is enabled and display button is checked

removed banner to download
button text isn't context-sensitive right now
fixed create_initial_data command
created Miscellaneous Index Page in load_v1_db

When I try to create an OfflineAccessPage, upon publishing the page in the CMS, the page crashes (see below).

Add misc index page to create_initial_data?
This new page can be identical to article, except for the support of this button. No need to remove stuff from the normal article for this.

Environment:

Request Method: POST
Request URL: http://localhost:8000/admin/pages/add/home/offlineapppage/586/

Django Version: 3.1.11
Python Version: 3.6.9
Installed Applications:
['home',
 'search',
 'iogt_users',
 'comments',
 'iogt_content_migration',
 'questionnaires',
 'messaging',
 'django.contrib.humanize',
 'wagtail_localize',
 'wagtail_localize.locales',
 'wagtail.contrib.forms',
 'wagtail.contrib.redirects',
 'wagtail.embeds',
 'wagtail.sites',
 'wagtail.users',
 'wagtail.snippets',
 'wagtail.documents',
 'wagtail.images',
 'wagtail.search',
 'wagtail.admin',
 'wagtail.core',
 'wagtail.contrib.modeladmin',
 'wagtailmenus',
 'wagtailmedia',
 'wagtailmarkdown',
 'wagtail_transfer',
 'wagtailsvg',
 'wagtail.contrib.settings',
 'django_comments_xtd',
 'django_comments',
 'modelcluster',
 'taggit',
 'allauth',
 'allauth.account',
 'allauth.socialaccount',
 'rest_framework',
 'sass_processor',
 'translation_manager',
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'django.contrib.sites',
 'django_extensions']
Installed Middleware:
['django.middleware.security.SecurityMiddleware',
 'whitenoise.middleware.WhiteNoiseMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'django.middleware.locale.LocaleMiddleware',
 'wagtail.contrib.redirects.middleware.RedirectMiddleware',
 'iogt_users.middlewares.RegistrationSurveyRedirectMiddleware',
 'external_links.middleware.RewriteExternalLinksMiddleware',
 'iogt.middleware.CacheControlMiddleware']

Traceback (most recent call last):
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/django/core/handlers/base.py", line 181, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/django/views/decorators/cache.py", line 44, in _wrapped_view_func
    response = view_func(request, *args, **kwargs)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/wagtail/admin/urls/__init__.py", line 127, in wrapper
    return view_func(request, *args, **kwargs)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/wagtail/admin/auth.py", line 172, in decorated_view
    response = view_func(request, *args, **kwargs)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/django/views/generic/base.py", line 70, in view
    return self.dispatch(request, *args, **kwargs)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/wagtail/admin/views/pages/create.py", line 96, in dispatch
    return super().dispatch(request)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/django/views/generic/base.py", line 98, in dispatch
    return handler(request, *args, **kwargs)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/wagtail/admin/views/pages/create.py", line 104, in post
    return self.form_valid(self.form)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/wagtail/admin/views/pages/create.py", line 110, in form_valid
    return self.publish_action()
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/wagtail/admin/views/pages/create.py", line 151, in publish_action
    self.parent_page.add_child(instance=self.page)
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/treebeard/mp_tree.py", line 1083, in add_child
    return MP_AddChildHandler(self, **kwargs).process()
  File "/data/idems/iogt/iogt_venv/lib/python3.6/site-packages/treebeard/mp_tree.py", line 377, in process
    newobj.path = self.node.get_last_child()._inc_path()

Exception Type: AttributeError at /admin/pages/add/home/offlineapppage/586/
Exception Value: 'NoneType' object has no attribute '_inc_path'

Hi, this is working great in practice. What is the purpose of the 'display button' flag? Why would someone include a button and then not show it?
Could you instead add 3 text fields for the button:

Text to show on a smartphone. Help text: This text appears when it is possible for the user to install the app on their phone.
Text to show on a feature phone. Help text: This text appears when the user is using a feature phone and thus cannot install the app (the button will be disabled in this case). [Currently not implemented]
Text to show when offline. Help text: This text appears when the user is navigating the site via the offline app and thus it doesn't make sense to install the offline app again (the button will be disabled in this case). [Currently not implemented]

@geoo89 changes addressed


[gym] iOS Export Options "Destination" Handling

Checklist

[x] I've run bundle exec rspec from the root directory to see all new and existing tests pass
[x] I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
[x] I've read the Contribution Guidelines
[x] I've updated the documentation if necessary.

Motivation and Context
gym supports passing in archive export options through the export_options parameter. When gym runs fastlane/gym/lib/assets/wrap_xcodebuild/xcbuild-safe.sh -exportArchive ..., it expects that a .ipa file (amongst other files) will be created afterwards.
However, if within export_options you specify destination: "upload", no external files are generated (including the .ipa) since destination: "upload tells xcodebuild to upload to iTunes Connect immediately.
As a result, if you specify destination: "upload", the archive will successfully upload to iTunes Connect (assuming you have configured everything else correctly), but you will get the following error:
ERROR [2020-06-15 09:29:18.37]: The generated archive is invalid, this can have various reasons:
ERROR [2020-06-15 09:29:18.37]: Usually it's caused by the `Skip Install` option in Xcode, set it to `NO`
ERROR [2020-06-15 09:29:18.37]: For more information visit https://developer.apple.com/library/ios/technotes/tn2215/_index.html
ERROR [2020-06-15 09:29:18.37]: Also, make sure to have a valid code signing identity and provisioning profile installed
ERROR [2020-06-15 09:29:18.37]: Follow this guide to setup code signing https://docs.fastlane.tools/codesigning/GettingStarted/
ERROR [2020-06-15 09:29:18.37]: If your intention was only to export an ipa be sure to provide a valid archive at the archive path.
ERROR [2020-06-15 09:29:18.37]: This error might also happen if your workspace/project file is not in the root directory of your project.
ERROR [2020-06-15 09:29:18.37]: To workaround that issue, you can wrap your calls to gym with
ERROR [2020-06-15 09:29:18.37]: `Dir.chdir('../path/to/dir/containing/proj') do`
ERROR [2020-06-15 09:29:18.37]: For an example you can check out
ERROR [2020-06-15 09:29:18.37]: https://github.com/artsy/emission-nebula/commit/44fe51a7fea8f7d52f0f77d6c3084827fe5dd59e

The purpose of this PR is to prevent Fastlane from displaying this misleading error.
Description
The changes in this PR are fairly straight forward.
I simply check if the export options plist contains the destination key with a value of upload. If it does, the code no longer executes the "move" related functions (since there are no files to move in the first place).
Testing Steps
Run gym using the following export options (depending on how your specific Xcode project is configured, you might need to include other options):
{
    "destination": "upload",
    "method": "app-store",
    "signingStyle": "automatic"
}

Also, specify export_team_id (an existing gym parameter)

@googlebot I signed it!

@googlebot I fixed it.

@DomenicBianchi01 I learned so much from this! 🤯 Hopefully I learned the right thing though lol... So if I’m understanding this correctly, you use gym to upload to App Store Connect by setting destination as upload? I had absolutely no idea this was a thing!
This code change totally makes sense and looks good from a review standpoint. I’m going to try to get something setup locally to test this because I really want to see this working on my own machine too 😇

Oh my goodness I did it! I uploaded an IPA through gym. This is 🔥

@DomenicBianchi01 I learned so much from this! 🤯 Hopefully I learned the right thing though lol... So if I’m understanding this correctly, you use gym to upload to App Store Connect by setting destination as upload? I had absolutely no idea this was a thing!
This code change totally makes sense and looks good from a review standpoint. I’m going to try to get something setup locally to test this because I really want to see this working on my own machine too 😇

Correct! At the company I work at, we have multiple targets, each which need to be signed using a different team id/provisioning profiles/certificates/etc.
By setting the destination field, Xcode is actually smart enough to figure out exactly which iTMSTransporter team id needs to be used (sorry I don't know the actual name for this identifier, but it is NOT the team id shown in within the Signing & Configurations menu in Xcode) for a specific export and is therefore able to upload to App Store Connect in one shot.
Without these changes, I need to manually provide the iTMSTransporter team id for upload_to_app_store. Long story short, because we manage many different targets with different team ids, having to provide this extra ID is not ideal since setting the destination field means I don't need to worry about the ID at all.

@googlebot I consent.

@DomenicBianchi01 Thanks again for adding support for this! I pushed a commit on to this to also add this for mac as well. I will get this merged in tomorrow morning and out in the next release 💪


#0: Update CODEOWNERS

@rdjogoTT fyi

Note that this means that if either of you make updates to this, you will require the other's approval


[BUG] CPU % is more than 100%

This always happens when PC renders a video.

Hi,
Sorry for delay in answer.
I have reproduced it (but for myself it was like 101-103%).
And it is exactly the numbers Windows returns as CPU utility via its API.
For me lower than 100% number looks like exactly the same as shows in Task Manager,
so I suspect Windows itself just cut high numbers down to 100%.
This is well observed behavior and possibly related with TurboBoost-like technologies when CPU overclock itself for short amount of time.
As it is not affect graph, I do not see it as a bug.


Error in eigen(private$.susceptibility * self$contact) : 0 x 0 matrix

Hi
and thank you for creating this model!
I'm running in the error message in the title when trying to run the shiny_app(). Do I need to initialize some other values in addition to the contact matrices?
The whole error message is

> shiny_app()
Listening on http://<IP_ADDRESS>:4552
Warning: Error in eigen: 0 x 0 matrix
62: stop
61: eigen
60: .subset2(public_bind_env, "initialize")
59: Parameters$new
58: module
53: callModule
52: server
Error in eigen(private$.susceptibility * self$contact) : 0 x 0 matrix

Hello,
Can you please tell us what operating system you are using?
In the meantime, you can access the app online here: http://hospicov.ehesp.fr/

Hi,
Ubuntu 18.04, but on a virtual machine. Could that affect something?
The hospicov:Parameters seem to contain these values but they are mostly NULL

> hospicov::Parameters
 object generator
Public:
nage: 0
preImmune: NULL
preExposed: NULL
preInfected: NULL
symptomatic: NULL
progression: NULL
beta: NULL
school: NULL
home: NULL
work: NULL
other: NULL
agegroupnames: NULL
initialize: function (R0 = 2.2)
getList: function ()
clone: function (deep = FALSE)
Active bindings:
susceptibility: function (x)
R0: function (value)
removal: function (x)
duration: function (x)
nbDays: function (x)
Private:
.susceptibility: NULL
.R0: NULL
.duration: Trimester
.nbDays: 90
.removal: NULL
Parent env: <environment: namespace:hospicov>
Locked objects: TRUE
Locked class: FALSE
Portable: TRUE

The virtual machine is not an issue
There was an issue in the Parameters script indeed. It should be fixed now
Please try to install the latest dev version (not released yet) with the following command
devtools::install_github("PascalCrepey/HospiCoV")

And tell us if it is ok now

Works nicely now, thanks!


Help Suggestion

This may be helpful to others attempting to compile a program using espeakng with mbrola voices in auto-py-to-exe.
I spent many hours researching this. Mbrola voices work fine in IDE Thonny but not in an exe created using auto-py-to-exe.
Finally stumbled onto the solution.  Add path i.e. Home/.local/lib/python3.10/site-packages/espeakng to the additional files/
add folder section.

Hi, this issue tracker is for issues with the codebase behind https://pypi.org itself, not the projects hosted on PyPI.
You should report this issue to the tracker for the project in question instead.

OK, thanks
On Monday, July 10, 2023 at 08:30:37 AM EDT, Dustin Ingram<EMAIL_ADDRESS>wrote:

Hi, this issue tracker is for issues with the codebase behind https://pypi.org itself, not the projects hosted on PyPI.
You should report this issue to the tracker for the project in question instead.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


POC wasm as upstream filter

When the filter is trying to be created. it try to get the clusterManager reference from ServerFactoryContext but it seems it is not available at that moment the pointer is null. not initialized at that moment.
[2024-03-26 12:35:53.520][144854083][critical][assert] [source/server/server.cc:144] assert failure: config_.clusterManager() != nullptr.
[2024-03-26 12:35:53.520][144854083][critical][backtrace] [./source/server/backtrace.h:104] Caught Abort trap: 6, suspect faulting address 0x182652a60
[2024-03-26 12:35:53.520][144854083][critical][backtrace] [./source/server/backtrace.h:91] Backtrace (use tools/stack_decode.py to get line numbers):
[2024-03-26 12:35:53.520][144854083][critical][backtrace] [./source/server/backtrace.h:92] Envoy version: 22e6a78621ca66d3109cfa2a0f075e7efb721801/1.30.0-dev/Modified/DEBUG/BoringSSL
[2024-03-26 12:35:53.541][144854083][critical][backtrace] [./source/server/backtrace.h:96] #0: Envoy::SignalAction::sigHandler() [0x10c6dc9b8]
[2024-03-26 12:35:53.541][144854083][critical][backtrace] [./source/server/backtrace.h:96] #1: _sigtramp [0x1826bb584]
[2024-03-26 12:35:53.541][144854083][critical][backtrace] [./source/server/backtrace.h:96] #2: pthread_kill [0x18268ac20]
[2024-03-26 12:35:53.541][144854083][critical][backtrace] [./source/server/backtrace.h:96] #3: abort [0x182597a20]
[2024-03-26 12:35:53.545][144854083][critical][backtrace] [./source/server/backtrace.h:96] #4: Envoy::Server::InstanceBase::clusterManager() [0x10a3f5bcc]
[2024-03-26 12:35:53.547][144854083][critical][backtrace] [./source/server/backtrace.h:96] #5: Envoy::Server::ServerFactoryContextImpl::clusterManager() [0x10a374710]
[2024-03-26 12:35:53.548][144854083][critical][backtrace] [./source/server/backtrace.h:96] #6: Envoy::Extensions::HttpFilters::Wasm::FilterConfig::FilterConfig()
To make it work I just mock the clusterManager and could create a policy to add a header as upstream filter.
I have to add a check to not make the clearCacheRoute, I guess this has no meaning as upstream. Probably other checks are needed in the code.
Due to mock the clusterManager, I understand some functionality is not available like making calls to any server. not sure if has sens in an upstream filter.
I don't know how we could solve the clusterManager issue.


[Bug] Sort Existing Macros button not working

When i try to use the sort existing macro button i get the following error:

If it matters, these are my settings for the module:

Check added; Full handling for unauthored macros will take more effort to do nicely than I'm gonna put in until there's been some refactoring elsewhere, so for now it just yells a bit in the console but otherwise sorts. Gonna hope this was an isolated case.