pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, elf: etc.) (or perl6: for all) | irclog: irc.pugscode.org/ Set by Tene on 29 July 2008. |
|||
00:05
bennett left,
explorer__ left
00:09
elmex left
00:29
meppl left
00:30
meteorjay joined
00:34
eternaleye_ left
01:07
Limbic_Region left
01:10
ruoso left
01:15
eternaleye joined
|
|||
speckbot | r14588 | larry++ | Added ~ twiddle macro to make it easier to write bracketing constructs. | 01:16 | |
pmichaud | AIIIIIIIIIE!!!!! | 01:27 | |
that said, ~ (twiddle) is wicked cool, too. | |||
01:28
ab5tract left
01:40
hercynium joined
01:45
mncharity joined
02:01
wknight8111 left
|
|||
mncharity notes the specbot links at the top of irclog.perlgeek.de/perl6/2008-10-06 , to www.perlcabal.org/svn/p6spec/revision?rev=14586 and www.perlcabal.org/svn/p6spec/revision?rev=14587 , yield blank pages. | 02:06 | ||
lambdabot | Title: IRC log for #perl6, 2008-10-06 | 02:07 | |
02:12
alester_ joined
|
|||
mncharity | A curiousity: feather.perl6.nl/syn/S06.html#Flatt...ment_lists says "The | operator flattens lazily -- the array is flattened only if flattening is actually required within the subroutine.". However, it's not just the routine which needs the arguments, the multimethod dispatcher needs them too. So the sentence seems incorrect? And the necessary behavior/spec, more complex. | 02:18 | |
lambdabot | Title: S06 | ||
mncharity | Hmm. Though... I guess the mmd dispatcher could count as "within the subroutine". ok, nm. | 02:19 | |
@tell wayland76 apropos testrole, elf likely currently supports multi infix:<==>. fyi. | 02:30 | ||
lambdabot | Consider it noted. | ||
mncharity | @tell masak re "elf--, rakudo-- # that's just stupid :)", re "my $x; say $x.defined", I've added class Any { method defined { defined(self) } } to misc/elf/elf_h_src/Prelude.pm. Extending the elf prelude is easy. Contributions welcome. | 02:49 | |
lambdabot | Consider it noted. | ||
03:01
s1n left
03:03
alester_ left
03:06
Ontolog joined
03:07
hercynium left
03:13
eternaleye left
03:14
eternaleye joined
|
|||
pugs_svn | r22521 | putter++ | [elf_h] Startup (main) refactored to make Elf derivatives easier. Fixed elf code bugs: missing required arguments; object fields accessed as hash. Added list argument recognition (for on_sbcl). | 03:15 | |
r22522 | putter++ | [elfish/on_sbcl] elfcl runs fib. | 03:28 | ||
mncharity | departing footsteps echo in the empty chamber | 03:31 | |
night shift out. cheers. & | |||
03:31
mncharity left
03:54
agentzh left,
agentzh joined
04:00
mellifluidicpuls joined
04:14
mellifluidicpuls left,
mellifluidicpuls joined
04:19
mellifluidicpuls left,
mellifluidicpuls joined
04:46
justatheory left
04:54
s1n joined
05:06
Psyche^ joined
05:19
zamolxes left
05:21
Patterner left,
Psyche^ is now known as Patterner
05:22
eternaleye left
05:23
BinGOs left
05:24
eternaleye joined
05:29
Bzek joined
05:36
BinGOs joined
05:37
iblechbot joined
05:45
dduncan joined
|
|||
dduncan | I have a grammar question | 05:45 | |
concerning repetition by separator, eg: 'foo' ** ',' ... | 05:46 | ||
I know from S05 that that pattern will match one or more occurrances of 'foo' that are separated by commas ... | 05:47 | ||
my first question is, will that pattern also match zero occurrances? | |||
also, what is the best way to say, repeat by the separator but that there must be at least or at most N matches? | 05:49 | ||
06:23
iblechbot left
06:35
bsb joined
06:50
ashizawa joined,
mellifluidicpuls left
06:54
zamolxes joined
07:05
jferrero joined
|
|||
moritz_ | dduncan: I don't think you can add counts to **, so you have to fall back to 'foo' [',' 'foo']**2..10 | 07:30 | |
07:34
smg left
07:35
cosimo joined
07:49
elmex joined
|
|||
dduncan | moritz_ okay, but my main question, can 'foo' ** ',' match zero occurrances of 'foo', or only 1+? | 07:50 | |
that's what I want to know the most | |||
07:52
pmurias joined
|
|||
pugs_svn | r22523 | pmurias++ | [smop] converted s1p_lexicalscope to RI, and extended the RI language to make it work | 07:52 | |
moritz_ | dduncan: I think it has to match the atom on the left at least once | 07:56 | |
dduncan: not 100% sure though | |||
dduncan | I'll look at S05 again, and if I can't find a definitive answer, I'll ask on p6l | ||
pmurias | dduncan: what's the state of Muldis? | 07:57 | |
moritz_ | "If you supply any other atom (which may be quantified), it is interpreted as a separator (such as an infix operator), and the initial item is quantified by the number of times the separator is seen between items:" | 07:58 | |
dduncan | the language spec is 95% done, the reference implementation about 10% done | ||
moritz_ | and then <ident> ** ',' matches 'foo' | ||
where it's quantified by zero commas | |||
and it matches 'foo,bar' where it's quantified by one comma | 07:59 | ||
so I guess to match the empty string you'd need -1 commas ;-) | |||
dduncan | moritz_ I was under the impression that the commas were just a means of saying that you want to match a bunch of 'foo' | ||
08:00
pmurias left
|
|||
dduncan | say we want to match a list of items, but the list might be empty, and the whole list is delimited by brackets | 08:00 | |
moritz_ | right, but that's not how I read the specs | 08:01 | |
dduncan | now, if the ** syntax in question always matches at least 1 foo, then I would qualify a zero or more list by grouping the whole thing with a []? | ||
which is fine | 08:02 | ||
but if the syntax can match zero or more, I would wonder how to say I want at least 1 | |||
eg, the distinction between * and + | |||
moritz_ | call that *+ ;-) | 08:03 | |
08:04
Ontolog left
|
|||
dduncan | pmurias, so as I said, 95% and 10% ... this next day or 2 I've been focusing on improving the actual grammar (the 'Tiny' dialects), including adding specific syntax for routine and type declarations, so people can write those in a manner like a normal programming language, rather than having to write those indirectly by way of data literals (which the compiler turns the former into) | 08:08 | |
the new version, of PTMD_Tiny at least, would also lend itself much better to support by text editors for syntax coloring and function extraction | 08:09 | ||
I've also been working on a textless language module for BBEdit that would take advantage of taht | 08:10 | ||
08:15
sri_work left
08:16
sri_work joined
08:29
Ontolog joined
08:30
barney joined
08:49
meppl joined
|
|||
meppl | good morning | 08:49 | |
08:58
zamolxes left
|
|||
barney | chromatic++ for www.reddit.com/r/programming/commen...q_eqv_and/ | 09:01 | |
lambdabot | Title: Perl 6 offers no less than eq, ==, eqv, ===, =:=, and ~~ : programming, tinyurl.com/3zvpby | ||
09:05
smg joined
09:14
alanhaggai joined
09:21
masak joined
09:22
barney left
09:25
viklund left
09:26
Alias_ joined,
viklund joined
09:27
Alias_ is now known as adamkennedy
09:50
masak left
10:07
Ontolog left
10:11
Bzek left
10:13
c1sung_ joined
10:17
Patterner left,
meteorjay left,
smtms left,
Lorn left,
jrockway left,
cotto left,
spinclad left,
szbalint left,
nnunley left,
pjcj left,
xinming_ left,
Guest16015 left,
c1sung left
10:18
literal left,
idemal left,
beppu left,
Juerd left,
gbacon left,
ewilhelm left,
obra left,
sunnavy left,
Patterner joined,
meteorjay joined,
smtms joined,
Lorn joined,
jrockway joined,
xinming_ joined,
pjcj joined,
cotto joined,
gbacon joined,
Juerd joined,
literal joined,
sunnavy joined,
obra joined,
Guest16015 joined,
ewilhelm joined,
idemal joined,
spinclad joined,
beppu joined,
szbalint joined,
nnunley joined
10:19
Bzek joined
10:23
ewilhelm_ joined
10:27
ewilhelm left
10:28
tomyan joined
10:30
Juerd_ joined,
Juerd left
10:32
Lorn__ joined,
sunnavy left
10:33
sunnavy joined
10:34
smtms left,
smtms joined,
dduncan left
10:37
meteorja1 joined,
lumi left,
lumi joined
10:38
Lorn left,
meteorjay left
10:47
jrockway left,
jrockway joined
10:48
beppu left,
beppu joined
10:50
nnunley_ joined,
plash_ joined
10:51
szbalint_ joined,
Psyche^ joined
10:52
nnunley left,
szbalint left,
Patterner left,
Psyche^ is now known as Patterner
10:59
literal left
11:00
literal joined
11:02
ewilhelm_ left
11:05
ewilhelm joined
11:13
ewilhelm left,
sunnavy left,
spinclad left,
cotto left,
pjcj left,
xinming_ left,
Guest16015 left,
idemal left,
obra left,
gbacon left,
ewilhelm joined,
sunnavy joined,
xinming_ joined,
pjcj joined,
cotto joined,
gbacon joined,
obra joined,
Guest16015 joined,
idemal joined,
spinclad joined
11:24
Deepi joined
11:34
masak joined
11:37
ewilhelm left
11:39
spinclad_ joined
11:42
BinGOs left
11:44
spinclad left,
cotto left,
pjcj left,
xinming_ left,
Guest16015 left,
idemal left,
obra left,
sunnavy left,
gbacon left
11:46
sunnavy joined,
xinming_ joined,
pjcj joined,
cotto joined,
gbacon joined,
obra joined,
Guest16015 joined,
idemal joined,
spinclad joined,
BinGOs joined
11:47
pjcj left,
pjcj joined
11:50
spinclad left
11:53
ewilhelm joined
11:54
pmurias joined
12:05
pmurias left,
ewilhelm left,
cotto left,
xinming_ left,
Guest16015 left,
idemal left,
obra left,
sunnavy left,
gbacon left,
pmurias joined,
ewilhelm joined,
sunnavy joined,
xinming_ joined,
cotto joined,
gbacon joined,
obra joined,
Guest16015 joined,
idemal joined
12:20
cotto left,
xinming_ left,
pmurias left,
Guest16015 left,
idemal left,
obra left,
sunnavy left,
gbacon left,
ewilhelm left
12:25
pmurias joined,
ewilhelm joined,
sunnavy joined,
xinming_ joined,
cotto joined,
gbacon joined,
obra joined,
Guest16015 joined,
idemal joined,
ewilhelm_ joined
12:29
alanhaggai left
12:30
ewilhelm_ left,
cotto left,
xinming_ left,
pmurias left,
Guest16015 left,
idemal left,
obra left,
sunnavy left,
gbacon left,
ewilhelm left,
Guest16015 joined,
gbacon joined,
xinming joined
12:31
idemal joined
|
|||
moritz_ thinks about a macro prefix:<> is parsed { S+ } { "$_" } | 12:32 | ||
then you could write (escaped) bareword URLs ;) | |||
presumably even with check for well-formedness at compile time ;) | 12:33 | ||
12:43
lisppaste3 left
|
|||
masak | moritz_: neat, but why? :) | 12:43 | |
lambdabot | masak: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
12:43
lisppaste3 joined
|
|||
moritz_ | masak: because we can? | 12:45 | |
masak | @tell mncharity tell mncharity re method defined: cool, re contributions to elf: I'll keep that in mind | ||
lambdabot | Consider it noted. | ||
12:50
ewilhelm joined,
sunnavy joined,
obra joined
12:51
zamolxes joined
|
|||
masak | moritz_: yes, I saw that reason. I was wondering if you had any deeper use for it. also, I thought Perl 6 was sort of moving away from barewords... :) | 12:52 | |
moritz_ | masak: then don't call it "bareword". It's an elaborate quoting construct, of which Perl 6 has more than perl 5 ;) | 12:53 | |
masak | aah. | ||
masak sees it now | |||
great! carry on. | 12:54 | ||
moritz_ | I think the actual use is very little, but it's a nice proof-of-concept of what macros can do | 12:55 | |
masak | aye. | 12:56 | |
13:05
ashizawa left
|
|||
rakudo_svn | r31750 | pmichaud++ | [rakudo]: spectest-progress.csv update: 205 files, 4363 passing, 74 failing | 13:11 | |
moritz_ | wow, google has indexed S11 from perlcabal.org | 13:23 | |
a slightly more permissive robots.txt is very helpful ;) | 13:24 | ||
13:29
plash_ left
13:33
sri_work left
13:52
iblechbot joined
|
|||
TimToady | that would be term:<> | 14:00 | |
14:00
TJCRI joined,
Deepi left
14:01
Deepi joined
|
|||
moritz_ | token term:<> { <sym> \S+ }; # like this? | 14:04 | |
or can you declare macro term:... ? | 14:05 | ||
TimToady | macro term:<> is parsed / <sym> \S+ / | 14:07 | |
but if token it must be term:sym<> instead | |||
the name of the rule is distinguished from the name of the operator | 14:08 | ||
inside the grammar, term:<> would be the operator that the grammar is using, not the one it's parsing | 14:09 | ||
we must make this distinction or we can't parse P6 using P6 | |||
masak 's head spins | 14:10 | ||
14:10
alanhaggai joined
|
|||
TimToady | @tell dduncan yes, you must use []? currrently to get 0 instances of <foo> ** ',' | 14:10 | |
lambdabot | Consider it noted. | ||
moritz_ | .oO( maybe we need #perl6-for-dummies ) |
||
masak | moritz_: oh yes, pretty please! I would be there all the time. | 14:11 | |
TimToady | just cargo cult the rules in STD.pm and you should be fine :) | ||
I'm about to check in the version of STD that uses the new '(' ~ ')' <expr> notation, but still have a few bugs | 14:12 | ||
where it currently has all those ugly <in:...> calls | |||
moritz_ hasn't quite understood that either | |||
masak neither | 14:13 | ||
TimToady | which I want to get rid of because it fills the AST with "in" nodes that are relatively useless | ||
moritz_ | does ~ only counts nesting constructs that are matched by other rules that use ~ ? | 14:14 | |
TimToady | the ~ is actually a kind of parser combinator I stole from Haskell, where it's called 'between" iirc | ||
on first inspection it merele rewrites <a> ~ <b> <c> to <a> <c> <b> | 14:15 | ||
masak | why would one want that? | 14:16 | |
TimToady | but the reason to pull <b> out front in the notation is because you're really setting up the final goal | ||
and it's very important to know the goal in order to know when to quit | |||
and in the absence of finding the goal, what the correct error message is | 14:17 | ||
masak | hm. so this helps in generating better error messages? | ||
TimToady | yes | ||
masak | that's good. | ||
TimToady | as well as passing the terminator down to the intermediate rule | 14:18 | |
masak | ooh | ||
TimToady | in the error messages in the new bit of S05 text, you'll see that it was complaining that it couldn't find ']' | ||
that's the goal that was specified by the ~ | 14:19 | ||
moritz_ | so <c> somhow knows that it expects a <b> as the terminator? | ||
and if so, how? | |||
TimToady | yes, in fact STD currently sets $+GOAL as a context var | ||
masak starts to see the uses of this | |||
TimToady | you can also read ~ as "before b find a c" | 14:20 | |
but there's also the readability issue of putting the two brackets right next to each other | |||
and in a visually parallel construct, which <in:> isn't | 14:21 | ||
nor was the old form with '(' <EXPR> [ ')' || fail ] | |||
moritz_ | aye, that was a real cludge | ||
TimToady | '(' ~ ')' <EXPR> is much clearer | 14:22 | |
masak | yes, and it packages a common idiom, too | ||
TimToady++ | |||
TimToady | well, stole it from Haskell | ||
specifically, parsec | |||
masak | Parsec++, too | ||
TimToady | the one thing that bugs me is that it still isn't really a combinator in the haskellian sense | 14:23 | |
it's really only a macro | |||
but we don't have an easy notation for first class chunks of pattern | |||
masak | maybe that's next :) | 14:24 | |
TimToady | when we do, perhaps ~ will be defined in terms of it | ||
moritz_ | and I thought S05 was pretty stable | ||
TimToady | it's just something I wanted while trying to clean up STD | ||
masak | TimToady: speaking of grammars, if I thought long and hard on how to connect {*} in a particular grammar to a particular class, and then wrote to p6l about it, would there be a chance such a feature could be added to Perl 6? | 14:25 | |
TimToady | um, I'm already doing it | ||
look at viv | |||
masak | viv? | ||
14:25
ruoso joined
|
|||
moritz_ | gimme5 that uses STD | 14:25 | |
TimToady | the vi-to-v translator that will replace gimme5 | 14:26 | |
masak | that's good news | ||
moritz_ | (if I remeber the commit message correctly) | ||
TimToady: any thoughts on www.nntp.perl.org/group/perl.perl6....29636.html ? | |||
masak | is that written in Perl 6? | ||
lambdabot | Title: [PATCH] How to match against a grammar - nntp.perl.org, tinyurl.com/4rcksm | ||
TimToady | not yet | ||
masak | TimToady: then does it really count? | ||
moritz_ | ah well, it's not pressing | ||
TimToady | not yet | ||
ruoso | hi! | ||
TimToady | not yet! | ||
moritz_ | ;) | 14:27 | |
masak | I mean, is there a strategy for how to syntactically connect a grammar and a class in Perl 6? | ||
not yet... :/ | |||
that's what I was planning to propoe | |||
propose* | |||
TimToady | all I do currently is set a context var to the class or object I want to call reduction actions in. | 14:28 | |
with a name constructed from the {*} tag | |||
that seems quite general | |||
masak | TimToady: a context var in the grammar? | ||
TimToady | a context var set in the code calling the grammar | 14:29 | |
again, see viv | |||
masak | oki | ||
TimToady | a context var in Perl 5 looks like $::ACTIONS because it's just emulated with local | ||
masak | ah. | ||
pugs_svn | r22524 | moritz++ | vim modeline for viv | ||
TimToady | ruoso: btw I am seriously considering merging $+foo with $*foo now | 14:30 | |
masak | actually, the end goal would be not to have to write tree traversal code in a class that uses a grammar | ||
ruoso | TimToady, with or without falling back? | ||
TimToady | with considering GLOBAL to automatically be contextual unless declared otherwise | 14:31 | |
ruoso | ok, so the global variables declared by the prelude are visible as contextual | 14:32 | |
TimToady | yes, by and large, haven't thought about whether I want any exceptions | ||
ruoso | as opposed to having the contextual lookup falling back to global lookup | 14:33 | |
TimToady | well, depends on whether you just count GLOBAL as outermost lexical | ||
(well, unless there's PROCESS, which is outside GLOBAL) | |||
but the context lookup might not even know it's getting into a symbol table that is also considered a top-level package | 14:34 | ||
so not "fallback" in the cognitive sense, at least | 14:35 | ||
ruoso | I wasn't planning GLOBAL to be the outermost lexical | ||
I was planning "prelude" to be the outermost lexical | |||
and "prelude" "use" the builtin | |||
TimToady | maybe prelude can set up more than one level of outer lexical...hmm... | 14:36 | |
down 18 levels of brackets, we find a little call to the insert_user_code_here() macro... | 14:37 | ||
and maybe prelude is really wrapper | |||
so it's also postlude | |||
ruoso | oh... wait... | 14:38 | |
there are two senses of prelude here.. | |||
TimToady | much like p5 used to wrap programs in a loop when you use -p or -n | ||
ruoso | one which is the code that invoke the actual program | ||
and other which is the outermost scope | |||
TimToady | good question whether they need to be or even should be distinct | 14:39 | |
ruoso | the good thing about they being distinct is that every new file shares this same object as the outermost scope | ||
TimToady | but I would argue that part of the definition of a language is specifying how the parse tree is handled at the end | ||
"every new file"? no, every file in a given language | 14:40 | ||
different languages have different preludes | |||
14:40
eternaleye left
|
|||
TimToady | preludes/postludes | 14:40 | |
ruoso | actually... every "STD Perl 6 comp_unit" | ||
TimToady | well, if we don't give them the opportunity to tweak the calling code, then it's immutable at least by convention | 14:41 | |
but we want to change it ourselves with new versions of Perl 6 | |||
but I think prelude as wrapper would be an easy thing for people to grok | 14:42 | ||
ruoso | ok, maybe the prelude scope is itself a contextual var (at the time of "use") | ||
14:44
jhorwitz joined
|
|||
TimToady | maybe use treats the calling code as prelude wrapper for the called module | 14:44 | |
no, that won't work | 14:45 | ||
violates audreyt's separate compilation concerns | |||
ruoso | TimToady, one thing is "ultimate outer scope" and the other is "ultimate caller scope" | ||
"outer" and "caller" are different axes in variable lookup | |||
TimToady | yes, but perhaps they both end up at the same place, and that might buy us something or other | 14:46 | |
ruoso | i'm not sure how that can happen... | ||
TimToady | you can go out dynamic contexts, but you keep ending up in someone's lexical context | ||
so they're already interwoven | 14:47 | ||
ruoso | yes... of course... | ||
that's the exact point | |||
contextual lookup goes "back" in the "caller" axis, making regular lookups where the variable has the "is context" trait | |||
TimToady | the question is whether outer and caller from the main scope end up at the same place | ||
ruoso | you do realize that will make all your globals visible as local variables, don't you? | 14:48 | |
i.e. $OUT | |||
14:50
icwiener joined
|
|||
TimToady | hmm, well, maybe $*OUT merely tells the compiler to bypass lexical lookup and go straight to looking up $OUT dynamically | 14:50 | |
ruoso | yeah... that's the "contextual lookup" I've been referring to | ||
and there's the "ultimate caller" | |||
which declares "my $OUT is context = $GLOBAL::OUT" | 14:51 | ||
TimToady | but there could be great value in confusing lexical and dynamic notation if we want to implement temp using context on lexicals | ||
ruoso | we could assume that temp $OUT would create a local copy to $*OUT | 14:52 | |
TimToady | question is how 'my $x; temp $x = foo()" gets the temporized $x into its dynamic scope. | 14:53 | |
ruoso | we had been there before... | ||
TimToady | it's not in the dynamic scope, since $x isn't visible there | ||
ruoso | temp needs contextual vars | ||
TimToady | but if you access $x lexically, it doesn't know to look it up dynamically | ||
ruoso | that's why "my $x; temp $x" is supposed to be a failure... | 14:54 | |
"my $x is context; temp $x" otoh, should do the trickl | |||
TimToady | eh, not specced as failure in p6 | ||
ruoso | TimToady, yeah... I know... we discussed that before :) | ||
TimToady, and we agreed at the time that temp can only be applied to contextual vars... | |||
14:55
d4l3k_ joined
|
|||
TimToady | I don't recall agreeing to that, but maybe I'm getting senile, or maybe I just didn't understand what you were saying | 14:55 | |
14:55
alanhaggai left
|
|||
ruoso | heh... | 14:56 | |
TimToady | I can always blame jet lag too | ||
ruoso | oh wait... I'm the one getting senile.. | ||
14:56
pmichaud_ joined,
pmichaud left,
PerlJam left
|
|||
ruoso | it's "temp $x" that means "my $x is context" | 14:56 | |
14:56
Juerd joined,
PerlJam joined,
Juerd_ left
|
|||
ruoso | so it's a "my $x; temp $x" causes a 'redefining variable in the same scope' warning... | 14:57 | |
14:57
dalek left
|
|||
TimToady | defining temp as "is context" doesn't help | 14:57 | |
ruoso | why | ||
? | |||
14:57
masak left
|
|||
ruoso | inside the current scope, you can use the local name... | 14:57 | |
TimToady | because you'll have some code that sees $x lexically and will go straight to the lexical without looking in the dynamic context | ||
and the dynamic context is not guaranteed to be in the lexical context | 14:58 | ||
14:58
d4l3k_ is now known as dalek
|
|||
TimToady | when you have routines calling back and forth | 14:58 | |
14:58
alanhaggai joined
|
|||
ruoso | oh... I think I see what you mean... | 14:58 | |
TimToady | I think I see what needs to happen though | ||
if you temporize $x somewhere, it's because it's already visible and mutable in the lexical scope | |||
so it retroactively "mutes" it to a context var, so that anyone who looks it up lexically knows to look it up dynamically instead | 14:59 | ||
ruoso | but that doesn't solve the following: | ||
package foo { my $var = 1; sub bar { say $var } }; my $var is context = 2; foo::bar() | 15:00 | ||
TimToady | It globally records the *fact* of temporization like p5, but doesn't track the *data* of it like p5 | ||
so the data is still contextual | |||
ruoso | TimToady, should foo::bar() say "1" or "2" on the above example? | 15:01 | |
I don't think there's a way to actually avoid the twigil to mean 'this lookup should be subject to contextual lookup' | 15:02 | ||
TimToady | it should say 1 | ||
if you want to force dynamic lookup, you need the * | |||
ruoso | right.. so it seems we agree after all | 15:03 | |
TimToady | but then it throws away the * and looks for $foo and any dynamically surrounding lexical scope | ||
(where declared contextual) | |||
(or temporized contextual) | 15:04 | ||
againg the "fact" of temporization, but not the value | |||
pugs_svn | r22525 | ruoso++ | [smop] SMOP__S1P__AdhocSignature lets you define a signature with custom molds for ACCEPTS and BIND | ||
ruoso | TimToady, should that mean that $*foo looks in the current scope for a contextual var first? | ||
TimToady | well, the fact comes from lexical lookup, then the value presumably comes from somewhere inner to the lexical that was temporized | 15:05 | |
ruoso lunch & | |||
TimToady | will think about current scope | ||
15:05
hercynium joined
|
|||
TimToady | first answer, probably | 15:06 | |
and maybe $+foo forces one CALLER in there | 15:08 | ||
'course, that means $?foo should mean here or in my direct caller :) | |||
but if $*foo looks in this scope first | 15:10 | ||
15:10
justatheory joined
|
|||
TimToady | and if we make temp mark the current lexical as temporarily contextual | 15:11 | |
then the redirection of $foo to $*foo on temporized variable would be wrongish, I think | 15:12 | ||
since it would find the lexical again first | |||
so maybe it redirects to $+foo instead | |||
but then, what if the temp was done in the current scope? | |||
which I think argues that temp must also set up a contextual mirror in the current scope, and then we redirect to $*foo | 15:13 | ||
so in the case of "my $x; temp $x" in the same scope, we can probably just mark the my as contextual to begin with instead of complaining | 15:14 | ||
TimToady is getting mushbrain, need more coffee | |||
I do like that this seems to be getting closer to the p5 local model while extracting out the damaging component of global state | 15:16 | ||
makes me feel happier about emulating p6 context with locals in p5 | 15:17 | ||
and maybe p5 could move to this model someday | |||
and then get localized my vars :) | |||
TimToady suspects that coffee will only help a little with TimToady's kind of mushbrain... | 15:24 | ||
[particle] | a long walk and lots of wires might help | 15:25 | |
TimToady | coffee already gets me wired, and makes me walk down the hall occasionally | 15:31 | |
15:32
alanhaggai left
15:47
justatheory left
15:49
adamkennedy left
15:58
rindolf joined,
Lorn__ left,
zamolxes left
16:07
Exodist joined
16:21
justatheory joined
16:25
cosimo left
16:29
betterworld left
16:30
mncharity joined
16:41
Deepi left,
pyrimidine joined
16:42
pmurias joined
|
|||
pmurias | ruoso: hi | 16:43 | |
rakudo_svn | r31757 | particle++ | [rakudo] [perl #59570] $*OS and $*EXECUTABLE_NAME globals initial implementation | ||
r31757 | particle++ | ~ add support for $*OS, $*OSVER, $*EXECUTABLE_NAME | |||
r31757 | particle++ | modified and expanded from azawawi++'s original code | |||
mncharity | rakudo: say [$*OS, $*OSVER, $*EXECUTABLE_NAME] | 16:47 | |
lambdabot | mncharity: You have 1 new message. '/msg lambdabot @messages' to read it. | ||
p6eval | rakudo 31667: OUTPUT[Null PMC access in get_string()ā¤current instr.: 'parrot;P6metaclass;add_parent' pc 95 (runtime/parrot/library/P6object.pir:126)ā¤] | ||
mncharity | masak: :) | ||
mncharity notes 31667 seems << than 31757 | 16:48 | ||
moritz_ should take a look at evalbot | 16:49 | ||
16:51
Bzek left
|
|||
moritz_ | rakudo needed a 'make clean', it seems | 16:51 | |
rebuilding now | |||
rakudo: say [$*OS, $*OSVER, $*EXECUTABLE_NAME].perl | 16:53 | ||
p6eval | rakudo 31667: OUTPUT[["./parrot", "./parrot", "./parrot"]ā¤] | ||
moritz_ | [particle]: do you want a ticket? ;-) | 16:54 | |
[particle] | hrmm, what happened there... oh, i think i know | ||
no ticket | |||
moritz++ | 16:58 | ||
rakudo_svn | r31758 | particle++ | [rakudo] silly me (particle--), i forgot to create a new string every time | ||
r31759 | particle++ | [rakudo] refactor package definition exit code based on feedback from pmichaud++ | 16:59 | ||
moritz_ | actually it's mncharity++ for detecting ;) | 17:00 | |
[particle] | rakudo: say [$*OS, $*OSVER, $*EXECUTABLE_NAME].perl | ||
p6eval | rakudo 31757: OUTPUT[["./parrot", "./parrot", "./parrot"]ā¤] | ||
[particle] kicks p6eval :P | 17:01 | ||
17:01
Lorn joined
|
|||
moritz_ | [particle]: no need for kicking, parrot is rebuilt every full hour on p6eval's server | 17:02 | |
[particle] | hourly... good to know. on the hour? | 17:03 | |
moritz_ | yes | ||
[particle] | rakudo: say [$*OS, $*OSVER, $*EXECUTABLE_NAME].perl | ||
p6eval | rakudo 31757: OUTPUT[["linux", "", "./parrot"]ā¤] | ||
[particle] | good, except the version is wrong | ||
moritz_ | [particle]++ | ||
[particle] | s/version/revision/ | 17:04 | |
moritz_ | where should parrot get the os version from? | ||
[particle] | it gets it during config, i think | ||
from what, i'm not sure | |||
moritz_ | uname -a? | ||
or more like /etc/debian_version? | |||
[particle] | maybe on linux | ||
not on windows :) | |||
anyway that $* stuff is compiler-specific | 17:05 | ||
so, it's definitely not a rakudo bug, it's a parrot bug | |||
17:06
rindolf left
|
|||
[particle] | did spectest_regression get slow again, or is it just so many more tests? | 17:07 | |
moritz_ | I think mostly more tests | 17:09 | |
rakudo.de/progress.png | |||
just look at the total | |||
[particle] | yeah | ||
17:15
jferrero left
|
|||
moritz_ | [particle]: spectest_regression is up to ~9m CPU time again, which is roughly where it was before precompiled modules | 17:15 | |
17:16
PZt left
|
|||
[particle] | ok, that's how it felt to me (i never remember to look at the time at the end) | 17:16 | |
17:16
cotto joined
17:17
cotto left
|
|||
moritz_ | due to parallel testing I'm now at 5m20 real time | 17:17 | |
[particle] | how do i enable that? | ||
moritz_ | (2 CPUs; I need to get more of them) | ||
[particle] | i have 4, hoping for 8 by next year | ||
moritz_ | TEST_JOBS=2 make spectest_regression | ||
(on linux) | |||
ok, maybe TEST_JOBS=5 for you ;) | |||
you might need a fairly recent version of TAP::Harness on windows | 17:18 | ||
mncharity | perl6: "a".length | 17:19 | |
p6eval | rakudo 31760: OUTPUT[Method 'length' not found for invocant of class 'Perl6Str'ā¤current instr.: '_block11' pc 21 (EVAL_10:13)ā¤] | 17:20 | |
..pugs: OUTPUT[*** No such method in class Str: "&length"ā¤ at /tmp/b6hbFJ9DW3 line 1, column 1 - line 2, column 1ā¤] | |||
..elf 22525: RESULT[1ā¤] | |||
pugs_svn | r22526 | pmurias++ | [mildew] say "Hello World" compiles correctly | ||
moritz_ | length is a banned word ;) | ||
mncharity | :) now gone from elf. The current 1 minute CL elf compile is a pain. | 17:23 | |
moritz_ wonders if mncharity has ever built gcc ;) | 17:24 | ||
mncharity | lol | 17:25 | |
17:25
khisanth_ joined
|
|||
moritz_ | perl6: print "ab".chars | 17:25 | |
p6eval | elf 22526, pugs, rakudo 31760: OUTPUT[2] | ||
moritz_ | perl6: print "ab".codes | ||
p6eval | elf 22526, pugs: OUTPUT[2] | ||
..rakudo 31760: OUTPUT[Method 'codes' not found for invocant of class 'Perl6Str'ā¤current instr.: '_block11' pc 21 (EVAL_12:13)ā¤] | |||
mncharity | many, many times. but I'd not consider the gcc build process a model of sanity. | ||
17:25
Khisanth left
|
|||
mncharity | (at least as of some years aog() | 17:26 | |
17:26
khisanth_ is now known as Khisanth
|
|||
mncharity | *ago | 17:26 | |
perl6: print "å".codes | 17:29 | ||
p6eval | rakudo 31760: OUTPUT[Method 'codes' not found for invocant of class 'Perl6Str'ā¤current instr.: '_block11' pc 21 (EVAL_12:13)ā¤] | ||
..elf 22526, pugs: OUTPUT[1] | |||
mncharity | perl6: print "å".bytes | ||
p6eval | elf 22526, pugs: OUTPUT[3] | ||
..rakudo 31760: OUTPUT[Method 'bytes' not found for invocant of class 'Perl6Str'ā¤current instr.: '_block11' pc 21 (EVAL_12:13)ā¤] | |||
moritz_ | perl6: my $s = "A\c[COMBINING ACUTE ACCENT]"; say $s.codes; say $s.chars; say $s.graphs; | 17:30 | |
17:30
pmurias left
|
|||
p6eval | elf 22526: OUTPUT[Can't locate String/Multibyte.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at ./elf_f line 89.ā¤ at ./elf_f line 3861ā¤27ā¤27ā¤] | 17:31 | |
..rakudo 31760: OUTPUT[Method 'codes' not found for invocant of class 'Perl6Str'ā¤current instr.: '_block11' pc 42 (EVAL_11:20)ā¤] | |||
..pugs: OUTPUT[2ā¤1ā¤1ā¤] | |||
TimToady | wow, I didn't expect pugs to get that right | ||
moritz_ neither | 17:32 | ||
TimToady | I wonder if it \c canonicalized to NFC | ||
pugs: my $s = "-\c[COMBINING ACUTE ACCENT]"; say $s.codes; say $s.chars; say $s.graphs; | 17:33 | ||
p6eval | pugs: OUTPUT[2ā¤1ā¤1ā¤] | ||
rhr | pugs has a .graphs in prelude that has an incomplete list of combining chars | ||
moritz_ | perl6: my $s = "A\c[COMBINING ACUTE ACCENT]"; say $s.codes; say $s.chars; say $s.graphs; | ||
p6eval | rakudo 31760: OUTPUT[Method 'codes' not found for invocant of class 'Perl6Str'ā¤current instr.: '_block11' pc 42 (EVAL_11:20)ā¤] | ||
..elf 22526: OUTPUT[27ā¤27ā¤27ā¤] | |||
..pugs: OUTPUT[2ā¤1ā¤1ā¤] | |||
moritz_ | ah, elf doesn't interpolate \c | ||
ruoso | TimToady, hmm... I was thinking earlier that you were meaning to merge $*foo and $+foo as being the same thing... which would mean dropping one of the syntaxes | 17:41 | |
TimToady, I was thinking on 'temp $x' declaring a local name '$x' that points to the contextual variable... which would be kinda the same of 'my $x is context<rw>' | 17:43 | ||
then in that scope, you could either use '$x' or '$*x' but to access a temp variable not declared "here", you would always need the '$*x' syntax | 17:45 | ||
mncharity | re elf \c , more generally, the old STD didn't really support strings, so strings are kludged in elf. no interpolation in general. with new STD_blue, can do better. | ||
ruoso .oO(is there going to be a STD_green?) ;) ;) ;) | |||
TimToady | green is my favorite color, though I like purple better | 17:46 | |
mncharity | STD_blue is a hopefully minimal wrapper around gimme5. written in p5. STD_something is a version written in p6. then the parser disappears into elf. | ||
TimToady | have you looked at viv? it spits out something ASTish now | 17:47 | |
and at least once I successfully spat out the VAST for STD.pm | 17:48 | ||
for some definition | |||
17:48
ab5tract joined
17:50
tomyan left
|
|||
ruoso | TimToady, btw... I think I have my mind clearer now... and I think a good model could be dropping either '$*foo' or '$+foo', as both would mean the same thing, that variable would start looking for contextual vars *in the current scope*, and falling to the callers... 'temp $x' would just be a synonim for 'my $x is context<rw>'... and I think that's all | 17:52 | |
I think that addresses all the issues you raised... | 17:53 | ||
TimToady | not if the intent of temp $foo is to override someone's use of $foo without them having to say $*foo | 17:54 | |
I'm looking for something a little closer to the spirit of local | 17:55 | ||
17:56
mberends joined
|
|||
ruoso | TimToady, "someone" where? | 17:57 | |
in an inner scope? or in an inner caller? | |||
TimToady | in the lexical scope of the original my $foo but not in the lexical scope of the temp $foo | ||
ruoso | hmmm... | 17:58 | |
TimToady | the purpose of temp is different than the purpose of "is context" | ||
temp overrides the meaning of the root variable without changing its scope | |||
we need at least a bit in that variable that says, "oops, look in the dynamic scope instead" | 17:59 | ||
ruoso | it's weird the idea of a code being able to mess with the closure's variables | ||
mncharity | TimToady: viv? no, I haven't - awesome. | ||
ruoso | I mean... if that variable is marked as contextual, ok... | ||
but it looks like a huge mess to support that for non-contextual variables | 18:00 | ||
rakudo_svn | r31762 | particle++ | [rakudo] make branch explicit in 'variable' action method | 18:01 | |
ruoso | because that would be automagically turning a 'my $foo' into 'my $foo is context' | ||
TimToady, is there some use case for this specific feature? | 18:02 | ||
TimToady | well, the overhead is not on that end, but on the rvalue end that has to check the bit and redirect | ||
not sure, but you're not implementing temp correctly if it doesn't change the root variable's meaning everywhere that can see it | 18:03 | ||
ruoso | *that can see it* | 18:04 | |
you said well.. | |||
TimToady | lexically | ||
ruoso | 'my $x' is *not* visible from some scope that is not an inner scope | ||
'my $x' is *not* visible by an inner "caller"... just by an inner "scope" | |||
you can't say 'temp $x' in that case, because 'my $x' is not visible to you... | 18:05 | ||
TimToady | but I can call into a routine that is in the tree of $x, and it can temporize during that call, even though I'm not called by the code that declared $x in the first place | 18:06 | |
ruoso | that looks like p5 local, meaning that it's treating the variable as if it were global | 18:07 | |
TimToady | anyway, ETOOMANYCONVERSATIONS for the moment, gotta concentrate on #parrot | ||
ruoso | btw... if both codes can see the variable, why can't the code just set a value for that variable, and reset it to the original value when exitting that scope? | 18:10 | |
18:18
kjs_ joined
|
|||
Gothmog_ | Hm. What about refs to that variable? And what about big objects? | 18:19 | |
18:23
riffraff joined
|
|||
Gothmog_ | So if you have a capture of your outer $x, I suppose it should still point to the outer $x after you temp $x. | 18:23 | |
Just thinking loud. | |||
18:27
icwiener left
18:31
tewk joined,
riffraff left
|
|||
ruoso | Gothmog_, in theory yes... 'temp' would just mess with future lookups of the variable... | 18:34 | |
Gothmog_ | So if it's that way, and you just overwrite the variable, captures wouldn't work. | 18:38 | |
ruoso | what do you mean? | 18:40 | |
mncharity | TimToady: re viv, yay! :) | 18:42 | |
so STD_blue becomes a thin wrapper around viv. | 18:43 | ||
Gothmog_ | If you overwrite the value at the original location of my $x when you write temp $x, and your capture is in fact a pointer to that original location, it would suddenly contain the inner $x, and it would be virtually impossible to work around that. | 18:44 | |
Of course, everything under the assumption that a capture of the outer $x is supposed still to contain the outer one when you do temp $x. | 18:45 | ||
gtg | 18:46 | ||
bye! | |||
18:49
azawawi joined
|
|||
azawawi | hi | 18:49 | |
moritz_ | hi azawawi ;) | ||
azawawi | moritz_: how r u? | 18:50 | |
18:50
alanhaggai joined
|
|||
moritz_ | distracted | 18:50 | |
azawawi | rakudo: 1.unpolar(0) | 18:51 | |
p6eval | rakudo 31762: RESULT[1+0i] | ||
azawawi | rakudo: cis(0) | 18:52 | |
p6eval | rakudo 31762: RESULT[1+0i] | ||
azawawi | rakudo: cis(0) == 1.unpolar(0) | ||
p6eval | rakudo 31762: RESULT[Bool::True] | ||
18:54
alanhaggai left
19:20
pmurias joined
|
|||
pugs_svn | r22527 | putter++ | [viv] Simplify using viv as a library - if($0 eq __FILE__). | 19:25 | |
r22528 | putter++ | [elfish/on_sbcl] Still struggling towards self compilation. | 19:29 | ||
r22528 | putter++ | [elf_h] Tweaks. | |||
19:29
pmurias left
19:31
mncharity left
19:33
rdice joined
|
|||
azawawi | moritz_: is there a new parrot release on the way? | 19:39 | |
moritz_ | azawawi: there's a parrot release every month | 19:40 | |
azawawi | moritz_: cool | 19:41 | |
19:45
rdice left
|
|||
pugs_svn | r22529 | ruoso++ | [smop] removing old_src dir, since its been a while since anyone touches it | 19:58 | |
19:58
jferrero joined
20:00
ab5tract left
20:01
pmurias joined
|
|||
pmurias | ruoso: have you seen the version of lexical scope converted to the RI DSL | 20:02 | |
pmurias finally has internet in his room ;) | |||
ruoso | :) | 20:03 | |
pmurias, yeah... I just saw it... | |||
it looks great... | |||
and yeah... I know I'm not using it yet ;), but that was because the ri I created was copy'n'pasted from other one | 20:04 | ||
pmurias | the RI DSL has only became usable in that commit | ||
20:05
justatheory left
|
|||
ruoso | yeah... it indeed looks much better | 20:05 | |
have you seen test/36? | 20:06 | ||
pmurias, I think 'sub dispatch' will be needed sooner than I expected... | 20:07 | ||
but that's a good thing... | |||
because it means that the code will be closer to actual Perl 6 | |||
that came with the realization that the prelude should be populated by the things in src-s1p | |||
pmurias | 'sub dispatch' = ? | ||
ruoso | pmurias, yeah... how &map, &infix:<+> work | 20:08 | |
and in fact, 'multi sub dispatch' is what I mean | 20:09 | ||
since &infix:<+> will have an important variant for (int,int) | |||
that's why I started AdhocSignature... | 20:10 | ||
to allow the signatures in src-s1p to be compiled to blocks of m0ld code | 20:11 | ||
that will both reply to ACCEPTS and to BIND | |||
remember the idea of having the signature translated to the start of the routine? | |||
that's an improved version of that ;) | |||
pmurias | is signature introspection required for something? | 20:13 | |
ruoso | some introspection is... | 20:14 | |
.arity should probably be added to AdhocSignature | |||
20:15
pmichaud_ is now known as pmichaud
|
|||
ruoso | but I don't think full introspection is really needed... | 20:15 | |
at least not for start | |||
moritz_ | .count is needed for map, isn't it? | ||
20:15
pmurias left,
pmurias joined
|
|||
ruoso | moritz_, wasn't 'arity' used for that? | 20:16 | |
moritz_ | ruoso: if you want @list.map( -> $x? { 2 * $x } ); to pass an argument to the block, you need .count | ||
ruoso | hmm... | 20:17 | |
alright then... .arity and .count | 20:18 | ||
moritz_ | but that example is nonsense | ||
20:18
Caelum joined
|
|||
ruoso was trying to figure out what that meant | 20:18 | ||
moritz_ | perhaps if we had a rand() that could be both unary and nullary | 20:19 | |
like perl 5's | |||
ruoso | sub rand ( $i? = 1 ) | ||
moritz_ | then @list.map(&rand) would behave differently, depending on wheter you use .count or .arity | ||
ruoso: exactly | 20:20 | ||
ruoso | anyway... adding both shouldn't be a trouble | ||
TimToady | for things that work left to right, it makes some sense to use .arity and bind the extra params only if they're there | 20:21 | |
for right-to-left things like the new ..., it really needs .count | |||
since *@_ is arity 0 | |||
but count * | |||
(yes, the spec on ... is inaccurate there) | 20:22 | ||
ruoso | pmurias, anyway... I think we should consider translating as much as we can to the RI DSL, since that will allow us a nicer transition to supporting non-native captures and identifiers | ||
TimToady | hmm, I wonder if we can play games with an invocant declaration... | 20:23 | |
for map -> $prevcap: $_ { $$prevcap + $_ } | |||
pmurias | ruoso: ;) | 20:24 | |
TimToady | but what would you do the first time? O_o | ||
moritz_ | TimToady: pass a capture to the entire array as invocant? ;) | ||
not that it's useful in any way ;) | 20:25 | ||
ruoso | TimToady, is it possible to have invocant declaration in a sub? what does it point to? | ||
TimToady | would presumably depend on what kind of capture you try to bind to it | 20:26 | |
if you're binding a capture with an invocant, it's obvious | |||
if one without, maybe first arg | |||
ruoso | hmm.... that brings us back to an old discussion... | ||
moritz_ | isn't that old, deprecated method fallback? | ||
ruoso | the signature of .postcircumfix:<( )> | 20:27 | |
TimToady | yes, but I have to commute to work before we can rehash that. :) | ||
moritz_: we're talking about how you write a method dispatcher in p6 without assuming methods | |||
ruoso stands for '.postcircumfix:<( )> ($capture)' instead of '.postcircumfix:<( )> (|$capture)' | |||
TimToady | I think &method should be callable as a subroutine | ||
anyway, gotta rn | 20:28 | ||
*run | |||
ruoso planning on how to implement multi sub | 20:29 | ||
pmurias | ruoso: re multi sub dispatch its not difficult to write a simple version of it, but having it fast is complicated | 20:30 | |
ruoso | pmurias, I'd be happy with "good enough" | ||
for some reason, I think SMOP won't be that slow | 20:31 | ||
20:31
rdice joined
|
|||
ruoso | (even without optimizations, I mean) | 20:32 | |
20:32
kjs_ left,
rdice left
|
|||
ruoso | pmurias, most importantly, I'm ok with having a first implementation that will be replaced somewhere in the future | 20:32 | |
pmurias | the runloop as done is propably a huge performance hit | ||
ruoso: do we really need multis now? having mildew compile more stuff could be a better idea | 20:34 | ||
ruoso | pmurias, the thing is that for mildew to compile correctly, we need multis | ||
otherwise we will need to rework it in a very near future | |||
I mean... 'say "Hello"' is a multi dispatch | 20:36 | ||
we can have mildew working before multi, but it will be simply wrong... | |||
20:36
pyrimidine left
|
|||
ruoso | and we will need multis for the code in src-s1p | 20:36 | |
moritz_ | diakopte1: ping | 20:38 | |
20:40
zamolxes joined
|
|||
pmichaud | class Foo { ... }; say Foo.WHAT; # "Foo\n" | 20:41 | |
module Bar { ... }; say Bar.WHAT; # ??? | |||
ruoso | pmichaud, 'cannot find class Bar in the current scope' | ||
pmurias | ruoso: you can look at how jonathan implemented multis in parrot | 20:42 | |
ruoso | pmurias, good point... | 20:43 | |
20:43
justatheory joined,
Jedai left
20:44
Jedai joined
20:46
jferrero left
|
|||
ruoso | pmichaud, I was trying to find in the specs, but I couldn't... TimToady said someday in the irc that Bar.something always look for a class... if you want to use it as a package you need to use :: | 20:46 | |
pmichaud | ruoso: thanks, that's a big help. | 20:47 | |
ruoso++ | 20:48 | ||
ruoso | :) | 20:49 | |
azawawi | moritz_: regarding RT #56226 - (roots.pl), did u mean to use unpolar instead of polar in @results? | 20:54 | |
pmurias | ruoso: is there anything else missing before mildew can start compiling stuff which runs correctly? | ||
20:54
pyrimidine joined
|
|||
moritz_ | azawawi: sorry, don't have concentration at the moement... care to reply to the ticket? | 20:55 | |
ruoso | pmurias, we need P6Meta.pm to be completed | 20:56 | |
unless you consider using only pureprototypehow | |||
pmurias, compiling P6Meta.pm seems to be the target for mildew, I think | 20:57 | ||
(the first target, of course... many others to come later ;) | |||
azawawi | moritz_: done... | 20:58 | |
ruoso | pmurias, that means also implementing the Capture Expansion | ||
pmurias, to support foo(|@bar) | |||
then gather/take | 20:59 | ||
feed operators | |||
pretty much what's in the ROADMAP | |||
pmurias | P6Meta could be simpilified | ||
ruoso | pmurias, seems fine to me.. | 21:00 | |
but our next major milestone is to have both P6Meta.pm and Object.pm compiled | |||
if we can simplify them a little bit, I think there's nothing wrong with it (as long as they do what they are supposed to do) | 21:01 | ||
but one thing that's missing on P6Meta is "method dispatch" | 21:02 | ||
I was hoping someone could write it.. | |||
ruoso have to run... | |||
pmurias, I'll try to get back online asap... | |||
ruoso will backlog later... | 21:03 | ||
21:03
ruoso left
|
|||
pmurias | sleep& | 21:06 | |
21:06
pmurias left
21:08
mberends left
21:09
zamolxes left
21:13
TJCRI left
21:15
pyrimidine left
21:17
xuser left
21:20
iblechbot left
|
|||
pugs_svn | r22530 | moritz++ | [irclog] point r\d+ in #perl6 to SVN::Web instead of trac, because trac's CSS | 21:27 | |
r22530 | moritz++ | is a 404, and I don't know how to fix that. | |||
moritz_ | that worked. | 21:28 | |
21:41
justatheory left
21:42
justatheory joined
21:47
ruoso joined
21:49
pyrimidine joined
21:50
pyrimidine left
22:09
Lorn__ joined
22:14
jferrero joined
22:18
alester left
|
|||
ruoso | cool... parrot implementation of multis is pretty close to what I had thought also... | 22:19 | |
22:22
Lorn left,
cognominal joined,
Lorn_ left
22:24
ab5tract joined
22:26
wknight8111 joined
22:28
sri_work joined
22:33
jferrero left,
cls_bsd left
|
|||
azawawi | moritz_: roots() and polar() are now implemented in any-num.pir (RT #56226) | 22:50 | |
22:52
azawawi left
22:53
justatheory left
22:54
Alias_ joined
22:56
plash_ joined
23:10
araujo left
|
|||
meppl | good night | 23:14 | |
23:18
meppl left
23:36
Chillance joined
23:42
Lorn__ left
23:44
Kitchy joined
|
|||
Kitchy | If the Perl 5 to Perl 6 translator that | 23:45 | |
...I mean... | |||
If the Perl 5 to Perl 6 translator that's been discussed actually happens, would we be able to put an end to Perl 5? | 23:46 | ||
23:46
justatheory joined
|
|||
Kitchy | Because all I've heard was that Perl 5 will still be around. Maybe it doesn't need to be. | 23:47 | |
pmichaud | why shouldn't it be? Perl 5 is excellent. | ||
Kitchy | If you could do it with just Perl 6 installed, you'd be able to use it. | 23:48 | |
It would be like a perl 5/6 combo that's billed as Perl 6 but works with Perl 5 too. | |||
ab5tract | sounds like a waste of time | ||
Kitchy | It kind of sounded like Perl 6 will have such a translator anyway. | 23:49 | |
pmichaud | Kitchy: sure, it probably will. But we're not ones to believe in "only one way of doing things" :-) | ||
Kitchy | If the translator is easily enough invoked from within Perl 6, it's not really limiting and dedicated Perl 5 could be discontinued. | 23:51 | |
pmichaud | Perl 5 will be "discontinued" when people decide they no longer need it. Personally, I think that may be a while. | ||
ab5tract | wasn't there going to be a perl 5 for parrot? | 23:54 | |
anyway, lots of perl 5'ers seem to also love hating perl 6. so threatening (or even implying) to 'discontinue' their choice platform probably wouldn't go over too well. | 23:57 | ||
not to mention: what's the necessity of it anyway? | |||
Kitchy | I mean requiring them to install Perl 6 and do something to invoke Perl 5 if they want to use it. | 23:58 | |
23:58
justatheory left
|
|||
TimToady | this will all work itself out over the long run. we need a story for those who want to migrate, and a story for those who don't. | 23:58 | |
those need not be the same story | 23:59 | ||
23:59
Exodist left
|
|||
pmichaud | I like the notion of "story" here -- very good. | 23:59 |