pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, smop: etc.) || We do Haskell, too | > reverse . show $ foldl1 (*) [1..4] | irclog: irc.pugscode.org/
Set by TimToady on 25 January 2008.
00:02 lambdabot left 00:08 thestarslookdown left 00:12 justatheory left
meppl good night 00:31
00:31 masapong joined 00:33 meppl left 00:41 junzi joined
pugs_svnbot r20444 | lwall++ | [STD] continue removing old quotesnabber stuff 01:02
01:34 IllvilJa left 01:38 nipotan left, nipotan joined 01:56 alester joined 01:58 braceta joined, braceta left 02:02 Limbic_Region left 02:06 justatheory joined
mncharity steven_/Auzon/etal: I was wrong. The "cut startup time by 1/2" I saw wasn't my edits... it was an artifact of using a different version of perl. doh. 02:18
Startup in 5.10 is ~1/2 the time of startup in 5.8.8, despite what I believe to be similar Moose installs. But perhaps I'm wrong about that last bit. 02:19
pmurias: could you add a note to elf_f_src/README on how elf_f_nomoose was created? I went to update it and hit unexpected diffs. 02:28
pugs_svnbot r20445 | putter++ | [elf_f] Now uses #!/usr/bin/env perl instead of #!/usr/bin/perl. This makes getting 5.10 more likely, and 5.10 appears ~1/2 the startup time of 5.8.8. 02:33
mncharity re artifact, so it turns out using Moose in a less messy manner won't actually help us. The 2 sec startup hit is better, but... we've no idea how to make it go away. 02:34
Actually, the cleaned up version starts up 10% faster. And 25-30% of the startup is doing the immutable optimization. Leaving ~1sec as a puzzle. 02:41
pmurias: hmm... it seems _nomoose can't be compiled by elf_f or elf_e? and can't compile itself? what am i missing...? 02:54
nomoose -> faster 02:58
pugs_svnbot r20446 | putter++ | [elf_f] Renamed the "nomoose" variant to "faster". It's not quite working.
r20447 | lwall++ | [STD] <...> quoting working again using Moose now 03:19
03:23 bsb joined 03:26 junzi left 03:37 pbuetow_ joined
mncharity Wow. elf_f_faster self-compiles in 4 sec (if the parsetree is cached). 03:41
pugs_svnbot r20448 | putter++ | [elf_f_faster] Now compilable by elf_f and itself.
mncharity vs 14 sec for elf_f, and a parse time of 15 sec. 03:42
perhaps it's time to profile STD_red again... 03:43
03:49 pbuetow left
mncharity TimToady: re parsefail and fudge, at least for elf, parsefails are no longer the bottleneck. 70% of t/ currently parses. it would be nice to have more, but... the main current obstacle to getting information from individual test success/failures is instead the emitter/runtime - locally broken p5 code causing 03:50
p5 not to run, or runtime errors stopping it. both before other, possibly passing tests, are reached.
03:52 silverspeed joined
mncharity yes, it would be possible to go through and manually flag tests to be skipped. but... that's most/a great many of them. and change with every tweak of the parser and compiler. changes which you want to stay aware of. so... it's not clear to me that fudge helps much with this. 03:53
pugs_svnbot r20449 | putter++ | [elf_f] Add run-tests result for elf_f_faster. 03:57
mncharity Thinks there are 32909909 tests. :) And may also have other issues. But... 8 minutes to run t/. Happiness. 03:58
03:59 silverspeed left
mncharity caveat is of course that it takes very little time to do nothing. 04:03
so it's mainly an observation on overhead.
mncharity tries to remember where p6 notes the process id... 04:04
04:07 kst` joined, kst left 04:08 justatheory left
mncharity using speculative $*PROCESS_ID 04:10
TimToady it's just $*PID 04:18
mncharity ah, ok. thanks. 04:19
04:20 bsb left
mncharity muses that with elf_f_faster, one might create a tool which takes a .t file, and repeatedly reruns it on file fragments, to automagically figure out which parts are breaking the test. 04:22
s/fragments/subsets/
that might not even be very hard... hmm... 04:24
04:35 eternaleye left 04:38 Psyche^ joined
mncharity re 32909909, I keep forgetting how nearly identical elf_f and elf_f_faster are. it was again a perl version artifact. 04:38
TimToady I'm still trying to decide what the relative LTM of terminators should be with respect to ordinary tokens. 04:40
04:40 eternaleye joined
TimToady should <?before <foo bar>> dwim or should <?before >> > dwim? 04:41
can argue it both ways...
should all terminators take precedence over all normal tokens, or vice versa, or should I attempt to interleave them by length? 04:42
for sure /a || b/ has to not treat it as /a | | b/ 04:44
so I think I need to interleave them and make them pretend to be tokens, even though they're not part of the current sublanguage 04:45
and probably sanest to explain non-dwimminess in terms of LTM
so at a point where >> is a valid token, you have to say > > to get two > terminators 04:46
(good thing there's no )) token in normal Perl :))
04:50 Patterner left, Psyche^ is now known as Patterner 05:00 kst`` joined
mncharity backlogs 05:00
05:01 kst` left
mncharity re "even though they're not part of the current sublanguage", is that necessarily true? ie, if W is the terminator, might not a sublanguage allow \W to escape it and ignore it's terminator-ness? 05:03
where it only allows \W because W is the current terminator.
05:05 kanru left
TimToady for instance, in q/foo/ the current sublang is single quoting, but the / as a terminator isn't really part of that language 05:08
and I don't want to derive a new lang every time someone says q!foo! or q%foo%
mncharity ah, ok. 05:09
so terminators are expression terminators, so the issue is ... err, in what sublanguage are EXPR terminators problematic? 05:13
or... I see, calling / a terminator, even though it's not a <terminator>.
?
TimToady every language has both internal and external terminators 05:15
the internal ones we can precalculate a lexer for 05:16
the external one's tend to be dynamically determined by context
*ones
certainly a terminator like / in /foo/ has to take precedence over nibbling the next char and treating / as a character to match 05:17
even though that's the same length
mncharity if the external tokens are treated as tokens, then for some lexer implementations, you will have to do a custom lexer. 05:18
*external terminators
in interpolated contents, any external terminators can't be treated specially, no? 05:20
TimToady the internal escapes can be handled by normal lexing--I'm doing that now, more or less, though it's largely untested 05:21
mncharity i was thinking "$a" where $a has a ", but... that doesn't quite work. /$a/ where $a = qr{/}? 05:22
ie, wondering if one ever needs to have two lexers, one understanding the terminator, and one which must not for "things which get inserted and thus can't be looked at, but which still need to be lexed here". 05:23
TimToady there isn't anything that does double interpolation like that 05:28
hmm, looks like "\n" doesn't parse the \n as an escape yet, sigh 05:29
probably a similar problem somewhere of matching . at the same length as \ 05:30
so probably an ordering issue on LTM
mncharity perl -we '$a=q{\4/}; print qr/$a/;'
re double, which lexer is doing the \4, and recognizing it's a problem, but not considering / to be a terminator? 05:31
TimToady the perl5 lexer contains a great deal of bogosity due to reparsing and treating rx as strings 05:32
mncharity ah, ok. all gone in p6.?
TimToady in general we never do that in p6
strictly single-pass parsing
05:32 Auzon joined
TimToady but it means we have to keep careful track of which language we are in, and know when to "pop" back to the previous set of terminators 05:35
and that, of course, is one of the reasons we're doing most of the parsing with recursive descent
mncharity for whatever it's worth, redsix took the "it's just a token" approach. 05:36
TimToady bottom-up engines really only work for a fixed language 05:37
hmm, no, the nibbler has a :: before the . matching, so LTM should always prefer the escape. 05:39
must be some other problem...
probably some insufficiently moosified role or some such... 05:40
well, back to reading traces...
mncharity re redsix, rather, each "redsix token" is made up of n lexemes, which are the unit of precedence parsing. so < > is just two lexemes, and the second gets added to the currently valid set when the first is parsed, and then dropped from the set when it's eventually seen. 05:41
so you can do smalltalk-like n-ary "tokens". :) 05:42
TimToady does that work for q[[ ]] and such? 05:43
05:45 jan_ left
mncharity looking... 05:46
05:52 kst`` left
mncharity it didn't in redsix (the whole pugs parser concept of balanced delimiters was dropped in favor of quick special-case fakes). whether it could or not... 05:53
TimToady it's also not entirely clear whether one wants to check the terminator set on every lex decision; there could be a different set of terminators for expect_infix than for expect_term 05:57
and, in fact, \s{...} is probably one of those, since {...} is a fine term, but maybe that just means that {...} is a funny terminating infix
mncharity re "whether it could", I suspect it would have been straightforward to add. q[[ ]] would just call EXPR with the second lexeme ]] (the lexemes linked back to their "token"s) to be added to it's lexeme working set. 05:59
TimToady but it's also fine as a terminator, if you buy that (1+) doesn't require expect_term to check for )
mncharity lol # funny terminating infix
(1+) reminds me of \(2:) which went by recently, where : is normally an infix, but here... 06:00
TimToady some infixes that delimit list terms are allowed to have a right nullterm 06:01
comma too
but you still can't write for 1,2,3, { .$say }
since the closure would just be the 4th term in the list 06:02
mncharity one of the "TimToady: (" n STD.pm observations was that while EXPR would parse '3,', it would forget there was a , there, returning just the 3. 06:03
TimToady alternately (and this might actually be what the spec says), you aren't allowed to use a closure in a list like that without parenthesizing the whole list
that view would make \s{} a hard terminator that doesn't pay attention to infix/term 06:05
mncharity err, I don't get that last part. (4, {}) would have to parse, so how could the {} be a terminator? (in either of the two meanings we've used)? 06:07
TimToady it would be a terminator set by the "while" for the top level only, so inside parens would have no effect 06:08
mncharity ahh
TimToady not clear what people will expect most of the time
mncharity circumfix:<while {<statementlist>}> :) 06:09
TimToady heh
but we don't currently do anything terminator-y with the 2nd element of <sym> 06:10
mncharity can the 2nd elem of sym ever work if it's also a valid postfix op? ie, the EXPR would grab it and never give it back. 06:13
circumfix:<zz ++>... $x = zz 3 ++; 06:14
Eevee er. 06:16
TimToady postfix cannot have space before it 06:17
Eevee interesting
06:20 bsb joined
mncharity ah, ok 06:29
06:35 alester left 06:36 [particle1 joined
spinclad $x = zz3++ 06:36
mncharity my 'svn up' seems to be hanging... :/ 06:37
spinclad circumfix:<-- ++>... $x = --3++;
06:37 [particle] left, stevan_ left, thepler left, exp_evalbot left, rafl left, gbacon left
TimToady hangs for me too 06:39
spinclad $hangup = "{sleep 3;}+++{sleep 3;}"; 06:40
06:41 exp_evalbot joined
mncharity perhaps the feather memory issue again. 06:43
svn: PROPFIND of '/pugs': Could not read status line: Connection reset by peer (svn.pugscode.org)
06:45 chris2 joined
spinclad we just had a netsplit; might be some net congestion? 06:48
(but /me to bed, perchance to dream...) & 06:49
mncharity goodnight spinclad 06:50
Auzon see you, spinclad
mncharity yeah. very late here in EST land. end of day for me. will sync tomorrow morn.
06:51 gbacon joined
mncharity 'night all & 06:51
06:51 mncharity left 06:54 [particle] joined, rafl joined, thepler joined, rafl left, mncharity joined, [particle] left
mncharity no space before postfix!?! so no postfix:<kg> ? eep! 06:54
& 06:55
06:55 mncharity left 06:57 rafl joined 06:58 IllvilJa joined 06:59 bsb left 07:07 bsb joined 07:10 meppl joined 07:19 meppl left 07:41 IRSeekBot joined 08:47 pmurias joined 08:54 schmalbe joined 09:11 bsb left 09:27 meppl joined 10:06 schmalbe left 11:19 polettix joined 11:21 Schwern joined 11:49 kanru joined 12:01 kane__ joined 12:10 kane_ left 12:20 meppl left 12:22 jferrero left 12:23 meppl joined 12:25 iblechbot joined 12:33 Limbic_Region joined 12:44 iblechbot left 13:02 Ched- joined 13:22 FurnaceBoy joined 13:29 Schwern left 13:32 meppl left 13:33 meppl joined 13:48 Schwern joined 13:53 vixey joined 13:58 Schwern left, Squern joined 14:00 FurnaceBoy left 14:08 Squern left 14:09 Squern joined 14:11 smtms joined 14:19 Squern left, Limbic_Region left 14:31 c9s left 14:37 iblechbot joined 15:05 cognominal_ joined, cognominal__ left 15:12 Torment joined 15:19 polettix left 15:28 Jedai left 15:34 justatheory joined 15:40 djk joined 15:56 lisppaste3 left, mncharity joined
mncharity SVN server still down. :/ 15:57
perhaps someone with feather access could kick it?
moritz_ I have access to feather. How do I kick it? 15:58
mncharity is it set up to restore services when you reboot it? 15:59
moritz_ dunno
I tried to restart apache2 16:00
mncharity Juerd: SVN service on feather appears borked. we have access... but don't know what to do. guidance?
still borked. 16:05
moritz_ uhm, http is also borked 16:06
I did a sudo /etc/init.d/apache2 stop 16:07
got a warning (nothing fatal)
and ps -el|grep apache2|wc -l
41
mncharity :/ I have to run. Will retry later (~t+12hr). re 41, eep. 16:08
moritz_ what the bloody hell?
see you later
16:08 mncharity left
moritz_ svn and ordinary http up again 16:10
(sudo killall -9 apache2)++
I hope I didn't destroy somebody else's apache, but they had all UID = 0 or UID = 33
16:11 lisppaste3 joined 16:14 Southen_ joined
pugs_svnbot r20450 | clkao++ | Make Data::Bind compile cleanly. 16:16
16:26 justatheory left 16:34 pmurias left 16:46 Southen left 17:07 luqui joined 17:21 schmalbe joined 17:40 luqui left 17:55 schmalbe left 18:10 polettix joined 18:12 djk left
Juerd moritz++ 18:19
18:24 chris2 left 18:34 kane_ joined 18:44 kane__ left 18:48 polettix left 18:53 FurnaceBoy joined 19:26 cmarcelo joined 19:30 finchely joined 19:46 finchely left
meppl good night 19:49
19:52 luqui joined 19:53 meppl left 20:04 Psyche^ joined 20:15 Patterner left, Psyche^ is now known as Patterner 20:46 polettix joined 21:08 rindolf joined
rindolf Hi all. 21:08
TimToady: here?
21:19 polettix left 21:24 stevan_ joined, stevan_ left 21:25 stevan_ joined
diakopter moritz_: I think the init script for apache2 is not correct (probably modified from the original, I'm guessing) 21:25
rindolf Hi diakopter 21:30
Hi moritz_
Hmmm.. TimToady has been idle for 14 hours.
21:32 iblechbot left 21:42 FurnaceBoy left 22:03 justatheory joined 22:15 rindolf left 22:30 justatheory left
Tene So, I was adding the optional test param to List::uniq on rakudo, and I vaguely remembered something about uniq inspecting the arity of the test, and if the test took a single parameter, testing test($arg1) == test($arg2) instead of test($arg1,$arg2) 22:32
I don't see that in the synopses anywhere, though, so maybe I just made that up? I'm not sure.
Eevee is uniq in the synopses at all? it's not in S29 23:06
wolverian I remember sort doing that. 23:08
pugs_svnbot r20451 | putter++ | [elf] elf_f can no longer be compiled by elf_e - now self-compilation only. 23:39
r20451 | putter++ | Parser.pm temp files improved, so simultaneous elf's no longer break each other.
r20451 | putter++ | PrimitivesP5.pm added to elf_f_faster. $*PID added to PrimitivesP5.pm, and unlink() to the runtime. run-tests now ignores a bogus enormous plan number from list_quote_junction.t. Updated run-tests results.
23:40 mncharity joined
mncharity moritz_++ 23:40
@tell clkao How goes Data::Bind? I'm looking for something to implement Signature/Capture binding for subs in elf. Thoughts? 23:47
no lambdabot?
:/ /me wonders how to reinvite lambdabot...
luqui lambdabot is not in the building 23:53
pugs_svnbot r20452 | lwall++ | [STD] now successfully recognizes escapes in double quotes
23:55 geezusfreeek joined 23:59 ting_ joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!