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. |
|||
mncharity | ah, :) | 00:03 | |
00:10
lisppaste3 left
00:11
Level1Tech joined,
Level1Tech left
|
|||
pugs_svnbot | r20456 | putter++ | [elf] New IR node Given. Parses, but no emitter yet. | 00:18 | |
cognominal_ | TimToady, in S05:392 an apparent typo s/equivalant/equivalent/ | 00:23 | |
00:28
wknight8111 joined
00:33
lisppaste3 joined
00:35
lisppaste3 left
|
|||
speckbot | r14543 | larry++ | typo from cognominal++ | 00:46 | |
00:48
braceta left
|
|||
mncharity | print STDERR ">$s< ",autobox->type($s),"\n"; #=> >str< INTEGER :/ | 00:54 | |
00:58
lisppaste3 joined
01:01
justatheory left
01:03
cjfields joined
01:10
justatheory joined
01:15
eternaleye joined
01:25
revdiablo left
01:27
Ched left
01:28
Ched joined
|
|||
mncharity finds himself knee deep in perlguts... wondering "how did I get here?" | 01:30 | ||
01:33
Psyche^ joined
01:35
ofer left,
ofer joined
01:39
syle left
|
|||
mncharity | hmm. one can have an SVt_PVIV which is not SvIOK. curious. ah well, have working autobox patch. will wait on checking in new elf until a patched autobox release occurs. | 01:49 | |
01:50
Patterner left,
Psyche^ is now known as Patterner
02:01
cjfields left
02:08
Lorn joined
02:24
kanru left
02:35
Limbic_Region left
02:38
ofer left
02:39
ofer joined
02:49
[particle1 joined,
[particle1 left
|
|||
mncharity | sigh. the definition of statement_control:default, "no 'when'-block mached in the current scope", means when() needs to be present at the IR level. :/ | 02:58 | |
03:01
jhorwitz left
|
|||
mncharity | wow. when is magical. ok... | 03:03 | |
TimToady | I think you're reading more into "default" than is intended | 03:05 | |
03:05
cmarcelo left
|
|||
TimToady | it's just "when *" | 03:05 | |
it doesn't have to track whether other whens matched other than by being reached in the ordinary way of control flow | 03:06 | ||
of course, when * -> ($x) {...} is a bit more magical... | 03:07 | ||
or rather, when * -> $x {...} | |||
well, packing up for Narita, so afk till earlier today :) | 03:10 | ||
& | |||
cognominal_ | do pod5 processor support entities? | 03:11 | |
TimToady | supposed to support E<...> | ||
& really | |||
cognominal_ | I ask that question because rakudo does not support utf-8 | 03:12 | |
thx | |||
mncharity | TimToady: thanks. I was discovering the magic of when() via default. :) | 03:16 | |
03:17
[particle2 joined
03:21
syle joined
|
|||
pugs_svnbot | r20457 | putter++ | [elf,STD_red] Added support for statement modifiers. 'say 3 if 4' no longer crashes. | 03:25 | |
03:38
pbuetow_ joined
03:49
wknight8111 left
|
|||
mncharity | good night & | 03:49 | |
03:49
mncharity left,
snooper left
03:56
vixey left,
vixey joined
04:01
vixey left
|
|||
pugs_svnbot | r20458 | putter++ | [elf] Statment modifier bugfixes. | 04:01 | |
04:02
schmalbe joined
04:20
[particle2 left
|
|||
cj | moo | 04:36 | |
04:39
schmalbe left
05:02
Psyche^ joined
05:11
nipotan is now known as nipotaway
05:14
Patterner left,
Psyche^ is now known as Patterner
05:36
eternaleye left
05:37
eternaleye joined
05:54
mediogre joined
06:01
meppl joined
06:07
IllvilJa left
06:25
lambdabotx joined
06:27
lambdabotx left
06:32
justatheory left
06:34
meppl left
06:37
meppl joined
06:43
Entonian joined
06:46
xdg_ joined
06:49
iblechbot joined
07:05
elmex joined
07:07
Entonian left
07:26
mj41 left
07:27
integral joined
07:29
mj41 joined
07:55
vixey joined
08:35
Lorn left
09:16
IllvilJa joined
09:30
meppl left
09:32
ruoso left
09:47
syle left
09:55
mncharity joined
09:57
lvh_ joined
|
|||
lvh_ | hello :-) | 09:58 | |
I'm trying to understand reduction. my $q = [<] @nums; Does what exactly? | |||
vixey | lvh_: it inserts < between every element of nums | ||
lvh_ | If I understand correctly, it's boolean and tells me wether @nums has ascending numbers, ie 1>2>3>4>.. etc | ||
moritz_ | it's the same as @nums[0] < @nums[1] < ... @nums[*-1] | 09:59 | |
lvh_ | ah :-) | ||
okay, thanks. | |||
Also, if I want to play with this stuff, should I be using Rakudo/Parrot or pugs? | |||
moritz_ | both ;) | 10:00 | |
lvh_ | right :-p | ||
moritz_ | pugs is more feature complete, but it isn't being developed anymore | ||
lvh_ | Seriously, though, are you guys moving towards two equivalent implementations? That sounds hairy. | ||
Ah, the end goal is having parrot work? | |||
moritz_ | rakudo is the fast moving frontier, but not yet very feature complete | 10:01 | |
lvh_: the "end goal" is to have as many perl 6 implementations as we can get. One would be a great start. | |||
lvh_ | Okay, but in a year from now people will most likely be using rakudo and not pugs? | ||
moritz_ | presumably, yes | ||
pugs: say [<] <1 2 3 4> | |||
exp_evalbot | OUTPUT[1] | 10:02 | |
moritz_ | pugs: say [<] <1 2 2 4> | ||
exp_evalbot | OUTPUT[] | ||
moritz_ | rakudo: say [<] <1 2 3> | ||
exp_evalbot | OUTPUT[Statement not terminated properly at line 1, near "[<] <1 2 3"current instr.: 'parrot;PGE::Util;die' pc 120 (runtime/parrot/library/PGE/Util.pir:82)called from Sub 'parrot;Perl6::Grammar;statementlist' pc 18770 (src/gen_grammar.pir:2734)called from Sub | ||
..'parrot;Perl6::Grammar;statement_block' pc 15616 (src/gen_grammar.pir:1612)called f... | |||
moritz_ | rakudo: say [<] <1 2 3>; | ||
exp_evalbot | OUTPUT[Statement not terminated properly at line 1, near "[<] <1 2 3"current instr.: 'parrot;PGE::Util;die' pc 120 (runtime/parrot/library/PGE/Util.pir:82)called from Sub 'parrot;Perl6::Grammar;statementlist' pc 18770 (src/gen_grammar.pir:2734)called from Sub | ||
..'parrot;Perl6::Grammar;statement_block' pc 15616 (src/gen_grammar.pir:1612)called f... | |||
moritz_ | ah well, meta operators not yet implemented in rakudo | ||
lvh_ | moritz_: what is this vector notation? | 10:03 | |
moritz_ | lvh_: <foo bar> is the same as qw(foo bar) in Perl 5 | ||
lvh_: that is "split at whitespace and make a list out of it" | |||
pugs: my @list = 1, 2, 3; say [+] @list; # the same | 10:04 | ||
exp_evalbot | OUTPUT[6] | ||
lvh_ | moritz_: okay. Single space separators? So <this,is,a,single,item>; is ugly, but returns a singleton list? | ||
moritz_ | right | 10:05 | |
cognominal_ | this is what is infuriating with rakudo, high level stuff is implemented but "trivial" way to enter literate structures are missing. | ||
moritz_ | also I wouldn't call it "singleton" | ||
lvh_ | moritz_: I don't mean signleton in the java sense | ||
moritz_ | cognominal_: parsing <...> and <<...> and chained comparison isn't very trivial ;) | ||
cognominal_: but that's right, it's annoying | 10:06 | ||
lvh_ | cognominal_: ooh, trivial! I can do trivial | ||
moritz_ | rakudo: my @l = 1, 2, 3; say @l; | ||
exp_evalbot | OUTPUT[1] | ||
moritz_ | d'oh | ||
rakudo: my @l = (1, 2, 3); say @l; | |||
exp_evalbot | OUTPUT[123] | ||
moritz_ | ah well, parsing assignment with list context isn't easy either | 10:07 | |
rakudo: my @l = (1, 2, 3,); say @l; | |||
lvh_ | moritz_: eh.... I thought (in perl5) @'s evaluated in scalar context returned the length of the array | ||
exp_evalbot | OUTPUT[123] | ||
lvh_ | moritz_: oh, nvm, perl6 vs perl5 sigils are confusing me | ||
moritz_ | lvh_: where did I have scalar context? | ||
ah | |||
sigils are invariant in p5 | |||
mncharity | TimToady: (n+1) STD.pm doesn't seem to have an infix_prefix_meta_operator:sym<[ ]> for '[<] <2 3 4>'. | ||
moritz_ | s/p5/p6/ | ||
lvh_ | moritz_: yeah. I forgot that | 10:08 | |
cognominal_ | rakudo: my @l = (1) | ||
exp_evalbot | RESULT[1] | ||
moritz_ | lvh_: happens to the best of us. Even TimToady++ confuses p5 and p6 syntax at times | ||
cognominal_ | rakudo: my @l = (1); say @a[0]; | 10:09 | |
exp_evalbot | OUTPUT[Scope not found for PAST::Var '@a'current instr.: 'parrot;PCT::HLLCompiler;panic' pc 158 (src/PCT/HLLCompiler.pir:103)called from Sub 'parrot;PAST::Compiler;keyed' pc 6040 (src/PAST/Compiler.pir:1675)called from Sub 'parrot;PAST::Compiler;post_children' pc 1664 | ||
..(src/PAST/Compiler.pir:364)called from Sub 'parrot;PAST::Compiler;call' p... | |||
cognominal_ | oops | ||
rakudo: my @a = (1); say @a[0]; | |||
exp_evalbot | OUTPUT[get_pmc_keyed() not implemented in class 'Integer'current instr.: '_block11' pc 43 (EVAL_11:24)called from Sub 'parrot;PCT::HLLCompiler;eval' pc 785 (src/PCT/HLLCompiler.pir:458)called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1067 (src/PCT/HLLCompiler.pir:587)called from Sub | ||
..'parrot;PCT::HLLCompiler;command_line' pc 1246 (src/P... | |||
lvh_ | moritz_: right, I don't know enough perl6 but I feel a junction is in order here: timtoady and larry are the same person? | ||
moritz_ | lvh_: yes | 10:10 | |
cognominal_ | moritz, you see | ||
rakudo: my @a = (1,2 ); say @a[0]; # with two elts : ok | |||
exp_evalbot | OUTPUT[1] | ||
moritz_ | rakudo: my @a = 1,; say @a[0] | 10:11 | |
exp_evalbot | OUTPUT[get_pmc_keyed() not implemented in class 'Integer'current instr.: '_block11' pc 53 (EVAL_11:25)called from Sub 'parrot;PCT::HLLCompiler;eval' pc 785 (src/PCT/HLLCompiler.pir:458)called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1067 (src/PCT/HLLCompiler.pir:587)called from Sub | ||
..'parrot;PCT::HLLCompiler;command_line' pc 1246 (src/P... | |||
moritz_ | that would be the "assignment in list context" thingy | ||
mncharity | TimToady: (n+1) it vaguely looks like, in expect_infix, the ordering of infix before infix_prefix_meta_operator causes ipmo:! to never be tried on '!< ...'. | 10:12 | |
TimToady: (n-=2) The last too comments are obviously bogus. Too early in the morning. :/ | 10:20 | ||
10:33
FurnaceBoy joined
|
|||
pugs_svnbot | r20459 | putter++ | [STD_red] Parse '[<] <2 3>;', but not '[<] 2,3;'. | 10:36 | |
moritz_ | mncharity: btw I tries run-tests in elf_f_src today and got 0 run 0%. 0 ok 0%. | 10:38 | |
mncharity: do I have to rebuild elf? | |||
10:40
mediogre left
10:49
ruoso joined
|
|||
mncharity | ah well. STD_red [<] not going to happen this morning. | 10:49 | |
moritz_: 0% ! | |||
10:50
iblechbot left
|
|||
moritz_ | mncharity: yes. 0%. Did you break something? | 10:51 | |
mncharity | what does ./elf_f ../../t/01-sanity/02-counter.t say? | ||
re broke, not that I know of... :/ | |||
moritz_ | Can't locate autobox.pm in @INC | 10:53 | |
ok | |||
I broke it :( | |||
10:53
agentzh left
|
|||
moritz_ | I updated my debian (testing), which installed perl 5.10 | 10:53 | |
thus making all previous installed modules (via cpan) unavailable | |||
mncharity | upside is, hopefully a new version of autobox coming out today... ;) | 10:54 | |
ah, it's been uploaded. autobox-2.51 propagating through CPAN... | 10:55 | ||
moritz_ | now it starts passing stuff | 10:57 | |
sorry for the noise | |||
mncharity | oh, so very no problem. great to have feedback. | 10:59 | |
11:08
agentzh joined
|
|||
moritz_ | mncharity: are there any tasks that can be done without much compiler knowledge? like writing builtins and the like | 11:12 | |
pugs_svnbot | r20460 | putter++ | [elf] run-tests now does a "is elf running at all?" sanity check, with visible stderr. moritz_++ | ||
mncharity | hmm... | 11:13 | |
let's see... there's easy stuff, like taking PrimitiveP5's $*PID and doing similar $*GID, etc, etc. ... | 11:15 | ||
figure out what say() is really supposed to do with arrays, and tweak it (its body is p5, it's also in PrimitivesP5.pm). ... | 11:17 | ||
that and adding a method say to STRING would get ../../../t/spec/S16-io/say.t to pass... | 11:18 | ||
moritz_ | mncharity: consider writing a TODO file with a section "low difficulty" | ||
mncharity | oh, good idea | 11:19 | |
moritz_ | mncharity: maybe I'll get around to some of it, but it's also a good thing to point people to | ||
mncharity | at the other extreme is someone needs to really understand the p6 object model, and design a non-glacial p5 runtime for it. elf is currently just faking it, which is fine for implementing the compiler, but at some point it would be nice to be more real. | 11:20 | |
at some point the attempt to "be real p6" diverges from Moose. | 11:21 | ||
moritz_ | jonathon is currently doing similar work for rakudo | 11:22 | |
mncharity | mid-range, and all p5, is creating a p5 multimethod module which does something realish. eg, take Class::Multimethods and sync it's policies with p6. | 11:23 | |
* its | |||
The original vision for elf was "good enough to make p6 compiler development non-unpleasant". So one idea is just "try to do something, anything, and complain when it doesn't work". Ie, handling a more normal map() form is on the todo list from earlier feedback. | 11:27 | ||
I shall scramble to quickly fill any gaps in the road thus encountered. | 11:29 | ||
perl6: say(2,3,4); | |||
exp_evalbot | kp6: OUTPUT[234] | 11:30 | |
..pugs: OUTPUT[234] | |||
..rakudo: OUTPUT[234] | |||
11:30
smtms left
|
|||
mncharity | perl6: say([2,3],[4,5]); | 11:30 | |
exp_evalbot | kp6: OUTPUT[2 34 5] | ||
..pugs: OUTPUT[2 34 5] | |||
..rakudo: OUTPUT[2345] | |||
11:31
smtms joined
|
|||
mncharity | perl6: say([2,[3,4],5); | 11:31 | |
exp_evalbot | kp6: OUTPUT[syntax error at position 3, line 1 column 3:say([2,[3,4],5) ^ HERE] | ||
..pugs: OUTPUT[***  Unexpected "[" expecting ":", identifier or ")" at /tmp/zUlUKdj2UX line 1, column 5] | |||
..rakudo: OUTPUT[Statement not terminated properly at line 1, near "([2,[3,4],"current instr.: 'parrot;PGE::Util;die' pc 120 (runtime/parrot/library/PGE/Util.pir:82)called from Sub 'parrot;Perl6::Grammar;statementlist' pc 18770 (src/gen_grammar.pir:2734)called from Sub | |||
..'parrot;Perl6::Grammar;statement_block' pc 15616 (src/gen_grammar.pir:1612)called f... | |||
mncharity | perl6: say([2,[3,4],5]); | 11:32 | |
exp_evalbot | kp6: OUTPUT[2 3 4 5] | ||
..pugs: OUTPUT[2 3 4 5] | |||
..rakudo: OUTPUT[2345] | |||
11:44
iblechbot joined
|
|||
lvh_ | make test shows a lot of lines like 7/160 skipped: various reasons | 11:47 | |
pugs_svnbot | r20461 | putter++ | [elf] say() formatting slightly improved. Any::say() method added. Autoboxing no longer unavailable in EmitSimpleP5's prelude. | ||
lvh_ | Normal? | 11:48 | |
moritz_ | lvh_: normal | ||
lvh_: which "make test" are you talking about? parrots? | 11:49 | ||
mncharity | That elf now (almost) passes t/spec/S16-io/say.t says unfortunate things about its coverage. Things like "there are no tests of hashes". Contribution of failing tests would be appreciated. | 11:50 | |
moritz_ | I'll put that into Auzon++s TODO for is summer of code project ;) | 11:57 | |
mncharity | :) | 11:58 | |
moritz_ | actually there's quite a lot of stuff mentioned during the last week regarding test suite TODOs | ||
so I think the project is really worth it | 11:59 | ||
mncharity | agreed. | ||
oh wow. t/blocks/placeholders.t actually parses. insufficiently evil corner cases. :) | 12:03 | ||
yeah, having folks sit down to generate a truly rigorous test suite is badly needed. | 12:05 | ||
hmm, will be badly needed. can't say it's really the bottleneck at the moment, but will hopefully become so. | |||
mncharity contemplates converting STD_red into p6... lot's o hours... | 12:11 | ||
lvh_ | moritz_: yes | 12:17 | |
12:19
Psyche^ joined
|
|||
lvh_ | why do people here always say Auzon++ instead of just Auzon? I know about karmabots but this is ridiculous :-p | 12:29 | |
12:36
Patterner left,
Psyche^ is now known as Patterner
|
|||
moritz_ | programmers love ridiculous stuff ;) | 12:37 | |
lvh_: even you increment his karma ,) | 12:38 | ||
[particle] | lvh_++ # this is ridiculous :-p | 12:49 | |
pugs_svnbot | r20462 | putter++ | [elf] Require new autobox-2.51, and decompose SCALAR into STRING, INTEGER, and FLOAT. Also make sure Moose is current. | 12:54 | |
moritz_ | it's not even on my cpan mirror, and you already require it as the minimum version ;) | 12:55 | |
mncharity | lol | 12:57 | |
:/ sorry about that. | |||
moritz_ | nah, don't bother. It's the right thing to do ;) | ||
13:02
FurnaceBoy left
13:07
FurnaceBoy joined
13:21
FurnaceBoy left
13:22
FurnaceBoy joined
|
|||
moritz_ | mncharity: run-tests hangs after printing xx-uncategorized/io_finalize_part1.t | 13:27 | |
13:29
eternaleye left
|
|||
mncharity | looking... | 13:31 | |
(my guess is now that more loops are recognized and emitted, we'll start seeing non-terminations. run-tests should probably use ulimit) | 13:32 | ||
13:32
rdice joined
13:35
masak joined
|
|||
mncharity | yeah, part2.t sleep's in a loop, waiting for part1.t to successfully run... a long wait. | 13:35 | |
13:36
ispy_ joined
|
|||
masak | how can I emulate coro/yield with given/take? by calling given in a void context? | 13:36 | |
mncharity | adding ulimit to run-tests. you should be able to kill the elf which is waiting, and thus unstick run-tests. | ||
masak: I think you mean gather/take? | 13:42 | ||
masak | oops, yes | ||
still, how? | 13:43 | ||
mncharity | re ulimit... but that won't help us here. :/ it's not running cpu-bound, but sleeping. can bound cpu sec, but not runtime sec. | 13:47 | |
re how, | |||
mncharity tries to remember gather/take... | |||
masak | :) | ||
I know about it closing over a dynamic scope | 13:48 | ||
and I can see how that would enable amulation of coros | |||
but I feel I need to be spoon-fed a complete example | |||
doesn't need to be fancy, tho' | |||
mncharity | the only thing which comes immediately to mind is that gather is defined to return a lazy list. so that list becomes a handle for transferring control back into the gather block (by looking for the next value in the list). | 13:52 | |
13:53
alester joined
|
|||
masak | mncharity: I'm with you so far | 13:55 | |
seems we are stuck at about the same place along the road to findout | |||
maybe an example of how gather/take could be used to emaulate coro could be included in the spec | 13:56 | ||
mncharity | maybe something like my @a = gather { while 1 { say "again!"; take(13) }}; @a.pop; #=>again! @a.pop; #=>again! gimme_the_ability_to_again(@a); | ||
masak | yes, that looks like some sort of coro-ing | 13:57 | |
masak 's head swims | |||
it _is_ a powerful construct | |||
mncharity | there is no doubt a cute little unix command for limiting the realtime duration of a process... /me struggles to find it... | 13:58 | |
[particle] | IPC::Run has a portable timeout implementation | 14:02 | |
14:07
ispy_ left
14:08
jhorwitz joined
|
|||
mncharity | "In words of the author of IPC::Run > I would personally recommend IPC::Cmd rather than IPC::Run right now." | 14:08 | |
14:09
TJCRI joined
|
|||
[particle] | i have been using IPC::Run in production on windows for 4+ years | 14:09 | |
if IPC::Cmd has timeout, that may be fine too. just don't know it. | 14:10 | ||
14:11
wknight8111 joined
|
|||
mncharity | re timeout, yeah, I don't see it. :/ | 14:12 | |
14:21
pbuetow_ left
14:22
pbuetow joined
14:27
pmurias joined
14:30
Patterner left,
Psyche^ joined,
Psyche^ is now known as Patterner
|
|||
pmurias | use v5 is assumed to be a lexical grammar changing module right? | 14:40 | |
by STD.pm | |||
rephrasing my question in a human-readable form, STD.pm assumes that v5 invokes v5.pm (or similiar) that changes the grammar? | 14:42 | ||
s/in/into | |||
moritz_ | I'd expect it to take over the parsing | 14:43 | |
do you really think you can built a sane parse tree or even AST for perl5 code? | |||
pmurias | moritz_: you = me? or you = someone? | 14:45 | |
moritz_ | you = anybody | 14:46 | |
they say "nothing but perl can parse Perl", and I believe this to be true for Perl 5 | |||
pmurias | why not? MAD does it | ||
moritz_: it's even more true for Perl6 | 14:47 | ||
[particle] | it's also true for perl 6 | ||
however, if you ignore BEGIN in perl 6, you can parse it without perl 6 | |||
this is not true for perl 5 | |||
moritz_ | aye | 14:53 | |
pmurias | [particle]: an example please ;) | 14:55 | |
[particle] | www.perlmonks.org/index.pl?node_id=44722 | 14:57 | |
moritz_ | pmurias: p5 has really nasty things like prototypes, and heuristics when a { is a block or a hash | 14:58 | |
pmurias: and things like foo / ... is ambigous, you don't know if / a division or a beginning regex unless you know foo's prototype | 14:59 | ||
Khisanth | but perl5 is a bit of a moving target anyway :) | ||
moritz_ | all the worse ;) | 15:01 | |
but let's finish the thought - even if we could parse p5, what then? We can't reimplement all of perl5 on parrot | 15:02 | ||
so we'd have to link in a perl interpreter anyway | |||
Khisanth | can't or don't have the resources to do it? | 15:06 | |
moritz_ | both | 15:07 | |
Patterner | 5.4: 1997 5.6: 2000 5.8: 2002 5.10: 2007 Moving like greased snails. | ||
moritz_ | I believe it's impossible to clone such a complex piece of software that's defined by implementation, not by specs | ||
Patterner | the Test Suite is the Spec. | 15:08 | |
moritz_ | I wish it were so | ||
the Spec is a mixture of test suite, documentation, previous behaviour and a what you might call "common sense" | 15:09 | ||
pmurias | mncharity: if you wish to do start a second backend and port the STD_red to perl6, doing a ruby backend might make sense | 15:10 | |
15:14
sscaffidi joined
|
|||
mncharity surfaces, backlogs | 15:15 | ||
pugs_svnbot | r20463 | putter++ | [elf] run-tests will now timeout non-terminating tests. moritz_++ particle++ | ||
pmurias | a proper js backend would be very usefull, but js would likely require lots of workarounds | 15:16 | |
mncharity: hi | |||
mncharity | hi pmurias | 15:17 | |
re IPC, what a zoo. the python folks "recently" did a cleanup of their IPC stuff. Someone should clone their api. This seems to be one of those "pile of CPAN modules, variously unmaintained, buggy, or not quite the right thing". | 15:19 | ||
re porting STD_red to p6, | 15:20 | ||
15:22
justatheory joined
|
|||
mncharity | pros include () lower barrier to entry for elf. () elf can become a p5 module, and then relocatable/renamable (ie, so you can have multiple p6 instances in a p5 process). () full bootstrap. () closer to running on non-p5 languages. () perhaps easier for more people to hack on it. () ... | 15:23 | |
cons include () extra source of uncertainty while debugging (but what is _really_ running?). () somewhat longer edit-test cycle. () ... | 15:24 | ||
() lots of hours work... | 15:25 | ||
s/IPC/process management/ | |||
pmurias | i don't understand the first con | 15:26 | |
mncharity | with ruby, one can be fairly sure that the source you are looking at corresponds closely to what is running. with the extra p6 compiled to p5 step, without looking at the p5, you would never quite certain if something odd isn't an elf compiler artifact. | 15:28 | |
pmurias | happend with mp6 a lot | ||
a couple of times | |||
but the generated code was clean so it could be hand checked if the bug appeared to be strange enough | 15:29 | ||
15:31
masak left
|
|||
mncharity | so far it hasn't been a big issue with elf. but part of that may just be that I've been conservative in dialect, and having written it, have a feel for what is less likely to bite. be interesting to see what happens as others start writing hunks of code. | 15:32 | |
but big hit is hours. probably cost 2 or 3 person days. | 15:33 | ||
moritz_ | elf can already parse 70% of the tests. Shouldn't you focus on running mor of them first? | 15:34 | |
*more | |||
mncharity | could be. would you be more enthused by pure p6/p5-ness, or say 90% non-parsefail? | 15:36 | |
pmurias: re js, yeah, that would be nifty. :) | 15:37 | ||
moritz_ | 90% non-parsefail | ||
because then it could be a *real* help for writing the test suite | 15:38 | ||
having a syntax checker helps | |||
mncharity | as long as the performance wasn't too bad. PIL2JS was too slow to be usable. we should be able to do better compilation in elf (if not, something is very wrong), and js implementations are faster, so in principle we should be able to get near native js speed, just as we currently have near native p5 speed. | ||
re syntax checker, one difficulty is that you never really know if a parse is correct until you try to use it and test the result. hmm, though that's less of a problem with STD than it was with redsix - backtracking lets the parser search out all sorts of weird false parses one didn't anticipate. | 15:40 | ||
moritz_ | mncharity: even a non-authoritive syntax checker is great | 15:42 | |
mncharity | pmurias: re "lots of workarounds", ... I started to ask which... yeah, lots of work. | 15:45 | |
moritz_: re checker, I guess the gotcha is it doesn't seem to get me closer to other people working on elf... | 15:46 | ||
or using it even | |||
search.cpan.org/~vpit/Variable-Magi...e/Magic.pm <- intriguing | 15:52 | ||
lambdabot | Title: Variable::Magic - Associate user-defined magic to variables from Perl. - search. ..., tinyurl.com/65bqv9 | ||
pmurias | mncharity: why do you use (sub {})->()? | 15:53 | |
isn't do {} better | |||
mncharity | search.cpan.org/~tbusch/JavaScript-...nkey-0.19/ search.cpan.org/~claesjac/JavaScrip...aScript.pm | 15:55 | |
lambdabot | Title: Thomas Busch / JavaScript-SpiderMonkey-0.19 - search.cpan.org | ||
mncharity | pmurias: for 'is p5'? me greps... | 15:56 | |
err, which/where? | 15:57 | ||
pmurias | output of t/builtins/my.t | 15:58 | |
mncharity | looking... | 15:59 | |
pmurias | should i paste the offending bit? | 16:00 | |
;) | |||
mncharity | ah, bare blocks. my impression is | 16:01 | |
16:01
cjfields joined
16:02
Alias_ left
|
|||
mncharity | bare blocks are param-less self-executing routines. could be wrong. was thinking that this way, whatever we eventually do to get routines more real (local()ization, $_, etc) would then "just happen". | 16:02 | |
also didn't think of it :) | 16:03 | ||
pmurias | you are likely right | 16:04 | |
mncharity | it's actually happening on the AST->IR conversion step, rather than the emitter. hmm... having the emitter then try to optimize, having lost information, seems non-ideal. could have an extra IR node... :/ | 16:05 | |
moritz_ | beware that 'return' does something different | 16:06 | |
in do { ... } it exits the surrounding sub | |||
in (sub { ... })->() it doesn't | |||
mncharity | I guess the key would be whether things like $?ROUTINE are altered inside of a block or not. if not, then it really isn't a sub, and the IR should be changed. | ||
ah, there's an even better one. | 16:07 | ||
hmm... svn up is hanging again... | 16:09 | ||
16:12
chris2 joined
|
|||
moritz_ | 17:22 <@Juerd> Oh, outage. Have to run. | 16:13 | |
don't know if that's connected | 16:14 | ||
I can't ssh to feather | |||
mncharity | ^.^ | 16:16 | |
ok, I've a fixed version for whenever we get svn back. good catch. | 16:18 | ||
re "you are likely right"... or so not :) | 16:19 | ||
moritz_ | Juerd: I can ping feather, but there's no way to connect to it (ssh and http time out) | ||
16:19
FurnaceBoy left
|
|||
mncharity | pmurias: anything else seem odd? | 16:23 | |
or, whenever you notice or are puzzled by something, let me know... odds are good it's a thinko. | 16:25 | ||
pmurias | haven't found anything yet ;) | ||
mncharity | :) | ||
pmurias | the syntax error (lack of semicolon) was a bit out of the ordinary too | 16:28 | |
mncharity | my.t? | ||
16:28
meppl joined
|
|||
pmurias | yes | 16:30 | |
svk pull hangs :( | 16:31 | ||
pasteling | Someone at 81.168.228.98 pasted "error isolated" (10 lines, 279B) at sial.org/pbot/31080 | 16:32 | |
pmurias | semi-isolated :( | ||
mncharity | re my.t, looks like a misparse... | 16:36 | |
16:40
braceta joined
|
|||
mncharity | hmm. so there seem to be at least two problems. there's an infix:is which is preempting the interpretation of the sub is(). and the infix:is is crawling out of the block, likely via the EXPR "lets move the ops around" system. upside is it probably affects a lot of files. | 16:43 | |
"Why did p6 take 5 years 'till Christmas? Well, we had to write a parser for it..." :) | 16:44 | ||
that clears up the question of what to work on today... thanks :) | 16:46 | ||
pmurias | np ;) | ||
16:46
nipotaway is now known as nipotan
16:54
Psyche^ joined
|
|||
mncharity | re 'two problems', nope. "{4}\nis(3);". it's not stopping after the }, and since there's an infix:is, it becomes infix:is({4},(3)). cute. | 16:54 | |
16:58
braceta left
17:06
Patterner left,
Psyche^ is now known as Patterner
17:08
eternaleye joined
|
|||
pmurias | swimming& | 17:11 | |
mncharity | *envious* | ||
17:11
alanhaggai joined
|
|||
mncharity | TimToady: (n+1) It looks like EXPR is willing to eat "{3}\nis(4)" because there is currently no stopper check between the expect_term and the expect_infix, and Test's sub is() resembles infix:is. Adding a 'last if stdstopper' avoids the over eating. | 17:15 | |
bummer no svn | 17:17 | ||
hmm, and search.cpan.org is busted. | 17:37 | ||
ie, returning no matches for "any" search. | 17:38 | ||
17:39
braceta joined
|
|||
pmurias | mncharity: what do you want to find on cpan? | 17:40 | |
mncharity | used kobesearch.cpan.org , was looking for padwalker | 17:42 | |
do you know of any module which provides a "current-environment" aka "binding" abstraction? ie, | 17:43 | ||
eval('$b',Binding.new) where Binding.new captures the enclosing sub and package, so a padwalker elsewhere can access '$b'. | 17:44 | ||
pmurias | no | ||
mncharity | oky. that's one which would be easier in ruby&CL, but can deal... | 17:46 | |
pmurias | but walker only works on the pads which are in the current call chain | ||
so the absoulte depth would be enough | |||
mncharity | challenge is p6 eval calls compiler which calls assorted methods which eventually calls eval_perl5 and p5's eval(). oh, which doesn't take an environment, so even if the info is routed, you still lose with lexicals. :/ | 17:48 | |
17:48
FurnaceBoy joined
|
|||
pmurias | mncharity: you can still access them by passing the right int to peek_my()? | 17:50 | |
mncharity | re lexicals, so p6 eval() has to be emitted as foo(sub{my($p5)=@_;eval($p5)}) so the p5 gets eval()ed in the right place. | 17:51 | |
re int, yes, with everyone... was going to say everyone tracking their frames, but since the p5 compiler is free to discard frames, that would be problematic. might be able to use a marker variable, so | 17:53 | ||
search up the stack until you see the "I am eval()" marker, and then go one frame further. | |||
pmurias | but we would accessing the vars in a funny way | 17:54 | |
or playing with LexAlias a lot | |||
really swimming& | |||
mncharity | but that still leaves the problem of "yes you can look up vars, but that doesn't directly help you evaluate code". where the sub approach perhaps work. | ||
17:55
pugs_svnbot left,
pmichaud left
|
|||
mncharity | :) | 17:55 | |
17:55
dalek left,
Juerd left,
wolverian left,
dalek joined,
pugs_svnbot joined
17:56
PerlJam left
|
|||
[particle] | svn's back up | 17:56 | |
pugs_svnbot | r20464 | particle++ | [fudge] recognize 'nok' as a valid test function | ||
r20465 | particle++ | [spectest] use 'nok' where appropriate to test truth, add tests for True vs Bool::True, etc. | 17:59 | ||
Auzon | particle++ indeed. ok(not(...)) is annoying to write. | 18:00 | |
[particle] | Auzon, moritz_: btw `svn log | ack -A 99 -iw auzon -r 20000:HEAD` works great to get the log of just your commits since r20000 | 18:01 | |
Auzon | Excellent. | ||
18:01
Juerd joined
|
|||
Auzon | Now to figure out what all those ack commands do... :P | 18:01 | |
[particle] | --thppt | 18:02 | |
Auzon | My version mentions --thpppt, but --thppt works too | 18:03 | |
Tene | as does --thppppppppppppppppppppppppt | 18:05 | |
alester | Auzon: EVERYTHING. THEY DO EVERYTHING. THEY ARE ALL POWERFUL. | ||
Auzon | alester: "It does awesome is what it does."? | 18:06 | |
alester | THAT IS CORRECT | ||
AWESOME IS ACK'S MIDDLE NAME. | 18:07 | ||
Juerd | I'm DISABLING apache2 on feather until someone has tuits to find out what the hell causes the memory problems | ||
[particle] | that's gonna hurt somebody's feelings, juerd :) | 18:08 | |
Juerd | [particle]: The current situation is that feather crashes every few days, and people lose work because of that. | ||
I have no tuits to find the problem. Someone must know what happened because it started happening one specific moment. | |||
Letting apache2 run like this is no option as far as I'm concerned. | 18:09 | ||
Either something has to be made that kills it when it consumes too much memory, or the leak must be found and plugged. | 18:10 | ||
[particle] | understood. i'm sure with apache2 being down, somebody'll find it | ||
any way to notify folks who may try to restart it about the problems? | |||
...rather than have somebody blindly restart it and cause problems again. | |||
Auzon | Juerd: Does that include the main Apache2 instance? | 18:15 | |
18:16
braceta left
|
|||
Eevee | you know, computers suck | 18:16 | |
18:17
braceta joined
|
|||
mncharity | Juerd: if it happens every few days... what about a nightly reboot? *innocent look* | 18:17 | |
18:19
kanru joined,
lvh_ left,
wolverian joined
|
|||
[particle] | fix >> hack | 18:22 | |
mncharity notes ulimit -v # The maximum amount of virtual memory available to the shell | 18:24 | ||
TimToady | back home | 18:25 | |
18:25
silbirs joined
|
|||
TimToady | re infix, my expect_infix contains <!infixstopper> | 18:25 | |
which should also check stdstopper | |||
Auzon | oh. Regarding limiting resources, you might want BSD::Resource | 18:26 | |
TimToady | (but apparently doesn't yet) | ||
18:27
schmalbe joined
18:30
IllvilJa left
|
|||
Juerd | Auzon: I don't know and I don't have time to figure it out. | 18:32 | |
[particle]: Whoever wants to investigate can get root access to enable apache2 and then fix it. | |||
But I'm not going to start Apache2 without that volunteer. | 18:33 | ||
[particle] | ok, i figured there are folks with root that might just restart apache2 blindly | ||
i'll watch the channel for traffic wrt that | |||
18:37
alanhaggai left
18:39
ruoso left
|
|||
TimToady | in any case, I'm refactoring all the stopper logic in various directions to be more LTM friendly | 18:40 | |
on the plane home I rewrote the regex parser to use EXPR to parse ||, |, &&, & for instance | 18:44 | ||
it just derives a new expect_term and expect_infix | |||
18:45
cjfields left
18:58
meppl left
18:59
meppl joined
19:18
meppl left
19:20
meppl joined
|
|||
[particle] | cooooool | 19:22 | |
19:32
PerlJam joined
19:37
FurnaceBoy left
|
|||
pmurias | mncharity: you could even emitt it as eval(foo(...)) it looks cleaner but is less flexible | 19:41 | |
19:49
schmalbe left
|
|||
mncharity | pmurias: got it working. awaiting svn. | 19:51 | |
re "to parse ||, |, &&, &", ^.^! | |||
19:52
braceta left
|
|||
mncharity | hmm, someone will just have to create a Smiley.pm with lots of smiley ops which do something. | 19:52 | |
ooo, svn back | |||
spinclad | *<8oO | ||
*<8-0 | 19:53 | ||
?:-[ # headscratch | |||
lambdabot | Unknown command, try @list | ||
pugs_svnbot | r20466 | putter++ | [STD_red] Added stdstopper to EXPR, to avoid "{3}\nis(4)" being one EXPR. TT reports it should be in infixstopper instead. | 19:57 | |
r20467 | putter++ | [elf] Emit bare blocks as do{}. pmurias++ moritz_++ | 20:00 | ||
r20468 | putter++ | [t] Added ;'s to improperly terminated "ends in the middle of a line" blocks. | |||
20:01
Caelum left
|
|||
mncharity | r20466 should have been pmurias++ too | 20:01 | |
20:01
Caelum joined
20:02
peepsalot joined,
peepsalot left
|
|||
mncharity waits for self bootstraping cycle to complete. pmurias: it's about to be eval($expr,sub{my$s=eval($_[0]);Carp::carp($@)if$@;$s}) where the later is passed around as an environment handle. | 20:03 | ||
should be doing a wantarray, but... will wait for testfails to add it. | 20:04 | ||
20:06
Caelum left,
Caelum joined
|
|||
pugs_svnbot | r20469 | putter++ | [elf] my $d;eval('$d') now works. | 20:09 | |
mncharity | pmurias: re eval(foo), oh.... there's an idea... | 20:12 | |
though eval($exp,$env?) perhaps requires less magicalness from eval(). and can grow into a non-hack (we really should have a current-environment concept). | 20:14 | ||
pmurias | i meant it to be eval(compile_to_p5("...p6 code...")) so it would use the minimum of magicalness | 20:24 | |
mncharity | right, but then eval() isn't really a p6 sub any more. we're treating it like a macro. which is fine, but... perhaps not clearly preferable. | 20:29 | |
pugs_svnbot | r20470 | putter++ | [elf] Update run-tests.result_faster . | ||
mncharity | ie, the p6 eval('') macro-expands to <the underlying p5 eval>(compile_to_p5('')) vs moving towards something vaguely like sub *eval($expr,$env=CALLER::binding){} or somesuch | 20:42 | |
CALLER::environment ... whatever | |||
pugs_svnbot | r20471 | putter++ | [elf] 'loop (my $x=1;$x<4;$x++) {say $x}' now runs. Scoping is no doubt in need of fixing. | ||
mncharity | ruby-doc.org/core-1.9/classes/Binding.html docs.python.org/ref/exec.html ha, but not CommonLisp www.lisp.org/HyperSpec/Body/fun_eval.html#eval | 20:43 | |
lambdabot | Title: Class: Binding | ||
mncharity | www-sop.inria.fr/mimosa/fp/Bigloo/d....html#Eval | 20:44 | |
lambdabot | Title: R5RsScheme Revised(5) Report on the Algorithmic Language Scheme | ||
20:46
cjfields joined
|
|||
mncharity | so t/builtins/my.t still shows some scoping (and other?) issues, but the whole thing now runs. | 20:46 | |
might be nice to have something like ruby's somewhat-smalltalk-inspired ruby-doc.org/core-1.9/index.html documentation. | 20:49 | ||
lambdabot | Title: RDoc Documentation | ||
mncharity | pmurias: btw, thank you so much for championing elf_f_faster. it makes this exercise sooo much more pleasant. | 20:52 | |
eep. ./STD_red_run -e '!foo()' #=> dotty:! !?! | 20:55 | ||
spinclad: assorted exclamations "!#*!?!" could also be operators. :) | |||
spinclad | (: balanced brackets :) | 20:57 | |
mncharity | lol | 20:58 | |
oh my, nofat_space et al are gone from STD.pm... | |||
spinclad | *<8-O SHOUT! O-8>* | ||
20:59
ruoso joined
|
|||
mncharity | TimToady: (n+1) statement_control:loop's rule() seems to require ws between 'loop' and '('? the hints example about it shows it without | 21:01 | |
re SHOUT!, boldface ansi terminal code print STDERR. | 21:02 | ||
21:07
ilogger2_ joined
21:09
ilogger2 joined
|
|||
Eevee | mncharity: !foo() is always prefix | 21:10 | |
perlcabal.org/syn/S12.html#line_237 | |||
lambdabot | Title: S12 | ||
21:14
Auzon joined
|
|||
mncharity | ah, thanks! | 21:16 | |
TimToady: (n+1) it looks like noun parsers '!foo()' as dotty:<!> rather than prefix:<!> ? | 21:17 | ||
btw, I've been using the 'TimToady: (' format consistently, so it can be searched out of the web-or-other log. | 21:18 | ||
21:19
peepsalot joined
|
|||
mncharity | Does anyone know of a way to tell the perl compiler "please don't optimize away variables - look, there's an eval() here"? | 21:20 | |
moritz_ | don't think so, except just listing the variables | 21:21 | |
$var1; $var2; $var3; etc | |||
mncharity | that does it. ok, something for the infinite compiler todo list... maybe, depending on spec. | 21:24 | |
hmm, though t/spec/S29-context/eval.t test 1 depends on an unused variable not being optimized away. | 21:25 | ||
moritz_ | I think an eval() should prevent a compiler from optimizing away any variables, except for including them in closures | 21:28 | |
which is the way perl 5 works | |||
pmurias | does perl5 optimize away variables? | ||
moritz_ | but that's a nice question for p6l | ||
pmurias: only from closures | |||
pmurias | moritz_: example please? can't find out anything myself? | 21:31 | |
s:2nd/?// | |||
moritz_ | pmurias: wait a sec | 21:32 | |
pasteling | "moritz_" at 89.13.241.101 pasted "perl5 optimizes variables away from closures (for pmurias)" (15 lines, 202B) at sial.org/pbot/31081 | 21:34 | |
pugs_svnbot | r20472 | putter++ | [STD_red] Disabled dotty:<!> so '!foo()' gets prefix:<!> instead. | ||
Eevee | ..ah, tricky | 21:35 | |
moritz_ | pmurias: in this example you'll see that $y isn't in $closure's lex pad | ||
pmurias | thanks | 21:37 | |
g' night | 21:43 | ||
mncharity | good night | 21:48 | |
Anyone know what lexical scope $/ should have? | 22:05 | ||
rakudo: "ab" ~~ /b/; say $/; | 22:06 | ||
exp_evalbot | OUTPUT[Parrot VM: Can't stat languages/perl6/perl6.pbc, code 2.main: Packfile loading failed] | ||
mncharity | :/ | ||
moritz_ | uhm, are there different lexical scopes? | ||
rakudo: "ab" ~~ /b/; say $/; | |||
exp_evalbot | OUTPUT[b] | ||
moritz_ | mncharity: it was just a race condition with the build cronjob | 22:07 | |
mncharity | wondering about "ab" ~~ /b/; say $/; { "abc" ~~ /c/; say $/; } say $/; | 22:08 | |
re cronjob, ah! :) | |||
namely, is $/ my'ed in any block which contains a rx? a single $/ my'ed at the top of a sub? | 22:09 | ||
moritz_ | uhm, good question | ||
mncharity | rakudo: "ab" ~~ /b/; say $/; { "abc" ~~ /c/; say $/; }; say $/ | 22:10 | |
exp_evalbot | OUTPUT[bcb] | ||
moritz_ | pugs: "ab" ~~ m/a/; { "ab" ~~ m/b/; say $/; }; say $/; | ||
exp_evalbot | OUTPUT[bb] | ||
moritz_ | so they behave quite differently | 22:11 | |
mncharity | with the rakudo behavior, one wouldn't be able to do given $n { when 3 { $x ~~ /3/ }; when 4 { $x ~~ /4/ }; }; say $/; | 22:12 | |
re differently, yeah. | |||
[particle] | the answer lies within the #parrot log for last night | 22:13 | |
mncharity | LOL | ||
grasshopper goes in search of the log... | |||
[particle] | www.parrotcode.org/misc/parrotsketc...t.20080519 | 22:14 | |
lambdabot | tinyurl.com/629aef | ||
[particle] | starting around "<pmichaud> I still have to figure out the real semantics of $/, $_, and $?" | 22:15 | |
shower & | |||
moritz_ | irclog.perlgeek.de/parrot/2008-05-19#i_299699 and later | ||
lambdabot | Title: IRC log for #parrot, 2008-05-19 | ||
moritz_ | though I don't quite understand the discussion I'm afraid | 22:16 | |
ah, reading a bit on it seems to get a bit clearer | 22:18 | ||
22:21
IllvilJa joined
|
|||
mncharity | 'my $+x;' declared bogus, ah well, elf will need edits. | 22:22 | |
22:28
audreyt joined
|
|||
mncharity wants lots of tests capturing that conversation | 22:30 | ||
looks like there might be distinct Block and "immediate block" concepts... sounds like maybe a new IR node... but I'm still unclear on it | 22:31 | ||
Auzon | Duly noted. | ||
mncharity | :) | ||
eep. looks like a bunch of local()s are needed in every sub call. :/ | 22:32 | ||
22:33
fridim_ joined
|
|||
Auzon | I'm still slowly experimenting with a safemode for elf. I'm thinking of just disabling the file IO, Perl 5 evals, and running it under BSD::Resource or similar. Ideally I could make an EmitSaferPerl5.pm with all of these hacks in it, but I'm a bit lost in elf's architecture. | 22:34 | |
I found out that I can just add croak("...") if $ENV{ELF_SAFEMODE} in the prelude, but that seems a bit invasive. | |||
s/in the prelude/in the relevant subroutines in the prelude/ | 22:35 | ||
moritz_ | and you'd need a way of disabling $ENV{ELF_SAFEMODE} = 0; | ||
pugs_svnbot | r20473 | putter++ | [elf,STD_red] Parse regex adverbial modifiers. | ||
Auzon | I checked, and it doesn | 22:36 | |
doesn't matter if you do that | |||
mncharity | Auzon: re architecture, any questions? | 22:37 | |
Auzon | I believe that's because Elf doesn't give a copy of the environment to the scripts. | ||
mncharity | re disable p5 evals, I'm not sure you can. eg, PrimitivesP5's getting $*PID from $$. | ||
moritz_ | but you can formulate that as subs exported from the prelude | 22:38 | |
sub get_pid { $$ } | |||
mncharity | re "Elf doesn't give a copy of the environment to the scripts", you mean elf doesn't have a %*ENV? | 22:39 | |
moritz_ | no need for a perl 5 eval that's callable from p6 | ||
Auzon | I hand-modified a copy of elf_f_faster to have eval_perl5 croak if ELF_SAFEMODE was set. It seemed to work OK. | 22:40 | |
mncharity | re get_pid, trying to go in the other direction. moving things to PrimitivesP5. any runtime calling convention changes would have to be hand edits in the EmitSimpleP5 core prelude, but happen automagically in Primitives. | ||
any p5 based runtime should be able to use Primitives. but the p5 code in Emit is specific to a particular runtime design. | 22:41 | ||
moritz_ | ok, I don't know how the different parts of your runtime are called | ||
Auzon | elf_f_safe -e 'say $*PID' works. | 22:42 | |
oh, duh | |||
Hm. | 22:43 | ||
my elf_f_safe isn't correct somehow | |||
mncharity | the prelude is composed of () stuff in EmitSimpleP5.pm (as a string), () PrimitivesP5.pm which is p6, but is allowed to do sub foo() is p5 {'this is p5'}, and () Prelude.pm which is supposed to be backend independent p6. | ||
moritz_ | mncharity: do you have some kind of architectural overview of elf_f? | ||
mncharity | so () depends on particular p5 runtime, () depends on p5, () works anywher. | 22:44 | |
no, still just winging it. | |||
ie, the current set of design choices are considered all experimental/peliminary, and subject to "may change at any moment without notice". | 22:45 | ||
moritz_ | heh ;) | 22:46 | |
moritz_ notices that his waking times don't overlap too much with mncharity's and Auzon's :( | |||
mncharity | :/ | 22:47 | |
Auzon | Waking times? What're those? :P | ||
moritz_ | off to bed now | ||
Auzon | Ah... | ||
I'll try to wake up earlier then. :) | |||
mncharity | good night moritz_. thanks for the help today | ||
Auzon | See you, moritz_ | ||
moritz_ | how do you say "waking times" in proper english? | 22:48 | |
mncharity | Auzon: I really don't think the "disable <pause> | ||
err, hmm... | |||
Auzon | I don't know. I was just joking about my messed up sleep schedule. | ||
moritz_ | ok ;) | ||
bed & | |||
mncharity | "when you are away" ? | ||
*awake | |||
"work hours", so... "sleeping hours"? so... | 22:49 | ||
hmm. puzzlement | |||
Auzon | Seems that $*PID is forbidden under my safemode hack, too. | 22:52 | |
mncharity | <unpause> Auzon: I really don't think the "disable p5 eval" is a viable strategy... hmm... if it happened after the prelude was loaded... and obviously didn't apply to p5 eval via p6 eval... which is a big hole there... hmm, I just don't know... | ||
if you can delay safety until after the prelude runs, then maybe. but if before, I expect the prelude to go boom. | 22:54 | ||
(note of context: I was quite dubious for a while about pmurias's seeking a non-Moose variant of elf... which turned out to be a big win, so... I may well be wrong). | 22:55 | ||
what I'm very reluctant to do is alter how elf gets architected in pursuit of "safe", where the RightThing is instead an external vm box. | 22:58 | ||
which means theirs "the other shoe drops" potential... it works... a new bit of prelude gets built... it can no longer work... . maybe. | 22:59 | ||
*there's | |||
23:00
peepsalot left
|
|||
mncharity | sound vaguely plausible? | 23:02 | |
Auzon | Hm... | ||
Well, evalbot is already in a chroot. | 23:03 | ||
mncharity | as long as it doesn't have permission to edit the filesystem, can't access sensitive info, can't send spam, has short runtime limit, etc, then that should be fine, no? | 23:07 | |
Auzon | spam and runtime limit are what I'm trying to prevent | ||
I'm thinking that BSD::Resource could help, without imposing any requirements on elf itself. | |||
Or maybe something in evalbot to keep it from running beyond ~5 seconds. | 23:09 | ||
mncharity | spam is controlled by what (isn't) in the chroot. limits can be imposed by a wrapper script. runtime, memory, filehandles, etc. ulimit handles much of it. run-tests is using a simple alarm timer for runtime. looking at BSD::Resource... | ||
re 5 sec, sounds plausible. elf_f has a ~2 sec startup overhead. for the usual irc channel stuff, responses should be sub-second after that. | 23:11 | ||
Auzon | Would you rather use elf_f_faster in the evalbot? | 23:13 | |
That's what I was planning, but I'm not sure how much it sacrifices compared to elf_f | 23:14 | ||
23:15
eternaleye joined
|
|||
mncharity | good question. it's very slightly less capable than elf_f. i don't know how that will play out. ? perhaps a elf/elf_bot symlink? that also deals with elf_g eventually coming out. | 23:15 | |
at the moment, I believe the only difference is array instance variables are not initialized. has @.a; but I haven't looked closely at it. | 23:16 | ||
s/it/the issue/ | |||
Auzon | Yeah. I'm making the build script, so I could do something like that. Maybe look for the recommended version in README, or have it find the latest version | 23:17 | |
mncharity | BSD::Resource looks neat. | ||
Auzon | Or maybe I'll just need to update the build script for every new elf iteration, unless they can all be compiled in a similar way | ||
mncharity | the latest version has sometimes been "known not to work". so a manual approach is probably better. | 23:18 | |
don't have to compile anything. elf is in the repo. | |||
Auzon | re BSD::Resource, indeed. I recall using it a few years ago for something or other. | ||
23:19
fridim_ left
|
|||
mncharity | that was literally a one-line change. :) | 23:21 | |
pugs_svnbot | r20474 | putter++ | [elf] Added %*ENV. 'say %*ENV<PATH>' works. Auzon++ | ||
Auzon | Does elf support the .perl method yet? | 23:22 | |
mncharity | no. was waiting for someone to be interested or to do it. | 23:23 | |
Juerd | What is elf? | ||
Auzon | supper & | 23:24 | |
mncharity | thanks Auzon. may do a .perl(), taking your question as interest. :) | 23:26 | |
23:27
Zygo joined
|
|||
mncharity | Juerd: you're kidding, no? /me seems to have seriously misjudged visibility among #perl6 folks. elf is... | 23:27 | |
Juerd | mncharity: Really I have no idea. | 23:28 | |
23:28
Zygo left
|
|||
mncharity | elf is an implementation of p6, composed of a backend written in p6, and a frontend written in ruby hand derived from STD.pm. | 23:28 | |
Juerd | mncharity: I have very, very few tuits available to Perl 6. | ||
I see | |||
My main complaint about Perl 6 development is that it's so invisible if you're not actively tracking it. | 23:29 | ||
There are no mailing list summaries, there's just a bunch of blogs. And that's very limited. | |||
mncharity | the backend self-compiles, it uses a p5 runtime in an almost-but-not-quite pure manner (there are one or two dangling kludges), and a small single digit percent of the t/ test suite is passing. | 23:30 | |
Juerd | Mainly, my impressions of Perl 6 are limited to the design meeting minutes posted by chromatic, and the rakudo progress info posted by jnthn | ||
Which t/ test suite? | |||
mncharity | pugs | ||
Juerd | Then anything >1% is impressive for something so young that I didn't know about it yet :) | ||
mncharity | misc/elf/run-tests.result_faster | ||
lol | |||
Juerd | That test suite is huge. | 23:31 | |
mncharity | misc/STD_red is actually up to parsing ~70% of the files. | ||
some fraction of which are even correct parses. ;) | |||
Juerd | ...correctly? :) | ||
mncharity | lol | ||
Juerd | Right. | ||
mncharity | maybe I should do another design meeting. or send a note. previous experience of the former was not a win. | 23:33 | |
visibility has been intentionally lowish. t/ just started being run a few days ago. | 23:34 | ||
Files: 813. 602 parsed 74%. 239 run 29%. 44 ok 5%. Tests: 16409+. 620 ok <3.77%, 15789+ not. Though a commit or two behind. | 23:36 | ||
run means a plan was seen, so the p5 emitted wasn't so invalid perl or strict died. | 23:37 | ||
*died immediately | |||
meppl | good night | 23:42 | |
mncharity | the primary objective of elf is to encourage potential p6 implementation developers to be active. ie, to write a p6 compiler in p6. with the resulting pushing on spec, and on p5 runtime. current attempt to achieve that is to focus on t/. other possibilities are | ||
good night meppl :) | |||
completing the bootstrap by translating STD_red to p6, providing a fast p6 regex on p5 implementation that p5 developers can use, and... other ideas welcome. | 23:43 | ||
meppl | ;) | 23:50 | |
Auzon | Juerd: re elf, it compiles/runs in Perl 5, and is quite fast. The regular variant is <3s for say "hello, world", and the fast variant is ~.25s | 23:55 | |
elf also only requires Ruby 1.9, Perl, and a few modules, so it's pretty easy to get running | 23:58 |