Re: [way OT] ... Intel? Maybe not.
How does directing this sort of thing at someone who worked on a tiny little bit of Tiger, which you guys seem to use personally, help anything at all? Unless you have complaints about perl on Tiger, these comments seem inappropriate. If anything, I'd be thankful to have an engineer who works on perl for Apple on this list. Personally, Tiger works great for me, and I'd like to thank everyone involved in working on it. Ian On Jun 8, 2005, at 3:34 PM, Joseph Alotta wrote: On Jun 8, 2005, at 3:27 PM, John Delacour wrote: At 10:36 am -0700 8/6/05, Edward Moy wrote: We hope that the additional price our customers pay is justified by the fit-n-finish that we put into the systems. The beachballs in Tiger are terrific! If I'd paid the full price for the upgrade I'd be seriously considering demanding my money back. JD I am hating Tiger, it is so slow many places, I will reload Panther this weekend. The spotlight thing is nice but the performance overhead is unacceptable.
Re: CamelBones on Intel? Maybe not.
Is there any reason you would NEED to compile it fat? Does anybody expect that the same partition will boot on both x386 and PowerPC macs? Ian On Jun 7, 2005, at 5:32 AM, Sherm Pendley wrote: On Jun 7, 2005, at 5:19 AM, Gisle Aas wrote: Why would it be painful to compile perl and its modules as a fat binaries? *If* Apple compiles a fat perl ... and *if* that fat perl doesn't require me to buy an Intel/Mac with money I don't have ... and *if* that fat perl is configured properly to produce fat XS modules ... and *if* the ffcall library that CamelBones uses is updated to support Darwin/x86 calling conventions ...
Re: CamelBones on Intel? Maybe not.
On Jun 7, 2005, at 11:51 AM, Joseph Alotta wrote: I used to be a NeXt developer. This announcement is very reminiscent of the NeXt announcement to stop making those little black boxes and bring NeXt OS on Intel chips. We had just bought a ton of hardware and they demo this clunky 386 PC. First of all, it looked nasty. We were used to that elegant design. Secondly, it kept crashing. It destroyed the culture. It was like putting Haydn into the juke box at a disco. Everyone went home. The vice president of our division, who bet his career on NeXt, resigned and NeXt languished for years. It is the same scenario playing out again. Will Steve Jobs never learn? Did NeXT produce their own boxes, or did they allow installs on any PC with supported hardware. I believe that is a key difference. Apple boxes will be exactly the same as they would have been, except they will have a different CPU. You still won't be able to install OS X on a commodity PC without jumping through a lot of hoops. I think the only way that you look at it is that if IBM couldn't or wouldn't deliver the processors Apple needed at a reasonable price, what else could Apple do? Ian
Re: CamelBones on Intel? Maybe not.
On Jun 7, 2005, at 12:57 PM, Wiggins d'Anconia wrote: Ian Ragsdale wrote: On Jun 7, 2005, at 11:51 AM, Joseph Alotta wrote: Did NeXT produce their own boxes, or did they allow installs on any PC with supported hardware. I believe that is a key difference. Apple boxes will be exactly the same as they would have been, except they will have a different CPU. You still won't be able to install OS X on a commodity PC without jumping through a lot of hoops. Why wouldn't you? Memory, drives, video, etc. are all the same right now. Motherboard has pretty standard features, other than it is setup for a Power processor. Apple has been going cheap for a while, SCSI - IDE ring any bells? It would be a real shame if they didn't allow you to install OS X on any commodity PC, once again back to that whole volume issue. Some combination of BIOS, custom ASICs, EULAs, lack of support, and installer trickery. There are lots of ways Apple can discourage this. I don't think anybody expects these are 100% solutions, but they are sufficient to ensure that consumers and corporations won't consider it a solution. This leaves hobbyist/enthusiast types, and I'm sure Apple can live with it. It's like iTunes' DRM - it's not a 100% solution, but just enough of a barrier that the general public won't bother. Without a different chip, Macs really are just a pretty looking box with a nice software package preinstalled. Darwin runs on Intel already (mostly) which is the real key, if Apple goes through with this and won't let you install on a commidity PC then they really missed the boat, in fact I would say they couldn't even find the dock. The cost speed issues are resolved by moving to x86 chips and supporting chipsets. Keeping them off commodity PCs doesn't hurt those things at all, but keeps them from dealing with support issues and having to compete head to head with MS. Do you think MS would have been nearly so quick to declare support for OS X/Intel if Apple allowed installs on commodity PCs? If Apple can get to a 15-20% market share, then maybe they could afford the loss of hardware revenue, but they aren't there yet. I think the only way that you look at it is that if IBM couldn't or wouldn't deliver the processors Apple needed at a reasonable price, what else could Apple do? Will definitely agree with you there. Though you have to love the media spin making it seem like this is Apple's choice to drop IBM, uh huh. I'm sure Apple could have stuck with IBM, but they would be paying through the nose to be 4th in line behind Sony, MS, and Nintendo. Ian
Re: CamelBones on Intel? Maybe not.
On Jun 6, 2005, at 5:18 PM, Joel Rees wrote: Jobs is insane. I'm not so sure about that. IBM seems unwilling or unable to produce mobile G5s, which is a market that Apple considers very important. They also are 2 years behind schedule on 3.0Ghz G5s, and appear to be focusing on video game processors instead of desktop and mobile processors. Apple might be OK in a speed comparison right now (on desktops, they are clearly losing in laptop comparisons), but how about in two years? Perhaps IBM has told Apple that they won't attempt a laptop chip, since the volume is way higher for video game consoles? What should Apple do? Personally, it looks like it will be a bit painful for a few years, but a far better move in the long run. Ian
Re: Tiger version
On Apr 12, 2005, at 9:41 AM, Lola Lee wrote: Chris Devers wrote: Your best bet is to just keep an eye on tech news sites. The release of Tiger will surely be a headline on CNet, Slashdot, etc, and maybe even non-tech-specific sites like CNN or the BBC. And not a moment too soon . . . go over to http://www.apple.com/macosx/. Release date - April 29th. I've been looking at http://www.apple.com/macosx/developertools/ and unfortunately it doesn't say which Perl version. Surely this tidbit is buried elsewhere on the site? They often release their copies of open source stuff before the final release, which would be found here: http://www.opensource.apple.com/darwinsource/index.html The 10.4 stuff isn't up yet, but the WWDC 2004 Developer Preview had 5.8.4 according to that page. Ian
Re: ANN: ShuX 3.0-beta1
It works for me if I open it from the Finder. Have you tried using open? open /Applications/ShuX.app It has the advantage of being easier to type. Ian On Mar 18, 2005, at 2:03 PM, David Wheeler wrote: On Mar 18, 2005, at 11:45 AM, Sherm Pendley wrote: One of the features of CamelBones 1.0 will be the ability to package stand alone apps that require no external framework, and can be installed with a simple drag-and-drop. This release takes advantage of that - just mount the disk image and drop ShuX wherever you want. I don't have CamelBones installed. I just installed this release of ShuX, but it doesn't appear to work. Here's what happens when I try to launch it from the terminal: % /Applications/ShuX.app/Contents/MacOS/ShuX zsh: bus error ShuX.app/Contents/MacOS/ShuX Yes, I'm using Panther (Mac OS X 10.3.8). Regards, David
Re: What Perl editor do you recommend?
On Mar 3, 2005, at 7:04 AM, Randal L. Schwartz wrote: Ian == Ian Ragsdale [EMAIL PROTECTED] writes: Ian If you want to stay with something free, I'd suggest TextWrangler from Ian Bare Bones: Ian http://www.barebones.com/products/textwrangler/index.shtml Ian It has good syntax coloring, and integrates well with the command-line Ian perl - you can set a keyboard shortcut to run scripts check their Ian syntax, and you can write filters and other scripts in perl. Pretty Ian sweet for a free product. Again, if you keep pushing free, I'm going to say emacs. :) Emacs has all that. And more. Keep pushing free? I was the first response! :) I like vi better than emacs personally, but mainly cause I know it a lot better. For someone on OS X, that wishes to use a GUI (which was my assumption), would you really suggest they spend the time learning emacs or vi? My guess is that most people who suggest such things don't realize how long they spent learning how to be productive in it. I'd guess that anybody who learned vi or emacs after 2000 wouldn't suggest it. I personally learned it in '94 and still don't feel that productive in it. Ian
Re: What Perl editor do you recommend?
If you want to stay with something free, I'd suggest TextWrangler from Bare Bones: http://www.barebones.com/products/textwrangler/index.shtml It has good syntax coloring, and integrates well with the command-line perl - you can set a keyboard shortcut to run scripts check their syntax, and you can write filters and other scripts in perl. Pretty sweet for a free product. Ian On Mar 2, 2005, at 11:38 AM, Ted Zeng wrote: Hi, Thanks for the help here. I am almost finishing my first tool on OS X. I am using TextEdit as the editor. I sometime use Pico, but I am still not comfortable with Unix editor. I know there must be some good editors for Perl. Do you have any recommendation? ted zeng Adobe Systems
Re: MOD_PERL and OSX
My guess is that you have a version mismatch between mod_perl and perl. Ian On Nov 9, 2004, at 4:59 PM, Mark S Lowe wrote: It would seem after many attempts to get anything of any level of complexity running in mod_perl under OSX, that perhaps it cant be done. I have libraries that work fine in the normal cgi-bin, but constantly produce 500 server errors when running from my mod_perl mod-cgi bin. I can get little hello worlds running fine, but the second I try to access various built-in libraries, just the use statement cases fatal errors. Has anyone conquered the mod_perl world of OSX? Ive read every thread that has come through this forum for the last year. Those posts did help resolve the basics, but Im still left with a so so mod_perl engine. Any general direction or guidance would be great. Thanks. Mark
Re: BBEdit 8.0
On Sep 9, 2004, at 5:00 PM, Chris Carline wrote: I'm curious as to the attraction of BBEdit. Coming from a Unix/Windows background, I find that whilst it seems pretty solid and has some nice features, it costs at least five times more than any sane person should be prepared to pay. But even taking that into account, it actually seems to do *less* (at least for me!) than the free alternatives that ship by default on OS X (personally, I use Vim). I know vim, but not super well - what does it do that BBEdit does not? I imagine if you already know vi/vim well and have it customized to your liking, there's no need to pay for anything else. Personally, I've been using it off on for about 10 years and still don't know how to use most of it's features. Most of the time when I have advanced processing to do I copy the file locally and edit using BBEdit. OK, so its integration into the enitre OS is generally a lot better than the free stuff, but... Well, for Mac users that's a huge distinction, especially if you don't already know vi or emacs. There isn't really any learning curve to deal with. So why the attraction? Is it really only old OS =9 users that use it, or am I really missing something? Well, I imagine a lot of it's following started during the OS = 9 days, when things like vi or emacs weren't really available. It also served as a replacement for things like grep and sed which weren't available at the time. I'd imagine that for many people it's the interface - you can accomplish a ton of things that are doable with command line tools but that most people don't know how to do. Here are some of the things I find really useful: Effortless transparent handling switching of line endings. Powerful HTML tools Shell worksheets (allows easy editing running of shell commands) Multi-file regular expression find replace functionality, with nameable saveable expressions Transparent FTP/SFTP support Easy scriptability and integration with command line tools Ian
Re: [OT] MySQL for Web Apps
On Feb 4, 2004, at 1:59 AM, Bill Stephenson wrote: It occurs to me that the unix os is basically a database in and of itself and perl interacts directly with the os, therefore, using it to store and retrieve data may not be that inefficient. I agree with this - you can get good results with a well-planned directory structure. Now, if you have one server dedicated to serving only 2500 users and in 2-3 years you have 5000 users and upgrade that server to one twice as fast and big, and so on This is true to a point, but disk drives haven't progressed at nearly the rate of CPU/RAM, so you could definitely start running into problems like this. The main disadvantage of using a database engine like MySQL is that users cannot define data fields. If other applications are going to access the data in question than you must reformat it to provide the access. And again, I'm lazy (actually, I have other things I like to do) and really don't want to learn more. I'd rather use what I already know and leverage what I already have. Since I don't know exactly what you're building here, it's hard to comment, but I agree, that is one area that hasn't been solved very well with relational databases, at least not in MySQL. If some of your users want columns different than others, you either need to split the tables somehow, or have all the columns (and maybe some extras) you think you may ever need available and only expose the ones particular users ask for. If anybody knows a cleaner way to do this, I'd love to hear it. If Rick's Dream comes true I can just port the data at that time. There are a lot of programmers out there working on faster, easier to use, database engines that have more features. Chris, you may be right, XML may be a fad, but the next big thing in data storage/retrieval could be right around the corner too. The above are some of the excuses I've come up with to avoid spending more time learning stuff. If I'm deluded, it's because I have boxes upon boxes of software that doesn't work anymore and time invested in each of them. It's not that I don't believe that MySQL and other database engines have a place, I'm just trying to avoid learning how to use them if I don't really need too. Personally I think it's worth it in the case of MySQL (or other relational databases). The basics are pretty easily learned in an afternoon or two, and as your application and needs change, you'll definitely save yourself days worth of work by being able to leverage a good DB when your solution really calls for one. Ian
Re: mssql
FreeTDS (www.freetds.org) is an open source implementation of the Tabular Data Stream protocol used by Sybase and MSSQL. You can use freetds and DBD::sybase to connect to MSSQL. I have used it without problems on a number of linux machines with the DBD::sybase module but have never tried it on OS X, however, a google search for freetds and mac os x turns up some people who seem to have it working. It is a bit of a pain to set up - the configuration is a little strange, but the freetds docs are somewhat helpful and you can feel free to ask me questions if you run in to problems. HTH, Ian On Saturday, March 8, 2003, at 12:17 AM, rich allen wrote: iH is there anyway to connect from Mac OS X to mssql? thanks - hcir
Re: Cursor return, no line feed
The simple old way (I'm not sure if the syntax below supercedes it) is:
$|=1;
Assigning any non-false value to $| will turn off buffering.
Ian
On 1/31/03 9:16 PM, Dan Mills [EMAIL PROTECTED] wrote:
On Friday, January 31, 2003, at 12:26 PM, Martin Redington wrote:
Try the following:
perl -e 'for($i = 0; $i 100; $i++){ print STDERR $i; sleep 1 ;
print STDERR \r}'
(I used STDERR, to avoid buffering of stdout. There is a way to
disable this, but I can't recall it off the top of my head).
iirc, you can turn off the buffering with:
STDOUT-autoflush (1);
-Dan
Re: How do you install modules in OS X?
This is a bug in the version of CPAN that comes with perl 5.6. If a module is in the perl core distribution and you try to install or upgrade it (it's possible that it moved into the core in a later version than 5.6) then that version of CPAN will grab perl to install that module. If you instead download and install the latest version of CPAN by hand (if you try to use CPAN you trigger the bug) then this will be fixed and it will grab only the modules you specify, not the whole perl distribution. Ian On 10/31/02 2:52 PM, Trey Harris [EMAIL PROTECTED] wrote: In a message dated Thu, 31 Oct 2002, Sherm Pendley writes: The version of CPAN.pm shipped with OS X is over-zealous about installing prerequisites, and will try to install Perl 5.8.0 for you if you use it to install the bundle. Unfortunately, in doing so it overwrites the existing Perl, causing no end of problems. Which brings up a question that's been nagging at me. There must be some way to tell CPAN, don't upgrade Perl unless I tell you to, and if some other module you're trying to install needs a new version of Perl, try to find an older version of the module that doesn't, isn't there? I've never bothered trying to track down this elusive (nonexistant?) option, since I use the 'ask' mode rather than the 'follow' mode for dependencies. I just answer 'no' and go to search.cpan.org and work out the dependencies for myself. Annoying, but it works. :-) Trey
Re: OS X meltdown
You should be able to re-install without having to reinstall everything. Since only Apple stuff goes in /System, the archive install option on the 10.2 disk should move the /System folder and reinstall all the system files without disturbing everything else. Ian On 10/24/02 12:29 PM, Trey Harris [EMAIL PROTECTED] wrote: Time to haul out a small fortune of DVDs (but not quite enough to justify buying another FireWire disk, alas) to make backups before reinstalling, I think.
Re: OS X meltdown
On 10/24/02 12:41 PM, Trey Harris [EMAIL PROTECTED] wrote: In a message dated Thu, 24 Oct 2002, Ian Ragsdale writes: You should be able to re-install without having to reinstall everything. Since only Apple stuff goes in /System, the archive install option on the 10.2 disk should move the /System folder and reinstall all the system files without disturbing everything else. *Should*. My system has been acting so strangely that I'm very suspicious of anything short of a reformat of the disk. I might give it a try, but this has knocked me out of commission for three days, and I'm thinking it's better to get it all over with than take the chance that at some random point in the future it will all happen again If it was me, I'd back up my Users folder and my Applications folder, and do a clean install. If you create the users with the same UIDs, you should be able to just put the Users Applications folders back be pretty close to where you started - most mac applications are very good about storing all preferences in the users's preferences folder. Good luck, Ian
Re: FYI: Successful Install of Perl 5.8.0 RC 1 + Apache 2.0.36 +ModPerl-2.0 on OSX 10.1.4
If you are hoping for case-sensitivity, which is the only part of a new file system that would fix this problem, don't get your hopes up - I'm pretty positive that Apple will never make their default file system case sensitive. This has been discussed at length in many forums. As for HFS+, what does everybody dislike about it? The only problem I see with it is a lack of journaling. It has support for huge files volumes, is fast, B*tree based and has support for extended metadata forked files. If you compare it's feature list to most file systems people ask for, the only thing it's really missing is journaling. It is not the MOST robust file system I've heard of, but I haven't had a problem with it in a few years. It got corrupted under OS 9, but that was more an issue of OS 9's stability. Ian On 6/4/02 4:05 PM, Alex S [EMAIL PROTECTED] wrote: I'd prefer to see if we could convince the developers at Apple to use a better file system. I'm hoping that one of the new people on the core Apple dev team (forget his name at the moment), who is a filesystems guy, is there to make that all better! A journalled FS would be nice too. But for now, it's wishful thinking! -Alex David Wheeler wrote: On 6/4/02 1:35 PM, R Blake [EMAIL PROTECTED] claimed: for those who are interested .. Building a Bleeding Edge OpenSource OSX Server http://homepage.mac.com/blakers Ach. I wonder if we could convince the porters to change the distribution so that we don't have to do this: mv INSTALL INSTALL.txt; David
Re: Accessing Samba - Mount Volume Possible?
On 5/1/02 3:29 PM, Randy Boring [EMAIL PROTECTED] wrote: Pre-warning, I'm biased, as I work for Thursby Software Systems, Inc. I'll keep that in mind. :) Samba is mostly a server, so it's not likely that you really want to mount _via_ Samba, you probably want to mount a Samba volume via an SMB or CIFS client. Actually, the Samba package does include a way to mount a filesystem as a client, but I don't believe that this works on OS X. (They also include a rudimentary command-line client, which I don't believe you want.) Apple does ship an smb client with OS X, but yes it has problems, only one of which is being limited to one mount at a time. (Lack of browsing the network is another.) I agree that Apple's current smb implementation has problems, especially the lack of browsing capabilities, but it does NOT have a problem mounting more than one share at a time - I do this on a regular basis. I know you have a product to sell but lets keep it truthful. :) You were probably thinking about the competing product Sharity (from Objective Development), which in it's demo form only allows one mount at a time (but has very nice browsing capabilities). DAVE, on the other hand, is a robust client (and server if you want), which can connect to many shares at once, handles FAT and NTFS volumes and servers of many kinds (Windows 95/98/ME/NT/2K/XP and many UNIX-based servers including Samba servers). To answer your question, it also supports mounting via AppleScript. I will agree with you that Dave was a great product on OS 9 - I don't really have much experience with it on OS X, beyond one of the first betas. Ian
Re: mod_perl stopped working...
On 4/11/02 1:31 PM, PK Eidesis [EMAIL PROTECTED] wrote: But this whole Perl 5.6.1, mod_perl crapola has left me very befuddled. In some ways I have myself to blame because I dicked with Apple's stock 5.6.0 install... I never should have done that. Otoh, Perl/CPAN/mod_perl install should have protected me from screwing myself up. FWIW, the CPAN behavior that tries to get you to upgrade to 5.6.1 is actually a bug in CPAN, that can be avoided if you upgrade to the latest CPAN *by hand* (not using CPAN). The problem is with installing modules that have been merged into the base perl install - it doesn't understand that it can get them on their own, so it gets them by grabbing the latest perl. This has caused a lot of problems for us when installing modules. Ian
Re: Installing Perl
On 3/19/02 11:56 AM, Palle Bo Nielsen [EMAIL PROTECTED] wrote: It seem like it can't find the LWP/Simple.pm package, which probably isn't installed per default on Mac OS X Server. So what I thought was... A) Do I need to install a fresh copy of Perl from CPAN ? No, you don¹t. You can install modules without having to upgrade perl. B) Do I only need to install the LWP/Simple.pm from CPAN ? If so, how can I find it at CPAN ? You should use the CPAN module that comes with perl, like this: Perl -MCPAN -e install LWP::Simple It will need to be configured the first time you run it, you can use the default settings for pretty much everything. For more info on CPAN, try perldoc CPAN at the command line. You can also go to the web page (www.cpan.org) download the modules install them manually, but the CPAN tool tends to be easier. Ian
Re: Perl as alternative to MySQL
On 3/18/02 1:07 PM, Danny Arsenault [EMAIL PROTECTED] wrote: Please let me know if this is crazy! It's not totally crazy. :) Now, the folks on the Lasso list claim that this kind of file-based DB thing is done all the time in Perl, and now that we have Perl on OS X, I wonder if I should try to develop this part of it in Perl rather than learn MySQL, which seems a lot harder, and I'm not running NASA over here. Sure, you can do this stuff in perl just fine, but I don't think I'd recommend it in this case. Flat-file solutions are easy to a point, but they don't scale very well, especially if you start adding a lot of data. I would recommend you start learning MySQL. If you can learn perl, you should be able to use mysql just fine - it is definitely one of the more simple databases out there, as far as I've seen. So please let me know if there are any good sites or resources about this, or if I'd better just go with MySQL or maybe something else entirely. Given your lasso background, I would suggest you consider PHP as well. I prefer perl myself, because I know it a lot better, but I think you'd be up and running a lot quicker with PHP. It is easier to learn, and it works much more like lasso than perl does, so it should be easier for you to get used to. It is also installed by default on OS X, you just need to enable it. Ian
Re: how to use DropScript?
DropScript executes the script inside it and passes the paths of any files that were dropped on the app. The default one clones itself with any script you drop on it. So, you write your script in a way that just expects filenames as arguments, and then you drop your script on DropScript, which will create a new applet with your script inside. If your script doesn't do anything, I would guess that something is wrong with your script - maybe line endings? Ian On 2/4/02 9:52 AM, CDE Francis [EMAIL PROTECTED] wrote: I've got a Perl script that massages my access logs each month. I tried to use Wilfredo's DropScript to make a dropplet but the resulting .app file doesn't do anything. I ended up going to Terminal and saying 'perl [scriptname] [logname]' but dammit I want my Power of Unix, Simplicity of Mac. How? Side note: has nntp.perl.org been turned off? I'd definitely rather talk Perl via nntp than smtp. -F.
Re: ImageMagick (to use with PerlMagick)
I downloaded compiled it successfully a couple of weeks ago, but have since been too busy to make sure it works correctly. Try running ranlib /usr/local/lib/libMagick.la and then trying to compile PerlMagick again. It seems as if you have to run that on new libraries before you can link to them. Ian On 1/29/02 10:17 AM, Tomás García Ferrari [EMAIL PROTECTED] wrote: Hello, I'm trying to get ImageMagick + PerlMagick running on MacOSX. I found several places from where I can get ImageMagick, but I can not compile PerlMagick... I downloaded the ImageMagick source and discover that if I suceed compiling it from source, PerlMagick can be compiled as well at the same time. But now, I'm having this error when I tipe 'make': /usr/bin/libtool: internal link edit command failed make[2]: *** [libMagick.la] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Anybody suceed having ImageMagick + PerlMagick running? Any experience to share? Regards + Thanks, Tomás +-- --+ Tomás García Ferrari Bigital http://bigital.com/ +-- --+
Re: Apache::args vs Apache::Request speed
How about setting something up on SourceForge? I know they have OS X environments available for compiling and testing. Ian On 1/28/02 2:19 PM, John Siracusa [EMAIL PROTECTED] wrote: I'm cc-ing this to the Mac OS X Perl list in the hopes that someone can provide a test environment for you. (I would, but my OS X box is behind a firewall at work.) So how about it, [EMAIL PROTECTED] folks, can any of you help get libapreq up and running on OS X an long last? (See message quoted below) -John On 1/28/02 2:02 PM, Joe Schaefer [EMAIL PROTECTED] wrote: Stas Bekman [EMAIL PROTECTED] writes: Great! Now we have an even broader benchmark. Please tell me when 1.0 is released (in case I get carried away with other things and don't notice the announce) and I'll make sure to update my benchmarking package, re-run the benchmarks and correct the results in the guide. Great- there's a typo or two in the handler_do sub, but they should be pretty obvious when you try to run it. I hope a new release will be just around the corner, but if you want to test out some of the latest stuff, have a look at http://www.apache.org/~joes/ I don't think we'll have a 1.0 that works on OS/X, but I might be able to include a patch in the distro that will build the C api of libapreq directly into httpd. This might allow OS/X to run Apache::Request and Apache::Cookie at the same time, but that platform is unavailable to me for testing.
Re: Configuring /Setting Up Perl on OS X 10.1.2
Just make sure you install the dev tools - without them you don't have make or GCC, and you won't be able to install any additional perl libraries. Other than that, I haven't found anything to be missing out of the box. Oh - and make sure you have BBEdit 6.5 - possibly the best perl tool ever. :) It can search the perl docs, run the scripts right from the editor, and parse any error messages to tell you what went wrong. Ian On 1/18/02 4:50 PM, Jason Bourque [EMAIL PROTECTED] wrote: Hello, I am going to a three day Perl class next week and would like to know if there is anything I have to do to set up my Mac for Perl Scripting. Any technotes or things I need to install before the fun starts? Thanks, Jason Bourque
Re: Help with Perl on MacOSX
On 1/10/02 1:38 PM, Chris Devers [EMAIL PROTECTED] wrote: On Thu, 10 Jan 2002, John Gruber wrote: (BBEdit is about as agnostic about line endings as an editor can get.) Vim is pretty agnostic too -- it'll just optionally put a little [dos] or [mac] or [unix] in the corner if you ask it to -- but that's not really the core issue here. I mean, what *is* the default line terminator on OSX supposed to be? It seems like half the software, the old Classic stuff, is making one assumption while the other hald, the old NeXT stuff, is making the opposite assumption, with a small agnostic middle ground. If OSX is Unix, then it either needs to adopt Unix line endings (and the Classic stuff will just have to Deal With It), or it the installed set of Unix tools should be adapted to recognize Mac endings. Or something. This is annoying, but workable. The classic mac users that don't use UNIX won't be using UNIX tools and won't care about UNIX line endings. The ones that do use UNIX are already aware of the issue and know how to deal with it. Unfortunately, this problem doesn't seem like it will be going away any time soon Well, UNIX stuff should keep using the UNIX line endings to maintain compatibility with other UNIXes. Cocoa stuff should continue to use the UNIX line endings for the same reason. It's the carbon stuff that should eventually transition to use the UNIX line endings. Hopefully as the platform matures more people will be writing to the Cocoa APIs, and the Carbon developers will be forced to use (or at least tolerate) UNIX line endings to maintain compatibility with everything else. Ian
Re: SOAP::Lite
Larry, there are a few debugging tricks you can do at this point. The first
thing you should do anytime you get an internal server error is check the
apache error log (in /var/log/httpd/error_log) - this might give you some
indication of what is going wrong.
Another handy thing to try is to run the script on the command line - I'm
not familiar with SOAP::Lite, but if it uses the CGI module, you can
probably just run your script like 'perl scriptname args=1args=2' - if
there is a compile error, you should see that here. You can also check your
script's syntax with perl -cw scriptname. If you're using BBEdit, you can
check syntax from there from the perl menu. If you're not using BBEdit, I
recommend you get it. :)
Also check out the the CGI::Carp module - put this line at the top of your
script:
use CGI::Carp qw( fatalsToBrowser );
This will print any fatal errors in your script to the web browser instead
of the error log - very handy for debugging.
If you've installed the SOAP::Lite module, and have copied the working
script verbatim, I would guess that your problem is line endings - make sure
your script is using unix line endings instead of mac - mac line endings
confuse perl into thinking your script is one long line.
Ian
On 10/4/01 6:52 PM, Larry Staton Jr. [EMAIL PROTECTED] wrote:
I've been playing around with AppleScript and Perl clients to XML-RPC
servers and SOAP servers. Both implementations work very nicely.
However, I would like to build a Perl server with SOAP::Lite. I have
attempted the Temperatures example at http://guide.soaplite.com. When I
try to access the Perl server with a Perl client, I get a 500 Internal
Error message at line 3 in the client script. Here is the client script:
use SOAP::Lite;
print SOAP::Lite
- uri('http://my.server.com/cgi-bin/Temperatures')
- proxy('http://my.server.com/cgi-bin/temper.cgi')
- f2c(32)
- result;
Any suggestions? TIA.
--
Larry Staton Jr.
E-mail: [EMAIL PROTECTED]
Weblog: http://staton.weblogger.com
Brought to you by Mail.app from Mac OS X
Re: Cocoa interfaces
On 9/18/01 12:40 PM, Stefan Rusterholz [EMAIL PROTECTED] wrote: On Mon, 17 Sep 2001, Wilfredo Sánchez wrote: yeah; in MacOS X we could (finally) have applications written in Perl that for the user would look just like any other. So then, let's start a petition =) I think too, that such an API was simply genious! With that, the OS X platform would gain a lot of application programmers. Hmmm, I just have to think about that. I enjoy the idea to write a non webserver based application to admin mysql on OS X. And that was only the top of it... I'm all for this as well. I'm a hell of a lot better Perl programmer than I am a C or ObjC programmer, and I would be thrilled to be able to do these things in Perl. If there's a petition, I'll sign it. If there is someone to send feedback to, give me a name - I'll do it. Ian
Re: GUI?
I believe that the interface for Tenon's iTools uses this approach. Ian On 8/18/01 12:15 AM, Bill Stephenson [EMAIL PROTECTED] wrote: Otherwise, you can use the Interface Builder and write some code to pass objects between a perl app and an app built with the Developer Tools. I have not seen this done yet, but I've heard it's possible.
Re: MySQL data files HERE!
I just wanna chime in here with a quick explanation of what is going on, so that it doesn't seem so arbitrary. In the public beta, the root password was set to be the same as the first user you created. This is bad for a number of reasons, but this is why you could use 'su' with your own password. In the released version, there is NO root password at all, which is why you couldn't use 'su'. However, sudo can authenticate users as root using their own password, and 'su' doesn't ask for a password if you are root, which is why 'sudo su' worked just fine. If you really wanted to (I don't recommend this, although others might disagree) you could set the root password using 'sudo passwd'. Then, you would be able to log in as root if you wanted to, and 'su' would work normally. However, I've been using my machine steadily since the release, and have had no real need to do this - sudo has taken care of all my needs. Ian On 6/29/01 12:59 PM, Nelson Goforth [EMAIL PROTECTED] wrote: Answering my own question... Since I wasn't getting anywhere with 'su' - I thought to try: sudo su And it worked! Just used my 'admin' password (don't have root enabled) and I was in like Flynn. Whoever that was. Thanks for the assistance. I've been using Unix (mostly perl) for a several years, but always on a remote server and so without a lot of access to the innards. I've got a lot to learn with OS X for that reason. But running perl, PHP and MySQL right on my own machine is changing the way I write websites and databases - in a good way. No telnet, no Fetch... Nelson
Re: MacPerl to OSX Perl
My guess is that it is a line endings problem - I get this error under most unix systems if I use a file with macintosh line endings. Can whatever editor you're using translate the line endings to unix? Ian --On Sunday, April 1, 2001 3:16 PM -0800 hciR nellA [EMAIL PROTECTED] wrote: iH i have a two page script that works under MacPerl which uses Net::Telnet and Socket. when i copy the script to my OS X documents folder and try to run it, perl complains that there is a right curly brace that doesn't have a match. Any ideas what may be causing this? thanks - hcir mailto:[EMAIL PROTECTED] Made with a Mac!
Re: Carbon apps on unix disk
Your definitions are correct, but carbon apps can come in two forms. If you are careful in writing your carbon app, and compile it in PEF format, it can run in OS 9 as well as OS X. If you compile into Mach-O, you can use some native services that you can't with PEF, and it will only run in OS X, and not OS 9. Either way, you will get a blue (or graphite) apple in the menu bar instead of a multicolored one. On 4/1/01 10:33 PM, "Ken Williams" [EMAIL PROTECTED] wrote: Apparently I need some clarification of terms. I thought these were the definitions: carbon: will run on OS X without needing the classic environment cocoa: uses a specific OS X application framework classic: will run under OS 9, but not OS X So checking whether something is "carbon" should be a simple matter of running it, then checking whether the logo in the upper-left is rainbow-colored or blue. Right? The comments below seem to indicate something different. [EMAIL PROTECTED] (Ian Ragsdale) wrote: Pepper is definitely carbon - it runs on OS 9 as well. Ian On 4/1/01 8:48 PM, "Bill Stephenson" [EMAIL PROTECTED] wrote: PhotoLine and Pepper both work well on either format, but they're not really "Carbon" apps are they?
