SqlClient fails to convert decimal(38,20) to .Net decimal for values within the range of .Net's decimal type

This program
        static void Main(string[] args)
        {
            using (var con = new SqlConnection("server=.;database=tempdb;Integrated Security=true"))
            {
                con.Open();
                var cmd = new SqlCommand("select cast(4210862852.86 as decimal(38,20))  val", con);
                using (SqlDataReader rdr = cmd.ExecuteReader())
                {
                    rdr.Read();

                    var val = rdr.GetDecimal(0);
                    Console.WriteLine(val);
                }
            }
        }

fails with
System.OverflowException: 'Conversion overflows.'
at SqlBuffer.cs line 254:
                if (StorageType.Decimal == _type)
                {
                    if (_value._numericInfo.data4 != 0 || _value._numericInfo.scale > 28)
                    {
                        throw new OverflowException(SQLResource.ConversionOverflowMessage);
                    }

This value is well within the range of a .NET decimal, and it's a value that the SqlClient can write using a SqlParameter.  So it should be converted to .NET decimal.
The byte pattern in SQL and TDS for this value is:
0x261400010000D877FB4DEE8B51699A5005000000
And it looks like SqlBuffer refuses to convert any value with a non-zero value in the last 4 bytes.  But a .NET Decimal is stored as a 12-byte integer, along with a sign and a scaling factor.
So the apparent intent is to determine if the SqlDecimal uses a larger-than-12 byte integer and trigger the overflow.
So this conversion has a bug.  It looks like the SqlClient is confused on the byte ordering SQL Server is using, and the last 4 bytes of this buffer are not the 4 least-significant bytes of the 16-byte integer embedded in the decimal.
This number requires uses 12 (base-10) decimal digits to store, so it requires fewer than 12 (base-256) bytes to store.
https://docs.microsoft.com/en-us/dotnet/api/system.decimal?redirectedfrom=MSDN&view=netframework-4.8

As recently announced in the .NET Blog, focus on new SqlClient features an improvements is moving to the new Microsoft.Data.SqlClient package. For this reason, we are moving this issue to the new repo at https://github.com/dotnet/SqlClient. We will still use https://github.com/dotnet/corefx to track issues on other providers like System.Data.Odbc and System.Data.OleDB, and general ADO.NET and .NET data access issues.

This same exception occurs in .NET Framework and Core. It seems like a fairly basic bug but I'm guessing there is a good reason it hasn't been discovered yet. Priority wise, I'm going to consider this an edge case for now unless there is more information that is occurs in a more general use case.

This same exception occurs in .NET Framework and Core. It seems like a fairly basic bug but I'm guessing there is a good reason it hasn't been discovered yet. Priority wise, I'm going to consider this an edge case for now unless there is more information that is occurs in a more general use case.

@David-Engel, I have the same issue, I am trying to retrieve value:<PHONE_NUMBER>234.56789 stored in SQL as:<PHONE_NUMBER>234.56789000000000000, because of a column data type decimal(35,17), as you can see it does not exceed the limit of the .Net decimal type if you ignore the 0's. Can you recommend an interim solution while this is set as low priority?

As a workaround, use an intermediate conversion to string.  Either on SQL Server with a CAST or on the client like this:
var val = Decimal.Parse(rdr.GetSqlDecimal(0).ToString());

As a workaround, use an intermediate conversion to string. Either on SQL Server with a CAST or on the client like this:
var val = Decimal.Parse(rdr.GetSqlDecimal(0).ToString());

Thank you for the reply @dbrownems, much appreciated. Note that I am using Entity Framework Core 2.1, any suggestion would be great?

Would it be possible to remove or exclude the trailing zeros when the _value._numericInfo.scale exceed 28 in the below extract, in that way you keep your precision there is no rounding issue, and throwing the conversion overflow is more valid?
if (StorageType.Decimal == _type)
{
if (_value._numericInfo.data4 != 0 || _value._numericInfo.scale > 28)
{
throw new OverflowException(SQLResource.ConversionOverflowMessage);
}

I'm hitting the same issue. We have a test which writes a random decimal value to the database, and then ensures that the same value can be retrieved from the database intact. Which is failing intermittently because of this.

Same problem here. A simple entity project generated from a sql server database cannot write decimals from c# back to the database, even when they are both of same type decimal.

Any updates on this? This issue is present since 3 years.

It is on the to-do list this semester.


page is not responsive and no dark mode available

I will make the page responsive and add dark mode to it

I would like to solve this issue on time. Assign it to me

done


feat: extended stages, several fixes in page-templating

Ignoring CSS-Linter errors due to upcoming scss-rework


Firmware v.8: changing sample period (interval) impossible, but changing protection voltage OK ...???

On my UPS Plus I can change the protection voltage with what is essentially a few lines from the 'full feature ....' script:
    try:
        givenPV_mV = int(sys.argv[1])
        if givenPV_mV >= PV_Mini_mV and givenPV_mV <= PV_Maxi_mV :
            bus.write_byte_data(DEVICE_ADDR, 0x11, givenPV_mV & 0xFF)
            bus.write_byte_data(DEVICE_ADDR, 0x12, (givenPV_mV >> 0o10) & 0xFF)
            print("Successfully set the protection voltage to: %d mV" % givenPV_mV)
        else:
            errMsg = "Valid protection voltage values range from {:.0f} to {:.0f} mV".format(PV_Mini_mV, PV_Maxi_mV)
            print(errMsg)
    except Exception as exc:
        print("Incorrect parameter: {}. ({})".format(sys.argv[1], str(exc)))

where givenPV_mv is the argument when executing the script.
As long as the argument in mV stays between the set limits, the new value gets written to the registers.
However, if I do the same for the sample period (argument name givenSI), every execution with an acceptable value  ends in an error situation from which the f/w doesn't recover by just restarting the Pi.
The code is just like the lines above:
    try:
        givenSI = int(sys.argv[1])
        if givenSI >= SI_Min and givenSI <= SI_Max :
            bus.write_byte_data(DEVICE_ADDR, 0x15, givenSI & 0xFF)
            bus.write_byte_data(DEVICE_ADDR, 0x16, (givenSI >> 0o10) & 0xFF)
            print("Successfully set the battery sampling interval to: %d min" % givenSI)
        else:
            errMsg = "Valid sampling interval values range from {:.0f} to {:.0f} min".format(SI_Min, SI_Max)
            print(errMsg)
    except Exception as exc:
        print("Incorrect parameter: {}. ({})".format(sys.argv[1], str(exc)))

After this I can still shut the Pi down from the GUI, but I have to disconnect the power and remove the batteries to make the f/w work again.
Both scripts are based on the script setProtectionVoltage.py by frtz13.  Above are just the core lines with the write_byte_data function calls which are just like the ones in the 'full feature ...' script.
I run ftrz13's control script fanShutDownUps.py on my UPS/Pi combo. It is possible by certain *.ini settings to make it shut down the Pi immediately upon disconnecting the AC power. However, since that involves writing to a few i2c registers, too, the shut down never happens because of a crash. This was also reported by frtz13 himself in another issue.
Very much looking forward to a f/w version that can handle writes properly making operation as a UPS, protecting from AC power blackouts, possible again! At the moment the UPS doesn't protect from anything.
I am not going to try out what is will do to my batteries, when the UPS doesn't shut down the Pi and it keeps running indefinitely without AC. Too risky.

We have assigned testers to reproduce the errors.


[local operators and functionals] update interfaces

This is a reminder to myself to refactor the interfaces for local operators and functionals (or just drop them), after the pending refactor of the (global) operators and functionals. The current interfaces only allow for assembling into a matrix and not for matrix-free operators. In addition, they are not used anywhere atm...

To clarify: in the sense of operators and two-forms (products), the method we currently call apply actually provides apply2, as reflected in the interfaces. apply would be used by a matrix-free operator...

Implemented by now.


kubernetes v1.0.2-v0.6.1-alpha

Follow-up of #184

Follow-up of #184

/cc @tsenart

LGTM

Great job! Realling looking forward to this :+1:

@sttts is this ready for review on dcos?

Also... we are moving to locking a version of CLI subcommands to a version of a DCOS service... such that you can not update (and break) a tested version of a dcos service.   It would be great to move to this model.

The CLI subcommand for k8s is not part of this PR yet.

After discussion with @karlkfi and @jdef, it seems this PR is blocked by mesosphere/kubernetes-mesos#421, but this should get in soon.

Rebased.

Followed up by #200.


Package renaming

Pull Request Test Coverage Report for Build 137

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

Totals

Change from base Build 134:
0.0%

Covered Lines:
151

Relevant Lines:
156

💛  - Coveralls


Fix dependabot config again

Third time's the charm.
I'll try to wait until every CI check is finished on the PR before merging. Maybe the dependabot action only runs at the end, which is why we only see it fail when we merge.

Alas, the dependabot check did not run. We'll see if it works upon merging.

It worked :raised_hands:


Scala Hadoop Enrich: way of improving error trap with Thrift input?

Cascading's error trap for unexpected exceptions is great with textual input formats but useless with formats like Thrift. Example output:
[B@e3c15ea
[B@64af48e9
[B@68344ac0
[B@34891c4a
[B@47d2eae9
[B@1a71ec39
[B@4601ec11
[B@77496cbe
[B@484112ab
[B@2689338e
[B@10904e3a
[B@36db4683

Not sure if there is a solution here, but worth exploring.

There is no error trap since the move to Spark, closing

Does that mean that all the continue_on_unexpected_error and errors: bucket paraphernalia is no longer used?

it's been kept for backwards-compatibility purposes

Let's create a ticket to track removing this from the product, even if 90% of this will go "for free" when we move to Dataflow Runner...

even if 90% of this will go "for free" when we move to Dataflow Runner...

It depends on how long we want to keep supporting the scalding-based pipeline for.

Right - let's open up a ticket to discuss this.


Do you have any plan to release the Discriminator weights for 256 and 512 models?

Hi ajbrock,
Do you have any plan to release the discriminator weights for 256 or 512 models? I tried to use the discriminator for 128 models and I think it is a conditional discriminator. Is there any chance to convert it to an unconditional discriminator? Please correct me if I misunderstand anything about it.
Thank so much!

Hi qilimk,
We are currently considering training and releasing a 256x256 model using this repo, but have not made any decisions yet. The discriminators are conditional, but you could conceivably remove the projection layer to make it unconditional (it's not clear how much this will impact the network, however, you'd have to figure that out for yourself.)

Do you consider to release the weights of TensorFlow version discriminator for the 256x256 or 512x512 models? Thanks.

There are no plans to release the TF versions of the discriminator weights at this time.


Enable deferred device deletion feature for devicemapper

Docker 1.9 has now deferred device deletion feature support for devicemapper. That means a container can be removed even if underlying device is busy as it has leaked into another mount namespaces. We are having issues where a container is launched and then SPC is launched and root device of containers launched before SPC leaks into SPC container under /hosts. That means none of the container launched before SPC can be deleted till SPC exits.
This should help fix that issue.

@cgwalters PTAL.

I think we should cleanup the code and figure it will work on all modern versions of docker.  At least all of the ones we currently support.  Or just do it the old way.

Looks like it was added in July
commit e221291a25fb905a476d9328785bdbfbd9cb7373
Merge: 60b34cb 41588a5
Author: Jessie Frazelle<EMAIL_ADDRESS>Date:   Mon Jul 13 17:04:06 2015 -0700

    Merge pull request #14194 from phemmer/cli-version-format

    add --format flag to `docker version`

@rhatdan Thanks for finding that commit. So yes, if it has been added in july (3 months back), then it is fairly recent. So that means docker 1.7 does not support it and docker 1.8 likely supports it.
So what do you consider modern version of docker. Should this work with docker 1.7 or not?

I think we should move forward to docker-1.8 and just require that version or greater for docker-storage-setup

@rhatdan @cgwalters I got rid of old method of querying version. PTAL.


Allow showing of success message for logged in users as well

Problem:
Currently, Frappe only displays the success message to a Web Form if the user is a Guest, while logged in users are redirected back to the form.
Solution:
Show the success message for logged in users, and only when the form is submitted for the first time.

Ya know what, make a PR to Frappé staging with this. Ping on the Frappé Developers group on where to make this PR

[PR[(https://github.com/frappe/frappe/pull/5939/files) made to Frappe.


WIP Manual es6 cleanup

Whoah there was an assignment to a global
barycenter_sort = (a, b) => {

Whoah there was an assignment to a global
barycenter_sort = (a, b) => {

Probably more cleanup opportunity in Decorana. Did what I could with that code. It's pretty interesting that it's ported from old Fortran code.

Probably more cleanup opportunity in Decorana. Did what I could with that code. It's pretty interesting that it's ported from old Fortran code.

Ready for review @jdfekete @Fil. Thanks!

Ready for review @jdfekete @Fil. Thanks!

Thanks a lot for the cleanup. I fixed a few issues but everything seems to be fine. More tests are needed to be sure, but that'll be for later.

Thanks a lot for the cleanup. I fixed a few issues but everything seems to be fine. More tests are needed to be sure, but that'll be for later.


Adding support for image save/load.

@jstarks @jterry75
The new cmdlets Export/Import-ContainerImage (aliased to Save/Load-ContainerImage respectively) can save or restore images from a tar file.
Includes a fix to the return type of Request-ContainerImage.

LGTM


Library is always shown even with --no-library option

Hi!. I tried running vimiv --no-library and even adding start_show_library: no to my vimivrc file but the library is always shown upon opening. I'm using latest git version.
Thanks in advance for looking into this.

Does it also show the library if you add a path to an image to the command? E.g.
vimiv --no-library Images/my_image.png
If not, it will always show the library, as there is nothing else to show and the library is the preferred way to open an image, once vimiv has been started.

Ok. I was under the impression that --no-library would never show the library. The flag is a bit misleading i guess. Don't know if you can/plan to change the behaviour (either by changing the man page or actually never showing the library). Feel free to close. Thanks!

Just out of curiosity, what would you display instead? Just a plain background? And how should the user then open images?

This makes sense and is already possible in the (private) Qt rewrite, I really have to get this in a usable state :smile:

Closing as this has been implemented in the Qt port which is now in a much more usable state. No new features will be implemented here. I hope the new version can be of some use to you, in case anything is missing please open an issue.


Kip213 docs

Docs for the KIP 213 change.
2 important notes:

I have put the KTable-KTable foreign key join in a separate section than the regular KTable Ktable join. It's fairly similar, but I have attempted to highlight the differences without getting into the underlying mechanics. Is this the correct approach? Or do I need to expose the mechanics too?

Can someone review the record + offset table at the end of the section to verify if it makes sense?

@guozhangwang @mjsax @vvcephei  not sure who else may be interested.

@bellemare -- seems you did not push your changes :)

@vvcephei  @mjsax Okay, should be done now. LMK

@bellemare -- this PR needs to be rebased to resolve merge conflicts.

Okay I think it's good to go now - thanks for your reviews guys!

Thanks for the PR @bellemare!
Merged to trunk and cherry-picked to 2.4 branch.


Stash screen check not working

I have issues to get the screen check for the stash tab to work. It keeps on returning negative. Looked at the FAQ and confirmed:

Using windowed fullscreen
Using DX12
Done several manual calibrations

The calibration image shows what is shown in info, but it still returns negative every time. Any other things I can try?

Are you using anything that alters the output on screen, e.g. graphical filters (ReShade, Nvidia GeForce Experience, driver settings, HDR, etc.)?

I turned off all the overlap options in GeForce Experience.

Ok, I checked on other overlays, that were running and that I'm aware off:

Discord
Steam
GameBar

Turned off all and I still get a negative. Maybe I missed an overlay, but those are the ones that I could find and I interacted with in the past.

Oh, I may have found a bug. Do you have the Act-Tracker, Betrayal-Info, or Necropolis feature enabled? If not, could you enable one of those and then test the stash check again?

Thank you so much for being so responsive and making the mod. Really great to get help so quickly. I enabled the act tracker and now it works!


Open graph in a dedicated page

First of all, awesome work! It's really great.
It doesn't seem to be possible to open the graph in a dedicated page, it's always opened as a split view. Would it be possible to open it in a new page for better exploration?

Thank you for your comment! You can drag the page tab to your current view so that it will be on the same page. Alternatively, you can drag it to the side view on the right, where it will dock for easier navigation. I’m not exactly sure what you mean by "new page." Do you mean a pop-up window? If so, it might cause users to switch between windows frequently when editing files.


Increase connectionTimeout for DynamoDB client

I believe a 2ms timeout here is a source of test flakiness.

@tjlahr Thanks for the PR. I think you're right that 2ms is definitely too short -- I added some additional logging locally and was seeing that with the current 2ms connectTimeout, the ddb client had to do some retries. So it stands to reason that maybe under certain circumstances, it could run out of retries and fail.

Released v2.0.1


Gdcm 2023 11 06

@thewtex @dzenanz looks like nuking my git checkout worked!
Since @dzenanz updated GDCM just the other day, there's not much here except I added the .codespellrc config file.


Applying new force in step method

Hi all,
I'm building a custom RL env to do some learning tasks with soft filaments in PyElastica. I'm running into trouble applying new actions and I was looking over the Case 1 code for some guidance on how I might do that. One of the points that I am confused about is how you apply a new action when you call the step method of the env. The reset method finalizes the simulator and my understanding is that after finalization no new forces can be added. Is the point that no new forces can be added but we can change the magnitude of the forces/torques already there? In other words, how is the step method applying a new force without resetting the environment?
Thanks

Hi @davenpi ,
In the step method we are passing the action, and action array contains the control points for muscle torque spline. As you can see in step method, we pass the numbers inside the action to the spline_points_func_array_* . Note that  spline_points_func_array_* is a NumPy array and initialize in the reset method, and we are only changing the entries of the array.
So you don't need to reset the environment to change the forces, you only need to update the action.

Hi @armantekinalp
Thanks for the response. The issue I was having turned out to be an action space sampling issue. I thought I wasn't able to specify new actions but actually it was just that the policy kept picking the same action. Once I normalized the action space as indicated in the SB3 docs (and this issue) things started working as expected. Thanks again.


TTX dump can't be recompiled

This might be caused at the TTX/FontTools side of things, but reporting it for completeness sake:
When I follow the instructions and dump the resulting font with TTX/FontTools, I get a nice varibox-VF.ttx file. But when I want to compile this back to a font, I get:
~/code/i-can-variable-font/example messing-around★  20:08:36
➤ ttx varibox-VF.ttf
Dumping "varibox-VF.ttf" to "varibox-VF.ttx"...
Dumping 'GlyphOrder' table...
Dumping 'head' table...
Dumping 'hhea' table...
Dumping 'maxp' table...
Dumping 'OS/2' table...
Dumping 'hmtx' table...
Dumping 'cmap' table...
Dumping 'loca' table...
Dumping 'glyf' table...
Dumping 'name' table...
Dumping 'post' table...
Dumping 'GDEF' table...
Dumping 'GPOS' table...
Dumping 'fvar' table...
Dumping 'gvar' table...
~/code/i-can-variable-font/example messing-around★  20:08:43
➤ ttx varibox-VF.ttx
Compiling "varibox-VF.ttx" to "varibox-VF#1.ttf"...
Parsing 'GlyphOrder' table...
Parsing 'head' table...
Parsing 'hhea' table...
Parsing 'maxp' table...
Parsing 'OS/2' table...
Parsing 'hmtx' table...
Parsing 'cmap' table...
Parsing 'loca' table...
Parsing 'glyf' table...
Parsing 'name' table...
Parsing 'post' table...
Parsing 'GDEF' table...
Parsing 'GPOS' table...
Parsing 'fvar' table...
Parsing 'gvar' table...
ERROR: Unhandled exception has occurred
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttx.py", line 398, in main
    process(jobs, options)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttx.py", line 372, in process
    action(input, output, options)
  File "/usr/local/lib/python2.7/site-packages/fontTools/misc/loggingTools.py", line 372, in wrapper
    return func(*args, **kwds)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttx.py", line 293, in ttCompile
    ttf.save(output)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/__init__.py", line 216, in save
    self._writeTable(tag, writer, done)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/__init__.py", line 654, in _writeTable
    tabledata = self.getTableData(tag)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/__init__.py", line 665, in getTableData
    return self.tables[tag].compile(self)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/tables/otBase.py", line 90, in compile
    self.table.compile(writer, font)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/tables/otBase.py", line 674, in compile
    conv.write(writer, font, table, value)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/tables/otConverters.py", line 391, in write
    value.compile(subWriter, font)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/tables/otBase.py", line 649, in compile
    conv.write(writer, font, table, value, i)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/tables/otConverters.py", line 391, in write
    value.compile(subWriter, font)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/tables/otBase.py", line 623, in compile
    table = self.preWrite(font)
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/tables/otTables.py", line 209, in preWrite
    for item in self.Item:
  File "/usr/local/lib/python2.7/site-packages/fontTools/ttLib/tables/otBase.py", line 557, in __getattr__
    raise AttributeError(attr)
AttributeError: ('Item', 'VarData[0]', 'VarStore')
~/code/i-can-variable-font/example messing-around★  20:08:53
➤

Issue over at the TTX/FontTools repo.

Thanks for the heads up. It looks like they've fixed it already, so going to close this out. Let me know if you think something should be noted in the guide though.

Perhaps a "make sure you have the most up-to-date TTX/FontTools", but then again you can complete the i-can-variable-font build process nicely without running into this error. So leaving the notes as-is sounds good enough!


dropping json gem dependency

hello simplecov-contributors!
just out of interest, how important is supporting really really really old rubies for simplecov?
i recently saw this tweet from Mike Perham (https://github.com/rails/rails/pull/23453) and started looking at our Gemfiles. some of the projects only use simplecov and therefor a quite significant amount of gem dependencies.
dropping the json is just one example and it's only a minor code change, it's almost a philosophical question and there is no right or wrong. there are opinions. i'm interested in the opinion of you, the simplecov contributors.
thanks for simplecov!
ben

My take: if it's causing us problems we should drop EOL versions.

I second that, I think we should get rid of support for EOL'd rubies. On the 2.x-vresions of Ruby I've personally not seen any upgrade issues anyway, so now that 2.0 is getting EOL'd this month it might even make sense to drop support for that too.

Somewhat related as to supporting outdated rubies: A minor compatibility issue came up that breaks simplecov for 1.9.3, which EOL'd around a year ago: https://github.com/colszowka/simplecov/pull/448/files#r52411167

my personal take on this:
to me, it's ok to drop support for EOL'd versions of ruby (currently speaking of 1.8 and 1.9, 2.0 will be EOL'd in a few weeks). you can still use the older version of SimpleCov if you are on 1.8. you could consider security patches for older versions, but this introduces a lot of communication and maintenance overhead. i personally don't even know how i can install 1.8.7 on my mac without spending a significant amount of time on it.
what just came to my mind. maybe this can also simplify the rails integration? never versions of Rails are pretty hardcore at dropping older ruby versions. (AFAIK Rails 5 will only run on 2.2 and higher?)
i will prepare a PR that removes the json dependency, since it's included in 2.0 and higher. but i guess that should go into the next major versions where the dropped support for old rubies can be properly announced?

Just dropepd support of old rubies and of the JSON gem.


bug: slidebox does-continue not works on ios

Hello, I am Chinese , my  english is poor.  I will try my best to explain my question.
I used ionic to develop a software.
I used method  $ionicSlideBoxDelegate.update() after setting slides, the 'does-conitnue = true' can not works on ios,  but it can work on android.

Greetings @Demonlovemoon!
My sensors indicate that you need to update your issue through our custom issue form. We are now requiring all issues to be submitted this way, to ensure that we have all of the information necessary to fix them as quickly as possible.
Click Here To Update Your Issue
I will have no choice but to close this issue if it is not resubmitted through the form. Please fill out the rest of the form, so that I may use my friendly robot powers to assist you.
Thank you!

Greetings @Demonlovemoon!
I've closed this issue because my sensors indicated it was old and inactive, and may have already been fixed in recent versions of Ionic. However, if you are still experiencing this issue, please feel free to reopen this issue by creating a new one, and include any examples and other necessary information, so that we can look into it further.
Thank you for allowing me to assist you.


ksy update

added the kaitai-struct files I currently have

I added th11 support in another branch but figured I should do these in their own PR first

I wonder if the new ks will fix the issue we had

nah it turns out i had an old version of the kaitai struct compiler installed, so these commits literally revert the code and then bring it back (whoops)
plus i didnt even touch the ones that actually had the issue


in-memory-web-api returns html

In-memory-web-api returns html instead of dummy data.

Can you show your configuration (how you configure the in-memory module) and also your mock data.

Yeah, that was the problem.
But it was not same as in your case.
Seeing the below code, I thought HttpModule gets loaded first. But somehow it did not happen(Dunno why!)
  imports: [
    BrowserModule,
    FormsModule,
    HttpModule,
    RouterModule.forRoot(ROUTES, { useHash: true })
  ],

This is how I solved the problem:
I changed the following code to the second snippet.
    imports: [
        FormsModule,
        CommonModule,
        ModalModule,
        RouterModule.forChild(routes),
        InMemoryWebApiModule.forRoot(DepartmentData)
        ],

    imports: [
        **HttpModule**,
        FormsModule,
        CommonModule,
        ModalModule,
        RouterModule.forChild(routes),
        InMemoryWebApiModule.forRoot(DepartmentData)
        ],


Caveats of Start-RSJob -ModulesToImport

PoshRSJob <IP_ADDRESS> on PowerShell v5.
When you first use Start-RSJob, if you don't specify a -ModulesToImport, then on later runs of Start-RSJob the -ModulesToImport will not work and script blocks depending on those modules will fail.
This is because the runspaces have already been set up without the modules you wanted, and they haven't been torn down.
It's also worth mentioning there's no equivalent of a -Force for this. If you update the module, then it won't be reflected inside jobs in the run spaces (even when you start them later on).

This looks like a side effect of allowing the commands to work with ForEach-Object. I'll have to think about how I want to handle this in either rolling back the change and taking away the ForEach-Object support or figuring out another way to do this.
I'm not sure I want a -Force parameter with Start-RSJob as the user shouldn't have to worry about knowing when to force a new runspacepool to be created due to needing another module imported. At that point, they could just use a new batch name via the -Batch parameter and it would create a new runspacepool and import the module correctly.

This affects more than just -ModulesToImport. -FunctionsToLoad and I suspect (have not tested) that -PSSnapinsToImport will also be affected.

I do not have any issues with this
PSv5
as far as I see, both jobs have different runspaceid.
I'm also testing modules and also do not find any problems
PS D:\> Import-Module PoshRSJob
PS D:\> Function Test {'This is a test'}
PS D:\> Function Test1 {1..10}
PS D:\> 1|start-rsjob {Test} -FunctionsToLoad Test

Id       Name                 State           HasMoreData  HasErrors    Command
--       ----                 -----           -----------  ---------    -------
1        Job1                 Running         False        False        Test

PS D:\> 1|start-rsjob {Test1} -FunctionsToLoad Test1

Id       Name                 State           HasMoreData  HasErrors    Command
--       ----                 -----           -----------  ---------    -------
2        Job2                 Running         False        False        Test1

PS D:\> Get-RSJob | fl *

HasErrors      : False
Verbose        :
Debug          :
Warning        :
Progress       :
Name           : Job1
ID             : 1
State          : Completed
InputObject    : 1
InstanceID     : b320e1c2-b514-4c20-b0c8-e6c73a1ed1ae
Handle         : System.Management.Automation.PowerShellAsyncResult
Runspace       :
InnerJob       : System.Management.Automation.PowerShell
Finished       : System.Threading.ManualResetEvent
Command        : Test
Error          :
HasMoreData    : True
Output         : {This is a test}
RunspacePoolID : 5aa9db1a-7525-4465-8bb5-19c7d2d0f555
Completed      : True
Batch          : 5aa9db1a-7525-4465-8bb5-19c7d2d0f555

HasErrors      : False
Verbose        :
Debug          :
Warning        :
Progress       :
Name           : Job2
ID             : 2
State          : Completed
InputObject    : 1
InstanceID     : 65f685aa-0a54-4baf-9206-ee250f98693a
Handle         : System.Management.Automation.PowerShellAsyncResult
Runspace       :
InnerJob       : System.Management.Automation.PowerShell
Finished       : System.Threading.ManualResetEvent
Command        : Test1
Error          :
HasMoreData    : True
Output         : {1, 2, 3, 4...}
RunspacePoolID : 287945f8-5d95-4929-8bcb-b2a07dd790e2
Completed      : True
Batch          : 287945f8-5d95-4929-8bcb-b2a07dd790e2

PS D:\> Get-Module PoshRSJob

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     <IP_ADDRESS>    PoshRSJob                           {Get-RSJob, Receive-RSJob, Remove-RSJob, Start-RSJob...}

PS D:\>

It's working now because you are using the latest version that fixed it. If you download V<IP_ADDRESS>, then there would be issues with your first example. I pretty much know where the issue is happening at in the code. I define the module/pssnapin/function point before I get to the runspacepools and if an existing one is used, then none of these things are loaded. I just need to load everything after I pick a runspacepool (either a new one or existing) and then attempt to add these into the mix. It definitely needs testing because I don't know yet if it will actually work. :)

Yes, I need to read releasenotes....
but... You comment out both code branches - with and without -Batch
but with batch you know what you do, if runspacepool with selected batch name already exists, you reuse it and its fine when you ignore -modulestoload - you alreay load modules when you create batch (line 448)
thus the bug actually present when you do not use batch but still use the same runtimepool - lines 399-407
I think that Start-RSJob should distinguish between pipeline and several  independent launches and reuse ruinspace pool only when it detect pipeline input
the best fix I know  - generate batch name in begin {} block :)
begin {
If (-NOT $PSBoundParameters.ContainsKey('Batch')) {
                $Batch = $RunspacePoolID = [guid]::NewGuid().ToString()
}
}

and do not test for $PSBoundParameters.ContainsKey('Batch') inside process

I'm pretty sure I know how to solve the issue for Modules/Functions etc... in regards to making sure that they are updated properly; just need to get some time to update the code.
Distinguishing the pipeline support for the jobs can be checked fairly simply by first looking at the named parameter for InputObject and then looking at the Process block. The big thing is making sure that we handle not only ForEach-Object, but also the ForEach keyword and even using other loops like While to ensure that all bases are covered. I started looking at using Get-PSCallstack as a means to determine whether or not I could accurately see if there was any sort of looping going on, but wasn't too impressed with the initial results.

Get-PSCallstack has very poor performance. It's best not to call it in any looping code like a Process block.

Yep. That and you would still have to parse the code to determine if the command was used in a loop.

You want to support RunspacePool reusing automatically inside any loops ? I find it overkill feature because user can use -Batch.
and... imagine code like this
foreach ($i in 1..10)
{
  if ($i%2) {
    Start-RSJob { OddFunction() } -FunctionsToImport OddFunction
  } else {
   Start-RSJob { EvenFunction() }  -FunctionsToImport EvenFunction
  }
}

Are you sure user want to run both functions in the same Runspace ? I''m not
I'm think than the one only loop that can guarantee that user want it run in the same runspace - is pipeline. All other - user desision. To use or not to use -Batch parameter.

You want to support RunspacePool reusing automatically inside any loops ? I find it overkill feature because user can use -Batch.
I think the entire idea behind all of this was to support something like this:

1..10 | ForEach [
    $_|Start-RSJob -Name {$_} -ScriptBlock {$_}
}

So I guess I would answer that with a yes. But in hindsight, I really should have never bothered trying to wedge the type of support that I had with anything other than directly piping the input into the command.
If a person wanted to use a foreach loop with the command, then they need to know that each command will create a new runspacepool (and lose any use of throttling) unless they use the -Batch parameter (as you mention). I would consider that more of a user education to understand how to use the command and parameter to ensure that the module behaves as intended.
Some good feedback and this does fit in with what I spent some of the day working on to ensure that only -Batch use will reuse the runspacepool and have it autogenerated in the Begin block.

If you do desision about runspace reusing on code analysis then you probably can't catch code like this
$BigData | ForEach [
    if ( Test-SomeHardDecision $_ ) {
      $_ | Start-RSJob -ScriptBlock { TestFunction } -ModulesToImport 'C:\Debug\MyModule'
    }
    else {
       $_ | Start-RSJob -ScriptBlock { TestFunction } -ModulesToImport 'C:\Production\MyModule'
   }
}

and user will be disappointed on result because it will be breaking change with current (and past) module behaviour
Both your and my examples have point of management with -Batch parameter
But I believe that decision to reuse or not reuse pool can be only on user side or when invoke contract stable. And only pipeline can guarantee that it stable because all parameters bounded just one time on call and other loops bound parameters on each invoke and user may want to mutate it


Site model

Restoring the Site model so we can populate sites table using ActiveRecord.
Things to check

[ ] If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
[ ] This code does not rely on migrations in the same Pull Request
[ ] If this code includes a migration adding or changing columns, it also backfills existing records for consistency
[ ] If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
[ ] API release notes have been updated if necessary
[ ] Required environment variables have been updated added to the Azure KeyVault

 Site UUIDS: Transition [2/2] - Remove the old site model [SPIKE]


[Bug]: Make the Code Redable and make the cards load independently not all at once

Contribution guidelines

[X] I've read the contribution guidelines and wholeheartedly agree

Description
[Bug]: Make the Code Redable and make the cards load independently not all at once. Very hard to debug and components are not reused
Expected behaviour
Make the Code Redable and make the cards load independently. it should be easy to debug.
Actual behaviour
Code is not Redable ,  cards are not loading independently
Steps to reproduce
check bes lighthouse code base
Relevant screenshots
check bes-lighthouse
What browsers are you seeing the problem on?
No response
Relevant log output
No response

FYI @sumodgeorge


Update teardown script

PVs are not namespaced in kubernetes. This script can potentially delete all the other PVs in the cluster. Thus namespacing the deletion of the PVs. Also it would be a good practice to delete the namespace at last.

Sorry for goofing up. I have created new PR to delete specific set of PVs and not all.
Basically -n ceph wont apply for PVs in kubernetes.


[BUG] Version dependency for typing_extensions

Describe the bug
The recent libraries with FastAPI require an up-to-date typing_extensions (e.g. 4.8.0)
The version requirements are too specific, so it is hard to install with other libraries...
Plus, both pydantic==1.10.4 and fastapi, other dependencies on the library, are satisfied with typing-extensions==4.8.0.
However, the current dependency typing_extensions==4.5.0 shows an error.
This would be solved if the requirements.txt should be fixed to:
pydantic==1.10.8
typing-extensions>=4.8.0

Have you searched existing issues?  🔎

[X] I have searched and found no existing issues

Reproduction
Just
pip install netspresso

(Use with library)

throws an error.
Screenshot
No response
Logs
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
fastapi 0.104.1 requires typing-extensions>=4.8.0, but you have typing-extensions 4.5.0 which is incompatible.
pydantic-core 2.14.3 requires typing-extensions!=4.7.0,>=4.6.0, but you have typing-extensions 4.5.0 which is incompatible.

System Info
Python 3.8
General with all OS systems

Found out that there is no problem in this library.
I'll close this issue, but I recommend that it'd be better if you allow keeping up-to-date library versions.
It's hard to use with other well-known libraries which have dependency on up-to-date pydantic or fastapi.


[UPGRADE] Upgrade Grafana to the latest version

Is your feature request related to a problem? Please describe.
Grafana's team doesn't directly specify EOL but there are few CVE's in our current version:

CVE-2021-39226
CVE-2020-27846
CVE-2021-27358
CVE-2021-28148
CVE-2021-27962
CVE-2021-28147

The latest released version is 8.2.4
Check if there are any breaking changes we should take care of when upgrading.
Additional context
Check if this fixes #2420 or if we can include this in this issue. Also check if we can do this refactoring when taking care of the upgrade: #2028

DoD checklist

[ ] Changelog updated
[ ] COMPONENTS.md updated / doesn't need to be updated
[ ] Schema updated / doesn't need to be updated
[ ] Feature has automated tests
[ ] Automated tests passed (QA pipelines)

[ ] apply
[ ] upgrade

[ ] Idempotency tested
[ ] Documentation added / updated / doesn't need to be updated
[ ] All conversations in PR resolved
[ ] Solution meets requirements and is done according to design doc
[ ] Usage compliant with license
[ ] Backport tasks created / doesn't need to be backported

Spike about versions was in #2719.

Upgraded to the newest version: 8.2.5

✔ Tested apply and upgrade from v1.0 (x86_64) and from v1.1 (aarch64).


proto use fails with an odd error when git is missing

What version?
0.41.3
Which command?
proto use
What happened?
I installed proto on a recently re-installed machine. Git is not yet installed.
proto use crashes with a confusing error that doesn't explain the reason
I expect the error message to mention the failing command git.
The output of proto use:
$ proto use
  node ━━━━━━━━━━━━━━━━━━━━ | Installing Node.js 22.9.0
   npm ━━━━━━━━━━━━━━━━━━━━ | Installing npm 10.9.0
  pnpm ━━━━━━━━━━━━━━━━━━━━ | Installing pnpm latest                                                                    Error:   × Main thread panicked.
  ├─▶ at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\tokio-
  │   1.40.0\src\runtime\time\entry.rs:568:9
  ╰─▶ A Tokio 1.x context was found, but it is being shutdown.
  help: set the `RUST_BACKTRACE=1` environment variable to display a backtrace.

Note the "help" text which suggests setting RUST_BACKTRACE=1 (I wonder if there's a way to mention setting the --log=trace or PROTO_LOG=trace in addition or instead?)
Trace logs?
[DEBUG 2024-10-06 18:12:37.420] proto  Running proto v0.41.3  bin="C:\\Users\\dan\\.proto\\bin\\proto.exe" args=["--log=trace", "use"] pid=1412
[TRACE 18:12:37.421] starbase::app  Running startup phase
[DEBUG 18:12:37.424] proto_core::proto  Creating proto environment, detecting store  store="C:\\Users\\dan\\.proto" home="C:\\Users\\dan"
[TRACE 18:12:37.424] starbase::app  Running analyze phase
[DEBUG 18:12:37.425] proto::systems  Loading configuration in upwards mode  working_dir="C:\\Users\\dan\\.proto"
[DEBUG 18:12:37.425] proto_core::proto_config  Loading .prototools  file="C:\\Users\\dan\\.proto\\.prototools"
[TRACE 18:12:37.425] starbase_utils::fs  Reading file  file="C:\\Users\\dan\\.proto\\.prototools"
[TRACE 18:12:37.426] schematic::config::loader  Loading partial configuration  config="ProtoConfig"
[TRACE 18:12:37.426] schematic::config::loader  Creating layer from source  config="ProtoConfig" source="<code>"
[TRACE 18:12:37.427] schematic::config::loader  Merging partial layers into a final result  config="ProtoConfig"
[DEBUG 18:12:37.427] proto_core::proto_config  Loading .prototools  file="C:\\Users\\dan\\.proto\\.prototools"
[TRACE 18:12:37.428] starbase_utils::fs  Opening file  file="C:\\Users\\dan\\.proto\\.prototools"
[TRACE 18:12:37.428] starbase_utils::fs_lock  Locking file  file="C:\\Users\\dan\\.proto\\.prototools"
[TRACE 18:12:37.428] starbase_utils::fs_lock  Unlocking file  file="C:\\Users\\dan\\.proto\\.prototools"
[TRACE 18:12:37.429] schematic::config::loader  Loading partial configuration  config="ProtoConfig"
[TRACE 18:12:37.429] schematic::config::loader  Creating layer from source  config="ProtoConfig" source="<code>"
[TRACE 18:12:37.430] schematic::config::loader  Merging partial layers into a final result  config="ProtoConfig"
[DEBUG 18:12:37.430] proto_core::proto_config  Merging loaded configs without global
[DEBUG 18:12:37.430] proto_core::proto_config  Merged 1 configs
[TRACE 18:12:37.430] starbase::app  Running execute phase
[DEBUG 18:12:37.431] proto::commands::install  Loading all tools
[TRACE 18:12:37.431] starbase_utils::net  Checking for an internet connection  timeout=750
[DEBUG 18:12:37.431] proto_core::tool_loader  Finding a configured plugin  tool="internal-schema"
[TRACE 18:12:37.431] starbase_utils::net::offline  Resolving <IP_ADDRESS>:53
[DEBUG 18:12:37.432] proto_core::proto_config  Merging loaded configs with global
[DEBUG 18:12:37.432] proto_core::proto_config  Merged 2 configs
[DEBUG 18:12:37.432] proto_core::tool_loader  Using a built-in plugin  plugin="https://github.com/moonrepo/tools/releases/download/schema_tool-v0.15.0/schema_tool.wasm"
[TRACE 18:12:37.433] warpgate::loader  Creating plugin loader  cache_dir="C:\\Users\\dan\\.proto\\plugins"
[TRACE 18:12:37.433] warpgate::loader  Loading plugin internal-schema  id="internal-schema" locator="https://github.com/moonrepo/tools/releases/download/schema_tool-v0.15.0/schema_tool.wasm"
[TRACE 18:12:37.434] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\internal-schema-3d513fa42b2af231aabb30d98ce37f264630c0f72a637fe9c1c1625330b0cc1c.wasm"
[TRACE 18:12:37.434] warpgate::loader  Plugin already downloaded and cached  id="internal-schema" path="C:\\Users\\dan\\.proto\\plugins\\internal-schema-3d513fa42b2af231aabb30d98ce37f264630c0f72a637fe9c1c1625330b0cc1c.wasm"
[TRACE 18:12:37.436] warpgate::loader  Loading plugin yarn  id="yarn" locator="https://github.com/moonrepo/tools/releases/download/node_depman_tool-v0.13.1/node_depman_tool.wasm"
[TRACE 18:12:37.436] warpgate::loader  Loading plugin bun  id="bun" locator="https://github.com/moonrepo/tools/releases/download/bun_tool-v0.13.0/bun_tool.wasm"
[TRACE 18:12:37.436] warpgate::loader  Loading plugin deno  id="deno" locator="https://github.com/moonrepo/tools/releases/download/deno_tool-v0.12.0/deno_tool.wasm"
[TRACE 18:12:37.436] warpgate::loader  Loading plugin pnpm  id="pnpm" locator="https://github.com/moonrepo/tools/releases/download/node_depman_tool-v0.13.1/node_depman_tool.wasm"
[TRACE 18:12:37.436] warpgate::loader  Loading plugin npm  id="npm" locator="https://github.com/moonrepo/tools/releases/download/node_depman_tool-v0.13.1/node_depman_tool.wasm"
[TRACE 18:12:37.436] warpgate::loader  Loading plugin node  id="node" locator="https://github.com/moonrepo/tools/releases/download/node_tool-v0.12.2/node_tool.wasm"
[TRACE 18:12:37.436] warpgate::loader  Loading plugin python  id="python" locator="https://github.com/moonrepo/tools/releases/download/python_tool-v0.11.0/python_tool.wasm"
[TRACE 18:12:37.438] starbase_utils::net  Online!
[TRACE 18:12:37.440] starbase_utils::fs  Reading file  file="C:\\Users\\dan\\.proto\\temp\\.last-version-check"
[TRACE 18:12:37.441] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\yarn-b9341305d212d01f814c24338dadc08498000fcc4a6b6e8e1e7b27fc5cd7478c.wasm"
[TRACE 18:12:37.441] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\bun-4b79ec6cdd21539c566e496b71ed6962349b8bd7c84d114f758b9277aedbcd81.wasm"
[TRACE 18:12:37.441] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\deno-0c576e3fa327e68fc1896e3eb15866c63f35d549fc5fc64ca1f22c271c1c2a9b.wasm"
[TRACE 18:12:37.441] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\npm-b9341305d212d01f814c24338dadc08498000fcc4a6b6e8e1e7b27fc5cd7478c.wasm"
[TRACE 18:12:37.441] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\pnpm-b9341305d212d01f814c24338dadc08498000fcc4a6b6e8e1e7b27fc5cd7478c.wasm"
[TRACE 18:12:37.442] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\python-d9edd08733791589cdb1a72ccb39494f6af46ce8f1c36a959635db26b2d1782b.wasm"
[TRACE 18:12:37.442] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\node-2c6c77c45d1bdb8f047e79502196bb8fd995504ce5c4c03a9d26b1f7c8b15d59.wasm"
[TRACE 18:12:37.442] warpgate::loader  Plugin already downloaded and cached  id="yarn" path="C:\\Users\\dan\\.proto\\plugins\\yarn-b9341305d212d01f814c24338dadc08498000fcc4a6b6e8e1e7b27fc5cd7478c.wasm"
[TRACE 18:12:37.443] warpgate::loader  Plugin already downloaded and cached  id="bun" path="C:\\Users\\dan\\.proto\\plugins\\bun-4b79ec6cdd21539c566e496b71ed6962349b8bd7c84d114f758b9277aedbcd81.wasm"
[TRACE 18:12:37.443] warpgate::loader  Plugin already downloaded and cached  id="deno" path="C:\\Users\\dan\\.proto\\plugins\\deno-0c576e3fa327e68fc1896e3eb15866c63f35d549fc5fc64ca1f22c271c1c2a9b.wasm"
[TRACE 18:12:37.443] warpgate::loader  Plugin already downloaded and cached  id="npm" path="C:\\Users\\dan\\.proto\\plugins\\npm-b9341305d212d01f814c24338dadc08498000fcc4a6b6e8e1e7b27fc5cd7478c.wasm"
[TRACE 18:12:37.443] warpgate::loader  Loading plugin rust  id="rust" locator="https://github.com/moonrepo/tools/releases/download/rust_tool-v0.11.0/rust_tool.wasm"
[TRACE 18:12:37.443] warpgate::loader  Plugin already downloaded and cached  id="pnpm" path="C:\\Users\\dan\\.proto\\plugins\\pnpm-b9341305d212d01f814c24338dadc08498000fcc4a6b6e8e1e7b27fc5cd7478c.wasm"
[TRACE 18:12:37.444] warpgate::loader  Plugin already downloaded and cached  id="python" path="C:\\Users\\dan\\.proto\\plugins\\python-d9edd08733791589cdb1a72ccb39494f6af46ce8f1c36a959635db26b2d1782b.wasm"
[TRACE 18:12:37.444] warpgate::loader  Plugin already downloaded and cached  id="node" path="C:\\Users\\dan\\.proto\\plugins\\node-2c6c77c45d1bdb8f047e79502196bb8fd995504ce5c4c03a9d26b1f7c8b15d59.wasm"
[DEBUG 18:12:37.444] proto_core::tool_loader  Loading WASM plugin  source="C:\\Users\\dan\\.proto\\plugins\\bun-4b79ec6cdd21539c566e496b71ed6962349b8bd7c84d114f758b9277aedbcd81.wasm"
[DEBUG 18:12:37.445] proto_core::tool_loader  Loading WASM plugin  source="C:\\Users\\dan\\.proto\\plugins\\yarn-b9341305d212d01f814c24338dadc08498000fcc4a6b6e8e1e7b27fc5cd7478c.wasm"
[DEBUG 18:12:37.445] proto_core::tool_loader  Loading WASM plugin  source="C:\\Users\\dan\\.proto\\plugins\\npm-b9341305d212d01f814c24338dadc08498000fcc4a6b6e8e1e7b27fc5cd7478c.wasm"
[DEBUG 18:12:37.445] proto_core::tool_loader  Loading WASM plugin  source="C:\\Users\\dan\\.proto\\plugins\\deno-0c576e3fa327e68fc1896e3eb15866c63f35d549fc5fc64ca1f22c271c1c2a9b.wasm"
[DEBUG 18:12:37.446] proto_core::tool_loader  Loading WASM plugin  source="C:\\Users\\dan\\.proto\\plugins\\pnpm-b9341305d212d01f814c24338dadc08498000fcc4a6b6e8e1e7b27fc5cd7478c.wasm"
[DEBUG 18:12:37.446] proto_core::tool_loader  Loading WASM plugin  source="C:\\Users\\dan\\.proto\\plugins\\python-d9edd08733791589cdb1a72ccb39494f6af46ce8f1c36a959635db26b2d1782b.wasm"
[DEBUG 18:12:37.446] proto_core::tool_loader  Loading WASM plugin  source="C:\\Users\\dan\\.proto\\plugins\\node-2c6c77c45d1bdb8f047e79502196bb8fd995504ce5c4c03a9d26b1f7c8b15d59.wasm"
[TRACE 18:12:37.447] warpgate::plugin  Storing plugin identifier  id="bun"
[TRACE 18:12:37.447] warpgate::plugin  Storing plugin identifier  id="yarn"
[TRACE 18:12:37.448] warpgate::plugin  Storing plugin identifier  id="deno"
[TRACE 18:12:37.448] warpgate::plugin  Storing plugin identifier  id="npm"
[TRACE 18:12:37.448] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\rust-040c7eeef51cbff67aad1bec847a49b15d6724dee002b9045f102180c0e72817.wasm"
[TRACE 18:12:37.449] warpgate::plugin  Storing plugin identifier  id="pnpm"
[TRACE 18:12:37.449] warpgate::plugin  Storing plugin identifier  id="python"
[TRACE 18:12:37.449] warpgate::plugin  Storing plugin identifier  id="node"
[TRACE 18:12:37.449] warpgate::plugin  Storing host environment  id="bun" env={"arch":"x64","libc":"unknown","os":"windows","home_dir":{"path":"/userhome/","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"}}
[TRACE 18:12:37.449] warpgate::plugin  Storing host environment  id="yarn" env={"arch":"x64","libc":"unknown","os":"windows","home_dir":{"path":"/userhome/","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"}}
[TRACE 18:12:37.450] warpgate::plugin  Storing host environment  id="deno" env={"arch":"x64","libc":"unknown","os":"windows","home_dir":{"path":"/userhome/","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"}}
[TRACE 18:12:37.450] warpgate::loader  Plugin already downloaded and cached  id="rust" path="C:\\Users\\dan\\.proto\\plugins\\rust-040c7eeef51cbff67aad1bec847a49b15d6724dee002b9045f102180c0e72817.wasm"
[TRACE 18:12:37.450] warpgate::plugin  Storing host environment  id="npm" env={"arch":"x64","libc":"unknown","os":"windows","home_dir":{"path":"/userhome/","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"}}
[TRACE 18:12:37.450] warpgate::plugin  Storing host environment  id="pnpm" env={"arch":"x64","libc":"unknown","os":"windows","home_dir":{"path":"/userhome/","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"}}
[TRACE 18:12:37.451] warpgate::plugin  Storing host environment  id="python" env={"arch":"x64","libc":"unknown","os":"windows","home_dir":{"path":"/userhome/","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"}}
[TRACE 18:12:37.451] warpgate::plugin  Storing host environment  id="node" env={"arch":"x64","libc":"unknown","os":"windows","home_dir":{"path":"/userhome/","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"}}
[DEBUG 18:12:37.452] proto_core::tool  Creating tool bun and instantiating plugin
[DEBUG 18:12:37.452] proto_core::tool  Creating tool yarn and instantiating plugin
[DEBUG 18:12:37.452] proto_core::tool  Creating tool deno and instantiating plugin
[DEBUG 18:12:37.452] proto_core::tool_loader  Loading WASM plugin  source="C:\\Users\\dan\\.proto\\plugins\\rust-040c7eeef51cbff67aad1bec847a49b15d6724dee002b9045f102180c0e72817.wasm"
[DEBUG 18:12:37.453] proto_core::tool  Creating tool pnpm and instantiating plugin
[DEBUG 18:12:37.453] proto_core::tool  Creating tool npm and instantiating plugin
[DEBUG 18:12:37.454] warpgate::client  Creating HTTP client
[DEBUG 18:12:37.454] proto_core::tool  Creating tool python and instantiating plugin
[DEBUG 18:12:37.454] proto_core::tool  Creating tool node and instantiating plugin
[TRACE 18:12:37.455] warpgate::plugin  Storing plugin identifier  id="rust"
[TRACE 18:12:37.455] warpgate::plugin  Storing host environment  id="rust" env={"arch":"x64","libc":"unknown","os":"windows","home_dir":{"path":"/userhome/","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"}}
[DEBUG 18:12:37.456] proto_core::tool  Creating tool rust and instantiating plugin
[DEBUG 18:12:37.459] warpgate::client  Created HTTP client
[TRACE 18:12:37.460] warpgate::plugin  Creating plugin container  id="rust"
[TRACE 18:12:37.460] warpgate::plugin  Creating plugin container  id="yarn"
[TRACE 18:12:37.460] warpgate::plugin  Creating plugin container  id="npm"
[TRACE 18:12:37.460] warpgate::plugin  Creating plugin container  id="bun"
[TRACE 18:12:37.460] warpgate::plugin  Creating plugin container  id="node"
[TRACE 18:12:37.460] warpgate::plugin  Creating plugin container  id="pnpm"
[TRACE 18:12:37.460] warpgate::plugin  Creating plugin container  id="deno"
[TRACE 18:12:37.460] warpgate::plugin  Creating plugin container  id="python"
[TRACE 18:12:37.484] warpgate::plugin  Created plugin container  id="bun" plugin="e38f73de-f9f9-464d-b38f-86e4bcdf4a69"
[TRACE 18:12:37.484] warpgate::plugin  Created plugin container  id="node" plugin="2c67be8d-b3da-4cb8-87c9-61e23310d451"
[TRACE 18:12:37.484] warpgate::plugin  Created plugin container  id="deno" plugin="54717592-c407-4187-a5f4-004b39e23150"
[TRACE 18:12:37.484] warpgate::plugin  Created plugin container  id="python" plugin="8db3fe24-d3ad-4a9c-87b2-05362fd14b1a"
[DEBUG 18:12:37.485] proto_core::tool  Created tool bun and its WASM runtime
[DEBUG 18:12:37.486] proto_core::tool  Created tool python and its WASM runtime
[TRACE 18:12:37.486] warpgate::plugin  Created plugin container  id="rust" plugin="1aeb586b-acde-4c93-9295-0c604ddc3a2c"
[DEBUG 18:12:37.486] proto_core::tool  Created tool node and its WASM runtime
[DEBUG 18:12:37.486] proto_core::tool  Created tool deno and its WASM runtime
[TRACE 18:12:37.487] warpgate::plugin  Calling guest function register_tool  id="bun" plugin="e38f73de-f9f9-464d-b38f-86e4bcdf4a69" input={"id":"bun"}
[TRACE 18:12:37.488] warpgate::plugin  Created plugin container  id="pnpm" plugin="1e2b9b5b-6df9-4979-9ce9-6caf23402361"
[DEBUG 18:12:37.489] proto_core::tool  Created tool rust and its WASM runtime
[TRACE 18:12:37.488] warpgate::plugin  Calling guest function register_tool  id="python" plugin="8db3fe24-d3ad-4a9c-87b2-05362fd14b1a" input={"id":"python"}
[TRACE 18:12:37.489] warpgate::plugin  Created plugin container  id="npm" plugin="6cf8629f-04d6-4296-a3da-aee51b74c01f"
[TRACE 18:12:37.489] warpgate::plugin  Created plugin container  id="yarn" plugin="21080f1a-6da9-486b-a10d-4859509ec689"
[TRACE 18:12:37.489] warpgate::plugin  Calling guest function register_tool  id="node" plugin="2c67be8d-b3da-4cb8-87c9-61e23310d451" input={"id":"node"}
[TRACE 18:12:37.489] warpgate::plugin  Calling guest function register_tool  id="deno" plugin="54717592-c407-4187-a5f4-004b39e23150" input={"id":"deno"}
[DEBUG 18:12:37.490] proto_core::tool  Created tool pnpm and its WASM runtime
[TRACE 18:12:37.490] warpgate::plugin  Called guest function register_tool  id="bun" plugin="e38f73de-f9f9-464d-b38f-86e4bcdf4a69" output={"config_schema":{"name":"BunPluginConfig","ty":{"type":"Struct","fields":{"dist-url":{"schema":{"ty":{"type":"String"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false}},"partial":false}},"inventory":{},"name":"Bun","plugin_version":"0.13.0","self_upgrade_commands":["upgrade"],"type":"Language"}
[TRACE 18:12:37.490] warpgate::loader  Loading plugin go  id="go" locator="https://github.com/moonrepo/tools/releases/download/go_tool-v0.13.0/go_tool.wasm"
[DEBUG 18:12:37.492] proto_core::tool  Created tool yarn and its WASM runtime
[DEBUG 18:12:37.492] proto_core::tool  Created tool npm and its WASM runtime
[TRACE 18:12:37.491] warpgate::plugin  Calling guest function register_tool  id="rust" plugin="1aeb586b-acde-4c93-9295-0c604ddc3a2c" input={"id":"rust"}
[TRACE 18:12:37.492] warpgate::plugin  Called guest function register_tool  id="python" plugin="8db3fe24-d3ad-4a9c-87b2-05362fd14b1a" output={"inventory":{},"name":"Python","plugin_version":"0.11.0","type":"Language"}
[TRACE 18:12:37.493] warpgate::plugin  Called guest function register_tool  id="node" plugin="2c67be8d-b3da-4cb8-87c9-61e23310d451" output={"config_schema":{"name":"NodePluginConfig","ty":{"type":"Struct","fields":{"bundled-npm":{"schema":{"ty":{"type":"Boolean"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false},"dist-url":{"schema":{"ty":{"type":"String"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false}},"partial":false}},"inventory":{},"name":"Node.js","plugin_version":"0.12.2","type":"Language"}
[TRACE 18:12:37.493] warpgate::plugin  Called guest function register_tool  id="deno" plugin="54717592-c407-4187-a5f4-004b39e23150" output={"config_schema":{"name":"DenoPluginConfig","ty":{"type":"Struct","fields":{"dist-url":{"schema":{"ty":{"type":"String"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false}},"partial":false}},"inventory":{},"name":"Deno","plugin_version":"0.12.0","self_upgrade_commands":["upgrade"],"type":"Language"}
[DEBUG 18:12:37.494] proto_core::tool_manifest  Loading manifest.json  file="C:\\Users\\dan\\.proto\\tools\\bun\\manifest.json"
[TRACE 18:12:37.494] warpgate::plugin  Calling guest function register_tool  id="pnpm" plugin="1e2b9b5b-6df9-4979-9ce9-6caf23402361" input={"id":"pnpm"}
[TRACE 18:12:37.495] warpgate::host  Calling host function get_env_var  plugin="1aeb586b-acde-4c93-9295-0c604ddc3a2c" name="RUSTUP_HOME"
[TRACE 18:12:37.495] warpgate::plugin  Calling guest function register_tool  id="yarn" plugin="21080f1a-6da9-486b-a10d-4859509ec689" input={"id":"yarn"}
[TRACE 18:12:37.495] warpgate::plugin  Calling guest function register_tool  id="npm" plugin="6cf8629f-04d6-4296-a3da-aee51b74c01f" input={"id":"npm"}
[DEBUG 18:12:37.496] proto_core::tool_manifest  Loading manifest.json  file="C:\\Users\\dan\\.proto\\tools\\python\\manifest.json"
[DEBUG 18:12:37.497] proto_core::tool_manifest  Loading manifest.json  file="C:\\Users\\dan\\.proto\\tools\\node\\manifest.json"
[TRACE 18:12:37.497] starbase_utils::fs  Opening file  file="C:\\Users\\dan\\.proto\\tools\\bun\\manifest.json"
[DEBUG 18:12:37.498] proto_core::tool_manifest  Loading manifest.json  file="C:\\Users\\dan\\.proto\\tools\\deno\\manifest.json"
[TRACE 18:12:37.498] starbase_utils::fs  Reading file metadata  file="C:\\Users\\dan\\.proto\\plugins\\go-f7e80cff695d64bd5aa1aab5c38ba0415543e1a65ff9f20db63496ff9b39c07b.wasm"
[TRACE 18:12:37.499] warpgate::host  Called host function get_env_var  plugin="1aeb586b-acde-4c93-9295-0c604ddc3a2c" value=""
[TRACE 18:12:37.497] warpgate::plugin  Called guest function register_tool  id="pnpm" plugin="1e2b9b5b-6df9-4979-9ce9-6caf23402361" output={"config_schema":{"name":"NodeDepmanPluginConfig","ty":{"type":"Struct","fields":{"dist-url":{"schema":{"ty":{"type":"String"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false},"shared-globals-dir":{"schema":{"ty":{"type":"Boolean"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false}},"partial":false}},"inventory":{},"name":"pnpm","plugin_version":"0.13.1","type":"DependencyManager"}
[TRACE 18:12:37.500] warpgate::plugin  Called guest function register_tool  id="yarn" plugin="21080f1a-6da9-486b-a10d-4859509ec689" output={"config_schema":{"name":"NodeDepmanPluginConfig","ty":{"type":"Struct","fields":{"dist-url":{"schema":{"ty":{"type":"String"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false},"shared-globals-dir":{"schema":{"ty":{"type":"Boolean"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false}},"partial":false}},"inventory":{},"name":"yarn","plugin_version":"0.13.1","type":"DependencyManager"}
[TRACE 18:12:37.500] starbase_utils::fs  Opening file  file="C:\\Users\\dan\\.proto\\tools\\node\\manifest.json"
[TRACE 18:12:37.501] starbase_utils::fs_lock  Locking file  file="C:\\Users\\dan\\.proto\\tools\\bun\\manifest.json"
[TRACE 18:12:37.500] warpgate::loader  Plugin already downloaded and cached  id="go" path="C:\\Users\\dan\\.proto\\plugins\\go-f7e80cff695d64bd5aa1aab5c38ba0415543e1a65ff9f20db63496ff9b39c07b.wasm"
[TRACE 18:12:37.501] starbase_utils::fs  Opening file  file="C:\\Users\\dan\\.proto\\tools\\deno\\manifest.json"
[TRACE 18:12:37.500] warpgate::plugin  Called guest function register_tool  id="npm" plugin="6cf8629f-04d6-4296-a3da-aee51b74c01f" output={"config_schema":{"name":"NodeDepmanPluginConfig","ty":{"type":"Struct","fields":{"dist-url":{"schema":{"ty":{"type":"String"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false},"shared-globals-dir":{"schema":{"ty":{"type":"Boolean"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false}},"partial":false}},"default_version":"bundled","inventory":{},"name":"npm","plugin_version":"0.13.1","type":"DependencyManager"}
[DEBUG 18:12:37.502] proto_core::tool_manifest  Loading manifest.json  file="C:\\Users\\dan\\.proto\\tools\\pnpm\\manifest.json"
[TRACE 18:12:37.502] warpgate::plugin  Called guest function register_tool  id="rust" plugin="1aeb586b-acde-4c93-9295-0c604ddc3a2c" output={"default_version":"stable","inventory":{"override_dir":{"path":"/userhome/.rustup/toolchains","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"},"version_suffix":"-x86_64-pc-windows-msvc"},"name":"Rust","plugin_version":"0.11.0","type":"Language"}
[DEBUG 18:12:37.503] proto_core::tool_loader  Loading WASM plugin  source="C:\\Users\\dan\\.proto\\plugins\\go-f7e80cff695d64bd5aa1aab5c38ba0415543e1a65ff9f20db63496ff9b39c07b.wasm"
[DEBUG 18:12:37.503] proto_core::tool_manifest  Loading manifest.json  file="C:\\Users\\dan\\.proto\\tools\\yarn\\manifest.json"
[TRACE 18:12:37.503] starbase_utils::fs_lock  Unlocking file  file="C:\\Users\\dan\\.proto\\tools\\bun\\manifest.json"
[TRACE 18:12:37.503] starbase_utils::fs_lock  Locking file  file="C:\\Users\\dan\\.proto\\tools\\deno\\manifest.json"
[TRACE 18:12:37.504] starbase_utils::fs_lock  Locking file  file="C:\\Users\\dan\\.proto\\tools\\node\\manifest.json"
[DEBUG 18:12:37.504] proto_core::tool_manifest  Loading manifest.json  file="C:\\Users\\dan\\.proto\\tools\\npm\\manifest.json"
[TRACE 18:12:37.505] starbase_utils::fs  Opening file  file="C:\\Users\\dan\\.proto\\tools\\pnpm\\manifest.json"
[DEBUG 18:12:37.505] proto_core::tool_manifest  Loading manifest.json  file="C:\\Users\\dan\\.proto\\tools\\rust\\manifest.json"
[TRACE 18:12:37.506] starbase_utils::fs_lock  Unlocking file  file="C:\\Users\\dan\\.proto\\tools\\deno\\manifest.json"
[TRACE 18:12:37.506] warpgate::plugin  Storing plugin identifier  id="go"
[TRACE 18:12:37.506] starbase_utils::fs_lock  Unlocking file  file="C:\\Users\\dan\\.proto\\tools\\node\\manifest.json"
[TRACE 18:12:37.507] starbase_utils::fs  Opening file  file="C:\\Users\\dan\\.proto\\tools\\npm\\manifest.json"
[TRACE 18:12:37.507] starbase_utils::fs_lock  Locking file  file="C:\\Users\\dan\\.proto\\tools\\pnpm\\manifest.json"
[DEBUG 18:12:37.507] proto_core::tool  Attempting to override inventory directory  tool="rust" override_virtual=WithReal { path: "/userhome/.rustup/toolchains", virtual_prefix: "/userhome", real_prefix: "C:\\Users\\dan" } override_real=Some("C:\\Users\\dan\\.rustup/toolchains")
[TRACE 18:12:37.508] warpgate::plugin  Storing host environment  id="go" env={"arch":"x64","libc":"unknown","os":"windows","home_dir":{"path":"/userhome/","virtual_prefix":"/userhome","real_prefix":"C:\\Users\\dan"}}
[TRACE 18:12:37.508] starbase_utils::fs_lock  Unlocking file  file="C:\\Users\\dan\\.proto\\tools\\pnpm\\manifest.json"
[TRACE 18:12:37.508] starbase_utils::fs_lock  Locking file  file="C:\\Users\\dan\\.proto\\tools\\npm\\manifest.json"
[DEBUG 18:12:37.509] proto_core::tool  Creating tool go and instantiating plugin
[TRACE 18:12:37.509] starbase_utils::fs_lock  Unlocking file  file="C:\\Users\\dan\\.proto\\tools\\npm\\manifest.json"
[TRACE 18:12:37.509] warpgate::plugin  Creating plugin container  id="go"
[TRACE 18:12:37.521] warpgate::plugin  Created plugin container  id="go" plugin="809b50df-9892-47da-906f-e4bc68bf49d1"
[DEBUG 18:12:37.521] proto_core::tool  Created tool go and its WASM runtime
[TRACE 18:12:37.522] warpgate::plugin  Calling guest function register_tool  id="go" plugin="809b50df-9892-47da-906f-e4bc68bf49d1" input={"id":"go"}
[TRACE 18:12:37.522] warpgate::plugin  Called guest function register_tool  id="go" plugin="809b50df-9892-47da-906f-e4bc68bf49d1" output={"config_schema":{"name":"GoPluginConfig","ty":{"type":"Struct","fields":{"dist-url":{"schema":{"ty":{"type":"String"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false},"gobin":{"schema":{"ty":{"type":"Boolean"}},"hidden":false,"nullable":false,"optional":true,"read_only":false,"write_only":false}},"partial":false}},"inventory":{},"name":"Go","plugin_version":"0.13.0","type":"Language"}
[DEBUG 18:12:37.523] proto_core::tool_manifest  Loading manifest.json  file="C:\\Users\\dan\\.proto\\tools\\go\\manifest.json"
[DEBUG 18:12:37.523] proto::commands::install  Detecting tool versions to install
[TRACE 18:12:37.524] warpgate::plugin  Calling guest function detect_version_files  id="yarn" plugin="21080f1a-6da9-486b-a10d-4859509ec689" input={}
[TRACE 18:12:37.524] warpgate::plugin  Called guest function detect_version_files  id="yarn" plugin="21080f1a-6da9-486b-a10d-4859509ec689" output={"files":["package.json"],"ignore":["node_modules"]}
[TRACE 18:12:37.525] proto_core::flow::resolve  Attempting to detect a version from directory  tool="yarn" dir="C:\\Users\\dan\\.proto"
[TRACE 18:12:37.525] warpgate::plugin  Calling guest function detect_version_files  id="rust" plugin="1aeb586b-acde-4c93-9295-0c604ddc3a2c" input={}
[TRACE 18:12:37.525] warpgate::plugin  Called guest function detect_version_files  id="rust" plugin="1aeb586b-acde-4c93-9295-0c604ddc3a2c" output={"files":["rust-toolchain.toml","rust-toolchain"]}
[TRACE 18:12:37.526] proto_core::flow::resolve  Attempting to detect a version from directory  tool="rust" dir="C:\\Users\\dan\\.proto"
[TRACE 18:12:37.526] warpgate::plugin  Calling guest function detect_version_files  id="go" plugin="809b50df-9892-47da-906f-e4bc68bf49d1" input={}
[TRACE 18:12:37.527] warpgate::plugin  Called guest function detect_version_files  id="go" plugin="809b50df-9892-47da-906f-e4bc68bf49d1" output={"files":["go.mod","go.work"]}
[TRACE 18:12:37.527] proto_core::flow::resolve  Attempting to detect a version from directory  tool="go" dir="C:\\Users\\dan\\.proto"
python ━━━━━━━━━━━━━━━━━━━━ |
  deno ━━━━━━━━━━━━━━━━━━━━ |
  pnpm ━━━━━━━━━━━━━━━━━━━━ |
python ━━━━━━━━━━━━━━━━━━━━ |
  deno ━━━━━━━━━━━━━━━━━━━━ | Installing Deno latest
python ━━━━━━━━━━━━━━━━━━━━ |
  deno ━━━━━━━━━━━━━━━━━━━━ | Installing Deno latest
  pnpm ━━━━━━━━━━━━━━━━━━━━ | Installing pnpm latest
python ━━━━━━━━━━━━━━━━━━━━ | Installing Python ~3.11
  deno ━━━━━━━━━━━━━━━━━━━━ | Installing Deno latest
  node ━━━━━━━━━━━━━━━━━━━━ |
  pnpm ━━━━━━━━━━━━━━━━━━━━ | Installing pnpm latest
python ━━━━━━━━━━━━━━━━━━━━ | Installing Python ~3.11
  deno ━━━━━━━━━━━━━━━━━━━━ | Installing Deno latest
  node ━━━━━━━━━━━━━━━━━━━━ | Installing Node.js 22.9.0
python ━━━━━━━━━━━━━━━━━━━━ | Installing Python ~3.11
   bun ━━━━━━━━━━━━━━━━━━━━ |
  deno ━━━━━━━━━━━━━━━━━━━━ | Installing Deno latest
  node ━━━━━━━━━━━━━━━━━━━━ | Installing Node.js 22.9.0
python ━━━━━━━━━━━━━━━━━━━━ | Installing Python ~3.11
   bun ━━━━━━━━━━━━━━━━━━━━ | Installing Bun latest
  deno ━━━━━━━━━━━━━━━━━━━━ | Installing Deno latest
  node ━━━━━━━━━━━━━━━━━━━━ | Installing Node.js 22.9.0
  pnpm ━━━━━━━━━━━━━━━━━━━━ | Installing pnpm latest
   npm ━━━━━━━━━━━━━━━━━━━━ | Installing npm 10.9.0
[DEBUG 18:12:37.571] proto_core::flow::resolve  Resolving a semantic version or alias  tool="node" initial_version="22.9.0"
[TRACE 18:12:37.571] warpgate::host  Calling host function send_request  plugin="6cf8629f-04d6-4296-a3da-aee51b74c01f" input={"url":"https://registry.npmjs.org/npm/"}
[TRACE 18:12:37.571] warpgate::plugin  Calling guest function load_versions  id="deno" plugin="54717592-c407-4187-a5f4-004b39e23150" input={"initial":"latest"}
[DEBUG 18:12:37.572] proto_core::flow::resolve  Loading available versions  tool="python"
[DEBUG 18:12:37.573] proto_core::flow::resolve  Loading available versions  tool="node"
[TRACE 18:12:37.573] warpgate::plugin  Calling guest function load_versions  id="pnpm" plugin="1e2b9b5b-6df9-4979-9ce9-6caf23402361" input={"initial":"latest"}
[DEBUG 18:12:37.574] extism::pdk  Loading Git tags from remote https://github.com/denoland/deno  plugin="54717592-c407-4187-a5f4-004b39e23150"
[DEBUG 18:12:37.574] proto_core::flow::resolve  Resolving a semantic version or alias  tool="bun" initial_version="latest"
[TRACE 18:12:37.574] warpgate::plugin  Calling guest function load_versions  id="python" plugin="8db3fe24-d3ad-4a9c-87b2-05362fd14b1a" input={"initial":"~3.11"}
[DEBUG 18:12:37.576] proto_core::flow::resolve  Loading available versions  tool="bun"
[TRACE 18:12:37.575] warpgate::host  Calling host function send_request  plugin="1e2b9b5b-6df9-4979-9ce9-6caf23402361" input={"url":"https://registry.npmjs.org/pnpm/"}
[TRACE 18:12:37.576] warpgate::host  Calling host function exec_command  plugin="54717592-c407-4187-a5f4-004b39e23150" input={"command":"git","args":["ls-remote","--tags","--sort","version:refname","https://github.com/denoland/deno"],"env":{},"set_executable":false,"stream":false,"working_dir":null}
[TRACE 18:12:37.575] warpgate::plugin  Calling guest function load_versions  id="node" plugin="2c67be8d-b3da-4cb8-87c9-61e23310d451" input={"initial":"22.9.0"}
[DEBUG 18:12:37.576] extism::pdk  Loading Git tags from remote https://github.com/python/cpython  plugin="8db3fe24-d3ad-4a9c-87b2-05362fd14b1a"
[TRACE 18:12:37.577] warpgate::plugin  Calling guest function load_versions  id="bun" plugin="e38f73de-f9f9-464d-b38f-86e4bcdf4a69" input={"initial":"latest"}
[TRACE 18:12:37.578] warpgate::host  Calling host function send_request  plugin="2c67be8d-b3da-4cb8-87c9-61e23310d451" input={"url":"https://nodejs.org/download/release/index.json"}
python ━━━━━━━━━━━━━━━━━━━━ | Installing Python ~3.11
   bun ━━━━━━━━━━━━━━━━━━━━ | Installing Bun latest
  node ━━━━━━━━━━━━━━━━━━━━ | Installing Node.js 22.9.0
  pnpm ━━━━━━━━━━━━━━━━━━━━ | Installing pnpm latest
   bun ━━━━━━━━━━━━━━━━━━━━ | Installing Bun latest
  node ━━━━━━━━━━━━━━━━━━━━ | Installing Node.js 22.9.0
  pnpm ━━━━━━━━━━━━━━━━━━━━ | Installing pnpm latest
   npm ━━━━━━━━━━━━━━━━━━━━ | Installing npm 10.9.0[TRACE 18:12:37.581] starbase::app  Running shutdown phase (because another phase failed)
Error:   × Main thread panicked.
  ├─▶ at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\tokio-
  │   1.40.0\src\runtime\time\entry.rs:568:9
  ╰─▶ A Tokio 1.x context was found, but it is being shutdown.
         0: 0x7ff7e39b6cca - <unresolved>
         1: 0x7ff7e39b6c1b - <unresolved>
         2: 0x7ff7e3dd89b0 - <unresolved>
         3: 0x7ff7e3dc160c - <unresolved>
         4: 0x7ff7e3dd3505 - <unresolved>
         5: 0x7ff7e3a43b09 - <unresolved>
         6: 0x7ff7e43fc255 - <unresolved>
         7: 0x7ff7e3dd7aec - <unresolved>
         8: 0x7ff7e44072cb - <unresolved>
         9: 0x7ff7e4407166 - <unresolved>
        10: 0x7ff7e4404c0f - <unresolved>
        11: 0x7ff7e4406d36 - <unresolved>
        12: 0x7ff7e493e904 - _jit_debug_register_code
        13: 0x7ff7e49847be - _jit_debug_register_code
        14: 0x7ff7e44407c8 - <unresolved>
        15: 0x7ff7e42bf228 - <unresolved>
        16: 0x7ff7e45201d6 - <unresolved>
        17: 0x7ff7e44fc679 - <unresolved>
        18: 0x7ff7e3ce26d3 - <unresolved>
        19: 0x7ff7e3c68054 - <unresolved>
        20: 0x24036b9592f - <unresolved>
        21: 0x24036a20965 - <unresolved>
        22: 0x24036b66145 - <unresolved>
        23: 0x24036b95021 - <unresolved>
        24: 0x7ff7e4891dc3 - _jit_debug_register_code
        25: 0x7ff7e3f6245a - <unresolved>
        26: 0x7ff7e3fc3702 - <unresolved>
        27: 0x7ff7e3fc16ca - <unresolved>
        28: 0x7ff7e3fbe551 - <unresolved>
        29: 0x7ff7e3e4eaec - <unresolved>
        30: 0x7ff7e3e4e385 - <unresolved>
        31: 0x7ff7e3e49acb - <unresolved>
        32: 0x7ff7e3e48f3a - <unresolved>
        33: 0x7ff7e404d111 - <unresolved>
        34: 0x7ff7e404cc3e - <unresolved>
        35: 0x7ff7e4055a9d - <unresolved>
        36: 0x7ff7e3f54f73 - <unresolved>
        37: 0x7ff7e44362dd - <unresolved>
        38: 0x7ff7e443543b - <unresolved>
        39: 0x7ff7e443a61c - <unresolved>
        40: 0x7ff7e442ee64 - <unresolved>
        41: 0x7ff7e442f846 - <unresolved>
        42: 0x7ff7e441598d - <unresolved>
        43: 0x7ffa2990dbe7 - BaseThreadInitThunk
        44: 0x7ffa2a8c5a4c - RtlUserThreadStart
  help: set the `RUST_BACKTRACE=1` environment variable to display a backtrace.

Operating system?
Windows
Architecture?
x64

We actually error when the command doesn't exist on the machine: https://github.com/moonrepo/proto/blob/master/crates/warpgate/src/host.rs#L165
So I'm not entirely sure git missing was the problem here.

I can see now that uninstalling git and trying again, I get the more comprehensible error:

Error: plugin::call_func::failed
× Command or script git does not exist. Unable to execute from plugin.

So I'm not sure what the original issue was either and I can't repeat it as such.
Maybe it had something to do with this. It looks like maybe we're qualifying pwsh by its full path and extension but not powershell:
https://github.com/moonrepo/proto/blob/fbba5f20e540a86308ac8db6ba026d7501d3f940/crates/system-env/src/helpers.rs#L107-L108

Hrmm that's even more weird. Anytime I see the "A Tokio 1.x context was found, but it is being shutdown." error, I always assume Rust async just crashed in some weird way. I'm not even sure how to reproduce that.

I think it means that we're ending the program with some task is still in process.
Here's the relevant doc afaict. Hopefully, it makes more sense to you: https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.html#method.block_on

Runs a future to completion on this Handle’s associated Runtime.
This runs the given future on the current thread, blocking until it is complete, and yielding its resolved result. Any tasks or timers which the future spawns internally will be executed on the runtime.
When this is used on a current_thread runtime, only the Runtime::block_on method can drive the IO and timer drivers, but the Handle::block_on method cannot drive them. This means that, when using this method on a current_thread runtime, anything that relies on IO or timers will not work unless there is another thread currently calling Runtime::block_on on the same runtime.
If the runtime has been shut down
If the Handle’s associated Runtime has been shut down (through Runtime::shutdown_background, Runtime::shutdown_timeout, or by dropping it) and Handle::block_on is used it might return an error or panic. Specifically IO resources will return an error and timers will panic. Runtime independent futures will run as normal.
Panics
This function panics if the provided future panics, if called within an asynchronous execution context, or if a timer future is executed on a runtime that has been shut down.

In particular, I don't understand how exec_command and send_request in warpgate host.rs and call in plugin.rs let the caller know that subprocess is complete (whether succeeded or failed) and it's safe to shut down now.
In terms of the logging above, I see a lot of "Calling host function" and not a lot of "Called host function". To make sense of the trace, (1) these should have some correlation ID unique to each call of exec_command so you can tell which end corresponds to which start (2) if the block ends with a premature return using ?, there's no way to know whether the task is still in flight.
Maybe some of the above is what #[instrument(name = "host_func_exec_command", skip_all)] is for and the issue template/troubleshooting tools should recommend using --dump or PROTO_DUMP? I wish I had gotten that output when I could reproduce the bug!

In particular, I don't understand how exec_command and send_request in warpgate host.rs and call in plugin.rs let the caller know that subprocess is complete (whether succeeded or failed) and it's safe to shut down now.

I agree, there's non-ideal layers here. However, extism (the plugin layer) is synchronous, so in this context, we don't need to wait for anything in the context of tokio/async. So if anything in extism errors, it just bubbles up.
The exception to this is send_request, which must spawn a blocking task in tokio, because reqwest requires tokio. This requirement is super annoying, but no other work around until extism supports async.

In terms of the logging above, I see a lot of "Calling host function" and not a lot of "Called host function". To make sense of the trace, (1) these should have some correlation ID unique to each call of exec_command so you can tell which end corresponds to which start (2) if the block ends with a premature return using ?, there's no way to know whether the task is still in flight.

Is the plugin field not enough data? That's already a UUID.

Maybe some of the above is what #[instrument(name = "host_func_exec_command", skip_all)] is for and the issue template/troubleshooting tools should recommend using --dump or PROTO_DUMP? I wish I had gotten that output when I could reproduce the bug!

These labels were in the logs before but it added sooo much noise that it became hard to read. So yeah, right now they are just in the dumps. I can maybe add an env var or something that toggles them on.

Added --log verbose in v0.41.5

I think I might have experienced similar, but with proto install which I understand replaces proto use. I got the same error, so I tried installing each tool individually instead, in the form proto install rust 1.78.0 etc (for each tool and version in my .prototools file. I had the odd failure of node not installing, for the same reason as #615 actually - where an HTTP request failed. Another due to my own plugin not supporting ARM on Linux.
So I wonder is this error because proto install spawns off multiple async processes to install each tool, and if one tool fails to install for one of the above reasons, then we're seeing this error?
I'll do some more investigataion myself, but wanted to braindump my initial findings in case it helps.

So I wonder is this error because proto install spawns off multiple async processes to install each tool, and if one tool fails to install for one of the above reasons, then we're seeing this error?

Yeah. Anytime a command has to process multiple tools, either loading or executing something, it's always done in parallel, 1 tool per 1 thread.
I try to provide human-readable error messages everywhere I can, so if something seems cryptic, or a panic occurs, that's usually somewhere outside of proto, most likely in a 3rd party library or the WASM layer.

I don't see anything like TaskTracker and CancellationToken in the proto code. Here's how the tokio docs recommend shutting down: https://tokio.rs/tokio/topics/shutdown

I use JoinSets, which are very similar: https://docs.rs/tokio/latest/tokio/task/struct.JoinSet.html
I'm not sure a cancellation token would even help here with the panic in the original post.

I use JoinSets, which are very similar: https://docs.rs/tokio/latest/tokio/task/struct.JoinSet.html

It even has a comparison to JoinSet! Gosh I'm jealous of the Rust ecosystem and its documentation!

I'm not sure a cancellation token would even help here with the panic in the original post.

I think I need a trace catching the panic red-handed :-/. My backtrace is unfortunately not very useful. I'm reinstalling proto with cargo install --git https://github.com/moonrepo/proto.git proto_cli --debug --root $HOME/.proto --force to hopefully catch a better backtrace next time!

So digging into potential failures when installing a tool. I'm currently testing this on Windows, and when trying to install all tools, I was getting the panic and failure, so again, I try and install each tool individually. I just received this:
proto install node 20.12.2
Installing Node.js
Downloading pre-built archive
Error: net::http
  × Failed to make HTTP request for https://nodejs.org/download/release/
  │ v20.12.2/node-v20.12.2-win-x64.zip.
  ├─▶ error decoding response body
  ├─▶ error reading a body from connection
  ╰─▶ stream error received: unexpected internal error encountered

It might be the case that this is a different error to when I tried to just run proto install - but is there a reason why I don't get friendly errors currently, and only the tokio panic? It would at least be helpful when running proto install to know which tool failed, but perhaps, continue installing the others anyway?
Will continue to add any extra information I find - and also happy to help in any way I can. Currently trying to get some self-hosted GitHub Action runners setup across all platforms (macOS, Windows and Linux/Ubuntu), and proto will make this so much easier 🙏 - I really appreciate this tool and all it offers!

Yeah at least for proto install, I can look into not failing the entire install if 1 tool fails.

FYI the underlying connection issue I was encountering was down to DNS within a Windows VM: https://github.com/moonrepo/proto/issues/615#issuecomment-2422395741
But aside from that, the improvements to the error messages you mentioned above would be a great addition.

I updated the error handling for proto install in v0.43. Gonna close this for now. Feel free to create a new issue if it pops up again.


Localisation msf arch64 build

I did a fresh build using arch64 docker dev environment and I hitting this error:
Execution platform: @local_config_platform//:host
In file included from ./modules/localization/msf/msf_localization.h:42:0,
from modules/localization/msf/msf_localization.cc:17:
./modules/localization/msf/local_integ/localization_integ.h:24:10: fatal error: localization_msf/gnss_struct.h: No such file or directory
#include "localization_msf/gnss_struct.h"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Checking on third party directory seems like it lacks the localization_msf includes and libs for  arch64 (only x86_64 dir is in place).
Any idea why this is not present for arch64 and how I should install it or is there any way to avoid this ?

I also had the same problem，i use jetson nx

I also had the same problem,have you solved it

locailization msf component currently only support x86_64

locailization msf component currently only support x86_64. If you don't need locailization msf component, remove msf dir in localization, and try to build again to avoid this


:sparkles: Upgrade to Remix 2 [Spike]

This PR is a spike to see whether we can upgrade to Remix 2, timeboxed to three days.
I will spend a few days (3) maximum in this direction before evaluating whether this can be made into a prototype or we need to rethink e.g using Next.js' static exports feature.
Context
We are currently pinned on an old version of Remix due to an infinite-reload bug for static exports. We cannot upgrade without breaking static exports (required for RTD, GitHub pages).

As per usual, this is much harder than it should be because of weird dependency graphs and poor module support.
It looks like<EMAIL_ADDRESS>pulls in<EMAIL_ADDRESS>instead of 5.0.0, which conflicts with our requested version. I somehow fixed it temporarily, but it resolves to this solution.
Before this problem, I was struggling to deal with react-syntax-highlighting, which seems to be picked up as a CJS dependency despite the imports using the ESM entry

OK, hacking around that by dropping syntax highlighting and overriding the vite version. Now it loads a page, but complains about mixing server and client code

OK, at this point myst-theme mostly works; I ripped out syntax highlighting (and probably broke some other things).
Findings
SPA Mode
The code that introduced the reload behaviour has since been modified to support Remix V2's SPA mode. If we wanted to upgrade Remix, we could do so iff. we found a way to use SPA mode to generate our static exports. Generating an SPA is a useful output for MyST, but it is not the best-case scenario for static exports; client-side SPAs introduce the "white-flash" loading screen, and have a long-time to meaningful first paint.
SSR-SPA
However, underpinning Remix 2's SPA mode is the clientLoader mechanism. It looks like the clientLoader can be used to build an SSR-SPA.[^ssr-spa]. This would be an improvement over our existing SSR MPA, because we could perform link-prefetching (and other goodies!). I assume given the existence of this repo, the problem associated with #184 does not cause issues, but I don't have enough of the context to be certain.
Vite
Another benefit of this upgrade, though, is that Remix now intends to use Vite for the server (faster, more plugins, etc).
[^ssr-spa]: A server-side-rendered single-page-application - each route has a dedicated HTML page, but once that page loads, navigation between pages is performed as an SPA (not loading HTML!) This is faster and supports fun optimistions.

@rowanc1 / @stevejpurves do you recall #184 well enough to know whether the approach taken in https://github.com/brophdawg11/remix-ssg/tree/main/demos/ssg-spa-client-loaders would work?

Given that this is a pretty complex PR (-2000 / +2000) I suggest that we try to decide whether it should get over the finish line or not, otherwise I worry it is going to become stale very quickly.
@agoose77 what is the information that you need in order to decide whether this spike is worth implementing entirely, or whether it's best to pursue other strategies for improving the static site workflow?

@choldgraf the line diff is deceptive; most of the changed lines are in the lock file.
Given the rate of change in myst-theme, I think it will be fairly stable. At this point, I think the spike is close to done - the final day I've allocated to it will see whether static exports work (either with the remix server or vite). That will conclude the spike, and following feedback from the MyST team, we should have an idea of where to go next.


Improve default date handling.

This PR is more of a workaround than an actual fix to this issue, but at the very least it should start some discussion about the best way to handle this problem.
The DefectDojo Finding model defaults to the current date for the date that a finding was discovered. This is a reasonable default, but the problem comes later when the model is processed. Depending on which re-import endpoint you call, something different can happen:

Web UI: If the finding was discovered on the current date, then the test start date is used.
API v1: The test start date is always used.
API v2: The scan date is always used.

This PR will make it so that regardless of how a scan is re-imported, the finding date will always be used as long as the scan importer provided it. If the date is the default, then it uses the start date from the test. It does so by creating a DefaultDate subclass of the datetime object, which we can check for but behaves identically to a normal datetime object in all other ways.
Caveats:

Does not fix API v1 Scan Import (Only Re-Import).
Does not fix Web UI Scan Import (Only Re-Import).
This, in the current form, completely breaks the database migration generator.

These caveats can be addressed if this solution is one we would like to implement.

Thanks for the PR... But.... if we need this kind of complexity for a default date, I think we (so not you) are doing something wrong :-) I think we should just take "today" if there is no date available in the scan report nor something specified in the requests coming in to the APIv2 or to the backend for the WebUI. Is that possible?

I think we should just take "today" if there is no date available in the scan report

The finding defaults to the current date, so removing the code in the import handlers that sets the date to the target_start date (or other variants) would solve this easily with no special DefaultDate class.

wdyt @mtesauro @devGregA

There definitely needs to be some sort of homogeneity with how dates are handled, but I think adding a new class to handle this is a little overkill. Just make the default date today and call it a day.

@iwalton3 can you adjust the PR to do just that? seems like you are in the know now of where and when :-)

@iwalton3 if you merg upstream dev into this branch, it will pick up the new workflow definition and stop tests from failing


Kernel BUG on probe

I am experiencing a kernel BUG at Coyote/driver/fpga_dev.c:108 (accl_integration branch)
I am currently using an Alveo U280. Linux Kernel: 6.5
My steps:

I made sure that coyote driver was not loaded
I used Vivado Hardware Manager 2022.2 to load the bitstream
I ran sw/util/hot_reset
lspci | grep Xilinx shows that the board is correctly identified
I launch sudo insmod coyote_drv.ko

This last command hangs, because of the kernel bug.
I also experienced this error previously, with the same setup apart from the Linux kernel, which was 5.15

Some time before this error happened, I experienced another error: AMD-Vi IO_PAGE_FAULT, while I was launching the test.cpp file with options -f -r. This error happened before any test functions were actually run


Recreating network should not recreate running node containers

When a user deletes a network and creates a new one, errors are reported by both the api-engine and docker-agent. This issue arises because whenever a network is created, containers are also created for all nodes belonging to the current organization. You can refer to the relevant code here.
Due to Docker's restrictions, it is not possible to send "create" requests to existing containers, resulting in the following error. One possible solution is to filter the not running nodes on this line.
api-engine error:
Exception in thread Thread-79:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.8/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/var/www/server/api/routes/network/views.py", line 160, in _start_node
    raise e
  File "/var/www/server/api/routes/network/views.py", line 158, in _start_node
    raise ResourceNotFound(detail="Container Not Built")
api.exceptions.ResourceNotFound: Container Not Built

docker-agent error:
ERROR:server:Exception on /api/v1/nodes [POST]
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/docker/api/client.py", line 268, in _raise_for_status
    response.raise_for_status()
  File "/usr/local/lib/python3.8/site-packages/requests/models.py", line 1021, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 409 Client Error: Conflict for url: http+docker://localhost/v1.41/containers/create?name=real-peer-20.node1.cello.com

The above exception was the direct cause of the following exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 2190, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1486, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1484, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1469, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
  File "/var/www/server/server.py", line 89, in create_node
    container = client.containers.run(
  File "/usr/local/lib/python3.8/site-packages/docker/models/containers.py", line 858, in run
    container = self.create(image=image, command=command,
  File "/usr/local/lib/python3.8/site-packages/docker/models/containers.py", line 917, in create
    resp = self.client.api.create_container(**create_kwargs)
  File "/usr/local/lib/python3.8/site-packages/docker/api/container.py", line 431, in create_container
    return self.create_container_from_config(config, name, platform)
  File "/usr/local/lib/python3.8/site-packages/docker/api/container.py", line 448, in create_container_from_config
    return self._result(res, True)
  File "/usr/local/lib/python3.8/site-packages/docker/api/client.py", line 274, in _result
    self._raise_for_status(response)
  File "/usr/local/lib/python3.8/site-packages/docker/api/client.py", line 270, in _raise_for_status
    raise create_api_error_from_http_exception(e) from e
  File "/usr/local/lib/python3.8/site-packages/docker/errors.py", line 39, in create_api_error_from_http_exception
    raise cls(e, response=response, explanation=explanation) from e

docker.errors.APIError: 409 Client Error for http+docker://localhost/v1.41/containers/create?name=real-peer-20.node1.cello.com: Conflict ("Conflict. The container name "/real-peer-20.node1.cello.com" is already in use by container "4c97783b97b4ad987ba62961fe642c53efbb3cc5bd96d2cbb3724796321b5a03". You have to remove (or rename) that container to be able to reuse that name.")

When creating "existed" containers, is it possible to identify such case based on the docker engine's response msg?
If so, we could just ignore the error and return OK.