Camelia, the Perl 6 bug

IRC log for #parrot, 2009-01-05

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:08 dalek r34947 | jkeenan++ | trunk (5 files):
00:08 dalek : Change names of two Parrot::Configure::Data methods to reduce the number of
00:08 dalek : subroutines named '*slurp*'.  Cf.:  https://trac.parrot.org/parrot/ticket/117.
00:08 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34947
00:10 dalek r34948 | jkeenan++ | trunk (5 files):
00:10 dalek : Change names of two postconfiguration test files to correspond to changes in names of Parrot::Configure::Data methods.
00:10 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34948
00:10 AndyA joined #parrot
00:11 dalek r34949 | Whiteknight++ | branches/pdd09gc_part1/src/gc:
00:11 dalek : [pdd09gc_part01] pulled out some stuff that I don't support like PMC_next_for_GC and dod_trace_ptr, which can be dealt with later
00:11 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34949
00:22 Limbic_Region joined #parrot
00:28 tetragon joined #parrot
00:39 dalek r34950 | Whiteknight++ | branches/pdd09gc_part1/src/gc:
00:39 dalek : [pdd09gc_part1] some small fixes and diagnostics. Current crash appears to be in the memory pool handling during string concatenation, and not part of the normal GC
00:39 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34950
01:01 dalek r34951 | jkeenan++ | trunk (5 files):
01:01 dalek : Remove dwim.pir example.  Cf.:  https://trac.parrot.org/parrot/ticket/120.
01:01 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34951
01:10 Fayland joined #parrot
01:10 tetragon joined #parrot
01:21 nopaste "kid51" at 68.237.17.128 pasted "warning during Configure.pl: gen::makefiles" (3 lines) at http://nopaste.snit.ch/15187
01:26 kid51 allison: ping
01:26 pdcawley joined #parrot
01:26 allison kid51: pong
01:26 kid51 allison:  does the warning shown in my last nopaste pertain to what you were doing earlier today?
01:27 kid51 (importing stuff from rurban's branch)?
01:27 chromatic Looks like a Cygwin thing.
01:27 allison kid51: possibly, do you know what revision it appeared on?
01:28 allison kid51: the suspicious revision is going to be r34940
01:28 kid51 I'm seeing it at 34951.  I know it must be recent because I've been running Configure.pl frequently today.
01:28 allison kid51: that's where I merged in some cygwin configure changes
01:29 allison kid51: and what platform?
01:29 kid51 Darwin and Linux
01:29 purl Darwin and Linux are the OSes I have...
01:29 kid51 purl has good taste in OSes
01:29 purl kid51: what?
01:30 allison Darwin PPC/Intel? which version?
01:30 kid51 PPC
01:31 kid51 But I think this should appear on any OS other than cygwin.
01:31 chromatic Agreed.
01:33 allison r34940 had no problems on 10.5 Intel and Ubuntu Edgy... checking for changes since then
01:35 MariachiElf joined #parrot
01:35 nopaste "kid51" at 68.237.17.128 pasted "Possibly relevant code from config/gen/makefiles/root.in" (15 lines) at http://nopaste.snit.ch/15188
01:37 allison ok, it was definitely introduced in r34940
01:37 allison (just confirmed)
01:38 kid51 What would 'config.fpmc' be?  Typo?
01:38 Infinoid that's what we generate config_lib.pasm from with miniparrot during build time, I think
01:41 kid51 Well, it makes a certain kind of sense to say that 'cygchkdll' is undefined on non-Cygwin systems.  Question is:  How come this warning was never triggered previously?
01:43 allison oddly, that changeset includes a change to set 'cygchkdll' to an empty string by default
01:43 kid51 Perhaps the deletion of cygchkdll => '', from config/init/defaults.pm ?
01:44 kid51 Let me try that.
01:45 allison kid51: yes, that's almost certainly it, revert that change
01:46 kid51 doing make realclean;perl Configure.pl
01:47 jrockway joined #parrot
01:50 dalek r34952 | jkeenan++ | trunk/config/init:
01:50 dalek : Restore assignment of empty string to 'cygchkdll' so that that attribute is not seen as undefined by genfile() call in config step gen::makefiles.
01:50 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34952
01:57 rurban I've just deleted the whole cygchkdll stuff, because it is not needed anymore.
01:58 rurban The config checks can be done via cygwin, and the dll check is unnecessary
01:58 rurban s/done via cygwin/done with cygwin/
01:58 rurban Why do you have to that at 3am in the night :)
01:59 tetragon joined #parrot
02:06 rurban allison, kid51: cygchkdll is required in that version because the library patches are not yet in. the importlib and dll must be in build_dir. and all references to cygchkdll must also be gone.
02:07 allison rurban: the problem was that the patch deleted the default value of 'cygchkdll'
02:08 allison rurban: try again? that last comment doesn't make sense
02:08 rurban In the end we don't need cygchkdll anymore. But we have now an interim state. why don't you apply the patches in the order I committed
02:08 rurban I got rid of cygchkdll completely.
02:09 allison rurban: okay, will you want to reintroduce 'cygchkdll' later?
02:09 rurban config/inter/libparrot.pm is important e.g.
02:10 allison rurban: or have you permanently removed it?
02:10 rurban No. in the branch it is gone completely.
02:10 rurban permanently removed. bad name, lame functionality
02:11 allison rurban: you had so many different changes mixed together, I had to break them down into stages
02:11 rurban :)
02:11 allison rurban: independent patches generally work best
02:12 rurban we have time enough to fix everything
02:12 allison rurban: ?
02:12 rurban the problem is that they are interconnected. one fix leads to the change, and so on.
02:13 allison rurban: yes, exactly, that's the problem. If you develop your changes independently it will be much better.
02:13 rurban These were massive changes
02:14 allison rurban: well, they were several independent changes
02:14 allison rurban: each could be grouped into a set and applied to trunk cleanly
02:14 allison rurban: it just requires a bit of organization
02:15 rurban I organized with quilt and all my patchsets worked fine, up and down.
02:15 rurban you need to apply them in the correct order
02:15 rurban and all, not just cherrypicking.
02:15 allison rurban: right, but we aren't applying all the patches
02:16 allison rurban: that's the reason for logical groupings of changes, so they can be accepted/rejected as a group, rather than being all mixed up
02:16 rurban ooh. will there be  discussion? if you have told me what is bad I would have done that in the branch.
02:16 chromatic Certainly not in one big thud to trunk.
02:17 allison rurban: I sent you an initial email, will send to the list if you're comfortable with it
02:17 rurban Sure. But it's a it late, and if I knew before it would have been easier.
02:17 rurban I had theese ready patches in august.
02:18 allison rurban: aye, but it was such a huge changeset, it took me a long time to review it
02:18 ask_ joined #parrot
02:18 allison rurban: if they were smaller independent change sets, I could have reviewed them one at a time and given you a quick reply on each
02:19 * mugwump would just bounce them for not being small and independent :->
02:19 allison mugwump: we give new developers more grace :)
02:19 rurban hopefully you apply the important parts so that trunk works and can be installed at least.
02:19 allison rurban: I applied several independent changesets that could cleanly apply to trunk/
02:20 rurban I can make easily 100 patches out of it, but it is logically grouped to the tickets
02:20 allison rurban: I extracted them from the total diff on the trunk and made sure each passed all tests.
02:20 rurban but then they were applied in strange random order.
02:20 allison rurban: the problem is that the tickets depend on eachother.
02:20 rurban yes
02:21 allison rurban: each ticket should stand alone, be able to be applied without any of the other tickets
02:21 rurban but only two, the big makefile changes
02:21 allison rurban: yes, the makefile changes I didn't apply
02:21 rurban that's not possible. there must be an order.
02:21 allison rurban: also, the src/library.c changes I didn't apply, because they still crash
02:22 rurban similar to be p5p cleanup I made. he applied just the makefile changes but not the Configure changes. So it didn't work at all.
02:23 allison rurban: well, I had to introduce the change adding #IF and #UNLESS before the makefile changes from #CONDITIONAL_LINE and #INVERSE_CONDITIONAL_LINE could be made
02:23 rurban can you please paste the src/library.c errors? I tested on cygwin, debian and freebsd.
02:23 allison but, the conditional line changes should have been a completely separate patch from the install changes
02:24 rurban I needed them for the install logic
02:24 allison rurban: I'm taking your word for the crashes, it says in the comments
02:24 rurban you mean ,brak up the lib from the makefiles, okay, that's a point
02:25 chromatic Work in smaller increments.
02:25 rurban well, i have full time for two more days...
02:25 allison and do one set of changes for CONDITIONED_LINE to IF, and a separate set of changes for other makefile changes
02:27 allison rurban: I gave some specific suggestions for how to move forward on the remaining code in the branch in the email
02:28 allison rurban: do feel free to ask questions. Putting together good independent patches is a skill all good developers learn at some point, and a bunch of us here are glad to help.
02:28 Andy joined #parrot
02:31 mugwump my recommendation on that front is to use something like quilt
02:31 mugwump (or stgit if you're a git-svn user, or mq if you prefer mercurial, etc)
02:38 allison mugwump: he used quilt, but that doesn't actually force you to create sensible patch sets
02:38 allison mugwump: only a bit of programmer skill can do that
02:40 allison mugwump: the tricky part is that the order the developer thought of things is almost never the right order for patch sets
02:40 allison (which has always been my biggest argument with git)
02:50 kid51 My 2 cents:  I've been following the pdd30install_stage3 and have become concerned that the changes being planned there are too big for one branch.  This afternoon, e.g., I noticed vast changes in 'make test'.  But, OTOH, I can see that extracting patches from a branch still undergoing development and applying them to trunk is a recipe for trouble.
02:52 kid51 I concede that I haven't read the PDD in question, so I may not understand the scope of what had to be done.
02:52 Eevee joined #parrot
02:57 kid51 My 3rd cent:  Other than issues already documented in RT, Configure.pl must run cleanly at all times.  So any time a warning or failure shows up there, immediate attention is required.
03:06 mugwump allison: yes.  having quilt-like features are essential though for re-ordering hunks through the incremental patch sequence as it is built
03:06 mugwump of course the programmer skill to built the incremental sets should go without saying..
03:24 kid51 Parroteers:  feedback requested on this:  http://use.perl.org/~kid51/journal/38219
03:25 allison kid51: I've now applied all changes from pdd30install_stage 3 that will be applied to trunk. All remaining changes I've asked Reini to split into smaller patch sets.
03:26 pmichaud kid51:  the answer to your second question is thus far best answered by http://www.rakudo.org/2008/12/rak​udo-perl-now-passing-over-5.html
03:26 shorten pmichaud's url is at http://xrl.us/bebhyp
03:26 pmichaud kid51:  if parts of your question are left unanswered, then let me know which and I'll post answers.
03:27 kid51 Well, *you* were, of course, the person that post was primarily intended for :-)
03:28 pmichaud does my post adequately answer the second question?
03:28 allison kid51: and agreed on Configure.pl running cleanly at all times. My bad in this case, because I didn't see the warning when I applied the patch.
03:29 kid51 pmichaud:  Part 2 I dig.  It's graphic.  And for this purpose I'm looking for something that makes a strong first impression.
03:29 kid51 Something that says, "If you don't like this, then RTFM."
03:29 mugwump kid51: gosh there was a lot of FUD along those lines on the /. post about perl.git too
03:30 pmichaud of course, the graphic is out of date -- more up-to-date graphs are at http://www.pmichaud.com/perl6/  and http://www.rakudo.de/
03:31 kid51 pmichaud:  Well we should figure out a way to have the latest graph at rakudo.org -- because in these situations, I need to be able to remember a web address quickly.
03:31 pmichaud yes, I need to get with Andy and find out what we can do to have some permanent pages set up on rakudo.org
03:31 pmichaud either that or we'll need to point people to the perl6/rakudo wiki
03:32 kid51 allison:  And I didn't see it at first either, because I was focusing at that moment on things that are post-configuration and hence don't require my compulsive 'make realclean'.
03:32 kid51 A cron job that updates it nightly would be good.
03:33 Andy pmichaud: I"m thinking of switching Rakudo.org to Drupal over MT
03:33 kid51 A somewhat related question I got posed today at this Linux meetup was:  "Why doesn't Perl just build on the Java virtual machine?"
03:33 Andy "just"
03:34 pmichaud Andy: Drupal could work too.
03:34 Andy prob'ly more suited towards publishing pages
03:34 kid51 I knew enough to respond by asking:  "The JVM:  is that open-source?"  Response:  "It is now."
03:34 Andy SO MUCH I CAN DO WHEN BOOK IS DONE
03:34 ask_ joined #parrot
03:35 * kid51 wonders what BOOK Andy is writing.
03:35 Andy oh good golly
03:35 pmichaud as for your first question, I'd probably respond with something like "oh, when did the Perl 5 specification finish?"  ;-)
03:35 Andy http://www.amazon.com/Land-Te​ch-Job-You-Love/dp/1934356263
03:35 mugwump kid51, audreyt posed a similar question, why did VM development have to stall language design, before writing pugs
03:36 pmichaud I don't know that VM development stalled language design.  AFAICT, what stalled language design was implementation.
03:36 tetragon joined #parrot
03:36 kid51 pmichaud:  That sort of response is a bit too esoteric for the kind of situation I'm describing.
03:37 pmichaud it's a fallacy to think that language design completely precedes or is independent of implementation in this case.
03:37 mugwump sure, pragmatically you consider implementation when designing
03:37 pmichaud kid51: it's not really intended as an esoteric response.  People have this mythical idea that we stabilize language design and then build an implemenetation.  But that's not really how it works.
03:38 pmichaud I'd say that 80% of the language design changes over the past three years have been in direct response to things discovered in the process of making an implementation.
03:40 kid51 pmichaud:  I know the esotericity (?) is unintended.  But the people who pose this question are, to a greater or less extent, looking to bait me.  I don't want to get into the game of out snarky-ing them.  I need an answer I can give with a straight face and force them to drop their attempts to bait me and to engage in a serious discussion.
03:42 pmichaud then the answer is "the test suite for Perl 6 needs a lot more tests, and Rakudo covers about 60% of the tests we do have."
03:42 kid51 pmichaud:  In other words, I want to provide a response that changes the tone of the discussion to one that is respectful of what we've accomplished so far and curious about the next steps.
03:42 chromatic I take software development advice from people who haven't tried to build a new language on a new virtual machine with almost completely no money somewhat less than seriously.
03:44 jimmy joined #parrot
03:44 pmichaud at our current rate of progresses (June 2008 to present), we would expect to be passing ~15,000 tests by the end of 2009.
03:44 kid51 chromatic:  Well, these people aren't even going so far as to offer advice.  But my other concern is that I want to recruit other people *in New York City* to work on the Parrot project.  'cause just working online gets awfully lonely.  I enjoyed this Linux meetup today for the same reason that I enjoy our hackathons:  F2F hacking.
03:45 chromatic My best response is "How long *should* it take to write this software?"
03:46 chromatic Then keep asking for details.
03:46 pmichaud the typical answer to that would be "eight years is too long."
03:46 pmichaud (I don't agree with that answer, but that's what it would be from a baiter)
03:49 chromatic Okay, how long should it take to write a grammar engine which supports lexically scoped modifications?
03:49 kid51 More specific to Parrot:  We could use a demonstration of one language built on Parrot using libraries from another.  That, in addition to the speed of register-based design, was, as I recall, part of the initial 'promise' of Parrot.
03:49 chromatic Oh, and you have zero dollars to do it.
03:49 chromatic But Pheme did that in 2006!
03:49 pmichaud kid51: that's Parrot's goal for July 2009.
03:50 kid51 chromatic:  I understand where you're coming from by citing the dollars attached.  But I don't want to conduct the discussion on that turf, if only because I'm soliciting people's volunteer efforts.
03:50 kid51 July 2009, ie. 1.5?
03:50 mugwump how solvent is the parrot foundation these days?
03:50 mugwump or, is it solvent yet, I guess
03:50 pmichaud kid51: I'm assuming that sort of thing is what we mean by "language interoperability"
03:50 kid51 The Parrot Foundation is so new that it probably has 0 funds.
03:51 pmichaud kid51: tsk -- at least read the parrot foundation news blog :-)
03:51 kid51 pmichaud: Yes.  What would be a nice would be a lang interop demonstration that someone could run at a local user group meeting.
03:52 chromatic It seems to me that saying "It should take X periods of time" depends very heavily on the available amount of ideal work units.
03:52 chromatic When everyone's a volunteer, the number of predictable work units is zero.
03:53 pmichaud kid51: I suspect we'll be there in July.  In the meantime, we do at least have mod_parrot, which can have multiple languages running in the same interpreter (and communicating with or via Perl 6)
03:54 kid51 chromatic:  Again, in these sorts of discussions, I don't really want to answer one question with another.  There's a risk that people will perceive that as intellectual one-ups-manship.  And, from a recruiting/collaborating POV, I want to avoid that as much as possible.
03:55 rurban_ joined #parrot
03:55 mugwump you certainly have to compare apples with apples, like comparing the development time put into jvm or .net
03:56 mugwump *plus* that developing Java
03:56 mugwump or C#
03:57 kid51 IIRC, JVM was *not* open-source at time of onset of Parrot development -- and people at meetup today said it was not completely open-source even today.  Correct?
03:57 chromatic C# being ten years old.
03:57 mugwump then look at the year it was written, way before .net - and COM+ was about Y2000 as well
03:57 mugwump s/written/proposed/
03:57 mugwump although COM dates back to 1993
03:57 chromatic The JVM wasn't anywhere near open source at the time of writing, and it's arguable that it's completely open now.
03:58 chromatic Certainly there's little chance we'd get to make changes to the JVM according to our needs.
03:58 kid51 chromatic:  Not *that* is an interesting point.
03:59 kid51 e.g., "How much influence will you, Mr Language Developer, be able to exert on the future development of the JVM or on .NET?"
04:00 chromatic Considering they're still debating whether to add support to the JVM to invoke a method when you don't know the type of the invocant at compile time, very little.
04:00 chromatic This is not a VM for dynamic languages.
04:00 kid51 ... which is another point.
04:00 chromatic You'd have to build a lot of Parrot on top of the JVM to make Perl 6 work.
04:01 kid51 Alright, my bedtime nears.  If y'all can synthesize any of this for comments to my use.perl post, I would appreciate that.
04:02 pmichaud kid51: keep bugging me until I do.  Tonight's not a good night for me to do that (I'm focused on branch update/merge)
04:25 jimmy JVM seems to be a stack machine, and parrot is a  register machine.
04:27 chromatic Not a huge difference to Perl 6 either way.
04:27 dalek r34953 | pmichaud++ | branches/rvar/compilers/pct/src/PCT:
04:27 dalek : [pct]:  Add .clone method to PCT::Node .
04:27 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34953
04:28 jimmy parrot is failed to build on windows xp with strawberry perl now.
04:28 dalek r34954 | pmichaud++ | branches/rvar/languages/perl6/src (2 files):
04:28 dalek : [rakudo]:  Add simple type constraints to attributes.
04:28 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34954
04:36 dalek r34955 | tene++ | branches/pct_hll (3 files):
04:36 dalek : [pct]: Accept a namespace for parsegrammar in HLLCompiler
04:36 dalek : [rakudo]
04:36 dalek : * Use a namespace for parsegrammar and parseactions
04:36 dalek : * Add a workaround for a scary crash
04:36 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34955
04:37 dalek r34956 | tene++ | branches/pct_hll (6 files):
04:37 dalek : Assorted updates all over to make things play nicer with HLLs.
04:37 dalek : Languages can get through compilation... don't actually run yet.
04:37 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34956
04:40 Tene pmichaud: I think I only have one item left...
04:42 dalek r34957 | tene++ | branches/pct_hll/languages/lolcode:
04:42 dalek : [lolcode]: Remove some debugging.
04:42 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34957
04:42 Tene pmichaud: the compiled things run, but in the wrong HLL.  If I add .HLL to the --target=pir output, it works.
04:43 Tene Oh, idea...
04:43 allison jimmy: what's the build failure message?
04:48 Debolaz joined #parrot
04:48 Tene Setting :hll on the PAST::Block works for lolcode, but not for rakudo...
05:36 dalek r34958 | tene++ | branches/pct_hll (6 files):
05:36 dalek : Fix some typos.  Looks like rakudo works in its own HLL pretty well now.
05:36 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34958
05:40 dalek r34959 | tene++ | branches/pct_hll/languages/perl6/t/pmc (4 files):
05:40 dalek : [rakudo]: Add some .HLLs to pir tests.
05:40 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34959
05:40 MariachiElf joined #parrot
05:42 Tene pmichaud: nevermind about earlier question.
05:51 TiMBuS joined #parrot
05:59 MariachiElf joined #parrot
06:03 particle joined #parrot
06:09 Tene Okay, I now have lolcode, rakudo, and cardinal in their own HLL namespaces.
06:09 jimmy joined #parrot
06:09 dalek r34960 | tene++ | branches/pct_hll/languages/cardinal (14 files):
06:09 dalek : [cardinal]: Use the 'cardinal' HLL namespace.
06:09 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34960
06:11 jimmy allison: see TT #130
06:13 dalek r34961 | pmichaud++ | branches/rvar/languages/perl6/src/builtins:
06:13 dalek : [rakudo]:  Handle multi-level namespace classes.
06:13 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34961
06:13 Tene Next I need to add :lang to rakudo's eval.
06:22 cotto joined #parrot
06:32 dalek r34962 | pmichaud++ | branches/rvar/languages/perl6/src/parser:
06:32 dalek : [rakudo]:  Throw exception on attempts to define attributes outside of classes
06:32 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34962
06:40 dalek r34963 | tene++ | branches/pct_hll (409 files):
06:40 dalek : Marge trunk into branch.
06:40 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34963
06:41 pmichaud Tene: can I review pct_hll before it's merged back to trunk?
06:41 Tene pmichaud: yes, please
06:41 pmichaud okay if I do it tomorrow?
06:41 Tene Sure.
06:42 flh joined #parrot
06:42 pmichaud excellent work on getting those languages to run in hll, btw.
06:42 pmichaud that's just... well, fantastic :-)
06:42 Tene pmichaud: available to discuss implementation of rakudo's eval handling the :lang parameter?
06:43 pmichaud my guess at this point is that :lang corresponds to a compiler name.
06:43 pmichaud eval('source', :lang<Cardinal>)
06:44 Tene can I just load_bytecode "languages/$lang/$lang.pbc"?  Do we need a central registry somewhere?
06:44 pmichaud I think we had decided that language .pbcs would end up in runtime/parrot/library/languages
06:45 pmichaud just a sec, I'll find the reference.
06:47 dalek r34964 | tene++ | branches/pct_hll/languages/perl6/src/builtins:
06:47 dalek : [rakudo]: Initial implementation of :lang for eval.
06:47 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34964
06:47 Tene With that patch, this works, which is exciting:
06:47 Tene eval('VISIBLE "O HAI"', :lang<lolcode>);
06:47 pmichaud Tene: http://irclog.perlgeek.de/par​rotsketch/2008-09-09#i_559140
06:48 pmichaud allison proposed a "load_language" opcode.
06:49 pmichaud for now you can shim in anything that works and isn't too much code, though.
06:49 pmichaud Until we get a load_language opcode I'm guessing I'll make a 'load_language' method on the Parrot HLLCompiler object (when it's written)
06:49 Tene As does this:
06:49 Tene eval('puts "lol"', :lang<cardinal>);
06:50 pmichaud okay, I wanna see APL work then :-)
06:52 Tene Working on it...
06:57 Tene pmichaud: is there :hll for STMTS, or just for Block?
06:58 pmichaud just Block at the moment, I think.
06:58 pmichaud does APL produce a ::Stmts?
06:58 Tene TOP returns a PAST::Op.
06:58 Tene I'll make it return a Block
06:58 pmichaud just put it inside of a Block
06:58 pmichaud (that's what the compiler does anyway.)
07:04 Tene pmichaud: the problem with APL is that it prints its return values instead of returning them.
07:04 pmichaud well, printing is the normal behavior, yes.
07:04 pmichaud it could probably print + return.
07:05 dalek r34965 | tene++ | branches/pct_hll/languages/APL (2 files):
07:05 dalek : [APL]: Move to an HLL namespace.
07:05 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34965
07:05 pmichaud even if it just prints for now, that's okay with me.
07:05 Tene for example:
07:05 Tene my $x = eval("X←8+3\nX÷2", :lang<APL>);
07:05 Tene returns undef into $x
07:05 Tene and prints 5.5 to stdout
07:05 pmichaud right.
07:06 Tene unless APL has a return operator...
07:07 pmichaud my $catchpir := "    get_results '0', $P0\n    $S0 = $P0\n    print $S0\n
07:07 pmichaud exit 1\n";
07:07 pmichaud just change that exit 1  so that it does   .return ($P0)
07:07 pmichaud maybe that will be enough.
07:07 pmichaud actions.pm:21
07:08 Tene nope, doesn't work
07:08 uniejo joined #parrot
07:09 Tene I think I need to pop off the last item in the statement list and change it into a return op
07:10 pmichaud no, that's not entirely it either
07:10 pmichaud there's a 'try' node involved here for some reason.
07:10 pmichaud I think it's to catch domain errors.
07:12 pmichaud maybe need to add a return op to the statementlist
07:12 Tene This works:
07:12 nopaste "tene" at 67.186.244.107 pasted "APL patch to return values" (19 lines) at http://nopaste.snit.ch/15193
07:12 Tene That doesn't print, though.
07:13 Tene Wait, I lied.
07:13 pmichaud you definitely don't want to .pop
07:13 Tene I left off the .push()
07:13 Tene No, that doesn't work.  You're right.
07:15 pmichaud in tools/gen_operator_defs.pl, modify the 'aplprint' sub so that it returns the value printed.
07:15 pmichaud that ought to do it.
07:15 pmichaud then if aplprint gets called, we still get the result value back.
07:16 Tene Yes, it both prints and returns.  Which is okay, but suboptimal.
07:16 pmichaud that's the APL spec, though.
07:16 pmichaud APL says that any expression that isn't an assignment prints the result.
07:16 Tene nodnod
07:17 pmichaud I'd rather keep APL true to spec at this point.  Besides, we get the point across :-)
07:17 Tene nodnod
07:17 dalek r34966 | pmichaud++ | branches/rvar/languages/perl6/src/parser:
07:17 dalek : [rakudo]:  Add private method declarations.  Also clean trailing spaces.
07:18 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34966
07:18 pmichaud okay, I need a nap for a while.  I'll look over the pct_hll branch stuff when I re-awake.
07:18 Tene in rakudo, t/pmc/perl6multisub-type.t fails, not sure why
07:18 Tene spectest_regression looks nice to far, though
07:19 pmichaud it's probably looking for some things in the wrong hll namespace.
07:19 Tene pmichaud: one last thing...
07:19 Tene what's the rakudo syntax for use for another lang?
07:19 pmichaud rakudo, or Perl 6?
07:19 Tene eh, whichever
07:20 pmichaud well, I think officially it's "eval" :-)
07:20 Tene unofficially we could add use Foo :lang<...>; ?
07:20 pmichaud for inline language support it'd likely be something like   Q:APL   but we'll need some heavy-duty parser support for that.
07:21 pmichaud oh
07:21 pmichaud for 'use'   it's   use Foo:from<lang>
07:21 Tene Ah.
07:21 Tene Is that syntax okay in rakudo right now?
07:21 * Tene looks.
07:21 pmichaud no.
07:21 pmichaud I don't think we're parsing the colon stuff in names yet.
07:22 Tene Is that coming sometime?
07:22 pmichaud yes, not too long.
07:22 Tene kk
07:22 pmichaud how much had to change in rakudo to get hll to work?
07:22 Tene Not very much
07:22 pmichaud okay, good.
07:23 Tene a few .HLL decls, s/String/parrot;String/ and such in parent=> decls, (more)
07:23 pmichaud while I'll definitely be in favor of merging the other pct_hll stuff to trunk, I might want to hold off for rakudo's hllification until after rvar is merged back to trunk.
07:23 Tene pass namespaces for parsegrammar and parseactions
07:23 Tene Sure.
07:23 pmichaud but that won't be long, and if there aren't many changes, then it should be easy to do.
07:23 Tene should be
07:23 Tene ETA for rvar?
07:23 pmichaud the :lang mod to eval would still work even if Rakudo is in the Parrot branch
07:24 pmichaud sorry, in the Parrot HLL
07:24 pmichaud rvar is getting pretty close.  I think I just have roles, grammars, subsets, and WHENCE left to do
07:25 pmichaud but each new feature is getting easier and easier to add.
07:25 Tene "just" :)
07:25 pmichaud well, I'm not having to implement them from scratch, I'm just having to take what jonathan++ has already done and refactor them into the new structure
07:25 pmichaud it takes me longer to figure out what was happening in the original than it does to put it in rvar :-)
07:25 Tene I think I'm going to come up with some grammar for cardinal to use for 'require'.
07:26 pmichaud sounds like fun.
07:26 Tene Formally I'm supposed to work at $realjob tomorrow, so I might not be around much.
07:27 Tene spectest_regression is taking way too long to run, I think...
07:27 Tene not sure
07:28 pmichaud it often takes a while, depending onyour machine.
07:28 pmichaud after I get rvar merged (and write some reports) I think I'll work on the HLLCompiler refactor.  It's timely, and a prereq for the PGE changes I need to make.
07:30 Tene I'll clean this up a bit after review from you tomorrow and then work on a blog post.
07:30 pmichaud fantastic.  you've achieved a major parrot milestone.  :-)
07:30 pmichaud anyway, I'm falling asleep at my keyboard so I'd better make it to the bed while I still can :-)
07:30 Tene goodnight
07:31 Tene Oh, maybe I can get pipp in an HLL namespace too.
07:33 TiMBuS quick q: does parrot have an op or pmc method to get the max intval?
07:34 nopaste "tene" at 67.186.244.107 pasted "rakudo test_summary output from pct_hll branch for pmichaud++" (63 lines) at http://nopaste.snit.ch/15194
07:34 TiMBuS failing that, is there a macro with it defined so i can just make a quick op in C
07:46 chromatic I don't think there's an op or method.
07:47 chromatic PARROT_INTVAL_MAX in config.h might work though.
07:47 TiMBuS that sounds like it'd do
07:52 TiMBuS woop, works just fine
07:52 TiMBuS thanks chromatic
07:53 chromatic You're welcome.
08:02 dalek r34967 | petdance++ | trunk (2 files):
08:02 dalek : working on the more stringent perlcritic-cage target
08:02 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34967
08:05 dalek r34968 | rurban++ | trunk/config/gen/makefiles:
08:05 dalek : fix cygchkdll leftover issue with r34836
08:05 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34968
08:09 jimmy TT #130 fixed now?
08:12 rurban blib/lib is not created on mingw?
08:13 rurban jimmy: Your pasted cmdline is not correct. -Wl,-L "E:/pipp/ Parrot-dev/blib/lib"    -Wl,-L "E:/pipp/Pa rrot-dev/blib/lib"
08:15 elmex joined #parrot
08:17 rurban jimmy: what is the value of set P0["libparrot_shared"], in your config_lib.pasm?
08:17 rurban it is not created
08:18 nopaste "tene" at 67.186.244.107 pasted "Perl 6, Ruby, and APL in the same program" (3 lines) at http://nopaste.snit.ch/15195
08:23 lathos aExcellent.
08:23 jimmy rurban:set P0["libparrot"], "$(LIBPARROT_SHARED)"
08:24 rurban jimmy: P0["libparrot_shared"] ?
08:24 rurban I'm just setting up vanilla perl...
08:25 jimmy set P0["libparrot_shared"], "libparrot.dll"
08:25 rurban does "mingw32-make libparrot.dll" work?
08:25 jimmy wait
08:27 * jimmy had pasted it at TT #130
08:29 jimmy Is it readable?
08:29 rurban It is better to use {{{   code }}} in trac
08:29 dalek r34969 | tene++ | branches/pct_hll/languages/APL (2 files):
08:29 dalek : [APL]: Return results in addition to printing them.
08:29 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34969
08:29 cxreg is anyone maintaining an up to date apt source for parrot?  alioth is pretty out of date and sam didn't get a response when he asked to update it
08:29 jimmy should I repaste it?
08:29 rurban nope, I see the problem
08:29 dalek r34970 | tene++ | branches/pct_hll/languages/pipp (2 files):
08:29 dalek : [pipp]: Move to the 'pipp' HLL NameSpace
08:30 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34970
08:31 rurban First I have to fix the vanilla distribution, ... The Config logic is broken there
08:31 rurban I'm building now...
08:37 jimmy cxreg: I don;t know,
08:38 rurban jimmy: I can reproduce your problem. I'll fix ASAP
08:38 jimmy I used strawberry perl.
08:39 rurban That's basically the same as vanilla. strawberry has more cpan libs
08:39 jimmy Iet me try it again
08:39 rurban The problem is -Wl,-L <prefix>/blib/lib => -Wl,-L <prefix>
08:39 dalek r34971 | tene++ | branches/pct_hll/languages/pynie (2 files):
08:39 dalek : [pynie]: Start using the 'pynie' HLL namespace.
08:39 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34971
08:40 rurban I'm just wondering why mingw don't uses any import lib, like libparrot.lib
08:42 allison joined #parrot
08:42 jimmy rurban: I know nothing about it.
08:43 rurban Allison: I just fixed up cygchkdll for cygwin, and I'm working on fixing mingw right now
08:46 jimmy rurban: I had pasted failed message after running 'make realclean' at TT #130.
08:47 rurban jimmy: I'm just testing my fix for youi. This will need some time
08:47 jimmy 'make reaclean && perl Configurel.pl && make
08:48 jimmy I see.
08:52 iblechbot joined #parrot
08:54 rurban jimmy: The problem is that I can immediately fix it for you, but then it is not to good installable anymore.
08:55 Tene allison: around?
08:56 allison Tene: yes
08:56 Tene allison: nevermind, I have a workaround.
08:56 allison ok
08:57 * allison about to leave, total system fail (it thinks it has 80GB of virtual memory, with 7GB free disk space, and thrashing horribly)
08:57 jimmy rurban: That is nothing, my
08:58 Tene allison: ouch
08:58 allison rurban: the best solution is to simply revert r34940
08:58 dalek r34972 | tene++ | branches/pct_hll (3 files):
08:58 dalek : [pheme]: Use the 'pheme' HLL namespace.
08:58 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34972
08:59 allison rurban: if those changes weren't adequately tested in that combination, they we blow them away
08:59 Zaba joined #parrot
08:59 allison s/they/then/
08:59 rurban allison: I know. But then the libparrot_shared path is hardcoded and when installed you cannot compile anymore.
08:59 allison rurban: that's the way it worked before, so no loss
09:00 rurban I know, but I wanted to make it installable :)
09:00 allison rurban: later
09:00 rurban okay. I revert the mingw part for now. and fix it later.
09:00 allison rurban: there are quite a few install changes we're waiting on until they're more stable, this is just one more
09:00 allison rurban: good
09:01 jimmy I had build parrot.exe
09:02 jimmy built
09:04 dalek r34973 | tene++ | branches/pct_hll/languages/pheme:
09:04 dalek : [pheme]: Register pheme as the compiler for 'pheme' instead of 'Pheme'
09:04 dalek : to match the directory it's in.
09:04 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34973
09:11 Tene pmichaud: couldn't 'Q:APL' come from something like APL.pm adding a rule to the grammar at compile time?
09:16 Zaba joined #parrot
09:16 allison joined #parrot
09:16 rurban jimmy: can you try r34974?
09:16 dalek r34974 | rurban++ | trunk/config/init/hints:
09:16 dalek : fix mingw compilation - TT#130 - and add vanilla cfg
09:16 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34974
09:19 jimmy ok
09:20 Tene allison: I was originally going to ask about modifying TGE to allow specifying the HLL ns of the grammar you're deriving from.  I worked around it by just exporting ['TGE'] to the current HLL ns beforehand.
09:23 dalek r34975 | cotto++ | trunk/languages/pipp/config/makefiles:
09:23 dalek : [pipp] update test-pmc target, add to make test
09:23 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34975
09:23 rurban My TT#130 mingw fix allows compilation with an already installed shared libparrot. So it's better than before.
09:26 ChrisDavaz joined #parrot
09:28 jimmy rurban: ok is not that ok
09:28 rurban Still not compiling?
09:28 jimmy yes
09:28 jimmy not
09:29 rurban did you do archclean and realclean?
09:29 jimmy just make realclean && perl Configure.pl && make
09:30 rurban what is set P0["libparrot_ldflags"] in your config_lib.pasm?
09:30 jimmy set P0["libparrot_ldflags"], "libparrot.dll"
09:31 rurban I see. Wait, I'll have to check
09:31 jimmy ruiban++
09:33 alvar joined #parrot
09:41 rurban jimmy: my mingw smoke is at http://smolder.plusthree.com/app/pu​blic_projects/report_details/12210
09:41 shorten rurban's url is at http://xrl.us/bebijw
09:42 rurban jimmy:what is your ALL_PARROT_LIBS line in Makefile?
09:42 jimmy ALL_PARROT_LIBS     = libparrot.dll $(ICU_SHARED) $(C_LIBS)
09:45 jimmy maybe downloading strawberry perl can reproduce the failure.
09:46 rurban No, I can reproduce it also. Just have to find out how to do that best.
09:47 jimmy I thought you can not.
09:48 rurban I'm playing with the best strategy for libparrot_ldflags. The former failure I had because there was still a parrot process around
09:48 rurban It's either '-Wl,-L$(BUILD_DIR) libparrot.dll' or '-Wl,-L$(BUILD_DIR) libparrot.lib'
09:50 cotto joined #parrot
09:50 jimmy I  like  best strategy. :)
09:51 rurban can you try: config/init/hints/mswin32.pm line ~236: libparrot_ldflags   => '-Wl,-L$(BUILD_DIR) libparrot.dll',
09:53 Zaba joined #parrot
09:58 allison Tene: modifying TGE to support the HLL namespace is the right way to go eventually, but glad you found a work around for now
09:59 braceta joined #parrot
10:01 Tene I'm very pleased with the pct_hll branch.
10:01 Tene Need sleep now, though.
10:07 jimmy rurban: I will try it.
10:08 rurban Wait, It will not work for pbc_to_exe
10:08 rurban I'm currently testing      vlibparrot_ldflags   => "\"$build_dir\\libparrot.dll\"",
10:08 rurban libparrot_ldflags   => "\"$build_dir\\libparrot.dll\"",
10:09 rurban Plus I added the importlib for mingw.
10:09 rurban But the importlib is only needed when being installed
10:10 jimmy what's the solution before?
10:10 rurban -Wl,-L$(BUILD_DIR) libparrot.dll will fail within pbc_to_exe complation
10:11 rurban -Wl,-L$(BUILD_DIR) libparrot.dll will fail within pbc_to_exe compilation
10:11 rurban It's still a little bit of a mess...
10:12 jimmy what's the solution before 34940?
10:13 jimmy actually, I don't know what happened.
10:14 rurban I switched the default to being directly linked, not via -lparrot, because this is disturbed by -L/usr/lib picking up an already installed parrot. of you wanted to know exactly :)
10:14 jimmy > libparrot_ldflags   => "\"$build_dir\\libparrot.dll\"" does not work.
10:15 rurban oh, works good for me.
10:16 jimmy so I think you could download the strawberry perl
10:17 jimmy maybe it is very strange.
10:17 nopaste "rurban" at 212.183.49.253 pasted "mingw-tryout.patch" (68 lines) at http://nopaste.snit.ch/15196
10:18 rurban I have about 50 different perls around... strawberry is also somewhere
10:22 rurban The above paste should work on every mingw perl, if it's vanilla, strawberry or self-compiled
10:22 jimmy wow
10:22 rurban tyring now with strawberry-perl-5.10.0.3
10:22 jimmy Iet me give it a try.
10:23 jimmy I am using strawberry-perl-5.10.0.3-ddrive.exe
10:29 rurban yes, confirmed: strawberry is a plan vanilla with just some cpan modules added. same system as vanilla
10:31 rurban But TAP::Harness::Archive is missing.
10:35 jimmy rurban: works now with 15196
10:38 jimmy but why there is libparrot.lib.
10:41 rurban For r34976 I'm sending now the mingw smoke report also
10:41 dalek r34976 | rurban++ | trunk/config (2 files):
10:41 dalek : More mingw fixes, analog to cygwin:
10:41 dalek : - link directly to dll to protect against already installed libparrot
10:41 dalek : - add importlib for mingw for easier installation
10:41 dalek : - force gcc.exe to gcc for Makefile check
10:41 dalek : Tested with vanilla and strawberry perl
10:41 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34976
10:46 dalek r34977 | kjs++ | trunk/compilers/pirc/src (2 files):
10:46 dalek : [pirc] work on parser. There may be a bug in bison, but added a workaround.
10:46 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34977
10:47 tomyan joined #parrot
10:47 kj joined #parrot
10:48 rurban latest mingw t/pmc/complex fails:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/12225
10:48 shorten rurban's url is at http://xrl.us/bebimw
10:49 jimmy yes, it failed all the time.
10:49 rurban I'll fix now the complex problem: only two wrong tests
10:50 Zaba joined #parrot
10:50 jimmy rurban:
10:51 nopaste "jimmy" at 220.231.152.66 pasted "another patch for rurban" (20 lines) at http://nopaste.snit.ch/15197
10:51 jimmy this patch works well too.
10:52 jimmy without http://nopaste.snit.ch/15196
10:53 jimmy i hate libparrot.lib.
10:55 rurban you will need libparrot.lib when being installed and you want to do link with -lparrot
10:56 jimmy hope so. I don't know why only win32 and cc==gcc.
10:57 rurban you can always link directly to the dll as we do in our internal build, but there's no search logic for dll's, only .lib
10:57 jimmy seems that it is for gcc only
10:57 rurban msvc has it's own importlib logic. I don't want to touch that
10:57 jimmy http://nopaste.snit.ch/15197 works well for me.
10:57 rurban ron should try that
10:58 rurban good, thanks.
10:59 jimmy these two lines must be added. other is unuseful.
11:00 dalek r34978 | kjs++ | trunk/compilers/pirc/src (5 files):
11:00 dalek : [pirc] better error message for unrecognized sub pragmas.
11:00 dalek : + add an error alternative to parser, so it can try to continue after the first error.
11:00 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34978
11:03 jimmy and let me give a try with removing mingw-make condition
11:06 rurban you mean the makefile? this is completely ignored in our build. we only need it when being installed
11:07 ruoso joined #parrot
11:21 jimmy rurban++
11:25 dalek r34979 | kjs++ | trunk/compilers/pirc/src (5 files):
11:25 dalek : [pirc] disallow $P0. $P1(), $P0 .$P1() and $P0 . $P1(). Give proper error messages.
11:25 dalek : Fix a bug in the parser (action method only).
11:25 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34979
11:26 jimmy should we remove parrot_config.* after make clean?
11:27 Lorn joined #parrot
11:27 donaldh joined #parrot
11:31 jimmy seems that parrot_config.* is not removed by 'make clean'
11:33 mberends joined #parrot
11:40 dalek r34980 | kjs++ | trunk/compilers/pirc/src (3 files):
11:40 dalek : [pirc] improve error checking in PASM mode.
11:40 dalek : + some refactoring of regular expressions.
11:40 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34980
11:46 masak joined #parrot
11:46 kj joined #parrot
11:53 rurban_ joined #parrot
12:12 PacoLinux joined #parrot
12:28 braceta joined #parrot
12:35 dalek r34981 | rurban++ | trunk/lib/Parrot:
12:35 dalek : Fix msvc warning in t/src/compiler.t:
12:35 dalek :   LINK : warning LNK4044: Nicht erkannte Option "Lblib\lib"; ignoriert
12:35 dalek :   And we don't want to use /LIBPATH:$PConfig{blib_dir} here, only for static.
12:35 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34981
12:54 dalek r34982 | rurban++ | trunk/lib/Parrot:
12:54 dalek : Fix fatal [perl #58704] [BUG] t/src/compiler.t failures with VC++ / Win32
12:54 dalek : - added -DPARROT_IN_EXTENSION on MSVC. To be tested on borland.
12:54 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34982
13:00 dalek r34983 | kjs++ | trunk/compilers/pirc/src (7 files):
13:00 dalek : [pirc] value of basic .consts are now returned by lexer.
13:00 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34983
13:18 gaz joined #parrot
13:59 register joined #parrot
14:11 gryphon joined #parrot
14:14 jonathan hi all
14:14 * jonathan is working on bytecode annotations
14:16 tewk jonathan++
14:18 Wknight8111 joined #parrot
14:19 dalek r34984 | Whiteknight++ | trunk/docs/book:
14:19 dalek : [Book] Two small modifications, preparing to include more info about LexPads
14:19 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34984
14:22 Coke (hll/pct) that removes one of the big blockers to switching tcl to pct.
14:35 jonathan My word, how slow can merging be... :-S
14:39 Wknight8111 what are you merging?
14:42 jonathan Updating my bcanno branch with latest trunk.
14:45 Coke rurban: note, borland isn't one of our core targets for win32.
14:45 Coke (not that getting it to work wouldn't be nice)
14:53 dalek r34985 | jonathan++ | branches (1168 files):
14:53 dalek : Updated bcanno branch with latest from trunk.
14:53 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34985
14:53 Wknight8111 what does the bcanno branch do?
14:56 jonathan Wknight8111: Bytecode annotations, so we can have HLL line/file info.
14:56 Wknight8111 oh, very nice
14:57 * Infinoid hasn't made any recent progress with bytecode at all, sadly.
15:04 Coke jonathan: ah, that'll be much nicer than my fallback plan.
15:05 Coke ... if that works for something like tcl that is mostly runtime dispatch.
15:07 jimmy joined #parrot
15:09 dalek r34986 | jonathan++ | branches/bcanno/src:
15:09 dalek : [bcanno] Resolve a merge conflict.
15:09 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34986
15:12 jimmy rurban: I know what happened now. mswin32.pm is really a bit complicated.
15:12 dalek r34987 | jonathan++ | branches/bcanno/src:
15:12 dalek : [bcanno] Resolve more merge conflicts, s/PIO_/Parrot_io_/ for annotations dump.
15:12 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34987
15:13 dalek r34988 | jonathan++ | branches/bcanno/src:
15:13 dalek : [bcanno] Remove extraneous underscore in last ci.
15:13 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34988
15:14 jonathan Coke: Don't see why not, provided the PIR you generate has the right things in it.
15:14 jonathan Phew. Back to having my branch building again.
15:19 Coke jonathan: part of the potential problem is that I'm not always generating PIR; oft times I am merely invoking things from the runtime library.
15:20 Coke but I will hold out hope (and thereby avoid spending any cycles thinking about it. =-)
15:20 dalek r34989 | infinoid++ | trunk/lib/Parrot:
15:20 dalek : Clean up an old, commented out merge conflict in Parrot::Configure.
15:20 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34989
15:22 dalek r34990 | Whiteknight++ | branches/jit_h_files/src/jit/i386 (2 files):
15:22 dalek : [jit_h_files] move over another function, passes all tests.
15:23 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34990
15:24 jonathan Coke: If it doesn't work for Tcl, then we can look into why not and work out a solution. :-)
15:25 kj jonathan: hi, long time no see
15:25 jonathan kj: Hi! :-)
15:25 jonathan Yes, I was having Christmas/new years break, had family here to entertain, etc.
15:26 pmichaud message Tene the pct_hll branch changes all look great!  I'm comfortable with merge-to-trunk for everything except rakudo (I want to merge the rvar branch first)
15:26 purl Message for tene stored.
15:26 pmichaud message Tene it's okay to implement eval :lang in Rakudo in trunk, though :-)
15:26 purl Message for tene stored.
15:26 kj ah very good. Hope you recharged for a new season of hacking :-)
15:26 jonathan Yes!
15:26 jonathan Already digging into fighting with IMCC. ;-)
15:27 kj pirc got some new ammunition ;-)
15:27 jonathan (And relying in you to do a better, less hacky job of .annotate in PIRC.)
15:27 kj actually, just doing a co of bcanno branch to see what you're doing :-)
15:28 pmichaud jonathan: I have a question for you on objects/inheritance
15:28 pmichaud t/spec/S12-class/parent_attributes.t:25 looks wrong to me
15:29 dalek r34991 | jonathan++ | branches/bcanno/compilers/imcc (4 files):
15:29 dalek : [imcc] Fix imcc.y and compile it and imcc.l.
15:29 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34991
15:29 jonathan I'd have expected method set($v) { $.x = $v }
15:30 pmichaud would that work?  $.x isn't rw
15:30 jonathan Right, it would need to be.
15:30 pmichaud okay.
15:30 jonathan I think $!x shoudl only be lexically visible.
15:30 jonathan (Rakudo may well not enforce that right now.)
15:30 pmichaud that's what the spec says
15:31 pmichaud rvar enforces it :-)
15:31 jonathan Ah, good.
15:31 pmichaud okay, I'll change the test then.
15:31 jonathan Yes, agree.
15:32 pmichaud jonathan++ # thanks
15:34 jonathan pmichaud++ # fixing rakduo so that it fails bad tests
15:34 kj jonathan: IIUC, annotations are stored in bytecode as pairs of 2 integers; the first integer is an index into the constant table indicating the key, the second integer is an index into the constant table indicating the value
15:35 kj (that's only the annotations stuff, not the "annotation group" stuff, haven't read that yet)
15:37 sjn jonathan: thanks for your talk submission, btw :D
15:37 * pmichaud needs to get his talk submission in.
15:37 jonathan sjn: I submitted for four different conferences this weekend. ;-)
15:38 sjn jonathan: feel free to submit more for NPW ;-)
15:38 jonathan sjn: I'm pondering doing that.
15:38 jonathan Would there be interest in a kinda mini-Perl 6 tutorial?
15:38 jonathan I'm doing one at the Belgian Perl Workshop.
15:39 sjn could be, give us a writeup and we'll figure it out ;-)
15:39 jonathan kj: Not quite - there are three values.
15:40 jonathan offset, key (but that's not an index into the constants table, but the annotation keys section), and value.
15:41 kj ah yes, I misread. I see now. But they're not really inline with the instructions in the code segment right? I mean, annotations are stored in a separate segment
15:43 jonathan Right.
15:43 jonathan I'm just stashing them as instructions from an IMCC point of view
15:43 jonathan But we don't emit anything into the bytecode in pbc.c
15:43 jonathan Or won't.
15:43 jonathan Still working on that bit.
15:48 dalek r34992 | Whiteknight++ | branches/jit_h_files/src/jit/i386 (2 files):
15:48 dalek : [jit_h_files] a few more functions moved over
15:48 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34992
15:49 * Coke wonders what's going on with these slurp commits.
15:51 * kj wonders what's a slurp commit
15:53 jhorwitz joined #parrot
15:59 Coke e.g. r34947.
15:59 Coke ah, there's a ticket in the commit msg.
16:06 * Coke posts his self-de-confusing comment to the ticket.
16:09 dalek r34993 | jonathan++ | branches/bcanno/compilers/imcc (2 files):
16:09 dalek : [imcc] Get annotations now being passed through to code generation stage, so we can start work on storing them.
16:09 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34993
16:13 dalek r34994 | kjs++ | trunk/compilers/pirc/src (5 files):
16:13 dalek : [pirc] improve support for annotations.
16:13 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34994
16:15 davidfetter joined #parrot
16:30 * Coke presses the "build is broken" button.
16:30 Coke (ok, it's make test, not the build. still)
16:30 Coke https://trac.parrot.org/parrot/ticket/131
16:39 hercynium joined #parrot
16:39 dalek r34995 | jonathan++ | branches/bcanno/src:
16:39 dalek : [core] Correct dump output for annotations segment to be consistent with othesrs.
16:39 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34995
16:40 dalek r34996 | jonathan++ | branches/bcanno/compilers/imcc:
16:40 dalek : [imcc] Create annotations segment when needed, along with initial group.
16:40 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34996
16:42 jhorwitz mmmmm, tasty tasty annotations
16:43 kj jonathan: currently there's a SEGMENT_NAME #define for directory, fixup, constant and bytecode.
16:44 kj should there be one for ANNOTATIONS?
16:44 kj (in packfile.h)
16:44 jonathan kj: Perhaps.
16:45 Coke (i wonder how many spec tests for tcl I could pass if I could give annotation information in the error messages)
16:45 kj also, maybe it should be created as part of create_default_segments, but then again, maybe not as not all bytecode will have annotations
16:45 jonathan I worry about the way we associate debug segs with code segs (by name) at the moment...it seems fragile.
16:45 jonathan I think we need not bother creating it if we have no annotations.
16:46 jonathan No point creating/packing/unpacking it otherwise.
16:48 dalek r34997 | moritz++ | trunk/languages/perl6/t:
16:48 dalek : [rakudo] track file merges/moves in t/spectest.data. Also add a few more test
16:48 dalek : files.
16:48 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34997
16:57 flh joined #parrot
17:11 jan joined #parrot
17:15 steffen joined #parrot
17:17 steffen hi everyone, i've been trying to get parrot to execute some perl6 for me, but i can't get it to make the perl6.pbc file, can anyone help me?
17:18 jonathan Probably. :-)
17:18 Infinoid hi steffen, you're in the right place.  can you paste your build log to us at http://nopaste.snit.ch/ ?
17:19 mberends did you manage to make parrot ok?
17:19 steffen i'm not sure lol
17:19 steffen i installed parrot 0.6.1 with gentoo's package manager
17:19 mberends nonononono
17:20 mberends that's way too old
17:20 steffen thought that might come ;)
17:20 steffen so i tried building parrot 0.8.2 from the downloads but that gave an error, let me just find that one sec
17:20 steffen got it, just gonna post it to that link you posted
17:21 dalek r34998 | kjs++ | trunk/compilers/pirc/src (2 files):
17:21 dalek : [pirc] store annotations in circular list. Add function to bcgen module, copied from jonathan++ 's annotation work.
17:22 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34998
17:22 nopaste "steffen" at 94.192.245.178 pasted "parrot 0.8.2 buildlog" (14 lines) at http://nopaste.snit.ch/15198
17:22 steffen i posted the last bit, i can copy it all if you want
17:23 steffen i'm quite experienced with gentoo but because portage is so great i always shied away from manually installing things with make so i might've made a silly mistake
17:23 Wknight8111 joined #parrot
17:24 mberends probably not needed, if you're happy to start again from scratch
17:24 steffen yeah sure
17:24 steffen i'll uninstall parrot 0.6 with portage as well make sure that doesn't get in the way
17:25 mberends good idea, and then make sure you have subversion client installed
17:25 steffen got that
17:26 mberends btw, how come your gentoo still has perl 5.8.8 ?
17:26 steffen its the latest gentoo has
17:26 steffen just checking bugzilla for 5.10
17:28 steffen ok i found some ebuilds for perl 5.10 should i try to install that?
17:28 Wknight8111_ joined #parrot
17:28 mberends no need, just try the subversion install line from parrot.org
17:29 mberends you can update to perl 5.10 later, it's desirable but not essential for parrot
17:29 steffen ok checking it out now
17:30 contingencyplan joined #parrot
17:31 mberends after subversion completes your parrot directory, run perl Makefile.pl in there
17:31 steffen done, it suggests gmake next should i do that?
17:32 mberends yes
17:32 steffen emerging parrot 0.6 only took 3 minutes so this shouldnt be too long hopefully
17:32 ruoso joined #parrot
17:33 mberends we're patient...
17:33 steffen thanks :)
17:34 Infinoid mberends: it might be a while for gentoo to get 5.10.  I've hacked it into my gentoo install, but it breaks some things
17:34 mberends pity about that
17:34 Infinoid its worth it in the long run...
17:35 steffen yeah updating programming languages is quite difficult for gentoo
17:36 Infinoid if portage had direct support for CPAN, that would fix a lot of stuff.  there's some mention of adding that to paludis, but so far that seems to be vapor
17:36 Infinoid g-cpan is a nice hack but far from complete
17:37 steffen that would be very nice, stop duplicating so much work
17:37 steffen gmake just finished btw
17:37 Infinoid indeed
17:37 mberends after gmake is done, try gmake test, and if that's happy, gmake perl6
17:37 steffen i think, it doesnt give any success indicator it just went back to command line
17:37 steffen trying test now
17:37 Infinoid great
17:37 steffen looks good so far
17:39 mberends if gmake perl6 looks ok, then cd languages/perl6 and do a make test there
17:39 steffen ok
17:41 steffen still testing ;)
17:41 mberends and for good measure, in a separate shell do gmake spectest_regression in languages\perl6 - it takes even longer
17:42 steffen hehe its always a good sign if the tests take longer than the compile
17:43 Infinoid especially when they pass.
17:43 steffen lol yeah
17:43 steffen running this as a user should be ok right?
17:43 Infinoid correct
17:44 mberends your paths may differ, but here I also added: sudo ln -s /home/mydir/parrot/languages/perl6/perl6 /usr/local/bin/perl6
17:44 steffen thats a good idea yeah
17:44 Infinoid that's probably a better idea than "make install"
17:45 steffen yeah i dont like to use make install manually
17:45 steffen ok gmake test just finished and failed
17:45 steffen Failed 7/397 test scripts. 35/11685 subtests failed
17:46 mberends please nopaste the entire make test log
17:46 steffen ok
17:47 steffen stupid question again, does it produce a log file automatically?
17:47 mberends sorry, I meant the console transcript
17:48 mberends sometimes parrot goes unstable for short periods, then either the developers fix it or reverse the most recent changes
17:49 nopaste "steffen" at 94.192.245.178 pasted "parrot gmake test output" (429 lines) at http://nopaste.snit.ch/15199
17:49 steffen yeah makes sense
17:49 steffen i posted everything from the scrollback but the beginning was already gone
17:49 steffen i'm pretty sure the relevant bits are in there though
17:50 chromatic joined #parrot
17:51 Infinoid hmm.  did you build with the same user you tested with?
17:51 steffen yeah
17:52 mberends odd, the error messages claim 'cannot find -lparrot'
17:52 Infinoid I'm on x86-64 gentoo too, so I can try to reproduce the issue.  which subversion rev are you building from?  ("svn info" will tell you that)
17:53 steffen rev34998
17:53 steffen yeah i did the build and test in the same shell
17:53 Infinoid did you pass any parameters when you ran Configure.pl or Makefile.PL?
17:53 steffen no
17:54 Infinoid ok, one moment, lemme see if it works here
17:54 steffen just ran Makefile.PL, then gmake, then gmake test
17:54 steffen ok cheers :)
17:58 mberends this one beats me, but in the past a flaky toolchain did that to me on gentoo. now I'm on debian unstable, which is pretty stable anyway
17:58 Infinoid you do have some files in blib/lib/, right?  (libparrot.a  libparrot.so  libparrot.so.0.8.2)
17:59 Infinoid steffen: ok, I'm seeing the same issues
17:59 steffen i got libparrot.a  libparrot.so  libparrot.so.0.8.2
17:59 steffen hm i'll just load up my debian VM and try in that if i get the same error
17:59 dalek r34999 | jonathan++ | branches/bcanno (5 files):
17:59 dalek : [core][imcc] Store bytecode annotations in the packfile. This also tweaks a few other things, including associating the code and annotations segments when unpacking. Followed the model of debug segments, though may change both in the future.
17:59 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=34999
18:00 Infinoid the only -L in the gcc command line for these tests is /usr/lib64.  so it seems to be assuming parrot was installed, and that seems wrong.  any recent merges from pdd30-install branches or somesuch?
18:02 steffen not by me ;)
18:03 Infinoid steffen: this stuff worked fine for me a couple days ago, so I'm trying to figure out which patch broke it
18:03 steffen ok :)
18:03 mberends so would adding a -L to the local blib/lib/ in the appropriate Makefile fix this?
18:03 jonathan OK, break/dinner time, and afterwards more work on annotations. Might even have something working/useful by the end of the day.
18:03 chromatic It has to precede the /usr/libxx part, but it should.
18:04 Infinoid mberends: I think it was already there, trying to figure out the details now :)
18:06 ask_ joined #parrot
18:06 steffen im gonna try linking the files from blib/lib to /usr/lib64 and run tests again, might as well give it a shot :)
18:07 Infinoid that'll probably work.  in the meantime, I'm bisecting
18:07 dalek r35000 | Whiteknight++ | branches/jit_h_files/src/jit/i386 (2 files):
18:07 dalek : [jit_h_files] move a few more functions over.
18:07 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35000
18:07 Wknight8111 35000!
18:07 purl I don't like big numbers like that.
18:07 mberends 35000 factorial, yes, that's a big number even for pugs
18:08 Infinoid Wknight8111++
18:08 steffen would hate having to calculate that one without a computer
18:10 Tene 3^^^3
18:11 steffen can i find perl6 libs on cpan as well or is separate?
18:14 Infinoid separate, I think.  the Perl6:: stuff on CPAN is for adding perl6-like features to perl5
18:15 steffen yeah i think you're right
18:16 steffen is there a central place for perl6 yet? cpan6.org appears to be a placeholder
18:16 Infinoid good question, I don't know.  (I'm not really a perl6 guy.)  most of the modules I know of are in the parrot or pugs repositories
18:18 chromatic http://citeseerx.ist.psu.edu/vie​wdoc/summary?doi=10.1.1.59.1271
18:18 chromatic Context threading for VMs.
18:20 steffen ok with the stuff from blib/lib linked to /usr/lib64 gmake test runs fine
18:20 Infinoid great.  move on to languages/perl6, build and test there?
18:21 steffen had already started doing gmake perl6, someone said that earlier
18:23 Infinoid wow, they improved branch prediction by 95%
18:23 Coke_away (issues with parrot) see trac # 131
18:23 Coke_away shorten that
18:23 purl That URL is at http://xrl.us/bebjy9 [citeseerx.ist.psu.edu]
18:23 steffen yeah that seems pretty impressive
18:23 steffen coke:  was that for my problems?
18:23 chromatic Improved branch prediction could be a 10-15% performance improvement easily.
18:24 Infinoid thanks Coke
18:24 Coke steffen: https://trac.parrot.org/parrot/ticket/131
18:24 Infinoid yep, that's the issue
18:25 steffen thanks
18:27 steffen i'll post my testoutput to that bug as well
18:27 steffen and the workaround
18:27 purl it has been said that the workaround is to force Perl to use magical string
18:27 Infinoid the bug was introduced in r34981
18:27 steffen it seems my perl6 has just said hello world :)
18:27 mberends \o/
18:27 Infinoid -                    ? "$PConfig{rpath_blib} -L$PConfig{blib_dir} "
18:27 Infinoid +                    ? ("$PConfig{rpath_blib} " .
18:27 Infinoid +                      ($^O =~ m/MSWin32/ and $PConfig{cc} eq 'cl'
18:27 Infinoid +                         ? "" : "-L$PConfig{blib_dir} "))
18:29 steffen yeah it works :)
18:30 chromatic r30000 was 5 months ago.
18:32 steffen thanks everyone :) gonna let it finish the regression test and then add my info to the bugreport
18:32 Infinoid steffen: its ok, I've just committed a fix.
18:32 Infinoid steffen++
18:33 steffen even better :)
18:33 dalek r35001 | infinoid++ | trunk/lib/Parrot:
18:33 dalek : Fix a build error introduced in r34981 (precedence error).  This fixes TT #131.
18:33 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35001
18:33 Coke Infinoid: thanks for tracking that down. I got an email from kid51 about it earlier today, and only had enough tuits to verify and log.
18:33 Infinoid Coke: if you have a moment, please verify the fix?
18:36 steffen i'll try it as well once these regression tests have finished
18:38 Infinoid no problem, thanks.  if "prove t/perl/Parrot_Test.t" works, that's good enough for me.
18:38 steffen Infinoid: you mentioned most of the perl6 modules you know are in the pugs and parrot repos, is it part of the main subversion tree or is it in another place?
18:38 Coke Infinoid: running now.
18:40 mberends steffen: the parrot and pugs repos contain everything afaik
18:42 steffen ok
18:43 Infinoid on that front, things are still pretty disorganized.  probably because there isn't all that much to organize
18:43 Infinoid is November the biggest perl6 project at the moment?
18:44 mberends yes, it's the most cited rakudo application
18:44 steffen whats november?
18:44 purl november is at http://www.november-wiki.org/ or http://use.perl.org/~masak/journal/37212 or http://github.com/viklund/november/
18:45 steffen ah ok just saw the page
18:45 steffen that sounds useful
18:45 steffen especially since i wanna do a webapp
18:46 mberends in a few days I'll have enough done on a rakudo http daemon to share it
18:47 Infinoid ooh!
18:47 Infinoid there's also mod_parrot, if you want to go the apache route
18:47 steffen nice
18:48 jhorwitz and mod_perl6...
18:48 purl i heard mod_perl6 was happy with it too
18:48 jhorwitz purl: forget mod_perl6
18:48 purl jhorwitz: I forgot mod_perl6
18:49 steffen hehe
18:50 Infinoid purl, mod_perl6 is built on mod_parrot
18:50 purl OK, Infinoid.
18:51 dalek r35002 | Whiteknight++ | branches/jit_h_files/src/jit/i386 (2 files):
18:51 dalek : [jit_h_files] a few more functions moved over.
18:51 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35002
18:52 * Wknight8111 grumbles angrily about the JIT system on i386
18:52 Infinoid well, at least i386 *has* one.
18:53 * Wknight8111 grumbles about the lack of JIT on other systems
18:53 Infinoid heh :)
18:53 Wknight8111 getting JIT working for amd64 is on my 2009 to-do list
18:54 Wknight8111 so many things on the list, so few days in a year
18:54 Infinoid that actually sounds like a lot of fun.  too bad I don't know the first thing about JIT
18:54 kj I thought targeting some other JIT engine was part of the plan
18:54 * kj forgot the name
18:55 kj LLVM
18:55 Wknight8111 i dont know anything about LLVM
18:55 * Wknight8111 should probably look into that
18:59 Infinoid hmm.  I'm also interested in JIT on ARM, which LLVM doesn't support (but then, it's not a parrot core target either)
18:59 Coke Infinoid: +1
18:59 purl 1
18:59 Coke (on the tests)
18:59 Infinoid thanks!  Coke++
19:00 * Infinoid closes the ticket.
19:02 steffen btw here is what spectest_regression had to say: All tests successful (4 subtests UNEXPECTEDLY SUCCEEDED)
19:02 steffen :)
19:02 Infinoid sounds like things are working well
19:02 steffen yeah
19:03 Wknight8111 LLVM looks interesting, now that I'm reading the documentatio
19:07 Wknight8111_ joined #parrot
19:20 Wknight8111 (my internet connection)--
19:20 dalek r35003 | Whiteknight++ | branches/jit_h_files/src/jit/i386 (2 files):
19:20 dalek : [jit_h_files] another long string of functions moved
19:20 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35003
19:21 Wknight8111 only about 26 more functions to move, I think
19:21 Wknight8111 may as well be 1000, at the rate this is going.
19:22 steffen hehe
19:31 dalek r35004 | Whiteknight++ | branches/jit_h_files/src/jit/i386 (2 files):
19:31 dalek : [jit_h_files] another string of functions moved
19:31 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35004
19:41 Limbic_Region joined #parrot
19:42 Wknight8111 joined #parrot
19:48 ask_ joined #parrot
19:51 On2 joined #parrot
19:52 gmansi joined #parrot
19:52 estrabd joined #parrot
19:53 On2 joined #parrot
19:54 Khisanth joined #parrot
19:57 Infinoid at some point, the Parrot Bug Summary should be made trac-aware
20:09 Coke the PBS is tied to RT.
20:09 Coke so, we might get a new, trac based email, but that one isn't changing.
20:09 Coke whee, bus error
20:09 purl Go take a walk.
20:12 geof joined #parrot
20:13 Coke are freeze/thaw expected to work?
20:14 chromatic Yes.
20:15 chromatic Otherwise we can't use PBC.
20:15 Coke I have a .tcl file; I load it in, compile it to an Eval PMC; I freeze the PMC and write it to disk. in a separate process, I read in the .fpmc, and thaw it.
20:15 Coke when I thaw it, bus error.
20:15 chromatic That's a problem.
20:16 Coke hurm. the .fpmc has only 1973 bytes. I find that odd.
20:16 Coke (no pun intended)
20:16 chromatic Yes, that does sound small.
20:17 Coke chromatic: I'm happy to check this in to partcl if you wish to poke.
20:17 Coke or happy to ask you dumb questions and be enlightened. =-)
20:18 Tene Oh... calling conventions to invoke scheme routines are awkward.  It expects a cons for passing multiple arguments.
20:18 nopaste "coke" at 72.228.52.192 pasted "generate the fpmc" (45 lines) at http://nopaste.snit.ch/15200
20:18 chromatic Scheme or Pheme?
20:18 Coke ah, the lowness of the tcl file is explained by the "error what;" code I'm compiling there;
20:19 Coke (had a different error when trying to compile the actual file.)
20:19 chromatic What's the size of frozen before you say it?
20:19 Tene chromatic: pheme
20:20 Tene my $add = eval("(lambda (x) (+ x 2))", :lang<pheme>); say $add.arity();
20:20 Tene 1
20:20 chromatic Oh, right.
20:20 chromatic Hm.
20:21 chromatic but that lambda only takes one argument
20:23 Tene erm
20:23 Tene copied wrong
20:23 Tene my $add = eval("(lambda (x y) (+ x y))", :lang<pheme>); say $add.arity();
20:23 chromatic That one should take two arguments.
20:23 nopaste "coke" at 72.228.52.192 pasted "generate the fpmc (fixed) (still bus errors on thaw)" (37 lines) at http://nopaste.snit.ch/15201
20:23 Tene It doesn't.
20:24 chromatic The generated PIR should have .param pmc x and .param pmc y.
20:24 chromatic If I recall correctly.
20:24 Tene I'll be writing a PCT scheme soon.
20:24 Tene I can't get pheme to output PIR
20:24 chromatic --target=PIR should work
20:25 Tene ... oh, it does.
20:26 Coke chromatic: length of the preparsed tcltst.tcl is now 99029; seems to be the same on disk, after reading but before thawing, etc.
20:26 nopaste "tene" at 97.117.74.5 pasted "--target=pir output for chromatic++" (26 lines) at http://nopaste.snit.ch/15202
20:26 Coke chromatic: doh. I actually "say" the output, not print it.
20:27 chromatic Hm.  I wonder why I did that.
20:27 Coke changing that to a print, it's 99028 all around (including before printing it the first time). I seem to get further, but still it still bus errors.
20:27 chromatic Probably because it fit Scheme's calling conventions better.
20:28 On joined #parrot
20:28 chromatic I wonder why the say truncates it.
20:28 Coke it didn't.
20:29 Coke the shortness was because I was trying to compile a hard coded tcl snippet. sorry about the initial confusion.
20:29 On joined #parrot
20:29 Coke when I thaw it, I now get an Eval object. if I invoke it, bus error. If I do fpmc=fpmc[0] to get the first invokable sub, I then get the nicer "attempt to access code outside of current code segment"
20:30 Coke (but it still dies without running the frozen tcl.)
20:30 Coke s/frozen/thawed/
20:31 * Coke rebuilds parrot without optimize.
20:33 Coke (sos I can get a bt.)
20:34 dalek r35005 | Whiteknight++ | trunk/docs/book:
20:34 dalek : [Book] A few small changes and fixes to chapter 4
20:34 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35005
20:37 Coke ah. turning off optimize yields the more informative:
20:37 Coke src/inter_call.c:440: failed assertion '(sig_pmc)->vtable->base_type == enum_class_FixedIntegerArray'
20:37 Coke Abort trap
20:38 chromatic You're trying to invoke something which isn't a Sub, apparently.
20:39 Coke What if it were a PIR subclass of a .Sub ?
20:40 chromatic Then hopefully it gets thawed correctly.
20:41 Coke (currently, it's trying to invoke an Eval)
20:41 chromatic We might not freeze the associated PMCProxy for a PIR subclass.
20:42 Coke if I add the fpmc=fpmc[0] trick to get at the first invokable in the Eval, it claims to be a Sub before I invoke it.
20:42 Coke (which it may be. checking on the freeze side.)
20:42 chromatic A Sub or a TclSub?
20:43 Coke Sub.
20:43 Coke (there are probably tclprocs internally, but the top level items pre-freeze and post-thaw is a Eval, whose [0] is Sub
20:43 particle Infinoid: ping
20:44 Infinoid particle: hey
20:44 Coke I don't know that I can tell where it goes south after I invoke the fpmc on thaw.
20:44 particle happy new year! those asserts are killing me.
20:44 chromatic Can you thaw it in process and invoke it there?
20:44 Infinoid particle: how and where?
20:45 Infinoid the only feedback I've gotten about MSVC so far is from kj, but I'm foggy on the details
20:45 nopaste "particle" at 76.121.106.245 pasted "partial build output for infinoid" (3789 lines) at http://nopaste.snit.ch/15203
20:46 Coke chromatic: aha. no.
20:46 Coke if I freeze it, thaw it, invoke the thaw, same assertion failure.
20:46 chromatic Alright, that's a start.
20:46 chromatic Now we need to reproduce it in PIR.
20:47 Infinoid wow.  I take it there's no __attribute__unused__ on MSVC?
20:47 dalek r35006 | tene++ | trunk (31 files):
20:47 dalek : Partially erge pct_hll branch into trunk.
20:47 dalek : I'm *mostly* sure this doesn't break anything.
20:47 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35006
20:47 Coke chromatic: I'll see if I can strip this down a bit.
20:47 particle Infinoid: we've got warnings set pretty high
20:47 Infinoid particle: what's different between you and kj?  different versions of MSVC maybe?
20:47 particle ...for msvc.
20:48 particle does he not get those warnings? i don't know. i'm running msvc2008.
20:49 particle i'm making tags now to see what's going on
20:49 Infinoid last I heard, it built fine for him
20:50 particle it builds fine. those are *warnings*
20:50 Infinoid I can see how they would get really annoying tho
20:51 estrabd joined #parrot
20:53 particle -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_NORETURN
20:53 particle nothing about UNUSED
20:53 chromatic What's the UNUSED macro look like in MSVC?
20:54 nopaste "coke" at 72.228.52.192 pasted "this just generates an error on key type" (33 lines) at http://nopaste.snit.ch/15204
20:54 Coke (be nice if it told you what type that was.)
20:55 dalek r35007 | Whiteknight++ | trunk/docs/book:
20:55 dalek : [Book] Add some stubbish sections about classes and objects, that I'll expand on later.
20:55 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35007
20:55 Coke I hate to chase this down since it's just a hack to try to eke out a little more speed for now.
20:56 Coke (also seems odd that parrot lets me freeze something it cannot thaw.)
20:57 Infinoid chromatic: judging from parrot/compiler.h, MSVC doesn't have an equivalent to gcc's __attribute__((__unused__))
20:57 Infinoid (or we haven't added support for it.)
20:59 particle may need to #define UNUSED(x) x = x
21:00 particle ah, i see #define UNUSED(a) if (0) (void)(a);
21:03 Infinoid well, we can hack the ASSERT_ARGS() macro to put one of those after the variable declaration.  but will that result in a warning about mixing variable declarations with code?
21:03 Infinoid (it would on GCC.)
21:03 particle of course it would, it needs to be C89
21:04 particle in fact, it's an *error* on msvc
21:08 On2 joined #parrot
21:08 Infinoid hmm.  there's a lot to be said for XS's ability to just wrap the entire function with init and exit code :)
21:10 chromatic That's one of the features of XS I like.
21:11 chromatic Nothing else comes to mind at the moment.
21:12 Infinoid same here
21:13 * Coke wonders how long it will be until we have no .c files checked in.
21:14 Coke (we already mangle PMC and OPS...)
21:14 alvar joined #parrot
21:16 Infinoid preprocessing all of the C sources does not seem very practical to me as a short term solution... as much as I might wish I could.
21:16 Infinoid so far, I can think of the following alternate solutions:
21:17 Infinoid 1.  disable ASSERT_ARGS() on MSVC (or a particular version of MSVC) somehow, maybe #defining it to something to make it ignore the trailing semicolon
21:17 Infinoid 2.  disable ASSERT_ARGS() everywhere by default, enable it only if a particular Configure.pl option is passed
21:18 Infinoid #2 isn't so bad, actually, assuming we can get rid of the trailing semicolon in a portable way.  it's already found all of the current issues, after all
21:18 Infinoid well, ok, *most* of the current issues.
21:19 contingencyplan_ joined #parrot
21:20 particle define it as UNUSED(ASSERT_ARGS_ # x = 0) ?
21:20 contingencyplan_ joined #parrot
21:21 particle er, not quite
21:22 Infinoid the trailing semicolon is a problem for parsing, but we can always remove it from the sources and put it in the macro as necessary, that's an easy fix (if a big patch).
21:22 Infinoid and then for MSVC we can just define it to ""
21:23 Infinoid I was hoping to avoid that, because it's a little weird when you're browsing sources.
21:23 particle why is the trailing semi a problem? are two semis in a row a C error
21:24 particle #define UNUSED(a) if (0) (void)(a);
21:24 Infinoid in gcc, if you have a lone ";" before a variable declaration, it triggers the mixed declarations and code warning
21:24 Coke (take that, msvc)
21:25 particle hrmm
21:25 chromatic You ask yourself "How can Microsoft possibly break the C language?  I'm here to tell you, MSVC."
21:26 Infinoid particle: trailing semi in the macro is fine.  I'm talking about the trailing semi in "ASSERT_ARGS(some_function);" littered throughout the C source files
21:26 Infinoid after ASSERT_ARGS() is replaced by whatever, the semi is still there
21:26 particle yes, i know
21:27 particle so you get if (0) (void)(...);;
21:27 particle if UNUSED is expanded
21:27 Infinoid well, we can set up a special UNUSED() macro without the extra semi, if it helps
21:27 Infinoid ...but won't you still have a warning because that if(0) is too high in the function?
21:27 Infinoid or error, as the case may be.
21:28 Coke do other projects written in C jump through these hoops, OOC?
21:29 particle not many
21:29 Tene perl6: eval(q<VISIBLE "O HAI GUYZ">, :lang<lolcode>)
21:29 polyglotbot OUTPUT[O HAI GUYZ␤]
21:29 Infinoid we have a ton more codingstd seatbelts than most C projects
21:29 particle tene++
21:29 Coke nifty.
21:29 particle now do tcl! :)
21:30 Coke Tene: does this magic require the target language use PCT?
21:30 Tene perl6: eval(q<(lambda (msg) (write "scheme got " msg))>, :lang<pheme>)("omg")
21:30 polyglotbot OUTPUT[scheme got omg]
21:30 Tene Coke: no, it just runs load_bytecode and then compreg's whatever the :lang is
21:31 Tene particle: if someone wants to update the rebuild-parrot script running on feather3 to compile TCL too, that would be great.
21:31 confound joined #parrot
21:32 Tene Coke: it potentially requires the language to live in its own .HLL, depending on whether anything happens to conflict without it.
21:32 Coke tcl does that.
21:32 Tene Then as long as tcl.pbc is in languages/tcl/tcl.pbc, :lang<tcl> should work fine.
21:33 Coke now I can finally update partcl's [inline] to work with other languages aside from PIR and PASM.
21:33 Coke (last time I tried it, I ran into the HLL issues, where languages would step on each other.)
21:33 Tene Rakudo doesn't live in its own .HLL yet, as pmichaud wanted to wait for the rvar merge first.
21:34 particle but you can do apl
21:34 Tene cardinal, pheme, lolcode, pynie, and APL all work, though.
21:34 particle tene: have you updated abc yet?
21:34 Tene particle: no
21:34 particle ok, that's a good one to do, because it will likely always ship with parrot
21:37 estrabd joined #parrot
21:40 Tene http://www.reddit.com/r/programming/comments/7nl8​p/multiple_languages_in_the_same_interpreter_in/
21:40 shorten Tene's url is at http://xrl.us/bebmgu
21:43 * pmichaud adds a twitter note.
21:44 Infinoid nice.  now we get to start worrying about variables declared in one language having different subclassed methods than what we're used to in other languages?
21:44 pmichaud isn't that something that we wanted to eventually be worrying about?  ;-)
21:45 Infinoid absolutely, it's great progress
21:45 Infinoid (I know we've talked about that before.)
21:45 Coke tene++
21:46 Coke tene: in partcl, I just created a new builtin command, [inline {lang} {source}] ; there
21:46 * estrabd bumped it up
21:47 pmichaud I don't suppose feather's p6eval builds any of the other langs.
21:47 chromatic I'd add that to Pheme, but quoting is going to be a pain there.
21:47 Coke http://code.google.com/p/partcl/source/​browse/trunk/runtime/builtin/inline.pir
21:47 shorten Coke's url is at http://xrl.us/bebmhi
21:51 * Coke will see about fixing that up this evening.
21:51 GeJ Good morning everyone
21:52 * jonathan is back
21:53 Tene chromatic: was the plan for me to write a PCT scheme implementation to replace pheme or in addition to pheme?
21:54 nopaste "infinoid" at 96.238.213.50 pasted "particle: does this clear up the warnings, or just replace them with new ones?" (23 lines) at http://nopaste.snit.ch/15205
21:54 Infinoid particle: ^^
22:08 particle Infinoid: *boom*
22:08 particle doesn't like the bare semicolon
22:09 particle src\string.c(140) : error C2143: syntax error : missing ';' before 'type'
22:09 particle src\string.c(143) : error C2065: 'd' : undeclared identifier
22:09 particle etc
22:09 Infinoid I was afraid of that.
22:09 Infinoid any ideas for something else we can stuff in there to make things work?
22:10 jonathan What are you trying to twist MSVC to do? :-)
22:11 Infinoid right now, we're just trying to silence a ton of warnings: http://nopaste.snit.ch/15203
22:11 jonathan I did see _lots_ of ASSERT warnings...
22:11 jonathan Ah, yes.
22:11 Tene jonathan: did you figure out that Parrot_oo_get_class_str issue I was harassing you about?
22:12 jonathan Tene: It kinda slipped my mind - sorry. :-( Have only really got properly back into stuff today.
22:12 Tene jonathan: s'okay
22:12 jonathan Infinoid: Does this just appear when we have an argument that isn't used?
22:13 TiMBuS joined #parrot
22:13 particle jonathan: no, it happens at least once for every function
22:13 Infinoid jonathan: no.  it's to do with how we're actually emitting the assertions
22:13 Infinoid hopefully at most once for every function, too
22:13 jonathan Hmm.
22:13 jonathan So is ASSERT_ARGS_CHECK a macro?
22:14 Infinoid it's a ton of macros, generated by headerizer.
22:14 Infinoid ASSERT_ARGS() concatenates the name of the function to make the macro name
22:14 jonathan Ah yes, so I'm seeing.
22:14 chromatic Tene, I'd like to port Pheme to PCT.
22:15 jonathan And where is PARROT_ASSERT_ARG defined?
22:15 pmichaud chromatic: as in you'd like to see it done, or you'd like to do it yourself?
22:15 Tene chromatic: okay, that's going to be one of my next big items, then.
22:15 Infinoid jonathan: include/parrot/exceptions.h
22:16 Infinoid in order to do the maximum amount of good, I tried to make it possible to put them at the very top of the function (many functions in parrot do a lot of work on the lines of local variable declarations, including passing the function arguments in calls to other functions)
22:16 Infinoid c89 isn't always easy...
22:17 jonathan Infinoid: In exceptions.h I see lines like
22:17 jonathan #define ASSERT_ARGS_exit_fatal __attribute__unused__ int _ASSERT_ARGS_CHECK = \ PARROT_ASSERT_ARG(format)
22:17 chromatic I probably won't have time to do all of it myself.
22:17 Infinoid yep, that's what I'm talking about
22:17 chromatic If Tene has time, he's welcome.
22:17 jonathan But I don't see PARROT_ASSERT_ARG defined until the bottom of exceptions.h?
22:18 Tene pmichaud: was I supposed to be working on any of the other milestones for this release?
22:18 Infinoid jonathan: the ASSERT_ARGS() is parsed later, so it all works.
22:18 Infinoid unfortunately, MSVC doesn't have an __attribute__unused__, hence the warnings
22:18 pmichaud Tene: not that I'm aware of.  I think we can mark this one as "landed" also.
22:18 Infinoid hack upon hack upon hack
22:18 * jonathan looks up the flag to get post-preprocessed output
22:19 donaldh joined #parrot
22:19 Tene pmichaud: and "multiple languages in the same interpreter" for the Feb. release also landed?
22:19 Infinoid jonathan: on gcc, it looks like:     __attribute__((__unused__)) int _ASSERT_ARGS_CHECK = ((interp) ? (0) : (Parrot_confess("interp", "src/string.c", 3238), 0)) || ((tc) ? (0) : (Parrot_confess("tc", "src/string.c", 3238), 0));
22:20 Infinoid PARROT_ASSERT_ARG is just PARROT_ASSERT, but it returns 0 so I can use it in an initialization chain
22:21 Infinoid I'm not married to this ugly hack, it's just the only way I could see to get the args checked at the top of the function.
22:22 jonathan Hmm, I get
22:22 jonathan int _ASSERT_ARGS_CHECK = (0) || (0);
22:22 jonathan Ah, and thus the warning.
22:22 Infinoid maybe NDEBUG is defined, that short-circuits the asserts
22:22 Infinoid but the warning will occur either way, I think
22:23 jonathan OK, but it's clear to me now why it warns about unused.
22:23 jonathan Yes.
22:23 particle yep
22:23 Infinoid any suggestions are welcome.  (including ripping it out entirely :))
22:25 particle no varargs macros, either :(
22:26 Infinoid yeah, and no inline functions.
22:26 jonathan Nothing comes to mind right away. :-(
22:27 particle #define FUNCTION(name, args) name(args); \
22:27 particle ASSERT_ARGS(x);
22:27 particle then FUNCTION(Parrot_default_charset, (SHIM_INTERP))
22:27 particle er, of course, you need { in there :(
22:27 particle foo, there's no good way
22:28 jonathan particle: Yeah, I followed the same line of thought, then realized you'd need something at the end too...
22:28 Infinoid this stuff is working reasonably well with gcc, and it caught a bunch of problems which I've fixed.  I think I'd rather disable it on MSVC somehow rather than revert it entirely
22:28 particle aha! have a perl script preprocess out every line with ASSERT_ARGS(...)
22:28 Infinoid haha
22:29 Infinoid if we were going to go down that route, I'd rather have the perl script *insert* it for capable platforms
22:29 tewk Don't change line numbers based on platform, thats evil.
22:30 Infinoid I can insert a blank line in its place.
22:30 particle don't need to change line numbers, just add /* */
22:30 particle inserting it causes line numbers to change. deleting it doesn't have to.
22:31 Infinoid oh, I see.  well, I can always append it to the "{" line
22:31 dalek r35008 | pmichaud++ | trunk/languages/perl6/docs:
22:31 dalek : [rakudo]: spectest-progress.csv update: 265 files, 5914 passing, 0 failing
22:31 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35008
22:31 Infinoid but ... all this seems a bit heavy-handed just to make a codingstd seatbelt not barf on a major supported platform.
22:31 jonathan Infinoid: Agree with just disabling it for MSVC.
22:31 jonathan Maybe make it appear with --maintainer?
22:31 chromatic +1 to disable
22:31 Infinoid I'm fine with that.
22:32 jonathan We've enough developers using gcc to spot issues that come up as a result of this.
22:32 chromatic Not enough people build with maintainer, I fear.
22:32 jonathan chromatic: I meant the two in conjunction rather than one or the toher.
22:32 jonathan *other
22:32 Infinoid with my version of bison, I can't build with --maintainer
22:32 jonathan So you do get it on MSVC if you --maintainer
22:33 Infinoid well, we'd still have to make it *work* on MSVC for that :)
22:33 jonathan Infinoid: Erm, actually that's a good point. I can't build on Win32. ;-)
22:33 jonathan Infinoid: It's not that it doesn't work, it's just that it spews warnings.
22:33 chromatic If it works on MSVC with --maintainer, that's fine.  I don't know MSVC.
22:33 jonathan Disable under MSVC and leave it at that would do me.
22:33 Infinoid ok.  so how do I do that without getting an error about the trailing semicolon?
22:34 jonathan Oh.
22:34 Infinoid (if I have no choice but to remove the trailing semicolons from 1800 functions, I will.  but I think I've already made branch merging hard enough)
22:34 jonathan Why can't we write:
22:34 tewk can't you use a pragma around the #define contents to turn off warnings?
22:34 jonathan ASSERT_ARGS(PackFile_Constant_unpack_key)
22:34 jonathan Instead? And have the macro stick it in?
22:35 jonathan Yes, maybe wait for some branch merges to happen. ;-)
22:35 Infinoid jonathan: that's what I was talking about, removing trailing semicolons from 1800 functions.
22:35 Infinoid the resulting sources read a little weird, but that's not the worst thing that can happen
22:36 davidfetter joined #parrot
22:36 jonathan Uppercase suggets macro suggests magic. :-)
22:36 Infinoid yeah
22:37 donaldh Has anyone built on linux-x86-gcc3.4.6, I don't see it mentioned in PLATFORMS
22:37 Infinoid I did, about a year ago.  it worked.
22:38 Infinoid (gentoo's "hardened" toolchain has been 3.4.x for a long time)
22:39 donaldh I'm seeing a weird link problem where global symbols from .o files are becoming local to libparrot.so and then main.o won't link.
22:40 tewk donaldh: what symbol? is it marked PARROT_EXPORT?
22:40 Infinoid do those symbols have ... yeah, what tewk said
22:41 donaldh Yep, e.g. src/embed.c Parrot_new
22:41 donaldh e.g. 00000000 T Parrot_new in src/embed.o
22:42 donaldh but 000dc1b0 t Parrot_new in blib/lib/libparrot.so
22:43 nopaste "donaldh" at 213.123.171.12 pasted "link error on linux-x86-gcc3.4.6" (18 lines) at http://nopaste.snit.ch/15206
22:45 acmoore joined #parrot
22:45 acmoore left #parrot
22:45 Infinoid donaldh: is this your first trying builds on this machine, or is it a new error?
22:46 donaldh First on this machine. I've been working on Cygwin but want to run valgrind.
22:46 donaldh So I'm guessing a toolchain problem.
22:47 donaldh It's a system based on Redhat Enterprise Linux so I'm not sure of the provenance of the toolchain, even though it reports gcc 3.4.6
22:50 Infinoid I have an old 3.3.6 on this machine if you think testing that will help
22:51 donaldh Hmm, thanks, but I'll maybe just rebuild this machine.
22:55 particle how do i expand a literal newline in a c macro?
22:56 particle s/expand/emit/
22:56 Infinoid \n maybe?
22:57 particle that's what i was going to try, ok
22:58 particle sigh, can't have a macro spit out a pragma anyway
22:59 Infinoid if you stick pragmas around the macro, do they stick when the macro is used?
22:59 * Infinoid has a habit of expecting far too much sophistication from the tools he uses.
23:01 particle no :(
23:01 particle #pragma warning( disable: 4189)
23:01 particle doesn't work
23:01 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 your girlfriend? Please be specific!
23:03 Infinoid particle: well, the patch I nopasted above, in addition to moving the semicolons into the ASSERT_ARGS macro works fine for me
23:04 Infinoid is there a strategically optimal moment to check that change in?  I've already touched a ton of files last week, and I'd like to avoid making branch merging any worse if possible
23:05 Infinoid or I could just make the change, and post something to the list essentially saying "victim here!" and offering to help with any possible merging problems.
23:06 Infinoid (I've got some scripts to help me add and modify these things pretty easily.)
23:06 jonathan Infinoid: Your last patch only caused me minor merge issues.
23:06 jonathan svn being retarted caused me bigger ones.
23:07 jonathan erm, retarded
23:07 jonathan ...takes one to know one...
23:07 jonathan I doubt the whipping out the semis would be a big pain to me.
23:07 Infinoid in that case, I'll JFDI
23:08 jonathan pm's branch touches relatively little C.
23:08 jonathan AFAIK.
23:08 donaldh Does anything ever set a PMC's real_self pointer to anything other than the PMC itself?
23:08 jonathan Yes.
23:08 donaldh how / where?
23:09 jonathan When you subclass a PMC with a high level class.
23:09 jonathan See class.pmc for where in the code this happens.
23:09 jonathan Or if not in there, something called from there.
23:10 donaldh I grepped for real_self and only found pmc.c and dod.c
23:10 donaldh Which is where my confusion started.
23:10 chromatic dod.c: where confusion goes to die
23:10 jonathan That's...odd.
23:11 Whiteknight joined #parrot
23:11 jonathan If we're not using that, I have to wonder how on earth calling subclassed vtable methods works...
23:12 donaldh I'm trying to wind backwards from Parrot_ObjectRef_mark crashing when real_self = 0xff
23:12 chromatic That sounds more like a corrupt PMC to me.
23:13 jonathan I guess the real test is, does commenting out the 4 lines that reference real_self and then removing it from the struct and re-compiling make any difference to any tests/languages?
23:13 donaldh I can try that/
23:13 jonathan (That isn't a fix to the problem though, it sounds like corruption.)
23:13 donaldh Yes it does.
23:13 purl if you say so...
23:13 jonathan (So I expect you'll hit another issue further down the line.)
23:14 donaldh That's why I thought I'd try valgrind.
23:16 Infinoid big patch incoming, hopefully this makes MSVC happy
23:17 dalek r35009 | infinoid++ | trunk (98 files):
23:17 dalek : [cage] Attempt to work around MSVC warnings related to ASSERT_ARGS().
23:17 dalek : * remove the trailing semicolon from ASSERT_ARGS() in the functions being checked.
23:17 dalek : * add the semicolon to ASSERT_ARGS() itself.
23:17 dalek : * disable ASSERT_ARGS() so it defines to nothing on MSVC.
23:17 dalek : * update t/codingstd/c_args_assert.t so it no longer expects to see the semicolon.
23:17 dalek review: http://www.parrotvm.org/svn​/parrot/revision?rev=35009
23:19 * particle rebuilds
23:19 Infinoid still built fine on linux, testing now
23:20 particle Infinoid++ # building fine
23:27 donaldh jonathan: everything builds with real_self removed
23:28 Whiteknight we don't use real_self?
23:29 Whiteknight ...actually, that doesn't surprise me, I could never figure out what it was supposed to be doing anyway
23:29 donaldh Whiteknight: apparently not.
23:30 donaldh btw does anyone listen to / moderate legal@parrot.org ?
23:31 * jonathan wonders how PMCs get virtual calls to vtable methods right now when they are subclassed...
23:31 Whiteknight sounds like a little bit of black magic to me
23:32 chromatic find_vtable_method
23:32 chromatic or something
23:33 jonathan chromatic: No, I mean if you are in a VTABLE method and you call another one, or do a method call. Does it dispatch by the subclass or not?
23:33 jonathan real_self was added for that purpose
23:33 jonathan I'm guessing we must be doing it some other way.
23:35 chromatic Don't know right yet.
23:36 hercynium joined #parrot
23:39 donaldh Is the code for that in oo.c - Parrot_oo_find_vtable_override
23:39 chromatic That sounds right.
23:44 donaldh It looks like it walks from the PMC's class vtable so a new method dispatch would start at the PMC's class again.
23:47 chromatic Through >mro?
23:57 Tene pmichaud: any thoughts yet on what you want for the PCT tutorial?

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

Parrot | source cross referenced