Re: [perl #29380] [Test PATCH] Accessing Pointers in Structs as Aggregates
Chromatic [EMAIL PROTECTED] wrote:
Count: 4
0: 263958416
1: 0
2: 263958412
3: 264243256
And differently here. What your struct layout is describing was:
struct container {
int count;
int ar[2];
};
But you get from nci_p_ a pointer to:
struct container {
int count;
int *mayarray;
};
So I've modified the struct description (attaching a struct_ptr that
describes the array), and this works as expected.
leo
Re: IMCC bug?
Global subroutine labels have to begin with an underscore. Oh, yeah. Now I remember :P It shouldn't segfault though, but produce some kind of error. Each time I did this, it produced run-time errors. Never said 'invalid symbol' or anything. It would be nice if it had. __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover
Re: [perl #29440] [BUG] .emit/.eom only with a comment crashes parrot
Hi, On Saturday 08 May 2004 13:42, Leopold Toetsch wrote: .emit # .eom Yes. $ cat imcc/BUGS BUGS: ... - the parser doesn't like empty subs: .sub _foo .end inserting a 'noop' helps. Are .emit/.eom sections subs? This is IMO not obvious. I'll add it to the bugs file. leo
Re: IMCC bug?
Togos [EMAIL PROTECTED] wrote: Each time I did this, it produced run-time errors. Never said 'invalid symbol' or anything. It would be nice if it had. Fixed. This subroutine call syntax now automatically references a global label, so your example is now valid code. leo
Re: TODO: Linker magic step for configure
Saturday, May 8, 2004, 11:39:03 PM, Dan Sugalski wrote: Another todo list task for the interested. A perl linker thing. Right now, through the wonders of the Unix default linking conventions, every function in parrot gets exported whether we want them to be or not, and generally we don't. That needs fixing. I've spent most of today wading through Windows' linking stuff. Here's what I have learned: DS [Linker isdom of the ages, or at least the hour, snipped] DS Works for me. The basic recommendations all seem sound, so unless DS someone's got an issue with them, let's start putting them all in DS place. DS I'm not sure about building multiple parrots at once at the moment, DS so I think we can defer that one for right now. You're right, I remembered that that too after my head stopped spinning. Got too involved in the library stuff I checked. There's another thing I would like to bring up: make. I guess we should stick to a single variant of it (hmm, boost jam http://www.boost.org/tools/build/jam_src/ looks nice, but I guess GNU make is the more suitable - and well known - choice). This would avoid the don't use xxx, because it won't work on nmake/your make here. Also, MS provides the complete compiler for download, but that package comes without nmake (see README.win32), and the Makefiles currently don't work with GNU make on Windows. Someone with more cross-platform experience might want to comment on that, though. Maybe the current scheme is really sufficient, and I'm bringing up a non-issue here. Ron
Re: Unexpected pcre match failures
In line 9 of 'test_pcre.imc' I'm calling a sub, that does nothing at all. But as a side effect the string a isn't matching the regex a any more. I don't see any effect on calling the sub or not. Both cases do match. Trying 'test_pcre.imc' with a parrot from sources as of 2004-05-09 14:30' I get also the expected results. Unfortunately 'Parrot m4' is behaving just like yesterday. I try to make a new test case and to fire up a debugger. CU, Bernhard -- /* [EMAIL PROTECTED] */ NEU : GMX Internet.FreeDSL Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl
[CVS ci] fix assigned enum_class PMC enums
* PMCs have now fix assigned numbers * the numbering is in classes/pmc.num * this breaks existings PBCs leo
Re: [PATCH: P6C] update calling convention
Abhijit A. Mahabal wrote: this is my first patch ever (not just p6i: ever). So do tell me what I have done wrong. Sorry not to respond before the patch was applied. Crazy week. This is a patch for one of the ToDo items in languages/perl6/Todo. I have updated the calling conventions in a bunch of places, but may have missed some. It looks great Abhijit. My one change would be this: We're gradually moving towards using the real symbol table. Those places where you see find_lex will eventually be calls to the dispatch mechanism (look for a lexical subroutine with that name, failing that look for a global subroutine of that name, multiple dispatch, etc.) I'd rather not take a step back to calls based on the PIR name of the subroutine. -find_lex $P2, die -.pcc_begin non_prototyped -.arg $P0 -.pcc_call $P2 -substr_ret_label: -.pcc_end +_die($P0) If syntax like this: find_lex $P2, die $P2($P0) isn't possible yet, it probably should be. BTW, should I keep working on P6C? As A12 has just come out P6C may be heavily under construction, and I don't want to be in the way... Please do. I'm working on a first rough implementation of classes, but it shouldn't interfere with general patches. Send your patches to [EMAIL PROTECTED] so they show up in the perl6 RT queue. Thanks, Allison
Re: [PATCH: P6C] update calling convention
Allison Randal [EMAIL PROTECTED] wrote: If syntax like this: find_lex $P2, die $P2($P0) isn't possible yet, it probably should be. Works since some weeks. Allison leo
Re: writing PMCs (documentation)
I just moved from Berlin to London and started a new job, so haven't had time recently for Parrot documentation. Indeed there is plenty to be done. I should be back on the case in a week or two. Mike On 7 May 2004, at 17:13, Simon Glover wrote: No. The closest we have to something like this is probably the stuff written by Mike Scott for the Wiki: http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ParrotDiagramsPMC
Re: P6C: Parser Weirdness
On Sat, 8 May 2004, Abhijit A. Mahabal wrote: I was writing a few tests for the P6 parser and ran into a weird problem. If I have the following in a file in languages/perl6, it works as expected: [...] Now, if I put exactly the same contents in a file in languages/perl6/t/parser, then I get the following error: Okay, I traced the problem to a use FindBin in P6C::Parser.pm. Is it okay to change use lib $FindBin::Bin/../../lib; to use lib ../../lib; or is there a good reason not to? The current version makes it necessary to put all files that use P6C::Parser in the same directory, and the change would allow: perl t/parser/foo.t to work. --Abhijit
Re: [perl #29257] Build libnci.so by default
Adam Thomason [EMAIL PROTECTED] wrote: It's not the library that's the trouble, it's the contained objects. The build rule shouldn't contain nci_test$(O) but just path/libnci$(SO) : nci_test.c $(LD) $(LD_SHARED) $(LIBNCI_DEF_FILE) ... No need to have a CC_SHARED with -fPIC (not yet). Adam leo
Re: [perl #29441] [PATCH] MSWin32 Docs
Ron Blaschke [EMAIL PROTECTED] wrote: Documentation update, including build instructions for local ICU installation. Thanks, applied. leo
Re: IMCC bug?
Togos [EMAIL PROTECTED] wrote: .sub looper print i like peanuts\n shooper() _shooper() print goodbye\n end .end .sub shooper non_prototyped .sub _shooper print hello\n .end Global subroutine labels have to begin with an underscore. It shouldn't segfault though, but produce some kind of error. When you compile it to PASM first, everything is one compilation unit and the shooper label can be fixed up. This isn't done, if the label shooper is in a different compilation unit. leo
