Re: [PATCH] Unified PMC/PObj accessors phase 2
Gordon Henriksen [EMAIL PROTECTED] wrote: The patch is at the URL below, and I've split it into 4 for you. The=20 classes-include-lib patch must be applied before any of the other 3.=20 I've resolved the 3-4 conflicts that occurred since the patch was first=20= I've applied now pmc-accessors2-classes-include-lib. *But* 1) PObj_int_val or such doesn't exist, i.e. Buffer (logically) doesn't have an int_val, so I renamed that back to PMC_int_val (for all PMC types). 2) The *misc.patch doesn't compile in jit/i386 3) *src-a*.patch reverts Mike's docu patch 4) didn't look at the second src patch then Yeah such big patches are a pain. Thanks anyway, leo [* - Somewhat inadvisedly, I think. UnionVal is 8 bytes on a 32-bit=20 architecture, but bloats to 16 bytes on a 64-bit architecture. That's likely so because of alignment. But real numbers would be better of course. leo
Re: Alignment Issues with *ManagedStruct?
Gordon Henriksen [EMAIL PROTECTED] wrote: Maybe you ought to capitulate to the hierarchical nature of it all and simply push on another struct layout specifier to handle the nesting. Exactly that's the plan: .DATATYPE_STRUCT .DATATYPE_STRUCT_PTR are already in CVS. leo
Re: [DOCS] Documentation tools
Suppose I could make a few changes to Pod-Simple, then our problem would be solved. But, being serious, say I'd decided to use Template-Toolkit, it would never have occurred to me to shove all of that in CVS. It always surprised me a that ICU was there, rather than just what was needed to get it to work. So, it seems just to be a question of adding a prerequisites phase to the config. I would propose that we leave Pod-Simple in CVS until I have time to implement that, then we can delete it (promise). Mike On 6 Feb 2004, at 01:39, Robert Spier wrote: 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?
On 02/05/04 Uri Guttman wrote:
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):
[...]
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
[...]
BTW, this was on a sparc/solaris box.
The offsets look incorrect. On basically every modern 32 or 64 bit
OS (with sizeof(int) == 4) it should look like:
struct yt (size=8, alignment=4)
char i : offset 0
char k : offset 1
int j : offset 4
struct xt (size=16, alignment=4)
char x : offset 0
struct yt Y : offset 4
char z : offset 12
lupus
--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better
Re: Alignment Issues with *ManagedStruct?
Paolo Molaro [EMAIL PROTECTED] wrote: The offsets look incorrect. On basically every modern 32 or 64 bit OS (with sizeof(int) == 4) it should look like: Yeah. But in the meantime Parrot should calculate correct offsets :) lupus leo
anim_parrot_logo.imc: .include question + general imcc questions
Hello, While looking at Chromatic's anim_parrot_logo.imc (in examples/sdl), I was wondering why the includes weren't at the same place. Indeed, the source reads: .sub _main _init() _MAIN() end .end .include library/sdl_types.imc .pcc_sub _init prototyped .include library/sdl.pasm .pcc_begin_return .pcc_end_return .end Why does: .sub _main _init() _MAIN() end .end .include library/sdl_types.imc .include library/sdl.pasm fails with: error:imcc:parse error, unexpected PARROT_OP, expecting $end in file 'library/sdl.pasm' line 1 included from '../tmp/foo.imc' sub '_new_SDL_Image' line 10 And two more imcc questions: - why using .pcc_sub instead of .sub? What is the difference? Which is best/should be used? - isn't there a kind of return imcc op instead of .pcc_begin_return / .pcc_end_return. I found the .return imcc op in imcc/README but it fails with error:imcc:parse error, unexpected '\n'. Is it to be used only when returning something (ie, returning nothing isn't allowed?) Thank you for the answers, Jérôme -- [EMAIL PROTECTED]
Re: Alignment Issues with *ManagedStruct?
Uri Guttman [EMAIL PROTECTED] wrote:
boy, was this easy with this module. all we need to do is mess around
with the output to get whatever leo needs.
s/leo/Joe R. Parrot Hacker/ - I can craft initializers by hand ;)
1) some script e.g. gen_struct (struct2pasm ...) located in tools/dev or
build_tools.
2) options:
--gen-pasm, -p(default, *if* src file =~ /\.pasm$/
--pmc=Px (for --gen-pasm only, default P15)
--gen-pir (default)
--named-initializer=0,1 (1)
--named-accessor=0,1 (0)
--out-file, -o=file (default: change input in place unless stdin)
3) Operation
3a) Take a C structure, spit out initializer
3b) take a commented C structure, add or change initializer
3b) is for source-files that may contain multiple C structures
like in my original posting WRT this util or like below
with this struct (from leo with some minor changes):
## gen_struct(--options, --pmc=P20, --gen-pasm)
# struct xt {
# char x;
# struct yt {
# char i,k;
# int j;
# } Y;
# char z;
#} X;
## end_gen
## begin autogeneratedd bla bla
4) The output
4a) initializer name / P-register = $init_pmc
new P20, .OrderedHash # .PerlArray if --no-named-initializer
or
.local pmc struct_xt_init # --gen-pir
struct_xt_init = new OrderedHash
and
.include datatypes.pasm# for DATATYPE_ consts below
4b) data type of item
push $init_pmc, .DATATYPE_$type # --no-named-init...
or
set $init_pmc[$var], .DATATYPE_$type # --name-init..
If item is a nested struct or a pointer to nested struct please
consult docs/pmc/struct.pod
4c) item count = 0, or N for array of items
push $init_pmc, $item_count
4d) offset - always 0 for now
push $init_pmc, 0
4e) nice to have: preserve C comments (put these after '#')
S. also t/pmc/nci.t for examples of initializers and src/nci_test.c for
the referenced C structs.
I hope above outline is somewhat clear else please just ask.
uri
leo
Re: anim_parrot_logo.imc: .include question + general imcc questions
Jerome Quelin [EMAIL PROTECTED] wrote: Hello, While looking at Chromatic's anim_parrot_logo.imc (in examples/sdl), I was wondering why the includes weren't at the same place. Indeed, the source reads: One include is inlined init code, while the other has subroutines. And two more imcc questions: - why using .pcc_sub instead of .sub? What is the difference? Which is best/should be used? They are equivalent in PIR code, plain .sub is the prefered syntax. PASM code still needs .pcc_sub _label: to denote a global sub entry. Might be .entry _label: somewhen. - isn't there a kind of return imcc op instead of .pcc_begin_return / .pcc_end_return. .macro .ret_void .pcc_begin_return .pcc_end_return .endm should do it. ... I found the .return imcc op in imcc/README but it fails with error:imcc:parse error, unexpected '\n'. Is it to be used only when returning something (ie, returning nothing isn't allowed?) .return item is used inside above return pairs to return something from the sub. Jérôme leo
RE: [PATCH] Unified PMC/PObj accessors phase 2
[* - Somewhat inadvisedly, I think. UnionVal is 8 bytes on a 32-bit architecture, but bloats to 16 bytes on a 64-bit architecture. That's likely so because of alignment. But real numbers would be better of course. Err? No, I'd think it's because the union contains two 16-byte structs (64-bit ptr + 64-bit ptr = 128-bit struct = 16 bytes). Shouldn't be any padding in UnionVal unless there's a 32-bit architecture out there that wants to align 32-bit values to 64- bit boundaries... -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
Two things to think about
Just some opinion pieces: http://www.ondotnet.com/pub/wlg/3941 and my reply http://blog.simon-cozens.org/bryar.cgi/id_6649 -- You can't have everything... where would you put it? -- Steven Wright
Re: [PATCH] Unified PMC/PObj accessors phase 2
Gordon Henriksen [EMAIL PROTECTED] wrote:
That's likely so because of alignment. But real numbers would
be better of course.
Err? No, I'd think it's because the union contains two 16-byte
structs (64-bit ptr + 64-bit ptr = 128-bit struct = 16 bytes).
The minimum size is {bufstart*, buflen). The 2 pointers just fill that
memory.
leo
Re: [DOCS] Documentation tools
Suppose I could make a few changes to Pod-Simple, then our problem would be solved. Pod::Simple is relatively easy to subclass. And Sean is pretty receptive to changes. never have occurred to me to shove all of that in CVS. It always surprised me a that ICU was there, rather than just what was needed to get it to work. I don't think ICU should be in there at all... but that's just my vote :) So, it seems just to be a question of adding a prerequisites phase to the config. I would propose that we leave Pod-Simple in CVS until I have time to implement that, then we can delete it (promise). I wasn't going to make any rash actions like deleting it on the CVS server side ;) It's there, there's no rush to get it out, but I think in general, we want to keep the parrot source from becoming immensely huge. -R
Re: [DOCS] Documentation tools
Robert Spier [EMAIL PROTECTED] wrote: Pod::Simple is relatively easy to subclass. And Sean is pretty receptive to changes. [ more referenced source inside ] - icu - lib/Test/* - lib/Pod/* are all standard thingys. I'm not thinking that we are gonna reinventing wheels nor that we are gonna copying existing wheels, so I'd vote for just removing all that from CVS. All non-trivial packages have some preliminaries. Some prominent notes in README and INSTALL can provide the necessary steps, how to get that source. If we are going towards real user releases, we can provide complete packages including all, for now its just simpler to not ship (and maintain[1]) everything. *If* we need additions or changes to such prelim source code, please work out a simple scheme that works: $ man patch ... comes to my mind. I'd really like that have clarified towards next release at best. leo [1] IIRC there was already one icu update outside that finally got it into CVS - but the whole code is still unused.
Re: [DOCS] Documentation tools
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote: - icu - lib/Test/* - lib/Pod/* are all standard thingys. I'm not thinking that we are gonna reinventing wheels nor that we are gonna copying existing wheels, so I'd vote for just removing all that from CVS. yep All non-trivial packages have some preliminaries. Some prominent notes in README and INSTALL can provide the necessary steps, how to get that source. I'd like to see Configure.pl say what's needed, and do what it can to help if requested. Meanwhile, I've been adding some perl code of my own which should give a more parroty feel to the docs. http://homepage.mac.com/michael_scott/Parrot/docs/html/index.html There are some links to actual files in the distribution (READMEs etc) which will be broken because it's not up there, but they work ok locally. As you can see the structure is lifted from the wiki, this is because it saved me thinking while I got it working. The Item, Group and Section modules in Parrot::Docs will make it fairly easy to set up alternative subsystem-based views of the content instead. Eagle eyes will note that I put the parrotcode.org css and small parrot png in docs/resources so that they work without a network. Hope I haven't transgressed again. Oh, btw, while googling for parrot and leap I found this (indirectly): http://news.bbc.co.uk/2/hi/science/nature/3430481.stm Mike
Re: [PATCH] Unified PMC/PObj accessors phase 2
Leopold Toetsch wrote: Gordon Henriksen wrote: 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 I've applied now pmc-accessors2-classes-include-lib. *But* 2) The *misc.patch doesn't compile in jit/i386 3) *src-a*.patch reverts Mike's docu patch Ack! Bad cvs update! No cookie! Not sure why those didn't merge. http://www.ma.iclub.com/pub/parrot/ now lists a .tgz with separate patches for each file. You can apply the patches in any order, or not at all; there are no interdependencies. Except!: include_parrot_pobj.h will remove the compatibility interfaces, so you may wish to sit on that for a month or so. -- Gordon Henriksen [EMAIL PROTECTED]
