Re: [perl #18034] [PATCH] Missing node types for imcc
Leopold Toetsch wrote: Thank you. Applied, except the bxor change, which breaks a perl6 test (t/compiler/1_5.p6). There is some ongoing discussions how the binary ops in perl6 will look like finally, but using '~' as bxor is the current state. I can live with this. Since imcc is an intermediate code format, it doesn't really matter to me what the symbol is, as long as it is distinguishable. However, you may want to look at the Cola code, because it currently outputs ^ for xor, which causes a failure when imcc is run. I haven't checked the other imcc-using components yet. Additionally you can spit out an explicit bxor $I1, $I2, $I3 to be independed from not yet finished operator changes. The operator names are in one table within the cscc code, so it will be relatively easy to change if needed. Operator names are the least of our worries (different sized ints, objects, classes, virtual methods, etc, etc, etc). Cheers, Rhys.
Re: C# and Parrot
At 7:21 PM +0530 10/20/02, Gopal V wrote: 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 ?. I think so. I'm going to add in some conversion ops for the shorter float forms, and for the partial-sized integers. I'm unsure at the moment whether I want to commit to full 64 bit integers in I registers. On the one hand it means a lot more can be done at the low level, on the other it means things are going to be potentially slow and emulated on non-64 bit int platforms. Plus it'll waste a fair amount of L1 cache for no purpose most of the time. 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). Yeah, I want to do that with parrot, being able to on the fly generate low-level call frames and call into native routines without having to explicitly generate and compile C code for it. It's a portability problem, to be sure, but on the other hand if we're going to have a JIT most places we're already getting much grubbier. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Help! Bugs! Crawling all over!
Steve Fink wrote: I currently get three test failures when running with GC_DEBUG on, but not always the same three (depending on how I muck with unrelated parts of the code.) On my system I get failures with op/string.t tests 96 and 97 and pmc/pmc.t test 76 (aka 75) The first two can be fixed by the patch below. The last one looks like a fundamental problem in MultiArray. The line b-cell_buffer = new_buffer_header(interpreter); in function new_marray is creating a new buffer header, overwriting the new_bufferlike_header created earlier. -- Peter Gibbs EmKel Systems Index: string.c === RCS file: /cvs/public/parrot/string.c,v retrieving revision 1.99 diff -r1.99 string.c 166c166,167 a-flags = ~(UINTVAL)BUFFER_constant_FLAG; --- a-flags = ~(UINTVAL)(BUFFER_constant_FLAG | BUFFER_COW_FLAG | BUFFER_external_FLAG);
Re: Two problems groping around in PerlHashes
At 9:30 AM +0200 10/21/02, Leopold Toetsch wrote: Jason Gloudon wrote: 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 ? As we are now (almost) able to generate packed arrays of chars, shorts , we should expand the type concept to not only the PMCs, but to all types. Yep, I concur. Negative numbers for non-PMC types is fine. Shouldn't a Perl Hash be a homogenous data structure, ie. it should contain just PMCs ? The current HASH_ENTRY holding a UnionVal and a type is more flexible, when native types are involved. So I'm not sure, if we should limit the value to be PMC only. For plain PerlHash PMCs, yes, they should be PMCs only. The union went into them in a fit of enthusiasm and generality. :) More specialized aggregates can hold more specialized things, but I'm not sure we're going to have a need for something that really efficiently holds multiple fundamental data types. All-ints, floats, strings, or PMCs, sure, and certainly ones with tighter restrictions on what types of PMCs can be stored, but I doubt we'll see a general need to store, say, PMCs and ints. And after recent discussions WRT C# and JVM, we'll have a bunch of yet more native types in the future. Yeah, I think so. I'm not thrilled with it, but that's rarely made a difference in the past. Now shouldn't be any different. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #18034] [PATCH] Missing node types for imcc
Rhys Weatherley wrote: However, you may want to look at the Cola code, because it currently outputs ^ for xor, which causes a failure when imcc is run. I haven't checked the other imcc-using components yet. Ah, thanks. s/\^/~/ checked in. leo
Re: [perl #x17936] [PATCH] MANIFEST
I just wanted to obsolete this Patch, because the missing files now have entered the MANIFEST. But bugs6.perl.org only tells me Permission denied. Im logged in, and the bugtracker recognizes this patch as mine. I've tweaked the permissions, try again. -R
[perl #18044] Assembler doesn't return a useful exit status
# New Ticket Created by Clinton Pierce # Please include the string: [perl #18044] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18044 * With bad arguments, the assembler returns 1 to the OS. Peachy. * Upon success, the assembler returns the status 0 to the OS and will write the bytecode as requested. * Upon failure, the assembler returns the status 0 to the OS and writes some bytecode. No telling how healthy that bytecode is. Makes it tough to write a harness during testing. IMHO, the assembler should (at least) return a different exit code for bytecode not fully assembled. Optimally, it shouldn't even write out the partial bytecode.
Re: Another vtable update
On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote: I'm currently committing the new splice vtable method for array classes. And finally, PMCs are currently only copied in, not cloned - I don't know, what is correct. clone is a deep copy? whereas copied means that another reference to the same object is stored? If so, I'd say that if only one option is available, then it should be copied. Because cloning sounds potentially expensive, and this way splicing temporaries into an array wouldn't cause the creation of a clone, only to destroy the original. [And something that does need a clone spliced in can explicitly call a clone op, and then splice that in] I'm not sure if having clone and copy variants of splice would be worth it. [Mainly because I'm worried if we're going a bit far on the number of ops we've got] Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [RFC] 2. Proposal for _keyed opcodes
At 5:46 PM +0200 10/21/02, Leopold Toetsch wrote:
Leopold Toetsch wrote:
2. Proposal for _keyed opcodes
--
The thread with subject pdd06_pasm, pdd08_keys: _keyed ops clearly
showes the shortcomings of the current _keyed opcodes and the
implementation of these.[1]
The 3 operand keyed add @a[$i] = @b[3] + %h{k}:
add_p_ki_p_kic_p_kc
Attached is a proof of concept of my proposal.
With an approach like this, we could cut down the VTABLE to roughly
1/3 of it's current size. The _keyed entrys would only consist of
the set_.._keyed{,_int} variants plus exists_keyed and
defined_keyed. And, we would never have the opcode explosion to 64
times of current size.
The big disadvantage here is speed. It means that specialized
aggregates will have to create temporary PMCs for things that don't
already have them, which is potentially slow and wasteful, something
I'd rather avoid. Encouraging the use of specialized aggregates is
one of the reasons for the typing system coming in with perl 6, and
given the size of aggregates in perl 5 I think it's something that
will see some heavy use.
I don't mind the opcode explosion, honestly. It's automatically
generated, and that's not a big deal. There are other ways to cut
down on it as well, if we find the need.
For the moment, I'd rather things stay the way they are. If we can
produce demonstrable speed wins, then I'll change my mind. For now,
though, things stay generally the way they are. We can do some mild
reworking to get things manageable if they're currently really
unmanageable.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [RFC] 2. Proposal for _keyed opcodes
Leopold Toetsch [EMAIL PROTECTED] writes:
Leopold Toetsch wrote:
2. Proposal for _keyed opcodes
--
The thread with subject pdd06_pasm, pdd08_keys: _keyed ops clearly
showes the shortcomings of the current _keyed opcodes and the
implementation of these.[1]
The 3 operand keyed add @a[$i] = @b[3] + %h{k}:
add_p_ki_p_kic_p_kc
Attached is a proof of concept of my proposal.
A 6 operand 3 keyed op get's rewritten like so:
/* OP _p_k_p_k_p_k =
* set py, p_k
* set pz, p_k
* new px, .PerlUndef
* OP px, py, pz
* set _p_k_px
*/
- It uses only set_ ops
- only imcc, but with pasm syntax in example
I like this approach. (The first time you posted it I didn't
understand it).
What happens if you try to use it on an object which has no real
components like a bitvector or a packed structure? There will always
be a pack-unpack cycle. On the other hand, is there any case where
this pack-unpack cycle can be avoided?
The newly created PMC is of type PerlUndef. Is this the correct
behavior or shouldn't it be the same type as the old element in the
Component? Something like this.
# OP Px[kx], Py[ky], Pz[kz]
set Pa, Py[ky]
set Pb, Pz[kz]
typeof Ii,Px[kx]
new Pc, Ii
OP Pc, Pa, Pb
set Px[kx], Pc
With an approach like this, we could cut down the VTABLE to roughly
1/3 of it's current size. The _keyed entrys would only consist of the
set_.._keyed{,_int} variants plus exists_keyed and defined_keyed. And,
we would never have the opcode explosion to 64 times of current size.
Instead of 1 opcode and 1 vtable-lookup with a quite complex
vtable-function you have 6 opcodes and 5 vtable lookups with simple
vtable-functions.
From the just opcode-counting point of view, the first solution is
surley better, but the complexity of the vtable function is much
larger than in the later case. The vtable has to distinguish all 8
possible combinations of keyed/non-keyed and than do up to 4
vtable-lookups with the resulting calls to the vtable functions. So
behind the behind the scenes the total number of vtable-calls
(except for some very special cases) is exactly the same. Remains the
number of opcodes. But as the opcode-table gets smaller so its much more
likely that it fits into the cache. Also no vtable function has to
decide wether its called with 1, 2 or 3 keyed elements.
bye
b.
--
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: Two problems groping around in PerlHashes
Jason Gloudon wrote: 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 ? As we are now (almost) able to generate packed arrays of chars, shorts , we should expand the type concept to not only the PMCs, but to all types. Shouldn't a Perl Hash be a homogenous data structure, ie. it should contain just PMCs ? The current HASH_ENTRY holding a UnionVal and a type is more flexible, when native types are involved. So I'm not sure, if we should limit the value to be PMC only. And after recent discussions WRT C# and JVM, we'll have a bunch of yet more native types in the future. leo
Re: Another vtable update
Dan Sugalski wrote:
Just in case folks missed it, I fixed the docs for the splice vtable
entries in PDD2.
I'm currently committing the new splice vtable method for array classes.
It should work like documented in »perldoc -f splice«. Differences are:
- no return value, meaning perl{,6} has to get the values out of the
array, which will be removed by splice, if needed.
- all parameters have to be present, an empty array serves for a missing
LIST param, a missing LENGTH parameter should be substituted by
»array.length - offset«.
A negative »count« parameter is supported, though I'm not too sure, if
it does what it should to, as well as a negative »offset«.
And finally, PMCs are currently only copied in, not cloned - I don't
know, what is correct.
leo
PS please make clean after cvs update.
RE: Scratchpad confusion
I think, I can answer a few of these questions. -Original Message- From: Allen Short [mailto:washort;twistedmatrix.com] 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? =) Neither, Dan Sugalski owes us an update, which should be coming soon ... 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? I am sure they will be a PMC. In fact two different patches have been submitted to make them PMCs, one by me and a better one by Sean O'Rourke. Sean's has not been committed yet, probably because he is waiting for a decision on the more flexible ops by Dan. -- Jonathan Sillito
Re: Another vtable update
At 9:27 PM +0100 10/21/02, Nicholas Clark wrote: On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote: I'm currently committing the new splice vtable method for array classes. And finally, PMCs are currently only copied in, not cloned - I don't know, what is correct. clone is a deep copy? whereas copied means that another reference to the same object is stored? If so, I'd say that if only one option is available, then it should be copied. Copying is the right thing to do here. If the compiler wants to put copies of things into an aggregate, it can make copies first. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C# and Parrot
Dan Sugalski wrote: I think so. I'm going to add in some conversion ops for the shorter float forms, and for the partial-sized integers. I'm unsure at the moment whether I want to commit to full 64 bit integers in I registers. On the one hand it means a lot more can be done at the low level, on the other it means things are going to be potentially slow and emulated on non-64 bit int platforms. Plus it'll waste a fair amount of L1 cache for no purpose most of the time. 64-bit integers (both signed and unsigned) are rare enough in C# (and Java) code that accessing them via PMC operations will not be a huge burden. Putting them in registers is not necessary on my account. As to your other message, where you suggest making INTVAL's 64-bit all of the time, I really don't like that proposal. It makes the common case inefficient. You'll also go mad trying to implement 64-bit multiplication and division in the JIT ( :-) ). If you make it a PMC operation, you can let the compiler do the work. There are other places in Parrot that assume that an INTVAL is the same size as a native pointer (e.g. set_addr). Mandating a fixed size might break these assumptions. My humble suggestion is to do this: INTVAL is guaranteed to be 32 bits or higher in size. FLOATVAL is guaranteed to be 64 bits or higher in precision. Int64 is added as a new PMC type. Then use conversion opcodes to re-normalize results to smaller fixed sizes where necessary. Languages that care about sizes must do explicit conversion. Other languages can be free-form. It will be a little annoying to do this in the C# compiler: add I0, I1, I2 conv_int32 I0, I0 However, the JIT can optimize away the conv_int32 on a 32-bit platform, so it isn't really an issue. But it will be an issue if you make everything 64-bit. BTW, I've yet to come across a compiler that doesn't have some way to use 64-bit integers. The names vary: long on some, long long on others, and the obnoxious __int64 on Windows. But that's just a configuration problem. Cheers, Rhys. P.S. Don't forget the unsigned types. :-)
64-bit ints and non-capable hardware
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) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Another vtable update
On Mon, Oct 21, 2002 at 04:54:48PM -0400, Dan Sugalski wrote: At 9:27 PM +0100 10/21/02, Nicholas Clark wrote: On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote: I'm currently committing the new splice vtable method for array classes. And finally, PMCs are currently only copied in, not cloned - I don't know, what is correct. clone is a deep copy? whereas copied means that another reference to the same object is stored? If so, I'd say that if only one option is available, then it should be copied. Copying is the right thing to do here. If the compiler wants to put copies of things into an aggregate, it can make copies first. You keep using that word. I do not think that it means what you think it means. :-) [I take it that you mean: copying the PMC in is the right thing to do where. If the compiler wants to put a copy of the value into an aggregate, it can make a deep copy first ] Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [perl #17936] [PATCH] MANIFEST
Jürgen Bömmels (via RT) [EMAIL PROTECTED] writes: # New Ticket Created by Jürgen Bömmels # Please include the string: [perl #17936] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17936 There are again some files missing in MANIFEST. I just wanted to obsolete this Patch, because the missing files now have entered the MANIFEST. But bugs6.perl.org only tells me Permission denied. Im logged in, and the bugtracker recognizes this patch as mine. Confused b. -- 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: Another vtable update
At 10:35 PM +0100 10/21/02, Nicholas Clark wrote: On Mon, Oct 21, 2002 at 04:54:48PM -0400, Dan Sugalski wrote: At 9:27 PM +0100 10/21/02, Nicholas Clark wrote: On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote: I'm currently committing the new splice vtable method for array classes. And finally, PMCs are currently only copied in, not cloned - I don't know, what is correct. clone is a deep copy? whereas copied means that another reference to the same object is stored? If so, I'd say that if only one option is available, then it should be copied. Copying is the right thing to do here. If the compiler wants to put copies of things into an aggregate, it can make copies first. You keep using that word. I do not think that it means what you think it means. :-) D'oh! Yes, the PMC *pointer* can be used directly. The PMC being inserted in with the splice operation does *not* have to be cloned, copied, or otherwise twiddled with. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #18034] [PATCH] Missing node types for imcc
Rhys Weatherley (via RT) wrote: # New Ticket Created by Rhys Weatherley # Please include the string: [perl #18034] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18034 The attached patch adds some missing expression node types to the imcc syntax. In particular, for the Parrot instructions bxor, bnot, lsr, and, or. Thank you. Applied, except the bxor change, which breaks a perl6 test (t/compiler/1_5.p6). There is some ongoing discussions how the binary ops in perl6 will look like finally, but using '~' as bxor is the current state. '^=' is perl6's hyper assign operation for arrays, which will or will not sometimes be handled inside parrot, so I don't like to use '^' currently. Additionally you can spit out an explicit bxor $I1, $I2, $I3 to be independed from not yet finished operator changes. Rhys Weatherley. leo
Help! Bugs! Crawling all over!
I haven't been applying many patches recently, partly because I haven't had much time available, and partly because there are gc-related bugs lurking in the code that I regard as higher priority. I tried tracking them down, but somewhere in the middle I realized that I really ought to be trying to put together a 0.0.9 release instead. So, I just checked in something that breaks 'make test' for everyone: GC_DEBUG is now on by default for tests. (But _only_ for tests -- the parrot executable still has it off by default.) I reworked it so that it is a property of the interpreter and can be enabled and disabled at runtime via the --gc-debug flag to parrot, or by setting the $PARROT_GC_DEBUG environment variable. In fact, it should be possible to toggle it in the middle of a run, but I haven't tried it -- it changes the parameters to the memory management system, so turning it on halfway through a program might do strange stuff. This slows parrot down by about 7% when debugging is turned off (on my machine, for lifetest). So there is also a DISABLE_GC_DEBUG #define in include/parrot/parrot.h that may be turned on for optimized builds. For a -O3 compile on my system, I get a 1% slowdown over the previous CVS version when running without the jit, and a 1% speedup when running with the jit. Or, in other words, no measurable overhead. (Which is unsurprising; it just means I didn't break anything.) I currently get three test failures when running with GC_DEBUG on, but not always the same three (depending on how I muck with unrelated parts of the code.) The slowdown when GC_DEBUG is turned on is... more than 7%. It isn't too bad for most of the tests or mopstest, but for lifetest I get a factor of 140x slowdown. Heh. It also turned out to be too annoyingly slow for t/op/stacks.t test #7 and t/pmc/intlist.t tests #3 and #4. I don't want to make the tests too onerous to run, so I put in a not-so-pretty hack to disable GC_DEBUG for just those three tests, when running under 'make test' or a variant. It's documented in the makefile and in those tests.
RE: 64-bit ints and non-capable hardware
Dan Sugalski:
# 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)
Mac Classic processors and Palm DragonBalls?
By the way, it looks like Palm OS now supports stdio emulation. I don't
know what versions it works for (it mentions using a Palm VII, which
uses 3.2, I think), but that should make porting much easier.
Apparently, you write a host app with a text box and scroll bar, then
tell the stdio emulation system what those are called. You then call a
specialized form of program; it must have linked in StdIOPalm.c. More
info:
http://www.palmos.com/dev/support/docs/palmos/StandardIOApp.html#102439
4.
***
The Palm OSR supports command line (UNIX style) applications for
debugging and special purposes such as communications utilities. This
capability is not intended for general users, but for developers. This
feature is not implemented in the Palm OS, but rather by additional C
modules that you must link with your application.
Summary of Standard IO
Standard IO Macros and Functions
fgetc
fgets
fprintf
fputc
fputs
getchar
gets
printf
putc
putchar
puts
SioAddCommand
Siofgetc
Siofgets
Siofprintf
Siofputc
Siofputs
Siogets
Sioprintf
Sioputs
Siosystem
Siovfprintf
sprintf
system
vfprintf
Vsprintf
Application-Defined Functions
SioMain
Standard IO Provider Functions
SioClearScreen
SioExecCommand
SioFree
SioHandleEvent
SioInit
--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: C# and Parrot
Bryan C. Warnock sent the following bits through the ether: Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe for floating point numbers? For the JVM: http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#19511 The floating-point types are float and double, which are conceptually associated with the 32-bit single-precision and 64-bit double-precision IEEE 754 values and operations as specified in IEEE Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard 754-1985 (IEEE, New York). More details at: http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#33377 HTH, Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ Cryptonomicon: The girl's guide to geek guys
Re: 64-bit ints and non-capable hardware
On Mon, 2002-10-21 at 15:11, Dan Sugalski wrote: Okay, I'm about ready to just bite the bullet and declare that INTVALs have to be 64 bit integers. Which INTVALs? INTVAL, IMHAOSBRPO[1], is overused internally. I see little relative performance and size damage if INTVAL is made 64 bits and relegated only to user-space math as long as the internals (pointer-tracking, sizes, offsets, etc) are left as native. You can check and cast when numbers cross over. OTOH, converting all of the internals to 64-bit is probably not such a good idea. Of course, I registers are probably being used for both uses completely independent of each other. Or did I miss the point on wherefore 64-bit? Does anyone know of a platform that has neither native nor emulated 64 bit integers? (One we're likely to run on, rather) If it has neither, the internals shouldn't be affected, although user-space values will be. But you can convert to BigInt at 32 bits vice 64. (Assuming that's still the plan.) [1] In My Humble And Oft-Stated But Rarely Patching Opinion ;) -- Bryan C. Warnock bwarnock(gtemail.net|raba.com)
Re: Character Properties
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Sender: [EMAIL PROTECTED] (Unverified) Date: Mon, 21 Oct 2002 11:37:51 -0400 From: Dan Sugalski [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.12-dev, http://develooper.com/code/qpsmtpd/ At 11:09 PM -0600 10/20/02, Luke Palmer wrote: 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. While they're certainly useful, I think essential's an awfully strong word there. You'll note that, just off the top of my head, C, BASIC, Fortran, Perl, Python, Java, Ruby, Pascal, Oberon, Modula (2 and 3), Forth, Eiffel, Haskell, BLISS, C++, C#, COBOL, PL/I, APL, B, and BCPL all don't do character properties/attributes. -- Dan Fair enough. Then tell me how you solve this problem: You have a text file in a string, that the user has marked several places in. He's referring to words for which he wants to keep bookmarks in. Now, he deletes text (using substr), and we want to keep the marks relative to the words, not their positions. This seems easy, yet there's not necessarily an easy way to do it. Uh oh, violating perl philosophy :) Ok, how about this: Is there a reason Inot to? Or should I not go there? Luke
Re: Character Properties
Dan Sugalski wrote : And, FWIW, emacs is written in C. Granted a much macro-mutated version of C, but C nonetheless. Just like Perl 5 ;-)
RE: Character Properties
Jonathan Scott Duff wrote: Ok, how about this: Is there a reason Inot to? Or should I not go there? Off hand, it sounds expensive. I don't see a way to only let the people who use it incur the penalty, but my vision isn't the best in the world. It should be possible to define the bookmark methods on the basic string class to rebless the object onto a more powerful subclass. This way, there is no overhead until the extra information is actually attached. (bless, not copy, because there may be other references to the string). Dave.
Re: Character Properties
[EMAIL PROTECTED] (David Whipp) writes: It should be possible to define the bookmark methods on the basic string class to rebless the object onto a more powerful subclass. That makes it a doubly good candidate for modulehood. -- It's 106 miles from Birmingham, we've got an eighth of a tank of gas, half a pack of Dorritos, it's dusk, and we're wearing contacts. - Malcolm Ray
Re: Character Properties
At 10:53 AM -0700 10/21/02, Austin Hastings wrote: Yeah, but emacs isn't written in any of those languages. What, you're using emacs as an argument *for* something? :-P And, FWIW, emacs is written in C. Granted a much macro-mutated version of C, but C nonetheless. --- Dan Sugalski [EMAIL PROTECTED] wrote: At 11:09 PM -0600 10/20/02, Luke Palmer wrote: 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. While they're certainly useful, I think essential's an awfully strong word there. You'll note that, just off the top of my head, C, BASIC, Fortran, Perl, Python, Java, Ruby, Pascal, Oberon, Modula (2 and 3), Forth, Eiffel, Haskell, BLISS, C++, C#, COBOL, PL/I, APL, B, and BCPL all don't do character properties/attributes. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Character Properties
At 2:20 PM -0600 10/21/02, Luke Palmer wrote: Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Sender: [EMAIL PROTECTED] (Unverified) Date: Mon, 21 Oct 2002 11:37:51 -0400 From: Dan Sugalski [EMAIL PROTECTED] X-SMTPD: qpsmtpd/0.12-dev, http://develooper.com/code/qpsmtpd/ At 11:09 PM -0600 10/20/02, Luke Palmer wrote: 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. While they're certainly useful, I think essential's an awfully strong word there. You'll note that, just off the top of my head, C, BASIC, Fortran, Perl, Python, Java, Ruby, Pascal, Oberon, Modula (2 and 3), Forth, Eiffel, Haskell, BLISS, C++, C#, COBOL, PL/I, APL, B, and BCPL all don't do character properties/attributes. Fair enough. Then tell me how you solve this problem: You have a text file in a string, that the user has marked several places in. He's referring to words for which he wants to keep bookmarks in. Now, he deletes text (using substr), and we want to keep the marks relative to the words, not their positions. This seems easy, yet there's not necessarily an easy way to do it. Uh oh, violating perl philosophy :) I didn't call the problem unreasonable, I was objecting to its characterization as an essential feature. It isn't. A useful thing, definitely, but there are a lot of those. It's hardly essential any more than, say, a hash that automagically maps to the current directory's files (iteratively, of course, catching all the subdirectories) is essential While perl is a language that makes it easy to do useful things, it doesn't mean that all useful things should be easy to do in perl. Given how large the set of Useful Things is, that's not unreasonable. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Character Properties
At 7:22 PM + 10/21/02, Rafael Garcia-Suarez wrote: Dan Sugalski wrote : And, FWIW, emacs is written in C. Granted a much macro-mutated version of C, but C nonetheless. Just like Perl 5 ;-) Almost. At least perl 5's macros look like C. Emacs' macro horrors make C look like Lisp... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Character Properties
On Mon, Oct 21, 2002 at 02:20:56PM -0600, Luke Palmer wrote: Fair enough. Then tell me how you solve this problem: You have a text file in a string, that the user has marked several places in. He's referring to words for which he wants to keep bookmarks in. Now, he deletes text (using substr), and we want to keep the marks relative to the words, not their positions. This seems easy, yet there's not necessarily an easy way to do it. Uh oh, violating perl philosophy :) Sounds like a good candidate for modulehood. Ok, how about this: Is there a reason Inot to? Or should I not go there? Off hand, it sounds expensive. I don't see a way to only let the people who use it incur the penalty, but my vision isn't the best in the world. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Character Properties
I didn't call the problem unreasonable, I was objecting to its characterization as an essential feature. It isn't. A useful thing, definitely, but there are a lot of those. It's hardly essential any more than, say, a hash that automagically maps to the current directory's files (iteratively, of course, catching all the subdirectories) is essential I see what you mean now. I had A Momentary Lapse of Reason, in which I forgot modules could do such things. It's very suited to a module---not very common, but very important to certain problems. Luke
[ANNOUNCE] POOC v0.2
The Perl6 OO Cookbook, v0.2 is online. http://cog.cognitivity.com/perl6/ Changes include: [] *Much* better accuracy in most of the early recipes (better matching to Apos/Exes and perl6-language: see the 'Status' fields of each recipe.) More fixes coming very soon. [] Ability to annotate sections and recipes w/ discussion/comments/questions [] Ability for the community to 'rate' each recipe for (1) general importance of the problem presented and (2) acceptability of the solution presented. [] A new section on assertions/invariants (no solutions, only problems :-D) For more info, see the new About/Contribute/Preface pages. -- For those of you who haven't yet visited, the goal of the POOC is (at the moment) less to give Solutions (because most haven't been decided yet) than to compile the full and complete list of Problems that solutions will eventually be shoved into. It represents all the questions that someone is likely to ask when being introduced to perl6 OO. There are 106 recipes so far. The interactive features are experimental. They're in there to encourage community discussion, and because they were easy to do (I'll tweak them as needed). There are many people out there who don't have the time or ability to help the perl6 programming efforts directly, but who still are intensely interested in the process; this represents one simple way of contributing. 1) Ratings I am hoping that the general community will help out by 'rating' each problem and solution. By giving a Problem a high rating, you're saying that a one-line solution to the problem is critically important to you. A low rating means you don't particularly care if perl6 even _supports_ a solution to the problem. By giving a Solution a high rating, you're saying that if that's the way perl6 actually solves the problem, you'd be thrilled. A low rating means you'd never remember the solution or syntax in a million years, and would need it stapled to your forehead if you actually wanted to use that feature. 2) Comments/Annotations A place exists in every section and recipe for comments, questions, objections, corrections, or general discussion. Use this to give feedback or ask/answer questions when you don't want to clutter up the mailing lists. -- For reference, in the first week the POOC had been visited by at least 550+ unique individuals, logging thousands of individual visits. Not bad, I think. MikeL
