Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

2007-08-22 Thread Ron Blaschke
Paolo Molaro wrote:
 On 08/16/07 Ron Blaschke wrote:
 This optimization reaches likely back to times, when the opcode engine was 
 designed. It's saving one interpreter push statement [1] per JIT calling 
 one 
 external function, and I've always thought of it as a very cool (and valid) 
 thingy, when I first realized, why the interpreter is the second argument 
 in 
 opcode functions ;)
 I think it's a really cool idea, too.  I'd like to have a way to disable
 it, though, to measure its effect, and maybe to work around compilers
 like VC (at least until a better solution comes around).
 
 The optimization done by the parrot jit is invalid for the x86 C calling
 convention: the area of memory containing the passed arguments
 can be used as scratch space by the called function.
 If you can make sure it's not harmful that way you could still use it
 when calling parrot's own jitted functions which could use a different
 calling convention, but it is wrong when interoperating with other code
 (gcc can generate the same issues, so it's not just VC).

Many thanks for your help.  I couldn't find detailed descriptions of the
x86 C calling convention, which also talk about this.  But as nobody
explicitly says you can reuse it, I guess it's undefined and should be
avoided.

Thanks,
Ron


Re: Current win32 linking issues: Summary

2007-08-22 Thread Ron Blaschke
Mark Glines wrote:
 On Tue, 21 Aug 2007 13:08:05 +0200
 Ron Blaschke [EMAIL PROTECTED] wrote:
 
 The win32 skippage will need to be removed again, once the PMCNULL
 symbol is exported correctly from libparrot.dll.
 Not adding the skip on the other t/src tests will cause them to
 fail.  I think it would be best to skip them all, or none of them.

 I agree.  If we can't find a quick fix to get the tests to pass, I can
 clean things up to make them consistent (all-failing or all-skipped)
 before the release.  I don't have a preference which route we take.
 
 Don't know if its a problem if they fail.  I don't have a problem with
 failures as they tell me there's something that needs attention.

 True.  Well, these issues do need attention, so maybe they *should*
 fail. :)

Jerry mentioned yesterday that there shouldn't be any failures for a
release, which makes sense as it would only upset users.  Maybe there
should be a ticket for the failures then?  Or an environment variable
like PARROT_PORTER which makes all tests fail that are skipped because
they are broken, not because the feature is not supported on the platform?

 1.  Do you have any ideas for how we need to decorate PMCNULL so it
 gets exported by the dll? PARROT_API doesn't seem to be sufficient.  I
 think maybe its because its a variable, not a function.
 
 2.  Do you have any preference on how we fix up the Parrot::Config stuff
 so we can put libparrot.lib on the link command-line for win32, in the
 t/src/ tests?
 
 Sorry to ask so many questions, but I'm a linux geek, and utterly
 clueless about win32...

Many thanks for helping with the t/src issues, I'm glad you jumped on
the Windows train.  Some things work differently on Windows and Visual
C++, especially the linking and loading part, with symbol
exports/imports on the very top.

One great way to find out about compiled objects, libraries and
executables is the COFF/PE Dumper (dumpbin), which shows details about
the binary image.  Another fine tool is the Dependency Walker (depends),
which exactly shows you which libraries would be loaded, including their
full path, what symbols they export and which they import.

Please don't hesitate to ask if you have any questions.  Depending on
$job workload it might take some time before I can get back to you, though.

Ron


Re: [svn:parrot] r20688 - in trunk: include/parrot src

2007-08-22 Thread Nicholas Clark
On Mon, Aug 20, 2007 at 05:26:22PM -0400, Andy Dougherty wrote:

 Nor can I.  Thus you either use lots of platform-specific code (determined
 by Configure.pl) or turn off gcc's -Wfloat-equal warning flag and just
 write f == 0.0.

Or, maybe

f = 0.0  f = 0.0

which I believe is identical, even in the face of NaNs.

Nicholas Clark


Re: Current win32 linking issues: Summary

2007-08-22 Thread Jerome Quelin
On 07/08/22 11:16 +0200, Ron Blaschke wrote:
 Jerry mentioned yesterday that there shouldn't be any failures for a
 release, which makes sense as it would only upset users.  Maybe there
 should be a ticket for the failures then?  Or an environment variable
 like PARROT_PORTER which makes all tests fail that are skipped because
 they are broken, not because the feature is not supported on the platform?

isn't what the TODO tests are meant to be? ie, bonus points if it works,
but no harm if they fail...

jérôme 
-- 
[EMAIL PROTECTED]


Re: Current win32 linking issues: Summary

2007-08-22 Thread Mark Glines
On Wed, 22 Aug 2007 11:16:12 +0200
Ron Blaschke [EMAIL PROTECTED] wrote:
  Don't know if its a problem if they fail.  I don't have a problem
  with failures as they tell me there's something that needs
  attention.
 
  True.  Well, these issues do need attention, so maybe they *should*
  fail. :)
 
 Jerry mentioned yesterday that there shouldn't be any failures for a
 release, which makes sense as it would only upset users.  Maybe there
 should be a ticket for the failures then?  Or an environment variable
 like PARROT_PORTER which makes all tests fail that are skipped because
 they are broken, not because the feature is not supported on the
 platform?

Or maybe we should wait until the release, then stop skipping the error,
which should help ensure it gets fixed before the next release.  (It is
a pretty important issue, I think, so I don't want to mask it any
longer than absolutely necessary.  Embeddability is important to me.)


 Many thanks for helping with the t/src issues, I'm glad you jumped on
 the Windows train.  Some things work differently on Windows and Visual
 C++, especially the linking and loading part, with symbol
 exports/imports on the very top.
 
 One great way to find out about compiled objects, libraries and
 executables is the COFF/PE Dumper (dumpbin), which shows details about
 the binary image.  Another fine tool is the Dependency Walker
 (depends), which exactly shows you which libraries would be loaded,
 including their full path, what symbols they export and which they
 import.

Great, good tips.  I don't know if I'm really on the windows train,
though.  I'm still primarily linux with a bit of freebsd on the side;
for me, win32 is mostly in the category of bizarre platform to make
portability testing more interesting.  But it will be good to know my
way around a little bit better, so I can solve things more quickly next
time. :)


 Please don't hesitate to ask if you have any questions.  Depending on
 $job workload it might take some time before I can get back to you,
 though.

I know the feeling.  Thanks!

Mark


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

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


Solaris CC is a bit more sensative than g++ in three cases.  First, making
sure that arguments have the correct type.  Second, making sure that that
return type is correct.  Finally, functions that return something, must 
return.  The attached patch fixes these things.

Steve Peters
[EMAIL PROTECTED]
--- 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
 }
 
--- src/string.c.oldWed Aug 22 08:14:21 2007
+++ src/string.cWed Aug 22 08:14:50 2007
@@ -2262,7 +2262,7 @@
 enc_char = ascii;
 
 /* check for encoding: */
-p = strchr(enc_char, ':');
+p = (char *)strchr(enc_char, ':');
 
 if (p) {
 *p = '\0';
--- src/ops/math.ops.oldWed Aug 22 08:43:16 2007
+++ src/ops/math.opsWed Aug 22 08:42:46 2007
@@ -432,7 +432,7 @@
 real_exception(interp, NULL, E_ZeroDivisionError,
 Divide by zero);
 
-  f  = floor($1 / den);
+  f  = floor((FLOATVAL)$1 / den);
   $1 = (INTVAL)f;
   goto NEXT();
 }
@@ -454,7 +454,7 @@
 real_exception(interp, NULL, E_ZeroDivisionError,
 Divide by zero);
 
-  f  = floor($2 / den);
+  f  = floor((FLOATVAL)$2 / den);
   $1 = (INTVAL)f;
   goto NEXT();
 }
--- src/ops/experimental.ops.oldWed Aug 22 08:40:58 2007
+++ src/ops/experimental.opsWed Aug 22 08:38:34 2007
@@ -139,8 +139,8 @@
 yk = ykp1;
   }
   $1 = r1;
-  $2 = (INTVAL)(xk * pow(-1, n));
-  $3 = (INTVAL)(yk * pow(-1, n+1));
+  $2 = (INTVAL)(xk * pow(-1, (FLOATVAL)n));
+  $3 = (INTVAL)(yk * pow(-1, (FLOATVAL)n+1));
 
   x = $2 * $4;
   y = $3 * $5;


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

2007-08-22 Thread Paul Cochrane
 --- 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


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

2007-08-22 Thread 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]


[perl #44847] Parrot 0.4.16 Release

2007-08-22 Thread via RT
# New Ticket Created by  Patrick R. Michaud 
# Please include the string:  [perl #44847]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44847 


This ticket is a placeholder for the 0.4.16 release on 18 September 2007.




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

2007-08-22 Thread jerry gay
On 8/22/07, Steve Peters [EMAIL PROTECTED] wrote:
 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.

these are compile *errors*? wow. they'll cause 'unreachable code'
warnings on msvc, but that's for the greater good if it allows solaris
cc to build parrot. however, please put a note somewhere or mark these
so that they're not removed by somebody who later decides to remove
unreachable code.

~jerry


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

2007-08-22 Thread Paul Cochrane
On 22/08/07, Steve Peters [EMAIL PROTECTED] wrote:
 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.

That's weird as I had suncc compiling Parrot recently...


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

2007-08-22 Thread Paul Cochrane
 We can leave it out, but then we'll never be able to compile Parrot with
 Solaris CC.

I just tried to compile Parrot with suncc and everything works (the
tests are running atm).  Did you configure with --cgoto=0?  This is a
known problem that suncc should be able to handle computed gotos but
switching them off actually makes suncc build Parrot and allows the
tests to run.

Paul


[perl #44851] Update step 2.f in release_manager_guide.pod

2007-08-22 Thread via RT
# New Ticket Created by  Patrick R. Michaud 
# Please include the string:  [perl #44851]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44851 


Supposedly a change to the pbc format eliminates the need
for step 2.f in the release manager guide:

: =item f
: 
: Update FPBC_COMPAT, perhaps by collapsing intra-release entries
: into a single entry naming the release.

I've published the 0.4.15 release having skipped this step 
(i.e., _not_ updating PBC_COMPAT), but I think we should verify
that things work as expected before officially removing it from
the guide.

So, this ticket is a placeholder to review the results of the
0.4.15 release and to update the guide accordingly.

Pm


[perl #44855] Re: Current win32 linking issues: Summary

2007-08-22 Thread Mark Glines
On Wed, 22 Aug 2007 11:16:12 +0200
Ron Blaschke [EMAIL PROTECTED] wrote:
 Jerry mentioned yesterday that there shouldn't be any failures for a
 release, which makes sense as it would only upset users.  Maybe there
 should be a ticket for the failures then?

I have created ticket #44855 for this issue.

It sounds like we need to pass -DIN_LIBPARROT or somesuch to the
compiler when compiling objects that end up in libparrot.dll.
Then, we can use that to decide how PARROT_API will be defined.

Sometime in the next couple of days, I'll see what's required to pass
additional defines to the compiler, from within the Makefile system.

Mark


[perl #44861] [TODO]: remove compiler warnings note from README

2007-08-22 Thread via RT
# New Ticket Created by  Patrick R. Michaud 
# Please include the string:  [perl #44861]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44861 


For the 0.4.15 release a note was added to README regarding the
large number of compiler warnings in the release:

+ As of the 0.4.15 release you may see a large number of compiler
+ warnings throughout the make process -- this is normal.  The configure
+ system now enables a lot of additional compiler warning options, and
+ we're still in the process of reviewing/cleaning up the warnings.

When the number of warnings comes back down, we should remove
this note.

Pm


[perl #44865] [BUG] t/stm/basic_mt.t fails on x86_64

2007-08-22 Thread via RT
# New Ticket Created by  Patrick R. Michaud 
# Please include the string:  [perl #44865]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44865 


As of r20786, t/stm/basic_mt.t is failing on my x86_64 box
with a failed assertion:

$ prove -v t/stm/basic_mt.t
t/stm/basic_mt1..4
ok 1 - wait (simple)
ok 2 - wait (simple, strings)
not ok 3 - get deadlock

# Failed test (t/stm/basic_mt.t at line 168)
# Exited with error code: 134
# Received:
# src/stm/backend.c:608: failed assertion 'successp'
# Backtrace - Obtained 13 stack frames (max trace depth is 32).
#   (unknown)
# Parrot_confess
#   (unknown)
# (unknown)
#   Parrot_stm_commit_ic
# (unknown)
#   (unknown)
# (unknown)
#   (unknown)
# Parrot_runops_fromc_args
#   (unknown)
# (unknown)
#   clone
# Aborted (core dumped)
#
# Expected:
# /okay/
#
ok 4 - wait + invalidate outer transcation
ok
All tests successful.
Files=1, Tests=4,  5 wallclock secs ( 1.92 cusr +  0.26 csys =  2.18 CPU)
$

For the 0.4.15 release I'm marking this test as 'todo' for 
64-bit platforms.

Pm


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

2007-08-22 Thread Paul Cochrane
On 22/08/07, Nicholas Clark [EMAIL PROTECTED] wrote:
 On Wed, Aug 22, 2007 at 05:40:45PM +0200, Paul Cochrane wrote:
   We can leave it out, but then we'll never be able to compile Parrot with
   Solaris CC.
 
  I just tried to compile Parrot with suncc and everything works (the

 CC isn't cc


 (C++ compiler versus C compiler)

Ooops.  Didn't realise, sorry.


Re: [perl #44809] [PATCH] use Storable instead of Data::Dumper for PMC .dump files

2007-08-22 Thread Mark Glines
Oops.  I replied to this on the RT site, but it looks like I neglected
to tell it to copy the list (or you).  I'll cutpaste my response below.


On Tue, 21 Aug 2007 21:02:39 -0400
James E Keenan [EMAIL PROTECTED] wrote:
 I do have some qualms.
 
 (1) I know that there have been issues with incompatibility among 
 different versions of Storable.  I myself have been bit by these
 issues with different versions of Storable distributed with different
 versions of Perl 5.8 (not to mention 5.6).  Some of these issues are
 alluded to in the POD 
 (http://search.cpan.org/dist/Storable/Storable.pm#FORWARD_COMPATIBILITY). 
   I have never heard such compatibility issues with respect to 
 Data::Dumper.  This is not a killer objection, but it should be
 considered.
 
 (2) Not that I'm opposed to Storable entirely.  Hey, I use it in 
 Parrot::Configure::Trace!  But there, as in other places I've used
 it, I've always found I got better mileage by using 'nstore' instead
 of 'store'.

Hi! I agree, nstore is more useful for stuff that's kept around for a
while, exchanged between machines and so forth.

But, keeping in mind these files are built by pmc2c.pl as part of the
parrot build process, rebuilt whenever the pmc file changes, and removed
whenever you do a make clean, does forwards compatibility (or even
endian-portability) actually matter? Correct me if I'm wrong, but I
don't think we keep any of these files around.

Mark


Parrot 0.4.15 Augean Stable released!

2007-08-22 Thread Patrick R. Michaud
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.15
Augean Stable. Parrot (http://parrotcode.org/) is a virtual 
machine aimed at running all dynamic languages.

Parrot 0.4.15 can be obtained via CPAN (soon), or follow the
download instructions at http://parrotcode.org/source.html.
For those who would like to develop on Parrot, or help develop
Parrot itself, we recommend using Subversion or SVK on the
source code repository to get the latest and best Parrot code.

Parrot 0.4.15 News:
- Implementation:
 + Lots of code review, many bugs fixed
 + Many more code cleanups and compiler warning levels
 + Started a new jit engine for 64-bit processors
 + Refactored configure process, with tests and new diagnostic options
 + Added new CodeString PMC for dynamic generation of PIR code
 + More pdd15 support for object metamodel.
- Languages:
 + Added NQP (Not Quite Perl), a very lightweight Perl 6-like language
 + Significant improvements and refactors to PCT (Parrot Compiler Toolkit)
 + perl6 passes more spec tests
 + Lua works now with a PGE/TGE/PAST-pm based compiler, lives in one pbc,
   and the interpreter has same behavior as original.
- Documentation
 + Added a committers' HOWTO
 + More PIR tutorial examples
 + Added PAUSE guide


Thanks to all our contributors for making this possible, and our
sponsors for supporting this project.

Enjoy!



[perl #44865] [BUG] t/stm/basic_mt.t fails on x86_64

2007-08-22 Thread Mark Glines via RT
On Wed Aug 22 09:49:20 2007, pmichaud wrote:
 # Failed test (t/stm/basic_mt.t at line 168)
 # Exited with error code: 134
 # Received:
 # src/stm/backend.c:608: failed assertion 'successp'

I get the same failure, intermittently, on dual-CPU x86.  It looks like
a thread race condition, not specific to x86_64.

t/stm/basic_mtNOK 3/4
# Failed test (t/stm/basic_mt.t at line 161)
# Exited with error code: [SIGNAL 6]
# Received:
# src/stm/backend.c:608: failed assertion 'successp'
# Backtrace - Obtained 13 stack frames (max trace depth is 32).
#   Parrot_print_backtrace
# Parrot_confess
#   (unknown)
# Parrot_STM_commit
#   Parrot_stm_commit_ic
# runops_slow_core
#   runops_int
# runops
#   (unknown)
# Parrot_runops_fromc_args
#   (unknown)
# (unknown)
#   __clone
#
# Expected:
# /okay/
#
# Looks like you failed 1 test of 4.



[perl #44855] [BUG] msvc: embedders can't link against libparrot.dll

2007-08-22 Thread via RT
# New Ticket Created by  Mark Glines 
# Please include the string:  [perl #44855]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44855 


t/src/compiler.t fails on msvc/win32 because the linker can't find the
PMCNULL variable.  Apparently this symbol is exported by the dll
properly, but not imported by the embedded application properly.

The background:

11:19 @Ron The story goes like this.
11:19 @Ron When building a DLL you need to tell the compiler to export the 
symbol. 
11:20 @Ron This is done by __declspec(dllexport).
11:20 @Ron When using the DLL you need to tell the compiler to import it, 
with __declspec(dllimport). 
11:21 @Ron This is done in include/parrot/config.h, but tied to #define 
PARROT_IN_EXTENSION. 
11:22 @Ron Which makes sense, because it was mostly relevant for the 
extensions, which are separate shared objects, linked against libparrot.

The problem:

Embedded applications (such as those compiled by t/src/compiler.t) do
not get the __declspec(dllimport) tag defined properly, and thus, do
not import symbols from the dll correctly.  This prevents third party
applications from embedding parrot, by linking against libparrot.

The proposed solution:

11:46 @Ron Infinoid, how about this.
11:46 @Ron in config.h, PARROT_API uses dllimport by default.
11:46 @Ron only uses dllexport if PARROT_EXPORTS is defined.
11:47 @Ron When compiling the sources that belong to libparrot.lib we'd need 
to define PARROT_EXPORTS.
11:48 @Infinoid will that be a headerfile define, or passed on the compiler 
command-line?
11:48 @Ron I think passed on the command line.

The tests in t/src/compiler.t are skipped so it'll pass today's 0.4.15
release, but should be unskipped for testing whether this issue is
resolved.

Mark


[perl #44853] compilers/pirc borken on win32

2007-08-22 Thread via RT
# New Ticket Created by  Klaas-Jan Stol 
# Please include the string:  [perl #44853]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44853 


Hello,

I found that compilers/pirc is currently not compiling using MS VC. It says
something about not knowing PARROT_ASSERT.

No time to look into it deeply right now, so this bug report instead.

regards,
klaas-jan


Re: [perl #44853] compilers/pirc borken on win32

2007-08-22 Thread Will Coleda
Also borked on gcc 4.0.1 osx/intel. See attached, result of cd  
compilers/pirc  make


On Aug 22, 2007, at 12:07 PM, Klaas-Jan Stol (via RT) wrote:


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


Hello,

I found that compilers/pirc is currently not compiling using MS VC.  
It says

something about not knowing PARROT_ASSERT.

No time to look into it deeply right now, so this bug report instead.

regards,
klaas-jan


--
Will Coke Coleda
[EMAIL PROTECTED]




errors.out
Description: Binary data





[perl #44875] YA Tcl segfault

2007-08-22 Thread via RT
# New Ticket Created by  Will Coleda 
# Please include the string:  [perl #44875]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44875 


During a routine svn up today, I noticed Tcl was segfaulting yet again.

svn_binary_search tells me* the offending revision was:

http://perlsix.org/svn/parrot/revision/?rev=20766

So now it's apparently a three-way death match between lua, tcl, and  
perl6.



* Actually, svn_binary_search got it down to after 20762 and no later  
than 20767 - I then did a quick scan of the log in that range to find  
the culprit**

** I did actually compile both 20765 and 20766 to verify this was the  
culprit.

--
Will Coke Coleda
[EMAIL PROTECTED]




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

2007-08-22 Thread Nicholas Clark
On Wed, Aug 22, 2007 at 05:40:45PM +0200, Paul Cochrane wrote:
  We can leave it out, but then we'll never be able to compile Parrot with
  Solaris CC.
 
 I just tried to compile Parrot with suncc and everything works (the

CC isn't cc


(C++ compiler versus C compiler)

Nicholas Clark