On Sat, 2003-05-31 at 09:57, Bryan C. Warnock wrote:
On Sat, 2003-05-31 at 09:53, Leopold Toetsch wrote:
Bryan C. Warnock [EMAIL PROTECTED] wrote:
As mentioned previously. Makes IMCC and PASM constant keywords
consistent, with '.const'.
As mentioned previously ;-) this doesn't
The following code:
.local PerlArray READDATA
.local PerlHash RESTOREINFO
.sub _main
READDATA = new PerlArray
RESTOREINFO = new PerlHash
call _data
end
.end
.sub _data
push READDATA, 10
ret
.end
Throws an error in the VM of:
push_integer()
If memory serves me right, Bryan C. Warnock wrote:
No .. to add large numbers very quickly ... ie split registers and
enemies ;-)
Understood. My point was that - to parallel virtual machines with
physical ones - the big drive for 64-bit has never been about squeezing
out another point-n
On Sun, 2003-06-01 at 10:08, Gopal V wrote:
If memory serves me right, Bryan C. Warnock wrote:
No .. to add large numbers very quickly ... ie split registers and
enemies ;-)
Understood. My point was that - to parallel virtual machines with
physical ones - the big drive for 64-bit
Clinton A. Pierce [EMAIL PROTECTED] wrote:
The following code:
push_integer() not implemented in class 'PerlHash'
This is, as far as I can tell, because the same register is used by IMCC
for both the READDATA and RESTOREINFO locals, thus by the time that the sub
_data gets around
At 06:57 PM 6/1/2003 +0200, Leopold Toetsch wrote:
Clinton A. Pierce [EMAIL PROTECTED] wrote:
The following code:
push_integer() not implemented in class 'PerlHash'
This is, as far as I can tell, because the same register is used by IMCC
for both the READDATA and RESTOREINFO locals,
If you want really use such constructs, you can't put them in different
compilation units, because they are basically one unit.
So a BASIC IMCC program, with all of the builtin functions it needs, plus
the actual user program itself as one compilation unit? All for the sake
of a few
If memory serves me right, Bryan C. Warnock wrote:
Reply inline ... and I've said more than I've quoted ... It could be
called as a critical appreciation ... though not much has been appreciated
below ... and what I know about parrot can be written on a shirt sleeve ;-)
Please do tell me if I've
At 12:00 PM 6/1/2003 -0600, Luke Palmer wrote:
If you use them often... then maybe one or two need a real register,
but I'd still be weary of doing that. Use find_global and its
friends.
Eureka!
Oh, find_global/set_global, where have you been all my life?
Thank you for pointing out the obvious.
Clinton A. Pierce wrote:
At 12:00 PM 6/1/2003 -0600, Luke Palmer wrote:
... Use find_global and its
Eureka!
Yep. globals are globals are globals.
eq RETURNTO, 10, CONT_10
AFAIK are these line numbers, why do you want to use strings - but I
really don't know (and will for sure not
Gopal V [EMAIL PROTECTED] wrote:
What I wanted to say was to have fixed size variables and an interpreter
specific internal notation would be ideal. And only if you wanted to
operate stuff with direct int registers.. The fixed size variables allow
the JIT to decide if we use half-a-register ,
[EMAIL PROTECTED] (Luke Palmer) writes:
It will still have a lot of power in text processing, and still be a
powerful quicky language, but that's no longer its primary focus --
not to say that highly structured programming is.
So, uh, what is?
And you can still do it the Perl 5 way in Perl
Just in case you were wondering.
Preparations for my imminent speaking tour:
http://damian.conway.org/tshirt.html
delayed it considerably, but I have had a draft of E6 complete for a few weeks
now.
Like the A6 it explains, it's big. So it's taken a few weeks for the design
team to check
Apologies if I've missed some earlier discussions on multimethods. The
apocolypses, exegesises and synopses don't seem to say much other than
(a) they will exist and (b) wait for apocolypse 12 for more information.
Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the
intent is
Apologies if I've missed some earlier discussions on multimethods. The
apocolypses, exegesises and synopses don't seem to say much other than
(a) they will exist and (b) wait for apocolypse 12 for more information.
Looking over RFC 256[*] and Class::Multimethods[**] it sounds like the
At 11:40 on 06/01/2003 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
Yep. Imcc should definitely move out off languages into its own subdir
under the top level (Not in the top level itself).
... Who should do
this? I'd be willing to help if given direction.
Moving directories
At 10:29 PM 6/1/2003 +0200, Leopold Toetsch wrote:
eq RETURNTO, 10, CONT_10
AFAIK are these line numbers, why do you want to use strings - but I
really don't know (and will for sure not learn) this language.
Because line numbers are Ancient Basic for designating branch
destinations in
CAP == Clinton A Pierce [EMAIL PROTECTED] writes:
CAP Yes, my friend. Continue to use quotes around the word language
CAP when describing this mess.
Without RETURN x, just plain old GOSUB/RETURN I could let PIR/PASM
handle all by itself with no supervision.
Or you handle
Luke Palmer [EMAIL PROTECTED] wrote:
This gives imcc a better help message, without being patronizing about
the meanings of the options (because they're clear from the long
option names). It also cleans up the option data structure in imcc
and test_main by removing the unsightly NULLs that
Josh Wilmes [EMAIL PROTECTED] wrote:
At 11:40 on 06/01/2003 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
Yep. Imcc should definitely move out off languages into its own subdir
under the top level (Not in the top level itself).
The problem is, if you're really going to do recursive
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #22455]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22455
Attached patch tests if either posix_memalign or memalign is present.
21 matches
Mail list logo
