Re: Two problems groping around in PerlHashes
On Sun, Oct 20, 2002 at 12:32:24PM +0200, Leopold Toetsch wrote: PDD02 specifies the needed methods exists_keyed type_keyed The vtable PDD refers to type_keyed returning the type of the *PMC*. This isn't accurate given the question. Should we change the PDD ? perlhash/array have exists_keyed (but no type_keyed), though the opcodes are missing. On a tangent: Shouldn't a Perl Hash be a homogenous data structure, ie. it should contain just PMCs ? -- Jason
Re: C# and Parrot
On Sun, 2002-10-20 at 07:39, Leon Brocard wrote: Leon Brocard sent the following bits through the ether: It looks like the DotGNU weekly IRC meeting will be discussing Parrot. Could be interesting: It was quite interesting. I managed to make it to the early one and Dan to the later one. An annotated and abridged chatlog is available: http://dotgnu.info/pipermail/developers/2002-October/008380.html It looks like we're going to need 8,16,32,64 bit types... Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe for floating point numbers? Are we still targeting a middle ground for C? (Enough to be able to parse and handle structs natively, and possibly even make calls natively?) -- Bryan C. Warnock bwarnock(gtemail.net|raba.com)
RE: Getting started guide v0.4
Erik Lechak:
# And in my tinkering around, I compile a lot. I have also added this
# handy little perl script that helps.
#
# I only know that it works on win32 (XP). I could get it working on
# linux if anyone is interested.
#
# Extensions are in win32 speak. But it uses Config.pm so it should be
# somewhat easy to make work for linux if it already does not.
# Here is a
# summary of what it does.
Sweet! Thanks. This could be very useful if we can set it up to work
on Unices.
# I think I know the answer, but is there a reason why in
# Config.pm 'so'
# maps to '.dll' and 'ar' only maps to 'lib' with no dot? Does
# it have to
# do with 'hello.lib' for windows and 'libhello.a' for linux?
$(AR) is the program you invoke to create a library, IIRC.
C:\Brent\Visual Studio Projects\Perl 6\parrot\parrotlib -?
Microsoft (R) Library Manager Version 7.00.9466
Copyright (C) Microsoft Corporation. All rights reserved.
usage: LIB [options] [files]
options:
/DEF[:filename]
/EXPORT:symbol
/EXTRACT:membername
/INCLUDE:symbol
/LIBPATH:dir
/LIST[:filename]
/MACHINE:{AM33|ARM|IA64|M32R|MIPS|MIPS16|MIPSFPU|MIPSFPU16|MIPSR41XX|
PPC|PPCFP|SH3|SH3DSP|SH4|SH5|THUMB|TRICORE|X86}
/NAME:filename
/NODEFAULTLIB[:library]
/NOLOGO
/OUT:filename
/REMOVE:membername
/SUBSYSTEM:{CONSOLE|EFI_APPLICATION|EFI_BOOT_SERVICE_DRIVER|
EFI_ROM|EFI_RUNTIME_DRIVER|NATIVE|POSIX|WINDOWS|
WINDOWSCE}[,#[.##]]
/VERBOSE
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: [perl #18008] t/src/list.t failing.
Simon Glover wrote:
-for (i = 0; i 5; i++)
+for (i = 0; i 5; i++) {
I'm wondering, how I could miss this.
Anyway, thank you for the report, fix checked in.
leo
Re: C# and Parrot
Leon Brocard sent the following bits through the ether: It looks like the DotGNU weekly IRC meeting will be discussing Parrot. Could be interesting: It was quite interesting. I managed to make it to the early one and Dan to the later one. An annotated and abridged chatlog is available: http://dotgnu.info/pipermail/developers/2002-October/008380.html It looks like we're going to need 8,16,32,64 bit types... Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ 43rd Law of Computing: Anything that can go wr...
Re: Two problems groping around in PerlHashes
Clinton A. Pierce wrote: While working on ...something... I found the need to be able to tell if a key exists in a PerlHash. Here's the kicker, I don't know what kind of data's gonna be there: int, float, PMC, or string. [ snipp ] exists Px[key], branch PDD02 specifies the needed methods exists_keyed type_keyed perlhash/array have exists_keyed (but no type_keyed), though the opcodes are missing. So once I can tell the key is there, that brings up the second problem: what exactly is behind that key? A PMC? A native type? The only thing I can think of that would suffice would be to tinker with typeof to make it able to recognize the PASM native types (N, I, S) and then to make it a keyed op. We must define and standardize the enum_type_*. list.h has a bunch of them, though, when reading PDD02, the values should be negative numbers to discern these types from PMCs. hash.h has it's own types, which of course should match those in list.h leo
Re: C# and Parrot (dotgnu meeting)
If memory serves me right, Leon Brocard wrote: It looks like the DotGNU weekly IRC meeting will be discussing Parrot. Could be interesting: http://www.dotgnu.org/pipermail/developers/2002-October/008345.html A condensed summary of the IRC meetings have been posted as :- http://www.dotgnu.org/pipermail/developers/2002-October/008380.html. Also the full logs are available from http://ajmitch.dhis.org/dotgnu/ Gopal ps: here's my hello world to parrot , a small example compiler that does IL and *now* parrot. http://symonds.net/~gopalv82/code/expr_compiler.tgz Check out the treecc AST operation management . -- The difference between insanity and genius is measured by success
Re: C# and Parrot
Bryan C. Warnock wrote: Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe for floating point numbers? The CLI has three floating point types, of which 2 are visible to C# and a third is used by the engine. These are float32, float64, and native float. The first two have specific sizes, and are expected to be IEEE compatible. The third is the native floating point representation for the underlying machine, which is assumed to have precision greater than or equal to float64. The actual size is unspecified by the standard, and it is OK to set native float == float64. Floating point operations are always performed in native float, and then down-graded to float32 or float64 prior to being stored in a local or object field. The long and the short of it is that Parrot's FLOATVAL is good enough for C#'s purposes, with the minor requirement of a double - float conversion opcode. Which is essentially a truncate and then re-extend to FLOATVAL, similar to the int - short and int - byte cases. Cheers, Rhys.
Re: C# and Parrot
If memory serves me right, Bryan C. Warnock wrote: It looks like we're going to need 8,16,32,64 bit types... Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe for floating point numbers? IL (Ecma-335) -- 134.1.1 Floating Point 14 The floating point feature set consists of the user-visible floating-point data types float32 and float64, and 15 support for an internal representation of floating-point numbers. Float32 -- Single Float64 -- Double And,IIRC the same for JVM as well ?. Are we still targeting a middle ground for C? (Enough to be able to parse and handle structs natively, and possibly even make calls natively?) Hmm... would be thinking of something like PInvoke in C# ? (viz a lot like JNI, but marshalls/unmarshalls args automatically, and we've managed to wrap parts of X11 with it). Or are you thinking about compiling C to Parrot ? Dan : Consider it both mildly interesting and mildly bemusing :) Gopal -- The difference between insanity and genius is measured by success
Scratchpad confusion
The ops described in PDD 6 and docs/parrot_assembly.pod for scratchpads appear to be subtly different from the ones actually in core.ops. In particular, i was led astray by the docs referring to the newpad op and core.ops implementing new_pad. which is it supposed to be? =) I started investigating scratchpads because I'm interested in improving the scheme compiler. I'd agree with Sean O'Rourke's comments (http://archive.develooper.com/perl6-internals;perl.org/msg12722.html) -- the current ops seem too limited; in particular, I dont see how one would save a scratchpad with a function definition, or modify the toplevel scratchpad. Looking beyond Scheme, it appears to me that other languages would need more flexible handling of scoping as well; Common Lisp, for example, keeps functions in a separate namespace from other variables. Being new to Parrot hacking, could someone point me at the rationale for making scratchpads a special case, rather than a PMC? Allen msg22687/pgp0.pgp Description: PGP signature
Two problems groping around in PerlHashes
While working on ...something... I found the need to be able to tell if a key exists in a PerlHash. Here's the kicker, I don't know what kind of data's gonna be there: int, float, PMC, or string. After hunting around in t/perlhash.t I found a few examples of checking for keys that don't exist. They look like: new P1, .PerlHash set P0, P1[not_there] typeof S1, P0 eq S1, PerlUndef, NOTTHEREBRANCH Okay this is cool, except it doesn't work if the hash has mixed types in it and the key you're looking for *actually exists*. For this code: new P1, .PerlHash set P1[mykey], I0 # So it will exist set P0, P1[mykey] Parrot correctly throws an error: Cannot fetch PMC out of non-PMC key! Correct or not, this is a pain in the butt. There's no way to grope around in a PerlHash unless you already know what keys are there and what type they are. What I think we need is an exists opcode. And looking at classes/perlhash.c it looks like there's a exists function already there. I just can't figure out how to use it in PASM. There appears to be no opcode for it. Is this something of the PMC API we can expose to PASM programmers? Can someone gimme a hint of how to make this a real live opcode? Or, if someone can easily turn this on somehow, I think the best API for something like exists would be: exists Px[key], branch So once I can tell the key is there, that brings up the second problem: what exactly is behind that key? A PMC? A native type? The only thing I can think of that would suffice would be to tinker with typeof to make it able to recognize the PASM native types (N, I, S) and then to make it a keyed op.
Re: perl6 operator precedence table
Mark J. Reed wrote: On 2002-10-17 at 22:52:49, Smylers wrote: ... I initially misread the bar as an exclamation mark. I realize that this is a sample size of one ... Make that a sample size of two. Well, not really. (Presumably there are many other people who also read Larry's mail without any problems.) I think the confusion is actually increased by the period; in this font (X11 fd: misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1), the period is notably larger than the dot of the exclamation point, which visually reduces the significance of that tiny gap. Ah yes. (I'm using a different variant of the same typeface.) If the font had got a full-stop-sized dot on the bottom of the exclamation (and question) mark there wouldn't be a problem. In which case, I withdraw my objection: * Perl has to make a working assumption that, in general, different characters look different; if they don't, that's the typeface's problem not Perl's. If we pander to every possible conflict that might occur in any typeface, there'll be very few characters left to use. (For example in the default Courier font used by 'KEdit' braces look like square brackets, but we blatantly need to have both of those in the language.) And xor isn't particularly common, so the scope for confusion would be limited. * I _can_ tell the difference, once I look properly, even in this font. I was concerned that those with vision difficulties may not be able to do so. But presumably such people will choose more sensible typefaces (and probably larger ones). Somebody fairly recently recommended some decent fixed-width typefaces. I think it may have been MJD, but I can't find the reference right now (could be at work). Smylers
Re: perl6 operator precedence table
Larry Wall wrote: $a .! $b # bitwise xor $a ! $b # logical xor ! $b # logical not I like the notion that binary ! means that the two sides are sharing one not. That's the definition of XOR in a nutshell. I like that too. It also means that C!! and C.!! become the equivalence operators for free. (Technically inverting the right operand then doing xor, but that's ... um, equivalent.) However it means that the binary ops become: $a || $b # logical or $a .| $b # bitwise or $a $b # logical and $a . $b # bitwise and $a ! $b # logical xor $a .! $b # bitwise xor That makes logical xor look a little inconsistent (it doesn't line up for a start). Doubling the exclamation mark would make logical xor fit in better (though that'd leave three of them in equivalence). I also like the idea that ~ is entirely freed up for some other nefarious use. Yeah; how'd that happen? Seems like not too long ago we were short of punctuation symbols, and now you've got a spare one lying around. Smylers
Re: perl6 operator precedence table
Somebody fairly recently recommended some decent fixed-width typefaces. I think it may have been MJD, but I can't find the reference right now (could be at work). Michael Schwern recently suggested Monaco, Neep or, if you can find them, Mishawaka or ProFont. I investigated and found this link to be useful: http://www.tobias-jung.de/seekingprofont/ -- ralph
Re: perl6 operator precedence table
Me wrote: Somebody fairly recently recommended some decent fixed-width typefaces. I think it may have been MJD ... Michael Schwern recently suggested Monaco, Neep or, if you can find them, Mishawaka or ProFont. Ah, yes. That's what I was failing to recollect. (Apologies to both MJD and Schwern ...) I investigated and found this link to be useful: http://www.tobias-jung.de/seekingprofont/ Ta. Smylers
Character Properties
What's the plan on having properties, or attributes (depending on how far we're taking it), on individual characters in a string? I think it's an essential feature, as Lisp has shown us. If there's an argument otherwise, I'm all ears. Luke
