Create a downloader component separate from the stages

Describe the feature
Currently we have two downloaders: a concurrent one for bodies and a linear one for headers.
Ideally, both downloaders would be concurrent. They have some shared logic:

They both build requests for batches of data
They both validate their responses

For headers, the check is whether they are sequential and connected
For bodies, the check is whether the transaction root and the ommers root matches what is in the header

They optionally transform the responses into something more manageable for the stages

Both of the downloaders also have retry logic and peer penalization.
Both downloaders also have their own issues:

The header downloader is linear, but it could be concurrent if we request headers by block number
The body downloader is concurrent, but is limited by the slowest peer, and the ommers/tx root check is expensive for some blocks

These issues lead to not saturating the network properly: each downloader, at some point, is not requesting as much data as it could, for various reasons. This leads to slow sync times for online stages.
To address these issues, the plan is now to create a downloader component that lives outside of the stages, with a channel to communicate with the stages.
High level plan

Create a new downloader component that downloads batches of headers and bodies optimistically
The stages should not build requests for bodies or headers; they just ask the downloader for the next header or body

Point 2) also means that the downloader component must satisfy these invariants:

Headers and bodies returned from the downloader component must sequentially connect and be valid according to the pre-validation rules we use now
The downloader must pre-emptively download as many headers or bodies as it can given the information it has (within some limit)

Flow

The downloader is instantiated alongside the pipeline
The downloader is given the current fork choice state (the tip) and our current local head (if any)
The downloader moves into an idle state
On the first request for a header or body, it will start downloading

If the request was a header, it will start downloading all the headers it can
If the request was a body, it will start downloading all the bodies it can

The stage that requested a header or body will either:

Get the data
Be told that we reached the tip (i.e. there is no more data for now)
Be told that we've re-orged (see reorg section)
Be notified that some super fatal error occured (see error handling section)

If data was received in the previous step, that piece of data is removed from the internal buffer of the downloader

Data is assumed by the stages to be in order and valid, so the stage should just insert the data into the transaction. If no more data is available, the stage should commit whatever it has written to the transaction already.

The downloader MUST not download headers and bodies at the same time, see the concurrency section.
It is up to the stages to control how much data to request, i.e. it is OK for stages to only ask for e.g. 1000 headers and commit.
Concurrency
The bodies are already downloaded concurrently and the headers will follow the same general idea:
For a range of block a to b, slice the range into n batches and request each batch from idle peers in the set, at most c at a time. Note that the batch size for headers and bodies should be different because of the fundamental constraint for request size being the message size limit of devp2p.
For headers to be downloaded concurrently, we have to request headers by block number instead of block hash.
There was some thought about downloading headers and bodies optimistically at the same time (i.e. as soon as a header has been downloaded, download the corresponding body), however this does not make a lot of sense for two reasons:

Concurrent downloads only really make sense during initial sync (or a sync of a longer range), during which we will most likely be stuck at the header stage for a long time (hours). If we downloaded bodies at the same time, we would just be wasting memory, as those bodies would not be accessed for quite a while.
For the above point an idea would be to write headers and bodies concurrently, but this trashes the database since it would interleave database pages containing headers with database pages containing bodies. This is unavoidable after initial sync, but does have performance implications for iterating a long range of e.g. headers sequentially.

Validation
For headers:

Check that the header hash is correct
Check that the header connects to our current data (either reverse or forward, depending on mode of operation)

For bodies:

Check that the tx root of the transactions in the body matches tx root in the header
Check that the ommers root of the ommers in the body matches the ommers root in the header

Note that the validation for bodies can be expensive
Configuration
The following parameters at least must be configurable:

The size of the internal buffer for headers (i.e. how many headers to have in memory at most at any time)
The size of the internal buffer for bodies (i.e. how many bodies to have in memory at most at any time)
The concurrency of the downloader (i.e. the maximum number of requests to have in-flight at any time)

This could technically be adjusted dynamically with info from the networking component (more peers -> higher concurrency)

The batch size of the requests for headers (i.e. how many headers to at most ask for from a peer per request)
The batch size of the requests for bodies (i.e. how many bodies to at most ask for from a peer per request)

Client vs downloader
The downloader sends requests to a client. For most of sync, this client will be the FetchClient in the networking component, which forwards requests to peers.
The reason the client is separated from the downloader itself is so it can be swapped; this is particularly important for post-merge syncing where syncing from a consensus client via the engine API is more appropriate - it is still possible to ask execution client peers for block data, but this will lead to us always being a bit behind.
Post-merge download
The consensus client will post new blocks to us via the Engine API. These new blocks (called payloads) should be kept in-memory by some component (TBD) until the consensus client sends a new forkchoice state. When the forkchoice state is sent, we need to figure out what payloads are now on the canonical chain and which we can discard. The new canonical blocks are kept in a buffer for the downloader to pick from later.
I propose that this buffering mechanism between EL/CL is kept in a engine API-specific downloader client. At some condition, we switch between the P2P client and this engine API client. This switching logic can be handled in a client that wraps both the P2P client and the engine API client.
Error handling
The downloader should internally handle timeouts, invalid responses, and retries. These should not propagate to the stages themselves.
The only errors that should propagate to the stages themselves are fatal errors from which the downloader can never recover. This will mean that the stage will block until it gets more data, however, this is fine since the pipeline cannot meaningfully progress without the requested data.
Re-orgs
The downloader should keep track of whether a re-org occurred or not and communicate this to the stages. For beacon consensus this would occur when a fork choice state is sent from the consensus layer to us and the new tip does not connect directly onto our local head.
The downloader should emit an event upon request of data containing:

The new tip
The latest block we have that connects to this tip

Upon receiving this event online stages must unwind to the latest block we have that connects to the new tip in order to discard any data that is no longer on the canonical chain.
In my opinion this can be left for later when we have the engine API and are able to meaningfully test it
Additional context
Supercedes https://github.com/paradigmxyz/reth/issues/744, https://github.com/paradigmxyz/reth/issues/741 and https://github.com/paradigmxyz/reth/issues/391

Create a new downloader component that downloads batches of headers and bodies optimistically

we're already doing this for bodies, right?
Can you elaborate on separate?
At this point I'm thinking we can achieve all that just by converting the downloader into a Stream type

we're already doing this for bodies, right?

No, they are not downloaded optimistically. The bodies stage asks for a range of bodies and then the current downloader will download only that range. If we are blocked on e.g. the first body, then we are spending a lot of time where we are not downloading anything. The main idea here is that the downloader will try to download as much as possible on its own, not only when the stages ask for a range of data.

Can you elaborate on separate?

In reference to what specifically?

If we are blocked on e.g. the first body, then we are spending a lot of time where we are not downloading anything.

blocked by what exactly? Do you refer to the execute function of the BodiesStage? which only tries to download a fixed batch per invocation which takes as long as the longest response + valdition (worst case first request arrives last), hence preventing follow-up downloads. This could be fixed by turning the bodies downloader into a stream itself that automatically sends new requests once a response arrived.

In reference to what specifically?

separate to what: do we want to extract them out of the stages (Headers,Bodies)?

This could be fixed by turning the bodies downloader into a stream itself that automatically sends new requests once a response arrived.

Hmm it sounds plausible that this may be addressable this way without a larger refactor? Do we still want to do the refactor as it should improve headers download speed as well?

Hmm it sounds plausible that this may be addressable this way without a larger refactor? Do we still want to do the refactor as it should improve headers download speed as well?

I would want the refactor to be done, it makes sense to merge the downloaders into one since they are so similar. It also makes sense to lookahead and download as much as possible.
If we just turn the bodies downloader into a stream we would likely still have the same issues I think? In the sense that the stage will request what it needs, no more. If we want it to request more than it needs, then there is a lot of additional logic needed in the stage and it ends up not really benefitting us in that sense

separate to what: do we want to extract them out of the stages (Headers,Bodies)?

I'm still not entirely sure what you mean. If you are referencing this line:
"The reason the client is separated from the downloader itself is so it can be swapped; "
Then what I mean is that the downloader component itself takes some trait Client (like the current downloaders do) so we can swap out the current FetchClient, that talks to P2P, to an EngineClient that talks to CL.

blocked by what exactly? Do you refer to the execute function of the BodiesStage?

Slow peers.

This could be fixed by turning the bodies downloader into a stream itself that automatically sends new requests once a response arrived.

See above: we request a range of blocks 0..1000 divided into, say, 10 batches. The bodies stage does not request more than it needs, and I don't think it should even if it could; it just seems a bit leaky?
If the last 9 batches arrive, and the first batch is blocked on a slow peer, then naturally we should repurpose the fast peers to download all the other batches. If the downloader component was separate, it could:

Download up to buffer_size bodies concurrently from as many peers as possible
If a batch is slow, no problem, we just keep requesting other batches from other peers until the buffer is filled.

In the current case, each time the bodies stage is executed, we will probably end up talking to the slow peer, which means that if the peer takes 20 seconds to respond, that's 20 seconds wasted for every commit_threshold number of bodies. In the case described above, this would be minimized since the other good peers would get more requests, so the total amount of wasted time "per batch" is lowered.
Hopefully that makes sense?

If we just turn the bodies downloader into a stream we would likely still have the same issues I think?

in Stage::execute we know the endblock right?
this is what we should use for the downloader, so even if the stage only fetches commit_threshold blocks the downloader can still send a followup request for every response it yields to the stage

Ok I think I understand now, basically we would have a long-lived stream with an internal buffer and e.g. the bodies stage would:

Hint what the latest header is
Hint what block we downloaded last
Poll the stream up to a max of commit_threshold times

And the stream would:

On each poll, if the internal buffer is less than the max size, request bodies concurrently until the buffer is full
Of course, once a body is returned, it is removed from the buffer

(and all the other stuff like validation, making sure bodies are returned sequentially etc)

Closed, we now spawn our downloader tasks #1055 #958


result prefix

Hi, I would spend big of time of creating pull request (I have not created branch, etc.) with this:
https://github.com/blueskydigital/extract-gettext/commit/7872001191c08843fcfe7569d57709cc01cc2a99
if you want, you can add it :)
Cheers, V.

Hi, sorry I missed this (should check my github projects more often).
I've published a new version https://github.com/mvhenten/extract-gettext/commit/e1610ba09391850ad59e376ef6880d4d5b314056 that should make things simpler. LMK if you would like me to backport your feature.

See personal email bottom of the readme.


Jenkins CLI fails

Experience this issue:
https://issues.jenkins-ci.org/browse/JENKINS-23232
with the container

dupe of #116


Simplifies exports on index, including all exports from pertinent files

This is just a nice-to-have. It simplifies the surface of xstate imports.

Wasn't sure what this would be considered in terms of a changeset. It shouldn't impact anything downstream though, so patch?

There is actually one possible breaking change in this. The function isActor was replicated in both Actor.ts and utils.ts. I removed the one from Actor.ts in favor of the utils.
Also apologize about accidentally including commit & revert of screaming snakecase change of actionTypes. I can toss this pull req and open a new one that is rebased.


Help users avoid creating/seeing duplicate accounts

Sometimes a user in a realm creates a second account, which causes confusion for someone trying to search/narrow to find things they've posted. Some reasons:

moving jobs/schools/etc. and losing access to an old email address, and thus to password reset emails
coming back after a while away, forgetting that they have an old account (or forgetting the email address for it), and creating a new one
testing and bots

I run into this at chat.zulip.org when I start typing a user's name in a field that autocompletes (like search or @-mentioning) and I see multiple user accounts. Sometimes it's like:
Cordelia<EMAIL_ADDRESS>Cordelia<EMAIL_ADDRESS>Cordelia-bot<EMAIL_ADDRESS>When, for instance, I'm typing a message to someone, it's clear to me that I don't want to @-mention the bot account, but which of the other two user accounts should I use?
I'd like to reduce how often I run into this. This might benefit from a few approaches, like:
a) help users avoid accidentally creating duplicate accounts (e.g., clearer instructions on login pages)
b) if a new account's been registered and it seems like a duplicate, notify the admin so they can try to fix it by editing/resetting the old account
c) if an autocomplete shows two accounts with the same display name, use boldface, greying, or some other UI hint to tell the user which of these accounts is most likely the one I want to talk to (using proxies like whether it's been active more recently, or has 10x as much of a posting history)
Probably the choices of approach depend on the reasons why people create second accounts. I haven't researched it and I'm sure I missed things.
Followup to #4235.

For chat.zulip.org in particular, we should add a small note in docs/chat_zulip_org.html that test accounts should use a certain naming scheme with "Test" in the name, since for some folks it's intentional (they want to have a a second account to test PMing with themself on mobile, or whatever).

Another thing we should fork off this issue is improved typeahead; opened https://github.com/zulip/zulip/issues/4249 for the most natural thing to do here.

A nice idea would be to actually show the user any other users with the same or similar names in the 2nd step of the registration flow (after we've confirmed their email and that they're allowed to join, where we're prompting them for name and ToS acceptance) to help them avoid collisions and also discover this sort of situation.  What do you think about that @brainwane?

I cautiously like that idea. Since it's after we've confirmed their email, there's less of a privacy risk to the existing user (in case they're truly different people), and we can point them to how to contact the org admin to say "hey that's actually my account" and let them handle that authentication out-of-band or however they want to do it.


Centralize Duplicate Code

This helps de-duplicate a lot of the parsing code. Just makes it a little more convenient to have a namespace interface.

Is there a reason for superflore to use its own package manifest parser rather than relying on catkin_pkg?

@nuclearsandwich That's a good question -- I'll check that. Would be nice to cut out this section of code.

That's a good question -- I'll check that. Would be nice to cut out this section of code.

Here's an example of bloom's entrypoint into package manifest parsing. You can point catkin_pkg at a directory and it will find packages whether you give it a repository root with multiple packages in subdirectories or a single package.
https://github.com/ros-infrastructure/bloom/blob/master/bloom/generators/debian/generate_cmd.py#L102

@nuclearsandwich I centralized the catkin_pkg logic, thanks for pointing me to it!

Ok, I think I'm done with this one now. Using some tools (namely pylint), I found some duplicated sections of the code and did some significant reduction.

Make sure you add catkin_pkg to the setup.py. I'd suggest requiring at least 0.4.0 as that is the version that includes package.xml format 3 support.

I should actually add some tests for the new functions first.

@tfoote Ok, this is ready for another look now.


My account keeps resting to its default state.

What happened:
The wallet was synced normally, but the channels I follow did not sync and "are gone". And now the channels are also gone from the website and the app.
This has happened to me four times now once when using the LBRY app on MacBook Pro Retina, 15-inch, Mid 2015 and three times when using the lbry.tv website. I use the Brave Browser.

Sorry to hear, this is a known bug in some rare cases. I replied on Reddit with what the next steps are and for additional information. Please give us a reply there.


Support Multi-Cluster name resolution with Consul

Describe the feature

For name resolution across multiple connected clusters, Consul should be able to resolve Dapr services across clusters. This will enable service invocation across Dapr services distributed across multiple services
This is in alignment with the proposal - https://github.com/dapr/dapr/issues/5389
Release Note

RELEASE NOTE:
ADD Multi-Cluster service invocation with Consul building block

@artursouza @yaron2

/assign

Can you define "connected clusters"?
No objection to the name resolution across cluster, but I don't think this addresses service invocation.
Please do outline how clusters must be connected for this to work.


It is recommended to change the neovim selection to the vscode selection

Pressing f1 or ctrl+shift+p is very troublesome, we need simpler functions to make its experience more similar to neovim.
I have made this suggestion many times, but I have never received a response. I want to know what are you worrying about? The early 0.62 also supports this feature, why cancel it?

Making multiple issues about same feature won't help to deliver them. Dup of #778


add message about what will happen when text is too long

@beckylettenberger @brianboyer added this but would like an edit -- warning text can be edited/viewed here under 'save warning' key https://docs.google.com/spreadsheets/d/1pogl4JaaIkEcXvPu2zDbTo_I4uLNSEm0vB8WxnNPBuU/edit#gid=1


Get selected element from list with a tabulation

Hi,
I wonder how to select a choice from a list or combo by tab key on keyboard.
At this time, tab key leave the dropdown list or combo without proceeding to a choice into the dropdown. So user has to
1- write his choice or move into the dropdown list with arrows
2- click on his choice or press return to accept the selection.
Is it a real issue, a nice feature to have or simply impossible?

I think is possible. To start, add an event with jQuery to the input that is used for it, then catch the tab key and cancel it and then add $(this).data('selected', []) your choices.
Please as questions on the forum. Issues are strictly for bugs.


ImgBB does not work

As far as I know I cannot get imgbb links to work.

Visit the sharable link. Right-click on the picture there and select "Copy Image Address".


Can't match multiple depth arrays with wildcard

I have the following rule:
{
  "props.exit_urls.*.url": "required"
}

But when I post the following data:
props[exit_urls][0][url] = ''

It isn't matching the rule.
I tried running the regexp  arrayExpressionRegex parser rule in src/Parser/index.js and it appears to only match everything after props..

Yes, since Indicative doesn't allow multiple nested arrays. It only support one level deep. Mentioned in docs too http://indicative.adonisjs.com/#indicative-basics-array-expressions
But can we?
Yes we can, but I have to spend some more time the Indicative validation engine, and frankly saying I don't know when I will work on it
Quick fix.
When using Adonis route validator, I define a custom data object documented here and simply limit them to one level of nesting.
If you have too much nested data, this will be pain, but for couple of keys, I believe you can transform them to one level of depth.

Would swapping indicative for https://www.npmjs.com/package/validatorjs be an option as they work quite similarly

You can try to use that package manually if you want.

@simontong I have added support for this too, will be released soon

thanks, i'll keep an eye out

Closing this since it's fixed in the new release of the framework (4.1).
Please upgrade (it takes only a few minutes).


Tech Radar: Entries overlap with Ring names

Expected Behavior
Entries in the Tech Radar should be clearly visible and not overlap with the Ring label.
Actual Behavior
Tech Radar entries overlap and obscure the Ring label
Steps to Reproduce
Example screenshot:

Create a Tech Radar
Add a bunch of entries to a Ring
Once you add enough they start overlapping the Ring label

Context
It's not breaking anything, it's just annoying and doesn't look good.
Your Environment
N/A I'm using a hosted instance from Roadie

Browser Information: Google Chrome Version 105.0.5195.102

Output of yarn backstage-cli info: N/A I'm using a hosted instance from Roadie

Hi, would love to contribute to this!
This will be my first time contributing to open-source.
I'm decently good with JS/TS and ReactJS. Would love to hear a response from you :)

@rutviklhase I'm sure the maintainers of this repository would love for you to contribute!

Indeed, would be awesome to get some help with this @rutviklhase 😁
Let us know if you have any questions. Some initial pointers would be to try to keep the change as minimal as possible. It's implemented with a d3 force simulation, so I would suspect that the cleanest approach would be to add a slight force acting away from the ring names, without having all the entries getting too bunched up.

Hi, is this still being worked on and is it still relevant?
I'm looking to make a first time contribution and think that this might suit me :)

@Linneaiv Never got a chance to work on this, unfortunately. You can take it up if you want to

@Linneaiv All yours to try if you want!


Module not found when using type from .d.ts file

I started this issue on angular/angular issues, but seems to be related to CLI, so just copy-pasting the issue here :).
I'm submitting a ...
[x] bug report

Current behavior
When assigning a custom type (like Post, or User) to a decorated property (with either ng decorator like @Input() or a custom one), where type is declared in d.ts file, angular throws an error:
ERROR in ./src/app/app.component.ts
Module not found: Error: Can't resolve './types' in '/home/dracco/projects/ng2/src/app'
 @ ./src/app/app.component.ts 11:0-31
 @ ./src/app/app.module.ts
 @ ./src/main.ts
 @ multi webpack-dev-server/client?http://localhost:4200/ ./src/main.ts
webpack: Failed to compile.

This does ** happen if:

type is added through generic (like Array<Post>) OR
no decorator is added to property OR
file with declaration has .ts extension instead of .d.ts

Expected behavior
No error should be thrown. property should have given type.
Minimal reproduction of the problem with instructions

Run ng init to create a new Angular project.
Create a d.ts file in app folder
Add an exported interface to the .d.ts file
Import above interface in component file
Add a property with decorator and above type (e.g. @Input() prop: MyType)
Run ng serve

What is the motivation / use case for changing the behavior?
The default workflow in TypeScript suggests keeping declarations and interfaces in .d.ts file. Simple Angular components might not use Observables and still accept data from the host. I am actually surprised nobody mentioned and solved it so far as it is pretty severe (it also happens in 4.0.0-beta.8).
Please tell us about your environment:

OS: linux x64 (Ubuntu 16.10)
Angular version: 2.3.1, 2.2.4, 4.0.0-beta.8
Angular CLI version: 1.0.0-beta.28.3
Node (for AoT issues): 7.5.0
NPM: 4.1.2

Possibly has to do with this issue.

Maybe, though I do refer to d.ts file without extension in the import statement.

Why not import the .d.ts into the typings.d.ts file instead of into the component?

Because it's generated and exports interfaces and namespaces, not declares them globally.

This isn't a CLI issue, but rather a TypeScript/Angular issue.

They said it's cli issue. Is Angular and CLI 2 separate products? If not, do cooperate. This issue does not happen if using webpack starter, so I don't believe it's issue on Angular or TypeScript side itself. Please reopen this issue and investigate it if you want people to believe that Angular is a serious platform.

I can confirm this issue, @Draccoz @filipesilva .
It does not happen when you change the filename from .d.ts to .ts.
It also does not happen when you change your import from import { Something } from 'yourlib'; to import { Something } from 'yourlib.d';
I just moved a working project from a webpack-starter seed (TypeScript/Angular) to CLI and got this error, so I assume it has something to do with the generated CLI project.

Thanks @basst314. I'm afraid though that @filipesilva doesn't care about it at all.

Hi @filipesilva ,
how are we supposed to handle custom typing files like my-types.d.ts in projects running on angular-cli when we want to use them in our component inputs as @Input() element: MyType ?
As written above, regular typescript imports like import { MyType } from 'my-types' don't really work when running on a cli-project.
Do we have to register our typing-files somewhere in the cli-config to be found during the build?
Or is there a documentation or guide you can refer us to?
Any help is very much appreciated!
Thanks!

This might actually be https://github.com/angular/angular-cli/issues/2034.

Hey @Draccoz, can you confirm that this does only happen when doing a normal jit build with ng build, but does work like a charm when building aot with ng build -aot? This is what I'm experiencing.
@filipesilva, #2034 might be related, but this one breaks the build, the other displays a warning and does not break the build. Also the concrete error message is different.
Could you please consider reopening this issue and take a look at @Draccoz github repo to reproduce the error?
Thanks!

Confirming the above. ng build -aot works correctly, while ng build produces:

ERROR in ./src/app/app.component.ts
Module not found: Error: Can't resolve './types' in '/home/dracco/projects/ng2-type-import-issue/src/app'
@ ./src/app/app.component.ts 11:0-31
@ ./src/app/app.module.ts
@ ./src/main.ts
@ multi ./src/main.ts

Can confirm this is still an issue in Angular CLI 1.0.2

@angular/cli: 1.0.2
node: 7.10.0
os: win32 x64
@angular/animations: 4.1.1
@angular/common: 4.1.1
@angular/compiler: 4.1.1
@angular/core: 4.1.1
@angular/forms: 4.1.1
@angular/http: 4.1.1
@angular/material: 2.0.0-beta.3
@angular/platform-browser: 4.1.1
@angular/platform-browser-dynamic: 4.1.1
@angular/router: 4.1.1
@angular/cli: 1.0.2
@angular/compiler-cli: 4.1.1

@basst314 you're right, #2034 is a warning and this is an error. Reopening.

any news on this? it's pretty annoying!

+1

+1 Any updates on this?
Maybe some workarounds?

Does anyone have a workaround for this (aside from using the any type on the input)?

name the files differently. e.g.
.def.ts
On 21 Jul 2017 00:44, "Marshall Cottrell"<EMAIL_ADDRESS>wrote:
Does anyone have a workaround for this (aside from using the any type on
the input)?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular-cli/issues/4874#issuecomment-316851117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACwLMvfmURHRHyCsREdtbWeRjQF4lkzKks5sP9hPgaJpZM4MHWjJ
.

@18steps I'm affraid this is not possible in my case.
TypeScript treats *.d.ts files in a special way that it doesn't compile them into the bundle.
In my project (non-angular), I use *.d.ts file which is placed outside the root of my project. The reason for that is because the file is shared with another project (angular + angular/cli). When compiling, TypeScript refers to that file with '../file_path.d.ts' but keeps the reference to the root path properly. Once I change the file name to *.def.ts it is no longer special for TS and the compiler moves the root path one level up. This ruins the whole tree of compiled files.
Here's an example how it looks when I use *.d.ts file:
└ my-project/  <-- I run tsc from this location
  └ tsconfig.json
  └ src/
    └ app.ts  <-- (imports something from ../../d/definitions.d.ts)
  └ dist/  <-- this is generated by tsc
    └ app.js
└ d/
  └ definitions.d.ts

And here's how it looks when I change the *.d.ts to *.def.ts (or anything else):
└ my-project/  <-- tsc is run from this place
  └ tsconfig.json
  └ src/
    └ app.ts  <-- (imports something from ../../d/definitions.def.ts)
  └ dist/  <-- this is generated by tsc
    └ my-project  <-- this is wrong
      └ src
        └ app.js
      └ d
        └ definitions.def.ts
└ d/
  └ definitions.def.ts

If you take a look at the /dist folder in the second example you'll notice that the compiler "moved" the root of the application 2 levels up.
I was searching for a solution for this behavior in the TS documentation but didn't find anything useful. Maybe someone knows some trick in the tsconfig.json that would solve my problem but this is something different from the bug described in this thread.

@filipesilva and @hansl can you estimate when there will be time to fix this issue? I see it has been labeled 'priotity urgent' but so far nothing has happened.

Just ran into this issue today, is there a fix planned in the near future?

Not using angular-cli, and having the exact same issue, I actually don't think it's angular-cli related.

Same here. Not using cli and get the same error. You can see that index.d.ts is never looked for if you follow the whole thing through.
ERROR in ./src/app/menu/menu.component.ts
Module not found: Error: Can't resolve './shared' in 'D:\Development\client\src\app\menu'
resolve './shared' in 'D:\Development\client\src\app\menu'
  using description file: D:\Development\client\package.json (relative path: ./src/app/menu)
    Field 'browser' doesn't contain a valid alias configuration
  after using description file: D:\Development\client\package.json (relative path: ./src/app/menu)
    using description file: D:\Development\client\package.json (relative path: ./src/app/menu/shared)
      no extension
        Field 'browser' doesn't contain a valid alias configuration
        D:\Development\client\src\app\menu\shared is not a file
      .ts
        Field 'browser' doesn't contain a valid alias configuration
        D:\Development\client\src\app\menu\shared.ts doesn't exist
      .js
        Field 'browser' doesn't contain a valid alias configuration
        D:\Development\client\src\app\menu\shared.js doesn't exist
      as directory
        existing directory
          using path: D:\Development\client\src\app\menu\shared\index
            using description file: D:\Development\client\package.json (relative path: ./src/app/menu/shared/index)
              no extension
                Field 'browser' doesn't contain a valid alias configuration
                D:\Development\client\src\app\menu\shared\index doesn't exist
              .ts
                Field 'browser' doesn't contain a valid alias configuration
                D:\Development\client\src\app\menu\shared\index.ts doesn't exist
              .js
                Field 'browser' doesn't contain a valid alias configuration
                D:\Development\client\src\app\menu\shared\index.js doesn't exist
[D:\Development\client\src\app\menu\shared]
[D:\Development\client\src\app\menu\shared.ts]
[D:\Development\client\src\app\menu\shared.js]
[D:\Development\client\src\app\menu\shared\index]
[D:\Development\client\src\app\menu\shared\index.ts]
[D:\Development\client\src\app\menu\shared\index.js]

I can confirm

Another workaround similar to marshall007's is to declare it like this:
export class FooComponent {
  @Input() public foo: IFoo; // does not work
  @Input() public foo: IFoo | any; // works
}

I can also confirm what @PhotoPaul said.
This is a serious issue, I hope it can be solved as soon as possible.

@hansl let's get some kind of resolution please?

In my project I'm getting the same error message as Asken. It only happens when using AOT. And I also narrowed it down to using a type imported from a package (with .d.ts) inside a decorator (e.g. @NgModule). If I use the imported type outside of a decorator, the build succeeds. In fact, I'm probably going to use InjectionTokens as a workaround, because then I won't have to use the imported types inside decorators; and using them for injection in component constructor seems to be fine. Also if I just define the interface in the same file (not .d.ts), then it works fine inside a decorator.
The error message itself seems to originate from inside enhanced-resolver. The file it can't resolve is inside the package only as a .d.ts file.
ERROR in ./src/app/app.module.ngfactory.js
Module not found: Error: Can't resolve 'my-interface-package/lib/IMyService' in '<project folder>\src\app'

My setup:
import { IMyService } from 'my-interface-package';
import { MyActualService } from 'my-implementation-package';

// IMyService is actually not an interface, but an abstract class, so it can be used for DI.

@NgModule({
    providers: [
        { provide: IMyService, useClass: MyActualService }
    ]
})
export class AppModule {}

Planned workaround for now:
export const MY_SERVICE_TOKEN = new InjectionToken('IMyService');

@NgModule({
    providers: [
        { provide: MY_SERVICE_TOKEN, useClass: MyActualService }
    ]
})
export class AppModule {}

@Component({
    template: '...',
})
export class SomeComponent {
    constructor(@Inject(MY_SERVICE_TOKEN) private myService: IMyService) {}
}

I'm still have this issue as well. In AOT only

Reverting did not help. I'm still going to keep poking around.
FWIW, I'm building libraries (separate projects created by ng generate library) that compile to dist in my root directory. I for some reason feel like they WERE exporting index.ts files and are now only building to index.d.ts files, but I could definitely be wrong about that. All I know is, index.d.ts files, as far as I know, are not compiled into the project bundles. Am I correct in thinking that?

I'm not sure if I'm even experiencing the same issue. However, I pointed my tsconfig aliases for my library projects from their dist/projectname directories (the built projects) to the source projects (libs/projectname/src) and it compiled fine.
I'm concerned that that will de-optimize my build, though... is that something I should worry about, or is this okay to do?

@dudewad Can you please provide a reproduction repository we can use to investigate this? It seems there are some metadata emitted from Angular's decorators, and we should be stripping those before we compile in AOT.

@dudewad This seems like a different issue. If you could provide a reproduction and create a new issue (here), that'd be great. Thanks!
I'm closing this issue as fixed.

This bug is still happening with version 7.1.4 and it's quite annoying.
Also (hoping that this can help with the bug resolution), I noticed that if you create two files like:

myfile.t
myfile.d.ts

and try to include in myfile.ts something exported by myfile.d.ts, the compiler will say that there is a circular dependency -> so it doesn't distinguish between those two files.

I had the same problem: Files with the ending .d.ts could not be resolved.
In my case the problem caused by the option annotateForClosureCompiler of the  angularCompilerOptions: https://angular.io/guide/aot-compiler#annotateforclosurecompiler
Setting annotateForClosureCompiler to false (or removing it, since false is the default value) in tsconfig.json fixed the problem:
"angularCompilerOptions": {
    "annotateForClosureCompiler": false
}


A Little Push?

Hi:
I have a nicely working IPv4 Mikrotik setup with three WANs (Starlink, local WISP and Verizon) using loading balancing/failover, three VLANs (Personal, Guest, IoT), etc. I had hoped to pursue an IPv6 setup with the Starlink connection, but I just can't get it to work with the code here. I am able to ping 2606:4700:4700::1111 from my interface=WAN1 (Starlink), but I cannot ping from the bridge or the VLANs. There is very little documentation out there, so I'd greatly appreciate any insights you have into routes I might need, etc.
Love NM - I go hiking every year outside of Santa Fe and Taos!
Take care,
Paul

Breakthrough tonight. I think I've got it working. Thanks.

@pfturner great news, anything we can incorporate here?
I need to update the config in this repo. When my POP changed recently, I had to adjust part of the firewall rules.

Let me work with it for a few days. Because of the VLANs I made some global address/route changes which may or may not be needed - figuring out if it’s stable. Also, had NextDNS working great in ipv4, believe I have some dynamic dns conflicts in ipv6…
I’m not a tech/network guy, just like to tinker!
I noticed some icmpv6 message that prevented me from getting 20/20. But a couple of times I did - strange.
Paul Turner
Mobile: +1<PHONE_NUMBER>
Email: @.***

From: tyd @.>
Sent: Thursday, March 21, 2024 9:21:44 PM
To: tyd/mikrotik-starlink-ipv6 @.>
Cc: pfturner @.>; Mention @.>
Subject: Re: [tyd/mikrotik-starlink-ipv6] A Little Push? (Issue #2)
@pfturnerhttps://github.com/pfturner great news, anything we can incorporate here?
I need to update the config in this repo. When my POP changed recently, I had to adjust part of the firewall rules.
—
Reply to this email directly, view it on GitHubhttps://github.com/tyd/mikrotik-starlink-ipv6/issues/2#issuecomment-2014144075, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BHGLMZ2A6XQCLBICZLBGCHLYZOBSRAVCNFSM6AAAAABFCD2DDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJUGE2DIMBXGU.
You are receiving this because you were mentioned.Message ID: @.***>

I have had to create a global address for each VLAN, but it seems to be working okay. I think I'll leave it turned off for now - or perhaps just leave link-local on to work on a few things.
From: Paul Turner @.>
Sent: Thursday, March 21, 2024 9:27 PM
To: tyd/mikrotik-starlink-ipv6 @.>; tyd/mikrotik-starlink-ipv6 @.>
Cc: Mention @.>
Subject: Re: [tyd/mikrotik-starlink-ipv6] A Little Push? (Issue #2)
Let me work with it for a few days. Because of the VLANs I made some global address/route changes which may or may not be needed - figuring out if it's stable. Also, had NextDNS working great in ipv4, believe I have some dynamic dns conflicts in ipv6...
I'm not a tech/network guy, just like to tinker!
I noticed some icmpv6 message that prevented me from getting 20/20. But a couple of times I did - strange.
Paul Turner
Mobile: +1<PHONE_NUMBER>
Email<EMAIL_ADDRESS>
From: tyd<EMAIL_ADDRESS>Sent: Thursday, March 21, 2024 9:21:44 PM
To: tyd/mikrotik-starlink-ipv6<EMAIL_ADDRESS>Cc: pfturner<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [tyd/mikrotik-starlink-ipv6] A Little Push? (Issue #2)
@pfturnerhttps://github.com/pfturner great news, anything we can incorporate here?
I need to update the config in this repo. When my POP changed recently, I had to adjust part of the firewall rules.

Reply to this email directly, view it on GitHubhttps://github.com/tyd/mikrotik-starlink-ipv6/issues/2#issuecomment-2014144075, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BHGLMZ2A6XQCLBICZLBGCHLYZOBSRAVCNFSM6AAAAABFCD2DDKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJUGE2DIMBXGU.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>


[WIP] Update to the chef_client_scheduled_task resource frequency_modify default functionality

Signed-off-by: Davin Taddeo<EMAIL_ADDRESS>
Updates resource so that the frequency_modifier only defaults to 30 if the frequency is "minutes" and will otherwise default to 1
Description

This update adds some logic into the pull request so that the frequency_modifier will be set to 1 if the frequency is set to hours, days, weeks, or months.  So that you don't end up scheduling a task to run once every 30 months by accident.
This could probably be more elegantly done, so if someone has improvements to make, I'd be very happy to get the input.
Related Issue

#9918
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

[x] I have read the CONTRIBUTING document.
[ ] I have run the pre-merge tests locally and they pass.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.
[X] All commits have been signed-off for the Developer Certificate of Origin.

Okay, so I fixed all the failing Windows unit tests for this resource, and I also put in unit tests that would validate that the frequency_modifier defaults to 1 unless the frequency is "minute", in which case it defaults to 30. So I feel like this is pretty solid.  Going to take this off of [WIP] and hopefully it can get pulled into the next update.


Add another work-around for General registry

cc @frapac

Codecov Report

Merging #271 into master will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #271      +/-   ##
==========================================
- Coverage   69.24%   69.23%   -0.02%
==========================================
  Files          15       15
  Lines        2432     2431       -1
==========================================
- Hits         1684     1683       -1
  Misses        748      748

Impacted Files
Coverage Δ

src/MOI/MOI_wrapper.jl
86.67% <0%> (-0.02%)
:arrow_down:

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 2ca4ee4...85fba6d. Read the comment docs.


check extension csharp

Fixed by https://github.com/aneoconsulting/ArmoniK.Extensions.Csharp/pull/63


feat(breadcrumb): add breadcrumb component

Notice
I added the devdepencency vue-router to support the to props and route.
The Composition API does not has this, so it does not has this.$router. It use provide/inject to get router and route to path.
https://github.com/vuejs/rfcs/blob/master/active-rfcs/0013-composition-api.md#plugin-development

Many Vue plugins today inject properties onto this. For example, Vue Router injects this.$route and this.$router, and Vuex injects this.$store. This has made type inference tricky since each plugin requires the user to augment the Vue typing for injected properties.
When using the Composition API, there is no this. Instead, plugins will leverage provide and inject internally and expose a composition function. The following is hypothetical code for a plugin:

Problem
When I test the code, it show a warning, maybe caused by not import the vue-router when test? I'm not sure.
 console.warn node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:39
      [Vue warn]: injection "Symbol([vue-router]: router)" not found.
        at <ElBreadcrumbItem>
        at <ElBreadcrumb separator-class="el-icon-check" >
        at <Anonymous ref="VTU_COMPONENT" >
        at <VTUROOT>

Thank you for your PR, I will review it in this week.


Interpolations without provided value should remain in the translation result

Clear and concise description of the problem
We're upgrading to v9.x. When translating a string, we want to perform some extra logic on the result, using special tags {tag} to be replaced in the translated result. In V8, the translated value still contained those values, but in V9 it doesn't anymore.
Input: { val: "I am a special {tag} string" }, calling t("val").
V8 result: I am a special {tag} string
V9 result: I am a special string
Suggested solution
Let's add an option to createI18n to toggle between those behaviors globally if it's not there.
Alternative
No response
Additional context
No response
Validations

[X] Read the Contributing Guidelines
[X] Read the Documentation
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Currently missing exactly this behaviour:
e.g.
en:
  form.validations.xxx: '{label} should be at least {min} characters'

(In combination with Zod for validation)
message: i18n.t("form.validations.xxx", {
  min: issue.minimum
})

Outcome is should be at least 1 characters, expect to find {label} should be at least 1 characters to then use later on in a template like so:
{{ t(errorMessage, {label, name, inputValue}, {resolvedMessage: true}) }

Currently missing exactly this behaviour.
E.g.: with the following translation key:
en:
  form.validations.xxx: '{label} should be at least {min} characters'

In combination with Zod for validation:
message: i18n.t("form.validations.xxx", {
  min: issue.minimum
})

The actual outcome is: should be at least 1 characters, Whereas I expect to find {label} should be at least 1 characters, for re-use later on like so:
{{ t(errorMessage, {label, name, inputValue}, {resolvedMessage: true}) }

My current work around is to manually map the missing keys back to their respective placeholders:
message: i18n.t("form.validations.xxx", {
  min: issue.minimum,
  label: '{label}',
  name: '{name}',
  inputValue: '{inputValue}'
})

Interesting solution. But how do you perform tricks like this when the value of the message is unknown (dynamic key)?

@youthug based on your question I felt like going for a bit of a puzzle, here's where I came up with:
utils/translateKeepMissing.ts
import {
  createParser,
  type MessageNode,
  type NamedNode,
  Node,
  type PluralNode,
  type ResourceNode,
} from "@intlify/message-compiler";

// See NodeTypes in "@intlify/message-compiler"
// Can't be imported due to '--isolatedModules' flag
const NodeTypes = {
  Resource: 0,
  Plural: 1,
  Message: 2,
  Text: 3,
  Named: 4,
  List: 5,
  Linked: 6,
  LinkedKey: 7,
  LinkedModifier: 8,
  Literal: 9,
} as const;

const isMessageNode = (n: Node): n is MessageNode => {
  return n.type === NodeTypes.Message;
};
const isPluralNode = (n: Node): n is PluralNode => {
  return n.type === NodeTypes.Plural;
};
const isNamedNode = (n: Node): n is NamedNode => {
  return n.type === NodeTypes.Named;
};

const getNamed = (node: ResourceNode) => {
  const placeholders: string[] = [];
  const traverse = (n: MessageNode | PluralNode) => {
    if (isMessageNode(n)) {
      for (const item of n.items) {
        if (isNamedNode(item)) {
          placeholders.push(item.key);
        }
      }
    }
    if (isPluralNode(n)) {
      for (const kase of n.cases) {
        traverse(kase);
      }
    }
  };
  traverse(node.body);
  return placeholders;
};

const p = createParser();

export default (key: string, named?: Record<string, unknown>) => {
  const {tm, rt} = useI18n();
  const rawLabel = tm(key) as string;
  const body = p.parse(rawLabel);

  const names = getNamed(body);
  const providedNamedValues = named ? Object.keys(named) : [];
  const unusedNames = names
    .filter((name) => !providedNamedValues.includes(name))
    .reduce(
      (acc, name) => {
        acc[name] = `{${name}}`;
        return acc;
      },
      {} as Record<string, unknown>,
    );

  return rt(rawLabel, {
    ...named,
    ...unusedNames,
  });
};

**Then use it where ever you need it **
import translateKeepMissing from "~/utils/i18n/translateKeepMissing";

// Translate the message and provided it with a value for min - that's used if it exists in the label.
const initialTranslation =  translateKeepMissing("form.validations.xxx", {
    min: 3,
}); // results in '{label} should be at least 3 characters'

Then later at any other point you can re-interpolate the string like so
const {t} = useI18n();

const finalTranslation = t(initialTranslation, {
 label: "Subject",
},
{
 resolvedMessage: true,
}); // results in 'Subject should be at least 3 characters'

@JvanderHeide Thanks for the reply and your great work! I haven't tested the code yet, but it seems a bit tedious. I think it would be better if this was provided as a feature by vue-i18n.

Can't fault you on that thought, I agree. Perhaps i have the time to dive in to that sometime in the future.


Pull requests often suffer a merge conflict in the changelog

https://github.com/mitogen-hq/mitogen/blob/master/docs/changelog.rst is a hot spot for lines changed/added in a pull request. This causes merge conflicts when two pull requests both add a changelog entry. Consequences are

higher maintainer burden
worse contributor experience
delay in merging PRs, causing them to pile up

A few possible mitigations and/or fixes, not all mutually exclusive

Placeholders, e.g. seed the file with a lot of empty bullet points.
Different merge strategy (e,g, merge=union)
New folder/file structure One file per changelog entry, render/combine changelog during release
Look at dedicated tools/workflows
e.g. https://github.com/conventional-changelog, https://github.com/nettsundere/cyberlog

Reading material

https://about.gitlab.com/blog/2015/02/10/gitlab-reduced-merge-conflicts-by-90-percent-with-changelog-placeholders/
https://medium.com/@nettsundere/on-reducing-changelog-merge-conflicts-1eb23552630b

A few possible mitigations and/or fixes, not all mutually exclusive

Placeholders, e.g. seed the file with a lot of empty bullet points.
Different merge strategy (e,g, merge=union)
New folder/file structure One file per changelog entry, render/combine changelog during release
Look at dedicated tools/workflows
e.g. https://github.com/conventional-changelog, https://github.com/nettsundere/cyberlog

Reading material

https://about.gitlab.com/blog/2015/02/10/gitlab-reduced-merge-conflicts-by-90-percent-with-changelog-placeholders/
https://medium.com/@nettsundere/on-reducing-changelog-merge-conflicts-1eb23552630b

Different merge strategy (e,g, merge=union)

Github UI does not respond to merge=union, e.g. https://github.com/moreati/changelog-merge-test/pull/2 shows as a conflict

Hi @moreati, I'm Henry and I'm currently working on Merge Mamba. If your project is having trouble with merge conflicts you might find it helps to avoid them in future and it'll always be free for open source projects.
I'll be adding new features over the next few months so if there are any adjacent problems that your project would love a tool to help with, just let me know and I'll try and fit them into the roadmap.

Looking at https://towncrier.readthedocs.io/ and https://scriv.readthedocs.io/
Open questions

Do non-maintainers need the tool installed to submit a PR? Can they be vendored to avoid that?
can they be integrated with CI? Should they be?
Would pre-commit help?

Single file script used by CPython https://github.com/python/core-workflow/blob/main/blurb/blurb.py, could be more suited to vendoring

Currently leaning toward blurb.


Method Arrangement in Swagger UI

Hi Abel
Is there any way to arrange methods in swagger ui using attribute ?
Thanks

Hi,
what do you mean exactly with "arrange methods"?
Swagger UI sorts your methods by it's path. When you use the Attribute [SwaggerWcfTag("YourGroupName")], you can specify method groups. Then you methods are arranged in groups. Will that solve your problem?

Hello,
Basically that [SwaggerWcfTag("YourGroupName")] is what I'm using right now, but my question, is there any way/options to sort by key/ or example i put and number sequence.
thanks

Hi, I don't think that there's a possibility to do so in the swagger 2.0 spec. I think, the only way, to add a feature like that, is to manipulate the swagger-ui and inject it:
var fileStream = new FileStream(@"C:\Work\Playground\swagger-ui\swagger-ui.zip", FileMode.Open); SwaggerWcfEndpoint.SetCustomZip(fileStream);

Ohhh Okay. Thanks! Hope to add that option in future version of swagger I think that will be very useful.

Yeah! You can pronounce your feature request here.
Has this solved the SwaggerWcf-Issue for you?

it there's still any issue please comment, I'll reopen


Soundness of AtomicCell::compare_exchange is dubious

AtomicCell<T>::compare_exchange will, if I understand the code correctly, use AtomucU*::compare_exchange_weak if T has the right size.  But this means that e.g. for (u8, u16), which has size 4, it will transmute these pairs into u32 and compare them as integers.  However, such pairs contain a padding byte, meaning that the u32 contains some uninitialized memory.  Having uninitialized memory in a  u32 is uncharted territory at best, but performing actual operations on such a datum (as opposed to just load/store) brings us very close to UB.  I am not sure what the rules are in LLVM for this case, but under the proposed poison semantics I think the comparison will return poison and hence using it in an if is UB.  For Rust, I think the intention is to make any operation on uninitialized data UB (like it is in C), meaning the comparison would already return UB.
Strictly speaking, this affects not just the fast path, but also the arbitrarily-sized case: bytes_eq might compare uninitialized bytes.

@Amanieu @stjepang with the newly proposed ptr::freeze and if you remove AtomicCell::get_mut, I think this can be made sound. You basically just have to make sure that you only ever write frozen stuff into the cell, and freeze things before you compare them. In contrast to the "zero padding"-based schemes @Amanieu suggested at the all-hands, this does not require a special function that knows where the padding bytes are.

That doesn't exactly solve the problem though: compare_exchange returns a T with the current value in the atomic if the compare fails. In the most common use case (CAS loop) this will be passed back in as the current argument to compare_exchange in the next loop iteration.
However since the padding bytes in T are always undef, the freeze operation could freeze them into a different value than the one in the atomic, which would cause the next compare_exchange call to fail even though the value in the atomic was not changed since the last iteration. This could result in the CAS loop never converging to a stable state.

@RalfJung Awesome news!
@Amanieu Are you sure? We have this if statement that should solve the issue you're describing. Note that compare_exchange will never fail spuriously due to the difference in undef bytes.

@stjepang Ah right. So you won't get spurious failures, but you could in theory get stuck in an infinite loop.

@Amanieu Hmm, not sure I understand how. If we do cell.compare_exchange(old, new) and we know cell.get() == old, the operation will always succeed, even if the two values differ in padding bytes.
Could you perhaps sketch out a simple example? I don't see the theoretical infinite loop here.

Let us assume some 2-byte type (u8, __pad: u8). The first byte contains a valid value, the second byte is padding. The underlying atomic type used is AtomicU16.

The current value in the AtomicU16 is (7, 0).
The user calls cell.compare_exchange(old = (7, undef), new = (8, undef)).
The undefs get frozen as u16s with values: old = (7, 60), new = (8, 90).
The inner atomic_compare_exchange_weak fails because the padding bytes don't match.
The inner atomic_compare_exchange_weak returns Err((7, undef)) because it returns a T instead of a u16, the value is "unfrozen"
compare_exchange loops back to step 2 with old = (7, undef).

Now that I look at it this way, I think this is fixable if you keep the previous value as a u16 when passing it back up the loop instead of converting it back to a T.

Thanks! I agree about keeping the previous value as a u16 rather than going u16 -> T -> u16. That should solve the problem.

Ah good point, yes you need to do the entire loop without round-tripping through T.
It is a bit dissatisfying that we cannot also have get_mut, though... all we need to have that, too, is an "atomic freeze operation" -- a way to freeze memory as the first thing compare_exchange does, in a way that does not count as a data race in the memory model. That seems like a pretty powerful operation though, and I have no idea how to integrate it with the rest of the memory model.
Pragmatically speaking, an asm! block probably has this effect as far as LLVM is concerned. But that's not really good enough for me.^^

Any thoughts on replacing get_mut with store_mut/load_mut which, IIUC, could still be implemented soundly?

These could freeze, so yes, they could be implemented in a sound way in this model.

I believe (1) Rust should not blame padding bytes as invalidate values as well, and (2) we should de-deprecate AtomicCell::get_mut().  This idea is not just popping from my head, but is actually inherited from the precedence of C/C++.
Paddings are not invalidate but unspecified in C/C++.  That means (1) you don't know what's the value of the paddings, but (2) computations on the paddings should not invoke undefined behavior.  It is for a good reason.  For example, padding bytes that do not introduce undefined behavior is essential in our implementation of AtomicCell::get_mut().

AFAIK padding bytes are indeterminate in C/C++. That's the same status as uninitialized memory, and it is very different from unspecified. Whether or not computations on indeterminate values are UB is not clear from the standard, but:

In the case of an indeterminate value all bit-patterns are valid representations  and  the  actual  bit-pattern  may  change  without  direct  action  of the program.

Source: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1793.pdf
In particular, comparing indeterminate values with anything is meaningless.
Also, another point not clear from the standard is what happens when you memcpy a 4-byte struct including a padding byte into a uint32_t -- does the entire integer value become indeterminate, or is this somehow tracked on a per-byte basis? From what I recall from the LLVM poison discussion, there are optimizations that are incompatible with either choice.

According to C17 6.2.6p6, "padding bytes take unspecified values":

When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values.51) The value of a structure or union object is never a trap representation, even though the value of a member of the structure or union object may be a trap representation.

Interesting. However, we also have C17 6.7.1 p9:

unnamed members of objects of structure and union type do not participate in initialization. Unnamed members of structure objects have indeterminate value even after initialization.

and <IP_ADDRESS> p15 + p17:

There may be unnamed padding within a structure object, but not at its beginning.

There may be unnamed padding at the end of a structure or union.

Also, to my knowledge, making padding indeterminate is needed to make SROA (scalar replacement of aggregates) a valid optimization.

Also note footnote 51 in your quote is

Thus, for example, structure assignment need not copy any padding bits.

But that doesn't square with just being unspecified: if I have an uninitialized variable and initialize it by assignment, and the assignment does not copy the padding bits, then those bits will remain indeterminate.

For unnamed members/paddings, I think the standard intentionally distinguished members and paddings: paddings are not members, and unnamed members are indeterminate and unnamed paddings are unspecified.  Also, I think the footnote 51 should be interpreted as informative, but not normative.  I think it suggests an implementation strategy.
I think SROA will be much more interesting than language laws.  Would you please give me a reference or example why paddings should be indeterminate for validating SROA?

I think that's just an artifact of wording -- padding is a kind of unnamed member. What other unnamed members would there even be=

Would you please give me a reference or example why paddings should be indeterminate for validating SROA?

Well, one effect of SROA is that only the elements of a struct get copied, not its padding -- exactly what the footnote alludes to.
struct Foo { uint8_t f1, uint16_t f2 };

Foo bar(Foo foo) {
  Foo foo2 = foo; // assume this one gets SROA'd
  return foo2;
}

Foo bar2(Foo foo) {
  Foo foo2;
  foo2.f1 = foo.f1;
  foo2.f2 = foo.f2;
  return foo2;
}

bar is basically transformed to bar2: it will return a Foo where the two fields got copied from the argument, but the padding was left uninitialized -- and hence is indeterminate.

Unnamed fields are anonymous ones: https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html
I still think paddings are not unnamed members mentioned in the standard.

I believe paddings are never indeterminate in C, so your SROA example is sound even though the padding bytes are unspecified values.

Unnamed fields are anonymous ones: gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html

How would it make any sense that those members do not get initialized?

I still think paddings are not unnamed members mentioned in the standard.

Given that padding is explicitly called out as "unnamed", I disagree with that reading.
Notice that this interpretation is not just mine, I took it from https://wiki.sei.cmu.edu/confluence/display/c/EXP42-C.+Do+not+compare+padding+data which explicitly quotes the above parts of the standard when talking about padding.

I believe paddings are never indeterminate in C, so your SROA example is sound even though the padding bytes are unspecified values.

I don't follow. Uninitialized variables are indeterminate. Why would their padding not be...?
The standard is generally extremely vague about all this indeterminate/unspecified/trap representation business. I think it is much clearer to follow the approach proposed for LLVM, where "indeterminate" becomes poison and there's a proper formal definition. Unintiailized memory is poison. The only way to explain my example above is to say that copying a struct resets all padding to poison.

On "unnamed":
I think distinguishing unnamed members and unnamed paddings, is the only way to make sense of C17 6.2.6p6 and [C17 6.7.1 p9 and <IP_ADDRESS> p15 + p17] at the same time.  Even if they conflict with each other, 6.2.6p6 is more clearly describing the semantics of padding with unambiguous words: padding bytes are unspecified.  I prefer to follow it.

On uninitialized struct/union values:
According to C18, struct and union values, even if uninitialized, should not be a trap representation.  (Here, "trap representation" means what we called "indeterminate" in this discussion: C18 3.18.2 says an indeterminate value is "either an unspecified value or a trap representation".)  C18 6.2.6p6 says: "The value of a structure or union object is never a trap representation, even though the value of a member of the structure or union object may be a trap representation."

On "unnamed"

I see where you are coming from. OTOH, I feel if the people doing the CERT C Coding Standard interpret it the way I quoted, that probably means they are not alone.  So at this point it probably stops being useful to stare at the vague C standard.

On uninitialized struct/union values:

Yeah, unfortunately the entire "trap representation" stuff in C/C++ is really poorly specified. For example, integers also don't have "trap representations" (I believe the next standard will even say that), and yet in the mainstream C compilers there are "weird" integers like undef and poison which definitely cannot be treated like "normal" values in the C standard (for example, x == x may return false and x == 0 ? 0 : y/x is UB because x might be non-zero the first time you look at it and 0 the second time).
So it is probably more useful to look at what compilers actually do. The only one I am familiar with and the most relevant for Rust is LLVM. LLVM trunk is inconsistent in what it does, but there is a proposal for a consistent model. In that model, structs and struct fields can definitely be poison. The part about structs not having trap representations likely stems from structs not being stored in registers, and registers with a constrained value range being the source of these "trap representations". But nowadays this is used in a whole different way. So for the purpose of this discussion I think we can safely ignore any part of the C standard that says certain things cannot have "trap representations"; compilers have poison/undef for all sorts of values.
So, in the poison model, I claim that reading padding gives back poison. In current LLVM, with both poison and undef, padding is undef. Even though I have been told this several times, I cannot find a good reference for it. The aforementioned paper says

LLVM uses undef in a few other situations. First, to represent the values of padding in structures, arrays, and bitfields.

Similar things are said in this bugreport. @rkruppe do you know if the LLVM IR specifies this padding stuff properly anywhere?
Since a mere read access to some location in memory cannot even "know" if it is reading padding or whatever, the only way I see to realize "reading padding gives undef/poison" is to say that copying a struct (at struct type) will reset the padding to undef/poison.
Also see this where more people agree with me that inspecting padding is UB in modern compilers (they say that violates the standard, which I am not sore sure about, but given the ambiguity of the standard that does not seem like a useful discussion).

I think the difference is on the viewpoint.  I, as a systems programmer, think that get_mut() is sane, and it should be supported in any systems programming languages.  From the viewpoint, I try to find evidence for allowing reading of uninitialized paddings, such as paragraphs in the standards and implementations in compilers.  On the other hand, you (and obviously I to a certain extent), as programming language researchers, think that there should be a good programming model that explains the real-world practice.  Unfortunately, this conflict doesn't seem to be resolved anytime soon :(  But for the purpose of library building, I prefer to take the viewpoint of systems programmers.
To summarize my viewpoint, (1) get_mut() is sane from a systems programmer's viewpoint, and (2) if get_mut() is currently not supported, it's the programming language's fault, and furthermore, (3) we should revise the undef/poison model (or anything else) so as to explain get_mut(), unless we could find a fundamental reason why it's undesirable to do so.
@stjepang For this reason, I'd like to propose to revert #332 (Deprecating AtomicCell::get_mut).

I, as a systems programmer, think that get_mut() is sane, and it should be supported in any systems programming languages.

I would like to support it! However, the way we ended up in this messy situation with C/C++ is by ignoring the fact that a language must have a single consistent semantics, and relying on mutually incompatible axioms and intuition instead.
In my view, your argument is flawed. From a systems programmer's viewpoint, one could argue that all sorts of things are "sane" -- things like benign data races or OOB loads on a definitely mapped page. The issue is that these arguments mix up intuition formed by looking at "what the hardware does", with "what the programming language is supposed to do". This is not a sensible way to argue, and it leads to miscompiled programs quickly.
What you are doing here is closing your eyes in the face of the problem and hoping that that makes it go away. It won't go away. It's not just "the language's fault"---we can make get_mut sound if we disable a bunch of optimizations. What we don't know is how to have both get_mut and these optimizations. Finding a way to reconcile this conflict is of course our responsibility as language designers, but that does not mean that we can just axiomatize it away. It is not uncommon that having two things that both seem intuitive is not actually possible at the same time (as you are well aware of course). We can either follow the C approach of "YOLO whatever, it won't be too bad" (leading to mysteriously miscompiled programs, long debugging sessions and the entire rest of the mess that is called "C semantics"), or we can acknowledge that when formal semantics are in conflict with systems programming intuition, sometimes there's an actual problem here that we cannot just ignore away.

So, in an attempt to make this conversation more constructive, what kind of feature would we need in the language to make get_mut compatible with compare_exchange? The soundness argument for compare_exchange relies on the invariant that the content of the AtomicCell is frozen at all times. get_mut allows that invariant to be violated, so we cannot rely on memory to be frozen. Hence we must freeze it ourselves. It seems to me what we would need is an atomic version of ptr::freeze, which we can use to freeze the memory when compare_exchange begins. We also have to make sure that racing writes do not write unfrozen data, but we control that code so that is easy.
So, we could have
fn store(&self, mut val: T) {
  ptr::freeze(&mut val);
  // do the atomic store, *at a type that preserves padding*
}

fn compare_exchange(&self, mut val1: T, mut val2: T) {
  ptr::atomic_freeze(self.value.get());
  ptr::freeze(&mut val1);
  ptr::freeze(&mut val2);
  // do the CAS loop, *at a type that preserves padding*
}

@Amanieu does that make sense to you? I am mostly worried about what it means that we now might perform a "write" operation even if the CAS failed.
Alternatively, we could specify that CAS freezes the memory before comparing, but that seems extremely risky given that we have no idea which optimizations LLVM will perform on this.

I think an argument could be made that compare_exchange should effectively do the same thing as a volatile load (i.e. it reads a frozen value from the AtomicCell).
In the end I think we should just do whatever C++ does (where get_mut is effectively the inverse of atomic_ref). The LLVM people will figure out the semantics for padding bytes and we should just copy whatever they do. This means that we should probably support something similar to get_mut.

I think an argument could be made that compare_exchange should effectively do the same thing as a volatile load (i.e. it reads a frozen value from the AtomicCell).

I was told that LLVM is looking into analysis that will replace atomic operations by non-atomic operations when the compiler can prove that there are no race conditions. That however means that we cannot say that atomic operations read frozen values.

@RalfJung I still think my previous comment quite clearly summarizes what the standard says about padding (they are just random bits and safe to access), and I think actually it's quite good semantics for everyone.  As far as I understand, existing optimizations, as well as system programmer's idioms, are supported.  In particular, get_mut() is sound.  And it's the status quo.
So to say get_mut() should be unsound, I expect there should be an optimization that renders wrong in the presence of get_mut(), or paddings being safe.  Just the existence of a language model (e.g. the freeze model) is, at least for me, not as convincing as a counter-example.

I still think my previous comment quite clearly summarizes what the standard says about padding (they are just random bits and safe to access), and I think actually it's quite good semantics for everyone.

Well, it's not how LLVM implements padding, so it's clearly not good for everyone, and certainly not good for Rust which uses LLVM as backend. I have heard your argument, there is no point in repeating it. I just don't agree, this is not how I interpret the C standard. I won't repeat my arguments now as you already know them.
And anyway the C standard is only relevant insofar as we might use it to deduce things about the LLVM semantics. And there I can easily craft examples that show that padding can indeed turn into undef any time:
pub fn test(x: (u32, u64), f: fn(&(u32, u64))) {
    let y = x;
    f(&y);
}

gets compiled to
define void @_ZN10playground4test17hc74ff9e76a3b675aE(i32 %x.0, i64 %x.1, void ({ i32, i64 }*)* nocapture nonnull %f) unnamed_addr #0 {
start:
  %y = alloca { i32, i64 }, align 8
  %0 = bitcast { i32, i64 }* %y to i8*
  call void @llvm.lifetime.start.p0i8(i64 16, i8* nonnull %0)
  %1 = getelementptr inbounds { i32, i64 }, { i32, i64 }* %y, i64 0, i32 0
  store i32 %x.0, i32* %1, align 8
  %2 = getelementptr inbounds { i32, i64 }, { i32, i64 }* %y, i64 0, i32 1
  store i64 %x.1, i64* %2, align 8
  call void %f({ i32, i64 }* noalias nonnull readonly align 8 dereferenceable(16) %y)
  call void @llvm.lifetime.end.p0i8(i64 16, i8* nonnull %0)
  ret void
}

As you can see, this creates a local allocation %y, then copies the two fields into y, and then passes %y to f. In particular, the padding in y does not get initialized, and hence is undef.
This can only be explained in Rust by saying that the let y = x copies the fields of x but resets the padding to undef.
I think this conclusively proves that in the LLVM model, get_mut will let undef creep into Atomic<(u32, u64)>. And since a conditional jump on the result of comparing undef is UB, this means that get_mut is UB unless we have some way to "atomically freeze" memory before compare_exchange.

So to say get_mut() should be unsound, I expect there should be an optimization that renders wrong in the presence of get_mut(), or paddings being safe. Just the existence of a language model (e.g. the freeze model) is, at least for me, not as convincing as a counter-example.

 I am afraid that is not a definition I can accept. You can't make a function "sound" by messing with it until the current compiler compiles it the way you want. I am honestly shocked to see you even propose this.
I think there is a wide consensus in the Rust community that "soundness" has nothing to do with compiler optimizations. It is about whether your program has UB according to the spec. The spec doesn't exist yet but we can try to infer what pieces of it have to be, like I did in the beginning of this post. You don't get to redefine this term.
Or maybe you gave up on soundness, and only care about this function doing the right thing de facto. That's a fair position, albeit not one I share. What is an interesting question is constructing a sequence of reasonable-looking optimizations that break Atomic<T> in an observable way. However, I am afraid that game is not very fun to play. I think I did the key step above by demonstrating how to put an Undef into an initialized (u32, u64) in safe code.

Here's another example demonstrating that the padding of any struct has to be considered undef, no matter how "thoroughly" it got initialized or frozen:
#![crate_type="cdylib"]

#[repr(C)]
pub struct X {
    a: u32,
    b: u64
}

pub fn foo(x: X) -> u32 {
  unsafe {
    return std::ptr::read((&x as *const X as *const u32).add(1));
  }
}

becomes
define i32 @_ZN10playground3foo17hdddbf0857401c2c8E(i32, i64) unnamed_addr #0 {
start:
  ret i32 undef
}

(Thanks to @nagisa.)

People reading this might also be interested in the atomig crate. Also see this discussion. Basically that is an entirely safe crate providing an Atomic<T> type, but only where T: Atom. There's no lock-based fallback; the trait just is not implemented for types that are too big. Because the crate is entirely safe it cannot have get_mut, but it does provide all the other operations.

If Rust decides to guarantee that padding will always be 0 (in repr(Rust)), then this whole problem goes away for such structs.
See https://github.com/rust-lang/rust/issues/70230

That issue is about adding the ability for types to opt-in to guaranteed-0 padding.
There is no proposal on the table that would make all padding always 0, and I doubt people would like that idea.

The first line of that issue description is "one option to gain more layout optimizations would be (either for all repr(Rust) types or with per-type opt-in) to use a different kind of padding."
But I agree that it might be hard to do it for all repr(Rust) because of backward compatibility concerns. Thinking of unsafe code initializing a struct field-by-field using pointers.


fix: implement proper yaml Unmarshal

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

Project coverage is 44.38%. Comparing base (b4db945) to head (45967f6).
Report is 15 commits behind head on main.

Files
Patch %
Lines

processor/libArchetypeOverride.go
6.25%
15 Missing :warning:

alzlib.go
0.00%
10 Missing :warning:

processor/libArchetype.go
81.81%
1 Missing and 1 partial :warning:

processor/libArchitecture.go
85.71%
1 Missing and 1 partial :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #133      +/-   ##
==========================================
+ Coverage   43.20%   44.38%   +1.17%
==========================================
  Files          16       28      +12
  Lines        1178     1433     +255
==========================================
+ Hits          509      636     +127
- Misses        570      674     +104
- Partials       99      123      +24

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


SOLR-17576: Remove deprecated master/slave support in ReplicationHandler

https://issues.apache.org/jira/browse/SOLR-17576
Description
Remove deprecated terms.
Solution
Deletes
Tests
Existing tests
Checklist
Please review the following and check all that apply:

[ ] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[ ] I have created a Jira issue and added the issue ID to my pull request title.
[ ] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
[ ] I have developed this patch against the main branch.
[ ] I have run ./gradlew check.
[ ] I have added tests for my changes.
[ ] I have added documentation for the Reference Guide

I'm confused. There seems to be a lot more in this than just touching up terminology to match the Leader/Follower?

@gus-asf unfortuantly, I have to agree with you....   I'm going to redo this PR to seperate out the code cleanups from the deprecations.   I just read @dsmiley link about "how to maintain forks" and it really pushed the atomicity of PR's.    It kills me to be going through code and seeing obvious errors and problems and NOT fix them.   The next time, I might try having two copies of Solr in seperate directories, and try to keep "annonying code issue fixes" on one, and the thrust of whatever I am doing on the other....

I've removed the extra refactorings and created a new issue https://issues.apache.org/jira/browse/SOLR-17579 to track that (and remind me!)


Add conda build github-action

Currently the Release github-action only builds wheel.

Will be done in beta-version

Fixed by applying copier template.


[DSSv3] Fix Issue 13684 - std.numeric.isRectangular

Added new function isRectangular

The commit message should contain the string "Fix Issue 13684 - ..." so that the bot picks it up. Upon merger, the bot  will then automatically close the issue.

I don't think Phobos needs such a function; it may encourage people to think jagged arrays (arrays of arrays) are a reasonable way for such rectangular multidimensional arrays, while we have a much better suited library for that: http://mir-algorithm.libmir.org/mir_ndslice.html
Using join() for the recursion and thus requiring potentially huge temporary buffers for such a check is bad.

@lucica28 As per @kinke 's comment I am going to close this PR. Feel free to close the issue as WONTFIX.


"Unable to load device"

Hello, I have UTV007 easycap device,
I compiled and tested your project on 3 smartphones - LG g2 , sony xperia z5 premium, and LG g3,
the device recognized by the app but show toast message : "Unable to load device" and then "Error connecting to device"
Tried it with EasyCap Viewer from play store and it worked good.
Any idea how to solve it?

I assume each of those devices has Kitkat or later?
Easycap viewer has its own user space driver, my app uses V4l2 linux kernel space drivers.  Its likely SELinux that is causing issues.  I had hoped requesting usb permission have an effect on SELinux policy to allow access, but I hadn't been able to test it on a SELinux enforcing device.   It isn't surprising that it had no effect.
The solution is to change SELinux to permissive mode, for that you will need root.  There is an app called "SELinuxModeChanger" that will do this for you.
I could add this functionality to Easycam itself, however I would prefer to add userspace drivers rather than require root access and do something that google deems "dangerous".  Creating a userspace driver is a large undertaking and at this point I simply do not have the time to do it.

It also occurs to me that its also possible that your kernel doesn't have the UTV007 module loaded.  To my knowledge they are never compiled by default.  You would need a custom kernel that supports easycap devices.

yes, my devices run kitkat and lolipop,
I followed your suggest and I root my device and installed "SELinuxModeChanger" which changed SELinux to permissive mode and I still facing the same problem .
can you provide information on how to load the UTV007 module and where can i get it?
or any other option to solve this issue?

I also have "Unable to load device" and then "Error connecting to device".
One Plus One device running Cyanogenmod Lollipop.
Tried with SELinuxModeChanger and no difference.
I took a look at /dev folder and there I see I have a /video folder and then more files like /dev/video0, /dev//video1, /dev/video2, etc...
Is /dev/video supposed to be a folder or a file?

<6>[ 1034.843926] msm-dwc3 msm_dwc3: DWC3 exited from low power mode
<6>[ 1034.846029] qpnp_chg_ext_charger_reset: qpnp_chg_ext_charger_reset reset:1
<6>[ 1034.848490] qpnp_chg_ext_charger_reset: qpnp_chg_ext_charger_reset reset:0
<6>[ 1034.853862] qpnp_chg_ext_charger_wdt_set: qpnp_chg_ext_charger_wdt_set seconds:0
<6>[ 1034.857996] bq24196_charge_en enable:0
<6>[ 1034.861099] bq24196_vddmax_set voltage:4350
<6>[ 1034.881320] bq24196_charge_en enable:2
<6>[ 1034.888248] xhci-hcd xhci-hcd: xHCI Host Controller
<6>[ 1034.893606] xhci-hcd xhci-hcd: new USB bus registered, assigned bus number 1
<6>[ 1034.899038] xhci-hcd xhci-hcd: irq 163, io mem 0xf9200000
<6>[ 1034.907307] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
<6>[ 1034.907446] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
<6>[ 1034.907665] usb usb1: Product: xHCI Host Controller
<6>[ 1034.907787] usb usb1: Manufacturer: Linux 3.4.67-cyanogenmod xhci-hcd
<6>[ 1034.907913] usb usb1: SerialNumber: xhci-hcd
<7>[ 1034.908988] xHCI xhci_add_endpoint called for root hub
<7>[ 1034.909003] xHCI xhci_check_bandwidth called for root hub
<6>[ 1034.910726] hub 1-0:1.0: USB hub found
<6>[ 1034.910996] hub 1-0:1.0: 1 port detected
<6>[ 1034.912099] xhci-hcd xhci-hcd: xHCI Host Controller
<6>[ 1034.912646] xhci-hcd xhci-hcd: new USB bus registered, assigned bus number 2
<6>[ 1034.913686] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
<6>[ 1034.913904] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
<6>[ 1034.914014] usb usb2: Product: xHCI Host Controller
<6>[ 1034.914223] usb usb2: Manufacturer: Linux 3.4.67-cyanogenmod xhci-hcd
<6>[ 1034.914343] usb usb2: SerialNumber: xhci-hcd
<7>[ 1034.915876] xHCI xhci_add_endpoint called for root hub
<7>[ 1034.915891] xHCI xhci_check_bandwidth called for root hub
<6>[ 1034.916567] hub 2-0:1.0: USB hub found
<6>[ 1034.916705] hub 2-0:1.0: 1 port detected
<6>[ 1035.595662] usb 1-1: new high-speed USB device number 2 using xhci-hcd
<4>[ 1035.621628] usb 1-1: config 1 interface 0 altsetting 1 bulk endpoint 0x83 has invalid maxpacket 256
<6>[ 1035.626960] usb 1-1: New USB device found, idVendor=1b71, idProduct=3002
<6>[ 1035.627204] usb 1-1: New USB device strings: Mfr=3, Product=4, SerialNumber=2
<6>[ 1035.627600] usb 1-1: Product: usbtv007
<6>[ 1035.627816] usb 1-1: Manufacturer: fushicai
<6>[ 1035.628203] usb 1-1: SerialNumber:<PHONE_NUMBER>02
root@A0001:/ #

<38>[ 1360.429239] type=1400 audit(1464167968.032:1938): avc: denied { getattr } for pid=14059 comm="arksine.easycam" path="/dev/video" dev="tmpfs" ino=3932 sco
ntext=u:r:untrusted_app:s0 tcontext=u:object_r:video_device:s0 tclass=dir permissive=1
<36>[ 1360.430169] type=1300 audit(1464167968.032:1938): arch=40000028 syscall=327 per=800000 success=yes exit=0 a0=ffffff9c a1=9f407260 a2=bef54978 a3=0 items=
0 ppid=289 pid=14059 auid=4294967295 uid=10192 gid=10192 euid=10192 suid=10192 fsuid=10192 egid=10192 sgid=10192 fsgid=10192 tty=(none) ses=4294967295 comm="ark
sine.easycam" exe="/system/bin/app_process32_original" subj=u:r:untrusted_app:s0 key=(null)
<36>[ 1360.430526] type=1320 audit(1464167968.032:1938):

D/EasycamView(14059): EasycamView constructed
V/WindowManager(  883): Adding window Window{af76fe2 u0 SurfaceView} at 4 of 10 (before Window{1a7c4500 u0 com.arksine.easycam/com.arksine.easycam.easycam})
D/EasycamView(14059): Surface created
E/NativeEasyCaptureJNI(14059): Cannot open '/dev/video0': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Insufficient permissions on '/dev/video0': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Cannot open '/dev/video1': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Insufficient permissions on '/dev/video1': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Cannot open '/dev/video2': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Insufficient permissions on '/dev/video2': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Cannot open '/dev/video32': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Insufficient permissions on '/dev/video32': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Cannot open '/dev/video33': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Insufficient permissions on '/dev/video33': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Cannot open '/dev/video34': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Insufficient permissions on '/dev/video34': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Cannot open '/dev/video35': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Insufficient permissions on '/dev/video35': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Cannot open '/dev/video38': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Insufficient permissions on '/dev/video38': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Cannot open '/dev/video39': 13, Permission denied
E/NativeEasyCaptureJNI(14059): Insufficient permissions on '/dev/video39': 13, Permission denied
E/NativeEasycam(14059): Unable to V4L2 driver for 1b71 @ /dev/bus/usb/001/002
E/NativeEasycam(14059): Unable to load device settings.
E/EasycamView(14059): Error connecting device
D/Easycam (14059): surfaceChanged
I/Timeline(  883): Timeline: Activity_windows_visible id: ActivityRecord{373a5da u0 com.arksine.easycam/.easycam t57} time:1296299

Each /dev/videoX is a file. Linux reads and writes to this file to control the device.  Your output does show that you are in permissive mode, so it appears that permissions on the videoX files prevent user apps from access.  Most lilkely all of those /dev/video files are created by the system, and none of them actually represent your usbtv device.
Typically when a v4l2 driver is loaded, the corresponding /dev/videoX file is created with the correct permissions. Are you using a kernel with the usbtv driver compiled?  Assuming you have busybox installed, you can check with the lsmod command.  If you don't see "usbtv", you don't have the driver.

hi, i need compiled usb.ko module for arm kitkat how can i?

anyone can provide me usbtv driver for kitkat ?????


Proposal: add suggestion for bad configuration field

add suggestion for bad configuration field
Description:
The configuration of envoy is very complex, sometimes the words is confusing, for example: the socket_address.port_value, if we provide socket_address: { address: ..., port: ... }, and then we are going to get an error like this:

INVALID_ARGUMENT:(admin.address.socket_address) port: Cannot find field.) has unknown fields

It is hard to find out what the problem is. It would be graceful if the error could give some suggestions like git. For example:
INVALID_ARGUMENT:(admin.address.socket_address) port: Cannot find field.) has unknown fields

Did you mean one of these?
       port_value

I agree this would be a useful enhancement. We could build some edit distance ordered data structure at Envoy startup based on the descriptor pool reflection field names for each type.
I think one complexity here is that the error messages don't come directly from Envoy, but instead the C++ protobuf libraries. For binary protos, we actually don't have field names, only field numbers. For JSON/YAML, there is no support today in proto for obtaining the individual field names for unknowns, see https://github.com/protocolbuffers/protobuf/issues/5967.
I'll leave this open in case anyone wants to work on this (either Envoy-side or Protobuf-side).


Starting ydl.Download() causing windows forms to recreate a new window.

I really don't know why but every time I try to do the Download method it opens another window.
Steps to reproduce: create a simple windows forms app and start a Download
I appreciate if you can help me make it stay in the same form window.

I created a super simple Forms app and couldn't reproduce this. Can you provide a code snippet?

namespace WindowsFormsApp1
{
    using System;
    using System.Windows.Forms;
    using NYoutubeDL;

    public partial class Form1 : Form
    {
        private readonly YoutubeDL ydlClient = new YoutubeDL();

        public Form1()
        {
            InitializeComponent();
        }

        private void Button1Click(object sender, EventArgs e)
        {
            this.ydlClient.VideoUrl = "https://www.youtube.com/watch?v=vhgp_WId5ds";
            this.ydlClient.Download(true);
        }
    }
}

The problem is with event registering. Try to put the current information in a label.

Same thing.

namespace WindowsFormsApp1
{
    #region Using

    using System;
    using System.Windows.Forms;
    using NYoutubeDL;
    using NYoutubeDL.Models;

    #endregion

    public partial class Form1 : Form
    {
        private readonly YoutubeDL ydlClient = new YoutubeDL();

        public Form1()
        {
            this.InitializeComponent();
        }

        private void Button1Click(object sender, EventArgs e)
        {
            this.ydlClient.VideoUrl = "https://www.youtube.com/watch?v=vhgp_WId5ds";
            this.ydlClient.PrepareDownload();

            this.ydlClient.Info.PropertyChanged += (o, args) =>
            {
                VideoDownloadInfo info = (VideoDownloadInfo) o;
                this.Invoke(new MethodInvoker(delegate
                {
                    this.label1.Text = info.Title;
                }));
            };

            this.ydlClient.Download();
        }
    }
}


Improvement/cosi 57 use cosi scality runner

Purpose: test and debug using scality ssh running
Related PRs:
https://github.com/scality/actions/pull/154
https://github.com/scality/devdocs/pull/667
Slack thread: https://scality.slack.com/archives/CFDJAPQ6S/p1730976697811189?thread_ts=1730909009.537229&cid=CFDJAPQ6S
Original idea: https://github.com/scality/cosi/pull/9#discussion_r1830640664

Closed in favor of https://github.com/scality/cosi-driver/pull/2


refactor(app-about, app-members, app-team-landing, en.ts): Added youn…

…g's bio and connected members'

resolve merge conflicts

There are a couple errors in the data object on app-team-landing.tsx. Other than data it looks good, so after that fix it should be ready for merging.

I got it.
I deleted my branch of OPENFORGE.IO
On Mon, Oct 22, 2018 at 1:50 PM Luis Carlos Chacón<EMAIL_ADDRESS>wrote:

Merged #256 https://github.com/openforge/OPENFORGE.IO/pull/256 into
develop.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/openforge/OPENFORGE.IO/pull/256#event-1918122500, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AX82n26_YkHORiG_FagDIP7RQfhcFRXnks5ungVbgaJpZM4Xkug8
.


After logging in the dashboard's header does not have proper orientation

Let me know if any work needs to be done on this. The logged-in name is pushed up  and the alignment of things are not perfect and also some part of the header is coming down a bit as you can see

Let me know if any work needs to be done on this. The logged-in name is pushed up  and the alignment of things are not perfect and also some part of the header is coming down a bit as you can see

@Sloth-Panda I will assign the issue to you so that you can start your work.

@Sloth-Panda I will assign the issue to you so that you can start your work.

@swapnilsparsh check it out

@swapnilsparsh check it out

Issue resolved by @Sloth-Panda

Issue resolved by @Sloth-Panda


User joined activity

Description

active_joined_activities class method in Attend returning all active activities for a user, with user as a parameter.
recently_joined class method in Attend returning 3 latest activities joined by user, with user as a parameter.

Functional Acceptance Criteria

Attend.active_joined_activities(user) returns all activities joined by user, order by activity date.
Attend.recently_joined(user) returns 3 latest activities joined by user, order by join time (attend_id).

Checklist

[x] I have performed a self-review of my code.
[x] I have added tests to cover my changes.
[x] I have updated the documentation, if applicable.
[x] My code follows the Coding Guidelines.

Type of Change

[ ] Bug fix
[x] New feature
[ ] Documentation update
[ ] Other (please specify)

Well we might pass to api after this.

Also merge your branch from main first

Even I fixed that testcase


Homelink example script arguments and documentation appear incorrect

As best I can tell, the homelink example script does not use the --name argument which it requests with the description asking for a phone Bluetooth name. This appears to be copied from the calendar script. If this is indeed not used, it should probably be removed from the script and documentation.

Yes, that does appear to be a copy error.  Thanks for catching.

Thanks! Shall I close this or will you take care of that?

I'll close!  Thanks again.


Fix typo in code sample

Just a minor typo in the code sample in the readme.

Coverage decreased (-2.7%) to 61.757% when pulling 2c6076c1b4a78938438d8c64a52c5bcedbadde44 on Mark-H:patch-1 into c317aad071cddb0bd022fb9e3a6e87cad38de730 on collizo4sky:master.


Status? Thoughts?

Hi there,
I'm wondering if there's still an intention to pursue the integration of r3f with jolt? AFAICT it's possible to integrate jolt and threejs. I'm curious about what your experience was attempting to write react-three-jolt? Any obstacles you ran into or thoughts you might be able to share?
Cheers,
Jun

FYI, there is this sandbox which integrates jolt with r3f https://codesandbox.io/p/devbox/jolt-physics-react-three-fiber-demo-hxkkje?file=%2Fsrc%2FApp.tsx

There will be more activity here soon 👀

To elaborate -
This repository has been acting as a placeholder for a comprehensive r3f jolt library.
I created that sandbox as a demonstration of what a very simple react three fibre + jolt integration looks like, but couldn't commit to building a full fledged rt/jolt library.
Using jolt directly is very doable, people are already using JoltPhysics.js with threejs and other libraries. Much of the value of creating a react-three/jolt library is ease of use and interop with the rest of the react-three ecosystem.
More recently @DennisSmolek has been working on a react-three/jolt library, so this repository won't be placeholder for much longer. Stay tuned 👀


Add publish assignment poll function

Here my fix which needs adaptation on rest api side to provide new publishPoll function (see my mail):
https://github.com/OpenSlides/OpenSlides/compare/master...emanuelschuetze:fix1718?expand=1

Not tested: Adding required=False to the votes field in the serializer might do it.

Works with #1778.

Is this done?

yes, done.