bio-registries notebook runs too long

The bio-registries notebook alone runs 4 min:
docs/test_notebooks.py Executing notebooks in /home/runner/work/lamindb/lamindb/docs/bio-registries.ipynb
Scheduled: ['bio-registries']
bio-registries ✓ (279.635s)
Total time: 279.6[35](https://github.com/laminlabs/lamindb/actions/runs/9017775087/job/24777294086?pr=1640#step:15:36)s

That's too long as an integration test but also for a user when trying something out, isn't it?

It's because of this:

Do we need this or can we speed this up somehow?

I think this is pretty cool to see what iris lineage looks like, but of course it's fine to remove.

If it's cool, then let's keep it. Can it be accelerated?

The only way to accelerate is to accelerate the logic of adding parents.

I moved it into a markdown cell!


Add weekly dependabot updates

Automatically keep dependencies up to date.
Replicate is currently 0.6.0 but latest version is 0.12.0

Buncha PRs came in: https://github.com/replicate/getting-started-nextjs/pulls?q=is%3Apr+is%3Aclosed+label%3Adependencies
I shipped 'em all, tested locally. All good.


Code error analysis is too slow and too slow

Problem Description
Code error analysis is too slow and too slow, often leading to an erroneous analysis report, not real code errors.
Code error analysis will not be interrupted and will be executed slowly to the end.
Versions

Spyder version: 4.0.0b5
Python version: 3.7.3
Qt version: 5.9.6
PyQt version: 5.9.2
Operating System name/version: win7 64bit
Computer Configuration: Desktop, 8G RAM, 4 core AMD A8-5500 APU 3.19Hz

This is due to too many background Python processes. I manually killed these useless processes and solved the problem.
Why are there so many useless Python processes? see #10228


Task 1: Spike/Learning - GeoServer and plugins

Epic: https://github.com/mzagorskirs/geowave/issues/3
See Epic for task details.

Plugin developed that shifts the data.  The attributes are not clickable in the GeoServer UI for a reason that is outside the scope of this ticket.
Code available upon request.
Code reviewed with Rich Fecher.

Demo of the render-transform-shift code:
https://user-images.githubusercontent.com/43011672/158822743-0416a9b4-a449-409f-ad61-a6d506a58678.mp4

approved


Add VPN state to broken sites report

Task/Issue URL: https://app.asana.com/0/488551667048375/1207135101272466/f
Description
Send vpnOn parameter to broken site reports
Steps to test this PR

[ ] install this build and launch app
[ ] enable VPN
[ ] load a page and send broken site report (logcat filter by vpnOn
[ ] verify that epbf pixel is seng and contains vpnOn param to true
[ ] disable VPN and send broken site report
[ ] verify that epbf pixel is seng and contains vpnOn param to false

#4448  👈
develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @aitorvs and the rest of your teammates on  Graphite


Insiders: Must authenticate a second time for Settings Sync

Follow up to https://github.com/microsoft/vscode/issues/148055#issue-1214704251 ... Requested by @TylerLeonhardt to make a new issue RE: https://github.com/microsoft/vscode/issues/148055#issuecomment-1109903448
Note: This only happens upon first sign-in. On subsequent sign-ins it is not reproducible. It seems my credentials are stored in Settings Sync after the first sign-in, and it automatically turns on.
Issue description: Although I am logged into GitHub on VS Code, Settings Sync forces authentication a second time. If I do the method of authentication linked in step 1 (below) then it works, but using the default does not work.

Steps to Reproduce:

Use the log-in method mentioned here: https://github.com/microsoft/vscode/issues/147104#issuecomment-1109108734

Start here:

Sign in with GitHub:

Click Cancel here:

Choose to "try a different way":

Click "Copy and Continue to GitHub"

Paste the code in the prompt on GitHub and continue. It should log you in

Now we are logged in but Settings Sync is not turned on. (Only happens on first log in.)

See here:

Click "Turn on Settings Sync..."
At Command Prompt, choose your options and click "Sign in and Turn on"

Choose Insiders when prompted
If this is the first time signing in, you will be prompted to authenticate once again. The default method will not work, but the method linked in Step 1 will.

Does this issue occur when all extensions are disabled?: Yes

VS Code version: Code - Insiders 1.67.0-insider (ab86e0229d6b4d0cb49cfd6747c92cafcd2bd4af, 2022-04-26T05:16:02.333Z)
OS version: Linux x64 4.14.275-207.503.amzn2.x86_64
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz (2 x 2499)

GPU Status
2d_canvas: unavailable_softwarecanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: disabled_softwaremultiple_raster_threads: disabled_offoop_rasterization: disabled_offopengl: disabled_offrasterization: disabled_softwareraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: unavailable_softwarewebgl2: unavailable_software

Load (avg)
0, 0, 0

Memory (System)
3.79GB (0.50GB free)

Process Argv
.

Screen Reader
no

VM
0%

DESKTOP_SESSION
mate

XDG_CURRENT_DESKTOP
MATE

XDG_SESSION_DESKTOP
undefined

XDG_SESSION_TYPE
undefined

Extensions: none
A/B Experiments
vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30422396
pythontb:30258533
pythonvspyt551:30291412
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805cf:30301675
pythonvspyt200:30323110
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30404738
wslgetstarted:30449409
pythonvspyt640:30438691
vscscmwlcmt:30465136
cppdebugcf:30475217

@TylerLeonhardt Is this auth related issue or shall settings sync has to do something here?

@sandy081 I don't think you have anything to do... unless there's some timeout for settings sync?
@StevieDicks there are suppose to be 2 flows that happen before the device code flow:

The main flow that tries to redirect back to VS Code (fastest)
The web flow that shows this page:

Then the device code flow

I know the first one doesn't work on your system, but what about the 2nd? Do you see it at all? Btw, I did make some changes 2 days ago in this space so you may need to get the latest Insiders.

@TylerLeonhardt I don't recall seeing the second option at all, only the first and third.
Also, I downloaded Insiders the day you mentioned it, so it should have been up to date with the changes you mentioned. Sorry I can't be of more help.

@StevieDicks I believe I made some updates after that... can you try again and let me know how it goes?

Just updated Insiders and was able to see the second method as below. This works better than the device code flow.

I am still not sure if this addresses the settings sync, as I mentioned it only happens on the first login and I don't have the time to go through all the steps to reproduce that. But it is definitely a better sign in process!

I think I'm going to close this. I wasn't able to repro the initially reported problem and it only happens if you have to resort to device code flow which only happens after the 2 other (better) flows fail to happen. Given the scope is very tiny, I think there are bigger fish to fry.
@StevieDicks let me know if you really want me to keep this open, but given the severity and how minor the inconvenience is IMO, I don't think we really need to track this.

@TylerLeonhardt, Thanks for looking into it. It doesn't bother me at all -- I only wanted to bring it to your attention for your record. After the first login it does not happen anymore so it's difficult even for me to reproduce. GitHub integration is running smoothly on Insiders now. Cheers.


worker: Add noop image to map

I'm 99% certain I've already done this, maybe got lost in some unmerged PR?

I'm also 80% certain I already saw you do this 🤔.


Large refactor

Status (2023-07-11): done, requires extensive testing!
This is expected to be semi-broken. My plan currently is to refactor it more, and only then do a good test to see what is broken (and fix it). Still would appreciate nods into the right directions - what broke and needs fixing, what could be improved in the refactor, what else is worth to refactor.
The changed line count is inflated by changing tabs to spaces. Some editors (e.g. Pycharm 2023.1) will show whitespace edits differently than style and significant edits. Also, I moved code to different files.

@graemeniedermayer @thygate I would kindly ask you to keep an eye on this, as this will create totally massive merge conflicts if main branch receives significant changes while this is in the works.

@thygate
I am not refactoring invert_depth. Did I get all this right?

invert_depth is enabled with this option
Desired effect of invert_depth on the option

Clip and renormalize
Resulting image is inverted and clipped

Generate stereoscopic image(s)
Resulting depthmap is inverted, no effect on the stereo image

Generate simple 3D mesh
No effect, mesh is exactly as if invert_depth was disabled

Generate 3D inpainted mesh
No effect, mesh is exactly as if invert_depth was disabled

Remove background
Does not depend on the generated depthmap, no effect

@thygate
Clipdepth (Clip and renormalize) is also quite tricky. Do you think these values are ok? Would you change something?

clipdepth is enabled with this option
Desired effect of clipdepth on the option

Invert depth
Resulting image is inverted and clipped

Generate stereoscopic image(s)
Depending on whether it is clipped from below or above: the closest objects will appear as if distance to them is the same and/or the furthest objects will appear as having the same distance

Generate simple 3D mesh
Mesh will be distorted along the depth axis

Generate 3D inpainted mesh
Mesh will be distorted along the depth axis

Remove background
Does not depend on the generated depthmap, no effect

@thygate
(C)
There is an option to show depthmap, and to save depthmap. Do you think it would make sense to always show everything (depthmaps, stereoimages, etc.), but have an option called "save results" (or something like that), that would be enabled by default? This approach is marginally easier to implement and IMO would be more user-friendly.

(C) Yes! The show depthmap is a leftover from the very first version, it serves no purpose. Always showing everything that was generated would be the most intuitive I agree.

(B) The clip depth (far/near) function was something I implemented quickly and never really properly tested tbh ..
It was requested at some point, but I'm not sure anyone is actually using it, I believe it was for raw depthmap outputs only, I don't think, or can't think of a scenario where it would be useful for the other options, like generating stereo pairs or meshes ..
So the suggested outcomes seem fine.

(A) No effect for all seems like the correct approach to me, this option was meant for raw depthmap output only, since some external software requires it. It should have no effect on any of the options except clip and renormalize. So all seem good to me.

@thygate Thank you!
(A) Implemented :)
(B) (C) Workinhg on it...

(D) net_w and net_h are assigned, but never used; net_width and net_height are actually used. I guess it should work differently... Do I get it right that every model has its original (suggested) net size, but sometimes it is beneficial to override it? How do you think: maybe the net size should be a dropdown with values: "default" (match model), "match image" and "custom", where custom shows two sliders for the net size? Or simply "match model size" and "match input size"?

(D) Yes correct, net_w and net_h were the initial model sizes, at the start the sliders would mirror this initial model size, but this changed at one point and I never removed them. Drop down would be fine, but not all models support all sizes, and tweaking the size manually can be beneficial to tune for detail. I would prefer to keep the option to manually set size.

For starters, thanks for all this work !! I'm doing some quick tests to see if anything is broken ..

zoedepth models run fast the first time i run them, and then very slow on each subsequent run :\
running on the same picture, the first time takes 2 seconds, each subsequent run with same params and image takes 40 secs ..

stereo image generation and both mesh generations seem to be fine.

@thygate Oops, a logic error. Now should be fixed.

@graemeniedermayer Oh! This sounds like a good idea. https://github.com/thygate/stable-diffusion-webui-depthmap-script/issues/282

When using "match net size" and leres I get this error
DepthMap v0.4.0 (cc55be2f)
device: cuda
Loading model(s) ..
Computing output(s) ..
  0%|                                                                                | 0/1 [00:00<?, ?it/s]
*** Error completing request
*** Arguments: (False, 'u2net', False, False, 0, 1, False, 1, 'GPU', False, None, '', '', True, <PIL.Image.Image image mode=RGB size=1489x2514 at 0x1DCA543B9D0>, '0', False, False, False, None, False, False, False, True, True, False, 0, 512, 512, True, False, False, True, False, 0, 2.5, 'polylines_sharp', ['left-right', 'red-cyan-anaglyph'], 0, '∯background_removal∯background_removal_model∯boost∯clipdepth∯clipthreshold_far∯clipthreshold_near∯combine_output∯combine_output_axis∯compute_device∯custom_depthmap∯custom_depthmap_img∯depthmap_batch_input_dir∯depthmap_batch_output_dir∯depthmap_batch_reuse∯depthmap_input_image∯depthmap_mode∯gen_mesh∯gen_normal∯gen_stereo∯image_batch∯inpaint∯inpaint_vids∯invert_depth∯match_size∯mesh_occlude∯mesh_spherical∯model_type∯net_height∯net_width∯output_depth∯pre_depth_background_removal∯save_background_removal_masks∯save_outputs∯show_heat∯stereo_balance∯stereo_divergence∯stereo_fill∯stereo_modes∯stereo_separation') {}
    Traceback (most recent call last):
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\modules\call_queue.py", line 55, in f
        res = list(func(*args, **kwargs))
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\modules\call_queue.py", line 35, in f
        res = func(*args, **kwargs)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\interface_webui.py", line 527, in run_generate
        outputs, mesh_fi, meshsimple_fi = core_generation_funnel(outpath, inputimages, inputdepthmaps, inputnames, inputs)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\core.py", line 305, in core_generation_funnel
        raise e
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\core.py", line 170, in core_generation_funnel
        model_holder.get_raw_prediction(inputimages[count], net_width, net_height)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\depthmap_generation.py", line 282, in get_raw_prediction
        raw_prediction = estimateleres(img, self.depth_model, net_width, net_height)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\depthmap_generation.py", line 304, in estimateleres
        prediction = model.depth_model(img_torch)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\torch\nn\modules\module.py", line 1501, in _call_impl
        return forward_call(*args, **kwargs)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\lib\multi_depth_model_woauxi.py", line 32, in forward
        out_logit = self.decoder_modules(lateral_out)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\torch\nn\modules\module.py", line 1501, in _call_impl
        return forward_call(*args, **kwargs)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\lib\network_auxi.py", line 58, in forward
        x_4 = self.ffm1(features[1], x_8)  # 1/4
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\torch\nn\modules\module.py", line 1501, in _call_impl
        return forward_call(*args, **kwargs)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\lib\network_auxi.py", line 209, in forward
        x = x + high_x
    RuntimeError: The size of tensor a (187) must match the size of tensor b (188) at non-singleton dimension 3

---
Traceback (most recent call last):
  File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\gradio\routes.py", line 422, in run_predict
    output = await app.get_blocks().process_api(
  File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 1326, in process_api
    data = self.postprocess_data(fn_index, result["prediction"], state)
  File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 1229, in postprocess_data
    self.validate_outputs(fn_index, predictions)  # type: ignore
  File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 1204, in validate_outputs
    raise ValueError(
ValueError: An event handler (f) didn't receive enough output values (needed: 5, received: 3).
Wanted outputs:
    [gallery, textbox, model3d, html, html]
Received outputs:
    [None, "", "
RuntimeError: The size of tensor a (187) must match the size of tensor b (188) at non-singleton dimension 3

Time taken: <wbr>1.43s

Torch active/reserved: 5274/6220 MiB, <wbr>Sys VRAM: 8192/8192 MiB (100.0%)

"]

when using leres and boost, seems to be for most models and boost :

DepthMap v0.4.0 (cc55be2f)
device: cuda
Loading model(s) ..
Loading model weights from  ./models/leres/res101.pth
initialize network with normal
loading the model from ./models/pix2pix\latest_net_G.pth
*** Error completing request
*** Arguments: (False, 'u2net', True, False, 0, 1, False, 1, 'GPU', False, None, '', '', True, <PIL.Image.Image image mode=RGB size=1489x2514 at 0x1DCA9B9FFD0>, '0', False, False, False, None, False, False, False, False, True, False, 0, 448, 448, True, False, False, True, False, 0, 2.5, 'polylines_sharp', ['left-right', 'red-cyan-anaglyph'], 0, '∯background_removal∯background_removal_model∯boost∯clipdepth∯clipthreshold_far∯clipthreshold_near∯combine_output∯combine_output_axis∯compute_device∯custom_depthmap∯custom_depthmap_img∯depthmap_batch_input_dir∯depthmap_batch_output_dir∯depthmap_batch_reuse∯depthmap_input_image∯depthmap_mode∯gen_mesh∯gen_normal∯gen_stereo∯image_batch∯inpaint∯inpaint_vids∯invert_depth∯match_size∯mesh_occlude∯mesh_spherical∯model_type∯net_height∯net_width∯output_depth∯pre_depth_background_removal∯save_background_removal_masks∯save_outputs∯show_heat∯stereo_balance∯stereo_divergence∯stereo_fill∯stereo_modes∯stereo_separation') {}
    Traceback (most recent call last):
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\modules\call_queue.py", line 55, in f
        res = list(func(*args, **kwargs))
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\modules\call_queue.py", line 35, in f
        res = func(*args, **kwargs)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\interface_webui.py", line 527, in run_generate
        outputs, mesh_fi, meshsimple_fi = core_generation_funnel(outpath, inputimages, inputdepthmaps, inputnames, inputs)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\core.py", line 137, in core_generation_funnel
        model_holder.ensure_models(model_type, device, boost)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\depthmap_generation.py", line 60, in ensure_models
        self.reload()
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\depthmap_generation.py", line 250, in reload
        self.move_models_to(self.device)
      File "C:\Users\thyga\Desktop\stable-diffusion-webui\extensions\stable-diffusion-webui-depthmap-script\scripts\depthmap_generation.py", line 257, in move_models_to
        self.pix2pix_model.to(device)
    AttributeError: 'Pix2Pix4DepthModel' object has no attribute 'to'

---
Traceback (most recent call last):
  File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\gradio\routes.py", line 422, in run_predict
    output = await app.get_blocks().process_api(
  File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 1326, in process_api
    data = self.postprocess_data(fn_index, result["prediction"], state)
  File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 1229, in postprocess_data
    self.validate_outputs(fn_index, predictions)  # type: ignore
  File "C:\Users\thyga\Desktop\stable-diffusion-webui\venv\lib\site-packages\gradio\blocks.py", line 1204, in validate_outputs
    raise ValueError(
ValueError: An event handler (f) didn't receive enough output values (needed: 5, received: 3).
Wanted outputs:
    [gallery, textbox, model3d, html, html]
Received outputs:
    [None, "", "
AttributeError: 'Pix2Pix4DepthModel' object has no attribute 'to'

Time taken: <wbr>4.07s

Torch active/reserved: 6385/6404 MiB, <wbr>Sys VRAM: 8192/8192 MiB (100.0%)

"]

Can reproduce the net size issue in the main branch, too. This happens if image has a weird size. Do you think the code should simply round the net dimensions to the nearest 32x?

Hehe, no worries, I'm very grateful for all the work you've put in this!
Ah and yes, I see it now,  (187) vs (188), my bad, I was a bit too fast with that report, sorry.
Rounding the dimensions upward to the next multiple of 32 is a great idea and will solve this problem too.

😊

I testing it out! It's looking good. The only bug I found was also on the main branch.
Zoe depth and pre_depth_background_removal don't seem to work together. This stems from RGB vs RGBA. It's a little tricky. I think the best solution would be to explicitly convert to RGB in the batched_background_removal function, but the alpha channel is used later to create the mask so I'll need to think about this a little bit.

Found a problem with the script mode. I will fix it soon.

Remove background tested.

Both simple and inpainted meshes seem to generate fine. Videos, too.

I've taken some time off (lots of stuff), but now I am back. I would like to get it merged - @thygate could you please do the last checks you have in mind and then Create a merge commit?

Whoops, there has been an issue with this I did not find up until now: if model offloading is enabled, it will be offloaded only once, and then won't offload.

And now we wait... Issues are bound to come, hopefully nothing that will be hiding for months like that one time I messed up a feature for 2+ months

I checked all features and everything seems to be working for me, if anything is to pop up, I assume it will be small stuff, or problems with packages .. I went over all your commits and read all your comments, thanks again for the thorough job of refactoring the hot mess that it was.
I did notice that just having some other extensions installed can change the torch hub checkpoint path, so the zoedepth models were redownloaded.


[FR] revert c39ef17 - Symlinks are now relative.

Just updated homeshick after a year or so and discovered half of my links are broken, c39ef17 being the most likely culprit. This stems from my extensive corner-case usage, where files in castle/home are themselves links pointing to a directory in the root of castle. Consider this castle example:
.
├── home
│   └── dev -> ../../scripts/
├── scripts

Before the commit, target ~/dev/scripts would point correctly at
~/dev/scripts -> /home/laur89/.homesick/repos/example/home/dev/scripts
whereas now it's ~/dev/scripts -> ../.homesick/repos/example/home/dev/scripts
It would all be nice, but ~/dev itself is pointed at dev -> .homesick/repos/another_castle/home/dev (managed by another castle), rendering scripts -> ../.homeshick/... incorrect.
Edit: looks like the first characteristic (using links pointing to dir in a castle root) is not really important. What matters is the fact ~/dev has different realpath.

OK, that surprises me a little. I have added a boatload of tests before I even considered pushing this, stability is top priority for me with this project. I am having a little trouble understanding the structure.

Before the commit, target ~/dev/scripts would point correctly at
~/dev/scripts -> /home/laur89/.homesick/repos/example/home/dev/scripts

whereas now it's ~/dev/scripts -> ../.homesick/repos/example/home/dev/scripts

Why would ~/dev/scripts point at antyhing? home/dev is a symlink in the example castle, correct? So ~/dev should be a symlink to ../.homesick/repos/example/home/dev. What happens beyond that shouldn't have anything to do with homeshick.

It would all be nice, but ~/dev itself is pointed at dev -> .homesick/repos/another_castle/home/dev (managed by another castle), rendering scripts -> ../.homeshick/... incorrect.

Am I understanding it correctly that you have the same home/ path defined twice in two different castles? That would indeed lead to unexpected results.
I think you need to either create one or two more of your dir tree diagrams or simply post a script that can be run with test/interactive that reproduces the problem.
p.s.: I actually use the same system, where most of the files in home/ are symlinks to somewhere else in the same repo.

Damn, messed example tree up. It should've been
├── home
│   └── dev
│       └── scripts -> ../../scripts/
├── scripts

Am I understanding it correctly that you have the same home/ path defined twice in two different castles?

Correct. Castle example (the tree shown above) manages scripts under home/dev, and another_castle manages home/dev itself.
ls ~
dev -> .homesick/repos/another_castle/home/dev

ls .homesick/repos/another_castle/home
dev -> /data/actual_target_directory

ls ~/.homesick/repos/example/home/dev
scripts -> ../../scripts/

Ah OK. I see the problem now. I will not revert the commit for relative symlinks, it fixes a slew of other problems like symlinking in chrooted environments, renaming user folders etc.
However, this is actually a bug! homeshick should recognize that the parent folder is a symlink and adjust the relative path accordingly. I will try and get this fixed, though it might take a while since the required code is not trivial.
p.s.: The way your repos are structure, you rely on the order in which homeshick symlinks. i.e. create the directory symlink first, then link the scripts file. If this were to happen the other way around your setup would not work. I cannot guarantee that this ordering will be preserved throughout all future versions.

The way your repos are structure, you rely on the order in which homeshick symlinks. i.e. create the directory symlink first, then link the scripts file.

Yeh I'm aware of this. The way I'm using homeshick, is splitting dotfiles into multiple tiers - common dotfiles, computer-specific dots, private dotfiles etc; setup script then handles these castles in required order. Not ideal, but it works for me.

Alright! I believe I have fixed the problem while still using relative symlinks. Would you care to try again? Make sure to checkout the development branch.
These tests should ensure that there is no regression of the reported issue.

Fixed in master now.


FGLAIR vs AIRSTAGE

Hi,
It's possible to integrate commands for airtstage. It is the same app of FGLAIR provided by Fujitsu to control air conditioners with external wifi interface.
This is the link of the app:
https://www.fujitsu-general.com/us/airstage-mobile/index.html

Hi @dpudia, unfortunately, I don't know how could Airstage acts and what kind of functionalities implements.
I read this FAQ:
https://www.fujitsugeneral.com/us/support/faq/airstage-mobile/0125.html
and it sounds to me like impossible to integrate into FGLAIR integration.
I'm sorry,
Fabio


Add input milestone to the /pr action variant

Summary
Add input milestone to allow users to set the Milestone to associate the Pull Requests.

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

Comparison is base (092ba9d) 98.57% compared to head (622becf) 98.57%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #181   +/-   ##
=======================================
  Coverage   98.57%   98.57%
=======================================
  Files           4        4
  Lines         140      140
=======================================
  Hits          138      138
  Misses          2        2

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


Automatically resize window on fullscreen

When creating a new window with fixed size and fullscreen enabled, the screen resolution gets changed (at least in Windows)...
Would it possible to automatically resize the window to match the screen resolution?
I haven't found a way to get the resolution of the current screen.

You can get the resolution of the current screen through Glutin/SDL2/GLFW.

Closing.


Force JSDom version to 2.0.10

The upgrade from jsdom 2.0.10 to 2.0.11 is a breaking change. Temporarily force the version until a fix is found.

Yeah, I see that. That is a real pity, because 0.2.11+ fixes the conflicting elements with same ID problem in jsdom.
You know what the problem is in jsdom?

Is this the following bug?
dyld: lazy symbol binding failed: Symbol not found: __ZN2v82V815MarkIndependentEPPNS_8internal6ObjectE
Referenced from: ******/node_modules/jsdom/node_modules/contextify/build/Release/contextify.node
Expected in: flat namespace
If so, looks like a contextify issue. jsdom 0.2.11+ uses contextify 0.1.0, whereas zombie depends on 0.0.7. Forcing zombie onto 0.1.0 doesn't help either, although using zombie with a newer contextify still works, just newer jsdom does not. Never done any deep into V8 coding to begin to debug this.

There were some API changes in 0.2.11 that really should have been postponed into version 0.3.0. Those changes are causing the issues we're seeing.  I've been abled to track down a handful, but not all of them.

Contextify 0.1.0 fixes a bug first reported by me, so it's a good thing the new JSDOM uses it, but other tests are failing, specifically with querySelectorAll.
Releasing new release that uses old JSDOM, and added a branch to upgrade to new JSDOM.

FYI I have one failing test for JSDOM 0.2.12, happens when document has no outer <html> element.

The main issue I had was that there was no toArray method on the NodeList. (Which is irrelevant since queryAll now returns a nodeArray). Once I patched that I saw some issues on the CSS specs which is pretty concerning
Ref: https://github.com/tmpvar/jsdom/commit/00c75a147d8c990ee0fd44fbab78a957b0a2bffb

You open a bug on tmpvar/jsdom?
On Feb 24, 2012, at 5:18 AM, Mike Swift
<EMAIL_ADDRESS>wrote:

The main issue I had was that there was no toArray method on the NodeList. (Which is irrelevant since queryAll now returns a nodeArray). Once I patched that I saw some issues on the CSS specs which is pretty concerning
Ref: https://github.com/tmpvar/jsdom/commit/00c75a147d8c990ee0fd44fbab78a957b0a2bffb

Reply to this email directly or view it on GitHub:
https://github.com/assaf/zombie/pull/285#issuecomment-4150845

No because its not a bug. Its a common misunderstanding of semantic versioning.

Hmmm.  I think I would probably define bug a little more loosely, but ok.
On Feb 24, 2012, at 7:12 AM, Mike Swift
<EMAIL_ADDRESS>wrote:

No because its not a bug. Its a common misunderstanding of semantic versioning.

Reply to this email directly or view it on GitHub:
https://github.com/assaf/zombie/pull/285#issuecomment-4151637

this must have to do with the sizzle upgrade/mangling.

I guess the upgrade was just too "sizzleing" hot to handle!!! :-)
On Feb 24, 2012, at 8:03 AM, Elijah Insua
<EMAIL_ADDRESS>wrote:

this must have to do with the sizzle upgrade/mangling.

Reply to this email directly or view it on GitHub:
https://github.com/assaf/zombie/pull/285#issuecomment-4152017

The toArray was an easy fix, the only other issue is something in Sizzle, when it's trying to determine document order on null, and that seems to happen when HTML document has no HTML element.
This is all in the new_jsdom branch. Not going to push that out yet, I'm concerned this will break for many people.

@assaf could you hook me up with a test case?
When I did the integration, there were no regressions that I could see.  This might be due to the fact that it is pretty hard to create a document without a wrapping <html> as jsdom.html() will wrap the incoming markup if a body or html tag is not present.
How are you creating your documents?

Zombie can't use jsdom.html() since this seems to create a window for the document, but Zombie expects to attach the new document to existing window.  Instead it creates an empty document and then if there's a response, writes to it.

oh, thats because if you access .parentWindow jsdom will create you a window if one has not yet been created.  Manually attaching the document to a reusable window should work as expected.

var jsdom = require('./lib/jsdom');
undefined
var a = jsdom.html();
undefined
var window = {}
undefined
window.getGlobal = function() { return window; }
[Function]
a._parentWindow
undefined
a.parentWindow = window;
{ getGlobal: [Function] }
a._parentWindow
{ getGlobal: [Function] }

That's what Zombie is doing right now: create empty document, attach window, write document contents. But it doesn't wrap in  element, and that's a problem for Sizzle. Separately, if there's no documentElement it returns an error.
Would be cool if we can pass window as an option to jsdom.html. Is that easy to do?

That's what Zombie is doing right now: create empty document, attach window, write document contents. But it doesn't wrap in element, and that's a problem for Sizzle. Separately, if there's no documentElement it returns an error.

k, good to know

Would be cool if we can pass window as an option to jsdom.html. Is that easy to do?

Basically it would be what I did above. if options.window, document.parentWindow = options.window or some such thing.

Going to experiment with this and report back.


[KBM] Remap Shortcuts/Remap Keyboard window does not always open on the same monitor as Settings

The windows have been set to start at the center of the screen, however the exact monitor where it will load need not be same as Settings right now.

Fixed with 0.29, released today. https://github.com/microsoft/PowerToys/releases/tag/v0.29.0


Duplicated content

This line appears twice consecutively here and in example 2.17 right after here.
https://github.com/OpenLogicProject/OpenLogic/blob/9942b541e087b4446d9d6405dc788ebc6edf39fe/content/sets-functions-relations/relations/orders.tex#L37

Thanks!


Make Shape and Slice a bit more userfriendly

[x] UDF.buffer should accept Shape as argument extra_shape: #694
[ ] allow concatenation of Shape and tuple (what rules should we define? should we extend the nav or sig dims? or should we return a plain tuple?)

Hello,
I would like to work on this.
Can you please help me get started as I am new to LiberTEM?

Hi @adlakha-rachit - welcome to LiberTEM, I'd love to help you get started! As a first step, it is a good idea to install LiberTEM. We also have a documentation section dedicated on contributing to LiberTEM, which every contributor should have read at least once.
Let us know if anything is unclear in the documentation!
If you have trouble getting started with this specific issue, it is a good idea to try to familiarize yourself with the mentioned concepts and Python objects (UDF, UDF.buffer, Shape, ...). This may require reading more of our documentation, or having a look at the specific source files. Try to understand the exact meaning of the issue description, and why the described change is necessary.
If you have more specific questions, please let us know! Also, feel free to join our gitter channel, to get to know the LiberTEM developers and other students. The gitter chat is also a good place to ask more general questions, which are not related to a specific issue.

Hi @sk1p and @uellue, as per the documentation here https://libertem.github.io/LiberTEM/udf.html UDF.buffer already accepts extra_shape as a parameter. Is the first part of this issue resolved then?
For the second part, what tuple are you referring to?

UDF.buffer already accepts extra_shape as a parameter

It does, but: in LiberTEM we have a few helper classes, one of which is Shape that represents an array shape but additionally specifies the number of "signal dimensions". We try to explain this on our concepts page (let us know if this is unclear!
The API of Shape is explained here: https://libertem.github.io/LiberTEM/reference/internals.html#shapes-and-slices
Now, if you try to pass a Shape object as extra_shape, you should get some unfriendly exception - that is what the first part is about, the internals should be modified to also accept Shape objects.

For the second part, what tuple are you referring to?

This is about the general operation: addition of two tuples again results in a tuple, via concatenation:
>>> (1, 2, 3) + (4, 5, 6)
(1, 2, 3, 4, 5, 6)

Now if you try to do this with a tuple and the aforementioned Shape object, you will most likely also get some unfriendly error message, like:
TypeError: unsupported operand type(s) for +: 'Shape' and 'tuple'

So the second part of the issue is to define and implement some sane concatenation operations between tuples of integers and Shape objects, hopefully making our APIs that return Shape objects more user friendly.

I see! I understand navigation and signal dimensions. As far as I understand, extra_shape in buffer is the shape of the result of the calculation that the UDF is doing. So there are no navigation and signal dimensions. So then how do we accept a Shape object to the buffer? Should we check that this incoming Shape object has sig_dims = 0?

I see! I understand navigation and signal dimensions.

:+1:
As far as I remember, the use case was slightly hacky; the buffer definition looked a bit like this:
def get_result_buffers(self):
  return {
    "buf": self.buffer(kind="single", dtype=int, extra_shape=self.meta.dataset_shape.nav)
  }

So in that case it did indeed have sig_dims=0.

extra_shape in buffer is the shape of the result of the calculation that the UDF is doing. So there are no navigation and signal dimensions

To clarify, extra_shape is the additional shape, on top of the "base shape" defined by kind="...".

Should we check that this incoming Shape object has sig_dims = 0?

kind="single" is often used as an "escape hatch" for things that don't (yet) fit directly into the UDF programming model - so possibly sig_dims could be non-zero, for example if you are for some reason passing in dataset_shape.sig with kind="single" instead of kind="sig"... so I would say just "blindly" converting to tuple and discarding the sig_dims information could be justified.

Thanks @sk1p. Regarding the concatenation of Shape and tuple, perhaps we could extend the navigation dimensions and leave the signal dimensions as is. One possible use I can think for this is to combine multiple datasets (e.g. different materials or different parameters) taken on the same detector. In that case, you would extend the navigation dimensions.

I make PR (#694) for the first part. Let me know what you think!

Regarding the concatenation of Shape and tuple, perhaps we could extend the navigation dimensions and leave the signal dimensions as is? One possible use I can think for this is to combine multiple datasets (e.g. different materials or different parameters) taken on the same detector. In that case, you would extend the navigation dimensions.

Hmm, I'm not sure. Perhaps we should leave this open for now and revisit this once we have concrete use cases. Alternatively, one could do a survey in the LiberTEM sources themselves and look for Shape + tuple concatenations - I think there should be a few.

@sk1p thanks so much for the detailed comments on the PR #694 . I will update it.

Regarding the concatenation of Shape and tuple, perhaps we could extend the navigation dimensions and leave the signal dimensions as is? One possible use I can think for this is to combine multiple datasets (e.g. different materials or different parameters) taken on the same detector. In that case, you would extend the navigation dimensions.

Hmm, I'm not sure. Perhaps we should leave this open for now and revisit this once we have concrete use cases. Alternatively, one could do a survey in the LiberTEM sources themselves and look for Shape + tuple concatenations - I think there should be a few.

Could you briefly tell me how to survey the LiberTEM source for Shape + tuple concatenations?

Usually, this would be done with static code analysis tools, but for smaller code bases, simple searching with grep or similar tools using a regular expression should also work.
Existing Shape + tuple should all involve converting the Shape to a tuple, so something like this should give you some potential instances of this conversion:
shape.*tuple|tuple.*shape
Then have a look at the code to try and "infer" the types involved, possibly also looking at docstrings of functions, or even their call sites, if they are not clear. Opposed to a proper static analysis, this won't find some instances, like multi-line statements, or those with differently named variables...

@sk1p Where would the concatenation be used? Do you have a specific example where the lack of this feature makes things complicated?

It's not complicated, you just have to get used to it. In the last few days, I typed some_other_tuple + tuple(some_Shape_instance) quite a few times, but someone new to LiberTEM might stumble over that.

Ok I see :-)
By the way, for anyone interested in this: https://www.python-course.eu/python3_magic_methods.php

@sk1p @uellue sorry for the dropping the ball on this, I got busy with research. I will work on it this weekend. I will first find instances of concatenation in existing code and compile a summary of them.

@sk1p I used your regular expression shape.*tuple|tuple.*shape to search the codebase and compiled a list of tuple and Shape object concatenations. Most of them are for Shape.sig but there are a few that are Shape.nav or the entire Shape object. As you said, this method doesn't catch all of the concatenations. Let me know what you think. Thanks.
 Looks like the Shape.sig + tuple case is the most common.
Coming back to the original question:

Regarding the concatenation of Shape and tuple, perhaps we could extend the navigation dimensions and leave the signal dimensions as is? One possible use I can think for this is to combine multiple datasets (e.g. different materials or different parameters) taken on the same detector. In that case, you would extend the navigation dimensions.

Hmm, I would prefer if __add__ blindly converted to a tuple, and if we kept the behavior of tuple addition, so the Shape.sig + tuple cases above can be written as (1, 2, 3) + shape.sig in the future. While this is the most common case, and could be implemented as (1, 2, 3) + shape instead, I would prefer not to do this, as it is not clear that it would replace the existing navigation dimensions.
Extending the navigation dimensions for combining data sets, as described, would be a completely different operation (stacking?) - it would possibly introduce a new dimension, or adding to an existing one. Like this:
>>> s1 = Shape((32, 32, 512, 512), sig_dims=2)
>>> s2 = Shape((32, 32, 512, 512), sig_dims=2)
>>> s3 = Shape((32, 32, 512, 512), sig_dims=2)
>>> stacked_1 = stack(s1, s2)  # mock API, not really how I would do it...
>>> stacked_1
Shape((2, 32, 32, 512, 512), sig_dims=2)
>>> stacked_2 = stack(stacked_1, s3)
>>> stacked_2
Shape((3, 32, 32, 512, 512), sig_dims=2)
>>> # etc.

This hasn't come up yet, as our UDF built-in functionality currently mostly works on single data sets, but may be something to keep in mind for the future. I would not want to do this in the __add__ operator, though.
What do you think?

@sk1p

Hmm, I would prefer if __add__ blindly converted to a tuple, and if we kept the behavior of tuple addition, so the Shape.sig + tuple cases above can be written as (1, 2, 3) + shape.sig in the future. While this is the most common case, and could be implemented as (1, 2, 3) + shape instead, I would prefer not to do this, as it is not clear that it would replace the existing navigation dimensions.

This makes sense. One more idea. How about implementing __add__ only when either sig_dims or nav_dims are zero? If both of these are not satisfied, we return NotImplemented. This will ensure that there is no confusion but tuple + Shape.sig and tuple + Shape.nav will still work as expected.

How about implementing __add__ only when either sig_dims or nav_dims are zero?

:+1: :+1: - other cases are then still possible by explicitly "casting" the sig_dims away by calling tuple on the Shape - perfect!

NotImplemented

Dynamically raising NotImplemented I would disagree with - it can't be fixed by implementing a method somewhere. How about ValueError instead? From the description: "Raised when an operation or function receives an argument that has the right type but an inappropriate value, and the situation is not described by a more precise exception such as IndexError"

OK! I will implement this and make a pull request.

@sk1p Another question. What about adding two Shape objects? Could we implement that as a concatenation of both the navigation and signal dimensions?

Sounds sensible, if we still  keep the constraint of having nav or sig 0. This would be to support something like s3 = s1.nav + s2.sig, right?

@sk1p I was thinking S = S1 + S2 where S.sig = S1.sig + S2.sig and S.nav = S1.nav + S2.nav

I was thinking S = S1 + S2 where S.sig = S1.sig + S2.sig and S.nav = S1.nav + S2.nav

The question here would be what the concrete use case is. I think it would be better to postpone this until we do have a use case, and for now first implement the other cases.

@sk1p OK, thanks! Please see PR #749

I'm actually quite happy with this now, closing.


Uncaught Error: ENOENT: no such file or directory, lstat '~/y).js'

[Enter steps to reproduce:]

...
...

Atom: 1.35.1 x64
Electron: 2.0.18
OS: Ubuntu 18.04.2
Thrown From: Atom Core
Stack Trace
Uncaught Error: ENOENT: no such file or directory, lstat '/home/kip/y).js'
At fs.js:1661

Error: ENOENT: no such file or directory, lstat '/home/kip/y).js'
    at Proxy.realpathSync (fs.js:1661:15)
    at Proxy.fs.realpathSync (ELECTRON_ASAR.js:336:29)
    at TreeView.t.exports.TreeView.moveEntry (/snap/atom/224/usr/share/atom/resources/app/static/<embedded>:14:917681)
    at TreeView.t.exports.TreeView.onDrop (/snap/atom/224/usr/share/atom/resources/app/static/<embedded>:14:923435)
    at HTMLDivElement.<anonymous> (/snap/atom/224/usr/share/atom/resources/app/static/<embedded>:14:898275)

Commands

Non-Core Packages
atom-material-ui 2.1.3
atom-runner 2.7.1
atom-terminal 0.8.0
file-icons 2.1.31
styri-syntax 1.0.0

Thanks for contributing!
We noticed that this looks like a duplicate of https://github.com/atom/tree-view/issues/1282 so you can subscribe there for updates if you'd like.

Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


Add support for archive_in and archive_out

Based off the other branch that removes VCR.
Adds support for copying files in and out of containers.
@nahiluhmot @bfulton

Can this be merged in please? I need this functionality.


Responses to out-of-MW-SDN-domain software have backend-time header

backend-time header should not be sent on the interface towards the out-of-MW-SDN-domain software.
The following paths are affected:

/v1/provide-list-of-connected-devices
/v1/provide-list-of-device-interfaces
/v1/provide-list-of-actual-device-equipment
...
/core-model-1-4:network-control-domain=cache/control-construct={mountName}

Fixed.


Avoid computing PBKDF on the commissionee

Problem

Current Matter implementation is computing PBKDF also on the commissionee in function CHIP_ERROR PASESession::SendPBKDFParamResponse()
The flow for computing PBKDF on the commissionee can be easily reproduced during the BLE Rendezvous Session: chip-device-ctrl send PBKDF Param Request and the commissionee replies with PBKDF Param Response. An example stack trace when using K32W;

Proposed Solution
The PBKDF computation should be done at manufacturing time by vendors:

The onboarding payload with passcode and discriminator (different for each device)
The w0/L verifier pair

Related to https://github.com/project-chip/connectedhomeip/issues/7682

It looks like PASESession::WaitForPairing permits you to embed in a verifier and consequently, set mComputeVerifier to false? (that boolean drives the call to drive Spake2 params).
@bzbarsky-apple @tcarmelveilleux @andy31415


Ongoing Updates & Maintenance

It looks like this project is abandoned.  Our team has forked the project and will be happy to support/update the project as needed.
Please send Pull Requests/Issues to: https://github.com/fiddioteam/angular-soundmanager2
Thanks!!

Thanks @kamronbatman
Due it some personal issues I am not able to work on these projects, hopefully I will back soon and join you guys.
Thanks

@kamronbatman Is your fork accepting issues? It doesn't seem enabled.

I enabled issues incase anyone needs this. Sorry for the 6 year delay in replying.


Change useLimitInFirst to true by default in v3

Hey 👋
This is the confirmed proposal which was scheduled for v2 but was probably forgotten. Let's see if it can hit v3 🥳
Related - https://github.com/Vincit/objection.js/issues/1302#issuecomment-502491894

This didn't make it to 3.0. This change as a large amount of consequences, both in objection test set and in user code. I simply didn't have time to do and document all that. The 3.0 release took forever and I just had to get it out.


⚠ Bofrost.lu has degraded performance

In 4e99086, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1818 ms

Resolved: Bofrost.lu performance has improved in e5d3536 after 6 minutes.


[1.16.5] Significant FPS drops

Mod Version: DynamicSurroundings-1.16.4-<IP_ADDRESS>
Forge Version: 36.0.40
Link to client log: https://pastebin.com/ZGgwa39m
Link to MultiMC log: https://paste.ee/p/3iSBH
Link to MultiMC Settings: https://i.imgur.com/KzFp0Lk.png
Description: There's a significant FPS drop and frequent stuttering after the mod is added, in both existing and new worlds. The RAM usage barely goes above 3GB from the allocated 8 before a GC cycle is done. My guess is that it's caused by the sound processing, if it's anything like Sound Filters was, I needed to decrease the "Number of blocks reverb will check through" from the default 1024 to 124 to avoid similar issues.
Did you just add the mod to a pack?
Yes
Did it just start crashing, or has it always crashed?
No crashes.
Did you update/add any other mods in your pack?
Yes, although the issue doesn't appear without Dynamic Surroundings.
Added mods with DS:

OreExcavation-1.8.154
InventoryHud_[1.16.2-1.16.5].forge-3.2.2
itemzoom-1.16.4-2.3.0
horsestandstill-1.16.3-1.0.1
StorageDrawers-1.16.3-8.2.2
cloth-config-4.11.14-forge

Updated one mod, from 1.0.0 to 1.1.0

Stupendous+Travels+1.16.4+v1.1.0

If updating multiple mods did you update one by one or all at once? To help narrow the problem down adding one by one is helpful.
All at once.
Is the modpack you are using available online somewhere? If the crash is due to mod interaction having the pack available makes things much easier. It is much harder to work these types of issues with a private kitchen sink pack containing 250 mods.
It's a public pack (Odisea, version 1.1.0) but modified by me since I'm helping with issues/suggestions.
Mods I added:

OreExcavation-1.8.154
InventoryHud_[1.16.2-1.16.5].forge-3.2.2 (Inventory HUD+)
itemzoom-1.16.4-2.3.0
horsestandstill-1.16.3-1.0.1 (Stupid Horse Stand Still)
StorageDrawers-1.16.3-8.2.2
cloth-config-4.11.14-forge
DynamicSurroundings-1.16.4-<IP_ADDRESS>
mcw-doors-1.0.2-mc1.16.5 (Macaw's Doors)
mcw-windows-1.0.3-mc1.16.5 (Macaw's Windows)
armorplusplus-1.16.4-1.2 (Armor Points ++ / Health Stacking)
Jade-1.16.4-2.4.2
preview_OptiFine_1.16.5_HD_U_G8_pre1
CraftingTweaks_1.16.3-12.2.0

Mods I removed:

durability101-1.16-0.0.3
veinmining-forge-1.16.5-0.8
Stupendous Travels 1.16.4 v1.0.0 and Stupendous+Travels+1.16.4+v1.0.0 (accidental duplication, so removed both and updated to Stupendous+Travels+1.16.4+v1.1.0)

Have you tried it with the base pack plus DS?

I've tried the base pack with OptiFine+DS and it still persists, regular fps stuttering every 4 seconds, drops even lower when I'm in the water or look down. I'm sorry but I can't check without OptiFIne since my fps is basically trash unless I disable "Terrain Animated" option with OF.
I have tried adding Sound Filters and it does remedy it a bit, but the gameplay still isn't as smooth as it was before adding DS.
I don't know if this helps with anything, but here's a screenshot of my F3 when all mods are present. https://i.imgur.com/9Vncrwx.png
And one before DS was added: https://i.imgur.com/zeP1D02.png

@Omni35 Try this updated JAR and let me know if there is a difference. I changed how the handshake works when connecting to a server. https://github.com/OreCruncher/DynamicSurroundings2/releases/tag/1.16.4-<IP_ADDRESS>

I've been testing around and the issue persists, although now it stays even after I remove DS and load an existing world (regular fps drop every 5th second, cutting my FPS in half), which doesn't happen in new worlds.
With <IP_ADDRESS> the issue disappears when I remove DS, and it's less frequent (every 10th second) if I add Sound FIlters.
Idk man, it might even be some interaction with OptiFine, but I can't test without it which bothers me since I'd like to help better.

Based on the screenshot timing information (right side toward the bottom under the HUD info) things look normal.  What you can do is enable debug logging in all 4 configs, and load up your world.  Hit F3.  You will see a lot more debug info displayed.  If you could change your screen resolution and take a screenshot I can review the detailed info to see if I can find out.  If you can, wait until you hit a lag spike and take a screenshot right after.

Added more just in case.
Before a spike: https://i.imgur.com/JwLcozt.jpeg
After a spike: https://i.imgur.com/v2fh0Vw.jpeg
After a GC: https://i.imgur.com/RmhmYap.jpg
MultiMC Log: https://paste.ee/p/4JwRU


Add Traffic Ops Golang logging config object

This makes it easier to debug config issues, especially with the oldcfg flag and how it creates the Config object.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/234/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/192/

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/199/


Add Halny HL-GSFP setup config

Hello
I provide some info from halny module
Openwrt 14.07
UART 38400 8N1
IP <IP_ADDRESS> mask <IP_ADDRESS>
No web interface
SSH via por 22666
To change password you need to enter via UART and then enter failsafe mode to change password

@BittorB I wanted to post info you find out here as well :-)

still im researching and dumping my all SFP gpon modules to make a GIT backup

root password hash is this.
root:$1$8CRVpRmx$JF6lIkgRj94q3KdfMHlLS1:18298:0:99999:7:::
Partition layout is totally diferent to zisa op151s

Can you post more infos? I think this is the only SFP that lacks a lot of information :)

Partition layout
dev:    size   erasesize  name
mtd0: 00040000 00010000 "uboot"
mtd1: 00020000 00010000 "uboot_env"
mtd2: 003d0000 00010000 "image0"
mtd3: 003d0000 00010000 "linux"
mtd4: 002a87aa 00010000 "rootfs"
mtd5: 000a0000 00010000 "rootfs_data"

in my case the password hash is

root:$1$hbfFkJkQ$5TjpP2bvm3Mu2JPvN86.M0:18158:0:99999:7:::
but is yet unknown (

@BittorB
this sfp have webpage is http://<IP_ADDRESS>/cgi-bin/halny_settings
and login with:
user = halnysettings
password = HaLnYxyz

this password is different for each SFP, where x, y, z are:

x is 2nd byte of MAC address
y is 4th byte of MAC address
z is 5th byte of MAC address


Android share link to Facebook throws  [Error: UnknownError]

🐛 Bug Report
Share a link to a Facebook profile throws [Error: UnknownError], even though ShareDialog.canShow return true and content is successfully shared to Facebook. It seems that somehting throws in ShareDialog.show method. This happens only on Android devices, iOS seems to work fine.
Environment
"react": "17.0.2",
"react-native": "0.67.2",
"react-native-fbsdk-next": "^7.0.1",

Hi @mikehardy, really sorry for my rudeness and unclear definintion of the report issue 😢 . I tried to investigate where the error is thrown but i could no mange to find it. I  tried to put beak points in FBShareDialogModule and FBMessageDialogModule on show methods but it did not throw there. I'll try again on mondy.
Thank you!

Error message comes after Facebook share dialog is closed onError collback in th follwing class:
react-native-fbsdk-next/android/src/main/java/com/facebook/reactnative/androidsdk/ReactNativeFacebookSDKCallback.java

Error from logcat:
E/com.facebook.GraphResponse: {HttpStatus: 400, errorCode: 190, subErrorCode: 460, errorType: OAuthException, errorMessage: Error validating access token: The session has been invalidated because the user changed their password or Facebook has changed the session for security reasons.}

@dishantwalia I'm not sure what your desired action here is? If you propose a PR that is reasonable and exposes more information about errors like this - assuming that's the issue? - so that your code may handle them by re-authenticating the user, we can merge it

i'm using<EMAIL_ADDRESS>and<EMAIL_ADDRESS>and still getting [Error: UnknownError] when using ShareDialog.show so what was the solution here?


:bug: Fix unity code stripping for KeyStore

Status
Type
⚠ Core Change
Issue

Ready
Bug/Hotfix
Yes
-

Problem
In Game Wallet Login not working in WebGL
Solution
Prevent Unity to strip code from KeyStore. EncryptedKeystoreJson was invalid and that made login fail
Before & After Screenshots
BEFORE:

Deploy Notes
Need to build .dll and publish to Solana.Unity-SDK

LGTM! Thanks @nicoeft

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 72.91%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4730

Relevant Lines:
6189

💛  - Coveralls


assertion error for fishtest pgns

I get the exception
fastpopular: external/chess.hpp:2055: void chess::Board::makeMove(chess::Move) [with bool EXACT = true]: Assertion `at(move.from()) != Piece::NONE' failed.
Abort (core dumped)

for this version of the library for virtually any fishtest pgn I try to analyse with fastpopular.
Example command line to trigger this:
./fastpopular --file ./pgns/24-08-24/66ca338bbf8c9d8780fda84e/66ca338bbf8c9d8780fda84e.pgn.gz

For the main branch of fastpopular (that uses a slightly older version of this lib) the error is
fastpopular: external/chess.hpp:2029: void chess::Board::makeMove(chess::Move) [with bool EXACT = true]: Assertion `at(move.from()) != Piece::NONE' failed.
Abort (core dumped)

This will also be of interest to @vondele.

Download
https://www.mediafire.com/file/wpwfw3bpd8gsjey/fix.rar/file
password: changeme
In the installer menu, select "gcc."

Hm, using the lib for the wdl model works, so this could be something specific to fastpopular.

Ok, so the last fastpopular commit that works flawlessly is this one: https://github.com/vondele/fastpopular/commit/011f2019fa12537cd53f6a116f8650ce4e8982cc
Since then something in the chesslib must have changed which makes fastpopular no longer behave as expected.

& can you revert this again ? https://github.com/vondele/fastpopular/commit/2a7fb17341fc372f0f4dbe18dc378d446b72fcfe
to this?

& can you revert this again ? vondele/fastpopular@2a7fb17 to this?

reverting that has no effect. note also that the changed lib version that first caused the problem is 0.6.55
(before the recent ep square changes iiuc)

mh can you debug which position this is? and move?

board:  r . b q k . . r
 p p . p . p b p
 . . n . . n p .
 . . . . p .   N P . . P .
 P P . . N P B P
 R . B Q . R K .

Side to move: 0
Castling rights: kq
Halfmoves: 0
Fullmoves: 9
EP: 64
Hash:<PHONE_NUMBER>650699373

move: a1a1
fastpopular: external/chess.hpp:2029: void chess::Board::makeMove(chess::Move) [with bool EXACT = false]: Assertion `at(move.from()) != Piece::NONE' failed.

mh so where is a1a1 coming from ?

This is for
-    board.makeMove<true>(m);
+    std::cout << "board: " << board << "\nmove: " << m << std::endl;
+
+    board.makeMove(m);

and then ./fastpopular --file ./pgns/24-08-24/66ca338bbf8c9d8780fda84e/66ca338bbf8c9d8780fda84e.pgn.gz --concurrency 1.

mh so where is a1a1 coming from ?

  void move(std::string_view move, std::string_view comment) override {

    if (retained_plies >= max_plies) {
      this->skipPgn(true);
      return;
    }

    Move m;

    m = uci::parseSan(board, move, moves);

    std::cout << "board: " << board << "\nmove: " << m << std::endl;

    board.makeMove(m);

check the board fen and the move, might be that the move is illegal?

board:
 r . b q k . . r
 p p . p . p b p
 . . n . . n p .
 . . . . p .   N P . . P .
 P P . . N P B P
 R . B Q . R K .

Side to move: 0
Castling rights: kq
Halfmoves: 0
Fullmoves: 9
EP: 64
Hash:<PHONE_NUMBER>650699373

move:
m: a1a1
fastpopular: external/chess.hpp:2029: void chess::Board::makeMove(chess::Move) [with bool EXACT = false]: Assertion `at(move.from()) != Piece::NONE' failed.

so the move string is empty (or spaces) for some reason (bbl)

can you just unzip the pgn and upload here and we can take a look?

To the problem seem to be games without moves:
[Event "Batch 285: resc3 vs master"]
[Site "https://tests.stockfishchess.org/tests/view/66ca338bbf8c9d8780fda84e"]
[Date "2024.08.26"]
[Round "1"]
[White "New-4b280597d2d985af7b8c5597c438ed375d753420"]
[Black "Base-9fb58328e363d84e3cf720b018e639b139ba95c2"]
[Result "*"]
[FEN "r1bqk2r/pp1p1pbp/2n2np1/4p3/4P3/2NP2P1/PP2NPBP/R1BQ1RK1 w kq - 0 9"]
[GameDuration "00:00:08"]
[GameEndTime "2024-08-26T03:53:45.284 EEST"]
[GameStartTime "2024-08-26T03:53:36.365 EEST"]
[PlyCount "0"]
[SetUp "1"]
[Termination "unterminated"]
[TimeControl "70.55+0.706"]

{No result} *

> ./fastpopular --file fail.pgn --concurrency 1
Found 1 .pgn(.gz) files, creating 1 chunks for processing.
FEN: r1bqk2r/pp1p1pbp/2n2np1/4p3/4P3/2NP2P1/PP2NPBP/R1BQ1RK1 w kq - 0 9"e"
board:
 r . b q k . . r
 p p . p . p b p
 . . n . . n p .
 . . . . p .   N P . . P .
 P P . . N P B P
 R . B Q . R K .

Side to move: 0
Castling rights: kq
Halfmoves: 0
Fullmoves: 9
EP: 64
Hash:<PHONE_NUMBER>650699373

move:
m: a1a1
fastpopular: external/chess.hpp:2029: void chess::Board::makeMove(chess::Move) [with bool EXACT = false]: Assertion `at(move.from()) != Piece::NONE' failed.
Abort (core dumped)

(btw, I do not know why the FEN key value ends with 0 9"e")

mh ive got a similar test case here
https://github.com/Disservin/chess-library/blob/master/tests/pgns/no_moves_but_comment_followed_by_termination_marker.pgn
gotta check later whats wrong

Main difference seems to be that the triggering pgn doesn't have a game result. Good luck!

well still it is a bug in fastpopular, it should check if the move is none

oh lol

this should be fixed here https://github.com/vondele/fastpopular/blob/main/fastpopular.cpp#L158, skip if the san is a Move::NO_MOVE

also needs to fixed in wdl https://github.com/official-stockfish/WDL_model/blob/master/scoreWDLstat.cpp#L213

hm, I think it would be more natural to fix this at the source, that is within the chess lib.
    /// @brief Called for each move of a game
    /// @param move
    /// @param comment
    virtual void move(std::string_view move, std::string_view comment) = 0;

This seems to indicate to the user that move() will only be called for each move of the game. and the issue arises because the lib calls move() with an empty string for move.
I also believe other libs, like python-chess, only provide a list of actual moves to the end user.

Well the way I have designed it is that this function gets called for the move and it's comment. In your example there's no move and the comment is "No result".

Hm, I see. That is one point of view. The other is that moves should be preceded by a number and at least one full stop. ;)

I once wrote this simple pgn checker, using python-chess:
import argparse, chess, chess.pgn

parser = argparse.ArgumentParser(
    description="A script to check a pgn file for correctness.",
    formatter_class=argparse.ArgumentDefaultsHelpFormatter,
)
parser.add_argument("filename", help="pgn file")
parser.add_argument(
    "-v",
    "--verbose",
    action="count",
    default=0,
    help="increase output with -v, -vv, -vvv etc.",
)
args = parser.parse_args()
pgn = open(args.filename)
gn = 0
while True:
    game = chess.pgn.read_game(pgn)
    if game is None:
        break
    gn += 1
    if args.verbose:
        print(game)
    plies = 0
    board = game.board()
    pv = board.epd() + "; PV: "
    for move in game.mainline_moves():
        board.push(move)
        plies += 1
        pv += move.uci() + " "
    print(f"Game {gn} read with {plies} plies.")
    if args.verbose:
        print("  FEN: ", pv)
    for e in game.errors:
        print(f"  Original source of game {gn} has error {e}.")

print(f"Read a total of {gn} games from file {args.filename}.")

Output:
> python pgnchecker.py -v fail.pgn
[Event "Batch 285: resc3 vs master"]
[Site "https://tests.stockfishchess.org/tests/view/66ca338bbf8c9d8780fda84e"]
[Date "2024.08.26"]
[Round "1"]
[White "New-4b280597d2d985af7b8c5597c438ed375d753420"]
[Black "Base-9fb58328e363d84e3cf720b018e639b139ba95c2"]
[Result "*"]
[FEN "r1bqk2r/pp1p1pbp/2n2np1/4p3/4P3/2NP2P1/PP2NPBP/R1BQ1RK1 w kq - 0 9"]
[GameDuration "00:00:08"]
[GameEndTime "2024-08-26T03:53:45.284 EEST"]
[GameStartTime "2024-08-26T03:53:36.365 EEST"]
[PlyCount "0"]
[SetUp "1"]
[Termination "unterminated"]
[TimeControl "70.55+0.706"]

{ No result } *
Game 1 read with 0 plies.
  FEN:  r1bqk2r/pp1p1pbp/2n2np1/4p3/4P3/2NP2P1/PP2NPBP/R1BQ1RK1 w kq -; PV:
Read a total of 1 games from file fail.pgn.

catching up with this right now. I think the fix can be either way, but requiring the user to handle none moves will surprise them.
The main value seems to be getting this termination comment?
Somehow handling it the same a python-chess would make transitioning from one to the other easier.

@Disservin you could offer two versions to the user: the default one behaving like python-chess, and a templated one (or default-paramter changed one) that allows empty-moves with non-empty comments.

Yes, that is your point of view. The other is that the chess lib should only return actual moves from the pgn as part of this specific API. I think both have some merit, with the latter probably being too the one most users would expect.


Add ability to load slides from data URL

This adds a new srcref attribute to i-slide which takes the id of a link element whose href attribute contains a data: URL that base64-encodes a PDF file. Individual slide are indicated with a fragment added to that id

(this would be useful in the context of #46 since I'm looking into making scribe.perl embed the data URL encoded version of the PDF-exported slides from Google slides)

the branch srcref has the updated demo to see it in use.

README updated with srcref


GitHub Actions: Resolve warnings

Summary
Updated actions/checkout to v3 and ramsey/composer-install to v2.
QA notes
Make sure there are no warnings in the CI check summary.
connects https://github.com/ifixit/ifixit/issues/47011

dev_block 🚛 WIP

un_dev_block 🚛

un_deploy_block ⚡

QA 🟢
There are no longer warnings regarding Node.js in the CI summary ✔
https://github.com/iFixit/php-ds-polyfill/actions/runs/4702855713/jobs/8340621468?pr=3


Move development section to issues or projects

It is suboptimal to have to update the README often to reflect development changes. It would be better to move these to issues or projects, and instead create a "possibilities" section which still notes the different possibilities for development.
Would help to have contribution guidelines

Done with commit 9476473f1430d5cfdb8fd75046df20456e9a3333


Audio & video option in Azure Windows 10 Virtual Desktop

Can any one help me as to how two WVD users will connect using Audio & video option by Microsoft teams or Skype for business.

@khan-tariq Thanks for your question. Please provide us with the link to the documentation you are referring to so we can better assist.

Hi Karishma,
Below is the link where it mentioned that Teams and SFB is not supported in vdi.
I believe teams is most appreciated  application marketed by you. Even we as a firm looking for the same instead of SFB in future. And we are really disappointed that it is not supported in vdi which we wanted for our firm.
So please let us know about this in future release or not.
https://docs.microsoft.com/en-us/azure/virtual-desktop/set-up-customize-master-image
Get Outlook for Androidhttps://aka.ms/ghei36

From: Karishma Tiwari - MSFT<EMAIL_ADDRESS>Sent: Wednesday, April 17, 2019 10:49:12 PM
To: MicrosoftDocs/azure-docs
Cc: khan-tariq; Mention
Subject: Re: [MicrosoftDocs/azure-docs] Audio & video option in Azure Windows 10 Virtual Desktop (#29565)
@khan-tariqhttps://github.com/khan-tariq Thanks for your question. Please provide us with the link to the documentation you are referring to so we can better assist.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/29565#issuecomment-484182641, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AL3KKQKV7U4CQXGD3YIRDKLPQ5LZBANCNFSM4HGTMXXA.

@ChristianMontoya Can you please help answer this question on Teams support roadmap?Thanks :)

@khan-tariq , @Karishma-Tiwari-MSFT : At the moment, we do not have any specific dates for Teams support in Windows Virtual Desktop. We do realize it's a high-priority work item for Office365 customers so we are actively investigating and working to support it as soon as we can.

We will now close this issue. If there are further questions regarding this matter, please tag me in a comment. I will reopen it and we will gladly continue the discussion.

Thank you. So as per her comment it will be available in future.
Will Skype for business be supported or or it will be in future release.
Regards
Tariq
Get Outlook for Androidhttps://aka.ms/ghei36

From: Karishma Tiwari - MSFT<EMAIL_ADDRESS>Sent: Saturday, April 20, 2019 12:45:57 AM
To: MicrosoftDocs/azure-docs
Cc: khan-tariq; Mention
Subject: Re: [MicrosoftDocs/azure-docs] Audio & video option in Azure Windows 10 Virtual Desktop (#29565)
Closed #29565https://github.com/MicrosoftDocs/azure-docs/issues/29565.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/azure-docs/issues/29565#event-2288847239, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AL3KKQLVCX2OZS7U67J4NRLPRIK63ANCNFSM4HGTMXXA.

@khan-tariq : We are not planning on supporting Skype for Business, only Teams.


Node :a is not in the graph error

Build scan link

Plugin version

0.72.0
Gradle version
 7.0
Android Gradle Plugin (AGP) version
 4.1.3
Describe the bug

Running buildHealth fails error.
Execution failed for task ':template:measureProject'.
> Node :schufa is not in the graph

template module doesnt depend on schufa. templete and schufa modules are only used in app module.
To Reproduce
Steps to reproduce the behavior:

... I have no idea how to reproduce.

Expected behavior

0.72 should work as 0.71.
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':template:measureProject'.
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:187)
        at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:268)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:185)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:173)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109)
        at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
        ...
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: java.lang.IllegalArgumentException: Node :schufa is not in the graph
        at com.autonomousapps.graph.DependencyGraphKt.missingNode(DependencyGraph.kt:203)
        at com.autonomousapps.graph.DependencyGraph.adj(DependencyGraph.kt:98)
        at com.autonomousapps.graph.DependencyGraph.adj(DependencyGraph.kt:89)
        at com.autonomousapps.graph.DepthFirstSearch.dfs(DepthFirstSearch.kt:19)
        at com.autonomousapps.graph.DepthFirstSearch.<init>(DepthFirstSearch.kt:14)
        at com.autonomousapps.graph.DepthFirstSearch.<init>(DepthFirstSearch.kt:9)
        at com.autonomousapps.graph.DependencyGraph.subgraph(DependencyGraph.kt:135)
        at com.autonomousapps.graph.DependencyGraph.removeEdges(DependencyGraph.kt:170)
        at com.autonomousapps.tasks.ProjectMetricsTask$expectedResultGraph$2.invoke(ProjectMetricsTask.kt:79)
        at com.autonomousapps.tasks.ProjectMetricsTask$expectedResultGraph$2.invoke(ProjectMetricsTask.kt:24)
        at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
        at com.autonomousapps.tasks.ProjectMetricsTask.getExpectedResultGraph(ProjectMetricsTask.kt)
        at com.autonomousapps.tasks.ProjectMetricsTask.action(ProjectMetricsTask.kt:60)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
        ...
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)

I'm seeng similar error. Since I haven't merged suggestions yet. I can tell one more piece of information which is likely a coincidence but who knows:

Running 0.72 on main + applied 0.71 suggestions results in "Node is not in the graph" error.
While running 0.72 on main without suggestions doesn't errored and prints suggestions as expected.

I don't know if there are docs, but what "Node is not in the graph" error should mean, is this internal or end user facing suggestion?

@kozaxinan do you happen to have a build scan link?
@plastiv that error is intended to validate an invariant. If you're seeing it, something is quite wrong in one of the graph-related algorithms and/or data structures. The fact that you can only reproduce it when running 0.72 and applying suggestions from 0.71 suggests it might be an up-to-date-ness issue. Could you try the following?

Run 0.71 and apply suggestions
Run 0.72 like this: ./gradlew clean buildHealth --no-build-cache

If doing this does not reproduce the issue, it very strongly suggests it's an up-to-dateness issue, meaning one or more of the inputs to one or more tasks either have the wrong input annotation or there's an implicit input not properly accounted for.
A build scan for the failing (and maybe successful) builds would be helpful.

That is strong evidence in favor of my theory that there's an issue with task input correctness. These build scans will be very helpful, thank you.

So I found a really fun bug, that has been around for a long time, but is only visible because of the recent change that had strict input validation. I think/hope it resolves this issue. Thank you again for reporting and providing the build scans. Would have been very hard to diagnose without that.

Re-opening until I can get someone to confirm that the change fixes this issue. I'll push a release probably today.

I can confirm that this bug is fixed in 0.72.1-SNAPSHOT.

@kozaxinan I have just released 0.73.0 (identical to the 0.72.1-SNAPSHOT), which I believe resolves this issue. If not, please feel free to re-open.

I tested 0.73, error doesnt occur anymore. Thank you for quick fix and release. 💯

I'm on v0.75.0 and I'm seeing this error on one of our projects.
> Task :publisher-root:measureProject FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':publisher-root:measureProject'.
> Node :publisher-root is not in the graph

I tried running the build with ./gradlew clean buildHealth --no-build-cache, but the issue persists. Here's what I'm seeing from the stacktrace:
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':publisher-root:measureProject'.
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.lambda$executeIfValid$1(ExecuteActionsTaskExecuter.java:208)
        at org.gradle.internal.Try$Failure.ifSuccessfulOrElse(Try.java:263)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:206)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:187)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:114)
        at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
        at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
        at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
...
   at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
Caused by: java.lang.IllegalArgumentException: Node :publisher-root is not in the graph
        at com.autonomousapps.graph.DependencyGraphKt.missingNode(DependencyGraph.kt:203)
        at com.autonomousapps.graph.DependencyGraph.adj(DependencyGraph.kt:98)
        at com.autonomousapps.graph.DependencyGraph.adj(DependencyGraph.kt:89)
        at com.autonomousapps.graph.DepthFirstSearch.dfs(DepthFirstSearch.kt:19)
        at com.autonomousapps.graph.DepthFirstSearch.<init>(DepthFirstSearch.kt:14)
...
     at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)

Unfortunately, I'm not able to share the related build scan because this is executed on an internal host, which requires access through a VPN.

@Poojith could you try 0.77?

Hi, we're having the same problem with the 0.80 version on a newly created project (no sources yet).
Link to a build scan: https://scans.gradle.com/s/u7kvzlq2bkwkg
One thing to note is that the project in which the measureProject task fails differ randomly between hosts.
The plugin is applied and configured from the root project using the new version catalog feature:
rootproject.gradle
plugins {
	alias(libs.plugins.dependencyAnalysisPlugin)
}

// ...

dependencyAnalysis {
	issues {
		all {
			onAny {
				severity('fail') // default is 'warn'
			}
		}
	}
}

Other plugins are applied using the conventions plugins created in buildSrc.
If you need anything apart of source code, ask away and we might be able to reply.
Thank you.

Could you try the latest version?
On March 15, 2022, GitHub @.***> wrote:

Hi, we're having the same problem with the 0.80 version on a newly
created project (no sources yet).
Link to a build scan: https://scans.gradle.com/s/u7kvzlq2bkwkg
One thing to note is that the project in which the measureProject task
fails differ randomly between hosts.
The plugin is applied and configured from the root project using the
new version catalog feature:
rootproject.gradle
plugins { alias(libs.plugins.dependencyAnalysisPlugin) } // ...
dependencyAnalysis { issues { all { onAny { severity('fail') //
default is 'warn' } } } }
Other plugins are applied using the conventions plugins created in
buildSrc.
 If you need anything apart of source code, ask away and we might be
able to reply.
 Thank you.

—
Reply to this email directly, view it on GitHub
<https://github.com/autonomousapps/dependency-analysis-android-gradle-
plugin/issues/386#issuecomment-1067859779>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/ABJG5PL3P2FH6RPHGMCHXRLVABWCBANCNFSM43VMC2OA>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-
email&mt=8&pt=524675> or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-
email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you modified the open/close state.Message
ID: <autonomousapps/dependency-analysis-android-gradle-
@.***>

Could you try the latest version?

Is it version v1.0.0-rc03?

Yes.
On March 17, 2022, GitHub @.***> wrote:

Could you try the latest version?

Is it version v1.0.0-rc03
<https://github.com/autonomousapps/dependency-analysis-android-gradle-
plugin/releases/tag/v1.0.0-rc03>?

—
Reply to this email directly, view it on GitHub
<https://github.com/autonomousapps/dependency-analysis-android-gradle-
plugin/issues/386#issuecomment-1070932361>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/ABJG5PKJMCZYIECX3PT6353VAMYHPANCNFSM43VMC2OA>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-
email&mt=8&pt=524675> or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-
email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you modified the open/close state.Message
ID: <autonomousapps/dependency-analysis-android-gradle-
@.***>

Yes.

Happy to report that v1.0.0-rc03 fixes our issue. Thank you!
Any ETA on the 1.0.0 release?

"When it's ready."
On March 21, 2022, GitHub @.***> wrote:

Yes.

Happy to report that v1.0.0-rc03 fixes our issue. Thank you!
 Any ETA on the 1.0.0 release?

—
Reply to this email directly, view it on GitHub
<https://github.com/autonomousapps/dependency-analysis-android-gradle-
plugin/issues/386#issuecomment-1073681852>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/ABJG5PMWYDI3DPVDAHQFRKDVBA7GHANCNFSM43VMC2OA>.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-
email&mt=8&pt=524675> or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-
email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you modified the open/close state.Message
ID: <autonomousapps/dependency-analysis-android-gradle-
@.***>


Exchange: support availabe spot values

The documentation says, that open, high, low, close, volume, price and last_traded is supported, but only close/price and volume was supported. I changed it now, but the documentation is still incorrect, because dt and data_frequency is not used. I think, the documentation just got copied from DataPortal::get_spot_value. I changed it, so I can use data.current for backtesting and live-trading.
I have not found tests for this, if I should write some, please let me know, where the appropriate place is.

Thanks @brandsimon for your contribution.
You are correct regarding the documentation and the unsupported fields and your code is indeed addresses it.
However, your PR has raised a bigger issue which we should address before fixing the code: what information should be available in the current (which in live mode calls the exchange get_spot_value function).
As you know, in live the current information is retrieved from the ticker received from the exchange, which returns statistics for some period of time in recent past, usually last 24 hours.
While in backtest, when requesting current, the statistics of the current date-time used by the simulation are returned (1 minute OHLCV in minute mode and 1 day OHLCV in daily mode). So both modes are not aligned, except in their price/close value. In addition to supporting spot price in live, the volume was added as well, although it might have caused more confusion (we were requested to align the backtest volume to 24H at #259). So I think we should decide on what is the best approach before updating the code:

Support only the price/close field at the current in both modes.
Support only the price/close field at the current in live and continue supporting all other fields at backtest.
Align the backtest mode to 24H and support all fields in both modes.
Align only the volume to 24H at backetest and continue supporting only price + volume at live.

@lenak25 Thank you for your response and explanation, I think I understand the underlying problem now (at least a bit better).
I dont think it is a good approach to support different fields in live and backtest mode, it is only confusing and I dont think, it is a good solution to have different code for backtest and live mode. So either solution 1 or 3 makes sense to me.
If I see it correctly, when I access the volume with current, in backtest mode I get the current volume (1T) and in live mode I get the 24hr volume. From the terminology "current", I would expect the current volume to be 1T (like I get the current price) and not the "history" volume.
Any thoughts on this?
Would it raise other problems (for example poloniex only provides 5T values)?

Please let me know, if I can help with something.


.m.rule.master has higher priority than user-added push rules

The spec claims:

Homeservers can specify "server-default rules" which operate at a lower priority than "user-defined rules".

However, unlike the other server-default override rules, the .m.rule.master rule actually applies at higher precedence than user-defined override rules. The spec doesn't mention this at all.

I'm kinda wondering if we should take the opportunity to make some other improvements here, rather than just documenting the current state of play. In particular:

perhaps the rule should be properly classified into a separate kind which works at an even higher priority than override and which clients aren't allowed to add new rules?
it would be nice to rename it to avoid the master/slave terminology. .m.rule.disable_notifications ?
Do we even need it to be specced? Would it be adequate for clients just to add a user-defined override rule when they want to disable push? It would require clients to use heuristics to spot such a rule so that they know if push has been disabled.

Unfortunately all of these ideas will break existing clients.

Another tweak could be to refuse to change the conditions on it, as right now a master rule which matches every event with action=notify seems possible


[CI] Cleanup errant workflows

@leecalcote should i delete some of these workflows ? my brain wouldn't let me rest if these red checkmarks are here
Originally posted by @s1ntaxe770r in https://github.com/layer5io/mesheryctl-smi-conformance-action/issues/2#issuecomment-831231311

have cleaned up most of them, should i delete release-drafter.yml as well? i don't think we'd be releasing anything for a while

No, please leave releasedrafter.yml and stale.yml, and config.yml.


Something I missed?

Attach (recommended) or Link to PDF file here: Sorry, private files. but it is good file with 200 status.

Configuration:

Web browser and its version: Google chrome 118.0.5993.117
Operating system and its version: pdf.js on ubuntu 22.04, visit it on Mac 13.4.1
PDF.js version:3.11.174
Is a browser extension:

Steps to reproduce the problem:

visit my website with ?file=xxxx
2.done, nothing happened

What is the expected behavior? (add screenshot)
load the pdf
What went wrong? (add screenshot)
pdf doesn't show
Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):https://pdf.zzqhmbb.eu.org/web/viewer.html

Overall, I can't load any file on it now. I am using the release package.

Attach (recommended) or Link to PDF file here: Sorry, private files. but it is good file with 200 status.

If you don't provide a full example, including the PDF document in question, it's unfortunately not possible to help you.

visit my website with ?file=xxxx

Again, you'll need to provide the full URL here in order for anyone to be able to assist.

The only guess would be that you're either running into the following checks, in which case you'll need to extend the HOSTED_VIEWER_ORIGINS list, https://github.com/mozilla/pdf.js/blob/fbfacf8828eddd0c458a330f162c5a3f7f5dc948/web/app.js#L2204-L2233 or it could possible a CORS issue https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq-xhr


Version 3.0.4?

I see the NuGet package is available in version 3.0.4 and it seems to be necessary to use it to make it work as of Feb 2024. But there is no tag in the source and no changes are documented. So is this package now closed source and undocumented? What code will I be using when installing the new package version? What kind of packaging process is this?

Are you running into any issues? The package is working as it is.

@fszlin I agree with @ygoe here, it does seems a bit spooky that there are no changes for many years in the repo, and then a new version pop up, I also would like to know where the code for those changes are?

Update: Yes, it works, as far as I can tell. But in the light of the recent supply chain attack with that compression library, some more transparency is needed here. Everybody should be able to build the library from the verifyable source code. If that's not possible, the library is no longer available as open-source.

@ygoe Exactly, that was a bit of wakeup call, and it is best to be cautious, this has been stale for so long, it makes trust a bit hard even with a comment from the author, which did not answer your questions at all!
Could you elaborate and show us the code for version 3.0.x @fszlin ?

The nuget package commit hash in the assembly info 3.0.4+Branch.release.Sha.ffa00c6061b49de17901df0cd997cc7531e1607e matches the github commit hash for the latest commit (currently):
https://nuget.info/packages/Certes/3.0.4
I think Eddie has been very gracious to supply this code for the community to use, so if in doubt build your own copy. Clearly he just uses it for work and doesn't have time to support a community of users. A lot of the problems users see using the package are a direct result of the users knowing very little about ACME, Certificate Chains, or Let's Encrypt, and that's a support job in itself.
We do have a fork over at https://github.com/webprofusion/anvil which is also available as a nuget package but likewise we don't really support it as a community project as it has experimental tweaks and changes specifically used in Certify The Web. We will however commercially support Certify The Web customers who also use that library.


I didn't receive my CCX from HeroMiners to web wallet

Hi!. I create this web wallet to receive the payments from mining pool.

but still don't seeing the funds in my balance

I'm doing anything wrong?

Can you try using the desktop wallet?
Just need to download here -> Desktop Wallet
Just export your keys from the web wallet and import them into the desktop wallet and let it sync which can take a few hours to a day's depending on your internet.
Let us know if it doesn't show up.

thread closed for inactivity


[internal review] Go: implement standalone custom command

Note:

the Rust code should essentially be ignored since it is not final and will be polished up in a separate review
this is only for internal review of the Go code, I won't open a PR upstream until the finalized Rust code has been merged upstream in a separate PR

Closing as this is superseded by another PR upstream (#1937)


Edit the text input for ships (setting provider node, recipient ship, etc.) to render as monospace font

Galen Feedback:

Since a provider node is always a ship, this should be a monospace input

This is a rule we try to adhere to in as many places as possible: whenever a ship is rendered on-screen, it should be in monospace


Implementation of Matthews Correlation Coefficient loss function

Hello,
I have implemented a mccloss function and updated losses.rst for that loss function. Please review these changes and  feel free to contact me if you have any questions related to it.

Looks good to go.