Re: Bounds checking in extension API
On Fri, 17 Oct 2003, Dan Sugalski wrote: On Fri, 17 Oct 2003, Simon Glover wrote: What, if any, validation of their input should the register access functions in the extension API do? Currently, they don't do any, which means that you can create a buffer overflow simply by using a register number 31 or 0; eg, Parrot_set_intreg(interpreter, 1, 100); reliably segfaults on my machine. Is it the responsibility of the extension writer to do this kind of bounds checking (in which case we need to make this extremely plain in the documentation), or should Parrot do this itself? This ought to be done by the extension API, though it was something I skimped on when I was throwing it together. OK, so what do we do in response to an out-of-bounds access? Throw a Parrot exception? Or indicate an error in some other fashion? Simon
Re: Bounds checking in extension API
On Fri, 17 Oct 2003, Simon Glover wrote: On Fri, 17 Oct 2003, Dan Sugalski wrote: On Fri, 17 Oct 2003, Simon Glover wrote: What, if any, validation of their input should the register access functions in the extension API do? Currently, they don't do any, which means that you can create a buffer overflow simply by using a register number 31 or 0; eg, Parrot_set_intreg(interpreter, 1, 100); reliably segfaults on my machine. Is it the responsibility of the extension writer to do this kind of bounds checking (in which case we need to make this extremely plain in the documentation), or should Parrot do this itself? This ought to be done by the extension API, though it was something I skimped on when I was throwing it together. OK, so what do we do in response to an out-of-bounds access? Throw a Parrot exception? Or indicate an error in some other fashion? Throw an exception. Which, I see, there isn't a facility to do from an extension. We need to fix that... Dan
Another extension API question
How do we create a Parrot_STRING in an extension? Parrot_Ints and Parrot_Floats are easy, since they're just declarations, and for PMCs there's Parrot_PMC_new, but there doesn't appear to be an equivalent for strings. Simon
Re: Another extension API question
On Fri, 17 Oct 2003, Simon Glover wrote: How do we create a Parrot_STRING in an extension? Parrot_Ints and Parrot_Floats are easy, since they're just declarations, and for PMCs there's Parrot_PMC_new, but there doesn't appear to be an equivalent for strings. We don't yet -- it's another spot the API's not been specified yet. I'm babysitting some long-running processes today, so I'll try and get some code put in. Dan
Re: Fixed opcode numbering infrastructure in
On Fri, 17 Oct 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote: 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. That's fine, basically. But there are some points, that we might consider: None of the numbers (well, OK, besides end) are fixed. I threw them in the file in alphabetic order and renumbered specifically to make sure the JIT broke good and proper. (Any renumbering broke the JIT, so I wanted to make sure that they didn't get overlooked) I don't much care what order they're in the final * Do this change later, when we have complete opcode support - a lot of e.g. string ops related to PMCs are just missing now. There is currently no urgent need, to have fix opcode numbers - we don't have Parrot 1.00 (or even 0.1.0). Missing ops aren't a big deal--any op that isn't in the list gets a number assigned to it, so there shouldn't be anything that needs to be done for new ops besides occasionally going through and sticking them in the ops file. *If* we renumber opcodes, then lib/Parrot/OpLib/core.pm should be sorted. This file is the base (and holds the numbering) of all utilities using ops. When this file is ordered to our needs, *no* other changes (and code duplication) in other utils is needed. For this reason, I reverted your patches to ops2c and jit2 - they are just in the wrong files. Put them *back*, please, unless you're going to fix core.pm. This is one of those cases where, like it or not, you get to deal with what I've done. If the numbering should go into core.pm, fine, but until core.pm returns explicit numbers (and nothing should be counting on the ordering from it) leave it where it is. We have exactly one magic opcode that is end. The other opcodes are *constant*. The noop is considered constant for hyterical reasons and as outlined in my summary to dynamic oplibs can be used for optimizations (replace some code with op_func_table[CORE_OPS_noop]). The Cwrapper__, Cprederef__, and Ccheck_events__ opcodes are constant too, because they are inserted for dynamic opcodes, prederefencing, and for event checking (which is not rediffed yet). There's no need for wrapper__--the proper op numbers should be inserted when the code is generated. I'll go dig, but I don't understand the reason for prederef__ since anything the deref core needs should be done at runtime. check_events__ is just another op and, once again, should just get thrown in as need be. Dan
Re: Fixed opcode numbering infrastructure in
On Fri, 17 Oct 2003, Juergen Boemmels wrote: Why not this way: Have a small number of _real_ core.ops which have fixed assigned numbers below say 256. This ops never change during the lifetime of parrot. All other libs are inited (not necessary loaded) at byte-code loadtime. The bytecode has a list of needed oplibs with the acompaning base offset. The ops of that oplib are added to core starting at base offset. Yep, that's the plan. (And has been for years, though it has been quite a while since the discussion came up last) Dan
Re: Fixed opcode numbering infrastructure in
At 08:55 AM 10/17/2003 -0400, Dan Sugalski wrote: On Fri, 17 Oct 2003, Juergen Boemmels wrote: Why not this way: Have a small number of _real_ core.ops which have fixed assigned numbers below say 256. This ops never change during the lifetime of parrot. All other libs are inited (not necessary loaded) at byte-code loadtime. The bytecode has a list of needed oplibs with the acompaning base offset. The ops of that oplib are added to core starting at base offset. Yep, that's the plan. (And has been for years, though it has been quite a while since the discussion came up last) I know we've had these discussions before but refresh my memory: I am confused between: a) Dynamic oplibs that are on-demand but always included in Parrot b) Dynamic oplibs that are add-ons and not included in Parrot I think (a) is a big win, especially for memory sensitive embedded platforms. (b) is a big lose. It invites people to spend time writing custom ops rather than reimplement their language in pure Parrot. (b) also muddies the water when you try to explain to someone why Parrot bytecodes are sorta portable. -Melvin
Re: Fixed opcode numbering infrastructure in
On Fri, 17 Oct 2003, Melvin Smith wrote: At 12:53 PM 10/17/2003 +0200, Juergen Boemmels wrote: Robert Spier [EMAIL PROTECTED] writes: 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)... Why is it hard? If we have a native interface and a well designed set of basic opcodes, what else do we need? My opinion on this has not changed in 2 years of Parrot. I see no benefit to writing a VM if we are going to allow all these added opcodes. There are three reasons, two technical and one political. The first, and perhaps least important (though we'll see with that) is to allow very low-overhead subs. The current calling conventions are fine, but there are going to be some time-critical cases that can't be rolled into a single sub invocation. Making it an op function cuts out a lot of the overhead. The second reason is the political one -- it gives language designers an out to modify the machine if they really need to do so. The third is a variant of sorts on the second--there are languages that are radically different from our core set that will likely be best served by having a different set of ops handy. Prolog and Haskell spring to mind and, while I don't know that they'll need a new set I can certainly see the possibility. Yes, it does mean that if library code written in ML (or whatever) uses the ML ops that you'll need the ML op pack, but that's fine. It's a bit more extreme than requiring an installed bytecode library, since hopefully we'll be able to avoid that for standalone executables, but its no more extreme than requiring a C library of one sort or another to be installed for a program to run. (While Parrot is going to reduce the need for C it won't eliminate it, and I don't see much difference between needing the PDL C extension and the ML op library for a program to run) Dan
Re: Fixed opcode numbering infrastructure in
On Fri, 17 Oct 2003, Melvin Smith wrote: At 08:55 AM 10/17/2003 -0400, Dan Sugalski wrote: On Fri, 17 Oct 2003, Juergen Boemmels wrote: Why not this way: Have a small number of _real_ core.ops which have fixed assigned numbers below say 256. This ops never change during the lifetime of parrot. All other libs are inited (not necessary loaded) at byte-code loadtime. The bytecode has a list of needed oplibs with the acompaning base offset. The ops of that oplib are added to core starting at base offset. Yep, that's the plan. (And has been for years, though it has been quite a while since the discussion came up last) I know we've had these discussions before but refresh my memory: I am confused between: a) Dynamic oplibs that are on-demand but always included in Parrot b) Dynamic oplibs that are add-ons and not included in Parrot The only difference is that opcodes in the a) set are in libraries on-disk that we build when we build parrot, and the ops in the b) set are in libraries on disk that we installed potentially after the fact. Which op libs are in which set depends on the distribution you're running. It's definitely possible that we'll ship an all-in-one distrib with a big set of optional ops, just as it's possible we'll ship a small one and you'll need to install one or more langauge-specific sets of ops after the fact. Dan
Re: Fixed opcode numbering infrastructure in
Juergen Boemmels [EMAIL PROTECTED] wrote: Have a small number of _real_ core.ops which have fixed assigned numbers below say 256. The problem with this approach is the JIT/EXEC subsystem. Dynamically loaded oplibs and JIT don't play together. To make this work, it would need probably a total rewrite of JIT code. The switched core has some overhead too, you can't expand a switch statement like the other table based opcode dispatches. Comments boe leo
Re: Fixed opcode numbering infrastructure in
Melvin Smith [EMAIL PROTECTED] wrote: I've asked this before: Please, someone give me an example where a dynamic opcode lib gives us something that a well designed set of core ops and an extension interface does not. Can you explain the difference? Dynamic opcode libraries are extensions to our core opcode set. Its debatable what shall be an opcode or better be a callable function. But opcodes are the primary execution parts of the VM. When speed matters, a piece of code is better a separate opcode then a function bound to some PMC. -Melvin leo
Re: Fixed opcode numbering infrastructure in
On Fri, 17 Oct 2003, Leopold Toetsch wrote: Juergen Boemmels [EMAIL PROTECTED] wrote: Have a small number of _real_ core.ops which have fixed assigned numbers below say 256. The problem with this approach is the JIT/EXEC subsystem. Dynamically loaded oplibs and JIT don't play together. To make this work, it would need probably a total rewrite of JIT code. The switched core has some overhead too, you can't expand a switch statement like the other table based opcode dispatches. The switched core's not that big a deal for this -- the default: case just does a lookup in the table and dispatch that way. Dan
[RFC] PIR changes coming
PIR next phase plans: (Note: I'd prefer to stay away from AST discussion here, I'm aware that we eventually wish to pass AST directly to IMCC, but I'd like to shelve that for a different thread) 1. .class, .field and .method directive support These will have to change the packfile format because we need to create the class layout and symbol table at assembly time. We can probably do this without designing the Class PMC yet, we'll just have to fake it with a Hash PMC. I'd rather have code like this: .class Foo .field f1 .field f2 .method Bar proto #body ... .endmethod # No body .nativemethod Baz noproto .endclass Than this: .sub _init $P0 = new Class $P0[:class] = TestClass store_global TestClass, $P0 # field $P0[i] = 0 # field $P0[s] = 0 $I0 = addr _TestClass__SampleMethod $P1 = new Sub $P1 = $I0 # method $P0[SampleMethod] = $P1 end .end #method Main .sub _TestClass__SampleMethod ... .end Now you tell me which you'd rather debug. :) Implicitly this creates all symbols for the class and at load time the correct PMCs will be created (Method PMCs for the methods, plain types or PMCs for the fields) and correct method addresses setup. This abstracts how we implement classes and objects into the IMCC compiler so we can change it without too much breakage to the high level languages. 2. Abstraction of subroutine call and return mechanisms based on compiler directives. I haven't completely figured out how this will look, but the general idea is, given the correct directive to .sub or .method, we should be able to hide all the details of the whole .pcc_call thing. This is less important than (1) but I think it is warranted. Leo and I already discussed this and we both think it is a good idea. Probably rather than .sub and .pcc_sub we combine both into .sub and provide directives like (proto, nonproto, parrotcall, fastcall) where parrotcall might be the standard continuation calling convention and the default for any .sub declared with no convention. I will most likely start on (1) very soon as I'm to the point with Cola that I need it and I don't like the hash code I'm currently emitting directly from the code generator to make classes and objects. My goal is to abstract enough so that PIR could be retargetted with little pain. -Melvin
Re: Fixed opcode numbering infrastructure in
Dan Sugalski [EMAIL PROTECTED] wrote: On Fri, 17 Oct 2003, Leopold Toetsch wrote: *If* we renumber opcodes, then lib/Parrot/OpLib/core.pm should be sorted. This file is the base (and holds the numbering) of all utilities using ops. When this file is ordered to our needs, *no* other changes (and code duplication) in other utils is needed. For this reason, I reverted your patches to ops2c and jit2 - they are just in the wrong files. Put them *back*, please, unless you're going to fix core.pm. I'll reorder core.pm (generation). Then jit2h (and other utils) aren't broken. This puts the renumbering in one place. Your approach was just wrong IMHO. If the numbering should go into core.pm, fine, but until core.pm returns explicit numbers (and nothing should be counting on the ordering from it) leave it where it is. core.pm is generated by ops2pm and is used by all utilities that deal with opcode libraries. So generating core.pm with the fixed numbering of ops.num seems to be by far the simplest approach and doesn't break all possible run cores. We have exactly one magic opcode that is end. The other opcodes are *constant*. There's no need for wrapper__--the proper op numbers should be inserted when the code is generated. When you run some code e.g. with the CGP core and you load an oplib, that doesn't have a CGP flavor - only functions, then the wrapper__ opcode inside the CGP core calls the dynamic opcode function of the dynamic oplib. Or when running -j: JIT emits a call to the wrapper__ op, that then executes the real function. The wrapper__ op might go away *if* we demand, that all oplibs are generated in all run core flavors, and *if* the oplib PMC is in the metadata, which depends on the freeze/thaw interface. For now the wrapper__ is needed and has to be a constant (well known) number. ... I'll go dig, but I don't understand the reason for prederef__ since anything the deref core needs should be done at runtime. The prederefed copy of the bytecode is filled with the prederef__ opcode. When executed, it calls do_prederef, which fills in the real function/opcode label/opcode number. Before this change, predereferncing was done in advance for CGP and switch core. This isn't possible any more because of dynamic oplibs. Predereferencing most be done just in time. ... check_events__ is just another op and, once again, should just get thrown in as need be. All these are plain ops, nothing special, except that their number is defined in oplib.h. If ops renumbering patches/generates this enum with matching opcode numbers all will continue to work. But as outlined for debugging its just simpler, to have some small numbers then 1227, so I'd prefer to have these ops (0-8) just in that order. Dan leo
Re: Fixed opcode numbering infrastructure in
At 02:49 PM 10/17/2003 +0200, Leopold Toetsch wrote: Melvin Smith [EMAIL PROTECTED] wrote: I've asked this before: Please, someone give me an example where a dynamic opcode lib gives us something that a well designed set of core ops and an extension interface does not. Can you explain the difference? Dynamic opcode libraries are extensions to our core opcode set. Its debatable what shall be an opcode or better be a callable function. But opcodes are the primary execution parts of the VM. When speed matters, a piece of code is better a separate opcode then a function bound to some PMC. I think we both know the difference. The ops are inlined, fast, cacheable and jitted. Extensions may not be. If an extension is pure Parrot, then it can also be jitted. The biggest overhead I see is when we have to fetch the routine through a PMC lookup, that is too slow. Here is the crux: This isn't a VM designed for raw speed. It is dynamic and symbolic, and optimized in the right places, but that does not mean we have to cut corners and make it messy. I can only see justification for extending the opcode set in the case of some weird language that has something Parrot doesn't support. In that case, I still say the proper thing to do is patch Parrot and include those ops in the standard distro. Maybe what we are really debating is: What do we include in the standard Parrot distribution. The fact that ops sit in separate libs doesn't bug me so much as the idea of lots of little oplibs sitting on CPAN. -Melvin
Re: Fixed opcode numbering infrastructure in
Leopold Toetsch [EMAIL PROTECTED] writes:
Juergen Boemmels [EMAIL PROTECTED] wrote:
Have a small number of _real_ core.ops which have fixed assigned
numbers below say 256.
The problem with this approach is the JIT/EXEC subsystem. Dynamically
loaded oplibs and JIT don't play together. To make this work, it would
need probably a total rewrite of JIT code.
I'm really no expert in the JIT system. But from my last step-thru
session in the debugger I remeber that build_asm calls out to a
function based on the opcode. Ah, here:
(op_func[cur_opcode_byte].fn) (jit_info, interpreter);
At build_asm time the oplib must already be loaded. The oplib must
then have funcions for JIT-emitting the code, otherwise it should just
emit calls to the slow core functions.
This means that the author of an oplib must also include a
JIT-emitting table (for all supported platforms). This raises the
level for writing oplibs, but the worst case is that the new oplib
under jit is as slow as the function-core (All ops call
functions). Ideally the JIT-emitting functions could be mechanically
created out of the *.ops files.
The switched core has some overhead too, you can't expand a switch
statement like the other table based opcode dispatches.
Thats definitly a problem.
But this can be solved by first finding out to which oplib a code
belongs (This can be done really fast by using bisection or something
similar). Then call the right switch function and stay in this
function as long as you are in this oplib.
Pseudocode:
while (next_op) {
if (op base || op base+num_ops) return
switch (op-base) {
...
}
}
As oplib-switches are slow it might be a good idea to include the core
ops to the switch function, so the core is always dispatched fast.
Comments
boe
leo
--
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Lexical Pads
On Oct 16, 2003, at 10:53 PM, Will Coleda wrote: I'm trying to write global for tcl, and trying to pull out a variable from the outermost pad, and failing to find it. Globals aren't stored in the lexical pads--there are find_global and store_global ops (see var.ops)--is that what you are looking for? JEff
Re: Fixed opcode numbering infrastructure in
Dan Sugalski [EMAIL PROTECTED] wrote: At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote: 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. That's fine, basically. But there are some points, that we might consider: * sort op numbers by usage, so that we have better code locality * sort ops by category. This could be useful to disable one block of ops (e.g. IO) for the safe core * leave them as they are *but* consider the numbers fixed - we add new ops only to one opsfile (e.g. new.ops), that get appended to core.pm, so that all other op numbers are fixed. * Do this change later, when we have complete opcode support - a lot of e.g. string ops related to PMCs are just missing now. There is currently no urgent need, to have fix opcode numbers - we don't have Parrot 1.00 (or even 0.1.0). *If* we renumber opcodes, then lib/Parrot/OpLib/core.pm should be sorted. This file is the base (and holds the numbering) of all utilities using ops. When this file is ordered to our needs, *no* other changes (and code duplication) in other utils is needed. For this reason, I reverted your patches to ops2c and jit2 - they are just in the wrong files. 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. We have exactly one magic opcode that is end. The other opcodes are *constant*. The noop is considered constant for hyterical reasons and as outlined in my summary to dynamic oplibs can be used for optimizations (replace some code with op_func_table[CORE_OPS_noop]). The Cwrapper__, Cprederef__, and Ccheck_events__ opcodes are constant too, because they are inserted for dynamic opcodes, prederefencing, and for event checking (which is not rediffed yet). I don't care, what opcode numbers these have, they are defined in an enum in oplib.h - but for debugging its by far simpler to seen an opcode number 6 (prederef__) then to have 1227. If they're needed now, then this is the time to make them not needed.. They are needed and will be needed and they are constant - not magic. 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. Yes, s. above, generate core.pm in the desired order. leo
Re: Fixed opcode numbering infrastructure in
Robert Spier [EMAIL PROTECTED] writes: 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.) Why not this way: Have a small number of _real_ core.ops which have fixed assigned numbers below say 256. This ops never change during the lifetime of parrot. All other libs are inited (not necessary loaded) at byte-code loadtime. The bytecode has a list of needed oplibs with the acompaning base offset. The ops of that oplib are added to core starting at base offset. This scheme is extendable: Oplibs can append new ops to the end. If a bytecode doesn't know anything about this new ops it will overwrite this ops with ops from another oplib. But thats not a problem because the bytecode does not need this new ops. Problems might be two independ bytecodes using different versions of the oplibs. Then you have either to renumber the bytecode or use two independent opcode-tables. We can for sure define a base-lib which has all whats now in core, which is loaded by default starting at 256. A typical bytecode which just uses the base-lib has no extra load cost, because the lib is already there. Comments boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: Fixed opcode numbering infrastructure in
At 12:53 PM 10/17/2003 +0200, Juergen Boemmels wrote: Robert Spier [EMAIL PROTECTED] writes: 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)... Why is it hard? If we have a native interface and a well designed set of basic opcodes, what else do we need? My opinion on this has not changed in 2 years of Parrot. I see no benefit to writing a VM if we are going to allow all these added opcodes. Only if the opcode libs are implemented in pure Parrot, where they can be packaged along with the bytecode file, do I see a real win for us, but even then, I can't understand why they should be ops rather than subs or such. I'm afraid we will just end up with the Perl5 situation where so many modules require C to build and install, and we are also making the VM more and more complex. I've asked this before: Please, someone give me an example where a dynamic opcode lib gives us something that a well designed set of core ops and an extension interface does not. Please also include in your example the semantics of packaging a portable bytecode. -Melvin
Re: Fixed opcode numbering infrastructure in
On Thu, 16 Oct 2003, Robert Spier wrote: 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)... Luckily, on second glance, it turns out to be neither. :) While new ops get added, old ones rarely, if ever, get removed. Perl 5's set has been stable, as has Python's, the JVM, the x86, Alpha, SPARC, and POWER's... since there's going to be a combination of dynamic oplibs that are going to have to be dynamically numbered anyway. (right?) Yes and no. Dynamic ops will go into slots, put in by name, with their number fixed at compile-time. We'd prefer to do this as little as possible for startup speed reasons, as it does slow down instantiating an interpreter. So why not treat the core oplib as dynamic? (With the exception of the handful that need to be fixed, like end.) Speed and complexity mainly. There's no win from the flexibility. Dan
Re: Fixed opcode numbering infrastructure in
Dan Sugalski [EMAIL PROTECTED] wrote: Put them *back*, please, unless you're going to fix core.pm. Done. op2pm.pl now has the renumbering. Its simpler and cleaner. Now, that 1237 opcodes are fixed numbered, shall we remove the finger-printing? Currently we just don't read PBCs, when the finger-print (generated from core.pm) doesn't match. Dan leo
Re: Fixed opcode numbering infrastructure in
On Fri, 17 Oct 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Put them *back*, please, unless you're going to fix core.pm. Done. op2pm.pl now has the renumbering. Its simpler and cleaner. Now, that 1237 opcodes are fixed numbered, shall we remove the finger-printing? Currently we just don't read PBCs, when the finger-print (generated from core.pm) doesn't match. We should keep the fingerprinting, since we can still have an issue where new bytecode can't run on old interpreters, but it's probably time to take another look at how we set the fingerprint. Dan
The Pumpking is dead, long live the Pumpking!
Hey folks. It's that time of year again, when the patch pumpkin passes paws. Hands, rather. Steve Fink now joins the ranks of Parrot Pumpkings Emeritus, having shepherded a number of releases out the door. We wish him a happy retirement and hope the nervous twitches stop soon. Replacing him as the pumking is the inimitable Leo Toetsch, so do please extend your sympathy^Wcongratulations to the newest volunteer for the post. Dan
Re: Fixed opcode numbering infrastructure in
Dan Sugalski [EMAIL PROTECTED] writes: On Fri, 17 Oct 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Put them *back*, please, unless you're going to fix core.pm. Done. op2pm.pl now has the renumbering. Its simpler and cleaner. Now, that 1237 opcodes are fixed numbered, shall we remove the finger-printing? Currently we just don't read PBCs, when the finger-print (generated from core.pm) doesn't match. We should keep the fingerprinting, since we can still have an issue where new bytecode can't run on old interpreters, but it's probably time to take another look at how we set the fingerprint. The fingerprint is an ugly hack: It builds an MD5-hash over the signatures and stores the first 10 bytes in the reserved slots of the parrot header. The reason why it was introduced was that the bytecode_numbers were floating, and each change led to hard to debug errors. When these opcodes are fixed now then the fingerprint should go out. If we want to keep the fingerprint it should be generated from the ops.num file, and it should be moved out of the header. The only reason I put it there was that by this time we used the nonextendable Version 0 bytecodeformat and had two independ ways of creating assembly (which is now dead). bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Bounds checking in extension API
What, if any, validation of their input should the register access functions in the extension API do? Currently, they don't do any, which means that you can create a buffer overflow simply by using a register number 31 or 0; eg, Parrot_set_intreg(interpreter, 1, 100); reliably segfaults on my machine. Is it the responsibility of the extension writer to do this kind of bounds checking (in which case we need to make this extremely plain in the documentation), or should Parrot do this itself? Simon
Re: Bounds checking in extension API
On Fri, 17 Oct 2003, Simon Glover wrote: What, if any, validation of their input should the register access functions in the extension API do? Currently, they don't do any, which means that you can create a buffer overflow simply by using a register number 31 or 0; eg, Parrot_set_intreg(interpreter, 1, 100); reliably segfaults on my machine. Is it the responsibility of the extension writer to do this kind of bounds checking (in which case we need to make this extremely plain in the documentation), or should Parrot do this itself? This ought to be done by the extension API, though it was something I skimped on when I was throwing it together. Dan
Re: The Pumpking is dead, long live the Pumpking!
Dan Sugalski wrote: Hey folks. It's that time of year again, when the patch pumpkin passes paws. Hands, rather. Steve Fink now joins the ranks of Parrot Pumpkings Emeritus, having shepherded a number of releases out the door. We wish him a happy retirement and hope the nervous twitches stop soon. Replacing him as the pumking is the inimitable Leo Toetsch, so do please extend your sympathy^Wcongratulations to the newest volunteer for the post. Dan . wow - 1st the PatchMonster, now the Pumpking. we watch in awe as the World Domination Plan unfolds. whats next, the WhiteHouse ? It would be a marked (tm) improvment..
Re: The Pumpking is dead, long live the Pumpking!
On Fri, 17 Oct 2003, Jim Cromie wrote: Dan Sugalski wrote: Hey folks. It's that time of year again, when the patch pumpkin passes paws. Hands, rather. Steve Fink now joins the ranks of Parrot Pumpkings Emeritus, having shepherded a number of releases out the door. We wish him a happy retirement and hope the nervous twitches stop soon. Replacing him as the pumking is the inimitable Leo Toetsch, so do please extend your sympathy^Wcongratulations to the newest volunteer for the post. wow - 1st the PatchMonster, now the Pumpking. we watch in awe as the World Domination Plan unfolds. whats next, the WhiteHouse ? It would be a marked (tm) improvment.. Are you sure you want to set a precedent for having an Austrian in the Whitehouse? Simon PS Steve: thanks for all of your hard work Leo: good luck!
[perl #24239] [PATCH] OpenBSD support
# New Ticket Created by Adam Thomason # Please include the string: [perl #24239] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24239 Two issues while building parrot on OpenBSD 3.3/i386: * arpa/inet.h doesn't include netinet/in.h (which defines struct in_addr) on its own. This sends up a wave a warnings about the incomplete type in function signatures. Moving the inclusion of netinet/in.h above arpa/inet.h in parrot.h fixes the problem for me, and doesn't seem to affect building on AIX or Gentoo. * pthread support requires both a ccflags option (-pthread) and a libs option (-lpthread). I've added config/init/hints/openbsd.pl to address this. Patch for both is attached. With it applied, the standard tests all pass and testj fails 5/924 subtests. I'll try to investigate the holdouts. -- Adam Thomason [EMAIL PROTECTED] -- attachment 1 -- url: http://rt.perl.org/rt2/attach/66165/49438/fa1e3b/openbsd.patch openbsd.patch Description: openbsd.patch
Re: The Pumpking is dead, long live the Pumpking!
On Fri, Oct 17, 2003 at 06:13:24PM -0600, Jim Cromie wrote: 1st the PatchMonster, now the Pumpking. we watch in awe as the World Domination Plan unfolds. whats next, the WhiteHouse ? Schwarzenegger, now Tötsch... there is a pattern here, but AEIOU is more ambitious than merely occupying the WhiteHouse. -- stef
Re: [perl #24239] [PATCH] OpenBSD support
On Fri, 17 Oct 2003, Adam Thomason wrote: # New Ticket Created by Adam Thomason # Please include the string: [perl #24239] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24239 Two issues while building parrot on OpenBSD 3.3/i386: * arpa/inet.h doesn't include netinet/in.h (which defines struct in_addr) on its own. This sends up a wave a warnings about the incomplete type in function signatures. Moving the inclusion of netinet/in.h above arpa/inet.h in parrot.h fixes the problem for me, and doesn't seem to affect building on AIX or Gentoo. * pthread support requires both a ccflags option (-pthread) and a libs option (-lpthread). I've added config/init/hints/openbsd.pl to address this. Patch for both is attached. With it applied, the standard tests all pass and testj fails 5/924 subtests. I'll try to investigate the holdouts. Thanks, applied. Simon
Re: Phalanx / CPANTS / Kwalitee
On Mon, Oct 13, 2003 at 10:28:29AM +0200, Thomas Klausner wrote: Obviously, this list is far from complete, which is why I request some feedback on more hints for Kwalitee from all of you! Something I'd be curious about: Modules with lower case names which aren't pragmas. (although how you determine this is hard) Nicholas Clark
Re: Phalanx / CPANTS / Kwalitee
Hi!
On Fri, Oct 17, 2003 at 10:09:04PM +0100, Nicholas Clark wrote:
Something I'd be curious about:
Modules with lower case names which aren't pragmas.
(although how you determine this is hard)
Well, here's a list of lowercase dist on CPAN (238 dists). Quite a lot of
those are in fact real distributions (eg. perl, parrot). In fact I think
that perl itself shouldn't be part of CPANTS
I've no clue on how to figure out if something is a pragmatic module (any
hints appreciated..)
abbreviation-0.02
again-0.02
autobless-1.0.1
autobox-0.06
base-2.01
base-Glob-0.01
bbobj-0.5.0
beancounter_0.6.2
bid
bignum-0.14
bioperl-0.05.1
bioperl-0.6.2
bioperl-0.7.0
bioperl-1.0
bioperl-1.0.2
bioperl-1.2
bioperl-1.2.1
bioperl-1.2.2
bioperl-db-0.1
bioperl-ext-0.6
bioperl-gui-0.7
bioperl-run-1.2.2
bitflags-0.10
capitalization-0.01
chronos-1.1.6.1
compatlib-1.2
conjury-1.004
coroutine0-0.02
csv2txt-2.0
ctflags-0.03
cvswebedit-v2.0b1
cyrillic-1.05
cyrillic-2.09
c_plus_plus-0.1
dapple-0.21
dateheader-1.0
dbd_rdb-1_16
dbMan-0.31
dbsh-0.01
ddb-1.3.1
deltax-modules-3.06
dTemplate-2.4
ebx-0.87
ec-1.25
enum-1.016
enum-fields-1.0
eperl-2.2.13
ePortal-3.2
esmith-1.70
eSTAR-RTML-1.7.0
etext.1.6.3
ex-constant-vars-0.01
ex-lib-zip-0.03
ex-newest-0.02
ex-override-1.1
examples
extensible_report_generator_1.13
extproc_perl-1.03
fameperl-2.1.3
finance-yahooquote_0.20
fldbm-0.01
font_ft2_0.1.0
forks-0.04
former-0.2beta
foundation-0.03
frogbak
gcrypt-0.3
gettext-1.00
gettext-1.01
glist-0.9.17a10
gmuck-1.07
grepmail-4.80
grepmail-5.10
grepmail-5.20
hp200lx-db-0.09
html2latex-1.1
htpl-3.14
http-headers-useragent-1.00
i2c-0.1
if-0.0101
import-1_01
interface-0.02
io-page-0.02
iodbc_ext_0_1
iPerl-0.6
jp_beta_1
kif-1.02
kif-2.01
lastlog.pm.gz
libao-perl_0.03-1
libapreq-1.2
libintl-perl-1.01
libnet-1.0703
libnet-1.16
libplot-perl-2.1.6.2b
libservlet-0.9.1
libservlet-0.9.2
libsirc-0.12
libwin32-0.191
libwww-perl-5.10
libwww-perl-5.53
libwww-perl-5.69
libxml-enno-1.02
libxml-perl-0.07
llg-1.07
load-0.05
log
loose-0.01
lot
makepp-1.19
mixin-0.04
mmds-1.902
modules-0.04
mod_perl-1.27
mod_perl-1.28
mqs-header-0.01
mqs-spool-0.03
mssql-1.008
namespace-0.05
new.spirit-2.0.26
new.spirit-2.1.19_beta
nsapi_perl-0.24
only-0.26
optimize-0.03
optimizer-0.05
parrot-0.0.10
parrot-0.0.3
parrot-0.0.4
parrot-0.0.5
parrot-0.0.8.1
parrot-0.0.9
parrot-0_0_7
payroll-0.4
pBLADE-0.10
pcsc-perl-1.0.8
pcsc-perl-1.2.2
pee-1.07
perl-5.6.1
perl-5.7.1
perl-5.7.2
perl-5.7.3
perl-5.8.0
perl-5.8.0-RC1
perl-5.8.0-RC2
perl-5.8.1-RC4
perl-GPS-0.12
perl-GPSData-0.02
perl-GPSData-0.04
perl-ldap-0.15
perl-ldap-0.251
perl-ldap-0.28
perl-ldap-0.29
perl-lisp-0.05
perl-vgalib-0.4
perl5-byacc-patches-0.6
perl5.00402-bindist04-msvcAlpha
perl5lib-1.02
perldap-1.4
perlhbm-0.01
perlindex-1.301
perlipq-1.25
perlmenu.v4.0
perlrpcgen-0.71a
perlSGML.1997Sep18
perl_archie.1.5
persist-0.3.2
persist-0.3.3
pgk_xs-0.05
pgsql_perl5-1.9.0
pod2lyx-0.25
podlators-1.27
poest-0.20030407
pop-0.07
ppt-0.12
pref.pm.gz
pRPC-modules-0.1005
psh-1.8
ptkFAQ-0_03
punctuation-0.02
pyperl-1.0
qtpl_perl-0.5
randompass-0.01
release-0.23
releasesystem-1.00
rlib-0.02
rms
router-lg-0.98a
rubyisms-1.0
savevars-0.07
sdf-2.001beta1
shishi-0.0.1
shufflestat-0.0.3
sitemapper-1.019
smg
smime-0.7
sol-inst-0.90a
sparky-public-1.06
speech_pm_1.0
spent-0.1
stem-0.10
strict-ModuleName-0.04
sub-curry-0.04
swig1.1p5
sybperl-2.15
tagged-0.1
tagged-0.40
tinyperl-1.0-580-win32
tkjuke-2.0.6
traceFunc-0.1
tux_perl-0.01
txt2html-2.03
types-0.05
typesafety-0.01
ubertext-0.95
uninit-1.00
uny2k-19.101
vague-1.3
variable-1.1
version-0.29
vm-1.0.1
vpopmail-0.08
vsDB-1.4.3
vstadaf-0.01
w3mir-1.0.10
web-1.44
webchat-0.05
webchat-0.64
wildproto-1.0.1
win-0.01
win32-guidgen-0.02
wing-0.9
xanton+xiri-0.63
xdbfdump-0.03
xisofs-1.3
xml-rax-0.01
xslt-parser-0.13
xxx2lout-1.35
your-0.01
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Phalanx / CPANTS / Kwalitee
Thomas Klausner wrote in perl.qa : Well, here's a list of lowercase dist on CPAN (238 dists). Quite a lot of those are in fact real distributions (eg. perl, parrot). In fact I think that perl itself shouldn't be part of CPANTS I've no clue on how to figure out if something is a pragmatic module (any hints appreciated..) You could check for the interface type field in the module list : 'p' means 'pragmatic'. You could also check if the distribution name matches a .pm file in the tarball. Oh, and the ex:: namespace is officially for experimental pragmas.
Re: Phalanx / CPANTS / Kwalitee
At 23:20 +0200 10/17/03, Thomas Klausner wrote: On Fri, Oct 17, 2003 at 10:09:04PM +0100, Nicholas Clark wrote: Something I'd be curious about: Modules with lower case names which aren't pragmas. (although how you determine this is hard) Well, here's a list of lowercase dist on CPAN (238 dists). Quite a lot of those are in fact real distributions (eg. perl, parrot). In fact I think that perl itself shouldn't be part of CPANTS I've no clue on how to figure out if something is a pragmatic module (any hints appreciated..) Hopefully this will be helpful forks-0.04 Maybe this should be integrated into threads.pm. If people think this is a good idea, please let me know. It's not a pragma, just as threads is not considerd to be a pragma (or is it?). load-0.05 I definitely intend this to be a pragma. As part of my plan for world domination, I would like to see this replace all AutoLoader.pm dependencies. So that you can control loading of modules externally: on demand for threaded applications, everything at once at mod_perl (pre-fork) startup time. Liz
Re: Phalanx / CPANTS / Kwalitee
Hi!
On Fri, Oct 17, 2003 at 09:42:21PM -, Rafael Garcia-Suarez wrote:
Thomas Klausner wrote in perl.qa :
Well, here's a list of lowercase dist on CPAN (238 dists). Quite a lot of
those are in fact real distributions (eg. perl, parrot). In fact I think
that perl itself shouldn't be part of CPANTS
I've no clue on how to figure out if something is a pragmatic module (any
hints appreciated..)
You could check for the interface type field in the module list : 'p'
means 'pragmatic'.
If the module list would be up to date that would be possible. But as it is
currently rather unmaintained (or is it not??), the module list is of little
help. Unfortunatly.
You could also check if the distribution name matches a .pm file
in the tarball.
Oh, and the ex:: namespace is officially for experimental pragmas.
thanks for the hints...
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
