[Event Request] table 36 "Sales Header" - OnBeforeSetLocationCodeFromShipToAddr

Can we please get the following event?
procedure SetShipToCustomerAddressFieldsFromShipToAddr(ShipToAddr: Record "Ship-to Address")
var
    IsHandled: Boolean;
begin
    IsHandled := false;
    OnBeforeCopyShipToCustomerAddressFieldsFromShipToAddr(Rec, ShipToAddr, IsHandled);
    if IsHandled then
        exit;

    "Ship-to Name" := ShipToAddr.Name;
    "Ship-to Name 2" := ShipToAddr."Name 2";
    "Ship-to Address" := ShipToAddr.Address;
    "Ship-to Address 2" := ShipToAddr."Address 2";
    "Ship-to City" := ShipToAddr.City;
    "Ship-to Post Code" := ShipToAddr."Post Code";
    "Ship-to County" := ShipToAddr.County;
    Validate("Ship-to Country/Region Code", ShipToAddr."Country/Region Code");
    "Ship-to Contact" := ShipToAddr.Contact;

    if ShipToAddr."Location Code" <> '' then
        //+EVENT
        IsHandled := false;
        OnBeforeSetLocationCodeFromShipToAddr(Rec, ShipToAddr, IsHandled);
        if not IsHandled then
        //-EVENT
            Validate("Location Code", ShipToAddr."Location Code");
    "Shipping Agent Code" := ShipToAddr."Shipping Agent Code";
    "Shipping Agent Service Code" := ShipToAddr."Shipping Agent Service Code";
    if ShipToAddr."Tax Area Code" <> '' then
        "Tax Area Code" := ShipToAddr."Tax Area Code";
    "Tax Liable" := ShipToAddr."Tax Liable";

    OnAfterCopyShipToCustomerAddressFieldsFromShipToAddr(Rec, ShipToAddr);
end;

[IntegrationEvent(false, false)]
local procedure OnBeforeSetLocationCodeFromShipToAddr(var SalesHeader: Record "Sales Header"; ShipToAddr: Record "Ship-to Address"; var IsHandled: Boolean)
begin
end;

Hi,
There are few requests to avoid/replace validate location code. Is it ok for you to use existing event OnBeforeUpdateLocationCode?

Hi,
you can see my full explanation in the other issue.
https://github.com/microsoft/ALAppExtensions/issues/15497#issuecomment-1015133347
For this event request it could sufficient if the procedure UpdateLocationCode is replaced by a new overload that includes a parameter  CalledByFieldNo, that we know which Field Changes caused the Update of the location code.
[Obsolete('Replaced by UpdateLocationCode().', '20.0')]
procedure UpdateLocationCode(LocationCode: Code[10])
var
    IsHandled: Boolean;
begin
    //+CHANGE
    //-IsHandled := false;
    //-OnBeforeUpdateLocationCode(Rec, LocationCode, IsHandled);
    //-if not IsHandled then
    //-    Validate("Location Code", UserSetupMgt.GetLocation(0, LocationCode, "Responsibility Center"));
    UpdateLocationCode(LocationCode, 0);
    //-CHANGE
end;

procedure UpdateLocationCode(LocationCode: Code[10]; CalledByFieldNo: Integer)
var
    IsHandled: Boolean;
begin
    IsHandled := false;
    OnBeforeUpdateLocationCode(Rec, LocationCode, CalledByFieldNo, IsHandled); //NEW
    if not IsHandled then
        Validate("Location Code", UserSetupMgt.GetLocation(0, LocationCode, "Responsibility Center"));
end;
[IntegrationEvent(false, false)]
local procedure OnBeforeUpdateLocationCode(var SalesHeader: Record "Sales Header"; LocationCode: Code[10]; CalledByFieldNo: Integer; var IsHandled: Boolean)
begin
end;

Thanks for your feedback.
Can be solved by implementing the approach shown here:
https://github.com/microsoft/ALAppExtensions/issues/15497#issuecomment-1016349222


lack of error and helperText props makes this useless for forms

If user never touched the input, even if a field is required, no error message displays. this makes this library flawed. i can show error messages for other material-ui fields, but not date picker. you should provide error and helperText props so that we can override the displayed error message (or lack there of) as needed.

Check out the documentation of v4.0.0-alpha.8. You should find the required props to implement form validation. There is even an example in the docs.


Add standalone code generation support for the Rust Standard Library

A targeted solution to manage some minor discrepancies between the windows-sys definitions and those required by the Rust Standard Library. Ideally we can reduce and eventually eliminate these differences over time, particularly once raw-dylib is ubiquitous.
https://github.com/rust-lang/rust/pull/110152

Looks great! Just a couple of issues:

Functions need to be pub fn.
The standard library is currently checked with #![deny(fuzzy_provenance_casts)] which means ::core::ptr::invalid_mut needs to be used for invalid pointer values.

Also just a quality of life thing but the reason for grouping functions in the same extern block was because of how linking libraries works. Currently rustc will read all the link names and append them, in order, to the linker arguments. E.g.:
#[link(name = "kernel32")]
extern "system" {
    pub fn SetLastError(dwerrcode: WIN32_ERROR) -> ();
}
#[link(name = "ws2_32")]
extern "system" {
    pub fn WSACleanup() -> i32;
}
#[link(name = "kernel32")]
extern "system" {
    pub fn DeleteFileW(lpfilename: PCWSTR) -> BOOL;
}

In this example kernel32 gets added to the command line twice. In more complex situations this can lead to even more duplication. This is not the end of the world but it can make diagnostics very noisy. This used to be a lot worse but rustc does now do some deduplication: if the same library appears consecutively then it will be collapsed into one argument.

All the more reason to switch those handles to isize. 😜

Yeah tbh with my libstd hat off I don't really disagree. But with my libstd hat on there's enough controversy around it that I can't really push such a change through the standard library until there's some kind of consensus (or near enough to it).

Anyway, I've address the main feedback - do check that I got it right.

That's working great, thanks!

OK, so previously the bindings were sorted by metadata name (including namespace) for stability but now its further sorted by the type names that actually appear in the generated bindings (irrespective of namespace). This makes it a little more readable. The imports are further sorted by library name before function name, so that they should all be grouped together and appear first. They aren't quite collapsed into shared extern blocks. The challenge there is that that would have to further group by calling convention but hopefully this is enough to trigger the compiler's deduplication.

This is fantastic, thank you! I've now updated the std PR with the generated bindings. The imports are fine as they are.


[BUG] Raspberry Pi/Arm support

I would like to run this API on my pi, but have been unable to do so because the image this API is based on, only runs on x86.
I have managed to get it running on my pi by modifying the Dockerfile a little and copying a few (around 5) files from the https://github.com/tiangolo/uvicorn-gunicorn-docker project.
This would also reduce the project's dependance on external Docker images. Dependance could be bad if the owners disappear.
If this is something you'd be willing to support, let me know and I can make a PR.

diff --git a/Dockerfile b/Dockerfile
index 3f0cad6..1231591 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,5 +1,34 @@
-FROM tiangolo/uvicorn-gunicorn-fastapi:python3.8-slim
+# gunicorn image
+FROM python:3.8-slim as my_gunicorn

+RUN apt-get update \
+&& apt-get install gcc ffmpeg -y \
+&& apt-get clean
+
+RUN pip install --no-cache-dir "uvicorn[standard]" gunicorn
+
+COPY uvicorn-gunicorn-docker/docker-images/start.sh /start.sh
+RUN chmod +x /start.sh
+
+COPY uvicorn-gunicorn-docker/docker-images/gunicorn_conf.py /gunicorn_conf.py
+
+COPY uvicorn-gunicorn-docker/docker-images/start-reload.sh /start-reload.sh
+RUN chmod +x /start-reload.sh
+
+COPY uvicorn-gunicorn-docker/docker-images/app /app
+WORKDIR /app/
+
+ENV PYTHONPATH=/app
+
+EXPOSE 80
+
+# Run the start script, it will check for an /app/prestart.sh script (e.g. for migrations)
+# And then will start Gunicorn with Uvicorn
+CMD ["uvicorn-gunicorn-docker/docker-images/start.sh"]
+
+
+#FROM tiangolo/uvicorn-gunicorn-fastapi:python3.8-slim
+FROM my_gunicorn
 # RUN apt-get update \
 #     && apt-get install --yes --no-install-recommends \
 #         build-essential python-dev
@@ -13,4 +42,5 @@ COPY . /app/
 WORKDIR /app
 RUN pip install -r requirements.txt

-CMD ["uvicorn", "main:app", "--host", "<IP_ADDRESS>", "--port", "8000", "--reload"]
\ No newline at end of file
+CMD ["uvicorn", "main:app", "--host", "<IP_ADDRESS>", "--port", "8000", "--reload"]
+

@Sonejiit working on Apple Air M1 (arm), not only x86.

But I will be glad if it works for rpi, send your PR

I am running it also on my m1 macbook air with no problem, but if you open docker desktop it shows like this

just wondering if yours is also running in docker's compatibility mode

@Soneji yes

haha, thought so! ;p


Evolution spec does not show prefix like Regional form name

E.g. Perrserker displays Meowth instead Galarian Meowth in evolution spec.

#20 fixes this issue.


Refactor release-1.2 branch to reflect to the new changes?

Should we revamp the release-1.2 branch to comply with pipfile & pipfile.lock instead of requirements.in & requirements.txt in order to be supported by the weekly updates?
The python package versions should remain the same.  These changes should be moved under 2022d branch.
Or should we leave it as it is because many users use the images for a long time now?

Since that release is already used by the users it is under code freeze. This change should not be applied in an already release.


Fix the navbar structure

The navbar is currently wrapped in a div with z transform above the router element.
-restructuring of the sidebar and the router element required
-possibly wrapping the content area in the sidebar or an parent element and passing the shouldit as a prop

Can u please assign this issue to me as a GSSOC contributor.

Hi, my skills are aligned for resolving this issue, can you please assign me this issue as I am a gssoc contributor.

Fixed by @akashgreninja


[DOCFIX] Update Contributing-Getting-Started.md

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/11378/
Test PASSed.


feature: create a mock data script for db

feature: create a mock data script for db and alter post_picture colu…mn to add picture_index
Task: 8697882t7

Task linked: CU-8697882t7 Add mock data for db


Added footer blue-15 component

Added footer blue-15
Resolves issue #503
Here is a screenshot of the component

Good job @Nupoor10
Congrats 🎉, your PR got merged. To be eligible for the swags from ClueLess. Follow this steps.
Note that this repo is excluded from Hacktoberfest but this PR is still eligible for ClueLess Swags.

Star this repository. ⭐
SignIn / SignUp in [ClueLess Website](https://www.clueless.tech/) .
Go to profile section from the top right hand corner.

Comment your profile URL under this comment tagging the person who merged your PR.

That’s it. Follow the leaderboard !
And don’t forget to share your achievement with your friends.


[cli_config] First version

This is an initial version for package:cli_config.
The only class in the API is the Config class.
/// A hierarchical configuration object.
///
/// Configuration can be provided as commandline arguments, environment
/// variables and configuration files. This configuration object makes
/// these accessible with a uniform API.
///
/// Configuration can be provided in three ways:
/// 1. commandline argument defines as `-Dsome_key=some_value`,
/// 2. environment variables as `SOME_KEY=some_value`, and
/// 3. config files as JSON or YAML as `{'some_key': 'some_value'}`.
///
/// The default lookup behavior is that commandline argument defines take
/// precedence over environment variables, which take precedence over the
/// configuration file.
///
/// The config is hierarchical in nature, using `.` as the hierarchy separator
/// for lookup and commandline defines. The hierarchy should be materialized in
/// the JSON or YAML configuration file. For environment variables `__` is used
/// as hierarchy separator.
///
/// Hierarchical configuration can be provided in three ways:
/// 1. commandline argument defines as `-Dsome_key.some_nested_key=some_value`,
/// 2. environment variables as `SOME_KEY__SOME_NESTED_KEY=some_value`, and
/// 3. config files as JSON or YAML as
///    ```yaml
///    some_key:
///      some_nested_key:
///        some_value
///    ```
///
/// The config is opinionated on the format of the keys.
/// * Command-line argument keys should be lower-cased alphanumeric
///   characters or underscores, with `.` for hierarchy.
/// * Environment variables keys should be upper-cased alphanumeric
///    characters or underscores, with `__` for hierarchy.
/// * Config files keys should be lower-cased alphanumeric
///   characters or underscores.
///
/// In the API they are made available lower-cased and with underscores.
class Config { }

This PR is to solicit feedback on multiple levels.
Our format opinions for end users.
What do we accept as valid hierarchical identifers in YAML/JSON/CLI-defines/environment variables?
We prefer underscores in identifiers. (pubspec.yaml and jnigen.yaml do underscores, however ffigen.yaml dashes.) Should we consider something else?
What about hierarchy in environment variables where we cannot use .. Do we use __?
What syntax do we prefer for CLI defines? -Dkey.nested=value (typical define style)? Or --set key.nested=value (Helm style)? Or --key.nested=value (typical CLI style).
Programmable API for package authors
class Config {
  /// Lookup a list of paths in this config.
  ///
  /// If [combineAllConfigs] combines results from cli, environment, and
  /// config file. Otherwise, precedence rules apply.
  ///
  /// If provided, [splitCliPattern] splits cli defines.
  ///
  /// If provided, [splitEnvironmentPattern] splits environment values.
  ///
  /// If [resolveFileUri], resolves the paths in config file relative to the
  /// config file.
  List<Uri>? getOptionalPathList(
    String key, {
    bool combineAllConfigs = true,
    String? splitCliPattern,
    String? splitEnvironmentPattern,
    bool resolveFileUri = true,
  });

  // ...
 The getters define how to treat the values in the various "provider"s. For example whether to split the strings on a character (e.g. splitting PATH on :). The getters also define on whether to combine the values from the various providers or not.
The error flow for package authors
Currently, both creating a Config and failures on config values can throw FormatExceptions. A YAML file could have the wrong format, but also a required config key could be missing which also makes the config the wrong format.
Should we consider having a dedicated type of exception instead?
Implementation considerations.
Please do not yet review those, let's get the other concerns right first.

@lrhn your thoughts on our APIs are always appreciated!
@jakemac53 @natebosch @devoncarew Any other packages besides JNIgen and FFIgen that we should take a look at while deciding our opinion on the config formats? Do we have any other standards going on in our ecosystem?
cc @mkustermann

It's been quiet here. If there's anymore feedback, please let me know. Otherwise I'll go ahead and merge this.


Lock installed package version

With version 1.1.5 of apm a package gets updated even if it is compatible with a dependency of a new installed package,
It would be great if a package version can be locked and unlocked so that it will not get re-installed with a new version if it is still compatible,

Can you give me an example of what you mean?

com.distriqt.Application:6.8.2 has following dependencies:
"dependencies": [
    "com.distriqt.Core:6.4.3",
    "androidx.core:1.3.2"
  ],

but installing com.distriqt.Share:7.1.1 also updates the androidx.core to version 1.6.1 even the Share dependencies are compatible with version 1.3.2 of androidx.core:
  "dependencies": [
    "com.distriqt.Core:6.x.x",
    "androidx.core:1.x.x"
  ],

I'm currently investigating an issue with androidx.core:1.6.1 and would therefore keep the version 1.3.2 for my app.

The latest Share ANE is not compatible with androidx.core 1.3.2. 7.1.1 was incorrectly specifying 1.x.x but has been corrected in 7.1.2.
However I would expect it to install 1.3.2 in the above case as it's specifically mentioned in the dependencies list. I'll check into what's happening there. There may be some case I'm not recalling.
Also I believe you should be able to install the androidx.core package directly and that may "lock" the version for you. i.e. apm install androidx.core 1.3.2

I already tried to 'lock' androidx.core by installing version 1.3.2 manually, but nevertheless it gets updated by installing the com.distriqt.Share:7.1.1


Live Variable Watches

It would be nice to have the functionality to place variable watches directly in the code, just like it's possible in LightTable.
Most likely, this will require modifying the code that is sent to the kernel by adding a language specific call such as:
from IPython.display import display

n = 0
for x in xrange(300)
    n = x; display(n)  # watch on n should display [n = 200] for example

where the inline display is added before sending the code to the kernel. This is already possible manually. However instead of listing only the actual value of the variable, every single change is concatenated into a list.
This feature would also make it possible to change plots online as every change would be displayed automatically.

This would be awesome. My dream development environment actually looks a lot like the Chrome Dev Tools mid-debugging, with watch expressions, lists of the values of all variables in scope, and value-on-hover for variables in your code.
Watch expressions are a great first step towards that. I'd like to implement them in a language-agnostic way.
What about a panel on the side of the editor that, after every chunk of code you send to the kernel, reruns all its watch expressions and shows the results? So the flow would be:

Write a watch expression to rerun after every call (e.g. display(n))
Send some code to the kernel (e.g. n = n**2)
Kernel executes the code from 2. and sends back the result
Watch panel sends its snippets to be run
Kernel executes the watch expression and sends back the result
Watch panel displays the new value of your expression

It's not quite as good as having all the old values there too, but it could be implemented with no knowledge of the particular language and no parsing of the code, and with little overhead.
Then the interface would look something like this (potato quality) drawing.

Or maybe a smaller panel that doesn't take up a whole vertical column. Or something. We can figure that part out.

This sounds eerily like it could use the comms channel that the ipython widgets use.

Huh, I hadn't looked at that channel at all. Can we use it with updates to Hydrogen alone, or does it need kernels to play along?

This could also be used to debug functions/methods directly by placing a call with parameters on the panel where the result of every assignment is displayed below (maybe even the same line, just like Bret Victor has envisioned it).
I don't know if the panel is the best way to display plots or anything that is bigger than some small values. Any ideas?

Definitely useful for functions, plots, etc also. I would love having live plots of my data onscreen while I manipulate it.
I expect a few hundred pixels wide is enough to use the plots to keep tabs on what's going on. You probably wouldn't want a larger plot always on-screen. When it's the thing you're actively looking at, you can run it in the main editor (or maybe resize the pane bigger).
This is now a priority, and probably the next significant feature that I work on.

Sounds great, maybe this will cause some further ideas for interactive programming. I'd love to see that!

Here's a preview:

It still needs some testing, but I expect to release this within the next couple of days.

This is now available for testing on the v0.4.0 branch: https://github.com/willwhitney/hydrogen/pull/60
You can install this branch by running apm dev hydrogen, cding into the folder Atom clones it to, and running git checkout v0.4.0.
Anybody who tries this out, let me know what you think in a comment on the pull request!

you might want to have a look at user_expression, they are side execution request that can be inserted by the client that are excuted befor (or after?) user code, do not appear in history and are ment to convey side information to the frontend.
You can for example, ask for a list of variable to be sent back after each execution, as a json objet.
Typically that's how the qtconsole display the list of availlable magics in a menu. it requets a ls_magic --json as a user_expression, and use the result to populate the menu.

@Carreau that's a really good thought.
For the moment I'm going to stick with this implementation despite it being a little dodgier and semantically incorrect. One of my biggest priorities is maintaining compatibility with as many kernels as possible, and lots of them implement only the "critical path" of executing code and skip the bells and whistles that are in the spec but not required to make the Jupyter notebook work. Definitely a change to make down the line though.

I completely understand, and that's typically the kind of things that are underdocumented.
This is one of the reason we asked for some funding to ba able get the principal kernel and frontends authors in the same room for a couple of day and figure out theses things.

That would be great.
I also cannot recommend strongly enough having some certification or automatic suite of tests for kernels. 75% of the kernels I've seen (from e.g. https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages) are broken, incomplete, or not to spec in one respect or another, and many of them don't even work with the notebook frontend.
Having a certification or testing process which displays a warning to the user when they're on a dodgy kernel would encourage kernel devs to implement the spec more closely (and tell them where they're not). Right now it seems like "works with the notebook" is the de facto test suite, and all kinds of awful things get shipped as a result.

I also cannot recommend strongly enough having some certification or automatic suite of tests for kernels. 75% of the kernels I've seen (from e.g. https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages) are broken, incomplete, or not to spec in one respect or another, and many of them don't even work with the notebook frontend.

We are working on that :
https://github.com/jupyter/jupyter_kernel_test
Still a question fo documentation on how to run it.
Sometime it is also difficult to express all the test.
like adding 1 and one can be 1+1, (+ 1 1) or +(1,1) which make some test tricky.
But we should at least be able to test the protocol in some area.

Frankly I think it will just take a lot of per-language effort to get this off the ground, but it's extremely worth it.
I expect many kernel developers will need an extra push to run these tests and implement parts of the spec they aren't personally using. Something like a build status badge on the kernel's logo in the notebook (that all their users can see) might do the trick.

There is work on that too, a main page that list the kernels and their features. Having auto-testing kernels features to put badges was considered.
https://github.com/jupyter/jupyter.github.io/pull/7

Design issues aside, this would be a strong step. Especially if there was a really clear separation between "known good" kernels and "experimental" ones.

Shipped!


dataset labels

Thanks for your excellent work!
I want to know that how to download the labels about the dataset, such as phase label and step label for each frame.

For /TAPIR/outputs/data_annotations/psi-ava/fold1/annotations/train.csv, I wonder about the meaning of each column. Thanks!

Hi!
To have the labels for each frame is necessary to take the original annotations and extend the phases and steps along the frames during the interval of times that are given in the original file. We have these annotations processed for one frame each second.  We can share these files if that would work for you.
Regarding the columns in the file train.csv in the annotations folder, they are:
CASE,FRAME,ID_NUMBER,BOX_X1,BOX_Y1,BOX_X2,BOX_Y2,ACTION_1,ACTION_2,ACTION_3,INSTRUMENT,STEP,PHASE

Could you please share the annotation files with me? My email address is<EMAIL_ADDRESS>


find the stream leader the old way if nodes are not advertised

Provide a description of what has been changed
Checklist

[x] I have verified that my change is according to the deprecations & breaking changes policy
[x] Tests have been added
[x] Changelog has been updated and is aligned with our changelog requirements
[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #4524

/run-e2e jetstream_cluster

Unit test are failing, could you check them?
https://github.com/kedacore/keda/actions/runs/4878814964/jobs/8704797046#step:12:707

thanks @mfadhlika! - I'll try to get some time to give this a test on my system.

@JorTurFer I have updated the test

nice1, tested good on my system. 🎉 🎉 🎉

/run-e2e jetstream_cluster


[generate-format] improve tracing of Serde serialization

Motivation
We now have a tool to trace Serde (de)serialization and extract formats (#2867).
This PR makes our handwritten (de)serializers follow the Serde data model more closely, making sure to report Rust containers (e.g. HashValue) before serializing their content (e.g. as bytes).
This makes no difference for LCS but greatly improves the output of generate-format.

Before

BlockMetadata:
  STRUCT:
    - id: BYTES
    - timestamp_usecs: U64
    - previous_block_votes:
        MAP:
          KEY:
            TUPLEARRAY:
              CONTENT: U8
              SIZE: 16
          VALUE: BYTES
    - proposer:
        TUPLEARRAY:
          CONTENT: U8
          SIZE: 16

After

BlockMetadata:
  STRUCT:
    - id:
        TYPENAME: HashValue
    - timestamp_usecs: U64
    - previous_block_votes:
        MAP:
          KEY:
            TYPENAME: AccountAddress
          VALUE:
            TYPENAME: Ed25519Signature
    - proposer:
        TYPENAME: AccountAddress
...
HashValue:
  NEWTYPESTRUCT:
    SEQ: U8

Incidentally, I switched HashValue from Bytes to a sequence [u8]. This is the same representation in LCS anyway.
Note that the problem of serializing HashValue as a fixed size array rather than a sequence is a separate issue (#1307).
Test Plan
cargo x test -p libra-types
cargo run -p generate-format

Also tested with #3008 (DRAFT)

@bors-libra r=davidiw

:pushpin: Commit 31a237f has been approved by davidiw

@bors-libra r+

:bulb: This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: #2991

:pushpin: Commit 31a237f has been approved by thefallentree

:hourglass: Testing commit 31a237f9d5a6063fe41bf6043fe308c055b8aef4 with merge 2e674548415db746af63243ac6584f1df78960e1...

:broken_heart: Test failed - checks-circle_commit_workflow

:umbrella: The latest upstream changes (presumably 2a1dfe369025f362511f255b5af7c4b9a14dd9c2) made this pull request unmergeable. Please resolve the merge conflicts.

@bors-libra r=davidiw

:pushpin: Commit df142a5 has been approved by davidiw

:hourglass: Testing commit df142a544b796eee837d8a112f0b9b0af15e0348 with merge 9b08f7bcd53ec6d28c8382273641a668d1b80684...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: davidiw
Pushing 9b08f7bcd53ec6d28c8382273641a668d1b80684 to master...


Crash upon using filled waystone scroll

Made 2 scrolls, right-clicked a waystone to fill them, gave them to my friends, and they both crashed once they used them.

This is fixed in 3.0.1


Support string distance matching

To give higher confidence in results, by comparing text of license, rather than just matching on some keywords
Use the following module: https://github.com/NaturalNode/natural

Alternative modules include https://www.npmjs.com/package/fast-levenshtein

This was going to be very slow


Prevent handoff.ip to be local

Horrible things happen when the handoff IP is set to localhost, and with horrible things I mean that monsters are going to eat all the data when nodes are being removed or added o.O

Hi Heinz, thanks for the pull request, this is definitely something we've run into before :). See http://docs.basho.com/riak/latest/community/product-advisories/210-dataloss/
However, we can't completely forbid the handoff IP from ever being set to localhost, since we often run multiple nodes on the same machine during development and testing.
It would be great if you wanted to submit a patch that is more selective, which guards against handing off to ourselves, but does so without prohibiting local multi-node setups. I don't know if we can accept this patch as it stands, though.

I can see that this makes  testing a bit harder, however you can just as well use an machine local non <IP_ADDRESS> ip during tests. My personal take is that users not deleting their data outweighs not having to set an ip during tests.
I agree that a proper tests of 'not handoff to yourself' is the something that would improve the security, but even with that in place, forbidding users to set it to a most likely wrong value would seem like a good start.

create jira issue


Function list does not go to the right line if some code is folded

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Godot 3.0 aa5f519
Issue description:
If some code is folded, the list of functions below the script list doesn't go to the correct line, it goes to some lines below (I suspect it's the same amount as hidden lines).
Steps to reproduce:

Create a script
Add multiple functions
Fold some code
Click in a function from the list to go (below the folded code)

cc @ianb96

I think I found the issue. This method in script_editor_plugin.cpp sets the scroll_position of the editor to be the line number, but that's incorrect since some lines might be collapsed.
It seems to work well if we switch it to use goto_line() instead of set_edit_state(), but then the code gets unfolded (although that actually seems like useful behavior? If you're trying to jump to a function, then ostensibly you also want to see what's in it and/or edit it).


Static linking fixes on Darwin

A few related fixes for static linking on macOS:

Don't pass options like -platform_version, -force_load, etc. to the static linker
Don't use .swiftmodule files as static linker inputs
Don't pass -lto_library to the static linker, and only pass it to the dynamic linker if we're actually performing LTO

@swift-ci please test


HTML5Backend issues

Hi!
You can find demo here.
Source code.
I use react-dnd on my current project. My case is collapsing DragSource after 'beginDrag' and uncollapsing on 'endDrag' for easy usage elements reordering(sorting).

I faced with the problem, i can start drag just on first and half of second item.
I don't have this problem without collapsing. But i am sure it isn't connected with nested reorder.
Probably it related with dimensions calculations under hood.

I am having a similar issue... Are you getting this error in the console?  Uncaught TypeError: Cannot read property 'nodeName' of undefined


Add getOpenAPI3 to OpenAPI3 emitter

This function is useful when you want to work with the OpenAPI 3 directly, or don't want to write it to disk for some reason. In my case, I am going to be emitting clients with Kiota, and I want to handle writing the OpenAPI myself, and keep it as an internal implementation detail.

All changed packages have been documented.

You can try these changes at https://cadlplayground.z22.web.core.windows.net/prs/2950/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/prs/2950/


TOML parsing glitches concerning dotted keys

Description
The parsing of the TOML config file appears glitchy. Adding a setting to the config file fails (instead taking the default value) depending on whether I use the dotted key syntax (and where it is placed in the file).
I experienced this problem while attempting to configure a container registry mirror for AWS EKS nodes, using the most current containerd/cri mirror config syntax.
Steps to reproduce the issue
1. If I update /etc/containerd/config.toml to append (at the end) the line:
plugins."io.containerd.grpc.v1.cri".registry.config_path = "/etc/containerd/certs.d"

then it fails. According to containerd config dump the CRI registry config path instead remains set to "", which is the default value.
2. If I instead append:
[plugins."io.containerd.grpc.v1.cri".registry]
config_path = "/etc/containerd/certs.d"

then it succeeds.
3. Alternatively, if I use the dotted key syntax as per (1), but insert it earlier in the file (before all of the other tables, including the plugins."io.containerd.grpc.v1.cri" super-table, are defined) then it succeeds.
Describe the results you received and expected
I expected the dotted key syntax (1) to succeed. All valid TOML syntaxes should be equivalent.
What version of containerd are you using?
containerd github.com/containerd/containerd 1.6.6 10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1
Any other relevant information
My test was based from the latest AWS EKS AMI release (v20221112).
Show configuration if it is related to CRI plugin.
Here is my full config.toml for reference:
version = 2
root = "/var/lib/containerd"
state = "/run/containerd"

#plugins."io.containerd.grpc.v1.cri".registry.config_path = "/etc/containerd/certs.d"    # <----- 3 ok

[grpc]
address = "/run/containerd/containerd.sock"

[plugins."io.containerd.grpc.v1.cri".containerd]
default_runtime_name = "runc"

[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "<sanitised>"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v2"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true

[plugins."io.containerd.grpc.v1.cri".cni]
bin_dir = "/opt/cni/bin"
conf_dir = "/etc/cni/net.d"

plugins."io.containerd.grpc.v1.cri".registry.config_path = "/etc/containerd/certs.d"    # <----- 1 ignored

#[plugins."io.containerd.grpc.v1.cri".registry]                                         # <----- 2 ok
#config_path = "/etc/containerd/certs.d"                                                #

Hy
I looked into this. I'm not a TOML expert but I think this has something to do with how TOML defines tables. If you look at the TOML documentation it states that:

Dotted keys create and define a table for each key part before the last one, provided that such tables were not previously created.

And:

Since tables cannot be defined more than once, redefining such tables using a [table] header is not allowed. Likewise, using dotted keys to redefine tables already defined in [table] form is not allowed. The [table] form can, however, be used to define sub-tables within tables defined via dotted keys.

Also take a look at the last two example in https://toml.io/en/v1.0.0#table where the above is described.
I hope this helps you.


Defer removal of use_json_field=None until Wagtail 5.0

Removing it in 4.0 creates a problem for bakerydemo, since it makes it impossible to write a StreamField definition that works on both the current released version (2.16) and Wagtail main (4.0a0).

I solved this for wagtailmedia tests: https://github.com/torchbox/wagtailmedia/pull/156/files without too much fuss it seems


[Fixes #350] Add more filters for pdn

This fix https://github.com/geosolutions-it/nexus-geonode/issues/350

@meomancer
You're right, the API does seem to sometimes send back a status of 200.
When issuing a request with these headers (which the browser does not automatically add btw):
Range-Unit: items
Range: 0-0
Prefer: count=exact

This tells PostgREST to give back a response with the Content-Range header, which contains the total number of records, while at the same time asking to only be returned a single record in the response body.
I have checked your example URLs and indeed it seems you are right that sometimes the response has a status of 200. This seems to happen when the result of the filters is a single record - I guess it makes sense, since we are asking for one record back and there is only one, so it is not really a partial content response.
The refactored change seems right now, thanks :)

could you review this @giohappy?

@meomancer what aboout start and end date filters for GeoNode? #350 should be split into two issues, one for GeoNode and one for PDN. I don't see the one for GeoNode thoufh.

ok, I see that it was created in GeoNode and I already merged the PR :)
I've updated the title of https://github.com/GeoNode/geonode/issues/7880 to make it clear that it's only for the GeoNode harvester.
Sorry but I'm recovering all my work from the holidays.


[DO NOT MERGE] Adding mlflow.pytorch.save_state_dict and mlflow.pytorch.load_state_dict methods

Signed-off-by: Shrinath Suresh<EMAIL_ADDRESS>What changes are proposed in this pull request?
Adding support for saving the pytorch model's state dict.
How is this patch tested?
Tested both entire model and state dict version
Release Notes
Is this a user-facing change?

[x] No. You can skip the rest of this section.
[ ] Yes. Give a description of this change to be included in the release notes for MLflow users.

(Details in 1-2 sentences. You can just refer to another PR with a description if this PR is part of a larger change.)
What component(s), interfaces, languages, and integrations does this PR affect?
Components

[ ] area/artifacts: Artifact stores and artifact logging
[ ] area/build: Build and test infrastructure for MLflow
[ ] area/docs: MLflow documentation pages
[ ] area/examples: Example code
[ ] area/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registry
[ ] area/models: MLmodel format, model serialization/deserialization, flavors
[ ] area/projects: MLproject format, project running backends
[ ] area/scoring: Local serving, model deployment tools, spark UDFs
[ ] area/server-infra: MLflow server, JavaScript dev server
[ ] area/tracking: Tracking Service, tracking client APIs, autologging

Interface

[ ] area/uiux: Front-end, user experience, JavaScript, plotting
[ ] area/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Models
[ ] area/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registry
[ ] area/windows: Windows support

Language

[ ] language/r: R APIs and clients
[ ] language/java: Java APIs and clients
[ ] language/new: Proposals for new client languages

Integrations

[ ] integrations/azure: Azure and Azure ML integrations
[ ] integrations/sagemaker: SageMaker integrations
[ ] integrations/databricks: Databricks integrations

How should the PR be classified in the release notes? Choose one:

[ ] rn/breaking-change - The PR will be mentioned in the "Breaking Changes" section
[x] rn/none - No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" section
[ ] rn/feature - A new user-facing feature worth mentioning in the release notes
[ ] rn/bug-fix - A user-facing bug fix worth mentioning in the release notes
[ ] rn/documentation - A user-facing documentation change worth mentioning in the release notes

Raised an upstream PR . Closing this as duplicate.


Add docker support

The goals for this PR are

Add docker support
Automatic deployment to azure container services using Github actions
Building and uploading latest builds to Docker Hub

For now, the Dockerfile builds a development image. That will change only when this is ready for production.

[x] Build a production image using Docker
[x] Upload the image to Docker Hub
[x] Deploy the image to Azure Container services

The ACI-Deploy github action presently has a bug which makes dns-name-label a required property. This is the reason why I'm using the Azure CLI instead.
Will merge this as soon as I'm confident this won't break anything down the road.

Presently, there's only one workflow. Probably best to have two workflows: one for pushes on main and one for pull requests on main
The first one will test, build and deploy, while the second will only test.


documentation: cluster config doc needs updated for ciao-cli subcommands

https://clearlinux.org/documentation/ciao-cluster-setup.html includes reference to ciao-cli commands.  Since https://github.com/01org/ciao/pull/224 the ciao-cli command line has changed and is not backwards compatible.  The documentation in https://github.com/01org/ciao was changed, but the external docu has not been yet and needs done.

It's not just the sections on ciao-cli that need to be updated.  The configuration changes and the resulting changes to the command line arguments of the various components require updates as well.  The instructions given to run launcher simply won't work any more.

I'll open a separate issue for @obedmr to address the config changes in the doc

https://github.com/01org/ciao/issues/274 opened to track the other changes for configuration parameters

A PR is open for ciao documentation.

@obedmr working on configuration package integration changes

This is done, just waiting the documentation rebuild. It should happen by EOD


Is it possible to use Long/high Pass to switch sides ?

Hello, I've been experimenting with the env a lot lately, and I'm confused on how to perform a Long/High pass to switch sides.
From the docs and experimenting with the game I know it's possible to perform Long/High passes (action_long_pass and action_high_pass) but the power of the pass/ to who you are passing is determined based on the direction of the player and all that. But what I'm looking for is switching sides like we see in irl games.

Hi @houssemeddinebayoudha, what do you mean by "to switch sides"?
If you are asking about the way to select the target player, as you can see in the docs:

action_long_pass = 9, perform a long pass to the player on your team. Player to pass the ball to is auto-determined based on the movement direction.

So if you want to manually select the target player of the pass, you have to make changes to the engine.


"Selected rows/columns only" functions  don't work in Export

System information:

Operating system (distribution) and version Windows 10
DBeaver version 6.3.0 EE

Describe the problem you're observing:
"Selected rows/columns only" functions  don't work in Export
Steps to reproduce, if exist:

Open a table and highlight several cells
Open export Wizard from the table context menu
Apply "Selected rows only"  and "Selected columns only"
Finish export

Expected result:
Highlighted values are exported.
Actual result:
The table is exported completely.

Verified


services/horizon/internal: Fix ParseFloat bug in /fee_stats

PR Checklist
PR Structure

[x] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[x] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[x] This PR's title starts with name of package that is most changed in the PR, ex.
services/friendbot, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[x] This PR adds tests for the most critical parts of the new functionality or fixes.
[ ] I've updated any docs (developer docs, .md
files, etc... affected by this change). Take a look in the docs folder for a given service,
like this one.

Release planning

[ ] I've updated the relevant CHANGELOG (here for Horizon) if
needed with deprecations, added features, breaking changes, and DB schema changes.
[ ] I've decided if this PR requires a new major/minor version according to
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.

What
Fix ParseFloat bug in /fee_stats endpoint.
Close https://github.com/stellar/go/issues/2006
Why
operationfeestats.CurrentState() returns a struct with the following fields:
https://github.com/stellar/go/blob/release-horizon-v0.24.0/services/horizon/internal/operationfeestats/main.go#L14-L49
Before operationfeestats.SetState() is ever called, operationfeestats.CurrentState() would return the default empty struct which means LedgerCapacityUsage would be set to the empty string.
The previous code attempted to parse this string as float thereby causing the handler to fail. To fix this I check that LedgerCapacityUsage is not empty before parsing it.
Known limitations
[TODO or N/A]

@tamirms what changed in the force push? I think that's one of the things I dislike about our current use of force push, it's very hard to find out what has changed after one has reviewed the PR, we should create new commits which makes the PR easier to review and also helps for learning since we can figure what wrong before and how it was fixed.

@abuiles I fixed a typo in the comment:
// LedgerCapacityUsage is the empty string when operationfeestats has not had its state set
before it was
// LedgerCapacityUsage is the empty string when operationfeestats has not has its state set


Repository avatars

first variant of code from old work for gogs
add migration 87
add new option in app.ini
add en-US locale string
add new class in repository.less

For issue #694 and #5625

Should I commit also index.css?

@sergey-dryabzhinsky yes, please.

add new option in app.ini.sample and docs

Codecov Report

Merging #6986 into master will decrease coverage by 0.04%.
The diff coverage is 19.87%.

@@            Coverage Diff             @@
##           master    #6986      +/-   ##
==========================================
- Coverage   41.44%   41.39%   -0.05%
==========================================
  Files         441      442       +1
  Lines       59696    59857     +161
==========================================
+ Hits        24739    24776      +37
- Misses      31732    31855     +123
- Partials     3225     3226       +1

Impacted Files
Coverage Δ

models/migrations/migrations.go
1.52% <ø> (ø)
:arrow_up:

models/migrations/v87.go
0% <0%> (ø)

routers/repo/setting.go
9.42% <0%> (-0.65%)
:arrow_down:

modules/setting/setting.go
48.06% <100%> (+0.46%)
:arrow_up:

routers/routes/routes.go
82.91% <100%> (+0.23%)
:arrow_up:

models/repo.go
45.92% <19.75%> (-1.29%)
:arrow_down:

models/repo_list.go
72.08% <0%> (-1.02%)
:arrow_down:

modules/log/event.go
65.98% <0%> (+1.52%)
:arrow_up:

modules/log/colors_router.go
87.5% <0%> (+4.16%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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

Ready for review

Drone service fails build.
Seems like main repo for https://gitlab.com/strk/go-libravatar dead by now.

The avatars seem a bit large to me, any other opinons?

@NotAFile in header on a repository page?

Cleaner repository header template:

Any other suggestions?

@lunny @lafriks @techknowlogick Any resolutions on reviews?

I've just dismissed my review so I'm not blocking this PR anymore.

Also rewrite models.repo.DeleteAvatar - now it uses Session too.

@sergey-dryabzhinsky Thanks for your good job!!!

Yes, this looks great! Was going to review but looks like you have reviewers, and a few minor details to fix. This is definitely something my organization will find useful!

@richmahn same here.
I've tired to make war with bloated GitLab in my company.
So I decided to take an action.
Love to use gitea at home to manage my pet projects.
Now it will be even better.

When no repository avatar was assigned it will render an empty img tag in repository list.
<img class="ui avatar image" src="">

Really hyped for 1.9! Thanks, everyone! 👍

Really hyped for 1.9!

Definitely! To me 1.9 seems to be much larger than previous feature releases. 👍


Update bindings for io.js 3.0.0

Update to io.js 3.0.0, use nan 2.0
The code has been updated to meet
the requirements of the updated V8 engine
as provided by io.js.
In some cases additional EscapableHandleScope
has been provided.
SassValueWrapper<T>::New has been changed:
in case of instance construction via
the function call sass.types.Color(0,0,0)
(actually incorrect JavaScript...)
instead of new sass.types.Color(0,0,0)
the new part is no longer executed by
falling through. This should not be necessary
because the constructor is called by
the NewInstance call anyway.
This fixes the following error:
FATAL ERROR: v8::Object::SetAlignedPointerInInternalField() Internal field out of bounds

\o/

It looks like this change is ready now for wider testing and review.
The coverage is down by one line in index.js which is interesting, because we no longer throw errors
as bare strings. This can be the consequence of the change in the SassValueWrapper<T>::New
to what I now believe is the correct behaviour.
@matryo you might want to have a look at this (I put my comments inline).

Amazing work @saper. I've just come back from my trip. Testing this on OSX now.

Things look good on OSX. I'll give Windows a whirl and start prepping a new release.

@saper thanks again for your work here. Please let me know when you think this is ready to ship (after squashing the git history of cause ;) )
@kkoopa we really appreciated your help here!

@saper do you think you'll have to complete the revisions soon or should I fork this branch?

@saper do you think you'll have to complete the revisions soon or should I fork this branch?

Forking is always good :)
The good news is that I believe that currently the branch is correct as far as functionality goes,
we are just tidying up the nan-related things. And maybe
(should I say Nan::Maybe<>? :) making things nicer. That's why I dedicded to have separate
commits on top of the original patch - they are self-contained and all tests pass in between.
Should we accidentally break something (missing Nan::New somewhere or similar), it would be
easy to fix.
We definitely need more tests for SassTypes! Like https://github.com/sass/node-sass/pull/1058
and also I am uncomfortable with the fact that CLI testing discovers bugs in the JS/C++ bridge
https://github.com/sass/node-sass/issues/1053#issuecomment-128311740
We should have tests before @chriseppstein decided to use our lists or maps for anything
usefel! :)
Right now I am working on ->ToXXX() stuff, but probably I'll push some other low-hanging
fruit first before. I think we can move from ->ToXXX to typecasts in some cases.
So right now I'd like to do it like this:

push more easy nitpicks
push changes in scope handling where still needed
push ->ToXXX/typecase work

The first priority is to get into a state where we can ship a workable iojs 3.0.0 binary :)
Last I checked this worked with OSX. When you're comfortable with the state of iojs 3.0.0 support I'm keen to build some binaries, test it, and ship.
At which point there is no rush to get the v8 binding code cleaned up, and no versioning issues since this completely internal.
With the latest LibSass beta about to drop I'll need to update LibSass binding code as well.

I wasn't sure if https://github.com/sass/node-sass/pull/1058 was dependant on this PR. That's the only reason I haven't shipped it.

As for your final points regarding test. I completely agree. Custom functions, and by extension the Sass types are experimental features developed by a non-core developer. This is largely accountable for the lack of test general lack of attention.

On Tue, 11 Aug 2015, Michael Mifsud wrote:

With the latest LibSass beta about to drop I'll need to update LibSass binding code as well.

Like this? https://github.com/sass/node-sass/pull/1040
I think we should definitely do a release with io.js 3.0 but with libsass 3.2.5.
Otherwise it'll be difficult to quickly sort out which one broke what in the reports...

I think we should definitely do a release with io.js 3.0 but with libsass 3.2.5.

Totally agree. That'll be 3.1.0 when this is ready to go.

Like this? https://github.com/sass/node-sass/pull/1040

Nice I missed this.

Like this? https://github.com/sass/node-sass/pull/1040

Nice I missed this.

While here; do you think we should add io.js 2.x to the build
matrix?

While here; do you think we should add io.js 2.x to the build matrix?

Assuming you mean travis ci yes. Also iojs 1.x, and 1.0.x.. essentially anything we're currently building binaries for.

While here;

For the record you can get me our Slack pretty much anytime. If I'm not there I'll get back to when I am. I'm online there most of the day.

@saper code cosmetics aside is there any reason we can't ship this as is?

So, this is it, I think.
I have addressed almost all comments from @kkoopa (big thanks again!). In case I decided to go in the other direction - I have replied to the code review comment in this thread.
Every commit in this pull request is standalone and should be passing tests (bar whimsical AppVeyor behaviour), so I will not be squashing them. If we will find problems, I want to have one of those commits clearly identified.
I hope I will soon stop whispering <v8::Local<v8::Value>> in my dreams :)

:heart_eyes:

Looks like AppVeyor has some trouble installing node v0.10.40.

Thank you @saper, @xzyfer and @kkoopa <3 <3


Visual update of the contribution page, including some minor bug fixes

I made a visual update of the contribution page, updated the navbar links on every page to the right direction and fixed a minor bug on the contribution page.

Changes are live on the website and are working fine. I'm therefore merging my pull request without a review by @canreal/developers


Support for ios simulator

I'm trying to build OpenBLAS v0.3.28 for ios simulator with these script and environments:

macOS 12.7.6
Xcode 14.2
Clang 14.0
Build script:

(ios-cmake/ios.toolchain.cmake comes from this repo: https://github.com/leetal/ios-cmake)
cmake \
 -B "build" \
 -DDYNAMIC_ARCH=FALSE \
 -DC_LAPACK=ON \
 -DBUILD_TESTING=OFF \
 -DNOFORTRAN=ON \
 -DBUILD_RELAPACK=OFF \
 -DCMAKE_TOOLCHAIN_FILE="ios-cmake/ios.toolchain.cmake" \
 -DENABLE_VISIBILITY=ON \
 -DPLATFORM=SIMULATOR64 \
 -DTARGET=NEHALEM

And I encount this error:
[ 88%] Building ASM object kernel/CMakeFiles/kernel.dir/CMakeFiles/samax_k.S.o
/Users/momo/Desktop/Lib/OpenBLAS/kernel/x86_64/amax_sse.S:55:2: error: invalid instruction mnemonic 'prologue'
 PROLOGUE
 ^~~~~~~~
/Users/momo/Desktop/Lib/OpenBLAS/kernel/x86_64/amax_sse.S:56:2: error: invalid instruction mnemonic 'profcode'
 PROFCODE
 ^~~~~~~~
/Users/momo/Desktop/Lib/OpenBLAS/kernel/x86_64/amax_sse.S:475:2: error: invalid instruction mnemonic 'epilogue'
 EPILOGUE
 ^~~~~~~~
make[2]: *** [kernel/CMakeFiles/kernel.dir/CMakeFiles/samax_k.S.o] Error 1
make[1]: *** [kernel/CMakeFiles/kernel.dir/all] Error 2
make: *** [all] Error 2

In samax_k.S (and many other similar files), PROLOGUE, PROFCODE and EPILOGUE is not defined. This is because in build/config.h, the system info is detect as OS_IOS, and commom_x86_64.h can't handle this definition to generate proper PROLOGUE and other mnemonic.
To solve this, I handly change #define OS_IOS 1 in generated config.h to #define OS_DARWIN 1, and It seems to work fine. But I'm not familiar with assamble and not sure if there's any potential problem. I'm still trying to figure out how config.h is generated and adding support for it. Thanks a lot for any help or information.

Are you actually compiling on an IOS system or simulator ? I think cmake/system_check.cmake is simply getting the OS name from CMake's CMAKE_SYSTEM_NAME variable (and possibly nobody tried to compile OpenBLAS with CMake on IOS yet). Right on top of the file are a few lines that already convert CMake's "WINDOWS" into the "WINNT" that OpenBLAS uses internally, you could try if copying those right after the first "endif ()" already solves your problem:
if (${HOST_OS} STREQUAL "IOS")
  set(HOST_OS DARWIN)
endif ()

Are you actually compiling on an IOS system or simulator ? I think cmake/system_check.cmake is simply getting the OS name from CMake's CMAKE_SYSTEM_NAME variable (and possibly nobody tried to compile OpenBLAS with CMake on IOS yet). Right on top of the file are a few lines that already convert CMake's "WINDOWS" into the "WINNT" that OpenBLAS uses internally, you could try if copying those right after the first "endif ()" already solves your problem:
if (${HOST_OS} STREQUAL "IOS")
  set(HOST_OS DARWIN)
endif ()

This patch works for my problem, thansk a lot!
I'm compiling on MacOS for iOS simulator, so ios-cmake toolchain is trying to compile for iOS with x86_64 arch, and I think this is the problem's cause.


cosmic-randr: remove env substituteInPlace

Description of changes
It doesn't substitute anything.

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

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

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

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

[ ] Fits CONTRIBUTING.md.

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

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

2 packages built:

cosmic-randr
cosmic-settings


Update Pigweed 53f260084d0

Problem
Periodically update Pigweed.
Change overview
Update Pigweed

Updated RPC signature which has changed in Pigweed
Use pw_python_wheels instead of pw_mirror_tree

Testing
Built EFR, ESP & NRF (RPC and non-rpc variants), and efr32 unit test driver.

Fast tracking, given this is updating deps. However... still failing.

/rebase

/rebase


ValueReferencePair Error when initializing ApiClient

I had an AAS server running and it can be access for example under http://localhost:8080/api/v3.0/shells
I installed the client with pip install git+https://github.com/rwth-iat/aas-api-python-client.git and it installed version aas-api-python-client-1.0.0.
Connection could not be established:
In [4]: from aas_api_python_client import ApiClient, Configuration, AssetAdministration
   ...: ShellRepositoryAPIApi, SubmodelRepositoryAPIApi
In [5]: configuration = Configuration()
In [6]: configuration.host = "http://localhost:8080/api/v3.0"
In [7]: api_client = ApiClient(configuration=configuration)
ERROR:root:Failed to get return type of method _construct_value_list: name 'ValueReferencePair' is not defined

@ddatadive when did you install the client? I have fixed the bug yersterday with https://github.com/rwth-iat/aas-api-python-client/commit/ebe65b9b1833343944364f07385b71b12e01a27e

Unfortunately, i still have this error with ebe65b9b1833343944364f07385b71b12e01a27e.

It seems pip did actually not install the fixed version. Problem is solved.


Fix "mark unread" not updating participating count on notifications page

fixes #497
uses getUsername from utils and removes getUserName function present in mark-unread.js since it was not working because of DOM changes.

Thanks for fixing, @tanmayrajani :)


Different build locations between versions

Sometimes packages will change where they put their UMD build in the npm package between versions. For example, in version 16.0.0-alpha.6 of the react package they kept their UMD builds in the dist directory. But in version 16.0.0-alpha.7 they moved the build into a umd directory. Similarly, the three package moved their bundled files into the build directory between version 0.77.0 and version 0.77.1.
This means we need a way to dynamically resolve the unpkg URL based on the package version.
Perhaps we could do something like:
import semver from 'semver'

const resolve = (packageName, version) => {
  if (packageName === 'react') {
    if (semver.gte(version, '16.0.0-alpha.7')) {
      // return paths that begin with /umd
    } else {
      // return the /dist paths
    }
  }
}

What do you think?

I kind of knew about this limitation but didn't have a real example until now
What I'm planning to do:

unit tests:

query all available version of a specific module and test again it
have a daily build on travis, that way we will be notified when such issue happens with any modules

update modules.json to follow:

{
  "react": {
    "var": "React",
    "versions": {
      "<= 16.0.0-alpha.6": {
        "development": "...",
        "production": "..."
      },
      "^16.0.0-alpha.7": {
        "development": "...",
        "production": "..."
      }
    }
  }
}

Does that make sense? I just want to reduce moving parts as much as possible and make editing as easy as possible

Yes I think that's a great plan 👍


Fixed #75 when Highlither returns empty string

Applied basically the same "hack" shown in the issue here: https://github.com/skttl/umbraco-fulltextsearch8/issues/75 and removed the unused StringBuilder-variable.

LGTM :)


Logs not showing up in VS code

Debug logs are not showing up on VS code output window. It works fine while running the application from terminal though.

Hey @acveigas, you'll want to ensure you have your launch.json set to capture stdout. For example:
{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "env": {
            },
            "skipFiles": [
                "<node_internals>/**"
            ],
            "outputCapture": "std",    <-----------------------------
            "program": "${workspaceFolder}\\dist\\index.js",
            "preLaunchTask": "tsc: build - tsconfig.json",
            "outFiles": [
                "${workspaceFolder}/dist/**/*.js"
            ]
        }
    ]
}


Update content/pt/docs/concepts/cluster-administration/_index.md

Changes

Update content/pt/docs/concepts/cluster-administration/_index.md

Related to #13939

/lgtm
/label tide/merge-method-squash


soc/*adsp: Fix snippets linkage

The Intel and NXP adsp linker scripts (mostly evolved via cut/paste between themselves) never actually had support for linker "sections" snippets as e.g. needed for STRUCT_SECTION_ITERABLE() usage[1].  Add them in reasonably appropriate places (Intel doesn't really have a clean .rodata area, because of the way cache address munging works, so in fact they're adjacent there).
[1] Actually cAVS did have the include for ROM snippets, but it was in
the wrong place and dumped the symbols into unusable addresses at
the top of memory.

See https://github.com/thesofproject/sof/pull/9261 for the SOF PR that needs this

Actually, closing this.  It turns out that the SECTIONS snippets linkage is complicated on the intel_adsp devices because the cache/uncache flipping interacts with the fact that idtlist.ld is included in that snippet level, and it needs to link somewhere else.
Also there's a brand new ROM_SECTIONS snippet type from @pdgendt  that literally just merged last week in #71911 which will work great; I'll use that.


Create Demographic xenophobe

Really like this template Been looking for something that I can use for my website. Thanks

😄


error:: an illegal memory access was encountered

Hi,when i run this code with my own dataset,it errors as:
Use config:
{'CONST': {'DEVICE': '0', 'NUM_WORKERS': 0, 'N_INPUT_POINTS': 2048},
 'DATASET': {'TEST_DATASET': 'Completion3D', 'TRAIN_DATASET': 'Completion3D'},
 'DATASETS': {'COMPLETION3D': {'CATEGORY_FILE_PATH': './datasets/Completion3D.json',
                               'COMPLETE_POINTS_PATH': '/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/datasets/Completion3D/%s/gt/%s/%s.h5',
                               'PARTIAL_POINTS_PATH': '/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/datasets/Completion3D/%s/partial/%s/%s.h5'},
              'KITTI': {'BOUNDING_BOX_FILE_PATH': '/home/SENSETIME/xiehaozhe/Datasets/KITTI/bboxes/%s.txt',
                        'CATEGORY_FILE_PATH': './datasets/KITTI.json',
                        'PARTIAL_POINTS_PATH': '/home/SENSETIME/xiehaozhe/Datasets/KITTI/cars/%s.pcd'},
              'SHAPENET': {'CATEGORY_FILE_PATH': './datasets/ShapeNet.json',
                           'COMPLETE_POINTS_PATH': '/home/SENSETIME/xiehaozhe/Datasets/ShapeNet/ShapeNetCompletion/%s/complete/%s/%s.pcd',
                           'N_POINTS': 16384,
                           'N_RENDERINGS': 8,
                           'PARTIAL_POINTS_PATH': '/home/SENSETIME/xiehaozhe/Datasets/ShapeNet/ShapeNetCompletion/%s/partial/%s/%s/%02d.pcd'}},
 'DIR': {'OUT_PATH': './output'},
 'MEMCACHED': {'CLIENT_CONFIG': '/mnt/lustre/share/memcached_client/client.conf',
               'ENABLED': False,
               'LIBRARY_PATH': '/mnt/lustre/share/pymc/py3',
               'SERVER_CONFIG': '/mnt/lustre/share/memcached_client/server_list.conf'},
 'NETWORK': {'GRIDDING_LOSS_ALPHAS': [0.1],
             'GRIDDING_LOSS_SCALES': [128],
             'N_SAMPLING_POINTS': 2048},
 'TEST': {'METRIC_NAME': 'ChamferDistance'},
 'TRAIN': {'BATCH_SIZE': 1,
           'BETAS': [0.9, 0.999],
           'GAMMA': 0.5,
           'LEARNING_RATE': 0.0001,
           'LR_MILESTONES': [50],
           'N_EPOCHS': 150,
           'SAVE_FREQ': 25,
           'WEIGHT_DECAY': 0}}
[INFO] 2021-01-04 11:01:13,525 Collecting files of Taxonomy [ID=all, Name=Uncategorized Test Set]
[INFO] 2021-01-04 11:01:13,529 Collecting files of Taxonomy [ID=02691156, Name=classic]
[INFO] 2021-01-04 11:01:13,532 Collecting files of Taxonomy [ID=02933112, Name=other]
[INFO] 2021-01-04 11:01:13,533 Complete collecting files of the dataset. Total files: 104
[INFO] 2021-01-04 11:01:13,534 Collecting files of Taxonomy [ID=all, Name=Uncategorized Test Set]
[INFO] 2021-01-04 11:01:13,535 Collecting files of Taxonomy [ID=02691156, Name=classic]
[INFO] 2021-01-04 11:01:13,537 Collecting files of Taxonomy [ID=02933112, Name=other]
[INFO] 2021-01-04 11:01:13,538 Complete collecting files of the dataset. Total files: 14
[DEBUG] 2021-01-04 11:01:14,724 Parameters in GRNet: 76707626.
[INFO] 2021-01-04 11:01:19,336 [Epoch 1/150][Batch 1/104] BatchTime = 0.697 (s) DataTime = 0.049 (s) Losses = ['535.0128', '533.6913']
[INFO] 2021-01-04 11:01:19,450 [Epoch 1/150][Batch 2/104] BatchTime = 0.114 (s) DataTime = 0.020 (s) Losses = ['581.4405', '579.0204']
[INFO] 2021-01-04 11:01:19,598 [Epoch 1/150][Batch 3/104] BatchTime = 0.147 (s) DataTime = 0.055 (s) Losses = ['758.7496', '758.8049']
[INFO] 2021-01-04 11:01:19,695 [Epoch 1/150][Batch 4/104] BatchTime = 0.098 (s) DataTime = 0.006 (s) Losses = ['695.8061', '692.7615']
[INFO] 2021-01-04 11:01:19,793 [Epoch 1/150][Batch 5/104] BatchTime = 0.097 (s) DataTime = 0.006 (s) Losses = ['554.6122', '544.2510']
[INFO] 2021-01-04 11:01:19,931 [Epoch 1/150][Batch 6/104] BatchTime = 0.138 (s) DataTime = 0.044 (s) Losses = ['539.5575', '530.9702']
[INFO] 2021-01-04 11:01:20,071 [Epoch 1/150][Batch 7/104] BatchTime = 0.141 (s) DataTime = 0.048 (s) Losses = ['556.2327', '553.9484']
[INFO] 2021-01-04 11:01:20,171 [Epoch 1/150][Batch 8/104] BatchTime = 0.099 (s) DataTime = 0.006 (s) Losses = ['682.0801', '675.5230']
THCudaCheck FAIL file=/pytorch/aten/src/THC/THCCachingHostAllocator.cpp line=278 error=77 : an illegal memory access was encountered

Did you meet the issue before? Thanks for advance.

Full error report as:
THCudaCheck FAIL file=/pytorch/aten/src/THC/THCCachingHostAllocator.cpp line=278 error=77 : an illegal memory access was encountered
Traceback (most recent call last):
File "/home/yaogan_504/pycharm-community-2020.2.2/plugins/python-ce/helpers/pydev/pydevd.py", line 1448, in _exec
pydev_imports.execfile(file, globals, locals)  # execute the script
File "/home/yaogan_504/pycharm-community-2020.2.2/plugins/python-ce/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
exec(compile(contents+"\n", file, 'exec'), glob, loc)
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/runner.py", line 76, in
main()
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/runner.py", line 58, in main
train_net(cfg)
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/core/train.py", line 112, in train_net
sparse_ptcloud, dense_ptcloud = grnet(data)
File "/home/yaogan_504/anaconda3/lib/python3.7/site-packages/torch/nn/modules/module.py", line 532, in call
result = self.forward(*input, **kwargs)
File "/home/yaogan_504/anaconda3/lib/python3.7/site-packages/torch/nn/parallel/data_parallel.py", line 150, in forward
return self.module(*inputs[0], **kwargs[0])
File "/home/yaogan_504/anaconda3/lib/python3.7/site-packages/torch/nn/modules/module.py", line 532, in call
result = self.forward(*input, **kwargs)
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/models/grnet.py", line 138, in forward
sparse_cloud = self.point_sampling(sparse_cloud, partial_cloud)
File "/home/yaogan_504/anaconda3/lib/python3.7/site-packages/torch/nn/modules/module.py", line 532, in call
result = self.forward(*input, **kwargs)
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/models/grnet.py", line 21, in forward
pred_cloud = torch.cat([partial_cloud, pred_cloud], dim=1)
RuntimeError: cuda runtime error (77) : an illegal memory access was encountered at /pytorch/aten/src/THC/THCCachingHostAllocator.cpp:278

Full error report as:
THCudaCheck FAIL file=/pytorch/aten/src/THC/THCCachingHostAllocator.cpp line=278 error=77 : an illegal memory access was encountered
Traceback (most recent call last):
File "/home/yaogan_504/pycharm-community-2020.2.2/plugins/python-ce/helpers/pydev/pydevd.py", line 1448, in _exec
pydev_imports.execfile(file, globals, locals)  # execute the script
File "/home/yaogan_504/pycharm-community-2020.2.2/plugins/python-ce/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
exec(compile(contents+"\n", file, 'exec'), glob, loc)
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/runner.py", line 76, in
main()
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/runner.py", line 58, in main
train_net(cfg)
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/core/train.py", line 112, in train_net
sparse_ptcloud, dense_ptcloud = grnet(data)
File "/home/yaogan_504/anaconda3/lib/python3.7/site-packages/torch/nn/modules/module.py", line 532, in call
result = self.forward(*input, **kwargs)
File "/home/yaogan_504/anaconda3/lib/python3.7/site-packages/torch/nn/parallel/data_parallel.py", line 150, in forward
return self.module(*inputs[0], **kwargs[0])
File "/home/yaogan_504/anaconda3/lib/python3.7/site-packages/torch/nn/modules/module.py", line 532, in call
result = self.forward(*input, **kwargs)
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/models/grnet.py", line 138, in forward
sparse_cloud = self.point_sampling(sparse_cloud, partial_cloud)
File "/home/yaogan_504/anaconda3/lib/python3.7/site-packages/torch/nn/modules/module.py", line 532, in call
result = self.forward(*input, **kwargs)
File "/media/yaogan_504/5E4006134005F297/linhemin/GRNet-master/models/grnet.py", line 21, in forward
pred_cloud = torch.cat([partial_cloud, pred_cloud], dim=1)
RuntimeError: cuda runtime error (77) : an illegal memory access was encountered at /pytorch/aten/src/THC/THCCachingHostAllocator.cpp:278

I've never met the issue before.
There are no other users reporting similar issues.
How about the ShapeNet dataset?

I've never met the issue before.
There are no other users reporting similar issues.
How about the ShapeNet dataset?

hi @hzxie
I also meet the same error. RuntimeError: CUDA error: an illegal memory access was encountered
Here is something may be helpful and may be something of feature sampling has error?

and it reports the "point features" has NaN is True.
tensor(True, device='cuda:0') =================point features after feature sample=================
Looking for your reply.
Best

@yjcaimeow
Maybe the coordinates of the points in the sparse_cloud out of the range (-1 , 1).

@hzxie
I check the range of sparse_cloud and it is in [-1, 1]. The sparse cloud is get from the gridding_rev operation.
I also try to *0.5. The same error also exist. :(

hi, @lin1061991611 Maybe your extensions are complied with a not corresponding version of cuda or cudnn? I've met this issue with a tensorflow model once.

has anyone solved this issue? I'm using pytorch=1.4.0, cuda=10.1 with a fresh conda environment. Still getting this error.

has anyone solved this issue? I'm using pytorch=1.4.0, cuda=10.1 with a fresh conda environment. Still getting this error.

I think this is because its extension "griding". Its  output tensors refuse to be readed, even if get printed, or refered to a specific GPU device.

Has anyone solved this issue? I'm using pytorch=1.8.1+cu111  with a fresh conda environment. Still getting this error.

I found the reason for my problem because the training data was not normalized.

I also meet the same problem,. when I use my own dataset to interfece, the program stops here：
class GriddingFunction(torch.autograd.Function):
    @staticmethod
    def forward(ctx, scale, ptcloud):
        grid, grid_pt_weights, grid_pt_indexes = gridding.forward(-scale, scale - 1, -scale, scale - 1, -scale,
                                                                  scale - 1, ptcloud)

the original input to the GriddingFunction( that is：gridding.forward(...)) is:

partial_cloud.size:  torch.Size([1, 2048, 3])
partial_cloud coordinate:  tensor([[[ 95.9131, -43.8667, 407.3000],
[  6.2308,  -5.8511, 400.2000],
[ 93.6227, -41.6913, 406.4000],
...,
[ 40.1768,   4.3794, 399.9000],
[ 76.5817,  -5.4377, 399.9000],
[ 56.0437, -37.4217, 396.4000]]], device='cuda:0')

but I saw the reply from upstairs， thought it was the lack of normalized. Then I normalized the partial_cloud, input the GriddingFunction( that is：gridding.forward(...)) , BUT still not worked.

normalized_partial_cloud:  tensor([[[ 0.8058, -0.2408, -0.2035],
[-0.9362,  0.6257, -0.6163],
[ 0.7613, -0.1912, -0.2558],
...,
[-0.2768,  0.8588, -0.6337],
[ 0.4303,  0.6351, -0.6337],
[ 0.0314, -0.0939, -0.8372]]], device='cuda:0')

I try to print relative information like:
        print("grid: ", grid)
        print("grid_pt_weights: ", grid_pt_weights)
        print("grid_pt_indexes: ", grid_pt_indexes)

But before printing this the program has reported an error:

torch.Size([1, 262144])
torch.Size([1, 2048, 8, 3])
torch.Size([1, 2048, 8])
THCudaCheck FAIL file=/pytorch/aten/src/THC/THCReduceAll.cuh line=327 error=700 : an illegal memory access was encountered
grid:  Traceback (most recent call last):
File "runner.py", line 77, in
main()
File "runner.py", line 68, in main
inference_net(cfg)
File "/root/autodl-tmp/GRNet/core/inference.py", line 59, in inference_net
sparse_ptcloud, dense_ptcloud = grnet(data)
File "/root/miniconda3/lib/python3.8/site-packages/torch/nn/modules/module.py", line 550, in call
result = self.forward(*input, **kwargs)
File "/root/miniconda3/lib/python3.8/site-packages/torch/nn/parallel/data_parallel.py", line 153, in forward
return self.module(*inputs[0], **kwargs[0])
File "/root/miniconda3/lib/python3.8/site-packages/torch/nn/modules/module.py", line 550, in call
result = self.forward(*input, **kwargs)
File "/root/autodl-tmp/GRNet/models/grnet.py", line 125, in forward
pt_features_64_l = self.gridding(normalized_partial_cloud).view(-1, 1, 64, 64, 64)
File "/root/miniconda3/lib/python3.8/site-packages/torch/nn/modules/module.py", line 550, in call
result = self.forward(*input, **kwargs)
File "/root/autodl-tmp/GRNet/extensions/gridding/init.py", line 52, in forward
grids.append(GriddingFunction.apply(self.scale, p))
File "/root/autodl-tmp/GRNet/extensions/gridding/init.py", line 23, in forward
print("grid: ", grid)
File "/root/miniconda3/lib/python3.8/site-packages/torch/tensor.py", line 162, in repr
return torch._tensor_str._str(self)
File "/root/miniconda3/lib/python3.8/site-packages/torch/_tensor_str.py", line 315, in _str
tensor_str = _tensor_str(self, indent)
File "/root/miniconda3/lib/python3.8/site-packages/torch/_tensor_str.py", line 213, in _tensor_str
formatter = _Formatter(get_summarized_data(self) if summarize else self)
File "/root/miniconda3/lib/python3.8/site-packages/torch/_tensor_str.py", line 88, in init
nonzero_finite_vals = torch.masked_select(tensor_view, torch.isfinite(tensor_view) & tensor_view.ne(0))
RuntimeError: cuda runtime error (700) : an illegal memory access was encountered at /pytorch/aten/src/THC/THCReduceAll.cuh:327

How can I fix this? Please advise, thank you.


Introduce support for 'gpt-4-1106-preview' model and dynamic token limit calculation

PR Type:
Enhancement

PR Description:

Added support for the 'gpt-4-1106-preview' model with a token limit of 128,000.
Implemented a new function get_max_tokens to dynamically calculate the maximum number of tokens based on model capabilities and configuration limits.
Updated various parts of the code to use the new get_max_tokens function instead of the static MAX_TOKENS dictionary.
Adjusted the configuration.toml to include a new max_model_tokens setting to allow limiting the number of tokens used, regardless of the model's maximum.

PR Main Files Walkthrough:
 files:

pr_agent/algo/__init__.py: Added 'gpt-4-1106-preview' model with a token limit of 128,000 to the MAX_TOKENS dictionary.
pr_agent/algo/utils.py: Introduced the get_max_tokens function that returns the maximum number of tokens for a given model, considering the max_model_tokens setting from the configuration.
pr_agent/algo/pr_processing.py: Replaced static MAX_TOKENS dictionary usage with the get_max_tokens function to dynamically calculate token limits during PR processing.
pr_agent/tools/pr_similar_issue.py: Updated to use get_max_tokens instead of MAX_TOKENS for token count checks when processing issues.
pr_agent/settings/configuration.toml: Added a new max_model_tokens setting to allow configuration of a maximum token limit for models.

Preparing PR description...

Preparing review...

PR Analysis

🎯 Main theme: Introduction of support for a new GPT-4 model and dynamic token limit calculation.
📝 PR summary: This PR adds support for the 'gpt-4-1106-preview' model with a token limit of 128,000 and implements a function to dynamically calculate token limits. It updates the codebase to use this new function and adds a configuration option to set a maximum token limit.
📌 Type of PR: Enhancement
🧪 Relevant tests added: No
⏱ Estimated effort to review [1-5]: 3, because the PR involves understanding the token calculation logic and ensuring that the new dynamic token limit calculation is correctly integrated across multiple files.
🔒 Security concerns: No security concerns found

PR Feedback

💡 General suggestions: The PR introduces a significant enhancement by adding support for a new model and improving the flexibility of token limit calculations. It is important to ensure that the new get_max_tokens function is robust and that all parts of the code that previously relied on static token limits are updated accordingly. Additionally, it would be beneficial to include tests to verify the behavior of the new function, especially since token limits can be a critical part of the system's functionality.

 🤖 Code feedback:

relevant file: pr_agent/algo/utils.py
suggestion: Consider adding a debug log when the token limit is set by the configuration rather than the model's default to aid in troubleshooting and clarity of operation. [medium]
relevant line: # get_logger().debug(f"limiting max tokens to {max_tokens_model}")

relevant file: pr_agent/algo/pr_processing.py
suggestion: It might be beneficial to refactor the repeated pattern of checking token limits against get_max_tokens(model) into a separate function to reduce duplication and improve maintainability. [medium]
relevant line: if total_tokens + OUTPUT_BUFFER_TOKENS_SOFT_THRESHOLD < get_max_tokens(model):

relevant file: pr_agent/algo/__init__.py
suggestion: Ensure that the comment regarding the potential limitation by config.max_model_tokens is accurate and that the code will indeed respect this setting in all cases where the model's token limit is used. [important]
relevant line: 'gpt-4-1106-preview': 128000, # 128K, but may be limited by config.max_model_tokens

relevant file: pr_agent/settings/configuration.toml
suggestion: Validate that the max_model_tokens setting is well-documented and that it's clear to users how this setting interacts with the model-specific token limits. [medium]
relevant line: max_model_tokens = 32000 # even if a model supports more tokens, quality may degrade. Hence, enable to limit the number of tokens.

Preparing review...

Preparing review...

Incremental PR Review

⏮ Review for commits since previous PR-Agent review: Starting from commit https://github.com/Codium-ai/pr-agent/pull/437/commits/094f641fb585e05686b6852af73b724501b55caa
(code)

PR Analysis

🎯 Main theme: Introducing support for a new model and dynamic token limit calculation.
📝 PR summary: This PR adds support for the 'gpt-4-1106-preview' model with a specific token limit and implements a function to dynamically calculate the maximum token limit based on model capabilities and configuration settings. It also updates various parts of the code to use this new function and adds a setting to limit tokens in the configuration file.
📌 Type of PR: Enhancement
🧪 Relevant tests added: No
⏱ Estimated effort to review [1-5]: 3, because the PR involves understanding the new dynamic token calculation logic and ensuring it integrates correctly with existing systems. It also requires verifying that the new configuration setting is properly used across the codebase.
🔒 Security concerns: No

PR Feedback

💡 General suggestions: The PR seems to be well-structured and targets a specific enhancement. It would be beneficial to ensure that there are tests accompanying this new functionality to verify the dynamic token calculation works as expected across different scenarios and model configurations. Additionally, it's important to check that the new configuration setting is documented clearly for end-users.

 🤖 Code feedback:

relevant file: pr_agent/algo/utils.py
suggestion: Consider caching the settings to avoid multiple calls to get_settings() within the same function or across functions that are frequently called. This can improve performance, especially if get_settings() is not a trivial getter. [medium]
relevant line: settings = get_settings()

relevant file: pr_agent/algo/utils.py
suggestion: It's good practice to log the final token limit after calculation, especially when it's being limited by configuration. Uncomment the debug log line to assist with troubleshooting and provide transparency in the token limiting process. [medium]
relevant line: # get_logger().debug(f"limiting max tokens to {max_tokens_model}")

relevant file: pr_agent/settings/configuration.toml
suggestion: Ensure that the new max_model_tokens setting is documented in the project's configuration guide or README to inform users about its purpose and how to use it. [important]
relevant line: max_model_tokens = 32000 # Limits the maximum number of tokens that can be used by any model, regardless of the model's default capabilities.


homography_list.pkl is missing!

Thank you for letting me know. Now, we have updated the readme.

Thank you for letting me know. Now, we have updated the readme.


Improve the quality of TH splices

#18 showed that sometimes PyF expressions appears in GHC error message. Since the merge of #30, the dumped splice is highly reduced, but can be improved. For reference, the current splice for:
let x = "hi" in [f|hello what's up {x}|] :: String

Is now:
   magicFormat
      (Builder.fromString "hello what's up "
         <>
           Builder.fromString
             (((((PyF.Internal.QQ.formatAny PyF.Formatters.Minus)
                   PyF.Internal.QQ.PaddingDefaultK)
                  Nothing)
                 Nothing)
                x))

This issue tracks all future possible improvements:

[X] magicFormat can be removed and replaced by OverloadedStrings. The formatting functions (e.g. formatAny) can return an IsString t => t and take care of the conversion from the internal format. This way the magicFormat and Builder.fromString items will not appear anymore. Moreover, this approach will also solve #21. Done in #32.
[ ] PyF.Internal.XX and PyF.Formatters can be cleaned a bit and potentially exported by the PyF module. This way, GHC will display them unqualified.
[ ] Nothing here means no padding. It can be replaced by a more explict item, such as PyFNoPadding

I'm targeting something as:
  "hello what's up "
   <>
  pyfFormatAny PyFMinus
                   PyFDefaultPadding
                   PyFDefaultPrecision
                   PyFDefaultGrouping x

edit: current status, after work on #32 is:
    ("hello what's up "
       <>
         ((((PyF.Internal.QQ.formatAny PyF.Formatters.Minus)
              PyF.Internal.QQ.PaddingDefaultK)
             Nothing)
            Nothing)
           x)

Question about the magicFormat removal. Considering the following code [f|hello {x}|]. Using IsString it will generate the following code:
"hello" <> formatXXX x

Where formatXXX :: IsString t _ -> t
If OverloadedString is enabled, "hello" type is IsString t => t too, so the result of the expression can be anything. If OverloadedString is not enabled, "hello" is a [String] and the expression can only be a [String].
However, the type of [f|{x}|] will be IsString t => t whatever the status of the extension. So the type of the result of f can change depending on the status of OverloadedStrings. I have three solution:

I do nothing. Meaning that PyF will only generate something different than a [String] if OverloadedString is on, except if the f expression does not contain raw string. That's weird.
I force the type of the raw string to IsString t even when OverloadedStrings is disabled.
I force the type of formatXXX to String when OverloadedStrings is disabled.

I'm closing this issue. The quality of the splice are way better than what they were and there is not much precise motivation for improving it.
Please reopen (or open a new ticket) if you care about this.


ConfigParserProperty + val_type=bool

Even if initiated as False, the property is loaded as true, because bool('False') == True, and so is saved as True for next start, worse, even if '' is put in the default config, it's casted as False, then saved as "False", and so is True at the next start…

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@tshirtman I'm not quite sure where it the problem in the config (I have no bool in config nor see any in the config.py loaded like that), but to get this right you can use literal_eval:
from ast import literal_eval
literal_eval('False') is False

If it's not a real problem in Kivy, please close :)


Phasefield fix / ThunderEgg cleanup

Phasefield wasn't converging because I switched from using BiCGStab to CG for the patch iterative solver, and never added an option for switching between the two. Phasefield still converges with the BiCGStab patch solver.

All ThunderEgg solvers now have CG as an option for the patch solver.
Renamed patch-bcgs-max-it and patch-bcgs-tol to patch-iter-max-it and patch-iter-tol since these are now options used for iterative patch solvers
Removed the redundant patch-solver-type option used in the star patch operator and switch to the patch-solver enum option
Iterative solver now only outputs on rank 0
Fix bug where the number of equations was being set incorrectly for ThunderEgg vectors
Fix bug where the number ghost cells for ThunderEgg was hardcoded to 1 instead of using mbc. This was causing patch data to be misread in the iterative patch solvers.

Things should be fixed now with the latest ThunderEgg


Fixed the issue - Refactor Profile.tsx #59

Description
This pull request refactors Profile.tsx (issue #59 ) for improved readability, reusability, and separation of concerns. In addition to updating Profile.tsx, I have created new modular components, including Dashboard, Sidebar, Projects, GitHubStats, and PinnedRepositories. Each component now handles specific responsibilities like data fetching and UI rendering, making the profile section more maintainable and easier to extend.
These changes address the issue of improving code structure and make the codebase more modular. The functionality remains the same, but the code is more organized and testable.
Fixes # (issue)
Type of Change

[x] New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Manual testing was conducted to ensure that the refactored components behave as expected.

Checklist

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

Additional Notes
Let me know if you need any further modifications or additions to the refactoring.

Summary by CodeRabbit
Release Notes

New Features

Introduced the Dashboard component to display user profile information.
Added GitHubStats component for fetching and displaying GitHub user streak statistics.
Implemented PinnedRepositories component to show pinned repositories from GitHub.
Created Projects component to display user projects in a grid format.
Launched Sidebar component for user profile navigation and friend request functionality.

Bug Fixes

Simplified the Profile component structure by integrating the Dashboard component and removing obsolete state management and interfaces.

These enhancements aim to improve user experience by providing a more organized and informative interface for user profiles and GitHub data.

Changes Required:

Your changes do not match with the original UI.

Your UI

Original UI

Those are components not pages so make a folder ProfileComponents inside ./src/components and keep the files inside the folder and export them to use it in Profile.tsx .


common-updater-scripts: incorrect handling of latest nix's hash mismatch messages

Issue description
When used with latest Nix the "new" hash is extracted incorrectly, sha256 = "got:   sha256:hashgoeshere or thereabouts.  This seems to be due to Nix changing the message used to be more friendly to humans:
https://github.com/NixOS/nix/pull/2574
Steps to reproduce
Use an update script invoking common-updater-scripts.  Sorry, LMK if repro is needed.
Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.
I don't expect this to be helpful but happy to provide anyway!

system: "x86_64-linux"
host os: Linux 4.20.5, NixOS, 19.03.git.06b6bb8 (Koi)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.3dtz6739_232d967
channels(will): "nur-nopkgs, testing, unstable-19.03pre166987.bc41317e243, nixos-1609-16.09.1943.25f4906da6"
channels(root): "nixos-18.09.1922.97e0d53d669"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

What about adding a flag to nix, which turns on machine readable error messages with a guaranty that those messages will not change in a backward incompatible way?
Would need someone to add that.
But wouldn't that be better to parse error messages intended for human readers with shell tools?

Alternatively, if the build fails, I think we could do something like:
nix-hash --flat --base32 --type sha256 $(nix-instantiate -A "$attr.src" --json --eval --strict)

On Thu, 31 Jan 2019 09:21:25 -0800, Jan Tojnar<EMAIL_ADDRESS>wrote:

--- a/pkgs/common-updater/scripts/update-source-version
+++ b/pkgs/common-updater/scripts/update-source-version
@@ -96,7 +96,7 @@ fi
 if [ -z "$newHash" ]; then
     nix-build --no-out-link -A "$attr.src" 2>"$attr.fetchlog" >/dev/null || true
     # FIXME: use nix-build --hash here once https://github.com/NixOS/nix/issues/1172 is fixed
-    newHash=$(egrep -v "killing process|dependencies couldn't be built" "$attr.fetchlog" | tail -n2 | sed "s~output path .* has .* hash ‘\(.*\)’ when .* was expected\|fixed-output derivation produced path '.*' with .* hash '\(.*\)' instead of the expected hash '.*'~\1\2~" | head -n1)
+    newHash=$(egrep -v "killing process|dependencies couldn't be built|wanted: " "$attr.fetchlog" | tail -n2 | sed "s~output path .* has .* hash ‘\(.*\)’ when .* was expected\|fixed-output derivation produced path '.*' with .* hash '\(.*\)' instead of the expected hash '.*'\|  got:    .*:\(.*\)~\1\2\3~" | head -n1)
 fi

 if [ -z "$newHash" ]; then

It is increasingly messy, perhaps we can drop the old regexes, most people probably set nix.package instead of changing nix in overlays so this would not be affected.

I'm not sure I follow, but FWIW I ran into this and I set nix.package
and don't set it via overlay.  Looks like the new behavior is in 2.2,
the current default for nix:
$ nix run -f channel:nixos-unstable nix -i -c nix eval '(builtins.fetchurl { url = https://nixos.org; sha256 = "1111111111111111111111111111111111111111111111111111"; })'
error: hash mismatch in file downloaded from 'https://nixos.org':
  wanted: sha256:1111111111111111111111111111111111111111111111111111
  got:    sha256:1q7rksf170b1zhy54b5cwig77ycgdiaibcbh47aq8rrw3szra24w

(err formatting might not work for email responses, maybe? sorry :))
I think it's reasonable to drop support for nix older than what's in the tree--
especially since you'd have to overlay to replace it and as you say
would likely do via nix.package anyway.
Oh... that's probably what you meant! :D

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/NixOS/nixpkgs/issues/54962#issuecomment-459429698Non-text part: text/html

nix-hash --flat --base32 --type sha256 $(nix-instantiate -A "$attr.src" --json --eval --strict)

Can we do that on a path that isn't valid? I was going to try nix hash-path or so but basically they all have the same problem :).  Maybe we should just add the extra sed :innocent:.

Any updates on this?

Any updates on this?

Should have been fixed by #55605

Thanks!


[Typography] line-height removed

@oliviertassinari I've seen that you removed the line-height. Was that intended? We noticed several UI changes in our app.
 lineHeight: '1.4em', // Improve readability for multiline button.
Cheers, Thomas
Originally posted by @thomaskempel in https://github.com/mui-org/material-ui/pull/13136#issuecomment-446998259

@thomaskempel Which variants have no more line-height? There should be no changes to their styles unless you explicitly use typography v2.
@oliviertassinari  button didn't have a line-height prior to typography v2. Adding it should be considered a breaking change.

There is something wrong with next typography variants flag. For example ListItemText has bigger lineHeight internally

button didn't have a line-height prior to typography v2. Adding it should be considered a breaking change.

@eps1lon True @thomaskempel Do you want to add the line-height back in the Button style? We should add a warning so we don't forget to remove it with v4.

There is something wrong with next typography variants flag. For example ListItemText has bigger lineHeight internally

@TrySound I agree, I think that we should use the body1 variant over the subheading variant with the next typography variants flag. Benchmark:

https://material-components.github.io/material-components-web-catalog/#/component/list
https://material.io/design/components/lists.html#specs
https://material.io/design/typography/#

button didn't have a line-height prior to typography v2. Adding it should be considered a breaking change.

@eps1lon True @thomaskempel Do you want to add the line-height back in the Button style? We should add a warning so we don't forget to remove it with v4.

Again: What do you mean by "back"? It didn't even have a line-height in ~1.0:
https://github.com/mui-org/material-ui/blob/73101790333124cc8f5857bc46038b7d2315842a/packages/material-ui/src/styles/createTypography.js#L113-L119
@TrySound
What do you mean by "internally"? The docs use typography v2 while 3.x still uses typography v1 by default. Changes in line-height are most likely intended.

Thanks for your help. I don't want to make too much trouble. I was just wondering if it was intended. I don't use any variant.
To keep the old style I just added the the removed line (in Button.js, on the root class) to my default style in the theme until we migrate to next. Don't know how many projects are affected by the same issue.

ListItemText just looks ugly with enable next typography flag, nothing else

@eps1lon Here is what I have in mind:
export const styles = theme => ({
  root: {
+   lineHeight: '1.4em', // To remove after v4 is released.
    ...theme.typography.button,

          primary = (
            <Typography
+             variant={theme.typography.useNextVariants ? 'body1' : 'subheading'}
-             internalDeprecatedVariant
              className={classNames(classes.primary, { [classes.textDense]: dense })}
              component="span"
              {...primaryTypographyProps}

Oh so we're not talking about the button variant but the Button component. That was not obvious from the original comment since it was posted in a PR that didn't signal any changes to the actual implementation.
I didn't agree with the change in the first place. Especially since it was targeted at multiline buttons that never appear in the material design guidelines.
@oliviertassinari
This came up previously in #12726. I originally preferred subtitle1 (which is currently used if typography v2 is enabled) but body1 and body2 are closer to the primary-secondary concept. Only difference between subtitle1 and body1 is the line-height. subtitle1 is closer to the spec mocks. The internalDeprecatedVariant is still necessary though for typography v1 users that have deprecation warnings enabled.

@eps1lon I'm note sure to understand. Are you happy to move forward with the changes I have proposed in https://github.com/mui-org/material-ui/issues/13900#issuecomment-447254595?

Fix a recent regression.
Makes us follow the specification more closely. You can check you the reference implementation or the specification website. The two line spacing is too wide by 4px, exactly what we get with moving from subheading1 to body1 (1.75 * 16 - 1.50 * 16 = 4).

Regarding the multiline button, I think that it's important to handle, it can happen independently from the developer will. For instance went translating the website, or when resizing the screen.