On Sat, 12 Nov 2005 09:58:49 -0800, Jerry Gay wrote:
>
> the following output is snipped from parrot's build output with msvc-7.1:
> classes\env.pmc(26) : warning C4273: '__p__environ' : inconsistent dll linkage
> D:\usr\local\perl\bin\perl.exe build_tools\pmc2c.pl --c
> classes\env.pmc
Hi everyone,
I am not a regular to this list but I'd like to induce some thoughts on
threading. I'm not too much into the subject myself, but I've got some
pointers, which I hope are of some use. Please ignore me if I am not
making any sense here.
Herb Sutter has an interesting article called "
The following test results are taken from Revision 10428 on a Windows
XP, Visual C++ 2005 Express Edition box.
Doesn't look too bad. I only had to change one thing: Remove the
declaration C from C. For
that see also ticket perl #37665 [1].
Also, there are a lot of warnings for IO and string fuc
Leopold Toetsch wrote:
> On Dec 10, 2005, at 16:50, Ron Blaschke wrote:
Here's a side by side comparison, Revision 10460, of
Visual C++ 7.1 and 8.0.
arithmetics.t suffers from -0.0 vs 0.0 problems. We've had something
similar some time ago. They seem to have changed that in 8.0
jerry gay wrote:
> On 12/12/05, Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> arithmetics.t suffers from -0.0 vs 0.0 problems. We've had something
>> similar some time ago. They seem to have changed that in 8.0, as the
>> test passes there.
>>
> it s
Tuesday, December 13, 2005, 7:43:07 PM, jerry gay via RT wrote:
> applied locally, it fails on my earlier msvc install due to a version
> comparison error:
> Determining if your C compiler is actually Visual C++..Argument "13.1.10"
> is
> n't numeric in numeric ge (>=) at config/auto/msvc.pm
jerry gay wrote:
> classes\env.pmc(26) : warning C4273: '__p__environ' : inconsistent dll linkage
> D:\usr\local\perl\bin\perl.exe build_tools\pmc2c.pl --c
> classes\env.pmc
> normally, i'm able to squash all compiler warnings, but i'm having
> trouble tracking this one down. this, by the
Tuesday, December 13, 2005, 10:38:42 PM, jerry gay wrote:
> On 12/13/05, Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> jerry gay wrote:
>> > classes\env.pmc(26) : warning C4273: '__p__environ' : inconsistent dll
>> > linkage
>> > D:\
On Mon, 12 Dec 2005 12:18:47 +1300, Sam Vilain wrote:
> On Thu, 2005-12-08 at 17:16 +0100, Ron Blaschke wrote:
>> The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software."
>> [1] He starts with "The biggest sea change in software development since
>>
Lacking committer privileges, I'd like to discuss patches first. I'll
only start coding anything after I received at least one +1 from a
committer. After that I would submit a patch and wait for it to be
applied or rejected. That way I hope to avoid warnocked patches.
t/pmc/env.t is failing on
Tuesday, December 20, 2005, 8:09:32 PM, François PERRAD wrote:
> At 11:53 16/12/2005 +0100, you wrote:
>>I can think of two ways to fix this:
>>
>>- Hide every env access behind the platform stuff. That is, add
>>something like Parrot_environ.
> For me, this way sounds better.
> The platform/env
jerry gay wrote:
> compiling either with msvc 6.0 or 7.1 on win32, parrot behaves
> differently wrt 0 vs -0 depending on whether optmizations are enabled.
> nmake realclean && svn up && configure.pl && nmake smoke
> ## passes tests, which expect 0 and not -0
> nmake realclean && svn up && config
Here are my test results for r12017 using Visual C++ 8.0 (Visual C++
2005 Express Edition).
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/configure/step.t 2 512192 10.53% 10-11
t
t/examples/streams.t fails on Windows with something like
# got: 'read:[1 =head1 INFORMATION\015]
# read:[2 \015]
.
# expected: 'read:[1 =head1 INFORMATION]
# read:[2 ]
and
# got: 'read:[=head1 INFORMATION\015\n\015\nThis small example shows
the]
#
chromatic wrote:
On Saturday 25 March 2006 07:47, Ron Blaschke wrote:
t/configure/step.t
$fromfile and $tofile needs to be closed before calling
move_if_diff, as Windows can't delete open files.
I forgot to check this in a while back, but fixed now as #16032 (I hope).
Thanks,
jerry gay wrote:
On 12/22/05, Ron Blaschke <[EMAIL PROTECTED]> wrote:
Tuesday, December 20, 2005, 8:09:32 PM, François PERRAD wrote:
At 11:53 16/12/2005 +0100, you wrote:
I can think of two ways to fix this:
- Hide every env access behind the platform stuff. That is, add
somethin
Here's another round of test results on my box. I've also added the
details for the tests that failed. The C and
are not unexpected on Windows.
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/doc/
Jerry Gay (via RT) wrote:
> # New Ticket Created by Jerry Gay
> # Please include the string: [perl #39760]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=39760 >
>
>
> compilers\imcc\imcparser.c
> imcparser.c
> compiler
Leopold Toetsch wrote:
> Am Samstag, 15. Juli 2006 21:27 schrieb Ron Blaschke:
>
>> Attached patch brings the declarations of imcc_init in main.c and imc.h
>> in sync.
>
> Well, much simpler - I've deleted the line in main.c :-)
> Thanks for the hint.
Bummer,
Jerry Gay (via RT) wrote:
> # New Ticket Created by Jerry Gay
> # Please include the string: [perl #39760]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=39760 >
>
> compilers\ast\astparser.c
> astparser.c
> compilers\as
I'm looking into this issue and would like to ask for some advice.
I have added the following platform dependent functions.
int Parrot_math_isnan(double)
int Parrot_math_finite(double)
On Win32 the implementation is simple because the IEEE recommended
functions _finite and _isnan are supported.
Will Coleda wrote:
> Since both tcl and perl seem to like this style (but I'm sure some
> languages need truly native representations), I'd propose that the OS
> PMC give a way to say which is preferred.
I agree.
As another note, many programs are fine with forward slashes, including
Microsoft's
I'm looking into this issue and would like to ask for some advice.
I have added the following platform dependent functions.
int Parrot_math_isnan(double)
int Parrot_math_finite(double)
On Win32 the implementation is simple because the IEEE recommended
functions _finite and _isnan are supported.
Bill Coffman wrote:
> There is no platform independent way to produce "NaN" or "Inf", so IMHO,
> you
> did it the only way it can be done.
>
> That being said, you can optimize by looking at the bits. Wikipedia
> explains IEEE-754 http://en.wikipedia.org/wiki/IEEE_754
Many thanks for your though
Bill Coffman wrote:
> NegNan doesn't exist, except as a fluke of the representation (see link for
> how they are represented). A -NaN is the same as a NaN. They both fail
> all
> comparison tests, even NaN == NaN is false (unless your compiler optimizes
> the comparison out). Only difference is
Philip Taylor wrote:
> Ron Blaschke wrote on 01/08/2006 08:17:
>>
>> I am wondering if this NaN != NaN property could be used for the isnan
>> and finite tests, like so:
[snip]
>> Is this not portable enough? Is it better to look at the bits directly?
[great stuff sn
This is on trunk, revision 14585, using Windows XP and Visual C++.
I have GDBM available as "gdbm.lib" which is successfully tested for in
config/auto/gdbm.pm.
Determining if your platform supports gdbm...
...
gdbm is working.
(yes) .done.
For some reason
Will Coleda wrote:
> Applied as r14586.
>
> Jerry Gay was having a similar issue yesterday.
>
> Anyone with gcc on win32 care to verify it works for them still?
>
> Some of this duplicate (or disparate) build logic will hopefully go away
> as the build system gets cleaned up in the coming weeks.
This is about revision 15444. Parrot seems to smoke not bad on my
Windows XP / Visual C++ 8 box.
6734 test cases:
6687 ok,
47 failed,
268 todo,
585 skipped
and 0 unexpectedly succeeded
I thought I'd remove C<-DNDEBUG> from the compiler flags for smoking
Parrot, but this causes t
Nikolay Ananiev (via RT) wrote:
> # New Ticket Created by "Nikolay Ananiev"
> # Please include the string: [perl #40998]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=40998 >
> When build_dir contains spaces the build p
Jonathan Worthington wrote:
> chromatic via RT wrote:
>> With ICU optional these days, is this still necessary?
>>
> Since Windows doesn't ship with a C compiler and this toolkit is one of
> the easiest ways to get hold of one for free, then yes, it's good to
> have it documented. (It may be *ca
Jonathan Worthington wrote:
> Ron Blaschke wrote:
>> Seems like the old Visual C++ Toolkit 2003 is discontinued.
>>
>> http://msdn2.microsoft.com/en-us/visualc/aa336490.aspx
>>
> Aha. If you would have a moment to write these latest changes into
> readme.win32.p
Sorry to bring this up again, but I hope someone can help me with this.
I'm trying to compile Parrot on Windows XP / Visual C++ with assertions
enabled, that is, without C.
When running miniparrot I receive the following error:
Assertion failed: (PTR2UINTVAL(mmd_table[i].func_ptr) & 3) == 0, fil
chromatic wrote:
> On Wednesday 20 December 2006 11:24, Ron Blaschke wrote:
>
>> - The assertion seems to check that the lowest two bits of a function
>> pointer are zero. Why's that?
>
> Presumably because pointers need a specific alignment, so those two bits wi
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
I have managed to build Parrot::Embed on Windows/VC8, and judging from
the test output it works. There are two warnings, but I guess those are
no problem?
$ ./Build test
t\interpok 1/31Parrot VM: Can't stat no file here, code 2.
error:imcc:syntax error, unexpected IDENTIFIER
chromatic wrote:
> On Friday 22 December 2006 11:08, Ron Blaschke wrote:
>> There are three steps necessary (four using VC8).
>>
>> 1) Two additional functions need to be exported.
>> Parrot_register_pmc
>> Parrot_unregister_pmc
>
> In some .def f
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, Parro
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.
>
>>>
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
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
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
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/
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
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
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
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
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
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
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,
chromatic wrote:
> On Mon, 2005-05-16 at 09:58 -0700, Ron Blaschke wrote:
>> Attached patch quotes some paths.
>> Otherwise Parrot won't built if living below a directory containing
>> spaces (eg "C:/Documents and Settings").
> Will this have problems if a
Below are the test results of
Windows XP SP2
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077
for 80x86
Activestate Python 2.4.1 Build 245
Activestate Perl 5.8.6 Build 811
ANTLR 2.7.5
ICU 3.2
GDBM 1.8.3
GMP 4.1.4
Failed TestStat Wstat T
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> t\op\spawnw.t 5 1280 65 83.33% 2-6
> exit status?
Quite likely, yes. I'd gladly provide a patch, if someone would
decide The Right Thing To Do. That is, what should
Parro
Ron Blaschke wrote:
> Leopold Toetsch wrote:
>> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>>> t\pmc\bigint.t1 256221 4.55% 22
>> What's up with that one?
> Maybe my fault. The program segfaults at C in
> C. Memory gets alloc
Leopold Toetsch wrote:
> Ron Blaschke wrote:
>> Ron Blaschke wrote:
>>>>>t\pmc\bigint.t1 256221 4.55% 22
>> The problem seems to be caused by the C in
>> F. Well, not the actual cause, but that's
>> where we fail.
> mp
Leopold Toetsch wrote:
> Jerry Gay <[EMAIL PROTECTED]> wrote:
>> dynclasses and spawnw have been busted on win32 for some time now.
>> with this patch, these annoying test failures will be skipped on
>> win32.
> Good, just commit it ;-)
Just my opinion on this: I'd rather see failures for things
Nothing unexpected, I guess.
Windows XP SP2
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Activestate Python 2.4.1 Build 245
Activestate Perl 5.8.6 Build 811
ANTLR 2.7.5
GNU bc 1.06
GNU m4 1.4
ICU 3.2
GDBM 1.8.3
GMP 4.1.4
Faile
Feeling adventurous today, I decided to give the Microsoft Visual C++
8 / 2005 / 14 (Beta2) - whatever the version number is - a whirl.
http://lab.msdn.microsoft.com/express/visualc/default.aspx
There are a number of deprecation warnings - mostly string function,
probably because their vulnerable
Nick Glencross wrote:
> My understand is that on Windows DLLs must be self-contained and cannot
> have unreferenced symbols, and so I've linked against libparrot.so which
> of course pulls in much of its code. I see this also being done in the
> MSWin32 case...
Yes, Windows needs to know where the
I'm feeling rather dumb asking this, but F says:
Currently GNU bc is only used for doublechecking Parrot bc.
Now, my question is: Where is "Parrot bc?"
Ron
Bernhard Schmalhofer wrote:
> Ron Blaschke schrieb:
>>Now, my question is: Where is "Parrot bc?"
> "Parrot bc" is sitting on my local disk, being very disfunctional.
> I'll check it in, as soon as it does something useful.
I see.
> It will Python
Hi!
I'm using a current MS compiler (Version 13.10.3077) and ActiveState Perl
5.8.0 (Build 806) to compile parrot. The compiler warns about
c1 : warning C4349: /Gf is deprecated and will not be supported in future
versions of Visual C++; remove /Gf or use /GF instead
which is specified by Activ
Sunday, November 7, 2004, 11:25:52 AM, Jens Rieks wrote:
> On Sunday 07 November 2004 09:48, Leopold Toetsch wrote:
>> * where exactly is the mismatch coming from?
> Unix uses "\n" to indicate end-of-line, windows uses "\r\n". The problem is,
> that the "perlhist.txt" file is checked in as a text f
On Mon, 08 Nov 2004 09:45:06 -0600, Christian Lott wrote:
> "Do you hvae msvc (cl.exe) in the path?"
> No. I thought I did but looks like I don't...
> It's at c:\Program Files\Microsoft Visual C++ 2003\bin\cl.exe
> How would I set the path without overwriting my previous settings?
> set PATH=%PATH%
On Mon, 08 Nov 2004 10:46:47 -0600, Christian Lott wrote:
> Ron Blaschke wrote:
>>No. Look for a batch file called vcvars32.bat below the Microsoft Visual
>>C++ 2003 directory, and run it. It'll setup your environment.
>>"dir /s vcvars32.bat"
> OK. Path
Thursday, November 11, 2004, 5:42:29 PM, Dan Sugalski wrote:
> Or something like that.
[snip]
FWIW, I really like the idea.
Will there be a data type for "characters," or are those just strings
with a single grapheme?
As a side note, the Java people decided for UTF-16 Unicode "char"s,
and some
Leopold Toetsch wrote:
> Sriram Krishnan <[EMAIL PROTECTED]> wrote:
>> I'm trying to build Parrot (from CVS) on Win XP Sp2 with VS.-NET 2003.
> Please folks with Windows installed: have a look at these issues.
I'm running Windows XP, VS.NET 2003 and (precompiled) ICU 3.0, and can
confirm the offe
Just had a look at the following test failures on Windows.
t\pmc\nci.t 2 512562 3.57% 3 46
I have added the test output below. It may not look that way at first
sight, but the failures are a result of missing exported symbols in
libnci_test.dll (which remembers me of my
Sorry for the inconvenience, but please drop the original patch, and
use this one instead.
This patch adds all missing export symbols to libnci_test.dll that are
needed by t/pmc/nci.t.
t\pmc\nciok
All tests successful.
Files=1, Tests=56, 18 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Just curious. Are there any plans moving parrot to subversion?
Ron
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> I am not sure what things are known (expected?) to broken,
> The normal CVS state is that "make test" succeeds on linux and OS X.
> Intermittent expected failures are announced here.
Great, that
Will Coleda wrote:
> Ron Blaschke writes:
>> On a personal note, I (still) really like to help in win32, though
>> it's quite hard for me to get a grip on this collaboration thingy.
> *looks around* Apparently, you're not the only one. =-)
;-)
I've been blinki
Sriram Krishnan wrote:
> Post #1
> Post #2
> I managed to get it to build finally. I built ICU 2.8 and co-py-pasted
> the data output to the blib folder.I don't think this is the- way to do
> it - but hey..it works :)
> Post #3
[snip]
I have set up the things as described in README.win32 (actuall
chromatic wrote:
> On Sat, 2005-02-05 at 12:58 -0800, chromatic wrote:
>> Why not generate the .def file instead of hoping that people add the
>> correct symbols? Here's a patch that seems to do the trick for me
>> (though not running Windows, I can't really test if the defines are all
>> correct
Jonathan Worthington wrote:
> "Ron Blaschke" <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch wrote:
>>> Sriram Krishnan <[EMAIL PROTECTED]> wrote:
>> Failed Test
Sriram Krishnan wrote:
> Thanks for the reply. Readme.Win32 should have a notice about building in
> anything other than Visual Studio 6. Since 'msdev' is hardcoded inside the
> ICU build stuff, it *won't build on anything other than Visual Studio 6*.
> For anyone interested, I've written step-by-s
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> assign nci_dlvar_float, nci_dlvar_float_decl
> This calls Undef::assign, which morphs the Undef to the RHS type. So the
> Undef becomes an array and
>> N2 = nci_dlvar_float[0]
> thi
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> I see. Does this morphing work as designed? Creating an array out of
>> an undef feels somewhat wrong.
> Yes and yes ;)
> A longer answer is: all operators currently need an existing LHS.
[snip]
T
Bernhard Schmalhofer wrote:
> Ron Blaschke wrote:
>> I haven't checked the details, but I think this will not work, as it
>> seems to generates a list of all symbols beginning with nci_, but
>> 'int_cb_D4' is used, too.
> nci_test.c is used only for testi
Just for your information: Here are the latest test results on
Windows.
Ron
Failed TestStat Wstat Total Fail Failed List of Failed
---
t\dynclass\pybuiltin.t5 1280 65 83.33% 1-2 4-6
t\dynclass
I'd like to clean up string_init, because it currently backfires
(segfaults) on Windows if parrot is installed (empty
DEFAULT_ICU_DATA_DIR ...).
Could someone please tell me what string_init is supposed to do, where
it _should_ look for the ICU data directory (if at all)?
...
build_path =
Dynclasses are broken on Windows for two reasons:
1) Missing exported symbols
If the powers that be give me a sign how it should be done, I'll
gladly implement it.
What do people think of my previous proposal? Is it any good?
"
How about this: We separate things into 2 steps.
1) Create a .sym fi
Monday, February 14, 2005, 12:07:51 PM, Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> I'd like to clean up string_init, because it currently backfires
>> (segfaults) on Windows if parrot is installed (empty
>> DEFAULT_ICU_DATA_DIR ...).
>
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> Now things boil down to creating the .sym files. These might be
>> created by grepping the source for C, C, etc, or
>> by whatever script created the compilation unit(s).
> Not everything that star
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> I've put the precompiled ICU into a directory, and supply the
>> --icushared and --icuheaders. This precompiled package contains only
>> the bin, include and lib. There's no data directory.
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch wrote:
>> If I would be the one to choose, I'd add the C macro
>> everywhere, and expand it to C<__declspec(dllexport)> on Windows (no
>> more .def files). I'd al
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> - adds correct linkage for gpm
>> Some tests fail, though
>> t\pmc\bigint.t 12 307221 12 57.14% 5-10 13-15 18 20-21
> Is there any indication what's going wrong?
Not y
Ron Blaschke wrote:
> Leopold Toetsch wrote:
>> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>>> - adds correct linkage for gpm
>>> Some tests fail, though
>>> t\pmc\bigint.t 12 307221 12 57.14% 5-10 13-15 18 20-21
>> Is there a
Here are the current test results on my WinXP, VC++ 7.1 box.
Failed TestStat Wstat Total Fail Failed List of Failed
---
t\dynclass\gdbmhash.t13 332813 13 100.00% 1-13
t\dynclass\pybuiltin.t6
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> Here are the current test results on my WinXP, VC++ 7.1 box.
> [ dynclasses failing ]
>> PS: Should I keep posting them from time to time, or are they of no
>> interest to anyone?
> Yes please
Gay, Jerry wrote:
> with this version installed, 'icudata.lib' is the proper name for
> --icushared.
> BTW your patch doesn't mention that you've changed versions from 2.8 to
> latest (currently 3.2), or update the version mentioned in the rest of the
> readme.
> if parrot runs successfully wit
I've been experimenting with dynamic linkage on Windows. As a teaser
to read on, here's how far I've got.
Before
Failed TestStat Wstat Total Fail Failed List of Failed
---
t\dynclass\foo.t 1 25
Chip Salzenberg wrote:
> According to Ron Blaschke:
>> - The parrot library should be named C and
>> C on Windows
> OK, but will Windows allow delimiter(s) on the DLL name? Without
> them, there's an ambiguity (is "parrot110.dll" 1.10 or 11.0?).
> Also
MrJoltCola wrote:
> At 04:08 PM 3/28/2005, Ron Blaschke wrote:
>> > On the one hand, IMCC doesn't really help you _run_ code, so I'm not
>> > inclined to see it part of libparrot. On the other hand, I haven't
>> > grokked the entire code base organiz
Chip Salzenberg wrote:
> According to Ron Blaschke:
>> The idea [of parrot01.dll] was mainly stolen from other projects,
>> guess it's some sort of convention on Windows. [...] Adding all
>> three parts, with dots, will work nicely, too, I guess.
> That'd b
F currently fails on Windows. The reason is that the
test expects the exit code in the higher byte of the termination
status. In other words:
set S1, 'perl -e "exit(123)"'
set I1, 99
spawnw I1, S1
shr I2, I1, 8
print "return code: "
p
Leopold Toetsch wrote:
> We gonna switch to SVN soon.
Lovely. :-)
> citing Chip:
> I think it would be a Good Thing for Parrot to live under Subversion
> rather than CVS. Just the change sets and rename tracking is enough
> reason, IMO.
I've been using SVN happily for almost a year now. It wor
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> The documentation for spawnw (F) says:
>> Spawn a subprocess and wait for it to finish. The return status,
>> which is very system-dependent, goes in $1.
> Yeah. What does Perl5?
$?
"
Leopold Toetsch wrote:
> Francois PERRAD <[EMAIL PROTECTED]> wrote:
>> I add a new target 'setup' in the main Makefile.
>> That's allow the creation of a setup-parrot-x.y.z.exe ('standard' binary
>> distribution) that contains all parrot install directories and the ICU
>> shared libraries.
> Shou
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> Or even:
>> nmake win32-installer
>> ?
>> The Windows equivalent of "rpm" would be "msi".
> Maybe then:
> nmake win32-inno-installer
> nmake win32-msi-insta
1 - 100 of 248 matches
Mail list logo
