Attached is a FAQ I wrote up over a couple days to hopefully prepare for any
TPC fallout that might occur. (and FAQs are a good thing, from what I hear).
Anyways, any thoughts on where it should go, how it should be reworked to
fit in with other documentation, etc would be appreciated. Just looki
Here are the warnings that remain in MSVC on level 4.
1) core.ops(2481) : warning C4047: 'return' : 'void ** ' differs in levels
of indirection from 'long *'
This occurs when compiling core_ops_prederef.c. run_native and run_compiled
both return a long*. This meshes well with core_ops.c's use of
Just realized that I've been forgetting the [PATCH] modifier, so I apologize
about that. :)
This patch adds the ability to do: 'make quicktest' instead of 'make test'.
This patch causes the assemble.pl'ed output to be cached, and only
regenerated-when necessary. This causes the .pbc and .pasm fil
Yesterday I posted a MSVC-warning -cleanup patch, which did some incorrect
casts to BOOLVAL (thanks Steve Fink). This patch adds a TO_BOOLVAL macro,
and uses it everywhere a cast is needed.
Mike Lambert
to_boolval.patch
Description: Binary data
Some more minor fixes and cleanup to parrot's ability to read in pbc data
off of STDIN. Note that using an MSVC-compiled parrot doesn't work in
cygwin...it reads in less data than it should, both before and after this
patch. Only a gcc/cygwin-compiled parrot works in cygwin. I don't think this
is
This patch cleans up most of the MSVC-warnings when using warning level 4
(the highest, one above the default level 3). It turns off two level-4
warnings for 'unreferenced formal parameter' and 'named type definition in
parentheses', the latter of which was turning up warnings in MS VC headers.
Le
Trying to track down various MSVC warnings that I'm getting, but I'm stuck
about what to do, for this one:
In win32, PIOHANDLE is typedef'ed as HANDLE.
In the windows API,
GetStdHandle returns a HANDLE, (used in io_win32)
open returns an int, (not used in parrot, but the MSDN examples show it us
