»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg p6eval perl6: ... | irclog: irc.pugscode.org/ | UTF-8 is our friend! | Rakudo Star Released!
Set by moderator on 11 August 2010.
00:00 Psyche^ joined
diakopter sorear: the disconnections seem to be resolved 00:02
cognominal I dont know why the simplest perl6 programs opens it 15 times in a row.
plobsing It is probably using &_config from parrot's config.pir to try to determine things. cacheing might be useful. 00:04
pugssvn r32022 | lwall++ | [STD] "$a.$b" produced bogus method call and didn't check $a correctly 00:08
00:12 infrared left
plobsing cognominal: the constructor for PCT::HLLCompiler loads it to provide the '$version' attribute. Rakudo creates 14 PCT::HLLCompiler objects. 00:19
sorear diakopter: Tentatively seems to be working now. What did you do? 00:20
TimToady std: sub g(:$1) { ... } 00:21
p6eval std 32021: OUTPUT«[31m===[0mSORRY![31m===[0m␤Can't declare a numeric parameter at /tmp/W1IEcuEbM6 line 1:␤------> [32msub g(:$1[33m⏏[31m) { ... }[0m␤Parse failed␤FAILED 00:01 113m␤»
pugssvn r32023 | lwall++ | [STD] disallow 'my $$$$a' 00:22
diakopter sorear: I didn't do anything :)
TimToady just like most "cures" for arthritis... 00:23
sorear: btw, I'm working on the export problem, but it's non-trivial because EXPORT:: currently sits in the lex, not the package stash, which might need to be rethunk 00:36
sorear erm. export problem? 00:45
oh
diakopter: So, for strawberry, I should what, avoid all dependance on non-core XS modules? 00:48
00:51 miyagawa joined
sorear hello miyagawa 00:53
diakopter: it;s back. 00:55
00:57 colomon joined
jnthn -> sleep 00:57
01:06 redicaps joined
sorear diakopter: do you know who to talk to about fixing dalek's github plugin? 01:06
ingy colomon: you can compile rakudo* without installing it 01:07
colomon: then run: PERL6=path/to/star/perl6 make test
I think
sorear diakopter: wait a second. No XS means no Class::MOP. Do I need to de-Moose STD?
01:11 lue joined
lue cool! Someone tried to log in as me a couple hours ago! [er, I mean hi o/] 01:11
dalek ecza: d48cc27 | sorear++ | :
<pre>m Op.pm

  </pre>
   <pre style='white-space:pre-wrap;width:81ex'>Implement Op-level support for :($x, $y) := (1, 2)</pre>		 01:12
ecza: d7d7109 | sorear++ | :
<pre>m CompilerDriver.pm

m Op.pm m Optimizer/Beta.pm
  </pre>
   <pre style='white-space:pre-wrap;width:81ex'>Beta is closer; still need to handle lexicals</pre>
ecza: f6ca7b8 | sorear++ | :
<pre>m CgOp.pm

m Niecza/Actions.pm m Op.pm m Sig.pm
  </pre>
   <pre style='white-space:pre-wrap;width:81ex'>Remove several fossils from Decl::SimpleVar</pre>
diakopter sorear: XS isn't a problem at all 01:15
sorear: I don't remember the specifics; I'll look at it again tonight. 01:16
sorear should I ask Alias for information on what modules are OK to use?
sorear goes off and rereads perlport 01:17
diakopter no; that'd be a burdensome request
sorear: don't worry about it until I get back to you with error messages or a success report :) I'll try tonight 01:18
01:23 gbacon joined 01:24 TiMBuS joined 01:45 petdance joined 01:59 whiteknight joined
diakopter sorear: ping 01:59
sorear pong. 02:01
STDeco's sins according to perlport: * Manipulating paths without File::Spec * Using %ENV at all * Relying on XS modules * Character class ranges 02:02
I am thinking of changing STDeco to use Storable and __DATA__ instead of YAML::XS and heredocs, anyway 02:03
ingy :( 02:04
02:04 ruoso joined
ingy __DATA__ and YAML::XS! 02:04
sorear That might work 02:05
The big problem with heredocs is that they get interpreted twice
leading to the beauty of YAML::XS::Load(Encode::encode_utf8(<<RETREE_END)); 02:06
because YAML::XS and perl both think that they should be doing the byte->char conversion
ingy I think YAML::XS has a utf8 bug :\\ 02:07
I'll look into it
02:08 Ragnar1990 joined, Ragnar1990 left 02:10 literal joined 02:11 drbean joined
diakopter sorear: well, the Makefile would need entirely rewritten to work in cmd.exe/strawberry/dmake 02:12
02:13 Felipe__ joined
diakopter sorear: so, on that note, I'll have to give up on that effort, indefinitely 02:16
sorear diakopter: feel free to completely rewrite STDeco's makefile. I do not like the current one at all.
diakopter I would, if I understood it in the slightest 02:17
sorear I don't really understand it either
I'm not really good at the whole "bootstrapping" thing 02:18
diakopter then we are paddleless above a creek
sorear the crux of the makefile is ./viv -5 -o STD.pmc STD.pm6
everything else is scheduling stuff to try and keep us out of bootstrap hell 02:19
a lot of the stuff there is fossils from back when viv was in active development
diakopter odd... (more) 02:20
sorear in particular the STD.store stuff
diakopter die "Did you run make in src/perl6?";
sorear Storable can pull in a 15MB parse tree dump in about 1/16 of the time needed for STD to reparse it
diakopter is executed
when I run perl viv -5 -o STD.pmc STD.pm6 02:21
sorear STD.pm needs to be deleted
diakopter ok, I did that..
sorear I'm not sure if this is a Perl bug
diakopter now I get Can't locate STD.pm in @INC 02:22
sorear but STD.pm overrides STD.pmc if they're in different areas
you haven't built STD yet
the bootstrap version of STD.pmc is kept somewhere else
stage0 I think
diakopter so... 02:23
sorear there are @INC shenanigans to find the correct version at each stage of the bootstrap
they were mostly created by a random design walk
diakopter i see
installing Moose now.
sorear I think the current approach is to set $ENV{STAGE} = 0, which causes stage0 to be added to @INC 02:24
recently Audrey changed the executables to add the $0 path to @INC in front of the system libpath
diakopter ok, this is fail. need a much newer strawberry
sorear which avoids certain issues if there's an installed CPAN STD 02:25
STAGE=0 adds /stage0 *in front of that*
diakopter in cmd.exe ? 02:26
sorear it might be saner if the built STD.pmc and the invariant files (CursorBase, RE_ast, etc) were kept in entirely different places
STAGE=0 ./std CORE.setting # because STD isn't smart enough to compile .setting files on demand
02:27 jhuni joined
sorear STAGE=0 ./viv -o STD.pmc -5 STD.pm6 02:27
diakopter ok but that's not how it would look in cmd.exe
sorear STAGE=0 ./viv -o Cursor.pmc -5 Cursor.pm6
those three command should be the minimal Unix build sequence with the current guts
02:28 Felipe__ joined
diakopter trying to install Moose on much later strawberry, now. 02:28
02:28 leprevost joined, miyagawa left
diakopter sorear: strawberry uses dmake.exe, btw 02:29
sorear would it help if --use-bootstrap-std became a command line argument 02:31
instead of using %INC
02:31 ruoso joined, araujo joined
sorear tools.openoffice.org/dmake/index.html ? 02:32
diakopter yeah I think that's a version.
I think it's not distributed with strawberryperl, but instead it downloads some "fully-unencumbered" (old[er]) build of it from somewhere 02:33
upon first opportunity
nice; Moose installed ok
LibYAML installed ok 02:34
sorear: it seems to be working. Compiling *.pm6 02:35
tylercurtis Do
tylercurtis accidentally hit enter. 02:36
diakopter that's smiled upon
that works 02:37
and SPEEDY too
perl viv -e 'say("hi")'
300ms
course, I have lines such as: Γöé ΓööΓöÇVAST::value__S_number, BEG: 4, END: 5, SYM: number, WS: 1, 02:39
afk&
tylercurtis Do super (callsame/with or nextsame/with) calls in Perl 6 roles and classes that compose roles have flattening semantics like Smalltalk traits? 02:42
TimToady those calls do not see roles at all, only whatever has been flattened into the classes, so I think your answer is "yes" 02:43
if the same role goes into more than one class, nextsame will find all of them 02:44
likewise if you mixin a role, you get a new anonymous class 02:45
tylercurtis rakudo: role A { method f { say 'A'; } }; class B does A { method f { say 'B'; callsame; } }; B.new.f
p6eval rakudo b64718: OUTPUT«B␤»
tylercurtis So, that's the correct behavior, right? 02:46
TimToady callsame can't be used for that
yes
and is intended to be like Smalltalk traits
tylercurtis Thanks. I thought that would be the case. I'm just trying to make sure I understand both in what ways roles are the same as traits and in what ways they differ. 02:47
02:48 molaf joined
tylercurtis rakudo: role A { has $!f; }; class B does A { has $!f; }; say 'alive'; 02:52
p6eval rakudo b64718: OUTPUT«===SORRY!===␤Attribute '$!f' already exists in the class, but a role also wishes to compose it␤»
tylercurtis rakudo: role A { has $!f; }; class B does A { method f { say $!f; } }; B.new.f; 02:53
p6eval rakudo b64718: OUTPUT«Any()␤»
tylercurtis rakudo: role A { has $f; }; class B does A { method f { say $f; } }; B.new.f; 02:54
p6eval rakudo b64718: OUTPUT«===SORRY!===␤Symbol '$f' not predeclared in f (/tmp/ij1tqoqco6:22)␤»
TimToady well, we went beyond the original traits when we allowed attributes
but we were already starting to treat roles more like generics than traits are 02:55
tylercurtis "also is Foo" also seems to be an extension (although traits perhaps might have allowed that if Smalltalk allowed multiple inheritance). 02:57
02:59 Italian_Plumber joined
tylercurtis S14 suggests that one way to deal with conflicts is "to write a class method that overrides the conflicting role methods, perhaps figuring out which role method to call." How would the method in the class call the role methods? 03:00
TimToady I think it allows self.RoleName::meth 03:09
not sure what rakudo implements there though
03:16 mjk joined
perigrin_ TimToady: there has been later papers about stateful Roles from what I've heard 03:23
tylercurtis +1 to that (although I'm not sure I like that it's "self.RoleName::meth" instead of "self!RoleName::meth"). Much nicer than the aliasing Smalltalk traits require.
03:27 TomDLux joined
TomDLux evening, folks 03:27
perigrin_ notes that there has not been later papers regarding his own attrocious manging of the English language. 03:28
perigrin tylercurtis: having listened to people complain about the aliasing that Moose requires for the same collision problem ... yeah I like that solution too :) 03:32
tylercurtis Evening, TomDLux. 03:33
TomDLux I've tried try.rakudo.org, and while it works fine for say ( 1 | 2 | 3 ).perl ... but it generates an eror for assigning the junction to a var, and then doing something with the var. I have seen that in some discussion ... is try.rakudo.org just out of date? 03:35
ash_ rakudo: say (1 | 2 | 3).perl 04:02
p6eval rakudo b64718: OUTPUT«any(1, 2, 3)␤»
pmichaud I have a patch for nqp-rx that gives about a 9% improvement in Rakudo's compile speed.... should I commit it to Parrot or wait until after the release? 04:09
PerlJam pmichaud: presumably it also helps other compiler writers? 04:13
pmichaud PerlJam: yes; my only question is whether there might be a bug lurking that isn't adequately tested by the standard tests 04:15
PerlJam leans towards committing than not 04:16
ash_ pmichaud: have you tried rakudo's tests too?
i presume, if it passes its tests, and still builds rakudo, that should expand its tests a bit too 04:17
pmichaud ash_: yes, it passes rakudo's tests also
and nqp's
ash_ s/builds rakudo/builds rakudo and tests successfully/
04:20 karb joined
pmichaud okay, committing patch. 04:26
dalek p-rx: 6e87137 | pmichaud++ | :
<pre>m src/Regex/Cursor-protoregex-peek.pir

   <pre style='white-space:pre-wrap;width:81ex'>Allow protoregexes to avoid calling !cursor_debug when debugging is turned off.</pre>		 04:27
p-rx: 4dc9c4b | pmichaud++ | :
<pre>m src/PAST/Compiler-Regex.pir

   <pre style='white-space:pre-wrap;width:81ex'>Avoid calls to '!cursor_debug' method when debugging is disabled.
This (combined with previous commit) appears to improve Rakudo compilation speed about about 9% on the core.pm benchmark.</pre>
p-rx: c95f68a | pmichaud++ | :
<pre>m src/stage0/HLL-s0.pir

m src/stage0/P6Regex-s0.pir m src/stage0/Regex-s0.pir
  </pre>
   <pre style='white-space:pre-wrap;width:81ex'>Update bootstrap with improved debug calling.</pre>
rcfox Is it possible to have class variables, rather than object variables?
pmichaud ?
rcfox "Static members" ?
pmichaud oh
yes, use 'our' or 'my'
rcfox Instead of has?
pmichaud yes.
afk for a short while 04:30
rcfox Thanks.
PerlJam rcfox: what are you doing with class variables? (I don't think we have a good example for the book) 04:33
(actually, I don't think we have *any* example for the book)
rcfox PerlJam: Actually, I'm using it in a grammar. :) 04:34
Give me a few minutes and I'll have something to show. 04:35
sorear is back 04:36
04:37 redicaps left
sorear diakopter: nice! 04:39
diakopter: So I guess binmode STDOUT, ":utf8"; isn't adequate to print arbitrary Unicode characters on Windows, huh. 04:41
Alias <sorear> should I ask Alias for information on what modules are OK to use? 04:46
sorear: Most XS works just fine, unless it wants to link to some underlying libwhatever that we don't have
05:09 Cyrus joined 05:14 kaare joined
jdv79 XS-- 05:18
rcfox PerlJam: github.com/rcfox/Perl-6-English-Par...English.pm 05:20
(Some of the alignment is wonky because cperl-mode doesn't like Perl 6 in some cases.) 05:21
dukeleto Something doesn't make sense about the graph at rakudo.org/status . It looks like there are more passing tests than spec tests. What is up?
dukeleto would just like to say "Rakudo passes about X % of the perl 6 spec tests currently" for a presentation. /me would like to know what I should say X is 05:22
pmichaud the script I was using isn't counting tests correctly any more
something changed in the test output or the structure of the tests.... and I haven't had a good chance to go back and fix it
dukeleto pmichaud: i see. could you give me a rough estimate for what X is currently?
pmichaud the hard part is knowing how many tests there actually are 05:23
we don't have a good way of calculating that.
dukeleto pmichaud: ok. is there a better statistic that I can mention ?
dukeleto is working on his PL/Parrot + PL/Perl6 talk for PDXPUG: pugs.postgresql.org/pdx 05:24
pmichaud when is your presentation?
sorear dukeleto: the last time X was calculated, it was ~80. But it's really not a good measure because the spectests are really the rakudotests now 05:25
the total amount of spectests has been changing over time
dukeleto pmichaud: my presentation is thursday at 7pm 05:26
pmichaud okay. I can get you a number tomorrow, I think.
dukeleto sorear: yes, which is why i assumed that a % was better than saying "we pass 12,454 spec tests"
pmichaud: cool! I appreciate it.
sorear we passed 30k around June 05:27
pmichaud dukeleto: well, the problem with a percentage is that saying we pass 100% of 5K tests is a lot different from saying we pass 80% of 25K tests :)
tylercurtis rcfox: heh. I don't use \\s+ or similar in my grammars because cperl-mode interprets it as a substitution.
dukeleto pmichaud: yes, both have their pitfalls, no better way to lie than with statistics 05:28
rcfox Heh, weird.
tylercurtis dukeleto: How about "We pass X% of the N spectests."? 05:29
dukeleto tylercurtis: sure. But it seems that N's wavefunction won't collapse until pmichaud observes it 05:30
tylercurtis dukeleto: True. But you can't know X until you know N. 05:31
05:34 am0c joined
dukeleto has a few slides to get PostgreSQL database people interested in Rakudo, anybody have suggestions? 05:38
sorear giving a link
dukeleto sorear: a link to rakudo.org ? I plan on giving lots of links
sorear I meant to the slides 05:39
so we could give context-appropriate advice
dukeleto sorear: ah, I am working on them now, will push a skeleton in a few mins. In the meantime, take a look at pl.parrot.org/plperl6.html 05:40
sorear: github.com/leto/presentations/raw/5...G/pres.pdf 05:45
sorear: that is just a rought skeleton, i haven't added in the example code for PL/Perl6 yet, but gives you a feel for it
sorear: i want to excite and attract developers to PL/Parrot+PL/Perl6 and therefore parrrot and rakudo. any suggestions you have regarding that would be greatly welcome 05:46
05:49 lucs joined
sorear wonders if a slightly fancier demo would be an improvement 05:51
dukeleto sorear: what kind of slightly fancier demo? 05:54
sorear: you mean a fancier example stored procedure in PL/Perl6 ? 05:55
sorear yes 05:56
plobsing that second PL/Perl6 demo makes me wish for "@_ -> ... { ... }" as a kind of let-like syntax
sorear I didn't see any PL/Perl6 example at all
plobsing the first link 05:57
sorear only a PL/PIR example which implements +5
plobsing pl.parrot.org/plperl6.html
dukeleto sorear: that link has a good example procedure
05:57 wtw joined
dukeleto sorear: i will probably use that example in the presentation, with possibly a few others 05:57
05:58 cjk101010 joined
sorear my ($limit) := |@_ 05:58
dalek ecza: 1a512a6 | sorear++ | :
<pre>m Op.pm

  </pre>
   <pre style='white-space:pre-wrap;width:81ex'>Beta-reduction: decls and bare blocks</pre>
ecza: d059983 | sorear++ | :
<pre>m CompilerDriver.pm

m Optimizer/Beta.pm
  </pre>
   <pre style='white-space:pre-wrap;width:81ex'>Finish fixing and put beta-reduction live
30% decrease in test suite runtime, -15K SAFE.dll, -80K compiled testsuite</pre>
sorear How much incremental time would it take to get, say, PL/Lua working? 05:59
dukeleto plobsing: yeah, the -> ... { }(|@_) looks a bit scary to a newcomer. What is that (|@_) syntax called?
sorear dukeleto: Would it be possible to just use $^limit? 06:00
dukeleto sorear: basically, PL/Parrot needs to know where an HLL pbc lives, then it loads that in a Parrot interpreter for that HLL, and then a bit of wrapper code is needed to execute strings of Lua and data marshall
sorear: could be. how would $^limit be used ? 06:01
sorear needs to come up with a bunch of concrete syntaxes for Niecza's IRs
sorear is looking at 56,500 lines of yaml dump
CREATE ... $$
[+] (1, 1, *+* ... $^limit); 06:02
$$
plobsing that would be really nifty
dukeleto sorear: look at github.com/leto/plparrot/blob/master/plperl6.pir for how the data marshalling is done in PL/Perl6
sorear S06:1733 "Placeholder variables" 06:03
already handled in Rakudo 06:04
tylercurtis wants Smalltalk's semicolon but isn't sure he actually has any use for it.
dukeleto sorear: i will try adding a test using $^limit now
tylercurtis rakudo: (.say: 'foo'; .say: 'bar') given $*OUT 06:05
p6eval rakudo b64718: OUTPUT«foo␤bar␤»
dukeleto sorear: gist.github.com/528644 <-- error i get trying to use placeholder variables 06:08
sorear: seems like I can't do sub (@_) { ... } with placeholders 06:09
06:11 itz joined, au|irc joined, andyrhee joined, japhb_ joined
plobsing dukeleto: it appears you can wrap using just 'sub {' in stead of 'sub (@_) {' and it does the right thing wrt placeholders vs @_ 06:12
rakudo: (sub { say $^limit })(12)
p6eval rakudo b64718: OUTPUT«12␤»
plobsing rakudo: (sub { say @_[0] })(12)
p6eval rakudo b64718: OUTPUT«12␤»
06:13 szbalint joined, jdv79 joined
dukeleto plobsing: does it work within an eval ? i will try it 06:13
06:14 chitragupt joined
dukeleto plobsing: i get "Too many positional parameters passed; got 1 but expected 0" when I remove the (@_) signature for the sub 06:14
tylercurtis If you don't use @_ within it, it won't expect a *@_ parameter. 06:16
plobsing dukeleto: can I see the code giving you this error? 06:17
dukeleto rakudo: (eval q<<< sub { say 42 } >>>)(1)
p6eval rakudo b64718: OUTPUT«Too many positional parameters passed; got 1 but expected 0␤ in <anon> at line 1:/tmp/EpcYfeWj84␤ in main program body at line 22:/tmp/EpcYfeWj84␤»
dukeleto plobsing: there ya go
plobsing well sure it'll give you that error. your block is smart about how many params it expects and enforces that. 06:18
rakudo: (eval q<<< sub { say $^x } >>>)(1)
p6eval rakudo b64718: OUTPUT«1␤»
plobsing rakudo: (eval q<<< sub { say @_[0] } >>>)(1)
p6eval rakudo b64718: OUTPUT«1␤»
dukeleto plobsing: i guess that test is just wrong, then.
dukeleto goes and fixes stuff 06:19
sorear dukeleto: sub (@_) { is wrong
sub (@_) { expects 1 array parameter 06:20
sub { expects any number of parameters
sub { with the @_ placeholder used is equivalent to sub (*@_), _not_ sub (@_) 06:21
also you should be passing parameters :flat
moritz_ sub { } expects zero parameters
plobsing rakudo: (sub { }).signature.perl.say 06:22
p6eval rakudo b64718: OUTPUT«:()␤»
dukeleto sorear: i flatten the array in PIR
i am running into the issue that sub {} expects 0 zero parameters, as moritz++ says 06:23
so perhaps I want (*@_) ?
06:24 am0c joined
sorear sub {} expects 06:24
plobsing dukeleto: you want *@_ if you want weak argument-arity like perl 5
sorear 0 parameters if no placeholders are used
0-infty parameters if @_ is used
dukeleto I still get that same error "Placeholder variable cannot override existing signature" when if I use *@_ 06:25
06:25 foodoo joined
cjk101010 I thought sub {} is equivalent to sub (*@_) {}? 06:25
dukeleto s/when if/when/
sorear forgive my pg-stupidity, but surely somefunctionwithnoargs(1,2,3) failing is a GOOD thing?
if you want the function to accept any number of parameters, use @_ in it somewhere
moritz_ cjk101010: not anymore 06:26
dukeleto: why don't you let the user declare a signature?
sorear or maybe allow some kind of WITH SIGNATURE clause in the header, of pg lets you do that
dukeleto sorear: yes, i agree. But there is the definition of the function signature to Postgres, and the definition of the signature in PL/Perl 6. I was telling Postgres to expect 1 param, but not telling Rakudo to expect any, and that is probably just a bad test on my part 06:27
cjk101010 moritz_: what's the difference? and since when it isn't equivalent anymore? It's written in the 5-to-6
+tutorial
moritz_ cjk101010: these days when there is no signature, perl tries to be smart about guessing the arity, besed on your (non-)usage for @_ in the subroutine 06:28
I'll update the 5-to-6 thing, thanks
cjk101010 ok… thanks for the information.
sorear dukeleto: so basically this stuff lets you add new SQL functions in any language? like select * from log where channel = '#perl6' and my_p6_regex(text); ?
dukeleto moritz_: i have thought about that. With PL/PIR, the user *does* declar the signature. But currently, I don't do that in PL/Perl6. Perhaps I should. Pointy blocks (like described on pl.parrot.org/plperl6.html) alleviate the situation a bit, but placeholder variables seem to be borked 06:29
cjk101010 by the way, great work with perl6… I'm really impressed
06:29 uniejo joined
dukeleto sorear: PL/Parrot lets you embed any Parrot HLL as a language to write stored procedures in Postgres. So, yes :) 06:30
tylercurtis dukeleto: well, you could probably do { blablabla $^placeholder }(|@_)
dukeleto moritz_: one concern is security. if the user can specify the function name and signature, they can overwrite other functions and do nefarious things. PL/PIR still uses anonymous subs, but allows the user to specify the signature, since in PIR the signature is actually part of the subroutine 06:31
moritz_: the stored procedures are actually all anonymous, so that other procedures can't modify them, only call them from SQL. 06:33
moritz_: so, what I actually want is a way for an end-user to specify a signature but not the name of the sub. That is why I thought pointy blocks would be what I wanted
moritz_ dukeleto: you can do that with sub to 06:34
rakudo: my $x = sub ($x, $y) { say $x * $y }; $x(2, 5)
p6eval rakudo b64718: OUTPUT«10␤»
06:35 Su-Shee joined
dukeleto moritz_: perhaps I can just have the end user write "($x,$y) { ... }" and I can prepend a "sub " to it before compilation. interesting. 06:35
sorear dukeleto: I've never been in a position to use stored procedures; the question was aimed at clarifying how they were used
tylercurtis Good night, #perl6! 06:37
dukeleto sorear: they are used when a user wants to call code written in languages other than SQL from SQL 06:40
plobsing dukeleto: how about expecting a code object returned from the eval? users can overwrite names all they like because you only hold on to anonymous references to code objects.
sorear How demanding is pg's security model? 06:42
Should Alice be able to do &infix:<+> := &infix:<->; and affect Bob's PL/Perl6 procedures?
dukeleto plobsing: i thought that was what eval q<<< sub .... >>> did ? I store the output of the eval in a PIR variable and invoke it
sorear (Do stored procedures even have owners?) 06:43
plobsing dukeleto: sure, but if you do that, why be worried about subsequent overwrites? your reference won't change out from underneath you.
dukeleto sorear: that is a good question. Usually only the database super-user can write stored procedures, but anybody else can call/use them 06:44
sorear: but if you allow anybody to write them, then your example with modifying &infix can happen 06:45
plobsing: perhaps my worry about overwrites is unnecessary. But I only hold onto the code object until it is run, then that goes away. 06:46
plobsing: so I think that if two procedures named foo are defined, the last one wins 06:47
plobsing: i am not even sure if it is a huge issue, because in theory, DBAs would only let a trusted user write procedures
plobsing: but PG has a concept of trusted and untrusted languages. The untrusted ones have a bunch of restrictions about what they can do, so my worries about overwriting defintions are mostly for when/if the trusted version of PL/Perl6 happens 06:49
is there a way to syntax check a snippet of Rakudo from PIR without running it? 06:52
sorear call perl6;Perl6;Grammar.parse maybe? 06:54
you'll need to set up a few environmenty bits
plobsing don't phasors and macros need to be evaluated in order to parse Perl 6?
moritz_ yes 06:55
plobsing so then you can't parse Perl 6 with a guarrantee of not running anything 06:56
sorear std: BEGIN { say 2 + 2 } # You can fake it pretty well
p6eval std 32023: OUTPUT«ok 00:01 115m␤» 06:57
dukeleto wonders if/how phasors should be dealt with in PL/Perl6 07:02
plobsing can you parse in an extremely paranoid sandbox? 07:03
sorear Not in current Rakudo
plobsing in the extreme case you could fork off a child and drop all perms. How often do stored procedures get parsed? 07:05
mathw You could have a subset of Perl 6 which didn't allow macros and compile-time phasers I suppose
dukeleto would probably be fine with a subset of Perl 6 without phasors/macros 07:07
plobsing: in theory, they should be only parsed once. I think that is true currently.
sorear Why are you so concerned about phasors, anyway 07:16
What do you have against CATCH 07:17
pragma_ what the frick is a phasor
sorear They're actually spelled phaser
pragma_ oh, a phase changer?
sorear S04:1275
pragma_ now that makes more sense and less star-trekkie.
carry on, gentlemen.
sorear the perl 6 naming process has always been pun-oriented 07:18
pragma_ a pun is fun
sorear Alias_: semi-OT: diakopter talked about Strawberry using a nonstandard make, some kind of old forked version of dmake. Where can I read more about this? 07:24
dukeleto sorear: one could say that Perl 6 runs on puns
dukeleto just caused an infinite loop in Parrot's GC with PL/Parrot. Maybe it is time for bed... 07:26
frettled Perhaps the basic type should be Pun
dukeleto frettled: one pun for Mu, one pun for me, ... 07:27
sorear dukeleto: I wonder what the security implications of embedding Parrot
frettled exactly :)
sorear 's GC into pgsql are
How well does pg handle sigsegv?
dukeleto sorear: it core dumps
sorear: the connection core dumps, not the master process
sorear pg forks after accept? 07:28
dukeleto sorear: for instance, there is a bug in IMCC that throws parse errors incorrectly, so syntax errors in PIR cause a core dump. Not fun.
sorear I'm more thinking of the fact that Parrot's mark recurses on the C stack
dukeleto sorear: pg forks a thing called a pg_backend for every connection to the database. So invalid PIR coredumps the backend 07:29
sorear so building a linked list with more than 50,000 or so nodes will dump core with standard Linux stacklimits
(fixing this is nontrivial but a high priority)
dalek ecza: aae0b1f | sorear++ | :
<pre>m Op.pm

m RxOp.pm
  </pre>
   <pre style='white-space:pre-wrap;width:81ex'>Enable regexes to use beta-opt</pre>
sorear finds that he uses git-grep a lot more often than ack now 07:37
07:47 tadzik joined
tadzik ahoj 07:47
mathw oh hai tadzik
07:50 mjk joined 07:51 cono joined
sorear hellow tadzik 07:52
07:59 barney joined
moritz_ support.github.com/discussions/repo...roken-html 08:12
avar I can also bring in a commit bot here that uses the github API and isn't broken like that 08:14
moritz_ now that would be nice 08:15
avar It needs everyone to add a post-receive-hook though: help.github.com/post-receive-hooks/
08:16 dakkar joined
avar This is how it looks like: paste.scsys.co.uk/48377 v.nix.is/~avar/bot.png 08:17
It tries to emulate the github timeline view
moritz_ hm; a bot could be pull-only and still use the github API 08:19
avar sure, but not the post-receive-hook api 08:20
which is lazier :)
sorear Why don't we just use CIA?
moritz_ it doesn't have the karma hooks that dalek comes with :-) 08:21
sorear karma hooks? 08:23
avar You could also make CIA announce commits in #perl6-secret, then have a bot there that funnels the messages here after performing regex replacements on them.
That'd probably be easiest if CIA does what you want, just ~30 lines of POE code
moritz_ would probably need 200 08:24
I currently don't feel up to actual work, maybe my blood pressure rises later to a reasonable levell, then I'll see what I can (and want to :-) do 08:26
sorear avar: why bother? CIA already supports custom print formats
avar That was predicated on "if that's needed..." 08:27
you'd also need a name -> nick mapping
08:29 dakkar joined 08:36 mjk joined
dukeleto moritz_, plobsing, sorear: i just updated PL/Perl6 so that end users can specify the function signature and placeholder variables now work as well. Thanks for all the suggestions! 08:43
moritz_ o/ 08:44
sorear yay 08:55
I don't see a way to set up a nick mapping with CIA, although I can set the karma hook 08:56
so y'all will need to have your CIA nickname be the same as your #perl6 nickname, I think
(which need not be the same as your github id. I think.) 08:57
09:02 timbunce joined 09:05 thebird joined 09:13 nadim_ joined
jnthn morning, 6folk 09:15
moritz_ mrnng 09:16
sorear hello jnthn
mathw lolitsjnthn 09:19
mathw has a happy
nadim_ morning, I was reading Gabor's post about the +- operator (it wasn't clear if it was built in or gabor's) and I wondered if it was possible to defined junctions with user defined operators? can någon point me to an URL? 09:20
tadzik hello
nadim_ s/någon/someone/
mathw the +- operator in that post is a custom one
sorear nadim_: junctions and user-defined operators are completely orthogonal in rakudo
mathw autothreading of junctions should work over user-defined operators
unless you specifically define them in such a way that it doesn't 09:21
09:21 masak joined
masak hola, #perl6! 09:21
jnthn como estas, masak? 09:22
.oO( I bet I got that wrong... )
 09:23
nadim_ so $j = 3 +- 3 ; say 't' if 4 ~~ $j ; # print t ?
masak jnthn: you seem to have gotten that right, modulo IRC-optional accents :) 09:24
jnthn heh
masak jnthn: I'm fine, thanks. still struggling a bit with sleeping on the right hours. why was it so easy in Italy, but so difficult here at home? :/ 09:25
jnthn After 2 years, Slovak never got me writing its accents on IRC. :-)
masak: I dunno...maybe the need to get up in the morning for the conference helped? :-)
09:25 Trashlord joined
masak jnthn: a small part of me protests that those are not accents, but something else. I don't know if linguists actually separate the two, though. 09:26
arnsholt masak: You called? =)
moritz_ that's why :sameaccent got renamed to :samemark
masak jnthn: well, it was more like I woke up consistently at 7, and that was pretty convenient for the conference as well.
moritz_ www.perlmonks.org/?node_id=855407 please correct me if I wrote BS somewhere 09:27
arnsholt But yeah, the distinction between accent and not is kinda fuzzy
mathw saluton, masak 09:28
sorear masak: the general term is diacritical mark
hence samemark/ignoremark
masak sorear: ah, thanks.
sorear wonders how often the dakuten gets called an accent 09:29
masak sorear: so maybe Slovak things could be said to be diacritics but not accents?
09:29 jferrero joined
jnthn masak: They may be more than one type of thing... :-) 09:29
moritz_ is the french cedilla an accent?
nadim_ no
non 09:30
arnsholt I'd say yes =)
jnthn moritz_: I'll try and write some kind of blog post in the next couple of days with an update on the state of things in this area.
mathw moritz_: looks as accurate as my knowledge can assess
arnsholt Is the dot over the i an accent, though? =)
masak mathw: saluton! what's the state of Form, and what's the next step in its evolution? :)
mathw The state is unchanged since R* 09:31
moritz_ did you mean "the dot over the ı"? :-)
mathw The next step is some documentation
arnsholt moritz_: Exactly =D
nadim_ accents is what make you pronounce domething slightly differently. The cedila makes a different phoneme. IMO of course
jnthn moritz_: Note that the meta-model for Rakudo will be re-written into NQP
mathw I also need to understand what exactly is going on with passing certain things to sub form() and whether what currently has to be done is right or not
jnthn moritz_: It will thus not need to be re-written per backend. 09:32
mathw \\o/
jnthn Just re-worked once, which has to happen during the great metamodel upheavel anyways. :-)
mathw Rakudo on not-Parrot could be really really good 09:33
sorear actually the dakuten might be an accent, since it sometimes gets dropped or added for no reason
moritz_ jnthn: I don't think I understand. The metamodel needs to build on top of some primitives, which will likely be different among different backends
jnthn I expect to have something interesting to show on the "port of NQP to .Net" front later on this week.
sorear I would like to point
nadim_ sorear: that would be the worst definition ever of what an accent is!
jnthn moritz_: Rakudo's ClassHOW will be built upon some universal, portable primitives. 09:34
sorear out, re. Niecza vs. multi-backend Rakudo, that I don't see the competition
mathw jnthn++
sorear++
moritz_ sorear: me neither; which is probably not quite clear from www.perlmonks.org/?node_id=855440 09:35
which is what I meant with "Neither Sprixel nor Niecza are a Rakudo port to a different platform. They have rather different goals than Rakudo. If we can re-use some of their code, we will."
jnthn moritz_: That's more accurate.
I expect there to be some idea sharing and so forth. 09:36
But the "port PAST and NQP" steps for Rakudo is a very deliberate part of what I'm doing too. 09:37
They've proved to be a good toolchain for compiler hacking. Now they can become a good toolchain for multi-backend compiler hacking.
mathw \\o/
Why shouldn't these wonderful tools help people targetting other systems
jnthn Exactly. :-) 09:38
sorear moritz_: fwiw, I fully expect to port Niecza to Parrot at some point
moritz_ sorear: wow, that surprises me a bit :-) 09:39
masak jnthn: how does your Test::Mock stack up against chromatic's observations about his own module Test::MockObject at www.modernperlbooks.com/mt/2010/08/...bject.html ? 09:40
jnthn masak: Well, you saw how long it took me to design and implement Test::Mock. :P 09:41
masak: So probably badly. ;-) 09:42
09:42 yves joined
masak jnthn: I think I'd like to explore things in that direction. 09:42
thing is, I haven't done much mocking myself.
masak asks a question on chromatic's blog
jnthn phenny: tell masak I'm more familiar with mock testing in .Net. I can say that Test::Mock does most if not all of the mocking stuff that I needed for that use case. 09:44
phenny jnthn: I'll pass that on when masak is around.
jnthn oh gah, fail
phenny: er, where "that use case" = "a project for $dayjob"
phenny: tell masak er, where "that use case" = "a project for $dayjob"
phenny jnthn: I'll pass that on when masak is around.
jnthn ...OK, I'm really going to make another cup of coffee now. 09:45
09:45 masak joined 09:49 araujo joined
sorear any objections to me continuing Project CIA 09:55
now that Infinoid has become reachable, it's a little less urgent, but I'd still like to try it 09:56
moritz_ sorear: I personally don't like bots entering the channel just for a commit, and leaving again. But it's not a good reason.
sorear moritz_: Did CIA once do that? 09:57
moritz_ sorear: wait, I think I'm confusing CIA with the github.com owned bots 09:58
masak another Twitterer liking Perl 6: twitter.com/cjk101010/status/21381010302
phenny masak: 09:44Z <jnthn> tell masak I'm more familiar with mock testing in .Net. I can say that Test::Mock does most if not all of the mocking stuff that I needed for that use case.
masak: 09:44Z <jnthn> tell masak er, where "that use case" = "a project for $dayjob"
masak right. but it's interesting to consider things that people like chromatic++ and Ovid++ say about mocking, and see how they mesh with one's own mocking module. 09:59
10:00 Italian_Plumber joined
masak also, a really good piece of advice from @miyagawa: twitter.com/miyagawa/status/21359813423 :-) 10:01
masak gladly considers himself a Rakudo developer in this context :)
10:01 CIA-21 joined
sorear let's see if the custom karma hook thing works 10:01
karma sorear
buubot: karma sorear
buubot sorear: sorear has karma of 768
tadzik buubot: karma tadzik 10:02
sorear damn you, now I don't want to push
buubot tadzik: tadzik has karma of 36
sorear 3 * 2^8, such a round number :(
tadzik buubot: why so low? :)
buubot tadzik: why is buu_ so angry
bbkr rakudo: $_="aaaa"; s:1th/a/X/; .say # IMO this should be syntax error
p6eval rakudo b64718: OUTPUT«Xaaa␤»
jnthn masak: Well, next time I'm in Japan... :-)
sorear pushed...
CIA-21 03Stefan O'Rear++ 07master * reba4446 10/ (7 files):
Start decoupling sub metadata from protopads
Soon the protopad will be just like any other pad, and elidable in many cases.
+10K SAFE.dll due to duplicated functionality. - bit.ly/aIPFnx
sorear hmm. 10:03
well, the ++ custom format worked!
moritz_ bbkr: why should it?
masak buubot: karma Rear
buubot masak: Rear has karma of 1
moritz_ bbkr: or asked differently, what do you gain from forcing the user to the proper inflection form? 10:04
dalek ecza: eba4446 | sorear++ | :
<pre>m CgOp.pm

m Cursor.cs m Decl.pm m Kernel.cs m SAFE.setting m Unit.pm
  </pre>
   <pre style='white-space:pre-wrap;width:81ex'>Start decoupling sub metadata from protopads
Soon the protopad will be just like any other pad, and elidable in many cases.
  +10K SAFE.dll due to duplicated functionality.</pre>
jnthn People shouldn't have to be fluent english speakers 1nd.
bbkr moritz_: there is no such thing in english as "firth". just doesn't look good. where is the gain? future portability between different P6 implementation that may be more strict in this matter. 10:06
moritz_ std: s:1nd/a/b/
p6eval std 32023: OUTPUT«ok 00:01 113m␤»
moritz_ bbkr: you get the best portability by sticking to the spec, not by making up your own rules that seem to make sene right now 10:07
bbkr moritz_: you're right. I haven't checked STD :( 10:08
moritz_ and the spec is pretty clear that (\\d+)<identifier> translates to a colonpair with key <identifier> and value of that number
so you could also write :5pos instead of :pos(5)
bbkr moritz++ # for nice rx modifiers 10:09
moritz_ rakudo: 'abc' ~~ m:2pos/./; say $/
p6eval rakudo b64718: OUTPUT«c␤»
moritz_ :-)
bbkr std: $_="aaaa"; s:th(1)/a/X/; .say # just checking 10:10
p6eval std 32023: OUTPUT«ok 00:01 117m␤»
bbkr \\o/
moritz_ I copied that part of the implementation from STD.pm
masak sushi & 10:15
CIA-21 03Stefan O'Rear++ 07master * r8e00559 10/ (8 files in 2 dirs): 10:27
Add direct support for sub types
-10K testsuite; reward will be greater when more types than Sub and Regex exist. - bit.ly/bwiwFf
sorear ok, that didn't work
dalek ecza: 8e00559 | sorear++ | :
<pre>m Body.pm

m CodeGen.pm m Decl.pm m Kernel.cs m Niecza/Actions.pm m Op.pm m RxOp.pm
  </pre>
   <pre style='white-space:pre-wrap;width:81ex'>Add direct support for sub types
  -10K testsuite; reward will be greater when more types than Sub and Regex exist.</pre>		 10:28
10:30 M_o_C joined
sorear unfortunately github's built in CIA integration has no configuration options at all 10:32
10:33 Gruber joined 10:36 wamba joined 10:37 dalek joined 10:41 CIA-21 left
sorear (I give up) 10:43
maybe I'll find some CIA staffer and ask them
10:47 Infinoid joined
Infinoid Sorry about the trouble with dalek's log. Thanks to some guidance from moritz++, I've applied an updated. I'd love it if someone could commit something to test it out. 10:48
sorear done 10:51
11:00 Italian_Plumber joined
sorear Infinoid: it's been ten minutes since I pushed, is something broken 11:01
Infinoid I don't know. Exactly where did you push? 11:06
I don't see your push on github.com/rakudo/rakudo/commits/master
sorear no, I'm not a rakudo committer
however niecza should also be in dalek's db
github, sorear, niecza 11:07
Infinoid Ok. I see that feed in dalek's log, but I don't know what the feed polling interval is 11:08
sorear dalek has per-feed polling intervals? for someone who theoretically maintains it ... 11:09
Infinoid I theoretically maintain it
dalek generates dynamic polling intervals, so it doesn't hammer the server with a large number of polls at exactly the same moment
...and so it doesn't time out of IRC while doing so
sorear it does a pretty good job of flooding itself off irc when combined with git push 11:10
Infinoid It's not particularly smart, it just increments the interval for each new feed. Figuring randomness is better than always hitting the worst case
Sure, there's no protection from large numbers of updates on a single feed
sorear oh, you meant because of time spent in the poll routine
nine moritz_: oh, I think, I patched test_summary.pl to produce correct JSON 11:11
Infinoid yeah, time waiting for http and such
If github connections are timing out, we don't want to wait serially for 30 timeout periods all at once
sorear and no multithreading. 11:12
:)
Infinoid Yeah. I didn't write the bot, and I didn't install it, I just wrote some plugins for it :) 11:13
Should probably rewrite them in rakudo at some point.
sorear Who *did* write the bot 11:14
11:14 meppl joined
Infinoid sorear: It's botnix. 11:22
11:25 daxim joined
sorear Botnix is a person? I thought it was the name of the bot *embarrassed* 11:25
Infinoid nah, it's the name of the software 11:26
Infinoid has no idea who the authors are
11:28 dalek joined
Infinoid Might work better now. 11:28
sorear FR: dalek should log-ahead the things it was going to send, and ensure that everything gets to the channel eventually even if the bot crashes
pugssvn does this
Infinoid Lack of flow control is more a problem with the bot software than with the feed plugins 11:29
sorear has no idea how hard this would be to do in botnix
Infinoid Give me a perl6 IRC module that does that, and I will port the plugins to that bot. Deal? :)
sorear I came here to write an IRC module 11:30
Infinoid I think that would be a pretty cool thing. Or does it already exist and I haven't been paying enough attention? 11:32
moritz_ nine: then please submit that patch :-)
sorear Infinoid: some exist, but they suck 11:33
dalek kudo: 85602a2 | moritz++ | /:
remove some trailing whitespaces (dummy commit to test an IRC bot)
 11:39
ecza: 465c16d | sorear++ | /:
Implement hints as a storage category

  $?FILE no longer lives in the runtime lexpad. (User-defined hints still do for
now, since they're my variables in disguise... will fix.) -73K testsuite		 11:40
11:40 envi^home joined 11:41 pragma_ joined
masak today's task: find out why the enum commit causes pls to segfault. 11:41
Infinoid sorear: If you find a better one, and a reliable bot written for it, please let me know :)
Infinoid <-- gone 11:42
11:42 Infinoid left
sorear protopads in niecza are now exactly like any other pad 11:43
this feels like a so much better state
11:44 azert0x joined
pugssvn r32024 | nine++ | Changed spec test perf graph to show percentages instead of a multiplier 11:45
r32024 | and tweaked output.
nine moritz_: as soon as I can find what I did. git doesn't show me a commit or diff...
dalek ecza: 992bd0e | sorear++ | /:
Finally kill off share_lex

Metasubs no longer need to hold a runtime reference to the protopad, any more than any other pad. -16K testsuite		 11:46
nine moritz_: btw. what do you think of the new graph? niner.name/rakudo/benchmarks.png 11:48
tadzik oh, so looks like it's faster than it was?
nine tadzik: seems to be. Though it's hard to say how much of that is just jitter. The server used for this is bored all day, but still 11:49
sorear nine: chromatic likes to use callgrind for stuff like that 11:51
what are you benchmarking?
moritz_ nine: i like it. There are good explanations for it too (some optimizations on integer operations)
nine: re diff, try git diff origin/master..HEAD 11:52
nine: and git diff --cached
one of them should show you a diff
nine moritz_: nothing. Quite strange. From a look at the code, I think the error is still there. It's just a missing comma after all. I remember stumbling upon that but cannot say what I did then... 11:56
sorear: I'm running rakudo's spec test suite daily and collecting the run times of the individual test files and summing up the changes. 11:57
moritz_ nine: hm. I feared it's more than a single comma, since JSON doesn't like trailing commas 11:59
takadonet morning all 12:00
12:02 awwaiid joined
sorear the compiled testsuite has just crossed 1MB 12:04
negatively \\o/
from a high of 1.6MB
dalek ecza: 605bd5c | sorear++ | /:
Don't generate full protopads unless needed

In subs with no unclonable phasers or methods, it's not necessary to have a protopad. This is the first step and elides most variables from such unneeded pads. -60K testsuite
masak takadonet: \\o 12:05
arnsholt Is there an easy way to do the equivalent of $callback = sub { ... } in NQP-rx? 12:09
$cb := sub() { ... } doesn't seem to do it
takadonet anyone else noticed that the build time is a lot faster now? 12:10
sorear $cb := sub () { ... }
sub() isn't even legal Perl 6 12:11
(Unifying Rule: \\w+\\( in term position is *always* a sub call)
arnsholt Ah, not a bad idea probably 12:12
Also explains why my braino if(...) fails weirdly
sorear calls it a night
masak 'night, sorear 12:13
sorear in the last 3-4 days the runtime of MAIN.exe generated from test.pl has gone from 57s to 13s
this is so addictive
(case in point: it's 5am localtime)
masak good thing you decided to call it a night now, while that's still an option :P 12:14
dalek ecza: 91d5840 | sorear++ | /:
Elide the protopad entirely when possible

  -24K testsuite.		 12:17
12:19 lithos joined
masak sorear: so... a 'protopad' is the same as a static lexpad? 12:24
12:27 rgrau joined
masak rakudo: sub foo(--> NoSuchType) { say "OH HAI" } 12:32
p6eval rakudo b64718: OUTPUT«===SORRY!===␤Unable to parse postcircumfix:sym<( )>, couldn't find final ')' at line 22␤»
masak rakudo: class A { method foo(--> NoSuchType) { say "OH HAI" } }
p6eval rakudo b64718: OUTPUT«===SORRY!===␤Malformed method at line 22, near "foo(--> No"␤»
masak both these error messages could be improved to indicate the actual problem. 12:33
masak submits rakudobug
moritz_ agreed
masak std: sub foo(--> NoSuchType) { say "OH HAI" }
p6eval std 32024: OUTPUT«[31m===[0mSORRY![31m===[0m␤No type found after --> at /tmp/bZliUYrKsY line 1:␤------> [32msub foo(--> [33m⏏[31mNoSuchType) { say "OH HAI" }[0m␤ expecting any of:␤ type_constraint␤ typename␤Parse failed␤FAILED 00:01 113m␤»
masak std: class A { method foo(--> NoSuchType) { say "OH HAI" } }
p6eval std 32024: OUTPUT«[31m===[0mSORRY![31m===[0m␤No type found after --> at /tmp/xM7dfF2UkP line 1:␤------> [32mclass A { method foo(--> [33m⏏[31mNoSuchType) { say "OH HAI" } }[0m␤ expecting any of:␤ type_constraint␤ typename␤Parse failed␤FAILED 00:02 113m␤»
masak 'No type found' isn't spot on either, but it's much better.
12:38 bpalmer joined 12:44 tadzik joined 12:49 lichtkind joined
lichtkind join #froscon 12:49
ups
moritz_ hands lichtkind a / 12:50
lichtkind \\me grabs it :) 12:51
moritz_: thanks :)
12:52 bpalmer left
masak lichtkind: your slashes are backward. you need to walk one time around the Möbius strip, and they'll be forward slashes again. 13:05
lichtkind masak: right except this time it was a joke 13:06
masak the principle still stands. :)
13:08 orafu joined
masak rakudo: class A is NoSuchType {} 13:09
p6eval rakudo 85602a: OUTPUT«===SORRY!===␤No applicable candidates found to dispatch to for 'trait_mod:<is>'. Available candidates are:␤:(Mu $child, Role $r)␤:(Routine $r, Any :default($default)!)␤:(Code $block, Any $arg?, Any :export($export)!)␤:(Mu $child, Mu $parent)␤:(Mu $type where ({ ... }), Any
..:rw($rw)…
masak std: class A is NoSuchType {}
p6eval std 32024: OUTPUT«ok 00:01 111m␤»
masak when I make a typo in the type after 'is', I'm less interested in the available candidates to trait_mod:<is> and more interested in line number and file. 13:10
masak submits rakudobug
bbkr rakudo: class A is Mu is Mu {} 13:13
p6eval rakudo 85602a: ( no output )
moritz_ multiple inheritance ftw! 13:14
masak rakudo: class A { method foo { say "OH HAI" } }; class B is A is A {}; B.new.*foo
p6eval rakudo 85602a: OUTPUT«OH HAI␤»
masak rakudo++
jnthn++
bbkr indeed, works as expected 13:15
masak rakudo: class A { method foo { say "OH HAI" } }; class B is A {}; class C is A is B {}; C.new.*foo
p6eval rakudo 85602a: OUTPUT«===SORRY!===␤Could not build C3 linearization: ambiguous hierarchy␤»
masak submits rakudobug
it's a good day when I find something amiss in the OO system. :) 13:16
rakudo: class A { method foo { say "OH HAI" } }; class B is A {}; class C is B is A {}; say "alive"; C.new.*foo 13:17
p6eval rakudo 85602a: OUTPUT«alive␤OH HAI␤»
masak rakudo: class A { method foo { say "OH HAI" } }; class B is A {}; class C is A is B {}; say "alive"; C.new.*foo
p6eval rakudo 85602a: OUTPUT«===SORRY!===␤Could not build C3 linearization: ambiguous hierarchy␤»
masak interesting.
oh jnthn! :P 13:19
13:28 Guest19527 joined, am0c joined, tadzik joined, Holy_Cow joined 13:31 mantovani joined
masak rakudo: class A is A {] 13:34
rakudo: class A is A {}
p6eval rakudo 85602a: OUTPUT«===SORRY!===␤Unable to parse blockoid, couldn't find final '}' at line 22␤»
rakudo 85602a: OUTPUT«===SORRY!===␤No applicable candidates found to dispatch to for 'trait_mod:<is>'. Available candidates are:␤:(Mu $child, Role $r)␤:(Routine $r, Any :default($default)!)␤:(Code $block, Any $arg?, Any :export($export)!)␤:(Mu $child, Mu $parent)␤:(Mu $type where ({ ... }), Any
..:rw($rw)…
masak std: class A is A {}
p6eval std 32024: OUTPUT«ok 00:01 111m␤»
13:36 rgrau_ joined 13:42 drbean joined
masak rakudo: my $1 = "foo"; say $1 13:47
p6eval rakudo 85602a: OUTPUT«foo␤»
masak rakudo: my $1 = "foo"; say $/.perl
p6eval rakudo 85602a: OUTPUT«[Any, "foo"]␤»
masak I'm not sure if I consider this a bug or a feature :)
belay that, it's way cool :) 13:48
PerlJam looks like a feature to me :)
masak and really, really consistent.
tadzik what's Any in here? 13:50
moritz_ just Anything
13:51 javs joined 13:54 plobsing joined
masak tadzik: a value formerly known as 'undef'. 13:56
rakudo: $1 = "foo"; say $/.perl 13:57
p6eval rakudo 85602a: OUTPUT«[Any, "foo"]␤»
masak don't even need to declare the variable, in fact.
14:00 Guest23195 joined
masak Guest23195: velkommen. vær vores gæst, Guest23195. 14:01
:)
mathw That sounds like a challenge... 14:03
PerlJam It didn't sound like a challenge when I tried pronouncing it in my head. 14:09
Particularly that "velkommen" part :) 14:10
14:10 avuserow joined
masak preliminary results about the segfault: perl6 -e 'use App::Pls; use JSON::Tiny' causes it. 14:12
clearing either file out completely uncauses it. 14:13
in a way, that's bad news. but it's also a bit interesting.
I'll see if I can minimize either file.
14:16 azawawi joined
azawawi hi 14:17
masak hi
azawawi sorear: ping
14:19 avuserow joined
masak azawawi: I think he crashed after optimizing niecza all night. 14:19
azawawi masak: i see... thx 14:21
phenny: tell sorear I am getting this error when doing a 'make dist' after 'make clean all' in src/perl6. "make: *** No rule to make target `stage2/STD_P5.pmc', needed by `dist'. Stop." 14:22
phenny azawawi: I'll pass that on when sorear is around.
masak first I decided that this post might be of interest for #perl6, then I felt it might be OT, and then I changed my mind and found it highly relevant: timothyfitz.wordpress.com/2009/02/1...mes-a-day/ 14:24
maybe Rakudo would benefit from continuously running the test suite on a cluster of computers, bringing it down to a minute or so. 14:25
failures would be reported back by a bot.
colomon ick
masak and 'When I say reliable, I don’t mean “they can fail once in a thousand test runs.” I mean “they must not fail more often than once in a million test runs.”' sounds pretty nice as well.
colomon or do you mean as an extra smoker?
masak colomon: yes, something like that. a fast one. 14:26
colomon ick retracted, then.
masak we don't really have any website to deploy to, unless you count Try Rakudo.
colomon I was confusedly thinking that you wanted that to replace developer's local spectests.
masak but that doesn't feel so business-critical for some reason :)
colomon But supplementing the local spectests? -- that's cool, and not a bad idea. 14:27
mathw we could do with tests that reliable at my work
fortunately it's on my list of things to do
masak colomon: could probably be extended to the app cheese as well.
colomon +1
pmichaud good morning, #perl6 14:32
tadzik hello pmichaud
takadonet pmichaud: morning
colomon o/
masak mor-NING! 14:33
pmichaud mathw: have a name picked out for the rakudo release? 14:34
mathw not a clue 14:35
I thought there was a list?
pmichaud the list is currently empty, I think.
mathw hmm 14:36
pmichaud We can always go with Pisa
mathw that's what I was just thinking
it's appropriate
I need to read the release procedure
pmichaud I'll tentatively add Pisa for now... but it's open for change
mathw It seems like an appropriate one to me 14:37
moritz_ +1 to Pisa
pmichaud oh, is there a "Pisa.pm"? ;-) 14:38
pmichaud checks
mathw heh there is that
PerlJam notices that coming up with the release name still seems to be the most onerous part of the process :)
mathw but maybe we should also allow YAPC venues
pmichaud well, I'd like to give credit to the appropriate group, as opposed to the city in which an event takes place. 14:39
for example, next year is in Riga, but the group would be Moscow.pm (IIUC)
mathw true
point taken
I just thought of a problem 14:40
I have neither commit access to Rakudo or a CLA
PerlJam mathw: sounds like you need minions that do. 14:41
mathw I remember now
pmichaud mathw: I can give you commit access for the release
mathw I intended to sort this all out before the release
but then I forgot
and then I forgot I was doing the release this month 14:42
14:43 jedai joined
masak moritz_, pmichaud, jnthn: here's my smallest possible case of segfault with the enums patch applied to Rakudo: gist.github.com/530197 14:43
pmichaud hmm. looks like YAPC::EU was sponsored by perl.it 14:44
mathw "Italy"
or, "Rakudo #32: Just Give Me A Pizza, Okay?"
pmichaud well, there does appear to be a "Pisa.pm", and about half of the yapc::eu organizers were local to Pisa, so perhaps "Pisa" is good enough. 14:46
masak I'd say it is. 14:47
mathw I'll probably draft the release announcement tonight 14:50
then you can all assess its Suckiness Index 14:51
first I have to go and play some miserable English consort music
which is one of my favourite ways of spending the first part of an evening :)
masak spends far too much time on online MP3 stores shopping for 'miserable ENglish consort music' 14:52
s/N/n/
mathw excellent taste 14:53
mathw hopes to do five-part Jenkins today 14:54
I think all of us will be there
until afterwards
I bid you farewell
masak bows elaborately
dalek kudo: e3f9c5e | pmichaud++ | /:
Bump PARROT_REVISION.
 15:00
kudo: ae18b90 | pmichaud++ | /:
Merge branch 'master' of github.com:rakudo/rakudo
kudo: e26cb01 | pmichaud++ | /:
Add draft of 2010.08 release announcement.
kudo: 5a33278 | pmichaud++ | /:
Update 2010.08 release information in release_guide.pod .
15:00 lichtkind_ joined 15:05 drdanger joined
dalek kudo: e0850ed | moritz++ | /:
[release] fix copy&pasto, add a new feature to feature list
 15:05
15:06 Holy_Cow joined 15:21 macroron joined 15:46 Holy_Cow joined 15:50 wamba joined, wooden joined
pugssvn r32025 | lwall++ | [STD] spot-on-ify the no type message 15:56
r32025 | some preliminary work to fixing exports
15:57 justatheory joined 16:00 platypus_ joined
platypus_ how does one determine what's in a reference? Do I have a reference to a scalar, array, hash? 16:01
moritz_ how did you take the reference?
platypus_ Say i wrote: my %a; my $b = \\%a;
moritz_ are you talking about Perl 5 or Perl 6? 16:02
platypus_ how do I determine programtically that $b has a reference to a hash
perl 6
moritz_ in Perl 6, you'd just write
my $b = %a
and then
if $b ~~ Hash { ... }
16:03 zostay joined
platypus_ wonderful, thank you. Tried that a few weeks ago and did not work then. Will try again with latest. 16:03
moritz_ rakudo: my %a = a => 1, b => 2; my $b = %a; if $b ~~ Hash { say "yes, a hash" }
p6eval rakudo 85602a: OUTPUT«yes, a hash␤» 16:04
moritz_ seems to work :-)
16:05 plainhao joined 16:07 pyrimidine joined 16:09 Chillance joined
jnthn back from @stuff 16:15
moritz_ wb
jnthn masak: Hmm. Wonder if the C3 impl has issues. :S 16:16
16:16 hercynium joined
jnthn masak: Wouldn't be entirely surprising. I'll check. It may not be wrong. 16:16
You can't always build a C3 linearization.
16:20 risou joined, patrickas joined
patrickas good evening #perl6 16:20
diakopter 'morn 16:21
16:24 azert0x joined
patrickas rakudo: say (1...^*).batch(10).perl; 16:24
p6eval rakudo 85602a: OUTPUT«Can't take numeric value for object of type Whatever␤ in 'Any::Numeric' at line 1339:CORE.setting␤ in 'prefix:<^>' at line 6741:CORE.setting␤ in main program body at line 22:/tmp/ResChIiNlM␤»
colomon patrickas: your patch still isn't in there. I completely forgot about it. :( 16:25
patrickas colomon: it's ok no hurry :-)
I also tried to refactor the whole series like you told me but did not get very far
colomon would be nice to have it in by tomorrow. 16:26
patrickas The way you described it it seemed simple, the way it ended up with me, it turned out as complicated as the current impl! 16:28
do you have some time to take a look / discuss it a bit ? 16:29
colomon I guess I could spare a few minutes.
(from $work, I mean)
gfldex std: sub f($a,$b){say $a, $b}; my $g = -> |@a {f(@a)}; $g.(1,2);
p6eval std 32025: OUTPUT«ok 00:02 119m␤»
gfldex rakudo: sub f($a,$b){say $a, $b}; my $g = -> |@a {f(@a)}; $g.(1,2); 16:30
p6eval rakudo 85602a: OUTPUT«Nominal type check failed for parameter '@a'; expected Positional but got Capture instead␤ in <anon> at line 2:/tmp/yoB8GjlFoz␤ in main program body at line 22:/tmp/yoB8GjlFoz␤»
gfldex is std right in that case?
colomon gfldex: I think it's your code that's weird 16:31
gfldex very well possible :)
colomon gfldex: in a way std doesn't see.
I don't know if -> |@a makes sense or not -- but f(@a) shouldn't work if we have f($a, $b) 16:32
moritz_ f(|@a) should work if you have f($a, $b) 16:33
TiMBuS my $g = -> *@a {f(|@a)};
gfldex rakudo: sub f($a,$b){say $a, $b}; my $g = -> *@a {f(|@a)}; $g.(1,2);
p6eval rakudo 85602a: OUTPUT«12␤»
gfldex there we go :)
ingy morning 16:39
patrickas hello ingy
16:46 ruoso joined
colomon rakudo: say (1 ... -10).perl 16:47
p6eval rakudo 85602a: OUTPUT«(1, 0, -1, -2, -3, -4, -5, -6, -7, -8, -9, -10)␤»
16:47 isBEKaml joined
isBEKaml hi, folks! 16:48
colomon rakudo: say 'g', 'z' ... 'a' 16:50
p6eval rakudo 85602a: OUTPUT«(timeout)»
isBEKaml rakudo: say 'n' ... 'm' #ROT 13? 16:56
p6eval rakudo e0850e: OUTPUT«nm␤»
isBEKaml rakudo: say 'n' ... 'za'... 'm' #ROT 13?
p6eval rakudo e0850e: OUTPUT«No applicable candidates found to dispatch to for 'infix:<...>'. Available candidates are:␤:(@lhs, @rhs)␤:(@lhs, Any $rhs)␤:(Any $lhs, @rhs)␤:(Any $lhs, Any $rhs)␤␤ in main program body at line 22:/tmp/Z4dTJFRh00␤»
isBEKaml :)
rakudo: say 'n' ... 'z', 'a' ... 'm' #ROT 13?
p6eval rakudo e0850e: OUTPUT«No applicable candidates found to dispatch to for 'infix:<...>'. Available candidates are:␤:(@lhs, @rhs)␤:(@lhs, Any $rhs)␤:(Any $lhs, @rhs)␤:(Any $lhs, Any $rhs)␤␤ in main program body at line 22:/tmp/e9C24txaPw␤»
isBEKaml rakudo: say 'n' .. 'z', 'a' .. 'm' # this works locally, I thought ... was just desugared to .. ? 16:58
p6eval rakudo e0850e: OUTPUT«nopqrstuvwxyzabcdefghijklm␤» 16:59
isBEKaml hm, time to look up the difference in the spec..
rakudo: say 'n' .. 'za' .. m # is this right, takes forever on my poor machine. :| 17:02
p6eval rakudo e0850e: OUTPUT«Could not find sub &m␤ in main program body at line 22:/tmp/wa6KDrDp9b␤»
isBEKaml rakudo: say 'n' .. 'za' .. 'm' # is this right? takes forever on my poor machine. :|
p6eval rakudo e0850e: OUTPUT«too many positional arguments: 3 passed, 1 expected␤ in 'Range::new' at line 1␤ in 'infix:<..>' at line 4720:CORE.setting␤ in main program body at line 22:/tmp/G7Ew3bTPcm␤»
colomon isBEKaml: ... is not desugared to .., it's completely different code 17:03
and the problem you're seeing is that 'n' ... 'z', 'a' ... 'm' is a three-part series, which isn't supported yet 17:04
whereas n' .. 'z', 'a' .. 'm' is just two ranges separated by a comma
rakudo: say ('n' ... 'z'), ('a' ... 'm') 17:05
p6eval rakudo e0850e: OUTPUT«nopqrstuvwxyzabcdefghijklm␤»
moritz_ is that what you need for rot13?
isBEKaml I see. I was looking for more unix-y like tr "a-z" "n-za-m" :)
17:06 Italian_Plumber joined
colomon isBEKaml: 'n' ... 'z', 'a' ... 'm' is supposed to work, but afaik Rakudo's infrafstructure doesn't support it yet. 17:07
isBEKaml can you tell me about the last one? 'n' .. 'za' .. 'm' ? Does this also fall under the three part series?
17:07 sftp joined
colomon isBEKaml: errr, very no 17:07
did you mean 'n' ... 'za' ... 'm' 17:08
?
isBEKaml colomon: err, I really have to read about the difference between '..' and '...' to answer that one. :S
17:09 proller_ joined
colomon isBEKaml: 'n' .. 'za' .. 'm' is just a syntax error of some sort. Ranges always have two endpoints. 17:09
'n' ... 'za' ... 'm' is a hypothetically valid series, which does 'n' ... 'za' and 'za' ... 'm' and leaves out one of the 'za's. 17:10
rakudo: say 'n' ... 'za'
p6eval rakudo e0850e:
..OUTPUT«nopqrstuvwxyzaaabacadaeafagahaiajakalamanaoapaqarasatauavawaxayazbabbbcbdbebfbgbhbibjbkblbmbnbobpbqbrbsbtbubvbwbxbybzcacbcccdcecfcgchcicjckclcmcncocpcqcrcsctcucvcwcxcyczdadbdcdddedfdgdhdidjdkdldmdndodpdqdrdsdtdudvdwdxdydzeaebecedeeefegeheiejekelemeneoepeqereseteuevewexeyezfafbfcfdf…
colomon and then
rakudo: say 'za' ... 'm'
p6eval rakudo e0850e:
..OUTPUT«zayzyyyxywyvyuytysyryqypyoynymylykyjyiyhygyfyeydycybyaxzxyxxxwxvxuxtxsxrxqxpxoxnxmxlxkxjxixhxgxfxexdxcxbxawzwywxwwwvwuwtwswrwqwpwownwmwlwkwjwiwhwgwfwewdwcwbwavzvyvxvwvvvuvtvsvrvqvpvovnvmvlvkvjvivhvgvfvevdvcvbvauzuyuxuwuvuuutusuruqupuounumulukujuiuhugufueuducubuatztytxtwtvtutttstrtq…
colomon so definitely not what you want 17:11
17:11 imarcusthis joined
isBEKaml oh, I didn't expect this. Not definitely what I want. colomon++ 17:11
so, how would I do a "tr" like ROT13 in p6? 17:12
colomon looks for moritz_ ...
isBEKaml wait, moritz_ showed that already? 17:13
colomon no, I think he understand tr better than I do
moritz_ hm 17:14
rakudo: say 'hello'.trans('a..z' => 'n..za..m')
p6eval rakudo e0850e: OUTPUT«uryyb␤»
isBEKaml I could just think of doing it with a .subst, but got into a little confusion with .. and ... as you saw above. :)
moritz_ just use tr :-) 17:15
erm, trans
isBEKaml moritz_++
colomon rakudo: say "uryyb".trans('a..z' => 'n..za..m')
[1:14pm] p6eval: rakudo e0850e: OUTPUT«uryyb␤»
p6eval rakudo e0850e: OUTPUT«hello␤»
isBEKaml I forgot about the trans. :-) 17:16
moritz_ speaking of which... once you know how to parse two quoting constructs that share the same delimiter, it's trivial to implement the tr/// syntactic form
PerlJam moritz_: so ... are you saying you're going to implmement tr/// now? :-) 17:17
moritz_ PerlJam: you've missed a predicate there
PerlJam: did you just volunteer for the parsing part? :-) 17:18
isBEKaml moritz_: the predicate is already handled elsewhere? How did jnthn++ do [[ + ]] reduce ops? :-)
or [[[[ + ]]]] thingies? 17:19
moritz_ isBEKaml: that's not a quote
jnthn moritz_: Ain't s/// hint-y?
moritz_ jnthn: nope; parsing a regex doesn't swallow the delimiters; parsing a quote does 17:20
isBEKaml oh..
jnthn moritz_: oh...yes, tricky-ish. 17:21
17:24 Eevee joined, avuserow joined
isBEKaml moritz_: so we are essentially passing in a list of pairs to .trans, that would have to be chained to once the "predicate" issue is hammered out of the way? :-) 17:26
moritz_ isBEKaml: trans also understands two strings 17:27
and builds the pair list internally
isBEKaml rakudo: "hello".trans('e' => 'p', 'l' => 'b')
p6eval rakudo e0850e: ( no output )
isBEKaml rakudo: say "hello".trans('e' => 'p', 'l' => 'b')
p6eval rakudo e0850e: OUTPUT«hpbbo␤»
isBEKaml rakudo: say "hello".trans(<e p l b>) # Let's see... 17:28
p6eval rakudo e0850e: OUTPUT«e.perl is not a Pair␤ in <anon> at line 2223:CORE.setting␤ in 'Cool::trans' at line 1␤ in main program body at line 22:/tmp/UnjrlvbItG␤»
isBEKaml It seems to expect a list of pairs.
rakudo: say "hello".trans("bello", "gemmo") # Let's see... 17:29
p6eval rakudo e0850e: OUTPUT«bello.perl is not a Pair␤ in <anon> at line 2223:CORE.setting␤ in 'Cool::trans' at line 1␤ in main program body at line 22:/tmp/uhVsETRuU2␤»
17:30 molaf joined
moritz_ rakudo: say "hello".trans("bello" => "gemmo") 17:31
p6eval rakudo e0850e: OUTPUT«hemmo␤»
moritz_ ok, we have to construct *one* pair
isBEKaml yes, atleast one pair. 17:32
pragma_ Huh, so the . operator is no longer concatenation? 17:35
moritz_ no, . is method call
~ is concatenation
isBEKaml pragma_: the ~ is what we use for concatenation.
moritz_++ was faster. :)
parrot release today? 17:37
17:37 pyrimidine joined
moritz_ huh, I just managed to lose two commits. 17:37
masak nom &
jnthn So...masak eats commits? 17:39
moritz_ actually the misguided use of git am --abort ate it 17:41
isBEKaml moritz_ would actually participate in Porror events. :P 17:42
spoil the pun with horror or mix the two! ;)
isBEKaml should shut up and go read something... 17:44
17:45 avuserow joined 17:48 Su-Shee left 17:51 jferrero joined 17:55 pyrimidine joined
isBEKaml when is the rakudo release this month? Sometime this week? 17:57
jnthn Thursday for R* 17:58
crap
Thursday for Compiler
isBEKaml I just asked that my uploaded rakudo slackbuild script be pulled down from the pending queue in slackbuilds.org so a newer version will be delivered upon rakudo2010.08 release. 17:59
jnthn R* distro release comes after that one.
isBEKaml I was thinking of packaging R* for slackware, but isn't very viable and goes against slackware installation mechanisms. 18:00
So, I'm packaging rakudo and parrot separately. Parrot was approved and is now available on slackbuilds.org.
any chance that we can have a separate docs/libraries package apart from R* ? 18:01
18:02 mberends joined
jnthn mberends! \\o/ 18:04
mberends wow, jnthn++ has been 6modeling a lot!
PerlJam isBEKaml: since that's part of the point of R*, I don't see how.
isBEKaml PerlJam: well, that means I will just have to pull them out and host from a different location( I don't want to do that) 18:05
jnthn mberends: NQPSetting.pm lives...and compiles...and code is run with it as the outer scope. There's a --setting mode for compiling it.
mberends: Added in .Str to NQPNum and NQPInt so we can actually, like, say/print them now. :-)
mberends: Added a make test target and pulled in the 2 nqp tests we pass. Think I've busted it for Mono though. Sorry. :-( 18:06
(Just the building rather than the code.)
mberends jnthn: aww
PerlJam isBEKaml: Hmm. So you want rakudo-2010.08-compiler, rakudo-2010.08-libs, and rakudo-2010.08-docs (or something similar) ? 18:07
jnthn mberends: Yeah, but I really really wanted the setting 'cus it was blocking everything else. :-)
PerlJam er, s/rakudo/rakudo-star/
mberends jnthn: but srsly, it looks great :)
jnthn mberends: Plan: subs, few operators, .Bool, :pasttype if/unless/while. 18:08
isBEKaml PerlJam: err, R* source would be based on the previous release. I'm fine with the Rakudo compiler that would be built with the slackbuild script. I just want the libs/docs separate.
PerlJam: libs --> modules. 18:09
mberends jnthn: very nice
jnthn mberends: Yeah, it'll be nice to be turing complete. ;-) 18:10
I mean, after that, what more's needed. ;-)
mberends er.
dalek kudo: 037f685 | tadzik++ | /:
Optimize Range.pick for integers and non-replacing pick

Includes an off-by-one fix from moritz_
Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
jnthn mberends: :P
mberends: I'm in denial that at some point PAST::Regex nodes will also need compiling. :P
mberends jnthn: keep your head in the sand for a while, it's okay ;) 18:11
jnthn There's plenty to do before then. Like...make ClassHOW work. :-) 18:12
OK, going to the nomshop...all I have here is pasta and picked gerhkin and I don't think I can make a great meal out of those... 18:13
isBEKaml jnthn: You're porting Rakudo to some other platform? :)
jnthn: ok, happy nommin'! 18:14
jnthn isBEKaml: NQP for now. But simultaneously working out the new meta-model design. I'll soon start getting that in place in Parrot too. :-)
bbiab
18:18 colomon joined
mberends \\o colomon 18:19
colomon o/
18:22 lerut joined
moritz_ hm 18:23
it's Tuesday, right?
colomon oh 18:24
moritz_ so, is there a #phasers today?
colomon !
lerut ye
moritz_ in 35min, right? 18:25
moritz_ can never remember the time
colomon thinks moritz_ is right 18:28
18:28 azert0x joined
isBEKaml ah, 6model on github shows it as a C# project, so I assume he's porting NQP to .NET CLR ? that's awesome! 18:29
18:29 tadzik joined
moritz_ right 18:29
tadzik moritz_++ # spotting stupid bug in my patch
moritz_ see also perlgeek.de/blog-en/perl-6/notes-fr...athon.html and www.perlmonks.org/?node_id=855407 for some discussions
isBEKaml it'd be awesome if we can get an implementation running on jvm too! :) 18:30
moritz_ tadzik: actually it was the test suite that caught it
tadzik moritz_: how is random number generation tested?
moritz_ isBEKaml: I guess once the first two are done, the third will be easy :-)
isBEKaml moritz_: I hope so, the jvm's a different beast. 18:31
moritz_ tadzik: this one was caught by t/spec/S03-operators/series-arity0.t
my @rolls = ({ (1..2).pick } ... 2).munch(100);
tadzik oh
moritz_ ok +@rolls > 0, 'the series had at least one element...';
ok +@rolls < 100, '... and the series terminated';
that second test failed, because with the offby1 error, it woul produce 1, 1, 1, 1 ... 18:32
tadzik huh
spectests++
moritz_ colomon++ # writing those tests
tadzik oh, btw, my second patch is alredy deprecated (pmichaud++ did the same during his range optimizations) 18:33
you may want to remove it
oh, alredy done 18:36
isBEKaml moritz_: I see. the perlmonks' post shows ppl wary of porting/implementing p6 on the jvm due to the recent Google/Oracle lawsuit. :| 18:40
tadzik :D 18:41
isBEKaml esp the last comment by chromatic++
18:41 pragma_ left
allbery_b wonders if Oracle handed the future to the CLR with that self-kneecapping 18:44
isBEKaml MS looks like the winner here. the mobile market is where it's still weak. With this lawsuit, all it has to do to accelerate mobile sales with more products. 18:46
jnthn #phasers in 15?
isBEKaml </offtopic>
jnthn isBEKaml: The JVM is just like a crappy version of the CLR. 18:50
isBEKaml: So not _that_ different.
isBEKaml jnthn: I can't say that. the jvm guys took a lot of pain to ensure backward compatibility. Sure, some things are pretty screwed up, like generics(again backward compatibility was taken into the picture) 18:51
18:51 Lorn joined
isBEKaml jnthn: what really sucks is, they don't look to adding new features into the system, instead are drawn into a long and protracted process called JSR. :( 18:52
I don't know about the CLR (never programmed in it) 18:53
18:53 azert0x joined 18:54 azert0x joined
isBEKaml many have given up proposing new features. Even closures were ruled out of future _standard_ editions. OpenJDK is still looking to implement them. 18:54
18:55 ash_ joined
isBEKaml I don't know how far they are into it, project-lambda iirc was heavily into it. 18:55
18:55 hercynium joined 18:58 javs joined
isBEKaml alright guys, later tomorrow. 19:01
isBEKaml goes to zzz....
jnthn pmichaud: #phasers if you're about :-) 19:04
sorear niecza: class A { method foo { say "OH HAI" } }; class B is A {}; class C is A is B {}; say "alive"; # My C3 implementation has not been tested. At all. 19:05
phenny sorear: 14:22Z <azawawi> tell sorear I am getting this error when doing a 'make dist' after 'make clean all' in src/perl6. "make: *** No rule to make target `stage2/STD_P5.pmc', needed by `dist'. Stop."
p6eval niecza 91d5840: OUTPUT«Unhandled exception: System.Exception: C3 MRO inconsistency detected␤ at Niecza.DynMetaObject.BuildC3MRO () [0x00000] in <filename unknown>:0 ␤ at SAFE.CreateProtoobject_5C (Niecza.Frame th) [0x00000] in <filename unknown>:0 ␤ at Niecza.Frame.Continue () [0x00000] in
..<filename u…
19:06 cono joined
jnthn sorear: Heh. They're either both wrong or both right. :-) 19:13
19:15 tylercurtis joined 19:29 dual joined
patrickas rakudo: sub foo {my @a = (1,2,3,4,5);my $val ;gather {while @a {$val = @a.shift();take $val;}}};say ~( foo() ) ; say foo(); 19:29
p6eval rakudo 037f68: OUTPUT«5 5 5 5 5␤12345␤»
patrickas is that ^^ a known bug ?? Is it a bug at all ? 19:30
TimToady not a bug, really 19:31
put the my inside the while loop
you've just taken five refs to the same var 19:32
though, perhaps a bug, nonetheless
since take is supposed to de-containerize like return
sorear phenny: tell masak yes, protopad = static lexpad. static lexpad is probably more correct now since I've eliminated all prototype aspects of the static pad.
phenny sorear: I'll pass that on when masak is around.
patrickas TimToady thx, I already worked around it in the code ... but I was wondering if I should rakudobug it or not? 19:33
moritz_ I'm pretty sure we had a bug report once, but I think I closed it because all tests passed in the end 19:34
sorear phenny: tell azawawi make dist should probably be retired
phenny sorear: I'll pass that on when azawawi is around.
moritz_ speaking of make, 'make snap' would be nice to have back, because p6eval uses it
TimToady I already fixed snap 19:35
testing a fix for dist 19:36
moritz_ std: 1
p6eval std 32025: OUTPUT«ok 00:01 112m␤»
moritz_ has kept up, so the fixed worked
TimToady++
pugssvn r32026 | lwall++ | [STDeco] fix make dist 19:37
moritz_ patrickas: all gather/take bugs in t/spec/S04-statements/gather.t pass, modulo those that rely on lazy list assignment
19:37 Mowah joined
moritz_ I'll switch them binding instead 19:37
sorear good * #perl6
pugssvn r32027 | moritz++ | [t/spec] switch laziness tests to binding, since we know better that it does not evaluate the items eagerly 19:38
patrickas moritz - Comments added\t: Miraculously the tests now pass, so I'm closing this ticket. Feel free to open again if it resurfaces again.
:-) 19:39
19:45 nimiezko joined
mathw hello 19:47
19:47 cj_ joined
TimToady howdy doo 19:48
moritz_ parrot release is being furiously worked on, it seems 19:49
mathw good-oh
jnthn o/ mathw 19:50
mathw o/ jnthn
I'll be needing that Parrot release :) 19:51
TimToady what are they furious about this time? :)
jnthn Gahhh...do I blog a "no no no no" response to chromatic's comments on PerlMonks or bother to sign up for an account...or just get on with doing something useful. :/ 19:58
Tene jnthn: I'm interested in seeing your comments and response. 19:59
dalek ok: 1ec2cc5 | ++ | /:
fixed a non-working example: $number vs $count

Signed-off-by: Moritz Lenz <moritz@faui2k3.org>		 20:00
sorear jnthn: Rakudo and niecza's behavior is absolutely right
jnthn: link?
jnthn sorear: I wondered if that might be the case.
sorear: to...the ticket for the C3 thing?
sorear "chromatic's comments on PerlMonks" 20:01
jnthn oh
www.perlmonks.org/?node_id=855567
sorear class C is Grandparent is Parent means that C wants the grandparent's methods to take precedence
jnthn sorear: Yes, I looked at that and thought "er...wait" :-)
sorear which is inconsistant with the ordering created by class Parent is Grandparent
jnthn I'm relieved that you get the same result. 20:02
Aye. That ticket can be rejected.
sorear I had to add more debug code to get said result though.
jnthn Thanks for doing so. :-) 20:03
Tene jnthn: If you disagree with him, I'm very interested in a response from you to that comment.
jnthn Tene: I don't disagree with The Whole Thing; it's the section that starts "Any runtime for Perl 6 is going to end up looking a lot like Parrot." that bothers me. 20:04
Tene jnthn: That's the part I'm curious about a response to.
TimToady the problem is he said "can support", which I agree with, except that parrot doesn't do that--it tries to supply the implementations instead, and by and large they're unusable 20:05
jnthn TimToady: My feeling is that the implication seems to be that the VM should have those fetures directly.
mathw I thought it interesting that he thinks the runtime has to provide all that
20:06 fda314925 joined
jnthn TimToady: I'd argue that it simply needs to allow for an efficient implementation of them. 20:06
mathw If the runtime did all tha titself, it would only be able to run Perl 6
jnthn Maybe I should wait to reply until I have the code to back up my response though. :-)
dalek ecza: e4ff073 | sorear++ | /:
Add NIECZA_C3_TRACE debug mode
sorear jnthn: I would argue that statement is vacuously true. In about five years Parrot is going to look very, very much like the JVM or CLR
mathw jnthn: one also wonders if it's worth arguing with him 20:07
when you could be doing awesome stuff with the metamodel
jnthn mathw: Right, I maybe should just write that as my reply. ;-)
sorear: lol :-)
mathw I get the impression that chromatic is very difficult to argue with due to a high stubbornness quotient
PerlJam jnthn: perhaps the Parrot he's thinking of is the hypothetical future Parrot that does all of that stuff? 20:08
oh ... sorear already said it
jnthn PerlJam: Perhaps so.
PerlJam mathw: arguments are easy. resolution is hard :) 20:10
mathw yes 20:11
20:13 smash_ joined
smash_ hello everyone 20:13
tadzik hi smash_
mathw o/ smash_ 20:14
20:20 tylercurtis joined 20:22 thebird joined 20:27 icarroll joined
icarroll perl6: say +(1,2,3,4,5); 20:28
p6eval pugs, rakudo 037f68: OUTPUT«5␤»
icarroll rakudo: say [+] (1,2,3,4,5);
p6eval rakudo 037f68: OUTPUT«15␤»
tadzik rakudo: say +('any', 'elements', 'but', 6, 'of', 'them') 20:29
icarroll rakudo: say (1,2,3,4,5);
p6eval rakudo 037f68: OUTPUT«12345␤»
rakudo 037f68: OUTPUT«6␤»
icarroll rakudo: say ~(1,2,3,4,5); 20:30
p6eval rakudo 037f68: OUTPUT«1 2 3 4 5␤»
20:50 ilogger2 joined 20:53 Cyrus joined 20:54 Guest23195 left
sorear rakudo: my @x; say @x[*-1] 21:01
p6eval rakudo 037f68: ( no output )
sorear rakudo: my @x; sub foo($k) { say $k }; foo @x[*-1]
p6eval rakudo 037f68: ( no output )
sorear in Perl 5, the latter version dies, while the former DTRTs 21:02
:/
21:15 whiteknight joined
mj41 Parrot vs. JVM by allison video.google.de/videoplay?docid=290...749292774# 21:15
21:17 fod joined
sorear whiteknight: I see I wasn't *entirely* crazy when I went all Chicken Little on continuation/inferior runloop interactions those months ago... 21:18
21:19 tylercurtis joined
whiteknight sorear: it's always been a problem, and likely will be for a long time coming 21:20
this certainly isn't my first run-in with it
tadzik mj41: are the slides somewhere around? 21:23
mj41 tadzik: wiki.jvmlangsummit.com/pdf/38_Randal_parrot.pdf 21:24
tadzik: also try to search perl6.cz/wiki/Perl_6_and_Parrot_lin...ot.2C_Pugs 21:25
tadzik mj41: thanks 21:26
21:29 drbean joined
pmichaud good afternoon, #perl6 21:30
diakopter wth is his obsession with [multiple] trampolines?
I know that mono uses at least two 21:31
pmichaud sorry I missed #phasers -- was busy with $otherstuff
sorear Hello pmichaud
diakopter: who? 21:32
diakopter "chromatic's comments on PerlMonks" you asked for
sorear ah 21:33
diakopter "Any runtime for Perl 6 is going to end up looking a lot like Parrot." -- his entire posting reads a lot better if this statement is amended to "Any runtime for Perl 6 is going to end up looking a lot like an attempt at a Perl 6 implementation."
jnthn pmichaud: No worries. :-)
pmichaud I guess I should comment on the perlmonks thread. 21:36
diakopter by "support Perl 6" it sounds like he means "support all of Perl 6's control flow and memory management structures natively", which shows merely that he wants certain parts of the implementation at the same level as the GC/JIT. 21:37
21:39 chromatic joined, masak joined
masak ahoy! 21:39
phenny masak: 19:32Z <sorear> tell masak yes, protopad = static lexpad. static lexpad is probably more correct now since I've eliminated all prototype aspects of the static pad.
jnthn yayitsmasak! 21:40
masak I missed tonight's #phasers. ごめん。
chromatic Okay, anyone who wants to psychoanalyze me can do it while I'm here.
pmichaud masak: I missed it also. :-)
masak I will make up for it in a completely non-satisfactory way by reading its logs.
jnthn masak: Not loads happened. You did miss your chance to say "omg finished my gsoc proj!" :-)
masak pmichaud: yes, but your missing it was probably honourable, whereas mine was not.
jnthn: perhaps I get to say that in all other possible circumstances instead. :P 21:41
21:41 PZt joined
jnthn masak: Do we want to know what dishonorable thing you were up to? :-) 21:41
masak jnthn: I was indulging in an impromptu dinner. 21:42
I... got a bit carried away...
jnthn Inpromptu dinner causes inpromptness.
;-)
diakopter chromatic: it seems I could do it while you weren't here, too 21:44
masak chromatic: you should be here more often. 21:45
chromatic My preference is while I'm here.
[particle] how does that make you feel? 21:46
masak [particle]++ # the only one who gets it 21:47
TimToady I prefer to psychoanalyze parrots. 21:49
[particle] tell me more about parrots.
chromatic As long as those psychoanalyzed parrots get bugs filed on them, great!
masak chromatic: according to @chromatic_x on Twitter, you're a grump today. 21:50
chromatic Well sure, but I'm happy to explain what I mean by "writing trampolines for the rest of your life". 21:51
sorear What definition of trampoline are you using? 21:54
chromatic The rough "My platform's native calling conventions don't support all of the operations I need to do, so I need to do something clever in them so I don't recurse forever and still support the non-linear control flow I need." 21:55
diakopter chromatic: I agree with your point (that a Perl 6 runtime will look a lot like Parrot). But I claim it will be built on [not part of] something that has a very robust (thousands of productive hours put into it) GC and a very robust JIT. I believe that solely because of the resources [un]available to parrot. 21:56
but of course I'm not *complaining* about that lack of resources. ;) 21:57
chromatic You pick your poison though.
Build on an existing platform which provides a GC and a JIT, and you have to build the rest of your Parrot workalike.
You may or may not be able to tell that GC and that JIT how Perl 6 works. 21:58
You may or may not be able to ask for platform changes to smooth out any impedence mismatches between it and Parrot.
diakopter yeah. that's the poison.
pmichaud rakudo and nqp's perspective is that we're hedging our bets on both solutions, fwiw. 21:59
s/solutions/paths/
sorear I fail to see the distinction here
PaFo has ... exactly how much ... chance of getting a change approved to ISO C or the Pentium ISA?
chromatic As much as anyone. 22:00
masak sorear: why would it need that?
chromatic PaFo also has the same chance of getting a change approved to the Mars mission.
TimToady you're planning to host parrot using the Mars mission? Cool!!! 22:01
pmichaud lol 22:02
sorear masak: chromatic appears to be arguing against rakudo -> (parrotoid) -> CLR on the basis having less control than rakudo -> (parrotoid) -> C89
masak sorear: ah.
chromatic I'm not arguing *against* anything.
diakopter chromatic: I'm quite certain that a parrotoid -> CLR will be able "... tell that GC and that JIT how Perl 6 works." CLR has WeakReferences and quite a lot of control over the GC, actually, and JIT control is "solved" in my C# sprixel runtime, from which niecza spawned, sort of. 22:05
and that's ignoring the strong possibility of distributing a custom mono 22:06
chromatic Are you able to have precise GC?
sorear (I should point out that I'm only avoidng Parrot for short-term performance reasons, since niecza is really just intended as a better viv. Once lorito lands there will almost certianly be a port to Parrot) 22:07
pmichaud fwiw, I'm not sure what this discussion is about.
(not that I need to, but I have trouble seeing a coherent thread)
masak chromatic: while on the topic of GC, I've never heard anyone explain how the DESTROY submethod would work in Perl 6 on top of Parrot. maybe you know?
diakopter pmichaud: I think it was about www.perlmonks.org/?node_id=855567
pmichaud diakopter: sure, I saw that thread.
diakopter that's what I think it was about 22:08
chromatic masak, are you asking about timely destruction?
pmichaud diakopter: but perlmonks seems to be more along the lines of "Rakudo should focus on finishing what it has instead of looking at other backends."
and I disagree.
sorear People have an expectation that { my $x = open "foo" } should close foo immediately
I think this is a P5ism and should die
diakopter pmichaud: I meant that url exactly.
that post.
pmichaud sorear: it's already been declared dead, at least on #perl6 22:09
masak chromatic: no, I'm asking if there's some decision, anywhere, about how the plumbing between the GC and the DESTROY submethod will actually work.
chromatic I still don't understand that question then, masak.
sorear closing files should be done with an explicit framing construct, like C# and Java have now and Scheme has had since forever
jnthn chromatic: I guess it partly boils down to, "is the destroy v-table method in object overridable"?
Or more ot the point
What would be the consequences of doing so? 22:10
masak chromatic: maybe I'm phrasing it badly. all I'm seeing in the spec is a hand-wavey "DESTROY will get called on destruction". that's not enough for an implementation.
jnthn I don't think it's an especially big deal though.
chromatic I've overridden it before. As far as I know, it's still overridable.
jnthn OK
We may be able to hang it off that then.
masak actually, it's probably DESTROYALL that would be called by the GC.
s/probably // 22:11
tylercurtis jnthn: trac.parrot.org/parrot/browser/trun...t.pmc#L289
chromatic Given automatic allocation and deallocation of PMC attributes, you're not leaking anything then either.
22:11 pmichaud_ joined
diakopter chromatic: mono's is not precise, and neither is .Net's 22:11
pmichaud_ *sigh* feather connection fail
jnthn tylercurtis: hmm
pmichaud_ diakopter: I agree with chromatic's bottom point on that post (more)
"I suppose the question is whether another runtime can create enough trampolines to prop up the as-yet-unported pudding layer sooner than we can fix those bugs in Parrot." 22:12
Rakudo and NQP are taking the approach that we're willing to explore both paths.
chromatic I suppose my point on the PerlMonks thread, phrased badly and nearly implicit, is that "Supporting additional backends from PCT doesn't necessarily take away from the goal of a performant, spec-compliant implementation of Perl 6 with Rakudo but it's definitely not a quick way to get a performant, spec-compliant Rakudo."
I think the desire to support multiple backends was one of the two things that killed Pugs.
pmichaud_ chromatic: I agree, but I think Pugs had different motivations for multiple backends 22:13
chromatic Yes and no.
diakopter heh
chromatic One of those desires was -Ofun for sure, but Pugs had unusable performance.
TimToady I don't think multiple backends killed pugs *at all*
masak oh noes, hugme quit?! :(
pmichaud_ I don't think unusable performance was what killed bugs
*pugs
I think it was an unmaintainable core codebase
chromatic I stopped using Pugs when the spec tests took 8 hours to run.
I don't mind cleaning up unmaintainable code. 22:14
See also IMCC.
TimToady patches welcome
sorear I started using Rakudo when 'make' took 12 hours.
masak the decrease in bus number killed Pugs.
chromatic I seem to recall fixing that, too.
pmichaud_ chromatic: the point is, that nobody has stepped up to maintain pugs
sorear yes. chromatic++
pmichaud_ 'make' has never taken 12 hours on my system, fwiw. it's never taken more than 1.
chromatic It's too simplistic to say "No one could maintain Pugs." 22:15
diakopter chromatic: oops, I'm wrong; the just-released major release of Mono (2.8) does have a precise one.
chromatic No one could maintain Pugs for at least one reason.
pmichaud_ I didn't say "no one could maintain pugs". I'm saying "no one has"
masak chromatic: "No-one has wanted to maintain Pugs."
pmichaud_ and the reason it's not maintained has little to do with multiple-backend-ness
chromatic Fair point, but I'm not sure it changes my argument.
masak or what pmichaud_ said.
chromatic diakopter, are you able to give the GC hints about object layouts for precision?
No one has maintained Pugs for at least one reason.
diakopter chromatic: sigh; another correction; 2.8 isn't released yet 22:16
pmichaud_ one thing we do know that is different between pugs and rakudo is that rakudo's parser is accessible to more people
chromatic That's a huge advantage for Rakudo, yes.
pmichaud_ and I've maintained that parsing is at the core of making a successful perl 6 implementation.
chromatic Being able to write in NQP and Perl 6 is another advantage.
sorear chromatic: the CLR knows object layouts (it's a lot like the JVM in how it handles this)
pmichaud_ that's where pugs ran into difficulty -- it was hard to grok the parser and translation unless you were a strong lambdacamel 22:17
TimToady the chief problem with pugs is that the code got too smart for anyone who isn't brilliant to understand
much of the time in #perl6 back then was explaining what snippets of Haskell are really doing
masak or it was too smart from the beginning.
chromatic I recall that, as you recall.
Pugs never had a strong priority of improving its bus number. 22:18
TimToady it did, but Haskell didn't. :)
pmichaud_ returning to my earlier comment -- rakudo and nqp are basically entering a phase where we're going to see if parrot improves faster than our ability to target another vm 22:19
sorear (am I the only one who thinks Juerd ought not to IRC from feather?)
masak jnthn++ # "The hottest footwear!"
jnthn: that's your best pun in a long time!
chromatic Maybe I'm wrong, but I've always thought that the effort spent on supporting multiple backends for Pugs took away from making Pugs more maintainable.
pmichaud_ and it's not mutually exclusive -- we fully expect that what jnthn learns from implementing a new object metamodel in nqp will get ported back into Parrot 22:20
jnthn masak: Wow, one you like. :-)
masak jnthn: yeah, almost all the other ones were awful :P
jnthn chromatic: The way this is looking at the moment is that we'll end up with _more_ written in NQP.
chromatic: Which means more hackable.
(And more portable.)
chromatic Unless it's a pudding layer.
jnthn And also fewer primitives that need to be made fast. 22:21
TimToady Perl 6 is pudding. Yum!
diakopter mmm butterfly pudding
pmichaud_ chromatic: (I'm speaking for jnthn here a bit) I think that neither jnthn nor I have a lot of confidence in our ability to effect changes in Parrot except by first prototyping them outside of Parrot.
(jnthn please clarify if I'm mis-stating your feelings on this) 22:22
jnthn It's not a mis-statement, just not a full one. I also believe it's _easier_ to prototype at least the current set of stuff I'm doing outside of Parrot. 22:23
chromatic Use cases and design constraints definitely help me make and suggest changes to Parrot.
pmichaud_ chromatic: agreed, and so we're looking to provide them.
jnthn But yes, it's true. In the prototype I'm working on, I could just throw in a "static lexpad" concept and hack up an auto-close that uses it and move on. It took me 10 minutes. Now I get to see how it works and how useful it is. 22:24
chromatic I support that fully, but in my mind that's orthogonal to supporting multiple backends.
TimToady one way to view these parrot attempts at high-level features such as multimethods is that they are useful prototypes that should expect to be thrown away
chromatic That's how I view them.
jnthn TimToady: Right. They have been _enormously_ useful in getting us started. 22:25
pmichaud_ ...except that Parrot has had trouble with the "expect to be thrown away" part (e.g., deprecation policy)
TimToady that's getting better, I think
pmichaud_ sure, I agree
chromatic I like to think our current deprecation policy has improved a lot.
22:26 fod joined
pmichaud_ but we still have plenty of cases where core issues in Parrot haven't been addressed. NQP can (1) block, (2) try to improve parrot, and (3) explore other ways of solving the problem. 22:26
multiple backends falls into 3
chromatic My preference is 2, 1, 3. 22:27
pmichaud_ well, that makes sense. I've had little success with 2.
TimToady 3 also feeds back into knowing how better to express what we want from 2
chromatic We'll see.
TimToady We've already seen. :) 22:28
sorear Do you have a stand on non-Rakudo implementations not using Parrot? 22:29
chromatic Does it matter? I'm not in charge of how other people spend their time. 22:30
pmichaud_ beyond the points illustrated above, the other reason for targeting other backends is that, as was pointed out to me last year, there's one major scripting language that doesn't run on .Net
chromatic Ruby?
pmichaud_ ;-)
okay, maybe two. but the point is, I'd like for Rakudo to mean more than "Perl 6 on Parrot" 22:31
I'd like it to be robust enough to be shared on multiple platforms.
sorear FWIW Niecza is stealing bits and pieces of Rakudo all over the place
both design and actual code
diakopter Microsoft contracted ActiveState to build ActivePerl.Net, and they did for a while in 1999-2000, but it was abandoned.
pmichaud_ Allison also made a similar comment at yapc::eu -- that she felt that it was important that we target multiple backends so that we can show other languages a path by which they can ultimately target Parrot. 22:32
perigrin ActivePerl.NET wasn't Perl on the CLR
diakopter sorry, there was one that was Perl on the CLR
perigrin but perl embedded into the CLR with a bridge
TimToady yes, just a bridge
diakopter I found the one that was a Perl implementation, not the bridge
sorear Is "Perl on the CLR" allowed to use unsafe blocks 22:33
diakopter I say yes.
TimToady as long as they're declared unsafe :)
sorear rewriting the p5vm without pointer arithmetic sounds like "fun"
chromatic I suppose it's two things. 22:34
sorear and by fun I mean 20+ man-years
TimToady oh wait, you weren't asking my permission...
chromatic 1) I have a concern that supporting multiple backends will provide some distraction from making a spec-complete Rakudo on any backend. I know developers aren't completely fungible, but there is a pudding layer.
2) I want that pudding layer for Rakudo on Parrot to move as much into Parrot as possible.
masak Yapsi is also heavily inspired by Rakudo.
pmichaud_ We want #2 also. 22:35
TimToady I want the pudding layer for Rakudo to move as much as possible into Perl 6. The only way we can agree is to reimplement large chunks of Parrot in Perl 6.
which is a disavowed goal of Parrot. :) 22:36
jnthn The pudding layer should be lagom. :-)
masak :)
pmichaud_ and yes... Rakudo has experienced the pushback that TimToady++ mentions quite heavily.
It's much less so in recent months... but that may also be because we've stopped pushin. 22:37
*pushing.
chromatic I don't understand any of that. 22:38
TimToady you really shouldn't give us straight lines like that...
diakopter as in... so obtuse... 22:39
diakopter just startled all my cow-orkers with a guffaw 22:40
chromatic Look, I'm trying to communicate something here I find important.
pmichaud_ I recognize that. 22:41
I'm not sure what part isn't understood.
chromatic What is that pushback and what does it mean?
I think also "Why is there pushback?" but that question may depend on my previous one.
masak wants to go to bed but finds the discussion fascinating 22:42
pmichaud_ when we identify things that Perl 6 needs from Parrot, we have historically gotten "Perl shouldn't be dictating what Parrot provides"
or, even if we identify something really important, it takes months or years for progress to be made on it
chromatic I can think of several examples.
pmichaud_ I think you mentioned PCC earlier -- that's probably a very good example, and spot-on for this discussion. 22:43
chromatic I have spent a lot of effort to improve that in 2010.
pmichaud_ the PCC that parrot put together wasn't sufficient for Rakudo's needs, and that was explicitly identified at the time it was being done 22:44
chromatic If I have to spend more effort to do so, I will.
pmichaud_ i.e., it was recognized at the time it was being done that we'd ultimately end up writing our own dispatcher
jnthn (binder in this case, I think) 22:45
pmichaud_ right, binder
thanks.
jnthn (though we've needed our own dispatcher too)
22:46 awwaiid joined
pmichaud_ By no means do I wish to discount or downplay the improvements that Parrot has made over the past year. They've been terrific. 22:46
22:46 pyrimidine left
jnthn I agree. Parrot _has_ improved and it has helped. 22:46
chromatic That's deliberate. 22:47
pmichaud_ and we recognize that also. If we're not saying it enough, I'll say it more frequently and publicly. :)
but there are also some areas where the pace of change feels.... glacial.
chromatic Then we will prioritize them. 22:48
pmichaud_ we've prioritized them a bit also
thus, the #1 item I identified at yapc::na we're already working on -- object metamodel improvements
it is fully expected that we'll do a new metamodel in Parrot. 22:49
chromatic Sure, and I understand that sometimes Rakudo needs things before Parrot can provide them appropriately.
It has to go both ways, though.
pmichaud_ and we fully expect that someday Parrot will completely switch over to our new model.
jnthn Do we? :-)
pmichaud_ jnthn: I do.
chromatic I do.
jnthn I don't quite have that much hubris. ;-)
Oh, OK
:-)
\\o/ 22:50
jnthn polishes it extra shinily
pmichaud_ but at the same time we may be able to make some progress on a multiple-backend strategy, so we're doing that too.
chromatic I expect to have my own input into it with regard to what else Parrot needs, but yes.
pmichaud_ the other items identified at yapc::na.... I'm not so certain how they'll get handled. 22:52
jnthn chromatic: That's fine, so long as we end up with a superset rather than disjoint sets. :-) Given I'm aiming very a very small "core" and then NQP gets everything built atop of that, a superset could still be pretty small, though.
s:1st/very/for/
pmichaud_ where did the yapc::na list end up, anyway? I thought it was on the parrot wiki but I don't see it now. 22:53
chromatic Someone took a picture of it.
pmichaud_ I thought it was also transcribed somewhere.
pmichaud_ looks.
chromatic I think that small core, fat NQP works against Parrot's interests in some ways. 22:54
pmichaud_ in some sense "small core" is really "Lorito"
chromatic If we implement most of the rest of Parrot in terms of NQP perhaps. 22:55
TimToady or QP
pmichaud_ assuming one of parrot's goals continues to be multiple languages running on top of it, what do we expect those languages to be written in? 22:57
(honest question, not rhetorical)
TimToady whatever the implementors choose to use 22:58
chromatic NQP seems the most likely candidate.
TimToady in the short term
chromatic Right, in the short term.
pmichaud_ I agree that may be only a short-term answer.... but I'm fairly sure they won't be doing it in PIR or the standard opcode set.
so Parrot has to provide something a bit higher-level than what it has now, if NQP is excluded. 22:59
either way, I think we end up with small core, fatness in an intermediate layer
chromatic I see no technical reason to exclude NQP.
pmichaud_ right. I'm just saying that "fat NQP works against Parrot's interests" would seem to apply to almost any other pudding layer 23:00
so then it's a question of "what are Parrot's interests...?"
chromatic I interpreted it as "Pudding written in NQP" not as "Pudding available as part of NQP".
tylercurtis Why not both?
chromatic The former doesn't necessarily imply the latter, but the latter could imply the former. 23:01
pmichaud_ even as "Pudding written in NQP", that sounds a bit like Lorito. Small core, higher-level stuff written in a higher-level abstraction.
perhaps the wrong abstraction, but...
chromatic And I'm fine with that.
I believe it's in Parrot's interests to take many of the Rakudo workarounds, polish them, generalize them, perhaps make them extensible for some Rakudo-specific customizations, but ultimately adopt and absorb them. 23:02
pmichaud_ I agree. 23:03
chromatic Parrot can provide most of the pudding. You can put chocolate chips and marshmallows in it.
TimToady that strikes me as premature optimization, usually
chromatic What does, TimToady?
pmichaud_ I'd really like for Parrot to provide more of the pudding. But so far things haven't moved in that direction very quickly. 23:04
TimToady you want most of what you do to be in high level language, and then take bits into core
not assume it's almost all going into core
fsdo core
tylercurtis TimToady: I think a large part of the purpose of Lorito is so that much of Parrot's "core" can be written in high level languages.
chromatic I'm talking of things like dispatch and binding, not necessarily the setting. 23:05
TimToady sure
pmichaud_ we're talking of dispatch and binding in NQP also
iiuc what jnthn++ is working on
chromatic My *preference* for supporting multiple backends is to port Lorito's M0, not NQP. 23:06
pmichaud_ I don't see a problem with that (more)
TimToady my preference is that they be the same :)
pmichaud_ NQP would have no issue with targeting a Lorito M0 that can then go to multiple backends 23:07
chromatic Which would you like to be the same, TimToady?
pmichaud_ but I think that we'd need some exploration about how to get our higher-level concepts onto those other backends, so that we know what M0 would need to look like
TimToady Lorito's and NQP's MO
jnthn chromatic: Thus why NQP's class meta-object will be written in NQP.
pmichaud_ ...and that's exactly the avenue that jnthn++ is exploring.
jnthn chromatic: And thus I won't have to port it. :-)
Sounds like if we can agree on what comes beneath that, we have a chance of converging. :-) 23:08
pmichaud_ the url I have for the lorito bof notes is thenceforward.net/parrot/yapc_bof_20100621.txt but it seems to be gone/missing now.
tylercurtis webcache.googleusercontent.com/sear...&gl=us 23:10
chromatic Instead of emitting NQP code for another backend, you're okay with emitting Lorito-compatible code?
pmichaud_ i'm not sure about "emitting NQP code" -- we don't do that now. afaik.
right now we have an emitter for PIR
jnthn is working on a .net emitter
I don't see any reason why we'd have difficulty with a Lorito emitter 23:11
jnthn chromatic: Oh, I was talking about the object-y stuff, not the code generation.
But the approach is the take PAST and then emit different things from that.
pmichaud_ ....and write the emitters in NQP, ultimately.
in that sense, it's similar to what PIRATE is doing.
jnthn pmichaud_: Already am. 23:12
pmichaud_ (iiuc what PIRATE is doing)
chromatic Yes, that's the intent of PIRATE
jnthn pmichaud_: github.com/jnthn/6model/blob/master...ompiler.pm
pmichaud_ if Lorito's M0 ends up handling the multiple backend aspects for us, we'd happily target it. 23:13
23:13 jhuni joined
pmichaud_ but something is going to need to describe the metamodel, and it makes sense for us to write that description in p6 or nqp 23:13
chromatic Right.
pmichaud_ that's what we're doing.
well, jnthn++ thus far.
chromatic Yes, portability to other backends is a possibility of Lorito. I'd like to see it run on Dalvik, for example. 23:14
pmichaud_ I would view NQP and Rakudo's work on multiple backends as being the path by which Lorito learns what is needed for it to target other backends, then.
chromatic I don't see that as helpful to Lorito.
It's not harmful, but I don't think it's necessary. 23:15
pmichaud_ I do. I don't think the people involved in creating Lorito have enough understanding of Perl 6's needs.
chromatic In what sense?
pmichaud_ I mean as a team dynamic; certainly individuals (yourself) are there. 23:16
but when we say we need serialization, the discussion tends towards proving that parrot already has what we need instead of seeing that the current model is tragically flawed.
or when we need better exception handling and subroutine leave semantics... there's just not an understanding of the issues that we're trying to express. (more) 23:17
or, when I give Perl 6 code to try to illustrate it, the answer often comes back with "that's something Perl 6 will have to layer on top of parrot, not something parrot should natively provide"
sorear there is also an attitude that providing for Perl 6 is politically untenable because it undermines the notion of Parrot as a cross-language VM 23:18
chromatic Then stop perpetuating that myth, sorear. 23:19
sorear It perpetuates fine in #parrot without me
I only ever talk about it here
chromatic I disagree, and filing Parrot bugs in here is not effective. 23:20
pmichaud_ but more to my original point -- how often do discussions of Lorito also include "and we need it to go to other vm backends?"
chromatic Not often, mostly because that's not the primary goal of Lorito. It's a benefit and it's something I want to make possible, but it's not the primary goal. 23:21
pmichaud_ I don't recall seeing anything in the lorito discussion documents that mention .net or jvm or the like. Maybe I'm just missing them.
if that's a goal, then we'll need some experience to feed into the design.
chromatic Maybe I'm horribly naive, but I believe that most of porting Lorito to another backend is mapping the handful of M0 ops to another VM. 23:22
pmichaud_ Do we know what M0 ops are needed to efficiently implement a p6-like object metamodel?
chromatic I believe the same M0 ops needed to implement just about anything else we support right now. 23:23
pmichaud_ that's the disconnect (more) 23:24
what "parrot supports right now" is not really what Rakudo needs.
or, it's a good first approximation, but we need to refine it a lot more
in some sense that statement feels like it might repeat the error that Parrot originally made, when it sought to reimplement the Perl 5 vm 23:25
because that vm wasn't really what is needed for Perl 6
chromatic Let me rephrase then.
pmichaud_ okay, please do.
I know my statements probably read much harsher than I intend. 23:26
chromatic If we can port Parrot as it exists now to M0, M0 is sufficient to implement an efficient metamodel in NQP.
pmichaud_ I'm not so sure about that.
diakopter (what's M0)
chromatic M0 is a series of very low level ops, as if you were writing a virtual machine for a language like C without hewing to its memory model or calling conventions. 23:27
s/series/set/
pmichaud_ I still remain concerned that Parrot focuses far too much on opcodes when what we really need is methods
chromatic Me too. 23:28
pmichaud_ and since the discussions I've seen of Lorito are focused on making opcodes more efficient, I worry that it's gotten things backwards.
chromatic I want to make vtables go away in favor of multimethods in Lorito.
Better?
pmichaud_ Definitely. 23:29
TimToady is not so sure...
chromatic Why is that?
pmichaud_ TimToady: I still think we'll have the notion of vtable-like things that are hidden from the normal method call interface, but they still end up acting very method-like. 23:30
23:31 Italian_Plumber joined
TimToady it just feels like interpreter-on-top-of-interpreter to me 23:31
and FP is fundamentally built on lambdas, not multimethods
pmichaud_ that's a good notion/point to remember.
chromatic Some FP has to perform pattern matching for dispatch though. 23:32
pmichaud_ anyway, I'll be called to dinner soon (more)
TimToady Yes, "some", not "all"
pmichaud_ I'll note that while others have focused on the fact that NQP is looking at other backends, it is not at all the core team's primary focus at the moment, except maybe for jnthn++ 23:33
i.e., what gets the most publicity is not necessarily where the effort actually ends up
chromatic Like I said, it's none of my business how other people spend their time.
I just want to make sure that Parrot supports Rakudo as best it can.
pmichaud_ +1 to that :)
chromatic If that means pleading and cajoling to pull parts of proofs of concept and workarounds into Parrot, so be it. 23:34
pmichaud_ Perhaps kid51 can re-produce the notes he had posted from the yapc::na meeting
[particle] i think they're on the parrot wiki, but i can't recall
pmichaud_ [particle]: I couldn't find them there. 23:35
tylercurtis chromatic: Is the Parrot object model intended to be implemented on top of M0 in some manner? If so, I suppose that that means it will probably allow pointer arithmetic? In which case, how do we translate pointer arithmetic to JVM ops?
[particle] harumph
tylercurtis webcache.googleusercontent.com/sear...&gl=us google cache of broken link pmichaud_ mentioned earlier to those notes, I think.
chromatic I don't think we have to support pointer arithmetic; we just have to support numbered slots.
pmichaud_ tylercurtis++ # yes, that looks like it 23:36
my comments from lists.parrot.org/pipermail/parrot-d...03223.html also still apply
#4 has been addressed.
chromatic #1 is in progress, as always. 23:37
pmichaud_ #1a has been worked on
I haven't seen much new from #1b lately
#2 is still a bit of an issue
chromatic I can work on #6 if you want it now. It's fairly easy.
pmichaud_ jnthn++ is working on it 23:38
chromatic Lexicals?
pmichaud_ yes
as well as attributes
and we still have some p6 spec work to be done there
TimToady hides
chromatic Primitive lexicals seems like an easy fix in Parrot. 23:39
jnthn I'm only digging into attributes for the moment.
pmichaud_ sure, but we still need tools to be able to support them
jnthn It's too early for me to say whether Parrot doing #6 will for certain help but I suspect yes.
pmichaud_ and even if you gave us primitive lexicals tomorrow, I doubt we'd do much with them until after jnthn's work lands
chromatic NQP support you mean?
pmichaud_ NQP and PCT, yes.
jnthn (In the long run, not "tomorrow", as Pm said)
Well, medium run
:-) 23:40
chromatic Let me know. I know how to make them work in Parrot.
pmichaud_ right
that's one of the reasons that item was #6 on my list -- it's worth considering but not a huge impact
#2 from the yapc::na list is more important (the general handling of lexpads and contexts in parrot)
chromatic Sure, but a week of work for lexicals is going to land sooner than a month work of lexpand handling. 23:41
jnthn chromatic: What I will say is don't spend time on native type support in the Object PMC. 23:42
chromatic: Well, re-phrased.
Don't spend time on it in the epxectation it'll help Rakudo.
pmichaud_ my feeling is that this is an area where lexpad handling will ultimately be the arbiter of how it needs to work
chromatic Right, that's part of metamodel changes.
jnthn (Think you know that, but don't want to send you down a blind alley.)
pmichaud_ i.e., the week of work for core types in lexicals would ultimately be lost because lexpad handling implies a more radical change anyway 23:43
not sure that's the case, but that's my feeling.
23:43 mjk joined
chromatic They have to be able to store and retrieve things that aren't PMCs anyway. 23:43
pmichaud_ it feels like one of those fundamental things like list/arrays/iterators in p6, where the smallest change in the fundamentals ends up having radical changes on the entire system
chromatic Adding typed storage is fairly easy.
jnthn I think we may need a model change though. 23:44
pmichaud_ anyway, typed storage might be of some use to NQP at some point, it's very unlikely to help Rakudo anytime soon.
i.e., Rakudo's typed storage is likely to be based on the object metamodel.
and not on Parrot register types.
jnthn For example, the static lexpad and dynamic lexpad probably want to look a lot more alike.
chromatic Including lexicals?
trac.parrot.org/parrot/wiki/PCCPerf...provements 23:45
I want to address how we handle contexts and signatures anyway.
That could include more specific types of Subs, like Closure.
pmichaud_ ...Closure?
chromatic Or at least a specific Sub subclass which knows it has an outer scope. 23:46
outer static scope
jnthn argh, didn't we kill that?
pmichaud_ ah.
well, that's a piece we're definitely missing.
chromatic static scopes?
pmichaud_ afaik, we don't have a way in Parrot to say "create a Sub of type OtherPMC"
TimToady seems more like you'd want a specific class that *doesn't* know about that, since the default is to have an outer
pmichaud_ and yes, what TimToady said
we have far more subs with outer scopes than subs without. 23:47
subs without outer scopes are quite rare in Perl 6, or NQP.
chromatic I have no preference which is the default, merely that we can distinguish them.
pmichaud_ right now we can distinguish by the existence of an :outer flag :-)
jnthn Isn't that just a pointer-is-not-PMCNULL check today?
TimToady it should be orthogonal to type
jnthn (e.g. the otuer thingy)
pmichaud_ and yes, the inability to have good sub types is a blocker for many parts of NQP and Rakudo. 23:48
chromatic I don't want to perform runtime checks for things we know at compile time.
pmichaud_ we don't always know the outer at compile time.
TimToady huh?
jnthn pmichaud_: We _can_ conceptually though.
pmichaud_ TimToady: artifact of Parrot's compilation model.
yes, conceptually we can.
jnthn pmichaud_: Other things keep us from doing so.
Right. :-) 23:49
pmichaud_ but imcc's linkage is a problem.
jnthn That's the disconnect there.
[particle] shoots imcc 23:50
pmichaud_ anyway, NQP suffers from the Sub PMC type problem today -- it doesn't have a way to compile-time create a Sub of type RegexPMC
(or any subclass of Sub)
[particle] if only bullets stopped zombie compilers
pmichaud_ I'm being called to dinner
chromatic I think that's fixable.
TimToady
.oO("put a bullet through csh's head")
 23:51
pmichaud_ chromatic: I think it needs to be fixed as part of a larger serialization fix
although perhaps there's an intermediate step
chromatic :subtype( 'MyCoolSub' )
pmichaud_ chromatic: would that work even if MyCoolSub is a type created during :load :init ? 23:52
i.e., not a core PMC or dynpmc?
chromatic Not sure, but it could be fixed.
pmichaud_ okay. That gets into some nasty parts of imcc, I fear.
and definitely affects freeze/thaw sorts of things, I suspect. 23:53
anyway
chromatic: your concern about multiple-backends diluting effort is noted; let us know if it looks like progress in other areas is stalling.
chromatic Will do. 23:54
pmichaud_ I don't agree that multi-backends was a primary cause for lack of effort on pugs
but I agree it is a danger
chromatic It wasn't the primary cause no.
pmichaud_ personally, I still measure success in terms of how usable rakudo is for the typical programmer
and for me, that's features and speed at this point 23:55
(and correctness)
okay, gone to dinner.
TimToady chow 23:56
sjohnson ciao 23:57
（　｀ー´）

Powered by Cro and the Raku® Programming Language.

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

Thank you!