text:
Create registration task

I'm starting the work on a registration task with this PR. See overview here: https://github.com/fractal-analytics-platform/fractal-tasks-core/issues/39
The goal is to have basic tasks that perform the necessary functionality in fractal-tasks-core and then have more complex tasks with heavier dependencies in other packages (some will fit well into scmultiplex, maybe some 3D image-based registration task will be its own package).
The registration will be split up into multiple tasks. The following parts are in scope for this first PR:
1. Calculate registration
Tasks that calculate the transformation needed for registration and store this information in the OME-Zarr. This runs for each cycle of each well (parallelization on the image level)

2D image-based registration task
2D label-based registration task => will go into scmultiplex
(later also 3D registration tasks, but those aren't in scope for this PR)

2. Applying registration to ROI tables
One way we can use registration is by adapting the ROI tables. That way, we don't need to change any of the image data, but all our ROI-based loading and ROI-based visualization should work well with it.
Needs to read in tables from multiple cycles, thus runs on a per-well level
3. Applying registration to images
Actually changing the image data based on the transformation that were calculated.
The benefits of doing this separately from step 1:

We can (optionally) perform the registration such that only the consensus region between all cycles remain (not possible in the per cycle calculation)
We can perform the calculation at a lower resolution if desired
Flexibility and logical separation between calculating the registration and applying it: We may not always want to burn-in registration into the images. This gives us a flexible way where the user can add a task to perform the alignment on the images or they can be content with 1 (& optionally 2)

Downside is having to load some image data twice.

Out of scope for this PR, but worth investigating: Finding a better way to store transformation in the OME-Zarr either in line with the upcoming transformation spec for OME-NGFF (still a bit underdefined and still developing) or by adopting the same method as the SpatialData people are using (see e.g. https://spatialdata.scverse.org/en/latest/design_doc.html) [that should eventually make its way into OME-NGFF. I couldn't figure out how they save it to the on-disk OME-Zarr for now, but will investigate more]

TODOs:

[x] 2D image-based registration task
[x] Apply registration to ROI tables task
[x] Apply registration to 2D images task
[x] Run tasks through local Fractal setup
[x] Test task on small 3D dataset
[x] Come up with relevant test data to run tests on the tasks

Polishing:

[ ] Unit tests for helper functions
[x] Tests for full tasks on real data

Open questions:
Interaction with 2D to 3D workflows: If we align 2D, does that somehow link back to 3D data? Gets tricky! Certainly not in initial version

While developing the Apply registration to ROI tables task task, I now noticed the following:
Having a reset-origin removes the ability for using ROI tables to shift cycles vs. each other without modifying the data. Because even if we correctly modify the ROI starting position to shift it by the necessary amounts, reset-origin then gets around this again.
See issue here: https://github.com/fractal-analytics-platform/fractal-tasks-core/issues/339
I'll think about it some more whether in that context, the complexity of having non-0 origins be handled via these resets is still the correct decision.

One way around this for the time being:
We reset origins of the ROI tables before applying the translations. I'll investigate this as a solution while we consider options in #339

I added a first version of applying the registration to ROI tables now. Needs some polish (some doc building is failing). I also have some tests that need to be polished and added.
Also need some extra checks on whether certain alignment scenarios could produce negative ROI coordinates (when it should now be 0-based) and figure out how to fix that best.
Next steps:

Add support to apply registration to different ROI tables (e.g. FOV registration => add to well). Check whether that makes sense
Add a task that burns this into images. e.g. create Zarr array of 0s for whole well, then write one ROI at a time based on the registered ROIs (=> only writes the correctly aligned part)

I now tested all 3 new tasks successfully. They are run in the following order:
Calculate 2D registration (image-based)
Apply Registration to ROI Tables
Apply Registration to Image
Here are some aligned outputs vs. non aligned inputs:
Inputs:

Outputs:

It still works on some dummy 3D datasets => algorithms handle 2D & 3D data. Not sure how well the Calculate 2D registration (image-based) task will perform both memory-wise and on finding correct transformation on more complex 3D registration problems though

Here's an example workflow based on example 03. I think it will make sense to update example 03 with this once we have this task released.
workflow-export-Workflow multiplex-3-1692632697640.txt

What remains to be done:

[ ] Better handling of tables when running Apply Registration to Image
[ ] Come up with relevant test data to run tests on the tasks with real data => test correct registration calculated (in ROI table), correct shift applied to ROI tables, images are 0-padded correctly afterwards (still same shape though)

Future improvements

[ ] Unit tests for more of the helper functions in the tasks would be helpful (check testing coverage to see whether the main tests cover them already)
[ ] Implement a registration that works better at different resolutions (the current scikit-image based one works well at level 2 on our test data, but "fails", i.e. predicts 0 shifts, at level 0).
[ ] Become more robust for different imaging dimensionalities (e.g. test on czx data from the MD)

With https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/487/commits/a1527ae8d2331e3d77c2d1756efd3553dd6d762d, I added tests/tasks/test_registration.py (@jluethi, feel free to rename/refactor as you prefer).
By modifying
def test_multiplexing_registration(
    zenodo_images_multiplex_shifted: list[str],
):
    debug(zenodo_images_multiplex_shifted)

you should be able to write a test workflow that creates an OME-Zarr and then calls any of the registration-related tasks.
The zenodo_images_multiplex_shifted fixture only runs if the tests/data/fake_multiplex_shifted folder does not exist (and it takes about 6 seconds to run), and what it does is to (1) copy the tests/data/fake_multiplex folder, (2) modify all four images of cycle2.
New cycle2 images look like this:

and they are prepared in _shift_image (which is also the function to modify if we want e.g. to replace noise with zeros, or if we want to change the XY shifts).
NOTE: I tend to think that it is correct to set mode="I" in Image.fromarray(...), but I've not tested that the images are then loaded correctly when converting to zarr. I only checked that the file sizes are reasonably similar to the original ones, and that img.show() (in Pillow) shows what I expect. If anything weird happens during zarr-conversion, this may be the actual issue.

Thanks Tommaso, will try to set up some tests with this.
Also, note to myself:

[ ] Add logging to the tasks.
[ ] Figure out what triggers the error below (sometimes, not always. Even for the same dataset!)

They mostly seem to run as expected, but sometimes Apply Registration to Image runs into the following error:
TASK ERROR:Task id: 7 (Apply Registration to Image), e.workflow_task_order=6
TRACEBACK:
2023-08-23 14:11:24,452; INFO; START apply_registration_to_image task
Traceback (most recent call last):
  File "/Users/joel/Library/CloudStorage/Dropbox/Joel/BioVisionCenter/Code/fractal/fractal-demos/examples/server/FRACTAL_TASKS_DIR/.fractal/fractal_tasks_core0.10.0/venv/lib/python3.9/site-packages/fractal_tasks_core/tasks/apply_registration_to_image.py", line 353, in <module>
    run_fractal_task(
  File "/Users/joel/Library/CloudStorage/Dropbox/Joel/BioVisionCenter/Code/fractal/fractal-demos/examples/server/FRACTAL_TASKS_DIR/.fractal/fractal_tasks_core0.10.0/venv/lib/python3.9/site-packages/fractal_tasks_core/tasks/_utils.py", line 79, in run_fractal_task
    metadata_update = task_function(**pars)
  File "pydantic/decorator.py", line 40, in pydantic.decorator.validate_arguments.validate.wrapper_function
    from contextlib import _GeneratorContextManager
  File "pydantic/decorator.py", line 134, in pydantic.decorator.ValidatedFunction.call

  File "pydantic/decorator.py", line 206, in pydantic.decorator.ValidatedFunction.execute

  File "/Users/joel/Library/CloudStorage/Dropbox/Joel/BioVisionCenter/Code/fractal/fractal-demos/examples/server/FRACTAL_TASKS_DIR/.fractal/fractal_tasks_core0.10.0/venv/lib/python3.9/site-packages/fractal_tasks_core/tasks/apply_registration_to_image.py", line 200, in apply_registration_to_image
    old_table_group = zarr.open_group(
  File "/Users/joel/Library/CloudStorage/Dropbox/Joel/BioVisionCenter/Code/fractal/fractal-demos/examples/server/FRACTAL_TASKS_DIR/.fractal/fractal_tasks_core0.10.0/venv/lib/python3.9/site-packages/zarr/hierarchy.py", line 1532, in open_group
    raise GroupNotFoundError(path)
zarr.errors.GroupNotFoundError: group not found at path ''

I figured out what triggered the error above: I was storing the output locally to the Dropbox folder. This one uses a new FileProvider API. Apparently, that one gets confused if I delete a folder (the output folder) and then recreate it before the deletion has synced to the server 🙈
All running as intended now, with some added logs

Github doesn't run the CI anymore on the PR though. Do we need to merge conflicts for that to trigger again?

Yes, the CI was block due to a conflict. I fixed it.

@tcompa I changed the padding to use a constant value. Otherwise, the shift that the registration calculates is not always 100% robust, but can vary slightly. With the constant value, it looks to be more robust.
Also, I added cellpose to that test workflow, because I need to test that label images are copied over by the apply_registration_to_image task. Unfortunately, this adds over a minute to the test runtime. Do we have good ways of just adding mock label images to Zarrs that we use in any other tests? It seems to run now, but not the most efficient.

Do we have good ways of just adding mock label images to Zarrs that we use in any other tests? It seems to run now, but not the most efficient.

You can copy what I did in test_workflows_cellpose_segmentation.py.
First, define a function like patched_segment_ROI, which produces a fake label array. Then you should include monkeypatch in the test function parameters, and use it like

    monkeypatch.setattr(
        "fractal_tasks_core.tasks.cellpose_segmentation.segment_ROI",
        patched_segment_ROI,
    )

In this way, the segment_ROI function of cellpose_segmentation.py is (temporarily) replaced by the patched one, which runs much faster (and is also fully reproducible).

If you need more realistic labels, the other option is to increase level.

Thanks, this monkeypatch approach works great and is very reproducible. It also reduced runtime a lot, even compared to level 4 cellpose.

I have a side observation I'll briefly document here, not related to the PR and not a Fractal bug as far as I can tell, but confused me a bit when analyzing the test data:
In the current napari version I was using (0.5.0a2.dev268+g4ba0e6ac), the intensity image and the labels aren't a perfect overlap when viewing them in napari, if the two are in a different resolution. It isn't that noticeable for level 0 image vs. level 1 label:

But it stands out when using level 4 labels:

The actual shapes are correct, it just looks like the display is shifted by one or a few pixels when displaying low-res labels on high-res images.
It's unrelated to whether registration is applied or not, I think a more general napari thing. But I went digging a bit until I realized our arrays were all fine.

@tcompa The PR would now be ready for review. I think it covers the basic functionality we need.
Some ideas for future improvements

[ ] Real 3D support for Calculate 2D registration: Not reducing to a 2D image anymore, maybe using SimpleITK with Max in an advanced version of this task
[ ] Unit tests for more of the helper functions in the tasks would be helpful (check testing coverage to see whether the main tests cover them already)
[ ] Implement a registration that works better at different resolutions (the current scikit-image based one works well at level 2 on our test data, but "fails", i.e. predicts 0 shifts, at level 0).
[ ] Become more robust for different imaging dimensionalities (e.g. test on czx data from the MD)
[ ] Have a way to transfer shifts between ROI tables? i.e. if they are calculated per FOV, can we transform well table accordingly? Not trivial. For the moment: Apply it to both ROI tables if that is the desire

Self-reminder for something else I should review (from https://github.com/fractal-analytics-platform/fractal-tasks-core/actions/runs/6038282653/job/16384333401?pr=487):
tests/tasks/test_registration.py::test_multiplexing_registration
  /home/runner/work/fractal-tasks-core/fractal-tasks-core/fractal_tasks_core/tasks/apply_registration_to_ROI_table.py:235: RuntimeWarning: invalid value encountered in maximum
    np.maximum(max_df.values, table.values),

I now went through the entire PR once, and it mostly looks good to me!
My current changes can be reviewed with git diff c653f2ed099cd2916ee48cf2b1277413d77c60d6, and they mostly focus on:

Testing of helper functions
Docstrings/comments, type hints, internal logic

Here are some first remarks; it'd be nice if @jluethi can chime (either through commits or through comments that I can implement).

Where should helper functions be? They are currently within the task modules, but some of them look quite general (e.g. get_acquisition_paths, currently in apply_registration_to_ROI_tables.py).
Moving these functions to the core library has some pro's: we can make sure that they are always properly tested, and we can easily make them more consistent with the other core-library functions.
In some cases, however, moving them to the core library would require a lot of effort towards generalization, which is not worth it (e.g. for write_registered_zarr, which is quite specifically related to the way it's used in the apply_registration_to_image.py task).
I propose to move at least some of the functions, e.g. get_table_path_dict and get_acquisition_paths.

As per https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/487#issue-1845308806, I am expecting the calculate-registration task to only consider 2D images. Where can I see that it isn't performing 3D registration? The np.squeeze functions called on the phase_cross_correlation arguments are not meant to remove non-dummy dimensions. I'm missing something here.

I found the names of apply_registration_to_roi_table (helper function) and apply_registration_to_ROI_table (task function) very confusing. I now renamed them to apply_registration_to_single_ROI_table (helper function) and  apply_registration_to_ROI_tables (task function), but I'm happy of any other version that keeps them reasonably different.

It'd be nice to always specify the parallelization level somewhere in the task docstring (on top of having it in the manifest).

Minor issue in apply_registration_to_ROI_tables.py: https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/487/files#r1312686801.

Minor issue in calculate_2D_registration_image_based.py: https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/487/files#r1311606441.

Minor issue in get_acquisition_paths: https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/487/files/043e63d7bb4cca421a0d978d6328c53e0b9208e8#r1312680204.

Other (even less relevant) code comments here in the PR.

I added a couple of FIXMEs for missing docstrings (I included the ones that were obvious, but some were less trivial) or other small changes.

I'll be mostly waiting for feedback on this PR, but later I still want to review a few issues:

[ ] Making sure that all the FIXMEs I introduced are eventually removed
[ ] Reviewing the origin-reset strategy
[ ] Reviewing whether we now have sufficient testing of helper functions (I think so, apart from some very task-specific ones like write_registered_zarr).

Thanks a lot for the review @tcompa !
I addressed the smaller comments. On the larger points:

Where should helper functions be?

I moved get_acquisition_paths, get_table_path_dict and is_standard_roi_table to lib_zarr_utils (first 2, as they are generic for Zarrs) and lib_regions_of_interest (as it's ROI specific). It makes sense to have them in the core library (and refactor as needed to have them there). Feel free to move them to another library file if that fits better.
My impression of the other helper function is that they'd be too specific to the task, thus I would not get them into the core library, at least not as of know.

Question (@jluethi): is it worth moving some of these functions to a lib_registration.py (or similar) module in the core library? Or is each function only relevant for its own task?

I think the other helper functions are task specific. I've not had to import any in another task so far. But happy to move them once that would come up.

As per https://github.com/fractal-analytics-platform/fractal-tasks-core/pull/487#issue-1845308806, I am expecting the calculate-registration task to only consider 2D images. Where can I see that it isn't performing 3D registration? The np.squeeze functions called on the phase_cross_correlation arguments are not meant to remove non-dummy dimensions. I'm missing something here.

Ah, true! Yes, everything is written with 3D in mind otherwise and I've tested it with some 3D images (our tiny test set), thus it should be working for 3D in general. But forgot that squeeze works that way and thought it may be running in 2D mode because of that. But turns out, it's not a 2D specific implementation.
I wouldn't have the highest confidence that this algorithm for 3D registration will be too robust in complex cases, but I've now updated the task name to represent that it's not 2D limited.

I found the names of apply_registration_to_roi_table (helper function) and apply_registration_to_ROI_table (task function) very confusing.

Great, thanks for renaming!

It'd be nice to always specify the parallelization level somewhere in the task docstring (on top of having it in the manifest).

Good idea! I think such information would fit well in the main body of the docstrings. As well as other limitations like e.g. only processing 2D or 3D data or similar things.
Does an entry like Parallelization level: image work? It seems to get parsed correctly into the doc_info.

5-7: Minor issues

I can't make sense of those links. Were they something tagged as FIXME? Or what were the issues?

I added a couple of FIXMEs

I addressed all the once I found. I think this PR contains no more newly introduced FIXMEs.
While fixing some FIXMEs, I changed the handling for axes and added a get_axes_names to the main library. That should make it more robust to figure out which case we're handling (e.g. zyx vs. cyx for 3D arrays). I plan to use this more to implement support for 2D registration from the MD once I have some test data (probably after this PR is merged), see https://github.com/fractal-analytics-platform/fractal-tasks-core/issues/506

Reviewing the origin-reset strategy

Would be great to check this. In my testing, it was robust, i.e. would reset the origin before saving it, thus making it 0, 0, 0 origins for the registered tables. That may be a good strategy in general and then all our origins become simpler.

Reviewing whether we now have sufficient testing of helper functions (I think so, apart from some very task-specific ones like write_registered_zarr).

Would be great if you could have a look whether coverage is ok now. I moved some tests to the main tests (when the functions were moved) and added a few more small tests for the new functions I added.
write_registered_zarr gets some basic testing through the test of the task and given that it's really part of how the task runs, maybe that's enough for the moment?

In summary: I think the issues were addressed now and the PR would be ready to merge after another look at the origin-reset strategy and maybe points 5-7 above. Future work on better MD support will come later.

In summary: I think the issues were addressed now and the PR would be ready to merge after another look at the origin-reset strategy and maybe points 5-7 above.

Great, thanks for all the updates!
Points 5-7 were links to some PR-code comments, which apparently are not robust when they get "resolved". Anyway, they are now all fixed.
I'll review origin&coverage and then this is ready also on my side.

As discussed this morning with @jluethi:

Work on ROI origin shifting will take place in a different PR, based on #339.
Coverage is generally good. There a few non-tested lines here and there, typically related to exceptions, which we can improve in the future; but at least the new core-library functions are 100% tested.
I'm OK with merging this one in the current state, so that it becomes part of the upcoming 0.11.0 version.

authors: jluethi tcompa


text:
cannot find 'fence_mermaid' in the module 'mermaid2'

Hello,
I encounter this following bug:
INFO    -  Building documentation...

MkDocs encountered as error parsing the configuration file: while constructing a Python object
cannot find 'fence_mermaid' in the module 'mermaid2'
  in "/home/unger/tmp/test/mkdocs-mermaid2/mkdocs-mermaid2-plugin/test/mkdocs.yml", line 24, column 19

Steps to reproduce the bug

git clone https://github.com/fralau/mkdocs-mermaid2-plugin

cd mkdocs-mermaid2-plugin
sudo python setup.py install

cd test
python -m mkdocs serve

It seems that mkdocs cannot find fence_mermaid in mermaid2
          format: !!python/name:mermaid2.fence_mermaid

Thanks for your help

This is strange...
In the Python REPL, can you do:
>>> import mermaid2
>>> mermaid2.fence_mermaid
<function fence_mermaid at 0x10e4ab4d0>

Does the function appear?

Thank you @fralau for your quick answer.
Here is the output
% python                                                              20s ~/tmp/test/mkdocs-mermaid2/mkdocs-mermaid2-plugin/test master
Python 3.8.3 (default, May 17 2020, 18:15:42)
[GCC 10.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mermaid2
>>> mermaid2.fence_mermaid
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'mermaid2' has no attribute 'fence_mermaid'
>>>

The mermaid module seems to be found since I get no error in python REPL when I import it.

Here are the versions used when I do
pip install mkdocs-mermaid2-plugin --upgrade :
Defaulting to user installation because normal site-packages is not writeable
Requirement already up-to-date: mkdocs-mermaid2-plugin in /home/unger/.local/lib/python3.8/site-packages (0.1.5.post1)
Requirement already satisfied, skipping upgrade: beautifulsoup4>=4.6.3 in /home/unger/.local/lib/python3.8/site-packages (from mkdocs-mermaid2-plugin) (4.9.1)
Requirement already satisfied, skipping upgrade: setuptools>=18.5 in /usr/lib/python3.8/site-packages (from mkdocs-mermaid2-plugin) (47.1.1)
Requirement already satisfied, skipping upgrade: mkdocs>=1.0.4 in /home/unger/.local/lib/python3.8/site-packages (from mkdocs-mermaid2-plugin) (1.1.2)
Requirement already satisfied, skipping upgrade: soupsieve>1.2 in /home/unger/.local/lib/python3.8/site-packages (from beautifulsoup4>=4.6.3->mkdocs-mermaid2-plugin) (2.0.1)
Requirement already satisfied, skipping upgrade: livereload>=2.5.1 in /home/unger/.local/lib/python3.8/site-packages (from mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (2.6.2)
Requirement already satisfied, skipping upgrade: click>=3.3 in /usr/lib/python3.8/site-packages (from mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (7.1.2)
Requirement already satisfied, skipping upgrade: lunr[languages]==0.5.8 in /home/unger/.local/lib/python3.8/site-packages (from mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (0.5.8)
Requirement already satisfied, skipping upgrade: tornado>=5.0 in /home/unger/.local/lib/python3.8/site-packages (from mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (6.0.4)
Requirement already satisfied, skipping upgrade: Markdown>=3.2.1 in /home/unger/.local/lib/python3.8/site-packages (from mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (3.2.2)
Requirement already satisfied, skipping upgrade: PyYAML>=3.10 in /usr/lib/python3.8/site-packages (from mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (5.3.1)
Requirement already satisfied, skipping upgrade: Jinja2>=2.10.1 in /usr/lib/python3.8/site-packages (from mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (2.11.2)
Requirement already satisfied, skipping upgrade: six in /usr/lib/python3.8/site-packages (from livereload>=2.5.1->mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (1.15.0)
Requirement already satisfied, skipping upgrade: future>=0.16.0 in /usr/lib/python3.8/site-packages (from lunr[languages]==0.5.8->mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (0.18.2)
Requirement already satisfied, skipping upgrade: nltk>=3.2.5; python_version > "2.7" and extra == "languages" in /home/unger/.local/lib/python3.8/site-packages (from lunr[languages]==0.5.8->mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (3.5)
Requirement already satisfied, skipping upgrade: MarkupSafe>=0.23 in /usr/lib/python3.8/site-packages (from Jinja2>=2.10.1->mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (1.1.1)
Requirement already satisfied, skipping upgrade: joblib in /home/unger/.local/lib/python3.8/site-packages (from nltk>=3.2.5; python_version > "2.7" and extra == "languages"->lunr[languages]==0.5.8->mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (0.15.1)
Requirement already satisfied, skipping upgrade: regex in /home/unger/.local/lib/python3.8/site-packages (from nltk>=3.2.5; python_version > "2.7" and extra == "languages"->lunr[languages]==0.5.8->mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (2020.6.7)
Requirement already satisfied, skipping upgrade: tqdm in /home/unger/.local/lib/python3.8/site-packages (from nltk>=3.2.5; python_version > "2.7" and extra == "languages"->lunr[languages]==0.5.8->mkdocs>=1.0.4->mkdocs-mermaid2-plugin) (4.46.1)

Your installed version 0.1.5 does not correspond to the github version (0.2.1).
My best guess is that you did not actually upgrade to the new version?

Contrarily to https://github.com/fralau/mkdocs-mermaid2-plugin/commit/5ccbe4d6a2a67052c303606cb74d30388b48a843 , mermaid2/__init__.py is empty in my system.
cat /home/unger/.local/lib/python3.8/site-packages/mermaid2/__init__.py

Your installed version 0.1.5 does not correspond to the github version (0.2.1).
My best guess is that you did not actually upgrade to the new version?
Thanks for pointing this me out. How can I install it?
Why pip install mkdocs-mermaid2-plugin --upgrade does not suffice?

Your version does not correspond to that on github.

Not sure. Try to uninstall and reinstall?

It did fixed it. I don't why I had a former version in cache, even if I provided "--upgrade".
Thank you very much for help!

No problem. Happy to help 🙂

source: gharchive/issue

authors: fralau kevung

license: MIT

license_type: permissive

license_source: github-api


text:
UI list item border radius - onclick focus inside a card

Framework7 version: latest
Platform and Target: all
Live Link or JSFiddle: (https://framework7.io/docs/cards#examples)

Describe the bug
UI list item inside a card, if press any link you will see top & bottom corner radius don't exist.
To Reproduce
Steps to reproduce the behavior:

crate a card and add some links list
Click on any list item and you will see top and bottom border corners of list items have radius 0, but card has radius.

Please create a CodeSandBox with your code.


text:
errors when using clangd

I am using clangd (18) which is a language server for C and C++.
I get following error in included nappgui headers: At least gcc 4.2 is required.
This is probably a bug

Hi @alex-s168.
Its not a bug, its a safeguard. The lower GCC version used "officially" in NAppGUI CI is 4.6.3 (Ubuntu12) and 4.3 (MacOSX Snow Leopard). Previous versions cannot be guaranteed to work.
With Clang, the lowest version used is 3.0.0 (Ubuntu12).
More info here
https://nappgui.com/en/guide/win_mac_linux.html

I get that but I am using clangd 18. It looks like it doesn't set the preprocessor defines

Check that you really have Clang selected with CMake:
-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
More info here
https://nappgui.com/en/guide/win_mac_linux.html#h8


text:
Question: Jest testing & ignoring tests

I'm using, https://github.com/piotrwitek/react-redux-typescript-starter-kit, which in turn is using the plugin-typescript. Thank for making this.
I trying integrate jest, https://github.com/facebook/jest, and I keep running into an issue     SyntaxError: Unexpected token import. My hypothesis is that the plugin is transpiling tests, they have a tsx extension. Is there a mechanism to blacklist certain folders, e.g. test or something like that?

There is no way currently to blacklist files, but it may be possible using packages configuration. However it sounds to me like the problem is that files are not getting transpiled from es6 modules to common's. That is what the error is saying - there are still import statements in the code which node is trying to run.

@cramhead if the source files are .tsx they need to be transpiled even if they don't contain import export because they will likely contain TypeScript specific syntax as well as jsx syntax. Unless you have conflicting compiler options for your own source or for other dependencies, you should be able to accomplish this by configuring the loader to pass those files through plugin-typescript. As @frankwallis noted  you can accomplish this with package configuration.
This is just an example:
SystemJS.config({
  transpiler: "plugin-typescript",
  packages: {
    jest/tests: {
       "*.tsx": {
         loader: "plugin-typescript"
       }
    }
  }
});

react-redux-typescript-starter-kit uses the ts-jest plugin to compile typescript when running jest. This is all configured in jest.config.json - to run the tests use jest --config ./jest.config.json or npm test and the files should get compiled.
see https://github.com/piotrwitek/react-redux-typescript-starter-kit/blob/master/package.json#L30

authors: aluanhaddad cramhead frankwallis

repo: frankwallis/plugin-typescript

license: mit

license_source: bigquery


text:
🛑 AEOS is down

In 4819723, AEOS (https://www.aeos.net/) was down:

HTTP code: 503
Response time: 1945 ms

Resolved: AEOS is back up in 13a5303 after 9 minutes.

repo: fraserbooth/fb-monitor


text:
NaN when I use a DETR that I fine tuned

Hello, I have a problem when trying to use pvic with a “modified” DETR, I performed a fine tune on the DETR which is found within its repository, when running with the base DETR it works, but with the DETR weights modified by running as follows:

It ends up failing and giving this error:

I found my problem similar to the last two comments on this problem here
Do you have any suggestions on how I can solve this issue?

Hi @JonasFerreiraSilva,
I think the NaN loss only happens occasionally during training. Perhaps you could skip those bad batches by zeroing out the gradient when the loss is NaN. You could do something like this
loss_dict['cls_loss'] = torch.nan_to_num(loss_dict['cls_loss'])

Cheers,
Fred.

@JonasFerreiraSilva
Did you solve this problem? I faced the same error and I modified my code in the 191 line utils.py according to @fredzzhang comments  but the loss is 0.0000.
        loss_dict = self._state.net(
            *self._state.inputs, targets=self._state.targets)
        if loss_dict['cls_loss'].isnan():
            loss_dict['cls_loss'] = torch.nan_to_num(loss_dict['cls_loss'])
            print(f"The HOI loss is NaN for rank {self._rank}")```

Hi @hellog2n,
If that doesn't solve the issue, I think you need to add that function somewhere earlier in the network. See [this post] for reference.
Since it's normally the spatial features that cause the issue, you can add it here.
# Compute spatial features
pairwise_spatial = compute_spatial_encodings(
    [boxes[x],], [boxes[y],], [image_sizes[i],]
)
pairwise_spatial = torch.nan_to_num(pairwise_spatial)

@fredzzhang Thank you for your responding! I solved. :)

@hellog2n Can you share what exactly you did that solved this? Was it what @fredzzhang suggested?

@morrisalp  Hi, did you solve the problem??

repo: fredzzhang/pvic


text:
Launch some Test in free5gc-compose

I have installed the free5gc-compose and it works perfectly. But, could we launch some test like in the Test phase (https://github.com/free5gc/free5gc/wiki/Test)  in the free5gc github project ?

Actually, this is not supported in the current docker version. But you can always try to use a UE/RAN simulator.

authors: Trauck abousselmi


text:
Added Accessibility Question

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)

Adds to #374

Hey, so glad to see this as a new quiz category! I'm happy to add more questions but want to do things in the way that's easiest for the maintainers to keep up with. Is one question per PR the way to go or would multiple at once be a better option?

Hi @preeformance !
Either option works fine.
If you have a list of questions right now, then you can add all of that to the same PR.
When that is merged and you think of new questions then you can create a new PR for those 👍

I'll create a new PR after I write a few more questions. Thanks!

source: gharchive/pull-request


text:
Old Text

Challenge iterate-with-javascript-while-loops has an issue.
It looks like there is some old text leftover from when the for loop section came before the while loop section. Now that while loops are the first time loops are mentioned, this text is confusing and out of place (highlighted in blue).

How about:
The first type of loop we will learn is called a while loop because it runs "while" a specified condition is true and stops once that condition is no longer true..
I'll make a PR if you or mods agree.

Go ahead and drop a PR

@JoolsMcFly thanks!

Ikhf j

Where can I see if this issue is cq should be resolved in the challenge I see in beta?

Beta, deployments are done one every couple of days, maybe you should hold on for a few days and if you still see the issue, then please report back.
Thanks.

authors: JoolsMcFly RebeccaMorris TeejayParker frutsy007 raisedadead spieg

repo: freeCodeCamp/freeCodeCamp


text:
Regular Expressions: Restrict Possible Usernames - Test not working

Describe your problem and - if possible - how to reproduce it
You can cheat this exercise by simply entering /../gi as all the "should match" tests have even digits and all the "should not match" tests are odd. I suggest this is updated so people like myself can not game the system.
Add a Link to the page with the problem
https://learn.freecodecamp.org/javascript-algorithms-and-data-structures/regular-expressions/restrict-possible-usernames
Tell us about your browser and operating system
Using Chrome on Windows 10 - Don't think this will make a difference to the issue though
If possible, add a screenshot here
I don't think it requires one the problem is pretty self explanatory.

The answer that work for is this:-
let username = "JackOfAllTrades";
let userCheck = /\w\D/; // Change this line
let result = userCheck.test(username);

Duplicate of #17733

Closing in favor of the duplicate mentioned

this answer works well:
let userCheck = /^[^0-9][^0-9]\w./; // Change this line

@aligaber Please do not post comments which are not related to the issue.

let username = "JackOfAllTrades";
let userCheck = /^[A-Za-z]+[A-Za-z]+[0-9]*$/; // Change this line
let result = userCheck.test(username);

it works


text:
Test issue for the YouTube video I am creating for FreeCodeCamp

This is a test issue for a video I am creating. Please ignore

Hi. Please don't create spam issues as they create noise for the maintainers.  If you want to experiment, the best approach is to do so on your own fork.

My apologies to the maintainers. I was keen to have the freeCodeCamp repo name in the video as it is for the freeCodeCamp YouTube channel. But I will do this in a fork in the future if this is preferred by the maintainers and the video will just have to show my GitHub username instead

Well, this issue still exists if you want to reference it in your video.  However if you want to create multiple demo issues or PRs, it would be best if you did that in your own fork.  Doing it here means a lot of people will get unnecessary notifications.

authors: eddiejaoude ojeytonwilliams


text:
Missing word in APIs and Microservices Intro

https://github.com/freeCodeCamp/freeCodeCamp/blob/6fac38ef7d724efc469f7918a9e5013210e1f39c/client/i18n/locales/english/intro.json#L293
In this paragraph it seems like the word "apps" in line 293 it could want to say ...write back end-ready apps with Node.js...

Issues labelled with help wanted or first timers only are open for contributions.
Please make sure you read our guidelines for contributing. Join us in our chat room or the forum if you need help contributing, our moderators will guide you through this.


text:
feat(enhancement): Add community dropdown and link to guide pages in …

…primary navigation

Pre-Submission Checklist

[ ] Your pull request targets the staging branch of freeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm test. Use git commit --amend to amend any fixes.

Type of Change

[ ] Small bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[x] Addressed currently open issue (replace XXXXX with an issue no in next line)

Closes #15792
Description

Added Community Dropdown
Added new link to fcc guide pages

@adityaparab thanks for the pull request, while we review this, could you update the PR title and the commit to more sensible scope name as per http://conventionalcommits.org/
For instance in your case it would be nav.
We will have a set of scopes soon to help you in selecting one in future, but for now they are broadly aimed towards a context of the application, in your case its nav (for navigation).
I would also recommend to make the title a little shorter, typically below 50 chars.
You can add more info the description of the commit itself, should you prefer.

@adityaparab This looks and works great! I made a minor commit to it since we recently moved  /about to about.freecodecamp.org and /donate to donate.freecodecamp.org
@BerkeleyTrue I double checked and the map button seems to work OK on the different views. I also checked the drop down on different viewport widths and it looks great! I think we can push this to production.

This is live!  @adityaparab congrats!!

authors: BerkeleyTrue QuincyLarson adityaparab raisedadead


text:
'use strict' mode explanation

Added documentation on Javascript's "use strict" mode
Type of Change

[ ] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)
[x] Improves existing documentation

Checklist:

[x] Tested changes locally.
[x] Addressed currently open issue (replace XXXXX with an issue no in next line)

Closes #16643
Description
Added a line of explanation for the user on Javascript's 'use strict' mode, the first time it appears in the ES6 challenge.

Hi @dabao12321 we are going to have to close this. Please do not be disappointed, we understand you are contributing for the first time, so if you are interested please take a look at our Guidelines for Contributing, when you make a pull request.
And finally this is being closed in favor of #16652 because it has a more  desirable fix.


text:
test(challenges): Corrected expected average value

Modified 8.675 to 8.52 in three places for correct average value
BREAKING CHANGE: n/a
Closes #17561

Pre-Submission Checklist

[x] Your pull request targets the staging branch of freeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm test. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[x] Addressed currently open issue (replace XXXXX with an issue no in next line)

Closes #17561
Description

In the third test for the challenge, I replaced the value 8.675 with 8.52 in the text (x1) and testString (x2). The average expected value is not correct given the 5 ratings in the challenge. I have confirmed via hand calculations and external scripts.

:sparkles: :sparkles: :sparkles: Awesome! Congratulations on your first contribution to freeCodeCamp! :sparkles: :sparkles: :sparkles:
Thank you for submitting an issue and a PR for this, @matthew-t-smith. We're all really looking forward to your next contribution.

authors: matthew-t-smith scissorsneedfoodtoo


text:
Add the SPACE between the ''

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Hi @IsharabAhmed,
Can you explain the reasoning?
Adding a space to the string will make it truthy.
!!''  //false
!!' ' //true


text:
Modified Spanish endings and sentences.

Some of the Spanish endings needed a change from the Usted form (formal) to the informal form (since that is how the article should be written in Spanish).
Modified briefly some sentences to make it more understandable for Spanish readers.

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Is this a difference between European Spanish and LATAM Spanish?

Not really. The modifications I made were based on the original article. The author gives advice such as "go alone", but the translation to Spanish was set to "to go alone", which can be confusing

Thanks @thisislola! 👍 🌋

authors: joshalling lynxlynxlynx thisislola


text:
Welcome from Hactober 2018!

Welcome from Hactober 2018!

[ ] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the master branch of freeCodeCamp.
[ ] None of my changes are plagiarized from another source without proper attribution.
[ ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Hi @Ayzrian,
Thanks for opening this PR.
However, it's low effort PR. So I'm closing this PR and marking it invalid.
Please browser our repo and I'm sure you'll find something you can contribute to.
Happy coding and hoping you'll open another PR soon!


text:
Update README.md

[ ] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the master branch of freeCodeCamp.
[ ] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Hi,
Thanks for this pull request (PR).
Unfortunately, we are marking this PR invalid for hacktoberfest. We believe it does not follow the recommended guidelines:

Quality Standards
In line with Hacktoberfest value #2 (Quantity is fun, Quality is key), we have provided examples of the quality standards we encourage. This applies mainly to beginners.

PRs that are automated e.g. scripted opening PRs to remove whitespace / optimize images.
PRs that are disruptive e.g. taking someone else's branch/commits and making a PR.
PRs that are regarded by a project maintainer as a hindrance vs. helping.
Something that's clearly an attempt to simply +1 your PR count for October.

Learn more at https://hacktoberfest.digitalocean.com/details

authors: RandellDawson waluigi-san


text:
Update index.md

Add three free courses on deep learning. Two from fast.ai that are USF graduate courses and one from Kaggle that is used for people starting to do competition.

[x ] I have read freeCodeCamp's contribution guidelines.
[x ] My pull request has a descriptive title (not a vague title like Update index.md)
[x ] My pull request targets the master branch of freeCodeCamp.
[x ] None of my changes are plagiarized from another source without proper attribution.
[x ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Add new free deep learning courses that are good.

Thanks for contributing to the freeCodeCamp repository. Congratulations on your first PR! 🎊
Look forward to more contributions from you! ✈

authors: fheld thecodingaviator


text:
Add body text and link

Added content and a link to an existing online implementation of the 401k calculator

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 🎉

authors: RandellDawson fmahaztra


text:
Added link to official BS4 documentation

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

@japarado Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝

authors: japarado thecodingaviator


text:
Update implement-quick-sort.spanish.md

Fix wrong spanish translation of the description of the algorithm

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

Fix wrong spanish translation of the description of the algorithm

Thanks!

authors: davidpucheta lynxlynxlynx


text:
Getting latest changes from old fork

[x ] I have read freeCodeCamp's contribution guidelines.
[ x] My pull request has a descriptive title (not a vague title like Update index.md)
[ x] My pull request targets the master branch of freeCodeCamp.
[ x] None of my changes are plagiarized from another source without proper attribution.
[x ] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[ x] My changes do not use shortened URLs or affiliate links.

Closes #XXXXX

Hey, it looks like something went wrong when you created this PR.  Please take another look at the contribution guidelines.

This fork is way behind master.  It needs to be re-synced.


text:
fix(curriculum): "Set Class" description formatting

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] All the files I changed are in the same world language, for example: only English changes, or only Chinese changes, etc.

Couple quick formatting improvements.

@tywmick  Congrats on your first pull request (PR)! 🎉
Thank you for your contribution to the page! 👍
We're happy to accept these changes, and look forward to future contributions. 📝

authors: ojeytonwilliams tywmick


text:
feat(UI): take back to learn map after finishing a block

Checklist:

[x] I have read and followed the contribution guidelines.
[x] I have read and followed the how to open a pull request guide.
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #49170

Now, campers are taken back to the map after finishing a block instead of directly starting the next block step-1 in Responsive Web Design Certification.

Hey @moT01, Can you please review this and let me know if any changes are to be done?

Please rebase and make sure the tests are passing. Thanks.

Please rebase and make sure the tests are passing. Thanks.

Done sir. Now all tests are passing and also I've done the rebase.

Please rebase and make sure the tests are passing. Thanks.
I have successfully done the rebase as you mentioned and also all tests are passing except Firefox.

You would need to update the test for the changed functionality. We have outlined working with tests in our guide. Please reach out to the Discord chat for more help :)

This PR now has irrelevant changes.
I am unsure if you are trying some different method, but this project has specific guidelines about rebasing. There are detailed in the guidelines we linked earlier: https://contribute.freecodecamp.org/#/how-to-open-a-pull-request?id=conflicts-on-a-pull-request

This PR now has irrelevant changes.
I am unsure if you are trying some different method, but this project has specific guidelines about rebasing. There are detailed in the guidelines we linked earlier: https://contribute.freecodecamp.org/#/how-to-open-a-pull-request?id=conflicts-on-a-pull-request

I tried running all the commands following the document that you sent. But still, the tests are failing because of the files that were edited after syncing fork. Please help me out.

I have solved the issue and also all the tests are passing. Kindly review and please let me know any suggestions/changes required. And sorry for the errors that I had made. This being my first contribution, I faced some errors. I'll be more careful from next time onwards.

Thank You so much. I'll do this.

So @DEVelooper29 do you need any help with the PR still ?

I made a few updates to this - it should be good to go.

Do we want to take the camper back to the project they just completed, or to the next project?

Either way works. I like both for their own reasons. Back to the project they just completed means they can see their checkmarks (also, that's how this PR is atm). To the next project is where the next challenge is, so maybe that's better - don't know.

Thank you for your contribution to the page! 👍
We are happy to accept these changes and look forward to future contributions. 🎉


text:
RFC: Should Addw/Subw/Dshlw become "first-class" IR nodes?

Now that #1350 is going to remove the redundancy of WIR nodes that correspond with "augmented" IR nodes in 1.4.0, we should figure out to do with the other WIR nodes.
Some (Addw/Subw/Dshlw) are actually distinct and useful flavors of IR nodes that have slightly different width semantics. I think these are important and we might want to consider including them in the IR.
Other WIR nodes are just random pass-internal pseudo-nodes that people stashed in WIR.scala. I think they should be split out to different places in the code to represent their "lifetimes" in the compiler.
WDefInstanceConnector => only used in VerilogPrep and VerilogEmitter
WVoid, WInvalid => become private to ExpandWhens and perhaps a couple core transforms
EmptyExpression => becomes private to passes.memlib
CDefMPort, CDefMemory => handled in #1210

Argument in favor of inclusion: currently, non-growing ops are used as a bridge to Verilog. However, they also make it possible to match non-growing Chisel operations with a single op.
Argument against inclusion: more code complicates the compiler.

Hedge against compiler complication is the notion of "canonical form" where you choose a subset of nodes and allow transform writers to write against this form. I think it is perfectly sensible to create a "canonical form" as a subset of primops in LowForm to make it easier to write various transforms.

I agree. I think the odd thing is that it could currently be argued that Addw et al. are the "canonical form" despite being absent in the spec :)

I would say they're not canonical form because they can't express expanding addition whereas Add + Tail can express Addw, it's not unusually to go from canonical form to a richer set in order to make emission prettier

I would say they're not canonical form because they can't express expanding addition whereas Add + Tail can express Addw

I mean they CAN ... but your point is a great one nonetheless.

It seems to me addw ≡ tail(add(a, b), 1), and the inlined form could be treated as Addw in the parts of the compiler where you care, but otherwise not need any other sort of support. Are inlined operators like this unfriendly to firrtl as currently implemented?

I'm against these for the sole reason that they exist in the FIRRTL compiler to represent the semantics of a single backend (Verilog). As new backends and front ends proliferate, it seems more natural to have a canonical IR as opposed to allowing the set of IR nodes to increase, though that would be a tempting option. I admit that *w operators straddle this boundary as they do seem useful and exist in Chisel (though I wouldn't let the Chisel API guide the IR nodes selection).
A better approach, albeit enormously more complicated, would be to explore a notion of "dialects" in FIRRTL that would allow new operators to be added. The necessary support for this would likely be another enormous infrastructure refactor.

It seems to me addw ≡ tail(add(a, b), 1), and the inlined form could be treated as Addw in the parts of the compiler where you care, but otherwise not need any other sort of support. Are inlined operators like this unfriendly to firrtl as currently implemented?

There are places in the compiler where these kinds of multi-level expression trees end up getting divided, but they are generally supported, and there isn't any pass between PadWidths and VerilogEmitter that would break them up.
The approach you're describing is what I'd like to do if we decide against including the Xw operators in the IR. It's already the strategy CombineCats uses to improve Verilog emission.

It seems to me addw ≡ tail(add(a, b), 1), and the inlined form could be treated as Addw in the parts of the compiler where you care, but otherwise not need any other sort of support. Are inlined operators like this unfriendly to firrtl as currently implemented?

One nice new thing is that #1241 made it strictly true that addw ≡ tail(add(a, b), 1). This was not the case before that PR if a and b were both zero-width. I think this change is an extra point in favor of dropping Addw et al.

So it currently seems like nobody actually wants these as first-class IR nodes. I am certainly not a fan of adding more stuff if it's not necessary.
In a similar vein, I am generally in favor of the idea of "custom IR nodes." However, it seems like the general feeling is that pattern-matched op-tail subtrees could provide identical benefits in the narrow context where Dshlw et al. are used, without the potential for breaking downstream code. This pattern-matched subtree approach is also used by CombineCats.
To me, this makes it seem like the current use of Dshlw isn't a great motivating example for custom ops. I think we should wait to have a great motivating use case before adding new APIs that potentially affect all transforms.
My current vote for fixing the many wrap-op issues is eliminating them for 1.4.0. I already have some code for replacing them with pattern-matched subtrees, and I can roll that into #1350.

I think custom IR nodes makes a lot of sense. :+1: addw and friends may, as you suggest, be too simple of a motivating case. I think this is because their rewrite rules are pretty simple. I.e., an Expression => Expression.
More complex examples in terms of types might, in order of complexity, include:

FixedPoint (How could we rewrite FixedPointToSInt and PadWidths where the special sauce for the custom nodes is encoded not in the transforms, but in the actual custom node?)
Floating Point (Transforming 1.0 + 2.0 would, at minimum, be Expression => Statement and likely require emission of an FPU instance to handle this. However, it seems very useful to be able to just pass around floating point types and lower them later.)
Tensors

More complex ops could include:

Vector operations
Cross module references

I expect the complexity here is that we need to think about how to generalize some transforms to work on custom types where the custom types define how transforms use them. "Common" transforms should likely work across all types and custom types, i.e., Common Subexpression Elimination, Dead Code Elimination, (to-be-written Global Value Numbering), Inlining, Flattening, etc. At minimum, anything custom would need to define how it is lowered to canonical IR. I think that then existing transforms would have to know to ignore custom IR nodes and conservatively excluded them from any optimizations.
tl;dr: enormous infrastructure rabbit hole...

I think custom IR nodes makes a lot of sense. 👍 addw and friends may be, as you suggest, too simple of a motivating case. I think this is because their rewrite rules are pretty simple. I.e., an Expression => Expression.

Exactly. My concern with addw is not the work in adding the infrastructure, but that the infrastructure invariably takes some flavor from the set of pre-existing motivating use cases, which would possibly lead to some contrived decisions if those were only the wrap ops.

Not to pull the conversation in a random direction, but I these custom IR nodes may have some similar flavor to a pattern I've been running in to:

Start off with a := f(b) being implemented by making an ExtModule (or empty DefModule with DontTouch, whatever, it's just a placeholder to block optimization passes until the implementation gets filled in), with a and b as outputs and inputs to the module.
Run the FIRRTL compiler until things have been lowered to a point that is convenient to run whatever analysis is needed
Replace the ExtModule with some implementation, which may also get inlined, optimized, etc.

I think this pattern could apply to custom IR nodes. It's a little silly for something like Addw because we can immediately fill in the implementation, but for more sophisticated things I think it is helpful. FixedPoint is actually a great example. You could have a FixedPoint be an SInt with an annotation for it's binary point, emit a bunch of placeholder modules for the various operations, and then a transform comes in and implements the logic for doing those operations.
The tricky bit would be dealing with inference, but I think having an API for adding constraints could be generically useful (e.g. marking an ExtMod as having an output width that is a function of both input width and binary point).

authors: albert-magyar grebe jackkoenig seldridge

repo: freechipsproject/firrtl


text:
Format src 3

Contributor Checklist

[-] Did you add Scaladoc to every public function/method?
[-] Did you update the FIRRTL spec to include every new feature/behavior?
[-] Did you add at least one test demonstrating the PR?
[-] Did you delete any extraneous printlns/debugging code?
[x] Did you specify the type of improvement?
[x] Did you state the API impact?
[x] Did you specify the code generation impact?
[x] Did you request a desired merge strategy?
[x] Did you add text to be included in the Release Notes for this change?

Type of Improvement
Code cleanup
API Impact
None
Backend Code Generation Impact
None
Desired Merge Strategy
Squash
Release Notes
Firrtl source code has been machine reformatted with scalafmt. All PR's to this repo must now be
formatted correctly in order to pass CI.
Reviewer Checklist (only modified by reviewer)

[ ] Did you add the appropriate labels?
[ ] Did you mark the proper milestone (1.2.x, 1.3.0, 1.4.0) ?
[ ] Did you review?
[ ] Did you check whether all relevant Contributor checkboxes have been checked?
[ ] Did you mark as Please Merge?

I rebased this to include changes from https://github.com/freechipsproject/firrtl/pull/1839
And by rebased, I mean I cherry-picked the first commit adding the ability to run Scalafmt, I completely redid the second commit by rerunning scalafmtAll but committed it as Chick with the same message. Then cherry-picked the 3 following commits.

Closing in favor of https://github.com/freechipsproject/firrtl/pull/1852

authors: chick jackkoenig


text:
UnionLists overwrite list/leaf type of subtypes

It seems my fix for unionlists of subtypes not becoming lists had a sideeffect overwriting the subtype itself ( see #60 ).
I am not completely sure how we should to fix this, but at least I have a testcase that demonstrates the problem.
diff --git a/nodeutil/json_rdr_test.go b/nodeutil/json_rdr_test.go
index 2b638a6..3d1def8 100644
--- a/nodeutil/json_rdr_test.go
+++ b/nodeutil/json_rdr_test.go
@@ -124,6 +124,46 @@ func TestJsonRdrTypedefUnionList(t *testing.T) {
        }
 }

+func TestJsonRdrTypedefMixedUnion(t *testing.T) {
+       mstr := `
+    module x {
+        revision 0;
+        typedef ip-prefix {
+            type union {
+                type string;
+            }
+        }
+        leaf-list ips {
+            type ip-prefix;
+        }
+        leaf ip {
+                type ip-prefix;
+        }
+}
+        `
+       m, err := parser.LoadModuleFromString(nil, mstr)
+       if err != nil {
+               t.Fatal(err)
+       }
+       tests := []struct {
+               in  string
+               out string
+       }{
+               {
+                       in:  `{"ips":["10.0.0.1","10.0.0.2"],"ip":"10.0.0.3"}`,
+                       out: `{"ips":["10.0.0.1","10.0.0.2"],"ip":"10.0.0.3"}`,
+               },
+       }
+       for _, json := range tests {
+               t.Log(json.in)
+               actual, err := WriteJSON(node.NewBrowser(m, ReadJSON(json.in)).Root())
+               if err != nil {
+                       t.Error(err)
+               }
+               fc.AssertEqual(t, json.out, actual)
+       }
+}
+
 func TestNumberParse(t *testing.T) {
        moduleStr := `
 module json-test {

nuggets.  if i get a chance, i'll take a look
On Fri, Dec 1, 2023 at 4:08 AM Henning Rogge @.***>
wrote:

It seems my fix for unionlists of subtypes not becoming lists had a
sideeffect overwriting the subtype itself ( see #60
https://github.com/freeconf/yang/issues/60 ).
I am not completely sure how we should to fix this, but at least I have a
testcase that demonstrates the problem.
diff --git a/nodeutil/json_rdr_test.go b/nodeutil/json_rdr_test.go
index 2b638a6..3d1def8 100644
--- a/nodeutil/json_rdr_test.go
+++ b/nodeutil/json_rdr_test.go
@@ -124,6 +124,46 @@ func TestJsonRdrTypedefUnionList(t *testing.T) {
}
}
+func TestJsonRdrTypedefMixedUnion(t *testing.T) {

  mstr := `

module x {

   revision 0;

   typedef ip-prefix {

       type union {

           type string;

       }

   }

   leaf-list ips {

       type ip-prefix;

   }

   leaf ip {

           type ip-prefix;

   }

+}

   `

  m, err := parser.LoadModuleFromString(nil, mstr)

  if err != nil {

          t.Fatal(err)

  }

  tests := []struct {

          in  string

          out string

  }{

          {

                  in:  `{"ips":["10.0.0.1","10.0.0.2"],"ip":"10.0.0.3"}`,

                  out: `{"ips":["10.0.0.1","10.0.0.2"],"ip":"10.0.0.3"}`,

          },

  }

  for _, json := range tests {

          t.Log(json.in)

          actual, err := WriteJSON(node.NewBrowser(m, ReadJSON(json.in)).Root())

          if err != nil {

                  t.Error(err)

          }

          fc.AssertEqual(t, json.out, actual)

  }

+}
+
func TestNumberParse(t *testing.T) {
moduleStr := `
module json-test {
—
Reply to this email directly, view it on GitHub
https://github.com/freeconf/yang/issues/96, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAACA7QDGZG7ZHHDW7J6TNLYHGM73AVCNFSM6AAAAABACQK6IOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAZDANBTGQYDSNI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I dug a little bit deeper into the issue...
I think the problem arises from the fact that the meta.compileType() function is allowed to convert a type from "single" to "list" variant if the parent is a leaf-list (meta/compile.go line 242-244 and 303-305). This is okay for built-in types and inline subtypes, but it can lead to issues for named type definitions of unions that are also used elsewhere. Because these have pointers to their union-types, which means we can have multiple types which have pointers to the same unionTypes.
I have a patch that solves the testcase above, but it breaks the parser_samples_test.go because it copies all unionTypes in the meta/core.go function mixin().
I will send a Draft-PR so you can have a look at the code and tell me what you think about it. Maybe I will find a way to fix the break later.

created PR #97

yeah, this seems serious.  i have your branch and will look at it later
today.
On Tue, Dec 5, 2023 at 3:17 AM Henning Rogge @.***>
wrote:

created PR #97 https://github.com/freeconf/yang/pull/97
—
Reply to this email directly, view it on GitHub
https://github.com/freeconf/yang/issues/96#issuecomment-1840232319, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAACA7R5ARB4WVZFRYTCB2LYH3KBTAVCNFSM6AAAAABACQK6IOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBQGIZTEMZRHE
.
You are receiving this because you commented.Message ID:
@.***>

authors: HRogge dhubler

repo: freeconf/yang


text:
"release is too old" error could be more helpful

e.g. we could include:

the version provided by the caller
the latest version already existing

Same for the error "release already exists".
suggested by Thorsten

These are not happening anymore in the current version v1.21.1

repo: freiheit-com/kuberpult


text:
Refactor datepicker

📥 Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
☑ Submission checklist

[ ] I have read the CONTRIBUTING doc
[ ] yarn build works locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

💬 Further comments
Closes #796

@all-contributors, please add @SercanSercan for code

@all-contributors add @SercanSercan for code

authors: SercanSercan piofinn

repo: fremtind/jokul


text:
sequential-render API tweaks

Instead of a very ember concurrency specific API that is fetchDataTask now, let us pass a promise to the task that could be native or a perform of the task. This way we can knock off,

asyncRender (the absence of a promise implies synchronous render)
queryparams
taskOptions
fetchDataTask
All these can be replaced with a single taskPromise attr

As first step, we will expose a new API that accepts a promise, upon successful resolution, call updateRenderStates, which ensures that only after async operation is done, we will increment appState

authors: kanalveli-ramachandran kulkarni-kashyap

repo: freshworks/ember-sequential-render


text:
Use atomic counters

I tried making the pool faster on NUMA systems but the effect is very minor, because the channel uses a Mutex.
However, since I already did the work, I would like to share it.
Should I rebase the history into one commit?

The massive test fails on travic-ci in debug mode because the iter().take(test_tasks).fold is faster than the last thread finishing itself.
This could happen with any synchronisation method. I adjusted the test accordingly.

Looks great! Can you rebase and squash?

Rebased into one commit.
Thank you for the review.

Thanks for your contribution! 🎉

Version 1.0.2 has been released which includes these changes.

Thank you, was a pleasure.

repo: frewsxcv/rust-threadpool


text:
Tiebreaker in _TypeResolver

_TypeResolver should default to calling something a string if there is a tie between string and another type.
Currently I am experiencing inconsistent behaviour for calls like
import unittest
from io import BytesIO

from tabulator import Stream
from tableschema import infer

class BooleanTestCase(unittest.TestCase):
    def test_check_type(self):

        data = BytesIO(b"foo\tbaraz\t\n1\ttst\tm tst\n\tf\tother test")

        with Stream(data, format="tsv") as stream:
            sample = stream.sample
        schema = infer(sample[0], sample[1:])
        assert schema["fields"][1]["type"] == "string"

Here there is a tie between boolean and string. If the test is run on its own then 1/2 the time it fails. I think that the best way to follow "in the face of ambiguity refuse the temptation to guess" would be for the typeresolver to just stick to string.
Or perhaps even to have a configurable threshold % of strings at which string would be the default.

I agree we should have it deterministic.

repo: frictionlessdata/tableschema-py


text:
listProducts with query passed in

📦 Published PR as canary version: Canary Versions

:sparkles: Test out this PR locally via:
npm install @friggframework/api-module-yotpo@0.0.14-canary.119.95e0f67.0
# or
yarn add @friggframework/api-module-yotpo@0.0.14-canary.119.95e0f67.0

:rocket: PR was released in @friggframework/api-module-yotpo@0.0.14 :rocket:

:rocket: PR was released in @friggframework/api-module-yotpo@0.0.15 :rocket:

repo: friggframework/frigg


text:
Use React ref instead of id for canvas

I'm not sure why we had different ids for the different graph types, but it was causing strange things to happen when we changed from one type to the next. Now we just use a ref. Since we re-set the paper project, I don't think there's any harm in using the same canvas for differen types.

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

repo: frontrowed/graphy


text:
Espresso-october-2016 Branch

Espresso tests includes SearchTest (check if getting results from all categories) and DownloadTest to download a file from a specific source.

Thank you very much!
I'll now see if I can rebase this branch and bring it up to speed.
Is there a gradle task I must run in order to start the automatic tests? maybe something like
./gradlew espresso ?
no clue how to use it

This is how I do on Android Studio:

On Project Files select androidTest/java > com/frostwire/android > gui/activities and right click to run for example on 'DownloadTest' This test go to Settings, un-select all sources except Archive.org, go back to search, search 'Creative Commons' and download the first result on Audio for Archive.org

awesome, I'll do that!

@muckachina I've rebased this branch, and created a clone branch called espresso-november-2016 on my repository.
When you have a chance, add my repository as a remote (if you don't have it already):
git remote add gubatron https://github.com/gubatron/frostwire

then do a git fetch gubatron
and you should get all my branches, then you can delete your local espresso-october-2016 branch and push the espresso-november-2016 branch to your github repo.
I'll be closing this and opening a new pull request.

authors: gubatron muckachina

repo: frostwire/frostwire


text:
Allow optimizing for Weak spot DMG

There is no way to optimize for Weak spot DMG at the moment. This only affects Sharpshooter's Oath

how does weak spot DMG work? is it a guaranteed crit?

Yea the same as crit hit mode, but only for arrow charged attacks, and has some special DMG bonus with sharpshooters oath

repo: frzyc/genshin-optimizer


text:
travis-ci badge in README.md should be changed to a GitHub Action badge

When the move from travis-ci to github actions was made, the "build" badge was not updated.  One helpful reference for defining this badge can be found in https://stackoverflow.com/questions/57719605/official-badge-for-github-actions

Closed with #55

repo: fsaintjacques/semver-tool


text:
Reader disposal

any way to avoid disposable readers?
if not ensure that disposal gets rid of all unreferenced inputs.

success 💪


text:
Add F# events support

Do not merge, work in progress.

[x] Basic Event object implementation
[x] Event module functions
[x] 'IEvent` methods
[x] Testing
[x] Docs

@alfonsogarciacaro, I think I have small problem with workflow - changes I've done to import/core/fable-core.js are not copied to test folder. So all my tests are failing. Am I doing anything wrong?

I wanted the tests in the CI server to run against the fable-core version in npm, so I'm checking the environment variable DEV_MACHINE before replacing fable-core with the development version. You can comment that line for now, I will uncomment it again when the new version of fable-core is published :+1:
Thanks a lot for your work!

And sorry, I forgot, can you please also edit the part about Events in the docs now that you made Events work too :)

It's not ready yet - as for now I've get Event module functions working. Still need to add methods from IEvent (AddHandler etc.).
Will update docs when I'm done :)

Looks like I'm green on all tests, docs updated. From my point of view it's ready to merge. But code review and any comments appreciated.

This is an amazing work! The code looks great, I just left a couple of comments but they're not very important. Only, if we're really interested in making the size of fable-core.js smaller, we could try to unify the code for Event and Observable static functions. But probably when we implement tree shaking this won't be very important.
I'm really surprised you got the code for the second replacement pass (the CoreLibPass) right as it's not very intuitive :) I'll leave some comments for future contributors. Also, I forgot to tell there's a readCoreLibMethods.js script in the src/tools folder to automatically update CoreLibMethods.fs. Did you use it?
I'll merge the code as is. I'm also giving you edit rights in case you need to change something later.
Thanks a lot for this, Krzysztof!

Thanks. :)
Yes, unification between Event and Observable sounds like good idea.
No, I haven't used readCoreLibMethods.js, i just modified this file I shouldn't modify by hand ;)

authors: Krzysztof-Cieslak alfonsogarciacaro

repo: fsprojects/Fable


text:
Project Import are not server agnostic when global storage

I would like to use the global storage, so to avoid downloading twice the same packages. However switching, all my imports path depends to the active username and this cannot build on another machine.

Is there a way to work this out?

The storage:none features is only supported for new style msbuild.

authors: apobekiaris forki

repo: fsprojects/Paket


text:
KeyShared fails to partition correctly when SequenceId is not set

Is it expected behavior, that KeyShared fails to partition correctly when SequenceId is not set?

Hi, no this is not expected. Here are the key-related integration tests, feel free to add a PR with a failing test.

Is it ok if I just give a C# Example?

C# example won't run integration test after you submit it :(

nvm, It was bad data in a test.

repo: fsprojects/pulsar-client-dotnet


text:
Integration No Longer Available

Searching for the integration and it no longer exists, heading to the project page on the HACS website and it now gives a 404 - https://hacs.xyz/docs/repositories/integration/fuatakgun_eufy_security I'm not sure if this is a geolication issue (I'm in Australia) or if the integration has been pulled.

You can manually add repository and continue to installation, i will take a look at this

Do you mean via add ons? The WS server is up, I cannot determine how to add the front end other than this method. I can see the HomeBase detected and connected but need the UI to manage I guess.

+1, integration is not available. During the installation process after downloading the integration in HACS (and restarting Home Assistant) the Configure -> Integrations -> Add Integration won't list Eufy Security.

After several restarts and I left it there overnight and the Integration would appear for me this morning.

I have the same issue, with the integration not available (the add on was installed and looks to be running properly). Will see if anything changes tomorrow.

Yea I have had it running for 5 days now and no change, I'm not entirely certain that it can change by itelf @mateszlanka can you confirm that you got the fuatakgun eufy security integration and not the standard eufy one?

The integration/documentation redirects to the fuatakgun's github so I can confirm I'm using the correct one.
I'm running it on a Raspberry Pi 4, with Home Assistant OS, and had several restarts and re-download of the repository in HACS, but I'm not sure what helped finally.

Ok this is completely my fault as I am new to Home Assistant and didn't read up on HACS. I did not realise that it is an Add-On that must be installed (for others with this issue - https://www.youtube.com/watch?v=zlaJrepZl2E). Now I can find the integration fine as I am doing it the right way.

authors: CameronMcGuffie fuatakgun mateszlanka rgruener


text:
整个训练过程需要多长时间？

非常棒的工作，为贵团队点赞！！！
在之前的回答中，你们提到了使用8张A100进行训练，请问：
1.使用的80G的A100吗？
2.整个训练过程花费了多长时间？
希望能得到回复，感谢！

对的
整个流程应该是要训好几天，具体几天我有点忘了，抱歉。


text:
Tracer panic with large initial_sequence and delayed TCP probes

When running with a large initial_sequence, such as 64000, for TCP tracing, the tracer can panic if a delayed TCP probe response from a prior round is received.
This happens because the check to determine if a given sequence is in the current round check if difference between the  sequence (the sequence number of the probe response) and the round_sequence (the sequence number for the first probe in the round) is less than the BUFFER_SIZE (currently 1024):
/// Is `sequence` in the current round?
pub fn in_round(&self, sequence: Sequence) -> bool {
    sequence >= self.round_sequence && sequence.0 - self.round_sequence.0 < BUFFER_SIZE
}

For example, if initial_sequence is 64000 and round_sequence is 64055, a delay probe response from a prior round, such as sequence 64491, will incorrect pass the above check and result in a panic (typically observed in complete_probe but can, by luck, pass through to later processing).
The solution is to restrict the maximum allowed initial_sequence to u16::MAX - 2 * BUFFER_SIZE (2048) to ensure sequence numbers from the immediate prior round will be correctly discarded by the in_round check

cc @zarkdav


text:
Make ProcTable template flexible

@fujunwei , PTAL.

Merge it and i will rebase the dawn/main after landing [CL-73400](https://dawn-review.googlesource.com/c/dawn/+/73400 .

authors: fujunwei huningxin


text:
🛑 Deliveries Service is down

In 364800e, Deliveries Service (https://api.waypath.io/deliveries/v1/health-monitor) was down:

HTTP code: 504
Response time: 10078 ms

Resolved: Deliveries Service is back up in 6bcd13e.


text:
Create dependabot.yml

Added dependabot with weekly updates for Github Actions, Maven and Docker

New line at the end is added, Thanks @MikaelEdwartz

Looks like we have a recurring problem with missing newline at the last line in some textfiles.
This is how a line is defined in POSIX standard:
A sequence of zero or more non-  characters plus a terminating  character.
Something for .editorconfig #28 to fix so all developers have this enabled.
Can also be set in IntelliJ directly.

Well noticed @MikaelEdwartz! Amazing dependabot @jLereback 💗

authors: jLereback kappsegla signealfonson

repo: fungover/haze


text:
enable channels_last for hdf5like source

Add optional argument channels_first to Hdf5LikeSource with default value true.
If channels_first is set to false, then the data source is read in channels_last manner.

Great, thanks a lot!
Can you add the docstring also to the other HDF5-like sources (N5 and Zarr)? Otherwise ready to merge.

authors: funkey maisli

repo: funkey/gunpowder


text:
doesn't work

It looks like a cool idea but sadly doesn't work properly. It seems like you haven't uploaded all of the necessary files.

Thank you for your interest, but as you mentioned we haven't uploaded the
moon seismic data to repo.
I assume that's why it doesn't work.
On Wed, Dec 27, 2023, 19:19 xHector1337 @.***> wrote:

It looks like a cool idea but sadly doesn't work properly. It seems like
you haven't uploaded all of the necessary files.
—
Reply to this email directly, view it on GitHub
https://github.com/furkanyg/moonviewer/issues/1, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AU7W7DWCYR6IZVQJDXSK4MLYLRDCXAVCNFSM6AAAAABBEQ5EAWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA2TONJVGMZDSNY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

You should add seismic data, mate. otherwise, this is meaningless.

All the seismic data was created by our team, for this reason we can't
publish it.
We have uploaded the code for beeing able to look up to code quality by the
judges who are qualified for the project administration.
Thank you for your interest.
On Sat, Dec 30, 2023, 20:44 xHector1337 @.***> wrote:

You should add seismic data, mate. otherwise, this is meaningless.
—
Reply to this email directly, view it on GitHub
https://github.com/furkanyg/moonviewer/issues/1#issuecomment-1872572381,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AU7W7DS4GDUKEMBWI7JVVXDYMBHGFAVCNFSM6AAAAABBEQ5EAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZSGU3TEMZYGE
.
You are receiving this because you commented.Message ID:
@.***>

repo: furkanyg/moonviewer


text:
Prebuilt binary for Linux with phosg prelinked

I'm trying to pull the pictures and sounds out of old HyperCard stacks in an environment where I don't have root/sudo so I can't install phosg as a library.
I've been playing with the make files to try to merge the two codebases. There's probably a trick to make it easy, since the macOS release.zip has all the binaries and they seem to run. Can we have a Debian release?

You can specify the location of phosg by defining the cmake variable PHOSG_DIR, e.g. when you have phosg in a directory parallel to resource_dasm:
 cmake -DPHOSG_DIR=../phosg .

Note that for that to work there must be a symlink (or hardlink) inside the phosg directory called "phosg" that points to "src" like so:
ln -s src phosg

See: https://github.com/fuzziqersoftware/resource_dasm/blob/4b27622cf46c756120840bf414813015eb8fefa9/CMakeLists.txt#L24-L31

That worked to link and run resource_dasm. Thank you very much. However I wasn't able to link the one after, m68kdasm. I'll keep trying, maybe there's an include or a config issue on my system.
[ 62%] Linking CXX executable m68kdasm
/usr/bin/ld: CMakeFiles/m68kdasm.dir/src/m68kdasm.cc.o: in function std::thread::thread<void (&)(std::function<bool (unsigned long, unsigned long)>&, std::atomic<unsigned long>&, std::atomic<unsigned long>&, unsigned long, unsigned long), std::reference_wrapper<std::function<bool (unsigned long, unsigned long)> >, std::reference_wrapper<std::atomic<unsigned long> >, std::reference_wrapper<std::atomic<unsigned long> >, unsigned long&, unsigned long, void>(void (&)(std::function<bool (unsigned long, unsigned long)>&, std::atomic<unsigned long>&, std::atomic<unsigned long>&, unsigned long, unsigned long), std::reference_wrapper<std::function<bool (unsigned long, unsigned long)> >&&, std::reference_wrapper<std::atomic<unsigned long> >&&, std::reference_wrapper<std::atomic<unsigned long> >&&, unsigned long&, unsigned long&&)': /usr/include/c++/9/thread:126: undefined reference to pthread_create'


text:
Prevent gcloud update message

When invoking gcloud inside Docker, we don't want it to notify about available updates. The GCloud version is fixed within the Docker image.

FYI branched wrongly and force-pushed to fix

repo: fuzzylabs/vertex-edge


text:
🛑 e-Library is down

In cafee1c, e-Library (https://e-library.darunnajah.ac.id) was down:

HTTP code: 508
Response time: 268 ms

Resolved: e-Library is back up in cdfcb95 after 27 minutes.


text:
Templates never reloaded

The content of a filesystem-based template is cached and never reloaded. We should monitor the filesystem for changes.

Could influence #22 (Cache rendered pages), as we must only reload the cache if the file gets changed. Therefore, our mechanism introduced here should allow for template change detection from outside.

Done for viewer template, yet to do is the editor template (and possibly unit tests).

Should refactor the last change. Maybe I can move the logic around atomic.Value into the Template struct itself, so that none of its users need to bother.

repo: fxnn/gone


text:
Error for mat2npy

make mat2npy causes the following error.
mat2npy.py: error: argument --dataset_name: invalid choice: 'oxford' (choose from 'oxford5k', 'oxford105k', 'paris6k', 'paris106k')

Fixed in the newest commit

still have some errors:
python mat2npy.py \
        --dataset_name oxford5k \
        --feature_type resnet \
        --mat_dir ./data
Traceback (most recent call last):
  File "mat2npy.py", line 50, in <module>
    with h5py.File(os.path.join(args.mat_dir, input_file), 'r') as f:
  File "/home/ubuntu/anaconda/lib/python3.6/site-packages/h5py/_hl/files.py", line 312, in __init__
    fid = make_fid(name, mode, userblock_size, fapl, swmr=swmr)
  File "/home/ubuntu/anaconda/lib/python3.6/site-packages/h5py/_hl/files.py", line 142, in make_fid
    fid = h5f.open(name, flags, fapl=fapl)
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/h5f.pyx", line 78, in h5py.h5f.open
OSError: Unable to open file (unable to open file: name = './data/oxford5k_resnet.mat', errno = 2, error message = 'No such file or directory', flags = 0, o_flags = 0)
Makefile:23: recipe for target 'mat2npy' failed
make: *** [mat2npy] Error 1


text:
Refactoring NeblioTransactionHelper.cs - 2

As part of this Issue we will be refactoring rest of the methods in the class where we do not need Async/await and where there is a possibility to merge IF conditions.
Below are the changes made in NeblioTransactionHelpers.cs class.

Removed unnecessary Async/Await.
Merged few IF conditions.
Removed unnecessary Try/Catch blocks.
Removed unnecessary assignments to variables.

Pull request is raised already and linked to this issue. Moving this issue to QA.

closing for duplicity

authors: VenkataRoundSqr fyziktom

repo: fyziktom/VirtualEconomyFramework


text:
💡 [REQUEST] - Pass default values for node parameters via NodeData.msg

Implementation PR
No response
Reference Issues
Related to #110
Summary
We want to add a new field to the NodeData.msg to allow for the specification of the default value of the NodeData element.
This is to allow the library to determine the default value and provide various default values for different nodes.
Basic Example
The Wait Node wants a default value of 1 second for the wait time float parameter.
The Constant node on the other hand should have a 0 for its default float value.
Drawbacks
We need to adapt both the frontend and backend.
Unresolved questions
No response

Working on this

authors: Oberacda mdeitersen


text:
merge from EFs and general FGraph common updates

This branch has grown too much and need to get back. Most of its functionalities are there

node simplified, not it does not track the list of factors.

repo: g-ferrer/mrob


text:
Deploy FHIR Services

Include definitions and commands to set up a FHIR instance, including a FHIR server and mysql database
PR should include:

docker compose file to easily set up services
Cloudformation templates for AWS-based deployments

in mysql database, create a db with name cohort


text:
Twitter integration

Idea from February high-level meeting
Feature Request
Desired behaviour
As users add tools or workflows, we should trigger tweets on the Dockstore account. This can be done using the twitter api.

Superseded by specification about events I think


text:
Add search by name for VariantSet and ReferenceSet

Since PR #403 introduces name attributes to VariantSet and ReferenceSet, would it make sense to add a name parameter to SearchVariantSetsRequest and SearchReferenceSetsRequest to allow for searching by name?

+1 For being able to search on data we are storing. References can't currently be searched by name either.


text:
Update protobuf-java dependency version to 3.0.0-beta-3

Fixes #661

+1 for important infrastructure, thanks!

+1 merging

authors: david4096 heuermh kozbo


text:
🛑 Revista is down

In 2089877, Revista (https://pensamientopenal.com.ar/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Revista is back up in 543cfaa.


text:
🛑 Test ReportingAPI is down

In ee0b3c8, Test ReportingAPI ($RAPI_URL) was down:

HTTP code: 503
Response time: 5368 ms

Resolved: Test ReportingAPI is back up in 72badbc.

repo: gaeljw/poc-uptime


text:
Enforce the FCE creation date

Requested by Sean via Zendesk:

Is there any way to create a popup to warn people that they should not be saving a Full Compliance Evaluation with a date earlier than the actual creation date? The only time anyone should enter an earlier date is if they're creating it after September 30 for the previous Federal Fiscal Year.

After discussing with Sean, the plan is to disable the FCE creation date field and set it to today for FCEs within the current fiscal year or September 30 for FCEs created after the selected fiscal year has ended.
As an additional enhancement, during the first two weeks of October, verify the selected FCE year before proceeding since during that period FCEs are often created for both the current and previous year.

repo: gaepdit/iaip

license: Unlicense


text:
allow for passing global data via the config object

Adds the ability to pass data via the config object so that it can be used in each file.
I can see a future need for passing a file (just JSON, probably), but this solves the basic need.
Does not support command line use currently, as passing a file would almost certainly be required.
If you'd like to see file-passing and/or command line support implemented before merging, I'd be happy to do so.

Can you think of a use-case within the Foundation documentation? Not to say that's the only reason the library exists, but that's the main reason it exists right now. ;)

This is definitely outside of what the Foundation docs need. I've noticed a couple other divergences with our project needs, and maintaining a permanent fork might be our best option for now. Once there's more stability on our end, we can reassess.

Ooh! You're using it in your own work? That's exciting :) To be sure, I don't want this to be a ZURB-only library, which is why I wrote it in a way that's adaptable.
I think the reason we don't need the site-level metadata is because we funnel these pages into a proper static site generator with its own Handlebars environment set up. However, it's probably possible to use only Supercollider to compile the whole page layout, although you're missing extra features like custom partials.
My main concern is feature creep, but perhaps Supercollider needs to give you more access to Handlebars. You can pass in your own Handlebars instance, but I don't know if you can pass in custom data that way, or just partials and helpers.

Finally merged this! Thanks for the contribution :)
The only change I made was to flip the extend order, so that local variables override global ones.
Found a use-case within Foundation—eventually, all three frameworks will use the template, and we need a way to globally define things like framework name, repo name, etc.

Aaaaand doing that flip introduced a bug ;) I love object extends.

authors: gakimball thompsongl

repo: gakimball/supercollider


text:
Improve retry policy

Is your feature request related to a problem? Please describe.
I came to this problem by using anvil. During communication between anvil and chain provider, connection reset and abort happens and it is look like that anvil isn't retrying on such errors.  My proposal that retry policy should be triggered also on some tcp errors, I am talking about this part - code
Describe the solution you'd like
Solution can be similar to reqwest-middleware crate, something like this - link
Thanks

what errors do you have in mind?
retry only retries errors that could be attributed to a spurious network or rate-limit.

what errors do you have in mind? retry only retries errors that could be attributed to a spurious network or rate-limit.
Yep, correct, but I think those errors are missed: io::ErrorKind::ConnectionReset and io::ErrorKind::ConnectionAborted, I think they are under  reqwest_err.is_request()

authors: kubmichael mattsse

repo: gakonst/ethers-rs


text:
fix(core): i256 docs

Motivation
Fixes #2183
Doesn't help that doc CI is constantly failing :(

Solution

PR Checklist

[ ] Added Tests
[ ] Added Documentation
[ ] Updated the changelog
[ ] Breaking changes

@DaniPopes I believe this is caused by cargo +nightly
we don't need +nightly here.
ref tokio docs job
https://github.com/tokio-rs/tokio/blob/master/.github/workflows/ci.yml#L464
mind giving this a try?

authors: DaniPopes mattsse


text:
Update tutorial.md

Updated to track where knownGene table is available. I am curious about why this issue occurs but

thanks @TKlingstrom!

authors: TKlingstrom shiltemann

repo: galaxyproject/training-material


text:
remove proteomic datatypes

These should be included in newer Galaxy releases.

@jj-umn can we remove the proteomics datatypes? They should be included in Galaxy now, isn't it?

ping @jj-umn @iracooke

Hi @bgruening this is most likely fine but I am not the maintainer of those repos so I cant be 100% sure.  I believe almost everything in the old proteomics datatypes is now in the main galaxy distribution but in theory it is possible this might break stuff.

I would like enforcing the removal of all datatypes and if anything is missing we should fix it asap in Galaxy.
Just to stick to the best-practice-guidelines.

Let's merge it. All datatypes should be in Galaxy and we should enforce this as community.

authors: bgruening iracooke

repo: galaxyproteomics/tools-galaxyp