From darren at DarrenDuncan.net Fri Jul 4 18:48:17 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] testing two refs for same target Message-ID: Hello. I have one or more questions of the Perl gurus that I'm unsure of myself. I wanted to know what the standard or best practice is for comparing two references to see if they point to the same item/object. What I had thought of was simply doing "$ref1 eq $ref2", but I wanted to know whether there was a better way. The context is that I have an array of references to objects and also a scalar having a reference to one of the same objects in the array; I want to remove the identified object from the list, so I need to know which one it is. On a related note, do you know if Perl allows you to remove elements from an array while you are running a foreach loop on it; for example: foreach my $item (@items) { if( $item eq $wanted_item ) { remove_current_item(@items); last; } } In other words, does Perl have a built-in function like "remove_current_item"? Currently I am doing something like this: foreach my $i (0..$#items) { my $i_to_remove; if( $items[$i] eq $wanted_item ) { $i_to_remove = $i; last; } } splice( @items, $i_to_remove, 1 ); But that looks messier than I would like. On a separate but related question, is it reasonable to use object references as keys in a hash? So I could for example, do this: delete( $items{$wanted_item} ); Finally, would any of the above actions cause the object references to stringify and no longer be references? Essentially, I'm sort of exploring new territory here. Thanks for any answers. BTW, I plan to upload tonight the first version of SQL::ObjectModel (name registration pending; used by Rosetta) which one can actually use for something (not just documentation), although it will be at alpha development status. This class is an unserialized representation of SQL, and would be the standard way of formatting database commands for Rosetta to execute. My main question above relates to deleting the link from a node's parent to itself. Have a good day. -- Darren Duncan From michael at negativespace.net Fri Jul 4 22:10:31 2003 From: michael at negativespace.net (Michael S. Joyce) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] testing two refs for same target In-Reply-To: References: Message-ID: <1057374630.2149.40.camel@localhost> I has been quite a while since I've done any real Perl, but here goes. I don't consider myself a guru. > I wanted to know what the standard or best practice is for comparing two > references to see if they point to the same item/object. Well, a reference in a string context gives you things like "ARRAY(0x9384934)". The number is an internal perlism which is supposed to uniquely identify the target of the reference. So, if two references stringify to the same string, they should be equal. > What I had thought of was simply doing "$ref1 eq $ref2", but I wanted to > know whether there was a better way. That should work, as eq provides a string context for both operands, so the refs get stringified, like above. > The context is that I have an array of references to objects > and also a scalar having a reference to one of the same objects > in the array; I want to remove the identified object from the > list, so I need to know which one it is. > > On a related note, do you know if Perl allows you to remove > elements from an array while you are running a foreach loop > on it; for example: > > foreach my $item (@items) { > if( $item eq $wanted_item ) { > remove_current_item(@items); > last; > } > } I remember reading somewhere that modifying the amount of things in a list with foreach was a bad idea, and produced unexpected results. I think there was something on perlmonks about it. > In other words, does Perl have a built-in function like "remove_current_item"? Currently I am doing something like this: > > foreach my $i (0..$#items) { > my $i_to_remove; > if( $items[$i] eq $wanted_item ) { > $i_to_remove = $i; > last; > } > } > splice( @items, $i_to_remove, 1 ); This is the safe way to do it. You could also use grep. @list = grep {$_ ne $wanted_item}, @list but be warned: that will remove everything that is equal to $wanted_item, not just the first one as yours does. > But that looks messier than I would like. > > On a separate but related question, is it reasonable to use object > references as keys in a hash? So I could for example, do this: > > delete( $items{$wanted_item} ); Programming Perl, 2nd edition (the Camel) has a section called "Hard References Don't Work as Hash Keys" on p256. The problem is that hash keys are stored internally as strings, so when you use a reference as a hash key, it gets stringified into "ARRAY(0xSOMETHING)". The interpreter is free to move things around in memory, so if you ever go to dereference your hash key, you will likely get garbage. To quote the camel: $x{ \$a } = $a; ($key, $value) = each %x; print $$key; #WRONG! The Perl Cookbook mentions(p486) Tie::RefHash, which is meant to correct this problem. I've never used it, so I cannot comment on it. The book also makes a reference to Tie::RevHash, but I think that may be a misprint. > Finally, would any of the above actions cause the object > references to stringify and no longer be references? Stringification doesn't change the actual reference. $x = \$a; print "$x" #stringify $x print $$x; #still prints whatever was in $a. > Essentially, I'm sort of exploring new territory here. > > Thanks for any answers. You're welcome. > BTW, I plan to upload tonight the first version of SQL::ObjectModel (name > registration pending; used by Rosetta) which one can actually use for > something (not just documentation), although it will be at alpha development > status. This class is an unserialized representation of SQL, and would > be the standard way of formatting database commands for Rosetta to > execute. My main question above relates to deleting the link from a > node's parent to itself. > > Have a good day. -- Darren Duncan > Thank you. I've a weekend with no homework. I'm very excited. Michael From darren at DarrenDuncan.net Sat Jul 5 00:20:44 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] testing two refs for same target In-Reply-To: <1057374630.2149.40.camel@localhost> References: <1057374630.2149.40.camel@localhost> Message-ID: At 8:10 PM -0700 7/4/03, Michael S. Joyce wrote: > > In other words, does Perl have a built-in function like "remove_current_item"? Currently I am doing something like this: >> >> foreach my $i (0..$#items) { >> my $i_to_remove; >> if( $items[$i] eq $wanted_item ) { >> $i_to_remove = $i; >> last; >> } >> } >> splice( @items, $i_to_remove, 1 ); > >This is the safe way to do it. You could also use grep. > > @list = grep {$_ ne $wanted_item}, @list > >but be warned: that will remove everything that is equal to >$wanted_item, not just the first one as yours does. Hello Michael, thanks for your answers. In the above example, it does look like your solution is much shorter than mine, and that it would work. In some ways, your solution is better, and I will probably use it for that. This is because (although I would have to verify it), a user may declare more than once that one node is the child of another, meaning a reference to the child would appear in the list of the parent's children more than once. If I was severing the link (which I was), then I would actually want to remove all occurances. One reason that I used the solution I did, aside from not thinking of the one you provided, is that it may be faster, since it doesn't go through the whole list every time. On the other hand, maybe it isn't faster. But I think I may go with your solution anyway. -- Darren Duncan From peter at PSDT.com Sat Jul 5 00:41:46 2003 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] testing two refs for same target In-Reply-To: <1057374630.2149.40.camel@localhost> References: Message-ID: <4.3.2.7.2.20030704222901.00ab1580@shell2.webquarry.com> Hello from Port Angeles (en route to OSCON/Perl Conference 7). At 08:10 PM 7/4/2003 -0700, Michael S. Joyce wrote: > > I wanted to know what the standard or best practice is for comparing two > > references to see if they point to the same item/object. > >Well, a reference in a string context gives you things like >"ARRAY(0x9384934)". The number is an internal perlism which is supposed >to uniquely identify the target of the reference. So, if two references >stringify to the same string, they should be equal. > > > What I had thought of was simply doing "$ref1 eq $ref2", but I wanted to > > know whether there was a better way. > >That should work, as eq provides a string context for both operands, so >the refs get stringified, like above. Correct. And in a deliberate bit of magic, == also works (references get nummified to unique values as well. Not hard to guess what values). > > On a related note, do you know if Perl allows you to remove > > elements from an array while you are running a foreach loop > > on it; for example: > > > > foreach my $item (@items) { > > if( $item eq $wanted_item ) { > > remove_current_item(@items); > > last; > > } > > } > >I remember reading somewhere that modifying the amount of things in a >list with foreach was a bad idea, and produced unexpected results. I >think there was something on perlmonks about it. > > > In other words, does Perl have a built-in function like > "remove_current_item"? No. >Currently I am doing something like this: > > > > foreach my $i (0..$#items) { > > my $i_to_remove; > > if( $items[$i] eq $wanted_item ) { > > $i_to_remove = $i; > > last; > > } > > } > > splice( @items, $i_to_remove, 1 ); > >This is the safe way to do it. You could also use grep. > > @list = grep {$_ ne $wanted_item}, @list > >but be warned: that will remove everything that is equal to >$wanted_item, not just the first one as yours does. A good example of why some people have wanted to be able to last out of a grep block. However, Duncan did say that "one of the items" in the array would be the same object. > > But that looks messier than I would like. > > > > On a separate but related question, is it reasonable to use object > > references as keys in a hash? So I could for example, do this: > > > > delete( $items{$wanted_item} ); > >Programming Perl, 2nd edition (the Camel) has a section called "Hard >References Don't Work as Hash Keys" on p256. The problem is that hash >keys are stored internally as strings, so when you use a reference as a >hash key, it gets stringified into "ARRAY(0xSOMETHING)". The interpreter >is free to move things around in memory, so if you ever go to >dereference your hash key, you will likely get garbage. >To quote the camel: > > $x{ \$a } = $a; > ($key, $value) = each %x; > print $$key; #WRONG! > >The Perl Cookbook mentions(p486) Tie::RefHash, which is meant to correct >this problem. I've never used it, so I cannot comment on it. The book >also makes a reference to Tie::RevHash, but I think that may be a >misprint. Yes, it would be. I've not yet bothered with Tie::RefHash; I usually solve this problem with a parallel hash that maps the stringified object to the object itself: for my $obj (@objects) { $objhash{$obj} = $obj } In this case, since the hash is replacing an array in the application, there's no other data to be associated with the object and so the hash is sufficient by itself, i.e., Duncan can do what he wants if he populates the hash as above. This is a recognized idiom. > > Finally, would any of the above actions cause the object > > references to stringify and no longer be references? > > Stringification doesn't change the actual reference. > > $x = \$a; > print "$x" #stringify $x > print $$x; #still prints whatever was in $a. Right. Stringification doesn't change anything (unless it's overloaded in a very antisocial class). Using the stringified value is the gotcha. -- Peter Scott peter@psdt.com http://www.perldebugged.com From Peter at PSDT.com Sat Jul 5 00:48:18 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] testing two refs for same target In-Reply-To: References: <1057374630.2149.40.camel@localhost> <1057374630.2149.40.camel@localhost> Message-ID: <4.3.2.7.2.20030704224621.00aa4490@shell2.webquarry.com> At 10:20 PM 7/4/2003 -0700, Darren Duncan wrote: > >This is the safe way to do it. You could also use grep. > > > > @list = grep {$_ ne $wanted_item}, @list > > > >but be warned: that will remove everything that is equal to > >$wanted_item, not just the first one as yours does. > >Hello Michael, thanks for your answers. In the above example, it does >look like your solution is much shorter than mine, and that it would >work. In some ways, your solution is better, and I will probably use it >for that. This is because (although I would have to verify it), a user >may declare more than once that one node is the child of another, meaning >a reference to the child would appear in the list of the parent's children >more than once. In which case the hash solution wouldn't work. Strange sort of inheritance relationship you've got going there... >If I was severing the link (which I was), then I would actually want to >remove all occurances. One reason that I used the solution I did, aside >from not thinking of the one you provided, is that it may be faster, since >it doesn't go through the whole list every time. On the other hand, maybe >it isn't faster. But I think I may go with your solution anyway. -- >Darren Duncan -- Peter Scott peter@psdt.com http://www.perldebugged.com From darren at DarrenDuncan.net Sat Jul 5 02:15:07 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] testing two refs for same target In-Reply-To: <4.3.2.7.2.20030704224621.00aa4490@shell2.webquarry.com> References: <1057374630.2149.40.camel@localhost> <1057374630.2149.40.camel@localhost> <4.3.2.7.2.20030704224621.00aa4490@shell2.webquarry.com> Message-ID: Peter Scott said: >In which case the hash solution wouldn't work. Hello Peter; thank you for your replies too. Actually, if a user is declaring more than once that a node is a child of another, this would likely be considered an error, but it is one that my current input checking routines don't look for. A hash would be ideal except that I am interested in maintaining the order of all the child nodes under a parent. I may probably end up using both an array and a hash which both list the same items, for different reasons. >Strange sort of inheritance relationship you've got going there... I should clarify that there is technically no inheritence being used here. All of the "nodes" are each separate objects, all of which are in the same class. SQL::ObjectModel is conceptually similar to an XML DOM, which has a tree of nodes, except that it is more specialized in its content. If it were practical to do so I may even change it later to subclass an XML DOM implementation or something. But I probably won't since I don't need most of the DOM features and they take up space. -- Darren Duncan From Peter at PSDT.com Sat Jul 5 10:22:03 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] testing two refs for same target In-Reply-To: References: <4.3.2.7.2.20030704224621.00aa4490@shell2.webquarry.com> <1057374630.2149.40.camel@localhost> <1057374630.2149.40.camel@localhost> <4.3.2.7.2.20030704224621.00aa4490@shell2.webquarry.com> Message-ID: <4.3.2.7.2.20030705081908.00aafca0@shell2.webquarry.com> At 12:15 AM 7/5/2003 -0700, Darren Duncan wrote: >Actually, if a user is declaring more than once that a node is a child of >another, this would likely be considered an error, but it is one that my >current input checking routines don't look for. Ah, then a hash would be ideal: $child{$obj} ? error("Object is already a child") : ($child{$obj} = $obj); > A hash would be ideal except that I am interested in maintaining the > order of all the child nodes under a parent. tie %child, "Tie::IxHash"; >I may probably end up using both an array and a hash which both list the >same items, for different reasons. > > >Strange sort of inheritance relationship you've got going there... > >I should clarify that there is technically no inheritence being used >here. All of the "nodes" are each separate objects, all of which are in >the same class. I misspoke. I meant the parent-child relationships you were talking about. But we should reserver 'inheritance' for class relationships, so in your case it's a container tree, or... someone help me out with the proper term here. >SQL::ObjectModel is conceptually similar to an XML DOM, which has a tree >of nodes, except that it is more specialized in its content. If it were >practical to do so I may even change it later to subclass an XML DOM >implementation or something. But I probably won't since I don't need most >of the DOM features and they take up space. -- Peter Scott peter@psdt.com http://www.perldebugged.com From darren at DarrenDuncan.net Sun Jul 6 21:07:24 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] question about possible Perl runtime bug Message-ID: Hello. I have found a situation, when using both Perl 5.6.0 and 5.6.1, which suggests that Perl is executing something that I would expect to be an error. Please see the following, simplified example: use strict; use warnings; sub myfunc { _myfunc( 5, {} ); } sub _myfunc { my ($count,$gotten_already) = @_; print "args are '$count' and '$gotten_already'\n"; $gotten_already->{$count} = 1; print "size is ".(keys %{$gotten_already})."\n"; $count--; if( $count > 0 ) { if( $count == 3 ) { _myfunc( $count ); } else { _myfunc( $count,$gotten_already ); } } } myfunc(); When I run that code, I get the following output: args are '5' and 'HASH(0x80fe22c)' size is 1 args are '4' and 'HASH(0x80fe22c)' size is 2 Use of uninitialized value in concatenation (.) or string at - line 10. args are '3' and '' size is 1 args are '2' and 'HASH(0x811e73c)' size is 2 args are '1' and 'HASH(0x811e73c)' size is 3 What I am expecting is for Perl to die after printing the second output line. On the third invocation of _myfunc(), "$gotten_already" contains an undefined value, because it wasn't passed one. However, the interpreter still treats the variable as a valid hash reference, even though I never passed one in. Considering that I am using strict, why is automatically creating a hash ref when I try to use it without scolding me for not explicitely declaring/creating the hash ref first? Is this a bug? Or is it so-called "proper behaviour"? Thanks for any light you can shed on this. -- Darren Duncan From nkuipers at uvic.ca Sun Jul 6 21:32:45 2003 From: nkuipers at uvic.ca (Nathanael Kuipers) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] question about possible Perl runtime bug Message-ID: <3F08DE79@wm2.uvic.ca> >is it so-called "proper behaviour"? I *think* that what you have encountered is called autovivification, and depending how you look at it, it's Perl being naughty or nice. There was a thread on this on perlmonks last week, some moron was complaining that he was mis-spelling his keys or even hash names and loading up the wrong hashes with the wrong values, and he wanted a 'no autovivification' sort of pragma. I told him to stop whining and pay more attention while programming. :) Gosh, hope it wasn't any of you... nathanael From darren at DarrenDuncan.net Sun Jul 6 22:11:35 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] question about possible Perl runtime bug In-Reply-To: <3F08DE79@wm2.uvic.ca> References: <3F08DE79@wm2.uvic.ca> Message-ID: nathaneal said: > >is it so-called "proper behaviour"? > >I *think* that what you have encountered is called autovivification, and >depending how you look at it, it's Perl being naughty or nice. There was a >thread on this on perlmonks last week, some moron was complaining that he was >mis-spelling his keys or even hash names and loading up the wrong hashes with >the wrong values, and he wanted a 'no autovivification' sort of pragma. I >told him to stop whining and pay more attention while programming. :) > >Gosh, hope it wasn't any of you... No, that wasn't me. I've never used or read Perl Monks before, although I have heard that they exist. That said, I came up with my question here while trying to debug a method I wrote (the bug was that I didn't pass a hash reference as an argument when I should have). When I discovered the problem, I figured that this was something Perl should be checking for. Just as we have "use strict" to turn off auto-variable-instantiation, we should have something to disable auto-vivification. If I pass a scalar and try to use it as a hash ref, Perl has a runtime error, but it isn't with an undefined value; I would expect the same behaviour when the variable contained anything but a hash ref. I will look into this issue later, and if the functionality doesn't exist, I will suggest it to the relevant Perl core developers. -- Darren Duncan From darren at DarrenDuncan.net Sun Jul 6 22:13:05 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] question about possible Perl runtime bug Message-ID: As an addendum, Perl is supposed to make easy things easy and so forth. Having a no-auto-vivify option will certainly make it a lot easier to develop in. This is something that should be handled at the language level, not the app level. -- Darren Duncan From Peter at PSDT.com Mon Jul 7 16:50:54 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] question about possible Perl runtime bug In-Reply-To: References: Message-ID: At 8:13 PM -0700 7/6/03, Darren Duncan wrote: >As an addendum, Perl is supposed to make easy things easy and so >forth. Having a no-auto-vivify option will certainly make it a lot >easier to develop in. This is something that should be handled at >the language level, not the app level. -- Darren Duncan May I suggest not opening that can of worms in p5p. The issue has been discussed to death before and there is nothing new here. The mode you suggest has been discussed and I think it is at the "patches welcome" stage. The behavior is documented; it's very useful for things like multilevel hash population: $foo{bar}{baz} = 42; I've never actually wanted to turn it off; there have been many cases when I was glad it was there. Well, there might have been one case when I wanted to turn it off. Usually the thing that annoys people is that exists() will autovivify the first level hash key: if (exists $foo{bar}{baz}) # autovivifies bar key I think that's the case that got in my way once. If you search the archives you'll find out why no one has yet figured out how to stop this from happening. Peter (on iBook in tutorial at Perl Conference) From abez at abez.ca Mon Jul 7 18:20:35 2003 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] question about possible Perl runtime bug In-Reply-To: References: Message-ID: Yah so much code depends on it and it saves a lot of headaches for a simple hack but in a larger system stuff like auto-vivify is a pain. Just remember to use exists or make a small lib of handle anti-auto-vivify methods. abram On Mon, 7 Jul 2003, Peter Scott wrote: > At 8:13 PM -0700 7/6/03, Darren Duncan wrote: > >As an addendum, Perl is supposed to make easy things easy and so > >forth. Having a no-auto-vivify option will certainly make it a lot > >easier to develop in. This is something that should be handled at > >the language level, not the app level. -- Darren Duncan > > > May I suggest not opening that can of worms in p5p. The issue has > been discussed to death before and there is nothing new here. The > mode you suggest has been discussed and I think it is at the "patches > welcome" stage. > > The behavior is documented; it's very useful for things like > multilevel hash population: > > $foo{bar}{baz} = 42; > > I've never actually wanted to turn it off; there have been many cases > when I was glad it was there. Well, there might have been one case > when I wanted to turn it off. Usually the thing that annoys people is > that exists() will autovivify the first level hash key: > > if (exists $foo{bar}{baz}) # autovivifies bar key > > I think that's the case that got in my way once. If you search the > archives you'll find out why no one has yet figured out how to stop > this from happening. > > Peter (on iBook in tutorial at Perl Conference) > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From darren at DarrenDuncan.net Mon Jul 7 23:47:47 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] I have uploaded a working SQL::ObjectModel today Message-ID: Hello. As hinted at on Friday, I have now (a few days late) uploaded my first SQL::ObjectModel (part of Rosetta) version that you can actually play with. The code and documentation is now feature complete. If search.cpan.org hasn't updated to show the new version by the time you read this, you can see it on my own server at "http://darrenduncan.net/d/perl/Rosetta-0.15.tar.gz" or "http://darrenduncan.net/d/perl/Rosetta-0.15/lib/SQL/ObjectModel.pm" (temp urls). You should be able to see your own contributions (answers to my questions) in the code. I would appreciate any feedback, if you have the chance. Thank you. -- Darren Duncan From darren at DarrenDuncan.net Sat Jul 12 19:40:40 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] converting objects to/from xml In-Reply-To: References: Message-ID: I have another question, mainly for those of you who have worked with XML in Perl. Given that my SQL::ObjectModel objects are conceptually organized like XML, I would like to make a module which will convert them to XML, and conversely parse an XML document into one of those objects. I would like to use some suitable modules from CPAN which handle most of the work, but I am unsure of which ones to use. I had tried looking at some SAX modules (which seem common), because a callback interface seems to make sense for parsing XML, but I got the impression that this was perhaps too complicated. Most of the SAX examples I saw didn't have much to do with parsing or generating XML. I want object-oriented modules, and pure perl also, for the moment. I am wondering whether I would be better off coding this conversion myself, which I would expect is less than 40-100 lines of code, or whether the robustness or wider compatability brought by a CPAN module would be better. I prefer a simple solution, so I could for example do this: my $firstxml = "..."; my $objectmodel = SQL::ObjectModel::XML->from_xml( $firstxml ); my $secxml = SQL::ObjectModel::XML->to_xml( $objectmodel ); Then "$firstxml eq $secxml" probably returns true. The hypothetical SQL::ObjectModel::XML module would have all the references to the CPAN module or alternately home grown implementation internally. Thanks in advance for any suggestions. -- Darren Duncan From peter at PSDT.com Mon Jul 14 15:48:13 2003 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] converting objects to/from xml In-Reply-To: References: Message-ID: <5.2.1.1.2.20030714133752.00b83d58@shell2.webquarry.com> At 05:40 PM 7/12/2003 -0700, Darren Duncan wrote: >I have another question, mainly for those of you who have worked with >XML in Perl. > >Given that my SQL::ObjectModel objects are conceptually organized like >XML, I would like to make a module which will convert them to XML, and >conversely parse an XML document into one of those objects. > >I would like to use some suitable modules from CPAN which handle most >of the work, but I am unsure of which ones to use. I had tried >looking at some SAX modules (which seem common), because a callback >interface seems to make sense for parsing XML, but I got the >impression that this was perhaps too complicated. Most of the SAX >examples I saw didn't have much to do with parsing or generating >XML. I want object-oriented modules, and pure perl also, for the moment. > >I am wondering whether I would be better off coding this conversion >myself, which I would expect is less than 40-100 lines of code, or >whether the robustness or wider compatability brought by a CPAN module >would be better. > >I prefer a simple solution, so I could for example do this: > >my $firstxml = "..."; > >my $objectmodel = SQL::ObjectModel::XML->from_xml( $firstxml ); > >my $secxml = SQL::ObjectModel::XML->to_xml( $objectmodel ); > >Then "$firstxml eq $secxml" probably returns true. > >The hypothetical SQL::ObjectModel::XML module would have all the >references to the CPAN module or alternately home grown implementation >internally. > >Thanks in advance for any suggestions. -- Darren Duncan O'Reilly's "Perl & XML" is excellent for this kind of thing. From reading Chapter 6, I think you can do: use XML::TreeBuilder; my $tree = XML::TreeBuilder->new; $tree->parse($firstxml); my $objectmodel = SQL::ObjectModel->model_from_tree($tree); Since I don't know what your object model is, I suggest you write the method model_from_tree() to convert the XML::Parser tree to whatever that is. That tree is a mixture of arrayrefs and hashrefs, too long to type an example here. Logically it should map cleanly to your object model. Obviously you can encapsulate all the calls above into a single method of your own if you want. Then for output you have: my $secxml = SQL::ObjectModel->to_tree($objectmodel)->as_XML; That last one is a bit harder because creating the tree requires making this hierarchy of XML::Element objects. There are methods in that class that let you build up such a tree. Disclaimer: I haven't done this. But if I was going to do what you're describing, this is the approach I would try to make work. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From nkuipers at uvic.ca Mon Jul 14 16:02:25 2003 From: nkuipers at uvic.ca (Nathanael Kuipers) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] converting objects to/from xml Message-ID: <3F13262E@wm2.uvic.ca> >O'Reilly's "Perl & XML" is excellent for this kind of thing. From >reading Chapter 6, I think you can do: If you are interested in giving this book a looksee, Darren, I am happy to lend it to you at our next meeting (or before, if you happen to be on campus at any time, since I work there). Cheers, Nathanael From semaphore_2000 at yahoo.com Mon Jul 14 16:52:23 2003 From: semaphore_2000 at yahoo.com (Doug Snead) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] converting objects to/from xml In-Reply-To: Message-ID: <20030714215223.59930.qmail@web40910.mail.yahoo.com> I like to use XML::Simple where I can. Here's a little utility I use to "dump" an xml file, as perl data. =========[ xmldump.pl ]======== #!/usr/bin/perl # Usage: # perl xmldump.pl file:data.xml # perl xmldump.pl http//somesite.com/data.xml # etc. use XML::Simple; use LWP::Simple; use Data::Dumper; my $data = XMLin( &get_page_content( $ARGV[0] ) ); print Dumper($data); sub get_page_content { my ($url) = @_; my ($content) = get($url); defined $content or print STDERR "Can't fetch content from $url\n"; return $content; } 1; ========================== - Doug --- Darren Duncan wrote: > I have another question, mainly for those of you who have > worked with XML in Perl. > > Given that my SQL::ObjectModel objects are conceptually > organized like XML, I would like to make a module which will > convert them to XML, and conversely parse an XML document > into one of those objects. > > I would like to use some suitable modules from CPAN which > handle most of the work, but I am unsure of which ones to > use. I had tried looking at some SAX modules (which seem > common), because a callback interface seems to make sense for > parsing XML, but I got the impression that this was perhaps > too complicated. Most of the SAX examples I saw didn't have > much to do with parsing or generating XML. I want > object-oriented modules, and pure perl also, for the moment. > > I am wondering whether I would be better off coding this > conversion myself, which I would expect is less than 40-100 > lines of code, or whether the robustness or wider > compatability brought by a CPAN module would be better. > > I prefer a simple solution, so I could for example do this: > > my $firstxml = "..."; > > my $objectmodel = SQL::ObjectModel::XML->from_xml( $firstxml > ); > > my $secxml = SQL::ObjectModel::XML->to_xml( $objectmodel ); > > Then "$firstxml eq $secxml" probably returns true. > > The hypothetical SQL::ObjectModel::XML module would have all > the references to the CPAN module or alternately home grown > implementation internally. > > Thanks in advance for any suggestions. -- Darren Duncan __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From darren at DarrenDuncan.net Mon Jul 14 22:08:28 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] converting objects to/from xml In-Reply-To: <3F13262E@wm2.uvic.ca> References: <3F13262E@wm2.uvic.ca> Message-ID: > >O'Reilly's "Perl & XML" is excellent for this kind of thing. From >>reading Chapter 6, I think you can do: > >If you are interested in giving this book a looksee, Darren, I am happy to >lend it to you at our next meeting (or before, if you happen to be on campus >at any time, since I work there). > >Cheers, > >Nathanael Thank you, Nathanael, I would look forward to reading it. I don't plan to be at UVIC anytime soon, although I will be downtown for the rest of this week and next week. Peter and Doug, thank you both for your module suggestions. I gave both XML::TreeBuilder and XML::Simple a look. They both hold promise. That said, given that I now understand SAX a bit better, given the references to it in XML::Simple POD (which uses it), I will probably revisit this as a possible ideal solution, in combination with existing modules which convert XML to SAX events and those converting SAX events to XML. Time will tell. Thank you and have a good day. -- Darren Duncan From Peter at PSDT.com Tue Jul 15 19:14:35 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] Next Meeting Message-ID: <5.2.1.1.2.20030715164716.01b45cb0@shell2.webquarry.com> When shall we meet next week? I shall spur attendance by offering a free copy of the User Friendly book, "Evil Geniuses in a Nutshell," from O'Reilly, to an attendee to be chosen at random. I can report on OSCON 2003 and the 7th Perl Conference. Does anyone have a technical topic they want to present? If not, I can vamp one from the notes for the tutorials I took (PAR, Performance Profiling, Template Toolkit, DocBook). -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Tue Jul 15 21:35:15 2003 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] Next Meeting In-Reply-To: <5.2.1.1.2.20030715164716.01b45cb0@shell2.webquarry.com> References: <5.2.1.1.2.20030715164716.01b45cb0@shell2.webquarry.com> Message-ID: I'm fine with that. abram On Tue, 15 Jul 2003, Peter Scott wrote: > When shall we meet next week? I shall spur attendance by offering a > free copy of the User Friendly book, "Evil Geniuses in a Nutshell," > from O'Reilly, to an attendee to be chosen at random. > > I can report on OSCON 2003 and the 7th Perl Conference. Does anyone > have a technical topic they want to present? If not, I can vamp one > from the notes for the tutorials I took (PAR, Performance Profiling, > Template Toolkit, DocBook). > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From Peter at PSDT.com Tue Jul 15 21:51:24 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] Next Meeting In-Reply-To: References: <5.2.1.1.2.20030715164716.01b45cb0@shell2.webquarry.com> <5.2.1.1.2.20030715164716.01b45cb0@shell2.webquarry.com> Message-ID: <5.2.1.1.2.20030715195103.01b90bc0@shell2.webquarry.com> At 07:35 PM 7/15/2003 -0700, abez wrote: >I'm fine with that. Okay, what day do people want to go with? The usual choices are Monday, Tuesday, or Wednesday. >abram > >On Tue, 15 Jul 2003, Peter Scott wrote: > > > When shall we meet next week? I shall spur attendance by offering a > > free copy of the User Friendly book, "Evil Geniuses in a Nutshell," > > from O'Reilly, to an attendee to be chosen at random. > > > > I can report on OSCON 2003 and the 7th Perl Conference. Does anyone > > have a technical topic they want to present? If not, I can vamp one > > from the notes for the tutorials I took (PAR, Performance Profiling, > > Template Toolkit, DocBook). > > -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Tue Jul 15 22:38:00 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] Next Meeting In-Reply-To: <5.2.1.1.2.20030715164716.01b45cb0@shell2.webquarry.com> References: <5.2.1.1.2.20030715164716.01b45cb0@shell2.webquarry.com> Message-ID: Peter Scott said: >When shall we meet next week? I shall spur attendance by offering a free copy of the User Friendly book, "Evil Geniuses in a Nutshell," from O'Reilly, to an attendee to be chosen at random. > >I can report on OSCON 2003 and the 7th Perl Conference. Does anyone have a technical topic they want to present? If not, I can vamp one from the notes for the tutorials I took (PAR, Performance Profiling, Template Toolkit, DocBook). I can't currently think of any evening conflicts at the moment. However, next week may work better than other weeks for me, as I already know I will be in Victoria every day next week, and won't have to make a special trip from deep cove. As for a discussion topic, one suggestion basically is that if you have something you want to present then do it. I would like it if you at least said a few things about the conferences you went to, even if they aren't the main topic. Regarding a few things that I would like to know how to do, if someone wants to present on these then it could help me, most important items first: - How to compile Perl and/or C/XS extensions for it and/or other OSS stuff you download, rather than just using fully linked binaries. For example, I don't know how install non pure Perl extensions such as gd or libxml that aren't already installed for me. - Making standalone executable binaries out of Perl programs (for multiple platforms) so that I can distribute a program commercially that I made with Perl without exposing the source code. - Using XML or XSLT with Perl. So those are my current suggestions. Thank you. -- Darren Duncan From nkuipers at uvic.ca Wed Jul 16 00:21:35 2003 From: nkuipers at uvic.ca (Nathanael Kuipers) Date: Wed Aug 4 00:11:24 2004 Subject: [VPM] next meeting date Message-ID: <3F14E357@wm2.uvic.ca> I move for Wednesday. From Peter at PSDT.com Wed Jul 16 11:55:29 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] next meeting date In-Reply-To: <3F14E357@wm2.uvic.ca> Message-ID: <5.2.1.1.2.20030716095524.00b33fc8@shell2.webquarry.com> At 10:21 PM 7/15/2003 -0700, Nathanael Kuipers wrote: >I move for Wednesday. Seconded, any objections? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From darren at DarrenDuncan.net Thu Jul 17 01:02:55 2003 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] next meeting date In-Reply-To: <5.2.1.1.2.20030716095524.00b33fc8@shell2.webquarry.com> References: <5.2.1.1.2.20030716095524.00b33fc8@shell2.webquarry.com> Message-ID: >At 10:21 PM 7/15/2003 -0700, Nathanael Kuipers wrote: >>I move for Wednesday. > >Seconded, any objections? I'm not aware of any conflicts currently. Thirded. -- Darren Duncan From Peter at PSDT.com Thu Jul 17 10:43:54 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] next meeting date In-Reply-To: References: <5.2.1.1.2.20030716095524.00b33fc8@shell2.webquarry.com> <5.2.1.1.2.20030716095524.00b33fc8@shell2.webquarry.com> Message-ID: <5.2.1.1.2.20030717084311.00b8dd80@shell2.webquarry.com> At 11:02 PM 7/16/2003 -0700, Darren Duncan wrote: > >At 10:21 PM 7/15/2003 -0700, Nathanael Kuipers wrote: > >>I move for Wednesday. > > > >Seconded, any objections? > >I'm not aware of any conflicts currently. Thirded. -- Darren Duncan Done. What room can we get? Abram? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From abez at abez.ca Thu Jul 17 10:54:30 2003 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] next meeting date In-Reply-To: <5.2.1.1.2.20030717084311.00b8dd80@shell2.webquarry.com> References: <5.2.1.1.2.20030716095524.00b33fc8@shell2.webquarry.com> <5.2.1.1.2.20030716095524.00b33fc8@shell2.webquarry.com> <5.2.1.1.2.20030717084311.00b8dd80@shell2.webquarry.com> Message-ID: I'll try to get one today. abram On Thu, 17 Jul 2003, Peter Scott wrote: > At 11:02 PM 7/16/2003 -0700, Darren Duncan wrote: > > >At 10:21 PM 7/15/2003 -0700, Nathanael Kuipers wrote: > > >>I move for Wednesday. > > > > > >Seconded, any objections? > > > >I'm not aware of any conflicts currently. Thirded. -- Darren Duncan > > Done. What room can we get? Abram? > > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From Peter at PSDT.com Sun Jul 20 01:19:19 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Victoria Perl Mongers meeting Message-ID: <5.2.1.1.2.20030717084159.00b34140@shell2.webquarry.com> Victoria.pm will meet Wednesday, July 23, 7pm, at UVic's CIT120. I will present a review of OSCON and the 7th Perl Conference, then a summary of interesting bits from the tutorials I attended on PAR (Perl Archives), Benchmarking, DocBook, and the Template Toolkit. I have a copy of Iliad's User Friendly O'Reilly book, "Evil Geniuses in a Nutshell" to be given away by fair random selection to an attendee. For those unfamiliar with UVic, see grid B3, centre right. Parking can be found at the top centre of B3. If you don't know how to get to UVic - welcome to Victoria - see . Other topics to be covered as time permits; make requests for anything particular. (Courtesy copy to VLUG members by permission of the list manager. Victoria.pm's home page is .) -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From Peter at PSDT.com Tue Jul 22 02:45:00 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Victoria Perl Mongers meeting Message-ID: <5.2.1.1.2.20030720004439.01c2be78@shell2.webquarry.com> Victoria.pm will meet tomorrow, Wednesday, July 23, 7pm, at UVic's CIT120. I will present a review of OSCON and the 7th Perl Conference, then a summary of interesting bits from the tutorials I attended on PAR (Perl Archives), Benchmarking, DocBook, and the Template Toolkit. I have a copy of Iliad's User Friendly O'Reilly book, "Evil Geniuses in a Nutshell" to be given away by fair random selection to an attendee. For those unfamiliar with UVic, see grid B3, centre right. Parking can be found at the top centre of B3. If you don't know how to get to UVic - welcome to Victoria - see . Other topics to be covered as time permits; make requests for anything particular. (Courtesy copy to VLUG members by permission of the list manager. Victoria.pm's home page is .) -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From Peter at PSDT.com Fri Jul 25 12:41:59 2003 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Linux Lunacy update Message-ID: <5.2.1.1.2.20030725103855.00b87d58@shell2.webquarry.com> My bad - the Linux Lunacy visit to Victoria is Sep 19, not Sep 23. It's on their way back. Emailing Randal now. For those of you that weren't there, we tossed around the idea of inviting the Linux Lunacy crowd to get together at Big Bad John's - sounds like Randal Schwartz's kind of place. Next month's meeting will feature a talk by self on the Template Toolkit - if anyone else has any personal experience with TT feel free to contribute. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ From cconstan at csc.UVic.CA Fri Jul 25 12:47:19 2003 From: cconstan at csc.UVic.CA (Carl B. Constantine) Date: Wed Aug 4 00:11:25 2004 Subject: [VPM] Linux Lunacy update In-Reply-To: <5.2.1.1.2.20030725103855.00b87d58@shell2.webquarry.com> References: <5.2.1.1.2.20030725103855.00b87d58@shell2.webquarry.com> Message-ID: <20030725174719.GH25124@csc> *On Fri Jul 25, 2003 at 10:41:59AM -0700, Peter Scott (Peter@PSDT.com) wrote: > My bad - the Linux Lunacy visit to Victoria is Sep 19, not Sep > 23. It's on their way back. Emailing Randal now. > > For those of you that weren't there, we tossed around the idea of > inviting the Linux Lunacy crowd to get together at Big Bad John's - > sounds like Randal Schwartz's kind of place. Just FYI, VLUG is also inviting the Linux Lunacy crowd out and maybe have a short 1hr meeting that month. Maybe there is something the two of us can get together on? -- Carl B. Constantine University of Victoria Programmer Analyst http://www.csc.uvic.ca UNIX System Administrator Victoria, BC, Canada cconstan@csc.uvic.ca ELW A248, 721-8766