Parrot 0.6.3 "Beautiful Parrot" Released | parrotcode.org/ | 5/649/88 new/open/stalled tix | logged in irclog.perlgeek.de/parrot/today
Set by moderator on 26 June 2008.
00:02 bacek_ joined
bacek_ morning everyone 00:02
davidfetter oi 00:07
rurban hi
purl hi, rurban.
Whiteknight finally got his copy of "Perl 6 and Parrot Essentials"
rurban Something worth to read?
davidfetter wonders whether the Whiteknight's talking backwards 00:08
rurban Aren't the docs and srcs better?
pmichaud P6PE is fairly out of date :-)
rurban rakudo?
purl rakudo is probably The Way of The Camel or in languages/perl6 (svn.perl.org/parrot/trunk/languages/perl6) or use.perl.org/~pmichaud/journal/35400 or rakudo.org or Part of this balanced breakfast!
00:09 AndyA joined 00:12 kid51 joined 00:24 rurban left 00:25 Ademan joined
Whiteknight yes, the book is fairly out of date, but I got it for 1.90$ on amazon 00:31
so i figured, what the hell
00:35 ruoso joined
kid51 Do you know how someone registers at smolder? smolder.plusthree.com/app/public_pr..._reports/8 00:36
00:42 AndyA joined
DietCoke I'm tempted to get a copy and make allison sign it. 00:59
dalek r28974 | jkeenan++ | trunk:
: [configure] Merge autoicu branch into trunk.
: (rt.perl.org/rt3/Ticket/Display.html?id=43334). Extensive refactoring
DietCoke and then sell it on ebay or something.
dalek : of auto::icu, but no reduction in functionality. Add 5 test files. Drop
: references to nonexistent '--icudatadir' option in documentation in two
: locations.
diff: www.parrotvm.org/svn/parrot/revision?rev=28974
cotto_work particle, ping
dalek r28975 | jkeenan++ | autoicu:
: Branch has been merged into trunk and is no longer needed at HEAD.
diff: www.parrotvm.org/svn/parrot/revision?rev=28975
tetragon Hrm, how would one sell the autoicu branch on ebay, anyway... 01:00
dalek r28976 | jkeenan++ | autoicu-28734: 01:01
: Branch to which tag corresponded has been deleted; tag no longer needed.
diff: www.parrotvm.org/svn/parrot/revision?rev=28976
davidfetter cotto_work, i'm looking for ways to make postgres more welcoming to windows developers. anybody i can ask about this in detail where you work?
cotto_work let me look into that 01:02
I'll ask around.
davidfetter cotto_work, thanks :) 01:03
Whiteknight DietCoke, did you read my question from earlier?
01:06 Andy joined
DietCoke no. 01:16
email works best for that. 01:20
Whiteknight I'll email you the question then 01:31
DietCoke well I'm _here_ now. =-)
(just if you don't see me answer.)
dalek r28977 | chromatic++ | trunk: 01:43
: [parrot-config] Turned parrot-config into a fakecutable; this allows programs
: to query Parrot's configuration. See RT #32365.
diff: www.parrotvm.org/svn/parrot/revision?rev=28977
stupidbot Error calling said() for rt: Malformed RT response received from rt.perl.org/rt3/
Whiteknight DietCoke, should we create a branch for the "vtable functions have self" stuff? 01:53
it's going to require a number of changes to tests and stuff too
pmichaud if it needs a lot of changes, it's probably wrong.
what sorts of changes are you thinking will be needed (to tests?) 01:54
Whiteknight yes, tests mostly
have to monkey around in IMCC too, and I would rather not do that in trunk
pmichaud the only tests that should be affected would be those using :vtable, right? 01:55
Whiteknight yeah, there were tests in t/pmc/namespace and t/pmc/parrotobject
pmichaud and any subs that have :vtable and :method shouldn't be affected at all
DietCoke branches are cheap.
Basically, if you have to ask, yes. =-) 01:56
Whiteknight Okay, I'll make one up later and we can monkey around in it 01:59
DietCoke apparently picked a bad point to branch off the no_builtin_methods branch, as he got the json testing failures. 02:00
pmichaud when that happens to me I just drop the old branch and start a new one :-)
"branches are cheap" :-)
afk # rummikub 02:01
02:01 Theory joined
dalek r28978 | chromatic++ | trunk: 02:08
: [tools] Removed outdated and bitrotted pbc2c.pl; it doesn't run anymore, and no
: one has touched it in any substantive way since 2005.
diff: www.parrotvm.org/svn/parrot/revision?rev=28978
02:08 magnachef joined 02:26 Eevee joined
dalek r28979 | coke++ | no_builtin_methods: 02:33
:
: Make the find_builtin function always fail.
: Remove the tests that actually check the builtins.
: Only failures are some leftovers from trunk, and some floating point
: differences that our builtin version of say had from print: now that
: we're basically using print, they match up, so we can probably just
: revert those particular failing tests. (and rip out the rest of
: the builtin checker.)
diff: www.parrotvm.org/svn/parrot/revision?rev=28979
02:49 confound_ joined
dalek r28980 | jkeenan++ | autojit: 02:59
: [configure] Refactor some code from within runstep() into
: _check_jitcapability() and _handle_asm(). Move hard-coded jit path to data
: point in auto::jit object.
diff: www.parrotvm.org/svn/parrot/revision?rev=28980
r28981 | coke++ | trunk: 03:12
: pass the codingstd tests
diff: www.parrotvm.org/svn/parrot/revision?rev=28981
DietCoke anyone else having connectivity problems to feather/? 03:18
pmichaud not me. 03:20
at least, if you're reading this then I'm not :-)
Tene I am. 03:22
However, I'm having connectivity problems to everywhere.
DietCoke Hurm. I switched computers on my home network, and it seems fine now. I blame windows, apparently. 03:23
Tene Internet service gets turned on at my house on the 8th. I'm steeeeeealing.
dalek r28982 | coke++ | no_builtin_methods: 03:28
: Merge from trunk up to r28981
: (Mainly to fix all the failing tests that weren't my fault!)
diff: www.parrotvm.org/svn/parrot/revision?rev=28982
cotto_home what's the status of make cover? 03:32
dalek r28983 | pmichaud++ | rakvar:
: Creating branch to fix rakudo variable handling.
diff: www.parrotvm.org/svn/parrot/revision?rev=28983
r28984 | coke++ | no_builtin_methods: 03:45
: Change the expected output of "say <float>" to match print's precision.
diff: www.parrotvm.org/svn/parrot/revision?rev=28984
r28985 | coke++ | no_builtin_methods: 03:57
: use the sqrt method directly instead of relying on auto-dispatch.
diff: www.parrotvm.org/svn/parrot/revision?rev=28985
r28986 | coke++ | no_builtin_methods: 04:11
: Use explicit method calls instead of the implicit ones that are going away.
diff: www.parrotvm.org/svn/parrot/revision?rev=28986
r28987 | coke++ | no_builtin_methods: 04:13
: use explicit method calls instead of relying on auto-dispatch.
diff: www.parrotvm.org/svn/parrot/revision?rev=28987
r28988 | coke++ | no_builtin_methods: 04:19
: remove trailing space
diff: www.parrotvm.org/svn/parrot/revision?rev=28988
r28989 | coke++ | no_builtin_methods:
: Disable more checks for builtins. All tests still pass.
diff: www.parrotvm.org/svn/parrot/revision?rev=28989
r28990 | coke++ | trunk: 04:27
: [build]
: Fix 'make -j'; If you use $(PARROT) in your build step, you should depend
: on it.
diff: www.parrotvm.org/svn/parrot/revision?rev=28990
04:32 masak joined
dalek r28991 | pmichaud++ | trunk: 04:44
: [rakudo]:
: * Clean up placeholder variable actions.
diff: www.parrotvm.org/svn/parrot/revision?rev=28991
r28992 | pmichaud++ | trunk: 05:04
: [rakudo]: change 'process_contextualizer' to 'contextualizer_name'
diff: www.parrotvm.org/svn/parrot/revision?rev=28992
r28993 | chromatic++ | trunk: 05:07
: [PMC] Added splice vtable entry to FixedPMCArray (see RT #34394).
diff: www.parrotvm.org/svn/parrot/revision?rev=28993
05:22 natacha29 joined
dalek r28994 | chromatic++ | trunk: 05:27
: [PMC] Re-added hash and PMC Hash headers mistakenly deleted in r28900, so as to
: allow C++ builds to compile and prevent C builds from warning (NotFound, RT
: #56534).
diff: www.parrotvm.org/svn/parrot/revision?rev=28994
r28995 | pmichaud++ | trunk:
: [rakudo]: methods should be .blocktype('method') instead of using pirflags
diff: www.parrotvm.org/svn/parrot/revision?rev=28995
r28996 | coke++ | no_builtin_methods:
: Eliminate all traces of "builtins"
diff: www.parrotvm.org/svn/parrot/revision?rev=28996
05:30 Psyche^ joined
cotto_home would it be appropriate to add an HLL to COVER_DIRS in the code that generates Parrot's Makefile? 06:03
dalek r28997 | chromatic++ | trunk: 06:09
: [PMC] Re-added hash and PMC Hash headers mistakenly deleted in r28900, so as to
: allow C++ builds to compile and prevent C builds from warning (NotFound, RT
: #56534).
diff: www.parrotvm.org/svn/parrot/revision?rev=28997
06:10 particle joined 06:14 Ademan joined
dalek r28998 | chromatic++ | trunk: 06:26
: [src] Tidied some code; no functional changes.
diff: www.parrotvm.org/svn/parrot/revision?rev=28998
06:51 TimToady joined, diakopter joined, allison joined, cotto-work joined 07:15 magnachef joined 07:41 Ademan joined 08:13 KVirker joined, KVirker left 08:22 stupidbot joined 08:33 bacek joined
dalek r28999 | fperrad++ | trunk: 08:37
: [install] pipp
diff: www.parrotvm.org/svn/parrot/revision?rev=28999
r29000 | fperrad++ | trunk: 08:42
: [smoke] add pipp
: - remove plumhead
: - remove trailing space
: - add Perl coda
diff: www.parrotvm.org/svn/parrot/revision?rev=29000
r29001 | fperrad++ | trunk: 09:38
: [Pipp] recursive count is not implemented
diff: www.parrotvm.org/svn/parrot/revision?rev=29001
r29002 | fperrad++ | trunk: 09:40
: [Pipp] complete ctype
diff: www.parrotvm.org/svn/parrot/revision?rev=29002
09:41 stupidbot joined 09:46 MeGaMiC joined 09:52 bacek joined 09:57 bacek joined
bacek evening everyone 09:57
moritz good localtime() bacek ;) 09:58
bacek moritz: :) 09:59
rt #56214 10:06
stupidbot Error calling said() for rt: Malformed RT response received from rt.perl.org/rt3/
bacek stupid bot...
I've disable this function for now...
message pmichaud index2.diff from RT#56214 waiting for your opinion 10:07
purl?
spinclad s/message/msg/ maybe? 10:13
purl, messages? 10:14
ENOPURL
10:15 barney joined 10:18 rurban joined
rurban Shouldn't contain the languages/*/Makefile a install target? I'd need it for the examples and docs 10:18
10:36 kj joined, vhold joined
barney They probably should have an 'install' target. But nobody bothered yet. 10:36
dalek r29003 | bernhard++ | trunk: 10:40
: [Pipp]
: Add a TODO test for contants.
diff: www.parrotvm.org/svn/parrot/revision?rev=29003
10:42 Whiteknight joined 10:48 davidfetter joined 11:07 contingencyplan joined 11:08 kid51 joined 11:16 contingencyplan joined 11:19 rdice joined
rurban cygwin needs to add an import lib. How does mingw does that? 11:19
in root.in I'd need just to add something like after LIBPARRTO_SHARED LD : #CONDITIONED_LINE(win32):\t----out-implib libparrot.dll.a \\ 11:20
The problem is just the ldflags line in pkgconfig and config_lib.pasm. -lparrot 11:21
linking to a dll alone works fine, but this would need to change those two settings. Generating the import lib seems to be easier.
All assumed from a packaged version via reallyinstall. 11:22
dalek r29004 | bernhard++ | trunk: 11:25
: [Pipp]
: Implement define() and constant().
diff: www.parrotvm.org/svn/parrot/revision?rev=29004
rurban BTW: does #CONDITIONED_LINE(win32) contain cygwin also? 11:26
nope. 11:27
kid51 barney: There was a message posted to list requesting that commit messages contain more than just the subsystem -- that they include some description as well. (Some problem with a git tool.)
barney rurban you can ask ./parrot_config win32 11:28
kdi51: do you mean int the first line of the message ? 11:30
moritz that's what the git tools expect, yes
rurban barney: I only got cygchkdll for cygwin. good enough.
barney I see 11:36
11:49 tetragon joined
kid51 barney: Yes. See a post by G Broadwell in past day. (Just passing the message along; I have no preference, myself.) 11:52
kid51 only started to indicate a subsystem in commit messages in the past few days :-) 11:54
tetragon kid51: At some point in the near future, I'll be temporarily unable to do any PPC testing. (near future is defined as when Apple can ship an LCD panel to Toronto without damaging it)
kid51 Thanks for the update. I've been nudging people who participated in buildfest at YAPC to try out all your patches, but am experiencing the herding cats problem. 11:55
dalek r29005 | bernhard++ | trunk: 11:57
: [Pipp PHC] Add support for constants.
diff: www.parrotvm.org/svn/parrot/revision?rev=29005
tetragon I'm half-tempted to check the boxes at the Apple store for Xcode and do 10.5 Intel testing there 11:58
moritz bacek: are you around? 12:00
bacek moritz: little bit
for.t?
moritz bacek: with your latest index() patch, will the returned failure be a StrPos? 12:01
bacek not yet.
actually I thinks that StrPos is redundant... (Int|Failure) junction is enough for any use-cases... 12:02
perl6: my Int $a = 0; say defined $a;
polyglotbot OUTPUT[1ā¤]
barney is going to enjoy the sun at the Isar
moritz bacek: only as long as we don't implement character levels 12:03
barney: Munich?
bacek so, for index() we need something like my $p = $b.index(foo); if defined $p ...
barney Yes
moritz bacek: I'm going to apply your patch and extend the tests a bit 12:08
dalek r29006 | moritz++ | trunk: 12:12
: [rakudo] implement Str.index, patch curtesy by bacek++ (Vasily Chekalkin)
diff: www.parrotvm.org/svn/parrot/revision?rev=29006
r29007 | moritz++ | trunk: 12:18
: [rakudo] add S29-str/index.t to spectest_regression.
: bacek++ for implementing
diff: www.parrotvm.org/svn/parrot/revision?rev=29007
12:30 skv joined
dalek r29008 | pmichaud++ | trunk: 12:45
: [rakudo]: coding stds in src/classes/Str.pir .
diff: www.parrotvm.org/svn/parrot/revision?rev=29008
12:46 rdice joined
moritz parrot doesn't seem to implement complex log() function 12:48
pmichaud it's possible. 12:49
moritz I tried to cargo-cult a log(Complex) impelementation in the same way that exp() is done, and it still returns 0 always 12:50
oh wait, it does seem to be implemented 12:51
and it seems to be correct (at least from a glance at the src/pmc/complex.pmc file) 12:53
pmichaud nopaste diff ?
nopaste "moritz" at 89.13.212.252 pasted "complex log() and log10() for rakudo - not working" (53 lines) at nopaste.snit.ch/13453 12:54
pmichaud log10 doesn't appear to be implemented in complex.pmc 12:56
moritz yes, but if parrot is clever enough it just dispatches to log(x)/log(10) 12:57
pmichaud I don't think parrot is that clever
moritz that would explain whay log10 doesn't work, but what about log()?
btw I fear the complex log10 tests are a bit wrong ;) 12:58
... not anymore ;) 13:02
pmichaud what test file?
moritz spec/S29-num/log.t 13:03
nopaste "pmichaud" at 76.183.97.54 pasted "log on complex seems to work" (14 lines) at nopaste.snit.ch/13454 13:06
pmichaud log10 fails 13:07
nopaste "pmichaud" at 76.183.97.54 pasted "log10 fails" (15 lines) at nopaste.snit.ch/13455
pmichaud I'm not sure why your patch doesn't work, unless it's due to Parrot MMD somehow.
DietCoke is ln an opcode or a method dispatch? 13:09
(method dispatch is going away)
pmichaud it's a pseudo-opcode that does method dispatch
DietCoke: do you plan to replace it with a real opcode, or eliminate it entirely?
DietCoke nothing in core was using it. in the no_builtin_methods branch, it's just gone. I can add opcodes for anything that was a builtin for which an opcode is needed. 13:10
but I didn't want to bother adding opcodes for things that weren't used.
pmichaud adding an opcode might be tricky
and I'd be initially against that approach 13:11
DietCoke as am I. Good. switch to explicit methods. =-)
(may be why the log10 isn't working, that may not be in the list in src/builtin.c on trunk.
pmichaud log10 isn't implemented in complex.pmc
DietCoke ah. (yah, it's in the list, so that'd do it.) 13:12
so far, the only opcodes I added were the 4 say variants.
pmichaud if we write an opcode for 'ln', we also have to do opcodes for
"abs", "neg", "not", "fact", "sqrt", "ceil", "floor"
"acos", "asec", "asin",
"atan", "cos", "cosh", "exp", "ln", "log10", "log2", "sec",
"sech", "sin", "sinh", "tan", "tanh", "fact"
DietCoke yup. note that I think most of those already have _n_n variants.
pmichaud and that seems like a horribly lot of opcodes to generate if they're just going to be turned into method calls
DietCoke I'll all for dropping them, no arguments here. 13:13
pmichaud okay
DietCoke I was only considering it on the off chance you were going to ask for them.
pmichaud right now I'm on a "get rid of unneeded opcodes" bias
DietCoke You can switch over to the method syntax now.
(if you want, you can try out the branch and see what breaks in perl6 there. 13:14
(this whole thing, btw, is just to help me kill the getclass opcode. =-) 13:15
pmichaud I'm trying to focus on $_ handling today
I was going to do it yesterday but family events kept me from really getting into it
moritz: instead of a = ln a 13:16
try
a = a.'ln'()
that switches it from being an opcode to a method call
13:17 Whiteknight joined
moritz pmichaud: no luck here 13:18
pmichaud hrm
I suspect mmd issues then
moritz pmichaud: but focus on $_ first, that's much more important atm ;)
pmichaud I agree
DietCoke has about a dozen checkouts of parrot on feather. Oy. 13:20
dalek r29009 | coke++ | no_builtin_methods: 13:24
: Remove targets related to src/builtin.c
: Add in some -j protection from trunk.
diff: www.parrotvm.org/svn/parrot/revision?rev=29009 13:25
DietCoke what generates this line in src/gen_builtins.pir for perl6: .sub 'exp' :multi(Complex) 13:29
moritz DietCoke: that's from src/classes/Complex.pir
gen_builtins.pir seems to be the concatenation of src/classes/* and src/builtins/* 13:30
13:32 rurban joined
DietCoke ok. with a small change to Complex, all internal tests pass. checking the regression tests... 13:32
nopaste "coke" at 65.91.151.194 pasted "Use explicit method syntax..." (22 lines) at nopaste.snit.ch/13456 13:33
dalek r29010 | pmichaud++ | trunk:
: [rakudo]: spectest-progress update: 83 files, 1365 passing tests
diff: www.parrotvm.org/svn/parrot/revision?rev=29010
DietCoke (though looking at that, I'm wondering why I passed the argument in one case, and not the other.
presumably I'll find out if something fails in the regression. =-)
pmichaud should _not_ be passing the argument, I suspect. 13:34
DietCoke eh, these methods are wierd, at least on the base float.
pmichaud we aren't calling the methods on the base float, though.
rakudo's floating point sqrt currently uses sqrt_n_n 13:35
DietCoke ok. are these getting called on the root Complex object?
pmichaud probably not 13:36
looks like it's a subclass of Complex
DietCoke ok. with that small patch, no problems with assuming any other builtins. 13:40
pmichaud excellent. DietCoke++ 13:41
Coke++
DietCoke so, just figure out which PMC is actually getting those invoked to figure out if you need to pass it. if it's like Complex in core, you don't need 'em.
pmichaud (just to get all the karmas in the right slots :-)
Float requires that it be passed?
that's.....odd
and perhaps even wrong.
DietCoke ah, no. I was confusing it with the string methods. 13:42
pmichaud okay
DietCoke (some of which require you pass IN a string to work on.)
(even though, clearly, you've already got one.)
pmichaud okay, I'm going to focus on $_ for a while, so I might not answer unrelated questions :-) 13:43
I might not even make any snide remarks :-)
moritz snide remarks = sneaky side remarks? ;-) 13:44
pmichaud <no remark here>
13:47 rdice joined
particle $_ 13:49
moritz particle: implicit remark? ;-) 13:51
pmichaud .that_would_be_this
moritz pmichaud: you lost ;)
pmichaud I said *might*
besides, $_ is clearly on topic :-)
particle i'm just encouraging conversation about the current topic 13:52
dalek r29011 | pmichaud++ | rakvar: 13:57
: drop branch to re-sync it with trunk
diff: www.parrotvm.org/svn/parrot/revision?rev=29011
r29012 | pmichaud++ | rakvar: 13:58
: Recreate branch from trunk
diff: www.parrotvm.org/svn/parrot/revision?rev=29012
14:00 rjbs left 14:16 confound joined 14:18 gmansi joined 14:40 Ontolog joined
dalek r29013 | fperrad++ | trunk: 14:41
: [Pipp] file_get_contents & readfile
diff: www.parrotvm.org/svn/parrot/revision?rev=29013
Ontolog oh cool I'm logged publicly? 14:42
pmichaud irclog.perlgeek.de/parrot/today 14:43
moritz and irclog.perlgeek.de/perl6/today for #perl6 14:45
dalek r29014 | Whiteknight++ | gsoc_pdd09: 14:53
: [gsoc_pdd09] changes to header allocators. Better separation between aggregate and non-aggregate types
diff: www.parrotvm.org/svn/parrot/revision?rev=29014
r29015 | Whiteknight++ | gsoc_pdd09: 15:00
: [gsoc_pdd09] updating to trunk r29014
diff: www.parrotvm.org/svn/parrot/revision?rev=29015
rurban I've prepared now a patch which renames pdb to parrot_pdb - conflicts with existing pdb binaries. (python, ...) 15:08
DietCoke feather going down shortly. 15:12
moritz hard disk failure
DietCoke save early save oftne. 15:13
moritz commit often. (wait, that doesn't help if the svn repo is on feather... ;-)
Whiteknight is the repo mirrored anywhere? 15:23
Infinoid I didn't think the svn repo was on feather 15:26
DietCoke ours isn't, no. 15:27
particle pugs repo is on feather 15:28
so, no spectest updates for a while
i hope moritz can deal with that :)
moritz particle: I'm writing the "how to add tests" howto, it'll take some time to finish before I want to commit it ;) 15:29
cotto_home moritz, are you putting something about make cover in there to see what still needs to be tested? 15:30
moritz cotto_home: Perl 6 spectest, not parrot tests :/ 15:31
cotto_home gotcha
particle unless cotto_home has developed a coverage testing engine for perl 6... 15:34
cotto_home no such luck 15:38
15:48 cjfields joined 16:01 james joined, rob joined 16:03 jan joined 16:06 wolverian joined 16:08 dalek joined 16:09 leo joined, polyglotbot joined 16:11 pmichaud joined, PerlJam joined 16:12 rob left 16:13 Whiteknight joined
DietCoke how can I easily do a diff of "stuff I've changed on branch foo as compared to trunk". do a reverse merge then an svn diff of my work dir? 16:13
16:14 Ontolog joined
particle you wanna diff against head, or base? 16:16
DietCoke welp, I was thinking base originally,but since it would have to be applied against head... I'll just do it this way. =-)
16:16 Juerd joined
particle okie, that'll work 16:16
DietCoke hurm. annoying. I want -all the changes on that branch-, but I still have to specify start/end revisions. 16:17
particle svn log --stop-on-copy 16:18
that'll get you the rev number for branch creation 16:19
DietCoke I can get it, it's just annoying that svn merge isn't doing that -for- me. =-) 16:20
DietCoke tells himself "this is still better than CVS." =-)
moritz DietCoke: that's one of the many reason why SVN sucks
16:20 james left
dalek r29018 | Whiteknight++ | vtable_self: 16:21
: Creating branch to work giving vtable functions the self keyword
diff: www.parrotvm.org/svn/parrot/revision?rev=29018
DietCoke hurm. now the merge seems to be picking up things it shouldn't.
in a check out of trunk, I was running:
svn merge -r28930:HEAD svn.perl.org/parrot/branches/no_bu...n_methods/ .
where 28929 is the revision that created the branch.
moritz: in this case, most of the suck could be handled by a small wrapper script. 16:22
moritz DietCoke: or by native support for branches ;)
16:23 Casan joined 16:24 sjansen joined
particle DietCoke: then why didn't you use 28929 in the merge? 16:25
16:26 Ademan joined, jonathan joined
particle see docs/project/committer_guide.pod 16:26
16:27 magnachef joined
dalek r29019 | Whiteknight++ | vtable_self: 16:27
: [vtable_has_self] uploading initial patch to IMCC grammar. Modification to one test for desired behavior.
diff: www.parrotvm.org/svn/parrot/revision?rev=29019
16:34 Theory joined 16:35 barney joined 16:38 Theory joined
DietCoke particle: doesn't seem to impact the update in the merge of wrong stuff. 16:40
U runtime/parrot/library/CGI/QueryHash.pir
(If that was ever changed on branch, it was only because i merged changes from trunk.)
japhb Thank you, kid51 and moritz, for speaking up on behalf of git tools in the wee hours today.
DietCoke: I think you're beginning to see why adherents to other source controls say that SVN merge is insane .... 16:41
rurban I'm ready now with my cygwin perl package and will update the Bug#56544 with the final install_files.pl patch. 16:42
16:42 DietCoke left
particle rurban++ 16:43
rurban we will see how useful the layout will be. I just put all the languages with the exe's and the docs and examples into one big parrot-languages package
just parrot-perl6 is seperate. I didn't like it to be named as in fedora: "parrot-rakudo" 16:44
dalek r29020 | pmichaud++ | rakvar: 16:46
: [rakudo] implicit part 1
: * Eliminate incorrect declarations from statement_block
: * Add declare_implicit_var to allow controlled addition of implicit vars 16:47
diff: www.parrotvm.org/svn/parrot/revision?rev=29020
r29021 | bernhard++ | trunk: 17:01
: [Pipp PHC] Fiddle with the SEA-rule. Pass hello_11.php.
diff: www.parrotvm.org/svn/parrot/revision?rev=29021
17:09 tco joined
dalek r29022 | pmichaud++ | rakvar: 17:16
: [rakudo]: implicit vars #2
: * Eliminate __MAYBE_NEED_TOPIC_FIXUP
diff: www.parrotvm.org/svn/parrot/revision?rev=29022
r29023 | pmichaud++ | rakvar: 17:19
: [rakudo]: implicit vars #3
: * Anything that parses with a signature goes into $?BLOCK_SIGNATURED,
: even if the signature is empty or non-existent
diff: www.parrotvm.org/svn/parrot/revision?rev=29023
17:19 desertmax joined
dalek r29024 | bernhard++ | trunk: 17:21
: [Pipp PCT] Use correct sub for string concatenation.
: Pass two more test cases in hello.t
diff: www.parrotvm.org/svn/parrot/revision?rev=29024
r29025 | pmichaud++ | rakvar: 17:31
: [rakudo]: implicit vars #4
: * Change routine_def to initialize $_, $/, $! to be scalars
: * $! and $/ in pblocks default to OUTER::<$!> or OUTER::<$/>
diff: www.parrotvm.org/svn/parrot/revision?rev=29025
r29026 | bernhard++ | trunk: 17:36
: [Pipp PCT] use correct subs for string comparison.
: Pass some more TODO tests.
diff: www.parrotvm.org/svn/parrot/revision?rev=29026
particle pmichaud: how do you specify unlimited outer? i suggest either 0 or '*' 17:50
0 would allow max to stay an int
pmichaud it's strictly internal at this point 18:00
it will either be MAX_INT or -1, though
because 0 will be used to indicate "search caller's scope"
particle i thought 1 was caller's scope 18:09
hrmm
pmichaud 1 is caller's outer scope 18:10
particle yeah, took another read to see that
pmichaud I don't have the params in yet for it (because don't want to add them if I don't need them), but the idea will be that !OUTER can specify the min and max depths
particle ## start with caller's outer scope (i.e., outer depth is 2)
.local int depth
depth = 2
pmichaud with default of both being 1
particle that's a confusing comment 18:11
18:11 peepsalot joined
pmichaud the current scope is inside of !OUTER 18:11
depth 1 is the caller's scope
depth 2 is the caller's outer scope
particle yes, i see that. 18:14
however, the api comment refers to caller's immediate outer scope as 1
pmichaud ...api comment?
oh, right 18:15
particle C<max> parameter specifies the maximum outer to search -- the default value of 1 will search the caller's immediate outer scope and no farther.
so you have a magic number of 1 inside the sub
18:15 slightlyoff joined
particle you add to depth 18:15
pmichaud when I do '!OUTER'('$foo', 3) it means that I want to search up to 3 outer scopes from the current one
which means I search up to 4 outer scopes from within !OUTER
18:15 slightlyoff left
pmichaud I can change depth to read depth = min+1 18:16
particle yes, that's what i'd like :)
also, does it make sense to rename BLOCK_SIGNATURED to ROUTINE? the first isn't a very clear name, but i'm not certain the second is precise 18:17
pmichaud not every signatured block is a Routine
for example, -> $a { ... } has a signature but isn't a routine
particle yeah, that's what i was thinking :(
18:18 cjfields left
particle and POINTY_OR_ROUTINE is ugly too 18:18
pmichaud and what I'm really getting at is that a PAST::Block has already been started, because we parsed a signature
as opposed to creating a new PAST::Block at this point (e.g., for a bare curly)
dalek r29027 | pmichaud++ | rakvar: 18:19
: [rakudo]: implicit vars #5
: * Change comment and definition of depth in !OUTER, per particle++
diff: www.parrotvm.org/svn/parrot/revision?rev=29027
particle thanks, pmichaud++ 18:21
Tene Hmm... I should push this stuff up before I forget about it. 18:23
dalek r29028 | tene++ | trunk: 18:26
: [lolcode]
: * Store params in $?BLOCK symtable.
: * Store subs in $?BLOCK symtable.
: * Start building a parse tree for expressions at compile time.
: * Minor PCT typo fix.
diff: www.parrotvm.org/svn/parrot/revision?rev=29028
Tene pmichaud: I was looking into examining the lexical environment to find vars and subs that the compiler doesn't know about for lolcode, and I realized that in normal cases, the compiler is already running in the same environment that the compiled code will run in, so I can just do normal lookups instead of passing something in, afaict. Can you confirm or deny that this is a sane plan? 18:28
rurban I cannot see jesse. I cannot mail to parrotbug@parrotcode.org from seamonkey my latest cygwin realinstall fixes. Not with attachments and not without. 18:30
Should I just send them to the -porters list instead? 18:31
NotFound Tene: looks not sane to me, that way the code will no work same way when running a generated pbc. 18:32
moritz rurban: yes
pmichaud Tene: it depends on the structure of the compiler
cotto-work particle, ping
pmichaud However, in some cases it is reasonable for the compiler to look at the existing environment for hints 18:33
for example, things like eval() can do that
cotto-work the meeting is cancelled 18:34
I'm really sorry to do that, but one Anandeep is sick and needs to be there
particle cotto-work: ack! oh, well 18:36
then i can start my vacation earlier
Tene >
> Thanks.
>
> -Daniel
>
> ________________________________
>
> From: Stephen Weeks [mailto:sweeks@gurulabs.com]
> Sent: Wed 7/2/2008 11:14 PM
> To: Daniel Lyman
> Subject: Re: RE : [Fwd: RE: fooru kernel module problem in GL250]
>
18:36 Tene left
Whiteknight ...? 18:37
NotFound Wrong paste target?
moritz seems like ;)
18:38 Tene joined
dalek r29029 | Whiteknight++ | vtable_self: 18:38
: [vtable_has_self] added some comments around to help me find my way through this IMCC mess.
diff: www.parrotvm.org/svn/parrot/revision?rev=29029
Tene fail. 18:39
moritz Whiteknight++ # gsoc_pdd09 branch builds cleanly 18:41
Tene moritz: does it run, though? I thought he said it didn't run yet.
Whiteknight it builds!?! 18:42
I mean, it didn't last time I checked
moritz Tene: it doesn't, "make test" segfaults on PGE.pbc
Whiteknight okay, that's more like it. That's it's been doing for me
moritz Whiteknight: I just updated, 'make realclean; perl Configure.pl && make -j 2', and it compiled ;)
Whiteknight what platform are you guys one?
s/one/on/ 18:43
moritz Debian (32 bit i386)
Whiteknight holy crap, same as me
Whiteknight has to go try it again now
moritz from a cross-platform development POV it's a boring platform 18:44
because all the platform dependent failures happen on other OSses ;)
NotFound moritz: or at least, we do don't know if the problems we have are platform dependant, we fix anyway. 18:46
Whiteknight moritz, you're saying that it compiled all the way through? did it build PGE.pbc? 18:49
dalek r29030 | pmichaud++ | rakvar:
: [rakudo]: implicit vars #6
: Make subroutines to handle implicit vars in immediate blocks (e.g., 'if')
: and in function blocks (e.g., 'for').
diff: www.parrotvm.org/svn/parrot/revision?rev=29030
moritz Whiteknight: I think that the last output from 'make' was not an error
Whiteknight: then I did a "make test", and it complained about PGE.pbc 18:50
Whiteknight I'm double-checking now. but if it works then it's a miracle
moritz trying again to confirm
no error message in the last few lines, but 'make' had an exit status of 2 18:51
Whiteknight yeah, the -j hides the failure on PGE.pb
scroll up a bit and you can see the segfault 18:52
moritz tries again without -j2 and without ccache
particle pmichaud: this refactor and enhancement is looking really good so far 18:58
moritz pmichaud: when you're done with your branch the autounfudge tool will really help ;-)
particle moritz: svn diff exists on windows, can you use that instead of diff? 18:59
moritz particle: don't think so, the files are not under version control
Auzon You can get GNU diff for Win32.
moritz particle: (unless you find a way to hijack svn diff for arbitrary files)
dalek r29031 | bernhard++ | trunk: 19:01
: [Pipp PCT] Start to use optok parsing.
diff: www.parrotvm.org/svn/parrot/revision?rev=29031
particle i have diff on win32, but it's hard to make that a requirement 19:03
moritz particle: is it worse than requiring Algorithm::Diff and a custom workaround? 19:05
particle yes, it's worse 19:06
cpan requirements are better than non-cpan
from my pov. don't know how patrick feels
moritz ok, I'll see if I can find some tuits to work around it 19:07
particle write a diff util in rakudo
:)
19:08 DietCoke joined
NotFound Or in lolcode. 19:08
DietCoke tries to summon dietcoke
Tene lolcode doesn't have IO yet. 19:09
NotFound Even better ;)
DietCoke tries to summon dietcoke, one more time. 19:11
PerlJam What's Pipp? Is that the new name for plumhead? 19:12
Tene Yes.
PerlJam cool
rurban moritz: I got now enough tuits to send email to parrotbug :) 19:13
cotto-work pipp is <reply>Pipp is Parrot's PHP
rurban moritz: problem was the missing -- bla --- bla markers
cotto-work purl, pipp is <reply>Pipp is Parrot's PHP
purl-- 19:14
rurban I have to package the new clisp-2.46 now, and come then back to parrot. I believe some there are still some dynlib problems with wrong dll names for cygwin. 19:16
particle heads for the rain forest. happy fourth! & 19:18
cotto-work take pictures! 19:19
dalek r29032 | fperrad++ | trunk:
: [Pipp] add PMC PhpResource
diff: www.parrotvm.org/svn/parrot/revision?rev=29032
r29033 | bernhard++ | trunk:
: [Pipp PCT] Add bitwise ops to optok parsing.
: However readded tests are still TODO.
diff: www.parrotvm.org/svn/parrot/revision?rev=29033
cotto-work barney, does fperrad know that I've got an out-of-tree phparray implementation? 19:25
I'd hate for there to be duplication on something like that 19:26
barney cotto: I don't know. Maybe we should do a #pippsketch 19:27
cotto-work getting him to hang out on #parrot would be sufficient 19:28
barney That's right. 19:29
cotto-work do you know why he doesn't? His English seemed fine over email.
barney Probably simply personal taste 19:31
PerlJam cotto-work: why out-of-tree? :) 19:32
cotto-work there's no accounting for taste
I wrote some of it during working hours and need to get the legal dep't to clear it before I can commit
PerlJam oh.
cotto-work yeah 19:33
barney is calling it a day
19:48 iblechbot joined
Whiteknight Is there a way to determine whether a given PMC has an overridden Invoke vtable method? 19:51
or, whether it's invoke vtable is defined in PIR?
Tene Hmm... I wonder if I committed something I shouldn't have committed. 19:53
pmichaud ...now to see how much of spectest_regression is broken with my changes. 19:54
dalek r29034 | tene++ | trunk: 19:59
: [lolcode]
: * Oops, left some debug statements in. Remove them.
diff: www.parrotvm.org/svn/parrot/revision?rev=29034
Whiteknight will the find_method vtable function find a vtable method if it exists, or will it only find methods? 20:04
pmichaud it only finds methods 20:05
Whiteknight is there something I can do to look up a vtable method then, given it's name?
pmichaud vtable methods aren't callable directly from pir, unless they're indicated via :method or are otherwise treated as a sub 20:06
Tene What is the consequence of running load_bytecode on the same pbc multiple times?
pmichaud tene: if it's the same pathname each time, only the first load occurs. Later ones are short-circuited.
Tene Fantastic.
Whiteknight okay, I think i'm thinking about the wrong problem
pmichaud parrot doesn't distinguish between 'foo.pir' and 'foo.pbc' (those would each be loaded) 20:07
and likely 'path/to/foo.pbc' and 'foo.pbc' would cause a double-load also
we had some discussion years ago about embedding a uuid into the .pbc files to detect it based on the file..... but that didn't happen
Whiteknight: if I define a vtable method in PIR as .sub 'foo' :method :vtable('get_boolean') 20:08
then I can only get to it as a method by using $P0.'foo'
er
then I can only get to it as a method by using $P0.'foo'() --- i.e., find_method will only find the 'foo' entry
nopaste "tene" at 67.137.148.11 pasted "handle :lang in eval()" (47 lines) at nopaste.snit.ch/13457
Whiteknight pmichaud, I'm trying to fix invokations of the type $P0(), which calls the invoke vtable method
pmichaud Whiteknight: yes, I remember those being somewhat broken. :-| 20:09
Tene That's a bit hackish, but it works until we actually have a registry solution of some sort.
pmichaud ...but I thought they were fixed now. at least when I tested it a couple of months ago it seemed to do what I wanted
Whiteknight I think IMCC generates a callmethod opcode for that, and I think I can implement the solution directly in the opcode itself if I can figure out what I need
it probably works now, I'm trying to implement a patch where :vtable functions have the "self" keyword 20:10
pmichaud ....why would $P0() generate a callmethod opcode? that seems....wrong
Whiteknight maybe it generates an invoke opcode, I'm having trouble reading this IMCC source
pmichaud invoke opcode would be correct, yes.
Whiteknight either way, I'll figure it out
pmichaud Whiteknight++ 20:11
pmichaud gets a stunned look
<stunned look>....spectest_regression passed with my changes on the first attempt.</stunned> 20:12
Tene Nice.
Whiteknight pmichaud++
pmichaud that's.... scary.
Tene pmichaud: does it pass *more* tests, though?
pmichaud good scary, but still scary.
20:12 rurban_ joined
pmichaud Tene: if I remove a few 'skip' markers it might :-) 20:12
PerlJam pm: clearly your changes weren't broad and sweeping enough :)
pmichaud I guess not. 20:13
I guess I need broader and sweepier changes.
Tene pmichaud: will you have tuits to look at that eval patch for me? 20:15
20:15 allison joined
Tene Seems to work fine with lolcode, but cardinal gives me some weird errors I need to look at. 20:16
pmichaud what if the name of the compiler doesn't match the name of the pbc?
perhaps rakudo should have a registry of :lang values, at least short-term. 20:17
Tene That's too architectural for me to propose. 20:18
Whiteknight philosophical question: Instead of treating the "self" of a method as just the first in a list of arguments, could we create an interp->arg_self field and pass it in there separately? 20:19
Tene tcl gives me 'Null PMC access in find_method' and cardinal gives me "push_pmc() not implemented in class 'Sub'"
Tene tries lua 20:20
pmichaud I really like the fact that self is the first argument
it fits well for Rakudo and PGE
dalek r29035 | moritz++ | trunk:
: [rakudo] added S03-operators/arith.t to spectest_regression. Auzon++
diff: www.parrotvm.org/svn/parrot/revision?rev=29035
r29036 | fperrad++ | trunk:
: [Pipp] fopen, fclose & fpassthru
diff: www.parrotvm.org/svn/parrot/revision?rev=29036
Whiteknight okay
Tene lua gives me "Unknown PMC type to thaw 0" 20:22
Whiteknight okay, let me ask from a different angle. If I overwrite the invoke vtable of the Sub pmc, what does that look like internally? How does parrot know whether to call the PIR method or the C method? 20:23
Tene APL works, except for encoding issues.
pmichaud I don't think you can overwrite 'invoke' of the Sub pmc, except via a subclass of Sub
that's like saying "how can I overwrite the get_integer vtable of the Integer pmc" 20:24
Whiteknight oh, I see what you are saying, so you cant have both a PIR and a C version of the same vtable method in the same class? That makes a little bit more sense
pmichaud I'm not even sure it's possible to overwrite a vtable method of a PMC class 20:25
(from PIR)
...but if you can, then it would seem to replace any existing vtable method for that PMC class 20:26
Whiteknight okay, so that's only possible for PIR-defined classes and subclasses?
pmichaud I think so. I'm not the architect, but that's my expectation.
20:27 AndyA joined
Whiteknight okay, so would you know if, at the C level, that there is a way to determine whether a particular vtable method is defined in C or PIR? 20:27
Tene Ooo... I get "continuation jumping runloops" trying to eval php from rakudo.
pmichaud Tene: I suspect that :lang on eval may need to wait on pdd25cx, then 20:28
if not for rakudo (and others) to start using .HLL
Whiteknight: I'm sure there's a way to find out if a vtable method is defined in C or PIR, but it seems like one shouldn't need to check that
Whiteknight pmichaud, you would think so. PIR-defined vtable methods need to be passed the "self" argument, whereas C-defined versions already have it 20:29
"invoke methods" 20:30
pmichaud ...but wouldn't this be the same code that is already handling :method flags?
Whiteknight no. $P0() calls the invoke opcode, not the callmethod one 20:31
pmichaud let me put it another way
currently if I do
.sub 'foo' :method :vtable('get_boolean')
and then later do
$I0 = istrue $P0
then my 'foo' method gets invoked, and self is properly set to $P0 20:32
note that there's no "callmethod" opcode here.
so _something_ is already handling this.
Whiteknight okay, I think I'm explaining it wrong
I'm talking about the "invoke" vtable method only, not get_boolean or any others
if I have ".sub invoke :vtable", without the :method, the invoke function should have a "self" argument 20:33
pmichaud ...but if you wrote ".sub invoke :vtable :method" it would work, right?
Whiteknight probably, yes
pmichaud that's what I mean "it's the same code that is already handling :method flags"
we just want it to happen for :vtable even when :method isn't present.
i.e., ":method" is in some sense redundant here --- every :vtable effectively implies :method 20:34
Whiteknight exactly. But IMCC can't determine whether "$P0()" calls a custom vtable override, however
pmichaud I don't think IMCC is what should be determining that.
that seems like it's part of the vm itself
Whiteknight But IMCC sets up the code to pass the arguments, including the "self" argument 20:35
pmichaud ohhhhhhhh
Whiteknight so, based on syntax, if I call "foo.bar()" IMCC passes "foo" as the first argument to "bar"
pmichaud this gets back to my point earlier
$I0 = istrue $P0
Whiteknight but If I call "$P0()" It won't pass $P0 as the first argument to it's invoke vtable
pmichaud IMCC doesn't have to know that $P0 is to be the first argument to 'foo' -- something else is doing that.
same goes for $P0() 20:36
IMCC shouldn't be responsible for passing the additional argument
Whiteknight Right, which is why I'm trying to find a more appropriate place to do it
pmichaud instead, the invoke opcode needs to be smart enough to say "oh, I'm going to a PIR vtable method, so pass the thing being invoked as its first argument."
Whiteknight Exactly, and if the invoke vtable method is a PIR function, we need to pass the invoked object as the "self" parameter first 20:37
currently, this is not happening, unless we do :method too
pmichaud and if .sub 'invoke' :vtable :method already works, then the 'invoke' opcode already has the logic for doing that
(otherwise it wouldn't work.) 20:38
Whiteknight let me test quickly that it actually does work as I am expecting...
pmichaud yes, it's entirely possible that it doesn't work.
Whiteknight no, it doesnt work
nopaste? 20:39
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
pmichaud okay, so it's the invoke opcode that likely needs work
but IMCC should always generate the same code for $P0() (since IMCC can't know what $P0 is)
Whiteknight right, that's the conclusion I'm slowly arriving at
Yeah, I spent a lot of time reading through IMCC before I realized that
pmichaud ....actually, it's not even the opcode that needs to do it 20:41
it's the invoke vtable method that needs to do it
just a sec 20:42
Whiteknight rafb.net/p/nCAxGE45.html
this shows you what I'm trying to do, basically 20:44
i have the basics up and running in branches/vtable_has_self
pmichaud I get "invoke() not implemented in class 'Foo'" 20:45
ah, missing a namespace
nopaste "tene" at 67.137.148.11 pasted "parrot dies on loading perl6.pbc and cardinal.pbc" (8 lines) at nopaste.snit.ch/13459
pmichaud okay, now I get "too few arguments"
so :method doesn't help here 20:46
Whiteknight right, it's attempting to slurp up "self" as the first argument, but a self was never passed
in C, it's always called self->vtable->invoke(interp, self, next_addr), so it has the self. 20:47
pmichaud I think the culprit is src/pmc/object.pmc:528-529
it could also be the invoke vtable method in Sub 20:48
Whiteknight is "object.pmc" a top-level class?
pmichaud yes.
it's the base class for all PIR-class objects
Whiteknight I've been hunting for this kind of thing all day 20:49
and you find it in like 30 seconds
pmichaud I have a few years advantage in parrot
also, I was recently in the invoke code when trying to figure out the lexical issues a couple of weeks ago :-)
Whiteknight so if I push on another argument in that place you pointed out, you think that will solve (or approximately solve) my problem? 20:50
20:50 AndyA joined
pmichaud I'm not sure. I'm thinking maybe not. 20:50
Whiteknight well, I'm going to try it anyway
pmichaud there's got to be another step involved here somewhere
Whiteknight why do you say that?
pmichaud I'm trying to figure out how the 'istrue' opcode manages to set 'self' 20:51
istrue just becomes a call to the get_bool vtable method
and somehow that vtable method manages to set self when calling a PIR-based method
Whiteknight does is_true have self in trunk? 20:52
pmichaud lost me there.
Whiteknight IMCC currently doesnt parse the keyword "self" unless the :method tag is on a sub
pmichaud right, I mean when :method is present it works somehow 20:53
and I don't mean from the IMCC perspective
Whiteknight okay
pmichaud I mean from the vtable activation perspective
somehow when the get_boolean vtable method is activated, it manages to pass the PMC as the first argument to the corresponding PIR sub 20:54
(which IMCC then picks up as :self because of the :method flag)
er, s/:self/self/
Whiteknight so the question is, how does istrue pass that first argument?
pmichaud more precisely, how does get_boolean do it.
(or get_integer, or get_pmc_indexed_keyed, or any of the other vtable methods besides 'invoke') 20:55
the 'invoke' vtable method seems to be the only one that isn't passing a first argument as 'self'
Whiteknight I think it's because of the way IMCC parses it 20:57
pmichaud nononononono
you're too fixated on IMCC, I think :-)
Whiteknight That has to be a component of if
pmichaud (easy to do :-)
Whiteknight or, problems in IMCC lead to workarounds elsewhere
pmichaud all that IMCC needs to do is recognize that when :vtable is present that it needs to recognize self 20:58
in the same way that it does for :method
but that doesn't change at all the way the vtable methods are *invoked*
Whiteknight well, it does that now in my branch
pmichaud because IMCC doesn't invoke vtable methods
in particular, IMCC has no control over what arguments are sent to vtable methods -- all it does is say what to do with them when they're received
Whiteknight I think I see your point 20:59
so then it does come down to a problem with the invoke vtable method not passing it's "self" correctly
pmichaud correct
do we have an example of an 'invoke' vtable method written in PIR that works? 21:00
(either with or without :method?)
Whiteknight well, no.
pmichaud well, there ya go. :-)
Whiteknight all current tests are written using the "vtable doesnt have self" rule, so all the tests for it break when we add it because there aren't enough arguments floating around
pmichaud getting IMCC to recognize :self with :vtable is probably a separate issue from getting the invoke vtable method to properly pass self.
...they are? 21:01
whoa
pmichaud checks
Whiteknight Yeah, t/pmc/parrotobject.t has about 3 or 4 tests that die when we enable "self" parsing
t/pmc/namespace.t has one also
pmichaud oh, but that's not "all current tests" 21:02
most of the tests in t/ for :vtable have :method also, which means that they recognize 'self'
ack ':vtable' t
Tene pmichaud: is it that .HLL works fine but isn't used by most HLLs, or is .HLL not fully implemented? 21:03
Whiteknight Most are testing the "init" vtable, all the ones testing the invoke vtable without :method fail
pmichaud Tene: it's that PCT isn't HLL aware yet, and we have to work out the symbol export/import issues
Tene Hmm. Okay. 21:04
pmichaud Whiteknight: I think the first goal should be to get :vtable to be able to pass the present set of tests (that are currently passing) without requiring :method
Tene So now I need to learn about .HLL
pmichaud Tene: in particular, when a language adds .HLL, then all of its symbols appear in a namespace separate from other HLLs 21:05
Whiteknight pmichaud, that's what I'm working on now. But without proper "self" passing, all the tests don't get enough arguments.
pmichaud Whiteknight: right, so it's just a matter of getting imcc to recognize that :vtable should cause self
but those tests that aren't currently passing (such as invoke :vtable) probably won't start passing because of that
Whiteknight I have that done already. IMCC recognizes self in :vtables in my branch
but allowing the keyword isn't the same as making sure a value gets passed for it 21:06
Tene pmichaud: would making PCT be .HLL-aware be a pretty significant redesign of PCT, or just a modification?
21:06 AndyA joined
pmichaud Tene: significant -- I'll explain in a second 21:06
Tene can wait. :)
pmichaud Whiteknight: I think we're in pretty close agreement (more)
I'm saying that having :vtable work without :method for the existing tests that pass is worth committing. 21:07
I'm also saying that getting self to work on those vtable methods where it's not presently working is probably a separate bug/issue
in other words
if I can write
.sub 'foo' :vtable('get_boolean') # note, no :method 21:08
and have the istrue opcode dtrt and that 'foo' has a self symbol locally defined, then that's really what the original ticket was trying to address
Whiteknight ok
I don't like committing things that break tests though!
pmichaud which tests break? 21:09
I guess that's the part I don't quite understand.
moritz pmichaud: how's your rakvar branch going?
dalek r29037 | moritz++ | trunk:
: [rakudo] add S04-statements/repeat.t to spectest_regression
diff: www.parrotvm.org/svn/parrot/revision?rev=29037
Whiteknight t/pmc/parrotobject.t and t/pmc/namespace.t
pmichaud moritz: very well. All of the spectest_regression tests still pass.
Whiteknight: ohhhhhhhhhhhh
i get it, i get it
I can help there I think, just s ec
moritz pmichaud: Woot!
pmichaud moritz: yes, I'm a little taken aback and surprised. I've had to double-check to make sure I'm not accidentally running spectest_regression from trunk :-) 21:10
moritz: once I get .implicit_invocant working I'll merge back to trunk.
moritz pmichaud++ 21:11
pmichaud Whiteknight: for the :vtable test in t/pmc/namespace.t, I will argue that the test itself is incorrect. It should require a string parameter.
Whiteknight yes, I've modified that one in my branch already. It's the ones in t/pmc/parrotobject.t that are eluding me
pmichaud okay, let me look at those. 21:12
...what ticket started this whole mess again? ;_) 21:13
21:13 clunker3__ joined
Whiteknight #47674 21:14
pmichaud okay 21:15
I think allison sent you down a false trail in trying to look at expand_pcc_sub_call 21:16
I could be wrong about that, but that's my guess 21:17
Whiteknight yes, it was a bit of a false trail. It looked enticing, but it just wasn't correct 21:18
21:23 teknomunk joined
pmichaud sorry, got interrupted here 21:36
Whiteknight I think I have it mostly figured out, I can't determine how to push a new argument onto the argument list, however 21:37
pmichaud vtable arguments are fixed
Whiteknight no, I mean the arguments passed to the PIR vtable method 21:38
pmichaud oh, that. yeah, I don't know how that happens either.
anyway, I think we're well beyond the edge of my knowledge now -- hope I didn't throw you onto any more false trails
Whiteknight looking at the seg_args and get_params opcodes, I still can't figure out how
it's okay, I think I'm going to have to send Allison an email about it
pmichaud Tene: (HLL) Parrot has a number of HLL namespaces 21:39
right now PCT and PGE both live in the 'parrot' HLL namespace
(and that's where they're likely to remain)
Tene listens.
pmichaud but things like rakudo and tcl and lolcode and the like should really live in their own namespaces
Tene Right.
pmichaud which means that when we got to look up a symbol like PAST::Op, we have to either (1) know to go look for it in the 'parrot' HLL namespace, because that's where PCT lives, or (2) import the PCT symbols into the current HLL namespace 21:40
s/got/go/
same for PGE and P6object
in fact, with P6object, when we go to create a new class, we want the protoobjects for that new class to be created in the caller's HLL namespace, not in P6object's 21:41
as well as any methods that get created or imported
for the choice between (1) and (2) above, currently I'm thinking the best option will be to import the PCT symbols into the current HLL namespace 21:42
but I'd like to have a way of doing that which doesn't require each HLL to specify all of the symbols that ought to be imported 21:43
bacek morning everyone 21:44
Tene nods.
pmichaud I'm planning to create a branch to get rakudo into its own HLL -- that might actually be a good task for as soon as I get the lexicals worked out 21:45
at the same time we could play with getting other languages into their own HLL as well (and do it in the same branch)
Tene pmichaud: is there currently a way to get the caller's HLL namespace?
pmichaud I suspect via getinterp there may be. It's one of those things I need to look at. 21:48
if you wanted to figure that out it'd be a big help :-)
although it wouldn't surprise me if Tcl already does it :-P
(Tcl being the best example of using .HLL that we have to date)
Tene $P0 = getinterp 21:49
ns = $P0['namespace'; 1]
in tcl
Let's see what's in there.
pmichaud does that get namespace or hll namespace?
we really want/need the hll namespace
_alternatively_ 21:50
we could pass the hllnamespace to p6object
and it would just store it there.
Tene Oh, true.
That might be nice as an option anyway.
pmichaud yes.
but somehow I still think it's useful if p6object is hll aware
Tene Looks like no. 21:55
NotFound Someone has at hand some pir that fails because of gc problem? 21:57
Tene pmichaud: getinterp['namespace'].get_name()[0] ha sit 22:03
s/ha sit/has it/ 22:04
pmichaud Tene++ 22:10
afk for a while # going out for dinner
Tene However, that's the *current* namespace, not of the caller. 22:11
Tene finds of caller
getinterp['namespace';1].get_name()[0] has caller's 22:13
bacek nopaste? 22:14
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
nopaste "bacek" at 202.7.166.165 pasted "infix:xx= implementation for moritz/pmichaud (S03-operators/repeat.t is #pure after this patch)" (22 lines) at nopaste.snit.ch/13461 22:16
bacek afk # $dayjob->accept($self) 22:17
22:21 Ademan joined
moritz that patch leads us to the question: should we implement all those combined infix + asignment operators manually, or should we wait for another big refactor and generated them automatically? 22:21
22:49 silug joined
moritz temporarily retires to his bed 22:49
Tene go home now. 22:51
23:03 slightlyoff joined 23:04 slightlyoff left 23:10 rdice joined 23:24 tetragon joined 23:27 AndyA joined
pmichaud (implement combined ops): I think for ops that we have specific (and likely used) tests for, we can go ahead and generate the manually. But I wouldn't make any special effort to generate them all, as eventually they'll be done automagically. 23:36
23:52 bacek_ joined
japhb pmichaud: Will the automatic generation for op/assign just create "A = A op B"? If so, that's an efficiency problem. Nice as a fallback, but not what I'd want for the standard set .... 23:57

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!