Re: [perl #22864] [PATCH] Move ParrotIO to PMCs
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
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] ...)
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..
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..
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
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
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
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
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
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
# 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
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
- 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
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
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
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
> > 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
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]