Allow addressing by ID instead of "analog input" etc

@mxinden
A default config should probably come with comments to allow people familiar with Modbus to know where to put things in the config and keep a mental map. That being said, addressing by "coil" and other such names seems cumbersome and error-prone. Addressing by ID directly seems better.
Sub-addressing could be done by id:bit, ranges could be done explicitly by id-idN or implicitly by id, float32, little endian.
Gut feeling is that we will develop stronger opinions when using it for some time.

@mxinden This is not yet done, correct?

Seems it's not, yet.
CC @bastischubert

Disregarding that joule as an absolute would be better as we can calculate Wh as a rate() from there, I think this would be the better model. Current style:
  - name: 'dcim_power_consumption-xxx'
    protocol: 'tcp/ip'
    id: 2
    analogOut:
      - name: power_consumed_watt_hours
        help: 'Power Consumtion in WattHours'
        address: 1226
        metricType: counter
        labels:
          datacenter: 'Halma'
          room: 'xx'
          rack: 'xx'
          fuse: 'xx'
          customer: 'xx'
          billable: 'xx'
        dataType: float32

Proposed new style:
pre-amble block for the whole target, or exporter instance
  - protocol: 'tcp/ip'
    id: 2 << what is this? Is it unique? Or can it go into pre-amble?

    address: 1226 << this could either be keyed by address, or name. But given that the address is static, it should most likely be keyed by address
        name: 'power_consumed_watt_hours'
        help: 'Power Consumtion in WattHours'
        metricType: counter
        dataType: float32
        labels:
          datacenter: 'xx'
          room: 'xx'
          rack: 'xx'
          fuse: 'xx'
          customer: 'xx'
          billable: 'xx'

`id: 2 << what is this? Is it unique? Or can it go into pre-amble?`

The id field or SlaveID is used whenever one talks to a gateway (e.g. TCP/IP gateway) instead of straight to a modbus device. The id is used to multiplex the request to the right device behind the gateway. See http://docs.tibbo.com/tmgm/slave-id-based-routing.htm for more details.

In regards to the proposed changed format:

Prometheus needs a way to address the specific module via a module http parameter in the configuration file. Thus dropping the name property of a module definition makes this addressing impossible. Is there a particular reason why you want to drop it?

In regards to changing addressing via ID instead of analog in/out or digital in/out  there is a third option: Reading more and more modbus documentations it seems like another specification is function codes see the Wikipedia article.
As of today the specification via  analog in/out or digital in/out seems to work for our generated configuration. For now, given that this is not blocking any functionality, I would suggest postponing this change until we have more feedback by other users in regards to their preference.


How to restore wandb local server data after laptop/computer/machine that hosts the server accidentally died?

Hi Wandb Server Team,
Great work on the local server!
A quick question - how to restore wandb local server data after laptop/computer/machine that hosts the server accidentally died?
If it helps, we did mount /vol to a local persistent directory.
Please help. Many thanks.

Hi @liswp, glad you are enjoying W&B server! If you just copy the volume to whichever machine you would now like to run the server on, you should be able to simply attach it to the new container and data will be restored.
For example: docker run --rm -d -v wandb:/vol -p 8080:8080 --name wandb-local wandb/local will work if the volume is named wandb on the host machine.
Let me know if that helps!

Hi Nate,
Thanks for the message. When I do this, I got:
*** Running /etc/my_init.d/01_enable-services.sh...
*** Enabling production mode
*** Running /etc/my_init.d/02_load-settings.sh...
chgrp: changing group of '/vol/env': Operation not permitted
chgrp: changing group of '/vol/env/kid.txt': Operation not permitted
chgrp: changing group of '/vol/env/overrides.env': Operation not permitted
chgrp: changing group of '/vol/env/key.pem': Operation not permitted
chgrp: changing group of '/vol/env/minio-config.json': Operation not permitted
chgrp: changing group of '/vol/env/settings.json': Operation not permitted
chgrp: changing group of '/vol/env/jwks.json': Operation not permitted
chgrp: changing group of '/vol/env/minio_creds.env': Operation not permitted
chgrp: changing group of '/vol/env/session.txt': Operation not permitted
chgrp: changing group of '/vol/env/users.htpasswd': Operation not permitted
*** Loading settings...
*** Booting runit daemon...
*** Runit started as PID 45
*** Setting up mysql database...
*** Starting wandb servers...
*** Migrating database...
What do you think? Many thanks.

Hi Nate,
Just one more piece of observation - even if I don't copy the volume and use the existing volume, I get automatically redirected to local:8080/signup page, and I cannot login to my old account.
This issue has been consistent for us throughout the past few months such that we have to create a brand new local server, manually sync every run and format our panels from scratch everytime the linux ubuntu machine we have died or ran out of battery.
Please help. Many thanks.

Hi Nate,
Yes, I tried chmod -R 777 the entire /vol, didn't work. Please help. Thanks.

@liswp it looks like you will need to create a backup of the volume first docker run --rm --volumes-from wandb -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /wandb
Is there any way to access the original machine and run this?
Also, are you able to run a wandb server on the new machine with a new clean volume? I just wanted to make sure that Docker has the right permissions on the new machine.

sudo chown -R 999:root wandb


Prepare for release

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Messaging.EventGrid


[FEA] Dump host buffer on cuDF reader error

With: https://github.com/NVIDIA/spark-rapids/issues/8672 we have a point of entry where we can perform more in depth debugging, other than an exception that goes to the driver. There is currently a config spark.rapids.sql.[parquet|orc|avro].debug.dumpPrefix that will dump unconditionally (success or failure) to disk at a location given by dumpPrefix. What we would like is to add a dump config for "dump on error" where we use the path in dumpPrefix to deposit a host buffer that failed to decode.
We would include the path we dumped to (the full filename) in the same exception thrown here https://github.com/NVIDIA/spark-rapids/issues/8672 so we can see it easily in the driver.
As part of this we need to make sure that the dumpPrefix can be a distributed file system.

Fixed by #8970


Check case studies for mentions of Docker and update as needed

Umbrella issue: https://github.com/kubernetes/website/issues/30771
Description
Check Case Studies and for mentions of Docker.
Mitigation - case studies
We will not update case studies. For case studies that mention Docker, add a warning shortcode to the bottom of the page:
{{< warning >}}
This case study mentions Docker, which is no longer compatible with Kubernetes. For more information, see the [Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/).
{{< /warning >}}

You may need to use the underlying HTML instead:

  Warning: This case study mentions Docker, which is no longer compatible with Kubernetes. For more information, see the Dockershim Deprecation FAQ.

/triage accepted
/milestone 1.24
/assign @nate-double-u

Thanks for putting the list together @shannonxtreme

I think that these 4 are borderline cases that may need a warning attached:

https://kubernetes.io/case-studies/peardeck/index.html
https://kubernetes.io/case-studies/prowise/index.html
https://kubernetes.io/case-studies/squarespace/index.html
https://kubernetes.io/case-studies/wink/index.html

But I'm not convinced that they become warning worthy with the dockershim removal. Thoughts?

https://kubernetes.io/case-studies/peardeck/index.html
➤ I'd reword “Docker containers” to “containers”
https://kubernetes.io/case-studies/prowise/index.html
➤ I'd reword “Dockerize” to “containize”
https://kubernetes.io/case-studies/squarespace/index.html
➤ I'd reword “Docker file” to “Dockerfile”
https://kubernetes.io/case-studies/wink/index.html
➤  I'd change “just over two years ago” to “in 2015”
➤ I'd also change “Dockerized” to “containerized”
separately, maybe we should omit older case studies from the index of case studes - and when we serve those old case studies, do so with a note about heritage? I do think that's a separate issue of course.

@sftim I'm checking in on the case studies omitting thing, but I suspect the answer is "probably not". R


Unable to deploy package.xml.INVALID_OPERATION: Too many files in zip

Expected result
Deployment should be successful.
Package.xml contains around 3.7k components and when SFDX_MDAPI_TEMP environment variable is set temp files are generated of size 17.9 MB.
Actual result
Deployment fails with error : INVALID_OPERATION: Too many files in zip
System Information
@salesforce/cli/2.44.8 darwin-x64 node-v20.13.1
@oclif/plugin-autocomplete 3.0.18 (core)
@oclif/plugin-commands 3.3.4 (core)
@oclif/plugin-help 6.0.22 (core)
@oclif/plugin-not-found 3.1.10 (core)
@oclif/plugin-plugins 5.1.3 (core)
@oclif/plugin-search 1.0.24 (core)
@oclif/plugin-update 4.2.14 (core)
@oclif/plugin-version 2.1.2 (core)
@oclif/plugin-warn-if-update-available 3.0.19 (core)
@oclif/plugin-which 3.1.10 (core)
@salesforce/cli 2.44.8 (core)
apex 3.1.13 (core)
auth 3.6.17 (core)
data 3.4.3 (core)
deploy-retrieve 3.8.3 (core)
info 3.3.3 (core)
limits 3.3.9 (core)
marketplace 1.2.8 (core)
org 4.1.14 (core)
packaging 2.4.5 (core)
schema 3.3.9 (core)
settings 2.2.7 (core)
sobject 1.4.6 (core)
source 3.3.18 (core)
telemetry 3.3.11 (core)
templates 56.2.9 (core)
trust 3.7.3 (core)
user 3.5.11 (core)

SF ENV. VARS.
SF_BINPATH,/Users/****/.local/share/sf/client/bin/sf
SF_AUTOUPDATE_DISABLE,true
SF_DISABLE_AUTOUPDATE,true
SF_UPDATE_INSTRUCTIONS,Use "npm update --global @salesforce/cli" to update npm-based installations.

Windows: false
Shell: zsh
Channel: stable

Diagnostics
:white_check_mark: pass - salesforcedx plugin not installed
:white_check_mark: pass - no linked plugins
:white_check_mark: pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org
:white_check_mark: pass - [@salesforce/plugin-trust] can ping: https://registry.yarnpkg.com
:white_check_mark: pass - [@salesforce/plugin-trust] can ping: https://registry.npmjs.org/
:white_check_mark: pass - using latest or latest-rc CLI version
:white_check_mark: pass - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches apiVersion
:white_check_mark: pass - [@salesforce/plugin-deploy-retrieve] default target DevHub max apiVersion matches default target org max apiVersion
:x: warn - [@salesforce/plugin-deploy-retrieve] sourceApiVersion matches default target org max apiVersion
:white_check_mark: pass - can access: https://test.salesforce.com
:white_check_mark: pass - can access: https://appexchange.salesforce.com/services/data
:white_check_mark: pass - [@salesforce/plugin-auth] CLI supports v2 crypto
:white_check_mark: pass - can access: https://developer.salesforce.com/media/salesforce-cli/sf/channels/stable/sf-win32-x64-buildmanifest

Deployment fails with error : INVALID_OPERATION: Too many files in zip

That error comes from the server and means there are over 10,000 files in the zip file sent with the deploy.  The SF_MDAPI_TEMP_DIR environment variable can be used to see all the files within the zip, but doesn't cause the failure.  It's only to help debug problems.  If you unset that env var you'll see the same error.
See this doc:
https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_metadata.htm?_ga=2.267468238.151983424.1719251687-125335880.1718988572


Create Sessions webpage

Create a Sessions webpage to add notes and workshop/session details.

@Nitesh-thapliyal may i work on this issue


Add celery_worker_last_heartbeat_timestamp gauge

Implements #228.
I tested this manually and it seems to work as expected:
❯ for i in {1..10}; do curl "http://localhost:9808/metrics" -sL | rg last_heartbeat_timestamp | rg -v '^#'; done
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.6771803171352026e+09
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.6771803191380432e+09
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.677180321139897e+09
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.677180321139897e+09
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.677180323141491e+09
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.6771803251429496e+09
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.6771803271442914e+09
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.6771803291466177e+09
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.6771803311494062e+09
celery_worker_last_heartbeat_timestamp{hostname="2f17101080ee"} 1.6771803331514475e+09

I cannot get the test I added to pass locally with the redis or rabbitmq brokers, however. I think it's something to do with my test setup, but it always fails at the is not None assertion, as (no matter how long the sleep is) there's never any samples. It passes fine with the memory broker.

Abandoning as #235 fixed in a different way.


fix(Markdown): nested ordered and unordered list fix

Overview

Fixes a bug with Markdown where ordered list items  that were nested in an unordered list were still getting a bullet point

PR Checklist

[ ] Related to designs:
[x] Related to JIRA ticket: web-1983
[x] I have run this code to verify it works
[x] This PR includes unit tests for the code change
[x] This PR includes testing instructions tests for the code change
[x] The alpha package of this PR is passing end-to-end tests in all relevant Codecademy repositories

Testing Instructions

Navigate to the Markdown component
Observe no visual bugs on the nested ordered/unordered lists

PR Links and Envs
Note: I am using these same PR envs as the Markdown Checkbox PR -- the alpha packages are this PR's (which branches off of Markdown Checkbox)

Repository
PR Link
PR Env

Monolith
Monolith PR
Monolith Env

Portal
Portal Link
Portal Env

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.165-alpha.6b5064.0@codecademy/gamut-labs@33.0.1-alpha.6b5064.0@codecademy/gamut@48.3.1-alpha.6b5064.0@codecademy/monaco@0.6.60-alpha.6b5064.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://62d9ba3eda5ea31639f166d9--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.6.169-alpha.315079.0@codecademy/gamut-labs@33.0.5-alpha.315079.0@codecademy/gamut@49.1.1-alpha.315079.0@codecademy/monaco@0.6.64-alpha.315079.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://62e7eac6767c7565e6545d75--gamut-preview.netlify.appDeploy Logs


Bug report

Bug report
Operating System: Windows 10
MultiBit HD Version:0.1.2

Waiting for my money about 2 days already.
I've removed personally identifying information:

From the screen shots it may be that you've set your transaction fee too low and the miners are ignoring it. Generally using the defaults in the latest version of MultiBit HD 0.1.4 will have a good chance of rapid inclusion in a block. You should upgrade your MultiBit HD to avoid this happening in the future.
Since this is an issue with the block chain and miner acceptance, I'm going to close this issue.

So, I won't get my money back or what?

It'll get into a block eventually but it could be quite a while.

Week, month or how long approximately?

Work out the fee rate you paid and have a look at http://www.cointape.com for network stats

Do I need to write a report to Bitstamp? Or this error means only that I paid not enough fee and that I just have to wait? I've done it before like a 100 times with the same fee and everything was OK.

Fees are a bit annoying with bitcoin at the moment as they make life difficult for everyone.
With the latest MultiBIt HD code there is a slider (in Preferences | Fees) that you can adjust.
If you have an old version the fees weren't adjustable - a month or two ago transaction fees went up x5 which is probably the problem.
You'll just have to be patient I am afraid

Is there a chance that they will never come back?

It's possible that the bitcoin network forgets the transaction "because it is old and they don't like it".
In this case you can just do a "Manage wallet | repair wallet" and you can resync to what is on the blockchain. In this case it will be as if the transaction never happened and you'll see the bitcoin back in your wallet.
A bitcoin transaction is either succesful (i.e. the recipient has the bitcoin) or eventually fails (in which case you have the bitcoin). It can't get lost.

But I've already repaired it and nothing changed.

Everything is fine, I got my money. Thank you a lot for your help.

Good to hear it confirmed ok (eventually)


AI Still Spawning

Even after setting all config values to 0 there are still some ai spawn including some at the military base. Can you make it so that nothing spawns at all ?

You can use another resource with that which resolved it in my case, which is the one linked:
https://forum.cfx.re/t/release-remove-ai-planes-cars-and-spawns-from-airports/225151
Another solution could possibly by replacing the Military Vehicles/Peds to something else or finding a solution to make them invisible or something.


typo in compile from source docs

Summary
Its just a simple typo where loca should say `local
Steps To Reproduce

Go To https://getkong.org/install/source/
The part where it says to install Luarocks 2.30...

./configure \
  --lua-suffix=jit \
  --with-lua=/usr/local/openresty/luajit \
  --with-lua-include=/usr/**loca**/openresty/luajit/include/luajit-2.1

thanks, fixed in https://github.com/Mashape/getkong.org/pull/270


fix: adapt dyno name to Scalingo

Successfully deployed on the test-jvm-common app
Fix #20 / OPSB-228

Please rebase master ;-)


Don't set the ad free cookie on reject all

What does this change?

When a user rejects all, the ad free cookie will no longer be set
Amends the consent Cypress tests to test the new logic
Adds an article option to use the optout adtest

Why?
This avoids us having to use a workaround for opt out advertising to remove the ad free cookie. Reject all is no longer an ad free experience with the introduction of opt out advertising, so this code change reflects that.

I think we can get rid of the whole "ad free cookie reason" concept now couldn't we?

After discussing the consent tests and their reasons for failing, we've decided to skip them for now, and add a ticket to the backlog to revisit them after getting some help from opt-out. Getting these tests working is still important, but not something that will be straightforward to do right now.


Remove SDS Timeout for default and root case

cherry-pick for release 1.7 https://github.com/istio/istio/pull/26001/
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any changes that may affect Istio users.

@williamaronli: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio_release-1.7
c53277548a367ab8221dc081ad4e908bafdaf096
link
/test integ-security-k8s-tests_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@williamaronli: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio_release-1.7
c53277548a367ab8221dc081ad4e908bafdaf096
link
/test integ-security-k8s-tests_istio_release-1.7

integ-telemetry-k8s-tests_istio_release-1.7
c53277548a367ab8221dc081ad4e908bafdaf096
link
/test integ-telemetry-k8s-tests_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@williamaronli: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio_release-1.7
c53277548a367ab8221dc081ad4e908bafdaf096
link
/test integ-security-k8s-tests_istio_release-1.7

integ-telemetry-k8s-tests_istio_release-1.7
c53277548a367ab8221dc081ad4e908bafdaf096
link
/test integ-telemetry-k8s-tests_istio_release-1.7

integ-multicluster-k8s-tests_istio_release-1.7
c53277548a367ab8221dc081ad4e908bafdaf096
link
/test integ-multicluster-k8s-tests_istio_release-1.7

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Blog App: Integration specs for views and fix n+1 problems

In this milestone we @Miliyonayalew and @MarcoOquendoC

Write integration tests with Capybara gem.
Secure app from n+1 problems.
Make sure that the N+1 problem is solved when fetching all posts and their comments for a user.
We Don't use the bullet gem in this exercise - instead analyze the logs as the requirement

Before

After

Add Integration specs
Update README.md

@Miliyonayalew Can you check your slack ?


added evaluation script for PPHumanSeg model

This PR is meant to add an evaluation script for the PP Human segmentation model present in the zoo as mentioned in this issue #119 .
I referred to the val script used by PaddleSeg which can be found here and here and implemented the evaluation script for PPHumanSeg in the method other evaluation scripts on zoo are written.
This is the ouput I'm getting after running the evaluation script :

Let me know if this PR can be improved further. Thanks!

@labeeb-7z Thanks for your contribution! Could you add the evaluation results of fp32 and int8 models on PPhumanseg Readme? You can add the information like the example below:

Results of accuracy evaluation with tools/eval.

Models
Mean Accuracy

PPHumanSeg
0.9023

PPHumanSeg quant
0.xxxx

*: 'quant' stands for 'quantized'.

@WanliZhong here's the output I got for quantized model :

@WanliZhong here's the output I got for quantized model :

There is too much loss of accuracy in the quantized model and we need to consider re-quantizing the model. Thank you for the evaluation script! 👍

For more reference on the evaluation metric you can have a look at the metrics module of PaddleSeg which is used by the evaluation script of PaddleSeg I linked in PR description.

I've moved the *_all variables outside the loop (apologies for that). As for ignoring index and adding 1, I've tried to followed the PaddleSeg implementation. And for the one_hot vectors, again I have implemented the one_hot function of PaddleSeg and followed their evaluation script.
Let me know of any other changes. The updated miou is :

@fengyuentau I've made the suggested changes, Thanks!


Minimal example provided in documentation works on  IOS but does not detect tag on Android

Hi all, advice or help appreciated (ps - awesome tool!)
Following the documentation we have built NFC tag scanning into our app and works perfectly on IOS but on Android the tag is not read (to tag is ever returned from await NfcManager.getTag()
Checked - the phone is NFC capable and the app NFC tools on the phone can read the tag (i.e issue is in our code  - not in the phone).
Checked - AndroidManifest.xml contains:
After the tech is launched by the user tapping the 'scan' button there is no error but scanning the tag does nothing. Pairing the phone with Android studio we see the following in logcat:
2024-09-19 23:05:01.901 14222-14419 ReactNativeNfcManager   org.gearlog.app                      D  isSessionAvailable: false
2024-09-19 23:05:01.905 14222-14419 ReactNativeNfcManager   org.gearlog.app                      D  registerTagEvent
2024-09-19 23:05:01.908 14222-14419 ReactNativeNfcManager   org.gearlog.app                      I  enableForegroundDispatch, enable = true
And then nothing else
Phone is Samsung A10 running Android 11 (it's a cheap old phone we used for physical testing - but should work given that NFC tools works?)
How can we generate more debug or logging to help resolve?
Code follows...

  async scanNFC() {
    try {
      alert('We see this message');
      await NfcManager.requestTechnology(NfcTech.Ndef);

      const tag = await NfcManager.getTag();
    alert('We never see this message');
       -> our tag parsing code follows but we never get to that as never get a tag

    } catch (ex) {
     	-> our error alerting

      );
    } finally {
        NfcManager.cancelTechnologyRequest();
    }
  }

To add further to this we have boiled the code down to the absolute minimum and the basic issue (Android) only is that 'await NfcManager.getTag()' simply never resolves. The NFCManager is running and once the app is on that screen the normal android phone default response to a nearby tag no longer occurs - so clearly the app has grabbed NFC as the manager starts - but when an tag is close NfcManager.getTag() does not resolve. Could this be something to do with how android sends the tag event on older phones (A10 running Android 11 which can run the app NFC tools just fine)

To add further to this we have also tried on a Google Pixel 5 running Android 14 with the exact same result. In summary the most basic minimal example of using this library works perfectly on an iOS device but does not detect the same tag either on Android 10 or Android 14 with the issue being that that 'await NfcManager.getTag()' simply never resolves. This leaves us confused as this cannot be the case and there must be many users developing against Android with this device and yet we cannot get a couple of code lines of minimal example to work? Any suggestions much appreciated :)

To futher add to this we have also tried the below method of using NFCmanager on Adroid with the exact same result - the await for the tag never resolves....
    NfcManager.setEventListener(NfcEvents.DiscoverTag, tag => {
         alert("tag found");

       });
       await NfcManager.registerTagEvent();

hey @kitkline which kind of card are you using?
what is the output of reading card in iPhone?
is there any information about the card that you are trying to read?


[Google Bard] ...

Extension
https://www.raycast.com/EvanZhouDev/raycast-bard-ai
Description
Error:

Steps To Reproduce

Open bard
Type something
And you get the error.

Current Behaviour
No response
Expected Behaviour
No response

@immortalsantee I think the Google Bard extension, which uses cookies, won't work effectively anymore. Luckily, you can now install the Google PaLM extension, which has the same functionality as Google Bard, but is more reliable and faster.
You can check it out here


Added note to readme.

Why? Because why not.

Stop.

I forgot that this is zig, not jai.


sslscan: 2.0.15 -> 2.0.16, ssldump: 1.6 -> 1.7

Description of changes

Things done

Built on platform(s)

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

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

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

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

[ ] Fits CONTRIBUTING.md.

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

2 packages built:

ssldump
sslscan


doc: Add Cilium container networking control flow

This patch adds a control flow diagram that explains the cilium
container networking IP address Management with IPAM and with
default Kubernetes Cluster Node Pool CIDR.
Signed-off-by: Swaminathan Vasudevan<EMAIL_ADDRESS>

This change is

Coverage decreased (-0.02%) to 45.543% when pulling 5fca980a66f5e475841c8e2aefc9861f03b6829c on soumynathan:Add-cilium-address-management-control-flow into 08297854e9a3135b1f8885e31c0e917d4b167c95 on cilium:master.

Addressed review comments.

test-docs-please

Docs test failed:
14:46:29  Please fix the following documentation warnings:
14:46:29  /srv/Documentation/concepts/ipam/index.rst:: WARNING: image file not readable: concepts/ipam/cilium_container_networking_control_flow.png

You may want to try using the local make test-docs target to validate this if you haven't already.

Docs test failed:
14:46:29  Please fix the following documentation warnings:
14:46:29  /srv/Documentation/concepts/ipam/index.rst:: WARNING: image file not readable: concepts/ipam/cilium_container_networking_control_flow.png

You may want to try using the local make test-docs target to validate this if you haven't already.

Sure will check it out.

test-docs-please

@soumynathan Too late to the party, but could you push a source code (?) for the png, so that we can update the diagram in the future?

@brb what change do you need to make, let me know I can churn it out.

At the moment I don't have any change in mind, but if we need to do a change in the future, then the source code will be handy.


CTRL + Enter not working in Chrome 43 for WIndows.

CTRL + Enter key combo to advance does not work in Chrome v. 43.0.2357.124 on Windows 7.

works for me in Chrome v. 43.0.2357.124 m (laptop) on Windows 7.

There are already quite a few issues regarding , namely #921 and #912.

Thanks for reporting this. I'm closing this as a duplicate.


[python3] Build error

Copy issue body from /vcpkg/installed/vcpkg/issue_body.md

Package: python3:arm64-osx -> 3.11.4#4
Host Environment

Host: arm64-osx
Compiler: AppleClang <IP_ADDRESS>30022
vcpkg-tool version: 2023-08-09-9990a4c9026811a312cb2af78bf77f3d9d288416
vcpkg-scripts version: 1384becef 2023-09-05 (6 hours ago)

To Reproduce
vcpkg install boost
Failure logs
-- Using cached python-cpython-v3.11.4.tar.gz.
-- Cleaning sources at /Users/koshkaaa/Documents/3rd_Party/vcpkg/buildtrees/python3/src/v3.11.4-ce6efd80c0.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /Users/koshkaaa/Documents/3rd_Party/vcpkg/downloads/python-cpython-v3.11.4.tar.gz
-- Applying patch 0001-only-build-required-projects.patch
-- Applying patch 0003-use-vcpkg-zlib.patch
-- Applying patch 0004-devendor-external-dependencies.patch
-- Applying patch 0005-dont-copy-vcruntime.patch
-- Applying patch 0008-python.pc.patch
-- Applying patch 0010-dont-skip-rpath.patch
-- Applying patch 0012-force-disable-curses.patch
-- Applying patch 0014-fix-get-python-inc-output.patch
-- Applying patch 0015-dont-use-WINDOWS-def.patch
-- Applying patch 0002-static-library.patch
-- Using source at /Users/koshkaaa/Documents/3rd_Party/vcpkg/buildtrees/python3/src/v3.11.4-ce6efd80c0.clean
-- Getting CMake variables for arm64-osx-dbg
-- Getting CMake variables for arm64-osx-rel
CMake Error at scripts/cmake/vcpkg_configure_make.cmake:625 (message):
  python3 requires autoconf from the system package manager (example: "sudo
  apt-get install autoconf")
Call Stack (most recent call first):
  ports/python3/portfile.cmake:257 (vcpkg_configure_make)
  scripts/ports.cmake:147 (include)

Run brew install autoconf

... and autoconf-archive and pkgconfig

CMake Error at scripts/cmake/vcpkg_configure_make.cmake:625 (message):
  python3 requires autoconf from the system package manager (example: "sudo
  apt-get install autoconf")


Fix build by ordering the linked libraries.

With wl-asneeded as default and UglyLogStubs using inkevent, linking them in the wrong order
makes the latter stripped by the linker

[approve ci]

clang format successful! https://ci.trafficserver.apache.org/job/clang-format-github/33/

RAT check successful! https://ci.trafficserver.apache.org/job/RAT-github/46/

the patch has been added in Ubuntu
https://launchpad.net/ubuntu/+source/trafficserver/7.0.0-4ubuntu1
and should fix this failure
https://launchpad.net/ubuntu/+source/trafficserver/7.0.0-4

AU check failed! https://ci.trafficserver.apache.org/job/autest-github/32/

FreeBSD11 build successful! https://ci.trafficserver.apache.org/job/freebsd-github/1728/

Linux build successful! https://ci.trafficserver.apache.org/job/linux-github/1623/

Intel CC build successful! https://ci.trafficserver.apache.org/job/icc-github/158/

clang-analyzer build successful! https://ci.trafficserver.apache.org/job/clang-analyzer-github/290/


add fine-tune cli in scripts

A fine-tune cli option is needed to tune the algorithms and return the best value. Skopt seems a safe choice (?). The values that are passed through as optional algorithm arguments (--a-) are those that should be tunes. It would be helpful to get these arguemnts as a range (such that the way space of search is defined in skopt).

We already changed the argument delivering from --a-<arg> value form to arg arg:value in front of the object name so the plan for adding fine-tuning should have some changes. Also we need fine-tuning for global arguments such as learning rate.

It seems that the easiest way to handle fine-tuning for both the general hyper-parmeters and object ones (e.g., mu in algorithm class), it is better to have a fine_tune method defined for the algorithm class.


Implement standalone chat detection API

Description
As a followup to #195, as an orchestrator developer, I want to implement the changes for the updated API, so that I can provide standalone detections on chat. This endpoint is designed for detectors working on full chat histories
Tasks

Implement standalone detector endpoint (accepting chat history request) in orchestrator
Add http client for detection_chat
Test with dummy detector that works on full chat histories

Acceptance Criteria

[ ] Unit tests cover new/changed code
[ ] Examples build against new/changed code
[ ] READMEs are updated
[ ] Type of semantic version change is identified

The API wasn't very clear o a few things to me, so I'm looking here.

Do we need to support deprecated fields (Assistant message's function_call, Function message)?

Will we support all modalities for this endpoint? e.g.: For User messages' content array variant, will we support both text and image?


Enhanced FileOrCreate description

Signed-off-by: wawa0210<EMAIL_ADDRESS>from kubernetes/kubernetes#87113
Currently FileCreate mount files may cause confusion for users due to problems with the parent directory. It does not create a parent directory.

/hold https://github.com/kubernetes/website/pull/19442

/hold  cancel

/assign @markthink


Keep hierarchical assets directory structure

Issue summary
When organizing image and font assets in subdirectories their paths are flattened eg. resources/assets/images/foo/bar.png -> dist/assets/images/bar.png
With this PR it becomes dist/assets/images/foo/bar.png
Solution
At first I thought this was a bug in the laravel-mix-copy-watched package (invalid bug report) but turns out it works as intended and keeping the hierarchy is actually an additional option.
I thought I'd open up a PR as others might encounter this as well. This is how it worked in sage 9, no?
Feel free to close this if you don't agree that this is a better default.

It is intended for the paths to be flattened and was the same behavior on Sage 9 (AFAIK).

Just tested to make sure, Sage 9 didn't flatten the path.

Gotcha.
In this case, it is intended to be flattened.

@Log1x What happens if there is more than one file with the same file name? Flattening would lead to a file name collision. What is the intended solution in this case?

The files and folders inside of the asset folders are not flattened. They just don't live in an asset directory inside of dist.

@Log1x Thank you for the clarification, I misunderstood the original intent of the PR.

For what it's worth I just SSHed into a live Sage 9 project (rebuilt this morning) and checked out the dist folder. Output of tree:
.
├── assets.json
├── images
│   ├── new-florida-majority-splash_36e8a018.jpg
│   ├── new-fm-logo_c9632e96.png
│   └── nfm-horizontal_8bf85334.png
├── scripts
│   ├── customizer_f67555a9.js
│   └── main_f67555a9.js
└── styles
    └── main_f67555a9.css

For what it's worth I just SSHed into a live Sage 9 project (rebuilt this morning) and checked out the dist folder.

This doesnt match my test in the current master branch O.o
$ tree resources/assets/images/                                                                                5s 598ms
resources/assets/images/
└── test
    └── logo.png

1 directory, 1 file
$ tree dist/images/
dist/images/
└── test
    └── logo.png

@Log1x What happens if there is more than one file with the same file name? Flattening would lead to a file name collision. What is the intended solution in this case?

The files and folders inside of the asset folders are not flattened. They just don't live in an asset directory inside of dist. It is more or less a redundant folder.

This is an issue in dist though because of the flattening.
 $ tree resources/assets/images/
resources/assets/images/
├── logo.png
└── test
    └── logo.png

1 directory, 2 files
$ tree dist/images/
dist/images/
└── logo.png

I see what you are saying now. You have me initially confused as it seemed like you were suggesting that compiled assets should live in an assets folder within dist which is not the case (nor was it on Sage 9).
You're right about copyWatched flattening the directories, though.
This can be fixed by passing ** to the from directory like so:
mix.copyWatched('resources/assets/fonts/**', 'public/fonts')
   .copyWatched('resources/assets/images/**', 'public/images');

Oops, just re-read my issue, sorry about the confusion

The modified version you merged doesn't fix this issue.
$ tree resources/assets/images/
resources/assets/images/
├── bar
│   ├── baz
│   │   └── foo.png
│   └── foo.png
└── foo.png

$ tree dist/images/
dist/images/
└── foo.png


SSA optimization is ineffective when a function has loops

Problem
This code:
struct EnumEmulation {
    a: Option<Field>,
    b: Option<Field>,
    c: Option<Field>,
}

unconstrained fn main() -> pub Field {
    let mut emulated_enum = EnumEmulation { a: Option::some(1), b: Option::none(), c: Option::none() };

    for _ in 0..1 {
        assert_eq(emulated_enum.a.unwrap(), 1);
    }

    emulated_enum.a = Option::some(2);
    emulated_enum.a.unwrap()
}

is functionally the same as
struct EnumEmulation {
    a: Option<Field>,
    b: Option<Field>,
    c: Option<Field>,
}

unconstrained fn main() -> pub Field {
    let mut emulated_enum = EnumEmulation { a: Option::some(1), b: Option::none(), c: Option::none() };

    assert_eq(emulated_enum.a.unwrap(), 1);

    emulated_enum.a = Option::some(2);
    emulated_enum.a.unwrap()
}

However, their optimized SSAs are completely different
After Dead Instruction Elimination:
brillig fn main f0 {
  b0():
    v111 = allocate
    store u1 1 at v111
    v112 = allocate
    store Field 1 at v112
    v113 = allocate
    store u1 0 at v113
    v114 = allocate
    store Field 0 at v114
    v115 = allocate
    store u1 0 at v115
    v116 = allocate
    store Field 0 at v116
    jmp b1(u64 0)
  b1(v13: u64):
    v117 = eq v13, u64 0
    jmpif v117 then: b2, else: b3
  b2():
    v124 = load v111
    v125 = load v112
    constrain v124 == u1 1
    constrain v125 == Field 1
    v131 = add v13, u64 1
    jmp b1(v131)
  b3():
    v120 = load v113
    v121 = load v114
    v122 = load v115
    v123 = load v116
    store u1 1 at v111
    store Field 2 at v112
    store v120 at v113
    store v121 at v114
    store v122 at v115
    store v123 at v116
    return Field 2
}

vs
After Dead Instruction Elimination:
brillig fn main f0 {
  b0():
    return Field 2
}

I think mem2reg is failing to promote to reg values that are used across multiple blocks
Happy Case
Ideally, the two programs should generate the same optimized SSA
Project Impact
Nice to have
Impact Context
This generates a big blowup in bytecode size in aztec's public functions. See https://github.com/AztecProtocol/aztec-packages/pull/5153
Workaround
Yes
Workaround Description
We can reduce the amount of unused references by using traits instead of emulating enums via options, this is the case for the context enum, that we could transform into a context trait.
Additional Context
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response

I think mem2reg is failing to promote to reg values that are used across multiple blocks

mem2reg is one of the only passes that does work well between multiple blocks. One obvious missing case here is that we're not unrolling the loop since we avoid doing so completely in brillig since they can be runtime bound.

@sirasistant how common are small loops like this? I'm also not certain how much unrolling them will help since they will use non-constant values in the loop which means instructions from each iteration will still remain in the code. This example benefits greatly from loop unrolling mostly because there are no inputs to main so the loop can be removed entirely.
If a loop is normally 5 iterations which contain 4 instructions each, unrolling even that small loop to get 20 instructions is more questionable.

@sirasistant if you're just looking at why the loop isn't being unrolled that'd be the loop unrolling pass which is currently completely skipped for unconstrained code.

I know, it's fine for it not to be unrolled (even in the case the bounds are known at compile time, unrolled loops can lead to bigger bytecode), I meant what optimization steps are not acting due to the presence of the loop itself

I'm looking at the SSA and it seems that mem2reg is not identifying that the loads are known:
With loop:
After Inlining:
brillig fn main f0 {
  b0():
    v7 = allocate
    store u1 1 at v7
    v8 = allocate
    store Field 1 at v8
    v9 = allocate
    store u1 0 at v9
    v10 = allocate
    store Field 0 at v10
    v11 = allocate
    store u1 0 at v11
    v12 = allocate
    store Field 0 at v12
    jmp b1(u64 0)
  b1(v13: u64):
    v15 = eq v13, u64 0
    jmpif v15 then: b2, else: b3
  b2():
    v31 = load v7
    v32 = load v8
    v33 = load v9
    v34 = load v10
    v35 = load v11
    v36 = load v12
    constrain v31 == u1 1
    v38 = eq v32, Field 1
    constrain v32 == Field 1
    v40 = add v13, u64 1
    jmp b1(v40)
  b3():
    v16 = load v7
    v17 = load v8
    v18 = load v9
    v19 = load v10
    v20 = load v11
    v21 = load v12
    store u1 1 at v7
    store Field 2 at v8
    store v18 at v9
    store v19 at v10
    store v20 at v11
    store v21 at v12
    v24 = load v7
    v25 = load v8
    v26 = load v9
    v27 = load v10
    v28 = load v11
    v29 = load v12
    constrain v24 == u1 1
    return v25
}

After Mem2Reg:
brillig fn main f0 {
  b0():
    v41 = allocate
    store u1 1 at v41
    v42 = allocate
    store Field 1 at v42
    v43 = allocate
    store u1 0 at v43
    v44 = allocate
    store Field 0 at v44
    v45 = allocate
    store u1 0 at v45
    v46 = allocate
    store Field 0 at v46
    jmp b1(u64 0)
  b1(v13: u64):
    v47 = eq v13, u64 0
    jmpif v47 then: b2, else: b3
  b2():
    v60 = load v41
    v61 = load v42
    v62 = load v43
    v63 = load v44
    v64 = load v45
    v65 = load v46
    constrain v60 == u1 1
    v66 = eq v61, Field 1
    constrain v61 == Field 1
    v67 = add v13, u64 1
    jmp b1(v67)
  b3():
    v48 = load v41
    v49 = load v42
    v50 = load v43
    v51 = load v44
    v52 = load v45
    v53 = load v46
    store u1 1 at v41
    store Field 2 at v42
    store v50 at v43
    store v51 at v44
    store v52 at v45
    store v53 at v46
    return Field 2
}

without loop

After Inlining:
brillig fn main f0 {
  b0():
    v7 = allocate
    store u1 1 at v7
    v8 = allocate
    store Field 1 at v8
    v9 = allocate
    store u1 0 at v9
    v10 = allocate
    store Field 0 at v10
    v11 = allocate
    store u1 0 at v11
    v12 = allocate
    store Field 0 at v12
    v13 = load v7
    v14 = load v8
    v15 = load v9
    v16 = load v10
    v17 = load v11
    v18 = load v12
    constrain v13 == u1 1
    v20 = eq v14, Field 1
    constrain v14 == Field 1
    v21 = load v7
    v22 = load v8
    v23 = load v9
    v24 = load v10
    v25 = load v11
    v26 = load v12
    store u1 1 at v7
    store Field 2 at v8
    store v23 at v9
    store v24 at v10
    store v25 at v11
    store v26 at v12
    v29 = load v7
    v30 = load v8
    v31 = load v9
    v32 = load v10
    v33 = load v11
    v34 = load v12
    constrain v29 == u1 1
    return v30
}

After Mem2Reg:
brillig fn main f0 {
  b0():
    v36 = allocate
    v37 = allocate
    v38 = allocate
    v39 = allocate
    v40 = allocate
    v41 = allocate
    return Field 2
}

I guess the ideal SSA mem2reg could output in this case given that I don't think any pass removes loops with empty bodies, is something like this:

After Mem2Reg:
brillig fn main f0 {
  b0():
    v36 = allocate
    v37 = allocate
    v38 = allocate
    v39 = allocate
    v40 = allocate
    v41 = allocate
    jmp b1(u64 0)
  b1(v13: u64):
    v47 = eq v13, u64 0
    jmpif v47 then: b2, else: b3
  b2():
    v67 = add v13, u64 1
    jmp b1(v67)
  b3():
    return Field 2
}

This might be related, poseidon is a bit unusable right now in brillig:
This code:
unconstrained fn main() -> pub Field {
    dep::std::hash::poseidon2::Poseidon2::hash([0; 2], 2)
}

Generates this huge SSA after optimization
After Dead Instruction Elimination:
brillig fn main f0 {
  b0():
    v1170 = allocate
    v1171 = allocate
    v1172 = allocate
    v1173 = allocate
    store [Field 0, Field 0, Field 0] at v1170
    store [Field 0, Field 0, Field 0, Field 2⁶⁵] at v1171
    store u32 0 at v1172
    store u1 0 at v1173
    v1174 = allocate
    store [Field 0, Field 0, Field 0] at v1174
    v1175 = allocate
    store [Field 0, Field 0, Field 0, Field 2⁶⁵] at v1175
    v1176 = allocate
    store u32 0 at v1176
    v1177 = allocate
    store u1 0 at v1177
    jmp b2(u64 0)
  b2(v32: u64):
    v1178 = lt v32, u64 2
    jmpif v1178 then: b3, else: b4
  b3():
    v1305 = lt v32, u64 2
    jmpif v1305 then: b29, else: b30
  b29():
    v1307 = array_get [Field 0, Field 0], index v32
    v1308 = load v1174
    inc_rc v1308
    store v1308 at v1174
    v1309 = load v1175
    inc_rc v1309
    store v1309 at v1175
    v1311 = load v1177
    v1312 = not v1311
    v1313 = load v1176
    v1315 = eq v1313, u32 3
    v1316 = mul v1312, v1315
    jmpif v1316 then: b31, else: b32
  b31():
    inc_rc v1308
    store v1308 at v1174
    inc_rc v1309
    store v1309 at v1175
    jmp b39(u32 0)
  b39(v275: u32):
    v1340 = lt v275, u32 3
    jmpif v1340 then: b40, else: b41
  b40():
    v1390 = load v1176
    v1392 = lt v275, v1390
    v1393 = not v1392
    jmpif v1393 then: b48, else: b49
  b48():
    v1395 = load v1174
    v1396 = load v1175
    v1397 = load v1176
    v1398 = load v1177
    v1399 = cast v275 as u64
    v1400 = array_set v1395, index v1399, value Field 0
    store v1400 at v1174
    store v1396 at v1175
    store v1397 at v1176
    store v1398 at v1177
    jmp b49()
  b49():
    v1394 = add v275, u32 1
    jmp b39(v1394)
  b41():
    jmp b42(u32 0)
  b42(v277: u32):
    v1341 = lt v277, u32 3
    jmpif v1341 then: b43, else: b44
  b43():
    v1369 = load v1174
    v1370 = load v1175
    v1371 = load v1176
    v1372 = load v1177
    v1374 = load v1175
    v1377 = cast v277 as u64
    v1378 = array_get v1374, index v1377
    v1379 = load v1174
    v1383 = array_get v1379, index v1377
    v1384 = add v1378, v1383
    v1385 = array_set v1370, index v1377, value v1384
    store v1369 at v1174
    store v1385 at v1175
    store v1371 at v1176
    store v1372 at v1177
    v1387 = add v277, u32 1
    jmp b42(v1387)
  b44():
    v1342 = load v1174
    v1344 = load v1176
    v1345 = load v1177
    v1347 = load v1175
    v1350 = call poseidon2_permutation(v1347, u32 4)
    inc_rc v1350
    store v1342 at v1174
    store v1350 at v1175
    store v1344 at v1176
    store v1345 at v1177
    v1351 = allocate
    store [Field 0, Field 0, Field 0] at v1351
    jmp b45(u32 0)
  b45(v290: u32):
    v1352 = lt v290, u32 3
    jmpif v1352 then: b46, else: b47
  b46():
    v1359 = load v1351
    v1361 = load v1175
    v1364 = cast v290 as u64
    v1365 = array_get v1361, index v1364
    v1366 = array_set v1359, index v1364, value v1365
    store v1366 at v1351
    v1368 = add v290, u32 1
    jmp b45(v1368)
  b47():
    v1354 = load v1174
    dec_rc v1354
    v1355 = load v1175
    dec_rc v1355
    v1357 = load v1177
    v1358 = array_set v1354, index u64 0, value v1307
    store v1358 at v1174
    store v1355 at v1175
    store u32 1 at v1176
    store v1357 at v1177
    jmp b38()
  b38():
    v1327 = load v1174
    dec_rc v1327
    store v1327 at v1174
    v1328 = load v1175
    dec_rc v1328
    store v1328 at v1175
    jmp b30()
  b30():
    v1306 = add v32, u64 1
    jmp b2(v1306)
  b32():
    v1318 = load v1177
    v1319 = not v1318
    v1320 = load v1176
    v1322 = eq v1320, u32 3
    v1323 = not v1322
    v1324 = mul v1319, v1323
    jmpif v1324 then: b33, else: b34
  b33():
    v1332 = load v1176
    v1333 = load v1177
    v1334 = load v1176
    v1336 = cast v1334 as u64
    v1337 = array_set v1308, index v1336, value v1307
    v1339 = add v1332, u32 1
    range_check v1339 to 32 bits
    store v1337 at v1174
    store v1309 at v1175
    store v1339 at v1176
    store v1333 at v1177
    jmp b37()
  b37():
    jmp b38()
  b34():
    v1326 = load v1177
    jmpif v1326 then: b35, else: b36
  b35():
    v1331 = array_set v1308, index u64 0, value v1307
    store v1331 at v1174
    store v1309 at v1175
    store u32 1 at v1176
    store u1 0 at v1177
    jmp b36()
  b36():
    jmp b37()
  b4():
    v1179 = load v1174
    inc_rc v1179
    store v1179 at v1174
    v1180 = load v1175
    inc_rc v1180
    store v1180 at v1175
    v1182 = load v1177
    v1183 = load v1176
    v1185 = eq v1183, u32 0
    v1186 = mul v1182, v1185
    jmpif v1186 then: b6, else: b7
  b6():
    store v1179 at v1174
    store v1180 at v1175
    store u32 0 at v1176
    store u1 0 at v1177
    jmp b7()
  b7():
    v1188 = load v1177
    v1189 = not v1188
    jmpif v1189 then: b8, else: b9
  b8():
    inc_rc v1179
    store v1179 at v1174
    inc_rc v1180
    store v1180 at v1175
    jmp b15(u32 0)
  b15(v108: u32):
    v1228 = lt v108, u32 3
    jmpif v1228 then: b16, else: b17
  b16():
    v1291 = load v1176
    v1293 = lt v108, v1291
    v1294 = not v1293
    jmpif v1294 then: b24, else: b25
  b24():
    v1296 = load v1174
    v1297 = load v1175
    v1298 = load v1176
    v1299 = load v1177
    v1300 = cast v108 as u64
    v1301 = array_set v1296, index v1300, value Field 0
    store v1301 at v1174
    store v1297 at v1175
    store v1298 at v1176
    store v1299 at v1177
    jmp b25()
  b25():
    v1295 = add v108, u32 1
    jmp b15(v1295)
  b17():
    jmp b18(u32 0)
  b18(v110: u32):
    v1229 = lt v110, u32 3
    jmpif v1229 then: b19, else: b20
  b19():
    v1270 = load v1174
    v1271 = load v1175
    v1272 = load v1176
    v1273 = load v1177
    v1275 = load v1175
    v1278 = cast v110 as u64
    v1279 = array_get v1275, index v1278
    v1280 = load v1174
    v1284 = array_get v1280, index v1278
    v1285 = add v1279, v1284
    v1286 = array_set v1271, index v1278, value v1285
    store v1270 at v1174
    store v1286 at v1175
    store v1272 at v1176
    store v1273 at v1177
    v1288 = add v110, u32 1
    jmp b18(v1288)
  b20():
    v1230 = load v1174
    v1232 = load v1176
    v1233 = load v1177
    v1235 = load v1175
    v1238 = call poseidon2_permutation(v1235, u32 4)
    inc_rc v1238
    store v1230 at v1174
    store v1238 at v1175
    store v1232 at v1176
    store v1233 at v1177
    v1239 = allocate
    store [Field 0, Field 0, Field 0] at v1239
    jmp b21(u32 0)
  b21(v125: u32):
    v1240 = lt v125, u32 3
    jmpif v1240 then: b22, else: b23
  b22():
    v1260 = load v1239
    v1262 = load v1175
    v1265 = cast v125 as u64
    v1266 = array_get v1262, index v1265
    v1267 = array_set v1260, index v1265, value v1266
    store v1267 at v1239
    v1269 = add v125, u32 1
    jmp b21(v1269)
  b23():
    v1241 = load v1239
    v1242 = load v1174
    dec_rc v1242
    v1243 = load v1175
    dec_rc v1243
    inc_rc v1241
    v1244 = load v1176
    store v1242 at v1174
    store v1243 at v1175
    store v1244 at v1176
    store u1 1 at v1177
    jmp b26(u32 0)
  b26(v180: u32):
    v1246 = lt v180, u32 3
    jmpif v1246 then: b27, else: b28
  b27():
    v1251 = load v1174
    v1252 = load v1175
    v1253 = load v1176
    v1254 = load v1177
    v1255 = cast v180 as u64
    v1256 = array_get v1241, index v1255
    v1257 = array_set v1251, index v1255, value v1256
    store v1257 at v1174
    store v1252 at v1175
    store v1253 at v1176
    store v1254 at v1177
    v1259 = add v180, u32 1
    jmp b26(v1259)
  b28():
    v1247 = load v1174
    v1248 = load v1175
    v1250 = load v1177
    store v1247 at v1174
    store v1248 at v1175
    store u32 3 at v1176
    store v1250 at v1177
    jmp b9()
  b9():
    v1190 = load v1174
    v1194 = array_get v1190, index u64 0
    jmp b10(u32 1)
  b10(v58: u32):
    v1195 = lt v58, u32 3
    jmpif v1195 then: b11, else: b12
  b11():
    v1210 = load v1176
    v1212 = lt v58, v1210
    jmpif v1212 then: b13, else: b14
  b13():
    v1214 = load v1174
    v1215 = load v1175
    v1216 = load v1176
    v1217 = load v1177
    v1218 = sub v58, u32 1
    range_check v1218 to 32 bits
    v1219 = load v1174
    v1223 = cast v58 as u64
    v1224 = array_get v1219, index v1223
    v1225 = cast v1218 as u64
    v1226 = array_set v1214, index v1225, value v1224
    store v1226 at v1174
    store v1215 at v1175
    store v1216 at v1176
    store v1217 at v1177
    jmp b14()
  b14():
    v1213 = add v58, u32 1
    jmp b10(v1213)
  b12():
    v1196 = load v1174
    v1197 = load v1175
    v1199 = load v1177
    v1202 = load v1176
    v1204 = sub v1202, u32 1
    range_check v1204 to 32 bits
    v1205 = cast v1204 as u64
    v1206 = array_set v1196, index v1205, value Field 0
    store v1204 at v1176
    store v1199 at v1177
    dec_rc v1206
    store v1206 at v1174
    dec_rc v1197
    store v1197 at v1175
    return v1194
}

Whereas on acir
After Dead Instruction Elimination:
acir fn main f0 {
  b0():
    enable_side_effects u1 0
    enable_side_effects u1 0
    enable_side_effects u1 1
    enable_side_effects u1 0
    enable_side_effects u1 0
    enable_side_effects u1 1
    enable_side_effects u1 1
    enable_side_effects u1 1
    v4039 = call poseidon2_permutation([Field 0, Field 0, Field 0, Field 2⁶⁵], u32 4)
    inc_rc v4039
    v4041 = array_get v4039, index u64 0
    dec_rc v4039
    enable_side_effects u1 1
    enable_side_effects u1 1
    return v4041
}

@sirasistant I haven't looked into that SSA in-depth but what makes you think it is underoptimized? Comparing brillig to acir generation isn't the best comparison since Acir will always have all loops unrolled and if blocks flattened. With no blocks remaining many optimizations like mem2reg become trivial. So it's generally expected that Acir will be much simpler and smaller especially if loop bounds are small or if it uses all constant values.

It's just that the SSA seemed quite large after optimization, I only saw a raduction in instructions of ~500 after inlining to ~300 after all the optimization pipeline, with all values in the program being constant. We are going to switch from pedersen to poseidon in aztec, let's see if the faster execution of poseidon2 compensates the more complex SSA generated (pedersen hash is a single opcode)

Interesting, I tried forcing trying to unroll loops in brillig to test how it'd look like with unrolled loops and it seems like it didn't help much reducing instruction count:

After Dead Instruction Elimination:
brillig fn main f0 {
  b0():
    v2020 = allocate
    v2021 = allocate
    v2022 = allocate
    v2023 = allocate
    store [Field 0, Field 0, Field 0] at v2020
    store [Field 0, Field 0, Field 0, Field 2⁶⁵] at v2021
    store u32 0 at v2022
    store u1 0 at v2023
    v2024 = allocate
    v2025 = allocate
    v2026 = allocate
    store u32 0 at v2026
    v2027 = allocate
    store u1 0 at v2027
    store [Field 0, Field 0, Field 0] at v2024
    store [Field 0, Field 0, Field 0, Field 2⁶⁵] at v2025
    jmpif u1 0 then: b55, else: b56
  b55():
    store [Field 0, Field 0, Field 0] at v2024
    store [Field 0, Field 0, Field 0, Field 2⁶⁵] at v2025
    jmpif u1 1 then: b120, else: b121
  b120():
    store [Field 0, Field 0, Field 0] at v2024
    store [Field 0, Field 0, Field 0, Field 2⁶⁵] at v2025
    store u32 0 at v2026
    store u1 0 at v2027
    jmp b121()
  b121():
    jmpif u1 1 then: b125, else: b126
  b125():
    v2219 = load v2024
    v2220 = load v2025
    v2221 = array_set v2219, index u64 1, value Field 0
    store v2221 at v2024
    store v2220 at v2025
    store u32 0 at v2026
    store u1 0 at v2027
    jmp b126()
  b126():
    jmpif u1 1 then: b130, else: b131
  b130():
    v2216 = load v2024
    v2217 = load v2025
    v2218 = array_set v2216, index u64 2, value Field 0
    store v2218 at v2024
    store v2217 at v2025
    store u32 0 at v2026
    store u1 0 at v2027
    jmp b131()
  b131():
    v2192 = load v2024
    v2193 = load v2025
    v2195 = load v2025
    v2196 = array_get v2195, index u64 0
    v2197 = load v2024
    v2199 = array_get v2197, index u64 0
    v2200 = add v2196, v2199
    v2201 = array_set v2193, index u64 0, value v2200
    v2202 = array_get v2201, index u64 1
    v2203 = array_get v2192, index u64 1
    v2204 = add v2202, v2203
    v2205 = array_set v2201, index u64 1, value v2204
    v2206 = array_get v2205, index u64 2
    v2207 = array_get v2192, index u64 2
    v2208 = add v2206, v2207
    v2209 = array_set v2205, index u64 2, value v2208
    v2210 = call poseidon2_permutation(v2209, u32 4)
    inc_rc v2210
    v2211 = allocate
    v2212 = array_get v2210, index u64 0
    v2213 = array_get v2210, index u64 1
    v2214 = array_get v2210, index u64 2
    store [v2212, v2213, v2214] at v2211
    dec_rc v2192
    dec_rc v2210
    v2215 = array_set v2192, index u64 0, value Field 0
    store v2215 at v2024
    store v2210 at v2025
    store u32 1 at v2026
    store u1 0 at v2027
    jmp b62()
  b62():
    v2028 = load v2024
    dec_rc v2028
    v2029 = load v2025
    dec_rc v2029
    inc_rc v2028
    store v2028 at v2024
    inc_rc v2029
    store v2029 at v2025
    v2031 = load v2026
    v2032 = eq v2031, u32 3
    jmpif v2032 then: b79, else: b80
  b79():
    inc_rc v2028
    store v2028 at v2024
    inc_rc v2029
    store v2029 at v2025
    v2145 = load v2026
    v2146 = lt u32 0, v2145
    v2147 = not v2146
    jmpif v2147 then: b103, else: b104
  b103():
    v2186 = load v2026
    v2187 = array_set v2028, index u64 0, value Field 0
    store v2187 at v2024
    store v2029 at v2025
    store v2186 at v2026
    store u1 0 at v2027
    jmp b104()
  b104():
    v2149 = load v2026
    v2150 = lt u32 1, v2149
    v2151 = not v2150
    jmpif v2151 then: b108, else: b109
  b108():
    v2183 = load v2024
    v2184 = load v2026
    v2185 = array_set v2183, index u64 1, value Field 0
    store v2185 at v2024
    store v2029 at v2025
    store v2184 at v2026
    store u1 0 at v2027
    jmp b109()
  b109():
    v2153 = load v2026
    v2154 = lt u32 2, v2153
    v2155 = not v2154
    jmpif v2155 then: b113, else: b114
  b113():
    v2180 = load v2024
    v2181 = load v2026
    v2182 = array_set v2180, index u64 2, value Field 0
    store v2182 at v2024
    store v2029 at v2025
    store v2181 at v2026
    store u1 0 at v2027
    jmp b114()
  b114():
    v2156 = load v2024
    v2160 = array_get v2029, index u64 0
    v2161 = load v2024
    v2163 = array_get v2161, index u64 0
    v2164 = add v2160, v2163
    v2165 = array_set v2029, index u64 0, value v2164
    v2166 = array_get v2165, index u64 1
    v2167 = array_get v2156, index u64 1
    v2168 = add v2166, v2167
    v2169 = array_set v2165, index u64 1, value v2168
    v2170 = array_get v2169, index u64 2
    v2171 = array_get v2156, index u64 2
    v2172 = add v2170, v2171
    v2173 = array_set v2169, index u64 2, value v2172
    v2174 = call poseidon2_permutation(v2173, u32 4)
    inc_rc v2174
    v2175 = allocate
    v2176 = array_get v2174, index u64 0
    v2177 = array_get v2174, index u64 1
    v2178 = array_get v2174, index u64 2
    store [v2176, v2177, v2178] at v2175
    dec_rc v2156
    dec_rc v2174
    v2179 = array_set v2156, index u64 0, value Field 0
    store v2179 at v2024
    store v2174 at v2025
    store u32 1 at v2026
    store u1 0 at v2027
    jmp b86()
  b86():
    v2038 = load v2024
    dec_rc v2038
    v2039 = load v2025
    dec_rc v2039
    inc_rc v2038
    store v2038 at v2024
    inc_rc v2039
    store v2039 at v2025
    jmpif u1 0 then: b6, else: b7
  b6():
    store v2038 at v2024
    store v2039 at v2025
    store u32 0 at v2026
    store u1 0 at v2027
    jmp b7()
  b7():
    jmpif u1 1 then: b8, else: b9
  b8():
    inc_rc v2038
    store v2038 at v2024
    inc_rc v2039
    store v2039 at v2025
    v2091 = load v2026
    v2092 = lt u32 0, v2091
    v2093 = not v2092
    jmpif v2093 then: b137, else: b138
  b137():
    v2134 = load v2026
    v2135 = array_set v2038, index u64 0, value Field 0
    store v2135 at v2024
    store v2039 at v2025
    store v2134 at v2026
    store u1 0 at v2027
    jmp b138()
  b138():
    v2095 = load v2026
    v2096 = lt u32 1, v2095
    v2097 = not v2096
    jmpif v2097 then: b142, else: b143
  b142():
    v2131 = load v2024
    v2132 = load v2026
    v2133 = array_set v2131, index u64 1, value Field 0
    store v2133 at v2024
    store v2039 at v2025
    store v2132 at v2026
    store u1 0 at v2027
    jmp b143()
  b143():
    v2099 = load v2026
    v2100 = lt u32 2, v2099
    v2101 = not v2100
    jmpif v2101 then: b147, else: b148
  b147():
    v2128 = load v2024
    v2129 = load v2026
    v2130 = array_set v2128, index u64 2, value Field 0
    store v2130 at v2024
    store v2039 at v2025
    store v2129 at v2026
    store u1 0 at v2027
    jmp b148()
  b148():
    v2102 = load v2024
    v2106 = array_get v2039, index u64 0
    v2107 = load v2024
    v2109 = array_get v2107, index u64 0
    v2110 = add v2106, v2109
    v2111 = array_set v2039, index u64 0, value v2110
    v2112 = array_get v2111, index u64 1
    v2113 = array_get v2102, index u64 1
    v2114 = add v2112, v2113
    v2115 = array_set v2111, index u64 1, value v2114
    v2116 = array_get v2115, index u64 2
    v2117 = array_get v2102, index u64 2
    v2118 = add v2116, v2117
    v2119 = array_set v2115, index u64 2, value v2118
    v2120 = call poseidon2_permutation(v2119, u32 4)
    inc_rc v2120
    v2121 = allocate
    v2122 = array_get v2120, index u64 0
    v2123 = array_get v2120, index u64 1
    v2124 = array_get v2120, index u64 2
    store [v2122, v2123, v2124] at v2121
    dec_rc v2102
    dec_rc v2120
    v2125 = array_set v2102, index u64 0, value v2122
    v2126 = array_set v2125, index u64 1, value v2123
    v2127 = array_set v2126, index u64 2, value v2124
    store v2127 at v2024
    store v2120 at v2025
    store u32 3 at v2026
    store u1 1 at v2027
    jmp b9()
  b9():
    v2044 = load v2024
    v2048 = array_get v2044, index u64 0
    v2051 = load v2026
    v2053 = lt u32 1, v2051
    jmpif v2053 then: b154, else: b155
  b154():
    v2081 = load v2024
    v2082 = load v2025
    v2083 = load v2026
    v2084 = load v2027
    v2085 = load v2024
    v2089 = array_get v2085, index u64 1
    v2090 = array_set v2081, index u64 0, value v2089
    store v2090 at v2024
    store v2082 at v2025
    store v2083 at v2026
    store v2084 at v2027
    jmp b155()
  b155():
    v2056 = load v2026
    v2058 = lt u32 2, v2056
    jmpif v2058 then: b159, else: b160
  b159():
    v2071 = load v2024
    v2072 = load v2025
    v2073 = load v2026
    v2074 = load v2027
    v2075 = load v2024
    v2079 = array_get v2075, index u64 2
    v2080 = array_set v2071, index u64 1, value v2079
    store v2080 at v2024
    store v2072 at v2025
    store v2073 at v2026
    store v2074 at v2027
    jmp b160()
  b160():
    v2059 = load v2024
    v2060 = load v2025
    v2062 = load v2027
    v2065 = load v2026
    v2067 = sub v2065, u32 1
    range_check v2067 to 32 bits
    v2068 = cast v2067 as u64
    v2069 = array_set v2059, index v2068, value Field 0
    store v2067 at v2026
    store v2062 at v2027
    dec_rc v2069
    store v2069 at v2024
    dec_rc v2060
    store v2060 at v2025
    return v2048
  b80():
    v2034 = load v2026
    v2035 = eq v2034, u32 3
    v2036 = not v2035
    jmpif v2036 then: b81, else: b82
  b81():
    v2139 = load v2026
    v2140 = load v2026
    v2141 = cast v2140 as u64
    v2142 = array_set v2028, index v2141, value Field 0
    v2144 = add v2139, u32 1
    range_check v2144 to 32 bits
    store v2142 at v2024
    store v2029 at v2025
    store v2144 at v2026
    store u1 0 at v2027
    jmp b85()
  b85():
    jmp b86()
  b82():
    jmpif u1 0 then: b83, else: b84
  b83():
    v2138 = array_set v2028, index u64 0, value Field 0
    store v2138 at v2024
    store v2029 at v2025
    store u32 1 at v2026
    store u1 0 at v2027
    jmp b84()
  b84():
    jmp b85()
  b56():
    jmpif u1 1 then: b57, else: b58
  b57():
    store [Field 0, Field 0, Field 0] at v2024
    store [Field 0, Field 0, Field 0, Field 2⁶⁵] at v2025
    store u32 1 at v2026
    store u1 0 at v2027
    jmp b61()
  b61():
    jmp b62()
  b58():
    jmpif u1 0 then: b59, else: b60
  b59():
    store [Field 0, Field 0, Field 0] at v2024
    store [Field 0, Field 0, Field 0, Field 2⁶⁵] at v2025
    store u32 1 at v2026
    store u1 0 at v2027
    jmp b60()
  b60():
    jmp b61()
}

It seems to take advantage of unrolled loops in brillig we could be missing an optimization step for non-flattened control flow that would

switch jmpif with a constant value to jump
prune blocks that are never targeted
inline blocks that only have one predecessor into the predecessor

It seems to take advantage of unrolled loops in brillig we could be missing an optimization step for non-flattened control flow that would

switch jmpif with a constant value to jump
prune blocks that are never targeted
merge blocks a & b where b predecessor is only a and a successor is only b

The last point should be done already by the simplify_cfg pass which does currently apply to brillig code as well.

prune blocks that are never targeted

The second point should be automatic by the function printer, since blocks are actually never removed in general. So it must still be reachable.

switch jmpif with a constant value to jump

This is one area where brillig opts can improve I think. We used to do this automatically in more passes but it was removed for bugs (IIRC) and we just rely on a check during flattening currently. We can try adding this to another pass (simplify_cfg? A different pass?)

struct EnumEmulation {
    a: Option<Field>,
    b: Option<Field>,
    c: Option<Field>,
}

unconstrained fn main() -> pub Field {
    let mut emulated_enum = EnumEmulation { a: Option::some(1), b: Option::none(), c: Option::none() };

    for _ in 0..1 {
        assert_eq(emulated_enum.a.unwrap(), 1);
    }

    emulated_enum.a = Option::some(2);
    emulated_enum.a.unwrap()
}

On current master, this program now compiles down to
After Array Set Optimizations:
brillig fn main f0 {
  b0():
    v50 = allocate
    store u1 1 at v50
    v51 = allocate
    store Field 1 at v51
    v52 = allocate
    store u1 0 at v52
    v53 = allocate
    store Field 0 at v53
    v54 = allocate
    store u1 0 at v54
    v55 = allocate
    store Field 0 at v55
    jmp b1(u64 0)
  b1(v10: u64):
    v56 = eq v10, u64 0
    jmpif v56 then: b2, else: b3
  b2():
    v63 = load v50
    v64 = load v51
    constrain v63 == u1 1
    constrain v64 == Field 1
    v70 = add v10, u64 1
    jmp b1(v70)
  b3():
    v59 = load v52
    v60 = load v53
    v61 = load v54
    v62 = load v55
    store u1 1 at v50
    store Field 2 at v51
    store v59 at v52
    store v60 at v53
    store v61 at v54
    store v62 at v55
    return Field 2
}

Ah misread and though this was improved (but still suboptimal), looks like it's unchanged :sweat_smile:

Yeah I think for this to improve mem2reg needs to do more than one pass of the code to gather information about loops ):

An extreme example is regression_4709 which resolves acc to a constant whereas in brillig we need to calculate this at runtime.
https://github.com/noir-lang/noir/pull/5128

Another extreme example, 15% of the runtime in this test is spent evaluating std::compat::is_bn254(), which should be known at compile time (but contains a loop)

We're currently not inlining any functions in brillig no matter how small afaik. This along with the fact that we don't perform any optimizations during brillig-gen means that these checks make their way into runtime code whereas they should be optimized out. As well as std::compat::is_bn254() we're going to be preserving all of the bytecode for the other branch which we don't need (e.g. in lt for fields).
@sirasistant It might be worth looking into a pass which automatically inlines brilllig functions which contain a number of instructions below a certain limit (maybe 5-10 or so?) to get some of these benefits of constant folding without increasing the bytecode size) There's also some overhead associated with performing a brillig function call so that could be used to make sure inlining always reduces the bytecode size.

For this function:
unconstrained fn main() {
    assert(std::compat::is_bn254());
}

This is the final SSA after all optimizations:
After Array Set Optimizations:
brillig fn main f0 {
  b0():
    v57 = allocate
    store u1 1 at v57
    jmp b1(u32 0)
  b1(v2: u32):
    v58 = lt v2, u32 2⁵
    jmpif v58 then: b2, else: b3
  b2():
    v60 = load v57
    v61 = lt v2, u32 2⁵
    constrain v61 == u1 1 '"Index out of bounds"'
    v62 = array_get [u8 2⁴×3, u8 100, u8 78, u8 114, u8 225, u8 49, u8 2⁴×10, u8 41, u8 184, u8 2⁴×5, u8 69, u8 182, u8 129, u8 129, u8 88, u8 93, u8 40, u8 51, u8 232, u8 72, u8 121, u8 185, u8 2⁴×7, u8 145, u8 67, u8 225, u8 245, u8 147, u8 2⁴×15, u8 0, u8 0, u8 1], index v2
    v63 = array_get [u8 2⁴×3, u8 100, u8 78, u8 114, u8 225, u8 49, u8 2⁴×10, u8 41, u8 184, u8 2⁴×5, u8 69, u8 182, u8 129, u8 129, u8 88, u8 93, u8 40, u8 51, u8 232, u8 72, u8 121, u8 185, u8 2⁴×7, u8 145, u8 67, u8 225, u8 245, u8 147, u8 2⁴×15, u8 0, u8 0, u8 1], index v2
    v64 = eq v62, v63
    v65 = mul v60, v64
    store v65 at v57
    v66 = add v2, u32 1
    jmp b1(v66)
  b3():
    v59 = load v57
    constrain v59 == u1 1
    return
}

Ah, my bad. You're right, I misread the inlining pass when checking this.
That said, we should be able to unroll loops in any brillig function without arguments or foreign calls safely.

That said, we should be able to unroll loops in any brillig function without arguments or foreign calls safely.

We definitely can try. I think the main concern before was just increasing code size. Unsure what a reasonable limit is but I'm sure we can think of some arbitrary measure.

This shouldn't increase code size as in the case where there are no runtime arguments/foreign call results/etc SSA optimizations should be able to simplify the function down into a constant return value.

Was looking at this a bit today in standup and talking with @vezenovm and we noticed the brillig can be improved a bit if we manually make a read only copy before the loop:
struct EnumEmulation {
    a: Option<Field>,
    b: Option<Field>,
    c: Option<Field>,
}

unconstrained fn main() -> pub Field {
    let mut emulated_enum = EnumEmulation { a: Option::some(1), b: Option::none(), c: Option::none() };

    let my_copy = emulated_enum;
    for _ in 0..1 {
        assert_eq(my_copy.a.unwrap(), 1);
    }

    emulated_enum.a = Option::some(2);
    emulated_enum.a.unwrap()
}

With this the new SSA would be:
After Array Set Optimizations:
brillig fn main f0 {
  b0():
    v36 = allocate
    store u1 1 at v36
    v37 = allocate
    store Field 1 at v37
    v38 = allocate
    store u1 0 at v38
    v39 = allocate
    store Field 0 at v39
    v40 = allocate
    store u1 0 at v40
    v41 = allocate
    store Field 0 at v41
    jmp b1(u32 0)
  b1(v10: u32):
    v42 = eq v10, u32 0
    jmpif v42 then: b2, else: b3
  b2():
    v49 = add v10, u32 1
    jmp b1(v49)
  b3():
    v45 = load v38
    v46 = load v39
    v47 = load v40
    v48 = load v41
    store u1 1 at v36
    store Field 2 at v37
    store v45 at v38
    store v46 at v39
    store v47 at v40
    store v48 at v41
    return Field 2
}

Which is 4 fewer instructions within the loop compared to Tom's example. I could see this being important especially for larger loops. It should also be a fairly easy optimization for users to apply even if it's difficult for the compiler to identify this automatically.
Another thing we noticed is these instructions at the end:
v45 = load v38
...
store v45 at v38

Where we're loading a value only to immediately store it again. In mem2reg when we load from a reference whose value is unknown, that value will stay unknown afterward, but this doesn't need to be the case! We now know that the reference loads to v45 so it's value can now be known! This would help us remove any subsequent loads to v38 (although there are none here)
Another check we could add though is for store v45 at v38 - ie. storing a value in a reference when we know that the reference already holds that value. Since we now know that v38 holds v45 internally, we can remove this store entirely. Then, we can remove v45 = load v38 from dead instruction elimination along with potentially v38 = allocate and store u1 0 at v38 as well. The only hiccup to removing all of them would be that the last load would be removed during DIE but the last store is only removed during mem2reg which happens beforehand. That store staying would prevent the allocate from being removed as well.

That sounds great!
If we reach this point:
After Array Set Optimizations:
brillig fn main f0 {
  b0():
    v36 = allocate
    store u1 1 at v36
    v37 = allocate
    store Field 1 at v37
    jmp b1(u32 0)
  b1(v10: u32):
    v42 = eq v10, u32 0
    jmpif v42 then: b2, else: b3
  b2():
    v49 = add v10, u32 1
    jmp b1(v49)
  b3():
    store u1 1 at v36
    store Field 2 at v37
    return Field 2
}

we can probably update the unroller to delete empty loops like this one

I get to this point in #5865 if we do a copy outside the loop and read the copy in the loop:
After Array Set Optimizations:
brillig fn main f0 {
  b0():
    jmp b1(u32 0)
  b1(v10: u32):
    v42 = eq v10, u32 0
    jmpif v42 then: b2, else: b3
  b2():
    v49 = add v10, u32 1
    jmp b1(v49)
  b3():
    return Field 2
}

Just catching an edge case for arrays w/ inc_rc, but the optimization looks promising.


Make 1.9 the minimum version of ansible

1.8 doesn't seem to detect Centos systemd services correctly, and will try to run initctl.
@BrianHicks: any problems with updating requirements.txt to 1.9?

We've already had people fixing various issues by upgrading to 1.9. I'd say go ahead and make it ==1.9.

Merged.


Create a new did:tdw

Hi! I'm trying to create a new did:tdw, but it seems that generating a fresh keypair triggers an error.
I created the following testcase:
import { expect, test } from "bun:test";
import { generate } from '@digitalbazaar/ed25519-multikey';
import { createDID, resolveDID } from "../src/method";
import { createSigner } from "../src/signing";

test("shit", async () => {
  const ed25519 = await generate();

  const authKey = {
    type: "authentication"as const,
    publicKeyMultibase: ed25519.publicKeyMultibase,
    secretKeyMultibase: ed25519.secretKeyMultibase
  };

  const result = await createDID({
    domain: 'example.com',
    signer: createSigner(authKey),
    updateKeys: [
      `did:key:${authKey.publicKeyMultibase}`,
    ],
    verificationMethods: [authKey],
    created: new Date(),
  });

  const resolveResult = await resolveDID(result.log, {versionId: 1});
  expect(resolveResult).toBeObject();
});

I think the resolveDID step should succeed, but instead it throws an error:
error: version 1 failed verification of the proof.

If I do not generate the key material but use one of the keys defined in test/fixtures/keys.json the above test case succeeds.
Maybe @digitalbazaar/ed25519-multikey is not the correct tool to create the key material? How was the content of test/fixtures/keys.json created?

yeah, this issue is the reason I ended up creating the fixture keys. It appears their is something interacting in the @digitalbazaar/ed25519-multikey library and bun. If you log the publicKey that is generated you'll notice it is always the same.. We will either need to resolve the root cause of this issue or drop bun..
thanks for creating this issue. Will keep it open until one of the above options has been used

I managed to get your test to pass without using the digitalbazaar library. Here is the code that uses @noble/ed25519
import { expect, test } from "bun:test";
import * as ed from '@noble/ed25519';
import { createDID, resolveDID } from "../src/method";
import { createSigner } from "../src/signing";
import { base58btc } from "multiformats/bases/base58";

test("shit", async () => {
  const privKey = ed.utils.randomPrivateKey();
  const pubKey = await ed.getPublicKeyAsync(privKey);

  const publicKeyMultibase = base58btc.encode(Buffer.concat([new Uint8Array([0xed, 0x01]), pubKey]));
  const secretKeyMultibase = base58btc.encode(Buffer.concat([new Uint8Array([0x80, 0x26]), privKey]));

  const authKey = {
    type: "authentication"as const,
    publicKeyMultibase,
    secretKeyMultibase
  };

  const result = await createDID({
    domain: 'example.com',
    signer: createSigner(authKey),
    updateKeys: [
      `did:key:${authKey.publicKeyMultibase}`,
    ],
    verificationMethods: [authKey],
    created: new Date(),
  });

  const resolveResult = await resolveDID(result.log, {versionId: 1});
  expect(resolveResult).toBeObject();
});

I will remove the digitalbazaar library from the dependency list

I'm working on a PR that removes the dependency and removes the key fixtures here https://github.com/bcgov/trustdidweb-ts/pull/14

Works - thank you!


Document "main" key support on Action

In theory, we support aliasing a function with a name other than "main" to "main" as this is what our runtime containers expect.
Verify this is supported (curosry look at code says we do), but should have unit tests for at least 2 languages (e.g., JS and Python and perhaps Java which was added recently).
In addition, we should have at least 1 integration test to prove it works.

@pritidesai Priti indicated to me that there are some unit and/or int. tests but not dedicated to testing for "main" by itself (and per runtime kind).

@pritidesai is there more to this in terms of automating aliasing of another function as main? perhaps some indicator in YAML manifest?


DependencyProperty DisplayFormat for DateTimePicker and TimePicker

Customizable format of the displayed Date / DateTime.
The default value is still the format of the SpecificCultureInfo.

Well, I think this change has already been made with #2930.

@xxMUROxx Can we maybe merge this together with #2930 ?

@punker76 I think the solution of @xxMUROxx  is more complete than mine. You can delete my pull request.
Sorry for not checking the open pull requests.

@punker76 @mosberger My solution allows only to specify whether to have short/long time/date. @mosberger s solution does allow custom formatting.
Lets discuss about whether or not we should provide a custom string format on TimePicker/DateTimePicker. My opinion is to have a behavior like MS provided it in DatePicker; to not let the user change the string Format like he wants to. Why do we need this bahavior. For each culture the date-time format is already predefined since ages.


package.windows10.appxmanifest does not set the correct descriptions as in config.xml

Bug Report
Problem
No matter what I do, the Cordova package manifest always ends up with the description "A sample Apache Cordova application that responds to the deviceready event." instead of what I put in config.xml.
I even ran a node script to replace the 2 description tags in package.windows10.appxmanifest, and an extra entry in the generated config.xml, but after I build the above description just comes back!
What is expected to happen?
Just pick up and use the description as in the source config.xml
What does actually happen?
It always replaces all the descriptions with "A sample Apache Cordova application that responds to the deviceready event."
Information

Command or Code

Environment, Platform, Device
Ionic UWP,  building on Windows 10 Cordova version 10.0.0
Version information
ionic  info

Ionic:

   Ionic CLI                     : 5.4.16 (C:\Users\peter\AppData\Roaming\npm\node_modules\ionic)
   Ionic Framework               : @ionic/angular 4.11.13
   @angular-devkit/build-angular : 0.803.29
   @angular-devkit/schematics    : 8.3.29
   @angular/cli                  : 8.2.2
   @ionic/angular-toolkit        : 2.3.3

Cordova:

   Cordova CLI       : 10.0.0
   Cordova Platforms : android 9.0.0, windows 7.0.1
   Cordova Plugins   : cordova-plugin-ionic-keyboard 2.2.0, cordova-plugin-ionic-webview 5.0.0, (and 14 other plugins)

Utility:

   cordova-res : 0.15.3
   native-run  : 0.2.9

System:

   Android SDK Tools : 26.1.1 (C:\Users\peter\AppData\Local\Android\sdk)
   NodeJS            : v14.17.0 (C:\Program Files\nodejs\node.exe)
   npm               : 7.21.1
   OS                : Windows 10

We are archiving this repository following Apache Cordova's Deprecation Policy. We will not continue to work on this repository. Therefore all issues and pull requests are being closed. Thanks for your contribution.


Do not submit an empty pre/post-send script for approval

Addresses what seems to have been a regression from 04efc23: every time you save the global config page, a warning pops up in Manage that you have a script to approve…but it is empty. Note that the method call here is deprecated as of https://github.com/jenkinsci/script-security-plugin/commit/f4c0bb9b58e105b4fc6b62be0f7f2daa46178190 but I am not touching that.

I would appreciate a release when you get a moment BTW!

(That would be automatic if an appropriate label were applied prior to merge.)

@slide could this be released please?

@slide could this be released please?

In progress now, sorry, I should have done that sooner.

https://github.com/jenkinsci/email-ext-plugin/releases/tag/1814.v404722f34263 thanks! If you apply labels like bug prior to merge, then the release should happen without human intervention. (There is no open RFE to create a check that blocks merge until some known label is applied.)


Add correct options to linmos to removeLeakage

Results from leakage code (@sunmish) has shown rather high stokes-v leakage. Talking to @AlecThomson it is pretty clear that I am not supplying the appropriate set of options to linmos in order for leakage to be removed.
I need to:

supply a stokesiname to linmos to list each of the per-beam stokes I images
need to change the naming scheme to files so it is not .pol{i,q,u,v}. and is just .{i,q,u,v}.

Speaking to Mark, so long as the stokes can be found in the file name and removeLeakage is true, the .v. will be replaced automatically with .i. as needed by linmos.

What a fun one this was.
New naming scheme for wsclean image products. A regex is used to properly convert its - separators to . in order to avoid clashes in the file path (e.g. parent directories, field names).
It also became apparent that a bug meant the correct rotation was not provided to linmos, which may be limiting the success of the leakage removal.

Corrected in #161


Demo URL

how to access the Live-Demo from the GitHub repo.
you may add an URL to your repo 👍
https://www.jqueryscript.net/demo/Table-Live-Search-Plugin-jQuery/

Done !

you can upload your code at codepen
it will be more useful for any changes or updates


webapp: Move az webapp up command to core from extension

This command should be available as a core  command https://docs.microsoft.com/en-us/cli/azure/ext/webapp/webapp?view=azure-cli-latest#ext-webapp-az-webapp-up

Moved to Sprint 50


feat(http.js) Add general ajax function

A new ajax function has been added to the http plugin that allows for general ajax calls. This function works much the same as the jQuery ajax function with the addition of similar knockout unwrapping that is available on the other http functions.
closes #633

this can be merged in

Closing since Durandal has been superseded by Aurelia just shy of four years ago.


Vendor cosmos-sdk here?

I'll be putting up a branch momentarily containing my work on 0.44.1 migration.  There's still 1 remaining issue, with something something with the bank module.  Lucky for me, I've made an appointment for the first Notional symposium!  Yes, actual drinking and monologues..... for YouTube :P
There are surely issues, as there are surely issues with chopping in the decimal math thing in the cosmos-sdk.
The sheer amount of merge-quest that will be involved with ongoing maintenance of o-sdk + c-sdk is truly very high.  I bet that 0.44.1 -> 0.44.2 takes a day at least.  Then there's the entropy.
In fact the only reason I am quite so keen on this is that post-0.43.0 we made it so that if we were Marshaling-- it is the Golang idea of Marshaling like json.Marshal etc.... whereas earlier cosmos-sdk uh, well, you'd codec.Marshaler but now you codec.Codec.  For me personally the usability improvement there was enormous, so I really wanted to get the SDK to that point.
After 0.44.2, I'm kinda thinking that we vendor the SDK here-- reason is, that in order to work on this effectively and easily, that's what I needed to do.  Apologies in advance for the needed reviews; I think that in the future we can ease this with various automation.
I'd like to build a (physical) build server for Osmosis, or rent a (physical) build server for Osmosis.  This way, we can do much more in the few minutes of non-flow-breaking time that we allow ourselves for CI.  (tho really, from what I've read, anything over a minute is too much)
thoughts?
🙏
-j

I don't think this is super-needed. (the SDK vendoring-- but I may hack on the updated SDK and change my mind.)


Create GitHub Action to push on Docker Hub

done.
We could have a better versioning, but the ci/cd is done


Add source S2I Build to fabric8:build

Currently we have the following build types:

Docker direkt
Binary Docker for OpenShift
Binary S2I for OpenShift

An additional "Source S2I" build should be added to help in creating images for mixed (i.e. non-java) projects on OpenShift.
Therefor BuildMojo need to be extended:

A new property fabric8.build.s2i.source should be added with the possible values binary or source (with binary being the default)
When source is selected then:

Change the this source type to Source
When triggering the build, send a tar archive of the project directory (${project.baseDir} excluding /target and possibly .git) to OpenShift when triggering the build

This parameter is still a global one which applies to all images to be created. In order to allow image specific build.strategy and build.s2i.source value from BuildImageConfiguration.fromExt could be extracted, overwriting the global parameter (that's probably not the perfect location where to put this information into, but should be sufficient for now as I consider this a bit of a rare use case, too)

@fabric8io/fmp-core-team do you think this is still a useful extension ? The original idea was to add e.g. simple non-java builds with fmp in order to allow an easy integration.

Since fmp is designed for maven space only, not sure whether it should be added or not. Would it make sense for those non-java based projects to have poms in their repo? Can this be somehow done in fabric8-kit?

yeah, maybe. Let's keep it to not lose the idea, but with a very low priority. We have bigger fish to fry.

Closing as per discussion with the current maintainers' team.


Handle relative unix socket paths

Make relative unix sockets absolute by making them absolute against the AppWorkPath
Fix #17833
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

What was the previous behaviour? Did it resolve relative to working directory or just crash?

Codecov Report

Merging #17836 (3223c51) into main (2e8fc5b) will increase coverage by 0.02%.
The diff coverage is 42.85%.

@@            Coverage Diff             @@
##             main   #17836      +/-   ##
==========================================
+ Coverage   45.54%   45.56%   +0.02%
==========================================
  Files         808      808
  Lines       90056    90060       +4
==========================================
+ Hits        41013    41035      +22
+ Misses      42489    42472      -17
+ Partials     6554     6553       -1

Impacted Files
Coverage Δ

services/auth/signin.go
55.76% <ø> (ø)

modules/setting/setting.go
50.27% <42.85%> (-0.38%)
:arrow_down:

modules/charset/charset.go
71.71% <0.00%> (-4.05%)
:arrow_down:

modules/git/repo_base_nogogit.go
82.85% <0.00%> (-2.86%)
:arrow_down:

modules/git/utils.go
68.05% <0.00%> (-2.78%)
:arrow_down:

services/pull/pull.go
41.78% <0.00%> (-0.41%)
:arrow_down:

models/issue_comment.go
52.97% <0.00%> (-0.29%)
:arrow_down:

routers/api/v1/repo/pull.go
29.35% <0.00%> (+0.51%)
:arrow_up:

models/notification.go
65.65% <0.00%> (+0.86%)
:arrow_up:

modules/notification/ui/ui.go
62.31% <0.00%> (+1.44%)
:arrow_up:

... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 04c55e9...3223c51. Read the comment docs.

Should we mark this as breaking?

Yeah I think this is technically breaking although anyone not using an absolute unix path would have faced multiple problems.

What was the previous behaviour? Did it resolve relative to working directory?

Yes It would have simply been relative to the current working directory which would have broken severely for hooks and serv.


Instagram Access Tokens

Avoid others being confused by warning them for now.

I think you should be allowed to merge now @philsturgeon and you can remove me as co-author as I only merged in master.
I am not super savvy when it comes to PLs so I am hoping "you get it" if your merge and remove me as co-author.

I don’t have permission but I don’t care about attribution if that got confused anyhow. Merge it in via copy and paste if needs be. 😄

You and other you got the attribution ;)


need to release v0.2.2

0.2.1 was released in May 2017. There have been many bugfixes since then, but no release.
I would like to do the following before a release

[ ] Fix #67
[ ] Set up conda-forge packaging

I no longer think it is practical to fix #67 before doing a new release. Fixing that issue properly will require a major refactor to how timesteps our handled.
@raphaeldussin, I would be happy if you could move ahead with the release process for xmitgcm v0.2.2.

Do we want the conda-forge for this release?

Yes I think so. I would just imitate what @ocefpaf set up for xgcm.
Sent from my iPhone

On Jul 17, 2018, at 9:50 PM, raphael dussin<EMAIL_ADDRESS>wrote:
Do we want the conda-forge for this release?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

ok! If I got it right, this is orthogonal and I can release first, then pypi then conda-forge.
I have a new version ready to be pushed. Just want to make sure I did it right :

cloned xgcm/xmitgcm
update the development.rst with filtered content of git log (commit1)
bumpversion patch (commit2)

If that's ok, I'll push to xgcm/xmitgcm master's

Yes that sounds like a good plan.
When in doubt, try to follow the procedure from xarray https://github.com/pydata/xarray/blob/master/HOW_TO_RELEASE

sounds good!

it's been released 10 days ago on pip. Working on the conda-forge this week

You also need to make the new tag in git, push to master, and draft the release on github (steps 8 - 12).
Ideally all of these things happen in very close temporal proximity to each other, so the "release" is a discrete event.

When all this is done, we should announce the release on the mitgcm mailing list.

I can't add the requirements.txt with sphinx=1.6.7 to fix it because I don't own the project
on readthedocs.

We are using an environment.yml (conda environment) rather than environment.txt (pip environment) for rtd.
You don't need to own the project on rtd to fix this. Just make a PR with the necessary updates to https://github.com/xgcm/xmitgcm/blob/master/doc/environment.yml.

got it! I may have found the problem in the build log
(see https://readthedocs.org/api/v2/build/7563226.txt)
The first phase works well, installing sphinx 1.2.3 as required. Only, after that comes
this command :
conda install --yes --name stable mock pillow sphinx sphinx_rtd_theme
that triggers the update to sphinx 1.7.5. I don't know what controls this.

It seems like that line is built into the build process. Weird. I wish there were a way to disable that.
Maybe open a new rtd issue?

apparently it is a known issue, waiting for conda update
https://github.com/rtfd/readthedocs.org/issues/3829

@ocefpaf @jbusecke are you ok to be listed as co-maintainers of the conda recipe ?

@ocefpaf @jbusecke are you ok to be listed as co-maintainers of the conda recipe ?

Sure.

Yup
Julius Busecke

On Jul 30, 2018, at 3:32 PM, raphael dussin<EMAIL_ADDRESS>wrote:
@ocefpaf @jbusecke are you ok to be listed as co-maintainers of the conda recipe ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


Add other operating systems support

Currently, SOCD cleaner is Windows only because it heavily relies on win32 api. But since it's a relatively small program, making it crossplatform wouldn't be a hard task. But it's about the lowest priority for me for now unless there is a high desire for it or somebody else implements other OS support.

Linux is implemented in rewrite branch. Macos isn't planned for now, I don't have mac to take a stab at it anyway, so closing


Responses to MLE requests sent by SED

When I experimented with a SED device I noticed a small problem:

SED attaches to a parent.
Parent sends Data Response to the SED (new Pending Dataset).
SED sends Data Request to receive new Pending Dataset.
Parent puts Data Response with the new Dataset to the indirect queue.
SED is going to retrieve Data Response when poll timer expires. It can be in a few hours or days.

Maybe we could provide a procedure to notify MAC layer that MLE (or any other protocol) expects response. During waiting for a response the poll period could be much shorter than one set by an application.
This could be somehow a solution to #1353

How about adding a "expectedResponseTimeout" (exRT) field to otMessageInfo? By default, 0 would mean that no response is expected, and non-zero values - to expect a response in no more than exRT. MAC layer would then send N data requests every exRT/N milliseconds. Or instead of linear delay between data requests there could be an exponential delay like in CSMA.
Also, if multiple messages with exRT!=0 were sent (e.g. from MLE and app layer), then the MAC could use some intermediate values, so that the device would not spam too many data requests.

Good point.
I am working on adding a new class DataPollManager which contains all the logic for handling of data polls and selection of polling interval (based on a combination of state of OpenThread and wishes of the app/user). I should have the PR for this soon. This can be used to address this issue.

Proposed fix in #1551.