Camelia, the Perl 6 bug

IRC log for #parrot, 2008-06-30

Parrot | source cross referenced

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

All times shown according to UTC.

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

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

Parrot | source cross referenced