Requirements Error

Any idea what's causing this issue?
$ pip3 install -r requirements.txt
Defaulting to user installation because normal site-packages is not writeable
Collecting requests==2.28.1
Using cached requests-2.28.1-py3-none-any.whl (62 kB)
Collecting schedule==1.1.0
Using cached schedule-1.1.0-py2.py3-none-any.whl (10 kB)
Collecting user-agent==0.1.10
Using cached user_agent-0.1.10.tar.gz (20 kB)
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [30 lines of output]
Traceback (most recent call last):
File "", line 2, in
File "", line 34, in
File "/tmp/pip-install-hc6t1ydk/user-agent_5d05addb72194e6fa553c7e763aa2694/setup.py", line 10, in
setup(
File "/home/kali/.local/lib/python3.10/site-packages/setuptools/init.py", line 86, in setup
_install_setup_requires(attrs)
File "/home/kali/.local/lib/python3.10/site-packages/setuptools/init.py", line 75, in _install_setup_requires
dist = MinimalDistribution(attrs)
File "/home/kali/.local/lib/python3.10/site-packages/setuptools/init.py", line 57, in init
super().init(filtered)
File "/home/kali/.local/lib/python3.10/site-packages/setuptools/dist.py", line 473, in init
for ep in metadata.entry_points(group='distutils.setup_keywords'):
File "/usr/lib/python3.10/importlib/metadata/init.py", line 1021, in entry_points
return SelectableGroups.load(eps).select(**params)
File "/usr/lib/python3.10/importlib/metadata/init.py", line 459, in load
ordered = sorted(eps, key=by_group)
File "/usr/lib/python3.10/importlib/metadata/init.py", line 1018, in
eps = itertools.chain.from_iterable(
File "/usr/lib/python3.10/importlib/metadata/_itertools.py", line 16, in unique_everseen
k = key(element)
File "/usr/lib/python3.10/importlib/metadata/init.py", line 943, in _normalized_name
or super().normalized_name
File "/usr/lib/python3.10/importlib/metadata/init.py", line 622, in normalized_name
return Prepared.normalize(self.name)
File "/usr/lib/python3.10/importlib/metadata/init.py", line 871, in normalize
return re.sub(r"[-.]+", "-", name).lower().replace('-', '')
File "/usr/lib/python3.10/re.py", line 209, in sub
return _compile(pattern, flags).sub(repl, string, count)
TypeError: expected string or bytes-like object
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

It looks like you're getting an error while downloading the user-agent module. To solve this try downloading it separately by typing pip install user-agent or pip3 install user-agent. If the error persists it means that the error is within the user-agent package which is something I'm not capable of fixing.


Error in example command

This command fails:
Install-WindowsFeature -Name "BitLocker", "Data-Center-Bridging", "Failover-Clustering", "FS-FileServer", "FS-Data-Deduplication", "Hyper-V", "Hyper-V-PowerShell", "RSAT-AD-Powershell", "RSAT-Clustering-PowerShell", "NetworkATC", "Storage-Replica" "NetworkHUD" -IncludeAllSubFeature -IncludeManagementTools
The example command is missing a comma between Storage-Replica and NetworkHUD
[Enter feedback here]

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

ID: 0ab3539e-5334-d406-7078-1bab3a66215d
Version Independent ID: c1486a71-19a8-e347-d456-6714529306e6
Content: Deploy Azure Stack HCI on a single server - Azure Stack HCI
Content Source: azure-stack/hci/deploy/single-server.md
Service: azure-stack
Sub-service: azure-stack-hci
GitHub Login: @ronmiab
Microsoft Alias: robess

@bsniderpa - the issue has been corrected in another PR. Changes should be published today.

please #close


More releasing guide updates

Plus a syntax fix in the last one.

Marking this ready for review without additional changes for now because the syntax problem is annoying ;-)


CSIP Profile: cannot access https://dilcis.eu/XML/METS/CSIPExtensionMETS/DILCISExtensionMETS.xsd

CSIP, SIP, AIP,DIP METS Profile(s)
Error 404 on trying to access one of the XML Schemas for CSIP METS profile:
https://dilcis.eu/XML/METS/CSIPExtensionMETS/DILCISExtensionMETS.xsd

Is there any time frame when will be URL links to schemas published?

Update on the way.

Fixed with PR #581

Is this fixed?
Because I still cannot access the XSD under this link: https://dilcis.eu/XML/METS/CSIPExtensionMETS/DILCISExtensionMETS.xsd

@shsdev its this link to the profile the namespace for it is the one you gave: http://earkcsip.dilcis.eu/schema/DILCISExtensionMETS.xsd


Added jpg support.

Does the srcVar has to be explicitly changed when loading the image like it was doing before?

👍
Looks good to my, there is only one thing to change, and if you don't mind I can change it myself or you can do it :)

👍 Looks good for me. Thanks for the contribution!


SurveyJS resetting state in React

Are you requesting a feature, reporting a bug or asking a question?
Bug.
What is the current behavior?

What is the expected behavior?
To not reset form
How would you reproduce the current behavior (if this is a bug)?
???
I am using last versions of the packages, but I am still not sure why this error occurs.
Specify your

browser: Safari, Chrome and Firefox
surveyjs platform react
surveyjs version: 1.0.67

Hello! Thank you for the reporting. I don't manage to reproduce it. Could you please provide an example or json to reproduce the problem.

@dmitrykurmanov Will come back at this.

this.model = new Survey.Model(intake());
// ...
this.model.startTimer();
// ...
this.model.stopTimer();

Removed the timers. Fixed it.

Call this method to start timer that will calculate how much time end-user spends on the survey or on pages

https://surveyjs.io/Documentation/Library/?id=surveymodel#startTimer
Hmm, why would this fix anything at all?

@StephanMeijer Hello! Thank you for the comment https://github.com/surveyjs/surveyjs/issues/1535#issuecomment-462466472
You are using quiz and I've reproduced the bug.

We've fixed the bug. Fix will be available in the next minor update.

@tmvnk 🎉

Glorious! Thank you so much <3


🚀 Enhancement: Add Python (ML) starter template

🔖 Enhancement description
If I:

Go to functions
Click the "Create function" button
Select Python
Click on the "Runtime" dropdown

I don't see the Python (ML) runtime:

For reference, the blog suggests:

It would be nice to be able to easily create a blank/starter Python (ML) runtime function.
🎤 Pitch
The problem right now is it seems like something is broken/missing when you try to create a Python (ML) runtime function because the option isn't available.
👀 Have you spent some time to check if this issue has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

@stnguyen90 I was exploring how the functions are created for each runtime and found a call to https://cloud.appwrite.io/v1/functions with the runtime as part of the payload, so for Python (ML), this endpoint should be able to handle it right? How can I check if it does or not?


Parse versions

WIP

Stuck on:

Don't found way to early returns from .map() so from_str has manual iteration
Maybe same in read_function, don't have time to fully test.
Doc tests not compiling, not found why.

Found error in gir: Version: 3.0.. May be it same error for you add .filter(!s.is_empty()) in gtk

Ignore fixing part.
But i still not fully understand for what you do it.

I used take_while to cut of the iterator on a parsing error.
filter(!is_empty()) in main crates' build scripts is needed to avoid returning an empty cfg that causes an ICE in rustc.
Regarding the version numbers complexity. Do you think there's any harm in using a tuple and defaulting failed elements to 0?
Then there're some strategies of acting on the versions to choose from:

we may get away with ignoring the "patch" version (third element) and just leaving the door open to adding it if there's demand;
collect the list of x.y.z versions that are present in such attributes and put the list into the build scripts, so e.g. the build script would enumerate pango_1_30, pango_1_31_0, pango_1_32, pango_1_32_4, pango_1_34, pango_1_36, pango_1_36_7.

filter(!is_empty()) in main crates' build scripts is needed to avoid returning an empty cfg that causes an ICE in rustc.

Thinked that empty part of split result can be only from empty string which better check directly. Now see other option ("3.0.").

Regarding the version numbers complexity. Do you think there's any harm in using a tuple and defaulting failed elements to 0?

I plan replace empty parts with 0. "3.1." => Version([3,1,0]) "3..2" => Version([3,0,2]).
Don't thinked about tupples.
Possible problems:

comparing different length (2,3) and (1,4,2),
iterating (mostly on comparing)

If we decide to care about the patch version part, iterating blindly doesn't seem possible, we'll have to use the actual set of versions encountered when parsing the library (have Library maintain that set).
A fixed length tuple that defaults to zero seems an easy compromise. To rephrase the linked example,
    let mut parts = lib.version.splitn(4, '.')
        .map(|s| s.parse())
        .take_while(Result::is_ok)
        .map(Result::unwrap);
    let version: (u16, u16, u16) = (parts.next().unwrap_or(0), parts.next().unwrap_or(0), parts.next().unwrap_or(0));

If some of the parts fails to parse the tuple is filled with zeroes ("3.1." => (3, 1, 0), "2.a.1" => (2, 0, 0)). Implementing Ord is straightforward, formatting cfg directives is manageable.

Queston, we need about add patch version in cfgs or not?

Let's only add them if they're non-zero: pango_1_32_4, pango_1_34.

Ok.

And add warning to log this.

The more specific versions don't seem to have any impact that would justify a warning.

But we know, that in library some function has really 3digits version, and adjust decision about iterating in build.rs

Remake Version to tuple

We have 1.32.4 in pango and some odd minored in others. Seems we really need store version in Namespace, and use it when generating build.rs or include to it  module with versions.

Why u16, not u32?

like gir_version ?

Why u16, not u32?

u16 seemed exceedingly big for any sane version numbers.

like gir_version ?

Sounds good.

Renamed files

Looks good. Do you want to merge or build on this more?

As classes and interfaces seems not versioned, I only add deprecated-version for functions

We might also be interested in enumeration and bitfield members' versions.

And constants.
IMHO better add config check to function before this, so ready for merge.
Warnings about versions I have not remove, check_version will changed to store versions to namespace. But it can be done only after generating main code to prevent desynchronization.
Or you prefer remove check_version now?

With version autodetection we have problems if generate config check on sys before do it on full generated main :cry:

Or you prefer remove check_version now?

It's fine for now.
Re. desynchronization, do I understand it correctly that your concern is about compatibility between the 'sys' and 'normal' modes because the 'normal' mode doesn't know about cfg versions? The objective of replacing manual sys crates needs the existence of cfg versions but doesn't require any conditional compilation in sys crates.

@homu r+

:pushpin: Commit 6608d25 has been approved by gkoz

:hourglass: Testing commit 6608d25 with merge e7a20f1...

:sunny: Test successful - status

Seems I don't understand something.
We have sys with autodetected cfg_xxx and function
#[cfg(gtk_3_12)]
 pub fn GTK_POPOVER(widget: *mut ffi::GtkWidget) -> *mut ffi::GtkPopover {
     unsafe { ffi::cast_GtkPopover(widget) }
 }

its current analog gtk_popover_get_type with same cfg. Or gtk_popover_new.
normal gtk get cfg value through DEP_GTK_CFG.
My concern is that:
if pub use self::popover::Popover; in gtk main.rs don't have same #[cfg(gtk_3_12)] for some reason,
then it not detected on CI as it use latest version.

main.rs suggests an application? Testing applications for compatibility with older libraries could be difficult.
Our CI currently builds with both GTK 3.6 (travis and appveyor) and 3.14 (appveyor only), so missing a cfg should get caught.

Oh, forgot that gtk default is 3.6 - almost oldest supported version.

Then no obvious problems, but still don't like that condition on sys may added before same condition on normal.


 Of course, it's also possible that I didn't fully understand how weighted chance works.
Regarding my exact problem. I tried to set up the frequency of the events for a long time, based on what I understood to be weighted chance, but even after hundreds of tests the results seemed strange to me.
I then set all EventType Weights to 1. If I understand correctly, in this case each category should have a 16.67% chance of being selected. These are the results after 200 runs.

Am I correct that these results are very unlikely and something is going wrong or have I not understood weighted chance?
Sorry for my English, it's not my native language.

These results seem correct except the neutral one. And you have understood what it is.
But the actual probabilities will be more complicated than that because some events will remove other events from happening or some events have conditions to be activated.
.
And in general there are some very bad events that will remove the lesser version of it so having everything set to 1, very bad should happen more commonly than bad.

These results should also vary depending on the amount of events chosen.
When i get home from work i'll test this myself.

I should probably mention that I changed the event count to one.

What events did you disable?

Neutral - Birds, LeaflessBrownTrees, LeaflessTrees ,Locusts, Trees
Bad - Bees, DoorGlitch, OutsideLandmines, OutsideTurrets
Very Bad - ForestGiant, InsideBees, Warzone

Simple fix but i will release whenever I decide to make some new events, and out of my own curiosity I tallied the events 1,000,000 times for 1, 3, 8 and 20 Events all on experimentation using default weights.
1 Events

3 Events

8 Events

20 Events

That looks really good, thank you.
Great work and really great mod.


Start reporter with the Rails app

This adds a new after_initialize hook to the Railtie to start the reporter during the app boot, after all the other app config/initialization setup is done, which should give us access to the already configured Judoscale instance.
The way it's implemented is by running a new worker every time the process PID changes, so that if you're running a single thread server (e.g. Puma in thread mode only), you only get this initial reporter running, and it will be responsible for all collection & reporting. In cluster/workers mode, however, a reporter will be created during boot, and a new one for every forked process whenever a new request hits the request middleware, so each process get their own reporter thread. This is necessary because each process keeps an in-memory "store" of request metrics to flush every few seconds, and that store isn't shared among different processes, so we have each process run its own reporter thread and report the stored metrics on their own, a simple approach to make sure all processes are always covered, and that if a process is killed and restarted (e.g. by puma or unicorn), a new reporter can start again automatically to handle that new process as well.

The only issue is we may not know if we're running in single vs cluster mode from Rails perspective, and we can't just do workers in single mode, but maybe I can find a way to "activate" the web collectors when the first request hits or something.

I was thinking that when we attempt to start a reporter from the RequestMiddleware, we could assume that a new reporter would only be started if we're running in cluster mode. In that case, we could skip worker metrics for those reporters.
Maybe we could include an option to Reporter.start to say "if this actually starts a new reporter, ignore metrics collectors for jobs". Now that I write it out, that feels messy... just sharing one approach. :-)


chore!: bumped framer-motion to v4

Overview

Bumped framer-motion to v4.

PR Checklist

~[ ] Related to designs:~
[x] Related to JIRA ticket: WEB-1030
[x] I have run this code to verify it works
[x] This PR includes unit tests for the code change

Notes
Corresponding monolith PR: https://github.com/codecademy-engineering/Codecademy/pull/27137

🚀 Styleguide deploy preview ready!https://6154a6142fe2450096982548--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.5.107-alpha.a194ed.0@codecademy/gamut-labs@25.0.0-alpha.a194ed.0@codecademy/gamut@38.0.0-alpha.a194ed.0@codecademy/monaco@0.4.19-alpha.a194ed.0<EMAIL_ADDRESS>
📬Published Alpha Packages:@codecademy/gamut-kit@0.6.5-alpha.1324e3.0@codecademy/gamut-labs@28.0.0-alpha.1324e3.0@codecademy/gamut@40.0.0-alpha.1324e3.0@codecademy/monaco@0.5.5-alpha.1324e3.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://61800c7c18edaa5926f0dabe--gamut-preview.netlify.appDeploy Logs


FHIR exporter should export family name as a string instead of an array

In STU3 1.8, HumanName.family has a cardinality of 0..1 and should be exported as a string instead of an array. This is causing synthea output to fail validation on upload to a stu3 server.

Thanks for the bug report. I'll fix this in a few minutes.


Docked views

Took another pass at this, and got it into a place I'm happy with. The intention is to closely mirror the TabContainer API.
See issue #874 and corresponding Toolbox PR https://github.com/exhi/toolbox/pull/165

Reviewing this now Tom

This is an extremely cool component and really well implemented!  Can't wait to merge it.
One question -- could it be useful on tablet?  What is desktop specific here?

Thanks for taking a look Lee, and for the great suggestions - I've pushed an update implementing them.
Toggling Behaviour:
The toggling behaviour is inspired by Gmail's docking behaviour. Toggling between docked / dialog and collapsed / expanded are toggled independently of each other, except for one specific case: going from docked+collapsed to dialog inserts an intermediate docked+expanded state.
Happy to change to a different approach if we feel it makes more sense. I'll admit that I feel the Gmail system is quite hard to reason about, but doesn't feel surprising in actual use. Would also like to get @amcclain's thoughts on this, since we had a back-and-forth on this behaviour in the early days of this component.
Tablet:
I didn't consider tablet usage, but think it would make sense and be a worthy addition. One potential complication is the mobile and desktop toolkits currently use different implementations for the dialogs - but I expect an approach using dynamic imports of platform-specific view implementations could work. Do we want to go ahead and do that now?

I trust the toggle behavior well thought out and intended -- just thought
the code was a bit unclear to reason about. Maybe rename the method to just
toggleState or something more generic to make it clear that it is not a
binary thing....not a big deal.
I don't think there is a huge need to do anything on the tablet now -- the
question is -- if we intend to, and the API is going to be generic, should
we put this object in the cross-platform package now, so clients won't need
to adjust imports later....
Not sure about this one, but it seems like if we are trying to model it
after tab container, that would be the way to go.
On Fri, Apr 5, 2019 at 6:47 AM Tom Tirapani<EMAIL_ADDRESS>wrote:

Thanks for taking a look Lee, and for the great suggestions - I've pushed
an update implementing them.
Toggling Behaviour:
The toggling behaviour is inspired by Gmail's docking behaviour. Toggling
between docked / dialog and collapsed / expanded are toggled independently
of each other, except for one specific case: going from
docked+collapsed to dialog inserts an intermediate docked+expanded state.
Happy to change to a different approach if we feel it makes more sense.
I'll admit that I feel the Gmail system is quite hard to reason about, but
doesn't feel surprising in actual use. Would also like to get @amcclain
https://github.com/amcclain's thoughts on this, since we had a
back-and-forth on this behaviour in the early days of this component.
Tablet:
I didn't consider tablet usage, but think it would make sense and be a
worthy addition. One potential complication is the mobile and desktop
toolkits currently use different implementations for the dialogs - but I
expect an approach using dynamic imports of platform-specific view
implementations could work. Do we want to go ahead and do that now?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/exhi/hoist-react/pull/1049#issuecomment-480232002,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACM16e3Lv11R2OGtnOf1oAcgEzQKyLbBks5vdynegaJpZM4cWHak
.

Thanks for taking a look. A couple of notes:
DockViewModel.id
In the end, I made it so that dock views always require an id. It seemed the most useful and stable to make apps responsible for providing the id, and I think the stability is worth the inconvenience of not having the id generated for you.
BEM classes
I've updated the styling to use BEM standards, but must admit that BEM is something that never really felt right for me, not entirely sure why.
I think a large part is because you have to use the fully qualified name in the markup, and so the SASS and component don't read the same. Do you think it might be overkill to add a JS util function to generate BEM class names using the baseClassName as the root? Then both the JS and SASS will be labelling a component as e.g. '__header'. Just a thought, and obviously a larger question than this branch.
Dialog Toggle
I agree that its difficult to reason about.
I tried something a bit different - I tried hiding the dialog toggle button when a view is collapsed. I think its a good solution that has effectively the same behaviour (it prevents going from fully collapsed to dialog) but is clearer for both users and code. It allows the behaviour of the dialog toggle button to be a simple binary toggle. It also has the nice side-effect of minimising the space on collapsed docked views.


docs: Update CODE_OF_CONDUCT.md(email address change)

Run bundle exec jekyll build --trace --baseurl "/blog"
bundle exec jekyll build --trace --baseurl "/blog"
shell: /usr/bin/bash -e {0}
env:
GITHUB_PAGES: true
JEKYLL_ENV: production
JEKYLL_GITHUB_TOKEN:
JEKYLL_LOG_LEVEL: debug
Couldn't load liquid-c. Skipping.
To use retry middleware with Faraday v2.0+, install faraday-retry gem
PluginManager: Required rake, sass, json, github-pages, jekyll-feed, jekyll-gist, jekyll-github-metadata, jekyll-include-cache, jekyll-mentions, jekyll-optional-front-matter, jekyll-paginate, jekyll-readme-index, jekyll-redirect-from, jekyll-seo-tag, jekyll-sitemap, minima
Couldn't load jekyll-docs. Skipping.
Couldn't load jekyll-import. Skipping.
Logging at level: debug
Logging at level: debug
bundler: failed to load command: jekyll (/home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/bin/jekyll)
/opt/hostedtoolcache/Ruby/3.3.4/x64/lib/ruby/3.3.0/psych/parser.rb:62:in _native_parse': (/home/runner/work/blog/blog/_config.yml): did not find expected '-' indicator while parsing a block collection at line 34 column 5 (Psych::SyntaxError) 	from /opt/hostedtoolcache/Ruby/3.3.4/x64/lib/ruby/3.3.0/psych/parser.rb:62:in parse'
from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/safe_yaml-1.0.5/lib/safe_yaml/load.rb:143:in load' 	from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/safe_yaml-1.0.5/lib/safe_yaml/load.rb:157:in block in load_file'
from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/safe_yaml-1.0.5/lib/safe_yaml/load.rb:157:in open' 	from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/safe_yaml-1.0.5/lib/safe_yaml/load.rb:157:in load_file'
from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/jekyll-3.10.0/lib/jekyll/configuration.rb:143:in safe_load_file' 	from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/jekyll-3.10.0/lib/jekyll/configuration.rb:180:in read_config_file'
from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/jekyll-3.10.0/lib/jekyll/configuration.rb:207:in block in read_config_files' 	from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/jekyll-3.10.0/lib/jekyll/configuration.rb:205:in each'
from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/jekyll-3.10.0/lib/jekyll/configuration.rb:205:in read_config_files' 	from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/jekyll-3.10.0/lib/jekyll.rb:113:in configuration'
from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/jekyll-3.10.0/lib/jekyll/command.rb:43:in configuration_from_options' 	from /home/runner/work/blog/blog/vendor/bundle/ruby/3.3.0/gems/jekyll-3.10.0/lib/jekyll/commands/build.rb:29:in process'


ImportError: cannot import name 'ModelFilter' from 'huggingface_hub'

Describe the bug
C:\Users\Username>python
Python 3.10.11 (tags/v3.10.11:7d4cc5a, Apr  5 2023, 00:38:17) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

from huggingface_hub import HfApi, ModelFilter, ModelSearchArguments
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name 'ModelFilter' from 'huggingface_hub' (D:\Program Files\Python\Python310\lib\site-packages\huggingface_hub_init_.py)

Reproduction
C:\Users\Username>pip install --no-cache-dir transformers huggingface-hub -U
Requirement already satisfied: transformers in d:\program files\python\python310\lib\site-packages (4.25.1)
Collecting transformers
Downloading transformers-4.44.1-py3-none-any.whl.metadata (43 kB)
Requirement already satisfied: huggingface-hub in d:\program files\python\python310\lib\site-packages (0.20.3)
Collecting huggingface-hub
Downloading huggingface_hub-0.24.6-py3-none-any.whl.metadata (13 kB)
Requirement already satisfied: filelock in d:\program files\python\python310\lib\site-packages (from transformers) (3.15.4)
Requirement already satisfied: numpy>=1.17 in d:\program files\python\python310\lib\site-packages (from transformers) (1.26.4)
Requirement already satisfied: packaging>=20.0 in d:\program files\python\python310\lib\site-packages (from transformers) (23.2)
Requirement already satisfied: pyyaml>=5.1 in d:\program files\python\python310\lib\site-packages (from transformers) (6.0.2)
Requirement already satisfied: regex!=2019.12.17 in d:\program files\python\python310\lib\site-packages (from transformers) (2024.5.15)
Requirement already satisfied: requests in d:\program files\python\python310\lib\site-packages (from transformers) (2.32.3)
Requirement already satisfied: safetensors>=0.4.1 in d:\program files\python\python310\lib\site-packages (from transformers) (0.4.4)
Collecting tokenizers<0.20,>=0.19 (from transformers)
Downloading tokenizers-0.19.1-cp310-none-win_amd64.whl.metadata (6.9 kB)
Requirement already satisfied: tqdm>=4.27 in d:\program files\python\python310\lib\site-packages (from transformers) (4.66.4)
Requirement already satisfied: fsspec>=2023.5.0 in d:\program files\python\python310\lib\site-packages (from huggingface-hub) (2024.6.1)
Requirement already satisfied: typing-extensions>=<IP_ADDRESS> in d:\program files\python\python310\lib\site-packages (from huggingface-hub) (4.12.2)
Requirement already satisfied: colorama in d:\program files\python\python310\lib\site-packages (from tqdm>=4.27->transformers) (0.4.6)
Requirement already satisfied: charset-normalizer<4,>=2 in d:\program files\python\python310\lib\site-packages (from requests->transformers) (3.3.2)
Requirement already satisfied: idna<4,>=2.5 in d:\program files\python\python310\lib\site-packages (from requests->transformers) (2.10)
Requirement already satisfied: urllib3<3,>=1.21.1 in d:\program files\python\python310\lib\site-packages (from requests->transformers) (1.26.16)
Requirement already satisfied: certifi>=2017.4.17 in d:\program files\python\python310\lib\site-packages (from requests->transformers) (2024.6.2)
Downloading transformers-4.44.1-py3-none-any.whl (9.5 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 9.5/9.5 MB 4.3 MB/s eta 0:00:00
Downloading huggingface_hub-0.24.6-py3-none-any.whl (417 kB)
Downloading tokenizers-0.19.1-cp310-none-win_amd64.whl (2.2 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.2/2.2 MB 4.5 MB/s eta 0:00:00
Installing collected packages: huggingface-hub, tokenizers, transformers
Attempting uninstall: huggingface-hub
Found existing installation: huggingface-hub 0.20.3
Uninstalling huggingface-hub-0.20.3:
Successfully uninstalled huggingface-hub-0.20.3
Attempting uninstall: tokenizers
Found existing installation: tokenizers 0.13.3
Uninstalling tokenizers-0.13.3:
Successfully uninstalled tokenizers-0.13.3
Attempting uninstall: transformers
Found existing installation: transformers 4.25.1
Uninstalling transformers-4.25.1:
Successfully uninstalled transformers-4.25.1
Successfully installed huggingface-hub-0.24.6 tokenizers-0.19.1 transformers-4.44.1
Logs
No response
System info
- huggingface_hub version: 0.24.6
- Platform: Windows-10-10.0.19045-SP0
- Python version: 3.10.11
- Running in iPython ?: No
- Running in notebook ?: No
- Running in Google Colab ?: No
- Token path ?: C:\Users\Username\.cache\huggingface\token
- Has saved token ?: False
- Configured git credential helpers:
- FastAI: N/A
- Tensorflow: N/A
- Torch: 2.3.1+cu121
- Jinja2: 3.1.4
- Graphviz: N/A
- keras: N/A
- Pydot: N/A
- Pillow: 10.3.0
- hf_transfer: N/A
- gradio: N/A
- tensorboard: N/A
- numpy: 1.26.4
- pydantic: 2.7.4
- aiohttp: 3.9.5
- ENDPOINT: https://huggingface.co
- HF_HUB_CACHE: C:\Users\Username\.cache\huggingface\hub
- HF_ASSETS_CACHE: C:\Users\Username\.cache\huggingface\assets
- HF_TOKEN_PATH: C:\Users\Username\.cache\huggingface\token
- HF_HUB_OFFLINE: False
- HF_HUB_DISABLE_TELEMETRY: False
- HF_HUB_DISABLE_PROGRESS_BARS: None
- HF_HUB_DISABLE_SYMLINKS_WARNING: False
- HF_HUB_DISABLE_EXPERIMENTAL_WARNING: False
- HF_HUB_DISABLE_IMPLICIT_TOKEN: False
- HF_HUB_ENABLE_HF_TRANSFER: False
- HF_HUB_ETAG_TIMEOUT: 10
- HF_HUB_DOWNLOAD_TIMEOUT: 10

Hi @phicha20224, ModelFilter has been deprecated in https://github.com/huggingface/huggingface_hub/pull/2028 and removed in the last version of huggingface_hub (0.24.x). What you should do is pass all arguments you were passing to ModelFilter directly to list_models.
Example:
- from huggingface_hub import list_models, ModelFilter
+ from huggingface_hub import list_models

- for model in list_models(filter=ModelFilter(library="keras")):
+ for model in list_models(library="keras"):
    # do something
    ...

This should simplify should code by not relying on other classes


excersises(yacht): add order-independence tests to full-house and four-of-a-kind

Existing code only tested cases when dice in full-house and four-of-a-kind categories would have groups in certain positions when sorted. For example:
3,3,3,3,5 => four of a kind
3,3,3,5,5 => full house

but there were no tests for these cases
3,5,5,5,5 => four of a kind
3,3,5,5,5 => full house

I.e. the cases where group positions and lengths are switched around and a group with smaller number of elements goes first.
I saw several solutions which were hardcoding checks like
if (sorted[0] == sorted[3]) {
  // assume success in detecting four-of a kind
}

which is not correct, because it would fail in the 3,5,5,5,5 case while it shouldn't.
This PR adds a few more tests to check alternative ordering.
Not really sure if the new test case naming is good, a bit too vague, was out of ideas on how to name them correctly while staying compact.

Thanks @dimsuz for the contribution, and for your patience


why do not work chuncked file

hi, my filedownloader.properties
http.lenient=false
process.non-separate=true
download.min-progress-step=65536
download.min-progress-time=2000
download.max-network-thread-count=1
and when create new task :
final BaseDownloadTask task = FileDownloader.getImpl().create(model.getUrl())
.setPath(model.getPath())
.addHeader("ISDMUser64", username)
.addHeader("ISDMHashPassword", password)
.setCallbackProgressTimes(300)
.setMinIntervalUpdateSpeed(400)
.setListener(taskDownloadListener);
my file downloaded with one chunk but i need many chunks
pls help me

chunked resource works well in SingleTaskTestActivity#chunked-files-download-test Demo, you can clone the demo project, and check it out.
If the transfer-encoding is chunked, FileDownloader will fetch the data from the input stream with the 4096byte space buffer again and again until no data left in the input stream.

i can download many chunk in same time? ex download 5 chunk file same time like internet download manager windows application , i can do it with your library?
so Thanks for answer

You can download different resources simultaneously, and the number of it is open configure by: filedownloader.properties#download.max-network-thread-count or FileDownloader#setMaxNetworkThreadCount.

i means  wanna downloading one file from many part in same time ,ex downloading one file with 10 part in same time , i am testing your sample chunked file but in packet capture(android application for show packet) show me one request from your application but in LoaderDriod(download manager application) when select 10 part in packet capture show 10 request from application and download in same time

Oh... Sorry, I misunderstood. For that, you can follow this issue: #102
In current latest version (0.3.4) isn't support such feature.


Bug: Hass.Agent application crashes when using sensors

Please make sure that the issue you're planning to report is not already registered :)

Describe the bug
When I use the HASS.Agent application on Windows 11 then it immediately crashes after loading all the features. I am using the following sensors:
CPU_Load
MemoryUsage
GPULoad
To Reproduce
Steps to reproduce the behavior:

Open HASS.Agent.exe
Wait for the application to load all the features (Home assistant API, MQTT etc)
The application crashes after loading the features.

Expected behavior
The application crashes when all the features are loaded.
Screenshots
N/A
Misc info (please complete the following information):

Windows 11 23H2
Windows' UI language: English (United States)
HASS.Agent version: It both happens in version 2022.14.0 and 2023.11.1-ubeta
My specs are: AMD Radeon RX 7900 XTX, AMD Ryzen 7 5800X, and 32 GB DDR4.

Please check what's applicable (multiple answers possible):

[x] Installed via installer
[ ] Installed manually
[x] Problem occurs in HASS.Agent
[ ] Problem occurs in Satellite Service

Additional context
Add any other context about the problem here.
Logs
[2023-11-15] HASS.Agent_20231115.log

As per our discord discussions, I've checked the code and each of the commands/sensors publish calls are wrapped in try/catch block. I might be missing something here but the fact that application is closing just like that without any error in the logs in at least concerning.
I'd like to ask you to check the Windows event viewer once the application crashes but I know you're currently testing something else, I'll grab you on discord with the details :)

Might be a possible issue with our usage to LibreHardwareMonitor.
Buthchbear22 is able to use the stock LHM GUI app without crash whilst there is possible crash point in the sensor:

Fixed in https://github.com/hass-agent/HASS.Agent/releases/tag/2.0.0


Conversation with agent with finetuned model

name: Pull Request
about: Create a pull request
Description
moved conversation_with_agent_with_finetuned_model to a separate branch from main to keep it consistent with the official repo
Checklist
Please check the following items before code is ready to be reviewed.

[x]  Code has passed all tests
[x]  Docstrings have been added/updated in Google Style
[x]  Documentation has been updated
[x]  Code is ready for review

Further update of https://github.com/modelscope/agentscope/pull/169 is move here.


Surveys Page

[ ] Surveys index should display sample charts of questions completed by other participants (see image)

[ ] You should be able to see the "Surveys" index page without logging in.

Providers/researchers can see aggregate data with sample surveys, while users can see their survey progress
Currently with 5.0 you are unable to see surveys index page without logging in, is it necessary to see?

This is an older design, we'll recreate a new issue if we need new design directions in the future.


Email names with numbers in them don't pass validation

email names with numbers in them, like my own, fail validation because in parse.validate_email the numbers aren't included in the allowed chars.

closed by #28


Remove the "2" from the name?

We should do this.

Agreed. Need to figure out a name that doesn't conflict.

Maybe we add the memory fallback and make it more generic client side storage


[LiveComponent] Fix calculateFingerprint with big objects

Q
A

Bug fix?
yes

New feature?
no

Tickets
N/A

License
MIT

This pull request will fix an issue for large objects (for example entities with a large relations) with in the FingerprintCalculator
While working with liveComponents I noticed my project getting slower and slower. After some digging I found out that in the calculateFingerprint function the data is serialized. When an entity with relations passes by it will serialize the entity and its child objects. This takes a considerable amount of time and is not needed.

I'm having the same issue.

Great catch on this!
These fingerprints need to be a deterministic string that represents "the input passed into a component" - https://github.com/symfony/ux/blob/e45a8edfcd6d6ab62248d1ffe42ef13e9dcc11b3/src/LiveComponent/src/Util/LiveControllerAttributesCreator.php#L68 - and they need to always return the same string for the same input.
If you pass an object (e.g. a Post entity) into a component, the spl_object_id() of that might be different the next time the component is re-rendered via an Ajax call, right?
I'm open to ideas on how to fix this. In practice, if we added some special code for entity objects that, if persisted, used their id instead of serializing them, that might solve things. For example, if one of the items in $data is a Post entity, then instead of serializing that or spl_object_id(), we use App\Entity\Post:{THE_ID}.

These fingerprints need to be a deterministic string that represents

Oops, didn't realize this. Could spl_object_hash() be used? I don't know if this would still have a perf problem.

You're right. From php.net:

When an object is destroyed, its hash may be reused for other objects.

These fingerprints need to be a deterministic string that represents "the input passed into a component" -

We should have a test to prove this behaviour.

Perhaps it's an idea to add if (\is_object($value) && method_exists($value, 'getId')) {                 return $value->getId();             } instead of \is_object($value).

Using objectNormalizer greatly improves the performance over just serializing the object.

Let's give this version a try - thanks @LunkLoafGrumble!

FYI - I'm reverting this in #832. But I'm hoping that it's not a problem anymore because usually zero LiveProps are used to calculate the fingerprint. But please tell me if you still have issues.


Slow performance at box selection example

Describe the bug
Clicking on any feature causes lag. Text on "Selected regions" and style of features takes too long to being update after the click.
A screenshot of chrome performance tab on the click time

To Reproduce
Steps to reproduce the behavior:

Open 'box selection example'
Click on any feature
See the lag

I was also be able to reproduce locally on versions 7.1.0 and 7.1.1-dev.1668701704879
Expected behavior
No lag :)

For an immediate response in a Select interaction you need condition: click.  The default condition: singleClick has a 250ms delay to ensure it is not the first of a double click.

For an immediate response in a Select interaction you need condition: click. The default condition: singleClick has a 250ms delay to ensure it is not the first of a double click.

Unfortunately this not solves the problem. I have tested with both conditions. Also.. the delay is between 1 and 1.5 seconds.
The crazy thing is that select hover features example has no delay.

How does that compare with the Select Features example https://openlayers.org/en/latest/examples/select-features.html with Hover action type selected?

How does that compare with the Select Features example https://openlayers.org/en/latest/examples/select-features.html with Hover action type selected?

I got confused the "condition" with "toggleCondition". With condition click I was able to have no delay.
Very thanks!


rebase on remote

this PR is created as a prerequisite for the traverse feature. #1230 got closed automatically by GitHub.

Hmmm okay so a high-level question... why is that a prerequisite for traverse? 🤔 will traverse, instead of using the existing rebase logic (i.e. onto parent, taking commits from after fork point) use the logic of rebasing onto remote tracking branch instead?

Okay... I see that within #1235, Rebase on Remote is suggested for branches that are diverged from their remote, right? 🤔 in general, git-machete suggests either:

git push --force, if local branch points to newer commit than remote or
git reset --keep <remote-branch>, if local branch points to older commit than remote

Generally, offering rebase onto remote as a third option would be viable... but I'd rather keep git-machete as opinionated as possible wrt. what's suggested to users.
In fact, it'd best to first analyze the sequence of events that might lead to a situation where a user wants to rebase their local branch onto its remote counterpart... esp. who's the original author of that branch? who's the last person to push commits to that branch?

sequence of events that might lead to a situation where a user wants to rebase their local branch onto its remote counterpart

committing some reviews on the remote branch, then also committing some fixes or a half feature I was working on locally.

As we have discussed it somewhere - rebase on remote is not required for traverse it; it's also not a priority now then
As we have discussed it somewhere (@zmerr finding) - rebase on remote is implemented by git4idea - possibly we could re-use it
these changes are outdated now

closing! 📕


Aliases to native types in not-entirely-native modules

If, in a module that is not entirely native, I try to make an alias involving a type that is native, this results in an error:
import ceylon.math.whole { Whole }
alias MyWholeNumber=>Integer|Whole; // error: illegal reference to native declaration 'Whole': declaration 'MyWholeNumber' is not native (mark it or the module native)

However, under the current compiler, aliases can't be marked native:
native("jvm") alias MyWholeNumber=>Integer|Whole // error: native declaration is not a class, constructor, method, attribute or object: 'MyWholeNumber' may not be annotated 'native'

I would like to be able to make an alias involving native types without marking the whole module as native. But at a minimum, I think the first error message should not suggest marking the alias declaration as native.
(ceylon --version reports ceylon version 1.3.3 0d594b3 (Contents May Differ).)

.. or allow marking aliases native?

@kingjon3377 I guess I see the problem but I should point out that in this particular case, you can solve it by using the module ceylon.whole instead of the deprecated module ceylon.math.
@xkr47

allow marking aliases native?

Yes, that would be a more correct solution to the general problem.

I've opened #7373, and pushed an implementation. The requested feature is now available on master.


(Potentially) remove processer_bind.h

Most of the processor_bind.h files are in a state where they can be removed, leaving only base.h. The question is whether we would have a need, in the future, for processor-specific files. libspdm/library/ and its headers are processor agnostic, as is most of libspdm/os_stub/. Hopefully we'll never write any assembly language, although if we did it would probably go under libspdm/os_stub/ or a new libspdm/arch/ directory. Additionally processor-specific #defines can be defined via the makefiles / compiler.
We do have the "OpenSSL on Windows" issue in ia32 and x64 that would need to be resolved: https://github.com/DMTF/libspdm/blob/acf5e97f41279fdeaaf25f61c7bfc68dd8bfef46/include/hal/x64/processor_bind.h#L101-L124

@steven-bellock will make a proposal.

@steven-bellock , may I know if you have plan to implement this?
We are going to add new arch, if there is no plan to remove arch dir.


Support cc as an optional alternative to cmake

While compiling another project I noticed I was not able to cross compile to x86_64-pc-windows-msvc, due to cmake. We've banned cmake in our projects both because it (generally speaking) complicates/makes impossible cross compilation, as well as just adding another dependency/point of failure/hindrance to contributions.
This is mainly a straight forward port of the cmake script(s) to cc but with one important difference, namely that target features are now respected.
With cmake, zlib-ng is probing the compiler/target headers for intrinsics/features/definitions, and importantly, can enable features irrespective of the target/features supplied to cargo/rustc. For example, cargo build --features zlib-ng --target x86_64-unknown-linux-gnu on my current machine will enable avx2, sse2, sse3, sse4.2, pclmulqdq, xsave, avx512, and vpclmulqdq, despite the only target features enabled by default for that target being fxsr, sse, and  sse2.
With the change to cc, I made it so that the target features selected by the user are what are actually respected, instead of generating binaries that won't work on CPUs without 1 or more features that the machine the binary was built on did have.
The one caveat to this is that avx512 target features are not currently stable in rustc, so I've added an additional feature that needs to be enabled for those features to be probed for, but maybe there is a more elegant way to support that in a way that makes sense to the end user.
I also didn't port the powerpc, s390, or riscv related optimization features since this PR is already quite large, but it should be trivial to add support in subsequent PRs.

Thanks so much for tackling this! I agree that less cmake will be better for everyone.
Previously it was my understanding that zlib-ng ships with cmake as build system, and superseding it with an own implementation also means it needs to be maintained here.
For that reason I definitely won't be merging this PR without explicit support from the libs team, and I think it would be easiest to use their channel to probe for additional opinions.
(I also converted the PR into a draft while CI is failing)

With cmake, zlib-ng is probing the compiler/target headers for intrinsics/features/definitions, and importantly, can enable features irrespective of the target/features supplied to cargo/rustc. For example, cargo build --features zlib-ng --target x86_64-unknown-linux-gnu on my current machine will enable avx2, sse2, sse3, sse4.2, pclmulqdq, xsave, avx512, and vpclmulqdq, despite the only target features enabled by default for that target being fxsr, sse, and  sse2.

I see, that's probably why after upgrading libz-ng to latest release break our cargo-binstall cross compilation on aarch64 linux.
We use cargo-zigbuild for cross compilation and it was working until libz-ng is upgraded https://github.com/rust-cross/cargo-zigbuild/issues/210

With cmake, zlib-ng is probing the compiler/target headers for intrinsics/features/definitions, and importantly, can enable features irrespective of the target/features supplied to cargo/rustc. For example, cargo build --features zlib-ng --target x86_64-unknown-linux-gnu on my current machine will enable avx2, sse2, sse3, sse4.2, pclmulqdq, xsave, avx512, and vpclmulqdq, despite the only target features enabled by default for that target being fxsr, sse, and sse2.

zlib-ng should only be doing that if given WITH_NATIVE_INSTRUCTIONS; otherwise, it should be using runtime detection, which uses these intrinsics but only after checking the CPU capabilities at runtime. If it's using features from the host CPU in any other circumstance, that's absolutely a bug.

zlib-ng should only be doing that if given WITH_NATIVE_INSTRUCTIONS; otherwise, it should be using runtime detection, which uses these intrinsics but only after checking the CPU capabilities at runtime. If it's using features from the host CPU in any other circumstance, that's absolutely a bug.

Yes, I was wrong about this, the probing for intrinsics just adds the source files and appropriate compiler flags if the compiler supports them, the runtime detection will only use them if the host CPU supports them.
I think if this PR would otherwise be accepted I can change the code to just do what zlib-ng does and enable all the source files/flags supported by the C compiler rather than relying on the target features to be enabled in rustc, but I'm not going to spend more time on this PR unless it's indicated it would be merged barring that change.

Is there any chance of getting a review on this? I'd rather close this than have it sitting.

@Jake-Shadle I'd recommend you to open a new topic in zulip channel https://rust-lang.zulipchat.com/#narrow/stream/351149-t-libs.2Fcrates and cc those who works in libz-ng

This would be amazing, as I would love to use this library for https://github.com/wcampbell0x2a/backhand/pulls, but don't want cmake in my build system.

I would love to see this happen, but also, this seems like a massive increase in complexity and maintenance burden for this crate, to duplicate the build system of upstream.
Is there any chance we could get upstream zlib-ng to add support for a non-cmake build system and then use that, so that we don't have to effectively rewrite their build system downstream and then maintain that rewrite as upstream's build system continues to change in the future?

Other than the *.in file transformations, all of the complexity in the build script beyond what a normal project has is simply due to the compiler probing for features and headers. IMO this is incredibly over conservative in an attempt to support really old compilers or "esoteric" targets that are already supported by vanilla zlib.
The easiest way to reduce complexity would just be to remove all of the probing and just....turn on everything for the target. If the user is using an extremely old compiler or targeting something that doesn't support all of the features, they can either 1. special case the build script to remove the specific feature(s) not supported by their concrete use-case 2. disable the zlib-ng feature to just use vanilla zlib instead. The build script could also just detect the failure and fallback to zlib automatically and print a warning about it, but generally I find a hard error to let the user know something went wrong is better so that they can either fix it or workaround it.

Is there any chance we could get upstream zlib-ng to add support for a non-cmake build system and then use that, so that we don't have to effectively rewrite their build system downstream and then maintain that rewrite as upstream's build system continues to change in the future?
What would that be though? I don't see what reason they would have to support another one for a single downstream project.

If the user is using an extremely old compiler or targeting something that doesn't support all of the features

IMO adding environment variable for these features make more sense

all of the complexity in the build script beyond what a normal project has is simply due to the compiler probing for features and headers

That's not the only complexity or maintenance burden here. There's also the list of files (needs updating every time zlib-ng adds a new source file), and the list of symbols to define (needs updating every time zlib-ng's build system adds a new such symbol).
I'm not saying we shouldn't consider doing this. I'm observing that if we do, we change the maintenance burden from "upgrade to new upstream version of zlib-ng and make sure tests pass" to "upgrade to new upstream version of zlib-ng, audit the build system to see if they've added any new symbols, and port any logic needed to set those symbols".

The easiest way to reduce complexity would just be to remove all of the probing and just....turn on everything for the target.

Defaulting to building zlib-ng in "probe for everything you know about at runtime" mode does seem like the right answer, particularly if it simplifies the build logic; if people want to hard-enable or hard-disable any features, or probe at compile time, perhaps we could control the use of cmake versus the non-cmake simplified build system via feature flags.

I don't see what reason they would have to support another one for a single downstream project.

The same reason this project would consider doing so: to try to help their users who don't want to add a cmake dependency, at the expense of taking on additional complexity. The difference is that zlib-ng is better positioned to manage that complexity than we are.
I know at least one project that's considering a build system rewrite away from cmake for the exact same reason: aws-lc.

That's not the only complexity or maintenance burden here. There's also the list of files (needs updating every time zlib-ng adds a new source file), and the list of symbols to define (needs updating every time zlib-ng's build system adds a new such symbol).

I'm not saying we shouldn't consider doing this. I'm observing that if we do, we change the maintenance burden from "upgrade to new upstream version of zlib-ng and make sure tests pass" to "upgrade to new upstream version of zlib-ng, audit the build system to see if they've added any new symbols, and port any logic needed to set those symbols".

That's the normal amount of burden that any cc-based build script needs to do, looking at zlib-ng history there does seem to be more churn wrt build system affecting file/etc changes compared to the typical C project, but not to a degree that would make version upgrades take a significant longer period of time barring large version updates or a too long period of not updating.

Defaulting to building zlib-ng in "probe for everything you know about at runtime" mode does seem like the right answer, particularly if it simplifies the build logic; if people want to hard-enable or hard-disable any features, or probe at compile time, perhaps we could control the use of cmake versus the non-cmake simplified build system via feature flags.

I think that's a reasonable compromise, that way if the simpler cc-based build fails the error can tell them to turn on the cmake feature to do the probing to support their limited environment/target but most won't need to do that.

The same reason this project would consider doing so: to try to help their users who don't want to add a cmake dependency, at the expense of taking on additional complexity. The difference is that zlib-ng is better positioned to manage that complexity than we are.

They support regular make, presumably for those who don't want to use cmake, I just am not aware of any other build systems in the C space that don't add external dependencies (python, lua, etc) or are platform specific (bash scripts, vcxproj etc) that one would have any hope of proposing to them.

Defaulting to building zlib-ng in "probe for everything you know about at runtime" mode does seem like the right answer, particularly if it simplifies the build logic; if people want to hard-enable or hard-disable any features, or probe at compile time, perhaps we could control the use of cmake versus the non-cmake simplified build system via feature flags.

I think that's a reasonable compromise, that way if the simpler cc-based build fails the error can tell them to turn on the cmake feature to do the probing to support their limited environment/target but most won't need to do that.

The above part of the conversation gave me an idea I want to share, right after sharing my disposition about this: I feel strongly about not wanting to chase zlib-ng build system changes to the point where I wont hit the merge button for that reason alone. However, I also wouldn't oppose to somebody else doing it.
With this basis, something that would work under such circumstances is the addition of a cargo feature that uses this build system instead of the default one. I would even mark it with use-alternative-build-system-alpha to indicate it's early and unstable and may not even be working unless it's kept working by the people who are using it.
That way the maintenance burden is shifted to contributors and there are no guarantees that it keeps working, which allows us to learn what it means to have it and maybe maintain it. Something I can imagine will happen is that as the build system gets patched to support upstream changes, I see and learn how to do that, maybe realising that it is indeed very doable which would ease the transition to being maintained here as well. Something that could also happen is the 'devil in the detail' which shows it's much less feasible, leading to its removal. But that way we could at least find out as this feature is without any doubt valuable and should be considered.

I've now split it so that cmake and cc are supported in parallel, cmake with the regular zlib-ng feature and cc with zlib-ng-no-cmake that way all of the crates that currently use zlib-ng will continue working as before, but crates that don't want to use cmake can expose a feature flag to use the non-cmake feature instead.
The code is much more simple now and no longer does intrinsic/header detection, and rather just turns on all reasonable features. Amusingly, this means that several linux-gnu targets are skipped when building without cmake in CI due to those targets using an ancient (almost 8 years old) version of GCC that doesn't support some AVX-512 flags.

Just a heads up that this requires a rebase.

I just encountered this as well. We have a project with well-documented instructions for building from source and upgrading zip2 (which in turn pulled in libz-ng-sys) would break all of our downstream users by now requiring CMake.

I'm going to close this since it doesn't appear it will be merged, I'll leave the fork up for now in case someone wants to carry if forward, or just use it for reference or something.

If you still have time I think it would be good to click open once more because I think there is desire for this to be merged but the rebase happened only a few days ago to resolve the conflicts. I and a few others I know of have a great need for this so it would be nice to give the maintainers a little bit more time to review, please 🙏

I understand your perspective, thanks. It's a bummer that so many folks will not use ng/the best implementation because of CMake. I don't have time unfortunately or else I would do this myself.

I'd be happy to have this merged, was just closing PRs and issues in my backlog that didn't seem to be going anywhere.

Great to hear! If a release is desired, I'd need a PR with the version change as I don't think I can merge my own PRs.

Is there no way to use this new option with cross? https://github.com/ofek/pyapp/pull/137
I'm guessing the images cross uses have very old compiler versions?


Isolate feed builds

Right now, if one feed fails, the entire process fails.  Either in the Makefile or GitHub Actions, this should be set up so that we are alerted that feed fails, but the remaining feeds continue.

This has been partially addressed in #73 by separating the builds into separate steps, but a single failing check on one of the other steps could make this one fail as well.
In #62 I created the EXIT_STATUS environment variable such that failures in our lesson data could be caught and sent up to us. In that PR, I added a fine-grain catch for a specific edge case because I knew the data would go through fine and what the fix was.
In #73, I added a catch for that particular process by using the || BASH operator to shortcut in case of an error, recording to EXIT_STATUS and moving on.
We could do the same for the other processes, but it might be a good idea to have all of these processes set EXIT_STATUS + 1 for each failure so that we know how many processes fail by the status number.


how to transform a  WMS/WFS iso19139 transferoption to record.geojson?

Description
Following the discussion at https://github.com/opengeospatial/ogcapi-records/issues/95, to capture enough detail on a association in record.geojson so a client is able to bind to the service advertised, we need some mapping from for example the iso19139 transfer-options model to a template+variables structure as suggested in record.geojson.
iso
<gmd:MD_DigitalTransferOptions>
          <gmd:onLine>
            <gmd:CI_OnlineResource>
              <gmd:linkage>
                <gmd:URL>https://service.pdok.nl/hwh/wsdiensteninspire/wms/v1_0?service=wms&request=getcapabilities</gmd:URL>
              </gmd:linkage>
              <gmd:protocol>
                <gmx:Anchor xlink:href="http://www.opengis.net/def/serviceType/ogc/wms">OGC:WMS</gmx:Anchor>
              </gmd:protocol>
              <gmd:name>
                <gco:CharacterString>kabel</gco:CharacterString>
              </gmd:name>
              <gmd:description>
                <gmx:Anchor xlink:href="http://inspire.ec.europa.eu/metadata-codelist/OnLineDescriptionCode/accessPoint">accessPoint</gmx:Anchor>
              </gmd:description>
            </gmd:CI_OnlineResource>
          </gmd:onLine>

record geojson
{
   "rel": "map",
   "type": "image/png",
   "title": "Ozone map",
   "href": "https://geo.woudc.org/ows?service=WMS&version=1.3.0&request=GetMap&crs={crs}&bbox={bbox}&layers=totalozone&width={width}&height={height}&format=image/png",
   "templated": true,
   "variables": {
      "crs": {
         "description": "...",
         "type": "string",
         "enum": [ "EPSG:4326", "EPSG:3857" ]
      },
      "bbox": {
         "description": "...",
         "type": "array",
         "items": {
            "type": "number",
            "format": "double"
         },
         "minItems": 4,
         "maxItems": 4
      },
      "width": {
         "description": "...",
         "type": "number",
         "format": "integer",
         "minimum": 600,
         "maximum": 5000
      },
      "height": {
         "description": "...",
         "type": "number",
         "format": "integer",
         "minimum": 600,
         "maximum": 5000
      }
   }
}

In general clients like qgis/openlayers will know how to interact with a wms, so i'm a bit reluctant to capture the full structure of a wms getmap into the record. A minimal requirement though is to capture the fact that the endpoint is a WMS and the relevant layer(s) at that endpoint. For which the current spec does not provide guidance. what do people think?

Thinking out loud: one approach could be to add the appropriate binding information to the links column in pycsw (which is a JSON) when ingesting an ISO document and then generate accordingly from .../items or .../items/{itemId}.  Thoughts?


tests: showcase verdict output for drops and alerts in tests - v4

Previous PR: https://github.com/OISF/suricata-verify/pull/1308
Changes from previous PR:

check for libnet 1.1 for tests with reject rules
rebase

Ticket
Redmine ticket:
https://redmine.openinfosecfoundation.org/issues/5464

Suri PR https://github.com/OISF/suricata/pull/9220


How to debug the front-end code locally ？

Hello.
I am currently using your repository for local development. It really works very well and I appreciate it.
But at the moment I have a question, how do you debug the front-end code locally (especially js part as well as html etc) By building a separate http server, which is possible. But I don't know if it is already supported inside your code?
I would be grateful if I could get an answer from you.

I rely a lot on Chrome's devtools. Under the Sources tab you can find the typescript files and set breakpoints and everything.

https://github.com/sorenisanerd/gotty/wiki/Developing-GoTTY


modsec collection is inconsistent

https://hub.crowdsec.net/author/crowdsecurity/collections/modsecurity is inconsistent, as it refers twice the parser and doesn't refer the scenario
the APACHEERRORPREFIX and MODSECAPACHEERROR seems to have some mistakes as well according to https://github.com/crowdsecurity/crowdsec/pull/349

fixed


Add installation notes to README

Perhaps I'm unforgivably naive? Or blind? I just read the README for the global_search function, and love this. Just what I want. And I see there's a .sql file, great, and I use pgadmin a lot, and work with postgres a fair bit, but still feel rather clueless as to how to make this function available ... so that I can SELECT * FROM global_search('Foo');.
Now yes, I know, I searched on-line I did some reading, and yep, just ran the SQL and can see the function in pgadmin in my database and selected from it! It all worked. But I hope it's not deemed presumptuous, naive, or stupid of me my postgresql pros who assemble such functions, but yep a short note for orientation on how to make the function available to you (aka install it) would to my mind be useful and welcome. And yes, you can validly argue that this is presumed knowledge and close this and ignore it, or take the feedback as it stands that yep, even a moderately experienced postgres user has a moment when they first encounter "functions" I guess.

Thanks for your feedback! You're right that in this repository of code with its short READMEs, how to create the functions is presumed to be known. But I'll take your point that it's not necessarily true for all users and will add a few explanations.


oci-seccomp-bpf-hook: 1.2.0 -> 1.2.1

Motivation for this change
Update to the latest release.
cc @NixOS/podman
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Commit message should be linuxPackages.oci-seccomp-bpf-hook: 1.2.0 -> 1.2.1

Commit message should be linuxPackages.oci-seccomp-bpf-hook: 1.2.0 -> 1.2.1

Commit message should be linuxPackages.oci-seccomp-bpf-hook: 1.2.0 -> 1.2.1

Fixed as suggested :+1:

Commit message should be linuxPackages.oci-seccomp-bpf-hook: 1.2.0 -> 1.2.1

Fixed as suggested :+1:

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 110931 run on x86_64-linux 1

1 package failed to build and are new build failure:

linuxPackages-libre.oci-seccomp-bpf-hook: log was empty

12 packages built:

linuxPackages.oci-seccomp-bpf-hook
linuxPackages_5_10.oci-seccomp-bpf-hook
linuxPackages_hardened.oci-seccomp-bpf-hook
linuxPackages_latest-libre.oci-seccomp-bpf-hook
linuxPackages_latest_hardened.oci-seccomp-bpf-hook
linuxPackages_latest_xen_dom0.oci-seccomp-bpf-hook
linuxPackages_latest_xen_dom0_hardened.oci-seccomp-bpf-hook
linuxPackages_lqx.oci-seccomp-bpf-hook
linuxPackages_testing_bcachefs.oci-seccomp-bpf-hook
linuxPackages_xen_dom0.oci-seccomp-bpf-hook
linuxPackages_xen_dom0_hardened.oci-seccomp-bpf-hook
linuxPackages_zen.oci-seccomp-bpf-hook

This is a semi-automatic executed nixpkgs-review which is checked by a human on a best effort basis and does not build all packages (e.g. lumo, tensorflow or pytorch).
If you have any questions or problems please reach out to SuperSandro2000 on IRC.
Result of nixpkgs-review pr 110931 run on x86_64-linux 1

1 package failed to build and are new build failure:

linuxPackages-libre.oci-seccomp-bpf-hook: log was empty

12 packages built:

linuxPackages.oci-seccomp-bpf-hook
linuxPackages_5_10.oci-seccomp-bpf-hook
linuxPackages_hardened.oci-seccomp-bpf-hook
linuxPackages_latest-libre.oci-seccomp-bpf-hook
linuxPackages_latest_hardened.oci-seccomp-bpf-hook
linuxPackages_latest_xen_dom0.oci-seccomp-bpf-hook
linuxPackages_latest_xen_dom0_hardened.oci-seccomp-bpf-hook
linuxPackages_lqx.oci-seccomp-bpf-hook
linuxPackages_testing_bcachefs.oci-seccomp-bpf-hook
linuxPackages_xen_dom0.oci-seccomp-bpf-hook
linuxPackages_xen_dom0_hardened.oci-seccomp-bpf-hook
linuxPackages_zen.oci-seccomp-bpf-hook


rocksdb: reduce rocksdb block size to 16KB

Signed-off-by: Qi Xu<EMAIL_ADDRESS>
What is changed and how it works?

Issue Number: Close #14052
What's Changed:

The writecf and defaultcf's default block size is changed to 16KB to improve read performance (reduce read amplification)

Related changes

PR to update pingcap/docs/pingcap/docs-cn:
Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test
Manual test (add detailed scripts or steps below)
No code

Side effects

Performance regression

Consumes more IOPS

Breaking backward compatibility

Release note
Change the default value of rocksdb's defaultcf and write fc's SST block size from 64KB to 16KB.
This change can improve read performance by reducing read amplification and improve the block cache utilization, at the cost of needing more IOPS. It's estimated to have 1.4 times IOPS of the original setting.

Any test report?

Any test report?
The multi-rocksdb and single-rocksdb tpcc result is the proof.

Sysbench point-select and read-only would be more persuasive (with small and large memory). Also this change would require updating dataset for benchbot etc.

QPS comparison
block-size | 4KB | 8KB | 16KB | 32KB | 48KB | 64KB | 128KB | 256KB
point_select | 18610.19 | 18510.92 | 18342.34 | 18397.36 | 18630.23 | 17708.04 | 15059.51 | 13280.67
read_only | 676.23 | 673.76 | 680.13 | 666.84 | 656.87 | 668.61 | 601.21 | 625.11
update_index | 1213.41 | 1293.45 | 1281.39 | 1284.23 | 1311.48 | 1277.53 | 1206.97 | 1145.58
insert | 1442.53 | 1415.76 | 1448.68 | 1480.1 | 1461.75 | 1429.91 | 1426.27 | 1377.59
read_write | 438.4 | 429.78 | 440.78 | 436.18 | 440.02 | 429.25 | 420.08 | 400.91
From TPS perspective, it's roughly same.
But the key is read amplification, in point select, the 16KB block size is only have 5.7x read amplification and the 64KB has 12.1 read amplification.  This will greatly improve the multiple index lookup scenario where TiDB's performance is not outstanding.

/run-build

/test

/test

/test

/test

/merge


esprima master dependency

Hi JSHint is failing due to an error in esprima that is bubbled up from (i believe) here since you're tracking the master branch.. Can you please revert esprima version to a stable branch if possible
https://github.com/jquery/esprima/issues/1239

turned out to be jshint


Potential Improvements for UP-TCK

Refactor Test Manager

Improve Readability and Modularity:

Current Python files under the test manager are too large.
Separate files based on their functionality.

Configuration Management:

Use a configuration file for constants.

Input Handling:

Use a context map with uE keys for function inputs in the create_command function (this approach might be beneficial for other functions as well).

Logging:

Add individual log files for process logs to facilitate debugging.

User Interface for Running Tests

Use a JSON configuration file to provide a user-friendly interface for running tests, instead of relying on a bash script.

Continuous Integration (CI)

Update the CI process to mirror the local user setup and execution process as closely as possible, ensuring consistency between development and production environments.

Additional items:
Add check to tck_step to make sure transport with default URI have been assigned and success status  from test agent before starting test


chore: Update example app to use Expo 48.

Motivation
Expo 48  is now available and in order to stay ahead of the curve this pull request updates the example app to use the latest SDK. We can and should consider updating the library dependencies to RN 71+, but we can save that for another pull request.
Note: It also contains the same small fix in https://github.com/web-ridge/react-native-paper-dates/pull/262, which you can see for more details.

[x] Followed the upgrade instructions from the Expo team.

Great!! 👌🏻👌🏻


Add better logging to configuration file log messages

Old code only recorded that we hit an error but provided no clarity on
what the problem might be. This change ensures that we show the error as
well since it may contain vital info on what the problem might be.
What ticket does this PR close?
Connected to #1062
Where should the reviewer start?
Jenkins Build
What is the status of the manual tests?
Have you run the following manual tests to verify existing functionality continues to function as expected?

[ ] Manually tested Keychain provider
[ ] Manually run Kubernetes-Conjur demo with a local Secretless Broker image build of your branch

If this feature does not have any/sufficent automated tests, have you created/updated a folder in test/manual that includes:

[ ] An updated README with instructions on how to manually test this feature
[ ] Utility start and stop scripts to spin up and tear down the test environments
[ ] A test script to run some basic manual tests (optional; if does not exist, the README should have detailed instructions)

Links to open issues for related automated integration and unit tests
Links to open issues for related documentation (in READMEs, docs, etc)
Screenshots (if appropriate)

Thanks @diverdane!
Re other error messages:

The first two errors bubble up to a fatal error here: https://github.com/cyberark/secretless-broker/blob/2f16c4062b33b45e6cd70461f95eab038c5a8634/bin/juxtaposer/main.go#L310
The third one probably should have an issue created for it


[stable/gocd] Add support for SSH keys on server and agent (New PR Cr…

This PR contains changes done in PR #4270 originally raised by @or1can inorder to add support for setting SSH keys on the gocd server and agent. Creating a new PR as PR #4270 ran into some commit issues and it would be super useful for many to get these changes merged at the earliest.

/ok-to-test

Hello @Dilip-Nandakumar -- would you mind updating the changelog too?

@GaneshSPatil But the ssh key support only works if you have helm install done with agent replica count set to 'n' as follows
$ helm install --name gocd --namespace gocd --set agent.security.ssh.enabled=true,server.security.ssh.enabled=true,agent.replicaCount=2 ./gocd

Inorder for elastic gocd agent to work i had to create a new elastic agent profile with the pod definition as follows
apiVersion: v1
kind: Pod
metadata:
  name: pod-name-prefix-{{ POD_POSTFIX }}
  labels:
    app: web
spec:
  volumes:
    - name: ssh-secrets
      secret:
        secretName: gocd-ssh
  containers:
    - name: gocd-agent-container-{{ CONTAINER_POSTFIX }}
      image: {{ GOCD_AGENT_IMAGE }}:{{ LATEST_VERSION }}
      securityContext:
        privileged: true
      volumeMounts:
        - name: ssh-secrets
          readOnly: true
          mountPath: /home/go/.ssh

Is there any other way ?

@Dilip-Nandakumar -- For elastic agents, defining the volume mounts as part elastic profiles is the preferred way.

Can you take a look at failing build? and also rebase the PR?

@GaneshSPatil @bdpiparva Fixed build issues and rebased the PR.

/lgtm


xarray.rolling_window Converts dims Argument from Tuple to List Causing Issues for Cupy-Xarray

What is your issue?
Hello,
I'm currently working on the development of cupy_xarray, and I've come across an issue with xarray.rolling_window. Specifically, it seems that the dims argument gets automatically converted to a list from a tuple.
While numpy.normalize_axis_tuple can handle lists, thereby not raising errors when using numpy-backed xarray objects, its cupy equivalent (cupy.core.internal._normalize_axis_indices) does not. When a list is passed, it raises the following error:
File cupy/core/internal.pyx:424, in cupy.core.internal._normalize_axis_indices()
TypeError: 'list' object cannot be interpreted as an integer.

It seems the line that might fix this is L2487:
https://github.com/pydata/xarray/blob/c9d89e2b51b6dfee34e371a9232024ec45cd2d9c/xarray/core/variable.py#L2487-L2494
For the time being, we've managed to devise a workaround in cupy, but I thought it would be worthwhile to bring this to your attention.
Relevant Cupy PR: https://github.com/cupy/cupy/pull/7575
Contributor: @dcherian

This seems like a real easy fix?
axis = tuple(self.get_axis_num(d) for d in dim)

I think the only other one is dask, which should also work.

@negin513 would you mind creating a PR for this?

@headtr1ck Thanks. I created the corresponding PR for this : https://github.com/pydata/xarray/pull/7938


create loading state

@avirankatz wasn't this issue fixed?

Yes, we did push a fix. Let's discuss this today.


Additional API for World Management

Add methods to delete an unloaded World, as well as a method to retrieve the folder for a World.

Seems about right, thanks.


Issue on page /generated/xarray.open_rasterio.html

After some modifications I would like to write my xarray back to tif. However I couldn't find xarray.write_rasterio. What is the recommended way to go here?

have a look at rioxarray, especially Dataset.rio.to_raster, for this. If that's not what you're looking for, or if you need help with it, I would try asking on their issue tracker / discussions.


Problem getting user speed

💬 Questions and Help
I'm struggling to get the user speed.
double velocity = 0;

  @override
  void initState() {

    _determinePosition(); //just for authorisations

    Geolocator.getPositionStream(
        locationSettings: const LocationSettings(
      accuracy: LocationAccuracy.bestForNavigation,
      //distanceFilter: 0,
    )).listen((Position position) {
      _onAccelerate(position);
    });

    super.initState();
  }

void _onAccelerate(Position position) {
    setState(() {
      velocity = position.speed;
    });
  }

Future<Position> _determinePosition() async {
    bool serviceEnabled;
    LocationPermission permission;

    serviceEnabled = await Geolocator.isLocationServiceEnabled();
    if (!serviceEnabled) {
      // not enabled
      return Future.error('Location services are disabled.');
    }

    permission = await Geolocator.checkPermission();
    if (permission == LocationPermission.denied) {
      permission = await Geolocator.requestPermission();
      if (permission == LocationPermission.denied) {
        // denied
        return Future.error('Location permissions are denied');
      }
    }

    if (permission == LocationPermission.deniedForever) {
      // Permissions are denied forever, handle appropriately.
      return Future.error(
          'Location permissions are permanently denied, we cannot request permissions.');
    }

    return await Geolocator.getCurrentPosition(
        desiredAccuracy: LocationAccuracy.bestForNavigation);
  }

-1 km/h is not fast...

Hi @SwiftyFlow,
On which platform (Android, iOS, macOS, web or Windows) are you experiencing this problem?

I managed to go at 4.50km/h!
Future _getSpeed() async {
await Geolocator.requestPermission();
final LocationSettings settings = _createLocationSettings();

while (_running) {
  await Future<void>.delayed(const Duration(milliseconds: 1000));
  Geolocator.getPositionStream(locationSettings: settings).listen(
    (Position position) {
      print('Received position: $position');

      if (position.speed.isNegative) return;

      setState(() {
        velocity = position.speed;

        context.read<MaxSpeedProvider>().setCurrentSpeedTo(position.speed);

        if (velocity > context.read<MaxSpeedProvider>().maxSpeed) {
          context.read<MaxSpeedProvider>().setMaxSpeedTo(velocity);
        }
      });
    },
  );
}

}
Still not happy with the result... I have tried a stream builder but I cannot yield the result because of async issues. I'm stuck...

Hi @SwiftyFlow, the geolocator plugin calls the native APIs to get position information. We do not have control over the accuracy of the readings.
We do expose the accuracy values, however. You can get them from a Position by calling position.speedAccuracy. Documentation about what this accuracy means can be found here for Android and here for iOS. These values can tell you how accurate the speed readings are.


refactor(upgrader): clean up the UpgraderInterface and simplify the contract

Codecov Report
Attention: Patch coverage is 70.00000% with 6 lines in your changes missing coverage. Please review.

Project coverage is 92.53%. Comparing base (c4796c0) to head (a85ca84).

Files with missing lines
Patch %
Lines

contracts/axelar-gateway/src/contract.rs
33.33%
4 Missing :warning:

contracts/upgrader/src/contract.rs
84.61%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #84      +/-   ##
==========================================
- Coverage   93.16%   92.53%   -0.63%
==========================================
  Files          36       37       +1
  Lines        2267     2076     -191
==========================================
- Hits         2112     1921     -191
  Misses        155      155

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

🚨 Try these New Features:

Flaky Tests Detection - Detect and resolve failed and flaky tests


Cannot read property 'startLineNumber' of null: TypeError: Cannot read property 'startLineNumber' of null

I get an error "Unable to open 'User Settings': Cannot read property 'startLineNumber' of null.".
It only happens if extensions are activated and 'User Settings' contain:
"terminal.integrated.shellArgs.osx": [],

Here is what the developer tools print:
ERR Cannot read property 'startLineNumber' of null: TypeError: Cannot read property 'startLineNumber' of null
    at t.getSettingsAtLineNumber (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:3993:384)
    at t.getSettings (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:3993:14)
    at t.render (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:3990:609)
    at t.render (file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:3981:289)
    at file:///Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:4241:265
    at <anonymous>

VSCode Version: 1.30.0
OS Version: macOS 10.12.6

Steps to Reproduce:

Start VSCode

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

@vscodebot Unfortunately, it is not a duplicate.

Looking at the trace this is a dup of #65272 as root cause is same


nipples.js

My dashboard was empty (no graphics).  My investigation shows that my browser could not load nipples.js (code 404).  There are no other error logs. Maybe there is something in my server/nodered setup that prevents this.

Hi Pandos,
The loading of the libraries has already caused me a lot of headaches in the past, with other nodes of me.  There are lots of different configurations, causing this kind of troubles...

Can you please share a screenshot of the error in the browser log.
And can you share which kind of settings you have configured (related to urls) in your settings.js file.  For example this setting://ui: { path: "ui" },

Bart

Hi Pandos,
The loading of the libraries has already caused me a lot of headaches in the past, with other nodes of me.  There are lots of different configurations, causing this kind of troubles...

Can you please share a screenshot of the error in the browser log.
And can you share which kind of settings you have configured (related to urls) in your settings.js file.  For example this setting://ui: { path: "ui" },

Bart

I suspected that my path configurations may be the cause.
httpAdminRoot: '/admin',
httpRoot: '/',
httpStatic: '/data/static/',
ui: { path: "" }
Reverting to default Node-RED settings resolved the problem.  There are cases when I want my dashboard ui to be the root (/) entry point.  If you ever get time for a solution…  For now I am fine as I want to play around with controlling PTZ in my camera.  I will start with your example using your ONVIF-node.
/Fred
Från: bartbutenaers<EMAIL_ADDRESS>Skickat: den 11 januari 2021 11:03
Till: bartbutenaers/node-red-contrib-ui-joystick<EMAIL_ADDRESS>Kopia: Pandos Me<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Ämne: Re: [bartbutenaers/node-red-contrib-ui-joystick] nipples.js (#1)
Hi Pandos,
The loading of the libraries has already caused me a lot of headaches in the past, with other nodes of me. There are lots of different configurations, causing this kind of troubles...

Can you please share a screenshot of the error in the browser log.

And can you share which kind of settings you have configured (related to urls) in your settings.js file. For example this setting:

    //ui: { path: "ui" },

Bart
—
You are receiving this because you authored the thread.
Reply to this email directly,  https://github.com/bartbutenaers/node-red-contrib-ui-joystick/issues/1#issuecomment-757844765 view it on GitHub, or  https://github.com/notifications/unsubscribe-auth/ACQCUJLIVN2DPLPWFZM3XM3SZLEFZANCNFSM4V5GF4DQ unsubscribe.  https://github.com/notifications/beacon/ACQCUJPSI5EVM4VY3GR5P4DSZLEFZA5CNFSM4V5GF4D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFUV4WHI.gif

I suspected that my path configurations may be the cause.
httpAdminRoot: '/admin',
httpRoot: '/',
httpStatic: '/data/static/',
ui: { path: "" }
Reverting to default Node-RED settings resolved the problem.  There are cases when I want my dashboard ui to be the root (/) entry point.  If you ever get time for a solution…  For now I am fine as I want to play around with controlling PTZ in my camera.  I will start with your example using your ONVIF-node.
/Fred
Från: bartbutenaers<EMAIL_ADDRESS>Skickat: den 11 januari 2021 11:03
Till: bartbutenaers/node-red-contrib-ui-joystick<EMAIL_ADDRESS>Kopia: Pandos Me<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Ämne: Re: [bartbutenaers/node-red-contrib-ui-joystick] nipples.js (#1)
Hi Pandos,
The loading of the libraries has already caused me a lot of headaches in the past, with other nodes of me. There are lots of different configurations, causing this kind of troubles...

Can you please share a screenshot of the error in the browser log.

And can you share which kind of settings you have configured (related to urls) in your settings.js file. For example this setting:

    //ui: { path: "ui" },

Bart
—
You are receiving this because you authored the thread.
Reply to this email directly,  https://github.com/bartbutenaers/node-red-contrib-ui-joystick/issues/1#issuecomment-757844765 view it on GitHub, or  https://github.com/notifications/unsubscribe-auth/ACQCUJLIVN2DPLPWFZM3XM3SZLEFZANCNFSM4V5GF4DQ unsubscribe.  https://github.com/notifications/beacon/ACQCUJPSI5EVM4VY3GR5P4DSZLEFZA5CNFSM4V5GF4D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFUV4WHI.gif

Hi Fred,
I had a similar issue last week.  Does it work when you use ui: { path: "/" } instead of ui: { path: "" }?

Hi Fred,
I had a similar issue last week.  Does it work when you use ui: { path: "/" } instead of ui: { path: "" }?

Setting ui path to "/" resolved the issue.


Log to file

The current log output is nice and all but currently it is

always wiped clean,
not really readable since it's always in a terminal.

This can be fixed using whatever tool is available (tee for running in terminal, journalctl for systemd, normal file redirects, ...) Might revisit if we ever daemonize mumd ourselves.


Airthings ble for view plus

Its rather a question then an issue : is it possible/planned to pull data from view plus via ble ?
A had a view plus and dont like the cloud way of pulling data from it

Unfortunately I do not have that model so I cannot do any testing, and it is not clear to me from the product specifications if the View devices provide access to the sensor data via ble (the specifications suggest that bluetooth is only for on-boarding and setup). In addition, support for Airthings devices via bluetooth has now been integrated into Home Assistant Core, so this add-on is not really being used anymore. Your best bet may be open an issue in the Home Assistant Core repository, and mention the integration "airthings_ble". Sorry to not be able to provide more help.


Prevent tab pane from activating twice

Due to the bindTabToCollapse function, activating a tab activates a panel, and activating a panel activates a tab. This causes double activation which can cause an animation glitch.
Open the demo and click "Key Features" and then "Source" in quick succession. After source loads, key features loads a second time and then source loads a second time. Alternatively, add the "fade" class to the tab panes and watch the content fade in then out then in again.

This fixed the issue that I was having as well. Thanks @mstrelan! @openam please merge this in.


imagai seems not working in linux(ubuntu18.04)

lt said:
Using TensorFlow backend.
2019-08-09 10:34:50.660802: W tensorflow/core/platform/profile_utils/cpu_utils.cc:98] Failed to find bogomips in /proc/cpuinfo; cannot determine CPU frequency
2019-08-09 10:34:50.661635: I tensorflow/compiler/xla/service/service.cc:161] XLA service 0x3f68f1b0 executing computations on platform Host. Devices:
2019-08-09 10:34:50.661714: I tensorflow/compiler/xla/service/service.cc:168] StreamExecutor device (0): ,
2019-08-09 10:34:50.739878: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:965] ARM64 does not support NUMA - returning NUMA node zero
2019-08-09 10:34:50.740194: I tensorflow/compiler/xla/service/service.cc:161] XLA service 0x3da98830 executing computations on platform CUDA. Devices:
2019-08-09 10:34:50.740286: I tensorflow/compiler/xla/service/service.cc:168] StreamExecutor device (0): NVIDIA Tegra X1, Compute Capability 5.3
2019-08-09 10:34:50.740690: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1433] Found device 0
...................................................
TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 191 MB memory) -> physical GPU (device: 0, name: NVIDIA Tegra X1, pci bus id: 0000:00:00.0, compute capability: 5.3)
WARNING:tensorflow:From /usr/local/lib/python3.6/dist-packages/tensorflow/python/framework/op_def_library.py:263: colocate_with (from tensorflow.python.framework.ops) is deprecated and will be removed in a future version.
Instructions for updating:
Colocations handled automatically by placer.
GStreamer: Error opening bin: empty pipeline not allowed

The problem you are having is with the GStreamer installed on your Linux. Kindly follow this thread on solving this. https://stackoverflow.com/questions/44247926/gstreamer-and-opencv3-videocapture-error-opening-bin-empty-pipeline-not-allow
Do you have ffmpeg installed? You might want to do that.

Thank you!l have solved this.

l have trained yolov3-tiny weights in darknet and l got a tiny-yolo weight ,but how can l translate it into your tiny-yolov3.h5
l tried but it says error
ValueError: You are trying to load a weight file containing 12 layers into a model with 2 layers.
or something like that.

ImageAIs custom detection class doesn't support TinyYOLOv3 yet. It will be supported in future updates.


Removed memory mode. Why?

Why was the memory mode removed in r8 ?

You can find a memory monitor here: https://github.com/paulirish/memory-stats.js

r14 bring back the memory panel :)
https://github.com/mrdoob/stats.js/releases/tag/r14


Increase session duration

Hall B shift takers are required to fill out the BTM timesheet every hour at the top of the hour, and they typically don't touch the timesheet any other time; since the user session duration is less than an hour, the typical shift taker must log in eight times during a typical 8 hour shift, unless they routinely interact with the BTM webpage (e.g., refreshing it).
It would be ideal if the shift taker only has to log in once per shift; logging in can be distracting from more critical shift responsibilities, especially if the user's password is difficult to type.
Related: https://github.com/JeffersonLab/smoothness/issues/15

Please check with hall staff to ensure there isn’t a script / browser plug-in clearing your browser session / cache every hour.  My understanding is there was something to that effect setup on your hall kiosk computer.   I don’t believe the other two hall counting houses are having this issue.  The app session expiration is already configured at 8 hours so it seems something client side is clearing it.

Note: closing your web browser also clears your session.

Constantly having to login to the bta system is an issue in Hall C as well.
Tabs in the same browser logged into the logbook stay logged in at least for the duration of a shift.

Please check with hall staff to ensure there isn’t a script / browser plug-in clearing your browser session / cache every hour. My understanding is there was something to that effect setup on your hall kiosk computer. I don’t believe the other two hall counting houses are having this issue. The app session expiration is already configured at 8 hours so it seems something client side is clearing it.

I remember someone acting like they had done that in Hall B, made some script or setting/plugin mess on some particular browser instance, which would be a weird approach anyway since we run per-machine profiles, but I suspect that was just misinformation and I found no evidence of it on Hall B computers.  Regardless, I tested in 100% stock firefox and google-chrome profiles on rhel7, rhel8, and rhel9, and saw similar behavior in all combinations at least once, automatic logout on the hour.

Is this a group account or personal account being logged out?   Is there more than one instance logged in somewhere else using the account in question?
There is an hourly automatic refresh (if the edit form is not open) so one wild guess at this point is that could be problematic.  Keep the last row on the table in edit mode as a test to avoid the hourly auto refresh and see if that fixes it.
Another thing I can try later is I think the OAuth session is only 30 minutes, but that should be separate from the app session - that's something I can bump up if it turns out to be related but historically I don't think it was.

Is this a group account or personal account being logged out?

Personal

Is there more than one instance logged in somewhere else using the account in question?

No other instances with my user name.

Another thing I can try later is I think the OAuth session is only 30 minutes

When I was on shift, it seemed to be longer than ~15 min., but shorter than ~30 min; I wasn't timing it very precisely, so it could very well be exactly 30 min.

I was able to recreate the issue.  I left browser open for an hour and on auto-refresh was logged out.  Error in app server log is:
ELY23012: Refresh token failure status: 400 {"error":"invalid_grant","error_description":"Token is not active"}

I've bumped up the Keycloak SSO Session timeout from 30 minutes to 8 hours.   This appears to fix the issue.    Waiting another hour and on auto-refresh all is well (still logged in).
The client adapter used in the app server changed over the summer with the patching/upgrades and it appears the new "Elytron" OAuth client lib uses token refreshes to maintain the app server session in sync with OAuth session.  The app server session and Keycloak OAuth session are distinct and I don't think the prior lib did this sync (backchannel logout on session expiration - it's probably configurable - we'll just bump SSO expiration for now).  The app server session is set to 8 hours (480 minutes) as seen here:
https://github.com/JeffersonLab/btm/blob/ad0b3f413db554cd96f3b40eac4ca1626d8cb68d/src/main/webapp/WEB-INF/web.xml#L45
Ironically this issue is nearly the opposite of https://github.com/JeffersonLab/smoothness/issues/16 in which users could not log out.  In this issue users can't stay logged in.   There are up to three different sessions/cookies in play: Wildfly app server, Keycloak OAuth server, and formally CUE login was handled by MIS Shibboleth, which has it's own session.

Is this a group account or personal account being logged out? Is there more than one instance logged in somewhere else using the account in question?

That google-chrome/firefox+rhel7/8/9 test was with my personal account, after scratching all the relevant web browser profiles in $HOME and letting google-chrome/firefox create one from scratch with whatever their defaults are.

This should be resolved.   If not, let me know.


Background color of search results

Describe the bug
Search results are not clearly visible because of it's background color
Screenshots

Can You please assign it to me. I would like to contribute

@adityakmrmishra Could I know why is this issue closed?

Don't worry there was a little confusion I'm reopening it

@adityakmrmishra I have made changes which solves this issue and pulled a request #34


new MacVim icon is too light

Hi,
I'm running macOS High Sierra (10.13.2), and I had to reinstall MacVim for some reason, and I find that the new MacVim icon as it appears in the Dock  is too light of a color.  The default color of the Dock is white, and the white "V" in the  MacVim icon fades into the Dock's white background making the icon hard on the eyes.   I think the old icon that was dark green stood out nicely, and because I'm used to looking for the highly visible dark green icon in the Dock, I don't like the new color.
I looked at the new MacVim.icns file, and it contains ten icons  while my old MacVim.icns file contains five icons.  Is it possible to make available a ten icon file with the old dark green icon?  Thanks.

The history of the MacVim icon in the repository is here, which you can use to fetch the desired version of the icon yourself.
All the document-type icons are generated (there is a Makefile in src/MacVim/icons used to do so) if you want to regenerate everything yourself, although I think applying those would require you to rebuild MacVim yourself as well.