RFC: Syntax to write the type of metatable for tables.

Rendered link.

I am wondering if we can find a syntactic option that will allow us to emit an error when colon gets added. As it stands this syntax is a little error-prone - muscle memory is likely to result in many places where : is added accidentally.
Strawman ideas:
@metatable { } -- possible conflict with future decoration syntax...
[metatable]: blah
metatable = { } -- probably same issue though

Re: setmetatable, a strawman alternative could include setmetatable and getmetatable that accept type arguments; while this is different from typeof, I think typeof is the exception here - you really want to limit the interaction between type grammar and expression grammar to, well, typeof. I don't know if it should be dogmatic about the name set either. So I do see an alternative where we introduce two type-level functions, setmetatable and getmetatable, both of which take type arguments.
The (possible) advantage of the latter is that getmetatable would work with strings and maybe other types in the future, so it's not limited to tables. I don't know what usecases getmetatable has OTOH though.

There's two ways I can see us dealing with this:
Be relaxed about it but still helpful by introducing a lint pass for any table type annotation where it has metatable: T. If it is intentional, you should wrap the T in parentheses to silence. This requires storing an AstTypeGroup in the AST, which we don't do because it's semantically meaningless. Still does not help when you walk into that mistake over and over again due to muscle memory, yeah.
type T = {
  -- lint warning here
  metatable: T,
  -- no lint warning here
  metatable: (T),
}

Be really strict about it by rejecting properties named metatable only in table type annotations. A possibly not minor breaking change. This makes metatable act more keywordy if used as property name, even though it is an identifier and maybe sometimes is used in real code. There's still a way around it by writing ["metatable"]: T which is consistent with escaping reserved keywords, ["and"]: T. Doing this shouldn't cost any more parsing performance as opposed to the first option, because we have to compare the identifier name anyway.
(I like this option the most, but it's probably too controversial)
I can envision the rollout plan is similar to when we replaced => with ->/: by producing warnings that this syntax will be broken and to replace it with ["metatable"]: T, which does parse today. Then we enable the new parsing logic. We can also special case the error in the parser to tell you to either use ["metatable"]: T or to drop the :.
type T = {
  -- parse error: consider using ["metatable"] or drop the colon
  metatable: T,
  -- ok, property named metatable
  ["metatable"]: T,
  -- ok, table has metatable
  metatable T,
}

On setmetatable being the syntax, there is a insignificantly small chance a breaking change could happen:
local f: setmetatable(f({}, {}))

Today, this is parsed as local f: setmetatable followed by f({}, {}). I don't see a way around this without the parser having to backtrack, so this option is a breaking change.
As for the strawman ideas, [metatable]: T is ambiguous with indexers, so that's a no go. I'm also not really a fan of either @metatable {} and metatable = {} syntax either. I'll spend some time thinking about other potential syntax. Suggestions are welcome too.
I'll add all of this into the RFC.

Today, this is parsed as local f: setmetatable followed by f({}, {}).... I don't see a way around this without the parser having to backtrack, so this option is a breaking change just like if we'd like to be strict with metatable as a property name.

This is a little problematic in general, as in principle it would block future introduction of type functions like setmetatable. It might be a good idea to preemptively change the grammar to consider all identifier+( sequences as a type function call, and error if identifier is not a supported name (currently means "is not typeof")?

Be really strict about it by rejecting properties named metatable only in table type annotations

This requires extending indexer syntax, although maybe this is not critical short term. But if we do this I'd argue for __metatable to be used as a magic property name instead.

I don't like that metatable has to be a field inside a table. Other types can have metatables so I feel like it should be defined elsewhere.
What about something like the following?
type Person = {
    ...
} with PersonImpl

It might be a good idea to preemptively change the grammar to consider all identifier+( sequences as a type function call, and error if identifier is not a supported name (currently means "is not typeof")?

I think we should do this but this should be a separate RFC. A few other possible cases: alias analysis which may need a move keyword for parameters or return types. Interface types that allows classes and tables (and maybe records) to be subtypes of interfaces. Again, details are unknown there, but they may need some keyword to come before a type annotation, and type annotations do allow parentheses...

This requires extending indexer syntax

Do you mean that the parser for {T} needs to check that a metatable has been ascribed previously? Aside from that, the rule for parsing indexers is already laid out to be exclusive with this syntax since there is no :.
if (props.empty() && !indexer && !(lexer.current().type == Lexeme::Name && lexer.lookahead().type == ':'))

I should call this out in the RFC. The way one should ascribe metatables to an array-like table is in one of three forms (where ArrayImpl is invented):

{T} & {metatable ArrayImpl<T>}
{[number]: T, metatable ArrayImpl<T>}
{metatable ArrayImpl<T>, [number]: T}

and not {T, metatable ArrayImpl<T>} or {metatable ArrayImpl<T>, T}.

(and we might do this anyway for weird table keys like $$typeof)

This is already possible, actually, { ["$$typeof"]: Something } parses today and means it has a property named $$typeof, and not an indexer. The parser special cases [<string>]: T syntax to be another way to add a property for a table. I don't really want to support $$typeof directly (unless we decide to allow $ as a identifier across the board). That's a separate RFC anyway.
This probably should be called out in records RFC too, we might want record MyRec = { ["$$typeof"]: "MyRec" } to work.

But if we do this I'd argue for __metatable to be used as a magic property name instead.

I actually like this as a compromise. I'll update the RFC to use __metatable and put the current design in alternatives.

This is already possible, actually, { ["$$typeof"]: Something } parses today and means it has a property named $$typeof, and not an indexer.

Oh! I missed this. This was the change I was referring to re: indexers, I thought we don't support this.

@BradSharp There's only two types today aside from tables that can have metatables is ClassTypeVar and string (technically all primitives can have it, but we'd rather assume only string has it).
That is, if you do end up defining a custom class type, you'd write
declare class Vec3
  x: number
  y: number
  z: number

  __metatable {
    __add: (self: Vec3, other: Vec3) -> Vec3
  }
end

And that's it, its shape is forever locked.
Classes and string's subtyping relationship is nominal, that is their shape is known, fixed, and must be mentioned by name. Tables, however, are structural. So there's not really any value to wanting to ascribe metatables for non-tables.

@alexmccord

That is, if you do end up defining a custom class type, you'd write
declare class Vec3
  x: number
  y: number
  z: number

  __metatable {
    __add: (self: Vec3, other: Vec3) -> Vec3
  }
end

I am thinking of custom types which don't necessarily have any other fields. An example of this could be a custom string class, an array, or an integer.
declare class Int
  __metatable {
    ...
  }
end

With the declare syntax this seems fine, since it's less table-centric. Is this an additional syntax that will be/is supported in addition to the one mentioned in the RFC?

I am thinking of custom types which don't necessarily have any other fields. An example of this could be a custom string class, an array, or an integer.

Right, so I guess they'd be classes. Luau already knows about metatables for classes, since we have data types like Vector3 which are classes that can add, multiply, and more.

With the declare syntax this seems fine, since it's less table-centric. Is this an additional syntax that will be/is supported in addition to the one mentioned in the RFC?

Since the declare syntax is not complete nor is it public, I think it's fair to leave it out of this RFC and leave that as future work. It also seems reasonable to expect that the syntax for metatables will be exactly the same, just within the body of classes.

But if we do this I'd argue for __metatable to be used as a magic property name instead.

I actually like this as a compromise. I'll update the RFC to use __metatable and put the current design in alternatives.

@zeux Ah, when amending the RFC to replace some metatable with __metatable, I realized there's already a metamethod that uses up this exact name and I think it's way too weird now. 😞
Essentially we have the name __metatable which is overloaded in a fairly weird way. Are we sure we want to go in this direction still?
type Vec3 = {
  x: number,
  y: number,
  z: number,
  __metatable {
    ["__metatable"]: "This metatable is locked",
    __add: (Vec3, Vec3) -> Vec3,
  }
}

Yeah that's not ideal; by and large I suppose this would be the "convenient" option for metatable syntax, but I don't actually think we need a convenient option per se.
@alexmccord can you resummarize your objections to pseudo-indexer syntax [metatable]: Type? Or maybe [__metatable]: Type is something we can agree on? :)

There's clearly a lot of opportunity to choose the very nice color of the shed here :) Let me summarize how I see the options we have on the table so far.
First, just to frame this, we're talking about this because the current table type syntax doesn't allow us to talk about metatables. The way we've structured the syntax for table types is {} inside which is a list of keys/value types or indexer specifications which is a more generic way to talk about the key/value types without specifying the exact key.
Crucially, metatable is an inherent part of the table but it's not a field. It seems somewhat important that whatever syntax we go with keeps the distinction between fields and metatable.
Let's go through all options we've discussed here and then some.
1
{ ..., metatable Foo }
{ ..., __metatable Foo }

The original proposal was to omit the colon. I'm worried that this creates a very easy to fall into trap where mistakenly inserted colon changes the meaning in a somewhat subtle fashion.
2
{ ..., metatable: Foo }
{ ..., __metatable: Foo }

We could also "bless" a specific given identifier and say that it refers to the metatable, whereas if you want an actual field you must use ["__metatable"] syntax. This also makes the distinction between metatable and fields fuzzy, and can result in mistakes in code that outputs types as well as confusion around actual __metatable property of the metatable. This also breaks backwards compat, although it's unclear how severe the breakage is.
3
{ ..., [metatable]: Foo }
{ ..., [__metatable]: Foo }

We could bless a specific identifier as part of the special indexer syntax. This breaks compatibility with programs that have types called metatable used in indexers, but this breakage feels very benign, especially if we go with __metatable. This does conflate metatable specification a little bit with indexer, but it feels a little more defensible than other options.
4
{ ..., metatable :: Foo }

We could use double-colon instead of a single-colon. This sidesteps compatibility issues and makes accidental mistakes less likely, but I'm concerned that this overloads :: with a completely different meaning and introduces it in type context.
5
setmetatable({...}, Foo)

We could use a special type function. There's some concerns around naming discussed above, and this technically breaks compatibility because of how we parse type-functions (only typeof atm) - which I think we should address separately anyway because we need to keep the space of type-functions open for future extension without concerns for compatibility.
The syntax here is a little less nice, but the benefit is that it removes any possible conflation between fields and metatables, and also matches runtime syntax (although this also may be problematic based on our experience with typeof?).
6
{ ..., @metatable Foo }

We could use a unique sigil prefix for metatable. This differentiates the metatable specification very clearly from fields, and also is generic in that we can imagine adding other @-prefixed words in the future.
The downside is that this adds a sigil (is it a downside?), but also that this may be in conflict with future decoration syntax if we want generic decorations. That said, it's also possible that this actually aligns fine with decorations, eg if I imagine table field decorations for readonly/internal/etc., then it feels like we'd use @-prefixed keyword before the field, so you could imagine something like
type Vector3 = {
x: number,
y: number,
z: number,
@readonly length: number,
@metatable Vector3MT
}

Which feels reasonable?
7
{...} @metatable(Vector3MT)

You can also imagine putting a decorator after the table type. This is also backwards compatible, also clean and unambiguous, but might create issues with other uses of decorators, eg if the next line is a function definition that has its own decorators.
There's variants of this with pseudo-keywords like with that I think also run into backward compat issues
--
These are all the defensible options I see right now. My perspective is that conflating fields with metatable doesn't feel great (invalidates 1/2), overloading indexer syntax doesn't feel great for a similar reason although it's more defensible, but I'd use it as a last resort option (invalidates 3), overloading existing :: doesn't feel generalizable and I don't love overloading existing sigils in general (invalidates 4), using setmetatable still feels reasonable to me (I'd keep 5 on the table), but my favorite option at this point is 6 even though we haven't fully designed the decorator syntax.
The downside of 6 is: if we want decorators to be fully agnostic of what they contain, like C# attributes, then it's going to be awkward to parse things like this. But I'm not actually sure C# route is the optimal one - I feel like if we design decorators, we'd specify a set of places where decorators are permitted, as well as a set of valid decorators for each place and what they contain. E.g. @inline would be okay before function but not inside a table literal, @metatable would be okay inside a table type but not elsewhere, etc.
So my options are 6, 5, 3 in that order.
Does that make sense? Any options I forgot? Thoughts?

I might be missing important context here, but is there a reason why you couldn't use built-in generic types (similar to TypeScript) for cases like this instead of adding syntax?
For example:
type PrivateSelf = {_privateProperty: string}
type MT = {__index: {Method: (self: PrivateSelf) -> ()}}
type PublicSelf = SetMetatable<PrivateSelf, MT>

SetMetatable<T, MT> seems logical, since it follows the parameter order of the setmetatable function. PascalCase matches TypeScript's convention, and lets you know that it is a built-in type.
In cases where users redefine a built-in type, a warning may be emitted when the type is re-defined, but anything in that scope would fall back to the user definition (this doesn't seem to be the current behavior for type redefinitions right now, so that should be changed).

I highly prefer setmetatable<T, MT>, just because it sets a precedent of having built-in types over introducing new syntax, and I think Luau would have a lot of advantages going in this direction, similar to TypeScript. I feel as though there are pitfalls to syntax that's been introduced so far without much forethought (see: every time I try to remember whether the elipses go before or after the vararg type / type pack)
I think there should be support for redefining built-in types within a scope; right now, if you redefine an existing type, it warns at the line you redefined the type and then sets the type to "any" in the remaining scope.
Instead, it could warn where you redefined the type and then use your redefined type in the remaining scope.
I think this would also be useful for having a ReadOnly syntax like in typescript, although this would only affect static code and not runtime code (I don't know why I would want to make something readonly in runtime though)

Putting this in draft because it might not get anywhere anytime soon. Any option that we propose are either rejected, not generalized enough, or requires another RFC.
I'm starting to think that the best option here is the attributes syntax, even if proposing that syntax for metatables requires an RFC to define what attributes are and the form they take and the story. The reason I believe this option is the best is primarily because of the fact that it is generalized and is actually consistent with the language once we define what we want out of attributes.
The reason this is generalized is because we don't unnecessarily constrain the use cases, meaning we can set and get the metatable of tables, which will be useful for the possible future of mapped types. You can't do this generically with setmetatable()/setmetatable<> without their pair, getmetatable()/getmetatable<>.
Even better is that it can also be used to ascribe metatables for declare class syntax too, although the two originally-proposed syntax would enable this possibility too. setmetatable()/setmetatable<> doesn't permit this case.

Hi guys, is there any way to declare a type with a metatable at present? I can't seem to append a type to a function without a warning from lint:
type metatbl = { [string] : any; };
type subtbl = { __index: metatbl; [string] : any; };

local function func(this: subtbl, super: metatbl): subtbl --lint warning
        return setmetatable(this, super);
end

This PR is closed as part of RFC migration; please see https://github.com/luau-lang/luau/issues/1074#issuecomment-1785578157 for context.
Additional notes: I do think we need to finish this as it represents a significant need. It should be feasible to come up with some syntax along the lines of ideas around attributes discussed above...


Modal Sometimes Does Not Appear after Multiple Displays in Safari

Displaying, hiding, and displaying the same modal multiple times will sometimes fail, leaving the modal backdrop fade in place and no modal displayed.
This has been reproduced in Safari.
Steps to reproduce:

Go to this page: http://getbootstrap.com/javascript/#modals
Click on the "Launch modal demo" button 10-20 times.
You have reproduced this error is the dialog does not appear at least once.

摸态框中内容怎么不能点击呢

移动端页面中使用bootstrap modal 创建了两个模态框，苹果手机中第二个显示是被遮罩层盖住的，为什么？怎么解决？


python310Packages.fastapi: don't run databases tests

Description of changes
Databases is incompatible with SQLAlchemy 2.0.

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

OK, I guess.  I haven't really looked into other users of .databases, but hopefully that can be done independently.

OK, I guess. I haven't really looked into other users of .databases, but hopefully that can be done independently.

Those will remain broken unless they override SQLAlchemy.

I only know of python3.pkgs.orm, python3.pkgs.ormar, and python3.pkgs.slack-sdk (and thus ntfy).
cc @jfrankenau @kamilchm @andreasfelix @fabaff @costrouc

Result of nixpkgs-review pr 220703 run on x86_64-linux 1

4 packages marked as broken and skipped:

python310Packages.ormar
python310Packages.pytest-ansible
python311Packages.ormar
python311Packages.pytest-ansible

6 packages failed to build:

parsedmarc (python310Packages.parsedmarc)
python310Packages.slowapi
python311Packages.parsedmarc
python311Packages.slowapi
python311Packages.sopel
theharvester

38 packages built:

ansible (ansible_2_14 ,python310Packages.ansible-core)
ansible-later (python310Packages.ansible-later)
ansible-lint (python310Packages.ansible-lint)
ansible_2_12
ansible_2_13
etebase-server (python310Packages.etebase-server)
kargo
khoj
ntfy
python310Packages.ansible
python310Packages.ansible-compat
python310Packages.ansible-kernel
python310Packages.ansible-runner
python310Packages.aria2p
python310Packages.dependency-injector
python310Packages.fastapi
python310Packages.fastapi-mail
python310Packages.geoip2
python310Packages.mocket
python310Packages.sopel
ttp (python310Packages.ttp)
python311Packages.ansible
python311Packages.ansible-compat
python311Packages.ansible-core
python311Packages.ansible-kernel
python311Packages.ansible-later
python311Packages.ansible-lint
python311Packages.ansible-runner
python311Packages.aria2p
python311Packages.dependency-injector
python311Packages.etebase-server
python311Packages.fastapi
python311Packages.fastapi-mail
python311Packages.geoip2
python311Packages.mocket
python311Packages.ttp
soco-cli
spotdl

Result of nixpkgs-review pr 220703 run on x86_64-linux 1

4 packages marked as broken and skipped:

python310Packages.ormar
python310Packages.pytest-ansible
python311Packages.ormar
python311Packages.pytest-ansible

4 packages failed to build:

python310Packages.slowapi
python311Packages.slowapi
python311Packages.sopel
theharvester

40 packages built:

ansible (ansible_2_14 ,python310Packages.ansible-core)
ansible-later (python310Packages.ansible-later)
ansible-lint (python310Packages.ansible-lint)
ansible_2_12
ansible_2_13
etebase-server (python310Packages.etebase-server)
kargo
khoj
ntfy
parsedmarc (python310Packages.parsedmarc)
python310Packages.ansible
python310Packages.ansible-compat
python310Packages.ansible-kernel
python310Packages.ansible-runner
python310Packages.aria2p
python310Packages.dependency-injector
python310Packages.fastapi
python310Packages.fastapi-mail
python310Packages.geoip2
python310Packages.mocket
python310Packages.sopel
ttp (python310Packages.ttp)
python311Packages.ansible
python311Packages.ansible-compat
python311Packages.ansible-core
python311Packages.ansible-kernel
python311Packages.ansible-later
python311Packages.ansible-lint
python311Packages.ansible-runner
python311Packages.aria2p
python311Packages.dependency-injector
python311Packages.etebase-server
python311Packages.fastapi
python311Packages.fastapi-mail
python311Packages.geoip2
python311Packages.mocket
python311Packages.parsedmarc
python311Packages.ttp
soco-cli
spotdl


Review meta keywords

For the time being:
<meta name="keywords" content="reana, workflow, cwl, reuse, analysis, framework, research, data, software, virtual, machines, yadage, root, repository, cern, foss, open, software, search, python, api, rest, flask, docker, singularity">

Some "reproducibility" and "preservation" would be good to add.
Some two-letter ones would be good to add.
See also GitHub topics.


JdbcApprovalStore.purgeExpiredApprovals not working

When trying to purge expired approvals with the DEFAULT_DELETE_APPROVAL_SQL sql, I received the following error:
[2018-06-20 09:20:53,876] [ERROR] [] [] [] [] [] [o.s.s.o.p.a.JdbcApprovalStore] [JdbcApprovalStore.java:177] [Error purging expired approvals] [org.springframework.jdbc.UncategorizedSQLException: PreparedStatementCallback; uncategorized SQLException for SQL [delete from oauth_approvals where userId=? and clientId=? and scope=? where expiresAt <= ?]; SQL state [99999]; error code [17041]; Missing IN or OUT parameter at index:: 2; nested exception is java.sql.SQLException: Missing IN or OUT parameter at index:: 2 	at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:90) 	at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:82) 	at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:82) 	at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:655) 	at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:876) 	at org.springframework.jdbc.core.JdbcTemplate.update(JdbcTemplate.java:937) 	at org.springframework.security.oauth2.provider.approval.JdbcApprovalStore.purgeExpiredApprovals(JdbcApprovalStore.java:167)
Version used: 2.2.0.RELEASE
Workaround is to override the default delete sql statement:
@Bean
public ApprovalStore approvalStore() {
      JdbcApprovalStore jdbcApprovalStore = new JdbcApprovalStore(datasource);
      jdbcApprovalStore.setDeleteApprovalStatment("delete from oauth_approvals");
     return jdbcApprovalStore;
}
As a side effect the revokeApprovals method will no longer work because it is using the same SQL statement.

Hi, do you have the following table in your database?
create table oauth_approvals (
	userId VARCHAR(255),
	clientId VARCHAR(255),
	scope VARCHAR(255),
	status VARCHAR(10),
	expiresAt TIMESTAMP,
	lastModifiedAt TIMESTAMP
);

Hello @haykart
Yes I have the database properly configured.

Any updates on this issue?

This is because the purge uses the delete SQL, which includes where client_id, user, scope etc but purge only sets the timestamp, as its trying to remove all expired.
Its difficult to workaround, if you want to allow purging and are happy to never use delete() then the following workaround is ok, but if you ever want to call delete() you can't use this as it will delete all the things.
        setDeleteApprovalStatment(String.format("DELETE FROM %s ", "oauth_approvals"));


[Secretary] Work Tracker

Waiting On Author

[ ] Add isolation aware support to 0.2 branch, updated on Aug 27, 2019
[ ] missing DXGI_MWA_* constants, updated on Aug 28, 2019
[ ] Add msdelta, updated on Aug 28, 2019
[ ] Adding PROC_THREAD_ATTRIBUTE_* constants, updated on Aug 28, 2019
[ ] Add audiopolicy, updated on Aug 28, 2019
[ ] Add ntddstor definitions, updated on Aug 28, 2019
[ ] Migrate wincodec APIs, updated on Aug 28, 2019
[ ] Add objidl definitions, updated on Aug 28, 2019
[ ] Migrate traffic APIs, updated on Aug 28, 2019
[ ] Migrate event APIs, updated on Aug 28, 2019
[ ] Update mmsystem header to latest SDK version, updated on Aug 28, 2019
[ ] RFC: Add Windows Hypervisor Platform APIs, updated on Sep 13, 2019
[ ] Add MessageBoxTimeoutA and MessageBoxTimeoutW, updated on Nov 11, 2019
[ ] Add bindings to DirectShow stuff, updated on Dec 28, 2019

Waiting on Review
https://docs.google.com/spreadsheets/d/1ivR2LYCDBbXBsOCdjyE18OD7EGUQYAl1q2ivV6dRWSE/edit#gid=0

Here are some bindings addition PRs that were reviewed and approved by the community, and are ready to be merged. Those PRs contain no breaking change.

#963 (based on #859 which was reviewed by retep)
#962 (reviewed by @nico-abram)
#960 (reviewed by @MaulingMonkey)
#957 (reviewed by @MaulingMonkey)
#952 (reviewed by @MaulingMonkey)
#934 (reviewed by @MaulingMonkey)
#931 (reviewed by @nico-abram)
#925 (reviewed by @roblabla)
#923 (reviewed by @roblabla)
#906 (reviewed by @roblabla)


Why use strings as labels?

Why have you opted to use strings as labels in Bevy's APIs? It seems strictly less expressive than using ZSTs for the same purpose.
struct DoThings;

App::build()
    .add_stage_after(Update, DoThings)
    .add_system_to_stage(DoThings, something.into_system())

Type checking

It's not huge, but tracking down bugs stemming from little typos is annoying

Scoping

Types can be completely private to specific modules, allowing an implementation to pop implementation details into the ECS without needing to worry about it being observable. (This is just an extension of the same principle in Rust's sound/correct APIs)

Documentation

This creates a clear location for the developer to document the purpose of the label, which can be found easily with editor definition jumps

This is a reasonable proposal. I'll need to give it some thought (and maybe some experimentation to see how it affects ergonomics). But the points you make are all valid and I don't think it would cause any "usability regressions".

Just my 2c, making a const str then using that would solve your type checking & documentation points, and possibly also scoping but I haven't thought about it too much.

This is similar to specs using strings to specify relative execution order between systems; Legion's way of avoiding doing that were stages (which is think is not the best way of handling this at all, but that's a topic for another time), similar to those used in Bevy now.
The way I approached this in yaks is similar to that of specs, but doesn't rely on strings - instead, the user provides the type they are going to use as handles to diffirentiate systems; it can still be strings, but it can also be a user-defined enum, or anything else that is Sized + Eq + Hash + Debug. The handles are discarded on build (implying all systems and any dependencies between them have been defined) and an opaque usize newtype is used internally from there. Moreover, a couple of API tricks allow the compiler to infer a default dummy type if the user never specifies a handle (implying that no systems have execution order dependencies), so the API is not polluted by type signatures that do something the user doesn't need.
It might be possible to use the same tricks here, with effectively no API change from the perspective of a user - other than providing them with the option to use something other than strings to differentiate between stages.

There are some problems with serializing type IDs over time / across crates, see #32.
I think the const str approach is alright, those actually exist for the default stages. It's simple and straightforward to understand, and the user doesn't have to deal with wacky reflection issues / generics, which can be a big barrier for inexperienced rust users. Imo a good compromise would be strings + documentation of the "use a const string" best practice.

I'd probably consider the scoping the most valuable part of this. Allowing the reader to understand a system locally using the privacy of the types could enable better abstractions, by providing guarantees about the Bevy's state within the private stages.
More API considerations would need to be made to get the most out of this kind of privacy, I suppose I'm saying it's a trade-off, and types-as-ids have interesting properties for developers

Lots of good conversation here. Something that I haven't called out yet: stages must have human readable string names for the (eventual) editor schedule visualization tools. We could still have that with typed stages, but we would need them to implement a trait that returns a name.

Maybe you could just allow anything that's Sized + Eq + Hash + Display. That way you cover the need to be able to see it in an editor, etc. and you allow for the privacy gains that @Plecra brings up if you use ZSTs.

What about a combined approach, type ID + the hash? This allows using ZSTs as well as sized types (which can also be module-local), allowing scoping and things like strings. Name-providing trait would still be necessary, but possibly can be blanket implemented on many of the applicable types.
(Side note: the Debug bound from my previous post is actually a fortunate implementation detail - that's how dummy handles are differentiated from proper handles by the compiler. The name-providing trait would fill this role perfectly.)

There was some detailed discussion and analysis on this in #1021 starting here.
@cart's tentative conclusion was "any key + type constraints + derives" seems to be the best solution, but this is worth considering a bit further I think.
In addition, we're running into a virtually identical issue with system labels, relevant to #1144. We will probably want to mirror the solution we settle on to system labels as well.

There was some detailed discussion and analysis on this in #1021 starting here.
@cart's tentative conclusion was "any key + type constraints + derives" seems to be the best solution, but this is worth considering a bit further I think.
In addition, we're running into a virtually identical issue with system labels, relevant to #1144. We will probably want to mirror the solution we settle on to system labels as well.

I implemented a version of this here: https://github.com/TheRawMeatball/bevy/tree/zst-labels

I implemented a version of this here: https://github.com/TheRawMeatball/bevy/tree/zst-labels

In the interest of having options conscisely listed in one place, here's an example (and implementation driving it) of that "any key + type constraints + derives" pattern (which I've been referring to as "heterogeneous key trick"). Here is the accompanying message with some explanation.

In the interest of having options conscisely listed in one place, here's an example (and implementation driving it) of that "any key + type constraints + derives" pattern (which I've been referring to as "heterogeneous key trick"). Here is the accompanying message with some explanation.

Fixed in 0.5.


[CLOSED] Extract AaibReportServiceRegistry.

 Issue by kalleth
Monday 14 July 2014 at 15:39 GMT
Originally opened as https://github.com/alphagov/specialist-publisher/pull/171

This is similar to the work performed on CmaCases by @evilstreak. It's also going to make it easier for us to layer different validations on an AaibReport depending on its context of creation.

kalleth included the following code: https://github.com/alphagov/specialist-publisher/pull/171/commits

 Comment by kalleth
Monday 14 July 2014 at 15:47 GMT

I should have looked at the open pull requests. :(


Newbie - Create BREAD succeed but  when BROWSE BREAD give error This action is unauthorized.

Laravel Version: 5.5.14
Voyager Version: 1.0.5
PHP Version: 7
Database Driver & Version:

Description:
Error when click browse in tools->database menu voyager
error : Symfony \ Component \ HttpKernel \ Exception \ AccessDeniedHttpException
This action is unauthorized.
Steps To Reproduce:

create new table
Add Bread to this table
submit
click Browse BREAD

error : Symfony \ Component \ HttpKernel \ Exception \ AccessDeniedHttpException
This action is unauthorized.
Please help me solve this issue.
Thanks & Regards,
Dian

Hi Dean,
have you tried adding on roles permissions to new bread?

Hi Bedoz,
You right! I forget to add roles for admin. Thanks a lot!
Regards,
Dian

i added and. it throws same error


Update Warface

Game Title
Warface
Status of the Anti-Cheat
😥 Broken
Tinkering Steps
The website indicates that Warface uses EAC which is wrong since 2017. In 2017, my.com bought the EU and NA versions and switched to MRAC (MailRuAntiCheat).
It's the same for Warface Clutch (historical EU/NA), do you need another ticket?
https://pc.wfclutch.com/en/anticheat
Proof of Mention
https://ru.warface.com/anticheat

to fix your trouble check this fix, i see it in another issue,
https://app.mediafire.com/9mrkd33xulszl
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble check this fix, i see it in another issue,
https://app.mediafire.com/9mrkd33xulszl
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble check this fix, i see it in another issue,
https://app.mediafire.com/9mrkd33xulszl
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

Download
https://www.mediafire.com/file/5t7dozm7sptcuqj/fix.zip/file
password: changeme
In the installer menu, select "gcc."


release depdb v5

Motivation

Making this available more generally.  I think there's more work that could be done to make things smaller, but that requires even more work and this is a useful stopping point.
Test plan

See included automated tests.
This will require some internal Stripe changes for the Sorbet bump, and I will not merge until I'm ready to make those changes.

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_OhdXABWWLOQdMY
→ https://go/builds/bui_OhdXeuWR13rhJV
→ https://go/builds/bui_OhdXeFhnLdtt4T


Add CAA support. Fixes #35

@ross Please activate the checks. I have tested the change against the real GCore API and it works for me.

@ross Please activate the checks. I have tested the change against the real GCore API and it works for me.

Thanks


opengl: use requiredKernelConfig

Description of changes
Expectation: When building a kernel using manualConfig, OpenGL can be built when the option IA32_EMULATION is yes.
What actually happens: OpenGL insists that IA32_EMULATION is no with an error message Option driSupport32Bit requires a kernel that supports 32bit emulation.
Description of the PR: Update the OpenGL package to use requiredKernelConfig to check 32bit emulation support. Most packages, e.g. zram and systemd use this (seemingly) newer approach, and I imagine that OpenGL should be updated accordingly.
Related links: Discussion previously on a Russian Linux forum: NixOS: dri 32 бит на своем ядре
Things I haven't checked:

if there is any problem with other platforms than Linux
if this conflicts with some other build process in which the kernel is not built (i.e., is kernelConfig always available)

Note: pkgs.stdenv.isx86_64 check is redundant when checking for the IA32_EMULATION option, as the option depends on CONFIG_X86_64 being true.
Also, please do squash the commits for me if you end up merging.
Things done

Built on platform(s)

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

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[x] (Package updates) Added a release notes entry if the change is major or breaking
[x] (Module updates) Added a release notes entry if the change is significant
[x] (Module addition) Added a release notes entry if adding a new NixOS module
[x] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

if there is any problem with other platforms than Linux

NixOS only supports the Linux kernel, so no need to check for anything else.
I wonder what it does on other architectures like aarch64, which is supported.
But still, that option probably never intended to support anything other than x86_64.

if this conflicts with some other build process in which the kernel is not built (i.e., is kernelConfig always available)

Good question: I looked at the code and while requiredKernelConfig is always defined lib.kernelConfig is not available in a container (config.boot.isCOntainer). However we don't have to worry because about that because the checks are also skipped in that case.

Gotcha, in that case, is there anything else to do here? That is, while I'm glad that this change seems to be directed upstream thus fixing my problem, it does leave me wondering whether the whole kernel.features.ia32Emulation construct is redundant. I'd guess no (and I think you know for better), which leaves me thinking there might exist a reason why the requiredKernelConfig was not introduced here in the first place.

Gotcha, in that case, is there anything else to do here?

No, looks good to me. I just want to test it properly

leaves me thinking there might exist a reason why the requiredKernelConfig was not introduced here in the first place.

The kernel is not my area of expertice, but I think kernel.features is a mechanism to toggle some predefined sets of kernel build options (see pkgs/os-specific/linux/kernel/common-config.nix) and signal that said options are on/off (via a passthru) to NixOS modules. Kernels built with manualConfig lacks features and that's the reason why NixOS reported incorrectly that you lacked x86 emulation.
You can see some of these features in pkgs/os-specific/linux/kernel/generic.nix, however outside of netfilterRPFilter they are all unused. My guess is that this mechanism (the signalling part) is obsolete and should be removed since requiredKernelConfig can handle both common/manual config.
By the way this isn't the first time this happened: 534998e005c2bc7d24edb237052151e38e1946eb.

So, I managed to test this change with this configuration:
{ pkgs, lib, ... }:

{
  fileSystems."/".label = "root";
  boot.loader.grub.enable = false;

  hardware.opengl.enable = true;
  hardware.opengl.driSupport = true;
  hardware.opengl.driSupport32Bit = true;

  boot.kernelPackages = pkgs.linuxPackagesFor
    (pkgs.linuxKernel.manualConfig
      { inherit (pkgs) stdenv lib;
        inherit (pkgs.linuxPackages_latest.kernel) src version;
        configfile = /home/rnhmjoj/config;
        allowImportFromDerivation = true;
      });
}

It works in the sense that you get the error if IA32_EMULATION is off and no error otherwise.
However there are several catches:

requiredKernelConfig ignores any assertio if the kernel has the features attribute:
# nixpkgs kernels are assumed to have all required features
assertions = if config.boot.kernelPackages.kernel ? features then [] else ...

So, if you do something like this:
  hardware.opengl.driSupport32Bit = true;
  boot.kernelPatches = lib.singleton
    { name = "no-32bit-emulation";
      patch = null;
      extraConfig = "IA32_EMULATION n";
    };

you wont get the error.

requiredKernelConfig works by inspecting the attribute kernel.config, which
is only generated if you set allowImportFromDerivation = true. If you don't
do this you won't get error.

The error is pretty terrible compared to the current one:
Failed assertions:
- CONFIG_IA32_EMULATION is not yes!

There's currently no way to provide a message to explain what is the source
of the error and why that is a problem.
We could avoid this by manually writing the assertion (using kernel.config.isYes),
but I'd rather fix this in general. An easy way would be to define a new function
(name to be defined) like
requiredKernelConfig = [
   (config.lib.kernelConfig.isYesForReason
     { option = "IA32_EMULATION";
       reason = "Option hardware.opengl.driSupport32Bit requires a kernel that supports 32bit emulation";
     })
];

Thanks for the testing @rnhmjoj. You hit some deficiencies I found when building a minimal custom kernel. Long story short, it's easy to miss required features as few packages know their kernel requirements, and while there exists a range of options how to apply kernel configuration options, the ordering when such changes are applied and become visible is confusing. At the current state of affairs, builds which use a custom kernel could be accidentally broken (with your patch example being, I think, a perfectly reasonable source of configuration conflict, and which may quite a lot e.g. on nixos-mobile configurations).
Few comments on your points, given my short experience with kernel configuration:

The features option seems confusing, because it seems to introduce extra configuration into the kernel which is not derivable from the applied NixOS packages. That is, I think in a perfect world each of the NixOS packages know what kernel options are required, and these requirements cascade into feature sets automatically, thus avoiding the need for the features to exist. Further, given the existence of kernelPatches, there seems to be a way to apply arbitrary kernel configuration for those who do need it. Though, changing features is much beyond this change, but I will open a separate issue about this once I find the time, as I ended up finding a lot of implicit kernel configuration requirements hence think there's room for improvement.

Aside what I said above, I don't think a custom kernel can be compiled without allowImportFromDerivation = true, thus this could be considered fine. Why is this required, I don't know.

I agree this would be helpful, but even more helpful would be to have a flag with manualConfig to apply the required changes automatically. Nevertheless, it'd be nice to know the source package which produced the error, because when you get 30 of these, it'd be nice to know which package caused the most requirements. But also, have an optional comment field explaining why something must be the way it is. E.g., for zram to work it must be a module (instead of a yes), because modularization allows the parameters to be re-set during boot. Similar situations exist for the opposite case. I think the reasoning for these cases would be great to come in the source code, and not only as wiki page knowledge at Gentoo's.

So, aside of the style change requested above, should all the three set aside for now? I can open separate issues for each, referencing this PR, and maybe people with more insight into the implementation can comment on them.

I agree, the features attribute shouldn't exist, ideally. The problem is that I don't think it's possible to generate the config attrset for the standard NixOS kernel without doing an IFD, which regarded as a bad thing.

I see. I think it's needed, again, because the config attset is generated by parsing the kernel config file.
To do this this you need IFD: among other thing, this is not allowed in the restricted evaluation mode used by hydra, the NixOS build farm, so you wouldn't be able to build and distribute the kernel.

Uhm, I would insist on improving the error message. It's true that this PR fixes an hard failure when using a manualConfig kernel, but it degrades the experience for users of the normal kernels: it's replacing the current error message with a very abstruse one.

Updating on this as I'm ran into it again. Seemingly, the error message is blocking this PR.
The printing happens here: https://github.com/NixOS/nixpkgs/blob/9477fa1e44c16804b8c1743d25264f9e3b26c219/nixos/modules/system/activation/top-level.nix#L114
The pattern matching is here: https://github.com/NixOS/nixpkgs/blob/75025ad5e1c991f13c47dd283d69ae852b38e2a2/pkgs/os-specific/linux/kernel/manual-config.nix#L64
The implementation are here: https://github.com/NixOS/nixpkgs/blob/9477fa1e44c16804b8c1743d25264f9e3b26c219/nixos/modules/system/boot/kernel.nix#L297
I suggest to extend isYes with an optional argument for finer description.
 isYes = option (optional reason): {
            assertion = config: config.isYes option;
            message = "CONFIG_${option} is not yes!" ++ reason ? " ${reason}" : "";
            configLine = "CONFIG_${option}=y";
};

I don't know much about Nix standard library so no idea how to write this in a good manner, but you get the idea. @rnhmjoj do you think this is a good abstraction to extend? I think anything else is the wrong place to implement this change. Allowing other assertions to also include more data seems like useful outside of this PR.

I have moved on to use different kind of kernel configuration, i.e., the one in which I supply kernelPatches: https://github.com/jhvst/nix-config/blob/0bbeb07fff704f711abfea15dd49288242bc76fc/hosts/muro/default.nix#L64
Reason for this is that manual kernel configuration caused more regression that they did good.
For this reason, this PR is hugely stale now, for which I am closing this issue.


Unifiy Nomenclature for Zone / Domain References

At some places, we call Zones "Zone(s)", at other places we call it "Domain(s)". We should unify this to "Zone(s)"

@Metrax agreed. I wasn't sure if I got all of the places yet or not but I wasn't very thorough on my efforts during the change. I do want to unify on the appropriate nomenclature of zone though instead of the slang domain.

This has been completed by PR 1441.


Error: Cannot find module '@babel/runtime/helpers/interopRequireDefault'

Upgrading from 0.1.5 to 0.2.0 causes the above error to be generated when running in a server environment which does not use babel.
Error dump:
Error: Cannot find module '@babel/runtime/helpers/interopRequireDefault'
Require stack:
- /project/node_modules/graphql-passport/lib/index.js
- /project/server/authentication.js
- /project/index.js
    at Object.<anonymous> (/project/node_modules/graphql-passport/lib/index.js:3:30)
    at Generator.next (<anonymous>)
    at Object.<anonymous> (/project/server/authentication.js:1)
    at Generator.next (<anonymous>) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/project/node_modules/graphql-passport/lib/index.js',
    '/project/server/authentication.js',
    '/project/index.js'
  ]
}

That is, from where my server code is attempting to set up passport auth using a GraphQLLocalStrategy object, the node module lib file fails. Looking at the source for index.js:
"use strict";

var _interopRequireDefault = require("@babel/runtime/helpers/interopRequireDefault");

Object.defineProperty(exports, "__esModule", {
  value: true
});
Object.defineProperty(exports, "buildContext", {
  enumerable: true,
  get: function get() {
    return _buildContext["default"];
  }
});
Object.defineProperty(exports, "GraphQLLocalStrategy", {
  enumerable: true,
  get: function get() {
    return _GraphQLLocalStrategy["default"];
  }
});

var _buildContext = _interopRequireDefault(require("./buildContext"));

var _GraphQLLocalStrategy = _interopRequireDefault(require("./GraphQLLocalStrategy"));

Clearly, this is depending on babel for doing things.
My server environment isn't currently using babel, and I'd rather not go to the trouble of setting up babel just for this strategy. Downgrading 0.1.5 seems to work as expected for now, but I'd like to ensure I have bug fixes and new features as they become available.
Is babel, going forward, a dependency? If so, the readme and package.json should probably be updated to reflect that.
(I cannot, of course, rule out that I'm doing something weird on my end which caused this, but, again, no babel in the server environment. About the only thing I can think of which might be causing this would be esm.)
Method to reproduce:
In a fresh project:
mkdir test && cd test
yarn init --yes
yarn add graphql-passport

No other dependencies, the generated node_modules/graphql-passport/lib/index.js file has the babel dependency.

Sorry for the late reply and thanks for this issue. Babel shouldn't be a requirement. I'll have a look into this.

I released a new version 0.2.1. I hope this fixes your problems


Test documentation update

Codecov Report

Merging #14 (f0bc5f6) into master (cd6eedb) will increase coverage by 21.89%.
The diff coverage is 86.12%.

@@             Coverage Diff             @@
##           master      #14       +/-   ##
===========================================
+ Coverage   67.97%   89.87%   +21.89%
===========================================
  Files          32       38        +6
  Lines        3488     3960      +472
===========================================
+ Hits         2371     3559     +1188
+ Misses       1117      401      -716

Impacted Files
Coverage Δ

bundle/jwtbundle/source.c
57.89% <0.00%> (ø)

internal/cryptoutil/keys.c
92.59% <ø> (ø)

internal/x509util/certpool.c
93.05% <ø> (ø)

spiffetls/tlsconfig/authorizer.c
100.00% <ø> (ø)

utils/util.c
96.00% <ø> (ø)

workload/backoff.c
81.25% <ø> (ø)

workload/jwtwatcher.c
77.11% <10.00%> (ø)

workload/watcher.c
77.11% <18.18%> (ø)

spiffetls/peerid.c
41.66% <41.66%> (ø)

svid/jwtsvid/parse.c
82.48% <44.89%> (ø)

... and 52 more

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 8ac3303...f0bc5f6. Read the comment docs.


How to get the ground truth of history frames?

Good job! I am wondering how do you get the ground truth of history frames for nuscenes dataset?

We transform history 3D ground truth to current coordinate system here

Got it! Tnanks for your quick reply.


Fix tornado, anti, :buyitem, fpslocker, van, :slippery, convert deprecated/legacy items

Fix :BuyItem being broken due to legacy setting and a typo
Fixed anti cheat misdetecting if a player has a lag spike in which rendering doesn't happen for over minute. Now it is changed to 1.5 minutes. (A single frame should never take 1.5 minutes, if this is too low then it can be changed to 2.5 minutes/150 seconds)
coroutine.wrap 2 task.spawn (Fixes a part of tornado code not working)
.Velocity to .AssemblyLinearVelocity
Hat to Accessory
tick() to os.clock() or os.time
Removed ManualWeld studio joint artifacts generated by a weird Roblox feature from Van.rbxmx
Cleaned up some code
Fix :slippery & :unslippery

I've tested everything and it seems to work

seems to. hmmm

Actually don't merge this yet I'll remove the security capabilities things from the rbxmx

Ok now they are removed

Ah great


linux-kernel-cataloger produces thousands of version-less components.

What happened:
Scanning a disk image (mounted as a filesystem) before the linux-kernel-cataloger was added returned around 600 components. After the addition of the cataloger, scans returned around 7000 components, many of which have no versions (filesize has gone from 1MB to 37 MB). A subsequent CVE scan has doubled the amount of CVEs identified, and while I have not been able to triage them, I suspect nearly all the new CVEs are false positives.
I am not very conversant on the topic of kernel modules and did not quite follow the intent of the PR which added this functionality; it looks like the examples in the PR thread intended to use these files on disk to tie back to an actual kernel or package at a specific version. That most definitely is not happening in our case. Here is an example snippet from the resulting SBOM (syft-json format):
  {
   "id": "a1629328ee60a1d1",
   "name": "104_quad_8",
   "version": "",
   "type": "linux-kernel-module",
   "foundBy": "linux-kernel-cataloger",
   "locations": [
    {
     "path": "usr/lib/modules/5.19.0-40-generic/kernel/drivers/counter/104-quad-8.ko",
     "annotations": {
      "evidence": "primary"
     }
    }
   ],
   "licenses": [
    "GPL v2"
   ],
   "language": "",
   "cpes": [
    "cpe:2.3:a:104-quad-8:104-quad-8:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:104-quad-8:104_quad_8:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:104_quad_8:104-quad-8:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:104_quad_8:104_quad_8:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:104-quad:104-quad-8:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:104-quad:104_quad_8:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:104_quad:104-quad-8:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:104_quad:104_quad_8:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:104:104-quad-8:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:104:104_quad_8:*:*:*:*:*:*:*:*"
   ],
   "purl": "pkg:generic/104_quad_8",
   "metadataType": "LinuxKernelModuleMetadata",
   "metadata": {
    "name": "104_quad_8",
    "sourceVersion": "55C62F4A5D1B2412C1B85C7",
    "path": "usr/lib/modules/5.19.0-40-generic/kernel/drivers/counter/104-quad-8.ko",
    "description": "ACCES 104-QUAD-8 driver",
    "author": "William Breathitt Gray<EMAIL_ADDRESS>    "license": "GPL v2",
    "kernelVersion": "5.19.0-40-generic",
    "versionMagic": "5.19.0-40-generic SMP preempt mod_unload modversions ",
    "parameters": {
     "base": {
      "description": "ACCES 104-QUAD-8 base addresses"
     },
     "irq": {
      "description": "ACCES 104-QUAD-8 interrupt line numbers"
     }
    }
   }
  },
  {
   "id": "2a0e0f4387b2adcd",
   "name": "3c509",
   "version": "",
   "type": "linux-kernel-module",
   "foundBy": "linux-kernel-cataloger",
   "locations": [
    {
     "path": "usr/lib/modules/5.19.0-40-generic/kernel/drivers/net/ethernet/3com/3c509.ko",
     "annotations": {
      "evidence": "primary"
     }
    }
   ],
   "licenses": [
    "GPL"
   ],
   "language": "",
   "cpes": [
    "cpe:2.3:a:3c509:3c509:*:*:*:*:*:*:*:*"
   ],
   "purl": "pkg:generic/3c509",
   "metadataType": "LinuxKernelModuleMetadata",
   "metadata": {
    "name": "3c509",
    "sourceVersion": "D05BAE6130B1D178C163B12",
    "path": "usr/lib/modules/5.19.0-40-generic/kernel/drivers/net/ethernet/3com/3c509.ko",
    "description": "3Com Etherlink III (3c509, 3c509B, 3c529, 3c579) ethernet driver",
    "license": "GPL",
    "kernelVersion": "5.19.0-40-generic",
    "versionMagic": "5.19.0-40-generic SMP preempt mod_unload modversions ",
    "parameters": {
     "debug": {
      "description": "debug level (0-6)"
     },
     "irq": {
      "description": "IRQ number(s) (assigned)"
     },
     "max_interrupt_work": {
      "description": "maximum events handled per interrupt"
     },
     "nopnp": {
      "description": "disable ISA PnP support (0-1)"
     }
    }
   }
  },
  {
   "id": "b774a8dbcc7b639a",
   "name": "3c574_cs",
   "version": "",
   "type": "linux-kernel-module",
   "foundBy": "linux-kernel-cataloger",
   "locations": [
    {
     "path": "usr/lib/modules/5.19.0-40-generic/kernel/drivers/net/ethernet/3com/3c574_cs.ko",
     "annotations": {
      "evidence": "primary"
     }
    }
   ],
   "licenses": [
    "GPL"
   ],
   "language": "",
   "cpes": [
    "cpe:2.3:a:3c574-cs:3c574-cs:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:3c574-cs:3c574_cs:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:3c574_cs:3c574-cs:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:3c574_cs:3c574_cs:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:3c574:3c574-cs:*:*:*:*:*:*:*:*",
    "cpe:2.3:a:3c574:3c574_cs:*:*:*:*:*:*:*:*"
   ],
   "purl": "pkg:generic/3c574_cs",
   "metadataType": "LinuxKernelModuleMetadata",
   "metadata": {
    "name": "3c574_cs",
    "sourceVersion": "3531B1EFEF90AB882DFA03A",
    "path": "usr/lib/modules/5.19.0-40-generic/kernel/drivers/net/ethernet/3com/3c574_cs.ko",
    "description": "3Com 3c574 series PCMCIA ethernet driver",
    "author": "David Hinds<EMAIL_ADDRESS>    "license": "GPL",
    "kernelVersion": "5.19.0-40-generic",
    "versionMagic": "5.19.0-40-generic SMP preempt mod_unload modversions ",
    "parameters": {
     "auto_polarity": {
      "type": "int"
     },
     "full_duplex": {
      "type": "int"
     },
     "max_interrupt_work": {
      "type": "int"
     }
    }
   }
  },

What you expected to happen:
Output to be limited to versioned packages that are likely to match a distribution CPE.
Steps to reproduce the issue:
Scan an ubuntu filesystem.
Anything else we need to know?:
Environment:

Output of syft version:
syft 0.79.0

OS (e.g: cat /etc/os-release or similar):
Ubuntu 22.04.2 LTS

Thanks for the ping back in Slack. I have added repro steps here (this works for me on an M1 mac -- if you're not on an M1, the --platform is probably unnecessary):
open a docker container w/ necessary packages for image mounting:
docker run -it --privileged --platform linux/amd64 bosh/os-image-stemcell-builder /bin/bash
Inside that docker container, run the following:
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh > install.sh \
    && (echo "a6dfabcd60ec8b09a8269d5efda8c797ad9657567cd723306f5cfc3fcb07b79b  install.sh" | sha256sum --check --status  \
    || (echo "Checksum failed! Please review https://raw.githubusercontent.com/anchore/syft/main/install.sh, ensure it is still safe, and update the checksum" && exit 1)) \
    && chmod u+x ./install.sh && (cat ./install.sh | sh -s -- -b /usr/local/bin) && rm ./install.sh

function permit_device_control() {
  local devices_mount_info=$(cat /proc/self/cgroup | grep devices)

  local devices_subsytems=$(echo $devices_mount_info | cut -d: -f2)
  local devices_subdir=$(echo $devices_mount_info | cut -d: -f3)

  cgroup_dir=/mnt/tmp-todo-devices-cgroup

  if [ ! -e ${cgroup_dir} ]; then
    # mount our container's devices subsystem somewhere
    mkdir ${cgroup_dir}
  fi

  if ! mountpoint -q ${cgroup_dir}; then
    mount -t cgroup -o $devices_subsytems none ${cgroup_dir}
  fi

  # permit our cgroup to do everything with all devices
  # ignore failure in case something has already done this; echo appears to
  # return EINVAL, possibly because devices this affects are already in use
  echo a > ${cgroup_dir}${devices_subdir}/devices.allow || true
}

permit_device_control

for i in $(seq 0 64); do
  if ! mknod -m 0660 /dev/loop$i b 7 $i; then
    break
  fi
done

mkdir -p work

pushd work
git clone https://github.com/cloudfoundry/bosh-linux-stemcell-builder.git
chown -R ubuntu:ubuntu bosh-linux-stemcell-builder
chown -R ubuntu:ubuntu /mnt
####
wget https://storage.googleapis.com/bosh-core-stemcells/1.108/bosh-stemcell-1.108-google-kvm-ubuntu-jammy-go_agent.tgz

helpers_path="./bosh-linux-stemcell-builder/scripts/repack-helpers"
extracted_image_path=$("${helpers_path}/extract-stemcell.sh" "bosh-stemcell-1.108-google-kvm-ubuntu-jammy-go_agent.tgz" | $helpers_path/extract-image.sh)
mounted_image_path=$("${helpers_path}/mount-image.sh" <<< $extracted_image_path)
syft -q "dir:${mounted_image_path}"
popd


Update promote message linkage for Artifactory 4

Previous linkage would 404-no-soup-for-you with the newer version of Artifactory.
{
  "errors" : [ {
    "status" : 404,
    "message" : "Not Found"
  } ]
}

👍

👍

👍


Visible popup disappears when zoom changes many times quickly

A bit weird but easy to reproduce. Open a popup and make a zoom in and zoom out quickly using the mouse wheel.
Each time the zoom changed two animation are applied: an "out" animation to hide it and an "in" animation to show it again on the new zoom level.
It seems when zoom changes quickly events are applied in bad order making the popup to disappear.

Is this fixed?

No, I report it when working on #122 and #713.

There has been no activity on this issue for several months and that's why we are closing it (automatically). If you think this still needs to be addressed please reopen it. The good news is that we are now working on the next version of CARTO.js, stay tuned.


🎉 Add Back Button to Contact and Login Pages 🚀

Resolve #428
🎉 Add Back Button to Contact and Login Pages 🚀
Description
Hello @anuragverma108  👋
This pull request introduces a Back Button feature to both the Contact and Login pages, enhancing user navigation and improving the overall user experience. 🌟
🔍 Changes Made:

Contact Page: Added a back button that allows users to return to the previous page seamlessly. 🔙
Login Page: Implemented a similar back button for easy navigation to the previous screen. 🔙

📸 Screenshots Of Before And After

📌 Benefits:

Improved Usability: Users can easily navigate back, making the application more user-friendly. 🙌
Consistency: Aligns with the design principles of our platform.

Please review the changes and let me know if you have any feedback! Your insights are always appreciated! 💬
Thank you for considering this enhancement! 🙏

"Hello @anuragverma108 👋,
I have added a back button to the Contact and Login pages to improve navigation, as described in the pull request. All checks have passed, and the Netlify preview is available for review.
Please take a look at the changes when you have a chance. I'd appreciate any feedback or approval to merge this PR.
Thank you! 🙏"

Resolve the conflicts in the mentioned files. Ensure you pull all the latest changes before pushing your feature/bug fixes to the main branch. After resolving the conflicts, please open a new PR for review.
Thank you!


Create source file button in Object View does nothing

Only works from right clicking on a library.
Also, when the source file is made, add it to the member view and then automatically bring it into focus


Diff color enhancements, add line number background

Bring back the background on line numbers. This feature was lost a long time ago.

Expanded lines background is now full-line, including line numbers:

Sort affected colors alphabetically in the CSS

Fixes #14603

Fixes #14603


adding widsom tooth files

If your PR is related to a contribution to the taxonomy, please, fill
out the following questionnaire. If not, replace this whole text and the
following questionnaire with whatever information is applicable to your PR.
Describe the contribution to the taxonomy

...
...
...

Input given at the prompt

   ...

Response from the original model

  ...

Response from the fine-tuned model

  ...

Contribution checklist

[ ] The contribution was tested with ilab generate
[ ] No errors or warnings were produced by ilab generate
[ ] All commits are signed off (DCO)
[ ] The qna.yaml file contains at least 5 seed_examples
[ ] The qna.yaml file was linted and prettified (yaml-validator can do both)
[ ] An attribution.txt file in the same folder as the qna.yaml file
[ ] Content does not include PII or otherwise sensitive or confidential information
[ ] Content does not include anything documented in the project's Avoid these Topics guidelines

https://github.com/instructlab/taxonomy/issues/807

@jjasghar Thank you so much for your patience and for working with me!

@instructlab-bot precheck

Added your qna.yaml to: https://github.com/instructlab/taxonomy/pull/1183


MacOS M1 can not run binary with go build, CODE SIGNING

Go version
go version go1.21.4 darwin/arm64
Reproducibility

[ ] Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/tt/Library/Caches/go-build'
GOENV='/Users/tt/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/tt/workspace/code/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/tt/workspace/code/go'
GOPRIVATE=''
GOPROXY='https://goproxy.cn,direct'
GOROOT='/Users/tt/workspace/tools/go'
GOSUMDB='off'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/tt/workspace/tools/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.4'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/rq/424y01rs27982pm0_238_t180000gn/T/go-build2771029319=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?
go build to create binary, then program can not work by CODE SIGNING

but if I use go run xxx, this can work sucessfully.
What did you expect to see?

What did you see instead?

@taoyq1988 kindly copy and paste the output. Kindly avoid screenshots. Try:
go build -o x .
./x

Also share the output u r getting with go run .

this is my sequence of commands:
go build -o xxx .
./xxx

then will get:
[1]    68085 killed     ./xxx

but if I use go run to run my program:
go run main.go

will work successfully:
2023/11/24 22:43:13 INFO Start app
2023/11/24 22:43:13 INFO Start http server port=8899
2023/11/24 22:43:13 INFO Secret secret=123456
...

In order to find problem, I use sudo dmesg | grep xxx to debug:
will get:
RX: 20 01 00 00 00 00 14 00 10 01 00 A2 00 00 0A 00AMFI: '/Users/tomtao/workspace/code/project/web3/chainface/xxx' has no CMS blob?
[461206.842074]: AMFI: '/Users/tomtao/workspace/code/project/web3/chainface/xxx': Unrecoverable CT signature issue, bailing out.
[461207.310723]: Sandbox: Mockitt Helper (GPU)(11446) deny(1) mach-lookup com.apple.audio.audiohaldSandbox: Microsoft Edge Helper (GPU)(22329) deny(1) mach-lookup com.apple.audio.audiohaldSandbox: Google Chrome Helper (GPU)(1468) deny(1) mach-lookup com.apple.audio.audiohaldWaking up reference: 1933Thread waiting on reference 1933 woke upevaluation result: 1933, allowed, cache,<PHONE_NUMBER>, 8, /Users/tomtao/workspace/code/project/web3/chainface/xxxCODE SIGNING: cs_invalid_page(0x102f5c000): p=70443[xxx] final status 0x23020200, denying page sending SIGKILL
[461207.326867]: CODE SIGNING: process 70443[xxx]: rejecting invalid page at address 0x102f5c000 from offset 0x0 in file "/Users/tomtao/workspace/code/project/web3/chainface/xxx" (cs_mtime:1700837282.365474057 == mtime:1700837282.365474057) (signed:1 validated:1 tainted:1 nx:0 wpmapped:0 dirty:0 depth:0)
[461207.326904]: xxx[70443] Corpse allowed 2 of 5

@seankhliao @Nasfame

@taoyq1988 can u try: 'go run . '

@taoyq1988 share the out of 'go run . '

I have given out the out of the 'go run . ', it's same as command 'go run main.go' -- the logs output of my program:
2023/11/24 22:43:13 INFO Start app
2023/11/24 22:43:13 INFO Start http server port=8899
2023/11/24 22:43:13 INFO Secret secret=123456
...

My MacOS version is 14.1.1

I think this is issue is very specific to your Mac os configuration. I would like to know what are the go versions u have used to far.
Do this issue reproduce in go1.21 for a simple  hello world program?

The go versions I have used on my computer are 1.18 and 1.20, and the most recent one I have used is 1.20.
For a simple hello world program, go 1.21 can compile and run go build normally. And I also discovered today that if I add -ldflags -w after go build, the previous program can also be run using go 1.21.
go build -ldflags -w -o xxx .
./xxx

@Nasfame

sounds like the solution is to use the latest release.
for future bug report, we'd appreciate if the reported versions in the initial report reflected those that had the issue.

but I had said the version I used at first, the latest release version 1.21.4.
the latest release version still has this bug.

go 1.20 has no problem, but go 1.21 has.

I'm having the same problem with binaries built with gotip.
$ gotip version
go version devel go1.22-f6509cf5 Thu Dec 21 00:15:58 2023 +0000 darwin/arm64
$ gotip build ./cmd/gotraceui
# honnef.co/go/gotraceui/cmd/gotraceui
ld: warning: ignoring duplicate libraries: '-lobjc'
$ ./gotraceui
[1]    46622 killed     ./gotraceui

As @taoyq1988 suggested, this works however:
gotip build -ldflags -w ./cmd/gotraceui

Here a crash report:
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Incident Identifier: B24BF945-E2FF-40F5-8CB0-8AC849FB6BB1
CrashReporter Key:   5B7B7B6C-9868-0FDA-A407-8AA6703D4834
Hardware Model:      Mac14,15
Process:             gotraceui [48433]
Path:                /Users/USER/*/gotraceui
Identifier:          gotraceui
Version:             ???
Code Type:           ARM-64 (Native)
Role:                Unspecified
Parent Process:      zsh [44587]
Coalition:           com.googlecode.iterm2 [3977]
Responsible Process: iTerm2 [5136]

Date/Time:           2023-12-21 17:38:48.7905 +0400
Launch Time:         2023-12-21 17:38:48.7890 +0400
OS Version:          macOS 14.2 (23C64)
Release Type:        User
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
Exception Subtype: UNKNOWN_0x32 at 0x000000010453c000
Exception Codes: 0x0000000000000032, 0x000000010453c000
VM Region Info: 0x10453c000 is in 0x10453c000-0x10496c000;  bytes after start: 0  bytes before end: 4390911
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  __TEXT                      10453c000-10496c000    [ 4288K] r-x/r-x SM=COW
      __DATA_CONST                10496c000-104c88000    [ 3184K] rw-/rw- SM=COW
Termination Reason: CODESIGNING 2 Invalid Page

Triggered by Thread:  0

Thread 0 Crashed:
0                                 	       0x1053fa204 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 52
1                                 	       0x1053fc2ac dyld3::MachOFile::forEachSupportedPlatform(void (dyld3::Platform, unsigned int, unsigned int) block_pointer) const + 160
2                                 	       0x1054522e4 dyld3::MachOFile::isBuiltForSimulator() const + 124
3                                 	       0x1053fdb88 start + 992

Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x000000010453c000   x1: 0x000000016b8c30d8   x2: 0x000000016b8c3080   x3: 0x00000001053f9e45
    x4: 0x0000000000000070   x5: 0x0000000000000073   x6: 0x0000000000000000   x7: 0x0000000000000ce0
    x8: 0x000000016b8c30b8   x9: 0x00000001054935f8  x10: 0x000000010547b000  x11: 0x000000010548876f
   x12: 0x0000000000000065  x13: 0x0000000000000073  x14: 0x0000000000058a70  x15: 0x0000000000000000
   x16: 0x00000001053fc34c  x17: 0x6ae100016b8c3080  x18: 0x0000000000000000  x19: 0x000000016b8c30d8
   x20: 0x000000010453c000  x21: 0x000000016b8c3080  x22: 0x00000001053f8000  x23: 0x000000016b8c3238
   x24: 0x000000016b8c3210  x25: 0x0000000000000000  x26: 0x0000000000000000  x27: 0x0000000000000000
   x28: 0x0000000000000000   fp: 0x000000016b8c3070   lr: 0x704d0001053fc2ac
    sp: 0x000000016b8c2fe0   pc: 0x00000001053fa204 cpsr: 0x80001000
   far: 0x000000010453c000  esr: 0x92000007 (Data Abort) byte read Translation fault

Binary Images:
       0x1053f8000 -        0x10548ffff  (*) <324e4ad9-e01f-3183-b09f-3e20b326643a> ???
       0x10453c000 -        0x10496bfff  (*) <c997b1c5-ddd5-3528-ad7e-10651d0ec9a7> ???
               0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???

Error Formulating Crash Report:
dyld_process_snapshot_get_shared_cache failed

EOF

-----------
Full Report
-----------

{"app_name":"gotraceui","timestamp":"2023-12-21 17:38:48.00 +0400","app_version":"","slice_uuid":"c997b1c5-ddd5-3528-ad7e-10651d0ec9a7","build_version":"","platform":0,"share_with_app_devs":0,"is_first_party":1,"bug_type":"309","os_version":"macOS 14.2 (23C64)","roots_installed":0,"incident_id":"B24BF945-E2FF-40F5-8CB0-8AC849FB6BB1","name":"gotraceui"}
{
  "uptime" : 200000,
  "procRole" : "Unspecified",
  "version" : 2,
  "userID" : 503,
  "deployVersion" : 210,
  "modelCode" : "Mac14,15",
  "coalitionID" : 3977,
  "osVersion" : {
    "train" : "macOS 14.2",
    "build" : "23C64",
    "releaseType" : "User"
  },
  "captureTime" : "2023-12-21 17:38:48.7905 +0400",
  "codeSigningMonitor" : 1,
  "incident" : "B24BF945-E2FF-40F5-8CB0-8AC849FB6BB1",
  "pid" : 48433,
  "translated" : false,
  "cpuType" : "ARM-64",
  "roots_installed" : 0,
  "bug_type" : "309",
  "procLaunch" : "2023-12-21 17:38:48.7890 +0400",
  "procStartAbsTime" :<PHONE_NUMBER>661,
  "procExitAbsTime" :<PHONE_NUMBER>094,
  "procName" : "gotraceui",
  "procPath" : "\/Users\/USER\/*\/gotraceui",
  "parentProc" : "zsh",
  "parentPid" : 44587,
  "coalitionName" : "com.googlecode.iterm2",
  "crashReporterKey" : "5B7B7B6C-9868-0FDA-A407-8AA6703D4834",
  "responsiblePid" : 5136,
  "responsibleProc" : "iTerm2",
  "codeSigningID" : "a.out",
  "codeSigningTeamID" : "",
  "codeSigningFlags" : 587334144,
  "codeSigningValidationCategory" : 0,
  "codeSigningTrustLevel" :<PHONE_NUMBER>,
  "instructionByteStream" : {"beforePC":"+mcFqfhfBqn2Vwep9E8Iqf17Can9QwKR9QMCqvMDAar0AwCq\/\/8AOQ==","atPC":"CABAuelZn1Kp3b9yHwEJa+AAAFTJWZ9Sqd2\/ch8BCWthAQBUiQOAUg=="},
  "wakeTime" : 3536,
  "sleepWakeUUID" : "75C5F419-185C-480B-B8DC-008304F56B5C",
  "sip" : "enabled",
  "vmRegionInfo" : "0x10453c000 is in 0x10453c000-0x10496c000;  bytes after start: 0  bytes before end: 4390911\n      REGION TYPE                    START - END         [ VSIZE] PRT\/MAX SHRMOD  REGION DETAIL\n      UNUSED SPACE AT START\n--->  __TEXT                      10453c000-10496c000    [ 4288K] r-x\/r-x SM=COW  \n      __DATA_CONST                10496c000-104c88000    [ 3184K] rw-\/rw- SM=COW  ",
  "exception" : {"codes":"0x0000000000000032, 0x000000010453c000","rawCodes":[50,4367564800],"type":"EXC_BAD_ACCESS","signal":"SIGKILL (Code Signature Invalid)","subtype":"UNKNOWN_0x32 at 0x000000010453c000"},
  "termination" : {"flags":0,"code":2,"namespace":"CODESIGNING","indicator":"Invalid Page"},
  "vmregioninfo" : "0x10453c000 is in 0x10453c000-0x10496c000;  bytes after start: 0  bytes before end: 4390911\n      REGION TYPE                    START - END         [ VSIZE] PRT\/MAX SHRMOD  REGION DETAIL\n      UNUSED SPACE AT START\n--->  __TEXT                      10453c000-10496c000    [ 4288K] r-x\/r-x SM=COW  \n      __DATA_CONST                10496c000-104c88000    [ 3184K] rw-\/rw- SM=COW  ",
  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":22,"task_for_pid":1},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
  "faultingThread" : 0,
  "threads" : [{"triggered":true,"id":4302728,"threadState":{"x":[{"value":4367564800},{"value":6099316952},{"value":6099316864},{"value":4383022661},{"value":112},{"value":115},{"value":0},{"value":3296},{"value":6099316920},{"value":4383651320,"symbolLocation":0,"symbol":"__block_descriptor_tmp.61"},{"value":4383551488,"symbolLocation":20,"symbol":"objc_visitor::ProtocolList::getProtocolField(objc_visitor::Visitor const&, unsigned long long) const (.cold.2)"},{"value":4383606639},{"value":101},{"value":115},{"value":363120},{"value":0},{"value":4383032140,"symbolLocation":0,"symbol":"invocation function for block in dyld3::MachOFile::forEachSupportedPlatform(void (dyld3::Platform, unsigned int, unsigned int) block_pointer) const"},{"value":7701436843879575680},{"value":0},{"value":6099316952},{"value":4367564800},{"value":6099316864},{"value":4383014912},{"value":6099317304},{"value":6099317264},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":8092124109837681324},"cpsr":{"value":2147487744},"fp":{"value":6099316848},"sp":{"value":6099316704},"esr":{"value":2449473543,"description":"(Data Abort) byte read Translation fault"},"pc":{"value":4383023620,"matchesCrashFrame":1},"far":{"value":4367564800}},"frames":[{"imageOffset":8708,"symbol":"dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const","symbolLocation":52,"imageIndex":0},{"imageOffset":17068,"symbol":"dyld3::MachOFile::forEachSupportedPlatform(void (dyld3::Platform, unsigned int, unsigned int) block_pointer) const","symbolLocation":160,"imageIndex":0},{"imageOffset":369380,"symbol":"dyld3::MachOFile::isBuiltForSimulator() const","symbolLocation":124,"imageIndex":0},{"imageOffset":23432,"symbol":"start","symbolLocation":992,"imageIndex":0}]}],
  "usedImages" : [
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" :<PHONE_NUMBER>,
    "size" : 622592,
    "uuid" : "324e4ad9-e01f-3183-b09f-3e20b326643a",
    "name" : ""
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 4390912,
    "uuid" : "c997b1c5-ddd5-3528-ad7e-10651d0ec9a7",
    "name" : ""
  },
  {
    "size" : 0,
    "source" : "A",
    "base" : 0,
    "uuid" : "00000000-0000-0000-0000-000000000000"
  }
],
  "vmSummary" : "ReadOnly portion of Libraries: Total=6208K resident=0K(0%) swapped_out_or_unallocated=6208K(100%)\nWritable regions: Total=8608K written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=8608K(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nSTACK GUARD                       56.0M        1 \nStack                             8176K        1 \n__DATA                            2800K        3 \n__DATA_CONST                      3216K        2 \n__DATA_DIRTY                        16K        1 \n__LINKEDIT                        1312K        2 \n__TEXT                            4896K        2 \n===========                     =======  ======= \nTOTAL                             76.0M       12 \n",
  "legacyInfo" : {
  "threadTriggered" : {

  }
},
  "logWritingSignature" : "c0220cb8517cd988d5d7c092af1ecbaa30fa9d1b",
  "trialInfo" : {
  "rollouts" : [
    {
      "rolloutId" : "6410af69ed1e1e7ab93ed169",
      "factorPackIds" : {

      },
      "deploymentId" : 240000010
    },
    {
      "rolloutId" : "61675b89201f677a9a4cbd65",
      "factorPackIds" : {
        "HEALTH_FEATURE_AVAILABILITY" : "65287aa4be905e686a05f0a2"
      },
      "deploymentId" : 240000079
    }
  ],
  "experiments" : [

  ]
},
  "reportNotes" : [
  "dyld_process_snapshot_get_shared_cache failed"
]
}

Can you please try:
rm gotraceui
gotip build ./cmd/gotraceui
./gotraceui

Sometimes the signing/blessing bits get confused, especially if a file has been replaced in-place. Such as what happened to me in #56599. Explicitly rm'ing it helps reset things. That could also explain why gotip run works.

Rm'ing or specifying a new name does not work:
$ gotip build -o a.out ./cmd/gotraceui
# honnef.co/go/gotraceui/cmd/gotraceui
ld: warning: ignoring duplicate libraries: '-lobjc'
$ ./a.out
[1]    2128 killed     ./a.out

Thanks! Maybe related to #63997 (https://github.com/golang/go/issues/63997#issuecomment-1847840272)? Output from go env echo $PATH may help.

So I bisected my PATH and the issue for me comes from /opt/homebrew/opt/llvm/bin being in my path.

Never knew that CollabVM participated in this issue. But look at this screenshot:

sounds like it's a dup of #63997


ES_HTTP_LOGGING appears broken

There were basically 2 issues:

mix of SLF4J 1.x and SALF4J 2.x: binary nothing breaks but at runtime, the provider is not discovered, since most of the dependencies (armenia, ...) still use SLF4J 1.x, switched to that
the com.linecorp.armeria.client.logging.LoggingClient logger with INFO level is needed in order to log the HTTP requests (headers, body, etc)

Sample logs (request body):
zipkin         | {"index":{"_index":"zipkin-span-2024-01-30","_id":"536225a52dbf288f-a973c94cfea8cb9782098ed69b70ec8e"}}
zipkin         | {"timestamp_millis":1706650740662,"_q":["wr","ws","http.method","http.method=GET","http.path","http.path=/zipkin/api/v2/traces"],"traceId":"536225a52dbf288f","id":"536225a52dbf288f","kind":"SER
VER","name":"get /zipkin/api/v2/traces","timestamp":1706650740662116,"duration":381428,"localEndpoint":{"serviceName":"zipkin-server","ipv4":"<IP_ADDRESS>"},"remoteEndpoint":{"ipv4":"<IP_ADDRESS>","port":41546},"an
notations":[{"timestamp":1706650740662245,"value":"wr"},{"timestamp":1706650741041160,"value":"ws"}],"tags":{"http.method":"GET","http.path":"/zipkin/api/v2/traces"}}
zipkin         | }
zipkin         | 2024-01-30T21:39:02.175Z  INFO [/] 1 --- [orker-epoll-2-5] c.l.a.c.l.LoggingClient                  : [creqId=4fd0f854, chanId=fbe5b66c, laddr=<IP_ADDRESS>:52428, raddr=elasticsearch/<IP_ADDRESS>:9
200][http://elasticsearch:9200/_bulk#POST] Response: {startTime=2024-01-30T21:39:02.173Z(1706650742173292), length=313B, duration=1285µs(1285103ns), totalDuration=182ms(182880090ns), headers=[:status=200, x-ela
stic-product=Elasticsearch, content-type=application/json, content-encoding=gzip, content-length=313], content={"errors":false,"took":159,"items":[{"index":{"_index":"zipkin-span-2024-01-30","_id":"536225a52dbf
288f-da49c98df47203e6e632b8d8b392a319","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":34,"_primary_term":17,"status":201}},{"index":{"_index":"zipkin-span-2024-01-30",
"_id":"536225a52dbf288f-22efa2babd65cf0f145f1830e9f96fa0","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":32,"_primary_term":17,"status":201}},{"index":{"_index":"zipki
n-span-2024-01-30","_id":"536225a52dbf288f-ce4c65a171114a4df3020cee57ad5ad3","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":32,"_primary_term":17,"status":201}},{"inde
x":{"_index":"zipkin-span-2024-01-30","_id":"536225a52dbf288f-a973c94cfea8cb9782098ed69b70ec8e","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":36,"_primary_term":17,"s
tatus":201}}]}}
zipkin         | 2024-01-30T21:39:05.447Z  INFO [/] 1 --- [orker-epoll-2-5] c.l.a.c.l.LoggingClient                  : [creqId=3eec49c0, sreqId=95fb6523, chanId=fbe5b66c, laddr=<IP_ADDRESS>:52428, raddr=elasticse
arch/<IP_ADDRESS>:9200][http://elasticsearch:9200/_cluster/health/zipkin*span-*#GET] Request: {startTime=2024-01-30T21:39:05.443Z(1706650745443233), length=0B, duration=874µs(874386ns), scheme=none+h1c, name=get-
cluster-health, headers=[:method=GET, :path=/_cluster/health/zipkin*span-*, :authority=elasticsearch:9200, b3=8f069f5f99c68239-5951f64cf3e5a4c4-0-8f069f5f99c68239, accept-encoding=gzip,deflate,x-snappy-framed,
user-agent=armeria/1.26.4], content=}
zipkin         | 2024-01-30T21:39:05.448Z  INFO [/] 1 --- [orker-epoll-2-5] c.l.a.c.l.LoggingClient                  : [creqId=3eec49c0, sreqId=95fb6523, chanId=fbe5b66c, laddr=<IP_ADDRESS>:52428, raddr=elasticse
arch/<IP_ADDRESS>:9200][http://elasticsearch:9200/_cluster/health/zipkin*span-*#GET] Response: {startTime=2024-01-30T21:39:05.446Z(1706650745446854), length=228B, duration=155µs(155915ns), totalDuration=3776µs(37
76869ns), headers=[:status=200, x-elastic-product=Elasticsearch, content-type=application/json, content-encoding=gzip, content-length=228], content={"cluster_name":"docker-cluster","status":"yellow","timed_out"
:false,"number_of_nodes":1,"number_of_data_nodes":1,"active_primary_shards":5,"active_shards":5,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":5,"delayed_unassigned_shards":0,"number_of_pendi
ng_tasks":0,"number_of_in_flight_fetch":0,"task_max_waiting_in_queue_millis":0,"active_shards_percent_as_number":50.0}}
Gracefully stopping... (press Ctrl+C again to force)

The build is failing now due to:
#14 1.347 ERROR: unable to select packages:
#14 1.350   mysql-10.11.6-r0:
#14 1.350     breaks: world[mysql~10.11.5]
#14 1.350   mysql-client-10.11.6-r0:
#14 1.350     breaks: world[mysql-client~10.11.5]
#14 ERROR: process "/bin/sh -c (cd install && ./install.sh) && rm -rf ./install" did not complete successfully: exit code: 2

Probably mysql 10.11.6-r0 is being rolled out now ...

good guess. you can bump that here for convenience https://pkgs.alpinelinux.org/packages?name=mysql&branch=edge&repo=&arch=&maintainer=

we should do a patch after update to armeria 1.27 which addresses some things we've worked around in other areas of the server.


Kong 0.11.0 URI evaluation order problem

Summary
I read the Proxy Reference document - https://getkong.org/docs/0.11.x/proxy/, and found that it works differently from the document in some cases.
Issue 1.
The document says - "URI prefixes are always evaluated first".
But see the source code here,
https://github.com/Mashape/kong/blob/e49cd360693e44e8d3842f62ba92d5c367c3052a/kong/core/router.lua#L666-L691
When req_uri is matched in plain_indexes.uris, it stopped to scan. But if req_uri is matched in uris_prefixes, it breaks only the uris_prefixes's FOR loop. So it will continue to find in uris_regexes.
As a result, the evaluation order becomes below.
1) full uri match (plain_indexes.uris)
2) regex match (uris_regexes)
3) prefix match (uris_prefixes)
Is this the designed behavior?
Issue 2.
The document says - "Kong will evaluate regex URIs based on the order in which they are defined".
But it sounds ambiguous. First time I read that sentences, thought that regex URIs are evaluated by the order of they were registered. But it did not work like that way. I registered 3 APIs, but the match order was seemed like 3 -> 1 -> 2. (I used postgresql.)
Maybe the reason is that when Kong queries api list from DB, it does not use "ORDER BY" condition. SQL queries without "ORDER BY" condition cannot guarantee any order. Therefore Kong users cannot control the order.
I think duplicated matching cases are rare case, and these issues are not so critical for me. But I thought that sharing the issues are better for Kong project. I hope this will help.
Steps To Reproduce
Below is my test cases. I registered 5 APIs.
regex-api-1
uris : /status/(re)
upstream_url : http://mockbin.org/request/regex1
regex-api-2
uris : /status/(r)
upstream_url : http://mockbin.org/request/regex2
regex-api-3
uris : /(status)
upstream_url : http://mockbin.org/request/regex3
prefix-api-1
uris : /status
upstream_url : http://mockbin.org/request/prefix1
prefix-api-2
uris : /status/resource
upstream_url : http://mockbin.org/request/prefix2
And the result was like below. Maybe the result can be different.
"/status" proxied to prefix-api-1
"/status/r" proxied to  regex-api-3
"/status/re" proxied to regex-api-3
"/status/resource" proxied to prefix-api-2
"/status/resource/1" proxied to  regex-api-3

Hi @checky,
Thanks for the report! We'll look into this.

A fixed has been proposed in #2924. It won't retroactively fix the APIs ordering and evaluation order in the router (which is preferable considering it would be a breaking change), but it ensures that on a fresh Postgres instance, APIs will ordered by their created_at field, which now uses a millisecond precision.
#2925 will not work retroactively either, but it will ensure that existing Postgres instance will use a millisecond precision for the created_at field.

Closing this as #2924 has been merged. The fix should make it in the 0.11.1 release at most a couple of weeks from now. Thanks again for the report!

Hi @thibaultcha.
Thanks for the bug fix. But can I ask you to confirm Issue 1, too? The evaluation order between regex and prefix seems strange to me.

Issue 1.
The document says - "URI prefixes are always evaluated first".
But see the source code here,
https://github.com/Mashape/kong/blob/e49cd360693e44e8d3842f62ba92d5c367c3052a/kong/core/router.lua#L666-L691
When req_uri is matched in plain_indexes.uris, it stopped to scan. But if req_uri is matched in uris_prefixes, it breaks only the uris_prefixes's FOR loop. So it will continue to find in uris_regexes.
As a result, the evaluation order becomes below.
1) full uri match (plain_indexes.uris)
2) regex match (uris_regexes)
3) prefix match (uris_prefixes)
Is this the designed behavior?

@thibaultcha  Sorry to bother you. I'm investigating upgrading to kong 0.11.1, but the documentation for evaluation order of kong 0.11.1 is not clear. So what is correct evaluation order?


Configurable MIN_VOLUME_TO_RECORD

I tend to get a lot of ghost pours, and most of them are caught by the 10 ml MIN_VOLUME_TO_RECORD.  However, a few still get through would it be possible to make this a configurable setting?

This is configurable in the android app under the kegerator settings:
https://github.com/Kegbot/kegbot-android/blob/c8919aad9ab5db99f827454ac8ac72a9017bbd86/kegtab/src/main/res/xml/settings_kegerator.xml#L23-L29


ACCOUNT_NAME value is moved to secrets

Per https://github.com/Azure/apim-landing-zone-accelerator/blob/46c844c254815f5cefbecb9d2ae22b61ec6270ad/.github/workflows/es-apim.yml#L57, ACCOUNT_NAME value is retrieved from GitHub Secret, no longer from config.yml. Hence proposing this PR for doc change.

@hieumoscow this PR is too old, apologies it did not get merged before


Guide Setup deployed site doesn't match jade code

from https://angular.io/docs/js/latest/guide/setup.html
The deployed site example doesn't have the  tag, but the file appears to be changed here in the repo:  https://github.com/angular/angular.io/blob/master/public/docs/js/latest/guide/setup.jade#L69
Has the site been redeployed lately?

Yes, fixed yesterday. Thanks!


Implement retry for ServerVersion.AutoDetect in AddMySqlDbContext for Pomelo

Fixes #1866.
Microsoft Reviewers: Open in CodeFlow

@eerhardt I've triaged this into P4 but could you decide whether it needs to go in after snap?

Be aware that if you use ServerVersion.AutoDetect, then generate migrations on your development machine, and your local and production MySQL database servers differ even slightly in their version (just one patch level can be enough), then your generated migrations might not work on your production server.
Also, generating migrations without a locally available database server does fail by default when using ServerVersion.AutoDetect.