Loading Fastboot failed, timed out.

Provisioning failed with Loading Fastboot failed, timed out. message.
Steps to reproduce:
Make provisioning as described in official documentation, RPI 5 should make provisioning of CM 4.
Logs:
provisioner.log
keywriter.log
triage.log
progress.log
After failure not able to use rpiboot:
$ sudo ./rpiboot
[sudo] password for pc:
RPIBOOT: build-date Dec 17 2024 version 20240422~085300 62f37dae
If the device fails to connect then please see https://rpltd.co/rpiboot for debugging tips.
Waiting for BCM2835/6/7/2711/2712...
Loading embedded: bootcode4.bin
Sending bootcode.bin
Successful read 4 bytes
Waiting for BCM2835/6/7/2711/2712...
Loading embedded: bootcode4.bin
Second stage boot server
Cannot open file boot.sig
Cannot open file boot.sig
Cannot open file boot.sig
Cannot open file boot.sig
Cannot open file boot.sig

Thanks for the report, @AndriiNeivanov
Inspecting the logs, it appears that you've written the key successfully - which explains future rpiboot strangeness if you don't also sign those components.
What is unexpected, however, is Fastboot timing out.
With the device in such a state, are you able to get the result from fastboot devices? Note that this output will contain a serial number - which I strongly recommend you obfuscate (replace it with X's or similar).

Probably it was a power loss issue. It looks like CM 4 has power loss during provisioning.
So, I moved forward and hang on Starting Resizing OS images stage in provisioning.log:
provisioner.log
keywriter.log
progress.log
triage.log
Only red led is glowing.
Monitor lost the device:

With the device in such a state, are you able to get the result from fastboot devices? Note that this output will contain a serial number - which I strongly recommend you obfuscate (replace it with X's or similar).

It looks like fastboot works well now:
$ fastboot devices
xxxxxxxxxxxxxxxx	fastbootd

Thanks for the update, @AndriiNeivanov.
One thing you can try is 'forgetting' the device entirely.
Delete the entire log set for that device:
rm -rf /var/log/rpi-sb-provisioner/xxxxxxx/
And then re-plugging the power of the compute module IO board.

One thing you can try is 'forgetting' the device entirely.
Delete the entire log set for that device:
rm -rf /var/log/rpi-sb-provisioner/xxxxxxx/
And then re-plugging the power of the compute module IO board.

I deleted and tried again, and had failure in provisioner.log:
Loading Fastboot failed, timed out.
progress.log
provisioner.log
keywriter.log
triage.log
Also the monitor.sh had failure.

Thanks for confirming @AndriiNeivanov
@roliver-rpi will you have chance to look at this?

@timg236 , are you familiar with this RPIBOOT failure mode? Unfortunately, any error returned by the 'rpiboot' executable has been dropped as rpi-sb-provisioner.sh only checks for a timeout error when loading the fastboot gadget.

I've got the same issue and stuck now.
Maybe important is that I had to change SOURCE_EEPROM_IMAGE from "/lib/firmware/raspberrypi/bootloader-2712/latest/pieeprom-2024-12-15.bin" because the original file does not exist.

Have restarted the process and now I'm getting keywriter error
Writing key and EEPROM configuration to the device
Writing failed, timed out.

I've got the same issue and stuck now. Maybe important is that I had to change SOURCE_EEPROM_IMAGE to "/lib/firmware/raspberrypi/bootloader-2712/latest/pieeprom-2024-12-07.bin" because the original eeprom file does not exist.

The same on my RPI 5 (prov server) for CM 4 (prov client).
$ ls -la bootloader-2712/latest
total 8304
drwxr-xr-x 2 root root    4096 Dec 19 14:59 .
drwxr-xr-x 4 root root    4096 Dec 19 14:59 ..
-rw-r--r-- 1 root root 2097152 Dec 16 11:13 pieeprom-2024-11-12.bin
-rw-r--r-- 1 root root 2097152 Dec 16 11:13 pieeprom-2024-11-27.bin
-rw-r--r-- 1 root root 2097152 Dec 16 11:13 pieeprom-2024-12-07.bin
-rw-r--r-- 1 root root 2097152 Dec 16 11:13 pieeprom-2024-12-15.bin
-rw-r--r-- 1 root root  102804 Dec 16 11:13 recovery.bin

$ ls -la bootloader-2711/latest
total 6348
drwxr-xr-x 2 root root   4096 Dec 19 14:59 .
drwxr-xr-x 4 root root   4096 Dec 19 14:59 ..
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2023-01-11.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2023-05-11.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-01-18.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-01-22.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-04-15.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-04-17.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-05-17.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-07-30.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-09-05.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-10-10.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-10-21.bin
-rw-r--r-- 1 root root 524288 Dec 16 11:13 pieeprom-2024-12-07.bin
-rw-r--r-- 1 root root  97604 Dec 16 11:13 recovery.bin
-rw-r--r-- 1 root root  99352 Dec 16 11:13 vl805-000138c0.bin

I fixed path on latest and it resolved the problem. From now on my CM 4 has success boot.
@roliver-rpi, @tdewey-rpi, please add the patch below to main branch and to the Raspberry Pi APT repositories.
git diff dev/eeprom-image-fix..main
index f6a6f5e..de31d8d 100755
--- a/service/rpi-sb-provisioner.sh
+++ b/service/rpi-sb-provisioner.sh
@@ -370,12 +370,12 @@ BOOTCODE_BINARY_IMAGE=
 BOOTCODE_FLASHING_NAME=
 case ${RPI_DEVICE_FAMILY} in
     4)
-        SOURCE_EEPROM_IMAGE="/lib/firmware/raspberrypi/bootloader-2711/latest/pieeprom-2024-12-07.bin"
+        SOURCE_EEPROM_IMAGE="/lib/firmware/raspberrypi/bootloader-2711/latest/pieeprom-2024-09-05.bin"
         BOOTCODE_BINARY_IMAGE="/lib/firmware/raspberrypi/bootloader-2711/latest/recovery.bin"
         BOOTCODE_FLASHING_NAME="${FLASHING_DIR}/bootcode4.bin"
         ;;
     5)
-        SOURCE_EEPROM_IMAGE="/lib/firmware/raspberrypi/bootloader-2712/latest/pieeprom-2024-12-15.bin"
+        SOURCE_EEPROM_IMAGE="/lib/firmware/raspberrypi/bootloader-2712/latest/pieeprom-2024-09-23.bin"
         BOOTCODE_BINARY_IMAGE="/lib/firmware/raspberrypi/bootloader-2712/latest/recovery.bin"
         BOOTCODE_FLASHING_NAME="${FLASHING_DIR}/bootcode5.bin"
         ;;

The SOURCE_EEPROM_IMAGE certainly needs updating for CM5 as the original file no longer exists as @oliora points out.
I'm still not sure why you've been facing issues on CM4 @AndriiNeivanov as bootloader-2711/latest/pieeprom-2024-09-05.bin is still available; I've been able to provision a CM4 using rpi-sb-provisioner 1.3.1 installed from the apt repository without issue.

It looks like my CM 4 does not work with pieeprom-2024-09-05.bin, but work well with pieeprom-2024-12-07.bin.

Even with the recent EEEROM file the rpiboot times out for me, effectively never hearing back from RPi 5. The log is the following:
RPIBOOT: build-date Nov  7 2024 version 20241107~183156
Loading: /tmp/tmp.Sn0ZqN5hRV/bootcode5.bin
Waiting for BCM2835/6/7/2711/2712...


Profile icon search should be more fuzzy

The search should work more like the quick pick, where it has fuzzy matching such that prvm would match profile-icon-vm:

Contiguous search is enough for icons widget filtering. Also icon ids are simple one word strings. We can get back to this if needed.


calculating splash styles with variables

implements #130
I replaced the existing colors and some sizes with the variables available. Those where no 100% match so I post the comparison below.
Before:

After:

One thing: I couldn't replace the font-family with the one from the variables (sans). If I do I get following output:

Which one is the correct one? (maybe @nylira)

Thanks @faboweb!


Vickel: Watch pastranagarcia.com

Vickel requests the watch of the watch_keyword pastranagarcia\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

pastranagarcia\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Adjust SDL loop timing a bit

This fixes the fact that SDL only called tick every 20ms, so you would always be running behind and get two updates. Also switches render/tick around as SDL was backwards compared to STM32/Pico.

... and then I realise that this will have unstable render timing in Emscripten as loop gets called at [whatever your refresh rate is]... which probably isn't 100Hz... hmm...
(Which also means it was already running render at a different rate to everything else, and was also synced unlike the non-Emscripten SDL code)

Came back to this as it helps the audio buffering in DaftBoy.
"Fixed" Emscripten by #ifdef-ing the render check. It's still the odd one out, running at the display refresh rate unlike SDL on anything else (the same as before this change)...

Thank you!


Extend documentation for new users

Hi,
I'd like to try kubernetai to mirror some service from a remote cluster-2 to another one cluster-1 on AKS.
But we can't understand what are the steps and the implications from the documentation here.

Of course, for this to work, you will also need to ensure that Service Endpoint IPs are routable across the clusters, which is possible to do, but not necessarily the case by default.

Could you add some command to verify this?
After the cloning of the project and the makes, what should we do?
Is there a way to backup the current coreDNS, before deploying this?
Thanks!

Perhaps https://github.com/coredns/multicluster-dns can help answer some of your questions.
It's specific to GKE, but concepts would be similar to AKS.


Attempting to fix link issue

Not sure why the original didn't work, going to use the auto tester to experiment :)

Nevermind. This has already been fixed, just not in the published dlang.org


Terminate child containers on program termination.

Upon receiving a termination signal, ensuring any spawned containers are also terminated. This is required since we intentional do not attach stdint to the container. This means, however, that interrupts such as Ctrl+C did not stop the build process. Likewise, termination signals such as SIGTERM merely exited cross, and did not terminate the container.
This also refactors the global container state to store whether the container exists and current logic to terminate the container if it exists. By coupling the two, it simplifies safe handling and modification of this global state. Since we have a signal handler, these functions may be called asynchronously, therefore any global state may be modified, rendering the current state invalid if not appropriately guarded. Coupling the two ensures that our logic is sound.
Fixes the regression in #964.
Closes #1041.

#964 isn't in a published version, therefor this changelog entry should not be added as a fix

having a hard time seeing what the actual change is, could you split out the move into shared and the fix into two commits?

Definitely. Sorry, this was made more confusing than it needed to be.

I've separated out the two commits, one for the refactoring and one for the change. The refactoring makes this quite easy to do, since all we need is to attach a name to the container, and if there's an interrupt, we handle the container termination like we do when using remote docker. If the docker command exits successful, IE, with no interrupts, then we simply mark that the command has completed.

bors r=Emilgardis


python modules in local path can cause conflicts

This issue was originally created at: 2012-08-22 16:13:43.
This issue was reported by: greengadgetz.
greengadgetz said at 2012-08-22 16:13:43
Python modules in the local directory hide normal python models. If you run from a directory containing a python module that has the same name as one used by scons (i.e. "random") scons will import the local version instead of python's installed version.
Here is an example that reproduces this behavior:

---example start----

$ mkdir random
$ touch random/__init__.py
$ scons
Traceback (most recent call last):
  File "/opt/local/bin/scons", line 187, in <module>
    import SCons.Script
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.2.0/SCons/Script/__init__.py", line 76, in <module>
    import SCons.Environment
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.2.0/SCons/Environment.py", line 54, in <module>
    import SCons.Platform
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.2.0/SCons/Platform/__init__.py", line 52, in <module>
    import tempfile
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tempfile.py", line 34, in <module>
    from random import Random as _Random
ImportError: cannot import name Random

---example end----
In this case there is no SConstruct file so the expected result is a different error:

scons: *** No SConstruct file found.

Tested on OS X version 10.7.4, but likely affects other platforms
$ python --version
Python 2.7.3
$ scons --version
SCons by Steven Knight et al.:
  script: v2.2.0.issue-2856:2676:d23b7a2f45e8[MODIFIED], 2012/08/05 15:38:28, by garyo on oberbrunner-dev
  engine: v2.2.0.issue-2856:2676:d23b7a2f45e8[MODIFIED], 2012/08/05 15:38:28, by garyo on oberbrunner-dev
  engine path: ['/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.2.0/SCons']
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 The SCons Foundation

This is "just the way it is".  IDLE famously blows up this way, when a learner saves a file with an unfortunately chosen name, it's imported in favor of one IDLE needs, and breakage ensues.  Suggest we reject this - not even sure where one would document it.

Sounds good.
I'll close.


saveGif reference page lists incompatible usage scenario

Most appropriate sections of the p5.js website?
Reference
What is your operating system?
Windows
Web browser and version
110.0.5481.178 (Official Build) (64-bit) (cohort: Stable)
Actual Behavior
Note: I'm not sure if this is a bug with saveGif or an error in the documentation.
The usage notes on the saveGif reference page contain this sentence:

This may be called in setup, or, like in the example below, inside an event function, like keyPressed or mousePressed.

This is incorrect. This function can't be called outside of an event function and still produce a correct result. The GIF resulting from calling this in setup always has a black frame as its first frame.
Expected Behavior
The previous version (1.5.0) contained an accurate description of where saveGif could be successfully used.

It is not recommended to write this function inside setup, since it won't work properly. The recommended use can be seen in the example, where we use it inside an event function, like keyPressed or mousePressed.

Steps to reproduce
https://p5js.org/reference/#/p5/saveGif
Incorrect text in version 1.6.0: https://github.com/processing/p5.js/blob/1c19ae44063e387936d0614e76f5a091167bf13c/src/image/loading_displaying.js#L183
Previous description (accurate) from version 1.5.0:
https://github.com/processing/p5.js/blob/00821f33ca1d8a6990364568f0374c4aaf713faa/src/image/loading_displaying.js#L180
Would you like to work on the issue?
No

Hi, as of 1.6.0 this is supported. If I put saveGif('mySketch', 5); in the setup of the example, I get this gif output:

I'm going to close this for now for organizational purposes, but if you notice a scenario where it's still not recording gifs properly, feel free to open another issue, but on the main p5 repo, since the docs in this repo are automatically built from the source code there.

Gotcha. Thanks for moving this! @davepagurek


Fetch data assets from Supabase storage

In this PR the client fetches data asset files from a Supabase storage bucket. Data asset files are

pumps.geojson
weather_light.geojson

The files get pushed when the Github actions of the OSM harvester and the DWD harvester are in place.

Create a public bucket in Supabase. Maybe call it "data_assets".
Set up this Github repo by specifying some variables/secrets:

variable "SUPABASE_DATA_ASSETS_BUCKET" (Name of storage bucket)
secret "SUPABASE_ACCESS_TOKEN" (service role key of Supabase project)
variable "SUPABASE_URL" (Supabase project url)
variable "SUPABASE_PROJECT_ID" (Supabase project id)

In vercel project add env variable "NEXT_PUBLIC_PUMPS_DATA_URL" with url of generated pumps.geojson (you can find the address via Supabase project site)
In vercel project switch env variable "NEXT_PUBLIC_RAIN_DATA_URL" to url of generated weather_light.geojson (you can find the address via Supabase project site)

thank you @JensWinter! This is a very valuable increment. We will have a look into this PR after reviewing your other two related PRs

Hi @JensWinter , thanks again for your proposal! 👍🏼 We have splitted this pull request to tackle pumpen and dwd data separately. pumpen PR is already merged: https://github.com/technologiestiftung/giessdenkiez-de/pull/603

Nice!


Gripper for Franka

Hi @cheng-chi, this work is incredible!
I would like to ask if the UMI is designed to be used with the Schunk WSG-50 gripper?
I want to reproduce UMI on a Franka robot, does that mean I have to buy a WSG-50 gripper and replace Franka's original gripper with the WSG-50?

Hi @cheng-chi,
For the CAD model you provided, does this mean we won't have the exact same view as the one collected by UMI (because there is no side mirros)?
The CAD model is only for the gopro and finger mounts?

@ErinZhang1998 The CAD model provided in this thread is a prototype used in earlier stages of this project and is not fully compatiable with UMI. You can modify it to be compatible with UMI, or modify the Franka mount CAD to be compatible with Franka hand.

any update on the gripper controller @Yingdong-Hu ?


Memory leaks just by including doctest.h

Description
We upgraded from doctest 1.2.6 to 2.2.3. Now Visual Studio reports memory leaks.
Steps to reproduce
The following simple example code gives 3 memory leaks when run.
#include "stdafx.h"

#define DOCTEST_CONFIG_IMPLEMENT
#include "doctest.h"

int main()
{
    int flag = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
    _CrtSetDbgFlag(flag | _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

    return 0;
}

Detected memory leaks!
Dumping objects ->
{175} normal block at 0x004F5620, 8 bytes long.
 Data: <  O     > EC 98 4F 00 00 00 00 00
{163} normal block at 0x004F5578, 8 bytes long.
 Data: <| O     > 7C 8E 4F 00 00 00 00 00
{156} normal block at 0x004F57E0, 8 bytes long.
 Data: < 5O     > AC 35 4F 00 00 00 00 00
Object dump complete.

Extra information

doctest version: 2.2.3
Operating System: Windows 10
Compiler+version: Microsoft Visual Studio 2015

strange... valgrind on Unix doesn't report anything.
Version 2.0+ uses a lot more things from the STL - this could be a bug in the toolchain (i've had such issues many times before where a specific version of the compiler is giving trouble).
I'll try to reproduce it and investigate but I don't know when I'll get to this.

The same leaks occur in VS2019 Preview 2.
Further investigation shows that this is caused by g_infoContexts being thread_local. When DOCTEST_THREAD_LOCAL is defined to nothing then the leaks go away. Is it necessary to have it be thread_local if all the tests run from the same thread?

All tests always run from the same thread but if one test case spawns multiple threads and uses asserts and logging with INFO() - then that needs to be thread-local. If you don't have such a scenario you may indeed use DOCTEST_THREAD_LOCAL.
Thanks for diagnosing this - I'm very curious as to why a thread-local global std::vector is a problem. If you have any ideas I would be grateful - otherwise I'll look into it when I have the chance... But for now version 2.3 with xml reporting is the priority.

Solution: creating the static thread_local object from a getter function solves it. Like this:
    std::vector<IContextScope*>& getInfoContexts() {
        static DOCTEST_THREAD_LOCAL std::vector<IContextScope*> g_infoContexts; // for logging with INFO()
        return g_infoContexts;
    }

Is this solution related to the "static initialization order ‘fiasco"?
This global is used only after main() is entered so all globals (including this one) should be already initialized... Thanks for letting me know it works this way! I'm still really puzzled why this is necessary though...

Perhaps. It is a bit of a bad experience to see memory leaks just by including the header, though.

So... Could you do this fix locally for your copy of doctest for now, and wait for me to try to figure this thing out when I have the time?

Yes. I have already fixed it here locally.

So I just tried copy-pasting your example and am unable to reproduce this with VS 2017.
Are you running the executable in some special way? I haven't investigated what _CrtSetDbgFlag and those flags do but I assume the program would check itself upon exiting...? I tried the Debug version since in Release that call for setting flags is a no-op.
How did you diagnose that the problem was the thread-local global? There are other thread-local global variables apart from it...

This is with a clean new Console Application project created via the project wizard.
Don't you see the memory leaks in Visual Studio's output window?

To be clear: The memory leaks are not printed with the console output, but rather in the Output window inside Visual Studio itself.

I previously tried it in a solution generated with CMake but now just tried it with a new Console Application project created from the studio - and got no errors. I used VS 2019 Preview 4.3.

I highly suspect that this has nothing to do with doctest... memory leaks are diagnosed on the CI with industry-standard tools such as valgrind and the sanitizers on Linux. And it is really strange that only that thread-local global is problematic.
I'm currently out of ideas about this and don't want to commit fixes which I don't understand. I just released version 2.3.0 but will keep this issue open if any new information comes up - for now I'm clueless :|

Well I'm going to close this... It will remain for others to find and inspect if anyone else hits this problem, but as far as I understand there shouldn't be anything wrong with that thread local, and there are no problems with the other thread locals as well... I cannot reproduce this locally - I'll need even more information on how to reproduce it - with an even smaller example... perhaps using cl.exe on the command line with the full list of flags or something, and not calling the executable through the debugger maybe... I don't know. But the fix suggested here doesn't seem right to me. You could still define DOCTEST_THREAD_LOCAL to nothing locally.

A related issue might show up when using doctest with mingw32/64.
The simplest example would be:
#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include <doctest/doctest.h>

TEST_CASE("simple test")
{
    CHECK(1 == 1);
}

run with "-s" to see the issue. when debugging with gdb it shows a segfault.
Adding #define DOCTEST_THREAD_LOCAL removes the segfault but I did not run it through memory analyzer to see if there is a leak as well.


data: mnvsk97.json

Changes proposed
Adds mnvsk97 profile to the LinkFree Database

Check List (Check all the applicable boxes)

[ ] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[ ] This PR does not contain plagiarized content.
[ ] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Looks good, Thanks for Contributing! 🎉

Thanks for the review. Looking forward to more contributions 😄


[WIP] Update OWNERS

Add a new website owners group

Separate out “I can approve changes to English” from “I can approve changes anywhere on the website”

Add labels to PRs that make web development changes
Let the localization team review changes that add new localizations (?)
Don't allow English reviewers to review changes for other languages (website owners still can)

I need to make time to work on this.

Relevant to https://github.com/kubernetes/website/pull/45762

/retitle Switch to finer controls on approver access

/remove-sig release
/remove-area release-eng

/lgtm
/hold
This looks good to me, however, I'd like for this change to take place after the v1.30 release (currently slated for April 17, 2024), so that no behaviour changes for the Docs Lead and Release Lead (cc. @drewhagen @katcosgrove).
Thanks for this, @sftim 🤝

This change makes sense to me, the en owners group should only be allowed to approve en PRs while website-owners have the ability to approve other localizations
/approve
With 1.30 released yesterday (April 17, 2024), I'm unholding this PR
/hold cancel


Closes #166

Checks non-overlap of migration start/end times if they involve the same source/dest. Am I missing any cases here?

Ah, yes this seems to be failing from the hypothesis draws. @grahamgower is that an easy change to writing those tests that you had in mind? Or requires some major rewriting..?

At the moment, graphs() adds all demes in a loop, then draws all migrations/pulses in another loop. It could be changed to draw mutations/pulses in the deme-adding loop, just between the currently added deme and the existing demes. It would then be easier to limit migrations to be non-time-overlapping for each deme pair. E.g. see how times are drawn in the epochs_lists() function above it, to draw a set of unique times, sort them, and then use them as non-overlapping time intervals.

Ok, trying something here to avoid adding overlapping migrations to a random graph in the tests...

Hey @grahamgower ... not sure what this error here means in build-deploy-docs: "Error: Input required and not supplied: token". Do we need to update something in setting up github actions?

Ah, sorry about the docs action failure. I disabled that for forks, because github suggested there's a security issue with it (Ben Jeffery told me he'll come up with a way of doing this differently). So for now, pull requests from forks will get permission errors from the docs github action. If it gets too annoying, I'll temporarily delete the action. Or you can push a branch to the popsim-consortium/demes-python repo, and open a pull request from there (which will have the right permissions). This all applies to the demes-spec repo too, btw.

Is this ok to merge and just ignore that error for now, then?

Fine by me


Disable TCP Timestamp

the TCP timestamp response to approximate the remote host's uptime and aid in further attacks. Additionally, some operating systems can be fingerprinted based on the behavior of their TCP time stamps.

Hi again @Acenl12
Any updates?

Oops was a mistake


New approach to defining Schemas

Hello :wave: During the last firebreak (June 2017) I've worked on a new approach to defining schemas. This achieves a few things that improve schemas:

All schemas can be generated from a single file per-format, even the exceptional cases (redirects/gone)
Notification and frontend are much more accurate (frontend could be even more accurate, but examples need fixing)
Usage of a format (jsonnet) that allows importing for re-use of common definitions and to try avoid duplications. We can also use comments in the definitions 🎉
Definitions are generated just when needed.

This approach has been documented in an RFC which has been accepted.
As of late September 2017, this approach now passes tests for all dependent repos (which has involved some accuracy compromises).
I've tried to fix everything that I think could be broken by this, but I'd not be surprised if something gets caught on it. The most likely reason for this is the change of the examples directory, which has required updates in govuk-content-schema-test-helpers and govuk_schemas.
I'm due to go on leave from September 28th until October 9th so if/once this gets approved I wouldn't plan to merge it until October 9th so I can be about if it breaks things.

@tijmenb reflecting on the problem regarding the document types yaml import, I've put together an approach to still allowing this via a document_types file created as part of schema generation in https://github.com/alphagov/govuk-content-schemas/pull/634/commits/4321416d5a6de18332ea4f7867d452f2d3b5354f which will output a dist/allowed_document_types.yml file as per https://github.com/alphagov/govuk-content-schemas/blob/054a457cc312cacdac5cbe2e064daf3edddf5b73/dist/allowed_document_types.yml
What do you think?

@kevindew that looks good! The docs would be able to work with this. Btw I forgot that the tests for https://github.com/alphagov/govuk_document_types/blob/master/spec/data_lint_spec.rb#L39 also use the YAML file.
One thing that I hadn't realised is that this makes it somewhat easier to add document types (by adding them to the schema right?). This may make it easier to have the same document types with a slightly different name.

@tijmenb well remembered, I'll get something in on that too when we merge.
Yes there's a risk of that. I'll have a little ponder over that.

Yep, don't let that hold you off from merging!


[Console] Small refactor to the logic layer

Description

Logic->middleware (a more accurate description of the purpose)
pass Environment in to all middleware functions
pull ExitCode into its own file
move factory functions to one spot

Issues Resolved
I started making these changes while adding metadata stuff, but no issue just for this.
Testing
Unit and manual tests.
Check List

[ ] New functionality includes testing

[x] All tests pass, including unit test, integration test and doctest

[x] New functionality has been documented
[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Closing in favor of #793

Closing in favor of https://github.com/opensearch-project/opensearch-migrations/pull/793


fix(build): properly copy source SASS files to dist

PatternFly-Next preview: https://patternfly-next-pr-2367.surge.sh

:tada: This PR is included in version 2.35.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update glMatrix comments to support JSDoc 3

jsdoc-template/publish.js can be updated to export the publish function.

Actually, I can't even generate docs with whatever the newest jsdoc version is.  I get tons of errors.  Do I need to downgrade jsdoc to v2 instead of the current v3?

Having discovered the link at the bottom left of http://glmatrix.net/docs/2.2.0/ which profoundly states the docs were generated with JsDoc Toolkit 2.4.0, I can now see the source of my complications.  I suppose this issue can be disposed of now, though it may be of some help to other jarheads out there like me :P

I think this issue still has merit, but should probably be restated as "Update glMatrix comments to support JSDoc 3." Reopening for that reason.

I've made JSDoc 3 part of the build process now. In doing so I'm no longer using the old custom template, but I think that's a worthwhile tradeoff to get things running. A better template can be rebuilt over time.

Sweet, I love glMatrix.  I'm living in the Philippines where internet service is THE absolute worst on the planet so being able to generate the docs locally is a big deal for me.  Otherwise, I'm flipping a coin to see if I'm going to have to wait 10 minutes for my isp to decide to finally serve me.  I think it's good to update to JSDoc 3.  I guess it's become quite popular and seems easy to use.  I got them generated with toolkit 2.4, but there seems to be some issue with functions opting to use SIMD, you might check that out.  I can always look into the code and check the comments which is great already.  But local docs is really convenient.  Thank you.


black Integration icon please add background color or white version for dark designs

Version of the custom_component
0.10.1
Describe the bug
The black bird on the integration icon/logo visually disappears on dark Design background.
May be resolved by adding an light background to the icon or providing a negative version for dark designs.

Hi, can you please provide a screenshot of what you're referring to?

Brand files are here: https://github.com/home-assistant/brands/tree/master/custom_integrations/frigate
They support a dark_ variant (docs).
PRs welcome :-)

Thats also the case for the favicon.


Textfield with type number updown arrow is not working in Mozila

Up-down arrow stop working in mozila accidentally.

https://stackoverflow.com/questions/67382247/material-ui-textfield-with-type-number-up-down-arrow-stopped-working-in-mozila-f


Add OpenStack image build upload procedure

What this PR does / why we need it:
Add procedure to upload gardenlinux images to OpenStack environments.
For each OpenStack environment we need to create a Openrc object with proper access information. This need to be passed for each environment to the function upload_image() together with the name of the image, builddate and the path to the image vmdk file in the local filesystem.
Updated the PR. For each OpenStack environment we need a glci.model.CicdCfg which contain internally an glci.model.Openrc object with access information and image properties. The image is now uploaded directly via web url (e.g. S3 object url) to Glance instead of uploading it from file system.
It's now also integrated with the publish process.
cc @ccwienk
Release note:

Add image upload procedure for OpenStack environments.

Updated the PR. For each OpenStack environment we need a glci.model.CicdCfg which contain internally an glci.model.Openrc object with access information and image properties. The image is now uploaded directly via web url (e.g. S3 object url) to Glance instead of uploading it from file system.
It's now also integrated with the publish process.


Hide orphaned resources and support exclude state filters on resources page (#3032)

Pull request opened by the merge tool on behalf of #3032

Merged in 23c85812eb04adc76b1b7b957dc6bc66dbcea952


🐞 [Bug]: Enhance the load domains behavior

Is there an existing issue for this?

[X] I have searched the existing issues

which package/s did you face the problem with?
Dashboard
What happened?
While testing the dashboard, I noticed that 2 requests are invoked when the reload icon is pressed. Both of them have the same response/result. Are they both needed?
the ret_count query is set to one of them, it can be done by removing the first one and send only one request with the ret_count if needed
Steps To Reproduce

Go to the dashboard
Connect your wallet
Deploy a micro VM
Go to attach a domain to it
Inspect the page and Go to the network tab
Press on the reload button beside the domains select
Watch the network tab and you'll see that two requests are sent to the server and only the difference is that the ret_count query is set to one of them

which network/s did you face the problem on?
Dev
version
b4861f5
Twin ID/s
143
Node ID/s
No response
Farm ID/s
No response
Contract ID/s
No response
Relevant screenshots/screen records
Screencast from 06-13-2024 08:46:01 AM.webm
Relevant log output
N/A

This is not possible for our implementation as we don't lose 1st page as request so we need to get count then load a random page so we might load 3rd page before 1st one

there are now 2 requests also

https://gridproxy.dev.grid.tf/nodes?ipv4=true&ipv6=true&available_for=201&status=up&page=1&size=0&ret_count=true&sort_by=free_cru&sort_order=desc&domain=true
https://gridproxy.dev.grid.tf/nodes?ipv4=true&ipv6=true&available_for=201&status=up&page=1&size=20&sort_by=free_cru&sort_order=desc&domain=true

its impossible to make it only one request. We enhanced the load domains by reducing the size of the request and set it to zero
you can validate it by checking the size flag here
https://gridproxy.dev.grid.tf/nodes?ipv4=true&ipv6=true&available_for=201&status=up&page=1&size=0&ret_count=true&sort_by=free_cru&sort_order=desc&domain=true

verified on devnet
version : a542a73

the request size is 0 now


Deleted smart contract can be called successfully

Description
A Discord member reported that he can called a deleted smart contract successfully. I can also reproduce the problem. Is this an expected behavior?
 Querying a smart contract returns CONTRACT_DELETED as expected.
Steps to reproduce

Create a smart contract
Delete the smart contract
Call the smart contract function

Additional context
No response
Hedera network
testnet
Version
latest
Operating system
None

@pathornteng Can you please attach the smart contract code you used to reproduce this issue?  I can reproduce this partially, in that I am seeing what maybe an issue with selfdestruct, but I see in hashscan and the mirror node that your contract is in a deleted state and mine is not.  More information will be helpful here.

I was able to reproduce it.  I opened an issue for it on services.

Related issue in services https://github.com/hashgraph/hedera-services/issues/11664 is closed with a fix that went in to 0.49.  Consider whether this issue is now closed?  Also, remember that with Cancun changes - in 0.50 - selfdestruct no longer deletes contracts!  (unless they were created in the exact same transaction that self destructs them)


[WIP] Generate Docs for v0.8.2

Need #696 to merge and then update feature_branch folder + re-generate docs


[EasyCodingStandard] Fixer excluded in CS can't be used in custom configuration

Hello,
Given this is my easy-coding-standard.yml:
imports:
    - { resource: 'vendor/symplify/easy-coding-standard/config/psr12.yml' }

services:
    PhpCsFixer\Fixer\Whitespace\NoExtraBlankLinesFixer:
        tokens:
            - break
            - case
            - continue
            - curly_brace_block
            - default
            - extra
            - parenthesis_brace_block
            - return
            - square_brace_block
            - switch
            - throw
            - use
            - use_trait

and my code:
<?php

declare(strict_types=1);

namespace App\Command;

use Symfony\Bundle\FrameworkBundle\Command\ContainerAwareCommand;
use Symfony\Component\Console\Helper\ProgressBar;
use Symfony\Component\Console\Output\OutputInterface;

...

while php-cs-fixer tries to fix "no_extra_blank_lines"

There's any way to use an excluded fixer in a coding standard?
Thank you.

Hi,
at the moment there is no way to unexclude excluded checker:
There was a suggestion for removing parameters before, but no one ever send any PR.
The syntax would be somewhat magic:
parameters:
    exclude_checkers:
        SomeExcludedChecker: ~ # exclude
        AnotherExcludedChecker: false # remove this line

For your sollution, I'd recommend you using PSR2 set, that has already many rules from PSR12 + add rules your need from PSR12 manually.
On the other hand, if there is no reason to exclude NoExtraBlankLinesFixer, it can be removed. It was based on early demo implementation of PSR12 made by someone else and I really didn't dig deep into this.

Hi,
Glad to hear that.
Well that could be a solution, but I wanted to stick to a CS and overwrite only the ones that I needed my way. This way I would be up to date with upstream regarding new fixers.
But I think I'll stick to your suggestion for now. In any case, I submited a PR related to NoExtraBlankLinesFixer in psr12.yml.
Thank you for your response.

Thanks for great cooperation, it is pleasure :+1:


use mockito-core instead of mockito-all

mockito-all does not work with Java 9 or later

Yes, it also still works with Java 8!
Thanks @xuwei-k ! Good work!


How work with admin users

I try use next code in function _construct:
if (!Auth::user()->role('Admin'))
$this->middleware('auth.admin');
But admin roles not works. Auth::user() is null. How I can use your package with admin users? I use spatie/laravel permissions & backpask. Thank you!

This is beyond the scope of this package.


Add BUILD_DIR env variable to configure name for build output directory

Hi there
This is my first pull request for anything, I think, so let me know if I'm breaking protocol.
I'm not exactly hot on Node backend stuff really, but the intention here was to allow the build directory to be set to anything (excluding a few reserved names like public, src, .git and node_modules).
My rationale came from doing a bit of Cordova development, where the web files are expected to be in a 'www' folder instead of 'build'
I have tested this myself that it outputs files into the specified folder, and it will throw an error if the path is forbidden.
I don't know what to do re: adding real tests, but I'm willing to take pointers

Ok, cool. That's actually a really simple solution.
To anybody who stumbles across this, it should be as simple as doing
"postbuild": "mv build www"
where www is the folder you want to output to.
(Right??)

Correct, you got it @DanProudfoot!
Really looking forward to contributions from you in the future. 😄


in your example, please change st = SuffixTree(test) to st = SuffixTree(ex)

in your example, please change st = SuffixTree(test) to st = SuffixTree(ex)

okay, Thanks


Bug: Files list renders with ~1s delay when mini.nvim is installed and a file with unknown extension exists

RTFM Checklist

[X] I have searched exisiting issues / discussions
[ ] I have read the Wiki including the Advanced section
[ ] I have read man fzf / I am well versed in shell fzf

Operating system
Mac
Shell
bash
Neovim version (nvim --version)
NVIM v0.10.1
Fzf version (fzf --version)
0.52.1 (6432f00)
Output of :lua print(os.getenv('FZF_DEFAULT_OPTS'))
nil
Is the problem reproducible with mini.sh?

[ ] My issue is reproducible with mini.sh
[ ] My issue IS NOT reproducible with mini.sh
[X] I have not tested with mini.sh (not relevant, requires LSP, Windows, etc)

Fzf-lua configuration
-- No specific setup options are required but `mini.nvim` needs to be installed.
require('fzf-lua').setup({})

Describe the bug / steps to reproduce
The latest version of fzf-lua enables icon support when mini.nvim plugin is installed.
When using files list (:FzfLua files), the list renders with ~1s delay when mini.nvim is installed and a file with unknown extension exists in current path.
The render delay happens due to overriding vim.fn.fnamemodify with a custom lua implementation in module lua/fzf-lua/path.lua and function ft_match:
  vim.fn.fnamemodify = M._fnamemodify

The lua override is called for files of unknown type and each call adds a noticeable lag. Triggering this issue can be done with a simple lua script:

Create an empty file file.bak in current path.
Create a script file.lua in current path with following contents:

_fnamemodify = function(fname, mods)
  return fname
end

vim.fn.fnamemodify = _fnamemodify

local _, res = pcall(vim.filetype.match, { filename = vim.fn.getcwd() .. "/file.bak" })
print(res)

Run the script:

➜ time nvim --headless --noplugin -l file.lua
nil

real    0m0.636s
user    0m0.622s
sys     0m0.009s

It seems that a more nested path give a longer delay for some reason.
When debugging this problem I've temporarily commented out both vim.env and vim.fn.fnamemodify overrides in lua/fzf-lua/path.lua and didn't notice the error stated in the file (E5560: Vimscript function must not be called in a lua loop callback) afterwards when using the plugin.
Could this error exist only in some versions of neovim? Maybe the override could be enabled only if version is lower than some specific release? In 0.10.1 it tentatively seems to be not needed.

The render delay happens due to overriding vim.fn.fnamemodify

Are you sure that this is what’s causing the delay? The override implements only :t for file tail (basename):
https://github.com/ibhagwan/fzf-lua/blob/cc8b1ee2868e10fb4f4c00ca827a5b2af7a9b88a/lua/fzf-lua/path.lua#L575-L580
The delay is most likely due to vim.filetype.match which is a feature of using mini.icons and there’s not much I can do about it, while I cache extensions and file names for further lookups there will still be paths which will end up calling vim.filetype.match (the fallback) which is IMHO in the crux of the issue.
Unless mini.icons implements more static extensions/file name and a logic that doesn’t rely on calling vim.filetype.match there’s nothing else I can do about this, for further reading see @echasnovski’s input in https://github.com/echasnovski/mini.nvim/issues/1007#issuecomment-2242499529 as well as the discussions in #1319.

About this:

When debugging this problem I've temporarily commented out both vim.env and vim.fn.fnamemodify overrides in lua/fzf-lua/path.lua and didn't notice the error stated in the file (E5560: Vimscript function must not be called in a lua loop callback) afterwards when using the plugin.

The call is wrapped in pcall so it won’t generate the error but it would also not display an icon for all paths where the vim.filetype.match is required (a lot).

Are you sure that this is what’s causing the delay?

Please try out the attached lua script with an empty file of unknown type.
When vim.fn.fnamemodify is overwritten with a custom lua function calls to vim.filetype.match seem to last a long time:
_fnamemodify = function(fname, mods)
  return fname
end

vim.fn.fnamemodify = _fnamemodify

The override can be an echo function like in the example, not even implementing :t but returning instantly.  Running it with nvim having disabled plugins shows the time delay.

Please try out the attached lua script with an empty file of unknown type.

Ty for the debugging efforts @somnam, I will try.
However, as I mentioned above, without this override we won’t have the vim.filetype.match severely impacting mini.icons functionality.

Oh, I get it. Other file types don't display correctly without the override. That's indeed limiting. Thought it's strange that the lua override generates such a delay. Do you have an idea what might cause it?

Oh, I get it. Other file types don't display correctly without the override. That's indeed limiting. Thought it's strange that the lua override generates such a delay. Do you have an idea what might cause it?

Perhaps this:

The override can be an echo function like in the example, not even implementing :t but returning instantly. Running it with nvim having disabled plugins shows the time delay.

The above is not a good test, not doing what the modifier is requesting returns full paths (instead of, for example,  just the basename when :t is requested), that, in fact causes the runtime code to take different paths inside vim.filetype.match which falls back into string pattern matching, if it needs to exhaust a lot of patterns, it will generate a delay.
From my experiments only :t and :p (which I didn’t implement) are called in our case, that means, either :p needs to be implemented to make sure the same code path is taken or I missed something and additional modifiers need to be implemented.

The above is not a good test, not doing what the modifier is requesting returns full paths

Yeah, I'm not sure what's the issue here. When I use the _fnamemodify fallback from lua/fzf-lua/path.lua in my script instead of my echo override I get the same long delay. Uhm, maybe it's due to overriding the vim builtin with a lua function and that will always cause a delay. I'm not familiar with neovim internals tho.
Thanks for looking into this, probably disabling the icons globally is the quickest fix.

The above is not a good test, not doing what the modifier is requesting returns full paths

Yeah, I'm not sure what's the issue here. When I use the _fnamemodify fallback from lua/fzf-lua/path.lua that implements :t in my script instead of my echo override I get the same long delay. Uhm, maybe it's due to overriding the vim builtin with a lua function and that will always cause a delay. I'm not familiar with neovim internals tho.

I just did some testing, implementing both :p and :t, if anything it made things worse (as probably more patterns needed to be tested against).

Thanks for looking into this, probably disabling the icons globally is the quickest fix.

ATM, there is no applicable workaround to this issue, this  is probably the most reasonable medium, to not use mini.icons in the auto-detect algo, if anyone wants to use mini they can always add defaults = { file_icons = 'mini' } to their setup call.
Unfortunately having to rely on vim.filetype.match isn’t a good fit for anything that requires performance, although I’m pretty sure the second+ run(s) will always be faster (due to caching) the first time lag/delay is annoying and there will still be cases where cache isn’t applicable (I.e. persistent delay).

https://github.com/ibhagwan/fzf-lua/commit/769b6636af07ea4587e6c06067d8fe9fb0629390
@somnam, post the above commit only nvim-web-devicons is auto-detected and enabled, mini.icons will require an additonal manual step:
require("fzf-lua").setup({ defaults = { file_icons = "mini" } })

@somnam, post the above commit only nvim-web-devicons is auto-detected and enabled, mini.icons will require an additonal manual step:

@ibhagwan, this is really unfortunate. At least for these reasons:

The "... there will still be cases where cache isn’t applicable (I.e. persistent delay)" is not the case with upstream MiniIcons.get(). All outputs are persistently cached and the second+ call with the same arguments is always faster.
The git_icons is enabled by default yet Git is notoriously slow and is for me the persistent cause of significant delay on large projects (until you told me about an explicit opt-out git_icons = false, which is indeed faster).
On Nightly 0.11 vim.filetype.match() was optimized for quite visible performance gain (about 4x faster). So at least auto-enabling there might be an option.

One thing I noticed is that there is indeed not that much difference between the first and second execution of :FzfLua files git_icons=false. For reference, I tend to use this repo for profiling when I need "big realistic repo" (like for 'mini.pick' and 'mini.icons'), fzf finds 1010325 files there. Here is data from my profiling (measured manually with physical timer by hand; Nightly version is NVIM v0.11.0-dev-504+gaa853f362):

file_icons
Execution number
Neovim version
Duration (seconds)

'mini'
first
0.10.0
11.6

'mini'
second
0.10.0
10.3

'mini'
first
Nightly
6.36

'mini'
second
Nightly
5.5

'devicons'
first
0.10.0
2.75

'devicons'
second
0.10.0
2.75

'devicons'
first
Nightly
2.72

'devicons'
second
Nightly
2.75

false
first
0.10.0
1.0

false
first
Nightly
0.91

The second execution in session of 'mini' case should be much faster in theory.

A bit of exploration showed that require('fzf-lua.devicons').PLUGIN._state.icons indeed doesn't cache all cases, but only extensions and filenames returned by MiniIcons.list('file'). Using MiniIcons.get() directly would have resulted into all 1010325 cases being cached. However I think this might be bad for 'fzf-lua' as it needs to communicate that cache through RPC each time, right?
But the general idea of "vim.filetype.match() should not be called on second+ call for same input" seems achievable. For example, caching file name when it does not have extension should improve things (as there are 41239 such files which on my machine with original vim.filetype.match() takes about 8 seconds). So I applied the following patch:
Patch with caching filenames without extension
diff --git a/lua/fzf-lua/devicons.lua b/lua/fzf-lua/devicons.lua
index c1ba2be..1e35d6b 100644
--- a/lua/fzf-lua/devicons.lua
+++ b/lua/fzf-lua/devicons.lua
@@ -470,6 +470,11 @@ M.get_devicon = function(filepath, extensionOverride)
   icon = icon or STATE.default_icon.icon
   color = color or STATE.default_icon.color

+  if not ext then
+    local name = STATE.icons.by_filename_case_sensitive and filename or filename:lower()
+    STATE.icons.by_filename[name] = { icon = icon, color = color }
+  end
+
   if STATE.icon_padding then
     icon = icon .. STATE.icon_padding
   end

After that, the same profiling for :FzfLua files git_icons=false gave this:

file_icons
Execution number
Neovim version
Duration (seconds)

'mini'
first
0.10.0
10.75

'mini'
second
0.10.0
5.38

'mini'
first
Nightly
6.47

'mini'
second
Nightly
5.5

Massive improvement for second execution on 0.10.0.
But, as there is no improvement on Nightly, my instinct says that it is not vim.filetype.match() calls that causes the difference extra ~2.75 seconds compared to file_icons = 'devicons'.

Sorry for the wall of text. Was curious about the nature of delay. Hope it all helps :)

@somnam, having the whole second as delay supposedly due to vim.filetype.match() seems quite big for me. Could you clarify, how this delay manifests itself? Ideally, make a screencast.
Also, assuming you have 'mini.misc' available, could you, please execute the following commands and post what it added to the following buffer:
:lua require('mini.misc').setup({ make_global = { 'put', 'put_text', 'stat_summary', 'bench_time' } })
:lua buf_id = vim.api.nvim_create_buf(false, true)
:lua put_text(stat_summary(bench_time(vim.filetype.match, 1000, { filename = 'should-not-match', buf = buf_id })))

For me it gives something like this:
{
  maximum = 0.000738008,
  mean = 0.000245835569,
  median = 0.00024022,
  minimum = 0.00023772,
  n = 1000,
  sd = 2.7421614662341e-05
}

@echasnovski, tysm for the detailed information and testing!

The "... there will still be cases where cache isn’t applicable (I.e. persistent delay)" is not the case with upstream MiniIcons.get(). All outputs are persistently cached and the second+ call with the same arguments is always faster.

Correct, fzf-lua doesn’t use the upstream MiniIcons.get cache all paths and full paths, this would require much more memory and is bad for many different reasons.

The git_icons is enabled by default yet Git is notoriously slow and is for me the persistent cause of significant delay on large projects (until you told me about an explicit opt-out git_icons = false, which is indeed faster).

That is 100% true, the only reason this remains true by default is because I dislike breaking changes and this was true for a long time until I realized it was causing delay in large repos (granted it has to be pretty big), I also added a special warning so users are aware if it’s exceptionally slow - doing so with mini would require profiling each icon get call, not very practical.
There might be a case to default git_icons to false even though it would be considered “breaking” (btw, it’s false in many of the offered :FzfLua profiles).

On Nightly 0.11 vim.filetype.match() was optimized for quite visible performance gain (about 4x faster). So at least auto-enabling there might be an option.

If nightly is much better we can revisit this but it’s not the only reason it makes sense to default to false, given the extreme popularity of mini.nvim I expect 99% of the users to have mini installed which means loading mini.icons automatically will succeed, even for those who do not wish to use icons, this differs from users who wish to use icons in their config and therefore install an icons package specifically.

A bit of exploration showed that require('fzf-lua.devicons').PLUGIN._state.icons indeed doesn't cache all cases, but only extensions and filenames returned by MiniIcons.list('file'). Using MiniIcons.get() directly would have resulted into all 1010325 cases being cached. However I think this might be bad for 'fzf-lua' as it needs to communicate that cache through RPC each time, right?

Correct, as I mentioned in my first bullet point caching all paths similar to mini is impractical for fzf-lua, the memory requirement could also result in OOM in big repos and other issues resulting from an exceptionally big cache.

But the general idea of "vim.filetype.match() should not be called on second+ call for same input" seems achievable. For example, caching file name when it does not have extension should improve things (as there are 41239 such files which on my machine with original vim.filetype.match() takes about 8 seconds). So I applied the following patch:

While it might work for your machine could there  be other (extreme cases) where it would result in worse performance?
Also, this is where it starts to become questionable, if you cached only the file name you’ll end up potentially a wrong icon sometimes, filetype is determined by the full path (using full path pattern matching by the runtime), but if you cached by file name only you will have set the icon to the one retuned by the first call.
NOTE: this is in fact what currently happens with some extensions, since we cache the extension only and not the full path, the first seen extension would be the one for all future occurrences of the same extension regardless of the path, this is a bug by design as I wanted to minimizes the cache size.

Massive improvement for second execution on 0.10.0.

Sorry for the wall of text. Was curious about the nature of delay. Hope it all helps :)

Always does, ty @echasnovski!

If nightly is much better we can revisit this but it’s not the only reason it makes sense to default to false, given the extreme popularity of mini.nvim I expect 99% of the users to have mini installed which means loading mini.icons automatically will succeed, even for those who do not wish to use icons, this differs from users who wish to use icons in their config and therefore install an icons package specifically.

Hence the official suggestion for plugin authors to use icons only if _G.MiniIcons variable is present. This approach is used for any 'mini.nvim' module to check whether the user called its setup(). So this becomes:

If _G.MiniIcons is not nil -> user called require('mini.icons').setup() -> use icons.
If _G.MiniIcons is nil -> user did not call require('mini.icons').setup() -> don't use icons.

While it might work for your machine could there be other (extreme cases) where it would result in worse performance (many random files which would require an even larger cache)?

Sure, with random files which don't contain dot this might happen to a certain extent. However, a reference project is built from real world repos and it contains about 4.1% files without extension (41239 out of 1010427). From which only about 1.9% (19102) are unique and will be used in cache. I think caching 1.9% of searched files will be acceptable for most users. Especially if they use 'mini.icons' which already has bigger cache.

Also, this is where it starts to become questionable, if you cached only the file name you’ll end up potentially a wrong icon sometimes, filetype is determined by the full path (using full path pattern matching by the runtime), but if you cached by file name only you will have set the icon to the one retuned by the first call.

As far as I understand, filetype matching is currently done based on basename, hence the caching suggestion. Yes, matching filetype based on full path was added yesterday and it indeed results in a fuller matching.
In vast majority of real world cases (I feel like over 99.9%) relying on only extension and basename is enough. The other cases are just cherry on top. So I think this should be a good compromise in 'fzf-lua'.
Note: by the way, filetype matching is better when a dummy buffer is supplied (the reason is roughly that some file names are intentionally not matched because the answer should differ on buffer content). Like here. This should also resolve this part.

Hence the official suggestion for plugin authors to use icons only if _G.MiniIcons variable is present.

That’s a good idea, I know about this I just didn’t think about it, the code already checks the variable exists to make sure setup was called :)
https://github.com/ibhagwan/fzf-lua/blob/769b6636af07ea4587e6c06067d8fe9fb0629390/lua/fzf-lua/devicons.lua#L183-L191
Btw, I forgot to ask you if a refresh the icon colors is ever needed? with nvim-web-devicons I reload the icons once bg changes from dark to light, are the MiniIcons.. hl groups ever updated?
As far as I understand, filetype matching is currently done based on basename, hence the caching suggestion. Yes, matching filetype based on full path was added yesterday and it indeed results in a fuller matching.
Correct, that’s because I wrote this code before your recent changes, I briefly tested full path matching and it does impact performance a bit so I wanted to test it more before (if?) I make the change to match mini’s internal get.

In vast majority of real world cases (I feel like over 99.9%) relying on only extension and basename is enough. The other cases are just cherry on top. So I think this should be a good compromise in 'fzf-lua'.

That was indeed my logic.

Note: by the way, filetype matching is better when a dummy buffer is supplied (the reason is roughly that some file names are intentionally not matched because the answer should differ on buffer content). Like here. This should also resolve this part.

I saw that and wanted to avoid the scratch buffer bit as it does go into a code path internal that I’d like to avoid as it could impact performance or potentially break the monkey patch, the txt file issue I would consider an upstream bug, I don’t see any reason why an empty buffer in the call args should change the result of a match, especially with a case as simple as txt.

Btw, for comparison I ran the libuv profiler with mini on the latest nightly, it is indeed much better:

First run, same folder as above

Second run matches 0.10.0 as vim.filetype.match is never called a second time

@echasnovski : It seems that the reason for the observed delay isn't directly vim.filetype.match but the override of vim.fn.fnamemodify with a custom lua function in the code:
https://github.com/ibhagwan/fzf-lua/blob/cc8b1ee2868e10fb4f4c00ca827a5b2af7a9b88a/lua/fzf-lua/path.lua#L595-L599
In the initial post a minimal script was added that overrides this method the same way with a simple echo function and a timing of calling vim.filetype.match afterwards on a file with unknown extension (file.bak):
_fnamemodify = function(fname, mods)
  return fname
end

vim.fn.fnamemodify = _fnamemodify

local _, res = pcall(vim.filetype.match, { filename = vim.fn.getcwd() .. "/file.bak" })
print(res)

The result matches with the observed delay in fzf-lua ui:
➜ time nvim --headless --noplugin -l file.lua
nil

real    0m0.636s
user    0m0.622s
sys     0m0.009s

The same delay can be also observed when the override method is same as in fzf-lua  code:
M._fnamemodify = function(fname, mods)
  if mods == ":t" then
    return M.tail(fname)
  end
  return fname
end

vim.fn.fnamemodify = M._fnamemodify

local _, res = pcall(vim.filetype.match, { filename = vim.fn.getcwd() .. "/file.bak" })
print(res)

Results in:
➜ time nvim --headless --noplugin -l file.lua
nil

real    0m0.605s
user    0m0.589s
sys     0m0.009s

Removing the custom override reduces the run time of the script by a factor of 20x:
local _, res = pcall(vim.filetype.match, { filename = vim.fn.getcwd() .. "/file.bak" })
print(res)

➜ time nvim --headless --noplugin -l file.lua
nil

real    0m0.031s
user    0m0.014s
sys     0m0.010s

I hope these timings clarify a bit what was meant to be conveyed in the initial post.
The same time improvement was also observed after commenting out the override of vim.fn.fnamemodify in fzf-lua code, but for some reason the icon for the known file type didn't load correctly then:

but for some reason the icon for the known file type didn't load correctly then:

I already explained the reason in https://github.com/ibhagwan/fzf-lua/issues/1358#issuecomment-2253418968, it’s because filetype match now fails with E5560 (in the pcall).

Btw, I forgot to ask you if a refresh the icon colors is ever needed? with nvim-web-devicons I reload the icons once bg changes from dark to light, are the MiniIcons.. hl groups ever updated?

'mini.icons' intentionally is designed only around highlight groups. Built-in icon data use only fixed set of 9 color groups, users can add any highlight groups in config as they like.
The highlight groups in icon data won't change between different color schemes, but as 'fzf-lua' relies on colors then they need to be updated because they might change. If highlighting was done with Neovim's utilities using only highlight groups, then it would have been no need to reload colors.

Correct, that’s because I wrote this code before your recent changes, I briefly tested full path matching and it does impact performance a bit so I wanted to test it more before (if?) I make the change to match mini’s internal get.

As a heads-up, I think there will be one more small-ish change to how "file" and "extension" is resolved (due to surfacing of echasnovski/mini.nvim#1086). I don't think this will affect 'fzf-lua' mocking, but still.

... the txt file issue I would consider an upstream bug, I don’t see any reason why an empty buffer in the call args should change the result of a match, especially with a case as simple as txt.

As it was explained to me, the idea is to mimic Vim's filetype detection to the dot, which makes it easier to maintain. The logic is to rely on content checking to not return 'text' for help files. While I agree that particular case of 'txt' can be improved, there are unfortunately more cases like this. Basically, if filetype detection relies on content, it will not correctly detect filetype. Here are some notable examples where presence of buf makes a difference:

The 'ts' extension is not recognized as 'typescript' filetype, because it might be detected as 'xml'.
The 'bash' extension is not recognized as 'sh' filetype, because it might have different flavors.
And many more...

I initially thought that using contents = { '' } in vim.filetype.match() would be enough, but it is not. Which indeed seems to be unintended, but I do not have energy right now for fixing it upstream.

Auto enables mini.icons if _G.MiniIcons is present

That's nice. Thank you!
I've another thing to nit pick even here. Users of 'mini.icons' might have both _G.MiniIcons variable and 'nvim-web-devicons' module (due to MiniIcons.mock_nvim_web_devicons() which is present to make it work for plugins which don't yet have support for 'mini.icons'), while users of 'nvim-web-devicons' will likely not have _G.MiniIcons variable. I'd say that preferring _G.MiniIcons test is more versatile, but I hope that eventually it will be not needed for users to have. So not really sure if its worth changing.

Btw, for comparison I ran the libuv profiler with mini on the latest nightly, it is indeed much better:

I sure hope so that spending a week on profiling, refactoring, improving (and arguing that improvement should be merged) was worth it :)

@echasnovski : It seems that the reason for the observed delay isn't directly vim.filetype.match but the override of vim.fn.fnamemodify with a custom lua function in the code:
...
The result matches with the observed delay in fzf-lua ui:

Ah, that delay. Yeah, it is visibly less than a second for me, but it is there. With those examples I understand it better, thanks!
It is indeed weird and just too big of a difference, but I think I have a clue of what's going on.
There is no such delay if your examples use almost any different file name which doesn't match anything. For example, replace '/file.bak' with '/no-detection-here'. This tells that 'file.bak' is special. Which indeed it is, as it is a part of "ignored" extensions, which in turn use vim.fn.fnamemodify(file, ':r') to remove last extension. As mocks return same as input in this case, there is seemingly infinite loop here. Taking ':r' modifier into account seems to solve the issue.

I've another thing to nit pick even here. Users of 'mini.icons' might have both _G.MiniIcons variable and 'nvim-web-devicons' module (due to MiniIcons.mock_nvim_web_devicons() which is present to make it work for plugins which don't yet have support for 'mini.icons'), while users of 'nvim-web-devicons' will likely not have _G.MiniIcons variable. I'd say that preferring _G.MiniIcons test is more versatile, but I hope that eventually it will be not needed for users to have. So not really sure if its worth changing.

@ibhagwan, I've just been bitten by it myself :rofl: (as I have both _G.MiniIcons and MiniIcons.mock_nvim_web_devicons()). The symptoms are very fast execution at expense of very few icons shown. This is because since yesterday there are significantly less explicitly supported extensions returned in MiniIcons.list('extensions') because there is no need in them anymore. As it is used inside mocking of require('nvim-web-devicons').get_icons_by_extension(), it makes 'fzf-lua' think that there are significantly less supported extensions then there is.
I am not sure which approach you'd find better here, but I thought leaving this here for better visibility should not be a bad thing.

The highlight groups in icon data won't change between different color schemes, but as 'fzf-lua' relies on colors then they need to be updated because they might change. If highlighting was done with Neovim's utilities using only highlight groups, then it would have been no need to reload colors.

Not possible, the headless neovim wrapper is an external process unaware of the highlight groups in the main thread, these need to be queried from the main thread and relayed as colors.
Since there’s a finite amount of hl groups I guess there’s no harm in resolving these each time (not happening currently).

As a heads-up, I think there will be one more small-ish change to how "file" and "extension" is resolved (due to surfacing of https://github.com/echasnovski/mini.nvim/issues/1086). I don't think this will affect 'fzf-lua' mocking, but still.

fzf-lua uses its own path utilities to extract the extension, I don’t think it would change anything.

Here are some notable examples where presence of buf makes a difference:

I know about these, I was referring to the difference in resolving between having no buffer and a scratch empty buffer (as you have in mini).

I've another thing to nit pick even here. Users of 'mini.icons' might have both _G.MiniIcons variable and 'nvim-web-devicons' module (due to MiniIcons.mock_nvim_web_devicons() which is present to make it work for plugins which don't yet have support for 'mini.icons'), while users of 'nvim-web-devicons' will likely not have _G.MiniIcons variable. I'd say that preferring _G.MiniIcons test is more versatile, but I hope that eventually it will be not needed for users to have. So not really sure if its worth changing.

The first class mini support  is much better than the mock_nvim_web_devicons() which will have many icons missing (due to not calling vim.filetype.detect).

So not really sure if its worth changing.

Shouldn’t be a big deal to change, I can check if the package path contains mini so I’ll know it’s the mock.

I sure hope so that spending a week on profiling, refactoring, improving (and arguing that improvement should be merged) was worth it :)

I wasn’t aware this was your handiwork, chapeau :)

taking ':r' modifier into account seems to solve the issue.

Ty for the debugging @echasnovski! I’ll add :r support.

I've just been bitten by it myself 🤣 (as I have both _G.MiniIcons and MiniIcons.mock_nvim_web_devicons())

I was just replying to you about this, easy solution with self._ package:match.

@echasnovski: Thank you for finding the infinite loop case, that fully explains the observed behaviour 🎉 .

Here are some notable examples where presence of buf makes a difference:

I know about these, I was referring to the difference in resolving between having no buffer and a scratch empty buffer (as you have in mini).

Ah, yeah, maybe that makes sense.
I've just tried something, but it will also error with E5560 due to vim.api.nvim_buf_get_lines() and vim.api.nvim_buf_line_count(). Mocking them seems to fix the issue. Here is the patch:
More mocking to the god of mocking
diff --git a/lua/fzf-lua/path.lua b/lua/fzf-lua/path.lua
index 885d683..44cb859 100644
--- a/lua/fzf-lua/path.lua
+++ b/lua/fzf-lua/path.lua
@@ -585,6 +585,9 @@ M._env = setmetatable({}, {
   end
 })

+M._nvim_buf_get_lines = function() return { "" } end
+M._nvim_buf_line_count = function() return 1 end
+
 function M.ft_match(args)
   if not args or not args.filename then
     error('At least "filename" needs to be specified')
@@ -595,14 +598,20 @@ function M.ft_match(args)
   -- E5560: Vimscript function must not be called in a lua loop callback
   local _env = vim.env
   local _fnamemodify = vim.fn.fnamemodify
+  local _nvim_buf_get_lines = vim.api.nvim_buf_get_lines
+  local _nvim_buf_line_count = vim.api.nvim_buf_line_count
   vim.env = M._env
   vim.fn.fnamemodify = M._fnamemodify
+  vim.api.nvim_buf_get_lines = M._nvim_buf_get_lines
+  vim.api.nvim_buf_line_count = M._nvim_buf_line_count
   -- Normalize the path and replace "~" to prevent the internal
   -- `normalize_path` from having to call `vim.env` or `vim.pesc`
   local fname = M.normalize(M.tilde_to_HOME(args.filename))
-  local ok, ft, on_detect = pcall(vim.filetype.match, { filename = fname })
+  local ok, ft, on_detect = pcall(vim.filetype.match, { filename = fname, buf = 0 })
   vim.fn.fnamemodify = _fnamemodify
   vim.env = _env
+  vim.api.nvim_buf_get_lines = _nvim_buf_get_lines
+  vim.api.nvim_buf_line_count = _nvim_buf_line_count
   if ok then return ft, on_detect end
 end

This makes it work for 'ts', 'asm' extensions, and others.
There is only one problem I can observe and it is with shell files (like 'sh', 'bash', etc.; the ones which use these detection functions). But those error even in a vim.filetype.match({ filename = 'hello.sh', buf = 0 }) (actual buffer id doesn't matter) inside nvim -u NONE but not with nvim --clean. Which is indeed very strange and looks like a bug.
Accounting for these extensions instead of currently done 'txt' might solve this partially, but not 100%, because there are more detect.bash, detect.sh, etc. cases. Only somehow tweaking the 'fzf-lua' child process (maybe something to do with runtime paths?) or fixing it upstream seems to be the 100% solution. But I am clueless here, I am afraid.

https://github.com/ibhagwan/fzf-lua/commit/d1493cfac8e5c4907759ac827b983fa5aeaf7ad4
@echasnovski @somnam see the latest iteration changes:

If nvim-web-devicons isn't avilable and the user called mock_nvim_web_devicons fzf-lua will load mini.icons natively, it will also call require("mini.icons") setup if it can't find _G.MiniIcons beacuse why not?

Added :r modifier with a slight change, reading the docs if the file starts with a dot it should be returned as is:
https://github.com/ibhagwan/fzf-lua/blob/d1493cfac8e5c4907759ac827b983fa5aeaf7ad4/lua/fzf-lua/path.lua#L579-L582

MiniIconsXXX hl groups are now refreshed with each run:

@echasnovski, if you ever decide to add new fixed hl groups kindly let me know
https://github.com/ibhagwan/fzf-lua/blob/d1493cfac8e5c4907759ac827b983fa5aeaf7ad4/lua/fzf-lua/devicons.lua#L178-L198

I've just tried something, but it will also error with E5560 due to vim.api.nvim_buf_get_lines() and vim.api.nvim_buf_line_count(). Mocking them seems to fix the issue. Here is the patch

Ty @echasnovski, I'll test, not a big fan of so many monkey patches but we can give it a shot.

https://github.com/ibhagwan/fzf-lua/commit/6edea7e876477a2a5811c1a172ff6d2a25669e1f
@echasnovski tysm for the improved mock patch, works great!
With this I believe mini.icons first class support is in a great state.

MiniIconsXXX hl groups are now refreshed with each run:

@echasnovski, if you ever decide to add new fixed hl groups kindly let me know

I'll do better: I'll try to not add new highlight groups.
But that said, I think it might have been a good idea to cache actually used in utils.hexcol_from_hl() highlight groups and then use them when color scheme changes. It doesn't need manual tracking, more to the point, and is more robust for users which might want to use their own highlight groups. But using only MiniIconsXxx groups results in cleaner UI, so maybe it is a good thing to discourage using them here :)

With this I believe mini.icons first class support is in a great state.

:rocket:

But that said, I think it might have been a good idea to cache actually used in utils.hexcol_from_hl() highlight groups and then use them when color scheme changes. It doesn't need manual tracking, more to the point, and is more robust for users which might want to use their own highlight groups. But using only MiniIconsXxx groups results in cleaner UI, so maybe it is a good thing to discourage using them here :)

Correct, no biggie, I'll make the modifications for that.

Just remember about the mentioned earlier '.sh', '.bash', etc. issues if anybody will raise an issue about them not having an icon.

Already found an issue with sh, will have to see what went wrong with the mock as it fails with autoset_dpi.sh /usr/share/nvim/runtime/lua/vim/filetype/detect.lua:1352: bad argument #1 to 'find' (string expected, got nil)

6edea7e
@echasnovski tysm for the improved mock patch, works great!
With this I believe mini.icons first class support is in a great state.

Something seems not right :( On 6edea7e87647 I get inconsistent number of search results with 'mini.icons' enabled. Sometimes even 0. Doesn't seem to be the case on d1493cfac8e5.

https://github.com/ibhagwan/fzf-lua/commit/d0a8c9ac40d12043c1a7fba69820d713c810ec26
@echasnovski, I didn't read this properly the first time, added exceptios for the 4 prolematic types.

https://github.com/ibhagwan/fzf-lua/commit/131d755dbeadb9adb31c54599fa15dd232f92a64
Ok, I think this is the final commit in regard to this issue and mini.icons in regards to:

But that said, I think it might have been a good idea to cache actually used in utils.hexcol_from_hl() highlight groups and then use them when color scheme changes. It doesn't need manual tracking, more to the point, and is more robust for users which might want to use their own highlight groups. But using only MiniIconsXxx groups results in cleaner UI, so maybe it is a good thing to discourage using them here :)

Used hl groups are discovered as part of the enumeration of filenames/filetypes/extensions and are resolved to hex colors every time fzf-lua UI is opened.

Default colors

:hi! link MiniIconsAzure ErrorMsg

:hi! clear MiniIconsAzure

@somnam, it seems that with the :r fix the initial enumeration also opens pretty fast:
:FzfLua files file_icons=mini profile=true query=[DEBUG fzf_opts.--tiebreak=index

First open:

Second open:

Compared to the first open times posted in https://github.com/ibhagwan/fzf-lua/issues/1358#issuecomment-2254171146 this is a great improvement, tysm for all the help @echasnovski!


Has WinUI publishing regressed for you?

Sorry for posting an issue on your project to ask you this. But searching GitHub I noticed you had a WinUI MAUI pipeline similar to mine. I've found that in the past few weeks my build has regressed (dotnet/maui/issues/20299).
I see that your last publish was three weeks ago which I think would have been before .NET 8.0.101 and .NET MAUI 8.0.6 releasing. I'd be curious to see if your next publish has any issues. Apologies again for posting an issue like this on your GitHub, potentially you won't have any issue, but if you do, hopefully I will have at least saved you some time debugging.

Hey @BurkusCat
No problem at all!
I didn't publish new Release after upgrading to NET 8 but I did a pre Release that is working.
Indeed I was struggling with issue similar to the one that you are describing..
https://github.com/Skuty/TrackYourDay/compare/main...refactor-update-net-version-to-8, two last commits were the one that fixed the issue.

Thanks @Skuty - your pipelines where you have split NuGet restore from build, led me to do the same thing. That is where I realised my issue was I was setting RUNTIMEIDENTIFIER: win-x64 globally in my pipeline which caused all steps to use it even though I only wanted specific steps to use it. Removing that global variable resolved the issue for me and allowed me to create builds that outputted to the win10-x64 folder. Thanks again! :)


[FR] Bluetooth QR code scanner compatibility improvement

Please verify that this feature request has NOT been suggested before.

[X] I checked and didn't find a similar feature request

Problem statement
I would love to use a zebra DS2278 Bluetooth barcode scanner in it’s BLE mode.
But it really likes to replace the 0x22 quotation marks in the storage locations with U+201D.
I’m not entirely sure yet who’s to blame and I wouldn’t be surprised if this problem apppears with other scanners too.
This happens in windows and ios at least.
see here
QR CODE: {"stocklocation": 1}
Scanned: {“stocklocation”: 1}

Suggested solution
I wonder if it would be possible to consider them equivalent and replace them with the right character during input?
Describe alternatives you've considered
You can set this particular model to a classic bluetooth HID mode and that works fine but consumes more energy.
I have tried a few different code pages and keyboard localizations but it seems to persistently be a problem.
Examples of other systems
No response
Do you want to develop this?

[X] I want to develop this.

Adding a setting to the barcode plugin to replace these chars would not be too difficult. I'll have a look into this before the next release.

What about a custom replace regex setting like we could input via sed? This can actually all happen in the browser and would be extremely generic and not specific to this scanner model.

This might tie in well with some of the ideas raised in https://github.com/inventree/InvenTree/pull/4336
As this config is specific to a particular scanner, it does seem to make sense to have these a "browser" settings (not user or global)

@diodenschein to clarify on this one - you're talking about the web interface, yeah?

This requires some further thought before implementation, so bumping from the next release cycle

Sorry I haven't responded.
Life got in the way.
I would like to look into what's going on a bit more and have forgotten what I exactly did.
I'll test some more cases and write them down.


make doesn't seem to work

Didn't see a read me - ran make and got this :
$ make
cc -std=c99 -Wall -pedantic -Wextra -Werror    -c -o jshon.o jshon.c
jshon.c:9:21: fatal error: jansson.h: No such file or directory
 #include <jansson.h>
                     ^
compilation terminated.
make: *** [jshon.o] Error 1

You need to install jansson. If you already have it installed you're probably missing a "development" package or something from your distribution.


Webpack refactor

closes https://github.com/j4k0xb/webcrack/issues/6
closes https://github.com/j4k0xb/webcrack/issues/30
closes #33
supersedes #31

Should also strip the __esModule property? This still got emitted currently:
Object.defineProperty(exports, "__esModule", {
  value: true
});

Also, these JSON imports and external imports weren't unbundled

Should also strip the __esModule property? This still got emitted currently:

Done

Also, these JSON imports and external imports weren't resolved as they should? They still emit a .js file instead of .json or inlining the import

emitting .json is now also implemented
externals are properly resolved (by ignoring) but not inlined yet

also, export statements aren't transformed.
they are firstly all initialized within a single VariableAssignment to undefined, then get assigned the actual value later.

thats specific to typescript: https://www.typescriptlang.org/play?module=1#code/KYDwDg9gTgLgBAG2PAhnAvHAjAbiA
this PR is mostly about fixing the webpack issues themselves

acked

Externals are inlined now:
import { MessageChannel, parentPort, Worker, workerData } from "worker_threads";

And import paths are properly resolved again for existing modules:
import * as json from "./1.json"; instead of import * as json from "1";

:thinking: is anything still blocking this pr?

yeah there are a couple issues like creating multiple conflicting import { a } from
didn't have much time recently to work on it

👌

yeah there are a couple issues like creating multiple conflicting import { a } from didn't have much time recently to work on it

my few cents: generate names like import { a as a$chunkId$ } from './chunkId.js';


Issue with nested v-for loop

Hello,
I don't know if it's a bug or not but unfortunately  nobody could help me.
I have 2 items, when I click on one of both I call a method which display content (with v-if property and 2 nested v-for). It works well the first time but next, I get this message : Uncaught TypeError: Cannot read property 'raw' of undefined ? Basically, I want to display the current content (after click on the item) and hide the others in playing with a "visible" boolean property.
Here is the whole code (simplified) :http://jsbin.com/jubuko/edit?html,output
and project test here : http://telkea.com/CI-test/
This is odd, I hope we could help me.
Thank you very much.

Hi!
Didn't you mean children1 in object.children instead of children1 in object in the second loop? It appears to be working when this is fixed.

you are the boss!!!!!!
Thank you so much.


Please Monitor or Take a Poll on the New Feedback Mechanism After Implementing

While the previous feedback method may not have been optimal, most people perceive a thumbs up/down feedback box as a dismissive way for a company/service to easily disregard feedback without follow-up.  It would be helpful if the documentation team took baseline polling (or asked a 3rd party company to conduct it on their behalf) before and after to measure if people felt more heard.
The perception that you cannot help/are not truly heard when documentation is broken greatly factors into satisfaction/dissatisfaction for a product.

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

ID: fe6e7ce4-21d7-4105-0be1-cc97203cfe78
Version Independent ID: fe6e7ce4-21d7-4105-0be1-cc97203cfe78
Content: Provide feedback for Microsoft Learn content - Contributor guide
Content Source: Contribute/content/provide-feedback.md
Product: non-product-specific
GitHub Login: @carlyrevier
Microsoft Alias: cahublou

Thank you, @jarredm-demo, for your feedback. We have shared these updates with our MVP community and have received a lot of great feedback to help shape future capabilities and features. While we continue to iterate on them, we hope you’ll continue to share your feedback using the new feedback system or by submitting public pull requests for content that has this capability already enabled. You can find more information here: https://learn.microsoft.com/en-us/contribute/content/how-to-write-quick-edits


Code example to save a custom model with a serve() method fails

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
Yes and No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
Mac OS X 10.13.6
Mobile device (e.g. iPhone 8, Pixel 2, Samsung Galaxy) if the issue happens on mobile device:
N/A
TensorFlow installed from (source or binary):
binary
TensorFlow version (use command below):
VERSION='2.0.0-preview'
GIT_VERSION="b'v1.12.0-6502-g76aa6cf917'"
Python version:
3.6.8
Bazel version (if compiling from source):
N/A
GCC/Compiler version (if compiling from source):
N/A
CUDA/cuDNN version:
N/A
GPU model and memory:
N/A

Describe the current behavior
The documentation of the tf.saved_model.save() function shows a code example to save a custom model with a serve() method, but it fails:

when subclassing the keras.models.Model class, it is compulsory to define a call() method (or else you get NotImplementedError: When subclassing the Model class, you should implement a call method..
when saving the model as shown in the code example, I get ValueError: Exporting an object with no tf.saved_model.save(..., signatures=...) argument specified, and with more than one @tf.function-decorated method attached to it: ['_default_save_signature', 'serve']. The signature keys for these functions are ambiguous. Specify signature functions explicitly.

However it works if I define a call() method and I specify the signature explicitly.
Describe the expected behavior
Perhaps the documentation just needs to be fixed to add a call() method and an explicit signature argument, but it would be nicer if it could work without having to do that.
Code to reproduce the issue
import tensorflow as tf
from tensorflow import keras

(X_train, y_train), (X_test, y_test) = keras.datasets.mnist.load_data()

class MyModel(tf.keras.Model):
    def __init__(self):
        super().__init__()
        self.probas = keras.layers.Dense(10, activation="softmax")
    @tf.function(input_signature=[
        tf.TensorSpec(shape=[None], dtype=tf.string)])
    def serve(self, serialized):
        expected_features = {
            "image": tf.io.FixedLenFeature([28 * 28], dtype=tf.float32)
        }
        examples = tf.io.parse_example(serialized, expected_features)
        return self.probas(examples["image"])
    def call(self, inputs):
        return self.probas(inputs)

m = MyModel()
m.compile(loss="sparse_categorical_crossentropy", optimizer="sgd")
m.fit(X_train.reshape(-1, 28*28), y_train)
tf.saved_model.save(m, "my_model_test",
    signatures=m.serve.get_concrete_function(
        tf.TensorSpec(shape=[None], dtype=tf.string, name="serialized_inputs")))

You can try removing the call() method, it will fail. You can also try removing the signatures argument in the tf.saved_model.save() call, it will fail.
Other info / logs
Here is the output I get when I don't specify the signature:
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-424-4d06f50f5010> in <module>
      2 m.compile(loss="sparse_categorical_crossentropy", optimizer="sgd")
      3 m.fit(X_train.reshape(-1, 28*28), y_train)
----> 4 tf.saved_model.save(m, "my_model_test")#,
      5 #    signatures=m.serve.get_concrete_function(
      6 #        tf.TensorSpec(shape=[None], dtype=tf.string, name="serialized_inputs")))

~/.virtualenvs/tf2/lib/python3.6/site-packages/tensorflow/python/saved_model/save.py in save(obj, export_dir, signatures)
    820
    821   if signatures is None:
--> 822     signatures = _find_function_to_export(saveable_view)
    823   signatures = _canonicalize_signatures(signatures)
    824

~/.virtualenvs/tf2/lib/python3.6/site-packages/tensorflow/python/saved_model/save.py in _find_function_to_export(saveable_view)
    144            "keys for these functions are ambiguous. Specify signature "
    145            "functions explicitly.").format(
--> 146                [previous_attribute_name, name]))
    147     exported_function = value
    148     previous_attribute_name = name

ValueError: Exporting an object with no tf.saved_model.save(..., signatures=...) argument specified, and with more than one @tf.function-decorated method attached to it: ['_default_save_signature', 'serve']. The signature keys for these functions are ambiguous. Specify signature functions explicitly.

This works for me now (with a cast to float so fit() works). Probably after https://github.com/tensorflow/tensorflow/commit/24cc2f6d0b86674a34e831357eb60d70d54190e7
Thanks for the report.