% Alias_ has left Alias_!adam@CPE-124-188-112-79.nsw.bigpond.net.au
% barney has joined #parrot
% jrt4 has left jrt4!~bojangles@c-24-18-106-126.hsd1.mn.comcast.net
% rrando_ has joined #parrot
% iblechbot has joined #parrot
% Ademan has joined #parrot
<dalek> r26639 | bernhard++ | trunk:
<dalek> : [HQ9+]
<dalek> : Clean up files generated during testing.
<dalek> : Remove DYNPMC support in Makefile.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26639
% jq- is now known as jq
<barney> infinoid++ for getting rid of unneeded HQ9plus.pm
% Ademan has left Ademan!~dan@c-69-181-114-208.hsd1.ca.comcast.net
<cognominal> I am working on a fix for #52276
<dalek> r26640 | bernhard++ | trunk:
<dalek> : [HQ9+]
<dalek> : Remove obsolete directory languages/HQ9plus.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26640
<dalek> r26641 | bernhard++ | trunk:
<dalek> : #52264 (Bug: duplicate directory names in SVN)
<dalek> : Run mk_manifest_and_skip.pl after removing languages/HQ9plus
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26641
<dalek> r26642 | bernhard++ | trunk:
<dalek> : [HQ9+]
<dalek> : Update NEWS.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26642
% barney has left barney!~bernhard@p549A2DA0.dip0.t-ipconnect.de
% slavorg has left slavorg!~tomi@windmill.london.pm.org
% rdice has joined #parrot
% davidfetter has joined #parrot
% slavorg has joined #parrot
% guru has joined #parrot
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
% guru has left #parrot
% Theory has joined #parrot
% davidfetter has joined #parrot
% rrando_ has left rrando_!~jrt4@c-24-18-106-126.hsd1.wa.comcast.net
% rrando has joined #parrot
% jan has joined #parrot
% Limbic_Region has joined #parrot
% guru has joined #parrot
% guru has left #parrot
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
% buchetc has joined #parrot
% guru has joined #parrot
% buchetc has left buchetc!~christoph@pD9E3050E.dip.t-dialin.net
% tetragon has left tetragon!~seneca@216.126.67.44
% tetragon has joined #parrot
% darbelo has joined #parrot
% lightsey has joined #parrot
% Psyche^ has joined #parrot
% Patterner has left Patterner!~Psyche@e177237153.adsl.alicedsl.de
% Psyche^ is now known as Patterner
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se
% IllvilJa has left IllvilJa!~jilves@emea-netcache1.oracle.co.uk
% lightsey has left lightsey!~john@c-98-194-197-54.hsd1.tx.comcast.net
% kj has joined #parrot
% jan has joined #parrot
% tsg has joined #parrot
* Infinoid makes some progress in getting "make -j2" to work
<Infinoid> ("makes"!  get it?  ha ha.)
% IllvilJa has joined #parrot
<cotto_home> thanks for working on that!
<dalek> r26643 | infinoid++ | trunk:
<dalek> : [Makefile] The pdd17pmc branch merge broke "make -j2".
<dalek> : * Add some missing build interdependencies, so make knows what it can and can't
<dalek> :   build in parallel.
<dalek> : * Now "make -j2" seems to work pretty reliably for me... more testing is on the
<dalek> :   way.
<dalek> : * This change shouldn't have any effect on non-parallel builds.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26643
* Infinoid starts bashing the hell out of it with "make -j8"
<Infinoid> I'm focusing on GNU make, at the moment.  But I'm curious, does nmake support multithreaded building too?
<leo> Infinoid: -j3 started testing successfully here - looking good - thx
<Infinoid> -j8 causes a segfault in miniparrot
<Infinoid> thanks for the testing :)
<leo> welcome
<Coke> leo: hey!
<leo> Infinoid: indeed -j8 is b0rked
<leo> hi Coke 
<Infinoid> (-j8 was busted before pdd17pmc, too)
% tsg has left tsg!~chatzilla@61.48.117.38
<leo> Infinoid: -j5 did stop too - anyway, the amount of -j really doesn't matter if all dependencies are ok - so the succeeding -j2 was an accident ;)
<Infinoid> yeah, higher numbers just shake out bugs more I think :)
<leo> depends on load, whatever, but yes
<Infinoid> comprehensive tests are difficult.
<leo> watch out for missing .str file deps
<Coke> c has threatened twice now to redo how we do .str stuff to avoid issues.
* leo thinks this is error prone and should be automagicall happen
<leo> *ly
<Infinoid> leo: absolutely.  .str deps should be generated by the summary rules
% guru has left #parrot
<leo> indeed - that part of your patch: +$(SRC_DIR)/scheduler$(O) : $(SRC_DIR)/scheduler.str   \
<leo> should really be autogened by detecting usage of CONST_STRING inside .c
<Infinoid> is there a way to do that automatically, without grepping for CONST_STRING for each source file before building?
* Infinoid will let chromatic solve that problem :)
<leo> as -jn was working some time ago, I'd estimate, the evil is one of the newer .c files 
<leo> Infinoid: greeping is fine, isn't it ;)
<Infinoid> it's just slow
<Infinoid> however, .str isn't the only issue here
<leo> doit it once, iff there is no .str file
<Infinoid> one of the bugs I fixed was: a source file in src/ wanted to #include a header (generated by pmc2c) in src/pmc/
<Infinoid> another of the bugs: compilers/pge/ was being run before $(GEN_LIBRARY) had completed
<Infinoid> so I'm trying to find and fix all of those things I can...
<leo> yep there are a log of possible errors
<leo> Infinoid++
% rrando has left rrando!~jrt4@c-24-18-106-126.hsd1.wa.comcast.net
<Infinoid> hmm
<Infinoid> [11:43] <@leo> doit it once, iff there is no .str file
<Infinoid> ... or if the .c timestamp shows a modification
<leo> well after a make, you have related .src files
<leo> .str - sorry
<Infinoid> true, just possibly out of date
<leo> doesn't  matter, check against the dep rules
<Infinoid> and if the .c file (after modifications) no longer has any CONST_STRINGs, that means you have to remove the .str and everything else
<Infinoid> I don't understand .str, but it seems pretty ugly :)
<leo> .str is a nice thing to have to preconstruct const STRINGs at compile time
<Infinoid> ah, that sounds useful
<leo> it is
<Infinoid> can you do what the linux kernel folks do, namely, drop it out into a constant-sized record in a separate linker section?
<Infinoid> that'd remove the need for any secondary files
<leo> the .str files are just doing that
<Infinoid> ok
<leo> well, not a separate linker section, but a separate const structure
<Infinoid> they use a linker section because ld concatenates everything for you in the final link, and that makes it easy to enumerate
<Infinoid> they use that for init() function pointers, for example
<Infinoid> I dunno.  maybe when make -j works, I'll start looking at breaking .str :)
<leo> see also:
<leo> # constant string support
<leo> .c.str : $(PERL) $(BUILD_TOOLS_DIR)/c2str.pl $< > $@
<leo> which has another list of deps
<leo> ... in the Makefile
<Infinoid> ok.  I see the problem caused by make -j8, now I have to figure out how to fix it.
<Infinoid> register_nci_method() was called with an Iterator PMC whose _namespace pointer was NULL
% rrando_ has joined #parrot
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
<Infinoid> I don't think the vtables[] array was fully built
<leo> Infinoid: that's very likely just a secondary error
% ratmice has left ratmice!bosshog@nightfall.forlorn.net
<Coke> Infinoid: src/scheduler.c has a borked dependency.
<Coke> ... and it's my fault. =-)
<Infinoid> another one?
<Coke> I added 3 includes to pmc/*.h there to let it *build* on my machine, but didn't add those deps.
<Coke> ... did I miss an svn up? might have.
<lichtkind> pmichaud: thanks without your help i could not finish the article
<Coke> if you've already fixed that, danke.
<Infinoid> yeah, I added those 3 :)
<Infinoid> and a couple of other things
<Coke> yay. 
<darbelo> Coke: I talked with you about a SoC proposal involving languages/c99 a few day ago. I have few more questions about that.
<darbelo> do you have a minute?
<Coke> darbelo: I have a real world thing that may interrupt at any second, but yes.
<Coke> if I run away, feel free to email particle and myself.
<Coke> (and I can reply within an hour or so.)
<darbelo> OK, sorry I was silent this few days but Life got briefly in the way. I'm trying to hammer out the timeline of the proposal.
<Coke> Infinoid: I just did a few high -j runs, and it either worked, or did the cygwin-y segfault when running miniparrot to gen the config.
<Coke> darbelo: happens.
<Infinoid> Coke: I am currently debugging a segfault in miniparrot, but it's happening on linux.  are we talking about the same thing, or is there an additioanl cygwin issue?
<Coke> I use it only as a point of reference. it's how cygwin used to die all the time when cygwin refused to build for me.
<Coke> I'm doing my current testing on feather because it's much faster than my desktop. =-)
<Infinoid> well, I'll ping you when I've found a fix.
<Coke> when I was debugging this the last time, I ended up doing a build in ../parrot with -j <big>, and moving that off. then getting a fresh copy in parrot/ and building with -j 1 and then doing a diff -rbu (using svn export to avoid diffing all the .svn files)
<Coke> which was a PITA but did help narrow down the .str issues.
<Infinoid> that's pretty similar to the setup I've got right now. :)  but the .str issues seem to be solved, for the moment.
<Coke> excellent.
<Infinoid> I think this is just a missing Makefile dep
<Coke> I feel like an idiot, I did a quick test after I saw your initial stuff and realized I'm the one that borked the deps on that file while fixing the -j1 build.
<Infinoid> seems likely that it's proceeding to the link phase with something half-built.
<darbelo> chromatic suggested testing c features by groups and using the tests as milestones.
<darbelo> I'm trying to find the right level of granularity.
<Coke> I've heard eric talk about "every 2 weeks"
<Coke> which from a real world project management standpoint, makes sense. anything longer than 2 weeks is hard to manage.
<leo> Coke: [BUG] in a subject is still enough to file a report?
<Coke> anything in the subject is fine.
<Coke> it all ends up in rt.
<Coke> BUG vs PATCH vs RFC vs RFE vs... is *mostly* just to help the humans looking at the tickets.
<Coke> (PATCH is slightly special)
<darbelo> I meant feature granularity. Think  'all looping constructs'  versus 'for' 'while' 'do-while' as separate entities.
<darbelo> Or, are you suggesting 'feature set that can be implemented in two weeks time' ?
% Senaka has joined #parrot
<ewilhelm> Coke: Senaka is applying to Apache for SoC
<Coke> real world was here and is now gone.
<Coke> darbelo: that.
<Senaka> Coke: hi
<purl> bonjour, Senaka.
<Coke> that's a good way to base your granularity, I think.
% guru has joined #parrot
<Senaka> need some help here
<Coke> ewilhelm: feel free to jump in, also. ^_^
<Coke> Senaka: Guten tag.
<Senaka> Coke: sorry ddn't get you.
* ewilhelm tries to keep fingers and toes away from GC's
<Senaka> :)
<Coke> Senaka: Good day. hello.  
<Senaka> :)
<Senaka> hello, Good day you too
<darbelo> Now that I think about it, that makes more sense, from a management perspective,
<Senaka> I'm working on Harmony GC
<Coke> EEEEEEEK, garbage collection!
<Senaka> and the aim is to make it pluggable to Parrot
<Senaka> :)
<Coke> that would be nice, actually. =-)
<Senaka> now I spoke to Allison
<Senaka> i think they started some work on it
<Coke> which is something I would have recommended doing if time permitted (talking to allison).
<Senaka> anyway, I would like to know whether I could find someone involved in SoC to give me a hand on this end too?
<Senaka> is Allison into SoC?
<Coke> We have a few mentors lined up for the parrot end of summer of code, including myself and particle.
<Coke> (and chromatic)
<Coke> lemme check the list...
<Senaka> OK...
<Coke> (chromatic is one of our primary C hackers atm.)
<Senaka> Ok
<Senaka> would he like to give me a hand?
<Senaka> do u think so?
<Senaka> I mean on the Parrot end...
<Coke> hurm. let me back up a step: this would be an apache SOC project, but you want someone you can coordinate tech questions with once you're underway?
<Senaka> yes
<Senaka> exactly
<Coke> ah. that's a much lower bar that I am sure we can meet, yes. =-)
<Coke> seen chromatic?
<purl> chromatic was last seen on #parrot 1 day and 14 hours ago, saying: Most of them built for me anyway.  [Mar 28 22:22:18 2008]
<Infinoid> LIES
<Senaka> :)
<Senaka> need some info to start with if you don't mind
<Coke> what's your name/email? I can send out a solicitation to the list that will probably get you a few responses.
<Senaka> and BTW I ran Parrot on Gutsy
<Senaka> cheers...no issues at all
<Coke> excelllent.
<Dave> :)
<Senaka> name: Senaka Fernando, e-mail: senakafdo AT gmail
<Senaka> I went thru the Configure.pl
<Senaka> now, say for instance I want to change the GC? not use malloc or something, how to do that?
<Senaka> I mean is it possible 2 use the -gc option?
<Coke> The goal has been for some time to have pluggable GC models. I am uncertain of the current state.
<Senaka> hmm... ok
<Coke> I am not a C hacker, but I can probably find out the answer to that question.
<Senaka> perhaps I can contribute to that fact
<Coke> darbelo: haven't forgotten you: any more questions? =-)
<ewilhelm> Coke: you must have heard me wrong
<ewilhelm> darbelo: I've always said "every 1 week"
<Coke> ewilhelm: regarding the 2 weeks thing? very likely. Fire hose, you know.
<Infinoid> Senaka: there's a --gc=<foo> option to Configure.pl
<Coke> ewilhelm: I'm used to the "industry standard" "no more than 2 weeks", and probably combined them in my head when reading. 
<Infinoid> possible options of <foo> are: gc, libc, malloc, malloc-trace
<ewilhelm> mainly a matter of challenging the student to think through things at a granularity that reveals potential roadblocks
<Coke> so, slightly smaller chunks... which makes sense for a project with a mentor. =-)
<Senaka> Infinoid: yes I saw that too
<Infinoid> config/auto/gc.pm sets up the Makefile to build for each of those
* Coke asks Infinoid to volunteer so I don't have to send to the list!
<Infinoid> what am I being volunteered for?
<Senaka> the issue is how could i change the gc altogether?
<Coke> ... giving senaka GC related information. Oh look, you've already started. =-)
<Infinoid> I think you'd want to add a 5th option
<Senaka> like say -gc=bar?
<Infinoid> rather than replacing the current ones
<Coke> (we already have 4 options? Is anyone testing those! Aigh. =-)
<Infinoid> Coke: adding options is easy.  making them *work* isn't. :)
<Infinoid> config/auto/gc.pm claims only 1 of the 4 is working
<Senaka> Coke: ok I'll take the second
<Senaka> aha looks like....yes
<darbelo> Ok, so "every seven days a new test shall pass, or I will be kicked in the ass". Sounds good.
<Infinoid> Senaka: so to add another option, you'd add another if/else clause to runstep() in config/auto/gc.pm.
<Infinoid> then, create a source subdirectory and start fleshing out the API
<Senaka> reading
<Senaka> reading gc.pm
<Coke> looks like src/gc/gc_*.c has 2 different ones there atm.
<Senaka> yes
<Senaka> got it
<Senaka> Infinoid
<purl> Infinoid is mailto:mark@glines.org or Mark Glines
<Infinoid> or just put it in src/gc/ with the others...
<Senaka> purl thanks
<purl> pas de quoi Senaka
<Infinoid> purl++
<Senaka> purl: ddn't get u
<purl> Senaka: i'm not following you...
<Senaka> :)
<Infinoid> purl?
<purl> Infinoid?
<Senaka> oh!
<Infinoid> purl: what are you?
<purl> i am probably going alone. or almost an anagram of Donaudampfschiffahrtskapitaensmuetzenkordel or a perv or an auto-triage bot or a she or so stupid or a smartass or the sixth beatle. or http://www.infobot.org or dumb
<Senaka> purl: are you a bot?
<purl> a bot? yeah right.
<Infinoid> (yes)
<Coke> bad bot.
<purl> :(
<Senaka> purl: wow u do good
<purl> Senaka: excuse me?
<Senaka> :)
<Senaka> purl: at least u r faster when it comes to typing
<purl> Senaka: sorry...
<Senaka> :)
<Senaka> Infinoid: where were we?
<purl> were we are on stage together
<Infinoid> reading gc.pm I believe
<Coke> purl, forget were we
<purl> Coke: I forgot were we
<Coke> so, yes, I think Infinfoid can be your contact. =-)
<Senaka> Coke: thanks
<Infinoid> I'm a cage cleaner, but I can whack more intelligent people as needed
<Senaka> will let the list @ Harmony
<Coke> Infinoid++ #for letting himself be volunteered.
<Senaka> Infinoid what's your name btw
<Infinoid> Mark Glines
<Coke> it's in scrollback!
<Coke> Infinoid?
<purl> Infinoid is mailto:mark@glines.org or Mark Glines
<Senaka> ok got it
<Senaka> ewihelm: literal is you?
<Senaka> ewihelm: I meant are you literal on the #gsoc on freenode?
<Senaka> I just want to thank
<ewilhelm> Senaka: no, I don't know who that is
<ewilhelm> oh, that's Hinrik -- a student
<Senaka> ewilhelm: thanks
<Senaka> he gave me details about this list
<darbelo> Can someone comment on the sanity of separating de c99 preprocessor into it's own grammar.
<Senaka> hi anyone here who knows about SoC proposals n stuff?
<darbelo> It could make it (almost) testable on it's own and unclutter the c99 grammar, which is good.
<darbelo> But it might be more effort than it's worth.
<ewilhelm> Senaka: what about them?
<guru> I'm trying to track down a windows-specific test failure. t/op/arithmetics.t shows that -0 is not being produced.  Where should I start looking? 
<Infinoid> guru: I'd start with a simple C application, figure out what hoops you need to go through, to get a float variable set to -0
<Infinoid> the code in question is the neg_n op; it boils down to just a function that takes a float and returns its negative
<Infinoid> grep src/ops/math.ops for inline op neg(inout NUM)
<Infinoid> (assuming its even possible on MSVC.  I have no idea, negative 0 is one of those bizarre C99 spec things I've never tried to understand)
<guru> Is src/ops/math.ops in PIR?
<Infinoid> its in pseudo-C
<Infinoid> it is preprocessed to form core_ops*.c
<guru> No wonder I couldn't figure out what I was reading.
% guru has left #parrot
<darbelo> ewilhelm: SoC has 13 weeks for coding, right?
% particl1 has left particl1!~particle@c-24-19-3-148.hsd1.wa.comcast.net
<darbelo> Or am I missing somethig from the schedule?
<Infinoid> ewilhelm: Senaka had a question about SoC stuff... its possible that the GC work will expose bugs in Parrot that we'll need to fix up, and was wondering whether/how to mention that
<Infinoid> (its an apache SoC project)
% chromatic has joined #parrot
<chromatic> We won't let any Parrot bugs block successful completion of a project.
<chromatic> That is, any bugs we can fix or work around, we will.
<Senaka> chromatic: thanks
<chromatic> You're welcome.
<Senaka> g2g... bye channel... will be back 2moro...
<Senaka> thanks for all the help I got from everybody
% Senaka has left #parrot
% moha has joined #parrot
% moha has left #parrot
<Infinoid> do flock bits follow inodes, or pathnames?
<Infinoid> I hacked c2str.pl to just lock all_cstring.str, instead of creating a .lck file and unlinking it afterwards.  that seems to have fixed "make -j8".
<Infinoid> you have 2 c2str.pl processes, one of which holds a lock, the second of which is waiting for the lock, then the first one exits (unlinking the lockfile as it goes), a third one comes up and creates a new lockfile and (of course) obtains the lock, so now the 2nd and 3rd are writing simultaneously.
<Infinoid> at least, I think that's what was happening.
<dalek> r26644 | infinoid++ | trunk:
<dalek> : [c2str] Fix another race, now "make -j8" works reliably for me.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26644
% Auzon has joined #parrot
* Infinoid hopes he didn't just break everyone else.
<chromatic> Works for me.
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-200-156.dynamic.mnet-online.de
<chromatic> Ah, nice work on the seek.
<Infinoid> thanks.  That's straight from "perldoc -f flock".
% kj has joined #parrot
% wknight8111 has joined #parrot
<wknight8111> hey, can somebody fix the problem with the languages/HQ9Plus directory?
<Infinoid> wknight8111: looks like bernhard cleaned that up this morning.  are you having an additional issue?
<wknight8111> oh, it's still saying that I can't update my SVN
<wknight8111> I'll try cleaning it all up and trying again
<Infinoid> hmm.  is the old directory getting in the way of the update?
<Infinoid> maybe just delete all of languages/ and retry the update
<wknight8111> that's what I'm doing now
<wknight8111> stupid windows and case-insensitive path names...
<wknight8111> yay! it's working! now I can update and get back to hacking!
<Infinoid> great!
<Infinoid> how familiar are you with nmake?  do you know if there's an option to build with multiple processes in parallel?
<Infinoid> (something analogous to GNU make's "-jN" option, for N jobs)
<cotto_home> Thanks for fixing make -j, Infinoid.  That had been bugging me for some time.
% paco has left paco!~chatzilla@139.Red-80-36-122.staticIP.rima-tde.net
<Infinoid> cotto_home: me too.
<cotto_home> Have you spent much previous time looking at the build system, or did you just get annoyed and dive in to fix that?
<cotto_home> *just to fix
<Infinoid> hmm.  I've fought against these Makefiles once before, trying to get splint running.
<wknight8111> let me look around at nmake, see if i can find something like that
<wknight8111> no, it doesnt appear that nmake has a parallel build option
<Infinoid> well, great.  that means I haven't broken anything.
% chromatic has left chromatic!~chromatic@sub17-30.member.dsl-only.net
<wknight8111> that reassurance is key
<Infinoid> I appreciate it. :)
% chromatic has joined #parrot
<leo> Infinoid: -j5 is currently testing i.e. it seems to have passed build troubles
<Infinoid> great, thanks!
<leo> just that one again:
<leo> Failed Test    Stat Wstat Total Fail  Failed  List of Failed
<leo> -------------------------------------------------------------------------------
<leo> t/library/pg.t               43    1   2.33%  13
<leo> but if nobody has fixed that code since, I'm the culprit anyway
% kj has left kj!~IceChat7@ip565fd420.direct-adsl.nl
% mmcleric has left mmcleric!~chatzilla@213.148.16.237
% mmcleric has joined #parrot
<chromatic> Which Pg test is that?
% particle has joined #parrot
% jan has left jan!~chatzilla@89-253-66-101.customers.ownit.se
% peepsalot has left peepsalot!~peeps@67.9.161.48
% rrando_ has left rrando_!~jrt4@c-24-18-106-126.hsd1.wa.comcast.net
<dalek> r26645 | chromatic++ | trunk:
<dalek> : [runtime] Finished moving Test::More and friends to hierarchical namespaces.
<dalek> : All tests still pass.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26645
% rrando has joined #parrot
% peepsalot has joined #parrot
<darbelo> particle: I'm a SoC applicant, Coke told me you were the one to talk to regarding my project. It's about improving languages/c99.
% lichtkind has left lichtkind!~chatzilla@d90-135-105-73.cust.tele2.de
<wknight8111> hello darbelo, I'm an SoC applicant too
<wknight8111> I haven't seen particle around today
<wknight8111> see particle?
<wknight8111> seen particle?
<purl> particle was last seen on #parrot 2 days and 11 hours ago, saying: harumph, my nicks switched  [Mar 28 05:32:43 2008]
<Auzon> particle is here now :P
% Auzon has left #parrot
<ewilhelm> darbelo: you just missed particle by a few minutes
<ewilhelm> probably be ~30 before he's back
<darbelo> oh well.
<ewilhelm> you have general SoC questions or parrot-specifiC?
<darbelo> Kind of both. It was about geting a mentor for my project.
<ewilhelm> well, we sort that out if you get in, but it is good if you talk with someone ahead of time
<ewilhelm> my guess is that I'm not going to allow either of coke or particle to be (directly) mentors since we have lots of parrot projects for SoC
<ewilhelm> so they'll be somewhat busy managing mentors
<darbelo> I was without a working net connection for the last few days. Just got it back now. Last time I was here, Coke referred me to particle.
<darbelo> I think he was the one who had the most knowledge in the areas I'd have to work with during the project.
<darbelo> If I get in, o course ;)
* ewilhelm also refers you to particle
<ewilhelm> but he's at the store atm
<ewilhelm> chromatic will be mentoring about 8 GC implementations
<ewilhelm> Tene: you know anything about c99?
<darbelo> Hm. Is the MAINTAINERS file up to date for c99?
<ewilhelm> tewk: ping
<ewilhelm> well, tewk is a student, so I hope somebody else has knowledge there
<wknight8111> darbelo, what are you trying to do with the c99 implementation?
<ewilhelm> otherwise the two of you will have to have a cage match to determine who is the student and who is the mentor
<darbelo> wknight8111: Get it to work, first. Then, do some Sparse-like things with it.
<wknight8111> oh, okay. I heard somebody talking about implementing NCI signatures for it, but I thought that would be a lot of work
<ewilhelm> hmm, perhaps we could get josh siglet(?) to mentor
<ewilhelm> wknight8111: that would probably be tewk
<wknight8111> ok
<darbelo> Compiling c99 seems like too much for the summer. So I'm sticking with parsing, and then Doing Things to the parse trees.
<darbelo> I've already submitted it to the web-app, Some of the details are there. But it would benefit from some review, and sanity checking of the schedule.
<ewilhelm> triplett that is
<ewilhelm> darbelo: it looks pretty good, but I'm just the proposal gestapo
<darbelo> Well, my disconnectedness forced me to write it without any kind of reference. I just got back here and transcribed it in a hurry to get in before the 'soft deadline'
% kid51 has joined #parrot
<darbelo> "Sane enough for the gestapo" that's quite an endorsement :)
<ewilhelm> particle must be stuck in traffic
* ewilhelm wrote to josh triplett
<ewilhelm> though maybe he is applying as a student, we'll see
<chromatic> We have Parrot projects?
<ewilhelm> piles of parrot projects
* kid51 logs on from the U.S. for first time in six days.
<ewilhelm> chromatic: did you get mail on psoc-manager list?
<chromatic> The only thing I saw was one proposal.
<ewilhelm> today?
<purl> today is kick ECarroll day or Harry Houdini's death day.
<chromatic> wxCPAN GUI proposal, on Thursday.
<ewilhelm> no, different list
<ewilhelm> proposals don't come to the managers list, but I sent the link just 5min ago
<chromatic> I might not be on the list then.
% guru has joined #parrot
% contingencyplan has joined #parrot
% c9s has left c9s!~c9s@163.26.225.208
% mmcleric has left mmcleric!~chatzilla@213.148.16.237
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% contingencyplan has joined #parrot
* particle returns
<particle> darbelo: ping
<darbelo> Pong.
<particle> what's up?
<purl> Your face, particle. That's what.
<ewilhelm> bad bot
<wknight8111> yeah, the bot needs a stern talking-to
* particle gives purl a wedgie
<particle> pmichaud: ping
* particle needs to consider submitting to yapc::na tonight
* darbelo is looking for guidance and mentor-sheep
* ewilhelm is looking at languages/c99/MAINTAINER :-/
<darbelo> maybe a ship. Or a ship full of sheep.
<particle> tewk (with my help) created the first stab at c99
<particle> kj then ported it to the new compiler tools (pct)
<ewilhelm> if there are no overwhelming flaws in the application, we can sort-out the mentorship after the edit cutoff
<particle> kj also extended it, so it parses more than it did before
<particle> iirc, c99 can now parse some sdl header files
<darbelo> Thing is, The grammar chokes on the only available test file. That can give people the wrong impression.
<particle> indeed.
<particle> we have very many works-in-progress by excited developers
<particle> but there seem to be fewer test tuits than code tuits :(
<wknight8111> like me, I'm more excited then I am talented
<wknight8111> :)\
<particle> you're a lot like me, then :)
<darbelo> Fixing that is trivial. changing main ( void ) to int main(int argc, char **argv)
<Coke> (yapc::na) I think I'm not going to submit a talk, and just focus on the workshop.
<darbelo> but there are some other areas where it needs work.
<particle> coke: that's what i thought i'd do, too
<Coke> kid51: haven't forgotten your patch. I think it's good, but I think we can rip out more.
* particle notices a lot of files have been modified in the past week
<kid51> Coke:  The question is:  Do we want to throw out Parrot::Revision entirely, or do we want to retain it for a narrowly defined focus.  I know your ticket requested the former, but I'd like to make a case for the latter.
<kid51> What else would need ripping out (if not the whole thing)?
<chromatic> I can live with it only supporting SVN, and not doing anything for other VCSes.
<kid51> After all, I ripped out anything *I* couldn't maintain ;-)
<dalek> r26646 | chromatic++ | trunk:
<dalek> : [PDB] Taught PDB how to catch Parrot exceptions.  See RT #37287.  This still
<dalek> : needs more work, but it's a start.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26646
<kid51> particle:  At least submit a 1-paragraph proposal so jmcadams has something to work with.
* kid51 must eat dinner; just back from Toronto
% kid51 is now known as kid51_afk
<Coke> I didn't see a compelling reason to keep it. I'll re-read your email to see. But I agree we should rip out at least this much.
<Coke> if we only disagree about the last bits, that can be done separately, later.
<particle> was is das dalek?
<ewilhelm> I think dalek is the commit bot
<ewilhelm> or else somebody with real quick and consistent typing :-)
<particle> ja, wondering if this is the replacement for svnbot or what
<chromatic> That's the plan.
<dalek> r26647 | chromatic++ | trunk:
<dalek> : [dynpmc] Made GDBMHash PMC use parrot/embed.h instead of parrot/parrot.h (RT
<dalek> : #39043).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26647
<particle> hopefully this beastie is more stable. however, it must be throttled or we'll get chided by ircops
<particle> ~1message/second
<dalek> r26648 | chromatic++ | trunk:
<dalek> : [Amber] Updated PMCs to match PDD 17 changes.
<dalek> : Made PMCs use parrot/embed.h instead of parrot/parrot.h (RT #39043).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26648
<dalek> r26649 | chromatic++ | trunk:
<dalek> : [regex] Made PMCs use parrot/embed.h instead of parrot/parrot.h (RT #39043).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26649
% guru has left #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net
<dalek> r26650 | chromatic++ | trunk:
<dalek> : [Pugs] Made PMCs use parrot/embed.h instead of parrot/parrot.h (RT #39043).
<dalek> : Fixed some compilation errors and warnings.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26650
<dalek> r26651 | chromatic++ | trunk:
<dalek> : [WMLScript] Made PMCs use parrot/embed.h instead of parrot/parrot.h (RT #39043).
<dalek> : Fixed some compilation warnings.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26651
% Theory has joined #parrot
% kid51_afk is now known as kid51
<Coke> seen pmichaud?
<purl> pmichaud was last seen on #parrot 1 day and 2 hours ago, saying: Paula's calling me for dinner -- bbl  [Mar 29 17:29:07 2008]
<Coke> particle: are you on top of our current SOC status? =-)
<Coke> I've heard people say that make -j2 test is faster. How can this be?
<Coke> (since there is only one executable in the makefile)
<chromatic> Make usually blocks on IO, not CPU.
<Coke> "assuming parrot is already built...."
% teknomunk has left teknomunk!~teknomunk@ubuntubob.residential.okstate.edu
% teknomunk has joined #parrot
<chromatic> I don't think I understand your question then.
<Coke> "make test" runs a *single* executable, neh?
<Coke> (perl t/harness...)
<Coke> assuming yes, then how can "make -j" make that run faster, if all it does is run multiple targets at the same time? there's only one target...
<chromatic> Yes, that's true.
<Coke> I'm just making sure that I am not the one with the disconnect here. 
<chromatic> If Test::Harness runs its files in parallel, there's a bonus.
<chromatic> Otherwise, no real bonus, if make all has already happened.
% rdice has left rdice!~richarddi@CPE001217e365c7-CM00159a01d44c.cpe.net.cable.rogers.com
<dalek> r26652 | coke++ | trunk:
<dalek> : [tcl] Made PMCs use parrot/embed.h instead of parrot/parrot.h (RT #39043).
<dalek> : chromatic++
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26652
* Coke pays attention to chromatic's commits and tcl-blocks him.
% tsg has joined #parrot
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net
<chromatic> 'bout time someone does.
% tsg has left tsg!~chatzilla@211.157.41.194
* Coke tries to close out his windows ticket, but ends up doing the ZOMG UPGRADE EVERYTHING dance he does whenever he boots this xp box
* Coke launches firefox to check for updates... which finishes installing the last update he downloaded. nice.
% Ademan has joined #parrot
<chromatic> No dancing, please.
<Coke> ... I could just shimmy.
<chromatic> The IRC goggles... they do nothing.
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
<ewilhelm> my -j ears are burning
<ewilhelm> does it run more than one t/harness - e.g. in languages?
<Coke> no.
* Coke double checks...
<Infinoid> that would be awesome.
<Coke> no.
<ewilhelm> hmm, well make only parallelizes on sub-Makefile's, right?
<Coke> no.
<Infinoid> no, actually, sub-Makefiles are where parallel makes usually break badly
<Coke> (because each sub makefile is considered a single task by the top level make)
<chromatic> What's long and hard and full of dependencies?  A submakefile.
<Infinoid> make parallizes on peer nodes in the dependency tree
<ewilhelm> so how does it slice targets to determine which parts are independent?
% grim_fandango has joined #parrot
<Coke> it analyzes all the deps.
<Infinoid> its just looking at the dependency tree... parents and children are dependant, siblings aren't
<Coke> it has to do that to do the build anyway.
<ewilhelm> ok, so if test had e.g. a list of result files to be built then it would parallelize?
<Coke> yes.
<Infinoid> if there were no interdependencies declared between them, then make will consider them fair game
<ewilhelm> (not that this would be a good approach)
<Coke> and then you could have a step at the end that combined all the result files into harness output.
<Infinoid> hey, anything that reduces developer turnaround time is worth considering in my book :)
* ewilhelm would rather see it just pass -j to prove
<Coke> does prove respect -j ?
* Coke checks.
<ewilhelm> yep
<Infinoid> ooh
<Coke> well there you go.
<Coke> only problem there is tests that depend on each other to run, neh?
<Coke> I don't think we have any of those.
<chromatic> They are stupid.
<chromatic> Throw rocks at them.
<Coke> Yes, master.
<ewilhelm> no, only problem is when things assume that they can make stupid tempfiles
<purl> okay, ewilhelm.
<Infinoid> hmm, from what I've seen so far, they're pretty good at using the basename of the test
<Infinoid> (for core tests at least)
<ewilhelm> but easily solved with e.g. $filename .= $$ if need be
<Infinoid> do we run any tests more than once?
* Infinoid throws rocks at them
<ewilhelm> yeah, basename works too
* Coke has updated firefox, safari, subverison, and is waiting for parrot, ie7, xp, quicktime ... come on...
<Coke> I eagerly await this mythical prove -j!
<Coke> =-)
% kid51 has left kid51!~jkeen@pool-68-237-10-176.ny325.east.verizon.net
* Coke is bit by the hq9+ issue during the svn up process. *grr*
<Infinoid> Coke: wknight8111 solved it by just removing all of languages/ and redoing the update
<Infinoid> prove -j will be awesome.  but recursion to different harnesses will be interesting
% grim_fandango has left grim_fandango!~matt@bas2-kingston08-1167933634.dsl.bell.ca
<Coke> it's my understanding that we are moving to "highlander harnesses"
<chromatic> There should never be any sequels?
<Coke> cloooose.
* ewilhelm misses highlander joke ... dons kilt, tries adding scotch
<ewilhelm> Infinoid: yeah, no "different harnesses"
* Coke forgot how slow "make realclean" is on windows.
% Ademan has left Ademan!~dan@h-68-164-168-66.snfccasy.dynamic.covad.net
% Ademan has joined #parrot
<chromatic> Here's a nickel kid, get yourself a kernel with decent IO.
<ewilhelm> oh crap, these cost a nickel?
<chromatic> Or 12 billion dollars and 5 years, if you're Vista.
<chromatic> (and if you're not trying to read files while you're getting network traffic)
* Coke can't sleep, IO will eat me.
% tetragon has left tetragon!~seneca@206-248-175-68.dsl.teksavvy.com
<Infinoid> I Spent 12 Billion Dollars And 5 Years And All I Got Was This Lousy Vista
<dalek> r26653 | coke++ | trunk:
<dalek> : [codingstd]
<dalek> : Eliminate unused code (msvc++)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26653
<Coke> (I think the original long running realclean I was complaining about had been stuck in some kind of loop due to the upgrade. I rescind my complaint
<pmichaud>  /lastlog pmichaud 5
<pmichaud> oops
<Coke> oooh, nifty.
<Coke> I'll never have to wade through backscroll again. =-)
<Coke> pmichaud: how goes?
% tetragon has joined #parrot
<pmichaud> pretty well (reading scrollback)
<Coke> Infinoid: can you resolve 37323 ?
<Coke> (or rather, have you just?)
<Coke> bother. strawberry perl's "migw32-make" seems to be preferred whether i'm in xp or cygwin.
<Infinoid> the latter bit sounds like what I solved
<Infinoid> but I'd answer the original complaint with "do a realclean first, dork"
<Infinoid> changing build types on the fly isn't easy
<Infinoid> but if some specific examples can be found of sourcefiles which aren't rebuilt upon modification, I'd be happy to fix those up
<Infinoid> (so far, I haven't had any problems with that)
<pmichaud> particle: pong
<Infinoid> if we really wanted to support reconfigure-with-different-build-type-on-the-fly, we should be putting our object files in a special subdir, named after the build type, or using a special suffix
<Infinoid> I've never seen such a system that I'd call "pretty".  is it worth the trouble?
<Coke> I'm not the guy to ask, but in general, having to ever do "make realclean" sucks.
<chromatic> Sorry.
<Infinoid> well, I can call "make realclean" internally when Configure.pl sees that a Makefile already exists... that'd save some time
<pmichaud> ick!  no!
<Infinoid> didn't think so. :)
<pmichaud> calling "make realclean" when someone requests a different-build-type-on-the-fly might be reasonable, though
<dalek> r26654 | chromatic++ | trunk:
<dalek> : [dotnet] Ported PMCs to PDD 17 (somehow missed them).
<dalek> : Made PMCs use parrot/extend.h instead of parrot/parrot.h (RT #39043).
<dalek> : Fixed some compilation warnings.
<dalek> : I don't know if the tests pass; I don't have Mono.  I'm just bored.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26654
* Coke waits for someone to volunteer to give chromatic mono.
% AndyA has left AndyA!~andy@82.152.157.85
* ewilhelm wonders if it requires wine
% AndyA has joined #parrot
<dalek> r26655 | coke++ | trunk:
<dalek> : [t] Add a failing todo test for RT# 43048 (div by zero const. folding issue)
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26655
<Coke> ewilhelm++ on his technical innuendo skill.
<chromatic> Wow, compilers/bcg didn't even *compile*.
<dalek> r26656 | chromatic++ | trunk:
<dalek> : [BCG] Rescued this compiler; now it compiles.
<dalek> : Made PMCs use parrot/extend.h instead of parrot/parrot.h (RT #39043).
<dalek> : Removed several compiler warnings.
<dalek> : Half of the tests fail, but that means they all run and half pass.  Progress.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26656
<Coke> pointers on how to catch an exception from C?
<chromatic> r26646
<Coke> different but related question: for 43048, should we be 1) avoiding the constant folding of 1/0 in the first place, or should we be taking the exception that is returned from our eval and freezing that into the bytecode to rethrow it?
<Coke> I suppose the alternate version is to, if we get *any* exception trying to fold, back off on the fold and then let whatever happens at runtime happen.
<Coke> I like that version.
<pmichaud> is the constant folding actually being done based on the op?  I guess it would be.
<pmichaud> is there a   div_n_ic_nc op?
<pmichaud> actually, as I think about it more, I'm doubting that the actual op is used for the constant fold
<Coke> it seems to be.
<Coke> compilers/imcc/optimizer.c //eval_ins
<Coke> it's calling interp->op_func_table[opnum] ...
<pmichaud> I guess you're right.
<Tene> ewilhelm: I know nothing about c99. why?
* Coke wonders if coke had said "tene" at one point when he meant "tewk"
<chromatic> I was just thinking that, but my eyes have stopped working from refactoring PMCs.
<ewilhelm> Tene: I was just looking for potential mentors for that proposal
<Tene> Ahh.
<ewilhelm> it looks like we might need to recruit one or two more parrot mentors for SoC still
<Tene> As always, if you need my help, just let me know what I need to do.
<ewilhelm> well, depends on what you can and want to do
* ewilhelm is just the drummer
<Tene> Yeah, sure.
<ewilhelm> ok, I'll go back to guessing at your skillset
<Coke> whoa. I think I fixed an IMCC bug.
* chromatic assigns a pile of tickets to Coke
% chromatic is now known as chromatic_not_fixin
<Tene> ewilhelm: heh. :)
% andrewks has joined #parrot
<andrewks> good evening all.  Is there an Allison around looking for an ia64 box?
* Coke tries to run.
<cotto_home> andrewks, she hangs out here on occasion.  
<Coke> email is probably your best bet.
<Coke> allison?
<purl> somebody said allison was Allison Randal <mailto:allison@perl.org>
<Tene> ewilhelm: mostly HLL stuff so far. My C is iffy.  I don't remember most of what I've done.  I recommend svn log | grep tene
<ewilhelm> Tene: how about perl 6?
<purl> perl 6 is the spec, rakudo and pugs are the implementations.
<Tene> ewilhelm: I have a few patches to rakudo, iirc.  I've been actively following Perl 6 for quite a while.
<Tene> ewilhelm: Vague question. I'm not sure what you're asking.
<Coke> has pmichaud volunteered for perl6 mentoring yet?
% jan has joined #parrot
* Tene finally sleep.
* Coke finishes his testing and commits the imcc fix
<dalek> r26657 | coke++ | trunk:
<dalek> : [IMCC]
<dalek> : '$I0 = 1/0' generated a compile time exception due to constant folding instead of a
<dalek> : catchable runtime exception.
<dalek> : - if an exception occurs during this kind of constant folding, just abort the
<dalek> :   optimization.
<dalek> : - fixup the todo test to have proper syntax (which was missed due to the constant
<dalek> :   folding)
<dalek> : - eliminate two invalid tests that used invalid opcodes which were missed due to
<dalek> :   this issue.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26657
* Coke remembers the good old days when he would just work on tcl and leo would be the one mucking with imcc. =-)
<pmichaud> pmichaud has not volunteered for perl6 mentoring yet
% marmic has left marmic!~chatzilla@89-253-66-101.customers.ownit.se
<ewilhelm> no t-shirt for pmichaud :-(
% davidfetter has joined #parrot
<dalek> r26658 | chromatic++ | trunk:
<dalek> : [IMCC] Fixed a segfault when parsing a yield outside of a coroutine (reported
<dalek> : by Seneca Cunningham, RT #52220).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=26658
% chromatic_not_fixin has left chromatic_not_fixin!~chromatic@sub17-30.member.dsl-only.net
% darbelo has left darbelo!~darbelo@190.3.135.60