Re: Alignment Issues with *ManagedStruct?
Uri Guttman [EMAIL PROTECTED] wrote:
printf( %d event.type\n, (char *)kbevent.type ) - (char *)kbevent ;
offsetof(struct, item)
is used inside parrot/jit/*
want me to hack up this little script and c generation stuff? the hard
part is parsing the struct so i would have to assume some simple format
and not full c for the moment. the only thing needed by the parser is
all the member names.
Very much appreciated.
I thought of that too. A Perl script that takes a C struct and emits an
*ManagedStruct initializer. WRT align: as such struct initializers are
in library code and used by different machines, I'd rather have the
alignment calculation inside the unmanagedstruct.pmc.
But as a last resort this script could regenerate the offsets for a
particular machine.
## gen_struct()
# struct event_t {
# char x; /* optional comment */
# char y;
# int flags;
# };
## end_gen
## autogenerated from above template
## don't modifiy - rerun gen_struct $file
.local pmc event_t_struct_init
.include datatypes.pasm
event_t_struct_init = new .OrderedHash
event_t_struct_init[x] = .DATATYPE_CHAR # optional comment
event_t_struct_init[1] = 0# no array of items
event_t_struct_init[2] = 0# automatic offset
event_t_struct_init[y] = .DATATYPE_CHAR
event_t_struct_init[4] = 0# no array of items
event_t_struct_init[5] = 0# automatic offset
event_t_struct_init[flags] = .DATATYPE_INT
event_t_struct_init[7] = 0# no array of items
event_t_struct_init[8] = 0# automatic offset _or_ 4/8
## end autogen
gen_struct --force-align file.imc
could fill in the correct offset in the last line.
Running gen_struct the first time should produce the autogenerated part.
For PASM only, it could look like:
## gen_struct(P23)
...
new P23, .OrderedHash
set P23[x], ...
You might have a look at Fruntime/parrot/include/datatypes.pasm which
is autogenerated too. *Struct.pmc doesn't yet handle all types, but this
will be fixed.
uri
leo
Re: Alignment Issues with *ManagedStruct?
Am Donnerstag, 5. Februar 2004 09:45 schrieb Leopold Toetsch:
Uri Guttman [EMAIL PROTECTED] wrote:
printf( %d event.type\n, (char *)kbevent.type ) - (char *)kbevent ;
offsetof(struct, item)
is used inside parrot/jit/*
want me to hack up this little script and c generation stuff? the hard
part is parsing the struct so i would have to assume some simple format
and not full c for the moment. the only thing needed by the parser is
all the member names.
Very much appreciated.
I thought of that too. A Perl script that takes a C struct and emits an
*ManagedStruct initializer. WRT align: as such struct initializers are
in library code and used by different machines, I'd rather have the
alignment calculation inside the unmanagedstruct.pmc.
I'am currently writing a simple C-parser in imc. My plan is to extract all
structs, enums, unions and typedefs in order to create ManagedStructs
automatically.
If one goes even a step further, it should even be possible to create pasm/imc
wrapper for C functions automatically.
The tokeniser is already working, but the token processing is of course not
very simple, but I think I will have a first working alpha version within the
next few days.
But as a last resort this script could regenerate the offsets for a
particular machine.
## gen_struct()
# struct event_t {
# char x; /* optional comment */
# char y;
# int flags;
# };
## end_gen
## autogenerated from above template
## don't modifiy - rerun gen_struct $file
.local pmc event_t_struct_init
.include datatypes.pasm
event_t_struct_init = new .OrderedHash
event_t_struct_init[x] = .DATATYPE_CHAR # optional comment
event_t_struct_init[1] = 0# no array of items
event_t_struct_init[2] = 0# automatic offset
event_t_struct_init[y] = .DATATYPE_CHAR
event_t_struct_init[4] = 0# no array of items
event_t_struct_init[5] = 0# automatic offset
event_t_struct_init[flags] = .DATATYPE_INT
event_t_struct_init[7] = 0# no array of items
event_t_struct_init[8] = 0# automatic offset _or_ 4/8
## end autogen
gen_struct --force-align file.imc
could fill in the correct offset in the last line.
Running gen_struct the first time should produce the autogenerated part.
For PASM only, it could look like:
## gen_struct(P23)
...
new P23, .OrderedHash
set P23[x], ...
You might have a look at Fruntime/parrot/include/datatypes.pasm which
is autogenerated too. *Struct.pmc doesn't yet handle all types, but this
will be fixed.
uri
leo
jens
Re: Alignment Issues with *ManagedStruct?
Chromatic [EMAIL PROTECTED] wrote:
[ align issues ]
Nested structs are ugly. The alignment of the first item seems to depend
on the biggest item in the struct.
struct {
char // 0
struct {
char// 1
}
char // 2
}
struct {
char // 0
struct {
char// 4
int // 8
}
}
So we need some notion of nested structs or a hint for correct
alignment. I've checked in basic alignment handling for normal
cases, but not the second one above.
Below is a test program to experiment with that stuff.
leo
#include stdlib.h
#include stddef.h
#include stdio.h
// offsetof expands to ((size_t) (( struct xt *)0)- x )
struct xt {
char x;
struct yt {
char i;
int j; // use different items here
} _y;
char z;
} _x;
int main(void) {
printf(x : %d\n, offsetof(struct xt, x));
printf(i : %d\n, offsetof(struct xt, _y.i));
printf(j : %d\n, offsetof(struct xt, _y.j));
printf(z : %d\n, offsetof(struct xt, z));
return 0;
}
Re: [DOCS] Documentation tools
Ah, ok, my bad then. I'd just assumed that, apart from any need for modification, the other things were there simply to save having to tell everyone to go off and get them. I don't intend to change Pod-Simple if I can possibly help it, so it's ok by me to delete lib/Pod, if that's the consensus. Mike On 5 Feb 2004, at 06:31, Robert Spier wrote: I've added the Perl modules for the docs tools to lib/Parrot/IO and lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes (1.03) which they use. I probably blinked.. but why are we including CPAN modules that we are not likely to change into the parrot repository? -R
Re: Alignment Issues with *ManagedStruct?
Jens Rieks [EMAIL PROTECTED] wrote: I'am currently writing a simple C-parser in imc. My plan is to extract all structs, enums, unions and typedefs in order to create ManagedStructs automatically. If one goes even a step further, it should even be possible to create pasm/imc wrapper for C functions automatically. The tokeniser is already working, but the token processing is of course not very simple, but I think I will have a first working alpha version within the next few days. Sounds great. Not too simple to write that al in PIR ;) leo
Re: Alignment Issues with *ManagedStruct?
Leopold Toetsch [EMAIL PROTECTED] wrote: gen_struct --force-align file.imc It seems that this part finally has to consult the C compiler, i.e. generate a test program and parse the offsetof() values of struct items. The problem is nested structs, s. classes/unmanagedstruct.pmc for some comments and the test program in another f'up in this thread. $gcc-source/stor-layout.c seems to deal with that, but its a bit unreadable :) leo
PIR version of Data::Dumper
Here is a first version of a Data::Dumper i've written to be able to dump the AST of my C parser. A dumpertest.imc is included, which shows the dumper in action. I'am sorry, but I have no idea how to convert this to a test. BTW, is the order of the hash elements guaranteed to be equal across platforms? jens =head1 TITLE dumper.imc - PIR version of Data::Dumper =head1 SYNOPSIS ... # not needed anymore in the near future _init_dumper() ... # dump the P0 register _dumper( P0, P0 ) ... END .include library/dumper.imc =head1 DESCRIPTION PIR implementation of Perl's Data::Dumper module. =cut .include ../../runtime/parrot/include/datatypes.pasm =head1 FUNCTIONS This library provides the following functions: =over 4 =item _init_dumper() For internal use only. Initializes a hash with helper callbacks. At the moment, this function has to be called before any use of C_dumper(). This will change in the near future. This function returns nothing. =cut .sub _init_dumper saveall .local pmc helper .local pmc sub new helper, .PerlArray global Data::Dumper::helper = helper newsub sub, .Sub, _dump_PerlArray _register_dumper( .PerlArray, sub ) newsub sub, .Sub, _dump_PerlHash _register_dumper( .PerlHash, sub ) newsub sub, .Sub, _dump_PerlVal _register_dumper( .PerlInt, sub ) _register_dumper( .PerlNum, sub ) newsub sub, .Sub, _dump_PerlString _register_dumper( .PerlString, sub ) restoreall .pcc_begin_return .pcc_end_return .end =item _register_dumper( id, sub ) Registers a dumper for new PMC type. =over 4 =item id the PMC id, as returned by the Ctypeof op. =item sub a Sub pmc, that gets called in order to dump the content of the given PMC =back For example: newsub sub, .Sub, _dump_PerlArray _register_dumper( .PerlArray, sub ) This function returns nothing. =cut .sub _register_dumper .param int id .param pmc sub .local pmc helper helper = global Data::Dumper::helper set helper[id], sub .pcc_begin_return .pcc_end_return .end =item _dumper( name, pmc[, indent] ) This is the public interface to the dumper library. =over 4 =item name Required. The name of the PMC. =item pmc Required. The PMC to dump. =item indent Optional. The indent used at the start of each line printed. =back BNote: This function currently returns nothing. It should return the dumped data as a string, like Perl's Data::Dumper. Instead, everything is printed out using Cprint. =cut .sub _dumper .param string name .param pmc dump .param string indent _do_dumper_named( name, dump, indent ) print \n .pcc_begin_return .pcc_end_return .end # # internal helper function # .sub _do_dumper_named .param string name .param pmc dump .param string indent print indent print \ print name print \ = _do_dumper_unnamed( dump, indent ) .pcc_begin_return .pcc_end_return .end # # internal helper function # .sub _do_dumper_unnamed .param pmc dump .param string indent .local pmc helper .local int type .local int exist .local pmc cb helper = global Data::Dumper::helper typeof type, dump exists exist, helper[type] if exist, CALL_HELPER print unkown-type(pmc # print type print ) branch DONE CALL_HELPER: cb = helper[type] saveall set S5, indent set P6, dump invokecc cb restoreall DONE: .pcc_begin_return .pcc_end_return .end # # Dumps a PerlString pmc # .sub _dump_PerlString .param pmc str .param string indent print \ print str print \ .pcc_begin_return .pcc_end_return .end # # Dumps a Perl[Num,Int] pmc # .sub _dump_PerlVal .param pmc val .param string indent print val .pcc_begin_return .pcc_end_return .end # # Dumps a PerlArray pmc # .sub _dump_PerlArray .param pmc array .param string indent .local string subindent .local int size .local int pos .local pmc val .local string posstr .local int tmp subindent = concat subindent, indent print PerlArray (size: print array print ) [ set size, array set pos, 0 unless size, iter_end iter_loop: print \n set val, array[pos] print subindent _do_dumper_unnamed( val, subindent ) # next array member inc pos # skip the ',' after the last element if pos = size goto iter_end print , # elements left? branch iter_loop iter_end: print \n print indent print ] .pcc_begin_return .pcc_end_return .end # # Dumps a PerlHash pmc # .sub _dump_PerlHash .param pmc hash .param string indent
Re: PIR version of Data::Dumper
Jens Rieks [EMAIL PROTECTED] wrote: Here is a first version of a Data::Dumper i've written to be able to dump the AST of my C parser. Wow, fine. A dumpertest.imc is included, which shows the dumper in action. s/included/missing/ :) I'am sorry, but I have no idea how to convert this to a test. Test::More provides Cis_deeply to compare structures. ... BTW, is the order of the hash elements guaranteed to be equal across platforms? Just the opposite, its guaranteed to be not the same even on one platform, albeit a srand() like call is still missing to get really random key order. .include ../../runtime/parrot/include/datatypes.pasm That should just be .include datatypes.pasm ... at least, if run from parrot root (which we currently presume) BTW - we still have the mess with 2 different library directories: - library - runtime/parrot/* We really should clean that up, before more and more code goes in. I'd rather have: - runtime/parrot/lib that is all files that need installation in one place. leo
Another note WRT *ManagedStruct
For hysterical raisins there is still an old compat layer in these PMCs, that provides a char* like access to PMC_data() and a get_integer() that does weird things, in the absence of a struct initializer. If no one hollers, I'll just remove that cruft. It simplifies the general case a lot e.g. getting the size of a *ManagedStruct. leo
Re: Alignment Issues with *ManagedStruct?
On Thu, Feb 05, 2004 at 11:04:40AM +0100, Jens Rieks wrote: I thought of that too. A Perl script that takes a C struct and emits an *ManagedStruct initializer. WRT align: as such struct initializers are in library code and used by different machines, I'd rather have the alignment calculation inside the unmanagedstruct.pmc. I'am currently writing a simple C-parser in imc. My plan is to extract all structs, enums, unions and typedefs in order to create ManagedStructs automatically. If one goes even a step further, it should even be possible to create pasm/imc wrapper for C functions automatically. The tokeniser is already working, but the token processing is of course not very simple, but I think I will have a first working alpha version within the next few days. Have you looked at http://search.cpan.org/~grichter/ExtUtils-XSBuilder/ ? Tim.
Re: Some minor decisions and timetables
At 4:28 PM +0100 2/4/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, here's a quick scoop and status. *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm partial to the bleeding heart release, but not that partial) I had planned towards Feb 29th. A nice dated too this year. Works for me. *) Namespaces are going to use the: find_global Px, [key; key; key], final_name_string format. I may add in a dummy: find_global Px, Pn[key], final_name I'd add some syntax additions and some notes: - Pn above is a NameSpace PMC, derived from Hash The problem there is that there's just no point, really. Might as well not bother with find_global and just use normal hash access. Arguably that's what we ought to do, I suppose, but things are sufficiently different that I'd as soon not. (That and it's an otherwise useless parameter in most cases, which fluffs up the instruction stream) *) Just constant keys for names right now. We'll work on dynamic keys later, if we don't already have 'em in. Dynamic keys are (still) working ;) I thought so, but I wasn't sure. *) I like Tim's namespace idea (prepending the language) and we'll put that in, though probably for the next release. That's not really difficult, if the namespace PMC handles above directory-like traversal keys. Oh, it's going to have to. The namespace stuff's going to have to be annoyingly complex, unfortunately. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PIR version of Data::Dumper
Am Donnerstag, 5. Februar 2004 16:25 schrieb Jens Rieks: Am Donnerstag, 5. Februar 2004 14:35 schrieb Leopold Toetsch: Jens Rieks [EMAIL PROTECTED] wrote: Here is a first version of a Data::Dumper i've written to be able to dump the AST of my C parser. Wow, fine. A dumpertest.imc is included, which shows the dumper in action. s/included/missing/ :) dumpertest.imc got stripped, I have resend it. I'am sorry, but I have no idea how to convert this to a test. Test::More provides Cis_deeply to compare structures. Hmm, I'll have a look at it later. The C parser has a higher priority atm. ... BTW, is the order of the hash elements guaranteed to be equal across platforms? Just the opposite, its guaranteed to be not the same even on one platform, albeit a srand() like call is still missing to get really random key order. .include ../../runtime/parrot/include/datatypes.pasm That should just be .include datatypes.pasm ... at least, if run from parrot root (which we currently presume) Oops, fixed. Now it is runtime/parrot/lib/dumper.imc BTW - we still have the mess with 2 different library directories: - library - runtime/parrot/* We really should clean that up, before more and more code goes in. I'd rather have: - runtime/parrot/lib that is all files that need installation in one place. Sounds okay. The different include paths we have are a bit messy... I'am a bit messy, too :-) Forgot to include the new file. The _init_dumper function is removed, it uses the Cerrorsoff from latest CVS to prevent exception raising if the global does not exists. leo jens =head1 TITLE dumper.imc - PIR version of Data::Dumper =head1 VERSION version 0.02 =head1 SYNOPSIS ... # dump the P0 register _dumper( P0, P0 ) ... END .include runtime/parrot/lib/dumper.imc =head1 DESCRIPTION PIR implementation of Perl's Data::Dumper module. =cut .include datatypes.pasm =head1 FUNCTIONS This library provides the following functions: =over 4 =item _helper() For internal use only. Initializes an array with helper callbacks. This function returns the helper array. =cut .sub _helper saveall .local pmc helper .local pmc sub .local int type errorsoff 1 # .PARROT_ERRORS_GLOBALS_FLAG helper = global Data::Dumper::helper typeof type, helper if type == .PerlArray goto END new helper, .PerlArray global Data::Dumper::helper = helper newsub sub, .Sub, _dump_PerlArray _register_dumper( .PerlArray, sub ) newsub sub, .Sub, _dump_PerlHash _register_dumper( .PerlHash, sub ) newsub sub, .Sub, _dump_PerlVal _register_dumper( .PerlInt, sub ) _register_dumper( .PerlNum, sub ) newsub sub, .Sub, _dump_PerlString _register_dumper( .PerlString, sub ) END: restoreall .pcc_begin_return .return helper .pcc_end_return .end =item _register_dumper( id, sub ) Registers a dumper for new PMC type. =over 4 =item id the PMC id, as returned by the Ctypeof op. =item sub a Sub pmc, that gets called in order to dump the content of the given PMC =back For example: newsub sub, .Sub, _dump_PerlArray _register_dumper( .PerlArray, sub ) This function returns nothing. =cut .sub _register_dumper .param int id .param pmc sub .local pmc helper helper = global Data::Dumper::helper set helper[id], sub .pcc_begin_return .pcc_end_return .end =item _dumper( name, pmc[, indent] ) This is the public interface to the dumper library. =over 4 =item name Required. The name of the PMC. =item pmc Required. The PMC to dump. =item indent Optional. The indent used at the start of each line printed. =back BNote: This function currently returns nothing. It should return the dumped data as a string, like Perl's Data::Dumper. Instead, everything is printed out using Cprint. =cut .sub _dumper .param string name .param pmc dump .param string indent _helper() _do_dumper_named( name, dump, indent ) print \n .pcc_begin_return .pcc_end_return .end # # internal helper function # .sub _do_dumper_named .param string name .param pmc dump .param string indent print indent print \ print name print \ = _do_dumper_unnamed( dump, indent ) .pcc_begin_return .pcc_end_return .end # # internal helper function # .sub _do_dumper_unnamed .param pmc dump .param string indent .local pmc helper .local int type .local int exist .local pmc cb helper = global Data::Dumper::helper typeof type, dump exists exist, helper[type] if exist, CALL_HELPER print unkown-type(pmc # print type print ) branch DONE CALL_HELPER: cb = helper[type] saveall set S5, indent set P6,
[CVS ci] pointers to struct
I've committed a first attempt to handle pointers to contained structs. Please have a look at src/nci_test.c:nci_pi (case 4) and t/pmc/nci_19. The information for the contained structure is currently a property of that initializer element. I hope this syntax is ok. For testing please run: make libnci.so leo
Patch vaporized?
I've submitted a patch to bugs-parrot, and it didn't seem to get posted to RT or otherwise handled. Anyone know where it might've gone? http://www.parrotcode.org/openpatches http://www.parrotcode.org/openpatches isn't working (ERROR RETRIEVING DATA). -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
Re: Patch vaporized?
On Thu, Feb 05, 2004 at 11:25:22AM -0500, Gordon Henriksen wrote: : I've submitted a patch to bugs-parrot, and it didn't seem to get posted : to RT or otherwise handled. Anyone know where it might've gone? Did it have an executable attachment? :-) Larry
Re: [CVS ci] pointers to struct
Leopold Toetsch [EMAIL PROTECTED] wrote: I've committed a first attempt to handle pointers to contained structs. Please have a look at src/nci_test.c:nci_pi (case 4) and t/pmc/nci_19. And another one, handling call_back functions passed in from external. Again: For testing please run: make libnci.so leo
Re: Alignment Issues with *ManagedStruct?
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT Chromatic [EMAIL PROTECTED] wrote: LT [ align issues ] LT Nested structs are ugly. The alignment of the first item seems to depend LT on the biggest item in the struct. that is a known rule for alignment of nested structs. since larger items usually have strict alignment requirements on many platforms (misaligned accesses either fail with bus faults or pay a massive penalty as on the alpha), the compiler has to align the whole struct so that item will be aligned. it can't just pad internally since that could vary. a char followed by a 32 bit item could need 1,2, or 3 bytes of padding depending on where the struct starts. so cc will force that struct to 32 bit alignement and pad 3 bytes after the char to keep the 32 bit item aligned. LT So we need some notion of nested structs or a hint for correct LT alignment. I've checked in basic alignment handling for normal LT cases, but not the second one above. you just need to do the same thing in offsetof but do it for the nested struct elements. it won't necessarily be the same as when that struct is top level so you can't cheat there. it sounds like between the PIR solution and the cpan module that i don't need to do my own hack. or should i still work on it? it would be an external perl5/c solution that would be able to generate some form of table of item offsets. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Some minor decisions and timetables
DS == Dan Sugalski [EMAIL PROTECTED] writes: DS At 4:28 PM +0100 2/4/04, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Okay, here's a quick scoop and status. *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm partial to the bleeding heart release, but not that partial) I had planned towards Feb 29th. A nice dated too this year. DS Works for me. then how about calling it the bleaping insert avian release? :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Alignment Issues with *ManagedStruct?
Uri Guttman [EMAIL PROTECTED] wrote: LT Nested structs are ugly. The alignment of the first item seems to depend LT on the biggest item in the struct. that is a known rule for alignment of nested structs. since larger items usually have strict alignment requirements Ok. Then I'll try to put that in unmanagedstruct.pmc. Seems not be too hard. it sounds like between the PIR solution and the cpan module that i don't need to do my own hack. or should i still work on it? it would be an external perl5/c solution that would be able to generate some form of table of item offsets. I'll do the alignment stuff. An util that actually generates the initializer - as outlined in the previous posting - would be great though. Pointers to nested structs and function pointers as struct items are already in CVS (at least, when returned from the external C lib) - I'll update the docs/pmc/struct.pod tommorrow, including nested structures. uri leo
Re: perl6-internals Re: RT Cleanup
On Wed, 4 Feb 2004, Steve Fink wrote:
Try
cd languages/perl6
./perl6 --force-grammar -e 1 # don't worry if it fails
make test
$ ./perl6 --force-grammar -e 1
error:imcc:fixup_bsrs: couldn't find addr of sub '_main'
Error: '/home/doughera/src/parrot/parrot-andy/parrot -r __eval__.imc ' failed with
exit code 1
Stopped at ./perl6 line 346
main::mydie(256, '/home/doughera/src/parrot/parrot-andy/parrot -r __eval__.imc
') called at ./perl6 line 828
main::pass4('__eval__.imc', '__eval__.warn') called at ./perl6 line 750
main::pass2('__eval__.imc', '__eval__.warn') called at ./perl6 line 444
main::output_tree('P6C::prog=ARRAY(0xa54fd4)', '__eval__', '__eval__.warn')
called at ./perl6 line 509
main::pass1('Parse::RecDescent=HASH(0xb4d68c)', '__eval__', '__eval__.warn',
1) called at ./perl6 line 571
main::run() called at ./perl6 line 222
$ ./perl6 --test
Can't locate object method new via package P6C::IMCC::ExtRegex::CodeGen at
P6C/IMCC/ExtRegex.pm line 68.
t/rx/basic.tes..FAILED tests 1-8
Failed 8/8 tests, 0.00% okay
t/rx/call.tes...FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
t/rx/special.tesFAILED tests 1-2
Failed 2/2 tests, 0.00% okay
Failed Test Status Wstat Total Fail Failed List of failed
---
t/rx/basic.test 88 100.00% 1-8
t/rx/call.test22 100.00% 1-2
t/rx/special.te 22 100.00% 1-2
10 subtests skipped.
Failed 3/18 test scripts, 83.33% okay. 12/100 subtests failed, 88.00% okay.
WHOA! Somehow you got a different number of results than tests ran!
This should never happen! Please contact the author immediately!
WHOA! Somehow you got a different number of results than tests ran!
This should never happen! Please contact the author immediately!
WHOA! Somehow you got a different number of results than tests ran!
This should never happen! Please contact the author immediately!
END failed--cleanup aborted.
WHOA! Somehow you got a different number of results than tests ran!
This should never happen! Please contact the author immediately!
END failed--cleanup aborted.
WHOA! Somehow you got a different number of results than tests ran!
This should never happen! Please contact the author immediately!
END failed--cleanup aborted.
Hey, that took forever, didn't it? Maybe you should try using
./perl6 --test
instead, as documented in [I forget where, and can't look it up right
now].
It's only documented inside the perl6 script itself. It's not documented
anywhere reasonably obvious, such as a README file.
--
Andy Dougherty [EMAIL PROTECTED]
Re: Alignment Issues with *ManagedStruct?
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT I'll do the alignment stuff. An util that actually generates the normally i would never comment on your english which is usually very good but util(ity) is pronounced with a hard 'u' as in 'you'. so that should be 'a' and not an. LT initializer - as outlined in the previous posting - would be great LT though. i am playing with ExtUtil::XSParser now and i have some problems with it. i will be writing the author. does anyone on this list use it now? i can send in what i have done. it seems to be more a work in progress than something useable but i could be wrong. at least one method i need to override (find_includes) was not described properly in the docs and i had to scan the source to make it work. also the P:RD parser doesn't seem to return a parse tree but some ok (1) values. any help would be appreciated. i mainly need the c struct parser to give me a tree and i can do the rest. thanx, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: PIR version of Data::Dumper
On Thu, Feb 05, 2004 at 02:35:38PM +0100, Leopold Toetsch wrote: Jens Rieks [EMAIL PROTECTED] wrote: Here is a first version of a Data::Dumper i've written to be able to dump the AST of my C parser. Wow, fine. A dumpertest.imc is included, which shows the dumper in action. s/included/missing/ :) I'am sorry, but I have no idea how to convert this to a test. Test::More provides Cis_deeply to compare structures. ... BTW, is the order of the hash elements guaranteed to be equal across platforms? Just the opposite, its guaranteed to be not the same even on one platform, albeit a srand() like call is still missing to get really random key order. So it would be really nice to have a Data::Dumper be able to sort the keys, like the Perl one now can. Tim.
RE: Patch vaporized?
Larry Wall wrote: Gordon Henriksen wrote: I've submitted a patch to bugs-parrot, and it didn't seem to get posted to RT or otherwise handled. Anyone know where it might've gone? Did it have an executable attachment? :-) Thanks, Larry, but no. :) It was a very lage patch, however; it converts pmc-cache.int_val etc. to PObj_int_val(pmc) etc. across the entire source tree. (Sorry, Leo, by far the easiest way to find them all was to change the field names and fix them as make found them; rather makes it difficult to create incremental patches.) So maybe sheer size was the problem. I'll post the file to my web server this evening and just include a link to it in YA resubmission, I suppose. How annoying... -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
Re: RT Cleanup
Melvin:
Here's a warnocked imcc issue for you:
http://bugs6.perl.org/rt3/Ticket/Display.html?id=24251
I don't have a suggested patch, sorry.
Regards.
On Sunday, February 1, 2004, at 04:42 PM, Stephane Peiry wrote:
On Sun, 2004-02-01 at 01:42, Will Coleda wrote:
24251 - warnocked
I don't like when this happens.. and even though I cant do much
directly
about it, I would like to point out to this:
http://www.nntp.perl.org/group/perl.perl6.internals/20534
also just tried this.. gcc doesn't give any better error msg
(parser error before if)
int main () {
int if = 1;
if (if) {
if = 0;
}
}
do you have a patch? I think its a nice to have so If you sourself
provide a nice patch guess it would be applied :)
well.. my 2c
Stéphane
--
Will Coke Coledawill at coleda
dot com
Re: [DOCS] Documentation tools
I can possibly help it, so it's ok by me to delete lib/Pod, if that's the consensus. I'm not sure what the consensus is. But we should probably come to one. -R
Re: Alignment Issues with *ManagedStruct?
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT Uri Guttman [EMAIL PROTECTED] wrote: LT == Leopold Toetsch [EMAIL PROTECTED] writes: i am playing with ExtUtil::XSParser now LT ... but I hope that people out there are speaking Perl and can help with LT that issue. mitchell charity pointed me to a much better module Convert::Binary::C. it looks perfect and seems robust and it is very well documented. i just installed (10747 tests!) it and will play with it soon. if it does what it claims, it will be trivial to generate anything we need. all it needs is a couple of calls to parse any c source and one method will return a list of all the structs with a fully broken out parse tree with offsets! i will hack up something basic using it and we can tweak the output to whatever parrot needs. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Patch vaporized?
Gordon Henriksen [EMAIL PROTECTED] wrote: It was a very lage patch, however; it converts pmc-cache.int_val etc. to PObj_int_val(pmc) etc. across the entire source tree. (Sorry, Leo, by far the easiest way to find them all was to change the field names and fix them as make found them; rather makes it difficult to create incremental patches.) So maybe sheer size was the problem. Ok. If you have kind of a script that does the job, please just post that (accompanied with enough info ...) leo
Re: Alignment Issues with *ManagedStruct?
Uri Guttman [EMAIL PROTECTED] wrote: LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT I'll do the alignment stuff. An util that actually generates the normally i would never comment on your english which is usually very good but util(ity) is pronounced with a hard 'u' as in 'you'. so that should be 'a' and not an. Hey - thanks for that. You did hear my talk in Paris :) I had really bad English teachers. Grammatics wasn't one of my favorites either. Anyway, if I'm stampering on someone's language feet, I'd like to apologize in advance. Please just correct me. We don't even speak German here ... LT initializer - as outlined in the previous posting - would be great LT though. i am playing with ExtUtil::XSParser now ... but I hope that people out there are speaking Perl and can help with that issue. uri leo
Re: Patch vaporized?
At Thu, 5 Feb 2004 11:25:22 -0500, Gordon Henriksen wrote: [1 text/plain; us-ascii (7bit)] I've submitted a patch to bugs-parrot, and it didn't seem to get posted to RT or otherwise handled. Anyone know where it might've gone? I'm the one who would know. Please email me off-list with the message-id, subject, from address, and time sent, and I'll track it down. It's possible it's in the moderation queue. The MyDoom crap has been making his life more difficult. http://www.parrotcode.org/openpatches http://www.parrotcode.org/openpatches isn't working (ERROR RETRIEVING DATA). This is on my list to fix. -R
Re: Patch vaporized?
Did it have an executable attachment? :-) If anyone wants some MyDoom, I've got over a gigabyte (from the past 19 or so hours) absorbed by the perl.org servers I'd be glad to share with you. I can arrange for them to be emailed one at a time, or all at once. -R
Re: event.c - of signals and pipes
events.c(67) : error C2061: syntax error : identifier 'sig_int' sig_atomic_t needs config support. Or as you said below, move all signal stuff to platform code - then I guess we have config support for it without anything new/extra/special. events.c(564) : error C2065: 'fd_set' : undeclared identifier win32 has select() AFAIK - might need just another header file. It has a select() function, but looking at the docs no mention is made of pipes - just sockets. PIPES It looks like things like fd_set don't deal with pipes here either, just sockets; see:- Argh, what an OS. Anyway the communication with the io_thread could be done with sockets. Does the Win32-API provide socketpair()? Unless I'm missing something, no. It's only mentioned in the porting UNIX apps to Windows docs - thus it is most probably provided by the Interix UNIX emulation layer (part of Windows Services For UNIX). It's not mentioned anywhere other than that in the MSDN (just the one search result...) Is there any reason not to have our own pipe abstraction (e.g. stuff in platform.c/.h)? Win32 does have pipes, after all - they just need setting up a little differently. Or if there is more concern over platform specific issues, even a complete abstraction for communication with the I/O thread, so we can do it as sockets or pipes behind the scenes (or whatever else) on a platform-by-platform basis. Perhaps that's going to far, I'm not familiar enough with the range of platforms out there to know. SIGNALS Win32 doesn't have usable signals. All code dealing with signals will move to platform files anyway. OTOH we need a Win32 event loop to be able to catch program termination. OK, sounds like a plan. Thanks, Jonathan
Re: Alignment Issues with *ManagedStruct?
boy, was this easy with this module. all we need to do is mess around
with the output to get whatever leo needs.
with this struct (from leo with some minor changes):
struct xt {
char x;
struct yt {
char i,k;
int j;
} Y;
char z;
} X;
and this trivial script (i pass the filename on the command line):
#!/usr/local/bin/perl -w
use strict ;
use Data::Dumper ;
use Convert::Binary::C ;
my $cbc = Convert::Binary::C-new() ;
$cbc-parse_file( @ARGV ) ;
#print Dumper $cbc-compound() ;
my @structs = $cbc-compound() ;
foreach my $struct ( @structs ) {
print $struct-{'type'} $struct-{'identifier'}\n ;
foreach my $declaration ( @{$struct-{'declarations'}} ) {
my $type = $declaration-{'type'} ;
foreach my $declarator ( @{$declaration-{'declarators'}} ) {
my $decl_name = $declarator-{'declarator'} ;
my $offset = $declarator-{'offset'} ;
print \t$type $decl_name : offset $offset\n ;
}
}
}
i get this lovely output:
struct yt
char i : offset 0
char k : offset 1
int j : offset 2
struct xt
char x : offset 0
struct yt Y : offset 1
char z : offset 7
this was part of the structure parse tree (via Dumper):
$VAR2 = {
'context' = 'xyz.h(3)',
'declarations' = [
{
'declarators' = [
{
'declarator' = 'x',
'offset' = 0,
'size' = 1
}
],
'type' = 'char'
},
{
'declarators' = [
{
'declarator' = 'Y',
'offset' = 1,
'size' = 5
}
],
'type' = 'struct yt'
},
{
'declarators' = [
{
'declarator' = 'z',
'offset' = 6,
'size' = 1
}
],
'type' = 'char'
}
],
'pack' = 0,
'align' = 1,
'size' = 7,
'identifier' = 'xt',
'type' = 'struct'
};
BTW, this was on a sparc/solaris box.
so what output formats do we need?
the structures parse tree (from the compound method) has everything you
could want and is very simple to navigate. this is one amazing module
and it should get more publicity for sure.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
[PATCH] Unified PMC/PObj accessors phase 2
Leo, The patch is at the URL below, and I've split it into 4 for you. The classes-include-lib patch must be applied before any of the other 3. I've resolved the 3-4 conflicts that occurred since the patch was first abortively submitted on Monday, so the old patch (named 20040202-pmc-accessors.patch) should be discarded if it resurfaces. http://www.ma.iclub.com/pub/parrot/ I realized that some of the accessor macros should've been named PObj_* instead of PMC_* (since they apply to STRINGs and Buffers, too). So they are as of this patch. I've also macro-ized access to UnionVal in general, since it was sometimes used outside of the context of a pobj. [*] The old syntax continues to work, and so nobody's patches will break excl. those w conflicts. But the pobj-cache.foo_val and PMC_ptr1p/PMC_ptr2v macros ought to be treated as deprecated. Gordon Henriksen [EMAIL PROTECTED] [* - Somewhat inadvisedly, I think. UnionVal is 8 bytes on a 32-bit architecture, but bloats to 16 bytes on a 64-bit architecture. The generic containers which use UnionVal don't appear to use both ptrs simultaneously or make use of the void*/int pair, so could use an 8-byte structure as their bucket type.]
Re: Alignment Issues with *ManagedStruct?
On Thursday, February 5, 2004, at 05:23 , Leopold Toetsch wrote:
Nested structs are ugly. The alignment of the first item seems to depend
on the biggest item in the struct.
[...]
Yeah, the struct is aligned to align the largest element therein. e.g.:
struct { char; struct { char; char; char; } }
is at +0, +1, +2, +3
But: struct { char; struct { char; char; short; } }
is at +0, +2, +3, +4
And: struct { char; struct { char; short; char; } }
is at +0, +2, +4, +6
So we need some notion of nested structs or a hint for correct
alignment. I've checked in basic alignment handling for normal
cases, but not the second one above.
Maybe you ought to capitulate to the hierarchical nature of it all and
simply push on another struct layout specifier to handle the nesting.
struct xt {
char x;
struct yt {
char i;
int j; // use different items here
} _y;
char z;
} _x;
int main(void) {
printf(x : %d\n, offsetof(struct xt, x));
printf(i : %d\n, offsetof(struct xt, _y.i));
printf(j : %d\n, offsetof(struct xt, _y.j));
printf(z : %d\n, offsetof(struct xt, z));
return 0;
}
Mac OS X output is:
x : 0
i : 4
j : 8
z : 12
Gordon Henriksen
[EMAIL PROTECTED]
Re: Patch vaporized?
I think I've tracked this down, mostly. The patch was rejected from the mailing list because it was too big. (Several hundred k.) You can find it in RT as 26056: [PATCH] Unify PMC accessor macros 2 26057: [PATCH] Unified PMC/PObj accessors phase 2 (26057 is one that points to a URL. Gordon, should I merge the two tickets?) Don't be afraid to email perlbug dash admin at perl.org with problems like this. I'll track them down as quick as I can. -R I've submitted a patch to bugs-parrot, and it didn't seem to get posted to RT or otherwise handled. Anyone know where it might've gone?
Re: Patch vaporized?
On Thursday, February 5, 2004, at 11:35 , Robert Spier wrote: I think I've tracked this down, mostly. The patch was rejected from the mailing list because it was too big. (Several hundred k.) That's what I figured. You can find it in RT as 26056: [PATCH] Unify PMC accessor macros 2 26057: [PATCH] Unified PMC/PObj accessors phase 2 (26057 is one that points to a URL. Gordon, should I merge the two tickets?) Either merge them or close 26056 as wontfix or equivalent (sorry, I'm a Bugzilla feak :). The first patch has conflicts with current source, which is why I freaked out when it didn't show up pronto. Gordon Henriksen [EMAIL PROTECTED]
