On 06.04.2009 04:17, Bruce Gray wrote:
On Apr 5, 2009, at 6:48 PM, Lyle wrote:
--snip--
There is a problem with the Rakudo Makefile? Help would be very much
appreciated...
http://perl.bristolbath.org/blog/lyle/2009/04/first-perl-6-experiences.html
Yes, there is a problem. I have
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: '..\..\parrot.exe' : return
Will Coleda wrote:
On Wed, Jul 30, 2008 at 7:09 PM, James Keenan via RT
parrotbug-follo...@parrotcode.org 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,
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
outright on some
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
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 someone who is
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 probably a better
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.
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
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
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
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56756
On a win32 build with AS perl and the MS tools, I get
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 Cmake while building PGE.
../../parrot -o PGE.pbc --output-pbc PGE.pir
../../parrot
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 --intval=long long int
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
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 changes
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
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 files
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/Include/gl
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
9.0
Hi Geoffrey,
I managed to get the Fexamples/opengl/triangle.pir 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
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
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
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),
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
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 done
James E Keenan wrote:
Ron Blaschke wrote:
Hi,
I've been looking into a failure of Ft/dynoplibs/myops.t 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
chromatic wrote:
On Saturday 08 March 2008 07:31:08 Ron Blaschke wrote:
I've been looking into a failure of Ft/dynoplibs/myops.t 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
Hi,
I've been looking into a failure of Ft/dynoplibs/myops.t 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
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51104
during the build of languages/c99, specifically:
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
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
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
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 {
warn
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
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.
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
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/group/perl.perl1
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
Applied, thanks! (r22519)
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 maybe test
it on other computed goto platforms?
Just
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
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 platforms?
Just to clarify, you did
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
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-based programming.
Many
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
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 have
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 see
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45109
In languages/lisp/system.pir
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45109
In languages/lisp/system.pir
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 hunks it's register 0x11 to 0x12.
With hunk three
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 taking
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? The variable
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 tell the Coverity thing to ignore that particular warning.
Just curious
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
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
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 ld:
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
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
All I know about intel calling
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
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
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
for 80x86
The current setup is:
Visual Studio 2008
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 different feature
Jerry noticed that some symbols are missing with ctags, for example
Cmem_sys_free.
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
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:
* Lscheme:...
Links to an absolute URL. For example,
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
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 Cnmake test, as
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) too.
It looks like r18945 should have fixed
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
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 the PATH can be
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 needs to be
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 on Windows.
Would using File::Spec be less fragile?
I've
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 March 2007 05:00, Ron Blaschke wrote:
Attached patch replaces the backslashes
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 builds
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 shift
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
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?
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.
snip reasoning
this looks fabulous
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
available
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
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 supposed only as
workarounds until
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 Fblib/lib in the environment variable PATH. This should be
done before trying to built parrot, otherwise one gets a broken
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
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
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
Fblib/lib and try again
Paul Cochrane wrote:
Sorry, I guess there was some mental PATH overloading going on. Try
adding the absolute path to Fblib/lib 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
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 sometimes
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
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
Fblib/lib and try again. If this is working please see
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 articulated
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
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
---
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
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
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
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.
This is generally only tricky when building in-tree
chromatic wrote:
On Friday 22 December 2006 12:54, Ron Blaschke wrote:
-void Parrot_register_pmc(Parrot_INTERP, Parrot_PMC);
-void Parrot_unregister_pmc(Parrot_INTERP, Parrot_PMC);
+PARROT_API void Parrot_register_pmc(Parrot_INTERP, Parrot_PMC);
+PARROT_API void Parrot_unregister_pmc
Leopold Toetsch wrote:
Am Mittwoch, 20. Dezember 2006 20:24 schrieb Ron Blaschke:
- The assertion seems to check that the lowest two bits of a function
pointer are zero. Why's that?
That's a bigger hack to discern function from PMC pointers in that table.
That
hack and the whole table
1 - 100 of 241 matches
Mail list logo
