Scrolling jumps

After our discussion about the scrolling images stuttering here, I've been looking into it more (thanks for all the advice over there too), and I don't think what I'm experiencing is a pause/stutter from the images having to load anymore. It was that the images actually jump, sometimes a little, sometimes a lot, but always forward, i.e. up, ahead in time.
In image_set_scroll() I found this comment: # This seem to cause some scroll-jumps, not sure why, maybe wrong gtk event?, so could that have something to do with it?
It happens in exactly the same way regardless of whether it's using pixbuf_proc.so or not, however, so maybe not, since image_set_scroll() isn't called when pixbuf_proc.so is being used.
It even happens when only a single image is scrolling over and over, and it seems related to the image's dimensions in relation to the window's dimensions.
Say I start with an image with these dimensions: 500x375
Then, I keep decreasing the window's width until the scrolling starts to jump. In this case, it happened when the window dimensions became around 876x1034 pixels.
If I change the window's height to, say, 500 pixels, the jumping began when the window dimensions were 410x500.
At a height of 765 pixels: 635x765.
Next, say I use another image which has these dimensions: 500x750
Then, here's two example window dimensions for when the jumping begins to happen:
426x1024
281x674

Ah, right, don't think I've ever bothered testing resizing the window after app starts, as it's never been relevant to my "set it up to start with preset dimensions" (or typically full screen) use-case.
So I'd guess that some values calculated from window size do not get updated properly after initial start, breaking the scrolling math somewhat.
Simple fix might be just to make window non-resizable, but guess resizing can be useful for some other use-cases or in tiling layouts, where WM messes with window sizes constantly.

I've been looking into this, and I believe I've determined when it happens. In scroll_update(), when pos is calculated by 			pos += self.image_cycle(), if it's negative, then the jumping happens. The more negative, the bigger the jump.
So I've been trying to figure out how to fix this, but I'm having trouble following the code. Any hints? What needs to be done in the case pos is negative?

Hm, I just tried to reproduce the issue and seem to have failed:
https://e.var.nz/2020-11-27.image-scroller-test.mp4 (~17M, 2m26s)
("image-test-500x750.jpg" used there is https://e.var.nz/2020-11-27.image-scroller-test.image-test-500x750.jpg )
I can see some jitter when resizing the window, i.e. in an instant window goes from AxB -> MxN scrolling jumps a bit, do you mean that?
Some of jank on resizing is from WM here, as it only sends new dimensions to gtk occasionally, not on every pixel of change, and tries to scale/fit some stuff in-between these updates, and don't think I've accounted for an actual resizing moment at all.
As you didn't mention that it's only at the moment of resizing specifically, guess you meant that scrolling itself stutters, and don't think I can reproduce it here, unless I still don't know what exactly to look for, so maybe you can point out at which seconds/frames it happens in the linked video?
(barring some compression artifacts, any >2px jump should probably be visible with -r 60 there)

So I've been trying to figure out how to fix this, but I'm having trouble following the code. Any hints?

self.dim_* stuff there are helpers to get various dimensions used in scroll-time calculations.

dim_box_alloc gets pixel-length of the scrolled box, only part of which fits into window. It can be e.g. 23k pixels with 1080p resolution, and is either width or height depending on scroll direction.

dim_box_pack determines whether to add image at the top or at the bottom, used when adding them. Adding makes dim_box_alloc return larger value, as box with images expands. Removing image contracts it.

Scrolling up vs down (or left-vs-right) differs in that you have to either add or subtract offset, e.g. scroll position goes either 0-1-2-3-4-... or 23000-22999-22998-..., and dim_scroll_translate is intended to abstract this.
For both of these cases, it returns value with "0" for initial position that you can increment as 0-1-2-3-4-... without doing any if's and decrements on it - makes position into just an incrementing value, nothing more complicated.
To translate back to "real" window coordinates as GTK presents these, you just run same dim_scroll_translate on the adjusted value before passing it to GTK.
Under the hood, it leaves direct-scroll values as-is, while mirroring reverse-scroll around max position (23k in example above).

dim_scroll_for_image is used to get appropriate dimension for each image when it's added/removed to/from the scrolled box.
As images are added to the box at the scroll-direction end (e.g. bottom for scroll-to-bottom), images on the other end need to be removed, so that machine doesn't run out of CPU/RAM trying to juggle some huge 1-terrapixel-panorama.
When you add or remove stuff to existing window, GTK scroll can jump according to the size of addition/removal, unless it's on the bottom or right, so as images get added/removed as necessary for specified queue-size/preload-threshold parameters, image_cycle returns cumulative offset for scroll after additions/removals.
I.e. if it added 500x750px image, running dim_scroll_for_image will return e.g. 750 for it, and if it's scroll-to-the-top scenario, but something like -750 (+ box_spacing gap size between images) have to be returned because presumably GTK scrolls when adding content to keep window position already.
When scrolling to the bottom, removal of such image at the top should return -750.
Scrollbar itself expanding/contracting for changes on the right/bottom doesn't matter iirc, as offset in it is only counted from the left/top in pixels, and is absolute (same regardless of its size).
offset = -(offset if not self.dim_scroll_rev else offset_rev) line in image_cycle basically checks whether it's offset of additions or removals that is relevant for this scroll direction and returns appropriate value.
You can spot weird disconnect in the logic here - if "presumably GTK scrolls when adding content to keep window position already", then why do pos += self.image_cycle() and adj.set_value(self.dim_scroll_translate(pos, pos_max)) at all?
Don't actually know, but presumably in some cases it doesn't actually scroll, or scrolls incorrectly - maybe when window is brand-new with scroll-to-left and first image is added, it'd assume that you want left-side position and keep "skipping" all added images on the left by keeping that "0" position.

There's also special dim_scroll_for_pixbuf for getting same dimension value for pixbuf returned from .so lib, which is used with asynchronous image loading.
Iirc what happens there is that Image gets added to gtk window, same as with synchronous operation, but there's no way to know its dimensions without loading the image, and if it happens to be jillion-by-zillion px in size, or is loaded from some slow nfs/sshfs/whatever, that should not be done synchronously, so all images are loaded in the background too.
So after bg thread returns loaded and rescaled pixbuf, then that helper is used to get its dimension in the relevant direction, sets pixbuf for GTK Image widget, and adjusts scrolling accordingly, same as with dim_scroll_for_image above.

I think idea behind all these is to avoid having like 4 "if" cases in every single calculation for every scrolling direction, which might be how it was done somewhere in git history here, and was more confusing on the other level (had to think how to adjust everything 4x and with confusing different signs and flag checks for each case).

What needs to be done in the case pos is negative?

Certainly looks like a bug somewhere, as dim_scroll_translate should have it be monotonic from 0, and "0" should only happen in the very beginning of the scroll process, I think, otherwise position should stay somewhere in/near the middle of the box.
But if you have some weird queue size for images, or there's a bug somewhere to that effect, so that they get removed in scrolled-past direction immediately somehow, then I guess pos can get to 0, but it really should not - there should always be N images to scroll in either direction (again, except at the very start of the script).
I think #infinite-image-scroller, #infinite-image-scroller * { background: transparent; } line in ScrollerConf.win_css might be the one that makes scrollbar caret transparent, maybe try removing it to see how that "scroll position" works visually, where scrolling position stays and how/where it jumps.
Can also just put a bunch of print()'s all over the code and see if there's anything odd there, I guess.
But again, can't seem to reproduce the issue, so can't really do the same here, as it'll all be perfectly normal and expected values for me.
Maybe check that video above and tell me what you're doing differently from me there to trigger issue to happen.

Wow, thanks for all that info. I'll try to see if I can understand it later, but for now, here's a screencast of the jump happening, with debugging print()s I added. https://www.dailymotion.com/video/x7xr0hi  (Download link: https://ufile.io/12zfeuqh )
I think you might experience it if you make the window very narrow and tall, then leave it for long enough while the images scroll by.

Can you try same trick with e.g. --queue=10:0.6 parameter?

As you seem to have only one image above/below one being scrolled, so I think this should happen with an overly narrow window, as gtk scrolling position bumps into start/end of scrolled box as images get added/removed.
(also, feel like I'm suggesting this queue option for like a 3rd-5th time to you, maybe should just bump default value to avoid that kind of weirdness)

I think issue showcased in that screencast is best illustrated by this snapshot from it:

You have default value to "only load 3 images into a scrolled box" and you have all three visible in a window!
Given that this app works by adding images on one side of the scrolled box and removed on the other, there's just no way for it to work sanely if you have all images that it can possibly load already on display - of course added/removed images will be visible (and not off-screen) and cause whatever jumps and weirdness.
If you have 50 images in a window, -q/--queue should be at least 52 or maybe more like 70 in case some take a while to load, to avoid bottlenecking the scrolling, and with 3 on display, -q/--queue should be at least 5, and now-default 10 should suffice.
(there's also that second prefetch-threshold parameter, which should also influence that, and probably documented in the option description)

Yup, increasing conf.queue-size fixes it. Awesome! Defaulting to 10 should prevent the issue in just about all reasonable cases, but I got to thinking how to handle the edge case, like 50 images in the window all at once. LOL.
I came up with the following proof-of-concept that does work, though still isn't the right way to do it (see comment in code). In scroll_update():
			pos += self.image_cycle()
			if pos > 0:
				adj.set_value(self.dim_scroll_translate(pos, pos_max))
			elif pos < 0 and pos != (len(self.box_images) * -1):  # Hack to not increase queue_size before images are loaded (if it takes awhile, queue_size gets huge)
				self.conf.queue_size += 1

Eh, you might also want to be able to scroll stuff manually, and account for various processing and fs slowdowns, without increasing number of images there.
pos != (len(self.box_images) * -1) seem to be compating image count to pixels.
Also not sure if position going negative is a reliable indicator of window size being larger or close-enough to total width/height of images (depending on scroll direction) - I think with e.g. same-size images all displayed in a narrow window, it should stay at 0, and only go negative on size mismatch between removed and added image in that image_cycle func (in which way - depends on scroll direction too).
Seem to be too much complexity for an automatic solution to a rare issue which should be much easier to fix with a manual switch, which is there already.
I'm kinda surprised why you was so resistant to using it, given that narrowing the window, you can easily see how the whole thing works, with just 3 images being cycled there, and despite my repeated suggestions to use the damn option.

No, no, don't get me wrong. I'll definitely use the "damn option." Sorry. I'm just trying to be helpful since a case could arise where the scroller still jumps and users might not know to make the queue bigger. If it's not worth the trouble figuring out how to do it, though, no worries.
Just in case, though, to address why I compated image count to pixels, it's because I noticed that with three images, before they load, pos was -3. I think this has to do with pos being 1 for each in this case, and the code adds them together. Obviously the right way is to determine when they've loaded the right way, but I couldn't figure that out without looking into it more. Then, add to this the other possibilities you mention, like pos being negative not being a reliable indicator, and yeah, it's a harder problem than my simple solution warrants. Again, sorry if I seemed weird about it or something. Let me know if you don't appreciate my input, cuz I do have a few more things I wanted to tell you about.

No, no, don't get me wrong. I'll definitely use the "damn option." Sorry. I'm just trying to be helpful since a case could arise

Yeah, that's how I understood it as well.
Mentioned you there specifically as a real-world UX case where this manual approach seem to have failed, as I guess it's not apparent how the thing works and how to tweak it accordingly, but idk, maybe it's just you :)
Probably not worth worrying even this much about UI/UX design in this random weird ad-hoc script anyway.

I noticed that with three images, before they load, pos was -3

I think it might be an some bug where maybe between-image gap interval is subtracted from 0 or something like that.
But if it just happens on startup, probably not worth worrying about.

Let me know if you don't appreciate my input, cuz I do have a few more things I wanted to tell you about.

Nah, it's fine, it's not hard to fix stuff here, though dunno if I'm interested in actually improving the thing much - as far as I'm concerned it worked fine for rare use-cases I had for it, and not sure if I'll really need it again.
Though do use it occasionally to cover display when e.g. listening to something not far from the display to put something non-distracting on it so that I can't interact with it.

Cool.


fix: Stop calling ClientDisconnect on host

Fix #534

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add additional collected wisdom to README.md.

@robertlipe
since this pull request is 4 months old?  maybe  good idea to look it over and see if  it still  fits or needs edits?
I think if it's details instructions, Gamiee wants that on the  Wiki page here   https://github.com/pine64/blisp/wiki
For example,  there is a wiki page there just for Pinecil V2 ( that is where Gamie moved the detailed instructions I wrote).
Depending on how long the added notes are,  one way is to put a short sentence on Readme which links  it over to the blisp wiki page.
I think you have the power to just do it for this repo now.


adaptive cruise will be forcefully disengaged after 3 minutes of standstill on Toyota

Describe the bug
With openpilot's current standstill, ACC will be forcefully disengaged by the car after exactly 3 minutes if the front car doesn't move. In this situation, the car will be shifted to park. This is a potential problem for comma pedal users as comma pedal users tend to not move the cruise control lever when the car is stopped, if the front car doesn't move due to heavy traffic, the car will be shifted to P
How to reproduce or log data
Stop behind a completely stationary car in a Toyota hybrid vehicle, after 3 minutes with no movements, ACC will be forcefully disengaged and the car shifted to P.
Expected behavior
Enter the "Waiting" mode (seems to be related to CRUISE_CONTROL_STATE 11 in PCM_CRUISE_SM) instead of the current  "operate cruise lever or accelerator pedal to resume" mode.
openpilot issues a warning to let user take control before this occurs.
Device/Version information (please complete the following information):

Device: comma two
Dongle ID: 399b1cca765e80b4
Route: 399b1cca765e80b4|2020-12-09--11-54-59
Timestamp: the final disengagement in this route
Version: 0.8.1
Car make/model: Toyota Prius 2018

Additional context
With openpilot's standstill logic, the car's dash will immediately display a "operate cruise lever or accelerator pedal to resume" message upon entering standstill, while the stock system will display the "waiting" message and only display "operate cruise lever or accelerator pedal to resume" after the front car has moved, which doesn't seem to trigger this lock-out.
okay waiting triggers this as well, so I am thinking openpilot can issue a warning on the screen after about 2 and a half minute so the user can push the lever manually to avoid this.

TIL that if you sit with cruise control engaged in stand still traffic, eventually a 2017 Prius Prime will put itself in park. This causes OP to freak out and alarm.

https://discord.com/channels/469524606043160576/524327905937850394/761394246493929482
This has been documented before on the discord server.

Waiting mode is 7, mode 11 is a 3 seconds timer after which PCM enters mode 7.
Same will happen if you will wait too long in the mode 7 (Tested on Corolla Hybrid 2020).
What I've discovered for TSS2 models: OP don't need to send standstill request. Could be true for all Toyotas, need to check.
If you would like to participate in the tests - DM me on the discord.

Waiting mode is 7, mode 11 is a 3 seconds timer after which PCM enters mode 7.
Same will happen if you will wait too long in the mode 7 (Tested on Corolla Hybrid 2020).
What I've discovered for TSS2 models: OP don't need to send standstill request. Could be true for all Toyotas, need to check.
If you would like to participate in the tests - DM me on the discord.

Right, I've timed it, same will happen in waiting mode on stock.
However, op will not be able to restart with the SnG hack (at least on TSS-P) applied if the car doesn't roll forward.

Could you do one test? carcontroller.py try to comment out lines 92, 93 , reboot and try. Will it still go into P in 3 minutes?

Could you do one test? carcontroller.py try to comment out lines 92, 93 , reboot and try. Will it still go into P in 3 minutes?

No, but this is more or less expected since the car doesn't go into standstill

I'm not sure why I understand this is a problem. It sounds like this is all handled gracefully within the car, cruise is disabled and parking brake is engaged. Since openpilot's state is tied to the car's cruise state, it should handle this gracefully as well.

I feel like there should be an alert, as the user can prevent this from happening, with the current implementation of standstill, the user can press the resume button to get the car out of standstill mode.


Are Pretrained Models available?

This is a very interesting work. I am wondering if you can provide the weights of the trained models you evaluate in the paper (semantic segmentation task). Also it would also be nice to provide the code for training semantic segmentation models in shift dataset.

Hi @Eric-mingjie, great to hear that you enjoy our work!
We plan to release the trained models, however it will take some time to polish the code for training. I'll let you know as soon as we have a more clear idea on the expect time of release.


Improve instructions a bit for bash

Took me a while to understand why source wasn't working. It's because it doesn't export variables defined in a script into the environment by default. To do so, we need to use set -o allexport or set -a. Since I think some others might have the same issue, I updated the README a bit to include this command.

This shouldn't be necessary, testing in bash:
[nemo157@shao docs.rs]$ export | grep DOCSRS
[nemo157@shao docs.rs]$ . .env.sample
[nemo157@shao docs.rs]$ export | grep DOCSRS
declare -x DOCSRS_DATABASE_URL="postgresql://cratesfyi:password@localhost:15432"
declare -x DOCSRS_DOCKER_IMAGE="ghcr.io/rust-lang/crates-build-env/linux-micro"
declare -x DOCSRS_INCLUDE_DEFAULT_TARGETS="false"
declare -x DOCSRS_LOG="docs_rs=debug,rustwide=info"
declare -x DOCSRS_PREFIX="ignored/cratesfyi-prefix"
declare -x DOCSRS_TOOLCHAIN="nightly"

You may have an old .env file from before the sample had export added to make it actually export the variables into the environment.

I didn't even pay attention to that. Quite convenient! Closing then as unneeded.


Remove Throw methods from Assert

As we improved the Throw methods with #870, we should use them consistently. Therefore I would suggest to remove the Throw methods from the static Assert class, as they are redundant.

I think I'm happy to leave them to be honest. Some people will prefer the shorthand versions.

For me, it would be a benefit to have a consistent assertion API, where I can search for Assert.That and find all assertions in a code base. When there are shortcuts/alternatives for this, it gets harder to distinguish the normal pattern, especially as here the order of the exception type and the subject under test is different.
That was the main difficulty I had, when migrating a previous project from NUnit to xunit, that the order of the arguments was sometimes different.
And it is also not that much shorter 😄
await Assert.Throws<CustomException>(action);
// vs.
await Assert.That(action).Throws<CustomException>();

That's just my thoughts. In the end it is up to you, and I can close the PR...

Yeah let's close it for now. The API you desire is still there. And it might annoy some people if we remove this overload. If you don't wanna use it then you don't have to 😄


missing commit error in matlab

as soon as I installed it and make a right click to a seq file of the library in Matlab I get this weird error message which block the context menue

could be because we clone with depth 1, but thats weird...
what if delete the pulseq-cest-library folder, change line 29
sys_cmd = ['git clone --depth 1 https://github.com/kherz/pulseq-cest-library.git ' lib_path];
to
sys_cmd = ['git clone https://github.com/kherz/pulseq-cest-library.git ' lib_path];
and try it again


Make installer (setup)

Please make an installer (setup) like other apps.

After some consideration, I probably won't do this for the foreseeable feature. I don't see any big benefits, and the application already has all of its dependencies embedded. The background exe and all other data are stored in the AppData folders, so the only thing that would be in the application's folder would be just the editor executable.
Closing this issue for now until there are some general benefits for doing this.

Ok 👌


Bad quality result

For content

and style

the method gives bad quality result:

which look like a bug and not expected behaviour.
See result by https://github.com/sunshineatnoon/PytorchWCT:

I used the command: python main.py --content content.jpg --style style.jpg --outDir results/             --alpha 1.0.

i cant find the result pic ，，could u tell me how you deal with

After spending a lot of time and frustration I finally found the problem why bad results are given. The problems lies in the whitening and color transformation more specifically the way the means are added back to the colored feature map. The implementation is different in this repo and in PytorchWCT repo. Although it's been quite some time since the issue was raised hope it helps


Added SOS Django Template

SOS Django Template is an opinionated project template that separates development and production environments as well as provides dependencies enhancing your development cycle.

I've added to the list. Thanks for the PR!


Check for whitespace before a PHP open tag at start of file

_Issue Title
[New sniff] Check for whitespace before a PHP open tag at start of file
_Issue Content
Rule type:
Error
Rule:
Covered via:

Required: No PHP notices

Ref: https://make.wordpress.org/themes/handbook/review/required/explanations-and-examples/#code
There should be nothing (except possibly a hashbang) before the PHP open tag if it's the first real content in the file.
This can prevent "headers already send" PHP notices.
This is loosely related to the check for BOM-marks at the start of files. (#5)
Theme check file covering this rule:
Not checked.
Notes for implementation:
This was discussed in the video chat earlier today with an eye on adding the Generic.PHP.CharacterBeforePHPOpenTag sniff to the ruleset.
On closer review of that sniff, it demands that all PHP files start with a PHP open tag. This would cause issues with themes using views without a file docblock at the top, so the upstream sniff can not be used.
The sniff needed here would need to check that there is no inline HTML before the first PHP open tag to prevent these issues.
As this means that a custom sniff is needed, I'd like to point out that this sniff could be useful for more than just themes, so it should be pulled to WPCS and once it has been merged there, the sniff should be included into TRTCS via the ruleset.
To do:

[x] Create unit tests
[x] Create new sniff and pull it to WPCS
[ ] Once merged upstream, add the new sniff to the ruleset.

Update: I've closed the PR to WPCS as it turns out that this is already checked for by another sniff included in WPCS. This is an upstream PHPCS native sniff which can be included here too.
Note: the upstream sniff does not handle unicode whitespace preceeding the PHP open tag, but that should be fixed upstream and is being discussed there.


standardize results file names

Use Case
right now if we run pack with a config file that has save_analyze_result turned on the file names start with results_seed_0...
but if we run without save_analyze_result then the file names are different
Solution
no matter what the files names should include

recipe name
recipe version
config file name
seed number

Alternatives
Please describe any alternatives you've considered, even if you've dismissed them

The Analysis function can run multiple seeds simultaneously in parallel, and adds the seed_  prefix to the name of the result file on line 2216 of Analysis.py. We can check whether more than one seed is being packed before adding this prefix.
Here is the line that adds this:
seed_basename = f"seed_{seed_index}_{packing_basename}"

save_as_simularium takes in an input for the result_file_path. We also pass in the env which has its own env.result_file. We should keep these consistent with one another.


Swift 3.2 or Swift 4.0 Support

Hello,
Are there any plans to support Swift 3.2 or Swift 4.0?  I did a quick test upgrade and found the changes to NSAttributedString seems to have an impact.  Have you or anyone else had any luck upgrading?

Branch master and develop is migrated to Swift 4.


Update logging to give correct line/file/func numbers

fixes #376. I haven't been able to test this because I haven't been able to get a suitable build environment for TransformerEngine, so plausibly this doesn't work.

closing because #382 is much better


brew postinstall<EMAIL_ADDRESS>fail

brew config output
HOMEBREW_VERSION: 3.0.1
ORIGIN: https://github.com/Homebrew/brew
HEAD: c951be8d3c7b339c7e759b7c40aec859e09a70a5
Last commit: 10 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 4e2330d834fde71bf7a33835ee8e872f1545d7aa
Core tap last commit: 6 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.3 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 12.0 build 1200
Git: 2.30.1 => /opt/homebrew/bin/git
Curl: 7.64.1 => /usr/bin/curl
macOS: 11.2.1-arm64
CLT: <IP_ADDRESS>.1.1610135815
Xcode: 12.4
Rosetta 2: false
brew doctor output
❯ brew doctor
Your system is ready to brew.

[X] The brew doctor above contains no "Warning" lines.

What were you trying to do (and why)?
brew install python
What happened (include all command output)?
❯   brew reinstall<EMAIL_ADDRESS>==> Downloading https://homebrew.bintray.com/bottles/python%403.9-3.9.2.arm64_big_sur.bottle.tar.gz
Already downloaded<EMAIL_ADDRESS>==> Reinstalling<EMAIL_ADDRESS>==> Pouring<EMAIL_ADDRESS>==><EMAIL_ADDRESS>-m ensurepip
Last 15 lines from<EMAIL_ADDRESS>File<EMAIL_ADDRESS>line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File<EMAIL_ADDRESS>line 87, in _run_code
exec(code, run_globals)
File<EMAIL_ADDRESS>line 5, in
sys.exit(ensurepip._main())
File<EMAIL_ADDRESS>line 210, in _main
return _bootstrap(
File<EMAIL_ADDRESS>line 129, in _bootstrap
return _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
File<EMAIL_ADDRESS>line 38, in _run_pip
return subprocess.run([sys.executable, "-c", code], check=True).returncode
File<EMAIL_ADDRESS>line 528, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command<EMAIL_ADDRESS>'-c', '\nimport runpy\nimport sys\nsys.path = ['/private/tmp/tmp5z61f7c3/setuptools-49.2.1-py3-none-any.whl', '/private/tmp/tmp5z61f7c3/pip-20.2.3-py2.py3-none-any.whl'] + sys.path\nsys.argv[1:] = ['install', '--no-cache-dir', '--no-index', '--find-links', '/private/tmp/tmp5z61f7c3', 'setuptools', 'pip']\nrunpy.run_module("pip", run_name="main", alter_sys=True)\n']' died with <Signals.SIGKILL: 9>.
Warning: The post-install step did not complete successfully
You can try again using:
brew postinstall<EMAIL_ADDRESS>==> Caveats
Python has been installed as
/opt/homebrew/bin/python3
Unversioned symlinks python, python-config, pip etc. pointing to
python3, python3-config, pip3 etc., respectively, have been installed into
<EMAIL_ADDRESS>You can install Python packages with
pip3 install
They will install into the site-package directory
/opt/homebrew/lib/python3.9/site-packages
See: https://docs.brew.sh/Homebrew-and-Python
==> Summary
🍺<EMAIL_ADDRESS>3,779 files, 64.6MB
What did you expect to happen?
brew install python
Step-by-step reproduction instructions (by running brew commands)
brew install python

brew postinstall<EMAIL_ADDRESS>❯   brew postinstall<EMAIL_ADDRESS>==> Postinstalling<EMAIL_ADDRESS>==><EMAIL_ADDRESS>-m ensurepip
Last 15 lines from<EMAIL_ADDRESS>  File<EMAIL_ADDRESS>line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File<EMAIL_ADDRESS>line 87, in _run_code
    exec(code, run_globals)
  File<EMAIL_ADDRESS>line 5, in <module>
    sys.exit(ensurepip._main())
  File<EMAIL_ADDRESS>line 210, in _main
    return _bootstrap(
  File<EMAIL_ADDRESS>line 129, in _bootstrap
    return _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File<EMAIL_ADDRESS>line 38, in _run_pip
    return subprocess.run([sys.executable, "-c", code], check=True).returncode
  File<EMAIL_ADDRESS>line 528, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command<EMAIL_ADDRESS>'-c', '\nimport runpy\nimport sys\nsys.path = [\'/private/tmp/tmp6lwwo77b/setuptools-49.2.1-py3-none-any.whl\', \'/private/tmp/tmp6lwwo77b/pip-20.2.3-py2.py3-none-any.whl\'] + sys.path\nsys.argv[1:] = [\'install\', \'--no-cache-dir\', \'--no-index\', \'--find-links\', \'/private/tmp/tmp6lwwo77b\', \'setuptools\', \'pip\']\nrunpy.run_module("pip", run_name="__main__", alter_sys=True)\n']' died with <Signals.SIGKILL: 9>.
Warning: The post-install step did not complete successfully
You can try again using:
  brew postinstall<EMAIL_ADDRESS>

died with <Signals.SIGKILL: 9>.

I still have the same problem. Does anyone have a solution yet ? Would be great :)

@hriekehof reinstall homebrew for me

ran into the same issue. i remembered seeing some errors about codesigning a couple days ago when updating python and sure enough in console.app i'm finding these python crashlogs:
Process:               Python [55807]
Path:                  /opt/homebrew/*/Python.framework/Versions/3.9/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.9.2 (3.9.2)
Code Type:             ARM-64 (Native)
...
Termination Reason:    Namespace CODESIGNING, Code 0x2

over in this issue https://github.com/Homebrew/brew/issues/10554 i found some helpful commands that fixed it for me. I ran:
brew reinstall $(brew deps<EMAIL_ADDRESS>brew reinstall<EMAIL_ADDRESS>

I'm having this issue as well.

Same here.

Likewise, reinstalling<EMAIL_ADDRESS>and its dependencies fixes the problem, and also allows google-cloud-sdk to be installed.


fix(chat): not allow dots in the end of name (Issue #1003)

Description:
not allow dots in the end of name
Issues:

Issue #1003

UI changes

Checklist:

[x] the pull request name complies with Conventional Commits
[x] the pull request name starts with fix(<scope>):, feat(<scope>):, feature(<scope>):, chore(<scope>):, hotfix(<scope>): or e2e(<scope>):. If contains breaking changes then the pull request name must start with fix(<scope>)!:, feat(<scope>)!:, feature(<scope>)!:, chore(<scope>)!:, hotfix(<scope>)!: or e2e(<scope>)!: where <scope> is name of affected project: chat, chat-e2e, overlay, shared, sandbox-overlay, etc.
[x] the pull request name ends with (Issue #<TICKET_ID>) (comma-separated list of issues)
[x] I confirm that do not share any confidential information like API keys or any other secrets and private URLs

/deploy-review


Enable functional tests to have a descriptive name

What would you like to be added:
Allow a descriptive name to be associated with each functional test which can be printed during testing.
Why is this needed:
Enable more meaningful output during functional testing to make it easier to determine exactly what is being tested.
Documentation update:
Once this is implemented and descriptive names are set for each test the Test Samples Available table can be removed from readme.md

Ideas:

Add a specific annotation to each manifest to be applied. Functional test framework looks for this annotation during testing and prints the value of the annotation.
Add a description field to the functional-test.yaml for each manifest that can be printed during testing.


toc resizing issues / unique anchors in headings

I have closed #483 and redo/compete it:

toc resizing issues: the commit fixes some issues when resizing the toc window:

the text did not resized as the window and overflowed
there was no possible scrolling Now the text is reflowed according to the dimensions of the new window, overflow is avoided and a scroll bar appears when needed.

create unique anchors in headings and update links in tocs. This tries to address the longstanding issue https://github.com/jupyter/notebook/issues/77 pointed out by @JanSchulz. Hope it will help...

The commit adds current toc number to headings anchors. This enables to get unique anchors for recurring headings with the same text. This is not perfect since external links may fail if toc changes (eg headings are added/removed). Anyway, one can always add an anchor  in the heading and refer to that anchor, eg [link](#myanchor).  This anchor is automatically removed when building toc links.

Just edited the last sentence in the presentation, where the html was interpreted, and thus the axample was difficult to understatnt. Please read it as
"This is not perfect since external links may fail if toc changes (eg headings are added/removed). Anyway, one can always add an anchor  in the heading and refer to that anchor, eg [link](#myanchor).  This anchor is automatically removed when building toc links.  "

@jfbercher Wow, thank you!  Do you have an amazon wishlist? :-)

Commit "	Add anchors to original IDs" :
The original ID is also preserved and an anchor is created to refer to it and can be used (but toc uses the new IDS!). It is thus possible to link to the heading line using both the old style (but ids may not be unique) or the new style.
Finally it is possible to link to a heading line by:  [link](#initialID), or [link](#initialID-tocnumber) or [link](#myanchor) [if one defines his own anchor]

Not sure if this is related to the new ID generation:
# Heading Name creates a TOC entry
# Heading/Name not
# Heading:Name not

Thanks. Good tests.
Indeed, this was related....
These special characters still caused a problem when checking for the existence of new ids (before creating them). I have now escaped all special characters in my keyboard (and "normal" extended characters work), so it should work now

This fixes it. Looks good now!
I wonder, should we remove the old toc extension to avoid confusion. This one is now much better.

I wonder, should we remove the old toc extension to avoid confusion. This one is now much better.

yes please :-)

OK. Let's merge the changes for toc2 and remove old toc.

OK, nice :-)
Perhaps should we edit the docs in toc2 and rename it as toc?

Will there be confusion with minrk's original extension ?

Yes, you are right.
Let's keep it as toc2.
On Thu, Feb 25, 2016 at 7:16 PM, Juergen Hasch<EMAIL_ADDRESS>wrote:

Will there be confusion with minrk's original extension ?
—
Reply to this email directly or view it on GitHub
https://github.com/ipython-contrib/IPython-notebook-extensions/pull/488#issuecomment-188914879
.

Do you think the name on the disc matters?

No sure if this is something this started, but I notice that the execution of an md cell now has a noticeable delay. Is there any way to do the regeneration of the toc in the background?

@JanSchulz perhaps try a setTimeout in the event rendered.MarkdownCell callbacks registered in nbextensions/usability/toc2/main.js#L434-L444?

@jcb91 I change it to
    $([IPython.events]).on("notebook_loaded.Notebook", function(){ // curiously, the event is not always fired or detected
                                                       // thus I rely on kernel_ready.Kernel to read the initial config
                                                       // and render the first  table of contents
            read_config();
        table_of_contents();
        // render toc for each markdown cell modification
        //$([IPython.events]).on("rendered.MarkdownCell", table_of_contents);
        $([IPython.events]).on("rendered.MarkdownCell", function(){setTimeout(table_of_contents,100)});
            console.log("toc2 initialized (via notebook_loaded)")
        extension_initialized=true  ; // flag to indicate that initialization was done
})

    $([IPython.events]).on("kernel_ready.Kernel", function(){
        if (!extension_initialized){
            read_config();
            table_of_contents();
            // render toc for each markdown cell modification
            $([IPython.events]).on("rendered.MarkdownCell", function(){setTimeout(table_of_contents, 100)});
            console.log("toc2 initialized (via kernel_ready)")
        }

and it seems to be faster. Is that the way you wanted it?

As far as I am concern, I do not noticed any delay introduced by the last modifications and indeed these add a very small amount of new calculations.
I have some big notebooks with big tocs and I have no problems with them.
There are much more consuming oerations that happens when you render a md cell, eg the rendering itself, mathjax, what happens in latex_envs, in highlighter, etc. Furthermore, javascript is asynchronous and is able to process several things together.
I can certainly be wrong, but I don't think that the processing delay you notice is due to the last modifications in toc, or to toc itself. These kind of delays may happen when there are lot of things that are written in cell outputs (and that may behidden), eg javascript code or html via display. You should inspect your notebook, the extensions you use, perhaps copy cells to another nb.
Anyway, if delaying toc computation by 0.1s does something noticeable, we could implement it! I have absolutely no opposition to that. But it would be nice to better understand from where comes the problem.

@jfbercher How would you debug that? Up to now I haven't done any profiling in the browser :-(

@JanSchulz Can you create a repo, eg "toc_test",  in your github account and upload an example of notebook with this slow rendering problem? I would like to check with one of your files since I do not have  this feeling myself.

@jfbercher Ok, I tried to recreate it by removing the timepout but now I can't: it's fast even when I use the old code (as seen in code inspect in chrome). I've no idea why this happend or why it went away when I used the timeout.
Sorry for the noise :-(


mam2: receiver context need to have access to all PSKs

mam_recv_msg_context_t currently holds a single PSK.
It needs to hold a map <psk_id,  psk> and select the right one depending on the psk_id parsed from a message.

Fixed by #830


Bundler/OrderedGems doesn't consider dash over underscores

Expected behavior
I would expect the following gems to be sorted as follows (emphasis on dash preceding underscore):
gem "devise-security"
gem "devise_invitable"

Actual behavior
When Rubocop auto-corrects, the following happens instead:
gem "devise_invitable"
gem "devise-security"

Steps to reproduce the problem
Save the following in a Gemfile file locally:
# frozen_string_literal: true

source "https://rubygems.org"

gem "devise-security"
gem "devise_invitable"

Now run rubocop --auto-correct Gemfile and notice the gems getting switched.
RuboCop version
$ [bundle exec] rubocop -V
0.92.0 (using Parser <IP_ADDRESS>, rubocop-ast 0.7.1, running on ruby 2.7.1 x86_64-darwin19)

You probably want to enable ConsiderPunctuation for Bundler/OrderedGems. Otherwise, dashes and underscores are both removed for the purpose of sorting.

Indeed. More details in #8209
Closing, but let us know if that doesn't resolve your issue 👍

:bow: @dvandersluis and @marcandre. Yep, that fixed it! I had tried experimenting with ConsiderPunctuation yesterday but must have had a typo or didn't properly load my configuration. Anyway, this is what I was looking for.


Fix cloud-init blocking on WSL1

cloud-init status --wait blocks forever if cloud-init won't ever start. Known cases where that may happen:

the cloud-init systemd units being masked or disabled by default in the rootfs (not our case)
systemd not enabled by default in the rootfs image (not our case either)
the distro instance being registered as a WSL 1 instance (we don't control that :) )

We're not considering that properly. With the patch https://github.com/ubuntu/WSL/pull/508/commits/bb7265201cb521ec23a636e4d7f221376880eb4c, we check if both the cloud-init.service unit is enabled (which covers 1) as well as systemd not offline, which covers 2. and 3.
The very same check was implemented in the new script that will replace this launch in the new WSL format via this PR: https://github.com/ubuntu/wsl-setup/pull/17.
I also added an end-to-end test case that sets WSL1 as the default setting globally and attempts to register the instance. Without that patch the test would timeout. See https://github.com/ubuntu/WSL/pull/508/commits/472a2d8d65db263385bd69c79f2bdfeef0ed8b5c.
UDENG-5629.

CI had two issues blocking me:

releases-info, a Go binary used to select which rootfses to build the application packages from, had outdated considerations about what CPC publishes under https://cloud-images.ubuntu.com/wsl:

Jammy file naming conventions are now the same as Noble's.
The CPC publisher no longer strips the "ubuntu" suffix on both releases.

Look at https://cloud-images.ubuntu.com/wsl/jammy/current/:
...
[   ] SHA256SUMS.gpg                                      2024-12-13 15:01  833
[   ] ubuntu-jammy-wsl-amd64-ubuntu.rootfs.tar.gz         2024-12-12 21:42  324M  File system image and Kernel packed
[   ] ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz 2024-12-12 21:42  324M  File system image and Kernel packed
[TXT] ubuntu-jammy-wsl-amd64-wsl.manifest                 2024-12-12 21:42   17K  Package manifest file
[   ] ubuntu-jammy-wsl-arm64-ubuntu.rootfs.tar.gz         2024-12-12 21:45  308M  File system image and Kernel packed
[   ] ubuntu-jammy-wsl-arm64-ubuntu22.04lts.rootfs.tar.gz 2024-12-12 21:45  308M  File system image and Kernel packed
[TXT] ubuntu-jammy-wsl-arm64-wsl.manifest                 2024-12-12 21:45   17K  Package manifest file
...

The images contain a suffix "ubuntu22.04lts".
Also, that naming convention used to be from 24.04 onwards.
But as we can clearly see 22.04 and 24.04 are following the same naming convention
(see https://cloud-images.ubuntu.com/wsl/noble/current/):
[   ] SHA256SUMS.gpg                                      2024-12-13 05:37  833
[   ] ubuntu-noble-wsl-amd64-ubuntu.rootfs.tar.gz         2024-12-12 20:21  347M  File system image and Kernel packed
[   ] ubuntu-noble-wsl-amd64-ubuntu24.04lts.rootfs.tar.gz 2024-12-12 20:21  347M  File system image and Kernel packed
[TXT] ubuntu-noble-wsl-amd64-wsl.manifest                 2024-12-12 20:20   16K  Package manifest file
[   ] ubuntu-noble-wsl-arm64-ubuntu.rootfs.tar.gz         2024-12-12 20:23  332M  File system image and Kernel packed
[   ] ubuntu-noble-wsl-arm64-ubuntu24.04lts.rootfs.tar.gz 2024-12-12 20:23  332M  File system image and Kernel packed
[TXT] ubuntu-noble-wsl-arm64-wsl.manifest                 2024-12-12 20:23   16K  Package manifest file

Every now and then the PowerShell script that downloads the rootfs and validate the checksums failed with a shallow stack trace of an attempt to index into a null array.
That was not really helpful. After investing some time on this I could finally learn that we implemented the wrong regex pattern (two spaces instead of a space and a raw star/asterisk character).

That was weird:

The self-hosted runner: wsl-ci lost communication with the server. Verify the machine is running and has a healthy network connection. Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access can cause this error. Source

The VM was crashing. There are quite a few events like the one below that happened yesterday and today.

I resized it to the second VM size compatible with GitHub large Windows runners (which are available by default now for open source projects) so that, if we were to migrate this out of our self-hosted runners we wouldn't be surprised with a downgrade. I then resized to the first size, as the change didn't solve the crash. That seems outside of our control. Even with more powerfull specs than my laptop, the crash still happened in the VM but didn't in my computer.
I'll turn the WSL1 test case off for now and park a card to investigate this later.


GetSSSR function does not locate "big" rings in cucurbituril-like systems

If molecule is a ring of condensed rings, e.g. cucurbituril ("barrel"), when Chem.GetSSSR function locates only "small" cycles forming barrel's walls, and ignores a "big" one corresponding to one of barrel's caps:
from rdkit import Chem
# smiles copied from https://pubchem.ncbi.nlm.nih.gov/compound/Cucurbituril#section=Canonical-SMILES&fullscreen=true
mol = Chem.MolFromSmiles('C1N2C3C4N(C2=O)CN5C6C7N(C5=O)CN8C9C2N(C8=O)CN5C8C%10N(C5=O)CN5C%11C%12N(C5=O)CN5C%13C(N1C5=O)N1CN3C(=O)N4CN6C(=O)N7CN9C(=O)N2CN8C(=O)N%10CN%11C(=O)N%12CN%13C1=O')
mol

from collections import Counter
Counter([len(r) for r in Chem.GetSSSR(mol)])
# output: Counter({5: 12, 8: 6})

We expect Chem.GetSSSR to return an additional ring containing at least 24 atoms, which corresponds to one of the "barrel" caps. This is in line with the fact that cucurbituril contains 19 cycles, which can be verified via degree of unsaturation: for cucurbituril[6], it's equal to 31, which corresponds to 12 C=O double bonds, 18 "small" cycles, and a missing "big" one.
Configuration:

RDKit version: 2023.03.3
OS: Windows 11
Python version (if relevant): 3.10.12
If you are not using conda: how did you install the RDKit? via PyPI

I can confirm that this is a real bug. @IvanChernyshov is right about the fundamental algebraic definition of n SSSR. (I think the missing ring is 30-membered though).

Here's a simplified SMILES that showcase the same problem, but might be a little easier to debug:
`mol = Chem.MolFromSmiles('C(C1C2CC3C4CC56)C6C6C1C1C(C7)C2C3C7C(C2)C4C5C2C6C1')
mol

Counter([len(r) for r in GetSSSR(mol)])
Counter({5: 6, 6: 3}) # Counter({5: 6, 6: 3, 9: 1}) expected


Adding CloudStation as a Supporter for OpenWhisk

Congrats on the launch 🎉

@broerse Thanks so much!

@rabbah @mrutkows Thanks. Talk about it from the Meetup in Amsterdam: https://www.youtube.com/watch?v=DAluXhuKvPE&feature=youtu.be


[vue-tsc] Type error for component after updating to 1.4

Repro: https://stackblitz.com/edit/vitejs-vite-xv9dk6?file=src/App.vue
Given
<script setup lang="ts">
import { h } from 'vue';

const test = () => {
  return h('p', {}, 'test');
};
</script>

<template>
  <test />
</template>

Build of this fails with
src/App.vue:10:4 - error TS2554: Expected 0 arguments, but got 1.
10   <test />
      ~~~~

This used to work in 1.3.
While this can be alleviated by giving const test a param, I don't know if this is supposed to be erroring here in the first place.

I also have  the same problem


Use of absolute string path breaks generateSources task remote cacheability

Summary
Input property rootFolders is referenced as an absolute path string .
If you use a gradle remote cache absolute paths may differ based on the machine used for the build.
Description
I believe we could change this to a ConfigurableFileCollection similar to graphqlFiles fix the issue
Version
1.4.5, but pretty sure this is still on master.

Good catch, thank! The reason rootFolders is a ListProperty<String> and not a List<DirectoryProperty> is that, in theory at least, the src/main/graphql folder can contain something else that .graphql files and we want the task to stay UP-TO-DATE even if an unrelated file changes.
This PR changes the paths so they are relative and the task can be relocable


After adding the configuration file, you will need to remove and reinstall puppeteer for it to take effect.

Guys, we are in XXI century. There is a thing called lazy loading. Its super useful thing and its a breeze to implement.

Could you clarify which parts of the config are not taken into effect? if you mean the installation location, the installation only happens on npm i in npm scripts. Otherwise, the installation location lookup or any other configuration does not require installation. Note that if Puppeteer is already installed, npm might choose not to re-run install scripts.

Well, thanks for the feedback. We don't plan on writing config files for the users as the config is completely optional for installing Puppeteer. We are working on a CLI for browser download which would decouple npm i from the browser download.


chore: remove snippet leading whitespace

The system test failure looks like it might just be a flaky test that should be linked to that tracking issue (will do in a sec). The docs failure I'm getting in my unrelated PR also. It seems like we might've changed something lately that broke this, but I don't know why it wouldn't have shown up in the PR for that change.


Install fails with build error.

gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/mnt/c/Users/Dave/Documents/Projects/testing/node_modules/node-gyp/lib
/build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:310:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR!  Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>postinstall script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/dave/.npm/_logs/2020-04-19T02_44_09_878Z-debug.log
ERROR
Command failed with exit code 1: npm install
Error: Command failed with exit code 1: npm install
2020-04-19T02_44_09_878Z-debug.log

Any resolution on this? experiencing the same...


Using LTS NVR with pyHik

I'm running HA 0.39.3.
LTS (Hikvision) CMIP3022W IP camera - working great.
LTS (Hikvision) LTN8716T-HT NVR errors with 'Problem finding attribute: list index out of range' error.

I'm attaching the device trigger file you posted over on the HASS forum here so I can easily find it later.
dvr_triggers.txt

No events found if using existing code.  Changed to:
ettype = eventtrigger.find('{http://www.std-cgi.com/ver20/XMLSchema}eventType')
This worked, but many duplicates due to multiple ports (like 16 iterations of VMD).
Perhaps  value is unique (like VMD-1, VMD-2, etc.)

I've finished the changes on my other library so I should have some time to tackle this now.  Also recently got access to a hikvision NVR I can use for testing.  I'll make a Dev branch for the changes and post back here when I have something ready for you to test.

Could you post a sample from your NVR alert stream?  The following command will retrieve it with curl and send the output to a file.
curl -u USER:PASS http://YOUR-NVR-IP/ISAPI/Event/notification/alertStream > stream.txt

I'm seeing some variations in naming between the test NVR I have access to and the triggers XML sample you provided earlier so I want to make sure I cover all the variations.

I'm sure you wish the naming conventions were a little more standardized.
This NVR is a hybrid with 16 analog inputs plus 16 IP camera inputs. It also has IO inputs.
Included several incidents - IO alarm event, videoloss event, motion detection event, and line crossing event.
stream.txt

Are the IO inputs a priority for you?  They are reported a little differently in the event triggers list so they may not be included in the first NVR revision.
Your stream also shows some slightly different behavior in terms of the the 'videoloss' event that's continually posted to channel 0.  Some adjustments might be needed to the watchdog to keep things working smoothly, but we can get that all figured out once we get to the testing phase.

IO not a priority. I will be using this to trigger camera notifications.

I've gotten things to a point where they seem to be working reliably with my test NVR so it's time to see if you can break it. :)
I think the easiest way to test it out is download the "nvr" branch of pyhik from github and copy the pyhik folder to your hass "deps" directory.
https://github.com/mezz64/pyHik/tree/nvr
Then grab the updated hass hikvision binary sensor component from the commit linked below and place it in the following folder tree in your hass config directory: custom_components/binary_senors/.  Once it's there comment out the REQUIREMENTS line at the top of the file so HASS just looks in the deps directory rather than trying to use the currently non-existent 0.1.1 version.
https://github.com/mezz64/home-assistant/blob/8b31311ae83283d9341e5cdb0574d1d168104aa0/homeassistant/components/binary_sensor/hikvision.py
Let me know if you encounter any issues.

Use this hass commit.  I made some changes to keep sensor names the same for existing users.
https://github.com/mezz64/home-assistant/blob/6e86886120e5e9cd80dbf0aeda9418df2885567f/homeassistant/components/binary_sensor/hikvision.py

See attached. Adding debug logger did not increase error logging. Using curl to the eventStream still works. Changing login password to the NVR gives a different error message.
error_1.txt

Make sure you have the following logging definitions in your hass config to get debug logs:
pyhik: debug
custom_components.binary_sensor.hikvision: debug

Once those are defined start things up again and post the full log.

Noted the constants file was using the hikvision style - changed to std-cgi.
Attached error.
error_2.txt

No need to change the constants.py for the namespace.  It gets updated dynamically during setup.  Based on that log it looks like your are still using the last release version of pyHik, not the one from the nvr branch.
Can you double check that you commented out the requirements line in the hass hikvision binary sensor file and that the you have a pyhik folder in your custom_components directory that contains the pyhik files __init__.py, constants.py, hikvision.py, watchdog.py?

Requirements line in binary_sensor/hikvision.py has been removed.
The pyhik folder was in loaded into deps.
Copied pyhik folder into custom_components folder.
Same errors.

Directories should be as follows:
custom_components/binary_sensor/hikvision.py  *This should be the file from the commit linked above with REQUIREMENTS commented out.
deps/pyhik/**pyhik library files** *These should be from the nvr branch of this repo.
If that's how you have it setup then something isn't working right in hass in terms of order of imports.  What version of hass are you testing with?

HA v0.40.2.
Redropped the pyhik folder into deps folder.
More info now in the error file.
error_3.txt

Ok, we are making progress. 👍
Your logs show you are utilizing the new pyhik library, but not the new hikvision.py hass component.  If for some reason you can't get it to load from the config/custom_components directory you can always overwrite the existing file in the components/binary_sensor directory also.

Overwrote existing hikvision.py in components/binary_sensor folder.
Looks better now.
See attached.
error_4.txt

I think I fixed your error with the latest commit to the nvr branch.  Please download and replace the files in your deps directory and give it another shot.

Yep - that looks like it.
Both Line Detection and motion are working on various inputs, both analog and digital.
No errors - excellent work.
error_5.txt

Awesome. Glad it's working for you. I'll wait a day or so to merge into master and submit a PR to hass just in case something pops up after you use it for a while.

Closing this now... Version 0.1.1 with NVR support has been pushed to pypi.  PR to integrate with hass is submitted.


further increase target area of scrubber

18px height -> 32px height.
still too finicky on touchscreens for my fingers + passes WCAG 2.2 AA now 👍🏼

Merged a tweaked version, thank you!


Feature: trying to enforce a specific order within custom groups leads to complicated config

What rule do you want to change?
sort-classes
Describe the problem
I'm using perfectionist/sort-classes as a replacement for react/sort-comp which is autofixable, but I'm also trying to follow Airbnb's class order, which leads to a very verbose config for the rule...

Code example

{
	type: 'natural',
	ignoreCase: false,
	groups: [
		'static-property',
		'static-method',
		'property',

		// React properties
		'displayName',
		'propTypes',
		'contextTypes',
		'childContextTypes',
		'mixins',
		'statics',
		'defaultProps',

		'constructor',

		// React lifecycle methods
		'getDefaultProps',
		'getInitialState',
		'state',
		'getChildContext',
		'getDerivedStateFromProps',
		'componentWillMount',
		'UNSAFE_componentWillMount',
		'componentDidMount',
		'componentWillReceiveProps',
		'UNSAFE_componentWillReceiveProps',
		'shouldComponentUpdate',
		'componentWillUpdate',
		'UNSAFE_componentWillUpdate',
		'getSnapshotBeforeUpdate',
		'componentDidUpdate',
		'componentDidCatch',
		'componentWillUnmount',

		'handlers',
		'callbacks',
		['get-method', 'set-method'],
		'get-set-methods',
		'method',
		'unknown',
		'render-methods',
		'main-render',
	],
	customGroups: [
		// React properties.
		{
			groupName: 'displayName',
			elementNamePattern: 'displayName',
		},
		{
			groupName: 'propTypes',
			elementNamePattern: 'propTypes',
		},
		{
			groupName: 'contextTypes',
			elementNamePattern: 'contextTypes',
		},
		{
			groupName: 'childContextTypes',
			elementNamePattern: 'childContextTypes',
		},
		{
			groupName: 'mixins',
			elementNamePattern: 'mixins',
		},
		{
			groupName: 'statics',
			elementNamePattern: 'statics',
		},
		{
			groupName: 'defaultProps',
			elementNamePattern: 'defaultProps',
		},

		// React lifecycle methods.
		{
			groupName: 'getDefaultProps',
			elementNamePattern: 'getDefaultProps',
		},
		{
			groupName: 'getInitialState',
			elementNamePattern: 'getInitialState',
		},
		{
			groupName: 'state',
			elementNamePattern: 'state',
		},
		{
			groupName: 'getChildContext',
			elementNamePattern: 'getChildContext',
		},
		{
			groupName: 'getDerivedStateFromProps',
			elementNamePattern: 'getDerivedStateFromProps',
		},
		{
			groupName: 'componentWillMount',
			elementNamePattern: 'componentWillMount',
		},
		{
			groupName: 'UNSAFE_componentWillMount',
			elementNamePattern: 'UNSAFE_componentWillMount',
		},
		{
			groupName: 'componentDidMount',
			elementNamePattern: 'componentDidMount',
		},
		{
			groupName: 'componentWillReceiveProps',
			elementNamePattern: 'componentWillReceiveProps',
		},
		{
			groupName: 'UNSAFE_componentWillReceiveProps',
			elementNamePattern: 'UNSAFE_componentWillReceiveProps',
		},
		{
			groupName: 'shouldComponentUpdate',
			elementNamePattern: 'shouldComponentUpdate',
		},
		{
			groupName: 'componentWillUpdate',
			elementNamePattern: 'componentWillUpdate',
		},
		{
			groupName: 'UNSAFE_componentWillUpdate',
			elementNamePattern: 'UNSAFE_componentWillUpdate',
		},
		{
			groupName: 'getSnapshotBeforeUpdate',
			elementNamePattern: 'getSnapshotBeforeUpdate',
		},
		{
			groupName: 'componentDidUpdate',
			elementNamePattern: 'componentDidUpdate',
		},
		{
			groupName: 'componentDidCatch',
			elementNamePattern: 'componentDidCatch',
		},
		{
			groupName: 'componentWillUnmount',
			elementNamePattern: 'componentWillUnmount',
		},

		{
			groupName: 'handlers',
			elementNamePattern: /^handle.+$/.source,
		},
		{
			groupName: 'callbacks',
			elementNamePattern: /^on.+$/.source,
		},
		{
			groupName: 'get-set-methods',
			elementNamePattern:
				/^(get|set)(?!(InitialState$|DefaultProps$|ChildContext$)).+$/
					.source,
		},

		// Separate groups so that the main `render` comes last.
		{
			groupName: 'render-methods',
			elementNamePattern: /^render.+$/.source,
		},
		{
			groupName: 'main-render',
			elementNamePattern: 'render',
		},
	],
},

Additional comments
Is there any way to configure a specific order within custom groups that I'm missing?
Validations

[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

Hi @stormwarning
Could you please give a code example including:

Initial state or currently sorted state.
What you expect to happen instead.

This will help us better understand what feature you are looking for.

Oh, the config I'm using works, it's just not ideal for this case.
Ideally, I could define a single react-lifecycle custom group and define the exact order within it; something like
{
  groupName: 'react-lifecycle',
  elements: [
    'componentWillMount',
    'componentDidMount',
    // etc...
  ],
}

Where elements (or what have you) is a list of patterns. Items matching would be in this group and the order of the group would be the order of the elements array itself.

Class components aren't used as much in React these days, so I understand if this isn't something to work on right away, I just wanted to point it out and see if there was a better way to configure this that I've missed

@hugop95, I think https://github.com/azat-io/eslint-plugin-perfectionist/issues/408#issuecomment-2514187578 would address the need

@OlivierZal I'm actually not sure if this falls under the same need as what we discussed in #408: if I understand correctly:

The config works and sorts with the expected order.
But it's verbose.

Ideally, I could define a single react-lifecycle custom group and define the exact order within it

What is the objective behind this? Let's consider that you have
{
  groupName: 'react-lifecycle',
  elements: [
    "componentWillMount",
    "componentDidMount",
    // etc...
  ],
}

and
{
  groupName: 'other-stuff',
  elements: [
    "otherStuff1",
    "otherStuff2",
    // etc...
  ],
}

I assume you would want your groups to look like
groups: [
 "react-lifecycle",
 "other-stuff"
]

Is this better than doing
groups: [
 "componentWillMount",
 "componentDidMount",
 "otherStuff1",
 "otherStuff2",
]

?
Can you confirm that this is solely for convenience (and not a missing feature) purpose?

elements (or what have you) is a list of patterns. Items matching would be in this group and the order of the group would be the order of the elements array itself.

This is regrouping two things in one:

The order of groups (the order of the elements array).
What each group matches (each elements member).

I'm not a fan of that for multiple reasons:

It's opinionated: choosing to match by element pattern is common, but is only one of all the filters that are offered.
customGroups order matters: the first custom group that matches is the one that will be used. Following your architecture, the following configuration would never give the expected result:

[
	"component", // Anything NOT matching the two below
    "componentWillMount",
    "componentDidMount",
]

Where should component go? (it matches the 3 members of the array).


Keep left menu consistent

I click on "Getting Started" under the C# Guide heading and all the higher level links in that menu then disappear. If i click on "What's new in C#" then the left menu stays consistent. I can't imagine that is deliberate.

⚠ Idea migrated from UserVoice
Created By: James Urry
Created On: 2017/03/13 11:31:55 +0000
Votes at Migration: 2
Supporters at Migration: 2

There's some ideas in the works here.
TL;DR; version: The .NET guide(s) would have a single TOC that's both too long and too deep to be really useful. As a result, we've gone to local TOCs at a number of levels. The breadcrumbs are the only substitute, and we know it's a poor one.
We're currently looking through all the content, and developing a larger navigation strategy. It will be a while, but it's known.
@Dend This may be wholly a content issue. If so, do you want to close this, and open a corresponding issue on the /dotnet/docs repo?

@BillWagner agree, a content issue that should be tracked in the content repo. @Powerhelmsman will help with moving the issue there.

@BillWagner I created a new issue on dotnet/docs repo. here is the link https://github.com/dotnet/docs/issues/4572. Please keep working on the issue there.


config.filter.http.ext_authz.v2.AuthorizationRequest headers_to_add not doing interpolation

Bug Template
Title: headers_to_add not doing interpolation
Description:
I'm trying to use ext_authz with oauth2-proxy under istio.
these docs point to this doc which states The same format specifier as used for HTTP access logging applies here, however unknown header values are replaced with the empty string instead of -.
However, what gets sent is:
[Envoy (Epoch 0)] [2020-02-09 02:19:18.510][39][trace][filter] [external/envoy/source/extensions/filters/http/ext_authz/ext_authz.cc:80] [C1704][S12786298896255907122] ext_authz filter calling authorization server
[Envoy (Epoch 0)] [2020-02-09 02:19:18.510][39][debug][router] [external/envoy/source/common/router/router.cc:434] [C0][S17990863836512223039] cluster 'outbound|80||oauth2-proxy-oauth2-proxy.oauth2-proxy.svc.cluster.local' match for URL '/qfqf'
[Envoy (Epoch 0)] [2020-02-09 02:19:18.510][39][debug][router] [external/envoy/source/common/router/router.cc:549] [C0][S17990863836512223039] router decoding headers:
':authority', 'kubernetes-dashboard.home.mikebryant.me.uk'
':method', 'GET'
':path', '/qfqf'
':scheme', 'https'
'content-length', '0'
'x-auth-request-redirect', '%REQ(:SCHEME)://%REQ(:AUTHORITY)%/%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%'
'x-envoy-internal', 'true'
'x-forwarded-for', '<IP_ADDRESS>'
'x-envoy-expected-rq-timeout-ms', '5000'

Note the header sent to the authorization service hasn't been interpolated / formatted
Repro steps:
Use this config - the important part is to try and use format strings in the headers
        name: "envoy.ext_authz"
        config:
          failure_mode_allow: false
          http_service:
            authorization_request:
              allowed_headers:
                patterns:
                - exact: Authorization
                - exact: Cookie
              headers_to_add:
              - key: X-Auth-Request-Redirect
                value: "%REQ(:SCHEME)://%REQ(:AUTHORITY)%/%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%"
            server_uri:
              cluster: outbound|80||oauth2-proxy-oauth2-proxy.oauth2-proxy.svc.cluster.local
              uri: http://oauth2-proxy-oauth2-proxy.oauth2-proxy.svc.cluster.local
              timeout: 5.000s

Note: The Envoy_collect tool
gathers a tarball with debug logs, config and the following admin
endpoints: /stats, /clusters and /server_info. Please note if there are
privacy concerns, sanitize the data prior to sharing the tarball/pasting.

Admin and Stats Output:

Include the admin output for the following endpoints: /stats,
/clusters, /routes, /server_info. For more information, refer to the
admin endpoint documentation.

Note: If there are privacy concerns, sanitize the data prior to
sharing.

Config:

Include the config used to configure Envoy.

Logs:

Include the access logs and the Envoy logs.

Note: If there are privacy concerns, sanitize the data prior to
sharing.

Can confirm none of the format strings are expanded for authorization requests; is there any other way to do this?


improve low bits model loading

Type of Change
feature or bug fix or documentation or others
API changed or not
Description
detail description
JIRA ticket: xxx
Expected Behavior & Potential Risk
the expected behavior that triggered by this PR
How has this PR been tested?
how to reproduce the test (including hardware information)
Dependency Change?
any library dependency introduced or removed

https://inteltf-jenk.sh.intel.com/view/nlp-toolkit-validation/job/nlp-toolkit-validation-top-mr-extension/1536/

UT - python3.9: https://inteltf-jenk.sh.intel.com/job/nlp-toolkit-optimize-ut/3015/
UT - python3.10: https://inteltf-jenk.sh.intel.com/job/nlp-toolkit-optimize-ut/3016/

GPT-J load-in-4-bit: https://inteltf-jenk.sh.intel.com/job/nlp_toolkit_optimize_validation_localtest/6473/
Mistral-7B autoround: https://inteltf-jenk.sh.intel.com/job/nlp_toolkit_optimize_validation_localtest/6474/
Mistral-7B GPTQ Qbits: https://inteltf-jenk.sh.intel.com/job/nlp_toolkit_optimize_validation_localtest/6477/
Mistral-7B GPTQ NeuralSpeed: https://inteltf-jenk.sh.intel.com/job/nlp_toolkit_optimize_validation_localtest/6476/

Mistral-7B autoround neuralspeed: https://inteltf-jenk.sh.intel.com/job/nlp_toolkit_optimize_validation_localtest/6483/


Dynamic import behavior is inconsistent with static import

Do you want to request a feature or report a bug?
This is a bug.

What is the current behavior?
The following should always be true for ES6 modules but right now it may evaluate to false when using webpack:
import X1 from 'x';
import('x').then(ns => ns.default === X1); // should always be Promise.resolve(true)

If the current behavior is a bug, please provide the steps to reproduce.
The following repo contains an example: https://github.com/jkrems/webpack-dynamic-import/blob/master/import-compare.js
This only seems to happen when the imported module was written as a CommonJS module.
You can run it via npm install && npm test.

What is the expected behavior?
Importing the default export using dynamic- and static import should always evaluate to the same value.
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
> node --version
v6.11.0

> webpack --version
3.0.0

Can you point me to the spec speccing the CJS interop for import()?

@sokra Not sure what you mean. This isn't related to CJS interop per se. It's an invariant in the module spec that isn't dependent on anything else.

Note: this seems to be addressed in webpack 4.


Not working for inceptionv3

Hi.
Thanks for the great work.
I tried running the main_cls.py with relu equilize and correction true for InceptionV3 (from PytorchCV model zoo), and got about 0.002 accuracy, whereas its working fine for resnet18, resnet50 etc.
Note: M using the input size 299 for inceptionv3.
Appreciate your comment.
Thanks !

There is something wrong to the equalized prediction results.
I've double checked the equalize part and it seems worked as expected. (If you use "python main_cls.py --equalize --relu", it get the same accuracy as original model)
And the set_quant_min_max part is ok, too. Actually if you use additional flags "--distill_range" and "--true_data", the accuract is still low on inceptionv3.
I suspect the reason is the change of activation range (or the weight range), which is not suitable for quantization on inceptionv3.
Unfortunately, I don't have time to verify this since one have to check the feature maps (weight) layer by layer.
Did you try the official implementation from aimet?

Closing issue. Feel free to reopen


Bad paths in 1.2.0

The recent minor bump was a breaking change in my setup. I'm using Rails 5.1.2, webpack-dev-server. (Fairly new to JS ecosystem tools, so bear with me...)
I have an nginx proxy set up to route all requests from www.indexical.dev/api to www.indexical.dev:9000. So the ideal routing for assets should be something like: www.indexical.dev/api/packs/application.js
I'm running webpack-dev-server with the following command:
bin/webpack-dev-server --public www.indexical.dev:9000 --inline --hot

And a webpacker config file like so:
development:
  <<: *default
  public_output_path: api/packs

  dev_server:
    host: www.indexical.dev
    port: 9000
    https: false

All that works, except that javascript_pack_path in the webpacker gem now gives me the address http:/www.indexical.dev/api/packs/application.js instead of http://www (etc). Somehow the change from v 1.1.2 to v 1.2.0 turned http:// into http:/, so that absolute urls were no longer possible.
Happy to answer more questions -- not exactly sure how to investigate JS issues very well, so apologies.

hi @andrewcsmith
Sorry for the inconvenience, I believe this was caused by #38
expect 1.2.1 to be release soon, I will update you as soon as I release it

1.2.1 released


added checklist in Pull Request Template

Checklist
N/A

The test is already run by Travis and the other checkbox doesn’t help me much as a reviewer I think ☺


Pytube errors #930 #931 #932 and some more

fixed #930 #931 #932 and other pytube based errors

Nice job! Yet to test it but this bug was annoying!

Tnx


Fix old partialWriteWithCsvDozerBeanWriter() is to an example of partial writing

The old partialWriteWithCsvDozerBeanWriter() is not an example of partial writing. I modify it to make it a right example.

Coverage remained the same at 99.085% when pulling 2228d63e2024974eca6474014493d6646e5603ae on dota17:ISSUE#177 into f5c1359f042ad2f5502791fbaa3d819b6e8c8b95 on super-csv:master.

I usually put "close #177" in the description and not as the start of the pr header

OK，Thank you for your work.


Fix bug when source class has parents

An error occurs when the sourceEntity has @Id propperty in parent class.

Needs test case, can't evaluate it otherwise.

@Ocramius should we close this one? I mean, it doesn't have test, is from 2013 and the destination branch is 2.4...


Release 0.5.0

Pull Request Test Coverage Report for Build 234

4 of 6 (66.67%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+11.6%) to 62.472%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core/src/main/java/io/gridgo/core/support/exceptions/InvalidGatewayException.java
0
2
0.0%

Totals

Change from base Build 218:
11.6%

Covered Lines:
566

Relevant Lines:
906

💛  - Coveralls


PIOasm disasm comment wrong

When compiling the following test-code:
.program test
.fifo txput
.wrap_target
    mov  rxfifo[0], ISR
    mov  rxfifo[1], ISR
    mov  rxfifo[2], ISR
    mov  rxfifo[3], ISR
    mov  rxfifo[Y], ISR
.wrap

I seem to get a correct binary according to the documentation. Sadly the disasm comments are wrong, swapping indexed and Y-mode:
static const uint16_t test_program_instructions[] = {
            //     .wrap_target
    0x8018, //  0: mov    rxfifo[y], isr
    0x8019, //  1: mov    rxfifo[y], isr
    0x801a, //  2: mov    rxfifo[y], isr
    0x801b, //  3: mov    rxfifo[y], isr
    0x8010, //  4: mov    rxfifo[0], isr
            //     .wrap
};

I tried very hard to use code-blocks in this text, but the line-endings failed hard in the preview whatever I tried.

merged into develop


Fix rendereditable to check the latest text before setting the selection

When user taps on a textfield,  both the gesture recognizer on top of the editable text and the render editable will handle the tap. This is due to the renderEditable needs to be able to receive tap if any of its textspans have gesture recognizers.
This causes an issue if the gesture recognizer on top of the editable text changes the text in text editing controller. It took one frame for the text to propagate to renderEditable, and renderEditable may uses outdated text stored in its textpainter to handle the pointer events.
This pr adds a sanity check in rendereditable before it wants to set the selection in response of pointer events.
fixes https://github.com/flutter/flutter/issues/78918
Pre-launch Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I signed the CLA.
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

It looks like this caused some legitimate failures, e.g. here in rendering/editable_test.dart.

The problem seems to just be that the test needs to be updated to set the text value to its TextSelectionDelegate as well.


added detection for EndCity structures

All new structures have to be linked to the correct dimension (if not Overworld).

Sorry I didn't pull this because I was in the middle of reformatting all the code.

Completely unrelated to this pull request...
I just noticed that you updated the starting page and at first describe the web based pack builder. As I never took a look to that code, I assume it is not working with the latest changes to the definition file syntax. The files you provide at your website are also not here in the repository. Probably they have to be looked trough and adapted slightly.
Did you test them with Minutor 2.1?

Yeah, the code needs to be updated... which honestly isn't a lot of work.  I'll do it this week.
I'm wondering, however, if it wouldn't be better in the future to build a pack editor directly into Minutor.  That's a bit more work though.

You are right with "isn't a lot work" when you refer to blocks and block colors.
But it took me several month of external code analysis to get the Mob spawn detection work the correct way.


Lengthen the abstract preview in the tooltip

Users reported to not reading any of the abstract in the tooltip because they anticipated it would be too short to learn anything useful from. For abstracts in the tooltips to be useful, we should show more text (I suspect at least 40+ words).

Before calling this issue finished, the code should be cleaned up, in particular:

[ ] Merging Citation and CitationTooltipBody
[ ] Using a more sophisticated link component for the "(see more)" link


When will the code about TIARA be open sourced?

After reading your article, I feel very innovative, and there are still some details that I don't understand very well, and I want to understand it through code. When will the code be open sourced?

Code is going through our release process and should be here in the repo in the coming weeks. Thanks for your interest.


malf clients can steal peoples organs

Description
and normal clients if pvs lets them see organs in right click menu
other player verified it was real and not clientside
this can maybe be done for actions too if they had ItemComponent
an easy visual way to know if you can do it is if someone is wearing clown shoes etc but arent waddling, you can probably steal their organs

That's awesome

How are people seeing organs, and how were they pilfering them? Just being able to select them via the right click menu is not enough. E.g., just use the /menuvis all command to show all entities including those in containers.
It sounds more like they were getting disembowelled and had their organs removed & parented to themselves?

Just being able to select them via the right click menu is not enough

literally this
i just right click the guy take the lungs drop it on the floor, repeat for all organs
and then he got mad


Encode dataclass custom root json is different from BaseModel custom root json

Initial Checks

[X] I have searched GitHub for a duplicate issue and I'm sure this is something new
[X] I have searched Google & StackOverflow for a solution and couldn't find anything
[X] I have read and followed the docs and still think this is a bug
[X] I am confident that the issue is with pydantic (not my code, or another library in the ecosystem like FastAPI or mypy)

Description
Encode dataclass custom root json is different from BaseModel custom root json
Example Code
import json

from pydantic import BaseModel
from pydantic.dataclasses import dataclass
from pydantic.json import pydantic_encoder
from typing import List

class Model1(BaseModel):
    __root__: List[int]

obj1 = Model1(__root__=[1, 2, 3])
print(obj1.json())
"""
[1, 2, 3]
"""

@dataclass
class Model2:
    __root__: List[int]

obj2 = Model2(__root__=[1, 2, 3])
print(json.dumps(obj2, default=pydantic_encoder))
"""
{"__root__": [1, 2, 3]}
"""

Python, Pydantic & OS Version
pydantic version: 1.10.2
            pydantic compiled: True
                 install path: /Users/near/.pyenv/versions/miniconda3-latest/envs/test2/lib/python3.7/site-packages/pydantic
               python version: 3.7.6 (default, Jan  8 2020, 13:42:34)  [Clang 4.0.1 (tags/RELEASE_401/final)]
                     platform: Darwin-21.3.0-x86_64-i386-64bit
     optional deps. installed: ['typing-extensions']

Affected Components

[ ] Compatibility between releases
[ ] Data validation/parsing
[X] Data serialization - .dict() and .json()
[ ] JSON Schema
[X] Dataclasses
[ ] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

ye, we have Custom Root Types on models, but not dataclasses.

I fix it in #4540
@samuelcolvin

It's not a bug, it's the correct behaviour.

The reason is?

Custom root types wouldn't make sense on dataclasses
Please ready pull request template which you must have seen and deleted - we're working on V2 where custom root types will be removed completely, and this isn't suitable for a patch release on V1.X, you might also want to read https://pydantic-docs.helpmanual.io/blog/pydantic-v2/
Your PR contained no explanation.

Since the pydantic_dataclass custom root cannot be mixed with other fields, I think to encode it should be the same behavior as BaseModel.
And not everyone is ready to move pydantic from V1 to V2, that needs time

And not everyone is ready to move pydantic from V1 to V2, that needs time

Agreed, but active development of V1 has stopped we're just releasing some minimal bug fixes, there will be no V1.11 and this change would not be suitable for a patch release.

So inconsistent behavior of encoding custom root between pydantic_dataclass and BaseModel is not a Bug?

No it's not - __root__ doesn't mean anything special in dataclasses.
But more generally, there are real and problematic bugs in pydantic v1 - like in any codebase of this size and complexity. But if we tried to fix them all, we'd 1) fail, 2) never get to V2 such should be significantly easier to maintain, and long term have far fewer bugs.


Uncaught error during optimize with worker set to zero

After optimization with bedrock-webpack, and with workers set to 0 in the config, there seems to be some issue shutting down child processes:
Node v6.11.3
2017-09-21T14:02:23.780Z - critical: master: uncaught error: Error: channel closed
    at ChildProcess.target.send (internal/child_process.js:584:16)
    at Worker.send (cluster.js:64:28)
    at process.<anonymous> (/home/bedrock/veres-delta/node_modules/bedrock/lib/bedrock.js:409:27)
    at emitOne (events.js:96:13)
    at process.emit (events.js:188:7)
    at process.exit (internal/process.js:164:15)
    at EventEmitter.<anonymous> (/home/bedrock/veres-delta/node_modules/bedrock/lib/bedrock.js:420:15)
    at emitThree (events.js:116:13)
    at EventEmitter.emit (events.js:194:7)
    at ChildProcess.<anonymous> (cluster.js:378:15)
    at ChildProcess.g (events.js:292:16)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:219:12)

Closing old obsolete issue.


First stab at server initiated key rotation

Alright, this is more complete. PTAL @weswhet

Looks good! nice work.


Translate to full Apache Calcite algebra

In #5 we translate external collections to a Calcite TableScan; in this change we will go further, and translate all relational operations to Calcite relational operators (for example filter to Filter, map to Project).

Fixed in 61f3f519f5ba2cf2af9db09fa50dd2fee09aa858.


TypeError: require(…) is not a function when compiling with livereactload

Any ideas how to fix this error? It errors out when using next branch too.
I'm aware that this issue is likely because of livereactload or even babel, but maybe someone saw it before.
https://github.com/milankinen/livereactload/issues/71

I'll close this as it is related to livereactload only.


LightGBMError: Check failed: (split_indices_block_size_data_partition) > (0)

Description
Execution of code failed with error
LightGBMError: Check failed: (split_indices_block_size_data_partition) > (0) at /usr/local/src/lightgbm/LightGBM/lightgbm-python/src/treelearner/cuda/cuda_data_partition.cpp, line 280 .

Reproducible example
Please, use this repo
Environment info
Docker image, based on nvidia/cuda:12.2.0-devel-ubuntu22.04
GPU: GeForce GTX 1060
CPU: AMD Ryzen 5 1600
Additional Comments
Same massage for classifiction and regression models

Thanks for using LightGBM.
The repo you've linked shows how you installed LightGBM, but not the code you're using to run LightGBM. Can you please share the exact code you're using? Are you able to provide a reproducible example (exact code that we could run which replicates the error)?
Although you didn't say it here, I know you're using the Python package specifically because of your comments on #6325. See these links for some examples of good reproducible examples in Python: https://github.com/microsoft/LightGBM/issues/6321#issuecomment-1948512259.
It's going to be very difficult to help you given only the details you've provided so far.

Can you please share the exact code you're using?

The repo I provided has code snippet inside the README

Thanks for reporting this issue. I think it should be quick to fix. I'm trying with your example.

Update the progress here.
I've built the docker image and try to reproduce the error. But the code runs successfully within the docker container. Here's the output. I modified the code the get the training loss.
import lightgbm as lgb
from sklearn.datasets import make_regression

X, y = make_regression(n_samples=10_000)
dtrain = lgb.Dataset(X, label=y)
dval = lgb.Dataset(X, label=y)
bst = lgb.train(
        params={
           "objective": "regression",
           "device": "cuda",
           "verbose": 1,
       "metric": "l2"
        },
        train_set=dtrain,
    valid_sets=[dval],
    callbacks=[lgb.log_evaluation(period=1)],
    num_boost_round=5
)

[LightGBM] [Warning] Using sparse features with CUDA is currently not supported.
[LightGBM] [Info] Total Bins 25500
[LightGBM] [Info] Number of data points in the train set: 10000, number of used features: 100
[LightGBM] [Info] Start training from score -0.370042
[1]     valid_0's l2: 22190.7
[2]     valid_0's l2: 19590.2
[3]     valid_0's l2: 17420.6
[4]     valid_0's l2: 15575
[5]     valid_0's l2: 13972.9

My GPU is V100, which is different with yours.
One more thing that I would like to confirm is that, in the Dockerfile, there seems to be no LightGBM version being specified. So it builds the latest version from source. In your container where the error can be reproduced, can you provide the commit head of the LightGBM repo? That would be helpful for me to further identify the root cause.
Thanks.

@shiyu1994, Thanks for your response!

can you provide the commit head of the LightGBM repo? That would be helpful for me to further identify the root cause.

Sure, it's https://github.com/microsoft/LightGBM/commit/252828fd86627d7405021c3377534d6a8239dd69

@shiyu1994, Do you have any information about the problem?


Fixing clippy errors

Clippy errors getting fixed by this commit:
error: private item shadows public glob re-export
Error:    --> akd/src/lib.rs:486:1
    |
486 | mod utils;
    | ^^^^^^^^^^
    |
note: the name `utils` in the type namespace is supposed to be publicly re-exported here
   --> akd/src/lib.rs:483:9
    |
483 | pub use akd_core::*;
    |         ^^^^^^^^^^^
note: but the private item here shadows it
   --> akd/src/lib.rs:486:1
    |
486 | mod utils;
    | ^^^^^^^^^^
    = note: `-D hidden-glob-reexports` implied by `-D warnings`

Codecov Report
Patch coverage has no change and project coverage change: +0.03% :tada:

Comparison is base (be1055e) 87.73% compared to head (250422f) 87.76%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the GitHub App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #402      +/-   ##
==========================================
+ Coverage   87.73%   87.76%   +0.03%
==========================================
  Files          39       39
  Lines        8771     8771
==========================================
+ Hits         7695     7698       +3
+ Misses       1076     1073       -3

Files Changed
Coverage Δ

akd/src/directory.rs
83.28% <ø> (ø)

... and 1 file with indirect coverage changes

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


Cannot be used with lazily-loaded engines in dev mode

We've run into an issue where we cannot navigate to our lazily load (in-repo) engines when in development mode. 1
This is because the asset-loading service behind ember-engines constructs a manifest file based on what it sees as the engine's trees/assets. For some reason it's adding ember-svg-jar assets as well, and when loaded we get a console error:
Could not read config from meta tag with name "svg-jar/config/environment".

I've created a repo with the repo case here (error occurs when clicking the Users link):
https://github.com/sohara/svg-jar-lazy-engine

The bug is fixed in the latest ember-svg-jar v1.X.X. Feel free to reopen the issue if you still can reproduce it.

@sohara I am using the latest ember-svg-jar v1.X.X and ember-cli v.2.12 , but then {{svg-jar}} doesn't seem to be working in IN-REPO-ENGINE. I still get the error 'Could not read config from meta tag with name "svg-jar/config/environment"'. Is it really necessary to use ember v.3.0. Can we any way achieve a solution using ember cli v.2.12


languageCode case

Hi!
I'm not sure if this question related to this package actually.
Why sometimes languageCode is in lower case and sometimes in upper (fr or FR in my case) depending on the device? 🤔

@Legi0n1138 Indeed this is not related to the lib. Stack Overflow might be a better platform than a library issue to ask that next time 😅
fr (lowercase) is the language code, FR (capitalized) is the country code.
The combination of the two (with sometimes and additional script code) is called a language tag.
Ex: fr-FR for French french, fr-CA for Canadian french, en-UK for Great Britain english, en-US for American english.

@zoontek

fr (lowercase) is the language code, FR (capitalized) is the country code.
Then why the package returns a country code instead of language code?

@zoontek

fr (lowercase) is the language code, FR (capitalized) is the country code.

Then why the package returns a country code instead of language code?

In which cases? Issues have templates, I though it was a simple question

@zoontek I wasn't sure that this is a bug
Physical device
Hardware Model:      iPhone8,4 (iPhone SE)
OS Version:          iPhone OS 13.1.3 (17A878)

I published a new version where they are enforced: https://github.com/react-native-community/react-native-localize/releases/tag/1.3.2

@zoontek Thanks! 😄


 Since Terminals don't really have
any gaps anyways, it'll now not be taken into account anymore.
Center alignment breaks bitmap glyphs which expect left-alignment
Automatic "opsz" axis makes Terminus TTF

Depends on #14013
Closes #14006
Validation Steps Performed

Use Terminus TTF at 13.5pt
Print UTF-8-demo.txt
No gaps between block characters ✅

Service this?

Depends on #14013

Oh, since you said

Depends on https://github.com/microsoft/terminal/pull/14013

and that's a decently big one, I'm guessing we don't want to. Nvmd.

Automatic "opsz" axis makes Terminus TTF

makes it what

Center alignment breaks bitmap glyphs which expect left-alignment

this is almost certainly going to mess us up in other ways.

this is almost certainly going to mess us up in other ways.

That's possible, but just so you know, that's exactly how GDI and DxEngine draw text. Only AtlasEngine was drawing glyphs centered in their layout box.


Add access to unique group ID

It looks like the LFXLight instances each get their own consistent, accessible, unique identifiers. Is it possible to add this the LFXGroup as well?

Yes, I added this to LFXGroupImpl.java:
public String getID() { return getTagID().toString(); }

Before I fixed it I wrote this. But when I got to the end I realized that I should just add it, so I did. Someone might still be interested in how groups are implemented so I posted it anyway.
The the bulb's id is its mac address, which the protocol uses to address it. So exposing that through the api is a no brainer.
Groups on the other hand are not part of the protocol. Groups are created on top of tags (which are in the  protocol) and tags works like this:

A bulb has a bitfield which indicates which tags it has. There are 64 different tags that the bulb can have. These tags are enumerated in LFXTagID.
A bulb has a label for each tag.

So it is technically possible to have two bulbs both having TAG_01 but bulb one thinks that the label for TAG_01 is "A" and bulb two thinks that the label for TAG_01 is "B".
lifx-sdk-android didn't like a tag system, so they implemented groups on top of tags:

A group is a tag. That is, it's id is the tag.
When creating/changing a group's label all bulbs are told to change the label for that tag.
There can not be two groups with the same label.
A group can not have an empty label.

Personally I like tags better than groups, but I wanted to be compatible with other apps so I went with groups.
All this comes down to: exposing the tag id through the api is probably fine.


Add download stop action

The lib should have an option of stopping the download

Since response$ is now available its possible to destroy HTTP requests.

How exactly is this supposed to be used?
Expose response$ externally for manually destroying

@ohenepee Here is an example for version 2.0 —
const [{response$, meta$}] = DownloadFromMTDFile('/hello.txt.mtd')
response$.subscribe(response => {
  setTimeout(() => response.destroy(), 1000) // stops the download after 1 second
})

PS: Install version 2.0 — npm i mt-downloader@next

You're just awesome!


Don't requite GET_ACCOUNTS on ICS+ devices

Fixes #14

For some reason my application can't start properly with 1.3.0-SNAPSHOT when triggered by PACKAGE_REPLACED.
It creates a SecurityException when accessing the system accounts.
Any idea?

Which version of Android and device do you test it on? Can you post the exception with stack trace?

Android 5.0, OnePlus One.
I have a variety of devices I can check later today.
On Wed, Feb 25, 2015, 10:53 AM Daniel Novak<EMAIL_ADDRESS>wrote:

Which version of Android and device do you test it on? Can you post the
exception with stack trace?
—
Reply to this email directly or view it on GitHub
https://github.com/inloop/easygcm/pull/16#issuecomment-75999707.

@adrien-aubel Have you found some time to debug this problem? Can you post a stacktrace? I can't replicate this issue.


[Bug] When the data of the last point is 0, there will be problems when displaying the table.

Search before asking

[X] I had searched in the issues and found no similar issues.

Apache SkyWalking Component
OAP server (apache/skywalking)
What happened

What you expected to happen
Hope the last point is filtered out when it is 0
How to reproduce
When the data of the last point is 0, there will be problems when displaying the table.
Anything else
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

We don't have plan to exclude the latest value actually. Read https://github.com/apache/skywalking/issues/10501, that is the right way to do so. 0 sometimes means 0, it is meaningful


update doc for Load

addressed comments

add an exmaple?

@piiswrong any idea why this failed?

I agree that an example would be helpful.
@nswamy  and I talked about the example. We felt there should be a how-to in our docs that discusses how to load/save models. We we create that we can add a link to that from here.
@piiswrong  is that ok with you?

ok.
note that is is mostly for partial loading.
if you are loading the exact same model you can module.load directly.
this is useful when you want to initialize your new (with more params) model from a pretrained model.