Re: The Block Returns
On Thu, Oct 16, 2003 at 01:46:30AM +0100, Simon Cozens wrote: [EMAIL PROTECTED] (Larry Wall) writes: But for the time being I'm tied to an IV pole We got rid of those; they're PMC poles now. Get well soon, Ditto! Dave. -- Little fly, thy summer's play my thoughtless hand has terminated with extreme prejudice. (with apologies to William Blake)
Re: Help me please
Stefan Lidman [EMAIL PROTECTED] writes: Shannon Francis [EMAIL PROTECTED] writes: [...] Oh dear. Asking a mailing list to do your homework for you is bad enough. Asking a mailing list that has recently been quiet enough to elicit jokes about it in the summaries is, well, we'll have to see what sort of mood I'm in when I write the next one won't we? Hmm, a joke about p6l-SUBS. I wonder when that was :-) Ooh yes. Good point. So far under the radar there haven't been any posts to it since I started summarizing. =head2 Meanwhile, in perl6-language-subs perl6-language-subs? Whassat then?
RE: Phalanx / CPANTS / Kwalitee
On 16 October 2003 05:47 Robert Spier wrote: Yes. We've been thinking about this. It either needs stealing buildd from Debian, having a box we don't mind destroying every so often, or having a VMware virtual machine we can undo easily. What we need is more free time ;-) User Mode Linux (limiting to Linux, of course) might be a lighter weight way to do this. Would this cope with Win32, MacOS or other OS specific modules? Barbie.
Re: Perl Core Tests
On Thu, Oct 16, 2003 at 11:12:53AM -0700, chromatic wrote: On Thu, 2003-10-16 at 10:46, Ovid wrote: I was browsing through the Perl core tests and I saw that some tests in the t/uni/ directory used Test::More, but most other tests would explicitly 'print ok 1\n'. Is this to reduce the dependancy of the core tests on external modules (and if so, why does t/uni/ not follow the convention) or have they simply not been converted? Stuff in t/op mostly can't use Test or Test::More because those modules rely on the features being tested. Most everything else can use Test::More. Barring any Unicode-related fiascos (of which I am proudly and blissfully unaware), they probably haven't been converted yet. See perlhack for details. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I'm not actually Kevin Lenzo, but I play him on TV.
Re: Help me please
On Thu, Oct 16, 2003 at 09:37:52AM +0100, Piers Cawley wrote: Stefan Lidman [EMAIL PROTECTED] writes: Shannon Francis [EMAIL PROTECTED] writes: [...] Oh dear. Asking a mailing list to do your homework for you is bad enough. Asking a mailing list that has recently been quiet enough to elicit jokes about it in the summaries is, well, we'll have to see what sort of mood I'm in when I write the next one won't we? Hmm, a joke about p6l-SUBS. I wonder when that was :-) Ooh yes. Good point. So far under the radar there haven't been any posts to it since I started summarizing. Then you obviously missed this very important thread: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00326.html I did wonder why it never made the summary. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: Help me please
Paul Johnson wrote: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00326.html I did wonder why it never made the summary. On the bright side, all of these recent discussion has finally given me reason to setup a procmail filter to sort out this list.
Perl Core Tests
I was browsing through the Perl core tests and I saw that some tests in the t/uni/ directory used Test::More, but most other tests would explicitly 'print ok 1\n'. Is this to reduce the dependancy of the core tests on external modules (and if so, why does t/uni/ not follow the convention) or have they simply not been converted? Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Perl Core Tests
On Thu, 2003-10-16 at 10:46, Ovid wrote: I was browsing through the Perl core tests and I saw that some tests in the t/uni/ directory used Test::More, but most other tests would explicitly 'print ok 1\n'. Is this to reduce the dependancy of the core tests on external modules (and if so, why does t/uni/ not follow the convention) or have they simply not been converted? Stuff in t/op mostly can't use Test or Test::More because those modules rely on the features being tested. Most everything else can use Test::More. Barring any Unicode-related fiascos (of which I am proudly and blissfully unaware), they probably haven't been converted yet. My goal was to improve coverage so every piece had at least nominal tests that could be improved, not to improve every existing test. Other people have had different goals. (It feels pretty good to port the tests to a more maintainable framework.) -- c
Re: Perl Core Tests
Chromatic wrote in perl.qa : Stuff in t/op mostly can't use Test or Test::More because those modules rely on the features being tested. Most everything else can use Test::More. Barring any Unicode-related fiascos (of which I am proudly and blissfully unaware), they probably haven't been converted yet. t/test.pl is intended to be a lightweight replacement for Test::* for op/ tests. My goal was to improve coverage so every piece had at least nominal tests that could be improved, not to improve every existing test. Other people have had different goals. (It feels pretty good to port the tests to a more maintainable framework.) One improvement is to add names to tests. It makes them damn easier to track down when they fail.
Re: Fixed opcode numbering infrastructure in
At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Folks, I've added in the infrastructure needed to implement fixed opcode numbers. There's now a file ops.num that holds the opcode name/number pairs for all ops with a fixed number. I don't know yet, what are the goals of this patch. There is not any sign in the list, that ops should be numbered like that and so on ... The goals are to assign permanent numbers to the opcodes. What the numbers are is generally irrelevant, but they must be constant across all systems for the lifetime of parrot. Second, you for sure did ignore all comments in core.ops and my summaries, how various things are *working* now. No, I didn't. All I did was run through the generated output and strip out values, making sure that end was 0. There really shouldn't be any other magic numbers for opcodes, though I see there are some. I can understand the noop code, though I don't see much reason to make it a magic number. The rest I'm not seeing any need for magic numbers--certainly not for the event checking ops, nor for the wrapper op. If they're needed now, then this is the time to make them not needed.. This patch breaks all predereferenced cores as well as dynamic opcode libraries at first sight. And the JIT, yes. (Though I was unaware the prederef cores broke) That's fine. Fixing them is simple enough to do. If you don't have really *very* strong arguments for this patch then please just undo it - now - thanks. I do. It needs doing, and it needs doing now, before we make more changes to the runloops, to make sure things aren't more difficult to fix later. If it's just a matter of changing a few op numbers in the ops.num file, then that's fine--this is the time to change them. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Dynamic oplibs - intermediate summary
On Thu, Oct 16, 2003 at 05:40:30PM +0200, Leopold Toetsch wrote: As JIT code is unrolled, it IMHO can only call the function core (or CGP again) for loaded opcodes. As is this would mean that the JIT can't JIT any opcodes that are brought in by dynamically loaded classes, it would be pain for any heavy users of custom classes. Would it be beneficial (and feasible) to either provide a mechanism (flag on the command line, flag in the bytecode, whatever parrot treats treats a perl-level pragma as, etc, not sure) to either a: disable the JIT until the main program starts (running on CG or some other low startup cost core until then) or b: signal a (partial) re-JIT of something/everything after a library/ everything has loaded? I've no idea how easy this might be. Or sensible. Nicholas Clark
Re: Dynamic oplibs - intermediate summary
On Thu, 16 Oct 2003, Nicholas Clark wrote: On Thu, Oct 16, 2003 at 05:40:30PM +0200, Leopold Toetsch wrote: As JIT code is unrolled, it IMHO can only call the function core (or CGP again) for loaded opcodes. As is this would mean that the JIT can't JIT any opcodes that are brought in by dynamically loaded classes, it would be pain for any heavy users of custom classes. This should only be temporary. If the right information is tagged in the opcode library, then the JIT should be able to JIT the loaded ops (since we do, after all, have to have the library loaded when we enter the segment of code that uses the new ops. I don't mind just in time loading, but I figure we ought to do it more than one or two ops before we execute the new code. :) Dan
Re: [perl #24224] [PATCH] IMCC: Macros are handled via hash
Leopold Toetsch [EMAIL PROTECTED] writes: JüRgen BöMmels [EMAIL PROTECTED] wrote: There are still some things to do: - a global hash is still not totally right. It should be moved to the interpreter structure As Dan already outlined, macros should have some limited scope, probably per file. So currently the hash has to be cleared like the other (still) global strutures. Yes, it should be per-file scope. But the generated flex lexer has some more global state variables like yyin and yytext. Reworking the whole imcc global stuff isn't finished yet. Various structures have to be separated and kept per sub and or file. All of these should then be in IMCC_INFO hanging off from the interpreter structure. The IMCC_INFO does not need to be part of the interpreter. Anyway, I don't like to have a HASH and parrot Strings inside the lexer (when not really needed) just to manage macros. Currently a hash like that for SymRegs is just fine. It will be replaced by a still simple but expandable hash finally. Ok, granted. Parrot-Strings might be a little heavy. But introducing yet another hash implementation does not seem right to me either. It would be nice if both the PerlHash.pmc and the macro hash could use the same base implementation and use callbacks for the details. But on the other hand malloc/free and gc-memory have so diffrent requirements. bye boe
Re: Instantiating objects
On Wed, 15 Oct 2003, Jeff Clites wrote: My brain was in PMC == class mode when I wrote what I wrote above, but now I need to rethink, since that's not a given (yet?). Not a given ever. PMCs may have a backing namespace, and that namespace may be a HLL class, but it might not. The terminology (PMC classes vs HLL classes) is definitely confusing, and unfortunate. We probably ought to have a renaming before we go live. Dan
Objects
Okay, it's pretty obvious I need to rethink things a bit for objects. (I'd have responded to everyone in turn, but I lost power last night and the mail came in this morning in odd order) I'll get back to everyone on this later on today. Dan
Re: [perl #24224] [PATCH] IMCC: Macros are handled via hash
Juergen Boemmels [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: The IMCC_INFO does not need to be part of the interpreter. I don't like to have global state variables around. I don't know yet, what happens if 2 interpreter threads both do eval()... It will be replaced by a still simple but expandable hash finally. Ok, granted. Parrot-Strings might be a little heavy. But introducing yet another hash implementation does not seem right to me either. We need for sure a hash with plain cstrings as keys too. The code in hash.c seems rather heavy (and slow) to me, callbacks would slow down it additionally. bye boe leo
Re: [perl #24224] [PATCH] IMCC: Macros are handled via hash
On Thu, 16 Oct 2003, Leopold Toetsch wrote: Juergen Boemmels [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: The IMCC_INFO does not need to be part of the interpreter. I don't like to have global state variables around. I don't know yet, what happens if 2 interpreter threads both do eval()... If it's per-interpreter, nothing, since each thread should have its own intepreter. (Though I can see some potential deadlock issues, though that's not specific to this) It will be replaced by a still simple but expandable hash finally. Ok, granted. Parrot-Strings might be a little heavy. But introducing yet another hash implementation does not seem right to me either. We need for sure a hash with plain cstrings as keys too. The code in hash.c seems rather heavy (and slow) to me, callbacks would slow down it additionally. It should all be black-box--if the code in hash.c is nasty, it can certainly be rewritten. (Though I'd keep in mind the need for a random seed in the hash, and Unicode makes hashing somewhat interesting) Dan
Re: [perl #24224] [PATCH] IMCC: Macros are handled via hash
At 10:21 AM 10/16/2003 -0400, Dan Sugalski wrote: On Thu, 16 Oct 2003, Leopold Toetsch wrote: Juergen Boemmels [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: The IMCC_INFO does not need to be part of the interpreter. I don't like to have global state variables around. I don't know yet, what happens if 2 interpreter threads both do eval()... If it's per-interpreter, nothing, since each thread should have its own intepreter. (Though I can see some potential deadlock issues, though that's not specific to this) I don't like the idea of IMCC becoming so tightly coupled with the interpreter. I still wish to be able to build it standalone. Hopefully we can keep this in mind going forward. -Melvin
Dynamic oplibs - intermediate summary
Now all run cores[2] are able to execute dynoplibs/test.pasm [1]. This is currently done for all cores except the function (slow) core by running the wrapper__ opcode, which calls the real function in the parrot function core. Cores with an address table for function dispatch (CGoto, CGP) get a new address table, where all new entries are pointing to the wrapper__ opcode. CGP does use this address table only once when the opcode is predereferenced. The switch core calls the wrapper from the default case statement. JIT emits a call to the wrapper function. Next will be to try to find and load oplibs of the flavor of the currently running core. If a program is run with the -C (CGP) core, the dynop_register function will try to find the ..._cgp_ops_load symbol in the current dynamic oplib or in a separate file. If this is successful, the opcode dispatch can use these opcodes directly. The switch core will need some dispatch helpers (probably via next function pointers containing loaded switch_cores. JIT is different. As JIT code is unrolled, it IMHO can only call the function core (or CGP again) for loaded opcodes. When run from a source file, the Cloadlib opcode is executed immediately, so that the assembler can generate the bytecode with these new opcodes. At runtime the loadlib finds the library already loaded and does nothing (it could even be replaced by Cnoops if its known, that the program is to be run directly). When a PBC is generated, and the code is run from that, now the Cloadlib is honored, when it is executed. So when there are multiple loadlibs and these are not executed in the correct sequence, you'll get nice crashes. This will be replaced (as Dan did lay out) by putting the library PMCs into the metadata, so that library loading happens before program startup and in the desired sequence. Comments welcome, leo [1] $ cat dynoplibs/test.pasm ... loadlib P1, myops_ops ... fortytwo I0 print I0 what_do_you_get_if_you_multiply_six_by_nine S0 ... $ make shared export LD_LIBRARY_PATH=.:blib/lib $ make -C dynoplibs clean all make -C dynclasses make libnci.so $ parrot -j dynoplibs/test.pasm in test loaded myops_ops loaded foo loaded libnci found 3 libs Ops runtime/parrot/dynext/myops_ops.so PMC runtime/parrot/dynext/foo.so NCI libnci.so the answer is: 42 aka fortytwo [2] *if* platform supports dynamic loading of course. I didn't look at EXEC, but as it does use JIT for building its code, it could work too.
Re: [perl #24224] [PATCH] IMCC: Macros are handled via hash
Melvin Smith [EMAIL PROTECTED] wrote: I don't like the idea of IMCC becoming so tightly coupled with the interpreter. I still wish to be able to build it standalone. Hopefully we can keep this in mind going forward. IMCC_INFO is a macro, easily changable. But building it standalone would need some additional defines for PBC building and and the compiler callbacks. Anyway, why would you want to build it w/o parrot? The imcc files are supposed to move down one directory soon. There is no imcc$(EXE) anymore. Your baby evolved - its parrot :) -Melvin leo
Fixed opcode numbering infrastructure in
Folks, I've added in the infrastructure needed to implement fixed opcode numbers. There's now a file ops.num that holds the opcode name/number pairs for all ops with a fixed number. Right now it's only got two entries (one of which really ought to be redone) but I'd like to get all the extant standard ops in there. ops2c.pl has been adjusted to number appropriately, and all tests pass. Note that I have *not* adjusted the JIT's numbering of the opcodes, and the JIT currently fails with the ops.num file that's checked in. Once it works right (don't touch ops.num until then!), and volunteers are welcome, we can fill the file in right and be done with it. Dan
Re: [perl #24224] [PATCH] IMCC: Macros are handled via hash
On Oct 16, 2003, at 7:21 AM, Dan Sugalski wrote: On Thu, 16 Oct 2003, Leopold Toetsch wrote: Juergen Boemmels [EMAIL PROTECTED] wrote: Leopold Toetsch [EMAIL PROTECTED] writes: The IMCC_INFO does not need to be part of the interpreter. I don't like to have global state variables around. I don't know yet, what happens if 2 interpreter threads both do eval()... If it's per-interpreter, nothing, since each thread should have its own intepreter. (Though I can see some potential deadlock issues, though that's not specific to this) The lex-generated stuff that Juergen mentioned could be more of a problem, since it seems to store its state in globals (yytext, etc.), and that might be pretty tricky to fix. I've always worried about the apparent lack of thread-safety of such generated lexers/parsers when I've run across them before, and wondered why they don't pass around a context structure instead. (I suppose the tools are old enough that they may actually pre-date threading as a widespread concept) JEff
isa query
What should this code print? newclass P1, Foo instantiate P2, P1 isa I0, P2, Foo print I0 print \n end How about this? newclass P1, Foo instantiate P2, P1 isa I0, P2, ParrotObject print I0 print \n end (NB Both will segfault without the fix I just checked in for parrotobject.pmc, as the PMC wasn't being initialized properly due to a typo). Simon
mmd_dispatch_numval
From mmd.pod: =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num) Like Cmmd_dispatch_string, only it returns a FLOATVAL. Wouldn't it be more sensible to call the function mmd_dispatch_floatval ? Simon
Re: mmd_dispatch_numval
On Thu, 16 Oct 2003, Simon Glover wrote: From mmd.pod: =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num) Like Cmmd_dispatch_string, only it returns a FLOATVAL. Wouldn't it be more sensible to call the function mmd_dispatch_floatval ? Yep. The terminology's mixed in a number of places--we should probably go fix it everywhere and be done with it. (Unless I'm just behind the times and its already been done :) Dan
Re: mmd_dispatch_numval
On Thu, 16 Oct 2003, Dan Sugalski wrote: On Thu, 16 Oct 2003, Simon Glover wrote: From mmd.pod: =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num) Like Cmmd_dispatch_string, only it returns a FLOATVAL. Wouldn't it be more sensible to call the function mmd_dispatch_floatval ? Yep. The terminology's mixed in a number of places--we should probably go fix it everywhere and be done with it. (Unless I'm just behind the times and its already been done :) OK, I've changed it over to mmd_dispatch_floatval in mmd.c, mmd.h and mmd.pod; as far as I can tell, it's not yet being used anywhere else. Simon
Re: mmd_dispatch_numval
On Oct 16, 2003, at 2:40 PM, Simon Glover wrote: On Thu, 16 Oct 2003, Dan Sugalski wrote: On Thu, 16 Oct 2003, Simon Glover wrote: From mmd.pod: =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num) Like Cmmd_dispatch_string, only it returns a FLOATVAL. Wouldn't it be more sensible to call the function mmd_dispatch_floatval ? Yep. The terminology's mixed in a number of places--we should probably go fix it everywhere and be done with it. (Unless I'm just behind the times and its already been done :) OK, I've changed it over to mmd_dispatch_floatval in mmd.c, mmd.h and mmd.pod; as far as I can tell, it's not yet being used anywhere else. Although I think float is clearer than number (in that it's clearly different than integer), it might be easier to go with number--since we have set_number vtable methods, and N registers rather than F registers JEff
Re: mmd_dispatch_numval
On Thu, 16 Oct 2003, Jeff Clites wrote: On Oct 16, 2003, at 2:40 PM, Simon Glover wrote: On Thu, 16 Oct 2003, Dan Sugalski wrote: On Thu, 16 Oct 2003, Simon Glover wrote: From mmd.pod: =item FLOATVAL mmd_dispatch_numval(interp, left, right, func_num) Like Cmmd_dispatch_string, only it returns a FLOATVAL. Wouldn't it be more sensible to call the function mmd_dispatch_floatval ? Yep. The terminology's mixed in a number of places--we should probably go fix it everywhere and be done with it. (Unless I'm just behind the times and its already been done :) OK, I've changed it over to mmd_dispatch_floatval in mmd.c, mmd.h and mmd.pod; as far as I can tell, it's not yet being used anywhere else. Although I think float is clearer than number (in that it's clearly different than integer), it might be easier to go with number--since we have set_number vtable methods, and N registers rather than F registers Ah, but we currently use floatval and FLOATVAL in a lot more places than we do numval or NUMVAL (or number). Simon
Re: Fixed opcode numbering infrastructure in
Dan Sugalski [EMAIL PROTECTED] wrote: Folks, I've added in the infrastructure needed to implement fixed opcode numbers. There's now a file ops.num that holds the opcode name/number pairs for all ops with a fixed number. I don't know yet, what are the goals of this patch. There is not any sign in the list, that ops should be numbered like that and so on ... WTF Second, you for sure did ignore all comments in core.ops and my summaries, how various things are *working* now. This patch breaks all predereferenced cores as well as dynamic opcode libraries at first sight. If you don't have really *very* strong arguments for this patch then please just undo it - now - thanks. Dan leo
Re: Dynamic oplibs - intermediate summary
Nicholas Clark [EMAIL PROTECTED] wrote: On Thu, Oct 16, 2003 at 05:40:30PM +0200, Leopold Toetsch wrote: As JIT code is unrolled, it IMHO can only call the function core (or CGP again) for loaded opcodes. As is this would mean that the JIT can't JIT any opcodes that are brought in by dynamically loaded classes, it would be pain for any heavy users of custom classes. [ snip ] First - no pain. CGP and JIT rutimes are equally fast with PMC related code. JIT only shines with natural int loops doing int and float arithmetics. When it comes to HLL there is no difference in performance - both cores just do function calls. Second - as said the JIT core does unroll opcodes, that is each JITted assembly representation of any opcode is repeated in the execution stream of the JITted instructions. While any other core branches around in a fixed set of opcodes, the JIT runtime has a sequence of assembly instructions representing these opcodes. Now when you load such opcodes dynamically, there is no means to insert these into the current CPU instructions - there is no hardware CPU representaion for loaded ops (if there is any, the opcode would be in core, because it is important) Nicholas Clark leo
Lexical Pads
Can someone explain to me the lexical pad stack and static nesting depth? I'm trying to write global for tcl, and trying to pull out a variable from the outermost pad, and failing to find it. - I'm fairly certain this is because I'm abusing new_pad and store_lex (always using 0 as the static nesting depth). Works fine when all I care about is the current pad - but getting to variables elsewhere in the pad stack results in a lexical not found error. Do I need to manually keep track of my nesting depth? If so, what's the rationale? (why have the stack if you also have the nesting depth?) Heading off to experiment... -- Will Coke Coledawill at coleda dot com
Re: Fixed opcode numbering infrastructure in
The goals are to assign permanent numbers to the opcodes. What the numbers are is generally irrelevant, but they must be constant across all systems for the lifetime of parrot. At first glance, gut reaction, that seems really hard(tm) and really limiting(tm)... since there's going to be a combination of dynamic oplibs that are going to have to be dynamically numbered anyway. (right?) So why not treat the core oplib as dynamic? (With the exception of the handful that need to be fixed, like end.) -R
