Re: [perl #52198] [BUG]: Test failures on Win32: t/op/arithmetics.t t/op/sprintf.t t/pmc/complex.t t/pmc/float.t

James Keenan via RT wrote: > On Wed Jul 30 16:58:55 2008, jk...@verizon.net wrote: > >> t/op/arithmetics.t >> >> t/pmc/complex.t >> >> t/pmc/float.t >> > > For the record, according to our Smolder reports for MSWin32, these 3 > files have tests that are either still TODO-ed out or are failing > o

Re: [perl #52198] [BUG]: Test failures on Win32: t/op/arithmetics.t t/op/sprintf.t t/pmc/complex.t t/pmc/float.t

Will Coleda wrote: > On Wed, Jul 30, 2008 at 7:09 PM, James Keenan via RT > wrote: >> Interestingly enough, we are also getting failures on these 4 test files >> on the OpenBSD Smolder tester: >> >> http://smolder.plusthree.com/app/public_projects/report_details/3135 >> >> But, AFAICT, the Smolder

Re: [perl #61522] build trouble on win32

Xiao Yafeng wrote: > On Sat, Dec 20, 2008 at 6:56 AM, Ronald Blaschke via RT < > parrotbug-follo...@parrotcode.org> wrote: > >>>..\..\parrot.exe >>> ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir >>> --ouput=PGE\builtins_gen.pir PGE\builtins.pg >>> MAKE : fatal error U1077: '..\..\parro

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

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 lea

Re: [perl #60678] Configure.pl manifest problem on Win32

Will Coleda wrote: > On Thu, Nov 20, 2008 at 4:12 PM, Will Coleda <[EMAIL PROTECTED]> wrote: >> On Thu, Nov 20, 2008 at 3:45 PM, Peter Schwenn <[EMAIL PROTECTED]> wrote: >>> Will Coleda >>> >>> You can drop this thread if you like. This is a waste of your time. What I >>> need to do is to find so

Re: [perl #54372] [BUG] test failures on win32/msvc

Will Coleda wrote: > On Wed, Sep 10, 2008 at 10:51 PM, James Keenan via RT > <[EMAIL PROTECTED]> wrote: >> Coke, particle: Where do we stand on this ticket? >> >> thank you very much. >> >> kid51 >> > > I haven't touched a win32 build of parrot in some months now, msvc or > otherwise. Smolder is

Re: [perl #58704] [BUG] t/src/compiler.t failures with VC++ / Win32

Tim Heckman wrote: > NotFound wrote: >> On Tue, Sep 9, 2008 at 5:23 AM, via RT Tim Heckman >> <[EMAIL PROTECTED]> wrote: >> >>> # New Ticket Created by "Tim Heckman" >>> # Please include the string: [perl #58704] >>> # in the subject line of all future correspondence about this issue. >>> # htt

[Link] Deep Dynamic Language Runtime

A quick overview of Microsoft's Dynamic Language Runtime (DLR). http://channel9.msdn.com/shows/Going+Deep/John-Lam-and-Martin-Maly-Deep-DLR/ Ron

NCI and Calling Conventions (esp. on Windows)

AFAICT, Parrot uses function pointers for NCI. This means NCI uses whatever calling convention the compiler uses by default. Unfortunately, there's More Than One Way To Do It. On Windows, there's the C calling convention (__cdecl), which is usually used by default by the Visual C++ compiler. The

Windows Symbol Export/Import

Currently, PARROT_API is declared similar to this. #if defined(PARROT_IN_EXTENSION) #define PARROT_API __declspec(dllimport) #else #define PARROT_API __declspec(dllexport) #endif That is, only import if we're in an extension, otherwise export. IMHO, this isn't quite right. Export and import s

Re: time op inconsistent on Win32

Jonathan Worthington wrote: Hi, I've just been looking at the time op, and what it returns is somewhat platform specific. * On Win32, it's the number of seconds since January 1, 1601 If I remember correctly, some parts of Windows use 100ns ticks since 1601 to represent time. Not sure if c

Re: YAPC::EU 2008

Bernhard Schmalhofer wrote: Jonathan Worthington schrieb: Allison Randal wrote: Bernhard Schmalhofer wrote: We could always do the 12th AND the 16th, just for fun and bonus productivity (if everyone isn't exhausted from a day of hacking and three days of conference)? ;-) Patrick and I will

Re: [perl #56756] [BUG] t\pmc\pmc.t failure on win32

Will Coleda (via RT) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #56756] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=56756 > On a win32 build with AS perl and the MS tools, I get the f

Re: [perl #56484] Re: The long long and The Short of It

can produce a segfault, that's bad. CC'ing rt to get a ticket. On Mon, Jun 30, 2008 at 3:55 PM, Ron Blaschke <[EMAIL PROTECTED]> wrote: Given a regular x86 (GNU/Linux) box, using GCC 4.2.3, should the following produce a working Parrot, using 64-bit ints? perl Configure.pl --in

The long long and The Short of It

Given a regular x86 (GNU/Linux) box, using GCC 4.2.3, should the following produce a working Parrot, using 64-bit ints? perl Configure.pl --intval="long long int" --opcode="long long int" If fails for me on C while building PGE. ../../parrot -o PGE.pbc --output-pbc PGE.pir ../../parrot .

Re: [perl #44763] [BUG] Assertion fails if PCRE is not available

James Keenan via RT wrote: This is what I'm getting on Linux where Configure.pl says that I do not have PCRE: $ prove -v t/library/pcre.t t/examples/library.t t/library/pcre.. 1..1 ok 1 # SKIP no pcre-config ok t/examples/library.. 1..4 ok 1 - examples/library/getopt_demo.pir ok 2

Re: Renaming Plumhead

Bernhard Schmalhofer wrote: "Plumhead", from *P*lum*h*eaded *P*arakeet, is the current name of the PHP on Parrot implementation. As "Plumhead" is a stupid name, cotto proposed to rename to "Pharrot". "Pharrot" is definitly nicer than "Plumhead", but maybe too close to Parrot. Furthermore it ch

Re: I need Windows OpenGL headers for study/testing

Geoffrey Broadwell wrote: On Wed, 2008-05-28 at 21:30 +0200, Ron Blaschke wrote: Geoffrey Broadwell wrote: I guess you are right. I have changed it as you suggested. Now Configure says: Generating OpenGL bindings...In OpenGL header 'C:/Program Files/Microsoft SDKs/Windows/v6.1/Inclu

Re: I need Windows OpenGL headers for study/testing

Geoffrey Broadwell wrote: On Wed, 2008-05-28 at 20:39 +0200, Ron Blaschke wrote: [snip] In other words, let's assume the *parent* of the /gl/ directory will be in the include path list, and force to only glob the /gl/ child of that parent. The original version would also glob all the fil

Re: I need Windows OpenGL headers for study/testing

Geoffrey Broadwell wrote: On Tue, 2008-05-27 at 21:16 +0200, Ron Blaschke wrote: [Answers to all my questions] Forgot to mention, I sent in a new patch a few hours ago incorporating all of the OpenGL Win32/MSVC portability fixes to RT 54868: http://rt.perl.org/rt3/Ticket/Display.html?id

Re: I need Windows OpenGL headers for study/testing

Geoffrey Broadwell wrote: On Tue, 2008-05-27 at 11:29 +0200, Ron Blaschke wrote: OK, I'll generate the Win32 header list from $ENV{Include}. What is that set to on your system, so I know what to expect? Mine currently is: INCLUDE=C:\usr\include;C:\Program Files\Microsoft Visual Studio

Re: I need Windows OpenGL headers for study/testing

Hi Geoffrey, I managed to get the F running on Windows XP SP3, VC++ 9.0, using Parrot r27789. There are glitches involved, though. I'll just explain what I did. First I checked the OpenGL install on my box. I have the "Windows SDK for Windows Server 2008 and .NET Framework 3.5" installed

Re: [perl #42699] r18304 Test failures on NexentaOS (GNU/OpenSolaris)

chromatic via RT wrote: On Sunday 13 April 2008 10:34:22 Ronald Blaschke via RT wrote: Here's the result of r26955. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/examples/shootout.t 13 33

Re: [perl #52198] [BUG]: Test failures on Win32: t/op/arithmetics.t t/op/sprintf.t t/pmc/complex.t t/pmc/float.t

chromatic wrote: On Friday 28 March 2008 11:55:30 James Keenan via RT wrote: Am confused. What diagnostic output beyond 'prove -v' are you referring to? For example... t/op/arithmetics1..26 ok 1 - take the negative of a native integer ok 2 - take the absolute of

Re: PARROT_ASSERT considerations

Andy Lester wrote: On Mar 11, 2008, at 2:43 PM, Ron Blaschke wrote: It ties pointers to INTVALs, which I guess it shouldn't. As I read the mail, it seems like the only problem we have is in casting the pointer to an int to find its truthiness. I'd say use the !!(x) and be do

Re: PARROT_ASSERT considerations

Leopold Toetsch wrote: Am Dienstag, 11. März 2008 20:43 schrieb Ron Blaschke: void Parrot_assert(INTVAL condition, ARGIN(const char *condition_string), ARGIN(const char *file), unsigned int line) ... PARROT_ASSERT is used to assert pointers too, for example in src/string.c: What

PARROT_ASSERT considerations

PARROT_ASSERT is currently defined as: #ifdef NDEBUG # define PARROT_ASSERT(x) ((void)0) #else # define PARROT_ASSERT(x) Parrot_assert((INTVAL)(x), #x, __FILE__, __LINE__) #endif with void Parrot_assert(INTVAL condition, ARGIN(const char *condition_string), ARGIN(const char *file),

Re: Scheduler, Timer and DOD

chromatic wrote: On Saturday 08 March 2008 07:31:08 Ron Blaschke wrote: I've been looking into a failure of F on Windows, but I don't think the problem is limited to that platform. $ prove t\dynoplibs\myops.t t\dynoplibs\myops..5/10 t\dynoplibs\myops..6/10 # Failed test &#

Re: Scheduler, Timer and DOD

James E Keenan wrote: Ron Blaschke wrote: Hi, I've been looking into a failure of F on Windows, but I don't think the problem is limited to that platform. $ prove t\dynoplibs\myops.t t\dynoplibs\myops..5/10 t\dynoplibs\myops..6/10 # Failed test 'three alarm'

Scheduler, Timer and DOD

Hi, I've been looking into a failure of F on Windows, but I don't think the problem is limited to that platform. $ prove t\dynoplibs\myops.t t\dynoplibs\myops..5/10 t\dynoplibs\myops..6/10 # Failed test 'three alarm' # at t\dynoplibs\myops.t line 118. # Exited with error code: 255

Re: Eclipse

Andy Lester wrote: Anyone out there using Eclipse? I figure there might be value in its ability to handle large codebases all at once. Any pointers for startup and using the existing parrot project? I know Eclipse a bit from Java development. You'd probably want to start with "Eclipse IDE

Re: [perl #47978] [C99] [IMCC] double free

chromatic wrote: On Thursday 29 November 2007 20:34:17 Will Coleda wrote: On feather, languages/c99 (et al.) fail with: $ make ../../parrot -o src/CPP_PGE2AST.pbc --output-pbc src/CPP_PGE2AST.pir *** glibc detected *** ../../parrot: double free or corruption (fasttop): 0x0823e328 *** running

Re: [perl #51104] [BUG] bad pointer! segfaults are bad!

Jerry Gay (via RT) wrote: # New Ticket Created by Jerry Gay # Please include the string: [perl #51104] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=51104 > during the build of languages/c99, specifically: ..\..\parrot

What are the constraints for INTVAL?

Hi, I'm trying to get an intuition how Parrot uses the basic data types, with an eye on INTVAL and opcode_t, what their limits and relationships are. Given a regular 32-bit x86 box, should it be possible to use Parrot with a 16-bit short, or a 64-bit long long, intval? The same question for o

Re: Quick config/auto/pack.pm Question

James E Keenan wrote: Ron Blaschke wrote: "l" is documented as: l A signed long (32-bit) value. I'm not expert in this, so let me ask: Where is this documented other than 'perldoc -f pack'? Yes, that's where it's documented. Am I missing something obvious here? Ron

Quick config/auto/pack.pm Question

I noticed the following in pack.pm. sub _set_ptrconst { my ($conf, $ptrsize, $intsize, $longsize) = @_; if ( $intsize == $ptrsize ) { $conf->data->set( ptrconst => "u" ); } elsif ( $longsize == $ptrsize ) { $conf->data->set( ptrconst => "ul" ); } else {

Re: [perl #50622] "nmake test" bug?

jerry gay wrote: On Feb 7, 2008 5:38 AM, via RT Ted Neward <[EMAIL PROTECTED]> wrote: t/library/pg. Interestingly, a parrot.exe process is left running, even after Ctrl-C'ing the console window in which the tests are running. Could very well be a configuration p

Re: Let's use snprintf()

Andy Lester wrote: On Feb 5, 2008, at 1:17 PM, [EMAIL PROTECTED] wrote: (He sent this to me directly by mistake) snprintf is problematic on older Solaris systems, for one. At least through 2.7 (2.8?) it's not included in any lib. So other apps needed to test and bring in their own version.

Re: Anyone has perl 1 docs?

Klaas-Jan Stol wrote: On Jan 14, 2008 5:57 PM, Mark J. Reed <[EMAIL PROTECTED]> wrote: On Jan 14, 2008 11:29 AM, Ron Blaschke <[EMAIL PROTECTED]> wrote: jesse wrote: I don't believe Perl 1 was ever ported to Windows. Well, actually it kinda was. ;-) http://www.nntp.perl.org

Re: Anyone has perl 1 docs?

jesse wrote: If only Perl1 source would compile, then it'd be easier, but it doesn't compile on windows (xp) and can't get it working on cygwin either. That sounds like the sort of situation where VMWare Player and, say, an ubuntu or redhat virtual machine might come in really handy. I don't be

Chain Smoker

I've started to hack up a little script to chain smoke Parrot. It's quite simple, all it currently does is: for each test configuration * copy (a hopefully clean) 'trunk' to a smoke directory * wipe the environment and replace with a controlled one (mostly Path, Include, Lib and http

Re: [perl #46937] [PATCH] Parenthesis spacing patch (win32)

Applied, thanks! (r22519)

Re: [perl #44291] [PATCH] Fix for suncc

Ron Blaschke wrote: > Joshua Isom wrote: >> On Oct 13, 2007, at 7:20 AM, Ron Blaschke wrote: >>> Attached patch should fix computed goto on Solaris with the Sun C >>> compiler. > [snip] >>> Could someone please review the patch if I got it right, and m

Re: [perl #44291] [PATCH] Fix for suncc

Joshua Isom wrote: > On Oct 13, 2007, at 7:20 AM, Ron Blaschke wrote: >> Attached patch should fix computed goto on Solaris with the Sun C >> compiler. [snip] >> Could someone please review the patch if I got it right, and maybe test >> it on other computed goto plat

Re: [perl #44291] [PATCH] Fix for suncc

Attached patch should fix computed goto on Solaris with the Sun C compiler. All tests successful (7 subtests UNEXPECTEDLY SUCCEEDED), 11 tests and 621 subtests skipped. Passed TODO Stat Wstat TODOs Pass List of Passed ---

Re: welcome ron to the company of parrots

jerry gay wrote: > i've just given ron blaschke (aka ron or rblasch) a commit bit. please > join me in welcoming him to the core committers. over the last few > years, ron has submitted many high-quality patches, and has always > been willing to share his knowledge of windows-

Re: mod_perl6 update

Jeff Horwitz wrote: > It gives me great pleasure to introduce you to the world's first > mod_perl6 handlers! They are run using Parrot's Perl6 compiler on top > of mod_parrot, and are compiled on the fly the first time a handler is > called. Each handler is passed an [Apache;RequestRec] object >

Some Thoughts on Windows Linking and Loading

Linking and loading is arguably one of the more difficult things on Windows. I'd like to let you know about how some of the things work. I think this is important because there are still some issues with that we need to sort out. Not sure if I get everything right here, so please feel free to co

Re: [perl #44967] Using a freed variable (Coverity CID 98)

I've had another look at this. Here's what I think is going on. The relevant output is: Event use_after_free: Using freed pointer "(ins)->next" Also see events: [alias][freed_arg] 493 for (ins = unit->instructions; ins; ins = ins->next) { Event alias: aliasing "(ins)->next" with "ins2" Also s

Re: [perl #43191] [BUG] Parrot doesn't build on Solaris: cannot dereference non-pointer type

Bernhard Schmalhofer via RT wrote: > On Di. 12. Jun. 2007, 22:38:24, rblasch wrote: >> I tried to smoke r18926 on Solaris but failed because of tons of "cannot >> dereference non-pointer type" errors. > > Ronald, can you still verify this with svn HEAD ? Yes, still a problem with HEAD. I should

Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed

Bernhard Schmalhofer wrote: > Ron Blaschke via RT schrieb: >> In all three sections a value is loaded into a register and then set as >> an attribute on an object. >> >> In the first hunk only the used register is changed from 0x12 to 0x13. >> In the second

Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed

Bernhard Schmalhofer (via RT) wrote: > # New Ticket Created by Bernhard Schmalhofer > # Please include the string: [perl #45109] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=45109 > > > > In languages/lisp/system.pir

Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed

Bernhard Schmalhofer (via RT) wrote: > # New Ticket Created by Bernhard Schmalhofer > # Please include the string: [perl #45109] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=45109 > > > > In languages/lisp/system.pir

Re: [perl #44967] Using a freed variable (Coverity CID 98)

Paul Cochrane wrote: I've had a chance to look at this and the implementation looks quite good to me. There's one thing that still bothers me. The snipped output is: > Event alias: aliasing "(ins)->next" with "ins2" > Also see events: [freed_arg][use_after_free] > At conditional (1): "ins2 != 0

Re: [perl #44967] Using a freed variable (Coverity CID 98)

Paul Cochrane wrote: > On 27/08/07, Ron Blaschke <[EMAIL PROTECTED]> wrote: >> Paul Cochrane wrote: >>> On 26/08/07, chromatic <[EMAIL PROTECTED]> wrote: >>>> On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote: >>> Ok, I'll just t

Re: [perl #44967] Using a freed variable (Coverity CID 98)

Paul Cochrane wrote: > On 26/08/07, chromatic <[EMAIL PROTECTED]> wrote: >> On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote: >> >>> The variable ins2 is freed by the call to subst_ins() but is then >>> later assigned to later in the if-block. Um, this isn't a good idea >>> is it? Th

Re: Current win32 linking issues: Summary

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 t

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

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

Re: Current win32 linking issues: Summary

Hi Mark, Mark Glines wrote: > On Mon, 20 Aug 2007 18:37:05 -0700 > Mark Glines <[EMAIL PROTECTED]> wrote: >> Jerry added a workaround in r20641, declaring a local variable >> PMCNULL within the test code, to get it to pass. Unfortunately, this >> workaround causes Darwin to fail with the message

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

Leopold Toetsch wrote: > Am Mittwoch, 15. August 2007 20:05 schrieb Ron Blaschke: >> Visual C++ seems to optimize quite heavily, and it looks like it reuses >> the memory on the stack where arguments are passed for local variables. > >> mov dword ptr [ebp+0Ch],edx >

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

Hi, JIT is currently broken on x86 Windows using optimized Visual C++ builds. Here's the reason why. Hopefully someone more familiar with the JIT can pick this up. ... 04e45c9a 68f06fe604 push4E66FF0h 04e45c9f e8370a1c0b call_Parrot_set_returns_pc 04e45ca4 83c404 add

Re: [Win32] There's a new compiler in town (sort of)

Hi Joshua, Joshua Hoblitt wrote: > Can you submit a patch for the PLATFORMS file? Here it is. http://rt.perl.org/rt3/Ticket/Display.html?id=44527 Ron

Re: [Win32] There's a new compiler in town (sort of)

Hi Andy, Andy Lester wrote: > On Aug 7, 2007, at 10:25 AM, Andy Armstrong wrote: > >> This any use? >> >> http://msdn.microsoft.com/vstudio/express/ > > Beautiful. Sure looks like it. There are a bunch of different editions available. Each edition contains a different compiler with a differen

Re: [Win32] There's a new compiler in town (sort of)

jerry gay wrote: > On 8/7/07, Ron Blaschke <[EMAIL PROTECTED]> wrote: >> Microsoft is working on the next iteration of their compiler, Visual C++ >> 9.0, currently in Beta2. >> >> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.20706.01 >&g

[Win32] There's a new compiler in town (sort of)

Microsoft is working on the next iteration of their compiler, Visual C++ 9.0, currently in Beta2. Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.20706.01 for 80x86 The current setup is: Visual Studio 2008 Beta2 Subversion 1.4.4 Perl 5.8.8 Parrot r20516 It builds right out of the b

ctags - confused

Jerry noticed that some symbols are missing with ctags, for example C. This happens for me too with ctags 5.6 on Win32, but other versions or platforms could suffer from the same problem. $ ctags --version Exuberant Ctags 5.6, Copyright (C) 1996-2004 Darren Hiebert Compiled: Jul 30 2006, 16:12:

Re: [perl #44213] docs/faq.pod - fix L pod abuse

Will Coleda via RT wrote: > Seems like a pretty straightforward patch, but isn't the L<> syntax > used currently proper? Is there a particular pod reader we're trying > to make happy? I tripped over this recently too. >From perlpod: * "L" Links to an absolute URL. For example, "L

Re: Odd Memory Corruption

chromatic wrote: > In theory, this patch should apply and run cleanly. It doesn't. > > Thus, something somewhere pokes into memory it shouldn't. > > Any ideas? Alternately, any comments on this analysis? I think adding memory checks is a brilliant idea, especially because memory is sometimes r

Optimized Build Failures on Win32

Parrot fails with an optimized build on Win32, Visual C++. Here are a few random observations, not sure if they are pointing to the problem or are merely side effects. It seems like the failures only affect JIT execution. I'm only seeing this with some shootout tests during C, as those are setti

Re: [perl #43187] [BUG] MinGW (build) busted?

chromatic wrote: > On Sunday 24 June 2007 04:48:19 Ron Blaschke wrote: > >> Thanks for picking this up. The problem was caused by C<#pragma once> >> which MinGW GCC 3.4.2 seems to choke on. There was some discussion on >> the list ("Removing #pragma") to

Re: [perl #43187] [BUG] MinGW (build) busted?

chromatic wrote: > On Tuesday 12 June 2007 22:28:26 Ron Blaschke wrote: > >> I tried to build r18933 and received the following error message: >> >> ... >> src\global_setup.c >> src\interpreter.c >> In file included from src\interpreter.c:38: >&g

Re: [perl #39426] [BUG] Can't build with cygwin.

Paul Cochrane wrote: >> Paul Cochrane wrote: >> >> Without the manual setting of PATH before building? >> > >> > With the manual PATH setting. There are several tickets for cygwin >> > not building in RT; are they all related? Is there something like a >> > hints file where the information about

Re: [perl #41569] t/distro/file_metadata.t fails on win32

Paul Cochrane wrote: > I couldn't get your patch to apply cleanly and so hacked it in by > hand. I'm attaching a new patch to this email (which is quite > possibly identical to yours) so that you can give it a quick test. If > all is happy, then I'll commit the change and close the ticket. I lo

Re: [perl #41569] t/distro/file_metadata.t fails on win32

Paul Cochrane wrote: >> > But if we convert what MANIFEST provides (i.e. Unix directory >> > separators) into whatever the current platform needs (i.e. what >> > canonpath() does) then it should agree with whatever svn spits out. >> > Or am I missing something? >> >> No, that's exactly what I think

Re: [perl #41569] t/distro/file_metadata.t fails on win32

Paul Cochrane wrote: > On 11/06/07, Ron Blaschke <[EMAIL PROTECTED]> wrote: >> jerry gay wrote: >> > On 6/11/07, Paul Cochrane <[EMAIL PROTECTED]> wrote: >> >> On 09/03/07, chromatic <[EMAIL PROTECTED]> wrote: >> >> > On Friday 09 M

Re: [perl #41569] t/distro/file_metadata.t fails on win32

jerry gay wrote: > On 6/11/07, Paul Cochrane <[EMAIL PROTECTED]> wrote: >> On 09/03/07, chromatic <[EMAIL PROTECTED]> wrote: >> > On Friday 09 March 2007 05:00, Ron Blaschke wrote: >> > >> > > Attached patch replaces the backslashes with slashes o

Re: [perl #39426] [BUG] Can't build with cygwin.

Paul Cochrane wrote: >> Without the manual setting of PATH before building? > > With the manual PATH setting. There are several tickets for cygwin > not building in RT; are they all related? Is there something like a > hints file where the information about the PATH can be set so that > cygwin b

Re: odbc.lib still linked?

Klaas-Jan Stol wrote: > recently a patch was supplied and applied for odbc32.lib being linked into > parrot. > > This file is not needed for Parrot, but it seems it is still linked (at > least, here on my machine, winxp). > > \parrot\library\PAST-pm.pbc >C:\Perl\bin\perl.exe -e "chdir sh

Re: Limiting Exported Symbols on GCC

Nicholas Clark wrote: On the other hand, we've managed very well in Perl 5 with the flag data in embed.fnc and generating the annotated headers programmatically. Interesting. I quite like this. Nicholas Clark Ron

Re: Limiting Exported Symbols on GCC

Nicholas Clark wrote: On Thu, Apr 12, 2007 at 04:56:15PM +0200, [EMAIL PROTECTED] wrote: On Thu, Apr 12, 2007 at 09:13:14AM -0500, Steve Peters wrote: 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 availab

Re: [Proposed PATCH] Change libparrot Names and Locations

jerry gay wrote: On 4/12/07, Ron Blaschke <[EMAIL PROTECTED]> wrote: Attached is a proposed patch to change the libparrot names and locations for Windows. I have tested the changes for "core" Parrot on Win32 Visual C++, Cygwin GCC, MinGW GCC and Ubuntu GCC. this looks fab

Limiting Exported Symbols on GCC

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://g

[Proposed PATCH] Change libparrot Names and Locations

Attached is a proposed patch to change the libparrot names and locations for Windows. I have tested the changes for "core" Parrot on Win32 Visual C++, Cygwin GCC, MinGW GCC and Ubuntu GCC. Minor Changes - * libparrot_(static|shared) now contains the path to the library, not the l

Re: Current State of Building Parrot on Cygwin

chromatic wrote: On Sunday 01 April 2007 07:15, Ron Blaschke wrote: As recently discussed it is currently necessary to include the absolute path to F in the environment variable PATH. This should be done before trying to built parrot, otherwise one gets a broken F and F. One needs a "

Re: Current State of Building Parrot on Cygwin

Steve Peters wrote: On Sun, Apr 01, 2007 at 04:15:24PM +0200, Ron Blaschke wrote: As recently discussed it is currently necessary to include the absolute path to F in the environment variable PATH. This should be done before trying to built parrot, otherwise one gets a broken F and F. One

Re: Current State of Building Parrot on Cygwin

Eric Hanchrow wrote: "Ron" == Ron Blaschke <[EMAIL PROTECTED]> writes: Ron> If you see this error ... Ron> the file has Windows line endings Dare I suggest that parrot not be so fussy about line endings? I second that. ;) Actually, both things are suppose

Current State of Building Parrot on Cygwin

Hi, As recently discussed it is currently necessary to include the absolute path to F in the environment variable PATH. This should be done before trying to built parrot, otherwise one gets a broken F and F. One needs a "make clean" or remove *both* files before trying again. Make sure to

Link'n'Load on Windows

Hi, I currently looking at some issues on Windows. 1) Linking There are a few symbols not exported which cause link errors in tests. I'll provide a patch to export them. 2) Loading On Windows it's usually best to put the applications and libraries in the same directory, but libparrot is mo

Re: [perl #37997] r10604 build failure on Cygwin

Eric Hanchrow wrote: I think it's relevant to note that I'm using the native Win32 subversion client, and hence most of my files are in DOS format: carriage-return/linefeed at the end of each line. If I convert that file's line endings to Unix format (plain line-feeds) it works. You're right,

Re: [perl #37997] r10604 build failure on Cygwin

chromatic wrote: On Friday 30 March 2007 07:35, Ron Blaschke wrote: Not 100% on this, but I think one or two of the stm tests hang, too. t/pmc/stmlog.t, test 2? No, I think this one's fine. More like t/stm/queue.t test 2 and t/stm/runtime.t test 4. Actually, t/stm/queue.t some

Re: [perl #37997] r10604 build failure on Cygwin

Paul Cochrane wrote: Sorry, I guess there was some mental PATH overloading going on. Try adding the absolute path to F to PATH. export PATH=/path/to/parrot/blib/lib:$PATH And then "make." I tried this (although, I appended the blib path to PATH, not sure if that makes a difference) and

Re: [perl #37997] r10604 build failure on Cygwin

Ron Blaschke wrote: Paul Cochrane wrote: I don't know if it's of much help, but I too am getting the Cygwin build barfing when miniparrot goes to build runtime/parrot/include/config.fpmc. I think that's actually a good sign. Try adding the absolute path to F and try aga

Re: [perl #37997] r10604 build failure on Cygwin

Joshua Gatcomb wrote: On 3/28/07, Ron Blaschke <[EMAIL PROTECTED]> wrote: Joshua Gatcomb wrote: If you could hang out on #parrot (irc.perl.org) when myself, Jonathan, particle, etc are around - it would go a long way towards getting a reproduceable test case that can be correctly artic

Re: [perl #37997] r10604 build failure on Cygwin

Paul Cochrane wrote: I don't know if it's of much help, but I too am getting the Cygwin build barfing when miniparrot goes to build runtime/parrot/include/config.fpmc. I think that's actually a good sign. Try adding the absolute path to F and try again. If this is working please see my previ

Re: [perl #37997] r10604 build failure on Cygwin

Joshua Gatcomb wrote: On 3/26/07, Ron Blaschke <[EMAIL PROTECTED]> wrote: Not sure about the details of this issue, but r17772 seems to build fine on Cygwin. Really? No one on #parrot has been able to get parrot to work on Cygwin for months. Interesting, didn't know about

[perl #37997] r10604 build failure on Cygwin

Not sure about the details of this issue, but r17772 seems to build fine on Cygwin. Here's the output of "make test" on my box. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/codingstd/

Re: [perl #41569] t/distro/file_metadata.t fails on win32

chromatic wrote: On Friday 09 March 2007 05:00, Ron Blaschke wrote: Attached patch replaces the backslashes with slashes on Windows. Would using File::Spec be less fragile? The problem basically boils down to matching a list of MANIFEST (UNIX?) files with the (native file name, attribute

Re: [perl #41569] t/distro/file_metadata.t fails on win32

Will Coleda wrote: I expect the first two to pass, but metadata is often often overlooked on commits. The last one is a new test, not everything has been updated yet. (And I'm not sure it *can* be without breaking windows). Should be passing the second test again as of r17398. Thanks for y

[perl #41569] t/distro/file_metadata.t fails on win32

Hi, Could someone please tell me the expected result of t/distro/file_metadata.pl at revision 17389? After looking into bug #41569 I'm getting the following on Windows (XP, SP2, VC++ 8.0, Subversion). >prove t/distro/file_metadata.t t/distro/file_metadata# Collecting svn:mime-type attr

Re: Building Parrot::Embed on Windows XP / Visual C++

chromatic wrote: > On Saturday 23 December 2006 11:32, Ron Blaschke wrote: > >> It would be great if you could make the change right away. I thought it >> was just too small of a change to submit an official patch. > > Thanks, applied as of r16229. > >>>

  1   2   3   >