Just wanted to let people who may have been interested in this know: The Poser Parser module has finally gotten far enough I can say it exists! I'm not releasing it yet. Right now, I have it parsing Poser files. Sort of. It's intelligently reading them into a data structure. That's the first and hardest part. It's got some work to go, of course. Right now it treats the declaration/geom loading block as a seperate Poser object then the definition block (for reference, objects in a Poser doc appear twice: once to declare them and load geometry where applicable, and once to define them and set all their properties, channels, etc. Well, one of the basic problems with parsing Poser's syntax is that it's not terrifically constant. For instance, just to start with you have no statement delimiter -- many programming languages have the equivalent of a 'period' in English -- some character that says 'this si the end of this line'. In Perl and C it's a semicolon. Some languages treat a carriage return as a delimiter. Javascript uses both (and treats an escaped carriage return as just a space). This sort of thing makes things much easier to parse. Poser's syntax doesn't have one. Usually a carriage return ends a statement, but there are things like weld and addChild that break that rule and must be specifically looked out for. Then there's blocks. Most programming and markup languages (of which Poser's file format is the latter) have some way to define a block. In HTML it's with < and >. In Perl and C and Javascript it's with { and }. In Lisp it's with ( and ) and indentation. VB uses certain keywords as block delimiters (If and EndIf, etc). Again, poser doesn't have a constant one. usually a block is defined by { and }, but some things aren't done the same way -- for instance, valueOpDeltaAdd (the ERC keyword) contains block-type properties that apply to the valueOpDeltaAdd declaration but aren't enclosed in blocks. Same goes for sphereMatsRaw. And to make matters worse on the statement delimiter thing, at least with addChild you know there's an additional argument to the keyword on the line under it. With the Map keywords in materials, that's not always true. There's a 0 0 on the next line UNLESS the value is 'NO_MAP' Just to make things a pain in the butt. So this has been an interesting experience, to say the least. If you look at http://www.dodger.org/ttt/poserParser/test3.html you can see a parsed result of one of my CR2s suspended in HTML format as an HTML dump of the data structure thus parsed. The hash keys beginning with an underscore are used for internal tracking and such: _fh is the open filehandle passed back and forth, _lastkey is the name of the last key encountered in case a block begins, _debug should be obvious -- it's a flag to determine the debugging status, and _seq is the order in which the keys of the current object were read in to enable them to be put back out in the same order (perl hashes don't keep track of their order implicitly). Oh yeah, and _rotseq parses the rotation order as it would have been specified in the PHI if one was used (and only appears in channel sub-objects). Right now this isnt' useful to anyone except other Perl hackers like me -- this is because it doesn't really parse the file but it does sort it into a Perl data structure. I'm adding parsing as I go. I think useCustomMaterial is a boolean (true/false) and just has a non-1 value for true because Poser is weird (same as how forceLimits uses a 4). If anyone knows for a fact otherwise, can you please correct me before I go a lot farther? Anyway, by the time this is done, I'll have all sorts of convenience methods including being able to add, drop, and replace material blocks from material library files (I'll call 'em .pm2 files, I think, though Perl won't care what extension they have). You'll be able to extract geomCustom geometry to an external file with a single command. You'll be able to traverse the tree or access subparts with some simple syntax. And so on. And it will actually PARSE the stuff. B^) Due to the spproach I'm taking, I can make this wotrk without necessarily knowing how everything works -- for instance, to this day I have no clue what sl and spl in a keys block mean. That's why it can parse into a data structure without me having to define what everything means. Just thought those f you who may have heard me mention this project might be interested in the status of things. Isn't it nice to know I can at least do something right? B^)

Very interesting work. I'm off programming for years :( Did this parser could be used to "reduce/delete" useless geometries added with the injection system for V3 ? Laurent

When I'm done. Yep. Using an OO interface through Perl you will be able to do all sorts of data manipulation including removing actors, replacing geometries, rearranging channels, removing and adding channels, and I have even figured out how to add and even combine MTs automagickally. B^)

wow that was a mouth full dodger. I did follow along and understand what you said but I still am not sure why you want to do this in pearl. And what, were and how you will use this when your done. Unless yor trying to make poser usable in a unix enviroment .

Perl is a really powerful (and really confusing) programming language. AFAIK it is platform independent as well, so it's not a bad choice. I think I get the gist of what you're doing, and why, so I'm definitely going to watch its progression. I know this is seriously putting the cart before the horse, but it would be great if this could end up compatible with the DAZ|Studio files down the road. (It looks like there will be a bit of a divergence in data files from Poser's .pz3.) Cheers!

Attached Link: http://www.kuroyumes-developmentzone.com/cr2_ufilespec.html

IMHO, Java would be a better approach. Still platform independent and just about everyone already has a JRE installed for running Java through browsers. For most, Perl is only available from the browser and the only people who have an independent environment are running web servers. I agree with Crescent, Perl is powerful but it has some syntax that makes one wince - just look at how it handles and parses strings!! Personally, I would only use it for web scripting. :) BTW, don't you just love the inconsistencies in the Poser file format. Yes, useCustomMaterial is 0 when there is none and non-0 when there is one defined. Sometimes it's 1, other times it's 32 or some other value - seems to be arbitrary. Have you looked at the info at the link? Also, I have a fully working parser that handles PZ3 and CR2 files written in C++ (fully OOP'd). Handles just about everything that could be found and can skip unused sections - either single lines or areas enclosed by {}. BYS

One more thought. Parsing Poser files is relatively easy. It's deciphering what it all means that can lead one to the sanitarium. Much of it is undocumented, some of it has no known use, other stuff is for Poser use only, and alot of it is needless repetition (check out Poser 5 material channels). Value ranges (especially for material properties) vary indiscriminately and do not necessarily match those shown inside of Poser (0-100% in Poser could be 0-1, 0-100, -10000-10000 in the file - who knows; only CL in some instances). Not saying that it's impossible, just extremely, frustratingly mind-numbing at times. ;0) BYS

IMHO, Java would be a better approach. Bite your tongue! I'm not going to make a toaster oven parse Poser! Still platform independent and just about everyone already has a JRE installed for running Java through browsers. Yes, but... YUCK. For most, Perl is only available from the browser and the only people who have an independent environment are running web servers. Perl is available from CPAN (www.cpan.org) for just about everyone. However, my largest reason for doing this is not as an end-user tool but as a developer tool. I agree with Crescent, Perl is powerful but it has some syntax that makes one wince - just look at how it handles and parses strings!! BTW, don't you just love the inconsistencies in the Poser file format. It's the semantical inconsistencies that are a pain in the bum. The fact that a statement delimiter is a carriage return - usually -- but sometimes not. The fact that blocks are seperated with curlies. Except for some blocks. That's the pain. I don't think parsing the actual data is that hard but parsing it into a structure in the first place is a pain.

BTW, What's so weird abut Perl's strings?

Attached Link: http://java.sun.com/api/index.html

Although I haven't done any extensive Perl coding, a friend of mine has and it seemed to involved some unimaginable syntax to pattern search and break strings apart. It was so daunting that it required both of us (I've been programming for 15 years) to decipher it. Maybe he was using a strange variation or API? What's so weird about Java. Okay, it doesn't compile into super-speedy code (but it can be if you dump system independence), but the workflow is amazing and the bytecode is still acceptably fast. I coded an entire 2D-3D application is a couple months - which is unheard of in C, C++, BASIC, Assembler. Python might be as close as it gets - and Python is very similar, at least in ideology, to Java. Java has a full (total, complete, more extensive in some areas than Windows) GUI interface (Swing), file handling, browser API, networking protocol APIs, wireless API, XML API, Mail API, Client-Server APIs, embedded systems APIs, telephony APIs, math APIs, graphics APIs, 3D graphics API, and on and on and on and on (there are so many APIs that cover so many areas that it would take several pages to list them - go to the link to see a limited number of available APIs). I doubt very much that Perl has that level of support. Java isn't just for toaster ovens anymore! ;0) As for Poser syntactical (semantic has to do with meaning in languages, not structure) inconsistencies, you have to build the general parser on the premise that there are hierarchical blocks of data separated by {}s and each line supposedly delimited by a CR or CR-LF. Then you must handle particular deviations from this premise. I have encounter many deviations in my research on the Poser file format. Even the most "official" (hmmm) documentation doesn't cover some of these oddities. If you'd like, I can send you the C++ classes into which my code parses the Poser files to get an idea about how I handled them and the structure. Then, if you can make sense of that :), I could send the methods (functions) which do the parsing. One thing to mention is that I abandoned any notion of recursive parsing due to the non-repetitive nature of hierarchy (you won't find a material node at the root level), being better to handle each 'type' of section as a class with subsections being classes pointed to by it (and so on). BYS

Although I haven't done any extensive Perl coding, a friend of mine has and it seemed to involved some unimaginable syntax to pattern search and break strings apart. It was so daunting that it required both of us (I've been programming for 15 years) to decipher it. Maybe he was using a strange variation or API? OH! regular expressions. Regexes. L Yes, regexes are pretty complex, but they are a sublanguage (used by more than Perl, too -- there are C libs for them, VB can use them, etc). And they are immensely powerful. But they are not the only way to deal with strings. There are still substr(), index(), reverse(), and of course eq and ne (string-mode == and !=), and you can easily split them into arrays and operate on them in a very C-like manner (@array = split //, $string). What's so weird about Java. L It's not the weirdness, it's the Java. Java was designed as a language to program home appliances (for instance, coffeemakers). As to using it online -- that was originally sort of a hack. I stand by the words of many Perl, Python, PHP, Shockwave, and other programmers when I assert that I believ Java was a really good idea. Too bad it didn't work. Java has [Peal has] a full (total, complete, more extensive in some areas than Windows) GUI interface (Swing) [Perl: Perl/TK], file handling[Built into Perl], browser API [LWP: lib-www-perl, if you mean acting as a browser. ePerl and PerlScript can act as client side Perl inside a browser], networking protocol APIs [More than you can shake a packet at], wireless API [Yup, several], XML API [Of course], Mail API [Several], Client-Server APIs [Perl can be embedded directly in Apache. Plus there are so many C/S APIs you'd be amazed], embedded systems APIs, telephony APIs, math APIs, graphics APIs, 3D graphics API, and on and on and on and on [...and on and on and on and on and on](there are so many APIs that cover so many areas that it would take several pages to list them - go to the link to see a limited number of available APIs). I doubt very much that Perl has that level of support. Java isn't just for toaster ovens anymore! ;0) Sorry to have to do this, but Perl has a lot more than that B^) The CPAN Archives. See, Perl has modules for almost everything ever under the sun. And it can use C libraries, too though Perl the XS interface. And since Perl is written in C, it uses those natively. Perl has GUI interfaces not only through PTK and tcl, but through a number of other methods depending on your OS. And since it can use C libraries, Perl can use any GUI interface C can. And before long it will be able to read parse Poser files, too. I do have it able to read them into a struct finally. In the next message, I'll post the module thus far. BTW, the main thing is a matter of programmer protocol. Not to scold, but it's generally considered bad form to mention Java in the presence of a Perl hacker (especially to recommend it ever be used anywhere) in much the same way that it's considered bad form to say to a vi user 'why don't you use emacs?' B^)

package PoserParser; use Carp; our $indent = 0; our $chanmode = 0; our $figureResFile;

sub new {
    my $class = shift;
    my $obj = {};
    bless $obj, ref $class || $class;
    return $obj;
}

sub read {
    my $obj = shift;
    my $filename = shift;
    local *PZ3;
    open PZ3, "<$filename"
       or carp "Can't read $filename: $!"
       and return undef;
    $obj->{_fh} = *PZ3{IO};
    my $fh = $obj->{_fh};
    $obj->readPZ3;
}


sub readPZ3 {
    $indent++;
    my $seq = 1;
    my $obj = shift;
    my $fh = $obj->{_fh};
    LINE: while (<$fh>) {
        chomp;
        s/^s+//g;
        s/s+$//g;
        next unless $_;
        if (/{/) {
            $chanmode++ if $chanmode;
#            warn " "x$indent, "Going to read subblock for $obj->{_lastkey}.n"
#                 if $obj->{_debug};
            my $subobj = {_debug => $obj->{_debug},
                          _fh => $obj->{_fh},
                          _seq => $seq};
            if ($chanmode >1 && $obj->{_lastkey} =~ /rotate([XYZ])/) {
                $obj->{_rotseq} .= lc $1;
            }
            $seq++;
            if (defined $obj->{_lastval}) {
                my $id;
                $subobj->{_id} = $obj->{_lastval};
#                warn " "x($indent+2), "(Block is $obj->{_lastkey}, ",
#                     "Subobject ID is $subobj->{_id})n", if $obj->{_debug};
            }
            bless $subobj, ref $obj;
            $subobj->readPZ3;
            if (defined $obj->{$obj->{_lastkey}}) {
                if (ref $obj->{$obj->{_lastkey}}) {
                    if (ref $obj->{$obj->{_lastkey}} eq 'ARRAY') {
                        if (my $idx = $obj->_hkin($obj->{$obj->{_lastkey}}, $obj->{_lastval})) {
                            ${$obj->{$obj->{_lastkey}}}[$idx-1] = {$obj->{_lastval} => {%{${$obj->{$obj->{_lastkey}}}[$idx-1]}, %{$subobj}}};
                            if (my $idx = $obj->_in($obj->{$obj->{_lastkey}}, $obj->{_lastval})) {
                                splice @{$obj->{$obj->{_lastkey}}}, $idx-1, 1;
#warn "I just removed index ",$idx-1," from $obj->{$obj->{_lastkey}}.nIt was $obj->{_lastval} as a scalar.n";
                            }
                        }
                        elsif (my $idx = $obj->_in($obj->{$obj->{_lastkey}}, $obj->{_lastval})) {
                            ${$obj->{$obj->{_lastkey}}}[$idx-1] = {$obj->{_lastval} => $subobj};
                        }
                        else {
                            push @{$obj->{$obj->{_lastkey}}}, $subobj;
                        }
                    }
                }
                else {
                    $obj->{$obj->{_lastkey}} = {$obj->{$obj->{_lastkey}} => $subobj};
                }
            }
            else {
                $obj->{$obj->{_lastkey}} = $subobj;
            }
        }
        elsif (/}/) {
            $chanmode-- if $chanmode;
            last LINE;
        }
        else {
            my ($key, $val);
            /^([a-zA-Z]+)(s+S.*)?$/;
            $key = $1;
            unless (defined $key) {
              warn "Undefined key! Line after $obj->{_lastkey}n";
            }
            if (defined $2) {
              $val = $2;
              $val =~ s/^s+//g;
            }
            if ($key eq 'sphereMatsRaw') {
                $val .= <$fh> for 1..9;
            }
            if ($key eq 'valueOpDeltaAdd') {
                $val .= <$fh> for 1..3;
            }
            if ($key eq 'addChild' or $key eq 'weld') {
                $val .= <$fh>;
            }
            if ((   $key eq 'textureMap'
                 or $key eq 'reflectionMap'
                 or $key eq 'transparencyMap'
                 or $key eq 'bumpMap')
                and $val ne 'NO_MAP') {
                $val .= <$fh>;
            }
            if ($key eq 'channels') {
                $chanmode = 1;
            }
            if ($key eq 'figureResFile') {
                $figureResFile = $val;
            }
            if ($key eq 'geomHandlerGeom') {
                $val = { objFile => $figureResFile,
                         group => $val };
            }
            if (defined $obj->{$key}) {
                if (ref $obj->{$key} eq 'ARRAY') {
                    push @{$obj->{$key}}, $val;
                }
                else {
                    $obj->{$key} = [$obj->{$key}, $val];
                }
            }
            else {
                $obj->{$key} = $val;
            }
            $obj->{_lastkey} = $key;
            $obj->{_lastval} = defined $val?$val:undef;
        }
    }
    $indent--;
}

sub _in {
    my $obj = shift;
    my $ary = shift;
    my $term = shift;
    return undef unless $ary && $term && ref $ary eq 'ARRAY';
    my $count = 0;
    for my $item (@{$ary}) {
        $count++;
        return $count if $item eq $term;
    }
    return undef;
}

sub _hkin {
    my $obj = shift;
    my $ary = shift;
    my $term = shift;
    return undef unless $ary && $term && ref $ary eq 'ARRAY';
    my $count = 0;
    for my $item (@{$ary}) {
        $count++;
        if (ref $item eq 'HASH') {
            return $count if $obj->_in([keys %{$item}], $term);
        }
    }
    return undef;
}

1;

I'm sure there are some weirdnesses in this but it's working finally. B^) Next step is to make it actually PARSE now that I can get the data structure read.

That's the way he was doing it. I don't know why since I don't use Perl. BTW, Java can use C and C++ as well. Java was designed as a platform independent OOP programming language. It was touted for embedded systems because of this. Not just for coffeemakers and toasters. Stop insulting my 15 years experience, please... If I were to take on another language, it would Python, not Perl. Look, I use a tool because it works (Java does), its workflow, its structure, its support, and, in this case, its system independence. That's why I used LISP when doing AI programming, Assembler when working in DOS, and C/C++ when working on applications in Windows/Linux/Amiga. I happen to love OOP (as do most other application programmers) over the primitive and archaic procedural approach. Again, I've been programming for about 15 years. Sorry, Java already can parse Poser files. BYS

To put this in much simpler terms: IMHO, Java would be a better approach. I'm not a Java programmer. I'm a perl programmer and thus inherently cooler than a Java programmer. Nuff said.

Java would objectively not be a better approach, unless you can tell me a simple way to make a Java class accessible in an object-oriented interface to a Perl programmer. My goal is to create a module for perl to parse Poser documents. Java would not help me at all to that end. I don't know XS well enugh to use the C++ Poser library(ies) or I might consider that a valid approach -- many Perl modules actually hook into and use C libs instead of coding in Perl from scratch, and such a module would be tremendously usable to a Perl programmer. A Java class, whether it's already been coded or not, is of no use to a Perl programmer whatsoever. So no, Java would not be a better approach.

Sorry, Java already can parse Poser files. And thus whjy, pray tell, should I write a Java class to do so when one already exists? And again, how would it help a Perl programmer read, manipulate, and create Poser documents?

Lol i was serriously going to learn java then i found out it was the main reason for my browser and out look always crashing so i dissabled java and gave up on that notion. Didnt think there was much money to be made crashing peoples web browers. Though turning on my toaster or coffee pot from work or the car would be trick.

As a short note: I've been programming in Perl for 7 years (I've been programming for about 18 years using BASIC, Pascal, Forth, and some C and Objective C). During that time I've grown very fed up with the fact that there will be the following conversation at least once for every project one starts in Perl: Me: I'm programming such-and-such in Perl Someone: Why don't you do it in Java? Me: (explains a number of reasons to do it in Perl) Someone: Expostulates on why Java is sooo much better and everything should apparently be done in Java. Me: So what does that have to do with the price of te in Hina? Someone: Repeats above expostulation and acts offended that I don't want to do it in Java and decides that my not wanting to do it in ava is a personal affront to their experience. Inevitably this conversation leads to the revelation that the Someone in question does not know Perl. At all. I have never had anyone who knows Perl even relatively fluently tell me I should 'do it in Java'. Never. So... since you do not know Perl and you do not want to know Perl, why is this thread of any interest to you whatsoever? I'm honestly confused. The thread title is not 'PoserParser.class : Java Class in progress', it's PoserParser.pm : Perl Module in progress' Nothing to do with Java. Java would not be of any use to a Perl programmer. So writing a Java class would not in any way help a Perl programmer. The only thing I can think of is that you, for some reason, want to make sure Perl programmers aren't able to read, parse, manipulate and create Poser documents using an OOP interface within Perl. Like I said, I just do not understand this.

Actually, here -- this should explain why I'm a Perl programmer and not a Java programmer, in case that was the real question... the following is a repost from comp.lang.perl

Subject: Re: byte array in perl, how? pack, unpack? java to perl
From: "John W. Krahn" <*****@***.org>
Newsgroups: comp.lang.perl.misc

vientoloco wrote:
> 
> This funtions are in java.
> I'll try to find similar functions in perl.
> Help, please :)
> Any tutorial?
> 
> /**
>   * transforms a hexadecimal string to a byte array
>   * @return the byte array, or null if the passed String is null
>   * @exception IllegalArgumentException if the passed String is not
> haxadecimal encoded */

In perl you usually don't work with byte arrays but with strings.


>  public static byte[] fromHex(String hex) {

sub fromHex {
    my $hex = $_[0];


>    if (hex == null) {
>      return null;
>    }

    return unless length $hex;


>    else if ((hex.length() % 2) != 0) {
>      throw new IllegalArgumentException("Hex String length must be a
> multiple of 2.");
>    }

    die "Hex String length must be a multiple of 2.n" if length $hex %
2;


>    int length = hex.length() / 2;
>    byte[] result = new byte[length];
>    String hits = "0123456789ABCDEF";
>    String h = hex.toUpperCase();
> 
>    for (int i = 0; i < length; i++) {
>      char c = h.charAt(2 * i);
>      int index = hits.indexOf(c);
>      if (index == -1) {
>        throw new IllegalArgumentException("Hex String can't contain '"
> + c +"'");
>      }
> 
>      int j = 16 * index;
>      c = h.charAt((2 * i) + 1);
>      index = hits.indexOf(c);
>      if (index == -1) {
>        throw new IllegalArgumentException("Hex String can't contain '"
> + c +"'");
>      }

    die "Hex String can't contain '$1'" if $hex =~ /([^[:xdigit:]])/;
<i><b>[Will you look at that!??]</b></i>

>      j += index;
> 
>      result[i] = (byte) (j & 0xFF); }

    $hex =~ s/([[:xdigit:]]{2})/chr hex $1/ge;


>    return result;

    if ( wantarray ) {
        return split //, $hex;
    }
    else {
        return $hex;
    }


>  }


John
-- 
use Perl;
program
fulfillment

BTW, the return result part there at the end =-- the only place Perl has more lines than Java to do the same thing --can be done in one line with a trinary, like so: return wantarray?split(//, $hex):$hex;

Well, I guess that means you really don't want any of my experience, help, or algorithms. Oh, well. I mentioned Java because it's a good OOP language (despite what you keep bickering about). Perl's good, but it's not OOP - which is where everything is going (if Perl is OOP, I missed it somewhere in your code and my brief encounters with it). Reminds me too much of COBOL in some ways. Another good procedural language that I don't like (I don't fancy C as much any more either). How many people program in COBOL these days? Coming from C then C++, Java is a natural progression for me - though I still program C++ for targeted platform code. Don't tell me that you think C++ is for toasters too? Instead of noodly code, I can show a full screen shot of my working java app. But I guess full-blown working apps don't impress you either. That's the thing. After working (working really hard) to code in C and C++, Java was the fastest development that I've encountered (even wrt BASIC). Maybe Perl has it, but I haven't come across it as a programmer for, once again, 15 years (is it sinking in yet that I'm no weekend coder? I've programmed for large corporations, for robotics, for APIs, for AIs, as well as stand alone applications). I've seen app SDKs using C, C++, Python, but none using Perl. And none using Java (yet). Only reason that I'm not into that much programming now is that I'm trying to move into 3D CG animation - which is going very well now that I've mastered Poser, Cinema 4D, and am quickly gripping LightWave and Maya. My point - handling Poser parsing and "data storage" is easy in classes. C++ has classes, but, honestly, it can be mind-numbing trying to code in it - especially the esoteric stuff. I basically consider C++, C patched with classes. Java, on the other hand, was easy, easy, and easier. The only encountered frustrations with it were in dealing with a third-party api (JAI), which is about as esoteric as any api can get. The only two other languages that I'd look at are Python (which I have tried) and maybe C# (which I haven't). Have fun... BYS

BYS, you said Java would be a batter thing to write a Perl module in. I'm open to any real suggestions, but you vehemently insisted that Java would be a better language for a Perl module. Perl is a language that's built around and dedicated to text munging. Sure, it's possible to use Inline::Java to include it, but that's absurd. Text munging is not a Java strength. It's a perl strength. Poser files are text files. Perl is OOP. Note the new method in this module:

sub new {
    my $class = shift;
    my $obj = {};
    bless $obj, ref $class || $class;
    return $obj;
}

This, in combination with the package declaration at the top of the module, mean that all the methods (the subroutines defined within the package namespace), are called from the object created and returned by the new() method. Maybe Perl has it, but I haven't come across it as a programmer for, once again, 15 years (is it sinking in yet that I'm no weekend coder? Will you bloody stop that. Stop takign the fact that I am not going to develop a PERL MODULE in JAVA personally. Yeesh. As a note -- you've specifically stated that you're not a perl programmer, you do not know perl, and you do not code perl. Therefore it's in no way surprising that you haven't seen the development runaround time in Perl. Working, full blown apps impress me plenty. Java apps impress me less, primarily because ther'es something wrong with the feel of the interface. As far as Perl SDKs, the GImP (essentially, the freware Photoshop) uses Perl as its scripting backend. More importantly, however, is the PDK available from Activestate. Yes, it's a full blown developer's kit capable of compiling both to full-blown standalone applications and to activeX controls, among other things. And yes, there's VisualPerl, a .NET extension. The MacPerl implementation of perl contains the ability to compile both standalone code and 'droplets' with an embedded, slimmed-down Perl interpreter. It should be noted that ActiveState is also the place that makes the Python Developer's Kit. They did Perl first. It's a real honest-to-god programming language. BTW, here are some objective or semi-objective comparisons: - http://www.flat222.org/mac/bench/

• http://rc3.org/cgi-bin/less.pl?arg=5040 (with which I disagreee -- the Perl code is muchy more concise and not needlessly wordy, but it could be coded JUST LIKE the Java version with only cosmetic differences. TMTOWTDI)
• http://use.perl.org/article.pl?sid=02/09/16/1448246&mode=thread&tid=35&threshold=-1
• http://www.infocopter.com/perl_corner/perl-vs-java-de.htm Notes that Perl is better with Rapid Application Development with an average development cost about 20% lower
• This one has me cheering: http://www.oreillynet.com/cs/weblog/view/wlg/461

Okay, here... let's just reverse this conversation and you can tell me how silly it might sound... This all takes place in an alternate world where there already is a Poser Parser module for Perl, but none for Java. In this world, you, BYS, decided the natural progression from C++ was to Perl and I decided Java was the best language for what I do. Alternate World Me: I'm going to develop a class for Java for the parsing, manipulation, and creation of Poser documents. I have it reading everything into a struct and have defined my class and so on. I don't have it parsing yet, but soon! Soon Java will be able to parse Poser docs! Alternate World You: Well, I think Perl would be a better approach, IMHO. AWM: I don't see what you mean. I don't like Perl and I want to program in Java. I don't know Perl and can't program in it. It has weird string manipulation techniques and I think it's a lot better to step one-by-one through a byte-array or use a String Object so that I have length+24 overhead on every string. AWY: No, Java doesn't allow for Functional Programming and has a slower turnaround time for development. You should use Perl. Those funny string manipulation techniques are regexes. AWM: But I'm writing a Java Class! How or why would you suggest I write a Jave class in Perl? Is there some way to inline Perl code into Java? Does it require a Perl interpreter or does it inline a bytecode Miniperl? Even then, why wouldn't I write a Jave class in native Java? AWY: Obviously you don't want my advice or knowledge and you're making a mockery of my 15 years of experience as a programmer. I decided Perl was the best language some time ago and I don't know Java at all. Because I have been programming for a long time by my reckining and regardless of how much experience you have, I must obviously know more about this than you and your rejection of my suggestion to write a Java Class in Perl indicates your complete and utter lack of respect for my experience, my god, queen, and country, myself persnally, my mother, my wife and our three dogs. You must hate me because you don't want to program a Java Class in Perl. Fine, then go away. I will have no more of this! Begone foule stinkybeast!

In Perl, some things do not look the same as in many other languages. For instance, package SomePackageName; is a namespace declaration. Namespace is basically perl's way of declaring a class. In Perl, an object is simply a reference that has been blessed into a namespace (and thus can call methods within that namespace implicitly passing itself as the first argument to them). Usually this reference is a HoH (Hash of Hashes). It doesn't have to be, but programmers of other languages will be generally more comfortable with this idea because a HoH most resembles what you'd think of as a struct. In C, think like it's a map of maps. Or a struct. In Java consider it pretty much analogous to a normal Object. And yes, hashes aren't always mega-fast in Perl. However, unlike Java it does have qsort. B^) Perl doesn't use '.' as a method or property accessor operator. That's because '.' was defined long, long ago as the string concatenation operator, and no one wants to change that now. For instance, in VB one would not expect to find them suddenly deciding that '&' is an access operator. Instead, perl uses the -> operator. It uses these to access and dereference any reference, blessed into a package (class) or not. A reference is something like a pointer, but not quite. An anonymous HoH is made by assigning a hash of hashes to a scalar variable (basically a string variable, though in this case it's a reference not a string). Thus: $hashref = { A => 'Apple', J => 'Jacks' }; Defines a hashref. If we do this: $hashref->{J} = {Boy => 'Jacks', Girl => 'Jills'}; Then we have made it an HoH, just as if we'd initially defined it as: $hashref = { A => 'Apple', J => { Boys => 'Jacks', Girls => 'Jills' } }; Now, if we want this to be able to access the methods defined in the SomeClass namespace, we can do this: bless $hashref, 'SomeClass'; And it's now part of the SomeClass namespace instead of part of MAIN, even if it was created by a subroutine (function or in this case constructor method) called from MAIN. So if, within package 'SomeClass' we have:

sub HiThere {
    my $obj = shift;
    my $who = shift;
    return 'I don't talk to strangers' unless $who;
    return "Ahoy there, $who";
}

Then we can call this method like, say: print $hashref->HiThere('Dodger'), "n"; And Perl will send "Hi there, Dodgern" to STDOUT, wherever that may be. This is a silly example because it doesn't involve the object passed to it as the first argument, which is automatically the reference that the method was called through. But instead, we could have made it store a message inside of the object, which is more what OO is best for. I.e.: sub HiThere { my $obj = shift; my $who = shift; $obj->{greeting} = $who ? "Ahoy there, $who" : 'I don't talk to strangers'; return $who ? 1 : undef; }

And this would be useful for something like: if ($hashref->HiThere('Dodger')) { print $hashref->{greeting}, "n"; } else { warn "Oooh, go away you weird man youn"; }

That's not only object-oriented, but it also allows you to play much deeper with the guts of it. the difference is that not only it is object-oriented, it's also able to be NOT object-oriented depending on what you need to do. Most people know the old adage about the toolbox: better to have a hammer, a saw and a screwdriver than to have 57 hammers in there. Anyway, this should give a decent primer of what you're looking at up there in my module.

You're both wackos. Settle this like REAL nerds do. . Protractor races.

but -- but... can I make an electronic one? It shouldn't be too much work to build the drivers for Windows in assembly, and the concept is pretty simple -- just have a contact that reduces in resistance as the angle inceases! B^) (Or I could code it to use Java)

First off, I must get this out of my system so that my ego doesn't revolt at what I'm about to post further on: Real Men don't NEED Runtime environments - they code in C (and maybe they use classes.) That being said, this Perl thingy has piqued my interest - mostly because of it's portability (and the fact that there are scads of tools out there that can convert it into perfectly workable *ix binaries :) .) Dodger - what is the end result here - just to parse a .cr2 and pick out the useful parts (which is damned useful to a slob wanting to make a utility, but otherwise the average Poser user is gonna shrug his shoulders and go "huh?"), or what exactly are you looking to do beyond parsing? If you're building a simple viewer, you're well on your way. If you were up to building a DAZ|Studio or Poser-like clone, emulating those two would take a gallon of work... If I were to choose between the two, it would prolly be Perl, mostly because its runtime isn't such a resource hog. /P

Attached Link: http://www.dodger.org/ttt/poserParser/test6.html

First off, update: it actually parses now. It reads things into a data structure intelligently -- a data structutre that acts like it knows what it's talking about, as opposed to stage 1 which was just reading into a multidimensional set of key/value pairs. See link for example output.

Second, here's an overview of the project's goals, as if I were submitting this for a client, though more sloppy:

Project: Poser Parser Perl Extension

• Intended Goal: Perl Module for Object-Oriented interface to create, read, manipulate, and write arbitrary Poser documents
• Breakdown of goals and statuses: Read and Parse Poser Documents via Perl Read in a Poser Object Definition Document (PZ3, CR2, PP2, HR2) or Poser Object Property Overlay (PZ2, HD2, FC2, MT5) or any existing hybrid file of these two core types (LT2, CM2) plus an additional filetype outside of the specification (P4 Material Definition: MT4) to a Perl data structure built from hashrefs and arrayrefs. Additionally, parse any known Poser Definition/Overlay keywords and store the values of recognised properties in an intelligent manner, storing unrecognised properties as arbitrary (freeform) strings. Status: Private Limited Beta Manipulate Poser Documents in Perl Add object methods to conveniently provide a user the ability to access subparts of a defined Poser document data structure, including but not limited to redirecting files, changing settings, replacing entire block definitions (for instance, changing one material definition for another one stored in an MT4 material deifnition file), rearrange them, and otherwise generally munge the data through an OO interface. Status: Pre-Alpha Create Poser Documents Using an Object-Oriented Perl interface, create Poser document data structures from whole cloth with automated defaulting of values pre-formulated and ready for OO manipulation as above. Status: Pre-Alpha Write Poser Documents via Perl Return syntactically correct and properly formatted Poser documents for output or storage Status: Pre-Alpha (next up)

Uses for this extension are really only limited by the imagination of the Perl user who uses it. Examples include:

• Batched and Automated matching of material settings for a set. For instance, if you are producing a large number of accessories to come in a set, Perl could be used in conjunction with this module to automatically set all 'steel' materials to the same material settings
• Simple Automated P4/P5 Compatibility
• Batched Morph Management
• Web-based interactive Poser Document editing
• Pose/MAT Pose/INJ Pose extraction
• Embedded Geometry Extraction
• Joint Editing
• Scene Mirroring

Other potentials for this module (together with the projected Wavefront OBJ parser) include the ability to create new morphs from morph target geometries outside of Poser, creation of geometry (interacting with a Fractal generator, prefab primitives, etc), and so on. All in all, the end goal is to simplify interacting with Poser documents when using Perl by providing an OO interface to them rather than treating them as arbitrary text documents (as is currently the only way to deal with them in Perl).

Real Men don't NEED Runtime environments - they code in C (and maybe they use classes.) Heh. Yep. Perl is coded in C B^)

Actually - this would be kinda cool for extracting individual char, prop, light, etc. files out of a .pz3 file... wihtout the tedium of loading a monster .pz3 file, or to recover parts of an otherwise corrupted .pz3 file. So instead of blending stuff you could make a respectable extraction toolkit out of it as well. PS: Don't make me go in there and convert it into a real language (and not that sissy scripting wannabe stuff) when you're done :p PPS: Incidentally, WRT Macs, OS 10.x will prolly have it, but does OS 9.x have a Perl interpreter? The Poser stuff is OS9 (since there is no Mac P5 yet), so portability may be limited to Win and Linux (err, it would be usable for us Win4Lin-using slobs, but not many others on the *ix side of the fence.) PPSS: Get hold of FlyerX - he's had to wrestle with all this Poser format bullshit before, back when he built Poseray (the free Poser-to-POV-Ray translation proggie. it even came with a built-in quick-viewer.) If nothing else you may be able to get hold of a nice GUI framework to stick it all in, and some modules that may come in handy for visual preview and all that happy crapola... If you're real lucky, CL may have told him enough about the file format std's to cut down on your workload by whole orders of magnitude. /P

All sorts of things, yup! One of my goals is having an easy way to build a consistent materials library setup andapply things automatically. Right now I've started cutting and pasting material blocks in, but it would be sooo much nicer to have the whole thing coded instead. You don't have to. There are Perl modules that export Perl as C B^) MacPerl is very popular among Maccies. I'm past wrestling with the Poser format. I'm done with that part. It's the output that I'm writing next, then the manipulation subroutines and convenience methods. Remember, I'm not writing a program here. I'm programming a Perl Extension. Other people will be free to use Perl and it to make programs, but a program isn't my goal. Some automation scripts for myself are my goals.

BTW, running strings on the Poser executable shows all the input formats in plain old printf/sprintf/readf formats B^)

"You don't have to. There are Perl modules that export Perl as C" Yep - but a lot of 'em do have problems in the memory department... but at least I can go back through and clean that up. OTOH, I am getting hold of SlickEdit, which is a nice little IDE that does all that conversion stuff for me - then I can pump the results through StackGuard (to fix any overrun potentials), do a final parsing of the results by eyeball, and the code will be guaranteed to be in usable order :) No worries - if you have a working parser/extractor thingy, the rest can be done fairly easily by anyone else - even if they don't know the Poser formats. It makes sense that Poser.exe would have the usual I/O plugs - esp. since it was a conversion of Mac-based code.:) /P

Yup. Not to mention that with some regex libs it's a piece of cake to translate manually. The only control structure that's significantly different is the foreach construct, and that's not even hard to work out in C.