»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg p6eval perl6: ... | irclog: irc.perl6.org/ | UTF-8 is our friend!
Set by sorear on 4 February 2011.
00:04 icwiener joined
jnthn sleep & 00:06
00:08 fridim_ left, tokuhirom joined 00:09 tokuhirom left 00:11 ethndbst joined, hundskatt left 00:12 pmurias left 00:13 replore_ joined 00:54 tokuhirom joined 01:09 tokuhirom left 01:13 woosley joined
[Coke] colomon: so, how DOES one generate sheet music from ABC? do you have to first convert to lilypond and then use that? 01:33
colomon [Coke]: yes
don't tell me you're porting it to nom? 01:34
[Coke] no. 01:35
colomon I think the command line needs to be something like perl6 bin/abc2ly.pl <my-tune.abc >my-tune.ly
[Coke] though I may have to to enable my kid's project.
for now, just trying to install lilypond via macpors.
*macports
colomon I think I ended up installing it from lilypond.org/download.html 01:38
which is slightly not perfect, because as far as I can tell it doesn't install a command-line client, which would be the most convenient way to handle the next step 01:39
01:45 plutoid joined 01:55 wolfman2000 left 02:01 benabik joined 02:13 ethndbst left 02:18 rgrau` left
dalek ecza: 557c6d8 | sorear++ | README.pod:
Document LF requirement in README
 02:32
02:32 cooper left 02:42 Guest46100 left
dalek ast: fface8f | coke++ | S05-mass/properties-general.t:
rakudo unfudging
 03:25
kudo/nom: 51838a5 | coke++ | t/spectest.data:
run fudged tests (yay!)
 03:26
[Coke] colomon: I am STILL installing lilypond prereqs. ;) 03:27
colomon [Coke]: I'm trying to get ABC working on nom. ;)
[Coke] ah, good, maybe you'll be done by the time this finishes. ;)
colomon if I can figure it out. :) 03:28
03:28 molaf joined 03:32 wolfman2000 joined
[Coke] pretty sure all those unfudges are due to diakopter++ 03:33
03:40 wolfman2_ joined, wolfman2000 left 03:44 khisanth_ joined
[Coke] colomon: oooh, finally got to lilypond itself. 03:44
03:45 Khisanth left 03:48 replore_ left
colomon \o/ 03:48
I don't think there's any way I'm fixing this tonight, alas.
03:50 wolfman2_ is now known as wolfman2000
colomon perl6: say ("This" ~~ m/a/).perl 03:50
p6eval rakudo 51838a: OUTPUT«Match.new(orig => "This", from => 4, to => -3, ast => Mu, list => ().list, hash => EnumMap.new())␤»
..pugs b927740: OUTPUT«Error eval perl5: "if (!$INC{'Pugs/Runtime/Match/HsBridge.pm'}) {␤ unshift @INC, '/home/p6eval/.cabal/share/Pugs-6.2.13.20111008/blib6/pugs/perl5/lib';␤ eval q[require 'Pugs/Runtime/Match/HsBridge.pm'] or die $@;␤}␤'Pugs::Runtime::Match::HsBridge'␤"␤*** '<HAND…
..niecza v11-28-g557c6d8: OUTPUT«Bool::False␤»
colomon b: say ("This" ~~ m/a/).perl 03:51
p6eval b 1b7dd1: OUTPUT«Match.new(␤ from => 4,␤ orig => "This",␤ to => -3,␤)␤»
colomon huh. 03:52
ABC tests have been broken all along, in that they weren't testing what I thought they were testing.
perl6: say ("This" ~~ m/a/).bool 03:53
p6eval niecza v11-28-g557c6d8: OUTPUT«Unhandled exception: Unable to resolve method bool in class Bool␤ at /tmp/11Ky6EtP8J line 1 (mainline @ 3) ␤ at /home/p6eval/niecza/lib/CORE.setting line 2224 (ANON @ 2) ␤ at /home/p6eval/niecza/lib/CORE.setting line 2225 (module-CORE @ 58) ␤ at /home/… 03:54
..rakudo 51838a: OUTPUT«Method 'bool' not found for invocant of class 'Match'␤ in block <anon> at /tmp/ym7vf7tyoW:1␤ in <anon> at /tmp/ym7vf7tyoW:1␤»
..pugs b927740: OUTPUT«Error eval perl5: "if (!$INC{'Pugs/Runtime/Match/HsBridge.pm'}) {␤ unshift @INC, '/home/p6eval/.cabal/share/Pugs-6.2.13.20111008/blib6/pugs/perl5/lib';␤ eval q[require 'Pugs/Runtime/Match/HsBridge.pm'] or die $@;␤}␤'Pugs::Runtime::Match::HsBridge'␤"␤*** '<HAND…
[Coke] whoops.
colomon perl6: say ("This" ~~ m/a/).Bool
p6eval pugs b927740: OUTPUT«Error eval perl5: "if (!$INC{'Pugs/Runtime/Match/HsBridge.pm'}) {␤ unshift @INC, '/home/p6eval/.cabal/share/Pugs-6.2.13.20111008/blib6/pugs/perl5/lib';␤ eval q[require 'Pugs/Runtime/Match/HsBridge.pm'] or die $@;␤}␤'Pugs::Runtime::Match::HsBridge'␤"␤*** '<HAND…
..rakudo 51838a, niecza v11-28-g557c6d8: OUTPUT«Bool::False␤»
03:55 satyavvd joined 04:01 sftp left 04:03 wolfman2_ joined, wolfman2_ left 04:04 wolfman2000 left 04:06 jaldhar joined
sorear sends out v12 announce 04:11
colomon \o/ 04:27
04:44 overrosy left 04:47 overrosy joined 04:52 jerome_ left 05:13 wolfman2000 joined 05:22 icwiener left 05:36 jerome_ joined 05:39 mkramer joined 05:51 kaleem joined
Timbus i asked marc lehmann(author of coro, EV, anyevent) about implementing libev and coro in perl 6 and well... i thought chromatic was a downer at times 05:54
:[
sorear haha
I guess you didn't know MLEHMANN's reputation 05:55
Timbus i did
i was expecting something like chromatic, and i got.. mlehmann.
sorear is kind of curious what mlehmann's reply way 05:56
was
Timbus summary: perl6 is bad and you should feel bad 05:57
he had more qualms with the language than any of my questions about getting libev into perl 6
sorear thought so.
Timbus which, i just noticed, he didnt answer 05:58
aaa
sorear seems to me it's a bad question; libev is a C library
mlehmann is very good at finding the flaws in things, and he's usually right 06:00
Timbus well that wasn't the issue. i was wondering if someone who was admittedly very experienced at writing event sbased programs, would have any good ideas for an event based system in perl 6, which could be better built around an event system
instead of having it 'added on' later
06:01 localhost left
sorear too late 06:01
Timbus never~
sorear most of the important architectural stuff in p6 is already non-negotiable
Timbus but the most slushy of the specs is specifically, coroutines, threads, signals 06:02
06:02 localhost joined
Timbus also having event-aware IO libraries instead of adding them later, which is what has to be done in perl 5 06:04
06:04 mkramer1 joined
Timbus stuff regarding the core libs 06:04
sorear Timbus: did mlehmann say anything constructive about how to deal with events?
Timbus not the core language itself
not a peep! time to pull apart libev and anyevent
sorear Timbus: note that Perl 6 has built-in coroutines. if I were designing event stuff, I'd probably make it look more like Coro::EV 06:05
Timbus he did tell me to give up on threads and use fork. which doesnt help on windows :/
perl6 doesnt expose its coroutines enough for me to get anywhere :{
06:06 mkramer left
Timbus i tired using exceptions and resume, and the coroutine example in the spec using pipes. gather and take could work but how do you abstract the syntax away (without macros) 06:07
tried*
(the first two attempts didnt work)
are context switches considered exceptional enough 06:09
06:12 kaleem left
sorear you can abstract the syntax with just ordinary functions 06:14
Woodi hmm, what 'drop threads means' ? 06:15
Timbus "If you want to do it right, use multiple processes, let the mmu do its work instead of trying to emulate it in software, and make sharing of variables between processes fast. Thats actually is the future, since multi core cpus will become very common, the core number will increase, and threads are made for single-core performance and their performance hurts on multiple cores." 06:16
quoting marc.
Timbus just slowly walks away from that one
sorear niecza: my @queue; sub start($f) { push @queue, $(gather { my $*coro__yield = { take 0 }; $f() }) }; sub yield() { $*coro__yield.() }; sub rub() { loop { my $l = shift @queue; push @queue, $l; $l.shift } }; for <a b c> -> $x { start { (say $x; yield) while 1 } }; run 06:17
p6eval niecza v12: OUTPUT«===SORRY!===␤␤Confused at /tmp/s4N3SB2b5v line 1:␤------> hift @queue; push @queue, $l; $l.shift }⏏ }; for <a b c> -> $x { start { (say $x␤␤Parse failed␤␤»
geekosaur thinks there's a certain amount of truth to that... and a certain amount of falsehood
sorear niecza: my @q;sub start($f){push @q,$(gather{my $*coro__yield={take 0};$f()})}; sub yield(){ $*coro__yield.() }; sub run(){loop {my $l=shift @q;push @q,$l;$l.shift}}; for <a b c> -> $x { start { (say $x; yield) while 1 } }; run 06:18
p6eval niecza v12: OUTPUT«===SORRY!===␤␤Undeclared routine:␤ 'gather' used at line 1␤␤␤Unhandled Exception: Check failed␤␤ at /home/p6eval/niecza/boot/lib/CORE.setting line 880 (die @ 2) ␤ at /home/p6eval/niecza/src/STD.pm6 line 1139 (P6.comp_unit @ 32) ␤ at /home/p6eval/n…
sorear niecza: my @q;sub start($f){push @q,$(gather {my $*coro__yield={take 0};$f()})}; sub yield(){ $*coro__yield.() }; sub run(){loop {my $l=shift @q;push @q,$l;$l.shift}}; for <a b c> -> $x { start { (say $x; yield) while 1 } }; run
p6eval niecza v12: OUTPUT«(timeout)a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a␤b␤c␤a􏿽xE2􏿽x90
sorear \o/
06:18 cognominal joined
sorear Timbus: that is a very p5 response 06:20
Timbus it is
and only a small portion of his rant :D
TimToady in my view, any lazy list is a candidate to turn into an event queue between threads
geekosaur but it does depend on the thread model. haskell's threads are designed to be a model for multiple cores, as are p6's; I wonder if he understood that
Woodi can someone write gather take manual pls ? :)
sorear No. 06:21
Woodi why no ? :)
not much in spec
sorear gather and take are very primitive; they cannot be implemented correctly in terms of any other primitive
geekosaur as for example POSIX threads are *not*, and as such do not map well to multicore
Timbus they dont? 06:22
geekosaur not really
TimToady in any case, resumable exceptions are not up to the kind of threading I'm leaning towards
06:22 cognominal___ left
sorear I think the thing we really need to be careful of here is to avoid confusing things that shouldn't be confused 06:22
TimToady I'd like to see low-level scheduling proceed much as in Erlang or Go 06:23
geekosaur you can write things that work reasonably in a multicore environment, but it's not really what they're designed for
06:23 envi_ joined
Timbus TimToady, well, less to do with threading, more to do with a way to resume events that would otherwise freeze an event system 06:23
sorear Haskell did something very very right when they decided that "parallel" and "concurrent" were not the same thing
TimToady sure, you have to know what blocks
geekosaur yes
(to both of those, actually :)
Timbus i do know what blocks! what do i do next :v 06:24
in perl 5 i use Coro::Handle
sorear it depends on what your goal is, and what programming paradigm you want to use to achieve it. 06:26
06:26 kaleem joined
TimToady the details of that may be outside of Perl 6 proper, to the extent that our parallel ops are primitives that don't commit to a particular method, but merely specify what you want solved 06:26
06:26 agentzh joined
sorear [how much sense does it make to share an epoll/kqueue descriptor between kernel threads?] 06:27
TimToady our parallel primitives are primarily trying to promise what you do and don't care about, and let the underlying system solve that within the constraints
Timbus so what I'm picking up from this is for perl 6, the idea would be to wrap my blocking callback in an async?
TimToady so it's completely bogus to say that it must be done with fork, or with green threads, or with your GPU, or your cell processor; all of these have strengths and weaknesses
Timbus that's fair 06:28
TimToady but as you say, we might want more syntax, maybe
06:28 sftp joined
sorear for the most syntactically light parallel things, like hyperops, we'll probably need pragmas to make this sane 06:28
TimToady but I'd like to see event dispatch tied rather closely to function multi-dispatch, as it is in Erlang
Timbus ! 06:29
that's what I was thinking when I made my IRC bot
TimToady an event is just a funny capture
sorear TimToady: I'm not very familiar with that
how is it related to the actor model?
TimToady sorear: sure, the computer is not always going to guess right 06:30
as far as I know, Erlang *is* an actor model
otoh, even if the computer doesn't guess right the first time, it's probably more important to guess right when you do something more than once, and then you can remember what worked well and what didn't from run to run 06:32
dalek kudo/nom: 4269d73 | moritz++ | t/spectest.data:
the Unicode properties regex tests need ICU
 06:33
TimToady on the gripping hand, there's no guarantee you'll have the same resources from run to run 06:34
sorear TimToady: *not-very-useful-mode* The actor model I am most familiar with is Io's
Io supports an 06:36
Io supports a @@method call syntax, which queues the method call on the target object's thread (lazily created if it doesn't exist yet)
also @method, which returns a Promise object, that can be forced to obtain the return value (putting the current thread to sleep if needed) 06:37
06:38 hundskatt joined
sorear what granularity does Erlang make threads for? does it also do OO and "one thread per object"? 06:39
TimToady basically any time you send an event to an event handler, it's a thread; everything is event-based, and there's a strong bias towards value semantics as you might expect in an FP language; more than that I can't say without getting more familiar 06:42
sorear there is also an "abort problem" 06:44
I haven't fully conceptualized it, but cancelling operations in an event-driven system is not quite easy
TimToady well, event-based processing is low level, and pretty much the antithesis of transactional processing 06:45
sorear you need to somehow keep track of what event handlers and what blocking syscalls are connected to what high-level operations
TimToady the plan as been for Perl 6 to support both levels, with some kind of scheduler in between eventually 06:46
*has
sorear e.g. pressing 'Stop' in a web browser needs to close sockets, cancel async-DNS, kill parser threads, etc
TimToady yes, that is much more convenient to handle on a transactional level 06:47
sorear could you elaborate on that?
Woodi Erlang works on VM so names can mean other things. so answer is needed how Erlang shedulers work... stackoverflow.com/questions/605183/...el-threads
sorear is there an established theory of network programming at the transactional level? 06:48
TimToady I'm sure there are several of 'em :)
sorear has Erlang in the 'need to learn more about' box 06:49
TimToady: how much has been written about the "transactional level" in the context of blocking I/O in Perl 6? this is the first I've heard of it 06:50
I'm guessing this isn't related to S1x's talk of STM, since in Haskell-land that's one of the cardinal rules - no I/O in a transaction
[tangentially, I have major issues with how S1x talks about dynamically thread-localizing variables] 06:52
Woodi I was reading yesterday orginal paper for Actor model from 70s and all definitions/lemas/proofs was done for proceses, there was no threads yet. on the other hand maybe it was a paper about "we can use messengers/messages to do parallel computation" (messangers are actors too). probably threads should just use reading memory... 06:53
06:53 Chillance left 06:54 koban joined
sorear Woodi: the word "process" in the 70s meant something closer to what "thread" does today 06:54
Woodi didnt't know. no idea how it worked then 06:55
Timbus and now, fork goes out of its way to share memory until something writes. how far we have come 06:56
did fork really used to spawn an entire new process? because wow 06:57
Woodi so there is confusion, let define maybe things. thread can be kernel or user space, posix is then user space 06:58
..in user space managed by kernel threads ?
Timbus im actually only familiar with windows threads. 06:59
but that sounds a bit crazy
Woodi green threads looks like higher lvl concept
in Windows threads are like proceses in unix world 07:00
sorear Timbus: the first Unix limited processes to 8kb of writable data segment, so copying all of it was not insane. 07:01
Timbus lol. touche 07:02
sorear (this is what happens when you try to turn a PDP-7 into a multiuser system)
07:03 koban left
Timbus sorear, i like this gather take implementation, but can you call 'take' from $f() 07:03
.. why dont I just try it
sorear Timbus: man 2 vfork may also enlighten you.
07:03 sftp left
sorear Timbus: you can in niecza but this is a bug. 07:03
Timbus oh. of course. coro_yield is calling take
so yes, its doing exactly that
07:04 wolfman2000 left
Timbus oh. scoping 07:04
sorear I don't know if it's actually in the synopses yet but the most recent Rule-1 ruling is that only 'take's lexically inside the 'gather' can couple to the 'gather'
Timbus yep that's fair 07:05
sorear Niecza is still using the older rule that gather/take is dynamically scoped
Timbus but since coro_yield is a closure, thats alright?
sorear right 07:06
Timbus cool. just making sure
masak morning, #perl6 07:11
sorear o/ masak
nebuchadnezzar morning
sorear o/ nebuchadnezzar
randomly: I think lexically scoped but dynamically evaluated variables would be a good addition 07:13
it's not cool that I have to fake scoping like $*coro__yield
my $yield; ... temp $yield = ... is _almost_ good enough, but that way is not threadsafe 07:14
Woodi maybe there should be Inter Perl6 Communication specced in some way ? :) will help to coexists betwin many v6 implementations 07:19
+ threads|STM in runtime and every features are in :) 07:20
continuations are just rich subs ? threads are below ? 07:22
everything can be coded in modules but /me things that languages take particular niche becouse of what technology is "in core"... do not missinterpret as "many features in core" 07:26
ok, no one listen, I will go work some :) 07:30
btw. todays Garfield is nice :) 07:32
07:52 alvis left
colomon ugh 07:55
sorear Woodi: I hate to be this blunt, but I'm not responding because I can't make sense of what you're saying. 08:11
moritz neither 08:12
08:23 mkramer1 left
Timbus is it strange that i get it? :I 08:27
sorear, does this gather/yield system require you (the event loop maker) to wrap every dispatched event inside a gather 08:28
coro::handle for example, doesn't need that. a regular event sub can just wait on a handle and other events (and coro threads) all loop like normal 08:30
colomon moritz: so, I've got regex accidental { '^' | '^^' | '_' | '__' | '=' }, and the debugger shows it's matching '^' and not going on to match '^^'. What should I be doing to solve that?
btw, jnthn++ # Grammar::Tracer rocks
Timbus put your longer tokens first? 08:32
colomon Timbus: I think LTM means that shouldn't work. But it's possible I'm completely misunderstanding it.
Timbus oh i misunderstood
colomon is reading the spec now
08:33 fhelmberger left
Timbus i was just recalling ltm used to not work, but that was way ages ago 08:33
colomon wait, it's *longest* -- shouldn't it automatically work, then?
Timbus i assumed from what you said, it was still not working
08:33 muixirt joined
colomon Timbus++ 08:33
Timbus i got karma and i dont know how! :D 08:34
colomon like I said, it was possible I was completely misunderstanding it. I was saying longest token and thinking shortest. :)
Timbus oh
08:36 fhelmberger joined
colomon and reordering does indeed fix the problem in nom. based on my reading of the spec, this is clearly a nom bug. (And I think one that b got correct, even though it didn't have working LTM as far as I know.) 08:36
Timbus odd 08:37
masak nom: '^^^^' ~~ / ('^' | '^^')+ /; say $0.elems 08:38
p6eval nom 4269d7: OUTPUT«4␤»
masak submits rakudobug
niecza: '^^^^' ~~ / ('^' | '^^')+ /; say $0.elems 08:39
p6eval niecza v12: OUTPUT«2␤»
colomon masak++ # forgive me for assuming that was already known
Timbus i knew it :v
masak maybe it is already known. I dunno.
niecza: '^^^^' ~~ / '^' | '^^' /; say $/.chars
p6eval niecza v12: OUTPUT«2␤» 08:40
masak seems there's some interaction between LTM and quantifiers and possibly capturing groups.
oh wait, that's niecza :)
nom: '^^^^' ~~ / '^' | '^^' /; say $/.chars
p6eval nom 4269d7: OUTPUT«1␤»
Timbus is the solution to properly collapse '|' in regex into an unordered list or,
masak nope, it's just LTM that's hosed :)
Timbus is LTM more complicated than that
08:41 aindilis left
Timbus is anything about regexes not complicated 08:41
08:41 aindilis joined
masak Timbus: short answer: all declarative prefixes of the transitive closure of alternatives and subrule calls should be treated on equal footing. 08:41
if that's what you meant by "properly collapse", then yes. 08:43
I believe QRegex attempts this, but I haven't looked at the source code
Timbus that is what i meant, in many more words
colomon Can not bind non-existant attribute '$!orig' on class 'Cursor' -- known bug?
Timbus but is it a fair 'cheat' to make the longer alternatives slightly more important 08:44
or does LTM happen in other cases
like. would LTM be fixed just by reordering alternatives, or is there more to it? i ask mostly out of childlike curiosity 08:45
moritz colomon: LTM is simply not working well enough
arnsholt Timbus: As long as you've no subrule calls that'd work
moritz colomon: re-ordering the alternatives is a workaround until it's fixed
arnsholt But full LTM has to consider the prefixes of subrules as well
Timbus ooo
colomon moritz: danke. any clue about the message Can not bind non-existant attribute '$!orig' on class 'Cursor' 08:46
moritz nom: say Curosor.^attributes
p6eval nom 4269d7: OUTPUT«===SORRY!===␤CHECK FAILED:␤Undefined routine '&Curosor' called (line 1)␤»
moritz nom: say Cursor.^attributes
p6eval nom 4269d7: OUTPUT«Method 'gist' not found for invocant of class 'NQPAttribute'␤ in method gist at src/gen/CORE.setting:3700␤ in sub say at src/gen/CORE.setting:5331␤ in block <anon> at /tmp/MbA73BYIbI:1␤ in <anon> at /tmp/MbA73BYIbI:1␤»
Timbus oh deer 08:47
moritz ouch
nom: say Cursor.^attributes.map(*.name)
p6eval nom 4269d7: OUTPUT«No type check cache and no type_check method in meta-object␤ in method reify at src/gen/CORE.setting:3980␤ in method gimme at src/gen/CORE.setting:4341␤ in method reify at src/gen/CORE.setting:4073␤ in method reify at src/gen/CORE.setting:3980␤ in method reify at…
moritz oh deer ** 2
masak o.O
moritz nom: say Grammar.^attributes
p6eval nom 4269d7: OUTPUT«Method 'gist' not found for invocant of class 'NQPAttribute'␤ in method gist at src/gen/CORE.setting:3700␤ in sub say at src/gen/CORE.setting:5331␤ in block <anon> at /tmp/N19QyHaHC6:1␤ in <anon> at /tmp/N19QyHaHC6:1␤»
moritz nom: say Int.^attributes
p6eval nom 4269d7: OUTPUT«Method 'gist' not found for invocant of class 'BOOTSTRAPATTR'␤ in method gist at src/gen/CORE.setting:3700␤ in sub say at src/gen/CORE.setting:5331␤ in block <anon> at /tmp/95oqbTUbEa:1␤ in <anon> at /tmp/95oqbTUbEa:1␤»
moritz jnthn: it seems that introspection is broken-ish 08:48
sorear -> sleep 08:49
colomon o/
hmmm.... nqp::bindattr($match, Match, '$!orig', nqp::getattr(self, Cursor, '$!orig'));
Timbus nom: say Int.^methods.grep(* eq 'gist') 08:50
p6eval nom 4269d7: OUTPUT«gist gist␤»
Timbus wuh
masak sorear++ # v11
Timbus say Cursor.^methods.grep(* eq 'gist')
nom: say Cursor.^methods.grep(* eq 'gist') 08:51
p6eval nom 4269d7: OUTPUT«Unmarshallable foreign language value passed for parameter '$_'␤ in method reify at src/gen/CORE.setting:4073␤ in method reify at src/gen/CORE.setting:3980␤ in method reify at src/gen/CORE.setting:3980␤ in method gimme at src/gen/CORE.setting:4341␤ in method eage…
moritz sorear++ # v12
Timbus :I
masak er, v12 :)
Timbus yapsi is still gunna win :3 08:52
08:52 mj41 joined
masak heh ;) 08:53
Timbus: I'm excited to see you experiment with abstracting coroutines from gather/take in the backlog. 08:54
Timbus: people have been telling me this should be possible, but I've never succeeded either.
08:54 jerome_ left 08:55 jerome_ joined 08:56 muixirt left
Timbus i'd still prefer resumable exceptions. they feel more flexible, and already package .resume into the exception you caught 08:57
except at the moment, they don't
a minor detail
moritz so what's the task? writing a wrapper and a yield() so that one can write coro { code; yield $value; code? } ?
Timbus that's a pretty good start 08:58
08:58 hundskatt left
Timbus and sorear already managed to do that 08:59
colomon nom: grammar X { regex number { <digit>+ }; regex note_length_denominator { '/' <bottom=number>? }; regex note_length { <top=number>? <note_length_denominator>? }; }; say X.parse("2", :rule<note_length>);
p6eval nom 4269d7: OUTPUT«=> <2>␤ top => <2>␤ digit => <2>␤ number => <2>␤ digit => <2>␤␤»
moritz nom: sub coro(&c) { gather c() }; sub yield(|$a) { take $a }; my @a := coro { say 1; take 2; say 3 }; say "done"; say @a;
p6eval nom 4269d7: OUTPUT«done␤1␤3␤2␤»
colomon woah, that's exploding on my local nom
moritz colomon: on what revision are you on? (or how old is it?) 09:00
colomon moritz: today
I mean, about thirty minutes ago
moritz hm
colomon maybe should rebuild it from scratch?
09:01 s1n left
moritz maybe 09:01
Timbus moritz, did.. did it work? 09:03
you also didn't use yield
moritz Timbus: no. I would have expect it to print 1 before done
Timbus thought so
moritz nom: sub coro(&c) { gather c() }; sub yield(|$a) { take $a }; my @a = coro { say 1; yield 2; say 3 }; say "done"; say @a;
p6eval nom 4269d7: OUTPUT«1␤3␤done␤2␤»
Timbus hehe 09:04
moritz hm, now it's too eager
Timbus did you see sorear's attempt?
moritz nom: sub coro(&c) { gather c() }; sub yield(|$a) { take $a }; my @a := coro { say 1; yield 2; say 3 }; say "done"; say @a;
p6eval nom 4269d7: OUTPUT«done␤1␤3␤2␤»
moritz Timbus: no
Timbus it required a scheduler and I don't think it made it back to the main thread
since the main thread.. scheduled 09:05
sub coro(&c) { gather { c({take $_}) } } 09:07
maybe 09:08
moritz uhm.
jnthn morning 09:09
Timbus sorear mentioned take needs to happen in the lexical
so. bundle it up and pass it to the coro sub as 'yield'? 09:10
moritz hm
jnthn LTM is only done for the protoregex case so far. It can handle alternations within those, mind. The pure alternation case isn't set up yet, however. 09:11
moritz nom: my &yield; sub coro(&c) { gather { &yield := sub(|$a) { take |$a }; c; } }; my @a := coro { say 1; yield 2; say 3 }; say "done"; say @a
p6eval nom 4269d7: OUTPUT«===SORRY!===␤Variable $a is not predeclared at line 1, near ") { take |"␤»
moritz nom: my &yield; sub coro(&c) { gather { &yield := sub ($a) { take $a }; c; } }; my @a := coro { say 1; yield 2; say 3 }; say "done"; say @a 09:12
p6eval nom 4269d7: OUTPUT«done␤1␤3␤2␤»
09:13 khisanth_ is now known as Khisanth
Timbus gist.github.com/1404124 this is what sorear did, moritz 09:15
needs scheduler
yes. yes i do use hard tabs.
jnthn moritz: It's not an introspection problem per se. It's just that cursors get many of their methods and attributes from a role written in NQP. So when you go introspecting, you get objects from outside of the Perl 6 type system. Thus they don't really behave as you want. 09:16
moritz jnthn: say Int.^attributes
nom: say Int.^attributes
p6eval nom 4269d7: OUTPUT«Method 'gist' not found for invocant of class 'BOOTSTRAPATTR'␤ in method gist at src/gen/CORE.setting:3700␤ in sub say at src/gen/CORE.setting:5331␤ in block <anon> at /tmp/CyoHisCpmh:1␤ in <anon> at /tmp/CyoHisCpmh:1␤»
jnthn moritz: Same story.
09:17 JimmyZ joined
moritz but shouldn't it work on Perl 6 core types? 09:17
nom: say Match.^attributes
09:17 s1n joined
p6eval nom 4269d7: OUTPUT«Attribute.new() Attribute.new() Attribute.new() Attribute.new() Attribute.new() Attribute.new() Attribute.new()␤» 09:17
moritz argl
nom: say Match.^attributes[0].gist
p6eval nom 4269d7: OUTPUT«Attribute.new()␤»
jnthn moritz: Yes, it should work in both of these cases. 09:18
Just didn't get there yet
moritz jnthn: ok :-) 09:19
colomon Incorrect pre-compiled version of src/gen/Metamodel.pm loaded ???? 09:23
moritz that means that some rest of an old installation or build are around somewhere :( 09:24
colomon I completely blew away my old nom install and started from scratch here 09:25
maybe it's in ~/.perl6?
jnthn Possibly
It tends to relate to leftover .pir files.
09:25 JimmyZ left 09:26 JimmyZ joined
dalek kudo/nom: c285a5e | moritz++ | src/core/Attribute.pm:
fix Attribute.gist
 09:26
colomon for what it's worth, there's no sign of a "Metamodel.pir" in my ~/.perl6 or my nom install 09:27
09:28 cognominal_ joined 09:30 mkramer joined
colomon ./install/lib/parrot/3.10.0-devel/languages/nqp/lib/Perl6/Metamodel.pbc 09:30
./src/gen/Metamodel.pm
./src/Perl6/Metamodel
moritz ./install/lib/parrot/3.10.0-devel/languages/nqp/lib/Perl6/Metamodel.pbc might be it
colomon removing it gets me a different error 09:31
09:31 cognominal left
moritz which one? 09:32
jnthn The problem will almost certainly be something leftover that was compiled against an older Metamodel.pm.
colomon t/01-regexes.t .. Could not find Perl6::Metamodel in any of: ., blib, /Users/colomon/tools/nom/rakudo/install/lib/parrot/3.10.0-devel/languages/perl6/lib, /Users/colomon/tools/nom/rakudo/install/lib/parrot/3.10.0-devel/languages/nqp/lib
current instr.: 'nqp;Perl6;ModuleLoader;load_module' pc 3656 (src/gen/perl6-moduleloader.pir:1649) (src/Perl6/ModuleLoader.pm:100)
ca
jnthn really needs to look in to the error reporting for this stuff; it's not really doing what it was intended to... 09:33
moritz colomon: hm, need to run 'make install' again 09:34
colomon okay, did that, and now I'm back to Incorrect pre-compiled version of src/gen/Metamodel.pm loaded 09:35
moritz harrumpf. 09:38
jnthn Yeah, I see what's going on.
It loads a pre-compiled PIR file that is old
It was built against an older Metamodel.pm
Which it detects and complains about. 09:39
Trouble is, it's a level too deep in its complaining.
What's interesting is the file that is outdated and expected an older Metamodel.pm.
Which it doesn't tell you. Sorry 'bout that...braino when I was implementing that stuff I guess. 09:40
Timbus gist.github.com/1404124 wheeee 09:42
colomon jnthn: mostly I'm worried because I did a fresh install of nom from scratch, and it just doesn't work.
Timbus i almost look like a real programmer :>
jnthn colomon: Did you have any pre-compiled PIR hanging around in your ~/.perl6/ ? 09:43
colomon might have 09:44
Timbus "unyeilded" hmm it seems im not real pro at grammar
moritz but understandable :-)
09:44 wk left
colomon jnthn: yes 09:44
09:44 mkramer left
jnthn colomon: That's the issue here. When you pre-compile, it's tied to the Rakudo you used to pre-compile it (more specifically, to the setting) 09:45
colomon: Meaning that those .pir files are now out of date. 09:46
moritz jnthn: curiously, I get the same error from an installed rakudo, but the local one works fine
colomon so is that what you meant about the error message being bad? because I never would have guessed it was a problem with a module from that message... 09:47
jnthn colomon: Exactly.
colomon okay.
moritz ah, now I understand :-)
colomon bad news is, after 45 minutes trying to get my fresh nom working, I still get the same bizarre error:
Can not bind non-existant attribute '$!orig' on class 'Cursor'
jnthn colomon: Ah, one of those. 09:48
colomon: I can probably fix that fairly quickly if I can have either instruction to reproduce or (easier) the backtrace when running with --ll-exception 09:49
colomon how's this? gist.github.com/1404214 09:50
jnthn moritz: I can see this "need to match up" issue will cause some confusion.
moritz: Need to find some good way(s) to try and Do The Right Thing. 09:51
colomon: looking
moritz jnthn: if the error message says "the $pir_file was compiled with an incompatible rakudo version" (and lists the correct module .pir file, not Metamodel), I think it's quite understandable
jnthn moritz: Well, I was also thinking of the issue where people upgrade their Rakudo and now the .pir files the module installer made are out of date. 09:53
tadzik it's worse when people don't upgrade their Rakudo and the .pir files are out of date
moritz jnthn: I see two possible solutions for that 09:54
09:54 PacoLinux left
moritz 1) rakudo overrides the .pir files with a new, correct version (possibly with some opt in, like an env variable) 09:54
2) a tool-chain solution, like 'panda recompile' or so
09:54 PacoLinux joined
jnthn People have tended to really dislike the idea of (1) (having Rakudo try to manage pre-compilation) 09:55
tadzik has an example
jnthn tadzik: I'd really like instructions on how to reproduce what you're seeing.
moritz jnthn: I think it fits the ".pir are just cache files" meme very well if rakudo manages them
tadzik gist.github.com/1404231 09:56
jnthn: see above
jnthn moritz: That was my view too :)
colomon I guess I'd worry about what I'm facing right now -- the need to have two different versions of Rakudo installed. 09:58
09:59 lestrrat left
moritz colomon: I guess the easiest solution is to have two separate UNIX users :/ 09:59
each having their own ~/.perl6/
colomon Ugh
and then do I need a third user for niecza? 10:00
that seems like a worst case solution.
moritz aye
I think the solution would be not to place the .pir files next to the .pm files
10:00 lestrrat joined 10:01 dakkar joined
jnthn tadzik: Before it fails, it does 10:01
env PERL6LIB=/home/tadzik/src/perl/panda/blib/lib:/home/tadzik/src/perl/panda/lib:/home/tadzik/.perl6/lib perl6
tadzik: Is it possible finding a Tiny.pir in one of the previous directories than /home/tadzik/.perl6/lib, where you just installed one? 10:02
*possibly
moritz: That'd work. 10:05
moritz: If we can work out where they go, and name that place with some kind of Rakudo version identifier. 10:06
moritz ~./perl6/cache/rakudo/2011.11-68-gc285a5e/JSON/Tiny.pir ? 10:07
jnthn moritz: Something like
moritz maybe add a distinction for core vs. user modules
10:07 JimmyZ left 10:08 JimmyZ joined
tadzik jnthn: nah, it's not there 10:09
colomon is going to try to go back to sleep 10:13
10:14 jerome_ left
jnthn tadzik: OK. Wonder if it's off-by-one error reporting confusing things again. 10:14
10:14 jerome_ joined
kranius hello #perl6 10:14
jnthn tadzik: It isn't something to do with confusion between an installed JSON::Tiny and the one in ext folder in Panda, I guess? 10:16
moritz \o kranius
10:16 jerome__ joined
tadzik jnthn: no, this one's not using ext at all 10:17
I can move it elsewhere, Justin Case
yep, still happens
moritz jnthn: any idea what "Method 'instantiate_generic' not found for invocant of class 'Undef'" could mean? 10:18
10:19 jerome_ left
jnthn moritz: Generic instantiation is role related. 10:19
moritz: Somewhow it must be trying to instantiate something that's not there.
(it goes through various things in the role as it does this) 10:20
moritz jnthn: I've copied&pasted the Str.trans code from b; no 'role' or 'does' or 'but' in there
jnthn moritz: Oh.
moritz: Ah, does it use any type captures?
::T in signature?
moritz no 10:21
just a submethod
multi submethod even 10:23
jnthn moritz: --ll-exception output?
moritz nom: class A { multi submethod a() { }; multi submethod a(Int) { } } 10:24
p6eval nom c285a5: ( no output ) 10:25
moritz hm
jnthn: will see that I get one
jnthn moritz: I just copy-pasted it into a file locally, changed the method into a sub and compiled it...and no error.
moritz jnthn: gist.github.com/1404328 10:26
might be something bootstrappy :/
that's with ss:g/multi submethods/multi method/ 10:27
jnthn ah, this is in the core setting?
moritz yes
jnthn moritz: It's not just that things in the setting require an explicit proto method ... ?
moritz jnthn: might be, didn't remember that 10:28
moritz tries
jnthn It looks like proto auto-gen fails.
moritz tries with explicit protos 10:29
jnthn moritz: I think this is going to need some debugging outside of the setting, though...the version of it with the sub doesn't actually work here. 10:33
moritz :( 10:34
probably relies on autovivification and similar sugar
jnthn moritz: OK, I fixed it 10:38
10:38 daxim joined, agentzh left
jnthn moritz: Two things. First it wrongly relies in $!source being initializable from the default .new 10:38
moritz: Adding a submethod BUILD(:$!source) { } in LSM fixes that.
moritz: Second, the "@to = @to xx ceiling(@from / @to);" hits the notorious "splice not implemented in Mu" list bug. 10:39
moritz: Evidently, not one of the cases I fixed at the weekend. :/
moritz: Workaround is easy enough though. 10:40
After that, trans("abc", "b" => "d"); gives me "adc" :)
10:40 satyavvd left
jnthn moritz: Also, die "Don't know how to handle a {.WHAT} as a substitution key"; 10:41
Needs a .gist on the .WHAT
moritz jnthn: what's the workaround?
jnthn moritz: Just assign to a different array
moritz: or even easier 10:43
moritz nom: my @t = 3, 4; @t = @t xx 3
p6eval nom c285a5: ( no output )
jnthn moritz: get rid of the if block
and just
for @from Z (@to ?? @to xx ceiling(@from / @to) !! '' xx @from) -> $f, $t {
Which will perform better anyway.
moritz: It's array assignment to self + infinite parts in the list that seems to cause the bug. That's why I noted my fixes at the weekend as partial. 10:44
moritz tries
jnthn Works here
10:44 JimmyZ left
jnthn moritz: gist.github.com/1404379 fwiw 10:44
moritz I need to wait for a rakudo recompile before I can try it :/
10:44 JimmyZ joined 10:48 bacek left
moritz nom: for 1 -> $, $ { } 10:58
p6eval nom c285a5: OUTPUT«Not enough positional parameters passed; got 1 but expected 2␤ in block <anon> at /tmp/_e4PgCgHE5:1␤ in method reify at src/gen/CORE.setting:4074␤ in method reify at src/gen/CORE.setting:3981␤ in method reify at src/gen/CORE.setting:3981␤ in method gimme at src/g…
masak nom: for 1 -> $, $? { } 11:00
p6eval nom c285a5: ( no output )
masak nom: for 1 -> $, $? { }; say "alive"
p6eval nom c285a5: OUTPUT«alive␤»
11:01 agentzh joined, bacek joined, woosley left 11:07 bacek left 11:19 bacek joined
Woodi "Agile is the answer to the paradox that we don't know what we should make until we already have a prototype of that thing." perlalchemy.blogspot.com/2011/11/th...hesis.html 11:36
fit to Perl6 and all NQP rewrites :) 11:37
btw, NQP rewrites wasn't Rakudo rewrites as ppls say on PM 11:38
jnthn If anybody bothered to look at the version control for nqp-rx to latest nqp, they'd see it was a series of step by step refactors rather than "throw it away and start over" 11:39
daxim so it kept compatibility? 11:40
masak with what?
jnthn daxim: I'd say Rakudo's grammar and actions are the biggest things written in NQP, besides NQP itself. The main things that changed were the addition of some "use" statements because NQP got proper separate compilation and modules. 11:41
dalek p: ef5f94f | mls++ | / (3 files):
use parrot op to switch to the profiling runcore
 11:46
jnthn Yes, it was basically, just use statements and fixing an accidental nested class because nested packages got fixed. Beyond that, it seems it compiled the Rakudo grammar and actions pretty much fine. Of course, the refactor towards a three way split (Grammar/Actions/World) came after that, but that wasn't due to NQP incompatibility. 11:47
jnthn just dug up the relevant commits out of curiosity.
11:57 wk joined 12:05 benabik left 12:13 Psyche^ joined 12:16 Patterner left, Psyche^ is now known as Patterner, plutoid left 12:31 tokuhirom joined 12:44 cognominal___ joined 12:46 Trashlord joined 12:47 cognominal_ left
dalek ast: da97881 | moritz++ | S05-transliteration/trans.t:
refudge trans.t for rakudo
 12:54
12:56 benabik joined 12:57 molaf left
colomon jnthn: btw, Grammar::Tracer is *awesome* 12:58
dalek ast: b76359c | moritz++ | integration/real-strings.t:
rakudo unfudges
 13:01
kudo/nom: 01ac0d8 | moritz++ | src/core/ (2 files):
bring Str.trans back

Mostly a copy&paste from 2011.07, plus some fixes from jnthn++ and a few small optimizations that avoid some box operations
kudo/nom: d2e4b02 | moritz++ | t/spectest.data:
enable some tests for trans, as well as another test that depended on it
jnthn colomon: Happy you like it :) 13:06
colomon jnthn: admittedly I'll like it even better when I'm not using it to diagnose strange nom regex bugs. ;) 13:07
jnthn colomon: Yeah; I need to look into the $!orig one a bit deeper. Need to take care of some $dayjob bits first, though. 13:08
moritz jnthn: when I do something like my str $r = $StrVar, does that unbox or call the vtable? 13:09
jnthn moritz: Call the vtable. Please explicitly nqp::unbox_s(...) for now. 13:11
moritz: It's a pain to deal with this side of the QAST migration.
moritz that's kinda... suboptimal 13:12
jnthn I'm aware.
colomon nom: say "545" ~~ m/ \d+ /
p6eval nom c285a5: OUTPUT«===SORRY!===␤Confused at line 1, near "say \"545\" "␤»
moritz I wonder what my str $x = 42; # is supposed to do
jnthn wonders what it does :)
nom: my str $x = 42; say $x 13:13
p6eval nom c285a5: OUTPUT«42␤»
jnthn heh :)
moritz call the vtable, I guess
jnthn Magic coercion fail.
colomon b: say "545" ~~ m/ \d+ /
p6eval b 1b7dd1: OUTPUT«===SORRY!===␤Confused at line 22, near "say \"545\" "␤»
moritz colomon: that's a weird backslash you have there
jnthn colomon: There's some weird character in your paste.
moritz colomon: it's color-inverted here
colomon b: say "545" ~~ m/ \d+ /
p6eval b 1b7dd1: OUTPUT«===SORRY!===␤Confused at line 22, near "say \"545\" "␤»
colomon huh
\
jnthn Same here
colomon what if I say \o/ 13:14
?
moritz colomon: that's fine
colomon nom: say "545" ~~ m/ \d+ / # typed over again
p6eval nom c285a5: OUTPUT«=> <545>␤␤»
moritz nom: say '545' ~~ m/ \d\+ /
p6eval nom c285a5: OUTPUT«#<failed match>␤»
colomon nom: say "545" ~~ m/ <digit>+ / # typed over again
p6eval nom c285a5: OUTPUT«=> <545>␤ digit => <5>␤ digit => <4>␤ digit => <5>␤␤»
moritz note that the .gist output is rather suboptimal 13:15
should probably be digit => [<5>, <4>, <5>] or so
Woodi do "str" works faster then "Str" ? why there are doble same types ? 13:17
moritz Woodi: please read S02 and S09 13:18
Woodi oh, ok
moritz (sections on native types)
13:19 kaleem left
jnthn You have to be extremely careful with str. There's a bunch of traps that will get you worse performance. With int and num - yes, you tend to get better performance, somethings massively better. 13:19
Trick when working with native num/int is to avoid method calls.
Since a method call requires an object, which requires boxing, which throws away the benefits. 13:20
Or at least, some of them.
(Of course, that is somewhat subject to change when we get some kind of method inlining. But method inlining almost certainly requires guards to be generated.)
moritz jnthn: I'm currently doing only concatenation and nqp:: ops on my str's 13:22
jnthn moritz: Yeah, your usage of them as generally been fine. It's when you start doing method calls on them that you can end up re-boxing the same string over and over again unintentionally. 13:24
*has
dalek kudo/nom: 8c9caf7 | moritz++ | src/core/Str.pm:
[trans] use native str for collecting the result
jnthn moritz: If there's a lot of substitutions being made you may well get better performance by collecting the parts and then joining. in a similar style to the (fairly well optimized, iirc) Str.join method. 13:25
moritz jnthn: I know, but I'm not yet ready for that level of optimization :-) 13:26
jnthn OK :)
Woodi is 'eq' the fastest way to compare strings ? 13:27
13:28 fridim_ joined 13:38 wk left
masak Woodi: what are you attempting to do? 13:39
I mean, why are you motivated to speed up 'eq'?
13:40 wk joined
Woodi becouse i use it frequently - probably 30k in 10k function calls 13:40
13:40 ethndbst joined, ethndbst left, ethndbst joined
moritz eq is fast, and even faster if you pass variables to it that are typed as Str 13:41
PerlJam Woodi: profile first
Woodi if $prefix eq '+' { if $data eq 'OK' .... } elsif $prefix eq ...
that numbers are from kcachegrind :)
moritz Woodi: if you have many alternatives, a hash lookup might be faster 13:42
Woodi not so many, but hmm....
PerlJam Woodi: hash lookup is still O(1) rather than O(n) ... did you order your conditionals such that the most likely string is tested for first? 13:43
(is there a "most likely"?)
masak there's always one or several most likely :) 13:44
Woodi I try use some order but, realy, I write library module and order depends on live data... 13:45
first will try s/given/if/ ...
oO( means more 'eq'... ) 13:46
but no smartmatch ?
moritz Woodi: it's really hard to follow your questions
Woodi i just ask 'is "eq" fastest'. you sugested hashes and no more questions. except "do given always use smartmatch ?"... 13:49
PerlJam Woodi: given doesn't do it, when does :)
moritz Woodi: 'eq' is fastest for checking strings for equality. Happy? 13:50
[Coke] is "blah" fastest often results in a "it depends" and "did you benchmark" and "show us code".
Woodi PerlJam: it's why I ask :)
[Coke] but, what moritz said, in general. ;)
Woodi moritz: yes!
moritz Woodi: but it's always faster to not run the code at all, by avoiding the comparison in some clever way
PerlJam Woodi: optimizing for speed invariably means adding lots of code to do what moritz just said. 13:51
moritz PerlJam: or removing lots of code :-)
Woodi "do less" is my favourite optimisation method :) 13:52
moritz then use it.
colomon new test file, new weird error: Method 'Str' not found for invocant of class 'CallContext' 13:55
13:55 tokuhirom left 13:56 JimmyZ_ joined
moritz colomon: are you using caller() or so? 13:56
colomon moritz: nope
moritz I've never seen that one.
13:58 JimmyZ left, JimmyZ_ is now known as JimmyZ
moritz jnthn: gist.github.com/1404870 is a segfault + backtrace I get from a simple script using SVG::Plot 13:58
(which depends on SVG, which depends on XML::Writer; I've installed both freshly with ufo + 'make install') 13:59
colomon moritz: .... okay, this stuff is scary
First run of test file: Method 'Str' not found for invocant of class 'CallContext'
Tweak one statement and add debugging output: Works fine 14:00
Turn off the debugging output: Works fine
moritz :(
colomon Revert to original code: runs much further than before, then Method 'uc' not found for invocant of class 'Any'
moritz that's the typical case of the compiler not having had any larger apps yet
colomon it feels very non-deterministic 14:02
PerlJam the debugger is your friend ;)
colomon the tweak I made should have had no effect.
moritz PerlJam: erm, which one? :/ 14:03
PerlJam whichever one he knows how to use.
(though I guess if "inserting debug statements" is the only one, he's out of luck) 14:04
14:05 JimmyZ_ joined, buubot_backup left
moritz oh, and it takes 18s to load SVG::Plot :( 14:06
(and SVG::Plot is only 714 lines, and loads only 3 other small-ish .pm files) 14:07
14:07 JimmyZ left, JimmyZ_ is now known as JimmyZ 14:12 sayu joined
awwaiid colomon, sounds like cached compiler intermediate files messing with you, offhand 14:12
14:13 JimmyZ_ joined, llabthgie joined
colomon awwaiid: except (unless nom is doing something really weird) I ran the code the exact same way every time, ie I shouldn't have been generating new PIR files. 14:15
oooo, I do see part of the problem, though.
14:15 JimmyZ left, JimmyZ_ is now known as JimmyZ
colomon yeah, my revert accidentally toasted my workaround for the LTM bug, which then caused the Method 'uc' not found for invocant of class 'Any' error. 14:16
now if I could only figure out how to duplicate the Method 'Str' not found for invocant of class 'CallContext' error... 14:19
moritz sounds like a really nasty leak 14:24
colomon: is the backtrace any help? maybe with --ll-exception? 14:26
colomon ignoring that, it seems like my big blocker is the Can not bind non-existant attribute '$!orig' on class 'Cursor'
moritz: I can't duplicate the CallContext error at all. It only happened the once. 14:27
moritz hm.
14:28 buubot_backup joined 14:30 sayu left, daxim left, fhelmberger left, envi_ left, Exodist left, wolverian left, rsimoes1 left, mattp_ left, Lothar left
colomon also, as nearly as I can see it was a completely illogical error, by which I mean it occurred in the last test of a series, all of which were exercising the same code. 14:31
jnthn That CallContext one may be a GC bug of some kind. 14:35
14:35 agentzh left
jnthn The same one tadzik has seen occasionally. 14:35
14:36 sayu joined, daxim joined, fhelmberger joined, envi_ joined, Exodist joined, wolverian joined, rsimoes1 joined, mattp_ joined, Lothar joined
moritz just fixed CGI::Application to work on nom 14:36
not a nom regression really, but the now properly done exception stuff 14:37
jnthn Ah, good
moritz: Will investigate the segfault...the stack trace doesn't make that one look GCesque, thankfully.
14:38 sayu left, cognominal_ joined, sftp joined
dalek ast: de6dbd7 | coke++ | S05-transliteration/with-closure.t:
rakudo fudge
 14:40
14:41 cognominal___ left
[Coke] moritz++ # more unfudges 14:41
dalek kudo/nom: 8716958 | coke++ | t/spectest.data:
run fudged test
[Coke] (ok, technically those were fudges, but we can now run the test file, so, net-un-fudge) 14:42
14:45 bluescreen10 joined
jnthn wonders what the net pass count is now if you have ICU 14:48
moritz the HTML::Template is quite curious 14:52
oh, I know why
has $!in;
...
method from_string($in) { self.new(in => $in) } 14:53
but since it's a private attribute, it doesn't get initialized by .new
jnthn That seems like a common thing to need to fix. 14:54
moritz just fixed HTML::Template 14:59
jnthn moritz: Was the above fix all it needed? 15:03
moritz jnthn: no
jnthn: another exceptioin fix
and
one test that did $someException ~~ m/.../
where $someException was of type Exception 15:04
jnthn Should that work, even if it's maybe not the best idea?
moritz dunno
15:08 worr left, mikemol left 15:14 worr joined
bbkr thinks about forking closure-based HTML::Template, this approach should speed it up by the factor of ~120. 15:16
maybe after NOM star
15:27 vifon joined 15:39 alvis joined 15:45 thou joined, thou left 16:00 slavik1 joined 16:12 JimmyZ left 16:13 vifon left 16:17 shortcircuit joined 16:18 daxim left 16:19 shortcircuit is now known as mikemol, mikemol left, mikemol joined 16:21 thou joined 16:29 estrabd_afk is now known as estrabd 16:43 noodles__ joined 16:50 am0c left, noodles__ left 17:03 wolverian left 17:05 wolverian joined
dalek p: 19f994b | jnthn++ | / (329 files):
Merge branch 'nci'
 17:07
[Coke] build gets real unhappy if you delete the perl you used to build and try to reconfigure. 17:10
(switching over to using perlbrew on feather. boom.)
jnthn colomon: ping 17:16
17:19 thou left 17:24 thou joined
dalek p: e62d398 | jnthn++ | src/NQP/Actions.pm:
Ensure references to self in NQP are decontainerized.
 17:25
kudo/nom: b2a9370 | jnthn++ | src/ (7 files):
Merge branch 'nci' into nom
 17:26
kudo/nom: aa15f3a | jnthn++ | tools/build/NQP_REVISION:
Bump to latest NQP revision.
jnthn phenny: tell colomon I think latest may fix the $!orig issue in ABC, though I get "Method 'at_key' not found for invocant of class 'Any'", which iirc you already have a patch for locally? 17:27
phenny jnthn: I'll pass that on when colomon is around.
17:29 mj41 left 17:30 alester joined
TimToady someone needs to ack both parrot and nqp and s/existant/existent/ 17:30
alester I think you can use perl for that. 17:31
TimToady I don't touch implementations, generally speaking.
it's a kindness to masak, who gets to file more bugs 17:32
and I'm just the stuporvisor; the union requires me to stand here and watch 17:33
alester TimToady: Done. 17:34
dalek p: c1c6435 | jnthn++ | src/ (3 files):
Spellos; TimToady++ for noticing.
 17:35
17:37 MayDaniel joined
jnthn moritz: Grr. Just tried to reproduce that SVG::Plot segfault locally and...it didn't segfault. :S 17:39
moritz :( 17:40
jnthn moritz: NCI stuff all merged, BTW. Testing appreciated. 17:41
Though there weren't any merge conflicts at all, so I doubt much will have gone awry.
Grr. I even upped it to 1..1000 rather than 1..100 and it didn't explode.
moritz djanatyn: sorry, I didn't know that I had to acknowledge the claim for that NCI task
17:43 MayDaniel left
jnthn moritz: Hm. Even producing a much larger output graph doesn't tickle it. 17:44
moritz: What platform are you on? 64-bit Linux, I guess?
moritz jnthn: yes
jnthn is on 64-bit also, though Windows :)
moritz: Was it very reproducable, or just "sometimes"? 17:45
moritz jnthn: i've tried it once or twice
17:47 kaleem joined
colomon jnthn: yes the at_pos in Any thing was because LTM wasn't working correctly. 17:47
phenny colomon: 17:27Z <jnthn> tell colomon I think latest may fix the $!orig issue in ABC, though I get "Method 'at_key' not found for invocant of class 'Any'", which iirc you already have a patch for locally?
17:47 wk left
jnthn colomon: Yeah, it's just NYI for the standalone alternation case...works for the protoregex one (which may have alternations...) 17:47
colomon at any rate, in my case it was easy enough to work around by switching the order of the cases. :) 17:48
17:48 thou left
tadzik ooh, nci :> 17:53
17:53 thou joined
cognominal_ jnthn, are you close to get a :from<nqp> ? 17:58
17:58 kaleem left
cognominal_ jnthn is writing code faster than I can read it. 17:58
I can't figure out, the global or whatever which hold a reference to all things loaded. 17:59
colomon jnthn: looks like the patch works, at least the test is running for a LOT longer now. (Probably because I'm tracing a bunch of complicated regex work.) 18:00
cognominal_ maybe the EXPORT_SYMBOL is a good place to start.
18:01 tokuhirom joined
colomon jnthn: hmm, new error is Method 'count' not found for invocant of class 'Continuation' 18:02
tadzik ha, GC bug I guess 18:03
try parrot -G perl6.pbc <code>
jnthn Ugh...that's nasty. 18:04
(GC bug)
cognominal_: It's not especially close; there's a whole bunch of more pressing stuff right now, I'm afraid.
18:04 dakkar left
jnthn cognominal_: There *isn't* a single global view any more. 18:04
cognominal_: That's why some kind of "use" is needed 18:05
cognominal_ ok, thx for the info. 18:06
I thought one things got "used", you could get them from some "root" place. 18:07
so a use becomes a noop since the second time from which you cant get at stuff? 18:08
jnthn cognominal_: Well, the module loader keeps track of the stuff
cognominal_: Basically, it holds on to the UNIT of the loaded module
From that its view of GLOBAL and EXPORT are looked up whenever it is used. 18:09
tadzik pararell build broken in nqp? 18:10
18:12 icwiener joined
jnthn Hopefully not...it was then moritz++ mentioned it works. 18:12
PerlJam cognominal_: Would the second use be a noop or would it still import the appropriate symbols?
jnthn PerlJam: the answer is the latter :)
18:19 ksi joined
tadzik oh, I'm on nci branch 18:23
colomon jnthn: okay, looks like ABC finishes tests with no crashes other than the random GC(?) ones. 18:29
jnthn: (that's on my local nom branch) 18:30
cognominal_ ePerlJam, jnthn, I meant that if the use was called with the same parameters, it would result in the importing of the same set of symbols so it could be viewed as a noop 18:31
PerlJam cognominal_: not if some other "use" had mangled those symbols in the mean time. 18:32
tadzik nqp build failure: gist.github.com/1405864
cognominal_ Perljam, indeed. 18:33
jnthn tadzik: oh...I upgraded to a later dyncallib and may have blown away your patch to that file
tadzik we should patch it upstream probably :) 18:34
can you reapply it? I have to learn the damn C++
jnthn tadzik: will do 18:35
tadzik thanks
colomon nom: say "[K:F]" ~~ m/ '[' (<alpha>) ':' (.*) ']' / 18:39
p6eval nom aa15f3: OUTPUT«#<failed match>␤»
colomon nom: say "[K:F]" ~~ m/ '[' (<alpha>) ':' (.*?) ']' /
p6eval nom aa15f3: OUTPUT«#<failed match>␤»
dalek p/qbootstrap: 7508c6a | jnthn++ | tools/build/Makefile.in:
First steps towards getting NQP bootstrapping with QRegex. This just twiddles the makefile so we always build QRegex during stage 2, and then build NQPQ as the stage 2 NQP.
p/qbootstrap: 6060370 | jnthn++ | src/QHLL/ (5 files):
Add a temporary QHLL copy of HLL to help facilitate the bootstrap.
p/qbootstrap: 70ac5d0 | jnthn++ | tools/build/Makefile.in:
Build QHLL in stage 2.
jnthn tadzik: oh, it's not a straightforward application of the same patch, the file got moved/renamed 18:40
tadzik: need to eat, will look after dinner 18:41
tadzik sure thing
18:41 hundskatt joined 18:44 buubot_backup left
diakopter /usr/local/bin/parrot: corrupted double-linked list 18:50
18:51 fridim_ left
diakopter every time 18:51
18:52 wolfman2000 joined, fridim_ joined
colomon niecza: say "[K:F]" ~~ m/ '[' (<alpha>) ':' (.*?) ']' / 18:52
p6eval niecza v12: OUTPUT«#<match from(0) to(5) text([K:F]) pos([#<match from(1) to(2) text(K) pos([].list) named({"alpha" => #<match from(1) to(2) text(K) pos([].list) named({}.hash)>}.hash)>, #<match from(3) to(4) text(F) pos([].list) named({}.hash)>].list) named({}.hash)>␤»
colomon b: say "[K:F]" ~~ m/ '[' (<alpha>) ':' (.*?) ']' /
p6eval b 1b7dd1: OUTPUT«[K:F]␤»
18:58 ashleydev left
jnthn colomon: Oh...you've found the infamous backtracking bug :/ 18:58
18:59 ashleydev joined, ashleydev left
colomon jnthn: suggested workaround? 19:00
19:00 ethndbst left
jnthn nom: say "[K:F]" ~~ m/ '[' (<alpha>) ':' .* ']' / 19:00
19:00 ethndbst joined
p6eval nom aa15f3: OUTPUT«=> <[K:F]>␤ 0 => <K>␤ alpha => <K>␤␤» 19:00
jnthn nom: say "[K:F]" ~~ m/ '[' (<alpha>) ':' $<other>=[.*] ']' / 19:01
p6eval nom aa15f3: OUTPUT«=> <[K:F]>␤ 0 => <K>␤ alpha => <K>␤ other => <F>␤␤»
colomon b: say "[K:F]" ~~ m/ '[' (<alpha>) ':' $<other>=[.*] ']' /
p6eval b 1b7dd1: OUTPUT«===SORRY!===␤Confused at line 22, near "\x{2}say \"[K:F"␤»
jnthn colomon: That one. It's backtracking into captures
colomon: btw, <alpha> already captures, so (<alpha>) is capturing it twice.
colomon jnthn: good point 19:02
perl6: say "[K:F]" ~~ m/ '[' (<alpha>) ':' $<other>=[.*?] ']' /
p6eval rakudo aa15f3: OUTPUT«=> <[K:F]>␤ 0 => <K>␤ alpha => <K>␤ other => <F>␤␤»
..niecza v12: OUTPUT«#<match from(0) to(5) text([K:F]) pos([#<match from(1) to(2) text(K) pos([].list) named({"alpha" => #<match from(1) to(2) text(K) pos([].list) named({}.hash)>}.hash)>].list) named({"other" => #<match from(3) to(4) text(F) pos([].list) named({}.hash)>}.hash)>␤»
..pugs b927740: OUTPUT«Error eval perl5: "if (!$INC{'Pugs/Runtime/Match/HsBridge.pm'}) {␤ unshift @INC, '/home/p6eval/.cabal/share/Pugs-6.2.13.20111008/blib6/pugs/perl5/lib';␤ eval q[require 'Pugs/Runtime/Match/HsBridge.pm'] or die $@;␤}␤'Pugs::Runtime::Match::HsBridge'␤"␤*** '<HAND…
19:04 ashleydev joined, ashleydev left, Chillance joined
colomon jnthn++ 19:04
19:04 buubot_backup joined 19:06 ashleydev joined
colomon I have all ABC tests passing! 19:09
dalek p: 47e75d0 | jnthn++ | 3rdparty/dyncall/dynload/dynload_syms_elf.c:
Hopefully fix the build for tadzik++.
 19:10
jnthn \o/
19:11 GlitchMr joined
jnthn tadzik: hope that helps :) 19:11
tadzik: And yeah, should probably submit upstream.
19:13 arlinius joined 19:19 [particle]1 joined 19:20 [particle] left, fsergot left
tadzik jnthn: yeah, -j1 builds now :) 19:21
19:28 [particle]1 is now known as [particle]
colomon and I just converted seven tunes to Lilypond! 19:29
tadzik jnthn: so which NativeCall branch is now functional? 19:37
jnthn tadzik: v2 19:38
19:38 Mowah_ joined
tadzik jnthn: 1) any reason why not merge it? 2) which tests/examples should run? 19:38
19:41 birdwindupbird joined, birdwindupbird left
jnthn tadzik: 1) none now that I've merged the other nci branches, 2) didn't have chance to triage them 19:41
bbiab
japhb TimToady, did you find enough brane to make a decision about irclog.perlgeek.de/perl6/2011-11-25#i_4755358 ? I saw you had discussed with jnthn++ the (I assume) related question of moving Failure out of Any, but did that lead to a conclusion on the original question? 19:43
19:45 Chillance left
masak spec updates or it didn't happen :) 19:45
19:46 Chillance joined 19:48 fsergot joined, kaare_ joined 19:49 Mowah_ left
jnthn back 19:54
20:10 arlinius left 20:18 fsergot left 20:21 miso2217_ left 20:23 cooper joined 20:24 miso2217 joined 20:37 wolfman2_ joined, ethndbst left 20:38 wolfman2_ left 20:39 fsergot joined, wolfman2000 left 20:41 birdwindupbird joined 20:42 birdwindupbird left
japhb masak: <tone variant="hopefully">He could have made his decision and just not finished the spec updates ...</tone> 20:45
PerlJam japhb: You should know how quickly things progress with the language spec by now ;) 20:48
20:50 fsergot left 20:52 arlinius joined, mj41 joined, molaf joined
japhb PerlJam, yeah, I know. It's just fundamental enough to be blocking multiple different areas I've been working on, and I don't want the work I already put in to just sit and bitrot. :-( 20:52
masak japhb: do you have a favorite resolution of the issue yourself? 20:59
jnthn is in favor of the "Failure is outside of Any" approach. 21:00
Until/unless I see a strong reason why not to do that, anyway.
Thing is, that's easy enough to say, but then we need to figure out the upshot of it. 21:01
japhb masak: Well, this all started with me talking myself in circles, but that was before TimToady floated the idea that jnthn favors
jnthn Like, how does said failover look.
japhb must handle a $day-job task for the $Big-Boss, and then can think more heavily on this variant 21:02
21:02 MayDaniel joined
PerlJam all we need is for someone to implement "Failure outside of Any" and see what happens :) 21:03
japhb PerlJam, I'm not sure I've got the core knowledge to be able to get something that pervasive right everywhere. But if no one else offers, I may see what I can manage. 21:05
21:05 ethndbst joined
Tene japhb: you don't need to get it right everywhere, just get it right in enough interesting places that someone else can clean up the rest. ;) 21:05
japhb Tene: well, there is that. :-)
jnthn :P 21:07
I can't help but wonder if TimToady is going to come back with some generalization of out-of-Any failover that junctions and failures and each hang off. 21:08
21:08 GlitchMr left
japhb Well that's the other point ... I'm a bit worried about throwing non-negligible tuits at something that soon after gets redesigned 21:10
21:12 Chillance left
jnthn japhb: At this point I'd be inclined to wait a little. 21:12
PerlJam you can't second guess the future. You can only act on what you know to be true.
masak know the feeling.
PerlJam so, it depends on how urgent you feel you need something to happen.
japhb Nodnod. 21:13
Thanks for the advice, guys, I appreciate it.
jnthn japhb: This is for the numeric work, iiuc?
japhb: Does it tie into val and MAIN handling too?
(just trying to get a clear idea of exactly what's blocked on it...)
japhb Yes, all three, and I was looking at working on some related test files. 21:14
But I can't even fix/write tests if I don't know what *should* be happening. :-/
So 4 paths of hacking blocked. However, my 5th one (trying to get OpenGL working under nom) is rapidly being unblocked by you, so I may have another -Ofun soon. 21:15
But I also don't want to leave the other work unfinished, it's important stuff, and I want that fine feeling of getting those items to finally be spec-compliant. 21:16
jnthn japhb: Yes, I agree it's important, and I'm really glad you're working on it. 21:17
japhb jnthn, thank you.
jnthn The NativeCall stuff is coming along. It turns out that pondering the nature of handling C arrays led me to have to think about a load of stuff I'd been somewhat putting off thinking about. 21:18
TimToady the problem with Failure outside of Any is that it prevents returning Failure from a function that returns a type like Int.
21:18 MayDaniel left
jnthn TimToady: Provided that doesn't just failover too... 21:18
Tene TimToady: how is that any better with Failure in Any?
TimToady Failure has up till now been thought of as a bottom type 21:19
jnthn It's not really. AFAIK, the other serious alternative is that Failure is a role that is mixed in to any type.
Oh, or that :)
21:19 tokuhirom left
japhb jnthn, (re NativeCall): yeah, and C arrays is probably the biggest remaining sticking point for OpenGL work. 21:20
"bottom type"?
jnthn japhb: I got a long way with the thinking last night. It's just that it ties in to another near-term thing and multiple long-term things...
Tene japhb: en.wikipedia.org/wiki/Bottom_type
PerlJam japhb: the last turtle
jnthn ...so I'd rather get it rightish.
japhb jnthn, gotcha, please do. :-)
Tene TimToady: I don't actually see the relation between "Failure is a bottom type" and "Failure is in Any" 21:21
jnthn TimToady: I worry a bit about bottom types. 21:22
japhb PerlJam, that was my guess, which seemed like an odd way to say it, but Tene's link (thanks!) gives some useful detail to that.
jnthn TimToady: From an optimization view, I'm bothered that we suddenly can't make so many assumptions.
Tene Also, returning Failure doesn't seem to match with what Wikipedia discusses there, afaict.
PerlJam Tene: if Failure is outside of Any it can't be used as a bottom type for those things that accept Any I expect 21:23
jnthn TimToady: For example, if I see Int, I can probbly know something about representation. I can generate code that is faster because it makes assumptions. 21:24
TimToady: I worry a bottom type means we'll have a bunch of extra checks to do.
PerlJam sentinels are usually there to get rid of extra checks.
21:25 bluescreen10 left
jnthn PerlJam: Can you elaborate a little? :) 21:25
jnthn thinks he sort of half-ish sees that PerlJam may be saying :)
PerlJam It seems to me that Failure outside of Any will result extra checks and that Failure in Any allieviates these. 21:26
jnthn oh wow, the guy who supervised my degre project is one of the references on that Wikipedia page. :)
PerlJam (assuming we continue using Failure as we have been)
jnthn PerlJam: Maybe I'm just not thinking hard enough about it...but basically "outside of Any" means that it gets detected because a type check we'd have had to do anyway fails. 21:28
PerlJam The more I think about it, the less I like "Failure outside of Any"
jnthn Of course, then we run into the issue that
my Int $x = something-that-fails(); # type check fails on the assignment...then what?
And if we say "oh, make it work somehow" then we're back to the same kind of problem for optimization. 21:29
So they're probably both about as problematic on a sense.
*in
Essentially, outside of Any means that we rely on type checks failing and doing something as a fallback. 21:30
PerlJam aye, I see what you're saying 21:31
jnthn Bottom type means Failure can be stored pretty much all the time. So then the question is...what makes it explode?
PerlJam If we had type-inference ala Haskell, Perl would make it explode in either case ;) 21:32
jnthn Well, I know how outside-of-Any is going to.
TimToady I think if we go with outside, the place to fudge it is in the return, depending on the caller's preferences 21:33
jnthn The "bottom type" is likely not going to hit a problem in, say, +, until the bigint addition op tries to grab the bigint part out of it and fails.
PerlJam So, like many things in Perl 6 land, I've thought about this enough to make my head hurt, but not enough to see a path forward that makes good sense.
TimToady so that a hyperop can tell the returner that it's okay to violate the return type
jnthn TimToady: What about ops, though? 21:34
TimToady what about 'em? 21:35
jnthn TimToady: $some-failure + 1
TimToady: Is that a dispatch failure? If so, does it failover? If it fails over, what to, and how do we specify that? Is it a generic thing? 21:36
colomon should be another failure, right?
jnthn etc :)
colomon: Seems so
TimToady it fails to dispatch the +, if + is Any, and Failre is outside
jnthn OK, here's my real worry
$a = $b + $c;
TimToady but that can probably throw, by current spec
jnthn $d = $a * 2; 21:37
Imagine that all of those were decalred as Int
TimToady including the ops?
PerlJam but then they'd be $i, $j, $k, and $l ;)
jnthn The optimizer says "oh, great, I can inline those ops!"
PerlJam jnthn: but it would be wrong for failure? 21:38
jnthn TimToady: As in, their return type?
PerlJam: Yes.
And if we can't inline reliably, we're in trouble.
TimToady well, it doesn't really matter if the returner or the dispatcher fails the Int check, as long as someone throws the exception 21:39
jnthn TimToady: ah, so:
TimToady I'm assuming only hypers and such would suppress the Int check on return
jnthn my Int $a = lol-i-fail(); # type check fail? 21:40
And
TimToady the inliner can inline when it sees there's another Int check in the dispatch
jnthn sub foo() returns Int { fail() } # what about this?
[Coke] colomon++ # just saw the abc fix message.
colomon [Coke]: I even added a simple README for you. ;)
[Coke]: you need to thank jnthn++ as well, he had to fix a nom bug for me and suggested a couple of work arounds as well. 21:41
jnthn TimToady: I don't quite understand "another Int check"
TimToady I suspect an explicit fail() also overrides the return type check
there's an outgoing Int constraint on the return, and an incoming on the +
jnthn TimToady: OK, agree with that bit. I'm asking what might be "violated" :) 21:42
TimToady: That is, can the optimizer/type checker rely on something that is marked "returns Int" actually returning Int?
[Coke] jnthn++ # sneaky ABC karma 21:43
jnthn TimToady: Or does it have to assume that it may fail() unless it can prove otherwise?
TimToady as long as it blows up somewhere reliably if you don't have an Int, with sufficiently localized information to determine what the error was, I don't care who throws the real exception
colomon [Coke]: even better, I've basically been waiting to be able to use Grammar::Tracer to start hacking on ABC again. There's lots of further things I'd like to implement...
jnthn TimToady: Well, but I worry whether we'll be lazy enough about Failure 21:44
TimToady any failure that is accidentally passed into an op should still carry the information about the original failure
PerlJam Failure seems like tainting all of a sudden.
TimToady the lazy failures are really a caller policy for parallelism
in the non-parallel case, we're only giving the user opportunity to say foo() // die 21:45
other than that, not much use case for lazy exceptions
jnthn OK, gotcha.
TimToady well, and also to allow your optimizer to make assumptions when the failure can be caught elsewhere reliably 21:46
jnthn Well, and also to know when a variable simply can't be a failure. 21:47
japhb And this brings me back to (part of) my original question. If a Failure can float around for a while before finally throwing up, what exactly causes that to happen? Does it propagate endlessly sort of like NaN? Does it throw only when it falls out of scope without being handled? Does every op have to check for it? Only some ops? ... 21:55
masak 'night, #perl6
japhb s/throwing up/throwing/ # Heh
o/
PerlJam japhb: I think it was righter originally ;) 21:56
jnthn japhb: Well, if we're saying it's outside of Any, then only ops that explicitly want to accept Failure and do something special with it would have to care. 21:57
japhb: Just as almost every op can ignore junctions.
Then we'd have a failover option
So it'd be like the junction auto-threader...apart from for failures. 21:58
I guess it'd make another failure with the original one contained within it.
benabik my $failure = fail 1; fail $failure # lolwut?
jnthn At some point either a type constraint will cause it to explode becuase you're putting it into a container that can't take Failure, or some other context that can't. 21:59
benabik: fail is like return :)
japhb jnthn, right ... but one of your previous points was about inlining and the optimizer. If the optimizer gets really lucky and manages to inline a lot of stuff in a row ... does it have to add checks for Failure at all the points in the original code that would have been calls?
jnthn japhb: No, because if it has a variable of type Int, that variable could never have successfully been assigned a Failure.
benabik jnthn: my $failure = (sub { fail })() #? Okay, that's somewhat obviously abusing the system. 22:00
jnthn benabik: If you do that, you'll get a Failure object in $failure.
benabik: Since the default type constraint on a scalar is Mu.
benabik jnthn: And passing it to fail causes a nested failure?
japhb jnthn, hmmm ... OK, as a concrete example, how would you implement infix:<==> in this new world?
benabik nested failures seem wierd.
22:01 ksi left
PerlJam "Failure oustide of Any" seems like we'd end up with lots of op variants with Failure arg types to DTRT (whatever that is) 22:02
jnthn PerlJam: No, the idea is that we *wouldn't*
japhb: Imagine we have $a == $b and one of them is a Failure
colomon because failure to dispatch is a failure?
jnthn japhb: The multi-dispatcher would fail to find a candidate.
It would then look at whether there's a special type of handler for this kind of dispatch failure - basically, we just generalize the mechanism we already have that does exactly this for junctions. 22:03
PerlJam "this kind of dispatch failure"? 22:04
jnthn Presumably, the handler for failures is then called instead of any of the op variants. It probably packages up the existing failure with some extra "then you tired to do this to it" info...or maybe just tracks it.
er, tracks the original error
22:04 benabik left
jnthn Now, if the question is, what happens if I have the (Any, Any) candidate, which does .Numeric, and one of those .Numeric calls returns Failure 22:04
That candidate is $a.Numeric == $b.Numeric 22:05
That second dispatch would fail, and hit the failure failover.
japhb Let me rephrase my question, since I think it came out differently than I'd intended: How would you implement infix:<==> so that it is still inlineable?
jnthn japhb: ah, I've been a bit unclear here maybe.
japhb: It's *individual candidates* that are inlinable.
japhb: The (Int, Int) candidate, for example, would be inlinable. 22:06
japhb Ah!
jnthn japhb: We could never inline an (Any, Any) if there is an (Int, Int) anyway.
japhb So if you ever have multiple candidates, no inlining for you
gotcha!
jnthn japhb: The rules are a little fun for that. But basically, if you can't be sure which candidate you're heading to, no inlining. 22:07
japhb OK, this is making more sense. I at some point got the impression that you were handling the case of multiple candidates where you can define a strict ordering of types in a somewhat-more-efficient-than-normal-multi-dispatch manner
PerlJam does the special failure processing interact with autoloading? 22:08
jnthn PerlJam: I hadn't considered it as doing so, so far...but interesting point :) 22:09
PerlJam: At the moment junction failover is basically done by looking through the capture and saying "so, do we have a junction in here that's to blame".
22:11 kaare_ left 22:15 imarcusthis left
jnthn japhb: Well, we sort candidates statically, if that's what you mean. 22:15
jnthn guesses TimToady will read this lot and yell if I've told any of it really rong :) 22:17
22:17 imarcusthis joined
japhb jnthn, I meant something along the lines of candidates for Int, Real, Numeric, Any, and Mu, and inlining a fast ladder typecheck and jump to the body of each inlined candidate. 22:18
jnthn japhb: Oh
japhb: No, I'm not doing that (yet)
japhb: That's kinda worthwhile if you can pull the ladder outside of a tight loop, I guess. 22:19
Well, more worthwhile
japhb sure.
I had just gotten confused and thought you were *already* doing something like that. :-) 22:20
jnthn No, the optimizer isn't so adventurous yet. :) 22:21
cotto jnthn: do you have any idea when 6model will be stable enough that it'll start to make sense to port it to Parrot core? 22:25
jnthn cotto: Large parts of 6model are already decidedly stable. The last large change was to the REPR API, and it was sufficiently internal that the change didn't actually spill out of the interface provided by the ops. 22:27
cotto: The work to come is about how 6model thinks about representations for things besides attribute-storing objects. 22:28
cotto: Tied into that is how you actually bootstrap 6model from zero.
I've been adding various representations, but those are just more implementations of an existing interface. 22:29
And not actually in 6model core.
cotto jnthn: other things like opaque chunks of memory or opaque pointers?
jnthn cotto: Arrays. 22:30
cotto: This has come up because I need to do C arrays.
japhb jnthn, in case it comes up:
jnthn cotto: I've been working on how NCI style stuff and 6model fit together. The answer is "really neatly"
cotto: But the array bit...6model was just never in that business before. 22:31
japhb It is really helpful to be able to have multiple array "views" (with different type info, etc.) into the same chunk of memory.
jnthn cotto: If I can define where I think this is really heading, I guess I'd label it something like "ubiquitous representation polymorphism" 22:32
japhb: That feels like something I can trivially provide. 22:33
japhb (I guess not just type info, but stride, offset, etc.)
jnthn, excellent!
22:33 MayDaniel joined
jnthn japhb: I mean, at some level, what's an array other than a pointer and some rules about how to compute offsets from it... :) 22:37
japhb jnthn, of course. :-) I just wanted to make sure that the API did not make assumptions that the owner of the array header (pointer + rules) was also the owner of the bits at the other end of that pointer. :-) 22:39
japhb remembers that PDL had a field day with that separation 22:40
jnthn japhb: Ownershp is a tricky issue in all of this.
*ownership
japhb I'm not surprised. 22:41
.oO( QueryInterface, AddRef, Release ... *shiver*)
jnthn japhb: Well, "don't guess" is probably a good policy... :)
japhb I can back that one. ;-)
22:58 benabik joined 23:09 mtk left
jnthn starts to twiddles that will let him get NCI arrays in over the next few days :) 23:13
japhb yay! 23:15
23:19 ethndbst left 23:20 ethndbst joined, ethndbst left, ethndbst joined 23:27 mj41 left 23:29 alester left 23:32 MayDaniel left, tokuhirom joined 23:37 whiteknight joined 23:38 whiteknight is now known as Guest28440 23:48 tokuhirom left 23:52 fridim_ left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!