|
00:01
finanalyst left
02:06
guifa left
02:09
guifa joined
06:16
guifa left
|
|||
| Geth | rakudo/main: b6ea57833e | (Patrick Böker)++ | azure-pipelines.yml Get PRs working for everyone The `build.addbuildtag` command requires special permissions of the PR creator. Effectively failing PRs for many people. Thus that command is not suitable in a public CI pipeline. |
09:21 | |
| rakudo/main: 49d06524d0 | (Patrick Böker)++ (committed using GitHub Web editor) | azure-pipelines.yml Merge pull request #5753 from patrickbkr/make-PRs-work-for-everyone Get PRs working for everyone |
|||
| nqp/main: 6dd486179d | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION Bump MoarVM for fallthru fixes |
09:24 | ||
| rakudo/main: 6363b8e176 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP to get MoarVM fallthru fixes |
09:34 | ||
|
09:54
sena_kun joined
10:03
finanalyst joined
10:04
finanalyst left
10:05
finanalyst joined
11:12
finanalyst left
13:22
guifa joined
13:59
guifa left
14:01
guifa joined
17:00
MasterDuke joined
|
|||
| MasterDuke | committable6: releases my @a; my $t = now; for ^10 { @a.push:$_ }; say now - $t; say @a[2] | 17:01 | |
| committable6 | MasterDuke, gist.github.com/bf8afbb4dad4ead0e0...6ca281b19a | 17:02 | |
| MasterDuke | committable6: releases my @a; for ^10 { @a.push:$_ }; say @a[2] | ||
| committable6 | MasterDuke, ¦releases (86 commits): «(Any)» | 17:03 | |
|
17:14
MasterDuke left
|
|||
| Geth | rakudo/ugexe/deprecate-multi-file-operations: d308e3e482 | (Nick Logan)++ (committed by ab5tract) | 5 files Deprecate IO subs that operate on multiple paths in 6.e While convienient, being able to pass multiple paths to e.g. &rmdir is problematic because there isn't a blessed way to handle what to do when an exception or failure occurs, i.e. should it try to rmdir every entry even if some things fail, or stop on the first failure? ... (24 more lines) |
17:17 | |
| rakudo/ugexe/deprecate-multi-file-operations: acdb021d9a | (Nick Logan)++ (committed by ab5tract) | 5 files Deprecate IO subs that operate on multiple paths in 6.e While convienient, being able to pass multiple paths to e.g. &rmdir is problematic because there isn't a blessed way to handle what to do when an exception or failure occurs, i.e. should it try to rmdir every entry even if some things fail, or stop on the first failure? ... (24 more lines) |
18:47 | ||
| ab5tract | freaking Windows... | 19:03 | |
| Geth | rakudo/main: 8991173fcf | (Christian Bartolomäus)++ (committed using GitHub Web editor) | src/Perl6/bootstrap.c/BOOTSTRAP.nqp [JVM] Reduce backend-specific code in find_best_dispatchee (#5714) This is a follow-up to fa853abc7f which reverted 99f52bcd75 for the JVM backend. From what I understand the cause of the breakage on the JVM was the the removal of the call to nqp::hllizefor in 99f52bcd75. I'm not sure ... (14 more lines) |
19:06 | |
| jdv | i used to work in a window factory which is the only gig ive worked at a 100% m$ shop | ||
| rakudo/ugexe/deprecate-multi-file-operations: ed7c6651e8 | (Nick Logan)++ (committed by ab5tract) | 5 files Deprecate IO subs that operate on multiple paths in 6.e While convienient, being able to pass multiple paths to e.g. &rmdir is problematic because there isn't a blessed way to handle what to do when an exception or failure occurs, i.e. should it try to rmdir every entry even if some things fail, or stop on the first failure? ... (24 more lines) |
|||
| jdv | useless info for the day | ||
| ab5tract | jdv: the fact that you lived to tell the tale is useful information :) | ||
| jdv | ha, i guess | 19:08 | |
| Geth | rakudo/ugexe/deprecate-multi-file-operations: 0cc1a84581 | (Nick Logan)++ (committed by ab5tract) | 5 files Deprecate IO subs that operate on multiple paths in 6.e While convienient, being able to pass multiple paths to e.g. &rmdir is problematic because there isn't a blessed way to handle what to do when an exception or failure occurs, i.e. should it try to rmdir every entry even if some things fail, or stop on the first failure? ... (24 more lines) |
19:26 | |
| ab5tract | .... How does this work? 100% of tests passed, but still failed? usercontent.irccloud-cdn.com/file/.../image.png | 19:55 | |
| [Coke] | in tap, that could be wrong number of tests run | 19:57 | |
| lizmat | or no "done-testing" without a plan | 20:01 | |
| ab5tract | hmm... but that shouldn't be the case here, unless a new test file in t/02-rakudo needs to be manually registered somewhere... And it was succeeding in just a previous run. | 20:04 | |
| I'll kick it and see if it flaps | |||
| Geth | rakudo/ugexe/deprecate-multi-file-operations: 1f3e360c62 | (Nick Logan)++ (committed by ab5tract) | 5 files Deprecate IO subs that operate on multiple paths in 6.e While convienient, being able to pass multiple paths to e.g. &rmdir is problematic because there isn't a blessed way to handle what to do when an exception or failure occurs, i.e. should it try to rmdir every entry even if some things fail, or stop on the first failure? ... (24 more lines) |
20:05 | |
| lizmat | ab5tract: also, all test pass, but on the MoarVM teardown something happens that causes a non-zero exit code | ||
| such as a segfault | |||
| I've seen that | |||
| ab5tract | hmm, ok that would make sense too | ||
| Unrelated to the previous query, but I'm wondering whether it is possible that we are returning different values for chown on Windows vs Linux | 20:07 | ||
| m: say chown("/tmp/nonexistent", "/tmp/also-nonexistent", :uid(111), :gid(222)) ~~ [] | |||
| camelia | True | 20:08 | |
| ab5tract | that apparently returns False on Windows :S | ||
| (if I'm reading the test outputs right) | |||
| lizmat | uid and gid on Windows are really iffy | ||
| ab5tract | yeah, I figured as much. But when then I'd still expect the code to produce an empty array for two failures (in the old code path) | 20:09 | |
| lizmat | only recently I've made $*USER return something sensible | 20:10 | |
| on Windows | |||
| ugexe | it could also potentially be related to the addition of the file-stat syscall that was added github.com/rakudo/rakudo/blob/8991...kumod#L494 | 20:11 | |
| as in a source of potentially odd guid and uid values | 20:12 | ||
| ab5tract | Maybe I should just flub those tests for Windows then.. | 20:14 | |
| ugexe | actually the syscall thing shouldnt have anything to do with it since that is only used when the uid and gid are not provided | 20:15 | |
| Geth | rakudo/ugexe/deprecate-multi-file-operations: 95bb11b83f | (Nick Logan)++ (committed by ab5tract) | 5 files Deprecate IO subs that operate on multiple paths in 6.e While convienient, being able to pass multiple paths to e.g. &rmdir is problematic because there isn't a blessed way to handle what to do when an exception or failure occurs, i.e. should it try to rmdir every entry even if some things fail, or stop on the first failure? ... (24 more lines) |
20:23 | |
| ugexe | i suspect chown on windows is a no-op, but that we are missing a piece where we check the file for existence first | 20:32 | |
| for nodejs i think that might be handled by this check that the user has write permissions to the file first - github.com/nodejs/node/blob/a34430...2869-L2873 | 20:37 | ||
| for our case we can probably just make that file-stat syscall unconditionally and check that. it will already throw an error if the path doesnt exist i think | 20:38 | ||
|
20:40
finanalyst joined
|
|||
| ab5tract | ugexe: so looking the IO::Path source, the file-stat does seem to be unconditional already. But the result is only used in a few 'stat-flags' calls for UID/GID. Is your suggestion to add an additional flag check for file existence? | 20:50 | |
| Unfortunately I'm a bit lost in connecting the Node source code to the syscalls in IO::Path | |||
| ugexe | ah i was thinking one of those would emit the "Failed to stat file: no such file or directory" error but i guess i was wrong | 20:54 | |
| although I suppose that data already exists in the result of that file-stat call | |||
| Geth | rakudo/ugexe/deprecate-multi-file-operations: ace48c2486 | ab5tract++ | src/core.c/IO/Path.rakumod Check for file existence first |
20:55 | |
| ugexe | the line using uv_fs_chown is on line 2876. i linked to line 2869. between those two lines there is only one significant thing that happens, that call to THROW_IF_INSUFFICIENT_PERMISSIONS | 20:56 | |
| i'm presuming that has to stat the file or something to check if it has sufficient permissions, and on windows if the file does not exist that would fail | |||
| and never reach the uv_fs_chown call at all | 20:57 | ||
| Geth | rakudo/ugexe/deprecate-multi-file-operations: efbf3e411c | ab5tract++ | 2 files Check for file existence first |
21:04 | |
| ugexe | thats fine but i think the better solution would be to check $stat to avoid the extra syscalls | 21:07 | |
| with the .e the file ends up getting stat-ed multiple times presumably, once with the call to .e, and once with the file-stat | 21:08 | ||
| (and avoiding that scenario is what file-stat was implemented for) | 21:09 | ||
| ab5tract | ugexe: yeah makes sense. I figured this would help verify that solution first | 21:14 | |
| and maybe make it work across moarvm + JVM at the same time | 21:15 | ||
| ugexe | presumably jvm has no problem | 21:16 | |
| but im just guessing. the core of the issue is libuv uv_fs_chown is a noop on windows | |||
| nqp::syscall("stat-flags", $stat, nqp::const::STAT_EXISTS) fwiw | 21:19 | ||
| Geth | rakudo/ugexe/deprecate-multi-file-operations: d5f6baa6c3 | ab5tract++ | 3 files Check for file existence first |
21:20 | |
| ab5tract | should have waited to push until migrating to checking the result of the stat call | 21:21 | |
| Geth | rakudo/ugexe/deprecate-multi-file-operations: da28b2e7dc | ab5tract++ | 3 files Check for file existence first |
21:25 | |
| ab5tract | FWIW, I'm not sure that Win_JVM actuallty runs tests .. | 21:30 | |
| I hope I don't jinx anything by saying this, but I think we've finally got it :) | 21:41 | ||
| guifa | speaking of the JVM --- where do hold the sys calls ? | 21:54 | |
| ab5tract | ugexe: Looks like the PR has gone green once again | 22:13 | |
| timo | guifa: pardon? | 22:19 | |
| guifa | timo: so in MoarVM there's a bunch of syscalls, called from NQP fairly directly with nqp::syscall(...). Where do those reside in our code for JVM (and for JS as well)? So I can bring over my multicast code to the other ones too | 22:29 | |
| timo | they don't have an equivalent, but also they don't need to, their implementations of nqp ops go much more directly to functions being called without going through some kind of bytecode like MBC | 22:30 | |
|
22:34
kjp left
22:36
kjp joined
22:38
kjp left,
kjp joined
|
|||
| guifa | hmm okay | 23:01 | |
| ab5tract | It would be nice to be able to develop reasonable analogs | 23:17 | |
| So that we don’t have to diverge | |||
| IIUC guifa would need to implement some NQP functions to do the work on JVM, etc | 23:18 | ||
| Then these functions are VM specific, which feels wrong | 23:19 | ||
|
23:19
sena_kun left
|
|||
| timo | yeah, they would become nqp::blabla ops from the perspective of the code inside rakudo or nqp | 23:20 | |
| but we can also support nqp::syscall("blabla", ...) to just mean nqp::blabla(...) for a set of names | |||
| guifa | So in Rakudo I just see nqp::foo, I guess I'm trying to figure out how to locate that code in JVM. | 23:25 | |
| but I admit I'm probably going a bit over my head | |||
| guifa also hates Java haha | 23:26 | ||
| timo | github.com/raku/nqp/blob/9a843dc6e...#L536-L537 <- github.com/raku/nqp/blob/9a843dc6e....nqp#L2399 | 23:36 | |
