Re: [perl #60044] [BUG?] rethrow just throwing?
On Fri, 24 Oct 2008, Allison Randal wrote: Will Coleda wrote: Allison Randal wrote: ...you expect 'rethrow' to keep the stack trace of the original 'die'? Yes. The way to do this is to add stack trace information to the Exception's 'stacktrace' attribute when the exception is first thrown, and print that out for an unhandled exception, instead of printing out the literal current path of execution. (This is why I added the 'stacktrace' attribute.) What about keeping track of where the exception was originally created? If we have lazy exceptions, then knowing where the fault they represent was detected is probably more important than were (exactly) it was triggered. Or does this all amount to the same thing? Is an exception only lazy because there's an enclosing dynamic scope that catches it and transmogrifies it into an Uncaught Exception? Or if not, could we have both back-traces available? A created_by back-trace and a thrown_by back-trace? -Martin
Re: Parrot-14347 Patches to get Parrot to build on VMS VAX
Leo wrote: I wrote: Bear with me on the VMSish filenames; xxx;1 is the original version, xxx; is the patched version of the file. I wrote a small perl helper, dealing with that. But what about filenames like: +++ lib/parrot.configure/step.pm; which actually is: +++ lib/Parrot/Configure/Step.pm As I said: bear with me. The filenames looked like [lib.Parrot.Configure]Step.pm originally, and I tried to make things easier for a *ix diff by unixifying them. Obviously I failed miserably... ;-) I now have an original source tree at the side of my devel directory, so I can diff -urdN the whole thing. This makes things interesting another way, though, because the files' capitalization is lost that way. sigh Please disregard the patch posted, as (it contained a bug and) I've done some more work last night. I now have a version that runs through Configure.pl without errors. The settings generated look sound, and the generated makefiles don't look too bad [1], but are not yet totally MMS-clean. I'll come back with a patch (against the latest SVN revision, of course) when it's good enough to be published. That said, it was a relatively painless port so far. Thanks to all who wrote the configuration scripts with portability in mind. cu, Martin [1] for a make/MMS comparison, please see http://vms.pdv-systeme.de/users/martinv/VMS_Programming_FAQ.html#4.1. (and yes, the trailing dot is part of the URL) -- | Martin Vorlaender | OpenVMS rules! VMS is today what | work: [EMAIL PROTECTED] Microsoft wants| http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: [EMAIL PROTECTED]
Parrot-14347 Patches to get Parrot to build on VMS VAX
Hi, at YAPC::EU vaxman.de bugged me to try and build Parrot on VMS. As all I had with me was an emulated VAX on my WinXP notebook (running VMS 7.3 and DEC C 6.0), I used that. First I needed some time to build/test perl 5.8.8, but I think I have it running now. Then I set out to Configure.pl Parrot... Please see my findings in the attached patch file. I'm sure config/init/hints/vms.pm will see more tweaks before I'm through. Bear with me on the VMSish filenames; xxx;1 is the original version, xxx; is the patched version of the file. At the moment pmc file generation aborts (probably due to an empty PMC list) - I'm looking into it. cu, Martin -- O Lord, won't you buy me | Martin Vorlaender | OpenVMS rules! an HP OS | work: [EMAIL PROTECTED] its name starts with Open | http://www.pdv-systeme.de/users/martinv/ and ends in VMS ...| home: [EMAIL PROTECTED] parrot-14347-vms.patch Description: parrot-14347-vms.patch
Re: [perl #40058] Disambiguate usage of class PMCs from class name lookup (pdd15, pdd06, pdd19)
On Sun, 6 Aug 2006, chromatic wrote: If my code depends on the undefinedness of certain symbols, and those symbols may or may not appear in some namespace somewhere due to something totally unrelated to my code, I have a problem. Ah. I thought we were considering the namespace which the language would use for its implementation, not for the namespace in which it would keep its client script's symbols. That being the case, your reservation eminently makes sense. But I didn't expect to see PerlArray as a reserved name in Perl 6, so I assumed we weren't talking about *that* namespace. -Martin
Re: [perl #40058] Disambiguate usage of class PMCs from class name lookup (pdd15, pdd06, pdd19)
On Thu, 3 Aug 2006, Chip Salzenberg wrote: KNOWN FUTURE DEVELOPMENTS It's already decided that we're moving class PMCs into the normal namespace tree. This change will eliminate many uses of the class-lookup opcodes, but not all: There's a two-level search will still be required, where the universal ['parrot'] HLL provides the fallback for class names not defined locally -- e.g. Cfind_type ['Integer'] could return ['yourHLL';'Integer'] if you've defined that, or else ['parrot';'Integer'] if you haven't. Any reason to treat HLL namespaces differently from classes, at least in respect of being an inheritance hierachy? Simply make 'yourHLL' inherit from 'parrot', and the rest follows... -Martin
Re: [perl #40058] Disambiguate usage of class PMCs from class name lookup (pdd15, pdd06, pdd19)
On Sun, 6 Aug 2006, chromatic wrote: Any reason to treat HLL namespaces differently from classes, at least in respect of being an inheritance hierachy? Preventative measures against future additions to 'parrot' breaking your code without your knowledge. It's the same reason many languages without namespaces or sigils have a sense of reserved keywords. The naive reaction to this is that if you define ['myHLL';'foo'] then whether ['parrot';'foo'] is defined (or later becomes defined) is of no concern. However there are two cases I can see where ['parrot';'foo'] must NOT exist: 1. if myHLL needs to search by some other order, such as the first of: ['myHLL';'foo'] ['myHLL';'bar'] ['parrot';'foo'] ['parrot';'bar'] 2. if myHLL does not actually define ['myHLL';'foo'] but then checks to see if it's usable, and would find ['parrot';'foo'] via the normal inheriting framework. But how often are these actually likely to be the case, and are there any other cases? -Martin
Re: Input / Output encoding filters.
I'm a bit slow coming back to this, sorry. It seems that seek is used in two ways: * returning to some previously identified point (including the start or end of the file) * moving a given number of characters you want to move relative to a known location Clearly you can always do the first, just by using the underlying byte offset without regard for the encoding. If you have a fixed number of bytes per character then you can trivially do the second as well. But if you have a variable-length encoding then you have to read through the byte stream to get to the position you want; this might or might not be desirable depending on the characteristics of the underlying stream. Furthermore it makes (some) sense always to be able to seek *forwards* -- even on a tty device -- but not backwards. So my suggestion is that we change the interface to seek, and have separate parameters for the previously known position and the character offset. The latter is obviously just an integer, but the first is a black-box token -- maybe a PMC, but more likely a mangled integer -- to ensure that the two args are distinguishable. (Please excuse me as I discuss this in terms of a HLL rather than Parrot...) In other words, change this: $fpos = $io.tell(); $io.seek(SEEK_SET, $fpos) to this: ... $io.seek($fpos, 0) or for brevity, just this: ... $io.seek($fpos) Now SEEK_SET, SEEK_CUR and SEEK_END just become special cases of previously known positions. And I'm tempted to say that they should be spelt 0, undef and -1 respectively. Thence it's fairly straightforward for the units of seek to be whatever you find convenient: counting whole records, or lines of text, or whatever. Clearly this needs to be discussed in p6-lang, but having separated the two parameter types, the filter can decide which it can implement, and how. -Martin
Re: About multithreading
Leo wrote: http://www.gotw.ca/publications/concurrency-ddj.htm The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software Herb Sutter On Tue, 20 Sep 2005, Jonathan Worthington replied: Yup, and it's encouraging to see Perl 6 is heading in a good direction on concurrency stuff at a language level too. So can we look towards having things like map and grep be parallel (or at least unordered) by default? -Martin
Re: parrot and refcounting semantics
On Thu, 28 Apr 2005, Robin Redeker wrote: I don't think circular references are used that much. Circular references are useful any time you need to be able to iterate over a collection, and also have to identify which collection a given object is in. This may even be implicit from other requirements, such as: * enforcing that an object may be in at most one collection of objects at a time * instructing an object to detach from its current collection (especially when forcibly destroying the object) In fact I often want BOTH timely destruction AND circular datastructures; for example, I want to hold an object that represents a row in a database, and I don't want to have to care which transaction, table, database or connection it belongs to. But at the other end, the object representing a transaction has to be able to reverse changes to all its component row objects. And when the transaction goes out of scope it needs to be either committed or rolled back. -Martin
Re: parrot and refcounting semantics
On Thu, 28 Apr 2005, Luke Palmer wrote:
Or, with the block hooks that I keep claiming makes timely destruction
almost never needed, it is:
{
my $s = new CoolClass;
# ... do stuff that may throw ...
LEAVE { destroy $s }
}
This destroys properly and even propagates the exception.
That's good ... but can we have a shorthand; stealing an old C keyword, I'd
suggest:
{
auto $a = new CoolClass;
# ... do stuff that my throw ...
}
Re: Parrot bytecode reentrancy
On Fri, 15 Apr 2005, Nigel Sandever wrote: I struck me a while back that there is a contradiction in idea of a shared, 'my' variable. I want to say lexical, but a var declared with 'our' is in some sense lexical. Shared-between-threads and shared-between-scopes are orthogonal properties; using our or my controls access by lexical scope; something else is needed to control access by thread, and :shared is as good as anything. The only exception to this orthogonality is that anything within a closure is not shared between threads -- but of course, that is only sensible because it is not even shared between multiple closures *within* a thread. -Martin
Re: Namespaces again
On Thu, 30 Sep 2004, TOGoS wrote: With this method, the *only* place you'll run into trouble is in a language where any string can be a variable identifier. [...] You could solve this by declaring that *all* variables in a namespace must begin with some sort of sigil, but then you can't pass a namespace to a function and have it be treated like a plain ole' associative array (or at least one with nice keys). Why not put the sigil prefix in a separate parameter to the relevant fetch and store opcodes, as a simple quoted literal string? Then you wouldn't have to generate extra temporary strings to hold the concatenations, but where you did have a string that included the appropriate sigil, it could be used directly by having an empty prefix. -Martin
Re: Synopsis 9 draft 1
On Mon, 6 Sep 2004, Aaron Sherman wrote: Sized low-level types are named most generally by appending the number of bits to a generic low-level type name: [...] int1 int2 int4 int8 int16 int32 int64 Ok, so Parrot doesn't have those. Parrot has int. The above generic low-level types are specific instances of a more general specification-based type system, with features grouped roughly as: * what range of values _must_ be storable, and what range of values _may_ be storable * what do you want to do if an attempt is made to store values outside the latter range The possible specifications for out of range behaviour should include: bound - force to nearest bound ignore - don't store, keep the previous value throw - die in perl-speak use(CONSTANT) - for example, use(undef) wrap- apply a modulus fastest - do whichever of the above gives the best performance on the current platform Presumably the default would be :out_of_range(wrap,lax), subject to modification by pragmata of course. The range should be specifyable as a numeric range, with an optional parameter: strict - use exactly the limits specified lax - use the natural limits of the underlying implementation (unless some contrary pragma is in effect, for testing purposes) Specification of signed and/or unsigned bitfields is problematic; usually they're used because the author assumes they will only-just-fit-into a specific implementation type, in which case the lax parameter would give the same benefit for a more readable range specification. Only in specific applications like CRC computation would an actual specific binary modulus be appropriate. Requirements of less expressive languages could be written in terms of these; in perl6-ish terms, perhaps something like this: my int $int1 :range( -1..0 ) :out_of_range(wrap); my int $int2 :range( -2..1 ) :out_of_range(wrap); my int $int4 :range(-16..15) :out_of_range(wrap); my int $int8 :range( -128..127 ) :out_of_range(wrap); my int $int16 :range( -32768..32767 ) :out_of_range(wrap); my int $int32 :range(-2147483648..2147483647) :out_of_range(wrap); my int $int64 :range(-9223372036854775808..9223372036854775807) :out_of_range(wrap); my int $int128 :range(-170141183460469231731687303715884105728..170141183460469231731687303715884105727) :out_of_range(wrap); my int $byte :range( 0..255 ) :out_of_range(wrap); my int $bool :range( 0..1 ) :out_of_range(use(1)); In my opinion we should target this case: a language that lets you specify to this level of detail, and automatically infers the most efficient low-level type from the given specification. To implement this, should we consider attaching a store (native) method to each integer register, which could implement the required logic for each of the above cases? Or would we need perhaps a vtable, with both store for when we're interpreting, and generate_jit_store for when we're jitting? -Martin
Re: Semantics for regexes - copy/snapshot
On Wed, 8 Sep 2004, Chip Salzenberg wrote: According to [EMAIL PROTECTED]: So how many stores do we expect for ($a = xxx) =~ s/a/b/g and which of the possible answers would be more useful? I think it depends on C($a = aaa) =~ s/a/b/g. I would agree with you in general, but since we're generally after speed, surely we want to allow for optimisations such as don't store unless something's changed; this would also be compatible with the boolean context value of s///. -Martin -- CAUTION: The information contained in this message is consequential and subject to legacy provenance. If you are the intended recipient you are hereby notified that reading this message is permitted. If you have not received this message please notarise the sender and destroy the originator.
Re: Semantics for regexes - copy/snapshot
On Tue, 7 Sep 2004, Leopold Toetsch wrote: [*] Unless it's a _feature_ that given tied $a, ($a = aaa) =~ s/a/b/g would call STORE four times (aaa, baa, bba, bbb). I'd expect two stores here. One for the initial setting of the value and one for the final result of the global subst. So how many stores do we expect for ($a = xxx) =~ s/a/b/g and which of the possible answers would be more useful? -- War against Terrorism is an oxymoron
Re: More on slices and iterators
On Tue, 15 Jun 2004, Dan Sugalski wrote: So, given that, should plain scalars act as iterators holding a single value and implement the iterator protocol? That'd be messy if two things tried to take an iterator over the same scalar as the same time. On the other hand if it created an iterator as a separate PMC then can see that would save having to construct an anonymous singleton array, and then an iterator over that. I would envisage that when the Perl6 compiler sees @foo[2, 3..7 :by(2), 11, 13, 17] it would create four iterators: one each over [2], [3..7:/2] and [11,13,17], and a concatenation iterator over those. Whether the iterator over [2] is created over a singleton array or directly from the scalar would seem to be simply a matter of economy. -Martin
Re: Event design sketch
On Tue, 11 May 2004, Uri Guttman wrote: Why would alarm need any special opcode when it is just a timer with a delay of [abs_time minus NOW]? Let the coder handle that and lose the extra opcodes. mab you want to make the latency between getting the abs_time, doing mab the substract[ion] and actually setting up the time as small as mab possible Accuracy of delivery (latency) is silly to worry about in Perl for granularities of more than about .05 seconds or so. Building a very fine grained accurate real-time system in Perl makes little sense to me. so i usually don't worry about who does the delta calculation and the slight amount of delay it takes. Never mind the granularity or latency, there are systems where time of day can be adjusted to take into account clock drift, while system elapsed time is left unaffected. Which you want depends on whether you want to sleep for a specific time, or wake up at a specific time, and it would be nice if Parrot didn't rule out making use of that. -Martin
Re: [PATCH] File Spec
On Thu, 4 Sep 2003 [EMAIL PROTECTED] wrote: On Mon, 1 Sep 2003, Michael G Schwern wrote: You also must worry about volumes. [my long explanation snipped] Sorry, wrong list; this is a standard-module issue, not an implementation issue or even a core-language issue. -Martin
Re: [PATCH] File Spec
point; on Win-NT4-POSIX links can only be created within the same directory. * If we rename a symlink from name A and pointing at B, to name C, will it still refer to the same file? How can we construct A+B from C or C from A+B to guarantee that it will? If we can't, how do we create a new symlink D that *will* refer to the same file? Or a new name E which it will refer to? And do all the above without requiring A and C to be in the same directory? I would strongly recommend deprecating any distinction between volume and path, and instead provide functions which focus on allowing us to answer the above questions in simple portable ways. But in the end, since Windows, MacOS, VMS and even RMX all have POSIX emulation, do we really care? Maybe we should just have functions for convert native name to POSIX and convert POSIX name to native and be done with it? -Martin [* Ok, an arbitrary number really means a 32-bit number -- or smaller] PS: don't forget, I said give or take filesystem permissions
Re: Bytecode metadata
On Sun, 26 Jan 2003, James Mastros wrote: just define a new packfile section, SIGNATURE, that is defined to be a cryptographic signature of all sections previous to it in the file. I'm battling with this in another file format at the moment; if possible can we please *not* have it sensitive to its own location in the file? For example, an auto-dearchive zip-file has its index at the end of the file, so that the code can go at the front. It would be nice if the whole archive could be signed, rather than just the dearchiving code. My suggestion: make the signature define which other parts of the file it applies to, say with a list of region boundaries as byte addresses in the file; that way signature manipulation remains fairly simple, and it's not too hard to check that a given section is spanned by a signature. And you could have multiple signatures applying to different parts of the file (one to the zip archive, another to the unarchiver). And how is this going to interact with -T or whatever we're going to use? Under my suggested scheme, the data would be untainted if it's covered by a verified signature, and tainted if not. -Martin
Re: 64-bit ints and non-capable hardware
On Wed, 23 Oct 2002, Rhys Weatherley wrote: Martin D Kealey wrote: [Frank Farance's paper] specification based extended integer range [at] http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/. Very interesting proposal. I wish they had adopted it. Would have saved me a lot of hassle with typedefs over the years. :-) Ditto! This ... works well in a statically compiled language like C because the compiler can ... say Oh! That's just int on this platform! and then compile away the distinction. I'm not sure how well it would work in a dynamic environment like Parrot, where the compiler doesn't necessarily know the final actual type. I think the equivalent for Parrot would be (1) a requirement to include a module MEDIUMINT (smaller than BIGINT), so that large (but not arbitrarily large) numbers could be supported (2) mechanisms to swap between that and INTVAL transparently at runtime, or at least, to allow the compiler to generate both sets of code without too much pain, or much impact on performance when the numbers are small enough to be INTVAL. (3) an opcode along the lines of truncate to N bits, where N is fixed (4) an opcode along the lines of throw exception if wider than N bits, where N is fixed It is up to the runtime engine. e.g. how would the engine rearrange the code to do signed int exact:64 with PMC's on 32-bit platforms and I registers on 64-bit? That way lies polymorphic instruction sets and other CLI madness ... (BTW: one of the criticisms of SBEIR was that exact and signed should have been mutually exclusive.) Rather than going the whole hog with polymorphic instruction sets, what about supporting what I'll call minor classes, which don't do inheritance or runtime polymorphism, specifically to support MEDIUMINT and other modules that mimic-but-extend native datatypes and operations, and are used as stand-ins by the compiler? P.S. I suspect one reason why it was rejected was because some programmer would ask for signed int exact:23517 and expect it to work on every compiler. Implementing the intrinsics for something like that is *hard*. I think there was agreement that it would be OK for the compiler to limit requests to 128 bits. For Parrot I would suggest that MEDIUMINT implement at least 2048 bit (256 byte), which would be useful for implementing cryptographic functions. -Martin -- CAUTION: The information contained in this message is consequential and subject to legacy provenance. If you are the intended recipient you are hereby notified that reading this message is permitted. If you have not received this message please notarise the sender and destroy the originator.
Re: 64-bit ints and non-capable hardware
Dan Sugalski [EMAIL PROTECTED] wrote: Okay, I'm about ready to just bite the bullet and declare that INTVALs have to be 64 bit integers. Does anyone know of a platform that has neither native nor emulated 64 bit integers? (One we're likely to run on, rather) I'm fairly new to Parrot, but I've spent a while following standards tracks for languages such as C and C++, and also using Perl, so hopefully I'm not too far off the mark here... I was wondering if anyone else followed the discussion in comp.std.c about integer types, prior to the adoption of the C99 standard? There was a substantial paper put out by Frank Farance, entitled specification based extended integer range or SBEIR for short; see http://wwwold.dkuug.dk/JTC1/SC22/WG14/docs/c9x/extended-integers/. It wasn't adopted at the time, mostly because it was too big a lump to swallow, too late in the standardisation process, but it looks like it might be timely for Parrot to consider the concepts involved. The basic idea is to express the requirements that a program has for its integers, and let the compiler choose the best option; minimum size trap-on-overflow, take-modulus-on-overflow, exactness of size (for modulus operation), compactness speed There were objections that this was too complex, and that some combinations didn't make sense. To address the complexity, I proposed that integers should be subcategorised as classical versus logical. Classical integers included all the existing C integer types, while logical integers were those based on usage specification rather than storage specification. In practice a logical specification would be something like an exact range of values with trap-on-overflow, whereas a classical or low level specification would be something like the range held by a CPU register, with host-specific handling of overflows. The relevance to Parrot is that, rather than opting for a short-list of integer sizes like [8, 16, 32 and 64 bit], we should if possible allow an extensible type system, possibly including optional automatic promotion to a library-implemented integer type (BigNum, Complex, or whatever). -Martin (I find it quiet disappointing that modern languages like Java and C# rely entirely on storage-based integer specifications 64 bit, when languages like Pascal and Algol had range-specified integers 20 years ago.) -- CAUTION: The information contained in this message is consequential and subject to legacy provenance. If you are the intended recipient you are hereby notified that reading this message is permitted. If you have not received this message please notarise the sender and destroy the originator.
Re: [perl #18044] Assembler doesn't return a useful exit status
On Mon, 21 Oct 2002, Clinton Pierce wrote: * With bad arguments, the assembler returns 1 to the OS. Peachy. Please can we have... #include sysexits.h exit(EX_USAGE); // 64 on most platforms * Upon failure, the assembler returns the status 0 to the OS and writes some bytecode. No telling how healthy that bytecode is. exit(EXIT_FAILURE); // 1 on most platforms -Martin -- CAUTION: The information contained in this message is consequential and subject to legacy provenance. If you are the intended recipient you are hereby notified that reading this message is permitted. If you have not received this message please notarise the sender and destroy the originator.
