GIMP Plugin Updates and Fixes

Reorganize save dialog
Rename functions, modify messages
Use JxlEncoderSetBasicInfo
Use float as intermediary format
Fix float image alpha channels
Fix grayscale ICC profile loading
Fix distance/quality conversion

Thanks for working on this!
Some nitpicking remarks/suggestions, just looking at the screenshot:

It might be good to annotate the sliders to indicate what they mean, e.g. write something like "higher fidelity" on the left of the "Distance" slider and "lower fidelity" on the right, or "faster" - "slower" for the "Effort" slider.
It could also be a good idea, if possible, to draw some annotated 'ticks' on the slider to give further guidance, for example putting words like "excellent", "very good", "good", "fair", "poor" at points corresponding to, say, d0.3, d1, d2, d3, d6, or something like that. Photoshop does that for its jpeg export dialog, and I think it is useful since many users will not know what to expect from specific numeric values.
Perhaps "Effort" could be considered an advanced setting, and just having the default 7 for lossy and 3 for lossless is good enough in most cases? Keeping it simple by default is maybe better.
What does "Use Original Color Profile" mean? This is not clear to me. The color profile of the image should always be "used" in some way - but I suppose this refers to the corresponding API field, which I think is used to signal whether XYB can be used or not. I think this option should always be disabled when doing lossy, and always enabled when doing lossless (so I don't see a need to put it as an explicit option in the UI).

@jonsneyers Thank you for the feedback.

I would appreciate suggestions to improve the explanatory text in the tool tips.  They don't show up in screenshots, but can significantly affect users' ability to learn and use the interface.

The GIMP-scale-entry widget doesn't seem to have the annotation features you describe.  I'll look into what else is available for a future revision.

In the previous version, Lossless Mode and Effort were both in the Advanced section.  I moved Lossless Mode to the standard section because normal users can be expected to use it (when they might otherwise use PNG).  Since lossless affects the Distance, Quality, and Effort sliders, users could be confused if the settings were separated in the interface.  Users may also want to change Effort to match their computers' capabilities.
Maybe a different label would help, like "Encoding Speed" with values subtracted from 10?  Then "Faster Decoding" could be renamed to "Decoding Speed".  They wouldn't match the cjxl options anymore though.

"Use Original Color Profile" does refer to the similarly named API option.  This is an option I expect some photographers might require.  Perhaps it could be renamed something like "Do not use XYB".  I understand that XYB is supposed to be a major feature of JXL, but right now, it seems to hinder the use of color spaces other than sRGB (at least with the API).  It is in the Advanced section to discourage use unless users really feels it's needed.

@jonsneyers Thank you for the feedback.

I would appreciate suggestions to improve the explanatory text in the tool tips.  They don't show up in screenshots, but can significantly affect users' ability to learn and use the interface.
The GIMP-scale-entry widget doesn't seem to have the annotation features you describe.  I'll look into what else is available for a future revision.
In the previous version, Lossless Mode and Effort were both in the Advanced section.  I moved Lossless Mode to the standard section because normal users can be expected to use it (when they might otherwise use PNG).  Since lossless affects the Distance, Quality, and Effort sliders, users could be confused if the settings were separated in the interface.  Users may also want to change Effort to match their computers' capabilities.
Maybe a different label would help, like "Encoding Speed" with values subtracted from 10?  Then "Faster Decoding" could be renamed to "Decoding Speed".  They wouldn't match the cjxl options anymore though.

Just my 2c here: I don't think matching cjxl options is particularly important :)

"Use Original Color Profile" does refer to the similarly named API option.  This is an option I expect some photographers might require.  Perhaps it could be renamed something like "Do not use XYB".  I understand that XYB is supposed to be a major feature of JXL, but right now, it seems to hinder the use of color spaces other than sRGB (at least with the API).  It is in the Advanced section to discourage use unless users really feels it's needed.

"Use Original Color Profile" does refer to the similarly named API option.  This is an option I expect some photographers might require.  Perhaps it could be renamed something like "Do not use XYB".  I understand that XYB is supposed to be a major feature of JXL, but right now, it seems to hinder the use of color spaces other than sRGB (at least with the API).  It is in the Advanced section to discourage use unless users really feels it's needed.

Maybe something is going wrong then - XYB should work well with any color space, not just sRGB.
Ah but passing the input to the encoder has to be done in a color space that the encoder understands, I suppose.
@lvandeve @sboukortt do we (plan to) have an encode api for input with an arbitrary ICC profile, where the encoder does the necessary conversion? Like what cjxl does...

@jonsneyers  The ICC profile issues I'm having may just be how it's currently implemented.  As far as I can tell, the ICC profile isn't really used.  For instance, the roundtrip test had used junk data instead of a real ICC profile.  If the encoder used the ICC profile, I'd expect junk data would have failed the test.

@lvandeve @sboukortt do we (plan to) have an encode api for input with an arbitrary ICC profile, where the encoder does the necessary conversion? Like what cjxl does...

I don't think so, at least nothing more than the reverse of what the decoder can do without a CMS

@jonsneyers The ICC profile issues I'm having may just be how it's currently implemented. As far as I can tell, the ICC profile isn't really used. For instance, the roundtrip test had used junk data instead of a real ICC profile. If the encoder used the ICC profile, I'd expect junk data would have failed the test.

If I understand correctly, if you have uses_original_profile set to false, then the ICC profile will just be ignored by the encoder and the pixels will be assumed to be sRGB (if ints are used) or linear sRGB (if floats are used). It will store the bytes of the ICC profile in the file, but they're just a blob that is only informative and doesn't influence rendering. If you have uses_original_profile set to true, then the ICC profile will not be ignored by the encoder (to do the conversion to XYB).
So it should basically always be set to true, I think.
@lvandeve / @sboukortt can you comment? I don't really fully understand how the api works here...

@lvandeve @sboukortt do we (plan to) have an encode api for input with an arbitrary ICC profile, where the encoder does the necessary conversion? Like what cjxl does...

I don't think so, at least nothing more than the reverse of what the decoder can do without a CMS

So we really want (the full) libjxl not to depend on a CMS library?
For the decode library (libjxl_dec) I understand that we want to keep it minimal in terms of dependencies and binary size, but for the full library I don't think that's a big concern.
Anyway, does that mean that as it currently is, when doing lossy, the gimp encoder plugin would need to convert (whatever space the pixels are in) to linear sRGB floats, and call the encoder with uses_original_profile=false? And when doing lossless, it can pass the pixels directly and set uses_original_profile=true?

@lvandeve @sboukortt do we (plan to) have an encode api for input with an arbitrary ICC profile, where the encoder does the necessary conversion? Like what cjxl does...

I don't think so, at least nothing more than the reverse of what the decoder can do without a CMS

So we really want (the full) libjxl not to depend on a CMS library?
For the decode library (libjxl_dec) I understand that we want to keep it minimal in terms of dependencies and binary size, but for the full library I don't think that's a big concern.
Anyway, does that mean that as it currently is, when doing lossy, the gimp encoder plugin would need to convert (whatever space the pixels are in) to linear sRGB floats, and call the encoder with uses_original_profile=false? And when doing lossless, it can pass the pixels directly and set uses_original_profile=true?

If I understand correctly, the encoder API today has some limitations wrt colorspaces.
@xiota is it possible, today, to always pass pixels in linear floating point RGB(A) (asking GIMP to do a colorspace conversion if needed) if d != 0 and pass pixels in their original colorspace and pixel format if d == 0, also passing the ICC? In this case, I believe "Use original profile" wouldn't be needed, right?

@veluca93 I removed the commented lines you indicated. They were mostly placeholders or reminders to myself.  I recompiled and opened and saved a few files with the different settings.  So it should be ready to merge.

is it possible, today, to always pass pixels in linear floating point sRGB(A) (asking GIMP to do a colorspace conversion if needed) if d != 0 and pass pixels in their original colorspace and pixel format if d == 0, also passing the ICC? In this case, I believe "Use original profile" wouldn't be needed, right?

When you say "today", do you mean make the changes today, or whether it's possible with the current API?  I think it can most likely be done, but I need to look at what functions are available to me through GIMP.  I'd also like to test the behavior to see if it behaves the way I'd expect.  I still think photographers might still want to have the option to skip XYB because other programs might not do the colorspace conversions.  It also occurs to me that it might be useful to use lossless/d=0 with XYB.  There are minimal (predictable?) losses from the conversion to XYB and file sizes are cut in half.

@veluca93 I removed the commented lines you indicated. They were mostly placeholders or reminders to myself. I recompiled and opened and saved a few files with the different settings. So it should be ready to merge.

Sounds good - usually we go with "// TODO(xiota): some description here" for such reminders :)

is it possible, today, to always pass pixels in linear floating point sRGB(A) (asking GIMP to do a colorspace conversion if needed) if d != 0 and pass pixels in their original colorspace and pixel format if d == 0, also passing the ICC? In this case, I believe "Use original profile" wouldn't be needed, right?

When you say "today", do you mean make the changes today, or whether it's possible with the current API? I think it can most likely be done, but I need to look at what functions are available to me through GIMP. I'd also like to test the behavior to see if it behaves the way I'd expect. I still think photographers might still want to have the option to skip XYB because other programs might not do the colorspace conversions. It also occurs to me that it might be useful to use lossless/d=0 with XYB. There are minimal (predictable?) losses from the conversion to XYB and file sizes are cut in half.

It seems to me that with that modification, that flag would be used in rather niche situations (I understand the issue of other programs not doing the color conversion - IIRC we want to change things so that you'd get sRGB by default in that case, which would likely be "more correct" than whatever the original colorspace is, but now that's not the case AFAIU). Anyway, I'm OK with leaving the option there at least for now, and removing it later if it becomes redundant/extremely niche. @lvandeve @sboukortt any opinions here?

Why is "Enable Advanced Settings" below "Advanced Settings"? It would make more sense to have it above, WDYT?

@veluca93 @jonsneyers  When using XYB, the plugin now converts to sRGB float before encoding, then back to the original profile and pixel format after decoding.

@veluca93 @jonsneyers When using XYB, the plugin now converts to sRGB float before encoding, then back to the original profile and pixel format after decoding.

Please make sure it's converting to unclamped values, so wide gamut doesn't get clamped to the sRGB gamut. (E.g. take a ProPhoto or P3 image and check that you get negative values and values above 1.0f)

I don't know how to check for that.

I don't know how to check for that.

Easiest way is to take an image like this:
https://webkit.org/blog-files/color-gamut/Webkit-logo-P3.png
and see if you can still see the logo after a roundtrip through saving as jxl and loading.

@jonsneyers I removed the sRGB conversion because it ruins the image you sent.  It still sends data to the encoder as float.  Now ICC profiles appear to behave the way I've been trying to get them to.  I had reordered some things to accommodate the format and colorspace conversion, so it may be that when the color profile is set makes a difference.

I wonder if there's any benefit to converting an 8-bit image to jxl, but keeping it as float on import.

Shouldn't make any difference. As it is now, jxl uses float as an internal representation in any case (which is why it can only do lossless ints up to 24-bit: that's the maximum precision that can be converted between float and int losslessly). So if you give it a uint8 buffer, it will internally convert it to a float buffer and then start encoding, and if you give it a float buffer, it will just copy it tot an internal float buffer and then start encoding.

@jonsneyers I removed the sRGB conversion because it ruins the image you sent. It still sends data to the encoder as float. Now ICC profiles appear to behave the way I've been trying to get them to. I had reordered some things to accommodate the format and colorspace conversion, so it may be that when the color profile is set makes a difference.

Likely the sRGB conversion also clamped the result to the nominal range of [0,1], causing gamut clipping.

@jonsneyers looks like you did the review here. Is there any blocker here?

I wonder if there's any benefit to converting an 8-bit image to jxl, but keeping it as float on import.

Shouldn't make any difference. As it is now, jxl uses float as an internal representation in any case (which is why it can only do lossless ints up to 24-bit: that's the maximum precision that can be converted between float and int losslessly). So if you give it a uint8 buffer, it will internally convert it to a float buffer and then start encoding, and if you give it a float buffer, it will just copy it tot an internal float buffer and then start encoding.

I was referring to the decode side.  Instead of converting the jxl back into an 8-bit image, keep it as float.  Maybe there's some latitude in the encode/decode process that could be beneficial for editing.  For instance, if there's a gradient that's prone to banding in 8-bit, maybe it somehow gets smoothed out a bit after enc/dec if kept as float.

I wonder if there's any benefit to converting an 8-bit image to jxl, but keeping it as float on import.

Shouldn't make any difference. As it is now, jxl uses float as an internal representation in any case (which is why it can only do lossless ints up to 24-bit: that's the maximum precision that can be converted between float and int losslessly). So if you give it a uint8 buffer, it will internally convert it to a float buffer and then start encoding, and if you give it a float buffer, it will just copy it tot an internal float buffer and then start encoding.

I was referring to the decode side. Instead of converting the jxl back into an 8-bit image, keep it as float. Maybe there's some latitude in the encode/decode process that could be beneficial for editing. For instance, if there's a gradient that's prone to banding in 8-bit, maybe it somehow gets smoothed out a bit after enc/dec if kept as float.

Ah yes, when doing lossy compression of an 8-bit image, decoding it to higher bit depth or to float is beneficial, especially since we don't do any dithering yet in the decoder when it's quantizing things down to 8-bit.

@jonsneyers looks like you did the review here. Is there any blocker here?

I don't think so. @xiota can you do some final sanity checks to see that things work properly?

@jonsneyers  Sorry.  It's not quite ready yet.  Switching to sending data to the encoder as float was a big change that introduced some glitches I need to fix.

@jonsneyers  I'm getting a ../lib/jxl/enc_modular.cc:506: JXL_ASSERT: !fp with one particular image, but others are working fine.  It occurs with the float conversion turned off, so it's either not a new problem or it's a problem outside of the plugin.

@jonsneyers I'm getting a ../lib/jxl/enc_modular.cc:506: JXL_ASSERT: !fp with one particular image, but others are working fine. It occurs with the float conversion turned off, so it's either not a new problem or it's a problem outside of the plugin.

That's not a new problem and it is a problem outside of the plugin.  https://github.com/libjxl/libjxl/pull/562 should solve it.

That's not a new problem and it is a problem outside of the plugin.

Thanks.  The plugin is good for now then.


x/tools/gopls: nil Signature (?) deref in Completion

#!stacks
"runtime.sigpanic" && "go/types.(*Signature).Results:=94" && "expectedReturnStmtType"

Issue created by stacks.
// expectedReturnStmtType returns the expected type of a return statement.
// Returns nil if enclosingSig is nil.
func expectedReturnStmtType(enclosingSig *types.Signature, node *ast.ReturnStmt, pos token.Pos) types.Type {
	if enclosingSig != nil {
		if resultIdx := exprAtPos(pos, node.Results); resultIdx < len(node.Results) {
			return enclosingSig.Results().At(resultIdx).Type()
		}
	}
	return nil
}

This stack sZBuvA was reported by telemetry:

crash/crash
runtime.gopanic:+69
runtime.panicmem:=262
runtime.sigpanic:+19
go/types.(*Signature).Results:=94
golang.org/x/tools/gopls/internal/golang/completion.expectedReturnStmtType:+3
golang.org/x/tools/gopls/internal/golang/completion.expectedCandidate:+37
golang.org/x/tools/gopls/internal/golang/completion.Completion:+150
golang.org/x/tools/gopls/internal/server.(*server).Completion:+19
golang.org/x/tools/gopls/internal/protocol.serverDispatch:+193
golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.ServerHandler.func3:+5
golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.handshaker.func4:+52
golang.org/x/tools/gopls/internal/protocol.Handlers.MustReplyHandler.func1:+2
golang.org/x/tools/gopls/internal/protocol.Handlers.AsyncHandler.func2.2:+3
runtime.goexit:+0

<EMAIL_ADDRESS>go1.23.3 darwin/arm64 other,vscode (10)

Dups: mCLZHw

Related Issues

x/tools/gopls: crash in Hover (telemetry) #69362
x/tools/gopls: automated issue report (crash) - unhandled basic type #40956 (closed)
x/tools/gopls: SignatureHelp bug reported by telemetry [_mSPWg] #64234 (closed)
x/tools/gopls: out-of-bounds index in "stub methods" code action #64087 (closed)
x/tools/gopls: crash during SignatureHelp #40230 (closed)
x/tools/gopls: SignatureHelp bug reported by telemetry #64245 (closed)
x/tools/gopls: panic in completion.enclosingFunction #49397 (closed)
x/tools/gopls: analysisinternal.ZeroValue crash on (presumably) unsafe.Pointer #70585 (closed)
x/tools/gopls: panic in deslice when completing unknown type in append #38091 (closed)
x/tools/gopls: Hover: panic in lookupObjectByName #69616

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

This is a strange one: the nil deref is dominated by a non-nil check.

This stack mCLZHw was reported by telemetry:

crash/crash
runtime.gopanic:+69
runtime.panicmem:=262
runtime.sigpanic:+9
go/types.(*Signature).Results:=94
golang.org/x/tools/gopls/internal/golang/completion.expectedReturnStmtType:+3
golang.org/x/tools/gopls/internal/golang/completion.expectedCandidate:+37
golang.org/x/tools/gopls/internal/golang/completion.Completion:+150
golang.org/x/tools/gopls/internal/server.(*server).Completion:+19
golang.org/x/tools/gopls/internal/protocol.serverDispatch:+193
golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.ServerHandler.func3:+5
golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.handshaker.func4:+52
golang.org/x/tools/gopls/internal/protocol.Handlers.MustReplyHandler.func1:+2
golang.org/x/tools/gopls/internal/protocol.Handlers.AsyncHandler.func2.2:+3
runtime.goexit:+0

<EMAIL_ADDRESS>go1.23.1 windows/amd64 vscode (2)

Closely related to https://github.com/golang/go/issues/70636.

There's definitely a bug here though. The condition checked is against len(node.Results), but in the presence of ill typed code, the signature length need not match the length of the return statement.
if resultIdx := exprAtPos(pos, node.Results); resultIdx < len(node.Results) {
    return enclosingSig.Results().At(resultIdx).Type()
}

My guess is that the compiler is somehow reporting the panic from the wrong call.

Aha, well the bug I spotted is exactly #70636.
Therefore, I'm not sure what this bug is. If it were a bug in the compiler's pclntab, I'd have expected it to always report the wrong function.

For triaging: we expect that this is really a dupe of #70636, somehow obscured by a misreported stack from the compiler. I'll leave this in the v0.17.0 milestone, but if it does not recur in the next prerelease, where #70636 is fixed, I think we can safely transfer this to a compiler/runtime bug.

FWIW, I can reproduce this exact crash with<EMAIL_ADDRESS>and the repro from my fix for #70636. Therefore, this is a dupe.

https://go.dev/cl/634038 is a reproducer for the problem that doesn't depend on telemetry.


Add a TripPlan application Readme

Summary of changes
Asana Ticket: 🎫 Investigate | Elixir/OTP Boundaries
Add a TripPlan application Readme.
Include information on how we use OpenTripPlanner.

Before getting review, please check the following:

[x] Does frontend functionality render and work correctly in IE?
[x] Have we load-tested any new pages or internal API endpoints that will receive significant traffic?
[x] Are interactive elements accessible to screen readers?
[x] Have you checked for tech debt you can address in the area you're working in?
[x] If this change involves routes, does it work correctly with pertinent "unusual" routes such as the combined Green Line, Silver Line, Foxboro commuter rail, and single-direction bus routes like the 170?
[x] Are the changes organized into self-contained commits with descriptive and well-formatted commit messages?

@alicia-mbta Please let me know if you have any suggestions for this, or if there are any other pieces you think it would be helpful to describe.
@thecristen and @paulswartz, tagging you in case you have suggestions as well.


Update Android WebView to handle garbage collection automatically

Action Items:

[x] Add Copyable class from iOS implementation.
[x] Update Dart InstanceManager with Finalizer support.
[x] Update Java InstanceManager with support for tracking garbage collected objects.
[x] Add dispose pigeon methods for HostApi and FlutterApi.
[x] Replace callback methods with anonymous functions.

This is now finished


dephell deps convert --envs=main includes dev dependencies (poetry.lock)

I try to convert locked dependencies from Poetry to requirements.txt, to later build a PEX file with only the production dependencies.
When running dephell deps convert --from=poetry.lock --to=requirements.txt --envs=main the resulting file contains all dependencies including dev ones.
I already looked at #137 which pointed me towards the --envs parameter, but it doesn't seem to work how I imagined.
Steps to reproduce:
Using dephell==0.7.7

Initialize a Poetry project (poetry init -n)
Add prod & dev dependencies (poetry add requests, poetry add -D pytest)
Convert dependencies, skipping dev dependencies (dephell deps convert --from=poetry.lock --to=requirements.txt --envs=main)

Expected result:

certifi==2019.9.11
chardet==3.0.4
idna==2.8; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
requests==2.22.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version != "3.4.*" and python_version >= "2.7"
urllib3==1.25.6; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7" and python_version < "4"

Actual result:

atomicwrites==1.3.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
attrs==19.2.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
certifi==2019.9.11
chardet==3.0.4
colorama==0.4.1; sys_platform == "win32" and python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
idna==2.8; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
importlib-metadata==0.23; python_version < "3.8" and python_version >= "2.7" and python_version != "3.0" and python_version != "3.1" and python_version != "3.2" and python_version != "3.3"
more-itertools==7.2.0; python_version >= "3.4"
packaging==19.2; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
pluggy==0.13.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
py==1.8.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
pyparsing==2.4.2; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version >= "2.6"
pytest==5.2.1; python_version >= "3.5"
requests==2.22.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version != "3.4.*" and python_version >= "2.7"
six==1.12.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version >= "2.6"
urllib3==1.25.6; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7" and python_version < "4"
wcwidth==0.1.7
zipp==0.6.0; python_version < "3.8" and python_version >= "2.7"

Hmm, can't reproduce.
pyproject.toml:
[tool.poetry]
name = "tmp"
version = "0.1.0"
description = ""
authors = ["Gram<EMAIL_ADDRESS>
[tool.poetry.dependencies]
python = "^3.6"
requests = "*"

[tool.poetry.dev-dependencies]
pytest = "*"

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

Resulting requirements.txt:
certifi==2019.9.11
chardet==3.0.4
idna==2.8; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
requests==2.22.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version != "3.4.*" and python_version >= "2.7"
urllib3==1.25.6; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7" and python_version < "4"

Possible causes of differences:

I'm using DepHell 0.7.8, and this bug was fixed in the latest release.
Your pyproject.toml is different.

Could you check it again on the latest version and provide generated pyproject.toml, please?

I retried with dephell 0.7.8 installed through the recommended method (curl | python).
My pyproject.toml:
[tool.poetry]
name = "tmp.nxehdzkkmi"
version = "0.1.0"
description = ""
authors = ["Thomas Gaudin<EMAIL_ADDRESS>
[tool.poetry.dependencies]
python = "^3.7"
requests = "^2.22"

[tool.poetry.dev-dependencies]
pytest = "^5.2"

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

When I run dephell deps convert --from=poetry.lock --to=requirements.txt --envs=main, requirements.txt:
atomicwrites==1.3.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
attrs==19.3.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
certifi==2019.9.11
chardet==3.0.4
colorama==0.4.1; sys_platform == "win32" and python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
idna==2.8; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
importlib-metadata==0.23; python_version < "3.8" and python_version >= "2.7" and python_version != "3.0" and python_version != "3.1" and python_version != "3.2" and python_version != "3.3"
more-itertools==7.2.0; python_version >= "3.4"
packaging==19.2; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
pluggy==0.13.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
py==1.8.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7"
pyparsing==2.4.2; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version >= "2.6"
pytest==5.2.2; python_version >= "3.5"
requests==2.22.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version != "3.4.*" and python_version >= "2.7"
six==1.12.0; python_version != "3.0.*" and python_version != "3.1.*" and python_version >= "2.6"
urllib3==1.25.6; python_version != "3.0.*" and python_version != "3.1.*" and python_version != "3.2.*" and python_version != "3.3.*" and python_version >= "2.7" and python_version < "4"
wcwidth==0.1.7
zipp==0.6.0; python_version < "3.8" and python_version >= "2.7"

When I run dephell deps convert --from=pyproject.toml --to=requirements.txt --envs=main, requirements.txt:
pytest==5.*,>=5.2.0
requests==2.*,>=2.22.0

When I run dephell deps convert --from=pyproject.toml --to=requirements.lock --envs=main, requirements.lock:
configparser==4.0.2; python_version < "3" \
  --hash sha256:254c1d9c79f60c45dfde850850883d5aaa7f19a23f13561243a050d5a7c3fe4c \
  --hash sha256:c7d282687a5308319bf3d2e7706e575c635b0a470342641c93bea0ea3b5331df \
  # ^ from importlib-metadata
contextlib2==0.6.0.post1; python_version < "3" \
  --hash sha256:01f490098c18b19d2bd5bb5dc445b2054d2fa97f09a4280ba2c5f3c394c8162e \
  --hash sha256:3355078a159fbb44ee60ea80abd0d87b80b78c248643b49aa6d94673b413609b \
  # ^ from importlib-metadata
pyparsing==2.4.2 \
  --hash sha256:6f98a7b9397e206d78cc01df10131398f1c8b8510a2f4d97d9abd82e1aacdd80 \
  --hash sha256:d9338df12903bbf5d65a0e4e87c2161968b10d2e489652bb47001d82a9b028b4 \
  # ^ from packaging
scandir==1.10.0; python_version < "3.5" \
  --hash sha256:2586c94e907d99617887daed6c1d102b5ca28f1085f90446554abf1faf73123e \
  --hash sha256:2ae41f43797ca0c11591c0c35f2f5875fa99f8797cb1a1fd440497ec0ae4b022 \
  --hash sha256:2b8e3888b11abb2217a32af0766bc06b65cc4a928d8727828ee68af5a967fa6f \
  --hash sha256:2c712840c2e2ee8dfaf36034080108d30060d759c7b73a01a52251cc8989f11f \
  --hash sha256:4d4631f6062e658e9007ab3149a9b914f3548cb38bfb021c64f39a025ce578ae \
  --hash sha256:67f15b6f83e6507fdc6fca22fedf6ef8b334b399ca27c6b568cbfaa82a364173 \
  --hash sha256:7d2d7a06a252764061a020407b997dd036f7bd6a175a5ba2b345f0a357f0b3f4 \
  --hash sha256:8c5922863e44ffc00c5c693190648daa6d15e7c1207ed02d6f46a8dcc2869d32 \
  --hash sha256:92c85ac42f41ffdc35b6da57ed991575bdbe69db895507af88b9f499b701c188 \
  --hash sha256:b24086f2375c4a094a6b51e78b4cf7ca16c721dcee2eddd7aa6494b42d6d519d \
  --hash sha256:cb925555f43060a1745d0a321cca94bcea927c50114b623d73179189a4e100ac \
  # ^ from pathlib2
six==1.12.0 \
  --hash sha256:3350809f0555b11f552448330d0b52d5f24c91a322ea4a15ef22629740f3761c \
  --hash sha256:d16a0141ec1a18405cd4ce8b4613101da75da0e9a7aec5bdd4fa804d0e0eba73 \
  # ^ from packaging, pathlib2
zipp==0.6.0 \
  --hash sha256:3718b1cbcd963c7d4c5511a8240812904164b7f381b647143a89d3b98f9bcd8e \
  --hash sha256:f06903e9f1f43b12d371004b4ac7b06ab39a44adc747266928ae6debfa7b3335 \
  # ^ from importlib-metadata
atomicwrites==1.3.0 \
  --hash sha256:03472c30eb2c5d1ba9227e4c2ca66ab8287fbfbbda3888aa93dc2e28fc6811b4 \
  --hash sha256:75a9445bac02d8d058d5e1fe689654ba5a6556a1dfd8ce6ec55a0ed79866cfa6 \
  # ^ from pytest
attrs==19.3.0 \
  --hash sha256:08a96c641c3a74e44eb59afb61a24f2cb9f4d7188748e76ba4bb5edfa3cb7d1c \
  --hash sha256:f7b7ce16570fe9965acd6d30101a28f62fb4a7f9e926b3bbc9b61f8b04247e72 \
  # ^ from pytest
certifi==2019.9.11 \
  --hash sha256:e4f3620cfea4f83eedc95b24abd9cd56f3c4b146dd0177e83a21b4eb49e21e50 \
  --hash sha256:fd7c7c74727ddcf00e9acd26bba8da604ffec95bf1c2144e67aff7a8b50e6cef \
  # ^ from requests
chardet==3.0.4 \
  --hash sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae \
  --hash sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691 \
  # ^ from requests
colorama==0.4.1; sys_platform == "win32" \
  --hash sha256:05eed71e2e327246ad6b38c540c4a3117230b19679b875190486ddd2d721422d \
  --hash sha256:f8ac84de7840f5b9c4e3347b3c1eaa50f7e49c2b07596221daec5edaabbd7c48 \
  # ^ from pytest
idna==2.8 \
  --hash sha256:c357b3f628cf53ae2c4c05627ecc484553142ca23264e593d327bcde5e9c3407 \
  --hash sha256:ea8b7f6188e6fa117537c3df7da9fc686d485087abf6ac197f9c46432f7e4a3c \
  # ^ from requests
importlib-metadata==0.23; python_version < "3.8" or python_version < "3.8" \
  --hash sha256:aa18d7378b00b40847790e7c27e11673d7fed219354109d0e7b9e5b25dc3ad26 \
  --hash sha256:d5f18a79777f3aa179c145737780282e27b508fc8fd688cb17c7a813e8bd39af \
  # ^ from pluggy, pytest
more-itertools==7.2.0 \
  --hash sha256:409cd48d4db7052af495b09dec721011634af3753ae1ef92d2b32f73a745f832 \
  --hash sha256:92b8c4b06dac4f0611c0729b2f2ede52b2e1bac1ab48f089c7ddc12e26bb60c4 \
  # ^ from pytest, zipp
packaging==19.2 \
  --hash sha256:28b924174df7a2fa32c1953825ff29c61e2f5e082343165438812f00d3a7fc47 \
  --hash sha256:d9551545c6d761f3def1677baf08ab2a3ca17c56879e70fecba2fc4dde4ed108 \
  # ^ from pytest
pathlib2==2.3.5; python_version < "3.6" or python_version == "3.4.*" or python_version < "3" \
  --hash sha256:0ec8205a157c80d7acc301c0b18fbd5d44fe655968f5d947b6ecef5290fc35db \
  --hash sha256:6cd9a47b597b37cc57de1c05e56fb1a1c9cc9fab04fe78c29acd090418529868 \
  # ^ from importlib-metadata, pytest
pluggy==0.13.0 \
  --hash sha256:0db4b7601aae1d35b4a033282da476845aa19185c1e6964b25cf324b5e4ec3e6 \
  --hash sha256:fa5fa1622fa6dd5c030e9cad086fa19ef6a0cf6d7a2d12318e10cb49d6d68f34 \
  # ^ from pytest
py==1.8.0 \
  --hash sha256:64f65755aee5b381cea27766a3a147c3f15b9b6b9ac88676de66ba2ae36793fa \
  --hash sha256:dc639b046a6e2cff5bbe40194ad65936d6ba360b52b3c3fe1d08a82dd50b5e53 \
  # ^ from pytest
urllib3==1.25.6 \
  --hash sha256:3de946ffbed6e6746608990594d08faac602528ac7015ac28d33cee6a45b7398 \
  --hash sha256:9a107b99a5393caf59c7aa3c1249c16e6879447533d0887f4336dde834c7be86 \
  # ^ from requests
wcwidth==0.1.7 \
  --hash sha256:3df37372226d6e63e1b1e1eda15c594bca98a22d33a23832a90998faa96bc65e \
  --hash sha256:f4ebe71925af7b40a864553f761ed559b43544f8f71746c2d756c7fe788ade7c \
  # ^ from pytest
pytest==5.2.2 \
  --hash sha256:27abc3fef618a01bebb1f0d6d303d2816a99aa87a5968ebc32fe971be91eb1e6 \
  --hash sha256:58cee9e09242937e136dbb3dab466116ba20d6b7828c7620f23947f37eb4dae4 \
  # ^ from tmp-nxehdzkkmi
requests==2.22.0 \
  --hash sha256:11e007a8a2aa0323f5a921e9e6a2d7e4e67d9877e85773fba9ba6419025cbeb4 \
  --hash sha256:9cf5292fcd0f598c671cfc1e0d7d1a7f13bb8085e9a590f48c010551dc6c4b31 \
  # ^ from tmp-nxehdzkkmi

When I run dephell deps convert --from=poetry.lock --to=requirements.lock --envs=main, I get an error (which is probably another issue):
WARNING conflict was found
Incompatible python constraint for zipp.

Required by marker: <3.8,>=2.7.

Supported:
 + Version 0.6.0 compatible with python >=2.7.
 + Version 0.5.2 compatible with python >=2.7.
 + Version 0.5.1 compatible with python >=2.7.
 + Version 0.5.0 compatible with python >=2.7.
 + Version 0.4.0 compatible with python >=2.7.
 + Version 0.3.3 compatible with python >=2.7.
 + Version 0.3.2 compatible with python >=2.7.
 + Version 0.3.1 compatible with python >=2.7.
 + Version 0.3.0 compatible with python >=2.7.
 + Version 0.2.1 compatible with python >=2.7.
 + Version 0.2.0 compatible with python >=2.7.
 + Version 0.1.0 compatible with python >=2.7.

More information about my environment:

Python 3.7.4
ArchLinux

Oh, I see, it's from lockfile. Thank you!


Labels of checkboxes in CesiumInspector are now real labels

Usual I click on text at side of a checkbox instead of on the checkbox. But this wasn't possible in CesiumInspector. This MR fixes it by adding label tag for each checkbox.
Btw: I'm in vacation next week. If you want to make adjustments to this MR (e.g. adding changelog entry if necessary) to get it in Cesium 1.49 release feel free to do it ;).
Btw2: Code of CesiumInspector is really ugly - a refactoring of whole code of it would be nice ;).

Thanks for the pull request @SunBlack!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.
:earth_africa: :earth_americas: :earth_asia:

Thanks @SunBlack! This has been in my todo list for a while but I haven't gotten around to it. I took a quick peak at the code changes and it looks fine. I'll do a more through review next week and get this merged in time for the release.

Btw2: Code of CesiumInspector is really ugly

I'm not surprised, I wrote this when I was still an intern on the team and I didn't really understand how knockout worked 😂 I probably won't have time to clean it up in the near future, but if you would like to I'm happy to review another pull request!

Thanks for updating this @SunBlack!


Compilation issue when building cilium-runtime

Bug report

General Information
Cilium version: Master
How to reproduce the issue
Running 'make docker-image-runtime'
Compiling bpftool in Dockerfile.runtime will encounter the issue with following error:
``Auto-detecting` system features:
...                        libelf: [ on  ]
...                           bpf: [ on  ]
/bin/sh: 1: /tmp/linux/scripts/bpf_helpers_doc.py: not found
Makefile:184: recipe for target 'bpf_helper_defs.h' failed
make[1]: Leaving directory '/tmp/linux/tools/lib/bpf'
make[1]: *** [bpf_helper_defs.h] Error 127
make[1]: *** Deleting file 'bpf_helper_defs.h'
Makefile:31: recipe for target '/tmp/linux/tools/lib/bpf/libbpf.a' failed
make: *** [/tmp/linux/tools/lib/bpf/libbpf.a] Error 2
make: *** Waiting for unfinished jobs....
``

Fixed by https://github.com/cilium/cilium/pull/9715


Blazor JSInterop example return a ValueTask

From @simonpbond ... [EDIT by @guardrex for formatting]

The JSInterop - Blazor documentation should return a ValueTask<T>?

https://docs.microsoft.com/aspnet/core/blazor/javascript-interop?view=aspnetcore-3.0#capture-references-to-elements

To use an extension method to focus an element, create a static extension method that receives the IJSRuntime instance:

public static Task Focus(this ElementReference elementRef, IJSRuntime jsRuntime)
{
    return jsRuntime.InvokeAsync<object>(
        "exampleJsFunctions.focusElement", elementRef);
}

I may be wrong, however I assume it should now be:

public static ValueTask<T> Focus<T>(this ElementReference elementRef, IJSRuntime jsRuntime)
{
    return jsRuntime.InvokeAsync<T>(
        "exampleJsFunctions.focusElement", elementRef);
}

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

ID: 49807900-0d56-e23c-1aef-d79099caeffb
Version Independent ID: feff434f-912c-0985-d575-4a23a629057d
Content: ASP.NET Core Blazor JavaScript interop
Content Source: aspnetcore/blazor/javascript-interop.md
Product: aspnet-core
Technology: aspnetcore-blazor
GitHub Login: @guardrex
Microsoft Alias: riande

I'll let engineering respond, but note that engineering reviewed everything just prior to 3.0's release last week, and that signature wasn't changed during the review+update. However, it's best for them to look at this syntax and comment further. I don't have an ETA on when they'll see this, but it's on the Blazor.Docs project now for triage. They'll get to it when they can.


Unable to find a config file

nps version: 5.3.2
node version: 8.1.2
npm version: 5.0.3

Scripts file (or at least the relevant bits):
exports.scripts = {
  dev: {
    default: {
      script: concurrent.nps(
        'bundleDeps.browser.dev',
        'build.css.dev',
        'build.browser.dev',
        'build.server.dev',
        'server.dev'
      )
    }
}

package.json
{
  "scripts": {
    "start": "nps -c ./build/package-scripts.js"
  }
}

The command executed:
npm start dev

The output:
> nps -c ./build/package-scripts.js "dev"

nps is executing `dev`: node node_modules/concurrently/src/main.js --kill-others-on-fail --prefix-colors "bgBlue.bold,bgMagenta.bold,bgGreen.bold,bgBlack.bold,bgCyan.bold" --prefix "[{name}]" --names "bundleDeps.browser.dev,build.css.dev,build.browser.dev,build.server.dev,server.dev" 'nps bundleDeps.browser.dev' 'nps build.css.dev' 'nps build.browser.dev' 'nps build.server.dev' 'nps server.dev'
[build.browser.dev] Unable to find a config file and none was specified.

Suggested solution:
Gotta pass the same config file to all subsequent scripts?

ping @kentcdodds

I'm on vacation. I'll get to it when I can. Thanks for your patience.

@jonataswalker Follow issue #139 and https://github.com/kentcdodds/nps-utils/issues/13. Sounds like you're facing the same troubles. Hopefully, it will be resolved in an upcoming release.

Ah ok @RichDonnellan thank for pointing it.

@jonataswalker Do you mind if I close this issue since there are two others you can track?

Yeah, let's do that. Thanks @Miklet :+1:


.NET Framework support for v4

Our current target for v4 is .NET Framework 4.5. However, this version is quite obsolete and it's support has been abandoned by MS more than half of the hear ago.
Given that we update vNext quite rarely, I'd suggest to re-target to the version that is being currently supported by MS. That is rather 4.5.2 or the 4.6.2.
I have a proposal to support 4.6.2 instead of 4.5 family. In the 4.6.x family were done some improvements in API that would useful to us. For instance:

Additional collections implement IReadOnlyCollection<T> such as Queue<T> and Stack<T>. Might be potentially useful as we use Stack<T> in a few places and might want to refactor this to have that in a single place only.
The System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture properties are now read-write rather than read-only. We actually have such switchers in our code and this would allow to eliminate them.
The AppContext - the whole new world of defining the compatibility/feature switches. It might be very cool feature for some default/experimental features that we want to be able to enable/disable globally at once. The very good example is this PR when we want to have constant names for tests decorated with AutoData attribute. The reason is that VS runner is unable to run such tests and there clients who use VS runner. We don't want to enable such behavior by default, therefore if user wants this feature, it would need to define it's own AutoData-like attribute, enable the strategy there and later use his attribute all over the code. Might be not very conveniently if you already have thousands of tests.
With AppContext we could define a custom switch to control the default behavior, so we could enable the behavior easily. The benefit is that this is the officially suggested way to do such things.
Of course, this should be used with caution and in exceptional cases only, however the instrument might be useful.

There might be some other benefits that I'm not aware of (e.g. some NuGet dependencies that have .NET Framework limitations).
Personally, I don't see too much issues with support of v4.6.x branch and higher. This branch is quite old and is being actively used. Given that our library is a test lib, we will enforce target framework for the test projects only without touching the production projects.
@AutoFixture/core What do you think about this? Would you agree to target v4.6.2 for the v4 or you have strong opinion to keep v4.5.x, so we should set v4.5.2 instead?

That's a good point, it's great that you brought it up 💯 IMO, while supporting v4.6.2 looks tempting, perhaps we could rather pick v.4.5.2 to allow for broader reach?

It's the only point that bothers me too - about support. However it's a dark area as I don't know whether .NET 462 will be an issue for clients or whether they are fine and already use it. We update to major quite rarely and will need to work with what we have for some time. That's why I put this topic here.
Just discovered that all our friends (NUnit, xUnit, NSubstitute, Moq, FakeItEasy) support 4.5, so probably we have no choice here - we'll need to stick to that. It would be a pity if somebody need us as 4.5, but we don't support that.
After all, 4.6.2 features are not critical to us, so we could probably live some time without that..

Wouldn't be best to aim to support only .NET Standard 1.5 ?

@Kralizek I see a few major reasons to support .NET 4.5 explicitly:

We target .NET Standard 1.5 that is supportable starting .NET 4.6. Meaning, that we'll automatically abandon .NET 4.5.
There are feature specific to desktop only and are missing on .NET Standard (e.g. serializable exceptions, MailAddress type, etc).
There might be people using VS 2012 and VS 2015. If we start to target .NET Standard only, I'm not sure they will be covered. While the framework might be compatible, I'm not sure that build SDK will handle that.

Also it doesn't cost too much to think about abandoning full framework support 😄

Done! Now we target v4.5.2.


Support dark mode by class

Is your feature request related to a problem? Please describe.
My app set dark mode with .
I don't think there is a way to use stylex to generate a css style like :is([data-mode="dark"] .myclass) { ... }.
Describe a solution you'd like
Describe alternatives you've considered
Additional context

You can have a look at the Next.js example to see how it might be done.
I don't know if this is your question or not, but try to be explicit about what you want support for.

Of course: for the needs of my app, i need to be able to demo a component in both light and dark mode on the same screen.

  <MyStyledComponent className="myComponent" />

  <MyStyledComponent className="myComponent" />

I cannot use @media (prefers-color-scheme: light/dark) because this is OS specific (unaffected by th color-scheme css property).
I would like to be able to generate a style like:
:root {
  --primary: red;
}

:is([data-mode="dark"]) {
  --primary: blue;
}

.myComponent {
  color: var(--primary);
}

Maybe from something like:
// tokens.stylex.js

import * as stylex from '@stylexjs/stylex';

export const colors = stylex.defineVars({
  primary: {
    default: 'red',
    ':is[dark-mode="dark"]': 'blue',
  },
});

// MyComponent.jsx

import { colors } from './tokens.stylex';

const styles = stylex.create({
  myComponent: {
    default: colors.primary,
  },
});

// ...

What do you think?

Or, to generate a style like:
:root {
  --primary: red;
  --primary-dark: blue;
}

.myComponent {
  color: var(--primary);
}

:is([data-mode="dark"]) .myComponent {
  color: var(--primary-dark);
}

Maybe from something like:
// tokens.stylex.js

import * as stylex from '@stylexjs/stylex';

export const colors = stylex.defineVars({
  primary: 'red',
  'primary-dark': 'blue',
});

// MyComponent.jsx

import { colors } from './tokens.stylex';

const styles = stylex.create({
  myComponent: {
    color: {
      default: colors.primary,
      ':is[dark-mode="dark"]': colors['primary-dark'],
    }
  },
});

// ...

hey @olivierpascal
how about using the required component as nested object
psuedoSelector(dark).myComponent : colorValue
psuedoSelector(light).myComponent : colorValue
for this there is a reference on docs, see if it helps
defining styles
correct me if it doesn't relate to your usecase

Mmmh, the problem is that the pseudo selector ':is[dark-mode="dark"]' should be at the root level and hence placed before the class name. I don't think it's possible to do so with a nested object, at the component level.

I think for my use case, the best API would be something like:
// tokens.stylex.js

import * as stylex from '@stylexjs/stylex';

export const colors = stylex.defineVars({
  primary: {
    default: 'red',
    ':is[dark-mode="dark"]': 'blue',
  },
  secondary: {
    default: 'green',
    ':is[dark-mode="dark"]': 'black',
  },
});

-or-
// tokens.stylex.js

import * as stylex from '@stylexjs/stylex';

export const colors = stylex.defineVars({
  default: {
    primary: 'red',
    secondary: 'green',
  },
  ':is[dark-mode="dark"]': {
    primary: 'blue',
    secondary: 'dark',
  },
});

Sorry to spam. I just see that [stylexjs.com], which  is achieving just this:
:root {
    --ifm-color-primary: #872291;
    /* ... */
}

html[data-theme=dark]:root {
    --ifm-color-primary: #be51c8;
    /* ... */
}

I guess it uses stylex. So the question is: how? 😲

There's a lot here already, so I'll try to just answer in the initial question. Using dark mode based on a user controlled data-id.  This can be done by creating default variables with defineVars and then creating separate themes with createTheme.
Something like:
// vars.stylex.js
import * as stylex from '@stylexjs/stylex';

export const colors = stylex.defineVars({
  primary: 'red',
  // ...
});

// color-themes.js
import * as stylex from '@stylexjs/stylex';
import {colors} from './vars.stylex.js';

export const darkTheme = stylex.createTheme(colors, {
  primary: 'blue',
  // ...
});

// layout.tsx

import {darkTheme} from './color-themes';

export default function RootLayout({isDarkMode, children}) {
  return (

      {/* ... */}

        {children}

  );
}

Now you can just import and use the variables from vars.stylex.ts directly
and use them. They will resolve to light mode or not based on whether
the theme is set on the html tag or not.

Things to note:

You don't need the data-id for StyleX, but you can keep it if you want it for other things.
The layout.tsx is an example for how this might be done in NextJS. You can set the theme
on the html element any way you want. e.g. If you're using DOM APIs for this, that will     work too.
Remember that you must always import the variables from the original defineVars export.

Just to add on to the conversation, you can also use a Context (if you are using React or Nextjs) to switch between themes globally similar to most other styling libraries out there
const ThemeContext = React.createContext(undefined)
...
const [theme, setTheme] = useState('light');
...
// You can also append props to children directly through cloneElement (but is discouraged by React team)
<ThemeContext.Provider value={ theme }>

		{children}

</ThemeContext.Provider>

You can also use custom hooks and an effect to automatically set default theme and persist data to local storage.
React docs: https://react.dev/reference/react/createContext shows the same exact application method.
This way you would not have to create one defineVars and two separate themes to use it with @media, you can just create the same defineVars with an added theme as mentioned above by @nmn, but this may not be a recommended use pattern (and why he did not cover it).

I didn't cover the JS bits but @kevintyj's suggestion is valid for React.

This way you would not have to create one defineVars and two separate themes to use it with @media

I'm not clear what this means so I'll try to clarify what I meant by multiple themes.
Case 1: Light Theme is default. Dark theme can be enabled manually
Use defineVars to create the default light theme, use createTheme to create a dark theme. Apply dark theme conditionally as suggested by @kevintyj
Case 2: System theme is default. Light and dark themes can be enabled manually
Use defineVars and use the media query to make this theme adapt to the media query. Use createTheme to create the "light" and "dark" themes that always use the light or dark colors respectively.

@nmn your solution works like a charm, thank you. I have nothing to add, maybe we can close this topic? Thanks all very much.

@nmn If we possess numerous properties but wish to override certain values, what would be the most effective method to accomplish this? I used  ...colors.__tokens but it didn't work, so I have to export base values.
Here is the code I've written, but I think it's not quite right.
// tokens.stylex.tsx
import * as stylex from '@stylexjs/stylex';
const DARK = '@media (prefers-color-scheme: dark)';

export const colorsRepo = {
  primaryText: { default: 'black', [DARK]: 'white' },
  secondaryText: { default: '#333', [DARK]: '#ccc' },
  accent: { default: 'blue', [DARK]: 'lightblue' },
  background: { default: 'white', [DARK]: 'black' },
  lineColor: { default: 'gray', [DARK]: 'lightgray' },
  borderRadius: '4px',
  fontFamily: 'system-ui, sans-serif',
  fontSize: '16px',
};

export const colors = stylex.defineVars(colorsRepo);

export const spacing = stylex.defineVars({
  none: '0px',
  xsmall: '4px',
  small: '8px',
  medium: '12px',
  large: '20px',
  xlarge: '32px',
  xxlarge: '48px',
  xxxlarge: '96px',
});

//themes.ts
import * as stylex from '@stylexjs/stylex';
import { colors, colorsRepo } from './tokens.stylex';

// A constant can be used to avoid repeating the media query
const DARK = '@media (prefers-color-scheme: dark)';

// Dracula theme
export const dracula = stylex.createTheme(colors, {
  ...colorsRepo,
  primaryText: { default: 'purple', [DARK]: 'lightpurple' },
  background: { default: '#555', [DARK]: 'black' },
});

// MyComponent.tsx
'use client';

import * as stylex from '@stylexjs/stylex';
import { colors, spacing } from './tokens.stylex';
import { dracula } from './themes';
import { useState } from 'react';

const styles = stylex.create({
  container: {
    color: colors.primaryText,
    backgroundColor: colors.background,
    padding: spacing.medium,
    marginTop: '10px',
    fontSize: colors.fontSize,
  },
});

export const MyComponent = ({ children }: any) => {
  const [isDark, setDark] = useState(false);
  const toggle = () => {
    setDark(!isDark);
  };
  return (

        <button onClick={toggle}>Toggle</button>
         {children}

  );
};

And one more thing, the class for debug mode is UnknownFile__dracula

I test with https://github.com/facebook/stylex/tree/main/apps/nextjs-example)

  <button>Toggle</button>

Hello

I had this bug the very first time I used stylex but, as I stopped using media queries, I forgot to create a issue.
On my side, the following does work:
export const colorsRepo = {
  background: 'red',
};

export const colorsRepo = {
  background: {
    default: 'red', // work
    whatever: 'lightgray',
  },
};

When the following silently fail (the entire var group is not set):
export const colorsRepo = {
  background: {
    default: 'red',
    '@media (prefers-color-scheme: dark)': 'lightgray',
  },
};

If you can reproduce this bug, maybe create a new issue with a minimal reproducible code?

If we possess numerous properties but wish to override certain values, what would be the most effective method to accomplish this?

This was a type constraint that I fixed yesterday. In the next version, you'll be able to override only some of the variables when creating a theme.

Ok @nmn, here is a full reproducible example:
// tokens.stylex.ts

import * as stylex from '@stylexjs/stylex';

// A constant can be used to avoid repeating the media query
const DARK = '@media (prefers-color-scheme: dark)';

export const colors = stylex.defineVars({
  primary: { default: 'blue', [DARK]: 'green' }, // NOT OK: text output is black
  // primary: 'blue', // OK: text output is blue
  // primary: { default: 'blue', whatever: 'green' }, // OK: text output is blue
});

// MyComponent.tsx

import * as stylex from '@stylexjs/stylex';
import React from 'react';

import { colors } from './tokens.stylex';

const styles = stylex.create({
  container: {
    color: colors.primary,
  },
});

export const MyComponent: React.FC = () => (

TEXT

);

The CSS var is not compiled.

Probably related to https://github.com/facebook/stylex/issues/235

@olivierpascal Yup, I think this is caused by #235 as well. Can you try a production build to verify in your case as well?

for me this is working both with context and prefers-color-scheme.
//themes.ts
const DARK = '@media (prefers-color-scheme: dark)';

export const lightTheme = stylex.createTheme(colors, {
  primary: 'blue',
  bg: {
    default: "white",
    [DARK]: "white",
  }
})

export const darkTheme = stylex.createTheme(colors, {
  primary: 'blue',
  bg: {
    default: "black",
    [DARK]: "black",
  }
})

how can i make it work without the colors object, If possible. I couldn't get the red or blue to appear both changing the prefers-color-scheme though the browser and by changing the theme via context.
export const colors = stylex.defineVars({
  primary: 'red',
  bg: {
    default: "red",
    [DARK]: "blue",
  }
});

then i made this provider like suggested above:
//providers.tsx
type Theme = 'light' | 'dark'

interface ThemeContextType {
  theme: Theme
  setTheme: Dispatch<SetStateAction<Theme>>
}
export const ThemeContext = createContext<ThemeContextType | undefined>(undefined)

export const ThemeProvider = ({ children }: Props) => {

  const [theme, setTheme] = useState<Theme>('dark')
  const contextValue: ThemeContextType = { theme, setTheme }

  return (
    <ThemeContext.Provider value={contextValue}>

          {children}

    </ThemeContext.Provider>
  )
}

export const useTheme = () => {
  const context = useContext(ThemeContext)
  if (!context) {
    throw new Error('useTheme must be used within a ThemeProvider')
  }
  return context
}

//component.ts
  const { setTheme } = useTheme();

//layout.ts
export default async function RootLayout({ children }: { children: React.ReactNode }) {

  return (
    <ThemeProvider>
        {children}
    </ThemeProvider>
  )
}

how can i make it work without the colors object, If possible

@alejandroyunes I don't understand what you're asking.

hi,
yes I think what I was asking is that if primary isnt any of the createThemplate it takes what is in the colors object in defineVars,
//themes.ts
const DARK = '@media (prefers-color-scheme: dark)';

export const lightTheme = stylex.createTheme(colors, {
  bg: {
    default: "white",
    [DARK]: "white",
  }
})

export const darkTheme = stylex.createTheme(colors, {
  bg: {
    default: "black",
    [DARK]: "black",
  }
})

export const colors = stylex.defineVars({
  primary: 'red',
  bg: {
    default: "red",
    [DARK]: "blue",
  }
});

why do I need the bg in colors and in both themes?

I still don't understand what you're asking, but you should be able to write this instead:
//themes.ts
const DARK = '@media (prefers-color-scheme: dark)';

export const lightTheme = stylex.createTheme(colors, {
  bg: "white",
})

export const darkTheme = stylex.createTheme(colors, {
  bg: "black",
})

export const colors = stylex.defineVars({
  primary: 'red',
  bg: {
    default: "red",
    [DARK]: "blue",
  }
});

Sorry to bring up an old thread but I'm not able to do dark mode without FOUCs.
Given this example...
// layout.tsx

import {darkTheme} from './color-themes';

export default function RootLayout({isDarkMode, children}) {
  return (

      {/* ... */}

        {children}

  );
}

I'm using Astro and during server-side rendering, dark mode is unknown so it defaults to light mode. Now on client hydration we get the light mode rendered, then once the React code kicks in and recognizes that dark mode is set, it re-renders.
The way I got this working in other styling libraries is by using descendent selectors similar to html[data-theme='dark'] .test. Even on the first render from SSR, the styles are correct. Is there an escape hatch here?
Thanks so much @nmn!

I'm using Astro and during server-side rendering, dark mode is unknown so it defaults to light mode.

This is the problem here. We have media queries for detecting dark mode. You shouldn't be trying to choose light mode or dark mode on the server at all.
I'm working on adding first-class support for light-dark(). Which will make doing this even more flexible.
But TLDR; Setting themes based on  selectors such as html[data-theme='dark'] should be avoided as a best practice. But even if you're using them, they should only be used when the user has manually overridden their preferred color scheme which should be known on the server. If you don't know their preferred color scheme, you should be using Media Queries to choose automatically. (And use light-dark() in the future)

Gotcha, so the rec is to store user prefs for dark / light on server and then use that for server side rendering.
FWIW, the stylex website uses html[data-theme=dark].

FWIW, the stylex website uses html[data-theme=dark].

The only SSR-safe ways of doing color theming is:

To store the user pref
Use media queries

Docusaurus generates a static bundle so there is no server to store user preferences on.
:(


Segmentation Fault

Hello authors!
While training Mamba on ImageNet1K (using a 224 image size, 16 patch size, and 196 sequence length per image), I've encountered instability issues. After running for several epochs, a segmentation fault occurs, interrupting the training process. This error seems to occur randomly. Have you experienced a similar issue, or do you have any suggestions for resolving this problem?
Thank you in advance for your assistance. I eagerly await your reply.

No I've never seen segmentation fault. Could also be hardware issues.


CategoricalPd:entropy

I have some trouble understanding the calculation of entropy for discrete action space (CategoricalPd).
def entropy(self):
        a0 = self.logits - tf.reduce_max(self.logits, axis=-1, keepdims=True)
        ea0 = tf.exp(a0)
        z0 = tf.reduce_sum(ea0, axis=-1, keepdims=True)
        p0 = ea0 / z0
        return tf.reduce_sum(p0 * (tf.log(z0) - a0), axis=-1)

Could you please give me some explanation for this? Thanks a lot!

First four lines are just calculating the softmax probabilities from the logits. the line that returns the entropy is just -p0log(p0) = -p0log(ea0/z0) = p0log(z0/ea0) = p0 * (log(z0) - log(ea0)) = p0 * (log(z0) - a0)


Spotify playlist regex not working

I tried to use the spotify playlist regex to catch https://open.spotify.com/playlist/37i9dQZF1EM10lRW9KvRGe?si=y2Nlg7ncRcqE86cLv73tDg and doesn`t work

You can try
^https?:\/\/(?:open|play)\.spotify\.com\/playlist\/[\w\d]+$

to catch
https://open.spotify.com/playlist/37i9dQZF1EM10lRW9KvRGe

You can try
^https?:\/\/(?:open|play)\.spotify\.com\/playlist\/[\w\d]+$

to catch
https://open.spotify.com/playlist/37i9dQZF1EM10lRW9KvRGe


Examples don't seem to work (?)

Hello, I've tried to visit

https://simondanisch.github.io/WGLDemos/soil/
and
https://simondanisch.github.io/WGLDemos/oceananigans/
but I don't see any plot. I do see the title and the slider (that I can move) however.

This is happening on Firefox 123.0 (Arch Linux, Wayland), and on Chrome 122.0 (Android 14).
Is it working for other people?

same here.  for the first link, i get a "WebSocket connection to 'wss://simondanisch.github.io/464cc53c-bb66-4bf8-8a49-9cdc35142bd8/4ff4/' failed" error, among many others.


Pipeline prefixes X to samplenames

Description of the bug
Running the pipeline with this samplesheet.csv:
sample,fastq_1,fastq_2,strandedness,condition,replicate
1A2,reads/1A2_S4_R1_001.fastq.gz,reads/1A2_S4_R2_001.fastq.gz,auto,1,A2
1B2,reads/1B2_S14_R1_001.fastq.gz,reads/1B2_S14_R2_001.fastq.gz,auto,1,B2
1C1,reads/1C1_S24_R1_001.fastq.gz,reads/1C1_S24_R2_001.fastq.gz,auto,1,C1
5A2,reads/5A2_S7_R1_001.fastq.gz,reads/5A2_S7_R2_001.fastq.gz,auto,5,A2
5B2,reads/5B2_S17_R1_001.fastq.gz,reads/5B2_S17_R2_001.fastq.gz,auto,5,B2
5C1,reads/5C1_S27_R1_001.fastq.gz,reads/5C1_S27_R2_001.fastq.gz,auto,5,C1

yielded these tables:
salmon.merged.gene_counts.tsv
gene_id	gene_name	X1A2	X1B2	X1C1	X5A2	X5B2	X5C1
16Sa	16Sa	11039.388	14.242	0	0	0	0
16Sb	16Sb	19419.287	13587.814	9855.454	330.904	4258.272	924.453
...

Why were samples renamed?
Cheers
Command used and terminal output
No response
Relevant files
No response
System information
No response

Could you confirm which version you're using for this please?


excludes inside licenseSet is not working as expected

I've moved to 4.0 and then, following the read.me, I moved includes and excludes to a single LicenseSet.
    <pluginManagement>
      <plugins>
        <plugin>
					<!-- This plugin is to control the headers -->
          <groupId>com.mycila</groupId>
          <artifactId>license-maven-plugin</artifactId>
          <version>${license-maven.version}</version>
          <inherited>true</inherited>
          <configuration>
            <defaultProperties>
              <owner>${license.copyrightOwners}</owner>
            </defaultProperties>
            <defaultUseDefaultExcludes>true</defaultUseDefaultExcludes>
            <licenseSets>
              <licenseSet>
                <inlineHeader>${inlineHeader}</inlineHeader>
                <excludes>
                  <exclude>**/README</exclude>
                  <exclude>src/test/resources/**</exclude>
                  <exclude>src/main/resources/**</exclude>
                  <exclude>**/THIRD-PARTY.properties</exclude>
                  <exclude>**/LICENSE.txt</exclude>
                  <exclude>src/site/*/**</exclude>
                  <exclude>.m2e-launchers/*/**</exclude>
                  <exclude>**/.c8tech.*</exclude>
                  <exclude>**/*.jks</exclude>
                  <exclude>**/package-info.java</exclude>
                  <exclude>**/.factorypath</exclude>
                  <exclude>**/.project</exclude>
                </excludes>
                <includes>
                  <include>pom.xml</include>
                  <include>src/main/java/**</include>
                  <include>src/test/java/**</include>
                </includes>
              </licenseSet>
            </licenseSets>
            <failIfUnknown>true</failIfUnknown>
            <mapping>
              <pom.xml>XML_PER_LINE</pom.xml>
              <xml>XML_STYLE</xml>
              <store>TXT_STYLE</store>
            </mapping>
            <detail>false</detail>
          </configuration>
          <dependencies>
            <dependency>
              <groupId>com.mycila</groupId>
              <artifactId>license-maven-plugin-git</artifactId>
              <version>${license-maven.version}</version>
            </dependency>
          </dependencies>
        </plugin>
...

    <profile>
      <id>when-building-any-project-check-headers</id>
      <activation>
        <file>
          <exists>pom.xml</exists>
        </file>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>com.mycila</groupId>
            <artifactId>license-maven-plugin</artifactId>
            <inherited>true</inherited>
            <executions>
              <execution>
                <id>check-license-headers</id>
                <goals>
                  <goal>check</goal>
                </goals>
                <phase>process-test-classes</phase>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>

Doing this made my build fails due to a non-mapped extension.
I've returned the excludes to the old configuration tag and then my build has worked again.

I think the issues are fixed in the unreleased 4.0.rc2, I believe you tried 4.0.rc1 to be clear.

@cvgaviao : are you able to locally build the current project's snapshot and try it to confirm (or not) ?
Thanks!

@mathieucarbou and @hazendaz, sorry to answer late.
I don't think that 4.0.rc2 fixed it. I've upgraded right now to it and just moved the includes and excludes back to under <licenseSet> and my project has failed to build again.
[INFO] --- license-maven-plugin:4.0.rc2:remove (update-license-header) @ c8tech-java-dev-vertx-parent ---
[INFO] Removing license headers...
[WARNING] Unknown file extension: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/m2e-launchers/c8tech-java-dev-vertx - update headers.launch
[WARNING] Unknown file extension: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/.c8tech.releng.parent
[WARNING] Unknown file extension: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.launcher/.c8tech.releng.vertx.launcher

@adamretter : any help would be appreciated here ;-) thanks!

@mathieucarbou I will try and take a look tonight

@cvgaviao when you say:

Doing this made my build fails due to a non-mapped extension.

Can you share the entire configuration and/or pom.xml?
Also can you share the details of the failure output by mvn?

@adamretter, I think that the issue is in the check mojo that is triggered when I try to 'install' the project. Seems that it is not respecting the excludes/include. I will update the issue to include the profiles that I'm using...
[INFO] --- license-maven-plugin:4.0.rc2:check (check-license-headers) @ c8tech-java-dev-vertx-parent ---
[INFO] Checking licenses...
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/pom.xml
[WARNING] Unknown file extension: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/.m2e-launchers/c8tech-java-dev-vertx - install.launch
[WARNING] Unknown file extension: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/.m2e-launchers/c8tech-java-dev-vertx - update headers.launch
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.jooq.codegen/src/main/java/br/com/c8tech/mmarket/backend/dev/jooq/ClassPrefixGeneratorStrategy.java
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.jooq.codegen/src/main/java/br/com/c8tech/mmarket/backend/dev/jooq/ObjectToVertxJsonConverter.java
[WARNING] Unknown file extension: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/.c8tech.releng.parent
[WARNING] Unknown file extension: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.launcher/.c8tech.releng.vertx.launcher
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.jooq.codegen/src/main/java/br/com/c8tech/mmarket/backend/dev/jooq/DatabaseMigrationUtils.java
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.jooq.codegen/LICENSE.txt
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.jooq.codegen/pom.xml
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/LICENSE.txt
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.jooq.codegen/src/main/java/br/com/c8tech/mmarket/backend/dev/jooq/CustomClassicReactiveVertxGenerator.java
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.launcher/src/main/java/br/com/c8tech/mmarket/backend/dev/exec/VertxLauncherWithContainer.java
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.launcher/pom.xml
[WARNING] Missing header in: /home/cvgaviao/Development/C8Tech/c8tech-java-dev-vertx/br.com.c8tech.dev.vertx.launcher/src/main/java/br/com/c8tech/mmarket/backend/dev/exec/package-info.java

[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  2.093 s
[INFO] Finished at: 2020-08-20T10:46:25-03:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.mycila:license-maven-plugin:4.0.rc2:check (check-license-headers) on project c8tech-java-dev-vertx-parent: Some files do not have the expected license header -> [Help 1]

It is failing because if <failIfUnknown>true</failIfUnknown>. And the files are not excluded probably based on the pattern matching expression. This is an ANT one: the project is using the Maven default API (ant-like) to select files and include/exclude them. There is no custom code here involved in file selection within MLP


Rewrite how “Preparing current file” is differentiated from the generic “Preparing targets”

The old implementation of inspecting the InProgressPrepareForEditorTask has a few race conditions including the fact that we would start the preparation task before the inProgressPrepareForEditorTask was set.
Instead, keep track of the purpose for each preparation task. This ends up simplifying the code as well.

@swift-ci Please test

@swift-ci Please test

@swift-ci Please test Windows


Feature/add fast and faster configurations

Adds the ability to scale the parameters that we've determined most affect computational performance via --fast and --faster gflags.  More specifically, this adds the following:

Scales maxFeaturesPerFrame by ~0.83 in the fast configuration and ~0.7 in the faster configuration
Scales horizon by ~0.91 in the fast configuration and ~0.84 in the faster configuration
Log messages to warn the user that parameters were changed
Associated unit tests

The scale factors are currently captured as constexpr both because I don't see an use case for changing the scaling parameters at runtime (as the user can just change the parameters directly and not use the flags provided) and because relying on parameter parsing order to pick up the scale factors first seems brittle.

Closing in favor of a more maintainable approach per request of @ToniRV


VectorFuzzer: Add support for LazyVector

Allow VectorFuzzer to generate lazy vectors that can be used in expression fuzzer.

@bikramSingh91 you did this right?

Fixed in #2769


Update to JLab 1

Update all the examples so they are compatible with JupyterLab 1.0:
This is mostly focusing on getting them to compile for JupyterLab 1, but they would require another pass to check they are working properly.
TODO

[x] 1_hello_world
[x] 2_commands_and_menus
[x] 3a_widgets
[x] 3b_datagrid
[x] 4a_kernel_output
[x] 4b_jupyterwidgets
[x] 5_signals_and_buttons
[x] 6_kernel_messaging
[ ] 7_serving_files?

Tried this PR linking examples 1 to 5. jlab can be built with latest jlab.
Only example 1 is an extension (which works as the expected message can be seen in the console`the JupyterLab main application:...)
@jtpio do you get the same behavior?
JupyterLab v2.0.0a1
Known labextensions:
   app dir: /opt/datalayer/opt/miniconda3/envs/datalayer/share/jupyter/lab
        1_hello_world v0.1.0  enabled  OK*

   local extensions:
        1_hello_world: /Users/echar4/datalayer/repos/jupyterlab-extension-examples/1_hello_world
        @datalayer/jupyterlab-twitter: /Users/echar4/datalayer/src/jupyterlab/twitter

   linked packages:
        2_commands_and_menus: /Users/echar4/datalayer/repos/jupyterlab-extension-examples/2_commands_and_menus
        3a_widgets: /Users/echar4/datalayer/repos/jupyterlab-extension-examples/3a_widgets
        3b_datagrid: /Users/echar4/datalayer/repos/jupyterlab-extension-examples/3b_datagrid
        4a_kernel_output: /Users/echar4/datalayer/repos/jupyterlab-extension-examples/4a_kernel_output
        4b_jupyterwidgets: /Users/echar4/datalayer/repos/jupyterlab-extension-examples/4b_jupyterwidgets
        5_signals_and_buttons: /Users/echar4/datalayer/repos/jupyterlab-extension-examples/5_signals_and_buttons

Versions in root README.md should also be updated.

For now I've been installing the extensions one by one with jupyter labextension install <folder> --debug, and this is what I have:
$ jupyter labextension list
JupyterLab v1.2.1
Known labextensions:
   app dir: /home/jtp/miniconda/envs/jupyterlab-extension-tutorial/share/jupyter/lab
        1_hello_world v0.1.0  enabled  OK*
        2_commands_and_menus v0.1.0  enabled  OK*
        3a_widgets v0.1.0  enabled  OK*
        3b_datagrid v0.1.0  enabled  OK*
        4a_kernel_output v0.1.0  enabled  OK*
        4b_jupyterwidgets v0.1.0  enabled  OK*
        5_signals_and_buttons v0.1.0  enabled  OK*
        6_kernel_messaging v0.1.0  enabled  OK*

   local extensions:
        1_hello_world: /home/jtp/git/jtpio/jupyterlab-extension-tutorial/1_hello_world
        2_commands_and_menus: /home/jtp/git/jtpio/jupyterlab-extension-tutorial/2_commands_and_menus
        3a_widgets: /home/jtp/git/jtpio/jupyterlab-extension-tutorial/3a_widgets
        3b_datagrid: /home/jtp/git/jtpio/jupyterlab-extension-tutorial/3b_datagrid
        4a_kernel_output: /home/jtp/git/jtpio/jupyterlab-extension-tutorial/4a_kernel_output
        4b_jupyterwidgets: /home/jtp/git/jtpio/jupyterlab-extension-tutorial/4b_jupyterwidgets
        5_signals_and_buttons: /home/jtp/git/jtpio/jupyterlab-extension-tutorial/5_signals_and_buttons
        6_kernel_messaging: /home/jtp/git/jtpio/jupyterlab-extension-tutorial/6_kernel_messaging

so far so good. I checked the log and it returned a linked package because it does not have extension metadata:   Missing extension module "lib/index.js"
Indeed I have not built the folder example 2 to 5. When I build, I have them listed. Tested extension 2 and it works fine.
LGTM


colorize build trace output based on predefined regex expressions

It would be extremely helpful if gitlab could colorize the console output based on a set of regular expressions, so that we could make colors red, warnings orange, make debug lines dimmed, ...
While some people may want to be able to overwrite these from the .gitlab-ci.yaml file, this feature should be under the control of the the instance, where admins could define new regular expressions.
A good example of similar feature is implemented into the famous OS X terminal: iTerm2 and here is an example:

It's better to have tools that output colorised output instead.

+1

+1
Love it!

We are currently in the process of closing down the issue tracker on GitHub, to prevent duplication with the GitLab.com issue tracker. Since this is an older issue I'll be closing this for now. If you think this is still an issue I encourage you to open it on the GitLab.com issue tracker.


Palette Lighting API

As mentioned in other issues (such as #20), the Dreamcast mods would benefit greatly from an API allowing them to control palette selection and lighting parameters manually. With this issue, I intend to outline all the functionality required by such an API to determine feasibility and implementation method.
So far, we know that the following would be a great help (if I've forgotten anything, let me know @PiKeyAr):

[x] LandTable specular toggle (see #20)
[x] Palette selection (expose LanternInstance::SetPalettes)
[x] Separately-addressable palette selections (implement and expose LanternInstance::SetDiffuse and LanternInstance::SetSpecular)

As a bonus, the following would be nice for otherwise custom palette handling by misc. mods:

[x] Palette file overrides (provide a callback interface so that a mod can indicate that it has a suitable replacement)
[x] Expose d3d::SetShaderOptions for toggling fog, lighting, alpha, blending, etc.
[ ] Implement explicit multi-palette support (e.g. Sky Deck multi-palette)

Some more ideas from @PiKeyAr:

[x] Possibility to blend between diffuse A/specular B and diffuse A2/specular B2 without touching other palettes
[x] A "disable built-in vertex colors" switch for objects described in #50. This isn't material-specific though... Basically anything that loads a non-level PVM/texlist has all its vcolors nullified if this is on.
[x] A "force default material color" switch. Basically set the material's R G B to B2 if this is enabled. Or better yet, have this on by default and have a "use built-in material color" flag for special cases.
[x] Parse only the first material in the model to determine whether the model ignores specular.
[x] Parse specular color 0x00000000 as "ignore specular".
[x] The "environment mapping on -> force object specular" condition is only getting in the way of accuracy at this point, and I suggest removing it or making it optional (disabled when the landtable specular switch is on).
[x] White diffuse+specular (currently implemented via manual palette selection, sometimes with modified PL files)
[x] If a material doesn't have the "use texture" flag, it doesn't get specular applied.
[x] Material overrides that persist across PL file changes (Sky Deck)
[x] Expose the alpha rejection value so that a mod could change it in real time
[x] Light direction override
[x] Palette override that works similarly to set_diffuse/set_specular but replaces the entire diffuse/specular palette with a specified color
[x] Blending between a palette and a specified color
[x] Adding a specific color on top of an existing palette? (Egg Viper)

Will palette selection allow me to hijack any material?
I was thinking of something like this: one bit in the unused material flags is picked up to tell whether custom palette selection is enabled or not. If it is, have the mod check a custom array that contains the materials and palette indices they need to use.
If the above is not possible, I guess we need to go back to the idea of using the unused material flags to indicate the palette pair number or something like that.

Honestly, that could work. We could even take it a step further. For example, a single unused bit in the material flags could indicate that a callback is to be run, so all mods that registered a callback have a say in what to do with that material. It would be first come first serve though; the first to say "I got this, don't ask those other guys" gets to control the outcome.

Some more ideas:

A "disable built-in vertex colors" switch for objects described in #50. This isn't material-specific though... Basically anything that loads a non-level PVM/texlist has all its vcolors nullified if this is on.

As far as the actual API implementation goes, I will use any system you come up with, but as an end user right now I see the following:

On a mod's end, a function called inside an init function that adds a specific material to an array that later gets processed by the PL mod. Something like
AddSpecialMaterial(matlist_xxxx, base_palette_number, specular_palette_number, fallback_specular_palette_number_for_ignore_specular_flag, other_flag_1, other_flag_2);
OR
An array of materials/material arrays (the latter would be better) defined in a mod with the flags/parameters like above

As for some new flags that may be useful:

A "force default material color" switch. Basically set the material's R G B to B2 if this is enabled. Or better yet, have this on by default and have a "use built-in material color" flag for special cases.
This is somewhat tangential to what you're doing, but a way to customize the transformation values used for environment maps would be an excellent addition to this API.

So after using this system for a while I'm very happy with the way it works. I think it can be used to make SADX a lot more accurate to the original game lighting-wise. There are only a few more things I wish I could do with it:

[ ] Some way to control the base palette's alpha component in the same function that sets palette indices. Would help with stuff like #51.
[ ] Something similar to the above but for specular. Maybe a way to make specular darker? For cases like these:

Even though it's the same palette, you can see the difference in how specular is applied. I'm not entirely sure how this is achieved in the original engine but I think it can be made to look very similar by just making the specular color darker.

OK, this is what it looks like when the base palette is entirely white:

So I guess I need a flag to ignore base lighting but add specular?

So the first material thing works for the most part, and only some objects need manual fixing. However, I found another thing that could help accuracy: apparently if the "ignore specular" is off but the specular color is 0x00000000 it has the same effect as ignore specular. This explains why the trees and boxes in Red Mountain are off.

Another thing: the Sweep badnik (sonic.exe 034D0CF0) has ignore specular in all its materials but it appears to be using the object specular. I can force level specular on it but it might be worth looking into just to ensure the material thing is being applied correctly.

Fixed: no texture (rhino tank etc), sweep, and material specular alpha functioning as ignore specular.

I've updated the checklist to include explicit multi-palette support. This would enable specific effects like the fading used in Sky Deck to mod developers. It will be a challenge to implement, but it would be very beneficial for Dreamcast mod accuracy and coolness factor. It would also help with material callbacks and such. As it stands now, Sky Deck tends to override changes made using the material callback system due to its multi-palette nature.

I've partially figured out how the game determines whether a material has forced white diffuse.
It's absolutely related to the "ignore light" flag. Case in point: Egg Carrier model in Sky Chase 1. All objects with white diffuse that are part of that model follow this rule: if there's a material with "ignore light", all materials after it (only after, not before) have forced white diffuse. Another example is the palm trees near Tails' house. The trunks have white diffuse because their material is listed after the leaves, which ignore lighting.
There are likely more conditions involved in this, because in Final Egg there is a model with several materials ignoring lighting, but white diffuse is forced only after the last one.

I've been running into a minor issue, but it's been pretty consistent so I thought I should report it. If an object is replaced in the mod like this:
*(NJS_OBJECT *)0xwhatever = object_whatever;
Then object_whatever's materials are parsed independently and the first material specular thing doesn't work with it.

That's an interesting bug. It shouldn't change anything as long as the pointers to the materials are the same as the ones referenced by the models used in that object.

Hmm.. It also looks like the landtable specular switch doesn't apply to objects in landtable animlists. They have level specular even though they don't have the ignore specular flag.

A few other things to consider...

[ ] A selectable white diffuse palette that can be set regardless of which PL file is loaded - this will help streamline things a lot, because at the moment one has to load modified PL files for cases when the PL file doesn't have a white diffuse palette
[ ] Ability to include or exclude materials for blend transitions (like have control which models fade or don't fade between two palettes in Past 3)
[ ] Material overrides that work regardless of PL file changes (Sky Deck)

Don't know whether it's possible to "fix", but I can't seem to get the material hooks to work with the hint monitor. I think this is because the hint monitor does some AllocateMemory and qmemcpy stuff (like in sub_7A91B0) and copies the model to a new place rather than renders it directly, so I can't reference the "new" materials in the copied model.
Is there any workaround for this?

Arbitrary palette index blending has been implemented. I'm considering the api stable enough to use, so I've merged it into master. After the next stable release, I'd like to implement explicit multi-palette management (e.g Sky Deck), and allow greater than 2 palettes for blending which would be addressable by using blend factors greater than 1.0f (Pretty straightforward, right?). At that point I'll consider it feature complete, ignoring of course the addition of overrides required for the accuracy of other Dreamcast mods.

A couple of new requests:

Palette override that works similarly to set_diffuse/set_specular but replaces the entire diffuse/specular palette with a specified color - would allow to fake SA_ONE blending by calculating fog color in a specific spot and adding it as specular color
Blending between a palette and a specified color - would allow to get rid of custom PL files entirely for such effects as Casino pinball room entry, dark room at the start of Froggy hunt cutscene, Egg Viper explosions.
Light direction override - would allow to fake the SL Lights system.

Re: White diffuse, I've almost figured out when it happens but at this point it looks inconsistent and honestly it's probably a fixed function pipeline bug like you said. So I'll be implementing it semi-automatically or manually for each model via the API. I don't think any other mods or vanilla SADX would benefit from white diffuse, so this "feature" of the original lighting system doesn't have to exist in this mod. I would really appreciate the function to replace a palette with a specific color though, not only for this "effect" but for other DC things, too.

I've added several new functions to the API related to replacing palettes. It should now be possible to replace a palette with a specified color, a color array, or a mix of an existing palette with a specified color.


Implementation of the composite renderer for molecules

Composite renderer is a composite of normal renderers with different types and selections. (e.g. ribbon for protein, nucl for nucleic, etc.) In this ad-hoc implementation, the composite renderer is implemented in the javascript code that sequentially create each corresponding sub-renderer. (In the future implementation, composite (or bind) renderer should be defined in the style XML files, and based on the style, we have to create each sub-renderer in the native C++ code)

Ad-hoc implementation done.


Bold doesn't work in Firefox, Heading works but not as it should

Bold doesn't work in Firefox (133.0 (64-bit) W10), it does nothing, seems to work in Chrome.
Steps for Reproduction

Load the editor in FF
Select some text
Apply bold style
Watch as nothing happens

Expected behavior: To convert the selected text to bold
Actual behavior: It does nothing
Platforms: FF 133.0 (64-bit) W10
Version: 2.0.3

If you apply any heading it does it over the whole line, not only the selected part

Steps for Reproduction

Load the editor in FF
Select some text
Apply any heading

Expected behavior: To apply the heading over the selected text
Actual behavior: Applies the heading over the whole line
Platforms: FF 133.0 (64-bit) W10
Version: 2.0.3

bro, You should have style，delete it，right


Multiple Drop-down

I have multiple  drop-downs on a page and i want to implement  required  functionality  using onlclck event. Is it possible to get back the selectedModel in event handler  so i can i check how many items are selected  in the drop-down

^ I want to implement limit functionality. (Not required functionality)

Hi @Rizwan-Qamar ,
Yes, you can use the on-item-click callback and check the input-model to see how many items are selected.


WIP: Speed up imitation learning training by allowing users to jump to a timestamp

During the training, we will replace one of the vehicles in history data with an agent. However, this agent might appear in the middle of an episode but SMARTS still step through the replay data from the beginning until the agent shows up.
In this PR, I exposed a param start_time to allow us to set the frame start time.

I don't think this is the right design. The reset(..., start_time=...) isn't actually doing what the API makes it seem. One would think it's offsetting the sim by the given start_time, but really just changing the internal clock.
This looks to be a one-off solution for the history data replay work and not useful to anything else (or applicable to anything else). Can we just offset the timestamps of the data replay data directly / modify the data replay input?

Yes, the side effect of changing the clock is hidden, I am not sure about the change of reset too. I can try your suggested approach by maintaining an offset that just applied to the history provider.

I don't think this is the right design. The reset(..., start_time=...) isn't actually doing what the API makes it seem. One would think it's offsetting the sim by the given start_time, but really just changing the internal clock.
This looks to be a one-off solution for the history data replay work and not useful to anything else (or applicable to anything else). Can we just offset the timestamps of the data replay data directly / modify the data replay input?

Yes, the side effect of changing the clock is hidden, I am not sure about the change of reset too. I can try your suggested approach by maintaining an offset that just applied to the history provider.

Underestimated the difficulty. Not only the history provider has the clock issue, but also the trap manager. The time that an agent is emitted, is specified in the mission's start time.
So two things:

the history provider needs to know the offset
mission starts at time 0 sec (Supporting multiple agent missions makes it harder :thinking: )

I will try to work towards the approach above.


Add global-hl-line-mode with dimmer with dimmer-fraction larger.

Thanks, but I don't want to use global-hl-line-mode. (Though I used it for a while many years ago.)


Clean branch flashing and wifi connection

Minor changes:

removed new_with_conn
new_with_call back could be replace by new
logging other output from MQTT (minor!)

This closes https://github.com/ferrous-systems/espressif-trainings/pull/85 and https://github.com/ferrous-systems/espressif-trainings/pull/91


CSS improvement idea.

What if you support this app also with Less of scss?
If you want i can code something out for this.

Cool. What specific improvements were you thinking of?

Just providing also less or scss for easier development

@Tjoosten happy to get that ... - we generally use less.

The problem is i"m only used to scss.

WONTFIX.


Plugin freezes Joplin

With v1.3.11, I cannot enable the plugin in Windows 11 or Arch Linux versions of Joplin or it will completely freezes joplin such that it is completely unresponsive to input. The menus will not even open.

The problem is still there with Joplin 2.10.6 (prod, darwin) without any plugins
I tested on

Windows 10 (10.0.19045)
macOS Ventura 13.0.1
Different notebooks configurations

It seems that UI freezes when I expand group of notebooks with emojis
Related issue #88

I  can expand groups of notebooks with emojis but only when the MacOS plugin is disabled

Confirmed the same behavior others are seeing. Cleared emoji's from all notebooks and was able to use the Mac OS Theme without issue. If I assign emoji's to any notebook - Joplin loads only a blank screen [1]
The only way to get it back is to go the config directory plugin's and delete the .jpl file.
[1]

Confirmed the same behavior others are seeing. Cleared emoji's from all notebooks and was able to use the Mac OS Theme without issue. If I assign emoji's to any notebook - Joplin loads only a blank screen [1]
The only way to get it back is to go the config directory plugin's and delete the .jpl file.
[1]

Same error over here, I have disabled the plugin and joplin works fine, I see it's a problem with the emojis, I could remove them but it helps me to quickly identify what's what.
Let's see if the developer can fix it soon!

It seems that setting the emojis via the "Choose emoji..." dialog triggers this issue, but adding the emojis into the text box does not.
no problem:

problem next time on startup:

Hope it gets fixed soon! :)

Maybe this is fixed in v2.11.7?
Improved: Add support for AVIF image format (#8175)
Improved: Improved word count when em-dash is used (#8083)
Improved: Updated packages aws, buildTools
Fixed: "New note" buttons so large they occlude Search (#8249) (#8159 by Rio Sinnott)
Fixed: Window is white on startup (#7484)

Maybe this is fixed in v2.11.7?
Improved: Add support for AVIF image format (#8175) Improved: Improved word count when em-dash is used (#8083) Improved: Updated packages aws, buildTools Fixed: "New note" buttons so large they occlude Search (#8249) (#8159 by Rio Sinnott) Fixed: Window is white on startup (#7484)

Version 2.11.11 has been released and the bug is still occurring, I was hopeful :(

I can confirm that @Aman-Anas solution works and I manually changed over all my notes to use emojis in the title rather than setting an emoji from Joplin's picker.

Definitely works if you do switch from using emoji icons for the notebooks (folders), to including the emoji in the title instead... but this then breaks the alphabetical sort of the notebooks, which makes it much more annoying to use, even if the theme looks a bit nicer. Frustrating.

Unfortunately, the issue persists as of version 3.0.14. This renders the theme unusable on your typical corp windows device with the current version.

@d1sc0v3r - do you have emoji's set through the New Notebook dialog? If so, there is a workaround above.


upgrade arrow to 37 and datafusion to 23

@houqp  should probably upgrade this to the latest datafusion 25 and arrow 39/40 now ?

Merged in #540


Async methods consume executor threads while idle

A quick review of the async methods seems to indicate that they just wrap the synchronous method in an executor and return the future. This results in the method requiring an executor thread for every outstanding request even if the request is waiting on I/O. This is similar to https://java.net/jira/browse/JERSEY-2058, Jersey seems to have addressed this problem via https://github.com/AsyncHttpClient/async-http-client.

We are rewriting the core of the java sdk and should have a much better solution to this in the next major release.

Hi @clarkbreyman
We just released 1.0.0-beta2 this past week and please feel free to give it a try. We have moved the async model onto the queue-based callbacks provided by Square OkHttp.
We are still looking into possibilities of moving onto Observable-based async.

Thanks for the ping - I'll take a look.

In latest master we already implemented Observable-based async with RxJava. Please feel free to take a look.
Closing as this specific issue is not relevant anymore.