Re: [perl #22864] [PATCH] Move ParrotIO to PMCs

2003-07-04 Thread Leopold Toetsch
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:

> to:
>mark roots from interpreter
>follow marked but previously unfollowed pmcs
>mark pmcs on system stack
>follow marked but previously unfollowed pmcs

> But considering the potential benefit for debugging, it might be worth
> it.

That scheme would work, yes. But it doesn't help much to solve the
problem.

Despite Dan's "we always do stack walking", I still think, we don't need
to trace the system areas when we:
1) immediately anchor newly created objects
2) or turn off DOD, where 1) isn't really possible

leo


Re: Lazy Arrays

2003-07-04 Thread Leopold Toetsch
Luke Palmer <[EMAIL PROTECTED]> wrote:

> First, do these work well as pmcs, or should it be integrated with
> PerlArray (I hope not)?

It should subclass PerlArray. I think you don't need LazySequence. You
can just set the exceptions to the lazy sequence in the PerlArray
subclass.
Array/PerlArray can hold values for e.g.:

  @a[0..1000, 1_000_000_000..1_000_001_000]

without growing to 1e9*x bytes.

>  Should Infinity be a pmc?

Probably yes.

> Any ideas on how these things should be set up at the assembly level?
> I was thinking either:

Have a look at the initializer in list.c:list_new_init() or
classes/array.c:init_pmc() and the docs of init_pmc in pdd02.

> Finally, what should things like:

> set $I0, $P0# $P0 contains 1..Inf

> Because integer registers can't well store infinity...

Through an exception.

> Thanks,
> Luke

leo


Lexical Pads (was: [perl #22767] ...)

2003-07-04 Thread Leopold Toetsch
Dan Sugalski <[EMAIL PROTECTED]> wrote:

> Pads shouldn't really be stacks, they should be plain linked lists.

A plain linked list is lacking the chunk allocation scheme. I'm not sure
if allocating a buffer_like and Parrot_allocate the memory for the pads
is better, then the current stack based implementation.

But I still don't know, how control stack, exception objects located
there, and scopes are playing together.

> Pads and namespaces are singly-linked lists, which we need to deal
> with separately.

WRT namespaces: pdd06 has named global tables and indexed access for
globals in such a table. This is similar to the indexed access in
lexical pads. The implementation of both is totally different though.

First we should know, if $HL is likely to access lexicals/globals by
name or by index or mixed ...
Then such a pad or namespace table probably should be a separate PMC
class with a hash and an array inside. So manipulation of these could be
done with normal opcodes + some special shortcut ops for common
operations.

leo


Re: [perl #22873] gentoo ebuild ... problem..

2003-07-04 Thread Leopold Toetsch
Leon Brocard <[EMAIL PROTECTED]> wrote:

> Thanks for the bug report. I've patched parrot in CVS to use perldoc
> -U.

Unknown option: U
perldoc [options] PageName|ModuleName|ProgramName...

(perldoc is very likely from 5.005; version 1.14)

leo


Re: [perl #22873] gentoo ebuild ... problem..

2003-07-04 Thread Leon Brocard
Leopold Toetsch sent the following bits through the ether:

> Unknown option: U
> perldoc [options] PageName|ModuleName|ProgramName...
> 
> (perldoc is very likely from 5.005; version 1.14)

I was a little hasty with the previous patch, sorry. I blame perldoc's
man page for not sorting options alphabetically.

I've reverted -U back to -u.

We'll need to check the perldoc version and if it's a recent one with
the annoying "Superuser must not run /usr/bin/perldoc without security
audit and taint checks." message then run it with -U as well as -u.

Apologies, Leon

ps and I was so proud of my first CVS commit too :-(
-- 
Leon Brocard.http://www.astray.com/
scribot.http://www.scribot.com/

... 668 - Neighbor of the Beast


Re: Tentative [PATCH]: valclone

2003-07-04 Thread Dan Sugalski
At 9:13 AM +0200 7/2/03, K Stol wrote:
In Perl this is possible (because of the syntax of Perl). But what 
about languages in which it cannot be expressed?
I know, Parrot is mainly for Perl, but not *only* for Perl. Wouldn't 
it be nice to have Parrot supporting this?
Yup, it would. Parrot's assuming pass-by-reference for reference 
types (Strings and PMCs) and pass-by-value for value types (ints and 
nums). I'm tempted to leave it like that so there's a level of 
constancy there, and let the languages that want to take parameters 
in by value rather than reference make a copy of what's passed in.

Real reference types, the way objects are traditionally handled, 
won't change in this sort of scheme (as we'd just copy the reference) 
but that's normally the way things are supposed to happen.

This, of course, brings up the question of who gets to decide whether 
things are passed by value or reference, the caller or callee, so I'm 
up for discussion on that.

  - Original Message -
  From: Gordon Henriksen
  To: K Stol
  Cc: [EMAIL PROTECTED]
  Sent: Wednesday, July 02, 2003 6:12 AM
  Subject: Re: Tentative [PATCH]: valclone
  Shouldn't Perl make this determination at compile time based upon 
the subroutine's signature? Doesn't seem to me that it is in any way 
a decision for the assembler.


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


Re: wxWindows Support

2003-07-04 Thread Dan Sugalski
At 7:08 AM -0700 7/4/03, David wrote:
There was a recent mention on the wxWindows* list that pairing it with Parrot
would be a good combination. Is there any interest in supporting wxWindows in
Parrot?
On the one hand, I don't particularly care to bless a windowing 
toolkit, since they all have cross-platform issues (either 
functionally or in appearance) but I have no problem at all if 
someone wants to build a Parrot interface to one of the kits and 
putting it in an extended library distribution.

-- David Cuny

*: For those not familiar with it, wxWindows (http://www.wxwindows.org) is an
open source, cross-platform native UI framework for Windows, Unix/GTK+,
Unix/Motif and X11, MacOS, MGL and OS/2.  It also provides network
programming, streams, clipboard and drag and drop, multithreading, image
loading and saving in a variety of popular formats, database support, etc.
Sorry for sounding like an advertisement; I'm cutting and pasting off the
website.
And yes, there is a wxPerl (http://wxperl.sourceforge.net/).


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


get__keyed_int

2003-07-04 Thread Leopold Toetsch
I alread did ask some time ago:
Is there any compelling reason that *_keyed_int vtables like:
PMC* get_pmc_keyed_int (INTVAL* key)

take a pointer to the key?
This needs then (in all ops files, incl JIT):
  INTVAL key = $3;
$1 = $2->vtable->get_pmc_keyed_int(interpreter, $2, &key);
(setting up a local and passing the address of it)

Just passing the integer key would be shorter and faster.
leo


wxWindows Support / Interfacing libraries with Parrot

2003-07-04 Thread Christian Renz
Actually, I was the one mentioning it in a completely offhand remark
in some discussion about the future of wxWindows ;-).
I'm not looking for official endorsement of wxWindows as "the"
GUI toolkit for Parrot -- TIMTOWTDI -- but it sure would be sweet to
have, and definitely would not hurt Parrot-based application
development :). 

When starting to think about this, I asked myself what library
interfacing with Parrot would look like. My first thought was to have
a Perl 6 interface for wxWindows, but then it ocurred to me that it
would be more clever to have all the interface classes in Parrot; this
way, _any_ language using Parrot could use the wxWindows classes. Is
this correct? Are there already tools to do the interfacing (á la
Swig) or does it need to be done by hand?
Greetings,
  Christian
--
[EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/
"One of the problems with Java is that they swept a bit too much of the
innate complexity of life under the carpet of the libraries. And so
now they've had to replace the carpets several times."  -- Larry Wall


Fw: Re: [ANNOUNCE] Parrot is feature-frozen until Wednesday

2003-07-04 Thread Clinton Pierce
Whoops.  Needed to go to the list as well.

> Original Message-
> From: "Clinton Pierce" <[EMAIL PROTECTED]>
> To: "Dan Sugalski" <[EMAIL PROTECTED]>
> Date: Fri, Jul-4-2003 4:24 PM
> Subject: Re: [ANNOUNCE] Parrot is feature-frozen until Wednesday
> 
> > It crashes rather badly in a number of spots on OS X, unfortunately. 
> > I've also noticed that we have no Win32 systems in the tinderbox. Are 
> > we building OK on Win32 anywhere?
> 
> I don't have a stable/spare Win32 box to donate as tinder... but.
> 
> Win32 build seems okay as of last night.  One eye-catching error at the end of the 
> build is:
> 
> link -out:imcc.exe -nologo -nodefaultlib -release-machine:x86 
> imcparser.obj imcl
> exer.obj imc.obj stacks.obj symreg.obj  instructions.obj cfg.obj sets.obj debug.obj  
> optimiz
> er.obj pbc.obj main.obj parser_util.obj jit.obj ../../blib/lib/libparrot_s.lib 
> oldnames.lib
> kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib 
> ole32.l
> ib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib 
> odbc32.lib o
> dbccp32.lib msvcrt.lib
> # the chmod doesn't work here, so move imcc and make it again :-(
> '#' is not recognized as an internal or external command,
> operable program or batch file.
> NMAKE : fatal error U1077: '#' : return code '0x1'
> Stop.
> 
> But everything else *looks* okay.
> 
> Some tests fail though.  The summary is:
> 
> Failed Test  Status Wstat Total Fail  Failed  List of Failed
> 
> t/op/stacks.t  2   512432   4.65%  3, 6
> t/pmc/intlist.t1   256 91  11.11%  6
> t/pmc/io.t 2   512 42  50.00%  3-4
> t/pmc/nci.t4  1024104  40.00%  2, 6, 8, 10
> t/src/manifest.t   3   768 43  75.00%  2-4
> t/src/sprintf.t1   256 21  50.00%  2
> 10 subtests skipped.
> Failed 6/49 test scripts, 87.76% okay. 13/751 subtests failed, 98.27% okay.
> NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff'
> Stop.
> 
> Given today's off-and-on power situation in Southeast Michigan, I have no tuits 
> round or otherwise to dive in futher.
> 
> 



[perl #22877] GC/Sweep errors in latest build

2003-07-04 Thread Clinton A. Pierce
# New Ticket Created by  "Clinton A. Pierce" 
# Please include the string:  [perl #22877]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=22877 >


This bug did not make itself known in a 6/23 checkout, and appeared sometime in the 
last week (I've only now synched my copy with CVS).

I don't have a small test case for this.  I apologize.  To reproduce the bug:

checkout and build latest parrot tree
$ cd languages/BASIC/compiler
$ cat > test.bas
dim a$()
for i = 0 to 100 step .5
for j = 1 to 30
a$(j)=" "
next j
for j = 1 to 30
print " ";
next j
print i
next i
^D
$ perl compile.pl test.bas
$ ../../imcc/imcc TARG_test.imc

And the apparent symptom is the loop counter (i) only goes up to 2 -- it should have 
gone to 100, by steps of 0.5.   If I alter the BASIC program in any way the bug gets 
delayed a little further or never happens at all.  

Hacking a "sweepoff" and "collectoff" into the PIR (TARG_test.imc) before anything 
else happens makes the bug go away.  I don't think this is a BASIC bug, nor do I think 
it's a register allocation/spilling problem in IMCC.

Placing traces in the PIR code causes the bug to move around also.  Usually only 
delaying the onset of the bug.






Re: wxWindows Support / Interfacing libraries with Parrot

2003-07-04 Thread Christian Renz
GUI toolkit for Parrot -- TIMTOWTDI -- but it sure would be sweet to
have, and definitely would not hurt Parrot-based application
Whoops. Just to clarify: It would be sweet to have an interface for
wxWindows in Parrot -- not the official endorsement.
And let me try to formulate a nice and clear question:

What is the easiest way to make a monster like wxWindows (in terms of
classes) available for Parrot?
(Or would it be easier to write a Parrot backend for gcc? ;-))

--
[EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/
"A man can no more diminish God's glory by refusing to worship Him than
a lunatic can put out the sun by scribbling the word 'darkness' on
the walls of his cell."  -- C.S. Lewis


Re: Tentative [PATCH]: valclone

2003-07-04 Thread K Stol
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
To: "K Stol" <[EMAIL PROTECTED]>; "Gordon Henriksen" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, July 04, 2003 4:56 PM
Subject: Re: Tentative [PATCH]: valclone


> At 9:13 AM +0200 7/2/03, K Stol wrote:
> >In Perl this is possible (because of the syntax of Perl). But what
> >about languages in which it cannot be expressed?
> >I know, Parrot is mainly for Perl, but not *only* for Perl. Wouldn't
> >it be nice to have Parrot supporting this?
>
> Yup, it would. Parrot's assuming pass-by-reference for reference
> types (Strings and PMCs) and pass-by-value for value types (ints and
> nums). I'm tempted to leave it like that so there's a level of
> constancy there, and let the languages that want to take parameters
> in by value rather than reference make a copy of what's passed in.
>
So, you agree it would be nice for Parrot to have an option to pass PMCs
(and maybe strings as well) by value, as well as the standard by reference,
right? If so, there should be some *fast* way of doing this (of course, this
is already possible using the current instructions, but it should be
*fast*), so maybe a special instruction for that?

> Real reference types, the way objects are traditionally handled,
> won't change in this sort of scheme (as we'd just copy the reference)
> but that's normally the way things are supposed to happen.
>
> This, of course, brings up the question of who gets to decide whether
> things are passed by value or reference, the caller or callee, so I'm
> up for discussion on that.
Well, this is my try...

Good point. At first I didn't really think this through too well. My first
idea was this:
The callee copies the passed-in PMCs, so the callee would be responsible. In
this case, the caller isn't really sure if the passed-in PMCs are still
valid after the function call: the called function could have changed them,
or even destroyed them (if the callee was compiled to handle the params. by
reference) (But this really isn't an issue, because the compiler will emit
the right instructions, but it's just a thought).

On the other hand, it would be quite ok if the callee doesn't really care
which PMCs it receives, it just does its job (and it doesn't really care if
the args are copies or the 'original' PMCs), and it depends on the compiler
for emitting the right code (so it will spit out by-value instructions). (so
the caller is responsible).

Would there be a performance difference? I think not, but I could well be
wrong (anybody?).

klaas-jan


Re: wxWindows Support / Interfacing libraries with Parrot

2003-07-04 Thread Leopold Toetsch
Christian Renz wrote:


What is the easiest way to make a monster like wxWindows (in terms of
classes) available for Parrot?
The easiest way isn't avaialble yet. That is custom dynamically loaded 
PMCs (classes) representing some functionality. Alreay working is the 
NCI (Native call interface) to call arbitrary C functions in some shared 
libs (modulo some struct handling and such, but e.g ncurses.so is 
running). Setting up required struct's from PASM isn't yet. As wxWindows 
is object oriented it would for sure better plug in Parrot's OO scheme, 
which is almost, hmm, well, ready ... (DAN) ...


(Or would it be easier to write a Parrot backend for gcc? ;-))
Why the smilies ;-) Parrot is a fine processor well suited for an 
optimizing compiler and with a reasonable architecture. Its not the 
first time that I'm thinking of such a hack.

... though it would need some extensions at both sides. 

Are some gcc people listening?

leo





Re: [perl #22877] GC/Sweep errors in latest build

2003-07-04 Thread Leopold Toetsch
Clinton A. Pierce (via RT) wrote:

I don't have a small test case for this.  
Please read some threads about IO & such after my post:

Subject: Timely destruction and TRACE_SYSTEM_AREAS
Date: Thu, 26 Jun 2003 09:59:18 +0200
If your are sure, that you are on a different kind of bug, then I'll 
have a closer look.

For now its just unsolved and a *bug*.

leo







Re: Tentative [PATCH]: valclone

2003-07-04 Thread Leopold Toetsch
K Stol <[EMAIL PROTECTED]> wrote:
> - Original Message -
> From: "Dan Sugalski" <[EMAIL PROTECTED]>
>>
>> This, of course, brings up the question of who gets to decide whether
>> things are passed by value or reference, the caller or callee, so I'm
>> up for discussion on that.

> The callee copies the passed-in PMCs, so the callee would be responsible. In
> this case, the caller isn't really sure if the passed-in PMCs are still
> valid after the function call:

If we are inside one language, that is all up to the compiler. You don't
have that at subroutine calls only, but on each assignment statement:

  set P0, P1
  set I0, I1

are very different instructions.
This is a compiler problem to emit a correct sequence of
set/assign/clone or something.

The real fun comes, when one language calls a sub/method of another one.
The proposed intermediate param class can't help here. Its a matter of
interface definitions - and that is fixed (IMHO) by the function
providing the interface or functionality

> klaas-jan

leo


Re: [perl #22877] GC/Sweep errors in latest build

2003-07-04 Thread Clinton Pierce
> > I don't have a small test case for this.  
> 
> Please read some threads about IO & such after my post:
> 
> Subject: Timely destruction and TRACE_SYSTEM_AREAS
> Date: Thu, 26 Jun 2003 09:59:18 +0200
> 
> If your are sure, that you are on a different kind of bug, then I'll 
> have a closer look.
> 
> For now its just unsolved and a *bug*.

I'm *sure* this is something else, and it reared its ugly head only in the last week.  
 



Re: Tentative [PATCH]: valclone

2003-07-04 Thread Gordon Henriksen
On Friday, July 4, 2003, at 10:56 , Dan Sugalski wrote:

This, of course, brings up the question of who gets to decide whether 
things are passed by value or reference, the caller or callee, so I'm 
up for discussion on that.
Isn't this again a function of the routine's signature? The callee ought 
to indicate whether it wishes a reference or not, and the caller in turn 
must be bound to conform to that contract. So my answer to this question 
would be that both are responsible for conforming to the signature 
dictated by the called routine. Admittedly not in keeping with Perl 5 
(aliased @_), but in keeping with the Apocalypses: Perl 6 arguments will 
be passed by value unless is rw is specified, meaning that the prototype 
must be examined, either at run- or compile-time, in order to make the 
decision.

The alternative: Pass all parameters by reference all the time and have 
the callee make copies when it wants a by-value parameter. Optimizer 
hell. Probably bad for locality of reference. Potentially good for 
performance if the average argument is larger than a pointer type, 
though.

—

Gordon Henriksen
[EMAIL PROTECTED]