machine.getState() doesn't exist

Bug
Description:
Machine method getState() as listed in docs doesn't exist. See codepen.
Expected result:
Return a stateNode.
Actual result:
Uncaught error, message: standardMachine.getState is not a function

Hi @bradwoods , this feature was added here and is going to be released in 3.4 I guess.

In V4 this will be:
myMachine.getStateNode('foo'); // retrieves myMachine.states.foo
myMachine.getStateNode('#someStateID'); // retrieves (nested?) state with id: someStateId

// alternatively:
myMachine.getStateNodeById('someStateId'); // same as above

myMachine.getStateNodeByPath('foo.bar.baz'); // retrieves nested state with path ['foo', 'bar', 'baz']
myMachine.getStateNodeByPath(['foo', 'bar', 'baz']); // same as above

This is to disambiguate a "State" and "StateNode", which are two different things.

This is now in master and the latest xstate@next.


NullReferenceException thrown for invalid movement

The following code is trying to move a piece that doesn't exist. There should certainly be an error, but a NullReferenceException makes it seem like the code is broken.
var game = new ChessGame();
game.MakeMove(new Move("a3", "a4", Player.White), true);

System.NullReferenceException
HResult=0x80004003
Message=Object reference not set to an instance of an object.
Source=ChessDotNet
StackTrace:
at ChessDotNet.ChessGame.GetSanForMove(Move move, Piece movingPiece, Boolean isCapture, CastlingType castle, List`1 ambiguities)
at ChessDotNet.ChessGame.MakeMove(Move move, Boolean alreadyValidated, Piece& captured)
at ChessDotNet.ChessGame.MakeMove(Move move, Boolean alreadyValidated)

Perhaps this is badly documented, but this is the expected behavior. The 'true' parameter is the alreadyValidated parameter, which basically tells Chess.NET that it can safely assume that the move is validated and correct. If you pass 'false' instead, it will return MoveType.Invalid.
I'm closing this for now, but let me know if this is bad practice.

Yep, throwing NullReferenceException is bad practice. I would throw something more appropriate like an InvalidOperationException. with a message like "Move could not be executed" or "Source piece does not exist".
I did read the documentation of alreadyValidated but I assumed that would allow me to make moves like a2 to h8; moves that are "possible", but not valid. Whereas a4 to a5 would simply be impossible.

See https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/using-standard-exception-types#nullreferenceexception-indexoutofrangeexception-and-accessviolationexception

That's fair. Reopening. I guess the steps to take are: 1) Figuring out what exceptions can all be thrown on invalid moves. 2) Preventing them and throw an InvalidOperationException.

similar issue in Atomic
https://github.com/ProgramFOX/Chess.NET/pull/27


Hook should exit on pydocstyle failure

Hello Weibullguy! Thanks for the awesome github action! I noticed pydocstyle doesn't exit but echos when it fails and I didn't see anywhere to open issues. So I thought I might make a PR which more strongly enforces pydocstyle. If this is undesirable, let me know I'd love to add a flag to make it possible to fail commits if not documented.  Thanks for the great repository!

Good catch.  Thanks!  It'll be in the next update which will occur after I release a new version of docformatter.

Lol.  You fixed it and now pydocstyle causes the lint action to fail because there's no docstring in tests/init.py.  I'll take care of that for the next release.


Data publication

@cojacoo, @jonaslenz, @AlexDo1, @lucfr
This is our main issue related to the planned data publication on Zenodo.
I added a README into the data folder. This will be the main source of information for users (scientists) who download the data directly from Zenodo. In a final version it should include a listing of all files and the origins; a statement about processing; a hint how to load or use the data and finally a description of the structure. For now, we only need the listing and the origin statement. Then, a preliminary Zenodo version can be published to implement the download function into RUINS.
The current state of the data folder can be downloaded here: http://ruins.hydrocode.de/data.zip
You can double-check, that all needed data is included.
TODOs

[ ] Update cordex_krummh to include all ET data - @cojacoo
[ ] Convert the krummhoern/* files into the missing hydro_krummh.nc file - @jonaslenz / @lucfr / @mmaelicke
[ ] add statements about data origin - @cojacoo

And: @cojacoo - you need to specify the list of authors (and order) for that data publication. I am not sure, who contributed.

I just tested weather.py with the new data in this branch.
Everything seems to work with the new data files as all of the plots are still shown.


Support writing multiple SPIRV files to disk when using precompiled modules (-embed-spirv)

This is to support vulkan consumption of separate SPV modules.

Obsoleted by https://github.com/shader-slang/slang/issues/5147


[AutoGen Studio] Allow multiline strings in chat input

Why are these changes needed?
It is useful for users to be able to input multiline strings when passing prompts to a LLM. This is mostly beneficial for the user, but it could also enhance the prompt since clear delimiters might yield better responses from the AI model: https://platform.openai.com/docs/guides/prompt-engineering/tactic-use-delimiters-to-clearly-indicate-distinct-parts-of-the-input.
This is currently rather hard to do since the entire input string is crammed up on a single line, and reviewing + editing it before submission is difficult.
Changes indtroduced in this PR:

the input was replaced with textarea
Shift+Enter key combination no longer submits the input, rather it creates a new line so the user can continue typing before pressing Enter to submit the prompt
the textarea component can be expanded to a maximum of 120px so the user can more easily tweak his prompt before submission

Note: most chat interfaces behave like this, I just wanted the same behavior here
Demo
https://github.com/microsoft/autogen/assets/11348201/87c883d6-1faa-4348-85c9-a562c998d38a
Checks

[x] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[ ] I've made sure all auto checks have passed.

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

Comparison is base (f39c3a7) 30.56% compared to head (40c7168) 30.38%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1105      +/-   ##
==========================================
- Coverage   30.56%   30.38%   -0.18%
==========================================
  Files          30       30
  Lines        4028     4028
  Branches      911      911
==========================================
- Hits         1231     1224       -7
- Misses       2723     2729       +6
- Partials       74       75       +1

Flag
Coverage Δ

unittests
30.38% <ø> (-0.13%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

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

@microsoft-github-policy-service agree


TFSSecurity is Depricated for Azure DevOps Service

Hi team,
This Tool may still work for some scenarios, but it is deprecated and unsupported for Azure DevOps Service (It is still the correct tool for On Premise installs).
Can we please Remove "Use with Azure DevOps Services" section (and have it fall back to OnPrem versions if the service is picked in the Version drop down)?
We should also add a note that explains that this tool is deprecated for Azure DevOps Services and that the recommended method to make changes is either via the Web UI, or the Rest Apis: https://docs.microsoft.com/en-us/rest/api/azure/devops/security/?view=azure-devops-rest-5.1
Again, this tool has not been blocked but it can no longer fulfill all scenarios that this article advertises for all users, and per the developers is no longer supported for the Service, ONLY for the On Prem version of the product.
Please let me know if you have any questions!
Thank you.

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

ID: f6f36e44-f157-3ff6-bdc9-38e90535fe97
Version Independent ID: 39e507c4-9812-16fb-f0c1-0583b39fb1c7
Content: Change groups & permissions, TFSSecurity - Azure DevOps
Content Source: docs/command-line/tfssecurity-cmd.md
Product: devops-server
Technology: tfs-admin
GitHub Login: @aaronhallberg
Microsoft Alias: aaronha

@SamGrantham - I'm updating the topic per your feedback with this PR: https://github.com/MicrosoftDocs/azure-devops-server-docs-pr/pull/41.


install cirun for this repository

graviton jobs run on the main OpenBLAS repo, but not on this one: https://github.com/OpenMathLib/BLAS-Benchmarks/actions/runs/9549517327/job/26319258806 is stuck on Waiting for a runner to pick up this job...
I asked Amit https://github.com/aktech of cirun.io, and his reply is

If you're adding a new runner in the same account ... install cirun for that repository and create a .cirun.yml in the repository to trigger runs.

So I copy-pasted the .cirun.yml from the OpenBLAS repository, and.. it's not enough, so I guess the I'd need to ask @martin-frbg to install cirun for the repository?

should be installed already - however, right as I checked the configuration it asked me to add a new permission so that cirun.yml could be read. So maybe it is working already, now that I granted that permission ?

Well, the job at https://github.com/OpenMathLib/BLAS-Benchmarks/actions/runs/9550767014/job/26323517279 is still waiting to be picked up by a runner.
The workflow file is https://github.com/OpenMathLib/BLAS-Benchmarks/blob/main/.github/workflows/run_cirun_graviton.yml and the .cirun.yml is https://github.com/OpenMathLib/BLAS-Benchmarks/blob/main/.cirun.yml

removed and re-added the repo to Cirun, and cancelled and reran the job again - now it runs but fails due to not finding an appropriate openblas-scipy32

Thank you!
scipy-openblas32 hiccup was due to numpy 2.0 released yesterday. Will probably fix itself on the next scipy-openblas32 rebuild. Meanwhile capping numpy<2 seems to work, and I can proceed fixing the build/upload stage.


Hide and show image filters

Hi,
I just want to ask if there's a way to toggle the image filter like hiding and showing? my plan is to create a privacy mode while streaming.
Thank you!

You can use alpha to hide and show image filters:
imageObjectFilterRender.setAlpha(0.0f); // hide
imageObjectFilterRender.setAlpha(1.0f); // show

You can do it after set filter in any moment.

Hi,
i tried these
glInterface?.muteVideo()
glInterface?.unmuteVideo()
and its working
thank you!


Root webpage wont load

Hey Chris,
Awsome Project, excited to get it working and setup but I've had alot of trouble today trying to get it to work.
I run though the readme and followerd all the steps, only thing that didn't work for me was the upload via command prompt, I've been able to flash the esp32cam via platformio in vscode in any case so I dont think that matters too much
The westerner does start and I can get some some of the subpage ok, but when I try to go to the  root espcam.local/ or espcam.local/index.html I got a 404 error.
Any help on this would be appreciated
Thank you
Joe

Hi Joe,
I'm sorry you're having some problems.
It sounds like the frontend has not built for you or not been uploaded so it can't find the HTML to serve to you.
Can you try running the steps from the Makefile manually? See if you can successfully run these commands:
cd frontend
yarn build
yarn export

You may need to install yarn - https://classic.yarnpkg.com/en/docs/install/#mac-stable
If it's worked successfully you should have a data folder in the firmware folder full of gzipped files. These need to be uploaded to a SPIFFS filesystem.
You can do that manually using the PlatformIO plugin in visual studio.
The README probably glosses over a few of the pre-requisites for building the front end - I'll update it to be a bit more detailed.
Thanks
Chris

Hi Chris,
Thank for getting back to me
Ive built it all again, and here is my output, with version numbers:
`joe@Joeboy-Surbook:/mnt/c/Users/Joeboy/OneDrive/Home Automation/VSCode/VSCode - ESP32CAM LEDS$ python3 --version
Python 3.6.7
joe@Joeboy-Surbook:/mnt/c/Users/Joeboy/OneDrive/Home Automation/VSCode/VSCode - ESP32CAM LEDS$ python3 -m venv venv
joe@Joeboy-Surbook:/mnt/c/Users/Joeboy/OneDrive/Home Automation/VSCode/VSCode - ESP32CAM LEDS$ source ./venv/bin/activate
(venv) joe@Joeboy-Surbook:/mnt/c/Users/Joeboy/OneDrive/Home Automation/VSCode/VSCode - ESP32CAM LEDS$ pip install -r requirements.txtCollecting platformio (from -r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/af/7a/07e5fa67f08eb738bcea35c9a5aa862463e693de26e02d9f4d393a75f567/platformio-4.3.4.tar.gz
Collecting bottle<0.13 (from platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/e9/39/2bf3a1fd963e749cdbe5036a184eda8c37d8af25d1297d94b8b7aeec17c4/bottle-0.12.18-py3-none-any.whl
Collecting click<8,>=5 (from platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/d2/3d/fa76db83bf75c4f8d338c2fd15c8d33fdd7ad23a9b5e57eb6c5de26b430e/click-7.1.2-py2.py3-none-any.whl
Collecting colorama (from platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/c9/dc/45cdef1b4d119eb96316b3117e6d5708a08029992b2fee2c143c7a0a5cc5/colorama-0.4.3-py2.py3-none-any.whl
Collecting marshmallow>=2 (from platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/a6/11/f824483fcfc4164d733c0a242cc01f7e3b153561500a6a69bba217c9f0f6/marshmallow-3.7.1-py2.py3-none-any.whl
Collecting pyelftools<1,>=0.25 (from platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/bb/2f/bf41f3c3867d6707fa9b872658bb23088a64d0e522e8979f54c694b8cbe1/pyelftools-0.26-py2.py3-none-any.whl
Collecting pyserial!=3.3,<4,>=3 (from platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/0d/e4/2a744dd9e3be04a0c0907414e2a01a7c88bb3915cbe3c8cc06e209f59c30/pyserial-3.4-py2.py3-none-any.whl
Collecting requests<3,>=2.4.0 (from platformio->-r requirements.txt (line 1))
Collecting semantic_version<3,>=2.8.1 (from platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/a5/15/00ef3b7888a10363b7c402350eda3acf395ff05bebae312d1296e528516a/semantic_version-2.8.5-py2.py3-none-any.whl
Collecting tabulate<1,>=0.8.3 (from platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/c4/f4/770ae9385990f5a19a91431163d262182d3203662ea2b5739d0fcfc080f1/tabulate-0.8.7-py3-none-any.whl
Collecting chardet<4,>=3.0.2 (from requests<3,>=2.4.0->platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl
Collecting idna<3,>=2.5 (from requests<3,>=2.4.0->platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/a2/38/928ddce2273eaa564f6f50de919327bf3a00f091b5baba8dfa9460f3a8a8/idna-2.10-py2.py3-none-any.whl
Collecting certifi>=2017.4.17 (from requests<3,>=2.4.0->platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/5e/c4/6c4fe722df5343c33226f0b4e0bb042e4dc13483228b4718baf286f86d87/certifi-2020.6.20-py2.py3-none-any.whl
Collecting urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 (from requests<3,>=2.4.0->platformio->-r requirements.txt (line 1))
Using cached https://files.pythonhosted.org/packages/e1/e5/df302e8017440f111c11cc41a6b432838672f5a70aa29227bf58149dc72f/urllib3-1.25.9-py2.py3-none-any.whl
Building wheels for collected packages: platformio
Running setup.py bdist_wheel for platformio ... error
Complete output from command "/mnt/c/Users/Joeboy/OneDrive/Home Automation/VSCode/VSCode - ESP32CAM LEDS/venv/bin/python3" -u -c "import setuptools, tokenize;file='/tmp/pip-build-jsxt_9uv/platformio/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" bdist_wheel -d /tmp/tmp6zas8155pip-wheel- --python-tag
cp36:
usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: -c --help [cmd1 cmd2 ...]
or: -c --help-commands
or: -c cmd --help
error: invalid command 'bdist_wheel'

Failed building wheel for platformio
Running setup.py clean for platformio
Failed to build platformio
Installing collected packages: bottle, click, colorama, marshmallow, pyelftools, pyserial, chardet, idna, certifi, urllib3, requests, semantic-version, tabulate, platformio
Running setup.py install for platformio ... done
Successfully installed bottle-0.12.18 certifi-2020.6.20 chardet-3.0.4 click-7.1.2 colorama-0.4.3 idna-2.10 marshmallow-3.7.1 platformio-4.3.4 pyelftools-0.26 pyserial-3.4 requests-2.24.0 semantic-version-2.8.5 tabulate-0.8.7 urllib3-1.25.9
(venv) joe@Joeboy-Surbook:/mnt/c/Users/Joeboy/OneDrive/Home Automation/VSCode/VSCode - ESP32CAM LEDS$ yarn --version
1.22.4
cd frontend && yarn
yarn install v1.22.4
[1/4] Resolving packages...
success Already up-to-date.
Done in 2.69s.
cd frontend && yarn build
yarn run v1.22.4
$ GENERATE_SOURCEMAP=false  react-app-rewired build
Creating an optimized production build...
Compiled successfully.
File sizes after gzip:
56.8 KB  build/main.edb86cda.js
453 B    build/main.4102b7b4.css
The project was built assuming it is hosted at /.
You can control this with the homepage field in your package.json.
The build folder is ready to be deployed.
You may serve it with a static server:
yarn global add serve
serve -s build
Find out more about deployment here:
bit.ly/CRA-deploy
Done in 132.78s.
cd frontend && yarn export
yarn run v1.22.4
$ rm -rf ../firmware/data && rm -f build/manifest && rm -f build/LICENSE && gzipper compress --level 9 --verbose ./build ../firmware/data
gzipper: Compression GZIP | level: 9
gzipper: Default output file format: [filename].[ext].[compressExt]
gzipper: File favicon.ico has been compressed 3.08 KB -> 2.91 KB (43.9662ms)
gzipper: File index.html has been compressed 609 B -> 356 B (31.336ms)
gzipper: File logo192.png has been compressed 5.22 KB -> 5.21 KB (38.2878ms)
gzipper: File logo512.png has been compressed 9.44 KB -> 9.43 KB (36.001ms)
gzipper: File main.4102b7b4.css has been compressed 850 B -> 453 B (29.5292ms)
gzipper: File main.edb86cda.js has been compressed 178.28 KB -> 56.8 KB (58.323ms)
gzipper: File robots.txt has been compressed 67 B -> 78 B (34.0236ms)
gzipper: File service-worker.js has been compressed 1.15 KB -> 683 B (35.2374ms)
gzipper: 8 files have been compressed. (1s 962.4901ms)
Done in 4.98s.
source ./venv/bin/activate && cd firmware && platformio run --target uploadfs
/bin/sh: 1: source: not found
Makefile:19: recipe for target 'upload_fs' failed
make: *** [upload_fs] Error 127
(venv) joe@Joeboy-Surbook:/mnt/c/Users/Joeboy/OneDrive/Home Automation/VSCode/VSCode - ESP32CAM LEDS$ `
so based on that output it all seems to build just fine, other then the upload bit which i can do manually

It looks like the upload_fs failed because platformio didn't install.
Makefile:19: recipe for target 'upload_fs' failed
make: *** [upload_fs] Error 127

Since it did build the actual files you can do it manually from the vscode plugin:

did you create a virtual environment and activate it? I think the make file failed to locate the venv so it failed.
python3 -m venv venv
source ./venv/bin/activate
pip install -r requirements.txt

Can you try again wih the latest code - I think the makefile should work

Thanks Chris, i'll give it a go now

ok so erasing flash and re-flashing still hasn't worked, even with that new makefile :(
looking at the serial console during first boot it look like there may be a SPIFFS issue:
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac
�Booting
Wifi Connected
<IP_ADDRESS>
Started up
Is Calibrated 0
E (1926) SPIFFS: mount failed, -10025
Started calibration
LED 0 is at 14 9
LED 1 is at 30 72
LED 2 is at 57 14
LED 3 is at 53 37
LED 4 is at 4 11
LED 5 is at 83 48
LED 6 is at 135 21
LED 7 is at 17 22
LED 8 is at 79 64
LED 9 is at 92 51
LED 10 is at 3 0
LED 11 is at 82 117
LED 12 is at 12 58
LED 13 is at 46 1
LED 14 is at 60 8
LED 15 is at 0 65
LED 16 is at 20 59
LED 17 is at 44 58
LED 18 is at 2 36
LED 19 is at 5 19
LED 20 is at 45 49
LED 21 is at 0 41
LED 22 is at 24 82
LED 23 is at 50 63
LED 24 is at 3 60
LED 25 is at 20 58
LED 26 is at 77 54
LED 27 is at 73 26
LED 28 is at 17 48
LED 29 is at 1 51
LED 30 is at 38 82
LED 31 is at 0 93
LED 32 is at 0 44
LED 33 is at 19 47
LED 34 is at 18 0
LED 35 is at 6 5
LED 36 is at 1 4
LED 37 is at 126 2
LED 38 is at 6 59
LED 39 is at 20 69
LED 40 is at 12 65
LED 41 is at 4 50
LED 42 is at 20 73
LED 43 is at 18 5
LED 44 is at 17 5
LED 45 is at 33 34
LED 46 is at 54 74
LED 47 is at 65 61
LED 48 is at 137 2
LED 49 is at 10 56
Wrote 200 bytes to preferences
Done calibration
I've taken a look at the error, seems to be common and applied a few fixes but they dont work either, could it be my easp32cam module?
I have another ESP32, so i might try that next

It's not one I've seen before. Is it definitely uploading the file system ok?
If you can try on another esp32 that would be great. I'll verify here as well.

Well, im really not sure, i dont see any errors in the upload, other then the warning about the bitbanged pin for fastled
I can get to some pages on the ESP itself, like /clear /leds /pause, and they will give me some output.
Ive just tried another ESP32 and i get the same error about the SPIFFS
E (4833) SPIFFS: mount failed, -10025

hmm, really weird. Can you send me the output from running:
make upload_fs

Thanks!

Hey Chris
here is the output from that command
joe@Joeboy-Surbook:/mnt/c/Users/Joeboy/OneDrive/Home Automation/VSCode/VSCode - ESP32CAM LEDS$ make upload_fs
cd frontend && yarn
yarn install v1.22.4
[1/4] Resolving packages...
success Already up-to-date.
Done in 2.65s.
cd frontend && yarn build
yarn run v1.22.4
$ GENERATE_SOURCEMAP=false  react-app-rewired build
Creating an optimized production build...
Compiled successfully.
File sizes after gzip:
56.8 KB  build/main.edb86cda.js
453 B    build/main.4102b7b4.css
The project was built assuming it is hosted at /.
You can control this with the homepage field in your package.json.
The build folder is ready to be deployed.
You may serve it with a static server:
yarn global add serve
serve -s build
Find out more about deployment here:
bit.ly/CRA-deploy
Done in 131.75s.
cd frontend && yarn export
yarn run v1.22.4
$ rm -rf ../firmware/data && rm -f build/manifest && rm -f build/LICENSE && gzipper compress --level 9 --verbose ./build ../firmware/data
gzipper: Compression GZIP | level: 9
gzipper: Default output file format: [filename].[ext].[compressExt]
gzipper: File favicon.ico has been compressed 3.08 KB -> 2.91 KB (51.9727ms)
gzipper: File index.html has been compressed 609 B -> 356 B (33.6298ms)
gzipper: File logo192.png has been compressed 5.22 KB -> 5.21 KB (32.8572ms)
gzipper: File logo512.png has been compressed 9.44 KB -> 9.43 KB (29.8769ms)
gzipper: File main.4102b7b4.css has been compressed 850 B -> 453 B (29.7532ms)
gzipper: File main.edb86cda.js has been compressed 178.28 KB -> 56.8 KB (53.8646ms)
gzipper: File robots.txt has been compressed 67 B -> 78 B (38.9692ms)
gzipper: File service-worker.js has been compressed 1.15 KB -> 683 B (36.0657ms)
gzipper: 8 files have been compressed. (998.0709ms)
Done in 3.72s.
. ./venv/bin/activate && cd firmware && platformio run --target uploadfs
/bin/sh: 1: platformio: not found
Makefile:19: recipe for target 'upload_fs' failed
make: *** [upload_fs] Error 127

and here is the upload and first boot on the standard ESP32 i have
Processing esp32dev (platform: espressif32; board: esp32doit-devkit-v1; framework: arduino)
-------------------------------------------------------------------------------------------------------------------------------------Verbose mode can be enabled via -v, --verbose option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32doit-devkit-v1.html
PLATFORM: Espressif 32 1.12.4 > DOIT ESP32 DEVKIT V1
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:

framework-arduinoespressif32 3.10004.200129 (1.0.4)
tool-esptoolpy 1.20600.0 (2.6.0)
tool-mkspiffs 2.230.0 (2.30)
toolchain-xtensa32 2.50200.80 (5.2.0)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 40 compatible libraries
Scanning dependencies...
Dependency Graph
|--  1.0.1
|--  1.9.0
|   |--  1.2.6
|   |   |--  1.0.1
|   |   |--  1.0
|   |--  1.0
|   |--  1.0.1
|--  3.3.3
|   |--  1.0
|--  1.0
|--  1.0
|   |--  1.0
|   |--  1.0
|   |--  1.0
|   |   |--  1.0
|--  1.0
|   |--  1.0
|--  1.0
|--  1.0
|   |--  1.0
|--  1.2.3
|   |--  1.1.1
|   |--  6.15.2
|   |--  1.0
|   |--  1.0
|--  1.0
Building in release mode
Retrieving maximum program size .pio\build\esp32dev\firmware.elf
Checking size .pio\build\esp32dev\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  15.4% (used 50552 bytes from 327680 bytes)
Flash: [========= ]  88.9% (used 1165209 bytes from 1310720 bytes)
Configuring upload protocol...
AVAILABLE: esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esptool
Looking for upload port...
Auto-detected: COM4
Uploading .pio\build\esp32dev\firmware.bin
esptool.py v2.6
Serial port COM4
Connecting........___
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, Coding Scheme None
MAC: 30:ae:a4:25:a9:e4
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 15872 bytes to 10319...

Writing at 0x00001000... (100 %)
Wrote 15872 bytes (10319 compressed) at 0x00001000 in 0.2 seconds (effective 521.6 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 128...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (128 compressed) at 0x00008000 in 0.0 seconds (effective 1535.5 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Writing at 0x0000e000... (100 %)
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 4107.3 kbit/s)...
Hash of data verified.
Compressed 1165328 bytes to 657347...
Writing at 0x00010000... (2 %)
Writing at 0x00014000... (4 %)
Writing at 0x00018000... (7 %)
Writing at 0x0001c000... (9 %)
Writing at 0x00020000... (12 %)
Writing at 0x00024000... (14 %)
Writing at 0x00028000... (17 %)
Writing at 0x0002c000... (19 %)
Writing at 0x00030000... (21 %)
Writing at 0x00034000... (24 %)
Writing at 0x00038000... (26 %)
Writing at 0x0003c000... (29 %)
Writing at 0x00040000... (31 %)
Writing at 0x00044000... (34 %)
Writing at 0x00048000... (36 %)
Writing at 0x0004c000... (39 %)
Writing at 0x00050000... (41 %)
Writing at 0x00054000... (43 %)
Writing at 0x00058000... (46 %)
Writing at 0x0005c000... (48 %)
Writing at 0x00060000... (51 %)
Writing at 0x00064000... (53 %)
Writing at 0x00068000... (56 %)
Writing at 0x0006c000... (58 %)
Writing at 0x00070000... (60 %)
Writing at 0x00074000... (63 %)
Writing at 0x00078000... (65 %)
Writing at 0x0007c000... (68 %)
Writing at 0x00080000... (70 %)
Writing at 0x00084000... (73 %)
Writing at 0x00088000... (75 %)
Writing at 0x0008c000... (78 %)
Writing at 0x00090000... (80 %)
Writing at 0x00094000... (82 %)
Writing at 0x00098000... (85 %)
Writing at 0x0009c000... (87 %)
Writing at 0x000a0000... (90 %)
Writing at 0x000a4000... (92 %)
Writing at 0x000a8000... (95 %)
Writing at 0x000ac000... (97 %)
Writing at 0x000b0000... (100 %)
Wrote 1165328 bytes (657347 compressed) at 0x00010000 in 15.7 seconds (effective 594.5 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
=================================================== [SUCCESS] Took 41.99 seconds ===================================================
--- Available filters and text transformations: colorize, debug, default, direct, esp32_exception_decoder, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at http://bit.ly/pio-monitor-filters
Please build project in debug configuration to get more details about an exception.
See https://docs.platformio.org/page/projectconf/build_configurations.html
--- Miniterm on COM4  115200,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
Jun  8 2016 �Booting
Wifi Connected
<IP_ADDRESS>
Started up
Is Calibrated 0
[E][camera.c:1049] camera_probe(): Detected camera not supported.
[E][camera.c:1249] esp_camera_init(): Camera probe failed with error 0x20004
E (1423) SPIFFS: mount failed, -10025
[E][SPIFFS.cpp:72] begin(): Mounting SPIFFS failed! Error: -1
Started calibration
Camera capture failed

Perhaps it is something to do with the versions of the one or more of the components i am using.
There are no lib dependencies in your platformio.ini file?
These are the libraries that my Platform IO is using when building the binarys:

Hey Joe,
I can see the problem. when you are running make upload_fs it's failing to upload the SPIFFS filesystem which is why when you run the code the SPIFFS fail to mount.
You are successfully uploading the firmware manually, but that upload is independent of the file system.
It's a bit weird the way SPIFFS work. The upload of SPIFFS is completely separate from the firmware upload.
You need to upload the firmware and you need to upload the SPIFFS they are two operations.
Whe you run:
make upload_fs

It's failing at this point:
. ./venv/bin/activate && cd firmware && platformio run --target uploadfs
/bin/sh: 1: platformio: not found
Makefile:19: recipe for target 'upload_fs' failed
make: *** [upload_fs] Error 127

This means that plaformio is not installed in the virtual environment that Make is using.
Can you run:
. ./venv/bin/activate
pip install platformio

and then do:
make upload_fs

Alternatively, you can manually upload the file system using the steps here - https://github.com/atomic14/self-organising-leds/issues/2#issuecomment-661764395
Chees
Chris

ah that's done it!
I ran the upload file system image option from platformio and after a reboot i can access the interface :)
I saw that option before, but i guess i hasn't really considered that the spiffs data was different from the actual firmware
I guess also my whole experience was slightly more complicated as im running windows, i was able to get the commands to run correctly in WSL so i just assume i would be able to follow the guide as is, but i think it also could use a little more details , i.e. the versions of Yarn and Node that are needed and how you go about getting them (not sure if it need all that detail as i was able to source that myself easy enough) or how the process could be run on windows
Either way, i've got it working now and i'm looking forward to playing around with it to get some structure to my unstructured leds strings :)

Ah right - I was going to ask if you were on windows as that does make it a bit more tricky! But I think WSL is a bit of game-changer nowadays.
Really pleased you've got it working - if you can think of any additions to the README to help other people get up and running that would be really useful.
Thanks for being the first guinea pig :)

No Worries, i'll piece together the steps i had to follow to get it working and put in a pull request.
Using WSL made it really easy, its just the platfomIO step doesn't work, so I'll see if i can solve that, as it does look like it is installed, but has trouble starting because the WSL is using a mnt point as the root folder


Use native Blob on Node.js 15.7.0

See https://github.com/nodejs/node/pull/36811
Node.js 15.7.0 is required

Fixed in https://github.com/node-fetch/fetch-blob/commit/689bee122b8c7764744a1c7e6e0c5d49af63bd4b
@xxczaki @jimmywarting Can one of you do a release?

Fixed in https://github.com/node-fetch/fetch-blob/commit/689bee122b8c7764744a1c7e6e0c5d49af63bd4b
@xxczaki @jimmywarting Can one of you do a release?

Are you sure fetch-blob is the right place to make the fix? In my opinion, an option inside node-fetch would suit this better. For example, you can pass a fetch option in Ky: https://github.com/sindresorhus/ky/#fetch

Are you sure fetch-blob is the right place to make the fix? In my opinion, an option inside node-fetch would suit this better. For example, you can pass a fetch option in Ky: https://github.com/sindresorhus/ky/#fetch

We need to make the API just work. Adding an extra option that deviates from the fetch spec might not be a good idea unless there's a problem we need to avoid.

We need to make the API just work. Adding an extra option that deviates from the fetch spec might not be a good idea unless there's a problem we need to avoid.

Tests are failing.

Tests are failing.

Good point. I think we'll either want to make Node.js Blobs pass the tests and adjust fetch-blob to work more closely as a polyfill or the other way round.

Good point. I think we'll either want to make Node.js Blobs pass the tests and adjust fetch-blob to work more closely as a polyfill or the other way round.

Oh sweet, native blob support!
well, one thing that was brought up was
// eventually
const blob1 = await fs.promises.readAsBlob('path/to/some/file1')
// blob1 identifies a persistent memory location where blob data is stored.

We have that support already, we made it like so: const blob = require('blob/from.js')(path)
I first thought about putting it on Blob.of(path) or Blob.from(path) but wanted it to be more closer to the spec

Seems to live at buffer.Blob I thought that was a weird place to put it... think it should have been put in utils like TextDecoder was and eventually move it into the globalThis, but whatever.

I guess Node's Blob don't yet support .stream()? cuz of whatwg stream is missing?
and it's missing fs.readAsBlob also?
and the only way to get a Blob instance is by constructing them with data you already have in the memory

We have already based ours on blob parts instead a being a buffer container containing all data like it was before when we didn't have blob-from-path. And because of that our fetch-blob can support other blob-like parts that isn't the same instanceof itself as long as it behaves as a Blob and have a way to read them. this is thanks to that it now operates on parts and not a single buffer container like how node's buffer.Blob implementation is at the moment.
So it could be possible to wrap them in such a way like this if we would like to do that:
import FetchBlob from 'fetch-blob'
import blobFromPath from 'fetch-blob/from.js'
import { Blob } from 'buffer'

var native = new Blob()
var fetchBlob = new FetchBlob([native, blobFromPath('./package.json')])

If you do want to upload something big, then you want to read the blob as a stream, hence why Blob.prototype.stream() exist. and you probably would want to use fetch-blob/from since there isn't any fs.promises.readAsBlob yet that can references a 2+ gb large file
fetch(url, {
  method: 'POST',
  body: blob_2gb
})

There is some pro and cons to nodes and fetchs blob

fetch-blob have blob/from that can handle very large files that makes it more superior to handle large data

nodes blob can yet only be constructed and behave more like a (Array)Buffer for now

fetch-blob have have .stream() support (all doe it's a node stream and not a whatwg stream)

we could technically polyfill stream by patching Blob.prototype.stream if it don't exist or create some "make-chunked-node-stream-from-blob" function that slices and read from slice(start, end).arrayBuffer() as a fallback if .stream() don't exist

Node's blob can be sent via MessagePort to multiple destinations without transfering or immediately copying the data that makes it more superior than fetch-blob

but since they can only be constructed for now what makes it more useful than using the transferable argument?postMessage(arrayBuffer, [arraybuffer]) sure you can send it to multiple destinations but i don't see that as normal huge usecase, you either slice and send or only use one destination

fetch-blob constructor can accept a native NodeJS blob part, NodeJs blob can't?

So you have to weight in if you either want to have support for large data with blob/from or if you want to be able to send them over postMessage to multiple destinations

IMO i think large data have a better usecase for now. We have talked about it before and Blob & Files have yet no real usecase in the NodeJS land if they can only be constructed. then you can as well stick with the buffer or string that you already have declared as a variable. and do things with it. the really good usecase starts to come when you must handle large data and have to do so with blob's backed up by the filesystem, the 2nd good usecase is to create workers from URL.createObjectURL(blob) but node haven't supported it yet 3th usecase would be as mention earlier, sending postMessage to multiple destinations without copying data, but that is only useful if you want to send to multiple destinations and don't want to transfer data and loose the information

since node's native blob are currently experimental and lacks support for .stream() and blob-from-path then i would want to hold off from using it currently. I would like to at least first see support for fs.promises.readAsBlob before considering replacing fetch-blob with native buffer.Blob

Oh sweet, native blob support!
well, one thing that was brought up was
// eventually
const blob1 = await fs.promises.readAsBlob('path/to/some/file1')
// blob1 identifies a persistent memory location where blob data is stored.

We have that support already, we made it like so: const blob = require('blob/from.js')(path)
I first thought about putting it on Blob.of(path) or Blob.from(path) but wanted it to be more closer to the spec

Seems to live at buffer.Blob I thought that was a weird place to put it... think it should have been put in utils like TextDecoder was and eventually move it into the globalThis, but whatever.

I guess Node's Blob don't yet support .stream()? cuz of whatwg stream is missing?
and it's missing fs.readAsBlob also?
and the only way to get a Blob instance is by constructing them with data you already have in the memory

We have already based ours on blob parts instead a being a buffer container containing all data like it was before when we didn't have blob-from-path. And because of that our fetch-blob can support other blob-like parts that isn't the same instanceof itself as long as it behaves as a Blob and have a way to read them. this is thanks to that it now operates on parts and not a single buffer container like how node's buffer.Blob implementation is at the moment.
So it could be possible to wrap them in such a way like this if we would like to do that:
import FetchBlob from 'fetch-blob'
import blobFromPath from 'fetch-blob/from.js'
import { Blob } from 'buffer'

var native = new Blob()
var fetchBlob = new FetchBlob([native, blobFromPath('./package.json')])

If you do want to upload something big, then you want to read the blob as a stream, hence why Blob.prototype.stream() exist. and you probably would want to use fetch-blob/from since there isn't any fs.promises.readAsBlob yet that can references a 2+ gb large file
fetch(url, {
  method: 'POST',
  body: blob_2gb
})

There is some pro and cons to nodes and fetchs blob

fetch-blob have blob/from that can handle very large files that makes it more superior to handle large data

nodes blob can yet only be constructed and behave more like a (Array)Buffer for now

fetch-blob have have .stream() support (all doe it's a node stream and not a whatwg stream)

we could technically polyfill stream by patching Blob.prototype.stream if it don't exist or create some "make-chunked-node-stream-from-blob" function that slices and read from slice(start, end).arrayBuffer() as a fallback if .stream() don't exist

Node's blob can be sent via MessagePort to multiple destinations without transfering or immediately copying the data that makes it more superior than fetch-blob

but since they can only be constructed for now what makes it more useful than using the transferable argument?postMessage(arrayBuffer, [arraybuffer]) sure you can send it to multiple destinations but i don't see that as normal huge usecase, you either slice and send or only use one destination

fetch-blob constructor can accept a native NodeJS blob part, NodeJs blob can't?

So you have to weight in if you either want to have support for large data with blob/from or if you want to be able to send them over postMessage to multiple destinations

IMO i think large data have a better usecase for now. We have talked about it before and Blob & Files have yet no real usecase in the NodeJS land if they can only be constructed. then you can as well stick with the buffer or string that you already have declared as a variable. and do things with it. the really good usecase starts to come when you must handle large data and have to do so with blob's backed up by the filesystem, the 2nd good usecase is to create workers from URL.createObjectURL(blob) but node haven't supported it yet 3th usecase would be as mention earlier, sending postMessage to multiple destinations without copying data, but that is only useful if you want to send to multiple destinations and don't want to transfer data and loose the information

since node's native blob are currently experimental and lacks support for .stream() and blob-from-path then i would want to hold off from using it currently. I would like to at least first see support for fs.promises.readAsBlob before considering replacing fetch-blob with native buffer.Blob

I think we can start of with the easiest thing first to support accepting buffer.Blob as an input for new Request(url, {body: Blob}) and new Response(blob). then we can decide if (request || response).blob() should return a buffer.Blob or a fetch-blob at the very least it has to return a blob with a .stream() functionality.

I think we can start of with the easiest thing first to support accepting buffer.Blob as an input for new Request(url, {body: Blob}) and new Response(blob). then we can decide if (request || response).blob() should return a buffer.Blob or a fetch-blob at the very least it has to return a blob with a .stream() functionality.

PR/Issue for supporting native blob with any kind of stream or async iterator as input have been made
#1091 -> #1092
Still doe, Buffer.Blob.prototype.stream are still missing, whatever kind of stream they implement we will support it in the feature


make tests run on 32-bit archs

On 32-bit architectures, the value of a constant used in trie_test.go would overflow a signed int:
$ GOARCH=386 go test -v ./...
# github.com/yl2chen/cidranger [github.com/yl2chen/cidranger.test]
./trie_test.go:551:8: constant<PHONE_NUMBER> overflows int
FAIL	github.com/yl2chen/cidranger [build failed]

We address the issue by using an unsigned 32-bit integer type instead.

Coverage remained the same at 91.234% when pulling 58d8bc23c099f8c67e8953ed4d759e13cdebf937 on satta:trie-test-32bit into e434ea71859d4e032b1b9ce2f443ec4a960ad2b5 on yl2chen:master.


Add video page on storefront

According to the design in Figma  #656

Closing this as storefront is deprecated


Dependabot force-pushes an existing update PR and also creates a new one for the same update

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
Bundler
Package manager version
bundler 2.4.22
Language version
ruby 3.3.0.rc1
Manifest location and content before the Dependabot update
No response
dependabot.yml content
No response
Updated dependency
Here's a partial YAML file
updates:
  - package-ecosystem: bundler
    directory: "/"
    schedule:
      interval: "daily"
      time: "02:00"
      timezone: "UTC"
    reviewers:
      - Shopify/rails
    labels:
      - "Gem upgrades"
    open-pull-requests-limit: 100
    insecure-external-code-execution: allow
    registries: '*'
    ignore:
    - dependency-name: "whatever" # some ignores, unrelated to the gems I've seen the issue with

What you expected to see, versus what you actually saw
What happens
On the same day, Dependabot:

created a PR titled "Bump debug from dea10b5 to 557233a" (11:23 AM GMT+9)
force-pushed 3 branches for PRs updating the debug gem

@dependabot force-pushed the dependabot/bundler/debug-cbd0f71 branch from 8951669 to 8c62606 (time: 6:23 PM GMT+9)
(original PR title: "Bump debug from dea10b5 to cbd0f71")
@dependabot force-pushed the dependabot/bundler/debug-2bdb8f8 branch from 7210076 to 570549b (time: 6:25 PM GMT+9)
(original PR title: "Bump debug from dea10b5 to 2bdb8f8")
@dependabot force-pushed the dependabot/bundler/debug-d4feeae branch from 437d318 to 875d313 (time: 6:26 PM GMT+9)
(original PR title: "Bump debug from dea10b5 to d4feeae")

Even though one of those earlier PRs had comments on it, none had additional commits.
After that happened, all 4 PRs were showing the exact same diff, with Gemfile.lock pointing to the same revision.
diff --git a/Gemfile.lock b/Gemfile.lock
index 5f3eb9a5ea95..13e0a60263a7 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -312,10 +312,10 @@ GIT

 GIT
   remote: https://github.com/ruby/debug.git
-  revision: dea10b50f2ca65ab3401ef28961b960cd087f98f
+  revision: 557233a90ff623c7dd00384a08471e5a5514f688
   specs:
-    debug (1.8.0)
-      irb (>= 1.5.0)
+    debug (1.9.0)
+      irb (~> 1.10)
       reline (>= 0.3.8)

 PATH

What I expected to see
Well, 3 open PRs updating the same gem should not co-exist in the first place, but when Dependabot created a new PR, I would expect it to close the outdated ones, not to force-push the same change to all of them.

Please note that this has been observed with multiple gems, here are 2 more examples:

google-cloud-ai_platform-v1

Bump google-cloud-ai_platform-v1 from 0.30.0 to 0.35.0
Bump google-cloud-ai_platform-v1 from 0.30.0 to 0.34.0
Bump google-cloud-ai_platform-v1 from 0.30.0 to 0.33.0

aws-sdk-sns

Bump aws-sdk-sns from 1.67.0 to 1.70.0
Bump aws-sdk-sns from 1.67.0 to 1.68.0

All the PRs above were still open yesterday until I closed the old ones.
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response

Since I last cleaned up outdated Dependabot PRs in our repository, 3 weeks ago, 11 update PRs have been made redundant by PRs created more recently by Dependabot.
For example Faraday:


infocfg -> keyisstring

FALSE as value for this config results in marshaling error from Go code

Solved in 0a350753b3cb3d85c4b51a5fc1089dd12760ae48 which also permited composite keys. All values are always internally converted to strings, some care must be taken when numerical precision must be involved; the same with dates


Build wasm32 via Nix

Codecov Report
Base: 72.47% // Head: 72.45% // Decreases project coverage by -0.01% :warning:

Coverage data is based on head (e6a3083) compared to base (884206f).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #610      +/-   ##
==========================================
- Coverage   72.47%   72.45%   -0.02%
==========================================
  Files          85       85
  Lines       11543    11550       +7
==========================================
+ Hits         8366     8369       +3
- Misses       3177     3181       +4

Impacted Files
Coverage Δ

fedimint/src/consensus/mod.rs
92.76% <0.00%> (-0.22%)
:arrow_down:

modules/fedimint-mint/src/lib.rs
90.43% <0.00%> (-0.19%)
:arrow_down:

fedimint/src/net/peers.rs
92.96% <0.00%> (+0.26%)
:arrow_up:

fedimint-api/src/db/sled_impl.rs
47.27% <0.00%> (+1.43%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Everything passed, but for some reason github actions fail to report the result from "Build wasm32" step.

Ah.... right... I'm removing that step. No wonder.

Will try #624 first instead.

Is this still needed now?