Azure Analysis Services: added support for new SKUs

Description
Added new SKUs for Azure Analysis Services: B1, B2, S0.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] I have read the contribution guidelines.
[ ] The pull request does not introduce breaking changes.

General Guidelines

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

SDK Generation Guidelines

[ ] If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
[ ] The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as a link to the swagger spec, used to generate the code.
[ ] The project.json and AssemblyInfo.cs files have been updated with the new version of the SDK.

Can one of the admins verify this patch?

@igor-uzhviev,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@azuresdkci test this please

what exactly should I test? This code just adds 5 new constants.

The AutoRest branch is closed until Monday, please open this PR then


Fix Makefile all target

Why we need this PR
Makefile's "all" target still has the old "container-build" dependency,
which was replaced by "container-build-ocp".
Changes made
Replace "container-build" dependency with "container-build-ocp" in Makefile target.

I think you can close this PR in favor of #317

@clobrano I think you can close this PR in favor of https://github.com/medik8s/node-healthcheck-operator/pull/317

I didn't notice it was already done, thanks!
/close


StrawberryShake v12 that says it supports the graphql-ws protocol defaults its subprotocol to the wrong spec

Is your feature request related to a problem?
Hello!  I saw that the StrawberryShake  GQL Client had documentation to support the graphql-ws protocol as located here: https://chillicream.com/docs/strawberryshake/networking#protocols
But in the code I see that the default protocol that gets added is "graphql-ws" and not "graphql-transport-ws" (which the official documentation here states should be the correct subprotocol, I know, its weird that the project is called graphql-ws but the sub protocol they expect is graphql-transport-ws) which is what my graphql server im trying to connect to is using (not currently using hotchocolate) and the traffic manager that makes sure the protocols match up give me an error, since i cannot specify only "graphql-transport-ws" as the sole protocol.
Here is the file in question that has that default set: https://github.com/ChilliCream/hotchocolate/blob/d412413d5f93f74e897c1253e4786f61fc59f773/src/StrawberryShake/Client/src/Transport.WebSockets/Protocols/GraphQLWebSocket/GraphQLWebSocketProtocolFactory.cs
The solution you'd like
I would love the ability to be able to set my own default protocol or have the option to configure my StrawberryShake client to use graphql-transport-ws protocol for subscriptions.  I assume the change would be in this file: https://github.com/ChilliCream/hotchocolate/blob/d412413d5f93f74e897c1253e4786f61fc59f773/src/StrawberryShake/Client/src/Transport.WebSockets/Protocols/GraphQLWebSocket/GraphQLWebSocketProtocolFactory.cs
(I tried to make an edit myself to submit as a suggestion but it didnt work locally how i thought it would, so wondering if someone in the community can help me or maybe look into this to see if im correct or not)
Product
Strawberry Shake

Having same issue after tying out this package. So full disclosure I'm just another potential consumer and and you may need to take what I have to say with a grain of salt. But from my investigation there isn't so much a default protocol here as there is only one available protocol implemented for the client at the moment. You can certainly add additional protocols to the connection request to the server via calling ConfigureWebSocketClient, however it will do little good as the client will immediately close the connection since it does not have an implementation for the protocol.
If you were felling like getting it working yourself it looks like you would need a separate IProtocolFacotry for the protocol (graphql-transport-ws) as well as a proper implementation of the ISocketProtocol interface that the factory returns that appropriately handles the graphql-transport-ws protocol. Then you could register that factory (presumably via AddProtocol on she ServiceCollection) and have it available for use with socket communication. Sadly I as mentioned did not see such implementation when searching in the code which means you would have to implement yourself.
TLDR; from what I can tell the client support for graphql-transport-ws protocol does not seem to be available (yet?). Perhaps the new protocol may be only supported in the server side code but at the moment not the client which is why its mentioned in the documentation?

Still looking for some assistance on this, perhaps in the future when I have time i could propose a solution but i just dont :(

We will add new subscription protocols in 13 ... this is on our backlog.

Looking forward to it! Thanks!

I'm confused about the current state of subscription protocols after reading the documentation (which promises to deliver SignalR and GRPC in version 12?)
Can we get an update from the maintainers here?

If I'm looking in the right place, it appears that currently Hot Chocolate also only supports the outdated protocol?
The reason I'm asking is that I need to know how GraphQL subscriptions handle unexpected connection interruptions. graphql-transport-ws includes Ping and Pong to support detecting these. Is there any documentation on this other protocol?

For that older stuff you could try this link which is just graphql-ws's older version of the protocol i linked above.  Doing a quick search, you are looking for the old protocol's "GQL_CONNECTION_KEEP_ALIVE".  I suggest searching the repo for the phrase "keep alive" and you will see some good tests and other files that should help you.  But in the mean time, this post and thread is about getting the graphql-transport-ws protocol type added to strawberryshake client for websockets 😄

If I'm looking in the right place, it appears that currently Hot Chocolate also only supports the outdated protocol?
The reason I'm asking is that I need to know how GraphQL subscriptions handle unexpected connection interruptions. graphql-transport-ws includes Ping and Pong to support detecting these. Is there any documentation on this other protocol?

What is provided here is the HotChocolate version when using ASP.NET, but in the implementation for the .NET console application (from ASP.NET) StrawberryShake and HotChocolate have different protocols ("graphql-ws" for the first and "graphql-transport-ws" for the second)
Because of this, the problem arises that I cannot connect the client from StrawberryShake and the server part from HotChocolate

Because of this, the problem arises that I cannot connect the client from StrawberryShake and the server part from HotChocolate

Now that would make a nicer case i think for updating StrawberryShake to include this protocol. But i do believe that HotChocolate has its own client that you can use.  But the StrawberryShake client is VERY cool, basically automatically writing code for me to connect to my schema and allow me to make requests.  I do hope they add this to their backlog.  Again I am still very busy in my day job otherwise id be happy to try to help.  Until then, all I can do is hold hope in my heart 😄 ❤


Broadcaster.Broadcast() then con.WriteClose()

I'm trying to broadcast a message and then close several connections at once. Eg:
	broadcaster := gws.NewBroadcaster(payloadType, payload)
	defer broadcaster.Close()

	for _, con := range conns {
		broadcaster.Broadcast(con.Socket)
	}

	for _, con := range conns {
		con.Socket.WriteClose(1000, reason)
	}

Broadcaster.Broadcast() adds the message to a sockets writeQueue, but Conn.WriteClose() > emitError bypasses the queue and closes instantly, causing the final message from the Broadcaster to not be sent yet.
What is the correct way to wait until the broadcaster has finished?

use WriteAsync to replace WriteClose
socket.WriteAsync(gws.OpcodeCloseConnection, nil, nil)

Thanks.. that does send the close. But it doesn't allow a custom close status?
$ ws ws://localhost:5000/connect
< last text message
websocket: close 1005 (no status)

And secondly - where does it actually close the socket connection when sending OpcodeCloseConnection? I don't see that in the code.

Ah.. the callback function was in a newer version than I had. I've updated and now that makes more sense, awesome.
WriteClose() supports the code and reason which I see is encoded in Conn.emitError(). Do we need to manually encode the status and reason to use it in WriteAsync()?

For reference I now have this function which looks to do what I need, but I was expecting a gws function that handles the code and reason encoding for me. No problem if not though - I'm just looking for the correct way
func closeConnections(conns []*connectionlookup.Connection, code int16, reason []byte) {
	closeCode := []byte{uint8(code >> 8), uint8(code << 8 >> 8)}
	payload :=  append(closeCode, []byte(reason)...)

	for _, con := range conns {
		con.Socket.WriteAsync(gws.OpcodeCloseConnection, payload, func(err error) {
			con.Socket.NetConn().Close()
		})
	}
}

Consider adding a new WriteCloseAsync method


Price repair update: fix Yahoo messing up dividend and split adjustments

Dividends

Rarely, Yahoo sets Adj Close = Close despite a dividend meaning they should be different. Easy to fix.

Stock splits

Sometimes, Yahoo fails to apply a stock split to pre-split price data. And rarely, they apply the adjustment twice! See Issue #1531. Harder to fix properly so this has a unit test.
This is implemented under the repair flag so nothing happens unless user requests it.
Related
And an improvement to the existing price repair: Yahoo often messes up price data on stock split day - all equal or simply missing. Incredibly unlikely that price didn't move/trade on stock split day so should be repaired.

@lcrmorin FYI


Fix #1899: Fix public members of anonymous js.Any classes.

The fix requires an additional phase (prepwaspublicbeforetyper jspretyper)
between parser and namer that adds @WasPublicBeforeTyper annotations
on every public ValDef or DefDef of anonymous classes.
The jsinterop will additionally fix the methods that should be public
in the js.Any anonymous classes.

Review by @sjrd

That's all, I think.
Did you measure how much longer does it take to compile the Scala lib after this change?

Oh, another thing: You will need to adapt the checkfiles of the partests that list the compiler phases. There is a list with comments at the end of Whitelisted.txt.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2496/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3230/
Test PASSed.

@gzm0 how do I run partests that have #partest?
I assume that I'm missing a flag or simply running it from the wrong place.
For example neg/t7494-no-options which I would update to:
error: Error: ploogin takes no options
    phase name  id  description
    ----------  --  -----------
        parser   1  parse source into ASTs, perform simple desugaring
    jspretyper   2
         namer   3  resolve names, attach symbols to named trees
packageobjects   4  load package objects
         typer   5  the meat and potatoes: type the trees
     jsinterop   6
        patmat   7  translate match expressions
superaccessors   8  add super accessors in traits and nested classes
    extmethods   9  add extension methods for inline classes
       pickler  10  serialize symbol tables
     refchecks  11  reference/override checking, translate nested objects
       uncurry  12  uncurry, translate function values to anonymous classes
     tailcalls  13  replace tail calls by jumps
    specialize  14  @specialized-driven class and method specialization
 explicitouter  15  this refs to outer pointers
       erasure  16  erase types, add interfaces for traits
   posterasure  17  clean up erased inline classes
      lazyvals  18  allocate bitmaps, translate lazy vals into lazified defs
    lambdalift  19  move nested functions to top level
  constructors  20  move field definitions into constructors
       flatten  21  eliminate inner classes
         mixin  22  mixin composition
        jscode  23
       cleanup  24  platform-specific cleanups, generate reflective calls
    delambdafy  25  remove lambdas
         icode  26  generate portable intermediate code
#partest !-optimise
           jvm  27  generate JVM bytecode
       ploogin  28  A sample phase that does so many things it's kind of hard...
      terminal  29  the last phase during a compilation run
#partest -optimise
       inliner  27  optimization: do inlining
inlinehandlers  28  optimization: inline exception handlers
      closelim  29  optimization: eliminate uncalled closures
      constopt  30  optimization: optimize null and other constants
           dce  31  optimization: eliminate dead code
           jvm  32  generate JVM bytecode
       ploogin  33  A sample phase that does so many things it's kind of hard...
      terminal  34  the last phase during a compilation run
#partest

Fails with:
> partestSuite/testOnly -- --showDiff neg/t7494-no-options
...
!! 1 - neg/t7494-no-options                      [output differs]
% diff /Users/nastucki/GitHub/scala-js/partest/fetchedSources/2.11.7/test/files/neg/t7494-no-options-neg.log /Users/nastucki/GitHub/scala-js/partest-suite/target/scala-2.11/test-classes/scala/tools/partest/scalajs/2.11.7/neg/t7494-no-options.check
@@ -27,6 +27,17 @@ superaccessors   8  add super accessors in traits and nested classes
        cleanup  24  platform-specific cleanups, generate reflective calls
     delambdafy  25  remove lambdas
          icode  26  generate portable intermediate code
+#partest !-optimise
            jvm  27  generate JVM bytecode
        ploogin  28  A sample phase that does so many things it's kind of hard...
       terminal  29  the last phase during a compilation run
+#partest -optimise
+       inliner  27  optimization: do inlining
+inlinehandlers  28  optimization: inline exception handlers
+      closelim  29  optimization: eliminate uncalled closures
+      constopt  30  optimization: optimize null and other constants
+           dce  31  optimization: eliminate dead code
+           jvm  32  generate JVM bytecode
+       ploogin  33  A sample phase that does so many things it's kind of hard...
+      terminal  34  the last phase during a compilation run
+#partest
...

That the diff contains the "pragmas" is a known bug. Are you sure your whitespace is correct? You might not need a newline at the end of the file (or have two of them).

I only inserted one line (with the new phase), that one has no problems in the diff as you can see. I was quite careful to not add spaces while editing the phase numbers. If I add a new line at the end it will be part of the diff, therefore it looks like the end of the file is fine. I also tried to remove the lines that should be removed by the "pragmas" but then it got weirder output.
With:
error: Error: ploogin takes no options
    phase name  id  description
    ----------  --  -----------
        parser   1  parse source into ASTs, perform simple desugaring
    jspretyper   2
         namer   3  resolve names, attach symbols to named trees
packageobjects   4  load package objects
         typer   5  the meat and potatoes: type the trees
     jsinterop   6
        patmat   7  translate match expressions
superaccessors   8  add super accessors in traits and nested classes
    extmethods   9  add extension methods for inline classes
       pickler  10  serialize symbol tables
     refchecks  11  reference/override checking, translate nested objects
       uncurry  12  uncurry, translate function values to anonymous classes
     tailcalls  13  replace tail calls by jumps
    specialize  14  @specialized-driven class and method specialization
 explicitouter  15  this refs to outer pointers
       erasure  16  erase types, add interfaces for traits
   posterasure  17  clean up erased inline classes
      lazyvals  18  allocate bitmaps, translate lazy vals into lazified defs
    lambdalift  19  move nested functions to top level
  constructors  20  move field definitions into constructors
       flatten  21  eliminate inner classes
         mixin  22  mixin composition
        jscode  23
       cleanup  24  platform-specific cleanups, generate reflective calls
    delambdafy  25  remove lambdas
         icode  26  generate portable intermediate code
           jvm  27  generate JVM bytecode
       ploogin  28  A sample phase that does so many things it's kind of hard...
      terminal  29  the last phase during a compilation run

I get
...
!! 1 - neg/t7494-no-options                      [output differs]
% diff /Users/nastucki/GitHub/scala-js/partest/fetchedSources/2.11.7/test/files/neg/t7494-no-options-neg.log /Users/nastucki/GitHub/scala-js/partest-suite/target/scala-2.11/test-classes/scala/tools/partest/scalajs/2.11.7/neg/t7494-no-options.check

[error] Failed: Total 4, Failed 2, Errors 0, Passed 2

Even tried copying the log and replace of the check with it and I get the same.

Nightly: https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3246/

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2509/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3244/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2510/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3246/
Test PASSed.

@nicolasstucki could you solve the partest problem?

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2514/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3254/
Test PASSed.

There are still some nightly tests failing

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2519/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3259/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2525/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3267/
Test PASSed.

Btw. I still do not understand why we need to remove the annotations. They will not be retained in the .class files anyways.

Principle of least garbage, I guess? They'll still be retained in the Scala symbol table. But it's true that the symbol table for anonymous classes cannot be accessed anyway. Except by macros ... but then macros have already been processed at this point, so they saw the annotations anyway.
We try leaving them be, I guess.

We try leaving them be, I guess.

It seems that if we are concerned about efficiency and we'll need two passes to remove them (current code is essentially a hand-implemented transformer pass), it might be worthwhile to at least consider to leave them.
I really wouldn't worry about annotations breaking subsequent phases. This is probably one of the few things scalac is resilient to :P

If we decide to leave them, I could implement the transformation directly on each method instead of each template. This will remove an additional pass on the template.

It has been decided, I will not clear the annotations.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2552/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3296/
Test PASSed.

The commit message has obsolete stuff (it says annotations will be removed).
That's all.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2556/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3300/
Test PASSed.

It has been decided, I will not clear the annotations.

This sounds like you have found more background than what we discussed on this PR. Could you please share it with this PR thread?

@gzm0 we decided to keep the annotations around as you suggested because as you said they will be erased automatically later on. Additionally this allowed the implementation of the fix to be much simpler, now we only need to take the ddef from  case ddef: DefDef if enclosingOwner is OwnerKind.RawJSType => (a case that already existed as a ValOrDefDef) and fix them directly there if needed. We don't have to worry about Templates and ValDefs anymore.

Ok. Thanks for clarifying.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2559/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3307/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2560/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3309/
Test PASSed.

Is there still an issue in the partests?

I'll execute them locally to check again.

The partests are not passing, but I just found out why. There are some whitespaces missing at the end of some lines in the check files.

Nightly: https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3314/

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2564/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3312/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2565/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3314/
Test PASSed.

The partests are failing on run/macro-term-declared-in-trait with the following diff:
@@ -3,7 +3,8 @@ prefix = Expr[Nothing]({
     def <init>(): <$anon: Base> = {
       $anon.super.<init>();
       ()
-    }
+    };
+    <empty>
   };
   new $anon()
 })

If the tree is not transformed by PreTyperComponent the issue disappears.
class PreTyperTransformer(unit: CompilationUnit) extends Transformer {
  override def transform(tree: Tree): Tree = tree
}

From the other side, if the phase is trivialized to an empty transformation the issue is still there:
class PreTyperTransformer(unit: CompilationUnit) extends Transformer {
  override def transform(tree: Tree): Tree = super.transform(tree)
}

I will probably have to have more cases in my transformation to avoid cleaning the empty trees during this transformation.

I fixed the partest issue using this case. No other changes.
@sjrd could you re-run the partests to make sure that there is no rogue configuration where it fails.

Weird ... OK.

Nightly here: https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3317/

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2566/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3317/
Test PASSed.

Good, all partests succeeded.

LGTM

Woooot!! Now I actually have something new to present in Japan :P

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2577/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3327/
Test FAILed.

Also typo in the commit message: missing 'n' in anonymous.

Dear Jenkins, retest this please.

LGTM

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2582/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3335/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2584/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3337/
Test FAILed.

Dear Jenkins, retest this please.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2585/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3338/
Test FAILed.

Dear Jenkins, retest this please.

Refer to this link for build results (access rights to CI server needed):
https://scala-webapps.epfl.ch/jenkins/job/scalajs-pr/2589/
https://scala-webapps.epfl.ch/jenkins/job/scalajs-matrix-build/3343/
Test PASSed.


Cannot auto encode DateTimeOffset option

Error at: `$` I run into a `fail` decoder: Cannot find case Cannot generate auto encoder for System.Nullable`1[[System.DateTimeOffset, System.Private.CoreLib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]. Please pass an extra encoder. in Microsoft.FSharp.Core.FSharpResult`2[System.Tuple`3[System.String,System.String,Microsoft.FSharp.Core.FSharpOption`1[System.DateTimeOffset]],System.String]

I don't see how I could pass an extra encoder. into the generic type.

Hello,
in order to help you, I will need a reproduction code and also can you please tell me which library is causing this exception?

@MangelMaxime It was my fault mixing Nullable with DateTimeOffset option.

Yes, Thoth.Json consider null as invalid value for DateTime, DateTimeOffset, etc.
It considers that null is represented using 'T option. It's more or less like null don't exist as a valid type for a class for Thoth.Json we could say.


[Bug]Window Level Tool  is not working properly

Describe the Bug
Window level tool not working properly on some images with original voiRange value like {lower: -0.36, upper: 1.02}.
Getting error in console : 'attempt to set zero width color range'
image.zip
Steps to Reproduce

Open attached image here -[https://www.cornerstonejs.org/live-examples/local]
Change window level by dragging mouse over the image

The current behavior
Window level is not changing properly.
Getting error in browser console -  'attempt to set zero width color range'
The expected behavior
Window level should apply properly
OS
Windows 10
Node version
v16.17.1
Browser
Chrome 114.0.5735.134

I don't see any issue here https://www.cornerstonejs.org/live-examples/local.html
Can you record a video?


Update go client and check v.ready in the CSI plugin

longhorn/longhorn#1255

The explanation for the 1st commit:
If one volume action output is not set to volume, the generated go volume client won't contain the action.


Update docs for CA bundles support

This involves updating the description for the source field for both the config specs i.e. v1.0.0-exp and v1.1.0-experimental.

Also the inline and local fields.


Add Support for Mermaid.js Diagrams

Feature Request: Mermaid.js Support
Integrate Mermaid.js for enhanced diagramming capabilities within blog posts.
What + Why:

Mermaid.js is a JavaScript tool for creating and dynamically modifying diagrams and charts via Markdown-inspired text definitions.
It would enable users to embed complex diagrams directly into their Hugo Bearblog posts, enhancing the content's visual and instructional quality.
Adds a powerful tool for technical bloggers and educators who need to include flowcharts, sequence diagrams, class diagrams, etc., in their posts.
Keeps the blog visually engaging and informative without sacrificing speed or simplicity.

Hi @cbrgm,
thank you for opening this issue 🧤. Nice to meet you 😁.
I have not used Mermaid myself, but it does look cool. It definitely seems useful for technical bloggers & educators!
I did some quick duckduckgo-🦆-ing on using mermaid.js with hugo. This post
https://robb.sh/posts/how-to-use-mermaid-diagrams-in-hugo/
has a quick & easy way to get you setup.
If you run into problems or have further questions there's also a discussion on the main Hugo discourse platform https://discourse.gohugo.io/t/correct-way-to-embed-mermaid-js/43491 about how to best embed Mermaid on Hugo.
I am not sure, if we'd need to add this to theme. It seems like this is more of a general issue. In fact once you have a working shortcut you could ship this as an (independent) Hugo module.
I hope that helps.
Kind regards 👋,
Jan

Hi @janraasch ,
Thanks for the swift and helpful response!
Mermaid integration looks straightforward with your guidance. I'll explore the links you provided, especially the setup guide and the Hugo forum discussion for any advanced embedding options.
Regarding theme integration, your point about creating a Hugo module makes a lot of sense. It could streamline the process for others facing the same issue.
And what a small world – I'm located in Hamburg! Great to connect with a "neighbor"  in this context. 😁
Best,
@cbrgm


App getting crash while Pin the image

Hi,
I have configured the Pinterest SDK using Cocoapods. I am using Objective-C language. When I am calling the below block my app getting crashed. Please tell me how to solve this issue.
[PDKPin pinWithImageURL:[NSURL URLWithString:@"https://about.pinterest.com/sites/about/files/logo.jpg"] link:[NSURL URLWithString:@"https://www.pinterest.com"]
         suggestedBoardName:@"test"
                       note:@"The Pinterest Logo"
                withSuccess:^
     {
         // weakSelf.resultLabel.text = [NSString stringWithFormat:@"successfully pinned pin"];
     }
                 andFailure:^(NSError *error)
     {
         //weakSelf.resultLabel.text = @"pin it failed";

     }];

Error:
** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[3]'
*** First throw call stack:
(0x186260f5c 0x19ad67f80 0x18614f8e8 0x18614f780 0x1001eb9f0 0x100196e38 0x18b7ee3c8 0x18b7ee344 0x18b7d6c6c 0x18b7edc5c 0x18b7a8bdc 0x186217c30 0x1862159d4 0x186215e04 0x186144dc0 0x191298088 0x18b81ef44 0x100186c14 0x19b5928b8)
libc++abi.dylib: terminating with uncaught exception of type NSException
Thanks
Boominadha Prakash M

Hi,
I solved this issue myself by adding Bundle display name in info.plist file. Now the app is not crashing.
Thanks,
Boominadha Prakash M

hello. I facing this problem, but i can fill where the key "BundleDisplayName"
Page say:
CFBundleURLTypes

CFBundleURLName

CFBundleURLSchemes

pdk{your-app-id}

So can you help me :)


Support .env-files

In my workflow I make heavy use of env-files.
several tools support .env out of the box:

docker / docker-compose
just  (https://just.systems/man/en/chapter_26.html?highlight=env#settings)
easy to support in makefiles
easy to support in python-apps

It would be nice if uv could support .env-files in the $CWD or parent-dirs.
see https://crates.io/crates/dotenv

Thanks for engaging with the project!
Specifically, you would like us to read .env files before every operation? Or something else?

Specifically, you would like us to read .env files before every operation?
yes.

pip supports a config-file pip.ini / pip.conf
all those values in that config-support can also be set as environment-variables
I have not yet seen a reference that uv pip supports such config-file or these envvars,
but many times I set such project-specific pip-envvars,  the same for twine.
some examples:

PIP_EXTRA_INDEX_URL
RUFF_CACHE_DIR
TWINE_USERNAME
TWINE_REPOSITORY_URL

<project-dir>
   .env
  .venv/
   docs/
   src/
   tests/

so my request is to support .env-files in $CWD,
and optionally in parent-levels (e.g in just this is configurable)

I always try to setup projects in an isolated way:
<project-dir>
   .env
  .venv/
   docs/
   src/
   tests/
   var/cache
   var/cache/ipython
   var/cache/pytest
   var/cache/python
   var/cache/ruff
   var/cache/sphinx
   var/cache
   var/log
   var/tmp

to make ruff use the my .env to read RUFF_CACHE_DIR,
I currently have to install ruff in the .venv and use python-entrypoint to execute ruff (slowing things down)
I use my package  https://github.com/libranet/autoread-dotenv  to read the .env  via sitecustomize-hooks,
so the env-vars become available for any python-generated entrypoint.

I'm going to mark this as not-planned for now. We may revisit in the future. If people have additional use-cases or thoughts please feel free to share!

I have a similar use case.
I am launching machine learning demos for students, and I am currently using Pipenv which loads environment variables from a file named .env. That file contains variables like DO_NOT_TRACK=1 and HF_HUB_DISABLE_TELEMETRY=1 which are applied for all the commands I run via pipenv run.
As a workaround, I can define them in my shell profile, but it would be great to have it natively supported by uv.

I am also migrating from pipenv which uses .env out of the box. It would be great if uv run could support this.

Willing to consider this further, i.e., we'd read it in uv run only.

This might of inspiration, PDM supports something like this: https://pdm-project.org/en/latest/usage/scripts/#env_file
I've personally used this as a way to not use tools like dotenv, since I usually need them locally and not on production 😊 (plus is one less thing to worry about)

We have a very similar use case and I'd love to use uv, but without a solution for this, we can't adopt it since we use .env files for all of our configuration.
I tried loading with python-dotenv and it errors out.
uv add python-dotenv
⠸ dotenv==0.0.5                                                                                error: Failed to download and build dotenv==0.0.5
Caused by: Failed to install requirements from build-system.requires (resolve)
Caused by: No solution found when resolving: setuptools>=40.8.0, distribute
Caused by: Failed to download and build distribute==0.7.3
Caused by: Build backend failed to determine metadata through prepare_metadata_for_build_wheel with exit status: 1
--- stdout:
--- stderr:
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help
error: invalid command 'dist_info'

While I would love the option of declaring a .env file in the uv run command, you can use python-dotenv package.

Supporting this in uv run seems like it could be really useful to me. When I'm working with Django I often have it pick up os.environ["..."] for things like API keys needed by my application. uv run ./manage.py runserver to pick up those from a .env file could be a really nice pattern.

I am also interested in the uv run support. I am coming from Poetry and currently use this plugin to achieve the same flow to pick up env variables from the .env at the project root.

I am also interested in the uv run support. I am coming from Poetry and currently use this plugin to achieve the same flow to pick up env variables from the .env at the project root.

Hi, I was also migrating from poetry to uv, and currently use taskfile to handle .env variable passing to uv run
Example of the taskfile
version: "3"
dotenv: [".env"]
tasks:
  manage:
    cmds:
      - uv run ./backend/manage.py {{.CLI_ARGS}}

and then i can run stuff like
task manage -- makemigraitons
task manage -- shell_plus  etc

Another user-case: I supply environment variables to my dev server with a .env file. I've been using poetry run bin/serve-dev to start things with a dotenv loading plugin for poetry.
uv run bin/serve-dev auto-loading my .env file would be nice, but to be honest uv run --env-file .env bin/serve-dev is fine too, if you want to limit the blast radius of this change.

After the migration from pipenv to uv our local Ansible environments are now broken as uv does not read the .env file.
@zanieb @charliermarsh After reading this thread it looks like that missing feature is a real showstopper?

Here's a non-Python example: Node JS added native support to this feature in September 2023 (changelog) and it has been supported by Bun/Deno for a while now.

My use case is to use a separate project-specific Conan Local Cache when entering the respective venv. This simply means setting the CONAN_USER_HOME env var to the venv path with source .venv/bin/activate.
Currently, this is done by fumbling this into the generated activate/deactivate scripts. These scripts also vary between the Python versions so this also needs to be tested and updated for new Python versions :-(

I'm not sure if my use case is related, but I really enjoy pyenv automatically activating a specific venv if it finds a .python-version file in the directory. I guess the same can be achieved with .env, but maybe there is already a way to use uv to auto-activate envs? Or is this not necessary anymore with uv run (sorry for my ignorance, I haven't really used uv much yet)?

Or is this not necessary anymore with uv run (sorry for my ignorance, I haven't really used uv much yet)?

It shouldn't be needed if you use uv run, though it's a bit more nuanced than that. Feel free to open a new issue if you run into problems there.

I like Brett Cannon and Jeff Tripletts takes on .env files, which identify the orthogonal purposes of using such files for configuration and for secrets. They also identify the issue with the lack of a standard of .env files, e.g. path separator variation and other nuances.
Brett posed the question, could we standardize on TOML for this? I think if uv picks this up, it could be done in stages, supporting .env today but with no promises on the unstandardized format, then eventually incorporating a more opinionated take inside pyproject.toml in a subtable of tool.uv.
Secrets management is it's own beast, of course.
The upside to uv tackling lockfiles is the standards discussion on that is already pretty mature, but there's no clear consensus on standardizing something for .env, so maybe that's a bridge too far.
https://snarky.ca/use-toml-for-env-files/
https://micro.webology.dev/2024/03/13/on-environment-variables.html

@blakeNaccarato  IMHO it is widely understood that .env-files should have a bash-compatible syntax. Besides that, there should not be anything language or tool specific.

Brett posed the question, could we standardize on TOML for this?

The great thing about ruff is that it's essentially a drop-in replacement for pylint and other tools you were probably using before.
Doing the same with .env files would be a DX win.
Championing an emergent new format would be an interesting idea, as a separate and second step, but until it becomes comparable to .env in terms of adoption, it seems like a DX loss to deprecate .env.

I use direnv for this exact use-case. It is installed as a global binary on pretty much any OS, then activates any .envrc or optionally also .env when the folder is entered. This is a mature tool that does exactly this one job very well, with the bonus of not being restricted to only Python as it works on any folder, anywhere.
The big plus for me is that you need to explicitly enable the file for each folder (once off check) so it will not activate any random file you get in a cloned repo.
uv doesn't need to do absolutely everything :wink:

Unfortunately i have to use Windows so direnv won't work for me.

Unfortunately i have to use Windows so direnv won't work for me.

I haven't tried it myself, but there is a windows download using winget offered, even though it does say only '*nix' compatible on their github 🤷♂. Ignore me if you've tried this and it didn't work :grin:

I wrote an isolated script for syncing .env with a tool.dev.env table in pyproject.toml (by default, but it's configurable via CLI) that you can run in a shell profile or in your shell initialization flow. It's barebones and only supports environment variables hard-coded in your pyproject.toml (e.g. no secrets), but I'm sure someone could extend it into a full utility. See also dump-env for a feature set supporting secrets and .env templating.
https://gist.github.com/blakeNaccarato/9871a3a36a1d0156a739af1fbc9a937e

I’m supportive of adding this to uv run. It would also enforce that the point is not to configure uv but to configure the underlying commands.
(I think it’s not too difficult to add and there’s clearly a lot of demand.)

I think there are two options here:

Respect .env in uv run (but not elsewhere). So, .env would be for providing runtime environment variables, but not for configuring uv itself.
Respect .env everywhere.

My inclination is to do the former (and I think we could get consensus on + ship that quickly). The downside is that you still need to provide UV_-prefixed environment variables (which could include credentials) through some other mechanism.
Maybe we start with (1) and we can always expand to (2) if it's well-motivated.
If we do (1), my preference would be:

Always read .env
Allow users to pass --env-file (or UV_ENV_FILE) to override the file.
Add --no-env-file and UV_NO_ENV_FILE to disable it.

(In other words, I think it should be opt-out, not opt-in.)

For my use cases, option 1 is sufficient. I only need .env files to be loaded at uv run time, and I would prefer uv run do so by default, which is equivalent to pipenv's pipenv run behavior. Offering opt-out flags seems like a good move.
With regard to credentials, which is often my reason for using a .env file in development, could you explain more about this statement?

My inclination is to do the former (and I think we could get consensus on + ship that quickly). The downside is that you still need to provide UV_-prefixed environment variables (which could include credentials) through some other mechanism.

In that scenario, if I had a development credential that was previously kept in an un-committed/.gitignored as, say, GOOGLE_API_KEY=123456 would I need to prefix GOOGLE_API_KEY with UV_ for uv to load it? Or are you talking only about env vars for configuring uv?

Or are you talking only about env vars for configuring uv?

I'm only referring to these. In other words, we'd pass the environment variables onwards to whatever uv run runs, but we wouldn't use them within uv itself.

Ah, OK. That makes sense, and requiring UV_ vars to be set elsewhere is OK for my needs. If I configure uv, I usually do so with env vars defined in my shell profile, not per-project in a .env file.

(In other words, I think it should be opt-out, not opt-in.)

I'd prefer the opposite, though I'm probably in the minority. I tend to exclusively use virtualenvs (and with direnv I don't even have to activate them), and a fair percentage of my code tends to run as services or sockets which would stil need a dotenv-type solution so i rarely use uv run even in development. I think making a new feature optional at least at first (if it's configurable by the uv.toml and well documented this should be usable?).
More importantly, direnv for example requires explicit permission (once) to load any .env file - i'd not like any repo i cloned to be able to set any ENV var it wants  - overwrite PYTHONPATH or system stuff?

@charliermarsh's recommendation (start with #1, and make it opt-out) makes a lot of sense to me.

I think there are two options here:

Respect .env in uv run (but not elsewhere). So, .env would be for providing runtime environment variables, but not for configuring uv itself.
Respect .env everywhere.

My inclination is to do the former (and I think we could get consensus on + ship that quickly). The downside is that you still need to provide UV_-prefixed environment variables (which could include credentials) through some other mechanism.
Maybe we start with (1) and we can always expand to (2) if it's well-motivated.
If we do (1), my preference would be:

Always read .env
Allow users to pass --env-file (or UV_ENV_FILE) to override the file.
Add --no-env-file and UV_NO_ENV_FILE to disable it.

(In other words, I think it should be opt-out, not opt-in.)

Option (2) is exactly what tools like Docker do,s o a big 👍 here.
With option (1) we will already get most of the use cases for running local (development) run commands. But option (2) will be needed for e.g. build commands for smaller projects that don't use a CI/CD pipeline, yet. I think that option will also fulfill their needs and the env discussion can be closed as a happy end 😀
IMHO without option 2 that topic will pop up sooner or later again and the discussion begins from the start...

With option (1) we will already get most of the use cases for running local (development) run commands. But option (2) will be needed for e.g. build commands for smaller projects that don't use a CI/CD pipeline, yet. I think that option will also fulfill their needs and the env discussion can be closed as a happy end 😀
IMHO without option 2 that topic will pop up sooner or later again and the discussion begins from the start...

Fully agree. uv run should give the same results as executing the command after activating the venv first to not confuse people.

Just to add a thought here, it would be really handy to define a project .env file next to the lockfile that could set the UV_EXTRA_INDEX_URL and UV_KEYRING_PROVIDER variables. This way I could switch between open-source project and work projects without editing my shell environment

I'm always using .env to set project-specific variables for pip, twine,django,uvicorn ... in each project.
All my projects are isolated application directories (think virtualenv on steroids),
where we actively try hard to avoid on anything depending in a users $HOME-dir.
(Avoiding: "it works on my machine" ... because of your .dotfiles)
My first use-cases would be to set the env-variables equivalents of PIP_* and "TWINE_"
for "uv pip install" + "uv publish"
mainly to set credentials that can not be used directly in a pyproject.toml.
For example:
in .env
PERSONAL_ACCESS_TOKEN='<personal-access-token>'
TWINE_REPOSITORY_URL='<url>'
TWINE_PASSWORD='<password>'
TWINE_USERNAME='<username>'

then in pyproject.toml if https://github.com/astral-sh/uv/issues/5734 is implemented
[tool.uv]
index-url =<EMAIL_ADDRESS>

Respect .env everywhere.

I'm favor to always read the .env to also support the project-specific UV_*-variables to override the global default config.

Allow users to pass --env-file (or UV_ENV_FILE) to override the file.

Yes.

Add --no-env-file and UV_NO_ENV_FILE to disable it.
In other words, I think it should be opt-out, not opt-in.

Yes. opt-out via an externally managed variable makes more sense logically
(because all other vars are already managed outside .env)
than opt-in (use the .env) via a non-.dotenv managed variable.

In https://github.com/astral-sh/uv/pull/8263, some commenters are making the case that this should be opt-in rather than opt-out. I want to open up the conversation for more opinions here before this ships.

I personally feel like reading any .env or otherwise named env file by default, without any input or config telling uv run to do so, is undesirable.
I also feel like having simple pyproject.toml config like read_dotenv_files = true (or equivalent CLI option) should opt-in to that behavior being automatic.
that allows projects (or users of projects) to trivially opt-in to dotenv style reading if it's desired/utilized and poses no risk for projects that don't desire to use it.

I personally feel like reading any .env or otherwise named env file by default, without any input or config telling uv run to do so, is undesirable.
I also feel like having simple pyproject.toml config like read_dotenv_files = true (or equivalent CLI option) should opt-in to that behavior being automatic.

Yeah. I commented similar on the other thread and suggested just a global config option but this would be a good solution too with a cli option to set it (like we have for app or lib already). Either way, opt in rather than out.

A couple of Python tools come to mind that do load .env files by default. For example, pipenv run ... and flask run do this out of the box in opt-out mode. pipenv considers the PIPENV_DONT_LOAD_ENV env var, and Flask uses FLASK_SKIP_DOTENV. As someone who uses pipenv for day-to-day application development, I am excited for uv to gain auto-loading of .env files by default. Having to add a pyproject.toml entry like read_dotenv_files = true would be OK, though I'm sure I would forget to add it occasionally in new projects.

For example, pipenv run ... and flask run do this out of the box in opt-out mode.

'Flask run' is however less of a tool in the 'uv' mold than very specific to Flask users, not going to be used by EVERY Python project and environment you write. It's more equivalent to 'django-admin'.
I'm not saying this is a bad thing, just  make it opt-in so there are no surprises. The large majority of users generally don't read release notes🤷♂

One facet of it is that uv run is very versatile, and not just used in uv projects, but could be used in any directory, and with/without existing project or virtual environment. And you can also use uv run to run things in a different directory like uv run --python ./path/to/venv or uv run --project foo  which also puts some distance between the .env file and the installed python software. Anchoring env file support to a configuration or a uv project would be a more consistent model, possibly(?)

After the migration from pipenv to uv our local Ansible environments are broken as uv does not read the .env file by default.
Also Docker and Ansible read .env by default.
In my case (what our company does): The .env files are only needed for local development where users also run uv run ... manually. Opt-in would be no comfort from the users perspective especially when projects will be migrated from tools like pipenv to uv. Also production systems get different environment variables that will be set for the run and will not use any .env file and if I would like to change that behaviour I will use the UV_xx environment variables.
So, maybe this approach will be accepted:

Use opt-out by default, so uv reads the .env file by default
Add UV_xx environment variables for not reading and reading .env files: You already planned this feature
Add another option for the pyproject.toml file so reading an .env file for a project can be set to opt-in instead of the default opt-out

@seapagan @AndreuCodina Would option 3 something you would like to see in uv?

@TheRealBecks
My preferred choice would still be opt-in by default but I can see that's unlikely to happen 😂
I've never really used 'pipenv' (went pip to poetry to uv) so the whole concept of auto-loading env files is strange to me.
Yeah, option 3 would work but I'd really love a global setting in the configuration file too, so I can opt-out for every project and just forget about it. I've not sat down and gone through the PR in depth yet so apologies if this is already there.

I don't really care as long as there is an env var which can overwrite the behaviour. I let direnv load .envs and so would disable it for uv.
We also have some projects where the .env is in a parent folder, not the repo folder. OS I guess for these repos, it wouldn't work anyways.

Opt-in would be no comfort from the users perspective especially when projects will be migrated from tools like pipenv to uv.
@TheRealBecks fwiw this doesn't track with me as an argument for opt-in by default.

If you're already having to do various other config changes and generate new lock files (you almost certainly are) and anything else in the migration process I struggle to see how marginally tweaking the new tools config isn't entirely expected anyway. Migrating between these tools isn't overly hard, but it's never as simple as literally just calling a different tool with 0 config changes either.

Isn't placing a file in the directory you are running uv from named exactly .env a sign you're opting-in already? If you have a .env-formatted file that you don't want auto-loaded by uv, then just name it something else.
Asking uv to force users to pass an "opt-in" flag every time (or set it via uv.toml) to load .env files is like saying git should require that users pass a --use-ignore-file (or equivalent in .git/config) to use .gitignore, or asking bash to require users to pass some flag to read .bashrc, etc.
I understand there are cases where opting out or explicitly passing a specific file would be needed (e.g. multiple dotenv variants (.env.stage, .env.dev, etc), dotenv files in other directories, etc) but having uv auto-load a plain .env file in the cwd is an absolutely reasonable default IMHO.

I can give a practical example:
.env and .env.myenvironment is the Python convention to store settings used by the code, and the code should decide if it gives priority to .env files or other sources. The settings must be managed by code, and the execution of the code the simplest and the same in all environments: uv run.
myenvironment is a value obtained with an environment variable, so:
dotenv = DotEnvSettingsSource(
    settings_cls,
    env_file=[".env", f".env.{os.environ["PYTHON_ENVIRONMENT"]"],
    env_nested_delimiter="__",
    case_sensitive=True,
)

Then, even if you're using pydantic-settings or a runner tool (uv), you'll need an environment variable.
So, we do agree, we need to provide an environment variable, but the issue is how.
With code is simple, but verbose (because we need this file in every project):
class ApplicationEnvironment(StrEnum):
    LOCAL = "Local"
    DEVELOPMENT = "Development"
    STAGING = "Staging"
    PRODUCTION = "Production"

    @staticmethod
    def get_current() -> str:
        return os.getenv("PYTHON_ENVIRONMENT", ApplicationEnvironment.LOCAL)

and it'll be used this way:
dotenv = DotEnvSettingsSource(env_file=[".env", f".env.{ApplicationEnvironment.get_current()}"],

This environment variable will be used for configuring the code itself, e.g. not adding telemetry if you're in localhost, adding secrets from Azure Key Vault if you're not in localhost, not showing the Swagger documentation in production, etc.
docs_url = (
    "/docs"
    if ApplicationEnvironment.get_current() != ApplicationEnvironment.PRODUCTION
    else None
)
app = FastAPI(
    docs_url=docs_url,
    redoc_url=None,
)

So, the thing is, when we deploy an application, we provide an environment variable on the cloud or with docker run, and the proper .env.myenvironment file is read.
But in localhost we can't do that, so where do we specify the environment variable?
.env files are for code configuration, so use another thing: pyproject.toml, mynewfile.json, etc.
In .NET we have a command for everything called dotnet, and it's the uv equivalent.
The launchSettings.json file is used in ASP.NET Core to configure how an application is launched during development, and you can specify environment variables and tool dotnet configurations.
In summary, uv or your framework should provide a (configurable) default environment variable to run the project, but not from the code settings. And this environment variable will be different in each environment, not relying on different uv parameters to read from here of there.
What environment variables do you need? TBH I don't think more than the PYTHON_ENVIRONMENT variable is necessary. On the cloud, with user-assigned managed identities, you add for example the AZURE_CLIENT_ID environment variable, but when you run the code in localhost, you don't set it by hand, you execute az login.

(Candindly, I don't find this framing very convincing because dotenv loading is something that other runners support and is much-used and appreciated by users of those tools.)

Isn't placing a file in the directory you are running uv from named exactly .env a sign you're opting-in already? If you have a .env-formatted file that you don't want auto-loaded by uv, then just name it something else.

Nope, it's a sign we're following best practices, and have writtten our code to already take care of this file, on our own terms. We also did this before dotenv was a thing though it may have had a different name. I did this when using pip then poetry both of which ignored it.

Asking uv to force users to pass an "opt-in" flag every time (or set it via uv.toml) to load .env files is like saying git should require that users pass a --use-ignore-file (or equivalent in .git/config) to use .gitignore, or asking bash to require users to pass some flag to read .bashrc, etc.

Setting in uv.toml would be a once-off system-wide thing.
Regarding the pyproject.toml - as already pointed out by others, there are always changes in the pyproject.toml needed coming from another tool to uv beore it works. Your argument also works the other way around - why should those who DONT want this functionality have to pass a flag or set an env each time?
You may never use this option in the settings or project toml but many people will, so why not have it implemented?
I understand the decision is already made and it's going to be opt-out regardless of this discussion, but please just at least give us a global option to set-and-forget to disable it 🤷♂It's not something I'm EVER going to use as uv isn't used in a prod setting (for me) after the virtual env is setup. An optional setting in the project toml to disable would be icing on the cake.
For me, I DO read changelogs and release notes and will adapt regardless, not everyone does.

We're switching from pipenv to uv, so in order to maintain our current workflows, I'd like to add my vote to the "include .env files by default" option.

Another vote for load .env by default in build and run cases. A .env file is a sign a user is opting in, and being able to configure a build env with a .env file is incredibly useful for private repositories.
Pipenv has a nice loading .env file output when it runs if you have a .env file, which makes it clear what is going on

Another vote for load .env by default in build and run cases. A .env file is a sign a user is opting in, and being able to configure a build env with a .env file is incredibly useful for private repositories.
Pipenv has a nice loading .env file output when it runs if you have a .env file, which makes it clear what is going on

In https://github.com/astral-sh/uv/pull/8263, some commenters are making the case that this should be opt-in rather than opt-out. I want to open up the conversation for more opinions here before this ships.

I don't know if it's too late now since that MR is merged. But, I'll try to outline a few arguments against making it a default:

Dotenv files are often used in situations where a "real" configuration file (toml, json, etc etc) with an app defined schema would be more appropriate (easier to both organise, read and validate).
Environment variables are often given preference over configuration files. Dotenv files are usually hidden (due to the leading dot) and it is counter intuitive that a hidden file should override a visible file.
What uv makes default, a lot of people will think is good practice. It follows that if uv enters the space of app configuration, it should give at least some thought to what is considered best practice for app configuration. In my opinion, it does not involve automatic loading of hidden files into the environment.
Runtime "environments" such as Kubernetes, Docker Swarm, Systemd services already offer ways of setting environment variables, and in my opinion their way should be preferred when running in those environments. They also all do it using non-hidden files (either explicitly configured environment files, or as part of their own service/resource configuration). In my opinion, it's fine for uv to similarly allow setup of environment variables, to enable locally running something that needs certain variables, but it should be explicit and opt-in, not opt-out.

(It's not too late, this was just merged into a feature branch for v0.5, but may still change between now and the actual v0.5 release.)

Is this issue also being used for tracking .env support in tools like uv sync, or is that already included in the merged PR.

A few points raised in this thread that I want to respond to:

variables like DO_NOT_TRACK=1 and HF_HUB_DISABLE_TELEMETRY=1 [...] As a workaround, I can define them in my shell profile

These "purely preferential" variables probably do belong in each developer's personal setup rather than having to be defined in every project he works on. So, I don't think this should be considered just a "workaround". If you are making an application where some variables must always be set, you should probably make it part of the code.

Here's a non-Python example: Node JS added native support to this feature in September 2023 (changelog) and it has been supported by Bun/Deno for a while now.

While it seems Bun does automatically load the .env-file, going by their docs both Node and Deno appear to need an explicit --env-file=config.env argument, which is what I think should be required here as well. Besides, I would point out that most tools in other languages don't support this at all. When there is a blessed config provider, it is usually not environment files (instead you see e.g. appsettings.json (C#), application.properties (Java), ususally something.toml (Rust)). However, although I think it is misguided to use environment files, I can certainly accept that there is already some usage of them among Python users.

I also feel like having simple pyproject.toml config like read_dotenv_files = true (or equivalent CLI option) should opt-in to that behavior being automatic.

This would be a good way to also satisfy those who want it "always on", but I think it should probably be a string option, i.e. env_file = "dev.env" (such that the option name matches the --env-file cli option).

Unfortunately i have to use Windows so direnv won't work for me.

you can hack it. part of me says that this is best left to direnv. direnv should work on windows. this issue shouldn't have to do with a programming language. but it's in pixi's field.

Willing to consider this further, i.e., we'd read it in uv run only.

but that wouldn't match the activation script. many tools rely on that.

I've decided to make this opt-in for now. I'm going to remove it from the v0.5 branch and PR it to main, since it's no longer a "breaking" change in any sense -- we can ship it in a patch release.

We're switching from pipenv to uv, so in order to maintain our current workflows, I'd like to add my vote to the "include .env files by default" option.

I'm in this camp. I just lost an hour of my time trying to sort of this discrepancy. I'd be much more happy switching to uv and recommending it to others if it "just worked" as a pipenv replacement.

Ii would be nice to also enable the env-file via uv.toml.

Hi!
I'd like to know what to know what are the actual best security practices when it comes to publishing to a private index. I know we can do it with one of the following ways:

use the CLI like uv publish --publish-url <url> --username <username> --password <password> or uv publish --publish-url <url> --token <token>.

But it seems like redundant / hassle, and I don't think it's the most secure way of doing (shell history, process list etc.).

use environment variables, UV_PUBLISH_URL, UV_PUBLISH_USERNAME, UV_PUBLISH_PASSWORD, UV_PUBLISH_TOKEN.

It's not the most secure way of doing things as well and the environment variables are available globally I think so it's not really flexible if we're working on different projects.

I recognize this might be delving into the extreme side of security concerns, I’m curious about what would be considered the best practice in this context.
Would implementing support for a .env file or another secure configuration method be worth exploring?

I understand the decision to make this an opt-in feature, but can we also make it configurable via pyproject.toml?

Opt-in through CLI flags should be made illegal please. It is really bad UX design (imo at least, if there are argument for it and against config in config file I would love to hear them), configuration should be defined in the config file it seems quite logical and intuitive and reproducible.
Is it complex to add a new field to the pyproject.toml/uv.toml?

We use several private package indexes and are currently migrating from pipenv to uv. With pipenv, one can setup an .env file once and copy it into projects. This file which contains the equivalent of UV_INDEX_BLAH_USERNAME and UV_INDEX_BLAH_PASSWORD variables. So I would really like if uv sync and uv lock also read from .env by default, not just uv run.


⚠ Processors has degraded performance

In 9bd1033, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 86 ms

Resolved: Processors performance has improved in 5f1b72e.


Checking options and pricing

In Sporestack v1 there was a convenient option to view available configurations, pricing and regions before deploying; I don't see that argument anymore in v2. Is there a way to get that information? (for regions and configurations, even a web page will do) If not, is there any plan to implement that?

Hey!
Sorry for the wait on this. I've made some improvements to the front page for it, but nothing yet on the client. At least starting to get some of the plumbing together for this.
https://sporestack.com/
Also lowered the prices a bit. I hope at least the table on the website will help for now.
Thanks,
Teran


Set Duration Before Starting Pomodoro

Love your plugin. I feel really motivated whenever I see the detailed logs generated after each session.
I was wondering if it's possible to add the option to set duration each time I use "Start Pomodoro" command? Currently, I have to go to options and change the Pomodoro time field. I may have different sessions that require different focus time throughout the day and I don't want to click settings, flexible pomodoro to change the duration each time.

Ok thanks
I will do it this weekend.
Thanks!

Thank you. Looking forward to this feature!

Please see 0.6.0
Thanks.


"robust_estimate_flatplane" failed when ego car is running straight up and down.

In this case, it will estimate a vertical plane.

@clmforgit This is a corner case and you can use other methods(lidar, MVS, etc) to estimate road elevations.


Update the guide to use the KOTS installer

Description

This now uses the KOTS installer. This will remove the requirement to update this with every release.
How to test

Follow readme
Release Notes

Update the guide to use the KOTS installer

Documentation

Have switched the Issuer to a ClusterIssuer because we no longer know the namespace they'll be deployed to. It defaults to gitpod, but not a guarantee


Closing as stale. Please reopen if you'd like to work on this further.

    Closing as stale. Please reopen if you'd like to work on this further.

Originally posted by @google-ml-butler[bot] in https://github.com/google/mediapipe/issues/3212#issuecomment-1099061984

This is still an issie

Hi @peter6053 ,
We are marking it as duplicate issue since we have similar issue running on thread https://github.com/google/mediapipe/issues/3214

@peter6053
Are you still looking for resolution on this issue?
From the terminal output, it seems like you are not using official mediapipe repository, rather trying some tutorial project on android. With third-party or user created repositories as well, WORKSPACE file defines a folder as a bazel workspace. In the official mediapipe repository, in WORKSPACE file, only two lines need to be added to configure the android ecosystem for mediapipe.
android_sdk_repository(name = "androidsdk", api_level=33, build_tools_version="<YOUR_BUILD_TOOL_VERSION>")
android_ndk_repository(name = "androidndk", api_level=21)

Please check if you have duplicate android_sdk_repository() call in the workspace file. This might be conflicting and raising the error.

Hi @ayushgdev , I am having the same issue,
When I run
android_ndk_repository(name = "androidndk", api_level=21)
I get the following error:
zsh: number expected
same for the previous command, but there I don't know how to find the build tool version

Hi @ArtanBerisha1
android_ndk_repository(name = "androidndk", api_level=21) is not a command for shell but rather to be included in the WORKSPACE.bazel file (.bazel is optional as per bazel naming convention). Please refer the image below. There are two lines added in the WORKSPACE file. Those are the required ones:

Further, to know the build tools version, follow the steps below:

Open Android Studio.
Go to Tools -> SDK manager
Go to SDK Tools tab
Expand Android Build SDK-Tools section. You will see one of the build tools version checked with status installed. If not, please consider installing version 30.0.3.
Expand NDK(Side by Side) section. You will see one of the NDk tools version checked with status installed. If not, consider installing version 21.1.6352462.


Fix some compilation errors

Fix two compilation errors encountered in GCC 7.4.

thnaks, I fixed this slightly differently.


message_feed_ui: Fix focus when clicking on message feed buttons.

This PR fixes the focus on messages when clicking message feed buttons that open popovers. The focus no longer changes when following buttons are clicked on the message-box:

"Add emoji"
"Move message"
"User avatar or name"

Fixes: #27820

Screenshots and screen captures:

Self-review checklist

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

Communicate decisions, questions, and potential concerns.

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

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

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

Completed manual review and testing of the following:

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

@N-Shar-ma Perhaps you could do a first-round review on this one? I have not tested.
This is not specifically a release goal.

@Vector73 Moving messages and clicking on user avatar or name seems to work fine, but emoji reactions are now added to the focused message (with the blue box) and not to the message for which the user opened the emoji palette.
If you study the code more closely, you'll see that the reaction emoji is toggled for the currently selected message. We need to change the code to retain and use the id of the message for which emoji palette was triggered, instead.

I have fixed that now.

Looks good to me now! FYI @alya

Merged, thanks @Vector73 and @N-Shar-ma!


What is a valid path value? DOMException: Failed to execute 'querySelector' on 'Document'

I am getting this error when I try to put the path to the next page as the "Path" options. What am I doing wrong?
DOMException: Failed to execute 'querySelector' on 'Document': 'http://localhost:5000/index?page=2' is not a valid selector.

I figured out what was wrong. I someone has a similar problem in the future. This is the change that I made:
function getPath() {
var more = document.getElementById('nxt').href;
return more;
}
var infScroll = new InfiniteScroll( grid, {
path: getPath,
append: '.grid__item',
outlayer: msnry,
status: '.page-load-status',
});
  `
`

Thanks for following up!


Upgrade org.pitest:pitest-maven 1.7.0 -> 1.7.1

This PR contains the following updates:

Package
Update
Change

org.pitest:pitest-maven (source)
patch
1.7.0 -> 1.7.1

Release Notes

hcoles/pitest
v1.7.1
Compare Source

#932 Improve switch mutation descriptions
#934 Configure console output verbosity
#940 Hide internal features
#942 Fix for 3rd party mutation operators not added to client classpath
#939 Improve caching of bytecode retrieval

[ ] If you want to rebase/retry this PR, check this box.

Suggested commit message:
Upgrade pitest-maven-plugin 1.7.0 -> 1.7.1

See:
- https://github.com/hcoles/pitest/releases/tag/1.7.1
- https://github.com/hcoles/pitest/compare/1.7.0...1.7.1


Attribute error with pyqt5 library

Really a nice and helpful tool. Unfortunately if fails for pyqt packages.

gathering licenses...
Traceback (most recent call last):
...
license = regex_license.search(metadata).group('license')
AttributeError: 'NoneType' object has no attribute 'group'

Reproduce: ini file from repo, requirements.txt with the following content

PyQt5==5.11.3
PyQt5-sip==4.19.13

For some reason, the license is not present in PyQt5-sip package metadata.
Fixed by https://github.com/dhatim/python-license-check/pull/22.
With the fix, your testcase results in:
gathering licenses...
2 packages and dependencies.
check unauthorized packages...
1 package.
    PyQt5 (5.11.3): ['GPL v3']
      dependency:
          PyQt5
check unknown packages...
1 package.
    PyQt5-sip (4.19.13): UNKNOWN
      dependency:
          PyQt5-sip << PyQt5

Thanks for the fast response. This fixes indeed the Attribute error. However, I still do not understand your approach with approved packages.
If I write in the ini file

[Authorized Packages]
PyQt5: 5.11.3
PyQt5-sip: 4.19.13

it still gives me the output (shouldn't it be all ok?):

gathering licenses...
2 packages and dependencies.
check unauthorized packages...
1 package.
PyQt5 (5.11.3): ['GPL v3']
dependency:
PyQt5
check unknown packages...
1 package.
PyQt5-sip (4.19.13): UNKNOWN
dependency:
PyQt5-sip << PyQt5

I would like to use your tool as a test step in CI pipeline.

Indeed, explicitly authorized packages do not have precedence over authorized licenses. This is a mistake. I am going to fix that.

Fixed by #23 in version 0.3.7


Issue: Remove dynamic System.Windows.Forms reference

Remove dynamic System.Windows.Forms reference from SSOSettingsFileImport to eliminate warning.
This work item was migrated from CodePlex
CodePlex work item ID: '10720'
Assigned to: 'tfabraham'
Vote count: '1'

[UnknownUser@9/9/2014]
Resolved with changeset 75386.


Pt-br translation fixes

Fixed some mistakes in the translation in the bundle_pt_BR.properties.

Hello @RobertoCassio
Thanks for your contribution.
I added some comments. Please take a look.

You're welcome, i will translate it too when i have some time to spare.
:)

Closed as a duplicate of https://github.com/dbeaver/dbeaver/pull/21498


Match style on the reswap field

Added comment in PRs: https://github.com/teia-community/teia-ui/pull/20#issuecomment-1073014478
Here might more more right place for this.

Closing in favor of #22


Unexpected token u in JSON at position 0

I updated my project to Gatsby 3 and can’t start the dev server unless I disable gatsby-plugin-favicon.
I am on Windows with WSL 2, this is the error that comes up if I try to start:
verbose Transition to "runningQueries" > "waitingForJobs"
verbose Transition to "runningQueries" > "done"
verbose Transition to "startingDevServers"

 ERROR

(node:8994) [DEP_WEBPACK_COMPILATION_CACHE] DeprecationWarning: Compilation.cache was removed in favor of Compilation.getCache()
(Use `node --trace-deprecation ...` to show where the warning was created)

 ERROR

(node:8994) [DEP_WEBPACK_COMPILATION_OPTIMIZE_CHUNK_ASSETS] DeprecationWarning: optimizeChunkAssets is deprecated (use Compilation.hooks.processAssets instead and use one of
Compilation.PROCESS_ASSETS_STAGE_* as stage option)

⠦ Building development bundle
/home/.../node_modules/yoga-layout-prebuilt/yoga-layout/build/Release/nbind.js:53
        throw ex;
        ^

SyntaxError: Unexpected token u in JSON at position 0
    at JSON.parse (<anonymous>)
    at /home/.../node_modules/favicons-webpack-plugin/lib/compiler.js:115:23
    at /home/.../node_modules/webpack/lib/Compiler.js:534:11
    at /home/.../node_modules/webpack/lib/Compiler.js:1089:17
    at Hook.eval [as callAsync] (eval at create (/home/.../node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/home/.../node_modules/webpack/node_modules/tapable/lib/Hook.js:18:14)
    at /home/.../node_modules/webpack/lib/Compiler.js:1085:33
    at /home/.../node_modules/webpack/lib/Compilation.js:2496:11
    at Hook.eval [as callAsync] (eval at create (/home/.../node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/home/.../node_modules/webpack/node_modules/tapable/lib/Hook.js:18:14)
    at /home/.../node_modules/webpack/lib/Compilation.js:2489:38
    at eval (eval at create (/home/.../node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:15:1)
    at /home/.../node_modules/webpack/lib/Compilation.js:468:10
    at /home/.../node_modules/webpack/lib/SourceMapDevToolPlugin.js:546:10
    at /home/.../node_modules/neo-async/async.js:2830:7
    at Object.each (/home/.../node_modules/neo-async/async.js:2857:9)```

My packages:

```  "dependencies": {
    "@wyze/gatsby-source-graphql": "^1.2.0",
    "gatsby": "^3.3.1",
    "gatsby-cli": "^3.3.0",
    "gatsby-plugin-env-variables": "^2.1.0",
    "gatsby-plugin-favicon": "^3.1.6",
    "gatsby-plugin-google-tagmanager": "^3.3.0",
    "gatsby-plugin-i18n": "^1.0.1",
    "gatsby-plugin-netlify": "^3.3.0",
    "gatsby-plugin-react-helmet": "^4.3.0",
    "gatsby-plugin-sass": "^4.3.0",
    "gatsby-source-filesystem": "^3.3.0",
    "gatsby-source-iubenda": "^1.0.2",
    "gatsby-source-strapi": "0.0.12",
    "intl": "^1.2.5",
    "node-sass": "^4.14.1",
    "prop-types": "^15.7.2",
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "react-helmet": "^6.1.0",
    "react-intl": "^4.7.6",
    "react-player": "^2.9.0",
    "react-slick": "^0.23.2",
    "typeface-roboto": "0.0.54",
    "universal-cookie": "^3.1.0"
  },
  "resolutions": {
    "graphql": "^15.4.0",
    "graphql-compose": "^7.25.0",
    "webpack": "^5.24.2"
  },```

I did log some variables too:
// Resolve / reject the promise
      if (childCompilation && childCompilation.errors && childCompilation.errors.length) {
        var errorDetails = childCompilation.errors.map(function (error) {
          return error.message + (error.error ? ':\n' + error.error : '');
        }).join('\n');
        reject(new Error('Child compilation failed:\n' + errorDetails));
      } else if (err) {
        reject(err);
      } else {

        console.log(childCompilation.assets);
        console.log(childCompilation.assets[outputName].source());
        console.log(outputName);
        console.log('test');

        resolve({
          outputName: outputName,
          stats: JSON.parse(childCompilation.assets[outputName].source())
        });
      }

Result:
{
  '.iconstats.json': { source: [Function: source], size: [Function: size] }
}

.iconstats.json
test

You'll have more help if you put this issue on Gatsby repo, and like that you'll trigger a problem that they can relate on the blog.


FEATURE: Add sourcegraph source

Did you check the docs?

[X] I have read all the docs.

Is your feature request related to a problem? Please describe.
Not really a problem. I like to show tries in a consistent way no matter where they come from.
I've just came across sourcegraph plugin for neovim and it seems to have a builtin file tree explorer.
Describe the solution you'd like.
Implement new source for sg.nvim. It should mimic the behavior of the sg's builtin file explorer.
Describe alternatives you've considered.
This can be a separate project, but I wanted to start somewhere and this repository seemed like a good choice.
Additional Context
Video showing sg.nvim in use https://youtu.be/j5sfHG3z3ao?si=iiiiXYawQtYDcUv0&t=208

Yes, I agree with you that it would be the best to make it a separate project. Just wanted to share this idea. Maybe a discussion would have been a better place. Feel free to move it there.

Yes, an external source would be the best way to go about this. Here is the example repo: https://github.com/nvim-neo-tree/example-source
It is a very simple hello world. Netman or the internal filesystem source would be good real world examples of interactive lazy loaded file system browsing.
I'm going to convert this to a discussion.


I don't want to use autofac, what can I do?

I want to use this NuGet in an existing project.

Hi @burdier,
Currently, it's not possible to use the package without Autofac.
If you decide to go with Autofac you'll need to get done only 2 steps:

Install the package Autofac.Extensions.DependencyInjection
Add .UseServiceProviderFactory(new AutofacServiceProviderFactory()) to the CreateHostBuilder method in Program.cs

Thanks for your reply.


Display BMI on Patient Overview

The design ("Patient / Overview" screen).
BMI = weight / height ^ 2, where weight in kg and height im meters, or weight in pounds and height in inches.
Need to finish Vitals form and vitals extract to get these values

Do after https://github.com/beda-software/fhir-emr/issues/67

https://github.com/beda-software/fhir-emr/pull/72


Investigate LOBPCG convergence in silicon supercells

On https://github.com/mfherbst/DFTK.jl/pull/40 with supercell = [3,1,1] and display_progress=true in the eigensolver, the eigensolver fails to converge. Not sure if there are not enough extra bands or if we're doing something wrong. Need to investigate this to do David's thing. Also not sure what convergence criteria people typically take for the iterative eigensolver, but I'm pretty sure it's way less tight than what we do now.
@mfherbst I hope you don't mind, I'm kinda using the issue tracker as a TODO list...

No I don't. Will be fun more fun once we implement it :). I'm actually on David's thing right now playing with it and ran into the same issue :smile:.


remove MIDI attributes from silent elements

This removes att.instrumentIdent from the non-sounding layer elements mSpace, rest, mRest, and multiRest, and thus brings them in line with space.

Makes perfectly sense, as there are no rests in MIDI. Thanks for spotting!

But there can be notes with zero velocity, effectively making them rests.  😊
The ability to assign a rest to an instrument, even if nothing sounds, could be useful in situations where multiple instruments exist in a layer.  I can also imagine educational MIDI applications that would “sound out” rests.
--
p.
From: Benjamin W. Bohl @.>
Sent: Tuesday, April 20, 2021 10:18 AM
To: music-encoding/music-encoding @.>
Cc: Subscribed @.***>
Subject: Re: [music-encoding/music-encoding] remove MIDI attributes from silent elements (#788)
Makes perfectly sense, as there are no rests in MIDI. Thanks for spotting!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/music-encoding/music-encoding/pull/788#issuecomment-823358958, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABLSX3NWCISA4I6DL7P32V3TJWLJLANCNFSM43II6TMQ.

But in the case of converting MIDI to MEI shouldn't the 0-velocity midi:note should still be a mei:note?
Vice versa, when converting MEI to MIDI (a format not containing any rests) shouldn't all the mei:rests be ignored programmatically?
The sounding out idea is an interesting one though...

Comments below.
--
p.
From: Benjamin W. Bohl @.>
Sent: Tuesday, April 20, 2021 1:40 PM
To: music-encoding/music-encoding @.>
Cc: Roland, Perry D (pdr4h) @.>; Comment @.>
Subject: Re: [music-encoding/music-encoding] remove MIDI attributes from silent elements (#788)
But in the case of converting MIDI to MEI shouldn't the 0-velocity midi:note should still be a mei:note?
[PR: ] Most likely, but not necessarily.  It depends on the intention/meaning of the MID encoding.
Vice versa, when converting MEI to MIDI (a format not containing any rests) shouldn't all the mei:rests be ignored programmatically?
[PR: ] Again, most likely, but not necessarily.
The sounding out idea is an interesting one though...
[PR: ] The assignment of rests to an instrument has uses beyond conversion to MIDI too.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/music-encoding/music-encoding/pull/788#issuecomment-823512926, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABLSX3NIYZFA6DJIETL3AK3TJXC6ZANCNFSM43II6TMQ.

But in the case of converting MIDI to MEI shouldn't the 0-velocity midi:note should still be a mei:note?

There is no 0-velocity MIDI note: the MIDI note-on command with zero velocity functions are a MIDI note-off message.
MEI notes are equivalent to two MIDI events: a Note-on message and a note-off message, so there is not a one-to-one mapping.   MEI notes have duration, but MIDI events are instantaneous, and the duration has to be inferred from the pairing of on/off events.  There are two models that can be selected for pairing: FIFO (first-in-first-out) and LIFO (last-in-first-out).  If there are more note ones than notes off for a sustained timbre, then you get a stuck note, and if there are more note offs and note ons, it does not really matter since the extra note-offs will not alter the sound.  I sometimes use an extra note-off at the end of a MIDI track to extend it longer to prevent the software synths from ending a previous note too soon and chopping off the reverb sound (works on some synths, but not all).
An exception is for General MIDI drum-track notes which are only supposed to have a note-on message and no note-off message.  The drum notes behave like triggers to start a recording of the percussion instrument it represents, and there is no note-off control for these recordings.
Also there are two types of note-offs: There are formal set of note-off messages starting with the hex digit 8.  These messages have two parameters: (1) the key number to turn off and (2) how fast to turn off the note (release-velocity).  Most synthesizers (especially cheaper ones) do not pay attention to the release-velocity.  A second method for turning off a MIDI note is to use a note-on message with a 0 attack velocity.  This is not a note-on, but rather an alternate method of turning off MIDI notes.
If you want to encode rests in MIDI, using note-off commands would not be safe since it would likely alter the sound of the performed MIDI.  Something like MIDI file meta-messages would be more robust.

Vice versa, when converting MEI to MIDI (a format not containing any rests) shouldn't all the mei:rests be ignored programmatically?

There is not a one-to-one mapping between MDI note events and MEI data, so there can be forms of MIDI data that cannot be converted into MEI.

But there can be notes with zero velocity, effectively making them rests.
Sorry, but that doesn't make sense at all. As @craigsapp there is nothing like a 0-velocity MIDI note. Also you would need a pitch here, but the "sound" of the rest wouldn't change even if you change their position on the staff. What you are trying to do here looks to me more like an invisible note in MEI (which still has the @instr).

The assignment of rests to an instrument has uses beyond conversion to MIDI too.
Actually I can't think of any. But apart from my lack of understanding this, the concept of a notated rest is incompatible with MIDI. So even if you want/need to assign an instrument to a rest, why would you try to do this with a special MIDI attribute? If we had a general purpose instrument assignment method it would be something different, but we don't (and I don't see the pressing need for that). I think that this is something so special that you better should customize MEI for your needs.

Proceed.

From: Klaus Rettinghaus @.>
Sent: Wednesday, April 21, 2021 4:06 AM
To: music-encoding/music-encoding @.>
Cc: Roland, Perry D (pdr4h) @.>; Comment @.>
Subject: Re: [music-encoding/music-encoding] remove MIDI attributes from silent elements (#788)
But there can be notes with zero velocity, effectively making them rests.
Sorry, but that doesn't make sense at all. As @craigsapphttps://github.com/craigsapp there is nothing like a 0-velocity MIDI note. Also you would need a pitch here, but the "sound" of the rest wouldn't change even if you change their position on the staff. What you are trying to do here looks to me more like an invisible note in MEI (which still has the @instr).
The assignment of rests to an instrument has uses beyond conversion to MIDI too.
Actually I can't think of any. But apart from my lack of understanding this, the concept of a notated rest is incompatible with MIDI. So even if you want/need to assign an instrument to a rest, why would you try to do this with a special MIDI attribute? If we had a general purpose instrument assignment method it would be something different, but we don't (and I don't see the pressing need for that). I think that this is something so special that you better should customize MEI for your needs.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/music-encoding/music-encoding/pull/788#issuecomment-823866684, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABLSX3JC2QHU3U3YNMWENJTTJ2BRDANCNFSM43II6TMQ.


Update our CI config to leverage Ubuntu 22.04 LTS

Ubuntu has released v22.04 "Jammy Jellyfish". We should adopt it.

GitHub's not ready for 22 yet. Here's an issue to track on their end.
https://github.com/actions/virtual-environments/issues/5428

GitHub now supports Ubuntu 22.
PR #1111 exists to bring it in, but it predates our extensive switch to using the community setup-ruby package with some custom local scripts. We'll need to evaluate how to upgrade to Ubuntu v22 while keeping these other CI niceties we added.


22/12/2022 Peer-peer code review.

Your code structure is neat and easy to understand, good work.

rightly said by Ms. Caren. It is really a neat, clean and nice coding.


⚠ Bofrost.at has degraded performance

In b03609c, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 3329 ms

Resolved: Bofrost.at performance has improved in 3cdc98c after 8 minutes.


Rename bn_bias_params + add kwargs in core

Add use_kwargs_dict in the following functions

tensors (dtype=None, device=None, requires_grad=False, pin_memory=False)
BatchNorm (eps=1e-5, momentum=0.1, affine=True, track_running_stats=True)
InstanceNorm (eps=1e-5, momentum=0.1, track_running_stats=True)
ConvLayer (dilation=1, groups=1, padding_mode='zeros')
CrossEntropyLossFlat (weight=None, ignore_index=-100, reduction='mean')
BCEWithLogitsLossFlat (weight=None, reduction='mean', pos_weight=None)
BCELossFlat (weight=None, reduction='mean')
MSELossFlat (reduction='mean')
L1LossFlat (reduction='mean')
LabelSmoothingCrossEntropyFlat (eps=0.1, reduction='mean')

Renamed bn_bias_params to norm_bias_params.
L1LossFlat documentation stated "Same as nn.MSELoss". Fixed the
typo.

Thanks for the PR! Can you explain why this one?: "Renamed bn_bias_params to norm_bias_params"

There was a TODO to change the name.
norm_types = (nn.BatchNorm1d, nn.BatchNorm2d, nn.BatchNorm3d, nn.InstanceNorm1d, nn.InstanceNorm2d, nn.InstanceNorm3d)

# in the function
if isinstance(m, norm_types): return L(m.parameters())

bn_bias_params is a general function, so the name change.

Thanks!

FYI there's some places you could have used delegates to do this more easily, so I'll make those changes now.

There are some redundant arguments also, I think in the losses.


fix: requested character too large for encoding in chr function

Which issue does this PR close?

Closes #480 .
Rationale for this change

improves compatibility with spark
What changes are included in this PR?

added support for negative integers while encoding
also added support for integers larger than 256

How are these changes tested?

Test cases added, all the existing tests pass.

@andygrove this is ready for review.

Thanks @vaibhawvipul


Update default all-accreditations value

This change is

Pull Request Test Coverage Report for Build 2611

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 74.561%

Totals

Change from base Build 2610:
0.0%

Covered Lines:
1700

Relevant Lines:
2280

💛  - Coveralls


add license

it's a very interesting project!
Would you consider adding a license to this repository to specify under which terms this code can be used?

Yes, but not in this first version, i am working on the definitive version, and in this version I will a license.


the name variable is undefined.

Hm... my linter doesn't display an error in this place.
https://github.com/tenphi/numl/blob/9f5e0805fa82682242b693c20d1fb36ba8716355/src/index.js#L81

Thanks for noticing! This part is a dead code. I forgot to remove it or at least comment it.
This logic will be returned in v0.13 to support lazy loading for elements.

Fixed in #e22bb912d208ce69ad04bbfbba243575a726e67d


Fix possible NRE in GetAsync between DllResourceStore  and ResourceStore

GetAsync in DllResourceStore was returning Task<byte[]>? rather than Task<byte[]?>, upon which ResourceStore relies for checking which of the possible filenames is the requested resource, if any.
https://github.com/ppy/osu-framework/blob/7bac4227a52cd9fd96def0e3b4815b9902e3bf44/osu.Framework/IO/Stores/ResourceStore.cs#L94
The .ConfigueAwait above was acting on a possibly null Task rather than a task which can possibly return null.

Cleaned up style some, added test coverage for failing scenario because I didn't know how to test the fix otherwise. Seems ok.


Reduce quantity of data queries to Ethereum/NEAR nodes.

The status of bridge transfers is currently monitored via this checkStatusAll loop which will check the transaction and sync status for every transfer with an in-progress status: https://github.com/aurora-is-near/rainbow-bridge-client/blob/152b0755d550998adf3533e1dc1f4c0e5f3892c2/packages/client/src/index.ts#L178
The loop interval is currently fixed by the @near-eth/client user (the frontend) at around 5 secs. This works well for checking the status of a pending transaction being mined. But when checking the sync status of a multi-hour transfer, checking so frequently is a waste of resources (node, Infura...)
Possible solutions:

Keep the same checkStatusAll loop but timestamp the last checkSync done on the transfer object and skip future calls until a reasonable interval is reached: https://github.com/aurora-is-near/rainbow-bridge-client/blob/152b0755d550998adf3533e1dc1f4c0e5f3892c2/packages/nep141-erc20/src/natural-erc20/sendToNear/index.js#L125
a) Couple minutes interval and same interval for each connector ?
But Ethereum -> NEAR transfers are faster and show a more precise status with the number of confirmations. (x/30)
b) Optionally defined at transfer creation ?
Each transfer can define it's own checkSync interval at transfer creation (with a reasonable default value adapted to the transfer direction so that if doesn't need to be specified by the user of the library)

Introduce a new mining status to differentiate checkTransactionStatus from checkSync and run 2 loops separately at different intervals. One loop checking the status of pending transactions while the other checking the sync status of transfers.

I'm currently leaning towards solution 1.b) which gives more freedom to connector libraries and keeps the @near-eth/client more general with the same ConnectorLib interface https://github.com/aurora-is-near/rainbow-bridge-client/blob/152b0755d550998adf3533e1dc1f4c0e5f3892c2/packages/client/src/types.ts#L53
cc @mfornet

Currently during checkSync (called every 5 secs) of Ethereum -> Aurora transfers, findEthProof is called to check whether a transfer was finalized by the event relayer. So a proof is built every 5 secs and building a proof requires querying  all the transaction receipts in a block individually: https://github.com/aurora-is-near/rainbow-bridge-client/blob/39ae822e0d72da8a66a68cce7c65afdc044b759b/packages/utils/src/findProof.ts#L99
This would explain the excess number of eth_getTransactionReceipt queries observed on infura.
For example if the event relayer is delayed by 1 hour, with 150 tx in the deposit block, that's 150 * 12 * 60 = 108k eth_getTransactionReceipt calls for a single user's transfer while the growth plan of infura is 5M calls per day for all users.

This is less of an issue on bridgetonear.org because checkSync will stop running if the event relayer didn't finalize within 10 blocks and fallback to the user's NEAR wallet to finalize the transfer. But on aurora.dev checkSync will loop forever until the transfer is finalized by the event relayer.

I like the idea about doing one transfer, then estimating the amount of time until the next expected change and repeat.
This will work fine for multi-hour transaction, and for fast transactions.
For transactions that depends on the event relayer finalizing them, we can do the same, since relayer is running in a loop, and it should be picking new tx as they appear. However it is possible for several reasons that relayer fails. To avoid oversaturating our endpoints we can exponentially increase the time we wait between calls up to a reasonable, but large amount. Start with 1 second and increase up to 10 minutes?

I'm also towards 1.b solution! I know that the amount is crazy as I was able to reach those limits quite easily in Alchemy, for example, during some hard testing of the bridge.
I also like the idea that @mfornet mentioned, this is a quite popular solution to reduce the number of redundant calls. I.e. we estimate that TX will take up to 10 minutes to complete, then we multiply that time by some factor (e.g. 1.5 * 10 minutes = 15 minutes) and during this time we expect to have the constant time of checking, e.g. 30 seconds. When this time ends up but the TX is not yet finalized, we increase the interval twice. And then this interval increases up to some limit, e.g. 10 minutes.