Camelia, the Perl 6 bug

IRC log for #parrot, 2008-04-01

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 cotto_work Infinoid, yes afaict
00:00 Infinoid the patch looks awesome, but I'm wondering if it will catch some extra headers you didn't want
00:01 Infinoid guess if it builds, that's proof that it didn't. :)
00:06 Coke why don't I want *all* the headers?
00:06 Coke the pmc's depend on parrot/parrot.h - if that isn't included...
00:06 Coke that patch is borked, btw. moment.
00:07 Infinoid Coke: depending on things in /usr/include/ is bad
00:08 Coke http://pastebin.com/d18e2f195
00:08 Infinoid (especially if you then prepend a "src/pmc/" to them)
00:09 Coke ok. moment.
00:09 Infinoid don't worry too much... if everything built, that means nothing depends on external headers, which is a good thing
00:09 Coke nothing does.
00:09 Coke but moment.
00:15 Sartak joined #parrot
00:17 Coke one of these depends on a .str file.
00:21 Coke one of them includes ../src/io/io_private.h - where is that path relative from?
00:22 Infinoid relative to the location of the source file
00:22 Infinoid (or header file, whatever file contains the #include line)
00:23 Coke that's in one of the pmcs.
00:23 Coke src/pmc/../src/io/io_private.h isn't right. =-)
00:23 Infinoid yeah, that does look wrong
00:23 Coke but it must compile or we'd have seen it before, neh?
00:24 Coke oh. duh, it's relative to ./include
00:25 Infinoid is it split out by pmc2c?
00:25 Infinoid or just relying on the -Iinclude?
00:26 darbelo joined #parrot
00:26 Coke the latter
00:26 purl the latter is better
00:27 rdice joined #parrot
00:27 Coke http://pastebin.com/de49c558 has an updated patch that builds on linux.
00:28 Coke otto... I'm working on this right now.
00:28 cotto_work thanks
00:29 Coke oh, that's from 6 hours ago. =-)
00:30 Coke cotto_work: try that patch.
00:30 Coke that generates a proper dep line for src/pmc/role.o
00:30 Coke (testing on windows...)
00:32 cotto_work did you notice that most of those includes are unnecessary/redundant?
00:33 Coke nope! =-)
00:33 Coke checking.
00:33 Coke like what?
00:33 Coke include/parrot/parrot.h ?
00:35 cotto_work all the pmc_* includes except pmc_{object|class}.h in {class|object}.pmc
00:35 cotto_work parrot make and make test run fine if all the other includes are commented out
00:35 cotto_work s/parrot//
00:36 Infinoid cotto++
00:36 Coke just because it's a dep on a static file doesn't mean it's not a dep.
00:36 Coke I'm putting in *all* the missing deps that file has, regardless of whether it's a generated file or not.
00:37 Coke doesn't matter for joe-parrot-builder, but for a developer who is changing one of the included .h files, that's important.
00:38 Infinoid for build deps, sure, but isn't cotto talking about the #include lines themselves?
00:39 Coke that's SEP. =-)
00:39 cotto_work yes, I'm talking about the explicit #includes in the .pmc files
00:39 Infinoid ok.  but if it doesn't include the other file, it doesn't need a build dep either
00:39 Coke well, if those are removed, then the deps will vanish the next time someone builds the makefile. =-)
00:40 Infinoid ok :)
00:40 particle joined #parrot
00:41 tetragon Bleh, parrot stopped building
00:42 Coke recent revision? what os?
00:42 tetragon OS X 10.5.2, ppc
00:42 tetragon Current rev
00:42 Coke can you nopaste/pastebin the build error?
00:43 tetragon And I know the manual changes I have to do to the makefiles didn't kill the missing rule
00:43 Coke I did just change somethign that gens the makefile, so it's a likely culprit.
00:43 Coke which revision?
00:43 Coke (i mean, do you have a before and after?)
00:44 Coke particle: can you test something for me on windows? applying a patch is murder.
00:44 particle k
00:44 tetragon Just after, it built a couple days ago
00:44 Coke http://pastebin.com/de49c558
00:45 tetragon http://pastebin.com/m47e4d2b8
00:45 Coke tetragon: you shouldn't be compiling jit at all, methinks.
00:45 tetragon I'm not explicitly telling it to do that
00:46 Limbic_Region Coke - I have access to Win32/MinGW and Win32/Cygwin if testing all variations is required
00:46 Coke I figured, but I'm fairly certain jit is still borked on ppc, so I'm not sure why it's building.
00:46 tetragon Hrm... some of the darwin stuff is using deprecated functions
00:46 Coke Limbic_Region: Doubtful, but if you're feeling paranoid...
00:47 Coke tetragon: yup. open ticket on that somewhere.
00:47 Coke (patches welcome, in a not at all snarky way.)
00:47 Limbic_Region nope, just offering what little contribution I provide these days
00:47 tetragon I was preparing to see if I could convince this thing to build without requiring manual Makefile edits
00:48 * tetragon grumbles about Apple's /usr/bin/perl being built as a universal binary
00:48 Coke tetragon: you shouldn't need manual edits at all. :|
00:49 Coke ah, is that why?
00:49 tetragon Back when builds still worked for me, it would trip over i386 assembly
00:49 Coke probably a matter of smartening up the darwin hints file to pick one or the other and not both.
00:49 cotto_work Coke, I'm not seeing any build failures so far.
00:49 tetragon Apple's perl includes '-arch i386 -arch ppc' in its build flags, which causes parrot to try to build itself as universal
00:50 particle coke: realcleaned, applied patch, configured, building now
00:51 Coke particle: danke.
00:55 particle build succeeds. testing now
00:56 * particle bets the t/configure tests are as repetitive as the t/steps tests
00:56 Coke particle: if the build worked, it worked.
00:56 particle sure. commit it. i'm still gonna test it :)
00:57 particle course, i can't test nmake -j
00:57 particle that's not a valid option :(
00:57 Infinoid hmm, I should test -j on mingw sometime
00:57 dalek r26678 | chromatic++ | trunk:
00:57 dalek : [GC] Fixed build for --gc=libc (Senaka Fernando, RT #52332).
00:57 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26678
00:58 * particle wonders when our svn revision will surpass our rt number
00:59 tetragon Coke: Some people would want both -arch flags
00:59 Coke tetragon: well, sure, if it built... but if it doesn't...
01:00 tetragon Coke: I haven't tested on my Intel yet...
01:00 tetragon Coke: I find universal builds tend to work there better than on ppc
01:00 cotto_work looks like the make race condition is gone
01:00 cotto_work as am I
01:01 cotto_work thanks for fixing that
01:01 dalek r26679 | coke++ | trunk:
01:01 dalek : [build]
01:01 dalek : Resolve #52316 ([BUG] undeclared dependency between role and namespace PMCs).
01:01 dalek : cotto++ for diagnosis.
01:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26679
01:02 * Coke goes to find the old open ticket about the darwin deprecation so he can merge the new bug with the old one...
01:08 particle # Trailing space or tab char found in the following files:
01:08 particle # C:\usr\local\parrot\trunk\config\auto\pmc.pm 131
01:08 * Coke grumbles.
01:13 * Coke can't find the old ticket he is sure that is a duplicate of. ah well.
01:15 Tene Coke: open a ticket about it.
01:16 Coke you funny. :p
01:17 Tene I certainly think so. :)
01:18 tetragon I found a build from a couple days ago.  It has jit built
01:19 dalek r26680 | coke++ | trunk:
01:19 dalek : [codingstd]
01:19 dalek : remove trailing whitespace introduced by myself and other villians.
01:19 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26680
01:21 Coke tetragon: hokay.
01:25 dalek r26681 | coke++ | trunk:
01:25 dalek : [oops]
01:25 dalek : Undo accidental commit included in  r26680. Villians, indeed.
01:25 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26681
01:52 * Coke wonders if anyone has thought about how we're going to do MMD without type ids.
01:53 grim_fandango joined #parrot
02:17 arbingersys joined #parrot
02:18 wknight8111 what is MMD?
02:18 purl i think MMD is the media database...do not hurt
02:18 wknight8111 thanks purl, you're a lifesaver
02:27 Infinoid purl: no, MMD is multi-method dispatch
02:27 purl okay, Infinoid.
02:28 wknight8111 Multi-method dispatch? looking that up now....
02:29 wknight8111 haha, it's reassuring when the documentation says "Part or all of this document is outdated"
02:29 Infinoid if you have multiple methods of the same name, MMD is the process of finding out which one to call, based on the types of arguments you've passed
02:29 wknight8111 oh. Suddenly I see what coke is worried about
02:30 wknight8111 without explicit data types, matching prototypes is going to suck mad nutz
02:30 Infinoid type ids would help, indeed
02:30 wknight8111 excuse my internet slang
02:30 Infinoid :)
02:30 Infinoid making MMD as easy (and foolproof) as possible would seem like a good thing, to me.
02:32 Infinoid purl, without explicit data types, matching prototypes?
02:32 purl well, without explicit data types, matching prototypes is going to suck mad nutz
02:32 Infinoid sorry, had to.
02:33 contingencyplan joined #parrot
02:42 dalek r26682 | duff++ | trunk:
02:42 dalek : [config] git URL might not be https and it might not be of trunk
02:42 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26682
02:42 grim_fandango_ joined #parrot
02:56 dalek r26683 | infinoid++ | trunk:
02:56 dalek : [raduko] minor change to pass t/codingstd/trailing_space.t
02:56 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26683
02:58 Infinoid Coke: should I check in your amd64 t/compilers/imcc/syn/regressions.t workaround?
03:02 * Infinoid doesn't want to paper over the fact that something is weird on amd64, but maybe the open ticket is enough.
03:23 wknight8111 what is weird about amd64?
03:24 wknight8111 i guess i haven't read enough bug reports yet
03:24 Infinoid something is being optimized differently enough to break a test
03:24 Infinoid see the last post on http://rt.perl.org/rt3/Tic​ket/Display.html?id=43048
03:26 Infinoid I'm not too familiar with IMCC (thankfully), but apparently all situations where the "div_i_ic_ic" was to be useful are supposed to have been optimized away.  so it was considered fair game to remove the op.  which uncovered the fact that apparently it isn't being optimized away on amd64, though everything seems great on x86
03:26 Infinoid or something like that.
03:27 wknight8111 that is weird that PIR would behave differently on the two platforms.
03:27 Infinoid sounds like a bug, doesn't it?
03:27 Ademan joined #parrot
03:28 wknight8111 maybe amd64 has some strange floating point bug, like a problem representing 0.0
03:28 wknight8111 of course, it's rarely productive to assume that the error lies in the hardware
03:28 Infinoid hah.  well, this is an Intel chip, so I wouldn't put it past them
03:29 wknight8111 i would like to see a hex dump of the floating point results out of the imcc parser, see if it's generating the proper values for 0.0
03:29 Infinoid I would have thought such a bug would have been discovered, advertized and worked around by now.
03:30 Infinoid but then again, very little of the stuff I do uses floating point at all.
03:30 Infinoid if you give me a command line I can run, I will run it
03:30 Infinoid (as I said, I'm IMCC-clueless)
03:31 wknight8111 i wouldn't know how to do it either, i'm not big on imcc internals either
03:31 Infinoid ./parrot --target=imcc-parse-results-thingy
03:31 wknight8111 and i dont have an amd64 laying around here, so i cant play with it
03:46 Infinoid that's odd.
03:46 Infinoid nopaste?
03:46 purl i guess nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://paste.husk.org/ or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or don't bother me while I'm eating
03:48 Infinoid http://rafb.net/p/w27OrL16.html
03:49 Infinoid apparently div_x_xc_xc is shorthand for a class of ops that includes div_i_ic_ic ?
03:50 Infinoid with -D I can see that parrot did attempt compile time constant folding, and got a real_exception (Divide by zero)
03:51 Infinoid so presumably it fell back on the runtime op
03:51 Infinoid and the same thing happened on x86, except for the runtime failure
03:55 Infinoid parrot's debugging flags aren't helping.  time for gdb...
04:10 Infinoid looks like gdb loves continuations almost as much as I do.
04:20 Infinoid ok.... here's where behavior starts to diverge
04:20 Infinoid compilers/imcc/parser_util.c line 648:         ins = IMCC_subst_constants_umix(interp, unit, name, r, n + 1);
04:21 Infinoid oops, try again
04:21 Infinoid compilers/imcc/parser_util.c line 653:         ins = IMCC_subst_constants(interp, unit, name, r, n + 1, &ok);
04:21 Infinoid both x86 and amd64 return NULL
04:21 Infinoid however, x86 sets &ok to 11, amd64 leaves it set to 0.
04:25 Infinoid I'm actually not sure whether that ok=11 thing was a stack smash, or somehow valid.
04:25 Infinoid longjmp--
04:30 liona29 joined #parrot
04:32 davidfetter joined #parrot
04:32 tetragon The make rule that my system is tripping over didn't exist a couple days ago
04:33 Infinoid which rule?
04:33 tetragon $(SRC_DIR)/exec_dep.c
04:33 * Infinoid fixed some Makefile stuff for "make -j", and possibly broke some other stuff
04:34 tetragon It works in i386 since the file src/jit/i386/exec_dep.c exists, but there is no file by an equivalent name for ppc
04:35 Infinoid and jit is somehow being detected on your platform, despite being ppc?
04:35 tetragon There is a jit directory for ppc and it built on the weekend
04:36 tetragon Anyway, the build is proceeding smoothly with the new rule commented out
04:37 tetragon And if an equivalent rule gets pumped out no matter which platform, I can already see that ARM'll break
04:37 Infinoid when in doubt, blame chromatic.  do you think it could have been r26636 ?
04:38 Infinoid that's where i386/exec_dep.c was created, and a corresponding ppc/exec_dep.c wasn't.
04:38 Infinoid and that's where the rule was added, too
04:39 tetragon Build didn't complete, fell over the missing object exec_dep.o
04:39 Infinoid http://www.parrotvm.org/svn​/parrot/revision?rev=26636
04:40 tetragon Looks like chromatic can be blamed
04:40 tetragon That commit appears to fit the bill
04:40 Infinoid svn merge -r26636:26635 .
04:40 Infinoid if that fixes it, flame away :)
04:41 Infinoid (you'll need a realclean/reconfigure after that)
04:42 tetragon The majority of the commit looks to be moving exec_dep.h contents into exec_dep.c
04:43 * Infinoid looks at RT#47289
04:44 Infinoid aaw, I don't know that we can blame chromatic after all.  not fully, at least. :(
04:44 petdance joined #parrot
04:45 * Infinoid reopens it
04:46 * tetragon notes that her build is now at jit
04:49 Infinoid any luck?
04:50 tetragon I determined that I forgot to clean the tree sufficiently before that build
04:51 tetragon (Where that build is the one that had just reached jit)
04:51 tetragon At the very least, my -arch flag stripping is working
04:51 tetragon I don't have to edit every generated makefile in the tree to remove them
04:52 tetragon But I'm back at jit
04:52 Infinoid ok.  please post a followup to RT #47289 when you've finished your testing
04:52 tetragon It succeeded in building jit
04:52 tetragon Now I just have to wait the rest out
04:53 Infinoid I reopened that ticket and posted a description of the problem
04:53 chromatic joined #parrot
04:53 chromatic I think I can fix the JIT problem.
04:53 Infinoid great!
04:53 chromatic Which platform has the problem?
04:53 Infinoid ppc
04:53 chromatic Good.
04:54 tetragon There are others that do, but not encountered yet
04:55 Infinoid good luck with it, I'm outta here.
04:55 Infinoid thanks for the quick response, chromatic
04:56 chromatic You're welcome.
04:56 tetragon With that merge, parrot built
04:56 jrockway joined #parrot
04:56 chromatic It looks like ARM will also have the problem.
04:58 tetragon The ARM I have laying around has neither Perl nor gcc on it
05:00 chromatic I know what the problem is there too, fortunately.
05:00 chromatic r26684 should work unmodified for you.
05:00 tetragon The appropriate .c files weren't created?
05:00 dalek r26684 | chromatic++ | trunk:
05:00 dalek : [JIT] Fixed the JIT build on PPC accidentally broken in r26636.  This also
05:01 dalek : finishes more of what RT #47289 tried to accomplish.
05:01 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26684
05:03 chromatic Right.
05:03 tetragon I'll test in a few minutes, need to relocate my computer
05:05 dalek r26685 | chromatic++ | trunk:
05:05 dalek : [JIT] Fixed the JIT build on ARM accidentally broken in r26636.  This also
05:05 dalek : finishes more of what RT #47289 tried to accomplish.
05:05 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26685
05:14 tetragon joined #parrot
05:21 tetragon chromatic: Build failed
05:22 tetragon Syntax error
05:24 tetragon http://pastebin.com/m4f813132
05:24 tetragon I'm taking a quick look at it
05:25 chromatic Me too.
05:27 tetragon Is it just me, or do both clauses of #if JIT_CGP in exec_dep.h have identical contents
05:28 chromatic What if you include "jit.h" in src/jit/ppc/exec_dep.h?
05:28 chromatic Good catch.
05:28 tetragon Same error, error message line numbers offset by one
05:29 chromatic How about also jit_emit.h?
05:30 tetragon Same error, offset two
05:32 chromatic It doesn't understand Parrot_jit_info_t, but that's defined in jit.h.
05:33 chromatic Can you do 'make realclean; perl Configure.pl; make' again?
05:33 chromatic make -j <n> should be fine
05:33 tetragon Don't worry, this little ppc only has one cpu
05:33 chromatic Still goes faster this way.
05:34 tetragon On this box, the thing that recently sped it up the most was tweaking it to automatically strip out the -arch flags it got from Perl 5
05:39 tetragon Same error
05:39 chromatic Bizarre.
05:39 purl vous avez dit "bizarre" ?
05:40 chromatic oui
05:42 chromatic I'll have to pull out my PPC and try it then.
05:42 ewilhelm when did parallel make start working?
05:42 tetragon Grr... When I went from "make -j2" to a plain old "make" it decided to rebuild
05:42 tetragon (Not rebuild as in start working)
05:43 chromatic Infinoid and Coke made it work in the past couple of days.
05:43 tetragon Actually, I'm trying a change to the file that I think will fix it
05:43 ewilhelm sweet.  Infinoid++; Coke++
05:44 * ewilhelm mentions distcc
05:45 chromatic Yeah, if you want to have multiple machines running simultaneously.
05:45 ewilhelm heh, does it work on ppc?
05:46 ewilhelm you could get about 10 of those for $200 now or so right?
05:46 chromatic If you want to burn that much electricity yeah!
05:46 tetragon And i386 works?
05:47 chromatic Yes.
05:48 ewilhelm (hmm... put a cross-compiler on your real machine and use the ppc just for disk)
05:49 chromatic Scratch-that Computing indeed!
05:50 tetragon It works now
05:51 tetragon I stuck #include "parrot/parrot.h" into exec_dep.c
05:52 tetragon http://pastebin.com/m7bddf9d2
05:52 chromatic That's all it took?
05:53 tetragon Yes
05:53 chromatic Alright, I'll patch the other files.
05:53 tetragon Wait... linker failed
05:54 tetragon ld: duplicate symbol _ppc_flush_line in src/jit.o and src/exec_dep.o
05:55 tetragon The symbol is definitely in both, text section
05:56 chromatic It's in jit_emit.h
05:56 tetragon I'll remove that #include from exec_dep.h
05:57 tetragon Now the compile fails
05:57 chromatic Remove both includes from exec_dep.h and copy the #include block from src/jit/i386/exec_dep.c into src/jit/ppc/exec_dep.c
05:58 chromatic lines 18 - 22
05:59 tetragon compile succeeds
06:00 tetragon Looks like the link succeeded
06:00 chromatic Now the real test
06:00 chromatic TEST_PROG_ARGS=1 prove t/op/*.t
06:00 chromatic (provided you're using bash or a bash-workalike)
06:01 tetragon I'm on a Mac, I get bash by default
06:01 tetragon And I get a whole stack of failing tests
06:01 chromatic It was tcsh for a while.
06:01 tetragon They switched to bash a couple major releases ago
06:01 chromatic Er, I mean
06:02 chromatic TEST_PROG_ARGS=-j prove t/op/*.t
06:02 tetragon Not nearly as many failing tests
06:03 chromatic That's better.
06:03 tetragon I got one sigbus so far
06:03 chromatic Not too surprising.
06:03 tetragon Either in t/op/interp.t or t/op/jit.t
06:04 tetragon And one test unexpectedly succeeded
06:04 chromatic info.t?
06:04 chromatic debuginfo.t?
06:04 tetragon Need to run them individually
06:05 tetragon Neither
06:05 tetragon Wait, it was debuginfo
06:05 chromatic I'll apply these changes for PPC and ARM, and hopefully that'll solve the compilation problem everywhere.
06:06 tetragon And the sigbus was interp.t
06:07 tetragon And I got the same sigbus before these changes (and it's on a TODO test)
06:08 chromatic What's the TODO message?
06:08 tetragon not ok 3 - runinterp - works with printing # TODO something funky here
06:09 chromatic There's a forehead slapper.
06:09 dalek r26686 | chromatic++ | trunk:
06:09 dalek : [JIT] Really fixed JIT for PPC and ARM (thanks to Seneca Cunningham).
06:09 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26686
06:09 tetragon I can put up the trace
06:10 tetragon http://pastebin.com/m6db3bd3f
06:11 tetragon And the prove -v output
06:11 tetragon http://pastebin.com/m7593b46e
06:12 chromatic The constant string is invalid for some reason.
06:12 chromatic ... probably not getting copied correctly from the parent interpreter.
06:12 chromatic ... due to some crazy system-dependent weirdness.
06:12 chromatic ... because it works on x86.
06:13 tetragon You're the one on the funky little-endian box
06:13 TonyC joined #parrot
06:14 tetragon Time to drop some coredumps
06:14 chromatic I fully admit that the x86 is a patch on a patch on a patch on the 4004, which is the best engineering the '60s had to offer (despite coming out in the '70s), but might I just add that cross-platform arch-independent JIT sucks?
06:16 tetragon I now have a coredump of the crash
06:24 chromatic I'm pretty sure I know where it is.
06:24 chromatic Do you mind filing these crashes as bugs?
06:24 tetragon Even the TODOs?  I think I currently have seven of them
06:25 chromatic If they succeed, bring them up here.
06:25 chromatic Otherwise they're groovy.
06:26 tetragon Most of the sigbus crashes are on TODO
06:26 tetragon I don't think there are any non-TODO ones left
06:26 chromatic That's probably good... but we should probably fix them at some point.
06:26 chromatic How about this.
06:27 chromatic If there aren't any RT numbers in the TODO descriptions, file them and I'll add the ticket numbers.
06:27 chromatic That way we'll *know* know they're there, instead of just thinking knowing.
06:28 dalek r26687 | chromatic++ | trunk:
06:28 dalek : [pobj] Removed a blatant lie from the STRING struct comments.
06:28 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26687
06:31 teknomunk joined #parrot
06:38 tetragon I'm outright failing t/compilers/imcc/syn/regressions.t
06:38 tetragon The non-TODO fails, and the TODO crashes
06:39 chromatic Coke made some recent changes there.
06:39 tetragon The TODO already has an RT number on it
06:40 tetragon Someone else had that one crash
06:40 chromatic Excellent.
06:41 tetragon That ticket doesn't have a stack trace, though
06:41 tetragon (41097)
06:41 chromatic Feel free to reply with one if you like.
06:56 iblechbot joined #parrot
08:44 Psyche^ joined #parrot
09:33 dalek r26688 | kjs++ | trunk:
09:33 dalek : [NEWS] add news about added operators to NQP
09:33 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26688
09:34 dalek r26689 | allison++ | trunk:
09:34 dalek : [pdd] Completed the core architectural component of the Strings PDD. Still
09:34 dalek : adding API sections.
09:34 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26689
09:42 cognominal someone can add to the perl6 status that hash composer is missing and array composer buggy
09:43 skv joined #parrot
10:32 ruoso joined #parrot
10:57 kj joined #parrot
11:05 * diakopter notes that [the link to] feather is down.
11:07 dalek joined #parrot
11:08 PerlJam joined #parrot
11:08 wolverian joined #parrot
11:10 jonathan joined #parrot
11:10 pmichaud joined #parrot
11:11 Juerd joined #parrot
11:15 leo joined #parrot
11:40 kid51 joined #parrot
11:42 muixirt joined #parrot
11:48 contingencyplan joined #parrot
12:17 rdice joined #parrot
12:40 particl1 joined #parrot
12:41 Infinoid joined #parrot
13:06 wknight8111 joined #parrot
13:21 skids joined #parrot
13:29 IllvilJa joined #parrot
13:37 gryphon joined #parrot
13:41 ask joined #parrot
13:42 ruz joined #parrot
14:29 wknight8111 is parrotcode.org down?
14:30 pmichaud looks like the dns was hacked
14:31 pmichaud pmichaud@orange:~$ nslookup parrotcode.org
14:31 pmichaud Server:         192.168.1.1
14:31 pmichaud Address:        192.168.1.1#53
14:31 pmichaud oops, wrong address -- never mind
14:31 pmichaud <-- tired
14:32 pmichaud ping works to parrotcode.org, but no response on port 80
14:33 wknight8111 ok
14:53 Coke someone volunteer to report the issue (after verifying) to webmaster@perl.org ?
14:54 dalek r26690 | coke++ | type_ids:
14:54 dalek : [tools]
14:54 dalek : parrotbug requires a configure'd parrot to work. Be more gentle when
14:54 dalek : informing the users about it.
14:54 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26690
14:54 PerlJam I just loaded www.parrotcode.org just fine.
14:58 Coke particl1: does parrotbug ``work'' on windows?
14:58 sjansen joined #parrot
14:59 Coke (or anyone else with windows. =-)
14:59 Coke If so, I think we can resolve RT41601
15:00 particle i guess i should ttake a look...
15:00 peepsalot joined #parrot
15:03 * particle reconfigs and rebuilds
15:06 wknight8111 it appears to be working for me now
15:13 * Coke notes that parrotbug just needs a config.
15:13 particle ==> Sending message to recipient...
15:13 particle I am terribly sorry, but I cannot find sendmail, or a close
15:13 particle equivalent, and the perl package Mail::Send has not been installed, so
15:13 particle I can't send your bug report. We apologize for the inconvenience.
15:13 particle So you may attempt to find some way of sending your message, it has
15:14 particle so, i gotta get a module or two
15:14 Coke I assume it tells you where the file was saved?
15:14 particle i'll retry after installing them
15:14 particle yep, i must have been throttled away
15:14 particle So you may attempt to find some way of sending your message, it has
15:14 particle been left in the file 'C:\Users\particle\AppData​\Local\Temp\bugrep05840'.
15:15 particle that's the text of the message, but not any of the other info (category, severity, etc)
15:18 Coke presumably that's in the file.
15:19 Coke I'd say that's "working". =-)
15:19 * Coke finds another email address that might be the guy that owns the macport.
15:31 particle i've installed Mail::Send and am trying again
15:31 Theory joined #parrot
15:32 AndyA joined #parrot
15:33 particle ==> Sending message to recipient...
15:33 particle Died at C:/usr/bin/perl-5.10.0/site/lib/Mail/Mailer.pm line 284, <STDIN> line 7.
15:33 particle it's b0rk
15:36 Coke Ok. if you have time, a patch would be great, otherwise I can take a look at it at home at some point.
15:39 dalek r26691 | coke++ | trunk:
15:39 dalek : [docs]
15:39 dalek : "I am happy to report improvements for both cc and gcc since last time I
15:39 dalek : ran a full 'make test'." -- Andy Dougherty (RT #52376)
15:39 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26691
15:44 Andy left #parrot
16:07 * Debolaz tries to run a binary perl6 and gets a coredump in his face.
16:11 jan joined #parrot
16:19 pmichaud Debolaz: what platform?
16:22 Debolaz Well, it did work for some things, but when I tried to declare a class with a method it went up in flames.
16:22 Debolaz FreeBSD 7
16:22 pmichaud maybe try it with parrot perl6.pbc instead of the binary
16:23 pmichaud or submit it to rakudobug@perl.org
16:23 pmichaud and we can take a look
16:24 Debolaz perl6.pbc worked fine.
16:24 pmichaud hmmmm
16:24 pmichaud must be something to do with compile/link.  Or perhaps a GC issue.
16:24 pmichaud I'd definitely report it to rakudobug then
16:24 kj using pbc_to_exe-generated executable also blew up my squaak compiler once
17:03 davidfetter joined #parrot
17:07 Psyche^ joined #parrot
17:08 barney joined #parrot
17:15 dalek r26692 | bernhard++ | trunk:
17:15 dalek : Let svn ignore the generated, that is copied, file exec_dep.c.
17:15 dalek : Clean up exec_dep.c
17:15 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26692
17:42 Coke pmichaud: ping
17:43 Coke pmichaud: can you take http://rt.perl.org/rt3/Tic​ket/Display.html?id=44447 ?
17:44 Coke even if all you do is add a note about how to move forward?
17:45 barney joined #parrot
17:47 peeps[work] joined #parrot
17:48 pmichaud coke: sure, I'll take care of it.  :-)
17:51 pmichaud Done.
17:52 mncharity joined #parrot
17:52 Coke sehr gut, thanks.
18:02 * Coke now has 30 rt tickets.
18:04 Coke 44+751+95
18:04 purl 890
18:08 barney 45 + 751 + 95
18:08 purl 891
18:10 Coke barney: that should refer to the similar ticket for perl6.
18:15 mncharity hi.  I'm groveling over the PAST spec, and will likely leave a trail of comments as I go.  Questions/comments would be welcome and appreciated.  tnx.
18:19 mncharity in http://www.parrotcode.org/docs/pdd/pdd26_ast.html , Var scope() "package" refers to a possible 'namespace' attribute, which is otherwise unmentioned as a possible attribute of Var.
18:19 particle these are better sent to the list, so they're not forgotten.
18:20 dalek r26693 | bernhard++ | trunk:
18:20 dalek : [HQ9+]
18:20 dalek : No need to load non-existing 'hq9plus_group'.
18:20 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26693
18:21 Coke PS in 9
18:23 particle coke: i'll likely be a bit late
18:23 particle shower &
18:23 * Infinoid practices his inflection and tone.  "Berift of life, it rests in peace!  If you hadn't nailed it to the perch, it'd be pushing up the daisies!"
18:27 chromatic joined #parrot
18:27 chromatic #ps in 2
18:28 mncharity particle: re list post, please feel free?   the exercise of <get on some list to be able to post; write post; get off list to return to no-more-cluttered-current state> seems rather a misson creep.
18:29 Coke mncharity: yes, but you're more likely to get results if you inconvenience yourself instead of us. =-)
18:30 mncharity re pdd26_ast.html , similar issue with Var slurpy() mentioning a 'named' attribute, which is not otherwise documented as a possible Var attribute.
18:33 Tene Oh, wow, I'm here again during #ps.
18:34 mncharity re inconvenience, ah, ok - my purpose is synthesizing an IR node set I can use for a few weeks from kp6/redsix/STD5/PAST.  the "reports of PAST doc oddities" is a side effect.  well, not entirely, also an opportunity to hear "oh, that's gone now, we punted that because x".  but what gets done with the observations is out of my mission scope. ;)
18:35 mncharity they're basically fyi's.
18:36 particle mncharity: you don't need to join, you only need to mail p2 and wait for a moderator to approve
18:36 chromatic I'm still unclear as to the goal of redsix etc; mind enlightening me or at least attempting?
18:37 Coke particle: you back?
18:37 particle yep
18:38 PerlJam chromatic: to win!
18:38 PerlJam oh ... that's probably something different :)
18:39 mncharity chromatic: sure, let's see...
18:42 mncharity redsix was a 2006 quick (order month) implementation of p6 in ruby.  There's a history in http://svn.pugscode.org/pugs/mi​sc/pX/Common/redsix/2006/README , but basically, pugs had gotten stuck, so redsix was written as a non-haskell pugs, set up to boostrap into p6.
18:42 shorten mncharity's url is at http://xrl.us/biqr5
18:42 chromatic What do you get out of the bootstrap?
18:43 pmichaud mncharity: named is an attribute for all PAST nodes, not just PAST::Var.  (It may be undocumented, yes.)
18:43 pmichaud mncharity: you're correct that PAST::Var is probably missing documentation for the namespace attribute.
18:43 mncharity the project ran over my time budget, and pugs got unstuck for a while, so it became inactive.  it occasionally got dusted over the years, but basically hasn't been worked on since.  so that's redsix.
18:44 mncharity re 'named', ah, ok.  not just 'name', but 'named' too.  got it.
18:44 mncharity tnx
18:45 pmichaud I agree it's a lot to put on one character difference -- but I went with named to match the parrot calling conventions (which also uses "named")
18:45 pmichaud 'name' is the name of the variable or block
18:45 pmichaud 'named' is how it's referred as a named parameter in a call
18:46 mncharity re 'What do you get out of the bootstrap?', the ability to work in p6.  which is a much nicer language to write language implementation in than p5/ruby/common-lisp/smalltalk/etc/etc.
18:46 mncharity as well as being a nice target state.
18:46 chromatic You need to have a platform on which to run it though.
18:51 mncharity re need platform, indeed.  and in so far as some platform doesn't quite match the intended use, there is cost.  but there's also a world of effort invested in compilers for assorted languages, etc.  some platforms will no doubt give much better performance than others for different aspects of p6.  someone suggested yesterday a fortran backend for large-scale numerical computing. :)
18:51 chromatic Yeah, but someone has to write it.
18:52 mncharity re one character difference, oh, np, I was just repeating to make sure I understood.
18:52 mncharity re 'someone has to write it', or have written it.  indeed.
18:53 chromatic Is redsix such a platform then?
18:56 mncharity re 'goal of redsix etc', one etc is elf, my current focus.  it's a bootstrapped backend (using an external parser, while waiting for STD to become usable, to then become fully bootstrapped).  it's intent it to provide people the ability to start creating large-scale p6 programs.  pugs never quite got there.
18:56 chromatic What's the underlying platform?
18:57 PerlJam mncharity: Say I was such a person, how would I use elf to create large scale perl 6 programs?
18:58 mncharity re 'Is redsix such a platform then?', no.  a ruby backend might be interesting, because the ruby object model is looks to be close enough to p6 to be able to use it fairly directly, and thus with fairly low overhead.  but while some of the ideas from redsix might be recycled, the redsix codebase is dead.  fairly thoroughly dead now that elf is working.
19:00 mncharity re elf underlying platform, the current one is p5.  a Moose-ish p5 mostly.  but a derivative which trades some Moose foundation-for-correctness for a more-hackish-but-faster p5 code, has been suggested.
19:03 mncharity re 'how would I use elf to create large scale perl 6 programs', wait a few days? :)  http://svn.pugscode.org/pug​s/misc/elf/elf_c_src/README  shows how how elf_c, the most recent elf, compiles it self.  basically whole-program compilation of the mentioned p6 files.  the intent is to get that down to
19:04 mncharity something like ../elf_c -x -o ../elf_c1 ElfC.pm  .  but,
19:06 PerlJam mncharity: how much of STD does elf grok?  Or, put another way, what's missing?
19:06 mncharity the dialect of p6 supported is currently quite narrow and kludgey.  mostly characterized by "whatever was quick and easy for the bootstrap".  vague plan is modularize (so people can easily resume work on the backends they were pursuing before hitting kp6, or longer ago, pugs, limits), less icky IR which can be lived with for at least a few weeks,
19:07 mncharity and start churning out Prelude, backends focused on conformance rather than convenience, and beginning the slog through the test suite.
19:08 chromatic Do you plan to build everything that Perl 5 doesn't support but Perl 6 needs in Perl 6 then?
19:11 mncharity re 'how much of STD does elf grok', zip.  well, I haven't tested it - perhaps some code fragments.  but it's using STD_red, a copy of STD hand translated badly into ruby, as an external parser.  basically, as STD5 matures, it can become an alternate parser.  As it matures enough to be plausibly translated back into p6 (eg, "metholate2"), it can use that.  and in some distant day it may be up to parsing STD.pm directly.  But very not
19:11 mncharity hmm, that was a long entry.  if anyone got clipped, sing out.
19:11 chromatic "But very not..."
19:12 mncharity "But very not rsn."
19:12 kj joined #parrot
19:16 mncharity re "Do you plan to build everything that Perl 5 doesn't support but Perl 6 needs in Perl 6 then?", not I.  Big picture is I'd like to build most everything in p6.  p5 is not a backend which gives me warm fuzzies, but various other people care about it, and it was a plausible place to do the backend bootstrap.  my objective with elf is to get other people unstuck.
19:18 chromatic To get people unstuck and able to write Perl 6, you need an AST emitted from a working Perl 6 parser which runs on a working Perl 6 backend?
19:19 mncharity yes.  no?
19:20 allison joined #parrot
19:21 Infinoid allison: just curious, what's the timeline for concurrency?  do we currently do any multithreading?  (I'm wondering how effective our testing of Harmony GC will be.)
19:21 PerlJam mncharity: I think you're falling into the same trap as other implementations have.  "I'll do all this work so that we can get a minimal Perl 6 going and *other people* can finish it off"  is the impression I get from you now.
19:22 allison Infinoid: yes, we're currently multi-threaded
19:22 allison Infinoid: so what we're doing now is implementing the final spec, mainly a matter of refinement and cleanup
19:23 Infinoid great, thanks.
19:24 allison Infinoid: I don't know if Harmony's GC is going to work with Parrot, it may be too custom to Java's needs to be useful, but it's worth experimenting
19:24 Infinoid it sounds like they are actively trying to make it standalone.  The question is how big the adaptation layer needs to be, right?
19:25 chromatic ... and how it finds live objects.
19:25 allison Infinoid: yes, well, or if an adaption layer is even possible
19:25 allison Infinoid: it depends on how great the mismatch of assumptions is
19:25 Debolaz It was mentioned earlier that it was at least hoped that version 1.0 of parrot would be ready this year, but when is it expected to be possible to write "real" applications with rakudo, even if not officially condoned and maybe with unstable results?
19:26 kj Debolaz: at least you can use the NQP Perl 6 subset :-)
19:26 Infinoid is parrot's 1.0 tied to raduko?
19:26 allison Infinoid: I suggested to the SoC student that he focus on developing Harmony's API for as a pluggable GC. That alone is a huge summer project
19:27 Debolaz Infinoid: Bound and gagged. :-P
19:27 pmichaud Debolaz: I expect people to be able to write "real" applications with rakudo by this summer
19:27 pmichaud it would help if we knew what features are needed-but-missing
19:27 pmichaud (i.e., for prioritizing)
19:28 allison Infinoid: well, having a usable implementation of 2 major languages is one of the 1.0 goals
19:28 allison Infinoid: currently rakudo and pynie are our top candidates
19:28 mncharity re trap, the hypothesis is indeed something like "the reason people are no longer writing p6 is the same reason *I* haven't been - you can't.  attempting non-small code in pugs becomes an exercise in working around pugsbugs, which on the inactive codebase, can't actually be fixed.  and kp6 is painfully slow (plus perhaps a couple of other issues)" plus the hypothesis
19:29 Infinoid allison: well, I'll make sure he doesn't get blocked on the parrot side of things :)
19:29 Infinoid you're right, though, it does sound like a lot of work.
19:30 Debolaz pmichaud: So you would encourage me to try implementing things with rakudo and bitch about it when it doesn't work? :) (Or at least make a note of it:)
19:30 chromatic I'm not sure about it being that much work.  A good GC only has a couple of entry and exit points in its API.
19:30 pmichaud Debolaz: yes, if you can handle a little frustration at times :-)
19:30 allison Infinoid: many thanks
19:30 mncharity "if you create a p6 implementation in which people can pursue the things they have already demonstrated interest in pursuing, but give them happy pragmatics (speed, easy customization and stability), then they will return and resume their work".
19:31 pmichaud Debolaz: unfortunately I've been distracted by non-rakudo items for a few months, but that appears to be resolving itself now
19:31 chromatic (now you may have to change all of the rest of the system to have lock points around acquiring GCable items, but that's a different problem)
19:31 Infinoid chromatic: one of the things that makes me nervous is: how tied are we to the current GC?  the other plugins are in varying stages of functionality, and apparently, they have been for years.
19:31 chromatic Less so than last year.
19:32 pmichaud Debolaz: but I would be very happy to hear reports of "I wanted to do this in rakudo but it doesn't work yet"
19:32 Infinoid I expect some more bugs to crop up, and I look forward to fixing them.
19:32 pelagic joined #parrot
19:32 chromatic Without some careful thought (or a great deal of luck) I think we'll have trouble with any non-stop-the-world collection.
19:33 Infinoid It seems like I should learn a lot about GC internals sometime in the near future.  at some point, I'd love it if you could elaborate on that.
19:34 mncharity PerlJam: avoiding "yet another dead-ish p6 implementation" was indeed the defining design objective of the exercise.  I believe elf has the right properties, but we'll see.  probably within a week or so, as a couple of people seem to be in a busy wait, so if they adopt it, at least someone is unstuck.
19:35 chromatic Mostly the problem is that if you move a GCable element (copying or compacting collector), you have to update all of the pointers to that element before they try to use it.
19:35 Infinoid I suppose that means they have to be scanned for, or have backreferences.
19:37 allison Infinoid: right, and currently there is no mechanism for backreferences, or intermediate pointers
19:37 mncharity I think that was everyone's questions.  Others welcome.  /me -> back to IR exploration.
19:37 chromatic mncharity, why build a new platform?
19:39 mncharity re "platform", same meaning a before, a compiler target?
19:39 mncharity *as
19:39 chromatic Right.
19:39 chromatic Every bootstrap needs to run on *something*, whether you emit C from Scheme or Smalltalk or Perl 5 from ELF or PIR/PBC from PCT.
19:39 chromatic Not that PCT is a bootstrap.
19:40 Infinoid allison: is such a mechanism proposed, or should I try a couple of halfbaked things and let you guys tell me how wrong I am? :)
19:40 * Infinoid promises to spend a couple of days trying to wrap his head around all of this stuff, in any case.
19:41 allison Infinoid: it's not currently spec'd. In fact, we're not planning to implement a compacting or copying collector until after 1.0
19:42 Coke allison: note that we have a few SOC proposals re: gc.
19:42 chromatic Infinoid, a copying collector isn't too bad.  If you're willing to live with stop-the-world, we could change pobject_lives() such that it copies or updates.
19:42 Infinoid well, Harmony is not a stop-the-world GC, so it sounds like things might break gloriously.
19:42 chromatic We have to pass in the pointer location, but that'll get rid of some boilerplate.
19:43 chromatic Harmony probably requires a read barrier.
19:43 mncharity re 'why build a new platform?', because new platform x gives you something you want that your current ones don't.  eg, Moose p5 added for easier and eventually more conformant p6 compilation than the preceeding bare p5.  ruby might provide faster method calls, an object system which might be wielded to implement true p6 oo without much overhead,
19:44 mncharity crude jit, and thus be faster and more correct than a p5 platform.  a common lisp platform would provide mature and wizzy compilers.  ... etc.
19:46 mncharity a 'not-very conformant but compiles to p5-compatible code' might provide the ability to write cpan modules in something like p6.
19:46 Infinoid ok.  Thanks for the answers, guys.
19:46 chromatic And so you want people who're already working on such a platform that can actually run Perl 6 code today to dump out an AST so that people who are blocking on the non-existence of an as-yet-unwritten platform can ... wait a little longer for that as-yet-unwritten platform to get to the point where they can actually run Perl 6 code?
19:47 chromatic I mean, I can see the theoretical benefits of running on a mature Lisp platform or Smalltalk or Rhino or whatever, but none of those experiments have ever worked beyond "Hey, I can parse Perl 6 lexical variable declarations and simple if/else blocks!"
19:48 mncharity me puzzled by preceeding paragraph... let's see...
19:48 mncharity *previous
19:48 chromatic I'm reading a lot of "this platform might do this" and "that platform could do that", but practically speaking, where's the beef?
19:49 mncharity is "people who're already working on such a platform that can actually run Perl 6 code today to dump out an AST" a reference to earlier interest in getting a yaml dump of ast from rakudo?
19:50 chromatic Yes.
19:51 mncharity ah, ok.  re yaml dump of ast, I ended up following pmichaud's suggestion to scrape the --target=parse output, and built a project elf_on_rakudo on it.  the parsing ended up being rather slower than I was hoping for, and STD_red seemed to be working fairly well, and so an elf_on_STD_red was done.  that then became the current elf.
19:53 mncharity also, yaml turned out to be a problematic interchange format.  elf_on_STD_red hit both yaml bugs, and performance issues, eventually switching to a more "I know you are running p5 - here is a dump format you can just eval there" interchange approach.  'match("rule name",0,1,"the text which matched",{...})'.
19:53 mncharity which was much faster and less buggy.
19:54 chromatic You want to write Perl 6 in Perl 6, right?
19:54 mncharity so the "yaml from rakudo parse" is no longer of near-term interest.  sorry I didn't gc that sufficiently.
19:55 mncharity yes
19:55 mncharity a dump of PGE matches would still be of interest however.
19:55 mncharity in whatever format
19:55 chromatic Well it's not *my* interest, but I'm only speaking for myself.  I've no interest in telling other volunteers what to do.
19:56 mncharity I wasn't suggesting it was.
19:56 dalek r26694 | allison++ | trunk:
19:56 dalek : [pdd] Clarification to Strings PDD from Jim Keenan.
19:56 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26694
19:57 chromatic In your mind, the simplest/most desirable/easiest way to write Perl 6 in Perl 6 at this point is to use Rakudo to parse Perl 6 code into a parse tree, export that parse tree somehow, parse that exported tree into an application written in Perl 6 and running on Perl 5?
19:58 Coke mncharity: you can dump pge match objects atm.
19:58 wknight8111 that process seems awfully convoluted to me
19:59 chromatic That's why I'm asking.  I feel like I'm missing something.
20:00 wknight8111 if it were me, and I know it's not, I would write Rakudo V 1.0 in PIR/NQP. Then write Rakudo V2.0 in Rakudo V1.0, etc.
20:00 wknight8111 that way you don't have to wait for a new tool/platform to be available before you can make a release
20:01 ruoso joined #parrot
20:12 dalek r26695 | kjs++ | trunk:
20:12 dalek : [pdd29] check in initial pdd stub for compiler tools. update manifest. keywords are set.
20:12 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26695
20:15 mncharity chromatic: no.  but s/Rakudo/STD_red/, and that is what elf is currently doing.  elf_on_rakudo did what you described - but I consider it dead code.
20:17 mncharity as for whether elf is 'the simplest/most desirable/easiest way to write Perl 6 in Perl 6 at this point', it's certainly letting me write p6 code which nothing other than pugs might run, without worrying about getting hung up on pugsbugs, and with a much faster edit-test cycle.  so, yes.
20:17 chromatic Is STD_red a Perl 6 grammar parser written in Ruby?
20:19 mncharity STD_red is a kludge of a direct hand translation of STD.pm into ruby.  it parses, buggily, p6.  upside is its fast, and the coverage is much better than STD5 at present.
20:21 mncharity token foo { <bar> <hee> {...p6 code...} }  ->   def foo() {  b=bar and h=hee and ...ruby code... and _make_a_match(..b..h..) }
20:21 chromatic What features does Rakudo need to support before it's a more viable platform than elf?
20:26 mncharity than elf itself, rather than the STD_red part of elf?  hmm...
20:27 dalek r26696 | kjs++ | trunk:
20:27 dalek : [pdd29] fix copyright year; add a reference and add an abstract line.
20:27 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26696
20:29 mncharity so rakudo has a more real parser.  you'd loose bootstrap, but for many things that doesn't matter.  matters for backend and primitives work, somewhat for Prelude, not at all for much else.  so after that, it's just performance?
20:30 chromatic Why would you lose bootstrap?
20:32 mncharity elf_c, the current "elf of Monday night, today, and hopefully move off it later this week", can compile http://svn.pugscode.org/pugs/misc/elf/elf_c_src/ in about 20 sec, and run it in doing the same task in 10 (the other half being the parser).  rakudo needn't be that fast, and much work is on smaller things, and one can do makefile-like 'avoidance of compilation'.  So while rakudo was too slow for elf_on_rakudo, it
20:32 mncharity may be fine to be viable, leveraging its other advantages.
20:32 mncharity re 'Why would you lose bootstrap?', because rakudo isn'
20:33 findlay joined #parrot
20:34 mncharity t implemented in p6?  so one still faces a variant of the pugs "I really need to do x, my compiler won't let me, and there is nothing I can do about, so I spend time trying to find workarounds".
20:36 chromatic Do you think then that the complexity of bootstrapping is less a barrier to overcome than the complexity of learning, say, NQP?
20:38 * ewilhelm ponders toggling the instruction set for nqp directly into the cpu's front-panel...
20:40 mncharity well, the backend portion of the bootstrap is done.  cost paid.  cost for the front end is mostly writing a "regex on regexp" implementation in p6.  of which there is already a p5, so it shouldn't be too bad.  vs NQP, the pain of maintaining STD_red should be included, though it's been at least slightly amortized over helping with STD.pm work.  re barrier,
20:41 chromatic There's a conceptual cost of understanding the layers, and bugs in lower layers tend to be much more difficult to find and to diagnose.
20:43 mncharity the key question short-term, this week, will be "you got this dialect working, it's a dialect you personally understand and has what you most wanted.  but as to whether *I* understand and can use it, and whether it has the features *I* need for comfortable development..." for a multiperson value of I, is unclear.  the question which follows is how rapidly a feature set which makes people generally happy can be grown.
20:47 mncharity re layers, and expecially error reporting, agreed.  currently taking advantage of the p5 layer being readable, but that doesn't scale.  current story is that the/a emitter should rsn start inserting #line's refering back to the original p6 source.  or let users toggle that.  or some such.  the info is available at emit time, it just hasn't been enough of an irritant (barely), to happen yet.
20:51 chromatic Your conjecture then is that there are more people willing to learn Perl 6 and how to write a bootstrapping compiler than there are willing to learn NQP?
20:52 rafl joined #parrot
21:03 mncharity re conjecture, no.  that there are more people willing to learn Perl 6 than NQP seems clear.  that [...] to learn some elf dialect of p6 than learn NPQ, of course depends entirely on how extensive the dialect support becomes, and when.  Unclear.  But that's not the near-term objective.  That there are more _p6 compiler writers_ wishing to work in bootstrapped p6 rather than in NQP on parrot is the conjecture.  well, hypothesis.
21:04 chromatic What's the near-term objective then?
21:04 mncharity support the '_p6 compiler writers_ wishing to work in bootstrapped p6 rather than in NQP on parrot'.
21:08 chromatic I thought that wasn't your near-term goal.  What is your near-term goal *not*, then?
21:08 mncharity while pugs also supported a population of people writing "some random module" in p6, their (not) being able to get work done does not at present directly hurt a development critical path towards Christmas.  And won't until we have enough of the language working that their language-design feedback becomes key.
21:17 * ewilhelm notes parallel that squeak was written in a subset of smalltalk
21:17 ewilhelm (though smalltalk was already a mature language at that point)
21:22 Tene It really would be nice to be able to write Random::Perl::Module to use with Parrot.
21:27 chromatic Sure, but the open question is "Is bootstrapping a likely way to get there?"
21:28 chromatic My opinion is no secret: you'll end up reinventing something that looks very much like Parrot to do so.
21:29 ewilhelm Tene: use in what way?  Couldn't perl5 be embedded (with limited connectivity ala inline) via C with a small matter of code?
21:29 ruz joined #parrot
21:29 ewilhelm of course, the squeak developers were apple employees :-/
21:29 Tene ewilhelm: Perl 6 modules, I mean.
21:30 ewilhelm well, that sort of supposes that rakudo is done, no?
21:32 chromatic No, why?
21:32 chromatic People wrote modules for Perl 5.000 despite Perl 5.10 being a decade away.
21:33 ewilhelm well, what breaks if I write Random::Perl::Module (e.g. File::Fu) in perl 6 today?
21:35 chromatic I don't understand the word "breaks" in this context.
21:36 ewilhelm what doesn't work?
21:36 purl Look buddy, doesn't work is a strong statement. Does it sit on the couch all day? Is it making faces at you? Does it want more money? Is it sleeping with purl's girlfriend? Please be specific!
21:36 ewilhelm iiuc, operator overloading isn't fully specified
21:37 chromatic Sure, and that means for File::Fu to work as written, Rakudo needs to support that type of operator overloading.
21:38 chromatic Unless that's absolutely the last thing added to Rakudo, I'm not sure that Rakudo has to be done for you do port File::Fu.
21:38 ewilhelm s/done/in some satisfactory state of readiness/
21:39 ewilhelm i.e. everyone has their own threshold of ride-along vs wait vs contribute
21:42 chromatic Yeah, but not all of them are "It must be DONE".
21:42 chromatic That's why I like to ask for specifics.
21:43 ewilhelm http://www.perlfoundation.org/perl6/ind​ex.cgi?what_can_i_do_with_perl_6_today
21:43 shorten ewilhelm's url is at http://xrl.us/biq6w
21:44 * ewilhelm is curious when the "3D graphics" stub will become a link
22:01 jan joined #parrot
22:10 * davidfetter wonders whether ewilhelm is the same ewilhelm he heard on talk of the nation today
22:10 chromatic This one is a Josh, not a Kaiser.
22:10 davidfetter heh
22:11 * davidfetter fails to note any early april stuff on parrotcode.org
22:11 davidfetter it must just be too subtle
22:16 wknight8111 the site was down this morning, that counts
22:16 mncharity pmichaud: one more for the todo list, but it seems unambiguous.  PAST::Op pasttype(for) mentions an otherwise unmentioned 'arity' attribute.  --target=PAST shows it in Block, but only if explicit arguments are given (eg, "foo () -> $x {3}" but not "foo () {3}").  fyi.  I think I'm all set.  thanks for your help.
22:17 Limbic_Region joined #parrot
22:20 ewilhelm davidfetter: I think I'm the one you had a beer with several months ago in portland
22:20 davidfetter w00t!
22:51 cotto_work now that PDD17 renamed "does" to "provides", are the "does" and "does_pmc" VTABLE method names also going to change?
23:02 nopaste joined #parrot
23:08 skids joined #parrot
23:20 dalek r26697 | allison++ | trunk:
23:20 dalek : [pdd] A few more clarifications to the Strings PDD, while responding to mailing
23:20 dalek : list comments.
23:20 dalek diff: http://www.parrotvm.org/svn​/parrot/revision?rev=26697
23:20 tetragon joined #parrot
23:43 Infinoid cotto_work: they probably should

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

Parrot | source cross referenced