parca: init at 0.22.0

Things done
This PR introduces the parca package. Parca, according to their own description, provides:

Continuous profiling for analysis of CPU and memory usage, down to the line number and throughout time. Saving infrastructure cost, improving performance, and increasing reliability.

 Note that this is the open-source server implementation, not the agent (which I may package later, but is significantly more complex).

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 359635

x86_64-linux

:white_check_mark: 1 package built:

parca

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 359635

x86_64-linux

:white_check_mark: 1 package built:

parca


Add 'Destroy' event as a Script Method

Description
Currently, PlayCanvas scripts support the following script methods (https://developer.playcanvas.com/en/user-manual/scripting/anatomy/):

initialize, postInitialize
update, postUpdate
swap

However, it is very common to do some clean-up once a script is destroyed (unbind events, free resources, etc), and the only way to do that is to manually hook up the destroy event:
MyScript.prototype.initialize = function() {
    this.on('destroy', this.destroy, this);
};

MyScript.prototype.destroy = function() {
    // cleanup
};

I suggest for us to simply add destroy as an optional script method, thus removing the need to manually hook the destroy event.

@Maksims @vkalpias Can you remember why script 2.0 switched destroy from a function to an event?

Event is more generic .. as other object can listened to destroy event of different object - so maybe it was done to have the better (more generic) solution, even though slightly less convenient?

Indeed, it is to be able to know from other places, when something is destroyed.
When you have "manager" & "instances" scripts, it was really awkward from manager to know when instance was destroyed.
With events it is very simple.
Also, events allow multiple listeners, when prototype method only single one, which in complex projects lead to even more problems.
Same is about enable/disable/state events.

Wait - it sounds like you're saying that, in scripts 2.0, both the event and function work. But I thought only the event worked. This kind of backs that up:
https://github.com/playcanvas/engine/blob/dev/src/framework/components/script/component.js#L121-L127

Just following up as I've literally just run the same issue. It doesn't seem immediately clear from a UX perspective why initialize would be called on the component but destroy would not, even though the event thing makes sense.
I wonder if the destroy event could not be fired on the script component first, before calling it's destroy() if it exists. This would handle the use case where events are needed, but also covers the scenario where someone could reasonably assume that a destroy would be called.

Just following up as I've literally just run the same issue. It doesn't seem immediately clear from a UX perspective why initialize would be called on the component but destroy would not, even though the event thing makes sense.
I wonder if the destroy event could not be fired on the script component first, before calling it's destroy() if it exists. This would handle the use case where events are needed, but also covers the scenario where someone could reasonably assume that a destroy would be called.
For context; I'm mainly thinking about this in reference to the api for ES Modules.

Not every script needs to do destroy logic.
Destroy event is usable from outside of a script, that is why it is an event.
Having a method will lead to a confusion, as devs will see a destroy method, then might need to subscribe from other place, they might fire their own destroy event - this will lead to a duplicate destroy event.
There should be least number of branching in learning curve.

Personally I'd love to have a destroy method as a convenience for the users.

Closing this as we do not intend to make further changes to Scripts v2. However, @marklundin, revisit the thread for the Scripts v3 design.


Code style improvements

Turned out to be quite a few changes :)

And yes, we still have some warnings from RuboCop about methods size, rescues… but it probably entails more architectural changes.

Thank's a lot Alexander for taking time to clean up the code.
It's really good to make the code more idiomatic. I especially liked this:
    'DIRNAME' => path.parent.realpath.to_s,
    'ABSOLUTE_FILENAME' => path.realpath.to_s,
    'RELATIVE_FILENAME' => File.join('.', path)

Makes me embarassed to read my old code. ;-)

It's okay, we're all a little embarrassed of our old code ;-)
Thank you.


Allow test L1 IP addresses

Allow user to configure a list of test L1 IP Addresses to connect to.

@juliangruber Merging this. As always, please feel free to leave comments.


Documentation sprint - Metadata.md

GitHub Issue: https://github.com/Islandora/documentation/issues/1040
What does this Pull Request do?
Updates documentation for Metadata!
What's new?
Not sure yet, this is a WIP.
How should this be tested?
Read it, and leave comments if it's wrong or confusing!
Interested parties
[I'll tag collab, Seth and Wilhelmina, when it's ready, but you're free to jump in now if you want!)

Hey folks thank you for your comments on the draft! The PR is marked as "ready for review" now. I know I missed the sprint deadline (sorry) but I don't want this to get orphaned.


Support a group key for storing storing a group of values on a single server

It would be nice if you could tell dalli to choose a server to choose a server to store/fetch values based on a group-key (user_id, etc).
I'm interested in implementing this but unsure if what the best API would be.
We could add an option to every get/fetch command:
dalli.set('abc',123, :hash_by => user.id)

Or use a block:
 dalli.group_by(user.id) do
   dalli.set('abc',123)
 end

I'm partial to the block format.  It seems less repetitive and seems less invasive than making all the operations support a new parameter.
Thoughts?

This would be trivial to support with the block format and a Thread local variable.  Pull requests accepted.  :beer:


Provide DBS REST API and client API which can return parent files by matching run lumis

i.e.
getParentFilesUsingRunLumiMatching(childLFN, parentDataset=None)
returns [{"child_lfn": blah, "parent_lfns" [....]}
REST API is needed for the concurrent call using pycurl.

Please provide your use causes and detail requirement.

For StepChain workflow there is no easy way to get the parentage between files.
https://github.com/dmwm/WMCore/wiki/StepChain-Parentage
We need to able to figure it out from child lfn to list of parent lfn for given parent dataset.
We can construct combining current dbs apis to get this results, however since this call need to be made for all the files for a given dataset, there is optimize way to handle this.
One way to handle is making concurrent call for getting this however current dbs api doesn't support currency for the APIs runs sequentially and need the relations between those api.
Requirement:
So we need to have either dbs api runs currently when it takes list of childLFNs and parentDataset.
Or need REST api which takes single childLFN and parentDataset, so we can make call that REST api currently using pycurl

As discussed with @ticoann yesterday, We had below decision:

We should use bulk operations to DB  in order to speed up DB access. Using pycurl for concurrent call to DB is a bad practice.
We should separate finding parentage from inserting them to keep the API execution time shorter.

The proposed API: listFileParents(listofchildLFNs, listofParentDatasets)
It will return a list of File Parentages as[(cid1, pid1), (cid2, pid2) ...(cidn, pidn)]
Note CMS LFN is a very long string so we will not return matching LFN pairs, but database ids. This API is not meant for humans to read what it returns, but for the insert API to upload parentage to the db. The insert API should call right after this one to insert to the same DB this one is connected. The list and insert APIs have to call in sequence and pairs.
This API will use run-lumi info from the child LFN to match the run-lumi of the list of parent dataset. There may have wrong matching because the same run-lumi info may show in multiple parent files. There is no way for DBS to know what were the real parent files.  Is this acceptable to the physicists, @bbockelm ?

isn't listFileParents already exists? listFileParentsUsingLumi? Also we need equivalent RESTApi

Different signatures. RESTApi should be the same.

Seangchan, Yuyi

The proposed API: listFileParents(listofchildLFNs, listofParentDatasets)
It will return a list of File Parentages as[(cid1, pid1), (cid2, pid2) ...(cidn, pidn)]
Note CMS LFN is a very long string so we will not return matching LFN pairs, but database ids.

given that the output of listFileParents api isn't human readable, I think the best would be to re-purpose it such that it finds and fixes the parentage files. I understand it will then become a very slow api (better if we had timing numbers for the find and the insert actions), but maybe we could then restrict it to a block level operation only (one block at a time)?
In addition to that, I'm concerned about the integrity of the DBS data. Would this API allow to overwrite a parent file? Or it only allow changes to children with NO parent files?
I know it's a substantial more work, but it might be a good idea to have a specific DBS role for such operations. I'd say any insert or data changes should have a different DBS role than the one used for changing dataset and file status. That would be a good way to protect data from human and other scripts/tools mistakes.

@amaltaro
All operations we talked in this group of APIs are block based APIs. We will keep the searching  and insert separately for now.
We are very short on time and man power right now, so I'd like to focus on the current issues. If we agree to redesign DBS permission system, we need to think through and have a plan.

Unite tests should include both client side tests and server side tests.
API listFileParents(list0fChildLFNs, listofParentDatasets)

Negative tests: if missing any of the inputs, the API should failed.
input: single item of LFN list and single dataset.
input: long list  of LFN and single dataset.
input: long list of LFN and long list of datasets.
All input tests should insert and read back to compare them. The test fails when they are different.

Unite tests should include both client side tests and server side tests.
API listFileParents(list0fChildLFNs, listofParentDatasets)
Negative tests: if missing any of the inputs, the API should failed.
input: single item of LFN list and single dataset.
input: long list of LFN and single dataset.
input: long list of LFN and long list of datasets.
All input tests should compare the result with listFileParents(logical_file_name). The test fails when they are different.

Discussed with Seangchan, we will restrict the missing file parentage is from single block. So The updated API is listFileParents(listofChildLFNs, listofParentDatasets, childBlockName)
where the listofChildLFNs are the missing parentage ones.

Discussed with Seangchan, we will restrict the missing file parentage is from single block. So The updated API is listFileParents(listofChildLFNs, listofParentDatasets, childBlockName)

Yuyi, Seangchan, I'm afraid I'm a bit lost in here...
Isn't the use case the following:

input: user/someone gives a block_name (str) and the parent dataset of this block (str) to this list* API
output: the API returns every single LFN (str) in that block (child LFNs) and their correspondent parent LFNs (list of str). (Or their file ids in the database)

IF this is the correct use case, why do we care about listofChildLFNs and listofParentDatasets? Is this design considering that in the future we might have a file with 2 different parent datasets?
Last but not least, just a minor suggestion, how about calling it listParentFiles instead? It's more clear IMO.

Alan:
We have this API because we want to find out the parent files for these listOfChildLFNs. In most case, all the file parentage is missing for the childBlockName, there is a small portion only part of the files has no parentage so we need to list the missing child files.
The API returns only the (childFile parentFile) that does not have parentage in DBS.
According to Seangchan, the parent files could be in more than one datasets, so it is a list.
we know the child file and try to find who are the parents. Based on DBS API naming convention, it  is listFileParents. We already have APIs called listFileParents(blockname), listFileChildren and so on.

I just discussed with Alan about the issue. Although agent doesn't have restriction on multiple datasets  as input, We never had that case. So I think it would be OK to change to listofParentDatasets to one parentdataset. Also parentdataset can be easily obtained from DBS call when you know the child block name we might make that optional as well. Yuyi, we can discuss this in more detail tomorrow.

Sounds good to me.
From: ticoann<EMAIL_ADDRESS>Reply-To: dmwm/DBS<EMAIL_ADDRESS>Date: Thursday, July 12, 2018 at 3:50 PM
To: dmwm/DBS<EMAIL_ADDRESS>Cc: Yuyi Guo<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [dmwm/DBS] Provide DBS REST API and client API which can return parent files by matching run lumis: listFileParents(listofchildLFNs, listofParentDatasets, blockName) (#569)
I just discussed with Alan about the issue. Although agent doesn't have restriction on multiple datasets as input, We never had that case. So I think it would be OK to change to listofParentDatasets to one parentdataset. Also parentdataset can be easily obtained from DBS call when you know the child block name we might make that optional as well. Yuyi, we can discuss this in more detail tomorrow.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dmwm_DBS_issues_569-23issuecomment-2D404646323&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=OIPhNHI2CrcLlm1OEN2wECQN_waEqFLC00oBW6_VzGg&s=272zYPxw-RA4kEalT9AGyywkP7RhV-SxbGskiBu6fXM&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABsXTvCm9UCf1FtnCLxv8v3W1qZAkidVks5uF7aUgaJpZM4U9N58&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=8bursUuc0V63OwREQMBG2Q&m=OIPhNHI2CrcLlm1OEN2wECQN_waEqFLC00oBW6_VzGg&s=YDdRWAt9lYcFjCrThNilu3YJclj07YJOp_0-evPbPIA&e=.

The new signature: listFileParents(block_name, logical_file_name=None)
DBS internal validation requires the same names.


event encoding fix for legacy typeid

On the way to close #659
Description
@SupunS  informed about event.Payload, which solves our problems totally.

For contributor use:

[X] Targeted PR against master branch
[X] Linked to Github issue with discussion and accepted design OR link to spec that describes this work
[X] Code follows the standards mentioned here
[ ] Updated relevant documentation
[X] Re-reviewed Files changed in the Github PR explorer
[ ] Added appropriate labels

yeah I need to get help from @sideninja on this I guess @SupunS , I really don't have any good idea to test this.

yeah I need to get help from @sideninja on this I guess @SupunS , I really don't have any good idea to test this.

You could have a test by creating an event and passing it to the TransactionResult struct and then asserting the method response.

@bluesign rearrange imports to satisfy CI

I will handle it and tests max tomorrow, had.a busy few days lately.

@bluesign I will fix the linting as this is an important improvement I will merge for today release and resolve it myself. Thank you


Check for admin login via keystone failing

Hi,
During an outage where the login via keystone for the admin user were failing, there were no alerts from the sanity checks. This check would be useful to have as a way to avoid future issues of the type. And remedy them before impacting the user.
Kind Regards

Imported from Launchpad using lp2gh.

date created: 2019-02-23T01:07:13Z

owner: mihaela

assignee: None

duplicate of: #7

the launchpad url

(by aieri)
Tentatively setting this as duplicate for LP#1772944.
Mihaela: by "login" did you mean login to Horizon?

(by mihaela)
Andrea: does look like LP#1772944 indeed. Please feel free to close. ta


Clang error when using emacs

I'm having an issue getting cquery working under emacs. I'm not sure where this issue is between:
Cquery compatibility with CentOS 7 and my general environment
Issue with the emacs config
My mistake in setup.
I've got cquery built and configured in emacs (although I had to use --check-cxx-compiler=g++ or I got a compile error). When attempting to autocomplete in emacs I get the following error in Messages:
clang failed with error 1:
/usr/bin/clang -fsyntax-only -Xclang -code-completion-macros -x c++ -Xclang -code-completion-at=-:56:13 -

I'm running:
Centos 7
GCC 5.3.1
clang 3.4.2

Cannot repro. Try disable other related autocomplete backends in emacs?

Yea, cquery does not invoke clang in this way. That looks like another completion backend.

You were right about that and I've fixed that. Also - thank you to whoever updated the emacs install instructions on the wiki.
I'm still ahving an issue:
Company: An error occurred in auto-begin
Company: backend company-lsp error "Wrong type argument: hash-table-p, nil" with args (prefix)

This may well be a company-lsp / lsp-mode error, rather than necessarily something to do with CQuery. I'm digging into it now.

Yep the "Wrong type argument: hash-table-p, nil" error appears many times in my Emacs too. There seems much to be done for lsp-mode, lsp-ui and company-lsp.

I believe that error was caused by having an incorrect path to the cquery executable (I had ~/cquery/bin/cquery rather than ~/cquery/build/release/bin/cquery). That's why lsp-mode couldn't get the capabilities. It's a very poor error message that you get via company-lsp though. You get a much better error via flycheck, which is how I found it.

To confirm - everything appears working now, using either git source or melpa for lsp-mode and company-lsp.
I have wonderful flyspell and autocompletion, and the best C++ coding experience I've ever had in emacs so thanks!
Now if only I could get this working in Windows too...

To Emacs users, have you ever felt the slow rendering of overlays?
cquery.el uses overlays to render cquery highlighting info in Emacs and because Emacs uses a zipper (I guess) to implement overlays, it may be extremely slow when there are a lot of objects to render.
(setq cquery-sem-highlight-method 'font-lock)
@politza has an alternative overlay implementation based on AA-tree (I'm slightly puzzled why AA-tree is used. It is uncommon and usually slower than red-black tree...) https://lists.gnu.org/archive/html/emacs-devel/2017-05/msg00084.html    I want to know whether others feel annoyed when rendering a long document with default cquery-sem-highlight-method 'overlay turned on.

@MaskRay That's just the topic's name, the implementation uses a red-black tree.


Add lyksoomu.com to the list of URL shorteners

lyksoomu.com redirects to adf.ly

With a single hit in metasmoke (so far - maybe search again ... though note that the regex search requires you to be logged in to metasmoke) and no hits on Stack Exchange I don't think this is significant enough to warrant inclusion. I'll propose to leave this open for now, but probably close it in a few days if there are no additional hits.


MDX component improvements

Just quickly going over the difference between our self hosted content and the old notion docs I saw some style differences that I think could be improved.

Spoiler collapsed state should have some bottom margin to better separate itself from the content below it.

Spoiler expanded state should be indented to show it belongs to that spoiler

Code block should not have so much bottom margin. Somehow the code blocks are double wrapped in <pre> tags that each have their own bottom margins. (The top margin might want to be tweaked as well)

Quote block lightbulb icon should not wrap to its own line on small screens. Smaller icon maybe better as well?

Also you might be able to spot more improvements by comparing our notion docs to the self hosted ones
https://www.c0d3.com/curriculum/js0/primitive_data_and_operators
https://www.notion.so/JS-0-Foundations-a43ca620e54945b2b620bcda5f3cf672

A redesign is currently under work for this page.


Add datasetid to 3d model

@j-bjorne Is this documented somewhere in the API docs?

There are currently a PR in the service contracts and docs, waiting for those to be merged before I push this.
https://github.com/cognitedata/service-contracts/pull/1388

@dbrattli Sorry for a late reply, I am waiting for other PR's to be merged before merging this one.

https://github.com/cognitedata/service-contracts/pull/1388
I will not merge this before this one get's merged. I was just readying it :)

I removed a couple tests for 3D since they were failing due to missing data-set-id. You might want to add those back.

Due to some issues, we rolled back the changes and are adding things later. @einarmo you said you removed tests, where can I see the tests you removed, because I would prefer to rather update the tests.

Due to some issues, we rolled back the changes and are adding things later. @einarmo you said you removed tests, where can I see the tests you removed, because I would prefer to rather update the tests.

https://github.com/cognitedata/cognite-sdk-dotnet/blob/master/CogniteSdk/test/fsharp/3DModels.fs
Two tests at the bottom are commented out.

If tests fail like this in the future, please contact us, we were testing something in staging and were relying on people to report issues instead of just silently removing tests. If we had been told these were failing, we would have rolled back our staging image and avoided rolling out in production. Please comment in these tests again, and the next time you decide to comment out 3D tests, please reach out to the 3D team!

If tests fail like this in the future, please contact us, we were testing something in staging and were relying on people to report issues instead of just silently removing tests. If we had been told these were failing, we would have rolled back our staging image and avoided rolling out in production. Please comment in these tests again, and the next time you decide to comment out 3D tests, please reach out to the 3D team!

I should have done more, but I did post in the api slack channel about this.

No worries, I think the tests can be commented in again. If you don't get any response we have a topic-3d and a 3d-shield role you can feel free to use in the future if you see any problems regarding 3d.

@dbrattli it has taken a while, but is it possible to get a thumbs up on this, finally tests are running on this


Github action fixes

Fixed build action
Added a separate release action

Sync with https://github.com/riscv/docs-spec-template.

cc @rsahita


kernel: sched: avoid unnecessary lock in z_impl_k_yield

z_impl_k_yield unlocked sched_spinlock, only to lock it again
immediately, do a little bit more work, then unlock it again.
This causes performance issues on SMP, where sched_spinlock
is often fairly highly contended and cores often end up spinning
for quite a while waiting to retake the lock in z_swap_unlocked.
Instead directly pass the spinlock key to z_swap and avoid the
extra lock+unlock.
Signed-off-by: James Harris<EMAIL_ADDRESS>

Looks correct to me. I do worry about the amount of attention being paid to k_yield(), which is almost never expected to be a performance path. Code spinning on yield() is almost always best modified to something that will block and context switch instead.

Absolutely fair.
I was mainly using it as the simplest possible context switch microbenchmark.
Have a preference for a better microbenchmark there? Two threads passing a semaphore back and forth or something?

Semaphore bouncing is good, they're pretty much the simplest possible blocking primitive.  Note that with SMP it's possible to get into a silly-cpu-swap syndrome though where the two threads keep bouncing between CPUs and thrashing their L1 cache needlessly.  If you want to look at context switch times in isolation but still exercise the SMP code paths, CONFIG_MP_NUM_CPUS=1 is your friend.
Also note that k_timer is a very simple ISR hook available to app code with minimal overhead and useful for benchmarking interrupt preemption times (i.e. k_sem_give() within a k_timer_hook() to return into a different thread, etc..)

Also note that k_timer is a very simple ISR hook available to app code with minimal overhead and useful for benchmarking interrupt preemption times (i.e. k_sem_give() within a k_timer_hook() to return into a different thread, etc..)

I've got one better - I've got a high-speed trace setup. It's great. Non-invasive and cycle-accurate (although that doesn't say nearly as much on a pipelined core with caching and branch prediction as it would otherwise... there's a lot of room for interpretation of the results still.)
I'll keep k_timer in mind for when that's not available however.

Semaphore bouncing is good, they're pretty much the simplest possible blocking primitive. Note that with SMP it's possible to get into a silly-cpu-swap syndrome though where the two threads keep bouncing between CPUs and thrashing their L1 cache needlessly. If you want to look at context switch times in isolation but still exercise the SMP code paths, CONFIG_MP_NUM_CPUS=1 is your friend.

@andyross - so a first quick profile for two threads pingponging on one core (that is, two threads pinned to one core, and each acquiring their own semaphore then releasing the other semaphore in a loop, with the other cores sitting in WFE) with my (rather hacked-up with performance tweaks) local branch:
14.452%		z_swap_next_thread
10.163%		z_pend_curr
07.752%		z_arm64_sync_exc
07.345%		z_reschedule
06.493%		z_unpend_first_thread
05.948%		z_ready_thread
05.200%		pend
05.170%		z_impl_k_sem_give
04.604%		z_abort_timeout
04.528%		ready_thread
04.276%		z_arm64_context_switch
03.413%		z_impl_k_sem_take
03.390%		z_thread_mark_switched_out
03.236%		thread_active_elsewhere
02.398%		sem_loop
01.970%		add_to_waitq_locked
01.619%		unready_thread
01.507%		z_thread_mark_switched_in
01.466%		z_timer_cycle_get_32
01.245%		unpend_thread_no_timeout
01.180%		z_arm64_call_svc
01.139%		z_reset_time_slice
01.044%		z_mapped_start
00.463%		z_requeue_current

That's percent_self_time function. Note that a number of things are inlined in the above....
And as for z_swap_next_thread in particular...
.212%  z_swap_next_thread:      	stp	x29, lr, [sp,#-48]!
.212%  z_swap_next_thread+0x4:  	mrs	x1, tpidrro_el0
.212%  z_swap_next_thread+0x8:  	mov	x29, sp
.212%  z_swap_next_thread+0xc:  	stp	x21, x22, [sp,#32]
.212%  z_swap_next_thread+0x10: 	adrp	x21, .+86016 (0x1002298c)
.212%  z_swap_next_thread+0x14: 	add	x21, x21, #0xb90
.212%  z_swap_next_thread+0x18: 	mov	x0, x21
.212%  z_swap_next_thread+0x1c: 	stp	x19, x20, [sp,#16]
.212%  z_swap_next_thread+0x20: 	ldr	x19, [x0,#0xb0]!
.212%  z_swap_next_thread+0x24: 	cmp	x19, x0
.213%  z_swap_next_thread+0x28: 	b.eq	.+176 (z_swap_next_thread+0xd8)
.208%  z_swap_next_thread+0x2c: 	cbz	x19, .+48 (z_swap_next_thread+0x5c)
.199%  z_swap_next_thread+0x30: 	ldrb	w1, [x1,#36] ; current_cpu->id
.199%  z_swap_next_thread+0x34: 	movz	x0, #1
.199%  z_swap_next_thread+0x38: 	lsl	x0, x0, x1
.199%  z_swap_next_thread+0x3c: 	ldr	x1, [x21,#0xb8] ; list->tail
.199%  z_swap_next_thread+0x40: 	ldrb	w2, [x19,#39] ; thread->base.cpu_mask
.199%  z_swap_next_thread+0x44: 	tst	x2, x0
.201%  z_swap_next_thread+0x48: 	b.ne	.+20 (z_swap_next_thread+0x5c)
.462%  z_swap_next_thread+0x5c: 	mrs	x22, tpidrro_el0
.462%  z_swap_next_thread+0x60: 	mrs	x20, tpidr_el1
.462%  z_swap_next_thread+0x64: 	ldrb	w0, [x20,#25] ; thread->base.thread_state
.463%  z_swap_next_thread+0x68: 	tbz	w0, #5, .+12 (z_swap_next_thread+0x74)
.185%  z_swap_next_thread+0x74: 	ldrb	w1, [x20,#25] ; thread->base.thread_state
.185%  z_swap_next_thread+0x78: 	ands	w0, w1, #0x1f
.185%  z_swap_next_thread+0x7c: 	cset	w4, eq
.185%  z_swap_next_thread+0x80: 	cbnz	x19, .+8 (z_swap_next_thread+0x88)
.185%  z_swap_next_thread+0x88: 	cbnz	w0, .+120 (z_swap_next_thread+0x100)
.165%  z_swap_next_thread+0x8c: 	ldrsb	w3, [x20,#26] ; thread->base.prio
.165%  z_swap_next_thread+0x90: 	ldrsb	w0, [x19,#26] ; thread->base.prio
.165%  z_swap_next_thread+0x94: 	ldrb	w2, [x22,#37] ; current_cpu->swap_ok
.165%  z_swap_next_thread+0x98: 	cmp	w3, w0
.165%  z_swap_next_thread+0x9c: 	b.eq	.+68 (z_swap_next_thread+0xe0)
.150%  z_swap_next_thread+0xb0: 	cbnz	w2, .+80 (z_swap_next_thread+0x100)
.183%  z_swap_next_thread+0xb4: 	mov	x19, x20
.183%  z_swap_next_thread+0xb8: 	mrs	x0, tpidr_el1
.183%  z_swap_next_thread+0xbc: 	ldrb	w2, [x0,#25] ; thread->base.thread_state
.183%  z_swap_next_thread+0xc0: 	tst	x2, #0x1f
.183%  z_swap_next_thread+0xc4: 	b.ne	.+60 (z_swap_next_thread+0x100)
.082%  z_swap_next_thread+0xc8: 	ldrh	w0, [x0,#26] ; thread->base.prio
.082%  z_swap_next_thread+0xcc: 	cmp	w0, #0x80
.082%  z_swap_next_thread+0xd0: 	csel	x19, x19, x20, lo
.082%  z_swap_next_thread+0xd4: 	b	.+44 (z_swap_next_thread+0x100)
.141%  z_swap_next_thread+0xe0: 	ldr	w0, [x19,#28] ; thread->base.prio_deadline
.141%  z_swap_next_thread+0xe4: 	ldr	w3, [x20,#28] ; thread->base.prio_deadline
.141%  z_swap_next_thread+0xe8: 	cmp	w3, w0
.141%  z_swap_next_thread+0xec: 	b.eq	.-60 (z_swap_next_thread+0xb0)
.302%  z_swap_next_thread+0x100:	cmp	w4, #0
.302%  z_swap_next_thread+0x104:	ccmp	x20, x19, #4, ne
.302%  z_swap_next_thread+0x108:	b.eq	.+128 (z_swap_next_thread+0x188)
.350%  z_swap_next_thread+0x188:	ldrb	w0, [x19,#25] ; thread->base.thread_state
.350%  z_swap_next_thread+0x18c:	tbz	w0, #7, .+40 (z_swap_next_thread+0x1b4)
.139%  z_swap_next_thread+0x190:	and	w0, w0, #0x7f
.139%  z_swap_next_thread+0x194:	strb	w0, [x19,#25] ; thread->base.thread_state
.139%  z_swap_next_thread+0x198:	mrs	x0, tpidr_el1
.139%  z_swap_next_thread+0x19c:	cmp	x19, x0
.139%  z_swap_next_thread+0x1a0:	b.eq	.+20 (z_swap_next_thread+0x1b4)
.174%  z_swap_next_thread+0x1a4:	ldp	x0, x1, [x19] ; node->prev / node->next
.174%  z_swap_next_thread+0x1a8:	str	x0, [x1] ; prev->next
.174%  z_swap_next_thread+0x1ac:	str	x1, [x0,#8] ; next->prev
.174%  z_swap_next_thread+0x1b0:	stp	xzr, xzr, [x19] ; node->prev / node->next
.328%  z_swap_next_thread+0x1b4:	mov	x0, x19
.328%  z_swap_next_thread+0x1b8:	strb	wzr, [x22,#37] ; current_cpu->swap_ok
.328%  z_swap_next_thread+0x1bc:	ldp	x19, x20, [sp,#16]
.328%  z_swap_next_thread+0x1c0:	ldp	x21, x22, [sp,#32]
.328%  z_swap_next_thread+0x1c4:	ldp	x29, lr, [sp],#48
.328%  z_swap_next_thread+0x1c8:	ret

You'll note:

A fairly flat execution profile (for the most part) - there are some caveats here (this core likes to stall at conditional branches instead of at proceeding loads).
A surprising amount of redundant work even after some local tweaks. This is with const/pure, and even so it does:

.462%  z_swap_next_thread+0x60: 	mrs	x20, tpidr_el1
.462%  z_swap_next_thread+0x64: 	ldrb	w0, [x20,#25]
[...]
.183%  z_swap_next_thread+0xb8: 	mrs	x0, tpidr_el1
.183%  z_swap_next_thread+0xbc: 	ldrb	w2, [x0,#25]
[...]
.139%  z_swap_next_thread+0x198:	mrs	x0, tpidr_el1

or
.462%  z_swap_next_thread+0x64: 	ldrb	w0, [x20,#25]
.463%  z_swap_next_thread+0x68: 	tbz	w0, #5, .+12 (z_swap_next_thread+0x74)
.185%  z_swap_next_thread+0x74: 	ldrb	w1, [x20,#25]

Nice.  Actually none of that looks to horrifying to me.  The redundant extractions of current_cpu are confusing to see but they should be treatable in C without mucking with the code too much.
FWIW: I see that SVC call in there, which worries me a little.  On Cortex M, context switch is effected by a PendSV exception (which has some... unfortunate side effects, c.f. CONFIG_SWAP_NONATOMIC).  Is that true on aarch64 too?  I would have assumed that it would implement a more traditional musical-chairs context switch?

One of the other components there is that there's currently a bunch of different spinlock calls in k_sem_give:

the semaphore lock, from z_impl_k_sem_give
sched_lock from z_unpend_first_thread,
timeout_lock from z_abort_timeout
sched_lock again from k_ready_thread

...which is totally optimizable further. (Although see #32800...)

FWIW: I see that SVC call in there, which worries me a little. On Cortex M, context switch is effected by a PendSV exception (which has some... unfortunate side effects, c.f. CONFIG_SWAP_NONATOMIC).

What's the actual race condition there? I looked at CONFIG_SWAP_NONATOMIC, but I must admit I'm missing something because can't you "just" set the PendSV exception priority higher than any interrupt's interrupt priority, and then when you want to context-switch, raise BASEPRI to a value between the two, then unmask interrupts? (And restore BASEPRI after of course.)
It's a pain, but (seemingly) doable.

Is that true on aarch64 too? I would have assumed that it would implement a more traditional musical-chairs context switch?

It currently is using SVC, which is unaffected by interrupt masking. So, the specific case you're worried about doesn't come up.
That being said, one of the major TODOs I have here is implementing a mode where it skips the SVC. It does add a nontrivial amount of overhead.

The redundant extractions of current_cpu are confusing to see but they should be treatable in C without mucking with the code too much.

Unfortunately, this is after pulling out the obvious cases into local variables.
The main issue is usages in inlined functions (or even nested inlined functions). I mean, I could plumb through _current_cpu / _current in random places in the scheduler as arguments, but that'd be, uh, messy.
I'll do up a quick PR and see how messy it actually gets.

The issue with PendSV is that it's actually lowest priority.  If it was high priority then it would trap as a nested interrupt when signaled from within an ISR and wouldn't be able to do the context switch.  It has to be the outermost nested state that returns directly to user mode.
So we end up with this situation where user code can get state ready, change the current thread, enter z_swap() (which, by taking a lock, tends to be used as a condition variable -- code assumes that the lock will be atomically released along with the context switch) but then be preempted by an interrupt before the actual context switch happens.  So the ISR runs in a state where _current reflects the "new" thread but not the interrupted thread.  This mostly affects timeslicing (which needs to know whose slice to update), but it's been a perenial gotcha in the scheduler where I'll make a change and realize a week later I've broken ARM in subtle ways.

The issue with PendSV is that it's actually lowest priority. If it was high priority then it would trap as a nested interrupt when signaled from within an ISR and wouldn't be able to do the context switch. It has to be the outermost nested state that returns directly to user mode.

Oh I see. You want to trigger a context switch inside an interrupt handler and have it actually do the switch only once it returns from the handler...
Yeah, I can see how that gets complicated. I think you can juggle setting PRI_14 to make it work, but it'd be annoying at best.
(Roughly - normally have PendSV's priority higher than all interrupt handlers, and reset to this in the PendSV exception handler (you may have to juggle BASEPRI here too - I'm not super familiar with how the Cortex-M works if you change the priority of a handler you're executing). If you're in an interrupt handler and you want to take a context switch, drop PendSV's priority to below all interrupt handlers before triggering it. Does require branching on if you're in interrupt context, which isn't ideal.)

Have you thought about introducing a debug option that intentionally triggers an interrupt (say, timer set to a random small time) immediately after setting _current?

Actuallly no.  Those were the reason it's currently set at lowest priority.  The reason it's annoying is that it makes swap non-atomic.  You can take the scheduler lock (or any other spinlock, but in practice it's the scheduler state that cares about this stuff), arrange state within that lock, and then call out the arch-provided context switch.  And then find yourself in an ISR in a situation where the swap hasn't happend yet, because the release of the BASEPRI lock (intended to unmask PendSV) trapped instead to an already-flagged interrupt that sits at a higher priority.
But yes: one solution would seemingly be to swap the priority of PendSV at interrupt entry and exit so that it's "highest" priority from within user code and "lowest" from the perspective of an ISR.  Or we could just code a more traditional context switch instead. :)  There's actually an ancient issue filed about this somewhere.

But yes: one solution would seemingly be to swap the priority of PendSV at interrupt entry and exit so that it's "highest" priority from within user code and "lowest" from the perspective of an ISR.

You have to be careful here; you can't restore the priority of PendSV before interrupt exit, or you'll get a hardfault. And you can't restore it after interrupt exit because it's an interrupt - it could have come from (almost) anywhere.
Hence the "solution" of resetting it in the PendSV handler itself.

Or we could just code a more traditional context switch instead. :) There's actually an ancient issue filed about this somewhere.

Yep. Though it is unfortunate in that case that you lose the HW optimizations.


marimo edit --sandbox no longer creates new files

Describe the bug
Sometime in between 0.9.23 and 0.10.2, marimo edit --sandbox new_file.py no longer creates new files. marimo edit new_file.py works fine, but adding --sandbox gives FileNotFoundError: [Errno 2] No such file or directory 'new_file.py'.
Environment
{
  "marimo": "0.10.2",
  "OS": "Darwin",
  "OS Version": "24.1.0",
  "Processor": "arm",
  "Python Version": "3.11.2",
  "Binaries": {
    "Browser": "131.0.6778.140",
    "Node": "v22.9.0"
  },
  "Dependencies": {
    "click": "8.1.7",
    "docutils": "0.21.2",
    "itsdangerous": "2.2.0",
    "jedi": "0.19.2",
    "markdown": "3.7",
    "narwhals": "1.14.2",
    "packaging": "24.2",
    "psutil": "6.1.0",
    "pygments": "2.18.0",
    "pymdown-extensions": "10.12",
    "pyyaml": "6.0.2",
    "ruff": "0.8.0",
    "starlette": "0.41.3",
    "tomlkit": "0.13.2",
    "typing-extensions": "4.9.0",
    "uvicorn": "0.32.1",
    "websockets": "12.0"
  },
  "Optional Dependencies": {
    "pandas": "2.0.2",
    "polars": "0.19.12"
  }
}

Code to reproduce
No response

Thanks, I'll fix this today. We are clearly missing this test coverage too


https://www.facebook.com/khaled.nbhan.35

README.md
Related content : Guide|Tools
Issue with the content : Yes|No
Your comments here. Please read CONTRIBUTING.md before posting issues.

EVET


createRecord for an entity that contains a lookup field

In the example, var data contains only simple text.
What is the syntax when we want to update lookup field?
The field name is new_contact. I tried setting
'new_contact': "715cafd5-ff34-e911-a95b-000d3ab3a35d"
I also tried to set like this:
'_new_contact_value': "715cafd5-ff34-e911-a95b-000d3ab3a35d"
or like this:
var arr = []; arr.push({ 	id: "715cafd5-ff34-e911-a95b-000d3ab3a35d", 	entityType: 'contact', 	name: "Steven Johanson" }); 'new_contact': arr
But each time I get the error:
{"message":"Timeout occurred as no response was received from listener window"}
If I don't try to put data in the lookup field, then everything works as expected.

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

ID: d52ef470-a937-70a7-6e7f-2cbbf0002005
Version Independent ID: 395cb415-829a-76a5-4912-c6ad19e70bdd
Content: createRecord (JavaScript API Reference) for Channel Integration Framework (CIF) in Dynamics 365
Content Source: ce/developer/channel-integration-framework/reference/microsoft-ciframework/createRecord.md
Service: dynamics-365-cross-app
GitHub Login: @kabala123
Microsoft Alias: kabala

@zupermann : Thanks for reaching out. I have taken your question to the internal folks who can help. I will revert to as soon as I get the information.
Thanks for your understanding.

Hi @zupermann: Can you try the following.
Use the below format to pass lookup value.
var data =
{
"name": "Sample Account",
<EMAIL_ADDRESS>"/contacts(3518ddae-2f46-e911-8190-000d3a6ce16d)"
}
var jsonData = JSON.stringify(data);
Microsoft.CIFramework.createRecord("account",jsonData).then(
function success (result) {
res=JSON.parse(result);
console.log("Contact created with ID: " + res.id);
//perform operations on record creation
},
function (error) {
console.log(error);
//handle error conditions
}
);
Let me know if this helps.

@zupermann : Did the solution help?

@kabala123 Thank you! We will try it today.

@kabala123 This worked. Thank you for all your responses! This was really helpful.

@zupermann : Great to know that it worked! I will enhance the documentation with this sample too. Closing this issue now.

var jsonData = '{
"new_interactionid":"123SDF456789ERT5"
"description":"INBOUND:Default values for this record were set programmatically.",
"subject":"INBOUND CALL",
"new_is_validated":"False",
"regardingobjectid@odata.bind":"/contacts(715cafd5-ff34-e911-a95b-000d3ab3a35d)"
}';
function createTask() {
// use createRecord API to create a new entity record
Microsoft.CIFramework.createRecord("task", jsonData));
}
Error:
"An error occurred while validating input parameters: Microsoft.OData.ODataException: Does not support untyped value in non-open type.
at System.Web.OData.Formatter.Deserialization.DeserializationHelpers.ApplyProperty(ODataProperty property, IEdmStructuredTypeReference resourceType, Object resource, ODataDeserializerProvider deserializerProvider, ODataDeserializerContext readContext)
at System.Web.OData.Formatter.Deserialization.ODataResourceDeserializer.ApplyStructuralProperties(Object resource, ODataResourceWrapper resourceWrapper, IEdmStructuredTypeReference structuredType, ODataDeserializerContext readContext)
at Microsoft.Crm.Extensibility.CrmODataEntityDeserializer.ApplyStructuralProperties(Object resource, ODataResourceWrapper resourceWrapper, IEdmStructuredTypeReference structuredType, ODataDeserializerContext readContext)
at System.Web.OData.Formatter.Deserialization.ODataResourceDeserializer.ReadResource(ODataResourceWrapper resourceWrapper, IEdmStructuredTypeReference structuredType, ODataDeserializerContext readContext)
at System.Web.OData.Formatter.ODataMediaTypeFormatter.ReadFromStream(Type type, Stream readStream, HttpContent content, IFormatterLogger formatterLogger)"


Offer 3 voices to choose from (Male/Female/Neutral)

Male character currently uses female voice, my immersion is shattered
Voices:
Female A
1CdYZ2r52mtgJsFs88U0ZViMSnzpQ_HRp

Female B
132G6oD0HHPPn4t1H6IkYv18_F0UVLWgi

Female C
1QnOliOAmerMUNuo2wXoH-YoainoSjZen

Male A
17MQWS6m6VKkiU9KWRNGbTemZ0fIBKm0O

Male B
1AwNZizuEmCgmnpAlqGLXWh_mvTm6OLbM

Male C
1TKFdmFLttjjzByj2fZW8J70ZHjR-RTwc

Robot
1NwpxG6kQ5lxwjPyuZTR0M9qc_7bMqPUH

Implemented in new UI :)


Add lint warning for inner function marked as #[test]

Rendered
Add a lint that warns when marking an inner function as #[test].
#[test] is used to mark functions to be run as part of a test suite. The
functions being marked need to be addressable for this to work. Currently,
marking an inner function as #[test] will not raise any errors or warnings,
but the test will silently not be run. By adding a lint that identifies these
cases, users are less likely to fail to notice.
Implemented in https://github.com/rust-lang/rust/pull/51450.

I have a quick question, why do inner test functions not run?
a good use case for inner test function is the  outer function you have a  const you dont want to expose to the world. but in the inner function, you need test the outer function with the const as input for example something like sin function with pi as input but obviously the const is supposed to be hidden.

@warlord500 they cannot run because test functions need to be addressable, and inner functions aren't.
cc https://github.com/rust-lang/rust/issues/36629

CC @rust-lang/lang

Yeah, this doesn’t need an RFC.
On Tue, Jun 12, 2018 at 12:51 AM Esteban Kuber<EMAIL_ADDRESS>wrote:

CC @rust-lang/lang https://github.com/orgs/rust-lang/teams/lang
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/2471#issuecomment-396499095, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABY2UT2CUmkHggvV0hvcBJqgUAMjwOk1ks5t73LsgaJpZM4Uh52H
.

What if we use hygiene to force name resolution of the harness paths (well, they can be just single identifiers then) to occur in the definition scope of the test functions?
It could even make the harness neatly pluggable - I mean, is it different than injecting a single macro invocation with all of those hygiene-tagged names, at the top-level of the crate?
cc @petrochenkov @alexcrichton  @Manishearth

Looks like for each fn marked with #[test] we need to

create a fresh "macro 2.0" macro
register that macro as coming from the same location as fn
mark all fn's tokens as produced by that macro
copypaste the marked tokens into whatever place the test harness needs

Sounds possible if expansion of #[test] has access to full compiler APIs and runs at correct phase, not sure about details.

@petrochenkov That's an interesting approach, but wouldn't it suffice to only have a single ExprPath that resolves to a specific function without being anywhere near it?

Ah, I see, then it should look something like:

create a fresh "macro 2.0" macro
register that macro as coming from the same location as fn
mark the ExprPath as produced by that macro
copypaste the ExprPath into whatever place the test harness needs

However, if we can do what I wrote above, then we can probably directly assign resolution to the ExprPath as well.

@petrochenkov Yeah, the main reason I wanted to avoid dealing with resolution directly is for moving the test harness into a library macro, so it would literally only get one ident token per fn.

We would still meet to make sure there are no rest functions nested inside another test function, right?

@estebank I don't see how that would be a problem.

We discussed this in the lang team meeting. Our conclusion: because this doesn't work today, we should have a lint about it. If someone wants to propose a separate RFC that defines a behavior for this, they can also propose a change to the lint.
@rfcbot fcp merge

As an aside, perhaps things like putting #[test] on a trait method should emit the same lint?

One possible way it wouldn't need an RFC might be if it's a fix-a-false-negative extension of the existing unused_attributes lint, as that's already emitted by
trait Foo {
    #[test]
    fn foo() {}
}

warning: unused attribute
 --> src/main.rs:2:5
  |
2 |     #[test]
  |     ^^^^^^^
  |
  = note: #[warn(unused_attributes)] on by default

I agree with @scottmcm, if we can make the unused_attribute lint fire, organically.
Otherwise, I strongly prefer a proper solution, along the lines of what @petrochenkov described.

Per https://github.com/rust-lang/rust/issues/36629#issuecomment-404753945, this was done without the RFC being accepted?

(This is currently not implemented on stable but it is implemented in the beta compiler, which becomes stable on 2018-09-13)

It can safely be reverted. I forgot about the RFCS I'd opened when I pinged on the PR and it got approved.

I still think this should be unused_attribute, but linting it is what's really important.
@rfcbot reviewed

Hmm, does unused_attributes not fire because of the #[cfg(test)] gating, or because of the fact that the nested functions are still items and some part of the traversal hits them?
For either, I think we can move the bit that looks at #[test] attributes to look only at item children of modules, which is the only place where #[test] fn works.
I could look into it or mentor someone through it.


Remove 'Copy to Clipboard' text in OBJ drawers

Description
As discussed in demo prep, remove the "Copy to Clipboard" text in the OBJ Bucket Details and Object Details drawers.
Type of Change

Non breaking change ('update', 'change')

Going to merge this now so it's in for the demo, but I will look into getting the text vertically centered relative to the icon


B2W2 C-Gear skin support

Kinda wondering if there'd be a point to this since it would not allow as much feedom as Black & White C-Gear skins do.


[Feature Request] - Calendar Events Extension

I've been looking for a CMS that uses SQLite for my clients and that is simple for them to use(I'm a web designer). Pagekit seems like a good choice thus far, even though it's still in early development.
This is my request for an events calendar. I build sites for small businesses in my local area and the most common request I get is the ability to post an event(page or blog post) and link it to a calendar. This makes it easy for their customers can track the business's upcoming events.
I think the simplest design for this would be a calendar extension that works like making posts, then attaches a link to that post in a fully fledged calendar. Alot of the code from the pages widget could be reused here? A bonus would a widget that shows a mini calendar with upcoming events.
Just an idea for design. Perhaps just adding a calendar to the blog extension would be easier. I honestly don't know. I'm not a developer.

We are open for suggestions and pull requests :smile:


Add HiGHS open source solver

I haven't really included the "basis_fn" into the code. What is the purpose of it?
Will ask fneum in a moment when testing the installation.

This PR needs a bit more time. The solving works though what does not work is reading out the right results.
To DO's:

[ ] The installation needs to be fixed to one version.
[ ] The solution file need to be read out correctly. While the obj. is the same for CBC, highs, glpk, the optimised capacities are different. This suggest that we need to read out the data correctly (maybe also a bug in HiGHS that was fixed in a newer version)

I haven't really included the "basis_fn" into the code. What is the purpose of it? Will ask fneum in a moment when testing the installation.

The basis_fn is used to write out the basis of the solution (which can be used for a warmstart later), however if I remember correctly the IPM does support this (only used for simplex) so you can just ignore this.
Thanks for the PR, I can do the rest. Just need some time since I want to prioritze the PIPS first.

@FabianHofmann, I will solve the two points/tasks above.
Yes, I think the PIPS solver might be the most interesting one for big problems where HPC need to be used.

Should work now according to https://github.com/PyPSA/PyPSA/pull/308#issuecomment-968326026

Adjustments according to https://github.com/PyPSA/PyPSA/pull/308. I think the HiGHS solver is close to be ready to merge. Only one thing:
In the above PR, I had to change solver_options={} so that the code works also with an undefined options dictionary. Something we might need to deal with here too. Feel free to make this change if required or let me know what you wish to see (I wasn't sure about the prefered architecture)

@pz-max thanks for the code, I made some changes to make things more light-weight. Also moved some of the docstring to the solvers.rst in the documentation. Hope your fine with the changes, see #17 (all your commits will still show up in the contribution)


Using black formatting

What about using black now that it is stable and a standard tool?

By using Black, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

Personally, I'd make it checked by CI... but I'm also OK to convert the code base and fix it once in a while.
What do you think?

Up to you.
I think it will be mostly fine expect at some places.
I also don't like CI check for such think, but it's up to you. You'r the main maintainer.
Finally it will also break the whole previous open PR, but there is not so much remaining ones.

I also don't like CI check for such think

The issue when partly using black is ending with PRs polluted by some reformatting.
Now, in practice with the current activity of the project, that shouldn't be a big deal...
And even less if it is set on save in the IDE or as a pre-commit hook.
So as I said, it's OK not to have it in the CI.

Finally it will also break the whole previous open PR

Yes, it's best to do so with no PRs opened.


点击看大图时奔溃

您好  为什么选择图片的界面 不报theme的错误   而看大图的界面却报错？

@hbzkw
Thanks for reporting this bug. I found that I forgot to set AlbumPreviewActivity and SelectedPreviewActivity's theme. What is your phone's Android os version?

@hbzkw
I don't have devices to reproduce this crash. But I may have fixed it, check out https://github.com/zhihu/Matisse/pull/61. You can reopen this issue if this crash still happen.


Example with rmf_demos

Implementation of a fleet adapter that integrates free_fleet manager and clients with the RMF demos (rmf_demos commit 2371649),
The adapter is based on the existing full_control fleet adapter, with modifications to utilise free_fleet's features for control and tracking of robots.
client provides an implementation of free_fleet's client for the slotcar robot from rmf_simulation.

What's the reason to completely re-implement the adapter? Why not use the same approach as in main branch with a free fleet server sending data to rmf adapter through ROS2? With the current approach you would need to implement it for each control type (full_control, read_only, etc.).

Hello @eliasdc! There are plans to deprecate the messages the free fleet main branch uses to communicate with the RMF fleet adapter as an API call, as it doesn't extend the full capabilities of RMF to these fleets. The same goes for Full Control and Read Only, as we have released a new flexible task system.
Instead, the recommended way is to implement the fleet adapter's interfaces to suit the fleet's operations. We are currently exploring this integration.


feat: increaed severity & contextulised connectivity check error

Increases log severity level from Debug to Waarning and adds error message to entry context.

Pull Request Test Coverage Report for Build 341749220

0 of 2 (0.0%)  changed or added relevant lines in 1 file are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.005%) to 57.874%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

cmd/newrelic-infra/newrelic-infra.go
0
2
0.0%

Files with Coverage Reduction
New Missed Lines
%

internal/agent/event_sender_vortex.go
1
73.21%

Totals

Change from base Build 341584023:
-0.005%

Covered Lines:
11110

Relevant Lines:
19197

💛  - Coveralls


README: Connect to the WebSocket Server code snippet does not compile

Following the Connect to the WebSocket server section of README.md leads to the following build error:
error: cannot invoke initializer for type 'WebSocket' with an argument list of type '(url: URL)'
        WebSocket(url: URL(string: "ws://localhost:8080/")!)
        ^
note: overloads for 'WebSocket' exist with these partially matching parameter lists: (request: URLRequest, certPinner: CertificatePinning?, compressionHandler: CompressionHandler?), (request: URLRequest, engine: Engine)
        WebSocket(url: URL(string: "ws://localhost:8080/")!)

Seems like the code snippet needs to be changed to
webSocket = WebSocket(request: URLRequest(url: URL(string: "ws://localhost:8080/")!))

Missed that in the update, thanks! Should be fixed now.


Create-Inferno-App failing install with Node v.10 due to<EMAIL_ADDRESS>

I receive the following error message when using create-inferno-app after install new Node version:
yarn add v1.6.0
(node:29860) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info<EMAIL_ADDRESS>The platform "win32" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "win32" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version ">=4 <=9".
error Found incompatible module
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
Aborting installation.
I haven't had a chance to figure out which package is depending on upath version 1.0.4  and causing this error.
Edit:  This is not isolated to create-inferno-app, same issue exists with create-react-app (not suprising)

Filed this same issue with create-react-app, got a quick fix response from @retyui:

Small fix
yarn config set ignore-engines true

it worked

I have rebased all updates from the upstream, updated all the depencies to latest versions and converted the source code to ESM.
The next major version will require Node 20 or newer.


Prepare release for webapp maven plugin

Prepare release for webapp maven plugin

Codecov Report

Merging #1046 into develop will not change coverage by %.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop    #1046   +/-   ##
==========================================
  Coverage      36.27%   36.27%
  Complexity       537      537
==========================================
  Files            103      103
  Lines           4430     4430
  Branches         683      683
==========================================
  Hits            1607     1607
  Misses          2684     2684
  Partials         139      139

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b79dfbe...7440c65. Read the comment docs.


SEC partial outage

It seems the SEC Archive is temporarily down in some/all regions. Nothing I can do about it currently.
Will finish hosting my own SEC archive in the next week.

Appears to be fixed as of 8.35am PST


OCPBUGS-25594: Fix text and indentation for TLS Security Profile

Fixes wrong description which mentioned no support for tls13 was there for Modern TLS Security Profile. Fixes indentation of the godoc as oc explain command gave a description hard to understand. Issue: https://issues.redhat.com/browse/OCPBUGS-25594

/assign @rfredette

Seems inert, @deads2k is making some big changes at the moment and I wonder if he'd prefer this to be merged before or after that change, the rebase on that PR may be complex

/lgtm

/retest

/jira refresh

/jira refresh

tested it with 4.15.0-0.ci.test-2024-03-06-015831-ci-ln-xk3h6qk-latest

% oc get clusterversion
NAME      VERSION                                                   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.15.0-0.ci.test-2024-03-06-015831-ci-ln-xk3h6qk-latest   True        False         40m     Cluster version is 4.15.0-0.ci.test-2024-03-06-015831-ci-ln-xk3h6qk-latest
%

oc explain ingresscontroller.spec.tlsSecurityProfile.modern
% oc explain ingresscontroller.spec.tlsSecurityProfile.modern
GROUP:      operator.openshift.io
KIND:       IngressController
VERSION:    v1

FIELD: modern
DESCRIPTION:
modern is a TLS security profile based on:
https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
and looks like this (yaml):
ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 -
TLS_CHACHA20_POLY1305_SHA256 minTLSVersion: VersionTLS13
NOTE: Currently unsupported.
%

% oc explain ingresscontroller.spec.tlsSecurityProfile.intermediate
GROUP:      operator.openshift.io
KIND:       IngressController
VERSION:    v1
FIELD: intermediate
DESCRIPTION:
intermediate is a TLS security profile based on:
https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29
and looks like this (yaml):
ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 -
TLS_CHACHA20_POLY1305_SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 -
ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES256-GCM-SHA384 -
ECDHE-RSA-AES256-GCM-SHA384 - ECDHE-ECDSA-CHACHA20-POLY1305 -
ECDHE-RSA-CHACHA20-POLY1305 - DHE-RSA-AES128-GCM-SHA256 -
DHE-RSA-AES256-GCM-SHA384 minTLSVersion: VersionTLS12
%

% oc explain ingresscontroller.spec.tlsSecurityProfile.old
GROUP:      operator.openshift.io
KIND:       IngressController
VERSION:    v1
FIELD: old
DESCRIPTION:
old is a TLS security profile based on:
https://wiki.mozilla.org/Security/Server_Side_TLS#Old_backward_compatibility
and looks like this (yaml):
ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 -
TLS_CHACHA20_POLY1305_SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 -
ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES256-GCM-SHA384 -
ECDHE-RSA-AES256-GCM-SHA384 - ECDHE-ECDSA-CHACHA20-POLY1305 -
ECDHE-RSA-CHACHA20-POLY1305 - DHE-RSA-AES128-GCM-SHA256 -
DHE-RSA-AES256-GCM-SHA384 - DHE-RSA-CHACHA20-POLY1305 -
ECDHE-ECDSA-AES128-SHA256 - ECDHE-RSA-AES128-SHA256 - ECDHE-ECDSA-AES128-SHA
- ECDHE-RSA-AES128-SHA - ECDHE-ECDSA-AES256-SHA384 - ECDHE-RSA-AES256-SHA384
- ECDHE-ECDSA-AES256-SHA - ECDHE-RSA-AES256-SHA - DHE-RSA-AES128-SHA256 -
DHE-RSA-AES256-SHA256 - AES128-GCM-SHA256 - AES256-GCM-SHA384 -
AES128-SHA256 - AES256-SHA256 - AES128-SHA - AES256-SHA - DES-CBC3-SHA
minTLSVersion: VersionTLS10
%

/label qe-approved
thanks

/retest


Update license in komorebi.json for v0.1.29

Ensures that the license accurately reflects the new license used for v0.1.29.

[x] I have read the Contributing Guide.

Please merge this.

/verify

why the hell its still not online ?? its already online in winget months ago. is the scoop maintainers having some personal issues? i thought scoop package managers is millions time better than winget. but oh i was so wrong. a version that is already updated to winget month ago and here we are.


let port to send retry packet to validate client

This is the draft PR just for reference to monitor progress in sprint. there is no intention to merge it.
My initial implementation did send retry packets from channel. it was too late, we need to send retry packet before channel gets created. I believe this is what needs to happen:

determine we need to validate client (TODO: introduce counter to monitor half-opened connections)
if we need to validate client we need to generate new connection id
we need to generate token (TODO: token needs protection against spoofing)
port sends retry packet, packet comes from source connection ID, client will use this source connection ID as destination connection ID for next initial packet
server then receives next initial packet with validation token
server checks if token is valid
if token is valid the server must create channel and bind it to source connection id. this is the detail where devil hides

existing function port_on_new_conn() creates channel and connection id one step. connection is bound to channel. here. also keep in mind connection id is object which gets inserted to look up table.
When dealing with address validation we don't want to create any persistent objects (channel and connection id). The draft PR here introduces function port_bind_channel(). It allows us to generate random connection ID at the time server sends a retry packet. Once we receive token back with next initial packet we create channel, and connection id object and insert it to look up table. (TODO: The insertion may fail, in this case we need to send RESET packet back, so client can quickly retry to connect).
The prototype still needs some love it looks like I'e messed up insertion of connection id to lookup table. I'm not able to find the channel I've created.

to test the code use:
cd demos/quic/server
gdb --args ./server 4433 ../../../test/certs/servercert.pem ../../../test/certs/serverkey.pem

run server, add brekapoints to port_bind_channel where we create channel for validated client. continue the next packet from client should find channel using ossl_quic_lcidm_lookup() but it does not happen.
to trigger the breakpoint you need to poke to server using client:
test/quic_client_test

the goal here is to get SSL handshake working.

cd demos/quic/server

Umm...no such dir?

update: the channel is actually found. the server accepts connection. then proceeds to call to write(). The server gets stuck in write. According to wireshark the server does not continue with handshake. Client keeps retrying with initial packet, but server does send its HANDSHAKE packet.
it looks like the channel is not able to perform a handshake.

> We can see that the next Initial packet shows a retry token that is 21 bytes long (the openssltoken string plus the trailing garbage, and the next packet in the datagram (which should be the TLS client hello) is not decoded properly
the trailing garbage is original destination connection id where client did send its connection request.
see port_send_retry() function for details where validation token is constructed:
680
681     /* TODO: generate proper validation token */g
682     memcpy(token.token_buf, "openssltoken", sizeof("openssltoken") - 1);g
683g
684     token.token_odcid = client_hdr->dst_conn_id;g
685     token_len += token.token_odcid.id_len;g
686     integrity_tag = (char *)&token.token_odcid +g
687         token.token_odcid.id_len + sizeof(token.token_odcid.id_len);g
688     /*g
689      * <IP_ADDRESS> Sending a Retry packetg
690      *   dst ConnId is src ConnId we got from clientg
691      *   src ConnId comes from local conn ID managerg
692      */g
693     memset(&hdr, 0, sizeof(QUIC_PKT_HDR));g
694     hdr.dst_conn_id = client_hdr->src_conn_id;g
695     /*g
696      * this is the random connection ID, we expect client isg
697      * going to send the ID with next INITIAL packet whichg
698      * will also come with token we generate here.g
699      */g
700     ok = ossl_quic_lcidm_get_unused_cid(port->lcidm, &hdr.src_conn_id);g
701     if (ok == 0)g
702         return;g
703g
704     hdr.dst_conn_id = client_hdr->src_conn_id;g
705     hdr.type = QUIC_PKT_TYPE_RETRY;g
706     hdr.fixed = 1;g
707     hdr.version = 1;g
708     hdr.len = token_len;g
709     hdr.data = (unsigned char *)&token;g
710     ok = ossl_quic_calculate_retry_integrity_tag(port->engine->libctx,g
711                                                  port->engine->propq, &hdr,g
712                                                  &client_hdr->dst_conn_id,g
713                                                  integrity_tag);g
714     if (ok == 0)g
715         return;g
716g
717     hdr.token = (unsigned char *)&token;g
718     hdr.token_len = token_len;g
719g
720     msg[0].data = buffer;g
721     msg[0].peer = peer;g
722     msg[0].local = NULL;g
723     msg[0].flags = 0;g
724g
725     ok = WPACKET_init_static_len(&wpkt, buffer, sizeof(buffer), 0);g
726     if (ok == 0)g
727         return;g
728g
729     ok = ossl_quic_wire_encode_pkt_hdr(&wpkt, client_hdr->dst_conn_id.id_len,g
730                                        &hdr, NULL);g
731     if (ok == 0)g
732         return;g
733g
734     ok = WPACKET_get_total_written(&wpkt, &msg[0].data_len);g
735     if (ok == 0)g
736         return;g
737g
738     ok = WPACKET_finish(&wpkt);g
739     if (ok == 0)g
740         return;g
741g
742     BIO_sendmmsg(port->net_wbio, msg, sizeof(BIO_MSG), 1, 0, &written);g

the token is chain of 'openssltoken' secret followed by original destination connection id.

Ok, thank you @Sashan .  So that all makes sense then, and it seems that the problem is at least in part that the crypto packet in the retired datagram isn't getting decrypted properly.  Wireshark is indicating that the stream offset field is duplicated in the retried datagram, which may either be an error in Wireshark, or part of the cause to this issue. Will keep looking

Actually I should word that differently.  Initial packets aren't encrypted, but we're trying.ti decrypt it, so something about the first non retried frames is putting the quic.port in a state where it thinks it's not the initial tls.client hello frame

Actually I should word that differently. Initial packets aren't encrypted, but we're trying.ti decrypt it, so something about the first non retried frames is putting the quic.port in a state where it thinks it's not the initial tls.client hello frame

I assume you mean initial packets which come with validation token (come as a reply to retry packet server sent). The first such packet arriving at server creates a channel The packet is then dispatched to channel where it should be handled (it starts in ch_rx() function). So this is the place where I would start looking at, but things are more complicated because everything is running on behalf of tick(). Port just puts the packet to the queue which is consomued by channel (ch_rx()) function. The ch_rx() gets invoked from tick.

yes, that is what I mean.  Currently, what (I think) is happening is that:

client sends an initial frame without a retry token
server sends a retry frame back
client sends the initial frame again
server accepts the frame in (3), and creates a channel in port_bind_channel, doing an hkdf deriviation for the el_set keys used to decode the crypto packet in the frame in (3)
server fails crypto packet decryption

I'm guessing that, in during channel creation (likely in ch_on_new_conn_common), when we call ossl_quic_provide_initial_secret, we do the hkdf derivation using the initial dcid rather than the scid provided in the retry packet, leading to decryption errors of the crypto packet, but I need to look more closely

> I'm guessing that, in during channel creation (likely in ch_on_new_conn_common), when we call ossl_quic_provide_initial_secret, we do the hkdf derivation using the initial dcid rather than the scid provided in the retry packet, leading to decryption errors of the crypto packet, but I need to look more closely
yes this was also my guess. I have not entirely eliminated that option yet. I've just pushed changes which print connection ids to stderr. I'm sorry I have not pushed those on Saturday. I hope they will be still useful to you.

thank you!  I think we're on the right track here.  If I use this patch:
commit 0556ab493c1c75e3fe5f9b65d33cc9b56da3c147
Author: Neil Horman<EMAIL_ADDRESS>Date:   Tue Nov 5 06:43:28 2024 -0500

    Generate initial secrets based on new dcid rather than odcid

diff --git a/ssl/quic/quic_channel.c b/ssl/quic/quic_channel.c
index b8b0b0743c..0e7b2db65f 100644
--- a/ssl/quic/quic_channel.c
+++ b/ssl/quic/quic_channel.c
@@ -3364,7 +3364,8 @@ static void ch_on_idle_timeout(QUIC_CHANNEL *ch)

 static int ch_on_new_conn_common(QUIC_CHANNEL *ch, const BIO_ADDR *peer,
                                  const QUIC_CONN_ID *peer_scid,
-                                 const QUIC_CONN_ID *peer_dcid)
+                                 const QUIC_CONN_ID *peer_dcid,
+                                 const QUIC_CONN_ID *peer_odcid)
 {
     /* Note our newly learnt peer address and CIDs. */
     ch->cur_peer_addr   = *peer;
@@ -3395,7 +3396,7 @@ static int ch_on_new_conn_common(QUIC_CHANNEL *ch, const BIO_ADDR *peer,
         return 0;

     /* Register the peer ODCID in the LCIDM. */
-    if (!ossl_quic_lcidm_enrol_odcid(ch->lcidm, ch, &ch->init_dcid))
+    if (!ossl_quic_lcidm_enrol_odcid(ch->lcidm, ch, peer_odcid == NULL ? peer_dcid : peer_odcid))
         return 0;

     /* Change state. */
@@ -3416,7 +3417,7 @@ int ossl_quic_channel_on_new_conn(QUIC_CHANNEL *ch, const BIO_ADDR *peer,
     if (!ossl_quic_lcidm_generate_initial(ch->lcidm, ch, &ch->cur_local_cid))
         return 0;

-    return ch_on_new_conn_common(ch, peer, peer_scid, peer_dcid);
+    return ch_on_new_conn_common(ch, peer, peer_scid, peer_dcid, NULL);
 }

 int ossl_quic_bind_channel(QUIC_CHANNEL *ch, const BIO_ADDR *peer,
@@ -3438,7 +3439,7 @@ int ossl_quic_bind_channel(QUIC_CHANNEL *ch, const BIO_ADDR *peer,
      * peer_odcid <=> is initial dst conn id chosen by peer in its
      * first initial packet we received without token.
      */
-    return ch_on_new_conn_common(ch, peer, peer_scid, peer_odcid);
+    return ch_on_new_conn_common(ch, peer, peer_scid, peer_dcid, peer_odcid);
 }

 SSL *ossl_quic_channel_get0_ssl(QUIC_CHANNEL *ch)

then the crypto packet in the init frame sent from the client in response to the retry frame gets decoded on the server correctly, as the initial secrets are generated based on the new, rather then the original dcid, which I believe was what the client was encrypting it with.  With this, the handshake continues, but runs into an error about a dcid mismatch, which I need to track down.  Also need to read the RFC to see if there is a proscribed behavior regarding what they initial keys should use as a secret value (RFC appears vague on that).

ok, according to:
https://datatracker.ietf.org/doc/html/rfc9000#name-handling-a-retry-packet
the RFC says that re-sending the initial frame in response to a retry mandates that, because the dcid is changed to the id specified in the retry packet mandates that the initial namespace keys in the el_set be updated to reflect that, so it seems that the client side is doing the right thing, and the patch above, while a bit of a hack, is doing the right thing, so I think the next step is to figure out why we're getting a dcid mismatch error in the handshake and correct that

Appears that the problem is that the client in the re-sent inital frame includes in the TLS handshake the initial source connection id transport parameter, but neglects to fill it out

hmm, with that patch above we continue the handshake, but then fail because we don't encode the proper destination cid in the server response, after which the client closes the connection with a TRANSPORT_PARAM_ERROR.
This patch solves that:
commit ecfc56cfa1541380826ec4014db43c8dcfd22254
Author: Neil Horman<EMAIL_ADDRESS>Date:   Tue Nov 5 10:52:52 2024 -0500

    ensure that ocid is sent after a retry frame causes new inital packet

diff --git a/ssl/quic/quic_channel.c b/ssl/quic/quic_channel.c
index 0e7b2db65f..4224996d72 100644
--- a/ssl/quic/quic_channel.c
+++ b/ssl/quic/quic_channel.c
@@ -1716,6 +1716,7 @@ static int ch_generate_transport_params(QUIC_CHANNEL *ch)
     WPACKET wpkt;
     int wpkt_valid = 0;
     size_t buf_len = 0;
+    int rc;

     if (ch->local_transport_params != NULL || ch->got_local_transport_params)
         goto err;
@@ -1733,8 +1734,14 @@ static int ch_generate_transport_params(QUIC_CHANNEL *ch)
         goto err;

     if (ch->is_server) {
-        if (!ossl_quic_wire_encode_transport_param_cid(&wpkt, QUIC_TPARAM_ORIG_DCID,
-                                                       &ch->init_dcid))
+        if (ch->odcid.id_len == 0)
+            rc = ossl_quic_wire_encode_transport_param_cid(&wpkt, QUIC_TPARAM_ORIG_DCID,
+                                                           &ch->init_dcid);
+        else
+            rc = ossl_quic_wire_encode_transport_param_cid(&wpkt, QUIC_TPARAM_ORIG_DCID,
+                                                           &ch->odcid);
+
+        if (rc == 0)
             goto err;

         if (!ossl_quic_wire_encode_transport_param_cid(&wpkt, QUIC_TPARAM_INITIAL_SCID,
@@ -3371,6 +3378,9 @@ static int ch_on_new_conn_common(QUIC_CHANNEL *ch, const BIO_ADDR *peer,
     ch->cur_peer_addr   = *peer;
     ch->init_dcid       = *peer_dcid;
     ch->cur_remote_dcid = *peer_scid;
+    ch->odcid.id_len = 0;
+    if (peer_odcid != NULL)
+        ch->odcid = *peer_odcid;

     /* Inform QTX of peer address. */
     if (!ossl_quic_tx_packetiser_set_peer(ch->txp, &ch->cur_peer_addr))
diff --git a/ssl/quic/quic_channel_local.h b/ssl/quic/quic_channel_local.h
index 7cafa109c4..232201c23e 100644
--- a/ssl/quic/quic_channel_local.h
+++ b/ssl/quic/quic_channel_local.h
@@ -106,7 +106,7 @@ struct quic_channel_st {
      * Randomly generated and required by RFC to be at least 8 bytes.
      */
     QUIC_CONN_ID                    init_dcid;
-
+    QUIC_CONN_ID                    odcid;
     /*
      * Client: The SCID found in the first Initial packet from the server.
      * Not valid for servers.

I'll push these to a scratch branch in a bit.
That gets the negotiation a little farther, but we now fail on another parameter error (which I'm guessing we never tested as we don't normally do retry packets).  With the above patch we encounter another parameter error, specifically a missing QUIC_TPARAM_RETRY_SCID param, which we never encode at all.  QUIC_TPARAM_RETRY_SCID is an extended param that is part of the QUIC retry offload draft RFC:
https://datatracker.ietf.org/doc/html/draft-ietf-quic-retry-offload-00
Apparently when this was coded we check for its presence on receiption, but we never do the encoding at all.
Given that the above draft RFC expired in November of 2022, and was never updated or replaced, I'm inclined to just rip that code out, as it appears its not likely to get codified as a standard at all

Based on discussion with @vavroch2010 I'm going to take the issues i've found and split them into separate issues so we can work on them in parallel.  I'll add the task list to the top of the issue associated with this PR

You should also try client with cloadflare quic server, this is not build by default. If I remember correct the cloudflare server validates client. This is what you need to do to get build it and test it to capture quic packets
cd $YOUR_OPENSSL_ROOT
git clone --recursive https://github.com/cloudflare/quiche cloudflare-quiche
./Configure -d enable-external-tests enable-unstable-qlog
make
make TESTS='test_external_cf_quiche' test

Once the above is done you can run it in your own which is useful if you need to watch client in debugger
cd $YOUR_OPENSSL_ROOT
export SRCTOP=`pwd`
export BLDTOP=`pwd`
export QUICHE_TARGET_PATH="$BLDTOP/quiche"
"$QUICHE_TARGET_PATH/debug/quiche-server" --cert "$SRCTOP/test/certs/servercert.pem" \
     --key "$SRCTOP/test/certs/serverkey.pem" --disable-gso \
     --http-version HTTP/0.9 --root "$SRCTOP" --no-grease --disable-hystart

The client is the one we use (test/quic_client_test)

hey hey!  With my hacked up code from the 3 tasks listed here quiche seems to work nicely!

this is no longer relevant, the change will be delivered by #25890


Dock Monitor is white and has artifacts on dropdown menus

My dock is looking discolored, and the arrows on the state dropdown menus are having "artifacts".
I'd supply you with some information to make it easier for you to help out, but quite frankly, i don't know what you'd need. I followed the Redux Devtools Walkthrough, in setting it up.
This is how it looks:

Could it be that some styles of your page override monitor styles?
If it's not the case - what does this command return? (I wonder which versions you are using exactly)
npm list | grep -E "(redux-devtools|react-json-tree)"

For example, I reproduced it by defining global div style:
div {
  background: #FFF;
}

You were right, there was a global div state, which my collaborator had set, apparently.
Thanks for the help, it would've taken me a while to debug on my own! Have a nice day!


Cannot assign value of type 'AppDelegate' to type 'GIDSignInDelegate!'

Cannot assign value of type 'AppDelegate' to type 'GIDSignInDelegate!'

I have added both -
#import <Google/SignIn.h>
#import <Google/Analytics.h>
in the Bridging header file.
I have installed the google SDK from cocoapods '/Library/Ruby/Gems/2.0.0/gems/cocoapods-1.2.0/lib/cocoapods.rb'
This is the AppDelegate declaration -
class AppDelegate: UIResponder, UIApplicationDelegate, GIDSignInUIDelegate {

Step 2: Describe your environment

xcode 8
iOS 10

Observed Results:

Compiler Error - Cannot assign value of type 'AppDelegate' to type 'GIDSignInDelegate!'

Relevant Code:
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
  // Override point for customization after application launch.
  self.initialize()
  IQKeyboardManager.sharedManager().enable = true
  TimeSyncManager.sharedInstance.syncTimeWithServer(withNotifcationOption: false)
  AppScreenManager.sharedInstance.setUpInitialScreen()
  SDKApplicationDelegate.shared.application(application, didFinishLaunchingWithOptions: launchOptions)
  //setUpGoogleSDK()

  var configureError: NSError?
  GGLContext.sharedInstance().configureWithError(&configureError)
  assert(configureError == nil, "Error configuring Google services: \(configureError)")

  GIDSignIn.sharedInstance().delegate = self      //<<--------Error at this Point

  application.registerForRemoteNotifications()
  UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .sound, .badge]) {
    (granted, error) in
    //Parse errors and track state
  }
  return true
}

You need to declare the protocol GIDSignInDelegate on your class, its separate from GIDSignInUIDelegate.


Add touchscreen and RTC to feature matrix

Touchscreen working perfectly, RTC not :/

Also maybe something about thermal management. It seems at least somewhat broken? I sometimes get a thermal panic when kernel compiling, so it's clear that the kernel is not consistent with thermal throttling. (Maybe it's just not doing any throttling at all?)

Also maybe something about thermal management. It seems at least somewhat broken? I sometimes get a thermal panic when kernel compiling, so it's clear that the kernel is not consistent with thermal throttling. (Maybe it's just not doing any throttling at all?)

<EMAIL_ADDRESS>looks like it isnt

<EMAIL_ADDRESS>looks like it isnt, or at least, not properly.

Hm but something is still wrong though, these patches are included in the 6.12-rc5 branch used in this repo, but I still got a thermal panic just yesterday using this kernel.

Weird, I'm not getting thermal panics 🤔 I can try to make mine panic while building the kernel.

Required conditions for overheating for me:

Kernel compile (a full one, at least ~10 minutes in)
Laptop on a flat surface. I got the advice on matrix to elevate the back of the laptop a little to get better airflow, and that indeed does seem to avoid the overheating.

On overheating the laptop simply shuts down. I can see the following messages afterwards using journalctl -b -1:
Nov 09 23:34:20 cobalt kernel: thermal thermal_zone26: cpu2-0-btm-thermal: critical temperature reached
Nov 09 23:34:20 cobalt kernel: reboot: HARDWARE PROTECTION shutdown (Temperature too high)
Nov 09 23:34:20 cobalt systemd-logind[1401]: The system will power off now!
Nov 09 23:34:20 cobalt systemd-logind[1401]: System is powering down.


GitLens showing commits by me as multiple different contributors

Issue Type: Bug
I don't know how to reproduce this, I'm assuming it has something to do with the interaction between GitLens and GitBash for windows since I don't have the issue on MacOS.
On the file blame, end of line blame, and GitLens explorer, my commits are shown under "You", "Cody Sayer", and "CodySayer".
It doesn't hinder functionality at all, but it looks wonky saying me, myself, and I contributed to this code.
Extension version: 9.5.1
VS Code version: Code 1.32.3 (a3db5be9b5c6ba46bb7555ec5d60178ecc2eaae4, 2019-03-14T23:43:35.476Z)
OS version: Windows_NT x64 10.0.17763

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 x 2808)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
15.88GB (8.15GB free)

Process Argv

Screen Reader
no

VM
50%

Is it possible that you have committed code to that repo with more than 1 username/email? If you do a git log of the file in question, do you see different author names?

I am closing this issue because it needs more information and has not had recent activity.  Please re-open this issue when more details can be provided.
Thanks!


Adding functionality to bookmark folders

This is a very handy functionality that lets us bookmark folders, and easily navigate to them in the future, rather than manually creating aliases for navigating into each folder.
Sample Use Case
cd /Applications/mywebapps/app1
bookmark app1

then next time  you could directly do
go app1

rather than having to cd into the folder manually.
P.S. - Been using this functionality for a long time, can't remember its original author. Code's been heavily modified by me now. :-)

:+1:


Not Redirect to shopify Embeded

After installation screen its redirecting to me on this url instead of using domain
http://https/?hmac=e0a979ed0112ba0cdb0c68cf8c2ff3a5aedac602cbce2dc396f9a9f1b676c9cf&shop=development-reset-iv-hydration-therapy.myshopify.com&timestamp=1585133101
After installing unlistd app its redirect on above screen without my custom domain

No issues here. Fresh install.
Please record the URL you're sent to by Shopify and report back.
There should be a redirect param on the URL.

Closing to inactivity. Reopen if still issue.


clarification on what is expected with /eth/v1/beacon/headers

2 Query parameters, slot and parent_root, and it's stipulated if no parameters are specified that slot defaults to head...

what if both parameters are specified? is it invalid, an OR, or an AND condition?

Assuming it's an AND (or OR really), does slot default to head only if there's no parent_root specified?

Assuming it's not defaulting slot, and a user specifies parent_root only, then is the expectation that the result would be all canonical and non canonical blocks with this parent?

If the block is finalized and only the canonical chain is stored, then we might only get the block with the parent_root on the canonical chain, because some clients may not store blocks that didn't make the chain long term. is that adequate for this endpoint?

what if both parameters are specified? is it invalid, an OR, or an AND condition?

I don't think there is much benefit in OR condition while AND can be useful to get blocks with parentRoot where slot is immeditately after parent slot.

Assuming it's not defaulting slot, and a user specifies parent_root only, then is the expectation that the result would be all canonical and non canonical blocks with this parent?

yes

If the block is finalized and only the canonical chain is stored, then we might only get the block with the parent_root on the canonical chain, because some clients may not store blocks that didn't make the chain long term. is that adequate for this endpoint?

You are returning what you have, if that's only canonical block thats fine, if client has some flag to keep all non-canonical blocks they can return those as well I guess.

closing ticket, I think this has pretty much gone stale at this point.


Ubuntu 18.04 in Hyper-V Quick Create VM gallery

I'm opening this, because setting up Ubuntu 18.04 with acceptable graphics performance seems to be not there #28.
Microsoft has told to work on delivering Ubuntu support right from the quick create VM gallery.
Idea of this issue is that everyone who would like to use Ubuntu through Hyper-V, can track this issue, and once it's delivered to quick create gallery we know it's done.

excited to see this. not that i couldn't implement enhanced mode using the instructions you can find around the web.  but it'd be nice to just one-click install from the quick create vm gallery.  thx all.

Hey all, just a friendly ping to let you know that we're still working through the process of bringing this to the quick create gallery. Really appreciate your patience in the meantime. And sure, we can use this issue and I'll close it out once it goes live...

Also eagerly waiting for the feature.

Can't wait for this!

@cwilhit any chance to see other distros in the gallery. Personally would love to see Fedora there

@tkiraga A tempfix would be to add a local gallery using the reg-key

You can now find the Ubuntu VM in the Quick Create Gallery. Thanks all for your patience up to this point--took a little longer than expected, but we got there: https://blogs.windows.com/buildingapps/2018/09/17/run-ubuntu-virtual-machines-made-even-easier-with-hyper-v-quick-create/#K45BZAclDJ9Ql6h6.97


Key not found: "consul_0.6.3_linux_amd64"

When I try to run the latest master of this cookbook I get this error. It seems that this key is not provided in consul_installation_binary.rb. Only linux-x86_64 is listed there. It still worked in version 1.4.3, when these keys were part of the attributes file

What are you trying to do?

I'm trying to install consul though this cookbook on debian 7.

Yes, I guess I am confused with your error message. Would you be able to put the log in Gist? You should be able to run kitchen converge default-debian-79 to get an instance with Consul installing and running.

I assume the problem is that this node attribute "node['kernel']['machine']" contains: amd64. But this is not  listed anymore. It basically is the same as x86_64.
The error is:
       Error executing action `enable` on resource 'consul_service[consul]'
       ================================================================================

       KeyError
       --------
       key not found: "consul_0.6.3_linux_amd64"

Please try again!

unfortunately the error still comes up.
This is what I use in my kitchen file:

driver:
name: vagrant
provisioner:
name: chef_zero
platforms:

name: debian-7.9
driver:
box_check_update: true
platform: debian
provision_command:
- apt-get update

Okay!
I'll give that a try this afternoon.
Sent from my iPhone
JB

On Mar 17, 2016, at 12:09, Michael Küller<EMAIL_ADDRESS>wrote:
unfortunately the error still comes up.
This is what I use in my kitchen file:
driver:
name: vagrant
provisioner:
name: chef_zero
platforms:
name: debian-7.9 driver: box_check_update: true platform: debian provision_command: - apt-get update
—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub

Oh, sorry for bothering you! I just noticed my tests were referencing an older commit of you github repository, which is why the errormessage did not make sense with your current code.


modify the generate_hostfile to support running on florence system

Support to run on florence system on multi-nodes.

@rogerxfeng8 @delock


feat: Implement latest LocalStorage db files checker

also reformat import
Fixes: #10

This doesn't seem to work for me after updating Wuthering Waves. When updating, the LocalStorage files are updated with the new version but not necessarily the latest union level, and then the RPC selects the most recently modified, which is the one with the highest number, which also seems to often not even contain the union level. I like the idea however. Updating the logic of getting the latest database file to check which file has the highest union level should fix the issue