eveo | Thanks. Fixed. | 01:06 | |
ugexe | eveo: github.com/labster/p6-file-directo...730005bR28 | 02:41 | |
(thats line 28 if not clear) | |||
windows blows up there... dunno if its supposed to or not | |||
Failed to create directory 'C:\Users\Nick\AppData\Local\Temp\file-directory-tree-module-tests\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a\a' with mode '0o777': Failed to mkdir: 206 | 02:42 | ||
must be the path limit length | 02:45 | ||
geekosaur | isn't there like a 64 character limit without using the new format and the APIs that support it? | 02:50 | |
ugexe | the above is 249 characters | 02:51 | |
but yeah its probably a limitation from the dos subsystem | 02:52 | ||
i would have thought that got avoided though, since we can get around other limitations from that like what is allowed in a file name | 02:54 | ||
geekosaur | ohh, it's actually 260 without the \\?\ thing | ||
amusingly it's often 255 *with* \\?\ | 02:55 | ||
ugexe | heh, ecosystem needs a Spec::UNC | ||
geekosaur | (has to be a new enough NTFS to support more) | 02:56 | |
ugexe | i wonder what happens if your home directory is over 260 characters | 03:01 | |
BenGoldberg gives up for the night. | 03:46 | ||
[Tux] | This is Rakudo version 2017.05-452-gcc4d9091d built on MoarVM version 2017.05-100-g5ea6aaab | 06:36 | |
csv-ip5xs 2.523 | |||
test 12.557 | |||
test-t 4.071 - 4.293 | |||
csv-parser 12.561 | |||
samcv | ugexe, i'm sure things would randomly freeze. anything not using the newer api heh | 06:51 | |
Geth | rakudo/nom: 96e6b338c1 | (Samantha McVey)++ | src/Perl6/ModuleLoader.nqp Fix ModuleLoader.nqp so RAKUDO_MODULE_DEBUG works the same as elsewhere Fixes a bug that would cause Rakudo to die during compilation if RAKUDO_MODULE_DEBUG were set to anything other than a number. This was discovered by the Rakudo AppImage builder here: travis-ci.org/samcv/rakudo-appimag...2276#L1204 ... (10 more lines) |
07:49 | |
rakudo/nom: 5facb268e4 | niner++ (committed using GitHub Web editor) | src/Perl6/ModuleLoader.nqp Merge pull request #1101 from samcv/RAKUDO_MODULE_DEBUG Fix ModuleLoader.nqp so RAKUDO_MODULE_DEBUG works the same as elsewhere |
|||
samcv | thanks nine | 07:51 | |
dogbert17_ | [Tux]: impressive timings, maybe jnthn will bring test-t under 4 secs today :) | 09:45 | |
nine | Sadly csv-ip5xs is still quite a bit slower than it used to be. | 10:01 | |
dogbert17_ | nine: any idea what might have happened with it? | 10:03 | |
nine | dogbert17_: none at all :/ | ||
dogbert17_ | :( | 10:04 | |
and how's your Ryzen rig performing? | |||
nine | dogbert17_: just excellent :) The random freezes I had initially once or twice a week seem to have vanished with some update. Thing is just that now that I cannot hear my computer anymore, I've noticed a lot of noises my flat makes by itself. | 10:28 | |
Probably from the ventilation system | |||
Good stuff on benchmarks: perf.readthedocs.io/en/latest/system.html | 10:50 | ||
eveo | ugexe: sent a PR to just skip that test on Windows: github.com/labster/p6-file-directo...ee/pull/11 | 10:53 | |
buggable: speed 6 | 10:56 | ||
buggable | eveo, ▆▆▃█▄▁ data for 2017-06-14–2017-06-16; range: 4.071s–4.533s; 7% faster | ||
eveo | w00t | ||
dogbert17_ | eveo: I'm seeing failures in t/spec/S32-io/pipe.t. Is that something you have noticed? | 12:20 | |
eveo | I saw it flop but no failures | 12:21 | |
lizmat also saw it flap a few times | |||
Failed tests: 12-13 | |||
dogbert17_ | same here | ||
lizmat | m: sub a(+@a) { say @a.iterator.is-lazy }; a ^Inf # this feels wrong | 12:52 | |
camelia | False | ||
lizmat | m: my $s = Set.new(my $ = 42); $_ = 0 for $s.keys; dd $s # so much for immutability | 12:59 | |
camelia | Set $s = set(0) | ||
lizmat is fixing | 13:03 | ||
[Coke] | I started seeing the proc piping failure errors locally | 13:10 | |
MasterDuke | i don't suppose there's a perl6 builtin i don't know about that will condense a list of numbers into a list of numbers and Ranges where the original numbers are contiguous? | 13:13 | |
[Coke] doesn't think so. | 13:14 | ||
you want to turn 1,4,5,2,3 into 1..5 ? | 13:25 | ||
timotimo | so .minmax? | ||
[Coke] | timotimo: that doesn't help collapse ranges. | ||
timotimo | well, you'd have to also check if all parts are contiguous | ||
[Coke] | m: say (1,3,4,5).minmax ; say (1,2,3,4,5).minmax | 13:26 | |
camelia | 1..5 1..5 |
||
[Coke] | right. so no, no builtin. but it seems like a SMOP (esp. if your input is sorted) | 13:27 | |
timotimo | right | ||
[Coke] | jj/win 3 | 13:33 | |
lizmat | MasterDuke: gist.github.com/lizmat/063358317dc...01de1c2687 :-) | 13:46 | |
.oO( it's been a while I coded without nqp:: ;-) |
13:47 | ||
.tell MasterDuke gist.github.com/lizmat/063358317dc...01de1c2687 :-) | 13:48 | ||
yoleaux | lizmat: I'll pass your message to MasterDuke. | ||
lizmat | afk& | 13:53 | |
Geth | rakudo/nom: 3267386b70 | (Elizabeth Mattijsen)++ | src/core/Rakudo/QuantHash.pm Introducing R:Q.ADD-ITERATOR-TO-SET Abstracted Set.new logic, with decont() fix applied. |
13:58 | |
rakudo/nom: aa5d6f5460 | (Elizabeth Mattijsen)++ | src/core/Setty.pm Use new R:Q.ADD-ITERATOR-TO-SET Also fixes problem with values not being deconted. |
|||
lizmat | really afk& | ||
eveo | hmmm | 15:53 | |
C:\Temp\zef>zef install Inline::Perl5 | |||
===SORRY!=== | |||
Failed to rename 'C:\Users\zoffi\.perl6\precomp\2A37703AAE6EC1F1B73611353136DF8699DEDD67.1497625661.30178\D3\D3EDFFC895935AACCE255AE00550C10AD9162CE3.tmp' to 'C:\Users\zoffi\.perl6\precomp\2A37703AAE6EC1F1B73611353136DF8699DEDD67.1497625661.30178\D3\D3EDFFC895935AACCE255AE00550C10AD9162CE3': Failed to rename file: operation not permitted | |||
C:\Temp\zef>perl6 -v | 15:54 | ||
This is Rakudo version 2017.05-456-gaa5d6f5 built on MoarVM version 2017.05-100-g5ea6aaa | |||
timotimo | can that error mean something unexpected? | ||
like "that file already exists"? | |||
eveo | more likely it means "filehandle isn't closed yet, so OS won't let you rename it" | 15:55 | |
timotimo | ah | 15:57 | |
ugexe | i think its permissions, ive been trying to track that bug down | ||
timotimo | is it sort of like a heisenbug? | ||
ugexe | i went through all the CUR sources and added :close to all the slurps, but it didnt help | ||
no, it happens every time | |||
timotimo | damn | ||
otherwise we could have tried it multiple times in a for loop ... | 15:58 | ||
eveo | definitely a release blocker then :( | ||
timotimo | there must be a strace-like for windows, a log from that could surely be helpful? | ||
ugexe | github.com/rakudo/rakudo/blob/nom/...le.pm#L227 | ||
thats where it happens | 15:59 | ||
timotimo | (it'd also show information about where things happen if we leave in rakudo module debug or --verbose for zef or something) | ||
could it be something's running in parallel? | |||
ugexe | i cant test just this second, but i wonder if running the command prompt as administrator and trying it would work | 16:00 | |
timotimo | the filenames are based on contents only, right? | ||
jnthn | Every time I saw an issue like that, it was about file handle not closed, fwiw | ||
eveo | ugexe: same issue as admin | 16:01 | |
ugexe | if true then the proc changes are somehow leaving an open handle during precomp that they did not before | 16:03 | |
or is an open proc holding a handle still somehow | |||
eveo digs into it | 16:06 | ||
It's lunch time and I could use a nice juicy bug desert | |||
ZofBot: om nom nom nom | |||
ZofBot | eveo, (This has already happened with the circled numbers, for instance!) For such ranges, Perl will pretend that the characters are contiguous for calculating successors and predecessors, and will fail if you run off of either end | ||
eveo | ugexe: how did you find out that was the line where it dies? I added some print statements around it and looks like it's dying elsewhere | 16:25 | |
ugexe | looked at the last line of RAKUDO_MODULE_DEBUG=1 and followed the logic to the rename | 16:26 | |
eveo | Ah | ||
hehe. On Windows I get sub-60-second parse time. Faster build time than even on my 24-core box... Sounds like I should move to Windows as default rakudo dev env | 16:52 | ||
ugexe | windows is slow at lot of stuff though | 16:55 | |
process launching seems especially slow | |||
*seems* - naturally i have never quantified this other than how long zef takes to install | 16:56 | ||
github.com/rakudo/rakudo/blob/nom/...oc.pm#L127 - if we are doing this (allowing an %*ENV to affect process spawning) maybe we should go all the way and add a PERL6SHELL (perl5 has a similar one; only for windows) | 17:02 | ||
PERL5SHELL for windows defaults to `cmd /c /x` fwiw (we aren't using /x) | 17:05 | ||
eveo | nooooo | 17:13 | |
Geth quit | |||
Damn. Over a month of uptime | |||
I think people using the toaster that noms too much ram caused it | |||
ugexe | how can people use the toaster? | 17:15 | |
timotimo | go to its website | 17:16 | |
eveo | depends on what you mean by "use" | 17:17 | |
The data is on toast.perl6.party/ | |||
But if you want to toast, get github.com/zoffixznet/perl6-Toaster and run ./toast | |||
ugexe | ah, so the website is using up too much ram? or someone running a toaster instance on the same server? | 17:18 | |
im just trying to parse whats using too much ram :x | 17:19 | ||
eveo | ugexe: the website. It's running my off-the-hip Perl 6 web app and I think something in DBIish module is keeping stuff around that it's not meant to keep | 17:20 | |
hm, Geth is still running, just not connected to IRC. | 17:21 | ||
eveo waits a bit | |||
ugexe | ah. fwiw heres another variant of off-the-hip perl6 web app tony-o posted the other day gist.github.com/tony-o/06833c25519...07def5ae63 | ||
timotimo | eveo: what's the difference between unkn and unknown? | 17:24 | |
is one a known unknown and the other is an unknown unknown? | |||
eveo | oh hehe | 17:25 | |
timotimo: I think Unkn is when a proc exited with non-zero status, but there were no "FAIL" messages and Unknown is when the run never happened (probably because I placed the module into exclusion list, for hanging) | 17:26 | ||
Yeah, that seems to be it | 17:27 | ||
timotimo | i see | 17:29 | |
i expect you'll be adding a tiny note to explain that to the site? | |||
eveo | Nah, I'll fix "Unknown" to read "No data" or something along those lines | ||
timotimo | that's good, too | ||
[Coke] | eveo++ getting all the shit done | 17:44 | |
timotimo | yes \o/ | 17:45 | |
eveo | Still no Geth... oh well, there goes the uptime | ||
timotimo | d'oh :| | ||
got any logs that might tell us what's wrong? | |||
eveo | Probably some IRC events IRC::Client is failing to handle properly | 17:46 | |
or at all :) | |||
Geth: uptime | |||
Geth | eveo, 33 seconds | ||
perlpilot | eveo++ yeah, what Coke said | ||
ugexe | i wonder if changing those 2 renames (both for completeness) to `try { ... }` would work as a temp fix | 17:50 | |
or maybe thats what it really should be, and throw a warning instead (if code still otherwise works being loaded from source) | 17:52 | ||
eveo | It wasn't needed before, so there's some more serious problem happening. | 17:58 | |
It goes to rename the same file 23 times while installing Inline::Perl5... that's not normal, is it? | |||
ugexe | i dont think so... we need a RAKUDO_MODULE_DEBUG=1 output differ | 17:59 | |
eveo | Looks like the issue's got nothing to do with precomp or or proc refactors. Still exists on a commit from 18 days ago | 18:16 | |
eveo builds olders tuff | |||
dogbert17 couldn't even install Inline::Perl5, it crapped out with '/usr/bin/ld: cannot find -lperl' | 18:33 | ||
ugexe | i've installed inline::perl5 ok | 18:37 | |
dogbert17 | could my error be that there's some lib missing perhaps | ||
eveo | ugexe: on Windows? | 18:39 | |
ugexe: which module were failing for you with rename thing on Windows, BTW? | 18:40 | ||
ugexe | inline::perl5 im talking about linux | ||
eveo | hm, trying to repro the rename problem on 2017.05 drops me into some powershell stuff when running `zef install Inline::Perl5` :S | 18:41 | |
oh it continued running... but failed eventually, though not with the rename thing | 18:42 | ||
ugexe | windows the two I know of are 1) install zef and then do `zef ...` 2) git clone github.com/ugexe/Perl6-App--ecogen running bin/ecogen locally with -Ilib more than once | 18:43 | |
eveo | just died of Unhandled exception: failed to load library 'dynext/perl6_ops_moar.dll' | ||
ugexe: that gives the rename issue? | 18:44 | ||
man, lengthy build times wear out | 18:46 | ||
ugexe | well it did on my windows vm, but its not on a windows workstation | ||
eveo | I'm not having issues with ecogen | 18:56 | |
I think I'm just gonna give up with this one. | |||
dogbert17 | m: say [^3].tail | 19:04 | |
camelia | 2 | ||
dogbert17 | m: say [^3].tail(1) # why the difference, are different tails called? | 19:05 | |
camelia | (2) | ||
lizmat | dogbert17: because you can also specify a number > 1 there, it needs to return a Seq for that | ||
m: my $count =1; dd [^3].tail($count) | 19:06 | ||
camelia | (2,).Seq | ||
dogbert17 | lizmat: but are they both calling the same method | ||
lizmat | m: my $count = 2; dd [^3].tail($count) | ||
camelia | (1, 2).Seq | ||
lizmat | dogbert17: no, there are different candidates for tail() and tail(N) | 19:07 | |
dogbert17 | in Array.pm we have 'multi method tail(Array:D: $n)' | ||
will that be called if no argument is given? | |||
dogbert17 just trying to get to grips with the nuances so I can doc it | 19:08 | ||
[Coke] | seen in zef: "Failed to update p6c mirror No such method 'IO' for invocant of type 'Any'" | ||
dogbert17 | lizmat: my bad, didn't se your candidate reply | 19:09 | |
lizmat | dogbert17: one could argue that Array.tail() should be a candidate as well | ||
dogbert17 | the candidate without a count, is that in Any? | ||
lizmat | but the no-param case is handled by tail in Any-iterable-methods.pm | ||
dogbert17 | so if I doc it, should I mention both candidates or only the one with a count? | 19:10 | |
lizmat | from a doc point of view, they should both be documented | 19:11 | |
dogbert17 | in Array.pod6? | ||
lizmat | well, I'm not sure: where are things like .grep and .first documented? | 19:12 | |
[Coke] | are we testing that the various signatures exist explicitly, or that, for example, an arg is effective optional? | ||
lizmat | are they mentioned in Array.pod6 ? | ||
dogbert17 | no | ||
[Coke] | I wouldn't lock in detail in the docs that isn't required if we don't have to. | ||
dogbert17 | tail is documented in List.pod6 | ||
lizmat | then I wouldn't document it in Array | ||
dogbert17 | ok, makes my job easier :) | 19:13 | |
lizmat | the fact that it exists in Array.pm is an optimization, not a specific feature | ||
dogbert17 | ah, cool | ||
eveo | greppable6: Build\.pm | 19:14 | |
greppable6 | eveo, gist.github.com/026bd641e7da675401...93cb4a950c | ||
dogbert17 | lizmat: do you have any opinions about docs.perl6.org/language/typesystem..._is_nodal, is there anything that has been overlooked there? | 19:16 | |
eveo | I guess I should rewrite toaster to use a perl5 app for the time being. I can't keep restarting it every half hour :P | ||
lizmat looks | 19:17 | ||
dogbert17 | eveo: why do you have to restart it, memory? | ||
lizmat | dogbert17: what I always find confusing with these examples, is that the last value is also the number of elements | 19:18 | |
but I guess there's no way around it | |||
dogbert17 | what about the textual description | 19:19 | |
lizmat | dogbert17: so, yes, I think that makes it clear and nothing was omitted that I can think of right now | ||
dogbert17 | cool, then I will close a doc issue | ||
lizmat | dogbert17: s/ which is not/which is not nodal/ | 19:20 | |
to drive the point :-) | |||
in literature, I think the redundancy would be troubling, but I feel that in documentation you cannot be explicit enough | |||
dogbert17 | lizmat: thx, will fix | 19:21 | |
lizmat | not all people reading the doc have had english as their first language | ||
(and that include me :-) | |||
dogbert17 and me :) | |||
eveo | .ask nine are you around by any chance? Does this MODULE_DEBUG output tell you anything why on windows even `zef --help` fails with some kind of rename issue. The code that writes to the file in question definitely closes it: gist.github.com/zoffixznet/87541b1...18235238e0 | ||
yoleaux | eveo: I'll pass your message to nine. | ||
eveo | hmmm.... but is the file that somehow creating the file it's being renamed to already closes it... | 19:22 | |
lizmat just pushd github.com/rakudo/rakudo/commit/b5...f9364a5808 # Geth being incommunicado | 19:24 | ||
eveo | hmm.. ."[ERROR] [22084] [17] No such method 'slurp-rest' for invocant of type 'Any' in sub at /home/zoffix/services/geth/lib/Geth/GitHub/Hooks.pm6 (Geth::GitHub::Hooks) line 28" | 19:25 | |
It's now running on updated perl6. I do hope it's just a missing module :/ | |||
dogbert17 notes that Geth has left #perl6 | 19:27 | ||
eveo | oh, but then it wouldn't even start | ||
oh god, it's the web guys changing the API without concern for the users :/ line 28 is HTTP::Server::Tiny | |||
I mean $env<p6sgi.input>.slurp-rest; | |||
They already broke my other app | 19:28 | ||
dogbert17 | Geth++ | 19:29 | |
eveo | Serious? They simply renamed it to "p6w.input"? | ||
and zofbot ded too | |||
freaking rapture.. All the things are broken | 19:30 | ||
zostay | sweet, someone else is trying to implement P6WAPI then tokuhirom++ | 19:32 | |
eveo | zostay: it's tokushirom's module, dude | 19:34 | |
And I'll be telling people to stay the hell away from it from now on. It's the second time this month they break my production apps with minute, cosmetic changes. | |||
great. It's not a handle anymore either, it's a Supply now | 19:39 | ||
just gonna install an older version | 19:42 | ||
Don't have time for this idiocy | |||
lizmat | eveo: which module are we talking about ? | 19:44 | |
HTTP::Server::Tint ? | |||
*Tiny? | |||
eveo | Yeah | 19:45 | |
Guess it's my own fault for using a module that can't even commit to a version number... | 19:46 | ||
Geth | geth: 3fb833f7c5 | (Zoffix Znet)++ | lib/Geth/GitHub/Hooks.pm6 Update env key name Broken by github.com/tokuhirom/p6-HTTP-Serve...ffce6cd54e |
19:48 | |
eveo | \o/ | ||
Geth | geth: 0fcc87beb5 | (Zoffix Znet)++ | lib/Geth/GitHub/Hooks.pm6 Revert "Update env key name" This reverts commit 3fb833f7c51c93df119f5585a3ad71415787df82. |
||
geth: e8e62a09c7 | (Zoffix Znet)++ | lib/Geth/GitHub/Hooks.pm6 Add a note to install a working version of HTTP::Server::Tiny |
|||
TimToady | S11 specced that all official modules should have version numbers more than 12 years ago, sigh... | 19:50 | |
eveo | Well, it's using "*" as a version number | ||
TimToady | that's not really a valid version number; it's a valid version number matcher | 19:51 | |
eveo | ZofBot: I missed you | ||
ZofBot | eveo, type; "Cannot bind to {$ | ||
eveo | TimToady: so it should be forbidden in META6.json? | 19:52 | |
There was talk about that in the past, because it's causing a module to never get updated if it's already installed, because it thinks it's already on latest version. | |||
TimToady | wildcards should not be part of the identity of a module; they should only be used where dependencies are being checked | ||
eveo | Cool | ||
zostay | the problem is that there's not a lot of releasing tooling available for managing the version numbers, so maintaining version numbers in the current ecosystem is pretty painful | 19:53 | |
eveo | huggable: version :is: * as version in meta file should not be allowed: irclog.perlgeek.de/perl6-dev/2017-...i_14743468 | ||
huggable | eveo, Added version as * as version in meta file should not be allowed: irclog.perlgeek.de/perl6-dev/2017-...i_14743468 | ||
TimToady | and if it's too hard to increment a version number, we should find a way to make it easier | 19:54 | |
lizmat | afaik, mi6 does this for you | ||
zostay | yeah, but mi6 is so new there are very few module authors who've had a chance to have even heard of it yet | 19:55 | |
Geth | rakudo/nom: 11f27a30bd | (Elizabeth Mattijsen)++ | src/core/Baggy.pm Make Baggy.new(@a) about 2x as fast - based on an array with 1000 unique elements - replace +@ signature by 2 candidates: \value and **@args - apparently there is a relatively large overhead involved with +@a sigs - also now properly complains if the single argument is lazy |
||
TimToady | basically, the official module system must support immutability | ||
you have to be able to name a module somehow and depend on it not changing out from under you | 19:56 | ||
zostay | yeah, the ecosystem encourages module authors to put a master branch in META.list, but ideally, it should be tags and the release process switches to a new tag... but at that point you probably need PAUSE-type infrastructure to manage the details without having every author editing the main list each time | 19:59 | |
eveo | We already have PAUSE support; the only piece missing is the frontend for browsing what's available. | ||
I added `try` to precomp renames and now "zef --help" doesn't crash, but based on how long it takes to run, seems like it's precomping everything on each run | 20:02 | ||
zostay | if modules.perl6.org can be made to work off of CPAN + Ecosystem and Ecosystem can become deprecated, I think production Perl 6 becomes a lot more feasible... as it is, it's one of the reasons I do not use it outside of O(fun) projects | 20:03 | |
eveo | ok, progress. Inline::Perl5 install now dies same way on HEAD as on 2017.05. So I should continue looking for some commit in 2017.05...HEAD that introed the rename brekage. | 20:08 | |
ugexe | github.com/rakudo/rakudo/commit/8e...6b086608c1 ? | 20:16 | |
eveo | but this one's closing | 20:18 | |
jdv79 | wut? the eco and cpan are separate things. | ||
kinda one or the other type deal | 20:19 | ||
eveo | why? | ||
Currently we support both | |||
there are people who don't want to switch from github system | 20:20 | ||
jdv79 | ok | ||
just saying they are different and cant really be merged | |||
eveo | Ah. Yeah | ||
I meant that it's unlikely to become "one or the other" but rather they'd both exist, with CPAN being more "solid" infrustructure and the github being more of a hippy, bleeding-edge type of stuff | 20:21 | ||
:) | |||
jdv79 | happy friday, btw | ||
yup | 20:22 | ||
eveo | k, 0c5fe56 still has rename issue | ||
jdv79 | ive been sucked into python land for cash lately and i dont appreciate it | ||
eveo | which sucks, 'cause it's meant to fix some other rename issue and if I go further back I won't know which rename issue is hitting me -_- | 20:23 | |
OK. Plan C: do version bumps and stresstest everything, then hunt that bug on HEAD. | |||
ZOFFLOP: t/spec/S17-supply/syntax.t | 20:40 | ||
pmurias | we have a roast test (fuged for the MoarVM) that tests that VM.properties exists, what is that supposed to be on VMs that are not JVM? | 20:47 | |
geekosaur | I think that question is why it's currently fudged :) | 20:48 | |
that is, it's suspected something liek that will be needed to allow programs to adapt to different backends, but nobody knows what it would need to look like yet | |||
Geth | nqp: f6459b6d4d | (Zoffix Znet)++ | tools/build/MOAR_REVISION Bump MoarVM MoarVM bump brought commits: github.com/MoarVM/MoarVM/compare/2...5-g369c0c5 369c0c5 Only update last accepted position when needed. b885d99 Save a deref by introducing a local variable. ... (13 more lines) |
20:49 | |
¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...5-g369c0c5 | |||
rakudo/nom: 51b63bf9f0 | (Zoffix Znet)++ | tools/build/NQP_REVISION Bump NQP NQP bump brought commits: github.com/perl6/nqp/compare/2017....2-gf6459b6 f6459b6 Bump MoarVM ... (18 more lines) |
|||
rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....2-gf6459b6 6e2e4f9aa8 | (Zoffix Znet)++ | src/core/Array.pm Flatten them all instead of using .push semantics. Brings interface in line with native arrays' and Buf's .append Bug find: www.reddit.com/r/perl/comments/6hl...6/dizyiaz/ |
|||
pmurias | Oracle is developing a JVM based node.js so I supposed the js backend could support getting JVM properties on that | 20:50 | |
are the commit messages with a lists of bumped commits useful? :/ | 20:51 | ||
ugexe | i kinda like it | 20:56 | |
eveo | pmurias: saves me about 5 minutes each, when writing the changlog | 20:57 | |
Otherwise I have to fish for nqp bump link, feed it to geth, then find the moarvm bump link, feed it to geth again, and then look through commits to find all the changes | |||
ZOFFLOP: t/spec/S17-procasync/kill.t | 20:58 | ||
pmurias | eveo: if I wrote a 'git log' wrapper that displayed all the info for any bump commits would that be useful for your? | 21:01 | |
s/your/you | |||
lizmat | eveo: are you sure this fix is correct ? | ||
Geth | roast: 76ccac8013 | (Elizabeth Mattijsen)++ | 6 files Add tests for QuantHash.new() not accepting laziness |
21:02 | |
eveo | pmurias: what's the problem with them being in the commit message? I don't use command line when writing changelog, but the commits from perl6.fail/release/stats | ||
lizmat | eveo: seems like it is very to release to do such a change: if it is a bug, it's been around for a long time already afaik | ||
*close | 21:03 | ||
if it isn't a bug, then we've messed up a Rakudo Star release candidate | |||
pmurias | eveo: it's not a significant problem for me | ||
japhb | lizmat: Doesn't gist.github.com/lizmat/063358317dc...e1-txt-L24 risk blowing callstack if there are many consecutive numbers in the input? Or am I misreading? | 21:04 | |
(Given lack of TCO, that is) | |||
eveo | 1 sec | ||
lizmat | japhb: well, potentially, but Perl 6 is not that afraid of recursion :-) | 21:06 | |
pmurias | sleep& | ||
Geth | roast: 859d37ef3f | (Zoffix Znet)++ | S32-array/create.t Test Array.append for multiple Iterables as args Rakudo fix: github.com/rakudo/rakudo/commit/6e2e4f9aa8 |
21:07 | |
eveo | ok | ||
lizmat: now I'm sure, as the tests I wrote matched behaviour. This new sig is the same as native arrays and bufs and the old sig is the same as .push. As for close to release. I'm still going to do another toast run to ensure there's no breakage | 21:08 | ||
lizmat | ok | ||
eveo | m: my %h = :42a, :72b; my @a; @a.append: %h, %h; dd @a | ||
camelia | Array @a = [{:a(42), :b(72)}, {:a(42), :b(72)}] | ||
eveo | m: my %h = :42a, :72b; my @a; @a.append: %h; dd @a | ||
camelia | Array @a = [:a(42), :b(72)] | ||
japhb | lizmat: I guess it depends on how big the invocation records are .... | ||
eveo | ^ other wise that's very surpsing and likely unwanted (since you have .push for that) behaviour | 21:09 | |
lizmat: but this release isn't a rakudo star candidate, is it? | 21:10 | ||
huggable: star | |||
huggable | eveo, Estimated Rakudo Star releases for 2017: .01, .04, .07 & .10 | ||
eveo | Yeah, looks like it'll be next month | ||
lizmat | ah, ok | 21:11 | |
I guess we want more of jnthn's performance improvements first eh? | |||
eveo | \o/ | ||
hmm | 21:23 | ||
eveo tweaks the sig a bit more | |||
'cause right now it ends up containerizing stuff before passing it to another multi | |||
no *@ sig :/ | 21:25 | ||
I meant *foo | |||
m: my @b = (1, 2, 3), <d e f>; multi foo (\v) { dd v }; multi foo(**@foo) { multi @foo }(@b».List, @b».List) | 21:27 | ||
camelia | 5===SORRY!5=== Cannot use '(unknown scope)' with variable declaration at <tmp>:1 ------> 3 dd v }; multi foo(**@foo) { multi @foo 7⏏5}(@b».List, @b».List) expecting any of: constraint Other potential difficulties: … |
||
lizmat | japhb: rewrote gist.github.com/lizmat/063358317dc...01de1c2687 without recursion | ||
eveo | hehe unknown scope? :) | ||
jnthn | Heh... | ||
lizmat | ^100000 .condense down from 137 seconds to 5 seconds, 1GB to 100MB # japhb | 21:29 | |
of course, adding a Range.condense variant would make more sense :-) | |||
timotimo | wow, though | ||
jnthn | In terms of call stack - you can recurse as deep as you want, except you'll run out of heap at some point :) | 21:30 | |
lizmat | japhb: still, having it recurse 1M times and still live, is something that I don't think P5 can do :-) | 21:31 | |
or maybe it can... it's just a warning after N recursions, right ? | |||
eveo | lizmat: ok, now I'm less sure... | 21:32 | |
m: my @b = (1, 2, 3), <d e f>; dd [].append: @b».List | |||
camelia | [(1, 2, 3), ("d", "e", "f")] | ||
ugexe | eveo: how were you building those 20ish+ day old rakudo commits on windows? seems like there were moarvm fixes that came after (revealing the bug that may had been happening) | ||
eveo | m: my @b = (1, 2, 3), <d e f>; dd [].append: @b».List, @b».List | ||
camelia | [1, 2, 3, "d", "e", "f", 1, 2, 3, "d", "e", "f"] | ||
ugexe | cause i get failures with ./perl6.bat (seems to be mishandling arguments) | ||
jnthn | lizmat: I think it can, just a warning that you'd need to disable | ||
lizmat | yeah, probably | ||
jnthn | ugexe: Wouldn't it have to be .\perl6.bat ? :) | ||
eveo | huggable, build-rakudo-win | 21:33 | |
huggable | eveo, perl Configure.pl --gen-moar --gen-nqp --backends=moar & gmake & gmake test & gmake install | ||
eveo | ugexe: ^ just running that in the repo | ||
ugexe | ah, im using nmake... wonder if it matters | ||
jnthn | ugexe: I did an nmake build last night | ||
It at least passed make test | |||
ugexe | and yea .\perl6.bat | ||
jnthn: yeah, but there is a bug that goes back some 20+ days that gives me this error | 21:34 | ||
(is building olderish commit) | |||
jnthn | ugexe: Is this the rename file one I saw float by earlier? | 21:35 | |
ugexe | yeah | ||
jnthn | I've hunted those before | 21:36 | |
I *think* I used docs.microsoft.com/en-us/windows-h...-logviewer one time | 21:37 | ||
eveo | m: my @d; my @b = (1, 2, 3), (4, 5, 6); @d.append: @b».List; dd @d # I'd expect this to just get flattened | 21:42 | |
camelia | Array @d = [(1, 2, 3), (4, 5, 6)] | ||
lizmat | eveo: we need either jnthn or TimToady decision on that... | 21:44 | |
jnthn | m: my @d; my @b = (1, 2, 3), (4, 5, 6); @d.append: |@b».List; dd @d | 21:46 | |
camelia | Array @d = [1, 2, 3, 4, 5, 6] | ||
jnthn | .append doesn't flatten sublists | ||
eveo | jnthn: so the behaviour for when it's given two iterables should be the same as wish .push? | 21:48 | |
jnthn | We've been down the "lots of magical flattening that wasn't asked for" road before | ||
eveo: .push will always result in one more entry in the array per argument given to it | 21:51 | ||
.append follows the single argument rule | |||
Or that's how I remember us deciding it. | 21:52 | ||
eveo | jnthn: It feels a bit of an inbetweener compared to the rest of the language. It flattens an Iterable argument, but doesn't flatten non-containerized elements like a normal slurpy or .flat call would | ||
m: my %h = :42a, :72b; my @a; @a.append: %h; dd @a | |||
camelia | Array @a = [:a(42), :b(72)] | ||
eveo | m: my %h = :42a, :72b; my @a; @a.append: %h, %h; dd @a | ||
camelia | Array @a = [:a(42), :b(72), :a(42), :b(72)] | ||
eveo | Wait, that's not it | ||
c: HEAD~2 my %h = :42a, :72b; my @a; @a.append: %h; dd @a | |||
committable6 | eveo, ¦HEAD~2: «Array @a = [:a(42), :b(72)]» | ||
jnthn | And @b>>.List produces a list (due to >>) which has two sublists | ||
eveo | c: HEAD~2 my %h = :42a, :72b; my @a; @a.append: %h, %h; dd @a | ||
committable6 | eveo, ¦HEAD~2: «Array @a = [{:a(42), :b(72)}, {:a(42), :b(72)}]» | ||
jnthn | So that top-level list is the single argument | ||
eveo | jnthn: ^ like this. you either get pairs, but then all of a sudden switch to hashes. And the Hash gets flattened like you'd have it with a slurpy, but non-containerized inner iterables don't get flattened, like with a slurpy | 21:53 | |
lizmat | jnthn: there's maybe the argument now that it is inconsistent with native array.push/append and Buf.push/append | ||
because .append on them flattens because the destination cannot take anything else | |||
eveo | m: dd buf8.new: (1, 2, 3), (4, 5, 6) | ||
camelia | Buf[uint8].new(1,2,3,4,5,6) | ||
lizmat | if we would want to be consistent with Array.append, ^^^ should perhaps fail ? | 21:54 | |
jnthn | Well, it could have been an error | ||
eveo | m: dd buf8.new: (1, 2, 3), (4, "5", 6) | ||
camelia | Type check failed in initializing element #4 to Buf[uint8]; expected uint8 but got Str ("5") in block <unit> at <tmp> line 1 |
||
jnthn | But yeah, I see we've made it inconsistent | ||
But looking at append in CORE.setting | |||
eveo | jnthn: well, 1 sec, let me revert HEAD | ||
jnthn | It's ended up not following the single argument rule anyway :S | ||
(*@values) | 21:55 | ||
lizmat | it used to | ||
jnthn | Oh :/ | ||
Geth | rakudo/nom: a38cb68373 | (Zoffix Znet)++ | src/core/Array.pm Revert "Fix Array.append for multiple Iterable args" This reverts commit 6e2e4f9aa83786c16ee854b9afd8ec02e8fee911. Makes things inconsistent still. Discussion: irclog.perlgeek.de/perl6-dev/2017-...i_14743982 |
||
lizmat | with a \item and a **@a candidate | ||
jnthn | Yeah, this is the problem. During the GLR TimToady and I tried to make things consistent. Then others seem to been to "fix" them for making some use case prettier. :/ | 21:56 | |
Geth | roast: 97665df6e6 | (Zoffix Znet)++ | S32-array/create.t Revert "Test Array.append for multiple Iterables as args" This reverts commit 859d37ef3f5aa39cc5bc99be274f48ebebc86203. Makes things inconsistent still. Discussion: irclog.perlgeek.de/perl6-dev/2017-...i_14743982 |
||
jnthn | *been keen | ||
Which will only get us back to the pre-GLR state where it was unpredictable. | |||
eveo | ok. now the sig is same as .push | ||
lizmat | eveo: note there are also \item candidates, that provide single arg semantics | 21:57 | |
jnthn | The reason we did the GLR was, among other things, to try and get more consistency | ||
lizmat | the \item candidates between Array.push and Array.append differ | ||
jnthn | And yes, it *does* mean that sometimes you have to ask for a bit more flattening explicitly. | ||
</grumpy> :-) | 21:58 | ||
eveo | Yeah, I meant the .append: @a, @b; is same as .push: @a, @b; | ||
jnthn | (Also, have been here through about 6 different list implementations. :)) | ||
eveo | :) | ||
jnthn: so what's the ruling? If all parts of current behaviour are nominal, then I'll add tests to cover the .append: @a, @b; case, 'cause there aren't any | 21:59 | ||
jnthn | The interesting push/append difference is when it receives a single argument | 22:00 | |
m: my @a; @a.push: ((1,2,3),(4,5,6)); dd @a | |||
camelia | Array @a = [((1, 2, 3), (4, 5, 6)),] | ||
jnthn | m: my @a; @a.append: ((1,2,3),(4,5,6)); dd @a | ||
camelia | Array @a = [(1, 2, 3), (4, 5, 6)] | ||
jnthn | m: my @a; @a.push: ((1,2,3),(4,5,6)); say @a.elems | ||
camelia | 1 | ||
timotimo | single arg rules. | ||
jnthn | m: my @a; @a.append: ((1,2,3),(4,5,6)); say @a.elems | ||
camelia | 2 | ||
eveo | m: my @a; @a.push: (1,2,3), (4,5,6); dd @a | 22:01 | |
camelia | Array @a = [(1, 2, 3), (4, 5, 6)] | ||
eveo | m: my @a; @a.append: (1,2,3), (4,5,6); dd @a | ||
camelia | Array @a = [1, 2, 3, 4, 5, 6] | ||
eveo | noooo | ||
jnthn | On multiple arguments, pretty sure we intended that arg list to be "the list" and so push/append would be doing the same | ||
That's how +@a works | 22:02 | ||
eveo | m: my @a; @a.append: [1,2,3], [4,5,6]; dd @a | ||
camelia | Array @a = [1, 2, 3, 4, 5, 6] | ||
eveo | Oh, wait. It's still using my commit | ||
jnthn | And the multi candidates we have presumably exist because this is faster than +@a :) | ||
eveo | c: HEAD~4 my @a; @a.append: (1,2,3), (4,5,6); dd @a | ||
committable6 | eveo, ¦HEAD~4: «Array @a = [(1, 2, 3), (4, 5, 6)]» | ||
eveo | *phew* | ||
jnthn | :) | ||
lizmat | www.0racle.info/articles/perl_6_on_rails | ||
timotimo | perlawhirl++ | 22:03 | |
eveo | OK. I'll write extra tests to cover the multi-Iterable args. The +@a explanation makes sense. | ||
timotimo | is there an opportunity to get around the high cost for +@a arguments? | 22:04 | |
japhb can't install p6doc on a current Rakudo (it dies during testing) | |||
Is this already a known problem? | |||
eveo | japhb: what does it die with? | ||
IIRC I saw it burnt on the last toast run | 22:05 | ||
timotimo | github.com/rakudo/rakudo/commit/11f27a30bd - see also | ||
eveo | Last two even, but the errors about "not a git repository". Sounds like new tests assumed too much? | ||
lizmat | does p6doc use Bags ? | 22:12 | |
eveo | lizmat: just see one instance in tests: xt/examples-compilation.t:my $counts = BagHash.new; | 22:19 | |
lizmat checks | 22:22 | ||
eveo fires up the toaster | 22:23 | ||
buggable, eco | 22:26 | ||
buggable | eveo, Out of 843 Ecosystem dists, 0 have warnings, 0 have errors, and 0 have no tags in META file. See modules.perl6.org/update.log for details | ||
eveo | curious... toaster tells me .. ooohhh | 22:27 | |
It told me 825 dists for toasting, but that's after it excluded dists I banned for hanging | |||
(like IRC::Client) | |||
or rather unkillable via Proc::Async.kill for some reason | 22:28 | ||
japhb | Sorry, got pulled away just after asking my question. | 22:43 | |
eveo: Yes, it's the not a git repository error | 22:44 | ||
eveo: gist.github.com/japhb/8f091d1fe77f...78a1215cd5 | 22:46 | ||
ugexe | "fatal: Not a git repository (or any parent up to mount point /usr/local)"? | 22:48 | |
n/m i misparsed your statement | 22:49 | ||
looks like the cwd is changing somewhere | 22:50 | ||
japhb | Yeah, that was going to be my guess -- lost track of CWD or spooky CWD action at a distance or so. | 22:51 | |
ugexe | `qx <git rev-parse --short HEAD>, :cwd($*CWD.add("zef"));` this fails for me (1 directory above /zef) but works if I use run | 22:52 | |
eveo | ugexe: thanks. Yeah, it's a regression in qx/false/ | ||
I mean thanks japhb | |||
ZofBot: thanks for everyone! | |||
ZofBot | eveo, name) }); }; for ^2 { my $v does IO = class Foo { method close { say "closed" } } | ||
ugexe | QX works, but not qx/qqx | 22:54 | |
eveo | m: class Foo { method sink { say "sunk" } }; my $res; try { my $x := 42; $res := Foo.new } | 22:56 | |
camelia | sunk | ||
eveo | I'm surprised it worked before | ||
Ohhh. It "worked". The Proc probably got sunk before exitcode and whatnot got set :/ | 22:57 | ||
I don't get why it's binding status at all: github.com/rakudo/rakudo/blob/a38c...oc.pm#L197 | 22:58 | ||
japhb | Wait, why does $res get sunk there? | ||
Does := not count as used? | |||
eveo | Oh. nevermind it's new code :) | ||
*phew* I thought it was that way for ages. Will fix soon | |||
ugexe is still looking for where qx/qqx is relted to QX | 22:59 | ||
japhb does not understand. | |||
eveo | japhb: try returns a value of last statement | ||
japhb | Ah, and *that* is what is getting sunk, not the binding itself. | ||
OK, that makes sense. | |||
Thanks, eveo | 23:00 | ||
eveo | I'll fix it in ~30m. Need to finish up something for work | ||
ugexe: somewhere around here, I'm guessing: github.com/rakudo/rakudo/blob/nom/....nqp#L9527 | 23:02 | ||
tehre's method postprocess_run that gens a call to QX | |||
a few lines below | |||
Geth | rakudo/nom: 5e0377366c | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp Add some suggestions for "skip" and "continue" |
23:12 | |
lizmat | and that concludes my hacking for today | 23:18 | |
good night, #perl6-dev! | |||
eveo | night | ||
ZOFVM: Files=1254, Tests=139499, 117 wallclock secs (19.29 usr 3.26 sys + 2218.77 cusr 205.66 csys = 2446.98 CPU) | 23:33 | ||
Geth | rakudo/nom: c532b790e0 | (Zoffix Znet)++ | src/core/Proc.pm Fix regression in qx// The Great Proc Refactor™[1] accidentally created a condition where a Proc returned from a try {} was being sunk. This caused qx// with processes that returned a non-zero exit status to explode. Fix by simplifying the code [1] github.com/rakudo/rakudo/commit/2c...9e5aeee840 |
23:37 | |
roast: 9cc1cb0bcd | (Zoffix Znet)++ | S02-literals/quoting.t Test qx// with error conditions - Test STDERR passes through - Test non-zero-exit processes don't explode Rakudo fix: github.com/rakudo/rakudo/commit/c532b790e0 |
23:38 | ||
eveo | japhb: ^ fixes it | ||
I guess the toast run that just completed is already outdated. | |||
eveo re-runs another one | |||
eveo reads #perl6 | 23:42 | ||
timotimo: FWIW some methods on Nil would explode or give some value: github.com/rakudo/rakudo/commit/c532b790e0 We also have this awful behaviour that calling most Cool methods on Nil will throw with "wanted a :D but got :U" exception | 23:43 | ||
ZofBot: everyone's away! It's just you and me, bud. Like the good old times. | 23:51 | ||
ZofBot | eveo, Either way is fine; if you want to throw extra stuff in as part of the grant report, I am not going to stop you | ||
eveo | ZofBot: I'm done with the grant tho, bruh. You're too slow. | ||
ZofBot | eveo, synacor | ||
japhb | eveo: Starting a rebuild now, thank you! | 23:57 |