Parrot 0.8.2 "Feliz Loro" Released www.parrot.org/news/2008/Parrot-0.8.2
Set by moderator on 23 December 2008.
dalek r35010 | infinoid++ | trunk/compilers/imcc (2 files): 00:00
: [cage] Remove trailing semicolons from ASSERT_ARGS tags in imcc.y.
: Also, tag the untagged IMCC_itcall_sub() function with ASSERT_ARGS.
review: www.parrotvm.org/svn/parrot/revision?rev=35010
00:08 Theory joined 00:09 AndyA joined
nopaste "jonathan" at 85.216.157.73 pasted "example of bytecode annotations" (53 lines) at nopaste.snit.ch/15207 00:11
00:13 kid51 joined
dalek r35011 | jonathan++ | branches/bcanno/src (2 files): 00:15
: [core] Make looking up bytecode annotations in effect at the point an exception was thrown work.
review: www.parrotvm.org/svn/parrot/revision?rev=35011
Tene jonathan++ # good work 00:16
jonathan Tomorrow I add missing seatbelts to the code, write tests and fix any bugs they uncover.
But that has them essentially working. :-) 00:17
particle jonathan++ # will we support 'column' and other annotations? 00:35
dalek r35012 | jkeenan++ | trunk (5 files): 00:38
: Revert r34951, restoring DWIM.pir and associated test. Cf.: trac.parrot.org/parrot/ticket/120.
review: www.parrotvm.org/svn/parrot/revision?rev=35012
jonathan particle: You can have a monkey annotation if you want. ;-) 00:40
.annotate 'whatever here' value 00:41
Only thing is that you must use the same type of value
So if you use an integer value in one place, you can't then under the same key also put, say, a string. 00:42
(That's so we can compactly store line numbers as just an opcode_t.)
chromatic I'm not sure about storing annotations directly in bytecode. 00:59
jonathan chromatic: Huh?
We're not, they go in their own segment.
chromatic Are they stored as indices into a segment?
Okay good.
jonathan Ah, I see the confusion.
When I said an opcode_t, I meant that we stored a line number just as one of those in the annoatations seg. 01:00
So it's reasonably compact.
chromatic Carry on then.
jonathan :-)
01:17 ask_ joined 01:21 Fayland joined 01:23 Ademan joined 01:29 jimmy joined 01:51 tetragon joined
kid51 rt.perl.org down (again) 02:04
02:29 Theory joined 02:32 TiMBuS joined
dalek r35013 | Whiteknight++ | trunk/docs/book: 02:36
: [Book] add more stuff about creating and manipulating classes programmatically
review: www.parrotvm.org/svn/parrot/revision?rev=35013
02:47 tetragon joined
kid51 Whiteknight: What is the link to the book? (I don't see it at www.parrot.org.) 02:48
Whiteknight it might not be at www.parrot.org 02:52
I actually don't know if it's anywhere on the web 02:53
I just write it, I don't post it or read it
kid51 I think it *used to be* present on the site.
There are so many dead or outdated links on the site.
Whiteknight yeah
Infinoid any relation to "Parrot Virtual Machine" over on wikibooks? 02:54
Whiteknight I've written both of them
Infinoid ah, ok
Whiteknight well, I wrote the one at wikibooks, and have partially written the one in the repo
kid51 Are they the same?
Whiteknight no, not the same
Infinoid one's a sequel of the other 02:55
Whiteknight They both contain the information I know, but they discuss it in different ways
anyway, I'm heading off to bed now. Goodnight gentlement 02:56
Tene jonathan: around? 02:57
kid51 en.wikibooks.org/wiki/Parrot_Virtual_Machine
Tene although maybe kjs knows too? 03:13
jimmy wikibooks?
purl wikibooks is awesome. ;/ It can fly too.
jimmy where
kid51 jimmy: I just posted the link. 03:14
Tene Anyway, the issue is that load_bytecode 'perl6.pbc' from another pir file crashes, unless that .pir also has .load_bytecode 'perl6_group'
jimmy thanks kid51
Tene I guess that's not included in the bytecode when compiling to perl6.pbc?
The opcode version, $P0 = loadlib 'perl6_group' doesn't work either.
nopaste "tene" at 67.186.244.107 pasted "this works" (7 lines) at nopaste.snit.ch/15208 03:15
"tene" at 67.186.244.107 pasted "this doesn't work" (5 lines) at nopaste.snit.ch/15209
"tene" at 67.186.244.107 pasted "this also doesn't work" (9 lines) at nopaste.snit.ch/15210
Tene I'm also tempted to try harassing chromatic, but I always ask chromatic when I run out of others to harass. 03:17
tewk pge question can I dump the call stack from with in a rule?, in other words the rules called to get to the current rule? 03:40
Coke doesn't die do that? 03:45
Tene Okay, 'op loadlib' just calls one function, Parrot_load_lib
Coke er, panic?
tewk Coke: yea panic,
I would like to get the backtrace without actually dying though. 03:46
Tene .loadlib calls two functions, Parrot_load_lib and Parrot_register_HLL_lib
tewk: there's a line commented out in the auto-resume stuff that will print the BT for a nonfatal exception
tewk: it's pretty easy to add a warn() to PGE that throws a nonfatal
tewk: src/exceptions.c:213 03:48
tewk cool there is a backtrace op 03:51
Tene: src/exceptions.c:213 led me to the backtrace op 03:52
Tene That works too. :) 03:53
04:19 ChrisDavaz joined 04:20 Fayland joined
Coke should we be able to flush a channel opened for reading? 04:24
(for tcl, that's an error.)
04:34 ask_ joined 05:15 Fayland joined 05:17 Andy joined 05:29 galf joined 05:38 ChrisDavaz joined 05:42 tetragon joined 06:22 MariachiElf joined
dalek r35014 | tewk++ | trunk/languages/ecmascript (10 files): 06:39
: [js] trying to generate code for object literals
review: www.parrotvm.org/svn/parrot/revision?rev=35014
tewk any PCT experts around? 06:41
object_literal generates bad code, I don't know how to do it right. ../../parrot js.pbc --target=PIR t/sanity_pt/05-objects_2.js 06:42
jimmy Infinoid: ping 07:00
Tene tewk: nopaste some PAST and PIR?
jimmy Infinoid: I know why there were C90 warnings and how to avoid them 07:01
tewk Tene: one minute,
nopaste "tewk" at 155.97.237.62 pasted "js object_literals" (70 lines) at nopaste.snit.ch/15212 07:03
tewk basically I want to create an object, call the set method on that object twice then return the object. 07:08
It can't be that difficult, I've just not done a lot of PCT.
07:13 mberends joined
jimmy msg Infinoid I know why there were C90 warnings and how to avoid them, the problem is semicolon, now the semicolon had moved to macro and we can write #ifdef NDEBUG # define ASSERT_ARGS(a) #endif 07:19
purl Message for infinoid stored.
07:46 ChrisDavaz joined 07:58 ChrisDavaz joined 08:14 uniejo joined 08:45 iblechbot joined
dalek r35015 | fperrad++ | trunk/languages/lua/t: 08:59
: [Lua]
: - fix test : now, hash seed is randomized
review: www.parrotvm.org/svn/parrot/revision?rev=35015
r35016 | jquelin++ | trunk/languages/befunge (2 files): 09:01
: beginning return of befunge to a working state
review: www.parrotvm.org/svn/parrot/revision?rev=35016
09:14 donaldh joined 09:35 kj joined 09:38 elmex joined 09:53 mj41 joined 10:02 galf joined 10:10 ChrisDavaz joined 10:30 masak joined 10:42 ruoso joined
dalek r35017 | kjs++ | trunk/compilers/pirc/src (5 files): 10:46
: [pirc] move .annotate rule to statements section, as it's not a chunk-like thingy. Remove cpp comments; add a pointer to the annotation struct which points to the instruction node. This way it will have access to the bytecode offest, which is needed to store the annotation in the segment.
review: www.parrotvm.org/svn/parrot/revision?rev=35017
cotto pi time! 11:14
dalek r35018 | kjs++ | trunk/compilers/pirc/src (4 files): 11:16
: [pirc] more emit stuff for annotations.
review: www.parrotvm.org/svn/parrot/revision?rev=35018
donaldh Are there any parrot configure experts out there? 11:17
kj donaldh: I think they're not awake yet; different time zone 11:19
donaldh k
dalek r35019 | kjs++ | trunk: 11:22
: [MANIFEST] fix manifest.
review: www.parrotvm.org/svn/parrot/revision?rev=35019 11:23
kj donaldh: did you have trouble building parrot?
donaldh Yep, on Linux with gcc 3.4.6 and I've tracked the problem down to config/auto/gcc.pm but want to make the solution more robust.
kj oh, ok. I just had a problem with configure; manifest wasn't up to date. but that seems to be a different issue. 11:24
donaldh The problem is that config/auto/warnings.pm detects that -fvisibility=hidden is supported but the reciprocal setting in config/auto/gcc.pm is hardcoded for gcc > 4.0 11:25
And gcc.pm runs before warnings.pm
kj ok. sorry, that's beyond my knowledge. You can send a patch through trac (trac.parrot.org) if you have an improvement 11:26
I know nothing about configure
donaldh Yep, just trying to figure out where to move the check to.
11:28 alvar joined
dalek r35020 | jquelin++ | trunk/languages/befunge: 11:56
: basic argv parsing
review: www.parrotvm.org/svn/parrot/revision?rev=35020
r35021 | kjs++ | trunk/compilers/pirc/src (4 files): 12:07
: [pirc] some refactoring for annotations.
review: www.parrotvm.org/svn/parrot/revision?rev=35021
12:08 Whiteknight joined
dalek r35022 | jquelin++ | trunk/languages/befunge: 12:20
: finish parsing: debug information
: nothing done when flag -d detected, though. this requires debug.pasm to
: be sanitized
review: www.parrotvm.org/svn/parrot/revision?rev=35022
12:21 Whiteknight joined
jonathan hi all 12:27
donaldh hi 12:28
kj hi jonathan 12:31
dalek r35023 | jkeenan++ | trunk/tools/dev:
: Removed per discussion in rt.perl.org/rt3/Ticket/Display.html?id=41912.
review: www.parrotvm.org/svn/parrot/revision?rev=35023
12:31 kid51 joined
dalek r35024 | jonathan++ | branches (179 files): 12:38
: Update bcanno branch with latest from trunk.
review: www.parrotvm.org/svn/parrot/revision?rev=35024
12:41 Whiteknight joined
moritz what's up with the rakudoreg branch? 12:45
kj moritz: hi, I can't seem to use svn up on your box 12:46
12:48 mst joined
moritz kj: what's the error message? 12:49
purl the error message is at the bottom
moritz kj: works for me
jonathan moritz: In what sense?
progress/why it exists/status? 12:50
moritz jonathan: is it already merged? if not, what's the plan and the statues?
12:50 damianc joined
moritz I know what it does 12:50
(or what it should do :)
kj svn: Der Client ist zu alt, um mit der Arbeitskopie Ā».Ā« zusammen zu arbeiten;
bitte besorgen Sie einen neueren Subversion-Client
kjs@timtowtdi:~/parrot$
<< that's the error message 12:51
moritz that means "the client is too old to work with this working copy"
jonathan moritz: Am waiting on pmichaud's branch to go in first.
kj yeah, that much I figured ;-)
12:51 Lorn joined
kj is my wc too old? 12:51
moritz kj: where did you get your working copy from?
kj mm. it's very old, maybe it's one that I copied there using winscp 12:52
I'll try to do a fresh co
moritz kj: just cp -r ~moritz/parrot/
kj k, thx. Should be faster
moritz oh wait
that uses my local parrot mirror 12:53
which means that you can't commit to it
a fresh checkout is better, then
kj ok, I can do a co,if that's easier
oki, thx
mst damianc: anyway. why am I here?
kj jonathan: would requiring a comma between the annotation key and value be more consistent with other PIR directives? 12:54
, so: .annotate "answer", 42; not: .annotate "answer" 42
jonathan Which other ones do? 12:56
damianc mst: Just a minute.
jonathan .local pmc foo # none
kj .lex
.lex "x", $P0
jonathan Heh 12:57
kj and .HLL used to have one
jonathan But it was removed, or?
kj well, the 2nd argument was removed
so no need for a comma
jonathan Ah, OK. 12:58
I don't really care much.
It's not exactly something I see people writing by hand.
But rather emitted by code-gen.
kj well, just thinking what's easier to read.
I'm fine either way
jonathan To read, it makes little difference either way to me. But if it's inconsistent with other directives, then it'd be better to be consistent. 12:59
dalek r35025 | kjs++ | trunk: 13:02
: [MANIFEST] fix manifest after some file was deleted.
review: www.parrotvm.org/svn/parrot/revision?rev=35025
kid51 kj Thanks for correcting my failure to update manifest. 13:07
kj kid51: np 13:09
moritz is the failure in t/pmc/freeze.t (test 25) known? 13:11
13:12 mst left
Coke moritz: yes, there's a trac ticket. 13:15
moritz Coke: ok, thanks 13:16
Coke trac.parrot.org, search for freeze. tick # 116
dalek r35026 | jonathan++ | branches/bcanno/docs/pdds: 13:17
: [pdd] .annotate should have a comma to match other directives, e.g. .lex. Suggested by kj++.
review: www.parrotvm.org/svn/parrot/revision?rev=35026
r35027 | jonathan++ | branches/bcanno/compilers/imcc (3 files):
: [imcc] .annotate now has a comma in it.
review: www.parrotvm.org/svn/parrot/revision?rev=35027
r35028 | kjs++ | trunk/compilers/pirc/src (4 files): 13:20
: [pirc] more work on annotations and fix a compile error on linux.
review: www.parrotvm.org/svn/parrot/revision?rev=35028
r35029 | kjs++ | trunk/compilers/pirc/src (3 files): 13:22
: [pirc] previous fix wasn't the fix I meant. Now fix the compile error on linux.
review: www.parrotvm.org/svn/parrot/revision?rev=35029
r35030 | kjs++ | trunk/compilers/pirc/src: 13:26
: [pirc] _tempnam is not available on linux; change into tmpnam.
review: www.parrotvm.org/svn/parrot/revision?rev=35030
r35031 | kjs++ | trunk/compilers/pirc/src (2 files): 13:36
: [pirc] no tempnam() function anymore; fix this later in a proper way.
: + fix a bug: .annotate can be first statement, in which case there's no instruction object in place. Just take the offset from lexer->codesize, which keeps track of this (and from which instructions take their offset as well).
review: www.parrotvm.org/svn/parrot/revision?rev=35031
r35032 | kjs++ | trunk/compilers/pirc/src (2 files): 13:40
: [pirc] fix some warnings on linux; missing prototype and a type cast.
review: www.parrotvm.org/svn/parrot/revision?rev=35032
r35033 | kjs++ | trunk/compilers/pirc/src: 13:44
: [pirc] fix a /* in a comment.
review: www.parrotvm.org/svn/parrot/revision?rev=35033
13:53 masak joined
dalek r35034 | jonathan++ | branches/bcanno/t/op: 13:54
: [t] Add tests for bytecode annotations and exceptions.
review: www.parrotvm.org/svn/parrot/revision?rev=35034
r35035 | Whiteknight++ | trunk/docs/book:
: [Book] Some updates to chapter 10 about compreg and compiler objects
review: www.parrotvm.org/svn/parrot/revision?rev=35035
masak jonathan: hallo. 13:55
jonathan masak: hej hej 13:57
masak :)
dalek r35036 | Whiteknight++ | trunk/docs/book: 14:05
: [Book] a small nit that's been bothering me. I need to update all chapter and section numbers
review: www.parrotvm.org/svn/parrot/revision?rev=35036
14:14 geof joined
jonathan Why might the headerizer miss a bunch of functions? 14:18
particle because it's told not to process that file? 14:19
jonathan: do you have spectest failures with rakudo?
jonathan Oh, it's only including the static ones. 14:20
dalek r35037 | pmichaud++ | trunk/languages/perl6/docs:
: [rakudo]: spectest-progress.csv update: 279 files, 6170 passing, 0 failing
review: www.parrotvm.org/svn/parrot/revision?rev=35037
jonathan particle: Not checked it in trunk for a couple of days. 14:21
particle: It's not skipping the file - it's packfile.c.
But also it only picks some of the other ones up for the header file. 14:22
Odd.
nopaste "jonathan" at 85.216.157.73 pasted "any clues? the headerizer generates header entries for the first function here, but not the second (and many others...)" (61 lines) at nopaste.snit.ch/15213 14:27
PerlJam jonathan: perhaps the macros are tripping it up somehow? (/me knows nil about the headerizer though) 14:29
dalek r35038 | kjs++ | trunk/compilers/pirc/src (2 files):
: [pirc] refactoring of code, needed for implementing tailcalls.
review: www.parrotvm.org/svn/parrot/revision?rev=35038
pmichaud jonathan: no clues here.
cognominal jonathan, I read here that headerizer was sensible to the function formatting 14:30
jonathan cognominal: s/sensible/sensitive/?
cognominal yes
it does not do true parsing 14:31
but maybe it has been fixed in the mean time
just a random clue
Coke looking at RT#62012, I suspect a misunderstanding of what <! means. 14:32
(and also some confusing examples.)
pmichaud Coke: you're correct. 14:35
Coke is replying to one of his emails on list now. 14:42
jonathan Found it. Dammit. 14:43
void
PackFile_Annotations_destroy(SHIM_INTERP, ARGMOD(struct PackFile_Segment *seg)) {
That's OK by our coding standards, right?
Whiteknight shouldnt the { be on it's own line? 14:44
jonathan We cuddle braces generally
But putting it on its own line makes the problem go away.
Ah, yes, we put the { on its own line it seems for functions. 14:45
Great bit of coding standard. "Cuddle braces. Apart from when you sholdn't."
PerlJam I thought the coding standard didn't like cuddled braces? 14:46
or maybe I'm just thinking of if statements in particular
jonathan We don't do them on ifs and fors as I understood it 14:47
Infinoid if statements are fine, I think
jonathan Well, it's kinda half-cuddling.
if (foo) {
}
else {
}
Infinoid function declarations need to be split, and so do the braces around "else"
jonathan but not } else {
Infinoid its kinda weird.
I've found cases where the headerizer won't generate a prototype for your function if the curly brace is on the same line 14:48
and other cases where it works just fine
jonathan Iv'e found the line in headerizer.pl that causes that too.
# Structs are OK if they're not being defined
@funcs = grep { !/^(static\\s+)?struct.+{\\n/ } @funcs;
Infinoid ah!
jonathan Suspect replacing .+ with [^)]+ would help.
Infinoid I'd like to replace some of the manually specified prototypes with headerized ones. It'd let me check their arguments properly. 14:49
dalek r35039 | jonathan++ | branches/bcanno/t/op: 14:50
: [t] Correct test plan.
review: www.parrotvm.org/svn/parrot/revision?rev=35039
Coke pmichaud: hurm. I am discarding my reply. not didactic enough. 14:51
Coke cries, as he has found the massive slowdown in tcl. 14:53
massive *recent slowdown.
(tracing)
PerlJam Are you crying because you don't know how to fix it? Otherwise it seems like a time for rejoicing instead. 14:54
Coke hurls code.google.com/p/partcl/source/bro...ray.pir#49 14:56
basically, if you trace something, the /easiest/ way to to implement the trace is to run some tcl code. But that means, running the tcl compiler to call uplevel ... which in turn invokes the tcl compiler. 14:57
so if someone activates a trace (which testing does, that's why I added this function), there's kind of a recursive invocation of the compiler.) 14:58
(only a few levels deep.)
dalek r35040 | jonathan++ | branches/bcanno (2 files):
: [core] Seatbelts for the annotations code.
review: www.parrotvm.org/svn/parrot/revision?rev=35040
Coke so the reason this is super slow is that tcl is slow by itself.
particle does every test activate a trace? 14:59
Coke it's part of the test harness setup.
they have a hash of, say, skip conditions. The hash isn't pre-populated, there's another has of initial conditions that contains code.
jonathan Ouch. 15:00
./include/parrot/packfile.h:701: error: nonnull argument references non-pointer operand (argument 1, operand 3)
Coke if you ask for a particular condition and it's unset, it goes to the initial conditions, invokes it, and stores the result in the hash you were actually asking after.
which, if you have a tclsh-speed shell, is no problem whatsoever.
Tene purl: irc log? 15:01
purl irc log is irclog.perlgeek.de/parrot/
jonathan Oh. ARGIN understanding fail.
Coke This might be a good time for me to work on [apply], which will give me anonymous HLL subs. Then I can curry this and just invoke a sub instead of recompiling each time. 15:02
Tene jonathan: think you could look at irclog.perlgeek.de/parrot/2009-01-06#i_808134 for me? issue with loadlib I was talking about earlier. 15:03
Tene sleeps now.
15:04 lu_zero joined
dalek r35041 | jonathan++ | branches/bcanno (2 files): 15:06
: [core] Fix some seatbelts.
review: www.parrotvm.org/svn/parrot/revision?rev=35041
Coke stops crying. 15:08
15:10 gryphon joined, mj41 joined 15:20 Andy joined
Infinoid Coke: turn that frown upside down! 15:22
tcl: puts "test"
polyglotbot OUTPUT[testā¤]
masak rakudo: sub foo {}; say foo.WHAT 15:23
polyglotbot OUTPUT[Listā¤]
masak I though this'd be Nil or something. 15:24
dalek r35042 | jonathan++ | branches/bcanno (3 files):
: [core] Clean up warnings from annotations code.
review: www.parrotvm.org/svn/parrot/revision?rev=35042
masak s/h/ht/ 15:25
Coke tcl: proc power {number power} { set val 1; while {$power != 0} { set val [expr $val * $number]; incr power -1; }; return $val }; puts "10**2 is [power 10 2]"
polyglotbot OUTPUT[10**2 is 100ā¤]
Coke tcl: proc power {number power} { set val 1; while {$power != 0} { set val [expr $val * $number]; incr power -1; }; return $val }; puts "2**10 is [power 2 10]"
polyglotbot OUTPUT[2**10 is 1024ā¤]
Coke Infinoid++ 15:26
jonathan masak: Yes, I think we have a ticket on that maybe.
masak oh, goodie.
Coke (bah. adding apply won't really help without some kind of compilation; otherwise I still have to rebuild the sub every time apply is invoked)
pmichaud rakudo: sub foo { return; }; say foo.WHAT;
polyglotbot OUTPUT[Nilā¤]
Coke tcl: [info args puts] 15:27
polyglotbot OUTPUT["puts" isn't a procedureā¤]
masak pmichaud: so falling out of a sub doesn't count as an implicit return? or is that the bug? 15:28
pmichaud falling out of a sub isn't a return. In particular, there's no control exception generated.
masak oh.
pmichaud (at least that's the way I understand it.) 15:29
whether an empty sub should return Nil is unspecced, but I suspect the answer is "yes".
masak :0
:)
Coke tcl: proc dump {args} {puts $args}; set a(1) boo; trace add variable a r dump; puts $a(1) 15:30
polyglotbot OUTPUT[booā¤]
masak let's hope we have a ticket for that, then.
jonathan Ah, if return is now handling back Nil, then the ticket I was thinking of is probably resolved.
pmichaud yes, that ticket is resolved.
jonathan OK, then we may want a new one. :-) 15:31
15:31 jhorwitz joined
dalek r35043 | jonathan++ | branches/bcanno (2 files): 15:31
: [core] Clean up one more warning introduced by annotations.
review: www.parrotvm.org/svn/parrot/revision?rev=35043
Coke hurm. 15:32
pmichaud sure. But I'd also like a spec clarification. :-)
Coke is there a way to ask polyglotbot which versions he's using?
Infinoid is there a way to ask parrot which versions it's using, from within tcl? 15:34
Tene: I think polyglotbot needs a "partcl" alias. 15:35
Coke Infinoid: I mean, svn versions. 15:36
sorry, should have said "revision"
Infinoid yeah, so did I
Coke no. much in the same way you can't ask parrot which svn revision it is.
Infinoid even if you can't query it, it's fairly predictable... it's rebuilt from cron quarter-hourly, on the quarter-hour. the builds take about 7 or 8 minutes, after which they're swapped into the live system (by updating a symlink).
Coke tcl: puts $tcl_version
Infinoid hmm. that's odd, considering we probe for it during Configure.pl 15:37
polyglotbot OUTPUT[0.1ā¤]
Infinoid has to drive to work, back later
Coke yes, but we don't put it into the built parrot, do we?
Infinoid I doc't know.
don't, too
jonathan OK, folks. Anyone who fancies building bcanno branch and giving it a test is most welcome now. 15:40
Beyond any issues anyone finds during that, I'm ready to merge.
dalek r35044 | kjs++ | trunk/compilers/pirc/src (4 files): 15:42
: [pirc] fix a bug. Constant nodes use value_type enumeration, not pir_type. Yes, this is bug-sensitive, but alternatives suck more.
review: www.parrotvm.org/svn/parrot/revision?rev=35044
Coke jonathan: grabbing a copy... 15:46
Whiteknight jonathan: you have any documentation about how annotations work?
pmichaud afk # reboot 15:47
jonathan Whiteknight: Yes, see pdd19 which mentions .annotate, and then exceptions PDD which tells you how to get annotations in force when the exception occurred.
I'm also going to propose an annotations op that will get for you, the current set of annotations that are in effect. 15:48
So we'll be able to implement things like $?FILE and $?LINE in Rakudo.
15:49 davidfetter joined
Coke jonathan: is there a way to put in annotations dynamically? 15:49
I am not certain I need this yet, but am curious. 15:50
jonathan Coke: As in, get a bytecode address and set an annotation at that address? 15:51
Don't have a way to do that at present.
It's probably not impossible either.
particle rakudo: say %*VM<config><revision>
polyglotbot OUTPUT[35044ā¤]
jonathan Coke: Would be interested to see your usecase for it. :-) 15:52
(If you do need it...)
Whiteknight jonathan, is that PDD19 in trunk, or PDD19 in branch? 15:58
jonathan Whiteknight: One in branch has changes. 16:00
Infinoid particle++ 16:02
Coke jonathan: all tests pass on bcanno on os x/86; checking tcl now. 16:07
Infinoid jonathan: parrot test PASS on linux/x86-64 16:08
jonathan Comments on my post to Parrot list from HLL developers also very welcome.
Coke++, Infinoid++ # thanks for testing 16:09
Coke (tcl looks fine as well, not surprising)
jonathan pmichaud: How's the branch going?
Coke: I'd have been very surprised if it had an effect on HLLs. 16:10
pmichaud jonathan: got distracted with family stuff yesterday. About to get back into it now.
jonathan pmichaud: OK. Anything you want help with on it?
I'm kinda blocking on doing much until it's merged.
pmichaud testing would be good. 16:11
jonathan Checking it out now. 16:12
pmichaud working on S06-multi/proto.t would be good. 16:13
and S06-multi/type-based.t
they're probably trivial fixes, but I suspect you can track them down as quickly as I can (and you can learn the revised structures in the process)
jonathan OK. 16:14
16:19 hercynium joined
dalek r35045 | kjs++ | trunk/compilers/pirc/src (2 files): 16:22
: [pirc] improve handling of different cases for invoking a .sub: .local, global_label and find-during-runtime options. (Too complex for a commit message, but it fixes some innocent bugs).
review: www.parrotvm.org/svn/parrot/revision?rev=35045
kj can anybody give an example of a built-in class that has methods, and what method? I'd like to test method-invocation in PIRC< , but namespaces are not handled yet, so can't create my own class. 16:25
dalek r35046 | Whiteknight++ | trunk/docs/book:
: [Book] Add some missing information about encoding: and charset: in string literals
review: www.parrotvm.org/svn/parrot/revision?rev=35046
jonathan Class has a bunch 16:26
kj ah yes, apparently it has "name"
thx
pmichaud String also has some. 16:27
and CodeString
purl CodeString is one of those that I think could give a nice performance win if it were written in C instead of PIR :-)
jonathan OK, any objects to me merging bcanno into trunk?
PerlJam purl: you have a long memory
purl PerlJam: excuse me?
jonathan *objections
kj jonathan++
Whiteknight purl forget CodeString
purl Whiteknight: I forgot codestring
Whiteknight jonathan+ 16:28
jonathan++
PacoLinux I have a build error in linux snv 34045 : src/exec_dep.h:35: error: expected identifier or '(' before '<<' token 16:30
jonathan PacoLinux: Sounds like you might have a merge conflict somewhere?
svn diff give anything?
dalek r35047 | Whiteknight++ | trunk/docs/book: 16:32
: [Book] Remove a mention of octal integers, which I don't think are supported, and add in binary
review: www.parrotvm.org/svn/parrot/revision?rev=35047
r35048 | jonathan++ | branches (31 files): 16:33
: Sync bcanno branch up with trunk, in preparation with merge.
review: www.parrotvm.org/svn/parrot/revision?rev=35048
nopaste "particle" at 76.121.106.245 pasted "rakudo test failure summary" (11 lines) at nopaste.snit.ch/15217
jonathan particle: That in trunk?
particle ayep
since pmichaud messed with NaN/Inf i suspect 16:34
jonathan *nod*
I see similar.
OK, what am I missing? 16:35
C:\\Consulting\\parrot\\trunk>svn merge --reintegrate svn.perl.org:/parrot/
branches/bcanno/
svn: Cannot reintegrate from 'svn.perl.org:/parrot/branches/bcanno' yet:
Some revisions have been merged under it that have not been merged
into the reintegration target; merge them first, then retry.
I've just got the branch sync'd up with trunk... :-S
oh, wait...
My trunk is not at latest. 16:36
jonathan tries svn up
Nope. Exact same error.
16:36 Theory joined
Coke when you updated the branch, did you do it the svn 1.4 way or the svn 1.5 way? 16:37
PerlJam jonathan: and did you merge trunk to branch first?
jonathan Coke: I've been using "svn merge trunk"
Coke (I'm assuming -reintegrate is some new 1.5 thing.)
jonathan (where trunk is the address of trunk)
particle yes, it is
jonathan: were there renamed/moved files?
if so, --reintegrate will fail. 16:38
jonathan particle: During the lifetime of the branch? Yes.
OK. So...what do I do?
particle they're hoping to fix that in 1.5.1
jonathan I'm hoping to merge a branch... :-S
particle they *were* ...
PerlJam yeah, aren't we at 1.5.4 now or somesuch?
jonathan OK, suggestions? 16:39
purl suggestions are welcome.
particle depends on which client jonathan is using
jonathan Indeed, purl.
purl indubitably
PacoLinux just made a new checkout and parrot builds fine, sorry
particle svn help # 1.5.2 here
jonathan Subversion command-line client, version 1.5.4.
particle ok
jonathan This is why I hate working in branches. It's not wroth the hassle...
particle well, you can use the old syntax
Infinoid I like working in git branches. checking that stuff into svn branches seems to increase the workload 5-fold 16:40
dalek r35049 | kjs++ | trunk/compilers/pirc/src (3 files):
: [pirc] fix bits for method invocation.
review: www.parrotvm.org/svn/parrot/revision?rev=35049
particle or svn propdel svn:mergeinfo WHATEVER_FILE_HAS_THE_PROBLEM
jonathan It doesn't tell me any file has a problem. :-|
particle: I never really understood the old syntax...
jonathan looks at the help 16:41
particle look at docs/project/committer_guide.pod
PerlJam jonathan: you should consider using git as your client :-)
Coke the hard way is to see what revision started the branch, then just merge from that to head from branch to trunk.
jonathan You know, if I take my branch, copy all of the files apart from the .svn directories into my trunk, and svn ci it'd work just great. ;-)
particle you should be able to see what rev started the branch by looking at svn:mergeinfo for the branch root dir 16:42
Whiteknight should probably look into git too, eventually
Coke presuming svn:mergeinfo is set by a simple cp when the branch is created. is it?
PerlJam or do the old way of "svn log --stop-on-copy"
Coke I'm sure you can find someone to volunteer to do the mergeback, j.
Infinoid I can do it tonight 16:43
jonathan Branch was created at 33279
Infinoid jumps up and down, waving and shouting "victim here, victim here"
jonathan Infinoid: OK, tag, you're it. :-)
Thanks!
Infinoid++
Infinoid np. I'll do it tonight after work 16:44
jonathan pmichaud: In rvar, I have:
Failed 49/261 test scripts. 347/7453 subtests failed.
Is that around what you'd expect?
particle coke: svn:mergeinfo is updated every time you merge from trunk to branch
Coke only if you do it a certain way, neh?
PerlJam Coke: only if you do the normal svn1.5 version of merging.
Coke (or with a certain client.)
pmichaud jonathan: I'm updating my spectest now also... will know how close it is in a second. That sounds about right, though. 16:45
PerlJam Coke: which jonathan has been doing
Coke has he? didn't sound like it. Ok. Good luck figuring out hte problem. =-)
nopaste "jonathan" at 85.216.157.73 pasted "pmichaud: test summary from me, for you to compare" (55 lines) at nopaste.snit.ch/15218 16:47
particle jonathan: cd trunk && svn merge -r33279:HEAD svn.perl.org/parrot/branches/bcanno
jonathan pmichaud: multi proto, syntax and type-based tests in S06 are failing.
pmichaud: Want me to look into those? 16:48
pmichaud jonathan: yes, that's consistent with what I'm seeing. I haven't done a lot of work there.
dalek r35050 | kjs++ | trunk/compilers/pirc/src (3 files):
: [pirc] fix a NULL pointer bug. Can't unshift onto an empty list.
review: www.parrotvm.org/svn/parrot/revision?rev=35050
particle Whiteknight: what's the word on the pcc refactor? 16:52
jonathan pmichaud: Question.
purl it has been said that Question. is &bar a closure? perl -le '{ sub foo { my $foovar="th0th rulz!"; sub bar { print "bar sez: @_; also, $foovar"; } } } &foo; &bar ("howdy");'
jonathan ':'?'(' ~ ')' <signature>
What is the ~ there?
particle jonathan: it means you want to match '(' <signature> ')' 16:53
jonathan So why not just write that? :-S
particle it's how STD.pm is written
when you're dealing with matching bracketing constructs, it's nice to see them appear next to each other 16:56
rather than having to scan forward visually to find the matching end bracket 16:57
dalek r35051 | jonathan++ | branches/rvar/languages/perl6/src/parser:
: [rakudo] A re-ordering of an alternation to account for not having LTM yet. Gets S06-multi/syntax.t to parse again.
review: www.parrotvm.org/svn/parrot/revision?rev=35051
jonathan ...and that gets us 2 less failing.
particle pmichaud: can i svn switch languages/perl6 to rvar, or do i need parrot/pge/pct updates as well? 16:58
jonathan I'm fairly sure pmichaud did at least one Parrot change (the shallow copying in inspect) that would matter. 16:59
particle ah, thanks
pmichaud yes, there are pct and core changes that matter. 17:04
17:06 Khisanth joined
jonathan pmichaud: $block<signature> := 1; 17:06
17:07 pdcawley joined
jonathan Can we now generally set data like this on PAST nodes? 17:07
pmichaud yes.
jonathan That's new in rvar, right?
pmichaud no, it's been in trunk also, but I hadn't declared it as "allowed" yet.
jonathan Ah, OK. 17:08
pmichaud I decided it's too useful to not have something like that available.
jonathan Agree.
pmichaud be careful because there's currently a conflict with other PAST::Node attributes (which will change in next release)
jonathan Ah, OK.
pmichaud i.e., $block.blocktype(...) currently uses $block<blocktype>
(that will change to be something more...private)
jonathan One reason for a test fail I just found is that we need to attach an (empty) signature object to subs and methods that are like sub foo { ... } 17:09
Otherwise using them as a multi will blow up.
pmichaud you mean as in "multi sub foo"...? 17:10
jonathan multi foo { ... }
Yes.
pmichaud okay.
jonathan Plus you should still be able to say &foo.signature, I think.
pmichaud all subs should get a signature object, then.
jonathan *nod*
pmichaud that should be handled in routine_def, I suspect.
jonathan That's what I was thikning. :-)
And I can check $block<signature>
Neat.
pmichaud I don't think checking $block<signature> quite works, because of placeholders 17:11
jonathan Oh? 17:12
Don't they lead to the block having a signature?
pmichaud block<signature> is a flag saying that we matched the <signature> subrule
it's not a "does this block have a signature" general thingy yet.
jonathan Ah.
pmichaud currently placeholders don't appear to generate a signature object either. 17:13
the only place where $block<signature> is used at the moment is to indicate whether to panic if a placeholder is encountered.
jonathan Yes, I just discovered that. 17:14
pmichaud you can change that to <have_signature> if that makes more sense.
or something else.
or maybe flag_signature
jonathan Maybe we need two flags?
17:14 pjcj joined
jq how does one truncate a string in pir? 17:14
jonathan Oh, but placeholders don't produce a signature yet. Hmm.
pmichaud they'll need to, but I'd skip worrying about that for now. 17:15
I don't know that we have any tests for it yet.
In general if there's not a test for something I'm not worried about fixing it until after the merge.
jq: substr
17:15 davidfetter joined
pmichaud $S1 = substr S0, 0, <truncate_length> 17:15
jq but it's not possible inplace? 17:16
pmichaud substr might be able to do that also
substr $S0, <truncate_length>, *, ''
where * is some magic "to end of string" value that I'd have to look up. :-| 17:17
particle perhaps -1
jq indeed, it works
thanks guys 17:18
pmichaud normally negative indices mean "from end of string"
so I'd think that -1 might leave the last character in place.
particle -1 is the last character
Coke for perlish values of normal. =-P 17:19
pmichaud actually, I was thinking in the Parrot context in this case.
in parrot, negative indices typically mean "from end of string"
particle i'm getting parrot test failures in rvar 17:20
ah, looks like many (maybe all) are TODO
i'll know when this finishes
pmichaud possible -- I hadn't tried 'make test' on core yet.
I want to get rakudo working first before worrying too much about core. 17:21
17:21 ruoso joined
pmichaud I need to go fetch some lunch -- bbiab. 17:22
#parrotsketch in 68
Coke adds a stupid shell script to checkout a fresh copy of a branch and test it. 17:26
Coke wonders if smolder deals with branches well.
dalek r35052 | jonathan++ | branches/rvar/languages/perl6/src/parser: 17:27
: [rakudo] Need to give subs/methods an empty signature if they don't have one declared by the user or from placeholders (which don't generate a signature yet - added a comment that we need to do that later).
review: www.parrotvm.org/svn/parrot/revision?rev=35052
r35053 | kjs++ | trunk/compilers/pirc/src (3 files):
: [pirc] fix bytecode generation for methodcalls.
review: www.parrotvm.org/svn/parrot/revision?rev=35053
r35054 | kjs++ | trunk/compilers/pirc/src: 17:28
: [pirc] fix a logic error.
review: www.parrotvm.org/svn/parrot/revision?rev=35054
pmichaud jonathan: I'd prefer that $block<signature> actually end up being the signature node instead of a flag. 17:29
then placeholders would have an easy way to add to it.
In fact.
$block<signature> should be the node, and that node should have a "complete" flag on it of some sort if it's already complete.
instead of an explicit_signature flag.
jonathan Ah, that would work too. 17:30
pmichaud so placeholders check $block<signature><complete> for the panic, creating $block<signature> if needed.
Coke particle: I got no failures in rvar branch.
pmichaud or something like that. 17:31
back in a bit
particle when's the last time trunk was merged to rvar? i'm just getting one failure
i think i fixed it in trunk already
Coke (r35051)
(is where I get no failures)
pmichaud particle: it's been a few days since I merged trunk to rvar. 17:32
particle ok, then. should be good after merge 17:33
pmichaud if I've done it at all.
I'm typically not a fan of merge trunk to branch -- I tend to create new branch from trunk and merge old branch to new 17:35
PerlJam pm: why?
17:36 tomyan left
pmichaud I find it easier to keep track of the diffs that way. 17:37
tewk PerlJam: because trunk changes get intermingled in with branch changes.
That is why rebasing operations are soooo nice.
pmichaud the way I do it is just the same process as merge branch back to trunk
except I'm merging branch into "copy of trunk" for my intermediate steps.
tewk pmichaud rebases manually by creating a new branch and applying the changes from the old branch. 17:38
pmichaud correct.
PerlJam Makes sense. 17:39
tewk one of my favorite git features. :)
PerlJam (except for why you're not using git yet :)
17:40 hercynium joined, contingencyplan joined
dalek r35055 | kjs++ | trunk/compilers/pirc/src (2 files): 17:41
: [pirc] work on methodtailcall. probably fixed, need more tests.
review: www.parrotvm.org/svn/parrot/revision?rev=35055
kj mmm. Weird. I may have found a bug in method tailcalls in parrot. 17:43
nopaste?
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl i think nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others)
nopaste "kjs" at 86.95.212.32 pasted "Method tailcalls: this doesn't work" (16 lines) at nopaste.snit.ch/15219
Coke tailcalls do occasionally not work.
I am not sure there is a proper todo test, however. 17:44
kj oh, it's a known issue?
dalek r35056 | jquelin++ | trunk/languages/befunge (3 files): 17:45
: loading befunge program now working
review: www.parrotvm.org/svn/parrot/revision?rev=35056
Coke like I said, I've seen it, but am not aware of a test for it.
particle please create a trac ticket 17:46
Coke finds a git overview... that uses parrot as an example. 17:47
utsl.gen.nz/talks/git-svn/intro.html#wtf-why
kj written by Sam Vilain 17:48
... not a stranger to parrot,iirc
Coke my biggest git question is how to model shared branch development: i definitely see how you can use local branches to simplify, but how to collaborate with that style, if those changes are not pushed upstream to a branch in svn? 17:54
tewk Coke: parrot.org needs to have a git server installed. 17:57
Coke would that obviate our svn server?
pmichaud tailcalls to methods written in C might not work.
jonathan pmichaud: Ah, it's not surprising that multis aren't working. YOu've removed one of the really important bits of type logic. :-)
pmichaud I know that returning tailcalls to calls from C doesn't work.
jq can i declare .local vars in a file outside a .sub?
tewk each committer could then have there own git repo where they could publish working branches.
pmichaud jonathan: s/removed/haven't restored/ 17:58
Coke jq: nope.
jonathan pmichaud: Sure. :-)
jq then how can i create lexicals for a file?
jonathan pmichaud: Now the failures make a lot more sense to me...
pmichaud I know that I hadn't restored all of the type logic yet.
jonathan pmichaud: We were passing some tests by accident.
Coke lexicals in parrot are sub-scoped, neh?
jonathan Which confused me into thinking we had more of it still there than we do.
tewk Coke: You could get rid of svn, but that is a policy decision. 17:59
jq so i need to create a global var?
pmichaud jonathan: so what piece is missing?
Coke jq: I /think/ so.
kj jq: depending on what you want to do,yes
Coke I would expect the rakudo folks to be able to answer that better.
kj you can also nest .subs 18:00
Coke kj: oRLY?
purl YA RLY.
tewk installing git at parrot.org would let committers experiment without disturbing the current work model.
pmichaud .subs nest? since when?
kj well,with :outer
Coke pmichaud: well, about 2001. =-)
jq how is it achieved?
jonathan pmichaud: The stuff that sets up type and constraints, and separates out different sorts of types.
Coke (but literal nested subs have long been removed.)
jonathan pmichaud: Will review/pop it back in.
pmichaud jonathan: I haven't done constraints yet
kj sorry, I said it wrong; you can create .subs that are lexically nested 18:01
pmichaud (as in 'where' clauses)
jq sthg like: global "i" = i
?
kj jq: using the :outer() flag
jq hmmm.
.local int i :outer
kj .sub foo :outer('bar') # means that foo has an outer sub, called bar. IOW, bar encloses foo, or foo is nested in bar
jonathan pmichaud: That's fine - once you or I have restored them, this code will handle 'em.
Coke news.bbc.co.uk/2/hi/americas/7721889.stm :: Protecting Argentina's parrot colony
pmichaud you can work on restoring them if you'd like :-)
kj no. .local <type> <name> are just aliases for registers.
jonathan pmichaud: OK. 18:02
jq kj: but i don't want to have nested subs
kj what's the problem you want to solve?
PerlJam tewk: someone probably could setup a git repo that stays in sync with the svn repo and vice versa via hooks
jonathan I'm still trying to get into my head everything that's not restored yet, and also not to make a mess of the nice setup we now have while putting them back in, which also means getting all of the new ways of doing stuff into my head. :-)
jq i want some vars to be shared between some subs
those subs are all in the same file
but i'm ok with a global var too
pmichaud jonathan: just do it with baby steps. I'll review each of your commits and let you know where things ought to change (as I just did for <signature>) 18:03
kj yes, I think that would be the solution. OR, and not sure whether there's any side effects to it, is to create a sub, and let all others have an outer pointer to that. Al
jonathan pmichaud: Sure. I will go back and fix that one up soon - just want to get this missing bit of type logic back in for multis.
kj all .lex'icals are then accessible from the other .subs
pmichaud jonathan: sounds great.
jq kj: quick & dirty is fine with me
so i'll use a global 18:04
kj quick&dirty->globals
jq global are achieved with: global "i" = i ?
kj no
jq then how?
purl i heard then how was it intended that you display a recursive data structure?
kj within one sub, you need to use one of the global ops. Most easy would be to use {set/get}_global 18:05
tewk PerlJam: I think we should do one way svn ->git for right now. its easier not to get screwed up that way.
dalek r35057 | jonathan++ | branches/rvar/languages/perl6/src/parser:
: [rakudo] Re-instate functionality of ;;, and set multi_invocant on parameters. This makes some tests that passed for the wrong reasons before now fail, which I'll resolve soon.
review: www.parrotvm.org/svn/parrot/revision?rev=35057
kj .sub main\\n $P0 = new "Hash"\\n set_global "foo", $P0\\n.end\\n
jq: there's a nice wikibook which explains PIR very nicely 18:06
tewk when is svn going to move to parrot.org? that would be a good time to get an official git mirror going.
pmichaud jonathan: why the substr() ? 18:07
jonathan pmichaud: Because the rule captures whitespace too.
pmichaud okay. substr is often wrong.
jonathan pmichaud: I remembered getting bitten by that *last* time I implemented ;; 18:08
Coke tewk; ISTR in the next 2 weeks.
jonathan pmichaud: I'll happily take suggestions of a different/better way.
Coke jq: the 'global' syntax was deprecated a while back, and removed recently.
pmichaud ...double-checking STD.pm 18:09
change param_sep to be (...) instead of [...]
purl pmichaud: that doesn't look right
pmichaud then you can check [1] instead of doing the substr.
jonathan Ah, STD.pm did that?
pmichaud er, [0]
no, but STD.pm probably should do that, for the same reasons.
jonathan Ah, OK.
I did consider doign that and then thought, "no, should do what STD.pm does..." ;-) 18:10
pmichaud either that or the ** <param_sep> in the signature token should be ** [ <.ws> <param_sep> ]
jq kj, coke: thanks
pmichaud that's a place where I think STD.pm ought to change.
the substr is probably not a good approach, because the white could conceivably be leading ws 18:11
jonathan Oh, yes, good point...
Changing now.
kj jq: np. Check out this: en.wikibooks.org/wiki/Parrot_Virtua...esentation
shorten kj's url is at xrl.us/bebo9u
pmichaud and yes, multi_invocant looks good -- the way I was thinking it should be. 18:12
...I'm curious, though -- would it be better to mark the params that *aren't* multi_invocants? 18:13
dalek r35058 | jonathan++ | branches/rvar/languages/perl6/src/parser (2 files):
: [rakudo] Use capture rather than substr for detecting ;;.
review: www.parrotvm.org/svn/parrot/revision?rev=35058
jonathan Well, we mark all of them, one or the other.
At the moment.
purl i heard at the moment was just goes BZZZZZZZT if you do anything slightly wrong
pmichaud what about placeholders?
I'd prefer to say that parameters are assumed multi_invocant unless marked otherwise.
dalek r35059 | jquelin++ | trunk/languages/befunge (3 files):
: debug initialization ported to modern pir
review: www.parrotvm.org/svn/parrot/revision?rev=35059
jonathan We ain't making a signature for them a thte moment... 18:14
pmichaud I'm thinking of when we do.
jonathan We'd probably want them to have multi_invocant => 1, yes.
pmichaud which is why I think that should be the default.
jonathan Or could modify Perl6MultiSub and then only mark those that are not multi-invocants.
pmichaud right
that's what I'm thinking.
I'd rather not be storing defaults.
only exceptions to the default. 18:15
jonathan I'm trying to remember if there's a reason it's done the way it is...
I suspect it musta made something easier...
pmichaud even if we do have to store multi_invocant, I'd rather that add_param do it
and not actions.pm
i.e., add_param can say "oh, no multi_invocant entry, so set it to 1) 18:16
jonathan That would mean _more_ code in actions.pm to check if we should add that parameter...
pmichaud it's the same as what you have no.
now.
just invert $multi_inv 18:17
jonathan Huh? But then we're still setting a 0/1.
pmichaud just a sec.
diff explains better.
nopaste "pmichaud" at 72.181.176.220 pasted "multi_inv suppression" (24 lines) at nopaste.snit.ch/15221 18:19
pmichaud oops, one more change.
nopaste "pmichaud" at 72.181.176.220 pasted "multi_inv suppression #2" (24 lines) at nopaste.snit.ch/15222 18:20
pmichaud the point being that we no longer have to generate :multi_invocant for placeholder params.
jonathan *nod* 18:21
But needs me to fix up Perl6MultiSub too.
pmichaud and our trees are correspondingly smaller, since the vast majority of params are multi_invocant
jonathan Sure.
pmichaud rebooting.
purl rebooting is the only way to do that i think
jonathan Ah, no, I can just set the value to 1 in add_param for now. 18:22
dalek r35060 | allison++ | branches/cc_restart (3 files): 18:24
: [calling_conventions] Renaming 'Parrot_pcc_invoke_sub_from_sig_object'
: to 'Parrot_pcc_invoke_from_sig_object'.
review: www.parrotvm.org/svn/parrot/revision?rev=35060
18:24 allison joined, barney joined
dalek r35061 | jquelin++ | trunk/languages/befunge: 18:26
: moved argv parsing in a sub
review: www.parrotvm.org/svn/parrot/revision?rev=35061
kj #ps in 3 18:28
pmichaud right -- that's what i meant by "if we do have to store multi_invocant, I'd rather that add_param do it" 18:30
18:31 chromatic joined
pmichaud #ps in -1 18:31
Whiteknight allison, have you figured out what the problem was in the calling_conventions branch? 18:34
chromatic Ghosts.
Whiteknight Ghosts?
purl In this room where shadows live / And ghosts that failed learned time forgives / Welcome friends, please stay awhile / Our story start with one small child ...
allison Whiteknight: so far I've managed to avoid reproducing the problem. I've been cleaning up the changes as I apply them, so maybe will avoid entirely.
chromatic Monkeys?
purl If you're like me, you fucking hate monkeys. Hate 'em. Well, it's one thing to espouse a sort of all-purpose antipathy - that is the domain of the armchair, part-time nihilist. It is another thing altogether to be gripped by conviction in such a way that you strike a monkey so hard that he launches as if from a cannon, at speeds well over one hundred miles per hour.
allison Whiteknight: I'm sticking to a strict "every commit passes all tests" policy. 18:35
Whiteknight good policy
I just wish I could figure outwhat caused the problem in the first place 18:36
allison Whiteknight: I can pretty much guarantee it was a mishandled context somewhere. 18:37
particle yep
allison Whiteknight: and, it might not even be in your code, it could be a bug elsewhere in the new context stuff that your code just happened to expose
Whiteknight I can't wait to get started on turning contexts into PMCs 18:38
I guarantee I'm going to mishandle a lot of them when that happens :)
dalek r35062 | jquelin++ | trunk/languages/befunge:
: maths.pasm moved to pir
review: www.parrotvm.org/svn/parrot/revision?rev=35062
allison Whiteknight: I still haven't flipped the switch of having existing calls to Parrot_PCCINVOKE use the new call signature PMC, so that may expose it.
dalek r35063 | jquelin++ | trunk/languages/befunge: 18:39
: oops, forgot to remove old file
review: www.parrotvm.org/svn/parrot/revision?rev=35063
Whiteknight oh okay. That was the biggest change so probably the most fraught with danger
allison Whiteknight: yes, I'll be glad to remove one more custom memory management implementation by turning contexts into PMCs 18:40
dalek r35064 | jquelin++ | trunk/languages/befunge:
: initializing vars being used later on
review: www.parrotvm.org/svn/parrot/revision?rev=35064
r35065 | kjs++ | trunk: 18:43
: [MANIFEST] regenerate manifest after some files were deleted and added.
review: www.parrotvm.org/svn/parrot/revision?rev=35065
barney After moving the Pipp sources into github, what would be a good approach for issue tracking ? 18:44
allison barney: what does core PHP development use?
chromatic Unicorn blood.
dalek r35066 | jonathan++ | branches/rvar/languages/perl6/src (2 files): 18:45
: [rakudo] Change the way we set up multi_invocant. Also default type to Any if it's not set. This gets us through - though partly failing - S06-multi/syntax.t.
review: www.parrotvm.org/svn/parrot/revision?rev=35066
allison barney: I'd lean toward adopting customs of the language community your working with, but we can also create a trac.parrot.org instance if that's useful
barney cvs and Track I think
pmichaud barney: fwiw, I set up a launchpad account for pynie.
you could do something similar for pipp
trac might be good also. 18:46
Whiteknight ha! Unicorn blood!
allison ah, launchpad provides issue tracking for free
pmichaud if we didn't already have rt.perl.org, I'd probably go with a trac instance on parrot.org though.
allison and, launchpad integrates with trac
jonathan pmichaud: That last commit gets things working with multi_invocant as you suggested. 18:47
pmichaud jonathan: yes, it looks good to me. 18:48
barney I'll try to get ahold of Johannes SchlĆ¼ter, pumįø±in of PHP 5.3, before making any move
pmichaud jonathan: this approach means that placeholders can do a simple 'add_param' and have type+multi set correctly automatically.
jonathan pmichaud: Indeed.
pmichaud that's much better also.
allison barney: good idea 18:49
purl allison: Good Idea: Visiting picturesque McLean, Virginia. Bad Idea: Visiting picturesque McLean Stevenson.
Coke snrks at purl. 18:50
pmichaud I wonder if eventually it'll be worthwhile to do the same for itype. I'll keep it in mind. 18:51
18:51 hudnix joined
jonathan itype? 18:51
dalek r35067 | jquelin++ | trunk/languages/befunge:
: fetching current instruction character
review: www.parrotvm.org/svn/parrot/revision?rev=35067
pmichaud "implementation type" 18:52
for example, the implementation type of @a is Perl6Array
particle we need to make sure our copyrights are up to date before 1.0
pmichaud as opposed to the value type
jonathan OK.
pmichaud in "my Int @a;" @a has an implementation type of Perl6Array and a value type of "Int"
jonathan -ish 18:53
They're parameteric types.
pmichaud but with "my Int @a is MyArray" @a has an implementation type of MyArray and a value type of "Int"
particle rather than container type? 18:54
or variable type?
pmichaud I suppose one could call it a container type -- the synopses say (or once said) "implementation type"
jonathan Is that not the same as my @a is MyArray of Int?
pmichaud yes, that's the same
jonathan Which thus boils down to something like MyArray[:of(Int)] 18:55
pmichaud I'm not sure that's right.
From S02: Perl variables have two associated types: 18:56
their "value type" and their "implementation type".
jonathan I think that was the outcome of a discussion I had with Larry.
pmichaud I'm going by the synopsis.
jonathan I'm working on S14. ;-)
particle ok. that's fine, it's just not the language we generally throw around
hopefully now (or soon) it will be :) 18:57
jonathan But seriously, I am trying to work out exactly how all of these are related.
pmichaud according to S02, MyArray[:of(Int)] would correspond to my MyArray of Int ....
not to my Int ... is MyArray
dalek r35068 | kjs++ | trunk/runtime/parrot/include: 18:59
: [runtime] fix old PIR syntax; .return -> .set_return
review: www.parrotvm.org/svn/parrot/revision?rev=35068
jonathan That begs the question of, how on earth does Int in this case end up being a type parameter to MyArray...
Ah, because there's a difference between
my MyArray[:of(Int)] @foo;
And
my @foo is MyArray[:of(Int)];
pmichaud correct. 19:00
jonathan Is that not what I said above?
pmichaud I don't think they're the same.
jonathan What aren't?
purl aren't is a type of verb or a contraction
Whiteknight aren't is not a verb 19:01
pmichaud thinking.
purl Oooh he is soooo fine!!!
pmichaud for the time being, I'm much more comfortable with the idea of implementation type being separate from value type, as described in S02. 19:02
if you can point me to the relevant conversation you had with TimToady, I'll re-evaluate :-) 19:03
jonathan Until we have an implementation of parametric types, it's rather moot anyway ATM.
pmichaud in which case having them separate is easier :-)
jonathan I'm sure the details will fall out more easily once we have something to play with. 19:04
pmichaud anyway, 'itype' tells us how to create the container
because my Int @foo; should create an Array, not an Int :-)
jonathan We can for now, sure, but I think the value type for an array is goig to want to become a type parameter to the implementation type. 19:05
Oh, I agree. I'm not proposing anything otherwise. :-)
dalek r35069 | kjs++ | trunk/examples/streams:
: [examples] remove old syntax; global->get_global
review: www.parrotvm.org/svn/parrot/revision?rev=35069
pmichaud I can see how that might work, yes. Anyway, it'll be easy to fix once we know for sure. 19:06
since it's mostly buried in add_param and <itype> stuff.
jonathan Sure.
I'm still getting a lot of this straight in my head.
dalek r35070 | kjs++ | trunk/examples/sdl/tetris: 19:08
: [examples] fix old syntax/semantics of PIR.
: invokecc $P0\\nret = I5 ==> ret = $P0()
review: www.parrotvm.org/svn/parrot/revision?rev=35070
r35071 | kjs++ | trunk/examples/sdl/minesweeper: 19:14
: [examples] fix old PIR syntax
review: www.parrotvm.org/svn/parrot/revision?rev=35071
r35072 | kjs++ | trunk/examples/sdl/tetris (3 files):
: [examples] fix old PIR syntax
review: www.parrotvm.org/svn/parrot/revision?rev=35072
19:17 uniejo joined
Coke gah. CFMX doesn't let you define a method on an object with the same name as a global. :| 19:25
*global function 19:26
dalek r35073 | kjs++ | trunk/examples/sdl/minesweeper: 19:27
: [examples] fix old syntax. new $I0-> new "SDL::Image".
: and other fixes.
review: www.parrotvm.org/svn/parrot/revision?rev=35073
r35074 | kjs++ | trunk/examples/sdl/lcd: 19:31
: [examples] fix usage of 'global' kw.
review: www.parrotvm.org/svn/parrot/revision?rev=35074
19:32 uniejo joined
dalek r35075 | kjs++ | trunk/examples/sdl/lcd: 19:33
: [examples] more clock fixes. If only I could my own clock.
review: www.parrotvm.org/svn/parrot/revision?rev=35075
Whiteknight allison, I have a question for you. I've been thinking it might be more efficient to do MMD distances as a Levenshtein distance on signature strings instead of manhattan distance over a type tuple array PMC 19:36
allison Whiteknight: the spec allows different languages to choose different strategies for MMD calcuations 19:37
Whiteknight I was talking about internally to Parrot
and how would an HLL specify the MMD calculation?
jonathan Whiteknight: Rakudo does it by subclassing MultiSub, which I think is what the PDD suggests too. 19:38
allison Whiteknight: by subclassing MultiSub
jonathan: yes
Whiteknight okay
Infinoid allison: is there anything I can do to help out with trac that doesn't require knowing much python?
Coke I find that I just have to click on buttons on the web. 19:39
allison Whiteknight: so, at some point, if you want to experiment with Levenshtein distance, you can do it in a subclass
Infinoid: it's just a web interface
Infinoid: we aren't actually adminning the install, our hosts do that
Whiteknight I might just do that, if we can find a way to create fewer PMCs in a PCCINVOKE and reuse more cached information, that would be a net plus 19:40
Infinoid in that case, you said you were open to volunteers, so how can I help?
allison Whiteknight: well, finishing the calling conventions refactors will make a huge difference there
(not just the current branch I'm merging in, but a few other key things) 19:41
chromatic Whiteknight, reducing the cost of calling conventions is our biggest performance goal.
Coke chromatic: do you remember the 4x slowdown I mentioned? 19:43
Whiteknight I know! Currently a type tuple PMC is created as part of a normal PCCINVOKE
if we can avoid creating type tuple PMCs in all cases, that's a savings 19:44
Coke It was very likely all due to adding basic "trace" support in partcl. Which invokes the tcl compiler on something that invokes the tcl compiler on something everytime someone does $P0['foo'] (for a $P0 that's being traced)
19:44 allison_ joined
dalek r35076 | kjs++ | trunk/examples/nci: 19:44
: [examples] fix 'invoke' into 'invokecc P0'. No longer implicit ops.
review: www.parrotvm.org/svn/parrot/revision?rev=35076
chromatic Coke, did you remove it?
Whiteknight, I looked into delaying that type tuple, but couldn't find an easy way to do so. 19:45
Coke chromatic: I commented it out to test something that didn't rely on it in a local co. 19:47
Whiteknight chromatic: I'm not talking about delaying it, I'm talking about deleting it outright. We don't create tuples and then we use a Levenshtein distance on the signature string instead of a manhattan distance on the tuple
Coke unfortunately, it's required for several .test files to function properly. 19:48
Whiteknight I'll work on a prototype proof-of-concept
Coke chromatic: I think this is going to force me to think about compilation again.
(since invoking the compiler at runtime is so expensive.) 19:49
dalek r35077 | kjs++ | trunk/examples/past: 19:51
: [examples] no longer bare method names.
review: www.parrotvm.org/svn/parrot/revision?rev=35077
Tene purl: parrot-dev? 19:52
purl parrot-dev is mailto:parrot-dev@lists.parrot.org or lists.parrot.org/mailman/listinfo/parrot-dev
chromatic I don't see how a Levenshtein distance will work. 19:53
Whiteknight well, it wouldn't be a "normal" one, you would have to modify it to ignore our adverb modifiers
actually be more like a hamming distance on the upper-case letters in the signature
chromatic More than that, it doesn't have anything to do with contravariance or covariance. 19:54
dalek r35078 | kjs++ | trunk/examples/nci: 19:55
: [examples] fix wrong syntax, but still doesn't work. "null libc"?? Why null and why not load the lib?
review: www.parrotvm.org/svn/parrot/revision?rev=35078
Whiteknight yeah, should definitely be a Hamming distance instead of a Levenshtein distance, but the idea is the same: Do the distance calculation on the signature string directly instead of on a separate tuple array 19:56
chromatic I can see that working only if you're looking for exact match, but that's not a complete multidispatch system.
Suppose you have a MyInt invocation and your best fit candidate is Integer. 19:57
How does a Hamming distance help there?
kj, dlfunc on a NULL shared library pointer usually (per POSIX) means to dlfunc from the current shared library (or one of the symbols currently available). 19:59
That doesn't work so well on pseudo-POSIX platforms like NeXT^H^H^H^HMac OS X, but it works on real Unix-like platforms.
Coke kj++ trac report. 20:00
kj chromatic: oh ok. thanks for the explanation
chromatic: could you check whether this works: ./parrot examples/nci/ls.pir ?
sjn chromatic: would you be interested in coming to Nordic Perl Workshop in April and give a talk about Perl6 (or something else relevant?) 20:01
chromatic kj, will do shortly.
sjn, that depends on my schedule.
20:01 uniejo joined
allison Whiteknight: we can refactor the current MMD dispatch to create fewer PMCs without changing the algorithm 20:01
kj ok. no hurries. Just curious whether it works now on non-windows
sjn chromatic: www.perlworkshop.no/npw2009/cfpapers.html
20:01 ruoso joined
chromatic kj, I'm surprised that POSIX trick works on Windows! 20:01
kj it doesn't 20:02
hence the 'doesn't work' comment in thecommit
but the code seems correct to me (in ls.pir)
Coke kj: new iterator, field, field = .ITERATE from start should probably be replaced with "foo = iter bar"
sjn chromatic: we're trying to get a Perl6/Parrot hackaton up and running too (right after NPW)
Coke (and you can then remove the .include of iterator types.
and kj++ for cleaning up examples. =-) 20:03
sjn www.perlfoundation.org/perl6/index....katon_2009
shorten sjn's url is at xrl.us/bebpnx
kj Coke: will have a look. I'm not so fluent in PIR
Coke: a number of PASM examples assume the old calling conventions, with fixed registers 20:04
chromatic kj, it works for me on 32-bit x86 Linux.
kj eh, so X5 holding first argument
chromatic: great. Doesn't on windows, but no idea how to fix that
Coke I don't really have a problem with deleting extremely old examples that aren't easily updated. 20:05
Tene Mail about the loadlib/load_bytecode/HLL issue sent to parrot-dev
kj thing is, I don' really enjoy rewriting that kind of stuff
not in PASM anyway
chromatic libc = loadlib 'libc'
Coke Tene: why not use .loadlib ?
Tene Coke: perl6.pir already has .loadlib 'perl6_group' 20:06
chromatic That may or may not be the right libc name on Windows or Darwin, but it works on Linux without the dlopen NULL trick.
Tene but when I go to load_bytecode perl6.pbc, it fails due to attempts to use Perl6Str
Which is defined in perl6_group.so
I'm entertained by the frequency of "I'm writing a compiler for X, but I'm not so fluent in X" in the parrot world. :) 20:08
chromatic perl6.pbc should load perl6_group.so.
Coke tene: see also coke:tcl
Tene chromatic: it does load it with .load_bytecode at compile time. That doesn't work right when perl6.pbc is load_bytecode'd from a different .HLL. Even adding a :load :init :immediate :omglol sub to perl6.pir that uses the loadlib op doesn't work. 20:10
chromatic: the only way I've found to successfully load_bytecode perl6.pbc is to do it from the same .HLL as perl6.pbc wants to run in or at least do the loadlib or .loadlib in that .HLL 20:11
pmichaud Tene: is this specific to perl6.pbc, or does the problem exist for any hll? 20:19
or is it "any hll that needs a .loadlib"?
Tene pmichaud: it exists for any HLL with custom pmcs.
yes, the latter.
purl or batter or letter or butter
pmichaud okay.
thanks.
Tene purl: forget the latter
purl Tene: I forgot latter
Tene This means that if this isn't a bug, every other language will need to special-case Perl 6. 20:20
pmichaud it's definitely a bug.
Tene and... tcl and pipp, I think?
kk, thx
pmichaud the common case will be languages that have custom PMCs or C code.
i.e., .loadlib is the comon case, not the special case. 20:21
*common
Coke does perl6.pbc have a .HLL 'perl6' at the top? 20:23
pmichaud at the moment, no.
it will, though.
Coke that might be part of the issue.
pmichaud I think Tene is working from a case where it did.
Tene Coke: doesn't help 20:24
Coke: I tried adding .HLL 'parrot'
dalek r35079 | kjs++ | trunk/compilers/pirc/src (5 files): 20:26
: [pirc] implement NCI_CALL bytecode generation + cleanups.
review: www.parrotvm.org/svn/parrot/revision?rev=35079
Tene Infinoid: if you want to add it, go ahead. 20:29
Infinoid: or you might be able to talk Coke into adding it.
Coke ?
Tene Coke: 08:35 #parrot: <@Infinoid> Tene: I think polyglotbot needs a "partcl" alias. 20:30
Coke I have no idea how to modify polyglotbot.
(and have no access to feather3)
Tene I can give you an account. 20:31
Coke: want an account on feather3? 20:32
Coke <shrug> 20:34
pmichaud mail about root classes sent. 20:35
Coke pmichaud: why not add opcode variants that take an HLL? 20:38
pmichaud Coke: doesn't solve :multi
(besides increasing our opcode load)
Coke our opcode load is already insane. there's no point in worrying about that.
IMO.
pmichaud oh, I think there is. 20:39
somehow I don't want to see
subclass
subclass_root_hll
subclass_hll_root
subclass_root_root
Tene subclass_subclass_hll_subclass_root
pmichaud (depending on whether we're creating a local subclass from a foreign class or vice-versa) 20:40
every time we create a specialized opcode, that actually makes it *harder* for code generators to deal with.
it's far easier to put the information into the operands.
Coke nevermind.
Is there actually a need for :multi on hlls other than your own? 20:42
pmichaud yes.
for example, I need to be able to multi-dispatch on a Class object
Coke I appreciate the thought, but it seems out of place with previous discussions about HLL interaction being on your own.
cognominal jonathan, how cold in slovaquia? 20:43
pmichaud same for Role and NameSpace, I suspect.
Coke why not keep :multi(CoreType) vs. :multi(['hll type']) ? 20:44
pmichaud because (according to allison) :multi(CoreType) is really :multi(['CoreType']) 20:45
Coke ... then we should eliminate it.
20:46 Whiteknight joined
pmichaud we had a very long discussion about this last week. She absolutely does not want to have strings mean something different from namespaces here. 20:46
I agree that we should eliminate :multi(CoreType)
Coke and 'coretype', for that matter.
pmichaud (and allison agreed with that also.)
Coke if that is the same as ['coretype']
allison I never said :multi(CoreType) should be :multi(['CoreType'])
Tene ... 20:47
pmichaud okay, let me rephrase then.
allison :multi is custom syntax and can do pretty much anything
pmichaud is :multi(CoreType) the same as :multi('CoreType')?
I think that currently it is.
allison at the moment, I don't think :mulit('CoreType') even works
pmichaud Yes, it does.
purl if you say so...
allison ok, then yes, they're currently the same 20:48
pmichaud Because when we were told to convert instances of
new Integer
to
new 'Integer'
allison (taking your word on it)
pmichaud I started doing that for :multi as well.
allison pmichaud: yes, in that context
pmichaud so, assuming that :multi(Integer) is really :multi('Integer')
allison :multi is a different story, it's sub modifier syntax, which has it's own parsing rules
pmichaud and what you said that 'Integer' is really ['Integer'] 20:49
it seems logical that :multi(Integer) is the same as :multi(['Integer'])
allison yes, but 'Foo' or ['Foo'] in a :modifier isn't actually a string or a key
PerlJam but it would seem really really odd to have two different syntaxes to talk about types. 20:50
20:50 Theory joined, donaldh joined
allison except that what we're defining here is how to select a dispatch type, which is completely different than instantiating an object 20:50
Coke I don't think :multi('Integer') works.
if I do a :multi(Integer), I can get dispatch to that .sub with foo(5), with :multi('Integer'), I cannot. 20:51
allison selection of dispatch type will likely have a much larger number of annotations than instantiation
it needs a syntax more similar to our PCC invocation than anything else
pmichaud well, it's arguable that get_class, subclass, and isa are also "selecting types" as opposed to "instantiating objects"
allison they're still just looking up a namespace 20:52
pmichaud actually, they're looking up a class.
allison MMD is dispatch
the names of classes and namespaces are isomorphic
pmichaud we're using a key to get to a namespace to get to the class, but really they're looking up a class.
allison (intentionally)
here's where the confusion is entering: MMD currently only selects by type name, so you're thinking of it as a namespace entry 20:53
but that's not how MMD works
it doesn't do hierarchical lookups
pmichaud it doesn't?
allison no
pmichaud if that's the case, then all of PGE and PCT are magically working somehow. 20:54
allison it stores and looks up by type number
pmichaud because they definitely think in terms of hierarchy.
for that matter, so is Perl 6.
I mean Rakudo.
allison yes, it works because it translates the bare string to a type number, and it does it within the current HLL
pmichaud but the type number is matched in a hierarchical and not exact sense, yes? 20:55
i.e., :multi('String') is actually including subclasses of 'String' 20:56
allison pmichaud: that has nothing to do with the syntax
that's the functionality behind the syntax
all the syntax does is look up a type number
donaldh What's the best way to submit a CLA?
pmichaud allison: that's all I need it to do.
donaldh I sent it to legal@parrot.org about 3 weeks ago but it bounced pending moderator approval. 20:57
allison donaldh: send it to the email address listed on the CLA form.
donaldh: oh, well we got it
donaldh: I approved the message, did you not get a notification that it had been approved?
donaldh allison: I don't think so. 20:58
allison pmichaud: yes, that's fundamentally what needs to do
pmichaud: though, really, it has to store the information as a string, and parse it at dispatch time, because many classes don't have a corresponding type at compile time 20:59
pmichaud it could store it as a key.
but yes, it's constant at compile type and looked up at some later point.
chromatic Sometimes it gets stored at compile time, when it's resolvable. 21:00
pmichaud that works too.
chromatic s/it/type number/
allison chromatic: yes 21:01
pmichaud I'm still very against this "store/lookup type by string" notion, because once we went to true namespace components strings became inadequate for identifying classes (short of designating a reserved separator token of some sort)
but that's probably not important at the moment.
szabgab has anyone built parrot on the mingw what comes with strawberry perl? 21:02
chromatic They don't get stored as STRINGs though. They get stored as Key constants.
pmichaud ah.
szabgab anything special I should know before I try to?
pmichaud allison just said they were stored as strings -- I was basing on that. 21:03
(unless we're just saying that a Key is a form of string, which technically it is.)
allison my basic point is that the :multi syntax isn't a Parrot string or a Parrot key, it's custom syntax for :modifiers, which means we're free to do absolutely anything 21:05
pmichaud I don't have a problem with that point.
I totally understand that.
chromatic a multi_sig stored on a Sub is a FixedIntegerArray, when it's resolved to type numbers, or a FixedPMCArray containing String PMCs (if they're single-word type names), Integer PMCs (if they're resolved at compile time), or Key constant PMCs (if they're compound type names not resolved at compile time).
allison like, say :multi( Foo;Bar :hll=python)
pmichaud I understand that we can adjust the :multi syntax however we might like. But introducing "yet another syntax to reference classes in foreign hll's" seems very wrong to me. 21:06
especially when we can use the (possibly slightly modified) key syntax and have it consistently work in other places too. 21:07
allison breaking key syntax to act like parameter passing is more wrong
pmichaud ...parameter pasing?
...parameter passing?
chromatic This is not a question of :multi only though!
allison :multi dispatch is parameter passing, you're defining a sub signatre
pmichaud I'm not breaking the key syntax to act like parameter passing, I'm extending the key syntax to be able to locate classes in other hlls
allison chromatic: it is, we already have a solution for all other cases
pmichaud allison: it's a *bad* solution. Did you see the examples in my post?
chromatic We have a solution for newclass? isa? does? 21:08
allison key syntax isn't about looking up classes, it's about a hash or array lookup on a PMC
pmichaud it's also about locating namespaces.
and it's also about identifying classes.
chromatic We need *some* syntax to identify classes.
allison only because we used it as a convenient shortcut
pmichaud it's a very convenient shortcut. 21:09
shortcuts can be good.
I'm just saying "let's improve the shortcut a bit"
chromatic A very convenient shortcut we freakin' use to *declare* namespaces.
allison the [...] syntax just creates a Key PMC
and a Key PMC is just a list of strings
pmichaud actually, it's a list of various things
not just strings.
allison strings or integers
pmichaud right
chromatic or other Key PMCs
allison the way it works internally is a linked list of Keys, yes, but keys are just strings and integers 21:10
chromatic Or other Key PMCs.
pmichaud so, since we don't use integer in Keys for anything related to namespaces/classes, and we have a need for this, why not use it here? 21:11
allison ooh, that's painful
pmichaud more painful than the 5-instruction sequence needed to do a simple "isa"?
chromatic more painful than a custom syntax to identify a type name independent of existing syntax used to declare a type name? 21:12
allison if keys aren't working, then we use something else
pmichaud the only place we need to do anything special with this is (likely) Parrot_oo_get_class
chromatic Note that HLLs have ID numbers too.
pmichaud yes, I did think that we could use the leading integer to indicate the HLL, with 0 as a special case meaning "global root" 21:13
allison what MMD will need to do, after the calling convention refactors is essentially create a constant CallSignature PMC
pmichaud this isn't just about MMD anymore.
it's about newclass, subclass, isa, does, and new.
allison so, a cheap way of creating a constant call-signature is desirable
pmichaud because those are expensive as well. 21:14
(if we stay with the "look up a namespace" approach)
allison pmichaud: but those are easy to solve, just add an opcode with an extra argument for a namespace object. Should have been done a while ago.
add opcode variants, that is
far more useful and powerful than namespace key hackery 21:15
pmichaud s/namespace//
it's not "namespace key" hackery.
allison true
pmichaud when I say newclass ['Foo']
allison key hackery in general
pmichaud there might not be a 'Foo' namespace yet. 21:16
anyway, I'm terribly disgusted with this conversation now. (more)
instead of a simple, elegant solution to the problem we're looking at specialized opcodes, :multi syntaxes, and opcode sequences simply to avoid treating keys as special (which they already are)
allison you should be able to say newclass $P0, ['Foo'] so it knows to create the new class and namespace in a specific location rather than in the hll root
I'm pretty frustrated with the conversation too 21:17
pmichaud before going down the specialized opcode path I'd much rather put the hll at the front of every key.
21:17 uniejo joined
allison if the "simple, elegant" solution seemed simple and elegant I'd go for it in a heart beat 21:17
but, I just can't see it
pmichaud what part seems not simple to you?
chromatic get_root_global
Let me make that more clear.
get_ *ROOT!!!* _global 21:18
allison we already have a solution for this
pmichaud it's an ugly solution.
chromatic We do NOT already have a solution for this.
PerlJam you guys just went in a circle
(you're on lap 3 I think)
allison it was never fully implemented, it's true
pmichaud I agree with chromatic: we do NOT already have a solution for this.
and the solution you're espousing is not truly a solution. 21:19
allison the standard pattern is, look up a namespace, do something with the namespace
that's standard throughout parrot
chromatic WINDMILLS DO NOT WORK THAT WAY! (for :multi)
allison if we have a couple of opcodes that can't handle that yet, they need to be fixed
pmichaud except it breaks if the namespace doesn't exist.
chromatic Namespace declarations do not work that way! (at compile time)
allison :mulit is a completely different case
: multi 21:20
chromatic :multi does not have to be a completely different case!
pmichaud we can't do "look up a namespace" for non-existing namespaces.
chromatic pmichaud, we could add proto-namespaces.
I know... I'll go sit in the corner.
allison trying to force compile-time :multi into the runtime syntax is never going to reach a sensible solution
chromatic THE SYNTAX ALMOST ALREADY COMPLETELY WORKS!
pmichaud introducing multiple opcodes makes things much more difficult for code generators, both automatic and human.
allison no, it really doesn't
pmichaud allison: you won't say what's broken about it.
you just keep saying "it's broken" 21:21
allison :multi needs a substantial rehaul anyway
chromatic All we need to make the syntax work is a simple, unambiguous way to anchor it!
The existing syntax is consistent throughout the system!
allison ok, how do you handle multi dispatch by value?
Infinoid PerlJam: I'm just glad I didn't start it this time.
chromatic Parrot dispatches by value?
allison how do you handle Perl 6's type modifiers on dispatch?
how do you handle multi dispatch on named parameters? 21:22
pmichaud allison: I'm not claiming that improving the key syntax will totally fix multis
Infinoid szabgab: it works fine for me. there's some details regarding how they built their libgmp (it uses instructions that don't run on my athlon), but it still runs.
pmichaud I'm not trying to totally fix multi here.
allison how do you handle named dispatch with optional parameters?
pmichaud I'm not trying to change the calling conventions.
allison (did you know that MMD can't currently deal with optional parameters?)
chromatic I thought I fixed that.
allison but I'm saying MMD has to handle all those things
:multi has to handle all those things
pmichaud that's fine. But when we need to identify a class, why is the Key syntax insufficient for doing that? 21:23
allison and simply modifying the key syntax, or using a number to indicate the root isn't going to help
szabgab Infinoid: thanks, parrot seemed to build fine but Parrot::Embed blows up for me
chromatic Because that's not what modifying the key syntax is for!
allison it's just going to add hackery that we have to remove later
pmichaud it's going to make :multi harder?
szabgab perl Build.PL says some syntax error
Infinoid szabgab: nopaste it and I'll have a look? (I haven't built on strawberry for a couple weeks.)
allison pmichaud: it'll end up getting wiped out 21:24
Infinoid hmm, there were some recent cygwin changes that may have affected mingw
pmichaud and replaced with what?
allison so, we'll add a hack, then remove the one case that actually depended on it
chromatic How does extending :multi to handle :named and :optional obviate the need to identify a class/type with an absolute name?
pmichaud what "one case"?
allison replaced with something a lot more like PCC syntax 21:25
pmichaud you keep thinking that :multi is the only broken case.
chromatic and I both disagree. Until we resolve that, I think this discussion is pointless.
allison no, I keep thinking :multi is a special case
chromatic What the frak does PCC have to care about class names?
allison the other cases are leftovers from an imcomplete conversion
chromatic Cf. what the frak does PCC have to care about struct padding?
pmichaud I disagree with that.
allison PCC is dispatch
pmichaud I disagree with "the other cases are leftovers".
szabgab upgrading Module::Build to see if that helps the problem go away 21:26
allison chromatic: where are you bringing struct padding into it?
chromatic Because that's C calling conventions.
The other thing you can't unify with PCC.
allison MMD isn't a C calling convention
it's PCC
chromatic PCC isn't an MMD calling convention.
Infinoid szabgab: I'll try it again here, but it's always worked for me out of the box, I don't think I've even installed anything from CPAN on this box.
allison PCC and MMD are one and the same
chromatic How? 21:27
allison they've been merged
chromatic If they are, then I can speed up PCC dramatically by removing mmd_distance from every invoke.
szabgab Infinoid: are you talking about parrot itself or Embed::Parrot ?
allison no, it only does MMD distance if the Sub discovered is a MultiSub
szabgab oh and actually I am using portbale strawberry which might be broken
chromatic I know.
Infinoid szabgab: parrot itself
chromatic That's why we have different names for them: because they're different things. 21:28
szabgab Infinoid: parrot built well for me
allison but the dispatch mechanism is the same
Infinoid did it pass tests?
chromatic The dispatch mechanism is not the same.
Infinoid I admit, I never actually went much further than that on mingw.
szabgab I have not tried testst yet
chromatic That's why MMD has mmd_distance.
Because the dispatch mechanism is not the same.
Because PCC does not care about best fit per expected and provided type.
allison chromatic: mmmm... yes it is, I wrote the code. both do a PCC dispatch
chromatic That's why we don't write: 21:29
allison MMD does a little more work, and tracks a little more information
chromatic .param [ 'Some'; 'Class' ] klass
allison any PCC dispatch is potentially an MMD dispatch
you don't need to, it extracts the types from the parameters for you
chromatic But you have to specify extra information when creating a multi sub because the dispatch system is different! 21:30
allison no, it's the same, the only difference is whether the sub was declared as :multi
chromatic PCC dispatch: look up a sub by name, if a name is provided. Invoke it. Pass parameters.
allison chromatic: mmmm... you have an interesting idea there, though
what if :multi was bare, no modifiers? 21:31
chromatic MMD dispatch: look up a sub by name, if a name is provided. Find the best candidate per provided parameters. Invoke it. Pass parameters.
allison and the types were declared as modifiers on the .param declarations?
pmichaud (note that you still need a way to specify the types)
allison we're trying to pack so much into that tiny :multi modifier, we're tying ourselves in knots
chromatic What pmichaud just said is what he and I have been arguing!
pmichaud allison: you're the one bringing :multi complications into this 21:32
chromatic We need a way to specify types, relative to other HLLs, and those types may not be available at the point of compilation.
pmichaud whether it's multi, newclass, subclass, new, isa, get_class, or does, we need a way to specify the types.
allison chromatic: hmm? I thought you were arguing for something like :multi([0;'foo';'bar']
chromatic Yes.
That's a way to specify a type.
allison yeah, that's what bugs me 21:33
chromatic If that goes on the .param line, that's fine.
I don't particularly care.
pmichaud you haven't said why it bugs you.
chromatic I kind of like putting it in .param.
allison but what if we said...
chromatic But we need a way to specify a HLL-based type without forcing a lookup, because that lookup might fail.
21:33 uniejo joined
chromatic forcing a lookup at the time of compilation, that is 21:33
allison .sub 'mysub' :multi 21:34
.param pmc foo :class['foo';'bar'] :hll('python')
...
or something like that
chromatic No, that's not okay.
pmichaud how would we solve the subclass case?
or 'isa'?
purl somebody said 'isa' was a great candidate for caching, do the lookup once, and save it
allison pmichaud: what subclass case?
all it's doing there is looking up the primary class
chromatic myclass = subclass [ 'Some'; 'HLLs'; 'Parent'; 'Class' ]
pmichaud chromatic: it's worse than that 21:35
subclass needs *two* classes.
chromatic That's right....
allison for subclass you should be passing it a class object, rather than a string or key
pmichaud allison: subclass is creating a class.
21:36 pdcawley joined
allison right, so you should be able to pass it a namespace as well as a class name 21:36
pmichaud and a key (can) uniquely identify a class object, so why not use that?
chromatic So to create a subclass in another HLL, you have to create the subclass in the other HLL, and pass that to the subclass opcode, to ....
allison that gives you the freedom to create your class relative to absolutely any point in the hierarchy
Infinoid szabgab: I'm still waiting for "svn update" and then I'll build... it will take a while on this poor old box. in the meantime, got an error message I can look at?
allison if keys are relative to anything other than the current HLL, it's going to make the code really horrible 21:37
pmichaud as long as we use keys for namespaces, we should also be able to use them for classes. (more)
why does it make it horrible?
that's the part I don't understand.
what's horrible about it?
allison personally, I'd love to get rid of keys for everything but looking up a namespace object
but, it's a handy shortcut
pmichaud if a key is sufficient to look up a namespace object, it should be sufficient to look up a class (since classes and namespaces are isomorphic)
allison 99% of code just works within one hll 21:38
pmichaud but you still haven't answered: "what's horrible about it?"
allison the exceptions to that rule can spend more effort
pmichaud: yes, I should probably sit down and spend half an hour writing out all the fundamental design principles involved 21:39
that's why I preferred having this conversation on the mailing list
pmichaud I posted my summary to the mailing list.
both chromatic and I seem to agree that having a special key to mean "from root" is less horrible than the alternatives. 21:40
chromatic I agree with that completely.
allison ok, I'll reply to that
pmichaud in particular, we don't see anything horribly wrong with it.
allison if looking up a namespace object is horrible, then our hll implementation is fundamentally broken
dalek r35080 | jonathan++ | branches/rvar/languages/perl6/src/parser: 21:41
: [rakudo] Restore check to make sure we can only multi/only/proto a named routine, as per S06.
review: www.parrotvm.org/svn/parrot/revision?rev=35080
chromatic No, our system is *dynamic*.
purl okay, chromatic.
allison because that's the core of all hll interaction
szabgab Infinoid: rafb.net/p/Wd7w6D81.html
pmichaud allison: but you're still avoiding the question.
allison pmichaud: I'm not sure what the question is
pmichaud you need to write down the fundamental design principles that are being violated, so that chromatic and I have a chance to answer them.
because thus far you're not enumerating them for us. And I think that chromatic and I are good enough designers that we probably know many of them already.
chromatic The question is: What's wrong with using the Key syntax to refer to classes and namespaces as we already do in every other part of the system?
szabgab chromatic: I was trying to build Parrot::Embed on Win32 Strawberry Perl and got an error on the file rafb.net/p/Wd7w6D81.html
allison do you want me to do it on the fly on IRC, or spend time thinking about it? 21:42
pmichaud allison: it's up to you.
szabgab somewhere at line 21
$ENV{} = join(
pmichaud you can spend time thinking about it if you prefer. I don't need an immediate answer.
allison because at the moment I'm in the "Blink" precongnition phase
I can tell you what's wrong
PerlJam allison: speaking as mostly a spectator here, I'd prefer you spend time thinking about it :)
chromatic szabgab, that should probably be $ENV{PATH}
szabgab this is a generated file, where is its source/ 21:43
?
chromatic Although in the source, it's $dl_env_var.
allison but, since you're coming from a different perspective, I probably can't explain why it's wrong in a way that will make sense without spending more time on it
pmichaud if you can't quickly explain why it's wrong, that probably also indicates something is horribly broken with Parrot.
chromatic szabgab, see Build.PL.
In particular, that comes from Config.pm's dl_env_var. 21:44
pmichaud but go ahead and take the time to do it.
chromatic szabgab, maybe change line 10 of Build.PL to add || '' at the end of the function call.
pmichaud in my experience, our negative reservations often evaporate when we have to explain them to someone else.
chromatic Or || "''" 21:45
allison pmichaud: well, something is broken with HLL namespaces, but we already knew that
they've been a major pain point for years now
pmichaud I'm not saying yours will, but at least give chromatic and I the benefit of understanding why what we're proposing is a bad idea.
allison the short answer
purl the short answer is "writing SQL by hand get's boring, repetitive, and is prone to errors", so the benefits of abstraction are large
allison it's a quick fix that doesn't actually solve the core problem 21:46
pmichaud that core problem being...?
allison we have too many quick fixes piled on top of each other in Parrot, and are trying to remove them, not add new ones
chromatic Apparently not "How do you refer to a type in another HLL if you don't know if that type has been declared yet?"
pmichaud you didn't answer my question of "that core problem being...?" 21:47
chromatic 'cuz that's MY core problem here.
allison chromatic: no, your solution won't solve that either
pmichaud sometimes "quick fixes" are in fact the right solution.
allison the core problem being how we work with HLL namespaces
the fact that they should be invisible
pmichaud do you envision that we will eventually radically change the way we work with HLL namespaces?
szabgab chromatic: firs of all I've forgotten to change PATH to point to c:\\gabor\\parrot 21:48
chromatic Making language interoperability completely invisible is too much magical girl show for me.
szabgab but even after setting it I got the same problem
i'll try your suggestings
allison and, accessing other languages is spec'd to go through an interface, so that language can choose to behave differently while still giving you the "standard" response
that's why you access a namespace object and then call methods or vtable functions on the namespace object 21:49
Infinoid chromatic: too easy? or too unlikely?
pmichaud allison: so, you envision that we will substantially change the way we work with HLL namespaces, by going through an interface object.
chromatic How do you refer to a type in another HLL if you don't know if that type has been declared yet?
allison pmichaud: yes
chromatic Infinoid, invisible? Impossible.
pmichaud allison: I have two answers, then.
chromatic: the way we would refer to a type in another HLL would be by asking the HLL's representative (e.g., it's compiler) to do it for us. 21:50
allison pmichaud: though, it's not a change to the current interface
pmichaud allison: oh. it's not a chance to the current "use a key to identify a class" interface?
s/chance/change/
allison pmichaud: but it is about not adding additional features that would actively work against substantially changing the way we work with HLL namespaces
chromatic pmichaud, that's going to make :multi a real pain to write.
pmichaud chromatic: I agree, I'm just trying to get at whatever is blocking allison. 21:51
chromatic szabgab, change line 70 of Build.PL to:
return $Config{ldlibpthname} if $Config{ldlibpthname};
allison pmichaud: no, that's just syntactic sugar, a shortcut for looking up the namespace in the current HLL
pmichaud why can that not be extended to be "a shortcut for looking up a namespace in another HLL"?
allison but since you're within the current HLL, pretty much anything is fair game
because that crosses the HLL boundary 21:52
pmichaud that shortcut could still go through the namespace objects to do it.
allison all bets are off
pmichaud it doesn't have to cross the HLL boundary directly.
dalek r35081 | jonathan++ | branches/rvar/languages/perl6/src/classes:
: [rakudo] Need to handle non-existent types too. This gets us mostly running S06-multi/type-based.t
review: www.parrotvm.org/svn/parrot/revision?rev=35081
21:52 slavorg joined
pmichaud i.e., you can still preserve your interface. 21:52
chromatic Yeah, it's just "Look up in this HLL, according to whatever semantics it likes." 21:53
allison but we already have that
chromatic Not for :multi, newclass, subclass, does, and isa.
pmichaud because we already have it, the shortcut can't do it as well?
szabgab chromatic: that change on line 70 helped a bit
now trying to paste the new error
pmichaud what's the problem with having a smarter shortcut? 21:54
in fact, the shortcut is *easier* in the long run, because the semantics are in one place
dalek r35082 | chromatic++ | trunk/ext/Parrot-Embed:
: [Parrot::Embed] Improved dynamic library path detection (reported by Gabor
: Szabo).
allison what's right about it?
dalek review: www.parrotvm.org/svn/parrot/revision?rev=35082
chromatic ... and they don't require multiplying other entities.
pmichaud if we require everyone to do get_namespace and then handle all of the exception cases differently (and muck around in other hll's namespaces to do it), then we make the long-term problem harder, not easier. 21:55
it's much easier to hide it behind a [0;'parrot';...] abstraction (or whatever syntax we choose)
allison that doesn't hide anything
pmichaud and then that abstraction honors the appropriate interfaces as they evolve.
chromatic Yep, one syntax for rooted lookups. 21:56
allison that's what get_namespace does
chromatic Not for :multi, newclass, subclass, does, and isa.
pmichaud allison, get_namespace doesn't work if I'm creating a new class.
allison I'm going to take a break
pmichaud: I'll read your message, and I'll think about it 21:57
at the moment, I'm not at all inclined to agree, but I'll think about it
chromatic szabgab, see tools/dev/nopaste.pl.
PerlJam I'm glad you guys are having this discussion in the early part of January rather than the later part of February :-)
pmichaud PerlJam: I don't think it impacts 1.0 21:58
chromatic Just think, without Pie-thon, we could have had this discussion in 2005 or 2006.
dalek r35083 | jonathan++ | branches/rvar/languages/perl6/src/parser:
: [rakudo] Restore marking of protos, which fixes S06-multi/proto.t.
review: www.parrotvm.org/svn/parrot/revision?rev=35083
allison PerlJam: well, in the later part of February it wouldn't even be a question
chromatic More like a 1.5 or 2.0 feature.
pmichaud it's really not a 1.0 critical feature.
yes, more like 1.5 or 2.0.
PerlJam If you say so. 21:59
purl damn straight
pmichaud it's only coming up now because people are starting to move their pct-based languages out of the 'parrot' hll.
but being unable to do that doesn't block progress or development on those languages.
PerlJam It seems to me that it will affect parrot's ability to be a "stable platform for language developers" if such things are in flux.
pmichaud PerlJam: no, it doesn't actually affect that either. 22:00
szabgab chromatic: oh, that's very much like the one I wrote for Pugs :-)
particle it's not a stable platform for hll interop
allison particle: which is a 1.5 feature
chromatic szabgab, yeah, it's the same problem.
pmichaud PerlJam: allison is completely correct that we're only talking about 1% of the cases where this happens at the moment.
particle allison: right.
chromatic Those cases affect libraries such as Test::More though.
particle szabgab: i wonder who has the prior art, you or me
szabgab my problem is that my IRC is open on my linux while I run Windows in a VirtualBox and I cannot copy-paste between the two 22:01
Tene pmichaud: this isn't a 1.0 issue? If this changes, won't it cause issues for HLL developers to update to match?
PerlJam is still glad you guys are having this discussion sooner rather than later! :)
particle szabgab: i can copy/paste with vmware
pmichaud Tene: it's only signficant if we deprecate the existing key syntax.
which nobody seems inclined to do at the moment.
szabgab yeah, it seems VirtualBox cannot do that
or I don't know how
PerlJam pm: or, as allison seemed to imply, if you introduce a new syntax that has to be subsequently changed. 22:02
particle szabgab: you can use a gmail draft
i do that sometimes, or g.ho.st/
PerlJam er, new variant of an existing syntax I guess
GeJ Good morning everyone
Infinoid hi GeJ
pmichaud however, I'll remain on record that if I have a choice between adding new opcodes or making all class keys root relative, I'm strongly in favor of the altter.
*latter
szabgab particle: yeah, that's and idea too
pmichaud PerlJam: I can't see how we would have to change the syntax.
it just means the syntax would have to adapt into whatever new mechanism we use.
it's only a problem if the syntax has to suddenly mean something different. 22:03
kj syntax changes aren't all that bad, anyway, especially if we expect people to write libraries in HLLs as well 22:04
PerlJam I was thinking if you adopted [0;'Foo';'Bar'] and then ended up deprecating it later.
pmichaud (1) we'd have to know what we're moving to at that point
Tene pmichaud: [;...;...] might be okay for "current HLL relative"
i nthe case we're changing it
pmichaud (2) it'd only be a problem if the [0;'Foo';'Bar'] syntax couldn't automatically map to whatever we're moving to
kj ponders whether we can't use a yada-yada-yada operator for hll-relative types 22:05
chromatic And that's only a problem if the functions to which we pass such keys don't know how to interpret them.
pmichaud correct.
PerlJam That's why you guys are paid the big bucks. ;-)
chromatic 'cuz we don't even have to touch IMCC's parsing to make [ 0; 'Foo'; 'Bar' ] work today. 22:06
pmichaud I don't mind if someday it's deprecated in favor of something else.
22:06 slavorg joined
pmichaud I just can't imagine that it would be so difficult to map it into whatever we end up using. 22:06
particle kj: about your need to load pirc instead of imcc...
GeJ Infinoid: I got caught by your freeze_25.pir ticket yesterday. While printing the thawed PMC string, it looks like all the 'good' ones end the same way.
particle kj: if imcc were first abstracted out of that op, then you could easily specify pirc instead 22:07
Tene kj: I'd prefer [; to [...;
particle in other words, make it so that imcc isn't *the* compiler, it's *a* compiler
pmichaud does imcc currently handle the case of null initial keys? 22:08
kj particle: you want to be able to keep it?
Tene: the bare ';' is easier to overlook. The '...' indicate you're assuming there's something there. Just a random idea :-)
chromatic I don't think IMCC handles null initial keys, but an initial key of 0 I don't think it minds.
pmichaud either way, the [;'Foo'] and [...;'Foo'] proposals are semantically identical to the [0;'Foo'] one that allison is so against.
22:09 particle joined
kj pmichaud: correct. 22:09
GeJ Infinoid: I'll try to make a dump of what I have and see if you can make sense out of it.
particle pidgin-- for going pear-shaped
Tene pmichaud: I was reading [0; as [hll_id;
particle kj: i want to make every parrot subsystem pluggable, including pir/pasm compilers
pmichaud Tene: in either case we're using the first key element as a way of saying "look up relative to root/hll"
particle with config- and run-time selection
kj particle: agreed, I'll start looking into it. At some point, anyway 22:10
pmichaud and allison seems against that.
particle what is allison for? i missed the conversation
PerlJam heh
Tene pmichaud: is your [0; proposal equivalent to get_root_namespace or get_root_namespace ['parrot'] ?
pmichaud note that she's not against the idea of what that first element should be, but rather against the idea of using keys at all to locate things in other hlls
Tene: it can be, with the proviso that it can be smarter about what happens if the requested namespace doesn't exist. 22:11
kj Gotta go. Goodnight all.
Infinoid GeJ: great. been tracking that on and off for a while, but I haven't worked myself up to reviewing the string hash code yet (which is where all the signs are pointing)
particle tene: it's get_root_namespace
pmichaud particle: it's also get_root_namespace ['parrot']
particle they're mostly the same 22:12
pmichaud assuming that we treat [0; 'parrot' as a unit.
yes, mostly the same.
Tene pmichaud: Ah. I was proposing that we paint the bikeshed "All keys are root-relative. [; or [...; or whatever is relative to the current HLL"
PerlJam Tene: that's backwards
particle i don't like it if [0;'Integer'] works
i want to see [0;'parrot';'Integer'] 22:13
pmichaud particle: Tene is proposing ['parrot';'Integer']
Tene Yes.
pmichaud where [;'Integer'] is a shortcut for "Integer in the current hll"
particle so the shortcut is longer.
(than current) 22:14
pmichaud and incompatible with existing usage, yes.
particle yep.
pmichaud anyway, it's moot given allison's currently stated position.
particle which is... yuck?
pmichaud modify the :multi syntax so that there's a way to refer to classes in other hlls
the new, newclass, get_class, subclass, isa, and does opcodes would continue to have to go through namespace ops to do things. 22:15
particle ah, just :multi
Tene although, come to think of it, [..; makes sense for pmichaud's proposed semantics, as an analogy to '..' in filesystems meaning 'the directory containing this directory'
particle we could make :multi four opcodes long :)
PerlJam random thought ... given some form of [0;'Foo'], would ['Foo';0;'Bar'] mean anything or would it be guaranteed to error? 22:17
particle .sub 'bar' :multi(:hll('Irish') ['Priest'], :hll('Brittish') ['Bishop'], :hll('Israeli') ['Rabbi']) 22:19
pmichaud PerlJam: I suspect it would error (or whatever it does now). 22:22
Infinoid perl6: eval(q<puts "hi">, :lang<tcl>) 22:30
polyglotbot RESULT[undef]
Infinoid tcl: puts "hi"
polyglotbot OUTPUT[hiā¤]
Infinoid wonder what I did wrong.
dalek r35084 | jhorwitz++ | trunk/src:
: [core] add NULLOK to args where appropriate so loadlib can dlopen the running
: process image when passed a NULL path.
review: www.parrotvm.org/svn/parrot/revision?rev=35084
Tene Infinoid: if tcl uses custom pmcs or dynops, it won't load correctly 22:31
GeJ PASM question: when adding attributes to a class, is there a link between the attribute's name and its type? Case in point : `addatribute cl, '%!key'` does that mean that the attribute MUST contain a hash? Or is this just a visual hint?
Tene Infinoid: pipp has the same problem, looks like
Infinoid: that's what my latest mail to parrot-devl is about
Infinoid ohnoes.
cotto GeJ, that's just a hint
Infinoid doesn't rakudo use custom pmcs too? 22:32
cotto Are you working on TT#116?
jonathan pmichaud: ping
Infinoid Tene: is it a search path thing?
GeJ cotto: I don't have a browser open yet... but if that's the freeze_25.pir one, then yes. 22:33
Tene Infinoid: no. look at the examples in my mail to the list.
Infinoid reading now
cotto GeJ, it is. any headway?
I've found some oddities, but no fix so far,
s/,/./
Infinoid cotto: I've posted a patch to make it crash reliably. the farthest I've been able to track it so far is to the string hash function 22:34
GeJ As I say to Infinoid earlier. When dumping the thawed PMC string on the screen, I can see that all the good ones end in a similar way. I have no idea if that's relevant or not. I'll just try to make a dump to document my findings. 22:35
Infinoid GeJ: it is. how are you dumping the PMC?
pmichaud pong
jonathan: pong
jonathan pmichaud: Ah, I think I may have answered my own question. :-)
pmichaud jonathan: hmm. That makes me question my answer, then. 22:36
jonathan Was trying to find where we set $?METACLASS and what it was.
pmichaud $?METACLASS is just a PAST::Var(:scope('register')) that gets shared lots of places.
jonathan Now I see it's...yes, that. :-)
Is this going to work out for nested classes?
pmichaud I got tired of creating that node over and over.
yes.
cotto ok. I'm looking at the attrib_metadata is goofy. With a bad hash seed, _class->attrib_metadata looks fine but clones of it have elements in the wrong order (according to get_repr)
pmichaud because each class will have its own :load :init block, and thus its own register.
jonathan Aha. 22:37
cotto s/ is goofy//
jonathan OK, thanks.
Infinoid yeah. I spent a lot of time looking at default.pmc and the handling of that metadata hash
it is obviously corrupt, but I don't think it's hash freeze/thaw's fault (directly)
jonathan I've got various of the multi tests passing again.
cotto with a good hash seed, the clone and the original attrib_metadata look the same (apart from addresses)
pmichaud jonathan++
jonathan Just looking at roles a bit now.
nopaste "jonathan" at 85.216.157.73 pasted "This look OK for fixing up "does"?" (48 lines) at nopaste.snit.ch/15225 22:38
pmichaud looking. 22:40
yes.
exactly what I was planning.
jonathan OK, will commit that bit. 22:41
Doesn't get roles working completely yet, but we faill a bit less spectaculorly. :-)
Infinoid cotto: yeah. I've been meaning to spend some time staring at numbers to figure out exactly what makes a "good hash seed" good, with an eye to fixing up the hash function to be more consistent, but haven't gotten around to it yet
jonathan pmichaud: Does STD.pm combine package_def and role_def now? 22:42
jonathan goes to check.
dalek r35085 | jonathan++ | branches/rvar/languages/perl6/src (2 files):
: [rakudo] Restore handling of trait_auxiliary:does.
review: www.parrotvm.org/svn/parrot/revision?rev=35085
pmichaud jonathan: yes.
jonathan Ah, so they do.
Hmm
pmichaud I was pleasantly surprised that it did.
jonathan It's fine, I just want to know how it parses parametric roles now... :-) 22:43
pmichaud I think it's in package_declarator:role
nope. 22:44
jonathan name doesn't seem to do it either
hmmm
pmichaud module_name?
yes, module_name does it.
jonathan token category:module_name { <sym> } 22:45
proto token module_name { <...> }
chromatic jhorwitz, with regard to r35084, not all of our platforms support that unfortunately. I don't believe either Windows or Mac OS X allow it.
jonathan That's all I can find - what am I missing?
oh, found it, duh :-)
cotto Infinoid, this may be of interest:
jonathan [ :dba('generic role') <?{ ($+PKGDECL//'') eq 'role' }> '[' ~ ']' <signature> ]? 22:46
nopaste "cotto" at 96.26.202.243 pasted "PIR to exercise strange hash seed-dependent attribute behavior" (25 lines) at nopaste.snit.ch/15226
jonathan Awesome. It's a <signature>, as I suggested a while back. :-)
OK, I'm happy
PerlJam :dba('generic role') ? that looks odd.
pmichaud and $?PKGDECL is set for you.
jhorwitz chromatic: the underlying code checks for it
cotto If you play with it long enough, you can get 4 different broken permutations.
pmichaud PerlJam: it's for the goal-matching sequence later.
jonathan PerlJam: I ain't figured out the dba is yet 22:47
jhorwitz chromatic: but the args didn't allow it at all
pmichaud so that when '[' ~ ']' <signature> fails, it says "can't find closing ] in generic role"
jonathan pmichaud: Can you elaborate a little on that? That's not quite enough for me to ge the idea...
PerlJam pm: what is dba mnemonic for?
pmichaud "doing business as"
jonathan pmichaud: Ah, so it's about giving a good error message?
Rather than affecting the parse?
pmichaud jonathan: yes, exactly.
jonathan and :foo(...) is a sub call?
pmichaud it sets the error message for the subsequent '[' ~ ']' ... expression. 22:48
22:48 Limbic_Region joined
pmichaud no, :dba('...') is just an adverb. 22:48
PerlJam only on those, or in general?
pmichaud PerlJam: only on those ... what?
PerlJam the bracketing construct
or is it for the group
?
pmichaud it's set for any bracketing construct that lexically follows. 22:49
jonathan As in, what are we setting the adverb on?
pmichaud oh.
the adverb is set on the current rule.
same as :i :sigspace etc.
chromatic jhorwitz, but platform-specific dlopens can't handle it.
jonathan Do you have to pre-declare adverbs that are allowable somewhere?
pmichaud I think they're silently ignored if not recognized. Like most adverbs.
jonathan OK. 22:50
cotto Infinoid, the order is only broken in cloned attr hashes. If you use _class->attrib_metadata, it looks fine.
pmichaud or maybe I should say "like most adverbs sent to methods"
Infinoid cotto: hmm, I wonder if normal cloned hashes are affected
pmichaud I think Rakudo's grammar is already using :dba in a couple of places. 22:51
jhorwitz chromatic: solaris requires us to use it that way. linux doesn't, but supports it. add windows, etc. and we have an interesting situation.
pmichaud (in the rvar branch, at least) 22:52
jonathan Oh?
I can't find any use of dba in grammar.pg
pmichaud guess not.
:dba defaults to the name of the rule if not set.
so it still works out.
e.g.: 22:53
token block { '{' ~ '}' <statement_block>
comes back with "cannot find closing } in block"
anyway, iirc I do have :dba implemented in PGE now.
jonathan Nice 22:54
pmichaud (along with the goal-matching syntax, of course :-) 22:55
jonathan goal-matching syntax being the '(' ~ ')' stuff?
jhorwitz chromatic: just brainstorming, but maybe the platform-specific Parrot_dlopen functions should check for nulls and either do the right thing or bow out gracefully.
chromatic I say we disallow null at the opcode level.
pmichaud jonathan: yes. There's not an official name for that syntax in S05, so I've dubbed it "goal-matching" 22:56
chromatic Or at least the function called from the opcode.
pmichaud it's got a tilde in it, though, so maybe we just call it "TimToady's hand wavy syntax"
similar to infix:<~~>
or maybe since it only has one tilde, it's the half-smart match 22:57
jonathan :-)
It confused the heck out of me when I first saw it. ;_) 22:58
jhorwitz chromatic: for now, should i throw in some asserts in the platform-specific functions?
pmichaud it didn't confuse me too much, but I didn't realize how much I wanted it until I started to update Rakudo's grammar for rvar :-)
particle pmichaud: do you want :dba everywhere it belongs?
pmichaud (i.e., I wanted it enough to go ahead and implement) 22:59
particle: so far there's only four places where we use the syntax. If there are :dba's in STD.pm that correspond to the places we use it, then yes, we can add it. 23:00
particle i can add :dba to all the rules in the grammar that STD has it in
chromatic jhorwitz, I'm not sure how valuable that is. Non-portable code will break in mysterious ways when run on platforms on which it can't run.
pmichaud particle: there's no point if the rule doesn't then use the ~ syntax, though.
chromatic I'd rather disallow platform-specific code where we can't ignore it, especially when we have a good workaround already.
particle will it not be useful later?
pmichaud I'd rather add the :dba when/if we convert to the ~ syntax.
than do it in advance.
particle like token ws
pmichaud anytime someone is modifying a regex in rakudo's grammar they should probably review STD.pm first anyway. 23:01
particle ok, so :dba only works for rules containing ~ syntax, so far 23:02
pmichaud right.
I'm not sure what it means in some of the places that STD.pm is currently using it.
(or what it's intended to mean.)
PerlJam oh, :dba is in S05. 23:03
I didn't realize that
pmichaud right.
PerlJam probably added about the same time as infx ~ 23:04
pmichaud you thought I made it up, didn't you? ;-)
PerlJam I had no idea. This was the first I saw it.
mj41 Hi, seems like my new Core 2 Quad can be useful for testing ... tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk ... 10 minutes to one full cycle (copy to temp, make, make test, send results). Good night. 23:05
PerlJam I mean, you and TimToady could have discussed it via cabalcall and you subsequently implemented it without it ever going in the spec (or with me missing that it went in the spec) for all I know
pmichaud nope. This has been in the spec for some time :-)
anyway, I need to do some family stuff. 23:06
jonathan: keep going on rvar as you see fit -- you've got the hang of it. I'll review your commits when I get back to the desktop.
I'll continue working on rvar tonight.
jonathan pmichaud: OK, sounds great.
pmichaud (I expect a good hacking night tonight, if I haven't just 'jinxed' it)
bbiaw
jhorwitz chromatic: my immediate problem is that mod_parrot will not work on solaris without this. it seems to me we need some portable (at the opcode or API level) way of loading the running process image, and can throw an exception if it's not supported.
jonathan I'm probably going to call it a night soon. Got a couple of other bits on roles done, but not got 'em working just yet. 23:07
jhorwitz will think about this some more. for now, dinner & 23:11
chromatic jhorwitz, you should be able to use loadlib 'libraryname' with a library in the current process. 23:12
In theory, the dynamic loader should give you a handle to the appropriate shared library even if it's already mapped into your process
jhorwitz right, but for apache, i want the functions from the httpd binary, not its shared libraries.
Limbic_Region chromatic - did you see whiteknight's recent use.perl post about MMD? 23:13
chromatic I did.
Limbic_Region oh, nevermind - supper is ready - was going to ask if you had an explanation as to why we sorted a list just to find the shortest distance (vs low watermark algorithm)
Limbic_Region AFK &
chromatic We don't anymore! 23:14
Whiteknight we dont?
chromatic We don't sort the list anymore.
Whiteknight well then
GeJ Infinoid, cotto: new file added to TT#116 23:15
dalek r35086 | jonathan++ | branches/rvar/languages/perl6/src/builtins:
: [rakudo] Get roles sort of working again.
review: www.parrotvm.org/svn/parrot/revision?rev=35086
GeJ Although it may require the use of a large screen... (sorry) 23:17
nopaste "cotto" at 96.26.202.243 pasted "more minimal PIR to demonstrate hash mishbehavior" (26 lines) at nopaste.snit.ch/15227 23:18
cotto trac isn't very smart about dealing with long lones 23:19
GeJ yes, I just figured this out. My apologies. 23:20
cotto no worries
davidfetter waves to cotto 23:21
cotto waves back
davidfetter are you back at msft? 23:24
cotto not until Sept, if ever
davidfetter k
cotto employment would definitely be nice about now
davidfetter yeah, i hear you
Limbic_Region ok - so I am back now 23:35
so even if Whiteknight's other ideas don't pan out, there is a small improvement in that we are not sorting the list? 23:36
Whiteknight I responded to your comment
chromatic Yes.
Whiteknight you cant take anything I write too seriously 23:37
chromatic It's the Internet. No one should take anything here too seriously.
Whiteknight BLASPHEMY! Writings on the internet are sacrosanct
Limbic_Region I see 23:38
Infinoid Whiteknight: [citation needed] 23:39
Limbic_Region so are you talking about vtable mmd or user method mmd or both?
chromatic They're mostly the same now. 23:40
Limbic_Region ok, just thinking about the example in Whiteknight's reply 23:43
regarding autoboxing
it seems to me that it might just make sense to generate all possible autobox aliases 23:44
rather than trying to calculate an edit distance 23:45
chromatic I think that runs into a problem where you might think an autoboxed version fits better than a non-autoboxed version.
You want to penalize autoboxing very slightly.
Limbic_Region well, that's Whiteknight's idea not mine 23:46
I am just looking at implementation
chromatic At least, when I enabled autoboxing, I ran into that problem. It could have been a flaw in my approach.
Whiteknight whoa whoa whoa, that's not my idea!
an autobox operation adds one to the distance
no autoboxing = 0 distance, which is always better
Limbic_Region doesn't want to put words into anyone's mouth 23:47
chromatic Right. That's what the autoboxing distance calculation does now.
Limbic_Region just still trying to think through how using string edit distance can be beneficial (as I stated previously, while I understand manhattan distance, I have never implemented an MMD)
chromatic I think it only works as a potential first order sieve. 23:48
TimToady re :dba, it is also used in error messages that emit "expecting..." 23:49
pmichaud, particle: ^^
chromatic ^_^ 23:50
TimToady and, in fact, that was its original purpose; the goal-directed syntax just happens to also expect something :)
Limbic_Region does Parrot use C3 for determining which method to use in multiple inheritence? 23:52
Whiteknight Limbic_Region: A Manhattan distance is very closely related to a Hammin distance
Basically counting the number of differences between the argument array you have, and the various candidates
davidfetter
.oO(taxicab metric)
TimToady p6 doesn't use distance at all, only exact/inexact 23:53
well, better/worse, if you squint
Limbic_Region Whiteknight - I never really thought of hamming distance in enough dimensions to see the correlation - but yes, I can see that now
jonathan Limbic_Region: C3 is used by Parrot in MI, yes.
TimToady: Rakudo subclasses MultiSub and implements the Perl 6 algorithm as per S12. :-) 23:54
TimToady whew :)
jonathan So what Parrot chooses as it's default MMD algorithm is pretty irrelevant to Rakudo. :-)
TimToady and does it allow you to ask "what is the new smaller list of candidates given these arguments?" that is, candidate search without actual dispatch? 23:55
so you can do &newmulti := &oldmulti.assuming(1,2,3) 23:56
jonathan TimToady: I didn't do that bit yet.
But it won't be hard to add either.
TimToady cool, just something to bear in mind 23:57
jonathan While I have your attention though... ;-)
&multi.signature # what does this return
Or, given a multi, how do we get all of the variants? 23:58
TimToady mm, maybe the sig of the proto that would be autogenerated?
I presume there'd be some way of introspecting the candidate list, but it's not specced
jonathan Where exactly is the auto-generation of protos spec'd? And if you write your own proto foo(...) { ... }
Then does it suppress auto-generation?

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!