Source locators

This basically adds the SourceInfo trait and several concrete classes for when source information isn't available and a concrete class for source information from a Scala source line.
Source information is also added to the FIRRTL IR nodes and emitter as an explicit parameter. Source information is propagated through the Chisel frontend and internals as an implicit parameter. For methods that don't return Unit (aka nothing), a macro transform explicitly adds the SourceInfo parameter as implicitly[SourceInfo] so apply() calls can be chained after. The transformed versions of methods are of the same name, except with do_ prepended. One of the macros (SourceInfoTransform) automatically detects the function name, which eliminates a lot of boilerplate.
The package split is up for debate. There is two packages:
coreMacros defines the transforms (that add explicit implicits: implicitly[SourceInfo]) and nothing else. This allows the macros to be used and invoked at the next level, which prevents a lot of ugly do_* calls everywhere. Turns out you just need the macro transform definitions, not the functions that are defined as macros, in a different compilation unit.
chiselFrontend defines the core data types. There's no real reason this needs to be separate from the rest of Chisel (other than the assert macros), but I think there's a certain elegance for splitting core data types from helpers (Driver and friends) and utils. chiselFrontend is split out from the rest of utils as a layer of safety, since the SourceInfo.materialize macro is defined in chiselFrontend, this prevents the system from generating source locators in Chisel core, which is almost certainly a bug.
Mems a work in progress, and is dependent on #189. Will be future work, probably near future work.
Defining how library writers would have source locators for entry points into their libraries is future work.
Only tested with Chisel unit tests. Someone should test with a more complex design, like rocket chip. Requires a FIRRTL compiler change to support the source info annotations. This will not yet work. However, you can test correctness without source locators passed through to FIRRTL by eliminating the part in Emitter.scala where the locators are actually generated.
ucb-bar/firrtl#166 is in, so this should work now!
Implementation for #147
Partially based on implementation sketch in #158

I can confirm that (with ucb-bar/firrtl#166) this successfully builds rocket-chip and executes the asm and bmark tests

retest this please

Why do the transformed do forms still take an implicit and thus need a separate argument list?

You shouldn't override a macro application with another macro application. override implies a runtime polymorphism. However, macros are resolved by the compiler and thus potential confusion.
I quite enjoy the solution proposed by the responder in https://groups.google.com/forum/#!searchin/scala-internals/twigg/scala-internals/Li-206hiwNE/V15YlmP2e0IJ
and subsequently executed in the gama frontend I showed you.

Transformed do_ forms take a separate argument list because there are methods take take a variable amount of arguments so I can't tack source locators onto the end. It could be in front of the usual arguments, but I think this is stylistically cleaner, being more consistent with the non do_ forms.
It doesn't need to be implicit though. Probably would be good to not have it be implicit for safety reasons.

Technically, the macros can also pack all the varargs into a sequence for the do_* forms. However, that justification is fairly reasonable. I'm still a fan of the single argument lists though so that the do_* forms provide nice, simple, distinct API for user (library) use.

Now I remember why all the sourceInfo parameters needed to be implicit: so they could be passed through to internal calls to core functions. For example,
  override def <> (that: Data)(implicit sourceInfo: SourceInfo): Unit = this := that

will error out with could not find implicit value if sourceInfo is not declared as implicit. So leaving that as-is, unless you have a better solution. The alternative was to manually thread through sourceInfo, which significantly hinders readability.

You could avoid the complications of threading by transforming directly into the proper function....
There is then the matter of functions that aren't trivially transformable (like andR) where expression in the do form is likely fine for small expressions. (Large expressions can declare an implicit val) The do-form version also ensure that you don't lose the source info.
Also, that example doesn't need macro transformations so you'd have to keep it implicit anyway

Transforming directly into the target functions puts more code into the macros, which in my opinion hides functionality and makes chiselFrontend less readable. Keeping this simple transform structure means that to understand the chiselFrontend internals, you only need to know that the macros transform methods by appending do_ in front of the function name and adding a second parameter list with sourceInfo. Otherwise, we'll need more macros (possibly in a separate compilation unit) and people may need to read each macro separately to understand what chiselFrontend is doing.

About overriding macros: attempted to implement the solution to get rid of this.type, and it doesn't work without more changes. Let's keep this already-large PR contained to just source info and have codebase improvements in a separate issue / PR?

Then this pull request should wait

Is there a practical reason you want to get rid of this.type in / before this PR (other than if it isn't blocking something, it might not get done)? It could end up as a merge / rebase nightmare, which I'd really like to avoid. Also, rocket-chip builds on this as-is, which is a pretty decent benchmark.
If you just want to get rid of the macro overrides, that still might be possible while leaving the this.type alone and hopefully limiting the scope of changes.

So, there are two different but related issues:

The use of this.type: I dislike it because it is wrong and a hack. this.type is a singleton type satisfied by only one class instance, this. The need to use a type cast is a signal that you are maybe doing something wrong.
It is tolerable for stuff like cloneType because we don't want to require the user to issue the boilerplate necessary to avoid it (using and defining typeclasses as per https://tpolecat.github.io/2015/04/29/f-bounds.html although I am making some assumptions on compile-time resolvability). However, for the definition of Chisel API functions, there is no reason for the hack since the user sees no boilerplate. (Also, the tolerability diminished when that trick is then used as justification to weaken quality elsewhere.)

It is not good to override a macro function with another macro function. In fact, it is likely best for any macro function to be final (as scalac already should error in 2.11 if you try to implement an abstract method with a macro function) since otherwise you are blurring the lines between compile-time replacement and runtime polymorphism. This way debugging is clear. The user invokes a call, you know they can only have been calling that specific macro function and thus debug from there. You don't have to worry about whether the compile time type matches the runtime type and so on.

The reason I lump them together is that the same idiom, using type members, solves both.
The overarching reason I am more particular is that scala macros are complicated and quite the power feature. You are rewriting the user's code in-place at the AST level in the middle of a scalac invocation. There are a lot of things that can go wrong and scala macros already call themselves out as being a little rough around the edges (e.g. the lack of hygiene). Rocket chip building is great in general but a poor example for testing macro use because rocket chip already works (both compiling, elaborating, and in tests). I am fearful of already hard to debug chisel issues becoming even harder to debug because the user (or chisel dev) does something that causes a macro invocation failure which crashes scalac, etc.

Limiting the change to Self types in the bitwise operators (shifts, pad, and twiddle) breaks rocket-chip (see 919d424):
hardfloat/src/main/scala/INToRecFN.scala:100: type mismatch;
found   : Chisel.UInt
required: INToRecFN.this.normCount.Self
       unroundedExp = unroundedExp(expWidth - 2, 0)
                                  ^

hardfloat/src/main/scala/INToRecFN.scala:103: type mismatch;
found   : Chisel.UInt
required: INToRecFN.this.normCount.Self
           Cat(UInt(0, expWidth - 1 - log2Up(intWidth)), unroundedExp)
              ^

For the concrete classes (which already are final), it should work if you also concretize Self (type Self = UInt, etc.). Unsure how you'll disentangle UInt and Bool though.
The need to use asInstanceOf in your implementation indicates the typer detected an issue. Subtyping means you can't Self won't be narrowed further.
Consider:
class A;
class B extends A;

class Parent {
  type T <: A // this says T is upper bounded by A, T at least A
  def getT: T = new A // this won't compile because just A isn't provably a T.
class Child extends Parent {
  type T <: B
}
val myB: B = (new Child).getT

In fact, this type hole is exhibited in your code. For example, do_<< is stated to return Self. In Bool, Self <: Bool means do_<< should return a subtype of Bool. But, do_<< returns a UInt and UInt <: Bool does not hold.
Note also, this also exposes how aggressive the scala type system is very aggressive about narrowing the type of a var (hence why people usually ascribe types to their vars).

Also, confirming that the single case statement matches essentially everything needed.

I think the only outstanding issue left on this PR is the Self types.
... which also turns out to be the most difficult and stubborn ...
Concrete types (like type Self = SInt) don't seem to work, it doesn't seem to detect overrides:
[error] chisel3/chiselFrontend/src/main/scala/Chisel/Bits.scala:645: type mismatch;
[error]  found   : SInt.this.(some other)Chisel.Self
[error]     (which expands to)  Chisel.Bits
[error]  required: SInt.this.Chisel.Self
[error]     (which expands to)  Chisel.SInt
[error]     this >> that.toInt

Bounded types (like type Self <: SInt) also don't work, it can't determine (for whatever reason) that the concrete type satisfies the required Self type:
[error] chisel3/chiselFrontend/src/main/scala/Chisel/Bits.scala:461: type mismatch;
[error]  found   : Chisel.UInt
[error]  required: UInt.this.Self
[error]     binop(sourceInfo, UInt(this.width), DynamicShiftRightOp, that)

F-bounds (like now Num is implemented, where you have trait Num[T <: Data]) may work, but I'm not sure how to make that play nice with concrete types that also extend each other (Bool extends UInt, but neither can be (directly?) type parameterized without changing the user facing API).

@sdtwigg need a resolution on this PR, either:

stick with macro overrides and this.type (removing the "Make all macrodefs final, use Self type" commit). rocket-chip should still build, and an issue can be opened so the search for a really good implementation solution can continue without fear of a merge trainwreck as work on chisel3 continues.
make macrodefs final, use type Self <: UInt (and similar) and .asInstanceOf workarounds where applicable (code as it is right now, with the "Make all macrodefs final, use Self type" commit). Rocket-chip would need to be fixed to make the typer happy. Unclear if this is actually a net improvement in code quality.
some better solution you know of right now that addresses all of these issues?

I also take it there are no other outstanding issues with this PR (at least ones that don't require wider discussion / should be opened as separate issues)?

Change to whitebox macros that will morph the return type after the substitution. Still treat macro functions as final.

I'm also standing by my insistence that assert should not use an extra macro invocation.

Assert no longer does, it's just a regular function with an implicit sourceInfo now (since it returns Unit). Just one macro layer (unless you count the sourceInfo.materialize), like it was before this PR.

Is it still possible for the source lines inserted into the message string to be different from the source lines captured by the implicit source info? That was a main concern.

Technically that is possible because sourceInfo.materialize doesn't share an implementation with assert.apply_impl (and so it's non-DRY), but I think the implementations (currently) are equivalent where it matters. sourceInfo.materialize doesn't (and I think shouldn't) provide lineContent (yes, I know, deprecated), which is very helpful for assert readability.
In the future, sourceInfo may provide a more stack-like functionality (to deal with libraries), which may differ from the desired behavior of assert messages. But that's a discussion for another day.

I'm referring specifically to:
def myAssert(cond: Bool, message: String)(implicit val sinfo: SourceInfo): Unit = {
  assert(cond, message)
}

It seems like the source information injected into the message will be different from the source information that gets injected into the assert command. This is not acceptable.

Is it not acceptable? I think it depends on user expectations for assert vs. source locators. In my opinion, when I see an assert go off, I want to see the line of code with the assert(...) call, rather than where it entered the library. Whereas source locators provide a lot more flexibility (and don't have established conventions yet, either).

Then, why don't we show the line in Chisel/assert.scala where the command was pushed, since that is where the assert command was 'actually' added?

If every assert(...) call (somewhere in your own code) gave you the same message (Assertion failure, chisel/Assert.scala:xx pushCommand(Stop(...))), that's not useful at all. Neither would the library entry point (Assertion failure, Module(myFlakyModule())), since there could be multiple assertions in that call.
Anyways, what would your suggested resolution be? If you really hate it that much, you could argue that the assertion should print only the custom user message (without source position / line) since some information is available in source locators. But I don't think that's a good debuggabilty decision.

In my opinion, asserts and source locators, while sharing some similar code and functionality, have different use cases and some divergence to match user expectations and provide the most useful debugging output is acceptable.

Assert should either take an implicit SourceInfo and use the line information in there to fill both parts of the assert statement OR assert should not take an implicit SourceInfo and use the macroApplication to construct both the message and the command info.

For case 1 (use implicit sourceInfo only), what happens if the source info isn't specific enough to narrow down the specific assert statement (say, the sourceInfo only provides the library entry point - yes, bad design, I know - where the called library contains multiple asserts that the developer didn't bother writing specific messages for)?
For case 2, this diverges from the general pattern for source locators and makes this a special case. What if users wanted multiple source locators showing the "stack" through several libraries deep (a possible feature implemented later)? Why should assert be special and not provide that?

The whole point of the implicit source info machinery is so libraries can
'extend the veil' of what is considered 'internal.'
Assert already is a special case since it is using its own macro
application. I am leaning towards case 2 (not having it use its own
implicit) since lineContent is already locked to the library invocation
site. This way all the source information points to the same place. Assert
taking an implicit is basically a lie since you can't fully 'extend the
veil' (because of lineContent).
Regarding case 1, you can raise the same issue for if the library uses
other base Chisel API calls improperly. However, given the previous points,
I am less concerned about case 1.
On Wed, May 18, 2016 at 4:29 PM, Richard Lin<EMAIL_ADDRESS>wrote:

For case 1 (use implicit sourceInfo only), what happens if the source info
isn't specific enough to narrow down the specific assert statement (say,
the sourceInfo only provides the library entry point - yes, bad design, I
know - where the called library contains multiple asserts that the
developer didn't bother writing specific messages for)?
For case 2, this diverges from the general pattern for source locators and
makes this a special case. What if users wanted multiple source locators
showing the "stack" through several libraries deep (a possible feature
implemented later)? Why should assert be special and not provide that?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ucb-bar/chisel3/pull/186#issuecomment-220188122

I don't think it's a good idea at all to remove implicit sourceInfo from assert, since that makes it oddly nonuniform compared to everything else.
If you really hate it this much, I'll just nuke the custom assert macro (delete the file, position, and line content from the printed assert message). If people like it they can open an issue to ask for it back. I personally think the debugging info provided is super useful, but I can't back that up with solid user data right now. This debate should really be its own larger issue, too.

Given that I am of the opinion that users should be supply their own
message to assert failures, I don't find lineContent that useful. (It just
encourages people to be lazier.)
My insistence is not to make it more non-uniform but to (in the current
implementation) note that it already is non-uniform compared to everything
else.
On Wed, May 18, 2016 at 4:54 PM, Richard Lin<EMAIL_ADDRESS>wrote:

I don't think it's a good idea at all to remove implicit sourceInfo from
assert, since that makes it oddly nonuniform compared to everything else.
If you really hate it this much, I'll just nuke the custom assert macro
(delete the file, position, and line content from the printed assert
message). If people like it they can open an issue to ask for it back. I
personally think the debugging info provided is super useful, but I can't
back that up with solid user data right now. This debate should really be
its own larger issue, too.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/ucb-bar/chisel3/pull/186#issuecomment-220191870

It's only non-uniform in that it provides additional data that isn't necessarily consistent with sourceInfo, but the sourceInfo is uniform with everything else.
I don't think it's reasonable to expect users to always supply assertion messages, especially when the assertion is obvious from the code. If you have assert(numBits > 0), do you really want to write assert(numBits > 0, "numBits must be positive") (which is really kind of redundant), or would you just want the system print out the assert code from which the logic should be immediately obvious?

Need a resolution on this. Either:

Keep as is, accepting that sourceInfo may not be consistent with the assertion print, but that they have different use cases.
Delete filename, line number, and line content from the assertion print, instead relying on sourceInfo being propagated properly (not sure if the FIRRTL compiler propagates it to Verilog yet). I don't think it's a good idea to have assert try to parse the implicit sourceInfo, since it's something that can change and take multiple forms (for example, what should happen if a list of sourceInfo, stack-trace-like, is given?)
Or something else that doesn't break uniformity of sourceInfo. I don't see a good reason to make it non-uniform, and I think doing so will confuse the heck out of people who might be trying to debug asserts.

I don't think the potential assert inconsistency is a good reason to block
this PR.
I also agree with Richard that user-provided assertion failure messages
should not be mandatory, as (1) they are often redundant with the trigger
condition and (2) making them shorter to write will further encourage their
use.
On Wed, May 18, 2016 at 5:35 PM, Richard Lin<EMAIL_ADDRESS>wrote:

Need a resolution on this. Either:

Keep as is, accepting that sourceInfo may not be consistent with the
assertion print, but that they have different use cases.
Delete filename, line number, and line content from the assertion
print, instead relying on sourceInfo being propagated properly (not sure if
the FIRRTL compiler propagates it to Verilog yet). I don't think it's a
good idea to have assert try to parse the implicit sourceInfo, since it's
something that can change and take multiple forms (for example, what should
happen if a list of sourceInfo, stack-trace-like, is given?)
Or something else that doesn't break uniformity of sourceInfo. I
don't see a good reason to make it non-uniform, and I think doing so will
confuse the heck out of people who might be trying to debug asserts.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/ucb-bar/chisel3/pull/186#issuecomment-220197711

My preference is 'option 4':
Assert doesn't take an implicit SourceInfo and both its message information and SourceInfo is filled in by the macroApplication details from it 'current' macro function.
I don't believe the scenario where the chisel developer debugging an issue with assert BOTH understands the 'current' assert transform macro to build up the message AND how implicits and the source info implicit materializer works BUT can't fathom how a macro that does both at once works. Assert is already going to be confusing because regardless of what you choose you are layering another macro application on top of it. The fact that you do this to add source information to the message string is already making it non-uniform to other functions.
Regardless, my main hangup was that you had macros overriding macros and that has been resolved. I don't care enough about the dual construction of SourceInfo in assert to argue this further.

I think the asserts is ultimately going to be a user interfaces issue, and we can't do more than speculate at this time. I'm going to leave it as is and we can readdress it later if necessary.
Will squash commits and merge.


Update emscripten binary compiled with -O3 + js algo

change C for matching with AS
also update js algo
improve AS. Add cached globals

Wow, a new gift every day! Emscripten is running really fast now. Let's see- on this particular laptop I'm seeing JS 115, Emscripten 160, Walt 100, AssemblyScript 130.
I'm working on another one of these things comparing the 4 of them using the Mandelbrot Set. (I see AS has one already.) I suspect it's going to be FPU bound and the performance won't be much different. So far Walt is slightly underperforming JS again although it seems to do a better job than JS at exploiting one of the optimizations (cycle detection).

It seems emscripten unroll all loops twice and use LICM optimization that's why it faster

That makes sense, since all those loops are parallelizable; with pthreads and SharedArrayBuffer you could easily assign horizontal bands to individual workers. (Although this calculation could also be done using webGL.)

AssemblyScript would support atomics and SIMD. PR for atomics (threads) already exists


Subdomain locales should all accept the same session cookie

This can't be solved universally, so it has been solved by documenting the necessary configuration settings for the express-session module to make it aware that the session cookie is good across subdomains of a specific domain.


python310Packages.requests-futures: 1.0.0 -> 1.0.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python310Packages.requests-futures is: Asynchronous Python HTTP Requests for Humans using Futures
meta.homepage for python310Packages.requests-futures is: https://github.com/ross/requests-futures
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.0.1 with grep in /nix/store/4sc6and3zxd9263d91zq8sd5nljzcd41-python3.10-requests-futures-1.0.1
found 1.0.1 in filename of file in /nix/store/4sc6and3zxd9263d91zq8sd5nljzcd41-python3.10-requests-futures-1.0.1

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

4 package rebuild(s)

First fifty rebuilds by attrpath
maigret
python310Packages.requests-futures
python311Packages.requests-futures
sherlock

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/4sc6and3zxd9263d91zq8sd5nljzcd41-python3.10-requests-futures-1.0.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python310Packages.requests-futures https://github.com/r-ryantm/nixpkgs/archive/9a23a0432dd56de6958f3b2a37031b85baf18907.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/4sc6and3zxd9263d91zq8sd5nljzcd41-python3.10-requests-futures-1.0.1
ls -la /nix/store/4sc6and3zxd9263d91zq8sd5nljzcd41-python3.10-requests-futures-1.0.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

4 packages built:

maigret
python310Packages.requests-futures
python311Packages.requests-futures
sherlock

Maintainer pings
cc @applePrincess for testing.


feat: new independent showcase page

Changes:
Move the user wall on the home page to a separate page to meet ASF's regulations for the project website.
Screenshots of the change:

cc @Baoyuantop @LiteSun to have a review

Hey @bzp2010 this version looks nice and clean, but I feel we can work more to build over this in the future. Personally I was thinking something on the lines of this page with the case studies linking to blogs on our websites or their's related to the work.
For now, this version does the work and looks clean too, so I feel we can keep it and moving forward build on it's foundation.
On a side note, given that this page is clear, what you all think about my suggestion in #519 on showcasing our users ?

Hi, @1502shivam-singh.
I saw your explanation there. I think this is very good. At the same time, we can fold a part of the logo by supporting downward expansion. However, this requires further understanding and interviews with users. This may take some time to move forward gradually.

Hi @1502shivam-singh , your design is good way IMO, and in apache way, we need a new page to show the user cases in stead of showing them in home page, so I will be very kind of you to give more advices on the single page design, thanks a lot

sorry to make nofollow to the wrong link, just modify them @bzp2010

Hi @1502shivam-singh , your design is good way IMO, and in apache way, we need a new page to show the user cases in stead of showing them in home page, so It will be very kind of you to give more advices on the single page design, thanks a lot

Sure, one small suggestion I have as of now is to redirect the learn more links to their respective case studies, but as mentioned by @bzp2010 above that these are on availability basis, so what we can do is link the ones we have and keep the rest as is. As time progresses we could adapt changes later.
As of visual design, we need to work on this, but firstly having something up is important so improving visual design can be done later I guess.

Nice suggestion @1502shivam-singh , we have some of the use case blogs in our website, they can be as the user case studies here, not many though. How about we use this page as the user case show page, and at the same time use it as the user case index page?
also cc @Serendipity96 @yzeng25 @juzhiyuan @Baoyuantop @KishaniKandasamy @moonming

Hi, @liuxiran. I have modified the showcase page to the style in the connection. link here, and demo here
In the process of modification, I found that some logo images are non-standard shapes. (e.g. square or too wide) These pictures don't show well. We need to notify these users to update the logo image. If there is no response, it should be removed or hidden.

In the process of modification, I found that some logo images are non-standard shapes. (e.g. square or too wide) These pictures don't show well. We need to notify these users to update the logo image. If there is no response, it should be removed or hidden.

LGTM, we can create a new issue to trace it
and it would be better to keep the name the same as the url, use showcase would be better then, or unified into powered by is also a good choice.

Hi @bzp2010 , please fix the conflict file when you have time , thanks

cc @Baoyuantop @1502shivam-singh to take a look, thanks

Update: Add a timeout for Axios to prevent the detection process from executing indefinitely.
cc @liuxiran @juzhiyuan


fix: enabled --create-sbom on each build we have

should have merged alongwith https://github.com/adoptium/temurin-build/pull/3053
Ref: https://github.com/adoptium/temurin-build/pull/3053#issuecomment-1188914473

Couple of quick questions:

Were the SBOM capabilities back-ported to Java 11?  Not sure we can SBOM there?
Is SBOM == Reproducible Build or just the creation of the SBOM?
Will this run on nightlies or only releases?

Couple of quick questions:
1. Were the SBOM capabilities back-ported to Java 11?  Not sure we can SBOM there?
2. Is SBOM == Reproducible Build or just the creation of the SBOM?
3. Will this run on nightlies or only releases?

TL;DR 1a) Yes, 2) No, 3) Both
SBOM creation and reproducible build enablement are separate actions - reproducible is enabled when a RELEASE build is done.
We have SBOM creation for all releases - they are included in the artifacts for all nightly builds as well as releases.

@sxa I think you can approve and merge this tomorrow

@sxa guess we have to merge this now, because https://github.com/adoptium/temurin-build/pull/3053 has been merged ?

@sxa guess we have to merge this now, because adoptium/temurin-build#3053 has been merged ?

ARGH! Yes ... Since @andrew-m-leonard is aware he can keep an eye on any side-effects from merging it


few improvements

What has been done
I use this library and found few things that I need. Maybe you can merge.

Disable recursive db_path walk in find function
Remove Input image must not have non-english characters error. In my system all works fine, idk why you've added this. If it's really important, you can make it a warning or optional. Definitely should be disablable
Interupt searching by pressing ctrl+C if DEEPFACE_KEYBOARD_INTERRUPT env variable is set. Useful for big searches - just press ctrl+c and thanks to caching, you can get results now, and continue the search later

1- having 2 branches for recursive or not is not a good design. IMO, going with recursive one is better.
2- Some versions of opencv throws exception if non-english characters available in the file name. You can find this in the closed issues. It was working on my environment, too. However, this doesn't avoid to see issues in repo. So, this behavior mustn't be optional.
3- may be helpful
So, it seems better not to merge this PR. If you create a new PR for the 3rd bullet, then I will be happy to merge.

1- You should organize folder for this task. That is not a problem from deepface's perspective.
2- Because if someone is having that issue, then an issue will be raised and I have to respond them all.


Remove unnecessary components on dashboard

Remove unnecessary components on dashboard

Yeah, definitely, those unnecessary components should be removed asap, but maybe we can use those components as a reference.


qemu: fix breakage of old binaries

clear container kernel 4.5-50 breaks old binaries, for example centos6.
Fix this by using vsyscall=emulate
Signed-off-by: WANG Chao<EMAIL_ADDRESS>

Coverage remained the same at 66.011% when pulling f4ea7d57213548035a64d1d412f6651d06b61e8d on wcwxyz:fix-vsyscall into 2d66ecacf63f8efc51f73f50b93f2140169ed90c on containers:master.

Coverage remained the same at 66.011% when pulling f4ea7d57213548035a64d1d412f6651d06b61e8d on wcwxyz:fix-vsyscall into 2d66ecacf63f8efc51f73f50b93f2140169ed90c on containers:master.

For reference for folks the info from the kernel is here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/kernel-parameters.txt#n4387
The theory looks OK to me. I see that emulate is the practical and safer method of enabling this.
Would you happen to have an easy example to demonstrate the failure, and maybe some example output of what you see when it fails - if that is appropriate?
I've added @sboeuf to review. @sameo is not here to review at the minute, so asking @dlespiau for his thoughts as well.

Running centos:6 /bin/bash would a segment fault:
[    3.940412] bash[222] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7fff828c0a88 ax:ffffffffff600400 si:7fff828c0f70 di:0
[    3.940422] bash[222]: segfault at ffffffffff600400 ip ffffffffff600400 sp 00007fff828c0a88 error 15
kernel: /usr/share/clear-containers/vmlinux-4.5-50.container
image: /usr/share/clear-containers/clear-16410-containers.img

Reading from the kernel info, I have two questions:

I don't understand why we have to enable vsyscall=emulate since emulate is designated as the default one.
Docs mentions that emulatewill make some exploits possible (even if hard) while no exploits are possible with none (but breakage possible, and I think that's our case, right ?).

The big question is, do we want to support old binaries like the ones we can find inside centos6 ? I don't think we want to support centos 6 anyway. Our centos target is centos 7.
@grahamwhaley can you give some feedback here ?

@wcwxyz we don't want to add such a parameter hardcoded into virtcontainers, but what you could do is add extra kernel parameters through the runtime.
Right now, the way you can do that is to add one more entry here: https://github.com/clearcontainers/runtime/blob/3.0.0-alpha.4/create.go#L149
ccKernelParams := []vc.Param{
		{
			Key:   "vsyscall",
			Value: "emulate",
		},
                ...
}

And then you will need to rebuild the runtime.
Another way would be for you to submit a PR to clearcontainers/runtime, by adding a configuration field to our config file configuration.toml and parse/add the kernel parameters you would have passed:
[hypervisor.qemu]
extra_kernel_params = "vsyscall=emulate foo1=bar1 foo2=bar2"
...

-1

So, with some more info and retrospect, I agree with @sboeuf - the right way to do this is not to hard wire it here, but to have a mechanism where such things can optionally be added in. That is just going to be a better more scale-able way forwards, and it avoids us adding the extra bit of attack surface to the default runtime when there is generally not a need.
For more reference, it looks like our setting for the vsyscalls in our default kernel config is indeed NONE:
https://github.com/clearcontainers/linux/blob/v4.9.34-clear-containers/arch/x86/configs/clear_containers_defconfig#L500
and hence the need to enable this on the command line if needed.
I'll stick a 'do not merge' on this to avoid any accidental button presses.

By centos6, I mean the docker image centos:6. You can't change how distros build their binaries.
I think a generic runtime should be able to run every docker image by default. For those who want to reduce attack surface they can add "vsyscall=none" by method @sboeuf mentioned above.
Anyway I'm happy to submit a pr to support passing extra kernel args from configuration file. But believe me, centos6 is old, yet still very popular.
What do you think?

If you guys are looking for improving kernel security, here's a good start:
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings

This issue is address via
https://github.com/containers/virtcontainers/pull/326
https://github.com/clearcontainers/runtime/pull/369


how to change helo

i dont see why it is nessesary to include the local ip address of my device into an unencrypted mail header that goes around the world while being monitored by all its *** players, its more an security risc then anything good. Think of the dalec who could kill my sweet robot dog just because its (or hes i am not quite sure) sending its exact locations in all messages ;)... So could you add an option to change the string send as helo by k9mail to something else?
tuan

Duplicate of #2793


Concatenating Strings with Plus Operator

Challenge Name

Concatenating Strings with Plus Operator
Issue Description

Im am using Linux Mint
For some reason it won't work proper
Browser Information

Browser Name, Version: Firefox,Recent?
Operating System: Linux Mint Serena
Mobile, Desktop, or Tablet: PC Desktop

Your Code

var myStr = "This is the start."+"This is the end.";

Screenshot

/home/roarke/Pictures/Concatenating Strings with Plus Operator.png

I'm having issues regular I get so far than this happens. Any ideas what it might be

In English sentences are separated by a space. You need a space between the first and second sentence. Reference how it is done in the example.

@PaulWalt74 Thank you for reporting this issue. But as another has mentioned, you need spaces. Please take a look at the note in the challenge itself.

Watch out for spaces. Concatenation does not add spaces between concatenated strings, so you'll need to add them yourself.

This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the "help" button on the challenge on freeCodeCamp, which will take you to the help chatroom for that specific challenge. You can also view our full list of official chatrooms.
If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding!

/home/roarke/Pictures/Concatenating Strings with Plus Operator.png
not working

It's a bug or for some reason it is not working in mint serena
On Fri, Jun 23, 2017 at 4:43 PM, Eric Leung<EMAIL_ADDRESS>wrote:

@PaulWalt74 https://github.com/paulwalt74 Thank you for reporting this
issue. But as another has mentioned, you need spaces. Please take a look at
the note in the challenge itself.
Watch out for spaces. Concatenation does not add spaces between
concatenated strings, so you'll need to add them yourself.
This is a standard message notifying you that this issue seems to be a
request for help. Instead of asking for help here, please click the "help"
button on the challenge on freeCodeCamp, which will take you to the help
chatroom for that specific challenge. You can also view our full list of
official chatrooms
http://forum.freecodecamp.com/t/free-code-camp-official-chat-rooms/19390
.
If you think I'm wrong in closing this issue, please reopen it and add
further clarification. Thank you, and happy coding!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/15491#issuecomment-310779158,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AbmhmWKnPnQRB9k2M6JmAgiO8PqSJcorks5sHDF0gaJpZM4ODHE5
.


Top fixed menu doesn't fixed inside a sidebar

Bug Report
Steps
open an sidebar and scroll it
Expected Result
the top fixed menu in this sidebar should be fixed
Actual Result
the menu is static
Version
0.82.0
Testcase
https://codesandbox.io/s/l2r183r3yl

Please post CSS related issues in the main repo: https://github.com/Semantic-Org/Semantic-UI
However, I am not sure that the described behavior is supported.


Auto create basic tier

This branch was based on feature/create-tier--create-tier-command but that branch does not seem to exist anymore, so I set feature/create-tier as base instead.

Take a look at the diff. There is some pipeline stuff listed that shouldn't be there

Sorry for the force, I couldn't revert a merge commit that was poisioning the PR. It should be good now.


proposal: x/net/proxy provide a Dialer like interface that exposes DialContext()

Currently, if one tries to instantiate a socks5 dialer, one receives a response with the proxy.Dialer interface.  This interface only exposes the Dial() (context free) method.  This method is deprecated in many cases (i.e. http client transports).  DialContext() is actually implemented for all the proxies, but is only visible within the internal package, so is not actually usable by end users.
Motivated by https://github.com/golang/net/pull/164 but the comment there is that since that PR changes the proxy.Dialer interface it breaks backwards compatibility (which I assume is if external users use the interface, and not just limited to the proxy package) and therefore should go through the proposal process to determine what API changes should be.

Interfaces can't be changed, that breaks backwards compatibility.
golang.org/x/net/proxy already has an interface for this ContextDialer
What can change is documentation to say that all returned dialers can be asserted to ContextDialer


JAXRS-based JagaHttpClient takes a JAXRS ClientBuilder, not Client..

this implies it has to build Clients, which it in fact does. It does this per request is likely a by-product of feign allowing timeouts at the request level. This is handled in different ways in the feign.Client impls..
Sorry for not providing code links, but I wanted to get this in before the day is done:)

Thought I wrote this down...
But one work-around (hack) is to take a Client instance and pass a ClientBuilder that will only ever return that one Client instance.

Given that we've found out multiple clients have issues with how the builder timeout work, I'm wondering if we should just hide that in our builder.  AFAIK, the main problem there is that there is no way to set timeouts on the default client.  I wonder if that's a big deal.  If it is, there are likely multiple ways we can address it.
Thoughts on removing those from the builder?

Hey Sam, just to make sure I understood, are you suggesting to remove the timeouts configuration from Mocca builder, and let users configure them directly with the HTTP clients (and then set the client in the builder)?

Yes, but I may do something to accommodate timeouts for the default client in the builder.  Of course, this would be a breaking API change.  I'll wait for opinion before coding it, but that's likely the route I would go.

That makes sense.
What if we just remove connection and request timeout from the builder, and if user wants to configure that for the default client, then they can configure the default client (like any other client) using MoccaDefaultHttpClient. In other words, we should move the connection and request timeout setters from the builder to class MoccaDefaultHttpClient.
What do you think?

By the way, we already do that for other properties in MoccaDefaultHttpClient. So I think that is the way to go.

I'm fine with that.  I will submit a PR before Monday.

Cool, thanks Sam!!


Perform Hyperparameter Tuning on Linear Regression

Objective:

Optimize the Linear Regression model by performing hyperparameter tuning, despite it having fewer hyperparameters compared to other algorithms.

Tasks:

Regularization Techniques:

Incorporate Ridge (L2) and Lasso (L1) regularization into the linear regression model to prevent overfitting.

Hyperparameter Identification:

Identify hyperparameters such as the regularization strength parameter ( \alpha ) in Ridge and Lasso regression.

Implement Grid Search:

Set up a grid of ( \alpha ) values to explore.
Use cross-validation to evaluate model performance for each ( \alpha ).

Analysis:

Plot validation curves to visualize how changes in ( \alpha ) affect model performance.
Select the optimal hyperparameter values based on cross-validation scores.

Documentation:

Explain the impact of regularization on model coefficients and performance.
Provide insights into the bias-variance trade-off observed during tuning.

Explanation:

Hyperparameter tuning, even in models with few hyperparameters like linear regression, can significantly influence model performance. Regularization parameters control the complexity of the model and help in generalizing better to unseen data. This issue encourages exploring the delicate balance between underfitting and overfitting, enhancing the model's predictive capabilities.

I can give it a try! Can you assign it to me?

@IngaleChinmay04 you are assigned with the issue.

@IngaleChinmay04 your pr has been merged. Thanks for participating in hacktoberfest.

Thanks!

@IngaleChinmay04 This repository was part of the open-source event SLOP organised by GDG On Campus DAIICT. So if you want to be part of the event check out https://events.mlh.io/events/11771-slop-4-0. We can consider your pull request for the leaderboard then.

Yes I'm interested

give @IngaleChinmay04 100 points

@IngaleChinmay04 check out the leaderboard here: https://slop.dscdaiict.in/leaderboard

Where can I find more repos for contribute in this?

@IngaleChinmay04 you could improve the documentation of this repository. I could open up the issue.


Add setters for modem and debug serial and default to Serial1 and Serial0

created setModemSerial() and setDebugSerial(), containing the serial port by default as first argument and the new serial port chosen by the user (no default new serial port in the prototype).
those functions overrides the last serial port with the new one. #5

What remains to be added to this PR is defaulting to Serial and Serial1. I guess this should happen in init() where we should:

Remove the arguments now that we have the setters
If this->modemSerial was not set, default to Serial1 and call begin(57600)
If this->debugSerial was not set, default to Serial and call begin(9600)

In the library, we can't reference Serial1, because it's only available on some boards. This has to come from the user sketch, as the library is not aware of the selected board in the Arduino IDE.

@johanstokking but surely we can default?

Serial1 is simply not defined if you have a different board type, e.g. Arduino Uno. So you'll get compilation errors. You can't default to something that's not defined.

Still have to get used to compiled languages :S
In that case, with these two setters we might as well remove init() since all it does is set these 2
PS: is the same true for Serial? Or can we default to that for debug still?


Temporary Workspace Filtering

We've onboarded some FireCloud users who have a lot of workspaces (for example, data delivery users). They are going back to FireCloud because we don't provide more filtering on workspaces.
We want to holistically think through how we're doing search/filter over workspaces. This likely has to wait until Q1. We need a provisional UX solution.
To this end, we need to expose the same filters FireCloud is exposing:

Make an expandable/collapsible panel on the workspace list page exposing these filters. These filters should already have backend support

We don't need "TCGA Access"

@zarsky-broad has an old mock here that gets us 'round the block

https://www.figma.com/file/L72ELhxEjkgfOhcrhD2d1hFz/Table-refresh?node-id=22%3A58

Two filters:

[ ] Access Level (Writer, Reader, Owner, Project Owner), multi-select
[ ] Project (aka namespace), multi-select

Behavior:

[ ] only one filter window can be open at a time
[ ] filter persists when user clicks "Back" button, like card/list view
[ ] search and filter are additive

@lstrano-broad Do you mind weighing in on the styling of these two filters?

This is the current state, how would you like it to look?

Before someone has filtered workspaces:

After filtering workspaces:

I propose that when the dropdown is active, i.e. someone is adding or removing items, that it hovers over the workspaces. When it is inactive then it is collapsed and ends in ...

Agree that it should - looks better, thx!

On Nov 21, 2018, at 2:58 PM, Kate Voss<EMAIL_ADDRESS>wrote:
Before someone has filtered workspaces:
After filtering workspaces:
I propose that when the dropdown is active, i.e. someone is adding or removing items, that it hovers over the workspaces. When it is inactive then it is collapsed and ends in ...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


replaceCustomElements fails with a VirtualText node

vtree.tagName is undefined so calling toUpperCase() fails with:

Uncaught TypeError: Cannot read property 'toUpperCase' of undefined

So check for existence prior to use.
introduced in commit: 6c801af9c880be4744c8d48a1a1b5fe80b3df13d
:beers:

@dobrite v0.8.1 released to fix this.


Error in code sample: UpdateRelationshipAsync

Thank you for adding a code sample re. my previous request.
There is an error in the code sample:
await UpdateRelationshipAsync(client, srcId, $"{srcId}-contains->{targetId}", updatePropertyPatch);
should be:
await client.UpdateRelationshipAsync(srcId, $"{srcId}-contains->{targetId}", updatePropertyPatch);

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: f69ab4ee-a444-27d9-eba6-60e378934ba6
Version Independent ID: 8da3d3e9-98b5-c695-b277-f9373dafcc09
Content: Manage the twin graph with relationships - Azure Digital Twins
Content Source: articles/digital-twins/how-to-manage-graph.md
Service: digital-twins
GitHub Login: @baanders
Microsoft Alias: baanders

@algattik Thank you for catching this. We will investigate and update the thread.

Thanks @algattik for the review.
I think this comment is actually a result of a confusing naming convention in our sample code.
To help contextualize the SDK calls that will typically be part of a larger program (such as the runnable sample later in the document), the SDK call examples are shown inside custom methods with try/catch code and print statements. The line I think you're referring to is calling the custom method created in the sample right above it, which takes in the client as a parameter -- not using the SDK call on the client directly.

To help clarify this difference, I'm going to update the custom method name to something that doesn't match the SDK call name. I'm also going to add more introductory text explaining that this is a contextual example built around the actual client call (and I'll also add a highlight to the client call itself to make it stand out in the example).
Will continue to update this thread as I implement these changes.

Hello @algattik,
I've added CustomMethod_ to the start of all the custom method names, to identify them in these code samples. I've also added more intro text and SDK call highlights in PR #146998.
Hopefully this makes the intent more clear and makes it simpler to see what is happening with the custom methods.
Does this seem to address the issue?

Since fixes to handle this issue have been published and the conversation has slowed down, I'm going to proceed to close the issue at this point. Feel free to comment back in this thread if you have further comments or questions, and we can always reopen if needed.
Thank you!
#please-close


Update the search Articles Icon based on the User's OS and situation

Issue Description:

The icon to the right of the text box displays "Command K" by default, even for users on Windows and Linux operating systems. This leads to confusion among users who are not familiar with macOS keyboard shortcuts.
Additionally, the icon remains as "Command K" while typing, with no indication of what users are supposed to do if their input does not match any article names. Ideally, the icon should dynamically adjust based on the user's operating system and change to something like "Return," "Enter," or a "Search" icon when searching is expected.

Steps to Reproduce:

Go to Anubhav homepage.
Focus on the text box with the "Command K" icon to the right.
Start typing in the text box.
Notice that the "Command K" icon remains unchanged, regardless of the operating system or input provided.

Expected Behavior:

The icon should dynamically adjust based on the user's operating system (e.g., "Ctrl K" for Windows/Linux).
When the user starts typing and no matching articles are found, the icon should change to a relevant action, such as "Return," "Enter," or a "Search" icon, indicating that the user can press Enter or tap on the icon to search.

Steps to Fix:

Detect the user's operating system and update the "Command K" icon accordingly:
macOS: "Command K"
Windows/Linux: "Ctrl K"
While the user is typing, if there is no matching article, update the icon to indicate an actionable behavior such as "Return," "Enter," or a "Search" icon.

Hi @dahighsky, Are you working on this issue ?

PR #51 fixes this issue


How to visualize pred boxes on cam img of Nuscenes dataset?

@tianweiy Thanks for the great work! I'm able to visualize pred boxes on BEV of Nuscenes dataset ,but how to realize it on cam img ? Is there an example ? Thank you in advance

Did you find a solution? I would also be interested in this

Did you find a solution? I would also be interested in this
Try https://github.com/nutonomy/nuscenes-devkit/issues/735


Allow apply_floor_snap to preserve the horizontal position regardless of stop_on_slopes

Removes the stop_on_slopes check from apply_floor_snap, allowing the part of the code that preserves the horizontal position to work independently of the value of stop_on_slopes. This should provide a more consistent behavior and prevent the character from sliding along the horizontal axis as a result of what should be a pure vertical snapping.
Fixes https://github.com/godotengine/godot-proposals/issues/9255
It would be technically more correct to set p_cancel_sliding on the parameters too, but it seemed like something for another PR.
EDIT:
@a0kami has made a test scene to make sure it is working as intended.
Pre-PR:  The non stop on slopes has non vertical motion on the snapping, more noticeable incrementing safe margin a bit. You can notice how snapping those bodies cause a wrong horizontal motion. Note how the bodies still snap even if the safe margin is large enough to touch the platform, contrary to the stop on slopes bodies that will not try to snap the body if the distance to the floor is less than the safe margin.
https://github.com/user-attachments/assets/56ba44c1-e935-4e19-b9cc-2a03fd53f9b5
After-pr: The snapping is now consistent between both types of bodies, the non stop on slopes bodies now snap correctly along the snapping vector, and the safe margin is being respected too.
https://github.com/user-attachments/assets/23d39036-516c-4846-946b-a2b0554eb736
As you can see the different is quite noticeable and we are gaining a lot of precision.
TEST PROJECT BY @a0kami:
test.tar.gz

PR updated with videos of pre and post PR and a test project.

Thank you! I'll probably have some time tonight or tomorrow!
To be clear, as is my first PR in Godot:

Should i change the comment in the 3D node to match your new one on the 2D node? for coherence, also yours is clearer.

I should add a code comment explaining why we can safely cancel the motion, as you explained.

Are those all the changes needed or do i need to tackle something else?
Thank you again for your time!

Should i change the comment in the 3D node to match your new one on the 2D node?

Yes.

I should add a code comment explaining why we can safely cancel the motion, as you explained.

Yes.

Are those all the changes needed or do i need to tackle something else?

 Then please squash the commits. After that I think we can merge it.

Done! Hope i didn't messed up with squashing, kind of confusing, but i think everything is okay.

Awesome! Thank you a lot for the assistance!

Thanks! Congratulations on your first merged contribution! 🎉


10x bamtofastq with EMA BAM

Hi,
A side feature request popped up while exploring the hg38 alignments peculiarities.
I tired to use this tool to convert a portion of EMA BAM file back to barcoded FASTQ: https://support.10xgenomics.com/docs/bamtofastq But the tool reported it as "Unrecognized 10x BAM file.". I guess it's likely that the tool is too tied to Lariat specificities. But it would be fantastic if EMA BAMs were compatible with this tool. Not sure if it's feasible without the modifications of the tool.
Or maybe there are alternatives that you could suggest?
Vlad

I use samtools fastq -TBX to convert a BAM file with BX:Z tags to FASTQ with BX:Z tags.

Thanks Shaun, that should work I guess since EMA started to support BX:Z-tagged FASTQs

No worries, Vlad. Happy to help.


Move all environment files into a separate folder to tidy up the repository.

I don't think this is necessary, Tiffany's own example doesn't have them organized in another folder.
Tiffany's Repo: https://github.com/ttimbers/breast-cancer-predictor


Add e2e test for sidenav

Closing this as we need to write e2e tests for all the components, which we can track outside of issues.


Kafka Group Support

I'm using dnstap to capture requests from multiple dns servers then forward it to my kafka , the only issue is I can't specify which kafka group to send to , only topics , which is not enough for my use case , it would be great if you can implement it as an optional feature in the kafkaproducer, since you are already using kafka-go library , i think it would be easy for you. appreciate your support.

I’m not sure I fully understand your request. As far as I know, groups are a concept primarily used on the consumer side in Kafka. Could you clarify what you mean by adding group support for the producer?

Thank you for your response , It's true i managed to set it up in from the consumer side.


What to do next with our blazing fast sparse implementation?

We now have blazing fast initialization and training of a spectral model, which gives us a ripe environment for innovation: we can do lots of experiments and improvements for relatively cheap.  There are a few steps forward worth thinking about.
More accurate: Line wings
We covered this in #9 and #10, and it should definitely be done.
More accurate: True Voigt instead of pseudo-Voigt
Since we're so fast now we can afford to spend more on the previously too-expensive Voigt computation.  We can use the Voigt-Hjerting function, which we have already previously implemented.  It appears to add ~27x the computation time, but should be feasible.
Parameter studies: accuracy scaling with P_rom
We could make a plot of residual sigma versus Prominence.  At what point do we hit a noise floor from the inaccuracies of our model?
Parameter studies: Clustering of erroneous line widths
A plot of Amplitude versus gamma width reveals a bunch of impossibly wide lines that are overfitting continuum imperfections
Application to data
The model accuracy is probably "good enough" to apply to data.  Yay!  Let's do that, since we'll learn a bunch of new things along the way.  We need to implement vsini, etc.
Continuum flexibility: Polynomial fitting
We could simultaneously fit the continuum polynomial.  We currently have this turned off.
Continuum flexibility: Gaussian Process
A GP seems like the right way to specify the continuum, but it has a scaling problem.  We could investigate scaling with GPyTorch, or celerite-for-pytorch?

these themes are all discussed in the paper.  while there's a difference of discussing them versus actually carrying them out, I think it's fine to close this issue and then open new standalone issues for any specific feature we wish to build.


Hostname Issue - Unresolved

          I'm having the same issue.

[2024-07-05T05:11:11Z INFO  govee::commands::serve] Starting service. version 2024.06.18-dc01fbc7
[2024-07-05T05:11:11Z INFO  govee::commands::serve] Starting LAN discovery
[2024-07-05T05:11:11Z INFO  govee::commands::serve] Waiting 10 seconds for LAN API discovery
[2024-07-05T05:11:21Z INFO  govee::commands::serve] Devices returned from Govee's APIs
Error: Please specify the mqtt broker either via the --mqtt-host parameter or by setting $GOVEE_MQTT_HOST
Stack backtrace:
   0: std::backtrace::Backtrace::create
   1: anyhow::error::<impl anyhow::Error>::msg
   2: govee::service::hass::HassArguments::mqtt_host
   3: govee::commands::serve::ServeCommand::run::{{closure}}
   4: govee::Args::run::{{closure}}
   5: tokio::runtime::park::CachedParkThread::block_on
   6: tokio::runtime::context::runtime::enter_runtime
   7: tokio::runtime::runtime::Runtime::block_on
   8: govee::main
   9: std::sys_common::backtrace::__rust_begin_short_backtrace
  10: std::rt::lang_start::{{closure}}
  11: std::rt::lang_start_internal
  12: main

I am using
GOVEE_MQTT_HOST=<IP_ADDRESS>
MQTT_BROKER=<IP_ADDRESS>

Log from mqtt shows:
1720154349: mosquitto version 2.0.18 starting
1720154349: Config loaded from /mosquitto/config/mosquitto.conf.
1720154349: Opening ipv4 listen socket on port 1883.
1720154349: Opening ipv6 listen socket on port 1883.
1720154349: Opening websockets listen socket on port 9001.
1720154349: mosquitto version 2.0.18 running
1720154383: New connection from <IP_ADDRESS>:38164 on port 1883.
1720154383: Client auto-9E86C469-4F09-4ABC-73FE-D6C67C1B6B04 disconnected, not authorised.
1720154387: New connection from <IP_ADDRESS>:52334 on port 1883.
1720154387: Client auto-28926D98-795E-37B8-3B1A-DE22E3468355 disconnected, not authorised.
1720154404: New connection from <IP_ADDRESS>:44408 on port 1883.
1720154404: New client connected from <IP_ADDRESS>:44408 as auto-B56393B7-A16C-02CC-1D16-133E160CEC9D (p2, c1, k60, u'cmdshft').
1720154440: Client auto-B56393B7-A16C-02CC-1D16-133E160CEC9D disconnected.
1720154449: New connection from <IP_ADDRESS>:60312 on port 1883.
1720154449: New client connected from <IP_ADDRESS>:60312 as auto-5C1ABB3B-A85C-8D23-A6A1-8E5D348BBF6D (p2, c1, k60, u'cmdshft').
1720154449: Client auto-5C1ABB3B-A85C-8D23-A6A1-8E5D348BBF6D disconnected.
1720154507: New connection from <IP_ADDRESS>:45789 on port 1883.
1720154507: New client connected from <IP_ADDRESS>:45789 as 3Ca219FYluVntBcPtOkhNT (p2, c1, k60, u'cmdshft').
1720154507: Client 3Ca219FYluVntBcPtOkhNT disconnected.
1720154507: New connection from <IP_ADDRESS>:58695 on port 1883.
1720154507: New client connected from <IP_ADDRESS>:58695 as 79gltOgDbn5YKaxR7mnlRq (p2, c1, k60, u'cmdshft').
1720154602: New connection from <IP_ADDRESS>:54077 on port 1883.
1720154602: New client connected from <IP_ADDRESS>:54077 as 5ZRLvDMOtgo142TQ8XhRMO (p5, c1, k60, u'cmdshft').
1720154602: Client 5ZRLvDMOtgo142TQ8XhRMO disconnected.
1720154784: Client 79gltOgDbn5YKaxR7mnlRq disconnected.
1720154784: New connection from <IP_ADDRESS>:57897 on port 1883.
1720154784: New client connected from <IP_ADDRESS>:57897 as 7G7bucucATKXmVOQWNAGVR (p5, c1, k60, u'cmdshft').
1720155199: Client 7G7bucucATKXmVOQWNAGVR disconnected.
1720155199: New connection from <IP_ADDRESS>:36257 on port 1883.
1720155199: New client connected from <IP_ADDRESS>:36257 as 2wUlb8cKUr8isS6FTSDiPT (p5, c1, k60, u'cmdshft').
1720155489: Client 2wUlb8cKUr8isS6FTSDiPT disconnected.
1720155489: New connection from <IP_ADDRESS>:44317 on port 1883.
1720155489: New client connected from <IP_ADDRESS>:44317 as 53HVvguZ8oIzInhBkCciX6 (p5, c1, k60, u'cmdshft').
1720156150: Saving in-memory database to /mosquitto/data//mosquitto.db.

Originally posted by @cmdshft in https://github.com/wez/govee2mqtt/issues/217#issuecomment-2210195024

Sounds like you need to configure the docker compose file differently, see the example:
https://github.com/wez/govee2mqtt/blob/main/docker-compose.yml#L7-L8
and note the stack.env comment from the top of the screen shot you shared.


Set private token as header and not as query parameter

Awesome work!
https://github.com/p0fi/gitlab-stats-for-scribtable/blob/42b873b6c279c1a2de292bfff03953d92813e1ae/gitlab-stats.js#L231-L251
Setting the private token as query parameter is discouraged and it should be rather set as a header, which this framework seems to support: https://docs.scriptable.app/request/#headers / https://docs.gitlab.com/ee/api/#personalproject-access-tokens
See also https://tools.ietf.org/html/rfc6750#section-5.3

Don't pass bearer tokens in page URLs:  Bearer tokens SHOULD NOT be
passed in page URLs (for example, as query string parameters).
Instead, bearer tokens SHOULD be passed in HTTP message headers or
message bodies for which confidentiality measures are taken.
Browsers, web servers, and other software may not adequately
secure URLs in the browser history, web server logs, and other
data structures.  If bearer tokens are passed in page URLs,
attackers might be able to steal them from the history data, logs,
or other unsecured locations.

Thanks for the quick fix, @p0fi!


Transformers - Add sqlfluff workflow

Add sqlfluff linting workflow (only for new changes using diff-quality).

Is there any benefit to doing a one-time lint on the existing files? Did you test this? The workflow looks good but I'm wondering how many changes this would make.

Is there any benefit to doing a one-time lint on the existing files? Did you test this? The workflow looks good but I'm wondering how many changes this would make.

Linting everything at once is possible (and there are good reasons for both doing it and not) with sqlfluff fix, but if we want to do it maybe it should be in a separate PR (I've had some troubles with fixing lint errors in the past on dbt projects). This workflow only adds a lint test (won't lint things automatically) for new and/or modified lines, not existing ones.


Is there a way to drop or close an actual connection when I'm using PooldConnection?

Because when I work with the connection of PooldConnection got by Pool.get and face some error that a protocol of the connection became bad state, I'd liket to close the actual connection.
I don't want to use test_on_checkout because it's high impact for performance.

I had similar issue, I hacked it like this:
implement has_broken with boolean holder
fn has_broken(&self, conn: &mut MyConnection) -> bool {
    if self.release_on_return_to_pool.get() {
            return true;
    }
...

pub struct MyConnection {
...
    /// Indicates that we want to release this connection on return to pool (used for gracefull shutdown)
    release_on_return_to_pool: Cell<bool>,
...

impl ProtocolRunnerConnection {
...
    /// Mark connection as "destroy" when return back to pool
    pub fn set_release_on_return_to_pool(&self) {
        self.release_on_return_to_pool.set(true);
    }
...
}

so when I have aquired connection and some error occures, I can decide, if to return connection to pool or to destroy it by calling set_release_on_return_to_pool

@sfackler
if this solution is ok, I could maybe do pull request to your library,
btw. r2d2 is very cool and works perfectly for me

This seems like quite the hack. Is there really no way of closing or returning a connection to the pool explicitly?
I'd expect something like
connection.close() for example— or pool.reclaim(connection)

FWIW I found one source that says connections are returned to the pool as soon as they go out of scope


chore(package) drop support of node v6

Summary
This PR drops the support of node v6 as we are going to use resources from commercetools monorepo which does not support v6 anymore.

Hi @butenkor .. please check this PR and let us know if it is ok for PS team if we roll this out as a breaking change.

If it is a breaking change maybe it makes sense to increase major version or the release?


add DataFrame.from_rows/2

WIP. ~Last hurdle is figuring out how to coerce atom keys to string keys without iterating over the whole list of rows Elixir-side. @philss any ideas?~ Figured it out! I'm able to pass a term and then match on the TermType. A bit convoluted, but it works!
I also think the ExAnyValue approach may permit us to have a single s_from_list without the macro implementation. And I think remove the iteration over the full list Elixir-side. @jonatanklosko @josevalim I believe that came up during our call.
Closes #59.
cc @kimjoaoun

@cigrainger does it mean we can have any value as a column now and they get the type term/any or something like that?!

@josevalim it means we can pretty arbitrarily support any value that Polars supports without checking/coercing on the Elixir side. The enum with its supported type variants is here.


Cluster deployment

Description

Motivation and Context

How Has This Been Tested?

[ ] Covered by existing integration testing
[ ] Added integration testing to cover
[x] Tested locally
[ ] Have not tested

Types of changes

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

Checklist:

[ ] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.

A new way to deploy a k8s cluster, composed by a master and a worker VM, without using vagrant. Then, NSM will be deployed on that cluster.

So in general, K8s cluster deployment is not NSM's core task here. There are better projects like https://kubespray.io/ that do that. We only needed these deployment scripts to init our development Vagrant environment and our CI/CD pipeline.
Essentially one can deploy the K8s cluster with whatever tools they see fit and the just:
export CLUSTER_RULES_PREFIX=null
make k8s-infra-deploy

This will download the images off the official docker hub and deploy to where kubectl is pointing. Of course, this method does not allow you to do local development and then deploy your images to that random cluster, but that is why we have Vagrant.
@edwarnicke can you please share your opinion here? Maybe we need a separate doc about external clusters explaining the above.

@BoutheinaDab I have a question... you have these scripts for configuring VMs once they are running to form a K8s cluster, but I don't see any hooks for starting VMs.  Thinking a bit about this we currently have two levels:

I don't have a K8s cluster, and want a way to stand that up soup to nuts.  Vagrant is an example of this.  packet.mk was trying to be another
I have a K8s cluster, the 'null' case handles this

It feels to me like you have an intermediate stage here where you have the VMs... you just need them setup as a proper K8s cluster.  Is that correct?  Out of curiosity, how are you getting your VMs?  I understand why Vagrant is a bad fit for you... I'm curious what you are using :)

@BoutheinaDab I have a question... you have these scripts for configuring VMs once they are running to form a K8s cluster, but I don't see any hooks for starting VMs. Thinking a bit about this we currently have two levels:

I don't have a K8s cluster, and want a way to stand that up soup to nuts.  Vagrant is an example of this.  packet.mk was trying to be another
I have a K8s cluster, the 'null' case handles this

@edwarnicke Thank you for feedback. Indeed, yes. I am in the first case, I don't have k8s cluster. I have two ubuntu VMs that I want to use to deploy a k8s cluster. Using Vagrant was not possible, because I was deploying NSM on a ubuntu VM, where the nested virtualization is not enabled.

It feels to me like you have an intermediate stage here where you have the VMs... you just need them setup as a proper K8s cluster. Is that correct? Out of curiosity, how are you getting your VMs? I understand why Vagrant is a bad fit for you... I'm curious what you are using :)
Right. I skipped the intermediate stage of starting the VMs. Indeed, the VMs are already created and started, and I just use them to setup a proper k8s cluster. It is correct!
Regarding the VMs, I am using two VMware VMs (ubuntu 16.04).

@BoutheinaDab OK... so question... why not use the existing scripts in scripts/vagrant/scripts ... those aren't specific to Vagrant really... they just install K8s on two VMs... however they have been stood up.

Well, I did not want to block the PR. I still think we do not need this. At least not in the proposed format. We already support Vagrant on VMware Workstation, VBox and KVM. We have recently added support for Kind as a cluster provider. We do support Helm Charts now. I think we have enough tools to cover development and basic deployment tasks.
I'll let @edwarnicke and @fkautz have the final say.
Please note that the PR has failing checks and conflicts, which renders it unmergeable as it is.


data-toggle collapse with data-target selector not using an #id does not update the control's  aria-expanded attribute

When using a data-toggle='collapse' and data-target selector is not an element id selector, the aria-expanded attribute in the control is not updated. However the collapse toggle function works.
Testcase:
https://jsfiddle.net/jcwchriswalker/c07nv4hs/

Both  control a separate div container. The only difference in the buttons is how the data-target is defined. The 'By ID' button uses a '#collpsediv1' reference and the 'by ClassName' button uses a class selector .collapse.div2 to reference the target
Both buttons successfully collapse/uncollapse the target.
The  By ID will correctly set the aria-expanded attribute based on the state of the data-target
The  By classname, does not update its aria-expanded attribute based on the state of the data-target.
In both cases, the data-target  correctly sets it aria-expanded attribute

I think it should be fixed by this PR #21654

I think it's solved by #21692. The main purpose of the PR is to support multi-targets, but it fix this issue because it rely on a different method to determine the trigger of a given collapse area.
Currently the methods rely on id only.

Thanks Pierre- I will be able to try this next week…
From: Pierre Vanduynslager<EMAIL_ADDRESS>Sent: Wednesday, January 25, 2017 4:14 PM
To: twbs/bootstrap<EMAIL_ADDRESS>Cc: Chris Walker<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [twbs/bootstrap] data-toggle collapse with data-target selector not using an #id does not update the control's aria-expanded attribute (#21845)
I think it's solved by #21692https://github.com/twbs/bootstrap/pull/21692. The main purpose of the PR is to support multi-targets, but it fix this issue because it rely on a different method to determine the trigger of a given collapse area.
Currently the methods rely on id only.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/twbs/bootstrap/issues/21845#issuecomment-275234127, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVXC9OcCnInffoySv0mLKgOqzj8rEc_Pks5rV7r9gaJpZM4Lt_Q4.

This is not fixed. Updated fiddle with 4.3.1 https://jsfiddle.net/3xburgo9/1/
Clicking "By classname" sets aria-axpanded=true, but clicking it again will not set it to aria-expanded=false. Works with the "By ID" button.

I'm seeing a similar issue but instead it seems ALL controls are updated when pressing one of them. Adding an id attribute to the rows fixes the issue: https://jsfiddle.net/auro02ph/

https://jsfiddle.net/jcwchriswalker/c07nv4hs/ works as expected for me, aria-expanded is toggled in both situations.
@kaptajnen Can you open a new issue for that example? It seems that sharing the classes might be causing that problem... https://jsfiddle.net/9oubjkg1/ has the latest v4.x version in it.
Know I'm a year late here, sorry 😬

https://jsfiddle.net/jcwchriswalker/c07nv4hs/ works as expected for me, aria-expanded is toggled in both situations.
@kaptajnen Can you open a new issue for that example? It seems that sharing the classes might be causing that problem... https://jsfiddle.net/9oubjkg1/ has the latest v4.x version in it.
Know I'm a year late here, sorry 😬

I'm not sure about this one, but I can confirm @kaptajnen observation.
The original issue does seem to work here too, though.

I'm not sure about this one, but I can confirm @kaptajnen observation.
The original issue does seem to work here too, though.

Closing out as stale.


Optimus doesn't select the nvidia chip

Optimus systems need to export NvOptimusEnablement somehow, but it has to come from the exe not a dll, and since renderdocui.exe is a C# program that's difficult.
Need to see if there's an alternative here.

There should now be an optimus profile provided that matches RenderDoc's executables. If you still find it selecting the wrong device then please open a new issue.


Made executors configurable.

Making executors configurable to be consistent through out leshan.
Signed-off-by: Michael Kremser<EMAIL_ADDRESS>

@MKremserBosch could you please resolve the conflicts here.

@sbernard31 could you please merge this PR into the master before the planned release.

I can imagine how you can use your own ScheduledExecutorService for InMemmoryRegistrationStore using LeshanBuilder, but how do you use the new CaliforniumLwM2mRequestSender constructor ?

@sbernard31 we use the second constructor to use our own executor (for tenant logging) - to be downward compatible we have the first constructor.

I meant how could you create your LeshanServer with this custom CaliforniumLwM2mRequestSender ?

@sbernard31 we build our own LeshanServer with a proper Builder using a setter for the lwM2mRequestSender.

Ok. Did you modified the LeshanServer a lot ? or just to be able to have a custom LwM2MRequestSender ? Could you show us your LeshanServer version. I would like to see if it makes sense to modify the code to avoid you to duplicate LeshanServer and LeshandBuilder.

@sbernard31 our builder sets the following members:
private ClientRegistry clientRegistry;
private ObservationRegistry observationRegistry;
private LwM2mRequestSender requestSender;
private Lwm2mClientRegistryListener lwm2mClientRegistryListener;
private CoapServer coapServer;

Ok I can see why you need a custom ~ClientRegistry and ObservationRegistry~ RegistrationStore.
For the ~Lwm2mClientRegistryListener~ RegistrationListener, why not using :
lwServer.getRegistrationService().addListener(listener);

About coapServer, You can just get it and modify it after the LeshanServer creation :
LeshanServer lwServer = builder.build();
lwServer.getCoapServer().add(new MyResource());
lwServer.start();

@MKremserBosch  I hope I didn't annoy you too much with my questions, I just want to understand your use case and see if we can limit code duplication.

@sbernard31 No Problem

Ok but you didn't really answer to my questions :p so I'm not sure what is the better thing to do...
I will probably integrate your PR if that can help at short term .

The RegistrationStore part is integrated in master (commit 5aaef6a5cb2a6885f7c1f6c2aca1c4bd9040853d) the Sender part is no more needed since #256.


Multiline docstrings are not handled well - do not propagate to documentation

e.g. this:
https://github.com/ModECI/modelspec/blob/0cdcac0f2bd4f139846c6b5ab18518d945ee4cef/examples/document.py#L22-L26
is only the last line in generated docs:
https://github.com/ModECI/modelspec/blob/0cdcac0f2bd4f139846c6b5ab18518d945ee4cef/examples/document.specification.json#L26
Required for proper documentation of MDF...

Something for @parikshit14 to look into.

Hey @parikshit14,
Can you check if it parses the first line into the short_description attribute without modifying the docstring? If so, then I would just concatenate the short and long description if they are both present. I would rather not change the docstring formatting if possible since it is a standard.

Fixed by #14


RefCounted implementation for classes

add a simple RefCounted variant for classes
varies quite a lot from the RefCounted for structs
because certain semantics aren't possible with classes
also remove the autoInit stuff and use a function+@disable
this() to guarantee that the payload is initialized

This still needs a bit polishing (docs et.al.), but I wanted to discuss a few things upfront.
The implementation for classes varies quite a lot from the existing RefCounted (which is also a PITA due to the autoInit stuff), but as things like autoInit and opAssign aren't implementable for classes and most of the other functions differ, I just made a second RefCounted.

Could you add an @nogc unit test(AFAICT this can infer @nogc, right?)

I agree this doesn't need the lazy initialization stuff, but instead of making it non-nullable, why not make it work just like any class reference T and be null by default? It should make it easier to use, usable in generic code that needs default-initialization, and the user should be able to make it non-null by composing it with a NotNull type.
It shouldn't be hard to implement; just cast _store instead of _store.payload (although either would probably work even when _store is null) and then add the proper overloads for typeof(null).

Added the @nogc test, adjusted the methods of the old RefCounted, and enabled ref escape checking for that.

why not make it work just like any class reference T and be null by default

Because it's a class value, not a class reference, i.e. you can't nullify scoped!Class either.
Granted it's possible to special case null, but being able to do rc = null; seems weird when you can't do rc = cinst;.
TODO:

[ ] implement polymorphic RefCounted conversions

In fact using payload and refCount might hide members of the payload, will change that back to the old scheme of wrapping everything in refCountedStore.

Because it's a class value, not a class reference, i.e. you can't nullify scoped!Class either.

RefCounted!T is a reference by any account I can think of. It is implemented in terms of a single pointer, and copying it makes an alias, not a copy of the payload. Ref is right there in the name.

Granted it's possible to special case null, but being able to do rc = null; seems weird when you can't do rc = cinst;.

You can if cinst is also a RefCounted.

How would you initialize a null RefCounted!T?

Analogous to T:
// These are equivalent
RefCounted!T c;
RefCounted!T c2 = null;

Mmh, I guess we could add a null state for RefCounted.
Default construction has problems with a nullary class constructors though.
auto c = RefCounted!C(); // this is null
auto c2 = refCounted!C(); // this is not

Ouch. std::shared_ptr gets around this by delegating the onus of construction to the user, but this is not an option for us.

This difference might be OK though, because one is clearly a function call while the other is a struct literal.

Changed the implementation to account for the discussed changes.
There is still quite some stuff left to be done (see TODOs), most importantly attribute inference doesn't work correctly.
I'd highly appreciate any help in getting this done, e.g. improving the documentation and examples or implementing nullable for Unique.

Left to be done.

[ ] implement proper destruction
[ ] polish documentation

I am terribly sorry I didn't chime in sooner - I was on vacation the past two weeks.
A lot of what @JakobOvrum has said above really resonates with my. Frankly, if we're going to overhaul Unique with this upcoming release, RefCounted should get a similar makeover. The two go hand in hand. As we all discussed in the Unique PR, now is not the time for half-measures and just putting a coat of polish on the old versions. Now is the a good time to rip them up and Do It Right™. RefCounted should:

Have much in common with the new Unique, including

get() functions
an empty property and opCast(T:bool) indicating whether the underlying pointer is null
alias get this
A single refCounted function which takes the constructor arguments for the underlying type and returns a RefCounted

Get rid of all the lazy initialization stuff such as autoInit and ensureInitialized. This is a can of worms a smart pointer type shouldn't open.

Get rid of refCountedStore(). The user shouldn't concern themselves with the underlying storage. That's an  implementation detail the user should have no need to know, provided we provide correct reference counting semantics.

In short, its API should be nearly identical to that of Unique (possibly with the addition of a refCount property) , just like shared_ptr has so much in common with unique_ptr.
Again, I'm sorry for all the legwork you've already done, Martin - I'll help in any way I can now that I'm back, including taking up these changes in my own PR.

A lot of what @JakobOvrum has said above really resonates with my. Frankly, if we're going to overhaul Unique with this upcoming release, RefCounted should get a similar makeover. The two go hand in hand. As we all discussed in the Unique PR, now is not the time for half-measures. Now is a good time to rip them up and Do It Right™. RefCounted should:

Not quite, RefCounted is widely used, so we cannot make radical changes.

get() functions
an empty property and opCast(T:bool) indicating whether the underlying pointer is null
alias get this

The implicit bool conversion is there, but get and empty could hide functions of the underlying type making things like a RefCounted range impossible. We should probably revise Unique to account for this.

A single refCounted function which takes the constructor arguments for the underlying type and returns a RefCounted

Will extend refCounted it to non-class types.

Get rid of all the lazy initialization stuff such as autoInit and ensureInitialized(). This is a can of worms a smart pointer type shouldn't open.

I agree, we'll have to see how to deprecate it properly.

Get rid of the refCountedStore() function. The user shouldn't concern themselves with the underlying storage. That's an implementation detail the user should have no need to know, provided we provide correct reference counting semantics.

I did that before, named it payload, but the purpose of refCountedStore is to namespace functions of RefCounted. Might make sense to drop this, b/c most RefCounted methods are unambiguous.

In short, its API should be nearly identical to that of Unique (possibly with the addition of a refCount property) , just like shared_ptr has so much in common with unique_ptr.

Right, let's see how far we can get.

Again, I'm sorry for all the legwork you've already done, Martin - I'll help in any way I can now that I'm back, including taking up these changes in my own PR.

You can make PRs that target my branch to collaborate on this.

The implicit bool conversion is there, but get and empty could hide functions of the underlying type

I think get and refCount should be fine, empty isn't needed as opCast(T:bool)() can be used instead.

Ah, I didn't realize that RefCounted was more widely used, so perhaps we need to move a bit more slowly. I also forgot Github lets you target PRs at arbitrary branches. I'll get poking around. Thanks again for the help.

I added support for any type in refCounted.

Ah, I didn't realize that RefCounted was more widely used, so perhaps we need to move a bit more slowly. I also forgot Github lets you target PRs at arbitrary branches. I'll get poking around. Thanks again for the help.

Meanwhile I'll work on the destruction problem.

The implicit bool conversion is there, but get and empty could hide functions of the underlying type making things like a RefCounted range impossible. We should probably revise Unique to account for this.

I have proposed to remove Unique.empty in #3225.

I'll hit the ground with this once after we settle on what API we want in #3225.

Meanwhile I'll work on the destruction problem.

Done, https://github.com/D-Programming-Language/dmd/pull/4650.

ping, what's the status of this?

I believe we're waiting for #3225 to shake out before deciding what to do here.

TODO:

[ ] Use isNull and nullify API
[ ] use __xdtor to recursively destruct classes

Closing in favor of a complete PR of all smart refs (WIP https://github.com/MartinNowak/phobos/tree/smartRefs).


Organize the team drive

[ ] Create shared drive guidelines

[ ] Get feedback on shared drive guidelines

[x] Move documents from old ADC drive to new ADC drive

[x] Share with the right people

Thomas is working on this:
Hi Erin, moving folders through the web interface is not possible (it was just a fluke that somehow worked for two folders), so I have been playing around with rclone on and off for the last week, mostly waiting for copies to finish.
It is just in the middle of doing another backup which has been running for the last 5 1/2 hours and is maybe only halfway done.
After that I will have to find all duplicates and rename or delete them on the original side and make sure original and backup are as identical as possible.
The next two are currently unsolved challenges I have to talk to Matt and Nick about. How to lock the files or find a time when nobody is accessing them and do another, hopefully quick, sync. Locking is likely, generally, not possible for files owned by someone else.
Deleting the originals

Update from Thomas:
Sorry, I put the migration to the side for a while as it does not seem possible to take ownership of somebody else’s files just for a specific folder which means there is no clean way to address 3. from above. I know we have to do it anyway. I will bring it up next week (Matt’s time is, of course, extra tight this month because of his jury duty).

Topic of discussion on July 10 Arctica call.

Update from Thomas:

'morning Erin, so we discussed this in our last meeting and Matt does not want us transferring files/folders half automated / half manually. He wants us to find a fully automated solution, so that we can apply it to all the WG directories that are currently being shared the same way as ADC. He mentioned that Dave Vieglais has a script to regularly sync D1 folders in two Google accounts. I am on vacation myself but will ask Dave about it when I am back in a couple of weeks. However, I am pretty sure that will not help us, as I understand it so far we cannot just move files or transfer ownership from accounts outside the NCEAS domain. Anyway, I will have to learn Python in order to understand Dave's script and then we all have to agree wether what we want do is possible and if not, if some type of automated copy will be enough. So, unfortunately, it will still be a while before we will move anything to a shared drive.

Will bring this up again in October!

Still needs to be done, @nhchavez -- did you accidentally close this? It's kind of critical for our backups, but as Thomas outlined, there are issues in doing the transfer well and completely. Happy to discuss alternate approaches.

I closed it because it seemed like there hadn't been any movement on since August 2020 and I was trying to clean things up. I can reopen it, and some more context on this issue would be helpful


Command to run on termux non rooted

Root should not be required, can you provide any extra info on your issue?

Can you provide a little more info on your issue? It's likely to be ARM based so it probably doesn't work with the releases since these are compiled for AMD64 but it's relatively simple to open it up in Visual Studio and compile an ARM-compatible version.


Use https on jshint.com

jshint.com should be switched to use https:// instead of http://

We maintain a separate repository for the JSHint website, and this feature has already been requested there: https://github.com/jshint/jshint.github.io/issues/38
https://github.com/jshint/jshint/issues/3329


Problem json serialize with nullability in kotlin

When use @Type json in MySql database with kotlin data class entity
throw nullpointer exception from objectmapper that some field can not be not null but any object i created is not null.
and after i use hibernate converter, everything worked.

The library is only tested with Java. There's no guarantee that it will work in any other JVM language. It could work though.


az acr run --platform windows: Access is denied during Dockerfile RUN creating C:\hello.txt file

Describe the bug
I'm running az acr run --registry mycr --platform windows --file .\HelloWorld.yaml . to build an images based on mcr.microsoft.com/windows/nanoserver:20H2 where my Dockerfile creates simple text file:
RUN echo *** Hello from image nanoserver:20H2 *** > C:\\hello.txt

and that RUN directive fails with a strange Access is denied error.
To Reproduce
1. HellowWorld.yaml
version: v1.1.0
steps:
  - id: build-hello-world
    build: --platform windows --tag {{.Run.Registry}}/hello-world:nanoserver-20H2 --file HelloWorld.dockerfile .
    when: ["-"]
  - id: test-hello-world
    cmd: |
      {{.Run.Registry}}/hello-world:nanoserver-20H2
    when: ["build-hello-world"]
  - id: push-hello-world
    push: ["{{.Run.Registry}}/hello-world:nanoserver-20H2"]
    when: ["test-hello-world"]

2. HelloWorld.dockerfile
FROM mcr.microsoft.com/windows/nanoserver:20H2
RUN echo *** Hello from image nanoserver:20H2 *** > C:\\hello.txt
CMD type C:\\hello.txt

3. Run az acr run
>  az acr run --registry mycr --platform windows --file .\HelloWorld.yaml .
Packing source code into tar to upload...
Uploading archived source code from 'C:\Users\mateuszl\AppData\Local\Temp\cli_source_archive_9aaa517afab748e482906c87f60f09c1.tar.gz'...
Sending context (1.829 KiB) to registry: mycr...
Queued a run with ID: db3b
Waiting for an agent...
2022/08/08 15:23:22 Downloading source code...
2022/08/08 15:23:31 Finished downloading source code
2022/08/08 15:23:33 Alias support enabled for version >= 1.1.0, please see https://aka.ms/acr/tasks/task-aliases for more information.
2022/08/08 15:23:33 Creating Docker network: acb_default_network, driver: 'nat'
2022/08/08 15:23:35 Successfully set up Docker network: acb_default_network
2022/08/08 15:23:35 Setting up Docker configuration...
2022/08/08 15:23:46 Successfully set up Docker configuration
2022/08/08 15:23:46 Logging in to registry: mycr.azurecr.io
2022/08/08 15:23:50 Successfully logged into mycr.azurecr.io
2022/08/08 15:23:50 Executing step ID: build-hello-world. Timeout(sec): 600, Working directory: '', Network: 'acb_default_network'
2022/08/08 15:23:50 Scanning for dependencies...
2022/08/08 15:23:54 Successfully scanned dependencies
2022/08/08 15:23:54 Launching container with name: build-hello-world
Sending build context to Docker daemon  11.26kB
Step 1/3 : FROM mcr.microsoft.com/windows/nanoserver:20H2
20H2: Pulling from windows/nanoserver
3c0e1d52fbf7: Pulling fs layer
3c0e1d52fbf7: Verifying Checksum
3c0e1d52fbf7: Download complete
3c0e1d52fbf7: Pull complete
Digest: sha256:3b9dae8c0c58f2c34a1276b1f7b24b3622032018da49af183a1c5d2135e4fc1a
Status: Downloaded newer image for mcr.microsoft.com/windows/nanoserver:20H2
 ---> bdd8e05157e7
Step 2/3 : RUN echo *** Hello from image nanoserver:20H2 *** > C:\\hello.txt
 ---> Running in 149832fb154a
Access is denied.
The command 'cmd /S /C echo *** Hello from image nanoserver:20H2 *** > C:\\hello.txt' returned a non-zero code: 1
2022/08/08 15:24:32 Container failed during run: build-hello-world. No retries remaining.
failed to run step ID: build-hello-world: exit status 1

Run ID: db3b failed after 1m13s. Error: failed during run, err: exit status 1
Run failed

Expected behavior
The ACR Tasks should build the image with success, as the docker build does locally:

Any relevant environment information
>  az version
{
  "azure-cli": "2.39.0",
  "azure-cli-core": "2.39.0",
  "azure-cli-telemetry": "1.0.6",
  "extensions": {
    "account": "0.2.3"
  }
}

>  $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.2.5
PSEdition                      Core
GitCommitId                    7.2.5
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

UPDATE:
Changing the Dockerfile from
RUN echo *** Hello from image nanoserver:20H2 *** > C:\\hello.txt
CMD type C:\\hello.txt

to
RUN mkdir C:\\Temp && echo *** Hello from Cadcorp custom image based on %BASE_IMAGE%:%BASE_IMAGE_TAG% *** > C:\\Temp\\hello.txt
CMD type C:\\Temp\\hello.txt

seems to help avoid the "Access is denied" error.
Still, it's unclear why the local build allows to create files in the root folder i.e. C:\hello.txt

It's azure-cli issue. Please reopen it in https://github.com/Azure/azure-cli/issues. Thanks.


Xanmod: Ashmem not found

Describe the bug
The xanmod website says that Ashmem is included by default, but it doesn't seem to be the case.
Steps To Reproduce
Steps to reproduce the behavior:
- modprobe ashmem_linux
modprobe: FATAL: Module ashmem_linux not found in directory /run/booted-system/kernel-modules/lib/modules/5.18.1-xanmod1

Also trying to start waydroid-container service:
Jun 09 11:45:21 nixos-wlaptop systemd[1]: Started Waydroid Container.
Jun 09 11:45:21 nixos-wlaptop waydroid[21215]: [11:45:21] Failed to load ashmem driver
Jun 09 11:45:21 nixos-wlaptop waydroid[21215]: [11:45:21] modprobe: FATAL: Module ashmem_linux not found in directory /run/booted-system/kernel-modules/lib/modules/5.18.1-xanmod1
Jun 09 11:45:21 nixos-wlaptop waydroid[21215]: [11:45:21] Failed to load Ashmem driver

Notify maintainers
 @fortuneteller2k @lovesegfault @Atemu
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.18.1-xanmod1, NixOS, 22.11 (Raccoon), 22.11pre383837.033bd4fa9a8`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.9.0`
 - channels(root): `"home-manager, nixos"`
 - channels(quantmint): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

From the log: warning: unused option: ASHMEM. Xanmod shouldn't be special here, that's a regular upstream feature.
I'd go and ask upstream about it.

ashmem was removed in linux 5.18, and waydroid has an issue for that: https://github.com/waydroid/waydroid/issues/406

It should be disabled for all 5.18 kernels then.