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
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
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 ar
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 loc
> >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 f
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 g
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
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-regis
[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 P
On Sun, Jun 01, 2003 at 10:44:02PM -0600, Luke Palmer wrote:
> You must not be following Perl 6 closely enough, then. Perl 6 is a
> "real" programming language now, as opposed to a "scripting" language.
Um, I've followed Perl6 closely enough to know that the distinction
between "real langauge" an
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 thro
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 t
> 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 dir
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
destinatio
> "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.
>>
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 th
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.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22455 >
Attached patch tests if either posix_memalign or memalign is present.
Additionally th
21 matches
Mail list logo
