Add slippage factors and margin scaling factors to market accordion

The Chore
We are missing a bunch of things from the risk model section of the accordion ... and presumably always have been.
These need to be added
Tasks

[ ] Add margin scaling factors to accordion
[ ] Add slippage factors
[ ] Remove "Risk Parameters" and just put sigma under the "Risk Model"

Additional details / background info
Current view:

Margin scaling needs to be in, and formatted nicely:

Slippage factors are easier ... not sure why they werent always there.

Once we are pulling in all the data additionally display:
Max. Initial leverage long: which is calculated as
(1.0/initial_margin) x (1.0 / (linear_slippage_factor + rf_long))

which should give us, with the numbers in the screenshots about (1/1.5) x (1/(0.001 + 0.023) = 28.
Max. Initial leverage short: which is calculated as
(1.0/initial_margin) x (1.0 / (linear_slippage_factor + rf_short))

which should give us, with the numbers in the screenshots about (1/1.5) x (1/(0.001 + 0.023) = 28.
Max leverage long:
(1.0 / (linear_slippage_factor + rf_long))

and Max leverage short:
(1.0 / (linear_slippage_factor + rf_short))

do we need all of these decimals?

@davidsiska-vega @JonRay15


Clean up and refactor into web-lib module

Description
This basically removes all the old calls, in favor of simpler version and focused only on building and deploying of web-assets.
This should become a new module ( aio-lib-web ? ) and do what aio-lib-runtime does for actions/runtime only for static assets, and cdn.
Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

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

Checklist:

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

first review lgtm, still missing tests

@Himavanth Please have a look at this.


README: fix TOC

The PR updates the table of contents.

Another approach would be removing TOC because GitHub shows it out of the box:

See https://github.blog/changelog/2021-04-13-table-of-contents-support-in-markdown-files/

Since GitHub has this feature by default it's better to drop the self-maintained TOC, because we've to maintain the entries twice, which is error prone.
#3469 modified one of the entries.

@JoeKar removed TOC, updated PR's description.


Fix runner pod to not stuck in Terminating when runner got deleted before pod scheduling

This fixes the said issue that I found while I was running a series of E2E tests to test other features and pull requestes I have recently contributed.

This has not made into the release yet right ?


ci: upload test coverage to codecov

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@5f225a0). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #55   +/-   ##
=======================================
  Coverage        ?   93.33%
=======================================
  Files           ?        5
  Lines           ?      345
  Branches        ?       66
=======================================
  Hits            ?      322
  Misses          ?       23
  Partials        ?        0

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Allow signing assertion instead of the response

Tested signing assertion only and response only with a GSA built with cl/84821935.

I'm not very familiar with this code, but the changes LGTM.  Have you tested this?

Yes. Tested signing assertion only and response only with a GSA built with cl/84821935.

great. thanks for confirming

Sure.
On Wed, Jan 28, 2015 at 10:13 AM, macpd<EMAIL_ADDRESS>wrote:

great. thanks for confirming
—
Reply to this email directly or view it on GitHub
https://github.com/google/gsa-admin-toolkit/pull/25#issuecomment-71885295
.


To-Do List

To-Do List
1. Listings Page

[ ] Create API route to load data into the listings page. (mid shouldnt be that bad tbh)
[ ] Add category as an attribute for products in the database. (easy af) - look at categories in main branch. /listings.tsx

2. Profile Page

[ ] Connect Supabase authentication to the profile page. (easy enough)
[ ] Add a favorites feature: - MAYBE

Users can favorite an item on the product page. (mid but could be annoying w typescript smh)
Implement an endpoint to store and retrieve user favorites
Display favorited items in the "Favorites" section of the profile page.

3. User Authentication

[ ] Restrict unauthenticated users from interacting with listings: (easy)
Redirect unauthenticated users to the login page.

4. Transactions

[ ] Implement transaction logic to change values in the db: (mid)
[ ] Transactions API endpoint
Make sure buyer balance is valid before deducting funds - FRONTEND CHECKS only then SENDS request

Deduct money from the buyer.
Add money to the seller.

5. Landing Page

[ ] Adjust the landing page: (easy af but could be annoying with typescript if we choose to keep the searchbar)

Either remove the search bar and redesign the layout.
Or pass the search bar input to the listings page and apply the search logic there.

6. Bidding System

[ ] Implement bidding feature + logic (HARD):

Include timers for bids.
need to do some research on how this can be done
Add confirmation for winning or losing a bid.
need realtime updates, and show outcome in the cart page/profile page?. need to research how we can do this

7. Create Listing

[ ] Implement logic for creating a new listing:

Save listings to the database. (mid and annoying)
need to make it a form basically. make sure it aligns w every attribute needed shown in the db schema

8. Roles Implementation

[ ] Logic for roles, V,  U, S

9. SuperUser View to ban/demote users

[ ] logic for that

10. [ ]API Endpoint to get Live Active bids for a user.

I got 1 and 7 for now

I got 4 and 6

All transactions in Profile Page and connect to review/comment component

Got the Open_AI ai connected for 11 and set up the backend

1 . Connected listings page to backend + got filters feature working with it

Got product page to work accordingly


Support for PEP 604 – Allow writing union types as X | Y

Nuitka version, full Python version, flavor, OS, etc. as output by this
command (it does more than you think, and we are adding more all the time):

python -m nuitka --version

0.8.4
Commercial: 1.0.0
Python: 3.10.5 (tags/v3.10.5:f377153, Jun  6 2022, 16:14:13) [MSC v.1929 64 bit (AMD64)]
Flavor: Unknown
Executable: C:\Users\user\AppData\Local\pypoetry\Cache\virtualenvs\my-app-uZqywXsA-py3.10\Scripts\python.exe
OS: Windows
Arch: x86_64
WindowsRelease: 10

How did you install Nuitka and Python
pip in a poetry environment

The specific PyPI names and versions
No relevant packages.

Many times when you get an error from Nuitka, your setup may be special
There is no issue if I use e.g. Optional[str] instead of str | None union types.

Also supply a Short, Self Contained, Correct, Example
Use of any function which uses union types as specified by PEP 604.

Provide in your issue the Nuitka options used
nuitka --onefile --prefer-source-code --assume-yes-for-downloads --enable-plugin=anti-bloat --noinclude-setuptools-mode=nofollow --noinclude-pytest-mode=nofollow --plugin-enable=multiprocessing --plugin-enable=numpy --plugin-enable=pkg-resources --plugin-enable=pylint-warnings --msvc=latest --enable-plugin=data-hiding --windows-onefile-tempdir --windows-icon-from-ico=D:\a\my-app\my-app\my_app\resources\favicon.ico --windows-company-name=MyApp --windows-product-name=My App (C) 2020-2022 MyCompany --windows-file-description=My App 2022.5.0 (09d086e) --windows-file-version=2<IP_ADDRESS> --windows-product-version=2<IP_ADDRESS> D:\a\my-app\my-app\my_app\MyApp.py

Note if this is a regression
No.

Consider getting commercial support
Yes, we have Nuitka Commercial and Priority.

I believe they are working, can you provide an example of something not working, please?

Ah, sorry. On closer inspection it seems like it has to do with forward referencing.
An executable is created by Nuitka, but when I run it I get TypeError: unsupported operand type(s) for |: 'str' and 'NoneType'.
Example with pydantic:
from pydantic import BaseModel, Field

class A(BaseModel):
    x: "B" | None = Field(None, hidden=True)

class B(BaseModel)
    y: int = 0

Changing "B" | None to "Optional["B"]" removes the error. Alternatively, forward referencing like this should be avoided.

I think Nuitka statically optimizes "B" | None according to normal rules, since B is not a type, but a string:
>>> "B" | None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'str' and 'NoneType'

>>> x = ast.parse("X: 'B' | None")
>>> ast.dump(x)
"Module(body=[AnnAssign(target=Name(id='X', ctx=Store()), annotation=BinOp(left=Constant(value='B'), op=BitOr(), right=Constant(value=None)), simple=1)], type_ignores=[])"

Right now, the annotation is build with the same parsing code that standard code does. Thankfully CPython a way to introduce new inconsistency, such that, we will have to specify a context here, that enforces different parsing during it. And esp. these forward declarations from strings are a specialty there. So now I don't know if | needs to be treated differently, or if strings need to be considered types.

Ok, I wasted my time, your example doesn't work in CPython either, please make a new report with a real incompatibilty when you find one.
python3.10 MiniPydanticAnnotation.py
Traceback (most recent call last):
  File "C:\Users\kayha\repos\Py2C\MiniPydanticAnnotation.py", line 3, in <module>
    class A(BaseModel):
  File "C:\Users\kayha\repos\Py2C\MiniPydanticAnnotation.py", line 4, in A
    x: "B" | None = Field(None, hidden=True)
TypeError: unsupported operand type(s) for |: 'str' and 'NoneType'


Update Composer dependencies (2023-05-20-00-13)

Visual regression test passed!
View the visual regression test report


[HTML] Make API a bit more flexible

On our design system we have one particular component which is exposed in the library in multiple components.
This particular component has 10 variants, so i have to use figma.connect() 10 times.
To avoid repeating code multiple times because the only thing that changes in the code is that we add change only one property.
So for the 10 code.connect calls the only thing that changes is that we add in props object variant: figma.string(variant) and we also
<component variant="${props.accent}" ...multiple other props>
  ${props.label}
</component>

Instead of repeating code for each code.connect like this
figma.connect(
  "URL",
  {
    props: sharedProps,
    example: (props) => html`
      <component variant="red" ...moreProps>
        ${props.label}
      </component>
    `
  }
);

figma.connect(
  "URL",
  {
    props: sharedProps,
    example: (props) => html`
      <component variant="blue" ...moreProps>
        ${props.label}
      </component>
    `
  }
);

ATTEMPT 1
So I tried separating the config in a separate function like this but i get an error:
const config = (accent) => ({
  props: {
    // shared props
    ...sharedProps,
    accent: figma.string(accent), // or other variant
  },
  example: (props) => html`
    <component variant="${props.accent}" ...moreProps>
      ${props.label}
    </component>
  `
})

figma.connect(
  "URL",
  config('blue')
);

figma.connect(
  "URL2",
  config('red')
);

Error:
undefined: The second argument to figma.connect() must be an object literal. Example usage:
`figma.connect('https://www.figma.com/file/123?node-id=1-1', {
  example: () => html`<button />`
})`

ATTEMPT 2
I tried instead of calling `config(accent)' this:
figma.connect(
  "URL2",
  {...config('blue')}
);

i get this error
undefined: TypeError: Cannot read properties of undefined (reading 'initializer')

For a better DX i think the API should be a little more flexible and allow passing something else than object litterals especially for such cases where the same code is repeated a lot of times.

Hey @massi08, thanks for the report. Just to validate my understanding, these are multiple different components (not variants) in Figma, so each has a different URL, but the code version is identical save for one prop which changes?
If so then we don't have a great solution for avoiding repetition right now. The reason you're hitting issues is that Code Connect files are actually parsed rather than executed, so we only support a subset of JS syntax.
One option is that you could have a script which generates the Code Connect file for each of these from one master copy, a bit like the example script we have for linking icons.
I'm going to raise this with the team for discussion about how we could better support your use case or more JS syntax.

Yes for exemple, tag component which is basically the same except it has different colors. To make it easier for designers when using our library to spot the right tag, instead of exposing one tag component with the accent property. We expose each variant in a component for e.g tag red, tag blue... But on the developer end we only expose one tag component with a variant property.
Thanks for your reply, I will check the script. I now understand why I am facing so many restrictions. for e.g: No ternaries in the string interpolation, the ones above.
I guess you have your reasons to only parse and not execute these files maybe for security or performance. But we will certainly appreciate more flexibility.


Add further public holidays for moldova...

International woman day on March 8th
Chrildrens day on June 1st
Christmas on December 25th

closes #217

Oh, I've added the tests as well (as requested yesterday) ;) (https://github.com/focus-shift/jollyday/pull/219)
Regarding these added holidays I'm not 100% sure either cause I'm from Poland and I have no direct contact to Moldova end users. I will try to check, though and get back to you.
One thing to notice is that probably Children's day is no more a national holiday, but it was up until 2021 (source: https://www.officeholidays.com/holidays/moldova/international-childrens-day)

ok, as to my best knowledge all the days you've added are indeed public holidays in Moldova.
Children's Day is public holiday since 2016 (source: https://gov.md/en/content/government-declared-international-childrens-day-day)

Thanks for the tests! I had some time and wanted to learn more about the public holidays in Moldova and started some tests :D The validFroms are nice. I will take your pr and will look what my will add to it.
Thanks for your work!

Hi @derTobsch,
thank you for quickly merging the pull requests :) One more question - would you be able to release last changes regarding Moldova soon? I'd be happy to update jollyday version in my project :)

Hi @derTobsch,
thank you for quickly merging the pull requests :) One more question - would you be able to release last changes regarding Moldova soon? I'd be happy to update jollyday version in my project :)

Release is on its way.


CMakeLists.txt: fix install on macOS if GNU coreutils are used

bsd ln supports both -h and -n, while GNU only supports -n.
In Nix we use GNU coreutils and hence the installation breaks.
Also see https://github.com/NixOS/nixpkgs/pull/182909
With this patch installation will work with both variants of ln

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Roadmap update

What would you like to be cleaned:
Update the Roadmap in the README.md, it's stale, e.g. we already supported multi-cluster. Maybe, refresh other parts as well, like the new introduced features.
Why is this needed:
Provide a high level overview and vision about the project.

Good point
cc @tenzen-y @mwielgus @mwysokin @dgrove-oss

This is a duplicated issue: https://github.com/kubernetes-sigs/kueue/issues/3377
/close


refactor(scaffolder): clean up codebase of RepoUrlPicker

As a result of a review on #25460 by @camilaibs, the code was inconsistent with RepoUrlPicker, which is otherwise very similar.
We discussed during the latest Scaffolder SIG on 12 July 2024 that we should either roll those changes back to stay consistent or apply those changes to RepoUrlPicker as well. Since it's definitely an improvement, this pull request should add those improvements to RepoUrlPicker as well.
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[x] All your commits have a Signed-off-by line in the message. (more info)

@benjidotsh do you think you could fix up the conflict in this? :pray:

Nice work again! @benjidotsh :pray:


Can Not Find Policy

I'm getting this error:
unable to find policy `#<OrderTransaction:0x007f006b354ce8>Policy` for `[#<OrderTransaction id: 1473, clientid: .....]

controllers/order_controller.rb =>
def index
  @user_orders = Order.includes(:order_transaction).where(user_id: current_user.id)
  @orders = @user_orders.map{|k| k.order_transaction}.keep_if{ |a| a != nil }
  authorize @orders, :index_self?
end

I tried several policy files but none of them worked for me.
policies/array_policy.rb =>
class ArrayPolicy < ApplicationPolicy
  def index_self?
    user.is_student? && !user.is_staff?
  end
end

policies/order_policy.rb =>
class OrderPolicy < ApplicationPolicy
  def index_self?
    user.is_student? && !user.is_staff?
  end
end

policies/order_transaction_policy.rb =>
class OrderTransactionPolicy < ApplicationPolicy
  def index_self?
    user.is_student?
  end
end

You cannot give an array or hash to authorize! You can only give a class name Order or OrderTransaction or an instance of a class.
@order = Order.first

authorize Order # useful for index action where you don't have an instance but a collection
authorize OrderTransaction # useful for index action where you don't have an instance but a collection
authorize @order # useful if you have a single instance


Fix white gap between logo and results at /result page

There is a white empty gap between logo and results at /result page...

Fixed on 367b502


Remove dupes

Should this be an option as a subset, or perhaps better yet, remove dupes from a Job in situ?

Done.


Adding Heavy-Light-Decomposition Implementation

Description of Change
Added a new file heavy_light_decomposition.cpp, which supports point updates and path queries in a tree. The implementation is completely original, and implemented from scratch.
Checklist

[x] Added description of change
[x] Added file name matches File name guidelines
[x] Added tests and example, test must pass
[x] Added documentation so that the program is self-explanatory and educational - Doxygen guidelines
[x] Relevant documentation/comments is changed or added
[x] PR title follows semantic commit guidelines
[x] Search previous suggestions before making a new one, as yours may be a duplicate.
[x] I acknowledge that all my contributions will be made under the project's license.

Notes: Adding an implementation of Heavy-Light decomposition.

Heyy, I'd like to contribute to this repository with my implementation of HLD. I have used some protected members in my base class (Tree), because these are to be accessed and modified in the derived class (HLD), but the check throw warnings-as-errors. Is there anyway around this?
Thank you.

After reviewing the commit chain, it seems that the following happened and I understand it was not your fault.
Description of the error
When you forked the repo, there was an accidental commit by a contributor who did not follow the protocol and hence broke the CI chain. the error reported is due to a file not in your commit chain.
These are the commits recorded as:  c3e0c1a , 2e46077 and a36fd06 and they do not bear your authorship.
The issue has been rectified as of writing this comment.
How to resolve
Please rebase your commits to the current master branch of the repo.
Sorry for the inconvenience. Thank you for your contributions 🙂

Thank you for your reply. I will re-fork and create a new pull request.


Difficulty ramp up

I am not sure if it's intended, but some values like these:
n.maxEnemyPowerCount += 2000;
n.maxOutsideEnemyPowerCount += 20;
n.maxDaytimeEnemyPowerCount += 200;

get added to the level's difficulty each time you land on said planet, and it is carried even if you fail a quota and restart the game that way. This makes the game ridiculously difficult on the next run if you fail a game. (or have a long run).
Also the numbers are quite extreme, Titan's default maxEnemyPowerCount is only 18, not sure if 2k is intended

This issue still persist on 1.2.5, also the loot value increases for each landing on the same planet. I don't think it's supposed to be that way

The previous values were marked //TODO during development, then I accidentally deleted the mark, I should have changed it, but forgot. Now I think this increase will be fair.

Maybe maxEnemyPowerCount += 4/6

I know, in 1.3.0 I will add a reset and return the old values, it will be better, now I’m taking a short break


cmd/preguide: add tighter checks on steps, order etc

At present it is possible for:

a script to declare steps that are not reference by the guide - this means that the user might not be able to complete the guide as scripted because steps are "missing"
a guide to reference steps out of order from the order in which they are declared in the script - in the same way, this might leave the user in a broken state

We should therefore:

enforce that the order of reference from a guide matches the order of declaration
that all steps in a script are referenced from a guide are referenced unless explicitly marked as "info only"
we might then want to run a version of the script where the "info only" steps are not run to verify they don't impact the integrity of the script

This was fixed in f25120e82323a6f1144aaff5af7cf6180f45c631


[analyzer] Why record_literal_one_positional_no_trailing_comma is a warning?

The following code produces an error in VM but only a warning in the analyzer
void foo((int,) r) {}

main() {
  foo((1));
}

Output
sgrekhov@SGREKHOV-HP:~/Google/dart-sdk/sdk$ ./out/ReleaseX64/dart-sdk/bin/dart analyze test.dart
Analyzing test.dart...             0.5s

warning • test.dart:4:7 • A record literal with exactly one positional field requires a trailing comma. Try adding a trailing comma. •
          record_literal_one_positional_no_trailing_comma

1 issue found.
sgrekhov@SGREKHOV-HP:~/Google/dart-sdk/sdk$ ./out/ReleaseX64/dart-sdk/bin/dart test.dart
test.dart:4:8: Error: The argument type 'int' can't be assigned to the parameter type '(int)'.
  foo((1));
       ^

Why it is a warning in the analyzer, not an error? My IDE (IntelliJ IDEA) doesn't show this error in red, but in yellow as if it is something like unnecessery cast.
Tested on Dart SDK version: 3.4.0-edge.148d5ac76d53537d808ec8a8a45f38ff88d57528 (main) (Sun Jan 28 18:15:40 2024 +0000) on "linux_x64"

@pq

Thanks! That was definitely an oversight. Fix in flight...


Add test CD file

This PR adds a workflow file that will the be the basis of our CD. At present, all it does is wait until the "Check" (HA config check, no linting) workflow has completed, then echoes it's status (success/failure). Eventually on success it will deploy config files up to the EC2 instance. However, I am having issues getting it to run and have seen in some places that it will only run if the file is on the default ('main`) branch. I don't think this would break anything by merging so I just want to try it out, but if this gets disapproved because it's not a finished product yet, I understand and I'll figure out another way to test.
Related #111

This also updates the workflows to only run linting on HA config files. I'm not sure if this is what we want necessarily, but this is an example of how to do it for now (until we make our own yamllint config)


Implement support for Lutris

What's your idea?
Hello there!
I installed a game (Yooka-Laylee) via Lutris (Flatpak) from Amazon Prime Gaming on the Steam Deck. I noticed that my save files are not recognized. After some research it is clear that Ludusavi knows the game in it's manifest, but does not understand the folder structure generated by Lutris. This might be related with #156.
If I add the prefixes folder and mark it as a prefix folder, it works:
/home/deck/Games/amazon/yooka-laylee/
The full save game folder is
/home/deck/Games/amazon/yooka-laylee/drive_c/users/deck/AppData/LocalLow/Playtonic Ltd/Yooka-Laylee/
PCGW's data set knows about the correct path on windows:
%USERPROFILE%\AppData\LocalLow\Playtonic Ltd\Yooka-Laylee\
There are - as always - several ways to archive this. One would be to check a "Lutris" folder ($HOME/Games) with globs.
One more elegant way could be to parse the *.yml files that are created for each game in the Lutris config folder:
/home/deck/.var/app/net.lutris.Lutris/config/lutris/games/
An excerpt of the file for this specific game:
game:
  args: ''
  exe: /home/deck/Games/amazon/yooka-laylee/drive_c/game/YookaLaylee64.exe
  prefix: /home/deck/Games/amazon/yooka-laylee
  working_dir: /home/deck/Games/amazon/yooka-laylee/drive_c/game

One could detect all games by adding all game.prefix-paths as prefix-folder-type roots.
I don't know you philosophy of handling this stuff. This is just a quick and dirty implementation idea, as I just stumbled across this project minutes ago.

Hi! Thanks for this suggestion and for the additional details.
I'm open to integrating Lutris via the YAML files, but the main challenge will be identifying the correct file for each game. Do you know where Lutris stores the game's official title, as opposed to the Lutris slug? In this case, the title and slug would be almost the same (Yooka-Laylee vs yooka-laylee), but that's not always true, since it looks like non-ASCII characters are omitted or even replaced by a UUID.

From this comment, it sounds like the game titles would be stored in /home/deck/.var/app/net.lutris.Lutris/config/lutris/pga.db. I'm not sure what else is stored there or if you'd be comfortable sharing a copy of it so I can take a look at the structure. If not, I can try to set up Lutris in a Linux VM to get a copy.

It is also in the yaml.
I have shortened out the download and install stuff.
game:
  args: ''
  exe: /home/deck/Games/amazon/yooka-laylee/drive_c/game/YookaLaylee64.exe
  prefix: /home/deck/Games/amazon/yooka-laylee
  working_dir: /home/deck/Games/amazon/yooka-laylee/drive_c/game
game_slug: yooka-laylee
name: Yooka-Laylee
requires: null
script:
  files:

  [...]

  game:
    args: ''
    exe: $GAMEDIR/drive_c/game/YookaLaylee64.exe
    prefix: $GAMEDIR
    working_dir: $GAMEDIR/drive_c/game
  installer:
  - task:
      arch: win64
      prefix: /home/deck/Games/amazon/yooka-laylee
      wine_path: /home/deck/.var/app/net.lutris.Lutris/data/lutris/runners/wine/lutris-7.2-2-x86_64/bin/wine
  - mkdir: $GAMEDIR/drive_c/game

  [...]

  - move:

  [...]

  system: {}
  wine:
    version: lutris-7.2-2-x86_64
service: amazon
service_id: ...
slug: yooka-laylee
system: {}
variables: {}
version: Amazon Prime Gaming
wine:
  version: lutris-7.2-2-x86_64
year: null

Thanks! That's perfect. It looks like this can work pretty similarly to the Heroic integration. I really appreciate all the detail you've provided.

No problem, thank you for your hard work. I might try to implement it myself, as I wanted to look into Rust anyways.
I'm just a bit unsure about the "correct" way to handle the "roots", as Lutris creates one Wine prefix per game. Would you add all roots found in the *.yml files or just the $HOME/.var/app/net.lutris.Lutris/config/lutris/games/ folder as a root typed "Lutris"? And how would the restore process work?
I haven't really used Ludusavi yet, tbh.

Just the path to the games folder as a new Lutris root type. The problem with adding each prefix as its own root is that each prefix has to be checked for each game, which increases scan time exponentially. By having a single root and then only looking up the prefix matching the game, it can stay much more efficient.
The restore process doesn't know about roots. It just knows that the backup found a file at some path, and so it'll copy the data back to the exact same path (notwithstanding any configured redirects).

I might try to implement it myself, as I wanted to look into Rust anyways.

That would be great, if you're interested :) You could use src/heroic.rs as a basis for a new src/lutris.rs:

lutris::Lutris::scan would read the YAML files and store any necessary metadata, like the prefix paths
lutris::Lutris::scan would be used by gui::app::start_backup and cli::run, then passed into prelude::scan_game_for_backup so it can check the prefix
The new root type would be added to manifest::Store, and any default paths (e.g., ~/.var/app/net.lutris.Lutris/config/lutris/games) would be added to config::find_missing_roots

Yeah, I looked into it yesterday and I already implemented some stuff.
Root folder resolution works so far and functions as intended in the GUI.. this was a quick patch.
Sorry for not replying earlier, so your answer could have been less detailed.
I add the Lutris folder as root and try to read all *.yml files in a similar fashion to the Heroic Launcher. This still needs some work, but most of the logic is implemented.. I just have to get my head around some Rust specifics, never worked with it.

The restore process doesn't know about roots and so wouldn't need to change. It just knows that the backup found a file at some path, and so it'll copy the data back to the exact same path (notwithstanding any configured redirects).

Ah okay, I guess that's what #156 is about.

Sorry for not replying earlier, so your answer could have been less detailed.

No worries! Glad to hear it's going well so far.

EDIT: Lutris is only interesting for Linux.. so should it still be an option for other OSs?

It's an edge case, but I'm gonna say yes because I see some articles/videos about installing Lutris on Windows via WSL. I could also imagine a use case like if you have a full OS backup from a Linux system on an external hard drive and you want to extract just the game saves from it, then you could do that process on any OS.

The YAML for Amazon Games do provide a field for the games name, but I got some (older?) files on my pc that do not.
For example Uplay (Ubisoft Connect) does not for my installment of Far Cry 6.
There is only an id provided as launch argument. (7c193df7-ac6c-48ed-ba63-af6f012880a3 in this case.)
game:
  args: uplay://launch/7c193df7-ac6c-48ed-ba63-af6f012880a3
  exe: drive_c/Program Files (x86)/Ubisoft/Ubisoft Game Launcher/UbisoftConnect.exe
  prefix: /home/aede/Games/ubisoft-connect
system: {}
wine:
  version: lutris-7.2-2-x86_64

(This is the full file..)
I'm not sure, if PCGW holds this information.. but I do not think so.
This could help to recue some of the older entries savegames.
It seems a freshly installed game does provide the name in the YAML for Uplay.
I will install some additional games on different platforms for testing later.. I do not use Lutris that often. I just thought it would be cool, if it was supported here.

On the progress: Roots are detected and files get parsed and the official titles are found.. so everything should work out for the supported, newer files. Still need to actually test it though.

@Root-Core Any more progress on this? I'd be happy to help finish it off if you're busy with other things.

@mtkennerly I actually had to RMA my Steam Deck and I do not have a GPU right now.
I ordered three GPUs over the last weeks.. two got canceled. One is in limbo for over a week now..
I'm just done for the moment.
My files are on my main rig and I haven't had the time or energy to copy them over to my laptop.
I will finish it once the GPU arrives.

Oh, wow, that's rough. No rush; I hope you have better luck with the latest order 😅


[Feature Request]: Support custom TCP callback host

Currently, using python log4j-scan.py -u http://locahost --custom-dns-callback-host <IP_ADDRESS> provides payload:
[•] URL: http://locahost | PAYLOAD: ${jndi:ldap://locahost.<IP_ADDRESS>/uhjut64}

Using a DNS callback server is sometime not trivial on a corporate internal network (could depend of network zones, ...).
Having the capabilities to define a direct TCP host (which host a simple TCP receiver, logging any IP trying to connect) could be very useful.
This parameter could be named:  --custom-tcp-callback-host and provides the behavior:
python log4j-scan.py -u http://locahost --custom-tcp-callback-host <IP_ADDRESS>:80
...
[•] URL: http://locahost | PAYLOAD: ${jndi:ldap://<IP_ADDRESS>:80/uhjut64}

If considered as relevant, I can provide a PR and the Python receiver.

Reopen for merge in original repo.
Testable from https://github.com/axel3rd/log4j-scan


docs: [IAC-2497]: Update initialize backend doc with dynamo db example

Description

Update initialize backend doc with dynamo db example
JIRA

PRs must meet these requirements to be merged:

[x] Successful preview build.
[x] Code owner review.
[x] No merge conflicts.
[x] Release notes/new features docs: Feature/version released to at least one prod environment.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://66ec404cc7eb82059e3da34f--harness-developer.netlify.app


Allow using the noImplicitAny option in TypeScript

When using the library via npm, and if you have the noImplicitAny option enabled, you get compiler errors. This should fix that. See attached txt for the errors.
noImplicitAnyLog.txt
There were some methods in the .d.ts of the package that lacked return type declarations. I added those to the source, and updated the definitions. Also added the noImplicitAny option to the tsconfig.json file, and added a few missing type declarations to the source to tighten things up.
The transpiled json output remains the same, since the types are only handled by Typescript anyways.

I like how you cleaned up the code, however there are a few points I like to be addressed:

In the Topology interface you remove the ? from the exchanges, queues and bindings properties. They need to be optional, it is allowed to define an incomplete topology.
While I agree with the need to support projects that use noImplicitAny, I do not want to be forced to use it inside this project. So please remove the noImplicitAny from the tsconfig.json. As you have probably seen, the lib/amqp-ts.d.ts is maintained manually, I will make sure that future updates here will be noImplicitAny compatible.

1 - I'll look at that. I don't think I meant to do that! Sorry, ill clean that up ASAP.
2 - I can totally get behind that. It was turned on so I could locate all potential places where the types were missing and fill them in. I'll remove that as well.
Thanks for your feedback!

I went ahead and modified my .d.ts to make it match the organization of yours rather than the auto-generated one from tsc. It makes what changed much more obvious.


Invite form not showing

Please check this completely new and untouched deploy to Heroku.
https://invitetest.herokuapp.com/users/sparkzilla/edit
Login: user: sparkzilla, password: telescope
You can see the invite form is missing.
You can also login as admin, password: telescope. In the admin Account page the form is there.
I believe the problem is related to the number of allowed invites.

Ok, it seems I have a misunderstanding about the way it works. Apparently if I select "Require Invite to Post" then the invite system will work. But I want to anyone to be able to post even if they are not invited (if the just find the site) AND if they are invited. In other words, I want to use the invite system as a way to spread the word about the site, irrespective of being able to post.

That's not really what invites do, sorry. You could clone the invites package and modify it to add in this new "spread the word" feature though.


Improved relational client API: $nested queries

Is your feature request related to a problem? Please describe.
As described in e.g. #3104, the current Prisma client API is quite limited when it comes to more complex relational queries (i.e. you can just query exactly one level of nodes). As a fallback it's possible to use the $fragment API which however can feel a bit cumbersome and lacks better tooling to make it nice to use (e.g. auto-completion for the GraphQL query/fragment + auto-generated interfaces for the response type generics)
Describe the solution you'd like
I'm proposing to add the following API to allow for more complex, type-safe, relational queries using the given programming language instead of having to fallback to GraphQL. This allows you to additionally to the user also deeply fetch the user's friends and posts including their comments.
const dynamicResult: DynamicResult = await prisma
  .user('bobs-id')
  .$nested({ posts: { comments: true }, friends: true })

// assuming the following type definitions
type Post = {
  id: string
  title: string
  body: string
}

type Comment = {
  id: string
  text: string
}

type User = {
  id: string
  name: string
}

// Note: This is just here for the sake of demonstration and would be automatically
// derived based on conditional types in TS
type DynamicResult = {
  posts: (Post & { comments: Comment[] })[]
  friends: User[]
}

The idea is to mimic a GraphQL query in JS (or languages):

To express whether you fetch a field/relation you set it to true or false. Empty/nested objects are equivalent to specifying true.
Scalars true by default Similar to how the client automatically fetches all scalar fields, the queried relations inside the $nested query also contain all scalar values by default.
Relations false by default Also same as for the typically client behavior, relations are not fetched by default but can be fetched by setting the corresponding field to true or { ... }.
The response value is strongly typed given on which fields you're querying. In TS this can be derived automatically using conditional types. In other programming languages this needs to be handled via generics (+ optionally code generation).

The $nested API works both on the root level (e.g. prisma.$nested({ ... })) as well on a node level (e.g. prisma.users().$nested({ ... }). See full example:
const nestedResult = await prisma.$nested({
  users: {
    $args: { first: 100 },
    firstName: false,
    posts: {
      comments: true,
    },
    friends: true,
  },
})

One thing I'm still missing in this proposal compared to how prisma-binding works now is how to use the info parameter from the GraphQL resolver to automatically fetch only the relations that are used in the query.
query {
  events {
    id
    venue {
      id
    }
  }
}

The above would be a query I sent to my Apollo Server. In the resolver, I then would use prisma.events(). In this case, I also want it to fetch the venue relation.
However, if venue { id }  would not be a part of the query I don't want it to fetch that relation.
With your proposal I don't see how that situation would be fixed, but I could be wrong of course 😄. Or maybe this would be out of scope for the prisma-client and there should be a separate package that translates the info param to the $nested syntax in your proposal?

Thanks for bringing this up. Prisma client is GraphQL agnostic by design. However, we're currently working on some really exciting features/improvements that let you build GraphQL servers with a similar efficiency and minimal boilerplate while keeping all the benefits of Prisma clients.
More on this soon. Please let's keep this issue focussed on the proposed API design and related topics.

this is basically populate of mongoose, but much more powerful
the problem is how to make it fast
when we moved to GraphQL we just avoid populate as it makes harder to make it type safe

looking at objection I am a bit surprised they've got the same-I've never visited this corner or the docs, even when working daily with it: http://vincit.github.io/objection.js/#relationexpression-object-notation
so you're on the same track. Love that.
Just one question on dynamic relation nesting-are you sure you won't need:
{
  parent: {
    $recursive: 5
  }
}

or maybe
{
  parent: {
    $recursive: 'all'
  }
}

?

@capaj maybe a better name would be $depth?

The idea is to mimic a GraphQL query in JS (or languages):

@schickling Like that premise.

Any update on this? Is it planned for anytime soon?

@vjsingh I fear this FAQ entry is relevant


change ld client initialization success failure metric to gauge

counter metric does not work during startup, changing to gauge, which proved to be working.

@chris-ryan-square @staktrace @r3mariano could you pls help stamp this one?
I occasionally needed to make some small changes in this repo, but not entirely sure whats the right process to get misk PR reviewed.

Your best bet is contacting #misk-discuss for reviews.

presumably

yes nobody used it as it never worked


Reference level of label_col factor not respected

When comparing two groups, it is standard practice to set the levels of the grouping variable (factor) in order to control which group is being used as the reference.  Libra does not respect factor levels in the metadata label_col, meaning that it may or may not use the reference group specified by the user.  This is a problem because A) half the time it's not doing the comparison the user intends and B) in order to find out what comparison it actually is doing, the user has to inspect the expression levels of individual genes and compare them to the sign of the fold change in the Libra output.
A hacky way around this exists: if you're not getting the comparison you want, swap the reference level, even if that means setting it to the level that you explicitly don't want to be the reference.  This is clearly undesirable, though.

By default, Libra will refactor according to the character order of the labels. We understand this is non-optimal and we will push a fix soon where we can include factor_levels as an argument.


lake clean can delete files outside of its build directories

Prerequisites

[x] Check that your issue is not already filed.
[ ] Reduce the issue to a minimal, self-contained, reproducible test case. Avoid dependencies to mathlib4 or std4.

Description
lake clean seems to sometimes delete files other than its build output, including entire projects.
After running it a few times, it successively deleted a number of dependency directories (of Mathlib4 in my case) but then deleted the entire Mathlib4 repository I was working in.
Context
Two instances of this were reported on Zulip, a first one here and a second one I encountered myself here
Steps to Reproduce
It's not fully clear what causes lake to get in this situation. The first Zulip thread seems to suggest the issue is related to a faulty lakefile.olean file from an incorrect version of Lean.
Expected behavior: All build outputs are deleted, including lake-packages, build, and lakefile.olean. No other files are touched, and I'd expect lake to never attempt to write or modify any file other than its build output directories.
Actual behavior: The whole repository was deleted.
Versions
[Output of lean --version in the folder that the issue occured in]
⊙  lean --version                                                                                julian@Airm
Lean (version 4.2.0, Release)

This is rc4 to be clear, which I see doesn't appear in the output.
The other Zulip thread appears to have been on 4.2.0 rc3.
[OS version] macOS Sonoma 14.0
Additional Information
#2592 seems tangentially related.
Impact
Add :+1: to issues you consider important. If others are impacted by this issue, please ask them to add :+1: to it.

The problem here is likely that since rc4 reverted the ABI incompatibility with rc1 present in rc3, rc4 is now ABI incompatible with rc3 (in the same way).

With the proper disclaimer now on the rc4 release of how to safely update to it to avoid this issue, I am going to close this. Future ABI incompatibility issues should be solved by #2749. Going forward, features like #2741 and #2740 should hopefully be added in future to further avoid this popping up again.


Can you choose to make certain markets only?

Dear,
i have a question about this software, (i'm still pretty new to github and trying to figure this out. But i do have a good trading background.)
So let's say i think for example Biden might win the republican nomination and won't drop out. Then i would only want to provide liquidity on one side of those markets. Yes rep nominee market, no on dropout market. How i see it this bot will just trade like every single market and on both sides? I think it's much more interesting to like figure out which side would win then provide only liquidity on that side. Because market making only works well in markets that go long enough sideways, not with prediction markets where always one side will win.
So could there be any possibility to add a feature like this maybe?
Thank you and regards

you would have to make major changes to this library. Start brushing up on some Python...
Were you able to run it normally?


Compile it with Visual Studio 2017

Is it possible to compile the framework with VS 2017?
I was able to manage to generate the solution with this change
if(NOT MSVC)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -Wextra")
endif()

However, I get compile errors likes these:
3>LINK : fatal error LNK1104: cannot open file '..\common\Debug\FaceliftCommonLib.lib'

because the Module FaceliftCommonLib does not export anything. So no lib at all is created.
How can I (or your) fix this?

I am currently working on fixes for Windows. I am using MinGW. I will push some fixes very soon (hopefully today). It would be great if you could give it a try with Visual Studio as well.

I have pushed fixes into my fork : https://github.com/jacky309/facelift/commits/windowsfixes
MinGW (or probably CMake's minGW generator) adds a weird "lib" prefix to all DLLs. That causes the generated "qmldir" files to be invalid. If you edit those files (they are in the "imports" folder) and add the "lib" prefix to the "plugin" line, you should be fine. But it could very well be that you get a different behavior with Visual Studio.
It would be great if you could give it a try !

It doesn't work, as mentioned in my first message:

You need to add my patch in the main CMakeLists.txt
if(NOT MSVC)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -Wextra")
endif()

Otherwise it will not work for Visual Studio
However, you should avoid setting global flags at all, when writing modern cmake.
Use instead something like this:
target_compile_options(FaceliftModelLib  PRIVATE "-Wall -pedantic -Wextra")
2.
Then you need to export something in the libraries, otherwise no lib file will be created.
And you get the errors when linking the libraries.
3.
Thats how you can change the name of a library:
if (CMAKE_COMPILER_IS_GNUCXX)
        set_target_properties(FaceliftModelLib PROPERTIES OUTPUT_NAME FaceliftModel)
endif()

You should setup appveyor  to automatically compile the library with Visual Studio 2017 in CI.

I just compiled the target BUILD_ALL, then I get the compile errors

See my PR: #49

When you solved the *.lib issue, tell me so that I can give it a try again.
FYI: you need to export something, otherwise no lib file will be created

We are not working on that issue for now. Feel free to add an exported dummy symbol to that lib and try to get further.

I added a dummy export in FaceliftUtils.h
__declspec(dllexport) int dummy_value__;
Now I get another linker error:
   Creating library C:/SourceCode/facelift/BUILDS/Facelift_VS2017/examples/MyPackage/Debug/MyPackageInterface_types.lib and object C:/SourceCode/facelift/BUILDS/Facelift_VS2017/examples/MyPackage/Debug/MyPackageInterface_types.exp
9>MyPackageInterface_types_unity_1.obj : error LNK2001: unresolved external symbol "public: static struct QMetaObject const facelift::ModelQMLImplementationBase::staticMetaObject" (?staticMetaObject@ModelQMLImplementationBase@facelift@@2UQMetaObject@@B)
9>MyPackageInterface_types_unity_1.obj : error LNK2001: unresolved external symbol "public: virtual struct QMetaObject const * __cdecl facelift::ModelQMLImplementationBase::metaObject(void)const " (?metaObject@ModelQMLImplementationBase@facelift@@UEBAPEBUQMetaObject@@XZ)
9>MyPackageInterface_types_unity_1.obj : error LNK2019: unresolved external symbol "public: virtual void * __cdecl facelift::ModelQMLImplementationBase::qt_metacast(char const *)" (?qt_metacast@ModelQMLImplementationBase@facelift@@UEAAPEAXPEBD@Z) referenced in function "public: virtual void * __cdecl facelift::example::mypackage::MyInterfaceQMLImplementation::qt_metacast(char const *)" (?qt_metacast@MyInterfaceQMLImplementation@mypackage@example@facelift@@UEAAPEAXPEBD@Z)
9>MyPackageInterface_types_unity_1.obj : error LNK2019: unresolved external symbol "public: virtual int __cdecl facelift::ModelQMLImplementationBase::qt_metacall(enum QMetaObject::Call,int,void * *)" (?qt_metacall@ModelQMLImplementationBase@facelift@@UEAAHW4Call@QMetaObject@@HPEAPEAX@Z) referenced in function "public: virtual int __cdecl facelift::example::mypackage::MyInterfaceQMLImplementation::qt_metacall(enum QMetaObject::Call,int,void * *)" (?qt_metacall@MyInterfaceQMLImplementation@mypackage@example@facelift@@UEAAHW4Call@QMetaObject@@HPEAPEAX@Z)
9>MyPackageInterface_types_unity_1.obj : error LNK2019: unresolved external symbol "public: void __cdecl facelift::ModelQMLImplementationBase::readyChanged(void)" (?readyChanged@ModelQMLImplementationBase@facelift@@QEAAXXZ) referenced in function "public: void __cdecl facelift::ModelQMLImplementationBase::setInterface(class facelift::InterfaceBase *)" (?setInterface@ModelQMLImplementationBase@facelift@@QEAAXPEAVInterfaceBase@2@@Z)
9>MyPackageInterface_types_unity_1.obj : error LNK2001: unresolved external symbol "protected: static class QQmlEngine * facelift::QMLModelImplementationFrontendBase::s_engine" (?s_engine@QMLModelImplementationFrontendBase@facelift@@1PEAVQQmlEngine@@EA)
9>C:\SourceCode\facelift\BUILDS\Facelift_VS2017\bin\Debug\MyPackageInterface_types.dll : fatal error LNK1120: 6 unresolved externals
9>Done building project "MyPackageInterface_types.vcxproj" -- FAILED.a

What can I do here?
It seems to be that in MyInterface.h  for the class MyInterface is no moc code generated, or at least the file is not generated or added to the build.

@jacky309
Any idea?

I do not even see where that symbol is defined at all : "int facelift::value". Do you ?

ahh, this is coming from my export in FaceLiftUtils.h
#define FACELIFT_HELPER_DLL_IMPORT __declspec(dllimport)
#define FACELIFT_HELPER_DLL_EXPORT __declspec( dllexport )

FACELIFT_HELPER_DLL_EXPORT int value;

Okay, so I have to find another way to create the .lib files

@jacky309
And update here?

@jacky309
See my PR for my fix.
However, now I get following error:
21>TunerInterface_unity_1.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static void __cdecl tuner::ModuleIPC::registerQmlTypes(char const *,int,int)" (__imp_?registerQmlTypes@ModuleIPC@tuner@@SAXPEBDHH@Z) referenced in function "public: static void __cdecl tuner::Module::registerQmlTypes(char const *,int,int)" (?registerQmlTypes@Module@tuner@@SAXPEBDHH@Z)
21>C:\User\SourceCode\facelift\BUILDS\Facelift_VS2017\bin\Debug\TunerInterface.dll : fatal error LNK1120: 1 unresolved externals
20>MyPackageInterface_unity_1.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static void __cdecl facelift::example::mypackage::ModuleIPC::registerQmlTypes(char const *,int,int)" (__imp_?registerQmlTypes@ModuleIPC@mypackage@example@facelift@@SAXPEBDHH@Z) referenced in function "public: static void __cdecl facelift::example::mypackage::Module::registerQmlTypes(char const *,int,int)" (?registerQmlTypes@Module@mypackage@example@facelift@@SAXPEBDHH@Z)
20>C:\User\SourceCode\facelift\BUILDS\Facelift_VS2017\bin\Debug\MyPackageInterface.dll : fatal error LNK1120: 1 unresolved externals

How to fix this?

Some progress is done with that PR : https://github.com/Pelagicore/facelift/pull/81

I close it for now. Maybe another PR is needed for running the examples. Because with Visual Studio you can build multiple configurations (Debug, Release....)


[IOS] Research and safely handle Uncaught exceptions in IOS Tuvali

Tuvali IOS is not catching uncaught exception which may cause iOS app to crash (We have not seen this case in our testing yet and very unlikely to happen as swift is less exception prone.)
Find a way to catch uncaught exceptions at module level and safely close the connections

Thaanu is looking into this issue


Implement System Variables in Aggregation Expressions

I have encountered a problem with aggregation and $$ROOT on mongomock==3.13.0. Tested under python 3.6 (shipped with Ubuntu 18.04) and python 3.7.0
My usecase: I need to group documents by some field, and retrieve lists mapped to said field value (think nested comments mapped to parent ids). Listed below, I have written the query for this purpose. The code seems to work fine on pymongo and produces desired result. However, with mongomock it fails with KeyError - seems like mongomock thinks that $$ROOT is supposed to be a field.
Below is the smallest example I was able to reproduce this with:
import mongomock

def query(client, parent_ids):
    """
    Retrieve child documents for specified parents, mapped to parent id, i.e.:
    {
        1: [{'_id': 2, 'parent_id': 1],
        2: [{'_id': 4, 'parent_id': 2],
    }
    """
    match = {'$match': {'parent_id': {'$in': parent_ids}}}
    group = {
        '$group': {
            '_id': '$parent_id',
            'docs': {'$push': '$$ROOT'}
        }
    }
    aggregates = client.test.test.aggregate([match, group])
    children = {}
    for aggregate in aggregates:
        children[aggregate['_id']] = aggregate['docs']
    return children

def works_on_pymongo_but_fails_with_mongomock():
    parent = {'_id': 1}
    docs = [{'_id': 2, 'parent_id': 1},
            {'_id': 3, 'parent_id': 1}]
    client = mongomock.MongoClient()
    client.test.test.insert_many([parent] + docs)
    query(client, [parent['_id']])

if __name__ == '__main__':
    works_on_pymongo_but_fails_with_mongomock()

And here's stack trace:
  File "mongomock_test.py", line 36, in <module>
    works_on_pymongo_but_fails_with_mongomock()
  File "mongomock_test.py", line 32, in works_on_pymongo_but_fails_with_mongomock
    query(client, [parent['_id']])
  File "mongomock_test.py", line 19, in query
    aggregates = client.test.test.aggregate([match, group])
  File "/home/pc/venv/lib/python3.7/site-packages/mongomock/collection.py", line 1762, in aggregate
    doc_dict = _accumulate_group(v, group_list)
  File "/home/pc/venv/lib/python3.7/site-packages/mongomock/collection.py", line 1672, in _accumulate_group
    values = [key_getter(doc) for doc in group_list]
  File "/home/pc/venv/lib/python3.7/site-packages/mongomock/collection.py", line 1672, in <listcomp>
    values = [key_getter(doc) for doc in group_list]
  File "/home/pc/venv/lib/python3.7/site-packages/mongomock/aggregate.py", line 296, in parse_expression
    return Parser(doc_dict).parse(expression)
  File "/home/pc/venv/lib/python3.7/site-packages/mongomock/aggregate.py", line 108, in parse
    return self._parse_basic_expression(expression)
  File "/home/pc/venv/lib/python3.7/site-packages/mongomock/aggregate.py", line 139, in _parse_basic_expression
    return get_value(self._doc_dict)
  File "/home/pc/venv/lib/python3.7/site-packages/mongomock/helpers.py", line 243, in g
    return recurse_embedded(obj, item)
  File "/home/pc/venv/lib/python3.7/site-packages/mongomock/helpers.py", line 236, in recurse_embedded
    ret = ret[k]
KeyError: 'ROOT'

This is strange because I seem to remember using mongomock for similar queries before, and it worked.

Hi @NazarTopolsky , thanks for reporting. Currently mongomock does not implement system variables. The error message should be better than that and eventually we should implement this feature.
https://docs.mongodb.com/manual/reference/aggregation-variables/

@NazarTopolsky I'd appreciate if you could take a look at my code and review #464 before I merge it.


Release a xgboost version build with scala 2.12

We should release a xgboost version build with scala 2.12. Spark 3.0 now is default use scala 2.12.

https://mvnrepository.com/artifact/ml.dmlc/xgboost-jvm_2.12/1.0.0


Don't wait to detect a missing appserver.

This patch is to make appscale more responsive to detect a failed appserver.


[csrng] Define, fix, and verify cs_aes_halt

This PR:

Adds a minimal specification of CSRNG's behavior on the cs_aes_halt interface.
Fixes the acknowledge output of cs_aes_halt driven by CSRNG to be level instead of pulse.
Configures CSRNG's DV so that it does not deassert the request of cs_aes_halt after a single acknowledge cycle.
Adds assertions to CSRNG RTL to ensure its AES is only active while cs_aes_halt is not.

Tested locally with a full regression run of CSRNG. The added assertion never failed and all test results are in line with current nightly results.

Thanks for your feedback, @cindychip.

do we need to add any chip level test to cover this, or the block level assertion checks are enough?

Both CSRNG and Entropy Source block-level DV have agents to randomly requests/acknowledge the cs_aes_halt interface. With this PR (and #17943 for Entropy Source), both blocks have RTL assertions that ensure they correctly implement their side of the interface.
Top-level tests implicitly test this feature when they use the entropy complex; in particular the max power test should use both blocks intensively and concurrently. There currently is a top-level testpoint (chip_sw_entropy_src_cs_aes_halt) that would specifically test this feature, but Entropy Source has some limitations (see #17943). Those limitations will be covered by block-level assertions, but we think replicating these checks at the top level doesn't add value. So we plan to remove that TLT in #17951.
TL;DR: We're verifying this feature in both blocks with this PR and #17943 and remove the top-level testpoint in #17951.


perf: Make mempool update async from block.Commit (backport #3008)

First step to fixing #2925
PR'ing this to see if we have any test failures. Note that this is safe in the happy path, as Reap and CheckTx both share this same lock. The functionality behavior is that:

Full nodes and non-proposers timeout_prevote beginning should not block on updating the mempool
Block proposers get very slight increased concurrency before reaping their next block. (Should be significantly fixed in subsequent PR's in
Reap takes a lock on the mempool mutex, so there is no concurrency safety issues right now.
Mempool errors will not halt consensus, instead they just log an error and call mempool flush. I actually think this may be better behavior? If we want to preserve the old behavior, we can thread a generic "consensus halt error" channel perhaps?

I'm not sure how/where to best document this. Please also let me know if tests need creating. Seems like the create empty block tests sometimes hit failures, I'll investigate tmrw
Also please feel free to take over this PR, just thought I"d make it to help us with performance improvements. Happy to get this into an experimental release to test on mainnets.

[ ] Tests written/updated
[x] Changelog entry added in .changelog (we use unclog to manage our changelog)
[ ] Updated relevant documentation (docs/ or spec/) and code comments
[x] Title follows the Conventional Commits spec This is an automatic backport of pull request #3008 done by Mergify.

PR checklist

[ ] Tests written/updated
[ ] Changelog entry added in .changelog (we use unclog to manage our changelog)
[ ] Updated relevant documentation (docs/ or spec/) and code comments

seems cometbft still miss some cb to notify sdk when consensus failure occurs right?


Can't refactor note. Error Cannot read property 'forEach' of undefined"

Describe the bug
Error Message Cannot read property 'forEach' of undefined" on refactor
To Reproduce
Steps to reproduce the behavior:

Choose a note
Perform Refactor

Expected behavior
Note is refactored.
Desktop (please complete the following information):

OS: Windows 10
VSCodium: Version: 1.51.1
Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f
Date: 2020-11-12T10:30:36.566Z
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19042
Dendron 0.15.2

** Dendron Log file**
Refactor.log

In another instance with Dendron 0.15.1-alpha3 it works fine.
This is with VSCode: Version: 1.51.1 (user setup)
Commit: e5a624b788d92b8d34d1392e4c4d9789406efe8f
Date: 2020-11-10T23:34:32.027Z
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19042

it tunrs out the note I tried to refactor didn't have an id in the frontmatter. I had created it using the mobile GitJournal app. After running Dendron:doctor everything works.


how can I use it by cdn?

I want import it by cdn。

I don`t know is it right?

Hey, would you mind to share how you solved it, so I can include it in the documentation?

Hey, would you mind to share how you solved it, so I can include it in the documentation?

you can see Image above。fires image is my enter file，second image is vite.config.ts。last is use；

But you only consume vue via cdn, not vue3-openlayers don't you?

But you only consume vue via cdn, not vue3-openlayers don't you?

yes

But you only consume vue via cdn, not vue3-openlayers don't you?

you mean vue3-openlayers  contain vue？do`t need import Vue？


Added Game replay and Quit buttons to Pygame Dots & Boxes - Issue Number 105

Description
This repository contains a Pygame Dots & Boxes game that has been enhanced with replay and quit buttons. These buttons provide users with additional functionality to start a new game or exit the current game. This removes the extra usage of keyboard by players and thus allows to just click on the respective buttons instead of pressing the keys R and Q.
Changes Made : Fixes #105

Replay Button: Added a replay button below the game over message. This button allows users to start a new game after the current game ends. The replay button is displayed with the text "Replay" and has a blue color.

Quit Button: Added a quit button below the replay button. This button allows users to exit the game when clicked. The quit button is displayed with the text "Quit" and has a red color.

Changing Grid size: Changed the grid size to 400X400 i.e SCREEN_WIDTH & SCREEN_HEIGHT to 400 each respectively to ensure proper spacing and padding upon addition of 2 buttons.

Implementation Details

Defined rectangles for both the replay and quit buttons.
Drawn the buttons on the screen using the draw_button function.
Handled mouse click events for both buttons to trigger the corresponding actions (replaying or quitting the game) when clicked.

Testing

Tested the functionality of both buttons by clicking on them during the game over phase. Verified that the game either restarted or quit as expected based on the button clicked.

Note

This enhancement improves the user experience by providing clear options for restarting or quitting the game, making it more intuitive and user-friendly.

@shrawani21 please review it and merge the above PR. Thank you! Also add the labels of gssoc and the level to this PR and in the issue. I have been asking for that since I opened issue. Pls try to review the PR and the corresponding issue that got resolved. Thank you :)


1b datasources vizjson

We need a place to store the 1b datasources vizjson and a apikey secured endpoint for it.
cc @javisantana @zenitraM

Closed with #6154.


add cavaquinho

Hello,
thank you for creating such useful tool. I've added brazilian cavaquinho to the tunings list.

Thanks Matheus!


update action context middleware to account for other data in private_metadata

I think this looks okay. I'm still not entirely clear on how the subject is being nested. I would have preferred the subject is flattened before it's embedded in the button itself. For instance, it feels like we are convoluting something because we do even more unpacking of the metadata and subject here, where I thought the middleware would largely abstract that for you.
Is it because you need theproject_id here?
https://github.com/Netflix/dispatch/blob/master/src/dispatch/plugins/dispatch_slack/case/interactive.py#L591
In that case you already have the signal object so you'd be able to fetch it via signal.project.id.

I think this looks okay. I'm still not entirely clear on how the subject is being nested. I would have preferred the subject is flattened before it's embedded in the button itself. For instance, it feels like we are convoluting something because we do even more unpacking of the metadata and subject here, where I thought the middleware would largely abstract that for you.
Is it because you need theproject_id here? https://github.com/Netflix/dispatch/blob/master/src/dispatch/plugins/dispatch_slack/case/interactive.py#L591 In that case you already have the signal object so you'd be able to fetch it via signal.project.id.

This probably makes it even more confusing. But, the middleware change is actually to satisfy what user_middleware expects here:
        participant = participant_service.get_by_case_id_and_conversation_id(
            db_session=db_session, case_id=context["subject"].id, user_conversation_id=user_id
        )

We use user_middleware to populate creator here:
            new_filter = signal_service.create_signal_filter(
                db_session=db_session, creator=user, signal_filter_in=filter_in
            )

The subject within context isn't actually used in handle_snooze_submission_event. We could, but it's in the private_metadata as well:
def handle_snooze_submission_event(
    ack: Ack,
    body,
    client: WebClient,
    context: BoltContext,
    db_session: Session,
    user: DispatchUser,
) -> None:
    """Handle the submission event of the snooze modal.

    This function is executed when a user submits the snooze modal. It first
    sends an MFA push notification to the user to confirm the action. If the
    user accepts the MFA prompt, the function retrieves the relevant information
    from the form data and creates a new signal filter. The new filter is then
    added to the existing filters for the signal. Finally, the function updates
    the modal view to show the result of the operation.

    Args:
        ack (Ack): The acknowledgement function.
        body (dict): The request body.
        client (WebClient): The Slack API client.
        context (BoltContext): The context data.
        db_session (Session): The database session.
        user (DispatchUser): The Dispatch user who submitted the form.
    """
    metadata = json.loads(body["view"]["private_metadata"])
    subject = SubjectMetadata.parse_raw(metadata["subject"])

So the issue stems from the middleware (action_context_middleware) expecting subject to be the only value in private_metadata, but we also need to use private_metadata as plumbing for the form_data in this situation, and then user_middleware need the subject context (and in a specific way).
It's all fairly confusing to me, hopefully this helps come up with a way we can simplify here, maybe in a separate PR.

Thanks, that helps makes things clearer for me. My preference is that we are explicit in supporting the form data use case for private metadata. The only use case originally for private metadata was to get a messages/button's context via SubjectMeta, it seems we now have an additional use case for storing form-data state (in this case between modals). For this, we should introduce another model may be called FormData, and make sure that the middleware can handle it (or ignore it) as appropriate.

That helps a lot, I forgot we have a similar pattern for TaskMetadata. Current iteration should cover what you suggested.


Add alternative to Travis for public CI

Given the news lately, it would be good to have an alternative to Travis ready to go.

I can create a PR for azure pipelines config if there's interest in using that.

We would be interested! However, at the moment we're waiting on some Fastly internal processes to see if we can add additional CI tools to projects under our github org. So I can't promise I'd be able to merge it yet, or possibly at all, depending on what our platform & tooling teams decide our path forward is. I will give you a heads up when I have an answer. We really appreciate the offer :heart:

Sounds good. I'll give it a try. No worries if you can't merge it.

Github Actions has been working since #331


Where should the permitted_attributes method live?

It's not being picked up from the Administrate Admin controller.

Your can find the related thread over here https://github.com/thoughtbot/administrate/issues/990#issuecomment-339066788


llvmPackages_16: init

Description of changes
For x86_64-linux:

libunwind is not compiling
dependents of libunwind

For other archs: help me!
For review-only and further work.
Things done

Built on platform(s)

[ ] 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

[ ] Fits CONTRIBUTING.md.

The babel commit is on staging, so a rebase should get it in

we should stop copying the entire directory and make changes to it, thats not in the nix spirit. probably out of scope for this but something that should eventually be improved.

This is still being worked on, you can see what we are doing in the Compilers Team matrix. We will get to this eventually, no worries.

Thanks for the PR @RaitoBezarius! :)
IMO we should definitely cc the llvm team for completeness here (even though you already seem to be part of it :smile:): @dtzWill @ericson2314 @lovek323 @primeos @alyssais @raitobezarius @rrbutani @sternenseemann
Would be great if we could get this into a mergable state ASAP to test chromiumDev (M113 will become chromiumBeta in a few days and will be released on the 2nd of May so we don't have much time at all, unfortunately (given that we have to test Chromium, fix potential regressions, and backport LLVM 16 to NixOS 22.11, etc.)). IMO it'd be perfectly fine to mark a few "optional" packages as broken for now and fix them via additional PRs (I already used that approach in the past as I only had to add new versions for Chromium).

we should stop copying the entire directory and make changes to it, thats not in the nix spirit. probably out of scope for this but something that should eventually be improved.

Definitely out of scope for this PR!

This confuses me. What previous PR? You should be able to just rebase and force push without having to open a new PR.
PS: I like my old approach of having a dedicated commit to copy the files (e.g., llvmPackages_13: Copy from llvmPackages_git / https://github.com/NixOS/nixpkgs/pull/132643 / https://github.com/NixOS/nixpkgs/pull/162104) so that the other commits clearly show the relevant changes but IIRC that hasn't been done since then (and it also has its drawbacks so feel free to use a different approach).

Thanks for the PR @RaitoBezarius! :)
IMO we should definitely cc the llvm team for completeness here (even though you already seem to be part of it smile): @dtzWill @Ericson2314 @lovek323 @primeos @alyssais @RaitoBezarius @rrbutani @sternenseemann
Would be great if we could get this into a mergable state ASAP to test chromiumDev (M113 will become chromiumBeta in a few days and will be released on the 2nd of May so we don't have much time at all, unfortunately (given that we have to test Chromium, fix potential regressions, and backport LLVM 16 to NixOS 22.11, etc.)). IMO it'd be perfectly fine to mark a few "optional" packages as broken for now and fix them via additional PRs (I already used that approach in the past as I only had to add new versions for Chromium).

Let's try to do this :). With @alyssais and @rrbutani we are trying to reduce the differences between llvmPackages_15 and llvmPackages_git.

we should stop copying the entire directory and make changes to it, thats not in the nix spirit. probably out of scope for this but something that should eventually be improved.

Definitely out of scope for this PR!

This confuses me. What previous PR? You should be able to just rebase and force push without having to open a new PR.

I created a previous PR which almost mass pinged a lot of people. :)

PS: I like my old approach of having a dedicated commit to copy the files (e.g., llvmPackages_13: Copy from llvmPackages_git / #132643 / #162104) so that the other commits clearly show the relevant changes but IIRC that hasn't been done since then (and it also has its drawbacks so feel free to use a different approach).

Got it. :)

for gold plugin debuggers: 2390bb2 known commit breaking Gold (you need to bisect more starting from this bad rev).

libunwind is broken on armv7l-linux:
<......................................................>
libunwind> -- Build files have been written to: /build/libunwind-src-16.0.0/runtimes/build
libunwind> cmake: enabled parallel building
libunwind> cmake: enabled parallel installing
libunwind> building
libunwind> build flags: -j1
libunwind> [1/19] Building CXX object libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o
libunwind> FAILED: libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o
libunwind> /nix/store/b1imbh7gwvrbl18lk7sihj7a3smmz8j3-clang-wrapper-16.0.0/bin/clang++ -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LIBUNWIND_LINK_DL_LIB -D_LIBUNWIND_LINK_PTHREAD_LIB -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/build/libunwind-src-16.0.0/libunwind/include -fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -fdiagnostics-color -O3 -DNDEBUG -fPIC -Werror=return-type -W -Wall -Wchar-subscripts -Wconversion -Wmismatched-tags -Wmissing-braces -Wnewline-eof -Wno-unused-function -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wsign-conversion -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wunused-parameter -Wunused-variable -Wwrite-strings -Wundef -Wno-suggest-override -Wno-error -pedantic -funwind-tables -nostdinc++ -D_DEBUG -UNDEBUG -D_LIBUNWIND_IS_NATIVE_ONLY -fno-rtti -std=c++11  -fstrict-aliasing -fno-exceptions -fno-rtti -MD -MT libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o -MF libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o.d -o libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o -c /build/libunwind-src-16.0.0/libunwind/src/libunwind.cpp
libunwind> clang-16: warning: argument unused during compilation: '-rtlib=compiler-rt' [-Wunused-command-line-argument]
libunwind> In file included from /build/libunwind-src-16.0.0/libunwind/src/libunwind.cpp:12:
libunwind> /build/libunwind-src-16.0.0/libunwind/include/libunwind.h:19:10: fatal error: 'stddef.h' file not found
libunwind> #include <stddef.h>
libunwind>          ^~~~~~~~~~
libunwind> 1 error generated.
libunwind> ninja: build stopped: subcommand failed.
error: builder for '/nix/store/n6r57sdwkz06i52yxfhk78baf6y6wyj4-libunwind-16.0.0.drv' failed with exit code 1;

Full log

Would it be possible to introduce lld as default linker for the llvmPackages_16.stdenv as part of this? The LLVM stdenv has been unusable since like forever because LLVM-based projects expect lld (bitcode linking, thinLTO, different flags supported) and often won't build with other linkers. Workarounds exist, but it just seems so pointless to not have that stdenv use lld by default.

https://github.com/NixOS/nixpkgs/issues/142901
https://github.com/NixOS/nixpkgs/issues/213144
https://github.com/NixOS/nixpkgs/issues/214524

Would it be possible to introduce lld as default linker for the llvmPackages_16.stdenv as part of this? The LLVM stdenv has been unusable since like forever because LLVM-based projects expect lld (bitcode linking, thinLTO, different flags supported) and often won't build with other linkers. Workarounds exist, but it just seems so pointless to not have that stdenv use lld by default.

Hmm, I'm not expert enough to know the full extent / consequences of this, I would rather have @rrbutani or @alyssais weigh on this.

Would it be possible to introduce lld as default linker for the llvmPackages_16.stdenv as part of this?

@aaronmondal I'm definitely sympathetic to complaints about the llvmPackages stdenvs (at the least, it should be easier to get a stdenv with clang/llvm bintools) but unfortunately I don't think this PR is the right place to make this kind of change (for scope reasons and also because we'd want to mirror any change we make to the other llvmPackages_* sets which likely means targeting staging, etc, etc).
Like @RaitoBezarius I'm not confident I know all the factors at play. The only thing that strikes me as potentially problematic is that, as I understand it, lld support for some platforms is still somewhat incomplete (i.e. lld on macOS has improved a lot but it's still missing support for some less common ld64 flags IIRC). This may not actually matter though – I'm not sure how pervasively llvmPackages.stdenv is used in nixpkgs and at least some of the users of it (chrome, firefox) swap out bintools to use lld anyways.
I saw your comment on #142901 – that definitely is the right place for this discussion. I'll try to post some thoughts there later this week; at minimum I think it makes sense to offer a stdenv that has "platform" libcxx/compiler builtins/libc but LLVM cc/bintools even if we end up deciding not to make that llvmPackages.stdenv.

Would it be possible to introduce lld as default linker for the llvmPackages_16.stdenv as part of this?

The current behavior is intentional and it certainly should not be tied to LLVM version. As usual, having a separate attribute (in the spirit of the historical lldClang) is very much on the table, but in another place.
Why it isn't done yet is simply because it's a bit of a messy situation and a nightmare to name, since you can additionally offer a choice between using libc++ or libstdc++ and even if you are feeling adventurous libunwind/compiler-rt and libgcc. Consequently you get an explosion of possiblities that needs representing somehow.
Platforms and cross bootstrapping would be the ideal fit to represent such things, but our LLVM support there is not quite as advanced and convenient as it could be.

libunwind is broken on armv7l-linux too:
<......................................................>
libunwind> -- Build files have been written to: /build/libunwind-src-16.0.0/runtimes/build
libunwind> cmake: enabled parallel building
libunwind> cmake: enabled parallel installing
libunwind> building
libunwind> build flags: -j1
libunwind> [1/19] Building CXX object libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o
libunwind> FAILED: libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o
libunwind> /nix/store/b1imbh7gwvrbl18lk7sihj7a3smmz8j3-clang-wrapper-16.0.0/bin/clang++ -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LIBUNWIND_LINK_DL_LIB -D_LIBUNWIND_LINK_PTHREAD_LIB -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/build/libunwind-src-16.0.0/libunwind/include -fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -fdiagnostics-color -O3 -DNDEBUG -fPIC -Werror=return-type -W -Wall -Wchar-subscripts -Wconversion -Wmismatched-tags -Wmissing-braces -Wnewline-eof -Wno-unused-function -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wsign-conversion -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wunused-parameter -Wunused-variable -Wwrite-strings -Wundef -Wno-suggest-override -Wno-error -pedantic -funwind-tables -nostdinc++ -D_DEBUG -UNDEBUG -D_LIBUNWIND_IS_NATIVE_ONLY -fno-rtti -std=c++11  -fstrict-aliasing -fno-exceptions -fno-rtti -MD -MT libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o -MF libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o.d -o libunwind/src/CMakeFiles/unwind_shared_objects.dir/libunwind.cpp.o -c /build/libunwind-src-16.0.0/libunwind/src/libunwind.cpp
libunwind> clang-16: warning: argument unused during compilation: '-rtlib=compiler-rt' [-Wunused-command-line-argument]
libunwind> In file included from /build/libunwind-src-16.0.0/libunwind/src/libunwind.cpp:12:
libunwind> /build/libunwind-src-16.0.0/libunwind/include/libunwind.h:19:10: fatal error: 'stddef.h' file not found
libunwind> #include <stddef.h>
libunwind>          ^~~~~~~~~~
libunwind> 1 error generated.
libunwind> ninja: build stopped: subcommand failed.
error: builder for '/nix/store/n6r57sdwkz06i52yxfhk78baf6y6wyj4-libunwind-16.0.0.drv' failed with exit code 1;

Full log

Fairly certain this is the same issue I'm seeing on x86_64, too. I think it's just because the clang-lib include directory is now at lib/clang/16/include, not lib/clang/16.0.0/include, meaning the symlink in resource-root no longer points to the right place. I was able to get it to build with this:
diff --git a/pkgs/development/compilers/llvm/16/default.nix b/pkgs/development/compilers/llvm/16/default.nix
index 17074a37b2b..a7b6c18982e 100644
--- a/pkgs/development/compilers/llvm/16/default.nix
+++ b/pkgs/development/compilers/llvm/16/default.nix
@@ -102,10 +102,11 @@ in let

   tools = lib.makeExtensible (tools: let
     callPackage = newScope (tools // { inherit stdenv cmake ninja libxml2 python3 release_version version monorepoSrc buildLlvmTools; });
+    major = lib.versions.major release_version;
     mkExtraBuildCommands0 = cc: ''
       rsrc="$out/resource-root"
       mkdir "$rsrc"
-      ln -s "${cc.lib}/lib/clang/${release_version}/include" "$rsrc"
+      ln -s "${cc.lib}/lib/clang/${major}/include" "$rsrc"
       echo "-resource-dir=$rsrc" >> $out/nix-support/cc-cflags
     '';
     mkExtraBuildCommands = cc: mkExtraBuildCommands0 cc + ''

But I'm not sure whether that's actually the right solution.

I think it's just because the clang-lib include directory is now at lib/clang/16/include, not lib/clang/16.0.0/include,

But I'm not sure whether that's actually the right solution.

Yup, this is exactly right; this is a documented change in LLVM16.

Thank you everyone for your help, with this, LLVM16 is compiling fine on x86_64-linux.
Please by all means, test the latest revision now.
For aarch64-darwin, I see 2 test failures:
FAIL: LLVM :: ExecutionEngine/Interpreter/intrinsics.ll (24905 of 47137)
******************** TEST 'LLVM :: ExecutionEngine/Interpreter/intrinsics.ll' FAILED ********************
Script:
--
: 'RUN: at line 1';   /private/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/build/bin/lli -jit-kind=mcjit -O0 -force-interpreter < /private/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/test/ExecutionEngine/Interpreter/intrinsics.ll
--
Exit Code: 134

Command Output (stderr):
--
LLVM ERROR: Tried to execute an unknown external function: roundevenf
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /private/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/build/bin/lli -jit-kind=mcjit -O0 -force-interpreter
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0  libLLVM.dylib            0x000000010c4f56a0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 72
1  libLLVM.dylib            0x000000010c4f45a8 llvm::sys::RunSignalHandlers() + 128
2  libLLVM.dylib            0x000000010c4f5d24 SignalHandler(int) + 320
3  libsystem_platform.dylib 0x00000001ada002a4 _sigtramp + 56
4  libsystem_pthread.dylib  0x00000001ad9d1cec pthread_kill + 288
5  libsystem_c.dylib        0x00000001ad90b2c8 abort + 180
6  libLLVM.dylib            0x000000010c437f00 llvm::report_fatal_error(llvm::Twine const&, bool) + 468
7  libLLVM.dylib            0x000000010dea2d3c llvm::Interpreter::callExternalFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) + 4264
8  libLLVM.dylib            0x000000010de96f68 llvm::Interpreter::callFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) + 192
9  libLLVM.dylib            0x000000010de96e2c llvm::Interpreter::visitCallBase(llvm::CallBase&) + 396
10 libLLVM.dylib            0x000000010dea0c20 llvm::Interpreter::run() + 64
11 libLLVM.dylib            0x000000010dea4a7c llvm::Interpreter::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) + 60
12 libLLVM.dylib            0x000000010de7ebfc llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>>> const&, char const* const*) + 1044
13 lli                      0x0000000104f80fc4 main + 9284
14 dyld                     0x00000001ad6a7e50 start + 2544
/private/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/build/test/ExecutionEngine/Interpreter/Output/intrinsics.ll.script: line 2: 51722 Abort trap: 6           /private/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/build/bin/lli -jit-kind=mcjit -O0 -force-interpreter < /private/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/test/ExecutionEngine/Interpreter/intrinsics.ll

--

********************
FAIL: LLVM-Unit :: TargetParser/./TargetParserTests/11/12 (45775 of 47137)
******************** TEST 'LLVM-Unit :: TargetParser/./TargetParserTests/11/12' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/private/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/build/unittests/TargetParser/./TargetParserTests-LLVM-Unit-29877-11-12.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=12 GTEST_SHARD_INDEX=11 /private/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/build/unittests/TargetParser/./TargetParserTests
--

Script:
--
/private/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/build/unittests/TargetParser/./TargetParserTests --gtest_filter=HostTest.getMacOSHostVersion
--
/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/unittests/TargetParser/Host.cpp:397: Failure
Expected equality of these values:
  0
  RetCode
    Which is: -1
/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/unittests/TargetParser/Host.cpp:430: Failure
Expected equality of these values:
  runAndGetCommandOutput(SwVersPath, argv, Buffer, Size)
    Which is: false
  true

/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/unittests/TargetParser/Host.cpp:397
Expected equality of these values:
  0
  RetCode
    Which is: -1
/tmp/nix-build-llvm-16.0.1.drv-0/llvm-src-16.0.1/llvm/unittests/TargetParser/Host.cpp:430
Expected equality of these values:
  runAndGetCommandOutput(SwVersPath, argv, Buffer, Size)
    Which is: false
  true

********************
********************
Failed Tests (2):
  LLVM :: ExecutionEngine/Interpreter/intrinsics.ll
  LLVM-Unit :: TargetParser/./TargetParserTests/HostTest/getMacOSHostVersion

@primeos With this, we have a working LLVM16 for x86_64-linux if you want to run tests for Chromium M113.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2090

@RaitoBezarius thanks for the heads-up (and sorry for the delay - I was sick). I can built chromiumBeta (M113) with llvmPackages_16 from this PR and the VM test passes (which is quite a relief :smile:) so functionally it LGTM. Would be great if we could get this merged soon. Are there any blockers left?

@RaitoBezarius thanks for the heads-up (and sorry for the delay - I was sick). I can built chromiumBeta (M113) with llvmPackages_16 from this PR and the VM test passes (which is quite a relief smile) so functionally it LGTM. Would be great if we could get this merged soon. Are there any blockers left?

The idea was to have some common "helper" function to be involved once we finished ensuring that llvmPackages_15 and llvmPackages_git have almost zero delta in patches, etc.
cc @rrbutani @alyssais
I think we are almost there for the delta in patches. llvmPackages_git was bumped to llvmPackages_15.
Once we confirm that delta is zero, we can introduce the helper I guess, to reduce code duplication and onboard llvmPackages_16 as part of this helper with updated patches.

DO NOT MERGE : this is for review and further work only, as @rrbutani is working on introducing a common function between LLVM versions to reduce the duplication.

Chromium M113 got released yesterday and contains important security fixes.
LLVM 16 is required now so I'll merge this now. Sorry not sorry :P
We really need to have new LLVM versions in Nixpkgs much sooner... (https://github.com/llvm/llvm-project/releases/tag/llvmorg-16.0.0 is from 2023-03-18)

DO NOT MERGE : this is for review and further work only, as @rrbutani is working on introducing a common function between LLVM versions to reduce the duplication.

Chromium M113 got released yesterday and contains important security fixes. LLVM 16 is required now so I'll merge this now. Sorry not sorry :P We really need to have new LLVM versions in Nixpkgs much sooner... (https://github.com/llvm/llvm-project/releases/tag/llvmorg-16.0.0 is from 2023-03-18)

Obviously, for security measures, I definitely understand (and that's why I left it this way.), we wanted to race you before.
So, it's definitely okay IMHO.

Based on https://github.com/emscripten-core/emscripten/issues/18302, it may be that libc++ may have some kind of mismatch. Hopefully there is a way to get that to align for emscripten alone.

I also hit this error today for a C codebase using atomics. The header that I expect to be included in my toolchain is located at /nix/store/[hash]-clang-16.0.1-lib/lib/clang/16/include/stdatomic.h on my system. I'm also debugging this under the assumption that I have a config problem (using nixpkgs_cc_configure with Bazel), but just sharing since I was surprised to see someone else run into this.

@primeos @RaitoBezarius thanks for your efforts! Is this planned to be backported to 22.11 or do you aim for 23.05 already?

@RaitoBezarius thanks for understanding :) And of course thanks for this awesome PR that saved me a lot of work! <3
I wanted to write another comment last week but it looks like I somehow forgot to... :o At least I already mentioned the hard deadline in https://github.com/NixOS/nixpkgs/pull/223282#issuecomment-1491875784. But I also wanted to mention that it would be best to merge this as it is anyway since I need to backport LLVM 16 to 22.11 for Chromium (which would likely be way too risky with that common "helper" function). And merging this as it is shouldn't interfere with that common "helper" function as it basically only adds new files and we can simply delete all of pkgs/development/compilers/llvm/16/ once that abstraction is ready (might just have to consider a few additional patches that got commited in the meantime).
https://hydra.nixos.org/eval/1794582?filter=llvmPackages_16&compare=1794561&full= looks really good (no failures - I only tested Chromium and expected that some LLVM packages might still fail) so I'll try to give backporting a try today (if someone else wants to handle it or help that's of course welcome as well - it should just be as simple as possible / a straightforward backport to get it merged ASAP).

@primeos @RaitoBezarius thanks for your efforts! Is this planned to be backported to 22.11 or do you aim for 23.05 already?

Yes, I already mentioned it in https://github.com/NixOS/nixpkgs/pull/223282#issuecomment-1491875784 ;)

I had a bit of time just now so I already got around to preparing a backport: https://github.com/NixOS/nixpkgs/pull/230327
Hopefully I didn't mess anything up. If CI passes and it doesn't cause (mass)rebuilds it should be good to go.

@nedwill
The problem for me was the use of the llvm release_version -- the derivation was trying to include a directory at /16.0.1 while the actual location built by llvm 16 is just /16.

@willcohen Thanks for letting me know. I was having some trouble getting one of the documentation tests to pass but was able to work around it with a derivation that skipped checking the tests. Now that this is merged the binary package the original derivation is working great for me.


Tuning of hyperparameters

Want to try to tune the hyperparameters of the model to optimise the profit
Potential approaches: Bayesian, random search, etc?

#31