Losing precision when passing data to shaders?

Godot version
4.1.dev.custom_build.578ca94ef
System information
Win10, GTX1060 5G, Vulkan1.3.236
Issue description
I passed some index data to the shader through Color, but somehow it lost precision when it came into the shader.
And Color looks like it doesn't allow data above 1.0... Is it intentionally designed like this?
GDScript:
extends MeshInstance3D

var tmpMesh = Mesh.new()
var vertices = PackedVector3Array()
var color = Color(1.0, 0, 0)

func _ready():
	var st = SurfaceTool.new()

	st.begin(Mesh.PRIMITIVE_TRIANGLES)
	# TRIANGLE 1
	st.set_color(Color(0.1, 0, 0, 1))
	st.add_vertex(Vector3(-1, -1, 0))

	st.set_color(Color(0.1, 0, 0, 1))
	st.add_vertex(Vector3(-1, 1, 0))

	st.set_color(Color(0.1, 0, 0, 1))
	st.add_vertex(Vector3(1, 1, 0))
	# TRIANGLE 2
	st.set_color(Color(0.11, 0, 0, 1))
	st.add_vertex(Vector3(-1, -1, 0))

	st.set_color(Color(0.11, 0, 0, 1))
	st.add_vertex(Vector3(1, 1, 0))

	st.set_color(Color(0.11, 0, 0, 1))
	st.add_vertex(Vector3(1, -1, 0))

	st.set_material(load("res://shader.tres"))

	mesh = st.commit()

Palette in editor:

Shader:
shader_type spatial;

uniform vec3 palette[3];
varying vec3 color;

void vertex(){
	int index = int(COLOR.r * 10.0);
	color = palette[index];
}

void fragment() {
	ALBEDO = color;
}

Image: Should be all green! but...

Steps to reproduce
run the reproduction project.
Minimal reproduction project
TEST_ARRAY_INDEX.zip

May be related to https://github.com/godotengine/godot/issues/76160?

And Color looks like it doesn't allow data above 1.0... Is it intentionally designed like this?

In Godot 4.x, vertex color data is limited to 8-bit integer for performance reasons (as it decreases memory bandwidth with complex meshes).

In Godot 4.x, vertex color data is limited to 8-bit integer for performance reasons (as it decreases memory bandwidth with complex meshes). See #75083.

Thanks for your response.

Are you sure that int() truncation isn't rounding the number down when you expect it to be rounded up?

I think * 10.0 will be executed before executing int().
int(0.1 * 10.0) → int(1.0) → 1 expected
int(0.1 * 10.0) → int(1.0) → 0 now
Or is this not the current order?
but the 0.11 is calculated correctly.
int(0.11 * 10.0) → int(1.1) → 1 now

Note that 0.1 is not a value that can be represented in binary, so there's very possibly rounding errors especially with 8 bit limits

Note that 0.1 is not a value that can be represented in binary, so there's very possibly rounding errors especially with 8 bit limits
If using 8 bit integer colours we get: (25.5,0,0,255) which is just (25,0,0,1), transformed to floating point we get (25/255,0,0,1) which becomes 250/255 when multiplying by 10, which is where I assume the issue comes from
For 0.11 you instead get 28 and 280/255

This makes sense. Got it!
How do I pass int data precisely to each vertex()?
Is it possible to do this with CUSTOM0?

You can probably use some method to encode a whole 32 bit value as a colour, but I'm not sure how color space transforms affect this

You can probably use some method to encode a whole 32 bit value as a colour, or 16 or 24 bits if you like, but I'm not sure how color space transforms affect this, assuming you're not using colour that is

Thanks for your advice; I'll give it a try.

Try out the packUnorm4x8 and packUnorm2x8 functions in the shader as well, just to see, the GDScript side should be done with bit shifts, will investigate in a bit and see if I have any suggestions

For the GDScript side try using to_argb32 and see how it lines up with the pack 4x8 function

For the GDScript side try using to_argb32 and see how it lines up with the pack 4x8 function

Tnanks again!
And how do you think about https://github.com/godotengine/godot/issues/76160 ?
Is it caused by the same reason?

Hard to tell tbh, but could be


[Runtime][PipelineExecutor] Move graph_split  into relay testing.

RFC: https://github.com/apache/tvm-rfcs/blob/main/rfcs/0014-pipeline-executor.md
Issue: https://github.com/apache/tvm/issues/8596
Currently the helper function of pipeline executor unit test like 'graph_slit' stay in the unit test file, and such function not directly related the testing logic.
moving such helper function into tvm.relay.testing folder.

I think it's better to keep this function in a pipeline executor test file. Things under relay.testing are supposed to be generally useful. And you need to add documentation and improve code quality if you want others to use this code.

I think it's better to keep this function in a pipeline executor test file. Things under relay.testing are supposed to be generally useful. And you need to add documentation and improve code quality if you want others to use this code.

@masahi, thanks for the follow up, I do see some requirement for a solution to handle graph splitting for example in this discussion(https://discuss.tvm.apache.org/t/relay-generate-sub-graphs-from-existing-graph/11594), as a short term solution, this graph_split function can serve as an example and a python level support,  I think that should be useful to separate this function into 'relay.testing' to let others use it, for sure I will add documentation and polish the code.

Hi, @huajsj. thanks for your contribution on TVM. I have a simple question for the graph_split func. In many real use case, the relay function can be existed in the module['main'] (i.e. OP fusion or BYOC cases). How can we handle these cases to split the graph?

Hi, @huajsj. Thanks for your contribution on TVM. I have a simple question for the graph_split func. In many real use case, the relay function can be existed in the module['main'] (i.e. OP fusion or BYOC cases). How can we handle these cases to split the graph?

As line 116 shown, graph_split only parse the top level function and treat the internal "relay.function" as a "relay.expr.call", that means the operator inside the function will not get involved by the graph split, and not impact the result. then either fuse or byoc logic will not get broken.
And if there is a requirement to split the internal function of like BYOC, then the order should be that do the graph split first then do the BYOC annotation.

Thanks.

Hi, @huajsj. Thanks for your contribution on TVM. I have a simple question for the graph_split func. In many real use case, the relay function can be existed in the module['main'] (i.e. OP fusion or BYOC cases). How can we handle these cases to split the graph?

As line 116 shown, graph_split only parse the top level function and treat the internal "relay.function" as a "relay.expr.let", that means the operator inside the function will not get involved by the graph split, and not impact the result. then either fuse or byoc logic will not get broken. And if there is a requirement to split the internal function of like BYOC, then the order should be that do the graph split first then do the BYOC annotation.

Thanks :-) 👍

@masahi , the document adding and code polish already done, please take a look.


Angular version upgraded

Angular 1.5. released
@zeari @AparnaKarve @abonas @himdel @skateman just letting you know

@miq-bot remove_label wip

@miq-bot add_label ui

waiting for angular-bootstrap-switch 0.5.0 release

@romanblanco quite a few failing tests, perhaps a rebase and/or look into them.

@dclarizio should be OK now. Thanks

@romanblanco bunches of these and the JS tests are failing:
1) ReportController#tree_add_child_nodes calls tree_add_child_nodes TreeBuilder method

     Failure/Error: //= require angular-patternfly-sass/angular-patternfly

     Sprockets::FileNotFound:

       couldn't find file 'angular-patternfly-sass/angular-patternfly' with type 'application/javascript'

     # ./app/assets/javascripts/application.js:8

@dclarizio seems like tests are passing :blush:


Implement backend options transformer

Enables plotting hvPlot output with HoloViews Matplotlib and Plotly backends.
Matplotlib
Plotly

This is now in a reasonable state but the list of transforms is not at all exhaustive.
Basically I've transformed some of the most important options but there is a long tail of options which are currently not handled. As a start it would be great if you could go through all user guides and reference notebooks and visually compare the plotly and matplotlib output with the bokeh output. Another useful approach is to insert this print statement:
if opt not in el_opts.allowed_keywords:
    print(f'{opt} not supported')
    ...

and see which options are currently being skipped and either make sure they are also UNSET (if not supported) or define the appropriate transform to ensure they are supported.

Coverage decreased (-0.5%) to 68.271% when pulling e143a9cb27cde9a2e6a404d15a71631d4deadebc on backend_transformer into 00e1ceb34ce3e66a42e7727090e149fd0da67c63 on master.

Here is a small write-up to clarify our intent here. As of now hvplot has a unique backend which is bokeh. hvplot's API allows to pass in kwargs to customize a bokeh plot, on the condition that they are known to holoviews. For instance to plot a dashed line one should provide the bokeh option line_dash="dashed". These options can be found by tab completion or with hvplot.help('line').
hvplot relies obviously on holoviews which itself supports two additional backends: matplotlib and plotly. It seems natural then to add support in hvplot for these alternative backends. There's however code out there that surely relies on customizing plots with bokeh kwargs. Where this happens, hvplot should try its best to transform the bokeh options provided to options understood by the targeted backend. For instance, the line_dash equivalent option for Matplotlib would be linestyle="dashed". Under the hood a mapping is used to store the options that can be linked or not between bokeh and matplotlib/plotly (TBD), and when they can be linked a transform function.
This allows for instance a user to turn a notebook with bokeh plots  to a notebook with matplotlib plots, while partly preserving the plot options originally defined for the bokeh backend. Note that this is not a dead-end, the underlying plot object can be accessed with hv.render and further customized.
# These two lines change the backend to matplotlib
import holoviews as hv
hv.extension('matplotlib')

import hvplot.pandas

df = ...
plot = df.hvplot.line(x='x', y='y', line_dash='dashed')
# Display plot in a cell
plot

# Get the Matplotlib figure to further customize it if required
fig = hv.render(plot)
...
fig.savefig('fig.png')

What has not yet been done in this work is to directly deal with matplotlib or plotly options, e.g. what to do with df.hvplot.line(linestyle="dashed"). This could be supported in principle. As of now this would result in a warning being emitted due to an option unknown to hvplot being used.

Here's a list of the current issues observed while running all the notebooks with the PR in its current state.
General:

date ticks are usually too long and not readable since partially overlapping
Can't get the line_width option to work

User guides

Plotting:

Bar plot with two y variables -> Display 'Year, Variable' in the x label ('Year' being x here), 'Variable' shouldn't be displayed there
hexbin: do not display an image, returns :HexTiles   [airtime,arrdelay], note this uses a dask df
heatmap: display the annotations by default (default in holoviews)
hist: error with by=... but that could also be because of dask again
box: figure with no plot when by=..., dask again
datashader: lots of unecessary space around the plot
violin: displaying the axes only, but again could be because of dask

Pandas API:

scatter: no colormap visible when c='whatever'
scatter_matrix, andrew_curves, parallel_coordinates: not working, options are not transformed in the PR
lag plots: no legend displayed by default while there's one with bokeh
tick formatter: ValueError: ClassSelector parameter 'xformatter' value must be an instance of (str, Formatter, function), not DatetimeTickFormatter(id='1002', ...).
error bars: not working well at all, the error lines are next to the bars
colormap: colormap='Greens' not working, colormap not respected

streams: not working df.groupby('y').sum().hvplot.bar(x='y') leads to a ZeroDivisionError
subplots: grid size really small and cannot be increased
time series: violin matplotlib plots have a cycled colormap while bokeh plots are just blue
geographic: spatialpandas plot upside down

Reference

heatmap: annotations displayed by default
ohlc: not working at all
violin: cmap not respected
contour and contourf: not working at all (clim=(None, None), is that expected?)
image: cartopy hangs when downloading the coastline shapefile (this is being fixed by cartopy)
quadmesh: the layout is kind of weird, too much padding around the plot
geopandas points: Issue with tiles: 'No plotting class for Tiles type and matplotlib backend found'

@philippjfr about the issue with line_width not being taken into account, I think I found why but I'm not sure what's the appropriate fix.
At this line
https://github.com/holoviz/hvplot/blob/483fe175cdf38102cda5b6fc060621ebf12fc63f/hvplot/converter.py#L958
the options I get for a Curve plot when I have declared that I want a Matplotlib plot (import holoviews as hv; hv.extension('matplotlib'); import hvplot.pandas) are:
OrderedDict([('axiswise', False),
             ('color', Cycle()),
             ('framewise', True),
             ('height', 300),
             ('labelled', ['x', 'y']),
             ('line_width', 20),
             ('linewidth', 2),
             ('logx', False),
             ('logy', False),
             ('muted_alpha', 0.2),
             ('responsive', False),
             ('shared_axes', True),
             ('show_grid', False),
             ('show_legend', True),
             ('tools', ['hover']),
             ('width', 700)])

They include linewidth=2, which is the default option for a Curve for the Matplotlib backend in holoviews:
https://github.com/holoviz/holoviews/blob/5e058cadb7c9817216e6eeafb2588ee5c5a5bc8c/holoviews/plotting/mpl/__init__.py#L231
Is it expected that at this stage .get() is able to return options from both backends>

In the Plotting guide the call to create a Hexbin plot (flights.hvplot.hexbin(x='airtime', y='arrdelay', width=600, height=500, logz=True)) doesn't display any image, it just returns :HexTiles [airtime,arrdelay].
Since the following code correctly displays an image with the Matplotlib backend I assume this is a hvplot issue.
hv.HexTiles(flights, kdims=['airtime', 'arrdelay']).opts(fig_size=200, logz=True, colorbar=True)

The object returned by hvplot has this .dataset property:
:Dataset   [index]   (year,month,day,dayofweek,dep_time,crs_dep_time,arr_time,crs_arr_time,carrier,flight_num,tail_num,actual_elapsed_time,crs_elapsed_time,airtime,arrdelay,depdelay,origin,dest,distance,taxi_in,taxi_out,cancelled,cancellation_code,diverted,carrier_delay,weather_delay,nas_delay,security_delay,late_aircraft_delay)

while the one returned by holoviews has:
:Dataset   [airtime,arrdelay]   (year,month,day,dayofweek,dep_time,crs_dep_time,arr_time,crs_arr_time,carrier,flight_num,tail_num,actual_elapsed_time,crs_elapsed_time,depdelay,origin,dest,distance,taxi_in,taxi_out,cancelled,cancellation_code,diverted,carrier_delay,weather_delay,nas_delay,security_delay,late_aircraft_delay)

Executing this:
fig = airports.hvplot.points('Longitude', 'Latitude', geo=True, color='red', alpha=0.2,
                       xlim=(-180, -30), ylim=(0, 72), tiles='ESRI')

works correctly with the Bokeh backend but fails with a horrible error message (https://github.com/holoviz/geoviews/issues/540) with the Matplotlib one.
Interestingly xlim and ylim appear to have been projected to Web Mercartor, while the crs of the Points element is still PlateCarree.
:Overlay
   .Tiles.I  :Tiles   [x,y]
   .Points.I :Points   [Longitude,Latitude]
    | Options(alpha=0.2, axiswise=False, color='red', data_aspect=1, framewise=True,
    |         legend_position='right', logx=False, logy=False, muted_alpha=0.2, responsive=False,
    |         shared_axes=True, show_frame=True, show_grid=False, show_legend=True,
    |         size=5.477225575051661, tools=['hover'], xlim=(-19981848.597392607, -3339584.8351176973),
    |         ylim=(0.1113194902619854, 11753184.255101029))

Anyway, Tiles elements don't have a matplotlib implementation in holoviews, so no background tiles would be plotted.
One way to adapt the code to support plotting background tiles with the Matplotlib backend may be to use the WMTS elements provided by geoviews instead of the Tiles elements provided by holoviews, given that the latter have no projection.

Plotly issues:

[ ] The legend is (always?) shown while it's not with Bokeh or Matplotlib => Opened a Holoviews issue (https://github.com/holoviz/holoviews/issues/5217)

Before the backend option transforms work hvPlot users could already pass Bokeh options as kwargs such as line_dash in df.hvplot.line(x='x', y='y', line_dash='dashed'), without hvPlot knowing anything about the line_dash option.
After this work, when a user selects another backend such as Matplotlb and calls df.hvplot.line(x='x', y='y', line_dash='dashed'), if line_dash is part of hvPlot's internal transforms mapping then it will be converted (the key or the value or both) to a valid option definition for the targeted backend. If the option isn't part of the mapping then it'll be ignored. In that case line_dash is part of the Matplotlib mapping and would be converted to linestyle='dashed'. So the advantage of this system is that it facilitates executing existing code with another backend. If some Bokeh options were passed in that code as kwargs they may or may not be used by the backend (this depends on whether this option is actually available in the targeted backend and also on whether I've mapped it or missed it).
Now let's imagine a new hvPlot user who doesn't care at all about Bokeh plots but wants to generate Matplotlib plots only, and wants a dashed line. If this user knows Matplotlib's API a little then the natural thing to do would be  df.hvplot.line(x='x', y='y', linestyle='--'). This isn't going to work though, the plot will be displayed but with a warning: WARNING:param.main: linestyle option not found for line plot; similar options include: []. hvplot.help('line') will list the line_dash option and so once the user has figured out that it is a Bokeh option then they'll have to go to Bokeh's site (or maybe Holoviews?) to see what values line_dash accepts. To avoid this pattern which feels a little awkward, what should we recommend in the docs for now? Should we, for now, recommend the usage of .opts() for matplotlib&plotly and link to the relevant section of the HoloViews docs?
One subtlety about the option transforms is that when a transform exists for an option (e.g. alpha to opacity for plotly), in most cases the value isn't validated, it's just passed internally to the backend via .opts. Not validating the value means that a user could provide a combination of a valid bokeh option with a value that would be invalid for bokeh but valid for the backend. For example, a user could select the plotly backend and provide color='hsl(0,100%,50%) (red color) this hsl(...) value being valid for plotly. However switching to bokeh, this code would no longer work and raise an error as this sort of value isn't accepted by bokeh for defining the color. What should we do to avoid this? I would suggest documenting that only valid Bokeh option values are supported for now. And is there a way in holoviews that we could leverage to validate an option value before attempting to render the figure? (I assume not and that it's the responsibility of the backend libraries only)

Maybe I am missing something but couldn't linestyle='--' (the matplotlib kwarg) just be passed through to matplotlib when the matplotlib backend is active, just the same way  line_dash gets passed to Bokeh without hvPlot knowing anything about it?
The issue with different backends accepting different types of values is tricky at the holoviews level as well, when trying to switch backends. I'm not sure it is a great idea but if we declare multiple backends are in use (as holoviews does is when loading the extension), keywords not recognized by the current backend could just be ignored instead of generating errors. e.g. df.hvplot.line(x='x', y='y', linestyle='--', line_dash='dashed') would be allowed. This could allow some more flexibility to switch backend but with a flat kwarg namespace you are out of luck if shared keywords with different value formats clash. Another type of solution would be something like df.hvplot.line(x='x', y='y', matplotlib_kwargs={...}, bokeh_kwargs={...) of course...

Before the backend option transforms work hvPlot users could already pass Bokeh options as kwargs such as line_dash in df.hvplot.line(x='x', y='y', line_dash='dashed'), without hvPlot knowing anything about the line_dash option.

Can you be more specific about what previously happened to line_dash in this case? Did it become a HoloViews plot option, or was it somehow kept around to be applied later as a Bokeh plot hook?

Maybe I am missing something but couldn't linestyle='--' (the matplotlib kwarg) just be passed through to matplotlib when the matplotlib backend is active, just the same way line_dash gets passed to Bokeh without hvPlot knowing anything about it?

That does sound reasonable to me, if that's how it works.

Should we, for now, recommend the usage of .opts() for matplotlib&plotly and link to the relevant section of the HoloViews docs?

I would definitely try to avoid using .opts() wherever practical, in order to minimize the number of concepts needed for most people to get most of their work done, and to make it easier to switch from .plot to .hvplot.

For example, a user could select the plotly backend and provide color='hsl(0,100%,50%) (red color) this hsl(...) value being valid for plotly. However switching to bokeh, this code would no longer work and raise an error as this sort of value isn't accepted by bokeh for defining the color. What should we do to avoid this?

I don't think we should work hard to avoid this. By default, if a user does that, then they've tied themselves to a particular plotting library, which seems fine by me! If a user did want to avoid that, they could follow @jlstevens' suggestion of being explicit withdf.hvplot.line(x='x', y='y', matplotlib_kwargs={...}, bokeh_kwargs={...}, ...) to sort things out by backend. But very few users seem to want to dynamically switch backends, even on HoloViews where the options can be sorted out cleanly, so I don't expect such options to be used much.

And is there a way in holoviews that we could leverage to validate an option value before attempting to render the figure? (I assume not and that it's the responsibility of the backend libraries only)

At least for now I'm happy to let the backend library do that validation. Eventually, sure, eager validation is more helpful for the user, but since few people will be creating plottable objects but not plotting them, validation should eventually happen already.

Maybe I am missing something but couldn't linestyle='--' (the matplotlib kwarg) just be passed through to matplotlib when the matplotlib backend is active, just the same way line_dash gets passed to Bokeh without hvPlot knowing anything about it?

I wasn't quite clear when I wrote that hvPlot doesn't know anything about line_dash. line_dash isn't part of the API and not mentioned in any of the options available in hvPlot. However hvPlot will check that the options passed are valid options for the Bokeh backend and so at this moment it knows that line_dash is OK.
Basically how things work right now is that it's always assumed internally that the options passed are Bokeh options. It looks something like that:

user_opts = {'line_dash': 'dashed'}
new_backend = 'matplotlib'

import holoviews as hv

hv.extension('bokeh')
hv.extension(new_backend)

# In hvplot the `_process_style` method is executed before setting the options
# on the element to parse the user options. It assumes the backend is bokeh.
# It will happily parse and let `line_dash` go further but will "block" `linestyle`
# since it's not one of the allowed options of the bokeh backend.

el = hv.Curve([[0,1], [1, 2]]).opts(backend='bokeh', **user_opts)

def transfer_opts(element, backend):
    bokeh_opts = el.opts.get(backend='bokeh', defaults=False)
    # Convert the bokeh options to another backend options using an internal mapping
    new_opts = {'linestyle': '--'}  # Just to get this snippet running
    return element.opts(**new_opts, backend=backend)

el = el.apply(transfer_opts, backend=new_backend)

The last line in the snippet is the command that is the last one executed in the code, before that everything is in Bokeh's world until it's converted into another backend world.

Philipp also designed another feature in this PR that I think is worth mentioning. A user can pass a backends parameter that allows to convert the options for all the backends requested, so that the object can be rendered using any of the available backends:
import hvplot.pandas
# load data ...
hvplot.extension('plotly', 'matplotlib')
o = crime.hvplot.line(x='Year', y='Violent Crime rate', line_dash='dashed', backends=['plotly', 'matplotlib'])
# Now the object has the `line_dash` option converted to all the backends
# And this returns a matplotlib figure with a dashed line!
hvplot.render(o, backend='matplotlib')

Maybe I am missing something but couldn't linestyle='--' (the matplotlib kwarg) just be passed through to matplotlib when the matplotlib backend is active, just the same way line_dash gets passed to Bokeh without hvPlot knowing anything about it?

I guess this should be possible but I don't know how tricky that'd be to implement, it might be that there are some things deeply tied to the Bokeh backend and its options (_process_style is about a 100 LOC). I wouldn't like this to block this PR any longer :/ What are your thoughts on this @philippjfr ? In the mean time I'll try to get the tests to pass and fix the docs build.

Setting pandas backend to holoviews currently defaults to Bokeh.
https://github.com/holoviz/hvplot/blob/0cf0d867cbb1548fa144f34f216482178f27340e/setup.py#L137-L143
Should we provide a way to set pandas backend to another extension (e.g. 'holoviews-matplotlib')?

A default Bokeh renderer is instantiated in hvplot.utilities and exposed in the main __init__.py file.
https://github.com/holoviz/hvplot/blob/0cf0d867cbb1548fa144f34f216482178f27340e/hvplot/utilities.py#L4
I don't see this documented anywhere. In this PR I've exposed holoviews.render which can be used as hvplot.render(...). Could we deprecate renderer and remove it in a future version?

Some work's required before this is merged probably to refine how the size/aspect options are handled with the other extensions:

hvplot sets default width/height options for bokeh plots, should these defaults be kept for matplotlib and plotly?
in the current state of the PR width and height are supported by all the extensions even without compatibility. This is because they're part of the options that are transformed (there's some special logic to convert width/size to matplotlib holoviews plotting options)
not sure what the current state of matplotlib is about setting the size but I guess it's done with figsize (Width, height in inches.), which is what pandas.plot() accepts. Note that this not an option directly supported by holoviews (which supports fig_inches and fig_size and others).

I'd suggest:

width and height be the declared  hvplot's way of setting a plot size
have special logic to convert figsize if provided to get closer to pandas' plot API

width and height be the declared hvplot's way of setting a plot size

This is in fact already the case, since width and height are part of the Generic Options.

have special logic to convert figsize if provided to get closer to pandas' plot API

Actually there was already some sort of handling of figsize. There's a warning (that should be emitted but is not, I'll fix that in this PR) that indicates that there's no concept of a Figure in hvPlot:
        if 'figsize' in mismatches:
            mismatches.pop(mismatches.index('figsize'))
            param.main.param.warning('hvPlot does not have the concept of a figure, '
                               'and the figsize keyword will be ignored. The '
                               'size of each subplot in a layout is set '
                               'individually using the width and height options.')

This makes sense, as figsize for Matplotlib controls the size of the whole Figure/Layout while width/height in hvPlot controls the size of each individual (sub)plot. We could just ignore figsize in the case of subplots but I tend to think that for the scope of this PR we should just stop there, and improve things when we get some feedback.

@philippjfr @jbednar this is ready for a review.

@jlstevens could you please review the last changes wrt compatibility?

Other than the suggestion to update the parameter docstring, the latest changes look fine to me!

Made some suggestions for the docs but overall this looks good!

@jlstevens thanks for the review! I applied your suggestions in the last two commits.

Tests look like they are passing and I'm happy to see it merge from my side!


Challenges -4 adding in challenges solution folder.

Issue Summary
Challleges -4 adding in challenges with solutions and explanation.
Issue Description
Challleges -4 adding in challenges with solutions and explanation and also using all the rules that mention in  README.md file.
Proposed Solution (Optional)
No response
Priority
High - Requires urgent attention
Category

[ ] Enhancement
[ ] Refactor
[ ] Security
[ ] Design
[ ] Other

Additional Context (Optional)
No response

@ajay-dhangar  "I would love the opportunity to contribute and work on this project.
Could you please assign the issue to me? I'm eager to dive in and make a meaningful impact. Thank you for considering my request!"


Terminal tab description - how was default determined

Testing #133549
I see the default is ${task}${separator}${local}${separator}${cwdFolder}, and for the terminals I was using, no description was initially appearing, so I was confused where I was supposed to see one and if I was looking in the wrong spot. Upon a search of this issue I realized what the description was and where I should be seeing it and was then able to play around and start seeing changes.
Was ${task}${separator}${local}${separator}${cwdFolder} deemed a universal enough basis for folks who will take advantage of this setting? It seems like such a long contrast in comparison to the ${process} default for title.

We want to keep info/clutter to a minimum. We decided upon that as the default description because descriptions should only be shown when they're important. On Windows, as you state, that happens less frequently, since we don't currently have cwdDetection enabled.


cloudinit: fix instability and user_data

Coverage decreased (-0.1%) to 56.63% when pulling 9ffcc91e22c99c08ddf718611c87a59dcbcdc163 on monstermunchkin:issues/135_145 into 8e74bea665840557cc3783c9f2c80d920ec88b85 on dmacvicar:master.

Is this going to fix issue https://github.com/dmacvicar/terraform-provider-libvirt/issues/145 ?

Yes, these commits fix both #145 and #135.


[com.google.fonts/check/unreachable_glyphs] Glyphs reached from MATH table are reported as unreacable

Observed behaviour
A font with MATH table will report many glyphs that reached from MATH table as unreachable.
Expected behaviour
It should take MATH table into account.
Resources and steps needed to reproduce
Using NotoSansMath-Regular.otf, gives:
⚠ WARN: Check font contains no unreachable glyphs (com.google.fonts/check/unreachable_glyphs)

Glyphs are either accessible directly through Unicode codepoints or through substitution rules.
In Color Fonts, glyphs are also referenced by the COLR table.
Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.

⚠ WARN The following glyphs could not be reached by codepoint or substitution rules:

arrowdblup.x

arrowleft.l

arrowright.r

arrowup.x

backslash.s1

backslash.s2

backslash.s3

backslash.s4

braceleft.s1

braceleft.s10

475 more.

Use -F or --full-lists to disable shortening of long lists.
[code: unreachable-glyphs]

thanks

After making the check aware of the references in the MATH table, I still get one unreachable glyph (upWhiteMediumTriangle):

@khaledhosny do you know where this glyph is supposed to be referenced / used? Or would this be a legitimate font bug detected by the check?

upWhiteMediumTriangle is used as a component in circledTriangle, since CFF does not have composites it became unused. So that is a build tooling issue.


DR-958 Fix issue with duplicated elements in table

Changes:

Change ng-repeat.
Add function to apply property to each new element, set default or disabled.
Remove old animation.

❤


Added D regular implementation

Added D implementation based on the code from Go.
I've tested several D implementations. This one based on memutils package for HashMap, which worked a bit better than built-in Associative Arrays.
Parallel versions also under preparation, but currently they are working quite slow.

I don't know much about D but wouldn't it need to install the deps before compiling?

when you run "dub build" it automatically install deps into specific folder and use it flawlessly.
I've updated Dockerfile to add 'dub' (D package manager). Because on Archlinux it is not in the bundle of compiler package.

I also updated the build command to
dub build --build=release

as that's what works for me. I notice D has an official compiler (DMD). Is it that ldc is faster?

I also updated the build command to
dub build --build=release

as that's what worked for me. I notice D has an official compiler (DMD). Is it that ldc is faster?

DMD is a reference compiler with its own backend. LDC is using DMD's frontend and LLVM backend. There is also GDC - which uses GCC as a backend. LDC/GDC could provide more optimizations in the code. So it is better to use one of them. It is possible even prepare 2 runs for both of them.


BUG: Binned groupby median function calculates median on empty bins and outputs random numbers

Code Sample, a copy-pastable example if possible
import pandas as pd
d = pd.DataFrame([1,2,5,6,9,3,6,5,9,7,11,36,4,7,8,25,8,24])
b = [0,5,10,15,20,25,30,35,40,45,50,55]
g = d.groupby(pd.cut(d[0],b))
print g.mean()
print g.median()
print g.get_group('(0, 5]').median()
print g.get_group('(40, 45]').median()

Expected Output
                  0
0
(0, 5]     3.333333
(5, 10]    7.500000
(10, 15]  11.000000
(15, 20]        NaN
(20, 25]  24.500000
(25, 30]        NaN
(30, 35]        NaN
(35, 40]  36.000000
(40, 45]        NaN
(45, 50]        NaN
(50, 55]        NaN
             0
0
(0, 5]     3.5
(5, 10]    7.5
(10, 15]  11.0
(15, 20]  18.0
(20, 25]  24.5
(25, 30]  30.5
(30, 35]  30.5
(35, 40]  36.0
(40, 45]  18.0
(45, 50]  18.0
(50, 55]  18.0
0    3.5
dtype: float64
Traceback (most recent call last):

  File "<ipython-input-9-0663486889da>", line 1, in <module>
    runfile('C:/PythonDir/test04.py', wdir='C:/PythonDir')

  File "C:\Anaconda2\lib\site-packages\spyderlib\widgets\externalshell\sitecustomize.py", line 714, in runfile
    execfile(filename, namespace)

  File "C:\Anaconda2\lib\site-packages\spyderlib\widgets\externalshell\sitecustomize.py", line 74, in execfile
    exec(compile(scripttext, filename, 'exec'), glob, loc)

  File "C:/PythonDir/test04.py", line 20, in <module>
    print g.get_group('(40, 45]').median()

  File "C:\Anaconda2\lib\site-packages\pandas\core\groupby.py", line 587, in get_group
    raise KeyError(name)

KeyError: '(40, 45]'

This example shows how the median-function of the groupby object outputs a random number instead of NaN like the mean-function does when a bin is empty. Directly trying to call that bin with its key leads to an error since it doesn't exist, yet the full median output suggests it does exist and that the value might even be meaningful (like in the (15, 20] bin or the (30, 35] bin). The wrong numbers that are returned can change randomly, another possible output using the same code might look like this:
(0, 5]     3.500000e+00
(5, 10]    7.500000e+00
(10, 15]   1.100000e+01
(15, 20]   1.800000e+01
(20, 25]   2.450000e+01
(25, 30]   3.050000e+01
(30, 35]   3.050000e+01
(35, 40]   3.600000e+01
(40, 45]  4.927210e+165
(45, 50]  4.927210e+165
(50, 55]  4.927210e+165

output of pd.show_versions()
pandas: 0.18.1

@Khris777 Thanks for reporting!
As a workaround for now, you can do:
In [11]: g.agg(lambda x: x.median())
Out[11]:
             0
0
(0, 5]     3.5
(5, 10]    7.5
(10, 15]  11.0
(15, 20]   NaN
(20, 25]  24.5
(25, 30]   NaN
(30, 35]   NaN
(35, 40]  36.0
(40, 45]   NaN
(45, 50]   NaN
(50, 55]   NaN

ATM, internval types are actual string reprs (and not a distinct dtype), so yes, g.get_group('(40, 45)') should be a KeyError, just like any other indexing operation.


New typeUrl/$typeUrl field causing issues in testing frameworks

Before Telescope 1.0, the generated messages only contained the object fields that are present in the protobuf message declaration. Now, the meta field typeUrl/$typeUrl is added. This causes issues when using the message in testing frameworks that do equality checks.

I know I somwwhat requested that addition. But seeing the consequences now I think it's not a great way to implement the feature. Ideally we can keep the proto fields and meta fields separate. Maybe it's better to add the type URL on the type instead of the instance. If you have ideas for this, let me know.
In the meantime I'll use this for cosmjs-types:
    prototypes: {
      addTypeUrlToDecoders: false,
      addTypeUrlToObjects: false,
    }

Oh, that makes sense to remove $typeUrl for equality checks.
Just wondering do we have to also remove typeUrl fields inside the objects that do encode and decode?
I think it's still possibly safe to have sth like this:
// addTypeUrlToObjects: true
export const WeightedVoteOption = {
  typeUrl: "/cosmos.gov.v1beta1.WeightedVoteOption",
  encode(message: WeightedVoteOption, writer: BinaryWriter = BinaryWriter.create()): BinaryWriter {
  decode(input: BinaryReader | Uint8Array, length?: number): WeightedVoteOption {

Just curious about that can we still leave addTypeUrlToObjects on.
Thank you very much

Just wondering do we have to also remove typeUrl fields inside the objects that do encode and decode?

I think those are actually fine (addTypeUrlToObjects: true) because they do not affect the data objects but only the types. There the field is good to have.
The real issue seems to be addTypeUrlToDecoders: true which adds the $typeUrl field to the Any instances.

And for $typeUrl, it would be very helpful that we have it for identifying proto type of an interface. It's really a bad news that we have to discard it.
But I guess we can generate "is" functions for those interfaces that need identify, like:
function isClientUpdateProposal(
  message: Partial<ClientUpdateProposal>
): message is ClientUpdateProposal {
// identify fields and their types
}

In this way we can tell their types when we need. If we go with this way, I think only those ones with "cosmos_proto.implements_interface" need "is" functions, there're not that many of them.

Can you show me where/how the field $typeUrl is currently used? Maybe I have better ideas then.

It's used to generated like this, only for those with "cosmos_proto.implements_interface":
export interface ModuleAccount {
  $typeUrl?: "/cosmos.auth.v1beta1.ModuleAccount";
  baseAccount?: BaseAccount;
  name: string;
  permissions: string[];
}

we use it to identify the polymorphic types in the application layer
e.g. for Osmosis Pools there are tons of Pool types:
https://github.com/cosmology-tech/create-cosmos-app/blob/6f12acbcdfdae0ead3460af2b0ace975c3e21ff2/examples/provide-liquidity/utils/pool.ts#L177
https://github.com/cosmology-tech/create-cosmos-app/blob/6f12acbcdfdae0ead3460af2b0ace975c3e21ff2/examples/swap-tokens/hooks/usePools.ts#L29-L30
cc @webmaster128

I've done recursive object cloning in tests and strip out properties, like $typeUrl. Would that help or are there more than tests that needs this removed?


Appstudio update mvp-test-component

Pipelines as Code configuration proposal

Pipelines as Code CI/mvp-test-component-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
10 seconds
init

✅ Succeeded
17 seconds
clone-repository

✅ Succeeded
1 minute
build-container

✅ Succeeded
17 seconds
deprecated-base-image-check

✅ Succeeded
17 seconds
inspect-image

✅ Succeeded
16 seconds
clair-scan

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
13 seconds
sbom-json-check

✅ Succeeded
11 seconds
label-check

✅ Succeeded
11 seconds
optional-label-check

✅ Succeeded
5 seconds
show-summary


README.md: update section on removing packs via PDSC file

Fix: https://github.com/Open-CMSIS-Pack/cpackget/issues/96

That is worth mentioning in this document, don't you think?

I have added a note about it.


[PartGraphSelector] Set node backend assignment after load

This will set node backend assignment after load is finished.
ONE-vscode-DCO-1.0-Signed-off-by: SaeHie Park<EMAIL_ADDRESS>

for #822 from draft #851
GrapView will show color nodes with this change


double outputs in the console and GUI stalls

Timestamps in the GUI were duplicated. And the GUI got stuck in the middle of the session.
W10DT713883-A_gui_log_2024-10-30_11-47-25.txt

Did this happen more than once? It looked like you ran several sessions before the duplicate outputs started

I ran one successful session before this failure session.

Key points in this session:
12:03:46 PM:INFO:Foraging:Foraging.py:log_session:line 4198:Starting log file at D:\BehaviorData\323_EPHYS3\0\behavior_0_2024-10-30_12-03-46\behavior

3 trials run

12:04:16 PM:INFO:Foraging:Foraging.py:log_session:line 4198:Starting log file at D:\BehaviorData\323_EPHYS3\0\behavior_0_2024-10-30_12-04-16\behavior

19 trials run

12:17:26 PM:INFO:Foraging:Foraging.py:log_session:line 4198:Starting log file at D:\BehaviorData\323_EPHYS3\744330\behavior_744330_2024-10-30_12-17-20\behavior

double timestamps start immediately, most likely an issue with how the last session ended and is probably just a logging error
531 trials run

01:52:54 PM:INFO:Foraging:Foraging.py:log_session:line 4198:Starting log file at D:\BehaviorData\323_EPHYS3\744331\behavior_744331_2024-10-30_13-52-49\behavior

302 trials
02:40:33 PM:INFO:Foraging:Foraging.py:_Save:line 2511:saving canceled by user
no more trials are generated
03:02:20 PM:INFO:Foraging:Foraging.py:_Save:line 2491:Saving current session, ForceSave=True
everything saves and you close, no data was lost

I think there are two things happening here.

The double timestamps are probably because a logger didn't get closed properly @micahwoodard do you have any insight here? Unless we know the problem, I suspect we should wait to see if it happens again
for some reason saving was cancelled by the user, which cause the session to stall. This seems impossible to debug, since we dont know what the trigger was.

as an aside its very difficult to look at this logs with the camera verbose level set so high.

We should disable the camera verbose. It's almost useless

We should disable the camera verbose. It's almost useless

You can do this on your rig by changing the codec: add -v 24 to the codec in Settings_box#.csv. This was changed to the default in the settings template in this PR: https://github.com/AllenNeuralDynamics/dynamic-foraging-task/pull/587

@XX-Yin let me know when you've completed this in your rig and we can close the issue

I didn't see this yesterday. We can temporarily close this issue. I will reopen it if I see it again


JUP-20 new events page

New events page with filters and a list and grid view.
The api for filtering is very messy and super coupled with the frontend filterState. any comments regarding cleaning this up or decoupling it would be greatly appreciated.

Is the large gap between the org search and the filters necessary?

Is the large gap between the org search and the filters necessary?

no, I just wanted to try and prevent layout shift when you added a club to the search, i removed it though, because you're right, it's too big when there aren't any clubs being filtered.


[release-1.8] Upgrade to latest dependencies

Bump eventing -nak3
/cc knative-sandbox/eventing-writers
/assign knative-sandbox/eventing-writers
Produced by: knative-sandbox/knobots/actions/update-deps

/lgtm
/approve


Generated Message Collection class

For an entire schema of multiple messages, it would be useful to auto-generate a collection class that can parse a header and dispatch to various classes. The lookup could be a perfect hash on an ordered list of template IDs.
A possible implementation could be along these lines (for Java).
public interface IProcessMsg
{
void process(DirectBuffer buffer, int offset);
}
public class MyMessageType implements MessageFlyweight, IProcessMsg …
<this delegates to the generated code… kind of like wrapping the generated code>

IProcessMsg msg = map.get(templateId);        // lookup template and return wrapped message class
msg.process(buffer, offset + header.size());     // process message

Closing for now due to inactivity.


Adds a sentinel step to drivers build for release branches

Description
Github Actions will skip a job if all of its dependencies are also skipped. This is ordinarily fine, but for release branches we don't want the drivers build to run, but we do want the full builds to run.
This adds a sentinel job in the drivers workflow to ensure that even if the driver build itself is skipped, the workflow runs at least one job, and therefore the full builds will also run.
This will not run on this PR, but I have tested the mechanism on one of my own repositories and it works: https://github.com/Stringy/wisdom/pull/10
Checklist

[ ] Investigated and inspected CI test results
[ ] Updated documentation accordingly

Automated testing

[ ] Added unit tests
[ ] Added integration tests
[ ] Added regression tests

If any of these don't apply, please comment below.
Testing Performed
Tested on my own repo here https://github.com/Stringy/wisdom/pull/10

Side note, I thought (and the PR comment seems to confirm) that GHA skipped a step if ALL previous needed steps were skipped. Building the full image needs both init and build-collector-slim, which were not skipped, so I find the behavior a bit odd.

Seems that it was missed on the original PR, because the full builds didn't run there either: https://github.com/stackrox/collector/actions/runs/6704112012


filetype: cfg, update README and CHANGELOG

This patch updates CHANGELOG and README to reflects changes introduced
by commit 199af95a.

Sorry for having forgotten those

Thank you :)


Add viewOperation render data judgment

:tada: This PR is included in version 1.0.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Req.Request, Req.Response: Change headers to be maps

Closes #223

Hi @wojtekmach, thanks for all the work put into Req!
We're in the processing of migrating from 0.3 to 0.4, and in the process I assumed that the :headers option in Req.new/1 and Req.update/2 would also have been changed to expect map data instead of lists. E.g.:
req = Req.new(url: "https://example.com", headers: %{"accept" => ["application/json"]})
Req.update(req, headers: %{"foo" => ["bar"]})

Is there a specific reason that in both cases, the :headers values are still lists in 0.4.x?

Both are supported! (If maps are not, it’s a bug.) the idea is passing eg accept: “application/json” is much more concise than the equivalent map with, notably, list of values.

In hindsight this is not necessarily super obvious so a PR that updates docs is welcome as always!

@wojtekmach See #241 for PR, feel free to change anything you like!


fix(provider): don't query leases on startup

ActiveLeasesForProvider never terminates; guard
against instantiating closed deployments instead
supersedes #1542

There is an issue here where when a manifest is submitted, it is assumed that the group data is present.

never mind, it "just works" - requests are queued until the data is fetched.


Enable Kafka Streams binder for Graal native compilation

Verification on the KTable is still pending.

Issue moved to spring-cloud/spring-cloud-stream #2323 via ZenHub


[fix] set correct dimensions

Hi
If you open app in horizontal orientation and then switch to portrain when you'll get menu with width equal to 0.6 height of the device

did it's work when change the screen orientation while showing hold menu?

It should


Drop pathlib2 dependency and merge installer._compat.{builtins, typing}

Follow up on #2
This also adds Text and Binary type names, which are better IMO. (and follow mypy's Text type)

Quoting myself from https://github.com/pradyunsg/installer/pull/6#issuecomment-625604376:

It is not suitable to use str as the type for each path component. RECORD entries are encoded in UTF-8 (not actually specified anywhere, but implemented by importlib.metadata), and so are file entries in the wheel (as specified in PEP 427). But installed path needs to be calculated using platform filesystem encoding (obviously). So the suitble type here should be unicode on Python 2 instead.

In term of this pull request, FSPath should always be Text, never Binary.

Can we say that paths in all wheel files must be UTF-8 encoded?
If so, then it makes sense to drop Binary from the declarations. It'll also simplify the handling of the INSTALLER file in the implementation, since I can rely on the fact that it'll be u"INSTALLER".

There was a discussion on this. I can’t recall where it’s made, but basically

Neither the wheel specification nor PEP 376 specifies what encoding files in the dist-info directory should be.
All existing metadata introspection implementations (e.g. pkg_resources and importlib.metadata) uses UTF-8.
All existing wheel creators use UTF-8 to write them
pip historically uses platform encoding to install wheels (this improved recently with my series of wheel encoding fixes). The combination of 2. and this basically means all pip-installable dist-info files are only ASCII-compatible.

So I’d say it should be expected at this point metadata files in a public wheel file should be in UTF-8, and a generic tool should assume this at all times.

Sounds fair to me. ^.^

Okai, I'm gonna go ahead and merge this, since no one has stated anything negative about this plan of action / PR. Plus, rebasing this and #12 to work around the CI issues introduced via #10 has been a pain. :)


Changing the Font Family

The font which was used here doesnot match the UI of the website so can you please assign this to me under @gssoc @apu52

@suraj-9849 The issue is not clear . Can you please raise your issue with the issue templates so that it will be more understanding .

Use this templates.
Sorry to close this issue for now.


An Issue of Fan wake Effect on FAST.farm

Hello, I have the following questions when running the FAST.farm file, The coordinates of my four fans as shown in the following figure, but the wind speed of the first three fans is still decreasing normally, and the last one is rising again. I can‘t understand this situation. According to the situation of wake effect, should the forth fan be smaller than the other? Thanks for your help.

Dear @Yangbyon,
Considering the wind turbine spacing of 500 m, and a mean wind speed (I'm estimating you are using) of around 8 m/s, it will take over a minute for the the wake from one turbine to hit the wake of the next turbine.  Thus, the start-up transient of the simulation (where wakes are fully propagated through the farm) is likely several minutes long.  But you are only showing the first 6 seconds of simulation results, so, these won't include wake effects yet.  The wind speeds you are plotting from each turbine are showing the ambient inflow turbulence before wakes from upstream turbines hit.  (The variation of wind speed between turbines is likely the result of the spatial variation of turbulence within the wind farm).
In general, I would recommend neglecting the simulation start-up transients before post-processing any OpenFAST or FAST.Farm results.
Best regards,


V2 : cannot change the shortcuts for reloading designs

Expected Behavior
Type in new shortcut, and use the shortcut to reload designs.
Actual Behavior
Cannot type in new shortcut.
Steps to Reproduce the Problem

Open V2 website
Pop open settings
Try to change the reload shortcut

Specifications

Version: V2
Platform: All
Environment: web

A few comments...
Probably one shortcut is fine IF the shortcut can be changed.
Mobile devices need to be able to change the shortcut, as SHIFT-RETURN is not possible from soft keyboards.

this fix has been released as part of V2 Pre-Release 2021 Jan 04. closing.

this fix has been released as part of V2 Pre-Release 2021 Jan 04. closing.


[Website]: documentation should have the ability to hide left/right sidebars

🚀 Feature Proposal

Motivation
To improve reading experience.
Example
https://jestjs.io/docs/expect#tomatchobjectobject
Pitch
A lot of unused space. And I have vertically rotated display.

Asked https://github.com/facebook/docusaurus/discussions/8071

You can already hide the left sidebar. I don't know a great use case for hiding the right sidebar.

I don't know a great use case for hiding the right sidebar.

To have more focus, more width for the content - and less scrolling. I do not always need the TOC.

You can already hide the left sidebar

Somebody needs to add a button to UI?

@Josh-Cena is it possible to hide the sidebar(s) via some UI button rather than config?

Not sure what that means, but the config enables you to have a button that toggles the sidebar...
Do you mean like a "user settings panel" where users can individually select whether to make the sidebar hideable or not? Then no, although that would be cool and is something I'doike to see, it's not possible yet.

Oh sorry, I misread the docs.
However, I tried it without success:
diff --git i/website/docusaurus.config.js w/website/docusaurus.config.js
index 66e8860952..94a62d8a08 100644
--- i/website/docusaurus.config.js
+++ w/website/docusaurus.config.js
@@ -54,6 +54,9 @@ module.exports = {
           },
           path: '../docs',
           sidebarPath: path.resolve(__dirname, './sidebars.json'),
+          sidebar: {
+            hideable: true,
+          },
           remarkPlugins: [
             [require('@docusaurus/remark-plugin-npm2yarn'), {sync: true}],
             require('docusaurus-remark-plugin-tab-blocks'),

[ERROR] ValidationError: "sidebar" is not allowed
[INFO] Docusaurus version: 2.0.1
Node version: v16.17.0

It's a themeConfig option, not a plugin option, so you can put it above this line instead:
https://github.com/facebook/jest/blob/cbf09923a329d26c636c8e78281254d6ed4c33bd/website/docusaurus.config.js#L160

That gets rid of the error, but it doesn't seem to do anything
diff --git i/website/docusaurus.config.js w/website/docusaurus.config.js
index 66e8860952..ebe4df04a2 100644
--- i/website/docusaurus.config.js
+++ w/website/docusaurus.config.js
@@ -157,6 +157,9 @@ module.exports = {
       textColor: '#fff',
       isCloseable: false,
     },
+    sidebar: {
+      hideable: true,
+    },
     navbar: {
       title: 'Jest',
       items: [

Oh, sorry! Forgot to mention it should be in another docs namespace:
diff --git i/website/docusaurus.config.js w/website/docusaurus.config.js
index 66e8860952..ebe4df04a2 100644
--- i/website/docusaurus.config.js
+++ w/website/docusaurus.config.js
@@ -157,6 +157,11 @@ module.exports = {
       textColor: '#fff',
       isCloseable: false,
     },
+    docs: {
+      sidebar: {
+        hideable: true,
+      },
+    },
     navbar: {
       title: 'Jest',
       items: [

There's no error because themeConfig allows unknown keys.

Ah cool, thanks! That worked.
4693cf5a69156a3c6fb6c9143b7ca99261e40244


Make React UI the default, keep old UI under /classic

The React app's assets are now served under /assets, while all old
custom web assets (including the ones for console templates) are now
served from /classic/static.
I tested different combinations of --web.external-url and
--web.route-prefix with proxies in front, and I couldn't find a problem
yet with the routing. Console templates also still work.
While migrating old endpoints to /classic, I noticed that /version was
being treated like a lot of the old UI pages, with readiness check
handler in front of it, etc. I kept it in /version and removed that
readiness wrapper, since it doesn't seem to be needed for that endpoint.
Signed-off-by: Julius Volz<EMAIL_ADDRESS>

@roidelapluie @brian-brazil

Pfft, got a weird unrelated test error, retrying:
goleak: Errors on successful test run: found unexpected goroutines:
[Goroutine 15531 in state chan send, with github.com/prometheus/prometheus/tsdb.(*SegmentWAL).cut.func2 on top of the stack:
goroutine 15531 [chan send]:
github.com/prometheus/prometheus/tsdb.(*SegmentWAL).cut.func2(0xc0001142c0)
	/home/circleci/project/tsdb/wal.go:600 +0xc5
created by github.com/prometheus/prometheus/tsdb.(*SegmentWAL).cut
	/home/circleci/project/tsdb/wal.go:599 +0x16c
]
FAIL	github.com/prometheus/prometheus/tsdb	185.399s

Since two people have at least had a look and there's one approval, I'll allow myself to merge this :)

is there a way to make classic ui default on > 2.23 ? it's working way slower but it might be me or my browser

There is no way , but feel free to open an issue about the exact problem you are experiencing and your scale so we can determine if that's a bug.


New fix

It's a while ago but i have picked up the development of this tool again 😊
Right now I have most of the functionality working and i am testing the online presence check.
Let's see where this goes.
If you want to support me, please think about sponsoring me. I have just set up my sponsor profile

I am happy for you to start again maintain this :)

Big Loran, welcome back, we need you. I downloaded the file, but it doesn't work.

Big Loran, welcome back, we need you. I downloaded the file, but it doesn't work.

Can you please create a separate issue with the error messages you see in the console? Thx!

The top bar does not appear. I send you the screenshots. Where should I look for the error message? I'm sorry
Whatsapp.docx

@ginevra2013, I have deleted your comment:

Create a separate issue
Ctrl-c/v the console error (check Google https://developers.google.com/web/tools/chrome-devtools/open)
Don't use docx files, it is too often used by cyber criminals, just past the screenshots in the issue

Don't take this the wrong way but if you don't know what the Chrome console is you better might look for a more production ready tool.


transformSync method configures systemjs type error

Describe the bug
Type systemjs cannot be assigned to type nodenext.

Input code
const { code } = transformSync(source, {
  jsc: {
    parser: {
      syntax: "typescript",
      tsx: true,
    },
    target: "es5",
  },
  module: {
    type: "systemjs",
  },
  isModule: true,
  sourceMaps: "inline",
});

Config
No response
Playground link
No response
Expected behavior
typescript check passed
Actual behavior
No response
Version
1.3.14
Additional context
No response

https://codesandbox.io/p/sandbox/holy-wave-pty9bo?file=%2Fnode_modules%2F%40swc%2Fcore%2Ftypes.d.ts&selection=[{"endColumn"%3A33%2C"endLineNumber"%3A852%2C"startColumn"%3A33%2C"startLineNumber"%3A852}]&workspace=%257B%2522activeFileId%2522%253A%2522clabdmgkh000al0g66fl2h2vt%2522%252C%2522openFiles%2522%253A%255B%2522%252FREADME.md%2522%252C%2522%252Fpackage.json%2522%252C%2522%252Ftsconfig.json%2522%252C%2522%252Findex.ts%2522%255D%252C%2522sidebarPanel%2522%253A%2522EXPLORER%2522%252C%2522gitSidebarPanel%2522%253A%2522COMMIT%2522%252C%2522sidekickItems%2522%253A%255B%257B%2522type%2522%253A%2522TERMINAL%2522%252C%2522shellId%2522%253A%2522clabdlmyx0007l0g6ffwi0jby%2522%252C%2522key%2522%253A%2522clabdlmtn005q3b6i87fdp7ct%2522%252C%2522isMinimized%2522%253Afalse%257D%252C%257B%2522type%2522%253A%2522PREVIEW%2522%252C%2522taskId%2522%253A%2522start%2522%252C%2522port%2522%253A5000%252C%2522key%2522%253A%2522clabdlffn000m3b6i1ywhj3xx%2522%252C%2522isMinimized%2522%253Afalse%257D%255D%257D

Please provide reproducible code via https://codesandbox.io/. See attached codesandbox works fine.

Sorry, I used '@ swc/wasm web`

@kwonoj https://stackblitz.com/edit/typescript-svlvz9?file=index.ts


[Proposal] Publish an architecture-independent websockets-11.0-none-any.whl

Dear community
I hope this finds you well 😄
I currently write a Python application on an ARMv7-based IoT computer running Linux. As the websockets package is only providing wheels for major architectures and platforms (such ARM64, x86-x64, etc.), it would be really great if you could provide a websockets-11.0-py37.py38.py39.py310.py311-none-any.whl on PyPi as well (without the speedups.c extension).
I currently build and use the pure Python wheel on my own. Nevertheless it would be great for other people, to have support for some more exotic or industrial platforms and not have to take the same steps I had to take. As websockets are more and more common in these fields, I also see quite some adoption.
Tell me what you think 😉
Best regards
Markus

Do you know if cibuildwheel can be configured to produce such wheels? That would be the easiest.
A quick search doesn't yield useful results. Searching for "none-any" doesn't work well :-/
If not, what is the equivalent of https://github.com/aaugustin/websockets/blob/8e1628a14e0dd2ca98871c7500484b5d42d16b67/.github/workflows/wheels.yml#L21 to produce such wheels?

Dear @aaugustin
Thanks for the great feedback 😄
Yes, cibuildwheel does not seem to support this.
I currently patch the setup.py to set extensions = [] and then run python setup.py bdist-wheel.
Please see my flow in Gitlab CI:
stages:
  - build

build:
    stage: build
    image: python:latest
    script:
      # Install Python build dependencies
      - pip install --no-cache-dir setuptools wheel
      # Clone the original websockets code from GitHub
      - git clone https://github.com/aaugustin/websockets.git
      - cd ./websockets
      # Checkout the current release
      - git checkout tags/10.4
      # Overwrite the setup.py to remove the speedup.c extension from building and adapt version name to 10.4
      - cp -fr ../custom/websockets/setup.py ./setup.py
      # Build the architecture-independent wheel (none-any)
      - python setup.py bdist_wheel
      - cd ..
      - mkdir ./wheels
      # Copy the genererated wheel to the top-directory
      - cp ./websockets/dist/* ./wheels
      - ls ./wheels

      # Install Poetry for building my own project
      - curl -sSL https://install.python-poetry.org | python3 -
      # Building project with Poetry
      - /root/.local/bin/poetry build
      # Download all dependency wheels with architecture independent code and copy them to ./dist
      # (use websockets wheel from top-level directory via --find-links option)
      - 'pip download --verbose --platform "none-any" --find-links ./wheels --only-binary=:all: -d ./dist/wheels .'

    only:
      - master
      - staging

    # Store all the wheels from the ./dist folder as an artifact for moving them to the ARMv7 based Linux computer later.
    artifacts:
      paths:
        - ./dist/*
      expire_in: 1 week

And the content of the setup.py:
# ./custom/websockets/setup.py

import pathlib
import re

import setuptools

root_dir = pathlib.Path(__file__).parent

description = "An implementation of the WebSocket Protocol (RFC 6455 & 7692)"

long_description = (root_dir / "README.rst").read_text(encoding="utf-8")

# PyPI disables the "raw" directive.
long_description = re.sub(
    r"^\.\. raw:: html.*?^(?=\w)",
    "",
    long_description,
    flags=re.DOTALL | re.MULTILINE,
)

exec((root_dir / "src" / "websockets" / "version.py").read_text(encoding="utf-8"))

packages = ["websockets", "websockets.legacy", "websockets.extensions"]

# ext_modules = [
#     setuptools.Extension(
#         "websockets.speedups",
#         sources=["src/websockets/speedups.c"],
#         optional=not (root_dir / ".cibuildwheel").exists(),
#     )
# ]

ext_modules = [] # Do not compile and include any external extension.

setuptools.setup(
    name="websockets",
    version="10.4", # Override version number
    description=description,
    long_description=long_description,
    url="https://github.com/aaugustin/websockets",
    author="Aymeric Augustin",
<EMAIL_ADDRESS>    license="BSD-3-Clause",
    classifiers=[
        "Development Status :: 5 - Production/Stable",
        "Environment :: Web Environment",
        "Intended Audience :: Developers",
        "License :: OSI Approved :: BSD License",
        "Operating System :: OS Independent",
        "Programming Language :: Python",
        "Programming Language :: Python :: 3",
        "Programming Language :: Python :: 3.7",
        "Programming Language :: Python :: 3.8",
        "Programming Language :: Python :: 3.9",
        "Programming Language :: Python :: 3.10",
        "Programming Language :: Python :: 3.11",
    ],
    package_dir={"": "src"},
    package_data={"websockets": ["py.typed"]},
    packages=packages,
    ext_modules=ext_modules,
    include_package_data=True,
    zip_safe=False,
    python_requires=">=3.7",
    test_loader="unittest:TestLoader",
)

Does this help you?
Best regards
Markus

Thank you very much. It helps.
I think the ideal way to do this would be:

Provide an environment variable to disable building the extension. This would happen in setup.py. Indeed, as far as I know, currently there is no mainstream alternative to setup.py (like setup.cfg) when one wants to build a C extension.

This step is trivial — the only question is naming the env variable — and it would already help you. You could set the env variable instead of patching setup.py.

Update the GitHub workflow to run python setup.py bdist_wheel right after python setup.py sdist and make sure the wheel is pushed to PyPI.

One thing to check before going live: do all installers prefer platform-specific wheels over generic wheels when both are available? Else, some people may get the unoptimized version when the optimized version is available for their platform.

Perfect. Sounds like a straightforward change, then. I'll do that for the next release.

I ran the workflow on the PR here: https://github.com/aaugustin/websockets/actions/runs/4584198510/jobs/8095537024
It produced a file websockets-11.0.dev0+gunknown-py37.py38.py39.py310.py311-none-any.whl which looks right.

websockets-11.0-py3-none-any.whl is available on PyPI.


Bump up pandas version in CI to 1.0.2.

LGTM if test passed

Thanks! I'd merge this now. FYI: @HyukjinKwon

+1!


Add policy for snapshot cache expiry and client session expiry

https://github.com/microsoft/FluidFramework/issues/7925 adds expiry to the snapshot cache. https://github.com/microsoft/FluidFramework/issues/7206 adds expiry to client sessions. We should add policy to control the behavior of these.
Ideally, there should be only policy (mostly in the driver) that controls the time after which snapshot cache should be expired and the session expiry time should be derived off of that.
For the snapshot cache policy, we may want to keep a default time (2 days currently) which is also the max and it can only be configured to a value smaller than that.

Relevant PR thread https://github.com/microsoft/FluidFramework/pull/8198#discussion_r754655027

After some offline discussion, we determined we do not want to link the snapshot expiry policy with the session expiry. We may change this in the future. The reasons for this are:

The snapshot expiry can change during the lifetime of a document, whereas the session expiry should not change.
If the snapshot expiry affects the session expiry, it would cause a side effect hosts may not be able to easily predict.


Added solution to Challenge-Twenty-Nine

Pull Request Template
All Submissions:

[x] Have you read and acknowledged our Code of Conduct?
[x] Have you checked to ensure there aren't other open Pull Requests

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes # (issue)
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made relevant changes to the documentation
[x] My changes generate no new warnings
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

@sid172014 did you mean to close the PR?

There's something wrong with this

Oh, I see

Thanks ! 🙏

Let me know if it appears on your Hacktoberfest profile after 15-20 minutes

Ye sure

@akebu6 Yes it did pop up on my hacktober profile

awesome!!


OpenAI Mock Backend

Overview

Add mocked backend for OpenAI testing.
Allow recording of requests to OpenAI to and audit log for mock updating.

Codecov Report

:exclamation: No coverage uploaded for pull request base (develop-openai-instrumentation@db63d45). Click here to learn what that means.
The diff coverage is n/a.

@@                        Coverage Diff                        @@
##             develop-openai-instrumentation     #929   +/-   ##
=================================================================
  Coverage                                  ?   81.36%
=================================================================
  Files                                     ?      190
  Lines                                     ?    19581
  Branches                                  ?     3401
=================================================================
  Hits                                      ?    15933
  Misses                                    ?     2669
  Partials                                  ?      979

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


How do I download the firmware?

Hello, how to download the firmware for the console r36s, to flash the flash drive?

Get the image from here: https://github.com/AeolusUX/ArkOS-R3XS
Follow the instructions here: https://ko-fi.com/post/Installation-Guide-for-ArkOS-v2-0-01272024-J3J6TVPH1

After updating the ArkOs firmware, Retroarch changed interface, it is very inconvenient for me to use it. And that's how it became.

How do I get it back to the previous one? Anyway, I've seen several themes on Amber Elec.


Do not allow bitcode on OS X target (fix Carthage dependecy failure).

Bitcode should be enabled for all targets except OS X. For Box this happens to be the same as Xcode 7.3's default (iOS = YES, OSX = NO), so the custom setting should just be deleted.
If ENABLE_BITCODE exists using Carthage with an OS X target will always fail with
target 'Box-Mac' has bitcode enabled (ENABLE_BITCODE = YES), but it is not supported for the 'macosx' platform

:+1:


feat: add support for non-storage elements

This commit adds support for field implementations that don't use a storage element.  The SystemRDL spec has a number of software and hardware access property combinations that end up with constant assignments or hardware assigns the value.
p.47 of the SystemRDL 2.0 spec has a table with the following entries:
field f { sw = r; hw = r;  };   Wire/Bus - constant value
field f { sw = r; hw = w;  };   Wire/Bus - hardware assigns value
field f { sw = r; hw = na; };   Wire/Bus - constant value

Sorry, I forgot about this yesterday when we reviewed the open PRs.  Will need to bump the tag.


Document pivot and unpivot operators

Description
This PR adds documentation for the PIVOT and UNPIVOT operators.
This PR has:

[x] been self-reviewed.

PIVOT and UNPIVOT are relational operators. I will add them to https://github.com/apache/druid/blob/master/docs/querying/sql-operators.md instead of https://github.com/ektravel/druid/blob/docs-pivot-unpivot/docs/querying/sql-functions.md.

@ektravel can you make a backport PR to 29.0 too? Thanks


Addition to PR #162

Yesterday, in the heat of the moment, I forgot the actual important part for the python 3 only release, sorry for that it was late :cold_sweat:
The kwarg in setup that tells PyPi, which python versions a package supports is python_requires, just for future reference, when you are going to deprecate the py34 support.

Thanks, fine.


GCP: Remove requirement for TARGET-INSTANCE object in AliasIP only use case

(Issue moved from: https://github.com/f5devcentral/f5-cloud-failover-extension/issues/15)
Reported by: @f5-applebaum
Use case is that you would like to failover only AliasIps (vs Forwarding Rules).
Currently, the failover requires TARGET_INSTANCE objects to be created which is only needed for Forwarding Rules.
Workaround is creating target instance objects:
https://cloud.google.com/sdk/gcloud/reference/compute/target-instances/create
gcloud compute target-instances create NAME --instance=INSTANCE [--description=DESCRIPTION] [--instance-zone=INSTANCE_ZONE] [--zone=ZONE] [GCLOUD_WIDE_FLAG …]

This is being tracked internally as:
AUTOSDK-195 - GCP: Remove requirement for TARGET-INSTANCE object in AliasIP only use case

Closing. This issue was resolved with release 1.2.


Update fr.json

"3 TP" can be misleading since there may be only 1 or 2 TP while not an O&R or triangle... "Up to 3 TP" or "3TP max" is better
Updating fr.json:
"Flyer" here is not a piece of paper ;-)
aircraft -> planeur (avion is for motorized aircraft
task	-> 	circuit
leg	->	branche
glide ->	finesse
glides  ->    transitions
circle	-> spirale or virage
...

You are right it can be misleading. Sadly the physical space does not allow more than a couple of characters and people are used to 3 TP. I reverted it after merging. Thank you for going through everything, really glad to have some help with french.


Test coverage is not at 100%

[ ] 100% test coverage on httpstan
[ ] 100% test coverage on pystan-next

It seems like there are more important things to work on right now.


getDragNode   function error in 2.4.0

Hi,
I tried migrating from  1.3.6 to 2.4.0, getting error during build  in below snippet
Angular version : 2.2.1
Property 'getDragNode' does not exist on type 'TreeModel'.
  drop: (tree:TreeModel, node:TreeNode, $event:any, {from, to}) => {

                 let tObj = tree.getDragNode();
                let sNode = tObj.node.children[tObj.index];
                let tNode = to.node;

                let resultLvl = tNode.level + ( sNode.hasChildren? 1 : 0);
                if(resultLvl < 3 ){

                    TREE_ACTIONS.MOVE_NODE(tree,node,$event,to);
                }else {
                    console.log('reject. Too many level');
                }
   }

Same here, is there updated doc section about it?

@tomalex0 I figured it out, fourth argument in mouse drop handler is { from , to }  <--- 'from' is an actual dragged node.

Hey guys,
2.X.X had breaking changes.
The docs are updated:
https://angular2-tree.readme.io/docs/drag-drop
And CHANGELOG.md specifies all changes and breaking changes between versions:
https://github.com/500tech/angular2-tree-component/blob/master/CHANGELOG.md


Fix generation of bibtex

Get last name of first author from profile

@celestemartinez can you add more context here so @haroldrubio can understand where to fix the bibtex?


large select

Seems like select with class="form-control form-control-lg" would look better with property set to height: 3rem; instead of height: calc(2.3125rem + 2px);

Hi @blue-eyed-devil input heights are calculated by
$input-height:                  calc(#{$input-height-inner} + #{$input-height-border}) !default;

here: https://github.com/twbs/bootstrap/blob/v4-dev/scss/_variables.scss#L350
Which makes sense since  .form-control is set to background-clip: padding-box; and borders should be calculated in pxs.
here: https://github.com/twbs/bootstrap/blob/v4-dev/scss/_forms.scss#L18

well it may make sense but this is how it look even in your documentation pages.

Duplicate of #23769.


[Fix] JSON decoder not properly decoding defaultConfigurationIsVisible in some projects

Resolves https://github.com/tuist/xcodeproj/issues/592
Short description 📝
This PR should fix decoding defaultConfigurationIsVisible (and other booleans) of multiple types of encoding (ie. plist encoded which encodes to a proper boolean or a normal pbxproj which encodes into a string).
Solution 📦
Try decoding it as a string like before, then an int, then a boolean and finally return nil if it cannot. Notice each try is marked with try? so it doesn't actually throw in case there is a type mismatch.
Implementation 👩💻👨💻

[X] Fix decoder process for booleans
[X] Test out in both pbxproj formats

Thanks for fixing this @tjwio 🙏


#50 Fixed credential name dose not show after using put-file command

Great work chasing that down!
Will sort out a release later this week.


Updates

Codecov Report

Merging #6 (a253f86) into master (dcb73a9) will decrease coverage by 0.83%.
The diff coverage is 96.25%.

@@             Coverage Diff             @@
##            master       #6      +/-   ##
===========================================
- Coverage   100.00%   99.16%   -0.84%
===========================================
  Files           10       13       +3
  Lines          295      360      +65
  Branches        41       42       +1
===========================================
+ Hits           295      357      +62
- Misses           0        2       +2
- Partials         0        1       +1

Impacted Files
Coverage Δ

falcon_auth2/utils/asyncio_compat.py
91.17% <70.00%> (-8.83%)
:arrow_down:

falcon_auth2/__init__.py
100.00% <100.00%> (ø)

falcon_auth2/backends/__init__.py
100.00% <100.00%> (ø)

falcon_auth2/backends/base.py
100.00% <100.00%> (ø)

falcon_auth2/backends/basic.py
100.00% <100.00%> (ø)

falcon_auth2/backends/meta.py
100.00% <100.00%> (ø)

falcon_auth2/getter.py
100.00% <100.00%> (ø)

falcon_auth2/middleware.py
100.00% <100.00%> (ø)

falcon_auth2/utils/__init__.py
100.00% <100.00%> (ø)

falcon_auth2/utils/classes.py
100.00% <100.00%> (ø)

... and 4 more

Continue to review full report at Codecov.

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


sudo output not necessarily in english

On a linux machine where sudo output is not english (e.g. variable LANG is set to de_DE.UTF-8), the method HardwareInfoUtils.isSudo() does not work properly

Hi,
It is extrange. In may case it does not change and my LANG in not english.
[~]$ sudo -n true
sudo: a password is required
[~]$ locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
What is your output if you do "sudo -n true"?
Thanks

Hi Javier,
on a suse linux (openSuSE 13.2 (x64)) of a colleague of mine, LANG is set to de_DE.UTF-8. This is what he tells me about sudo:
sudo -n true: sudo: Ein Passwort ist notwendig
sudo -V: Sudo-Version 1.8.10p3
Sudoers Policy-Plugin Version 1.8.10p3
Sudoers-Datei Grammatik-Version 43
Sudoers I/O plugin version 1.8.10p3

Ah. I just found this. Didn't try it yet
http://askubuntu.com/questions/357220/how-to-check-if-sudo-password-has-been-entered-for-this-terminal-session

Actually after submitting sudo -n true in bash, the return value is 1, when a password has to be provided. Otherwise it's 0.
Maybe that helps

Ok,  I will try the 'return value' approach this evening. I will keep you updated.
Thank you!

Hi Andreas.
Finally I developed another solution, based on output, which is empty in the case of sudo.
It will take a bit in order to be ready on Maven Central but you can already find the new version here:
https://oss.sonatype.org/content/groups/staging/org/jhardware/jHardware/0.6.1/jHardware-0.6.1.jar
Tell me if it works OK now.
Thank you

Hi Javier, just a short heads up:
The problem on my colleagues machine is still there (Version 0.6.1). But actually I think your fix should be working. So we will find out why it's not working on his machine and let you know. But this might take some days, because we are quite busy with other stuff right now. Sorry.

Hi Javier,
issue is fixed.
Thanks, Andi

Cool, I am glad it is fixed


How can I get my splash screen to work in development mode?

Hi I am currently trying to get a splash screen for my application.
So far I followed the docs https://tauri.studio/en/docs/usage/guides/visual/splashscreen. The splashscreen works as expected when I build the app for production, but when I start the app with tauri dev I get a segmentation fault (I think this happens when the close_splashscreen is invoked). Also I do not see the splash screen opening so I assume this is somehow related. my dev workflow is as follows:

cd frontend && yarn serve -> to open a vue.js app on localhost:8080
cd src-tauri && yarn tauri dev -> to start the tauri app in development mode

is there I way i can have my splashscreen also in dev?
this is the code i am currently using: https://github.com/happyshovels/double-shovel/tree/c23208766f1a555d017635fc7f0f36943d4955d1
my tauri info:
Operating System - Mac OS, version 10.15.7 X64

Node.js environment
  Node.js - 16.1.0
  @tauri-apps/cli - 1.0.0-beta.1
  @tauri-apps/api - 1.0.0-beta-rc.3

Global packages
  npm - 7.11.2
  yarn - 1.22.10

Rust environment
  rustc - 1.52.0
  cargo - 1.52.0

App directory structure
/frontend
/node_modules
/output
/src-tauri
/.git

App
  tauri.rs - 1.0.0-beta.1
build-type - bundle
CSP - default-src blob: data: filesystem: ws: http: https: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
distDir - ../frontend/dist
devPath - http://localhost:8080

thank you for your help :)

It works when I use cargo run in src-tauri instead of yarn tauri dev

So a couple things i noticed:
Rustc should be at 1.52.1
Api should be beta.1

Hi, thanks for the review :) I updated rustc 1.52.1 and the api to beta.1. Unfortunately, the issue still persists...

Actually I only needed the splashscreen to come around the white background issue ().
I found another workaround for this
.setup(|app| {

      let main_window = app.get_window("main").unwrap();
      // we perform the initialization code on a new task so the app doesn't freeze
      tauri::async_runtime::spawn(async move {
        sleep(Duration::from_millis(500));
        main_window.show().unwrap();
      });

      Ok(())
    })

and win the tauri.conf.json
"windows": [
  {
    ...
    "visible": false
  }
]

As this solved my original problem I will close this issue. thanks :)


Automatically determine if polling should be enabled to reduce CPU usage

I implemented a simple way to determine if polling should be used for watchiy based on the comments in the issue #96. Please review.
Closes #96
Note I've only tested this on Mac OS X, but it should work on other systems as well!

Coverage increased (+0.8%) to 91.732% when pulling cb2f5d139894153ffd1f5b87cb8cd1d3d81e7a4f on jeremija:jeremija-should-poll into a145c7cc0bc8a357d481af8c953bad54a0683563 on ForbesLindesay:master.


[Bug] Character Optimizer Substat Weights Don't Save

Description
On the Character Optimizer page, the values entered for the "Substat weight filter" and "Top % of weighted relics" are no longer saved and reset to defaults.
Steps to Reproduce

Enter a character optimizer page.
Change the "Substat weight filter" or "Top % of weighted relics" values.
Click "Start optimizer", click "Cancel".
Enter a different character optimizer page.
Return to original character optimizer page. The values will reset.

Expected Behavior
The set values used to save.
Actual Behavior
The values are reset.
Screenshots

Additional Information
This issue started with commit 2f5d890. Commit b09d6ea works as expected.

Thanks for the bug report! Deploying the fix in like 30 mins or so


Grafana Apache Echarts - Reinitialise chart

How to reinitialise Apache echarts on mouse over event in Grafana. Basically want to change some series properties and reinitialise the chart.

@viralui Use setOption() to update chart's options.
There is an examples in the documentation: https://volkovlabs.io/plugins/volkovlabs-echarts-panel/maps/geojson/#switching-between-maps


[fixed] Upgraded React.createClass(...) to ES6 classes

This PR reconciles https://github.com/reactjs/react-autocomplete/pull/225 and the current master branch.
React complains in the console because it's depreciating its React.createClass(...) syntax and separating its PropTypes module to its own package. This PR updates that.

I'd love to see this PR merged. But it seems 1) it is not synced with master anymore and 2) it brings more features than React update.
Could you please fix that to hope having it merged soon ?
Thx

@guillaumepotier It shouldn't have more features than the ES6 classes update. The git diff does look wonky though, since I pulled keyDownHandlers into the constructor to keep it as an object property. Maybe there's a better way?

No you're right. The wonky git diff made me think at first glance you added keyDownHandlers new features but you're right. Should be good, pulled your branch in my project and it works like a charm, without nasty React console error warning 👍

Hi! I really appreciate the effort here! I finally had time to sit down and do the required testing and research on this subject. I've published 1.5.5 which no longer uses React.createClass or React.PropTypes. I feel like I owe you an explanation since it seems like I just ignored your work and did the same thing as you. Here's my after-the-fact feedback:

PRs are best when they're small and do one specific thing. This PR contains two important changes that deserve to be reviewed in their own right, as well as a smattering of other things (like changing CJS require statements to ES import).
Similarly, keeping commits small and focused really helps speed up the review process. Ideally a commit should only do a single thing. I usually start by reviewing each commit individually, and do a final pass through using the full diff view ("Files changed" tab).
Another trick you can do to help the reviewer is to keep whitespace changes in separate commits. I do a lot of reviewing on the command line, so when I see a commit named "whitespace" or "indentation" and git diff --ignore-all-space returns nothing, I know I can safely move on to the next one.
The changes made to keyDownHandlers made the diff much harder to read than it had to, as well as introducing a (small) performance regression. Instead of creating each of the functions in keyDownHandlers every time Autocomplete is instantiated, I opted for a solution where they are available as a static class property, then invoked with the correct lexical scope by using Function#call (this was already in place).
Another small regression can be found in render, where the event handlers are being bound for every render. This can be avoided by binding the event handlers in the constructor.
The prop-types dependency should be listed in dependencies. One would think that the natural place would be peerDependencies, but I don't blame the React team for wanting to avoid the inevitable complaints that follow.
The change to prop-types needed a couple of alterations that were not at all obvious. The first was to exclude the dependency in the UMD build. The second was to update react-dogcen so the API documentation generator would continue to work.

I hope this can be taken as constructive feedback and not elitism or anything like that. Again, I really appreciate the work you've put in. I figured the path of least resistance was to just push my own changes, since it seemed like it was more important to get the changes out than to spend more time with PRs.

@CMTegner Lol, this isn't elitism at all and is a great resource to learn from. I'd actually like to thank you for taking the time to point out how this PR (and programming) could have been done better. I'll be referring to this next time I decide to contribute to an open repo.

Great, glad I could be of help! :)


Linear interp with NaNs in nd indexer

[x] Test added

When doing linear interpolatiion with an nd indexer that contains NaN's,  xarray previously threw a KeyError from the missing._localize function. This PR fixes this by swapping np.min and np.max with np.nanmin and np.nanmax in that function, ignoring any NaN values.

Thanks, @jenssss for sending a PR.
This looks good to me.
Could you add a line for this contribution to our whatsnew?

Looks good - if you want to go a step further you can probably do something along the lines of (untested):
if new_x.dtype in "mM" and LooseVersion(np.__version__) < LooseVersion("1.18") and new_x.isnull().any():
    raise ValueError("numpy 1.18 or newer required to use interp with datetime/ timedelta array containing missing values")
else:
    imin = ... np.nanmin(...)
    imax = ...

I misremembered the behavior of the old np.min with datetimes - see this comment: https://github.com/pydata/xarray/pull/3924/files#discussion_r407101544
Sorry for sending you down the wrong path. I can have another look tomorrow.

Okay, I removed the ValueError from my previous commit, so the content of _localize is now basically the same as in https://github.com/pydata/xarray/pull/3924/files#discussion_r407101544
I thought it better to use np.issubdtype(new_x.dtype, np.datetime64) instead of  new_x.dtype.kind in "mM" to check for datetime type. It's a bit longer, but I think it makes it more readable since you don't have to look up what dtype.kind is.

Thanks! I have two more suggestions:
Can you add an additional line with
(["2000-01-01T12:00", "2000-01-02T12:00", "NaT"], [0.5, 1.5]),

here:
https://github.com/pydata/xarray/blob/8313c3eb7e92c15a82a3ae8ba7dff7d49a37c309/xarray/tests/test_interp.py#L575
to have a test with a missing datetime.
Do you also want to add a note to the docstring, e.g. adding Missing values are skipped. Here:
https://github.com/pydata/xarray/blob/a36d0a1d4657c848dcdd76d0ecb9c783ad464057/xarray/core/dataarray.py#L1425
here:
https://github.com/pydata/xarray/blob/a36d0a1d4657c848dcdd76d0ecb9c783ad464057/xarray/core/dataarray.py#L1495
Does it also work for DataSets? Then maybe add to the docstring here:
https://github.com/pydata/xarray/blob/a36d0a1d4657c848dcdd76d0ecb9c783ad464057/xarray/core/dataset.py#L2603
and here:
https://github.com/pydata/xarray/blob/a36d0a1d4657c848dcdd76d0ecb9c783ad464057/xarray/core/dataset.py#L2731

LGTM. I'll merge in a day or two unless someone else has a comment.

thanks @jenssss I see this is your first PR - welcome to xarray!


Translations for character names are broken

The problem
Describe the bug
only some of the characters are automatically added to the dialogic_character_translations.csv file
To Reproduce
Steps to reproduce the behavior:

Go to the translation page in the settings
Click on Update CSV files
only some of the characters are added to the csv file

Expected behavior
all characters should be added to the csv file
System (please complete the following information):

OS: Windows 11
Godot Version: 4.2.1
Dialogic Version: 2.0 alpha 12

This sounds very similar to #1987 which might be fixed by a WIP PR already.

Oh, it is the same bug, sorry for the duplicate.


How to generate High Mutual Information use muliti-noraml-dense distribution?

I want to implement a benchmark which is used in smile/mine.
What is look like below, I guess the code should have the same style with bmi.benchmark.tasks.task_multinormal_dense,
but when I set rho = 0.99999 to get high mutaul information, I get Nan data.
def sample_correlated_gaussian(rho=0.5, dim=20, batch_size=128, cubic=None, device="cpu"):
    """Generate samples from a correlated Gaussian distribution with correlation rho."""
    x, eps = torch.chunk(torch.randn(batch_size, 2 * dim), 2, dim=1)
    y = rho * x + torch.sqrt(torch.tensor(1. - rho**2).float()) * eps
    if cubic:
        y = y ** 3
    return x.to(device), y.to(device)

What I met nan.

off_diag = rho
dense_task = bmi.benchmark.tasks.task_multinormal_dense(dim_x=3, dim_y=3, off_diag=off_diag)

Hi, bmi.benchmark.tasks.task_multinormal_dense has parameter off_diag, which has non-trivial constraints: the matrix $C_{ij}(\rho) = \begin{cases} 1 &\text{ if } i = j \ \rho &\text{ otherwise}  \end{cases}$ is positive-definite only for some values of $\rho$. This is highly non-trivial constraint and we should have updated the documentation...
If you want to generate many strong interactions, it will be probably better to use bmi.benchmark.tasks.task_multinormal_lvm, which has a guarantee to generate positive definite matrices. We describe this approach in Appendix D.2 of the manuscript.

def sample_correlated_gaussian(rho=0.5, dim=20, batch_size=128, cubic=None, device="cpu"):
    """Generate samples from a correlated Gaussian distribution with correlation rho."""
    x, eps = torch.chunk(torch.randn(batch_size, 2 * dim), 2, dim=1)
    y = rho * x + torch.sqrt(torch.tensor(1. - rho**2).float()) * eps
    if cubic:
        y = y ** 3
    return x.to(device), y.to(device)

Where can I find design of this, I guess the interation parameter is not same as bmi.benchmark.tasks.task_multinormal_lvm.
You know, there was a lot of test, they have a bencmark called staircase.

What I am trying to do is to validate estimators's expression on the extreme high mutual information from 5-13. I try the workflow first, that needs super complex setting, meeting numerous bugs.
So I am trying to implement by the minde way.
Here I found some problem.

When I implement by the method: the GPU usage is 70G, I guess there is some design of memroy leaking.

strength = [200, 650, 1100, 1550, 2000]
    task_list  = []
    for s in strength:
        task = bmi.benchmark.tasks.task_multinormal_sparse(dim_x=3, dim_y=3, strength=s)
        half_cube_task = bmi.benchmark.tasks.transform_half_cube_task(task)
        spiral_cube_task = bmi.benchmark.tasks.transform_spiral_task(task)
                #change task_name
        task_name = f"multinormal_sparse_{s}"
        half_cube_task_name = f"half_cube_multinormal_sparse_{s}"
        spiral_cube_task_name = f"spiral_multinormal_sparse_{s}"
        half_cube_task.task_name = half_cube_task_name
        spiral_cube_task.task_name = spiral_cube_task_name
        task.task_name = task_name

        task_list.append(spiral_cube_task)
        task_list.append(half_cube_task)
        task_list.append(task)
    for task in task_list:

        print(task)

        sampler_task = task

        print(f"Task {sampler_task.name} with dimensions {sampler_task.dim_x} and {sampler_task.dim_y} mi: {sampler_task.mutual_information} ")

        results = evaluate_task(args, sampler_task)

        results_tasks[sampler_task.name] = results
        print(results_tasks)```
  I refer this link:https://github.com/MustaphaBounoua/minde/blob/main/src/baseline/eval_baselines.py

Would switching to Snakemake be a possible solution? E.g., here there is an example workflow which can be used to generate data sets, save them to the disk, and run given estimators. This should limit the required memory (and also allow one to run multiple evaluations simultaneously when cluster is available, which is useful for large experimental designs) :slightly_smiling_face:

def sample_correlated_gaussian(rho=0.5, dim=20, batch_size=128, cubic=None, device="cpu"):
    """Generate samples from a correlated Gaussian distribution with correlation rho."""
    x, eps = torch.chunk(torch.randn(batch_size, 2 * dim), 2, dim=1)
    y = rho * x + torch.sqrt(torch.tensor(1. - rho**2).float()) * eps
    if cubic:
        y = y ** 3
    return x.to(device), y.to(device)

Where can I find design of this, I guess the interation parameter is not same as bmi.benchmark.tasks.task_multinormal_lvm. You know, there was a lot of test, they have a bencmark called staircase.

I don't think we have such a task in the benchmark. Probably the easiest option for adding it would be to implement the Sampler interface. (Alternatively, I think that one could construct an equivalent task using bmi.benchmark.tasks.task_multinormal_lvm, but this would require some algebra to figure out the parameters giving equivalent behaviour.)

Thank you for your kind reply. My experiments show that task_multinormal_sparse does not match the code I shared with you. This discrepancy arises because I am using this model to train on the F-DIME model.
https://arxiv.org/pdf/2305.20025
While the generated code remains stable, the BMI sparse code results in infinity. Therefore, I suspect that this code may be equivalent to a dense version. I will investigate further and provide feedback.
And I am curious about is f-dime implementation and smile implemetation in plan?

While the generated code remains stable, the BMI sparse code results in infinity. Therefore, I suspect that this code may be equivalent to a dense version.

Hmmm, I do not know where the instability may come – would you mind sharing a code example? Perhaps it's a problem with the float precision when calculating the decomposition of the covariance matrix (which is then very close to being noninvertible), but I'm not really sure...
If I understand the code you shared, the idea is to have several independent pairs of Gaussian variables $(X_k, Y_k)$, such that $\mathrm{corr}(X_k, Y_k) = \rho$. This can be implemented as:
from bmi.samplers import IndependentConcatenationSampler, BivariateNormalSampler

dimension = 10
correlation = 0.999

sampler = IndependentConcatenationSampler([BivariateNormalSampler(correlation) for _ in range(dimension)])

I see that there is also a parameter for a cubic transformation. This is probably the easiest to implement via:

from bmi.samplers import TransformedSampler

sampler = ...  # E.g., the code above to generate a base sampler, to be transformed
transformed_sampler = TransformedSampler(sampler, transform_y=lambda y: y**3)

And I am curious about is f-dime implementation and smile implementation in plan?

Thanks for sharing the paper! I was not aware of the $f$-DIME estimator. We haven't planned to add more neural estimators in the nearest future, with a current focus on implementing more expressive distributions. We can however accept PRs with JAX-based implementations, I think :slightly_smiling_face:

Hi, closing this issue for now – if more help would be needed, please free to reopen! :slightly_smiling_face: