text:
Error building vagga-git from AUR

I get this error when trying to build vagga-git from AUR
aura >>= Building `vagga-git`...
aura >>= Well, building `vagga-git` failed.
aura >>= Dumping makepkg output in 3.. 2.. 1..
==> Making package: vagga-git v0.2.5.r39.g410bb06-1 (Mon May 11 13:45:28 PDT 2015)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Cloning vagga-git git repo...
Cloning into bare repository '/var/cache/pacman/pkg/vagga-git17839/vagga-git/vagga-git'...
warning: templates not found /home/joe/.git_template
==> Validating source files with md5sums...
    vagga-git ... Skipped
==> Extracting sources...
  -> Creating working copy of vagga git repo...
Cloning into 'vagga-git'...
warning: templates not found /home/joe/.git_template
done.
Switched to a new branch 'makepkg'
==> Starting pkgver()...
==> Updated version: vagga-git v0.2.5.r41.g8a4ccef-1
==> Starting prepare()...
Cloning into 'rust-argparse'...
warning: templates not found /home/joe/.git_template
Cloning into 'rust-quire'...
warning: templates not found /home/joe/.git_template
==> Starting build()...
+ mkdir alpine
+ cd alpine
+ rm MIRRORS.txt
+ true
+ wget --no-use-server-timestamp http://nl.alpinelinux.org/alpine/MIRRORS.txt -O MIRRORS.txt
--2015-05-11 13:45:31--  http://nl.alpinelinux.org/alpine/MIRRORS.txt
Resolving nl.alpinelinux.org (nl.alpinelinux.org)... 88.159.20.184
Connecting to nl.alpinelinux.org (nl.alpinelinux.org)|88.159.20.184|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 405 [text/plain]
Saving to: ‘MIRRORS.txt’

     0K                                                       100% 32.9M=0s

2015-05-11 13:45:32 (32.9 MB/s) - ‘MIRRORS.txt’ saved [405/405]

++ sort --random-sort MIRRORS.txt
++ head -n 1
+ mirror=http://dl-4.alpinelinux.org/alpine/
+ wget --no-use-server-timestamp http://dl-4.alpinelinux.org/alpine//v3.1/main/x86_64/apk-tools-static-2.5.0_rc1-r0.apk -O apk-tools-static-2.5.0_rc1-r0.apk
--2015-05-11 13:45:32--  http://dl-4.alpinelinux.org/alpine//v3.1/main/x86_64/apk-tools-static-2.5.0_rc1-r0.apk
Resolving dl-4.alpinelinux.org (dl-4.alpinelinux.org)... 74.117.189.114
Connecting to dl-4.alpinelinux.org (dl-4.alpinelinux.org)|74.117.189.114|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 816815 (798K) [application/octet-stream]
Saving to: ‘apk-tools-static-2.5.0_rc1-r0.apk’

     0K .......... .......... .......... .......... ..........  6%  158K 5s
    50K .......... .......... .......... .......... .......... 12%  415K 3s
   100K .......... .......... .......... .......... .......... 18%  839K 2s
   150K .......... .......... .......... .......... .......... 25% 2.93M 2s
   200K .......... .......... .......... .......... .......... 31%  860K 1s
   250K .......... .......... .......... .......... .......... 37% 7.53M 1s
   300K .......... .......... .......... .......... .......... 43% 12.3M 1s
   350K .......... .......... .......... .......... .......... 50%  922K 1s
   400K .......... .......... .......... .......... .......... 56% 4.35M 1s
   450K .......... .......... .......... .......... .......... 62% 5.59M 0s
   500K .......... .......... .......... .......... .......... 68% 1.29M 0s
   550K .......... .......... .......... .......... .......... 75% 9.62M 0s
   600K .......... .......... .......... .......... .......... 81% 6.23M 0s
   650K .......... .......... .......... .......... .......... 87% 3.91M 0s
   700K .......... .......... .......... .......... .......... 94% 2.80M 0s
   750K .......... .......... .......... .......... .......   100% 4.73M=0.7s

2015-05-11 13:45:33 (1.04 MB/s) - ‘apk-tools-static-2.5.0_rc1-r0.apk’ saved [816815/816815]

+ wget --no-use-server-timestamp http://dl-4.alpinelinux.org/alpine//v3.1/main/x86_64/busybox-static-1.22.1-r15.apk -O busybox-static-1.22.1-r15.apk
--2015-05-11 13:45:33--  http://dl-4.alpinelinux.org/alpine//v3.1/main/x86_64/busybox-static-1.22.1-r15.apk
Resolving dl-4.alpinelinux.org (dl-4.alpinelinux.org)... 74.117.189.114
Connecting to dl-4.alpinelinux.org (dl-4.alpinelinux.org)|74.117.189.114|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 564957 (552K) [application/octet-stream]
Saving to: ‘busybox-static-1.22.1-r15.apk’

     0K .......... .......... .......... .......... ..........  9%  198K 3s
    50K .......... .......... .......... .......... .......... 18%  571K 2s
   100K .......... .......... .......... .......... .......... 27% 1.03M 1s
   150K .......... .......... .......... .......... .......... 36%  891K 1s
   200K .......... .......... .......... .......... .......... 45% 6.15M 1s
   250K .......... .......... .......... .......... .......... 54% 2.03M 0s
   300K .......... .......... .......... .......... .......... 63% 1.35M 0s
   350K .......... .......... .......... .......... .......... 72% 2.90M 0s
   400K .......... .......... .......... .......... .......... 81% 2.64M 0s
   450K .......... .......... .......... .......... .......... 90% 1.68M 0s
   500K .......... .......... .......... .......... .......... 99% 5.13M 0s
   550K .                                                     100% 3273G=0.6s

2015-05-11 13:45:34 (941 KB/s) - ‘busybox-static-1.22.1-r15.apk’ saved [564957/564957]

+ wget --no-use-server-timestamp http://dl-4.alpinelinux.org/alpine//v3.1/main/x86_64/alpine-keys-1.1-r0.apk -O alpine-keys-1.1-r0.apk
--2015-05-11 13:45:34--  http://dl-4.alpinelinux.org/alpine//v3.1/main/x86_64/alpine-keys-1.1-r0.apk
Resolving dl-4.alpinelinux.org (dl-4.alpinelinux.org)... 74.117.189.114
Connecting to dl-4.alpinelinux.org (dl-4.alpinelinux.org)|74.117.189.114|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2758 (2.7K) [application/octet-stream]
Saving to: ‘alpine-keys-1.1-r0.apk’

     0K ..                                                    100% 2.97M=0.001s

2015-05-11 13:45:34 (2.97 MB/s) - ‘alpine-keys-1.1-r0.apk’ saved [2758/2758]

+ sha1sum -c
+ cd ..
+ tar -xf alpine/apk-tools-static-2.5.0_rc1-r0.apk sbin/apk.static -O
+ tar -xf alpine/busybox-static-1.22.1-r15.apk bin/busybox.static -O
+ cp alpine/alpine-keys-1.1-r0.apk alpine-keys.apk
+ chmod +x apk busybox
src/test_int.rs:11:49: 11:52 error: illegal suffix `us` for numeric literal
src/test_int.rs:11           .add_option(&["-i", "--incr"], IncrBy(1us),
                                                                   ^~~
src/test_int.rs:11:49: 11:52 help: the suffix must be one of the integral types (`u32`, `isize`, etc)
src/test_int.rs:30:49: 30:52 error: illegal suffix `is` for numeric literal
src/test_int.rs:30           .add_option(&["-d", "--decr"], DecrBy(1is),
                                                                   ^~~
src/test_int.rs:30:49: 30:52 help: the suffix must be one of the integral types (`u32`, `isize`, etc)
src/test_int.rs:50:49: 50:52 error: illegal suffix `is` for numeric literal
src/test_int.rs:50           .add_option(&["-d", "--decr"], DecrBy(1is),
                                                                   ^~~
src/test_int.rs:50:49: 50:52 help: the suffix must be one of the integral types (`u32`, `isize`, etc)
src/test_int.rs:52:49: 52:52 error: illegal suffix `is` for numeric literal
src/test_int.rs:52           .add_option(&["-i", "--incr"], IncrBy(1is),
                                                                   ^~~
src/test_int.rs:52:49: 52:52 help: the suffix must be one of the integral types (`u32`, `isize`, etc)
src/test_env.rs:9:20: 9:23 error: illegal suffix `is` for numeric literal
src/test_env.rs:9     let mut val1 = 1is;
                                     ^~~
src/test_env.rs:9:20: 9:23 help: the suffix must be one of the integral types (`u32`, `isize`, etc)
src/test_env.rs:10:20: 10:23 error: illegal suffix `is` for numeric literal
src/test_env.rs:10     let mut val2 = 2is;
                                      ^~~
src/test_env.rs:10:20: 10:23 help: the suffix must be one of the integral types (`u32`, `isize`, etc)
error: aborting due to 6 previous errors
make[1]: *** [libargparse.rlib] Error 101
make: *** [rust-argparse/libargparse.rlib] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

Submodule 'rust-argparse' (git://github.com/tailhook/rust-argparse) registered for path 'rust-argparse'
Submodule 'rust-quire' (git://github.com/tailhook/rust-quire) registered for path 'rust-quire'
Submodule path 'rust-argparse': checked out '92629338a84148588a0735acee3006aeb44cebab'
Submodule path 'rust-quire': checked out '7a1d0eebea345386d88962b4344457bf392bf734'
./fetch_binaries.sh
apk-tools-static-2.5.0_rc1-r0.apk: OK
busybox-static-1.22.1-r15.apk: OK
alpine-keys-1.1-r0.apk: OK
make -C rust-argparse libargparse.rlib
make[1]: Entering directory '/var/cache/pacman/pkg/vagga-git17839/vagga-git/src/vagga-git/rust-argparse'
rustc -o libargparse.rlib src/lib.rs
Makefile:10: recipe for target 'libargparse.rlib' failed
make[1]: Leaving directory '/var/cache/pacman/pkg/vagga-git17839/vagga-git/src/vagga-git/rust-argparse'
Makefile:16: recipe for target 'rust-argparse/libargparse.rlib' failed

Yeah, probably rustc in aur is current beta. Vagga itself is currently only builds by rustc-1.0.0.alpha.2. I'm working on making it build on beta versions of rust.

@tailhook Any hope of updating to Rust 1.0?

@joehillen, yeah, I'm working on this. Just don't have enough time yet.

Since it's hard to build rust with musl support, there is now vagga-bin package which installs official binaries (currently from testing). Ping @rrader to update the package

authors: joehillen tailhook

repo: tailhook/vagga


text:
Fix: 時刻を修正時にフォーマットが変わってしまう

Close #151
Excel を CSV に変換時に10:00 → 1899-12-30T08:10:00.000Z に変わってしまう問題を修正しました。
ライブラリの変更について

XLSXの、readFile で読み込み、utils.sheet_to_csv で書き出すと、時刻の場合は、読み込み時のフォーマットに従って CSV に書き出しをする仕様だったのでライブラリを変更しました。

readXlsxFile でも文字列として Excel を読み込めないか調査したのですが、オプションがありませんでした。

コンフリクトしてましたが、全部 CSV のコンフリクトのようなので、コード自体には問題ないかと思います。

@phanect
ありがとうございます! コンフリクト解消しました。

source: gharchive/pull-request

authors: naogify phanect

repo: takamatsu-city/opendata

license_type: permissive

license_source: github-api


text:
feat(core): add View core component

I found the need for a more primitive component than Stack when using styled and in some other circumnstances. I found myself overriding YStack to be... well not a stack.
WDYT?

Looks good, I'll get this in alongside the beta PR.

Just out of curiosity, was it a default style on Stack that made you want View? Or something else?

I think since Stack is basically just a renamed View, going to leave this one. I will test if styled((react-native').View) works.

authors: mrjackdavis natew

repo: tamagui/tamagui

license: MIT


text:
windows10 host build Hypervisor-101-in-Rust setup

1、add proc-macro2 = "1.0.66" content in the project root directory *.toml
2、add use proc_macro2 as _; content to xtest/main.rs
3、compile is successful

Thanks for reporting the issue. Resolved with b3f60f37257db8e77112b4ffbb436458f022cae6 by updating the dependencies.

Thanks for reporting the issue. Resolved with b3f60f3 by updating the dependencies.

This is what I should do, do you have any good ways to improve the compilation speed in rust? There seems to be little information in this area

I am not sure as I have not felt the need of optimization. This project clean builds for debug in about 11 seconds on my primary environment, which is fine to me.

I am not sure as I have not felt the need of optimization. This project clean builds for debug in about 11 seconds on my primary environment, which is fine to me.

Through my efforts, I found some tools that can reduce the compilation time, which is very helpful during the development of rust.
https://github.com/mozilla/sccache
https://www.msys2.org/
[build]
rustc-wrapper = "C:/Users/botao/.cargo/bin/sccache.exe"
[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "linker=C:/msys64/mingw64/bin/ld.lld.exe"]

source: gharchive/issue


text:
Element array squash

This PR provides GL support for element arrays. Currently the polyline feature is the only feature to make use of them (with points and polygons to follow).
The polyline builder in src/builders/polylines.js was rewritten to make use of element arrays and to improve the runtime performance. It also more closely mimics the es code. Further optimizations were made, such as not creating line caps at the beginning of tile boundaries, and dynamically setting the triangle count for a fan joint or round line cap. Because of the latter, you no longer need to specify a zoom filter for rounded lines in a scene file.
All in all, we get a significant speed up in JS execution (~30%) in typical use. We also use less memory on the GPU side as a result of switching to element arrays (30-40%), and create far fewer triangles for joins and caps (30% - 67% depending on zoom).

Recent commits include support for element arrays in both polygon (with updated verison of earcut, which requires an npm install) and point builders.

96cf00b fixes the lines mutation so make the buildPolylines function not have side effects
1d57c84 uses lowercase keys to match the scene file for defining join and cap types
80c5faa fixes textures for round caps and a square cap not existing for the beginning of a line (this bug may also exist on the es codebase)

3f85d80 Fixes the texture coordinate bug that would cause diagonal texture artifacts (uv coordinates were incorrectly assigned)
6b83951 Includes a guard to gracefully degrade when element indices overflow and no Uint32 index support is available

I'm not overly concerned about enforcing total consistency in variable name convention (e.g. under_score vs. camelCase), even if that would be ideal (and if I was starting the project today I would use camel case anyway). But, perhaps we could change a couple of these to keep consistency within classes where possible, specifically:

In VBOMesh: toggleElementArray and elementBuffer
In VertexData: elementBuffer
In VertexElements: members are camel case (e.g. hasOverflown), but at least it's internally consistent, so optional to change

What do you think?
The old polyline builder had mixed styles anyway so I suppose we can leave it...

4e1f0a9 under_score styling
5c2df73 removes texcoord_scale dependency in polyline builder
279dff0 implements texture coordinates that "pass through" line caps (needs to be augmented to use texcoord_width when merged into master
95351b0 puts vertex_elements on equal footing with vertex_data. Both are passed in as arguments into VBOMesh instead of inside of an options argument

authors: bcamper dmvaldman

repo: tangrams/tangram

license: mit

license_source: bigquery


text:
fine-tune 時，mAP下降很多

您好，我想請教一下
我使用 prune.py  做剪枝後的 mAP 是 0.72

但是我將他 fine-tune 時，mAP 下降到幾乎為 0 了，請問是哪邊有錯誤嗎? 謝謝。
我執行的指令如下:
python train.py --cfg ../prune_0.1_Person_detection/prune_0.1_cfg/prune_0.1_yolov4-tiny-obj.cfg --weights ../prune_0.1_Person_detection/prune_0.1_weights/prune_0.1_yolov4-tiny-obj_final.weights --data ../Person_detection/cfg/person-prune.data --epochs 50 --batch-size 32
以下是訓練時的訊息:
learning rate: 0.0011625
/home/joy/.local/lib/python3.6/site-packages/torch/cuda/memory.py:346: FutureWarning: torch.cuda.memory_cached has been renamed to torch.cuda.memory_reserved
FutureWarning)
1/49    0.367G      1.38      6.37         0      7.76         0         0         4       160:
Class    Images   Targets         P         R       mAP        F1: 100%|█| 69/69 [03:4
all  2.18e+03  3.88e+03    0.0288     0.295    0.0927    0.0525
 Epoch   gpu_mem      GIoU       obj       cls     total      soft    rratio   targets  img_size

0%|                                                                        | 0/274 [00:00<?, ?it/s]learning rate: 0.002324
2/49    0.367G      1.12      5.61         0      6.73         0         0         8       160:
Class    Images   Targets         P         R       mAP        F1: 100%|█| 69/69 [01:4
all  2.18e+03  3.88e+03   0.00237   0.00954  2.99e-05   0.00379
 Epoch   gpu_mem      GIoU       obj       cls     total      soft    rratio   targets  img_size

0%|                                                                        | 0/274 [00:00<?, ?it/s]learning rate: 0.0034855
Gradient overflow.  Skipping step, loss scaler 0 reducing loss scale to 1024.0
3/49    0.367G      1.04       5.2         0      6.24         0         0         4       160:
Class    Images   Targets         P         R       mAP        F1:  90%|▉| 62/69 [04:

@chingi071
Can you pls tell the folder structure you have used for sparsity Training ? I mean .data file and the .txt file. Since for me during the sparsity training only 1 Img is getting detected and its corresponding label .
Thanks in advance :)

@anusha657 This is my folder structure.

Thanks @chingi071 for the response


text:
Adding in a function for checking if retries should be performed

Function implemented into the config as per #84

I would love to see function support for "retry" option instead!
That way we'll avoid some edge cases.
What do you think @tannerlinsley @smozely ?
It should affect compatibility

@Cherniavskii so you mean replace the current ‘retry’ being allowed to be true or a number ... and allow it to also be a object that covers all the config for retries?
I’d be happy to do that, but just want to make sure @tannerlinsley is ok with going that direction

Also, I'm more fond of the name shouldRetryFn. Thoughts?

Yes, I like the idea of just overloading the retry option with the ability to be a function, similar to how retry delays work

Yes, I like the idea of just overloading the retry option with the ability to be a function, similar to how retry delays work

Ah right, so for that your saying, if I provide a function for retry, then that function should handle everything ... so I'd end up with something like ...
config.retry: (failureCount, error) => {
  return failureCount <= 5 && error !== 'NoRetry';
}

So I have to implement both the retry count check in my function, and the extra logic ... I'm all cool with that.

I've updated with the overloading of the retry config item

So I have to implement both the retry count check in my function, and the extra logic

Yeah, I think it's still way better than dealing with edge cases like:
{
  retry: true,
  retryChecker: () => false,
  // what should happen?
}

@cherniavskii Thanks for pointing out the mistake with those typeof checks, I also expanded another test which was passing for the wrong reasons with my change

Awesome!

Whoop! thanks folks ... now to replace my home-grown solution with this!

authors: cherniavskii smozely tannerlinsley

repo: tannerlinsley/react-query


text:
Updating pager parameters does not  update the pager markup.

Using v7? yes
Describe the bug
When i change the pager parameters manually the change does not reflect on UI.
To Reproduce
Steps to reproduce the behavior:
this.setState({page:0})
Expected behavior
the pager should render initial page.
Codepen!
i us CDN version
https://codepen.io/anon/pen/Gabdao

You are not passing the page prop to the table. Please re-ask this question on https://spectrum.chat/react-table for more help. Thanks!

authors: B-Esmaili tannerlinsley

repo: tannerlinsley/react-table


text:
reverse the array

added code for reverse the array

please give this repo a star and follow me for follow back😊


text:
Extracting strings from a grammar with many options

Apologies for possibly naive question.  Thanks a lot for the help
I am trying to write a grammar in which there are multiple options, any of which can be matched (only one per input string), but it's not clear to me how to do so and still capture the parts that I want to capture.
Here's some example code:
struct name
  : plus< alpha >
{};

struct epithet
  : plus< alpha >
{};

// various possible combinations
struct just_a_name
  : must< name >
{};
struct genus_epithet
  : must< name, space, epithet >
{};
struct genus_epithet_infra
  : must< name, space, epithet, space, name >
{};

struct grammar
  : star<
    sor<
      just_a_name,
      genus_epithet,
      genus_epithet_infra
    >,
    eof
> {};

template<>
struct action< name >
{
  template< typename Input >
  static void apply( const Input& in, std::string& v, const std::string& )
  {
    v = in.string();
  }
};

template<>
struct action< epithet >
{
  template< typename Input >
  static void apply( const Input& in, const std::string&, std::string& v )
  {
    v = in.string();
  }
};

In the actions, I want to grab the name (and epithet when matched) if any of the three patterns (just_a_name, genus_epithet, genus_epithet_infra) are matched. But it seems that I can't extract those two things if their names aren't in the grammar. Or is that incorrect?  Maybe there's some way I can drill down to the string I want inside each action?

The order within the sor is your problem in the above example: sor stands for "Sequenced OR", meaning that all alternatives are tried in the order that you provide them. The first one which matches will match for the whole sor, hence if you try just_a_name first, it will match and sor will be happy and no longer try to match any other alternative. Therefore it will never try to match genus_epithet or genus_epithet_infra.
If you try to match the longer expressions first by using sor<genus_epithet_infra, genus_epithet, just_a_name>, you'll run into the next problem: You are using must, therefore genus_epithet_infra will generate a global failure (i.e. an exception) instead of local failure. To really solve your problem, you'd need to drop the must, or turn your grammar into something like
seq< name, if_must< space, epithet >, if_must< space, name > >

Although even that won't work because name and epiphet match the same characters and the star<> in you grammar could not possibly match more than once.
This might be because your example is an artificial example? Your real grammar is probably different, in any case your problem is the way the grammar works.

Thanks! Okay, here's the real code: https://github.com/ropenscilabs/pegax/blob/master/src/sci_name.h#L16-L158
I have these different patterns https://github.com/ropenscilabs/pegax/blob/master/src/sci_name.h#L38-L62 and i'm going to add many more. In my grammar any of them can be a possible match depending on the input string - and I'm hoping to have a cleaner looking grammar statement rather than one huge grammar statement with all possible patterns. Is there a way to use a grammar like https://github.com/ropenscilabs/pegax/blob/master/src/sci_name.h#L64-L77 but still be able to pull out individual parts when a match is found, e.g., epithet if genus_epithet is matched

You real grammar is even worse than the example grammar you posted earlier, sorry. It can not possibly work. Think about it: softSpace is star<space> which means the separator could be nothing. And name, epithet and infraname are all plus<alpha>, separated by softSpace. Looking at just_a_name, genus_epithet and genus_epithet_infra, there is no way to reasonably parse ABC as an input. Could be anything of those three.
Those (plus other) alternatives are inside of a star<sor<...>>. How would you imaging the input foobarbazblablubblaberhalloholagaga to match to those rules? It could be foobarbaz matches just_a_name three times, once with foo, once with bar and once with baz. Or is it meant to be genus_epithet_infra with foo being the name, bar being epithet and baz being infraname? Or is foobarbaz as a whole the name part of a larger genus_epithet_infra? Plus the rest and all possible combinations. Plus all the other combinations allowed by the additional alternatives. How would the grammar decide that? I'm afraid your understanding of how grammars (specifically PEGs) work is flawed and needs to be fixed first, this has nothing to do with the PEGTL.
Plus for the PEGTL any combination of sor< must<A>, must<B> > is always plain useless as must<A> either matches or generates a global error, so it will never even once try to match must<B>. This part is PEGTL-specific, so if you want to work on the general understanding of PEGs, I'd suggest to leave out all must-rules from your grammar for now and focus on the basics. Good luck!

authors: d-frey sckott

repo: taocpp/PEGTL


text:
Please include the tempdir option in help file

Using MACS on a shared HPC environment, it will fill up the tmp dir and result in some e-mails from the sysadmin. I see that the option exists in the callpeak_cmd.py source code and would be nice to add it to the help file and documentation as an option to redirect the temporary file write/read location.
Thanks!

Previous version man page? http://manpages.org/macs2_callpeak

This option doesn't exist on the latest release of MACS2? (pypi source)

Absolutely critical option required.

As a work around for the time being, you can modify the TEMPDIR/TEMP/TMP environment variable to point to an alternative temporary location to write files (this is untested but based on the function call to mkstemp: "The default directory is chosen from a platform-dependent list, but the user of the application can control the directory location by setting the TMPDIR, TEMP or TMP environment variables. There is thus no guarantee that the generated filename will have any nice properties, such as not requiring quoting when passed to external commands via os.popen()."
Setting up a pull request to add the option back to the software.

Running:

export $TMPDIR=$(mktemp -d)
<script>
rm -rf $TMPDIR

works.
PS: This is for a Nextflow pipeline, but it should work similarly for anything else.

Right. I forgot to mention this option in the README file which manpage is based on. On command line, if you type 'macs2 callpeak --help', you will see:
--tempdir TEMPDIR     Optional directory to store temp files. DEFAULT: XXX/XXX/tmp

Unfortunately, when I run:
macs2 callpeak --help

It does not display the --tempdir option. The version I am using is via an anaconda install, version macs2 2.1.0.20150731.

To be clear, this is the Anaconda2 install and the latest version of macs2 is for python3 correct?

@biobenkj This option can be found in the latest release on PyPI, version 2.1.1 20160309. Older versions, such as your 2.1.0, don't have such option. Also, I am not aware of Anaconda2, but I remember previously there is a bug in the math libraries in Anaconda. MACS2 is not ready for Python3, only for Python2.7.

Anaconda is a package manager for python: https://www.continuum.io/downloads
The latest version exists for the package manager (recently updated) but think this is a relevant issue for anyone using an older version to re-direct their temp directory based on @c-guzman comment. Feel free to close the issue since this is resolved in the latest version of MACS2

authors: biobenkj c-guzman taoliu

repo: taoliu/MACS


text:
Update n_char_view.rs

fix bug in release-build, that InlineNChar::into_inline_str fails to convert ucs4le to utf8, which is because of usage of std::mem::transmute, supposedly.

Closed by #217

authors: freemine zitsen

repo: taosdata/taos-connector-rust


text:
t.matchSnapshot sensitive to object key order (v13)

t.matchSnapshot seems to be sensitive to the order keys were added to an object.  Any solution to this?  For example with the following test generate snapshots, then reverse the order of properties: t.matchSnapshot({n2: 'v2', n1: 'v1'});.  The object is deepEqual to the snapshot value but this fails.
const t = require('tap')

t.test('snapshot test', t => {
  t.matchSnapshot({n1: 'v1', n2: 'v2'});
  t.end();
});

The specific use case is in istanbul-lib-processinfo.  My plan is to simplify initialization of the fields at https://github.com/istanbuljs/istanbul-lib-processinfo/blob/2c2086a96d6977264d7c0f7b6252fbb562c65391/index.js#L36-L44
The following should be functionally equivalent (given the assumption that key insertion order is an implementation detail):
Object.assign(this, defaults, fields)

This does change the order which fields are assigned.

I'd approach this by passing a sort option to tcompare.format, and then having the default snapshot stringifier pass that option.  I can see how it's a violation of the expectation in this case.

Unfortunate side effect, enabling sort by default is likely a breaking change for any project that uses t.matchSnapshot(obj) - the results which were previously unsorted are now sorted.  I think this is a good change, just seems like it might violate semver.

Since it was ambiguous before, I don't know that it's clear that it is actually a breaking change.  For comparison, I also shipped the "sort the snapshot file itself" change as a patch, and no one seemed to mind.  Since anyone using snapshots can probably just regenerate them easily enough, it's probably fine?

It's probably fine if no-one else pointed this out in the past few days.  When sorting the snapshot file didn't cause old snapshots to fail, so that's different.  Sorting the object keys makes the old snapshots fail.  As you pointed out regenerating is easy enough so it's probably fine, just something I noticed so I wanted to mention it.

authors: coreyfarrell isaacs

repo: tapjs/node-tap

license: isc


text:
implement truncate for spaces

This patch implements "crud.truncate" call. It's needed for spaces
truncation.
I didn't forget about

[ ] Tests
[ ] Changelog
[ ] Documentation

Closes #91

Please, update the doc and changelog.

Yes, it really looks good. Please, fix my comment and feel free to merge.

repo: tarantool/crud


text:
fixed 'requests (new session for request)', 'grequests (basic auth, jwt auto reset, send with max retries)'.

Hi @tariqdaouda @dothebart ,
I have added the functionality. Please check for changes
Regards,
Dilip Vamsi.

Codecov Report

:exclamation: No coverage uploaded for pull request base (geevent@b8033e1). Click here to learn what that means.
The diff coverage is 95.12%.

@@            Coverage Diff             @@
##             geevent     #125   +/-   ##
==========================================
  Coverage           ?   77.77%
==========================================
  Files              ?       12
  Lines              ?     2394
  Branches           ?        0
==========================================
  Hits               ?     1862
  Misses             ?      532
  Partials           ?        0

Impacted Files
Coverage Δ

pyArango/connection.py
66.66% <95.12%> (ø)

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 b8033e1...48f3458. Read the comment docs.

Hi,
I think you could add that to a disconnect of the connection? The best behaviour of a broken connection is to throw anyways, so the user can decide how to handle the error - i.e. make sure that his last query wasn't executed, but only the result didn't arive - this can't be decided in the driver.

Hi @dothebart  @tariqdaouda ,
I have added functionality to maintain the connection even when the db server restarts or the token is expired.
It also tries to retry to max number of times provided.
But, the tests seems to failing as the travis CI is unable to setup the arangodb.
It seems that the url to retrieve the arangodb setup file in '.travis.yml' file needs to updated.
I tried to update to the latest. But it seems that is also not valid.
Thanks and Regards,
Dilip Vamsi.

Hi @dilipvamsi,
Thanks for your contribution, can you check why the why the checks have faild?

Hi @tariqdaouda ,
The path to which the travis-ci gets the arangodb is failing to retrieve the file to install it for running the tests.
So, I was asking for your help to fix that in my previous comment.
Thanks,
Dilip Vamsi.

The problem seems to be coming form the ArangoDB repo. I've changed the link on the master branch to their master branch (instead of a specific branch) but it still fails.
$ curl -s -L https://raw.githubusercontent.com/brennv/arangodb-travis/master/setup_arangodb.sh -o setup_arangodb.sh
before_install.4
0.00s$ chmod +x setup_arangodb.sh
2.64s$ ./setup_arangodb.sh
curl -s -L http://www.arangodb.org/repositories/travisCI/ArangoDB-3.3.1.tar.gz -o ArangoDB-3.3.1.tar.gz
tar zxf ArangoDB-3.3.1.tar.gz
tar (child): ArangoDB-3.3.1.tar.gz: Cannot open: No such file or directory

There seem to be a problem in the link inside setup_arangodb.sh for downloading the db.
@dothebart do you have any idea as to why this is happening?
Cheers,

Hi,
we should switch travisci to use docker, I don't know whether I will have time to look into this.

Hi @tariqdaouda ,
All the coverage tests are running.
So, check it once and merge to the current branch.
Later merge it to the main branch.
Regards,
Dilip Vamsi.

Hi @tariqdaouda ,
Added functions "fetch_element", "fetch_list", "fetch_list_as_branches", "no_fetch_run".
Which calls db AQLQuery and also checks the returned result size and raises appropriate **errors.
"fetch_element" Query result should only return list with one element.
"fetch_list" merges all the batches returned from the Query to a list.
"fetch_list_as_branches" is a generator function which yields each branch returned by Query.
"no_fetch_run" Query result should only return empty list.
Regards,
Dilip Vamsi.

Ok, I've prepared the switch to docker based travis-ci via dothebart:travis-with-docker-containers - once this is merged, you should pull that into your pr, after that travis should work again.

Hi @tariqdaouda ,
Any plans on merging this to the master.

I think we need to have a way to run the tests gevent based before the geevent branch can be merged.

No a bad idea. For now, it is merged to dev.

Hi @dothebart , @tariqdaouda ,
I have fixed the leakage issue which is caused by using the same session for multiple requests (which can lead in to returning one requests results to another)
So, I don't think it is required to use grequests at all (as session object is different for different requests).
grequests also does the same internally which creates a new session for each request.
Regards,
Dilip Vamsi

ok, can you cherry-pick dd72e5f6c540e5e148943d615ddf7553bb78ce0b ?  (my changes to the travis control?) this should make the tests run then - hopefully green ;-)

authors: codecov-io dilipvamsi dothebart tariqdaouda

repo: tariqdaouda/pyArango


text:
Use initial date to set value to text field.

This will help in implementing a clear button on a date field.

@kalpeshp0310 After the changes, the selected date is not updated in the kitchen-sink.
If we can have that working, then it is ok for merging.

@kalpeshp0310 It seems that the picked date and time is not visible in the kitchen-sink app, please make the changes there are well so that it is updated when the date is picked.

repo: tarkalabs/tarka-ui-kit-flutter


text:
Editing section in preview

PR includes

[x] Bug Fix

Related issues
Resolve #1046

https://github.com/user-attachments/assets/8916814f-6602-4434-ac91-53130dbb3b72

repo: taskany-inc/hire


text:
Refactoring Awesome Books using ES6

In this branch i did:

Used ES6 modules to write modular JavaScript.
Refactored your functions to arrow functions.
Displayed the current date below the navigation bar using Luxon Library.
Divided your code into modules.

@Rustamxon7 Can you please give me a hint how should i fix it?

This link explains how to create Gitflow. You can look through and learn about it.


text:
[Bug]: Coupons can not be disabled

What happened?

Coupons extension can not be disabled without disabling cart and frontend.

Coupon field is not affected by cart settings nor it's configuration is present somewhere else.

What did you expect to happen?

Coupons extension can be disabled without disabling cart and frontend.

Coupon field is affected by cart settings or it's configuration is present somewhere else.

Version
3.2.0
What browser are you seeing the problem on?
Microsoft Edge
Relevant log output
No response

That is the expected behaviour. The coupons extension is required by the cart extension so disabling the coupon extension will disable the cart extension since it's a dependency.

authors: ARTdrakon sampoyigi

repo: tastyigniter/TastyIgniter


text:
Add API endpoints

Beginnings of endpoints - code should all work but docs are not yet complete.
If anyone else has time to jump in on the docs and complete them it would be helpful.

@sampoyigi Should be complete now

I'm not sure about exposing the coupon history database, we want developers to add history using the logHistory method or something similar and not directly adding records to the DB table.. Also the history can be exposed as a relationship of coupons and history only added when there's an order to associate with it.

No problem. Happy to leave history out of it - I can see what you mean.

Let me know if you're happy with the changes

Yep all good, thanks.

authors: ryanmitchell sampoyigi

repo: tastyigniter/ti-ext-coupons


text:
Some information about the algorithm?

Thanks for your great work!  This project had not been updated for a long time. Will it be updated later?
The example pencil_drawing was too complicated, can you provided some information about it's algorithm?
@tatsy

Hi @logic1988,
Thanks for your interest to my project. Actually, this project has not been updated for a while. While I would like to add a lot of new functions to this library, I do not have enough time to do it. So, please forgive me.
Anyway, for pencil_drawing example, it is almost an implementation of the following paper.

A Stylized Approach for Pencil Drawing from Photographs
http://onlinelibrary.wiley.com/doi/10.1111/j.1467-8659.2012.03143.x/full

Therefore, looking throughout this paper would help you to understand the example.
If you have some questions for specific parts of my code, I am always open to answer your question.

Thank you! Can you give a todo list? Maybe we can help you.

Hi @logic1988,
Thank you for offering me a help.
What I currently want to do on this project is to add a fast bilateral filtering and some soft segmentation algorithms. So, the update would not be just an update of the current code. I think it would be too much for asking a help for someone...
For the current code. I think they would be work well. If you have any trouble for the current code. It would be a great help if you revise the codes, and also I can help you to revise them.
If you have any specific trouble for this project. I will close this issue.

If I have any questions, I will ask you. Thanks again.

Hi @logic1988,
It's my pleasure. Thanks again for your interest and kindness.

repo: tatsy/lime


text:
fix(windows): Use SetForegroundWindow before focus hack

This fixes an issue we had with interactive notifications and "deep links", see https://github.com/FabianLars/tauri-plugin-deep-link/issues/26#issuecomment-1493671121 / https://github.com/FabianLars/tauri-plugin-deep-link/pull/27#issuecomment-1493784405
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Docs
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Checklist

[ ] This PR will resolve #___
[x] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
[x] I have added a convincing reason for adding this feature, if necessary
[x] It can be built on all targets and pass CI/CD.

Other information
Small discord conversation: https://discord.com/channels/616186924390023171/807549941936816148/1092384046912380978

Thanks for getting the fix in here!
I think that original focus hack should probably go away. It seems like Windows has already patched it. Trying to steal foreground focus is always going to be a dangerous and brittle game. Windows is going to always be fighting against apps that try to take focus without permission, so we should push devs to go with the AllowSetForegroundWindow approach instead in single-instance scenarios.
https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19083

I agree we should keep an eye on it, but removing it prematurely may be the wrong call right now. The hack was not added with single instance applications in mind so it likely has use-cases we're not thinking about right now.

Fair enough, though maybe we should pay attention to the output of the first SetForegroundWindow and skip the hack code if it succeeds.

authors: FabianLars RandomEngy

repo: tauri-apps/tao


text:
tauri-actions creates multiple release drafts

tauri-actions now creates multiple release drafts for each of the 3 platforms instead of uploading all of the artifacts into a single release draft.
Before/Expected Behavior :

Current/Unexpected Behavior :

Each of the 1.1.7 releases corresponds to the 3 platforms

Issue seems to be resolved

repo: tauri-apps/tauri-action


text:
essential wasm bindings

Describe the problem
using half maintained crates to just be able to invoke backend function or listen to backend event in wasm frontend does not feel right
Describe the solution you'd like
a lot of this library users are using rust for backend and frontend
so they can do everything on the backend and invoke or listen to it in the frontend
so all we need is just two functions
invoke and listen
Alternatives considered
No response
Additional context
No response

This is tracked here https://github.com/tauri-apps/tauri/issues/5354 already. Thanks for the request.

authors: FabianLars mahmoud-eltahawy

repo: tauri-apps/tauri


text:
[bug] HTTP not sending body.

Describe the bug
POSTing to a localhost URL, specifically I set the URL to http://localhost:2000 for testing my API, and it works however it will not send the body which is crucial.
However, using query works but I will not use query as that can potentially expose users' sensitive information.
My API is using expressjs and it is receiving the body as undefined and when checking to see if it was actually expressjs having issues, it wasn't having any issues, Tauri was.
Reproduction

Host an expressjs server on localhost using nodejs.
POST to the server with a body that the server will print out to the console.
Observe.

Expected behavior
I expect Tauri to send the body to the server.
Platform and versions
› OS: Windows 10.0.22000 X64
› Webview2: 104.0.1293.63
› MSVC:
- Visual Studio Build Tools 2022
› Node.js: 18.2.0
› npm: 8.9.0
› pnpm: Not installed!
› yarn: Not installed!
› rustup: 1.25.1
› rustc: 1.62.1
› cargo: 1.62.1
› Rust toolchain: stable-x86_64-pc-windows-msvc
Currently using the latest versions of Tauri.
Stack trace

Additional context
No response

Seems like it's an issue with just expressjs, somewhat. I honestly don't really know because when POSTing with axios, axios sends an empty Object to the server but the server receives it as undefined, but with Tauri it just completely sends an undefined body.


text:
[bug]

Describe the bug

I compiled and ran the official example - vue todos under Ubuntu 22.04. After the first run, I found that the toolbar displayed in a transparent color and the file name behind it. After switching the activation status of the window, the toolbar displayed normally
Reproduction
No response
Expected behavior
No response
Platform and versions

tauri "info"

Environment
› OS: Ubuntu 22.04 X64
› Node.js: 16.17.0
› npm: 8.15.0
› pnpm: 7.12.2
› yarn: 1.22.19
› rustup: 1.25.1
› rustc: 1.63.0
› cargo: 1.63.0
› Rust toolchain: stable-x86_64-unknown-linux-gnu
Packages
› @tauri-apps/cli [NPM]: 1.1.1
› @tauri-apps/api [NPM]: Not installed!
› tauri [RUST]: 1.1.1,
› tauri-build [RUST]: 1.1.1,
› tao [RUST]: 0.14.0,
› wry [RUST]: 0.21.1,
App
› build-type: bundle
› CSP: default-src blob: data: filesystem: ws: http: https: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
› distDir: ../dist
› devPath: http://localhost:3000/
› framework: Vue.js
App directory structure
├─ src-tauri
├─ docs
├─ public
├─ dist
├─ src
└─ node_modules
Stack trace
No response
Additional context
No response

Fixed in https://github.com/tauri-apps/tao/issues/567

authors: FabianLars qyvip


text:
Startup program crashes after packaging

Describe the bug
#![cfg_attr(
all(not(debug_assertions), target_os = "windows"),
windows_subsystem = "windows"
)]

use std::io::stdout;
use std::process::Command;

use std::{process, thread};
use std::os::windows::process::CommandExt;
use tauri::async_runtime::handle;
use tauri::{Manager, RunEvent};

fn main() {
	let mut child = Command::new("./src/server.exe").creation_flags(0x08000000)
		.spawn().expect("cmd exec error!");
	tauri::Builder::default()
		.plugin(tauri_plugin_single_instance::init(|app, _argv, _cwd| { //设置插件
			let window = app.get_window("main").unwrap(); //二次打开软件时，显示已打开窗口，单例运行app
			window.set_focus().unwrap();
			window.show().unwrap();
		}))
		.build(tauri::generate_context!())
		.expect("err building")
		.run(move |handle, event| match event {
			tauri::RunEvent::Ready => {
				println!("程序启动")
			}
			tauri::RunEvent::Exit => {
				child.kill().expect("!kill");
				println!("程序退出")
			}
			_ => ()
		});
}

When this code is commented out, it works fine
let mut child = Command::new("./src/server.exe").creation_flags(0x08000000)
		.spawn().expect("cmd exec error!");

Reproduction
No response
Expected behavior
No response
Platform and versions
1.0.1
Stack trace
No response
Additional context
No response

For future issues please add a proper description of the issue, and any errors you see. Also include the full output of tauri info as required in the issue templte.
The issue you're seeing here is most likely that the exe is missing afterwards. Command::new("./src/server.exe") this will always look for the file in a src/ folder relative to the main app which doesn't exist after bundling.
Take a look at this guide https://tauri.app/v1/guides/building/sidecar/ which automatically bundles the exe in your app bundle, it also sets the same creation flag.

Again, if you report errors please include the error messages in your comment, otherwise it makes it harder for us to help you because we (or i) don't always have access to a compiler.
Btw, you can remove the child.kill().expect() line since Tauri does this on Exit.

authors: FabianLars TheBlindM


text:
How to run

I'm trying to run after compilation on OpenSuse Tumbleweed and it is throwing the following error:
error: specify input device, e.g., found in /dev/input/by-id/.

Am I missing something? The ReadMe does not specify how to invoke the binary with any parameters.

And, to answer my own question (I've just switched to linux again after a while):
/dev/input/by-id contains a list of available input devices. One of those is a keyboard and points to the stream name (i.e. event2).
Adding /dev/input/event2 as a parameter works. Many thanks for this!

After passing this initial hurdle, it seems I can't get past
Cannot open any of the devices: Permission denied.

even though I've added my user to the input group and added the rule to /etc/udev/rules.d

After restart, it seems that the input group membership works.
Cannot open /dev/uinput: Permission denied.

Unfortunately, there is no uinput group so now I'm fiddling with the rule settings.

You need to create a uinput group in that case (as you did), add your user and set the rules as follows: https://github.com/tuomasjjrasanen/python-uinput/blob/master/udev-rules/40-uinput.rules

Thomas, thanks a lot for assistance.
I've added the following
SUBSYSTEM=="misc", KERNEL=="uinput", MODE="0660", GROUP="uinput"

to (a new file) /etc/udev/rules.d/40-uinput.rules.
After reboot I'm still getting Cannot open /dev/uinput: Permission denied.
At least it feels I'm closer to the goal. :)

There is a workaround by running ~/bin/dvorak /dev/input/event2 with sudo, of course.

Finally, after another reboot, /dev/uinput has the proper permissions assigned. Now I can run the command as an ordinary user.
Strangely, the shortcut keys do not work at all although they did when I initially tried it with sudo.

Got it, finally.
The keyboard has, in the meantime, change it's event number to event3 hence the run command did not work as it was referencing event2. Voila!

Updated installation instructions a bit as a result. Thanks!

authors: MisterY tbocek

repo: tbocek/dvorak


text:
Adding a platform function: tb_file_access

This patch adds a function named "tb_file_access" which is a wrapper of
the POSIX function "access".

帮忙吧 main.yml 的 ci 里面配置上
on:
  pull_request:
  push:
  release:
    types: [published]

触发下 ci build，确保正常编译能过

repo: tboox/tbox


text:
xmake timout on osx

Just seeing this, it does not not seems to append every time
$ xmake
checking for the architecture ... x86_64
checking for the Xcode application directory ... /Applications/Xcode.app
checking for the Xcode SDK version for macosx ... 10.12
checking for the target minimal version ... 10.12
configure
{
    arch = "x86_64"
,   ccache = true
,   target_minver = "10.12"
,   mode = "release"
,   plat = "macosx"
,   kind = "static"
,   buildir = "build"
,   xcode_sdkver = "10.12"
,   host = "macosx"
,   xcode_dir = "/Applications/Xcode.app"
}
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

This seems to be a problem of travis-ci, though I don't know why, but just here all jobs have the same problem

I tried to rollback to a previous normal commits in traivs-ci, but there's still this problem. 😢

Weird !

I have fixed it.

Cool :+1:

authors: uael waruqi

repo: tboox/xmake


text:
Handle FinalizationRegistry

This snapshots the ambient AC state when calling fr.register(), to be restored when invoking the FR's callback on that registered cell.

I also removed our changes of HostMakeJobCallback. First, because it felt awkward to refer to the JobCallback's [[AsyncContextSnapshot]] inside NewPromiseReactionJob and NewPromiseResolveThenableJob. And second, because it actually causes a memory leak with FinalizationRegistry.
The FR calls HostMakeJobCallback (causing it to snapshot) during its constructor to prepare the callback to be used for jobs later on. But that snapshot will never be used, we'll only use the registration time snapshot. So I had to move the snapshotting closer into PerformPromiseThen.

I thought this PR was meant to fix the regression introduced in #41. However, before #41, FinalizationRegistry callbacks were called with the FR construction context, rather than with the context at the time the register method was called. Have we actually discussed which should be the right behavior?
This is actually similar to some events in the web:
const asyncVar = new AsyncContext.Variable();

const image = document.getElementById("image");  // <img id="image">

asyncVar.run("foo", () => {
  image.addEventListener("load", () => {
    console.log(asyncVar.get());
  });
});

asyncVar.run("bar", () => {
  image.src = "./some/image.jpg";
});

Here we have a registration-time context (the registration of the load event, or the FR construction with a callback), and a separate context (the call to register, or the setting of the image's src) which asynchronously triggers the call to the registered callback.
It's not clear to me which of the two is the right behavior, and it clearly ties into the behavior of events in the HTML integration.

I remember this being discussed in Matrix. I believe register time is the correct one. Furthermore it's easy to do FR construction time by simply wrapping the callback.

I remember this being discussed in Matrix. I believe register time is the correct one. Furthermore it's easy to do FR construction time by simply wrapping the callback.

I think I misunderstood you when this was discussed, so I didn't realize there was a difference there wrt the previous behavior.
By the way, the terminology gets confusing here because for events, "registration-time" is the time at which you register the event by e.g. calling addEventListener, which would be equivalent to FR construction. Calling register would be an asynchronous kind of "call-time".

Edit: the other direction is more tricky, requiring to create a snapshot on registration, pass it in the held value, and run from the snapshot in the callback.

Spec-wise it's not more tricky, since the snapshot doesn't need to be held in the FR's [[Cells]]. In the current spec text, HostMakeJobCallback takes the snapshot and stores it alongside the callback, so it could be swapped in CleanupFinalizationRegistry() in the same way it is swapped in NewPromiseReactionJob.

By the way, the terminology gets confusing here because for events, "registration-time" is the time at which you register the event by e.g. calling addEventListener, which would be equivalent to FR construction. Calling register would be an asynchronous kind of "call-time".

Ah yes I meant FR register. It's not the same as addEventListener, but it's not equivalent an async dispatch either. IMO semantically it's more like addEventListener but with the event handler shared and added earlier.

Spec-wise it's not more tricky,

I was strictly taking the POV of the API consumer. It's harder to get the register time semantics manually.

the snapshot doesn't need to be held in the FR's [[Cells]]

I'm confused, if we want FR register time, doesn't the spec need to store the Snapshot in each cell?
I probably should read the PR

the snapshot doesn't need to be held in the FR's [[Cells]]

I'm confused, if we want FR register time, doesn't the spec need to store the Snapshot in each cell? I probably should read the PR

That is right, but I thought by "the other direction" you meant construction time.

I'd rather use the construction-time AsyncContext snapshot here, just for simplicity. Are there any cases that we're aware of where it's important to have the semantics described in this PR?

I think using construction-time is the incorrect choice, because observers like this (and DOM observers like MutationObserver) should be registered in the module scope. If it's in the module scope, the ambient context is just empty, and that's not useful.
I think choosing the context during the call to register is directly analogous to choosing the context when you attach an event listener. Andreu had brought up during last meeting that "registration-time" to him was when you passed the callback, but I think that's incorrect. Registration is when I invoke the method to be notified of a future event, eg fr.register() or el.addEventListener().

Not passing the callback at the time you register is a big difference from addEventListener. I think the consistency arguments can be made in both directions. Is there any actual utility to the semantics of this patch? If not, I really prefer the option which is simpler from an implementation and specification perspective. Note that it is always possible to build a wrapper around FinalizationRegistry which applies the semantics in this patch.
If we can’t come to a conclusion on this thread, let’s discuss this at the next AsyncContext meeting.

because observers like this (and DOM observers like MutationObserver) should be held in the module scope

Other observers batch things anyway (which FinalizationRegistry originally did as well, but was dropped at some point) so having a "registration time" for DOM observers is just a non-possibility anyway.

Other observers batch things anyway (which FinalizationRegistry was originally proposed to do as well, but was dropped at some point) so having a "registration time" for DOM observers is just a non-possibility anyway.

That's interesting. I've always assumed it only batched mutations per-observe calls (so two appendChilds on a subtree observe would only fire once per tick). I didn't all observe calls are invoked at once (so subtree observe and a separate attributes observe would also only fire once).
So it really isn't possible to automatically maintain "registration" time per observe call, and users that need it would have to use a separate WeakMap or something to handle Snapshots. Given that, I'm ok with either approach.

and users that need it would have to use a separate WeakMap

You don't even need to go that far.
class FinalizationRegistryWithSnapshot extends FinalizationRegistry {
  constructor(callback) {
    super(({snapshot, value}) => {
      snapshot.run(callback, value);
    })
  }
  register(target, value, token) {
    return super.register(target, {value, snapshot: new AsyncContext.Snapshot()}, token);
  }
}

In the AsyncContext call today, the group apparently decided on construction-time snapshot semantics. (Please correct me if I'm mistaken.)

You don't even need to go that far.

I was referencing MuationObserver in that comment, which would require a WeakMap to hold a #[element, registration-type] -> Snapshot mapping.

Updated to use creation-time context.

authors: Jamesernator andreubotella jridgewell littledan mhofman


text:
Normative: Parent completion ordering DFS invariant extension

This extension provides an approach to the case brought up in https://github.com/tc39/proposal-top-level-await/issues/158 where parent completion orderings entirely differing from the normal post-order execution might be seen as surprising behaviour.
This approach uses a new global execution ordering on async execution.
The async fulfillment is then split out into two separate phases: a first phase to gather the list of parent modules that are synchronously ready for execution at async fulfillment time of a dependent, and a second phase to execute this list in global execution-sorted order based on this ordering.
Async rejections are handled as previously.
This change only affects execution timings of deferred async executions, imposing this new post-ordering sort on them. If we consider module graphs where every module depends individually on a single module using top-level await, using the same well-defined post-order execution ordering on all sync parent subgraph execution completions that run together seems like a sensible adjustment to me to ensure predictable behaviour.
Further review / feedback very welcome. // cc @Ms2ger @littledan @MylesBorins @robpalme @sokra

Yulia: I think you've got more of the proposal paged in than me right now, so I'd appreciate it if you could take a look. Let me know if you prefer I try.

Yulia: I think you've got more of the proposal paged in than me right now, so I'd appreciate it if you could take a look. Let me know if you prefer I try.

I've rebased this to the PR bug fix in https://github.com/tc39/proposal-top-level-await/pull/159, and also separated out the cycle gathering on failure, as cycle errors are allowed to be sparse in the current TLA algorithm, it doesn't seem such an issue to ensure consistency by just relying on cycle root. Instead we can follow this up in a separate PR if necessary.
Thanks for feedback so far. The diff should now be a little simpler as well.

@jorendorff I've included your suggestions - brings the diff down nicely as well.

I've rebased this PR to the latest merge of the cycle root fix, should be much simpler to review. Further feedback welcome, I do think this is an important normative change to make. If it needs to go explicitly through the meeting that would be understandable.
Further feedback would be very welcome to understand implementer interest.

@syg it would be great to get your review on this PR if you're able to take a look.

(sorry about this) Ok, after thinking a bit more about this, what we are doing here is reverting a decision that was made earlier.
We are going from variant b (our current semantics)
(async () => {
  const [a, b, c] = await Promise.all([
    import('./a.mjs'),
    import('./b.mjs'),
    import('./c.mjs')
  ]);
  console.log(a, b, c);
})();

back to variant a:
(async () => {
  const a = await import('./a.mjs');
  const b = await import('./b.mjs');
  const c = await import('./c.mjs');

  console.log(a, b, c);
})();

Part of the motivation of this change is that this was an oversight, but I don't think so. We decided against this originally. The discussion is here: notesSlides
I don't know if it makes sense to rehash this -- Myles made a strong case for this synchronous behaviour based on the usecase.

Just to reiterate, this PR is only to ensure that all sync subgraphs that depend on async modules execute in the original ordering, and it doesn't affect any of the other execution properties of this proposal that have already been agreed.

I started implementing this an ran into a concern. I'd like the postorder position to be scoped to each top-level call to Evaluate(). However, this doesn't seem possible because the same async module can participate in concurrent, multiple top-level calls to Evaluate(), e.g. multiple <script> tags. That presents a problem: the postorder would need to be maintained as a global serial number or something, which puts it at higher risk of overflowing. There can be cleverer designs, I suppose, of resetting the global serial to 0 after all outstanding modules are finished, but that's too much complexity for my liking.

@syg nicely spotted - yes with the flattening of the previous recursive algorithm we need to now explicitly call the capabilities on the sync module parents of async modules.
Further to your suggestion, the fix can possibly actually resolve capabilities on all sync parents of async modules, as they could all have eg a later dynamic import expression that attached to those modules specifically. For this reason I've added the capability resolution within the main exec loop to all sync modules.
I also went ahead and moved the main "top level parent" capability resolution to the top, this is to ensure that the current module promise will resolve before the sync parent promises. Since all capability resolutions, I believe, wiill go into the task queue, the resolution functions can't be called synchronously. So having the capability resolution at the top should not break the sync invariant between the parent executions by calling a resolve function earlier than the parent executions. Please verify that I'm correct in that assumption though, and just let me know if further clarification would help.
Will also await on @codehag when she gets back for review before merging so we have time here too.

Further to your suggestion, the fix can possibly actually resolve capabilities on all sync parents of async modules, as they could all have eg a later dynamic import expression that attached to those modules specifically.

Great point!

If someone wants to an executable implementation in V8 to check things with, here's the CL: https://chromium-review.googlesource.com/c/v8/v8/+/2757901

If somebody knows how to build a node.js version from that, you could run https://github.com/evanw/tla-fuzzer with that change and check the result. That's how I found the original case.

I tested the patch in Node.js and can confirm it fixes https://github.com/tc39/proposal-top-level-await/issues/158 and has the correct timings for dynamic import registrations with the latest commit as well.

We've merged a test for the new semantics to Test262: https://github.com/tc39/test262/pull/2989

authors: Ms2ger codehag guybedford jugglinmike sokra syg


text:
Command line on newline

When hitting 'Enter' on a newline, the previous line is played again

gotcha https://docs.python.org/3/library/cmd.html#cmd.Cmd.emptyline

repo: tchapi/pianette


text:
error when exploring the data of a topic (works for other)

HQ
Error rendering Freemarker view [topic]: The following has evaluated to null or missing: ==> data.getKeyAsString() [in template "blocks/topic/dataBody.ftl" at line 32, column 80] ---- Tip: If the failing expression is known to legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing</#if>. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${data.getKeyAsString()} [in template "blocks/topic/dataBody.ftl" at line 32, column 78] - Reached through: #include "dataBody.ftl" [in template "blocks/topic/data.ftl" at line 144, column 13] - Reached through: #include "blocks/topic/data.ftl" [in template "topic.ftl" at line 48, column 13] ----
io.micronaut.views.exceptions.ViewRenderingException: Error rendering Freemarker view [topic]: The following has evaluated to null or missing:
==> data.getKeyAsString()  [in template "blocks/topic/dataBody.ftl" at line 32, column 80]

Tip: If the failing expression is known to legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing</#if>. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)??

FTL stack trace ("~" means nesting-related):
- Failed at: ${data.getKeyAsString()}  [in template "blocks/topic/dataBody.ftl" at line 32, column 78]
- Reached through: #include "dataBody.ftl"  [in template "blocks/topic/data.ftl" at line 144, column 13]
- Reached through: #include "blocks/topic/data.ftl"  [in template "topic.ftl" at line 48, column 13]
at io.micronaut.views.freemarker.FreemarkerViewsRenderer.lambda$render$0(FreemarkerViewsRenderer.java:98)
at io.micronaut.core.io.Writable.writeTo(Writable.java:74)
at io.micronaut.http.server.netty.RoutingInBoundHandler.encodeBodyAsByteBuf(RoutingInBoundHandler.java:1298)
at io.micronaut.http.server.netty.RoutingInBoundHandler.encodeBodyWithCodec(RoutingInBoundHandler.java:1255)
at io.micronaut.http.server.netty.RoutingInBoundHandler.lambda$subscribeToResponsePublisher$14(RoutingInBoundHandler.java:1190)
at io.reactivex.internal.operators.flowable.FlowableMap$MapSubscriber.onNext(FlowableMap.java:63)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap$SwitchMapSubscriber.drain(FlowableSwitchMap.java:307)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap$SwitchMapInnerSubscriber.onSubscribe(FlowableSwitchMap.java:366)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onSubscribe(InstrumentedSubscriber.java:75)
at io.reactivex.internal.operators.flowable.FlowableJust.subscribeActual(FlowableJust.java:34)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedCallableFlowable.subscribeActual(RxInstrumentedCallableFlowable.java:65)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap$SwitchMapSubscriber.onNext(FlowableSwitchMap.java:129)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.reactivex.internal.operators.flowable.FlowableSubscribeOn$SubscribeOnSubscriber.onNext(FlowableSubscribeOn.java:97)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.micronaut.http.context.ServerRequestTracingPublisher$1.lambda$onNext$1(ServerRequestTracingPublisher.java:60)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestTracingPublisher$1.onNext(ServerRequestTracingPublisher.java:60)
at io.micronaut.http.context.ServerRequestTracingPublisher$1.onNext(ServerRequestTracingPublisher.java:52)
at io.reactivex.internal.util.HalfSerializer.onNext(HalfSerializer.java:45)
at io.reactivex.internal.subscribers.StrictSubscriber.onNext(StrictSubscriber.java:97)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.reactivex.internal.operators.flowable.FlowableMap$MapSubscriber.onNext(FlowableMap.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap$SwitchMapSubscriber.drain(FlowableSwitchMap.java:307)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap$SwitchMapInnerSubscriber.onSubscribe(FlowableSwitchMap.java:366)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onSubscribe(InstrumentedSubscriber.java:75)
at io.reactivex.internal.operators.flowable.FlowableJust.subscribeActual(FlowableJust.java:34)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedCallableFlowable.subscribeActual(RxInstrumentedCallableFlowable.java:65)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap$SwitchMapSubscriber.onNext(FlowableSwitchMap.java:129)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.reactivex.internal.operators.flowable.FlowableSwitchIfEmpty$SwitchIfEmptySubscriber.onNext(FlowableSwitchIfEmpty.java:59)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap$SwitchMapSubscriber.drain(FlowableSwitchMap.java:307)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap$SwitchMapInnerSubscriber.onSubscribe(FlowableSwitchMap.java:366)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onSubscribe(InstrumentedSubscriber.java:75)
at io.reactivex.internal.operators.flowable.FlowableJust.subscribeActual(FlowableJust.java:34)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedCallableFlowable.subscribeActual(RxInstrumentedCallableFlowable.java:65)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap$SwitchMapSubscriber.onNext(FlowableSwitchMap.java:129)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.reactivex.internal.operators.flowable.FlowableSwitchIfEmpty$SwitchIfEmptySubscriber.onNext(FlowableSwitchIfEmpty.java:59)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.reactivex.internal.operators.flowable.FlowableMap$MapSubscriber.onNext(FlowableMap.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.lambda$onNext$0(InstrumentedSubscriber.java:80)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onNext(InstrumentedSubscriber.java:84)
at io.reactivex.internal.operators.flowable.FlowableCreate$NoOverflowBaseAsyncEmitter.onNext(FlowableCreate.java:403)
at io.micronaut.http.server.netty.RoutingInBoundHandler.lambda$buildResultEmitter$17(RoutingInBoundHandler.java:1380)
at io.reactivex.internal.operators.flowable.FlowableCreate.subscribeActual(FlowableCreate.java:71)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.internal.operators.flowable.FlowableMap.subscribeActual(FlowableMap.java:37)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.internal.operators.flowable.FlowableSwitchIfEmpty.subscribeActual(FlowableSwitchIfEmpty.java:32)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap.subscribeActual(FlowableSwitchMap.java:49)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.reactivex.internal.operators.flowable.FlowableDefer.subscribeActual(FlowableDefer.java:42)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.reactivex.internal.operators.flowable.FlowableSwitchIfEmpty$SwitchIfEmptySubscriber.onComplete(FlowableSwitchIfEmpty.java:71)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onComplete(InstrumentedSubscriber.java:112)
at io.reactivex.internal.operators.flowable.FlowableFlatMap$MergeSubscriber.drainLoop(FlowableFlatMap.java:426)
at io.reactivex.internal.operators.flowable.FlowableFlatMap$MergeSubscriber.drain(FlowableFlatMap.java:366)
at io.reactivex.internal.operators.flowable.FlowableFlatMap$MergeSubscriber.onComplete(FlowableFlatMap.java:338)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onComplete(InstrumentedSubscriber.java:112)
at io.reactivex.internal.operators.maybe.MaybeToFlowable$MaybeToFlowableSubscriber.onComplete(MaybeToFlowable.java:80)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.RxInstrumentedMaybeObserver.onComplete(RxInstrumentedMaybeObserver.java:92)
at io.reactivex.internal.operators.maybe.MaybeDoOnEvent$DoOnEventMaybeObserver.onComplete(MaybeDoOnEvent.java:115)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.RxInstrumentedMaybeObserver.onComplete(RxInstrumentedMaybeObserver.java:92)
at io.reactivex.internal.operators.flowable.FlowableElementAtMaybe$ElementAtSubscriber.onComplete(FlowableElementAtMaybe.java:102)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onComplete(InstrumentedSubscriber.java:112)
at io.reactivex.internal.operators.flowable.FlowableFlatMap$MergeSubscriber.drainLoop(FlowableFlatMap.java:426)
at io.reactivex.internal.operators.flowable.FlowableFlatMap$MergeSubscriber.drain(FlowableFlatMap.java:366)
at io.reactivex.internal.operators.flowable.FlowableFlatMap$MergeSubscriber.onComplete(FlowableFlatMap.java:338)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestContext.lambda$instrument$0(ServerRequestContext.java:68)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onComplete(InstrumentedSubscriber.java:112)
at io.reactivex.internal.operators.flowable.FlowableFromIterable$IteratorSubscription.slowPath(FlowableFromIterable.java:255)
at io.reactivex.internal.operators.flowable.FlowableFromIterable$BaseRangeSubscription.request(FlowableFromIterable.java:124)
at io.reactivex.internal.operators.flowable.FlowableFlatMap$MergeSubscriber.onSubscribe(FlowableFlatMap.java:117)
at io.micronaut.reactive.rxjava2.InstrumentedSubscriber.onSubscribe(InstrumentedSubscriber.java:75)
at io.reactivex.internal.operators.flowable.FlowableFromIterable.subscribe(FlowableFromIterable.java:69)
at io.reactivex.internal.operators.flowable.FlowableFromIterable.subscribeActual(FlowableFromIterable.java:47)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.internal.operators.flowable.FlowableFlatMap.subscribeActual(FlowableFlatMap.java:53)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.internal.operators.flowable.FlowableElementAtMaybe.subscribeActual(FlowableElementAtMaybe.java:36)
at io.reactivex.Maybe.subscribe(Maybe.java:4262)
at io.micronaut.reactive.rxjava2.RxInstrumentedMaybe.subscribeActual(RxInstrumentedMaybe.java:64)
at io.reactivex.Maybe.subscribe(Maybe.java:4262)
at io.reactivex.internal.operators.maybe.MaybeDoOnEvent.subscribeActual(MaybeDoOnEvent.java:39)
at io.reactivex.Maybe.subscribe(Maybe.java:4262)
at io.micronaut.reactive.rxjava2.RxInstrumentedMaybe.subscribeActual(RxInstrumentedMaybe.java:64)
at io.reactivex.Maybe.subscribe(Maybe.java:4262)
at io.reactivex.internal.operators.maybe.MaybeToFlowable.subscribeActual(MaybeToFlowable.java:45)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.internal.operators.flowable.FlowableFlatMap.subscribeActual(FlowableFlatMap.java:53)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.internal.operators.flowable.FlowableSwitchIfEmpty.subscribeActual(FlowableSwitchIfEmpty.java:32)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.internal.operators.flowable.FlowableSwitchMap.subscribeActual(FlowableSwitchMap.java:49)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.internal.operators.flowable.FlowableMap.subscribeActual(FlowableMap.java:37)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14755)
at io.micronaut.http.context.ServerRequestTracingPublisher.lambda$subscribe$0(ServerRequestTracingPublisher.java:52)
at io.micronaut.http.context.ServerRequestContext.with(ServerRequestContext.java:52)
at io.micronaut.http.context.ServerRequestTracingPublisher.subscribe(ServerRequestTracingPublisher.java:52)
at io.reactivex.internal.operators.flowable.FlowableFromPublisher.subscribeActual(FlowableFromPublisher.java:29)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.micronaut.reactive.rxjava2.RxInstrumentedFlowable.subscribeActual(RxInstrumentedFlowable.java:68)
at io.reactivex.Flowable.subscribe(Flowable.java:14805)
at io.reactivex.Flowable.subscribe(Flowable.java:14752)
at io.reactivex.internal.operators.flowable.FlowableSubscribeOn$SubscribeOnSubscriber.run(FlowableSubscribeOn.java:82)
at io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker$BooleanRunnable.run(ExecutorScheduler.java:288)
at io.reactivex.internal.schedulers.ExecutorScheduler$ExecutorWorker.run(ExecutorScheduler.java:253)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

Caused by: freemarker.core.InvalidReferenceException: The following has evaluated to null or missing:
==> data.getKeyAsString()  [in template "blocks/topic/dataBody.ftl" at line 32, column 80]

Tip: If the failing expression is known to legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing</#if>. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)??

FTL stack trace ("~" means nesting-related):
- Failed at: ${data.getKeyAsString()}  [in template "blocks/topic/dataBody.ftl" at line 32, column 78]
- Reached through: #include "dataBody.ftl"  [in template "blocks/topic/data.ftl" at line 144, column 13]
- Reached through: #include "blocks/topic/data.ftl"  [in template "topic.ftl" at line 48, column 13]
at freemarker.core.InvalidReferenceException.getInstance(InvalidReferenceException.java:134)
at freemarker.core.EvalUtil.coerceModelToTextualCommon(EvalUtil.java:467)
at freemarker.core.EvalUtil.coerceModelToStringOrMarkup(EvalUtil.java:389)
at freemarker.core.EvalUtil.coerceModelToStringOrMarkup(EvalUtil.java:358)
at freemarker.core.DollarVariable.calculateInterpolatedStringOrMarkup(DollarVariable.java:100)
at freemarker.core.DollarVariable.accept(DollarVariable.java:63)
at freemarker.core.Environment.visit(Environment.java:330)
at freemarker.core.Environment.visit(Environment.java:336)
at freemarker.core.Environment.visit(Environment.java:372)
at freemarker.core.IteratorBlock$IterationContext.executedNestedContentForCollOrSeqListing(IteratorBlock.java:317)
at freemarker.core.IteratorBlock$IterationContext.executeNestedContent(IteratorBlock.java:271)
at freemarker.core.IteratorBlock$IterationContext.accept(IteratorBlock.java:242)
at freemarker.core.Environment.visitIteratorBlock(Environment.java:642)
at freemarker.core.IteratorBlock.acceptWithResult(IteratorBlock.java:107)
at freemarker.core.IteratorBlock.accept(IteratorBlock.java:93)
at freemarker.core.Environment.visit(Environment.java:330)
at freemarker.core.Environment.visit(Environment.java:336)
at freemarker.core.Environment.include(Environment.java:2582)
at freemarker.core.Include.accept(Include.java:171)
at freemarker.core.Environment.visit(Environment.java:330)
at freemarker.core.Environment.visit(Environment.java:336)
at freemarker.core.Environment.include(Environment.java:2582)
at freemarker.core.Include.accept(Include.java:171)
at freemarker.core.Environment.visit(Environment.java:330)
at freemarker.core.Environment.visit(Environment.java:336)
at freemarker.core.Environment.visit(Environment.java:336)
at freemarker.core.Environment.process(Environment.java:309)
at freemarker.template.Template.process(Template.java:384)
at io.micronaut.views.freemarker.FreemarkerViewsRenderer.lambda$render$0(FreemarkerViewsRenderer.java:95)
... 213 more

Good catch :+1:
Thanks for the report

authors: ftardif tchiotludo

repo: tchiotludo/kafkahq


text:
Returns an Object of Data from the Links

Rather than having a single link, it will now return an object which can be traversed for more control over the data.

I would really need help in the unit tests....

repo: tcort/markdown-link-extractor

license: ISC


text:
Remove bitcoin/bitcoin prefix + remove superfluous word.

I'll let someone else merge this if they agree.

Cleaner. LGTM


text:
Loop issue

If you activate the loop mode on a sounds, double click it to run it then disable the loop sounds, the sounds goes on forever and we can't stop it anymore.
Solution
When a sounds is running in loop mode and you turn off the loop mode, simply stop looping it

Agree with that

Fixed in 1.3.

authors: tdimeco voxdei

repo: tdimeco/QuickSound


text:
Memory leak in java implementation?

First, thanks for making such an excellent toolkit!
There seems to be a possible memory leak or other finite memory related issue in the java implementation. I've found that when ingesting more than about 1M records (e.g. 1M works fine, but not 10M+), the JVM dies with java.lang.OutOfMemoryError: Java heap space.
We've taken care to avoid keeping such large datasets all in memory at once, and other operations (min/max/count/etc) seem to work fine so I'm fairly confident that this is specific to the t-digest implementation and not some other issue with how we're handling data.
Has anyone else run into this or found any sort of work around?

Tell me more.
Which digest are you using?
Have you turned on data recording by accident (most digests will record all
their input if asked, for debugging purposes)?
Can you make a test available to demonstrate the problem?
The production versions of t-digest (AvlTreeDigest and MergingDigest)
should be very well behaved. Memory for AvlTreeDigest should increase with
the log of  your input size, while MergingDigest should be absolutely
static in size with no allocation at all after initialization.
On Wed, Jun 13, 2018 at 8:02 PM Alexander Tronchin-James <
notifications@github.com> wrote:

First, thanks for making such an excellent toolkit!
There seems to be a possible memory leak or other finite memory related
issue in the java implementation. I've found that when ingesting more than
about 1M records (e.g. 1M works fine, but not 10M+), the JVM dies with java.lang.OutOfMemoryError:
Java heap space.
We've taken care to avoid keeping such large datasets all in memory at
once, and other operations (min/max/count/etc) seem to work fine so I'm
fairly confident that this is specific to the t-digest implementation and
not some other issue with how we're handling data.
Has anyone else run into this or found any sort of work around?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tdunning/t-digest/issues/111, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPSevjrwP-sjF9XnvrhxtKTxb9qY0gPks5t8VPEgaJpZM4Umq4t
.

Sorry for the false alarm, but I think the memory errors were unrelated to t-digest. Thanks for making this awesome tool!

authors: atronchi tdunning

repo: tdunning/t-digest


text:
Choose English spelling variant

In response to @gkampmeier comment: we need to choose a English spelling variant:

British English with "-ise"
British English with "-ize" (Oxford spelling)
American English

See this Wikipedia section on which organizations use what: e.g. International Organization for Standardization (ISO) uses British English with "-ize" and that is what I use as well.
We (website editors or @tdwg/exec) need to choose one soon and stick to it.

For what it's worth, GBIF follows UN spelling, so number 2.
http://dd.dgacm.org/editorialmanual/ed-guidelines/style/spelling.htm

I would go with option 2 as well
Kind regards,
Dimitris
--
Dr Dimitris Koureas, FLS
Head, Department of International Cooperation on Biodiversity
Infrastructures
*Naturalis Biodiversity Center *
P.O. Box 9517, 2300 RA Leiden, NL
Coordinator, Distributed System of Scientific Collections (DiSSCo
http://dissco.eu)
Chair, Biodiversity Information Standards Organisation (TDWG
http://tdwg.org)
ORCID: 0000-0002-4842-6487 | Linkedin: linkedin.com/in/dkoureas
Twitter: @DimitrisKoureas | Tel: +31 (0) 71 751 9251
Meeting requests https://doodle.com/dimitriskoureas
On 15 March 2018 at 15:07, Matt Blissett notifications@github.com wrote:

For what it's worth, GBIF follows UN spelling, so number 2.
http://dd.dgacm.org/editorialmanual/ed-guidelines/style/spelling.htm
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tdwg/website/issues/26#issuecomment-373387568, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALmnQGGmXT-t_3eTGzEo9J2IW_NmHu1Pks5tenWVgaJpZM4SsNS3
.

I'd say one more vote for option 2 and it is decided. 😄

option 2
On Thu, Mar 15, 2018 at 3:12 PM, Peter Desmet notifications@github.com
wrote:

I'd say one more vote for option 2 and it is decided. 😄
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tdwg/website/issues/26#issuecomment-373389165, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAOepZ-8yJJRKlZNnc-LPqDEYdpsTnV_ks5tena4gaJpZM4SsNS3
.

Added to contributing guide: https://github.com/tdwg/website/commit/a3e5d4ce2512f5b904c08d0a06334111a6a3d956

authors: MattBlissett dkoureas peterdesmet timrobertson100

repo: tdwg/website


text:
Enable server monitoring and backup

Pick a backup retention policy and enable the backups.
The playbook supports Borg, but maybe Azure Backups / snapshots of the VM are more practical.
Also enable some sort of monitoring.

[x] UptimeRobot
[ ] Backups


text:
Disable -> Clear PIN -> enable text on submit

What

Why

Test Plan

✅ | ❌ Not a front-end change
✅ | ❌ iOS QA Tests passed locally
✅ | ❌ Unit Tests passed locally

How

Current dependencies on/for this PR:

main

PR #76   👈

This comment was auto-generated by Graphite.

repo: teamforage/forage-ios-sdk


text:
🛑 API is down

In cd2557f, API (https://api.staging.greyfinch.com/healthz) was down:

HTTP code: 503
Response time: 77 ms

Resolved: API is back up in ba50109.

repo: teamgreyfinch/staging-status


text:
Strange bug with element.hover

I've come across a strange issue that has made my test suite unstable. element.hover occasionally fails to work and has a side effect.
After investigating various things, I inspected the element tag_name and text before calling element.hover and after. The element is changed to the html element after the call. This happens about 10% of the time.
Any insights into this behaviour? Those intermittent failing tests are driving me crazy.

Closing due to lack of response

authors: rahul-sekhar twalpole

repo: teampoltergeist/poltergeist


text:
Add user choice for SSH public keys upload

Problem
The script was automatically uploading all SSH public keys (id_*.pub) found in ~/.ssh without asking the user, which could potentially upload keys that weren't intended for GitHub.
Solution
Added an interactive prompt using gum choose that lets users decide:

Upload only primary keys (id_rsa.pub or id_ed25519.pub)
Upload all public keys (id_*.pub)
Skip the upload

Thank you

authors: mxcl stevenlei

repo: teaxyz/teaBASE