Reading keyboard ctrlKey (Alt, Shift) state from monitor

I would like to modify drop action behavior depending on ctrl button state.
E.g. if Ctrl is pressed currently dragged item has to be copied to a new place or if Alt is pressed I want to snap dragged item to a grid.
I could obtain button state from DOM events but React DND hides such a detail completely. Opening respective methods via monitor methods would be one of the options to fulfill my request.

I don't think this is currently possible. Right now you'd have to maintain that state in the component with document key listeners likely.
I think the major issue with this is that key events and drag events are pretty separate, so I don't see a clean way of having react-dnd provide key information alongside drag information.

According to my sources, drag events contain all required stuff:
https://developer.mozilla.org/en-US/docs/Web/Events/dragend. I'm going to
make PR next week
Сб, 20 авг. 2016 г. в 13:12, Jordan Gensler<EMAIL_ADDRESS>
I don't think this is currently possible. Right now you'd have to maintain
that state in the component with document key listeners likely.
I think the major issue with this is that key events and drag events are
pretty separate, so I don't see a clean way of having react-dnd provide key
information alongside drag information.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gaearon/react-dnd/issues/512#issuecomment-241182210,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAfVFf10W0cbAabNEwVFWVsFpXRvKSHdks5qhprcgaJpZM4JnTsb
.

Oh rad, I stand corrected! That'd be interesting to see implemented!

Was there ever a PR submitted for this? I solved this in our fork of react-dnd but it broke with recent changes to the library.
We solved it by adding a meta property that back-ends could use to send arbitrary data, and used that object in the HTML5 back-end to store the event key information.

@richardolsson That's a great news! I must confess I've made no progress on this case yet. React-dnd is so multi-layered so I need a pen and piece of paper to design the changes. Taking unit tests and docs into account makes such PR way too complicated for me (at least not a one evening task).
Besides that I'd like to see it a first-class citizen, while meta looks like a w.

At the time, all I did was these two commits (to react-dnd and dnd-core respectively):
https://github.com/zetkin/react-dnd/commit/aedf6d6f39f15e3b8e19311255f71fef4bc218f5
https://github.com/zetkin/dnd-core/commit/dc8dee33455867fe1dc2f4f75f58196f77691732
This broke later when the react-dnd HTML5 backend was split out into a separate library. I'm sure it could be added back in, but it would likely require changes to all three libraries, so it would be three parallel pull requests.
The problem with adding a feature like this as a "first class citizen" is that react-dnd is all about drag and drop, and not all devices where drag and drop might be relevant have a keyboard.
This is why I added it as a "meta" object. It was a way for the back-end to send meta-data that is specific for that back-end, rather than universal to any drag and drop operation.

What I could find about this:

An older discussion where someone suggested to handle the bubbling drag events on a parent component and cause it to rerender the dragging child component with props according to the pressed modifier keys
This pull request where hard-coded Apple behaviour was added to the code, allowing to switch to Copy mode using the Alt key.

On Windows and Linux, it seems that Ctrl+Drag stands for copy, Shift+Drag for move and Alt+Drag for link. On Apple, it seems that Alt+Drag stands for copy and god knows what other modifier keys there are and what they stand for. There seem to be other platform-specific restrictions, for example on Linux you cannot Alt+Drag at all (because it moves the current window) and on Firefox on Apple you cannot Shift+Drag for some reason.
In our case, we need to distinguish only between two actions, link and copy, so we decided to make a drag without any keys do the link action and a drag with any modifier key a copy action. This way we circumvent the platform differences and people can just use whatever modifier key works on their platform.
We implemented this by hacking the existing Alt key functionality:
function isModifierKeyPressed(event) {
    return event.altKey || event.ctrlKey || event.metaKey || event.shiftKey;
}

export const HTML5BackendWithModifierKeys = (manager, context) => {
    const result = HTML5Backend(manager, context);

    result.handleTopDragEnter_ = result.handleTopDragEnter;
    result.handleTopDragEnter = (e) => {
        result.handleTopDragEnter_(e);
        result.altKeyPressed = isModifierKeyPressed(e);
    };

    result.handleTopDragOver_ = result.handleTopDragOver;
    result.handleTopDragOver = (e) => {
        result.handleTopDragOver_(e);
        result.altKeyPressed = isModifierKeyPressed(e);
    };

    return result;
};

The key can be pressed either before starting the drag operation or during it. There is one oddity however, that is that pressing or releasing the key is only registered when moving the mouse afterwards. When pressing or releasing the key and then immediately releasing the mouse without moving it, the key press/release is not registered. This seems to be a browser limitation though.
What's really annoying about this workaround still is that react-dnd only allows us to access the dropEffect in the drag end handler (using monitor.getDropResult()), but not during the drag operation. This makes it impossible to show which mode is active in the drag preview. I suppose the suggestion of reacting to the bubbling drag events might be a better solution here, but I haven't tried that yet.

@cdauth the fix doesn't work (anymore?) because getCurrentDropEffect is called inside the original handleTopDragX. I'm trying to patch around it without forking the repo, shame that the issue still hasn't been addressed.
I don't suppose you had any luck with bubbling the drop effect?

I'm not sure, when I wrote the hack we were using version 11.1.3, and from the source code it doesn't look like a lot has changed in that method since then. I guess if it doesn't work for you you could also try to modify the event object itself (haven’t tried that code, that’s just how I imagine it):
const altKeyHack = (event) => Object.assign(event, { altKey: event.altKey || event.ctrlKey || event.metaKey || event.shiftKey });

export const HTML5BackendWithModifierKeys = (manager, context) => Object.assign(HTML5Backend(manager, context), {
    handleTopDragEnter(e) {
        HTML5Backend.prototype.handleTopDragEnter.call(this, altKeyHack(e));
    }

    handleTopDragOver(e) {
        HTML5Backend.prototype.handleTopDragOver.call(this, altKeyHack(e));
    }
});


Add parameters for Zoom and Center, instead of Box

It would be very helpful to allow zoom and center to be passed as parameters

This is a good idea. We don’t need this so we won’t be working on it any time soon but I would welcome a Pull Request.

See also: https://github.com/digidem/mapbox-map-image-export/issues/12


Can not connect to virtual machine and source_image_reference refers to Ubuntu and the screenshot to Windows server

Can not connect to virtual machine and source_image_reference refers to Ubuntu and the screenshot to Windows server

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

ID: 9d19afc6-1ffc-4a7f-8445-be1ae063d1f1
Version Independent ID: c78ded33-98a6-2ef5-c766-308e75911d04
Content: Quickstart: Use Terraform to create a Windows VM - Azure Virtual Machines
Content Source: articles/virtual-machines/windows/quick-create-terraform.md
Service: virtual-machines
GitHub Login: @ericd-mst-github
Microsoft Alias: erd

Hello, and thank you for the feedback.
The source_image_reference will be updated shortly.
Can you also elaborate on which step you are running into the connection error?

@romusters
Thanks for your feedback! We will investigate and update as appropriate.

@romusters


Default branch is random after git push --mirror (when no main branch exists)

Taking into consideration @zeripath comment on #3913.

I believe this is fixed now. Please reopen if this is still a problem.
Originally posted by @zeripath in https://github.com/go-gitea/gitea/issues/3913#issuecomment-646294904

The same behavior observed on issue #3913 is happening when there's no main branch or if the default branch is other than the main branch (for example dev).
Discovered by @jmorauga, @KimberlyOlivas and @djherrer.

I think it's better to add a push option  like -o repo.default-branch = xxxx to set default branch manually.

What's the expected ?

What's the expected ?

That the default branch is kept the same.

BTW if you don't want to hardcode scripts to any branch name you can get the default branch with git ls-remote --quiet --symref upstream HEAD

I don't know if the sequence of branches is fixed when git push --mirror from git. If that, the first branch should be the default branch of Gitea.

Hi, maybe an Idea is, add a aditional row on repo.json per gitlab like:
"defaultMainRepo": "yourDefaultMainBranch"
and then when execute the migration add  -o repo.default-branch = xxxx ( concatenate the defaultMainRepo value in this section), and if this json value is null, run as main branch.
I think could be more userful the user put in there what are their custom main branch temporally and in the future maybe create a main branch detector similar of the next line:
git ls-remote --symref https://github.com/hnakamur/ltsvlog HEAD | awk '/^ref:/ {sub(/refs/heads//, "", $2); print $2}'

Tested in the latest version, the default branch will always be the correct one.
So it seems that this issue has been fixed, as there has been a long time from the first report, it is hard to figure out which PR(s) fixed this issue.
If someone can confirm whether it is really fixed, then we can closed this issue.


Add spy node ban list

The Monero Research Lab (MRL) https://github.com/monero-project/meta/issues/1119 to recommend that all Monero node operators enable a ban list of suspected spy node IP addresses. The spy nodes can reduce the privacy of Monero users.

https://github.com/monero-project/meta/issues/1124

thanks for your contribution


Hello, did Expert Mesh participate in the model prediction process? And what was its role when doing the inference?

The expert mesh is used to project the labels on the sequence of intermediate meshes. If you want to use AMBER for inference only, you could either input a constant label, or re-write the code to make this parameter optional :)


Parsing "Microsoft encoding" is very lenient

I was reading through the code for Parse and I noticed that there is no validation on the first and last characters of the uuid-to-parse when the length of the input is 38 characters:
https://github.com/google/uuid/blob/16ca3eab7d2086fd5a82993a291cbf3b87fe38b7/uuid.go#L38-L61
I would expect there to be a check that s[0] == '{' && s[37] == '}' rather than simply ignoring those two characters. I am happy to send a PR if requested, it's a simple change. I am just verifying that this loose behavior is not actually desired.
(fwiw, it means that parsing something like a01234567-abcd-cdef-abcd-012345678901a would be parsed without an error, even though it has extra characters at the beginning and end. That's quite unexpected IMO.)

Thank you for pointing this out.  Yes, this is a bug and should be fixed.  Would be happy to have you send in a PR for this.

I've just come across this by virtue of the fact that:

"921ef402-cd4c-4be6-8483-a00566a43f60" -> Correctly succeeds
" 921ef402-cd4c-4be6-8483-a00566a43f60" -> Correctly fails to parse
"921ef402-cd4c-4be6-8483-a00566a43f60 " -> Correctly fails to parse
" 921ef402-cd4c-4be6-8483-a00566a43f60 " -> Unexpectedly succeeds!

Turns out it's not that it ignores whitespace if present at both ends, but it's just another version of this bug.


run the command "az apic api register -h " there are extra spaces in  the --api-location -l argument description

Describe the bug

Extra spaces appear after file
Related command
az apic api register -h
Errors
no error message
Issue script & Debug output
az apic api register -h
This command is from the following extension: apic-extension
Command
az apic api register : Registers a new API with version, definition, and associated deployments
using the specification file as the source of truth.
This command is in preview and under development. Reference and support levels:
https://aka.ms/CLI_refstatus
Arguments
--api-location -l   [Required] : Location of spec file  .
--resource-group -g [Required] : Resource group name.
--service -s        [Required] : APICenter Catalog or Service name.
--environment-name -e          : Name of environment created before.
Expected behavior
no extra spaces
Environment Summary
azure-cli                         2.58.0 *
core                              2.58.0 *
telemetry                          1.1.0
Extensions:
apic-extension                   1.0.0b5
Dependencies:
msal                              1.26.0
azure-mgmt-resource             23.1.0b2
Additional context
No response

Verified.


Updated sql programming guide to include jdbc fetch size

Can one of the admins verify this patch?

Jenkins, this is ok to test.

Merged build triggered.

Merged build started.

Test build #44740 has started for PR 9377 at commit 2806c26.

Test build #44740 has finished for PR 9377 at commit 2806c26.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44740/
Test PASSed.

Merged build finished. Test PASSed.

Thanks - going to merge this.


refactor setup-ui into fedimintd

In preparation for adding DKG to the setup-ui, first we need to move the setup-ui code into fedimintd so it has access to the config generation code.
Also this separates dependencies for config generation + UI from the server + consensus dependencies.

Looks good. Didn't merge because it's still a draft ..

Looks good. Didn't merge because it's still a draft ..

Thanks!


da.isel(lon=slice(0, 1), lat=slice(0, 1), time=slice(0, 1)) is not start and end inclusive

Describe the bug
The following code is not start and end inclusive (off by one)
da.isel(lon=slice(0, 1), lat=slice(0, 1), time=slice(0, 1))
print(da) # produces dimensions (1, 1, 1) should be (2, 2, 2)

<xarray.Dataset>
Dimensions:      (time: 1, lat: 1, lon: 1) # should be  (time: 2, lat: 2, lon: 2)
Coordinates:
  * lat          (lat) float64 -42.0
  * lon          (lon) float64 148.0
  * time         (time) datetime64[ns] 2023-06-01T05:30:00
Data variables:
    var1          (time, lat, lon) float64 ...

Closing due to #4 being merged to master


Issues for 4-18

--Make the Last Trade Date in prefs "Last Live Trade Date"
--Make the paper account trades include TradeKing's commissions

Make the buttons on the main activity fit correctly.

all three complete.


CANT BID FLIGHTS AFTER ADDING FARES

Describe the bug
A clear and concise description of what the bug is. Please upload the Laravel logs as well from storage/logs/laravel.log (or the file with the correct date)
I have added fares to our database and added those fare codes to my subfleet but when go and bid a flight i get this sql error
Version
Please enter the version
php vms 7
To Reproduce
Steps to reproduce the behavior:

Go to '...'subfleet
Click on '....'allot them a fare
Scroll down to '....'bid a flight
See error

Expected behavior
A clear and concise description of what you expected to happen.
the booking should be bidded
Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context and attach logs (from storage/logs/laravel-<date>.log)
AAL-sub.csv
fares.csv

error fixed our fault


Add compatibility tests to CI

test key environments such as jest (v25 & 26 for esm), create-react-app react-native, playwright for cross browser https://github.com/microsoft/playwright (hopefully supporting esm)

mocha puppeter https://www.google.com/search?q=puppeteer+mocha&oq=puppeteer+mocha&aqs=chrome..69i57j0l4.3296j1j7&sourceid=chrome&ie=UTF-8

playwright mocha https://playwright.dev/#version=v1.0.1&path=docs%2Ftest-runners.md&q=mocha

@fetch-mock/core is far simpler now, not requiring node-fetch, and it also removes the sandbox() method, which was also a cause of clashes, so less need fro these tests now


Show best time and space complexity of a problem

I was thinking that when either looking at the table where the problem is located with the link, video solution, etc or when clicking on the code solution that it could show what time and space complexity (time more important) a persons solution should be. I know its explained in most videos but having it in text somewhere where you can easily see it would be nice

The maintainers should add this to the Contribution Guidelines to add Space and Time complexity for every solution code in comments.
I hope this would be beneficial .


Is it possible to run this "medical-imaging-diagnostics" application on a GPU or an XGPU?

I successfully ran the application using a CPU but wanted to leverage the power of a GPU for improved performance. However, upon attempting to run it with a GPU, I encountered the following log error:
log: E itex/core/wrapper/itex_gpu_wrapper.cc:49] Could not load Intel Extension for Tensorflow* GPU backend, GPU will not be used.
I've also upgraded the intel-extension-for-tensorflow using "pip install --upgrade intel-extension-for-tensorflow[xpu]" command. but still facing the same thing as mentioned above.
Could you please provide some insight into the reason behind this issue? Alternatively, is this application designed solely for CPU usage?

Hello AryanKarumuri.
This application is designed for CPU, GPU support is not implemented.

Hi Alberto,
Thanks for the information.


[docs]: react/column-dnd  doesn't work

Describe the bug

invalid
Your minimal, reproducible example
https://tanstack.com/table/v8/docs/examples/react/column-dnd
Steps to reproduce
..
Expected behavior
..
How often does this bug happen?
None
Screenshots or Videos
No response
Platform
chrome
react-table version
v8
TypeScript version
No response
Additional context
No response
Terms & Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

It doesn't work for me either. I've tried in my code and it doesn't work. The reordering function is working as expected, the state of the variable with the order is ok, but the columns doesn't reorder

@lortschi The docs link has not been removed, the entire site just had a URL restructure recently. Just browse the sidebar.
A new column ordering guide has been made: https://tanstack.com/table/v8/docs/guide/column-ordering
And the column DnD example was rewritten with DnD Kit: https://tanstack.com/table/v8/docs/framework/react/examples/column-dnd
I don't know what page you are seeing where the react-dnd bugs still persist? This was all updated last night though, so maybe you're seeing a cached version of the example.


not to push data into ADX using databricks spark.

Describe the bug
i have followed the steps mentioned it below:

created table as mentioned it below in My Dataexplor
.create table subscore (subject1 : string, subject2:string, subject3:string)
I have create databricks cluster and added the below dependency libraries

%python
import pyspark
from pyspark.sql import SparkSession
creating sparksession and giving
an app name
spark = SparkSession.builder.appName('sparkdf').getOrCreate()
list  of college data with two lists
data = [["java", "dbms", "python"],
["OOPS", "SQL", "Machine Learning"]]
giving column names of dataframe
columns = ["Subject 1", "Subject 2", "Subject 3"]
creating a dataframe
dataframe = spark.createDataFrame(data, columns)
show data frame
dataframe.show()
KustoSparkTestAppId = "ba63fxxx-xxxx-xxxx-xxxx-d5b9f9688cdd"
KustoSparkTestAppKey = "1xxxx~xddxxx"
appId = KustoSparkTestAppId
appKey = KustoSparkTestAppKey
authorityId = "02aa9fc1-xxx-xxxx-xxxx-xxxx854dd434"
dataframe.write.
format("com.microsoft.kusto.spark.datasource").
option("kustoCluster", "https://mycluster.kusto.windows.net").
option("kustoDatabase", "xom1database").
option("kustoTable", "subscore").
option("kustoAadAppId", appId).
option("kustoAadAppSecret",appKey).
option("kustoAadAuthorityID", authorityId).
mode("Append").
save()
The below error message I am getting it.

To Reproduce
Steps to reproduce the behavior:
Expected behavior
two rows should be inserted into table, but it is not happening.
Screenshots

Desktop (please complete the following information):

Additional context
Add any other context about the problem here.

Am I missing any libraries here?

Try it.

Thanks for response Rengar lee. It is working now. but I am getting into another issue, inserting two records It is taking 5 mins

is it a driver issue or anything we need to configure it?

Defaulr kusto batching time is 5 minutes
You should change database batching policy
https://github.com/Azure/azure-kusto-spark/blob/master/samples/src/main/python/pyKusto.py
Less recommended is to use the flushimmediately flag
https://github.com/Azure/azure-kusto-spark/blob/master/samples/src/main/python/pyKusto.py
Line 85
Setting true for first argument


File imports in --predef string are resolved from the wrong folder

lihaoyi test$ ls
foo.sc
lihaoyi test$ cat foo.sc
object world {
  val hello = "Hello, world!"
}
import world._
lihaoyi test$ pwd
/Users/lihaoyi/Dropbox/Workspace/test
lihaoyi test$ amm --predef 'import $file.foo'
Loading...
Error loading Predef:
Cannot resolve $file import: /Users/lihaoyi/Dropbox/Workspace/foo.sc

Seems like it's trying to resolve them from the parent of the pwd, rather than the pwd itself.

The latest test branch commit https://github.com/lihaoyi/Ammonite/commit/de1508103e893e994dba44c6c10141b6eacd8682 disallows import $file within your --predef-code. If someone really wants this they can make it work, but until then banning it is probably good enough


Moved arm64 build to its own workflow step

This PR moves the 3ish hour ARM docker image build step into its own contained (ha) step that won't impede the release of tarballs or the amd64 docker image.
I've also tagged the arm image separately which seems like a common pattern from doing some research. I'm currently investigating if we can avoid doing this separate tag and just push to the same tag with 2 platforms, but I don't want to overwrite the amd64 image doing so.
Signed-off-by: Brooks Townsend<EMAIL_ADDRESS>

closing this as there is a better solution to this problem


CurrentUrl = ??

Hello,
I am a beginner in Python and I changed the Url's but still my wallpaper isn't changing.
i changed the pic_url and the api key (APIKEYOWM)
but on the website there are lots of different url's for the CurrentUrl = ...
so which one do I use ?
are those 3 url's the only thing i need to change ?
thanks and sorry if i asked a useless question (i am also learning english)

Are you getting a specific error?
Make sure you haven't placed the api key inside of os.getenv("API_KEY") this is an environment variable so you could either create your own .env file or just add your api key like this: APIKEYOWM = "YOUR KEY"
Otherwise try cloning the newest version of this repository and report any errors.

i updated the program and now there are only two links but nothing happend
I think the problem is that the program just dosen't start.

here is the error
C:\Users\chena\3D Objects\WALLPAPER\WallPaperChanger-main>python -m wallpaperChanger.mainScript
Traceback (most recent call last):
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.2032.0_x64__qbz5n2kfra8p0\lib\runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.2032.0_x64__qbz5n2kfra8p0\lib\runpy.py", line 87, in _run_code
exec(code, run_globals)
File "C:\Users\chena\3D Objects\WALLPAPER\WallPaperChanger-main\wallpaperChanger\mainScript.py", line 29, in
CurrentUrl = f"http://api.openweathermap.org/data/2.5/weather?q={2661187}&mode=xml&units=metric&APPID={a65b38088fbd3479f436ad8c984cfd5d}"  # <---
NameError: name 'a65b38088fbd3479f436ad8c984cfd5d' is not defined

When you add your city name and API key, you are to replace the curly brackets as well. For example, ...?q=sydney& instead of
...?q={sydney}&

It worked !
thanks and sorry cause it was a small mistake


Update the examples as per Minishift v1.7.0

Fix #4

Thanks a lot for this PR @budhrg and sorry for the delay, been on travel. Overall looks good, but there's one issue I'd like you to ask to fix (or we wait until I update it to Kube 1.7 later this year, up to you). You're using  in a number of places minishift ssh or other Minishift-specific idioms. Now, while the examples are done with Minishift, this is not a Minishift-specific by-example site but a general Kubernetes one so we should not introduce such implementation-specific details unless there is a good reason for it. Hope this makes sense?

ou're using in a number of places minishift ssh or other Minishift-specific idioms. Now, while the examples are done with Minishift, this is not a Minishift-specific by-example site but a general Kubernetes one so we should not introduce such implementation-specific details unless there is a good reason for it. Hope this makes sense?

Make sense :+1:
Updated the PR @mhausenblas Thanks

Awesome, thanks a lot!

Awesome, thanks a lot!

My pleasure :smile:

@mhausenblas , you forgot to update the website again :wink:

Geez, when will I ever learn. Guess we should automate that process ;)
Done!

Geez, when will I ever learn. Guess we should automate that process ;)

That would be awesome @mhausenblas  :+1:


Limit str to 100 to avoid ReDoS of 0.3s

Hey,
The fix for CVE-2015-8315 was incomplete. Limiting the input to 10,000 chars reduced the risk significantly but it is still possible to cause a delay of 0.3s. Suggested to limit it to 100 chars as there is no reason for a date to be over that :)
PoC:
ms=require('ms');
ms('1'.repeat(9998) + 'Q')
//Takes about ~0.3s

Thanks,
Karen Yavine
Security Analyst @ snyk.io

#90

Sweet! Thank you. 😊

Hey @leo!
Thanks for merging the PR!
Wondered when a new version will be released to npm?

Sad that module authors does not care about performance at all.

@karenyavine It was just released with version 2.0.0! 🎉

@leo, thanks for the fix and the release.
I was wondering why was this a breaking change, requiring a major release?

Because we lowered the limit. So if people have longer strings in place, it will break.

@leo I offer solution to not simply decrease limit, but to rework parsing, that boost parse speed up to 2 times

+1 on @Delagen's solution. Both the previous fix of limiting to 10000 chars, and the new one of limiting to 100 chars were merely a workaround.


[S-RUNNER] Initial commit of Shark Runner Inferene API.

Added shark-runner inference API, fully functional given only one input.

Missed the review request. I have also never built a pip package, but as long as we follow the general structure of organizing stuff into folders based on functionality, we should be fine


"Retry as Sudo" should honor NOPASSWD

Issue Type: Bug
To reproduce, create a linux user that is part of a group that can use the sudo command without password (NOPASSWD), then try to save a file that isn't writable without sudo privileges:

Currently, when clicking "Retry as Sudo", vscode prompts the user to input its password, even if he can use sudo without a password:

In this case, I think vscode shouldn't prompt for a password and honor the sudo configuration.
VS Code version: Code 1.43.2 (0ba0ca52957102ca3527cf479571617f0de6ed50, 2020-03-24T07:52:11.516Z)
OS version: Linux x64 5.5.13-arch1-1

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz (4 x 2494)

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

Load (avg)
1, 1, 1

Memory (System)
7.48GB (2.42GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (9)

Extension
Author (truncated)
Version

vscode-icontheme-nomo-dark
be5
1.3.6

vscode-intelephense-client
bme
1.3.11

gitlens
eam
10.2.1

php-debug
fel
1.13.0

docthis
joe
0.7.1

git-graph
mhu
1.22.0

vscode-docker
ms-
1.0.0

vsliveshare
ms-
1.0.1847

debugger-for-chrome
msj
4.12.6

@charlesg99 we use sudo-prompt so I think you should ask there, but I found https://github.com/jorangreef/sudo-prompt/issues/58 which may explain a solution?

Hello bpasero! Thank you for your research and sorry about the noise, I wasn't aware that you're using a third party solution for sudo. Seems like the issue you mentioned indeed contains a workaround  using environment variables, although it feels like this should just work out of the box. Thanks!


Ar is not working on Android Firefox, ar button is redirecting user to previous page

Description
AR is not working on Android Firefox and what weirder rather just not opening ar it goes back to the previous page
Live Demo
It works the same on my demo:
my demo
or model-viewer glitch
glitch
Version

model-viewer: v1.2.1

Browser Affected

[ ] Chrome
[ ] Edge
[x] Firefox
[ ] IE
[ ] Safari

OS

[x] Android
[ ] iOS
[ ] Linux
[ ] MacOS
[ ] Windows

@elalish  I have investigated it a little bit and its seems that there are two problems

self.history.back(); in ar.ts , on firefox it seems like after S.browser_fallback_url is triggered it wont add it to history. but it might be connected with nr 2.
firefox issue with S.browser_fallback_url i have oppened an issue for that https://github.com/mozilla-mobile/fenix/issues/15952

@matios13 Thanks, I was just looking at this as well. It seems Firefox still doesn't support app intents, and they fail in a strange way. I'm just going to screen Firefox out for AR until it supports these things.


match_array not using proper item equality check (3.3.0)

After upgrading to 3.3.0, I started seeing a handful of consistent spec failures.

Installed through rspec-rails version 3.3.0
Rails version 4.2.1
Using infer_spec_type_from_file_location!

Failure/Error: expect(cart.remove_entry(line_item.id)).to match_array([line_item])
        expected collection contained:  [#<OrderLineItem id: 272, order_id: 300, unit_price_cents: 2, quantity: #<BigDecimal:7fbf32f3f338,'0.1E1',9(27)>, created_at: "2015-06-12 21:07:45", updated_at: "2015-06-12 21:07:45", price_book_entry_id: 460, discount_code_used: nil, position: 2, hidden: false>]
        actual collection contained:    [#<OrderLineItem id: 272, order_id: 300, unit_price_cents: 2, quantity: #<BigDecimal:7fbf334d8c90,'0.1E1',9(18)>, created_at: "2015-06-12 21:07:45", updated_at: "2015-06-12 21:07:45", price_book_entry_id: 460, discount_code_used: nil, position: 2, hidden: false>]
        the missing elements were:      [#<OrderLineItem id: 272, order_id: 300, unit_price_cents: 2, quantity: #<BigDecimal:7fbf32f3f338,'0.1E1',9(27)>, created_at: "2015-06-12 21:07:45", updated_at: "2015-06-12 21:07:45", price_book_entry_id: 460, discount_code_used: nil, position: 2, hidden: false>]
        the extra elements were:        [#<OrderLineItem id: 272, order_id: 300, unit_price_cents: 2, quantity: #<BigDecimal:7fbf334d8c90,'0.1E1',9(18)>, created_at: "2015-06-12 21:07:45", updated_at: "2015-06-12 21:07:45", price_book_entry_id: 460, discount_code_used: nil, position: 2, hidden: false>]
      # ./spec/models/cart_spec.rb:144:in `block (4 levels) in <top (required)>'

Any chance you could put together a reproducible example for this?
Thanks!

FWIW, I tried to repro with this:
user = User.create!(name: 'foo')
reloaded = User.find(user.id)

expect([user]).to match_array([reloaded])

...and it passes just fine.  There's got to be something different about your case, but I have no way to guess what it is :(.

The only thing that might be different would be the fact that quantity is a decimal, loaded into the object as a BigDecimal, which you can see in my example results in different object IDs for that attribute on each record.

I'm not sure that BigDecimal is an issue. The object ids won't affect it. The precision between the two values is a little different, but unless the values that are stored required the larger of the precisions the two BigDecimal instances will be equal.
Can you share your remove_entry method? It is important to understand what is happening under the hood.
I was thinking that it was possible that the timestamps are at fault. However, if these are ActiveRecord instances, their equality is simply based on their id values. What is potentially happening is that something is mutating either object state between the expectation check and the description being formatted. I would need to know what remove_entry does to understand what it's true object type is.

Turns out the issue is that the returned OrderLineItem is actually wrapped in another object:
class LineItemBundle < DelegateClass(OrderLineItem)

In 3.3.0, the contains_exactly matcher appears to have reversed the order in which object equality is assessed, which is why these specs started failing:
[1] pry(main)> line_item = OrderLineItem.first
  OrderLineItem Load (8.6ms)  SELECT  "order_line_items".* FROM "order_line_items"  ORDER BY "order_line_items"."id" ASC LIMIT 1
=> #<OrderLineItem:0x007f9cec6cedb0 id: 1, ...>
[2] pry(main)> LineItemBundle.new(line_item) == line_item
=> true
[3] pry(main)> line_item == LineItemBundle.new(line_item)
=> false

We can work around the issue now that we know what it is, but it's a little unintuitive that equality seems to be evaluated in reverse order of written expectation.

@ahorner thank you for that details :blue_heart: I have reproduced the issue. Though I haven't been able to narrow down the cause.
Can you let me know which version you upgraded from?

I originally attempted to upgrade directly from 3.2.0, but have confirmed that the issue is not present in 3.2.3.

Thanks! :heart: I'll have to start digging further.
Currently, I'm not sure I see a regression here, at least not yet. From your description it seems a :bug: was fixed with the contains_exactly matcher :smile_cat:; though I do not see a cursory explanation for the change based on that matcher's history :grimacing:. It is possible updates across some of our repos have created a regression, but without a repo scenario based on a prior RSpec version, it will be difficult to track down.
I've looked at the current behavior and we may need to update some docs to explain it a bit more. Please let me know if the following makes sense or seems odd to you:

given we have the following classes:
Widget         = Struct.new(:name)
WidgetDelegate = Class.new(DelegateClass(Widget))

the same widget is equal to itself
a_widget = Widget.new("Any Name")
a_widget == a_widget
# => true
a_widget === a_widget
# => true

since Struct equality is based on the equality of all member attributes, two widgets with the same attributes are equal:
some_widget    = Widget.new("Matching Specific Name")
another_widget = Widget.new("Matching Specific Name")
some_widget == another_widget
# => true
some_widget === another_widget
# => true
another_widget == some_widget
# => true
another_widget === some_widget
# => true

by default a Ruby object (at least in 2.2) has four "equality" checks:

Object#=== (also called "case equality" or "match equality")

Case Equality – For class Object, effectively the same as calling #==, but typically overridden by descendants to provide meaningful semantics in case statements.

BasicObject#==

Equality — At the Object level, == returns true only if obj and other are the same object. Typically, this method is overridden in descendant classes to provide class-specific meaning.

Object#eql?

The eql? method returns true if obj and other refer to the same hash key. This is used by Hash to test members for equality. For objects of class Object, eql? is synonymous with ==. Subclasses normally continue this tradition by aliasing eql? to their overridden == method, but there are exceptions. Numeric types, for example, perform type conversion across ==, but not across eql?

BasicObject#equal?

Unlike ==, the equal? method should never be overridden by subclasses as it is used to determine object identity (that is, a.equal?(b) if and only if a is the same object as b)

in the case of an expectation: expect(actual_object).to eq(expected_object)
Language parsing rules dictate that the above expression states the "authoritative" source on equality is the expected_object. Thus we can use the earlier objects and see:
a_widget   = Widget.new("Any Name")
a_delegate = WidgetDelegate.new(a_widget)
a_widget == a_delegate
# => false
a_widget === a_delegate
# => false
a_delegate == a_widget
# => true
a_delegate === a_widget
# => true

a_widget.class
=> Widget
a_delegate.class
=> WidgetDelegate

When we use the a_widget as the "authoritative" source, the equality checks fail. This happens because, even though the struct Widget has overridden == to match based on equal member attributes, it still expects equality based on the object type. Since the a_widget and a_delegate types do not match the check fails.
If we make a_delegate the "authoritative" source, the checks pass. This is because the delegate passes the == and === messages to the underlying Widget object. Thus a_delegate == a_widget turns into a_widget == a_widget. Since the two objects are the same type and have the same attributes (in face in this instance they are the same object), the checks pass.

Based on the above behavior, I would assume that if:
expect(a_delegate).to eq(a_widget)

does not pass (it does not). Then both of the following should also not pass (they do not):
expect([a_delegate]).to contain_exactly([a_widget])
expect([a_delegate]).to match_array([a_widget])

In general, we expect == to be symmetric, so that (a == b) == (b == a).  To the extent that objects follow this, it shouldn't matter whether we check actual == expected or expected == actual.
We intentionally changed it from actual == expected to expected == actual for 3.3 in response to issues opened by users.  The specific change was here:
https://github.com/rspec/rspec-support/pull/193
This solved a specific issue multiple users ran into where objects with buggy == definition were passed to RSpec and would blow up.  It's a common mistake to define == like this:
class Color
  attr_reader :r, :g, :b

  def initialize(r, g, b)
    @r, @g, @b = r, g, b
  end

  def ==(other)
    other.r == r && other.g == g && other.b == b
  end
end

With this kind of definition Color#== works properly against other Color instances but raises errors when given any other kind of object, when it should return false for such situations.  When users do that they would get confusing errors that look liked they happened in RSpec when they did simple things like:
expect(display).to receive(:change_color).with(anything)
display.change_color(Color.new(10, 10, 10))

...because we were calling actual == expected (e.g. Color#==(anything)).  Switching to expected == anything fixed this problem.  See rspec/rspec-mocks#923 and rspec/rspec-expectations#732 for examples of reports from users about these problems.
I'm sorry that our bug fix for others caused this problem for you :(.  I didn't expect it -- as I said, we expect == to be symmetric, and as long as that's followed, our switch shouldn't affect anyone.
In this particular case, the non-symmetry of == is coming from a the ruby stdlib (DelegateClass) so there's not much you or us can do about that :(.
So I'm not really sure what, if anything we should do about this.

:smile_cat: @myronmarston thanks for identify the root change

In this particular case, the non-symmetry of == is coming from a the ruby stdlib (DelegateClass) so there's not much you or us can do about that :(.

@ahorner I'm going to hazard a guess that you own both LineItemBundle and OrderLineItem definitions. While possibly not the most ideal options I see two things you could do to change the equality behavior (using my code sample from above):

Implement a custom equality check using message passing so that delegators can intercept:
Widget = Struct.new(:name) do
  def ==(other)
    other.kind_of?(self.class) && name == other.name
  end
end

WidgetDelegate = Class.new(DelegateClass(Widget)) do
  def initialize(obj)
    @obj = obj
    super
  end

  def kind_of?(klass)
    @obj.kind_of?(klass)
  end
  alias_method :is_a?, :kind_of?
end

expect(a_widget).to eq a_delegate                   # pass
expect(a_widget).to match a_delegate                # pass
expect(a_delegate).to eq a_widget                   # pass
expect(a_delegate).to match a_widget                # pass
expect([a_delegate]).to match_array [a_widget]      # pass
expect([a_delegate]).to contain_exactly a_widget    # pass

Implement a custom conversion method:
Widget = Struct.new(:name) do
  def ==(other)
    super || (
      other.respond_to?(:to_widget) && other == self
    )
  end

  def to_widget
    self
  end
end

WidgetDelegate = Class.new(DelegateClass(Widget)) do
  def initialize(obj)
    @obj = obj
    super
  end

  def to_widget
    @obj
  end
end

expect(a_widget).to eq a_delegate                   # pass
expect(a_widget).to match a_delegate                # pass
expect(a_delegate).to eq a_widget                   # pass
expect(a_delegate).to match a_widget                # pass
expect([a_delegate]).to match_array [a_widget]      # pass
expect([a_delegate]).to contain_exactly a_widget    # pass

I think this is just the flip side of the issue we attempt to solve by flipping actual == expected, this is still a "buggy" #== operator

I think this is just the flip side of the issue we attempt to solve by flipping actual == expected, this is still a "buggy" #== operator

Yep, that's basically what I said above.  Problem is, the "buggy" #== definition comes from the ruby stdlib and is intentional, I believe.  After all, DelegateClass and SimpleDelegator are designed to proxy all their methods to the wrapped object...so == is proxied, too.

I think at this point I would be satisfied with updating the object description in the spec output to reflect the delegator's class. My confusion originally came from the fact that it wasn't obvious at all that a delegator was involved (probably due to #inspect also being delegated).

I think at this point I would be satisfied with updating the object description in the spec output to reflect the delegator's class. My confusion originally came from the fact that it wasn't obvious at all that a delegator was involved (probably due to #inspect also being delegated).

Do you have specific output in mind for this situation?

To handle the case of nested delegators, and also maintain information about the underlying item's actual class, something like the following might be appropriate:
def description(object)
  if object.respond_to?(:__getobj__)
    delegated_class = object.__getobj__.class
    description(object.__getobj__).sub(delegated_class.to_s, "#{object.class}:#{delegated_class}")
  else
    object.inspect
  end
end

> description(OrderLineItem.first)
=> "#<OrderLineItem id: 1, ...>"
> description(LineItemBundle.new(OrderLineItem.first))
=> "#<LineItemBundle:OrderLineItem id: 1, ...>"
> description(LineItemBundle.new(OtherDelegator.new(OrderLineItem.first)))
=> "#<LineItemBundle:OtherDelegator:OrderLineItem id: 1, ...>"

I'm completely open to feedback on this. If people think it's a good idea, I can open a PR to fit it into the existing object description code.

I think it's worth doing, although I think I might prefer it formatting something like:
> description(LineItemBundle.new(OrderLineItem.first))
=> "#<LineItemBundle(#<OrderLineItem id: 1, ...>)>"

Essentially using parens to "wrap" the inner inspect just like the delegator wraps the object.
Here's where this would go:
https://github.com/rspec/rspec-support/blob/master/lib/rspec/support/object_formatter.rb
Closing here since there's nothing actionable to do in rspec-core.

We just ran into this, too. We've got a class Status where we've overridden the == operator so that we can compare against a string like status == 'submitted'.  You will need to implement to_str though. Just be aware that by implementing to_str you are telling Ruby that it can usually treat your class as a String. However, normally in when Ruby wants to do that (such as with ==), it will invert the call and ask your object to respond:
Status = Struct.new(:name) do
  def ==(other)
    p("IN CUSTOM ==")
  end
  def to_str
    name
  end
end

submitted = Status.new('submitted')
submitted == 'submitted'
# "IN CUSTOM =="
# => "IN CUSTOM =="

'submitted' == submitted
# "IN CUSTOM =="
# => true

I have not audited the behavior too deeply so actual milage may very.

Thanks, I'll give that a try. After thinking about it some more, though, I don't really agree with the idea that == needs to always be symmetric (or that RSpec should be enforcing it). In this case, saying 'submitted' == status seems a little like saying "doctor is a Bob". It's a little unintuitive also to have to know that RSpec is going to compare things in the reverse order of what you specify.

Thanks, I'll give that a try. After thinking about it some more, though, I don't really agree with the idea that == needs to always be symmetric (or that RSpec should be enforcing it).

I suppose we could check == both ways, but it's been shown by multiple user reports that calling == on the actual object can and does lead to errors that users report back to us and expect us to work around or avoid.  We're trying to please everyone but I don't know if we can here :(.

It's a little unintuitive also to have to know that RSpec is going to compare things in the reverse order of what you specify.

Why do you find it unintuitive?  The objects passed to the matcher are the things you've provided as the standard of comparison....so doesn't it make more sense for us to check with them?  Other users have argued in favor of this, because they found it unintuitive in RSpec 3.0...3.2 that we used the actual object as the standard of comparison rather than expected.  For example, see rspec/rspec-mocks#730:

There are several things wrong with this.

First, we are invoking == on actual. This is not the matcher, it is the value being matched, and we should not be consulting it on the topic of it being equal to a matcher. Equality should always be decided by the value in the test, not the value under test.

So I've got some users telling me that actual == expected is unintuitive and they'd expect expected == actual, and I've got you telling me the opposite.  I believe RSpec 2 always checked expected == actual and no one ever complained (that I know of).
Meanwhile, we've got others users that have defined == so that actual == expected raises errors when expected is not of the same class.
I'm still of the opinion that == should be symmetric, and objects that violate this are fundamentally busted, hard to reason about and lead to all sorts of surprises.  Still, I'm open to doing whatever we can reasonably do to smooth this out for users...but it's not clear to me what that would be, given all the history above.
Bear in mind that == has a very specific meaning (value equality) and it doesn't make sense to me to say that a string is equal to an instance of Status.  Ruby has other operators (such as ===) that are meant to support "loose matching" rather than strict value equality.  Is there any reason you can't use === for your case since it looks to me like "matching" is really what you are going for?

it's been shown by multiple user reports that calling == on the actual object can and does lead to errors that users report back to us and expect us to work around or avoid.

This is understandable. I don't really have a good solution to the problem. Is there no way you could detect this sort of error and give the user a more meaningful message?

Why do you find it unintuitive?

To me this is unintuitive because when I write expect(a).to eq(b) I expect it to evaluate a == b, in the order it's read. It's confusing to me to occasionally bump up against it and have to realize that, oh yeah, RSpec compares it the other way. I remember that from RSpec 2 and always felt it was a little odd.

I'm still of the opinion that == should be symmetric, and objects that violate this are fundamentally busted, hard to reason about and lead to all sorts of surprises.

I understand the motivation for wanting it to be symmetrical, though I disagree that it is "fundamentally busted" if not, and don't really think it's the place for RSpec to try to enforce it. And, in fact, as far as I can tell swapping the order is just inverting the problem. Instead of making sure a has defined #==, we're just making sure b has defined #==.

Is there any reason you can't use === for your case since it looks to me like "matching" is really what you are going for?

That does seem more "proper" but in our case we'd like for our Status class to be able to transparently drop in in place of a string without actually needing to be too aware that it has some additional functionality under the hood. If we use === instead, we end up trying == by default, wonder why it's not doing what we expect, then remember, oh yeah, it's actually this Status object and I have to use that infrequently seen === operator for some reason.

That does seem more "proper" but in our case we'd like for our Status class to be able to transparently drop in in place of a string without actually needing to be too aware that it has some additional functionality under the hood...we end up trying == by default, wonder why it's not doing what we expect, then remember, oh yeah, it's actually this Status object

I would think in this case it would be important for them to be symmetric. For exactly the case you mention. It would be easy to have an actual string stored in a variable in some other part of the code, then do something like: display_status == status where status is a Status; which would fail. You would have to explicitly know that status wasn't actually a string and be sure you always do status == any_other_variable.

Another example which would be surprising without symmetry:
Status = Struct.new(:name) do
  def ==(other)
    other.respond_to?(:name) ? name == other.name : name == other
  end
end

status = 'foo'
case status
when 'foo'
  :equal
else
  :nope
end
# => :equal

status = Status.new('foo')
status == 'foo'
# => true

case status
when 'foo'
  'equal'
else
  'nope'
end
# => :nope

True, though those aren't the sorts of use-cases we're likely to come across. It's unlikely we're going to have a status string in a variable, and semantically it seems like status is always going to come first in equality operations. If it becomes a necessity, though, we can always monkey patch String at the time.
For case equality we can still define the === operator and have it work transparently. There's nothing keeping us from having both interfaces work transparently, but again, that's something we can address when it comes up, which may never happen. We're more likely to use a map, which will require converting to a string or symbol either way.

Unfortunately, case equality won't work transparently :crying_cat_face:. While the default implementation of === for most objects is ==, Ruby treats case statements as case_match === obj not obj === case_match. So even implementing a custom Status#=== won't make it work, as the expression will be 'test' === status:
status = Status.new('test')
status === 'test'
# => true

'test' === status
# => false

case status
when 'test'
  :match
else
  :nope
end
# => :nope

You know your code base and usage the best. Speaking from my own experience, non-symmetric equality with core types can lead to lots of unexpected pain later. I pointed out the case-statement issue simply because it has been a problem for me, as it's my default pattern for cleaning up several if, elsif, statements.
I know having to write your own custom matcher for this case is frustrating. Personally I think it could help convey the non-symmetric properties of the object:
RSpec::Matchers.define :represent do |expected|
  match do |actual|
    actual == expected
  end
end

Personally I think it could help convey the non-symmetric properties of the object

Yeah, the problem in our case is that we're trying to test the change in status:
expect {
  # do something
}.to change(object.status).from('viewed').to('submitted')

Composable matchers have got your back:
RSpec::Matchers.define :an_object_representing do |expected|
  match do |actual|
    actual == expected
  end
end

expect {
  # do something
}.to change(object.status).from(an_object_representing 'viewed').to(an_object_representing 'submitted')

That seems like a lot of workaround. I think we'll just monkey patch String for now. We also got bit by the DelegateClass issue above. We have a FieldDecorator class that gets used in one context and when stubbing:
allow(obj).to receive(:my_method)
obj.do_something
expect(obj).to have_received(:my_method).with(my_field)
# fails because it actually got called with a decorator

We end up having to patch this up in the FieldDecorator for the sake of the tests even though it's not something that is likely to ever come up in our code.

I ended up resolving it by adding delegate :instance_of?, to: :__getobj__ to FieldDecorator.


Remove netstandard2.0 outputs and PackageReferences.

With 2.1 out of support, there's little reason to keep the netstandard build outputs. Removing these simplifies the necessary assembly references in the Options and WebApi projects.
closes #1270

/backport to release/6.0


RG9uJ3QgY3JlYXRlIFN0cmF0ZWdpc3Qgd2hlbiBub3QgdXNlZnVsLg==

Pull request summary
Description:
VGhlIFN0cmF0ZWdpc3QgaXMgb25seSB1c2VkIHdoZW4gbW9kZSBpcyBBdXRvbWF0aWMu
Added:

None

Changed:

None

Removed:

None

Fixed:

None

Testing checklist:

[x] Changes are backward-compatible OR version migration code is included
[x] Codebase compiles with current tsconfig configuration
[x] Tested changes on {choose PUBLIC/PRIVATE} server OR changes are trivial (e.g. typos)

I can't backward-merge this, but congrats on cracking the obfuscation 😛

I only ever expected the fix to get included. Merging this commit was never on the table (though it would be harmless, overall).


Implement support for dockerignore and containerignore

Currently repo2docker creates a context object that includes the whole content of the repository it builds an image for. Thus it includes folders like .git which is usually something that has no interest in the final image, can take quite a lot of space and most importantly, kills the caching of that layer.
This patch adds support for reading dockerignore and containerignore files that are used to ensure only the relevant data are used to build the image.
By default it also excludes the .git folder if neither of these files are provided.
It makes use of docker-py's own file discovery mechanism to ensure coherence and avoid re-inventing a working wheel.
Note: containerignore comes from podman that reads either file. See the podman-build documentation.
Fixes #937
Related to #268 and #269 final discussions.

I just thought about something to discuss based on the default "ignore .git" behaviour introduced by this patch.
Since the goal of repo2docker is to provide a ready to use work environment with only the relevant pieces from a repo, should we have a configurable list of paths that we could ignore by default so people don't need to introduce another configuration file ?
I am currently mainly thinking of git and forge specific files and folders like .github, .gitlab-ci.yml, etc.

@manics I follow you on the reproducibility side but I thought that the following labels were there for that:
LABEL repo2docker.ref="<commit hash>"
LABEL<EMAIL_ADDRESS>LABEL repo2docker.version="2022.10.0"

?
I just saw that repo2docker.ref could contain HEAD which does not provide a useful information for reproducibility. The information would only be retrievable if one I explicitly runs the image to go into the git clone or based on the image generated name. May I suggest that HEAD should be replaced by the corresponding hash at image build time ?
In case we keep the .git folder by default, what are you thinking about my suggestion of a new argument that can be used with a list of files/folders to ignore ?

I rebased this PR by mistake, sorry for the noise!

@consideRatio no worries !
On that matter, something I am unsure of, it it globally preferred to rebase or to merge main back to the branch ? I am used to do the former to have a "semi-linear" history as they say in GitLab's configuration. I thought I have read something about it in the contributor documentation but I can't find it anymore.

On that matter, something I am unsure of, it it globally preferred to rebase or to merge main back to the branch ?

There is clear no consensus, but I think of two situations. When a PR is accepted an merged/rebased/squashed, and how to handle PR development before that.

We almost always use the merge button when merging PRs in jupyterhub org to retain commit authorship as I understand it.
I appreciate rebasing my PRs before merging them to have an easier to follow git history, but I dislike if rebasing makes a reviewer uncertain what is already reviewed once and what are new changes etc. Due to this, I'm often rebasing PRs before review efforts are put in, but not after.

Thanks @consideRatio, sounds good to me.
I haven't yet had a really big review on GitHub were I could see that rebasing did break the process for reviewers. Some times I have encountered policies that would be "we use merge from main" when updating a pull request but that is all. If it could help shape a consensus for the Jupyter project, we can use one of my contribution to do some testing in that regard.

@manics a small ping to get your opinion an my reproducibility related questions above as well as .git handling.

Having re-read #269, the ignore .git by default would be "out of spec" with regard to what docker does so I will remove it.
I'll open tickets for the other points as they are not directly related to this patch.


Something broke in help.py

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/discord/ext/commands/core.py", line 85, in wrapped
    ret = await coro(*args, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/discord/ext/commands/help.py", line 848, in command_callback
    return await self.send_bot_help(mapping)
  File "/usr/src/app/src/help.py", line 81, in send_bot_help
    help_commands_text=get_help_commands_text(self.context.bot),
  File "/usr/src/app/src/help.py", line 42, in get_help_commands_text
    text += cmd_help_text(bot, cmd)
  File "/usr/src/app/src/help.py", line 34, in cmd_help_text
    help_brief = bot.all_commands[cmd].help.split('\n')[0]
AttributeError: 'NoneType' object has no attribute 'split'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/discord/ext/commands/bot.py", line 939, in invoke
    await ctx.command.invoke(ctx)
  File "/usr/local/lib/python3.8/site-packages/discord/ext/commands/core.py", line 863, in invoke
    await injected(*ctx.args, **ctx.kwargs)
  File "/usr/local/lib/python3.8/site-packages/discord/ext/commands/core.py", line 94, in wrapped
    raise CommandInvokeError(exc) from exc
discord.ext.commands.errors.CommandInvokeError: Command raised an exception: AttributeError: 'NoneType' object has no attribute 'split'```

Looks like this was accidentally introduced in 570c2de718dd16c79eb80b359df94f480be5d13b.


Server bundle included in monorepo packages

What version of Remix are you using?
1.16.x
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce

Clone: https://github.com/paul-vd/remix-monorepo-server-bundle-reproduction
Install using pnpm
cd into skeleton folder (cd skeleton)
Run the application pnpm run dev

The code the reference is in /skeleton/app/routes/_index.tsx
Expected Behavior
The import { acme as AcmeA } from "@acme/package-a" should be removed from the client bundle, as it does for import { test as TestA } from "~/acme-test";
Actual Behavior
It is included in the client bundle.
Example
https://remix-monorepo-server-bundle-reproduction-skeleton.vercel.app/

Just bumping this up, as it's a long standing question I've never really had a solid answer to.
Exact same situation:
i'm running a Monorepo with a global server package @myapp/serverOnly
To use it in Remix we have to do the obvious serverOnly.server.ts with:
export * from '@myapp/serverOnly
But even with that bandaid VSCode will almost ALWAYS prioritise the package import when you aren't looking, and without any warnings / issues 🙄
Is there a solution to excluding a package from the client bundle directly? serverDependenciesToBundle was meant to be it I thought but it doesn't seem to work.

Is there a solution to excluding a package from the client bundle directly? serverDependenciesToBundle was meant to be it I thought but it doesn't seem to work.

Another issue would be with packages/dependencies which have a mix of client/server code, in which case serverDependenciesToBundle would not have helped. This is ilistrated in my reproduction repo, where the .server in the import method should be used to strip it from the client, but it does not.

Duplicate of #6711


Loader issue: Error in *.styl

As webpack.config is not accessible, I'm having an obvious issue with my *.styl files:
Module parse failed: *.styl Unexpected character '@' (1:0)
You may need an appropriate loader to handle this file type.
I need to include the following syntax in my webpack.config file:
module: {
loaders: [
{
test: /\.styl$/,
include: path.join(__dirname, 'src'),
loader: 'style-loader!css-loader!stylus-loader'
}
]
}
How do I resolve this issue?

Currently there is no built-in support for CSS preprocessors.
If you want to use one, use its CLI to compile it down to CSS, and import that CSS.
Here is how to use stylus CLI:
https://github.com/stylus/stylus#basic-usage

@gaearon Thanks, Dan! That worked a treat.


Style sign petition

@otlaitil and @alexander-bobin pair
You can ignore the commit bfc268c
https://www.pivotaltracker.com/story/show/95656562

Other than the comments I've posted, LGTM


Pull test script into repository

On the Website, you make a test script available so prospective users can check that securimage will work in their environment. Unfortunately, it does not appear to be anywhere in this repository! This makes it somewhat difficult to offer enhancements.

At this point I do not want to add the test script to the repo by default as not to leave it out in the world in any future installs. While there isn't much harm I'd rather not have the script be present when most may not use it.
For reference, the was the latest version kept by the internet archive can be found at https://web.archive.org/web/20170625003810/https://www.phpcaptcha.org/downloads/securimage_test.php if it becomes unavailable in the future. And noted that the test script isn't completely valid for the nextgen/4.0 branch.
Thank you!


Publish App to F-Droid (Free Open Source App Store)

Please do it! It's missing and me and all other google free people can't install this (probably) great app!

https://f-droid.org/
To request a new app be added, submit a “Request For Packaging” on the rfp tracker: https://gitlab.com/fdroid/rfp/issues/new

Meanwhile the app itself (as .apk) could also be released here (github) in the release section! :+1:

Nice! Ticket #222 :1st_place_medal:

https://f-droid.org/packages/de.stephanlindauer.criticalmaps/ ;-)

That was quick! :+1:


README document

Create a readme document at root of repo to play the game. I am thinking of making a github release with different arch builds so that users can use curl to install the program as a single binary using Robs build tool https://github.com/rwxrob/good.
For now, I can point the install steps using go install.

Done


Add files via upload

Hey, I'm guessing you weren't actually trying to do a pull request. If you were attempting to sync your fork with mine, take a look at the "Pulling updates" section of the Git notebook.

Yes. I’m sorry but thanks a lot!
Regards,
LAU Tsz Kit (Tim)
From: Kevin Liang
Sent: Tuesday, 1 August 2017 3:26 PM
To: kevinjliang/Duke-Tsinghua-MLSS-2017
Cc: Tim Lau; Author
Subject: Re: [kevinjliang/Duke-Tsinghua-MLSS-2017] Add files via upload (#2)
Hey, I'm guessing you weren't actually trying to do a pull request. If you were attempting to sync your fork with mine, take a look at the "Pulling updates" section of the Git notebook.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Refactor legacy codebase

Hi,
I have a legacy app I want to refactor using aider. Since the files are quite large, I keep hitting rate limits. What's a good approach to make the context a bit shorter with large files >= 1K loc.

Thanks for trying aider and filing this issue.
Can you be more specific about what you mean by "hitting rate limits"? Maybe paste the error output or a screenshot of the error?
There's a FAQ entry that might contain helpful information:
https://aider.chat/docs/faq.html#how-can-i-add-all-the-files-to-the-chat

@paul-gauthier thanks for the feedback. What happened was gpt-4 token limit reached. I was to got it to work by switching to gpt-3.5-turbo.

I'm going to close this issue for now, but feel free to add a comment here and I will re-open or file a new issue any time.


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v3.3 to before v5.4.125",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d646960f7986fefb460a2b062d5ccc8ccfeacc3a",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5d4c4b06ed9fb7a69d0b2e2a73fc73226d25ab70"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "d646960f7986fefb460a2b062d5ccc8ccfeacc3a",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "5d4c4b06ed9fb7a69d0b2e2a73fc73226d25ab70",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.4.125 by commit 5d4c4b06ed9fb7a69d0b2e2a73fc73226d25ab70, it was introduced in version v3.3 by commit d646960f7986fefb460a2b062d5ccc8ccfeacc3a. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1000754


incus : Added openvswitch integration to incus service

If it is to be used with openvswitch, Incus requires access to the openvswitch binaries in its path, and should be started after ovs-vswitchd.service
Description of changes
Two changes are made to the systemd service.

If virtualisation.vswitch is enabled, we will start incus after ovs-vswitchd.service
If virtualisation.vswitch is enabled, we will add virtualisation.vswitch.package to PATH

This resolves the path issues which prevent incus from deleting unnecessary virtual interfaces described here:
https://github.com/NixOS/nixpkgs/issues/290427
It also allows the test in this pull request to pass
https://github.com/NixOS/nixpkgs/pull/294819
Apologies in advance if anything was implemented incorrectly. They are simple changes so I hope they're fine.

Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Thanks! Would you be willing to write a nixosTest for the openvswitch and incus integration?

You can see the existing tests here: https://github.com/NixOS/nixpkgs/tree/master/nixos/tests/incus
the test should exercise the integration between the two to make sure incus is working with ovs and vice versa.
we’ll want a separate test for this, so we can add it as a test for the openvswitch package too.
Feel free to drop in #lxc:nixos.org on matrix if you need any assistance, or ask here.

You can see the existing tests here: https://github.com/NixOS/nixpkgs/tree/master/nixos/tests/incus
Run tests with nix-build -A nixosTests.incus.preseed for example.
the test should exercise the integration between the two to make sure incus is working with ovs and vice versa.
we’ll want a separate test for this, so we can add it as a test for the openvswitch package too.
Feel free to drop in #lxc:nixos.org on matrix if you need any assistance, or ask here.

I have looked over the tests. My initial idea would be to take the preseed test ( https://github.com/NixOS/nixpkgs/blob/master/nixos/tests/incus/preseed.nix ), but create the bridge using openvswitch. This should theoretically confirm that openvswitch integration is working, at least to the extent of creating a bridge which uses openvswitch. If openvswitch is not enabled, it should fail.
Is this kind of implementation what you're looking for?

Please see this pull request for the test:
https://github.com/NixOS/nixpkgs/pull/294819
I can confirm that it fails at present (incus can't find openvswitch binaries), but passes without issue with openvswitch in incus's path.

You can add the tests commit to this branch, or we can merge this and then you'll need to rebase that PR.

You can add the tests commit to this branch, or we can merge this and then you'll need to rebase that PR.

OK, I also added the tests to this branch. I will close the pull request for the tests.

You can also auto-close the issue if you use the github link format

The test file cannot be accessed currently, it will need to be added to nixos/tests/incus/default.nix similar to the other tests.
Please make sure you're testing the changes locally. This change does not currently eval.
It would be best if you could rebase and squash all these commits, including the fix below, into a single commit.

My apologies. I had things configured incorrectly when testing. Thank you for the fix.
I have tested everything, and rebased and squash as you requested.

This looks good, but unfortunately you'll need to make one more change. The commit message will need to be reworded to meet convention. https://github.com/NixOS/nixpkgs/blob/master/nixos/README.md#commit-conventions
Perhaps something like:

nixos/incus: add openvswitch integration and test

This looks good, but unfortunately you'll need to make one more change. The commit message will need to be reworded to meet convention. https://github.com/NixOS/nixpkgs/blob/master/nixos/README.md#commit-conventions
Perhaps something like:

nixos/incus: add openvswitch support

OK, it's fixed. Sorry I overlooked too many things in the process and waste much of your time. It was a good learning experience for me. Perhaps we are finally there?

Thanks for your contribution. :) It wasn't a waste in my opinion, and we all had to learn the details of packaging for nixpkgs to get here.

Looks like this PR introduced a regression for ZFS on nixpkgs-unstable. It currently errors out for me when I try to nixos-switch:
       error: A definition for option `systemd.services.incus.path."[definition 1-entry 1]"' is not of type `package or string'. Definition values:
       - In `/nix/store/xcadl56qxa44l2z40aabfsi1adlgn62y-source/nixos/modules/virtualisation/incus.nix':
           [
             <derivation zfs-user-2.2.3>
             "/nix/store/m2wcww4zhbkymywbihxgnp40adkmfm06-zfs-user-2.2.3/lib/udev"
           ]

Reverting this hunk seems to fix the issue:
diff --git i/nixos/modules/virtualisation/incus.nix w/nixos/modules/virtualisation/incus.nix
index 74217b2411ac..347cadd6a2e5 100644
--- i/nixos/modules/virtualisation/incus.nix
+++ w/nixos/modules/virtualisation/incus.nix
@@ -177,11 +177,10 @@ in
         "network-online.target"
       ];

-      path = lib.optional config.boot.zfs.enabled [
+      path = lib.mkIf config.boot.zfs.enabled [
         config.boot.zfs.package
         "${config.boot.zfs.package}/lib/udev"
-      ]
-        ++ lib.optional config.virtualisation.vswitch.enable config.virtualisation.vswitch.package;
+      ];

       environment = lib.mkMerge [ {
         # Override Path to the LXC template configuration directory

Oh, I figured it out. It should be lib.optionas, not lib.optional.


[Help wanted ] Installation  failed

Trying to install lumos but got error, maybe some dependencies are missing ?
yarn install v1.22.11
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[5/5] Building fresh packages...
[-/4] ⠠ waiting...
[-/4] ⠠ waiting...
[4/4] ⠠ @ckb-lumos/indexer
error /root/test/lumos/node_modules/@ckb-lumos/indexer: Command failed.
Exit code: 1
Command: node scripts/install_binary.js || npm run build-release
Arguments:
Directory: /root/test/lumos/node_modules/@ckb-lumos/indexer
Output:
node-pre-gyp args: install --fallback-to-build=false
node-pre-gyp info it worked if it ends with ok
node-pre-gyp info using<EMAIL_ADDRESS>node-pre-gyp info using<EMAIL_ADDRESS>| linux | x64
node-pre-gyp WARN Using request for node-pre-gyp https download
node-pre-gyp info check checked for "/root/test/lumos/packages/indexer/native/index.node" (not found)
node-pre-gyp http GET https://github.com/nervosnetwork/lumos/releases/download/v0.16.0/lumos-indexer-node-v93-linux-x64.tar.gz
node-pre-gyp http 404 https://github.com/nervosnetwork/lumos/releases/download/v0.16.0/lumos-indexer-node-v93-linux-x64.tar.gz
node-pre-gyp ERR! install error
node-pre-gyp ERR! stack Error: 404 status code downloading tarball https://github.com/nervosnetwork/lumos/releases/download/v0.16.0/lumos-indexer-node-v93-linux-x64.tar.gz
node-pre-gyp ERR! stack     at Request.<anonymous> (/root/test/lumos/node_modules/node-pre-gyp/lib/install.js:142:27)
node-pre-gyp ERR! stack     at Request.emit (node:events:406:35)
node-pre-gyp ERR! stack     at Request.onRequestResponse (/root/test/lumos/node_modules/request/request.js:1059:10)
node-pre-gyp ERR! stack     at ClientRequest.emit (node:events:394:28)
node-pre-gyp ERR! stack     at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:621:27)
node-pre-gyp ERR! stack     at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
node-pre-gyp ERR! stack     at TLSSocket.socketOnData (node:_http_client:487:22)
node-pre-gyp ERR! stack     at TLSSocket.emit (node:events:394:28)
node-pre-gyp ERR! stack     at addChunk (node:internal/streams/readable:312:12)
node-pre-gyp ERR! stack     at readableAddChunk (node:internal/streams/readable:287:9)
node-pre-gyp ERR! System Linux 4.15.0-88-generic
node-pre-gyp ERR! command "/usr/bin/node"<EMAIL_ADDRESS>"install" "--fallback-to-build=false"
node-pre-gyp ERR! cwd /root/test/lumos/packages/indexer
node-pre-gyp ERR! node -v v16.6.0
node-pre-gyp ERR! node-pre-gyp -v v0.14.0
node-pre-gyp ERR! not ok
404 status code downloading tarball https://github.com/nervosnetwork/lumos/releases/download/v0.16.0/lumos-indexer-node-v93-linux-x64.tar.gz
Exec error, code: 1, stderr:

><EMAIL_ADDRESS>build-release
> neon build --release

neon ERR! spawn cargo ENOENT

Error: spawn cargo ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:282:19)

Node.js 16 is not supported. Use Node.js 14 (LTS)


How to modify the dialog's style?

Excellent component.
How should I modify the dialog's style? For example, remove the icon from the card title bar and align the buttons to the right in the card actions bar.
Thanks.

Hi, sorry for delay i did not received notification 😅
You can make a custom component to show instead of my dialog component, please read README at this chapter : https://github.com/ThomasLeconte/vuetify3-dialog?tab=readme-ov-file#new-v140
Moreover, in cardOptions, you can set content of Vuetify's card slots programmatically. A little weird, but it's work !
If you have suggestions to improve library with your issue, don't hesitate to implement it !


Change AAD setting name prefix to AZURE

AZURE is used by ServicePrincipalCredential (and by extension DefaultAzureCredential) to locate application info in environment variables.

@SvenAelterman : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

I'm not sure I understand the problem that this PR is aiming to solve, as AAD is a commonly understood abbreviation of Azure Active Directory, whereas I feel that just using AZURE provides ambiguity as to the related service.

@aaronpowel The SDK team that develops the Azure.Identity SDK has the default providers that look for app registration credentials using AZURE_ as the prefix. So to avoid confusion between this example (which I understand doesn't use that SDK) and what the SDK is considering the default, I suggest modifying the example.
This is from personal experience with an app that started out life using AAD_ as the prefix and then being transitioned to the SDK.
PS: I don't disagree with your observation about AAD being common and well-understood.

@aaronpowel One more thing: the app I am working on is using the Identity SDK for the managed Functions and custom AAD auth for the SWA. So you wouldn't want to have to double up the same settings.

@SvenAelterman just so I'm making sure I'm on the same page, you're referring to https://azuresdkdocs.blob.core.windows.net/$web/dotnet/Azure.Identity/1.5.0/index.html as the SDK right?

@aaronpowell Yes, that's correct.

@aaronpowell Specifically, the behavior as documented here: https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/identity/Azure.Identity#environment-variables

#sign-off

@aaronpowell Thank you!


Does not work with Node v8

Broken dependency on require-dir within gulp-git, stack trace:
ypeError: require.extensions.hasOwnProperty is not a function
at requireDir (/Users/Kyle/Development/PactSafe/pactsafe-react-sdk/node_modules/require-dir/index.js:93:37)
at Object. (/Users/Kyle/Development/PactSafe/pactsafe-react-sdk/node_modules/gulp-git/index.js:4:18)
at Module._compile (module.js:569:30)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:503:32)
at tryModuleLoad (module.js:466:12)
at Function.Module._load (module.js:458:3)
at Module.require (module.js:513:17)
at require (internal/module.js:11:18)
at Object. (/Users/Kyle/Development/PactSafe/pactsafe-react-sdk/node_modules/react-component-gulp-tasks/tasks/release.js:1:73)

It seems there's an issue with node 8 and the require-dir module.
As a workaround you may to install the latest version of require-dir (0.3.2).

Got it working by npm i<EMAIL_ADDRESS>inside the node_modules/gulp-git folder


Non-hoisted styled-jsx dependency breaks styles

Bug report
Describe the bug
When styled-jsx with a version other than the one bundled with Next.js is manually added as a dependency to a Next.js project, style loading is delayed leading to an unstyled initial rendering flash.
To Reproduce
Reproduction in: https://github.com/ctavan/next.js-reproduce-styled-jsx-bug/commits/master
Adding styled-jsx as a dependency manually produces the buggy behavior: https://github.com/ctavan/next.js-reproduce-styled-jsx-bug/commit/489616fc9156ee9a089eb25f646e4ef10a037e36
Expected behavior
Adding styled-jsx as a dependency manually should either not produce the bug or lead to a build-time error/warning in Next.js (or it should be at least documented that you should not add another version than the bundled one of styled-jsx to a Next.js project).
Screenshots
Here's how the <head> looks like, when there is NO additional styled-jsx dependency. Note that the <style> tags are included before chunk/0.js is loaded in a blocking fashion:

Here's how the <head> looks like, when there is an additional styled-jsx dependency (different version than the one bundled with Next.js). Note that the <style> tags are included after chunk/0.js is loaded in a blocking fashion leading to html content flashing unstyled until chunk/0.js has been loaded:

System information

OS: macOS
Version of Next.js: 9.1.2

Adding a warning when someone tries to install styled-jsx themselves sounds reasonable to me.

@Timer any pointer of where and how this could be done? I'm happy to contribute.

We don't really have any prior art, so it's open for exploration. Maybe similar to how we check if minification was disabled.

I would probably hook into preinstall or postinstall depending if you want to throw an error ( pre-installation ) or warn ( post-installation ).
It does get complicated if you want to give a user a warning that references the correct package. For example, if styled-jsx was loaded as a child or peer dependency, you would want to warn the user with the parent, offending package that is in their package.json. From doing some work on yarn in the past, I can say this becomes complex quick unless you're handy with graphs and DFS.
An easier way might be to just check if the user's node_modules directory contains styled-jsx and then warn give an ambiguous warning, i.e. "It looks like one of your packages is using styled-jsx, which causes issues with Next.js."

Is there a way to import styled-jsx "through" next?
Most of my CSS is defined in separate files that get imported into the main component files, which kinda forces me to install my own version of styled-jsx in my package.json.
As described in this issue thread, this opens up the developer to package versioning issues between styled-jsx and next.

so  what can i do to fix this question


Update pokedex.ts

Elick, you copy-pasted Bulbasaur's egg groups for Tinkaton-Mega

I don't know what a pull request is


ModuleNotFoundError: No module named distutils

When running a script which is using the following libraries
import os
import sys
import json
import numpy as np
import pandas as pd
import logging
import tensorflow as tf
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from tensorflow import keras
from tensorflow.keras import layers

I get the following error: No module named distutils. The script runs fine from the command line or using Process Interop. Here is the Stack Trace:
  File "MyPythonScript.py", line 9, in <module>
    from tensorflow import keras

  File "C:\MyEnv\Lib\site-packages\tensorflow\__init__.py", line 30, in <module>
    import distutils as _distutils

and CSnakes Stack Trace:
  at CSnakes.Runtime.Python.PyObject..ctor(IntPtr pyObject, Boolean ownsHandle)
   at CSnakes.Runtime.Python.PyObject.Create(IntPtr ptr)
   at CSnakes.Runtime.CPython.CPythonAPI.Import(String name)
   at CSnakes.Runtime.Python.Import.ImportModule(String module)
   at CSnakes.Runtime.HousePriceNeuralNetworkExtensions.HousePriceNeuralNetworkInternal..ctor(ILogger`1 logger) in C:\...\obj\Debug\net8.0\CSnakes.SourceGeneration\CSnakes.PythonStaticGenerator\HousePriceNeuralNetwork.py.cs:line 49
   at CSnakes.Runtime.HousePriceNeuralNetworkExtensions.HousePriceNeuralNetwork(IPythonEnvironment env)

strange. Is is possible that this relates to https://github.com/tonybaloney/CSnakes/issues/302 ??


setContentOffset - need implementation

Fixed in https://github.com/nuno/TiCollectionView/pull/66/commits/49d48b36a05aab31232a64a0f5d43baf2b896936?diff=unified.


Careful Synthesis Progress Issue

Required Information
Class: LTW
Level: 48
Craftsmanship: 220
Control: 247
CP: 289
Recipe Name: Oxblood Targe
Recipe Level: 48
Solver Seed: (Look at the top of the Execution Log on the Solver page) 170301
Expected Behaviour
Careful Synthesis II returns a progress value of 57 (actual result in game)
Actual Behaviour
Optimizer calculates the progress value as 58, so the synthesis fails by 1 point. This happened on two separate iterations, both when I was unbuffed and when I was buffed with Matcha (HQ). (Stats above represent unbuffed ability.)
 You can try lowering the craftsmanship value a little until it generates a different sequence.
#267
Our modelling of the system is not 100% accurate unfortunately. I think you could try to compensate by lowering the value you enter for craftsmanship.

We have a new set of formulas for progress and quality increase. These changes are available on the beta site (ffxiv-beta.lokyst.net). Please let me know if these discrepancies are resolved.


Option to exclude bycatch fleets from the annual_F

This suggestion came up during a discussion with SEFSC. Some models include red tide as a fleet, but in some cases, it could be helpful to not include them in the benchmarks.
(@Rick-Methot-NOAA , please feel free to edit the comment/title of this issue if I did not capture it well!)

random notes on what this will take:
What this will take:

YPR_mask(f) is created in readdata using:

      if(bycatch_setup(f,2)==2)  //  omit bycatch fleet catch from YPR optimize

      { YPR_mask(f)=0;   }

-- So need to use this to exclude from annual_F and annual_catch also, or create new option by creating bycatch_setup(f,2)==3 to extend the exclusion and maintain backward compatibility.

note that it cannot work if using Z-M method to get F, that is without a lot of added code to exclude bycatch fleets from that Z.
easy to add exclusion of bycatch fleet if doing sum of Hrate
use exclusion when accumulating annual_catch(y) so that exploitation rate also will be as desired
in equil_calcs, looks like YPR_mask(f) is the tool to use.
-in equil_calc,  apply exclusion when calculation equ_F_std.  YPR_opt is already using YPR_mask (which was the target usage).  But equ_F_std was still using YPR_dead to report exploitation rate.  So bycatch could be excluded from the search for a target F, but the reported F was including bycatch.
in forecast code, F_std is calculated directly rather than using annual_F(y,1) as intermediary.

in forecast, this code is within the season loop, so the initialize to 0.0 seems wrong:
if((Fcast_Loop1==2 || Fcast_Loop_Control(1)==1) && ABC_Loop==1)  // get variance in OFL
{
Mgmt_quant(Fcast_catch_start+N_Fcast_Yrs+y-endyr)=0.;
for (f=1;f<=Nfleet;f++)
{
if(fleet_type(f)==1)
{Mgmt_quant(Fcast_catch_start+N_Fcast_Yrs+y-endyr)+=catch_fleet(t,f,2);}
else if (fleet_type(f)==3)
{}  //  survey
else if(bycatch_setup(f,2)==1) //  bycatch
{Mgmt_quant(Fcast_catch_start+N_Fcast_Yrs+y-endyr)+=catch_fleet(t,f,2);}
}
}

The solution outlined above was investigated and a branch created.  However, the code changes necessary in FORECAST were complex and would need much testing.  Nevertheless, this branch may have some useful code changes to compare and consider.
The alternative approach that was taken and completed was to implement git issue #45 such that red tide effect on natural mortality can be done as a predator, which inherently removes it from any F output issues.
Closing this issue.


2 entries in launch_background.xml

Before I run this package, I already  tag in my launch_background.xml file.
After the run, I see 2 item in the file:

@htsnet can you provide more information to this issue?

Sorry @henriquearthur , I didn´t see your first comment.
Before I had used this plugin, I already have a ITEM tag, like this:
<item>         <bitmap             android:gravity="center"             android:src="@mipmap/ic_launcher" />     </item>
Then, I run the plugin and, inside the launch_background.xml I saw the first one and this other:
<item>         <bitmap android:gravity="center" android:src="@drawable/splash" />     </item>
When the app start, I saw a mess (2 images). Then I look for the issue and found this duplilcate entry.
It is not a big deal, I just remove the first one and everything is OK.

The item this package looks for is android:src="@drawable/splash" to check if a entry was already added. As you had a android:src="@mipmap/ic_launcher" item, the package did not detected it.
This is normal because even using the package you are free to customize launch_background.xml manually.

Sorry @henriquearthur , I didn´t see your first comment.
Before I had used this plugin, I already have a ITEM tag, like this:
<item> <bitmap android:gravity="center" android:src="@mipmap/ic_launcher" /> </item>
Then, I run the plugin and, inside the launch_background.xml I saw the first one and this other:
<item> <bitmap android:gravity="center" android:src="@drawable/splash" /> </item>
When the app start, I saw a mess (2 images). Then I look for the issue and found this duplilcate entry.
It is not a big deal, I just remove the first one and everything is OK.

This works for me, thanks


Add support for loading multiple imports per component (localization)

I'd like to see support for loading locale-specific i18n message files together with the actual view component. This would allow for route-splitted translation files which, as the view itself, are just loaded on demand e.g. for usage with IntlProvider by react-intl.
Conceptually it might look like:
const AboutView = createLazyComponent({
  load: (language) => {
    return [
      import("./views/About"),
      import("./views/About." + language + ".json")
    ]
  }
})

but int theory instead of an array we could also use an object/dict for being more specific:
const AboutView = createLazyComponent({
  load: (language) => {
    return {
      view: import("./views/About"),
      messages: import("./views/About." + language + ".json")
    }
  }
})

If there are messages it would probably be a good idea to use IntlProvider with the messages given for wrapping the dynamically loaded view. It might be also cool to use injectIntl for offering the intl API via props to the loaded view.
What do you think?

I tried implementing these requirements in style of your component in this file:
https://github.com/sebastian-software/edgestack/blob/master/src/api/common/createLazyComponent.js

Hey @swernerx
Thanks for this suggestion.
With the latest code parse I did a bit of renaming to help the API move towards supporting something like your request.
My initial idea is to allow an additional prop to be provided to an async component instance.  Specifically a render callback function.  The render callback would then receive the result of the render.  Something like:
const AboutView = createLazyComponent({
  resolve: (props) => {
    const { language } = props
    return Promise.all([
      import("./views/About"),
      import("./views/About." + language + ".json")
   ])
  }
})

<AboutView
  render={(resolved) => {
    const [ View, translations ] = resolved
    return <View translations={translations} />
  }}
/>

The props pass through to the resolver poses an interesting question though.  This would affect our caching.  We would have to cache a result per variation of prop.  Therefore we may need to consider adding an additional configuration value to asyncComponent called something like passThroughProps that would allow you define which props to pass to asyncComponent.  These props would then be used as keys in a cache map of sorts.
Thoughts?

Looks good.
I just figure it would be nicer from the API standpoint to use named parameters/fields instead of array indexes and destructing. In this case we can't use Promise.all() as this does not work for objects... but it would be nicer from the usage standpoint. We could just return an objet in resolve() with { view: xx, translations: xx } and let the promise handling being done inside of asyncComponent.
I wonder what's the benefit of making the pass-through config required? Why not just pass-through all props?

Perfect,
I want to try something like this
<Switch>
	<Route path="/section1" render={(props) => (
		<Layout store={this.context.store} {...props} />
	)} />
</Switch>

const Layout = asyncComponent({
    resolve: (props) => {
        return Promise.all([
            System.import('./LayoutAsync'),
            System.import('./../logic/section1')
        ]).then(function([component, module]) {
            injectReducer(props.store, {key: 'section1State', reducer: module.reducer});
            injectSagas(props.store, module.SagasList);
            return component;
        })
    }
});

interesting, a lot of people solving the same problem :)
I did a prototype here https://github.com/hoschi/react-async-component/tree/feature/render
Here is an example usage:
import React from 'react';
import GeneralIcon from 'place/GeneralIcon'
import { asyncComponent } from 'react-async-component';

export let config = {
    resolve: (props) => import( /* webpackChunkName: "dynamic-icons" */ `icons/${props.iconName}/iconDescription`),
    getModuleId: (props) => props.iconName,
    autoResolveES2015Default: false,
    render: (iconDescription, props) => <GeneralIcon {...props} iconDescription={ iconDescription } />,
};

export default asyncComponent(config);

This can be used to

apply module content to a generic component
bundling each file in a directory as its own bundle and decide at runtime by props which to show
loading one module which contain different parts of the app, like @djeeg showed

As my use case is a bit different, I create another ticket this or next week.

I created issue #44 for my use case


Resolve only platform dependencies when generating POM file

Motivation:
The final dependent versions for a POM file are determined by the resolution strategy of versionMapping. That resolution strategy is useful to update dependencies constrained by platform dependencies. However, resolving conflicting dependencies can cause versions not intended by developers to be set in published POM files.
For example, SLF4J 1.3.x version is used in Aremria for better compatibility. As Armeria uses the low version, users who can't upgrade the version will not suffer any problems. Other users who want to use SLF4J 2.x can just define the high version because Gradle picks a higher version when resolving conflicts.
I propose to disable the custom versionMapping and use the default strategy which publishes the versions that are defined by the build script author with the dependency declarations.
The downside of the default strategy is that the platform dependencies are not used. The missing dependencies in POM are manually resolved from each project's compileClasspath.resolvedConfiguration
Modifications:

Remove the custom versionMapping defined in java-publish.gradle
Resolve missing versions in dependencies from compileClasspath.resolvedConfiguration.resolvedArtifacts

Result:

POM dependencies now respect the versions defined in dependency declarations.

Please, update this with https://github.com/line/gradle-scripts/pull/170 😉


docs: split API into separate pages

@dammy001 I summon you! 👀

@sheremet-va please check. also, is there any opening for joining the docs team?

@sheremet-va please check. also, is there any opening for joining the docs team?

I don’t think we have a docs team, but you can ask in discord. Maybe we should create one, we do need better docs 😄

@sheremet-va please check. also, is there any opening for joining the docs team?

I don’t think we have a docs team, but you can ask in discord. Maybe we should create one, we do need better docs 😄

@sheremet-va please check. also, is there any opening for joining the docs team?

I don’t think we have a docs team, but you can ask in discord. Maybe we should create one, we do need better docs 😄

@antfu what do you think?


Resource Manipulators: add shell commands for debugging

New commands in "ogmmanipulate"-namespace:

listManipulators (Show all manipulators by their app id)
getControllers (Show all manipulator configurations; optionally restricted to a specific app or manipulator type)
lastManipulationTime (Print the last execution time of all manipulators or a specific one)


pylint reports E0401:import error for the mido library

pylint_bug.txt

Why does this website ask for trace files that are too long to paste into bug reports???????????????????????????

It looks like my venv was the problem.
Somehow, the packages I installed into the venv (yes, it was activated) were installed in the global python env.

Somehow, the packages I installed into the venv (yes, it was activated) were installed in the global python env.

This can happen if you run ‘pip install’ vs python -m pip install. See here for more details: https://snarky.ca/why-you-should-use-python-m-pip/

@karthiknadig I know about python -m pip install xxx
After I discovered the problem, I had tried adding packages to the venv, but they still went to the global python.
I have never had this problem with Python on Windows until now. I ended up deleting the venv, and Python, and reinstalling Python for all users, so that it doesn't get installed in my user directory (Appdata ....)
Now, the venv seems to work much better, and vscode is able to resolve most python symbols/objects now.