Re: magic bullet needed for Perl upgrades on Mac OS X
On fredag, feb 28, 2003, at 18:20 Europe/Oslo, Dan Sugalski wrote: At 9:39 PM -0500 2/27/03, Sherm Pendley wrote: On Thursday, February 27, 2003, at 08:01 PM, Daniel Stillwaggon wrote: Any perl application could ship with all of the perls and modules that it requires in its .pkg. Before installing, it would do a quick query and find out which, if any, of these perl modules/versions would need to get installed in addition to the core program, and create a bom accordingly. That's a very interesting idea - I've been thinking along those lines for a future CamelBones installer, which would examine the target system and install a 5.6.*- or 5.8.*-compatible version of CB, as appropriate. It seems like it would bulk up the download, though. For many folks, disk space is plentiful - but bandwidth is not. For the shared CB in /Library/Frameworks, I've been thinking of having the initial download consist of nothing but a tiny installer app, which would examine the system and suggest what packages to download and install. The bigger issue, honestly, is dependent modules. I put together a simple client for the PerlMonks chatterbox ages ago, as a test, and it works pretty well, but it requires a whole host of modules be installed into the system perl, and I dodn't work out a good way to either include them with the program or check to make sure they were there when the program fired up. A way to do packaging would be good, though there are licensing issues there that you don't have to deal with when using system-installed code. What about PAR / pp ? from the man page: pp creates standalone executables from Perl programs, using the compressed packager provided by PAR, and the dependency detection heuristics offered by Module::Scan- Deps. The programs are stored verbatim without compila- tion. Marcus
Re: magic bullet needed for Perl upgrades on Mac OS X
On Friday, February 28, 2003, at 12:42 PM, Daniel Stillwaggon wrote: On Friday, Feb 28, 2003, at 09:20 US/Pacific, Dan Sugalski wrote: A way to do packaging would be good, though there are licensing issues there that you don't have to deal with when using system-installed code. Would the easiest solution be to come up with a list of basic perl modules and a collective petition to Apple for inclusion with the system? I don't imagine that there would be much resistance to a unified plea for inclusion of x given packages (if the number were reasonable, of course). That might help developers know what to expect on a system... I don't think that's the way to go. It doesn't solve the problem, since we don't want to have to wait (potentially years) for Apple to move on things. And it means that Apple's core perl modules would be different from what they are on other systems, that's a headache I don't want to deal with. And Apple can't solve the licensing issue any better than the rest of us can. The perl core already fills this role of letting developers know what to expect on a system. -Ken
Re: no-no?
On Friday, February 28, 2003, at 11:55 PM, Peter N Lewis wrote: Actually, since I've done this, installing 5.8 over your stock perl does not seem to cause any problems in general. Maahahahahah, NOT YET, it hasn't! The possibility exists that you'll be reverted back to 5.6 with an OS upgrade, or that some Apple installer script will break under 5.8 (though they tend to be *extremely* basic scripts), or something along those lines. I did find that various MUD clients would not work because they tried to link to perl and got hit with the binary incompatibility issue. Possibly the same problem would happen if you used CB apps. But other than those MUD programs, I have had no problems with 5.8 as the only installed perl on my system. Actually, I tend to do these kinds of bad idea perl installations from time to time, just because I know I can deal with it if things get hosed, and I like the experimentation. But I wouldn't recommend it to someone that just wants perl as a working tool in good shape. Sounds like you're probably of the same opinion, you don't mind tinkering a little with things if/when they break. -Ken
Re: magic bullet needed for Perl upgrades on Mac OS X
Hi, I'll chime in as an OSX user and perl user. I think you need to define this a little better. Pardon me for a long post of no code or even design, but I think as a direction I need to get this clear to myself. This applies to any distribution of an OS which includes Perl (or any other language) which is not controlled by distribution owner. Putting on my corporate hat and using jargon: What is Apples service level agreement to with users in regard to development tools included with OSX that are NOT directly controlled by Apple? I think this goes beyond perl. Let me just suggest some possible levels of support (Your friend at Apple would really need to make this explicit.) and their implications. A. Minimum Level - 1. Apple makes sure the language engine (compiler/interpreter plus included libraries) functions under the current revision of OSX and any Apple distributed Modules work with that rev level of engine and OS. 2. Whenever Apple releases a new version it makes sure any Modules and programs it has released work with the new version. 3. Apple makes no effort to keep to any particular latest revision. 4. Any user supplied modules are guaranteed nothing across a revision. It is up to users/writers to come out with compatible versions. B. Higher Level 1. A1 and A2 stay same. 2. Apple tries to stay reasonably close to leading edge revision of language engine. 3. Apple attempts to make compatible interfaces so third party apps continue to work with new revision. ok we can stop right here because this is already to much of a burdon on Apple or anyone I think the current situation is A with Apple fine with B2 if possible. so what about a different direction with Engine developers having a responsibility: C. Core + other 1. Apple makes sure the language engine (compiler/interpreter plus included libraries) functions under the current revision of OSX and any Apple distributed Modules work with that rev level of engine and OS. 2. Whenever Apple releases a new version it makes sure any Modules and programs it has released work with the new version. This version shouldn't change in Module compatibility until major OS changes when it could make a jump to new major revision if possible. Small revisions could be applied for security etc, but should not break interface compatibility except for some sev 1 issues (like major security issue or something). 3. The language engine should be designed so it is easy for more than one version (at least two but preferably any number) to co-exist with tool chains able to function totally independently. This is a service level that the language owners need to support. 4. Apple would then bless the means to switch to the different versions. What does this mean? In practice it means that if there were two copies of the language engine exactly as Apple released it, one in the default location and one in another location and independent, then whatever means that would be used to switch would be ok'd by Apple, and all the things that Apple provided that worked with one version would work with the other. That is, the location of the distribution shouldn't matter to Apple. The distribution used should be able to be chosen at the application program level also, but also the default system distribution should be settable via environment, init, Netinfo, or symlink change or whatever. 5. If the other version is switched in Apple has no responsibility... I think option C or something like it would be the way to go. It would mean that language developers could switch in their newer versions and see how they would work and Apple could still depend on a consistent version for its use. It would also allow Apple to upgrade to newer versions while still having an out if someone is depending on an older version. Simply have the new Apple version and the old Apple version available, then Apple can tell users, no problem - switch back as Apple moves forward. This would be really nice for Server folks (speaking as someone who has to plan for 100's of servers from 15K's to Blades.) since they could upgrade on their timetable. OK enough generics. Is this the direction to go? If so I think that there is some effort, but not a huge amount split between apple and perl developers. Perl Developers work 1. Make sure we can have multiple distributions co-exist with no interaction. Much of this is already there. There may be some unresolved issues. The work would be documenting exactly how to do this under Macosx and how to have modules point to where we want. 2. Making sure that all the modules Apple uses (modperl...) work with whatever distribution wanted - responding to discoveries below. Apple's Work 1. Documenting all Perl scripts and modules used with OSX distribution (probably already exists). 2. Creating documented method to switch default distribution locations (e.g. change a
Re: magic bullet needed for Perl upgrades on Mac OS X
I can't resist chiming in to this discussion. The problem of how to have multiple versions of Perl coexist on a system was solved in Perl long ago. It involves storing certain things in directories labeled with the version number, and specifying those directories at compile-time so that they are encoded in the perl binary. This way, no matter which binary you might have symlinked to /usr/bin/perl, it will look in the correct place and find modules which are appropriate for it. Not only can versions easily coexist, but upgrades are relatively painless. Unfortunately, this aspect of compiling Perl was ignored by Apple when they first imported Perl to their system, and there is no versioning in their directory setup. Can this be fixed? Sure, about a dozen ways, and I imagine Apple is going to fix it when they give us perl5.8.0 . In fact, a fix was proposed last October by Fred Sanchez, former lead of the BSD group at Apple, and accepted into the perl sources: http://archive.develooper.com/[EMAIL PROTECTED]/msg06039.html A message on the perl5-porters list at the time indicated that Fred also planned to explain to Apple how they can implement this while maintaining backward-compatibility: http://archive.develooper.com/[EMAIL PROTECTED]/msg87083.html -- Dave
Re: dmg of perl 5.8.0 on Mac OS X
On Fri, Feb 28, 2003 at 03:28:58PM -0600, Joe Davison wrote: On Thu, 6 Feb 2003, Nathan Torkington wrote: A .pkg is specifically just a distribution of files to be installed using the Installer program. You can add pre- and post- actions to a package (which I should have done for Perl--update your .cshrc to add /usr/local/perl5-8 to the path). The prompting for admin password, confirming acceptance of the license, selecting the drive to install on ... all that's done by the Installer program in response to instructions in the .pkg file. I used .pkg instead of .dmg because Perl's location is hard-coded in the binary, so it *has* to go into /usr/local/perl5-8. If I'd just given you a filesystem, you could have copied it anywhere and then filled my mailbox with you suck, Torkington! email :-) Actually, I'm just as happy you didn't update my .cshrc, since I don't use csh/tcsh -- I use zsh. And, a quick step back to the actual subject... :-) I've looked through the archives of the list, and I've seen a *ton* of discussion about what's a .pkg or .dmg and such side issues, but I've not seen much about people's actual reactions to the package and its installation itself. I mean, I trust gnat and all, but do people actually have this up and running well? :-) dha, veteran of the installation wars -- David H. Adler - [EMAIL PROTECTED] - http://www.panix.com/~dha/ The Inferno video is really in colour.
Re: favorite xml parser?
On Saturday, March 1, 2003, at 03:00 PM, stephen rouse wrote: with XML::DOM and XML::Parser (to try the SAX parsing method). i was wondering: is one way preferred over the other for some reason, or is it pretty much just a matter of preference? There is no golden rule - you need to decide which parsing technique is more suitable for the application you're writing on a case-by-case basis. XML::DOM builds up a DOM tree that represents an entire document. XML::Parser scans from top to bottom, reporting the nodes it finds in the document in the order they're found. If processing nodes sequentially is appropriate for your app's needs, you can save a *lot* of memory by using XML::Parser instead of XML::DOM. On the other hand, if you need random access to nodes within the document, you'll need to build up some sort of structure to hold them all anyway - in that case, you can save yourself a *lot* of work by letting XML::DOM to that work for you. sherm-- Welcome to Rivendell, Mr. Anderson.
Re: favorite xml parser?
On Saturday, March 1, 2003, at 03:00 PM, stephen rouse wrote: with XML::DOM and XML::Parser (to try the SAX parsing method). i was wondering: is one way preferred over the other for some reason, or is it pretty much just a matter of preference? Preference and application. Personally, I'm partial to XML::LibXML and related (Matt Sergeant's) modules, especially if you're planning on doing any XSLT processing (XML::LibXSLT). These require the gnome libxml (http://xmlsoft.org) C libs, though. If you're new to XML processing, XML::Simple::LibXML is a bare-bones LibXML wrapper that will get you up and running quickly. - Dan (Sherm, the Rivendell/Mr. Anderson sig is terrific.)
Re: favorite xml parser?
If you're new to XML processing, XML::Simple::LibXML is a bare-bones LibXML wrapper that will get you up and running quickly. Sorry, make that XML::SimpleObject(::LibXML).
Re: [Really OT] More Terminal/Finder cooperation
To reveal files in the Finder, the nifty open(1) command is faster than osascript and supports multiple files easily. Use a shell script or shell function such as the following. I called it rif and placed it under the ~/bin/`uname` directory to avoid the script being in the command path on other systems after rsyncing of binary directories. #!/bin/sh if [ -z $1 ]; then echo usage: `basename $0` files exit 1 fi open -a Finder $
Re: magic bullet needed for Perl upgrades on Mac OS X
Good afternoon, On 28/2/03 at 12:39 PM, Peter N Lewis [EMAIL PROTECTED] wrote: In that case, don't even think about trying to build a smaller bundle - people in general will not even blink before 10MB these days, and in general wont worry about it until it is *much* bigger than that. I disagree. For me, I don't blink if it's under 2MB. But anythinbg over that I make a conscious decision about whether I really want it. I find file size to be a very important factor in deciding whether to download. Not everyone has even 56K connections (much less broadband) if they don't live in/near a city. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia
