wxWindows support?

2003-12-31 Thread David Cuny
Back in July, I asked if it was possible to interface Parrot with the 
wxWindows  (an open source, cross platform, native UI framework). The answer 
was (1) it could be done via NCI, but *ick*, and (2) custom PMCs plus object 
support might be a better route, but they hadn't been implemented yet.

Since that point, objects have been added to Parrot, and there's been a lot of 
progress on other things. I'm wondering if it's now possible to interface 
wxWindows to Parrot.

Thanks!

-- David Cuny



IMCC bug: newclass optimized away

2003-12-31 Thread Luke Palmer
Both newclass and addattrib are optimized away by the 'used_once'
optimization under -O2.  This is obviously incorrect, since they have
side-effects.

Luke


Re: Strangeness with '.sub' in macros

2003-12-31 Thread Leopold Toetsch
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> When a macro contains a '.sub' call, and that macro is used twice, then I get
> a 'memory error'.

Confirmed. The segfault is in expand_pcc_sub_call(), the "sub" SymReg is
NULL on the second expansion.

> How can I tell 'parrot' to dump a core file?

Tell your OS to dump core :)
$ man bash
/ulimit

$ ulimit -c 2

> CU, Bernhard

leo


Re: IMCC keyed crasher

2003-12-31 Thread Leopold Toetsch
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> IMCC bus errors (at least on OS X) when presented with the construct:

> set $P0[$I1], Params[$I1]

That's an unimplemented multi-keyed operation.

leo


Re: Problem during "make test"

2003-12-31 Thread Leopold Toetsch
Harry Jackson <[EMAIL PROTECTED]> wrote:

> It gets even stranger. If I do a make clean and make test again it does
> not necessarily stop in the same place each time ie.

Do you have a SMP machine with SMP enabled in your OS?
The unpredictable behavior of your freezes makes me think, that it could
be related to multi-threading. OTOH arithmetic tests or such don't
utilize threads and no events are being generated.

leo


Re: More calling convention stuff

2003-12-31 Thread Leopold Toetsch
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I've added a new op to the list, foldup, to make unprototyped calls
> (and some prototyped calls) a bit easier. The syntax is:

>foldup Px

Now, as there is a second (almost duplicate) incarnation, the
implementation should really be an external subroutine as opcodes code
is expanded into each run core.

The question is - into which C file does it fit best?

leo


Re: IMCC bug: newclass optimized away

2003-12-31 Thread Leopold Toetsch
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Both newclass and addattrib are optimized away by the 'used_once'
> optimization under -O2.  This is obviously incorrect, since they have
> side-effects.

Please don't use -O2 :) Its experimental and its not up to all changes.

> Luke

leo


Re: PMC registry

2003-12-31 Thread Leopold Toetsch
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>register Px
>unregister Px

Done. Its using a custom hash with the ref count being the value.

Tests wanted :)

leo


Shared arena threads, GC, executable memory allocator

2003-12-31 Thread Leopold Toetsch
As already outlined the current copying GC isn't really thread-safe. A 
possible solution is to suspend all threads, while the shared 
interpreter is running garbage collection.

A shared-all thread type could use the same scheme, instead of 
explicitely declare a PMC to be shared, all is shared implicitely and is 
living in the shared interpreters arena_base.

OTOH the copying collector has disadvantages for the unthreaded case too 
(e.g. hash buckets can get moved during string_compare). We already have 
a non-moving GC system selectable at configure time. But when the 
external LEA allocator is used, memory allocation isn't thread safe. 
Libc's allocator is based on ptmalloc[1] - an early offspring of the LEA 
allocator, but ptmalloc isn't portable.

We can use the underlaying C-library as our allocator, but there are 
AFAIK speed issues on some systems.

And finally: Recent issues with fedora and non-executable JIT code also 
show a demand for an allocator inside parrot.

Writing a full-fledged allocator isn't trivial. Following the glossary 
and bibliography links from e.g. [2] may keep you reading for a while :)

Having an own allocator would have another advantage: We can pass hints 
to the allocator about the usage of the memory block. Executable code 
for JIT is long-living and unlikely to be resized. String buffers used 
e.g. in string_append, freeze, or Parrot_sprintf are very likely of 
having a short life-time and being subject to resizing.

leo

[1] http://www.malloc.de
[2] http://www.memorymanagement.org


Re: More calling convention stuff

2003-12-31 Thread Dan Sugalski
At 11:51 AM +0100 12/31/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
 I've added a new op to the list, foldup, to make unprototyped calls
 (and some prototyped calls) a bit easier. The syntax is:

foldup Px
Now, as there is a second (almost duplicate) incarnation, the
implementation should really be an external subroutine as opcodes code
is expanded into each run core.
The question is - into which C file does it fit best?
It's probably a misc.c or util.c thing. Seems the right place for it.
--
Dan
--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk


More Windows dev questions: Core dumps

2003-12-31 Thread Dan Sugalski
Or something much like them.

On a Unix system, a core dump is a file with a raw (mostly) copy of a 
process' current memory image that's written whenever a process does 
something profoundly illegal, like accessing an inaccessible section 
of memory with no trap handler that allows recovery or something of 
the sort. They're handy, because it means you can go and debug a 
process after the fact, and don't have to be there on the spot to 
figure out what's going on. Really handy for things that die 
overnight, or when you're not around, and you don't want the defunct 
process hanging around until you can attach to it with a debugger.

Does Windows do this? (I know other OSes, like VMS, do *not* do it) 
If so, how do I enable it? If not, I presume there's some reasonably 
simple way to attach a debugger to a process that's died. (I hope)

No, I'm not getting turned into a windows programmer, but until I get 
the Gameboy port of parrot going (or someone slides me an Alpha or 
Itanium VMS box) it's the only non-Unix platform I've got handy to 
work with.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk


Re: pdd16

2003-12-31 Thread Dan Sugalski
At 10:19 PM -0500 12/30/03, Dan Sugalski wrote:
At 2:28 AM + 12/31/03, Harry Jackson wrote:
I might be going mad here and maybe I have been up too long but, does:

http://dev.x.perl.org/perl6/pdd/pdd16_native_call.html

have two identical Parrot_callback_C and Parrot_callback_D function 
signatures.
Possibly, though they're supposed to have their parameters reversed. 
I'll go fix as soon as I can.
Yeah, it was definitely wrong. I've a checkin pending reasonable CVS access.
--
Dan
--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk


Fwd: Pie-thon benchmark code ready

2003-12-31 Thread Dan Sugalski
Delivered-To: [EMAIL PROTECTED]
To: Dan Sugalski <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: Pie-thon benchmark code ready
From: Guido van Rossum <[EMAIL PROTECTED]>
Date: Wed, 31 Dec 2003 09:54:15 -0800
While it's still 2003 in most of the US and Europe (and happy new year
to the folks in Asia, Australia and New Zealand! :-), I present the
official Pie-thon Parrot Benchmark:
  ftp://ftp.python.org/pub/python/parrotbench/parrotbench.tgz

I'll quote from the README.txt file:

"""
This is a benchmark to be run in front of a live audience at OSCON
2004 between Python and Parrot.  The bytecode must be Python 2.3
bytecode frozen in December 2003 (which is almost over as I write this
:-).
For some more background, see the python-dev thread around
  http://mail.python.org/pipermail/python-dev/2003-December/040977.html
The benchmark here is intended to make Dan Sugalski's life difficult:
there are some standard benchmark thingies (simple random algorithms
using basic data types) but also a lot of play with odd corners of the
language definition, and Python's extremely dynamic object model:
funky descriptors, mutable classes, that sort of thing.  The benchmark
is supposed to run with either Python 2.3 or Python 2.4.
[...]

On timing: there's a requirement that the benchmark runs for at least
30 seconds.  It currently runs for nearly a minute on my home box,
which is a four-year-old 650 MHz Pentium box.  If the contest hardware
is so fast that it runs under a minute, there's a number in b.py that
can be cranked up to increase the number of runs.  (It takes 27
seconds on my recent work desktop, and on my screaming IBM T40 laptop
it runs in 15 seconds, so I suspect that we should at least double the
number of runs from 2 to 4.)
"""
I'd be happy to answer any questions.  Let the competition begin!

--Guido van Rossum (home page: http://www.python.org/~guido/)


--
Dan
--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk


Re: More Windows dev questions: Core dumps

2003-12-31 Thread Vladimir Lipsky
From: "Dan Sugalski" <[EMAIL PROTECTED]>

> On a Unix system, a core dump is a file with a raw (mostly) copy of a
> process' current memory image that's written whenever a process does
> something profoundly illegal, like accessing an inaccessible section
> of memory with no trap handler that allows recovery or something of
> the sort. They're handy, because it means you can go and debug a
> process after the fact, and don't have to be there on the spot to
> figure out what's going on. Really handy for things that die
> overnight, or when you're not around, and you don't want the defunct
> process hanging around until you can attach to it with a debugger.
>
> Does Windows do this? (I know other OSes, like VMS, do *not* do it)

No, Windows does not use core files. If you run your code outside of a
debugger and a problem occurs you will be given the option of either
debugging the code or killing the executing process.

> If so, how do I enable it? If not, I presume there's some reasonably
> simple way to attach a debugger to a process that's died. (I hope)

Yeah. That's it. A debugger. Do you have one? If no, try to pull WinDbg
about.

http://www.microsoft.com/whdc/ddk/debugging/default.mspx?gssnb=1

It's free for downloading. You will find some "HOW TO" there either.

> No, I'm not getting turned into a windows programmer, but until I get

It's a pity that you ain't =)

>  Dan

0x4C56



Re: More Windows dev questions: Core dumps

2003-12-31 Thread Dan Sugalski
At 11:51 PM +0300 12/31/03, Vladimir Lipsky wrote:
From: "Dan Sugalski" <[EMAIL PROTECTED]>

 On a Unix system, a core dump is a file with a raw (mostly) copy of a
 process' current memory image that's written whenever a process does
 something profoundly illegal, like accessing an inaccessible section
 of memory with no trap handler that allows recovery or something of
 the sort. They're handy, because it means you can go and debug a
 process after the fact, and don't have to be there on the spot to
 figure out what's going on. Really handy for things that die
 overnight, or when you're not around, and you don't want the defunct
 process hanging around until you can attach to it with a debugger.
 Does Windows do this? (I know other OSes, like VMS, do *not* do it)
No, Windows does not use core files. If you run your code outside of a
debugger and a problem occurs you will be given the option of either
debugging the code or killing the executing process.
Bummer. Ah, well, one of the few Unix development things that I really like.

 > If so, how do I enable it? If not, I presume there's some reasonably
 simple way to attach a debugger to a process that's died. (I hope)
Yeah. That's it. A debugger. Do you have one? If no, try to pull WinDbg
about.
http://www.microsoft.com/whdc/ddk/debugging/default.mspx?gssnb=1

It's free for downloading. You will find some "HOW TO" there either.
I've probably got that installed already with the VS/.NET kit, but if 
not I'll go get it. Thanks.

 > No, I'm not getting turned into a windows programmer, but until I get

It's a pity that you ain't =)
I've too many systems stuck in my brain as it is--between VMS, 
various Unices, OS X userland,  RSTS/E, remnants of the much lamented 
Amiga, and bits of the Gameboy Advance, there's not much space left. 
It's a wonder I can find my car keys in the morning. :)
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk


Re: More Windows dev questions: Core dumps

2003-12-31 Thread Vladimir Lipsky


0x4C56
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "Vladimir Lipsky" <[EMAIL PROTECTED]>
Cc: "perl6-internals" <[EMAIL PROTECTED]>
Sent: Wednesday, December 31, 2003 10:49 PM
Subject: Re: More Windows dev questions: Core dumps


> At 11:51 PM +0300 12/31/03, Vladimir Lipsky wrote:
> >From: "Dan Sugalski" <[EMAIL PROTECTED]>
> >
> >>  On a Unix system, a core dump is a file with a raw (mostly) copy of a
> >>  process' current memory image that's written whenever a process does
> >>  something profoundly illegal, like accessing an inaccessible section
> >>  of memory with no trap handler that allows recovery or something of
> >>  the sort. They're handy, because it means you can go and debug a
> >>  process after the fact, and don't have to be there on the spot to
> >>  figure out what's going on. Really handy for things that die
> >>  overnight, or when you're not around, and you don't want the defunct
> >>  process hanging around until you can attach to it with a debugger.
> >>
> >>  Does Windows do this? (I know other OSes, like VMS, do *not* do it)
> >
> >No, Windows does not use core files. If you run your code outside of a
> >debugger and a problem occurs you will be given the option of either
> >debugging the code or killing the executing process.
>
> Bummer. Ah, well, one of the few Unix development things that I really
like.

Well, debug prompts not that bad. Still better than nothing.

> >  > If so, how do I enable it? If not, I presume there's some reasonably
> >>  simple way to attach a debugger to a process that's died. (I hope)
> >
> >Yeah. That's it. A debugger. Do you have one? If no, try to pull WinDbg
> >about.
> >
> >http://www.microsoft.com/whdc/ddk/debugging/default.mspx?gssnb=1
> >
> >It's free for downloading. You will find some "HOW TO" there either.
>
> I've probably got that installed already with the VS/.NET kit, but if

Oh! Then you might have got it. I read somewhere that one can do a crash
dump, an windows equivalent of unix core dumpes, with windbg. So if you
wish, you could look for how to create that thing in docs.

>  Dan

0x4C56



Object system

2003-12-31 Thread Luke Palmer
Since I'm working on a compiler that requires objects, and seeing as how
we have a python compiler now hanging over our heads, what work is
necessary to finish up the object system?

I notice that ParrotObject only has [get|set]_integer_keyed.  I assume
we intend to make those for the rest of the data types.

Also, in order to support anonymous classes, I'd like the method table
to be in the class object itself, as opposed to in mangled globals.  Is
this also something I could tackle?

What else could I do?

Thanks,
Luke


[OT] inc year

2003-12-31 Thread Leopold Toetsch
I'd like to wish all of you a
  not too much threaded,
  object oriented,
warning free compilation of the New Year with
  all garbage collected in the bin and everything
  operating in contiguous memory with healthy caches.
leo