Why don't we do overbright like this?

AIUI overbright simply means that the lightmaps and light grid should be scaled from 0 to 4, instead of 0 to 1, so we can represent a larger range of brightness. But image colors are only allowed to go from 0 to 1. This is a big problem... if we are using GL 1 (hence, perhaps, the mysterious "hardware implementations"). But we have shaders, so all we have to do is multiply by 4 whenever we read one of those special light textures. Problem solved?
I tried this approach and it looks the same to me, consistent with the complex cancellng system that we had before. Also fixes the Perseus glass and Procyon star chart issues addressed in #1404.
An explanation for the canceling approach is given in #1050:

We cannot overBright separate stage as stage are clamped within [0.0, 1.0] when blending multiple stages together, meaning the result of the multiplication of a separate light stage with a light factor will be clamped before blending it with the color map.

But this is not an accurate representation of how shaders work. Each stage acts independently and directly on the color and depth buffers. There is no scratch area where shader stages are blended before going into the color buffer.
I would expect this to ameliorate the color banding problems with low-precision color buffers since now we don't give up 2 bits of precision to make room for canceling.
I haven't tried vertex lighting yet. Not sure how it's supposed to work with overbright.

Screenies?

I haven't tried vertex lighting yet. Not sure how it's supposed to work with overbright.

Vertex lighting seems to use inverse light factor the same way.

From a recent master, default settings:

With this PR:

I'm all in favor of a simpler implementation.
In the past I first tried what you did there, but I got bugs. Maybe they were mistakes I did?
My main concern was about surfaces where the lightmap is applied more than once (and then multiplied more than once), basically terrain blended surfaces. Fortunately with your branch those terrain blended surfaces look fine (thunder outdoor and station15 garden):

On the station15 garden, plant leaves are wrongly lit, maybe they are vertex lit.
So, here is the light sources that should be multiplied:

lightmap light
vertex light
grid light
white fullbright light WHEN the lightmode is not fullbright

> - white fullbright light WHEN the lightmode is not fullbright

Doing this properly is one of the fix from #1404 (the starchart issue) and it should be done in all implementations.

On my end when I first tried your approach, I was having such places reproducing the same clamping as we get whih the legacy clamped overbright:

But as you see in this screenshot, your branch doesn't reproduce the clamping. That clamping in GLSL was also what prompted me to follow a more complex route to avoid that clamping.
I don't know why I got any clamping in the past even when doing overbright in GLSL that way. The GLSL code received heavy rewrites, maybe we fixed some bugs in the meantime?

So, here are the light sources that should be multiplied:
* lightmap light

* vertex light

* grid light

* white fullbright light WHEN the lightmode is not fullbright

Lightmap and grid light are what is implemented in the initial draft of this PR. I don't think the last case exists for the simplified approach; it sounds like a problem of canceling.
Vertex light is a tiny bit more complex than the other cases since everything has the vertex color attributes, not only things with precomputed lighting. Maybe I can check tess.bspSurface and scale u_ColorModulate by 4 if is true.

Here is an example of GLSL overbrigth clamping when I first applied the overbright on light per stage instead of screen:

I don't get why I got it and you're not getting it, but if we're not getting it with the per-light approach, that's great!

I don't think the last case exists for the simplified approach; it sounds like a problem of canceling.

Probably not, the fullbright light mode is to just apply a white lightmap, so it's just using the lightmap code. Maybe there is nothing to do.
Though, we must make sure the (multiplied) vertex light code doesn't multiple the (multiplied) white lightmap fallback.

I reproduce the clamped overbright with that GLSL implementation, now I remember when it's happening.
The clamped overbright happens with such GLSL implementation when the lightmap is blended as a separate stage (i.e. no collapsing is doable), when the engine processes a lightmap stage over a colormap stage (or the colormap stage over a lightmap stage), instead of a singe diffusemap stage:
This:
stage colormap
stage lightmap

Or this:
stage lightmap
stage colormap

Instead of:
stage diffusemap

Here is an example with a build of the pulse map attached (the one hosted on sweet folder has broken lightstyles so it doesn't reproduce the light clamping bug):
The master branch:

This branch:

File: map-pulse_0-20230207-114641-e9a0a5e.dpk.zip
I guess I don't reproduce the bug with plat23 anymore because I improved the collapse code and we now collapse more materials, getting them processed as a single diffusemap stage instead of separate colormap + lightmap stages.

To make it more obvious, the problem is where the red arrows are pointing at:

So I actually reproduce the bug with a released Tremulous map that is the original map build by the original author (only repackaged, not rebuilt):
Map: https://users.unvanquished.net/~sweet/pkg/map-metro-b1-2_0%2B0.dpk
viewpos: 2123 -231 -166 -89 26
With master:

With this branch:

Interestingly, your branch fixes the (what is assumed to be a) floating light shader that should not be visible:
Map: https://users.unvanquished.net/~sweet/pkg/map-metro-b1-2_0%2B0.dpk
viewpos; 2267 -429 -223 -51 -19
branch master or illwieckz/obb:

branch slipher/overbright-simple:

So basically, I'm all in favor of investing this more and if we can make it handle light styles properly, let's do it.
But for the 0.55.1 release we better merge my fix, we'll have all the time to investigate a different implementation after that.

I looked at the Metro light style shaders. So apparently it builds a composite lightmap in the color buffer from 4 additive stages, then does a standard multiplicative blend with the diffusemap in the final stage.
I guess we could keep the cancellation approach for light styles only. There is already detection and special handling for light styles anyway.

I guess we could keep the cancellation approach for light styles only. There is already detection and special handling for light styles anyway.

If that's doable that would be awesome! I dislike the cancelling-everywhere approach a lot (it's very fragile because of the very large amounts of uses case…).

So, here are the light sources that should be multiplied:

lightmap light
vertex light
grid light
white fullbright light WHEN the lightmode is not fullbright

Lightmap and grid light are what is implemented in the initial draft of this PR. I don't think the last case exists for the simplified approach; it sounds like a problem of canceling.
Vertex light is a tiny bit more complex than the other cases since everything has the vertex color attributes, not only things with precomputed lighting. Maybe I can check tess.bspSurface and scale u_ColorModulate by 4 if is true.

Vertex lighting is multiplied with the diffuse colours, so multiplying it by 4 again would be wrong.
Although on master vertex lighting is also somewhat broken with overbright: e. g. on map railgun from Wolf:ET the icicles are almost completely black without overbright clamping, owing to the fact that they're entirely vertex-lit. Perhaps there needs to be a check for surfaces that use only vertex lighting, which would then be multiplied or whatever. That shouldn't be done in tess however, just multiply the vertex colours themselves instead.

Although on master vertex lighting is also somewhat broken with overbright: e. g. on map railgun from Wolf:ET the icicles are almost completely black without overbright clamping

Probably the same bug as the procyon hologram?

Although on master vertex lighting is also somewhat broken with overbright: e. g. on map railgun from Wolf:ET the icicles are almost completely black without overbright clamping

Probably the same bug as the procyon hologram?

I doubt it, the procyon one has a lightmap.

Besides canceling, another possible approach to light styles would be using multiple collapse lightmap stages with additive blending, and disable dynamic lights in all but one.

disable dynamic lights in all but one.

I guess it is already the case, at least with the tiled renderer: light styles light map are expected to be rendered with Renger_generic3D and not with Render_lightMapping as far as I know.

multiple collapse lightmap

Actually I don't see how that would works? to collapse lightmaps with what?

This may be theoretical, but we may not exclude that some non-lightstyle lightmaps rendered with the lightMapping stage get blended like the light style ones and reproduce the bugs that happens with light styles.
It's just that the collapsing has been well improved so standalone non-light-style lightmap stages are more rare nowadays, but it is not guaranteed we collapse all of them or that we even can collapse all of them.

@slipher do you have any understanding about how the light style lightmap blending is working and then how we may workaround the related bugs?
Actually we may workaround some wrongness by normalizing to 1 at the end of the GLSL shader, to avoid bad colors popping up there and there. But that will still clamp them (it would still be better than the legacy lightmap shift that is not actually clamping but turns 75%s of the data into garbage).

I added a commit to multiply the light factor instead of dividing the inverse light factor, that also cleaned-up code, so it helps to have a better look at things.

Interestingly, your branch fixes the (what is assumed to be a) floating light shader that should not be visible:
Map: https://users.unvanquished.net/~sweet/pkg/map-metro-b1-2_0%2B0.dpk
viewpos; 2267 -429 -223 -51 -19
branch master or illwieckz/obb:

branch slipher/overbright-simple:

The metro map is the only map known to reproduce this floating transparent surface bug, so it's low priority, but anything helping to pinpoint what is happening is welcome.

I'm guessing it's the weird square on the wall that is the issue, right?

I'm guessing it's the weird square on the wall that is the issue, right?

For the “floating light shader”, yes.

I rebased on current master, fixed some merge conflict, and cleaned-up more cancelling leftovers.
@VReaperV I would love if you could look at that broken light style at said position in map with your magical tools and if you can actually describe what's going on and what could explain the light being that bad.
Maybe light styles are the only things that require a workaround when we multiply the lightmap directly in color/lightmapping shader.

I rebased on current master, fixed some merge conflict, and cleaned-up more cancelling leftovers.

@illwieckz I would suggest getting rid of your commit fixup: only multiply generic3D with light factor if it's a light style lightmap. This means treating the affected light map like as if overbright bits were configured to 0 (instead of 2).

I rebased on current master, fixed some merge conflict, and cleaned-up more cancelling leftovers.
@VReaperV I would love if you could look at that broken light style at said position in map with your magical tools and if you can actually describe what's going on and what could explain the light being that bad.
Maybe light styles are the only things that require a workaround when we multiply the lightmap directly in color/lightmapping shader.

Apparently it's some surface that has white image as both diffuse and lightmap, and is rendered using the lightMapping shader. It's also vertex-lit. On master at least, that is.

I rebased on current master, fixed some merge conflict, and cleaned-up more cancelling leftovers.
@VReaperV I would love if you could look at that broken light style at said position in map with your magical tools and if you can actually describe what's going on and what could explain the light being that bad.
Maybe light styles are the only things that require a workaround when we multiply the lightmap directly in color/lightmapping shader.

So the reason it doesn't show up on this branch is because the surface is rendered with blendfunc GL_DST_COLOR , GL_ZERO and GL_FUNC_ADD, and this branch produces a completely white fragment, while master doesn't.
The "before" value is essentially multiplied with the fragment value:
On master:

On this branch:

While on master u_InverseLightFactor is set to -0.25 for this surface, which means it's not used and the fragment essentially gets the vertex colours, this branch sets u_LightFactor to 4.0 for this surface, and then the lightmap colour is multiplied by it, resulting in light colour of {4.0, 4.0, 4.0, 1.0}, which is then multiplied with the vertex colours, which in turn is enough to create a {1.0, 1.0, 1.0, 1.0} fragment.

So the reason it doesn't show up on this branch is because the surface is rendered with blendfunc GL_DST_COLOR , GL_ZERO and GL_FUNC_ADD, and this branch produces a completely white fragment, while master doesn't.

Hmm, is this an explanation for why the square light emitting shader is displayed with master branch?

I was looking for an explanation for why the light style is broken with this branch, so that weirdly colored halo on the wall:

I suspect some kind of clamping.

Hmm, is this an explanation for why the square light emitting shader is displayed with master branch?

Yep.

I was looking for an explanation for why the light style is broken with this branch, so that weirdly colored halo on the wall:

...oh. I didn't realise that was the issue lol.

That thread was a big confusing I agree. 😄
Before comment https://github.com/DaemonEngine/Daemon/pull/1406#issuecomment-2454011193 I was talking about the light emitting shader, but starting with that one I was talking about light styles. 🙂

🤔

That looks more like overdark to me.

Dark map on material system fixed.
Trying a new approach where we configure the FBO to allow colors greater than 1. This also has side effects though...

Given that u_LightFactor is only used for lightmap and lightgrid, can't we just multiply those and avoid the shader hack altogether?

Given that u_LightFactor is only used for lightmap and lightgrid, can't we just multiply those and avoid the shader hack altogether?

This is the original implementation making it clamped…

Given that u_LightFactor is only used for lightmap and lightgrid, can't we just multiply those and avoid the shader hack altogether?

This is the original implementation making it clamped…
Edit: lightmap, lightgrid, and vertex color.

We could try using a different image format there.

I added two changes:

Also multiply the lightmaps used in light style.
Do not multiply fullbright light, I first believed this should also be multiplied, but it was not the case before.

The second change fixes the procyon hologram:

The metro visible “visible light emitting shader” is a tricky one.
As a remind, the lantern, the candle, etc. come with some shaders having a single stage like this:
	{
		map $lightmap
		blendfunc filter
	}

So we get floating lightmaps multiplied over whatever is behind.
I even don't know why it worked on Tremulous…
Maybe we can just strip them out…

I added a commit to fix the lantern/candle. I assume it's a shader bug, it doesn't make sense. That patch has nothing to do with overbright and could be done in another PR if we wanted to.

I don't see any bugs anymore, in all maps I've tested (metro, procyon, pulse…)

So, I noticed there was something still wrong with leaves in station15 garden.
Here is 0.54.1, the leaves on the floor are correct:

Here is this branch before we only multiplied light style/light map/diffuse map stages, the leaves on the floor are too dark:

HEre is this branch when I multiplied all colormaps (which is wrong), just to verify something, the leaves on the floor are correct, but the ones in tree are too bright:

Here is once I added the patch multiplying color map with lightFactor when rgbGen is vertex:

So here is an example of such leaf-on-the-ground shader:
textures/station15_custom/leave02d
{
	qer_editorImage textures/station15_custom_src/leave02d_d
	qer_alphaFunc greater .5

	q3map_cloneShader textures/station15_custom/leave02d_back
	q3map_vertexScale 1.5

	surfaceparm alphashadow
	surfaceparm trans
	surfaceparm nonsolid
	surfaceparm nomarks

	{
		map textures/station15_custom_src/leave02d_d
		rgbGen vertex
		depthWrite
		alphaFunc GE128
	}
}

Such shader doesn't have a lightmap, so it's processed as a generic shader.
But the colormap is blended with rgbGen vertex meaning it's multiplied with the vertex light.
So this is an old trick to do single-stage vertex-based lighting.
And indeed the old overbright code was multiplying vertex colors at map load.
So we need to multiply the vertex color like if it is a light.
I don't know yet why the foam is too bright, though.

I guess we should do something when using rgbgen oneMinusVertex because the vertex light was multiplied too before.

Here is the foam shader:
gfx/station15/haze
{
	entityMergable
	cull none
	{
		map gfx/station15/water_haze
		blendFunc blend
		rgbGen vertex
		alphaGen vertex
	}
}

I don't know what to do to fix it.

I guess we should do something when using rgbGen oneMinusVertex because the vertex light was multiplied too before.
But I don't know what to do in such case.

I haven't found a single occurrence of rgbGen oneMinusVertex in the whole betaserv dump.
There are some alphGen oneMinusVertex in some maps like transit, but I can't find usage of oneMinusVertex with rgbGen.

Maybe the haze always have been too bright but clamping hidden the bug.

If I remove rgbgen vertex from the haze shader, it looks correct:

So I guess the previous clamped overbright just set the vertex color to {1, 1, 1}, making the texture fullbright, but that was wrong.

It is possible to precompute the per-stage light factor at map loading time, but that would require to rewrite some of the BSP loading code (most shaders are loaded before the global light factor is known, and there are some tricky chicken-and-egg problem to solve).

The haze effect is not a map surface, it's a particle emitted surface, so I guess it has no vertex color, and we may work this around.

The haze effect is not a map surface, it's a particle emitted surface, so I guess it has no vertex color, and we may work this around.

Now done:

In fact such surface should better be collapsed as a diffuse map with vertex lighting, so they can also receive dynamic lights.
They are meant to receive light, it's just a trick to use vertex light explicitely instead of a lightmap, and the light map code already calls functions like isExplicitelyVertexLitSurface().
Such collapse is to be postponed for the future.

I added a commit to add gl_generic3DShader, this way every call of gl_genericShader don't need to receive any lightFactor (it no need to spam all the debug code to set it to 1). I have not stripped gl_genericShader from all the macros that are now useless, but we can do it.

Once material system is fixed, this will be ready to merge.

@VReaperV I reported the changes to the material system, but I probably did a stupid mistake somewhere as most textures are black, can you look at it?

Yeah, will do in a bit.

I'll check now if fixing the above makes it work with material system.

@illwieckz I'm not getting any black textures:

Can you confirm if the issue is still there on your end?

Why the change to have 3 generic shaders instead of 2?

To avoid the need of calling SetUniform_InverseLightFactor( 1.0 ) on every function using the generic shader (like debug tools), and the risk of forgetting about it.

Can you confirm if the issue is still there on your end?

I'll test this after sleeping. 🙂

I'd like to avoid adding u_LightFactor to the generic shader at all. I think we can do it via u_Color instead. We can add a flag to make Tess_ComputeColor scale by the light factor. I'll try this later.

I still have one bug with the material system, off:

on:

You'll see the plants are too bright.
(Don't mind if the floor and the trees look a bit different than stock map, I'm also experimenting other things with the map, but those plants are not modified).

It's because the vertex colour attribute is disabled. I'll look at why that happens.

I still have one bug with the material system, off:

on:

You'll see the plants are too bright.
(Don't mind if the floor and the trees look a bit different than stock map, I'm also experimenting other things with the map, but those plants are not modified).

Fixed now.

Since I only did a small change here and the pool of people who can review this isn't much larger than this pr's contributors, I took the liberty of reviewing it, especially as I reviewed most of it earlier anyway.

I squashed the “fixup” commits.
This looks ready to me.
There are some improvements that may be doable:

setting per-stage lightFactor at shader load time (this requires to rewrite some BSP loading code),
pre-multiplying lightFactor with u_Color to not have to pass it to GLSL (this may benefit from the former),
turn colormap stage with vertex color blending to a diffusemap one when the shader has no “nolightmap” keyword (so it can also receive dynamic light).

But that can be done in the future in subsequent PRs.

I moved the fix for the metro lanterns here:

https://github.com/DaemonEngine/Daemon/pull/1426

I also renamed the PR to fit what it does, as it is now in good shape for merging and we will going to do things that way.

Please remember that according to our PR etiquette, no one should merge another person's PR :)

I've now reimplemented the three special cases treated by illwieckz in way that avoids adding u_LightFactor to the generic shader. Those fixes are separated into a temporary fixup commit for convenient reading.
Let us call BASE the source tree obtained from merging #1426, #1431 and #1434 into master. Let us call SIMPLE this PR's tree, the slipher/overbright/simple branch (which incorporates the three aforementioned PRs). To verify the changes I have, using the scenes listed here, done a four-way comparison of BASE with all default settings, BASE with material system, SIMPLE with all default settings, and SIMPLE with material system. (Please suggest more scenes!)
Some bugs fixed by these overbright changes
Non-lightmapped vertex-lit surface not overbright scaled (station15 462 -1428 -114 178 -8)
BASE

SIMPLE

Improperly scaled 'glow map' (zittrig-arena 1201 -301 -338 87 0)
BASE ( + material system)

SIMPLE ( + material system)

Procyon star chart darkened with material system
BASE + material system

SIMPLE + material system

Consequences for framebuffers with only 1 byte of color
In some cases things are worse because of clamping in the color buffer that wasn't there before. In some cases things are a bit better because of the effective increased precision. It may be preferable to enable overbright clamping on low-end systems that don't have 16-bit float framebuffers.
Color clamping regression - Pulse 4822 -1312 -1314 98 13
BASE + r_highPrecisionRendering 0

SIMPLE + r_highPrecisionRendering 0

Decreased noise in dark area - Procyon -955 3443 276 94 7
BASE + r_highPrecisionRendering 0

SIMPLE + r_highPrecisionRendering 0


fix(e2e-nightwatch): fix eslint config generation

What kind of change does this PR introduce? (check at least one)

[x] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Docs
[ ] Underlying tools
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

Other information:
Commit 1b64ff8464c317f8d5616626bf483f582c2e01c3 introduced a nested if in _eslintrc.js with the same condition than the wrapping one. I may be missing something really obvious, but I think it was meant to check for TS instead.

😅Ahh you are right. Thanks!


Update layout.html.twig

There is an error with absolute path when using https hosting.

This is a read only repository.
Pull Request should be send to https://github.com/symfony/symfony.
After the merge in the main repository, a sub-tree of split is done and this repository is updated.


Flutter Web 3.10, tree shake still causing exception (fail)

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce

Upgraded to Flutter 3.10
exec flutter build web --web-renderer canvaskit

Expected results
it should build Flutter Web app.
According to the 3.10 release notes, Flutter Web should support tree shake.
Actual results
compile failed.
Here is the log:
Font asset "icomoon.ttf" was tree-shaken, reducing it from 1128 to 696 bytes (38.3% reduction). Tree-shaking can be disabled by providing the
--no-tree-shake-icons flag when building your app.
Font asset "CupertinoIcons.ttf" was tree-shaken, reducing it from 283452 to 1472 bytes (99.5% reduction). Tree-shaking can be disabled by
providing the --no-tree-shake-icons flag when building your app.
Font asset "AntDesign.ttf" was tree-shaken, reducing it from 70344 to 61444 bytes (12.7% reduction). Tree-shaking can be disabled by providing
the --no-tree-shake-icons flag when building your app.
Font asset "Entypo.ttf" was tree-shaken, reducing it from 66200 to 59840 bytes (9.6% reduction). Tree-shaking can be disabled by providing the
--no-tree-shake-icons flag when building your app.
Font asset "EvilIcons.ttf" was tree-shaken, reducing it from 13456 to 11752 bytes (12.7% reduction). Tree-shaking can be disabled by providing
the --no-tree-shake-icons flag when building your app.
Font asset "FontAwesome.ttf" was tree-shaken, reducing it from 165548 to 156252 bytes (5.6% reduction). Tree-shaking can be disabled by
providing the --no-tree-shake-icons flag when building your app.
Font asset "Feather.ttf" was tree-shaken, reducing it from 56228 to 52096 bytes (7.3% reduction). Tree-shaking can be disabled by providing
the --no-tree-shake-icons flag when building your app.
Font asset "Fontisto.ttf" was tree-shaken, reducing it from 313528 to 311148 bytes (0.8% reduction). Tree-shaking can be disabled by providing
the --no-tree-shake-icons flag when building your app.
Font asset "Foundation.ttf" was tree-shaken, reducing it from 56976 to 53220 bytes (6.6% reduction). Tree-shaking can be disabled by providing
the --no-tree-shake-icons flag when building your app.
Font asset "Ionicons.ttf" was tree-shaken, reducing it from 247192 to 224468 bytes (9.2% reduction). Tree-shaking can be disabled by providing
the --no-tree-shake-icons flag when building your app.
Font asset "MaterialIcons.ttf" was tree-shaken, reducing it from 230384 to 186436 bytes (19.1% reduction). Tree-shaking can be disabled by
providing the --no-tree-shake-icons flag when building your app.
Font asset "Octicons.ttf" was tree-shaken, reducing it from 49404 to 45600 bytes (7.7% reduction). Tree-shaking can be disabled by providing
the --no-tree-shake-icons flag when building your app.
Font asset "SimpleLineIcons.ttf" was tree-shaken, reducing it from 54056 to 51000 bytes (5.7% reduction). Tree-shaking can be disabled by
providing the --no-tree-shake-icons flag when building your app.
Font asset "Zocial.ttf" was tree-shaken, reducing it from 25788 to 23996 bytes (6.9% reduction). Tree-shaking can be disabled by providing the
--no-tree-shake-icons flag when building your app.
Font asset "fa-brands-400.ttf" was tree-shaken, reducing it from 187448 to 169440 bytes (9.6% reduction). Tree-shaking can be disabled by
providing the --no-tree-shake-icons flag when building your app.
Font asset "fa-regular-400.ttf" was tree-shaken, reducing it from 63728 to 48796 bytes (23.4% reduction). Tree-shaking can be disabled by
providing the --no-tree-shake-icons flag when building your app.
Font asset "fa-solid-900.ttf" was tree-shaken, reducing it from 394832 to 357436 bytes (9.5% reduction). Tree-shaking can be disabled by
providing the --no-tree-shake-icons flag when building your app.
Font asset "MaterialIcons-Regular.otf" was tree-shaken, reducing it from 1645184 to 10784 bytes (99.3% reduction). Tree-shaking can be
disabled by providing the --no-tree-shake-icons flag when building your app.
Codepoint 62694 not found in font, aborting.

Codepoint 62694 not found in font, aborting.

Codepoint 62694 not found in font, aborting.

Codepoint 63116 not found in font, aborting.

Target web_release_bundle failed: IconTreeShakerException: Font subsetting failed with exit code 255.

To disable icon tree shaking, pass --no-tree-shake-icons to the requested flutter build command
#0      IconTreeShaker.subsetFont (package:flutter_tools/src/build_system/targets/icon_tree_shaker.dart:208:7)
<asynchronous suspension>
#1      copyAssets.<anonymous closure> (package:flutter_tools/src/build_system/targets/assets.dart:127:25)
<asynchronous suspension>
#2      Future.wait.<anonymous closure> (dart:async/future.dart:525:21)
<asynchronous suspension>
#3      copyAssets (package:flutter_tools/src/build_system/targets/assets.dart:105:3)
<asynchronous suspension>
#4      WebReleaseBundle.build (package:flutter_tools/src/build_system/targets/web.dart:385:29)
<asynchronous suspension>
#5      _BuildInstance._invokeInternal (package:flutter_tools/src/build_system/build_system.dart:847:9)
<asynchronous suspension>
#6      Future.wait.<anonymous closure> (dart:async/future.dart:525:21)
<asynchronous suspension>
#7      _BuildInstance.invokeTarget (package:flutter_tools/src/build_system/build_system.dart:785:32)
<asynchronous suspension>
#8      FlutterBuildSystem.build (package:flutter_tools/src/build_system/build_system.dart:614:16)
<asynchronous suspension>
#9      WebBuilder.buildWeb (package:flutter_tools/src/web/compile.dart:81:34)
<asynchronous suspension>
#10     BuildWebCommand.runCommand (package:flutter_tools/src/commands/build_web.dart:191:5)
<asynchronous suspension>
#11     FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:1336:27)
<asynchronous suspension>
#12     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#13     CommandRunner.runCommand (package:args/command_runner.dart:212:13)
<asynchronous suspension>
#14     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:296:9)
<asynchronous suspension>
#15     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#16     FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:244:5)
<asynchronous suspension>
#17     run.<anonymous closure>.<anonymous closure> (package:flutter_tools/runner.dart:91:9)
<asynchronous suspension>
#18     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:150:19)
<asynchronous suspension>
#19     main (package:flutter_tools/executable.dart:91:3)
<asynchronous suspension>

Compiling lib/main.dart for the Web...                           1,664ms
Exception: Failed to compile application for the Web.

Code sample
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
[Paste your output here]

It may be the flutter_vector_icons problem. I used icons from the icon font that don’t exist.

It looks like flutter_vector_icons' issue (please see https://github.com/pd4d10/flutter-vector-icons/issues/19).
I will close this issue since it's not Flutter framework issue. Please follow up on the issue in the dedicated repository of flutter_vector_icons for further updates.
If you also can reproduce the issue without that package, please write in the comments, providing your flutter doctor -v, your flutter run -v,  your pubspec.yaml, a completed and minimal reproducible code sample that does not use 3rd party plugins and I will reopen it for further investigation.
Thanks!


hotunplug - reverse phase1

What this PR does / why we need it:
The purpose of the PR is on hotunplug - to remove the interfaces created by phase1 (bridge, tap, dummy nic) and the caches (file and volatile).
Hotunplug is detected when the spec interfaces/networks doesn't contain a network that is stored in the configState cache.
In such case unplug phase1 will try to clean the bridge, tap, dummy nic and the caches in case they exist.
The PR doesn't include -
In case a network has caches but the preparation for some reason didn't start, hotunplug won't remove the cached since the indicator to the cleanup is that the configState is PodIfaceNetworkPreparationStarted or PodIfaceNetworkPreparationFinished.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

On hotunplug - remove bridge, tap and dummy interface from virt-launcher and the caches (file and volatile) from the node.

/test pull-kubevirt-e2e-k8s-1.26-sig-network
/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4

/test pull-kubevirt-e2e-k8s-1.26-sig-network
/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4

/test pull-kubevirt-e2e-k8s-1.26-sig-network
/test pull-kubevirt-e2e-k8s-1.26-sig-network-multus-v4

@AlonaKaplan, question about the new logic around network-setup and configState cache,
what prevents us from using the current configState.Run for unplug flow as well?
I do realize accessing the configState cache is necessary to realize which network should be unplugged,
but it seems possible to expose such function.

/lgtm

/approve
The pr was lgtmed by three network team members.

rebased
/lgtm

/retest

/cherry-pick release-1.0

/cherry-pick release-1.0


[feature]: Support for multiple PowerDNS servers

Use Case A: A user wants to be able to administer multiple PowerDNS servers from the same frontend, but the nameservers have nothing to do with each other.
Use Case B: A user wants to be able to administer multiple PowerDNS servers from one WebUI.

👍
We need it for a split-dns scenario, but basically the same the same request.  Currently we are running multiple instances of powerdns-admin.

+1 for this FR. Split-dns is usual case IMHO.

+1 for this. I have 5 different PowerDNS Authoritative Server instances. It would be very nice to manage them from one PowerDNS Admin instance.

+1 fot his, we are currently using multiple PowerDNS instance for manage a split-dns scenario but would be fantastic to use just one web portal to manage multiple PowerDNS servers

Hi guys, is there a chance to see this implemented?

+100500 Manage multiple PowerDNS servers

I don't know how it's not understood that +1's mean nothing and only cause unnesseary chatter. Just the +1 on the first message is probably enough.

Duplicate of #489
Already referenced in #1178


Fixed getStatsReport

Try to fix #422.
The current change handles the case where stats is a Map.
In Chrome Canary it is no longer the case which I haven't thought through.

Thanks for doing this, I've got a PR in the works that resolves this and the new stats types (Chrome is moving to the standardized stats and they are different) but have not been able to finish. Will merge this meanwhile.
Do note that you can use chrome://webrtc-internals as well.


Support for JSON Type Definition

@epoberezkin, you've voiced interest in implementing JSON Data Definition Format ("JDDF"), formerly known as JSL, in AJV. I'm opening this issue to track that discussion.
It seems to me that the first thing to figure out is the answer to the question:

What would JDDF support for AJV look like?

I think we should figure out the following aspects of the developer experience with using JDDF in AJV, before doing anything else, because they'll define our product requirements:

Why would someone choose to use AJV, rather than anything else, for JDDF validation? This should inform everything we do. I think the answer goes back to AJV's core values: excellent performance, excellent conformance, and easy customizability / extensions. But I'd like your take.
How do we document support for JDDF in AJV? How do make it so that users aren't confused by whether some feature is JSON Schema-only?
How would AJV know whether to use JDDF versus JSON Schema? How does the user indicate which to use?
What does writing a custom keyword look like with JDDF?
How do we leverage ajv-i18n to support JDDF? This is something that can be easier to support with JDDF -- maybe an AJV-independent package can handle this, since error messages are standardized. i18n error messages for custom keywords is trickier, though.
How do we leverage ajv-pack to support JDDF? Is this going to be hard to do?
How are features like filtering additional properties, assigning defaults, async loading and validation going to work? These features are pretty tied to particular JSON Schema features.

I'm not suggesting we need a perfect answer to all these questions. I'm saying that these questions inform our requirements. And maybe the first iteration of AJV's support for JDDF is quite limited. That's fine. But we shouldn't go headfirst into implementation if that prevents us from supporting these more advanced use-cases, or if the developer experience is bad.
Once we get better requirements here, I can convert this ticket into a checklist of things we need.

@ucarion thanks for all the questions - it is very helpful.
Firstly, support for JTD is part of the last milestone in Mozilla's MOSS grant, it is planned for Q1'21 - it will be in Ajv v8, so it's about time to answer these.

Why would someone choose to use AJV, rather than anything else, for JDDF validation? This should inform everything we do..

My primary objective is to give the existing Ajv users a choice between more complex and expressive JSON Schema, that can be used in a wider range of validation scenarios, and a simpler, more restrictive, and, as a result, less error prone JTD. An additional advantage of JTD is that is now published as RFC8927
Why would JTD users choose Ajv - thanks for the compliments about the values, rigour and performance were indeed the main things. I've just made a standalone code generation comprehensive in #1332 (it will supersede ajv-pack in v7), so the users would be able to compile JTD schemas to functions or to standalone validation code that can be used without full Ajv code. I am also considering whether to add schema-based parsers (to fail faster while parsing) - it is not decided yet, possibly next year.

How do we document support for JDDF in AJV? How do make it so that users aren't confused by whether some feature is JSON Schema-only?

The docs are restructured, so there will be a separate page jtd.md, alongside json-schema.md, that would give a brief overview of JTD validation primitives. The main page would explain how to choose the correct export to use JTD with Ajv.

How would AJV know whether to use JDDF versus JSON Schema? How does the user indicate which to use?

There are already separate Ajv classes (exports) for JSON Schema draft-07 and draft-2019-09 support, so there will be a separate export for JTD too: import Ajv from "ajv/dist/jtd"
Currently the default export points to Ajv class that supports JSON Schema draft-07, and given that it is the most widely used spec it would most likely remain the case in version 8.
All these classes use the same core class, but add different keywords (aka vocabularies) and options, so there will be a documented way to have dual support for both JSON Schema draft-07 and JTD in one Ajv instance, to simplify the migration, should the users need to do it in stages. In this case users will have an option to have a default meta-schema for JTD or for draft-07. Also, while JTD does not define meta-schema to validate its own schemas (it is not needed for most users), there will be a bundled meta-schema for JTD with some additional extension keyword (e.g. anyOf, union or something else).

What does writing a custom keyword look like with JDDF?

Ajv v7 uses the same keyword definition API for pre-defined / bundled keywords and for user-defined keywords (I removed the word "custom", as they are all the same with some small exceptions)
"vocabularies" folder here and ajv-keywords package has many different keywords, it will be the same for standard JTD keywords and for any extensions

How do we leverage ajv-i18n to support JDDF? This is something that can be easier to support with JDDF -- maybe an AJV-independent package can handle this, since error messages are standardized. i18n error messages for custom keywords is trickier, though.

I didn't yet decide how to simplify extensions inside of ajv-i18n - potentially, they will be run-time so you can add languages for each keyword you define - similar approach that is now used in Ajv for the keywords themselves. There probably will be some mechanism to extend existing keywords definitions to add new functionalities to them - this approach could be used to implement parsing code as a separate extension, so the users who don't need it won't have it in their bundle.

How do we leverage ajv-pack to support JDDF? Is this going to be hard to do?

With PR #1332 standalone code generation is now first-class (and it is not be included in the browser bundle, so the cost for the users who don't need it is negligible), so it will work with JTD schemas too, as long as all keywords provide code snippets for any shared variables they define. ajv-pack package will not be needed for ajv v7/8.

How are features like filtering additional properties, assigning defaults, async loading and validation going to work? These features are pretty tied to particular JSON Schema features.

It has to be decided on a case by case basis. If JTD has similar semantics, it can be one of these:

supported with JTD schemas
provided as extension to JTD
not supported

Specifically:

filtering additional properties - most likely can be supported
coercion - most likely can be supported
assigning defaults - could be supported as extension
async loading - this is orthogonal to the schema spec, but it would require some extension to JTD to support external IDs (which is probably needed anyway)
async validation - can be supported as extension, it is only meaningful when custom keywords are used - all predefined keywords are synchronous.

No promises that any of those will be supported in the first release of Ajv v8, but they can be added over time as there is demand.

... maybe the first iteration of AJV's support for JDDF is quite limited ...

I think it should be as comprehensive as draft-07 support, I don't have any bog concerns - the new design in v7 makes it achievable. I think it would be equally straightforward to implement any JSON based DSL - I've done it with Ajv before v7, it is much easier now.

Implemented in #1428


battery module issues

Battery not update and when i run in terminal error show below:
error: module/battery: Error while creating inotify watch (what: Failed to attach inotify watch (reason: No space left on device))
error: module/battery: Error while creating inotify watch (what: Failed to attach inotify watch (reason: No space left on device))
error: module/battery: Error while creating inotify watch (what: Failed to attach inotify watch (reason: No space left on device))
error: module/battery: Error while creating inotify watch (what: Failed to attach inotify watch (reason: No space left on device))
error: module/battery: Error while creating inotify watch (what: Failed to attach inotify watch (reason: No space left on device))

my space:
$ df -h
Filesystem              Size    Used     Avail      Use%     Mounted on
dev                          3.9G     0         3.9G        0%          /dev
run                           3.9G   1.2M      3.9G        1%         /run
/dev/sdb1                 46G    32G      12G         73%       /
tmpfs                        3.9G    237M   3.7G         7%        /dev/shm
tmpfs                        3.9G     0         3.9G          0%        /sys/fs/cgroup
tmpfs                        3.9G    2.3M    3.9G          1%       /tmp
/dev/sdb2                  92G     63G     25G         72%      /home
/dev/sda3                 732G   698G   33G          96%      /media/EXT
tmpfs                       787M    20K      787M         1%      /run/user/1000

Try to increase the inotify watch limit on your system.


Update Makefile.ubuntu

resolve issue #1

Can this please be merged in?  I tested, could duplicate the error, and confirmed that this PR fixes the issue on Ubuntu.


CUDA static linking  question with separable compilation and nvcc linking

So I this situation:
gcc 5.4.0, blt master, and cmake 3.9.2
unit_test (no cuda code) -> lib_a.a (no cuda code) -> lib_b.a (yes cuda code requires sep comp and nvcc linking)
The unit tests fail to link because gcc has no idea where __cudaRegisterLinkedBinary is.
If I turn on separable compilation and nvcc linking (adding cuda as a dep), the unit test in the example fail because nvcc fatal   : Unknown option Wl,-rpath,/some_path_to_zlib_that_spack_built`.
Any ideas?

just to check: no mfem in this case?

Yes, no mfem.

Here is a simpler example. Separable compilation and linking with cuda is on. All gtest are failing to build since nvcc does not know about pthreads.
nvcc fatal   : Unknown option 'pthread'

After some recent discoveries, this is a cmake failure. Only versions of cmake 3.13.1+ do the right thing here.


Are create_io_arrays functions still necessary?

INS has moved to Array format, so perhaps we don't have to convert anymore, we should investigate this

We do functionally change data, so the answer is: Yes, the functions are still necessary

How do we functionally change the data?


Use io.BytesIO context manager in duckdb example

Use io.BytesIO's context manager to close the buffer after using it.

Nice! I think we do something similar in a few other examples so we can fix that too

Nice! I think we do something similar in a few other examples. I can fix it. Thanks!

Great!

Thank you @vegarsti!


Transparent Background

I can't set Transparent Background to the Circular Progress Bar

This control doesn't support transparent color for anti aliasing reasons. But in WinForm, transparent is same as the background of the parent object, so you can just set it directly to the background color of the parent object.

Well I had to use it on a background with a Gradient and not solid color.
I was able to do the transparent background, by adding it to your code and compiling it. It looks and works fine, except for the fact that we can't keep both background and inner color transparent at the same time

I don't remember the details exactly but I think that it was about nonavailability of anti aliasing when clearing a part of drawing. Happens when we want to clean the inner circle before drawing more.
And as we need to draw something there to keep the background color and it wasn't acceptable to define two background property, I choose to not accept transparent at all.
http://gamedev.stackexchange.com/questions/13202/how-do-i-draw-anti-aliased-holes-in-a-bitmap

#6


Add support for component google-calendar

http://camel.apache.org/googlecalendar.html

Found 0 matching posts for subject:google-calendar in Camel - Users within 700 days


Uncaught Error: EPERM: operation not permitted, lstat '/\pmintl.net\userdata'

[Enter steps to reproduce:]

...
...

Atom: 1.19.7 x64
Electron: 1.6.9
OS: Microsoft Windows 10 Enterprise
Thrown From: fuzzy-finder package 1.5.8
Stack Trace
Uncaught Error: EPERM: operation not permitted, lstat '\pmintl.net\userdata'
At fs.js:902

Error: EPERM: operation not permitted, lstat '\\pmintl.net\userdata\'
    at fs.lstatSync (fs.js:902:18)
    at Object.fs.lstatSync (ELECTRON_ASAR.js:244:16)
    at start (fs.js:1515:10)
    at Proxy.realpathSync (fs.js:1503:3)
    at Proxy.fs.realpathSync (ELECTRON_ASAR.js:321:29)
    at ~/AppData/Local/atom/app-1.19.7/resources/app/node_modules/fuzzy-finder/lib/path-loader.js:21:27
    at Array.map (native)
    at Object.startTask (~/AppData/Local/atom/app-1.19.7/resources/app/node_modules/fuzzy-finder/lib/path-loader.js:19:52)
    at Object.startLoadPathsTask (~/AppData/Local/atom/app-1.19.7/resources/app/node_modules/fuzzy-finder/lib/main.js:119:45)
    at ~/AppData/Local/atom/app-1.19.7/resources/app/node_modules/fuzzy-finder/lib/main.js:33:30
    at _combinedTickCallback (internal/process/next_tick.js:67:7)
    at process._tickCallback (internal/process/next_tick.js:98:9)

Commands

Non-Core Packages
atom-clock 0.1.15
autocomplete-python 1.10.2
busy-signal 1.4.3
highlight-selected 0.13.1
hydrogen-launcher 1.2.1
intentions 1.1.5
linter 2.2.0
linter-python 3.1.2
linter-ui-default 1.6.8
minimap 4.29.6
pure-syntax 0.3.0
python-debugger 0.2.0
python-indent 1.1.0
python-tools 0.6.9

Thanks for taking the time to contribute!
We noticed that this is a duplicate of https://github.com/atom/fuzzy-finder/issues/289. You may want to subscribe there for updates.
Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


I want to learn this Julia calculus library

Sorry to disturb you. I want to learn your library, but when I download it locally, I can’t use it. Can you tell me how to use this library. The functions in it cannot be used. My computer is equipped with Symbolics and SymbolicsUtils. Thank you

It's not registered, so you need to do ]add https://github.com/siravan/SymbolicNumericIntegration.jl. Look at the tests for examples.

Thank you for your reply. According to what you said, the direct installation requires very complicated version restrictions, which makes me very troubled. Can I download the source code and run the code directly before using it? If so, what needs to be noted or modified. I am a beginner, sorry to disturb you

You can ]dev the package and work on the source directly. This package is not going to be streamlined enough for complete beginners: it's still in production.


Feature Suggestion: Add Prepare Attack Event

Sorry about my IntelliJ linting 🙃
Feature suggestion to fire an event before details around an attack are calculated, potentially saving time if the dev knows an attack is going to be cancelled

Can you add it to the readme as well?

Updated @TogAr2


D3D12_PSO_SUBOBJECT type list incomplete

Description
The switch statement at:
https://github.com/baldurk/renderdoc/blob/a083680b08290541e50f1c9a3c79668769f8b364/renderdoc/driver/d3d12/d3d12_common.cpp#L1022
Is missing the following entries:
    D3D12_PIPELINE_STATE_SUBOBJECT_TYPE_AS	= 24,
    D3D12_PIPELINE_STATE_SUBOBJECT_TYPE_MS	= 25,

This means that PSO streams using these types will cause RenderDoc to fail with (e.g.):
d3d12_common.cpp(1172) - Error   - Unknown subobject type 25
Steps to reproduce

In any D3D12 application, call CreatePipelineState() on a D3D12_PIPELINE_STATE_STREAM_DESC which contains either of these subobject types.
Run with RenderDoc and observe previously mentioned error.

Environment

RenderDoc version: 1.12
Operating System: Windows 10
Graphics API: Direct3D 12

Is it valid to pass those subobjects when D3D reports no mesh shading support? RenderDoc reports that, and I assumed that meant it was invalid to call any mesh shading functions or pass any mesh shading data to the API.
How do you query to know if you're running on D3D12 where mesh shading is allowed? Is there anything other than D3D12_FEATURE_D3D12_OPTIONS7?

I don't know the answer to the first question but I will try to find out. I only have hardware that supports it so haven't hit that case.
I'm using D3D12_FEATURE_D3D12_OPTIONS7 and that's the only way of querying it that I'm aware of.

When running under RenderDoc you should see that mesh shading is explicitly listed as unsupported inside the D3D12_FEATURE_D3D12_OPTIONS7. Is your code checking for that support before passing in mesh shaders?
FYI even if it is somehow valid (knowing D3D12 being consistently messy this may be the case), it's only going to mean that I print a different error message that's more specific and still fail the CreatePipelineState.

Ah sorry, I hadn't realised that running under RenderDoc would actually cause a different return value on the query. When the query returns that there is no support, the engine will not actually create any mesh shaders, the struct just still exists in the PSO_STREAM with the shader set to null.
I asked @turanszkij about this who develops the engine I am trying to run. He has used a 1070 GTX under this scheme without any issue. He also asked on the DirectX discord where a MS employee responded that they thought it should be valid if there is no output from the debug layer (there is not) and if the Windows version is recent enough to support mesh shaders. This is probably as concrete of an answer as I can find.
A more specific error message would be helpful enough I think if that seems the best solution to you - it is easy enough to elide the subobjects when support is no available :).

struct PSO_STREAM
{
	CD3DX12_PIPELINE_STATE_STREAM_ROOT_SIGNATURE pRootSignature;
	CD3DX12_PIPELINE_STATE_STREAM_VS VS;
	CD3DX12_PIPELINE_STATE_STREAM_HS HS;
	CD3DX12_PIPELINE_STATE_STREAM_DS DS;
	CD3DX12_PIPELINE_STATE_STREAM_GS GS;
	CD3DX12_PIPELINE_STATE_STREAM_PS PS;
	CD3DX12_PIPELINE_STATE_STREAM_RASTERIZER RS;
	CD3DX12_PIPELINE_STATE_STREAM_DEPTH_STENCIL DSS;
	CD3DX12_PIPELINE_STATE_STREAM_BLEND_DESC BD;
	CD3DX12_PIPELINE_STATE_STREAM_PRIMITIVE_TOPOLOGY PT;
	CD3DX12_PIPELINE_STATE_STREAM_INPUT_LAYOUT IL;
	CD3DX12_PIPELINE_STATE_STREAM_IB_STRIP_CUT_VALUE STRIP;
	CD3DX12_PIPELINE_STATE_STREAM_DEPTH_STENCIL_FORMAT DSFormat;
	CD3DX12_PIPELINE_STATE_STREAM_RENDER_TARGET_FORMATS Formats;
	CD3DX12_PIPELINE_STATE_STREAM_SAMPLE_DESC SampleDesc;
	CD3DX12_PIPELINE_STATE_STREAM_SAMPLE_MASK SampleMask;

	CD3DX12_PIPELINE_STATE_STREAM_MS MS;
	CD3DX12_PIPELINE_STATE_STREAM_AS AS;
} stream = {};

The PSO desc structure is defined at compile time in this case to allow attaching mesh shader if requested. It is null initialized by default. If there is no mesh shader support, it is still valid to create the pso with this struct. It is not valid if we initialize MS or AS fields but there is no mesh shader support. This needs driver support for this version of the API and a recent win10 version.
The workaround is to dynamically create the stream and only add the fields that are really needed. It is only a bit more inconvenient, but we can fix on our side easily.

Right, RenderDoc intercepts the D3D calls for feature support and intends to act like a driver/runtime version that does not support features like this which I don't support, even when the driver does support them.
If I understand right your code only runs on bleeding edge versions of win10 where even if the hardware doesn't support it, the runtime does support it enough to be able to parse and ignore those empty subobject fields? And it would crash/misbehave if running on another win10 version? I was wondering if there was a graceful query for that, but I guess there probably isn't.
I can definitely add support for parsing those subobjects and should be able to ignore them if they're empty at least.

Yes, in our case we rely on bleeding edge win/driver version. If I understand correctly, we can assume in this case that this is the same problem as running on outdated driver, so it's our problem to handle this correctly.

That commit should handle the subobjects and ignore the AS/MS fields if they're empty. It will also properly detect if they're non-empty and fail the pipeline create. I can't test it because I don't run a windows version that supports those subobjects so I get something familiar looking like this:
D3D12 ERROR: ID3D12Device::CreatePipelineState: Unknown Subobject Type detected in stream: UNKNOWN (25) [ STATE_CREATION ERROR #1019: CREATEPIPELINESTATE_UNKNOWN_SUBOBJECT]
D3D12 ERROR: ID3D12Device::CreatePipelineState: Stream parsing failed. [ STATE_CREATION ERROR #1021: CREATEPIPELINESTATE_INVALID_STREAM]

Thanks! I've tested it and when the MS is empty I can now run with RenderDoc fine. If the MS is non-empty I see the expected error:
RDOC 026720: [15:55:58]     d3d12_common.cpp(1184) - Error   - MS passed to D3D12_PIPELINE_STATE_STREAM_DESC but mesh shaders not supported

I currently have no plans to look at mesh shaders so I can't give a timeline of when they may be supported.
Please do not comment on old bugs that have been resolved.


[Feature] Implement deque in C++

Description
deque is a data structure in python's collections module, documented on https://docs.python.org/3/library/collections.html#collections.deque.
It is used in basic algorithms such as BFS (broad-first search).
Currently, pkpy's deque was written in pure python at here. It is not efficient enough.
Our goal
Move the implementation of deque into c++, if possible.
It is allowed to use mixed python and c++ code.

hi @blueloveTH , I find this problem can be solved.
Can I get myself assigned to it.
thankyou!

Yes, you can!

Hello, it seems you are not working on this issue by either fork/star/pr.
So I have cancelled the assignment and leave the chance to new contributors.

Hi @blueloveTH I'd love to work on this issue. Please assign me.

Hi @blueloveTH I'd love to work on this issue. Please assign me.

This task is not easy. Do you think you have enough time to get familiar with pkpy's c++ bindings?

@blueloveTH, as I already have completed my previously assigned task, I would love to work on this issue for a few days. Please let me know, if @plon-Susk7 doesn't work on this.

Hi @numan947,
You can go ahead and work on this.

Wish you good luck! @numan947
I think you can implement a LinkedList(with minimum interfaces) to builtins and wrap it as deque in python/collections.py.

The biggest problem of deque in python is its _LinkedListNode is an object. When users do BFS via deque, lots of _LinkedListNode objects will be created and destroyed. They become garbages quickly.


Add Soul wars imbues

Adds items imbued via Soul Wars to Slayer plugin, clues, and ItemMapping.
Fixes #13253

Maybe the clues and black mask item mapping should have the new imbues sorted into the existing items?
It's potentially confusing to have them listed as "slayer helmet A, slayer helmet Ai, slayer helmet B, slayer helmet Bi, [... more ...], slayer helmet Ai2, slayer helmet Bi2, [... more ...]" and could make missing helmets harder to spot.


Store the # of tabs "wrangled" over time

Show a little stats counter at the bottom of the corral?

I wanted to make this value prominent to show how much value Tab Wrangler is adding. The search input didn't need to be so wide, so I placed it next to the value:


 This is the expected behavior of the build system.

OPS Build status updates of commit 4e8507f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Skype/docfx.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Add goal package to the building procedure

The assembly:site does not trigger building, testing and packaging.
This goal should be explicitly invoked.

Commit cherry-picked.


File '/node_modules/webvtt-parser/parser.js' is not a module/Unexpected token in parser.js

Having a few issues getting up and running with the WebVTT-Parser. We are wanting to use it in a react/redux environment for live error handling when users submit VTT files (basically just like the demo but in a react/redux javascript environment instead of a hardcoded HTML environment.) Currently running into a few issues when trying to get setup with the parser. After installing via yarn, when I import the constructor I get an error saying File '/node_modules/webvtt-parser/parser.js' is not a module. When I try to ignore that and use the parser I get this error:
./node_modules/webvtt-parser/parser.js
Module parse failed: Unexpected token (513:31)
You may need an appropriate loader to handle this file type.
|     this.parse = function(cueStart, cueEnd) {
|       function removeCycles(tree) {
|         const cyclelessTree = {...tree};
|         if (tree.children) {
|           cyclelessTree.children = tree.children.map(removeCycles);

Curious if anyone can provide insight on what I might be doing wrong.

Figured it out. At least temporarily/partially. Our webpack config wasn't compiling parser.js but upon changing out include: paths.appSrc, for include: [paths.appSrc, paths.appNodeModules + '/webvtt-parser/parser.js'], we have at least gotten rid of the unexpected token error.


Google authorization issue

I've sent the application to be revised by Google because they asked me to but they answered me this:
Dear Developer,
Thank you for submitting a verification request.
To proceed with the verification process, please make the following changes so that your project the-yisus-blog complies with our requirements.
Domain Verification
The website ownership of the following domains must be verified:
b2clogin.com
Please go to the Search Console to complete the domain verification process. You must use an account that is either a Project Owner or a Project Editor on the-yisus-blog.
When your project is changed to reflect these requirements, please reply to this email to confirm your compliance.

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

ID: 2c9d9c00-1382-c578-6b0d-7b5f9d63eebd
Version Independent ID: ce817a72-ca0d-ce18-f6ac-fc4812e9245d
Content: Set up sign-up and sign-in with a Google account using Azure Active Directory B2C
Content Source: articles/active-directory-b2c/active-directory-b2c-setup-goog-app.md
Service: active-directory
GitHub Login: @davidmu1
Microsoft Alias: davidmu

@SaurabhSharma-MSFT I think I can provide some more information as I'm also seeing the issue that's described here.  Setting up the authentication is working fine.  However, the issue is that google requires our settings to be validated in order to have a custom logo on the consent screen.  Also, once the user tries to login they are going to see an OAuth consent screen that states,

To continue, Google will share your name, email address, language preference, and profile picture with b2clogin.com. Before using this app, you can review b2clogin.com's privacy policy and terms of service.

However, we would prefer that our own domain name be in place of b2clogin.com because the way it reads now makes it look like the user is logging into Microsoft's site rather than our site.
In order to get past google's domain verification we had to add a TXT record to our DNS records for our own domain, but I don't think there's any way for us to do the same for b2clogin.com so that we can proceed with getting our consent screen validated by google.  If there is a way for us to validate the domain and satisfy google please let me know the steps.  An this support page should probably be updated to provide the steps to do that for everyone else as well.
I've emailed back and forth with google a few times on this asking that they allow our consent screen verification to go forward without verifying b2clogin.com, but I haven't been able to make progress on that side because I don't think the front line support understands the issue.  They just asked me to delete the domain from the settings, but the option is disabled since we are using the domain for the redirect URI.  Do you think you would be able to work with google on this issue so that they can whitelist b2clogin.com for everyone so that no one else will run into this issue in the future?  I'm assuming they already have login.microsoftonline.com whitelisted for this reason.

I'm seeing the same issue with Google Verification.  Has there been an answer or workaround for this?

Has Anyone Found a solution to this? I want to add google calendar to my App but i am blocked if i stay with Azure B2C.

bump, please address.
Client is concerned about Google throttling of OAuth logins to unverified domains, in particular custom.loginb2c.com, which is the display name of the consent screen (as configured from the Google console portal)

@SaurabhSharma-MSFT , can this please be reopened with the information from @atobrandon?  we are seeing the same thing and would like to have our logo and domain listed on the google screens, but it will not until google can verify the app.  Thank you.

I am also facing the same issue as per mentioned by @atobrandon
https://github.com/MicrosoftDocs/azure-docs/issues/23029#issuecomment-513828110
Currently in talk with Google representatives now.
Any help here would be greatly appreciated.

We're also trying to figure this out.  Anyone have an answer?  Does having Google verification allow you to change the name of this?

The solution for me was just to repeatedly explain to Google support that b2clogin.com is controlled by MS and doesn't belong to us, so it is impossible for me to add the DNS records they were requesting.  After explaining that a few times in various ways, I eventually asked for the case to be escalated and then they did whatever needed to be done on their end to allow us to display our own logo and domain on the consent screen.

The solution for me was just to repeatedly explain to Google support that b2clogin.com is controlled by MS and doesn't belong to us, so it is impossible for me to add the DNS records they were requesting. After explaining that a few times in various ways, I eventually asked for the case to be escalated and then they did whatever needed to be done on their end to allow us to display our own logo and domain on the consent screen.

Yes, Right.
I also tried to repeatedly explain Google support team about what we are using and also shared the documentation URLs to explain our need:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/b2clogin
https://docs.microsoft.com/en-us/azure/active-directory-b2c/
So finally they agreed and approved the domain and app.
It was hard but acceptable :)

Is there another form to use Azure AD but with own domains different from b2clogin for Google Identity Provider?

The solution for me was just to repeatedly explain to Google support that b2clogin.com is controlled by MS and doesn't belong to us, so it is impossible for me to add the DNS records they were requesting. After explaining that a few times in various ways, I eventually asked for the case to be escalated and then they did whatever needed to be done on their end to allow us to display our own logo and domain on the consent screen.

Yes, Right.
I also tried to repeatedly explain Google support team about what we are using and also shared the documentation URLs to explain our need:
https://docs.microsoft.com/en-us/azure/active-directory-b2c/b2clogin
https://docs.microsoft.com/en-us/azure/active-directory-b2c/
So finally they agreed and approved the domain and app.
It was hard but acceptable :)

In my case I explained 3 times and they did not verify the domain, I think I failed to send links to the documentation and insist more.

This is closed, but is it resolved?

I am also facing this issue right now. It should be possible to add the subdomain custom.b2clogin.com to the Google Search Console as a Verified Domain. It should be done through a txt record in DNS. That would be simple to add to the Azure B2C portal.


Documentation for ol.Overlay incorrect

In the stopEvent option documentation ol-overlaycontainer should be .ol-overlay-container.

Actually, both ol-overlaycontainer and ol-overlay-container are class names.  Yes confusing.  Which documentation are you referring to?

http://openlayers.org/en/v3.13.1/apidoc/ol.Overlay.html


feat: update charts to chatwoot v2.5.0

Description

Update charts to chatwoot v2.5.0
https://github.com/chatwoot/chatwoot/releases/tag/v2.5.0

Type of change

[x] Chore (Update Chatwoot version)

How Has This Been Tested?

[x]  Tested installation against a fresh k8s cluster
[x]  Tested upgrade against a k8s cluster running Chatwoot v2.4.1

Checklist:

[x] My code follows the style guidelines of this project
[x]  I have performed a self-review of my own code

Fixes https://github.com/chatwoot/product/issues/434


Kai/Marvel AI Onboarding Expedition

Description
This PR focuses on enhancing the onboarding process for Marvel AI by implementing a persistent progress bar and a real-time updating checklist. This was implemented by the squad 404 gladiator. This feature will guide users through key steps such as the:

Welcome Screen
Profile Setup
System Configuration
Final Steps
Result Page

Implementation:
To provide a clearer understanding of the implementation and guide you through all the relevant files, I will summarize the most important modifications made to this feature.

Database:
To accommodate the new onboarding feature, the existing "Users" collection has been modified. We added fields to track the progress of onboarding steps.
Database Diagram
A user document now looks like this:

{
 "users": {
   "123": {
     "fullName": "John Doe",
     "email"<EMAIL_ADDRESS>     "uid": "123",
     "onboarding": {
       "1": true,
       "2": true,
       "3": false,
       "4": false,
       "5": false
     },
     "occupation": "Software Developer",
     "socialLinks": {
       "facebook": "https://facebook.com/johndoe",
       "linkedin": "https://linkedin.com/in/johndoe",
       "twitter": "https://twitter.com/johndoe"
     },
     "profilePhotoUrl": "https://example.com/photos/johndoe.jpg",
     "bio": "Passionate developer with 5 years of experience",
     "systemConfig": {
       "email": true,
       "push": false,
       "reminders": true,
       "theme": false
     }
   }
 }
}

Modified signUpUser Function:
The backend function signUpUser was modified to save default onboarding values when a user signs up, incorporating the new onboarding data structure.

Firebase function modified: function/userControllers

HOC for Onboarding Screens:
A Higher-Order Component (HOC) was created to redirect users to the appropriate onboarding screens based on their current steps in the process. The HOC checks the user’s onboarding status and redirects accordingly during sign-up or sign-in.

HOC Created: frontend/hoc/onboarding/withLayoutRedirect
File Modified to accommodate the HOC: frontend/pages/index.js

Firebase Listener for Real-Time Updates:
A Firebase listener was added to update the Redux state and redirect users to the homepage upon completion of all onboarding steps.

File Modified: frontend/providers/GlobalProvider.jsx

Onboarding Layout:
A general onboarding layout was created to standardize all the onboarding screens. The layout includes a persistent progress menu to track onboarding steps.

Layout Created: frontend/layouts/OnboardingLayout
Icons Created:

frontend/assets/svg/IconProcessDoing
frontend/assets/svg/IconProcessDone
frontend/assets/svg/IconProcessUndo

New Component Created to Show Icons: frontend/component/CustomeCheckCircle

Welcome Screen:
The first screen of the onboarding process.

Screen Folders:

frontend/pages/welcome-screen
frontend/template/WelcomeScreen

Profile Setup:
A form to capture most of the onboarding fields and save them to the database. This included creating components for uploading profile images and handling social links.

Screen Folders Created:

frontend/pages/profile-setup
frontend/template/ProfileSetup/ProfileSetupForm
New component for handling social links: frontend/template/ProfileSetup/SocialLinkInput

New component for image uploading: frontend/components/ImageUpload
Hook to upload image to Firebase Storage: frontend/hook/useUploadFile
Utility function to crop profile photo: frontend/utils/getCroppedImg.js
Modified Firebase storage rules: storage.rules
New Firebase function to save form data to the database:

File Created: function/controllers/onboardingController.js
Function: setupUserProfile

Service to call the function: frontend/services/onboarding/setupUserProfile.js

System Configuration:
A screen to set up system preferences for users, such as email notifications and theme settings. Also modified how to theme in the whole system.

Screen Folders:

frontend/pages/system-config
frontend/template/SystemConfig

Modified project theme: Split theme.js into three files for better modularity:

frontend/theme/pallete.jsx
frontend/theme/componentsTheme.jsx
frontend/theme/theme.jsx

File Modified: _app.js to incorporate the theme across the project
Modified Redux slice to get theme info from the database: frontend/redux/slices/userSlice.js
Created a hook to sync user system configuration: frontend/hook/useThemeSync.jsx
Firebase function to save system configuration:

File Created: function/controllers/onboardingController.js
Function: setupUserSystemConfig

Service to call the function: frontend/services/onboarding/setupUserSystemConfig.js

Final Steps:
The final screen before completing onboarding.

Screen Folders:

frontend/pages/final-steps
frontend/templates/FinalSteps

Result Page:
The last screen confirms onboarding completion.

Screen Folders:

frontend/pages/result-page
frontend/templates/ResultPage

Firebase function to update onboarding status:

File Created: function/controllers/onboardingController.js
Function: advanceOnboardingStatus

Service to call the function: frontend/services/onboarding/advanceOnboardingStatus.js

Type of change

[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?
The following tests were conducted to verify the functionality:

[x] Test A: Verified that the progress bar updates correctly as the user advances through the onboarding steps.
[x] Test B: Tested the Firebase listener to ensure it updates the Redux state and redirects the user to the homepage upon completing onboarding.
[x] Test C: Confirmed that the onboarding screens are displayed in the correct sequence based on the onboarding status stored in the database.
[x] Test D: Verified the database integrity by inspecting user documents and ensuring that onboarding fields are properly updated as the user progresses through the onboarding steps.
[x] Test E: Tested edge cases, such as not entering required fields during profile setup, and confirmed that proper validation messages and error handling are triggered.
[x] Test F: Verified that the system functions correctly in both light and dark themes, ensuring consistent UI/UX and proper loading of user theme preferences.
[x] Test G: Tested the image upload functionality by uploading profile photos of varying sizes, and confirmed that cropping and resizing work as expected, with the correct URLs being saved in Firebase Storage and reflected in the database.
[x] Test H: Simulated network interruptions during the onboarding process and confirmed that the system properly resumes and synchronizes progress with the database after reconnection.

PR closed after Billy's review in dev session.


docs(sql): this library is now GA

Part of the work for #12120

This change is

@scotthart I think you want to review this again.


DX: JSON-RPC Interface for running workflows, returning receipts, pushing events

Summary
We need a standardized JSON-RPC implementation for handling web socket and HTTP interaction to integrate with the dashboard and any application.
Components

[x] Update web socket server to integrate JSON-RPC calls (probably use https://github.com/paritytech/jsonrpsee)

[ ] Update the WebSocket-relay example app to use this for running workflows and returning receipts.

[x] Expose a JSON-RPC API server for calls to /metrics and, eventually, other non-push-related queries. This could also happen over Websocket(s), so this is something to play with.
[x] Update metrics endpoint reusable for both Prometheus polling and via an internal API call.
[x] https://github.com/ipvm-wg/homestar/issues/407

ETA: 2023-11-03

Only thing left is updating the example to not break (needs a client).

Closed by #417


Docs work but all queries return 'Cannot read property 'x' of undefined'

Hey, I updated to faker<EMAIL_ADDRESS>Since then all queries return an undefined error. For example
query {
  profile {
    id
  }
}

{
  "errors": [
    {
      "message": "Cannot read property 'profile' of undefined",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "profile"
      ]
    }
  ],
  "data": {
    "profile": null
  }
}

The strange thing is that the editor and the docs still work correctly.
I tried downgrading but the error persists.
Any Idea what could be causing this?

@brasilikum Thanks for reporting 👍
I released v2.0.0-rc.15 📦 🎉
Can you please try it?

It works again! Thank you very much.
Would you be interested if I tried to set up some Github actions or some other CI to do some automated testing?

@brasilikum Yes this would be great 👍
The big challenge is that it should be CLI tests.
More details here: https://github.com/APIs-guru/graphql-faker/issues/7#issuecomment-523747852


server-side paging of connections list

connections list can grow pretty long especially the archived list
need to allow fetching only a small subset

completed as of 1.0.16


[BEAM-4426]: Addressed DataflowDistributionAccumulatorTest failure

Addressed DataflowDistributionAccumulatorTest failure on Windows
r: @pabloem
cc: @udim

This LGTM. I'll merge as soon as tests pass.

Unittest failed on this change @boyuanzz

Fixed in commit https://github.com/apache/beam/pull/5504/commits/3d0e6828b03716a563ab4f57e7c0f1828afaf2a5.

@pabloem pythonPreCommit passed

LGTM.


Implemented MonthField

I could not manage to rebase #530, so here is a new PR.

Can you amend the first commit message so it contains Co-authored-by information for the original user. You can get the name <email> from git log in the original PR.


Uncaught TypeError: Cannot read property 'displayBuffer' of null

[Enter steps to reproduce below:]

Change theme/color scheme.
View a file with hex colours
Start typing.

Atom Version: 0.177.0
System: Mac OS X 10.10.2
Thrown From: atom-color-highlight package, v3.0.8
Stack Trace
Uncaught TypeError: Cannot read property 'displayBuffer' of null
At /Users/bradpurchase/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:56

TypeError: Cannot read property 'displayBuffer' of null
  at color-marker.module.exports.MarkerMixin.getScope (/Users/bradpurchase/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:56:8)
  at color-marker.module.exports.MarkerMixin.hiddenDueToComment (/Users/bradpurchase/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:67:14)
  at color-marker.module.exports.MarkerMixin.isHidden (/Users/bradpurchase/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:53:6)
  at color-marker.module.exports.MarkerMixin.show (/Users/bradpurchase/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:18:33)
  at atom-color-highlight.AtomColorHighlightElement.updateSelections (/Users/bradpurchase/.atom/packages/atom-color-highlight/lib/atom-color-highlight-element.coffee:82:10)
  at /Users/bradpurchase/.atom/packages/atom-color-highlight/lib/atom-color-highlight-element.coffee:59:8

Commands
     -2:57.5 core:cut (atom-text-editor.editor.autocomplete-active)
     -2:56.2 core:paste (atom-text-editor.editor.autocomplete-active)
     -2:55.9 core:save (atom-text-editor.editor.autocomplete-active)
     -2:19.9 core:backspace (atom-text-editor.editor.autocomplete-active)
     -2:19.7 core:save (atom-text-editor.editor.autocomplete-active)
     -1:17.1 fuzzy-finder:toggle-file-finder (atom-text-editor.editor.autocomplete-active)
  4x -1:15.9 core:move-down (atom-text-editor.editor.mini)
     -1:15.3 core:confirm (atom-text-editor.editor.mini)
     -1:14.7 settings-view:open (atom-text-editor.editor.autocomplete-active)
     -1:10.1 core:close (div.text.native-key-bindings)
  4x -0:32.4 editor:newline (atom-text-editor.editor.autocomplete-active)
     -0:26.8 core:backspace (atom-text-editor.editor.autocomplete-active)
  2x -0:25.5 core:save (atom-text-editor.editor.autocomplete-active)
     -0:10.8 fuzzy-finder:toggle-file-finder (atom-text-editor.editor.autocomplete-active)
     -0:10.0 core:confirm (atom-text-editor.editor.mini)
     -0:00.4 editor:newline (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "disabledPackages": [
      "koala",
      "whitespace",
      "linter-rubocop",
      "linter-scss-lint"
    ],
    "themes": [
      "atom-light-ui",
      "atom-light-syntax"
    ]
  }
}

Installed Packages
# User
atom-color-highlight, v3.0.8
autocomplete-plus, v2.1.3
color-picker, v1.4.4
dash, v1.0.2
git-tab-status, v1.5.3
hipster-ipsum, v0.1.0
linter, v0.11.1
minimap, v4.1.3
project-manager, v1.15.5

# Dev
No dev packages

/cc @atom/core

Thanks for the report, I'm not sure why it fails like this, but I'll try to find the culprit.

I am running into the same problem when making changes to the "_settings.scss" file while working with Zurb Foundation. It is happening to me most of the time when I hit "Enter" to create a new line in any .scss file.
Here is my "config.cson" if that helps:
"*":
  editor:
    invisibles: {}
    fontSize: 12
  core:
    themes: [
      "seti-ui"
      "seti-syntax"
    ]
    disabledPackages: [
      "autocomplete"
      "highlight-line"
    ]
  "exception-reporting":
    userId: "fe09ace2-5aff-0322-bda5-9bc22d88eb4a"
  welcome:
    showOnStartup: false
  "linter-csslint": {}
  linter: {}
  "linter-htmlhint": {}
  "autocomplete-plus": {}
  "autoclose-html": {}
  autosave:
    enabled: true
  "linter-scss-lint":
    scssLintExecutablePath: "/usr/local/bin/scss-lint"
    scssLintExcludedLinters: [
      "Indentation"
    ]
  "project-palette-finder": {}
  "atom-color-highlight": {}
  "highlight-line": {}

Same issue here.

This happens constantly to me

This went away, but is back again today.
[Enter steps to reproduce below:]

Started typing in SCSS file.

Atom Version: 0.194.0
System: Mac OS X 10.9.1
Thrown From: atom-color-highlight package, v3.0.9
Stack Trace
Uncaught TypeError: Cannot read property 'displayBuffer' of null
At /Users/cnc137/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:56

TypeError: Cannot read property 'displayBuffer' of null
  at color-marker.module.exports.MarkerMixin.getScope (/Users/cnc137/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:56:8)
  at color-marker.module.exports.MarkerMixin.hiddenDueToComment (/Users/cnc137/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:67:14)
  at color-marker.module.exports.MarkerMixin.isHidden (/Users/cnc137/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:53:6)
  at color-marker.module.exports.MarkerMixin.show (/Users/cnc137/.atom/packages/atom-color-highlight/lib/marker-mixin.coffee:18:33)
  at atom-color-highlight.AtomColorHighlightElement.updateSelections (/Users/cnc137/.atom/packages/atom-color-highlight/lib/atom-color-highlight-element.coffee:82:10)
  at /Users/cnc137/.atom/packages/atom-color-highlight/lib/atom-color-highlight-element.coffee:59:8

Commands
 33x -3:25.8.0 core:move-right (atom-text-editor.editor.is-focused.autocomplete-active)
     -3:22.4.0 editor:newline (atom-text-editor.editor.is-focused.autocomplete-active)
 37x -3:22.1.0 core:move-right (atom-text-editor.editor.is-focused.autocomplete-active)
     -3:18.1.0 editor:newline (atom-text-editor.editor.is-focused.autocomplete-active)
 29x -3:17.9.0 core:move-right (atom-text-editor.editor.is-focused.autocomplete-active)
     -3:14.6.0 editor:newline (atom-text-editor.editor.is-focused.autocomplete-active)
     -3:14.1.0 core:backspace (atom-text-editor.editor.is-focused.autocomplete-active)
     -3:07.1.0 core:copy (atom-text-editor.editor.is-focused.autocomplete-active)
     -3:05.1.0 core:paste (atom-text-editor.editor.is-focused.autocomplete-active)
  4x -3:01.3.0 core:delete (atom-text-editor.editor.is-focused.autocomplete-active)
     -2:50.7.0 core:save (atom-text-editor.editor.is-focused.autocomplete-active)
     -1:18.7.0 core:copy (atom-text-editor.editor.is-focused.autocomplete-active)
     -1:15.3.0 core:paste (atom-text-editor.editor.is-focused.autocomplete-active)
     -1:14 core:save (atom-text-editor.editor.is-focused.autocomplete-active)
     -0:19.3.0 editor:newline (atom-text-editor.editor.is-focused.autocomplete-active)
     -0:12 core:save (atom-text-editor.editor.is-focused.autocomplete-active)

Config
{
  "core": {
    "themes": [
      "seti-ui",
      "seti-syntax"
    ]
  },
  "atom-color-highlight": {}
}

Installed Packages
# User
atom-beautify, v0.24.1
atom-color-highlight, v3.0.9
autoclose-html, v0.15.0
autocomplete-css, v0.6.0
autocomplete-html, v0.6.0
autocomplete-paths, v1.0.2
autocomplete-plus, v2.12.1
linter, v0.12.1
linter-csslint, v0.0.11
linter-htmlhint, v0.0.13
linter-jshint, v0.1.2
linter-php, v0.0.12
linter-scss-lint, v0.0.14
project-palette-finder, v2.4.17
seti-syntax, v0.4.0
seti-ui, v0.6.3

# Dev
No dev packages

I'll encourage all of you to migrate to pigments. It's a complete rewrite of this package but with a focus on performances and stability, which couldn't be really achieved with atom-color-highlight codebase.

atom-color-highlight is great, but there have definitely been performance issues.  pigments looks really impressive. nice work !

but there have definitely been performance issues

First implementation was too naive and wasn't really designed to handle really large files (ie. each change was destroying/recreating every color markers). Pigments on the contrary is designed to display and update only what's necessary, for instance the marker views used to display the colors are reused while you scroll, avoiding too much DOM manipulation.
There's still some performances issues in Pigments with really large project (1000+ variables), as I keep track of every variables, due to the frequent evaluation/conversion of these variables into colors. But I already have an idea on how to solve that, I just need the time to make the change and test it thoroughly.


When I import audio data using s3, an error occurs, and the displayed URL is in base64 format.

Describe the bug
When I import audio data using s3(In fact, it is MinIO that I built myself), an error occurs, and the displayed URL is in base64 format.
The left list can be played normally, but the annotation area in the middle shows a loading error.
To Reproduce
Steps to reproduce the behavior:

Import audio data using s3(In fact, it is MinIO that I built myself)
Click on a piece of data in the list for annotation.
See error

Screenshots

Environment (please complete the following information):

OS: 20.04.1-Ubuntu
Label Studio Version:last Docker image

Additional context
Add any other context about the problem here.

When I turn on this switch, it can be used normally


Create greeting bot using Github Actions for new pull requests and issues

Background
We'd like to add a greeting bot that provides a comment when a new pull request or issue is made
Solution
Use Github Actions to create a greeting bot for new issues and new pull requests in the  Open-Sentencing-Aggregator
repository.
Learn more about Github Actions here:
Tasks

Use this greeting bot an example
Read about Github Actions
Create Github Action, title the yml filegreetings.yml
Test Github Action

Acceptance criteria

Github action is present in ./github/workflows folder in  Open-Sentencing-Aggregator
repo.
file is named greetings.yml
greetings for PR and issue is as listed in example

Could I handle this task?

@gibrankasif go for it!

Hi @demilolu could you check my PR please.