samcv | where is the code for perl6 -n located? | 00:13 | |
anyone know? the one that takes stdin and then runs the given code once for each line of input | |||
MasterDuke | samcv: Actions.nqp | 00:16 | |
ugexe | git grep '<%?OPTIONS><n>' | 00:21 | |
samcv | thank you :) | 00:34 | |
BenGoldberg | If I wanted to use NativeCall to play with the C-level dirent struct and readdir functions, how would I declare the d_name part of the struct? In C, it's defined as: struct dirent { ...; char d_name[PATH_MAX+1]; }; typedef struct dirent dirent; | 01:33 | |
cuonglm | Can anyone take a look at this PR github.com/rakudo/rakudo/pull/1154 | 02:04 | |
thanks | |||
samcv | QAST::WVal.new( :value($*W.find_symbol(['Array'])) ) | 02:07 | |
^ this will get me an undefined array y/n? how do i make a defined Array? | |||
aka Array.new | |||
BenGoldberg | nativecallable6, struct foo { char bar[42] }; | 02:13 | |
nativecallable6 | BenGoldberg, gist.github.com/b828fd25a36677922e...23d9a7cec5 | ||
BenGoldberg | nativecallable6, struct foo { char bar[42]; }; | 02:14 | |
nativecallable6 | BenGoldberg, class foo is repr('CStruct') is export { has NYIRP6(Array with size) $.bar; # char[42] bar} | ||
BenGoldberg | NYI, fooey. | ||
AlexDaniel | heh | 02:26 | |
samcv | just had a friend get an issue. not all distros have ExtUtils::Command included with their perl | 05:29 | |
and they had no clue why rakudo star wouldn't install. as it's only used in the makefile | |||
Geth | rakudo/nom: 3f4a9ffac6 | (Samantha McVey)++ | Configure.pl Don't start Configure.pl without ExtUtils::Command Not all distros include this module, but it is needed to run the Makefile. If a user would try and install Rakudo Star and they don't have the module, this would obscure the missing module and they likely would not know why the Rakudo Star compilation/installation was failing. `use` the module in Configure.pl so the user immediately knows they must install this module if they do not have it. |
05:32 | |
moritz | samcv++ | 05:40 | |
travis-ci | Rakudo build failed. Samantha McVey 'Don't start Configure.pl without ExtUtils::Command | 06:16 | |
travis-ci.org/rakudo/rakudo/builds/274899885 github.com/rakudo/rakudo/compare/e...4a9ffac61e | |||
buggable | [travis build above] ☠ Did not recognize some failures. Check results manually. | ||
samcv | oh no | 06:44 | |
oh it looks like probably a flapper not me | |||
jnthn | gfldex: No; last inside whenever should work and mean "unsubscribe", but in the top-level react the only control exception that makes sense is done | 06:56 | |
lizmat | Files=1223, Tests=67675, 290 wallclock secs (11.03 usr 4.59 sys + 1963.13 cusr 206.70 csys = 2185.45 CPU) | 08:15 | |
yoleaux | 12 Sep 2017 16:40Z <Zoffix> lizmat: fixes to S24-testing/8-die_on_fail.t look good. The only thing I don't get is why they were passing before or what do you mean by "core returns the wrong exit codes". perl6 -e 'exit 255'; echo $? gives me 255. Some glitch in is_run() routine? | ||
lizmat | .tell zoffix they were passing before because they were checking for the wrong thing | 08:16 | |
yoleaux | lizmat: I'll pass your message to zoffix. | ||
[TuxCM] | This is Rakudo version 2017.08-112-g3f4a9ffac built on MoarVM version 2017.08.1-156-g49b90b99 | 08:58 | |
csv-ip5xs 1.281 - 1.302 | |||
test 9.524 - 9.536 | |||
test-t 3.394 - 3.402 | |||
csv-parser 10.661 - 10.844 | |||
lizmat | first time below 3.4 ? | 09:35 | |
.speed 10 | |||
ilmari | lizmat: it's been twice before | 09:56 | |
[2017-09-06 10:02:51]< |Tux|> test-t 3.376 - 3.490 | |||
[2017-09-13 09:58:25]< [TuxCM]> test-t 3.394 - 3.402 | 09:57 | ||
gfldex | didn't we used to have typed exceptions for IO? | 09:58 | |
moritz | m: say X::IO | 10:24 | |
camelia | (IO) | ||
gfldex | i'm getting `X::AdHoc: Failed to open file radio-fifo-i: No such file or directory` | 10:30 | |
but I can't find where that comes from | |||
lizmat | m: die; CATCH { dd $_ } # die will throw X::AdHoc | 10:33 | |
camelia | X::AdHoc.new(payload => "Died") Died in block <unit> at <tmp> line 1 |
||
lizmat | gfldex: ^^^ | ||
gfldex | so does fail | ||
and there are quite a few fails with bare strings left in Rakudo | |||
could be something for a SQUASHathon. Fairly easy to do and could be finished in one weekend | 10:35 | ||
Zoffix | . | 10:51 | |
yoleaux | 08:16Z <lizmat> Zoffix: they were passing before because they were checking for the wrong thing | ||
Zoffix still doesn't get it, but OK :) | 10:52 | ||
mst: I didn't know you were a vocalist in a Christian power metal band :) www.youtube.com/watch?v=oxS1aQSSb5M | |||
gfldex: IIRC the was a plan to make open die with a VM typed exception instead of X::AdHoc | 10:54 | ||
gfldex: this PR in particular: github.com/rakudo/rakudo/pull/894 | |||
s/the/there/; | 10:55 | ||
jnthn | Righty, that was lunch. Back to this scheduler... | 11:29 | |
timotimo | back to your regularly scheduler coding | 11:33 | |
Geth | rakudo/nom: 80e069a4b4 | (Elizabeth Mattijsen)++ | 2 files BUILDPLAN states 2,3 were not being used - so eradicate them - probably does not have any noticeable performance effects - but it cleans up, and means less codegen to worry about later |
11:38 | |
jnthn | lizmat: fwiw, I think they're used by NQP | 11:47 | |
lizmat | well, it spectests clean :-) | 11:48 | |
and as a single commit, easily reversible | |||
jnthn: are you saying that NQP executes Mu.BUILDALL ? | 11:50 | ||
lunch& | |||
jnthn | lizmat: No, I think it'd only happen if you inherit from an NQP class | 11:51 | |
lizmat | jnthn: so, do you think I should revert ? | 12:11 | |
jnthn | lizmat: Well, I doubt there's much doing that, though I think v5 was | 12:12 | |
lizmat | hmmm... v5 is severely bitrotted: 'Build' cannot inherit from 'Panda::Builder' because it is unknown. | 12:18 | |
jnthn | Basics of the new thread pool scheduler slowly starting to come together | 12:25 | |
lizmat assumes that will be merged post 2017.09 release, right ? | 12:26 | ||
jnthn | Absolutely. | ||
I've caused enough trouble for one release already :P | |||
gfldex | jnthn: do you got an interface for keeping track and terminating threads aleady? | ||
lizmat | gfldex: you mean terminating threads from the outside? | 12:27 | |
gfldex | yes | ||
jnthn | gfldex: The interface is the same as today | ||
Well, modulo it accepting some extra hints when asked for a queue | |||
That said, the new design does keep rather better track of what threads it's running | 12:28 | ||
So if we want to have a way to get that status info, we can | 12:29 | ||
The design still assumes "lives until shutdown" | |||
gfldex | I would like to terminate a thread that is blocking on a `open`. | 12:35 | |
lizmat | gfldex: I assume technically, you would like to end the work that a thread is doing, right? | 12:38 | |
gfldex | yes | ||
lizmat | ok, just checking :-) | ||
jnthn | Ah, that's...trickier | ||
gfldex | having non-bocking open would mitigate the problem. At least for my usecase. | 12:39 | |
lizmat | gfldex: since we can now pass handles between threads (afaik), wouldn't a start block returning the handle, and a Promise.in(5) timeout do the work for you ? | 12:46 | |
gfldex | if I `open` a FIFO (other fancy stuff like dev-inodes, plasticfs, unionfs and such) the thread will block. The fifo-file can be unlinked without the open call to return. Now I have a thead I can't possibly get rid of, because I can't even for a write from the other end of the pipe (that may be done from a different thread in the same process). | 12:50 | |
s/for/force/ | 12:51 | ||
I intend to build a webradio server that knows about bluetooth speakers and as such will have to talk to all sort of os-subsystems _and_ will run continuesly for weeks. | 12:53 | ||
at least that's the plan. | |||
Segmentation fault (core dumped) | |||
real 1702m34.239s | |||
that's how for Rakudo will carry me so far :) | |||
jnthn | lizmat: Promise.in timeout stuff doesn't terminate the other operation | 12:57 | |
lizmat | ah, duh... and the Promise.in runs in another thread anyway, right ? | 12:58 | |
gfldex | in the world of fork one could use signals. Is there something like that in the (portable) thread world? | 12:59 | |
jnthn | Perhaps yes, especially if you're willing to play NativeCall games | ||
gfldex fleets in terror | |||
jnthn | fwiw docs.libuv.org/en/v1.x/fs.html#c.uv_fs_open is on the one hand non-blocking, but on the other hand doesn't seem to provide a cancellation mechanism | 13:01 | |
It seems the open syscall does take O_NONBLOCK though | 13:02 | ||
jnthn reaches the point where he wants to try out the new scheduler in CORE.setting, before doing further smarts in it | 13:54 | ||
[Coke] | jnthn: ISTR you suggested that, in the setting $*ERR // stderr() would be problematic (and it is) - do you remember what your suggested resolution was? | 13:55 | |
(no worries if not) | |||
jnthn | Ummm...no | 13:56 | |
Though stderr() is an NQP thing | |||
Which is why it won't work in the setting | 13:57 | ||
(which is Perl 6 code) | |||
nqp::stderr gets the handle but that's the low-level object | |||
Do we have situations in CORE.setting where we don't have a $*ERR? | |||
I guess during the build... | |||
We can always use nqp::writefh(nqp::stderr(), nqp::encode('blah', 'utf8')) or so though | 13:58 | ||
hm, well, passes make test :) | 14:00 | ||
heh, that moment when your new scheduler passes spectest first time and you git diff to check if you really actually tested it :P | 14:08 | ||
Zoffix | :D | 14:10 | |
mst | jnthn: and you're still going to be paranoid for weeks | 14:11 | |
lizmat | Q: are we supposed to allow subclassing of Mu.bless ? | 14:12 | |
jnthn | Umm...I think that falls into "not very advisable but it's a method so what can we do about it" :) | ||
mst | also quite possibly "99% of the time a bad idea, but 1% of the time enables you to do things that are really quite awesome and had never occurred to anybody in advance" | 14:19 | |
like, "this is the sort of thing ingy or I might use to do something amazing and everybody else probably just loses a foot" ;) | |||
lizmat | what if you'd still be able to subclass .bless, but you'd need t supply your own .new ? | 14:20 | |
jnthn | Sounds a bit odd-ish... | 14:21 | |
lizmat | what if object creation with a single attribute could be made 30% faster | 14:22 | |
jnthn | What if we solved the more general problem and made all object creations 30% faster? :P | 14:23 | |
s/the more/a more/ | |||
Hurrah, for ^100 { run "ls" } runs in about half the memory with the new scheduler | 14:25 | ||
mst | lizmat: surely if that's possible it could be done via an optimisation that detects the presence of a single attribute with a constructor with a single positional arg or something? | ||
lizmat | well, I guess I could just wait for it :-) | ||
ah, maybe I expressed myself unclearly: the 30% is for a class with single attribute | |||
this would speed up *all* object creation through Mu.new, the percentage would vary with number of attributes and default values needing to be set or not | 14:26 | ||
jnthn | Ah, OK, then it's maybe less bad than I feared :) | ||
lizmat | basically, letting Mu.new do nqp::create(self).BUILDALL(%attrinit); directly | 14:27 | |
rather than go through Mu.bless | |||
mst | lizmat: then I'm confued as to the relationship with Mu.bless ? if you're already needing to detetc the 'single attribute' part you could detect 'My.bless has not been subclassed' at the same time? | ||
sorry if these are stupid questions | 14:28 | ||
Geth | rakudo/better-sched: d2eb742312 | (Jonathan Worthington)++ | 3 files Pass :hint-affinity to scheduler in some places These are cases where the input is arriving to be emitted by a Supply, and thus having multiple threads scrambling to handle the input will do more harm than good. Ignored by the current thread pool scheduler, but will be used by the upcoming new one. |
||
rakudo/better-sched: 80b49320cf | (Jonathan Worthington)++ | 2 files Initial re-implementation of thread pool scheduler Has separate general and timer queues with separate workers, and also introduces affinity queues, which are intended for cases where events will be fed into a `Supply`, and thus there's no point having lots of threads competing over them only to immediately stumble over each other. The separate timer queue helps with timer events being delayed, ... (15 more lines) |
|||
lizmat | mst: hmmm.. good point | ||
mst | I mean, that sounds really cool for the "didn't customize bless or BUILD or new" case in general | ||
you could perhaps inline BUILDALL in that case as well | 14:29 | ||
(and only call TWEAKALL if there's a TWEAK ...) | |||
jnthn | BUILDALL is what I think we'd code-gen | ||
lizmat | BUILDALL would be codegenned indeed | ||
mst | aha, ok | ||
jnthn | Rather than it being interpreted | ||
lizmat | I'm just doing some research into optimizing BUILDALL and grokking the whole machinery deeply | 14:30 | |
jnthn | Also worth noting that manual inlining is generally less useful in Perl 6 than one might thing, since spesh does it in a lot of cases | ||
mst | bearin mind in p5 M* what you call BUILD is always generated, and your TWEAK is the user-accessible bit | ||
lizmat | before starting on the codegen step | ||
jnthn | *might think | ||
mst | so my POV can be skewed by that | ||
lizmat | mst: BUILD/TWEAK will always be called | ||
mst | lizmat: I'm talking about the "when they don't exist" case | 14:31 | |
lizmat | ah, ok.. they will only be called if they exist, of course | ||
but I don't see BUILD and TWEAK code genned into BUILDALL just yet | 14:32 | ||
jnthn | In theory, though, a short BUILD/TWEAK method would be inlined into the code-gen'd BUILDALL, which in turn might manage to be inlined into .new | ||
And if the new is then inlined then we've basically won. | |||
lizmat | yup | ||
mst | my point being that if there's no BUILDs in the heirarchy you could generate a single BUILDALL that e.g. only unpacks the named args once | ||
not sure if your inlining includes signature merging | |||
jnthn | mst: Not yet, though it's in the realm of possible things :) | 14:33 | |
mst | hence the thing where "hier has no custom BUILDs" might still make generating a BUILDALL worth it if there's N levels since %attrinit would then only be unpacked once | ||
I think | 14:34 | ||
mst *thinks* he's being *theoretically* coherent here | |||
but that doesn't mean it's a good idea ;) | |||
lizmat | being theoretically coherent is always a good first step :-) | ||
mst | yeah, but I'm a pure mathematician by training, so I'm really good at being theoretically coherent with no actual relationship to reality ... ;) | 14:35 | |
jnthn | Hurrah, stresstest is also happy under the new scheduler | ||
I guess that means I can now work on making it a bit smarter :) | 14:36 | ||
Can confirm it fixes R | 14:37 | ||
rt.perl.org/Ticket/Display.html?id=122709 | |||
grr :) | |||
That RT | |||
lizmat | .oO( R you being fixed ? ) |
14:38 | |
jnthn | And makes things much betterin RT #131915 | ||
synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=131915 | ||
jnthn | And in theory helps with RT #130370; will check that now | ||
synopsebot6 | Link: rt.perl.org/rt3/Public/Bug/Display...?id=130370 | ||
jnthn | bah, output buffering actually makes that much less of an issue already :P | 14:40 | |
lizmat | don't you hate it if previous opts make new opts obsolete :-) | 14:41 | |
jnthn | ;) | ||
Well, adding .flush re-shows the problem of the late timer | 14:42 | ||
And I can see that with the new scheduler the timer fires on time | |||
So, yay | |||
samcv | jnthn, i'm getting crashes in p6decontrv | 14:45 | |
20<samcv>30 of perl6_ops.c:340 in the rakudo tree | |||
jnthn | Crashes? | 14:46 | |
samcv | SIGSEV | ||
jnthn | hm, line 340 is just a pointer comparison | 14:47 | |
Got any local changes? | 14:48 | ||
samcv | just things only triggered with -a and none of these happned with that | ||
libperl6_ops_moar.so`p6decontrv(tc...000cf6980, cur_op="") at perl6_ops.c:340 | |||
jnthn | Could be some kind of version skew | ||
samcv | maybe this means something | 14:49 | |
no cur_op? | |||
jnthn | e.g. a MoarVM change happened and then the extops weren't built against it | ||
samcv | i mean what would i have to do just compile rakudo again? | ||
if so then that can't be it since i have been doing that | |||
Geth | rakudo: sjn++ created pull request #1155: Improve generate MAIN usage for rakudobrew |
14:50 | |
lizmat | m: class A { method bless() { "blessed" } }; dd A.new | 14:51 | |
camelia | "blessed" | ||
samcv | jnthn, also how do i insert a value stored in Actions.nqp into a QAST node? | ||
jnthn | samcv: Did you try a make clean? If you only chanage Actions.nqp... | ||
What kind of value? | |||
Geth | rakudo/nom: 76ccfd591d | (Salve J. Nilsen)++ | src/core/Main.pm Improve generate MAIN usage for rakudobrew When using rakudobrew, the MAIN function's generated usage text contains very long paths on every line. This changes the output to showing the full path on only one line, and then the basename on all subsequent lines. |
||
samcv | a string value | ||
Geth | rakudo/nom: 7f0367b795 | lizmat++ (committed using GitHub Web editor) | src/core/Main.pm Merge pull request #1155 from sjn/sjn-main-usage Improve generate MAIN usage for rakudobrew |
||
samcv | QAST::WVal.new(:value($delimiter)), | ||
samcv | it's a variable that's in the code, well it's an argument for a sub in Actions.nqp and it's a str type | 14:52 | |
dogbert17_ | jnthn: is it enough to check out the 'better-sched' branch and rebuild rakudo in order to test it or does something else have to be done as well? | ||
samcv | if i try that i get: Object of type BOOTStr in QAST::WVal, but not in SC | ||
jnthn | dogbert17_: That'd be all for now | ||
samcv: Yeah, that's not sufficinet | |||
Geth | rakudo/nom: 62fd509333 | (Elizabeth Mattijsen)++ | src/core/Mu.pm Bypass Mu.bless if we can - check if the object's bless method is same as Mu.bless - if so, bypass calling Mu.bless and go for self.BUILDALL directly - makes object creation a bit faster - about 25% for .new on a class with a single attribute and a default value - about 1% slower if you subclass .bless yourself, but that should be rare |
||
jnthn | samcv: There's an add_str_constant or some such method on $*W that does it right | ||
dogbert17_ | hmm, the build, i.e. make went well but make test | ||
and make install didn't go that well | 14:53 | ||
jnthn | samcv: ah, add_string_constant actually | ||
dogbert17_: ohhh | 14:54 | ||
I forgot | |||
I uncovered a MoarVM bug | |||
samcv | that doesn't seem to accept a name though. only a value | ||
dogbert17_ | aha :) | ||
samcv | how do i refer to it by name then? | ||
jnthn | samcv: What kind of name? | ||
samcv | or do i do QAST::WVal(:value($*Wadd_string_constant($foo)) | ||
jnthn | Oh, I see | 14:55 | |
Yes | |||
samcv | to refer to the variable i mean | ||
ok thanks | |||
jnthn | For a moment I thought you were wanting to pass it as a named parameter | ||
samcv | but from the coredump it looks like that thing in perl6_ops.c wasn't getting any argument. so i added a throw in to it in case it gets a NULL pointer | 14:56 | |
jnthn | dogbert17_: HEAD of MoarVM :) | ||
dogbert17_ | jnthn: thx | ||
samcv | will see if it triggers that check and let you know. crash isn't always consistent just been happening randomly | ||
jnthn | samcv: "" doesn't mean NULL pointer | ||
samcv | oh | ||
jnthn | It's jsut that the bytecode stream is a char * | 14:57 | |
But the bytecode stream can have null bytes in it | |||
gdb then helpfully tries to show it as a string | |||
samcv | well the argument is MVMuint8 *cur_op | ||
jnthn | 'cus it can't know it's not | ||
And ends up showing either a junk string or, if it's a zero, the empty string | |||
samcv | so it points to something that has a NULL in there? | ||
jnthn | yeah | 14:58 | |
But it's not string data at all | |||
samcv | yep | ||
jnthn | And it's not even a null pointer, just a zero byte | ||
samcv | yeah i got it | ||
jnthn | Did you try a make clean ? | 14:59 | |
samcv | jnthn, now i get Object of type QAST::Want in QAST::WVal, but not in SC | 15:05 | |
yeah i'll try that | |||
this is with the WVal issue | |||
jnthn | samcv: oh... | 15:07 | |
Then add_string_constant is already returning a QAST node | |||
I forgot it did that | |||
So you don't need to wrap it int a WVal at all | |||
Just stick it straight into the tree | |||
samcv | ok cool | 15:08 | |
Skarsnik | Hello | 15:15 | |
yoleaux | 12:10Z <Zoffix> Skarsnik: you were asking how much HDD Toaster needed. I have the answer: irclog.perlgeek.de/perl6/2017-09-13#i_15156762 | ||
Skarsnik | Hm someone ran toaster already? | 15:16 | |
Zoffix | Skarsnik: I think stmuk was gonna. At least he was asking about how much HDD space was needed | 15:20 | |
ugexe | what tool should i use to find leaking/opening handles other than playing with ulimit? | 15:21 | |
Skarsnik | I am actually preparing a vm to run it | ||
stmuk | Skarsnik: I'm running it on a very low resource VM right now but I have only got to th Ds | ||
the more runs the better | 15:22 | ||
Skarsnik | Zoffix, I need to upgrade the free account to something? max core I could set was 8 | ||
Zoffix | Skarsnik: oh, dunno. I guess that's the limit now. I think I subbed to full account right away and while I still had the $300 credit, I could use full systems (32-core at the time, they have 64-core boxes now) | 15:23 | |
ugexe | someone should make a tool to generate a perl6 docker + toaster + post-run ~/.zef/store folder (so no fetching is required) | 15:24 | |
stmuk | Zoffix: which VPS service did you use? | 15:25 | |
Skarsnik | or just put all cmd on the readme in a script x) | ||
ugexe | that still requires downloading | ||
which means various commands could fail during install process | 15:26 | ||
Zoffix | stmuk: Google Compute Engine | ||
For toasting and rakudo-hacking-on-the-go. I use Linode for my always-on server | 15:27 | ||
ugexe | me too | ||
Skarsnik | btw why perlbrew? | 15:28 | |
perl on debian is too old? | |||
ugexe | does debian come with a perl with the proper flags turned on? | ||
Skarsnik | No idea | ||
Zoffix | Skarsnik: dunno, just force of habbit. I always brew my own perl, leaving system one alone | 15:29 | |
Skarsnik | Why would you need special flgas? | ||
Zoffix | For Inline::Perl5 | ||
Skarsnik | Ooh make sense | ||
jnthn | More scheduler fun tomorrow. :) bbl | 15:31 | |
stmuk | I've used the Redhat cloud service before as well .. I wonder if there is a regularly updated resource keeping tab on cloudy free-ness? | 15:34 | |
nine | I really don't like github.com/rakudo/rakudo/pull/1155...cdd7758403 | ||
It's useful only for rakudobrew users and may confuse others. | |||
Skarsnik | hm | 15:35 | |
not really | |||
zef does the same thing | |||
I get a /opt/....../zef in front of each line | 15:36 | ||
Zoffix | Skarsnik: it only does that because you're using rakudobrew | ||
Do you? | 15:37 | ||
Skarsnik | hm | 15:38 | |
it does not now x) | |||
stmuk | I think zef behaviour changed recently I've not seen the long paths for a while | 15:39 | |
Skarsnik | Usage: | ||
zef [--force|--force-fetch] fetch '[<identities> ...]' -- Download specific distributions | |||
I remember having a full path here | |||
Zoffix | Skarsnik: there's a plug in zef itself to avoid that.... Try zef dfasdassadsa | ||
Skarsnik | well anyway it's not here, it's cool | 15:40 | |
and I installed by hand | |||
stmuk | talking of rakudobrew .. there are some PRs open (inc. one of mine :-) ) | 15:42 | |
Skarsnik | Zoffix, toaster detect the number of core? | 15:43 | |
Geth | rakudo/nom: 9b527d0f08 | (Stefan Seifert)++ | src/core/Main.pm Revert "Improve generate MAIN usage for rakudobrew" This reverts commit 76ccfd591db960c6d1a22a496ef928cdd7758403. The issue only affects rakudobrew users and that's because rakudobrew plays tricks with module installation. The proper fix would be to change rakudobrew so it no longer uses different module installation paths for each rakudo version. |
15:44 | |
JimmyZ | jnthn: re TPS, how do you think about github.com/rakudo/rakudo/pull/1088 ? :) | 15:45 | |
Skarsnik | I need to toast HEAD and 2017.08 ? | ||
Zoffix | Skarsnik: yes | 15:46 | |
Skarsnik: .. and yes :) | |||
Skarsnik | so I do toaster 2017.08 HEAD and it's good? x) | 15:47 | |
And I can take a shower, do some groceries, write 10 000 words of stuff... | |||
stmuk | I'm seeing a few moar backtraces BTW | 15:48 | |
samcv | yay i got -a working \o/ splits the STDIN into an array | 15:52 | |
though not sure what default would be, perl has it be like \s+ | |||
Zoffix | it also uses $*ARGVFILES equivalent instead of STDIN, innit? | 15:54 | |
samcv | it's like -n | 15:55 | |
except it splits $_ into $*f, though the variable name can be changed of course | |||
i gotta sleep a tad more. o/ | 15:56 | ||
samcv & | |||
Zoffix | $ echo 'one three' > one; echo 'two four' > two; perl -wlaE 'say @F' one two | ||
onethree | |||
twofour | |||
\o | |||
Skarsnik: OK, I've just confirmed. when using rakudobrew, `zef dasdsadsad` prints awful long parts. When using my installer bash alias, it just uses `zef` | 15:58 | ||
Zoffix builds HEAD | 16:00 | ||
Oh, lol, nine++ reverted the update | 16:10 | ||
For a second I was confused why bleed rakudo did not show changed message :) | |||
Skarsnik | there is no spec to specify external deps in the meta file btw? | 16:11 | |
external = no perl6 deps | |||
Zoffix | I think samcv++ was working on that at some point | ||
Skarsnik | is that just agreed on the field name/struct? I mean implementation can came later | 16:12 | |
Zoffix | There's no official specification for the META file contents. As in, there are no roast tests (that I'm aware of) that test what happens with a META6.json file. | 16:15 | |
Geth | rakudo/nom: 2574f8835f | (Elizabeth Mattijsen)++ | 2 files Adapt BUILDPLAN further - replace state 0 for calling BUILD/TWEAK by just the Callable - saves one int + one list for each BUILD/TWEAK method in class or derived - adapt Mu.BUILDALL/BUILD_LEAST_DERIVED accordingly - runtime improvements within noise - move up all other states one notch |
||
Zoffix | Skarsnik: It's actually part of 6.d-prep preliminary TODOs, if you'd like to get the ball rolling there :) github.com/perl6/6.d-prep/tree/mas...6json-spec | 16:16 | |
lizmat | dinner& | ||
Zoffix | .oO( 6.d "Dismorphia" sounds so cool... ) |
16:17 | |
Skarsnik | Zoffix, I could add rt.perl.org/Ticket/Display.html?id=126744 in this file maybe x) | 16:20 | |
ugexe | what about design.perl6.org/S22.html#%3Afrom%3Cnative%3E | 16:22 | |
Skarsnik | I am not fan on how it's done in this, but it's some ideas | 16:24 | |
Zoffix | Skarsnik: yeah, so looks like ^ S22 has seen some updates. Would be sweet to see an impl and some tests :) | ||
Or maybe not. Perhaps this isn't something we want to rush just to include in 6.d | 16:25 | ||
Zoffix & | |||
Skarsnik | having the spec defined for 6.d could be a nice goal | ||
ugexe | most of it has nothing to do with rakudo, the important pats to hammer down are the parts rakudo uses | ||
Skarsnik | implemnetation will be for stuff like zef | 16:26 | |
ugexe | nine, tony-o, and myself came up with the s22 specs based on hours of discussion | 16:27 | |
Skarsnik | dunno. for me it should not be directly on the depend keyword, to make a good barrier between perl6 dependancies and the rest | 16:30 | |
ugexe | why is that distinction important | 16:31 | |
which, you otherwise make with :from<...> | |||
s/make/mark/ | 16:32 | ||
Skarsnik | It's clearer. From a packager point of view I would prefer having them on a separate part than the perl6 deps | 16:33 | |
ugexe | thats objective | 16:34 | |
Skarsnik | both are subjective point of view :) | ||
ugexe | right, im trying to ignore those things | 16:35 | |
i dont claim one looks better than the other | |||
Skarsnik | If you are like zef/panda/whatever writer for me it draw a clear line between "I need to handle the depends stuff to be perl6 module installer" and "the other deps I can do then later of let another tool do the job" | 16:36 | |
nine | Skarsnik: as a packager (which I am, too) you have to consider all dependencies anyway. What would duplicating the hierarchy gain you? | ||
ugexe | zef/panda/whatever can draw their own lines | 16:37 | |
Skarsnik | Well the perl 6 parts dep are like "generic" the non perl6 deps need specific need | 16:38 | |
ugexe | besides, it not even about what they can handle as far as fetching. its also about searching for all the parts to complete a dependency graph. if you don't have curl and can't fetch it, but a different optional dependency doesnt need curl, it should choose that path | ||
all of this before downloading any actual packages (just the index) | 16:39 | ||
thats why the keys in the example show names that correspnd to $*KERNEL, $*VM and the like | 16:40 | ||
Skarsnik | if it's a python module, maybe you need to call the python packager, if it's a C deps, maybe there is a tool to build the lib, or you can call the distrib installer or whatever | ||
ugexe | right, but that doesn't change anything | ||
Skarsnik | It change it's very different than handling a Perl 6 dep | 16:41 | |
ugexe | infact it only reinforces that a single dependency field is needed, unless you want to spec $each_lanage_dependencies : { } | ||
Skarsnik | No, just a non-perl6-deps or something | ||
ugexe | its not different | ||
what does that change? the python package manager still doesn't understand it | 16:42 | ||
the topic of handing off responsibility to other package manager (apt-get, cpanm) was also brought up and taken into consideration of this design | 16:43 | ||
there is also a poc implementation github.com/tony-o/p6-warthog (System::Query) | 16:49 | ||
nine | Skarsnik: why do you think that zef should install Perl 6 dependencies? If they are available as distro package, I'd want zef to let that do the job. Same as with Python or C dependencies. | 16:55 | |
Skarsnik | gist.github.com/Skarsnik/0c0b88a1f...0b4239d125 hm | 16:56 | |
I really not fan of the "gumbo:from<native>" | |||
sjn | o/ | 17:07 | |
Zoffix | \\o | ||
ugexe | so write { "name" : "gumbo", "from" : "native", ... } | ||
AlexDaniel | . | 17:11 | |
yoleaux | 10:36Z <gfldex> AlexDaniel: you may want to have a look at irclog.perlgeek.de/perl6-dev/2017-...i_15156473 | ||
AlexDaniel | gfldex: I noticed that during the squashathon it's best to have short tickets with very clear goals | 17:13 | |
gfldex: if we can do that for what you've said, then great | 17:14 | ||
Skarsnik | Finished Net::ZMQ: Fail | 17:17 | |
hm does it appears twice on the ecosystem file? x) | |||
Zoffix | Skarsnik: looks like it: modules.perl6.org/s/ZMQ | 17:19 | |
Skarsnik | ho there is 2 candidates | 17:20 | |
Zoffix | Yeah :) | 17:21 | |
Skarsnik | I wonder what zef install in this case xD | ||
Zoffix | Just said "===> Installing: Net::ZMQ:ver('0.8')" | 17:22 | |
Skarsnik | oh it takes highter version probably | ||
ugexe | both are the same meta file | ||
Zoffix | ugexe: no, they aren't. Did you click the dist URLs on MP6.org? They both point to one module, but there are two different modules. | 17:23 | |
One github.com/arnsholt/Net-ZMQ and the other github.com/gabrielash/perl6-zmq | |||
(the github icon on the site links to repos directly) | |||
ugexe | ah | ||
Zoffix | And the handling of same-name-multi-auth still needs to be implemented. I just had no clue where to get the auth info from | 17:24 | |
ugexe | yeah neither one include it | ||
er i see it is in one of them | 17:25 | ||
Zoffix | Ah, OK. I'll use that and fallback to GitHub username the next time I work on MP6.org | 17:26 | |
AlexDaniel | Skarsnik: thanks for working on it. <3 | 17:27 | |
where did my compose key go… :-S | 17:28 | ||
errr… emacs is now eating it, wtf | |||
“This is a bug. It's fixed in Emacs 24.4.” ahem | 17:30 | ||
actually, it's my mistake, nvm | 17:34 | ||
samcv: do we have full unicode 10 support now or are there any missing pieces? | 17:45 | ||
Geth | rakudo/nom: 9f1d03e727 | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/ChangeLog Log some changes Deliberately not logged: 89447213 636a3c12 d0a5cfa8 3518b13b ffd87fe5 3cfc3285 ab69dc3a 29cd9fb5 d8958fc3 b6a60236 43abdb1d 74ca5ce9 9b43c8de f1b08630 e3af6629 3e13825b 1f39d684 067f5407 e717d14d d135728b 90968895 d85569d0 85a97ab3 9a478b1e 75c98704 138b6ce0 72bf0238 c39db878 35916427 d5a5fb7c dfbd39b8 456c4398 e5a60099 fb140b89 dd52b07b 591b93ea 16f8419a 2762bcc4 76f1d897 2c0cd0a3 94fe65db f097e551 |
18:02 | |
AlexDaniel | releasable6: status | 18:03 | |
releasable6 | AlexDaniel, Next release in 3 days and ≈0 hours. 1 blocker. Changelog for this release was not started yet | ||
AlexDaniel, Details: gist.github.com/d9374cfd8b247e6c37...cbf8563d12 | |||
AlexDaniel | ah right… it takes a minute or two for releasable to pull stuff | ||
(relevant github.com/perl6/whateverable/issues/207) | |||
anyway, please take a look at the changelog and see if I logged your changes correctly | 18:04 | ||
meanwhile I'm taking a nap, have a nice evening everyone | |||
Skarsnik | ok reached W for 2017.08 x) | ||
AlexDaniel | Skarsnik: \o/ | 18:05 | |
Skarsnik: I'll be back in 3-4 hours :) | |||
Skarsnik | Time for dinner anyways | ||
I hope it will be finished before 5h | |||
Zoffix | Gah, read all the discussion on that blocker, just to get to the end and see lizmat++ already fixed it :) | 18:06 | |
Skarsnik: oh, forgot to mention. When I ran the Toaster, some time some modules would never finish testing. I think it's a bug in Proc::Async.kill (or it's just not meant to kill some things) that may or may not be fixed already. | 18:08 | ||
.tell AlexDaniel commit d0d105b8 can go from the ChangeLog. It was just a refinement over 5db5b1db and the issue it fixes did not exist in previous release. | 18:13 | ||
yoleaux | Zoffix: I'll pass your message to AlexDaniel. | ||
Skarsnik | hm everything fail with nom | 18:15 | |
nvm one passed lol | |||
lizmat | Zoffix: what did I fix ? | 18:26 | |
I wasn't aware I fixed any blockers | 18:27 | ||
Zoffix | lizmat: rt.perl.org/rt3/Public/Bug/Display...?id=132030 | 18:29 | |
The close-handles-on-exit thing | |||
lizmat | ah, that, yeah, I fixed that | 18:30 | |
Zoffix | \o/ | ||
lizmat | wasn't aware that was listed as a blocker :-) | ||
Geth | rakudo/nom: 532f709278 | (Elizabeth Mattijsen)++ | src/core/Mu.pm Oops, forgot to update the vivify shortcut check |
19:04 | |
travis-ci | Rakudo build failed. lizmat 'Merge pull request #1155 from sjn/sjn-main-usage | 19:25 | |
travis-ci.org/rakudo/rakudo/builds/275074500 github.com/rakudo/rakudo/compare/8...0367b79516 | |||
buggable | [travis build above] ✓ All failures are due to timeout (0), missing build log (0), GitHub connectivity (0), or failed make test (1). Across all jobs, only t/04-nativecall/12-sizeof.t test file failed. | ||
Skarsnik | err | 19:26 | |
Geth | rakudo/nom: b706b84312 | (Elizabeth Mattijsen)++ | src/core/Mu.pm Make BUILDALLPLAN and BUILD_LEAST_DERIVED use same internal logic This might have some effect on "but role" code. |
19:40 | |
rakudo/nom: 963b28d196 | (Elizabeth Mattijsen)++ | 2 files Make BUILDPLAN states order more logical - group all of the init / set default value states together - simplifies build plan creation - should not influence execution speed much - paves way for more optimizations in the future |
20:15 | ||
AlexDaniel | FWIW the blocker is probably resolved, but I wouldn't bet on it without toaster results | 21:56 | |
yoleaux | 18:13Z <Zoffix> AlexDaniel: commit d0d105b8 can go from the ChangeLog. It was just a refinement over 5db5b1db and the issue it fixes did not exist in previous release. | ||
AlexDaniel | we can theorize about it as much as we want but I want to see if the modules are actually working | 21:57 | |
IIRC whateverables still get stuck in their tests, for whatever reason. Will look into it now | |||
releasable6: status | |||
releasable6 | AlexDaniel, Next release in 2 days and ≈21 hours. 1 blocker. 105 out of 122 commits logged | ||
AlexDaniel, Details: gist.github.com/0fa137fd3f4224c88f...151222c940 | |||
Geth | rakudo/nom: c4043b068d | (Aleks-Daniel Jakimenko-Aleksejev)++ | docs/ChangeLog Log remaining commits Deliberately not logged: d0d105b8 db68552f c19e810e b62b40f1 76ccfd59 7f0367b7 9b527d0f 9f1d03e7 eb99bbc4 |
22:22 | |
AlexDaniel | Zoffix: thanks | 22:23 | |
Skarsnik_ | AlexDaniel, here the result : www.nyo.fr/~skarsnik/tmp/toast.sqlite.db look at Toaster instruction to use them ^^ | 22:49 | |
I need to go to sleep | 22:50 | ||
AlexDaniel | Skarsnik_: cool, thanks. Will take some time to set it up probably, but I'm on it :) | 22:55 | |
it runs! It runs!! | 23:18 |