Thread: [Camelbones-devel] CamelBones: Cross-perl portability - comments?
Brought to you by:
shermpendley
From: Sherm P. <sh...@do...> - 2004-01-31 19:17:08
|
Prior to Panther, the difficulties of shipping and supporting an application that works with various versions of Perl was the topic of much conversation, but it was mostly just theorizing, as Apple had only shipped a single Perl configuration to that point. With Panther, it's no longer theoretical, and the recent 0.2.1 release of CB attempts to address those concerns in the following ways: 1. The framework itself requires the use of an installer, which detects one of the two standard Perl configurations as shipped by Apple, and installs a framework to match it. I understand that drag-and-drop is the preferred means of installation for applications, and once the framework is installed, CB apps can in fact be installed that way. However, there is ample precedent for using an installer for supporting libraries - QuickTime, CarbonLib, MRJ, etc. all use an installer. 2. Version- and architecture-specific directories that are appropriate for the perl an app is running under are added to the module search path. Thus, an app developer who wants to bundle an XS module with his app can now do so, by including multiple copies of the module, each one compiled for the perl environments he wishes to support. Neither of the above attempts to address the case of an advanced user who has installed a custom Perl. Such a user will need to build a matching framework from source - something that's been simplified a great deal by the use of 'make' instead of PB/Xcode to build the framework. The same applies to XS modules; while an app developer can bundle XS modules for as many Perl configurations he knows about and wishes to provide support for, there still remains the possibility of the app being run under an unsupported version or architecture. In that case, having failed to find the needed module in the app bundle, Perl will continue to search in the normal CPAN directory. So, all that advanced users will need to do is install the required module using the standard procedure. In summary, I've tried to find a reasonable compromise. While an installer is required for the supporting framework, that's well within the realm of the traditional "Mac experience," and once it's done, applications can be shipped and installed in any way the app developer wants. Modules, both "pure Perl" and XS, can be bundled with an app so that a non-technical end user with a "factory" Perl has a hassle-free experience. Advanced usage with a nonstandard Perl is somewhat more complex but not (in my opinion) unreasonably so, especially in comparison to the difficulty of installing such a Perl in the first place. Comments anyone? Do y'all think this compromise is workable for you and your users? sherm-- |
From: Pedro M. C. <me...@is...> - 2004-01-31 20:18:54
Attachments:
smime.p7s
|
Hi, first, let me say that I was extremelly happy to see a new version of=20 camelbones :) regarding this problem, I think that having the *option* of making a=20 totally standalone application (that includes the libperl and all=20 required modules) would be nice to have. Yes, I understand that this would make downloads a bit bigger, but=20 really, how much bigger? libperl.dylib is 1.1Mb, and even with another=20= 900k of required perl modules, it's 2Mb,*unzipped*. I got around 900k=20 zipped... So it would not be a huge download to have the option of having your=20 libperl.dylib and required modules along with the App... That way,=20 install is just drag and drop. Maybe even using PAR to make it easier=20 to pack all the required modules together. That's my .1=80, Best regards, On 31/jan/2004, at 19:17, Sherm Pendley wrote: > Prior to Panther, the difficulties of shipping and supporting an=20 > application that works with various versions of Perl was the topic of=20= > much conversation, but it was mostly just theorizing, as Apple had=20 > only shipped a single Perl configuration to that point. With Panther,=20= > it's no longer theoretical, and the recent 0.2.1 release of CB=20 > attempts to address those concerns in the following ways: > > 1. The framework itself requires the use of an installer, which=20 > detects one of the two standard Perl configurations as shipped by=20 > Apple, and installs a framework to match it. I understand that=20 > drag-and-drop is the preferred means of installation for applications,=20= > and once the framework is installed, CB apps can in fact be installed=20= > that way. However, there is ample precedent for using an installer for=20= > supporting libraries - QuickTime, CarbonLib, MRJ, etc. all use an=20 > installer. > > 2. Version- and architecture-specific directories that are appropriate=20= > for the perl an app is running under are added to the module search=20 > path. Thus, an app developer who wants to bundle an XS module with his=20= > app can now do so, by including multiple copies of the module, each=20 > one compiled for the perl environments he wishes to support. > > Neither of the above attempts to address the case of an advanced user=20= > who has installed a custom Perl. Such a user will need to build a=20 > matching framework from source - something that's been simplified a=20 > great deal by the use of 'make' instead of PB/Xcode to build the=20 > framework. > > The same applies to XS modules; while an app developer can bundle XS=20= > modules for as many Perl configurations he knows about and wishes to=20= > provide support for, there still remains the possibility of the app=20 > being run under an unsupported version or architecture. In that case,=20= > having failed to find the needed module in the app bundle, Perl will=20= > continue to search in the normal CPAN directory. So, all that advanced=20= > users will need to do is install the required module using the=20 > standard procedure. > > In summary, I've tried to find a reasonable compromise. While an=20 > installer is required for the supporting framework, that's well within=20= > the realm of the traditional "Mac experience," and once it's done,=20 > applications can be shipped and installed in any way the app developer=20= > wants. Modules, both "pure Perl" and XS, can be bundled with an app so=20= > that a non-technical end user with a "factory" Perl has a hassle-free=20= > experience. Advanced usage with a nonstandard Perl is somewhat more=20 > complex but not (in my opinion) unreasonably so, especially in=20 > comparison to the difficulty of installing such a Perl in the first=20 > place. > > Comments anyone? Do y'all think this compromise is workable for you=20 > and your users? > > sherm-- > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Camelbones-devel mailing list > Cam...@li... > https://lists.sourceforge.net/lists/listinfo/camelbones-devel > -- Pedro Melo Cunha - <me...@is...> Novis Telecom, S.A. - Dir. Rede - ISP <http://www.novis.pt/> Edif=EDcio Novis - Estrada da Outurela, 118 - 2795-606 Carnaxide tel: +351 21 0104340 - fax: +351 21 0104301 |
From: Sherm P. <sh...@do...> - 2004-02-02 18:43:55
|
On Jan 31, 2004, at 3:18 PM, Pedro Melo Cunha wrote: > regarding this problem, I think that having the *option* of making a > totally standalone application (that includes the libperl and all > required modules) would be nice to have. I agree that would be a nice option, but there are some practical issues that would need to be addressed to make it work. One is, which libperl? The application would have to bundle a copy of the CB framework that's been linked against a specific version of libperl - and then copy the *same* libperl into the .app bundle. That could be accomplished with a "copy files" build phase in PB/Xcode. But, the file(s) to copy would be different, depending on what version of Perl needed to be bundled. So some manual adjustment would often be required. That sort of thing can be difficult to support - even experienced developers had trouble adjusting the CB-0.3.0-pre to get it to build on their own systems, for example. One way to work around the "which libperl" question would be to bundle a complete copy of the latest Perl with the CB developer's package. But that would be a significant increase in the size of that package; a tarball of /System/Library/Perl on my Panther machine is about 7.5MB, whereas the current release tarball is 1.6MB. > Yes, I understand that this would make downloads a bit bigger, but > really, how much bigger? libperl.dylib is 1.1Mb, and even with another > 900k of required perl modules, it's 2Mb,*unzipped*. I got around 900k > zipped... You have to also consider the size of CamelBones apps. RendezvousBrowser is 100KB. ShuX is perhaps a better example, as it has an application icon, two file icons, and a couple of tiff files for toolbar buttons; even with all that, it's still only 248KB. Thilo Planz' PerlPad, includes an extensive set of HTML help files, yet it still weighs in at a mere 376KB. At the moment, the "tiny app" crown is held by the web browser app that Tom Insam posted about yesterday - which is insanely cool, by the way. The compiled app is 36KB, and 12KB zipped. That's worth repeating - A fully functional (although admittedly very basic) web browser in a **twelve kilobyte** download. The sizes you speak of - 2MB unzipped, 900KB zipped - are fairly small in absolute terms. But relatively speaking, in comparison to the size of CB apps, they're huge. A 2MB addition to Mail.app (24MB) or Safari.app (11.2MB) would be insignificant; such an addition to a CB app can easily multiply its size by a factor of ten or more. > That way, install is just drag and drop. After the one-time install of the supporting framework, app install *is* just drag and drop. sherm-- |
From: Pedro M. C. <me...@is...> - 2004-02-02 19:15:46
Attachments:
smime.p7s
|
Hi, On 2/fev/2004, at 18:43, Sherm Pendley wrote: > On Jan 31, 2004, at 3:18 PM, Pedro Melo Cunha wrote: > >> regarding this problem, I think that having the *option* of making a=20= >> totally standalone application (that includes the libperl and all=20 >> required modules) would be nice to have. > > I agree that would be a nice option, but there are some practical=20 > issues that would need to be addressed to make it work. > > One is, which libperl? The application would have to bundle a copy of=20= > the CB framework that's been linked against a specific version of=20 > libperl - and then copy the *same* libperl into the .app bundle. > > That could be accomplished with a "copy files" build phase in=20 > PB/Xcode. But, the file(s) to copy would be different, depending on=20 > what version of Perl needed to be bundled. So some manual adjustment=20= > would often be required. That sort of thing can be difficult to=20 > support - even experienced developers had trouble adjusting the=20 > CB-0.3.0-pre to get it to build on their own systems, for example. > > One way to work around the "which libperl" question would be to bundle=20= > a complete copy of the latest Perl with the CB developer's package.=20 > But that would be a significant increase in the size of that package;=20= > a tarball of /System/Library/Perl on my Panther machine is about=20 > 7.5MB, whereas the current release tarball is 1.6MB. This is my prefered option. First, you don't need the full perl distro,=20= just libperl.dylib and the core modules you are going to use. Second, It's a trade-off, the decision being made by the programmer. I=20= prefer to download x Meg more (zipped even) but having the assurance=20 that is't just drag-and-drop install... As I said this is optional... >> Yes, I understand that this would make downloads a bit bigger, but=20 >> really, how much bigger? libperl.dylib is 1.1Mb, and even with=20 >> another 900k of required perl modules, it's 2Mb,*unzipped*. I got=20 >> around 900k zipped... > > You have to also consider the size of CamelBones apps.=20 > RendezvousBrowser is 100KB. ShuX is perhaps a better example, as it=20 > has an application icon, two file icons, and a couple of tiff files=20 > for toolbar buttons; even with all that, it's still only 248KB. Thilo=20= > Planz' PerlPad, includes an extensive set of HTML help files, yet it=20= > still weighs in at a mere 376KB. Yes, but they all lack drag-and-drop-install's, and that's something=20 that I think some people are wiling to pay with a large download. As=20 you said, making camelbones 0.3-pre was dificult to even experienced=20 perl programmers... Imagine doing it with end-users... There are alternatives: you could put the libperl and core modules in=20 the Runtime... That way, we only need to download it once, and all the=20= camelbones app's can share it. > At the moment, the "tiny app" crown is held by the web browser app=20 > that Tom Insam posted about yesterday - which is insanely cool, by the=20= > way. The compiled app is 36KB, and 12KB zipped. That's worth repeating=20= > - A fully functional (although admittedly very basic) web browser in a=20= > **twelve kilobyte** download. Yep, way cool :) > The sizes you speak of - 2MB unzipped, 900KB zipped - are fairly small=20= > in absolute terms. But relatively speaking, in comparison to the size=20= > of CB apps, they're huge. A 2MB addition to Mail.app (24MB) or=20 > Safari.app (11.2MB) would be insignificant; such an addition to a CB=20= > app can easily multiply its size by a factor of ten or more. Well, but the "small" size does not include the runtime. It uses the=20 perl already installed... I can live with that for=20 "programmer-oriented" apps... But for totally end-user experience, I think that unless we can make=20 camelbones "smart" enough to install with wichever perl is running,=20 it's very dificult to distribute CamelBones in the large. > After the one-time install of the supporting framework, app install=20 > *is* just drag and drop. I have a custom perl installed. Will it work there? There are a lot of=20= things that can go wrong, if people install a diferent perl. What about upgrades? If Apple releases a new operating system, with a=20 new perl, will it work. Don't get me wrong, I would prefer a small download that just works.=20 But I think that it would be GREAT to have a framework-version with=20 perl built-in. At least, that's my personal opinion. Thanks in advance, -- Pedro Melo Cunha - <me...@is...> Novis Telecom, S.A. - Dir. Rede - ISP <http://www.novis.pt/> Edif=EDcio Novis - Estrada da Outurela, 118 - 2795-606 Carnaxide tel: +351 21 0104340 - fax: +351 21 0104301 |
From: Sherm P. <sh...@do...> - 2004-02-02 21:35:56
|
On Feb 2, 2004, at 2:15 PM, Pedro Melo Cunha wrote: > On 2/fev/2004, at 18:43, Sherm Pendley wrote: >> >> One way to work around the "which libperl" question would be to >> bundle a complete copy of the latest Perl with the CB developer's >> package. But that would be a significant increase in the size of that >> package; a tarball of /System/Library/Perl on my Panther machine is >> about 7.5MB, whereas the current release tarball is 1.6MB. > > This is my prefered option. First, you don't need the full perl > distro, just libperl.dylib and the core modules you are going to use. That's all that end user applications would need. The developer package would need to include the Full Monty. > Yes, but they all lack drag-and-drop-install's On the contrary - all of the apps I mention can be installed via drag-n-drop. In fact, PerlPad *is* distributed and installed that way. Only the runtime requires an installer - and that's only required because it's simpler than making end-users figure out whether they need the Jaguar or Panther version of the framework, log in as an admin user, and drop it in /Library/Frameworks/. > making camelbones 0.3-pre was dificult to even experienced perl > programmers... Building it *from source* was difficult. That has nothing at all to do with end-users. It simply illustrates how difficult it is to support a project template that needs to be heavily customized for individual developers. An application that attempted to embed libperl and the modules it needs would definitely have to be customized with at *least* the addition of several "Copy Files" build phases. If a Perl other than the one supplied by Apple is to be embedded, several compiler and linker options would need to be changed as well. In other words, while its technically possible, it would result in endless streams of email from developers needing help with ProjectBuilder/Xcode settings. Are *you* willing to take on that support burden? > Imagine doing it with end-users... What? I did NOT propose that end-users should have to build the framework from source. > There are alternatives: you could put the libperl and core modules in > the Runtime... That way, we only need to download it once, and all the > camelbones app's can share it. Except for having libperl in the runtime, what you're describing is the current situation. You install the runtime once, and all CB apps share it. Putting libperl in the runtime would do *nothing* to help advanced users who have correctly installed a custom Perl. The situation would be pretty much the same as it is now; CB apps would continue to use the Perl found in the framework, and if they wanted them to use their custom Perl instead, they'd need to build the framework from source. In short, including libperl and core modules would increase the runtime download for everyone from 140KB to over 7.5MB, but the only people who would benefit from the increased bulk are users who believe themselves to be "advanced," but are in reality too stupid to install Perl in /opt instead of breaking their system Perl. > Well, but the "small" size does not include the runtime. It uses the > perl already installed... I can live with that for > "programmer-oriented" apps... > > But for totally end-user experience, I think that unless we can make > camelbones "smart" enough to install with wichever perl is running, The runtime installer *IS* smart enough to install a runtime that matches whichever standard Perl is running. As far as making the framework capable of loading any arbitrary libperl - it's not going to happen. Better programmers than me have tried to do that, and failed; the binary interface is too much of a moving target. > I have a custom perl installed. You have a non-standard system. Nothing I do will *ever* give you a simple, drag-and-drop experience. That's the price you pay for customizing your system. Building a framework that matches your customized Perl is as simple as such things get; you edit three lines of "GNUmakefile.perl", and run "make; sudo make install". Yes, that might be imposing for a non-technical end user, but such a user isn't likely to have installed a custom Perl in the first place. > What about upgrades? If Apple releases a new operating system, with a > new perl, will it work. That's precisely what just happened. Apple *did* release a new OS, with a new Perl, and once the updated runtime is installed, apps *do* continue to work. The delay in releasing a Panther-compatible framework was due to health problems, not technical issues. In fact, Apple bent over backwards, giving me free access to Panther beta releases, to help me get it done. If it weren't for a two-week hospital stay, and several months of related recovery, I would have been easily able to release a matching CB runtime on the day of the Panther release. sherm-- |
From: Pedro M. C. <me...@is...> - 2004-02-03 10:20:17
Attachments:
smime.p7s
|
Hi, Ok, I see your point. Going back to the your original mail, having a=20 package to install the Runtime is the best way I see of distributing=20 CamelBones framework. My original ideia of bundling a tested and known-to-be good version of=20= perl with CamelBones was just to try to remove the system-perl=20 dependencies from a camelbones app. But your explanation of the=20 framework instalation is good enough for me. Thanks On 2/fev/2004, at 21:35, Sherm Pendley wrote: > On Feb 2, 2004, at 2:15 PM, Pedro Melo Cunha wrote: > >> On 2/fev/2004, at 18:43, Sherm Pendley wrote: >>> >>> One way to work around the "which libperl" question would be to=20 >>> bundle a complete copy of the latest Perl with the CB developer's=20 >>> package. But that would be a significant increase in the size of=20 >>> that package; a tarball of /System/Library/Perl on my Panther=20 >>> machine is about 7.5MB, whereas the current release tarball is=20 >>> 1.6MB. >> >> This is my prefered option. First, you don't need the full perl=20 >> distro, just libperl.dylib and the core modules you are going to use. > > That's all that end user applications would need. The developer=20 > package would need to include the Full Monty. > >> Yes, but they all lack drag-and-drop-install's > > On the contrary - all of the apps I mention can be installed via=20 > drag-n-drop. In fact, PerlPad *is* distributed and installed that way. > > Only the runtime requires an installer - and that's only required=20 > because it's simpler than making end-users figure out whether they=20 > need the Jaguar or Panther version of the framework, log in as an=20 > admin user, and drop it in /Library/Frameworks/. > >> making camelbones 0.3-pre was dificult to even experienced perl=20 >> programmers... > > Building it *from source* was difficult. That has nothing at all to do=20= > with end-users. It simply illustrates how difficult it is to support a=20= > project template that needs to be heavily customized for individual=20 > developers. > > An application that attempted to embed libperl and the modules it=20 > needs would definitely have to be customized with at *least* the=20 > addition of several "Copy Files" build phases. If a Perl other than=20 > the one supplied by Apple is to be embedded, several compiler and=20 > linker options would need to be changed as well. > > In other words, while its technically possible, it would result in=20 > endless streams of email from developers needing help with=20 > ProjectBuilder/Xcode settings. Are *you* willing to take on that=20 > support burden? > >> Imagine doing it with end-users... > > What? I did NOT propose that end-users should have to build the=20 > framework from source. > >> There are alternatives: you could put the libperl and core modules in=20= >> the Runtime... That way, we only need to download it once, and all=20 >> the camelbones app's can share it. > > Except for having libperl in the runtime, what you're describing is=20 > the current situation. You install the runtime once, and all CB apps=20= > share it. > > Putting libperl in the runtime would do *nothing* to help advanced=20 > users who have correctly installed a custom Perl. The situation would=20= > be pretty much the same as it is now; CB apps would continue to use=20 > the Perl found in the framework, and if they wanted them to use their=20= > custom Perl instead, they'd need to build the framework from source. > > In short, including libperl and core modules would increase the=20 > runtime download for everyone from 140KB to over 7.5MB, but the only=20= > people who would benefit from the increased bulk are users who believe=20= > themselves to be "advanced," but are in reality too stupid to install=20= > Perl in /opt instead of breaking their system Perl. > >> Well, but the "small" size does not include the runtime. It uses the=20= >> perl already installed... I can live with that for=20 >> "programmer-oriented" apps... >> >> But for totally end-user experience, I think that unless we can make=20= >> camelbones "smart" enough to install with wichever perl is running, > > The runtime installer *IS* smart enough to install a runtime that=20 > matches whichever standard Perl is running. > > As far as making the framework capable of loading any arbitrary=20 > libperl - it's not going to happen. Better programmers than me have=20 > tried to do that, and failed; the binary interface is too much of a=20 > moving target. > >> I have a custom perl installed. > > You have a non-standard system. Nothing I do will *ever* give you a=20 > simple, drag-and-drop experience. That's the price you pay for=20 > customizing your system. > > Building a framework that matches your customized Perl is as simple as=20= > such things get; you edit three lines of "GNUmakefile.perl", and run=20= > "make; sudo make install". Yes, that might be imposing for a=20 > non-technical end user, but such a user isn't likely to have installed=20= > a custom Perl in the first place. > >> What about upgrades? If Apple releases a new operating system, with a=20= >> new perl, will it work. > > That's precisely what just happened. Apple *did* release a new OS,=20 > with a new Perl, and once the updated runtime is installed, apps *do*=20= > continue to work. > > The delay in releasing a Panther-compatible framework was due to=20 > health problems, not technical issues. In fact, Apple bent over=20 > backwards, giving me free access to Panther beta releases, to help me=20= > get it done. If it weren't for a two-week hospital stay, and several=20= > months of related recovery, I would have been easily able to release a=20= > matching CB runtime on the day of the Panther release. > > sherm-- > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Camelbones-devel mailing list > Cam...@li... > https://lists.sourceforge.net/lists/listinfo/camelbones-devel > -- Pedro Melo Cunha - <me...@is...> Novis Telecom, S.A. - Dir. Rede - ISP <http://www.novis.pt/> Edif=EDcio Novis - Estrada da Outurela, 118 - 2795-606 Carnaxide tel: +351 21 0104340 - fax: +351 21 0104301 |
From: Tom I. <to...@je...> - 2004-02-02 22:46:26
|
On Feb 2, 2004, at 18:43, Sherm Pendley wrote: > At the moment, the "tiny app" crown is held by the web browser app > that Tom Insam posted about yesterday - which is insanely cool, by the > way. The compiled app is 36KB, and 12KB zipped. That's worth repeating > - A fully functional (although admittedly very basic) web browser in a > **twelve kilobyte** download. > awww, thank you. I think it's worth mentioning that I'll never produce a serious commercial app like this, mostly because I can prise the lid off any camelbones app and look at all the source code. There are (complicated) ways round this, but I don't see a way of selling serious software on this toolkit. On the other hand, I wrote a web browser in 4 hours. I'm about another 4 hours away from it being good enough that I'll use it as my primary browser, it already has some serious wins over safari for me, like the search keywords, and state saving, when it does downloading and some simple bookmark handling, I'll switch.. I am finding it very hard to debug things, I get crashes occasionally, and my only recourse is to randomly change things till it stops. But, seriously, 0.2.1. That's a small number. Question - when is setting OBJC_EXPORT needed? I find I can drop it from some functions, and not others. And is there a list of the letters for various types? I get that '@' is ID, there's 'i', 'v', that sort of thing - is there a definitive list? Still _utterly_ cool, though. And I'm completely behind the 'If you've installed a different perl, you're hosed' philosophy. Why are people installing different perls anyway? I can understand wanting to replace the awfulness of 5.6.0, but 5.8.1 is a _good_ _perl_. .tom |
From: Sherm P. <sh...@do...> - 2004-02-02 23:36:25
|
On Feb 2, 2004, at 5:46 PM, Tom Insam wrote: > Question - when is setting OBJC_EXPORT needed? I find I can drop it > from some functions, and not others. The default is object ("@") parameters and return values. If something other than that is needed - i.e. int, float, char*, whatever - a method signature is needed. Don't get too attached to OBJC_EXPORT, by the way - I'm trying to figure out a more elegant way to deal with that information through method attributes. > And is there a list of the letters for various types? I get that '@' > is ID, there's 'i', 'v', that sort of thing - is there a definitive > list? It's based on Objective-C's type encoding. Supported types for Perl methods are: c/C - signed/unsigned char i/I - signed/unsigned int s/S - signed/unsigned short l/L - signed/unsigned long v - void (for return types) * - char* (C strings) @ - objects ^ - void* Partial support for the following types exists; they can be passed to and returned from Objective-C methods, but Perl methods can't take them as arguments or return them: : - selector { - struct The following are currently unsupported both ways: q/Q - long long/unsigned long long # - class [ - array ( - union b - bit field (Note to $self - write this up in a web page.) > I'm completely behind the 'If you've installed a different perl, > you're hosed' philosophy. Not even hosed, just slightly inconvenienced. Note that it's libperl.dylib that matters here, not /usr/bin/perl. If you've overwritten the factory libperl, you asked for trouble by doing that, and you'll get it. ;-) If you haven't overwritten the factory libperl, CB apps will be happy to continue using it. If you want CB apps to use your custom Perl, you'll need to build a CB framework that uses it. That's a simple matter of changing three lines in a make file, and typing "make; sudo make install". One has to wonder how anyone who sees that as a major challenge managed to install a custom Perl to begin with... > Why are people installing different perls anyway? Most people, when it comes to it, can't give a logical answer to that. They want "the latest Perl" simply because it's the latest - even if they're at the "hello world" stage of learning the language. They'll mumble something about the newer version being "better" - but they can't tell you precisely *why* it's better, or how the supposed improvements will affect their applications. There *are* some people out there who legitimately *need* a newer version. Their apps tickle a bug in the shipping version, or they need to do some major regression testing against older Perls, or whatever. But they're in the minority. sherm-- |
From: Terje B. <li...@po...> - 2004-02-01 19:09:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sherm Pendley <sh...@do...> wrote: >having failed to find the needed module in the app bundle, Perl will >continue to search in the normal CPAN directory. So perhaps a strategic goal in the effort to make Perl apps more Mac-friend= ly would be to make a pretty GUI app front-ending CPAN(plus).pm? :-) - --=20 "It's not the mere technical details of inserting the live round into the chamber, pointing the weapon at one's foot, and pulling the trigger, but rather, it's about the advisability of doing that in the first place." -- "Alan J. Flavell" on ciwah -----BEGIN PGP SIGNATURE----- Version: PGP SDK 3.0.3 iQA/AwUBQB1OpKPyPrIkdfXsEQK79gCePrA7LHkwzRUmmIKkyJePvnvMR9IAoMW5 YrM9NCPBT0fp0i7NM8g7dNCR =3DtWIT -----END PGP SIGNATURE----- |
From: Sherm P. <sh...@do...> - 2004-02-02 18:58:03
|
On Feb 1, 2004, at 2:08 PM, Terje Bless wrote: > So perhaps a strategic goal in the effort to make Perl apps more > Mac-friendly > would be to make a pretty GUI app front-ending CPAN(plus).pm? :-) That would *definitely* be nice to have, and it's on my to-do list. On the other paw, it's near the bottom of that list, because the difficulties that people have installing CPAN modules have nothing to do with the fact that the CPAN shell is terminal-based. A GUI app would make the process prettier, but it wouldn't make it any easier or less trouble-prone. sherm-- |