Camelia, the Perl 6 bug

IRC log for #parrot, 2009-01-06

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced