Will Coleda [EMAIL PROTECTED] wrote:
This causes the example Makefile to be autogen'd.
Thanks, applied.
leo
Philip Taylor [EMAIL PROTECTED] wrote:
Some changes so that perl Configure.pl --cc=icl correctly uses
the Intel C++ Compiler under Windows:
With those changes, it all compiles and passes the tests (and still
works in MSVC).
Great.
Thanks, applied.
leo
Arthur Bergman wrote:
On 2 May 2004, at 12:37, Leopold Toetsch wrote:
Can't you call that somewhere in an outer frame? E.g. where you create
the interpreter.
No, because I might be creating the interpreter in a callback from the
application, and then access that interpreter in ANOTHER callback
Ron Blaschke [EMAIL PROTECTED] wrote:
Add required symbols for export.
libnci.def
Flush buffers to avoid unordered output (of stdout). Who is
responsible for flushing the buffers at the end of the nci call?
Should be defined.
Thanks, applied.
leo
On 3 May 2004, at 09:11, Leopold Toetsch wrote:
Arthur Bergman wrote:
On 2 May 2004, at 12:37, Leopold Toetsch wrote:
Can't you call that somewhere in an outer frame? E.g. where you
create
the interpreter.
No, because I might be creating the interpreter in a callback from
the application, and
Arthur Bergman [EMAIL PROTECTED] wrote:
... , then call into
parrot using for example void Parrot_runcode(Parrot_Interp, int argc,
char *argv[]); Now my argument is that currently this does not work
because the stacktop is not set! so what Parrot_runcode should do is in
{
On 3 May 2004, at 13:27, Leopold Toetsch wrote:
because the stacktop is not set! so what Parrot_runcode should do is
in
{
if(!parrot-stacktop) {
set_stacktop
When you call Capp_x_run_plugin from different locations, this
wouldn't work. So the correct sequence is:
app_x_run_plugin(...) {
Trying to build ponie on OS X I keep seeing this:
t/pmc/dumperok 8/13# Failed test (t/pmc/dumper.t at line 428)
# got: 'VAR1 = PerlHash Method 'createIndentpmcManagedStruct' not fo
und
# in file '(unknown file)' near line -1
# '
# expected: 'VAR1 = PerlHash {
#
Okay, here's the rules for PMCs that live outside parrot, and calling
into parrot from the outside.
1) *ALL* PMCs which are created outside parrot must be registered
(unless they're otherwise anchored)
2) No call into parrot from the outside needs to pass in a stack top
(though it may via a
On Apr 28, 2004, at 10:59 AM, Larry Wall wrote:
All in all, very well written.
Thanks.
I do, of course, have a few quibbles:
On Wed, Apr 28, 2004 at 04:22:07AM -0700, Jeff Clites wrote:
: As it turns out, people find it convenient to programmatically
represent a
: character by an integer (think
On Thu, Apr 22, 2004 at 08:59:37AM -0700, Brent 'Dax' Royal-Gordon wrote:
You're welcome to try it again, though...while you're at it, you might
as well make all internal Parrot functions take an Interp * instead of a
struct Parrot_Interp *. That ought to save us a couple kilobytes.
Wibble.
Okay, folks, our base ICU as we ship with parrot just flat-out
doesn't seem to work with cygwin, and it seems somewhat spotty with
basic windows.
The answer would seem to be Use a system installed ICU, so that
sounds like a good place to start. There's an install kit for Windows
at
At 4:00 PM +0200 5/2/04, Marcus Thiesen wrote:
it seems as if the ICU makefiles don't work that well with BSD style makes
like the one in OpenBSD core and NetBSD. As I'm no makefile expert it's quite
hard for me to fix this, don't know if it is possible in a platform
independent manner.
This is a
On Mon, 3 May 2004 11:25:30 -0400, Dan Sugalski wrote:
Okay, folks, our base ICU as we ship with parrot just flat-out
doesn't seem to work with cygwin, and it seems somewhat spotty with
basic windows.
Things get really messy with Visual Studio 2003.
The answer would seem to be Use a
On Mon, 2004-05-03 at 10:08, Ron Blaschke wrote:
BTW, current test results on win32 are:
Failed 1/102 test scripts, 99.02% okay. 3/1519 subtests failed, 99.80%
okay.
Failed Test Stat Wstat Total Fail Failed List of Failed
On Mon, 03 May 2004 10:32:33 -0700, Chromatic wrote:
BTW, current test results on win32 are:
Failed 1/102 test scripts, 99.02% okay. 3/1519 subtests failed, 99.80%
Can you run these outside of the harness and post the results? Here's
the command I'd use on Unix with the path separators
Dan Sugalski wrote:
Okay, folks, our base ICU as we ship with parrot just flat-out
doesn't seem to work with cygwin
I figured I would add my lessons learned here so that people don't have to
start from scratch.
ICU's static only implementation (Win32) has not been completed and likely
will
Dan Sugalski wrote:
3) The embedding wrapper is responsible for setting and resetting the
top of stack.
Proof-of-concept:
--- src/embed.c 2 May 2004 10:47:54 - 1.113
+++ src/embed.c 3 May 2004 19:08:23 -
@@ -666,6 +666,17 @@
void
Parrot_runcode(Interp *interpreter, int argc, char
Ron Blaschke wrote:
Did just that some time ago, but with version 2.8. It's as simple as
In case anyone was wondering - this doesn't work on Cygwin. It was among
the many things I have tried. It links but then coredumps when ./parrot
config_lib.pasm is executed. Oh, and using the latest
Leopold Toetsch [EMAIL PROTECTED] wrote:
3) Inspect the delegated method or MMD sub and save only the needed
register range.
Have this now running here locally and tested:
$ ./bench -b=^over
Numbers are relative to the first one. (lower is better)
p-j-Oc p-C-Oc perl-th perl
Ron Blaschke [EMAIL PROTECTED] wrote:
not ok 27 - nci_cb_C1
# Failed test (t/pmc/nci.t at line 857)
# got: 'ok 1
# ok 2
# cb didnt run
Ah. ok. Callbacks are currently scheduled into the event thread, which
isn't running on Win32. They shouldn't really get there, but put
directly
At 9:33 PM +0100 5/3/04, Nicholas Clark wrote:
On Mon, May 03, 2004 at 10:46:28AM -0400, Dan Sugalski wrote:
3) The embedding wrapper is responsible for setting and resetting the
top of stack.
I don't think that this is quite right. The embedding wrapper needs to
set (and reset) the top of stack
At 9:43 PM +0100 5/3/04, Nicholas Clark wrote:
On Mon, May 03, 2004 at 04:36:38PM -0400, Dan Sugalski wrote:
At 9:33 PM +0100 5/3/04, Nicholas Clark wrote:
On Mon, May 03, 2004 at 10:46:28AM -0400, Dan Sugalski wrote:
3) The embedding wrapper is responsible for setting and resetting the
On Fri, 30 Apr 2004 12:52:20 +0200, Leopold Toetsch wrote:
There is no 'official' Win32 maintainer. I'd be glad if I could add a
line to RESPONSIBLE_PARTIES.
Though I don't consider myself a Win32 maintainer (porter?), as I'm way too
inexperienced with Parrot, I'd sure like to work on it.
Is
On Apr 30, 2004, at 10:00 AM, Nicholas Clark wrote:
On Fri, Apr 30, 2004 at 06:25:50PM +0200, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
Prefixing all the linkable functions as Perl_ or PerlIO_ etc
Ugly. Can't the linker hide it?
Probably yes on most platforms, but the usual
On Mon, May 03, 2004 at 10:46:28AM -0400, Dan Sugalski wrote:
3) The embedding wrapper is responsible for setting and resetting the
top of stack.
I don't think that this is quite right. The embedding wrapper needs to
set (and reset) the top of stack only if it's not set.
Otherwise this
On Mon, May 03, 2004 at 04:36:38PM -0400, Dan Sugalski wrote:
At 9:33 PM +0100 5/3/04, Nicholas Clark wrote:
On Mon, May 03, 2004 at 10:46:28AM -0400, Dan Sugalski wrote:
3) The embedding wrapper is responsible for setting and resetting the
top of stack.
I don't think that this is quite
27 matches
Mail list logo
