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 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
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
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
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
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
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
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
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
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
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 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
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
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
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
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.
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
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\imcc\imcparser.c
> imcparser.c
> compiler
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 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
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,
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]
#
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
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
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
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 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:\
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, 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:
> 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
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
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
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
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
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
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
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
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
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
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
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 <[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
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
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
Monday, April 25, 2005, 5:52:42 PM, jerry gay via RT wrote:
> On 4/23/05, Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> IMHO, compilation and linkage feels quite messy as a whole. I am not
>> sure how to get the current link command to look like the one above,
>> withou
Ron Blaschke wrote:
> link -dll -def:libparrot.def -nologo -nodefaultlib -o
> pge.dll pge_parse.obj pge_gen.obj pge_opt.obj pge_parsep5.obj
> pge_parseglob.obj
> LINK : warning LNK4044: unrecognized option '/o'; ignored
> LINK : fatal error LNK1181: cannot open inp
Seems to have been applied, in one way or the other. F
uses C. This ticket should be closed.
Can't reproduce, seems to pass C call. Should be closed.
.sub _main # void win32_setup(void)
loadlib P1, "kernel32.dll"
dlfunc P0, P1, "GetStdHandle", "pi"
set I0, 1
set I5, -11
invoke # Will crash here.
store_global "kernel32", P1
store_global "Win32handle", P5
e
t\pmc\complexok
All tests successful.
Files=1, Tests=26, 3 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Seems to be fixed, should be closed.
Bummer, forgot to attach the patch. Here it is.
capture_output_with_stderr.patch
Description: Binary data
Here are the test results for /trunk r7851 on
Windows XP SP2
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Activestate Perl 5.8.6
Activestate Python 2.4.0
ANTLR 2.7.5
ICU 3.2
GDBM 1.8.3
GMP 4.1.4
Tested configurations are
perl Co
Leopold Toetsch wrote:
> I can't test Win32 patches, so I can apply these only as is.
I am trying to cover this base with constant "update, build,
post-to-list, patch" cycles. ;-)
Ron
jerry gay wrote:
> On Apr 12, 2005 12:06 PM, Solinski, Mark <[EMAIL PROTECTED]> wrote:
>> > Has anyone successfully built Parrot on Win32 (MSVC 13.10.3077)
>> > recently?
> parrot builds fine on win32--vc-7.1-perl-5.8.6 for me, without icu. i have
> been building this way for some time now.
> co
Leopold Toetsch wrote:
> t/src/manifest.t tests 3 and 4 used to compare MANIFEST file entries
> against CVS/Entries. The latter is now .svn/entries with an xmlish syntax.
> The job is now to replace t/src/manifest.t:scan_cvs so that it extracts
> C items from .svn/entries and descends into C
> sub
Jens Rieks wrote:
> On Monday 11 April 2005 13:48, Ron Blaschke wrote:
>> I think this is just a mime-type issue.
> Yes, that seems to be the reason. I looks like all *.t files are affected.
> Is there a way to specify the mime-type on a filetype basis?
I think it's always the
Nicholas Clark wrote:
> On Mon, Apr 11, 2005 at 01:43:39AM -, [EMAIL PROTECTED] wrote:
[snip]
>> Modified: trunk/t/perl/Parrot_IO.t
>> ==
>> Binary files. No diff available.
> Oops. Is this a property thing on all the
Robert Spier wrote:
> The conversion is done.
> http://www.parrotcode.org/source.html
> Have fun!
Sweet! Is there any particular reason why everyone should use https?
Shouldn't http do for non-committers? Or am I nitpicking here?
Ron
Leopold Toetsch wrote:
> 5) if you move $parrot/icu e.g. to $parrot/_icu you can run
>$ perl Configure.pl --nomanicheck
> Please verify the build on Windows platforms,
> thanks
Looks good on Windows XP, VC++ 7.1. F complains,
quite expectedly.
Ron
Ron Blaschke wrote:
> mmd failure is new, test 18 fails with the following message.
> t\pmc\mmdNOK 18# got: 'Method '__add' not found
[snip]
Forget about this, Leo just fixed it.
Ron
Failed TestStat Wstat Total Fail Failed List of Failed
---
t\dynclass\foo.t 1 256 11 100.00% 1
t\dynclass\gdbmhash.t13 332813 13 100.00% 1-13
t\dynclass\pybuiltin.t6 1536
Leopold Toetsch wrote:
> Ron Blaschke <[EMAIL PROTECTED]> wrote:
>> Parrot currently doesn't compile on Windows, b/c of the following in
>> F.
>> const MMD_init _temp_mmd_init[] = {
>> };
> Thanks, fixed.
Great, thanks!
>> There's g
Jens Rieks wrote:
> On Sunday 03 April 2005 10:06, Leopold Toetsch wrote:
>> Jens Rieks wrote:
[snip]
>> then we verify that we can build with a system ICU or without. Then we
>> can move over to SVN and procede with step 4).
> Why don't we remove the support for the bundled ICU prior to the move?
Parrot currently doesn't compile on Windows, b/c of the following in
F.
const MMD_init _temp_mmd_init[] = {
};
error C2059: syntax error : '}'
There's gotta be at least one element in the array. Not sure why this
compiles on other platforms, though.
Ron
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
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:
>> 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:
> 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
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
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
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 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
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
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
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
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
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
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
Please mark this patch as rejected. It's not tasty enough for our
patchmonster.
> [jgloudon - Sun Aug 25 17:15:36 2002]:
> This is a simple fix to the broken libparrot.a makefile target for
> Visual C++
> win32 builds so that 'nmake test' works. This does not fix other non-
> UNIX
> targets and win32 builds with the borland compilers. The latter should
> be a
> matter of prov
t/pmc/nci.t passes. This ticket should be closed.
t\pmc\nciok
All tests successful.
Files=1, Tests=56, 20 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
The ticket for the more generic solution is
#31649: [TODO] Win32 - Automatically Export Symbols
Can't reproduce this one. Please close the ticket.
t/src/iook
1/20 skipped: fdopen does not handle illegal modes correct
All tests successful, 1 subtest skipped.
Files=1, Tests=20, 55 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
t/pmc/nci.t passes. Please close this ticket.
t\pmc\nciok
All tests successful.
Files=1, Tests=56, 19 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
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:
>> 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:
>> 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
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 ...).
>
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
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 =
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
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
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
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
I'll tackle this one next.
Ron
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
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 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
Just curious. Are there any plans moving parrot to subversion?
Ron
101 - 200 of 245 matches
Mail list logo
