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:03 bacek joined 00:04 Theory joined 00:07 bacek joined 00:09 AndyA joined 00:27 tetragon joined 00:29 magnachef_ joined 00:49 TiMBuS joined
dalek r28836 | chromatic++ | trunk: 01:11
: [GC] Cleared the metadata attached to a PMC_EXT structure when recycling it.
: This prevents stale (and themselves recycled) metadata PMCs from sticking
: around nothing expects them. This fixes at least RT #55782.
diff: www.parrotvm.org/svn/parrot/revision?rev=28836
stupidbot RT 55782: [BUG] for 1..1000 -> $a { say $a } segfaults in rakudo (Gargbage Collector) - open
dalek r28837 | Whiteknight++ | gsoc_pdd09: 01:37
: [gsoc_pdd09] adding changes to ensure we null out the various fields of a PMC_EXT, when we allocate a new one, and when we recycle an old one. We might not need both.
diff: www.parrotvm.org/svn/parrot/revision?rev=28837
r28838 | Whiteknight++ | gsoc_pdd09: 02:09
: [gsoc_pdd09] Fix handling of Sync* members of PMC_EXT. Free them once we free PMC_EXT items, which I don't think was done before. Add some function-level documentation.
diff: www.parrotvm.org/svn/parrot/revision?rev=28838
02:25 apeiron joined 02:29 tetragon joined 02:33 teknomunk joined
dalek r28839 | coke++ | trunk: 03:11
: Update perlcritic.t to use standard Test::Perl::Critic and a standard perlcritic
: configuration file instead of our handrolled (and recently broken by updates
: to Perl Critic) version.
: Resolves RT#56166.
diff: www.parrotvm.org/svn/parrot/revision?rev=28839
stupidbot RT 56166: [BUG] [PATCH] Perl::Critic Version Problems - open
DietCoke closes the one ticket he threatened to this weekend and calls it good. 03:17
msg kid51 I'll review the opnum one tomorrow during my lunch break.
purl Message for kid51 stored.
03:25 acalhoon joined
acalhoon hello 03:25
purl hi, acalhoon.
acalhoon any one here know how to get the perl6 executable to build under openbsd
?
03:26 Ademan joined
acalhoon i'm having trouble building pbc_to_exe 03:26
anyone around 03:27
?
Whiteknight I'm around, but I probably can't help you 03:28
what problem are you having? what revision are you on?
acalhoon i'm at revision 28838 03:29
which i believe is 0.6.3
Whiteknight okay, so exactly up to date (we're at 28839 now) 03:30
what error message are you getting?
acalhoon oh, ok, fair enough
/home/acalhoon/src/parrot/blib/lib/libparrot.a(string_primitives.o)(.text+0x26):src/string_primitives.c:58: undefined reference to `u_isdigit' 03:31
/home/acalhoon/src/parrot/blib/lib/libparrot.a(string_primitives.o)(.text+0x36):src/string_primitives.c:58: undefined reference to `u_charDigitValue'
/home/acalhoon/src/parrot/blib/lib/libparrot.a(string_primitives.o)(.text+0x75a): In function `Parrot_char_digit_value':
src/string_primitives.c:313: undefined reference to `u_charDigitValue'
/home/acalhoon/src/parrot/blib/lib/libparrot.a(unicode.o)(.text+0x1da): In function `compose':
src/charset/unicode.c:274: undefined reference to `unorm_normalize'
/home/acalhoon/src/parrot/blib/lib/libparrot.a(unicode.o)(.text+0x252):src/charset/unicode.c:284: undefined reference to `unorm_normalize'
...
it's during the build of pbc_to_exe
Whiteknight I dont think I can help you, but you should open a ticket
acalhoon somehow I managed to have a version of pbc_to_exe in my local binaries, but faking it out doesn't seem to help 03:32
should I revert back to a released version to see if I have the problem there?
Whiteknight Send an email to parrotbug@parrotcode.org with your system information, the revision number, and the error you have
you can try to revert, yes. But definitely send the bug email in so we know there is a problem with the current revision 03:33
acalhoon assuming I don't have the problem on the released revision
?
Whiteknight that will be nice information to know. Either way, we need to fix it 03:34
acalhoon do you know the rev number for the last release? or is switching to tags/RELEASE_*** the preferred method?
Whiteknight I don't know the revision number of it, no. Switching to the tag should probably work. 03:35
acalhoon sent 03:51
Whiteknight awesome, thanks
Infinoid acalhoon: wait... you have a pbc_to_exe on your path? maybe an older installed version of Parrot is confusing the newly built one 03:52
acalhoon i do
I have a local pbc_to_exe
too late btw :)
so, you suggest pulling the pbc_to_exe out of my path? 03:53
Infinoid I suggest uninstalling all the files from the older version of parrot, if possible
I don't think the executables will get in the way, but I'm afraid the libraries will.
acalhoon hmmm 03:54
is there a make uninstall equivalent?
Infinoid I doubt it. the install process is not very well-supported at the moment 03:55
acalhoon drat
:)
Infinoid which platform are you on? 03:56
using gcc?
acalhoon openbsd
yes
no such luck 03:57
I realize I installed a port of parrot-0.5.0 a while back
Infinoid does a quick build to see how many libs and stuff are generated
acalhoon I just "uninstalled" that and "removed" it 03:58
still no luck
I'll try from scratch
Infinoid have you already submitted a bug, with a build log or somesuch? if not, can you post one via nopaste.snit.ch? 03:59
acalhoon I just submitted the build log
as part of my bug report
Infinoid ok. I just checked RT, looks like it hasn't come through quite yet
acalhoon if my build from clean fails, I'll post the results to nopaste 04:00
Infinoid thanks!
acalhoon sure thing
drat 04:01
nopaste "acalhoon" at 74.131.25.177 pasted "make./ perl6 Build Failure" (54 lines) at nopaste.snit.ch/13426 04:02
acalhoon I pasted the "relevant" part
hope that helps :) 04:04
Infinoid looking now
what happens if you configure --without-icu ?
acalhoon haven't tried 04:05
Infinoid the missing functions are from ICU support. I think maybe we need to link against an additional library to get those on openbsd
acalhoon I see
perl Makefile.PL --without-icu ? 04:06
Infinoid Configure.pl is the main script, Makefile.PL is a wrapper and I don't know if it mangles its arguments. 04:07
acalhoon by the looks of it, it does
Infinoid so, "perl Configure.pl --without-icu" please 04:08
acalhoon in progress
acalhoon hesitates to say that it "looks better" 04:10
"Hello, world"
hooray!
Infinoid great!
... any idea which library u_isdigit() is part of, on openbsd? 04:11
is there a manpage?
acalhoon no manpage
at least not for me
this is a relatively new install of openbsd
to be honest, I can't really even suggest where to look :P 04:14
Infinoid here on linux there are libicui18n and libicuuc shared libraries, but I'm not sure how the whole ICU thing works.
I don't see either of those on pbc_to_exe's linker command line, either. 04:15
acalhoon ha
go figure
aha 04:16
hang on a minute
nopaste "acalhoon" at 74.131.25.177 pasted "OpenBSD ICU libs; under /usr/local/lib/icu" (264 lines) at nopaste.snit.ch/13427 04:19
acalhoon sorta verbose of me :)
but it mentions something to the effect of: 04:20
### To link your application with ICU:
# 1. use LDFLAGS, CFLAGS, etc from above
# 2. link with $(ICULIBS)
# 3. optionally, add one or more of:
# - $(ICULIBS_I18N) - i18n library, formatting, etc.
Infinoid do you have an icu-config command? 04:21
acalhoon yup 04:22
Infinoid is it in your PATH?
acalhoon yes
Infinoid hmm. Configure.pl's --help says its supposed to use that automatically, then 04:23
% icu-config --ldflags
-lpthread -lm -L/usr/lib64 -licui18n -licuuc -licudata -lpthread -lm
on my machine, libparrot.so is linked with those libraries, and pbc_to_exe is linked against libparrot, so everything works.
acalhoon interesting 04:24
04:24 Ademan joined 04:28 apeiron joined
acalhoon should i try with --icu-config="path" 04:28
?
scratch that, I AM trying that 04:29
Infinoid it's worth a try, if the version in your PATH is yielding the wrong data and you have another one to try
if it still doesn't work, can you cutpaste the failed gcc command line (for linking pbc_to_exe), add `icu-config --ldflags` (with backticks) to that command line, and see if it goes through? 04:31
acalhoon sure
(it just failed by the way) 04:32
yup
that seems to have worked
Infinoid \\o/
acalhoon ha 04:33
genius.
Infinoid so, for openbsd, the ICU libraries need to be added to the executable command lines, not just the libparrot line.
acalhoon apparently
Infinoid now ...
Infinoid scratches his head trying to figure out how to do that
acalhoon tell everyone to copy paste :)
well, tacking it on the the link portion of tools/dev/pcb_to_exe.pl works (basically the same as copy paste) 04:39
pbc_to_exe_gen.pl *** 04:40
looks like it stuffs the results into icushared 04:44
of icu-config that is
Infinoid yeah, I've got a patch to do basically the same thing, but to pull the cached icushared string from parrot's config 04:47
acalhoon icu-config found... good!
icuconfig: icu-config
icushared='-lpthread -lm -L/usr/local/lib -licuuc -licudata -lpthread -lm'
headers='/usr/local/include'
Setting Configuration Data:
nopaste "Infinoid" at 75.37.106.69 pasted "ICU patch for openbsd" (30 lines) at nopaste.snit.ch/13428
acalhoon icu_dir => '/usr/local', 04:48
);
ha
excellent, i'll try it out
your's still builds correctly I assume :) 04:50
Infinoid yep! 04:51
and its in a non-windows clause, so I shouldn't have to worry about that whole can of worms
acalhoon has not passed the moment of truth yet
looks promising! 04:52
Infinoid oh, the suspense. :P
acalhoon wait for it...wait for it.....
Hello, world. 04:53
purl rm -fr /
acalhoon YAY!
that's the ticket alright
I wonder how many more of those are missing for OpenBSD
:P
Infinoid so you're confirming that it works? 04:54
acalhoon I did indeed
like magic
Infinoid great. any other issues come up, or does "make" build to completion?
acalhoon I have a working perl6 executable 04:55
:)
[acalhoon]:~/src/parrot% ./perl6
> say "bawk bawk bawk"
bawk bawk bawk
dalek r28840 | infinoid++ | trunk:
: [pbc_to_exe]
: * OpenBSD needs ICU libs passed directly on the linker line for executables;
: linking libparrot against them isn't sufficient. Fix pbc_to_exe to do this
: when it links.
: * acalhoon++ for reporting and testing.
diff: www.parrotvm.org/svn/parrot/revision?rev=28840
acalhoon yippie 04:56
I've in some small way contributed to perl6 and open source
hah
thanks Infinoid
Infinoid karma acalhoon
purl acalhoon has karma of 1
Infinoid you are well on your way to becoming a parrot hero :) 04:57
thanks for the report!
acalhoon haha
Infinoid guess I get to kill the RT ticket when it shows up.
acalhoon karma Infinoid
purl infinoid has karma of 180
acalhoon wow
I've got a long way to go
:)
Infinoid me too.
karma pmichaud
purl pmichaud has karma of 1453
acalhoon yipes!
well thanks again. I'm off to bed. 04:58
Infinoid goodnight
04:58 acalhoon left
pmichaud karma leo 04:59
purl leo has karma of 1883
spinclad karma dan 05:00
purl dan has karma of 230
pmichaud karma particle
purl particle has karma of 1360
bacek knows the trick 05:01
karma c
purl c has karma of 7003
bacek karma bacek 05:02
purl bacek has karma of 45
bacek karma moritz
purl moritz has karma of 58
bacek bah... He've got commit bit...
jjuran karma jjuran 05:06
purl jjuran has neutral karma
Whiteknight karma Whiteknight 05:11
purl whiteknight has karma of 130
Whiteknight awesome, tripple digits 05:12
Infinoid opbots, trust Whiteknight 05:13
slavorg Ok
bacek pmichaud: I need more karma :) What about RT#56214? 05:15
stupidbot RT 56214: [PATCH] Implementation of Str.index. - new
dalek r28841 | pmichaud++ | trunk:
: [rakudo]:
: * spectest-progress update: 74 files, 1126 passing tests (0 failing tests)
diff: www.parrotvm.org/svn/parrot/revision?rev=28841
pmichaud bacek: (RT56214) * parameters should probably be named "substr" and "pos" instead of "x" and "start" (to match definition in S29) 05:18
bacek pmichaud: ok. 05:19
pmichaud * I'm guessing this belongs in Any instead of Str, so that 1000.index(...) will work
it doesn't seem to verify that a start parameter has been provided
(i.e., we aren't certain that start gets initialized)
I'm not sure what the purpose of "unless $I0 check length" is. 05:20
er, "unless $I0 goto check_length" 05:21
Infinoid slavorg has not been very reliable by itself, so I'm giving it a friend for better redundancy. If anyone objects, feel free to /kick
05:21 slavorgn joined
pmichaud I think that we should be able to do this with a single 'index' method 05:22
(that is then placed in global via !EXPORT)
bacek purpose of 'unless $I0' in spectest. 5 tests under # Empty strings 05:23
pmichaud doesn't Parrots <index> opcode already handle empty strings?
bacek I learned about '!EXPORT' after creating this patch :)
(index). Seems no. I've added this check after trying spectest. 05:24
parrot throws exception (and I think that it is good approach from parrot's POV) 05:25
pmichaud interesting, you're correct about the index op not handling "". I'm a bit surprised. 05:26
probably need a comment in the code about that. 05:27
bacek why? It's not-VM-problem. Enforcing particular semantic for language in this case is bad...
pmichaud except that the common semantic is that a null string matches immediately
bacek wow... 05:28
Submit a bug in parrot about inconsistency?
pmichaud no, I just mean in most languages. In C, index("hello world", "") returns 0 05:29
in Perl, index("hello world", "") returns 0
in PHP, strpos("hello world", "") returns 0 05:30
bacek hmm... 05:31
pmichaud none of them decide to return -1 or an indication of any sort of error
i.e., all of them consider the empty string to be found at any position in a target string. So, Parrot is the odd-environment-out by choosing to have "" always come back as "not found"
bacek ..and other languages can check empty strings for themself.
Definetely looks-like-a-bug 05:32
pmichaud well, it would be a bug except there's actually a test for it in in t/op/string.t . So it was apparently a deliberate design decision at some point.
If the string is null, or the substring is not found or is null, 05:33
B<index> returns "-1".
(from parrot docs). TO me that's a bizarre interpretation of index.
oh well.
bacek pasm_output_is( <<'CODE', '0', '0 length substr' ); 05:34
set I4, 0
set S4, "JAPH"
substr S3, S4, 1, 0
length I4, S3
print I4
end
CODE
null sring is not empty string...
pmichaud well, parrot's index opcode is definitely returning -1 if the substring is empty string 05:35
bacek this is from t/op/string.t. AFAIU this is expecting exception.
pmichaud $ cat x.pir
.sub 'main' :main $S0 = "Hello world" $I0 = index $S0, "", 0 say $I0
.end
$ ./parrot x.pir
-1
purl -1
pmichaud $
bacek yak... 05:36
it kind of weird...
pmichaud that's just really odd. anyway, I guess we're likely stuck with it for now.
but I'm wondering who thought it up in the first place.
anyway, test for empty string is better done as unless x goto ... instead of $I0 = length x; unless $I0 goto ... 05:37
bacek (side question) should we separate empty string and undef? 05:38
e.g. "foo".index(undef)
pmichaud well, undef should throw an exception if used 05:39
bacek 'use fatal' nad invoke 'fail()'? 05:40
pmichaud i.e., "foo".index("") should succeed, while "foo".index(undef) will likely throw an exception.
bacek s/nad/and/
pmichaud also, it looks to me like some of the tests in S29-str/index.t are wrong.
for example:
is(index("Hello World", "x"), -1, "One char, no match");
bacek why? 05:41
pmichaud from S29: If the substring is not found, a bare
C<StrPos> containing no position is returned. This prototype C<StrPos>
evaluates to false because it's really a kind of undef. Do not evaluate
as a number, because instead of returning -1 it will return 0 and issue
a warning.
bacek got it.
pmichaud anyway, bedtime here. 05:42
be back in a few hrs 05:43
bacek probably returning Failure/Undef better then Int
pmichaud: g'night
pmichaud well, it should really return StrPos
Failure is probably better for the time being, yes.
later
05:44 Ademan joined
bacek thinks that StrPos is actually (Int|Failure)... 05:44
05:57 Psyche^ joined
dalek r28842 | coke++ | trunk: 06:13
: sane-ifying macro usage slightly.
diff: www.parrotvm.org/svn/parrot/revision?rev=28842
r28843 | coke++ | trunk: 06:35
: Don't blindly add -w to every process we run. We're trying to add a parrot
: warning level that we don't want enabled all the time, so having this
: turned on just to use the harness is too verbose.
: Any perl we're invoking should already have 'use warnings' in the source
: anyway.
diff: www.parrotvm.org/svn/parrot/revision?rev=28843
r28844 | coke++ | trunk: 06:40
: Add a new warnings setting to parrot to squawk about deprecated items.
: Add a :deprecated flag to the op2c compiler which respects the warnings setting
: and issues a warning about any ops so tagged
: Add a note to DEPRECATED.pod about this.
: This resolves RT#41606.
diff: www.parrotvm.org/svn/parrot/revision?rev=28844
stupidbot RT 41606: [TODO] Add flag to do runtime check on deprecated ops - open
dalek r28845 | coke++ | trunk: 06:44
: You would think I'd notice these awkward sentences when doing the preliminary svn diff.
: Nope, need to see them in the email, apparently.
diff: www.parrotvm.org/svn/parrot/revision?rev=28845
06:45 iblechbot joined 06:49 Ademan joined
cotto_home rt#55782 07:07
stupidbot RT 55782: [BUG] for 1..1000 -> $a { say $a } segfaults in rakudo (Gargbage Collector) - resolved
07:10 Ademan joined 07:31 Ademan joined
dalek r28846 | fperrad++ | libs4php: 07:42
: [php] test ltrim with trailing space
diff: www.parrotvm.org/svn/parrot/revision?rev=28846
r28847 | fperrad++ | libs4php: 07:43
: [php] add acosh & friends
diff: www.parrotvm.org/svn/parrot/revision?rev=28847
08:20 cosimo joined 09:31 Whiteknight joined 09:33 barney joined 09:55 masak joined
dalek r28848 | bernhard++ | trunk: 10:06
: [Plumhead]
: svn merge -r 28822:28847 svn.perl.org/parrot/branches/libs4...s/plumhead
diff: www.parrotvm.org/svn/parrot/revision?rev=28848
10:22 bacek joined 10:47 tetragon joined 11:02 Whiteknight joined
dalek r28849 | bernhard++ | trunk: 11:09
: [Plumhead]
: Some whitespace changes, in order to keep diffs with 'libs4php' small.
diff: www.parrotvm.org/svn/parrot/revision?rev=28849
bernhard.schmalhofer@gmx.de | plumhead_renaming: 11:21
link: www.perlfoundation.org/parrot/index...d_renaming
11:21 clunker3 joined
dalek bernhard.schmalhofer@gmx.de | Plumhead: 11:30
link: www.perlfoundation.org/parrot/index.cgi?plumhead
11:43 ruoso joined 12:02 jq joined
dalek r28850 | bernhard++ | libs4php: 12:04
: [Plumhead]
: Update the src/pct in the libs4php branch with recent changes in 'trunk'.
diff: www.parrotvm.org/svn/parrot/revision?rev=28850 12:05
r28851 | bernhard++ | libs4php: 12:29
: [Plumhead]
: Merge some more changes from 'trunk' to 'libs4php'.
diff: www.parrotvm.org/svn/parrot/revision?rev=28851
r28852 | bernhard++ | trunk: 12:31
: [Plumhead]
: clean-pmc is covered with clean-common
diff: www.parrotvm.org/svn/parrot/revision?rev=28852
12:40 kj joined
Infinoid is RT acting funny for anyone else? logging you out within 5 minutes, failing to load its css properly, stuff like that? 12:42
pmichaud so far it's working okay for me -- I hadn't noticed anything yet. (But just now fired up RT) 12:43
barney Got an Internal Server Error, when trying to enter RT 12:44
Now, RT looks fine 12:46
Infinoid ok. I recently upgraded to firefox3, I'm wondering whether that's what caused these issues. 12:48
pmichaud I'm running firefox3 and haven't noticed anything 12:49
(fwiw)
dalek r28853 | Whiteknight++ | trunk:
: [docs] Improved function-level documentation for src/cpu_dep.c
diff: www.parrotvm.org/svn/parrot/revision?rev=28853
12:50 Whiteknight joined
barney runs FF3 as well 12:53
Infinoid ok, I'll keep searching then. thanks guys 12:55
dalek r28854 | bernhard++ | trunk: 12:58
: [Plumhead]
: Set up the missing superglobals as empty PhpArrays.
diff: www.parrotvm.org/svn/parrot/revision?rev=28854 12:59
12:59 UltraDM joined 13:04 gryphon joined
particle1 pmichaud: i'm still far off in scrollbackland, but your last post to p6l has a footnote marker with no footnote 13:22
dalek r28855 | bernhard++ | libs4php:
: [Plumhead]
: Merge some more changes from trunk into lib24php.
diff: www.parrotvm.org/svn/parrot/revision?rev=28855
pmichaud particle1: oops, thanks.
13:23 iblechbot joined 13:24 ruoso joined
dalek r28856 | pmichaud++ | trunk: 13:28
: [rakudo]:
: * Add stringification and numification to Range objects.
diff: www.parrotvm.org/svn/parrot/revision?rev=28856
pmichaud particle++ 13:29
dalek r28857 | Whiteknight++ | trunk: 13:41
: [docs] Improved file-level documentation for src/cpu_dep.c. Added several comments to explain some of the tricker or more esoteric features of that file. Removed outdated file references.
diff: www.parrotvm.org/svn/parrot/revision?rev=28857
13:42 rdice joined
dalek r28858 | moritz++ | trunk: 13:47
: [rakudo] add S03-operators/range.t to spectest_regression
diff: www.parrotvm.org/svn/parrot/revision?rev=28858
moritz I just had to interrupt the client during my last commit, hope it didn't do any harm 13:50
dalek r28859 | Whiteknight++ | gsoc_pdd09: 13:51
: [gsoc_pdd09] Update to trunk r28857
diff: www.parrotvm.org/svn/parrot/revision?rev=28859
14:05 paco joined 14:10 Andy joined
DietCoke pmichaud: 56464 sounds REALLY familiar. :| 14:11
dalek r28860 | Whiteknight++ | trunk: 14:14
: [misc] a few small changes, mostly additions made by headerizer
diff: www.parrotvm.org/svn/parrot/revision?rev=28860
DietCoke didn't I just track down a MMD-based problem like this?
pmichaud likely. I suspect there are a lot of these sorts of things floating (argh!) about :-) 14:15
DietCoke RT#54474
stupidbot RT 54474: [BUG] cmp doesn't works for integers - resolved
DietCoke guessing that float.pmc has a similar MMD_DEFAULT that needs updating.
yup. 14:16
it's using num_val(SELF) instead of VTABLE_get_xxxx(INTERP,SELF)
pmichaud I thought about investigating it but we've got visitors at the house so my ability to do in-depth tracking this morning is limited
so I figured I'd just file the ticket and let someone else search :-) 14:17
DietCoke Should be an easy fix, but someone should really go through all the PMCs so we don't have to keep doing this dance.
I'll see if I can fix this particular case right now.
14:21 davidfetter joined
pmichaud there was a ticket for "go through all the PMCs" but I closed it because nobody was doing it. Having specific errors seems to get action, though :-) 14:21
one odd thing about the MyFloat case is that it gets the tests exactly backwards. coincidence? 14:22
DietCoke yes. 14:23
it's using PMC_num_val() to try to extract something from a PMC structure that just doesn't exist in the object. 14:24
it should be using VTABLE_get_number to use the api.
god knows what it's pulling out by poking in the guts that aren't the guts it thinks.
pmichaud "These aren't the guts you're looking for. Move along."
DietCoke hurm. my simple fix is showing them reversed as well. bother. =-) 14:32
dalek r28861 | bernhard++ | trunk: 14:33
: [Plumhead PCT]
: Start with supporting '<script>' tags.
diff: www.parrotvm.org/svn/parrot/revision?rev=28861
DietCoke hurm. 14:39
nopaste "coke" at 72.228.52.192 pasted "this looks sane, neh?" (20 lines) at nopaste.snit.ch/13431 14:40
DietCoke someone double check that? (fails in current parrot.)
(missing a trailing OUTPUT)
14:44 jhorwitz joined
DietCoke there we going. doing a full make test run... 14:45
dalek bernhard.schmalhofer@gmx.de | Plumhead: 14:48
link: www.perlfoundation.org/parrot/index.cgi?plumhead
bernhard.schmalhofer@gmx.de | Plumhead: 14:52
link: www.perlfoundation.org/parrot/index.cgi?plumhead
tewk_ so should PMC_num_val not be used at all?
dalek r28862 | coke++ | trunk: 14:53
: Fix RT #56464 - cmp doesn't work on Float subclasses.
: Float was assuming that only PMCs would subclass it. Fixup to use the vtable
stupidbot RT 56464: [BUG] comparison opcodes don't work on subclasses of Float - open
dalek : to get at the float values in most cases. Add a test.
diff: www.parrotvm.org/svn/parrot/revision?rev=28862
tewk_ grep says other places are using it.
Andy PANTS CHECK 14:59
DietCoke it should be used less than it is, certainly. (note that there's a few cases of it left in float.pmc) 15:00
chromatic said in the first bug (for integer) that it must die.
I can only assume the initial thought was it would be faster than the vtable.
but I think we should err on "correct" first, and speedup later if needed.
dalek r28863 | Whiteknight++ | trunk: 15:01
Whiteknight if I had a dollar for every time I should have done that...
dalek : [core] merged src/stacks.c and src/stack_common.c into src/stacks.c.
: * Deleted src/stack_common.c from repo, removed from MANIFEST
: * merged function register_new_stack into new_stack. Deleted former.
: * Simplified Stack_Chunk_t structure definition to remove unneeded nonsense
: * Cache Stack_Chunk_t pool pointer instead of structure size. Saves on pool lookups.
diff: www.parrotvm.org/svn/parrot/revision?rev=28863
DietCoke ooh, nice. Whiteknight++ 15:02
pmichaud yes, _very_ nice.
Whiteknight more changes could be made, I was being conservative
pmichaud hands Whiteknight a dollar. :-) 15:03
Whiteknight I've been having a lot of problems with SVN this morning. The server isn't sending out confirmations for me 15:04
so things hang, then I need svn cleanup, svn update, etc
pmichaud I had that also.
moritz can't even access that server at all, routing troubles 15:06
pmichaud make realclean + build gives me 15:07
ar: src/stack_common.o: No such file or directory
make: *** [blib/lib/libparrot.a] Error 1
pmichaud@orange:~/parrot/trunk$
Whiteknight (svn.perl.org)--
dalek bernhard.schmalhofer@gmx.de | Plumhead:
link: www.perlfoundation.org/parrot/index.cgi?plumhead
Whiteknight oh crap, that needs to come out of the makefile
Whiteknight is fixing now... 15:10
Infinoid wants svn checkout -j 15:11
Whiteknight wants svn dwim 15:17
rjbs wants dwim sum 15:18
dalek r28864 | Whiteknight++ | trunk:
: [Makefile] removed src/stack_common.* from makefile
diff: www.parrotvm.org/svn/parrot/revision?rev=28864
r28865 | infinoid++ | trunk: 15:19
: [pod] Remove a couple of documentation references to src/stack_common.c.
diff: www.parrotvm.org/svn/parrot/revision?rev=28865
Infinoid one reference to stack_common remains in lib/Parrot/Docs/Section/C.pm, but I'm not sure how to remove it. 15:20
Whiteknight yeah, i'm looking at that right now too
moritz rm helps ;-) (/me ducks)
Infinoid moritz: that's a great way to fix failing spectests too! 15:21
moritz Infinoid: an even faster way is 'echo > languages/perl6/t/spectest_regression.data' 15:22
pmichaud actually, I think that'll end up running *all* of the spectests :-)
moritz if it does, it's a bug in t/harness 15:23
because of the --tests-from-file option
it did that in earlier versions of t/harness 15:24
actually 'make spectest_regression' with empty t/spectest_regression.data seems to run t/01-sanity/ and t/02-test-pm 15:29
particle1 seems the test harness needs tests
pmichaud possibly fudge returns an empty list of files 15:30
which harness then treats as being "run all tests in t/"
(or at least treats as meaning "run the default tests")
moritz particle1: I thinkk that tests for fudge are much more important atm 15:31
DietCoke pmichaud: fixed your float bug. more bugs no doubt lurking.
pmichaud DietCoke: yes, it's definitely fixed, and thanks. 15:32
moritz btw t/spec/S03-operators/context.....................dubious (when in spectest_regression)
pmichaud rakudo now passes about 44 more spectests (one I correct range.t)
moritz when I run it with ../../parrot perl6.pbc t/spec/S03-operators/context.rakudo I don't get any failure 15:33
dalek r28866 | Whiteknight++ | trunk:
: [lib] remove mention of stack_common from lib/Parrot/Docs/Section/C.pm. Somebody who knows this module better can double-check me.
diff: www.parrotvm.org/svn/parrot/revision?rev=28866
pmichaud s/one/once/ 15:34
particle1 moritz: check the exit code
moritz is that $? in the shell?
return value is 0 15:35
15:47 Ademan joined 15:50 jjore joined
dalek r28867 | coke++ | trunk: 15:50
: Resolve RT# 56470;
: Tell perlcritic not to warn about uninstalled modules.
stupidbot RT 56470: [CAGE] new perlcritic test gives verbose "not installed" diagnostics. - open
dalek diff: www.parrotvm.org/svn/parrot/revision?rev=28867
16:09 Theory joined 16:16 cjfields joined
DietCoke Anyone with some lex-fu about? 16:17
Whiteknight aye
DietCoke you have GSOC work to do. =-)
Whiteknight how much work do you need?
DietCoke ;but if you're bored, RT#47674 seems pretty straightforward. 16:18
stupidbot RT 47674: [TODO] :vtable pragma should enable 'self' - open
pmichaud doesn't that just mean that :vtable implies :method ?
DietCoke I think we need to make :vtable set a new flag, P_VTABLE, just like :method sets P_METHOD. Then we can change a conditional that keys off P_METHOD to key off P_METHOD|P_VTABLE
I think.
Whiteknight I'll take a look at it. I jump from project to project to keep from getting bored :) 16:19
pmichaud or, perhaps more precisely, :vtable implies the P_METHOD flag ?
DietCoke very good.
pmichaud: that may bring along extra baggage we don't want.
we -just- want 'self'.
pmichaud what other baggage is there with :method ? 16:20
DietCoke I don't know, and would rather not have to dig through the code to find out. =-)
pmichaud every use of :vtable that I have now also has :method on it
japhb DietCoke: won't you have to be code spelunking to find all places where P_METHOD may need to be changed to P_METHOD|P_VTABLE anyway?
DietCoke japhb: I don't want it changed -everywhere-, I just want 'self' 16:21
(and I already know where that one is.)
japhb ah
pmichaud the only think I can think of that might change this is that find_method should not come across things that are marked :vtable but not :method
DietCoke pmichaud: that's no doubt a workaround because you can't have self.
but then you're exposing those as methods, which is not (in general) the RTDT. 16:22
pmichaud agreed. We also have the problem that methods are being exposed as subs, which is also not the RTDT.
DietCoke one thing at a time. =-)
japhb DietCoke: this feels like something where a meaningful macro applies: #define P_NEEDS_SELF (P_METHOD|P_VTABLE)
or somesuch 16:23
purl rumour has it somesuch is a little vague I think... but it does have a ring to it
DietCoke so if we use P_METHOD, that would also have a hook into the PCC, which just don't apply to vtables.
purl, forget somesuch
purl DietCoke: I forgot somesuch
pmichaud well, they can apply to vtables if the sub also specifies :method :-)
DietCoke ... in which case they already have P_METHOD, neh?
;you can't fool me, it's turtles all the way down.
pmichaud yes. :-)
ugh, I cfind it really annoying that RT constantly logs me out. 16:24
(the fact that methods are exposed is subs is RT#53302, fwiw. Might want to link it with RT#47674.) 16:25
stupidbot RT 53302: [RFE] controlling :method entries in namespace - open
16:25 sjansen joined
pmichaud s/is subs/as subs/ 16:25
DietCoke Whiteknight: feel free to steal the ticket from me. 16:27
pmichaud afk, lunch. 16:28
Whiteknight Okay, I'll do that probably 16:32
dalek r28868 | bernhard++ | trunk: 16:33
: [Plumhead PCT]
: Start with support for comments.
diff: www.parrotvm.org/svn/parrot/revision?rev=28868
Whiteknight DietCoke, could you send me a PIR example test file for the behavior you want? 16:37
I think I figured out the solution, I need to test it
At least, I think I figured out how to add it in the parser, I dont know what the behavior will be 16:39
dalek bernhard.schmalhofer@gmx.de | Plumhead:
link: www.perlfoundation.org/parrot/index.cgi?plumhead
DietCoke Whiteknight: it's in the ticket. 16:44
(not as a formal .t file, but as a .pir example)
16:44 particle left
DietCoke if you add ":method" to the ":vtable" it generates the right output in svn-latest (but also exposes it as a method, which is wrong.) 16:44
Whiteknight okay, I'll use that and play with it. I'm worried that without being a method, the "self" won't be referring to anything 16:46
are vtable functions being called as pmc.vtable()?
pmichaud "self" generally refers to the first argument. 16:47
(in :method). I suspect the same would be true for :vtable
DietCoke ooh, yah. hadn't thought of that. :| 16:48
Whiteknight okay, I'll doublecheck that
DietCoke pmichaud: mebbe not. one is C conventions, one is PCC.
Whiteknight well, I'm compiling it now. Cross your fingers 16:53
DietCoke "Good luck, we're all counting on you." 16:54
Whiteknight haha, nice
spinclad RTDT? 16:57
RTTD?
purl RTTD is the right thing to do.
Whiteknight hmmm build didn't call flex at all. 16:58
R2D2? 16:59
purl hmmm... R2D2 is RMS..
moritz lol 17:00
Whiteknight purl doesn't think very highly of stallman it seems
purl Whiteknight: i'm not following you...
17:00 apeiron_ joined
moritz RMS? 17:01
purl RMS is Raving, Mad and Silly. or root mean square or Richard M. Stallman, GNU guru or self-defeating. or taking a cue from Microsoft "embrace, extend, etc." :-) (GNU/Linux anyone?) or see rms song or rms remix or xrl.us/bfdja / / or a freak (see www.stallman.org/saintignucius.jpg) or not a killer yet. or repetitive mistake syndrome or xrl.us/bfdi8
moritz that's quite a collection ;)
particle Whiteknight: you need perl Configure.pl --maintainer to call flex 17:02
Whiteknight Yeah, I did that
tewk_ Whiteknight: you have to configure with --maintainer or something to get lex and flex to run 17:05
Whiteknight yeah, it's working now 17:06
for some reason, it didn't call the first time through
DietCoke, I've got it working, sort of. I'll post a status update to the ticket 17:08
DietCoke woot. 17:13
Whiteknight in short, the "self" keyword works in :vtable functions now 17:18
DietCoke ... is there a long? =-) 17:19
Whiteknight however, you can't invoke class methods using it
DietCoke class methods don't work like they used to anyway.
DietCoke takes a look at his email.
Whiteknight Well, There's a patch there, we can submit it if you think the shortcomings aren't too bad 17:20
DietCoke where is the patch?
purl We don't need no stinking patch!
Whiteknight I did attach it, vtable_has_self.patch
DietCoke ah, just hasn't hit the list yet. 17:21
ah, so we were already tracking if it were a vtable. 17:22
ah. so it's parsing, but not as the right thing. =-)
Whiteknight It does everything right except the method invocation
DietCoke right. so you're parsing it now, but it's not resolving to the right thing. 17:23
Whiteknight sortof, yes
DietCoke ... if you comment out the #self.bar() it should work, as that works today. =-)
Whiteknight yes, exactly 17:24
DietCoke looks at the patch.
Whiteknight: woot. 17:29
;add the same conditional to the "self" conditional in compilers/imcc/pcc.c
Whiteknight You think that will do it?
DietCoke I just tried that locally and the test passes.
Whiteknight oh, fantastic. good eye.
DietCoke++
DietCoke Coke: stabbing things in the dark since 2001 17:30
;I have no idea if it breaks anything -else-, mind you. =-)
Whiteknight I'll run through the test suite here
DietCoke danke.
thanks for doing all the hard work. =-)
(about line 313) 17:31
Whiteknight yeah, I'm adding it now
DietCoke looks like that's the place where it actually populates the register, so that makes sense.
Whiteknight IMCC is such a mess. how did it ever get this way? 17:32
DietCoke it was written for one of the languages, and then parrot ate it.
Whiteknight you're right, works like a charm 17:33
DietCoke yay
Whiteknight testing now, so with my computer I should know if there is a problem in about....1 week
DietCoke heh 17:34
once you've finished your gsoc project, you can fixup PIRC. =-)
Whiteknight Yeah, I'll just push that project into the ever-expanding queue 17:35
particle keep in mind, Whiteknight, around here we reward enthusiasm with responsibility 17:36
tewk_ Whiteknight: can I tell parrot to use a larger inital heap before running GC.
Whiteknight what do you mean? you can use larger arenas 17:37
tewk_ Yeah I want to start out with large arenas.
I know I'm going to allocate a long of objects and hang on to them for a long time. 17:38
s/long/lot
DietCoke seems like we should support an CL option for parrot for that. 17:39
Whiteknight I know there's a macro somewhere, I just have to find it
DietCoke (hurm. Java's has a high-end limit. We should steal that.)
tewk_ What is the metric for growing arenas, and by how much do they grow? 17:40
DietCoke belatedly kicks off a make test for Whiteknight with his handrolled version of the patch 17:41
Whiteknight The metric for growing the arena is in src/gc/smallobject.c:84 UNITS_PER_ALLOC_GROWTH_FACTOR
tewk_ thanks for the pointer I'll go look, 17:43
Whiteknight Okay, the initial allocation numbers are defined in src/headers.c, starting on line 68 17:46
PMC_HEADERS_PER_ALLOC, BUFFER_HEADERS_PER_ALLOC, etc
When my branch gets merged in, a lot of this stuff is going to be much more organized 17:47
...or much less :)
DietCoke, we appear to have failures in t/pmc/namespace and t/pmc/parrotobject 17:49
DietCoke I also have failurres in codingstd!
;=-)
tewk_ Whiteknight: So do arenas grow linearly or do they ~"double" in size when they grow? 17:50
Whiteknight the factor currently is 1.75, so new_size = old_size * 1.75
DietCoke Whiteknight: seems to be related to vtables with declared arguments. 17:52
tewk_ That was what I was thinking, so not quite double
DietCoke Oh. it may be that the tests are wrong for ignoring self.
Whiteknight DietCoke, is that because we're "stealing" the first arguments as "self"?
DietCoke that is, they probably should have been complaining about 2 args (not 1) this whole time.
i wonder if there is code for methods to pull off one arg on the complaint of bad args. 17:53
(if so, then we need to hook our conditional in there too.)
17:54 Theory joined
Whiteknight for PMC invokes, it's not passing the PMC itself as the first parameter to the :vtable method 17:58
the failing test in t/pmc/namespace doesn't look right to me in the first place 18:06
the second argument, 'foo' should be passed as a parameter to the vtable method, and it hasn't been
Adding in ".param string name" solves the problem, and behaves as I expect it should 18:08
18:08 davidfetter joined
DietCoke tewk_: any response to the gentle ribbing about checking in your code? =-) 18:20
tewk_ what ribbing, my chat with particle? 18:23
DietCoke yaya
tewk_ I'm actually cleaning out the cruft right, now, I'll delete the nci branch sometime today, and create a new one with code it it. 18:24
DietCoke Just saw something go by on the mentors list about someone who hadn't appeared to even check out the repository, let alone check anything in. Just figured it was a belt and suspenders thing to checkin work in progress with the midterms coming up.
perfecto.
keep up the good work. =-)
Whiteknight I can't even imagine going this far without checking anything in 18:25
I'm so paranoid about losing work to a faulty HD
tewk_ tewk.com/nci.diff is always a current snapshot of my work that should apply cleanly against HEAD
DietCoke Whiteknight: ... and you trust OUR SERVERS? mmmheheheheh. 18:26
Whiteknight well, it's a small bit of redundancy...
note to self, DietCoke is not very reassuring
tewk_ I'm not quite that naive, close, but not quite.
dalek r28869 | kjs++ | trunk: 18:27
: [pirc] fix braced arguments in the macro preprocessor.
diff: www.parrotvm.org/svn/parrot/revision?rev=28869
tewk_ I use git, and push my changes to two backup servers as well as creating a diff.
DietCoke tewk_: useless note, your copyright dates on new files should probably be 2008 instead of 2006. 18:28
that's me, with the helpful code review! 18:29
tewk_ I just like to develop against SVN head, git allows me to do that easily. 18:30
18:30 Theory joined
tewk_ DietCoke: now that it works, I'm cleaning out old TGE code, point taken I'll touch copyrights. 18:30
DietCoke no, that's fine; I just thought we hadn't seen anything. I was merely acting in my role as backup backup out of the loop mentor.
davidfetter hello 18:32
anybody here using git on a project w/lots of contributors? 18:33
tewk_ I appreciate the attention, I just hate rebasing svn branches.
dalek r28870 | fperrad++ | libs4php:
: [php] add number_format()
diff: www.parrotvm.org/svn/parrot/revision?rev=28870
r28871 | kjs++ | trunk:
: [pirc] add new :lexid flag to pir parser.
: + minor refactor.
diff: www.parrotvm.org/svn/parrot/revision?rev=28871
tewk_ I know you can merge frequently, but that intermingles head and branch changes. 18:35
git fits my mental model and work patterns. 18:36
DietCoke I know the plan is to switch to PIRC someday. Has anyone written up something showing why we can't do it today? 18:37
Whiteknight I would like to know more about that myself
the currents status of PIRC doesn't seem to be well-documented
tewk_ PIRC just parses. IMCC builds PBC as well. 18:38
DietCoke Right, but is there anything other than a SMOP preventing that? 18:39
tewk_ I think the thought was finish the PBC to PMC refactor and then build a interface for bytecode generation (bcg), and then PBC could use bcg
DietCoke so a B MOP, then. =-) 18:40
kj DietCoke: pirc questions can go to kjs :-) 18:41
tewk_ Yeah, it will eventually get done. I remember when I started the pmc2c refactor so objects could be better supported so I could work on cardinal.
DietCoke aren't you he?
kj yeah :-)
DietCoke sneaky.
kj not well documented??
Whiteknight that's how he knows
that was my impression of it 18:42
DietCoke ok. then feel free to claim the ticket I'm about to create. =-)
Whiteknight maybe i didnt look in the right place
kj will do
oh maybe it's not well documented...
tewk_ I did just a little bit of the work, and after months and months of effort by allison, chromatic, pmichaud objects are finally reaching the end of the tunnel.
kj I will write up a bit
DietCoke kj: is pirc going to also do pasm, or will we also need a pasmc or will that stay with imcc?
kj it currently does the same thing as imcc, except it just parses , and is currently limited to some hard-coded instructions: that is, only a small set of instructions can be parsed, because I need a 'is_op(char *str)' function, that returns true if str contains the name of an op 18:44
so, instead of having a list of 10000 instructions hardcoded, imcc uses a is_op function, because using dynoplibs, you can have new instructions loaded
so the set of instructions can never be known beforehand
but I have trouble linking to this is_op function 18:45
DietCoke so also pasm, then?
kj it needs libparrot, and, well, it's just a pain to get that woorking
so yes, pasm too
I did include a separate pasm parser/scanner (pasm.l,y), just to have a 'clean' pasm grammar
it's also in pirc/new
but not sure if it actually compiles. 18:46
I just added that so I don't loose it
of course, if The General Feeling is that pasm should be separated, that can be done, but pirc, as it is now, already has a 3-stage architecture 18:47
oh, and for the SMOP part: i guess that's true, but PBC needs a clear interface; I did get some hope by the way after seeing the disasssembler, which doesn't look too complex. 18:49
tewk_ Moving the PBC code to PMC was the plan for improving the interface see pdd13 branch 18:51
kj istr that mdiep would work on that, but I may be wrong 18:53
Whiteknight DietCoke, I sent another message to that ticket with the updated patch and some info about the test errors we're getting 18:57
hopefully a keener eye then mine can find the problem
19:10 Ivatar joined
DietCoke mdiep is pretty much out of the picture at this point, or so I think. 19:22
19:24 cjfields_ joined
tewk_ I have interest in pdd13/bcg/pirc, but GSoC and school are probably going to take all my time. 19:24
Whiteknight ditto, I would love to work on that stuff when I have more time 19:27
DietCoke I'm not sure I've even seen your first message. 19:35
Whiteknight whose first message, mine? 19:37
DietCoke yes. 19:39
dalek r28872 | Whiteknight++ | gsoc_pdd09:
: [gsoc_pdd09] Fix some of my recent additions. Parrot compiles again without warning, although segfaults before build completes
diff: www.parrotvm.org/svn/parrot/revision?rev=28872
Whiteknight It's on the ticket for sure. My messages always take a long time to make it through to the list
dalek r28873 | Whiteknight++ | gsoc_pdd09: 19:44
: [gsoc_pdd09] updating to trunk r28866. I need to update to account for the changes made to stacks.c
diff: www.parrotvm.org/svn/parrot/revision?rev=28873
19:57 Auzon1 joined 20:04 Auzon joined 20:22 Ron joined
dalek r28874 | kjs++ | trunk: 20:24
: [pirc] update readme
diff: www.parrotvm.org/svn/parrot/revision?rev=28874
kj pirc readme contains a few notes on what to do for imcc/pirc replacement 20:25
Whiteknight okay, excellent 20:29
kj these are the major things; if you need more info, don't hesitate to ping 20:31
dalek r28875 | Whiteknight++ | gsoc_pdd09:
: [gsoc_pdd09] fix stacks.c to compile without warning or error with the new GC
diff: www.parrotvm.org/svn/parrot/revision?rev=28875
pmichaud I think I'll add a note about post-to-pbc generation also
kj I'd love to complete pirc at some point, but my knowledge of bytecode and such is just too little
pmichaud it would be very interesting to catalog the instructions that PAST::Compiler actually uses. I suspect the number is quite small. 20:32
Also, PAST::Compiler ends up maintaining its own lookup table of instructions -- might be nice to combine that with pirc at some point also 20:33
kj pmichaud: but at some point there will be more optimizations, that use specific instructions (special-purpose), no?
pmichaud kj: like what did you have in mind?
kj well, the easy ones would be n_add -> add 20:34
if that would be possible
pmichaud is that actually an optimization?
kj well, i think so, it prevents the creation of a new object
pmichaud only if you happen to have one around already that can be used :-) 20:35
(and that object is of the correct type)
kj true. And what about the library functions? There's special-purpose instructions for some, no?
so instead of a pir sub call, just emit the particular op; maybe for instance 'abs'? 20:36
pmichaud sure, but I still suspect the overall number of actual instructions used is quite small.
Rakudo can't just emit the particular op because of the potential for mmd 20:37
kj yes, i think you're right
DietCoke I am going to be ripping out a lot of the special cases in imcc there. (say, for example, is going to be an opcode)
kj DietCoke: what do you mean?
purl do you mean is that the problem I'm seeing now, or do you mean do I think that's a problem to be addressed?
pmichaud basically, any language that is planning to use Parrot's subroutine interface for mmd won't be able to do much with the opcode mmd
DietCoke pmichaud: urk? vtables participate in MMD. if you're avoiding an opcode to do your own MMD, that seems odd.
pmichaud DietCoke: it depends on the opcode. 20:38
DietCoke ok.
pmichaud I don't know that I want my compiler to have to know that a method named 'abs' is supposed to map to a vtable .abs
DietCoke kj: 'say' is not an opcode at the moment, but a special-evil-dispatch to the 'say' method on the ParrotIO object.
pmichaud we may end up doing that, but afaict there's not a whole lot of speed improvement. 20:39
DietCoke I'm not sure why you'd have to?
kj DietCoke: ah i see
pmichaud: these special cases is the whole point of a compiler, right?
DietCoke if you want the abs, what's wrong with '$P1 = abs $P0' ?
pmichaud class MyFunnyNumber { method abs() { ... } }
and then later
kj the nitty-gritty is part of any hardware targeting compiler
pmichaud $x = abs($myfunnynumber)
DietCoke you can have the method and the vtable call the same code, neh? 20:40
pmichaud yes, but then what's the advantage of the vtable?
DietCoke welll, why have vtables at all?
pmichaud I've been wondering that a lot lately.
DietCoke (that's not a snarky question.)
Infinoid it seems a lot easier to call vtables from C 20:41
DietCoke they don't use the PCC.
pmichaud kj: sure, the special cases are part of the point of a compiler. But they get awfully weird very quickly if we try to translate Perl 6 operators into opcodes.
kj pmichaud: it just seems so inefficient to have to call 'infix:+' when what we're doing is just add A, B 20:43
pmichaud it's not as if the opcodes allow me to avoid subs entirely -- I still have to be able to pass &prefix:<abs>
if we know that A and B are basic types, then yes, we might be able to optimize there
kj but add is a vtable method right?
so if A is a perl int 20:44
DietCoke well, you could do everything method wise inside perl6,but if someone passes you a Float and you try to call a method on it that's a vtable, you'll be hurting.
pmichaud kj: how often am I going to know that my operands are ints?
kj you don't, but that's fine... maybe I misunderstand the whole thing here 20:45
I would guess the add vtable method is invoked on A
with B as an argument
20:45 Ron joined
pmichaud so, when someone defines my sub infix:<+>(Any $a, Dog $b) { ... } --- how do we translate that to a vtable method? 20:46
kj wouldn't the add vtable method be invoked on $a, which is an Any object, and the $b Dog object would be passed as argument 20:47
pmichaud yes, but is the add opcode smart enough to distinguish that from 20:48
my sub infix:<+>(Any $a, Cat $c) { ... }
?
kj that case it will still pass $c as argument..
pmichaud right, but that's a *different* sub.
kj maybe my knowledge of the whole vtable thing is lacking here.
aah
aaaaaaah 20:49
pmichaud what's worse, the add opcode is actually a three-argument add
i.e., it's add_p_p_p
kj ah ok. I see your point
pmichaud which means that somehow the vtable add has to get the PMC that it's supposed to store the result in
and that target PMC has to already be initialized, and it has to be of an appropriate type to receive whatever value is the result of doing the add 20:50
kj uhm. So what *is* the use of vtables then... (what DietCoke said)
pmichaud I don't know.
the more I do stuff in Perl 6, the less useful they seem. I think they might've been very useful if we were implementing Perl 5, which is far less object and mmd-based. 20:51
Whiteknight Vtable overrides are, at the very least, going to help with tied variables I think
kj mmm it once seemed to make sense to me all. The vtable provides a uniform API for all PMCs
so each PMC decides what to do for each of the vtable functions 20:52
DietCoke Whiteknight: I disbelieve you.
Whiteknight that's fine, this isn't my area of expertise
DietCoke =-)
pmichaud (being able to overload [] is indeed a help. But we could likely do that even w/o vtables :-)
DietCoke sure, we could switch everything to methods. 20:53
it's not insane.
Whiteknight well, we can do things a million ways. Vtables are at least a convenient tool
pmichaud and, all of the above said, there *are* cases where the vtable methods work fine.
NQP uses them extensively, and so do things like 'abc' and APL
DietCoke yes, but if I can't use the add opcode on a perl6 PMC and a tcl PMC, is there any point?
pmichaud DietCoke: are we doing a tcl add or a perl 6 add? 20:54
DietCoke And this is why HLL interop needs to be spec'd. =-)
pmichaud my question actually has a useful answer
kj I don't think it has every been done before 20:55
DietCoke at the moment, I believe "left side wins"
kj hll interop for dynamic languages
pmichaud at the moment, the language translator wins
DietCoke ?
pmichaud perl 6 will take a '+' operator and convert it into infix:+
kj i mean, parrot is the first attempt.
pmichaud the default infix:+ numifies both of its arguments, adds them together, and returns a num result
DietCoke even if the LHS is not one of your PMCs?
pmichaud yes
DietCoke I believe that's breaking some kind of unwritten rule. =-) 20:56
(that PMCs know how to FOO themselve.s)
pmichaud I could do it as a method, but I absolutely can't do it as a vtable method, unless vtable add knows how to do mmd based on the rhs argument also 20:57
DietCoke and if someone else passes a perl6 PMC to the add opcode? will that DTRT, or does it rely on the infix+ to work?
pmichaud I suppose it depends on the perl6 PMC
I can certainly create a default vtable add method for the Any class that does the equivalent p6 add 20:58
DietCoke I really think we need to spec out how we expect HLL interop to work with something other than handwaving before we have 20 different languages that can't talk to each other. =-)
kj well, we already have the 20 different languages :-P
most of them incomplete
DietCoke (not that you're handwaving now; it's just the spec so far.)
moritz can any of the languages call subs from any of the other languages so far? 20:59
pmichaud I think I'm just saying that the existing vtable mechanism isn't powerful enough for Perl 6 mmd
DietCoke And I'm saying that if you need something else, i want to make sure that works if I try to call your code from my HLL.
pmichaud indeed, what appears to be happening in Rakudo is that the vtable methods simply forward to the appropriate sub
DietCoke that seems vaguely reasonable.
kj moritz: i think it should be not really a big problem, but how to load both modules, or import a module from one language
none of the existing languages can do that I think 21:00
for instance, module a written in abc needs a way to import/load a module written in (for instance) squaak
DietCoke I could probably whip up a POC that let tcl invoke perl6.
moritz that would be cool 21:01
DietCoke pmichaud: is there a .pbc I can load that compreg's perl6?
pmichaud perl6.pbc, yes. 21:03
kj mm, might be useful to have at least a showcase of how a typical import-like statement would work.
(for multi-file programs) 21:04
pmichaud we had this discussion a couple of months ago (w/japhb)
cotto_work DietCoke, go for it. For a project where HLL interoperability is major feature, there isn't much that specifies how it'll actually happen.
pmichaud we're thinking that there needs to be a standard way to invoke an importer for a given .pbc module
21:04 Limbic_Region joined
pmichaud since load_bytecode doesn't allow options to be passed, I'm guessing we store any options in a standard location and then a .pbc file has a :load :init sub that reads the options and processes them accordingly 21:05
kj standard way: sounds reasonable.. but each language has different semantics for loading/importing (or may have). For instance, import in Java and Python
(not sure if these differ, but if they're equal, it would be coincidental)
pmichaud kj: yes, it's a negotiation between the modules. We can define a low-level standard for .pbc, and individual languages layer their semantics on top of that. 21:06
nopaste "Coke" at 72.228.52.192 pasted "FAIL" (14 lines) at nopaste.snit.ch/13435
Limbic_Region salutations all - my YAPC photos are up
gatcomb.org/photos/joshua/2008/06/
pmichaud - I was sure to not post the one of you and the danish 21:07
pmichaud aha. tcl and perl6 have differing notions of PAST::Node, since they're using different PAST libraries...?
or perhaps the pbc for PAST is getting loaded twice?
DietCoke cotto_work: I am not the architect. =-) 21:10
I'm happy to do grunt work as it's laid out, but I'm not the guy to specify how that'll work.
I can, at least, keep tcl on the table as a potential player in the HLL space.
I would have written that document 7 years ago if I was that guy. =-) 21:11
pmichaud I'll be defining a protocol for rakudo modules, at least, but as I do that I'll be considering how other Parrot (or at least PCT) components will play with that.
DietCoke And it would be nice to know if we're going to have to use PCT to interact with rakudo, as an fyi.
pmichaud speaking of vtable add.... does anyone have an example of what a vtable add override would actually look like (in PIR)? 21:12
my expectation is that hll interop should _not_ depend on PCT.
DietCoke .sub add :vtable :method (#method only needed for self bug) ; do stuff;
pmichaud what do the params look like?
DietCoke I would expect there to be 'self', and then a single .param 21:13
pmichaud ....but add is a 3-arg opcode
DietCoke (is it int? pmc? good question.)
one of those is a return value.
pmichaud add $P0, $P1, $P2
kj .param pmc a; .param pmc b; would translate to add_p_p_p, I guess
DietCoke kj: not if a is self.
pmichaud so vtable add acts like n_add ?
DietCoke <shrug> I'm handwaving. =-)
pmichaud that's what I mean about it not being very useful. 21:14
normally to do an 'add' one does:
$P0 = new 'Integer'
add $P0, $P1, $P2 # add p1 and p2 together, place the result in $P0
i.e., the result PMC has to exist *before* the add opcode
so, how do I access that result PMC inside of my add :vtable method? 21:15
kj in other words, how to specify OUT parameters? 21:16
(that are declared as OUT in an ops file)
pmichaud well, some out parameters are okay
actually, now that I think about it... perhaps they aren't. I don't know that I'm doing anything that makes use of out parameters 21:18
kj maybe related, not sure, but how do you know for sure that your pir sub 'add' will return something?
if you just return nothing, that's fine as far as the pir compiler is concerned
pmichaud you mean a normal pir sub? I just make sure it has a .return statement :-) 21:19
kj right. but we don't check for that
pmichaud if it doesn't return something, that can result in a signature mismatch
DietCoke you could theoretically check its signature once that's in.
kj i.e. runtime error?
DietCoke would have to be.
pmichaud I think we might check for it if we're expecting a return value that we don't get.
DietCoke given we can swap out subs at runtiem.
pmichaud I know we don't carp if there are more return values than places to put them. 21:20
DietCoke just run it and get the error.
pmichaud: we probably should, neh?
pmichaud DietCoke: chip and I discussed it years ago, and we both decided it was better to throw them away
otherwise we end up doing a lot of ($P0, $P1 :slurpy) = foo()
when we're just going to throw away $P1 21:21
DietCoke I think we could come up with a better "I only want one return value" syntax.
kj that's $P0 = foo()
DietCoke .. arguably, that one, ya. =-)
pmichaud do we want 'foo' to have to check its caller and determine whether or not to return extra parameters?
kj as opposed to ($P0, $P1) = foo(0
pmichaud because that's what that would require
kj that's already specified in get_results opcode, right? 21:22
that you invoke before calling
DietCoke no, we could return them and ignore them. like we do now, except default to throwing an error without the extra sugar.
pmichaud kj: I'm not saying it can't be done -- I'm asking if we want every sub to do that. 21:23
DietCoke I imagine that's going to be far more painful a question to answer in terms of HLL interop than it is standalone.
pmichaud (every sub that returns multiple values, at any rate)
DietCoke -> 21:24
21:25 japhb joined
kj it's 22:25 and still in office. Time to go home. Good night everybody 21:25
NotFound By the way, the recent ticket about tailcall is related to that, the value returned by the tailcalled is not of the type expected by the caller. 21:27
21:28 grim_fandango joined
Whiteknight hey baby 21:33
...wrong channel :( 21:34
Auzon I hate when that happens ;)
moritz it could have been far worsen than "hey baby" ;-) 21:35
s/worsen/worse/
Whiteknight yeah, that's why I don't break into full cybersex until I've said "hello" 21:36
moritz lol, Whiteknight++
pmichaud Whiteknight: re parameters to vtable methods.... note that Parrot currently allows methods to be called as foo(invocant, args) in addition to invocant.foo(args) 21:45
(and PGE and Rakudo rely on this to some extent)
also, perhaps the find_method test you looked at doesn't presently carp because Parrot doesn't do argument checking on subs with zero params 21:47
but once it got turned into a method (or specifically expecting 'self'), then argument checking was turned on and it started complaining about the missing 'str' param 21:48
Whiteknight Either way, I think the find_method test should be expecting a name of a subroutine to find, so that's proper behavior 21:50
as to the invocant stuff, I have no idea how to fix it
dalek r28876 | Whiteknight++ | gsoc_pdd09: 21:54
: [gsoc_pdd09] add a few ugly but remarkably helpful diagnostics messages
diff: www.parrotvm.org/svn/parrot/revision?rev=28876
pmichaud Whiteknight: yes, acking it to expect a string argument is fine. 21:57
*asking
with :vtable, it should get the implicit self and the required string arg
if invoked as a function, we still pass two arguments (the implicit self and the required string) 21:58
22:00 Infinoid joined, teknomunk joined 22:02 Limbic_Region joined 22:16 cognominal joined 22:27 cjfields joined 22:31 sjansen joined 22:44 japhb joined 22:52 kid51 joined 23:03 tetragon joined 23:05 Theory joined 23:10 stupidbot joined 23:21 bacek joined 23:36 Theory joined, TiMBuS joined 23:39 bacek_ joined
DietCoke msg kid51 ok, lunchtime was optimistic. checking out the opsrenum branch now... 23:41
purl Message for kid51 stored.
DietCoke Anyone have any feedback on the :deprecatd ops thing? 23:42
23:45 tetragon joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!