Performance regression on Sysbench between Feb 10 and Feb 28

Bug Report
In #6962, we found that unify read pools caused a serious performance regression on TPCH. Yesterday, when we look back on Sysbench performance, we saw there existed a performance drop, and we found it maybe also caused by d2af249.
Moreover, the fix PR doesn't take effect on Sysbench regression.

$ lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                40
On-line CPU(s) list:   0-39
Thread(s) per core:    2
Core(s) per socket:    10
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 79
Model name:            Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz
Stepping:              1
CPU MHz:               2027.990
CPU max MHz:           3100.0000
CPU min MHz:           1200.0000
BogoMIPS:              4400.04
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cdp_l3 intel_pt ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts spec_ctrl intel_stibp

Profile: profile.svg.zip

I don't think the regression is as severe as it looks like.
In addition to the issue description, it's one TiDB instance and one TiKV instance running on the same server in this benchmark. The CPU resource on the machine is exhausted.
From the flamegraph, we can see it takes a lot of time in steal_batch_and_pop. It means lots of threads are fighting for the same global task queue. It usually happens when tasks are few (because if threads are busy handling requests they don't have time to seize the queue) so we can accept the waste of resource in most cases. But in this case, the bottleneck is the total CPU resource of the machine. The waste here leads to performance regression.
Potential improvements:

Adaptive running thread count. It can be beneficial for some real cases but may not necessarily solve this issue. The running TiDB can disturb the strategy of releasing more threads for running.
Limit the maximum number of threads which share the same global task queue to reduce contension if the thread number in the pool is considerable. NUMA-awareness can be also taken into consideration.

/cc @BusyJay

Low price node can also benefit from fixing the issue. Maybe yatp can maintain a global task count as an epoch to avoid false fetch.


Display service out-of-sync info and allow to approve/decline deployment

Highlight services that are out-of-sync and show the deployable artifacts for that service

Codecov Report

Merging #1877 into master will decrease coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1877      +/-   ##
==========================================
- Coverage   32.26%   32.17%   -0.10%
==========================================
  Files          99       99
  Lines        7659     7659
==========================================
- Hits         2471     2464       -7
- Misses       4870     4875       +5
- Partials      318      320       +2

Impacted Files
Coverage Δ

api/ws/hub.go
62.50% <0.00%> (-14.29%)
:arrow_down:

distributor/cmd/main.go
58.88% <0.00%> (+1.11%)
:arrow_up:

Continue to review full report at Codecov.

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

DO NOT MERGE YET since this requires the switch to the public API (#1833) to fetch the deployable artifacts from the API (get open approval events)

If there is no services onboarded yet, The bridge shows a different message with a link to instructions "how to onboard a service". This message is displayed in the "services" and in the "environment" tab. See images below.

When there is a service onboarded, but no deployment available yet on that stage, then I show the instructions how to deploy a service using "keptn send new-artifact".

When there is an sh.keptn.event.approval.triggered event, that hasn't been approved/declined yet, the bridge displays that service in the "environment" tab as "out-of-sync". Furthermore it shows those approvals as "artifacts" that can be deployed by approving that deployment. A deployment can also be declined.

If there is no services onboarded yet, The bridge shows a different message with a link to instructions "how to onboard a service". This message is displayed in the "services" and in the "environment" tab. See images below.
When there is a service onboarded, but no deployment available yet on that stage, then I show the instructions how to deploy a service using "keptn send new-artifact".

Recently we also had a discussion about such assistance and we decided to also show them when data is available. Maybe you also want to discuss having e.g. an Info-Button with a link to keptn-docs? Reason: E.g. if a long time has passed since you last onboarded a service, you probably have forgotten how it worked and so you have data but still want a quick info or link to the docs

If there is no services onboarded yet, The bridge shows a different message with a link to instructions "how to onboard a service". This message is displayed in the "services" and in the "environment" tab. See images below.
When there is a service onboarded, but no deployment available yet on that stage, then I show the instructions how to deploy a service using "keptn send new-artifact".

Recently we also had a discussion about such assistance and we decided to also show them when data is available. Maybe you also want to discuss having e.g. an Info-Button with a link to keptn-docs? Reason: E.g. if a long time has passed since you last onboarded a service, you probably have forgotten how it worked and so you have data but still want a quick info or link to the docs

Thanks @sandroschmid for sharing this with us. We actually have already an issue on that topic, #1635 and I would like to address that with that issue.


Make the Settings Model tests into proper CI tests

This pull request removes the need for the SettingsModel tests to run in
a UAP harness and puts them into the standard CI rotation.
This required some changes to Run-Tests.ps1 to ensure that the right
te.exe is selected for each test harness. It's a bit annoying, but for
things that depend on a resources.pri, that file must be in the same
directory as the EXE that is hosting the test. Not the DLL, mind you,
the EXE. In our case, that's TE.ProcessHost.exe
The bulk of the change is honestly namespace tidying.

I'd like to merge these green :)
@zadjii-msft would you be able to look into the profile icon failure?
@lhecker would you mind looking at the commandline normalization failure? We have seen smth like this before

expected: C:\Users\SHINET~1\AppData\Local\Temp\be8dba0d-abb9-45b0-b352-cdf6dea84b45 two\file 2.exe
actual: C:\Users\ShineTest\AppData\Local\Temp\be8dba0d-abb9-45b0-b352-cdf6dea84b45 two\file 2.exe

The good news is that the path normalization worked! The bad news is that the CI's hostname is too long.

@lhecker yay! that worked! Now it's just Mike's 🥲

Done. I absolutely adore that these can run in CI now


Add DEM class init through same or parent class + tests

See here for description: https://github.com/GlacioHack/GeoUtils/pull/118

Resolves #47


Assets using absoulte url

Describe the bug
When publishing the filament assets using php artisan vendor:publish --tag=filament-assets the assets are copied to /public/vendor/filament but the assets when loading the admin pages are still using the absolute url rather than the vendor folder path.
Expected behavior
The asset urls should be updated to point to the vendor folder.

Hey, this is expected behaviour as the vendor folder will override package files - the absolute URL should not be changed.

Hi @danharrin, so publishing the assets is effectively useless as the vendor files are never picked up.
Am I missing something? Using the absolute url it's always using the laravel routes rather than servering from the webserver

Can you publish a repository demonstrating this issue please?


Data binding

How is the data bound in the form. Specifically is it two way and reactive. Does changing field inputs update the form automatically?

Just listen for the submit event. Not using 2-way binding is better for accessibility, speed, and more.

It looks like it should be reactive

We're currently addressing a backlog of GitHub issues. Closing this thread as it is outdated. Please re-open if it is still relevant. Thank you for your contribution!


Fix codecov support

Purpose

Fix codecov support

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@0004674). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #322   +/-   ##
=========================================
  Coverage          ?   46.48%
=========================================
  Files             ?       28
  Lines             ?      712
  Branches          ?       48
=========================================
  Hits              ?      331
  Misses            ?      350
  Partials          ?       31

Continue to review full report at Codecov.

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


Other awks don't print trailing zeros when printing floats.

Other awks don't print trailing zeros when printing floats.
This feature would be great to have in frawk too as now when adding an integer value to a column which contained an integer will give you back a float which is quite annoying in my usecase.
I have for example BED files with chromosomal coordinates in column 2 and 3.
chr1	1000	2000	...

Like shown here, those intervals are extended:
https://github.com/ghuls/extendBed/blob/master/extendBed.sh
Test case:
for AWK in frawk gawk mawk; do
    echo "${AWK}:";
    echo '1 9.0 5.5 6.600' | ${AWK} '
        BEGIN { OFS="\t" }
        {
            print "column 1:", $1, $1 + 0, 0 + $1, $1 + 1.0;
            print "column 2:", $2, $2 + 0, 0 + $2, $2 + 1.0;
            print "column 3:", $3, $3 + 0, 0 + $3, $3 + 0.5;
            print "column 4:", $4, $4 + 0, 0 + $4, $4 + 0.4;
        }';
    echo;
done

frawk:
column 1:	1	1.0	1.0	2.0
column 2:	9.0	9.0	9.0	10.0
column 3:	5.5	5.5	5.5	6.0
column 4:	6.600	6.6	6.6	7.0

gawk:
column 1:	1	1	1	2
column 2:	9.0	9	9	10
column 3:	5.5	5.5	5.5	6
column 4:	6.600	6.6	6.6	7

mawk:
column 1:	1	1	1	2
column 2:	9.0	9	9	10
column 3:	5.5	5.5	5.5	6
column 4:	6.600	6.6	6.6	7

I think this is a reasonable ask. I initially thought this was going to make the semantics more explicit, but I've also found it annoying using frawk day to day. I'll see about (a) modifying what ryu is doing when the float has an exact integer representation (b) special-casing floating point rendering for this setting or (c) migrating to a different float rendering library/algorithm. I'm thinking (b), as checking if a float can be represented exactly as an integer is pretty cheap, and (e.g.) dtoa, while potentially interesting on its own, seems to also append ".0" in the same cases.

I think this is a reasonable ask. I initially thought this was going to make the semantics more explicit, but I've also found it annoying using frawk day to day. I'll see about (a) modifying what ryu is doing when the float has an exact integer representation (b) special-casing floating point rendering for this setting or (c) migrating to a different float rendering library/algorithm. I'm thinking (b), as checking if a float can be represented exactly as an integer is pretty cheap, and (e.g.) dtoa, while potentially interesting on its own, seems to also append ".0" in the same cases.

It might be worth to open a feature request to allow stripping all trailing zeros for those crates.

It might be worth to open a feature request to allow stripping all trailing zeros for those crates.

I'm closing this PR in light of #44, thanks for the contribution!


Add LittleIpsum v1.1.2

LittleIpsum was removed in #12975. 1.1.2 is an outdated version and the latest version is not available so we cannot accept this. You may be able to put this in caskroom/hombrew-versions.

Thank you for your contribution. However, the @scribblemaniac is right and we can't accept this. The latest version of LittleIpsum is 2.0.5 and only officially available in the AppStore at the moment.
You can still make a PR to add this as littleipsum1.rb (note that the "1" is necessary and represents the version) in caskroom/hombrew-versions.

Thansk for your feedback!
I totally appreciate the decision and I'll make a PR in hombrew/versions.


Add copy and paste hot keys

It would be nice if I could use keyboard for common actions.
Here's a short list of relevant hot keys that I commonly use in sketch with most common at top

[x] delete key
[x] duplicate ctrl D
[ ] copy ctrl C
[ ] paste ctrl V
[x] undo ctrl Z
[x] redo shift ctrl Z

Delete, duplicate, undo and redo are now available.
Copy and paste will take a bit more time.

where should I add the resolved issue? @gcate

Hey @kushcoder12, what do you mean? :)

By copy and paste, do you mean the copied component must drop into a specified Column within a certain Grid?

@theGeekyLad Hitting a copy hotkey would put the component(s) json into clipboard.
Hitting a paste hotkey would parse the json in clipboard and if it's valid component(s), it would add it to wherever the current selection is using the default drop-like behaviour.
Does that make sense?

@zvonimirfras can i try to work on this?

Sure, @Gobinath-B 😃
Go ahead!
Do you have a specific idea about the approach?


Add support to tarball .xz with volume header

Problem description
On ADD .xz tarball with volume header I have this error:
Step 6/14 : ADD ./portage-latest.tar.xz /usr
Error processing tar file(exit status 1): Unhandled tar header type 86
Problem location
A description of the problem is also here: https://bugs.gentoo.org/631644
Project version(s) affected
Server Version: 17.06.0-ce
containerd version: d24f39e203aa6be4944f06dd0fe38a618a36c764 (expected: cfb82a876ecc11b5ca0977d1733adbe58599088a)
runc version: 2d41c04 (expected: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4)
init version: v0.13.2 (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
seccomp
Profile: default
Kernel Version: 4.12.10
Operating System: Gentoo/Linux
OSType: linux
Architecture: x86_64

Hi, @geaaru, you filed this under docs. Which page are you referring to?

Sorry, wrong place. It's related to docker-ce.
But could be helpful add some informations to ADD command to avoid use of tar with volume header enable.

Hi @geaaru , I believe we cover this topic here: https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#add-or-copy
I'm going to close this issue but continue to look for other ways to make this topic more clear.


fix dying consumer deadlock during rebalance (#281)

This is a cherry-pick of the following change into the segment-stable branch:

segmentio/sarama-cluster@b92bef2

This resolves the final of the 3 issues documented in F8N-764:

hang during source.Close()

Testing
I ran Stage Archiver overnight with this change in place & the twice-hourly stopping of the archiver containers, and we didn't have any recurrence of the traceback & orphaned files during shutdown:

https://github.com/segmentio/terracode-infra/pull/1145
https://github.com/segmentio/archiver/commit/aba6b3fee9950ec3854ba3e84a72f0d2258427e0

Any chance we can split this into two PRs?  Maybe fix the test issue first (since in theory that's going to fail even before we cherry pick the change) and then process the cherry pick.  That way we don't comingle our commits with commits from upstream.

Any chance we can split this into two PRs? Maybe fix the test issue first (since in theory that's going to fail even before we cherry pick the change) and then process the cherry pick. That way we don't comingle our commits with commits from upstream.

@stevevls : good suggestion!  Cleanliness is next to godliness, as the saying goes.

Spoke to @stevevls offline, merging this in despite the single test failure (https://ci.segment.com/gh/segmentio/sarama-cluster/82).  Seems the tests are somewhat racy/flaky, but cleaning that up is a challenge for another day.


[Improvement] Add Iceberg (and minimal Spark DSv2) commands to Authz module

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Search before asking

[X] I have searched in the issues and found no similar issues.

What would you like to be improved?
We recently integrated Apache Iceberg into our product with Apache Kyuubi. We started from Ranger ACL plugin of Apache Submarine, but it has only DSv1 ACLs. So We add some DSv2 ACL checks to the module for Iceberg tables.
Below is the full list of added commands:
Spark DSv2 DDLs

AddColumns, AlterColumn, DropColumns, RenameColumn, RenameTable,
SetTableProperties, UnsetTableProperties
CreateV2Table, DropTable, ReplaceTableAsSelect
TruncateTable

Spark DSv2 DMLs

AppendData

Iceberg commands: DDLs

AddPartitionField/ DropPartitionField
SetIdentifierFields/ DropIdentifierFields
SetWriteDistributionAndOrdering

Iceberg commands: DMLs

MergeIntoIcebergTable
UpdateIcebergTable
DeleteFromIcebergTable

We uses Kyuubi already, and now Kyuubi has it's own Authz module. So we're willing to contribute back to Kyuubi.
How should we improve?
PrivilegesBuilder.buildCommand has almost all DSv1 and some DSv2 commands. Create PrivilegesBuilder.buildV2Command and PrivilegesBuilder.buildIcebergCommand for each purpose. Then call these functions from PrivilegesBuilder.build like:
  def build(plan: LogicalPlan): (Seq[PrivilegeObject], Seq[PrivilegeObject]) = {
    val inputObjs = new ArrayBuffer[PrivilegeObject]
    val outputObjs = new ArrayBuffer[PrivilegeObject]
    plan match {
      // RunnableCommand
      case cmd: Command =>
          buildCommand(cmd, inputObjs, outputObjs)
          buildV2Command(cmd, inputObjs, outputObjs)
          buildIcebergCommand(cmd, inputObjs, outputObjs)
      // Queries
      case _ => buildQuery(plan, inputObjs)
    }
    (inputObjs, outputObjs)
  }

Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

thanks @minyk

@yaooqinn this is getting bigger than I thought. Currently, initial translation to kyuubi was done and start to write unit test.
May I send Working-In-Progress PR for discussion? Any restriction for WIP PR?

feel free to send a WIP PR @minyk

Both V2 commands/plans and Iceberg commands are covered in the current Authz implementation. This issue should be good to close.

thanks @bowenliang123


Have ProdCell no longer inherit from Product

Several fields from Product are needed for the ProdCell definition, so the inheritance should be kept.


Update deletes Main Bucket and fails

When I download scoop, it seems to work fine (Invoke-Expression (New-Object System.Net.WebClient).DownloadString('https://get.scoop.sh')). I can install anything I want and they all work. However, once I try to update scoop scoop update It fails with the error:
Updating 'main' bucket...
Checking repo... 'https://github.com/ScoopInstaller/Main' doesn't look like a valid git repository

And the Main bucket is no longer in my scoop bucket folder.
I looked through other issues about this and tried a few.
The first I tried was deleting the .git file from ~/scoop/shims/apps/scoop/current but there is no .git file there.
I have also just deleted the whole scoop directory with git bash window rm -rf /scoop then reinstalling it several times.
Any help is very appreciated. And if this has been covered already my apologies, I must have missed it.

Install scoop normally, then run scoop install git and then try scoop update again.

Ok. I just did a fresh install of scoop and installed git
'git' (2.23.0.windows.1) was installed successfully!

Just ran the update and again
Updating 'main' bucket...
Checking repo... 'https://github.com/ScoopInstaller/Main' doesn't look like a valid git repository

I then renamed the folder for the existing Git in my system and did a fresh install of scoop and git with scoop. Same error
Updating 'main' bucket...
Checking repo... 'https://github.com/ScoopInstaller/Main' doesn't look like a valid git repository

I suspect some network / proxy problem.
What is result of git clone 'https://github.com/ScoopInstaller/Main' "$env:TEMP/TEST" ?

Also I just want to mention that now after that failure, if I try and install anything else or try the update again I get this:
WARN  The main bucket of Scoop has been separated to 'https://github.com/ScoopInstaller/Main'
WARN  You don't have the main bucket added, adding main bucket for you...
Checking repo... 'https://github.com/ScoopInstaller/Main' doesn't look like a valid git repository

@Ash258 When I do a git clone I get this.
git clone 'https://github.com/ScoopInstaller/Main' "$env:TEMP/TEST"
Cloning into 'C:\Users\Kevin\AppData\Local\Temp/TEST'...
remote: Enumerating objects: 143, done.
remote: Counting objects: 100% (143/143), done.
remote: Compressing objects: 100% (100/100), done.
remote: Total 34767 (delta 82), reused 77 (delta 43), pack-reused 34624
Receiving objects: 100% (34767/34767), 6.07 MiB | 2.01 MiB/s, done.
Resolving deltas: 100% (23221/23221), done.

And when I look in the directory
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         9/5/2019   1:35 PM                .vscode
d-----         9/5/2019   1:35 PM                bin
d-----         9/5/2019   1:35 PM                bucket
d-----         9/5/2019   1:35 PM                test
-a----         9/5/2019   1:35 PM            459 .editorconfig
-a----         9/5/2019   1:35 PM             84 .gitattributes
-a----         9/5/2019   1:35 PM              9 .gitignore
-a----         9/5/2019   1:35 PM           1156 appveyor.yml
-a----         9/5/2019   1:35 PM           1235 LICENSE
-a----         9/5/2019   1:35 PM            269 README.md

Hm, try running scoop bucket rm main and scoop bucket add main.

@r15ch13 Ok, the rm looks like it works, or at least didn't throw an error. But the add does the same error as earlier:
Scoop was installed successfully!
Type 'scoop help' for instructions.
PS C:\Users\Kevin> scoop bucket rm main
PS C:\Users\Kevin> scoop bucket add main
WARN  The main bucket of Scoop has been separated to 'https://github.com/ScoopInstaller/Main'
WARN  You don't have the main bucket added, adding main bucket for you...
Checking repo... 'https://github.com/ScoopInstaller/Main' doesn't look like a valid git repository

Here is the full error message. I didn't include it earlier because I didn't know if it would be anything.
 I appreciate the help and want to get this working again.

I'm facing the same error. Installed scoop several days ago and installed git, 7zip and neovim without problem. Then today when I tried to install nodejs-lts, I got this error. Now I can do nothing to scoop. I can't udpate, delete bucket or even uninstall scoop. I get all the same errors no matter what I do with scoop.

Does anyone else have a stab at this? I appreciate the help and want to get this working again.
I had similar issues. What I had found was the error is misleading and it is because of dos commands erroring out. Take a look at the description here :
https://github.com/lukesampson/scoop/pull/3815
I would be curious as to whether that solves your problem.

@greg-hutchinson I still have not gotten this to work. Best I have gotten was to just remember all the things I wanted scoop to install, and do a fresh install and leave it be. I am thinking of getting away from scoop and just installing things the old fashioned way, like git and node/npm.
I would love to have a fix for this though.

@kevmul - A quick fix to try for now. If you find where scoop has installed
to (On my machine C:\Users\Greg\scoop\apps\scoop\current) and go into the
lib directory you should find a git.ps1 file.
Change the line in the function git_proxy_cmd (currently line 7)
from
& "$env:COMSPEC" /c $cmd
to this
& "$env:COMSPEC" /d /c $cmd
Note the /d switch. Save it and see if this solves the problem for you.
This switch just invokes the git command without an extra autostart
features. My guess is that you might have something also starting that is
causing an error.
Another good way to know if this might work is if you just start a command
window by itself do you also get a message at the top of the window.
In any case, this switch can't hurt, if you think it causes other problems
you can always take it out. Good luck - I would be curious to know if this
fixes things for you. It did for me.
... Greg ...
On Mon, 4 May 2020 at 13:45, kevmul<EMAIL_ADDRESS>wrote:

@greg-hutchinson https://github.com/greg-hutchinson I still have not
gotten this to work. Best I have gotten was to just remember all the things
I wanted scoop to install, and do a fresh install and leave it be. I am
thinking of getting away from scoop and just installing things the old
fashioned way, like git and node/npm.
I would love to have a fix for this though.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lukesampson/scoop/issues/3629#issuecomment-623667544,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADDG3JX3ZSGTXSLD2WWPE5TRP4LOJANCNFSM4IT76P4Q
.

--

@greg-hutchinson I just did the change and IT WORKED! The main bucket was able to be added successfully and I was able to do the scoop update! I was even able to install a new program with scoop!
Thank you so much for this! I will mark this as completed and solved.

 Glad you can now keep using scoop 'cause it is a
great product.
I have submitted the fix already to the maintainers.
On Wed, 27 May 2020 at 06:14, kevmul<EMAIL_ADDRESS>wrote:

@greg-hutchinson https://github.com/greg-hutchinson I just did the
change and IT WORKED! The main bucket was able to be added successfully
and I was able to do the scoop update! I was even able to install a new
program with scoop!
Thank you so much for this! I will mark this as completed and solved.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lukesampson/scoop/issues/3629#issuecomment-634619659,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADDG3JQQAMHXQGFQCHCCHUTRTT74FANCNFSM4IT76P4Q
.

--


Dashboard exception: Solid Queue::job is missing a status method

When I open Queues and click on a job that did not run because of an exception or because I pass wrong args I get the following error and the dashboard fails with a fatal exception
When I analyse the logs this is the error I see that the Solid Queue::job is missing a status method
I'm using Rails 7.1 with mission_control-jobs (~> 0.2.1) and everything is running in a Puma 6.0
[hiphiphouse] [2024-05-22 17:55:33] I, [2024-05-22T17:55:33.515147 #15]  INFO -- : [24d6be8a-e014-4e7a-a987-6214618d79e0] Processing by MissionControl::Jobs::QueuesController#show as HTML
[hiphiphouse] [2024-05-22 17:55:33] I, [2024-05-22T17:55:33.515211 #15]  INFO -- : [24d6be8a-e014-4e7a-a987-6214618d79e0]   Parameters: {"server_id"=>"solid_queue", "application_id"=>"realestatescraperrails", "id"=>"default"}
[hiphiphouse] [2024-05-22 17:55:33] I, [2024-05-22T17:55:33.572069 #15]  INFO -- : [24d6be8a-e014-4e7a-a987-6214618d79e0]   Rendered layout /layers/heroku_ruby/gems/vendor/bundle/ruby/3.1.0/gems/mission_control-jobs-0.2.1/app/views/layouts/mission_control/jobs/application.html.erb (Duration: 45.1ms | Allocations: 7221)
[hiphiphouse] [2024-05-22 17:55:33] I, [2024-05-22T17:55:33.572507 #15]  INFO -- : [24d6be8a-e014-4e7a-a987-6214618d79e0] Completed 200 OK in 57ms (Views: 25.7ms | ActiveRecord: 25.1ms | Allocations: 8192)
[hiphiphouse] [2024-05-22 17:55:34] I, [2024-05-22T17:55:34.895968 #15]  INFO -- : [779eac64-9fb1-4161-bda7-a8c088579963] Started GET "/jobs/applications/realestatescraperrails/failed/jobs?server_id=solid_queue" for <IP_ADDRESS> at 2024-05-22 17:55:34 +0000
[hiphiphouse] [2024-05-22 17:55:34] I, [2024-05-22T17:55:34.897793 #15]  INFO -- : [779eac64-9fb1-4161-bda7-a8c088579963] Processing by MissionControl::Jobs::JobsController#index as HTML
[hiphiphouse] [2024-05-22 17:55:34] I, [2024-05-22T17:55:34.897892 #15]  INFO -- : [779eac64-9fb1-4161-bda7-a8c088579963]   Parameters: {"server_id"=>"solid_queue", "application_id"=>"realestatescraperrails", "status"=>"failed"}
[hiphiphouse] [2024-05-22 17:55:34] I, [2024-05-22T17:55:34.926022 #15]  INFO -- : [779eac64-9fb1-4161-bda7-a8c088579963]   Rendered layout /layers/heroku_ruby/gems/vendor/bundle/ruby/3.1.0/gems/mission_control-jobs-0.2.1/app/views/layouts/mission_control/jobs/application.html.erb (Duration: 13.4ms | Allocations: 4188)
[hiphiphouse] [2024-05-22 17:55:34] I, [2024-05-22T17:55:34.926398 #15]  INFO -- : [779eac64-9fb1-4161-bda7-a8c088579963] Completed 200 OK in 28ms (Views: 8.2ms | ActiveRecord: 11.5ms | Allocations: 5820)
[hiphiphouse] [2024-05-22 17:55:38] I, [2024-05-22T17:55:38.642000 #15]  INFO -- : [6cacec07-49ce-4790-b9f8-c2168298ce10] Started GET "/jobs/applications/realestatescraperrails/jobs/476c448c-2c9a-4b50-9d38-4c346a8c6ff9?filter%5Bqueue_name%5D=default&server_id=solid_queue" for <IP_ADDRESS> at 2024-05-22 17:55:38 +0000
[hiphiphouse] [2024-05-22 17:55:38] I, [2024-05-22T17:55:38.643418 #15]  INFO -- : [6cacec07-49ce-4790-b9f8-c2168298ce10] Processing by MissionControl::Jobs::JobsController#show as HTML
[hiphiphouse] [2024-05-22 17:55:38] I, [2024-05-22T17:55:38.643480 #15]  INFO -- : [6cacec07-49ce-4790-b9f8-c2168298ce10]   Parameters: {"filter"=>{"queue_name"=>"default"}, "server_id"=>"solid_queue", "application_id"=>"realestatescraperrails", "id"=>"476c448c-2c9a-4b50-9d38-4c346a8c6ff9"}
[hiphiphouse] [2024-05-22 17:55:38] I, [2024-05-22T17:55:38.655808 #15]  INFO -- : [6cacec07-49ce-4790-b9f8-c2168298ce10] Completed 500 Internal Server Error in 12ms (ActiveRecord: 1.4ms | Allocations: 6172)
[hiphiphouse] [2024-05-22 17:55:38] F, [2024-05-22T17:55:38.659066 #15] FATAL -- : [6cacec07-49ce-4790-b9f8-c2168298ce10]
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] NoMethodError (undefined method `status' for #<SolidQueue::Job id: 1, queue_name: "default", class_name: "NjuskaloScraperJob", arguments: {"job_class"=>"NjuskaloScraperJob", "job_id"=>"476c448c-2c9a-4b50-9d38-4c346a8c6ff9", "provider_job_id"=>nil, "queue_name"=>"default", "priority"=>nil, "arguments"=>["www.njuskalo.hr", nil, 2, false], "executions"=>0, "exception_executions"=>{}, "locale"=>"en", "timezone"=>"UTC", "enqueued_at"=>"2024-05-22T17:44:59.815855130Z", "scheduled_at"=>nil}, priority: 0, active_job_id: "476c448c-2c9a-4b50-9d38-4c346a8c6ff9", scheduled_at: "2024-05-22 17:44:59.815697000 +0000", finished_at: nil, concurrency_key: nil, created_at: "2024-05-22 17:44:59.952260000 +0000", updated_at: "2024-05-22 17:44:59.952260000 +0000">):
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10]
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activemodel (<IP_ADDRESS>) lib/active_model/attribute_methods.rb:489:in `method_missing'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] mission_control-jobs (0.2.1) lib/active_job/queue_adapters/solid_queue_ext.rb:113:in `status_from_solid_queue_job'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] mission_control-jobs (0.2.1) lib/active_job/queue_adapters/solid_queue_ext.rb:96:in `deserialize_and_proxy_solid_queue_job'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] mission_control-jobs (0.2.1) lib/active_job/queue_adapters/solid_queue_ext.rb:78:in `find_job'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] mission_control-jobs (0.2.1) lib/active_job/jobs_relation.rb:172:in `find_by_id!'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] mission_control-jobs (0.2.1) app/controllers/concerns/mission_control/jobs/job_scoped.rb:10:in `set_job'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:403:in `block in make_lambda'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:183:in `block (2 levels) in halting_and_conditional'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/abstract_controller/callbacks.rb:34:in `block (2 levels) in <module:Callbacks>'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:184:in `block in halting_and_conditional'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:598:in `block in invoke_before'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:598:in `each'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:598:in `invoke_before'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:119:in `block in run_callbacks'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] mission_control-jobs (0.2.1) lib/mission_control/jobs/adapter.rb:3:in `activating'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] mission_control-jobs (0.2.1) lib/mission_control/jobs/server.rb:18:in `activating'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] mission_control-jobs (0.2.1) app/controllers/concerns/mission_control/jobs/application_scoped.rb:28:in `activating_job_server'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:130:in `block in run_callbacks'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] turbo-rails (2.0.5) lib/turbo-rails.rb:24:in `with_request_id'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] turbo-rails (2.0.5) app/controllers/concerns/turbo/request_id_tracking.rb:10:in `turbo_tracking_request_id'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:130:in `block in run_callbacks'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] audited (5.6.0) lib/audited/sweeper.rb:16:in `around'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:130:in `block in run_callbacks'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] audited (5.6.0) lib/audited/sweeper.rb:16:in `around'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:130:in `block in run_callbacks'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actiontext (<IP_ADDRESS>) lib/action_text/rendering.rb:23:in `with_renderer'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actiontext (<IP_ADDRESS>) lib/action_text/engine.rb:69:in `block (4 levels) in <class:Engine>'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:130:in `instance_exec'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:130:in `block in run_callbacks'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:141:in `run_callbacks'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/abstract_controller/callbacks.rb:258:in `process_action'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_controller/metal/rescue.rb:25:in `process_action'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_controller/metal/instrumentation.rb:74:in `block in process_action'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/notifications.rb:206:in `block in instrument'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/notifications/instrumenter.rb:58:in `instrument'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/notifications.rb:206:in `instrument'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_controller/metal/instrumentation.rb:73:in `process_action'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_controller/metal/params_wrapper.rb:261:in `process_action'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activerecord (<IP_ADDRESS>) lib/active_record/railties/controller_runtime.rb:32:in `process_action'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/abstract_controller/base.rb:160:in `process'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionview (<IP_ADDRESS>) lib/action_view/rendering.rb:40:in `process'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_controller/metal.rb:227:in `dispatch'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_controller/metal.rb:309:in `dispatch'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:49:in `dispatch'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:32:in `serve'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:51:in `block in serve'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:131:in `block in find_routes'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:124:in `each'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:124:in `find_routes'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:32:in `serve'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:882:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] railties (<IP_ADDRESS>) lib/rails/engine.rb:536:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] railties (<IP_ADDRESS>) lib/rails/railtie.rb:226:in `public_send'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] railties (<IP_ADDRESS>) lib/rails/railtie.rb:226:in `method_missing'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/mapper.rb:22:in `block in <class:Constraints>'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/mapper.rb:51:in `serve'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:51:in `block in serve'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:131:in `block in find_routes'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:124:in `each'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:124:in `find_routes'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/journey/router.rb:32:in `serve'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/routing/route_set.rb:882:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] warden (1.2.9) lib/warden/manager.rb:36:in `block in call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] warden (1.2.9) lib/warden/manager.rb:34:in `catch'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] warden (1.2.9) lib/warden/manager.rb:34:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] rack (3.0.11) lib/rack/tempfile_reaper.rb:20:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] rack (3.0.11) lib/rack/etag.rb:29:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] rack (3.0.11) lib/rack/conditional_get.rb:31:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] rack (3.0.11) lib/rack/head.rb:15:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/http/permissions_policy.rb:36:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/http/content_security_policy.rb:33:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] rack-session (2.0.0) lib/rack/session/abstract/id.rb:272:in `context'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] rack-session (2.0.0) lib/rack/session/abstract/id.rb:266:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/cookies.rb:689:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/callbacks.rb:101:in `run_callbacks'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/callbacks.rb:28:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/debug_exceptions.rb:29:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/show_exceptions.rb:31:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] railties (<IP_ADDRESS>) lib/rails/rack/logger.rb:37:in `call_app'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] railties (<IP_ADDRESS>) lib/rails/rack/logger.rb:24:in `block in call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/tagged_logging.rb:135:in `block in tagged'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/tagged_logging.rb:39:in `tagged'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/tagged_logging.rb:135:in `tagged'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] activesupport (<IP_ADDRESS>) lib/active_support/broadcast_logger.rb:240:in `method_missing'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] railties (<IP_ADDRESS>) lib/rails/rack/logger.rb:24:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/remote_ip.rb:92:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/request_id.rb:28:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] rack (3.0.11) lib/rack/method_override.rb:28:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] rack (3.0.11) lib/rack/runtime.rb:24:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/executor.rb:14:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] actionpack (<IP_ADDRESS>) lib/action_dispatch/middleware/static.rb:25:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] rack (3.0.11) lib/rack/sendfile.rb:114:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] railties (<IP_ADDRESS>) lib/rails/engine.rb:536:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] puma (6.4.2) lib/puma/configuration.rb:272:in `call'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] puma (6.4.2) lib/puma/request.rb:100:in `block in handle_request'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] puma (6.4.2) lib/puma/thread_pool.rb:378:in `with_force_shutdown'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] puma (6.4.2) lib/puma/request.rb:99:in `handle_request'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] puma (6.4.2) lib/puma/server.rb:464:in `process_client'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2168298ce10] puma (6.4.2) lib/puma/server.rb:245:in `block in run'
[hiphiphouse] [2024-05-22 17:55:38] [6cacec07-49ce-4790-b9f8-c2

Hey @luigi7up, thanks for the report! What version of Solid Queue are you running?

Hi Rosa, I'm not at home right now, but since I'm bundling it without a
version lock and with Rails 7.1... I assume it's the latest. I can confirm
in a couple of hours.
Thank you
On Wed, May 22, 2024, 20:20 Rosa Gutierrez @.***> wrote:

Hey @luigi7up https://github.com/luigi7up, thanks for the report! What
version of Solid Queue are you running?
—
Reply to this email directly, view it on GitHub
https://github.com/rails/mission_control-jobs/issues/123#issuecomment-2125468593,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEUY65VPM4P5HFVXZI56TTZDTOV5AVCNFSM6AAAAABIEE7ZBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVGQ3DQNJZGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

Ahhh! Could you try upgrading to the last version? 0.3.1 as of now.

Yes, I did and it solved the problem. Thank you so much for such a swift
answer!
Best regards
Luka
On Thu, May 23, 2024 at 10:49 AM Rosa Gutierrez @.***>
wrote:

Ahhh! Could you try upgrading to the last version? 0.3.1 as of now.
—
Reply to this email directly, view it on GitHub
https://github.com/rails/mission_control-jobs/issues/123#issuecomment-2126569897,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEUY66YUPPK4NUSR2AWPOTZDWUR3AVCNFSM6AAAAABIEE7ZBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWGU3DSOBZG4
.
 It fails to remove it with the following exception:
ActiveRecord::StatementInvalid at /applications/realestatescraperrails/jobs/50e65d2a-5a98-4293-b940-2b489fb93800/discard
PG::UndefinedTable: ERROR:  relation "solid_queue_recurring_executions" does not exist
LINE 10:  WHERE a.attrelid = '"solid_queue_recurring_executions"'::re...
                             ^

Do you prefer if I opened another issue for it?

Oh! You need to copy and run the pending migration for Solid Queue, to create the solid_queue_recurring_executions table. In your app run:
bin/rails solid_queue:install:migrations

And then run the migrations.

Thanks for the tip! I'll run the migrations. I'd expect Rails to tell me
about the pending migrations, but I guess these are Gem specific...
Again, thanks for your help
On Thu, May 23, 2024, 16:50 Rosa Gutierrez @.***> wrote:

Oh! You need to copy and run the pending migration for Solid Queue, to
create the solid_queue_recurring_executions table. In your app run:
bin/rails solid_queue:install:migrations
And then run the migrations.
—
Reply to this email directly, view it on GitHub
https://github.com/rails/mission_control-jobs/issues/123#issuecomment-2127331609,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEUY6YI7Y5W3PBYLNESPQ3ZDX6ZXAVCNFSM6AAAAABIEE7ZBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRXGMZTCNRQHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@luigi7up, was this one solved for you after running the migrations?

Yes, it was. Sorry for not providing any update. I'm running the jobs like
crazy in production :)
The whole idea of having queuing system that uses the same DB is just great.
Thank you so much!
On Fri, Jun 7, 2024, 17:24 Rosa Gutierrez @.***> wrote:

@luigi7up https://github.com/luigi7up, was this one solved for you
after running the migrations?
—
Reply to this email directly, view it on GitHub
https://github.com/rails/mission_control-jobs/issues/123#issuecomment-2155062459,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEUY6ZJOQA7GUZ34IQ7SULZGHGC7AVCNFSM6AAAAABIEE7ZBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJVGA3DENBVHE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Set up tab stops according to the new number of cols

Closes #212.

Closing this. Needs more work.


[FEAT] Implement Wait List

Description
The feature allows users to join the wait list and be part of the early birds .

Purpose
For user to be able to join  the company early bords
Requirements

Backend:

API Endpoints:
 - **POST /wait-lists**

   - **Description:** Endpoint to create a wait list ticket.
   - **Request Body:**

     ```json
     {
       "name": "string",
       "email": "string"
     }
     ```

   - **Success Response:**

     ```json
     {
       "waitListId": "string",
       "status": "Open"
     }
     {

      "status": true,
      "message": "string",
     }

    ````

   - **Error Response:**

     ```json
     {
       "error": "Invalid request data",
       "details": "Description of the validation error"
     }
     ```

 - **GET /wait-lists/{waitListId}**

   - **Description:** Endpoint to retrieve details of a specific wait list details.
   - **Success Response:**

     ```json
     {
      "status": true,
      "message": "string",
      "data": {
          "waitListId": 0,
          "name": "string",
          "email": "string"
      }
      }
     ```

   - **Error Response:**

     ```json
     {
       "error": "Wait list not found"
     }
     ```

 - **GET /wait-lists**

   - **Description:** Endpoint to retrieve a list of all wait lists.
   - **Success Response:**

     ```json
     [
       {
      "status": true,
      "message": "string",
      "data": {
          "waitListId": 0,
          "name": "string",
          "email": "string"
      }
       },
       ...
     ]
     ```

   - **Error Response:**

     ```json
     {
       "error": "No wait lists found"
     }
     ```

Database Schema:

WaitLIst Table:

waitListId (UUID, Primary Key)
name (String)
email (String)
createdAt (Timestamp)
updatedAt (Timestamp)

Notifications:

Email confirmation to users upon joining the wait list.

Expected Outcome

Users can join the wait list only onces with their email and name.
Wait lists are stored in the database with all relevant details.
Email confirmation to users upon joining the wait list.

Checklist/Acceptance Criteria

Backend Functionality:

[ ] API endpoint accepts , validates and processes the wait list submissions.
[ ] Wait list are stored in the database with unique IDs.

Notifications:

[ ] Users receive a confirmation email showing that they have been added to the wait list.

Integration Testing:

[ ] End-to-end tests to ensure the wait list are received and stored properly on the database.
[ ] Data is correctly stored, and notification are sent.

This ticket is poorly described


[Bug]: Regridding error from differing time dimensions

What happened?
In this case, I am using the Dataset.regridder.horizontal(tool='regrid2') method to regrid a reference dataset to the grid of a test dataset. The time dimensions are different lengths, for example the old grid data has 20 years and the target grid data has 50 years.
I do not have this issue when the time dimensions are the same length (the years can differ, but length must match), or when the target grid does not have a time dimension.
Running this command (target has 50 years, old has 20 years):
>> regridded = old.regridder.horizontal("ANN", target, tool='regrid2')
Throws:
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Cell In[50], line 1
----> 1 regridded = old.regridder.horizontal("ANN", target, tool='regrid2')

File ~/miniconda3/envs/pcmdi_metrics_dev/lib/python3.9/site-packages/xcdat/regridder/accessor.py:316, in RegridderAccessor.horizontal(self, data_var, output_grid, tool, **options)
    311     raise ValueError(
    312         f"Tool {e!s} does not exist, valid choices {list(REGRID_TOOLS)}"
    313     )
    315 regridder = regrid_tool(self._ds, output_grid, **options)
--> 316 output_ds = regridder.horizontal(data_var, self._ds)
    318 return output_ds

File ~/miniconda3/envs/pcmdi_metrics_dev/lib/python3.9/site-packages/xcdat/regridder/regrid2.py:141, in Regrid2Regridder.horizontal(self, data_var, ds)
    137 ordered_axis_names = list(output_axis_sizes)
    139 output_data = self._regrid(input_data, output_axis_sizes, ordered_axis_names)
--> 141 output_ds = self._create_output_dataset(
    142     ds, data_var, output_data, axis_variable_name_map, ordered_axis_names
    143 )
    145 dst_mask = self._output_grid.get("mask", None)
    147 if dst_mask is not None:

File ~/miniconda3/envs/pcmdi_metrics_dev/lib/python3.9/site-packages/xcdat/regridder/regrid2.py:316, in Regrid2Regridder._create_output_dataset(self, input_ds, data_var, output_data, axis_variable_name_map, ordered_axis_names)
    313     else:
    314         coords[variable_name] = input_ds[variable_name].copy()
--> 316 output_da = xr.DataArray(
    317     output_data,
    318     dims=[axis_variable_name_map[x] for x in ordered_axis_names],
    319     coords=coords,
    320 )
    322 data_vars = {data_var: output_da}
    324 return xr.Dataset(data_vars, attrs=input_ds.attrs.copy())

File ~/miniconda3/envs/pcmdi_metrics_dev/lib/python3.9/site-packages/xarray/core/dataarray.py:417, in __init__(self, data, coords, dims, name, attrs, indexes, fastpath)
    415 if name is None:
    416     name = getattr(data, "name", None)
--> 417 if attrs is None and not isinstance(data, PANDAS_TYPES):
    418     attrs = getattr(data, "attrs", None)
    420 data = _check_data_shape(data, coords, dims)

File ~/miniconda3/envs/pcmdi_metrics_dev/lib/python3.9/site-packages/xarray/core/dataarray.py:163, in _infer_coords_and_dims(shape, coords, dims)
    158 for k, v in new_coords.items():
    159     if any(d not in dims for d in v.dims):
    160         raise ValueError(
    161             f"coordinate {k} has dimensions {v.dims}, but these "
    162             "are not a subset of the DataArray "
--> 163             f"dimensions {dims}"
    164         )
    166     for d, s in zip(v.dims, v.shape):
    167         if s != sizes[d]:

ValueError: conflicting sizes for dimension 'time': length 50 on the data but length 20 on coordinate 'time'

This does work when I slice "target" to be 20 years:
regridded = old.regridder.horizontal("ANN", target.sel(time=slice("1950-01-01","1969-12-31")), tool='regrid2')
This also works when I strip out the time coordinate:
regridded = old.regridder.horizontal("ANN", target.isel({"time":0}).drop("time"), tool='regrid2')
What did you expect to happen? Are there are possible answers you came across?
I would expect the time dimension to not affect horizontal regridding, or to get a clearer error message if the target grid should not have any time coordinates.
Minimal Complete Verifiable Example (MVCE)
import xcdat as xc

# I've been trying to create dummy arrays in-place that
# reproduce this issue but haven't been successful.

# These files are actually on the same grid but serve as
# an example.
path1="/home/ordonez4/git/pcmdi_metrics/pcmdi_metrics/extremes/test_nc_files/netcdf/MRI-ESM2-0_r1i1p1f1_land_TXn.nc"
path2="/home/ordonez4/git/pcmdi_metrics/pcmdi_metrics/extremes/test_nc_files/netcdf/Reference_fake_tasmax_land_TXn.nc"

# 50 year Dataset
target = xc.open_dataset(path1)
# 20 year Dataset
old = xc.open_dataset(path2)

regridded = old.regridder.horizontal("ANN", target, tool='regrid2')

Relevant log output
No response
Anything else we need to know?
 Can you do something like this:
ds_target = xc.open_dataset(path1)
target = xc.create_grid(ds_target.lat, ds_target.lon)
...
regridded = old.regridder.horizontal("ANN", target, tool='regrid2')

Also note #447 is on regrid2 (though I think the issue is different). Also...there is an active discussion about changing the API for xc.create_grids() in #388 – something to be aware of.

Just curious, can you try below in your code?
regridded = old.regridder.horizontal("ANN", target.isel(time=0), tool='regrid2')

@lee1043 It might have gotten lost in all my text, but pulling off the time coordinate like this does work:
regridded = old.regridder.horizontal("ANN", target.isel({"time":0}).drop("time"), tool='regrid2')
But @pochedls suggestion to make a new grid might be more robust, and it also worked in my case. I think #447 is different from my issue, but thanks for the heads-up on what else is happening in the regridding area.

I mainly wanted to flag that I was seeing inconsistent results depending on the time axis, and if the target grid really shouldn't have any time dimension it would be helpful to see that stated more explicitly.

@acordonez thank you for clarifying, I missed that part. Thank you for flagging this out!

I think the main issue/takeaway here is to improve the documentation, which I think may be out-of-date. The documentation lists a data_var parameter and a ds parameter, though I think ds should be something like target_grid with a note saying that it is a dataset that contains the regridding coordinates (and if it includes time, the time dimension should be the same length as the source dataset). Is this right?

@pochedls That summary sounds right to me, thanks for putting it together.

@pochedls That could be one way, and I can also think of benefit of giving ds as an input for regridder, when a user has loaded just 2 datasets and regrid one to another, without writing additional row of a code for target_grid. I think another alternative way could be revising the spatial regridder to drop the time coordinate from given ds if exist. What do you think?

I wasn't intending to comment on the name ds versus target_grid. I think it would be fine to pass in ds (and call it ds), but the documentation for horizontal is a little confusing. It says

ds (xr.Dataset) – The dataset containing data_var.

which I think isn't right?
I'd be fine with either:

updating the documentation (to say that ds should not have a time dimension or the time dimension should be the same size as the input dataset)
automatically dropping the time dimension of the target grid

In either case I think the documentation should be updated to say that

ds (xr.Dataset) – The dataset containing the target grid information

(if I am right that the current documentation is incomplete)

@pochedls @acordonez Circling around to this issue, I'm updating the documentation in another PR.
There's another issue here, the regrid2 code assumes output_grid has no time dimension, I'll add a check and raise an appropriate error.
Both @pochedls  and @lee1043  solutions work, the intended way to handle this is:
regridded = old.regridder.horizontal("ANN", target.regridder.grid, tool='regrid2')

The grid property is intended to extract the grid information from any dataset.


systemd-boot service: don't remove directories from EFI dir

This will only result in an error. These directories might be created by, for example, fwupdmgr.

Motivation for this change
Fix crashes after using fwupdmgr to update BIOS.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

The patch is trivial but I'd still like somebody's review before merging just to be sure we won't break boot accidentally.

@GrahamcOfBorg test installer.simpleUefiSystemdBoot
The change is trivial after all so if the test passes I'm going to merge this.

@GrahamcOfBorg test installer.simpleUefiSystemdBoot

Should not we delete the directories as outlined here instead?

I think we should treat this conservatively. Directories were created definitely not by us and for some reason. For example if someone runs fwupdmgr and then nixos-rebuild the firmware capsule will be removed which is not what we want.
On June 7, 2019 5:45:15 PM GMT+03:00, Jan Tojnar<EMAIL_ADDRESS>wrote:

Should not we delete the directories as outlined
here
instead?
--
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
https://github.com/NixOS/nixpkgs/pull/62065#issuecomment-499913167

--
Nikolay.


Editors no longer have ids

VS Code Version: 1.56.0-insider
OS: Windows_NT x64 10.0.19042
Live Share had previously relied on vscode.TextEditor#id to differentiate editors during coediting. However, (<any>editor).id is currently always returning undefined. This gives us no way to track text editors as they move across view columns. Is there some way we can identify these editors?
cc @daytonellwanger

An editor is always bound to a notebook (document), also edits happen on a notebook, so I am not sure why you need to know individual editors

This comment was in regards to vscode.TextEditors as well as vscode.NotebookEditors. Is there some internal identification property we can use for them?

@jrieken Just to clarify, not sure if needed: there is an editor action ("follow participant of live share session") that should only apply to that single pane. For example, when using multiple panes in split view, the "follow" function should be enabled only in the pane where the action button is clicked.

This comment was in regards to vscode.TextEditors as well as vscode.NotebookEditors. Is there some internal identification property we can use for them?

I see, we did get more strict and we checks that ensure that we don't have such accidental APIs, e.g only what's declared in the API file (vscode.d.ts) should be available at runtime.
To your question: the object identify itself should be sufficient in both editors. So, with some WeakMap trickery you should be able create your own identifiers


Python 3

Please follow the guide below

You will be asked some questions, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your pull request (like that [x])
Use Preview tab to see how your pull request will actually look like

Before submitting a pull request make sure you have:

[ x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x ] Searched the bugtracker for similar pull requests

What is the purpose of your pull request?

[x ] Bug fix
[ ] New extractor
[ ] New feature

Description of your pull request and other information
Hi Rogério,
Sorry for the delay. As requested, I have rebased my changes on this repo. As you have suggested, I have dropped support for Python 2 completely and kept it as a single package. I have had to change the build system from python_distutils to pybuild, because there seems to be a bug with python_distutils when building with sbuild. For some reason, not all files are packaged using python_distutils, even though it works fine with git-buildpackage.
If you use piuparts to test the package before release, you will need to use --warn-on-leftovers-after-purge, since the dpkg-maintscript-helper script doesn't handle the removal of the parent directories of the obsolete conf files properly.
If you choose to skip the release of 2016.08.17, since it's now quite dated, you'll also need to update debian/youtube-dl.maintscript to match the version number of the first official release that obsoletes the conf files.
The libav compatibility links fix wasn't accepted upstream, last time I checked, however the bug remains open as a Debian bug. Feel free to chop and change as you wish.
Best regards,
Carlos

Great suggestions, I'm merging your changes now. Please, feel free to send further pull requests, suggestions, etc. and I will try to act faster in the next iterations.


Publish page overtake amount incorrect

Go to publish and type lbry://one as the URL - the overtake amount should be 138K LBC, but it says any bid will win. I think it only works for your own claims at the moment

this is fixed in the latest RC


Clamp datetime, local_datetime and local_date to the 1-9999 year range

The default timestamp range of (4713 BC - 294276 AD) has problems:
Postgres isn't ISO compliant with years out of the 0-9999 range and
language compatibility is questionable.
See https://github.com/edgedb/edgedb/pull/2249#issuecomment-782353029
for an expanded rationale.

Looks good.


There is an error working on 4 GPUs

The code works with 2 GPUs. When I tried to use 4 GPUs, the error is as follow:
tensorflow/core/framework/op_kernel.cc:1192] Internal: WhereOp: Could not launch cub::DeviceReduce::Sum to count number of true indices, status: invalid resource handle
Traceback (most recent call last):
File "inception-bn.py", line 198, in
launch_train_with_config(config, SyncMultiGPUTrainer(get_nr_gpu()))
File "/usr/local/lib/python2.7/dist-packages/tensorpack/trainv1/interface.py", line 11, in launch_train_with_config
old_launch(config, trainer)
File "/usr/local/lib/python2.7/dist-packages/tensorpack/train/interface.py", line 92, in launch_train_with_config
config.steps_per_epoch, config.starting_epoch, config.max_epoch)
File "/usr/local/lib/python2.7/dist-packages/tensorpack/train/base.py", line 249, in train
self.initialize(session_creator, session_init)
File "/usr/local/lib/python2.7/dist-packages/tensorpack/utils/argtools.py", line 165, in wrapper
return func(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/tensorpack/train/base.py", line 177, in initialize
self.sess = session_creator.create_session()
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/training/monitored_session.py", line 425, in create_session
init_fn=self._scaffold.init_fn)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/training/session_manager.py", line 283, in prepare_session
local_init_success, msg = self._try_run_local_init_op(sess)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/training/session_manager.py", line 481, in _try_run_local_init_op
is_ready_for_local_init, msg = self._model_ready_for_local_init(sess)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/training/session_manager.py", line 466, in _model_ready_for_local_init
"Model not ready for local init")
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/training/session_manager.py", line 508, in _ready
ready_value = sess.run(op)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/client/session.py", line 896, in run
run_metadata_ptr)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/client/session.py", line 1124, in _run
feed_dict_tensor, options, run_metadata)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/client/session.py", line 1279, in _do_run
options, run_metadata)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/client/session.py", line 1298, in _do_call
raise type(e)(node_def, op, message)
tensorflow.python.framework.errors_impl.InternalError: WhereOp: Could not launch cub::DeviceReduce::Sum to count number of true indices, status: invalid resource handle
[[Node: report_uninitialized_variables_1/boolean_mask/Where = Where_device="/job:localhost/replica:0/task:0/gpu:0"]]
[[Node: report_uninitialized_variables_1/boolean_mask/Squeeze/_1263 = _Recvclient_terminated=false, recv_device="/job:localhost/replica:0/task:0/cpu:0", send_device="/job:localhost/replica:0/task:0/gpu:0", send_device_incarnation=1, tensor_name="edge_1259_report_uninitialized_variables_1/boolean_mask/Squeeze", tensor_type=DT_INT64, _device="/job:localhost/replica:0/task:0/cpu:0"]]
Caused by op u'report_uninitialized_variables_1/boolean_mask/Where', defined at:
File "inception-bn.py", line 198, in
launch_train_with_config(config, SyncMultiGPUTrainer(get_nr_gpu()))
File "/usr/local/lib/python2.7/dist-packages/tensorpack/trainv1/interface.py", line 11, in launch_train_with_config
old_launch(config, trainer)
File "/usr/local/lib/python2.7/dist-packages/tensorpack/train/interface.py", line 92, in launch_train_with_config
config.steps_per_epoch, config.starting_epoch, config.max_epoch)
File "/usr/local/lib/python2.7/dist-packages/tensorpack/train/base.py", line 249, in train
self.initialize(session_creator, session_init)
File "/usr/local/lib/python2.7/dist-packages/tensorpack/utils/argtools.py", line 165, in wrapper
return func(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/tensorpack/train/base.py", line 177, in initialize
self.sess = session_creator.create_session()
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/training/monitored_session.py", line 416, in create_session
self._scaffold.finalize()
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/training/monitored_session.py", line 196, in finalize
default_ready_for_local_init_op)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/training/monitored_session.py", line 258, in get_or_default
op = default_constructor()
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/training/monitored_session.py", line 193, in default_ready_for_local_init_op
variables.global_variables())
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/util/tf_should_use.py", line 170, in wrapped
return _add_should_use_warning(fn(*args, **kwargs))
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/ops/variables.py", line 1325, in report_uninitialized_variables
return array_ops.boolean_mask(variable_names_tensor, variables_mask)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/ops/array_ops.py", line 1127, in boolean_mask
return _apply_mask_1d(tensor, mask)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/ops/array_ops.py", line 1099, in _apply_mask_1d
indices = squeeze(where(mask), squeeze_dims=[1])
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/ops/array_ops.py", line 2350, in where
return gen_array_ops.where(input=condition, name=name)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/ops/gen_array_ops.py", line 3937, in where
result = _op_def_lib.apply_op("Where", input=input, name=name)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/op_def_library.py", line 767, in apply_op
op_def=op_def)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/ops.py", line 2576, in create_op
original_op=self._default_original_op, op_def=op_def)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/ops.py", line 1204, in init
self._traceback = self._graph._extract_stack()  # pylint: disable=protected-access
InternalError (see above for traceback): WhereOp: Could not launch cub::DeviceReduce::Sum to count number of true indices, status: invalid resource handle
[[Node: report_uninitialized_variables_1/boolean_mask/Where = Where_device="/job:localhost/replica:0/task:0/gpu:0"]]
[[Node: report_uninitialized_variables_1/boolean_mask/Squeeze/_1263 = _Recvclient_terminated=false, recv_device="/job:localhost/replica:0/task:0/cpu:0", send_device="/job:localhost/replica:0/task:0/gpu:0", send_device_incarnation=1, tensor_name="edge_1259_report_uninitialized_variables_1/boolean_mask/Squeeze", tensor_type=DT_INT64, _device="/job:localhost/replica:0/task:0/cpu:0"]]
What does it mean? Thank you!

Please tell me what you did as mentioned in the issue template.

This is a an issue from a cub primitive usually used in CUDA kernels and it is very likely to be caused by a TF issue itself.

Closing because necessary information about the bug wasn't provided.
It's very likely that upgrading TF will just solve this issue.


ImportError: cannot import name 'TabularPrediction' from 'autogluon' (/home/tommaso/repos/gemintelligence/env/lib/python3.7/site-packages/autogluon/init.py)

I am getting this error with a fresh install using the commands in the home page
# Here we assume CUDA 10.1 is installed.  You should change the number
# according to your own CUDA version (e.g. mxnet_cu100 for CUDA 10.0).
python3 -m pip install --upgrade "mxnet_cu101<2.0.0"
python3 -m pip install autogluon

And then
from autogluon import TabularPrediction as task

This has been blocking our releases too.

Any suggestion on alternative

I have reproduced the issue on a fresh machine and will deep dive:
>>> from autogluon import TabularPrediction as task
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'TabularPrediction' from 'autogluon' (/home/ubuntu/virtual/autogluon_test/lib/python3.7/site-packages/autogluon/__init__.py)

Issue identified:
gluoncv recently released v0.9.0 which depends on the pre-release autogluon.core module. AutoGluon has been changed to be a namespace package in preparation for v0.1 release, meaning it is now made up of several separate packages. However, having both autogluon==0.0.14 (non-namespace) and autogluon.core (namespace) installed creates a namespace collision. Because autogluon==0.0.14 installs 'gluoncv>=0.5.0,<1.0',, it installs the new gluoncv==0.9.0 which creates the namespace collision and breaks the package.
The following installation process works:
# Optionally upgrade pip for faster install and newer mxnet version
python3 -m pip install --upgrade pip

python3 -m pip install "mxnet<2.0.0"
python3 -m pip install "gluoncv>=0.5.0,<0.9.0"
python3 -m pip install autogluon

To fix a pre-existing broken environment:
python3 -m pip uninstall autogluon.core
python3 -m pip uninstall autogluon
python3 -m pip uninstall gluoncv
python3 -m pip install "gluoncv>=0.5.0,<0.9.0"
python3 -m pip install autogluon

This issue has been fixed with the release of v0.0.15. Please install the new version from a fresh environment to avoid any corruptions from prior installs. v0.0.15 should work identically to v0.0.14 minus the installation issue.

I can confirm this is resolved by v0.0.15.

This is the problem that bothered me for a few days. Now the problem is solved, thanks a lot :)

That issue is still there @Innixma
https://colab.research.google.com/drive/1JeK6zFR78fgYklaoyJbsE04mEjrPnWVC?usp=sharing#scrollTo=sIPK7XQJQmzo

@Patrickbro13

That issue is still there @Innixma
https://colab.research.google.com/drive/1JeK6zFR78fgYklaoyJbsE04mEjrPnWVC?usp=sharing#scrollTo=sIPK7XQJQmzo

This notebook is installing a pre-release version of AutoGluon from 2020 and the error you are getting in the notebook is unrelated to this GitHub issue, and is a parsing error by the user that did not convert their dtypes to float.

@Innixma I am really sorry , I forgot to update the issue and the link to the older notebook file which had that issue where I was installing the autogluon with the above instructions as mentioned but I found another notebook of your in other issue which resolved the issue so thanks for that and you can close this issue 😄


talksapp: talks.godoc.org slide progression is out of phase with slide width

What did you do?
Go to e.g. http://talks.godoc.org/github.com/SatishTalim/slides/whygo.slide (browsing with FF48.0) and progress through a number of slides.
What did you expect to see?
Slide progression where slide n+1 is aligned with the previous position of slide n.
What did you see instead?
Slides progressively move to the left (animation shifts more than one slide width to the left each step).

I can't seem to reproduce in either Chrome 54.0.2840.59 (current stable version), nor Firefox Developer Edition 51.0a2 (2016-10-15).
Is it an issue that's affecting Firefox 48.0 only? Is that the current stable version of Firefox, or is it out of date? If so, can you check if the current version has the same issue?

Just upgraded to 49.0. Problem remains.

I cannot reproduce this.
I tried a fresh VM of Ubuntu 16.10 just now, which comes with Firefox 49.0. I did not spot any issues with slides moving to the left. Here's a quick screencapture:
http://instantshare.virtivia.com:27080/15n83krlqf2n3.mov
Can you provide more information to try to help reproduce this? What OS are you using? Have you tried turning off any extensions you might have, clearing browser cache, using incognito window. Tried on another computer?

I am using ubuntu 12.04 (hopefully for not much longer - an upgrade window is coming soon).
Clearing cache, turning off all extensions or icognito mode do not fix this.
The reproduction is really as simple as described above. Here is how it looks after having progressed right by 9 slides.

I will try this on another machine (16.04) when I can later today.

Not reproducible on 16.04.


update:change text_to_image default size 1024x1024

Features

xx
yy

Feature Docs

change text_to_image default size 1024x1024
Influence

openai text to image
Result

Other

LGTM


Add Startup Institute to code school list

Startup Institute
Startup Institute offers all veterans an automatic $1,000 off the cost of their full-time program. Train to work in the innovation economy in the areas of web development, web design, digital marketing, or sales and account management. Additional scholarships are also available for: Women in Tech, People of Color in Tech, Seasoned Professional in Tech (age 40+), and Excellence in STEM. Learn more…

Will need to get an image for this too.

This was added in #459


InviteParticipants enhancements

re-use autocomplete component from within CreateRoomForm

This was normally already done (to check)

This was normally already done (to check)


Don't process JointPositions and JointStiffnesses message if message …

…is invalid. This prevents segmentation faults.

@mergifyio backport humble


Rename symbol does not show complete symbol name

Issue Type: Bug
Type a text with more than 16 characters
Set text cursor after the 16th characters and press F2 (rename symbol)
The small box will show the 15 characters that are behind the current cursor and the rest of the symbol name after the cursor.
VS Code version: Code - Insiders 1.45.0-insider (d342048538c28d54afd1c6beea03f3a89af04359, 2020-04-23T05:57:41.076Z)
OS version: Windows_NT x64 10.0.19616

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12 x 3696)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
63.84GB (49.84GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (4)

Extension
Author (truncated)
Version

vscode-idl
kur
0.1.2

devinsights
Mic
2020.4.16-1

vscode-nmake-tools
Mic
3.0.200422007

cpptools
ms-
0.27.0

(1 theme extensions excluded)

/duplicate of https://github.com/microsoft/vscode/issues/96013

@Jimmyzaurio In what language have you seen this happening? There has been similar report but this isn't easily reproducable

nvm - this happens with c, not with TS 🤷♂


Upload Button: Change it to 'open'

Change the upload button to use glyphicon glyphicon-open

Kidding, we used upload to cloud instead

heheheh I see the cloud.  Passed on local branch/

Passed on develop


Ring buffer swift3 migrate

Migrate Ring buffer to swift3 for #181

Thanks @JaapWijnen 😄 Looks great so far!
Would you be able to update the implementation of RingBuffer in the README.markdown?

@chris-pilcher Done!

Looks good @JaapWijnen!

Normally you would, and make some functions for accessing the private values you need. But as it's embedded in a playground and all these extra functions are kind of distracting from the actual way the data structure works I omitted it. And thus I had to make them fileprivate so I could play around with them in the playground.

@BenEmdon Normally you would, and make some functions for accessing the private values you need. But as it's embedded in a playground and all these extra functions are kind of distracting from the actual way the data structure works I omitted it. And thus I had to make them fileprivate so I could play around with them in the playground.


Keystore Location

Hi, you did a really great job, trying to implement it here, using the -demo-props sample, I got one problem though :+1:
saml.sso.key-manager.store-location=classpath:/config/certificate/keystore
saml.sso.key-manager.store-pass=somesecret

Using those two keywords fails into Exception

Cannot sign outgoing message as no signing credential is set in the context

I also tried this
saml.sso.key-manager.default-key=saml
But it says no entry was found though this command
keytool -list -v -keystore keystore
Says

Type Keystore : jks
Fournisseur Keystore : SUN
Votre Keystore contient 1 entrÚe(s)
Nom d'alias : saml
Date de crÚation : 11 mars 2014
Type d'entrÚe : keyEntry
Longueur de cha¯ne du certificat : 1
Certificat[1]:
PropriÚtaire : OU=oiosaml-sp, CN=null
╔metteur : OU=oiosaml-sp, O=insee-saml, C=fr
NumÚro de sÚrie : 144b1430c2d
Valide du : Tue Mar 11 14:09:25 CET 2014 au : Fri Mar 08 14:09:25 CET 2024
Empreintes de certificat :
MD5 :  CE:D5:BB:0F:B7:E7:C0:56:B5:BC:84:14:86:E1:14:7F
SHA1: 98:BE:98:62:92:EC:27:05:1F:9B:90:AC:A3:0B:72:A2:05:D5:85:3E

Is there a property I forgot to use a keystore? I first tried your example with pem key and everything worked fine on ssocircle IDP.
Thanks for sharing your work.

Hi @trblft, thank you for your kind words.
The properties that you need are:
saml:
  sso:
    key-manager:
      store-location: classpath:/config/certificate/keystore
      store-pass: somesecret
      default-key: saml
      key-passwords:
        saml: keysecret

Or in code:
serviceProvider
.keyManager()
  .storeLocation("classpath:/config/certificate/keystore")
  .storePass("somesecret")
  .defaultKey("saml")
  .keyPassword("saml", "keysecret");

You're basically missing to provide the key password, you only provided the store password.
Let me know how it goes.

Well... it works! :+1: so thanks a lot! Took me a few minutes to switch to application.yml mode. We're trying to use the -props sample here at INSEE (french national institute of statistics and demography) and we may succeed very soon. Have a nice day.

Something strange here, I may have spoken too soon, I get a kind of infinite loop redirection between two urls, here are the debug logs

2018-02-08 11:06:55.272 DEBUG 5064 --- [nio-8443-exec-3] o.s.s.saml.storage.HttpSessionStorage    : Storing message a58814ai4ff45idii0h12ic1c3c4f3 to session C8B94EDE2DB55C10359E982998BD2854
2018-02-08 11:06:55.272  INFO 5064 --- [nio-8443-exec-3] o.s.security.saml.log.SAMLDefaultLogger  : AuthNRequest;SUCCESS;0:0:0:0:0:0:0:1;https://localhost:8443;https://idp-interne.insee.test/idp/shibboleth;;;

I just call the authentication url

https://localhost:8443/saml/login?idp=https://idp-interne.insee.test/idp/shibboleth

And then back to the assertionConsumer URL it loops between those two

https://localhost:8443/saml/SAMLAssertionConsumer
https://idp-interne.insee.test/idp/profile/SAML2/POST/SSO

I guess I have to change some urls?


Guiding Center Trajectories and Fieldline tracing

This introduces the ability to compute fieldlines as well as particle trajectories using the guiding center approximation. The computation is done on the C++ side for better performance.
Some points of discussion:

How should this be tested?
I introduced boost::odeint as dependency. That library is header only and boost is probably available everywhere, but maybe worth discussing whether we should turn this into an optional part of simsopt.

I have moved everything Magnetic field related into simsopt.field. In terms of tracing, I have added right hand sides for field lines, full orbit, and guiding center. The guiding center rhs assumes \nabla p = 0 for now (an error is thrown when the general form is requested). We can add the more complex guiding center rhs once we can work with bfields from desc/spec/vmec.
For all three types of tracing, one can pass a list of phis at which the state should be recorded, as well as a list of stopping_criteria (intended for finding out when the particle is outside of a surface). There is an example in 1_simple/tracing.py.
The computation can be parallelized across an MPI communicator if desired.

The features introduced by this PR are great! Thanks!
Although I am still familiarizing myself with all the new functions, I think that I managed to add a test for energy conservation in the tests/field/test_particle.py. The conservation of energy in the full orbit case seems to be fine, with a maximum error in the 8th decimal place. I am having a bit more trouble to it in the guiding center case. @florianwechsung  could you check if there are some normalizations in the charge/velocity that should be taken into account in the test? I suspect that's the reason that some terms might not be canceling.

Thank you for adding the tests @rogeriojorge  I got them working with some very minor changes, could you have a look and double check that they make sense? I now get
Max Energy Error for full orbit     =  [-8.25014115 -8.36487096 -8.87836965 -8.36625564]
Max Energy Error for guiding center =  [-10.66350997 -10.37032219 -10.68677456 -10.77267388]                                             Max mu Error for full orbit         =  [-7.94533722 -7.99730043 -5.27184613 -8.08222078]
Max mu Error for guiding center     =  [-10.36245206 -10.06927661 -10.38571532 -10.47160711]

Lots of awesome new features here! Generally I like the division into simsopt.geo vs simsopt.field.
Comments so far:
More unit tests needed generally: e.g. for gc_to_fullorbit_initial_guesses, signed_distance_from_surface, SurfaceClassifier, LevelsetStoppingCriterion, IterationStoppingCriterion
It would be good if the extensive CI also covers the case in which boost is not present.
docstrings needed for compute_fieldlines, SurfaceClassifier, LevelsetStoppingCriterion, get_ncsx_data. The latter should explain whether or not the planar coils are included.
How about including a function to save Poincare/particle tracing results, and another function to load it and plot it?
Testing idea: verify that the field line tracing routine agrees with the magnetic axis from a known magnetic field. Could use the coil config in Cary & Hanson (1986). Rogerio has a simsopt script for these coils.
tracing.py line 24, do you mean velocity (a vector) or speed (a scalar)? In the latter case, how does gc_to_fullorbit_initial_guesses choose the gyro phase? This should be explained in the docstring.
trace_particles and trace_particles_starting_on_axis: 9000 eV is a weird default. How about 3.5 MeV.
The docstring for trace_particles should give explicit expressions for the guiding center equations used, since there are several variations. (E.g. whether or not a parallel drift is included, whether or not the B||* factor is included)
Does signed_distance_from_surface handle both the case in which Gammadash1 cross Gammadash2 points outward and the case in which it points inward? Both cases are possible, right?
It looks like signed_distance_from_surface is using surface.normal(). As I understand it, normal() is not the unit normal. Should signed_distance_from_surface be using the unit normal? It would be good if the base Surface class could return the unit normal. Users might be confused and think that normal() is a unit normal, so perhaps there is a clearer name for normal().
In my experience, plasma folks usually talk about the "parallel velocity" rather than "tangential velocity". So consider renaming "tangential_velocities" -> vpar or v_parallel?
Also, here are some comments more about MagneticField and interpolation code that's already in master, but with some relevance to this PR:
InterpolatedField needs more documentation. How are the interpolation nodes specified? What interpolation methods are used exactly? Documentation is needed both in the python and C++ source.
It would be good to have unit tests for the interpolation machinery, besides just field.test_magneticfieldstest_interpolated_field_convergence_rate / close.
Need user guide documentation for MagneticField and BiotSavart, similar to what is present for surfaces/curves.
In this, the documentation for set_points_cyl and B_cyl should say what order the coordinates are. I presume the order is (R, phi, Z), but it would be good to display this clearly.
Shorten name of magneticfieldclasses.py ? Maybe fields.py?
Does the interpolation machinery know that the phi coordinate is different from R and Z in that things are periodic in phi?
It's generally confusing that in some parts of simsopt (e.g. tracing.cpp line 155), phi is a coordinate which goes up to 2pi, whereas in the Surface parts of simsopt, phi means an angle that goes up to 1. VMEC uses angles that go up to 2pi, and it is often convenient to allow the cylindrical coordinate phi and surface parameter phi to be the same.

Thank you for the detailed comments. I took care of most of them. A few more detailed responses/questions:

How about including a function to save Poincare/particle tracing results, and another function to load it and plot it?

I added a routine to create the typical poincare plot in matplotlib. What did you have in mind for saving/loading? The results are just numpy arrays, so saving/loading anything is as easy as np.save(data, filename), and I don't think we need a dedicated function for that.

Testing idea: verify that the field line tracing routine agrees with the magnetic axis from a known magnetic field. Could use the coil config in Cary & Hanson (1986). Rogerio has a simsopt script for these coils.

Added a test for the NCSX configuration for which we have the magnetic axis.

trace_particles and trace_particles_starting_on_axis: 9000 eV is a weird default. How about 3.5 MeV.

I added a simsopt.util.constants file that includes charges, mass, and energy for some typical particles. I use an alpha particle as default now.

Does signed_distance_from_surface handle both the case in which Gammadash1 cross Gammadash2 points outward and the case in which it points inward? Both cases are possible, right?

Yes it works in either case. covered in tests now.

It looks like signed_distance_from_surface is using surface.normal(). As I understand it, normal() is not the unit normal. Should signed_distance_from_surface be using the unit normal? It would be good if the base Surface class could return the unit normal. Users might be confused and think that normal() is a unit normal, so perhaps there is a clearer name for normal().

Added a unitnormal function.

Regarding the non PR specific comments:

InterpolatedField needs more documentation. How are the interpolation nodes specified? What interpolation methods are used exactly? Documentation is needed both in the python and C++ source.

Opened an issue for this #103

It would be good to have unit tests for the interpolation machinery, besides just field.test_magneticfieldstest_interpolated_field_convergence_rate / close.

see #103
Need user guide documentation for MagneticField and BiotSavart, similar to what is present for surfaces/curves.
opened #104

In this, the documentation for set_points_cyl and B_cyl should say what order the coordinates are. I presume the order is (R, phi, Z), but it would be good to display this clearly.

fixed

Shorten name of magneticfieldclasses.py ? Maybe fields.py?

I agree that a shorter name would be good. We could also separate them into reiman.py, toroidal.py and dommaschk.py. That would be more consistent with how we keep surfaces and curves separate.

Does the interpolation machinery know that the phi coordinate is different from R and Z in that things are periodic in phi?

It doesn't, since it's a general interpolant on a box in 3d. The only benefit of adding the periodic-in-phi special case would be that we could save ourselves function evaluation on one side of a box domain, which is fairly negligible.  For other interpolants (e.g. ones using a fourier expansion in phi), this is of course different.

It's generally confusing that in some parts of simsopt (e.g. tracing.cpp line 155), phi is a coordinate which goes up to 2pi, whereas in the Surface parts of simsopt, phi means an angle that goes up to 1. VMEC uses angles that go up to 2pi, and it is often convenient to allow the cylindrical coordinate phi and surface parameter phi to be the same.

I agree that it's a bit confusing. The reasoning for this is twofold:

in general this is really just a parameter, not a physical angle. take CurveXYZFourier for example, there is no physical angle that \phi corresponds to
it simplifies integrals: if phi goes from 0 to 2pi, every integral needs to be normalised by 2pi. Where as now, we just write curve_length = np.mean(np.linalg.norm(curve.gammadash(), axis=1)) etc, no normalisation required.

Going through all curve and surface classes is not something I'm particularly keen on, so I'd only want to change this if people have very strong feelings about it (/ or if someone else volunteers to do it).

Thanks for all these improvements. A few more comments:

Can the interpolated field take advantage of nfp-symmetry and stellarator-symmetry, so phi only needs to cover half a field period rather than all of 2pi?

Rather than doubling the number of extensive-CI jobs by having "boost: [true, false]" in the matrix, consider adding just 1 or a few runs as in https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-including-additional-values-into-combinations

Since the interpolant does not know about periodicity in phi, is there any loss in accuracy for high-order interpolation near the "seam" at phi=0 and 2pi, since the interpolant does not take advantage of data on grid points "after" phi=2pi or "before" phi=0?

Consider renaming SurfaceClassifier -> SignedDistance, since the latter name is more general and it could be useful for other applications? Also consider moving it from simsopt.field to simsopt.geo since the signed distance function is a geometric concept and not really related to magnetic fields.

Thanks @landreman

Can the interpolated field take advantage of nfp-symmetry and stellarator-symmetry, so phi only needs to cover half a field period rather than all of 2pi?

Added that capability.

Rather than doubling the number of extensive-CI jobs by having "boost: [true, false]" in the matrix, consider adding just 1 or a few runs as in https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-including-additional-values-into-combinations

Only added two extra jobs not involving boost now, all other jobs now also have boost.

Since the interpolant does not know about periodicity in phi, is there any loss in accuracy for high-order interpolation near the "seam" at phi=0 and 2pi, since the interpolant does not take advantage of data on grid points "after" phi=2pi or "before" phi=0?

No, we have same order everywhere. Periodicity doesn't affect this type of interpolant, we always just rely on the values in the current 'cell', no matter if that cell is on the boundary of the r,phi,z cube or not.

Consider renaming SurfaceClassifier -> SignedDistance, since the latter name is more general and it could be useful for other applications? Also consider moving it from simsopt.field to simsopt.geo since the signed distance function is a geometric concept and not really related to magnetic fields.

The SurfaceClassifier is actually specific to computing the distance to a surface, so I don't think it should be renamed. The general concept here is the LevelsetStoppingCriterium, and one could create other types of classifiers which can then be passed to that criterium. I have moved the SurfaceClassifier into simsopt.geo.

Thanks @landreman and @rogeriojorge for your input. I merged rogerios branch into this branch, so github requires a fresh review to  merge this one.