| jdv79 | Zoffix: did you hit up nine or jnthn on that bug for hints? | 01:32 | |
| MasterDuke | does anyone have strong feelings about adding new dependencies to htmlify.p6 in doc? | 01:38 | |
| i just created a PR for Perl6::TypeGraph::Viz to use File::Temp instead of rolling its own temp file creation | 01:39 | ||
| but wanted to get some other opinions before merging it | 01:40 | ||
| jdv79 | just do it:) | 01:41 | |
| MasterDuke | ha, sounds like +1 so far | 01:50 | |
| Zoffix | jdv79, they're busy | 01:53 | |
| MasterDuke, +1 | |||
| jdv79 | Zoffix: :( | ||
| MasterDuke | +2 gets it done | 01:54 | |
| but now the more interesting change. converting the "Processing $dir Pod files ..." section to a bunch of start()s and await()s, and the "Writing [type graph images, specialized visualizations] to html/image" to a bunch of Proc::Async.new()s, start()s, and awaits()? | 02:00 | ||
| for me, it brings "time perl6 htmlify.p6 --no-highlight" from 6 min to 1.5 min | 02:01 | ||
| jdv79 | yes please | ||
| is it done? | |||
| MasterDuke | pretty much | ||
| jdv79 | nice! | ||
| MasterDuke | it's just a couple lines | ||
| but the docs do say Proc::Async is not implented for Rakudo on the JVM | 02:02 | ||
| *implemented | |||
| jdv79 | and? | ||
| MasterDuke | and all the async/concurrency parts of Rakudo are definitely kind of weird crash prone | 02:03 | |
| well, i don't think losing JVM compatability is the worst things for htmlify.p6, but not sure i want to make that decision unilaterally | 02:04 | ||
| Zoffix | MasterDuke, considering the JVM backend doesn't even pass the spectest at the moment, I wouldn't even worry about it for htmlify.p6 | 02:05 | |
| MasterDuke, you may wanna touch back with [Coke] though. I think he was working on parallelizing htmlify.p6 too, IIRC. | |||
| *touch base | |||
| MasterDuke | Zoffix: thanks, i'll create the PR and ask him to weigh in before i merge anything | 02:07 | |
| all, i created a PR (github.com/perl6/doc/pull/661) for docs that i would appreciate some eyes on | 02:48 | ||
| .tell [Coke] i created a PR (github.com/perl6/doc/pull/661) for docs that i would appreciate some eyes on, it's an attempt at parallelizing htmlify.p6. Zoffix++ mentioned you were working on the same thing | 02:49 | ||
| yoleaux2 | MasterDuke: I'll pass your message to [Coke]. | ||
| Zoffix | Check it out: i.imgur.com/oW9nuJr.png Making an interactive app for doing Rakudo releases. Gonna try to automate some steps too. It's Mojolicious via Inline::Perl5 :) | 02:54 | |
| Well, I guess screenshot isn't impressive, but each "step" is a separate plugin class, so it's easy to... do stuff... with them :) | 02:58 | ||
| grrr.... getting bitten by #128457 and can't workaround it ~_~ | 03:19 | ||
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128457 | ||
| Zoffix installs 2016.04 | |||
| Now modules fail. (āÆĀ°ā”Ā°ļ¼āÆļøµ ā»āā» | 03:32 | ||
| nine | Zoffix: Repository::Installation is fully backwards compatible but unfortunately not forwards compatible :/ Once it upgraded to the current version, and old rakudo won't be able to deal with it properly. | 08:06 | |
| psch | i kind of want to toss the EVAL call in CU::PrecompUnit | 10:31 | |
| just to see if things get easier to debug that way | |||
| but then, seeing as the Foo.pm already fails differently, it'd probably not help :| | |||
| +case | 10:35 | ||
| nine | psch: the EVALs all look like this: CompUnit::DependencySpecification.new(short-name => "NativeCall::Types", source-line-number => 5, from => "Perl6", version-matcher => Bool::True, auth-matcher => Bool::True, api-matcher => Bool::True) | 10:40 | |
| psch | yeah, except they might have colonpairs, 'cause the regex i used to pull that apart failed sometimes | ||
| nine | psch: I'd guess the only changing parts in current real life code are the short-name and line-number fields | ||
| oh | |||
| psch | anyway, the more reasonable approach would probably be storing the non-changing parts in a easier-to-parse format instead of fiddling with a regex and a .new call | 10:41 | |
| err, s/non-// | |||
| nine | true | 10:42 | |
| [Tux] | This is Rakudo version 2016.06-118-g3fda0b0 built on MoarVM version 2016.06-9-g8fc21d5 | 10:52 | |
| test 16.389 | |||
| test-t 9.585 | |||
| csv-parser 17.639 | |||
| psch | m: class A { has $.b }; my $a = A.new(:2b); say "$(.name.substr(2) ~":"~ $a."{.name.substr(2)}"() for $a.^attributes)" # i am going mad with power \o/ | 11:12 | |
| camelia | rakudo-moar 3fda0b: OUTPUTĀ«b:2ā¤Ā» | ||
| psch | m: class A { has $.b; has $.c }; my $a = A.new(:2b,:3c); say "$([~] do [.name.substr(2) ~":"~ $a."{.name.substr(2)}"() for $a.^attributes])" # haha! | 11:14 | |
| camelia | rakudo-moar 3fda0b: OUTPUTĀ«WARNINGS for <tmp>:ā¤Useless use of "~" in expression "~\":\"~ $a.\"{.name.substr(2)}\"()" in sink context (line 1)ā¤b:2c:3ā¤Ā» | ||
| psch | although probably wants a "quietly" - or a less crunched-in-one-line solution | ||
| i think that's a false positive though, isn't it? | 11:15 | ||
| dalek | kudo/nom: ba09318 | lizmat++ | src/core/Hash.pm: Make Hash initialization about 10% faster By given Hash its own dedicated STORE_AT_KEY, since we spent much more time initializing Hashes then we do Maps. |
11:20 | |
| p: b45f22e | (Pawel Murias)++ | src/vm/js/ (5 files): [js] Remove code to compile method specially in a way that passes the invocant in this as it's not compatible with containers. |
11:23 | ||
| kudo/nom: ecfb956 | lizmat++ | src/core/Map.pm: Make Map|Hash initialization about 30% faster By optimizing Map.STORE and optimizing the handling of a Map initializing a Map. |
12:29 | ||
| [Tux] | This is Rakudo version 2016.06-119-gba09318 built on MoarVM version 2016.06-9-g8fc21d5 | 12:32 | |
| test 16.117 | |||
| test-t 9.284 | |||
| csv-parser 16.431 | |||
| rm -rf /tmp/*-p5helper.so | |||
| give the girl a whishy! | 12:33 | ||
| whisky | |||
| lizmat | .oO( washy ) |
||
| [Tux] | This is Rakudo version 2016.06-120-gecfb956 built on MoarVM version 2016.06-9-g8fc21d5 | 12:48 | |
| test 16.082 | |||
| test-t 9.285 | |||
| csv-parser 16.577 | |||
| lizmat | yeah, I guess that other use cases will benefit more from that last opt | 12:51 | |
| dalek | kudo/nom: 539adae | lizmat++ | src/core/Exception.pm: Make X::Hash::Store::OddNumber more awesome By actually using the extra info added in the last commit |
12:52 | |
| psch | well, not having the EVAL PrecompUnit.deserialize gets NC installed | 12:57 | |
| it's apparently terribly broken, though | |||
| as in, 01-*.t to 16-*.t all fail completely | 12:58 | ||
| ohh, but that's the getextype problem apparently | 12:59 | ||
| nine | psch: cool :) Then I'd suggest we avoid the EVAL on JVM, so people can join in fixing JVM issues again and we at least don't regress any more | 13:40 | |
| We can get back to EVAL any time and a little break from that may actually help :) | |||
| psch | well, it definitely points at a architectural issue with my fix | ||
| i mean, the fact that it kinda-sorta almost fixes the Foo.pm case, but doesn't help with the PrecompUnit EVAL | 13:41 | ||
| which is probably because the latter nests two EVALs | |||
| hrm | 13:48 | ||
| what i don't like with interactive rebases | 13:49 | ||
| if there's exactly one commit that gets picked for the rebase | |||
| and my desired action is to drop that one commit | |||
| it doesn't work, because the buffer is then empty, and git does nothing if the rebase buffer is empty | |||
| as in, only contains comments | |||
| i mean, yeah, the instruction in the comments say as much | 13:50 | ||
| but i really don't want to push a revert commit and the following revert-revert commit | |||
| so i just 'reset --hard origin/master' i suppose? | |||
| well, that's what i have been doing at least | |||
| dalek | p/jvm-begin-eval: 87675a6 | peschwa++ | src/vm/jvm/ (5 files): Mostly debug says, with a few bits that point at a solution. Specifically the changes in QAST::Compiler seem like they are at least somewhat on the right path, in so far as that the missing JAST::Method actually arrives in the Java class, but unfortunately it loses pretty much all the CodeRef-relevant information... |
14:00 | |
| kudo/jvm-begin-eval: d5b9bc8 | peschwa++ | src/core/CompUnit/PrecompilationUnit.pm: Work around broken BEGIN time EVAL on JVM. There is a real solution for the problem somewhere, blah, blah, amend after branch |
|||
| kudo/jvm-begin-eval: 7715aee | peschwa++ | / (4 files): Companion branch to the NQP branch of the same name. As in the NQP branch, mostly debug output with a few bits that seem necessary to get the half-finished solution in NQP to work. As there's a workaround in nom and this issue is really tough... well, I'm taking a break from thinking about CompUnits and QAST compilation. |
|||
| psch | oh fsck | ||
| that one commit shouldn't have been there >_> | |||
| well, as long as it's meaningful on nom, right..? :| | |||
| hm, does that already break history if i amend the same commit on nom that didn't plan to push with the branch? | 14:03 | ||
| +i | 14:04 | ||
| git is hard /o\ | |||
| nine | it's only a branch anyway, isn't it? | 14:10 | |
| di you actually push to nom? | 14:11 | ||
| psch | no, didn't yet | 14:15 | |
| but well, the first commit on the rakudo branch is also on nom | |||
| and amended now | |||
| well, if nothing else it means cherry-picking from jvm-begin-eval, whenever it can be merged vOv | 14:46 | ||
| oh, but i probably should test if moar and jvm actually build with the patch as-is... :) | 14:47 | ||
| dalek | kudo/nom: 24e608e | peschwa++ | src/core/CompUnit/PrecompilationUnit.pm: Work around broken BEGIN time EVAL on JVM. There is a real solution for the problem somewhere, and the parts that I've kinda-sorta figured out are in the NQP and Rakudo branches jvm-begin-eval. |
15:31 | |
| psch | there, that builds moar and jvm | ||
| ...and of course now i notice that i don't know if having both installed could mess with the serialization of the DepSpec somehow | 15:35 | ||
| but backends don't share files, right? so everything's fine..? | |||
| nine | That's...a good question | 16:02 | |
| Maybe they do accidentally now | 16:03 | ||
| But even so, the serialization of the DepSpec is the smaller issue. They also share the bytecode. | 16:08 | ||
| psch | ...how does that work | 16:10 | |
| nine | The precomp files simply don't have a file extension :) So all backends try to load the same files, even if they were written by another backend | 16:45 | |
| I just forgot about multiple backends when I implemented that | 16:46 | ||
| psch | oh. well, that sounds rather fixable | ||
| lizmat | nine: wouldn't it be simpler to just include the backend name in the string for SHA1 creation ? | 18:19 | |
| nine | lizmat: nice idea! | 18:32 | |
| timotimo | that actually basically solves everything | ||
| nine loves hashes | 18:33 | ||
| jnthn | Hm, isn't there a "compiler ID" which is factored into the hash at the end of the repo chain? I'd've thought that might factor backend in... Or have things changed a load since then? ;) | 18:35 | |
| nine | Ah, is the compiler id different per backend? | 18:40 | |
| If yes, we're good | |||
| jnthn | Well, I'd check it... | 18:42 | |
| But it's the place I'd make the fix if there's a need to fix it :) | |||
| dalek | kudo/nom: 32087fe | lizmat++ | src/core/Any-iterable-methods.pm: Make Iterable.sink-all "simple" about 15% faster Finally found a way to work around the Cannot reference undeclared local '__lowered_lex_3225' bug while compiling the setting. |
19:24 | |
| kudo/nom: 240eeaf | lizmat++ | src/core/Any-iterable-methods.pm: A few % out of sequential-map "simple" sink-all |
20:08 | ||
| Zoffix | Is there a way to somehow pass Perl 5 data structures to Perl 5 code via Inline::Perl5? I have basically the same setup as here: github.com/niner/Inline-Perl5#invo...rom-perl-5 | 21:29 | |
| Except I'm trying to pass a hashref instead of a string and I'm just getting Perl6::Object or somethinbg | |||
| yeah, Perl6::Object | 21:30 | ||
| lizmat | Zoffix: isn't a perl5 hash marshalled to a Perl 6 Hash ? | 21:31 | |
| Zoffix | Yeah. I'm trying to go the other way though. Marshall Perl 6 hash into Perl 5 hash | ||
| Oh, this was meant for #perl :) | 21:33 | ||
| And I found a way to cheatsy-doodle: my $hash_ref = { $p6hash->kv } | |||
| s/#perl/#perl6/; | 21:34 | ||
| [Coke] | (htmlify ||-zation) - I was going after it a different way, but breaking it up into makefile-sized chunks was non trivial. | 21:39 | |
| yoleaux2 | 02:49Z <MasterDuke> [Coke]: i created a PR (github.com/perl6/doc/pull/661) for docs that i would appreciate some eyes on, it's an attempt at parallelizing htmlify.p6. Zoffix++ mentioned you were working on the same thing | ||
| tbrowder | I'm getting a rakudo build failure on the current nom: commit 23daf3bb448b9278499162b4c7c4ebb964fbcd36; error is: | 21:56 | |
| www.irccloud.com/pastebin/MRazIsZV/build-error | 21:57 | ||
| lizmat | tbrowder: that's not the current nom? | 21:58 | |
| tbrowder | I think it is... | ||
| lizmat | current is 240eeafbdc9f28c505f afaik | ||
| tbrowder: could you do a configure and build from that again? | 21:59 | ||
| tbrowder | it may be my git: git branch nom; ugh; I'll have to save some stuff before I do that...I'll report back | 22:01 | |
| lizmat | okido! | ||
| tbrowder | it will probably be tomorrow, but this is probably one of those times mentioned in the FAQ that a reconfig will cure (fingers crossed) | 22:03 | |
| dalek | kudo/nom: 6ed117a | lizmat++ | src/core/Any-iterable-methods.pm: Streamline sequential-map "simple" pull-one a bit Mainly for readability, wouldn't be surprised if codegen was the same. |
22:12 | |
| Zoffix | *phew* After an annoying day of messing with RT, my Rele6sr app is starting to get proper useful. It can now show new tickets since last release: i.imgur.com/ky1p95z.png | ||
| tbrowder | okay, build after reconfig is good, thanks (I've been doing: git checkout nom; git pull upstream nom while fiddling so I guess that doesn't always work: because that doesn't update npq? or ? | 22:14 | |
| lizmat | nqp bumps are still missed by make install :-( | 22:15 | |
| tbrowder | ah! ok, t'anks | ||
| Zoffix | This ticket can be closed: rt.perl.org/Ticket/Display.html?id...et-history | 22:19 | |
| Zoffix doesn't have the close button | |||
| This one too [resolved]: rt.perl.org/Ticket/Display.html?id...et-history | 22:20 | ||
| [Coke] | Zoffix: what's your rt id? | 22:22 | |
| nevermind, found you | 22:24 | ||
| you should have close buttons now. | |||
| Zoffix | Thanks. | 22:26 | |
| timotimo | Zoffix: damn, that feature alone is super helpful | 22:32 | |
| (new tickets since last release, i mean) | 22:37 | ||
| Zoffix | :) | 22:38 | |
| dalek | kudo/nom: 5581b24 | lizmat++ | src/core/Any-iterable-methods.pm: Add "push-all" to sequential-map "normal" The great benefit of this should be that any Slips are short-circuited by just doing a "push-all" on the iterator of the Slip. |
23:15 | |
| lizmat | and with that I wish #perl6-dev good night! | ||
| timotimo | gmat, liznite | 23:20 | |
| jdv79 | is "Suge Knight" the name ive heard pronounces "shoog night"? | 23:38 | |
| *d |
