Cube in demo appears squashed

The cube in the demo is squashed. It looks like an aspect ratio thing. I can't see anything in the source that would cause this. Any ideas?

After some digging the fix is kind of obvious:
diff --git a/gl21-cube/cube.go b/gl21-cube/cube.go
index 5a84ebc..b26b8f2 100644
--- a/gl21-cube/cube.go
+++ b/gl21-cube/cube.go
@@ -29,6 +29,8 @@ func init() {
        runtime.LockOSThread()
 }

+const width, height = 1280, 720
+
 func main() {
        if err := glfw.Init(); err != nil {
                log.Fatalln("failed to initialize glfw:", err)
@@ -38,7 +40,8 @@ func main() {
        glfw.WindowHint(glfw.Resizable, glfw.False)
        glfw.WindowHint(glfw.ContextVersionMajor, 2)
        glfw.WindowHint(glfw.ContextVersionMinor, 1)
-       window, err := glfw.CreateWindow(800, 600, "Cube", nil, nil)
+       monitor := glfw.GetPrimaryMonitor()
+       window, err := glfw.CreateWindow(width, height, "Cube", monitor, nil)
        if err != nil {
                panic(err)
        }
@@ -115,7 +118,9 @@ func setupScene() {

        gl.MatrixMode(gl.PROJECTION)
        gl.LoadIdentity()
-       gl.Frustum(-1, 1, -1, 1, 1.0, 10.0)
+       // Correct the projection for the monitor's aspect ratio.
+       f := ((float64(width) / height) - 1) / 2
+       gl.Frustum(-1-f, 1+f, -1, 1, 1.0, 10.0)
        gl.MatrixMode(gl.MODELVIEW)
        gl.LoadIdentity()
 }

I'm not sure that it's worth including this in the example program.

I'd be happy to accept a PR with a fix.

Thanks for reporting this @nf.
The window is not resizable, right? In that case, the aspect ratio can be hardcoded, no need to get the monitor (which might have a different aspect ratio). For a 800x600 window, it should be 4:3.

@errcw I'll give it a go.
@shurcooL I get the monitor to make it full screen; that's not a critical part of this fix.

Alternatively, to keep the example simpler, we can just change the window size to be square, since that's easier to compute a projection matrix for.
Note that the gl41core-cube example doesn't have this problem, it calculates a perspective projection matrix accurately:
https://github.com/go-gl/example/blob/ee0644b7c5650555db3c0f4d04f9ef5716e6c6ac/gl41core-cube/cube.go#L65

For reference, the way I create a perspective projection matrix in OpenGL 2.1 projects is usually something like this, but it needs github.com/go-gl/mathgl/mgl64 package to be imported:
gl.MatrixMode(gl.PROJECTION)
gl.LoadIdentity()
var projectionMatrix [16]float64
perspMatrix := mgl64.Perspective(mgl64.DegToRad(45), float64(windowSize[0])/float64(windowSize[1]), 1.0, 1500.0)
for i := 0; i < 16; i++ {
	projectionMatrix[i] = float64(perspMatrix[i])
}
gl.MultMatrixd(&projectionMatrix[0])

(The code is from an older project, it can be cleaned up to improve style.)


Make PGPUtil.pipeFileContents use buffer and not leak file handle

This avoids generating a new byte buffer if one was specified. It also makes sure the file handle is closed in case a exception while reading/writing happens.
It is generally safe to suppress exceptions from FileInputStream.close(), but let me know if you want the safeClose() removed. In case the buffer copy is a security pre-caution and it should remain, it should be documented in source.

Thanks for the patch. Applied.


Glitching of the slider when used inside a css grid

When I'm using the slider inside a css grid it glitches out of the screen and gets extremely big.
I've noticed this when comparing my site on mobile vs on the desktop. On big screens the slider sits inside a grid while on small screens it does not.
This is how it looks like when I load the page with the slider on a large screen (disply: grid applies).
https://user-images.githubusercontent.com/3080903/106955064-fd443c80-6734-11eb-8cd2-7911a2ffc407.mov
The div with the slider in it gets extremely big which causes the glitching and the whole layout to break.

This is the styled component where the slider sits in.
export const TwoColumnGrid = styled.div`
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  gap: ${({ gap }) => (gap ? gap : '2.5rem')};
  grid-auto-flow: row dense;
  ${({ backgroundColor }) =>
    backgroundColor ? `background-color: ${backgroundColor};` : null};

  & > :nth-of-type(4n - 1) {
    grid-column-start: 2;
  }

  @media (max-width: ${breakpoints.l}px) {
    display: block;

    & > * {
      margin-bottom: ${({ gap }) => (gap ? gap : '2.5rem')};
    }

    & > :last-child {
      margin-bottom: 0rem;
    }
  }
`

I've noticed I can work around by wrapping the slider inside a container with an absolute width like width: 200px but this defeats the purpose of the slider filling my container.
I'm using<EMAIL_ADDRESS>with<EMAIL_ADDRESS><EMAIL_ADDRESS>and<EMAIL_ADDRESS>

@AlexanderProd thanks for this. I'll look into it and get back to you

Hi @AlexanderProd can you try using this for the grid-template-columns
grid-template-columns: repeat(2, minmax(0, 1fr));

Check [this article] for more details.
Let me know if it works or not

@femioladeji Thank you very much! That fixed it.


Improve ConsPortfolioModel

This PR includes improvements and cleanup to ConsPortfolioModel.py to bring it a little more in line with other model files, and adds the ability to specify an age-varying list of RiskyAvg and RiskyStd.  These represent agent beliefs about risky returns, which might differ from the true (time invariant) risky return distribution.
It also includes a new alternate version of this file that (I think) will replace ConsPortfolioModel.py.  It takes bits and pieces from the old version, but the solver is a wholesale rewrite and simplification of the current version.
This PR is not ready to merge, as I need to rectify it with other changes that have been made to master in the meantime.

Okay, I think this is ready for merge.  The old version still works, and my new version has its own example file.
In a separate PR, after this is merged, we can remove the old files and remove the ALTs from the new ones.

@mnwhite I've posted my tweaks to add the numerical Merton-Samuelson limit to the ConsPortfolioModelALT.py notebook.
@MridulS, I think this is ready to merge (assuming Travis agrees)


example commands crash

I tried these with 0.1.1 on Debian 11
$ solo2 app admin uuid
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TryFromSliceError(())', src/apps/admin.rs:48:55
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ solo2 app ndef capabilities
thread 'main' panicked at 'explicit panic', src/transport/ctap.rs:90:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It turns out that this is due to libccid not supporting Solo 2.  I'd have hoped the program would be able to report that instead of just panicking.  (Although there's a mention of this in the last project update, it wasn't clear it's actually necessary to have updated packages, or what to do about it.)
I've raised https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006614 to try to get support added to Debian 11, at least.  It references two packages I built, one a backport from ccid 1.5, and another which patches 1.4.34 to support Solo 2 and Nitrokey 3.  Either of those work for me to the extent I've tested.  There are also Debian 10, Ubuntu 18.04, and Ubuntu 20.04 builds (untested).  If you install the 1.4.34-1~solo2+1 version on Debian 11 you'll need to pin it to avoid it being overwritten on updates; I obviously don't know enough about Debian versioning.
However, the easiest, and presumably most general, way to provide the support is to copy the built configuration file from ccid 1.5, or the patched version, into /etc/libccid_Info.plist, or wherever it lives in other distributions.  (That file was mentioned
libccid_Info.plist.gz
, but I didn't understand what it was about.)  I'll attach a copy of the minimally-patched version.

Yeah this is a sucky combination of Debian's "security fixes only" and CCID's "allowlisted device only"... Oh well.

Here is the Debian bug report, for reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006614

Oh well

This could at least show a more informative message than a bare panic!().


Transarmor Token Support for purchase() and authorize()

I'm not really sure if how I did this fits with the "way things are done" around here, but it works, its a needed feature so if its acceptable please merge it or if not, feel free to re-implement it the way you want it implemented.
Basically I just had to add getTokenCardType() and setTokenCardType() to PayeezyPurchaseRequest, which allows the user to supply a "tokenCardType" parameter when calling $gateway->purchase() or $gateway->authorize(). tokenCardType is required and must match a valid card type found in \omnipay\common\CreditCard. The user must also supply the built in cardReference parameter with the desired card token.
The CreditCard parameter must contain the cardholder name supplied by which ever field works for the user name billingName or whatever firstName / lastName fields they want. The card Expiration date must also be supplied.
There is a usage example added to the comments in PayeezyPurchaseRequest.php

I really dont understand this code style check b.s.
I fixed everything it complained about it, re-committed, then it ran again, passed every check except the hhvm check which actually failed due something completely unreleated to my code.
Then for some reason, instead of showing the latest results from the build check, which would show all passing except for hhvm, it shows the first build log with all of the code style errors on them which have all been fixed.
shrugs

We're actually dropping support for hhvm because it seems to be no longer supported on most modern distros.

OK merged.  Can someone please confirm that this works in production and I will tag for release.

Not sure if I count but I can verify it at least works on the test-mode endpoint. Also when do you think and how will I know when the updated code is available through composer?


⚠ BCR Bot has degraded performance

In 6a08ba4, BCR Bot (https://bcr.alternativasinteligentes.com/BCRApi/web/chatbot) experienced degraded performance:

HTTP code: 200
Response time: 1814 ms

Resolved: BCR Bot performance has improved in 57f15e9.


Cancelling a premove causes you to not be able to make another premove

If you make a premove, then right click to cancel it, if you try to make another premove before your opponent makes their move it does not register, and snaps the piece back to the original square. You can also see this behavior at https://react-chessboard.com/ with the Premove vs. Random example.

Great find, fixed in<PHONE_NUMBER>d7031a815c0a67b365f06c75c2bd90


Automatically comment new lines in roxygen sections #124

Closes #124
This PR makes it so that hitting enter on an roxygen comment line (starting with #') starts the new line with #' as well.
It only applies if there is no indentation before #'.

@andycraig Thank you for your work!
It looks fine. I will publish a new version this weekend.

@Ikuyadeu Thank you!


Control-C doesn't work during reloader sleep

https://github.com/mitsuhiko/flask/issues/1373#issuecomment-83229953
Not sure how fixable this is.

@untitaker It seems that this is a Windows only issue, but you could do a shorter sleep interval ex.
for i in range(60):
    sleep(1)

I've found this issue: http://bugs.python.org/issue581232
But it seems that this was supposed to be fixed a long time ago?


Slack : Bot doesnt respond at all : "TypeError: 'NoneType' object is not iterable". trace =>line 203, in _sanitize_user_message , for uid_to_remove in uids_to_remove:

Rasa version: Rasa: 1.10.14
Rasa SDK version (if used & relevant): NA
Rasa X version (if used & relevant): NA
Python version: Python 3.7.9
Operating system (windows, osx, ...): Windows 10
Issue:
I am testing a bot on slack after deploying it successfully in slack - I get : "TypeError: 'NoneType' object is not iterable"
Please note that the same Bot works well with "rasa shell"
The problem is ONLY seen when trying to test the bot in Slack.
Error (including full traceback):
Traceback (most recent call last):
File "c:\users\smohana\anaconda3\envs\rasa_new\lib\site-packages\sanic\app.py", line 976, in handle_request
response = await response
File "c:\users\smohana\anaconda3\envs\rasa_new\lib\site-packages\rasa\core\channels\slack.py", line 384, in webhook
user_message, metadata["users"]
File "c:\users\smohana\anaconda3\envs\rasa_new\lib\site-packages\rasa\core\channels\slack.py", line 203, in _sanitize_user_message
for uid_to_remove in uids_to_remove:
TypeError: 'NoneType' object is not iterable`
Command or request that led to error:
Just trying to interact with utter_greet in Slack

**Content of configuration file (config.yml)** (if relevant):
``
# Configuration for Rasa NLU.
# https://rasa.com/docs/rasa/nlu/components/
language: en
pipeline:
  - name: WhitespaceTokenizer
  - name: RegexFeaturizer
  - name: LexicalSyntacticFeaturizer
  - name: CountVectorsFeaturizer
  - name: CountVectorsFeaturizer
    analyzer: "char_wb"
    min_ngram: 1
    max_ngram: 4
  - name: DIETClassifier
    epochs: 150
  - name: EntitySynonymMapper
  - name: ResponseSelector
    epochs: 150

# Configuration for Rasa Core.
# https://rasa.com/docs/rasa/core/policies/
policies:
  - name: MemoizationPolicy
  - name: TEDPolicy
    max_history: 5
    epochs: 100
  - name: MappingPolicy

Content of domain file (domain.yml) (if relevant):
``
NA

Thanks for raising this issue, @Ghostvv will get back to you about it soon✨
Please also check out the docs and the forum in case your issue was raised there too 🤗

I am also getting same error on Rasa version: 1.10.14
Python version: Python 3.7.6
Operating system (windows, osx, ...): Windows 10
RasaX : 0.32.2
Exception occurred while handling uri: 'http://c5fad06398f9.ngrok.io/webhooks/slack/webhook'
Traceback (most recent call last):
File "c:\users\kr\anaconda3\envs\rasa\lib\site-packages\sanic\app.py", line 976, in handle_request
response = await response
File "c:\users\kr\anaconda3\envs\rasa\lib\site-packages\rasa\core\channels\slack.py", line 384, in webhook
user_message, metadata["users"]
File "c:\users\kr\anaconda3\envs\rasa\lib\site-packages\rasa\core\channels\slack.py", line 203, in _sanitize_user_message
for uid_to_remove in uids_to_remove:
TypeError: 'NoneType' object is not iterable

Hi @SindhuMohana , thanks for bringing this issue to our attention. It looks like some recent changes to the Slack Events API have affected compatibility with our Slack Connector.
The Slack change log details a way to opt-out of this API change using Slack's App Management page and selecting the checkbox under Event Subscription. Can you see if that works for you while we work on updating our Slack connector?

@b-quachtran  tht

Hi @SindhuMohana , thanks for bringing this issue to our attention. It looks like some recent changes to the Slack Events API have affected compatibility with our Slack Connector.
The Slack change log says this is opt-in though, so can you take a look at the change log to see if you can uncheck "Event Subscription" ?

@b-quachtran  If we uncheck this option ,event subscription wont be enabled which is not what we want ,
Looks like in  the event API changes   , api authed_users and authed_teams will be deprecated. Events will contain a single, compact authorizations field containing one party that the event is visible to.

Is this issue fixed? I had to comment out _sanitize_user_message function in slack.py to get a temporary fix

@reachkrr
Unchecking the option does not stop the event subscription for me. If you haven't already, I recommend unchecking it and testing it out (it may take a few minutes for the changes to take effect). However, new apps that are created don't have a choice and are just opted-in right away and since old apps will have to follow the new API anyways in February this is not a long-term solution.

Hi everyone, I've created a separate issue for updating the connector code here: https://github.com/RasaHQ/rasa/issues/6961 to keep track of the progress while a fix is being worked on.

@reachkrr
Unchecking the option does not stop the event subscription for me. If you haven't already, I recommend unchecking it and testing it out (it may take a few minutes for the changes to take effect). However, new apps that are created don't have a choice and are just opted-in right away and since old apps will have to follow the new API anyways in February this is not a long-term solution.

@jkuan1  I dont see any events coming through when I disable events in slack . attaching scerenshot

I'm also getting the same issue,
Did someone able to resolve it ?
What will be the solution for it.

I am still unable to resolve the issue
Slack for me doesn’t even have the option to unselect - the checkbox isn’t
there for the app In the respective api page
On Fri, 9 Oct 2020 at 6:24 PM, Harshesh Kamli<EMAIL_ADDRESS>wrote:

I'm also getting the same issue,
Did someone able to resolve it ?
What will be the solution for it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RasaHQ/rasa/issues/6895#issuecomment-706163630, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AL6XD3FWWHAYVRXEFEFCPTDSJ4BZRANCNFSM4SDYM4XA
.

is there any thing we could do to overcome this error like change RASA version or some thing?
which is the most stable version of rasa so that we dont get this issue again
if yes. how can the version of rasa

I'm having the same issue. Is there any solution?

Hi @robynbitner, what version of Rasa are you using? This issue has been resolved in Rasa 2.X

Hello @b-quachtran,
RASA_X_VERSION=0.33.1
RASA_VERSION=2.0.2
RASA_X_DEMO_VERSION=0.33.0
Python version: 3.7
I have deployed my chatbot using docker-compose. Could it be that there is still a bug for this?

@robynbitner Is there any way you would be able to upgrade to Rasa 2.1? It includes this PR that addresses the Slack connector issue: https://github.com/RasaHQ/rasa/pull/7186


Merge refactorings

Benchstat
name                    old time/op    new time/op    delta
ParseEntry-8               954ns ±14%     799ns ± 3%  -16.23%          (p=0.008 n=5+5)
ParseEntryNoTimezone-8     603ns ± 1%     541ns ± 3%  -10.28%          (p=0.008 n=5+5)

name                    old alloc/op   new alloc/op   delta
ParseEntry-8                144B ± 0%      144B ± 0%     ~     (all samples are equal)
ParseEntryNoTimezone-8    0.00B ±NaN%    0.00B ±NaN%     ~     (all samples are equal)

name                    old allocs/op  new allocs/op  delta
ParseEntry-8                3.00 ± 0%      3.00 ± 0%     ~     (all samples are equal)
ParseEntryNoTimezone-8     0.00 ±NaN%     0.00 ±NaN%     ~     (all samples are equal)

Coverage decreased (-1.8%) to 95.89% when pulling 7526601dea463b7ef5e9eee35dafc3a1ce0bcca7 on refactor into 1afc0c892ee855174641cb16f06576949f216d2e on master.


[DLL] Minimax algorithm

This is a work in progress. The PR will be changed to Ready For Review as soon as everything has been implemented.

This PR will be closed and continued in https://github.com/SoloGameDevGitHub/AIEngine/pull/24


Feature: Secure upload mechanism

SDK implementations of  : https://github.com/aleph-im/pyaleph/pull/463

Do not merge :warning:
Depends on : https://github.com/aleph-im/pyaleph/pull/463


dotnet core on OSX

Intention

I'm submitting a feature request
Similar to https://github.com/monterey-framework/monterey/issues/333, running the skeleton-esnext-aspnetcore sample results with the error notice asking whether the dotnet was installed.
So, I realized that I completely forgot how to install that component (other than installing VS code on my OSX) so we need to explain this situation a lot better.

Just because .Net Core confused me a little (name changes, overlapping with some "web tools" for vs)..
It's this right? https://www.microsoft.com/net/core#macos

@Thanood - I believe that this is what I was after, yes. My initial comment was written in frustration that I was not able to find it. It is indeed mentioned here.
I will update the User manual to explain this in a very clear way

Having successfully installed dotnet as described in https://www.microsoft.com/net/core#macos I installed the latest Monterey (0.4.1). Starting it, I selected the skeleton-esnext-aspnetcore built yesterday (it failed to run because of not having dotnet, installed.
I was under the impression that just a click on the Run tile would result in seeing the app run - however, I got this:

I believe that this is a bug/

Now you just need to install gulp ;) npm install gulp -g

It's referring to the local gulp. It's behind the red line, but also the command suggests it (no -g)..
So this would also happen when the npm install task fails. Or if it's not run. :smiley:

ah yes, thanks @Thanood  👍
I agree that it's likely that the node modules were not installed. I cannot reproduce this on windows or mac:

So we need more info I think

I've tried to install a skeleton yesterday and totally failed to notice that npm install didn't finish. I only noticed that in NPM view not all packages were displayed as "installed".
The problem was actually vscode locking some directories. My point is, though: It might be a good idea to highlight NPM errors some more.

I wonder if we should stop all queued tasks when the "parent" task fails. For example, when npm install fails, we would cancel all other queued tasks, because they all wait for npm install.

BTW, can you share the monterey log of that day?

It's at home. I'll look it up when I get there.

:+1: also there may be a npm-debug.log file in the project directory (Apparently npm creates those files when npm install fails)

Yes, I hope both are still there because I closed vscode, tried it again and then it worked.

Interesting. First we need to make sure that the user knows it had failed to run npm install, and all others queued tasks need to be cancelled.
Then the user should be able to restart the install  process. The treelist you see at the end of the scaffolding wizard can be used to install existing projects as well. We can create an install tile that brings this screen up

A comment on @JeroenVinke's comment

Now you just need to install gulp ;) npm install gulp -g

You applied the "wink" emoji to this comment, so I would guess that you realized how your "advice" is not a serious one: why would I have to run npm install -g gulp when I did that already long time ago. As @Thanood observed, the Gulp issued error message was to install local gulp.
More important point is this:
why did this error took place? I tried to apply the Run button on a three days old application that was then (three days ago) built and run perfectly normal. I still have this application saved and will try it again with the most current Monterey later todat

I wonder if we should stop all queued tasks when the "parent" task fails. For example, when npm install fails, we would cancel all other queued tasks, because they all wait for npm install.

Absolutely
It would be nice to issue the relevant explanation as well.

@JeroenVinke No errors in my log file from that day. I guess it's because it worked the second try.
Anyway, here's the log file:
type,id,date,msg"info","monterey","2016-09-22T18:12:15.569Z","application started"
"info","aurelia","2016-09-22T18:12:15.705Z","Aurelia Starting"
"info","aurelia","2016-09-22T18:12:15.947Z","Aurelia Started"
"info","updater","2016-09-22T18:12:16.075Z","current version: 0.4.0"
"info","updater","2016-09-22T18:12:16.075Z","using update feed url: https://nuts.jeroenvinke.nl:443/update/win32/"
"info","updater","2016-09-22T18:12:16.075Z","checking for updates now"
"info","updater","2016-09-22T18:12:16.075Z","checking-for-update"
"info","application-state","2016-09-22T18:12:16.119Z","State saved"
"info","npm-detection","2016-09-22T18:12:28.595Z","found package.json at C:\Users\Daniel\Documents\Entwicklung\js\aurelia\try-aurelia-webpack-materialize\package.json"
"info","aurelia-cli-detection","2016-09-22T18:12:28.598Z","did not find aurelia.json file"
"info","gulp-detection","2016-09-22T18:12:28.600Z","did not find gulpfile"
"info","webpack-detection","2016-09-22T18:12:28.600Z","webpack.config.js found: C:\Users\Daniel\Documents\Entwicklung\js\aurelia\try-aurelia-webpack-materialize\webpack.config.js"
"info","typings-detection","2016-09-22T18:12:28.602Z","did not find typings.json file"
"info","dotnet-detection","2016-09-22T18:12:28.603Z","did not find project.json file"
"info","application-state","2016-09-22T18:12:28.681Z","State saved"
"info","project-manager","2016-09-22T18:12:28.683Z","Project added"
"info","application-state","2016-09-22T18:12:28.720Z","State saved"
"info","TaskManager","2016-09-22T18:12:49.115Z","queued 'NPM install' for project 'try-aurelia-skeleton-webpack-materialize'"
"info","TaskManager","2016-09-22T18:12:49.116Z","started 'NPM install' for project 'try-aurelia-skeleton-webpack-materialize'"
"info","updater","2016-09-22T18:15:24.960Z","A new update is available"
"info","notification","2016-09-22T18:19:50.749Z","Version 0.4.1 has been downloaded and will be automatically installed on Quit"
"info","TaskManager","2016-09-22T18:23:50.701Z","task 'NPM install' for project 'try-aurelia-skeleton-webpack-materialize' finished without error"
"info","TaskManager","2016-09-22T18:24:44.346Z","queued 'npm start' for project 'try-aurelia-skeleton-webpack-materialize'"
"info","TaskManager","2016-09-22T18:24:44.346Z","started 'npm start' for project 'try-aurelia-skeleton-webpack-materialize'"
"info","notification","2016-09-22T18:24:44.365Z","Started"
"info","TaskManager","2016-09-22T18:24:46.314Z","task 'npm start' for project 'try-aurelia-skeleton-webpack-materialize' finished without error"
"info","application-state","2016-09-22T18:24:51.357Z","State saved"
"info","TaskManager","2016-09-22T18:25:54.227Z","queued 'NPM install' for project 'try-aurelia-skeleton-webpack-materialize'"
"info","TaskManager","2016-09-22T18:25:54.228Z","started 'NPM install' for project 'try-aurelia-skeleton-webpack-materialize'"
"info","TaskManager","2016-09-22T18:27:13.385Z","task 'NPM install' for project 'try-aurelia-skeleton-webpack-materialize' finished without error"

I believe the UX of the taskmanager has improved a lot. Tasks that have failed are always visible in the taskmanager now, and all dependent tasks will be stopped. That allows you to inspect what went wrong atleast. So I'll close this issue as we do not have an error message to go on


Do not move options in the risk manager, the API will do it

Something from here break the routing?

This happens after it routes, so this would not be it


MLFlow Logger slows training steps dramatically, despite only setting metrics to be logged on epoch

🐛 Bug
When using the MLFlow logger, with a remote server, logging per step introduces latency which slows the training loop.
I have tried to configure logging of metrics only per epoch, however it seems this still results in much slower performance. I suspect the logger is still communicating with the MLFlow server on each training step.
To Reproduce

Start an MLFlow server locally

mlflow ui

Run the minimal code example below as is, (with MLFlow logger set to use the default file uri.)
Uncomment out the tracking_uri to use the local MLFlow server and run the code again. You will see a 2-3 times drop in the iterations per second.

Code sample
import torch
from torch.utils.data import TensorDataset, DataLoader
import pytorch_lightning as pl

class MyModel(pl.LightningModule):
    def __init__(self):
        super().__init__()
        self.num_examples = 5000
        self.num_valid = 1000
        self.batch_size = 64
        self.lr = 1e-3
        self.wd = 1e-2
        self.num_features = 2
        self.linear = torch.nn.Linear(self.num_features, 1)
        self.loss_func = torch.nn.MSELoss()
        self.X = torch.rand(self.num_examples, self.num_features)
        self.y = self.X.matmul(torch.rand(self.num_features, 1)) + torch.rand(self.num_examples)

    def forward(self, x):
        return self.linear(x)

    def train_dataloader(self):
        ds = TensorDataset(self.X[:-self.num_valid], self.X[:-self.num_valid])
        dl = DataLoader(ds, batch_size=self.batch_size)
        return dl

    def val_dataloader(self):
        ds = TensorDataset(self.X[-self.num_valid:], self.X[-self.num_valid:])
        dl = DataLoader(ds, batch_size=self.batch_size)
        return dl

    def configure_optimizers(self):
        return torch.optim.Adam(self.parameters(), lr=self.lr, weight_decay=self.wd)

    def training_step(self, batch, batch_idx):
        x, y = batch
        yhat = self(x)
        loss = self.loss_func(yhat, y)
        result = pl.TrainResult(minimize=loss)
        result.log('train_loss', loss, on_epoch=True, on_step=False)
        return result

    def validation_step(self, batch, batch_idx):
        x, y = batch
        yhat = self(x)
        loss = self.loss_func(yhat, y)
        result = pl.EvalResult(early_stop_on=loss)
        result.log('val_loss', loss, on_epoch=True, on_step=False)
        return result

if __name__ == '__main__':
    from pytorch_lightning.loggers import TensorBoardLogger, MLFlowLogger
    mlf_logger = MLFlowLogger(
        experiment_name=f"MyModel",
        # tracking_uri="http://localhost:5000"
    )
    trainer = pl.Trainer(
        min_epochs=5,
        max_epochs=50,
        early_stop_callback=True,
        logger=mlf_logger
    )
    model = MyModel()
    trainer.fit(model)

Expected behavior
When using the TrainResult and EvalResult, or manually handling metric logging using the training_epoch_end and validation_epoch_end callbacks. It should be possible to avoid the MLFlow logger from communicating with the server in each training loop.
This would make it feasible to implement the MLFlow when a remote server is used for experiment tracking.
Environment
* CUDA:
	- GPU:
	- available:         False
	- version:           None
* Packages:
	- numpy:             1.18.2
	- pyTorch_debug:     False
	- pyTorch_version:   1.6.0+cpu
	- pytorch-lightning: 0.9.0
	- tensorboard:       2.2.0
	- tqdm:              4.48.2
* System:
	- OS:                Linux
	- architecture:
		- 64bit
		-
	- processor:         x86_64
	- python:            3.7.9
	- version:           #1 SMP Tue May 26 11:42:35 UTC 2020

Additional context
We host a MLFlow instance in AWS and would like to be able to track experiments without affecting the training speed.
It appears that in general the MLFlow logger is much less performant than the default Tensorboard Logger, but this would not be much of a problem if we could avoid calls to the logger during the training loop.
Solution
I've done a bit of debugging in the codebase and have been able to isolate the cause in two places
https://github.com/PyTorchLightning/pytorch-lightning/blob/d438ad8a8db3e76d3ed4e3c6bc9b91d6b3266b8e/pytorch_lightning/loggers/mlflow.py#L126-L129
Here self.experiment is called regardless of whether self._run_id exists. If we add an if not self._run_id here we avoid calling self._mlflow_client.get_experiment_by_name(self._experiment_name) on each step.
However we still call it each time we log metrics to MFlow, because of the property self.experiment.
https://github.com/PyTorchLightning/pytorch-lightning/blob/d438ad8a8db3e76d3ed4e3c6bc9b91d6b3266b8e/pytorch_lightning/loggers/mlflow.py#L112
Here if we store expt within the logger and only call self._mlflow_client.get_experiment_by_name when it does not exist, we eliminate all overhead, it runs as fast as fast as the tensorboard logger and all the mlflow logging appears to be working as expected.
I'd be happy to raise a PR for this fix.

have you tried to just increase the row_log_interval, its a trainer flag that controls how often logs are sent to the logger.

The model above is a contrived example, upon further testing I have realised that the performance difference between MFLow logger and the Tensorboard logger is not inherent to the MLFlow client.
I've done some debugging and added a solution section to the issue. It appears to be in in the experiment property of the MLFlowLogger. Each time .experiment is accessed, self._mlflow_client.get_experiment_by_name(self._experiment_name) is called, which communicates with the MLFlow server.
It seems we can store the response of this method thereby needing to call it only once, and this seems to resolve the dramatic difference between the Tensorboard and MLFlow Logger.

oh ok, that makes sense. Would you like to send a PR with your suggestion and see if the tests pass? Happy to review it.

yeah sure, I'll link it here shortly.

Did you encounter this #3392 problem as well?


number in vote app to big for styling

maybe we can go with 112k and 67k if the number is higher than 1k

I think that would make the voting not transparent enough, which I think is the main purpose of voting.

This issue was moved to webpack-contrib/voting-app#1


Include account in payment id/url

In order for the Open Payments router to check that the access token's grant allows access to a particular account's (identifier) payment(s), incoming and outgoing payment ids/urls should include the account id/url:
https://wallet.example/alice/incoming-payment/abc123

instead of
https://wallet.example/incoming-payment/abc123

https://github.com/interledger/rafiki/blob/dd2a140a1fd8f68ee6752befdea6d8e565bfe92b/packages/backend/src/app.ts#L261-L272

:+1: This is also what the spec says: incoming payments and outgoing payments.


Add section to README: How to use a BSP

I was advised by @jbeaurivage to add a section to the readme, detailing the steps I found difficult as a newbie getting started.
This is my first Github pull request ever.

@nQue, do you know about the cortex-m-quickstart template? When I first got started with embedded Rust, that's what I started from. I'm not sure if that appears anywhere in the README. If not, it probably should.

This looks good to go, pending any comments from @sajattack. Adding a reference to the quickstart template might be nice, but isn't required.

Sorry didn't see this.


Use CanRequestCase on all caseworker pages

Wherever the "Request next cases" button appears, only show it to users with the "Self Allocation User" role
Fixes VEGA-855

Codecov Report

Merging #43 (8bc4c95) into main (0f3061b) will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #43      +/-   ##
==========================================
+ Coverage   89.77%   89.80%   +0.03%
==========================================
  Files          22       22
  Lines         567      569       +2
==========================================
+ Hits          509      511       +2
  Misses         31       31
  Partials       27       27

Impacted Files
Coverage Δ

internal/server/all_cases.go
90.00% <100.00%> (+0.52%)
:arrow_up:

internal/server/tasks.go
90.00% <100.00%> (+0.52%)
:arrow_up:

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 0f3061b...8bc4c95. Read the comment docs.


npm and yarn start failed

Hi @yussan , I ran this project and got this issue:

Could you plz help to check it?
Thanks!

thanks for issue, checking....

Cause of error :

Error: Node Sass does not yet support your current environment: OS X 64-bit with Unsupported runtime (72)
For more information on which environments are supported please see: https://github.com/sass/node-sass/releases/tag/v4.5.3

Solution :

update node-sass
only use npm install and npm start (README.md updated)

Status : solved and merged


fails to compile

Problem is:
E: Incompatible types from different branches for @ret: Tuple[int, T0, T1] and Array[1d, int] (ldpc.py, line 118)
https://gist.github.com/nbecker/077b8d7494d1364de515e62c8d98c10a

        return f_out, interleave, counts, locs
    else:
        return f_out

two different types, that's not compatible with pythran :-)

I find that this type of issue is not easy to identify. Even if you think you're returning the same types, you may not, in a way that's not always visible to the naked eye...

Could pythran provide a better error message for such cases?
Maybe also add something about this to the user manual.

It's a tremendous task , maybe try with mypy ? Numpy support does not seem satisfying though... https://github.com/numpy/numpy-stubs


Crashes Map

Hi,
Please add Country and Map in the Diagnostics page so it will be easy to identify where every crash comes from
Thanks,
Jassim

Hi @jrahma thanks for the feature request. Looks like you already have an open issue about this: https://github.com/microsoft/appcenter/issues/750
I'm going to close this issue and will post updates in #750. Thanks!


is there a way to enable the sound test

Describe your problem here.
all the code seems to be there, tho idk how to enable it
if its even possible in the first place to enable the source code, then please say it here
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
not yet

by playing through the mod normally, no

by playing through the mod normally, no

i meant if i could enable it through the source code of the mod

it should, but it doesn't work for some reason

it should, but it doesn't work for some reason

oh, so even if you try to enable it through the source code (like with editing the SoundTestMenu.hx file), it still won't work?

no, look at this code here
						FlxG.save.data.weekCompleted = StoryMenuState.weekCompleted; 						ClientPrefs.beatweek = true; 						ClientPrefs.saveSettings(); 						FlxG.save.flush();

no, look at this code here FlxG.save.data.weekCompleted = StoryMenuState.weekCompleted; ClientPrefs.beatweek = true; ClientPrefs.saveSettings(); FlxG.save.flush(); it's suppost to unlock sound test, but it doesn't work for some reason

oh

2 year late lol but download this file put it into source and if prompted to replace it replace it https://drive.google.com/file/d/1jMvPuWlI2dNn-xbGR4DUj_OjIrNL0uD-/view?usp=sharing


Use Python to run RCNN algorithm on Zedboard (Xilinx Zynq®-7000)

Can you please tell whether we can use python to program Zedboard using the Pynq framework? I want to implement Mask RCNN algorithm on Xilinx Zedboard. Looking forward to your reply

这是来自QQ邮箱的假期自动回复邮件。


access signals that are arrays?

May be a dumb question, but how does one index into signals that are really SV arrays?
This doesn't seem to work:
#array[0].something

Hi, I think this depends a bit on how your simulator outputs array elements.
For example, Verilator creates a signal arra[0], array[1],  etc., for each element of the array.
Since in WAL [] gets you bit ranges from a signal, those signal names are translated to array<0>…
I just updated WAL's trace readers to improve this., so if you install from the latest main branch, it hopefully works.

I installed from main, and still see the same error
Traceback (most recent call last):
  File "/home/jzhang/.local/bin/wal", line 8, in <module>
    sys.exit(run())
             ^^^^^
  File "/home/jzhang/.local/lib/python3.11/site-packages/wal/wal.py", line 44, in run
    sys.exit(main())
             ^^^^^^
  File "/home/jzhang/.local/lib/python3.11/site-packages/wal/wal.py", line 95, in main
    resolved = resolve(optimized, start=wal.eval_context.global_environment.environment)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jzhang/.local/lib/python3.11/site-packages/wal/passes.py", line 182, in resolve
    return(resolve_vars(expr))
           ^^^^^^^^^^^^^^^^^^
  File "/home/jzhang/.local/lib/python3.11/site-packages/wal/passes.py", line 165, in resolve_vars
    return WList([resolve_vars(sub) for sub in expr], line_info=expr.line_info)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jzhang/.local/lib/python3.11/site-packages/wal/passes.py", line 165, in <listcomp>
    return WList([resolve_vars(sub) for sub in expr], line_info=expr.line_info)
                  ^^^^^^^^^^^^^^^^^
  File "/home/jzhang/.local/lib/python3.11/site-packages/wal/passes.py", line 165, in resolve_vars
    return WList([resolve_vars(sub) for sub in expr], line_info=expr.line_info)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jzhang/.local/lib/python3.11/site-packages/wal/passes.py", line 165, in <listcomp>
    return WList([resolve_vars(sub) for sub in expr], line_info=expr.line_info)
                  ^^^^^^^^^^^^^^^^^
  File "/home/jzhang/.local/lib/python3.11/site-packages/wal/passes.py", line 138, in resolve_vars
    env[binding[0].name] = True
        ~~~~~~~^^^
TypeError: 'Symbol' object is not subscriptable

I see. Can you share the trace file or the signal names generated for your array?

I just noticed it fails even if I comment out the array reference. Does this syntax look right to you?
(load "example.vcd")
(in-groups '("something.something.")
  (print CG ":")
  (print SIGNALS)
  (whenever (&& #clk #reset_n)
    (let [d 0]
     (print "d: " d)
    )
  )
)

Runs now thanks. I'll close this issue.

Great. If anything else comes up, feel free to contact me.

Actually when I try to access a signal within the array of structs I just see a bunch of Nones. Any ideas? It works fine when I print like like an integer from the top-level -- not within the array (print #clocks)

and this doesn't
(in-scope "something.something" (print #something))

There are two systems for evaluating signals at different places. Scopes and groups.
They work similarly but require different operators to resolve a signal.
If you use groups you need to use #signal, and if you use scopes you need to use ~signal.
Sop try either (in-scope "something.something" (print ~something)) or (in-group "something.something." (print #something)). Please note the added . for the group (scopes add the dot automatically).

I don't think either works, are we allowed to nest in-group/in-scope within another in-groups for example?

In WAL there are no structs, only signals from the waveform. How structs are mapped to signals is up to the simulator. If you can produce a minimal example, I can try to improve support for your use-case.

It just looks like
struct obj {
  logic [2:0] something;
}

struct obj2 {
  obj data;
}

What's confusing is the SIGNALS represents this how I would expect (.'s). But it doesn't get picked up when running. Perhaps it would be helpful if it does some fuzzy search on available variable names within the scope and/or outside of the scope to figure out what the var name should look like in WAL.

also why do undeclared signals return None values? Would it be better to throw an error?

Ok, I spend a little more time with SV arrays and structs. This is something which I have not worked with much in the past.
I simulated the following code using Verilator:
typedef struct {
  logic [2:0] something;
} obj;

typedef struct {
  obj data;
} obj2;

module tb();
  obj2 data [0:1];

  initial begin
    $dumpfile("trace.vcd");
    $dumpvars;
    data[0].data.something = 3'b101;
    #10
    data[0].data.something = 3'b010;
  end
endmodule

And then got this vcd:
$version Generated by VerilatedVcd $end
$timescale 1ps $end

 $scope module TOP $end
  $scope module tb $end
   $scope module data[0] $end
    $scope module data $end
     $var wire  3 # something [2:0] $end
    $upscope $end
   $upscope $end
   $scope module data[1] $end
    $scope module data $end
     $var wire  3 $ something [2:0] $end
    $upscope $end
   $upscope $end
  $upscope $end
 $upscope $end
$enddefinitions $end

#0
b101 #
b000 $
#10
b010 #

This already mostly worked as expected. I only had to slighlty correct the handling of scopes names in commit b7972b7.
Now WAL behaves like this:
WAL 0.8.1
Exit to OS or terminate running evaluations with CTRL-C
>-> (load "trace.vcd")
t0(0) >-> SIGNALS
("TOP.tb.data<0>.data.something" "TOP.tb.data<1>.data.something")
t0(0) >-> SCOPES
("TOP" "TOP.tb" "TOP.tb.data<0>" "TOP.tb.data<0>.data" "TOP.tb.data<1>" "TOP.tb.data<1>.data")
t0(0) >-> TOP.tb.data<0>.data.something
5
t0(0) >-> (in-scope 'TOP.tb.data<0>.data ~something)
5
t0(0) >->

WAL will now also throw an error if a scope or group resolution leads to an undefined signal. Thanks for the pointer.

Can you try the latest commit and let me know if that works for you?
I have not used much "advanced SystemVerilog" constructs, so I am very happy to hear your comments.

Works great now thanks


Shortcuts Duplicating on Homepage

If you are on the homepage and continue to click on "home". It will duplicate all of the shortcuts you have inside of the container.

Not gonna lie but that is pretty funny, if you click over 200 times, every disappears as well

time to get my 5000cps autoclicker and see what happens lol

Lol. Well I fixed it with 1 line of code in df23985. So have fun while it still is in BetterSEQTA+ :D


🐞 - inputDate doesn't reset value when FormControl .enable() and .reset() called together

Playground Link
https://stackblitz.com/edit/angular-axx3ke?file=src%2Fapp%2Fapp.component.ts
Description
We encountered this problem in InputDate.
If you create a form with the default disabled: true state and then call .reset() and .enable() on the form element associated with InputDate, the form value is reset, but the value inside the input in the interface is not cleared.
Similar problem in taiga-ui v3
https://stackblitz.com/edit/angular-ahinfu?file=src%2Fapp%2Fapp.component.ts,src%2Fapp%2Fapp.component.html
Angular version
18.2.2
Taiga UI version
4.4.1
Which browsers have you used?

[X] Chrome
[ ] Firefox
[X] Safari
[ ] Edge

Which operating systems have you used?

[X] macOS
[ ] Windows
[ ] Linux
[ ] iOS
[ ] Android

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


Possibility to set the package version on command line

Hello
I'm building a rust application using internal teamcity CI job. I want the build number to be part of the version of the binary (so eg. ./app --version knows from which build it came).
The only way I found so far is to let the build first edit the Cargo.toml (sed -i -e 's/^version = .*/version = "%build.version%"/' Cargo.toml), which seems ugly and fragile.
It would be great if I could somehow override the version from Cargo.toml through the command line ‒ either as a parameter or an environment variable.
Would something like that make sense? Are there plans to support it?

Is there any progress? Also looking for the feature to externally manipulate the package version. (CI is setting the version, Cargo.toml should not be changed).

Adding another +1 - we're setting the version upon release, and it'd be great to not need to edit Cargo.toml each time

By way of another +1 and showing analogous functionality in other toolchains, the .NET SDK allows for overriding version numbers at the command line with commands like dotnet build /p:Version=1.0.1 (https://andrewlock.net/version-vs-versionsuffix-vs-packageversion-what-do-they-all-mean/). I've often found that overriding package versions that way can be useful in using CI pipelines to control how packages are versioned.

absolutely same for me. CI and stuff.
I was going to use "built"'s GIT_VERSION for that, but we build in docker containers not passing .git inside. So this info is lost.

@Humandoodlebug
cargo build -Z unstable-options --config 'package.version="1.5.2"'

Will not work because --config overrides the cargo configuration, not the build definition in Cargo.toml

Editing the Cargo.toml isn't practical in some scenarios anyway - in Nix we don't really have conventional network access during build phases, and so it's not possible rewrite toml and regenerate lock files to workaround this.
I do see that there is a package macro that makes it easy to override the build version, falling back to the Cargo version, but it wouldn't be fun adding this to lots of Rust projects if Cargo could do it: https://docs.rs/git-version/latest/git_version/macro.git_version.html

Very surprising that this is still an open issue in feb 2022. 3 years have passed! probably lost/forgotten in the 1.2k issues.
Theres no good way to programmatically replace the version in cargo.toml.
Could we @ some of the active maintainers to get some visibility on this issue?

Is there a way to get cargo build to blend Cargo.toml version with [[bin]] name output? so that the cargo build --release makes a project-name-version.dll for example?

+1 here. I don't understand where the practice of statically specifying a version in a checked in manifest file comes from. I just want to release whatever is already checked in without having to commit again to change any manifests. It's very error prone unless you're using some fancy automated tools. It's so easy to overwrite a version that was already published previously if you release forgetting to change the manifest.
Being able to specify the version in the command line and completely omitting the version from the manifest would be my ideal workflow!

I suspect this is a large enough semantic change that this would need a major change proposal or an RFC and need a person to champion the proposal and implementation.  It is unlikely for someone else to pick up and do all of that leg work on behalf of someone interested in this work.  One challenge though is cargo is currently on a soft feature freeze and the cargo team is wanting to avoid distractions, including mentoring / shepherding, to be able to handle basic maintenance, finish currently committed work ,and to reduce technical debt so we can increase our capacity.
Things off the top of my head that would need to be figured out

Should the version field be made completely optional?
What are cargo's semantics without a version field and when no version is specified?
What all commands should accept a version?
How do we pass in versions, especially when running against multiple packages?
How do we help people when they miss specifying the version for one of the multiple packages?
How do we help workspace users with path dependencies?

Currently, to publish a crate with a path dependency, it also needs to have a version requirement specified.  That version requirement must match the crate its pointing to.  Tools like cargo-release handle updating version requirements of dependents so they don't become stale

Is there any prior art in other ecosystems that we can learn lessons from?

@epage This is a nice summary to figure out a considerate solution to this problem! Thanks for that!
It's a pity that it's unlikely that this effort would come from the core team, but it's understandable.
On the other hand, maybe an easier and good enough solution could be adding a flag (or env var) to pass the desired version to cargo so it could ignore the one specified in Cargo.toml? I'm absolutely unaware of cargo's internals, but if there's only one place where Cargo.toml is read to extract the version, then it seems like a pretty easy change to make.

On the other hand, maybe an easier and good enough solution could be adding a flag (or env var) to pass the desired version to cargo so it could ignore the one specified in Cargo.toml? I'm absolutely unaware of cargo's internals, but if there's only one place where Cargo.toml is read to extract the version, then it seems like a pretty easy change to make.

That still needs most of the questions I brought up answered.

In my (somewhat biased) opinion: there should be no static file defining the "current" version of a package at all. This should be determined at release time by looking up the VCS info or elsewhere.

Going back to your earlier comment

+1 here. I don't understand where the practice of statically specifying a version in a checked in manifest file comes from

I'd recommend doing a thought exercise to try to understand why so many ecosystems have static version fields.  It will both give you more empathy for other ways of doing things but could also help when proposing solutions.

@epage

I'd recommend doing a thought exercise to try to understand why so many ecosystems have static version fields. It will both give you more empathy for other ways of doing things but could also help when proposing solutions.

I really did the thought exercise, and what I posted was my conclusion :)
In my career (about 10 years) I've worked closely with several ecosystems: PHP, Python, JavaScript, Go (the longest time among others), and now I'm digging a bit into Rust. Among these, only Rust is so strict about having a static version in a file.

Go doesn't have it at all, it uses VCS for determining the package version. By looking at tags normally. To be fair it doesn't have a package repository either, and uses VCS for that too (they do have a proxy cache now). And I'm a big fan of this decision.
PHP doesn't need a static version file either.
In JavaScript there're tools to either bump the version automatically, or dynamically pass it at release time (if I'm not missing anything).
In Python there's a version field, but the config is defined in setup.py file, which can run arbitrary code. So one could fetch the version from elsewhere if it's necessary. Again, if I'm not missing anything.

So in my experience the need for a static version file is roughly 50/50 across different ecosystems.
My conclusion is: I don't understand where the practice is coming from, nor do I see any usefulness in it. I never appreciated having it, and in my, admittedly personal and biased opinion, having a static version file checked in to the VCS has zero benefits.
I accidentally discovered this issue today, and to my surprise looks like I'm not the only person wondering about these design decisions, which makes me glad that I'm not the only weirdo complaining about it :)

And, don't get me wrong, I'm sure there's reasons why people decided to make static version files a requirement. It's probably because of my ignorance that I don't see it. But, being unable to overwrite it dynamically is what surprises me, and it's what I'm advocating for to be implemented in one way or another.

Trying to be useful, I give my opinionated answers to the questions you posted, in case it could be helpful if someone is willing to drive this forward:

Should the version field be made completely optional?

Yes. I think it should possible to omit the version in Cargo.toml.

What are cargo's semantics without a version field and when no version is specified?

Fail to release. Display a warning about a missing version providing options to either specify it in Cargo.toml or dynamically via flag or env var.

What all commands should accept a version?

I'm unaware about the internal of Cargo, but probably any command that is reading Cargo.toml to extract the version in the current implementation.

How do we pass in versions, especially when running against multiple packages?

I understand that this is the tricky one here. I see several options with different levels of user-friendliness:

Require static version in case of a multi-package workspace.
Be able to define versions for each package separately similar to --version=package-1=1.0.0,package-2=2.0.0 or anything like that.
Have an explicit integration with different VCS and have conventions about how to name tags (or similar concepts). E.g. <package-name>/<version>.
Only allow releasing one package at a time (probably not practical when there're dependencies between local packages).
Probably many other options and ways to do it...

How do we help people when they miss specifying the version for one of the multiple packages?

Similar to the second answer above. Fail to release and provide guidance to fix it.

How do we help workspace users with path dependencies?

Currently, to publish a crate with a path dependency, it also needs to have a version requirement specified. That version requirement must match - the crate its pointing to. Tools like cargo-release handle updating version requirements of dependents so they don't become stale

That's even trickier. I don't have answer for it from the top of my head. Maybe in this case dynamic version release should be impossible. Or maybe it could depend on some hash identifier of the path dependency instead of semver (which I don't know if is a thing in Cargo at all).

Is there any prior art in other ecosystems that we can learn lessons from?

I described my experience with different ecosystems in the previous comments: https://github.com/rust-lang/cargo/issues/6583#issuecomment-1131675725
My favorite one is Go. Let the VCS be the source of truth, have conventions on how to extract versions from VCS, have a proxy in front of the VCS + checksum database to provide availability, reliability, redundancy, security and other properties. I understand this is way different from many other ecosystems, and probably impractical for Cargo at this point.

In discussing https://github.com/killercup/cargo-edit/issues/782, something I was thinking about is if the cargo version number is the best tool for tracking end-user version numbers and in some cases where people want to inject versions, it'd be better to inject it directly into the application rather than the manifest.
You see this version split in some commercial applications like Windows where they have different version numbers depending on the context.  I've also seen this with other proprietary software.
This also makes life a bit easier decoupling marketing from software development, kind of like how some people use code names for projects, not to obscure it, but because they need something to call it while marketing is coming up with a name (we understand, naming is hard)

I found a cargo plugin called cargo-bump it seems to be doing exactly that in a nice way of a cargo plugin:
https://crates.io/crates/cargo-bump

@John15321 this issue is about setting the version without changing the source code.  I do not believe there is yet an issue for cargo officially having a new subcommand for doing this and would recommend creating a separate issue if that is what you want.
There are also a couple of tools related to cargo bump mentioned in this thread

cargo release, particularly cargo release version
cargo-edit's cargo set-version

There is also cargo semver

@John15321 this issue is about setting the version without changing the source code.  I do not believe there is yet an issue for cargo officially having a new subcommand for doing this and would recommend creating a separate issue if that is what you want.
There are also a couple of tools related to cargo bump mentioned in this thread

cargo release, particularly cargo release version
cargo-edit's cargo set-version

There is also cargo semver

Sorry I did not have that in mind. This issue popped up when I was searching for a solution to changing the version in the toml file using a cli tool, and simply given that I have found one I wanted to share as most likely other people would find this issue as well with the same problem at hand

+1 here. It would be great to have a way to do this. It would be even better if it is not required to publish the crate to bump the crate version.

Hello, I've found myself here as someone doing a greenfield project at a large company where most of the current tools we build in CI use dotnet's ability to set the version baked into a binary at build time (shown somewhere far above) on the command line. While carefully controlling a semver in the Cargo.toml is ideal - when your team owns too many CLI tools, and needs to ship the automatically - a generated date based version number becomes very useful. I was quite surprised to find that cargo build --config package.name=1.2.3-1 and similar attempts, don't work for this. As I'm trying to sway folks into writing more tools in Rust, it's a hard up-hill battle at big companies and little things like this result in us having to put other checks in place, reminders to bump versions, and then parse out what it is in CI. In the meantime, I'm hoping the cargo set-version plugin will work, but now we have to install that in the CI pipeline too :(.

I was curious about this problem so I prototyped how I originally was assuming this would work, which was setting the CARGO_PKG_VERSION_* variables before running cargo commands would override whatever cargo was about to set.
In my prototype I added this before the CARGO_PKG_VERSION_* variables are set in compilation.rs,
https://github.com/juliusl/cargo/blob/0de91c89e6479016d0ed8719fdc2947044335b36/src/cargo/core/compiler/compilation.rs#L329
Here is what I wrote,
        // Determine if this compilation is for a dependency or for a workspace assembly
        let rpath = self.config.registry_base_path();
        let rpath = rpath.as_path_unlocked();

        // If the manifest path starts with the registry path, then it is a compilation for a dependency
        let version = if !pkg.manifest_path().starts_with(rpath) {
            // Handle pkg_version values
            let pkg_version = pkg.version();
            let major = if let Ok(major) = std::env::var("CARGO_PKG_VERSION_MAJOR") {
                major.parse().unwrap_or(pkg_version.major)
            } else {
                pkg_version.major
            };
            let minor = if let Ok(minor) = std::env::var("CARGO_PKG_VERSION_MINOR") {
                minor.parse().unwrap_or(pkg_version.minor)
            } else {
                pkg_version.minor
            };
            let patch = if let Ok(patch) = std::env::var("CARGO_PKG_VERSION_PATCH") {
                patch.parse().unwrap_or(pkg_version.patch)
            } else {
                pkg_version.patch
            };
            let pre = if let Ok(pre) = std::env::var("CARGO_PKG_VERSION_PRE") {
                pre
            } else {
                pkg_version.pre.to_string()
            };

            semver::Version {
                major,
                minor,
                patch,
                pre: pre.parse().unwrap_or(pkg_version.pre.clone()),
                build: pkg_version.build.clone(),
            }
        } else {
            pkg.version().clone()
        };

As a test I created a small app with this as the main.rs:
fn main() {
    println!("Hello, world!");

    println!("{}", env!("CARGO_PKG_VERSION"));
}

And I initialized with,
cargo init
cargo add tokio

I wanted to add a dependency because I had a suspicion that part of the complexity is that if you handle this by setting an env variable it would apply to all dependencies being compiled. I confirmed that fact and so I handle this issue by checking the manifest path, to figure out if the manifest is from the current working directory or if it was from the cargo registry.
Finally, I tested the above code:
❯ CARGO_PKG_VERSION_PATCH=1004 ../cargo/target/debug/cargo build                                                                                testver -> master ?
   Compiling pin-project-lite v0.2.13
   Compiling tokio v1.32.0
   Compiling testver v0.1.0 (/home/juliusl/rs/testver)
    Finished dev [unoptimized + debuginfo] target(s) in 1.02s
❯ ./target/debug/testver                                                                                testver -> master ?
Hello, world!
0.1.1004

I feel like this approach is straightforward enough and is intuitive/aligned with how the rest of cargo works, especially with usage in a CI pipeline.
So, I was wanted to post here and get some feedback and possibly start a PR? Possible behind a --allow-version-overrides arg action?

Hello, I've found myself here as someone doing a greenfield project at a large company where most of the current tools we build in CI use dotnet's ability to set the version baked into a binary at build time (shown somewhere far above) on the command line. While carefully controlling a semver in the Cargo.toml is ideal - when your team owns too many CLI tools, and needs to ship and consume them automatically, a generated date-based version number becomes very useful. I was quite surprised to find that cargo build --config package.name=1.2.3-1 and similar attempts, don't work for this. As I'm trying to sway folks into writing more tools in Rust, it's a hard up-hill battle at big companies and little things like this result in us having to put other checks in place, reminders to bump versions, and then parse out what it is in CI. In the meantime, I'm hoping the cargo set-version plugin will work, but now we have to install that in the CI pipeline too :(.

Hi @kyle-rader-msft. We have solved a very similar problem in the following way:

Setting all versions to 0.0.0 in all Cargo.toml files. This never changes. Cargo always treats all our crates as version 0.0.0
Having a separate crate for version computation. This crate's build.rs computes the desired version number (can be based off of git commit hash, date or whatever) and exposes the version as a constant in its lib.rs (https://github.com/mullvad/mullvadvpn-app/tree/main/mullvad-version)
All crates that needs the at-build-time computed version depends on the previous version-computation-crate and uses the constant:

For clap version: https://github.com/mullvad/mullvadvpn-app/blob/main/mullvad-cli/src/main.rs#L15
For Windows metadata: https://github.com/mullvad/mullvadvpn-app/blob/main/mullvad-cli/build.rs#L10

@faern tank you so much sharing that strategy! I need to delve into what's possible with build.rs :) But off the cuff, this sounds much better than my powershell and bash scripts to live update the Cargo.toml during CI... I'll try this out!

FYI making the version field optional is effectively approved, see #12786. It comes with the limitation that you can't publish to a registry.
I think @faer's solution is great and was what I was getting at with my earlier comment about separating the role of your product's version from Cargo.toml.
What id like to know if there are people who that solution doesn't work for. Most likely that would be people who have a reason for dynamically setting the version and publish to crates.io.

Thanks for tackling this @epage

#12786 is now merged.
Now that package.version is optional, I feel like this helps us better focus on that field being a tool for registry packages and that it might not be as relevant to products that are not being published to a registry.
In light of that, I propose to the cargo team that we close this issue and instead encourage people to look up the marketing version of their application as they best see fit (e.g. see https://github.com/rust-lang/cargo/issues/6583#issuecomment-1702417194), rather than trying to overload package.version as both the registry version and the marketing version (think Windows build numbers vs marketing version).  If there is a reason the registry version needs to be dynamic, let us know!

I need the package version to be dynamic (and was previously following #12144).
I use git for version control, so the exact version of my package is stored there, rather than in Cargo.toml. Duplicating the information into Cargo.toml is far from ideal:

There's an overhead of updating Cargo.toml with the version defined in version control.
Defining the same value in two places means that they can diverge, at which point it is unclear which one is correct.
Anyone working on the codebase will permanently have a dirty checkout. They can try committing the new version into Cargo.toml, but it would be out-of-sync immediately after committing.

Ideally, if the current commit matches a git-tag, then that tag is the current version. If the current commit is 20 commit of the last tag,v0.1.0, then the version would be v0.1.0+20. This is essentially the same idea proposed by op in https://github.com/rust-lang/cargo/issues/12144.
As prior art on this topic, in Python-world I use setuptools-scm, which does exactly this: https://github.com/pypa/setuptools_scm

@WhyNotHugo is your version for use in the package registry or is it a marketing version?
If its for marketing reasons, then my question would be "why does it need to be in Cargo.toml at all?".
If for the registry, it has the challenges of

No way to specify path+registry dependencies without having to commit on version updates without something like #11133 which was originally deferred out of #8415 due to fundamental flaws that were found during implementation

We also have #6126 which asks for us to adopt the opposite workflow and always specify the version

Cargo having to decide on what default tag policies should be natively supported and providing a customization point for non-native tag formats

Being opinionated is easier when you are a brand new build tool being used for brand new projects
We are cautious in what policies we standardize due to our compatibility requirements
The precedence of setuptools_scm helps but the Python ecosystem doesn't have a native concept of a workspace which further complicates things

Being incompatible with shallow clones when being used as a git dependency which we have active work towards supporting

Git dependencies are important for registry packages for being able to test out in-work changes in libraries
Shallow clone is important for performance, more so for when projects are always using them but having to conditionalize their support is less than ideal

Requires more work on each cargo invocation

Some caching could help reduce it
This would only apply to non-registry dependencies as we'd have to put the version into the .crate file's Cargo.toml

Looking at the above, it feels like we can make something work but that it would have enough caveats and limitations that it wouldn't be up to the expected quality for a cargo feature.
That leaves having some kind of plugin system.  At that point, I think of the cost (implementation + maintenance + user support) compared to the benefit.  The benefits seems relatively small to me especially when there is the "workaround" of release management tools which we will now be pointing people to as of #12745.

There is no "marketing version" or anything alike. Please see https://github.com/rust-lang/cargo/issues/12144 for more in-depth details; what I explained above is covered there in greater detail. I'm just talking about publishing regular libraries and applications written in Rust.

The precedence of setuptools_scm helps but the Python ecosystem doesn't have a native concept of a workspace which further complicates things

Python supports multiple libraries in a single git repository too. For overly complex scenarios, setuptools_scm allow configuring the exact git command used to extract the version. It is perfectly possible to filter tags. E.g.: a package in a multi-package repository might only respect tags prefixed with its name.

Being incompatible with shallow clones when being used as a git dependency which we have active work towards supporting

If somebody is explicitly avoiding version metadata when fetching code, then it is expected that version metadata will be absent. I'm not sure that I understand the issue here.

Looking at the above, it feels like we can make something work but that it would have enough caveats and limitations that it wouldn't be up to the expected quality for a cargo feature.

Let's not let perfect be the enemy of good. The current approach is terrible: someone needs to remember to copy-paste the version into Cargo.toml before tagging a new version. That someone also needs to remember to update the lockfile after updating the version and creating the tag (I've made several bug reports to projects that forget to do this step). Essentially, the version must be specified two and a half times (in concert) for each release.
And builds made from intermediate versions (e.g.: N commits after the last tag) just drag the version from the last tag, rather than having a version that identifies them as distinct.

That leaves having some kind of plugin system. At that point, I think of the cost (implementation + maintenance + user support) compared to the benefit. The benefits seems relatively small to me especially when there is the "workaround" of release management tools which we will now be pointing people to as of https://github.com/rust-lang/cargo/pull/12745.

I do agree that plugins might be an overkill here. Something simpler should definitely be the aim.
I looked briefly into the linked PR, but the suggested tools don't make sense to me. For example, cargo-release takes care of publishing and tagging a release. The usual approach  for releasing a new version it to create a git-tag, then push that to CI and CI builds the package and pushes it to a registry or wherever. cargo-release seems to fit perfectly when git isn't you method of version control.
When I tag v1.2.0, I am establishing that the given commit is v1.2.0. The fact that cargo needs to read the value from its own source is an annoyance, because we suddenly need tooling to feed the version from the version control system into cargo. Of course, it's possible to put together a small set of shells scripts to patch this all over the place, but that sounds immensely brittle.

There is no "marketing version" or anything alike. Please see #12144 for more in-depth details; what I explained above is covered there in greater detail. I'm just talking about publishing regular libraries and applications written in Rust.

I did look at that and the details I was asking for weren't there, hence why I asked.

The precedence of setuptools_scm helps but the Python ecosystem doesn't have a native concept of a workspace which further complicates things

Python supports multiple libraries in a single git repository too. For overly complex scenarios, setuptools_scm allow configuring the exact git command used to extract the version. It is perfectly possible to filter tags. E.g.: a package in a multi-package repository might only respect tags prefixed with its name.

There is a difference in expectations for a solutions to problems when contrasting python's "here are the tools, do it on your own" and cargo's "here is a first-class, native solution with a smooth workflow".  We can learn from Python's experience but the Python experience is not optimized for the problems we'll have (it its janky).

Let's not let perfect be the enemy of good. The current approach is terrible: someone needs to remember to copy-paste the version into Cargo.toml before tagging a new version.

I agree with the sentiment generally but taking it too far you gloss over fundamental problems which I think is happening here.. Without solving path dependencies, the problem hasn't gone away unless you restrict this to just single packages.  That is a pretty dramatic restriction.  Besides likely leading to more frustration when a feature is accessible sometimes but not always, it makes it unclear if a solution that gets stabilized will scale to workspaces.  We are then stuck with supporting that solution for ... forever, increasing the load for the cargo team.

. For example, cargo-release takes care of publishing and tagging a release. The usual approach for releasing a new version it to create a git-tag, then push that to CI and CI builds the package and pushes it to a registry or wherever. cargo-release seems to fit perfectly when git isn't you method of version control.

Let's not over-generalize.  That is your workflow but I've not seen that generally applied in the Rust community.  Instead, I've seen a lot of people fear release automation to the point that they don't even want to adopt a local-only tool that is dry-run by default and optionally logs everything it does to the screen.

@epage:

Now that package.version is optional

Maybe I'm missing something, but this, with cargo 1.78.0, doesn't seem to behave how I'd expect after reading this entire conversation:

Remove [package] version = "x.x.x" from Cargo.toml
cargo clean
Build with --config:

$ cargo build --config 'package.version="1.2.3"'
   Compiling my-program v0.0.0

I would expect the newly set version number to be applied as the build version.
I'm also using clap with the automatic -V/--version feature, and after building with this, it prints:
$ my-program --version
my-program 0.0.0

I would expect this to reflect the package.version value, as it 100% would if it was set in Cargo.toml instead.
This doesn't seem like "set the package version dynamically" is working? There's a good possibility I've messed something up though.
FWIW, my use case is that I need the version of my program, built in CI, to be the same as other programs built in the same pipeline (monorepo), so rather than modifying Cargo.toml with a sed script, I'm looking to pass the overall version to each program in the pipeline definition. This works fine for Python packages, but I'm having trouble with doing the same for Rust builds. I'm not pushing anything to crates.io BTW, it's all in-house.
If a sed script is current best practice, so be it.

@DavidAntliff See this comment: https://github.com/rust-lang/cargo/issues/6583#issuecomment-1783242798

Now that package.version is optional, I feel like this helps us better focus on that field being a tool for registry packages and that it might not be as relevant to products that are not being published to a registry.

You are not really supposed to put a product version into the Cargo version field, according to this comment. It's versioning for crates.io style registries.

instead encourage people to look up the marketing version of their application as they best see fit (e.g. see https://github.com/rust-lang/cargo/issues/6583#issuecomment-1702417194), rather than trying to overload package.version as both the registry version and the marketing version

It links to my previous comment about how we have solved basically the same problem you have. You will find it is much easier if you stop trying to cram the version into Cargo's version field altogether :)

That is your workflow but I've not seen that generally applied in the Rust community. Instead, I've seen a lot of people fear release automation to the point that they don't even want to adopt a local-only tool that is dry-run by default and optionally logs everything it does to the screen.

I feel like this a chicken and egg problem. Of course Rust community doesn't apply that workflow because it's not supported by Cargo or any other tools. Of course they fear release automation if the only way to implement it is with brittle scripts.
I find it surprising that using a Version Control System as a single source of truth for managing versions of your software is a controversial topic.

I made a draft patch to solve this. It reads the value of a environment variable to decide the default version. If the variable is unset or the value is not a valid SemVer version, it falls back to use 0.0.0. Since the  variable is purely suggestive, I named the variable CARGO_SUGGESTED_PKG_VERSION.
This design has a limit: when building many packages in one call of cargo, all unversioned packages will be affected. Since many build tools for other languages also behave like this, I believe this is an acceptable trade-off for a simple design.
If this design is not fundamentally flawed, I'd like to improve it to make it land. Any suggestions?

As mentioned in your PR, this is nominated for being closed.
I'd recommend reviewing the thread and seeing if you have anything to add to what has been said.

I should have mentioned that we (my workmates and I) have a policy to increase versions fast. For example, we increase the {MINOR} part everyday. This make versions in files more painful.
Currently we handle this with generation temporary manifests. But this isn't very lightweight.

I propose that we give this a try on workspace manifests only. It will be enough to solve the problems of those who want this feature without creating too much complexities or risks.

Can we drop the S-propose-close? This is one of the most annoying issues when using Cargo to publish crates to a registry.
The proposal to close mentions something about "marking version", simply because someone else further up in the comments mentioned such a concept. The concept of "marketing version" is out of scope on this issue. Let's not use the fact that someone mentioned an out-of-scope topic as an excuse to close the issue.
The issue is quite real for the simplest case of a single crate in a git repository with a single version: the version of the crate used by cargo and used to publish to a registry.
What's being proposed here is "let's provide a mechanism so that the version is read from the version control system".
Currently, someone needs to re-write the file each time a new version is created. This is needless churn, meaningless bureaucracy. It's a requirement to duplicate information. And it needs to be done before creating the tag, otherwise fetching the tag from git will result in inconsistent version numbers.
In fact, the very idea of storing the version number inside the file is a design issue: the version for a project is then stored in two places: in the version control system and in Cargo.toml. These can be different, leading to ambiguity.
Yes, this approach was the norm back in the days of CVS. Git has first-class tags, we don't need to imitate design patterns from the days of CVS.

What's being proposed here is "let's provide a mechanism so that the version is read from the version control system".

"A mechanism to pass the version from outside sources to cargo without modifying any file" would be a more accurate description. VCSs are typical such sources. But other sources (such as dates) are also used in various cases.

@sunhaitao

I should have mentioned that we (my workmates and I) have a policy to increase versions fast. For example, we increase the {MINOR} part everyday. This make versions in files more painful.
Currently we handle this with generating temporary manifests. But this isn't very lightweight.

Could you go into more detail on this?  I assume you are bumping the version every day because you are publishing to a registry every day?  Is this crates.io and are these meant for people outside your group to use?  What problem are you solving by releasing so rapidly?
To be clear, I'm not questioning doing it but wanting to better understand your use case.  I tend to publish my packages after every end-user noticeable change.

Can we drop the S-propose-close? This is one of the most annoying issues when using Cargo to publish crates to a registry.

As there are use cases beyond what I acknowledged in my comment, I'll remove it.  However, this is unlikely to move forward any time soon and there is a good chance it will still end up closed, see below.

The proposal to close mentions something about "marking version", simply because someone else further up in the comments mentioned such a concept. The concept of "marketing version" is out of scope on this issue. Let's not use the fact that someone mentioned an out-of-scope topic as an excuse to close the issue.

When discussing why a feature is needed, it is fully in scope to discuss use cases for why its needed and to see if there are better alternatives.  That is not out of scope.  In fact, the original issue sounds very much like its about a marketing version and not a registry version.

The issue is quite real for the simplest case of a single crate in a git repository with a single version: the version of the crate used by cargo and used to publish to a registry.

And as discussed here and here, we need to support more than that simple workflow and we'd need to work out the design considerations for those and recognize there are costs and whether we are willing to accept them.
This is not the type of design work that a couple of answers on a thread will do.  Due to all of the interactions and potential costs, this likely eventually become an RFC.

This is needless churn, meaningless bureaucracy.

I think it would be a helpful exercise to consider why it works the way it does rather than dismiss it out right.  Its much harder to evaluate how to improve a system if you can't acknowledge what problems it is solving.

As an alternative approach, I've considered writing a wrapper script that the above steps for me and then publishes the crate.
he main caveats with this approach are:

cloning the git-tag won't produce the same package as the one submitted to crates.io
consumers can't use a subsequent git-commit via cargo because the version won't match the expectation.

Before I forget, I thought this post about Python's dynamic metadata interesting: https://lucumr.pocoo.org/2024/11/26/python-packaging-metadata/

For cases I just verified, pip wheel generates metadata by saving calculated dynamic values for both setup.py-based and pyproject.toml-based packages. So the problem may only exists on other distribution forms.

One difference between Python and Cargo is that Cargo rewrites the static metadata on publish, so we can take something dynamic and make it static, and we have an Index. However, that doesn't completely remove the complexities.

I think the good balance is: The final package should have static metadata. But they don't all have to be hard-coded in the source. Some of them should be able to be decided on publish. Allowing all of them being so dynamic seems unnecessary.

@epage

Could you go into more detail on this?

Actually, we align the {MINOR} part to "How many days have passed since we started working on this {MAJOR} version". If we pause works on a package for a while, the {MINOR} part will jump several numbers on resuming.
And we don't publish all those versions to end users. Many of them only exist on developer machines. Some on build machines. Only few of them are released out.

@weihanglo
It is similar on frequently assigning a version. But on build machines, we only dare to touch the  part on each commit.
Anyway, changing the version a little on each build is a important use case for this feature.


#415: Images do not show up in cards where space in filename

Fixes Issue #415
- Summary
In the current behavior, cards will not show images that have a space in the filename. The solution was to encode spaces to %20 in the normalizePath() method. A more general path encoding should probably be put in place.
- Test plan

Added new test markdown entry in example/index.html
Ran example to visually inspect that the entries render, old and new

- Description for the changelog
normalizePath() now encodes white space to %20
- A picture of a cute animal (not mandatory but encouraged)

What is the general timing on a merge? Not pushing... just have clients griping at me about the photos not showing. Would love to tell them something.


Step validator on numeric inputs not working correctly

Subject of the issue
I think that the step validator should use a different formula.
Your environment
jquery, which is 3.4.1 and jquery validate 1.19.
Steps to reproduce
Use a numeric input with min=17 and step=5 and try to enter a value like 87. It will trigger the step validator and say the value must be divisible by 5.
Expected behaviour
If the validator would subtract the min value from the entered value, and then divide by the step value, 87 would/should pass validation.
Actual behaviour
The step validator is triggering when it should not.

Unfortunately, I think this is how Mozilla expect it to work.. https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/step
The library code is slightly wrong in that it should minimum the min value from the current value before finding the modular of step though i.e. (toInt(value) - toInt(min)) % toInt(param) !== 0 see:
https://github.com/jquery-validation/jquery-validation/blob/98fbc5f4287b9e580be6c1404094e9ae31b4abb2/src/core.js#L1548-L1551
I will probably add a new validation method to work out the 'minimum step' myself.


build tools: bring GNU Arm Embedded Toolchain Version 9 to CI and setup scripts

Describe problem solved by this pull request
Following the validation of the binaries built with GNU Arm Embedded Toolchain Version 9-2019-q4-major in https://github.com/PX4/Firmware/issues/14580, I am bringing the new version to both CI and setup scripts.
Describe your solution

Update container tags with the tag that brought version 9 to px4-dev-nuttx-bionic and px4-dev-nuttx-focal;
Update setup scripts, with a verification for an existing version there, and if it isn't version 9, then it does a replacement inline with the new path for the version 9.

@MaEtUgR seems like we are still having issues in the Nuttx side of things - have you been testing master lately with the new GCC9 toolchain?

@dagar @davids5 we continue to run into some errors here, but this time I think these might be false positives regarding the usage of strncpy, which seems to be present since GCC 8.2. Should we silent these where possible? And if yes, instead of using #pragma GCC diagnostic ignored..., where could we add -Wno-stringop-truncation?

Note that I tried adding add_compile_options(-Wno-error=stringop-truncation) to https://github.com/PX4/Firmware/blob/master/boards/px4/fmu-v5/optimized.cmake but same luck.

@TSC21 it may be a bug in the code. Have a look at it.

@TSC21 it may be a bug in the code. Have a look at it.

I did and I didn't see anything that might lead to a bug. Further research lead me to think that this might be actually a problem in the compiler, given that several users reported the same.

Already solved. Closing


Fix typo in the docs

Q
A

Documentation
yes

Bugfix
no

BC Break
no

New Feature
no

RFC
no

QA
no

Description

@laminas/technical-steering-committee
Hm, out of curiosity.
Adding a new release just to update documentation fixes (without changing any code behavior) adds some kind of noise to composer update and also on packagist.
Should we think about having an additional way to fix documentation without yet releasing a new tag?

@boesing

only a typo fix
without changing any code
some kind of noise
…

Exactly this has already been discussed in a TSC meeting. (Unfortunately, I don't remember which meeting it was.)


Incident Density is not producing valid results

Incident Density calls the Optimized Hot Spot tool. The surface output was producing output without the tool failing, however i noticed OHS doesn't like geographic coordinate systems... this is what was producing the bizarre results.
To fix this problem i edited the model for Incident Density and now project the input points and the input boundary, before OHS runs. Also added the parameter to the model for the projects. Made the change in both Pro and 10.4, as i was seeing it in both places.
Results should look something like below, patterns and sizes will vary depending on your test data.

┆Issue is synchronized with this Asana task

So as of today's running of these tools the output I'm getting is the same as the picture above so I'm assuming this is fixed.


Create an onboarding tutorial

something along the line of:

create AKS cluster
create MSI
assign MSI to the VM/VMSS
make all
make docker-build
make docker-push
make deploy
kubectl apply -f acrpullbinding_sample.yaml
kubectl get secret test-msi-acrpull-secret -oyaml
kubectl get serviceaccount default -oyaml

This is now seen in the end-to-end test as of #71


Clean dead code

It looks not meaningful annotation, feel free to close this PR if this is kept here for reference.
ping @tonistiigi @docker/maintainers
Signed-off-by: Zhang Wei<EMAIL_ADDRESS>

LGTM http://stackexchange.com/email/manage/8757/860930f330638a879dc5cdf1157e9f0289d022c0333a76392ce5ab6a908d133c

LGTM, but I also don't know if this was kept around for reference


Export rows as displayed with sorting applied

This change allows the rows to be exported as displayed in the table.  This considers the following:

only sorted rows are taken (as previous implementation)
sorting order of the rows is used
grouped row header is not exported
collapsed groups are not exported

Thanks for your contribution!
Could you provide code and steps to reproduce the issue?

Hello,
Here is a minimum viable example to demonstrate the issue.  Using the Olympic sample data as input, sort on the country name.  In the sorted state, "Afghanistan" will be on the top.  However, the export to a dataframe yields the rows in the original input state.
The intent of the PR is to output the rows as they are displayed in the sorting order.  The graphic below shows the results with the current version of the ipyagrrid widget.  With the changes to the JS backend, the sorted order (as displayed) will also be present in the dataframe.
Execute in a Jupyter notebook with ipyaggrid and pandas installed.
Step 1: Create Grid
import os
import json
import numpy as np
import pandas as pd
import urllib.request as ur
import ipywidgets as widgets
from ipyaggrid import Grid

url = 'https://www.ag-grid.com/example-assets/olympic-winners.json'
with ur.urlopen(url) as res:
    data = json.loads(res.read().decode('utf-8'))

columnDefs = [
    {'headerName': "Country", 'field': "country"},
    {'headerName': "Year", 'field': "year"},
    {'headerName': "Sport", 'field': "sport"},
    {'headerName': "Athlete", 'field': "athlete"},
    {'headerName': "Gold", 'field': "gold"},
];

gridOptions = {
    'enableColResize': True,
    'columnDefs': columnDefs,
    'enableSorting':True,
    'defaultColDef': {'sortable': True}
};

grid1 = Grid(quick_filter=True,
             theme='ag-theme-balham',
             compress_data=True,
             grid_options=gridOptions,
             grid_data=data,
             columns_fit="auto")
grid1

Step 2: Sort table by "country" column
Step 3:  Output the dataframe:
grid1.grid_data_out.get('grid')
Result:  Order of the output dataframe is the same as the original data; the sorting order of the user interaction was not applied to the output
Fix:  As described in PR code

Thank you for this description.
If I try this with your PR, it doesn't work for me. The output op grid1.grid_data_out.get('grid') is still in the original order.

My appologies.  I realize now that it was because in my version, I have both  #23 and this PR combined (they should be combined to fully test this case).  The reason why it didn't work for you is that in this version, the sync_on_sort event is not applied (see #23).  With this additional event, it causes a new output of the grid when sorted.  Normally, user changes to the order did nothing for a grid update event.
Here is the revised version to try when combined with #23.  The appropriate flags are added in this case:
import os
import json
import numpy as np
import pandas as pd
import urllib.request as ur
import ipywidgets as widgets
from ipyaggrid import Grid

url = 'https://www.ag-grid.com/example-assets/olympic-winners.json'
with ur.urlopen(url) as res:
    data = json.loads(res.read().decode('utf-8'))

columnDefs = [
    {'headerName': "Country", 'field': "country"},
    {'headerName': "Year", 'field': "year"},
    {'headerName': "Sport", 'field': "sport"},
    {'headerName': "Athlete", 'field': "athlete"},
    {'headerName': "Gold", 'field': "gold"},
]

gridOptions = {
    'enableColResize': True,
    'columnDefs': columnDefs,
    'enableSorting':True,
    'defaultColDef': {'sortable': True}
}

grid1 = Grid(
    quick_filter=True,
    theme='ag-theme-balham',
    compress_data=True,
    grid_options=gridOptions,
    sync_grid=True,     # <- normal sync
    sync_on_sort=True,  # <- sync event when sorted
    grid_data=data,
    columns_fit="auto"
)

grid1

@maartenbreddels : any outlook on incorporating these PRs #22, #23, #24 ?

Yes, we had some work to do, which eventually landed in ipyaggrid https://github.com/widgetti/ipyaggrid/pull/32 which allows us to do visual tests. This means we will not have regressions, and expected behaviour.
Are you willing to try this?  Basically you can rewrite your example as a test. See https://solara.dev/docs/howto/testing for the documentation. I think this feature should only be tested with the solara_test fixture since we only test a feature that we expect to behave the same in all jupyter environments.
Note that this requires a new release of solara, which I plan to do soon. Otherwise you can see #32 how the dev install of solara is done.

I can give that a try this week to get the tests working.  A good excercise to learn as well 👍 . Thanks!

If you run into issues, I'm happy to help. It will be good feedback for us if the documentation is good enough.

https://github.com/widgetti/ipyaggrid/pull/32 is merged, so if you rebase on master, you already have the directory structure you need setup.