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]
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: [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
> 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: [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
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
> > [* - 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]
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: 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
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?
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
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: [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?
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: [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: PIR version of Data::Dumper
Tim Bunce <[EMAIL PROTECTED]> wrote: > On Thu, Feb 05, 2004 at 02:35:38PM +0100, Leopold Toetsch wrote: >> 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. That's not specific to Data::Dumper. We are just lacking a sort routine. > Tim. leo