use cloud annotaion in electron

hello
please make object detection tutorial for
electron framework
is it possible use model annotation with electron ??

@bourdakos1
i install it
but i dont know how use it
 "@cloud-annotations/models": "^0.1.1",         "wcjs-player": "^6.0.0",         "wcjs-prebuilt": "^3.0.0"

There’s instructions on how to use the sdk here: https://github.com/cloud-annotations/javascript-sdk

Hello @bourdakos1
i read javascript-sdk
and work like below but i can't load model
and get error
istart simple electron app and
my step is here
1- i import model_web folder in my project
2- make a js file , test2.js
3- save this data on it ,https://cdn.jsdelivr.net/npm/@cloud-annotations/models
see image in link
https://pasteboard.co/J9GQkNv.png
and i  call my model with this code (image uploaded below)
https://pasteboard.co/J9GRjb5.png
and i get this error (image uploaded below)
https://pasteboard.co/J9GSM2Q.png
please help,

Hmm, my guess is that it’s having issues locating the model folder

@bourdakos1
i work more but
get this two error.
1-
https://pasteboard.co/J9HuM5y.png
2-
and another error that say
models is not define
but i have refrenced this  js script
At the Top locally
https://cdn.jsdelivr.net/npm/@cloud-annotations/models
error image >>
https://pasteboard.co/J9HvKg2.png

hmm sorry, I'm not sure I can help

ok man
if it is possible
make electron object detection tutorial in future .
thank you .

hello @bourdakos1
is it possible use my web_model
with tensorflowjs ???
for object detection .
is there demo or tutorial ?
in this link
https://github.com/cloud-annotations/javascript-sdk
you used
import models from '@cloud-annotations/models'
not tensorflow js

https://github.com/cloud-annotations/javascript-sdk uses tensorflowjs

@bourdakos1
Hello again how run this project ??
https://github.com/cloud-annotations/javascript-sdk
i go to its directory   C:\Users\mas\Desktop\models\nodejs\javascript-sdk-master
and run   npm install
next
npm start but  get this error
npm ERR! missing script: start
how i test it ???

It’s a library so you can’t really run it by itself. You can run the tests though
npm run test

@bourdakos1
i test npm run test   in main directory
and get this error
https://pasteboard.co/Jbbpjmy.png
https://pasteboard.co/JbbsNTp.png

btest not test

@bourdakos1
how improve speed and accuracy for object detection when i use javascript sdk  ???

Not much you can do to improve speed aside from trying to find a lighter model. Accuracy wise, you just need more training data

@bourdakos1
can you explain how decrease speed for detection ????
What do you mean by lighter model?

Instead of using ssd mobile for your model, you could find a model that is faster. That discussion is outside the scope of this issue though and there's not much I can do to help you


assertion "block < lfs->cfg->block_count" failed

I'm running LittleFS on a 16mbyte SPI flash on ESP32 and it's been working well, but last night I ran into the above assert. Here's the stack trace:
assertion "block < lfs->cfg->block_count" failed: file "/Users/jason/Projects/x/x-esp32-firmware/components/littlefs/littlefs/lfs.c", line 27, function: lfs_cache_read
abort() was called at PC 0x400e801b on core 0
0x400e801b: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)

Backtrace: 0x40094614:0x3fff2950 0x4009480f:0x3fff2970 0x400e801b:0x3fff2990 0x401703f9:0x3fff29c0 0x40170daa:0x3fff29f0 0x40171472:0x3fff2a40 0x400dbb19:0x3fff2ac0 0x400dabe4:0x3fff2af0 0x401381ad:0x3fff2b70 0x400d99dd:0x3fff2b90 0x400d9a35:0x3fff2bc0
0x40094614: invoke_abort at /Users/jason/esp/esp-idf/components/esp32/./panic.c:648

0x4009480f: abort at /Users/jason/esp/esp-idf/components/esp32/./panic.c:648

0x400e801b: __assert_func at /home/jeroen/esp8266/esp32/newlib_xtensa-2.2.0-bin/newlib_xtensa-2.2.0/xtensa-esp32-elf/newlib/libc/stdlib/../../../.././newlib/libc/stdlib/assert.c:63 (discriminator 8)

0x401703f9: lfs_cache_read at /Users/jason/Projects/x/x-esp32-firmware/components/littlefs/littlefs/lfs.c:1069

0x40170daa: lfs_ctz_traverse at /Users/jason/Projects/x/x-esp32-firmware/components/littlefs/littlefs/lfs.c:1069

0x40171472: lfs_traverse at /Users/jason/Projects/x/x-esp32-firmware/components/littlefs/littlefs/lfs.c:1069

0x400dbb19: x_fs_get_usage at /Users/jason/Projects/x/x-esp32-firmware/main/./x_fs_littlefs.c:178

Note that I have changed the names of some symbols and files for privacy purposes.
This is happening when I try to use lfs_traverse to get filesystem information. Here's the code I use for that:
static int lfs_traverse_count(void *p, lfs_block_t b) {
    *(lfs_size_t *)p += 1;
    return 0;
}

esp_err_t x_fs_get_usage(
		uint64_t* bytes_total,
		uint64_t* bytes_free,
		uint64_t* bytes_used) {

	lfs_size_t in_use = 0;
	int err = lfs_traverse(&lfs, lfs_traverse_count, &in_use);
	if (err) {
		return err;
	}

	*bytes_total = cfg.block_count * cfg.block_size;
	*bytes_used = cfg.block_size * in_use;
	*bytes_free = *bytes_total - *bytes_used;

	return ESP_OK;
}

Before this happened, I saw two instances of logging of bad blocks:
lfs debug:1229: Bad block at 3252
lfs debug:1229: Bad block at 3253
lfs debug:1229: Bad block at 3254
lfs debug:1229: Bad block at 3255
lfs debug:1229: Bad block at 3256

lfs debug:1229: Bad block at 436
lfs debug:1229: Bad block at 437
lfs debug:1229: Bad block at 438
lfs debug:1229: Bad block at 439
lfs debug:1229: Bad block at 440

I have since written a simple block checker and run it against the flash, and found no bad blocks. Here's that code:
	size_t s_size = 4096;
	uint8_t* buffer_work = malloc(s_size);
	uint8_t* buffer_compare = malloc(s_size);
	for (int i = 0; i < (16 * 1024 * 1024) / s_size; i++) {
		// erase block, read it, check all values are 0xff
		memset(buffer_compare, 0xff, s_size);
		memset(buffer_work, 0x00, s_size);
		x_hal_bulk_storage_erase(i * s_size, s_size);
		x_hal_bulk_storage_read(i * s_size, s_size, buffer_work);
		if (memcmp(buffer_compare, buffer_work, s_size) != 0) {
			printf("%08x: erase failed\n", i);
			continue;
		}

		// write bit pattern, read it, compare
		memset(buffer_work, 0b10101010, s_size);
		x_hal_bulk_storage_write(i * s_size, s_size, buffer_work);
		memset(buffer_work, 0xff, s_size);
		x_hal_bulk_storage_read(i * s_size, s_size, buffer_work);
		memset(buffer_compare, 0b10101010, s_size);
		if (memcmp(buffer_compare, buffer_work, s_size) != 0) {
			printf("%08x: bit pattern 1 failed\n", i);
			continue;
		}

		// write second bit pattern, read it, compare
		memset(buffer_work, 0b01010101, s_size);
		x_hal_bulk_storage_write(i * s_size, s_size, buffer_work);
		memset(buffer_work, 0xff, s_size);
		x_hal_bulk_storage_read(i * s_size, s_size, buffer_work);
		memset(buffer_compare, 0x00, s_size);
		if (memcmp(buffer_compare, buffer_work, s_size) != 0) {
			printf("%08x: bit pattern 2 failed\n", i);
			continue;
		}
	}

Aside from not being able to call lfs_traverse, everything else seemed to be working fine. I was able to read and write files, and list directories, but any call to lfs_traverse caused the above assert, even after a reboot.
Please let me know if there's any other information I can provide that will help with this. Happy to help in any way I can.
Thanks,
Jason

Hi Jason,
I am using littlefs for several weeks now and I saw this issue also 2 times, when the Flash is close to be totally full.

Hi @guillaumerems, thank you for your response. In my case the flash was almost empty. About 200kbyte stored out of 16mbyte available.

Hi @vonnieda, thanks for raising an issue.
Quick questions:
What hash of LittleFS are you using?
What configuration are you using? (read_size, prog_size, block_size (4KiB?), lookahead)
What compiler are you using? (It looks like ESP32 is a rather unique architecture, may be worthwhile to run tests on this guy, do you know of a qemu port?)
Actually this sounds like another issue I ran into. LittleFS wasn't tracking blocks correctly and would accidentally allocate a block that was already in use. The block could then be modified by two different filesystem mechanisms, making LittleFS think a write failed and the block had gone bad.
This was the fix: https://github.com/geky/littlefs/commit/e611cf5050fc44acb97057654b6885ec9b060915
If you do a git log and your hash is after that commit, we may have a different problem.
Unfortunately, at this point the filesystem is probably corrupted with pointers going the wrong places, so you'll need to reformat before a traversal will work again. I haven't put together a proper fsck program, so if you need the data on disk you may have to piece together the filesystem by hand. I can give you some pointers on this if you need them.

@guillaumerems, is this related to https://github.com/geky/littlefs/issues/12? The bug e611cf5 is more likely when there are fewer free blocks, so it sounds like it might be the source of your issue as well. Sorry I hadn't thought about if your issue was related. Were your able to reproduce https://github.com/geky/littlefs/issues/12 easily?

Hi @geky, thank you for your response!
Answers:
Hash: b2124a5ae54717737f6d96cb24e6f31e02158d1e
Config:
static struct lfs_config cfg = {
    // block device operations
    .read  = x_read,
    .prog  = x_prog,
    .erase = x_erase,
    .sync  = x_sync,

    // block device configuration
    .lookahead = 256,
    .block_size = 4096,
    .block_count = 4096,
    .prog_size = 256,
    .read_size = 256;
};

Compiler: xtensa-esp32-elf-osx-1.22.0-80-g6c4433a-5.2.0.tar.gz via https://esp-idf.readthedocs.io/en/latest/get-started/macos-setup.html
I am not familiar with qemu, unfortunately. I did find this: https://github.com/Ebiroll/qemu_esp32
In running the block check code I mentioned above I've erased the data, which is no problem. It's all test data at the moment. Next time this happens I will attempt to capture an image of the filesystem.
It does look like maybe it's starting to happen again, on this fresh format. I just saw lfs debug:1385: Bad block at 785 and I appear to have a reboot from earlier with:
assertion "entry.d.type == LFS_TYPE_REG" failed: file "/Users/jason/Projects/x/x-esp32-firmware/components/littlefs/littlefs/lfs.c", line 1526, function: lfs_file_sync

One odd thing is that I've been running LittleFS on this same system for over a week now and these problems have just popped up over the past day.

A few more notes that might help:

The system is basically a data logger.
The system writes about 30-40 bytes per minute by appending to files.
A do quite a few directory scans of the root directory, but do not create any other directories.
I create new files, and append to existing files. I do linear reads and append writes.
When it failed, the root directory had about 20 files in it.

Just noticed one more thing, not sure if it's related or not. LFS seems to be doing a lot of erases of just two pages. I added logging of the erase call and here's an excerpt:
I (11602) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 2)
I (16642) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 10)
I (16682) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 3)
I (21672) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 11)
I (21712) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 2)
I (26722) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 12)
I (26762) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 3)
I (31742) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 13)
I (31802) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 2)
I (36792) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 14)
I (36832) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 3)
I (41822) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 15)
I (41862) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 2)
I (46852) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 16)
I (46912) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 3)
I (51872) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 17)
I (51922) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 2)
I (56922) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 18)
I (56962) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 3)
I (61942) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 19)
I (61992) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 2)
I (66992) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 20)
I (67032) FB_FS_LITT (0000) bs_erase(0x3ffc1498, 3)

Note that block 2 and 3 are being erased over and over. My system appends to a file every 5 seconds, and it appears it's erasing one of those two blocks for every write to this file. So, each block is being erased every 10 seconds. At that rate I'll surpass 100k writes on those blocks in just  12 days.

That's a good thing to notice! But it is intentional. LittleFS's strategy is to recover from blocks when they go bad, as an alternative to wearing the blocks evenly. I put together a little simulator to show how this still extends the life of flash devices. You can also play around with the configuration to see how different write behaviors may impact the filesystem:
http://littlefs.geky.net/demo.html

The bug is interesting. Did LittleFS get remounted during the time or was this a week of continuous operation?
I have seen flash blocks go bad, but only fail to write intermittently. But I'd be surprised if a whole row of incremental blocks failed at once, like in your first log. Also from your setup I would expect block 2 or 3 to be the first to go.
There has been one fix since your hash of LittleFS: https://github.com/geky/littlefs/commit/9ee112a7cbdbf15a6aee931527f87f587ca523e5 (related pr https://github.com/geky/littlefs/issues/33)
But that issue only occurs when needing to extend a directory. With only 20 files in your root you should be fine (unless your filenames are ~192 characters long).
I'll try that qemu fork and see if I can get the test cases running on the ESP32 architecture. Unfortunately it may take me a few days before I can really sit down and debug this. Though thanks for all the info.
It's a long shot, but there have been a couple issues with compiler intrinsics. It'll be hard to know if this is the issue without a repeatable test, but passing -DLFS_NO_INTRINSICS may help reduce what could be the issue.

Thanks @geky.
Lots of remounts, at least 10 per day.
I think I confirmed that there aren't "really" any bad blocks with my block test code up above. For each block it:

erase the block
read the block and confirm all bytes are 0xff
write 0b10101010 to each byte
write 0b01010101 to each byte
read the block and confirm all bytes are 0x00

Let me know if you think this test is not sufficient.
I will merge the fix you mentioned, and will try -DLFS_NO_INTRINSICS.
In the meantime, I'll do some testing of my own and see if I can find a way to easily reproduce this.
Thanks for all your help!

On case I've seen of flash exhaustion was on the internal flash of an MCU after being reprogrammed a large number of times (LittleFS wasn't involved): Roughly 1 out of 10ish erases would fail to push all the bits to 0xff.
You could try running your block test ~100 times to make sure there's no blocks that fail intermittently. Although this will add to the wear on your block device, so choose a number of tries you're comfortable with.

Sidenote: Some quick math using your use case, correct me if I make a mistake:
1 file update = 2 erases (file data and metadata pair)
1 file update every 5 seconds = 1 erase every 2.5 seconds
100K erases cycles per block, for 4K blocks (16MiB / 4KiB) = 400M erases.
400M * 2.5 = 1G seconds = 31.7 years.
So, very roughly, you can expect your flash to last about 30 years with LittleFS and your use case.
Note, this doesn't take into account static files or manufacturing defects, so it's just a maximum estimate more than anything. But it should give you a ballpark of what to expect (at least when everything's working correctly).

Hi @geky, I agree with your math - although one caveat is that the capacity will go down over that time, whereas with universal wear leveling the capacity could be expected to stay the same until everything all failed around the same time. Anyway, I agree, it's not something I need to be concerned with. I didn't really understand the wear leveling scheme you were using and now I do.
I've added code to my write and erase functions to verify the operation afterwards with a read and compare. So, next time I see a "bad block" from LFS I hope this will tell me if I really did have a write failure, or if something else is happening.
Will report back as soon as I have something.
Also, as an aside, I tried destroying a block to see how many erase/writes it could handle, and I got up to  337k erase/writes before I had to stop the test and do something else. No failures so far. I'll continue the test tonight.

@geky I just had a thought that maybe explains this issue: Would a previously formatted, and used LFS volume, which is then reformatted but not fully erased, potentially cause this issue?
Here's the situation:

Flash starts erased from factory.
LittleFS formats, writing just a few blocks.
I use LFS for a while, creating some files, allocating blocks, etc.
I corrupt the superblock while doing some other tests.
I attempt to remount, it fails, so I format. I note this only erases and writes a few blocks, not the whole flash.
LFS starts allocating blocks and runs across a block that "looks" right, but it's actually from a previous format of the FS?

This might explain why I am seeing this error on my development board, which I reformat regularly, but not on other boards that are just in general use.
So, I guess the question comes down to: Do I need to do a chip erase before formatting to ensure the state of the FS?

Oh! The other tests you run, do they erase block 0? What about block 1? The first two erase blocks form the superblock, unfortunately erasing only one can cause problems.
There's a reoccuring issue I've seen where users try to switch between two filesystems on a single piece of storage. If block 0 is erased, LittleFS may pick up block 1, thinking that a power failure occured. Unfortunately, block 1 may contain significantly out of date data, leading to a corrupted filesystem.

So, I guess the question comes down to: Do I need to do a chip erase before formatting to ensure the state of the FS?

No. LittleFS makes no assumption about the state of memory after a format.
But! If your code tries to mount first (which, to be fair, is suggested for handling new flash), and there is a corrupted filesystem. LittleFS may not reformat, mount successfully, but fail later.
So at the moment you do need a full erase (or at least erase the first 2 blocks) after running tests or using another filesystem.
I do have an idea on how to improve this (by checksumming the sum of revision counts on the filesystem). But this would come with a code and runtime cost.

@geky I'm not sure if I've erased the first two blocks in all cases. I was doing quite a bit of stuff, including trying different filesystems, with this particular flash. It's quite possible this came up after I had experimented with just erasing the first block. I've now done a full chip erase on this board and will see if it comes up again.

I'm now experiencing this on multiple devices that have had their flash fully erased before formatting, so I think that rules out my previous guess.
Unfortunately I have not seen my write verify code trigger yet, so I don't think I have any bad blocks. I also think it's unlikely that there are bad blocks as these flash chips are all less than two weeks old and have barely been written to at all. I fear there may be some kind of compiler or platform incompatibility.
@geky Is there any information I can provide, or tests I can run, to help figure this out? I really want to use LittleFS as it's hundreds of times faster than SPIFFS, which I was previously using, but this is starting to become a showstopper :(
I do have a corrupt filesystem now, so if it would help for me to post an image of that, I can.

That was a good idea to add the verify function. Sorry you're running into so many problems.
A disk image could help quite a bit! If you don't want to post it publically you can email it to me at christopher dot haster at arm dot com, or the email in my git commits.

@geky Thanks for the response. I've emailed the file to the email you mentioned above.

Thanks to a ton of help from @geky I've found this to be a problem in my code. I was calling lfs_traverse without a mutex, while all other lfs_ calls were protected by a mutex. @geky explained that LFS uses a single directory read cache, which was likely getting corrupted by simultaneous reads.
I confirmed the issue by running lfs_traverse in a tight loop on another thread, which corrupted the filesystem in 8 seconds. I then added locking and was not able to reproduce the error.
So, @guillaumerems, make sure you have a mutex around all LFS calls!
I'm going to monitor my device for a few days to make sure this doesn't happen again, and then will close this issue.
Thank you to @geky for all his help, and for such a great filesystem!

I've seen no further instances of corruption on this, so calling it good. Thanks for all the help!


Fail to build project following README

Summary
Failed to build project while follow the master branch readme
Version
latest master
Additional context
I follow the readme:
$ git clone https://github.com/{your-personal-repo}/tui.editor.git
$ npm install
$ cd apps/editor
$ npm install

But when i run
npm run serve
i have the following error:

    ERROR in ./src/js/convertor.js
    Module not found: Error: Can't resolve '@toast-ui/to-mark' in '/xxxx/tui.editor/apps/editor/src/js'
     @ ./src/js/convertor.js 5:0-39 164:19-25
     @ ./src/js/editor.js
     @ ./src/js/index.js

    ERROR in ./src/js/toMarkRenderer.js
    Module not found: Error: Can't resolve '@toast-ui/to-mark' in '/xxxx/tui.editor/apps/editor/src/js'
     @ ./src/js/toMarkRenderer.js 1:0-39 42:15-21 42:39-45
     @ ./src/js/editor.js
     @ ./src/js/index.js

    ERROR in ./src/js/editor.js
    Module not found: Error: Can't resolve '@toast-ui/toastmark' in '/xxxx/tui.editor/apps/editor/src/js'
     @ ./src/js/editor.js 75:0-48 182:25-34
     @ ./src/js/index.js

    ERROR in ./src/js/markdownToHTML.js
    Module not found: Error: Can't resolve '@toast-ui/toastmark' in '/xxxx/tui.editor/apps/editor/src/js'
     @ ./src/js/markdownToHTML.js 1:0-63 6:19-25 10:19-35
     @ ./src/js/editor.js
     @ ./src/js/index.js

    ERROR in ./src/js/mdPreview.js
    Module not found: Error: Can't resolve '@toast-ui/toastmark' in '/xxxx/tui.editor/apps/editor/src/js'
     @ ./src/js/mdPreview.js 11:0-55 40:23-39
     @ ./src/js/editor.js
     @ ./src/js/index.js

    ERROR in ./src/js/convertor.js
    Module not found: Error: Can't resolve '@toast-ui/toastmark' in '/xxxx/tui.editor/apps/editor/src/js'
     @ ./src/js/convertor.js 6:0-63 36:24-30 40:22-38
     @ ./src/js/editor.js
     @ ./src/js/index.js

(xxxx is my local folder path)
Any extra step needed to build the project?

@kelvinkoko This error is because the bundle files of the libraries used in the editor are not created. So you have to install npm on each library, run the build, and build the Editor. Let me explain the process in more detail.
First, you need to go to each library folder in the Editor's root(tui.editorfolder). In the example, take toastmark as an example.
- tui.editor/
  - libs/
    - squire/ ...
    - to-mark/ ...
    - toastmark/ ...

$ cd libs/toastmark && npm install

You need to build the bundle file after installing npm. Each library has a different build script, so in this case you need to run the script in package.json at the root.
$ cd ../../ && npm run build:toastmark

This will create toastmark's build file and do the same for squire and to-mark.
I couldn't consider missing this process. This should be added to the documentation. And now I think it would be convenient to combine npm install script with the build script. I'll improve this later. 🤔
Thanks for reporting!

@seonim-ryu Got it, thank you for your detail instruction!~ I will try it.
Yes, it will be great if having a single build command :)

I too found that the instructions in README.md were not working ...

First, NPM complained that package.json (in the repo root) was invalid because it didn't have a version number...

https://github.com/nhn/tui.editor/blob/dba0438df7bb82265591fee3c317625198ee7daa/package.json#L1-L4

I added a version number (e.g. "version": "0.1.0",) and NPM was still having issues ... so I tried yarn and had some more success.

Running yarn/npm run test in the apps.editor directory resulted in an error from karma that ChromeHeadless was unavailable.

At this point, I'm not sure what's going on - but I'm thinking there are issues with the layout of the project... specifically, some things to consider:

Many of the dependencies in the project are old.... and have many vulnerabilities
Running npm audit resulted in many vulnerabilities:

libs/squire

 added 229 packages from 221 contributors and audited 229 packages in 6.542s              found 15 vulnerabilities (7 low, 4 moderate, 2 high, 2 critical)
libs/toastmark
added 1009 packages from 1510 contributors and audited 1080 packages in 30.005s          found 38363 vulnerabilities (38362 low, 1 high)
libs/to-mark
added 1419 packages from 1267 contributors and audited 1490 packages in 43.311s          found 121 vulnerabilities (56 low, 25 moderate, 37 high, 3 critical)
apps/editor
 added 4690 packages from 2607 contributors and audited 2039 packages in 148.597s         found 62 vulnerabilities (11 low, 25 moderate, 24 high, 2 critical)

Now, I have not looked at the particular vulnerabilities and their impacts (the impact may very well be zero) -- and it's highly likely that, due to the way node/npm dependencies work, the vulnerabilities are somewhere way deep in the dependency graph/tree. Still, however, it's a concern.
Also, unless I'm misreading something, the dependencies seem WAY out of date: try running an npm outdated --depth=1 in the apps/editor folder... It gets even more interesting at depth levels 2, 3, and 4.
@seonim-ryu I would suggest:

Consider setting up some form of CI (Travis/pick one.) ... This will, among other things:

Force any "hidden" dependencies out of the shadows by always starting a build and test from a 100% clean/neutral environment - e.g. there might be programs/libraries installed on your dev system that aren't in the docs (It happens - I try to avoid it, I still do it. The NPM/Yarn architecture -in theory- is supposed to help avoid that but it can still happen - especially if things get installed globally)
Give you great insight on commits - it also helps preserve the idea that the master branch should be 100% working 100% of the time. (e.g. if a proposed commit to master doesn't build/work/past tests, it doesn't break the codebase.)

I see that your most recent commit dba0438 is working on Github Workflows -- I'm not quite sure what's going on with the cron job. Check out https://github.com/actions/starter-workflows/blob/master/ci/node.js.yml for an example for a generic Node project. The major idea is that it should trigger on every push to master and every pull request to master...
Also, because you have to essentially write all the commands to set the package up, it makes writing install documentation really easy :grin:
Don't forget to test on multiple platforms ;) (certanly a few big variants of linux would be good - debian/ubuntu... etc. Node generally doesn't have cross-arch issues ... e.g. arm/aarch64/mips)

Really consider some of the dependencies and the structure... The whole NPM/Yarn ecosystem revolves around the idea of being able to download a repo, run npm/yarn install and then go... From the project root.

Double check the use of Bower in some of the dependencies - I'm 99% sure it's considered EOL.

Just some thoughts :)


Integrate with WebGPU Renderer + Release 1.0-pre6

WebGPU Integration + GIF Saver interface change
https://github.com/user-attachments/assets/23173fcb-b8db-4867-81e2-5598f12349e4
Issue: #66

@hermet done


[BUG] Cant copy/paste in the inspector

What happened?
Copying a single interface reference wont let you paste it at all.
If you have an array of interfaces, you can copy the array and paste it, but the pasted array is just full of null values.
Package Version
1.1.7
Unity Version
2021.3.27f1

ive found someone who implemented one and modified it a bit to work with copy/pasting arrays, thanks anyway :)
https://github.com/AlexeyTaranov/SerializeReferenceDropdown/tree/master


Automated cherry pick of #3457: build: show diffs made by checks

Cherry pick of #3457 on release/2.11.
#3457: build: show diffs made by checks

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.11@7ea767d). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff               @@
##             release/2.11   #3459   +/-   ##
==============================================
  Coverage                ?   7.13%
==============================================
  Files                   ?     476
  Lines                   ?   77315
  Branches                ?       0
==============================================
  Hits                    ?    5516
  Misses                  ?   71336
  Partials                ?     463

Flag
Coverage Δ

#aFlag
7.13% <ø> (?)

Continue to review full report at Codecov.

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

/lgtm

/approve

/approve


Upgrade actions/checkout v3.6.0 -> v4.1.0

This PR contains the following updates:

Package
Type
Update
Change

actions/checkout
action
major
v3.6.0 -> v4.1.0

Release Notes

actions/checkout (actions/checkout)
v4.1.0
Compare Source

Add support for partial checkout filters

v4.0.0
Compare Source

Support fetching without the --progress option
Update to node20

[ ] If you want to rebase/retry this PR, check this box

Suggested commit message:
Upgrade actions/checkout v3.6.0 -> v4.0.0

The new filter: tree:0 setting is interesting, but even the SonarCloud build with fetch-depth: 0 clones the repository in ~1.2 seconds, so there's not much to gain here at the moment. (This does look like a nice suggestion though; consider giving that a thumbs-up.)


Add AWS and boto3 configuration checking

Add functionality to validate the existence of AWS resources, like S3 buckets, or values from the SSM parameter store.

Make installation of AWS optional, since botocore is quite large (11MB)

Implement VCR for examples test

Add documentation on the AWS S3 class


Should self.name refer to self._name?

https://github.com/Ouranosinc/raven/blob/f04c32fb0ef2044c4c2d3f019a1e000a6294f7a8/raven/models/basic.py#L109
@julemai Reading over and linting the model code a bit. Wondering if this variable should actually be the intitialized self._name.

@Zeitsperre I haven't coded that but from looking at it, I think it's correctly used as is.
I think that you want to use the property setter self.name function to set the property self._name. The setter function is double-checking if the property was already set and will stop if it was already set and not matching the new value. While if self._name would be used directly this check wouldn't take place.
But as I said I didn't implement this and @huard is probably the better person to ask.


[tele5] Fix extractor

Before submitting a pull request make sure you have:

[x] At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense

What is the purpose of your pull request?

[x] Bug fix

Description of your pull request and other information
The API returns a list of videos if a 'bumper' (an ad) is supposed to be played before the video. The extractor will now select the video with the originally requested ID. This PR should fix #22666.

Thank you for your time and effort, Tele5 changed yet again, your version and the previously latest youtube-dl version now both produce a http-403 error.
This affects every video availabe on Tele5.de, even the Trailers.

I successfully used this fixed version to get https://www.tele5.de/digimon/ganze-folge/calumon-wird-befreit/ which did not work with 2019.09.28.
https://www.tele5.de/star-trek/enterprise/ganze-folge/freund-oder-feind/ also worked for me with this fix but not with 2019.09.28.
Interestingly enough I never encountered a 403 in case of star trek I encountered a 500 and with digimon I encountered a python exception.

Intresting I keep getting 403 errors for all videos on the tele5 website with FliegendeWurst's version.
With 2019.09.28 i get 403s for StarTrek and other Series and Trailers but for Digimon i now get the original "TypeError: list indices must be integers, not str" i originally reported at: https://github.com/ytdl-org/youtube-dl/issues/22666

Tele5 now uses JW Player and a partial (?) fix is already done in master.


Community Call Updates

The Accessibility Working Group will be invited to share 5-minute updates during TTW community calls.
The first call is February 15 from 15:00-16:30 UTC.
@aleesteele  described the call this way in her invitation email

This year, our community calls will serve as a platform for the community to come together, share accomplishments, and discuss governance-related matters. Moving forward, these public meetings will replace last year's Core Team meetings, enabling broader participation from our community.

Requests

Please use this issue to add your updates
Does anyone want to give the update? I could do it but would like someone else to have the opportunity
@aleesteele  are slides expected?

Hi @LizHareDogs - going to close this for now 😄 - doing some github gardening, and will make sure to log our presentation slides from each community call in this repository. What do you think?


Example project maps are blank

Bug report
Summary
All of the maps in the examples project are blank, despite having followed the Examples Setup very thoroughly 😉. It doesn't work either after following the installation instructions again and filling in the missing??? lines in AndroidManifest.xml and build.gradle.
I also replaced the API key with my personal one.
Environment info
OS: Windows 11
Target Platform: Android Virtual Device, Android 10 (Q), API 29
react-native info output:
 react-native: 0.65.1
 react: 17.0.2
 react-native-maps: 0.29.4

Steps to reproduce

clone repo
cd example
npm install
npx react-native run-android

Describe what you expected to happen:

Maps are not blank

Describe what you actually happens:

Maps are blank

Most maps are blank

Polygon creator is grey

Animating with MapViews is broken

Cached Map has a ListView

Image Overlay Component with Assets has a weird error

That's enough for today.

Same here on Android. iOS is working fine

In almost all cases the issue with a blank map rendering on Android is related to the API key. Please take a look at some of the other related issues that have been opened in the past. https://github.com/react-native-maps/react-native-maps/search?q=blank+map&type=issues

@christopherdro So does the example project work for you? If so, where did you insert your API key?

I have the same problem with my live app. The maps are working fine on Expo Go and on iOS phones, however, on Android phones (the playstore app, works fine on Expo Go) the map is returned blank.
I double checked the API-key, and I even replaced it with a new one and pushed through playstore again, without any result.
I have tried reverting to older published releases, none of them work either now. Anyone knows whats up?

I have the same problem with my live app. The maps are working fine on Expo Go and on iOS phones, however, on Android phones (the playstore app, works fine on Expo Go) the map is returned blank.
I double checked the API-key, and I even replaced it with a new one and pushed through playstore again, without any result.
I have tried reverting to older published releases, none of them work either now. Anyone knows whats up?

Can you log the errors? Or do you see any errors in the log?

Please make sure that Maps SDK for Android is enabled.

I am currently working on my diploma project and am already using the MapView Component there and everything is working fine. Just the example project is completely bugged. So did you just clone the repo and start it and eveything worked fine?

I haven’t ran through all the examples but I wouldn’t be surprised if there are various bugs since the example app isn’t updated often. Pull requests are welcome.

Please make sure that Maps SDK for Android is enabled.

Yep, this was the issue. Thank you.
I find it strange that it worked for several months before, but oh well, at least it is working now.


Adds tests for negated content and absent keyword

Ticket
Redmine ticket: https://redmine.openinfosecfoundation.org/issues/2224
#1942 with more tests

engine analysis test
checks with absent keyword and positive content

Having the engine-analysis test is nice, thanks! :)

Merged in #2150, thanks!


fix: fix op cli always generating passwords

When invoking the op cli, if the onepassword item had no password recipe, generate-password would always be appended to the cli args and any password value would be overwritten by a generated password.
Note I am very new to Go so please point me in the right direction if needed :)
As part of this fix I have extracted the logic which constructs the generate-password cli arg into a function in utils, and implemented a test around it.
Fixes #128

@edif2008 thanks for the review :) I've updated the PR description and applied your suggestion.


StormPlatform laws are flakey

[error] x StormPlatform matches Scala for single step jobs
[error]  the value is false (StormLaws.scala:132)
Usually passes. Sometimes it doesn't. May be a race condition, may be a real bug.

+1

at least getting a clearer error report would help. :/

I think it may help to use a more modern storm.
@pankajroark any news on getting heron to use the modern storm namespaces so we can use storm 1.0 or so and see if we can fix our issues?


App crashes when sent to Background (onPause)

Description
After following this tutorial to load a React Native bundle inside a Native Application, the app crashes every time the app is sent to Background (onPause()).
To give more context, our MainActivity starts the ReactNativeActivity which is starting a bundle of a react native application. When the app is in the foreground both activities are working as expected, except when the app is sent to background.
Steps to reproduce

Create a native project.
Follow the steps in this documentation to load a React Native bundle.
Start the React Native Activity through the Main Activity.
Open the app.
Send the app to the background.
Check the logs on Android Studio.
A crash on ReactInstanceManager.onHostPause will appear

React Native Version
0.73.8
Affected Platforms
Runtime - Android
Output of npx react-native info
System:
  OS: macOS 14.6.1
  CPU: (12) arm64 Apple M3 Pro
  Memory: 317.23 MB / 36.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.17.0
    path: /opt/homebrew/opt/node@20/bin/node
  Yarn:
    version: 3.2.1
    path: /opt/homebrew/bin/yarn
  npm:
    version: 10.8.2
    path: /opt/homebrew/opt/node@20/bin/npm
  Watchman:
    version: 2<IP_ADDRESS>
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /Users/oliveirac/.gem/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.0
      - iOS 17.0
      - macOS 14.0
      - tvOS 17.0
      - watchOS 10.0
  Android SDK:
    API Levels:
      - "23"
      - "26"
      - "27"
      - "28"
      - "29"
      - "30"
      - "31"
      - "32"
      - "33"
      - "34"
    Build Tools:
      - 30.0.3
      - 31.0.0
      - 33.0.0
      - 33.0.1
      - 34.0.0
    System Images:
      - android-30 | Google Play ARM 64 v8a
      - android-33 | Google Play ARM 64 v8a
      - android-34 | Google APIs ARM 64 v8a
      - android-34 | Google Play ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2023.1 AI-231.9392.1.2311.11255304
  Xcode:
    version: 15.0.1/15A507
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.11
    path: /usr/bin/javac
  Ruby:
    version: 2.7.4
    path: /Users/oliveirac/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.8
    wanted: 0.73.8
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

Stacktrace or Logs
java.lang.AssertionError
  at com.facebook.infer.annotation.Assertions.assertCondition(Assertions.java:82)
  at com.facebook.react.ReactInstanceManager.onHostPause(ReactInstanceManager.java:581)
  at com.facebook.react.ReactDelegate.onHostPause(ReactDelegate.java:107)
  at com.facebook.react.ReactActivityDelegate.onPause(ReactActivityDelegate.java:128)
  at com.facebook.react.ReactActivity.onPause(ReactActivity.java:52)
  at com.skybet.app.skybet.ui.ReactNativeActivity.onPause(ReactNativeActivity.kt:54)
  at android.app.Activity.performPause(Activity.java:8168)
  at android.app.Instrumentation.callActivityOnPause(Instrumentation.java:1510)
  at android.app.ActivityThread.performPauseActivityIfNeeded(ActivityThread.java:4735)
  at android.app.ActivityThread.performPauseActivity(ActivityThread.java:4696)
  at android.app.ActivityThread.handlePauseActivity(ActivityThread.java:4647)
  at android.app.servertransaction.PauseActivityItem.execute(PauseActivityItem.java:46)
  at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176)
  at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2066)
  at android.os.Handler.dispatchMessage(Handler.java:106)
  at android.os.Looper.loop(Looper.java:223)
  at android.app.ActivityThread.main(ActivityThread.java:7656)
  at java.lang.reflect.Method.invoke(Native Method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

Reproducer
can't use this
Screenshots and Videos
No response

After following this tutorial to load a React Native bundle inside a Native Application

That tutorial is sadly out of date.
I've rewrote it from scratch last week, you can find it here: https://reactnative.dev/docs/next/integration-with-existing-apps
Please follow the new instructions and report back if you still have issues.


Changed CloudWatch group name

what

CloudWatch log group name is changed

why

AWS Lambda stores it's logs only in CloudWatch log groups with prefix /aws/lambda/{function_name}
You can not override this path via terraform
Currently this module creates a new log group and it doesn't respect the pattern above

Thanks @salemgolemugoo for implementing this. Was wondering about  loggroups being created and not used as well.
At least a flag to disable its creation would be great to have, but it hope this PR will get merged 👍


[Feature] Make navbar sticky

Description
Making the navbar sticky will help users to navigate to other sections easily. Currently, if the user scrolls, the navbar disappears which doesn't provide a good user experience. Can I work on this issue under GSSOC'23?
Screenshots
No response
Additional Information
No response

Looks relevant to me go for it @suryanshsoni120 :rocket:


🏗 build: upgrade http4s to 1.0.0-M41

Closes https://github.com/jbwheatley/pact4s/pull/586. Backport of https://github.com/jbwheatley/pact4s/pull/595

Starting from 1.0.0-M31, support for Scala 2.12 is dropped.


Adds a small api, along with api documentation.

"skate"
when I removed the .git/ dir from slate it wasn't enough to make the gamecenter repo recognize it as something that wasn't a submodule, so I just renamed it

other than those small things, this looks great! Feel free to merge after you take a look at those comments


Fix parser bug where link label gets broken by ] in code span

 [before `]` after]
 ^        ^       ^
 |        |       |
(A)      (B)     (C)

When the parser encounters the ] at (C), it tries to parse a link label starting from the previous [ at (A) until it encounters the first ] at (B). This is fine, because

A link label begins with a left bracket ([) and ends with the first right bracket (]) that is not backslash-escaped.

However, due to

Code span backticks have higher precedence than any other inline constructs except HTML tags and autolinks.

the code span `]` takes precedence over the link closing.
Since a link label must not contain a ] that is not immediately preceded by a \, the above must not be parsed as a link label.
This patch fixes #642, a bug in the parser, where the range (A)...(C) was previously parsed as a shortcut link with the label (A)...(B) if the text between (A) and (B) [here: before `] is a valid link reference. We do this by simply comparing the found end (B) and supposed end (C) to ensure that the link label closed by (C) actually ends at (C).

As a bonus I've included a #[derive(Debug)] that helped me debug this and removed an unneeded &. But I can drop the unrelated changes if you don't want them.

Looks fine, merged.

@Martin1887 would it be possible to release a 0.9.3 patch with this fix?
This bug currently causes rustdoc to crash on some inputs, see for example https://github.com/rust-lang/rust/issues/111117 and https://github.com/rust-lang/docs.rs/issues/2131. We have a new lint, rustdoc::unescaped_backticks, which is supposed to detect "broken" inline code. This happens a lot on keyboard layouts where ` is a dead key. However, the lint can only work correctly if "broken" markdown is actually parsed according to the spec.
Looking at the roadmap for 0.10, it seems like the next major release still takes some time, so I'd appreciate it if you could make a point release. I've prepared an example diff for a potential patch release here, if that helps: https://github.com/raphlinus/pulldown-cmark/compare/v0.9.2...lukas-code:pulldown-cmark:0.9.3
Alternatively, we can work around this bug on the rustdoc side, which would probably just mean disabling the lint for the time being.

I see it right. I could create a new branch from the v0.9.2 tag and then you could create a pull request to that branch from your 0.9.3 branch.
What do you think, @raphlinus?

The branch branch_0.9.3 has just been created. The pull request from your branch to this new branch can already be created and hence when Ralph sends his OK the 0.9.3 release will be instantly published.


RuntimeError: PyTorch was compiled without NumPy support

This error happened when I was running the following codes in the fonduer-tutorials/hardware.
from metal.label_model import LabelModel

gen_model = LabelModel(k=2)
%time gen_model.train_model(L_train[0], n_epochs=500, print_every=100)

The whole error message was
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<timed eval> in <module>

/opt/conda/lib/python3.7/site-packages/metal/label_model/label_model.py in train_model(self, L_train, Y_dev, deps, class_balance, log_writer, **kwargs)
    417         l2 = train_config.get("l2", 0)
    418
--> 419         self._set_class_balance(class_balance, Y_dev)
    420         self._set_constants(L_train)
    421         self._set_dependencies(deps)

/opt/conda/lib/python3.7/site-packages/metal/label_model/label_model.py in _set_class_balance(self, class_balance, Y_dev)
    359         else:
    360             self.p = (1 / self.k) * np.ones(self.k)
--> 361         self.P = torch.diag(torch.from_numpy(self.p)).float()
    362
    363     def _set_constants(self, L):

RuntimeError: PyTorch was compiled without NumPy support

I think it's hitting a pytorch's known issue, which only happens on python 3.7.
My environment is as follows:
Python 3.7.1 | packaged by conda-forge | (default, Nov 13 2018, 18:15:35)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.__version__
'1.15.4'
>>> import torch
>>> torch.__version__
'0.4.1'
>>> import metal
>>> metal.__version__
'0.3.2'
>>> import fonduer
>>> fonduer.__version__
'0.4.0'
>>>

only installed torch-0.4.1.post2 works for me and don‘t downgrading the numpy
version from 1.15.4 -> 1.15.0！！！！  I reinstall the numpy version 1.16。


findByPath: handle files clashing by path

This PR is a work in progress (not complete) to fix up a couple of bugs that were caused due to the design remote findBy* functions with local filesystem inherent behaviour for a remote that allows path duplication e.g
FindByPath(...) previously returned a single file
However
FindByPath(...) actually picked the first path presented to it because Google Drive can allow for different files to have the same relative path, with no problem but the local file system will not.
With the new behaviour, a FindByPath call should return all found files.
This kind of old behaviour causes issues like not all the clashes being listed, not fully urlifying nor opening files, not properling list-ing, stat-ing and many others.

Closing in favor of more superior PR https://github.com/odeke-em/drive/pull/528


devicetree support for compound elements

I need a devicetree property as described below (documentation detail removed):
  dpd-wakeup-sequence:
    type: compound
    required: false
    description: Specifies wakeup durations for devices without RDPD

with an example use:
dpd-wakeup-sequence = <30000 20 45000>;

The value of this is an array of three integers.  binding-template.yaml specifies that compound remains the catch-all for more complex types, but when that's used all the generated macros include deprecation markers.
The documentation separately mentions type: array (which is not a listed available type) which works.
What is the appropriate type to use for this?  What would be appropriate if the element types were heterogeneous (what compound used to mean)?
In either case the generation needs to produce the property value as an initializer sequence, rather than individual elements, so some tooling enhancement will be required.

type: array not being documented together with the other types is a (bad) oversight. Will fix tomorrow.

Maybe a length: field could be added to bindings for checking the length too, if needed.
Something like
properties:
    dpd-wakeup-sequence:
        type: array
        length: 3
        required: false

Yeah, that could be useful, as long as its absence means any number of entries is allowed.
To be clear: array is intended to replace all uses of compound, including heterogenous structures?  Or does compound still get used for that.  You can answer by making it clear in the PR that improves the documentation.

Closed by #20173.  (The answer to the last question is that array means a list of integer values only.  compound appears to be used for "not an array or a phandle-array".)


Basic Improvements to Lua's setHealthBarColors

Currently, setHealthBarColors is sufficient enough, however if you are trying to change one side of the healthbar's colors, it's not too great at that.
Currently, running the code setHealthBarColors(nil, 'FF0000') in your Lua script presents you with this.

Due to the way this function is coded, trying to change one side of the healthbar's colors with it isn't ideal.
This PR fixes that, if one argument of the function is nil/empty, it will simply use the current health bar color for the switch.
Now, running the same example mentioned above provides you with this.

Thus making changing one half of the health bar's colors much simpler.
Reopen of #12074

copied the name wrong apparently lol

What if you already put a custom color? Wouldn't it overwrite it?

Most likely

Broke


Auto-generating a changelog based on commit messages

changelog format example:
### YouTube
  * extract only necessary fomats #83 @nilsocket
  * Fix the problem of extracting 1080P format #97
### 秒拍
  * Add support #88
### 微博
  * Add support #89

maybe this can help?
#!/usr/bin/python
# Copyright 2008 Marcus D. Hanwell<EMAIL_ADDRESS># Distributed under the terms of the GNU General Public License v2 or later

import string, re, os

# Execute git log with the desired command line options.
fin = os.popen('git log --summary --stat --no-merges --date=short', 'r')
# Create a ChangeLog file in the current directory.
fout = open('ChangeLog', 'w')
fout.write("Do Not Edit!  This is a generated file.\n\tYou should edit the NEWS file instead.\n\n")

# RKO add a header to the ChangeLog

# Set up the loop variables in order to locate the blocks we want
authorFound = False
dateFound = False
messageFound = False
filesFound = False
message = ""
messageNL = False
files = ""
prevAuthorLine = ""

# The main part of the loop
for line in fin:
    # The commit line marks the start of a new commit object.
    if string.find(line, 'commit') >= 0:
        # Start all over again...
        authorFound = False
        dateFound = False
        messageFound = False
        messageNL = False
        message = ""
        filesFound = False
        files = ""
        continue
    # Match the author line and extract the part we want
    elif re.match('Author:', line) >=0:
        authorList = re.split(': ', line, 1)
        author = authorList[1]
        author = author[0:len(author)-1]
        authorFound = True
    # Match the date line
    elif re.match('Date:', line) >= 0:
        dateList = re.split(':   ', line, 1)
        date = dateList[1]
        date = date[0:len(date)-1]
        dateFound = True
    # The svn-id lines are ignored
    elif re.match('    git-svn-id:', line) >= 0:
        continue
    # The sign off line is ignored too
    elif re.search('Signed-off-by', line) >= 0:
        continue
    # Extract the actual commit message for this commit
    elif authorFound & dateFound & messageFound == False:
        # Find the commit message if we can
        if len(line) == 1:
            if messageNL:
                messageFound = True
            else:
                messageNL = True
        elif len(line) == 4:
            messageFound = True
        else:
            if len(message) == 0:
                message = message + line.strip()
            else:
                message = message + " " + line.strip()
    # If this line is hit all of the files have been stored for this commit
    elif re.search('files changed', line) >= 0:
        filesFound = True
        continue
    # Collect the files for this commit. FIXME: Still need to add +/- to files
    elif authorFound & dateFound & messageFound:
        fileList = re.split(' \| ', line, 2)
        if len(fileList) > 1:
            if len(files) > 0:
                files = files + ", " + fileList[0].strip()
            else:
                files = fileList[0].strip()
    # All of the parts of the commit have been found - write out the entry
    if authorFound & dateFound & messageFound & filesFound:
        # First the author line, only outputted if it is the first for that
        # author on this day
        authorLine = date + "  " + author
        if len(prevAuthorLine) == 0:
            fout.write(authorLine + "\n")
        elif authorLine == prevAuthorLine:
            pass
        else:
            fout.write("\n" + authorLine + "\n")

        # Assemble the actual commit message line(s) and limit the line length
        # to 80 characters.
        commitLine = "* " + files + ": " + message
        i = 0
        commit = ""
        while i < len(commitLine):
            if len(commitLine) < i + 78:
                commit = commit + "\n  " + commitLine[i:len(commitLine)]
                break
            index = commitLine.rfind(' ', i, i+78)
            if index > i:
                commit = commit + "\n  " + commitLine[i:index]
                i = index+1
            else:
                commit = commit + "\n  " + commitLine[i:78]
                i = i+79

        # Write out the commit line
        fout.write(commit + "\n")

        #Now reset all the variables ready for a new commit block.
        authorFound = False
        dateFound = False
        messageFound = False
        messageNL = False
        message = ""
        filesFound = False
        files = ""
        prevAuthorLine = authorLine

# Close the input and output lines now that we are finished.
fin.close()
fout.close()

I know, i could have create a gist but this was alot more fun :+1: :seedling:


Label usage confuse

Every time series is uniquely identified by its metric name and optional key-value pairs called labels. - so looks like I can create a counter "counter_name" with label: key1 => value1 and it will create this time series determined by couner_name + key1.
And another unique series will be created with using the same counter name but different labels: counter "counter_name" with labels: "key1 => value1, key2 => value2"
Then later it confirmed by doc:
Changing any label value, including adding or removing a label, will create a new time series.
But on another article in the same documentation we see:
Client libraries MUST NOT under any circumstances allow users to have different label names for the same metric for Gauge/Counter/Summary/Histogram or any other Collector offered by the library.
It confuses that if client add or remove label - it will create new time series (for the same metric name) - but in the same time it MUST NOT be allowed.

It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.


Run Tests with miri

Run all the suitable tests with miri. Panicking ones and possibly really expensive ones should probably be skipped. Random numbers, such as necessary for Hash Maps are now possible with -Zmiri-seed=123. Accessing time stamps doesn't work with miri either, but fortunately, we already dealt with this problem for wasm-unknown, so miri is just another platform where we mock the time stamps.

Looks like parsing from actual files doesn't work either, so I guess we skip that too. However we have one test where we encode and immediately parse a run as LSS. There we don't need a file system, so in theory it should work. But it doesn't, because the parsing uses the memchr crate internally, which uses cpuid + core::arch on x86, which isn't supported by miri. So if we want to test parsing (which we really should want), then memchr needs to cfg(miri) in the fallback implementation they have. So I guess I'll mark this as blocked in the meantime.

For the file parsing we can just include_str / include_bytes them into the tests. Then we can just parse them normally, once memchr works.

This is now unblocked. memchr 0.3.1 just got released and is miri compatible.

One problem I'm seeing is that running the tests with miri is VERY SLOW. It's so slow that this is going to cost us a lot of time on CI. Maybe we could run it periodically instead of for every PR.


Set sensible defaults for vertical_geom_spec in MAPL3g

One of the issues we found when trying to exercise cap and History3G.
It seems when making a variable spec the vertical_geom_spec had no default. This meant that apparently two variables that didn't even have a vertical dimension were being flagged as unable to connect when testing the can_connect capability since the checking routine was claiming they had different vertical_geom_specs.

I see two possibilities.   Make a default presumably (NONE ==> Surface) or require specification of vertical.
To me, "surface" does not seem default-ish, so I lean towards forcing a field to specify (with MIRROR eventually being an option).


so: undefined symbol: _Py_ZeroStruct

when i run python main.py --dataset vmrdcompv1 --frame all_in_one --net res101 --cuda
Traceback (most recent call last):
File "/home/litong/vmrd-pytorch1.0/main.py", line 22, in
from roi_data_layer.roidb import combined_roidb
File "/home/litong/vmrd-pytorch1.0/roi_data_layer/roidb.py", line 9, in
from datasets.factory import get_imdb
File "/home/litong/vmrd-pytorch1.0/datasets/factory.py", line 14, in
from datasets.pascal_voc import pascal_voc
File "/home/litong/vmrd-pytorch1.0/datasets/pascal_voc.py", line 23, in
from .imdb import imdb
File "/home/litong/vmrd-pytorch1.0/datasets/imdb.py", line 14, in
from model.utils.cython_bbox import bbox_overlaps
ImportError: /home/litong/vmrd-pytorch1.0/model/utils/cython_bbox.so: undefined symbol: _Py_ZeroStruct

@li-source
I think your python environment is inconsistent with the python that generated the so file, you should regenerate one yourself. git clone https://github.com/jwyang/faster-rcnn.pytorch .Modify the make.sh file in the lib folder to change python to the python you want to use. Then execute make.sh to generate the so file

OK，thanks. Otherwise what is your  python environment?Mine is python3.6.2

Hi,My python environment python3.7.But ,I think this code will work well in the python2 environment

Hi,My python environment python3.7.But ,I think this code will work well in the python2 environment

For pytorch1.0 version，is python2 also available?

Sorry, I mean python2.x environment

ok，thanks. I will try.

Hello, have you run through successfully the program in python2.x environment currently?

when i run python main.py --dataset vmrdcompv1 --frame all_in_one --net res101 --cuda
Traceback (most recent call last):
File "/home/litong/vmrd-pytorch1.0/main.py", line 22, in
from roi_data_layer.roidb import combined_roidb
File "/home/litong/vmrd-pytorch1.0/roi_data_layer/roidb.py", line 9, in
from datasets.factory import get_imdb
File "/home/litong/vmrd-pytorch1.0/datasets/factory.py", line 14, in
from datasets.pascal_voc import pascal_voc
File "/home/litong/vmrd-pytorch1.0/datasets/pascal_voc.py", line 23, in
from .imdb import imdb
File "/home/litong/vmrd-pytorch1.0/datasets/imdb.py", line 14, in
from model.utils.cython_bbox import bbox_overlaps
ImportError: /home/litong/vmrd-pytorch1.0/model/utils/cython_bbox.so: undefined symbol: _Py_ZeroStruct

Sorry for the delay.
You should first follow https://github.com/jwyang/faster-rcnn.pytorch to make faster RCNN work.
It would be better to use the master branch and PyTorch 0.4.1. Note that 0.4.0 and 1.x will not work for the master branch.

Hello, have you run through successfully the program in python2.x environment currently?

Sorry for the delay.
You should first follow https://github.com/jwyang/faster-rcnn.pytorch to make faster RCNN work.
It would be better to use the master branch and PyTorch 0.4.1. Note that 0.4.0 and 1.x will not work for the master branch.


Add mmperf workflow

Thank you. I've sent you an invite to push to mmperf in case you want to change anything on that side

This is ready for review. PTAL


Problems with successful injection

Why is there imgui after injection but no function option?

Repo has been updated, you can now use imgui for drawing, and for menu: be patient, in few days I will make basic one.


[Feature Request] Addition of Sliding Window and Two Pointer Patterns and Related Problems

🚀 Feature Request
Describe the solution you'd like
I would like to propose the addition of algorithms and problem sets related to the Sliding Window and Two Pointer patterns. These techniques are widely used in solving a variety of problems, particularly in array and string manipulation, as well as in optimizing solutions to problems that involve continuous subarrays, subranges, and subsequences.
Importance:

Sliding Window Pattern: This technique is incredibly efficient for problems requiring the analysis of a fixed or variable-sized subarray. It reduces the time complexity from brute-force O(n²) to O(n) in many cases, making it ideal for handling large data sets in competitive programming and real-world applications like network traffic analysis, stream processing, and more.

Two Pointer Pattern: This pattern is pivotal in problems involving sorted arrays or strings, enabling us to efficiently find pairs or triplets that satisfy a particular condition. The technique reduces the need for nested loops, improving time complexity and performance.

Would you like to work on this feature?

[x] Yes
[ ] No

@ajay-dhangar Please assign me this issue and add gssoc-extd and hacktoberfest labels!


dangerous use of the global this object when function's type was annotated

I'm trying to make the function to have this by defining it in its type.
/**
 * @type {function(this:{hello:string})}
 */
function test() {
  console.log(this.hello)
}

test.call({ hello: 'world' })

However, I get an error. Is this meant to happen despite me giving the hint as to what this is going to be ?
t/this.js:5: WARNING - dangerous use of the global this object
  console.log(this.hello)
              ^^^^

0 error(s), 1 warning(s), 100.0% typed

Basically my function must adhere to an interface but can have a custom this. When i define it like
/**
 * @this {{hello:string}}
 * @type {_functionInterface}
 */
function test() {
  console.log(this.hello)
}

I get another error because the annotations are incompatible (can't use 2 together). Just have to suppress the globalThis for now.

I believe this is what you meant to do.
/**
 * @this {{hello:string}}
 */
function test() {
  console.log(this.hello);
}

test.call({ hello: 'world' });

You don't generally want to use @type when declaring a function.
Use @this, @param, and @return as needed instead.
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler

@brad4d why cannot I not annotate the function type? As I said, I want functions to adhere to an interface. Otherwise I would have to annotate each function with the same @this, @param and @return. Also the compiler doesn't work in my case:
/**
 * @type {Rule}
 */
const rule = {
  re: /(hello) world/,
  replacement,
}

/**
 * @this {ReplacerInterface}
 * @param {string} match
 * @param {string} hello
 * @returns {string}
 */
function replacement(match, hello) {
  this.emit('match', match)
  return `the match was "${match}": ${hello}`
}

/**
 * @type {Rule}
 */
const rule2 = {
  re: /(hello) (world)/i,
  replacement: replacement2,
}

/**
 * @this {ReplacerInterface}
 * @param {string} match
 * @param {string} hello
 * @param {string} world
 * @returns {string}
 */
function replacement2(match, hello, world) {
  this.emit('match (i)', match)
  return `the match was "${match}": ${hello} ${world}`
}

/** @implements {ReplacerInterface} */
class Replacer {
  emit(i) {
    console.log('the emitted match is %s', i)
  }
}
const replacer = new Replacer()

console.log('hello world'.replace(rule.re, rule.replacement.bind(replacer)))
console.log('HELLO WORLD'.replace(rule2.re, rule2.replacement.bind(replacer)))

/**
 * @interface
 */
var ReplacerInterface = function() {}
/** @type {function(string, ...*)} */
ReplacerInterface.prototype.emit = function () {}

/**
 * @typedef {{re:!RegExp, replacement: function(this:ReplacerInterface, ...string): string}}
 */
var Rule

Created internal issue http://b/131248506

OK, I see the issue now.
The problem code is here.
https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/CheckGlobalThis.java#L95
It's only looking at the JSDoc on the function specifically for an @this annotation (among other things),
so it misses the @type case. The pass runs as part of the "suspiciousCode" pass which goes after type checking, so it could definitely us the JSType on the node, when it exists for a more robust check.
To fix this bug for the case where type checking is disabled, it will be necessary to add logic that looks for an @type annotation, parses it, then looks inside it for a defined type for this. Since that will work with or without type checking enabled, that's probably the way to go.
I can't give fixing this a high priority relative to other things, because it represents a rather unusual use-case, but this would be a good first-fix for someone, so I've marked it "Help wanted".
By "unusual use case" I mean that this is a problem when you want to define "loose" functions that expect to be called with a this supplied. That's not a code pattern we want to encourage.
Why not just define the function to take the ReplacerInterface object as its first argument?

@brad4d , Thank you, to answer your question I don't want to pass ReplacerInterface as the first argument because not all replacers will need to access it. I have a library that binds all replacement rules to a constructor, so that typically if functions want to access this they will have a set of APIs from the interface, but they might choose to extend the interface to add other methods. I admit I could add it as the first argument it's true I just feel like I can put meta APIs in this and "pure" arguments can come directly as args if that makes sense. I see what you mean by this type of programming, using this as another argument, but sometimes it syntactically sugars up programming, e.g.,
function plain (interface, match, group) {
  // no access to the interface is needed
  return group
}
function access (interface, match, group, position) {
  this.emit(match, position)
  return group
}
function access (interface, match, group, position, string) {
  this.extendedAPI(parse(match, string, position))
  return match
}

@zavr-1, I have other suggestions to make for your case, but I don't want to make them here, since that discussion is likely to drown out the information about the issue being tracked here.
If you'd like to discuss it further, you could post your design problem as a question on
https://groups.google.com/forum/#!forum/closure-compiler-discuss


Code with SAPUI5

When I try to run my application as web application, the FLP opens with the first tile being the "Inventory Dashboard". When I click on it, I get an error "Request failed":
Request failed
{
"requestUri": "/here/goes/your/serviceUrl/local/$metadata?sap-language=DE",
"statusCode": 404,
"statusText": "Not Found",
"headers": [],
"body": "HTTP Status 404 - Not Found"
}

Please note that you need to run the application with the testFLPServiceMockServer.html file as the set-up has changed. If you run the testFLPService.html, you will see this issue.


Reduce the precision of numbers in path strings?

Hi,
while I'm aware that numbers in
M0.123456,0.123456L1.123456,1.123456L1.123456,0.123456Z
are used internally by the browser to calculate shapes, it seems weird to me the we really need 1e-6 pixel precision. I'm wondering if reducing numbers precision in path strings can enhance DOM performances because of shorter d strings to be parsed.
This function:
(pathString, precision) => pathString.replace(/\d+\.\d+/g, s => parseFloat(s).toFixed(precision))

works well, but parsing the path string seems a waste of CPU cycles: maybe it'd be better passing a precision option to path.toString() and process all floats with f => f.toFixed(precision) before creating the output string.
In that case it would be nice to have d3.geoPath.precision([digits]) too.
What do you think about it?
Thanks!

I doubt this would be a performance improvement, but it is nice if you want to generate smaller strings (for example if you are serializing to GeoJSON or SVG); see d3.geoQuantize for example.
I’d probably implement this by having a different implementation of Path that calls number.toFixed rather than relying on the default string-coercion of numbers. Three potential strategies:

Duplicate the implementation entirely. Have one that calls number.toFixed and another that uses string-coercion. (Note that the implementation that calls number.toFixed should still coerce to a number before calling number.toFixed.)

Have a shared implementation that calls a private method to convert an input number x to a string. The default implementation would be return x + "", while the fixed-precision version would be return x.toFixed(this._precision). This adds a bit of overhead to the default implementation since there’s now an additional function call per number, though.

Have a wrapper implementation that coerces each input value to a number, calls number.toFixed to round the number, and then calls through to an underlying Path instance (which is the same as the current implementation). This has no overhead in the default case, but in the case where you want fixed precision, it requires two additional coercions (from the result of number.toFixed back to a number and then back to a string again).

What about using arrays to store this._ and process it in .toString()?
A tentative version would be:
function Path() {
  //...
  this._ = []  // instead of this._ = "";
}

then instead of
moveTo: function(x, y) {
  this._ += "M" + (this._x0 = this._x1 = +x) + "," + (this._y0 = this._y1 = +y);
},

use

If you like this approach, in order to reduce calculations when we call toString we might reset the list of commands (this._ = []) so that later calls of toString would only encode latest commands, if any.
function Path(precision) {
  //...
  this._precision = precision;
  this._ = [];
  this._str = '';
}

toString: function() {
  if (!this._.length === 0) { return this._str }
  if (!this.precision) {
      this._str += this._.map(a => a[0] + (a[1] ? a[1].join(',') : '')).join('')
  } else {
      this._str += this._.map(a => a[0] + (a[1] ? a[1].map(n => n.toFixed(this._precision)).join(',') : '')).join('')
  }
  this._ = []
  return this._str
}

Your approaches likely have significantly more overhead than the ones I mentioned due to the large number of temporary objects and the resulting garbage collection cost.

Thanks, I suspected that too. If you are planning to do this soon, I'll wait and see the solution you'll come up with (always good reading d3 code), otherwise time permitting I'll try a patch following one of your approaches.

My take…
Option 1 is perhaps the fastest, but also the least maintainable since the code is wholly duplicated. So I’m not wild about that.
Option 3 can’t fix the precision of derived coordinates in path.arcTo and path.arc. (Only the input coordinates are rounded, so for example, x1 + t21 * x21 may not be rounded.)
That leaves option 2, which introduces a small amount of overhead in the default case, but if we can measure that and it’s not significant then I’d be okay with this change. However, I would ask you to implement tests.

Ah fantastic! OK will do.

I did a first quick test just measuring the time (not memory consumption for example), using lodash for convenience:
_.each(_.range(7), function(exp) {
    var cycles = Math.pow(10, exp)

    var start = new Date;
    _.times(cycles, function(n) {
        d3path.path().moveTo(10.1234567890, 10.1234567890);
    })
    var curpath = new Date - start;

    start = new Date;
    _.times(cycles, function(n) {
        d3pathToFixed.path().moveTo(10.1234567890, 10.1234567890);
    })
    var newpath = new Date - start;

    start = new Date;
    _.times(cycles, function(n) {
        d3pathToFixed.pathFixed(2).moveTo(10.1234567890, 10.1234567890);
    })
    var newpathfixed = new Date - start;

    console.log({exp: '1e' + exp, curpath: curpath, newpath: newpath, newpathfixed: newpathfixed})
})

with these results (ran it just 3 times as they seem to be consistent).
$ node index.js
{ exp: '1e0', curpath: 1, newpath: 0, newpathfixed: 0 }
{ exp: '1e1', curpath: 0, newpath: 0, newpathfixed: 0 }
{ exp: '1e2', curpath: 0, newpath: 0, newpathfixed: 0.01 }
{ exp: '1e3',
  curpath: 0.001,
  newpath: 0.001,
  newpathfixed: 0.003 }
{ exp: '1e4',
  curpath: 0.0001,
  newpath: 0.0002,
  newpathfixed: 0.002 }
{ exp: '1e5',
  curpath: 0.00008,
  newpath: 0.00017,
  newpathfixed: 0.00218 }
{ exp: '1e6',
  curpath: 0.000067,
  newpath: 0.00008,
  newpathfixed: 0.002227 }

$ node index.js
{ exp: '1e0', curpath: 1, newpath: 0, newpathfixed: 0 }
{ exp: '1e1', curpath: 0, newpath: 0, newpathfixed: 0 }
{ exp: '1e2', curpath: 0, newpath: 0, newpathfixed: 0.01 }
{ exp: '1e3',
  curpath: 0.001,
  newpath: 0.002,
  newpathfixed: 0.002 }
{ exp: '1e4',
  curpath: 0.0001,
  newpath: 0.0002,
  newpathfixed: 0.0021 }
{ exp: '1e5',
  curpath: 0.0001,
  newpath: 0.00018,
  newpathfixed: 0.00235 }
{ exp: '1e6',
  curpath: 0.000057,
  newpath: 0.000099,
  newpathfixed: 0.002258 }

$ node index.js
{ exp: '1e0', curpath: 1, newpath: 0, newpathfixed: 0 }
{ exp: '1e1', curpath: 0, newpath: 0, newpathfixed: 0 }
{ exp: '1e2', curpath: 0, newpath: 0, newpathfixed: 0.01 }
{ exp: '1e3',
  curpath: 0.001,
  newpath: 0.002,
  newpathfixed: 0.002 }
{ exp: '1e4', curpath: 0, newpath: 0.0003, newpathfixed: 0.0025 }
{ exp: '1e5',
  curpath: 0.00007,
  newpath: 0.00015,
  newpathfixed: 0.00205 }
{ exp: '1e6',
  curpath: 0.000063,
  newpath: 0.000074,
  newpathfixed: 0.002155 }

Also, using .toFixed() "the number is rounded if necessary, and the fractional part is padded with zeros if necessary so that it has the specified length": to avoid the string conversion and the padded zeroes maybe it would be faster to just round the number with a custom round() similar to this one.

I’m not sure that such the proposed rounding method is guaranteed to limit the number of decimal digits. Though certainly it does seem to be a widely-used technique. So, maybe? That was essentially how d3.round was implemented in D3 3.x; see round.js.
function round(x, n) {
  return n ? Math.round(x * (n = Math.pow(10, n))) / n : Math.round(x);
}

I removed d3.round from D3 4.0 since I didn’t think it was reliable, but perhaps it is reliable? It’s possible my judgment was affected by the earlier implementation of d3.round, which was not reliable; see https://github.com/d3/d3/issues/210#issuecomment-3608547.
The other exponential notation technique is also interesting (as packaged in round10.)
function round(x, n) {
  x = +x, n = +n;
  x = (x + "").split("e");
  x = Math.round(+(x[0] + "e" + (x[1] ? (+x[1] + n) : n)));
  x = (x + "").split("e");
  return +(x[0] + "e" + (x[1] ? (+x[1] - n) : -n));
}

This technique is arguably more intuitive, for example:
round(1.275, 2) // 1.28

But the first technique’s answer is arguably more correct, since a more exact representation of 1.275 is 1.27499999999999991118:
(1.275).toFixed(20) // "1.27499999999999991118"

So really the question is whether you want to interpret the input value 1.275 as its binary floating point value in IEEE754, or as the shortest-equivalent decimal value, i.e., as the exact decimal number represented by the result of number.toString.
Certainly the first technique is a lot faster, and if your input values aren’t hand-authored decimal values anyway (e.g., they are the result of trigonometric computations), then I think it’s perfectly reasonable to treat them as the language-native binary floating point values.
So all that suggests it might be reasonable to re-introduce d3.round, with the caveat that we have a better understanding now of how it should behave.

I've tried adding the linked round function:
function round(number, precision) {
    var factor = Math.pow(10, precision);
    var tempNumber = number * factor;
    var roundedTempNumber = Math.round(tempNumber);
    return roundedTempNumber / factor;
}

export function pathRounded(digits) {
  var path = new Path;
  (digits = +digits).toFixed(digits); // Validate digits.
  path._format = function(x) { return round(+x, digits); };
  return path;
}

and it seems it's ~2x faster than toFixed():
$ node index.js
{ exp: '1e0',
  curpath: 1,
  newpath: 0,
  newpathfixed: 0,
  newpathrounded: 1 }
{ exp: '1e1',
  curpath: 0,
  newpath: 0,
  newpathfixed: 0,
  newpathrounded: 0 }
{ exp: '1e2',
  curpath: 0,
  newpath: 0,
  newpathfixed: 0,
  newpathrounded: 0.01 }
{ exp: '1e3',
  curpath: 0.001,
  newpath: 0.002,
  newpathfixed: 0.002,
  newpathrounded: 0.002 }
{ exp: '1e4',
  curpath: 0.0001,
  newpath: 0.0002,
  newpathfixed: 0.0019,
  newpathrounded: 0.0009 }
{ exp: '1e5',
  curpath: 0.00007,
  newpath: 0.00016,
  newpathfixed: 0.00206,
  newpathrounded: 0.00114 }
{ exp: '1e6',
  curpath: 0.000054,
  newpath: 0.000085,
  newpathfixed: 0.002005,
  newpathrounded: 0.001053 }
--- curpath --- M10.123456789,10.123456789
--- newpath --- M10.123456789,10.123456789
--- newpathfixed --- M10.12,10.12
--- newpathrounded --- M10.12,10.12

so I agree it would be nice to have a proper round() function to be used for such cases.
We should do some more in-depth testing to we get a better idea.
Also maybe input values should be considered numbers, so to avoid using +x?

I did some further quick-testing. Given these functions:
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/round#PHP-Like_rounding_Method
function roundMDN(number, precision) {
    var factor = Math.pow(10, precision);
    var tempNumber = number * factor;
    var roundedTempNumber = Math.round(tempNumber);
    return roundedTempNumber / factor;
}

export function pathRoundedMDN(digits) {
  var path = new Path;
  (digits = +digits).toFixed(digits); // Validate digits.
  path._format = function(x) { return roundMDN(+x, digits); };
  return path;
}

export function pathRoundedMDNinputIsNumber(digits) {
  var path = new Path;
  (digits = +digits).toFixed(digits); // Validate digits.
  path._format = function(x) { return roundMDN(x, digits); };
  return path;
}

// https://github.com/d3/d3-format/issues/32
function round(x, n) {
  return n == null ? Math.round(x) : Math.round(x * (n = Math.pow(10, n))) / n;
}

export function pathRoundedD3(digits) {
  var path = new Path;
  (digits = +digits).toFixed(digits); // Validate digits.
  path._format = function(x) { return round(+x, digits); };
  return path;
}

export function pathRoundedD3InputIsNumber(digits) {
  var path = new Path;
  (digits = +digits).toFixed(digits); // Validate digits.
  path._format = function(x) { return round(x, digits); };
  return path;
}

we get this:
$ node index.js
{ exp: '1e0',
  curpath: 1,
  newpath: 0,
  newpathfixed: 0,
  rounded_MDN: 0,
  rounded_MDN_inputAsNumber: 0,
  rounded_D3: 1,
  rounded_D3_inputAsNumber: 0 }
{ exp: '1e1',
  curpath: 0,
  newpath: 0,
  newpathfixed: 0,
  rounded_MDN: 0,
  rounded_MDN_inputAsNumber: 0,
  rounded_D3: 0,
  rounded_D3_inputAsNumber: 0 }
{ exp: '1e2',
  curpath: 0,
  newpath: 0,
  newpathfixed: 0.01,
  rounded_MDN: 0,
  rounded_MDN_inputAsNumber: 0.01,
  rounded_D3: 0,
  rounded_D3_inputAsNumber: 0 }
{ exp: '1e3',
  curpath: 0.001,
  newpath: 0.001,
  newpathfixed: 0.002,
  rounded_MDN: 0.001,
  rounded_MDN_inputAsNumber: 0.002,
  rounded_D3: 0.001,
  rounded_D3_inputAsNumber: 0.003 }
{ exp: '1e4',
  curpath: 0.0001,
  newpath: 0.0001,
  newpathfixed: 0.0021,
  rounded_MDN: 0.0011,
  rounded_MDN_inputAsNumber: 0.0007,
  rounded_D3: 0.001,
  rounded_D3_inputAsNumber: 0.0012 }
{ exp: '1e5',
  curpath: 0.00019,
  newpath: 0.00012,
  newpathfixed: 0.00184,
  rounded_MDN: 0.001,
  rounded_MDN_inputAsNumber: 0.00115,
  rounded_D3: 0.00116,
  rounded_D3_inputAsNumber: 0.00097 }
{ exp: '1e6',
  curpath: 0.000063,
  newpath: 0.000082,
  newpathfixed: 0.002072,
  rounded_MDN: 0.001002,
  rounded_MDN_inputAsNumber: 0.001043,
  rounded_D3: 0.001006,
  rounded_D3_inputAsNumber: 0.00097 }
--- curpath --- M10.123456789,10.123456789
--- newpath --- M10.123456789,10.123456789
--- newpathfixed --- M10.12,10.12
--- rounded_MDN --- M10.12,10.12
--- rounded_D3 --- M10.12,10.12

so it would seem that using +x doesn't affect calculation time that much, but it helps, and that your rounding function seems a little bit faster.

After doing some testing I've moved some code in this repo so that we can play with ideas eventually. I've added some versions of moveTo using ifs trying to see if it's possible not to repeat code too much: it seems better than using _format at least :)
Now that I have a rough structure, I'll add more tests for the other commands so that we can discuss on numbers.
Meanwhile here are some results:
Executing 1 command call per test...
path.current.path().moveTo x 5,390,351 ops/sec ±1.49% (83 runs sampled)
path.withFormat.path().moveTo x 4,964,609 ops/sec ±1.62% (82 runs sampled)
path.withFormat.pathCoerceFixed(2).moveTo x 500,920 ops/sec ±2.95% (75 runs sampled)
path.withFormat.pathFixed(2).moveTo x 751,370 ops/sec ±2.77% (73 runs sampled)
path.withFormat.pathCoerceRound(2).moveTo x 1,391,397 ops/sec ±2.69% (72 runs sampled)
path.withFormat.pathRound(2).moveTo x 1,436,686 ops/sec ±2.95% (70 runs sampled)
path.withIf.path().moveTo x 4,541,117 ops/sec ±2.07% (83 runs sampled)
path.withIf.path(2).moveTo x 3,711,988 ops/sec ±1.22% (86 runs sampled)

Executing 10 command calls per test...
path.current.path().moveTo x 1,179,496 ops/sec ±1.68% (84 runs sampled)
path.withFormat.path().moveTo x 1,217,988 ops/sec ±1.15% (83 runs sampled)
path.withFormat.pathCoerceFixed(2).moveTo x 71,614 ops/sec ±1.67% (81 runs sampled)
path.withFormat.pathFixed(2).moveTo x 106,151 ops/sec ±1.81% (81 runs sampled)
path.withFormat.pathCoerceRound(2).moveTo x 418,692 ops/sec ±1.83% (78 runs sampled)
path.withFormat.pathRound(2).moveTo x 413,930 ops/sec ±2.28% (78 runs sampled)
path.withIf.path().moveTo x 1,261,124 ops/sec ±1.21% (86 runs sampled)
path.withIf.path(2).moveTo x 741,122 ops/sec ±1.42% (86 runs sampled)

Executing 100 command calls per test...
path.current.path().moveTo x 158,843 ops/sec ±3.43% (78 runs sampled)
path.withFormat.path().moveTo x 165,261 ops/sec ±2.01% (81 runs sampled)
path.withFormat.pathCoerceFixed(2).moveTo x 6,840 ops/sec ±2.83% (78 runs sampled)
path.withFormat.pathFixed(2).moveTo x 9,616 ops/sec ±2.17% (81 runs sampled)
path.withFormat.pathCoerceRound(2).moveTo x 53,534 ops/sec ±2.24% (80 runs sampled)
path.withFormat.pathRound(2).moveTo x 53,603 ops/sec ±3.87% (74 runs sampled)
path.withIf.path().moveTo x 156,071 ops/sec ±2.09% (82 runs sampled)
path.withIf.path(2).moveTo x 81,802 ops/sec ±2.55% (79 runs sampled)

Executing 1000 command calls per test...
path.current.path().moveTo x 14,793 ops/sec ±2.08% (82 runs sampled)
path.withFormat.path().moveTo x 14,506 ops/sec ±3.15% (81 runs sampled)
path.withFormat.pathCoerceFixed(2).moveTo x 663 ops/sec ±2.71% (77 runs sampled)
path.withFormat.pathFixed(2).moveTo x 1,055 ops/sec ±3.30% (78 runs sampled)
path.withFormat.pathCoerceRound(2).moveTo x 5,157 ops/sec ±2.73% (80 runs sampled)
path.withFormat.pathRound(2).moveTo x 5,880 ops/sec ±2.03% (81 runs sampled)
path.withIf.path().moveTo x 14,044 ops/sec ±4.20% (80 runs sampled)
path.withIf.path(2).moveTo x 7,836 ops/sec ±2.94% (82 runs sampled)

Executing 10000 command calls per test...
path.current.path().moveTo x 1,039 ops/sec ±17.22% (77 runs sampled)
path.withFormat.path().moveTo x 906 ops/sec ±18.15% (70 runs sampled)
path.withFormat.pathCoerceFixed(2).moveTo x 62.34 ops/sec ±2.52% (62 runs sampled)
path.withFormat.pathFixed(2).moveTo x 81.83 ops/sec ±25.11% (58 runs sampled)
path.withFormat.pathCoerceRound(2).moveTo x 313 ops/sec ±20.34% (60 runs sampled)
path.withFormat.pathRound(2).moveTo x 282 ops/sec ±19.74% (59 runs sampled)
path.withIf.path().moveTo x 350 ops/sec ±5.77% (70 runs sampled)
path.withIf.path(2).moveTo x 318 ops/sec ±8.97% (51 runs sampled)

Can you summarize those results? It’s hard to read those numbers at a glance. If only there were some way to, I dunno, visualize it… 😉

I've worked a bit more on this benchmarks, adding the ability to measure the execution time and the used heap memory: here you can find a detailed explanation of what I've done.
Also, I've added an interactive chart to explore the results: you can compare results for different implementations, number of digits and commands (moveTo, lineTo, etc..).
For example, here's the case for .moveTo() not rounding input values (digits = null):

while here's the case for rounding with _format() and ifs, with digits equal to 5 and 15:

Here we compare not rounding versus rounding with 5 digits:

I still have to investigate why we get higher execution times (and sometimes higher heap memory, as in the above picture) when we call the command just one time (*.path().moveTo(10.1234567890123456,10.1234567890123456)): it might be that garbage collection happens during the test (I doubt it being a very quick test) or something related to how I measure the heap (see https://github.com/mindrones/d3-benchmarks/blob/master/bench/path.js#L96: I explicitly garbage collect before and after releasing the path instance p).
All in all, my interpretation is that using _format() would be OK as the execution times increase ~2x when we call for example .moveTo() 10 or more times.
Looking forward to read yours :)

Re: greater-than-expected execution time when invoking the command just once, I'm now thinking it might be because we're hitting microsecond scale, hence those points' x-coordinate doesn't represent the actual duration. Still mumbling about memory values.

By the way I've noticed a couple of things in Chrome.
Large d strings make debugging DOM elements pretty slow (plus, it won't let you edit their d attribute), so hopefully shorter strings will improve performances, at least while debugging.

By inspecting the d attribute, it would seem that internally it rounds numbers to the 3rd digit, or they just format numbers in that panel for readability.

I've added another interactive to see hands-on if we get some performance benefits in the browser: please have a try at https://mindrones.github.io/d3-benchmarks/path_client/ (I've explained what I've done here).
It's a path with all its points on a circle and you can control how many points you want to draw: these points gets updated with a timer, so they continuously change at each iteration, making the circle rotate indefinitely.
I patched the d3.line() implementation so that it uses path.withFormat.path() and path.withFormat.pathRound() and added line.precision() to control the number of digits.
Basically:

using the path implementation with format() doesn't seem to impact performances;
if you use enough points (100k on my machine), you'll see that not rounding is ~2x slower than rounding with no digits. Rounding with 3 digits (1/1000 of a pixel seems enough to me), gives benefits too.

Using the implementation with format() and changing the number of digits we get this:

No rounding:

rounding at the 3rd digits

rounding with no digits:

Note that if you're interested to see these numbers with more precision than comparing stats widgets :), we could do an interactive that measures and plots these numbers using window.performance.now()
To summarize, I think rounding numbers in d3-path functions helps charts using path with a lot of points, while using format() doesn't seem to slow down things too much even if set to the identity function. Of course if this goes upstream, functions depending on path methods have to be patched with functions/methods like .precision() or similar to use the new implementation.

Hi all,
I just come across this post when seeking for solutions for this kind of DOM snapshot error:
           <path
    -        d="M4.440892098500626e-15,-58.48076606885378A1.5,1.5,0,0,1,1.538461538461543,-59.98027289113208A60,60,0,1,1,-49.818670465862,33.43800342445478A1.5,1.5,0,0,1,-49.37694389668395,31.335561450590387L-49.37694389668395,31.335561450590387A1.5,1.5,0,0,1,-47.327736942568905,31.766103253232043A57,57,0,1,0,1.461538461538468,-56.98125924657548A1.5,1.5,0,0,1,4.440892098500626e-15,-58.48076606885378Z"
    +        d="M4.440892098500626e-15,-58.48076606885378A1.5,1.5,0,0,1,1.538461538461543,-59.98027289113208A60,60,0,1,1,-49.818670465862006,33.43800342445478A1.5,1.5,0,0,1,-49.37694389668395,31.335561450590387L-49.37694389668395,31.335561450590387A1.5,1.5,0,0,1,-47.327736942568905,31.766103253232043A57,57,0,1,0,1.461538461538468,-56.98125924657548A1.5,1.5,0,0,1,4.440892098500626e-15,-58.48076606885378Z"
             fill="#F9CF54"
           />

The snapshot was generated on Mac but the unit tests were ran on Linux systems, and the floating point error makes the entire snapshot testing fail.
I found @mindrones's snippet really useful for this scenario. When doing tests, we have the luxury to trade CPU cycles for a passing unit test.
The following mock works for me:
// <jest root>/__mocks__/d3-path.js
const pathModule = require.requireActual('d3-path');
const PRECISION = 2;

pathModule.path.prototype.toString = function() {
  // Ref: https://github.com/d3/d3-path/issues/10
  //
  return this._.replace(/\d+\.\d+/g, s => parseFloat(s).toFixed(PRECISION));
};

module.exports = pathModule;

For comparing paths in tests, see also test.pathEqual from d3-shape.

I came upon this issue because the paths generated by geoPath have the coordinates in full floating point precision, which results in huge SVG attributes, slow/crashing developer tools, and all the other issues mentioned in this thread.
In my case, I just made the SVG virtual size (viewBox) large enough for the visual precision I need (about 1.5 SVG units per screen pixel, for normal resolution screens) and then truncated the decimals entirely:
const path = d3.geoPath().projection(...)
const path_trunc = d => path(d).replace(/\.\d+/g, '')

But I was wondering if geoPath had this functionality already built-in, instead of hacking away at the generated string!
I'm not sure how to use geoQuantize to achieve the same result, or if it's even the right tool for the job. This is strictly a SVG serialization issue.

Hello everything, thanks for all your hard work on D3!
I'm just dropping round to mention that I'd love to see this issued fixed. I'm currently consuming D3 by way of Vega, and reducing path decimals from 13 digits of mantissa down to 4 reduces the file size of emitted SVGs by ~75% and makes downstream testing much easier.

Just dropping by to say looking forward to this patch as well! My use case is also optimizing output file size, and the potential savings are huge. Thanks again for the great work!

I'm seeing a similar issue to @MrOrz, but in the context of React server side rendering hydration. The path string that is generated in Nodejs on the server has slight floating point differences to what's generated in the browser, resulting in this error.

Apologies for taking a few years, but I’m working on this now in #12 and it should be available soon. Note that d3-path isn’t used by d3-geo, but we’ll take a similar approach in d3.geoPath to limit the precision of generated SVG path data.


Ignores locale on fastboot server

Fastboot renders always in en, and ignores language setting.
It changes back on client render.

What version of ember-moment and ember-cli-moment-shim are you using

Latest:
    "ember-moment": "^7.4.1",
    "ember-cli-moment-shim": "^3.5.0",

The behavior should be the same out of the box but you may need to explicitly configure the shim to bring in the locales.  https://github.com/jasonmit/ember-cli-moment-shim#i18n-support
I still will treat this as a bug and figure out why both environments are not behaving identically w/o configuration.  Will just take me a few days until I can get around to it but the above may work for now.


fix: Artifact dir

#9  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tazarov and the rest of your teammates on  Graphite


Unexpected window close confirm dialog

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: latest
OS Version: Windows 11

Steps to Reproduce:

Drag a file outside and it will be opened in a new Window

When closing it, it request a confirmation

This is expected if you have window.confirmBeforeClose configured.

I may not configure window.confirmBeforeClose to false as I used to close the windows by a accidental click.
The scenario triggered is that I have two monitors. When I move the mouse pointer from the bottom left corner of one screen (where VSCode is maximized) to the top right corner of the other screen, Windows causes a slight delay of the mouse at the top right corner of the screen where the bottom left corner of the other screen is, coincidentally where the close button of VSCode is located.

What does the dialog read in english?

I suppose closing a file in a standalone window should behave as closing a file in the main window

The dialog appears from the window.confirmBeforeClose setting so you must have configured it.

i known that but
I suppose closing a file in a standalone window should behave as closing a file in the main window

I think you are asking to not apply the confirmation setting to floating windows.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


[bug] When sending out MAX amount (consolidation), an undesired 0 sats change output is created.

Watchonly forces to add a change address, even when consolidating funds (i.e. when sending out the MAX amount). This makes transaction have an one output with 0 sats. Therefore they are dropped as dust by the mempool.
Expected behaviour:
When max amount is selected, no change address are created and transactions have only one output.
Running watchonly 0.22 with LNbits 0.12

I think there is something wrong with this bit in the payment.js. There should never be an outputs when the diffAmount is 0. But for some reason it nonetheless gets created.
if (!excludeChange) {           const change = this.createChangeOutput()           const diffAmount = this.selectedAmount - this.totalPayedAmount           if (diffAmount >= this.DUST_LIMIT) {             tx.outputs.push(change)           }


Watch k8s

This pull requests brings the ability to watch for services on Kubernetes and generate events starting from them.
Status:

[x] create the k8s command
[x] watch for services
[x] generate openapi Services and Events
[x] send events
[x] unit tests
[x] documentation

Hi @SunSince90, since this PR shared one file with the etcd support work, it will need to be rebased now.