I decide to lay out warnings I get while building Parrot.
this might be Leo's property:
packfile.c(1225) : warning C4700: local variable 'num_segs' used without
having been initialized
And this, to learn from Simon, is Brent's one
spf_render.c(578) : warning C4761: integral size mismatch in argum
This patches touches 22 files and deals with
-DHAVE_COMPUTED_GOTO
-DHAS_JIT
-DGC_IS_MALLOC
prefixing.diff
Description: Binary data
On Sat, 16 Aug 2003, Sean O'Rourke wrote:
> Michal Wallace <[EMAIL PROTECTED]> writes:
>
> > Tadaa!
>
> /me blinks at the list comprehensions.
:)
> Cool stuff. test_microthreads failed for
> some reason I still need to look into, but
> there's a lot of cool stuff working
> already. Time f
Michal Wallace <[EMAIL PROTECTED]> writes:
> Tadaa!
/me blinks at the list comprehensions.
Cool stuff. test_microthreads failed for
some reason I still need to look into, but
there's a lot of cool stuff working
already. Time for Dan to begin thinking
about which direction the pie will fly.
/s
Tadaa!
Okay. I've done (almost) everything I can
do for python without jumping into C.
So here's a release!
http://pirate.tangentcode.com/
Check out the generator-based microthreads
demo. :) It's horribly slow, but it works!
And note the PARROT_INLINE function - a
nice little touch, I thou
On Sat, 16 Aug 2003, Sean O'Rourke wrote:
> Michal Wallace <[EMAIL PROTECTED]> writes:
> > I expected getprop to behave like find_lex
> > and throw an exception if the property doesn't
> > exist, but it doesn't:
>
> Are you sure that properties are what you want to use
> here, rather than attribu
At 6:06 PM +0200 8/16/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 11:58 PM +0200 8/15/03, Leopold Toetsch wrote:
What is that? I'd tossed all (hopefully) of the math, boolean, and
logical keyed vtables,
Ah yes - docu needs updating, but Dan didn't put his "yes agreed" un
Michal Wallace <[EMAIL PROTECTED]> writes:
> I expected getprop to behave like find_lex
> and throw an exception if the property doesn't
> exist, but it doesn't:
Are you sure that properties are what you want to use
here, rather than attributes (via get_pmc_keyed() or
similar)? IIRC parrot's prop
I expected getprop to behave like find_lex
and throw an exception if the property doesn't
exist, but it doesn't:
.sub _main
.local object Class
.local object setv
.local object getv
Class = new ParrotClass
setv = new PerlString
setv = "value\n"
setprop Class, "name", setv #
On Sat, 16 Aug 2003, Leopold Toetsch wrote:
> I have put in scratchpad_delete
>
> peek_pad P0
> delete P0["foo"]
>
> deletes names only.
Thanks! works great!
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-
contact: [EMAIL PROTECTED]
hosting:
At 5:36 PM -0400 8/15/03, Gordon Henriksen wrote:
Is the RISC design philosophy not useful
when applied to a JITted virtual machine?
Skipping all the rest...
No. It isn't, and JITting doesn't have anything to do with this. The
issue is expressable semantics, and in languages with active data
(wh
Leopold Toetsch wrote:
Michal Wallace <[EMAIL PROTECTED]> wrote:
Uh-oh. I just went to implement "del x"
and there's no op to remove a variable
This needs delete_keyed() in scratchpad.pmc to be implemented.
I have put in scratchpad_delete
peek_pad P0
delete P0["foo"]
deletes names only.
It seems that exception handlers get tied to
subroutines when they're created, not when
they're actually used. For example:
## this works:
try:
f = make_function()
f.die() # raise some error
except:
pass
## this does not work:
f = make_function()
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:58 PM +0200 8/15/03, Leopold Toetsch wrote:
>>What is that? I'd tossed all (hopefully) of the math, boolean, and
>>logical keyed vtables,
>>Ah yes - docu needs updating, but Dan didn't put his "yes agreed" under
>>these patches, yet ;-)
> Right, bec
Michal Wallace <[EMAIL PROTECTED]> wrote:
> Uh-oh. I just went to implement "del x"
> and there's no op to remove a variable
> from a lexical pad! :)
new_pad P0
...
delete P0["foo"]
This needs delete_keyed() in scratchpad.pmc to be implemented.
> Sincerely,
>
> Michal J Wallace
leo
With this patch, the major pieces are finished
...
load_bytecode "temp.imc"
$P0 = global "_sub2"
.pcc_begin prototyped
.pcc_call $P0
does what it look's like: call the Sub "_sub2" in the loaded sorce file.
C looks for a registered compiler of type
"FILE". This compiler then compiles
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> which isn't quite correct. The stdio PMCs should better live somewhere
>> in the interpreter globals and being marked (as long as the streams are
>> open).
> This is what currently happens in function Pa
At 11:58 PM +0200 8/15/03, Leopold Toetsch wrote:
Togos <[EMAIL PROTECTED]> wrote:
... a bit strange that there is a keyed version
of 'add', anyway.
What is that? I'd tossed all (hopefully) of the math, boolean, and
logical keyed vtables, for which we never want to have opcodes. Did I
miss one?
Luke Palmer <[EMAIL PROTECTED]> wrote:
> How does one call a parrot Sub from C and get the return value(s)? Is
> it even possible, given CPS, to do this generally? If not, how can I
> check when it is?
Good question. Its very similar to classes/Eval.pmc:invoke().
You would do:
- call runops_int(
I said:
> But shouldn't .pcc_begin_yield and .pcc_end_yield
> do "saveall" and "restoreall", respectively?
>
> Is there a case where we wouldn't want this?
Yes, because for python anyway, I also need to
put pop_pad in there:
saveall
pop_pad
.pcc_begin_yield
.return whatever
.pcc_en
Just tried out Kenneth Grave's yield stuff --
it works great!
But shouldn't .pcc_begin_yield and .pcc_end_yield
do "saveall" and "restoreall", respectively?
Is there a case where we wouldn't want this?
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
> In interpreter.c a call to build_asm is protected by
> #ifdef JIT_CAPABLE.
> When compiling with --jitcapable=0 JIT_CAPABLE is defined to 0. So the
> #ifdef will be true. Changing this into #if gets it back to compile
Thanks, applied.
> As far as I ca
JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
> There is a void * to functionpointer assignment in dynext.c
I have put in a cast with the correct func prototype, the patch just
gave me a warning.
Thanks,
leo
Uh-oh. I just went to implement "del x"
and there's no op to remove a variable
from a lexical pad! :)
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-
contact: [EMAIL PROTECTED]
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
---
Index: classes/parrotio.pmc
===
RCS file: /cvs/public/parrot/classes/parrotio.pmc,v
retrieving revision 1.6
diff -u -r1.6 parrotio.pmc
--- classes/parrotio.pmc 30 Jul 2003 14:59:48 - 1.6
+++ classes/parrotio.pmc 16 Aug 2003 12:31:5
Andy Bussey <[EMAIL PROTECTED]> wrote:
> Here's a revised patch to add the IMCC tests
> to 'make test' and 'make fulltest' - this time
> patched against root.in.
Thanks, applied.
Plus: print CFLAS once plus more fun
> Cheers,
> Andy Bussey
leo
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #23340]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23340 >
There is a void * to functionpointer assignment in dynext.c
-- attachment 1 ---
On Fri, 15 Aug 2003, Leopold Toetsch wrote:
> PS: have a look at the rather new C opcode in PIR ;-)
Cool! :)
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-
contact: [EMAIL PROTECTED]
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #23339]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23339 >
In interpreter.c a call to build_asm is protected by
#ifdef JIT_CAPABLE.
When compil
Kenneth A Graves <[EMAIL PROTECTED]> wrote:
> I know it's less than a day old, but I thought I'd point it out. If
> there's more than one sub in the packfile, then global has difficulty
> finding the right one.
Ah yes, thanks. Fixed (offsets are in opcode_t not in bytes ;-)
Test patch applied,
# New Ticket Created by Kenneth A Graves
# Please include the string: [perl #23337]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=23337 >
I know it's less than a day old, but I thought I'd point it out. If
there's more th
31 matches
Mail list logo