Jeff Clites <[EMAIL PROTECTED]> wrote:
> ICU somehow manages (optionally?) to suffix all it its symbols with the
> version number, automagically (meaning, they don't look that way in the
> source or the headers).
urename.h is responsible for this. All the symbols get a version suffix.
> JEff
le
Ron Blaschke <[EMAIL PROTECTED]> wrote:
> Is there anything specific that is known to be broken/not yet implemented
> on Win32? Anything else I can help with?
Almost all implemented except: threads, events, signals, sockets :)
Seriously, I think, we first need an event model for Win32.
Parrot o
# New Ticket Created by chromatic
# Please include the string: [perl #29333]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=29333 >
>From Parrot, I'm trying to access a struct within a struct. Given an
SDL_Surface named
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
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 scen
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
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
Jeff Clites writes:
> On Apr 19, 2004, at 12:06 AM, Luke Palmer wrote:
>
> >Therefore, the first syntax can be redefined to evaluate the code block
> >and assign the result to $0.
>
> Would you ever want to leave $0 unaltered? That's the only concern
> which comes to mind.
Absoultely: if you wa
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 usua
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 19, 2004, at 12:06 AM, Luke Palmer wrote:
Therefore, the first syntax can be redefined to evaluate the code block
and assign the result to $0.
Would you ever want to leave $0 unaltered? That's the only concern
which comes to mind.
My argument for using this notation stems from the fact th
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
di
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 p
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 deve
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
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
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
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, 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 s
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 k
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 http://os
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.
Wibbl
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
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 sep
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
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 C from different locations, this
wouldn't work. So the correct sequence is:
app_x_run_plugin(...) {
void stk;
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
> {
> if(!parro
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 th
Luke Palmer writes:
> <{ get_rule() }># call an anonymous rule returned by the code block
>
> Can also be written:
>
> <$( get_rule() )>
>
> Therefore, the first syntax can be redefined to evaluate the code block
> and assign the result to $0. The example now becomes:
>
> rule
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
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 fr
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
Will Coleda <[EMAIL PROTECTED]> wrote:
> This causes the example Makefile to be autogen'd.
Thanks, applied.
leo
33 matches
Mail list logo
