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

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!