Camelia, the Perl 6 bug

IRC log for #parrot, 2010-05-03

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
01:05 Austin_away joined #parrot
01:11 dl748 joined #parrot
01:18 dalek parrot: r46225 | NotFound++ | trunk/src/interp/inter_create.c:
01:18 dalek parrot: flush and unbuffer stderr and stdout at the start of interpreter destruction
01:18 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46225/
01:21 hicx174 joined #parrot
01:22 JimmyZ joined #parrot
01:23 JimmyZ \o
01:27 snarkyboojum joined #parrot
01:59 Psyche^ joined #parrot
02:04 snarkyboojum joined #parrot
02:18 parthm joined #parrot
02:34 ruoso joined #parrot
02:35 janus joined #parrot
03:05 theory joined #parrot
03:16 LoganLK joined #parrot
04:07 cotto seen kid51
04:07 purl kid51 was last seen on #parrot 1 days, 12 hours, 17 minutes and 10 seconds ago, saying: Those two files should have been governed by an svn:ignore property.  Committed fix in r46204.  [May  1 15:50:42 2010]
04:07 cotto seen jkeenan
04:07 purl I haven't seen 'jkeenan', cotto
04:08 cotto seen purl_is_stupid
04:08 purl I haven't seen 'purl_is_stupid', cotto
04:15 Austin_Hastings joined #parrot
04:22 parthm joined #parrot
04:23 japhb joined #parrot
04:42 dngor joined #parrot
04:43 cotto seen allison
04:43 purl allison was last seen on #parrot 2 days, 4 hours, 9 minutes and 58 seconds ago, saying: it's 1:30am here, going to get some sleep  [May  1 00:33:40 2010]
04:56 workbench joined #parrot
05:08 dalek parrot: r46226 | plobsing++ | failed to fetch changeset:
05:08 dalek parrot: merge pbc_frozen_strings1 branch
05:08 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46226/
05:11 sorear one idea I've been playing with recently is a "streaming" extension to PCT
05:11 sorear right now, compilers are required to prepare all their PAST and hand it back as a big lump
05:12 sorear but keeping all the PAST in memory at once is problematic
05:12 sorear (especially so ATM because the PAST retains match nodes, in NQP-based compilers)
05:13 sorear what if PCT provided an &*ISSUE hook which allowed compilers to send off PAST::Block s to the pipeline tail as they are constructed?  it would have to generate a name for the block and return a PAST::Node representing the block by name
05:14 sorear and the root block would have to become marked :main since we'd no longer be able to rely on it coming first
05:14 plobsing sorear: interesting idea. a streaming PAST model also lends itself well to task concurrency
05:15 parthm left #parrot
05:15 sorear it would also be good for "are we there yet?" types.  tail -f $outputfile.pir
05:19 eternaleye joined #parrot
05:19 plobsing not holding the entire PAST tree at once could also be easier on memory consumption
05:22 sorear plobsing: that's actually the primary reason
05:24 dalek parrot: r46227 | cotto++ | trunk/MANIFEST:
05:24 dalek parrot: [MANIFEST] regenerate manifest
05:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46227/
05:27 sorear PCT compilers appear to use close to O(n) space, and 6000 lines is the practical limit for NQP source files
05:27 sorear this is not going to cut it forever
05:28 plobsing so whatcha gonna do about it?
05:28 sorear well, I've got some ideas for a solution I've been playing with
05:29 sorear a "streaming" extension to PCT
05:29 sorear right now, compilers are required to prepare all their PAST and hand it back as a big lump
05:29 sorear what if PCT provided an &*ISSUE hook which allowed compilers to send off PAST::Block s to the pipeline tail as they are constructed?  it would have to generate a name for the block and return a PAST::Node representing the block by name
05:30 sorear that way, the blocks could be POSTed and written to the output file as soon as they are generated
05:30 sorear and memory usage would only be O(nesting depth) instead of O(file size)
05:30 sorear How is --target=past spelled these days?
05:31 plobsing an ISSUE hook seems good for the current architecture, but why not play to the advantages of the VM and use something like coroutines to manage separate compilation steps. then ISSUE simply becomes yield
05:34 sorear because ISSUE needs to return a value
05:35 sorear my &*ISSUE := sub ($x) { $x }; is simpler than writing a coroutine-calling loop
05:36 sorear because yield is harder to access from random languages than function calls
05:37 sorear because dynamic-scope-wide parameters are already playing to the advantages of the VM
05:54 eternaleye joined #parrot
05:57 dalek parrot: r46228 | plobsing++ | trunk/DEPRECATED.pod:
05:57 dalek parrot: deprecate String.lower()
05:57 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46228/
06:00 dalek TT #1606 created by plobsing++: [DEPRECATION] String.lower()
06:00 dalek TT #1606: http://trac.parrot.org/parrot/ticket/1606
06:02 uniejo joined #parrot
06:08 aukjan joined #parrot
07:16 somebody_ joined #parrot
07:18 riffraff joined #parrot
07:20 iblechbot joined #parrot
07:21 parthm joined #parrot
08:07 dalek parrot: r46229 | chromatic++ | trunk/src/pmc/imageiosize.pmc:
08:07 dalek parrot: [PMC] Fixed C++ build error in ImageIOSize PMC.
08:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46229/
08:07 dalek parrot: r46230 | chromatic++ | trunk/src/dynpmc/gziphandle.pmc:
08:07 dalek parrot: [dynpmc] Fixed some compilation warnings in GzipHandle PMC.
08:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46230/
08:25 moritz seen pmichaud
08:25 purl pmichaud was last seen on #parrot 10 days, 7 hours, 17 minutes and 2 seconds ago, saying: cotto_work: (troll refutation)  Thanks.  :-)  [Apr 23 01:07:58 2010]
08:25 fperrad joined #parrot
08:30 fperrad_ joined #parrot
08:36 riffraff joined #parrot
08:42 parthm left #parrot
09:12 dalek parrot: r46231 | chromatic++ | trunk/compilers/imcc/pbc.c:
09:12 dalek parrot: [IMCC] Rearranged the STRING comparisons in add_const_str() to find mismatches
09:12 dalek parrot: before performing almost useless comparisons.  This speeds up building an
09:12 dalek parrot: example NQP-based PBC by 27.777%.
09:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46231/
09:12 dalek parrot: r46232 | chromatic++ | trunk/src/pmc/imageiosize.pmc:
09:12 dalek parrot: [PMC] Rearranged STRING comparisons in ImageIOSize PMC's push_string() to
09:12 dalek parrot: filter out mismatched STRINGs earlier.  This improves the NQP-based benchmark
09:12 dalek parrot: by another 21.280%.
09:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46232/
09:12 dalek parrot: r46233 | chromatic++ | trunk/src/pmc/imageio.pmc:
09:12 dalek parrot: [PMC] Rearranged STRING comparisons in ImageIO PMC's push_string() to filter
09:12 dalek parrot: out mismatched STRINGs earlier.  This improves the NQP-based benchmark by
09:12 dalek parrot: another 12.049%.
09:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46233/
09:14 lucian joined #parrot
09:16 moritz wow
09:24 sorear ImageIO should probably be renamed
09:25 sorear I read those commits and my first thought was "WTF why are we shipping a graphics file library with Rakudo"
09:31 moritz FWIW, rakudo on latest parrot segfaults on t/spec/S06-signature/errors.rakudo
09:31 moritz (you can generate that file with `make t/spec/S06-signature/errors.t')
09:32 bacek joined #parrot
09:32 nopaste "moritz" at 192.168.1.3 pasted "backtrace from perl6 t/spec/S06-signature/errors.rakudo" (26 lines) at http://nopaste.snit.ch/20447
09:40 dalek rakudo: c9d9a99 | moritz++ | build/PARROT_REVISION:
09:40 dalek rakudo: bump PARROT_REVISION to get some testing after merge of pbc_frozen_strings1 branch
09:40 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​9d9a997fbf06c21a4241723cdc24a49bfb39760
09:42 JimmyZ joined #parrot
10:11 clinton joined #parrot
10:12 alexn_org joined #parrot
10:23 parthm joined #parrot
10:37 jsut_ joined #parrot
10:43 nopaste "bacek" at 192.168.1.3 pasted "moritz, this is spectest result on my box..." (11 lines) at http://nopaste.snit.ch/20448
10:43 bacek ~~
10:43 bacek moritz, I can't reproduce S06-signature segfault...
10:59 parthm left #parrot
11:17 * moritz is on 64 bit linux
11:39 riffraff joined #parrot
11:52 dalek rakudo: 1eef087 | (Solomon Foster)++ | src/core/operators.pm:
11:52 dalek rakudo: Change infix:<...> code to use the last three elements passed on the left-hand side to determine the series, rather than the first three.
11:52 purl dalek: that doesn't look right
11:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​eef08710bbac2b8d68bed0939642ce52b4bfcaa
11:58 Mokurai joined #parrot
12:03 bluescreen joined #parrot
12:14 ruoso joined #parrot
12:49 dalek rakudo: b440a11 | moritz++ | t/spectest.data:
12:49 dalek rakudo: two more passing test files
12:49 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​440a117618c820a22964e34d7b8179060619b98
13:11 Rahly joined #parrot
13:14 athomason joined #parrot
13:15 dalek plparrot: 4bd4e44 | dukeleto++ | plparrot.c:
13:15 dalek plparrot: Use constant Parrot strings when applicable
13:15 dalek plparrot: review: http://github.com/leto/plparrot/commit/4​bd4e44ea94b81a569c6f6492343adde05746b0a
13:25 Coke joined #parrot
13:25 Coke anyone wants easy karma, feel free to update the codestring branch with latest changes from trunk.
13:26 particle (easy karma)++
13:26 Coke I think I fixed sorear's bug building test.pir in codestring branch.
13:30 atrodo joined #parrot
13:33 whiteknight joined #parrot
13:33 dalek parrot: r46234 | coke++ | branches/codestring/src/pmc/string.pmc:
13:33 dalek parrot: Don't fixup get/set string to deal with alternate storage - If you want
13:33 dalek parrot: alternate storage, you need to override these 2 methods in your subclass'd PMC.
13:33 dalek parrot: This avoids an issue building Test.pir on rakudo, sorear++ for reporting.
13:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46234/
13:36 parthm joined #parrot
13:45 bacek ~~
13:49 Coke @bacek ~~ /Robot/ # True
13:50 bacek :)
13:53 Coke msg cotto - can we slap the svn front end on a github repo like github does? would that make everyone happy?
13:53 purl Message for cotto stored.
13:53 Coke msg (since github's svn-git seems much more transparent than git-svn)
13:53 purl Sorry, I've never seen (since before.
13:54 Coke msg cotto (since github's svn-git seems much more transparent than git-svn)
13:54 purl Message for cotto stored.
13:54 bacek Coke, erm... Why do we need svn frontend?
13:55 Coke bacek: for those who would prefer svn.
13:55 Coke "make everyone happy" instead of "make 90% happy"
13:55 bacek is svn-git two way?
13:56 Coke bacek: whatever github is doing seems to be, yes.
13:56 Andy joined #parrot
13:57 bacek http://github.com/blog/626-announcing-svn-support
13:57 bacek 1st of April...
13:57 moritz it works anyway :-)
13:58 bacek hollei schitt
13:58 Coke yah. So we really can do it both ways. Only thing we need on top is trac.
13:59 Coke ah. my bad, it's readonly.
14:00 Coke (FOR NOW!)
14:00 bacek bacek@icering:~/src/ppp/parrot.git$ svn commit -m "Added foo" foo
14:00 bacek svn: Commit failed (details follow):
14:00 bacek svn: MKACTIVITY of '/bacek/parrot.git/!svn/act/08d29​ebd-75ca-4ddd-a1d9-3fa6eb0e3573': Could not read status line: connection was closed by server (http://svn.github.com)
14:02 Coke curses.
14:02 Coke still good for all the tinder/smoke tools.
14:05 Coke they are currently working on the ability to commit.
14:05 Coke "@jcaspes - working on it right now. trying to make really sure that SVN doesn't do anything stupid with your code."
14:05 parthm joined #parrot
14:05 lucian joined #parrot
14:12 confound joined #parrot
14:12 parthm joined #parrot
14:13 parthm left #parrot
14:16 Coke seen sorear?
14:16 purl sorear was last seen on #parrot 4 hours, 51 minutes and 6 seconds ago, saying: I read those commits and my first thought was "WTF why are we shipping a graphics file library with Rakudo"
14:20 bubaflub joined #parrot
14:21 Coke I suspect our problem with the svn properties in trunk is that the merge backs have not been using "--reintegrate"
14:21 GodFather joined #parrot
14:22 Coke that combined with specific ranges to the merges to branch (instead of a simple "svn merge ^/trunk") is probably causing the svn:merge property propagation.
14:24 Coke I do wish that 'svn merge' had a verbose option to compensate for it being so slow.
14:25 GodFather joined #parrot
14:26 bacek Coke, it's called "git merge; git svn dcommit"
14:26 PacoLinux joined #parrot
14:27 Coke bacek: not helpful. =-)
14:27 Coke to me, git >> svn >> git-svn
14:27 Coke (the pain of the svn portion of git-svn outweighs the git goodness.)
14:28 bacek it's less painful now with svn 1.5 on server side.
14:29 dukeleto 'ello
14:32 Coke bacek: the mismatch still hurts. easier for me to just use svn if we're using svn.
14:32 Coke (though I'd prefer using git)
14:35 dukeleto git++
14:41 dalek parrot: r46235 | coke++ | failed to fetch changeset:
14:41 dalek parrot: merge changes from trunk
14:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46235/
14:41 nopaste "coke" at 192.168.1.3 pasted "svn error?" (6 lines) at http://nopaste.snit.ch/20450
14:43 mikehh joined #parrot
14:43 Coke that hosed my entire checkout.
14:43 Coke everything is locked. cleanup? can't. remove it? next directory is fubar.
14:43 bacek "git reset --hard remotes/trunk"
14:43 Coke svn--
14:43 Coke bacek: NOT HELPERING
14:43 Coke s/ER//
14:44 moritz svn-- indeed
14:44 bacek "helping is not implemented yet in my program"
14:45 Coke I'm not using git or git-svn. I've already said i wish to switch to git. telling me how to fix my problem /in git-svn/ is not at all helpful to me.
14:45 bacek Nice. Looks like LOLCODE testsuite expose bug in parrot lexicals.
14:54 Coke d'oh. rakudo's going to build much faster with -j1 due to memory issues, isn't it.
14:55 moritz unless you have quite some memory
14:55 moritz and it segfaults randomly on many test files
14:55 Coke whoops.
14:55 Coke it's segfaulting now?
14:55 Coke (against trunk?)
14:56 moritz on r46233
14:57 Coke hopefully the segfaults are the cause of the speed increase. =-)
14:57 Coke AREN'T
14:59 Coke moritz: any objection to a patch that rewrote gen_builtins.pl into NQP?
15:00 nopaste "bacek" at 192.168.1.3 pasted "most beautiful parrot bug ever..." (45 lines) at http://nopaste.snit.ch/20451
15:00 moritz Coke: no objections... what's the benefit?
15:00 bacek output of nopasted code is "not ok 6"
15:01 bacek If I'll comment out last .return - it will output "ok 6"
15:01 bacek And it's 1AM already...
15:01 Coke moritz: move towards eliminating perl5 as a direct dependency to the build process for rakudo.
15:02 Coke (plus, more sixian perl. =-)
15:02 moritz well, fine by me
15:02 moritz maybe it should go into a different directory then
15:03 riffraff joined #parrot
15:12 nopaste "moritz" at 192.168.1.3 pasted "another rakudo backtrace on parrot trunk" (50 lines) at http://nopaste.snit.ch/20452
15:13 dalek parrot: r46236 | mikehh++ | trunk (2 files):
15:13 dalek parrot: fix codetest failure - parentheses should not have space immediately after the opening parenthesis nor immediately before the closing parenthesis
15:13 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46236/
15:16 NotFound moritz: all backtraces I've looked at recently are almost the same, they are triggered from hashiterator shift.
15:16 Coke msg chromatic I just timed the codestring branch vs. trunk in building rakudo. my clock-based timings (I know, I know) show that trunk runs in 78% of the time that the branch does. :(
15:16 purl Message for chromatic stored.
15:17 moritz NotFound: can you also fix it? :-)
15:17 * moritz documutes
15:17 moritz s/o/e
15:17 moritz whatever
15:17 purl i guess whatever is easiest to type
15:18 NotFound moritz: no, I've just be able to make it less frequent by reducing the number of short-lived pmcs.
15:19 NotFound The real culprit hasn't been diagnosed yet.
15:20 Coke (reducing # of short lived pmcs always a plus)
15:21 NotFound Coke: yes, there were a lot of them in deep paths.
15:21 NotFound init_int has been very helpful.
15:30 Coke An infrequent rant: valgrind in macports still not updated to work with 10.6
15:31 arnsholt Quite. I don't think GHC works either
15:36 NotFound I think that at least part of the problem comes from Parrot_pmc_new_temporary. Temporaries are created in the constant pool, and thus not marked.
15:37 NotFound moritz: Can you make a short test?
15:38 NotFound Uh, forget it, pge doesn't even pass tests.
15:38 purl NotFound, I didn't have anything matching it, pge doesn't even pass tests
15:39 Coke NotFound: looks like Parrot_new_pmc_temporary is hardly used.
15:39 NotFound Coke: look at cmp.ops
15:39 Coke right.
15:40 Coke why is eq_p_i_l creating a temporary pmc at all?
15:40 NotFound Uh....
15:41 Coke (hurm. to use the LHS's vtable.) seems like there should be a better way than using a temp PMC, though. :(
15:41 Coke (note that eq_p_n_l does it the other way, getting a numeric from the PMC and comparing them directly)
15:51 Coke NotFound: looks evil. wonder, given how infrequently it's used, if it's still needed. if something like it is, maybe it'd be better to improve the vtable interface than rely on it.
15:51 NotFound Coke: VTABLE_equal_integer ?
16:01 davidfetter joined #parrot
16:05 darbelo joined #parrot
16:06 cotto Coke, github's svn backend is read-only (for now).
16:07 cotto I'll bring up the question of what would be preferred at the next #ps.
16:07 integral joined #parrot
16:08 cotto I've at least done enough exploring to know that it's possible to have multiple version controls backends for trac (though having n-1 be read-only is pretty essential to maintaining sanity).
16:08 cotto seen allison
16:08 purl allison was last seen on #parrot 2 days, 15 hours, 34 minutes and 50 seconds ago, saying: it's 1:30am here, going to get some sleep  [May  1 00:33:40 2010]
16:10 theory joined #parrot
16:27 iblechbot joined #parrot
16:30 ash_ joined #parrot
16:35 dalek parrot: r46237 | mikehh++ | trunk/t/src/embed.t:
16:35 dalek parrot: fix test failure with g++ build
16:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46237/
16:37 NotFound mikehh: Fail!
16:38 NotFound parrot.h must not be used from embedding!
16:40 ash_ why not use parrot.h in embedding?
16:40 ash_ is that breaking encapsulation?
16:40 darbelo Yeah.
16:40 ash_ got ya
16:40 NotFound ash_: because is for internal usage only.
16:41 darbelo It exposes all sort of things that embedders/extenders should know the details of.
16:41 darbelo s/should/shouldn't/
16:42 NotFound If real usages require a function that isn't available in extend.h or embed.h, you should open a ticket, instead of hacking up.
16:42 mikehh NotFound: I tried various other things and that was the only thing I get that test to pass with g++
16:42 NotFound mikehh: look at examples/embed/cotorra.c
16:43 mikehh it passedf with gcc - but I am dubious
16:43 NotFound mikehh: I don't care if the test pass, I care about his correctness.
16:43 NotFound If isn't correct, making it pass is counterproductive.
16:44 NotFound And we already have a lot of wrong embed tests skipped.
16:44 mikehh NotFound: ok I will look - but the calls are suspect
16:45 mikehh the string stuff got changed in r46226
16:45 darbelo Coke: ping
16:46 NotFound mikehh: if the code compiles in C without warnings, it will pass with C++ unless some header is wrong.
16:48 mikehh NotFound: yes - it claims that various functions are NOT defined (at least in g++ - it doesn't bother gcc)
16:49 NotFound Sigh.
16:50 ash_ are there some specific #includes that only happen if your in C or that don't happen if your in C++
16:50 ash_ ?
16:51 dalek parrot: r46238 | mikehh++ | trunk/t/src/embed.t:
16:51 dalek parrot: forgot to update copyright
16:51 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46238/
16:52 NotFound Oh, nice, the Makefile in examples/embed doesn't use ccwarn
16:52 mikehh before I modified I got:
16:52 mikehh # Failed to build 't/src/embed_1.o': t/src/embed.t: In function ‘int main(int, const char**)’:
16:52 mikehh # t/src/embed.t:59: error: ‘Parrot_str_new_constant’ was not declared in this scope
16:52 mikehh # t/src/embed.t:62: error: ‘Parrot_str_to_cstring’ was not declared in this scope
16:52 mikehh # t/src/embed.t:64: error: ‘Parrot_str_free_cstring’ was not declared in this scope
16:53 mikehh that's with g++ - no problems with gcc
16:53 NotFound mikehh: we are not checking our ability to compile wrong code.
16:54 mikehh NotFound: I found similar problems in other areas
16:54 NotFound mikehh: and if we keep hiding instead of solving, we'll have it forever.
16:56 mikehh NotFound: one of the reasons I use gcc and g++ in my tests and also with and without --optimize
16:57 NotFound mikehh: sorry if I'm being rude, but that problems with embed tests are a long history.
16:58 mikehh NotFound: np - I understand where you are coming from
16:59 NotFound Uhhh... We don't have any is_null in the extend interface? :o
16:59 darbelo That doesn't sound like a good idea.
17:00 particle call the pir op from c :P
17:01 mikehh I seem to recall other tests that required adding include/parrot/extend.h
17:03 cotto_work2 joined #parrot
17:04 Mokurai1 joined #parrot
17:07 dalek parrot: r46239 | NotFound++ | trunk/examples/embed/Makefile:
17:07 dalek parrot: use ccwarn in examples/embed
17:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46239/
17:28 Coke darbelo: pong
17:34 darbelo Coke: I can update codestring for you if you want me to, but I'll probably need input with regard to any conflicts from trunk.
17:35 darbelo ISTR there being optimizations on both trunk and branch.
17:37 chromatic joined #parrot
17:40 dalek parrot: r46240 | NotFound++ | trunk/t/src/embed.t:
17:40 dalek parrot: fix embed compile string error test for C++ buildability and parrot internal correctness, and place it after a simpler test
17:40 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46240/
17:41 chromatic PMCs created with Parrot_pmc_new_temporary() don't need to be marked.
17:43 Coke darbelo: already done.
17:43 Coke chromatic: is codestring still faster than trunk for you?
17:43 Coke (for me, was clock-slower, but I trust your measurements more than `time`)
17:44 chromatic I haven't tried.  What were you measuring?
17:44 Coke uh, darbelo, what did you?
17:44 Coke *do
17:44 Coke did you just  merge the things I hadn't merged y et?
17:44 Coke (and how did you do it?)
17:44 Coke chromatic: 'make -j1' in rakudo
17:45 darbelo Coke: I dcommited before you told me it was alredy done. Sorry.
17:45 Coke darbelo: ugh. I think you reverted everything.
17:45 chromatic Parrot's -o to PBC is a lot slower on trunk.
17:46 darbelo Coke: Entirely possible if it was already up to date.
17:46 chromatic I doubled its speed, but looking for constants to coalesce is at least an O(n) operation, where it could be O(1), and that n is a lot bigger than you think it should be.
17:47 darbelo Coke: We need to revert 46241 and 46242.
17:48 darbelo I'll do it now.
17:49 Coke darbelo: thanks.
17:50 darbelo Oh, and I screwed up the non-codestring merge too. Go me!
17:50 chromatic There's too much awesome in that single file for only one branch to contain.
17:50 Coke darbelo: just revert those 2 commits, and everything will be fine.
17:51 chromatic msg plobsing Building Rakudo's PBC now takes long enough that it's time to consider the hash lookup, as well as a unification of the three places that add constant strings.
17:51 purl Message for plobsing stored.
17:51 mikehh joined #parrot
17:53 Coke chromatic: if codestring is better for you, feel free to merge it back to trunk.
17:53 Coke (or I can, trying the --reintegrate option).
17:54 chromatic If the random segfaults are gone, that's fine.
17:54 Coke I thought those were a trunk thing.
17:54 chromatic Based on my timings, the version in the branch is faster than the version in the trunk.  The slowness is another step.
17:54 Coke ... I cannot parse that last sentence in the context of the first one.
17:54 Coke OH. the slowness is not the part we made faster. =-)
17:55 Coke what were you using? a build of nqp-rx?
17:55 chromatic The frozen strings merge.
17:55 GodFather joined #parrot
17:55 Coke darbelo: ... see that one change looks fine.
17:56 chromatic If you time building Rakudo's core.pir from Rakudo's core.pm, codestring is faster on the branch than in trunk.
17:56 Coke the two separately looked very very wrong.
17:56 chromatic If you time building perl6.pbc from Perl6Compiler.pir, trunk is several times slower.
17:56 Coke ah, just that one thing? mmkay.
17:56 chromatic CodeString is irrelevant to the latter.
17:56 dalek parrot: r46241 | darbelo++ | branches/codestring/src/pmc/codestring.pmc:
17:56 dalek parrot: Merge non-codestring changes from trunk.
17:56 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46241/
17:56 Coke ok. I think the diff on that should be similar with the recent merge from trunk.
17:56 dalek parrot: r46242 | darbelo++ | branches/codestring/src/pmc/codestring.pmc:
17:56 dalek parrot: Merge codestring.pmc changes from trunk as a separate commit to ease review.
17:56 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46242/
17:56 dalek parrot: r46243 | darbelo++ | branches/codestring/src/pmc/codestring.pmc:
17:56 dalek parrot: Undo codestring mis-merges darbelo--
17:56 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46243/
18:09 Coke chromatic: I just tried timings with src/gen/perl6-grammar.pir when building rakudo:
18:09 Coke codestring built using no more than 1031M memory, took 2m0.007s; trunk took ~1400M memory, builtin 31s.
18:10 Coke (my machine may have other stuff going on, however.)
18:24 ash_ i found a bug in nqp
18:24 ash_ well, really diakopter++ found it in perl6, and the problem also exists in nqp
18:24 PerlJam random question: should nqp get its own RT queue?
18:24 ash_ > sub foo($i) { return { $i }; }; my $a := foo(1); my $b := foo(3); say($a(), $b());
18:24 ash_ 33
18:24 ash_ should be 13
18:25 Coke PerlJam: given the large overlap between rakudo & nqp devs atm... meh?
18:25 PerlJam The devs are the same, but the bugs are different.
18:26 PerlJam But I guess there's also the argument to be made that NQP *is* a dialect of Perl 6  :)
18:26 PerlJam anyway ... just a thought.
18:26 Coke <shrug> go for it. you'll need to manage 2 bugs queues and pull in ask & robrt.
18:27 PerlJam Coke: you've convinced me the bang/buck ratio is *way* off   :)
18:27 * PerlJam meeting &
18:28 ash_ how do you compile nqp into pir? parrot-nqp --target=pir filename.nqp > filename.pir  doesn't seem to work
18:28 ash_ well at least when i run that pir file i get errors saying things like it cant find sub say
18:29 chromatic I'm surprised it took that much memory.  It's only ever taken ~360M for me lately.
18:33 arnsholt ash_: I've had similar issues. I think say() disappears when you're in a namespace (or something like that)
18:33 arnsholt It works if you replace say() with pir::say()
18:33 ash_ well, running the file works fine with parrot-nqp
18:34 Coke .pm.pir: $(PARROT_NQP) --target=pir -o $@ $<
18:34 Coke ... with a newline after the :
18:35 Coke (from partcl-nqp's makefile)
18:36 Coke ash: (with formatting:) http://github.com/partcl/partcl-nqp​/blob/master/build/Makefile.in#L56
18:41 dukeleto 'ello again
18:41 dukeleto how long until #ps ?
18:41 * dukeleto is in a different timezone and a bit lagged in general
18:41 bubaflub dukeleto: isn't ps on tuesdays?
18:42 dukeleto bubaflub: like I said, I am lagged :)
18:42 bubaflub haha.
18:42 bubaflub or from the future
18:42 bubaflub Great Scott!
18:42 dukeleto 1.21 gigawatts!?!
18:42 dukeleto bubaflub: congrats on getting the RTEMS project
18:42 bubaflub woo hoo!
18:42 dukeleto bubaflub: that is gonna be all kinds of fun
18:42 bubaflub i know, right?
18:43 dukeleto bubaflub: i am in NY for work, so I have not been keeping up with everything
18:43 bubaflub i'll need to eventually patch the makefile to handle out of directory builds for parrot
18:43 dukeleto bubaflub: have you been talking to the RTEMS guys?
18:43 bubaflub dukeleto: new job or just travel?
18:43 bubaflub dukeleto: yep.  i've got VirtualBox up and running and all the stuff built correctly already.
18:44 dukeleto bubaflub: new job. I work for http://solgenomics.net/ now. they are a research institute at cornell university
18:44 bubaflub ahhhhh cool.  bio stuff?
18:44 dukeleto bubaflub: there is a branch to handle out of dir builds, but it is only semi-function now
18:45 dukeleto bubaflub: yep. it is mostly the tomato genome project, but they are actually studying all of the Solanacaea family, which includes lots of plants
18:45 dukeleto bubaflub: they are mostly a Perl+Postgres shop, so it is right up my alley
18:45 bubaflub oh nice!
18:46 dukeleto bubaflub: how is your bonding period going? are you feeling covalent yet?
18:46 atrodo That's very nice
18:46 bubaflub dukeleto: heh.  i think most of the guys are in a separate time zone.  i'll get my bonds on a bit more after next week
18:46 * darbelo feels bound.
18:46 bubaflub finals--
18:47 dukeleto my new job is 100% telecommute as well (except for a few trips per year to the mothership). /me likes telecommuting
18:47 dukeleto darbelo: that is good to hear
18:47 bubaflub dukeleto: nice.  i had that for a bit last year, but switched to something local
18:47 bubaflub now i'm thinking about going back to telecommuting
18:48 dukeleto i am glad both of your are previous GSoC students and know the ropes. Less work for me :)
18:49 dukeleto May 24 is the end of the bonding. Wow, they sure did make the bonding period longer this year. We need to take advantage of that
18:50 bubaflub dukeleto: yeah.  it's pretty nice;  good amount of time after my finals to really dig in
18:52 dukeleto bubaflub: you will enjoy working with the RTEMS guys, they are very cool. I met Joel Sherril and Chris Johns at last years GSoC mentor summit
18:53 dukeleto bubaflub: and parrot+rtems has potentially far-reaching implications for both communities
18:53 bubaflub dukeleto: parrots in space!
18:53 dukeleto bubaflub: and not many people get to say that their code will run in space :)
18:53 dukeleto eggzactly
18:53 bubaflub bwahahaha
19:13 ash_ joined #parrot
19:45 Coke ... anyone using addrregistry?
19:45 chromatic Parrot_pmc_register.
19:46 chromatic src/interp/inter_create.c lines 269 and 270.
19:46 Coke ... why is that on the list to move to dynpmcs, then?
19:47 Coke (if it's used by our GC ?)
19:47 chromatic I have no idea.  I objected to that long ago.
19:47 Coke chromatic: could you object on the ticket?
19:47 Coke TT # 448
19:47 chromatic I responded via email.
19:48 Coke whoops.
19:48 Coke oh, hey, refresh, there it is. =-)
19:48 Coke chromatic++
19:50 Coke also, addrregistry has only the bare minimum of tests.
19:50 Coke but that woudl be a new ticket. =-)
19:58 jsut joined #parrot
20:08 dalek parrot: r46244 | coke++ | trunk/DEPRECATED.pod:
20:08 dalek parrot: Reflect current state of TT #448
20:08 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46244/
20:09 joeri joined #parrot
20:13 Coke chromatic: any object to whittling the list down to just file and OS?
20:16 Coke *objection
20:19 cotto_work joined #parrot
20:22 ash_ how do you dump a var in pir? _dumper?
20:29 Coke you have to load it first, but yes.
20:30 Coke here's a macro that does it: http://github.com/partcl/partcl/​blob/master/src/macros.pir#L257
20:31 Coke file needs a .str file; dynpmcs don't seem to support this yet.
20:33 * Coke wonders what the point of dynpmc singletons is.
20:33 * Coke guesses 'encapsulation'
20:34 Coke ahahaha. File is used by pbc2exe.
20:36 Coke msg moritz: when rakudo starts saying that it can't instantiate File and OS pmcs, insert a pir::loadlib('file'); pir::loadlib('os');
20:36 purl Message for moritz stored.
20:37 eternaleye joined #parrot
20:40 ash_ how does capture_lex work?
20:47 Coke I don't know, but if I wanted to check, I'd like in src/ops/*.ops for the opcode source.
20:47 Coke s/like/look/
20:48 Coke which points to src/sub.c line 593.
20:48 Coke note to cage cleaners, there's an "#if 0" just after that.
20:50 Coke (ingore my previous str rant. dynpmcs need to be declared as dynpmcs, just mv'ing them doesn't help. =-)
21:05 lucian_ joined #parrot
21:26 cotto_work joined #parrot
21:32 mikehh joined #parrot
21:32 jsut_ joined #parrot
21:33 chromatic joined #parrot
21:39 dalek plparrot: ca5e9ac | (Joshua Tolley)++ | Makefile:
21:39 dalek plparrot: Fix typo
21:39 dalek plparrot: review: http://github.com/leto/plparrot/commit/c​a5e9acc3bf5395c950ea5ee112fd92bbec6693a
21:43 Tene joined #parrot
21:46 bacek ~~
21:46 bacek Good morning, humans
21:48 humans Good morning, bacek
21:49 bacek :)
21:49 bacek chromatic, around?
21:50 ash_ how does capture_lex know what to capture?
21:52 ash_ i think there is a problem with capture_lex (or a possible problem)
21:53 chromatic I'm here.
21:53 bacek ash_, in nutshell - it iterates over :outer subs chain and capture every lex in current frame.
21:53 bacek chromatic, http://nopaste.snit.ch/20451
21:53 bacek chromatic, can you check output of nopasted pir?
21:54 chromatic not ok 6
21:55 bacek sigh...
21:55 bacek lexicals are broken.
21:55 bacek comment out .return and rerun it
21:55 chromatic Interesting.
21:55 ash_ http://gist.github.com/388632 is the bug i am referring too
21:56 chromatic 002a new P0, "String"                                        P0=PMCNULL
21:56 chromatic 002d assign P0, "ok 6"                                        P0=String=PMC(0x9d82604 Str:"")
21:56 chromatic 0030 find_lex P4, "ANOTHER"                                        P4=PMCNULL
21:56 chromatic 0033 say P4                                        P4=String=PMC(0x9d825a0 Str:"not ok 6")
21:56 chromatic not ok 6
21:56 chromatic 0035 set_returns PC4 (1), P6                                        PC4=FixedIntegerArray=PMC(0x9db306c) P6=PMCNULL
21:56 chromatic 0024 new P4, "String"                                        P4=PMCNULL
21:56 chromatic 0027 assign P4, "not ok 6"                                        P4=String=PMC(0x92ff5a0 Str:"")
21:56 chromatic 002a new P7, "String"                                        P7=PMCNULL
21:56 chromatic 002d assign P7, "ok 6"                                        P7=String=PMC(0x92ff604 Str:"")
21:56 chromatic 0030 find_lex P8, "ANOTHER"                                        P8=PMCNULL
21:56 chromatic 0033 say P8                                        P8=String=PMC(0x92ff604 Str:"ok 6")
21:56 Tene joined #parrot
21:56 bacek chromatic, exactly.
21:56 bacek It should output "ok 6" every time.
21:57 chromatic Look at the allocated registers.
21:57 chromatic Change the P-reg in the .return to something already seen.
21:57 purl chromatic: that doesn't look right
21:58 bacek But how it's related to output of previous line?
21:59 chromatic No idea.
21:59 chromatic Isn't that strange?
21:59 bacek Also, you can comment find_lex $P23, "IT" (for example).
21:59 bacek (Leave .return as is)
22:00 bacek It will output "ok 6"...
22:00 chromatic Change the return from $P32 to $P31 and the output is correct.
22:00 purl chromatic: that doesn't look right
22:00 bacek It's kinda weird...
22:00 bacek purl, forget change
22:00 purl bacek: I forgot change
22:00 cotto_work nice bug
22:03 bacek ash_, looks like your bug is same as mine...
22:04 chromatic Should we support using .lex on the same lexical name multiple times in the same scope?
22:05 ash_ hmmm i think i found some information related to my issue, http://trac.parrot.org/parrot/wiki/​Creating%20Closures%20with%20NQP-rx seems to work properly, which I wouldn't expect when you look at the issue I was having
22:05 ash_ that has a hand crafted pir::newclosure__PP op though, which I think might be nice if it was automattically done for you, at least in nqp
22:05 bacek chromatic, why not?
22:06 bacek 0032 find_lex P4, "ANOTHER"                                        P4=PMCNULL
22:06 bacek Breakpoint 2, Parrot_find_lex_p_sc (cur_opcode=0x8102df0, interp=0x8051040)
22:06 bacek at src/ops/var.ops:114
22:06 bacek 114
22:06 bacek (gdb) s
22:06 bacek 95    STRING  * const lex_name = $2;
22:06 bacek (gdb) n
22:06 bacek 96    PMC     * const lex_pad  = Parrot_find_pad(interp, lex_name, ctx);
22:06 bacek (gdb) p lex_name
22:06 bacek $1 = (STRING * const) 0xb7e8eb7d
22:06 bacek (gdb) p *lex_name
22:06 bacek $2 = {flags = 1435550665, _bufstart = 0xec83e589, _buflen = 138775320,
22:06 bacek strstart = 0xc708508b <Address 0xc708508b out of bounds>,
22:06 bacek bufused = 201598020, strlen = 2298478592, hashval = 2466194436,
22:06 bacek encoding = 0x84, charset = 0x5590c3c9}
22:06 bacek holy shit...
22:06 purl only in the Vatican, my friend.
22:06 bacek We do need to rework packfiles...
22:06 chromatic I could characterize double .lex declaration as a bug.
22:07 bacek When we unpack non-constant string in ImageIO thawed Strings have PObj_external_FLAG set.
22:07 chromatic Why are they not constant?
22:07 bacek They are.
22:07 bacek But problem is - we move buffers behind them.
22:08 chromatic I added the external flag to STRING thawing from PBC so we didn't have to allocate buffers.
22:08 bacek chromatic, and it's wrong if Buffer isn't constant.
22:08 chromatic Assuming the PBC is still in memory, that should be okay.
22:09 bacek check runtime/parrot/library/config.pir
22:09 bacek We read content into normal String, thaw it, free content.
22:09 bacek Bang.
22:09 chromatic That'd do it.
22:10 chromatic Can we detect when that optimization is safe?
22:11 chromatic Do I have any Thai food in the fridge?  oh yes!
22:11 bacek Not with current PackFile API...
22:12 bacek (Removing external flag doesn't help in this case... $1 still garbage in last find_lex)
22:12 bacek And this string come directly from IMCC... Not from PBC.
22:13 davidfetter mmm...thai fudz
22:13 bacek Actually, all constant strings looks like a garbage.
22:15 ash_ http://gist.github.com/388632 i got nqp to function as expected, well, sorta, i had to coerce it to
22:17 cotto_work ash_: http://trac.parrot.org/parrot/wiki/​Creating%20Closures%20with%20NQP-rx
22:17 ash_ i saw that
22:17 ash_ is there a reason nqp-rx doesn't do newclosure automattically?
22:18 chromatic I hate to remove that optimization, but until we know when we can use it correctly....
22:19 Austin ash_: Probably because it's expensive, and not always needed. (Expensive, both in performance terms and in terms of patrick's time to implement.)
22:20 ash_ but if its the wrong behavior?
22:20 Austin Wrong how?
22:21 ash_ http://gist.github.com/388632 for instance
22:22 ash_ you can't curry in nqp unless you specifically call newclosure, i know its a known issue in rakudo too, but maybe its not something that should be fixed in nqp-rx?
22:23 Austin What's wrong with that?
22:23 Austin You have different source code, you get different answers.
22:23 ash_ sorry, thats probably confusing
22:23 ash_ one sec
22:24 Austin It's not confusing. In fact, I kind of like the way you pass the block as a parameter to newclosure. That's clever.
22:25 ash_ yeah, but you shouldn't have to manually call newclosure
22:25 Austin Heh. You're in the wrong channel, dude.
22:26 * davidfetter mischans to keep ash_ company
22:26 ash_ i never know where to go for nqp issues ><
22:26 Austin Heh.
22:27 Austin This isn't an nqp issue. :)  If you want automatic closures, you should be in #perl6.
22:27 Austin :)
22:27 tcurtis joined #parrot
22:31 ash_ its not a nqp issue? because that is kinda unexpected behaviour for nqp, but maybe i am to influenced by perl6...
22:32 darbelo Crap. Forgot to squash.
22:32 Austin Remember what the NQ stands for.
22:33 ash_ yeah, true
22:33 ash_ but why even have closures in nqp then?
22:33 darbelo dalek is going to be quite spammy ina bit...
22:33 Austin There's no spec for nqp, other than "nq", so it's only an NQP defect if it prevents you from being able to do something. Since there's a pretty obvious work-around, this isn't much of a blocker..
22:33 Austin Because they're almost free?
22:34 dalek parrot: r46247 | darbelo++ | trunk/src/sub.c:
22:34 dalek parrot: Remove '#if 0' from src/sub.c
22:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46247/
22:34 Austin Patrick is a pretty smart guy, and he's involved with p6 as well as nqp. So if he happens to "borrow" some design bits for nqp, and closures are almost free, then it's a win.
22:34 dalek parrot: r46248 | darbelo++ | trunk/src/spf_render.c:
22:34 dalek parrot: Remove '#if 0' from src/spf_render.c
22:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46248/
22:34 dalek parrot: r46249 | darbelo++ | trunk/src/runcore/cores.c:
22:34 dalek parrot: Remove '#if 0' from src/runcore/cores.c
22:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46249/
22:34 dalek parrot: r46250 | darbelo++ | trunk/src/packfile/pf_items.c:
22:34 ash_ it seems odd though that you have to be aware of the underlying implementation if you expect closures to function in the way they do in other languages, thats my gripe, but maybe its not an issue?
22:34 dalek parrot: Remove '#if 0' from src/packfile/pf_items.c
22:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46250/
22:34 dalek parrot: r46251 | darbelo++ | trunk/compilers/imcc/pbc.c:
22:34 dalek parrot: Remove '#if 0' from compilers/imcc/pbc.c
22:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46251/
22:34 dalek parrot: r46252 | darbelo++ | trunk/src/pmc/bigint.pmc:
22:34 dalek parrot: Remove '#if 0' from src/pmc/bigint.pmc
22:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46252/
22:34 dalek parrot: r46253 | darbelo++ | trunk/src/interp/inter_create.c:
22:35 dalek parrot: Remove '#if 0' from  src/interp/inter_create.c
22:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46253/
22:35 dalek parrot: r46254 | darbelo++ | trunk/src/interp/inter_cb.c:
22:35 dalek parrot: Remove '#if 0' from  src/interp/inter_cb.c
22:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46254/
22:35 dalek parrot: r46255 | darbelo++ | trunk/src/debug.c:
22:35 dalek parrot: Remove '#if 0' and nearby commented out code from src/debug.c
22:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46255/
22:35 dalek parrot: r46256 | darbelo++ | trunk/compilers/imcc/cfg.c:
22:35 dalek parrot: Remove '#if 0' from compilers/imcc/cfg.c
22:35 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46256/
22:35 * Austin shrugs.
22:35 Austin At least you aren't coding in assembly.
22:35 ash_ true
22:36 darbelo Aw. C'mon, assembly's *fun*.
22:37 ash_ i like to abstract away my assembly with a few layers of indirection, personally :P
22:37 darbelo That's what C is for, yes.
22:37 darbelo ;)
22:38 cotto_work darbelo: did you check if any of those #if 0 pieces were worth keeping?
22:40 darbelo cotto_work: Not really. The few I looked at were out of sync enough with the surrounding code that they weren't worth keeping.
22:40 darbelo Or amounted to little more than the comments surounding them.
22:40 cotto_work fair enough.  bitrot can set in pretty quickly.
22:41 darbelo The upside of me forgetting to squash the commits is that now you can review/revert separately!
22:42 cotto_work are you using git-svn?
22:42 darbelo I'm trying it out, yes.
22:44 darbelo After merging my last branch with svn, I'm not confident in svn's ability to carry me through GSoC in a branch.
22:45 cotto_work I found some information that started to look like it'd give me a solution to the merge problem.
22:45 cotto_work I haven't gotten far enough to figure out if it'll work or if it's the info I'll need.
22:45 darbelo Does it make svn 4x faster when merging?
22:46 cotto_work I'm going for "doesn't leave me with a broken and useless checkout".
22:47 darbelo I had to sit through an endless parade of mergeinfo updates and resolve a big wad of self-inflicted tree conflicts for a merge that edited three files.
22:48 cotto_work I'm going to try to put more effort into making svn work.  If nothing else, I'll at least have a more legitimate gripe with it.
22:48 cotto_work Being able to merge would certainly be a bonus.
22:50 darbelo Well, to be fair, svn *merged* in my case. It just took me less time to patch/add/remove/ the files by hand.
22:51 darbelo Oh, and that yielded me 0 conflicts! It was, overall, a lot less effort.
22:51 darbelo So, doing stuff by hand is easier than using the tool. That means I don't need the tool.
22:56 darbelo Full disclosure: I'm not a git apologist either. It's just hurt me less so far.
22:57 bacek I'm not git apologist either.
22:58 bacek Git is just "right tool for the job"
22:58 bacek At least for now.
22:59 darbelo It maps better to my workflow, at the very least.
22:59 chromatic Same
23:07 dalek parrot: r46257 | chromatic++ | trunk/tools/docs/filename_and_chapter.pl:
23:07 dalek parrot: [tools] Made tools/docs/filename_and_chapter.pl compile again, then removed the
23:07 dalek parrot: unnecessary prototype and cleaned up some clunky code.
23:07 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46257/
23:14 mikehh tools/docs/filename_and_chapter.pl FAILs perlcritic - Subroutine prototypes used at line 14 and 70
23:14 mikehh all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#33614), fulltest) at r46256 - Ubuntu 10.04 amd64 (g++)
23:16 mikehh bah - forgot to commit
23:16 chromatic I just fixed that anyway.
23:20 mikehh I noticed :-}
23:20 mikehh BTW why does headerizer NOT remove stuff - it only seems to add
23:21 sorear Coke: Hi
23:21 purl niihau, sorear.
23:22 darbelo mikehh: Nobody patched it to remove ;)
23:22 mikehh maybe it should start with a clean slate
23:23 * darbelo holds up a sign with 'patches welcome' scrawled on it.
23:23 dalek parrot: r46258 | mikehh++ | trunk/src/packfile/pf_items.c:
23:23 dalek parrot: fix codetest failure - unused assertmacros (headerizer does not seem to remove definitions/macros)
23:23 dalek parrot: review: http://trac.parrot.org/parrot/changeset/46258/
23:24 mikehh maybe you should do the sackcloth and ashes bit :-}
23:28 * mikehh remembers looking at it when we did the PCC hackathon a while back
23:33 Whiteknight joined #parrot
23:33 cotto_work g'day Whiteknight
23:38 cotto_work This is odd.  Someone hacked out a C to HLL (Lisp, C, Lua, js, Java) compiler. http://cluecc.sourceforge.net/
23:38 Whiteknight hello cotto_work
23:45 tcurtis cotto_work: The really odd part of that is the C to C-without-integers-or-single-floats compiler.
23:45 sorear not particularly
23:45 sorear if you want to target lua...
23:56 tcurtis Why compile C to C at all, though?
23:58 cotto_work There's a similar project called CIL that compiles C to a subset of C.
23:59 cotto_work cil?
23:59 purl somebody said cil was the .NET assembly language. or C Intermediate Language or http://hal.cs.berkeley.edu/cil/

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

Parrot | source cross referenced