Specifications for using dictionary version to generate rules

Each ODM version with have rules that are specific to that version. In other words, each version of the ODM has its validation schema.
There was an important change to the organization of the dictionary from Version 1 to 2. Validation rules and schema can be applied to Version 1. This PR includes information to guide those rules.
For discussion and not included in this PR. Currently, an ODM dictionary version is identified within GitHub version tags. This means that the parts table name does not change, and a parts table when viewed by itself does include metadata that describes the version. We currently do not have, for example, parts_V2.0RC.csv, we just have parts.csv.
That said, there should be good hits about the version of the part.csv. For example, the largest value of 'lastUpdated' should equal the version of the parts table.

@DougManuel

Would each version 1 part use the same validation metadata as their version 2 equivalents? For example, assayID was replaced with methodID.
Ideally when a part is deprecated, the lastUpdated column would not be the same as the firstReleased. In your example for comp3, both columns have the same value , 1, which tells me that it was deprecated in version and should not be included in it. Recommend making changing tolastUpdated` to 1.1 or 2, so it can be included in the validation schema for v1 of the ODM.
Does the ODM use semver versioning, i.e. minor and major versions indicate breaking changes?

Mostly, the rules are the same in version 1 as in version 2. However, there are differences in both the organization of the dictionary and the specific rules. As an example, we don't have mandatory fields in version1, but we do in version 2. As well, table names have been renamed with a few breaking changes. measures in version 2 is Wwmeasures in version 2.

We followed LOINC for the released and updated versioning. (Or at least what we thought LOINC does). This versioning approach was introduced in Version 2 isn't finalized. So, we can modify the approach. I think we interpret being depreciated or replaced as not an update. Rather a depreciate is a depreciate. Currently, firstReleased and lastUpdated with the same version indicates that the part was never updated before being depreciated.

Yes. Following semver versioning. However, remember it is for the entire dictionary. So, if any part of the dictionary is breaking it would be a .1 update. i.e from 2.0 to 2.1.

@DougManuel I've updated the specification to provide more details on the logic and also rearranged some items
@mathew-thomson Do you mind checking the if logic for backporting from version 2 to version 2 makes sense?

@yulric The update looks good.
A few notes:

parts.csv has been updated to more closely follow semantic versioning. Now the versioning is "2.0" (text)where it was previously 2 (interger).
We need to have Cerebus schemas saved in the repository - not just the ability to make a schema. This means we need to have schemas that can validate all versions of the ODM dictionary. This doesn't mean that we need to have a schema for every ODM version update, but I think it does mean that we need a new schema whenever we make new parts, or breaking changes to parts. For example, we'd need a new schema if we make a change to mandatory headers or add a new category. However, we wouldn't need a new schema if we changed a part label.

I envisioned we'd have a folder that would be something like 'assets' and then have assets/rule-schema-v11.py, assets/rule-schema-v20.py. Don't know. Not elegant. Not sure what people do in situations like this. Remember that all these schemas may also be updated. So, we could have a repo update for the PHES-ODM-validation from 1.0 to 1.1, which may update some of the rule-schema-vxx.py files. Feels complicated....

Clarification on dictionary coding for depreciated parts. https://github.com/Big-Life-Lab/PHES-ODM/issues/229

@DougManuel I wonder about having the validation schema saved in the validation repo as opposed to the ODM repo.
If every change to the ODM triggers a new validation schema, then putting it in the validation repo would require an update, without any update to the actual code.

@DougManuel @zargot Updated based on your feedback. Can one of you approve?

I started the review. So, @yulric or @zargot will need to approve. ;)


Center of mass and translate operation added

New functions center_of_mass and translate were implemented and added to Proprieties.jl and Transformations.jl respectively.
They replace the functions calcCOM and centerXYZ that are now removed.
Minimal tests are included for it.

Codecov Report

Merging #2 (56b8988) into main (d25e280) will decrease coverage by 13.58%.
The diff coverage is 27.65%.

@@             Coverage Diff             @@
##             main       #2       +/-   ##
===========================================
- Coverage   88.88%   75.30%   -13.59%
===========================================
  Files           7        7
  Lines         135      162       +27
===========================================
+ Hits          120      122        +2
- Misses         15       40       +25

Impacted Files
Coverage Δ

src/Molecules.jl
100.00% <ø> (ø)

src/ZMAT.jl
0.00% <0.00%> (ø)

src/Parse.jl
86.48% <100.00%> (ø)

src/Properties.jl
100.00% <100.00%> (+100.00%)
:arrow_up:

src/Transformations.jl
100.00% <100.00%> (ø)

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 d25e280...56b8988. Read the comment docs.


refactor: dependency request use JsWord

Summary
Because importVarMap will clone request as key, so here use JsWord to avoid string clone.

Test Plan
It's not requried

!bench

Hard to say which is better since JsWord is hard for migrating to oxc and there is basically no change in benchmark

!bench

!bench

!bench

!bench

close for stale


Update intro with minor text changes and some links

@plaindocs Some minor changes (didn't brake the build this time). Let me know what you think.

@Zearin Thanks for the review. One minor change, as you suggested! :)

This deploy also currently failing due to heavy load on http://pragprog.com (see comment in https://github.com/cucumber/docs.cucumber.io/pull/21)

Close this PR; will redo on master.


feat: support DDL show cluster to display cluster info

What problem does this PR solve?

Issue Number: resolve #452
What is changed and how it works?
Please describe how it works
➜  openGemini git:(cluster-status) ts-cli
2024/01/04 17:18:53 proto: duplicate proto type registered: influxql.Measurements
2024/01/04 17:18:53 proto: duplicate proto type registered: influxql.Measurement
openGemini CLI 0.1.0 (rev-revision)
Please use `quit`, `exit` or `Ctrl-D` to exit this program.
> show cluster
+---------------------+--------+----------------+--------+----------+
| time                | status | hostname       | nodeID | nodeType |
+---------------------+--------+----------------+--------+----------+
|<PHONE_NUMBER>579799000 | 0      | <IP_ADDRESS>:8091 | 1      | meta     |
|<PHONE_NUMBER>579799000 | 0      | <IP_ADDRESS>:8091 | 2      | meta     |
|<PHONE_NUMBER>579799000 | 0      | <IP_ADDRESS>:8091 | 3      | meta     |
|<PHONE_NUMBER>579799000 | 1      | <IP_ADDRESS>:8400 | 4      | data     |
|<PHONE_NUMBER>579799000 | 1      | <IP_ADDRESS>:8400 | 5      | data     |
|<PHONE_NUMBER>579799000 | 1      | <IP_ADDRESS>:8400 | 6      | data     |
+---------------------+--------+----------------+--------+----------+
5 columns, 6 rows in set

> show cluster where nodeID = 1
+---------------------+--------+----------------+--------+----------+
| time                | status | hostname       | nodeID | nodeType |
+---------------------+--------+----------------+--------+----------+
|<PHONE_NUMBER>958993000 | 0      | <IP_ADDRESS>:8091 | 1      | meta     |
+---------------------+--------+----------------+--------+----------+
5 columns, 1 rows in set

> show cluster where nodeID = 1 and nodeType = meta
+---------------------+--------+----------------+--------+----------+
| time                | status | hostname       | nodeID | nodeType |
+---------------------+--------+----------------+--------+----------+
|<PHONE_NUMBER>034243000 | 0      | <IP_ADDRESS>:8091 | 1      | meta     |
+---------------------+--------+----------------+--------+----------+
5 columns, 1 rows in set

> show cluster where nodeType = meta
+---------------------+--------+----------------+--------+----------+
| time                | status | hostname       | nodeID | nodeType |
+---------------------+--------+----------------+--------+----------+
|<PHONE_NUMBER>726427000 | 0      | <IP_ADDRESS>:8091 | 1      | meta     |
|<PHONE_NUMBER>726427000 | 0      | <IP_ADDRESS>:8091 | 2      | meta     |
|<PHONE_NUMBER>726427000 | 0      | <IP_ADDRESS>:8091 | 3      | meta     |
+---------------------+--------+----------------+--------+----------+
5 columns, 3 rows in set

> show cluster where nodeType = mda
ERR: invalid node type%!(EXTRA string=mda)
> show cluster where nodeID = de
ERR: error parsing query: Invalid where clause

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Test A
[ ] Test B
[ ] Test cases to be added
[ ] No code

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

it is better to convert status to a string，because the meanings of numbers cannot be understood.


Overlays not update from inside event

I want to drag a marker and to readd a layer (i pass data on server so i want to reload it if marker pos change), but nothing happens. I tried inside draggend marker callback to:
make layers visible= false and true again.
reassign the layer object.
In both cases it fails. I can remove the layer and add it through leaflet data getMap() with remove and add these overlays, but its not the proper way i guess...
Any suggestions?

Please, we need an example, try to reproduce the problem in a jsfiddle an post it here.
Anyway, there has been a lot of changes in the markers functionality later, so you problem could be fixed with the current trunk.
I'm closing it, please reopen if needed.


topic: Fix history order for topic moves.

5c96f942060e mistakenly appended, rather than prepended, the edit to the history.  This caused AssertionErrors when attempting to view the history of moved messages, which check that the last_edit_time matches the timestamp of the first edit in the list.
Fix the ordering, and update the edit_history for messages that were affected.  We limit to only messages edited since the commit was merged, since that helps bound the affected messages somewhat.
Cherry picked from commit b747ea285f9a1f1077007c8fd0700c9dea2a148b. Because we have already merged other migrations, this migration is renumbered to 0517, which will appear as a no-op migration on main.

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[ ] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[ ] Calls out remaining decisions and concerns.
[ ] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[ ] Each commit is a coherent idea.
[ ] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[ ] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[ ] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

The CI failure is an unrelated thing that needs to be addressed by backporting changes for 24.04 support.

Merged, thanks @alexmv!


[Feature]: Connection SNI Routing with Traefik

Is there an existing issue already for this feature request/idea?

[X] I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

What problem is this feature going to solve? Why should it be added?
Current ingress requires a separate port for each Postgres cluster because TCP cannot be dynamically routed to the host like with HTTP. TLS TCP traffic can be routed with Server Name Indication (SNI) and TLS/SSL database connections are default with CNPG.
Traefik v3 includes proxy SNI routing of Postgres traffic. This would allow host-based routing of postgres clusters on a single port residing in the same K8s cluster.
Describe the solution you'd like
Include a standalone Traefik v3 deployment in the CNPG operator that handles Postgres ingress into the k8s cluster.  The operator would handle deployment and basic configuration of the Traefik SNI proxy.
Describe alternatives you've considered
Recommended approach in the documentation only, no operator support.
Additional context
I have successfully tested this in a K8s cluster for ingress connections. I have not tested postgres replication between K8S clusters.
Backport?
No
Are you willing to actively contribute to this feature?
No
Code of Conduct

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

@bkief I notice you have already tested Traefik successfully, can you please share the solution?

@bkief I notice you have already tested Traefik successfully, can you please share the details about the solution?

Agree. Can you please share what you have?

@xieydd @gbartolini - Here is a gist for a basic k8s setup. https://gist.github.com/bkief/32aeafe7c33db92fafda0308ec9c31dd
It uses a NodePort on 30007, but it could easily be a LoadBalancer on 5432 if you wanted to keep the standard port. The only thing that needs editing when adding a new database is an addition to the Traefik config in the configmap, specifically adding a new router and service for each database. Unfortunately Traefik does not yet support routing rules for SNI, so this has to be manually maintained. Not included here but its assumed that the CNPG service is running at opseng-tsdb-rw.tsdb.svc.cluster.local:5432 on the local K8s DNS. Also please note that only Traefik 3 support Postgres style TLS, and v3 is still in beta.
Hopefully that is all clear and good luck!

Since this could be just documentation and since traefikv3 still in dev, @bkief can you consider create a PR with this documentation? something like an example?
Regards

hello, I'm starting to use cloudnative-pg and I have the same problem using traefik. I solved it using the following Traefik ingress route.
Then to connect to the db we need just to put the correct hostname (the one we configured inside the HostSNI ) and port 443

and we need to configure the SSL mode to require

Regards


Support for yeelink.light.ceiling19

Is it possible to add full support for yeelink.light.ceiling19?

Try master branch.


Rename GOFUNC keyword to _GOFUNC

See this post:
https://sourceforge.net/p/pcbasic/discussion/programs/thread/e68427e82d/#9286

Fixed in https://github.com/udhos/basgo/commit/b0e493e95161ecba57ee00583b2f7936b6e958d7


Update emails-sent-to-users-when-their-settings-change.md

https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/2141
Fixed command.

@nenonix @JohanFreelancer9 Copy editing is needed for this PR. Thanks.

@tonysmit changes look correct. Could you please confirm and merge? Thanks!


Hyprland lags after some time

Regression?
No (It didn't really stop working completely, but got worse)
System Info and Version
 System/Version info
Hyprland, built from branch  at commit 9a09eac79b85c846e3a865a9078a3f8ff65a9259  (props: bump version to 0.42.0).
Date: Wed Aug 7 19:17:10 2024
Tag: v0.42.0, commits: 5069

flags: (if any)

System Information:
System name: Linux
Node name: archbtw
Release: 6.10.8-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Wed, 04 Sep 2024 15:16:37 +0000

GPU information:
00:02.0 VGA compatible controller [0300]: Intel Corporation Meteor Lake-P [Intel Arc Graphics] [8086:7d55] (rev 08) (prog-if 00 [VGA controller])

os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

Description
Everything went well until I installed spotify and it was basically unusable the songs would update like 20-30 seconds later. I tried it on kde, thinking it was the package problem, but apparently it worked fine on kde but not on hyprland. So I use the web app of spotify and then it just started lagging, very low frame rates it was unusable even the pc, so I shut it down and after a boot it seems pretty normal but when I full screen the apps it keeps stuttering here and there and it's not the same as before.
How to reproduce
Using intensive resource programs and generally hyprland for a long period of time
Crash reports, logs, images, videos
No response

@akaneboy I just disabled notifications as suggested on https://www.reddit.com/r/archlinux/comments/a7t079/spotify_having_slow_reaction_time/ and the delays are gone.

that would sound like a missing notification daemon to me @kllmanu

@akaneboy I just disabled notifications as suggested on https://www.reddit.com/r/archlinux/comments/a7t079/spotify_having_slow_reaction_time/ and the delays are gone.

i think the problem is bigger than spotify now when i try to just download hyprland without any config anything it just runs so slow it's unusable, i can't use it


[core] Handle refType in the proptypes generation

Solves https://github.com/mui/mui-x/issues/8326#issuecomment-1712652678

Closing per https://github.com/mui/material-ui/pull/38917#discussion_r1354355582


Triggers errors on pages with SVG objects

My console gets filled up with one–four copies of this error whenever the Coil extension is enabled on any website with an <object data="some.svg" type="image/svg+xml"></object> (example page).
XML Parsing Error: not well-formed
Location:
Line Number 5, Column 38:

See this note.
Firefox 86, macOS/Linux/Windows. Coil 0.0.51-amo.

Thanks for the report! Will look into it

Related #1642


Updates GUI text for new Homebrew version

The instructions in the GUI for downloading the kindle-comic-creator cask utilize an old brew command, so this PR updates the GUI text with the command that Homebrew uses now. It also renames references to "Brew" to "Homebrew".

This is what current homebrew tells you if you use the old command that the GUI suggests:
jameskerrane@Jamess-MBP ~> brew cask install kindle-comic-creator
Error: `brew cask` is no longer a `brew` command. Use `brew <command> --cask` instead.

This is a successful installation with the command that I changed the GUI instructions to:
jameskerrane@Jamess-MBP ~ [1]> brew install --cask kindle-comic-creator
==> Downloading https://kc2.s3.amazonaws.com/KindleComicCreatorInstall.dmg
Already downloaded: /Users/jameskerrane/Library/Caches/Homebrew/downloads/29bff483a8f694859b20eacf3cd654d0565c07fc31165f9ba8408c3f88edb26a--KindleComicCreatorInstall.dmg
Warning: No checksum defined for cask 'kindle-comic-creator', skipping verification.
==> Installing Cask kindle-comic-creator
==> Running installer for kindle-comic-creator; your password may be necessary.
Package installers may write to any location; options such as `--appdir` are ignored.
Password:
installer: Package name is Kindle Comic Creator
installer: Installing at base path /
installer: The install was successful.
🍺  kindle-comic-creator was successfully installed!

@thatrobotdev
Just a nitpick, since you can't copy paste from the UI, might be better to link change the wording and link to a wiki page instead.

A direct link to this wiki page might be nice, although for users already familiar with Homebrew I appreciate the cask name being mentioned in the app- https://github.com/ciromattia/kcc/wiki/Installation#mac
Maybe something like, "Cannot find Kindle Comic Creator! Install the 'kindle-comic-creator' cask using Homebrew to enable MOBI conversion".
It looks like the original link to KindleGen is defunct, so this would also solve that issue.

@thatrobotdev
I made a PR:

https://github.com/ciromattia/kcc/pull/555

Can you tests if this is ok for you?
I'll merge it.


Is it undefined behavior to hold an invalid reference, if it is never dereferenced.

It is not Safe in rust code to create invalid references, in that these references can be used by safe code to trigger Undefined Behavior, however, is it Undefined Behavior to create one of these references?
For example, does this code trigger Undefined Behavior?
struct Foo {...}
let _x: &const Foo = &*(1024 as *const Foo);

How about this code, which gets the address of the member, but does no reading?
struct Foo {
    member: i32
}
let _x: &i32 = &(*(1024 as *const Foo)).member;

How about this code, which creates an invalid reference by over-extending the lifetime, but does not follow it?
struct Foo {...}
let _x: &'static Foo;
{
    let y = Foo {...};
    _x = mem::transmute(&y);
}

Or this code, which creates a reference with the wrong lifetime, but only follows it while the object behind it is still alive?
struct Foo {
    member: i32
}
let y: &'static Foo;
{
    let x = Foo {...};
    y = mem::transmute(&x);
    println!("y.member = {}", y.member);
}

I believe the second two are equivalent.
The real question is, are these different:
let x: &'static Foo;
let foo = Foo {...};
x = unsafe { &*(&foo as *const _) };

// x is never alive while foo is not, *but* the lifetimes are a lie

I'd argue your examples are all the same actually; invalid references. References which either point to objects that don't exist, or which point to freed objects.
I'm not sure if this should be UB, although I lean to yes, but I don't like accessing it while the reference is alive to change it. Also, the first three should, in my opinion, at least be the same, even if we do decide to look at accessing things for UB.

I lean towards none of these being Undefined Behavior. I feel like in rust, we want to make sure that when people write unsafe code which they would expect to work in other languages, that code works in rust as well.
Since references act a lot like pointers, it seems reasonable to assume (from the POV of an unsafe rust programmer coming from other languages like C/C++) that they act like C++ pointers - that is that invalid references are invalid, and thus cannot be followed, but that they don't trigger any UB unless they are dereferenced. If we want to make our memory model as intuitive as possible for people, I think we should make sure that this type of behavior is not UB.
I think it's fairly likely that a decent number of existing crates depend on invalid references not triggering UB in order to work correctly, and it would be a shame to break them, or make them trigger UB, when we can avoid it at (what I would imagine is) almost no performance cost. I am not an expert in this area, but I'm not sure what optimizations we could gain by assuming that these references cannot exist in codegen.
This also fits into the goal of making unsafe rust nicer to write than many other languages (such as C) by reducing the number of pitfalls which can screw you up and trigger UB I understand that unsafe rust will always be hard due to the need to maintain rust's invariants (which include things like not having invalid references) at the safety boundary, but allowing people to break some of these invariant without necessarily triggering UB behind the safety privacy boundary seems reasonable, and like it will make more reliable programs. Many people complain about how C has too much Undefined Behavior, which is too easy to trip over, and I don't want Rust to make the same mistake without good reasons.

@mystor I'd argue that Rust references are far more like C++ references; &T -> T const&, &UnsafeCell<T> -> T&, &mut T -> T&&.

@mystor: @ubsan: But unlike C++ references, Rust references with lifetimes greater than their referents are (or IMO should be) illegal/UB because they allow safe code to cause UB, trivially (or accidentally, simply by autoderef), and with no way for the safe code to tell that is a risk.
IMO, references are something of the canonical example of "you should never even construct an invalid/mistyped/mis-lifetimed instance" - largely because of how incredibly easy it is for an invalid lifetime to leak out of unsafe {} or even broader boundaries (such as the module).

@eternaleye I don't really agree. I feel like lifetimes shouldn't exist at all after typechecking; they should only be a lint tool, to me. Just because safe code might cause UB with what unsafe code has done doesn't mean doing it in the unsafe code should be UB.

@ubsan: My point is that permitting the construction of references with invalid lifetimes is a huge footgun, due to how easy it is for that to pollute safe code on accident (via inference or otherwise).
Meanwhile, I'm not sure there are any useful patterns for references with invalid lifetimes that are not served equally well by raw pointers - whose big distinction is that they neither have nor enforce lifetimes.
Blurring the lines between them by permitting references to have invalid lifetimes, when you aren't permitted to dereference them, seems to me as if it encourages unnecessarily risky behavior on the part of the user.

@eternaleye I have personally used them in my own code :)
struct Foo {
    foo: Box<Foo>,
    foo_ref: &'static Foo, // reference into self
}

and other similar pattern: I've gone through 'static references to do things a lot. There's no point to making it undefined, except for some notion of nicer. It only outlaws more code, without making it easier to do anything compiler-y, so AFAICT, it only makes it harder to write correct Rust code. The point is to hopefully make it easier.

AFAIK in the current implementation there are currently only 3 restrictions on references:

nonzero: Can't be null. This is necessary for the enum layout trick.
noalias: No mutable aliasing.
dereferencable: The reference must point to valid memory (ie doesn't segfault). That memory doesn't need to contain a valid value, it just needs to not fault.

Violating any of these is UB. However there are also additional restrictions we may want to apply when dereferencing a reference:

Alignment: IMO a reference should only need to be correctly aligned when it is dereferenced. This allows the use of references to fields of a packed struct for example, which is unsafe (can cause UB from safe code) but not UB on its own if they are not dereferenced.
Valid value: This one is more debatable. Having a reference to an invalid value should be fine so that we can support the use of mem::uninitialized(). Overwriting such a value with ptr::write is also fine. The question is, is it UB to read such a value? I'm not entirely sure about this one.
Transient dereference: Is it UB to dereference an invalid reference without accessing any of its memory. One example of this is to get a reference to a sub-field of a reference (&a.b -- technically a is dereferenced, but its memory is never accessed).  The question can be reformulated as "does UB occur when we dereference or when we perform lvalue to rvalue conversion?" I am currently tending towards the latter.

@Amanieu lexpr to vexpr conversion ;P
I'd argue, for now, that it should be UB, but I think we should postmark it for revisiting in the future.

Since references act a lot like pointers, it seems reasonable to assume (from the POV of an unsafe rust programmer coming from other languages like C/C++) that they act like C++ pointers - that is that invalid references are invalid, and thus cannot be followed, but that they don't trigger any UB unless they are dereferenced.

Just a quick remark on this: Actually, at least in C11, creating an invalid reference is UB. From section 6.5.6 of the standard:

If both the pointer
operand and the result point to elements of the same array object, or one past the last
element of the array object, the evaluation shall not produce an overflow; otherwise, the
behavior is undefined.

@ubsan

There's no point to making it undefined, except for some notion of nicer. It only outlaws more code, without making it easier to do anything compiler-y

This is very interesting to me. I am sympathetic to this POV, but it seems to be one of the key questions that we need to decide: "to trust types or not to trust types". I think that using &'static u32 when, in fact, the underlying value is not 'static is strongly related to examples like "RefCell-Ref". This kind of example, to my mind, pushes us quickly towards "Tootsie-Pop"-style models, which I know you have historically been opposed to. =)
That said, I think I agree with @mystor that we have to tread carefully here -- it seems obvious to me that "access-based" models are likely to be less error-prone. I am very wary of giving too much significance to types.
Another related issue is the "only-access-using-volatile-loads" use case described in #16.

One thing I think may be worthwhile is to examine how many ways an invalid reference in unsafe code could give rise to an invalid reference in safe code - I'm particularly worried about lifetime inference.
If this turns out to be "not many, and easily managed" then making it UB to pass an invalid reference across an unsafe {} boundary into safe code would seem to make sense to me.
If it turns out that there are many, or that they're hard to defend against, then from an ergonomics and teachability standpoint, I think it'd be better to outlaw creating such references, even within unsafe code.
The third option, allowing invalid references to exist in safe code, seems to fall into the Tootsie-Pop zone, and notably constrain the optimizer on safe code.

@eternaleye Please define "invalid reference". I can't tell if you're talking about
{
    let y = 0;
    let x: &'static i32 = &* (&y as *const i32);
}

which should be fine, or
{
    let x: &'static i32 = &*(&0 as *const i32);
    x
}

@ubsan
To be clearer, I'd call this:
let x = unsafe {
    let y: &'static i32 = &*{
        let z = 0;
        &z as *const i32
    }
}

"passing an invalid reference to safe code across an unsafe {} boundary"
The let y creates it, but my worry is that there may be other ways of doing this that are not near to the point it's passed across, and which thus result in "spooky" invalid references making their way to safe code.
Once an invalid reference has made it to safe code, we have two options:

Constrain the optimizer in (at least some) safe code, removing its ability to optimize based on dereferenceability, including under inlining. This leads rapidly to the Tootsie-Pop model.
Admit UB that is potentially very hard to diagnose and correct, due to non-locality between the point at which UB occurs and the code which caused it to occur.

My preference is to prevent invalid references from entering safe code, but if it is hard to prevent an invalid reference (once created) from reaching safe code then case 2 recurs. As a result, it would then be beneficial to make constructing it invalid, such that it's a good boundary for best-effort lints, or a sanitizer which does preserve lifetime information in the binary.

@eternaleye that does not answer my question. I'm asking your definition of invalid reference, not for an example of one :P

@ubsan: An invalid reference is a reference that doesn't satisfy its contract, just like an invalid instance of any other type.
For references, the contract is that it points to a value of the specified type, and that the value outlives the specified lifetime.

@eternaleye
So you're saying the first example of mine should be undefined behavior? This:
struct Foo {
    foo: Box<u8>,
    foo_ref: &'static u8,
}

fn new() -> Foo {
    let b = Box::new(0);
    let ref_ = unsafe { &*(&*b as *const _) };
    Foo {
        foo: b,
        foo_ref: ref_,
    }
}

because I've definitely written this code; that foo_ref is not 'static.

I'd say that can't possibly be anything other than UB without a Tootsie-Roll model.

@eternaleye
I can't think of a reasonable model where that isn't defined behavior: no invalid reference ever exists (invalid meaning "points to an invalid value or invalid memory"). No memory model that I have seen so far has taken lifetimes into account: they aren't intended to be used for codegen, just for static analysis.

@ubsan
My model does consider lifetimes in safe code. IIRC old trans considered lifetimes in some situations.

Complete newbie here, but it seems like any code which creates a Foo and then tries to do anything at all with the foo_ref member (or call any Foo methods that touch that member) would be immediately invoking UB, since that member has already been dropped. It seems no different from "use-after-free" to me, which I assume is considered UB in Rust. The only question is whether "making-accessible-to-safe-code-after-free" should be UB as well, but I can't think of any reason we would want to allow that.

@lxrec The point (heh) is that, while the pointer foo_ref exists, foo also exists, and foo_ref points to *foo.

@ubsan

@lxrec The point (heh) is that, while the pointer foo_ref exists, foo also exists, and foo_ref points to *foo.

That's not a guarantee; it's a precondition - one that needs to hold on every piece of code that accesses it.
A guarantee is enforced; a precondition is relied on - and violating a precondition is UB.
Because the precondition there is not enforced by the type system, it can be violated by safe code.
As a result, safe code must behave very precisely - in particular, there are behaviors allowed by the type system that it must not perform, or else cause UB.
If the optimizer is unaware of exactly what those behaviors are (and that's a huge, possibly insoluble, kettle of fish in its own right), then the only solution is to apply blanket restrictions to the optimizer if such behaviors could exist.
Since such behaviors could exist if it's ever valid to pass an invalid instance of a type to safe code across an unsafe {} boundary, the only options for bounding such restrictions become privacy-based. Specifically, module and crate boundaries.
Thus, we arrive at the Tootsie-Pop model. One which I (and I believe you as well?) do not favor.

Id love to read some explanation as to the problems with the Tootsie-Pop model. Since I read the blog post, it has always seemed like a relatively sane model for allowing breaking the rules in unsafe code, and avoiding the problems with people triggering ub when writing that unsafe code, but still allowing aggressive optimization in most of the program.

The only explanation I could find was http://smallcultfollowing.com/babysteps/blog/2016/08/18/tootsie-pop-followup/, which if I understand correctly boils down to: Unsafe code is usually intended as an optimization, but if the optimizer is forced to be more conservative around any unsafety boundaries, then unsafe code can end up being slower than safe code; the example given was vec.get_unchecked() being potentially slower than the safe-but-bounds-checked vec[i] operation. If there's more explanation than that, I'd also love to hear it.

There was a (lengthy) discussion thread on internals.rust-lang.org.

I can't think of a reasonable model where that isn't defined behavior: no invalid reference ever exists (invalid meaning "points to an invalid value or invalid memory"). No memory model that I have seen so far has taken lifetimes into account: they aren't intended to be used for codegen, just for static analysis.

It was my understanding that there are a bunch of desirable optimizations that crucially rely on lifetimes being correct; or at least, they rely on references being more than just "valid" according to your definition. For example
fn foo<F: FnOnce()>(x: &mut u32, f: F) -> u32 {
  let r = *x;
  f();
  r
}

The compiler is (in my understanding) allowed to move the dereference of x after the call to unknown code. If x however is a perfectly valid reference that just happens to not be exclusively borrowed to foo for the given lifetime (but, say, for another lifetime that has long ended), then this transformation is incorrect.
Actually, I cannot see how a model would allow such transformations without taking lifetimes into account. According to your statement, a transmute that changes the lifetime (and nothing else) could never invoke UB, because the only bit that changed (the lifetime) is entirely irrelevant for the memory model. I must be missing something here?

@RalfJung

Actually, I cannot see how a model would allow such transformations without taking lifetimes into account.

Indeed, this is more or less what I concluded in this recent blog post.

I'd like to expand the scope of this topic beyond "holding an invalid reference", namely:
Even if we permit "holding" (but not using) invalid references, what about unaligned references? What about NULL references? Also, we certainly permit "holding" invalid and NULL pointers, but what about unaligned pointers?
See https://internals.rust-lang.org/t/rules-for-alignment-and-non-nullness-of-references/5430.
Actually, I think this goes beyond pointers. To me, the question is: Are there cases where even just "temporarily holding but not using an invalid value inside an unsafe function" is UB? (I am restricting this to "inside a function" because I think there are some guarantees we want to uphold even for unused values when certain or all function boundaries are crossed. In fact, this is needed for some optimizations.)
Most types don't matter here, as they clearly don't have any invalid values. Notable exceptions are pointers/references (this is what has been discussed here), str (must be valid UTF-8), bool and enums.
On the one hand, if the answer to the question is "yes" -- if there are such cases where just creating/holding a bad value is UB -- then we get into the difficult game to define what does and what does not constitute a use. Store/load, conditional branching, and pattern matching clearly do (and there is, I think, no question that these are UB for "invalid" values, but who knows?). But other cases are less clear-cut. Is it insta-UB to transmute 3u8 to bool? What about loading 3u8 from memory with a bool-pointer?
So, I'd somewhat prefer if we had as little such "invalid value UB" as possible -- ideally, none. It seems like a terrible footgun. However, I am not sure if that can be reconciled with NonZero and the optimizations the compiler does around it...
Just dropping problems here, not proposing solutions to all of them. ;)

@RalfJung yeah, I'm also of the opinion that we should make it as easy as possible to not commit UB, within reason. Passing and returning invalid values shouldn't be UB for example. OTOH, I don't think that invalid values should be treated specially - they should simply be treated as uninitialized. Use is UB, but there's a lot of stuff you should be able to do without it being UB.

Passing and returning invalid values shouldn't be UB for example.

I don't think that's always possible...
fn some_fn(x: &mut u32) {
  other_unknown_fn();
  *x = 13;
}

It should be permitted for the compiler to move the store around the call. However, if passing a bad pointer into some_fn is NOT UB, and other_unknown_fn diverges, that optimization is incorrect.

@RalfJung note that that is a use of x.

(the dereference, that is)
The passing itself isn't UB, but it's definitely not okay to do that to random APIs; you're breaking an API that the function has, and then the function does UB because you broke its API.

@ubsan

note that that is a use of x.

True -- but the use is after other_unknown_fn is called. If that function diverges, some_fn does not UB even if x is invalid. So, if we take your interpretation, reordering the store and the call is illegal. I think we want it to be legal, though.

@RalfJung ah, I guess that's true. Although, if you think about it, if we don't know if this function is noexcept or not, we can't reorder the store anyways, even if the pointer is valid.

@RalfJung perhaps passing as a parameter could be counted as a use, though? I'm not sure.

Although, if you think about it, if we don't know if this function is noexcept or not, we can't reorder the store anyways, even if the pointer is valid (because if it throws an exception, the pointer would never be written to).

Good point!

On the one hand, if the answer to the question is "yes" -- if there are such cases where just creating/holding a bad value is UB -- then we get into the difficult game to define what does and what does not constitute a use. Store/load, conditional branching, and pattern matching clearly do (and there is, I think, no question that these are UB for "invalid" values, but who knows?). But other cases are less clear-cut. Is it insta-UB to transmute 3u8 to bool? What about loading 3u8 from memory with a bool-pointer?

I think we made the decision that all of these are "instant" UB. The moment you have an invalid rvalue, you have UB. But then there's the little reference problem, which we should probably solve at the typeck level by allowing ExprRef to return *const T directly without a coercion.

@arielb1 I've gone back on that idea. It's just... too hard to work with, imo.

@ubsan
First, at least for nonnull/range that's how LLVM works, so we don't have much of a choice.
Also, what's the problem with that idea?

@arielb1 You've convinced me back on irc. I'm back to "creating an uninitialized rvalue is UB".

The main reason I want "no undef values ever" is because, well, see the LLVM long thread about undef. I'll like to keep this within the optimizer.

When refering to IRC please also link to relevant logs or copy them over.
Thanks.
On Jun 25, 2017 11:09 AM, "Nicole Mazzuca"<EMAIL_ADDRESS>wrote:
@arielb1 https://github.com/arielb1 You've convinced me back on irc. I'm
back to "creating an uninitialized rvalue is UB".
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nikomatsakis/rust-memory-model/issues/12#issuecomment-310889158,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AApc0uuAwED1mQPCjStkVhVVkGYJEd5Iks5sHhWzgaJpZM4JoGSH
.

arielby ubsan: what's the problem with instant UB on invalid rvalue?
[00:59:55] ubsan arielby: it doesn't actually help very much, and the standard library relies on that not being the case
[01:00:00] ubsan see: std::mem::uninitialized
[01:00:09] arielby ubsan: std::mem::uninitialized is being killed
[01:00:18] ubsan arielby: I know it's being killed
[01:00:31] ubsan but I still think that it's... a little strong
[01:00:54] ubsan I'm much more comfortable with "UB on use"
[01:01:23] arielby I'm actually less comfortable with "UB on use"
[01:01:27] ubsan where `use` is defined liberally
[01:01:31] arielby because that means you have undef values traveling through your code
[01:01:39] arielby and you are never sure what a use is or what value is undef
[01:01:50] ubsan arielby: it'd be reasonable rules
[01:02:01] ubsan like, passing to other functions, matching, using if, etc.
[01:02:19] ubsan or maybe not even passing to functions?
[01:02:23] ubsan I dunno
[01:02:35] ubsan I've been rethinking my mental model of values and objects
[01:03:10] arielby ubsan: first, is there a legitimate use case for invalid values that isn't handled by MaybeInitialized?
[01:03:37] ubsan arielby: initializing a stack thing one subobject at a time
[01:03:48] arielby ubsan: you do that with a MaybeInitialized
[01:03:55] arielby and pointers to subobjects
[01:04:03] ubsan arielby: hmm
[01:04:06] ubsan I mean, I guess?
[01:04:19] arielby let value: MaybeInitialized<MyStruct> = MaybeInitialized::uninit();
[01:04:34] arielby for i in 0..n { init(&mut value[pi(n)]); }
[01:04:45] ubsan I guess you could do that
[01:04:51] arielby I mean, if you want to use safe pointers
[01:04:59] arielby there's possibly some difficulty
[01:05:08] ubsan arielby: although I'd only want to break it at rust 2.0
[01:05:14] arielby but that's because of a different rule
[01:05:24] arielby ubsan: you mean, mem::uninitialized itself?
[01:05:28] ubsan arielby: yeah
[01:05:31] ubsan and the rules around it
[01:05:31] arielby of course
[01:05:34] arielby we'll special case it
[01:05:55] ubsan arielby: I'd rather allow people at least a release to fix their code
[01:06:05] ubsan *major release
[01:06:08] arielby I mean, GCC had 4.0 and they survived that
[01:06:16] ubsan before we go full UB
[01:06:23] ubsan arielby: I mean in Rust 2.0, not 3.0
[01:06:40] ubsan and we should *definitely* give people a ton of warning
[01:06:54] ubsan TBAA was a huge deal in the C community...
[01:06:58] arielby ubsan: btw we *already* do the UB thing
[01:07:09] ubsan arielby: do we?
[01:07:11] ubsan hmm
[01:07:11] arielby yes
[01:07:19] ubsan then yeah, uninitialized should be special cased, I guess
[01:07:22] arielby semi-inconsistently
[01:07:27] arielby (because it's UB)
[01:07:28] ubsan never mind then
[01:07:36] ubsan I wasn't clear on that
[01:07:57] arielby I once added nonnull enforcement to function pointers (it already was for data pointers) and that broke someone's code
[01:08:20] ubsan arielby: okay, never mind then lol

This is now becoming the validity invariant discussion at https://github.com/rust-lang/unsafe-code-guidelines/issues/76 and https://github.com/rust-lang/unsafe-code-guidelines/issues/77.


Changed most Dotty references to Scala 3

I just used this template and noticed that it still references Dotty in several places, so I updated those. I also modified the README slightly.
Also, I didn’t know how to test this code, so please consider it untested.

tested post-merge:
~ % sbt new scala/scala3.g8
[info] welcome to sbt 1.4.4 (AdoptOpenJDK Java 1.8.0_275)
[info] loading global plugins from /Users/tisue/.sbt/1.0/plugins
[info] set current project to tisue (in build file:/Users/tisue/)
[info] set current project to tisue (in build file:/Users/tisue/)

A template to demonstrate a minimal Scala 3 application

name [Scala 3 Project Template]: foo

Template applied in /Users/tisue/./foo
~ % cd foo
README.md  build.sbt  project/   src/
~/foo % less build.sbt
~/foo % sbt run
[info] welcome to sbt 1.4.4 (AdoptOpenJDK Java 1.8.0_275)
[info] loading global plugins from /Users/tisue/.sbt/1.0/plugins
[info] loading settings for project foo-build from plugins.sbt ...
[info] loading project definition from /Users/tisue/foo/project
[info] loading settings for project root from build.sbt ...
[info] set current project to scala3-simple (in build file:/Users/tisue/foo/)
[info] compiling 1 Scala source to /Users/tisue/foo/target/scala-3.0.0-M2/classes ...
[info] running Main$package
Hello world!
I was compiled by Scala 3. :)
[success] Total time: 3 s, completed Dec 13, 2020 6:56:17 PM

Thanks! And now I know how to test it! :)


Send route name to the front end

Context
Adds the changes proposed in #574 (which was closed until other things were merged in the mean time).
Changes proposed in this pull request

Adds a ChatRoute class in redbox/models to consolidate route names
returns 'route' in ChatResponse and in the streaming response
tests the above

Guidance to review
Have I tested enough? Am I using the appropriate streaming event
Relevant links
https://technologyprogramme.atlassian.net/browse/REDBOX-326
Things to check

[ ] I have added any new ENV vars in all deployed environments
[x] I have tested any code added or changed
[ ] I have run integration tests

My main concern with the enum approach is that the A/B test stuff proposes lots of ephemeral keyworded routes that will come and go quickly. Would the enum changing quite a lot from deploy to deploy be a problem? I think it isn't, but I thought I'd ask. To the front end it's all just strings right?

@wpfl-dbt yes it is just strings to the front end, and there is some design work to be done around how to surface the information to users. There is an idea to have some text in the future along the lines of 'this was identified as a summarisation request - was this not what you wanted? try X, Y, Z'. We'll have to make sure the design team are in the loop for the possibility of temporary routes and how to communicate these to users. (Maybe we could have keys with names like 'test-A', 'test-B' or something, or perhaps that is over complicating things). If nothing else, we could have some kind of JS switch block like:
switch (route) {
    case route_options.summary:
        msg = 'X';
        break;
    case route_options.rag:
        msg = 'Y';
        break;
    default:
        msg = 'Z';
}

where route_options is provided by an API call surfacing the enum options or sent at the start of the stream or something. The default route would allow us to handle temporary routes.
As for whether to include the Enum - I'm keen on it because we are attempting to type things reasonably strongly and I think there are some routes that we do want to persist.


Problem retrieving domain user list

Hi,
I'd like to get the list of the users of the domain using "google-api-php-client".
As SuperAdmin on the Google backend I have:

Activated the library: Admin SDK API (Cloud console)
Created a service account called<EMAIL_ADDRESS>(Cloud console)
Created the credentials for<EMAIL_ADDRESS>(Cloud console) and downloaded the json with these credentials: config_google.json
Given to the<EMAIL_ADDRESS>the domain delegation for the scopes: "https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.domain" (Admin console)

However, when executing the "listUsers" method I have the error:
{ "error": { "code": 403, "message": "Not Authorized to access this resource/api", "errors": [ { "message": "Not Authorized to access this resource/api", "domain": "global", "reason": "forbidden" } ] } }
This is the code I'm using:
`        $serviceAccountPath = base_path().'/config_google.json';
$credentials = json_decode(file_get_contents($serviceAccountPath), true);
    $this->client = new Client();
    $this->client->setApplicationName('Google Workspace Directory API');
    $this->client->setAuthConfig($credentials);
    $this->client->setScopes([
        'https://www.googleapis.com/auth/admin.directory.domain',
        'https://www.googleapis.com/auth/admin.directory.user',
        'https://www.googleapis.com/auth/admin.directory.group',
    ]);

    $service = new Directory($this->client);
    $users = $service->users->listUsers([
        'domain' => 'mydomain.com',
    ]);

`
What could be the problem? How can I solve it?
Thank you very much
Claudio

Hi all,
I've solved specifying the "sub" parameter in the request.
claudio

@claudiobat can you post the working code?


Update storage-files-introduction.md

content editing.

@frfriel : Thanks for your contribution to the Azure documentation! The author, @renashahmsft, has been notified to review your proposed change.


[Question] How to check the size of a file that's uploading and reject it if it exceeds a specifc size on a per URL basis?

Hi there!
I am trying to figure out the best way to reject overly large files on a per URL basis instead of utilizing the global config.jetty.multipartConfig values. Ideally, I'd like to reject the connection before the upload begins to avoid exhausting the connection.
For example, I have a designated link for uploading profile pictures and another for uploading profile banners where the max file size is 5 MB. But other URLs may expect 10+ mb files.
Thank you for your time and for making this amazing framework!

Hi @CorgiTaco - you can check the content length:
ctx.req().contentLength > YOUR_MAX_SIZE

Then throw a ContentTooLargeResponse :)

Would I call that in .before or .post?

And one other question too, is it possible to check the file extension of the uploading file?

Yes, UploadedFile#extension will give you that.


chore: Add missing project to pub_get_all script

Adds
Updates the pub_get_all bash script to include all current tests and projects.
Pre-launch Checklist

[x] I read the Contribute page and followed the process outlined there for submitting PRs.
[x] This update contains only one single feature or bug fix and nothing else. (If you are submitting multiple fixes, please make multiple PRs.)
[x] I read and followed the Dart Style Guide and formatted the code with dart format.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///), and made sure that the documentation follows the same style as other Serverpod documentation. I checked spelling and grammar.
[ ] I added new tests to check the change I am making.
[ ] All existing and new tests are passing.
[x] Any breaking changes are documented below.

I have read the CLA Document and I hereby sign the CLA


Rethink retry mechanism

Current Situation
Currently when the execution of a run fails, the run is marked as errored and a level of error is link with it.  The run scheduler will automatically retry to execute the same run until it reach the error level 6.
Each try is delayed a bit more. See: https://github.com/Jumpscale/ays9/blob/e7947c2a2a4702a57cca2bdc1f191aa396f5156d/JumpScale9AYS/ays/lib/RunScheduler.py#L7-L15
Problems
I see multiple problems with this design:

No way to configure this delay for each error level,
would that be per run, per AYS repository or globally.
In some situation, a AYS user can execute a blueprint and want to wait for all retries to be done before deciding if its requests has failed or not.
In this scenario, we force the use to wait for up to 46 minutes. I don't think this number is reasonable.
The only ways to know if a run is done is or to poll for the run detail, or to use the callback feature.
Both present some problems.

Poll:

This is not efficient and create a lot of "useless" request to AYS
There is not way to know if the run is going to be retried again or not

Callback:

This force the caller to block until the callback is done, which can lead to deadlock if for some reason ays stops sending callback

In case of the orchestrator, this means we block on an HTTP request, which block a connection. If case orchestrator has a lot of request, we can easily reach max number of file descriptor

There is not way to know if the run is going to be retried again or not
Each try sends a callback, caller doesn't know after how many callback it should stop blocking.

Some idea how to improve situations:

Make retry delay configurable. Per AYS repo or globablly
Allow user to specify the retry delays when executing a run ?
Allow user to specify if he wants to receive a callback for each tries, only in case of success, only X tries, specify a timeout

How about that we do in the callback data, how many retries are left, and when the next one is to be retired. We can then wait for that time and re-block in some way?

I think global configurations, in general, are the way to go. Too many configuration options get confusing and add complexity to users.
+1 for configurable

How about that we do in the callback data, how many retries are left, and when the next one is to be retired. We can then wait for that time and re-block in some way?

I like that cause then the caller has all the knowledge he needs to take decision on what to do.

It should be configurable per actor (with default values, of course) for more finegrained control over behavior.
Actor config will, of course, become more complicated, but this is an advanced feature in all cases.

No, that won't work. Because a run has many actors. Which will conflict.
So it might be better to do it per AYS repo.

Or input to the run create. It's the least invasive one and can be fine-tuned to give a lot of control over specific runs.

No, that won't work. Because a run has many actors. Which will conflict.

Currently this is already the case. The run scheduler look for the lowest error level present in a run, and wait the time of this error level. This allow to retries as fast as the lowest error level allow you.

I think it would be better if we specify the configuration during the run like this for example ays run create --retriesConfig '20,10,10,20,10,10' and make the default behavior configured using the jumpscale9.toml

We have one of two options:

configure on actor level:

Each actor defines their own retries, possibly on specific actions even. (install retries slowly, start retries immediately, update never retries - for instance)
Scheduling the run will take the nearest retry of them and schedule the errored actions for it. But this raises three issues:
- the finegrained control given to the user will not be met. It will depend on what other actors' actions are in that same run. This is undesirable because it would not be the expected behavior.
- We'll have to consider that we might have to drop items (non-retriables) from said run.
- Slower retries might retry very fast, making them fail more times than needed.

configure on run level:

You can optionally define run retries while creating it. Number of retries and their period will be in the user's complete control.
Downside:
- User has to be completely

Let's stick to configuring the delays on the run. Behavior will be more predictable that way.


[Feature Request] Request to new interactive segmentation model

Hi, thank you for developing and maintaining awesome annotation tool!
This is the feature request to add new interactive segmentation model.
Currently f-BRS seems require user many clicks to annotate and sometimes cannot annotate complex object.
This click based interactive segmentation model seems perform better than the current one (f-BRS) from the evaluation in their paper.
I used this interactive segmentation method both in CVAT and the tool in the repository, and feel that it really makes better segmentation than f-BRS. The branch is here.
I will proceed to prepare for an PR if I you think that this new interactive segmentation model is worth adding to this repository.
Thank you!

Hi @xiong-jie-y
The demo looks promising. If you believe it is better than f-BRS, do not think, just send a PR :) Especially if you already have written the code.
Thank you.


Postgres Data Types

Hi,
I noticed that DBeaver does not support the creation/edition of Postgres Data Types.   Is there any plan to support that functionality in the future?
TBH, at this point I only care for ENUMs, but I imagine that you may want to have this functionality for all data types.
During the database design, it's rather annoying to have to go back and forth with pgAdmin to do the work.   (I'm very new at Postgres, so I'm not familiar with the command lines yet.)
Describe the solution you'd like
In an ideal world, when creating the ENUM options, one should be able to add options, rename them, delete them, and very importantly, reorganizing them (because comparisons are done on a position basis)
Describe alternatives you've considered
As said, I used pgAdmin to generate the enums.  pgAdmin is very inflexible and does not let you massage the enum once created.
So, what I do is to look at the DDL produced by pgAdmin, copy it, and past it on a DBeaver SQL editor, where I drop the enum, edit it, and save it.   It's a bit cumbersome, because I have to redo the columns and the functions that use the enum, though.
Many thanks in advance and thank you for a great product!!
Alex

Thank you for idea.

Probably, connected with #72

Hello @aschoijett
I found a duplicate of your ticket at https://github.com/dbeaver/dbeaver/issues/3936 (also #72), so I will close your ticket as a duplicate.
You can subscribe and vote for the original ticket.
Thanks for the request.


Exoplayer init multiple times ?

 I would go to the issues page for that plugin and search the past issues for logs to see if it's a known issue, and if not you can submit the issue there.

@ryanheise  im using just_audio


Downloading of Rocket is not working

All in title. Can't download Rocket through link and api. Rocket Manager can't download it too. Downloading is starting but it doesn't downloading...

Apparently the build agents died because no space left :D
https://ci.rocket.foundation/

Ok, cleared sum logs, also fixed download taking too long to load.


It was determined to be a virus

avast detected idp.alexa.51 and isolated this software.  I also looked up that virus and most links I found were relating to false positives. If you're doubtful, here's a link that shows scans from several different antiviruses:
https://www.virustotal.com/gui/url/43c3f3ac0e7f42c85fc58df54516640c7bf522de39b34efb57d24d38dc989522/summary

Closing due to iTunesRichPresence no longer being maintained.


Cocoapods support

There is no official support for Cocoapods.
https://cocoapods.org/pods/leveldb-library Is a fork from https://github.com/matehat/leveldb.git.
Would it be possible to create a podspec file here and also support tvOS?

tvOS support coming anytime soon?

It seems you are wrong. On page cocoapods it says "Maintained by Google."
@cmumford Could you update pod to support leveldb 1.22?

@MoNTE48 Unfortunately this team doesn't have the bandwidth to add and maintain support for the numerous package/dependency management systems.

https://github.com/CocoaPods/Specs/commit/1a5bb2a0a68f70c798652039e07912288b65adcc
Issue can be closed!


Adding section mensuration in the menu

Is your feature request related to a problem? Please describe.
Adding section mensuration in menu.html from old.html according to the previous ui.
Screenshots

@Divyanshj The UI of the site is changed now. Please have a look here https://makesmatheasy.github.io/makesmatheasy/

Go ahead @Divyanshj
Deadline is 24/07/21


feat: Add earthly cat-gateway/event-db initial setup

Description
Added earthly docker target for building a docker image and applying all migrations and historic/test data init.
Added earthly check target to test that the docker image has been build properly and migrations have been applied.
Related Issue(s)
Closes #82

blocked by https://github.com/input-output-hk/catalyst-ci/pull/84


Updated NF1 data submodule

This pr focuses on updating the NF1 data submodule, creating a reference from the nf1_cellpainting_data repo. This is in response to issue #63. Any constructive feedback is welcome.

Thanks @jenna-tomkinson, merging now!


Change the git pre-commit actions to work on stable.

These are not being fixed, so it does not make sense to constantly take on new lints. The fmts may never be stabilized. Currently, you can not even commit, because it errors out. At least switch to lints that make it to stable when they are released.

For some reason it runs on all files not just the ones in the commit.

Makes sense


Update default branch to be main

Other request?
This is a simple change but speaks to the inclusive collaborative culture the AUDS strives to create.

Hey @alex-page,
Thanks for the request. The team's on leave this week, but we'll check it out for any hardcoded build dependencies when everyone's back.

Hey @alex-page,
Thanks for the request. The team's on leave this week, but we'll check it out for any hardcoded build dependencies when everyone's back.


modal feature missing?

Version Information:

linux 5.16.11-arch1-2
swhkd 1.1.0

Describe the bug:
sxhkd has the modal feature, e.g. (example from https://github.com/baskerville/sxhkd/blob/master/README.md )
super + o ; {e,w,m}
	{gvim,firefox,thunderbird}

swhkd doesn't seem to recognize the semicolor ;. Is this implemented yet?
Expected behavior:
Drop in replacement for sxhkd.
Actual behavior:
semicolon ; causes error.
To Reproduce:
same as above
super + o ; {e,w,m}
	{gvim,firefox,thunderbird}

Additional information:
Great project! Thank you!

Sorry but we do not support this feature yet.
We'll try to implement this feature after some refactors.
Thanks for your suggestion!

Pin this issue i guess

I'm sorry for the inconvenience we plan to implement this as soon as possible just how eden stated. I hope apart from that everything is at par in terms of quality and UX?

Devs, no need to apologize! sxhkd has been such an important component in my workflow so I am very grateful that you made swhkd available for everyone!
The modal feature discussed here is an important one, since most WM already supports one-key shortcuts, so this feature makes sxhkd unique. After swhkd adds this feature, it will definitely be more popular!
I can share some of the features that I can think can enhance the UX, probably as separate tickets so the scope of this ticket focuses on replicating what sxhkd has first.
Thanks again!

@tsankuanglee would you mind trying out the new branch where we implemented a new feature called modes, which is supposed to work similar to chords but with a greater readability and functionality.
The basic syntax of key modes:
# the default mode is `normal` mode, which is always on the bottom of the mode stack
super + m
    # commands starting with `@` are internal commands. Internal commands can be combined with normal commands with `&&`
    # @enter will push a mode into the mode stack
    @enter music && echo music > .swhkd_mode

mode music # define a mode with the `mode` statement
super + {n,p,space}
    mpc {next,prev,pause}
q
    @escape # an internal command to pop the current mode out of the mode stack
endmode # end a mode definition with `endmode`

I won't be able to test this until much later in the month. However, some initial thoughts:
I like the explicit mode design. It does make things much more clear. There are some implications though:

It seems this will break the original design goal of "drop-in replacement for sxhkd" (unless you are thinking about a config file pre-processor). I myself have no problem that the two are different, but you may need to mention the incompatibility for those who migrate.
The original sxhkd's linear design does have the benefit of complex expansion of {a,b,c} {d,e,f} that crosses modes. It's a design choice so whatever you call, I appreciate.
As opposed to @escape, could we have the flexibility to jump to any mode?
Is .swhkd_mode a necessary part of this feature? Or is it just for an external program to interact with the mode?

Thanks a lot again for this!

I won't be able to test this until much later in the month. However, some initial thoughts:
I like the explicit mode design. It does make things much more clear. There are some implications though:

It seems this will break the original design goal of "drop-in replacement for sxhkd" (unless you are thinking about a config file pre-processor). I myself have no problem that the two are different, but you may need to mention the incompatibility for those who migrate.
The original sxhkd's linear design does have the benefit of complex expansion of {a,b,c} {d,e,f} that crosses modes. It's a design choice so whatever you call, I appreciate.
As opposed to @escape, could we have the flexibility to jump to any mode?
Is .swhkd_mode a necessary part of this feature? Or is it just for an external program to interact with the mode?

Thanks a lot again for this!

Thanks for your prompt reaction

We do different from sxhkd from many aspects now. We'd like to implement more features that sxhkd doesn't have to satisfy more use cases. And we're working on documents to mention the incompatibility.
We actually choose to use the mode syntax because it's easier to implement and it's clearer in logic for me.
You can use @enter anywhere to push a mode into the mode stack and enter it. That's a convenient feature to me because you won't need to write duplicated things if you want to access a mode in different modes.
That is just an example to show that you can combine internal commands with normal commands with &&. This is useful if you want to show the current swhkd mode on your waybar or if you want to use a notification to indicate the current moe.

I understand that our implementation is not at all like the original but it's probably for the best because Edens implementation is clear and readable. It's alright to differ as long as it works.

modal feature missing?

As of https://github.com/waycrate/swhkd/pull/135 modal features are available. man 5 swhkd should help.

If I may chime in on this feature (which I think is an excellent improvement over the sxhkd system, in general); it is slightly different in that it it does not give easy one-off chords. For example, with sxhkd I do
super + e; t
 kitty

to execute terminal. I do something similar for a bunch of other commands too, often with multiple options etc.
With swhkd I would have to do
mode execute
t
 kitty && @escape

That's a fine workaround for a once-off, but becomes very frustrating to do for every chord I define.
This could be enhanced by allowing modes that do not persist (eg mode execute autoescape/nonpersist/temporary), but instead automatically pop the stack after the next keystroke.
(It would also be wonderful to be able to define a command to run when escaping up the stack in this way).
I spent many years using skhh on OSX, which has the most gorgeous way of defining and using modes and chords. It might be worth comparing

That seems like a nice improvement!
Could you open a separate issue for this suggestion? That would make it easier to track and discuss, thanks!


The update in cppo.py does not match with pseudo code in the paper

I was confused that the code implementation is a bit different from what the paper says. For example, line 309-384 in cppo.py do not match the update procedure stated in the paper. Could you update if there is any simplification here?

Thanks a lot for your support of our work and your questions. We have updated the version of our code to make it more clear. And we have some implementation tricks in our CPPO which are not reported in the paper due to the space limitation. For applying CPPO in complicated environments like MuJoCo, we find that directly using the gradient to update nu and lambda will be unstable. By the gradient of L to theta calculated in the paper, the main difference compared with classical PG is that it penalizes the trajectories with low returns. First, since the trajectory is too long to be unstable, we can estimate the return of every state (current return + value function) to determine whether to penalize it. Second, in practice, we find that the update of lambda and nu is unstable and we take a heuristic method to update. In the update of theta, we penalize the trajectories of which the returns are lower than nu, thus we take nu as a function of current trajectories’ return (we are sorry that we wrongly write it as beta in the paper, but the idea behind it is consistent, i.e., we penalize the state of which the return is lower than a bar that is determined by returns in the previous step). We hope our reply can address your question and our work is helpful for you. Also, we will appreciate it if you found a more stable method to train lambda and nu.


Captured BC7 Texture may have wrong mip data

Description
Replay in renderdoc has strange data with some bc7 textures.
Steps to reproduce

using a BC7 texture with size(560x220) and 6 mips
mip0 is fine, but higher mip has wrong data (just use SampleLevel(uv, 2) for visualization)
game window is running ok(right), but replaying in renderdoc has strong line (left)

Texture for test is attached here: seafloor.zip
Environment

RenderDoc version: 1.24 and 1.25 development
Operating System: Win 11
Graphics API: DX11

I tried debugging for more information in this way:

dump data from WrappedID3D11Device::Serialise_CreateTexture2D into dds container
mip0 has the right image, but other mips already have artifacts

I'll try later after work for more details. Any help is highly appreciated 😃

There was some code handling linearised access to block textures which wasn't properly calculating the number of rows when the mip was non-power-of-two. That's been fixed and it seems to work for me now.

This commit works and thanks a lot for quick response.


Update auto imports

Auto generated by CI

Could look something like this (run by action)

Would it be cleaner to put the imports in a separte file and import them from uix.ts?


Puppet Agent Fails Due to invalid multibyte char (US-ASCII)

Description of problem
When using this module on Debian Servers with UTF-8 locales set, errors are raised regarding characters not present in UTF-8 charset.
Expected Behavior
Puppet run finishes without errors
Current Behavior
During the puppet run, the catalog is not compiled due to an error from non-UTF-8 characters.
Info: Using configured environment 'feature_add_sensugo'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: {"message":"Server Error: Evaluation Error: Error while evaluating a Type-Name, Could not autoload puppet/type/sensu_user: /etc/puppetlabs/code/environments/feature_add_sensugo/modules/sensu/lib/puppet/type/sensu_user.rb:85: invalid multibyte char (US-ASCII) at /etc/puppetlabs/code/environments/feature_add_sensugo/modules/sensu/manifests/backend/tessen.pp:20:7 on node rtesrv5.reliant","issue_kind":"RUNTIME_ERROR","stacktrace":["Warning: The 'stacktrace' property is deprecated and will be removed in a future version of Puppet. For security reasons, stacktraces are not returned with Puppet HTTP Error responses."]}
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
Steps to Reproduce

Puppet Server on a Debian machine configured with the module and LANG=en_US.UTF-8 as the system locale.
Generate types (it will show errors regarding the chars not in UTF-8)
Execute puppet agent on a debian node.

Command used and debugging output
Master based puppet setup.
Platform and version information

Your OS: Debian Jessy 8.7
Your Ruby version: 2.1.5p273
Your version of Puppet: 4.10.12
Your version of Sensu: 5.14.1-6721
Your version of this module: v3.8.0 and v4.5.1

Anything else to add that you think will be helpful?
Possible Solution: Remove char ’ from the code.
Links:
https://github.com/sensu/sensu-puppet/blob/1b83daf0787faf9d09059adec0fb13097bedcca0/lib/puppet/type/sensu_filter.rb#L67
https://github.com/sensu/sensu-puppet/blob/1b83daf0787faf9d09059adec0fb13097bedcca0/lib/puppet/type/sensu_hook.rb#L65
https://github.com/sensu/sensu-puppet/blob/1b83daf0787faf9d09059adec0fb13097bedcca0/lib/puppet/type/sensu_user.rb#L89

The fix is simple but FYI that we don't officially support Puppet 4, only Puppet >= 5.0.0.  I think Puppet 4 is also EOL.  I'd recommend updating your Puppet install.

Thanks for the advice, we are migrating but it is a work in progress. Regardless, I did a PR with the fix. Thanks for the fast reply btw.


Include profile name in env vars used when writing to .env

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/2294
Originally created by @DouweM on 2020-08-21 17:50:59

If we don't, meltano config plugin@profile set --store=dotenv foo bar would set PLUGIN_FOO and override the value for all profiles, instead of just the targeted one.
The format could be <NAMESPACE>__<PROFILE>__<SETTING>

View 5 previous comments from the original issue on GitLab


Update 10-bootstrapping-kubernetes-workers.md

added additional flag for kubelet.service (--fail-swap-on=false)
After starting kubelet and kubelet-proxy, it would show "no resource found" when checking in the controlplane.
checking back on the worker node
systemctl status kubelet

shows that the process is stuck in restarting mode. Kubelet apparently could not be run on swap hence the addition of the flag.

will open a new one for the 2nd node


Provision SSISDB using Managed Identity - Powershell

Hello Team,
The document only states SQL Auth method to provision a SSISDB but in UI in ADF we have option to use MI as well.(system or user defined MI ).
If we try to use a devops pipeline , is it not possible to implement a MI authentication method using power shell ?
Thanks!
[Enter feedback here]

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

ID: e8473dce-d69d-625d-797a-912f3e9984ce
Version Independent ID: c00dcda3-3080-e98d-d3a4-a6cd26081304
Content: Set up an Azure-SSIS Integration Runtime with PowerShell - Azure Data Factory
Content Source: articles/data-factory/tutorial-deploy-ssis-packages-azure-powershell.md
Service: data-factory
GitHub Login: @swinarko
Microsoft Alias: sawinark

When using PowerShell to create SSIS IR that connects to SQL DB/MI via AAD Auth w/ the system/user-assigned managed identity for ADF, you need to omit the CatalogAdminCredential argument, see https://docs.microsoft.com/azure/data-factory/create-azure-ssis-integration-runtime#create-an-integration-runtime.  #please-close


v0.4.1

Codecov Report

Merging #3 (70636ce) into main (be9ac80) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main       #3      +/-   ##
==========================================
+ Coverage   95.97%   95.98%   +0.01%
==========================================
  Files          39       39
  Lines        2262     2269       +7
==========================================
+ Hits         2171     2178       +7
  Misses         91       91

Impacted Files
Coverage Δ

jwskate/jwa/__init__.py
100.00% <ø> (ø)

jwskate/jwa/encryption/__init__.py
100.00% <ø> (ø)

jwskate/jwa/key_mgmt/__init__.py
100.00% <ø> (ø)

jwskate/jwa/signature/__init__.py
100.00% <ø> (ø)

jwskate/jwk/__init__.py
100.00% <ø> (ø)

jwskate/jwt/__init__.py
100.00% <ø> (ø)

jwskate/jwe/__init__.py
100.00% <100.00%> (ø)

jwskate/jws/__init__.py
100.00% <100.00%> (ø)

jwskate/jwt/base.py
98.66% <100.00%> (+0.13%)
:arrow_up:

jwskate/jwt/signed.py
96.26% <100.00%> (ø)

... and 1 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


support neverlink in scala_library

java rules support this, but we don't.

This seems pretty straightforward to implement (just involves a little fiddling with setting up the jar lists in the provider). There might be a little incongruence with java interop until can safely use the new bazel CLs.
Do you know how to test it?

Stephen,
Wdyt about sending a PR where the only blocker is that it uses bazel from
head?
Will enable to start flushing out problems.
On Fri, 2 Jun 2017 at 21:56 Stephen Twigg<EMAIL_ADDRESS>wrote:

This seems pretty straightforward to implement (just involves a little
fiddling with setting up the jar lists in the provider). There might be a
little incongruence with java interop until can safely use the new bazel
CLs.
Do you know how to test it?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/213#issuecomment-305880860,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF9_AdrF84w8nKmSoZBmtC1AKcD2Mks5sAFrvgaJpZM4Nupc6
.

What is neverlink?

https://bazel.build/versions/master/docs/be/java.html#java_library.neverlink
Basically, when included, the jar is added to the compile path of dependents but not the runtime path or dependents (direct or transitive).
@ittaiz yes, a situation using neverlink just hasn't come up for me yet so would be aided by advice on testing it. (I suppose I could fake it by creating a neverlink target (with stub implementation) and then a similar target identical one (same interface, real implementation) that is included as a runtime_dep?)

The problem with testing neverlink is that the problem we're trying to
solve in the lead target is potential and order based on the classpath. If
the leaf will have the "correct" "linked" version first then there
shouldn't be a problem.
I have an idea which isn't very pretty but should work- have two targets
with different names implement the same interface (can be same
implementation) and assert in the test that only one of them is in the
classpath.
The downside to this test is that it doesn't demonstrate why it's a problem
but because the problem is tricky to reproduce (the order of loading the
jars) I think it's ok alongside a comment.
On Sat, 3 Jun 2017 at 0:32 Stephen Twigg<EMAIL_ADDRESS>wrote:

https://bazel.build/versions/master/docs/be/java.html#java_library.neverlink
Basically, when included, the jar is added to the compile path of
dependents but not the runtime path or dependents (direct or transitive).
@ittaiz https://github.com/ittaiz yes, a situation using neverlink just
hasn't come up for me yet so would be aided by advice on testing it. (I
suppose I could fake it by creating a neverlink target (with stub
implementation) and then a similar target identical one (same interface,
real implementation) that is included as a runtime_dep?)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/213#issuecomment-305914219,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABUIF302s3xPwW--w9lQGGG3GY5ukUVJks5sAH9YgaJpZM4Nupc6
.

Do we have any progress on this ? It'd be very useful to strip down jars of Spark jobs.

FWIW, we had the spark use case and were able to get unblocked by using deploy_env:
https://docs.bazel.build/versions/master/be/java.html#java_binary.deploy_env
https://github.com/bazelbuild/rules_scala/issues/576

Thanks for the tips. We've also succeeded in using deploy_env to strip out Spark's class.

@ittaiz Are we going to support neverlink for scala_library?

We can.
I think we haven't because no one cared enough to add it.

@ittaiz Is there someone who can help implement it? I am not at all versed with bazel code but can give it a shot if no one is available

@blorente @liucijus ?

I will look into it

Fixed by #1123

Fixed by #1123


update sdk

closing this as already included in https://github.com/honey-protocol/honey-frontend-solana/pull/274


0.15->master regression in infinite type detection

f (x::xs) = xs::x

This code (yay minimal examples) is detected as an infinite type in 0.15 but not in the editor on the special port. There, this code causes the server to send an empty response - presumably this code crashes the master branch compiler.

This code does it too
f x = x f

This one is still fine: type alias Foo = {foo : Foo}
So only some infinite types?

Maybe it has to do with type inference as opposed to just a unification bug.


Maybe a small mistake in builder.py

The definition of Conv2dReLU in builder.py.
Line 87: Maybe you wanna return the result not the conv.

Thanks!
Luckily, this method is never used.


Refactor .gitops.config.yaml

Currently the .gitops.config.yaml file looks like this:
deploymentConfig:
  # The organisation name of your deployment repo
  org: deployments
  # The repostiory name of your deployment repo
  repository: deployment-config-repo
  # The name of the application (name of the folder in `.preview-templates`)
  applicationName: app-xy

previewConfig:
  route:
    host:
      # Your router host
      # {SHA256_8CHAR_BRANCH_HASH} gets replaced by a shortened hash of your preview_id
      template: app.xy-{SHA256_8CHAR_BRANCH_HASH}.example.tld
  replace:
    # Paths that should be replaced in the `values.yaml`
    - path: image.tag
      variable: GIT_COMMIT # this is the git hash of your app repo
    - path: route.host
      variable: ROUTE_HOST # this is the resolved host.template from above

Proposed changes:

Add an apiVersion field so we can introduce breaking changes (at least required for the proposed changes)
Rename deploymentConfig to configRepository or configRepo
Drop previewConfig.route as it is OpenShift specific and not flexible
Add templating support to previewConfig.replace[].variable to make the template feature which currently lives under previewConfig.route.host.template available in a more flexible manner. Maybe we should drop previewConfig.replace[].variable as well and name it previewConfig.replace[].value with "${VAR}" support .
Rename the available SHA256_8CHAR_BRANCH_HASH variable to BRANCH_NAME_SHA_SHORT or similar - the current name is not rememberable.

+1 for the proposed changes

I would use e.g. PREVIEW_ID instead of SHA256_8CHAR_BRANCH_HASH because for create-preview you can already choose  something different from the branch as id
The previewConfig.route.host.template is currently also used as link in the PR comment. If we drop this and move the templating into the replace mechanism, we need an alternative source for that. Maybe we can just ask for the path to the final url in the chart and read it from there after the replacement (url: myapp.network.http.ingress.host)?
Maybe we should also add the possibility to replace in files other than values.yaml? This would solve #74

Calling it PREVIEW_ID would be fine for me as well. Maybe we can discuss again about more speaking preview URLs?
Regarding previewConfig.route.host we could simply drop the route part (e.g. previewConfig.host).
To add support for non Helm based deployments we could add something like this:
previewConfig:
  templateType: plain # could be changed to helm

replace:
  - path: spec.template.spec.containers[0].image
    value: registry.example.tld/org/myimage:${GIT_COMMIT}
    file: deployment.yaml # in case of helm would default to values.yaml

Another idea which came to my mind restructuring the .gitopc.config.yaml like this
apiVersion: v1
applicationName: my-cool-app
previewConfig:
  templateType: helm
  host: ${PREVIEW_ID}-preview.apps.example.tld
  # optional section
  templateSource:
    repository: https://github.com/org/repo.git # would default to `templateTarget.repository`
    path: .chart/ # would default to `.preview-templates/${applicationName}`
  templateTarget:
    repository: https://github.com/org/config-repo.git
  replace:
    - path: app.image.tag
      value: ${GIT_COMMIT}

This would open the possibility to chose where the template is taken from. So e.g. I can put the template for the preview environments to the application repository and when I create a preview the template is taken from the corresponding branch. Any thoughts?

Calling it PREVIEW_ID would be fine for me as well. Maybe we can discuss again about more speaking preview URLs?

Good point. We could use the branch name (or preview id in case of create-preview) and remove all special chars. Since we have to truncate (after 63?) chars, it is possible to have naming conflicts (e.g. my-long-branch-name-...-ending-1 + my-long-branch-name-...-ending-2 -> my-app-my-long-branch-name-...-en-preview). I guess we could replace the last e.g. 6 chars of a truncated name with its hash (my-app-my-long-branch-name-..-af46gf-preview) or something to prevent that...

Another idea which came to my mind restructuring the .gitopc.config.yaml like this

I like that idea! Regarding the support for different templating system: Why not be even more explicit and always specify the file name? While this adds 2 more lines for Helm based projects it also reduces the "magic" behind the scenes:
apiVersion: v1
applicationName: my-cool-app
previewConfig:
  host: ${PREVIEW_ID}-preview.apps.example.tld
  # optional section
  templateSource:
    repository: https://github.com/org/repo.git # would default to `templateTarget.repository`
    path: .chart/ # would default to `.preview-templates/${applicationName}`
  templateTarget:
    repository: https://github.com/org/config-repo.git
  replace:
    values.yaml:
    - path: app.image.tag
      value: ${GIT_COMMIT}
    - path: app.network.http.ingress.host
      value: ${HOST}
    Chart.yaml:
    - path: name
      value: ${PREVIEW_NAMESPACE}
    README.md: # just an idea: "Preview for branch BRANCH: HOST"
    - regex: BRANCH
      value: ${PREVIEW_ID}
    - regex: HOST
      value: ${HOST}

I like the idea of combining the branchname and hash - maybe fewer hash chars would be sufficient.
Yeah we can drop the Helm specific part. I just thought a bit about your replace proposal - first I wasn't sure if using file names as key is a good idea - but it makes it actually easy readable - and there's also almost no limitation to keys in YAML. So the replacements to the file are kept together in a nice way.
Maybe we should rename previewConfig.replace{}.path to something like yamlPath to make it more clear what kind of path that is.

Just a minor thought:
previewConfig:
  host: ${PREVIEW_ID}-preview.apps.example.tld
  templateSource:
    repository: https://github.com/org/repo.git
    path: .chart/
    branch: master # if not set defaults to feature branch
  templateTarget:
    repository: https://github.com/org/config-repo.git
    branch: main # defaults to master

Can we already agree on the target design for api version 2?

apiVersion: v1
applicationName: my-cool-app
previewConfig:
  host: ${PREVIEW_ID}-preview.apps.example.tld
  # optional section
  templateSource:
    repository: https://github.com/org/repo.git # would default to `templateTarget.repository`
    path: .chart/ # would default to `.preview-templates/${applicationName}`
    branch: master # if not set defaults to feature branch - if templateSource is missing defaults to `templateTarget.branch`
  templateTarget:
    repository: https://github.com/org/config-repo.git
    branch: main # defaults to master
  replace:
    values.yaml:
    - path: app.image.tag
      value: ${GIT_COMMIT}
    - path: app.network.http.ingress.host
      value: ${HOST}
    Chart.yaml:
    - path: name
      value: ${PREVIEW_NAMESPACE}
    README.md: # just an idea: "Preview for branch BRANCH: HOST"
    - regex: BRANCH
      value: ${PREVIEW_ID}
    - regex: HOST
      value: ${HOST}

Maybe we should rename previewConfig.replace{}.path to something like yamlPath to make it more clear what kind of path that is.
I would rather call it yamlProperty or yamlNode

Still trying to find a better name for templateTarget. Any ideas?

Regarding additional replace values (like the regex stuff for the README.md)
Those are not breaking changes, therefore could be easily added without changing the API version. I would add them later if needed.

Maybe we should rename previewConfig.replace{}.path to something like yamlPath to make it more clear what kind of path that is.

I would rather call it yamlProperty or yamlNode

Discussed with @niiku: yamPath is fine :)

Still trying to find a better name for templateTarget. Any ideas?

templateSource -> template
templateTarget -> target | previewConfig

apiVersion: v1
applicationName: my-cool-app
previewConfig:
  host: ${PREVIEW_ID}-preview.apps.example.tld
  # optional section
  template:
    repository: https://github.com/org/repo.git # would default to `templateTarget.repository`
    path: .chart/ # would default to `.preview-templates/${applicationName}`
    branch: master # if not set defaults to feature branch - if templateSource is missing defaults to `templateTarget.branch`
  target:
    repository: https://github.com/org/config-repo.git
    branch: main # defaults to master
  replace:
    values.yaml:
    - path: app.image.tag
      value: ${GIT_COMMIT}
    - path: app.network.http.ingress.host
      value: ${HOST}
    Chart.yaml:
    - path: name
      value: ${PREVIEW_NAMESPACE}

Still trying to find a better name for templateTarget. Any ideas?

templateSource -> template
templateTarget -> target | previewConfig

template and target are fine for me.
Minor thing I noticed now: the previewConfig.target.branch should default to the default branch of the repository instead of master (see also #115).
Do we also want to make the preview namespace/folder configurable? Just to uncover another magic part:
previewConfig:
  host: ${PREVIEW_ID}-preview.apps.example.tld
  namespace: ${PREVIEW_ID}-dev # defaults to ${PREVIEW_ID}-preview

For the PREVIEW_ID I'd suppose something like that to make it more readable:
# pseudo
raw_preview_id = branch or user defined preview_id in case of create-preview
sanitzed_preview_id = sanitize(raw_preview_id) # remove everything that cannot be used in namespace or folder name
preview_id = sanitzed_preview_id[:34] + sha256(raw_preview_id)[:6] # truncate preview id after 34 chars + append short hash

This would mean the PREVIEW_ID has max 40 chars -> the user can add 23 chars in the previewConfig.namespace

Regarding the default branch:
Great idea - but would imply API calls, right?
The configurable preview folder name / namespace is also a great idea.
Should me move the property to target?
Still struggling with those 63 chars, not sure what is counted in (host / path). Maybe we should try it out.

Regarding the default branch:
Great idea - but would imply API calls, right?

Not necessarily. When cloning the repo I think you should always get the default branch. Currently we explicitly checkout master after cloning.

The configurable preview folder name / namespace is also a great idea.
Should me move the property to target?

Ah, yes. Makes more sense.

Still struggling with those 63 chars, not sure what is counted in (host / path). Maybe we should try it out.

It's a restriction of the project/namespace name (https://docs.openshift.com/enterprise/3.0/architecture/core_concepts/projects_and_users.html#:~:text=63). I don't think the host url is restricted..?
updated proposal:
apiVersion: v1
applicationName: my-cool-app
previewConfig:
  host: ${PREVIEW_ID}-preview.apps.example.tld
  template:  # optional section
    repository: https://github.com/org/repo.git # would default to `target.repository`
    path: .chart/ # would default to `.preview-templates/${applicationName}`
    branch: master # if not set defaults to feature branch - if templateSource is missing defaults to `target.branch`
  target:
    repository: https://github.com/org/config-repo.git
    branch: main # defaults to repo's default branch (usually master or main)
    namespace: ${PREVIEW_ID}-dev # defaults to `${PREVIEW_ID}-preview` (PREVIEW_ID has max length TBD. Make sure not to exceed 63 chars total)
  replace:
    values.yaml:
    - path: app.image.tag
      value: ${GIT_COMMIT}
    - path: app.network.http.ingress.host
      value: ${HOST}
    Chart.yaml:
    - path: name
      value: ${PREVIEW_NAMESPACE}

Great, let's go with this!

Currently working on this on branch gitops-config-v2.
Also hacked together a little browser based converter for later: https://christiansiegel.github.io/gitopscli-config-converter/
A few small changes to the last proposal:

Remove the $ in front of variables. We don't have that in the current version either and I don't see a reason why this is needed.
Use separate organisation and repository like in the CLI. The whole internal git stuff works that way.
Use PREVIEW_HOST instead of just HOST. Similar to PREVIEW_NAMESPACE
Use GIT_HASH instead of GIT_COMMIT

:tada: This issue has been resolved in version 4.8.0 :tada:
The release is available on:

v4.8.0
GitHub release

Your semantic-release bot :package::rocket:


Fix date grouping logic

Ignore first commit, I sent a separate PR for it.

Current coverage is 88.04% (diff: 100%)

Merging #2740 into master will increase coverage by <.01%

@@             master      #2740   diff @@
==========================================
  Files           246        246
  Lines         18338      18338
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits          16144      16145     +1
+ Misses         1931       1930     -1
  Partials        263        263

Powered by Codecov. Last update 02d0a8e...68bf7f6


arch: arc: skip to raise ici int when it's already raised

before raising ici int, check whether there is already
one. if yes, skip to raise; if no, raise the ici int
Signed-off-by: Wayne Ren<EMAIL_ADDRESS>

@vonhust is there a problem you're trying to solve with that fix? Or otherwise why do we need it done that way?
I'm not saying we don't need it though - just would like to figure-out how did you come to that one :)

@vonhust is there a problem you're trying to solve with that fix? Or otherwise why do we need it done that way?
I'm not saying we don't need it though - just would like to figure-out how did you come to that one :)

It's not 100% fix of some issue, more like some kind of defensive coding. Because When I review the arc hs databook, i found in the provided code snippets, it's always reading status first and then raise an ici.
A case is that,  core A raised an ici to Core B, but Core B didn't respond it,  then Core A wants to raise an ici to Core B again, it reads the status, find there is already one, then skip to raise.

I didn't check the detailed hardware behavior on raising a IPI interrupt that is already pending, but I would expect it is 'harmless'. If indeed there is no issue raising an already pending interrupt, I don't see how this PR improves anything. Performance will go down, and as there is no 'else' to do something in case an IPI isn't acknowledged (or acknowledged with reasonable time) it doesn't make the implementation more robust, only slower.
Suggest to verify the detailed hardware behavior, if there is any risk raising an already pending interrupt.

Closing this one as it doesn't seem to provide a benefit.