From darren at DarrenDuncan.net Sat Feb 7 00:47:14 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] TIP: fixing a common Perl 5.8 problem on Mac OS X Message-ID: Hello. This is a tip for any of you who have run into a certain annoying warning that some Perl installs give off every time they are run, and you don't know how to stop it. I recently had this problem and didn't know how to solve it either, until now. Specifically, Perl says something like this: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "en_US" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Perl still continues to do its work as usual, but it is noisy. From my searches on the internet, I found that many people had complained about this problem, some going back to 1998 or so, and it occurred on many different platforms. A significant number of postings dealt with Mac OS X, and I eventually found a solution among them. This is the message thread I found with the solution: http://www.mail-archive.com/macosx@perl.org/msg05650.html What you need to do is edit or create the following file: ~/.MacOSX/environment.plist aka /Users//.MacOSX/environment.plist It should look like this on the inside: LANG en_US LC_ALL C Note that, in my situation, neither the file nor the ".MacOSX" folder existed yet, so I had to create both. The text file has Unix line breaks. The above details in the file came from the posted solution online, so some details like the plist version or the DTD url don't necessarily have to be the same, and the file can have additional content. When creating the ".MacOSX" directory, you will have to use the command line, since the Finder won't let you. But you can open said folder in the Finder after it is made and use it to put the file there if you want. After you add this file, log out and then log in again. When running Perl, the problem has gone away. As a bit of background, I had started off with a Mac OS X 10.2.6 system and a built from source copy of Perl 5.8.1rc4; this I had a week ago and it all worked well. I started encountering the above problem after doing a fresh install of 10.2.8, but left the Perl the same (it was on a different partition); the Perl still ran except for that warning. Thinking perhaps that my Perl may have become damaged, and before I did the online search, I installed Perl 5.8.3, from source, but it gave the same warning. Note that, throughout this whole time, the Perl 5.6.0 that came with the operating system never gave the warning once. I hope this has helped someone. Note that I have never seen mention of it on these lists before. -- Darren Duncan From darren at DarrenDuncan.net Mon Feb 9 16:04:01 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] February meeting Message-ID: P.S. Please keep all replies on-list. I have an update here concerning the February meeting. I may indeed be able to do the talk this month, however at my current rate I'll need another 2 weeks before I am ready. Therefore, I suggest having the meeting in the last week of February (in Feb 23-27). While I expect any day will work, a wednesday or later is slightly preferred by me as I can then do other things in town (and I get more time). But of course, whatever day the most people can make is best. The topic would be using databases with Perl, and would focus on up and coming technologies to aid in this effort, including the one I'm making. Said technology should actually be useable at the end of 2 weeks, tested with at least basic/common tasks. That was the plan before, however ... This week I learned about something else which you should all be interested in, that I can use to fill time. An official Parrot DBI project has started, which I have joined. This version will be written entirely in Parrot bytecode / IMC rather than the current XS/Perl dichotomy. This core won't probably won't be used by the Parrot-hosted-language programs that you write, but each language will have a module to take care of the dirty details, with the Perl one looking like the current DBI. We will take advantage of Parrot's Native Call Interface (NCI) feature that lets you use C shared libraries without writing any C yourself. That would make our development of drivers et al much easier. The email list for the PDBI development group is: dbdi-dev@perl.org Archives for said list are at either: http://www.mail-archive.com/dbdi-dev@perl.org/maillist.html Or: http://www.nntp.perl.org/group/perl.dbdi.dev The first one has a problem where it doesn't show messages after February 3rd, including any threads I participated in; the second one shows them. Tim Bunce's announcement concerning this development group and PDBI, through which I discovered it via the Perl 6 weekly summaries, is visible here: http://www.nntp.perl.org/group/perl.dbdi.dev/3 Or: http://www.mail-archive.com/dbdi-dev@perl.org/msg00002.html Considering this recent revelation, I am probably going to change the way I do my Rosetta project, at least at first. My prototype is still in Perl 5 and sits on DBI as usual, which is a solid platform right now. My next version was going to be in C, but now I'm thinking of writing it in Parrot IMC et al instead. That will let me just distribute one version that everyone can use, rather than seperate versions for every target platform that C requires. I will also bring that Joy of Tech cartoon book as a door prize, inscribed to our group by the artists. -- Darren Duncan From cconstan at csc.UVic.CA Mon Feb 9 16:43:46 2004 From: cconstan at csc.UVic.CA (Carl B. Constantine) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] February meeting In-Reply-To: References: Message-ID: <20040209224346.GK718@csc> *On Mon Feb 09, 2004 at 02:04:01PM -0800, Darren Duncan (darren@DarrenDuncan.net) wrote: > P.S. Please keep all replies on-list. > > I have an update here concerning the February meeting. > > I may indeed be able to do the talk this month, however at my current rate I'll need another 2 weeks before I am ready. Therefore, I suggest having the meeting in the last week of February (in Feb 23-27). While I expect any day will work, a wednesday or later is slightly preferred by me as I can then do other things in town (and I get more time). But of course, whatever day the most people can make is best. > I can't make Wednesdays at all right now. Sending my wife on a bookkeeping course and I have to look after the kids. Also that Wed, I have another meeting. Thursdays are never good for me either as I have a prior commitment. -- Carl B. Constantine University of Victoria Programmer Analyst http://www.csc.uvic.ca UNIX System Administrator Victoria, BC, Canada cconstan@csc.uvic.ca ELW A248, 721-8766 From abez at abez.ca Mon Feb 9 16:57:46 2004 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] February meeting In-Reply-To: <20040209224346.GK718@csc> Message-ID: I'd prefer to keep it on a monday or a tuesday. On Mon, 9 Feb 2004, Carl B. Constantine wrote: > *On Mon Feb 09, 2004 at 02:04:01PM -0800, Darren Duncan (darren@DarrenDuncan.net) wrote: > > P.S. Please keep all replies on-list. > > > > I have an update here concerning the February meeting. > > > > I may indeed be able to do the talk this month, however at my current rate I'll need another 2 weeks before I am ready. Therefore, I suggest having the meeting in the last week of February (in Feb 23-27). While I expect any day will work, a wednesday or later is slightly preferred by me as I can then do other things in town (and I get more time). But of course, whatever day the most people can make is best. > > > > I can't make Wednesdays at all right now. Sending my wife on a > bookkeeping course and I have to look after the kids. Also that Wed, I > have another meeting. Thursdays are never good for me either as I have a > prior commitment. > > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From peter at PSDT.com Mon Feb 9 21:31:47 2004 From: peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] February meeting In-Reply-To: References: <20040209224346.GK718@csc> Message-ID: <5.2.1.1.2.20040209193027.00b46f70@shell2.webquarry.com> At 02:57 PM 2/9/2004 -0800, abez wrote: >I'd prefer to keep it on a monday or a tuesday. I agree. We should have some sort of a pattern here. In fact, other PMs report that having a predictable meeting date was the single biggest factor in their successful growth. That is my aim. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From Peter at PSDT.com Mon Feb 9 21:34:53 2004 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] February meeting In-Reply-To: Message-ID: <5.2.1.1.2.20040209193214.00b9a8b8@shell2.webquarry.com> At 02:04 PM 2/9/2004 -0800, Darren Duncan wrote: >I may indeed be able to do the talk this month, however at my current >rate I'll need another 2 weeks before I am ready. Therefore, I >suggest having the meeting in the last week of February (in Feb >23-27). While I expect any day will work, a wednesday or later is >slightly preferred by me as I can then do other things in town (and I >get more time). But of course, whatever day the most people can make is best. I'd prefer we stick to Mondays or Tuesdays. I don't mind slipping a week or two; does anyone have anything else they'd like to present this month, and that would give you until March? I submitted a 1/2-day tutorial proposal to OSCON on how to handle legacy Perl code. If they approve it I will be notified on March 15 and would like to try it out on VPM in April and May. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From darren at DarrenDuncan.net Mon Feb 9 22:03:49 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] February meeting In-Reply-To: <5.2.1.1.2.20040209193214.00b9a8b8@shell2.webquarry.com> Message-ID: So the masses have spoken. Monday or tuesday it is. All other things being equal, I prefer tuesday, which gives more time. Is there anyone that can't make tuesday? Or in general, which of the two days is simply "better"? -- Darren Duncan From jeremygwa at hotmail.com Tue Feb 10 01:26:34 2004 From: jeremygwa at hotmail.com (Jeremy Aiyadurai) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] Perl for the Wireless????? Message-ID: is there such a thing as wireless perl? (like wireless java). Suppose I wanna write a program for a cell phone? are there any developements considering this? regards, Jeremy A. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From Peter at PSDT.com Tue Feb 10 01:36:42 2004 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] Perl for the Wireless????? In-Reply-To: Message-ID: <5.2.1.1.2.20040209233537.00b46db8@shell2.webquarry.com> At 11:26 PM 2/9/2004 -0800, Jeremy Aiyadurai wrote: >is there such a thing as wireless perl? (like wireless java). Suppose >I wanna write a program for a cell phone? >are there any developements considering this? I haven't heard of such a thing. A search for "embedding" and "perl" may help. As might the Cozens/Jenness book. Let us know what you find out. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From abez at abez.ca Tue Feb 10 01:53:12 2004 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] Perl for the Wireless????? In-Reply-To: <5.2.1.1.2.20040209233537.00b46db8@shell2.webquarry.com> Message-ID: http://www.rainer-keuchel.de/software.html Perl for WINCE List of Ports: http://search.cpan.org/~jhi/perl-5.8.0/pod/perlport.pod WinCE perl. http://perlce.sourceforge.net/ Nokia previously stated support for perl then sorta retracted it. A lot of the hardware is pretty closed so it's up to the manufacturer to provide the language support :p abram On Mon, 9 Feb 2004, Peter Scott wrote: > At 11:26 PM 2/9/2004 -0800, Jeremy Aiyadurai wrote: > > >is there such a thing as wireless perl? (like wireless java). Suppose > >I wanna write a program for a cell phone? > >are there any developements considering this? > > I haven't heard of such a thing. A search for "embedding" and "perl" > may help. As might the Cozens/Jenness book. Let us know what you find out. > > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From jeremygwa at hotmail.com Wed Feb 11 01:05:19 2004 From: jeremygwa at hotmail.com (Jeremy Aiyadurai) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] deallocating memory of multi-threaded server while IDLE. Message-ID: Hi all, how do i free up memory when a multi-threaded process is idle. my problem is when ever i create a thread, it eats up more memory. when the thread is done, the thread disappears, but the memory is not freed (by looking at windows task manager). so i'd like to free up memory when the process is idle. thanks in advance for any help. Jeremy A. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca From darren at DarrenDuncan.net Wed Feb 11 01:58:26 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] deallocating memory of multi-threaded server while IDLE. In-Reply-To: Message-ID: On Tue, 10 Feb 2004, Jeremy Aiyadurai wrote: > how do i free up memory when a multi-threaded process is idle. > my problem is when ever i create a thread, it eats up more memory. when the > thread is done, the thread disappears, but the memory is not freed (by > looking at windows task manager). > so i'd like to free up memory when the process is idle. > thanks in advance for any help. In my understanding, Perl itself has a limitation that, while it can reuse memory allocated to it, it can not or will never return any of its memory to the system (except when it exits). I don't think you can get around this, and it would affect every platform. I could be wrong, though, about the general limitation. (I also wouldn't be surprised if Parrot didn't have that limitation.) -- Darren Duncan From ef at kwinternet.com Wed Feb 11 09:38:38 2004 From: ef at kwinternet.com (Eric Frazier) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] deallocating memory of multi-threaded server while IDLE. In-Reply-To: References: Message-ID: <1076513920.450.9.camel@debian> Hi, Not that it matters that much, but I believe this is a OS level issue, not even Perl. Thanks, Eric On Tue, 2004-02-10 at 23:58, Darren Duncan wrote: > On Tue, 10 Feb 2004, Jeremy Aiyadurai wrote: > > how do i free up memory when a multi-threaded process is idle. > > my problem is when ever i create a thread, it eats up more memory. when the > > thread is done, the thread disappears, but the memory is not freed (by > > looking at windows task manager). > > so i'd like to free up memory when the process is idle. > > thanks in advance for any help. > > In my understanding, Perl itself has a limitation that, while it can reuse > memory allocated to it, it can not or will never return any of its memory > to the system (except when it exits). I don't think you can get around > this, and it would affect every platform. I could be wrong, though, about > the general limitation. (I also wouldn't be surprised if Parrot didn't > have that limitation.) -- Darren Duncan From darren at DarrenDuncan.net Wed Feb 11 13:30:46 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] deallocating memory of multi-threaded server while IDLE. In-Reply-To: <1076513920.450.9.camel@debian> References: <1076513920.450.9.camel@debian> Message-ID: At 7:38 AM -0800 2/11/04, Eric Frazier wrote: >Hi, >Not that it matters that much, but I believe this is a OS level issue, >not even Perl. >Thanks, >Eric My understanding is that other applications can return memory to the system while they are running, in which case the OS supports it. -- Darren Duncan From ef at kwinternet.com Wed Feb 11 13:39:07 2004 From: ef at kwinternet.com (Eric) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] deallocating memory of multi-threaded server while IDLE. In-Reply-To: References: <1076513920.450.9.camel@debian> Message-ID: <6.0.0.22.0.20040211113622.027aac40@mail.kwinternet.com> Hi, I don't have time to dig up the exact quote. But that is not the case. I can't remember if it was in advanced perl or the Camel book that talked about this. It might have been perltoot or another man page too. Wish I could remember. Thanks, Eric At 11:30 AM 2/11/2004, Darren Duncan wrote: >At 7:38 AM -0800 2/11/04, Eric Frazier wrote: >>Hi, >>Not that it matters that much, but I believe this is a OS level issue, >>not even Perl. >>Thanks, >>Eric > >My understanding is that other applications can return memory to the system while they are running, in which case the OS supports it. -- Darren Duncan From Peter at PSDT.com Wed Feb 11 13:51:39 2004 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] deallocating memory of multi-threaded server while IDLE. In-Reply-To: <6.0.0.22.0.20040211113622.027aac40@mail.kwinternet.com> References: <1076513920.450.9.camel@debian> Message-ID: <5.2.1.1.2.20040211115041.01884d68@shell2.webquarry.com> At 11:39 AM 2/11/2004 -0800, Eric wrote: >Hi, > >I don't have time to dig up the exact quote. But that is not the >case. I can't remember if it was in advanced perl or the Camel book >that talked about this. It might have been perltoot or another man >page too. Wish I could remember. On Unix and variants, a process never decreases its memory footprint. Once you allocate memory it is unavailable to other processes until the process terminates. >At 11:30 AM 2/11/2004, Darren Duncan wrote: > >At 7:38 AM -0800 2/11/04, Eric Frazier wrote: > >>Hi, > >>Not that it matters that much, but I believe this is a OS level issue, > >>not even Perl. > >>Thanks, > >>Eric > > > >My understanding is that other applications can return memory to the > system while they are running, in which case the OS supports it. -- > Darren Duncan -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From ef at kwinternet.com Wed Feb 11 14:13:11 2004 From: ef at kwinternet.com (Eric) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] deallocating memory of multi-threaded server while IDLE. In-Reply-To: <5.2.1.1.2.20040211115041.01884d68@shell2.webquarry.com> References: <1076513920.450.9.camel@debian> <5.2.1.1.2.20040211115041.01884d68@shell2.webquarry.com> Message-ID: <6.0.0.22.0.20040211120721.026c9678@mail.kwinternet.com> Peter, Is this more connected with the Kernel or with POSIX compliance? I know that the Kernel is responsible for supporting/implementing POSIX, but is it the support of POSIX that causes the problem or is it a not related Kernel issue? I wonder because I have heard that same phrase in reference to this discussion before about "Unix and its variants" Common thread that I know of in that case is POSIX Thanks, Eric At 11:51 AM 2/11/2004, Peter Scott wrote: >At 11:39 AM 2/11/2004 -0800, Eric wrote: >>Hi, >> >>I don't have time to dig up the exact quote. But that is not the case. I can't remember if it was in advanced perl or the Camel book that talked about this. It might have been perltoot or another man page too. Wish I could remember. > >On Unix and variants, a process never decreases its memory footprint. Once you allocate memory it is unavailable to other processes until the process terminates. > >>At 11:30 AM 2/11/2004, Darren Duncan wrote: >>>At 7:38 AM -0800 2/11/04, Eric Frazier wrote: >>>>Hi, >>>>Not that it matters that much, but I believe this is a OS level issue, >>>>not even Perl. >>>>Thanks, >>>>Eric >>> >>>My understanding is that other applications can return memory to the system while they are running, in which case the OS supports it. -- Darren Duncan > >-- >Peter Scott >Pacific Systems Design Technologies >http://www.perldebugged.com/ >*** New! *** http://www.perlmedic.com/ From abez at abez.ca Wed Feb 11 14:27:04 2004 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] deallocating memory of multi-threaded server while IDLE. In-Reply-To: <6.0.0.22.0.20040211120721.026c9678@mail.kwinternet.com> Message-ID: You really should test the behaviour. The task managers et al. are not very reliable to actually tell if you're going to run out of memory. I suggest turning off swap and then seeing how many processes w/ their threads you can add. Add processes when it looks like there is no memory left. The OS will probably come by and reclaim some memory from the other processes. abram On Wed, 11 Feb 2004, Eric wrote: > Peter, > > Is this more connected with the Kernel or with POSIX compliance? I know that the Kernel is responsible for supporting/implementing POSIX, but is it the support of POSIX that causes the problem or is it > a not related Kernel issue? I wonder because I have heard that same phrase in reference to this discussion before about "Unix and its variants" Common thread that I know of in that case is POSIX > > > Thanks, > > Eric > > At 11:51 AM 2/11/2004, Peter Scott wrote: > >At 11:39 AM 2/11/2004 -0800, Eric wrote: > >>Hi, > >> > >>I don't have time to dig up the exact quote. But that is not the case. I can't remember if it was in advanced perl or the Camel book that talked about this. It might have been perltoot or another man page too. Wish I could remember. > > > >On Unix and variants, a process never decreases its memory footprint. Once you allocate memory it is unavailable to other processes until the process terminates. > > > >>At 11:30 AM 2/11/2004, Darren Duncan wrote: > >>>At 7:38 AM -0800 2/11/04, Eric Frazier wrote: > >>>>Hi, > >>>>Not that it matters that much, but I believe this is a OS level issue, > >>>>not even Perl. > >>>>Thanks, > >>>>Eric > >>> > >>>My understanding is that other applications can return memory to the system while they are running, in which case the OS supports it. -- Darren Duncan > > > >-- > >Peter Scott > >Pacific Systems Design Technologies > >http://www.perldebugged.com/ > >*** New! *** http://www.perlmedic.com/ > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From Peter at PSDT.com Wed Feb 11 14:50:08 2004 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] deallocating memory of multi-threaded server while IDLE. In-Reply-To: References: <6.0.0.22.0.20040211120721.026c9678@mail.kwinternet.com> Message-ID: <5.2.1.1.2.20040211124254.01881158@shell2.webquarry.com> At 12:27 PM 2/11/2004 -0800, abez wrote: >You really should test the behaviour. The task managers et al. are not >very reliable to actually tell if you're going to run out of memory. >I suggest turning off swap and then seeing how many processes w/ their >threads you can add. > >Add processes when it looks like there is no memory left. The OS will >probably come by and reclaim some memory from the other processes. Real memory, right? The virtual memory allocation can't go down, can it? >abram > >On Wed, 11 Feb 2004, Eric wrote: > > > Peter, > > > > Is this more connected with the Kernel or with POSIX compliance? I > know that the Kernel is responsible for supporting/implementing > POSIX, but is it the support of POSIX that causes the problem or is it > > a not related Kernel issue? I wonder because I have heard that > same phrase in reference to this discussion before about "Unix and > its variants" Common thread that I know of in that case is POSIX My understanding was that it was just the way things were commonly implemented. Stevens in APUE says "Although sbrk can expand or contract the memory of a process, most versions of malloc and free never decrease their memory size. The space that we free is available for a later allocation, but the freed space is not returned to the kernel - it is kept in the malloc pool." Hmm. I guess a better memory management library could decrease process footprint... -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From abez at abez.ca Fri Feb 13 19:04:29 2004 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] perl segfault Message-ID: My supervisor (Dr. German) stumbled across a perl segfault. I determined what it was. He was printf'ing a string that contained the substring %ve If you type at the commandline perl -e "printf '%ve'"; echo $? You will notice the program segfaults and returns with code 139 (interesting enough this is the netbios/samba port). I've determined it's the printf trying to print a double which doesn't exist and isn't a double. It doesn't sound very serious but imagine you use a printf in a web app and the user types in a %ve.. So if you could test this in your versions it'd be nice. My interpretter is as follows: Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.21-1.1931.2.382.entsmp, archname=i386-linux-thread-multi uname='linux str' config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef' useithreads=define usemultiplicity= useperlio= d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=un uselongdouble= usemymalloc=, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)', gccosandvers='' gccversion='3.2.2 200302' intsize=r, longsize=r, ptrsize=5, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long' k', ivsize=4' ivtype='l, nvtype='double' o_nonbl', nvsize=, Off_t='', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='gcc' l', ldflags =' -L/u' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil perllibs= libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libper gnulibc_version='2.3.2' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so', d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE' cccdlflags='-fPIC' ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5', lddlflags='s Unicode/Normalize XS/A' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: MAINT18379 Built under linux Compiled at Aug 13 2003 11:47:58 @INC: /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 . -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From yf110 at victoria.tc.ca Fri Feb 13 19:36:20 2004 From: yf110 at victoria.tc.ca (Malcolm Dew-Jones) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] perl segfault In-Reply-To: References: Message-ID: On Fri, 13 Feb 2004, abez wrote: > > If you type at the commandline > perl -e "printf '%ve'"; echo $? %ve ? I don't seem to be able to use %ve in printf in perl on two different platforms. Is this a typo? > You will notice the program segfaults and returns with code 139 > (interesting enough this is the netbios/samba port). > > I've determined it's the printf trying to print a double which doesn't > exist and isn't a double. > > It doesn't sound very serious but imagine you use a printf in a web app > and the user types in a %ve.. But the user should never be entering the %ve in the first place. That is part of your code, not the data that a user would ever normally be allowed to enter (at least not without proper value and taint checking before you used it). You have asked printf to format one variable but then you didn't pass it (at least) one variable, which is a bug. If your code had passed a variable to printf then everything would have worked ok no matter what the value of that variable happened to be. (I have used %e here cause %ve does nothing for me) e.g. perl -e "my $printf '%e',undef" # pass in undef 0.000000e+000 perl -e "my $printf '%e',''" # pass in empty string 0.000000e+000 perl -e "my $printf '%e',1" # pass in a number 1.000000e+000 perl -e "printf '%e',\my %var" # pass a variable reference! 3.775808e+006 From abez at abez.ca Fri Feb 13 19:58:53 2004 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] perl segfault In-Reply-To: Message-ID: On Fri, 13 Feb 2004, Malcolm Dew-Jones wrote: > %ve ? I don't seem to be able to use %ve in printf in perl on two > different platforms. Is this a typo? A. What platform are you using? B. Try running this: perl -e "printf('%ve'); print 'Done',$/"; If you don't see Done.. Something is wrong. It could be you aren't seeing anything because the program has already crashed. > But the user should never be entering the %ve in the first place. That is > part of your code, not the data that a user would ever normally be allowed > to enter (at least not without proper value and taint checking before you > used it). Imagine in some code we have print "$floatingvalue:$uservalue$/"; Imagine the boss asks us to only print 2 decimal placeS? print "%.02f:$uservalue$/",$floatingvalue; The user enters in "%ve". > If your code had passed a variable to printf then everything would have > worked ok no matter what the value of that variable happened to be. The point is what could happen by accident. Your perl interpretter is supposed to protect you from certain things like segfaults for the simple operations. Interestingly enough perl -e "printf('%ve',2.2); print 'Done',$/"; #works perl -e "printf('%ve'); print 'Done',$/"; #doesn't perl -e "printf('%.02f %ve',2.2); print 'Done',$/"; #doesn't perl -e "printf('%.02f %ve',2.2,undef); print 'Done',$/"; #works I would gather that the %*e makes it look for another arguement on the printf arg stack. But it doesn't do proper checking (it's not there) and thus it seg faults. -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From Peter at PSDT.com Fri Feb 13 21:42:50 2004 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] perl segfault In-Reply-To: Message-ID: <5.2.1.1.2.20040213193729.00b949f8@shell2.webquarry.com> [BTW, are we meeting this month, and when? Darren?] At 05:04 PM 2/13/2004 -0800, abez wrote: >My supervisor (Dr. German) stumbled across a perl segfault. I >determined what it was. > >He was printf'ing a string that contained the substring %ve > >If you type at the commandline >perl -e "printf '%ve'"; echo $? > >You will notice the program segfaults and returns with code 139 >(interesting enough this is the netbios/samba port). > >I've determined it's the printf trying to print a double which doesn't >exist and isn't a double. > >It doesn't sound very serious but imagine you use a printf in a web app >and the user types in a %ve.. > >So if you could test this in your versions it'd be nice. 5.6.1 on Solaris: % perl -e 'printf "%ve"; print "\n"'; echo $status 0.000000e+00 0 5.8.1 on Fedora core: $ perl -e 'printf "%ve"; print "\n"'; echo $status Segmentation fault (core dumped) 139 5.6.0 on Fedora core: $ ./perl -e 'printf "%ve"; print "\n"' ; echo $status0.000000e+00 0 perl 5.8.3 on Fedora core: $ ./perl -e 'printf "%ve"; print "\n"' ; echo $status Segmentation fault (core dumped) 139 Fairly recent bleadperl on Fedora core: $ ./perl -e 'printf "%ve"; print "\n"' ; echo $status Segmentation fault (core dumped) 139 I think you've found a bug... go ahead and dust off perlbug and claim the honour and glory... -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From abez at abez.ca Fri Feb 13 22:02:57 2004 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] perl segfault In-Reply-To: <5.2.1.1.2.20040213193729.00b949f8@shell2.webquarry.com> Message-ID: Ok I sent the report in, quoted a bunch of emails etc. abram On Fri, 13 Feb 2004, Peter Scott wrote: > [BTW, are we meeting this month, and when? Darren?] > > At 05:04 PM 2/13/2004 -0800, abez wrote: > >My supervisor (Dr. German) stumbled across a perl segfault. I > >determined what it was. > > > >He was printf'ing a string that contained the substring %ve > > > >If you type at the commandline > >perl -e "printf '%ve'"; echo $? > > > >You will notice the program segfaults and returns with code 139 > >(interesting enough this is the netbios/samba port). > > > >I've determined it's the printf trying to print a double which doesn't > >exist and isn't a double. > > > >It doesn't sound very serious but imagine you use a printf in a web app > >and the user types in a %ve.. > > > >So if you could test this in your versions it'd be nice. > > 5.6.1 on Solaris: > > % perl -e 'printf "%ve"; print "\n"'; echo $status > 0.000000e+00 > 0 > > 5.8.1 on Fedora core: > $ perl -e 'printf "%ve"; print "\n"'; echo $status > Segmentation fault (core dumped) > 139 > > 5.6.0 on Fedora core: > $ ./perl -e 'printf "%ve"; print "\n"' ; echo $status0.000000e+00 > 0 > > perl 5.8.3 on Fedora core: > $ ./perl -e 'printf "%ve"; print "\n"' ; echo $status > Segmentation fault (core dumped) > 139 > > Fairly recent bleadperl on Fedora core: > $ ./perl -e 'printf "%ve"; print "\n"' ; echo $status > Segmentation fault (core dumped) > 139 > > > I think you've found a bug... go ahead and dust off perlbug and claim > the honour and glory... > > > -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From abez at abez.ca Mon Feb 16 17:33:27 2004 From: abez at abez.ca (abez) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] ROom Booked Message-ID: The next meeting should be held at: Tue 24FEB04 7:00pm- 9:00pm Cntr for Innovative Teach 120 abram -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From darren at DarrenDuncan.net Mon Feb 16 17:59:30 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] ROom Booked, and this week's plans In-Reply-To: References: Message-ID: At 3:33 PM -0800 2/16/04, abez wrote: >The next meeting should be held at: >Tue 24FEB04 >7:00pm- 9:00pm Cntr for Innovative Teach 120 >abram I'll mark that on my calendar. Incidentally, I posted Rosetta-0.23 very late (3:30am) on last Thursday night, which mostly straightens out some of the design hard work that I had to do. The release I am currently working on, 24, should actually be functional in regards to doing work with some databases. I plan to have it posted before the end of this week so that any of you eager beavers can play with it prior to the group meeting. Note that this version should/may support all of the following to some extent: - Oracle 8 or 9 - SQLite 2.8.12 - PostgreSQL 7.4 - MySQL 4.x/5.x (and maybe 3.23.x) - OpenBase 8.0 Those are ones that either I have some detail of knowledge of, or have used extensively before on another computer, or that I can install easily on my computer. Those will be improved and others added in later releases. That said, its very possible that SQLite will be the only one I have actually *tested* it with, as that is by far the easiest one to install: - Install Perl (5.8.3 for me) - Install DBI (1.40 for me) - Install DBD::SQLite (0.31 for me) - that's it; the actual database is embedded in the DBD, works without any setup -- Darren Duncan From Peter at PSDT.com Wed Feb 18 08:42:00 2004 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] Victoria Perl Mongers meeting Tue 24th Message-ID: <5.2.1.1.2.20040216184013.00b62438@shell2.webquarry.com> Victoria.pm will meet next on Tuesday, February 24th, 7pm, at UVic. Abram reserved CIT 120 as usual; email if you don't know how to get there. Darren Duncan will talk about "Using SQL databases with Perl": Database management is the oldest and most common use for computers besides mathematics, going back to the US census in the late 1800s. Since the late 1970s, we commonly organize computer databases as multiple sets / tables of data that are related to each other, and since the late 1980s we most often use a powerful 4th level programming language called SQL to easily manipulate these databases, and issue powerful but simple queries. Perl provides a very mature and popular module, called DBI (see http://dbi.perl.org), that lets any of your Perl programs talk to SQL databases with minimal effort. This talk will discuss things like when it is a good idea to use (or not use) a database in your program, and how (in detail) to do some common database tasks in Perl using DBI. This talk will also discuss new and upcoming advances in the field, such as using databases with Parrot (see http://www.nntp.perl.org/group/perl.dbdi.dev), and my own free project to vastly improve portability of applications between different SQL databases (see http://search.cpan.org/dist/Rosetta). Other topics to be covered as time permits; make requests for anything particular. There will be a book giveaway by the usual method; Darren will bring a copy of Nitrozac and Snaggy's "The Best of the Joy of Tech" (http://joyoftech.com/geekculturestore/webstore/bestofjoybook.html), signed and inscripted by the artists "To the Victoria Perl Mongers". (Courtesy copy to VLUG members by permission of the list manager. Victoria.pm's home page is .) -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From Peter at PSDT.com Mon Feb 23 08:43:00 2004 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] Victoria Perl Mongers meeting tomorrow Message-ID: <5.2.1.1.2.20040216184307.00b4cda8@shell2.webquarry.com> Victoria.pm will meet next tomorrow, Tuesday, February 24th, 7pm, at UVic. Abram reserved CIT 120 as usual; email if you don't know how to get there. Darren Duncan will talk about "Using SQL databases with Perl": Database management is the oldest and most common use for computers besides mathematics, going back to the US census in the late 1800s. Since the late 1970s, we commonly organize computer databases as multiple sets / tables of data that are related to each other, and since the late 1980s we most often use a powerful 4th level programming language called SQL to easily manipulate these databases, and issue powerful but simple queries. Perl provides a very mature and popular module, called DBI (see http://dbi.perl.org), that lets any of your Perl programs talk to SQL databases with minimal effort. This talk will discuss things like when it is a good idea to use (or not use) a database in your program, and how (in detail) to do some common database tasks in Perl using DBI. This talk will also discuss new and upcoming advances in the field, such as using databases with Parrot (see http://www.nntp.perl.org/group/perl.dbdi.dev), and my own free project to vastly improve portability of applications between different SQL databases (see http://search.cpan.org/dist/Rosetta). Other topics to be covered as time permits; make requests for anything particular. There will be a book giveaway by the usual method; Darren will bring a copy of Nitrozac and Snaggy's "The Best of the Joy of Tech" (http://joyoftech.com/geekculturestore/webstore/bestofjoybook.html), signed and inscripted by the artists "To the Victoria Perl Mongers". (Courtesy copy to VLUG members by permission of the list manager. Victoria.pm's home page is .) -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From Peter at PSDT.com Wed Feb 25 15:23:57 2004 From: Peter at PSDT.com (Peter Scott) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] Regular meeting schedule Message-ID: <5.2.1.1.2.20040225132214.019ec5d0@shell2.webquarry.com> At last night's meeting there was discussion around the issue of having a regular day for meetings and the third Tuesday of each month appeared most agreeable to those present. Comments? -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From darren at DarrenDuncan.net Wed Feb 25 16:12:03 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] Regular meeting schedule In-Reply-To: <5.2.1.1.2.20040225132214.019ec5d0@shell2.webquarry.com> References: <5.2.1.1.2.20040225132214.019ec5d0@shell2.webquarry.com> Message-ID: At 1:23 PM -0800 2/25/04, Peter Scott wrote: >At last night's meeting there was discussion around the issue of >having a regular day for meetings and the third Tuesday of each >month appeared most agreeable to those present. Comments? Aside from the very slight chance that a fixed date could lead to an unfixable conflict with some other unmovable event, I would say that this is a great idea. Third tuesday of each month sounds good. And a regular day makes VPM look more professional, and easier for potential members to schedule in advance for. -- Darren Duncan From darren at DarrenDuncan.net Sun Feb 29 15:48:40 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Wed Aug 4 00:11:31 2004 Subject: [VPM] Parrot 0.1.0 Released Message-ID: For those of you not otherwise aware, Parrot 0.1.0 has been released on this special leap-year day of February 29th, 2004. The previous release, I believe, was 0.0.13 on October 31st last year. Parrot is, among other things, a multi-language runtime specializing in dynamic languages, such as Perl, Python, and Ruby, and is *the* environment for Perl 6. This project has a very big future ahead of it, and is even used in a few production environments now. More info below. -- Darren Duncan The forwarded message: >Date: Sun, 29 Feb 2004 15:45:49 +0100 >From: Leopold Toetsch >To: P6I >Cc: P6L , perl6-announce@perl.org, > perl5-porters@perl.org >Subject: Parrot 0.1.0 Released > >Parrot 0.1.0 "Leaping Kakapo" Released! > >The Parrot team proudly presents the Parrot 0.1.0 leap release. It >provides some milestones like objects and multi-threading1[1] and >supports many more platforms. > >After some pause you can grab it from > or >just get the latest and best from CVS by following the directions at >. > >Turn your web browser towards for more >information about Parrot, get involved, and: > >Have fun! >leo > >[1] The list of changes includes: > > - "Ladies and gentlemen, I give you... objects!" > - Huge documentation overhaul > - More supported platforms, s. PLATFORMS > - Basic thread support for pthread based architectures > - Basic event handling for timers and signals including: > - PASM callbacks for NCI (native C) functions. > - Improved platform configuration > - COW stacks now working, stacks code redone > - Structure handling vastly improved > - Random PMC and rand primitives > - Better subroutine call syntax in PIR > - Make PIR subroutines compliant with pdd03 > - Improved profiling (DOD, GC timings) > - Hash code improvements, incl. random key order support > - Experimental freeze/thaw code for some PMC types > - IO improvements for buffered layer and Win32 > - String iterators > - String bitwise vtables > - Many new opcodes > - Suppport for JIT, where malloced memory isn't executable > - Priority DOD scheme for objects that need timely destruction > - Improved byte code loading (e.g. onLoad functions) > - Language updates: forth, Perl6/P6C, m4 > - Libraries: Getopt_Long, SDL, Dumper, Sort > - new JAPH examples > - Unified imcc and parrot test handling > - Many new tests (make test reports 1386 tests) > - Numerous bug fixes