Re: [perl #41243] [TODO] Link on Win32 with Borland C++

[Steve Peters]

On Tue, Dec 16, 2008 at 12:20 PM, Ron Blaschke r...@rblasch.org wrote:
 Andrew Whitworth wrote:
 I'll pick up borland and play with it, although I won't get to it
 until the next cycle. I've got a really old version of Turbo C++ 4.52
 left over from school, and free versions of Turbo C++ Explorer are
 available for download. I don't promise any miracles, but at least I
 will be able to prove that some errors still exist or not.

 --Andrew Whitworth

 On Tue, Dec 16, 2008 at 12:49 AM, Will Coleda via RT
 parrotbug-follo...@parrotcode.org wrote:
 On Thu Jan 11 09:55:40 2007, stmpeters wrote:
 On Thu Jan 11 08:57:22 2007, coke wrote:
 Need details.
 A recent patch has gotten Parrot to the point that it can be compiled
 with Borland C++ on Win32.  Unfortunately, it does not link correctly to
 actually create a valid parrot executable.  Additional configuration is
 needed to make Borland compile and link Parrot so that it can actually
 be run and tested.
 Without a champion for this compiler, there's not much we can do; Our 
 current targets for
 Windows include, as I understand it, cygwin, strawberry perl and its build 
 system, and recent
 versions of VisualC++. Borland isn't in our core list for the upcoming 1.0 
 release.

 If we do find a Borland champion, they should open a new ticket at 
 https://trac.parrot.org/.

 Rejecting this ticket; Regards.

 Some time ago, because of this ticket, I tried with Borland C++ 5.5.1
 and 5.82, and failed miserably.  But that may just be my bad bcc-foo.
 Unless someone's keen for this platform and has access to a fairly new
 (within two years) version (is it called C++ Builder now?), I'm not
 sure if this is worth pursuing.

 Ron


The issue I ran into at the time was that dmake, which was the usual
make program used with bcc32, is not capable of handling the Parrot
make file.  I believe it could work with gmake on win32, but I hadn't
really attempted anything down that direction since I was encountering
too many other issues following a major restructuring of the headers
that had occurred.

Steve

Re: [perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris

[Steve Peters]

Unfortunately, my changes to Perl 5 have been working better than my
changes to Parrot.  IIRC, the changes made fixed OpenBSD and NetBSD on
Parrot while Cygwin and Solaris didn't seem to fare as well.

Steve

On Thu, Jul 17, 2008 at 7:29 PM, Thorsten Glaser via RT
[EMAIL PROTECTED] wrote:
 On Wed Jul 16 10:33:06 2008, Whiteknight wrote:
 Is this still not resolved?

 On MirBSD (perl $^O 'mirbsd'), whose libm is about 85% NetBSD,
 15% OpenBSD, the Perl test succeeds.

 The following lines in perl/pp.c already trigger:
 38 /*
 39  * Some BSDs and Cygwin default to POSIX math instead of IEEE.
 40  * This switches them over to IEEE.
 41  */
 42 #if defined(LIBM_LIB_VERSION)
 43 _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;
 44 #endif

 I _suspect_ this would work on OpenBSD and NetBSD as well,
 but it's better to check with actual users of the system.
 I got this via IRC from a NetBSD developer:
 00:16│«replaced» $ perl -le'print atan2(-0.0,-0.0)'
 00:16│«replaced» -3.14159265358979

 This matches mine:
 [EMAIL PROTECTED]:~ $ perl -le'print atan2(-0.0,-0.0)'
 -3.14159265358979

 I think the bit less of precision is due to us trying to
 avoid the i387 issue of intermediate high precision (the
 FPCW is initialised to low precision by the kernel, which
 may be a good thing).

 bye,
 //mirabilos
 --
  Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL.
 -- Henry Nelson, March 1999

Re: [perl #37819] [PATCH] Sun4 builds fail linking against jit.o

[Steve Peters]

On Fri, Jun 6, 2008 at 8:12 AM, Andy Dougherty [EMAIL PROTECTED] wrote:
 On Thu, 5 Jun 2008, Will Coleda via RT wrote:

 On Tue May 15 14:54:01 2007, [EMAIL PROTECTED] wrote:
  On Wednesday 09 May 2007 07:21:44 Andy Dougherty wrote:
 
   [appending to an old ticket, since if anyone wants to ever get this
   working again, they'll probably have to fix up the blind guesses I
  made in
   that old patch too.]
 
  Thanks, applied as r18562 (er, oops -- r18561, due to an
  excruciatingly slow
  commit).
 
  -- c
 

 If the patch is applied, is this ticket safe to close now?

 No.  It's still the case that the sun4/SPARC jit is broken.  The patch
 just documented two things:  which specific function does not exist, and
 which other broken functions also need to be fixed.

 However, realistically, I don't think anyone's ever going to fix the SPARC
 jit, so you may certainly mark it as stalled or whatever else seems to
 suit.


Is it only sun4/SPARC that's broken or are all Solaris/SPARC's also
broken?  I would guess that if its all SPARCs, Linux or Solaris, that
this might be a bigger issue.

Steve Peters
[EMAIL PROTECTED]

Re: [perl #50956] Problems building in VS2008 with latest SVN tip

[Steve Peters]

.

 Determining whether (exuberant) ctags is installed..no.

 Determining Parrot's revision...r25835.

 Determining whether ICU is installedfailed.

 Generating C headers..done.

 Generating core pmc list..done.

 Generating runtime/parrot/include.done.

 Configuring languages.done.

 Generating makefiles and other build filesdone.

 Moving platform files into place..done.

 Recording configuration data for later retrieval..done.

 Okay, we're done!



 You can now use `nmake' to build your Parrot.

 After that, you can use `nmake test' to run the test suite.



 Happy Hacking,

 The Parrot Team





 C:\Prg\parrot-svnnmake



 Microsoft (R) Program Maintenance Utility Version 9.00.21022.08

 Copyright (C) Microsoft Corporation.  All rights reserved.



 Compiling with:

 xx.c

 cl -I.\include -nologo -GF -W4 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE
 -DNO_STRICT -

 DNO_HASH_SEED -DUSE_SITECUSTOMIZE -D_CRT_SECURE_NO_DEPRECATE
 -DHASATTRIBUTE_DEPR

 ECATED -wd4101 -DHASATTRIBUTE_NORETURN -wd4101 -Zi -wd4127 -wd4054 -wd4310
 -DHAS

 _JIT -DI386 -I. -Fo xx.obj -c xx.c

 src\string.c

 src\ops\core_ops.c

 c:\prg\parrot-svn\src\ops\object.ops(597) : warning C4702: unreachable code

 c:\prg\parrot-svn\src\ops\object.ops(602) : warning C4702: unreachable code

 c:\prg\parrot-svn\src\ops\object.ops(607) : warning C4702: unreachable code

 c:\prg\parrot-svn\src\ops\object.ops(612) : warning C4702: unreachable code

 c:\prg\parrot-svn\src\ops\object.ops(617) : warning C4702: unreachable code

 src\ops\core_ops_switch.c

 src\builtin.c

 src\charset.c

 src\core_pmcs.c

 src\cpu_dep.c

 src\debug.c

 c:\prg\parrot-svn\src\debug.c(986) : warning C4706: assignment within
 conditiona

 l expression

 src\dynext.c

 src\dynext.c(355) : warning C4055: 'type cast' : from data pointer 'void *'
 to f

 unction pointer 'PMC *(__cdecl *)(Parrot_Interp)'

 src\dynext.c(364) : warning C4055: 'type cast' : from data pointer 'void *'
 to f

 unction pointer 'void (__cdecl *)(Parrot_Interp,PMC *)'

 src\embed.c

 src\encoding.c

 src\events.c

 src\exceptions.c

 c:\prg\parrot-svn\src\exceptions.c(156) : warning C4702: unreachable code

 src\exit.c

 src\extend.c

 src\gc\dod.c

 src\gc\gc_gms.c

 src\gc\gc_ims.c

 src\gc\memory.c

 src\gc\register.c

 src\gc\smallobject.c

 src\global.c

 src\global_setup.c

 src\hash.c

 src\headers.c

 src\hll.c

 src\inter_call.c

 src\inter_cb.c

 src\inter_create.c

 src\inter_misc.c

 src\interpreter.c

 src\interpreter.c(655) : warning C4055: 'type cast' : from data pointer
 'void *'

  to function pointer 'jit_f'

 src\inter_run.c

 src\intlist.c

 src\key.c

 src\library.c

 src\list.c

 src\longopt.c

 src\misc.c

 src\mmd.c

 src\mmd.c(308) : warning C4055: 'type cast' : from data pointer 'DPOINTER *'
 to

 function pointer 'funcptr_t'

 src\nci.c

 src\nci.c(7089) : warning C4055: 'type cast' : from data pointer 'DPOINTER
 *' to

  function pointer 'funcptr_t'

 src\oo.c

 src\oo.c(221) : error C2375: 'Parrot_oo_get_class' : redefinition; different
 lin

 kage

 C:\Prg\parrot-svn\include\parrot/oo.h(237) : see declaration of
 'Parrot_

 oo_get_class'

 NMAKE : fatal error U1077: 'C:\Prg\ActivePerl\bin\perl.exe' : return code
 '0x2'

 Stop.



 C:\Prg\parrot-svn


Excellent!  A new Visual Studio version!  Is this the free version or
a paid-for version.  IIRC VS 2005 had some distinctions between the
two.

Steve Peters
[EMAIL PROTECTED]

[perl #49912] [BUG] Unable to Configure using Borland C

[Steve Peters via RT]

On Thu Jan 17 17:26:45 2008, [EMAIL PROTECTED] wrote:
 The following text shows the result of attempting to install Parrot
 using
 bcc32. The program appeared to hang at the Generating CPU specific
 stuff
 stage until killed.
 
 C:\parrotConfigure.pl --cc=bcc32
 Parrot Version 0.5.2 Configure 2.0
 Copyright (C) 2001-2007, The Perl Foundation.
 
 Hello, I'm Configure. My job is to poke and prod your system to figure
 out
 how to build Parrot. The process is completely automated, unless you
 passed in
 the `--ask' flag on the command line, in which case I'll prompt you
 for a few
 pieces of info.
 
 Since you're running this program, you obviously have Perl 5--I'll be
 pulling
 some defaults from its configuration.
 
 Checking
 MANIFEST.done.
 Setting up Configure's default
 values.done.
 Setting up installation
 paths.done.
 Tweaking settings for
 miniparrot...skipped.
 Loading platform and local hints
 filesdone.
 Finding header files distributed with
 Parrot..done.
 Determining what C compiler and linker to
 use.done.
 Determining whether make is
 installed..yes.
 Determining whether lex is
 installed...skipped.
 Determining whether yacc is
 installed..skipped.
 Determining if your C compiler is actually
 gcc..no.
 Determining whether libc has the backtrace* functions (glibc
 only)..no.
 Determining Fink location on
 Darwinskipped.
 Determining if your C compiler is actually Visual
 C++...no.
 Detecting compiler attributes (-
 DHASATTRIBUTE_xxx)done.
 Detecting supported compiler warnings (-
 Wxxx)..skipped.
 Enabling
 optimization...no.
 Determining flags for building shared
 libraries...done.
 Determine if parrot should be linked against a shared
 library...no.
 Determining what charset files should be compiled
 in..done.
 Determining what encoding files should be compiled
 in.done.
 Determining what types Parrot should
 use..done.
 Determining what opcode files should be compiled
 in...done.
 Determining what pmc files should be compiled
 in..done.
 Determining your minimum pointer alignment. 1
 byte.
 Probing for C
 headers.done.
 Determining some
 sizesdone.
 Computing native byteorder for Parrot's wordsize.little-
 endian.
 Test the type of va_ptr (this test is likely to
 segfault)stack.
 Figuring out how to pack() Parrot's
 types.done.
 Figuring out what formats should be used for
 sprintf..done.
 Determining if your C library has a working
 S_ISREGyes.
 Determining CPU architecture and
 OS...done.
 Determining architecture, OS and JIT
 capability...done.
 Generating CPU specific stuff...Terminating on signal SIGINT(2)
 

When using a non-default C compiler, you will usually need to add a
--link to the Configure line.  So, something like...

Configure.pl --cc=bcc32 --link=bcc32

should work.

Steve

Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config st

[Steve Peters]

On Dec 11, 2007 12:40 PM, Andy Dougherty [EMAIL PROTECTED] wrote:
 On Tue, 11 Dec 2007, Jim Keenan wrote:

  From: Andy Dougherty via RT
  Date: 2007/12/11 Tue AM 08:38:17 CST
  Subject: Re: [perl #48459] [PATCH]:   Refactor config/inter/progs.pm into 
  2 config steps
 
  
  I don't think this will work.  Specifically, to conduct a basic test of
  that compiler's functioning you need to compile *and link* a program, but
  you haven't picked a linker yet.
 
  Andy, that's what I thought at first, and you may well be correct.
 
  However, as I read the code in the current HEAD of
  config/inter/progs.pm, the *only* variable passed to the internal
  test_compiler subroutine is $cc (line 130).  $cc is assigned to much
  farther up inside the runstep() method (lines 61-62), and immediately
  thereafter assigned to the 'cc' argument in the Parrot::Configure object
  (line 63).  All the other values you mention are assigned between lines
  64 and 130, but, AFAICT, none of those assignments depend on either $cc
  or the value assigned to 'cc' inside the configuration object.  The
  test_compiler() method, *as written*, does not appear to depend at all
  on any of the other values located on the system or selected at the
  prompt, and it does not appear to depend on the Parrot::Configure
  object.  If so, then the refactoring I suggested is plausible.

 I think you're missing three things:

 1.  test_compiler() calls cc_build(), which most definitely does need to
 use $ccflags and $link.

 2.  The settings of things like ccflags and ldflags *could* depend on
 the compiler, even if the current inter/progs.pm file doesn't actually
 implement that.  Recognizing that some compilers are available on more
 than one platform, it makes sense to handle them in inter/progs.pm, not
 duplicate them in different hints files.  For now, though, such
 information is buried in various hints files.  For example, look at
 hints/linux.pm -- three different compilers are dealt with there.

 3.  Triggers (or callbacks) can change the flow in hidden ways.  For
 example, the solaris hints file sets the value of $link depending on
 whether the user is using cc or gcc.

  Of course, it may very well be that test_compiler() was misconceived all
  along and that it *should* have been passed the current state of the
  Parrot::Configure object ($conf).  What do you think?

 cc_build() consults the global $conf, and hence doesn't need it passed in.
 I would certainly agree that the flow of information isn't well controlled
 here.  Passing the object in sometimes and other times consulting the
 global object does seem like a recipe for confusion.  It might make sense
 to always do one or the other.

hints/linux.pm should really have separate flags for even g++, since
some warnings just don't work on g++.

I think it would be good if we could break out compilers separately
from the operating system.  This is especially useful for Sun Studio,
where ccflags cross operating systems.  Intel C tends to follow what
the primary system compilers, but it still runs on three distinct
operating system with some slight differences across the environments.

Steve Peters
[EMAIL PROTECTED]

Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC

[Steve Peters]

On Wed, Aug 22, 2007 at 04:11:38PM +0200, Paul Cochrane wrote:
  --- src/encoding.c.old  Wed Aug 22 08:15:22 2007
  +++ src/encoding.c  Wed Aug 22 08:15:58 2007
  @@ -105,6 +105,7 @@
   {
   UNUSED(encodingname);
   real_exception(interp, NULL, UNIMPLEMENTED, Can't load encodings 
  yet);
  +return NULL;
   }
 
   /*
  --- src/interpreter.c.old   Wed Aug 22 08:16:48 2007
  +++ src/interpreter.c   Wed Aug 22 08:17:39 2007
  @@ -692,6 +692,7 @@
   PIO_eprintf(interp,
   Computed goto unavailable in this configuration.\n);
   Parrot_exit(interp, 1);
  +return pc;
   #endif
   }
 
 
 I don't know if these two changes bring anything.  Neither function
 actually returns even though there is a return value expected, so the
 added code is actually dead code as it will never get executed.  The
 function real_exception() doesn't return, and we should be able to
 tell the compiler that (this is what Andy Lester has been doing a lot
 of with his recent function attribute work).  I'm guessing that suncc
 throws a warning here can be rectified in the fullness of time.
 
 Just my $0.02
 
 Paul

We can leave it out, but then we'll never be able to compile Parrot with 
Solaris CC.

Steve Peters
[EMAIL PROTECTED]

Re: [perl #44729] [PATCH] Various C++ cleanups

[Steve Peters]

On Fri, Aug 17, 2007 at 06:59:27AM -0700, Steve Peters wrote:
 # New Ticket Created by  Steve Peters 
 # Please include the string:  [perl #44729]
 # in the subject line of all future correspondence about this issue. 
 # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44729 
 
 
 The attached patch cleans up some problems with C++ compiling currently
 with Parrot.
 
 Steve Peters
 [EMAIL PROTECTED]

The changes to src/gc/smallobject.c seems to be causing some coredumps.  The
attached patch backs out that change and adds a few additional ones.

Enjoy!

Steve Peters
[EMAIL PROTECTED]
Index: src/stm/waitlist.c
===
--- src/stm/waitlist.c  (revision 20650)
+++ src/stm/waitlist.c  (working copy)
@@ -56,7 +56,7 @@
 
 if (!txlog-waitlist_data) {
 txlog-waitlist_data =
-mem_sys_allocate_zeroed(sizeof (*txlog-waitlist_data));
+(waitlist_thread_data*)mem_sys_allocate_zeroed(sizeof 
(*txlog-waitlist_data));
 MUTEX_INIT(txlog-waitlist_data-signal_mutex);
 txlog-waitlist_data-signal_cond = interp-thread_data-interp_cond;
 #if WAITLIST_DEBUG
@@ -84,12 +84,12 @@
 thr = get_thread(interp);
 
 if (!thr-entries) {
-thr-entries = mem_sys_allocate_zeroed(sizeof (*thr-entries) * 4);
+thr-entries = (waitlist_entry**)mem_sys_allocate_zeroed(sizeof 
(*thr-entries) * 4);
 thr-entry_count = 4;
 }
 
 if (thr-used_entries = thr-entry_count) {
-thr-entries = mem_sys_realloc_zeroed(thr-entries,
+thr-entries = (waitlist_entry**)mem_sys_realloc_zeroed(thr-entries,
 sizeof (*thr-entries) * thr-entry_count * 2,
 sizeof (*thr-entries) * thr-entry_count);
 thr-entry_count *= 2;
@@ -97,7 +97,7 @@
 
 i = thr-used_entries++;
 if (!thr-entries[i])
-thr-entries[i] = mem_sys_allocate_zeroed(sizeof (**thr-entries));
+thr-entries[i] = (waitlist_entry*)mem_sys_allocate_zeroed(sizeof 
(**thr-entries));
 
 PARROT_ASSERT(thr-entries[i]-head == NULL);
 PARROT_ASSERT(thr-entries[i]-next == NULL);
@@ -111,9 +111,11 @@
 add_entry(NOTNULL(STM_waitlist *waitlist), NOTNULL(struct waitlist_entry 
*entry))
 {
 int successp = -1;
+void *result;
 PARROT_ASSERT(entry-next == NULL);
 do {
-PARROT_ATOMIC_PTR_GET(entry-next, waitlist-first);
+PARROT_ATOMIC_PTR_GET(result, waitlist-first);
+entry-next = (waitlist_entry *)result;
 PARROT_ASSERT(successp != -1 || entry-next != entry);
 PARROT_ASSERT(entry-next != entry);
 PARROT_ATOMIC_PTR_CAS(successp, waitlist-first, entry-next, entry);
@@ -143,12 +145,14 @@
 waitlist_remove(STM_waitlist *waitlist, struct waitlist_entry *what)
 {
 struct waitlist_entry *cur;
+void *result;
 
 if (!waitlist)
 return;
 
 LOCK(waitlist-remove_mutex);
-PARROT_ATOMIC_PTR_GET(cur, waitlist-first);
+PARROT_ATOMIC_PTR_GET(result, waitlist-first);
+cur = (waitlist_entry *)result;
 
 /* if we became the first entry while we were acquiring the mutex */
 while (cur == what) {
@@ -158,7 +162,8 @@
 what-next = NULL;
 return;
 }
-PARROT_ATOMIC_PTR_GET(cur, waitlist-first);
+PARROT_ATOMIC_PTR_GET(result, waitlist-first);
+cur = (waitlist_entry *)result;
 }
 
 if (!cur) {
@@ -225,11 +230,13 @@
 {
 int successp;
 struct waitlist_entry *cur;
+void *result;
 
 /* make sure we are not interrupted by a concurrent removal */
 LOCK(list-remove_mutex);
 do {
-PARROT_ATOMIC_PTR_GET(cur, list-first);
+PARROT_ATOMIC_PTR_GET(result, list-first);
+cur = (waitlist_entry *)result;
 PARROT_ATOMIC_PTR_CAS(successp, list-first, cur, NULL);
 } while (!successp);
 
Index: src/pbc_merge.c
===
--- src/pbc_merge.c (revision 20650)
+++ src/pbc_merge.c (working copy)
@@ -175,7 +175,7 @@
 str_dup(NOTNULL(const char *old))
 {
 const size_t bytes = strlen(old) + 1;
-char * const copy = mem_sys_allocate(bytes);
+char * const copy = (char *)mem_sys_allocate(bytes);
 memcpy(copy, old, bytes);
 #ifdef MEMDEBUG
 debug(interp, 1,line %d str_dup %s [%x]\n, line, old, copy);
Index: src/gc/register.c
===
--- src/gc/register.c   (revision 20650)
+++ src/gc/register.c   (working copy)
@@ -298,7 +298,7 @@
 CONTEXT(interp-ctx) = ctx;
 
 ctx-regs_mem_size  = reg_alloc;
-ctx-n_regs_used= mem_sys_allocate(sizeof (INTVAL) * 4);
+ctx-n_regs_used= (INTVAL *)mem_sys_allocate(sizeof (INTVAL) * 
4);
 ctx-n_regs_used[REGNO_INT] = old-n_regs_used[REGNO_INT];
 ctx-n_regs_used[REGNO_NUM] = old-n_regs_used[REGNO_NUM];
 ctx-n_regs_used[REGNO_STR] = old-n_regs_used[REGNO_STR];
@@ -395,7 +395,7 @@
 const intslot

Re: Building with icc

[Steve Peters]

On Thu, Jun 07, 2007 at 12:19:57AM -0500, Andy Lester wrote:
 Anyone out there using the Intel compiler?
 
 How are you running Configure.pl?
 
 

perl Configure.pl --cc=icc --link=icc --ld=icc

Steve Peters
[EMAIL PROTECTED]

Re: SET_NULL

[Steve Peters]

On Fri, Jun 01, 2007 at 07:53:35PM -0500, Andy Lester wrote:
 From include/parrot/parrot.h:
 
 /* weird architectures might need this, s. C-FAQ 5.17
 *
 * the SET_NULL macros are only for system, where a NULL pointer
 * isn't represented by zeroes, so don't use these, for resetting
 * non-null pointers
 */
 
 #ifdef HAS_NON_ZERO_NULL
 #  define SET_NULL(x) x = NULL
 #  define SET_NULL_P(x, s) x = (s)NULL
 #else
 #  define SET_NULL(x)
 #  define SET_NULL_P(x, s)
 #endif /* HAS_NON_ZERO_NULL */
 
 
 This seems very wrong.  SET_NULL() isn't actually setting any values  
 if not HAS_NON_ZERO_NULL.  Is there some reason it's not actually
 
 #  define SET_NULL(x)  x = 0
 #  define SET_NULL_P(x, s) x = (s)NULL
 
 And for that matter, what's wrong with just using x = NULL  
 everywhere?  Why do we need a macro to do this?
 

I can't see any need for such a macro other than for the minor obfuscation
that it allows.  For most of the Parrot code, I haven't SET_NULL() used, and
I haven't used it myself.  I'm a bit curious how much it is actually used.


Steve Peters
[EMAIL PROTECTED]

Re: Coverage analysis for tests of configuration and build tools

[Steve Peters]

On Thu, May 10, 2007 at 04:50:56AM -0400, James E Keenan wrote:
 The results of a recent run of Devel::Cover along with the tests run 
 with the patch submitted in 
 http://rt.perl.org/rt3/Ticket/Display.html?id=42690 may be seen here:
 http://thenceforward.net/parrot/coverage/configure-build/coverage.html
 

Is there a gcov Makefile target?  I'd be more interested in seeing how
much of Parrot is being tested.

Steve Peters
[EMAIL PROTECTED]

Re: [svn:parrot] r18369 - in trunk: config/gen/platform/cygwin config/gen/platform/generic config/gen/platform/netbsd config/gen/platform/openbsd config/gen/platform/solaris src src/jit/ppc src/jit/su

[Steve Peters]

On Tue, May 01, 2007 at 10:52:19PM +0100, Nicholas Clark wrote:
  Date: Tue May  1 06:29:35 2007
  New Revision: 18369
  
  Modified:
 
 trunk/src/malloc.c
 
  Modified: trunk/src/malloc.c
  ==
 
 [3168 lines of diff]
 
 Given that that file starts:
 
 /*
   This is a version (aka dlmalloc) of malloc/free/realloc written by
   Doug Lea and released to the public domain.  Use, modify, and
   redistribute this code without permission or acknowledgment in any
   way you wish.  Send questions, comments, complaints, performance
   data, etc to [EMAIL PROTECTED]
 
 
 possibly it should be exempt from coding standards.
 
 Also, did it have any local modifications?
 And why does Parrot needs its own malloc?
 

According to our file, our version in 2.7.2.  The current free version is
2.8.3.  Obviously, if we need to keep this file, we should get up to the 
most recent version.  I wouldn't however, mess with it much to make it 
pass coding standards, since that would make it much more difficult to 
patch to keep up to date with the original.

Steve Peters
[EMAIL PROTECTED]

[perl #42795] [PATCH] NULL function pointer should be a pointer

[Steve Peters]

# New Ticket Created by  Steve Peters 
# Please include the string:  [perl #42795]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42795 


Index: lib/Parrot/Ops2c/Utils.pm
==
--- lib/Parrot/Ops2c/Utils.pm   (revision 18354)
+++ lib/Parrot/Ops2c/Utils.pm   (working copy)
@@ -680,7 +680,7 @@
 print $fh @{ $self-{op_func_table} };

 print $fh END_C;
-  (op_func$self-{suffix}_t)0  /* NULL function pointer */
+  (op_func$self-{suffix}_t *)0  /* NULL function pointer */
 };

[perl #41898] Build error with icc

[Steve Peters via RT]

On Sun Mar 18 12:21:18 2007, ptc wrote:
 I don't know if this is a BUG or what so I'm just sending it plain.
 I've just tried to build parrot with icc (not 100% sure if my build
 flags are correct either), and I'm getting this build error:
 
 icc -o miniparrot compilers/imcc/main.o \
 -Wl,-rpath=/home/cochrane/sourceforge/parrot_svn/blib/lib
 -L/home/cochrane/sourceforge/parrot_svn/blib/lib -lparrot -lpthread
 -lm -L/usr/lib  -licuuc -licudata -lpthread -lm -lpthread -lnsl -ldl
 -lm -lcrypt -lutil -lrt -lgmp -lreadline -lncurses -L/usr/local/lib
 src/null_config.o
 Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross
 your fingers
 ./miniparrot config_lib.pasm  runtime/parrot/include/config.fpmc
 miniparrot: src/mmd.c:1707: Assertion
 `((UINTVAL)(mmd_table[i].func_ptr)  3) == 0' failed.
 /bin/sh: line 1: 30223 Aborted ./miniparrot
 config_lib.pasm  runtime/parrot/include/config.fpmc
 make: *** [runtime/parrot/include/config.fpmc] Error 134
 
 Naive configure settings were (comments welcome as to what I might
 have done wrong here):
 
 perl Configure.pl --cc=icc --cxx=icc --ld=icc
 
 Any ideas as to what is going wrong here?
 

This has been resolved with the patches applied as r18347.

Re: [perl #42768] [PATCH] Enum cleanups

[Steve Peters]

On Fri, Apr 27, 2007 at 09:22:22AM -0700, Steve Peters wrote:
 # New Ticket Created by  Steve Peters 
 # Please include the string:  [perl #42768]
 # in the subject line of all future correspondence about this issue. 
 # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42768 
 
 
 Intel C++ complains very loudly using enum types in variable and parameter
 declarations. This patch helps to clean them up.
 

The attached additional patch fixes one problem caused by the previous
patch and gets Intel C++ to compile and pass all of its tests on 
Linux.  Only apply the attached patch after applying the first patch.

Steve Peters
[EMAIL PROTECTED]
Index: src/embed.c
===
--- src/embed.c (revision 18345)
+++ src/embed.c (working copy)
@@ -150,7 +150,7 @@
 
 /*
 
-=item Cvoid Parrot_clear_flag(Interp *, Parrot_Interp_flag flag)
+=item Cvoid Parrot_clear_flag(Interp *, Parrot_Int flag)
 
 =item Cvoid Parrot_clear_debug(Interp *, UINTVAL flag)
 
Index: src/pmc/role.pmc
===
--- src/pmc/role.pmc(revision 18345)
+++ src/pmc/role.pmc(working copy)
@@ -306,11 +306,9 @@
 PMC *new_attribute = pmc_new(interp, enum_class_Hash);
 
 /* Set name and type. */
-VTABLE_set_string_keyed_str(interp, new_attribute,
-CONST_STRING(interp, name), name);
+VTABLE_set_string_keyed_str(interp, new_attribute, 
CONST_STRING(interp, name), name);
 if (!PMC_IS_NULL(type)) {
-VTABLE_set_pmc_keyed_str(interp, new_attribute,
-CONST_STRING(interp, type), type);
+VTABLE_set_pmc_keyed_str(interp, new_attribute, 
CONST_STRING(interp, type), type);
 }
 
 /* Enter the attribute in the attributes array. */
@@ -483,8 +481,7 @@
 /* We'll build a hash just containing the name, then give this to
  * init_role_from_hash - saves some code duplication. */
 PMC *naming_hash = pmc_new(interp, enum_class_Hash);
-VTABLE_set_string_keyed_str(interp, naming_hash,
-CONST_STRING(interp, name), name);
+VTABLE_set_string_keyed_str(interp, naming_hash, 
CONST_STRING(interp, name), name);
 init_role_from_hash(interp, SELF, naming_hash);
 }
 
@@ -523,8 +520,7 @@
 
 */
 PCCMETHOD void attributes() {
-PMC *ret_attrib_metadata = VTABLE_inspect_str(interp, SELF,
-CONST_STRING(interp, attributes));
+PMC *ret_attrib_metadata = VTABLE_inspect_str(interp, SELF, 
CONST_STRING(interp, attributes));
 PCCRETURN(PMC *ret_attrib_metadata);
 }
 
@@ -558,8 +554,7 @@
 
 */
 PCCMETHOD void methods() {
-PMC *ret_methods = VTABLE_inspect_str(interp, SELF,
-CONST_STRING(interp, methods));
+PMC *ret_methods = VTABLE_inspect_str(interp, SELF, 
CONST_STRING(interp, methods));
 PCCRETURN(PMC *ret_methods);
 }
 
@@ -590,8 +585,7 @@
 
 */
 PCCMETHOD void roles() {
-PMC *ret_roles = VTABLE_inspect_str(interp, SELF,
-CONST_STRING(interp, roles));
+PMC *ret_roles = VTABLE_inspect_str(interp, SELF, CONST_STRING(interp, 
roles));
 PCCRETURN(PMC *ret_roles);
 }
 
Index: src/pmc/class.pmc
===
--- src/pmc/class.pmc   (revision 18345)
+++ src/pmc/class.pmc   (working copy)
@@ -468,11 +468,9 @@
 }
 
 /* Set name and type. */
-VTABLE_set_string_keyed_str(interp, new_attribute,
-CONST_STRING(interp, name), name);
+VTABLE_set_string_keyed_str(interp, new_attribute, 
CONST_STRING(interp, name), name);
 if (!PMC_IS_NULL(type)) {
-VTABLE_set_pmc_keyed_str(interp, new_attribute,
-CONST_STRING(interp, type), type);
+VTABLE_set_pmc_keyed_str(interp, new_attribute, 
CONST_STRING(interp, type), type);
 }
 
 /* Enter the attribute in the attributes array. */
@@ -744,8 +742,7 @@
 /* We'll build a hash just containing the name, then give this to
  * init_class_from_hash - saves some code duplication. */
 PMC *naming_hash = pmc_new(interp, enum_class_Hash);
-VTABLE_set_string_keyed_str(interp, naming_hash,
-CONST_STRING(interp, name), name);
+VTABLE_set_string_keyed_str(interp, naming_hash, 
CONST_STRING(interp, name), name);
 init_class_from_hash(interp, SELF, naming_hash);
 }
 
@@ -874,8 +871,7 @@
 
 */
 PCCMETHOD void attributes() {
-PMC *ret_attrib_metadata = VTABLE_inspect_str(interp, SELF,
-CONST_STRING(interp, attributes));
+PMC *ret_attrib_metadata = VTABLE_inspect_str(interp, SELF, 
CONST_STRING(interp, attributes));
 PCCRETURN(PMC *ret_attrib_metadata);
 }
 
@@ -904,8 +900,7 @@
 
 */
 PCCMETHOD void methods() {
-PMC

[perl #41898] Build error with icc

[Steve Peters via RT]

On Sun Mar 18 12:21:18 2007, ptc wrote:
 I don't know if this is a BUG or what so I'm just sending it plain.
 I've just tried to build parrot with icc (not 100% sure if my build
 flags are correct either), and I'm getting this build error:
 
 icc -o miniparrot compilers/imcc/main.o \
 -Wl,-rpath=/home/cochrane/sourceforge/parrot_svn/blib/lib
 -L/home/cochrane/sourceforge/parrot_svn/blib/lib -lparrot -lpthread
 -lm -L/usr/lib  -licuuc -licudata -lpthread -lm -lpthread -lnsl -ldl
 -lm -lcrypt -lutil -lrt -lgmp -lreadline -lncurses -L/usr/local/lib
 src/null_config.o
 Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross
 your fingers
 ./miniparrot config_lib.pasm  runtime/parrot/include/config.fpmc
 miniparrot: src/mmd.c:1707: Assertion
 `((UINTVAL)(mmd_table[i].func_ptr)  3) == 0' failed.
 /bin/sh: line 1: 30223 Aborted ./miniparrot
 config_lib.pasm  runtime/parrot/include/config.fpmc
 make: *** [runtime/parrot/include/config.fpmc] Error 134
 
 Naive configure settings were (comments welcome as to what I might
 have done wrong here):
 
 perl Configure.pl --cc=icc --cxx=icc --ld=icc
 
 Any ideas as to what is going wrong here?

There appear to be a couple of problems.  First, it appears that icc is 
optimizing something 
that causes that assertion to fail.  ifdef'ing the assertion seems to cause no 
problems.  
Second, there appears to be something hateful about the __LINE__ macro in icc.  
I've had to 
adjust the location of a few CONST_STRING() macros.

In the meantime, RT #42768 contains patches necessary to get Intel C++ 
compiling and 
passing tests on Linux.

[perl #42662] [PATCH] De-const variable for C++

[Steve Peters]

# New Ticket Created by  Steve Peters 
# Please include the string:  [perl #42662]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42662 


The const char * f below causes failures when compiled with C++.  The
patch below switches it to a plain char *.

Steve Peters

Index: src/ops/debug.ops
===
--- src/ops/debug.ops   (revision 18296)
+++ src/ops/debug.ops   (working copy)
@@ -61,7 +61,7 @@
 =cut

 op debug_load(inconst STR) :base_debug {
-const char *f;
+char *f;

 if (!(interp-pdb-state  PDB_BREAK)) {
 f = string_to_cstring(interp,($1));

Re: [perl #42615] [PATCH] C89 doesn't allow non-constant initializers

[Steve Peters]

On Thu, Apr 19, 2007 at 11:24:43AM -0700, Andy Dougherty wrote:
 # New Ticket Created by  Andy Dougherty 
 # Please include the string:  [perl #42615]
 # in the subject line of all future correspondence about this issue. 
 # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42615 
 
 
 This patch works around the following error message:
 
 src/inter_call.c, line 1350: non-constant initializer: op U
 src/inter_call.c, line 1350: non-constant initializer: op U
 src/inter_call.c, line 1351: non-constant initializer: op NAME
 src/inter_call.c, line 1351: non-constant initializer: op NAME
 
 diff -ru parrot-current/src/inter_call.c parrot-andy/src/inter_call.c
 --- parrot-current/src/inter_call.c   Sun Apr 15 03:15:15 2007
 +++ parrot-andy/src/inter_call.c  Thu Apr 19 10:26:02 2007
 @@ -1347,8 +1347,8 @@
  PMC* save_current_object;
  
  /* temporary state vars for building PCC index and PCC signature arrays. 
 */
 -opcode_t *indexes[2] = { arg_indexes, result_indexes };
 -PMC *sigs[2] = { args_sig, results_sig };
 +opcode_t *indexes[2]; /* = { arg_indexes, result_indexes }; */
 +PMC *sigs[2]; /* = { args_sig, results_sig }; */
  int arg_ret_cnt[2] = { 0, 0 }; /* # of arg args, # of result args */
  int max_regs[8] = { 0, 0, 0, 0, 0, 0, 0, 0 }; /* INSP args, INSP results 
 */
  int seen_arrow = 0;
 @@ -1359,6 +1359,11 @@
  
  va_list list;
  va_start(list, signature);
 +
 +indexes[0] = arg_indexes;
 +indexes[1] = result_indexes;
 +sigs[0] = args_sig;
 +sigs[1] = results_sig;
  
  /* account for passing invocant in-band */
  if (pmc) {
 

Cool!  I meant to look into this one since it also breaks Borland C++ and
causes warnings under -ansi -pedantic.

Steve Peters
[EMAIL PROTECTED]

Re: [perl #42597] [CAGE] Add Tests for C++ and C Style

[Steve Peters]

On Tue, Apr 17, 2007 at 07:53:21PM -0700, Mark Glines wrote:
 On Tue, 17 Apr 2007 18:53:32 -0700
 chromatic (via RT) [EMAIL PROTECTED] wrote:
 
  In particular, we need to detect:
  
  - variable declarations with name 'class'
  - variable declarations with the name 'namespace'
 
 Hi,
 
 After r18274 was checked in, splint's warning count for this dropped from
 116 lines to 35.  It currently reports the following:
 
 compilers/imcc/pbc.c:953:14: Name class is a keyword or reserved word in C++
 compilers/imcc/symreg.c:568:14: Name new is a keyword or reserved word in C++
 compilers/imcc/symreg.h:103:20: Name namespace is a keyword or reserved word 
 in C++
 lib/Parrot/Pmc2c/PCCMETHOD.pm:402:10: Name class is a keyword or reserved 
 word in C++
 lib/Parrot/Pmc2c/PCCMETHOD.pm:402:10: Name namespace is a keyword or reserved 
 word in C++
 src/debug.c:1276:11: Name new is a keyword or reserved word in C++ 
 src/debug.c:1688:18: Name new is a keyword or reserved word in C++
 src/gc/gc_ims.c:936:50: Name new is a keyword or reserved word in C++
 src/pic.c:559:25: Name class is a keyword or reserved word in C++
 src/pmc/array.pmc:1228:10: Name true is a keyword or reserved word in C++
 src/pmc/class.pmc:781:19: Name class is a keyword or reserved word in C++
 src/pmc/class.pmc:804:19: Name class is a keyword or reserved word in C++
 src/pmc/class.pmc:984:19: Name class is a keyword or reserved word in C++
 src/pmc/default.c:2249:54: Name class is a keyword or reserved word in C++
 src/pmc/delegate.c:154:57: Name class is a keyword or reserved word in C++
 src/pmc/delegate.pmc:43:10: Name class is a keyword or reserved word in C++
 src/pmc/delegate.pmc:67:14: Name class is a keyword or reserved word in C++
 src/pmc/delegate.pmc:108:47: Name class is a keyword or reserved word in C++
 src/pmc/deleg_pmc.c:54:58: Name class is a keyword or reserved word in C++
 src/pmc/namespace.c:303:81: Name namespace is a keyword or reserved word in 
 C++
 src/pmc/object.pmc:27:19: Name class is a keyword or reserved word in C++
 src/pmc/object.pmc:191:19: Name class is a keyword or reserved word in C++
 src/pmc/pair.pmc:51:17: Name class is a keyword or reserved word in C++
 src/pmc/parrotclass.pmc:111:10: Name class is a keyword or reserved word in 
 C++
 src/pmc/parrotclass.pmc:268:11: Name class is a keyword or reserved word in 
 C++
 src/pmc/parrotclass.pmc:339:11: Name class is a keyword or reserved word in 
 C++
 src/pmc/parrotobject.pmc:32:10: Name class is a keyword or reserved word in 
 C++
 src/pmc/parrotobject.pmc:89:10: Name class is a keyword or reserved word in 
 C++
 src/pmc/parrotobject.pmc:130:10: Name class is a keyword or reserved word in 
 C++
 src/pmc/parrotobject.pmc:166:10: Name class is a keyword or reserved word in 
 C++
 src/pmc/parrotobject.pmc:558:10: Name true is a keyword or reserved word in 
 C++
 src/pmc/role.pmc:90:14: Name namespace is a keyword or reserved word in C++
 src/pmc/role.pmc:122:14: Name namespace is a keyword or reserved word in C++
 src/pmc/scalar.pmc:1403:10: Name true is a keyword or reserved word in C++
 src/pmc/string.c:577:75: Name new is a keyword or reserved word in C++
 
 It won't be a complete list, because splint is only checking the files
 which A) are built on my platform, and B) I haven't blacklisted due to
 parse errors.  But I hope it's helpful.

Thanks so much.  gcc's -Wc++-compat hatefully ignores these kinds of problems,
and other issues prevent me from combing through with a C++ compiler.  I'll
take a look at the rest of these this evening, and hopefully work on 
-Wc++-compat as well.

Steve Peters
[EMAIL PROTECTED]

Re: [perl #42594] [PATCH] Probable buffer overflow in compilers/imcc/parser_util.c

[Steve Peters]

On Wed, Apr 18, 2007 at 11:18:20AM +0200, Mehmet Yavuz Selim Soyturk wrote:
 +format[sizeof(format - 1)] = '\0';
 
 
 Shouldn't that be 'format[sizeof(format) - 1]' ?
 

Yes, thanks!  Good catch!

Steve

Re: Should a dirhandle be a filehandle-like iterator?

[Steve Peters]

On Fri, Apr 13, 2007 at 07:43:23PM -0500, brian d foy wrote:
 As I was playing around with dirhandles, I thought What if... (which
 is actualy sorta fun to do in Pugs, where Perl 5 has everything
 documented somewhere even if nobody has read it).
 
 My goal is modest: explain fewer things in the Llama. If dirhandles
 were like filehandles, there's a couple of pages of explanation I don't
 need to go through.
 
 Witness:
 
 I can iterate through the elements of a named array with [EMAIL PROTECTED]:
 
my @a =  1 2 3 4 5 ;
for [EMAIL PROTECTED] { .say }   # but not = 1 2 3 4 5  :(
 
 and I can read lines from a file:
 
for =$fh { .say }
 
 Should I be able to go through a directory handle that way too? A yes
 answer would be very pleasing :)
 
my $dh = doc.opendir;
for =$dh { .say }# doesn't work in pugs
 
 And, since we're using objects now, .closedir can really just be
 .close, right? 
 
 And, maybe this has been already done, but wrapping a lazy filter
 around anything that can return items. I'm not proposing this as a
 language feature, but if many things shared the same way of getting the
 next item, perhaps I could wrap it in a lazy map-ish thingy:
 
my $general_iterator = lazy_mappish_thingy( doc.opendir ); 
 
for =$general_iterator { .say }
 
$general_iterator.close;  # or .end, or .whatever
 
 That last part is definetely not Llama material, but maybe I'll at
 least hit the haystack.

One of the things done for Perl 5.10 is to make dirhandles be a little
bit more like filehandles.  On OS's that allow it, things like

stat DIRHANDLE
-X DIRHANDLE
chdir DIRHANDLE

all make sense and do what you'd think they'd do.  

Steve Peters
[EMAIL PROTECTED]

Re: [perl #42509] [PATCH] Quiet some warnings under -ansi -pedantic

[Steve Peters]

On Sat, Apr 14, 2007 at 11:05:27PM +0100, Jonathan Worthington wrote:
 Hi,
 
 I just backed out one small part of this patch because it broke the 
 build using MS VC++ on Win32.
 
 Steve Peters (via RT) wrote:
 ndex: src/exec_save.c
 ===
 --- src/exec_save.c (revision 18179)
 +++ src/exec_save.c (working copy)
 @@ -21,6 +21,7 @@
  #include parrot/parrot.h
  #include parrot/exec.h
  #include exec_save.h
 +#include strings.h
 
  static void save_zero(FILE *fp);
  static void save_int(FILE *fp, int i);
   
 It appears that we do not have strings.h - I get the standard file not 
 found error in relation to that line. Hopefully another way can be 
 found to clear up the warning - I'm happy to test any of them on Windows.
 

Hhow hateful.  Lemme reboot and play around with Windows.

Steve Peters
[EMAIL PROTECTED]

Re: Limiting Exported Symbols on GCC

[Steve Peters]

On Thu, Apr 12, 2007 at 01:37:24PM +0200, Ron Blaschke wrote:
 While poking the GCC documentation I found that there's a feature 
 available to limit the exported symbols (with GCC = 3.3).  Maybe worth 
 considering?
 It's probably a design decision.  If there's an option to limit the 
 exported symbols or make all available, which one should be taken?
 
 http://gcc.gnu.org/wiki/Visibility
 http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Function-Attributes.html#Function-Attributes
 
 This can be done by adding C-fvisibility=hidden to CFLAGS and setting 
 PARROT_API to C__attribute__ ((visibility(default))).
 
 

I think that we need to tread very carefully with adding additional 
gcc-isms to Parrot, lest we break compatibility with additional compilers
even further.  If Parrot will run everywhere, we need to think about 
working more towards ANSI and POSIX compliance.

Steve Peters
[EMAIL PROTECTED]

[perl #42359] [PATCH] Assorted cleanups - part III (Intel C++)

[Steve Peters via RT]

On Mon Apr 09 23:01:35 2007, [EMAIL PROTECTED] wrote:
 On Sunday 08 April 2007 18:07, Steve Peters via RT wrote:
 
  On Sun Apr 08 16:08:05 2007, stmpeters wrote:
   The attached patch includes several cleanups needed to silence
   warnings
   when compiling Parrot with Intel C++.
 
  It helps to attach the right patch
 
 I get several warnings.  I've cleaned up this batch:
 
 src/pmc/eval.pmc: In function ‘Parrot_Eval_get_string’:
 src/pmc/eval.pmc:255: warning: passing argument 3 of ‘PackFile_pack’
 from
 incompatible pointer type
 src/pmc/eval.pmc: In function ‘Parrot_Eval_thaw’:
 src/pmc/eval.pmc:312: warning: passing argument 3 of ‘PackFile_unpack’
 from
 incompatible pointer type
 
 src/pmc_freeze.c: In function ‘run_thaw’:
 src/pmc_freeze.c:1435: warning: comparison of distinct pointer types
 lacks a
 cast
 
 src/pmc/string.pmc: In function ‘Parrot_String_nci_trans’:
 src/pmc/string.pmc:853: warning: array subscript has type ‘char’
 
 ... but my attempt to fix these causes more test failures in
 t/op/string_cs.t:
 
 src/encodings/fixed_8.c
 src/encodings/fixed_8.c: In function ‘get_byte’:
 src/encodings/fixed_8.c:49: warning: pointer targets in initialization
 differ
 in
  signedness
  src/encodings/fixed_8.c: In function ‘set_byte’:
  src/encodings/fixed_8.c:67: warning: pointer targets in assignment
 differ in
 sig
  nedness
  src/encodings/ucs2.c
  src/encodings/utf16.c
  src/encodings/utf16.c: In function ‘get_byte’:
  src/encodings/utf16.c:170: warning: pointer targets in initialization
 differ
 in
  signedness
  src/encodings/utf16.c: In function ‘set_byte’:
  src/encodings/utf16.c:188: warning: pointer targets in assignment
 differ in
 sign
  edness
  src/encodings/utf8.c
  src/encodings/utf8.c: In function ‘to_encoding’:
  src/encodings/utf8.c:334: warning: pointer targets in assignment
 differ in
 signe
  dness
  src/encodings/utf8.c:357: warning: pointer targets in assignment
 differ in
 signe
  dness
  src/encodings/utf8.c: In function ‘get_byte’:
  src/encodings/utf8.c:400: warning: pointer targets in initialization
 differ
 in s
  ignedness
  src/encodings/utf8.c: In function ‘set_byte’:
  src/encodings/utf8.c:418: warning: pointer targets in assignment
 differ in
 signe
  dness
 
 The test results are:
 
 not ok 5 - downcase
 # Failed test (t/op/string_cs.t at line 72)
 #  got: 'aeiou_��
  # '
 # expected: 'aeiou_��
  # '
 ok 6 - upcase
 not ok 7 - titlecase
 # Failed test (t/op/string_cs.t at line 90)
 #  got: 'Zaeiou_��
   # '
 # expected: 'Zaeiou_��
   # '
 
 As seen through less, they are:
 # Failed test (t/op/string_cs.t at line 72)
 #  got: 'aeiou_C4D6DC
 # '
 # expected: 'aeiou_E4F6FC
 # '
 # Failed test (t/op/string_cs.t at line 90)
 #  got: 'Zaeiou_C4D6DC
 # '
 # expected: 'Zaeiou_E4F6FC
 
 ... so the encoded characters get 32 added to them somehow, somewhere.
 
 I've attached your patch with a few changes on my end.
 
 -- c
 
 

These are likely caused by the varying definition of what a
STRING-strstart is.  Sometimes its a char *.  Sometimes its an unsigned
char *.  The pointer itself is a void *.  Its a big mess.  Obviously,
this all needs more work, and probably a bit more thought on my part. 
I'll probably break apart this patch to get the enum fixes in and deal
with the larger STRING issue separately.

Steve

The great class variable renaming

[Steve Peters]

One problem I recently ran into while working on compiling parrot with
C++ is the use of class as a variable name in struct _vtable and as
parameters in several functions.

This will need to change as I begin to move forward on my compatiblity
work and I'm looking for some consensus on the name for the vtable.
In my initial work, I've changed the name to pmc_class since it
seems to be the most accurate based on the documentaton in vtable.h.
I'm gladly open to suggestions for a different name for this
varaible.

Parameters and variables in functions will, however, be handled on
a case by case basis to work out the most appropriate replacement
name based on its use.  Please feel free to adjust if you think I've
gotten something wrong.

Regards,

Steve Peters
[EMAIL PROTECTED]

[perl #42359] [PATCH] Assorted cleanups - part III (Intel C++)

[Steve Peters via RT]

On Sun Apr 08 16:08:05 2007, stmpeters wrote:
 The attached patch includes several cleanups needed to silence
 warnings
 when compiling Parrot with Intel C++.
 

It helps to attach the right patch

Steve


intel_cleanups.out
Description: Binary data

[perl #42279] [PATCH] Parrot cleanups - part 2

[Steve Peters via RT]

On Mon Apr 02 17:16:45 2007, stmpeters wrote:
 Here's some additional cleanups for making Parrot a bit more friendly
 to a wider variety of C compilers.
 

It is always good to actually include the attachment you are sending.

Steve


Index: src/encoding.c
===
--- src/encoding.c	(revision 17946)
+++ src/encoding.c	(working copy)
@@ -65,7 +65,7 @@
 ENCODING *
 Parrot_new_encoding(Interp *interp)
 {
-return mem_sys_allocate(sizeof (ENCODING));
+return mem_allocate_typed(ENCODING);
 }
 
 ENCODING *
@@ -175,10 +175,10 @@
  * loading of encodings from inside threads
  */
 if (!n)
-all_encodings-enc = mem_sys_allocate(sizeof (One_encoding));
+all_encodings-enc = mem_allocate_typed(One_encoding);
 else
-all_encodings-enc = mem_sys_realloc(all_encodings-enc, (n + 1) *
-sizeof (One_encoding));
+all_encodings-enc = (One_encoding*)mem_sys_realloc(all_encodings-enc,
+(n + 1) * sizeof (One_encoding));
 all_encodings-n_encodings++;
 all_encodings-enc[n].encoding = encoding;
 all_encodings-enc[n].name = const_string(interp, encodingname);
@@ -191,7 +191,7 @@
 ENCODING *encoding)
 {
 if (!all_encodings) {
-all_encodings = mem_sys_allocate(sizeof (All_encodings));
+all_encodings = mem_allocate_typed(All_encodings);
 all_encodings-n_encodings = 0;
 all_encodings-enc = NULL;
 }
Index: src/charset.c
===
--- src/charset.c	(revision 17946)
+++ src/charset.c	(working copy)
@@ -62,7 +62,7 @@
 CHARSET *
 Parrot_new_charset(Interp *interp)
 {
-return mem_sys_allocate(sizeof (CHARSET));
+return mem_allocate_typed(CHARSET);
 }
 
 void
@@ -184,10 +184,10 @@
  * loading of charsets from inside threads
  */
 if (!n)
-all_charsets-set = mem_sys_allocate(sizeof (One_charset));
+all_charsets-set = mem_allocate_typed(One_charset);
 else
-all_charsets-set = mem_sys_realloc(all_charsets-set, (n + 1) *
-sizeof (One_charset));
+all_charsets-set = (One_charset *)mem_sys_realloc(all_charsets-set,
+(n + 1) * sizeof (One_charset));
 all_charsets-n_charsets++;
 all_charsets-set[n].charset = charset;
 all_charsets-set[n].name = const_string(interp, charsetname);
@@ -219,7 +219,7 @@
 CHARSET *charset)
 {
 if (!all_charsets) {
-all_charsets = mem_sys_allocate(sizeof (All_charsets));
+all_charsets = mem_allocate_typed(All_charsets);
 all_charsets-n_charsets = 0;
 all_charsets-set = NULL;
 }
Index: src/inter_call.c
===
--- src/inter_call.c	(revision 17946)
+++ src/inter_call.c	(working copy)
@@ -348,7 +348,8 @@
 PMC *elem;
 if (st-key) {
 st-src.slurp_i++;
-st-name = parrot_hash_get_idx(interp, PMC_struct_val(st-src.slurp), st-key);
+st-name = (STRING *)parrot_hash_get_idx(interp,
+   (Hash *)PMC_struct_val(st-src.slurp), st-key);
 assert(st-name);
 elem = VTABLE_get_pmc_keyed_str(interp, st-src.slurp, st-name);
 }
Index: src/exec.c
===
--- src/exec.c	(revision 17946)
+++ src/exec.c	(working copy)
@@ -69,7 +69,7 @@
 extern PARROT_API int Parrot_exec_rel_count;
 
 Parrot_exec_objfile_t * const obj =
-mem_sys_allocate_zeroed(sizeof (Parrot_exec_objfile_t));
+mem_allocate_zeroed_typed(Parrot_exec_objfile_t);
 exec_init(obj);
 Parrot_exec_rel_addr = (char **)mem_sys_allocate_zeroed(4 * sizeof (char *));
 obj-bytecode_header_size =
@@ -206,7 +206,7 @@
 Parrot_exec_symbol_t *new_symbol;
 
 symbol_number = obj-symbol_count;
-new_symbol = mem_sys_realloc(obj-symbol_table,
+new_symbol = (Parrot_exec_symbol_t *)mem_sys_realloc(obj-symbol_table,
 (size_t)(obj-symbol_count + 1) * sizeof (Parrot_exec_symbol_t));
 obj-symbol_table = new_symbol;
 
Index: src/interpreter.c
===
--- src/interpreter.c	(revision 17946)
+++ src/interpreter.c	(working copy)
@@ -208,13 +208,14 @@
 size_t nb = interp-code-base.size / 16;
 if (nb  8)
 nb = (size_t)8;
-pi-branches = mem_sys_allocate(sizeof (Prederef_branch) * nb);
+pi-branches = (Prederef_branch *)mem_sys_allocate(
+   sizeof (Prederef_branch) * nb);
 pi-n_allocated = nb;
 pi-n_branches = 0;
 }
 else if (pi-n_branches = pi-n_allocated) {
 pi-n_allocated = (size_t) (pi-n_allocated * 1.5);
-pi-branches = mem_sys_realloc(pi-branches,
+

Re: Current State of Building Parrot on Cygwin

[Steve Peters]

On Sun, Apr 01, 2007 at 04:15:24PM +0200, Ron Blaschke wrote:
 Hi,
 
 As recently discussed it is currently necessary to include the absolute 
 path to Fblib/lib in the environment variable PATH.  This should be 
 done before trying to built parrot, otherwise one gets a broken 
 Fruntime/parrot/include/config.fpmc and Fsrc/parrot_config.c.  One 
 needs a make clean or remove *both* files before trying again.  Make 
 sure to export the PATH changes, not just only set them, and use the 
 absolute path, not the relative (otherwise building some libs will fail 
 later on.)
 
 If you see this error
 
  make runtime/parrot/library/Crow.pbc
 ./parrot.exe -o runtime/parrot/library/Crow.pbc
 runtime/parrot/library/Crow.pir
 error:imcc:syntax error, unexpected $end
 in file 'runtime/parrot/library/Crow.pir' line 146
 make: *** [runtime/parrot/library/Crow.pbc] Error 1
 
 the file has Windows line endings, usually because checked out with 
 Windows' Subversion.  Get the Cygwin version and a clean checkout.
 

I was beginning to think that was the problem with Cygwin.  With Perl 5,
the build process keeps all the Perl library in the same directory with
executable.  This seems to make things much easier for Windows, since 
DLL's need to be on the PATH on Windows (including Cygwin).  Once I
reboot into Windows, I'll see what I can do to help make this more automatic.

Steve Peters
[EMAIL PROTECTED]

Re: [perl #42156] [PATCH] Make invoke() return opcode_t*

[Steve Peters]

On Thu, Mar 29, 2007 at 07:28:52PM +0200, Paul Cochrane wrote:
 On 28/03/07, via RT Steve Peters [EMAIL PROTECTED] wrote:
 # New Ticket Created by  Steve Peters
 # Please include the string:  [perl #42156]
 # in the subject line of all future correspondence about this issue.
 # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42156 
 
 
 In this next round of cleanups, I switched over the invoke() methods
 to return opcode_t* as Andy Dougherty suggested.  Also, I added
 a change to the NEED_CONTINUATION based on Kevin Tewks suggestions.
 Finally, I also included a couple of additional changes to back out some
 of my changes yesterday that are now irrelevant due to the first two
 changes.
 
 
 Thanks for the patch, however, applying it generates the warning: (on
 linux x86; gcc)
 
 src/sub.c: In function `mark_context':
 src/sub.c:55: warning: comparison of distinct pointer types lacks a cast
 
 I'm not sure how to proceed from here, and I hoped you would.  How
 should the patch be altered so that the warning doesn't appear?
 

Below is an additional change for src/sub.c.

I had been looking at this function for additional changes, but
I'd rather get this patch taken care of first, since the rest remaining
changes are made easier by this patch going in first.

I also noticed a warning with src/debug.c.  There are certainly, however,
some rather severe existing problems with the Parrot debugger that I don't
know I am qualified to handle.  It's pretty obvious that the previous
expectation that VTABLE_invoke() would return something that could be 
turned into a PackFile was incorrect since everywhere else it's expected to
return an opcode_t*.  I'm certain that I do not have the right answers, but
getting the Parrot Debugger to work may be a great exercize for a future
microgrant winner (hint hint).

Steve Peters
[EMAIL PROTECTED]

Index: src/sub.c
===
--- src/sub.c   (revision 17850)
+++ src/sub.c   (working copy)
@@ -52,7 +52,7 @@
  * and GC the continuation
  */
 obj = (PObj*)interp-current_cont;
-if (obj  obj != NEED_CONTINUATION)
+if (obj  obj != (PObj*)NEED_CONTINUATION)
 pobject_lives(interp, obj);
 obj = (PObj*)ctx-current_cont;
 if (obj  !PObj_live_TEST(obj))

Index: src/debug.c
===
--- src/debug.c (revision 17850)
+++ src/debug.c (working copy)
@@ -1973,15 +1973,27 @@
 struct PackFile *eval_pf;
 struct PackFile_ByteCode *old_cs;

-eval_pf = PDB_compile(interp, command);
+/*
+  The replacement code is almost certainly wrong.  The previous
+  code is almost certainly wrong as well.  Obviously, the
+  Parrot debugger needs some love.
+*/

+#if 0
+   /* eval_pf = PDB_compile(interp, command);
+
 if (eval_pf) {
 old_cs = Parrot_switch_to_cs(interp, eval_pf-cur_cs, 1);
 run = eval_pf-cur_cs-base.data;
 DO_OP(run,interp);
 Parrot_switch_to_cs(interp, old_cs, 1);
-   /* TODO destroy packfile */
+TODO destroy packfile
 }
+#endif
+run = PDB_compile(interp, command);
+if(run) {
+DO_OP(run,interp);
+}
 }

 /*
@@ -2000,25 +2012,22 @@

 */

-struct PackFile *
+opcode_t *
 PDB_compile(Interp *interp, const char *command)
 {
 STRING *buf;
 const char *end = \nend\n;
-PMC * compiler, *code;
+PMC * compiler;
 STRING *key = const_string(interp, PASM);
 PMC *compreg_hash = VTABLE_get_pmc_keyed_int(interp,
 interp-iglobals, IGLOBALS_COMPREG_HASH);
-
 compiler = VTABLE_get_pmc_keyed_str(interp, compreg_hash, key);
 if (!VTABLE_defined(interp, compiler)) {
 fprintf(stderr, Couldn't find PASM compiler);
 return NULL;
 }
 buf = Parrot_sprintf_c(interp, %s%s, command, end);
-
-code = VTABLE_invoke(interp, compiler, buf);
-return PMC_struct_val(code);
+return VTABLE_invoke(interp, compiler, buf);
 }

 /*

[perl #41837] [PATCH] integer overflow in include/parrot/sub.h

[Steve Peters via RT]

On Thu Mar 15 05:30:31 2007, nahoo wrote:
 On Mi. 14. Mär. 2007, 23:00:18, nahoo wrote:
  Index: include/parrot/sub.h
  ===
  --- include/parrot/sub.h(Revision 17473)
  +++ include/parrot/sub.h(Arbeitskopie)
  @@ -87,7 +87,6 @@
   SUB_COMP_FLAG_BIT_28 = 1  28,
   SUB_COMP_FLAG_BIT_29 = 1  29,
   SUB_COMP_FLAG_BIT_30 = 1  30,
  -SUB_COMP_FLAG_BIT_31 = 1  31,
   SUB_COMP_FLAG_MASK   = 0x0400,
   } sub_comp_flags_enum;
 
 I forgot to add a sort comment about the bug report. The range of an
 Enum is the same as the range of an integer (at least on i386), not the
 range of an unsigned interger. Then 1  31 is a negative number.

This patch appears to have been warnocked.  It is a needed fix for
32-bit Solaris compilers at least.

[perl #42151] [PATCH] Assorted casting cleanups - part I

[Steve Peters via RT]

On Tue Mar 27 10:54:17 2007, doughera wrote:
 On Tue, 27 Mar 2007, Steve Peters wrote:
 
  # New Ticket Created by  Steve Peters 
  # Please include the string:  [perl #42151]
  # in the subject line of all future correspondence about this issue. 
  # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42151 
 
 Thanks for taking on this Herculean task. However, one thought
immediately 
 came to mind:
 
  
  Index: src/ops/experimental.ops
  ===
  --- src/ops/experimental.ops(revision 17785)
  +++ src/ops/experimental.ops(working copy)
  @@ -520,7 +520,7 @@
   Interp * const new_interp = (Interp *)PMC_data($1);
   opcode_t *pc;
   Interp_flags_SET(new_interp, PARROT_EXTERN_CODE_FLAG);
  -pc = VTABLE_invoke(new_interp, $2, NULL);
  +pc = (opcode_t *)VTABLE_invoke(new_interp, $2, NULL);
   Parrot_runops_fromc_args(new_interp, $2, P);
   goto NEXT();
   }
 
 Instead of sprinking (opcode_t *) casts everywhere, wouldn't it be better 
 to declare the invoke() function as returning an (opcode_t *) ?  
 Similarly for most of the other bits you patched.  Wouldn't it make more 
 sense in the long run to change the functions to say they return what
they 
 actually return?
 
 Of course you can't always do that:
 
   Parrot_new_charset(Interp *interp)
   {
  -return mem_sys_allocate(sizeof (CHARSET));
  +return (CHARSET *)mem_sys_allocate(sizeof (CHARSET));
   }
 
 mem_sys_allocate() obviously can only return one type, but is used in
many 
 contexts.
 


Of course, some well defined macros could assist in cleaning this up. 
For example...

#define PARROT_MEM_ALLOCATE(type)  \
(type *)mem_sys_allocate(sizeof(type))

I don't know the Parrot opinion of macros, but it would certainly make
the code cleanup much easier.

Re: [perl #42110] [PATCH] Returning values from void functions

[Steve Peters]

On Wed, Mar 28, 2007 at 07:41:25PM +0100, Nicholas Clark wrote:
 On Tue, Mar 27, 2007 at 05:42:12AM -0700, Steve Peters via RT wrote:
 
   Anyway, it's worth noting that although one of functions actually
   doesn't
   return anything, it is documented as returning a PMC *.  So either the
   documentation or the function is wrong in parrotobject.pmc and should
   be
   fixed.
  
  Unfortunately, I can't find a gcc warning flag that would seem to catch 
  this sort of situation 
  either.
 
 I don't think that it's possible to make this non-conformity a fatal heresy 
 :-(
 (gcc --spanish-inquisition)

As long as this doesn't involve the comfy chair-type inquisition gcc seems
to like, we'd be alright.

As an aside, I've been using -Wc++-compat, my discovery from last week 
that I added to bleadperl, to help me find these issues so far.  Right
now, Parrot is not ready to compile with this full time, but I'm hoping
it will be by the end of the weekend.

 Getting parrot to build under -ansi -pedantic is left as an exercise to the
 reader. Likely to a reader on *BSD who wants to apply for a microgrant.
 (Even Solaris doesn't have headers that are clean with -ansi -pedantic. Which
 surprises me. Solaris is usually very clean and well engineered throughout)
 
 Can Intel or Sun's compilers be coaxed into being suitably grumpy about this?
 If so, do we have a machine capable of smoking them?
 And is it viable (or good) for parrot smoke failures to reach this list, much
 like most people configure their Perl 5 smokers to send the black smoke to
 p5p?
 

Intel's errors do not seem sensitive enough to pick it up, although 
HP-UX did.  I haven't looked at Solaris yet, but I'm certain it would 
pick up this failure as well.

Steve Peters
[EMAIL PROTECTED]

Re: [perl #42110] [PATCH] Returning values from void functions

[Steve Peters]

On Thu, Mar 29, 2007 at 12:51:54PM -0700, Leopold Toetsch via RT wrote:
 Am Mittwoch, 28. März 2007 20:41 schrieb Nicholas Clark:
  Getting parrot to build under -ansi -pedantic is left as an exercise to the
  reader.
 
 By filtering other useless and/or nonsensical warnings - yes - else no.
 
 leo - been there, done that
 

Sweeping dirt under the rug doesn't mean that the house has been cleaned
up.  It means I've turned it into someone else's problem.  I'd rather 
Parrot was solid and reliable than something VM users cannot rely on.

Steve Peters
[EMAIL PROTECTED]

[perl #42110] [PATCH] Returning values from void functions

[Steve Peters via RT]

On Tue Mar 27 05:32:41 2007, doughera wrote:
 On Mon, 26 Mar 2007, Steve Peters wrote:
 
  # New Ticket Created by  Steve Peters
  # Please include the string:  [perl #42110]
  # in the subject line of all future correspondence about this issue.
  # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42110 
 
 
  A couple of functions in XX are trying to return values from void
 functions.
  To some compilers, such as the standard HP-UX compilers, this is a
 big
  no-no.  The patch below fixes this problem.
 
 Yes.  I sent in this same patch last week.  I didn't send it to RT
 since I
 thought it was so obvious that someone would apply it right away and
 I'd
 spare that same someone the nuisance of closing the RT ticket.  My
 mistake.  I shouldn't have assumed.
 
 Anyway, it's worth noting that although one of functions actually
 doesn't
 return anything, it is documented as returning a PMC *.  So either the
 documentation or the function is wrong in parrotobject.pmc and should
 be
 fixed.

Unfortunately, I can't find a gcc warning flag that would seem to catch this 
sort of situation 
either.

 
 
  Steve Peters
  [EMAIL PROTECTED]
 
  Index: src/pmc/parrotobject.pmc
  
=
==
  --- src/pmc/parrotobject.pmc(revision 17781)
  +++ src/pmc/parrotobject.pmc(working copy)
  @@ -207,8 +207,10 @@
   PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v);
   if (PMC_IS_NULL(sub))
   sub = find_meth(interp, SELF, meth);
  -if (PMC_IS_NULL(sub))
  -return Parrot_set_attrib_by_num(INTERP, SELF, idx,
 value);
  +if (PMC_IS_NULL(sub)) {
  +Parrot_set_attrib_by_num(INTERP, SELF, idx, value);
  +return;
  +}
   (PMC*) Parrot_run_meth_fromc_args(interp, sub,
   SELF, meth, vIP, idx, value);
   }
  @@ -219,8 +221,10 @@
   PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v);
   if (PMC_IS_NULL(sub))
   sub = find_meth(interp, SELF, meth);
  -if (PMC_IS_NULL(sub))
  -return Parrot_set_attrib_by_str(INTERP, SELF, idx,
 value);
  +if (PMC_IS_NULL(sub)) {
  +Parrot_set_attrib_by_str(INTERP, SELF, idx, value);
  +return;
  +}
   (PMC*) Parrot_run_meth_fromc_args(interp, sub,
   SELF, meth, vSP, idx, value);
   }
 
 

[perl #42151] [PATCH] Assorted casting cleanups - part I

[Steve Peters via RT]

On Tue Mar 27 10:54:17 2007, doughera wrote:
 On Tue, 27 Mar 2007, Steve Peters wrote:
 
  # New Ticket Created by  Steve Peters 
  # Please include the string:  [perl #42151]
  # in the subject line of all future correspondence about this issue. 
  # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42151 
 
 Thanks for taking on this Herculean task. However, one thought immediately 
 came to mind:
 
  
  Index: src/ops/experimental.ops
  
=
==
  --- src/ops/experimental.ops(revision 17785)
  +++ src/ops/experimental.ops(working copy)
  @@ -520,7 +520,7 @@
   Interp * const new_interp = (Interp *)PMC_data($1);
   opcode_t *pc;
   Interp_flags_SET(new_interp, PARROT_EXTERN_CODE_FLAG);
  -pc = VTABLE_invoke(new_interp, $2, NULL);
  +pc = (opcode_t *)VTABLE_invoke(new_interp, $2, NULL);
   Parrot_runops_fromc_args(new_interp, $2, P);
   goto NEXT();
   }
 
 Instead of sprinking (opcode_t *) casts everywhere, wouldn't it be better 
 to declare the invoke() function as returning an (opcode_t *) ?  
 Similarly for most of the other bits you patched.  Wouldn't it make more 
 sense in the long run to change the functions to say they return what they 
 actually return?
 

I'll have to look into some of these a little more closely as I go through.  I 
should probably go 
through and refactor as I work on this cleanup.  I probably should reject this 
particular patch 
and look for some lower level cleanups that might make this whole process much 
easier, such 
as what you two have pointed out.

 Of course you can't always do that:
 
   Parrot_new_charset(Interp *interp)
   {
  -return mem_sys_allocate(sizeof (CHARSET));
  +return (CHARSET *)mem_sys_allocate(sizeof (CHARSET));
   }
 
 mem_sys_allocate() obviously can only return one type, but is used in many 
 contexts.
 

Yes, no getting around these ones :)

[perl #41195] [BUG]: Change to Configure.pl causing 'make' to fail on Darwin

[Steve Peters via RT]

On Sun Jan 07 08:27:28 2007, [EMAIL PROTECTED] wrote:
 
 On Jan 7, 2007, at 8:44 AM, Steve Peters via RT wrote:
 
  What is your c++ symlink pointing at?
 
 
 
 
 [parrot] 512 $ ls -l /usr/bin/c++
 lrwxr-xr-x   1 root  wheel  7 Aug  9  2004 /usr/bin/c++ - g++-3.3
 [parrot] 513 $ ls -l /usr/bin/g++-3.3
 -r-xr-xr-x   1 root  wheel  135816 May 14  2006 /usr/bin/g++-3.3
 

OK, this problem must be something similar to the linking problems I
have with suncc on Linux.  Even though I specify everything on the
Configure.pl command-line in terms of --cc and --link, it magically
switches to g++ when trying to link.  Obviously, then, the hints or
something that runs after is misbehaving and redefining variables
configuration variables.

[perl #41243] Link on Win32 with Borland C++

[Steve Peters via RT]

On Thu Jan 11 08:57:22 2007, coke wrote:
 Need details.

A recent patch has gotten Parrot to the point that it can be compiled
with Borland C++ on Win32.  Unfortunately, it does not link correctly to
actually create a valid parrot executable.  Additional configuration is
needed to make Borland compile and link Parrot so that it can actually
be run and tested.

[perl #41195] [BUG]: Change to Configure.pl causing 'make' to fail on Darwin

[Steve Peters via RT]

What is your c++ symlink pointing at?

Re: [svn:parrot-pdd] r16036 - trunk/docs/pdds/clip

[Steve Peters]

On Wed, Jan 03, 2007 at 03:43:17PM +, Nicholas Clark wrote:
 On Wed, Dec 06, 2006 at 06:30:35PM -0800, [EMAIL PROTECTED] wrote:
 
  +Recognizing the fact that ports depend on volunteer labor, the minimum
  +requirements for the 1.0 launch of Parrot are portability to major
  +versions of Linux, BSD, Mac OS X, and Windows released within 2 years
  +prior to the 1.0 release. As we approach the 1.0 release we will
  +actively seek porters for as many other platforms as possible.
 
 There is the potential for satisfying those requirements entirely with x86
 ILP32 systems, potentially using only 2 different compilers, which wouldn't
 be fab for ensuring portability :-(
 
 I would think that Sparc Solaris, building 64 bit, would be the best single
 target to aim for to increase portability spread.
 

Actually, I was thinking this could be accomplished with gcc only on all
of these environments.  That, however, would be very bad.

Steve Peters
[EMAIL PROTECTED]

[perl #31652] [TODO] Win32 - Microsoft Visual C++ Toolkit 2003

[Steve Peters via RT]

On Sun Dec 17 19:29:46 2006, [EMAIL PROTECTED] wrote:
 With ICU optional these days, is this still necessary?

I have a Visual C++ Toolkit 2003 lying around (I think), so, if I do,
I'll give this a try along with my Borland work.

[perl #40950] [PATCH] Compiling Parrot with the new Borland C++

[Steve Peters via RT]

 On Mon Nov 20 06:24:00 2006, stmpeters wrote:
  It took some tweaking to get some of the warnings shut off, but the
  attached patch actually gets the files to compile, although it doesn't
  actually build a parrot to test with.  Expect a few more patches over 
 the
  next week to finish this off.
  
  Steve Peters
  [EMAIL PROTECTED]
 
 
This patch still needs to be applied to continue work on compiling 
parrot with Borland C++.

[perl #41105] [PATCH] Silence a warning on Cygwin

[Steve Peters via RT]

On Sat Dec 16 18:59:18 2006, stmpeters wrote:
 This patch silences a minor warning on Cygwin.
 
 Steve Peters
 [EMAIL PROTECTED]
 
 $ diff -u parrot/src/pmc/parrotio.pmc parrot-patch/src/pmc/parrotio.pmc
 --- parrot/src/pmc/parrotio.pmc 2006-12-16 20:46:58.37500 -0600
 +++ parrot-patch/src/pmc/parrotio.pmc   2006-12-16 20:47:31.12500
-0600
 @@ -199,7 +199,7 @@
  PIO_setlinebuf(interp, SELF);
  res = PIO_reads(interp, SELF, 0);
  if (!res)
 -return res;
 +return (PMC*)res;
  /* readline should better return the string w/o NL */
  len = string_length(INTERP, res);
  while (len  (((char*)res-strstart)[len-1] == '\n'
 @@ -208,7 +208,7 @@
  --res-strlen;
  --res-bufused;
  }
 -return res;
 +return (PMC*)res;
  }
  }


Actually, no, not the previous patch.  Try the following instead.

--- parrot/src/pmc/parrotio.pmc 2006-12-16 20:46:58.37500 -0600
+++ parrot-patch/src/pmc/parrotio.pmc   2006-12-16 21:26:49.203125000 -0600
@@ -199,7 +199,7 @@
 PIO_setlinebuf(interp, SELF);
 res = PIO_reads(interp, SELF, 0);
 if (!res)
-return res;
+return PMCNULL;
 /* readline should better return the string w/o NL */
 len = string_length(INTERP, res);
 while (len  (((char*)res-strstart)[len-1] == '\n'
@@ -208,7 +208,8 @@
 --res-strlen;
 --res-bufused;
 }
-return res;
+PMC_str_val(pmc_res) = res;
+return pmc_res;
 }
 }

[perl #40815] Summary of 'make test' failures on Darwin

[Steve Peters via RT]

On Sat Nov 11 10:17:33 2006, [EMAIL PROTECTED] wrote:
 perl Configure.pl --without-gmp --cc=gcc --ccflags='-fno-common -pipe  
 -I/usr/local/include -pipe -fno-common'
 
 Then chromatic suggested manually editing the Makefile to delete '- 
 bundle' from the following line.
 LD_LOAD_FLAGS   = -bundle -undefined suppress
 
 make 21 | tee  ~/learn/perl/parrot.make.output.5.txt
 make test
 


The t/library/pcre.t is fixed by the patch in RT #40818.

Re: [perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris

[Steve Peters]

On Sat, Nov 11, 2006 at 04:02:21AM -0800, Joshua Hoblitt via RT wrote:
 Is this issue considered resolved for BSD and/or has acceptable test
 coverage?
 
 
I believe that things were alright for both OpenBSD and NetBSD.  Solaris
is still an issue.  t/op/trans.t passes when run like

  perl t/harness t/op/trans.t

but fails miserably when run like

  perl t/harness -v t/op/trans.t

Steve Peters
[EMAIL PROTECTED]

 On Tue Mar 21 17:46:51 2006, jisom wrote:
  It seems I'm mistaking problems.  OpenBSD does do atan2 correctly.  
  But, OpenBSD doesn't like printing -0.0.  It'll print it as positive. 
I'm not sure how to get it to print -0 instead of +0.
  
  On Mar 21, 2006, at 5:58 PM, Joshua Hoblitt wrote:
  
   Steve,
  
   What version of OpenBSD were you running (perhaps something old or
   direct from CVS)?
  
   -J
  
   --
   On Tue, Mar 21, 2006 at 03:13:18PM -0800, Joshua Isom via RT wrote:
   On OpenBSD 3.8 x86, I still get the failures with -0.0/0.0.  Check the
   smokes...
  
   On Mar 21, 2006, at 3:01 PM, Joshua Hoblitt wrote:
  
   On Tue, Mar 21, 2006 at 06:42:42AM -0800, Steve Peters via RT wrote:
   [jhoblitt - Sun Jan 01 18:49:23 2006]:
  
   I've commited a possible fix for openbsd, cygwin,  solaris as
   changesets
   r10839  r10843.  I basically applied what Steve Peters proposed 
   but
   with the changes in math.c instead of creating init.c (as agreed to
   on
   #parrot).
  
   This doesn't appear to have done anything for gcc/solaris... can
   someone
   test openbsd and cygwin?
  
   These changes fixed OpenBSD and were used with NetBSD to allow it to
   pass all of its tests.  That leaves the issue open for Solaris and
   Cygwin.
  
   Fantastic.  Thanks for the update.
  
   Can someone test this on Cygwin?
  
   -J
  
   --
  
  
  
 
 

Re: [ANNOUNCE] Test::Builder/More/Simple 0.64 (Emergency release)

[Steve Peters]

On Sun, Jul 16, 2006 at 02:53:08AM -0700, Michael G Schwern wrote:
 Miyagawa noticed that the changes to Test::Builder::Tester's
 test_fail() in 0.63 broke Test::Exception and probably plenty others.
 The change broke backwards compat and should not have been accepted.
 

Bleadperl has been upgraded to Test-Simple-0.64 with change #28586.

Thanks,

Steve Peters
[EMAIL PROTECTED]

Re: Cage Cleaning for dummies? Re: Call for Parrot Janitors

[Steve Peters]

On Thu, Jul 06, 2006 at 06:33:48AM +0100, Nicholas Clark wrote:
 On Wed, Jul 05, 2006 at 09:10:47PM -0700, chromatic wrote:
  On Wednesday 05 July 2006 19:58, Bill Ricker wrote:
 
   * Minimum GCC == whatever Perl5 was built with? or specific?
  
  Probably at least 2.9x.
 
 Why? IIRC gcc 2.7 was good and stable, and it's not like C89 has changed much
 in the past 10 years. I guess it's really down to whether the C compiler
 (gcc or otherwise) has awkward bugs on your platform.
 
   (Alas, I do _not_ have the Tru64/DEC compiler for Alpha AXP on my
   Debian/Alpha. There's someone I can talk to, I might be able to get
   it, or get access to it. Hmm.)
  
  Alpha would be very good.
 
 Any vendor compiler is very good at picking up sloppy C code. As well as
 Tru64, anyone with Irix, AIX, HP-UX, particularly if 64 bit, would be most
 welcome.
 

The MS Visual Studio compilers are also very picky, and that's where I 
made some initial contributions.

Alternative compilers on various OS's are also a good place to look for 
problems.  Intel C++ is on Linux, Windows, and Mac OS X (Intel).  The 
alpha Sun Studio compiler is available for Linux.  

Steve Peters
[EMAIL PROTECTED]

Re: Portable dirfd() (was Re: [perl #39261] stat() doesn't work on dirhandles)

[Steve Peters]

On Mon, Jul 03, 2006 at 12:22:15PM -0700, chromatic wrote:
 On Monday 03 July 2006 11:43, Steve Peters via RT wrote:
 
 (from p5p)
 
  OK, with change #28473, I just added the capabilities to a stat() or -X
  filetests for systems with the dirfd() libc call available.  There are
  two additional steps that need to be done.  First, Perl_pp_stat and
  Perl_my_stat() have a lot of similar code when doing fstat()'s.  Much of
  the common code should be refactored out.  Second, developing an
  internal dirfd() for operating systems that need it should be done so
  this functionality is more portable.  Also, adding a few extra tests
  wouldn't hurt either.
 
 I touched Parrot's File PMC the other day; could it use something like this?
 

Probably.  I have a couple of other configuration tasks I need to get 
finished for Parrot, so, I'll add a portable dirfd() implementation to 
the pile.

Steve Peters
[EMAIL PROTECTED]

Java's Scripting Framework information

[Steve Peters]

At Chip's YAPC talk, I mentioned that Java would soon be adding support 
directly to the language for scripting languages in their Java 6 or 
1.6 release.  Finding actual Sun documentation on the framework has been 
a little tough, but here's a sampling of a few articles that have been 
written just to see how things compare.  It still seems that Java is 
still very much in control, but, as the JSR title says, this is really 
about the web and embedding other languages into JSP.

Build your own scripting language for Java - 
http://www.javaworld.com/javaworld/jw-04-2006/jw-0424-scripting.html

The Mustang Meets the Rhino: Scripting in Java 6 - 
http://www.onjava.com/pub/a/onjava/2006/04/26/mustang-meets-rhino-java-se-6-scripting.html

JSR 223: Scripting for the Java Platform - 
http://www.jcp.org/en/jsr/detail?id=223

Steve Peters
[EMAIL PROTECTED]

Re: TAP::Harness

[Steve Peters]

On Sat, Jul 01, 2006 at 08:45:02PM +0100, Fergal Daly wrote:
 This might seem like an odd question but will it be tightly tied to
 TAP or will it be possible to use another protocol or an extension to
 TAP?

Pluggable testing protocols, perhaps.  They would need to follow some 
similar ground rules, though.

Steve Peters
[EMAIL PROTECTED]

Re: Unintended consequences

[Steve Peters]

On Mon, May 22, 2006 at 09:45:31PM -0500, Andy Lester wrote:
 Here's an example of why I'm not real excited about CPANTS:
 
 http://community.livejournal.com/perl/120747.html
 

I prefer Acme::Raise_my_kwalitee 
http://search.cpan.org/dist/Acme-Raise_my_kwalitee as my anti-CPANTs 
example.

Steve Peters
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: [perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful

[Steve Peters]

On Wed, May 10, 2006 at 10:30:42AM -0700, Leopold Toetsch wrote:
 # New Ticket Created by  Leopold Toetsch 
 # Please include the string:  [perl #39117]
 # in the subject line of all future correspondence about this issue. 
 # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=39117 
 
 
 See also http://use.perl.org/articles/06/05/03/1325204.shtml
 
 19:24 @leo Andy: btw - if you got some extra tuits: Using 
 v?snprintf/strlcpy/strlcat when useful would be also very welcome for 
 Parrot
 19:25 @leo strlcpy/strlcat would need a test too, snprintf should 
 already be in config tests
 19:25 @leo and we'd need an implementation, if libc doesn't provide 
 the funcs
 

I'm taking a look at it.  I should have something working this evening 
for the configs.  Adding the HAS_BLAH's will take some additional time.

Steve Peters
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: Smoke [5.9.4] 27938 FAIL(X) linux 2.6.15-20-386 [debian] (i686/1 cpu)

[Steve Peters]

[EMAIL PROTECTED] wrote:

Automated smoke report for 5.9.4 patch 27938
kirk: Intel(R) Celeron(R) CPU 2.00GHz (GenuineIntel 1994MHz) (i686/1 cpu)
onlinux - 2.6.15-20-386 [debian]
using cc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
smoketime 17 hours 54 minutes (average 1 hour 7 minutes)

Summary: FAIL(X)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:   - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

   27938 Configuration (common) none
--- -
O O O O O O 
O O O O O O -Duse64bitint

O O O O O O -Duselongdouble
O O O O O O -Dusemorebits
O O O O O O -Duseithreads
O O O O O O -Duseithreads -Duse64bitint
X O O O X O -Duseithreads -Duselongdouble
O O O O O O -Duseithreads -Dusemorebits
| | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING
| | | | +--- PERLIO = perlio -DDEBUGGING
| | | +- PERLIO = stdio  -DDEBUGGING
| | +--- LC_ALL = en_US.utf8
| +- PERLIO = perlio
+--- PERLIO = stdio

Locally applied patches:
SMOKE27938

Failures: (common-args) none
[stdio] -Duseithreads -Duselongdouble
Inconsistent test results (between TEST and harness):
../ext/threads/t/free.t.FAILED--expected test 18, saw test 
19

[perlio] -DDEBUGGING -Duseithreads -Duselongdouble
Inconsistent test results (between TEST and harness):
../ext/threads/t/free.t.FAILED--expected test 15, saw test 
16



What's happening above is that TEST cannot handle seeing tests come in 
out of order, while harness can. I'm scanning Test::Harness::TAP a bit, 
but it seems to be unspecified whether this is OK or not.  Should TEST 
care if the tests are reported out of order?


Steve Peters
[EMAIL PROTECTED]

Re: TODO tests and test::harness

[Steve Peters]

On Wed, Apr 19, 2006 at 07:22:33AM +0200, demerphq wrote:
 On 4/19/06, Andy Lester [EMAIL PROTECTED] wrote:
   BTW, the patch only shows TODO pass status when no failures occur.
  
   Oh and obviously all of Test::Harness'es tests pass. :-)
 
  This patch doesn't apply against my latest dev version of
  Test::Harness.  I'm going to have to massage it manually.
 
  But I like the idea.  Thanks.
 
 You're welcome. If it helps It was against Test-Harness-2.56.
 

Maybe I'm thinking too hard, or maybe the results reported aren't
exactly as clear as they probably should be.  Here's an example test and
its results as reported by Test::Harness with the TODO changes.

#!perl -w

use strict;
use Test::More qw(no_plan);

TODO: {
local $TODO = TODO testing;
is(1, 2, A failing test);
is(1, 1, A passing test);
}
[EMAIL PROTECTED]:~/smoke/perl-current/t$ ./perl harness th_test.t
th_testok
1/2 unexpectedly succeeded
TODO PASSED tests 1-2

All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED).
Passed Test Stat Wstat Total Pass  Passed  List of Passed
---
th_test.t  21  50.00%  1-2
Files=1, Tests=2,  0 wallclock secs ( 0.11 cusr +  0.01 csys =  0.12
CPU)

The line starting TODO PASSED shows all TODO tests, not those that
unexpectedly succeeded, which confused me a bit.  Also, the final
results show that one test passed, but then the list of passed is 1-2
instead of just 2 which is the unexpected success.  Is there a way to
have the list of passed just show the unexpected successes?

Steve Peters
[EMAIL PROTECTED] 


signature.asc
Description: Digital signature

Re: TODO tests and test::harness

[Steve Peters]

On Thu, Apr 20, 2006 at 10:36:08PM +0200, demerphq wrote:
 On 4/20/06, Steve Peters [EMAIL PROTECTED] wrote:
  Maybe I'm thinking too hard, or maybe the results reported aren't
  exactly as clear as they probably should be.  Here's an example test and
  its results as reported by Test::Harness with the TODO changes.
 
  #!perl -w
 
  use strict;
  use Test::More qw(no_plan);
 
  TODO: {
  local $TODO = TODO testing;
  is(1, 2, A failing test);
  is(1, 1, A passing test);
  }
  [EMAIL PROTECTED]:~/smoke/perl-current/t$ ./perl harness th_test.t
  th_testok
  1/2 unexpectedly succeeded
  TODO PASSED tests 1-2
 
  All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED).
  Passed Test Stat Wstat Total Pass  Passed  List of Passed
  ---
  th_test.t  21  50.00%  1-2
  Files=1, Tests=2,  0 wallclock secs ( 0.11 cusr +  0.01 csys =  0.12
  CPU)
 
  The line starting TODO PASSED shows all TODO tests, not those that
  unexpectedly succeeded, which confused me a bit.  Also, the final
  results show that one test passed, but then the list of passed is 1-2
  instead of just 2 which is the unexpected success.  Is there a way to
  have the list of passed just show the unexpected successes?
 
 Attached patch should fix it up. Both in terms of making it clearer
 and of fixing the list. So your test file would look like:
 
 All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 37 subtests skipped.
 Passed Todo  Stat Wstat Todos Pass  Passed  List of Passed
 ---
 t/demerphq.t21  50.00%  3
 Files=19, Tests=572,  8 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00 CPU)
 
 Hopefully thats clearer. The Todos column shows how many todos there
 are in the file.
 

Excellent!  It seems to be working more as I was hoping to see.  This
patch was applied as change #27925.

Steve Peters
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: TODO tests

[Steve Peters]

On Tue, Apr 18, 2006 at 06:30:20PM +0100, Nicholas Clark wrote:
 Last time I checked the core has 6 TESTS UNEXPECTEDLY SUCCEEDED
 What's the expected number of unexpected successes?
 Can it be made to be zero, even though we're testing the test modules?
 
 If so, I think that that would be useful, as it would mean that any (real)
 TODO test that unexpectedly started passing would be noticed.
 
 I bring this up because we seem to have inadvertently fixed really old regexp
 bugs that we didn't have a test case for, but I realise that right now adding
 TODO tests wouldn't actually have been *that* useful - if a TODO passes we
 don't notice.
 
 It would be good if we were in a position to notice. I'm not sure how much
 work that would be.
 

One of my unwritten TODOs is to go through the current Perlbug queue and
write test cases for all the currently testable problems.  My hope is
that unexpected fixes would be caught much sooner in these cases.  I've
made a bit of a start on this, and given tuits (or proper financial
motivation) I'm hoping to finish it sometime this year.  Of course,
writing new test cases for new tickets as they come in would help this
task immensely.

In the long term, however, it would be great if Test::Harness recognized
individual TODO test cases that passed and reported on them.  Maybe this
would be worthy of a Summer of Code project, or it may actually be
something much easier and basic that a normal grant would work for this.


Steve Peters
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

[perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris

[Steve Peters via RT]

 [jhoblitt - Sun Jan 01 18:49:23 2006]:
 
 I've commited a possible fix for openbsd, cygwin,  solaris as
changesets  
 r10839  r10843.  I basically applied what Steve Peters proposed but
 with the changes in math.c instead of creating init.c (as agreed to on
 #parrot).
 
 This doesn't appear to have done anything for gcc/solaris... can someone
 test openbsd and cygwin?

These changes fixed OpenBSD and were used with NetBSD to allow it to
pass all of its tests.  That leaves the issue open for Solaris and Cygwin.

Re: Activestate and Scalar-List-Utils

[Steve Peters]

On Tue, Mar 14, 2006 at 04:12:43PM -0500, David Golden wrote:
 So back at the beginning of February, there was some email traffic about 
 how ActiveState's automated PPM build system was using an outdated 
 version of Scalar-List-Utils, which was causing a cascading prerequisite 
 failure for many distributions.
 
 Has anyone heard any updates on this?  Does anyone have an inside 
 contact at ActiveState that can shed some more light on the subject?
 

The problem was that newer Scalar-List-Utils uses an internal Perl
function that Windows does not see as an exported function.  This was
changed with Perl 5.8.8.  Once ActiveState releases a Perl 5.8.8, they
should be able to upgrade the version of Scalar-List-Utils that they
distribute.

Steve Peters
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: unused unimplemented opcodes

[Steve Peters]

On Wed, Mar 08, 2006 at 05:16:37PM +0100, Leopold Toetsch wrote:
 There are some opcodes in core.ops which don't do anything:
 
 I'd do:
 
   setline   ... delete, doesn't make sense
   getline   ... move to debug.ops, implement it
   setfile   ... delete
   getfile   ... mpve to debug.ops, implement it
   setpackagedelete
   getpackagedelete - use get_namespace instead
 
 Any objections?
 

Please chainsaw away!

Steve Peters
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: [PATCH] Compiling Parrot on NetBSD

[Steve Peters]

On Thu, Mar 02, 2006 at 09:31:04AM -0500, Andy Dougherty wrote:
 On Wed, 1 Mar 2006, Steve Peters wrote:
 
  Thanks to the work that's already been done, it was very easy to get NetBSD 
  up
  and running.  The attached patch is all that's needed to add NetBSD support 
  to
  Parrot.
 
 I don't know the answer myself, but I was wondering:  Have all the various 
 *BSD distributions drifted apart far enough that it makes sense to 
 maintain completely independent hints and platform directories for each?
 

FreeBSD is certainly different from NetBSD and OpenBSD.  Those two are 
fairly close, but differ in support for various reentrant functions,
when threading became part of the libc, etc.  Overall, they are very
close.  As far as DragonflyBSD, BSDI (officially dead), PC-BSD, etc.,
I've not used any of them, so, I can't really say where they should
fall.

It partially comes down to how the directories are structured.  The
current structure is very logical and makes it easy to find where all
the code is coming from.  Merging them together, of course, reduces the
overall lines of code.  I guess it depends on what makes Parrot
easier to maintain and develop.

Steve Peters
[EMAIL PROTECTED]



signature.asc
Description: Digital signature

[PATCH] Compiling Parrot on NetBSD

[Steve Peters]

Thanks to the work that's already been done, it was very easy to get 
NetBSD up and running.  The attached patch is all that's needed to add 
NetBSD support to Parrot.


Steve Peters
[EMAIL PROTECTED]

+# Copyright: 2006 The Perl Foundation.  All Rights Reserved.
+# $Id$
+
+package init::hints::netbsd;
+
+use strict;
+
+sub runstep
+{
+my ($self, $conf) = @_;
+
+my $ccflags = $conf-data-get('ccflags');
+if ($ccflags !~ /-pthread/) {
+$ccflags .= ' -pthread';
+}
+$conf-data-set(ccflags = $ccflags);
+
+my $libs = $conf-data-get('libs');
+if ($libs !~ /-lpthread/) {
+$libs .= ' -lpthread';
+}
+$conf-data-set(libs = $libs);
+}
+
+1;
--- /dev/null   2006-03-01 20:37:19.0 -0600
+++ config/gen/platform/netbsd/math.c   2006-03-01 20:15:46.0 -0600
@@ -0,0 +1,44 @@
+/*
+ * math stuff
+ */
+
+/*
+ * force atan2() to use IEEE behavior
+ */
+
+#include math.h
+
+_LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;
+
+/*
+ * return true if the Numval has a negative sign
+ */
+#if DOUBLE_SIZE == 2 * INT_SIZE
+int
+Parrot_signbit(double x)
+{
+   union {
+   double d;
+   int i[2];
+   } u;
+   u.d = x;
+#if PARROT_BIGENDIAN
+   return u.i[0]  0;
+#else
+   return u.i[1]  0;
+#endif
+}
+#endif
+
+#if NUMVAL_SIZE == 12  DOUBLE_SIZE == 3 * INT_SIZE  PARROT_LITTLE_ENDIAN
+int
+Parrot_signbit_l(long double x)
+{
+   union {
+   long double d;
+   int i[3];
+   } u;
+   u.d = x;
+   return u.i[2]  0;
+}
+#endif

Re: [PATCH] Compiling Parrot on NetBSD

[Steve Peters]

Steve Peters wrote:
Thanks to the work that's already been done, it was very easy to get 
NetBSD up and running.  The attached patch is all that's needed to add 
NetBSD support to Parrot.



I should add that it passes all test too :)

Steve Peters
[EMAIL PROTECTED]

Re: MAKE SCHWERN PAY!

[Steve Peters]

On Tue, Feb 21, 2006 at 01:46:23PM -0800, Michael G Schwern wrote:
 On 2/20/06, Steve Peters [EMAIL PROTECTED] wrote:
 
  Remeber you are helping a good cause by getting and extra $500 to the
  Perl Foundation, but you're also helping to tear Schwern away from
  Worlds of Warcraft for a few minutes to write the check.
 
 
 Sad but true.
 
 Now if the tests were written in Lua...

I don't know if I could sneak Inline::Lua into the core, but if you
distract Rafael and Nicholas, maybe I can try. ;)

Steve Peters
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

MAKE SCHWERN PAY!]

[Steve Peters]

Hi all,

Recently, we've been closing in on making all the modules in the bleadperl
tested.  That's a great achievement.  We do, however, have a ways to 
go to completely earn the money.

As the fine print takes away(*), the modules must be reasonably tested
as judged by the then bleadperl pumpking Jarkko.  Whether this
responsibility on to Rafael is somewhat uncertain.  So, my guess is that
test coverage needs to be improved in several modules to accomplish
this task.  I don't have stats on pure-Perl modules at the moment, but 
XS-based modules in desparate need of additional testing:

POSIX
B (pick one, any one)
Devel::DProf
Devel::Peek
DynaLoader
Hash::Util
IPC::SysV

Any help that anyone can be provided would be great.  Also, if you look
into a module and you can't figure out how you'd ever test parts of it,
please let everyone know.  This helps to make the case that reasonable
testing has been completed.

Remeber you are helping a good cause by getting and extra $500 to the
Perl Foundation, but you're also helping to tear Schwern away from
Worlds of Warcraft for a few minutes to write the check.

Thanks in advance,

Steve Peters
[EMAIL PROTECTED]

*http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-04/msg01223.html


signature.asc
Description: Digital signature

Re: [perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris

[Steve Peters]

On Mon, Jan 02, 2006 at 09:01:55AM -0600, Greg Bacon wrote:
 In message [EMAIL PROTECTED],
 Joshua Hoblitt via RT writes:
 
 : I've commited a possible fix for openbsd, cygwin,  solaris as changesets  
 : r10839  r10843.  I basically applied what Steve Peters proposed but
 : with the changes in math.c instead of creating init.c (as agreed to on
 : #parrot).
 : 
 : This doesn't appear to have done anything for gcc/solaris... can someone
 : test openbsd and cygwin?
 
 After upping to r10844, trans.t still fails:
 

What operating system are you using?

Steve Peters
[EMAIL PROTECTED]

[perl #34549] [PATCH] t/op/trans.t failure on OpenBSD

[Steve Peters via RT]

 [stmpeters - Tue Mar 22 15:41:12 2005]:
 
 When running testing parrot-HEAD, I get a test failure in 
t/op/trans.t on 
 OpenBSD.  Running the same tests on Linux seem to work just fine...
 
  perl -Ilib t/op/trans.t
 1..19
 ok 1 - sin
 ok 2 - cos
 ok 3 - tan
 ok 4 - sec
 ok 5 - atan
 ok 6 - asin
 ok 7 - acos
 ok 8 - asec
 ok 9 - cosh
 ok 10 - sinh
 ok 11 - tanh
 ok 12 - sech
 not ok 13 - atan2
 # Failed test (t/op/trans.t at line 307)
 #  got: 'ok 1
 # ok 2
 # ok 3
 # ok 4
 # ok 5
 # ok 6
 # ok 7
 # ok 8
 # ok 9
 # ok 10
 # ok 11
 # ok 12
 # ok 13
 # ok 14
 # ok 15
 # ok 16
 # not 0.00ok 17
 # '
 # expected: 'ok 1
 # ok 2
 # ok 3
 # ok 4
 # ok 5
 # ok 6
 # ok 7
 # ok 8
 # ok 9
 # ok 10
 # ok 11
 # ok 12
 # ok 13
 # ok 14
 # ok 15
 # ok 16
 # ok 17
 # '
 ok 14 - log2
 ok 15 - log10
 ok 16 - ln
 ok 17 - exp
 ok 18 - pow
 ok 19 - sqrt
 # Looks like you failed 1 tests of 19.
 
 

Included below is a patch that fixes the above test failures on 
OpenBSD.  I've also included code to fix the problem on Cygwin (see 
ticket #36835) although I could not get Cygwin to compile with or 
without my patch.  A similar solution will likely work on a gcc-
compiled Solaris, but I discuss that in the more recent ticket there.  
I'm also guessing that NetBSD will require a similar patch, but I need 
to get on a NetBSD machine a test my patch.  Expect that patch later 
today.

--- MANIFEST.oldThu Dec 29 00:03:32 2005
+++ MANIFESTThu Dec 29 08:31:01 2005
@@ -189,6 +189,7 @@
 config/gen/platform/ansi/dl.c []
 config/gen/platform/ansi/exec.c   []
 config/gen/platform/ansi/io.h []
+config/gen/platform/cygwin/init.c []
 config/gen/platform/ansi/time.c   []
 config/gen/platform/darwin/begin.c[]
 config/gen/platform/darwin/dl.c   []
@@ -197,6 +198,7 @@
 config/gen/platform/generic/dl.h  []
 config/gen/platform/generic/env.c []
 config/gen/platform/generic/exec.c[]
+config/gen/platform/generic/init.c[]
 config/gen/platform/generic/io.h  []
 config/gen/platform/generic/itimer.c  []
 config/gen/platform/generic/math.c[]
@@ -210,6 +212,7 @@
 config/gen/platform/generic/threads.h []
 config/gen/platform/generic/time.c[]
 config/gen/platform/ia64/asm.s[]
+config/gen/platform/openbsd/init.c[]
 config/gen/platform/openbsd/memexec.c []
 config/gen/platform/openbsd/misc.h[]
 config/gen/platform/platform_interface.h  []
--- /dev/null   Thu Dec 29 05:43:20 2005
+++ config/gen/platform/generic/init.c  Wed Dec 28 23:11:38 2005
@@ -0,0 +1,3 @@
+/* Placeholder for platform specific initializations (header includes,
+ * global variable initialization, etc.
+ */
--- /dev/null   Thu Dec 29 05:43:38 2005
+++ config/gen/platform/openbsd/init.c  Wed Dec 28 23:23:45 2005
@@ -0,0 +1,3 @@
+#include math.h
+
+_LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;
--- /dev/null   Thu Dec 29 05:43:38 2005
+++ config/gen/platform/cygwin/init.c  Wed Dec 28 23:23:45 2005
@@ -0,0 +1,3 @@
+#include math.h
+
+const _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;

[perl #38060] [BUG] atan2() broken on Solaris with gcc

[Steve Peters via RT]

 [EMAIL PROTECTED] - Wed Dec 28 14:07:26 2005]:
 
 A quick demonstration of the issue:
 
 --
 #include stdio.h
 #include math.h
 
 int main ()
 {
 printf(%f\n, atan2(0.0, 0.0));
 printf(%f\n, atan2(-0.0, -0.0));
 }
 --
 
 --
 $ gcc foo.c -lm
 $ ./a.out
 0.00
 0.00
 --
 
 This is also documented in config/init/hints/solaris.pm:
 
 
 # Parrot usually aims for IEEE-754 compliance.
 # For Solaris 8/Sun Workshop Pro 4, both
 #atan2( 0.0, -0.0) and atan2(-0.0, -0.0)
 # return 0, when they should return +PI and -PI respectively.
 # For Sun's compilers, fix this with the -xlibmieee flag.
 # I don't know of an equivalent flag for gcc.
 # (Alternatively, and more generally, perhahs we should run an
 # ieee-conformance test and then call back into a hints-file 
trigger
 # to set platform-specific flags.
 #   A. Dougherty  7 March 2005
 # We don't know which compiler we're using till after the 
gccversion
 # test.
 
 
 The question is, can we get atan2() to 'behave' with gcc or do we need
 to provide our own implementation?

As Sun is the original author of the BSD math libraries, NetBSD, 
OpenBSD, and Cygwin are all similarly effected by this problem (see RT# 
34549 and 36835).  On Solaris, however, they've made the switch from 
BSD to ATT based math libraries, so some #ifdef's are probably needed 
for Solaris.  The code below is untested, but should solve the problem 
you are seeing after the patch for problem #34549 is applied.

--- /dev/null   Thu Dec 29 08:50:54 2005
+++ config/gen/platform/solaris/init.c  Thu Dec 29 08:50:26 2005
@@ -0,0 +1,4 @@
+#include math.h
+#if defined(__GNUC__)  defined(_LIB_VERSION)
+_LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;
+#endif

Re: Most Perl6 developers running linux on i386?

[Steve Peters]

On Wed, Dec 28, 2005 at 09:50:49PM -0500, Peter Schwenn wrote:
 I've spent a couple of days trying out Cygwin, MinGW, PXPerl,  and other 
 Windows based contexts, in order to build Pugs w/Embedded Parrot.  I've 
 learned a lot about configuration and little else.
 
 Would I be right in supposing that most people working on Perl6 and 
 Parrot development, and spend relatively little time jiggering configs 
 and makes, are working under Linux on i386 machines?  (excluding a few 
 who have had plenty of time to get a VS6/7 or Cygwin or ... environment 
 straightened out.)
 

These problems have come and gone over the years as people have taken up the
challenge of making Parrot compile and pass its tests on their system.   I
believe, however, that we've only seen the tip of the iceberg as I don't
recall complaints or patches regarding Parrot compiles on z/OS, VMS, BeOS, or
some of the other OS's that Perl 5 currently supports.  My hope and expectation
is that as th various Perl 6 projects start to look more like the end
product, more of these issues will come up.  I also expect that more active
developers will be picked up along the way to deal wtih these problems.  So, 
for me, I'm concerned, but I surely expect that none of these problems on 
Win32 based systems current is an indication of the level of support to expect
from these systems in the future. 

Steve Peters
[EMAIL PROTECTED]

Re: Devel::Cover not DWIMming on upgraded Perl -- but problem solved

[Steve Peters]

On Tue, Nov 01, 2005 at 08:25:36PM -0500, James E Keenan wrote:
 When I began to write this posting, it was to get an answer to a 
 question.  But I figured out a workaround halfway through, so now I'm 
 posting an answer.
 
 I have happily been using Devel::Cover for more than a year on Perl 
 5.8.4 on Darwin (Mac OS X 10.3).  Recently I upgraded to Perl 5.8.7. 
 Tonight I went to use Devel::Cover (v0.55, as previously) for the first 
 time since that Perl upgrade.  At first, it no longer DWIMmed. 
 Specifically:
 
 1.  When I ran 'make test HARNESS_PERL_SWITCHES=MDevel::Cover', I got 
 this message:
 
 t/01_test..
 This version of Devel::Cover was built with Perl version 5.008004.
 It is now being run with Perl version 5.008007.
 Attempting to make adjustments, but you may find that some of your 
 modules do
 not have coverage data collected.  You may need to alter the +-inc, 
 +-ignore
 and +-select options.
 
 t/01_test..ok
 
 I'd never had to set these options before; previously, D::C just worked. 
  Also, D::C took much longer to run.
 
 2.  I was testing coverage of a new module I'm developing called 
 File::Save::Home.  When I called 'cover', I got a report on this module, 
 but also on every core module as well:
 
 [snip]
  -- -- -- -- -- 
 -- --
 File   stmt   bran   condsubpod 
 time  total
  -- -- -- -- -- 
 -- --
 ...perl5/5.8.7/AutoLoader.pm0.00.00.00.00.0 
 n/a0.0
 ...l/lib/perl5/5.8.7/Carp.pm0.00.00.00.00.0 
 n/a0.0
 ...erl5/5.8.7/Digest/base.pm0.00.0n/a0.00.0 
 n/a0.0
 ...b/perl5/5.8.7/Exporter.pm   50.0   57.1   44.7   33.30.0 
 0.3   44.8
 ...5/5.8.7/Exporter/Heavy.pm   10.48.8   12.5   11.10.0 
 0.19.8
 ...l5/5.8.7/File/Basename.pm   28.2   25.87.7   50.0  100.0 
 0.1   27.8
 [snip]
 8.7/warnings/register.pm  100.0   50.0n/a  100.00.0 
 0.1   89.5
 blib/lib/File/Save/Home.pm 77.1   44.4n/a  100.0  100.0 
 0.3   73.4
 Total  10.86.24.3   12.3   14.0 
 100.09.0
  -- -- -- -- -- 
 -- --
 
 
 Writing HTML output to
 /Users/jimk/work/fsh/File-Save-Home/cover_db/coverage.html ...
 done.
 
 This problem of excessive output is the same one I typically experience 
 using D::C (v0.47, I believe) on Windows.  This is much more output than 
 I want or need.
 
 I hypothesized that if I were to upgrade to a new version of D::C, it 
 would be compiled against Perl 5.8.7 and these problems might go away. 
 But 'cpan' did nothing because it detected that I was using the most 
 recent version of D::C.
 
 So I downloaded the latest version of Devel::Cover from CPAN and 
 installed it manually.  (I did call 'make install UNINSTALL=1'.)  This 
 solved the problem.  The message described above went away, and 'cover' 
 reported only the results for the module under development.
 

I don't know if that is in the documentation for Devel::Cover or not,
but an upgrade in Perl usually requires and reinstall of Devel::Cover.

Steve Peters
[EMAIL PROTECTED]

Re: new sigil

[Steve Peters]

On Fri, Oct 21, 2005 at 11:03:07AM +0200, Bra??o Tichý wrote:
 /lurk
 - Original Message - 
 From: Steve Peters [EMAIL PROTECTED]
 To: Luke Palmer [EMAIL PROTECTED]
 Cc: perl6-language@perl.org
 Sent: Friday, October 21, 2005 4:21 AM
 Subject: Re: new sigil
 
 
 
 But I may have to support your code.  That's the issue.
 
 
 Isn't perl6 assuming the source file is in UTF-8 unless explicitly 
 specified differently?

My point is that there is a difference between the source file being in
Unicode and depending on characters outside of ASCII.  If someone wants
to code using whatever Unicode characters they want, that's fine.  Not
every computer or editor can do Unicode out of the box.  The issue 
starts when people are required to write code outside of ASCII and that
is not available.

 
 Also it's quite interesting how often was Latin-1 and UTF-8 used in the 
 discussion interchangeably;
 every source is Latin-1 is marginally better than every source is 
 ASCII, but we can do better.
 
 As for keyboard layouts: I don't think there is Yen sign on US keyboard 
 either.

And that is as much of an issue.

 bra??o
 
 P.S. this e-mail should be sent in UTF-8.

And I see your name as bra??o :)

Re: new sigil

[Steve Peters]

On Fri, Oct 21, 2005 at 09:42:00AM +0100, Carl Franks wrote:
 Where did you get ALT-155 from?
 
 I've just checked the windows Character Map, and ¢ (cent) is ALT-0162
 ( If it's not in your startmenu, do start - run - charmap )

Actually, both work.  That's where the issus with the documentation starts.
 
 It displays in Eclipse (3.1.1) whether the Text File Encoding is set to
 Cp1252 (default) or UTF-8 or ISO-8859-1

Older versions of Eclipse are not able to enter these characters.  That's
where the copy and paste comes in.

Steve Peters
[EMAIL PROTECTED]

Re: new sigil

[Steve Peters]

On Fri, Oct 21, 2005 at 02:37:09PM +0200, Juerd wrote:
 Steve Peters skribis 2005-10-21  6:07 (-0500):
  Older versions of Eclipse are not able to enter these characters.  That's
  where the copy and paste comes in.
 
 That's where upgrades come in.
 
That's where lots of money to update to the next version of WSAD becomes the
limiting factor.

Steve Peters
[EMAIL PROTECTED]

Re: new sigil

[Steve Peters]

On Fri, Oct 21, 2005 at 09:35:12AM -0400, Rob Kinyon wrote:
 On 10/21/05, Steve Peters [EMAIL PROTECTED] wrote:
  On Fri, Oct 21, 2005 at 02:37:09PM +0200, Juerd wrote:
   Steve Peters skribis 2005-10-21  6:07 (-0500):
Older versions of Eclipse are not able to enter these characters.  
That's
where the copy and paste comes in.
  
   That's where upgrades come in.
  
  That's where lots of money to update to the next version of WSAD becomes the
  limiting factor.
 
 So, you are proposing that the Perl of the Unicode era be limited to
 ASCII because a 15 year old editor cannot handle the charset? That's
 like suggesting that operating systems should all be bootable from a
 single floppy because not everyone has access to a CD drive.

I saying that, since my up-to-date version of vi on my up-to-date OpenBSD
can't type, much less even allow me to paste in, a Latin-1 character, this
is an issue.

Re: new sigil

[Steve Peters]

On Fri, Oct 21, 2005 at 10:30:40AM -0400, Rob Kinyon wrote:
   So, you are proposing that the Perl of the Unicode era be limited to
   ASCII because a 15 year old editor cannot handle the charset? That's
   like suggesting that operating systems should all be bootable from a
   single floppy because not everyone has access to a CD drive.
 
  I saying that, since my up-to-date version of vi on my up-to-date OpenBSD
  can't type, much less even allow me to paste in, a Latin-1 character, this
  is an issue.
 
 You're still using the base vi vs. vim?!? I didn't know people did
 that when it wasn't 3am on Sunday when trying to fix a borked /etc ...
 Huh!

I honestly don't know or care what flavor of vi I using, since it usually
changes depending on what *nix flavor I'm working on.  I also don't think that
it should make a difference what editor I'm using with a programming language.
Others seem to think differently.  C'est la vie.

Steve Peters
[EMAIL PROTECTED]

Re: new sigil

[Steve Peters]

On Fri, Oct 21, 2005 at 05:27:53PM +0200, Schneelocke wrote:
 On 21/10/05, Steve Peters [EMAIL PROTECTED] wrote:
  I honestly don't know or care what flavor of vi I using, since it usually
  changes depending on what *nix flavor I'm working on.  I also don't think 
  that
  it should make a difference what editor I'm using with a programming 
  language.
  Others seem to think differently.  C'est la vie.
 
 It won't make a difference. Even if you're in an environment where you
 can neither type nor copy'n'paste the cent sign, you can still use the
 ASCII version of the sigil. Sure, it's going to be one extra
 keystroke, but that's not really a big issue - and even less so when
 you consider that you probably won't be using the class sigil as often
 as the others, anyway.
 
 The amount of typing that was required for your emails in this thread
 so far probably exceeds the amount of extry typing you'll have to do
 to use the ASCII version of the sigil for your entire life already. :)

For me, all that you have written above is correct.  That still does not
fix that potential advocacy and documentation issues that are created by
this.  Someone who is new to Perl 6 after its released may not know the
difference.  That's the problem.

Steve Peters
[EMAIL PROTECTED]

Re: new sigil

[Steve Peters]

On Thu, Oct 20, 2005 at 07:56:09AM -0700, Larry Wall wrote:
 I don't know how long this EuroOSCON net is going to stay up, so I'll be
 brief.  I think we're having a new class sigil.  Where we've been
 writing ::T, that will revert to meaning an existing class T that
 we just might not see the declaration of for dynamic reasons.  Instead,
 the new sigil is the cent sign, so ::T is now written ¢T instead.
 
Looking at my U.S. English keyboard, I don't have a cent sign.  I don't
think a sigil that can't be typed (or easily typed) is something that
should be used.  

Steve Peters
[EMAIL PROTECTED]

Re: new sigil

[Steve Peters]

On Thu, Oct 20, 2005 at 05:17:57PM +0200, Juerd wrote:
 Juerd skribis 2005-10-20 17:03 (+0200):
  4. Why not ^, which is available?
 
 Or the euro symbol, which also has a C in it. It doesn't always have to
 be American ;) It's in iso-8859-15, which is compatible enough with
 iso-8859-1 to support ¥ and both « and ». (I hope those turn out as Y,
  and 's pretty equivalents.)
 
I think that you can type the above characters on some systems, but others,
like the one I'm using right now, I can't even copy and paste those characters
in.  I also know that on Windows, those characters may be available, but, for
the typical user, these characters are annoyingly impossible to write.  For 
example to type the yen symbol, its an ALT-0165 and requires the numeric
keypad. 

The idea of punishing programmers who choose to use certain operating system
or locales just doesn't seem right to me.

Steve Peters
[EMAIL PROTECTED] 

Re: new sigil

[Steve Peters]

On Thu, Oct 20, 2005 at 05:03:27PM -0400, Rob Kinyon wrote:
 On 10/20/05, Steve Peters [EMAIL PROTECTED] wrote:
  I have some serious concerns about using Latin-1 sigils within Perl 6 and
  the ASCII multi-character aliases.  Am I not understanding something that
  I should see this as an advantage?
 
 I had the same concern a few months back. I've come to see the light
 in this fashion:
 1) more and more Perl programmers come from non-English countries.
 Heck, the Pugs effort is at least 50% non-US, if not more. None of the
 are on US soil and very few of the leaders are US citizens.

Surely you aren't suggesting that these non-English speakers do not have
access to the ASCII (or EBCDIC) character sets for their editors, are you?

 2) More and more of us are programming with internationalization
 (i18n) in mind. Just recently, I had to edit french text within the
 templates of an app I work on. If you haven't already, you will be
 doing so in the near future, within the next 3 years.

I have worked on an app that needed to work with English (US and GB), 
German, and Japanese.  I do not, however, remember having to write my
code in anything but ASCII.

 3) Every editor (with very few exceptions) can display Latin-1
 and, with a few more exceptions, can input Latin-1. If your favorite
 editor cannot, then that's something to bring up with the authors.

As I mentioned earlier, most programmers in a corporate environment have
limited access to system settings.  Changing them in some cases can cause
reprimands or dismissal.  Systems are often set up with the bare minimum
of locales and character sets necessary to do the job.  Also, you have to
deal with the situations where programmers are connecting to *nix servers
through a variety of Windows-based XWindows servers (Exceed, Cygwin, etc.)
complicates what character sets are available immensely.

Also, what settings changes do I need to make to get Latin-1 on 
enter any operating system or editor here?  Welcome to your documentation
nightmare!  In Perl 5, we have a nearly impossible time keeping track of where
Microsoft has put their free compiler tools.  Now multiply that by the 
number of Linux distributions, BSD distributions, and various other operating
systems.  Don't forget different versions will do it differently, and have
documentation in different places.  Some of the documentation won't even be
available on the Internet, so Perl 6 would need to reference it in some way.
Are you beginning to get the magnitude of the documentation problem?

 
 Windows ... yeah. As you pointed out, the old joke goes Doctor,
 it hurts when I use Windows . . . then, don't use Windows!

Well over 95% of the desktop computers in a corporate environment are using
Windows.  If you are suggesting Perl 6 ignores Windows, then we should all
start writing Perl 6's obituary.  This sort of attitude does nothing to
advance Perl 6.

 With the availability of dual-booting into FreeBSD/Linux (given the
 near-complete migration of all the necessary Office products) and both
 gvim and emacs having been successfully ported to WIn32, there is a
 way to do it. gvim on WinXP will do all Latin-1 charset with the vim
 keys. (I don't know about emacs, but I'd be shocked if it didn't.) If
 your IT department's policy is rigid, a quick discussion with your
 manager's manager will solve that problem immediately. Or, the cost of
 a few lunches with your favorite IT person will exempt your computer
 from the nightly audit. ($50 goes a long way ...)
 
Again, I'd prefer not to be fired.  Everything you have written above is
not an option for the majority of the programmers out there.  Also, not
to helpful if you write your programs in TSO on an IBM mainframe.

 Personally, I plan on using every single Latin-1 operator I am
 given access to. All the cool kids will ...
 
Famous last words have never been more finely spoken.  Ignoring Windows and
other environments without ready access to Latin-1 seems like a horrible 
mistake to me.  While the cool kids are playing with their Latin-1 sigils, 
programmers in corporate environments where Latin-1 isn't available will 
start writing their new systems in Java, Ruby, or .NET.  

Steve Peters
[EMAIL PROTECTED]

Re: new sigil

[Steve Peters]

On Thu, Oct 20, 2005 at 04:23:44PM -0600, Luke Palmer wrote:
 On 10/20/05, Steve Peters [EMAIL PROTECTED] wrote:
  Like the old joke goes Doctor, Doctor, it hurts when I try to type a 
  Latin-1
  character.  So don't try to type Latin-1 characters!  Instead, many
  programmers will to use the ASCII equivolents that will require additional
  keystrokes.
 
 You mean additional keystroke.  We haven't yet developed any ASCII
 equivalent that takes more than two characters.  For most cases, the
 ASCII equivalents are easier to type than the Latin-1 versions. 
 However, being a Perl 6 programmer myself, I still use the Latin-1
 versions because I like how they look and feel better.  But nobody is
 forcing you to do the same.

But I may have to support your code.  That's the issue.

 
 The one thing you have to worry about is if you use an editor that
 doesn't support Latin-1 to read somebody else's code.  However, many
 many popular editors are capable of doing this, and any editor that
 doesn't probably will soon.  We've been over this and over this.

I'd say a lot more editors support ASCII than Latin-1.  Also, you are also
assuming that programmers have control over what tools they have available,
and have the ability to upgrade whenever they wish.  I've found this to be
very far from reality.  I understand that the ability to process the code
as Unicode is an important feature of Perl 6.  There is a big difference
between allowing it and requiring it.  Writing off a large number of 
editors, and even operating systems, seems like a big shot in the foot.

My biggest concern, however, relates to advocacy.  There will need to be
books, magazine articles, tutorials, etc. written to announce the arrival
of Perl 6.  If the code uses Latin-1 characters, and people are unable to 
look at the example code in their favorite editor or type in some of the
example code, we'll lose that person to Perl 6.  The other alternative is 
to preface every article with the explanation of the separate ASCII/Latin-1
sigils.  That doesn't sound practical, and cannot be policed or enforced.

 
 Also, don't think of the class sigil as a sigil.  You won't be writing
 it very often.  Just think of it as an operator.
 
 My final point:  we don't introduce unicode characters lightly.  We do
 so when we think it is the best symbol for the job, optimizing, for
 once, for readability rather than writability.

As you mentioned above, readibility is a big issue.  If I can't tell one sigil
from another, or cannot even see it, how can I support the code?

 If you don't think the
 class sigil should be a unicode character, come up with a better one. 
 We're not going to say You're right, Steve.  No more unicode sigils!
 until wee see a good alternative to the unicode sigil that we have.

~ seems to be available for a sigil, if my reading of S02 is correct, and
the cent sign is replacing :: in all cases.  If not (that is $::foo is
still the global variable named foo) then * may also be available.

Steve Peters
[EMAIL PROTECTED]

Re: new sigil

[Steve Peters]

On Thu, Oct 20, 2005 at 10:40:44PM -0400, Rob Kinyon wrote:
  Surely you aren't suggesting that these non-English speakers do not have
  access to the ASCII (or EBCDIC) character sets for their editors, are you?
 
 Surely you aren't suggesting that your editor doesn't have access to
 the Latin-1 charset, are you? Let's take a look at popular editors:
 vi - check
 emacs - check
 eclipse - check
 mutt - check (http://www.rano.org/mutt.html)
 Notepad - check
 A bazillion other editors - check
 (http://www.alanwood.net/unicode/utilities_editors.html)

Not every installed version of the above can handle Latin-1 by default.  Since
many programmers have little control over their installed software, this 
remains an issue.  Also, the ability to do this within the application is
not well documented within many editors.  Finally, most will of the above allow 
you to paste in Latin-1 or even UTF-8 data, but the ability to actually 
enter it from a keyboard using the editor is a completely different issue.  

  As I mentioned earlier, most programmers in a corporate environment have
  limited access to system settings.  Changing them in some cases can cause
  reprimands or dismissal.  Systems are often set up with the bare minimum
  of locales and character sets necessary to do the job.  Also, you have to
  deal with the situations where programmers are connecting to *nix servers
  through a variety of Windows-based XWindows servers (Exceed, Cygwin, etc.)
  complicates what character sets are available immensely.
 
 I have worked as a contractor in almost a dozen settings, most of them
 corporate lockdowns, and I've always been able to go to my manager and
 say To be more productive, I need this tool and it would be loaded
 the next day. The few times I've had to talk to an IT person to
 explain the tool, I'd do it over lunch (my treat) and it would be on
 my desktop the next morning. Saying you cannot get a tool you need
 loaded on your machine is, essentially, saying that you cannot play
 corporate politics. I'm assuming you can, which means this is a straw
 man.

I don't think a programmer's skill (or lack thereof) in corporate politics
should be a prerequisite to experimenting in Perl 6.  My bigger point is
about system settings which are typically locked down and not usually 
sweet-talkable.  Also, getting new software purchased can be a painfully
slow depending on the bureaucracy involved, and generally requires lots
of beers and lunches, or the right catastrophe, which could have been 
prevented and/or repaired with the tool you want, to speed up the process.

Steve Peters
[EMAIL PROTECTED]

Re: [ANNOUNCE] Test::Simple/More/Builder 0.62

[Steve Peters]

On Sat, Oct 08, 2005 at 01:38:06AM -0700, Michael G Schwern wrote:
 http://www.pobox.com/~schwern/src/Test-Simple-0.62.tar.gz
 or
 http://svn.schwern.org/svn/CPAN/Test-Simple/trunk
 or
 a CPAN near you.
 

I've just added this to bleadperl.

Thanks,

Steve Peters
[EMAIL PROTECTED]

Re: [ANNOUNCE] Test::Simple/More/Builder 0.62

[Steve Peters]

On Sun, Oct 09, 2005 at 11:12:59AM -0700, Michael G Schwern wrote:
 On Sun, Oct 09, 2005 at 11:34:50AM -0500, Steve Peters wrote:
  I've just added this to bleadperl.
 
 With or without Test::Builder::Tester?
 

So I don't continue the breakage, with Test::Builder::Tester.  For the
longer term, the decision rests with the pumpkings as to whether it stays
in or not.

Steve Peters
[EMAIL PROTECTED]

Re: Test::Kwalitee - Where is it hosted?

[Steve Peters]

On Tue, Oct 04, 2005 at 04:15:45PM +0100, Dave Cross wrote:
 David Landgren wrote:
 Gavin Henry wrote:
 
 Dear List,
 
 In Perl Testing - A Developers Notebook it has a section on 
 Test::Kwalitee.
 
 I can't find this module anywhere, nothing on the CPAN or on Google.
 
 It would only be POD, I imagine.
 
 Anyone know where it's hosted?
 
 Kwalitee, as in cpants.perl.org, is run by Thomas domm Klausner.
 
 What is Kwalitee
 http://cpants.perl.org/kwalitee.html
 
 Y::E 2005 Braga slides by Thomas Klausner
 http://domm.zsi.at/talks/2005_braga_cpants/s2.html
 
 Actually the book strongly suggests that it's a real module which runs 
 the Kwalitee checks on your code
 
 Download and install Test::Kwalitee. Then add the following code to
 your t/ directory as kwalitee.t:
 
 #!perl
 
 eval { require Test::Kwalitee };
 exit if $@;
 Test::Kwalitee-import(  );
 
 That's from section 4.9 Validating Kwalitee.
 

Looking at http://use.perl.org/~chromatic/journal/25127 (I love Google), its
still waiting to go to CPAN.

Steve Peters
[EMAIL PROTECTED]

Re: TODO: Find Copied and Pasted Code?

[Steve Peters]

On Fri, Sep 23, 2005 at 12:52:04PM -0700, chromatic wrote:
 I wonder what running PMD's CPD plugin on all of our .c files would
 discover.  Maybe it'd find places of insufficient abstraction.
 
 Does anyone have a working Java development environment and sufficient
 time to experiment?
 
   http://pmd.sourceforge.net/cpd.html
 

Actually, you don't need much of a development environment to use it.  The
page above has a link to a Java WebStart link that will allow you to install
and use it directly.

Steve Peters
[EMAIL PROTECTED]

Re: TODO: Find Copied and Pasted Code?

[Steve Peters]

On Fri, Sep 23, 2005 at 03:04:42PM -0500, Steve Peters wrote:
 On Fri, Sep 23, 2005 at 12:52:04PM -0700, chromatic wrote:
  I wonder what running PMD's CPD plugin on all of our .c files would
  discover.  Maybe it'd find places of insufficient abstraction.
  
  Does anyone have a working Java development environment and sufficient
  time to experiment?
  
  http://pmd.sourceforge.net/cpd.html
  
 
 Actually, you don't need much of a development environment to use it.  The
 page above has a link to a Java WebStart link that will allow you to install
 and use it directly.

A slight correction.  You will need a Java 1.4 or higher installed on your
system.  Mac OS X 10.3 and above should have that by default.  Users on
other environments may need to install a Java runtime (JRE) for Java 1.4
before trying.

Steve Peters
[EMAIL PROTECTED]  

Re: Test::Harness Extension/Replacement with Color Hilighting

[Steve Peters]

On Fri, Sep 16, 2005 at 03:55:15AM +0300, Shlomi Fish wrote:
 
 Thus, it seems the best option if we want to make sure Test::Harness is 
 custmisable in this and other ways is to spin it off and create a better and 
 more customizable test harnessing module, with an incompatible interface. 
 Another option is to create an environment variable triggered option for this 
 and future features, but that would be Evil.
 
 Mr. Lester, would you approve of a friendly spin-off of Test::Harness?
 

Another option would be to use Test::Harness::Straps.  This seems a lot more
easy than trying to write your own harness.  Since its already included
with recent Perls, that seems to make more sense than writing your own 
incompatible testing harness.

Steve Peters
[EMAIL PROTECTED]

Re: [ANNOUNCE] Test::Symlink

[Steve Peters]

On Wed, Jul 06, 2005 at 09:17:59AM +0100, Nik Clayton wrote:
 
 Small, sharp tools and all that :-)

One of the smallest, sharpest tools I have is a script called Clns.  It 
takes a file name and a link name and creates a link to the file.  The best
part is that it doesn't care about the order of the file and the link.  It
simply DWIM.  My concern with symlink_ok() is that I'll go to use it and
have to repeatedly check the syntax to see which should be the link and which
should be the file.  Although I don't mind writing tests, I'd prefer a 
test function that doesn't force me to think about the syntax of the test
function and let me focus on writing test cases to match the documentation.

P.S. See http://use.perl.org/~TorgoX/journal/24654 for the most recent
incarnation of lns.

Steve Peters
[EMAIL PROTECTED]

Re: prove with Devel::Cover example?

[Steve Peters]

On Fri, Jun 03, 2005 at 06:44:53PM +, Mark Stosberg wrote:
 Ok, I'm feeling brain dead about this one-- this seems easy but I'm
 missing it. 
 
 How can I use 'prove' and Devel::Cover together? I tried: 
 
  perl -MDevel::Cover prove ...
 
 but didn't cover the scripts that ran.
 
 Mark
 

prove is just a cover over Test::Harness, so (if I remember correctly)

  HARNESS_PERL_SWITCHES=-MDevel::Cover prove ...

should work.

Steve Peters
[EMAIL PROTECTED]

Re: DBD-mysql coverage == 56% - am I on drugs ??

[Steve Peters]

On Thu, May 12, 2005 at 09:23:48PM -0700, Michael G Schwern wrote:
 On Fri, May 13, 2005 at 01:27:41PM +1000, [EMAIL PROTECTED] wrote:
  OK, but if we remove that, the Stmt goes to ~70% wich is still 
  shockingly low for such an important module. It is also very distressing 
  that the Sub column isnt at 100% - why  you would go to the effort of 
  writing test cases and not at least call every method/function is beyond me.
 
 This is, after all, the whole point of Phalanx:  Find important, undertested 
 modules and improve their coverage.  I hope you're not just now realizing 
 that some of the most important and popular modules are also the most 
 undertested? 
 
 As for why no 100% coverage... test cases are often written in response to
 bugs and not in an attempt to cover all functionality.  You can debate the
 merits of either approach, but that's the way some folks do it.
 
 
 -- 
 Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
 Reality is that which, when you stop believing in it, doesn't go away.
   -- Phillip K. Dick

The other portion not taken into consideration by Devel::Cover is the XS
code in the module.  While the Pod coverage statistics cover this, IIRC, 
Devel::Cover is only looking at the Perl portion of the code.  Depending
on how much of this code is covered and the proportion of XS to Perl code,
these statistics could go up or down.  My gut instinct, however, tells
me not much will change.

Covering the XS portion of the code with gcov is possible, and Devel::Cover
will create all kinds of nice webpages and statistics for you too.  
Paul Johnson may have this written up somewhere, but, if not, I should 
really write something up about this since I've used it to determine Perl's
test coverage.

Steve Peters
[EMAIL PROTECTED]

Re: Building a module with tests

[Steve Peters]

On Fri, May 06, 2005 at 11:43:53AM -0400, Robert wrote:
 Andy Lester [EMAIL PROTECTED] wrote in message 
 news:[EMAIL PROTECTED]
  On Thu, May 05, 2005 at 10:12:14AM -0400, Robert ([EMAIL PROTECTED]) 
  wrote:
  Is there an article on the current best practices about creating a module
  with tests? I know there is h2xs but I somewhere in the back of my foggy
  brain I am thinking I read somewhere of a different. more preffered 
  method.
 
  Go look at Module::Starter.  Also, buy a copy of Perl Testing
  Developer's Notebook as soon as it comes out.
 
  xoxo,
  Andy
 
 
 :  )
 
 Seems it is not available as a PPM for ActiveStates Perl distro.
 

Looking at http://ppm.activestate.com/BuildStatus/5.8-M.html, the 
Module-Starter distribution is available for the ActiveState 5.8.x Perls.

Steve Peters
[EMAIL PROTECTED]

Re: Test::Tutorial needs updated

[Steve Peters]

On Mon, Apr 25, 2005 at 04:30:12PM -0700, Michael G Schwern wrote:
 And I just can't seem to get up the enthusiasm to do it.  The primary 
 problem is its testing against a very old version of Date::ICal and a lot 
 of the examples no longer work.  There's lots of secondary problems 
 resulting from it having been written almost four years ago.
 
 So if anyone's feeling enthused, have at it.
 
Having at it, with input, I'm assuming from here.  :)

Steve Peters
[EMAIL PROTECTED]

Re: Testing for NULL return values in test scripts

[Steve Peters]

On Tue, Apr 12, 2005 at 12:49:30PM -0500, Walter Goulet wrote:
 Hi,
 
 I was wondering if there is a way to use the ok() function in Test.pm
 to check for a null return value. It looks like the 3 arg form of ok()
 I'm using only tests the first 2 args to see if they're equal.
 
 I'm considering this approach:
 
 $val = some_func(); # returns NULL on failure
 
 if($val != 0  $val ne 0)
 {
$isnull = 0;
 }
 else
 {
$isnull = 1;
 }
 
 ok($isnull,0,NULL returned);
 

First, there is no NULL in Perl.  There is undef, so I'll assume that's what
you mean.  The test above does not test for undef at all.  It just checks
to see that the return is not equal to zero.  If you used Test::Simple, it
would be as simple as

use strict;
use warnings;

use Test::Simple tests = 1;

my $val = some_func();

ok(! defined $val, undef returned);


This should work just fine for what you are testing.

Steve Peters
[EMAIL PROTECTED]

[perl #34917] test t/op/trans.t#13 failed on OpenBSD 3.5/i386

[Steve Peters via RT]

 [jrieks - Mon Apr 11 12:17:57 2005]:
 
 It looks like atan -0.0, -0.0 == 0.0 on OpenBSD 3.5/i386:
 
 t/op/trans.NOK 13# Failed test (t/op/trans.t
 at line
 307)
 #  got: 'ok 1
 # ok 2
 # ok 3
 # ok 4
 # ok 5
 # ok 6
 # ok 7
 # ok 8
 # ok 9
 # ok 10
 # ok 11
 # ok 12
 # ok 13
 # ok 14
 # ok 15
 # ok 16
 # not 0.00ok 17
 # '
 # expected: 'ok 1
 # ok 2
 # ok 3
 # ok 4
 # ok 5
 # ok 6
 # ok 7
 # ok 8
 # ok 9
 # ok 10
 # ok 11
 # ok 12
 # ok 13
 # ok 14
 # ok 15
 # ok 16
 # ok 17
 # '
 t/op/trans.ok 19/19# Looks like you failed 1 tests
 of 19.
 
 from t/op/trans_13.pasm:
 atan N4, -0.0, -0.0
 .fp_eq   (N4, -3.1415926, EQ17)
 print not 
 print N4
 EQ17:   print ok 17\n
 
 

This ticket is a duplicate of ticket #34549.  I'll have a patch for this
issue later this week.

Re: $(TOUCH) in Perl: any reason not to use utime()?

[Steve Peters]

On Mon, Apr 04, 2005 at 12:00:20PM -0400, Chip Salzenberg wrote:
 Currently, config/gen/makefiles/root.in says:
 
   TOUCH  = $(PERL) -e ${PQ}open(A,qq{$$_}) or die foreach @ARGV${PQ}
 
 However, this fails for my source tree.  I habitually leave
 CVS-controlled files write-only until they are locally modified.
 (This is cvs -r behavior, also triggered by exporting CVSREAD=1.)
 
 Perl has a Cutime operator which should work even when files are
 read-only.  Is there a reason that $(TOUCH) doesn't use it?
 -- 

utime will only work if the file already exists.  The above looks like it
would work to create empty files.

Steve Peters
[EMAIL PROTECTED]

Re: [perl #34549] t/op/trans.t failure on OpenBSD

[Steve Peters]

Here's the responce from the OpenBSD folks.  It seems that turning on a 
define prior to the atan2() call will set the flags correctly for OpenBSD.
My guess is that NetBSD will behave similarly.

 Number: 4154
 Category:   library
 Synopsis:   atan2(-0.0, -0.0) returning incorrect result

Our libm is compiled in multi mode and defaults to posix mode, which 
sets errno and returns 0 if both args are (+-)0.0. IEEE mode does what you 
want.

Check lib/libm/Makfile and lib/lib/src/{e,w}w_atan2.c for some background 
info.

If you force libm to IEEE mode, you'll get the expected results:
(on macppc, same results on i386):

[EMAIL PROTECTED]:9]$ cat x.c 
#include errno.h
#include stdio.h
#include math.h

int main() {
double res;

_LIB_VERSION = _IEEE_;

errno = 0;
res = atan2(0.0, 0.0);
perror(atan2);
printf(atan2(0.0, 0.0) = %f\n, res);
errno = 0;
res = atan2(-0.0, 0.0);
perror(atan2);
printf(atan2(-0.0, 0.0) = %f\n, res);
errno = 0;
res = atan2(0.0, -0.0);
perror(atan2);
printf(atan2(0.0, -0.0) = %f\n, res);
errno = 0;
res = atan2(-0.0, -0.0);
perror(atan2);
printf(atan2(-0.0, -0.0) = %f\n, res);
}

[EMAIL PROTECTED]:10]$ a.out  
atan2: Undefined error: 0
atan2(0.0, 0.0) = 0.00
atan2: Undefined error: 0
atan2(-0.0, 0.0) = 0.00
atan2: Undefined error: 0
atan2(0.0, -0.0) = 3.141593
atan2: Undefined error: 0
atan2(-0.0, -0.0) = -3.141593
[EMAIL PROTECTED]:11]$ 



- End forwarded message -

[perl #34549] t/op/trans.t failure on OpenBSD

[Steve Peters via RT]

 [leo - Thu Mar 24 07:07:31 2005]:
 
 
 Comments, takers?
 


Since I'm fixing this in Perl, I take a whack at it in Parrot as well.

Steve

Re: [perl #34549] t/op/trans.t failure on OpenBSD

[Steve Peters]

On Wed, Mar 23, 2005 at 04:00:45PM -, Leopold Toetsch via RT wrote:
 Steve Peters [EMAIL PROTECTED] wrote:
  # New Ticket Created by  Steve Peters
  # Please include the string:  [perl #34549]
  # in the subject line of all future correspondence about this issue.
  # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34549 
 
 
  When running testing parrot-HEAD, I get a test failure in t/op/trans.t on
  OpenBSD.  Running the same tests on Linux seem to work just fine...
 
  perl -Ilib t/op/trans.t
  not ok 13 - atan2
  # Failed test (t/op/trans.t at line 307)
  #  got: 'ok 1
  # not 0.00ok 17
 
  atan N4, -0.0, -0.0
 
 Obviously another broken C system. What says your perl:
 
 $ perl -le'print atan2(-0.0,-0.0)'
 -3.14159265358979324


Tasty :-/

On OpenBSD, I get

 perl -le'print atan2(-0.0,-0.0)'
0

Steve 

reset() and S29 -- obsoleted?

[Steve Peters]

One function I noticed on the S29 list was reset().  With lexically scoped
variables, reset is almost useless.  Perl in a Nutshell calls it vaguely
deprecated.  Can we remove the vagueness and deprcate it completely?

Steve Peters
[EMAIL PROTECTED]

Re: Tinderbox

[Steve Peters]

On Mon, Mar 07, 2005 at 09:54:36AM +0100, Leopold Toetsch wrote:
 It would be very useful if tinderboxen could be revived.
 
 Thanks,
 leo
 

Do we need a separate tinderbox, or do you think it might be helpful to 
integrate parrot somehow into the current perl smoke reporting process?  
There is already a good infrastucture there to support this kind of testing.

Steve Peters
[EMAIL PROTECTED]

Re: #perl6, pugscode.org, and more

[Steve Peters]

On Wed, Feb 23, 2005 at 03:11:29PM -, Rafael Garcia-Suarez wrote:
 Aaron Sherman wrote in perl.perl6.compiler :
  On Wed, 2005-02-23 at 07:43 -0500, Aaron Sherman wrote:
  has anyone considered petitioning the major Linux distribution vendors
  to include it in their upcoming releases?
  [...]
  I don't know anything about Haskell, and it would be presumptuous of
  me.
 
  Face... so... red...
 
  Ignore me, this is already under way (and being quite well managed, it
  seems at http://www.haskell.org/fedora/ for the Fedora platform).
  They're pushing to get included in Fedora's extras.
 
 I've included it in Mandrakelinux's contribs. It's a huge RPM, but we
 may try to find place for it on the editions that come with the largest
 number of CDs :)

Also, its available through portage on Gentoo, but I suggest going and doing
something else while compiling ;)

Steve Peters
[EMAIL PROTECTED]

Re: Z machine

[Steve Peters]

On Wed, Feb 23, 2005 at 03:02:32PM +0100, Leopold Toetsch wrote:
 I've here some small parts of a Z machine code translator. It runs not 
 much more then a hello-worldish program.
 
 * written in PIR, using objects
 * translates Z code files to PIR
 * ~ 10 opcodes done
 * objects, props, attributes, abbrevs are all missing
 
 I've no time to play with it further, so I'd be glad if someone likes to 
 continue hacking on it.
 
 leo
 

I'll take a look at that.  I haven't played Leather Goddesses of Phobos in
a while ;).  

Steve Peters
[EMAIL PROTECTED]