[analysis_server] An error occurred while handling workspace/executeCommand request

Saving a file in VS Code (with the "fix on save" enabled) with the following code results in An error occurred while handling workspace/executeCommand request
void main() {
  // ignore: unnecessary_string_escapes
  const somePath = 'C:\some\path.dart';

  final regexp2 = RegExp('(.pub-cache/|\Pub\Cache\)');
  final regexp4 = RegExp('(.pub-cache/||\\Pub\\Cache\\))');  // <-- removing this line removes the exception
}

Full stacktrace
[Error - 16:09:15] Request workspace/executeCommand failed.
  Message: An error occurred while handling workspace/executeCommand request
  Code: -32001
[Error - 16:09:15] An error occurred while handling workspace/executeCommand request: Bad state: Can't create both a generic file edit and a dart file edit for the same file
#0      BulkFixProcessor._fixSingleError (package:analysis_server/src/services/correction/bulk_fix_processor.dart:743:7)
<asynchronous suspension>
#1      BulkFixProcessor._fixErrorsInLibraryUnit (package:analysis_server/src/services/correction/bulk_fix_processor.dart:612:7)
<asynchronous suspension>
#2      BulkFixProcessor.fixErrorsForFile (package:analysis_server/src/services/correction/bulk_fix_processor.dart:262:9)
<asynchronous suspension>
#3      OperationPerformanceImpl.runAsync (package:analyzer/src/util/performance/operation_performance.dart:172:14)
<asynchronous suspension>
#4      IterativeBulkFixProcessor.fixErrorsForFile.<anonymous closure> (package:analysis_server/src/services/correction/bulk_fix_processor.dart:995:23)
<asynchronous suspension>
#5      OperationPerformanceImpl.runAsync (package:analyzer/src/util/performance/operation_performance.dart:172:14)
<asynchronous suspension>
#6      _FixAllOperation._computeEditsImpl (package:analysis_server/src/lsp/handlers/commands/fix_all.dart:128:19)
<asynchronous suspension>
#7      TemporaryOverlayOperation.lockRequestsWithTemporaryOverlays.<anonymous closure> (package:analysis_server/src/lsp/temporary_overlay_operation.dart:94:16)
<asynchronous suspension>
#8      LspAnalysisServer.lockRequestsWhile (package:analysis_server/src/lsp/lsp_analysis_server.dart:521:14)
<asynchronous suspension>
#9      _FixAllOperation.computeEdits (package:analysis_server/src/lsp/handlers/commands/fix_all.dart:103:12)
<asynchronous suspension>
#10     FixAllCommandHandler.handle (package:analysis_server/src/lsp/handlers/commands/fix_all.dart:54:18)
<asynchronous suspension>
#11     ServerStateMessageHandler.handleMessage (package:analysis_server/src/lsp/handlers/handlers.dart:357:11)
<asynchronous suspension>
#12     LspAnalysisServer._handleRequestMessage (package:analysis_server/src/lsp/lsp_analysis_server.dart:997:20)
<asynchronous suspension>
#13     LspAnalysisServer.handleMessage.<anonymous closure>.<anonymous closure> (package:analysis_server/src/lsp/lsp_analysis_server.dart:452:15)
<asynchronous suspension>
#14     OperationPerformanceImpl.runAsync (package:analyzer/src/util/performance/operation_performance.dart:172:14)
<asynchronous suspension>
#15     LspAnalysisServer.handleMessage.<anonymous closure> (package:analysis_server/src/lsp/lsp_analysis_server.dart:435:11)
<asynchronous suspension>

Reproduces stably, Dart SDK version: 3.3.0 (stable) (Tue Feb 13 10:25:19 2024 +0000) on "macos_x64"

@DanTup fyi

@incendial I don't seem to be able to reproduce. The fixes run (the backslashes are removed), but no errors:
https://github.com/dart-lang/sdk/assets/1078012/788d3fdc-cbdc-4cf0-b655-5d0a38d5fc12
Can you reproduce in a new project, or only a specific one? Could you show a list of all the diagnostics you see for this file (and which fixes appear for each of the diagnostics)? It seems like we're trying to use both a FileEditBuilder and DartFileEditBuilder on the same file but I'm not sure which fix the FileEditBuilder is coming from.

btw, looks like I don't have any diagnostics on the last line which might be why I'm not triggering it - I presume if removing that line fixes it, you might have a diagnostic/fix showing up for it?

Can you try enabling "use-raw-strings"?

@bwilkerson this is happening because the fixes use a mix of generic and Dart file builders. If there is a fix using each in the same file it results in this error when trying to fix both (both for the LSP server's "fix all" and dart fix).
For example remove_unnecessary_string_escapes uses the generic builder:
https://github.com/dart-lang/sdk/blob/22d75929bd30f7d9246f7ec31a70f834113f7464/pkg/analysis_server/lib/src/services/correction/dart/remove_unnecessary_string_escape.dart#L32
But convert_to_raw_string uses a Dart builder:
https://github.com/dart-lang/sdk/blob/22d75929bd30f7d9246f7ec31a70f834113f7464/pkg/analysis_server/lib/src/services/correction/dart/convert_to_raw_string.dart#L44
I thought the right fix would be for the fixes to always use Dart edit builders and we should change the interface so they can't accidentally create other kinds of edit builders. However, we have a fix "Ignore diagnostic in analysis_options.yaml" which is a Dart fix but edits a non-Dart file and I realise that's not quite right.
One possibility would be to have addGenericFileEdit() return a Dart edit builder if called for a Dart file - however a Dart edit builder is not currently a superclass of a generic edit builder. So another option could be to just remove addGenericFileEdit entirely and force all code through a specific edit builder (Dart or YAML, and if we have other file types, make more specifically-named methods for each of them).
Any thoughts/opinions?

Maybe a slightly simpler idea: add an assert  to addGenericFileEdit to ensure it's not called for Dart or YAML files. As long as all callers have some test it should avoid this happening accidentally (but avoids having to make a breaking API change).

For example remove_unnecessary_string_escapes uses the generic builder

That's definitely a bug. The fix clearly only applies to Dart files.

Maybe a slightly simpler idea: add an assert to addGenericFileEdit to ensure it's not called for Dart or YAML files.

I like that idea.


Add conditional vue pt

Thank you for your contribution to the FreeCodeCamp Portuguese Translation!
Contributions like yours help millions of users learn to program in their native language.
Hope you continue to help us with more contributions!


Multiple redirect url not working in slack sso

When we try sso it works fine for the first redirect URL and when doing sso for the second one we are getting {"ok":false,"error":"bad_redirect_uri"}. Please help us in resolving the issue

Hi @iLvrge, thanks for asking the question! Can you please elaborate more on your issue? Does the SSO here mean the one you use for Slack workspace/organization login?

Ans to your question is Yes,
I have added 2 links in Redirect URLs.  The first one is working but when I try with the second one it is giving me the error bad_redirect_uri .

@iLvrge When you have multiple Redirect URIs, having redirect_uri parameter in the OAuth flow is required. Set the value in your Bolt app configuration: https://slack.dev/java-slack-sdk/guides/app-distribution#slack-config-for-distributing-your-slack-app

I am adding, and it works with the first one not with the second one.

Just in case, I created a simple OAuth app and saw how it works in the scenario. However, I didn't find any issues with multiple Redirect URIs.
Please make sure if your redirect_uri parameter is a complete URL like https://xxx.ngrok.io/slack/oauth/callback.
Also, I recommend checking the actual URL that your app generates again. The generated URL https://slack.com/oauth/v2/authorize?client_id=... must have redirect_uri as part of it in this scenario (I'm guessing your app does not generate the authorize URL with redirect_uri).

Thanks Seratch, My issue is fixed.


Lowered SAS version

API change check
API changes are not detected in this pull request.

TODO create GitHub issue for STG 94 release prep and add to comments above SAS version in Constants

/azp run net - storage - tests


on clean install, notifications about embedded T2 ethernet controller

on test 2018 13" on t2-atomic-bluefin-dx, after a clean image install a couple weeks ago, it's notifying about the embedded ethernet controller that should have modules blaclisted

I believe https://github.com/lauretano/t2-atomic/commit/1832947700268f9a457158a62470230943bde4da resolves this, awaiting testing

that commit did fix this, closing this issue.


Implement TURN

This is a covering ticket for all the things we need to do.
pion/webrtc

[x] Pass TURN configuration from pion/webrtc to pion/ice
[x] Add support for ICETransportPolicy so we can force TURN

pion/ice

[x] TURN MVP. Add basic TURN support via pion/turnc
[ ] Add TURN server to travis-ci, implement a version and confirm it can't regress
[ ] Update checklist/nomination logic so TURN is last (currently we just take first success)

#42 may already solve the 3rd point

@hugoArregui I am going to work on getting TURN/STUN tested in travis-ci. This is probably going to take me 2-3 days.
Would you be up for getting your checklist stuff re-merged? Sorry for all the breakage, I would love to work together closely and get both your changes in.

@enobufs Any other next steps you can think of?  I feel pretty good about where we are at TURN wise!

@Sean-Der @ernado @hugoArregui MANY Thanks to all of you for making this happen! I am sure many pion users will be very happy about the TURN support! I will be updating my app and test the new feature. My time this week is very limited because I have to move into my new apartment this weekend tho, I should be able to get some feedback in the week of June 2)
I guess the next step is to further improve ICE including @hugoArregui was planning to do (checklist stuff). Now we have relay candidate, a proper priority control in candidate nomination (and quality assurance) would be desired. Now we have another expert @ernado - awesome! I'm very hopeful that pion would yield very competitive connectivity over other webrtc libraries!

@Sean-Der sure! Let's ensure we are on the same page regarding the implementation though, the thing about the heuristic I wrote in the PR is now we have trickle.. so I'm not sure if it holds.. maybe I can add a "mininumCheckWait" (sorry, awful name) to wait a bit for candidates?


Pre-built binaries in 0.18.8 are not installable

Hello,
I have been looking at this for a little while and I think despite building pre-built binaries for a number of architectures, they are not usable by NPM. I think there is a bug in the version of node-pre-gyp that is used in libxmljs version 0.18.8 (0.9.1).
In node-pre-gyp 0.9.1, the command was including everything inside of the sibling directories of the build path. So even though it should include build/Release/*, the package actually includes build/*. You can see this in all of the archives that are downloaded.
This bug causes two issues:

It makes the tar.gz uninstallable because of another bug during installation where the untarring function doesn't create intermediate folders (it only creates files) .
It makes the binary distribution very large.

You can reproduce this by:
mkdir libxmljstest
cd libxmljstest
npm install --save<EMAIL_ADDRESS>
><EMAIL_ADDRESS>install /export/node_modules/libxmljs
> node-pre-gyp install --fallback-to-build --loglevel http

node-pre-gyp http GET https://github.com/libxmljs/libxmljs/releases/download/v0.18.8/node-v57-linux-x64.tar.gz
node-pre-gyp http 302 https://github.com/libxmljs/libxmljs/releases/download/v0.18.8/node-v57-linux-x64.tar.gz
node-pre-gyp http 200 https://github.com/libxmljs/libxmljs/releases/download/v0.18.8/node-v57-linux-x64.tar.gz
node-pre-gyp ERR! Pre-built binaries not installable for<EMAIL_ADDRESS>and<EMAIL_ADDRESS>(node-v57 ABI, glibc) (falling back to source compile with node-gyp)
node-pre-gyp ERR! Hit error ENOTDIR: Cannot cd into '/export/node_modules/libxmljs/build/Release'

<Source build follows>

Even though the binary is available for this architecture, it refuses to use the binary. I noticed that in later releases libxmljs downgraded to node-pre-gyp ~0.6.37. Not sure if this has the same bug, but I suspect it does. I think I have a fix, but wanted to check first to see if I was missing something.
# cat /etc/issue
Ubuntu 18.04 LTS \n \l
# node --version
v8.10.0
# npm --version
3.5.2

same here：
CentOS release 4.3 (Final)
Node v8.11.1
npm 5.8.0

It looks like someone else already updated this https://github.com/libxmljs/libxmljs/pull/523. I think this should be closed out now.
I just tried on node 8 and node 10 and both installs worked.


updated docs for CloudAMQP configuration

Merged.

Boom: http://docs.masstransit-project.com/en/latest/configuration/transports/rabbitmq.html?highlight=ssl#rabbitmq-with-cloudamqp

rock on, thanks for the help on this


add cdnbase to default

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:
/kind api-change
/kind backend-change
/kind ui-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.qevan seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Would be great to include an example project

looking at the video is a big hard to see what this library actually does

sorry I just saw the link to the example project, but maybe it's better to directly integrate it to this repo ?

@brightfuture Yes, it's in the Demo section. I put in a different repo to not pollute this repo and associated package.


use output as markdown in md cell

Is there a way to get markdown for the reference that could be injected into another markdown block?

I'm not sure I understand what you would like to do, is this referring to dois or a more general request?

I was playing with PlutoTeachingTools.jl, specifically footnotes and it seemed like a good use case for ShortCodes but would require using a ShortCodes result in a markdown block. I couldn't figure out the syntax and looking at show, figured it's due to the current output format designed to work in a code cell. Any way to reuse in markdown?

Not sure if this was very clear. Is the output of DOI reusable in other markdown, and if so how should it be done?

Is this what you would like to do? (embedding in a markdown cell in Pluto:
md"""Embedded in Markdown: $(DOI("10.1137/141000671"))

This looks like it already works?"""


Cow: Watch chewie-wxt8fd.flutterflow.app

Cow requests the watch of the watch_keyword chewie-wxt8fd\.flutterflow\.app. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

chewie-wxt8fd\.flutterflow\.app has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


System keymaps overridden

The system keymaps appear to have been overridden in the latest release. In all other applications using cmd + ` scrolls through all the open windows in that application. In the latest version it splits the editor window.

VSCode Version: 1.11
OS Version: OSX 10.10.5

Steps to Reproduce:

Open VSCode
Open another VSCode window
Attempt to scroll through the VSCode windows using cmd + `
It splits the current editor and doesn't scroll though open VSCode windows

@jamesRaybould Which keyboard layout (language, region) do you have?

Its British - PC - I've attached the keylayout I'm using in the operating system
British (PC 105).keylayout.zip

@jamesRaybould Thank you for the extra information. Could you please also attach how our C++ node module detects your keyboard layout:

open an editor
press F1 > Developer: Inspect Keyboard Mappings
save the information to a file and attach it here.

I will then take a look and check if the split editor action (bound to key code combinations cmd+\) is correctly mapped.

However, most likely:
Please note that we do not ship with keyboard layout specific default keybindings, and therefore some actions might be unbound by default, or they might be bound to unhappy / unfortunate / poor key combinations. This is something you can upvote in #1240

vscode_keymap.zip

@jamesRaybould I believe this might have been fixed with the fix for #24153 i.e. on ISO keyboards Chromium swaps the KeyboardEvent.code of [Backquote] and [IntlBackslash] which produce ` and \, so it sounds like we would get confused about cmd+` and cmd+\ due to this. We have added a workaround on our side where we "unswap" them.
In certain cases (where the computer has an ANSI built-in keyboard and an ISO keyboard is attached to it), it might take up to 3 seconds after the first keypress for us to detect this case and apply the workaround.
Could you please try again in the latest stable release or in the insiders version ?
Here is what I am trying and cmd + ` now cycles through the windows (i.e. works for me):

British - PC keyboard layout
attached external ISO keyboard:

enabled the setting of cmd+` moves focus to the next window


CFTimeIndex Resampling

I would appreciate some feedback on why this implementation for CFTimeIndex resampling doesn't match pandas' output 100%.

[x] Tentative attempt at addressing #2191 (resampling CFTimeIndex). Downsampling produces results that match pandas' results in all the tests done thus far. However, upsampling has trouble assigning the right values to the right bins.
[x] Tests (test_cftimeindex_resample.py) created for standard calendars but not for non-standard calendars (360 days etc.). Contents from test_cftimeindex_resample.py will be inserted into test_dataarray.py and  test_cftimeindex_resample.py will be deleted once resampling implementation is finalized. Files found in the tests/temp folder is meant to highlight resampling discrepancies between pandas and this implementaion. Both the files and the folder will be removed once resampling implementation is finalized.
[x] Not fully documented. Docstrings have yet to be added to resample_cftime.py. There were no doctrings from https://github.com/pandas-dev/pandas/blob/master/pandas/core/resample.py (which is where the codes were ported from) that could be conveniently copied.

Hello @jwenfai! Thanks for submitting the PR.

In the file xarray/core/common.py, following                are the PEP8 issues :

Line 720:80: E501 line too long (82 > 79 characters)

There are no PEP8 issues in the file xarray/core/groupby.py !

There are no PEP8 issues in the file xarray/core/resample.py !

There are no PEP8 issues in the file xarray/core/resample_cftime.py !

In the file xarray/tests/temp/cftime_resample_pandas_comparison.py, following                are the PEP8 issues :

Line 8:34: E226 missing whitespace around arithmetic operator
Line 18:34: E226 missing whitespace around arithmetic operator
Line 31:34: E226 missing whitespace around arithmetic operator
Line 58:34: E226 missing whitespace around arithmetic operator
Line 64:34: E226 missing whitespace around arithmetic operator
Line 69:80: E501 line too long (89 > 79 characters)
Line 71:34: E226 missing whitespace around arithmetic operator
Line 72:80: E501 line too long (95 > 79 characters)
Line 74:80: E501 line too long (109 > 79 characters)
Line 82:80: E501 line too long (84 > 79 characters)
Line 83:34: E226 missing whitespace around arithmetic operator
Line 84:54: E261 at least two spaces before inline comment
Line 90:80: E501 line too long (117 > 79 characters)
Line 91:80: E501 line too long (110 > 79 characters)
Line 92:80: E501 line too long (98 > 79 characters)
Line 93:80: E501 line too long (84 > 79 characters)
Line 94:34: E226 missing whitespace around arithmetic operator
Line 94:80: E501 line too long (98 > 79 characters)
Line 101:80: E501 line too long (84 > 79 characters)
Line 102:80: E501 line too long (84 > 79 characters)
Line 103:34: E226 missing whitespace around arithmetic operator
Line 108:34: E226 missing whitespace around arithmetic operator
Line 114:37: E226 missing whitespace around arithmetic operator
Line 117:34: E226 missing whitespace around arithmetic operator

In the file xarray/tests/temp/cftime_resample_tests.py, following                are the PEP8 issues :

Line 7:37: E226 missing whitespace around arithmetic operator
Line 17:37: E226 missing whitespace around arithmetic operator
Line 30:37: E226 missing whitespace around arithmetic operator
Line 57:37: E226 missing whitespace around arithmetic operator
Line 63:37: E226 missing whitespace around arithmetic operator
Line 68:80: E501 line too long (89 > 79 characters)
Line 70:37: E226 missing whitespace around arithmetic operator
Line 71:80: E501 line too long (100 > 79 characters)
Line 73:80: E501 line too long (114 > 79 characters)
Line 82:37: E226 missing whitespace around arithmetic operator
Line 83:80: E501 line too long (84 > 79 characters)
Line 89:80: E501 line too long (122 > 79 characters)
Line 90:80: E501 line too long (115 > 79 characters)
Line 91:80: E501 line too long (99 > 79 characters)
Line 93:37: E226 missing whitespace around arithmetic operator
Line 102:37: E226 missing whitespace around arithmetic operator
Line 105:80: E501 line too long (83 > 79 characters)
Line 107:37: E226 missing whitespace around arithmetic operator
Line 113:64: E226 missing whitespace around arithmetic operator
Line 114:64: E226 missing whitespace around arithmetic operator
Line 121:64: E226 missing whitespace around arithmetic operator
Line 122:64: E226 missing whitespace around arithmetic operator
Line 133:80: E501 line too long (145 > 79 characters)
Line 136:80: E501 line too long (164 > 79 characters)
Line 141:80: E501 line too long (105 > 79 characters)
Line 145:80: E501 line too long (91 > 79 characters)
Line 149:80: E501 line too long (105 > 79 characters)

In the file xarray/tests/test_cftimeindex_resample.py, following                are the PEP8 issues :

Line 44:45: E226 missing whitespace around arithmetic operator
Line 49:42: E226 missing whitespace around arithmetic operator
Line 72:80: E501 line too long (83 > 79 characters)

@spencerkclark Thanks for the detailed review! I'll fix up my code over the next few days.
I haven't completely solved the upsampling issue yet but I think I might have some clues as to what's happening. Timedelta operations on cftime.datetime does not always return correct values.
The issue can be sidestepped by shifting the the bins 1 second forward for closed=='right' and 1 second back for closed=='left' in groupby.py, but this obviously introduces issues for resampling operations at the second and microsecond resolution. This workaround doesn't pass all the tests. An extra time bin is still sometimes created. You'll see what I mean when I make a new commit sometime next week.

@jwenfai thanks for the updates.  It looks like there are some merge conflicts that are preventing our CI from running.  Could you please resolve those when you get chance, so we can see those results?

@spencerkclark Sorry about that, must be a couple of commits behind. Should be resolved now.

Yes, I noticed this too.  I think it's related to changes made here: https://github.com/pandas-dev/pandas/pull/24347.  At least in the test cases that I've run, I've only seen it make a difference in the NaN placement at the end of the time series.
For example with pandas 0.23.4:
In [1]: import xarray as xr; import pandas as pd

In [2]: nptimes = pd.date_range('2000', periods=2000)

In [3]: nptime_da = xr.DataArray(range(2000), [('time', nptimes)])

In [4]: nptime_da.resample(time='4AS').mean('time')
Out[4]:
<xarray.DataArray (time: 3)>
array([ 730., 1730.,   nan])
Coordinates:
  * time     (time) datetime64[ns] 2000-01-01 2004-01-01 2008-01-01

and with pandas master:
In [4]: nptime_da.resample(time='4AS').mean('time')
Out[4]:
<xarray.DataArray (time: 2)>
array([ 730., 1730.])
Coordinates:
  * time     (time) datetime64[ns] 2000-01-01 2004-01-01

I feel like the result under pandas master makes more sense, given the input array, whose final date is 2005-06-22.  Adding an additional bin labeled 2008-01-01 to the resampled time series seems superfluous given that with the default label='left' it's clear no data from the original time series would fall in that bin.

So I think the way you have things written now in _get_time_bins makes sense, though this subtle change in behavior on the pandas side makes testing against different releases of pandas a little trickier.

Glad to see that I'm not the only one getting different results. And I agree (biased as I am) that the additional bin at the end of resampled time series is superfluous.
If pandas master with the altered resampling logic will be the definitive version going forward, should development of CFTimeIndex resampling be suspended until this version of pandas master is released and xarray uses it as a dependency?
On a somewhat related note, looking over the latest pandas master resample.py made me realize that
https://github.com/pydata/xarray/blob/4317c697900c80604dee793ffc1186e5c57a03fd/xarray/core/resample_cftime.py#L114-L118
is now wrong due to changes made 16 days ago (https://github.com/pandas-dev/pandas/issues/24127) . Since non-integer offset frequencies are not supported by BaseCFTimeOffset, (is_day and offset.n == 1 should just be is_day), which can be further simplified to:
    if isinstance(offset, CFTIME_TICKS):
        return _adjust_dates_anchored(first, last, offset,
                                      closed=closed, base=base)

If pandas master with the altered resampling logic will be the definitive version going forward, should development of CFTimeIndex resampling be suspended until this version of pandas master is released and xarray uses it as a dependency?

I think it is OK to continue working here, with the aim of implementing resample for cftime that is closest to the most up-to-date pandas version.  We can add code to skip tests that depend on this behavior if the version of pandas is not recent enough (see an example of doing this here).  As we're working before version 0.24 of pandas is released we can keep an eye on our "py36-pandas-dev" CI build listed under the "Allowed Failures" section in Travis.

So the crux of the problem now seems to be in generating first_items; this is the Series that is used for both upsampling and downsampling a DataArray in xarray.  For data indexed by a DatetimeIndex, it is straightforward to generate this Series (it just takes the construction of a simple Series with np.arange and the reference index, the construction of a pandas.Grouper object, and a call to groupby with the method first).  In xarray, downsampling uses both the values (to define the groups) and index (to define the labels) of this Series, while upsampling only uses the index.
For data indexed by a CFTimeIndex, we do not have the luxury of a formal Grouper object; however, if we can create this first_items Series accurately, I think all other results of resample in xarray should follow.
I've put together a gist which compares the first_items Series generated with pandas with that generated by the cftime logic (the output of running the tests is also included).  I've tried to use a fairly challenging set of initial time indexes as well as resample frequencies (different than what are currently used in the tests); there appear to be many mismatches under the "upsampling" case, but also a few errors show up in the "downsampling" case (to some extent I think these are related to the omission of the _adjust_bin_edges method, which it turns out I do think we may need).  In theory though, because of how this first_items Series is created in the DatetimeIndex case, I don't think the way we create it in the CFTimeIndex case should depend on whether the length of the reference index is greater than or less than the length of the resample labels (upsampling or downsampling is determined instead by the resampling method used).
This inspired the alternative solution proposed in the second part of the gist (I've also added back in a call to a cftime version of the _adjust_bin_edges method); in this case there is no dependence on the relative lengths of the reference index and resample labels, and all of the test cases I've tried so far pass.
Let me know if this alternative solution makes sense.  Digging in to the guts of the resample code in pandas/xarray is still fairly new for me too, so I could be missing something.  In the gist I'm using this branch of xarray, the development version of pandas, and the latest version of cftime.  Thanks again for your hard work on this!

I'm on a break right now and I'll look more closely at the alternative solution when I'm back, but from what I've read in your comment the solution makes sense. Also, nice job catching why _adjust_bin_edges was needed and writing a comprehensive explanation in the code.

I'm on a break right now and I'll look more closely at the alternative solution when I'm back, but from what I've read in your comment the solution makes sense.

No worries!  I just wanted to get these thoughts down when I had some time.  No rush to make any updates.

It looks like tests are passing now. I'm going to give this another look over and then (probably) merge

I'm going to merge this when tests pass

Sounds good @shoyer, thanks for bringing this to the finish line.

All tests passed. Thanks, @spencerkclark and @shoyer, for all the help!

thanks @jwenfai and @spencerkclark !


Explicitly set host header for s3 origin

Background

I ran into some issues when I started forwarding the Host header from cloudfront. It causes signature invalidation on the request because the host is used to generate the signature
https://github.com/danielcondemarin/serverless-next.js/issues/408

Change

Explicitly set the host header when forwarding requests to S3 origin

Testing

Tested on my own website. Confirmed the fix

Thanks @stan-sack for PR'ing. I've added a test and also set the host header for dynamic HTML pages which was missing.


linuxPackages.virtualboxGuestAdditions: apply mp-r0drv-linux.c patch

These don't use a the virtualbox sources, but an iso as src, and we need
to add the kernel 5.3 patch aswell.
As for some reason the source files are present on the .iso with Windows
Line endings (sic!), call dos2unix first.
Unfortunately, we can't use the same kernel-5.3-fix.patch as virtualbox
itself, as some files are missing and paths are different.

Motivation for this change
Fixes https://github.com/NixOS/nixpkgs/issues/65689.
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)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @wkral @ambrop72

what do you mean by "patch for host virtualbox"?

The commit from #69323 as it hasn't been built into unstable channel yet. Since my system is pointed at that channel I figured it would isolate these changes without introducing anything from head of master since it seems there are a lot of tests failing on hydra right now.

Alright :-)

Backported to 19.09 in 9c9bd273c399270d330db970eb10d060519df1d2.


[VL] Avoid holding stream iterators in VeloxExecutionCtx

@zhztheplayer could you help take a look? thanks!


Update Packet metadata generation based on feedback

Summary
Adopt changes from https://github.com/mattermost/mattermost/pull/27490
Ticket Link
https://mattermost.atlassian.net/browse/MM-59082

Thanks @hanzei I updated my original PR


[v2] Render called twice in index.js

Hello,
After testing the version one of this Gatsby starter, I am testing the version 2.
With version two, the render method is called Twice, and I can't see why.
If I add {console.log("Render called!")} before the link for example, in version one this message is printed by console just one time, but twice in version two.
How I can fix this?
import React from 'react'
import { Link } from 'gatsby'

import Layout from '../components/layout'

const IndexPage = () => (
  <Layout>

Hi people

Welcome to your new Gatsby site.

Now go build something great.

     // Added line
     {console.log("Render called!")}
    <Link to="/page-2/">Go to page 2</Link>
  </Layout>
)

export default IndexPage

Well, I can see that this only happens in develop mode.
When you build, this doesn't happen.


fix(side-menu): slots

Describe pull-request
Aligning slots naming per our convention
Solving issue
Fixes: DTS-1957
What was done:

document all slot and their names in readme files
use <default> to indicate those are not named for purpose, can be used for side-menu sub-components ect...
show the user only Notes they really need to know about
added an additional sentence about why we show only some readmes in the Notes tab in Storybook

How to test

Go to Netlify PR preview link
Check that the Side-menu component and pattern stories still look and function OK.

Suggested test steps

[ ] Browser testing (Chrome, Safari, Firefox)
[ ] Keyboard operability
[ ] Interactive elements have labels.
[ ] Storybook controls
[ ] Design/controls/props is aligned with other components
[ ] Dark/light mode and variants
[ ] Input fields – values should be displayed properly
[ ] Events

The Side Menu does not close when clicking the collapse button on the "Many Navigation Items" pattern example, but it does close in our current Storybook link. Should this be addressed?
Side.Menu.not.closing.Many.Nav.Items.example.mp4

Fixed in another issue, just needed a rebase.


Glowup and include context on group invite landing page and unfurl

[x] Group Invite design styling on mobile
[ ] Group Invite design styling on desktop
[ ] Adapt DM screen with the same styling on mobile
[ ] Adapt DM screen with the same styling on desktop
[ ] Troubleshoot the onXmtp and canMessage variables to display the buttons vs links to the App Store
[ ] Design and implement the og:image/frame

I'm not sure if I understand the logged in/logged out states correctly but here's what I got.
We should make this look similar to how they look in the app but pop the Converse logo with the word "Converse" on the web view.

@lourou would you be able to look into this Converse website  request after the requests UI work is complete? I've added you to the repo
I believe the group context info is all available. If not, we can descope from the designs rather than invest in piping it through.
This should also extend to the opengraph metadata when one of these links is shared. Ideally, these links unfurl and include all of the above context information in an approximately equivalent design.

@saulmc sure thing, will look into this!

@saulmc do we want to generate on the fly and show a custom og:image containing the group icon, converse logo and group description inside the image, so that users see this when shared?

Hey @darickdang, I just finished implementing the group invite styling on mobile. Here's a preview on an iPhone 15 Pro screen. I also made sure it fits on iPhone SE and Mini. Do you see anything that needs to be changed?
<img src="https://github.com/user-attachments/assets/ae3cce9a-84b4-4fa9-ab8f-ae00cc61c400" width=350" />

thanks @saulmc 🙌
re: the generic og:image loading loop issue inside the app, I created the issue here


Anki FSRS Visualizer not matching up with Py-fsrs

Hello,
I'm trying to use the Anki FSRS Visualizer to fine-tune the perfect algorithm for my Python code that uses Python FSRS, but I'm having a problem. The results that show in the Anki FSRS Visualizer do not match the results from my Python code. I'm particularly looking at the interval data.
Here are my preferences:
0.4000, 0.5000, 1.0000, 2.0000, 1.0000, 0.9400, 0.8600, 0.0100, 1.3900, 0.1400, 0.9400, 2.1800, 0.0500, 0.3400, 1.2600, 0.2500, 1.5200

request_retention and maximum_interval remain unchanged.
For example, when I have difficulty Easy, it works. The interval is 2 days as expected.
Note: the difficulty value in my graph does not represent the same difficulty as the values in the fsrs. For me 1 means Easy and 3 means Hard.

But it does not work suddenly for difficulty Good (which creates an interval of 1 day)

I don't think there's an error with my code because the fact that the Easy difficulty worked but not the Good shows that there's an inconsistency elsewhere.
To rule out the error of it being an estimation error, where maybe it could be adding 0.9 days or something, I also tried parameters that made the Good difficulty beyond 1 day and it still did not work.
Last example is when I try two Good sessions in a row, I should get 5 days but I get an interval of 1 day.

If I were to add another Good session it would then be 5 days which is very confusing because now that's the result I want but I had to place an extra study session

By the way, another variable that could be causing this error is how the date studied of my study session does not line up with the recommended due date. But I made sure that the date of the study session does line up.
So I have one Good session, and the algorithm recommends studying in 1 day. So I placed the second Good session one day after, so I expect the algorithm to ask to study again in 5 days. But it doesn't, it says 1 day.
Another problem that I cannot verify is that maybe the algorithm for Anki Visualizer and FSRS Python are not the same. I think that's the most possible problem. Another problem is that maybe making the initial difficulty (Good) to the minimum value 1 broke something, but probably not since it works perfectly in the Visualizer.
Any ideas or help would be really appreciated. It's frustrating to see the perfect spacing algorithm in front of me but cannot apply it in my code. I really like the FSRS algorithm, and I really want to use it!
By the way, here is my Python code if it needs to be checked. At line 86-91 is where I use a loop to create the card. That has the largest possibility for error, although it seems to been working fine before I tried to fine-tuned the algorithm. So maybe no error there.
import os
import fsrs
import datetime as dt
import pandas as pd
import plotly.express as px
from StudySessions import Study_Session

class Spacing_Table:
    def __init__(self, vault_path):
        self.path = vault_path
        self.spacing_table = self.load_spacing_table()

        self.Study_Sessions = Study_Session(vault_path)
        self.schedule()

    def load_spacing_table(self):
        # where Spacing Table.md is held
        table_path = os.path.join(self.path, r"CBT Plan\iCanStudy\FSRS Spacing Table.md")

        with open(table_path, "r", encoding='utf-8') as file:
            data = file.readlines()

            # Collect Rows
            raw_rows = []
            # filtered rows
            rows = []

            # each line will be read as a row
            for line in data[3:]:
                raw_rows.append(line.split("|")[1:-1])

            # remove rows without an ID
            for row in raw_rows:
                if len(row)>1: # if not extra row from outside of table
                    if row[0].strip():
                        rows.append(row)

            # Collect Columns
            columns = data[1].split("|")[1:-1]
            columns = [word.strip() for word in columns] #remove extra spaces

            # Make Pandas DataFrame
            spacing_table = pd.DataFrame(rows, columns=columns)

            # spacing_table.to_excel(r"C:\Users\light\Downloads\FRSR.xlsx")

        return spacing_table

    def dates_and_difficulties(self, topic):
        # collect data
        index = self.find_study_session_index(topic, "Topic")
        encoded_study_session = self.spacing_table["Encoded"][index].replace("❌","")
        topic = self.spacing_table["Topic"][index].strip()
        difficulty = self.Study_Sessions.metadata(encoded_study_session, "difficulty")
        date = self.Study_Sessions.metadata(encoded_study_session, "date")
        subject = self.Study_Sessions.metadata(encoded_study_session, "subject")

        # Create dates based on difficultly and date
        f = fsrs.FSRS() # algorithm
        card = fsrs.Card() # create card

        def difficulty_to_rating(difficulty):
            if difficulty == 1:
                return fsrs.Rating.Easy
            if difficulty == 2:
                return fsrs.Rating.Good
            if difficulty == 3:
                return fsrs.Rating.Hard

        due_dates = []
        difficulties = []
        days_last_studied = []
        lapses = []

        session_count = 0
        for study_session in self.spacing_table.iloc[index][1:]: # For every study session for a particular topic
            if "[" not in study_session: # ignore empty cells
                break

            study_session = study_session.replace("❌","") # remove ❌ to prevent errors
            # print(study_session)
            date = self.Study_Sessions.metadata(study_session, "date")
            difficulty = self.Study_Sessions.metadata(study_session, "difficulty")

            card_schedules = f.repeat(card, date) # possible schedules
            card = card_schedules[difficulty_to_rating(difficulty)].card # iterations of next due date
            due_dates.append(card.due) # save due dates of topic
            difficulties.append(difficulty) # save difficulty
            days_last_studied.append((card.due - card.last_review).days) # days from last review until due date
            lapses.append(session_count)    # session number
            session_count += 1

        def filter_empty(element):
            if "[" in element:
                return True
            else:
                False

        filtered_row = list(filter(filter_empty, self.spacing_table.iloc[index])) # keep only study sessions

        # if latest study session has "❌", then it's not complete. Return second most recent date
        if "❌" in filtered_row[-1]: # check for latest study sesh
            if len(filtered_row) == 1: # if encoding is not complete
                return None, None, None
            return due_dates[-2], difficulties[-2], subject, days_last_studied[-2], lapses[-2]
        else:
            return due_dates[-1], difficulties[-1], subject, days_last_studied[-1], lapses[-1] # return latest date and difficulty

    def schedule(self):
        data = {}

        for i in range(len(self.spacing_table)): # for every row
            row = self.spacing_table.iloc[i]
            row = list(row)

            # Get topic
            topic = row[0]

            # Get date
            # Get difficulty
            date, difficulty, subject, days, lapse = self.dates_and_difficulties(topic)

            if date: # only append if encoding is complete
                data[topic] = [date,difficulty,subject, days, lapse] # get latest date or difficulty

        # graph data
        self.graph(data)

    def graph(self,data):
        dataframe = []

        # convert data into proper dataframe
        for topic, date_difficulty in data.items():
            row = {
                "Topic": topic,
                "Start": date_difficulty[0],
                "Finish": date_difficulty[0] + dt.timedelta(days=1),
                "Difficultly": date_difficulty[1],
                "Subject": date_difficulty[2],
                "Days since studied": date_difficulty[3],
                "Lapse": date_difficulty[4]
            }

            dataframe.append(row)

        data = pd.DataFrame(dataframe)
        colours = self.get_subject_colours("Subject Colours.txt")
        fig = px.timeline(data, x_start="Start", x_end="Finish", y="Topic", title='Retrieval Sessions', color = "Subject", color_discrete_map=colours, hover_data=
                          {"Topic":True,
                              "Start":True,
                              "Difficultly":True,
                              "Days since studied":True,
                              "Lapse":True,
                              "Finish":False})
        fig.update_xaxes(range=[dt.date(2024,5,8),dt.date(2024,8,12)])
        fig.show()

    def get_subject_colours(self, file_path):
        colours = {}
        with open(file_path, "r") as file:
            data = file.readlines()

            for line in data:
                subject = line.split(",")[0]
                colour = line.split(",")[1].strip()

                colours[subject] = colour

        return colours

    def find_study_session_index(self, topic, column = "ID"):
        """
        find the index for the row of the study session
        """
        for index, row in self.spacing_table.iterrows():
            if row[column].lower().strip() == topic.lower().strip():

                return index

def main():
    spacing_table = Spacing_Table(r"C:\Users\light\Documents\Alex's Vault")
    spacing_table

main()

Thank you for your time or advice,
Aurelion

In py-fsrs/go-fsrs/ts-fsrs, when determining the card as State.New, the ratings Rating.Again, Rating.Hard, and Rating.Good are calculated based on the current time(now) plus a certain interval, which is usually less than 1 day.
https://github.com/open-spaced-repetition/py-fsrs/blob/5d36ec32bcac350b489b78dd6c20b26a38582d09/src/fsrs/fsrs.py#L31-L39

Hello, thank you for the share. It 100% seems to be in the right direction, but I'm still facing issues.
I tried to code the due date for the Good and due date for the Hard in the same way the due date for Easy was calculated
if card.state == State.New:
	self.init_ds(s)
	s.again.due = now + timedelta(minutes=1)

	hard_interval = self.next_interval(s.hard.stability) # new lines
	s.hard.due = now + timedelta(days=hard_interval)

	good_interval = self.next_interval(s.good.stability) # new lines
	s.good.due = now + timedelta(days=good_interval)

	easy_interval = self.next_interval(s.easy.stability)
	s.easy.scheduled_days = easy_interval
	s.easy.due = now + timedelta(days=easy_interval)

but it did not work, and then I tried to hard-code it
if card.state == State.New:
	self.init_ds(s)
	s.again.due = now + timedelta(minutes=1)

	# hard_interval = self.next_interval(s.hard.stability) # new lines
	s.hard.due = now + timedelta(days=0)

	# good_interval = self.next_interval(s.good.stability) # new lines
	s.good.due = now + timedelta(days=1)

	easy_interval = self.next_interval(s.easy.stability)
	s.easy.scheduled_days = easy_interval
	s.easy.due = now + timedelta(days=easy_interval)

which fixed the problem for New cards, but did not fix the problem for new iterations afterwards. I checked my code and it does cycle between the states Learning and Review, so the iterations should work.
For example, here is the printed information on iterations that follow that recommend the next due date. So I made the next review date of the study session be the same as the algorithm's recommended due date
Session: 0
State: 0
Card's Difficulty Metric: 0
My Difficulty Metric: 2
Stability: 0
Date studied: 2024-05-19
Due date: 2024-05-20
---

Session: 1
State: 1
Card's Difficulty Metric: 1.0
My Difficulty Metric: 2
Stability: 1.0
Date studied: 2024-05-20
Due date: 2024-05-21
---

Session: 2
State: 2
Card's Difficulty Metric: 1.0
My Difficulty Metric: 2
Stability: 1.0
Date studied: 2024-05-21
Due date: 2024-05-26
---

Session: 3
State: 2
Card's Difficulty Metric: 1.0
My Difficulty Metric: 2
Stability: 4.957026011186596
Date studied: 2024-05-26
Due date: 2024-06-16
---

So Session: 0 is good because it's a 1-day interval for Good (I mean I hard-coded it), but then Session: 1 is wrong because it says a 1-day interval which should be 5. But then all of a sudden the code starts working afterwards??
Session: 2 is the 5-day interval, and then Session: 3 is a 21-day interval. This perfectly follows the algorithm shown on the Anki FSRS Visualizer? So why is the algorithm one session off??
Either way, this is progress, so I'm hyped to hear any more ideas or solutions!

If the ratings are [Rating.Good, Rating.Good, Rating.Good, Rating.Good], then the due times should be 0, 1, 5 and 21 respectively. However, the anki_fsrs_visualizer does not seem to be considering the special handling for the State.New case correctly, as it is producing a different result of 1, 5, 21, 74(The correct due time should be 75, which is what I get from the results of ts-fsrs and py-fsrs).

The difference in 74.08 and 75.04 was due to rounding of the interval in days, and recalculation of retention to 0.89899

The difference in 74.08 and 75.04 was due to rounding of the interval in days, and recalculation of retention to 0.89899

Okay, I've confirmed the data is consistent now.

I've added option to use ts-fsrs lib.
I would switch to ts-fsrs completely, but It handles the first review of cards differently from my implementation of The Algorithm article.


Enable multiple client/server pairs with NodePort uperf

Signed-off-by: Sai Sindhur Malleni<EMAIL_ADDRESS>Description
Currently uperf with NodePort servicetype only works
with pairs: 1. This PR fixes the issue with running multiple
pairs.
Fixes
#757
Thanks to Murali for the initial feedback and testing the PR to find issues.

/rerun all

Hey @smalleni, can you add a test case and update docs for this?

Hey @rsevilla87 docs already exist and I just modified an existing test case to run with 2 pairs. Hopefully that's good.

@rsevilla87 @jtaleric should be good now (defaulting to 2 pairs for nodeport and fixed the location of the test).


[IconMenu] Add ability to style underlying List inside of Menu.

Currently there is no way to style the underlying list when using IconMenu. This change would enable passing a listStyle object similar to how Menu already allows for and just pass the listStyles down to the Menu object.
const listStyles = { paddingTop: 0, paddingBottom: 0 };

<IconMenu listStyle={listStyles} menuStyle={...}>
  <MenuItem .../>
</IconMenu>

That's a good point. Care to submit a PR?
Also @jareddellitt , What is your use-case exactly?

Also, We are in the process of rewriting the menuItem component for the next version release. This might not even be needed by then. So , you will have to wait if you are banking on this change.

@tintin1343 I just wanted to be able to style the underlying List (adjust padding) when using IconMenu, similar to what can be done when just using Menu. Will rewriting MenuItem allow for this?

@jareddellitt : We will make it more composable that way everyone will have the freedom and flexibility to   design and make changes to the styles of the components. Right now some of the components are a mess. So a rewrite will allow for it.

@tintin1343 gotcha - would it be more reasonable to add list to the set of components with overridable styles when defining a custom theme and pull those styles from context.muiTheme inside of List?
getMuiTheme({
  list: {
    paddingTop: 8,
    paddingBottom: 8
  }
})

List.js
const {muiTheme} = context;

const styles = {
  root: {
    padding: 0,
    paddingBottom: muiTheme.list.paddingTop,
    paddingTop: hasSubheader ? 0 : muiTheme.list.paddingBottom,
  },
};

I guess I'm just looking for a way to override some of the static styles of components that are wrapped by higher level components. Is there a spot I can follow along/see the plan/help out for these rewrites?

Hello,
I understand that this component will be rewritted. I just want to highlight my issue with the autocomplete component. Indeed, this last one is using the menuItem, however, it is not possible to set the style into the div containing the text itself, so it is not possible for me to apply the css property text-overflow: ellipsis.

<div style="margin-left:0;padding-left:16px;padding-right:16px;padding-bottom:0;padding-top:0;position:relative;color:red;overflow:hidden;text-overflow:ellipsis;mui-prepared:;" data-reactid=".<IP_ADDRESS>.0.1:$0/=1$<IP_ADDRESS>">
    <div style="mui-prepared:;" data-reactid=".<IP_ADDRESS>.0.1:$0/=1$<IP_ADDRESS>.$primaryText">a very very very very long text which cannot be summarized here

Anyway, is there any work around until this rewriting?

Will this make it possible to remove the padding: 8px 0; that is set on the inside div?.... was hoping listStyle={{ padding: 0 }} would do it, but it did nothing.

I had a lot of trouble trying to remove the padding: 8px 0 as css classes couldn't reach the div and the menuStyle, lineSyle props didn't work either. However wrapping my listing content in a disabled menuItem and setting some negative margins works pretty good.
<IconMenu >
  <MenuItem class="icon-menu-wrapper" disabled={true}>

listing content

more listing content

     ...
  </MenuItem>
</IconMenu>

.icon-menu-wraper {
    margin: -8px 0 -8px 0; /* the real magic */
    padding: 0 !important; /* removes left and right padding */
    cursor: initial !important;
}

The post above by @hbeckeri is really helpful, but it was confusing for me to wrap in a disable MenuItem. It works equally as well for me with a div:
<IconMenu >

listing content

more listing content

     ...

</IconMenu>

.menu-hack {
    margin: -8px 0 -8px 0; /* the real magic */
    padding: 0 !important; /* removes left and right padding */
    cursor: initial !important;
}

@ekatzenstein Are you getting any warnings from material-ui? If I recall correctly Menus require children to be MenuItems.

add
<autocomplete          menuProps={{           menuItemStyle: {             whiteSpace: 'initial', lineHeight: 'normal',             display: 'flex',justifyContent:'center',flexDirection:'column',             fontSize: '14px'           }         }} />

Using MenuListProps should work.
<Menu  MenuListProps={{ style: { padding: 0 } }} >
  <MenuItem> First </MenuItem>
  <MenuItem> Second </MenuItem>
  <MenuItem> Third </MenuItem>
</Menu>```


Reversing a oneway tagged with "turn:lanes"

Related to #5674 and briefly mentioned in https://github.com/openstreetmap/iD/pull/5826#issuecomment-458578589.
If I understand how these tagging schemes work correctly, when turn lanes are tagged as turn:lanes:both_ways or just using turn:lanes on a bidirectional road, then when the way is reversed the order of the values (split by |) need to be reversed too (as the lane indexes are based on way direction).
If someone else could confirm that I've understood the tagging correctly, I'll work on a PR to fix this.
Personal note: It seems pretty silly to me to ever tag turn lanes in this way and not just specify :forward/:backward for clarity.

Personal note: It seems pretty silly to me to ever tag turn lanes in this way and not just specify :forward/:backward for clarity.

turn:lanes:both_ways is the successor to the centre_turn_lane=yes tag that NE2 pioneered, as discussed in this diary post.
There’s an important distinction between turn:lanes:forward/:backward and turn:lanes:both_ways. (It also isn’t the same thing as turn:lanes:reversible, which means the lane could go one way or another but not both simultaneously.) Typically, you’d tag turn:lanes:forward or turn:lanes:backward starting from the point the lane change restriction begins to the intersection where the driver turns. But with turn:lanes:both_ways, the driver may turn at any point along the center turn lane.
Simultaneously tagging a single center turn lane as a forward lane and a backward lane would throw off any statistics about OSM coverage by lane miles, and it could potentially cause incorrect timing of voice guidance by a turn-by-turn navigation application.

My understanding of turn:lanes:both_ways is that it's only ever used for a single center turning lane. You can't really reverse it.

There are some examples of lanes:both_ways being used to count reversible lanes or as a hack to account for extra-wide gore areas, but that’s kind of tagging for the… I’m not sure what. both_ways was originally proposed for center turn lanes. 🤷♂

If I understand how these tagging schemes work correctly, when turn lanes are tagged as turn:lanes:both_ways or just using turn:lanes on a bidirectional road, then when the way is reversed the order of the values (split by |) need to be reversed too (as the lane indexes are based on way direction).

Any turn:* tag’s value should remain unchanged when reversing a bidirectional way. When oneway=no, the way’s direction has no relation to the physical road. As a contrived example, a mapper may find it convenient to reverse a bidirectional way to make route relation roles consistent with adjoining ways, without the intention of rearranging the lanes on the road or making the lanes represent the opposite maneuvers. (That’s why :forward and :backward get swapped.)

ok, cool.. if I'm understanding the parts to this issue:

Does iD reverse turn:lanes:both_ways properly?

Yes, because it doesn't need to be reversed, and iD doesn't do anything to it.

Does iD reverse turn:lanes on a oneway road properly?

iD doesn't currently do anything.  We might consider reversing the parts?

Do we reverse turn:lanes on a bidirectional road properly?

iD doesn't currently do anything to the value, but it's likely most people would consider this style of tagging is wrong anyway.  A bidirectional road should really have separate turn:lanes:forward and turn:lanes:backward, which iD supports already.

We need to distinguish automatic reversing (e.g. due to merging) from manual reversing:
When reversing automatically, iD must preserve the meaning. Any *:lanes key without :forward or :backward suffix need reversing the order of lanes in the value. Maybe, we can just disallow reversing the way automatically. In case of a oneway, I think iD wouldn't reverse automatically anyway. Right?
In case the way isn't a oneway, using :forward or :backward suffix is required according to the lanes proposal. In case the suffix is missing, iD might show a validator issue and disable the merging etc. operation, which would require reversing the way. Some keys like witdth:lanes and change:lanes might be considered to be acceptable for bidirectional roads without using a :forward or :backward suffix.
When initiating the reversing operation manually, the desirable tag handling depends on the usecase.
The user might either wan't to preserve the meaning or to preserve the tags. Id should ask the user which one is desired, or offer two different operations.
Using the wrong variant of tag handling could be quite nasty where significant lane tagging exists.

When reversing automatically, iD must preserve the meaning. Any *:lanes key without :forward or :backward suffix need reversing the order of lanes in the value. Maybe, we can just disallow reversing the way automatically. In case of a oneway, I think iD wouldn't reverse automatically anyway. Right?

iD does automatic reverses sometimes:

when using the intersection editor, iD will automatically reverse any roads with oneway=-1
when joining ways that aren't drawn with the same direction, iD will reverse if needed.

In case the way isn't a oneway, using :forward or :backward suffix is required according to the lanes proposal.

Good to know..  I'm not worried about the bidirectional case then 👍
so that just leaves "Does iD reverse turn:lanes on a oneway road properly?"
I can't imagine that anyone would want "reverse" to mean anything other than "make the way go in the opposite direction".  So I don't think we need to provide a separate action for "leave the way alone and reverse the lanes".  I'll change the current behavior so that the oneway reverses, and we'll preserve the lanes.  Someday when we render lanes, this will be much easier for iD users to understand, but for now it's good enough.

@bhousel

I can't imagine that anyone would want "reverse" to mean anything other than "make the way go in the opposite direction".

I agree, but I was talking about two kinds of making the way go in opposite direction:

Reverse the way, but keep the meaning.
Example usecases: reversing for convienience of tagging or adding routes, reversing automatically
Reverse the way, but keep the tags.
This is how iD currently handles the reverse operation in view of the oneway tag.
Example usecase: the way has been nicely tagged including lane dependent destinations, turns, and maxspeeds based on an assumption of direction, then you realize that the small arrow on the map is pointing in the wrong direction.

Closing for now.. After talking through it extensively, I think it's safe for iD to leave the actual lanes alone when reversing a way (as long as we reverse the tags in situations described above).


Segmentation Fault

i'm using nodejs 8.11.3 and when i try to run fprint.identifyStart i get a segmentation fault error and it stops working

please try again with node-fprint 0.0.9

It's working, thank you


Does this support all-in-one? And what's the suggested requirements?

Is this allowed if I make the gateway IIS server and the RDP server to be the same server?
and if I install the whole system only for myself's personal use(I mean no more concurrent user), what's the suggested requirements:

bandwidth between the IIS and the browser
bandwidth between the IIS and the RDP server
how many memory and nums of CPU of the IIS

Thanks a lot.
And if available, I suggest that we can put the information onto the "requirements" of the main page

Is this allowed if I make the gateway IIS server and the RDP server to be the same server?

Yes

and if I install the whole system only for myself's personal use(I mean no more concurrent user), what's the suggested requirements:

A simple dual core with 4GB RAM will be enough

bandwidth between the IIS and the browser

About 20KB/sec

bandwidth between the IIS and the RDP server

About 50KB/sec (uncompressed bitmaps)

how many memory and nums of CPU of the IIS

The gateway work is minimal, most of the resources will be used by the rdp client process(es); about 50KB RAM by process most of the time
Thanks a lot.

And if available, I suggest that we can put the information onto the "requirements" of the main page

Good idea

Added to readme in version 1.5.0 :)


UDP packets >24kB result in segfault (1.16 and 1.17)

I am seeing segmentation faults of envoy when receiving UDP packets
larger than 24000 bytes in 1.16.1 - 1.17.4. (see stacktrace and
minimal reproduction info below)
This was already fixed I believe in
https://github.com/envoyproxy/envoy/commit/73eec645a39343eec33b5d61bf492ba49c397cfe
(didn't do a bisect, only tested docker images)
Title: UDP packets >24kB result in segfault (1.16 and 1.17)
Description:
I am seeing segmentation faults of envoy when receiving UDP packets
larger than 24000 bytes in 1.16.1 - 1.17.4. (see stacktrace and
minimal reproduction info below)
This was already fixed I believe in
https://github.com/envoyproxy/envoy/commit/73eec645a39343eec33b5d61bf492ba49c397cfe
(didn't do a bisect, only tested docker images)
Repro steps:
docker run -v $(pwd)/configv3.yaml:/config/configv3.yaml --rm --name envoy -p 12201:12201/udp -it envoyproxy/envoy:v1.16.5 -l info -c /config/configv3.yaml

import socket
with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock:
    sock.sendto(bytes(24001), ("<IP_ADDRESS>", 12201))

Config:
admin:
  access_log_path: /dev/stdout
  address:
    socket_address:
      protocol: TCP
      address: <IP_ADDRESS>
      port_value: 9901
static_resources:
  listeners:
  - name: listener_0
    reuse_port: true
    address:
      socket_address:
        protocol: UDP
        address: <IP_ADDRESS>
        port_value: 12201
    listener_filters:
    - name: envoy.filters.udp_listener.udp_proxy
      typed_config:
        '@type':
type.googleapis.com/envoy.extensions.filters.udp.udp_proxy.v3.UdpProxyConfig
        stat_prefix: service
        cluster: service_udp
  clusters:
  - name: service_udp
    type: STRICT_DNS
    dns_lookup_family: V4_ONLY
    connect_timeout: 0.5s
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_udp
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: <IP_ADDRESS>
                port_value: 1235

Logs:
see below for stack trace
Call Stack:
[2021-10-06 10:08:44.491][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:104]
Caught Segmentation fault, suspect faulting address 0x0
[2021-10-06 10:08:44.492][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:91]
Backtrace (use tools/stack_decode.py to get line numbers):
[2021-10-06 10:08:44.493][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:92]
Envoy version: 72ec3eed50b4154cb6d2251667b4c1c1ddfaa266/1.16.5/Clean/RELEASE/BoringSSL
[2021-10-06 10:08:44.495][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#0: __restore_rt [0x7f1b5b0a4980]
[2021-10-06 10:08:44.513][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#1: Envoy::Network::Utility::readFromSocket() [0x55ac6638761f]
[2021-10-06 10:08:44.523][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#2: Envoy::Network::Utility::readPacketsFromSocket() [0x55ac66388527]
[2021-10-06 10:08:44.533][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#3: Envoy::Network::UdpListenerImpl::handleReadCallback()
[0x55ac661d30a0]
[2021-10-06 10:08:44.543][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#4: Envoy::Network::UdpListenerImpl::onSocketEvent() [0x55ac661d2e51]
[2021-10-06 10:08:44.552][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#5: Envoy::Event::FileEventImpl::assignEvents()::$_1::__invoke()
[0x55ac65f5e226]
[2021-10-06 10:08:44.561][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#6: event_process_active_single_queue [0x55ac66399838]
[2021-10-06 10:08:44.570][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#7: event_base_loop [0x55ac6639820e]
[2021-10-06 10:08:44.579][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#8: Envoy::Server::WorkerImpl::threadRoutine() [0x55ac65f4f698]
[2021-10-06 10:08:44.589][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#9: Envoy::Thread::ThreadImplPosix::ThreadImplPosix()::{lambda()#1}::__invoke()
[0x55ac66547703]
[2021-10-06 10:08:44.589][22][critical][backtrace]
[bazel-out/k8-opt/bin/source/server/_virtual_includes/backtrace_lib/server/backtrace.h:96]
#10: start_thread [0x7f1b5b0996db]

how does the backporting work? Do I open a PR on v1.17.3?

Thanks everyone!


fix: error in Dockerfile

Summary:
Fixed error in Dockerfile by adding RUST_BACKTRACE=1 to ENV
Issue Reference(s):
Fixes #1052

still getting the same error
17.20   static lib URL: https://github.com/denoland/rusty_v8/releases/download/v0.75.1/librusty_v8_release_aarch64-unknown-linux-gnu.a
17.20   cargo:rustc-link-search=/prod/target/release/gn_out/obj
17.20   Downloading https://github.com/denoland/rusty_v8/releases/download/v0.75.1/librusty_v8_release_aarch64-unknown-linux-gnu.a
17.20   Python downloader failed, trying with curl.
17.20
17.20   --- stderr
17.20   thread 'main' panicked at /prod/vendor/v8/build.rs:426:10:
17.20   called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }
17.20   stack backtrace:
17.20      0: rust_begin_unwind
17.20                at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
17.20      1: core::panicking::panic_fmt
17.20                at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
17.20      2: core::result::unwrap_failed
17.20                at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/result.rs:1653:5
17.20      3: core::result::Result<T,E>::unwrap
17.20      4: build_script_build::download_file
17.20      5: build_script_build::download_static_lib_binaries
17.20      6: build_script_build::main
17.20      7: core::ops::function::FnOnce::call_once
17.20   note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
17.20 warning: build failed, waiting for other jobs to finish...
------
Dockerfile:28
--------------------
  26 |     # Compile the project
  27 |     ENV RUST_BACKTRACE=1
  28 | >>> RUN cargo build --release
  29 |
  30 |     # Runner stage
--------------------
ERROR: failed to solve: process "/bin/sh -c cargo build --release" did not complete successfully: exit code: 101


Conditional fields

Is there a suggested way to have conditional fields?
For example say I have 2 form fields that are related, a user can be of type A or type B. Type A can then either have title W or X and type B can have title X, Y, or Z.
What would be the best way to accomplish this?

I would just use react and conditionally render fields. When they are taken out reacts lifecycle events will get called and the lib removes them from form :)

closing


Feature Request: An elegant way to handle complex members

Right now, it is not possible to do a converter which will automatically convert a dict to a complex type so we have to define a separate converter function to handle the use case:
from typing import Optional
import attr

@attr.s
class Inner:
    a: str = attr.ib()

def optional_dict_to_inner(d) -> Optional[Inner]:
    if d is None:
        return None
    return Inner(**d)

@attr.s
class Outer:
    e: Optional[Inner] = attr.ib(converter=optional_dict_to_inner)
    i: Optional[int] = attr.ib(converter=attr.converters.optional(int))

print(Inner("A"))
print(Outer(e=None, i=1))
print(Outer(e={"a": "A"}, i=1))

What makes this worse is mypy is not able to handle a decorator to get around this without giving an error. Specifically, I tried to replace the optional_dict_to_enclosed to:
def optional_dict_to_obj(obj):
    def _optional_dict_to_obj(d) -> Optional[type(obj)]:
        if d is None:
            return None
        return obj(**d)
    return _optional_dict_to_obj

@attr.s
class Outer:
    e: Optional[Inner] = attr.ib(converter=optional_dict_to_obj(Inner))
    i: Optional[int] = attr.ib(converter=attr.converters.optional(int))

But that will cause mypy to complain as it requires type annotation on converters...
test_mypy.py:23: error: Unsupported converter, only named functions and types are currently supported

It would be nice to have an elegant way to tell the attr.ib that you are getting a dict you need to convert an object of a specific type without having to work around it like this... It would be something like attr.objfromdict and its optional equivalent attr.optional_objfromdict (I suppose the optional version is not required as we can just compose the attr.converters.optional):
@attr.s
class Outer:
    e: Optional[Inner] = attr.ib(converter=attr.converters.optional_objfromdict(Inner))
    i: Optional[int] = attr.ib(converter=attr.converters.optional(int))

Another simple approach is to have a default .fromdict() on each class (and handled correctly in mypy) so the above can be written as:
@attr.s
class Outer:
    e: Optional[Enclosed] = attr.ib(converter=attr.converters.optional(Enclosed.fromdict))
    i: Optional[int] = attr.ib(converter=attr.converters.optional(int))

What you're asking for is serialization. :)
There's multiple solutions for that in attrs and we consciously decided to keep it out of attrs core, because it's a complex topic: https://github.com/python-attrs/attrs/wiki/Extensions-to-attrs
FWIW, my code is kinda full of from_dicts or from_rows (for SQLAlchemy) because expressing such dependencies becomes quite complex and nested objects make it even even more complicated.
I personally find something like this more readable and debuggable:
@attr.s(auto_attribs=True)
class Sub:
    x: int

    def from_dict(cls, d) -> Sub:
        return cls(x=d["x"])

@attr.s(auto_attribs=True)
class C:
    y: int
    s: Sub

    @classmethod
    def from_dict(cls, d) -> C:
        return cls(
            y=d["y"],
            s=Sub.from_dict(d),
        )

Out of scope for attrs itself.

@hynek @wsanchez Thanks for the reply. I still think it would have been super useful to allow an option in attr.s constructor to automatically created the class function from_dict. There is no sense is explicitly defining this out every time...

By the way, @hynek the way you have it, if there are converters and validators on the elements, they will not be used in the from_dict... that is why in my version I would opt to just call the instance with cls(**d) to make sure those are all applied correctly.

FWIW, I’m personally not a huge fan of converters except for the simplest cases. And the same is true for automatically generated from_dicts: you run into problems quite fast (e.g. if you don’t control the dict and want different names in your models).
If you really want to, you can quite easily write a from_dict Generator based on attrs’ metadata yourself BTW.


Add Agilent scope families and fix a few sample depths

Add scope family structure (based off MSO series in Tek), fill it out with the supported models, and pick model on startup.
Modify sample depth for scopes according to family (only verified for EDUX1000A/G, DSOX1202A/G DSOX1204A/G

need to also adjust sample rates


use this.req insteadof this.ctx.req

use this.req directly

what's the purpose of this?

I'm going to close this PR due to inactivity.


Don't make PRs to packages that have a dependency that upper bounds the package CompatHelper bumps

The tests will then still use the old version and not be effective in knowing if the package actually is compatible with the old version.

I agree. I’m just not sure how to implement this.

What about:

Create a temp copy of the project.
Delete all [compat] entries except for julia
Pkg.update()
Read back the versions in the updated manifest.

That should get you the latest possible versions of all packages while respecting the upper bounds of dependencies, right?

It's like what @colinxs already said but, instead of adding this feature in CompatHelper.jl, can we have a mode in Pkg.add (and Pkg.test) to ignore indirect compat bounds if they prevent updating direct dependencies?

I'm happy with exploring different non-default modes for the resolver. The logic would be around here:
https://github.com/JuliaLang/Pkg.jl/blob/a9d85e7b8a22b1f0fe8cdbdfa4fe9d5f60ee5ea0/src/Operations.jl#L425-L431

Here's a screenshot of my inbox:

:laughing:

It is worth figuring out how to reduce these notifications.
Certainly one solution would be to have a single pull request for all suggested changes, instead of a different pull request for each suggested change: https://github.com/bcbi/CompatHelper.jl/issues/126

That would be a great change. But waiting to submit the PR until the resolver will actually use the version whose bounds are loosening is also useful. The main reason these are hanging around in my inbox is that these are the ones I couldn't deal with immediately because I needed to work my way up the hierarchy of dependencies.

I wanted to share a port of CompatHelper that I've been using internally which addresses this issue. Rather than deleting the existing compat entries like I described above, it replaces them with inequality specifiers. So a compat entry that looked like:
Foo = "0.2, 0.5, 0.6"

would get replaced with:
Foo = ">= 0.2"

before calling Pkg.API.up to find an updated set of packages. A single PR is then made with the updated compat entries, which addresses @timholy's concern above.
Some other differences that I can think of:

PR's are formatted with Markdown because why not. See here for an example.
A single compat branch is used, with new changes overwriting an existing PR.
A Personal Access Token is used rather than GITHUB_TOKEN so that GitHub Actions workflows are triggered.

I originally intended on split this up into PRs to CompatHelper, but it doesn't share much code since I'm relying on Pkg to do all the heavy lifting. If folks find this approach useful perhaps we can find a way to incorporate the changes?

I don’t think that is sufficient.
In your example, your bot makes a PR that replaces this line:
Distributions = "0.22"

With this line:
Distributions = "0.22, 0.23"

There is no guarantee that the test suite will use Distributions 0.23. This is the same problem that CompatHelper has, so I’m not sure how this approach solves it.
(Keep in mind that at the beginning of the test suite, when the test dependencies are resolved, the resolver is allowed to also change the versions of the direct dependencies.)
The core issue here is that when you run the test suite, you need to enforce that Distributions 0.23 is used.

Just to elaborate: even if Pkg.up gives you Distributions 0.23, that doesn’t mean that the test suite will give you Distributions 0.23. When you run Pkg.test, the resolver is allowed to downgrade you to Distributions 0.22 if it wants to.

I don’t mean to be negative! It’s a good idea, I just don’t think it solves the core problem.
I really like the markdown output, the single branch for all changes, and the option to use the PAT. It would be great to have those features in CompatHelper, and I’d be happy to accept PRs for those features.

You're not being negative :)
Perhaps I'm misinterpreting, but from the Pkg.test docs:

The tests are run by generating a temporary environment with only pkg and its (recursive) dependencies in it. If a manifest exists, the versions in that manifest are used...

So after the call to Pkg.up we get Distributions 0.23 from the current Context, and if you're checking in the Manifest.toml corresponding to the Context then the tests will use Distributions 0.23.
Of course if you don't check in a Manifest.toml, then all bets are off.
Based on https://github.com/JuliaLang/Pkg.jl/issues/1233 and other discussions, it sounds like the goal is to have Pkg.test() be equivalent to Pkg.activate("test"); Pkg.instantiate(); include("test/runtests.jl"), which would address this. I've been using @tkf 's Run.jl until this happens.

So, there are two problems here.
The first problem is that many people (myself included) do not check in the /Manifest.toml file into source control. There are many reasons for this. For example, one reason is that manifest files are not necessary compatible across different versions of Julia.
Therefore, we cannot have a solution that requires people to check /Manifest.toml into source control.
The second problem is that those docs are out-of-date and are no longer correct.
I have set up an example package to demonstrate: https://github.com/aluthge-test/Foo.jl
Look at the Project.toml file:
name = "Foo"
uuid = "8f191a96-946f-40fe-b50f-e281de84ebcd"
authors = ["Dilum Aluthge<EMAIL_ADDRESS>version = "0.1.0"

[deps]
StatsBase = "2913bbd2-ae8a-5f71-8c99-4fb6c76f3a91"

[compat]
DataFrames = "0.18"
StatsBase = "0.32, 0.33"

[extras]
DataFrames = "a93c6f00-e57d-5684-b7b6-d8193f3e46c0"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

[targets]
test = ["DataFrames", "Test"]

If you clone this package, enter it with julia --project, and run import Pkg; Pkg.update(), you will see that it gives you StatsBase v0.33.0.
And if you look at the Manifest.toml file, you will see that indeed, it has StatsBase v0.33.0. Here is the relevant portion of Manifest.toml:
[[StatsBase]]
deps = ["DataAPI", "DataStructures", "LinearAlgebra", "Missings", "Printf", "Random", "SortingAlgorithms", "SparseArrays", "Statistics"]
git-tree-sha1 = "a6102b1f364befdb05746f386b67c6b7e3262c45"
uuid = "2913bbd2-ae8a-5f71-8c99-4fb6c76f3a91"
version = "0.33.0"

Now, open a new Bash session and run the following lines:
export JULIA_DEPOT_PATH="$HOME/.julia.temp"
rm -rf $HOME/.julia.temp
export<EMAIL_ADDRESS>rm -rf Foo.jl
git clone https://github.com/aluthge-test/Foo.jl.git Foo.jl
cd Foo.jl
julia

You are now in a Julia REPL. Run the following lines in Julia:
import Pkg
Pkg.build(; verbose = true)
Pkg.status(; mode = Pkg.PKGMODE_PROJECT)
Pkg.status(; mode = Pkg.PKGMODE_MANIFEST)
Pkg.test()

This Bash script and Julia script replicate exactly what the default Travis script for Julia does.
Here are the results:
$ export JULIA_DEPOT_PATH="$HOME/.julia.temp"
$ rm -rf $HOME/.julia.temp
$ export<EMAIL_ADDRESS>$ rm -rf Foo.jl
$ git clone https://github.com/aluthge-test/Foo.jl.git Foo.jl
Cloning into 'Foo.jl'...
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 8 (delta 0), reused 8 (delta 0), pack-reused 0
Unpacking objects: 100% (8/8), 2.49 KiB | 425.00 KiB/s, done.
 for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.0-DEV.573 (2020-04-06)
 _/ |\__'_|_|_|\__'_|  |  Commit e25b3574d6 (3 days old master)
|__/                   |

julia> import Pkg

julia> Pkg.build(; verbose = true)
    Cloning default registries into `~/.julia.temp`
######################################################################## 100.0%
      Added registry `General` to `~/.julia.temp/registries/General`
  Installed SortingAlgorithms ── v0.3.1
  Installed DataAPI ──────────── v1.1.0
  Installed Missings ─────────── v0.4.3
  Installed OrderedCollections ─ v1.1.0
  Installed DataStructures ───── v0.17.11
  Installed StatsBase ────────── v0.33.0

julia> Pkg.status(; mode = Pkg.PKGMODE_PROJECT)
Project Foo v0.1.0
     Status `~/Downloads/Foo.jl/Project.toml`
   2913bbd2 StatsBase v0.33.0

julia> Pkg.status(; mode = Pkg.PKGMODE_MANIFEST)
Project Foo v0.1.0
     Status `~/Downloads/Foo.jl/Manifest.toml`
   9a962f9c DataAPI v1.1.0
   864edb3b DataStructures v0.17.11
   e1d29d7a Missings v0.4.3
   bac558e1 OrderedCollections v1.1.0
   a2af1166 SortingAlgorithms v0.3.1
   2913bbd2 StatsBase v0.33.0
   2a0f44e3 Base64
   8ba89e20 Distributed
   b77e0a4c InteractiveUtils
   8f399da3 Libdl
   37e2e46d LinearAlgebra
   56ddb016 Logging
   d6f4376e Markdown
   de0858da Printf
   9a3f8284 Random
   9e88b42a Serialization
   6462fe0b Sockets
   2f01184e SparseArrays
   10745b16 Statistics
   8dfed614 Test
   4ec0a83e Unicode

julia> Pkg.test()
    Testing Foo
┌ Error: Pkg.Resolve.ResolverError("Unsatisfiable requirements detected for package StatsBase [2913bbd2]:\n StatsBase [2913bbd2] log:\n ├─possible versions are: [0.24.0, 0.25.0, 0.26.0, 0.27.0, 0.28.0-0.28.1, 0.29.0, 0.30.0, 0.31.0, 0.32.0-0.32.2, 0.33.0] or uninstalled\n ├─restricted to versions 0.32-0.33 by Foo [8f191a96], leaving only versions [0.32.0-0.32.2, 0.33.0]\n │ └─Foo [8f191a96] log:\n │   ├─possible versions are: 0.1.0 or uninstalled\n │   └─Foo [8f191a96] is fixed to version 0.1.0\n ├─restricted to versions 0.33.0 by an explicit requirement, leaving only versions 0.33.0\n └─restricted by compatibility requirements with DataFrames [a93c6f00] to versions: [0.24.0, 0.25.0, 0.26.0, 0.27.0, 0.28.0-0.28.1, 0.29.0, 0.30.0, 0.31.0, 0.32.0-0.32.2] — no versions left\n   └─DataFrames [a93c6f00] log:\n     ├─possible versions are: [0.11.7, 0.12.0, 0.13.0-0.13.1, 0.14.0-0.14.1, 0.15.0-0.15.2, 0.16.0, 0.17.0-0.17.1, 0.18.0-0.18.4, 0.19.0-0.19.4, 0.20.0-0.20.2] or uninstalled\n     └─restricted to versions 0.18 by an explicit requirement, leaving only versions 0.18.0-0.18.4", nothing)
└ @ Pkg.Operations ~/dev/repos/aluthge-forks/julia/usr/share/julia/stdlib/v1.5/Pkg/src/Operations.jl:1385
     Status `/private/var/folders/jy/7hh5zyw95cg2lh66lfpthqq80000gn/T/jl_05x15G/Project.toml`
   a93c6f00 DataFrames v0.18.4
   8f191a96 Foo v0.1.0 `~/Downloads/Foo.jl`
   2913bbd2 StatsBase v0.32.2
   8dfed614 Test
     Status `/private/var/folders/jy/7hh5zyw95cg2lh66lfpthqq80000gn/T/jl_05x15G/Manifest.toml`
   324d7699 CategoricalArrays v0.7.7
   34da2185 Compat v2.2.0
   9a962f9c DataAPI v1.1.0
   a93c6f00 DataFrames v0.18.4
   864edb3b DataStructures v0.17.11
   e2d170a0 DataValueInterfaces v1.0.0
   8f191a96 Foo v0.1.0 `~/Downloads/Foo.jl`
   82899510 IteratorInterfaceExtensions v1.0.0
   682c06a0 JSON v0.21.0
   e1d29d7a Missings v0.4.3
   bac558e1 OrderedCollections v1.1.0
   69de0a69 Parsers v1.0.1
   2dfb63ee PooledArrays v0.5.3
   189a3867 Reexport v0.2.0
   a2af1166 SortingAlgorithms v0.3.1
   2913bbd2 StatsBase v0.32.2
   3783bdb8 TableTraits v1.0.0
   bd369af6 Tables v0.2.11
   2a0f44e3 Base64
   ade2ca70 Dates
   8bb1440f DelimitedFiles
   8ba89e20 Distributed
   9fa8497b Future
   b77e0a4c InteractiveUtils
   76f85450 LibGit2
   8f399da3 Libdl
   37e2e46d LinearAlgebra
   56ddb016 Logging
   d6f4376e Markdown
   a63ad114 Mmap
   44cfe95a Pkg
   de0858da Printf
   3fa0cd96 REPL
   9a3f8284 Random
   ea8e919c SHA
   9e88b42a Serialization
   1a1011a3 SharedArrays
   6462fe0b Sockets
   2f01184e SparseArrays
   10745b16 Statistics
   8dfed614 Test
   cf7118a7 UUIDs
   4ec0a83e Unicode
    Testing Foo tests passed

As you can see, Pkg.test attempted to resolve the test dependencies, but failed to do so with the original manifest. Therefore, Pkg.test re-resolved everything. As you can see, the test suite ended up using StatsBase v0.32.2.
So even though the /Manifest.toml file had StatsBase v0.33.0, the test suite ended up using StatsBase v0.32.2.

I think that you will need to be on a relatively recent Julia master in order to reproduce these results.

Thank you for the super detailed example! Indeed, this happens on 1.4.0. I also agree that checking in a Manifest.toml doesn't make sense for everyone, which doesn't handle this anyways.
I'm sure the Pkg devs had a reason for it, but perhaps Pkg.test should fail if it cannot resolve the test dependencies with /Manifest.toml?
Other alternatives I can think of are:

Generate new compat entries using the same, merged environment that Pkg.test would see so that the unsatisfied requirement is never generated.
Make /test/Project.toml a superset of /Project.toml and use /test/Manifest.toml to generate new compat entries.

Either way, it looks like the problem is more challenging than I originally suspected.

I don't know Pkg internals very well, but isn't the right algorithm something like:

parse the Project.toml file
check the registry for newer versions of each dependency
call the resolver with the "loosened" bounds and see what version it chooses
submit PR only if the version it uses is newer than the bound in the Project.toml file, submitting the version that the resolver chose. For example, if the package is bounded at 0.7, and both 0.8 and 0.9 are available but the resolver chose 0.8.1, submit a new bound of 0.8 rather than 0.9.

See my example above. Even if the resolver gives you 0.8 of a package, if your compat entry is 0.7, 0.8, then your test suite might actually use 0.7 instead of 0.8.
So even if your test suite passes, it doesn't mean that your package is compatible with 0.8, because the test suite might have used 0.7.

So it seems like there are two orthogonal issues here:

The original issue: "Don't make PRs to packages that have a dependency that upper bounds the package CompatHelper bumps". Correct me if I'm wrong @DilumAluthge, but CompatHelper doesn't use the resolver when updating compat entries and instead pulls the latest versions directly from the registries. Because of this, the new compat entry may be invalid in that the resolver would never let you instantiate an environment with the new upper bound. The approach I took here solves this issue.
Making sure the tests are run with the updated compat entries as @DilumAluthge explained above. It seems like this issue stems from the fact that there is a "test-time" environment which is a result of resolving a package's dependencies and test-specific dependencies. While this could be handled in CompatHelper (possibly using one of the approaches in https://github.com/bcbi/CompatHelper.jl/issues/160#issuecomment-611852811), I think this is probably best handled by Pkg. Given the discussion in https://github.com/JuliaLang/Pkg.jl/issues/1233, it sounds like this may be a non-issue in the future if one uses the new test/{Project,Manifest}.toml scheme since it would remove any test-time resolving. I can confirm that using Run.jl to emulate this behavior works well (Run.test() is basically just Pkg.activate("test"); Pkg.instantiate(); include("test/runtests.jl")).

Does that sound correct?

Yes, it seem pretty important to be able to replicate the environment without having to run the tests.

As a temporary stopgap, I hacked together a script that (I believe) solves points (1) and (2) above for those using the Run.jl workflow (i.e. /Project.toml is dev'ed relative to /test/Project.toml). It takes a similar approach as above:

Replace existing compat entries with >= specifiers in both /Project.toml and /test/Project.toml/.
Run Pkg.up on /test/Manifest.toml.
Use the versions in /test/Manifest.toml to generate compat entries for both /Project.toml and /test/Project.toml.
Optionally, Pkg.up on /Manifest.toml with the new compat entries.

The end result is that the direct dependencies shared between /Project.toml and /test/Project.toml have the same compat entries and can be tested (since we generated them from /test/Manifest.toml). Here's an example PR and implementation.
Again, it's a ugly hack, but appears to be working.

See my example above. Even if the resolver gives you 0.8 of a package, if your compat entry is this:
[compat]
Foo = "0.7, 0.8"

then your test suite might actually use 0.7 instead of 0.8.

Wouldn't obtaining the actually used versions be quite easy? For example, calling Pkg.status(; io) after Pkg.instantiate() reports them. As a demo, I have a Project.toml containing DataFrames = "0.21, 0.22". On the generated website, the output shows DataFrames v0.21.8.

See my example above. Even if the resolver gives you 0.8 of a package, if your compat entry is this:
[compat]
Foo = "0.7, 0.8"

then your test suite might actually use 0.7 instead of 0.8.

Wouldn't obtaining the actually used versions be quite easy? For example, calling Pkg.status(; io) after Pkg.instantiate() reports them. As a demo, I have a Project.toml containing DataFrames = "0.21, 0.22". On the generated website, the output shows DataFrames v0.21.8.

When Pkg.test runs, it is allowed to re-resolve all of the versions.

When Pkg.test runs, it is allowed to re-resolve all of the versions.

In the demo above, all the versions have just freshly been obtained in a CI job. You mean that Pkg.test would still lead to other versions?

In the demo above, all the versions have just freshly been obtained in a CI job. You mean that Pkg.test would still lead to other versions?

Yeah, it's possible. Because you often have test-only dependencies, which add new constraints to the resolver.
The best long-term solution to this issue is https://github.com/JuliaLang/Pkg.jl/pull/2176

Yeah, it's possible. Because you often have test-only dependencies, which add new constraints to the resolver.
The best long-term solution to this issue is https://github.com/JuliaLang/Pkg.jl/pull/2176

Fair enough. Thanks

Fair enough. Thanks

This is now fixed by the combination of the following:

https://github.com/JuliaLang/Pkg.jl/pull/2439
https://github.com/julia-actions/julia-runtest/pull/20
https://github.com/julia-actions/julia-runtest/releases/tag/v1.6.0

If you use GitHub Actions for CI, and you use the julia-runtest action, and you use v1 of the julia-runtest action, you will get this fix automatically.
For example, if your GitHub Actions workflow file uses this line to run the tests...
- uses: julia-actions/julia-runtest@v1

...then you will get this fix automatically.
If you use a different CI provider, or if you use GitHub Actions but you do not use the julia-runtest action, then you will not get this fix automatically.


Create Medium sized photos JIT

It would be a decent feature to create medium sized photos JIT when someone views an album.
I use the Lycheesync script to import my photo's, and have thousands.  I have modified the script to create the medium sized files, but as you could imagine, this is very time consuming.
It should not be too hard to create the medium file when someone clicks on the thumbnail, then display the medium file.  You can have a set medium cache size, which will delete files as needed.
Then have a site wide flag for whether you want to show medium files or not.
I will have a look in the source, but i am not great with php.
cheers

The idea doesn't sound bad, but I'm not sure how performant it is to create them on the fly with PHP. I think it's worth the trade-off, that uploads take longer. Adding caching, checks if a file exist and JIT generation would add much more complexity to the code.


Vendor rubocop-rspec

We aren't going to vendor its dependencies because we already require a systemwide installation of rubocop to work in your editor. This avoids requiring users to manually do another gem install rubocop-rspec to have their editor integration behave as expected.
CC @javian @reitermarkus for thoughts

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

Looks good to me but you seem to be upgrading Rubocop to 0.59.2 as well. If so, shouldn't https://github.com/Homebrew/brew/blob/560cde1a1a6127cfd4a78e533fb8ac6afe87c3d2/Library/Homebrew/constants.rb be updated to reflect that ?

@javian Good call, updated.

Feels kind of weird to vendor this since this is a development dependency.

Feels kind of weird to vendor this since this is a development dependency.

@reitermarkus Yeh, I agree but I think having the in-editor integration work without the rubocop-rspec stuff being installed for all of Homebrew/brew would be nice. Any thoughts on how to limit that just to editing a spec?

Yeh, I agree

Yeah, that being said, I don't have anything concrete against it.

Any thoughts on how to limit that just to editing a spec?

No, nothing.

No, nothing.

I have something:

Merging for now in hope of being able to do something cleverer in future.


feat: Get execution resources

Feature Request
Describe the Feature Request
After each call get the number of steps required + the number of builtins used

Describe Preferred Solution
Get these informations in res.call_info.execution_resources in the python test file

Describe Alternatives

Related Code

Additional Context

If the feature request is approved, would you be willing to submit a PR?
Yes / No (Help can be provided if you need assistance submitting a PR)

I think this is done
Can we close it?

I think so yes, the merged PR #237 does this