Re: Geography Specific Namespace
Jim Cromie wrote: Terrence Brannon wrote: OK, Ill concede its a bit over-dramatic, but it is an unfortunate historical fact that cant be easily corrected. Id hate to see the same mistake occur in every TLD. Ditto on that. Although its convenient to make the namespaces short as in Geo and Astro, I think it is more confusing in the long run to not name them more descriptively like Geography, Geology, Geometry, Astrology, and Astronomy. Ya, I always thought it weird what kind of stuff is strewn all over Geo::. Its really should be like schooling - you have different departments, Math, History, Geography, Archaeology, Biology, etc. So, that would mean geometry would be a subset of math, and would be Math::Geo:;, not plain old Geo::. Oh well. Perhaps a whole new namespace for geography stuff. How about... GIS::* (Bad idea, GIS is a subset of digitized geography) Geography::* Spatial::* I think most naiive people (e.g. me!) would look under Geo or Geography for this type of thing, so put it there. while Geography:: doesnt yet exist, it seems appropriate that it would. It might even result in a long-term migration. Aran, assuming that you have some non-trivial knowledge, can you elaborate on what GIS is, what youd expect to find in Geography::GIS, and what youre looking to create in relation to it ? Allright, well, Geography is a great namespace to start! I think it would be a good idea to plan out the namespace a little. I would like to propose coming up with a logical structure to the modules contained within Geography::. This would really just be a list of directories and module names and how they relate if at all. It would also describe justifications for choosing one name/structure over another. Then as module authors need geography functionality they can just write a module that fits in with the structure. Of course plans never quite fit the bill in practice, so it would just be a guideline. Comments, questions, moral support? I'd love to do this if its considered ok by the local gods. Aran
Re: Geography Specific Namespace
On Thu, Dec 04, 2003 at 09:26:04AM -0500, Aran Deltac wrote: Allright, well, Geography is a great namespace to start! I think it would be a good idea to plan out the namespace a little. I would like to propose coming up with a logical structure to the modules contained within Geography::. This would really just be a list of directories and module names and how they relate if at all. It would also describe justifications for choosing one name/structure over another. Then as module authors need geography functionality they can just write a module that fits in with the structure. Of course plans never quite fit the bill in practice, so it would just be a guideline. Comments, questions, moral support? A plan sounds like a good idea to me. Mark
Re: when an object gets possessed by an evil spirit
Elizabeth Mattijsen wrote: At 22:38 -0800 12/3/03, Stas Bekman wrote: In fact if it didn't have a problem with destroy (which is possible to workaround in the destroy method by tracking who created the original object), I'd say that this is a Copy-On-Write situation, as long as nobody modifies the object it's perfectly find to have several objects pointing to the same C structs from different threads. If you ever create an object in the parent perl and never modifying it, it'll be much more efficient, than blindly reconstruct all variables. Only when the object wants to be modified, it will be then reconstructed and modified, without affecting any other threads. You don't even need mutexes for this to work. This could be made into yet another handy reusable module, I'm sure Liz will post an announcement in the next few minutes ;) It's already there... ;-) Actually, this is the other thing that Thread::Bless does: do _not_ call DESTROY on objects that have been cloned, only call DESTROY on the original object. So, _if_ you have blessed objects and _if_ you're fine with only DESTROYing on the original object (and have the cloned objects share whatevers C structures they have),.then the only thing you need is add use Thread::Bless to your module's code and Thread::Bless will automagically only have DESTROY methods called on original objects. Right, and should be really called Thread::BlessReadOnly then. Alternately, again _if_ you have blessed objects and you _do_ need to fix objects up after they have been cloned (hence the name fixup for this functionality), you can have a method of your own devise called on each instantiated object automagically after Perl has cloned it. That's incomplete, because you won't call DESTROY on those fixedup/possessed objects. I suppose that you should check whether the user of your module provides the fixup callback and if it does DESTROY all objects (or make it configurable). However, this only works on blessed objects, not on unblessed ones. On the other hand, you could decide to bless your SV to a special class just to get this functionality. You mean double bless? My objects are already blessed, but they don't use bless: sv_setref_pv(ST(0), Example::CLONE, (void*)RETVAL); How about making your module more flexible and in addition to the overriden bless function provide a new_fixup methods, so one can choose to run new_fixup on already blessed/sv_setref_pv'ed object to store a weak copy of it? this can be called from the normal new(). So the only remaining nice-to-have issue is to do COW for a better performance. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: New module Algorithm::Interval2Prefix
On Thursday, December 04, 2003 7:49 PM, [EMAIL PROTECTED] wrote: Lars == Lars Thegler [EMAIL PROTECTED] writes: Lars I totally agree that when generating prefixes from number Lars intervals, this depends squarely on the involved numbers being Lars the same number of digits. But telephone numbers *will* be the Lars same length in the same prefix-area[2]. Lars [2] Since this is the only way the telephony switch can know Lars when the number you are dialling is 'complete'. That's not true in Japan, where the area codes are variable length. The local numbers are fixed, so they can make that decision (when the complete number is dialed) after they have parsed the area code. The way I beleive it works (I lived in Japan from 1988 to 1994, but I beleive this is still true today), is that the length of the area code depends on the 2nd digit. That sounds perfectly reasonable. Any number analysis must depend on some part of the prefix (area code or similar) determining the length of the number. /Lars
Re: Fwd: How to put a path into a module during build time?
On 12/4/2003 12:40 AM, [EMAIL PROTECTED] wrote: Andrew Savige replied to me offlist with a good solution. Taking a hint from lib/Net/Config.pm my $file = __FILE__; my $ref; $file =~ s/Config.pm/libnet.cfg/; That is definately a more elegant solution. I only have two problems with it: 1) I did not think of it. ;) I let myself get boxed in by the question. (Must think outside the box. Time for another read of Conceptual Blockbusting http://www.amazon.com/exec/obidos/ASIN/0738205370/). 2) The purpose of a Mailing List is NOT for people to post questions and get answers. The purpose of a Mailing List is for people to post questions and *everyone* to learn from the answers. --Andrew, please share with all of us next time. =) Regards, Randy. Thank you all for your help! This may be a good question to stick in a FAQ or some documentation somewhere. This solution isn't specific to MakeMaker, and I can't say if MakeMaker is the right place for this question, but the MakeMaker docs were the first place I looked to find this answer, so who knows. Thanks again, -- Josh I.
Re: when an object gets possessed by an evil spirit
At 14:21 -0800 12/4/03, Stas Bekman wrote: Tim Bunce wrote: Umm, post_clone_reconstruct() sounds pretty intuitive to me. Thanks Tim. But it _is_ very long Wouldn't post_clone be indicative enough? Liz
Re: when an object gets possessed by an evil spirit
Elizabeth Mattijsen wrote: At 11:07 -0800 12/4/03, Stas Bekman wrote: Elizabeth Mattijsen wrote: Alternately, again _if_ you have blessed objects and you _do_ need to fix objects up after they have been cloned (hence the name fixup for this functionality), you can have a method of your own devise called on each instantiated object automagically after Perl has cloned it. That's incomplete, because you won't call DESTROY on those fixedup/possessed objects. I suppose that you should check whether the user of your module provides the fixup callback and if it does DESTROY all objects (or make it configurable). Actually, these are both configurable seperately. You can specify whether all objects have DESTROY called on them (including the cloned ones), or only the original ones. Default is only original ones. And you can specify a fixup routine for cloned objects. Of which the default is none. Sounds good. I wonder whether it's safe to assume that if fixup is provided than DESTROY should be called as well for the CLONED objects. However, this only works on blessed objects, not on unblessed ones. On the other hand, you could decide to bless your SV to a special class just to get this functionality. You mean double bless? My objects are already blessed, but they don't use bless: sv_setref_pv(ST(0), Example::CLONE, (void*)RETVAL); Hmmm... didn't realize you can create blessed objects from XS. Moreover, I think that's what 99.9% of XS modules do. bless is really a non-XS module thing, and non-XS modules don't need the reconstruction anyway. But yes, the actual bookkeeping routine could be made available externally, something like: Thread::Bless-register( $object ); would that help? Yes it would. In fact I'd suggest to drop the CORE::bless overriding thing altogether as you may interfere with similar overrides. Just tell users to call this register method from new(), just after they have blessed the object. How about making your module more flexible and in addition to the overriden bless function provide a new_fixup methods, so one can choose to run new_fixup on already blessed/sv_setref_pv'ed object to store a weak copy of it? this can be called from the normal new(). Whether or not fixup routines are called, is determined by package, not by a single object. You _do_ need to register each single object though (which is done automatically if you use bless). Sure, your above: Thread::Bless-register( $object ); is what I was after ;) So the only remaining nice-to-have issue is to do COW for a better performance. You could do that by having the fixup routine set a flag in/for the object that it has been COWed. Then, whenever you need to make changes, you check that flag and when it's set, _then_ you can do the real fixup. That's right. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: BTRIEVE::*
On 12/4/2003 3:50 PM, Tim Bunce wrote: On Thu, Dec 04, 2003 at 11:42:07AM +0100, Steffen Goeldner wrote: Randy W. Sims wrote: Maybe DBMS::BTrieve::??? That looks good! But that's a new namespace. The horse has well and truly bolted on the db module namespace issue. They're all over the place. I think reusing an existing namespace is better than creating yet another one. I don't know (or can't remember) how the BTRIEVE::SAVE module got into the module list, but since it is that's the right place for new BTrieve modules. Tim. I missed that namespace. In fact, browsing http://www.cpan.org/modules/by-module/ I notice that things are /really/ getting out of hand. Maybe we need some CPAN police, volunteers for each of the domains listed at http://www.cpan.org/modules/by-category/, that must explicitly authorize new modules in that domain. Then we can have a Great CPAN Migration effort to herd some of the strays into the proper namespace. If there was just an easy procedure for migrating packages without the compatibility concerns... Randy.
