Adding support for multiple queued DMA transactions

After adding the DIO/QIO SPI modes I have done some further experiments with enabling a queue of SPI in-flight transactions and the results so far are very promising. By using a queue of in-flight DMA transaction structures instead of having just one static in-flight transaction, the Esp32 DMA controller can be sent multiple SPI transactions to process instead of the current code, where it always waits for the previous one to be finished before sending the next. In the current code this is a bottleneck that slows down redraw speeds and can also lead to a jerky display especially while animating. This bottleneck also likely prevents LVGL from using both update buffers effectively as well (since it can block the update thread).
Where this really pays off though, is for drivers that have to send data line by line (because the hardware doesn't support 7an arbitrary rectangle). The FT81x is one such devices and unless the rectangle is full display width, it has to break up repaint region rectangle into individual SPI DMA requests for each line of the area in a fast loop. Enabling 20, 50 or even 200 SPI transactions to be in-flight at once has a very, very noticeable effect of the speed of the display. The difference is night and day in refresh rates especially when using animated controls, etc... It's the first time I have seen the FT81x animate while being consistently free of animation frame skipping. Here's a quick video of the before/after: https://youtu.be/HxO02oeiakw
Since I laid some of this groundwork a few months back this isn't looking to be too hard to add this feature. All the changes will be in disp_spi.c. This also means that if there are other drivers that also loop over or burst sending SPI data (which results in multiple DMA transactions), they will automatically benefit from queued DMA transactions. For instance, the FT81x driver needed no changes at all. I don't expect any existing drivers to break (or even know) either.
At this point I have this working and I should have it ready to submit in a day or so, once I put it through some more testing, cleanup, etc... It builds on the Dual/Quad pull request I submitted earlier.

I've got this one pretty much ready to submit but there are maybe a few things to consider first:

This really, really boosts the performance of the FT81x driver but I also think it will boost the performance of the existing drivers for the il3820, jd79653a, and uc8151d. I say "think" because they all appear to send multiple SPI DMA transactions in bursts and this change reduces the latency between the bursts of individual SPI transfers. However I don't have any of those displays so I can't directly test them myself - this is just from me reviewing the other drivers.

The changes are all in disp_spi.c and are not very complicated but they do have the potential to send individual SPI transactions at faster rates as it removes the default send & wait-for-pending-results pattern that exists now between calls (but drivers can still wait for pending results as necessary - that has not changed). It should not really matter to the existing drivers and they likely won't even notice in a negative way. It also does not require any changes to any existing drivers. However, it potentially speeds up the data streaming to them and if they can't handle it then they might need to be adjusted. If a driver can't handle getting data at a fast burst rate then the best solution would likely be to simply sprinkle a few more disp_wait_for_pending_transactions() calls where needed to give the display controller time to process the data. But it may also be worth thinking about only enabling it once drivers are checked out to make sure they are working OK. I don't expect them to break but I also can't test them all myself as I don't have those other displays.

Right now, I have not done made it a per-driver opt-in -- it is enabled for all drivers. But I could switch that and only enable it for the FT81x where I know for certain it works (and works really, really well). This would be easy to do and I would likely do it through #defines and not kconfig. Each driver could be tested and then opted in once checked out. Or maybe it does make sense to opt them all in now and get some testing done by others who can test them.

Another thing is, while the code is fairly simple I sort of feel that maybe a few sentences somewhere about the queuing design and how it works may be warranted as there are maybe a few subtle things that future coders should think about when revising the core SPI code. The current code base doesn't have anything like that now in comments or otherwise, so I don't really know where it is preferred to put something like that (I lean towards wanting it in comments in disp_spi.c myself - a few short paragraphs).

Lastly, I know other's time is sometimes limited and while this is separate from the current open pull request for DIA/QIO modes it also builds on that. My question is, should I leave it as separate to submit later or update my pull request to include it now? This new stuff isn't all that much but it might make it easier to look at it in isolation of the new DIO/QIO code as they are separate ideas.
Comments?

This really, really boosts the performance of the FT81x driver but I also think it will boost the performance of the existing drivers for the il3820, jd79653a, and uc8151d. I say "think" because they all appear to send multiple SPI DMA transactions in bursts and this change reduces the latency between the bursts of individual SPI transfers. However I don't have any of those displays so I can't directly test them myself - this is just from me reviewing the other drivers.

I have the IL3820, so I can test the new approach on that display, @huming2207 have contributed the other two drivers, so maybe he can test it, what do you think @huming2207?

The changes are all in disp_spi.c and are not very complicated but they do have the potential to send individual SPI transactions at faster rates as it removes the default send & wait-for-pending-results pattern that exists now between calls (but drivers can still wait for pending results as necessary - that has not changed). It should not really matter to the existing drivers and they likely won't even notice in a negative way. It also does not require any changes to any existing drivers.

It's great the new approach only changes code on the disp_spi.c file, this means it's really ESP32 specific and once we get the generic drivers done (hopefully one day soon) we can still using this approach.

However, it potentially speeds up the data streaming to them and if they can't handle it then they might need to be adjusted. If a driver can't handle getting data at a fast burst rate then the best solution would likely be to simply sprinkle a few more disp_wait_for_pending_transactions() calls where needed to give the display controller time to process the data. But it may also be worth thinking about only enabling it once drivers are checked out to make sure they are working OK. I don't expect them to break but I also can't test them all myself as I don't have those other displays.

I got some displays so I can test them.

Another thing is, while the code is fairly simple I sort of feel that maybe a few sentences somewhere about the queuing design and how it works may be warranted as there are maybe a few subtle things that future coders should think about when revising the core SPI code. The current code base doesn't have anything like that now in comments or otherwise, so I don't really know where it is preferred to put something like that (I lean towards wanting it in comments in disp_spi.c myself - a few short paragraphs).

Just saw the comments on the PR, thanks for documenting them, I don't feel particularly familiar nor expert on the ESP32 platform so having those comments is always nice to have at hand.

Lastly, I know other's time is sometimes limited and while this is separate from the current open pull request for DIA/QIO modes it also builds on that. My question is, should I leave it as separate to submit later or update my pull request to include it now? This new stuff isn't all that much but it might make it easier to look at it in isolation of the new DIO/QIO code as they are separate ideas.

That PR was merged yesterday, thanks for it 😄 .

Hello @C47D
I remember previously ESP32's SPI can't do DMA when it's in half-duplex, single-wire MISO+MOSI mode. But meanwhile, those e-paper panels are using those modes. It's fine if you don't read anything from the panel (i.e. assuming the panel is full-duplex, no MISO), otherwise you may have some issues when reading. The reading may be necessary for panel self-check and temperature measurement.
Jackson

Hi @huming2207
By single-wire SPI do you mean the same IO pin for both MISO & MOSI? Does the ESP32 SPI even support that? I don't recall seeing a reference to that support. Does this work now? That would have to be half-duplex mode if so, so would have the half-duplex mode DMA restrictions.
The main restriction with ESP32 half-duplex and DMA is you can't mix reading and writing in one transaction as the I/O pin modes typically have to switch in DIO and QIO modes. However, when writing this isn't an issue as they don't switch so you can do DMA writes all day in half-duplex mode just fine in SIO, DIO, and QIO configs. You can also do DMA reads as well with optional dummy byte setup in SIO/DIO/QIO. What you can't do is reading and writing in the same transaction even serially as a write followed by a read phase - unless the only writing you need to do is send address and/or command bits - this is the sole exception that the ESP32 supports. The FT81x driver actually does exactly this. Because both DIO and QIO modes use both pins in the same direction at a time, this also means the both DIO & QIO modes are half-duplex by definition. For SIO (standard MISO/MOSI) I don't think it really matters but the single read or write phase only is still enforced by the ESP32 SPI driver in half-duplex mode.
At least that is how I understand it to work.
Note that there seems to be a ESP32 SPI bug when reading in half-duplex mode that makes it only possible to read one byte at a time, at least when address and dummy bits are involved. I reported this to Epressif and haven't heard much back yet. I had to work-around it in the FT81x driver as this is exactly how reads need to be set up for it. The bug doesn't show itself in full-duplex mode when reading but then you can't use DIO or QIO mode.
I don't see any reason why you can't start up as full-duplex, tear down and re-init in half-duplex or vice-versa as long as the particular device supports that. disp_spi.c would need tweaking thought as it currently assumes that half vs full is a compile time setting.
The FT81x display where I write and test most of this stuff supports full, half, SIO, DIO, and QIO modes so I regularly put the SPI code through all the scenarios to make sure I haven't broken things. I've tested full-duplex writing/reading in standard MISO/MOSI mode and half-duplex separate writing/reading in SIO, DIO, and QIO modes and so far it keeps working!

Hi @davidjade

By single-wire SPI do you mean the same IO pin for both MISO & MOSI? Does the ESP32 SPI even support that? I don't recall seeing a reference to that support. Does this work now? That would have to be half-duplex mode if so, so would have the half-duplex mode DMA restrictions.

Sorry I was distracted by something else. I meant the 3-wire SPI, that is CS, SCLK and DATA where DATA = MOSI and MISO together. See this:  https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/spi_master.html#c.SPI_DEVICE_3WIRE

The main restriction with ESP32 half-duplex and DMA is you can't mix reading and writing in one transaction as the I/O pin modes typically have to switch in DIO and QIO modes. However, when writing this isn't an issue as they don't switch so you can do DMA writes all day in half-duplex mode just fine in SIO, DIO, and QIO configs. You can also do DMA reads as well with optional dummy byte setup in SIO/DIO/QIO. What you can't do is reading and writing in the same transaction even serially as a write followed by a read phase - unless the only writing you need to do is send address and/or command bits - this is the sole exception that the ESP32 supports.

Hmm ok, understood. Previously for our own projects, I always kept the same setting for every transaction so probably that was the actual issue that the read operations didn't work.
I will go for a try tonight for my JD79653A panels with your improvements. Thanks.
Regards,
Jackson

@huming2207
If you look at disp_spi.c you'll see that in half-duplex reading, the write transaction length has to be set to zero and the rxlength has to be valid or the ESP32 driver flips out.
That said, this 3WIRE mode is one thing I can't test but currently it's not supported by disp_spi.c either.


Add support for multiple runs of the same XSPEC model with different fit configurations

This should have been in a long time ago, and I swear I had an issue for this but I cannot find it, but currently the XSPEC fitting functions (and the storage of the results in files, and in XGA objects) have no way of knowing what the fit configuration was. Thus changing the fit configuration doesn't run a different fit, which is terrible.
For instance, say you wanted to fit an absorbed plasma emission model to a cluster, with metallicity frozen and with it not frozen, and compare how the results change - you could not do that right now without setting up two versions of the same source and telling it not to load fits on declaration.
The reason I've never done this is because it is complicated, and more importantly it will add another layer of complexity for the user accessing results, but it does need to be done.

The primary things that need doing are:

The storage structures for results in source classes and spectrum classes will need to have an extra layer under 'model name', with a key based on the fit configuration. All methods that 'add fit results' to an object will have to be modified to accept and use such a key.
Of course this means the key must be generated - this will be done internally in the fit functions and passed out through the xspec run decorator. It will be achieved through calling a function which takes the arguments/keyword arguments from the functions, filters out a defined (i.e. hard coded) set that we know will be common to all fit functions (src, radii, lum_en, etc.) and then assemble a key from everything that is left. There may also be a version of this function that can be applied to a fit function from outside (i.e. reading the function signature), as that will then be able to easily create the 'default key'.
The fit scripts, and results files, will need to include the key in their names - otherwise things are gonna get overwritten, XGA may get confused, bad stuff all around. Unfortunately this may have the butterfly effect of making the file names too long for unix, in which case I'm going to need to add an inventory file like the product directories have.
Finally the user is going to need to be able to retrieve the fit of their choice - if there is only one version of a model fit (whether it is default, or the configuration was altered from default) then all the get methods will return that single fit. This (I suspect) will be absolutely fine for most users, but in the case there are multiple configurations of a single model fit then the user is going to have to pass more information. I think they're either going to pass the key (which honestly is probably gonna be more use for internal XGA methods), or they can pass a dictionary of the parameters that they changed from default, which will then be used alongside the other, still default, parameters to assemble the right key (I think this is the friendliest I can make this process). That will probably necessitate writing a function that can construct default keys. I also suspect I'll need to link particular model names to particular fit functions (in a constant dictionary) in order for that to work.

No doubt there are many more details to work out, BUT HERE WE GO.

Will now need to add the same functionality to the Spectrum class - including for the storing of plotting information for the models and XSPEC versions of the spectra - also will change the view method. THEN I'll need to go back to the view methods of AnnularSpectra and change them also.

Not doing this yet, but the same process of using fit configuration keys will need to be applied to the fakeit simulations done using spectra - this is in essence issue #111

The view methods of AnnularSpectra are all a bit buggered - the view_annulus method has had the conversion process started, but I forgot that they are still very basic compared to the view method of Spectrum, and still can't plot anything if no fit has been done, which is daft. Maybe I'll just completely rewrite them later.

Settled on rewriting them later - will add a get_view method to Spectrum (if I haven't already done that, I can't remember), and make use of that for view_annulus.

Note-to-self - even though the XSPEC fit functions (or the ones in 'general' anyway) now generate and pass out fit_conf keys, I still need to incorporate that into the script and results file names. This will mean altering the '_write_xspec_script' function.

Now I've started down this path, I think the best option for running the cross arf fits would be to control it with an argument to the existing single_temp_apec_profile function, rather than having it in its own function as it is now.
That will necessitate some rewriting, but I just think it makes the most sense from the user point of view. I can also allow them to choose whether they want an initial run with the non-cross-arf implementation first (as always happens as it is currently configured) or whether they just want to jump right in and try to run the first fit with cross-arf.

Also, I think I'm going to have to allow different sources to have different fit_conf keys when running something like single_temp_apec, because I do allow there to be different start temperatures for a set of sources.

I want a way of knowing which arguments to an XSPEC fit function matter in terms of the definition of the fit_conf storage key. Currently those arguments are just defined within each function - this was an okay place to start, but I a) want to be able to access that information outside of the fit functions (i.e. in the fit_conf_from_function function that I'm writing) and b) worry that at some point we'll forget to update the dictionaries that are manually setup in each function.
As such I think I will abstract all those dictionaries specifying what information to include in the fit conf keys to somewhere else, and they will include null entries for arguments to the functions that don't matter, and that way each function can check that no new argument has been added to the function signature that we haven't considered including in the fit conf storage keys

I have found myself in a bad circular import situation - this is because of the function I created to help users construct fit_conf keys by only passing the parameters they changed.
What has happened is that now BaseSource imports that function, which in turn imports all the XSPEC fitting functions, which has this huge long knock on effect because they import the BaseSource class, so it is circular at initial import time.
I've been trying the TYPE_CHECKING constant that can be imported from 'typing' which I've only just heard of, but actually I've just thought of a better solution, I can do a local import of the function which is causing the problems in BaseSource.

So I think the reading in of XSPEC fits from disk (i.e. when they have been previously run, and are now stored in the inventory file) should now be fully functional again - the new XSPEC-fit inventory reading method seems to be working well APART from when trying to load in cross-arf based annular spectrum fits, that doesn't seem to be functional again yet,


Fix syntax error in @if conditional statement

Fixed a minor typo where an @if used = instead of ==.

Thanks Zac, good pickup!

Happy to help – Megatype is great, thanks for all the hard work!


Extra tutorial for directed PAGA

[ ] Additional function parameters, change functionality or change defaults?
[ ] New estimator in cr.tl.estimators?
[ ] New kernel in cr.tl.kernels?
[ ] New gene trend model in cr.ul.models?
[ ] New plotting function in cr.pl?
[x] Other?

In practice, many people may want to compute a directed PAGA, given PAGAs huge success as a general tool for trajectory inference (best performer in TI benchmarks). To highlight this feature in cellrank, it may be good to have an extra tutorial which is just called "directed PAGA". This will bring more attention to this really cool feature.

This is what I get for the directed PAGA:

I get this by first computing the PAGA using scvelo:
scv.tl.paga(adata, groups='clusters', root_key='root_states_probs', end_key='final_states_probs',
            use_time_prior='velocity_pseudotime')

and then
figure_kwargs = {'cluster_key': 'clusters', 'mode':'paga_pie', 'basis':'umap',
                'legend_kwargs':{'loc':'top right out'}, 'legend_loc':'top left out', 'node_size_scale':5,
                'edge_width_scale':1, 'max_edge_width':4, 'title': f'directed PAGA fate map'}
if save_figure: figure_kwargs['save'] = f'paga_pie.png'
cr.pl.cluster_fates(adata, **figure_kwargs)

To compute latent time/velocity pseudotime, call
scv.tl.recover_latent_time(adata, root_key='root_states_probs', end_key='final_states_probs')

Closed via https://github.com/theislab/cellrank_notebooks/pull/24


Fetch persons and fill to select in create coordinator page

Fetch persons and fill to select in create coordinator page
Screenshots:

Before
After


add endpoint to startAllIndexes

This will be needed to get back all indexes before the server went down. Specially in case of a crash a k8s operator could issue this call once the server is back up to restore its state and data from the last commit point in s3.

The k8s readiness probes run periodically to ensure that the instance is ready to handle incoming requests. Can we also make sure that this endpoint can return a 200 if it's invoked multiple times after the indices have started?


go/build: MatchFile excludes x_js.go when GOOS != js

#102835 adds "js" to build.goosList, causing build.Context.MatchFile to exclude files named *_js.go when GOOS is not "js".
We have a number of existing files that match that pattern (mostly generated code containing embedded JavaScript strings), and there are probably more in the world at large. This seems like it might be too common a suffix to change at this time.

Approximately a dup of #26329, though there we just documented this change.
If we change this, presumably by removing js from goosList in go/build/syslist.go, there are 13 xxx_js.go files in the standard library that may need explicit build tags.
We could consider changing the GOOS name from js to something less common.  But the use of build tags in file names is an ongoing problem that will bite us again in the future.  We could simply freeze the current set, and require explicit build tags going forward.
CC @neelance @bradfitz

The specific case where this arises in Google is that we have a go-bindata-like tool that reads x.js and writes x_js.go. Looking at the public go-bindata, though, it just writes one file bindata.go, which doesn't hit this problem. I'm also looking through a very large GOPATH with tons of packages pulled in, and it looks like there are at least a few external projects that already had *_js.go files for use with GopherJS.
It may be that we can leave this as-is and document. I'll report back once I have more data (still downloading).

I think we should explicitly and prominently document that naming files with underscores that aren't instructions to go build is discouraged and likely to lead to broken code in the future. I think this has been apparent to a lot of us for a long time now.
Personally, I really like the feature of naming files with os/arch and I'd dislike it if we moved in the direction of requiring explicit build tags in more situations.

FWIW we did document this in the release notes: https://tip.golang.org/doc/go1.11#wasm

I think we should explicitly and prominently document that naming files with underscores that aren't instructions to go build is discouraged and likely to lead to broken code in the future.

If we go that route then I would argue that Go 2 should always interpret files with underscores as containing build instructions, regardless of the current set of GOOS values.

I am not convinced we should disallow all use of underscores except for GOOS/GOARCH. I think it would be fine for a project to have storage_aws.go, storage_azure.go, etc. If we do put the go version into the module file (#23969) then the go command could set the GOOS/GOARCH list appropriately when looking at files in that module. That would future-proof things (at least as far as not breaking builds) without imposing additional requirements on users.
Back to the question of how common the _js suffix is.
I have a list of the most commonly imported ~1000 open source repos that I use for testing vgo, plus ~100 of the projects that import the most other things. I found:

80,931 packages (29,281 after removing vendored code)
412,486 files (143,346 after removing vendored code)
51 *_js.go files (8 after removing vendored code)

It looks like these are all for GopherJS or the new wasm/js support:
$ find . -name '*_js.go' | grep -v /vendor/
./github.com/jtolds/gls/stack_tags_js.go
./github.com/pborman/uuid/node_js.go
./github.com/google/uuid/node_js.go
./github.com/gogo/protobuf/test/int64support/object_js.go
./github.com/goadesign/goa/uuid/uuid_js.go
./github.com/goadesign/goa/metrics_js.go
./github.com/mattn/go-runewidth/runewidth_js.go
./github.com/gopherjs/gopherjs/compiler/natives/src/internal/poll/fd_poll_js.go
$

That suggests it's fine to document and close (already done).


[FIX] Add missing _id suffix to processing status file column mappings

Fixes #369

Changes proposed in this pull request:

Since https://github.com/nipoppy/nipoppy/pull/382, the Nipoppy processing status file now uses column names bids_participant_id and bids_session_id instead of bids_participant and bids_session. This PR brings the column names expected internally by the CLI for this file into alignment with the Nipoppy schema.

Checklist
This section is for the PR reviewer

[ ] PR has an interpretable title with a prefix ([ENH], [FIX], [REF], [TST], [CI], [MNT], [INF], [MODEL], [DOC]) (see our Contributing Guidelines for more info)
[ ] PR has a label for the release changelog or skip-release (to be applied by maintainers only)
[ ] PR links to GitHub issue with mention Closes #XXXX
[ ] Tests pass
[ ] Checks pass

For new features:

[ ] Tests have been added

For bug fixes:

[ ] There is at least one test that would fail under the original bug conditions.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 98.372%

Totals

Change from base Build<PHONE_NUMBER>3:
0.0%

Covered Lines:
967

Relevant Lines:
983

💛  - Coveralls


Structured benchmark - GPT4 results

In the interest of getting things out quickly I've gone ahead and just got the code and results necessary for reproducing the GPT-4 results.
In this PR we should have:

README documenting all the steps to reproduce.
Necessary model handlers and additional code necessary to run the models.
Modal files for deployment for both structured and unstructured generation.
Data from all the runs so that re-running is not necessary.
A few Python notebooks so that visualization and error analysis is easier to perform.

I'll add the code for Mistral in another PR.

I'm almost done wrapping up the mistral part of this and realized that there were some small issues so I'm going to close this and the open another PR once the mistral stuff is added.


generate a chinese doc fail

generate a chinese doc fail with --include-example

Should be fixed with the new release.


why Multi-threaded only works for fragment downloads

Checklist

[ ] I'm asking a question and not reporting a bug or requesting a feature
[X] I've looked through the README
[X] I've verified that I'm running yt-dlp version 2022.07.18 (update instructions) or later (specify commit)
[ ] I've searched the bugtracker for similar questions including closed ones. DO NOT post duplicates
[ ] I've read the guidelines for opening an issue

Please make sure the question is worded well enough to be understood
why Multi-threaded only works for fragment downloads and doesn't work for non-fragment downloads?
and is there any other way to use concurrent download?
Provide verbose output that clearly demonstrates the problem

[ ] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
No response

Use external downloaders like aria2c

how to use Multi-threaded for fragment downloads and aria2 for non-fragment downloads?

--downloader aria2c --downloader m3u8,dash:native -N 8

does wget2 support HLS/DASH or not? #4169

Maybe.. Obviously, it depends on whether such a feature is implemented. Currently HLS/DASH support is only added to ffmpeg/aria2c, but PRs to add it to any downloader is welcome


'onRequestChange' event on IconMenu doesn't trigger on some cases

We met an issue when using IconMenu. See below behaviors
(A) onRequestChange event is triggered if we do mouse click on:

DropDownMenu (from material-ui library)

 (native HTML tag)

Outcome: onRequestChange is triggered param reason = 'clickAway'
(B) onRequestChange event isn't triggered if we do mouse click on:

 (HTML tag), but we stopped event bubble up in order to simulate the behavior from <Link> in react-router library
FlatButton (from material-ui library)

Is case (B) a bug (at least for FlatButton component) when it doesn't trigger the event?
This is sample code for (A) and (B). The log message onRequestChange appears in browser console for (A) and not for (B):
class MyIconMenu extends React.Component {
  _onRequestChange() {
    console.log('onRequestChange')
  }

  _onLinkClick(e) {
    // Simulate behavior from <Link> in react-router library
    e.preventDefault()
  }

  render() {
    return (

        <IconMenu onRequestChange={this._onRequestChange}>
          ...
        </IconMenu>
        <DropDownMenu>
          ...
        </DropDownMenu>
        <FlatButton label="Click no trigger onRequestChange" />
        Click no trigger onRequestChange

Other content

    )
  }
}

Versions
Material-UI: v0.15.0-alpha2
React: v0.14.7
Browser: Chrome v49.0.2623.112

@codeaholicguy is this connected to #3931 ? It seems like these issues can be consolidated as they both are related to problems with the onRequestChange event for IconMenu

I think this is related to a check in the IconMenu on line 181 and line 196 where it checks is open is not null, I believe this should be onRequestChange instead of open. Does that make sense or am I missing something?

I'm running into this as well.

Same problem here

We have removed the IconMenu component on the v1-beta branch, instead, we suggest using lower level API, like the Menu.


Fix headers parsing to ServerRequestFactory

Q
A

Is bugfix?
✔

New feature?
❌

Breaks BC?
❌

Fixed issues
-

This PR fixes the following:

Prevents duplication of the Host header in the request.
Adds parsing of headers prefixed with REDIRECT_ and CONTENT_.
Removes empty headers in the request, this is especially true for Content-Length and Content-Type.
Makes the first letter of each word in the header name uppercase when parsing, like the getallheaders() function.

👍


Login doesn't work anymore as of last week or so

If you press the button for the plugin, it just opens the client and doesn't enter the ID or passwords. Not sure if this is just my end but it very recently stopped working after a couple months of usage. Love this plugin so hope it gets fixed soon!

This should be fixed now: https://github.com/BackTrak/StreamDeckLolLoginPlugin/releases/download/v<IP_ADDRESS>/com.zaphop.lollogin.sdPlugin.zip
I have submitted it to the StreamDeck store, and the new version should go up in a week or so.
Thanks,
Nick.

Awesome! Thanks for updating so quickly. I’ll install this version manually to get back to using it. Cheers


feat: token price caching

Add caching to token price requests with revalidation every 10 minutes. Cached request saves ~300ms of initial load.
Before:

After:

:tada: This PR is included in version 1.172.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


chore(main): release 0.1.7

:robot: I have created a release beep boop
0.1.7 (2023-03-28)
Dependency Updates

deps: bump github.com/onsi/ginkgo/v2 from 2.9.0 to 2.9.1 (#114) (af9ff42)
deps: bump github.com/onsi/ginkgo/v2 from 2.9.1 to 2.9.2 (#124) (58531b2)
deps: bump github.com/onsi/gomega from 1.27.2 to 1.27.3 (#113) (21fd029)
deps: bump github.com/onsi/gomega from 1.27.3 to 1.27.4 (#117) (15d244f)
deps: bump github.com/onsi/gomega from 1.27.4 to 1.27.5 (#123) (c56eb11)
deps: bump sigs.k8s.io/controller-runtime from 0.14.5 to 0.14.6 (#129) (03a2c06)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/statnett/controller-runtime-viper/releases/tag/v0.1.7 :sunflower:


Migrate unparsed_json to NULL engine

NULL engines: https://clickhouse.com/docs/en/engines/table-engines/special/null#null
ClickHouse's proposed JSON flow: https://clickhouse.com/docs/en/integrations/data-formats/json#using-materialized-views
Build an example using this pattern

Also add --allow-unparsed <boolean> flag to explicitly use the unparsed_json table

Will not change the default engine type, it is incompatible with JSON:

Closed by #68


Pass vars to entry in _readFile method

See same in a active fork unzipper here:
https://github.com/ZJONSSON/node-unzipper/blob/master/lib/parse.js#L126


Delete VCL.Menus from uses(it is not used in project)

Very great lib!
Library works in FireMonkey Windows aps(tested)!

Removed in an other commit


(formal) model and explain (implementation) tradeoffs for process and IPC/signaling api

After knowing that Posix signaling and process api is very bad (not yet implemented though), I now finally understand why the Windows one is considered only slightly better: https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87151933. I think I should come up with a better (formal) model and explain (implementation) tradeoffs.

Moved to https://github.com/matu3ba/sandboxamples/issues/7, so closing.


Improve Asset Browser+ file selection

Has to provide for future integration of Asset Store.
maybe provide 2 options for simple, quick browsing of recent files plus full file system access

Once we have done some work on the Public Page, perhaps we can get back to this one. @gmarinov

I think we should probably move this up in the priority queue a bit, as the existing one is in pretty bad shape, unfinished, undesigned, and broken.

When uploading assets, once upload is completed, uploaded item should be auto-selected.

@annarosavizor sure, that is how it is planned to work for single image upload. Obviously if you select and upload multiple images, then that maybe doesn't make sense  (how to know which one you wanted to use), but for single image, of course.

Upload is still broken in Safari as of today.

Given this will be an interim approach, we should probably discuss how to best handle this. Maybe we don't need to fully implement the new (well 8 months old) design, but we need to at very least fix the currently broken one.


Add providers

closes #9
closes #21
This simply updates the supported embeddable webistes as seen in the wiki: https://github.com/torch2424/link-drops/wiki/Supported-Providers
Also, I frames were really non responsive, so this has been fixed, and works much better now!
Lastly, Embedly has been removed completely to save us some cash.

HOWEVER
I may have introduced a bug, where a div needs to be clicked in order for the in-viewport to work. This may be something regarding it's css I added. As I tried removing the html and it did not fix. My computer was acting very wonky the day I discovered this. But please do not pull if the problem persists.
EDIT: This is not because of this pull request, I am actually having the problem even on the current live production at linkdrops.com. As stated above it may just be my device, however I created an issue for it: #58

In review

--- Sizing
Youtube videos do not size properly.
Instagram imbeds do not size properly.
Wikipedia imbeds do not size properly.
Twitter imbeds do not size properly.
Gist imbeds do not size properly.
Kickstarter imbeds do not size properly.
--- Claimed to work in Wiki ---
Amazon imbeds do not show up.
Vine imbeds do not show up.
Vimeo imbeds do not show up.
Spotify imbeds do not show up.
--- Used to work, now broken ---
Soundcloud imbeds are no longer working.
Looks like this pull is far from ready, or the wiki should be updated. Either one.

@julianpoy
--Sizing--
I thought they looked fine being portrait, but I'll go and add css for them individually to fix that.
--Claimed to work in Wiki--
Are you sure it's not because of what I said in my OP.I tested all of these right now, and they all worked beautiful. Note for ones that did not start in the viewport, I had to click the link, and then go back for them to show up. It is a bug that is not because of this branch that was introduced into master, can needs to be fixed.
--Used to work, now broken --
Again, see the OP. I tested this working just fine.

Finished now is EXCELLENT to pull in . EXTENSIVELY tested on my end. going to work on that bug now

I fixed the bug I am referring to in another branch. twas a super easy fix, and I'll do the offest thingy you wanted while I am at it :)

#59 has been merged. Can you pull master into this branch, so that I can retest and verify all is well?

Pulled in yo!

Coolio. Will check this out and pull in if it works :)

--- Sizing ---
Youtube videos do not size properly.
Gist imbeds do not size properly.
--- Claimed to work in Wiki ---
Amazon imbeds do not show up.
Spotify imbeds do not show up.
--- Used to work, now broken ---
Soundcloud imbeds are no longer working.
https://www.dropbox.com/s/mg7rqdh2ycy8akv/Screenshot 2015-09-20 09.31.39.png?dl=0

@julianpoy We are going to have to do this in person. I tested this for like 2 hours, and got everything working. something is up with your machine, everything wors on all of mines. And I dont quite understand what's wrong with the youtube size

Did you see the screenshot?

These are the links I used:
https://soundcloud.com/oftheothertime/moments-in-takyon
https://open.spotify.com/track/18sbrkncm1bTPAv2pzsVGM
http://www.amazon.com/Schleich-14601-Giant-Turtle/dp/B001O2QW9G/ref=sr_1_1?ie=UTF8&qid=1442766332&sr=8-1&keywords=turtle
https://www.youtube.com/watch?v=A_7phE0RtbU

The soundcloud song can't be embedded period

Yes I saw the screenshot. Could you please explain to me the youtube thingy? and the spotify did work, just with play.spotify, not open.spotify, so I'll add that too

I wanted to avoid using just amazon.com/ , so I did some more deep linking, but you seemed to find a place where you can avoid /gp/product.

Most products I just looked at dont use /gp/product. Perhaps because Im using prime?

As for youtube: the box is far off-center

@julianpoy perhaps, but everything should be fixed now!

Yo, added some more centering to the youtube thing. but honestly, I cant replicate it

I notice that you replaced play.spotify.com with open.spotify.com. We need to handle both.

Honestly we need to be able to detect a lot of possibilities. We are going to be putting it out to users who will not be careful about what they paste

It does handle both. the code is currently:
<div class = "embed"
            ng-if = "(dump.content.indexOf('https://play.spotify.com/') > -1)
                || (dump.content.indexOf('https://open.spotify.com/') > -1)"

and I got the youtube thing, its the card size that's acting weird with the column thingy

I fixed it.

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

I made width auto hahaha

Width auto will inherit width 90%, therefore duplicated code

Whats up with soundcloud?

okay cool. Well is everything working for you?

Does your song settings match this?

The thing is, on master, my song embeds.

Okay, then we're going to have to use the soundcloud api then. Right now I'm doing homework, I'll switch it back to the soundcloud api from master

Oh gotcha, sounds good.

I switched back to the soundcloud api to make your song work <3

Woo!


Authentication flow fails when redirecting during sign-in on the Contributor Console.

When users attempt to authenticate via email on the Contributor Console, the page hangs after redirecting during the sign-in process. The expected behavior is for the sign-in process to complete and proceed seamlessly. However, authentication via LFID (e.g., use case: vthakurs LFID) works as intended.

Steps to Reproduce:

Click sign agreement on gerrit|github
Proceed to sign either with individual or coporate contributor options
Choose Email as the authentication method.
Enter the email and proceed with the sign-in process.
Observe that the page hangs after redirecting.

Expected Behavior:
The sign-in process should complete successfully, and the user should be redirected to the appropriate page or console after signing in.

Actual Behavior:
The page remains hanging, and the sign-in process does not complete.

Environment:

Platform: Contributor Console
Authentication Method: Email
LFID Authentication: Working (example: vthakurs LFID)
Email Authentication: Fails

Impact:
Users authenticating via email cannot access the Contributor Console, impacting usability and adoption for email-based users.

Attachments:

@nickmango I have tested on dev and working file with login with Gmail
PFA
Screencast from 28-11-24 07:37:42 PM IST.webm

lfx-header-v2.js:3 Refused to load the script 'https://www.googletagmanager.com/gtm.js?id=GTM-K4CSDQH' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-eval' 'unsafe-inline' https://cdn.dev.platform.linuxfoundation.org/lfx-header-v2.js https://cdn.platform.linuxfoundation.org/lfx-header-v2.js https://cdn.dev.platform.linuxfoundation.org/lfx-header-v2-no-zone.js https://cdn.staging.platform.linuxfoundation.org/lfx-header-v2-no-zone.js https://cdn.platform.linuxfoundation.org/lfx-header-v2-no-zone.js https://cdn.dev.platform.linuxfoundation.org/lfx-footer-no-zone.js https://cdn.staging.platform.linuxfoundation.org/lfx-footer-no-zone.js https://cdn.platform.linuxfoundation.org/lfx-footer-no-zone.js". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
@luismoriguerra kindly help look into this

https://pcc.dev.platform.linuxfoundation.org/?error=access_denied&error_description=matching platform username missing in SSO directory&state=NGZHXy1MNTZPV1lBeThCZFBZSF9WalBreTFDS0o0cmRfNDdCVzdqbTdlVA%3D%3D

@alyeldegwy We got the above error when loading the contributor console as per our observation this error is in the lfx-header-v2. Please take a look.
( This occurs when cookies are disabled for the browser )

Tested multiple times on dev site & found that it is working fine at my end, So updating this issue status


Apply on branches

Is it possible to make it explain difference between branches ?
Useful in case of merges, or to explain what the commited code in a specific branch is about. (feature, bugfix etc..)

This is an idea I've been playing with. It started with thinking about summarizing PRs, but a more primitive way of implementing it would be to generate a summary for branch diffs.
The challenge here is that it is possible for the diff to be quite large in a PR, spanning multiple commits across many files.
Also, it might be beneficial to provide commit-by-commit context to the AI, but am not sure what would be the best way of doing that.
I'll try to get a build a basic working version for experimentation

@jnsahaj Alright, I understand the complexity. But that same complexity is present for commits as well.
Maybe something we can learn from this repository ?
https://github.com/Codium-ai/pr-agent/blob/main/pr_agent/algo/pr_processing.py
I stay available if help needed ;)

This is interesting. I glanced over the way it handles large PRs and I think I get the idea. Thanks for the share, I'll start working on a prototype


Permissions

Coverage decreased (-0.72%) to 67.35% when pulling f0af087a598be5f8786067d6df6ef5c8e36198dc on permissions into 8747c57aa9f5684d2b13f52f769e8a30cbe11fd4 on development.


Improve navigation and UI/UX

UI, UX and navigation are not optimal and sometimes clunky, it would be nice to do a bit of redesign and polish to have a more streamlined interface (that is also mobile friendly), where elements have better positions and usage is more intuitive.
Elements that can be improved :

Navigation menu (unintuitive to click on your profile picture without any indication of a hidden menu)
Custom video player (buttons and elements are not placed very well)

Unintuitive navigation menu partially fixed by adding explanations on the homepage : 5193a2d98ba9151c5feb357060066451d3d7bd83


Failure to boot on latest bluefin-dx-nvidia image

Describe the bug
Upon rebasing from ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts@sha256:1cc9d1e1df47145c58601fd004f80aa6dd8342666dfc9949bc9631dea45d531c to ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest@sha256:ad7d306b70df3fbf7a772efb34858aa445e71366b76205259276a04325b07eda and rebooting, I am stuck on a gray screen with my cursor frozen near the corner of the screen.
What did you expect to happen?
I should have booted into a functioning Bluefin Fedora 40 install.
Output of rpm-ostree status
~
❯ rpm-ostree status -v
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts (index: 0)
                   Digest: sha256:1cc9d1e1df47145c58601fd004f80aa6dd8342666dfc9949bc9631dea45d531c
                  Version: 39.20240606.0 (2024-06-06T16:54:30Z)
               BaseCommit: 2be86a9b225ff5ad4ef21e6921d4d0ddb1774998c9bd6cd7a5f5ce6e59908b30
                   Commit: ac05b93335eb9f648da933edb1eb1545c9d33448b11ec3d3c19f924cd41f1ff6
                           ├─ 1password (2024-05-21T13:11:59Z)
                           ├─ copr:copr.fedorainfracloud.org:g3tchoo:prismlauncher (2024-05-08T12:24:33Z)
                           ├─ copr:copr.fedorainfracloud.org:hikariknight:looking-glass-kvmfr (2024-04-10T22:38:22Z)
                           ├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2024-03-18T11:54:48Z)
                           ├─ copr:copr.fedorainfracloud.org:uriesk:minecraft-wayland-glfw-git (2024-04-22T04:03:54Z)
                           ├─ fedora (2023-11-01T00:12:39Z)
                           ├─ google-chrome (2024-06-05T19:42:28Z)
                           ├─ rpmfusion-nonfree-nvidia-driver (2024-05-24T08:09:32Z)
                           ├─ rpmfusion-nonfree-steam (2024-04-20T13:10:44Z)
                           ├─ updates (2024-06-06T10:28:27Z)
                           └─ updates-archive (2024-05-17T02:42:10Z)
                   Staged: no
                StateRoot: default
          LayeredPackages: 1password glfw prismlauncher waydroid

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts (index: 1)
                   Digest: sha256:1cc9d1e1df47145c58601fd004f80aa6dd8342666dfc9949bc9631dea45d531c
                  Version: 39.20240606.0 (2024-06-06T16:54:30Z)
               BaseCommit: 2be86a9b225ff5ad4ef21e6921d4d0ddb1774998c9bd6cd7a5f5ce6e59908b30
                   Commit: 232d4f07ece56ea4f78e196d4a1cd41d62a867b40548734da41a468663d26c89
                           ├─ 1password (2024-05-21T13:11:59Z)
                           ├─ copr:copr.fedorainfracloud.org:g3tchoo:prismlauncher (2024-05-08T12:24:33Z)
                           ├─ copr:copr.fedorainfracloud.org:hikariknight:looking-glass-kvmfr (2024-04-10T22:38:22Z)
                           ├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2024-03-18T11:54:48Z)
                           ├─ copr:copr.fedorainfracloud.org:uriesk:minecraft-wayland-glfw-git (2024-04-22T04:03:54Z)
                           ├─ fedora (2023-11-01T00:12:39Z)
                           ├─ google-chrome (2024-06-05T19:42:28Z)
                           ├─ rpmfusion-nonfree-nvidia-driver (2024-05-24T08:09:32Z)
                           ├─ rpmfusion-nonfree-steam (2024-04-20T13:10:44Z)
                           ├─ updates (2024-06-06T10:28:27Z)
                           └─ updates-archive (2024-05-17T02:42:10Z)
                StateRoot: default
          LayeredPackages: 1password glfw prismlauncher waydroid

Output of groups
~
❯ groups
pmc wheel docker

Extra information or context
Rebasing to the non-NVIDIA image works just fine, just without NVIDIA proprietary hardware acceleration support

Were you able to switch to another virtual terminal?
Right now this sounds like gdm failed to start properly if a gray screen appeared.

Ctrl+Alt+F1-12 had no effect whatsoever.

We made some changes to our mutter package to remove an issue with XWayland. This may have been present with X directly as well.
Is this behavior still occuring?

I actually traded in my NVIDIA GPU for an AMD one a little bit after filing this ticket so I wouldn't have to deal with NVIDIA driver shenanigans anymore... sorry I can't check to see if the issue is still there anymore

Welcome to the promised land!

I'm still seeing this issue on an RTX 3080.
rpm-ostree output

❯ rpm-ostree status -v
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest (index: 0)
                   Digest: sha256:a1adf996664c0a79d07b0611b9b45e81ceb1be8c02056ea355054a572e24fa7b
                  Version: 40.20240622.0 (2024-06-23T01:13:53Z)
               BaseCommit: 29cf678691c97729d9e58da5739ec9176dbdc0cdbc448d08bb34c503e036a926
                   Commit: 3ccba737be0e287ea65c6a20834501e0f53ff0811f3393ca0defc2928824e68d
                           ├─ copr:copr.fedorainfracloud.org:hikariknight:looking-glass-kvmfr (1970-01-01T00:00:00Z)
                           ├─ fedora (1970-01-01T00:00:00Z)
                           ├─ updates (1970-01-01T00:00:00Z)
                           └─ updates-archive (1970-01-01T00:00:00Z)
                   Staged: no
                StateRoot: default
                Initramfs: '"-I /etc/crypttab /usr/lib/modprobe.d/nvidia.conf"'

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest (index: 1)
                   Digest: sha256:326e4a33d701be28ab461ee689cbda54bd02f3b9ab348a53ace08978c8fcb205
                  Version: 40.20240620.0 (2024-06-21T16:54:44Z)
               BaseCommit: f573ecf49af489cc81724c6c92237f6c596cffc406427a2f4e28a4f86d23142a
                   Commit: 95f483fc9f6c500d1e7a0d97ecdd249227d80bf208282c7a565fd8de331a0668
                           ├─ copr:copr.fedorainfracloud.org:hikariknight:looking-glass-kvmfr (1970-01-01T00:00:00Z)
                           ├─ fedora (1970-01-01T00:00:00Z)
                           ├─ updates (1970-01-01T00:00:00Z)
                           └─ updates-archive (1970-01-01T00:00:00Z)
                StateRoot: default
                Initramfs: '"-I /etc/crypttab /usr/lib/modprobe.d/nvidia.conf"'

Your local initramfs is likely not needed.
The Nvidia image has the drivers already loaded into the initramfs.
You also have input of today's image. Are you able to VT switch? If not, but you are able to ssh into the machine, you may be affected by Nvidia's atomic flip issue.

@m2Giles I am seeing this problem as well with
 ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts
                   Digest: sha256:92ecae19614229f0a398519c50c8c73ed1d87e8c42c4973368a7063b026fd8c7
                   Version: 39.20240811.0 (2024-08-11T05:55:49Z)

but not with rollback on
 ● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts
                   Digest: sha256:19d05e73414b3b694bf62487149390934783f3f7e443099a3faabe6edd7bdaa7
                  Version: 39.20240804.0 (2024-08-04T05:54:01Z)

any hints?

Are you able to VT switch?

no, I'm not able to switch to a tty, however I can make changes to the system by booting into the older image

note: I ended up buying an AMD GPU and rebasing to the normal bluefin-dx image, which resolved the problem

note: I ended up buying an AMD GPU and rebasing to the normal bluefin-dx image, which resolved the problem

that appears to be the best solution!


Removed genesis doc from node struct, retrieve from genesis doc provider

Addresses #1290.
The genesis doc was loaded and kept within the node datastructure. The only place where this field was used in CometBFT was to retrieve the genesis timestamp.
Additionally, there is a getter for this field which I changed to load the genesis document from the genesis document provider.
Thanks @andynog  for flagging this and suggesting the change.

PR checklist

[ ] Tests written/updated
[x] Changelog entry added in .changelog (we use unclog to manage our changelog)
[ ] Updated relevant documentation (docs/ or spec/) and code comments

As per a discussion (@andynog, @jmalicevic, @mzabaluev), this PR might not be too much beneficial at this point from a performance perspective. There are no real benefits at first by adding these changes. I believe we can close it.


Iframe display issue on newest browser versions

The iframe element with preview blocked by security policies.
Chrome:

Content Security Policy: The page’s settings blocked the loading of a resource at https://glisseo.localhost/admin/appearance/theme-inspector?preview=button&variation=primary (“frame-ancestors”).

Firefox:

Refused to frame 'https://glisseo.localhost/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'none'".

Found source of the problem: https://github.com/wodby/nginx/blob/60fb809439800a553bab54729465d97e91e8226b/templates/includes/defaults.conf.tmpl#L11 NGINX_HEADERS_CONTENT_SECURITY_POLICY: "frame-ancestors: 'self'" is resolving the problem.


[2.0.1] Update to SQLitePCL.raw 1.1.8

Fixes #428
See also aspnet/EntityFrameworkCore#9813

Closing per the discussion here: https://github.com/aspnet/Microsoft.Data.Sqlite/issues/428#issuecomment-329871867


Changed screenshot for #43

Issue No: #43

At this point, I think the same information is displayed in the expanded version of the processing modal and the https://api.refine.bio/processors/ link. Can you update the copy below the screenshot to reflect this?


Analytics event: EXTERNAL_LINK_CLICK

Description
The goal is to

add the type for event EXTERNAL_LINK_CLICK to the Events type.
https://github.com/WordPress/openverse/blob/839418fabb0972ec3c3ccf48c72fd64cbba03cb9/frontend/src/types/analytics.ts#L12

fire this event from the appropriate location in the codebase using the useAnalytics composable.
https://github.com/WordPress/openverse/blob/839418fabb0972ec3c3ccf48c72fd64cbba03cb9/frontend/src/composables/use-analytics.ts#L11

Reference
https://github.com/WordPress/openverse/blob/839418fabb0972ec3c3ccf48c72fd64cbba03cb9/rfcs/analytics/20221006-implementation_plan_frontend.md?plain=1#L287-L305
Additional information

RFC
Example usage in VHomeGallery.vue

Do we want to send several events when the user clicks on an external link that is also captured by the other events?
For example, we have #1085 for when the user clicks on "Creator" link. But it is also an external link. So, should we send both "EXTERNAL_LINK_CLICK" and "VISIT_CREATOR_LINK" on a click? Or should we have a filter in this issue implementation so that if the user clicks on an external link, we check if it's in one of the special cases (creator, license), and only send EXTERNAL_LINK_CLICK if it isn't? @dhruvkb , @zackkrida , @sarayourfriend , @krysal ?

In my opinion, EXTERNAL_LINK_CLICK is supposed to be like a catch-all fallback in case the click is not being captured by any other category. I see little value in sending more than one event for any interaction.

Agreed that we should not send duplicate events for effectively the same interaction. We'll need to keep in mind that to get the full picture of external navigation we will need to aggregate several events, however.

@dhruvkb, it seems that the component in the description for this event was taken from another event.
Do we really need the component to be sent with this event?
I implemented this event locally inside the VLink component. However, this way the component that I get from useComponent is VLink - which is absolutely useless. If we send the event from the parent of the VLink to be able to get the parent component - this might not be a very useful component anyways (I think url property might be more useful for this event than the component), and would mean a lot of code duplication all over the app.
What do you think, @WordPress/openverse-frontend ?

@obulat I think for this event just knowing the page it was made on is sufficient.

If there are multiple instances of this one a single page then an additional disambiguator is probably useful, but only if we care about whether a particular external link location is more useful to users than others. The external source links on the no results page and on a page with results are the same page and it wouldn't be possible to know if the user clicked through the dropdown without some way of disambiguating which instance of that external link they clicked.
I wrote more about this idea in this PR review which seems not to have been addressed. @obulat Your review dismissal mentions opening another issue for my feedback. Did that issue get created? It isn't linked from the PR so I wasn't sure what the result was.


Can phonegap-plugin-push be updated on the npm repo?

Expected Behaviour
The plugin plays nicely with other plugins like firebase-analytics.
Actual Behaviour
When trying to install the plugin, it fails with the following message:
Failed to install 'phonegap-plugin-push': CordovaError: Version of installed plugin<EMAIL_ADDRESS>does not satisfy dependency plugin requirement<EMAIL_ADDRESS>

Reproduce Scenario (including but not limited to)
Install the latest cordova-support-google-services plugin e.g. 1.2.1 and try installing the plugin.
Steps to Reproduce
As above
Platform and Version (eg. Android 5.0 or iOS 9.2.1)
Android: 8.0.0, ios: 4.5.5
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
N/A
Cordova CLI version and cordova platform version
cordova --version                                    # e.g. 6.0.0

8.1.2<EMAIL_ADDRESS>cordova platform version android                     # e.g. 4.1.1
8.0.0
Plugin version
cordova plugin version | grep phonegap-plugin-push   # e.g. 1.5.3

2.2.3
Sample Push Data Payload
N/A
Sample Code that illustrates the problem
N/A
Logs taken while reproducing problem
N/A
Description
The main problem is that the last update of this plugin on the NPM repo is 9 months old (as at 27th Feb 2019), so it contains old versions of the dependencies, which prevents it from installing, when there are newer versions of the dependency plugins installed. The only way I can get it to install is to roll back the dependent plugins by several versions e.g. I'm stuck with having to use firebase-analytics v11 when the latest version is v17.3.
Can this plugin be updated on the NPM repo with up to date dependency versions, please?

It looks like plugin.xml was updated after version 2.2.3, so while this is fixed in git, that fix is not reflected when using npm. Instead, you need to use the git URL when adding the plugin:
cordova plugin add https://github.com/phonegap/phonegap-plugin-push.git

It'd be great if a new version could be cut so that npm accurately reflects the most recent version of plugin.xml.

FYI for anyone coming across this thread before this plugin has been brought up to date.
The way I fixed it for my configuration was to do the following changes (in both the plugins and node_modules version of the files):

In plugin.xml make sure the following lines match the version on your project (in v2.2.3 the line numbers are: 42, 46 and 85):
    <preference name="FCM_VERSION" default="17.3.+"/>   <dependency id="cordova-support-google-services" version="~1.2.0"/>   <framework src="FirebaseMessaging" type="podspec" spec="~>3.3.1"/>

In docs/src/ios/PushPlugin.m, change:
    @import FirebaseMessaging;
to:
    @import Firebase;
and delete or comment out the following line:
    @import FirebaseAnalytics;
this is because the newer version of Firebase only requires the base module to be imported, as it does everything else itself.

Then remove/install the ios platform to be sure the plugin changes have been pulled in.

Now it should play nicely with Firebase, instead of causing many days of headaches.

Installing a pinned version also mitigates this issue
cordova plugin add<EMAIL_ADDRESS>Then reinstalling, seems to do the trick, i.e. rm -rf node_modules plugins platforms

Ah man! I spent 2 hours just to see that the npm version is old and I was wondering why the plugin.xml for push is not exactly same as the git version which was creating problems with fcm analytics version.

Is there any chance of this being updated any time soon?

It appeared that this plugin has been abandoned, so I switched to using the cordova-plugin-firebase-lib plugin, which solved all the compatibility problems I had with the various stand alone firebase plugins as it has built-in interfaces to all the various Firebase services I need to use. You can install it as normal from the npm repo.

@dfiggtns what about ios?

It's a cordova plugin, so it works for both android and ios.

It uses fcm for ios push. Looks like we have to go via fcm route for ios also.

Note that using FCM for iOS is not a viable option for many people. Just as one example, for anyone using Mixpanel (and cordova-plugin-mixpanel), FCM cannot be used for iOS.
It would be great if any of the maintainers of this project could chime in.

I don't believe this project is maintained any longer, so it might be worth looking for an alternative solution. I'm not familiar with Mixpanel, but OneSignal's push service might be worth looking at, if you can't use FCM directly.


Changes Meta from a type to an interface

This allows extending the interface to define custom meta types within your own implementation.
declare module "@ladle/react" {
  export interface Meta {
    myCustomMeta: string;
  }
}

Is this technically a breaking change?

@tajo I'm not aware of any reason that using this as an interface instead of a type would be a breaking change. The only difference I'm aware of when the type is just an object is that types don't allow being extended, but interfaces do.
Is there a particular reason that the experts in this file are mostly types, not interfaces?

Is there a particular reason that the experts in this file are mostly types, not interfaces?

Not really. Are other types that would make sense to convert into interfaces?

I think it would be nice to have most of them be interfaces by default so they could be extended or inherited if someone finds a reason to.
I guess the type that I've had a couple of issues with wouldn't be fixed by having it be an interface, and looking at it now, it's already an interface anyways. (Talking about the Story type - it out to inherit React.FC<Partial<P>>, since there's no guarantee the args were acutally specified anywhere. Kind of a tangent, though - I probably ought to open an issue for a discussion about this since there might be other ways to address it).
Since the Meta is there to allow custom values, it would be cool to be able to narrow that type. StoryDefault would be nice as an interface, too, because then I could do something like require Meta is provided, for example.
If add-ons or plugins are officially supported at some point, this will be more important, I think.

Because TypeScript will always perform declaration merging by default for interface but not for type,  the decision whether to use one of the other comes to how that type would be used by the consumers.
For example, a design system library may define an interface Theme with some base shape and this would allow consumers to define their own Theme. This way declaration merging would kick in and both codebases can rely on the same type. No need for consumers to create their own AppTheme and then wrap all the library functions.
On the other side, if the type is not meant to be extended in this way then creating an interface could potentially cause issues because of accidental declaration merging with user types. Declaration merging cannot be prevented.
I do not know enough about Ladle to say which types should interfaces but hopefully the information above can help you make that decision.

@rareyesdev thanks to shining light on this
with that in mind I think it makes sense to turn Meta into interface since that datastructure is meant to be customized with ladle defining some baseline properties
StoryDefault might make sense as interface too
I'll make these changes with v3, planning to release it with Vite v5 in a month or two (I think they are planning September release)


Classifier

This re-creates the classifier branch, primarily using the classifier-glob-entities. table.py is added back along with other improvements.

That's Rob's README - should I update it for this PR to be approved?

all imports that are src should have gamechangerml infront i.e. gamechanger.src.
it looks like src is at the root level of the repo which is not the case

Yeah, that is what I am saying-- for some reason Github is not showing that the version you are submitting is in conflict/deviates from the one on dev, both of which are gamechanger-ml/README.md and so Github should be catching the differences, but is not.  Thus my suggestion of "There might be other changes I am not aware of as well. Might be worth rebasing off of dev and re-dropping the contents of this PR in the appropriate location."

Yeah, that is what I am saying-- for some reason Github is not showing that the version you are submitting is in conflict/deviates from the one on dev, both of which are gamechanger-ml/README.md and so Github should be catching the differences, but is not. Thus my suggestion of "There might be other changes I am not aware of as well. Might be worth rebasing off of dev and re-dropping the contents of this PR in the appropriate location."

Understand. My content source is src. I cloned, pip install . but import gamechangerml or variants fails. Replacing dataScience did not work. I'll see what I can do.

I caught it. It seems I pulled gamechanger-ml prior to there being the gamechanger content root.


seas fails when passing inputs to ora, & fgsea

A thin wrapper function implemented in gCrisprTools fails when invoking the seas command:
https://github.com/RussBainer/gCrisprTools/blob/bfab1de2ff055e5005d8026817c4766af4c3ba9b/R/sparrow_integration.R#L185-L187

@RussBainer I think we fixed this one, right? If so, feel free to close.

Complete. Thanks for the attention, @lianos


Animate line: unable to see line on map

L7 Version: 2.0.34
Platform: ReactJS 16.13.0, Node.js v13.9.0, W10.

I am unable to see lines on Animate Line example (here). I tried with different broswer with no success.
If I try to use China mirror site, I can see lines (here).
When I try to use CodeSanbox example from both website, I am also unable to see lines (both are redirecting to the same codesanbox page).
When I try to use in ReactJS (in local) I am also unable to see lines.
If I try to switch to L7 2.0.0 version (for example) on CodeSanbox, I can see lines animated.
Could be some mismatch between all mirrors and a regression with 2.0.34?
Thanks for your answer.

sorry   Update website delay
before
 layer..color('color', v => {
        return `rgb(${v[0]})`;
      })

now
layer .color('color', v => {
        return `rgb(${v})`;
      })


2.8.0不兼容10.15，导出失败，希望解决一下，十分感谢！！

2.8.0不兼容10.15，导出失败，选择完导出文件夹后插件崩溃，无法导出，希望解决一下，十分感谢！！

嗨，有个办法可以解决：
打开你的终端粘贴下面的代码执行（可能会要求你输入开机密码）：
sudo xattr -r -d com.apple.quarantine /Users/${USER}/Library/Application\ Support/com.bohemiancoding.sketch3/Plugins/Sketch\ Measure.sketchplugin/Contents/Sketch/SMFramework.framework/SMFramework

Here is a possibly easier way to let a quarantined plugin to run. See the instructions here https://www.3dquakers.com/forester-on-catalina/ but imagine that it's describing sketch-measure-latest instead of 'Forester.'
You will be reminded that you may be compromising your machine's security. I make no claim that doing this is safe or wise or anything. Do it at your own risk.
I don't know how to reverse this, either, which would be a nice thing to know.

楼上终端粘贴代码不管用


update vulkanalia dependency in tutorial

version 0.21 doesnt have the vulkanalia::bytecode::Bytecode struct.

Thanks for your contribution, merging a previous PR seems to have made this change already.


Support non-local Java compiler use in mixed Java/Scala compilation

We need this feature to support SemanticDB generation (#2227) via a Java compiler plugin in mixed Scala/Java projects.
We already introduced non-local Java compilers in #1988. This change now also allows the use of a non-local Java compiler in mixed Java/Scala modules, if any -J option is given.
As compilers are cached, I added the hashCode of the relevant runtime javacOptions to the cache key.
I took the opportunity to remove non-relevant options from the existing Java compiler cache, to reduce the amount of cached compiler instances.
/CC @ckipp01 who implemented #1988.

Currently, we maintain two different caches, one for Scala/Mixed usage, and one for Java-only usage. But technically, the same Java compiler can be used in both setups.
Thus we could avoid holding additional Javac instances in the Scala-compilers-cache, by retrieving the instance from the javac-only-cache first.

Currently, we maintain two different caches, one for Scala/Mixed usage, and one for Java-only usage. But technically, the same Java compiler can be used in both setups.
Thus we could avoid holding additional Javac instances in the Scala-compilers-cache, by retrieving the instance from the javac-only-cache first.

I think we should work on this separately, as it probably involves further refactoring. We currently cache Compilers which is a pair of Scala and Java compile tools, whereas we want to re-use the same JavaTools in multiple Compilers.


scroll screen size problem

Report
i have replaced the contenview in the example with my own viewCotrollers
it works fine when the app loads and i change the tabs but when i click on the menu items
the screen width is wrong and it does not scroll to the end!
it works fine on iphone xs but in larger screen sizes like iphone xs

plus or ipad the size is wrong when the menu is clicked
when i change
self?.scrollView.frame.width
to
UIScreen.main.bounds.width
it makes the tab size better but with a padding on the sides
 segmentioView.valueDidChange = { [weak self] _, segmentIndex in             let contentOffsetX = UIScreen.main.bounds.width  * CGFloat(segmentIndex) changed:",self!.segmentioView.selectedSegmentioIndex)             self?.scrollView.setContentOffset(                 CGPoint(x: contentOffsetX, y: 0),                 animated: true             )       segmentioView.valueDidChange = { [weak self] _, segmentIndex in            let contentOffsetX = UIScreen.main.bounds.width  * CGFloat(segmentIndex)                self?.scrollView.setContentOffset(                 CGPoint(x: contentOffsetX, y: 0),                 animated: true             )

Hi,
may be you did this in viewDidLoad(), try viewDidAppear()

Hi,
may be you did this in viewDidLoad(), try viewDidAppear()

hi
i moved the code from viewwillappear to viewDidAppear
but still the same problem
there is a problem with contentOffsetX!


using @@ with & for full-text searches

I can't find a way to escape the ampersand such that it's passed through to postgres properly.  If I run my query via the cli, I get the expected result.  Running it via postgrest does not. It seems to ignore the & completely and only match on the term preceding it.
Is there a way to workaround this?

I have answered my own question. Ampersand can be replaced with +%26+.


Add module-info

Summary
We should create a real java-module for this library.
The quickwins I tried, using eclipse and intelliJ to do so did not work. I got strange compile issues
Tasks

Create module-info with a minimal set of dependencies
Test / Document it properly

integrated into master, thx sven


WL-4322 : anonymous coursework project

Manage Candidate ID and additional notes.
Sample, html, zip and more
Oak extends our provider

Can one of the admins verify this patch?

This branch doesn't currently merge, are you going to update it for the comments?

Yes we wanted to update all according to the last comments. They were from some time ago, but I think we were waiting your confirmation with some refactoring (https://github.com/ox-it/sakai/pull/67#discussion_r72432819).
Can you confirm this, please? And we will update all as soon as possible.

How is this going?

Are there any changes that have been made that aren't on this pull request?

Also seeing the same test failures that are present on the Sakai PR locally.

I've got my fixes in a branch here at the moment: https://github.com/ox-it/sakai/tree/WL-4322


How to use 'as access' filter to set access rules for Yii2 modules?

How to use 'as access' filter to set access rules for Yii2 modules?
For example:
I have Profile module and I want to restrict access to that module from unautorized users. On stackoverflow I found some answer that I can use 'as access' filter:
'modules' => [
    'roles' => [
        'class' => frontend\modules\profile\Module::className(),
        'as access' => [
            'class' => 'yii\filters\AccessControl',
            'rules' => [
                [
                    'allow' => true,
                    'roles' => ['@'],
                ],
            ],
        ],
]

Ok, but I cant find anithing about 'as access' usage in oficial yii2 guide(
Where can I finde more info about that?
And how to set this rules not in config file but in Module class itself? Is it possible?
I can't finde doc about this also.
Thanks.

It's here (in the last paragraph): http://www.yiiframework.com/doc-2.0/guide-concept-behaviors.html#attaching-behaviors


Move TaskDrivers to execute like OO Commands

TaskDrivers today work on the concept of doing everything they can to work on massive data-sets in parallel without having write contention.
The downside is that all data must be consolidated during a consolidation phase at the beginning of the frame which leads to at least a one frame delay if going from TaskDriverA to TaskDriverB.
To ensure consistency and prevent endless refactoring of ordering, we've made it so that it's always a one frame delay.
In practice we've seen that this isn't the most ideal way to use them. TaskDrivers tend to go deep with many Sub Task drivers to enact all the functionality required to complete a "Task".
This could lead to situations where it takes a noticeable amount of frames to get through the initial work to start doing something.
The change now is to have on-demand consolidation and run all TaskDriver jobs in order based on their Top level Task Driver.
All TopLevel TaskDrivers would get a chance to execute. They would schedule their jobs and so would their sub task drivers and so on down the chain. Developers would be able to order that scheduling as they know the flow of events to be able to efficiently burn through as many jobs as possible in one frame, only stopping when going to a job that will need to process the data over time or when complete.

Should we re-evaluate this as we get to use TaskDrivers in more situations?
I am a bit hesitant to remove the bulk processing efficiencies before we're sure that Task Drivers do in fact tend to go deep.
It may be that we have two variants or modes for them to operate in.

Yeah sorry, I should have been more clear. I do think there are two variants.
Before we had Driver vs System.
Driver jobs are unique to the Driver instance. You have 10 TaskDrivers, there are 10 Driver jobs and we'd run all 10 of those at the same time but on the 10 different pieces of backing data.
If you have one driver with 10,000 elements, and the other 9 each had 1 element, you'd still have 10 separate jobs running with a pretty big imbalance.
So we offered the concept of System jobs. If the data was the same and the processing was the same, we could have 10 TaskDrivers that all wrote to the System and we'd have 10,009 elements in one backing data. We'd run one job to process which could efficiently split the 10,009 elements across however many cores were needed to handle the chunk size.
The downside that we're running into is that in order to do that, we have to choose (or have Unity choose for us) a point in time during the frame to execute a given type of TaskDriver/System combo's jobs. And that leads to the one frame delay for each time we try and convert an element into a different element.
I'll use Wander as an example.

WanderTaskDriver

TimerTaskDriver (Idle)
DecisionTaskDriver
PathfindTaskDriver
FollowPathTaskDriver

MoveTaskDriver

We come into Wander with a Driver Start

+1 frame

We kick off a Timer to wait an amount of seconds for idling

+1 frame

Timer starts counting down

+X amount of seconds

Timer completes

+1 frame

We request to make a decision on where to go

+1 frame

We get the result

+1 frame

We pathfind to that location

+1 frame

We get the result

+1 frame

We trigger a follow path

+1 frame

Follow Path triggers a Move

+1 frame

Move updates our position

+X amount of seconds

Move complete

+1 frame

FollowPath gets the complete and kicks off the next move

+1 frame

Move updates the position again

+X amount of seconds

Continue until done

FollowPath notifies of fully complete

+1 frame

Wander gets the complete and kicks off Timer idle again

+1 frame

REPEAT

All the +1 frame aspects add up and could go away.
The two variants I see right now are Driver and OverTime (Names are bad and TBD)
The regular Driver jobs are scheduled such that we can execute them all in one frame because they are all chained together. Because they are triggered at the same time as other Top Level Task Drivers they will all interleave with each other unless a specific shared dependency has one of their jobs waiting on the other.
When we hit an OverTime job, that's when we bucket everything into what System jobs were. These are the massively parallel processing jobs that execute once per frame to allow for something to occur over time. Ex. Counting down a timer, moving something at a certain speed over time etc.
All the Driver jobs get a chance to go ahead and write to these by executing first. Once all the Drivers are done, all the OverTime jobs get their chance to update once at the end of the frame. They might write back to other Drivers and that will get picked up the next frame.
Our Wander example becomes:

We come into Wander with a Driver Start
We kick off a Timer to wait an amount of seconds for idling
OVERTIME - Timer starts counting down

+X amount of seconds

Timer completes
We request to make a decision on where to go
We get the result
We pathfind to that location
We get the result
We trigger a follow path
Follow Path triggers a Move
OVERTIME - Move updates our position

+X amount of seconds

Move complete
FollowPath gets the complete and kicks off the next move
OVERTIME - Move updates the position again
Continue until done
FollowPath notifies of fully complete
Wander gets the complete and kicks off Timer idle again
REPEAT

The current parenting is kind of gross:
https://github.com/decline-cookies/anvil-unity-dots/pull/247/files#r1190560198
As part of this, fix this API and how it works.


Support go templating in alerting

Describe the feature request
Would be nice instead of place holders if we could support full go templating in the alert providers if not all but at least the custom provider.
So we can do conditional logic and provide full templating.
https://pkg.go.dev/text/template
Why do you personally want this feature to be implemented?
All I want from our slack alert is to be able to include the URL for instance if status code is 500. Or I could template out the response body into the alert message.
How long have you been using this project?
2 weeks
Additional information
Would be willing to implement this myself.

Any chance you could show me an example of how it would look in the configuration?

Here is an example of how alert manager configures their slack notification via templates:
https://hodovi.cc/blog/creating-awesome-alertmanager-templates-for-slack/


fix(logging): make RPC call to instance-manager to set log level

Which issue(s) this PR fixes:

Issue https://github.com/longhorn/longhorn/issues/6702
What this PR does / why we need it:
Sync the log level with instance-managers.
Special notes for your reviewer:
Additional documentation or context

@james-munson need to handle https://github.com/longhorn/longhorn/issues/6702#issuecomment-2499674384

The current PR handles it, using setting log-level to control instance-manager logrus logs, and v2-data-engine-log-level to control spdk_tgt logs.
Note that it requires the instance-manager changes in https://github.com/longhorn/longhorn-instance-manager/pull/726

LGTM @james-munson ready to merge?

@mergify backport v1.7.x v1.6.x


Added basic implementation of generateAll. Some cleanup.

Added function generateAll with unit test for graphs, as well as canonical as shortcut for label(G)[1].

Missing codecoverage only for "abstract" default function which always throws an error.


Node with same ID get collapsed

If i have a node under another  node with the same id @ different levels, collapsing this second root node MOVES the first root node under the second one.

The idea behind IDs is to be unique, jsTree will not work with multiple nodes with the same ID in the structure. Either make sure your IDs are unique, or let jstree handle them (by not specifying IDs in your data).
Best regards,
Ivan


Run environment locally to check that it is working

┆Issue is synchronized with this Clickup task by Unito

@MaxiStefan can you produce some kind of short manual to set the environment up once you're done?

Yes, the plan is to get workflow conceptual model done, then workflow engine understood, and then ill run the simulator in the IDE. I will after that make a tutorial for the IDE


NifMap expansion error with rustler v0.27.0

We are encountering an error for rustler::NifMap with rustler v0.27.0:
error: expected item after attributes
   --> apps/our-application/native/src/our-file.rs:346:10
    |
346 | #[derive(rustler::NifMap, Debug)]
    |          ^^^^^^^^^^^^^^^
    |
    = note: this error originates in the derive macro `rustler::NifMap` (in Nightly builds, run with -Z macro-backtrace for more info)

More information after playing around with cargo expand:
error[E0277]: the trait bound `Timestamp: Decoder<'_>` is not satisfied
  --> apps/our-application/native/src/lib.rs:64:45
   |
64 |         let rustler_map_field_0_timestamp = try_decode_field(env, term, atom_timestamp())?;
   |                                             ^^^^^^^^^^^^^^^^ the trait `Decoder<'_>` is not implemented for `Timestamp`
   |
   = help: the following other types implement trait `Decoder<'a>`:
             &'a str
             ()
             (A, B)
             (A, B, C)
             (A, B, C, D)
             (A, B, C, D, E)
             (A, B, C, D, E, F)
             (A, B, C, D, E, F, G)
           and 29 others
note: required by a bound in `try_decode_field`
  --> aapps/our-application/native/src/lib.rs:60:16
   |
54 |         fn try_decode_field<'a, T>(
   |            ---------------- required by a bound in this
...
60 |             T: rustler::Decoder<'a>,
   |                ^^^^^^^^^^^^^^^^^^^^ required by this bound in `try_decode_field`

Interestingly, this used to work. There is a decoder available for the Timestamp type.

I fixed this build on my ma chine. The struct in question has an additional attribute #[rustler(decode)] to disable generating an Encoder (This used to be required for this specific struct, but it is not necessary any longer). Without this attribute, the errors disappear. Interestingly, Rustler has a [test](#[rustler(encode, decode)] // Added to check encode/decode attribute, #180) for this specific feature:
#[derive(NifRecord)]
#[rustler(encode, decode)] // Added to check encode/decode attribute, #180
#[must_use] // Added to check attribute order (see similar issue #152)
#[tag = "record"]
pub struct AddRecord {
    lhs: i32,
    rhs: i32,
}

I will close this for now. We can revisit this if it happens again.


feat: port data.nat.prime

[ ] depends on #1142

It looks like this needs updating after https://github.com/leanprover-community/mathlib/pull/17997

bors merge


Use Customer Balance to pay

Hi guys!
I would like to know if it's possible to use the credit BALANCE as payment method.
This is what nI'm trying to do from server:

However I'm receiving this error:

Thank you!

@charliecruzan-stripe : In the current version, there isn't any support for the Bank Transfer payment type (customer_balance) right?


Autocomplete should not suggest fields of type "never | undefined"

Sometimes types can have fields of type never|undefined to mark that those types shouldn't have that property:
type Test = {a: string,  b?: never };
If that's the case, when using autocomplete to specify an object literal of that type, the fields marked as never|undefined shouldn't be suggested.

Currently autocomplete just requires us to get a single type. If we did this we would have to get the types of all of its properties, too, which could mean more work. I think an exact type {| a: string |} (#12936) would be a better solution than trying to specify every property that shouldn't exist.

@andy-ms I completely agree. I opened this issue because when I opened #16679 it was suggested as a workaround/solution to mark fields as never. If that's the way to go, then I would argue that this issue would be necessary.
I was not aware that there was a proposal for exact types when I opened these 2 issues, and I agree that if those would get in the language, my use cases for this would be covered,

Does not seem that there has been a high demand for this request. closing for now.


Support private registries for github-actions

Is there an existing issue for this?

[X] I have searched the existing issues

Feature description
When using dependabot with GitHub Enterprise server where using Actions from github.com is disallowed, dependabot will raise pull requests to update actions to versions that are not available in the appliance.
As a concrete example, GitHub Enterprise Server 3.6 is bundled with actions/setup-dotnet v2 but the current latest version on github.com is v3.
Within GHES, dependabot will generate a pull request to bump a reference to v2 of this action to v3, which will then break because that version is not available in the appliance.
Configuring dependabot.yml to point to GHES for actions updates isn't possible as github-actions is not a supported value for the type property of a private registry under registries (docs).
At a minimum, dependabot should support private registries for github-actions so that enterprise-level actions can be correctly kept up-to-date.
Ideally, dependabot when run within GHES would be able to determine for itself whether public actions are allowed or not, and use the correct GitHub host to determine the latest actions versions that are available of its own accord without manual configuration.

Hei! Indeed github_actions is not allowed as a type, but Actions are backed by a git repository, so you should be able to configure a git source to do what you want.
Let me know how that works!

The uses documentation doesn’t seem to state that a full GitHub host name can be specified ahead of the repo user|org/name value.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsuses
That also seems like a lot of additional configuration to have to hardcode the URL of the GHES appliance itself running the jobs into every single step of every single workflow in the whole Enterprise when it otherwise Just Works™ as a built-in feature.

Sorry, I didn't explain why I mean correctly. I meant that you should be able to configure a git registry for your GHES instance.

Yeah … I am firmly with @martincostello in spirit. A good user (developer) experience looks way different from is proposed here. The Git repository declaration may be useful as workaround for now but – within a GHES environment – having to constantly work around weird edge cases in Dependabot limitations (see for example #1884, #1959) is really frustrating. Especially because Dependabot is supposed to be a first party product as in "part of the GitHub experience".

Just trying to help here, apologies if my suggestions don't fulfill your expectations.
Please help me understand what's being requested here.
Is it to, instead of writing
registries:
  github-octocat:
    type: git
    url: <my-ghes-url>
    username: x-access-token
    password: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}

be able to write
registries:
  github-octocat:
    type: github-actions
    url: <my-ghes-url>
    username: x-access-token
    password: ${{secrets.MY_GITHUB_PERSONAL_TOKEN}}

?

The built-in Dependabot integration for GHES already doesn't need to be configured with authentication for cloning repositories or raising pull requests, so I wouldn't expect to need to tell it how to authenticate with the GHES appliance itself and could discover for itself whether fetching GitHub Actions from the internet is allowed at all.
Ideally, something as minimal as this if Dependabot needs to be told it isn't running in the context of github.com, but given the first-party integration, I would expect it to be able to find out for itself that it wasn't running in "the" GitHub and act accordingly:
registries:
  github-octocat:
    type: github-actions
    url: https://github.corp.local

Ok!
I completely lack experience on GHES so let me check with the rest of the team and I'll get back 👍.

We tested exactly that, added a registry of type git and reference it in the updates section of package-ecosystem github-actions.
But it feels like the registry information is completely ignored. All I can see in the workflow logfile are calls to github.com but no calls to our GH Enterprise instance (GHE 3.5 i.e. we are using this dependabot version https://github.com/github/dependabot-action/blob/ghes-3.5/docker/containers.json). Has anybody successfully setup the workaround? Still wondering what we're doing wrong.
Thanks a lot!

Apparently the workaround has also recently regressed, as per https://github.com/dependabot/dependabot-core/issues/6140. So, no, you're not doing anything wrong, it's us.
I'll try find some time to look into this, sorry for the inconveniences!

IIUC, you're wanting the GHES appliance to prefer itself as the source of the action. This was actually added in GHES 3.7 by https://github.com/dependabot/dependabot-core/pull/5469. However, we later discovered a bug which was fixed by https://github.com/dependabot/dependabot-core/pull/6512 and released last week. So if you fetch the latest version of the Dependabot action for your GHES instance, this should work as desired.
I'm going to close because I think this is now handled, but if you're still encountering problems even after upgrading please comment and we can re-open.

Thanks a lot!
I made a quick attempt. Dependabot has made exactly the right calls to our enterprise instance and detected a necessary update. But nevertheless it fails... maybe just a misconfiguration on our side, haven't checked in detail
updater | INFO <job_4669> Updating ... from 1.0.0 to 1.0.1
updater | ERROR <job_4669> Error processing ... (RuntimeError)
updater | ERROR <job_4669> No files changed!
ERROR <job_4669> /home/dependabot/github_actions/lib/dependabot/github_actions/file_updater.rb:28:in `updated_dependency_files'

@MoritzKeppler if you could provide a bit more info about the local only action? I'm trying to put together a list of gaps in our actions support so we can tackle them. Is this a reusable workflow or is it a full fledged action in a private repo? If you could provide a representative "uses" setting from the workflow for this action. Anonymized is fine, but having all of the path segments included in the real "uses" setting. We use a regex to find/parse the action names and I suspect the update is failing because this regex is too specific.

Sure, it's a 'full fledged' action with two release "v1.0.0" and "v1.0.1"
The uses section in my test run looks like this:
 - uses<EMAIL_ADDRESS>        with:
          kube-config: ${{ secrets.KUBE_CONFIG }}
          version: v1.24.0


Update python version

Description of the proposed feature

The library requires an old version of python

pip doesn't install latest version (0.1.7) if python version is 3.11. In fact it silently installs 0.1.4 which breaks many/most examples and the current documentation. So even the simplest examples fails to load properly.
Are there known bugs when changing to Python 3.11? If not then is fixing this issue as simple as changing a line in the .toml file?


Support for recursively nested structures

I may be missing it but there doesn't seem to be a way to deal with XML like:
<item name="foo">
  <status code="1" />
  <item name="bar">
    <status code="2" />
  </item>
  <item name="baz">
    <status code="3" />
    <item name="biff">
       <status code="4" />
    </item>
  </item>
</item>

(In the case where there can be an arbitrary level of nesting).
This could be turned into e.g.:
{
  items: [
    {
      name: "foo",
      status: 1,
      items: [
      {
        name: "bar",
        status: 2
      },
      {
        name: "baz",
        status: 3,
        items: [
          {
            name: "biff",
            status: 4
          }
        ]
      }
    }
  }
}

Or even...
[
  foo: {
    status: 1,
    bar: {
      status: 2
    },
    baz: {
      status: 3,
      biff: {
        status: 4
      }
    }
  }
]

It seems like being able to refer to a named key elsewhere in the template might make the first translation possible.

Thanks for bringing this issue up. I'm taking a look at this right now. Doing something like this will give you the result that you want, but it isn't doesn't make for the nicest template syntax:
var template = [ 'item', { name: '@name', status: 'status/@code' } ];
template[1].items = template;

You can't create a recursive data structure directly in a JS definition but you can create a cycle after the fact as I showed above.
It might be nice to implement an escape code like we do for literals. For example using '+template' to refer to a recursive template:
var template = [ 'item', { name: '@name', status: 'status/@code', items: '+template' } ];

Let me know what you think.

Cool, I didn't realize there was a workaround.  I do much prefer the latter, though, and that's basically what I thinking.  Wouldn't it be '+item', though?  It seems like you'd want to be able to refer to a specific key within the template in order to have some flexibility about exactly what's nested where.  For example, <item> may not be the top-level node, but rather a recursive part of some larger structure, so you can't recursively include template, just the item piece.  If this isn't making sense, I can try to concoct a better example...


Search autocomplete not available on small screens

Version 2.1.0

Small screens, as defined by pivot css

Issue
Small screens have different functionality for searching, and unlike the regular screen sizes small screens do not use autocomplete. This makes searching more awkward.
Special:Search does autocomplete on small screens.
Setting autocomplete on in the php below for ul.side-nav has no effect
<input type="search" name="search" placeholder="<?php echo wfMessage( 'search' )->text() ?>" title="Search [alt-shift-f]" accesskey="f" id="searchInput" autocomplete="on">

autocomplete="on" is not for autocomplete on search. It is to remember the form content at a browser level. It should be left off.
Looks like we can use the mediawiki.searchSuggest.js of core as it allows for generic skin adaptation (CologneBlue) of multi search forms on same page as it is in Pivot.
Find
https://github.com/Hutchy68/pivot/blob/078f9c258c4869432256e03eba5af44a3f6768bd/Pivot.skin.php#L122
an change id="searchInput-offcanvas" to class="mw-searchInput"
and you can do the same in
https://github.com/Hutchy68/pivot/blob/078f9c258c4869432256e03eba5af44a3f6768bd/Pivot.skin.php#L167
Also, should designate
https://github.com/Hutchy68/pivot/blob/078f9c258c4869432256e03eba5af44a3f6768bd/Pivot.skin.php#L164
id="searchform" to id="searchform-sidebar"

Fixed with commit eb144a1. Pull develop branch to test it. Closing, reopen if necessary.


After party cell col span should be 6

Assigned to @shiraji
Overview (Required)
Currently, after party cell is 1.
But it should be 6 like welcome talk.

Links

https://github.com/DroidKaigi/conference-app-2017/blob/master/app/src/main/java/io/github/droidkaigi/confsched2017/viewmodel/SessionViewModel.java#L115

Here is the value from sessions.json
{"id":72,"title":"アフターパーティ / AfterParty","date":"2017/03/10","start_time":"18:30","end_time":"20:30","stime":"2017/03/10 18:30:00","etime":"2017/03/10 20:30:00","duration_min":120,"type":"dinner","desc":"アフターパーティではお寿司をはじめ、美味しい料理とドリンクを用意しています。みんなでワイワイ楽しみませんか？\nhttps://droidkaigi.connpass.com/event/43942/ で参加を受け付けています。\n\n楽しんじゃいましょう、気楽に！"}

The interesting part is "type":"dinner". So the question is "is data correct"?
If there is type "dinner", then it seems enum missing value "dinner". Is there any other type missing?

So the question is "is data correct"?

It's correct. We have to add new enum type DINNER.

OK. I will work on this issue.

Is this what you want? It's same colspan with welcome speech but not 6.

Thanks!
No, I think the colspan should be 6.

Then, can I fix welcome speech's colspan, too?

No, welcome talk session is held in room 1~3, so colspan=3 is correct 😃