pugscode.org/ planetsix.perl.org/ | nopaste: sial.org/pbot/perl6 | evalbot: perl6: say 3; (or rakudo:, pugs:, elf:, etc) | irclog: irc.pugscode.org/ | ~315 days 'til Xmas
Set by mncharity on 8 February 2009.
pugs_svn r25505 | wayland++ | Fixed S14 link to say "DRAFT" 00:00
wayland Do it poorly, then someone else will do it for you :)
I presume S14 should be considered in draft mode at the moment
We can have Larry bless it later, I presume? 00:01
jnthn Aye 00:02
wayland [The "Do it poorly" line was in reference to me motivating others to do stuff :) -- I'm not recommending it to others :)] 00:03
jnthn :-P 00:04
jnthn will probably do a Rakudo Day on Wednesday
Before I start my conferences and vacation trip. :-) 00:05
wayland well, enjoy all 3 :) 00:06
00:12 DemoFreak left, cas left 00:13 Ariens_Hyperion left
pugs_svn r25506 | wayland++ | IO.pod: Updated reference to Temporal.pod 00:16
r25506 | wayland++ | S14: Gave credits properly
00:17 skids joined
wayland jnthn: I think one other thing might help get people writing Perl6 -- S20: Calling foreign code :) 00:21
I'll see if I can't do something on it (but if others want to, let me know; I'm happy that way too :) ) 00:22
skids: Hi :)
skids hi!
skids having another go at trying to figure out STD.pm/YAML::Syck usage. 00:25
TimToady * ** 2 when * !% 2 for 1..* 00:26
lambdabot TimToady: You have 1 new message. '/msg lambdabot @messages' to read it.
jnthn TimToady: Uh...wtf is that?! 00:28
TimToady pugs: say ( $_ ** 2 if $_ % 2 == 0 for 1..* )[^20]
p6eval pugs: OUTPUT«*** ␤ Unexpected "if"␤ expecting operator or ")"␤ at /tmp/3E5SMRoUzT line 1, column 15␤»
TimToady I guess pugs doesn't really do list comprehensions yet
jnthn Is that the whatever * there?
TimToady yes 00:29
jnthn What is it meaning here?
Whatever ** 2 is?
Some kinda stand-in for $_?
TimToady plus generates {} around it 00:30
when you say @foo[*-1] it's really @foo[{$_-1}] 00:31
jnthn Around what? The $_ itself? Or the $_ ** 2 ?
Ah, OK.
TimToady and the subscript is handling closure args
1-ary
jnthn * !% 2 is like * % 2 == 0 ? 00:32
TimToady we defined % as one of the negatable operators
jnthn Ah, yes, I remember now...
TimToady it's "iffy"
:)
jnthn That is...disgustingly wonderful...
TimToady bows and falls over sideways
but I probably would write {$_ ** 2} for clarity in any case, just because of the proximity of * an d** 00:34
jnthn Yeah
I found it rather tricky to parse...
TimToady well, we're just lucky that * * * doesn't work as a 2-ary :) 00:35
jnthn std: * * *
p6eval std 25506: OUTPUT«ok 00:02 33m␤»
TimToady does parse, of course...
std: * ** 2 when * !% 2 for 1..*
p6eval std 25506: OUTPUT«ok 00:02 33m␤»
jnthn * ** * when * !% 2 for 1..* 00:36
std: * ** * when * !% 2 for 1..*
p6eval std 25506: OUTPUT«ok 00:02 33m␤»
TimToady I just did that
jnthn Ah, yes.
Oh, I see
It fails when though?
At what stage to we know that * * 2 is OK and * * * is not?
TimToady the when modifier is just a smartmatching if
it doesn't do any break 00:37
sec...
at somepoint we dispatch infix:<**>(*,2) and it finds a multi with an appropriate Whatever sig 00:40
but there is no (Whatever,Whatever) defined 00:41
jnthn Ah, OK.
So likely runtime/dispatch time failure.
TimToady this can probably be known at compile time unless someone adds in a pragma to search packages
but we're trying to limit multis by default to only look in lexical scopes 00:42
jnthn *If* we know all the multi variants...
Can't you eval('multi infix:<**>(Whatever $x, Whatever $y) { 42 }') though?
TimToady we know that lexical scopes are closed at CHECK time
pugs_svn r25507 | wayland++ | S31: Collected the pragmata from everywhere, and listed them here with cross-references
TimToady multis in packages are basically ignored right now 00:43
jnthn Ah.
We're probably getting that very wrong in Rakudo then. :-(
TimToady "is export" puts things into lexical scopes by deflut
*default
probably; we weren't clear on this till the past year or so
jnthn For a definition of "probably" along the lines of "certainly, I wrote it and know full well it's wrong, just in denial about having to fix it" :-) 00:44
pugs_svn r25508 | wayland++ | Added link to S31
TimToady :)
jnthn On a related note
class Foo { eval('method bar() { 42 }') } 00:45
What's this count as?
(Someone submitted a Rakudo ticket with this in...people do the oddest things...)
TimToady well, the question is exactly when does that block run 00:46
jnthn I suspect after class composition time.
TimToady and I think it runs once at class composition time, so the eval is essentially useless
yes
though it might give you a little switchability at that point 00:47
but methods aren't really a big problem, since they're late dispatched anyway
there's something fundamental going on here 00:48
jnthn It'd be a minor pain to make it work (as in, add the method to the class).
TimToady single-dispatch OO is independent of the current language, more or less
so it's run-time dispatched to whatever the current class says
jnthn But it'd be too late to resolve a conflict with a role...
TimToady multi-dispatch is fundamentally defining the language
so wants to be lexically scoped
00:49 eternaleye joined
jnthn Yes, I agree with the design call on that. :-) 00:49
TimToady it's sort of the way C++ ought to have been, the part where you want some non-virtual methods, but not as single dispatch
hence the distinction between multi dispatching even +$x unaries, because numification is a language choice, not an object choice 00:50
jnthn Aye.
TimToady vs $x."+" or whatever
which would be the object's choice of + method
jnthn Can you do that?
TimToady std: $x."+" 00:51
p6eval std 25508: OUTPUT«Potential difficulties:␤ Variable $x is not predeclared at /tmp/paprm8vcnE line 1:␤------> $x."+"␤ok 00:04 33m␤»
jnthn As in, wouldn't you have to write $x.prefix:<+> ?
TimToady no, that would be the multi version again
jnthn Is that not single dispatch first, still?
As in, aren't prefix:<+>($x) and $x.prefix:<+>($x) different? 00:52
TimToady I suspect that gets forced back into multi dispatch, since most other languages won't have the foggiest idea what to do with a method name like that 00:53
jnthn (In the sense that the first is a multi-dispatch right off the bat, and the second is a method dispatch, followed by a multi-dispatch unless the class $x is an instance of defines an only infix:<+>
Hmm, true...
pugs_svn r25509 | wayland++ | S16: Referred to other documents
r25509 | wayland++ | IO.pod: Got rid of filetest pragma
TimToady anyway, we're intending the ."foo" notation as a way of constructing non-standard method names for the consumption of other languages 00:54
since most of those languages don't make prefix/infix distinctions
01:03 nihiliad joined
TimToady so anyway, the .prefix and .infix forms might be considered macros like WHAT, perhaps 01:07
also, we allow .:<+> as a short form of .prefix:<+>, which can be really handy when you just want to move the prefix to the end 01:09
now that &[+] is allowed for the infix functional form, maybe .:[+] could be used for a multi infix in dotty form 01:10
though there's less call for that, since that's where you'd put the infix anyway 01:11
(albeit with precedence differences)
well, I blathering
my brane is in sideways at the moment, I think 01:12
araujo scratches his head 01:13
jnthn They're just fancy ways of re-writing method names, they're not so hard to add.
TimToady except if they're macros...
jnthn But yes, macros could be the way to go.
Apart from, we kinda don't have 'em in Rakudo. 01:14
Is STD.pm handling them at all yet?
TimToady well, there is that...
wayland One document claims that $=foo is a file-scoped variable, and another claims that it's a POD variable. Can someone clarify this?
jnthn Or rather, do you expect STD.pm to have the infrastructure in for handling macros?
TimToady std: (my $x = '').:<+>
oh, macros 01:15
p6eval std 25509: OUTPUT«ok 00:02 34m␤»
TimToady at the moment it only has the part where it introduces names like infix:<op> into the lexical pad
but macros actually have to run code at compile time
so we really need a more-or-less full bootstrap of STD before we can do that
jnthn Ah, yes. 01:16
TimToady at least, the user-defined macros
but we can do anything as grammar rules currently
so .WHAT and such can certainly be parsed that way 01:17
jnthn Do they not essentially install "stuff" into the grammar once they're parsed, though?
e.g. new tokens etc?
TimToady that part works already
jnthn Aha, OK, cool.
TimToady std: sub infix:<***> {...}; $a *** $b
jnthn So "all" that's left is triggering the code and doing the relevant insertion into the parse tree/parse buffer? 01:18
p6eval std 25509: OUTPUT«Potential difficulties:␤ Variable $a is not predeclared at /tmp/5s8cT1btHz line 1:␤------> sub infix:<***> {...}; $a *** $b␤ Variable $b is not predeclared at /tmp/5s8cT1btHz line 1:␤------> sub infix:<***> {...}; $a *** $b␤ok 00:05 38m␤»
TimToady heh
std: sub infix:<op> {...}; 42 op 24
jnthn Is STD.pm handling "is parsed" yet also?
p6eval std 25509: OUTPUT«ok 00:03 34m␤» 01:19
TimToady that's just a standard trait, but it doesn't do anything with it
jnthn Surely it somehow "extends" (I'm probably epic fail on the terminology here) the grammar, though?
TimToady std: macro postfix:<WHAT> is parsed(/whatever/) {...}
p6eval std 25509: OUTPUT«ok 00:04 37m␤» 01:20
jnthn std: macro foo is parsed(/'?*?'/) { ... }; ?*? 01:21
TimToady it's the postfix:<WHAT> that extends the grammar, but it will just parse as a standard postfix regardless of what "is parsed" says currently
p6eval std 25509: OUTPUT«############# PARSE FAILED #############␤Obsolete use of ?: for the conditional operator; in Perl 6 please use ??!! instead at /tmp/2PiT7q65Bg line 1:␤------> acro foo is parsed(/'?*?'/) { ... }; ?*?␤FAILED 00:03 35m␤»
jnthn OK.
TimToady and you really need to tell it the grammatical category on a macro so it knows what state to leave it in afterward 01:22
I suppose "macro foo" could default to "macro term:<foo>" though 01:23
jnthn Ah, true. 01:24
TimToady std: sub term:<[[[> {...}; [[[ + [[[
p6eval std 25509: OUTPUT«ok 00:03 37m␤»
jnthn Sick. :-) 01:25
TimToady bows and falls over the other direction this time
std: sub prefix:<[[[> {...}; [[[ + [[[ 01:26
p6eval std 25509: OUTPUT«############# PARSE FAILED #############␤Can't understand next input--giving up at /tmp/rXNexAjDqf line 0:␤------> ␤ expecting any of:␤ circumfix␤ noun␤FAILED 00:03 35m␤»
TimToady std: sub prefix:<[[[> {...}; [[[ + [[[ 42
p6eval std 25509: OUTPUT«ok 00:03 35m␤»
jnthn It's presumably parsing as prefix:<+> there?
TimToady I think that's the default 01:27
or is it ++
symbolic unary, so +
or !
it also ignores equiv and friends currently 01:28
again, trait handling requires a run-time :)
well, doing it right does 01:29
didn't stop me from cheating on enums though :)
jnthn ;-)
OK, it's later than I really should be concious... 01:30
jnthn sleeps
TimToady night
jnthn night, thanks for chat :-)
wayland 'night jnthn 01:32
Oh, are $= variables file scoped, but considered POD variables because POD auto-creates them? 01:33
ie. could I do $=foo = "text", and have that work, but be an unusual usage?
TimToady the design of $= variables is not really finalized
wayland ok
:)
TimToady we're just reserving the twigil
might just be a big hash under %=POD or some such, who knows what Damian will come out with eventually 01:34
wayland Ok.
TimToady though I'd guess we want to use the namespace directly for something 01:35
wayland There was talk about how we might unify some of the special variables into $?ENV and $*ENV. How would that work? $ENV.OS or something? 01:36
TimToady and we definitiely want the self-documenting aspect of the twigil
to alert people to the abnormalcy of the data source
wayland That makes sense :)
TimToady $?ENV and $*ENV have nothing to do with each other
$?ENV would be the environment of the compiler at that point in compilation 01:37
$*ENV is the environment of the run time
all ? vars are constants at run time
wayland Yah, I know that. That should've been $?ENV.OS (with alternatives being things like %*ENV{'OS'} or something)
TimToady well, people aren't in the habit of setting OS in the environment, so it doesn't seem like it belongs 01:38
wayland Or do we want things like $*ENV.operatingsystem ?
TimToady and it's something you probably want a top-level name for
wayland ok
It's just there's this comment in S28 that came from somewhere... 01:39
TimToady ENV should reflect more or less what the environment vars are used for already
wayland It said that you liked the idea of putting lots of other things in $*ENV, and then putting environment variables in $*ENV.environment
Maybe you've changed your mind :) 01:40
TimToady the idea doesn't sound familiar to me at the moment, but it could just be senility
or migraine...
I'm one of those fortunate few who get painless migraines
but all the miasma that goes with, I get to deal with 01:41
araujo finally understands why perl is like this
wayland Ouch. Anyway, it's currently in S28, svn.pugscode.org/pugs/docs/Perl6/Sp...iables.pod at the bottom of the named variables section 01:42
TimToady I see that, but I was probably agreeing that we wanted something more like we ended up with context vars 01:43
where the program's dynamic scopes can set up little environments
wayland OK 01:44
TimToady or maybe I was just nodding my head the way people do when they don't really understand :)
wayland :)
What would you say to something like %*PROC{PID}, %*PROC{UID}, and that sort of thing? 01:45
Or do you like them better the way they are? :)
01:45 dukeleto joined 01:46 sri_kraih joined 01:47 sri_kraih left
TimToady there are several competing design notions here 01:47
we'd like to minimize globals that have to be set up in advance, but we'd also like to huffmanize common vars like $*PID
I suppose some of these things could just be stubs in PROCESS:: or GLOBAL:: that lazily calculate if necessary 01:48
not necessary for $*PID, since that's just a number known at startup 01:49
wayland ok.
TimToady could even be autoloaded names, which PROCESS:: gets interrogated
so just exists as a when 'PID' somewhere until someone actually asks for $*PID 01:50
we've already got several ways to be lazy if we need to 01:51
wayland ok. I'm in the process of trying to knock S28 into shape :), so I'm mainly worried about labels. But the autoload idea is cool :)
("labels" used loosely here :) )
TimToady to the extent possible, just try to attach things to the right namespace or object, and then delegate to that namespace or object 01:52
course, if it's an object, it doesn't belong in S28 any more
so $*VM can delegate everything to class VM_Descriptor or whatever... 01:53
and as for which object attrs really ought to huffmanize upward, we'll just have to deal with that on a case-by-case basis 01:54
much like deciding what is imported into CORE scope defines the standard Perl 6 langauge
wayland Ok, I'll try to keep all that in mind :)
TimToady easy things easy, hard things possible... 01:55
course, deciding which is which is hard
wayland :)
I'll try to keep that in mind too. 01:56
TimToady and that natural languages generally prefer that principle over consistency :)
which is why your most common verbs are the most irregular 01:57
wayland Interesting :)
TimToady recomended reading: The Search for the Perfect Language, by Umberto Eco
s/m/mm/ 01:58
01:59 Maghnus left, Maghnus- joined, Maghnus- is now known as Maghnus
TimToady Eco does a great job of explaining *why* you don't want absolute consistency in a language 02:00
(in addition to why it can't be achieved in the first place)
wayland Ok, I'll add it to my reading list :). Looks interesting.
02:00 alc joined
TimToady it's about all the people trying to invent "philosophical languages" 02:00
like Wilkens, et al. 02:01
but has great applicability to computer language design nonetheless
wayland :). I remember someone asking Damian why he wrote his "Perl in Latin" thing in Latin instead of Esperanto :) 02:02
TimToady well, he knows Latin, for one...
but Latin also has all the lovely declensions and cases and such 02:03
me, I'd do it in Greek if I did it
s1n moritz_: take a look at ef8bb8a9bbc102a2aa96af93b81ee513eb8f4158 again 02:04
specifically, Range.pir:41
it does a to/from on the topic
as well as self
wayland knowing Latin was Damian's reason. I was under the impression that Esperanto did cases, etc, too.
wayland checs Wikipedia page
s/checs/checks/ 02:05
s1n moritz_: i believe all i did was move the ACCEPTS method directly to setting
TimToady but it might be too regular to map well onto Perl 5
s1n moritz_: to say it doesn't work means that i didn't move it over from setting correctly
TimToady Esperanto, not Greek
02:06 iblechbot left
TimToady Latin and Greek both provide "enough rope" 02:06
decommuting & 02:07
wayland bye, and thanks :)
s1n jnthn: ping 02:10
skids thinks when a nice, short, mnemonically advantageous, keyword is available from a language other than english, heck, use it.
e.g. the opposite of "init" isn't exit, it's "fini" :-) 02:11
dukeleto skids: +1 02:12
02:14 justatheory_ joined
s1n skids: no, init is an abbreviation for initialize, the opposite of that is terminate or better yet finalize 02:14
i believe fini is the italian equiv, which init is not
unless fini is not italian, or some other non-english-yet-latin translation, then you would be right 02:15
skids Yes, but fini does mean finish/finalize, is easily recognizable for english speakers, and makes a nice graphically matched pair with init, even though they are from different natrual languages. 02:16
02:17 justatheory left
s1n no see, as an english speaker, i can choose to abuse my own language all i want at the risk of avoiding foreign languages like the plague :) 02:17
therefore, exit seems to look better to me :)
skids heheh. Actually for edification, fini in italian is "fine", it is finish in french, and in esperanto, and apparently is colloquially used in german speaking populations as finish. 02:19
And I have no clue what fini is in Finnish. 02:20
s1n case in point, fini is a bad choice simply because it would require me, a native english speaker, to have to interact with other languages
skids What you never say "voila!" ?
s1n usually only in a mocking tone :) 02:21
skids OK fine think of it as "init" spelled backwards and upside down, then. 02:22
02:26 frooh joined, frooh left, frooh joined
frooh rakudo: my $foo = { bar => 'baz' }; $foo->{bar}; 02:27
p6eval rakudo 2a9382: OUTPUT«Statement not terminated properly at line 1, near "->{bar};"␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)␤»
frooh rakudo: my $foo = { bar => 'baz' }; $foo.{bar};
p6eval rakudo 2a9382: OUTPUT«Could not find non-existent sub bar␤current instr.: '_block14' pc 99 (EVAL_18:46)␤»
frooh rakudo: my $foo = { bar => 'baz' };
p6eval rakudo 2a9382: RESULT«{"bar" => "baz"}»
frooh rakudo: my $foo = { bar => 'baz' }; $foo{bar}; 02:28
p6eval rakudo 2a9382: OUTPUT«Could not find non-existent sub bar␤current instr.: '_block14' pc 99 (EVAL_16:46)␤»
frooh rakudo: my $foo = { bar => 'baz' }; $foo{'bar'};
p6eval rakudo 2a9382: RESULT«"baz"»
frooh rakudo: my $foo = { bar => {baz=>'bop'} }; $foo{'bar'};
p6eval rakudo 2a9382: RESULT«{"baz" => "bop"}»
frooh rakudo: my $foo = { bar => {baz=>'bop'} }; $foo{'bar'}{'baz'};
p6eval rakudo 2a9382: RESULT«"bop"» 02:29
frooh Can anyone here tell me if that's actually a hashref?
skids rakudo: my $foo = { bar => {baz=>'bop'} }; $foo.WHAT; 02:30
p6eval rakudo 2a9382: RESULT«Hash»
TimToady we try not to talk about references, though yes, it is one
frooh TimToady: why not?
TimToady most of the time you just want to think about the object involved 02:31
so it's just a Hash
frooh also: That's great. My coworkers are always confused about reference based data structures
right
which is good
TimToady and most of the syntax lets you ignore the ref distinction, unlike in p5
frooh clearly
and you told me that functions can specify that they want a ref in their signature so that we won't have to tell users to pass hash refs, right? 02:32
so it auto refs it
TimToady if you say sub foo (@foo) it's expecting an array ref to bind to @foo
and you just call it foo(@bar) to pass that ref 02:33
since an array or hash in item context just returns itself
frooh was the space in the previous line intentional/
or do spaces matter in function definitions?
TimToady the space is optional in the declaratoin, but not in the call
frooh got it
pugs_svn r25510 | lwall++ | [STD] clarify the general principle in the if() catcher 02:35
02:38 Whiteknight left
pugs_svn r25511 | leto++ | Tests for rounding NaN and Inf 02:47
02:49 agentzh left 02:54 Maghnus- joined, carpftb joined 02:58 aindilis` left 03:08 justatheory joined, justatheory_ left 03:10 Maghnus left, Maghnus- is now known as Maghnus 03:18 japhb joined 03:23 agentzh joined
TimToady std: if(42) {...} 03:33
p6eval std 25511: OUTPUT«############# PARSE FAILED #############␤if() interpreted as function call at line 1 ; please use whitespace instead of parens␤Unexpected block in infix position (two terms in a row) at /tmp/RBiSTsDjBi line 1:␤------> if(42) {...}␤ expecting any of:␤ infix or
..met...
frooh is that supposed to happen? 03:36
03:40 frooh left 03:47 cspencer joined
TimToady yes 03:50
skids TimToady: WRT the :kv, :p etc adverbs, obviously %a{}:p{}:p is a parsing ambiguity and probably not very useful. But is %a{}{}:p to be allowed or do we want to demand %a{;}:p always? 03:58
04:00 dduncan joined, dduncan left 04:01 hercynium left
pugs_svn r25512 | putter++ | [elfparse] EXPR porting continues. 04:11
04:14 cspencer left 04:15 cspencer joined
wayland TimToady: Have we clarified $*MOST_RECENT_CAPTURED_MATCH vs. $/[-1] vs. $/[-$n] yet? 04:17
04:32 hello\n joined
pugs_svn r25513 | lwall++ | kill DEF* variants 04:36
TimToady [-1] is almost always wrong
%a{}:p %a{}{}:p %a{}{}{}{}{}{}{}:p all mean the same thing, since {} is a noop 04:38
skids OK then, %a{1,2}{2,3}:p 04:40
TimToady and I have no idea what you're intending by %a{;}, which looks like a two-dimensional null slice
skids What's the preferred thing to jam in there to be clear you don't care what's in the {}'s -- ... ? 04:41
TimToady what kind of "don't care" are you not caring?
what are you trying to do?
04:41 sahadev1 joined
skids Figure out whether the adverbs will be legal to apply to the old fashioned nested slices. 04:42
TimToady adverbs apply to the topmost operator in scope, which for postfixes means the final one
skids And I'm brouwsing try5 output and getting the impression that they are already in there as intended (?)
04:44 nihiliad left
TimToady hmm, haven't use try5 in months; I generally use viv 04:45
wayland Btw, TimToady, I'm currently doing lots of the same things as your last commit :)
TimToady I believe STD already parses them as intended, though of course I could be wrong :)
where did you get that fossil about $FOO usually meaning the same as $*FOO?
that hasn't been true for years... 04:46
skids Thanks, I'll try that out. Since you didn't seem to bat an eye at using them on the last in a nested bracket pair, I would say yes it looks like STD handles them like that.
TimToady note, however, that if you say +%s{}:p it applies to the + rather than the subscript
so you'd have to say +(%s{}:p) in that case 04:47
not that that makes sense...
wayland From one of the previous attempts at S28, I suspect :)
TimToady ah
which presumably dated from the Pugsian Era 04:48
skids OK, so prefix ops suck up adverbs more greedily than postfix/postcircumfix.
TimToady it's not about greed
except insofar as precedence codifies it
skids Or well I guess greed is an overloaded word
wayland Oh, some of this stuff is definitely the Pugs era, which I was never very au fait with
TimToady basically, the adverb is applied as a unary modifier on whatever top-level node is on the left 04:49
which that is determined by precedence
and generally conforms to the temporally last thing evaluated
skids got it.
TimToady that is tighter than =
all this applies to %foo<key>:delete and %foo<key>:exists as well 04:53
you probably see those more often
which is odd, since they're huffman code longer
*coded
probably means :p should be :pairs
04:54 Avada joined
pugs_svn r25514 | wayland++ | Added a note about @*ARGS 04:56
r25515 | wayland++ | Added some things taken from the S28 sources. 04:58
skids Would :p:delete and :delete:p both be valid? And would we honor weird stuff like :kv:p? 05:01
05:03 masak joined
pugs_svn r25516 | lwall++ | more DEF extermination 05:04
TimToady it would depend on how the multisigs are written 05:05
they're just name arguments
*named 05:06
I expect :kv and :p would be exclusive
but :delete:p would mean delete the entries and return them as pairs, which seems orthogonal 05:07
skids so order cannot matter, if I get you...
TimToady they're not supposed to, which is reportedly one of the benefits of named args :)
skids :)
TimToady evacuate quickly and quietly vs evacuate quietly and quickly 05:08
could well be that the modified subscript op is written in terms of *%_ and it just looks for %_<delete> etc itslef 05:09
then maybe there's a fast unmodified def for normal subscripting 05:10
pugs_svn r25517 | wayland++ | - Made twigils short (see S02 for full doco).
r25517 | wayland++ | - Rearranged main variable list
TimToady or just :$p, :$delete, :$exists as separate args, but that seems a little strange 05:11
s/args/params/
pugs_svn r25518 | lwall++ | redelete fossil 05:13
skids If I get that far, I'll just try to do what seems best for the most useful cases and later it can always be modified. 05:14
pugs_svn r25519 | wayland++ | Lots of general reoganisation. Still needs lots more work, and I will continue when I get 05:17
r25519 | wayland++ | the chance (probably tomorrow). Hope I haven't reintroduced any old artifacts again :).
wayland Thanks all. I'm going to disappear until tomorrow :) 05:18
skids heading bedward too, obviously up too late the enzyte commercials are on. 05:19
s1n moritz_: please let me know what, if anything, you think i did wrong that hadn't already been done in the PIR version 05:22
bed&
05:35 Tene_ joined 05:40 Avada left 05:44 hello\n left 05:48 Tene left
masak appreciates the death of *DEF 06:04
rakudo: subset Percentage of Int where { 0 <= $^perc <= 100 }; sub set_percentage(Percentage $perc is rw, Int $value) { try { return $perc = $value; CATCH { return $perc = 0 if $value < 0; return $perc = 100 } } }; my Percentage $p; say set_percentage($p, 50); say set_percentage($p, 101) 06:19
the above hangs on my box.
p6eval rakudo 2a9382: No output (you need to produce output to STDOUT) 06:20
TimToady probably infinite regress on the test
masak but it shouldn't, right?
TimToady is the the bug where an error thrown in a handler gets recaught? 06:21
masak might be.
I know it hangs during the second call.
rakudo: subset Percentage of Int where { 0 <= $^perc <= 100 }; sub set_percentage(Percentage $perc is rw, Int $value) { try { return $perc = $value; CATCH { return $perc = 0 if $value < 0; return $perc = 100 } } }; my Percentage $p; say set_percentage($p, 101)
masak tries to minimize the example locally 06:22
p6eval rakudo 2a9382: No output (you need to produce output to STDOUT)
masak I've now minimized away the subset. :) 06:27
rakudo: sub s { try { return 1; CATCH { return 2 } } }; say s 06:28
OK, seems like the try block catches return exceptions. 06:29
p6eval rakudo 2a9382: No output (you need to produce output to STDOUT)
masak submits rakudobug
rakudo: package A { sub foo { say "OH HAI" } }; A.foo # should this work? 06:39
p6eval rakudo 2a9382: OUTPUT«Null PMC access in getprop()␤current instr.: 'parrot;P6object;HOW' pc 60 (runtime/parrot/library/P6object.pir:98)␤»
masak the :: form works. 06:40
rakudo: package A { sub foo { say "OH HAI" } }; A::foo
p6eval rakudo 2a9382: OUTPUT«OH HAI␤» 06:41
masak I guess A.foo above should not work, since foo is not a method on the package object A. 06:44
rakudo: package A {}; A.foo 06:45
06:46 ashizawa joined
p6eval rakudo 2a9382: OUTPUT«Null PMC access in getprop()␤current instr.: 'parrot;P6object;HOW' pc 60 (runtime/parrot/library/P6object.pir:98)␤» 06:46
06:48 f00li5h is now known as f00li5h[hireme]
masak rakudo: method foo { say self }; foo(5) 06:48
p6eval rakudo 2a9382: OUTPUT«5␤»
masak hah. 06:49
06:49 sahadev1 left
masak a regression. 06:49
masak is pretty sure he's filed a ticket against that once already
06:53 zamolxes left 06:57 oskie joined
masak RT is flaky today. 07:00
07:16 cspencer left 07:26 justatheory left
masak perl6: my $b = True; --$b; say $b 07:48
p6eval elf 25519: OUTPUT«No viable candidate for call to multimethod prefix__45_45($) at (eval 120) line 4␤ at ./elf_h line 4346␤»
..rakudo 2a9382: OUTPUT«Method 'pred' not found for invocant of class ''␤current instr.: 'parrot;Perl6Object;' pc 1594 (src/classes/Object.pir:696)␤»
..pugs: OUTPUT«0␤»
masak who's right, Pugs, or those other two whiney implementations? :P
08:01 meppl joined 08:08 iblechbot joined
Maghnus perl6: my $b = False; --$b; say $b 08:18
p6eval elf 25519: OUTPUT«No viable candidate for call to multimethod prefix__45_45($) at (eval 120) line 4␤ at ./elf_h line 4346␤»
..rakudo 2a9382: OUTPUT«Method 'pred' not found for invocant of class ''␤current instr.: 'parrot;Perl6Object;' pc 1594 (src/classes/Object.pir:696)␤»
..pugs: OUTPUT«-1␤»
08:19 dalek left 08:20 dalek joined
Matt-W Good morning 08:20
pugs_svn r25520 | moritz++ | [t/spec] various small improvements, and tests for $str.index("0") 08:21
moritz_ Matt-W: you wanted to see Str.split in pure Perl? then git-pull now ;-) 08:22
masak Matt-W, moritz_: morning, M-s :) 08:23
TimToady comb was written in P6 for pugs too
albeit P6 code that pugs could grok 08:24
masak in the interests of release-early, here's my take on SVG for Perl 6: github.com/masak/svg/blob/63f525916...vg-example
moritz_ TimToady: I also wrote comb in Perl 6 08:25
masak much remains to be done, but I'd be happy to receive comments on what's already there.
moritz_ TimToady: it's just a bit ugly right now, because rakudo doesn't support the :pos modifier yet, so I have to destruct the string piece-wise, so .from and .to in the match objects are wrong
still, it's a start
TimToady why do you have to destruct the string at all? does rakudo support :g? 08:26
moritz_ no 08:27
masak it doesn't?
moritz_ rakudo doesn't parse any adverbs
rakudo: say "abc" ~~ m:g/\w/
TimToady even inside the regex?
p6eval rakudo 2a9382: OUTPUT«Statement not terminated properly at line 1, near "\\w/"␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)␤»
moritz_ rakudo: say "abc" ~~ m/:g \w/
p6eval rakudo 2a9382: OUTPUT«a␤»
masak rakudo: my $s = "aaa"; say $a.subst('a', 'b', :g)
p6eval rakudo 2a9382: OUTPUT«Scope not found for PAST::Var '$a' in ␤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 146 (src/PCT/HLLCompiler.pir:102)␤»
masak rakudo: my $s = "aaa"; say $s.subst('a', 'b', :g)
p6eval rakudo 2a9382: OUTPUT«bbb␤»
moritz_ ah, wicked 08:28
I could do something like this:
08:28 DemoFreak joined
moritz_ $s.substr($regex, { take $_ }, :g) 08:28
for $str.comb 08:29
masak .subst
moritz_ right
TimToady might be easier to hack in :pos :)
or sneak in a . ** { $pos } somehow 08:30
moritz_ you can't access outer vars in regex closures :( 08:31
Matt-W moritz_: I'll take a look
TimToady I said "sneak", not "do it right" :)
or write an extra [.*?pattern]* inside 08:32
moritz_ well, it mostly works for now, so I'll leave it as-is until somebody implements :pos or :g (or sneaks them in ;-) 08:33
TimToady rakudo: say "abc" ~~ m/[.*?(\w)]*/
p6eval rakudo e074bf: OUTPUT«abc␤»
TimToady rakudo: say ("abc" ~~ m/[.*?(\w)]*/).join(' ') 08:34
p6eval rakudo e074bf: OUTPUT«a b c␤»
TimToady there you go
Matt-W moritz_: why say $limit = * in the argument list, and then turn that into Inf in the body? Why not just have Inf be the default value?
moritz_ Matt-W: because it's specced to be *
masak rakudo: my $foo = "b"; say "aaa".subst("a", { $foo }, :g)
p6eval rakudo e074bf: OUTPUT«_block26_block26_block26␤»
moritz_ Matt-W: and because $str.split(m/.../, *) has to work
Matt-W moritz_: okay, fair enough 08:35
TimToady my solution above will have correct .from and .to
08:35 bacek_ left
Matt-W moritz_: Looks nice, I really need to play around with gather/take 08:35
moritz_ TimToady: nice
08:36 ejs joined
moritz_ rakudo: say ("abc" ~~ m/[.*?(<.before \w>)/).join('|') 08:36
p6eval rakudo e074bf: OUTPUT«Statement not terminated properly at line 1, near "/[.*?(<.be"␤␤current instr.: 'parrot;PGE;Util;die' pc 129 (runtime/parrot/library/PGE/Util.pir:83)␤»
moritz_ TimToady: now if I could interpolate into a regex, I could use that ;-)
rakudo: say ("abc" ~~ m/[.*?(<.before \w>)]/).join('|')
p6eval rakudo e074bf: OUTPUT«␤»
moritz_ rakudo: say ("abc" ~~ m/[.*?(<.before \w>)]*/).join('|')
TimToady might loop a lot 08:37
08:37 s1n left
p6eval rakudo e074bf: No output (you need to produce output to STDOUT) 08:37
masak I've lately started to miss the power of Perl 6 regexes in other languages. 08:38
Matt-W I spend enough time missing Perl 5 ones 08:39
One day I'm going to have to get a job writing Perl 6 :) 08:40
pugs_svn r25521 | moritz++ | [t/spec] tests for $str.index(0) (really, this time ;-) 08:42
TimToady zzz & 08:45
08:45 ejs1 joined 08:53 alc left
masak Matt-W: the way to get a job writing Perl 6 is to find a niche where Perl 6 can do something which other programming languages can't (easily) do, and write something great that people want. 08:54
08:54 ejs left
Matt-W masak: unfortunately people are fickle and frustrating 08:54
And we probably want a slightly more mature Perl 6 implementation before that can happen :) 08:55
masak yes, but if they have an itch that your program scratches...
the Perl 6.0.0 release is somewhat of a mirage.
we all know that Perl 6 won't suddenly spring into existence. 08:56
it grows, organically, through thousands of contributions.
...and while not yet finished, it already supports a few interesting applications. 08:58
Matt-W indeed
And all we can do is continue to write stuff
I've been trying to put together a grammar for format fields 08:59
masak Matt-W++ 09:01
Matt-W later this week, with any luck, I'll have something to push up and get feedback on
at the moment it's a horrible mess :)
masak the trick is to push it before that stage :) 09:02
moritz_ there's something I don't really like about Perl6::Form - although only from a theoretical point of view, since I've never used it 09:03
since the format and the variables are intermixed, the form processor has to count how many arguments to consider variables 09:04
09:04 Lorn left, yahooooo left, edenc left, avar left, preflex left, edenc joined, avar joined
moritz_ and then the next argument is again interpreted as a form 09:04
09:04 Lorn joined
Matt-W yes 09:04
moritz_ that means that it can never produce good error messages such as "your templated suggested 5 variables, but you gave only 4
09:04 yahooooo joined
moritz_ (unless it's at the end of the argument list) 09:04
masak that's true. 09:05
it's a bit unfortunate.
moritz_ maybe all variable-arguments should go into an Array?
Matt-W there's a desire in it to keep the data variables close to the fields that they fill, I think
else I'd just stick the lot of them at the end like printf
moritz_ like process-form $format_string1, [$var1, $var2], $format_string2, [$var3, $var 4]
Matt-W: not all into the same array, but all belonging to one format template into one array 09:06
each
masak moritz_: either that, or just disallow multiple format strings. and the format sub will have to be called again.
09:06 preflex joined
masak there's something to be said for mimicking sprintf, for example. 09:06
Matt-W hmm 09:07
moritz_ masak: that's not so nice, because it means that it has to hide some state for you
Matt-W moritz_: it would allow nicer error messages
and you could just take pairs of arguments, except where an argument has no fields 09:08
masak oh, there's state involved.
I didn't realize that.
moritz_ for stuff like tables with headings
masak ah.
moritz_ they can't be rendered before the data is known
masak then I like the array idea better.
Matt-W If it was Java, we could also solve the problem by requiring the format parameters to be Format objects instead of strings, then we could easily tell them apart from data parameters :) 09:16
moritz_ I'm glad this is not java ;-) 09:17
Matt-W me too
masak you're making almost no sense at all. :)
Matt-W of course then we'd probably also have to say Formatter formatter = FormatterFactory.createFormatter(new FormatterContext()); 09:18
masak rolls his eyes at the Java bashing
Java can be abused, just like Perl.
Matt-W Sorry, I saw some Java yesterday and I need to work it out of my system
yes, it can
the trouble is, Java is abused in its standard library 09:19
masak and the forces working towards abusing it are cluelessness and frameworkitude, rather than golfing and cargo culting as in Perl.
but the bashing looks all the same to me.
let's add that List contains too many parentheses, while we're at it. :P 09:20
s/List/Lisp/
Matt-W nothing wrong with Lisp that a Haskell-style syntax wouldn't fix, IMO
But I guess I'd get used to it as it is
(intermittently reproduceable deadlocks)-- 09:21
09:25 bacek joined 09:29 pmurias joined 09:32 jeremiah_ left 09:34 jeremiah_ joined 09:43 szabgab joined 09:51 bacek left 10:03 s1n joined 10:31 s1n left 10:43 s1n joined 10:44 pmurias left 10:46 ejs2 joined 10:48 jferrero joined 10:52 bacek_ joined 10:57 ejs1 left 11:09 szabgab left 11:40 drbean_ joined 11:52 drbean left 11:57 jeremiah_ left
s1n moritz_: i see what you're talking about, i'm going to fix it to mimic the logic in to_test and from_test 11:58
moritz_: okay, i conceed, i was trying to wrap the to_test and from_test into accepts and i didn't do it correctly. don't worry about this until i send you another pull request 12:08
moritz_: that is, it doesn't support string ranges, but the use of .to and .from look correct 12:10
12:11 ludan joined 12:13 alanhaggai_ joined, alanhaggai_ is now known as alanhaggai, Ariens_Hyperion joined 12:14 alanhaggai left 12:16 Ariens_Hyperion left 12:19 charsbar_ left 12:22 charsbar joined 12:30 bacek_ left 12:41 SamB left
pugs_svn r25522 | masak++ | [u4x/TODO] added built-in grammar rules 12:50
r25522 | masak++ |
r25522 | masak++ | (Richard Hainsworth)++
masak that empty line was because I committed via git-svn, and git likes an empty line there. :) 12:51
13:05 ashizawa left, bacek joined 13:11 SamB joined 13:41 skids left 13:50 jeremiah1 joined 13:54 jeremiah1 left, jeremiah_ joined
literal moritz_: www.nntp.perl.org/group/perl.perl6....30871.html 13:58
you say that all references to @!foo must include the !, however, S02 says "$!foo object attribute private storage (mapped to $foo though)" 13:59
bacek moritz_: can you close #62168? It's not relevant anymore 14:00
masak literal: I hope that's a fossil.
bacek: I can close it.
bacek masak: ok
literal masak: can I ask why? it makes sense to me that you should be able to say $foo regardless of whether it has a public accessor 14:01
bacek masak: and #62992 too.
masak literal: I just think it's an unnecessary convenience, which might possibly be confusing.
literal oh wait, do you also have to use the dot if it's $.foo ?
if so, then it's not that strange 14:02
Matt-W you do
literal ok
Matt-W or so I thought
masak literal: when it's declared $.foo, you can refer to both $.foo and $!foo
literal: and they mean slightly different things.
(or very different things, depending)
14:04 icwiener joined
literal so, what's the deal with Temporal? why not call it Time? :P 14:07
14:07 nihiliad joined
masak I propose we name it Bike::Shed. 14:09
jnthn literal: I'm sure somebody will explain it in an Instant. ;-)
literal masak: but that's even longer than Temporal! :P 14:10
masak literal: so you're saying you're not completely happy with that name? :P
truth be told, as long as the implementation is not botched up, I'll accept a name as long as Temporal::Infinitessimal::Instant. 14:11
just don't make a mess of the API.
DateTime is a fine ideal by me.
literal is there a reason why some synopses aren't HTMLized on perlcabal.org/syn/ ?
masak literal: tuit shortage? 14:12
literal tuit?
masak literal: sorry. :)
it's a unit of work.
literal I see
some new synopses have been HTMLized, but S17 and S22 haven't been for a long time 14:13
masak masak.org/carl/w/index.php/Tuit
literal I just thought this process was automatic and there was some reason that these weren't being converted 14:14
masak the process is automatic, but things have moved around lately.
and I guess there's an index/script somewhere that needs updating. 14:15
jnthn finally gets the boring ASP task off his plate 14:19
OK, so who can tell me how to create a branch in GIT? 14:20
As in, one that is visible to others on github.
Matt-W github has a fork button when you're looking at a branch... I've never pressed it, but it might be a place to start looking 14:21
14:21 xinming_ joined
masak jnthn: I usually branch locally and then push to origin/mynewbranch 14:21
14:21 dalek left 14:22 dalek joined
jeremiah_ jnthn: book.git-scm.com/3_basic_branching_...rging.html 14:24
14:25 Ariens_Hyperion joined
PerlJam jeremiah_: I think it's the push that he really needs help with 14:25
jeremiah_ PerlJam: Ah, okay. :) 14:26
jnthn Aye. I have the branch locally. 14:27
So I'd so like
push origin/name_of_my_branch name_of_my_branch
?
masak git push origin name_of_your_branch 14:28
(don't ask me why, but that's the syntax)
jnthn origin is the name for the remote server I'm pushing too?
masak it's usually called origin by default
jnthn And master in "git push origin master" is my local master branch? 14:29
masak it's a convention, just like 'master'
jnthn OK.
masak jnthn: no, I _think_ origin and master are to be read together in git push.
as in, they specify two parts of the target.
but I'm just guessing, to be honest.
jnthn Creating a local branch is sure *faster* than svn... :-) 14:30
PerlJam well, "git push origin master" is the same things as "git push origin master:master" (the syntax is "git push <repo> <local-branch>:<remote-branch>") 14:31
(IIRC. I haven't had to do much remote pushing lately)
jnthn Aha, OK.
git might make sense to me some day... :-)
moritz_ literal: I might not know every aliasing for attributes 14:35
note to self: never try git-pull --rebase when you merged a branch and didn't push 14:36
14:39 skids joined, xinming left
jnthn Hmm. Did anyone move split to the setting/ 14:43
?
moritz_ yes, I did
jnthn We now fail a spectest. :-(
moritz_ jnthn: in which file? 14:44
jnthn t\spec\S29-str\split-simple.t 1 256 32 52 7-32
Did you put it in Str or Any?
moritz_ I put it in Str, and a proxy method in Any
it's all green here
jnthn t\spec\S29-str\split-simple...............................ok 1/32Method 'split' 14:45
not found for invocant of class 'Int'
moritz_ did you svn up?
jnthn Hmm
no, but I git pulled.
;-)
moritz_ and reconfigured rakudo?
jnthn ...epic fail.
moritz_: ah no 14:46
even with a re-configure I still fail the same way.
moritz_ jnthn: can you see from your build log if Any.pm was compiled? 14:47
dalek kudo: 70d9081 | jnthn++ | src/setting/Pair.pm:
Use $.key rather than self.key etc in Pair.pm; improvement suggested by moritz++.
jnthn moritz_: Hmm...it ain't in my gen_setting.pm 14:48
Though it is in Makefile.in
moritz_ /usr/bin/perl build/gen_setting_pm.pl src/setting/Any.pm src/setting/Array.pm src/setting/Bool.pm src/setting/Hash.pm src/setting/List.pm src/setting/Pair.pm src/setting/Str.pm src/setting/Whatever.pm > src/gen_setting.pm
jnthn SETTING = \ src/setting/Any.pm \
Trying a make realclean... 14:49
moritz_: OK, that did it. 14:50
Hmm...wonder if that means some makefile rules are wonky...
moritz_ is reliefed 14:51
src/gen_setting.pm: build/gen_setting_pm.pl $(SETTING)
jnthn Looks right to me...
Oh, can you get an odd situation where the makefile is changed, but it doesn't realize that Any.pm is now? 14:52
*new?
moritz_ yes
jnthn Oh.
What's the Right Thing to do in such situations?
Just say people should make clean? 14:53
moritz_ when you check out, build it, reconfigure, build again
yes
jnthn OK, good.
moritz_ always make clean before/after reconfigure
14:55 Ariens_Hyperion left
jnthn yay, my new branch is on github :-) 14:56
masak I like $.key -- maybe the rule of thumb should be to use $.foo for accessors, and self.foo for non-accessor methods... 14:57
(or other suitable sigils, of course) 14:58
jnthn Yes. 14:59
masak maybe I'll email that to the "Perl 6 best practices" thread on p6u. :) 15:00
that would make it the fastest-forming best practice in the history of programming. 15:01
15:03 jan_ left 15:05 jan_ joined 15:18 ejs2 left 15:22 ejs joined
masak rakudo: class A { has $!foo; method x { say $foo } }; A.new(:foo(5)).x 15:24
p6eval rakudo 70d908: OUTPUT«Scope not found for PAST::Var '$foo' in x␤current instr.: 'parrot;PCT;HLLCompiler;panic' pc 146 (src/PCT/HLLCompiler.pir:102)␤»
masak rakudo: class A { has $!foo; method x { my $foo = 7; say $foo } }; A.new(:foo(5)).x
p6eval rakudo 70d908: OUTPUT«7␤»
15:25 justatheory joined
masak if what S02:1402 says is true, the first should print 5, and the second should at least give a redeclaration warning. 15:25
masak submits rakudobug
(but I hope S02:1402 is wrong) 15:26
is it possible that the '(mapped to $foo though)' comment should really be on the table row talking about $^foo, not $!foo ? 15:29
15:30 cas joined
jnthn masak: I think Rakuod is right here. 15:33
You'd have to say "has $foo" to get $!foo and $foo
Unless there's been a recent spec change. 15:34
masak S02:1402 simply says "mapped to $foo".
something's gotta give.
jnthn $!foo is mapped to $foo? :-S
masak as I keep saying, I sure hope not.
but S02 says so, clearly. 15:35
masak does svn blame
jnthn I've no idea what it means.
per S12
masak it means that $!foo is mapped to $foo, according to S02. :)
jnthn has $brain; # also declares $!brain;
OK, then I'm going to say S02 is wrong/unclear. 15:36
Suggest mail to language list.
masak OK.
will do.
jnthn S12 has been clear on this for quite a while...I suspect it's more likely typo/braino...
Thanks. 15:37
15:38 pmurias joined
Nom- Ugh. What I wouldn't give for a native Perl driver for DB2... it'd make things so much less painful :( 15:39
s/native/pure perl/
TimToady S02 is wrong 15:53
Matt-W TimToady: hurrah! I assume you refer to the $!foo $foo mapping thing 15:54
PerlJam gosh I hope so 15:55
Matt-W Clearly the populace wants it to be wrong in that respect :)
jnthn Oh noes...actions.pm makes use of List...and worse, treats them as mutable... 15:56
TimToady *I* want it to be wrong; I don't want people writing $foo when they mean $!foo, which is why they have to declare it that way if they want it 15:57
I think S02 meant "is mappable to $foo" 15:58
not that that's the default
jnthn *nod*
s/mapped/mappable/ would clear it up, I think
15:59 eternaleye left
pugs_svn r25523 | lwall++ | remove confusing sidenote 16:02
16:03 hercynium joined
jnthn That clears it up too. ;-) 16:04
16:05 alexn_org joined
masak rejects his own rakudobug 16:10
16:11 icwiener left 16:18 M_o_C joined
pmichaud hello, all. 16:23
back from trip.
alester If I ignore a commit in the fork queue, I'll still get it when it gets applied to rakudo/rakudo, right?
jnthn pmichaud: Welcome back.
Hope trip went smoothly/ok etc. 16:24
pmichaud yes, it did go fairly smoothly. Very enjoyable. I didn't get much chance to work on Rakudo, though. :-|
time to rectify that. :-)
jnthn :-) 16:25
I'm digging in to make List have a ResizablePMCArray for storage, rather than inherit from it.
pmichaud okay.
jnthn And found...well...the nastiness you predicted. ;-)
I wish you were wrong sometimes. :-)
masak welcome back, pmichaud. 16:26
when's release day? :)
pmichaud still may be tomorrow.
masak cool.
pmichaud might be late tomorrow, but tomorrow is still my target.
masak aye.
pmichaud when planning tomorrow as the release day I had taken into account that I might not get much done over the weekend. :-)
jnthn pmichaud: One Bad Thing was that we were using Rakudo's List class in various places in actions.pm 16:27
pmichaud I'm surprised about that
jnthn This was bad not only because we want to compile List...
...but also because we were treating it as mutable!
pmichaud where is List being used in actions.pm ?
jnthn One call to list() but mostly because @?BLOCKS was a List and not an RPA 16:28
(Set up in perl6.pir, but used in actions.pm...)
pmichaud oh. @?BLOCKS can be an RPA.
jnthn Ok, that's what I figured, so I fixed that up. Apart from...when you call .list() on an RPA it turns itself into a List. :-| 16:29
for +@($thingy) { } now turns $thingy if it's an RPA into a List.
pmichaud yes, that does make things more difficult.
jnthn That's my current sticking point.
pmichaud make @?BLOCKS into something inherited from RPA that returns self for .list 16:30
16:30 rindolf joined
pmichaud for that matter, @?BLOCKS could be a PCT node or a Match object. 16:31
we just need something that honors .push and .pop
and .list
jnthn Aye
That would save creating some other class.
Any preference wish one?
pmichaud PCT::Node sounds like a good choice. or PAST::Node 16:32
jnthn ok
pmichaud heck, I bet it could even be Capture
jnthn The Parrot Capture?
pmichaud yes.
since that's what PCT::Node inherits from.
jnthn fail 16:33
Method 'unshift' not found for invocant of class 'Capture'
pmichaud weird.
oh, yes, that actually makes sense. 16:34
jnthn Isn't it PCT::Node that adds those?
pmichaud okay, try PCT::Node.
I'm thinking perhaps Capture should have them, the same way that RPA does.
but let's go with PCT::Node for now.
it's a relatively minor point at the moment.
16:35 eternaleye joined, Tene joined
jnthn pmichaud: Ah, I know have "get_number() not implemented in class 'Capture'" 16:39
pmichaud I suspect somewhere we have +$list 16:40
+@($list) should work though.
or we can add get_number to PCT::Node 16:41
jnthn Yeah, trying that...
16:41 riffraff joined
jnthn pmichaud: Am pondering doing Rakudo day tomorrow - does that work at all for you? 16:41
pmichaud yes. 16:42
jnthn OK, great.
pmichaud any day this week works.
jnthn It's awkward doing it any other day...
pmichaud okay, we'll go with that. I may be doing release-ish types of things tomorrow, but I don't think that'll be an issue.
jnthn Thursday will be a bit tied up with trip-prep, Friday I'm traveling etc.
Sure - I can always do stuff in a branch if needed.
I'm doing this current bunch of refactors in a branch. 16:43
May focus on more bug fixes tomorrow though, to make a better release. :-)
pmichaud good plan.
masak yay, bug fixes! 16:45
jnthn Yeah 16:47
masakbugs-- ;-)
masak :P
you'll need it. :)
16:47 Tene_ left
jnthn pmichaud: Ah, epic fail :-( 16:48
masak one strange effect of submitting most bug reports is that jnthn's bug fix blog posts seem eerily familiar. I'm reading them and going "why, this sounds a bit familiar. and this... and this. has someone been reading my thoughts lately?"
jnthn Match nodes contain...a ResizablePMCArray.
pmichaud jnthn: oh yes, that's an issue. 16:49
maybe we fix it so that .list on RPA returns self.
the other possibility is to have duplicate methods in place
jnthn I'll just do that.
And handle the fallout of it later. 16:50
pmichaud note that having .list on RPA return self will epic fail in other areas.
16:50 mikehh left
jnthn Sure, but it might at least get us through the compile. ;-) 16:51
16:51 mikehh joined, jan_ left
pmichaud the other possibility is to write the minimum methods needed for stage 1 compile in PIR. 16:51
and then let the settings .pm stuff override those when it's included. 16:52
16:52 masak left
moritz_ the more methods we write in Perl 6 the slower the compiler becomes 16:52
jnthn Yes, true, I did ponder something like that...
pmichaud moritz_: the slower the compiler becomes? afaik, right now the compiler isn't using any of the settings methods. 16:53
moritz_ pmichaud: I mean overall execution speed
jnthn get_iter() not implemented in class 'Capture'
*sigh*
moritz_ 2% slower for the test suite after converting .split and .comb to setting/
pmichaud I'm curious about the .split conversion -- what's going on in Any.split? 16:54
I'm also wondering why it would be that much slower -- is .split used a lot?
16:54 jan_ joined
moritz_ pmichaud: it re-dispatches to the Str.split methods 16:54
pmichaud moritz_: shouldn't the Str.split methods be in Any, then? 16:55
moritz_ pmichaud: I thought that was cleaner than cramming Any.pm with all methods that go into any
pmichaud: but I can also move them
whatever you prefer
pmichaud methods belonging to any definitely go in Any.
moritz_ ok.
pmichaud that said, it's okay with me if we have Any-str.pm, Any-num.pm, Any-list.pm, etc.
moritz_ ok, I've prepared the move, just waiting for the spectests to commit 16:59
pugs_svn r25524 | hinrik++ | [url/perl6.vim] kill the + twigil 17:02
literal url? typo..
17:05 eternaleye left
jnthn Ahhh...I makes it through the compile. 17:05
17:05 ludan left
[particle] wonders what it would take to get 10k tests by rakudo's first independent release 17:06
moritz_ [particle]: about 3k more passing tests
[particle] oh, right, i hate the regular test harness
Files=314, Tests=9301, 1171 wallclock secs ( 0.87 usr + 2.84 sys = 3.72 CPU)
of course, that's not 9301 passing tests 17:07
i don't know how many are passing, but not todo/skip
sigh.
moritz_ that's not so good, but at least it runs the tests in parallel
[particle] not here, 1171s is 19+m 17:08
moritz_ I don't understand that... if I move .split to Any-str.pm, I get type check failures 17:19
for the first parameter
even though there's a multi with Any of the type
so it means that it not participates in multi method dispatch correctly 17:20
jnthn Hmm. Odd. 17:21
moritz_ I pushed the branch move_split_to_any_str to github 17:23
if you want to take a look
jnthn: nopaste.snit.ch/15707 17:28
17:28 mikehh left
jnthn moritz_: Ooooh! 17:28
Yes. :-(
moritz_ that's very parrotish dispatch 17:29
17:29 mikehh joined
jnthn No, it's an incompleteness in multimethod dispatch in Rakudo. :-( 17:29
I'll try and solve it tomorrow. 17:30
17:30 aindilis joined
pugs_svn r25525 | moritz++ | [t/spec] tests for calling multi methods of parent class 17:34
moritz_ jnthn: added a test, opened a ticket
jnthn moritz++ # thanks!
pmichaud yes, this is a fairly big issue with Parrot multimethod dispatch. methods in subclasses override _all_ methods of parent classes. 17:35
jnthn pmichaud: AFAIU MMD is bredth-first.
17:35 dukeleto left
pmichaud so as far as Parrot is concerned, Bar's "a" method completely hides any "a" methods of its parents. 17:35
jnthn So if we find something that matches we run it, if not we look further up...
moritz_ still the error message in the move_split_to_any_str is "parameter type check failed", which still seems to be a different beast 17:36
pmichaud jnthn: that's not been my experience with Parrot's dispatch.
jnthn pmichaud: No, that's a Parrot dispatch issue, but we have our own dispatcher. ;-)
pmichaud oh, okay.
if we're using our own dispatcher (and yes, we are), then jnthn++ will undoubtedly have it fixed.
jnthn So in theory it's going to be a straightforward fix.
pmichaud: On our dispatcher - just trying to make something that works now, but we'll undoubtably optimize the heck out of it further down the line. :-) 17:37
pmichaud jnthn: yes, that works for me.
jnthn pmichaud: Is the README on your list of documents you planned to update/tweak?
pmichaud jnthn: yes.
but patches are welcome.
moritz_ pmichaud: do you plan to blog about us having a prelude? if not I might do it within the next two days 17:38
pmichaud yes, I'm blogging that as well.
moritz_ ok, then I'll pick a different subject
pmichaud I'm blogging the new build sequence, prelude, and release.
jnthn I scribbled a little on that, but someone replied with...
www.rakudo.org/2009/02/rakudo-built...be-wr.html # see comment 17:39
Wanting a kinda "plan"
TimToady by the by, I'm not stuck on the @?BLOCKS interface if something more functionish would make more sense
17:39 justatheory left
pmichaud TimToady: no problem -- @?BLOCKS is just our punned version of the variable internally anyway. 17:39
TimToady it's a synthetic variable at the best of times, I suspect
[particle] @?BLOCKS.pick.() #whee! 17:40
pmichaud jnthn: yes, I saw the request for a 'plan', which is why I'm planning to blog my vision for the plan.
TimToady: yes, a more functionish interface might be nice, though.
jnthn pmichaud: OK, excellent. 17:41
pmichaud that said, my 'plan' is likely to be less structured than some would like at this point.
17:41 justatheory joined
TimToady in STD I found that trying to shadow OUTER:: linkage with @?BLOCKS was kinda bogus 17:42
pmichaud my limited experience in Rakudo matches yours there.
moritz_ somehow planetperlsix didn't pick up jnthn++'s rakudo.org blog post 17:43
TimToady so paint @?BLOCKS et al. as somewhat deprecated
diakopter tried perl Configure.pl --gen-parrot 17:44
C:\strawberry\perl\bin\perl.exe tools\build\c2str.pl --all 17:46
src\string\api.c
In file included from config/gen/platform/win32/threads.h:9, from ./include/parrot/parrot.h:274, from src\string\api.c:26:
./include/parrot/thr_windows.h:128: error: redefinition of `struct timespec'
mingw32-make: *** [src\string\api.o] Error 1
jnthn Hmm...I'm sure when I built with strawberry it found - somehow - cl and nmake... 17:50
Were you building in the Strawberry command line shell etc? 17:51
And are nmake and cl in your path?
diakopter nmake is
not cl, yet.
I'm using nmake.exe 7.10.3077 btw 17:52
pugs_svn r25526 | moritz++ | [t/spec] include ticket information in fudge message 17:53
17:56 Whiteknight joined
[particle] with strawberry, you should use mingw32-make and gcc 17:56
cl and nmake shouldn't be in your path
17:58 alexn_org left
diakopter [particle]: about that error I pasted above (when using mingw32-make and gcc) 17:59
is that a parrot bug fixed in some later revision? 18:00
(than the one co'd by --gen-parrot)
jnthn Hmmm...not so sure.
When I built with Strawberry Perl on my laptop, I'm almost certian I ended up using nmake and cl...
[particle] no sure either. i'm having usb device trouble atm preventing me from printing a contract, so i need to suspend all my VMs. can check later 18:01
diakopter can rakudo (current git) not be used with parrot svn? 18:03
[particle] you can use parrot head with rakudo head
diakopter ok 18:04
[particle] build parrot head, git clone in languages/rakudo
pmichaud that's not the recommended build at the moment, fwiw 18:05
the recommended rakudo build is: git clone rakudo, then perl Configure.pl --gen-parrot
especially since Parrot trunk has had some breakages lately. 18:06
diakopter pmichaud: I did that... see above
pmichaud oh sorry, didn't see that part.
PerlJam pm: --gen-parrot doens't just checkout HEAD?
pmichaud PerlJam: no.
PerlJam cool.
pmichaud that's the whole point of --gen-parrot.
it does a checkout of whatever is in build/PARROT_REVISION
PerlJam will have to start playing with rakudo again 18:07
pmichaud diakopter: are you able to build Parrot at all on your system -- e.g., from a svn checkout of Parrot?
diakopter a problem with pinning to a particular svn revision (without post applying patches, I suppose) is for situations like this where the parrot build fails and the build might be fixed in a later revision 18:08
pmichaud diakopter: then we just re-pin.
diakopter pmichaud: checking out parrot HEAD now
heh, and I guess I'm getting all branches/tags too :P
pmichaud but the point of build/PARROT_REVISION is that it should only be updated to a version of Parrot that is known to work/be stable. 18:09
For example, I don't think the recent handling of the changes to the String PMC was really done properly.
but that's probably because we're still learning about our new development configurations. 18:10
18:10 rindolf left
diakopter while all of parrot SVN is checking out, I'll try removing gcc/ming32-make from PATH and configuring parrot rPARROT_REVISION 18:12
pmichaud we likely need our committers to be very wary of making updates to PARROT_REVISION (or things that depend on a new version of Parrot)
diakopter: faster is to just check out /trunk
checking out the entire repository is likely to take a very long time.
[particle] diakopter: you mean remove msvc/cl from strawberry path?
diakopter [particle]: no I'd like to try it jnthn's way first since it didn't seem like cl/nmake were affecting parrot configure's selection/use of gcc/ming32-make 18:15
inter::progs - Determine what C compiler and linker to use...Compilation failed with 'cl' 18:19
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86
18:19 riffraff left 18:20 Psyche^ joined
jnthn diakopter: Maybe things would be easier with ActivePerl... 18:21
pugs_svn r25527 | lwall++ | clarify what happens when associativity conflicts arise 18:23
r25527 | lwall++ | allow both tighter and looser at the same time
r25527 | lwall++ | remove all the synthetic @? variables; use the symbol tables directly
[particle] parrot/rakudo on strawberry perl used to just work.
jnthn Yeah, it did for me not long back too...
[particle] restarts 18:24
18:25 [particle] left
diakopter well, maybe it's just rPARROT_REVISION. trying from HEAD now 18:27
build failed at the same spot 18:29
diakopter goes to download activeperl 18:31
pugs_svn r25528 | rhr++ | [S28] we don't have both $*IN and $*STDIN etc. 18:34
18:36 alexn_org joined, Patterner left, Psyche^ is now known as Patterner 18:43 [particle] joined
diakopter jnthn: you were right; it was a 64-bit issue... well, several. three things had to align properly. I needed to be running under the 32-bit cmd.exe (WINDOWS\SYSWOW64\cmd.exe), I needed to have run the 32-bit VC env vars batch script, and I tried ActivePerl 32-bit, not 64-bit (which I tried first). However, now that parrot tried to Configure and nmake using cl, it died with nearly the exact same error. 18:57
pmichaud: see ^
C:\Perl\bin\perl.exe tools\build\c2str.pl --all src\string\api.c 18:58
C:\Users\xxxxxxx\source\parrot\trunk\include\parrot/thr_windows.h(128) : error C2011: 'timespec' : 'struct' type redefinition
C:\strawberry\c\include\pthread.h(307) : see declaration of 'timespec'
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2'
jnthn Erm, huh...it's lookinf at pthread.h from Strawberry when building with cl?! 18:59
diakopter no; c:\Perl\bin\perl.exe is activestate 32-bit 5.10
strawberry/gcc are nowhere in the PATH 19:00
jnthn no
C:\strawberry\c\include\pthread.h(307)
diakopter oh, hrm
jnthn I suspect it's this include that's the issue...
diakopter so it's not PATH
yeah INCLUDE
oh, and LIB 19:01
.... nmake realclean 19:02
[particle] rafb.net/p/c3DxQG57.html 19:04
diakopter [particle]: neat, thanks. 19:06
19:12 jferrero left 19:17 M_o_C left, M_o_C joined 19:23 preflex left 19:24 preflex joined 19:32 pmurias left
jnthn pmichaud: Turns out List and Array not being a ResizablePMCArray really does turn up a *lot* of stuff... :-| 19:34
pmichaud jnthn: I figured that might be the case. 19:35
jnthn It's taken me this long to only fail two sanity tets. :-|
19:35 barney joined
jnthn The test harness does run though. 19:35
pmichaud we also have to consider what might happen when we do type mapping, as well. 19:36
jnthn Eurgh.
Yes.
We're in *so* many places assuming it's OK to treat List as mutable.
pmichaud well, that's easily fixed by changing to Array
jnthn Fixing various of them to now deal with the underlying storage...
Sure, but a lot of the cases are things that construct a List. 19:37
pmichaud fine, we just promote it to an array.
jnthn For even, say, things like split?
pmichaud not in the function, but in the return value.
er, that's unclear.
when something calls 'split', we promote the result into an array -- exactly as we would do for Perl 6. 19:38
i.e., $P1 = $P0.'split'(...); $P1 = $P1.item();
or something like that.
jnthn I meant more that there are things that construct a list internally. 19:39
in PIR we're doing a lot of
$P0 = new 'List'
push $P0, 42
pmichaud so, change that to 'Array'
jnthn That's the preferred option? OK.
pmichaud still better would probably be 19:40
$P0 = new 'Array'; $P0.'push'(42)
jnthn Yes
pmichaud even better might be (someday) $P0 = 'Array'(42)
jnthn OK, I'll have a review and clean up all these things.
Even better would be that much of the stuff that's written in PIR won't be.
pmichaud exactly. 19:41
but this is part of the reason I haven't been pushing to clean up such things in PIR, because I'm hoping a lot moves to p6.
jnthn You're right though - using Array and .push makes the code in PIR now closer to what the Perl 6 will be.
Yeah, but trying to change the structure of Array and List *and* move them to Perl 6 at the same time feels too risky and too hard to me.
pmichaud sure, that makes sense. 19:42
which is also why I was saying we want baby steps :-)
PerlJam so, what will be left in PIR?
pmichaud PerlJam: things that don't easily map to Perl 6, or where efficiency is a major concern 19:43
19:43 IllvilJa left
PerlJam that's the obvious answer :-) I guess I was looking for an example. 19:44
jnthn infix:does ;-)
pmichaud infix:+
sorry, infix:<+>
jnthn sorry, infix:<does>
;-)
[particle] BEGIN {...} 19:45
pugs_svn r25529 | lwall++ | initial whack at describing how settings are snapshotted 19:58
r25529 | lwall++ | and how they interact with invocation of MAIN for settings
r25529 | lwall++ | that want to install flow control around the user code.
19:59 IllvilJa joined 20:03 barney left 20:06 alexn_org left 20:08 arthurium joined
arthurium perl6: say (6*3)/1*(1) 20:08
p6eval elf 25529, pugs, rakudo 70d908: OUTPUT«18␤»
arthurium perl6: say (6*0x3)/1*(1) 20:09
p6eval elf 25529, pugs, rakudo 70d908: OUTPUT«18␤»
arthurium perl6: say (6*0x103)/1*(1)
p6eval elf 25529, pugs, rakudo 70d908: OUTPUT«1554␤»
20:11 justatheory left, justatheory joined 20:20 alexn_org joined
jnthn observes the massive fail 20:28
diakopter std: say (6*0x3)/1*(1) 20:32
p6eval std 25529: OUTPUT«ok 00:02 33m␤»
20:47 Ariens_Hyperion joined
TimToady what massive fail? 0x103 is a hex number 20:51
PerlJam doesn't get it either 20:52
20:53 icwiener joined 20:57 ruoso joined, kane_ joined 20:59 duke_leto joined, Whiteknight left 21:02 Ariens_Hyperion_ joined
bacek good morning 21:02
perl6: my $a = 42; $a min= *; say $a
p6eval pugs: OUTPUT«*** ␤ Unexpected "min"␤ expecting operator␤ at /tmp/xapqXVSFcc line 1, column 16␤»
..rakudo 70d908: OUTPUT«Multiple Dispatch: No suitable candidate found for 'cmp', with signature 'PP->I'␤current instr.: 'infix:cmp' pc 15790 (src/builtins/cmp.pir:146)␤»
..elf 25529: OUTPUT«Unknown rule: infix_postfix_meta_operator:=␤It needs to be added to ast_handlers.␤ at ./elf_h line 2042␤»
21:03 duke_leto left
diakopter pmichaud: as a (temporary? permanent?) workaround for the http url /->\\ problem in Makefile.in, put the trailing 't/spec' on the next line, and qualify the Configure.pl replacer line with 'unless $maketext =~ /pugscode/' or something...? 21:14
ruoso std: my ($x, $y, $eps); if $x ~~ [..] $y ± $eps { ... } 21:15
lambdabot ruoso: You have 1 new message. '/msg lambdabot @messages' to read it.
p6eval std 25529: OUTPUT«############# PARSE FAILED #############␤Unable to parse array composer; couldn't find final ']'␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range at /tmp/JmLl8Est45 line 1:␤------>
..[32...
21:15 Ariens_Hyperion_ left
pmichaud diakopter: noted, thanks. I'll be looking at that shortly. 21:15
ruoso @tell pmurias re metaclass creating new objects instead of forcing p6opaque: You're absolutely right. 21:16
lambdabot Consider it noted.
ruoso isn't the range constructor an infix?
std: my ($x, $y, $eps); sub infix:<±> {...}; if $x ~~ [..] ($y ± $eps) { ... } 21:17
p6eval std 25529: OUTPUT«############# PARSE FAILED #############␤Unable to parse array composer; couldn't find final ']'␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range at /tmp/rt5vPBqgm3 line 1:␤------>
..[32...
TimToady it *should* have said: Can't reduce a nonchaining operator because it's diffy and not chaining 21:19
21:19 Ariens_Hyperion left
diakopter I'm not getting any output from rakudo's nmake spectest or nmake test... how do I diagnose this? 21:20
I *do* get output from nmake codetest 21:21
pugs_svn r25530 | lwall++ | [STD] reign in an overreaching [1..] check 21:22
TimToady std: [..] 1,2,3 21:24
p6eval std 25529: OUTPUT«############# PARSE FAILED #############␤Unable to parse array composer; couldn't find final ']'␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range at /tmp/vX50nGwoxD line 1:␤------>
..[32...
TimToady twiddles his thumbs
pmichaud diakopter: did t/spec get checked out? 21:25
i.e., is the t/spec directory populated?
diakopter yep 21:26
pmichaud was perl6.exe built?
diakopter yep
`C:\Perl\bin\perl.exe t\harness --fudge --keep-exit-code --jobs --tests-from-file=t\spectest.data` spins for a few seconds, but nothing on stdout 21:27
pmichaud does parrot/parrot.exe exist?
diakopter nope; I built it elsewhere b/c I was building from trunk
HEAD I mean
pmichaud ah. I suspect the harness isn't finding parrot.exe then.
and we haven't switched the harness to use the perl6.exe yet. 21:28
diakopter hm. I'll try adding BUILD_DIR to my PATH
pmichaud I think it currently looks explicitly for ..\..\parrot and parrot\parrot
i.e., I don't think it checks the path yet.
I'm working on an updated harness to fix this, but haven't checked it in yet.
diakopter (adding parrot.exe's location to the PATH didn't help) 21:29
pmichaud right, the t/harness file still requires Parrot's Test::Harness
as I said, I'm working on fixing that... but anyone else that wants to do it is very welcome to do so :-) 21:30
TimToady std: [..] 1,2,3 21:31
p6eval std 25530: OUTPUT«############# PARSE FAILED #############␤Unable to parse array composer; couldn't find final ']'␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range at /tmp/jdEKPB3mlo line 1:␤------>
..[32...
TimToady twiddles his thumbs more
pmichaud the revision number says it updated
TimToady actually, /me revises the patch... 21:32
pmichaud i.e., it now says r25530 instead of r25529.
ah.
ruoso TimToady, so... I'm a bit lost... 21:34
is "[..] 1,10" ok?
or in a more usefull way... 21:35
is "[..] something()" ok?
and... more to the point ;)
is "[..] $x ± $eps" ok?
TimToady no, you need to say &[..](|($x ± $eps)) for an operaotr like .. 21:37
21:37 mikehh left 21:38 ZuLuuuuuu joined
ruoso TimToady, hmm... even if the operator does return a list of two values? 21:38
(the other operator, not ..) 21:39
PerlJam [..] 1,10 I think I can grok, but I'm not sure what to make of [..] 1,10,20
ruoso PerlJam, [..] 1,10,20 would fail because there isn't a candidate for infix:<..>($more,$than,$two_values) 21:40
diakopter std: &[..](2,1)
p6eval std 25530: OUTPUT«############# PARSE FAILED #############␤Can't understand next input--giving up␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range at /tmp/cnKoBTDgAF line 1:␤------>
..&[..](2,1)...
TimToady that's why I'm revising the patch :)
ruoso TimToady, but my point is that if something() does return a list of two values? why can't I use the reduction with it? 21:41
TimToady because I'm a mean bastare
*bastard
21:41 alester left
TimToady grr! 21:41
PerlJam TimToady: what if the arity of something were explicit?
(or whatever you call the return list) 21:42
pmichaud ...is there a candidate for infix:<+>($more, $than, $two_values) ?
21:42 pmurias joined
pmurias ruoso: hi 21:42
lambdabot pmurias: You have 1 new message. '/msg lambdabot @messages' to read it.
ruoso TimToady, you mean that in terms of parsing or runtime? because in terms of runtime I didn't expect infix:<..> to be different from any other
pmichaud, infix:<+>(*@items) as the associativity of some infix has changed 21:43
TimToady then you can always call reduce &[..], whatever
pmichaud ruoso: has that made it into a spec somewhere?
pmurias ruoso: how do we call the protoobject creation method? create_protoobject?
ruoso pmurias, no... simply CREATE
[particle] what about Range(*@list)
TimToady std: Range(*@list) 21:44
p6eval std 25530: OUTPUT«############# PARSE FAILED #############␤Unable to parse argument list; couldn't find final ')' at /tmp/T3QRIBv76X line 1:␤------> Range(*@list)␤ expecting any of:␤ POST␤ infix or meta-infix␤ infix stopper␤ postfix␤
..postfix_prefix_meta_operator␤ standard stopper␤...
ruoso pmichaud, it made into STD iirc
[particle] hrmm
std: Range(@list[0,1]) 21:45
p6eval std 25530: OUTPUT«Potential difficulties:␤ Variable @list is not predeclared at /tmp/eQlttHiVhU line 1:␤------> Range(@list[0,1])␤ok 00:02 34m␤»
ruoso pmurias, I mean... $how.CREATE, not $obj.CREATE, of course
TimToady [particle]: that would depend on whether Range knows how to coerce a list to minmax 21:46
[particle] yep, it sure would.
ruoso one could argue that to be a very nice feature of Range
pmichaud ruoso: STD.pm seems to still indicate infix:<+> as being :assoc(left)
[particle] so, i wonder....
21:46 M_o_C left
pmichaud or am I looking in the wrong place? 21:46
ruoso pmichaud, I might be wrong... it's just something I remember... 21:47
TimToady ruoso: we restrict syntactic reduce operators to those that make sense when used n-ary, since other use might well indicate a braino
and because your trick is too cute to live :)
pmichaud ruoso: I remember it being speculated, but I didn't see any official changes come through. (otoh, I havent been following _every_ change so it's entirely possible I've overlooked it)
ruoso TimToady, I wasn't even thinking about it as a trick... it just felt as a natural use of the reduction operator... I didn't meant a trick... 21:48
pmichaud I'm very familiar with the "too cute to live" side of things :-)
pmurias ruoso: one thing i'm not sure how to do cleanly is defining things like infix:<+>:(int,int)
PerlJam ruoso: it feels bizarre to me if natural to you :)
ruoso it has been said that I think sideways... 21:49
pmurias it needs to be written in C for now, and yet has to .FETCH it's arguments
TimToady if you're going to call a function with two arguments, call the function
ruoso TimToady, I was also expecting [..] to DWIM
i.e.: call minmax 21:50
pugs_svn r25531 | lwall++ | [STD] revise previous patch to allow &[..]
jnthn That feels...odd.
TimToady ruoso: I'm doing your readers a favor :)
ruoso pmurias, I've been using a trick there... which is to define a function in mold that would call another function in C after doing the FETCHs 21:51
jnthn But @x ==> { *.min .. *.max } or similar ain't so bad. :-)
ruoso TimToady, well, if I do think sideways... I think I shouldn't complain about that ;)
TimToady :) 21:52
21:52 skids left
TimToady we don't allow ..= either 21:52
pmurias ruoso: wouldn't that cause a lot of boilerplate for every function?
ruoso pmurias, only for the ones we're going to define that way
which are not supposed to be many
[particle] .. is too fiddly 21:53
ruoso TimToady, ahhhh.... I already had code using it ;) ;) ;)
pmurias ruoso: all the arithmetic operators on native integers
TimToady too diffy, actually
meaning the type of the result differs from the arguments
[particle] ah, right. 21:54
my $x = 3; $x ..= 5; # diffy
21:54 r0bby_ is now known as r0bby
ruoso pmurias, but if you think about it... it's the same boilerplate that Perl 6 will do everytime... 21:54
pmurias, so no much harm
TimToady std: [..] 1,2,3 21:55
p6eval std 25531: OUTPUT«############# PARSE FAILED #############␤Can't reduce a nonchaining operator because it's diffy and not chaining at /tmp/4GDs6vLxs1 line 1:␤------> [..] 1,2,3␤ expecting prefix_circumfix_meta_operator__S_081reduce␤FAILED 00:02 33m␤»
[particle] how can i create a type that curries a value, like: my RangeFrom10 $x .= new 50;
ruoso pmurias, of course it would be cute if we had something in the RI DSL to generate the code for the binding of the signature...
TimToady std: &[..] |@foo 21:56
p6eval std 25531: OUTPUT«############# PARSE FAILED #############␤Can't understand next input--giving up␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range at /tmp/0qYcrkA5uN line 1:␤------> &[..]
..|@foo...
pmurias ruoso: one alternative i tried in my working copy is to wrap a C int_add with a infix:<+>:(int,int) written in perl 6
TimToady std: &[..](|@foo)
p6eval std 25531: OUTPUT«############# PARSE FAILED #############␤Can't understand next input--giving up␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range␤Please use ..* for indefinite range at /tmp/BqK9FwxHEX line 1:␤------>
..&[..](|@foo...
TimToady I think the lex clobbering timer hasn't gone off yet
ruoso pmurias, indeed... you can have the outer function in Perl 6, not mold...
pmurias, then call a s1p_ccode that receives the actual arguments 21:57
and you do the FETCH in Perl 6
pmurias i'm thinking of adding something like use NATIVE::int :from<C> :header<native_int.h>; 21:59
ruoso pmurias, you don't need to... you just need to have nativeimpl:infix:<+>:(int,itn) available in the lexical scope 22:00
TimToady, I suppose I can add as many parts as I want in my function name by using the ':'
22:01 rob__ joined
ruoso std: sub nativeimpl:infix:<+>:(int,int)($a,$b) {...} 22:01
p6eval std 25531: OUTPUT«ok 00:02 33m␤»
TimToady std: &[..](|[1,2]) 22:02
p6eval std 25531: OUTPUT«ok 00:03 46m␤»
pmurias ruoso: do you think loading them in with use would be better than manually inserting them into the lexical scope/some namespace?
shower&
ruoso pmurias, we eventually could have a SMOP:: package where we store this odd functions and types 22:04
pmurias forgot the hot water is cut off due to repairs of some sort :(
ruoso and then have this SMOP:: package in the lexical prelude
pmurias what i'm unsure if it's better to insert the primitives manually or via a use :from<C> 22:05
ruoso pmurias, let's insert them manually, but inside the SMOP:: package 22:08
I'm not sure what kinds of weirdness we can have from a "use :from<C>"
22:09 Ariens_Hyperion joined
ruoso maybe we could think of something like "use s1p_add_int_int :from<SMOP__S1P__CCode>" 22:09
which is more explicit on what it means 22:10
and it could even check if that symbol is really a s1p_ccode
but I'm not sure implementing the symbol lookup is worth the trouble... 22:11
it's probably better to register the symbols manually
22:23 alester joined
pugs_svn r25532 | hinrik++ | [util/perl6.vim] allow R modifier on reduce operators 22:25
r25533 | pmurias++ | [smop] added PRIMITIVES::int_add and used it to implement infix:<+>:(int,int)
r25533 | pmurias++ | [mildew] remove lamed circular reference breaking
r25533 | pmurias++ | added a noop RoleHOW
pmurias ruoso: do you think the primitives can be defined like that (they should be moved out from lexical_prelude to a seperate file propably)? 22:27
pugs_svn r25534 | pmurias++ | [smop] fixed bug with &PRIMITIVES::int_add 22:29
22:39 ejs left
pugs_svn r25535 | pmurias++ | [mildew] added &infix:<==>:(int,int),&infix:<->:(int,int) 22:42
r25535 | pmurias++ | updated bootstrap.dot
22:45 szabgab joined 22:46 ruoso left 22:50 cas left 22:54 tarbo2 joined 23:02 arthurium left 23:05 mikehh joined 23:09 ZuLuuuuuu left 23:11 icwiener_ joined 23:12 hercynium left 23:15 icwiener_ left 23:23 rob__ left 23:25 Whiteknight joined 23:26 bacek_ joined 23:27 skids joined 23:28 icwiener left 23:36 bigpresh is now known as bigpresh_, bigpresh_ is now known as presh, nihiliad left, presh is now known as bigpresh 23:43 Ariens_Hyperion left, pmurias left 23:47 alester left 23:58 Tene_ joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!