> Therefor I propose:
> Remove the integer-valued File-Descriptors. The ParrotIO-objects
> (wrapped in PMCs) are the only way to access IO. The
> standard-descriptors stdin/stdout/stderr can be obtained by new ops
> get_stdin (out PMC)
> get_stdout (out PMC)
> get_stderr (out PMC)
> respectivly the
After a quick reading of this, I'd have expected the value of "f" at the indicated
point to be 1, but instead it's 2.
.local int f
.sub _main
.local int x
.sub _foo1
f=1
x=2
call _foo2
end
.end
.sub _f
Sorry, the example was unnecessarily long.
> After a quick reading of this, I'd have expected the value of "f" at the indicated
> point to be 1, but instead it's 2.
.local int f
.sub _main
.local int x
.sub _foo1
f=1
x=2
call _foo2
> Yeah, I don't think you can use .local across subs like that. I think
> .local means "local to this sub" and *inner subs aren't closures*. In
> fact, I don't think inner subs are useful for much of anything at all.
The more I read, the more likely I think this is a bug. For example, the note
> The story is like this:
> - the "pseudo gloabal" declaration of C declares a variable usable in
> both subs. This was invented[1] to cover vars outside of all subs in a
> main execution stream, which is intersparsed with sub declarations, like
> a perl programm could be.
> - both subs "_foo1"
> Clint, I'm not sure which feature you mean is confusing here. I think you are
> referring to supporting .local outside of subs, and I agree with that. However,
> I think symbol tracking and scope checking is the high level language's
> responsibility so the example you provided really should not
Clarification:
running an invoke() at *any* time will cause all subsequent tracing to segfault. Thus
(pseudoPASM):
loadlib
dlfunc
invoke
trace 1
end
Will cause the segfault.
> Original Message-
> From: "Clinton A. Pierc
> First, always check the result of IO operations. If something fails,
> these return a PerlUndef, so:
> .sub _main
> fdopen $P1, 0, "r" # STDIN
> defined $I0, $P1
*Doh* Stupid Newbie Error.
> unless $I0, err
> read $S0, $P1, 255
>
> I checked in a fix for something that *may* have fixed this, but I'm
> not sure as I can't test it out at the moment. Try sync'ing up to CVS
> and giving it another whirl.
Still no luck. No luck either in getting a stack trace to the problem.
This may just be a quirk in MSVS.NET. I can't ge
Prompted by a comment in gnat's journal on use.perl.org, I present:
Parrot BASIC CGI
http://www.camfriends.org/testform.html
Let the fun begin. :)
Whoops. Needed to go to the list as well.
> Original Message-
> From: "Clinton Pierce" <[EMAIL PROTECTED]>
> To: "Dan Sugalski" <[EMAIL PROTECTED]>
> Date: Fri, Jul-4-2003 4:24 PM
> Subject: Re: [ANNOUNCE] Parrot is feature-
> > I don't have a small test case for this.
>
> Please read some threads about IO & such after my post:
>
> Subject: Timely destruction and TRACE_SYSTEM_AREAS
> Date: Thu, 26 Jun 2003 09:59:18 +0200
>
> If your are sure, that you are on a different kind of bug, then I'll
> have a closer look
>>> .sub _main
>>> fdopen $P1, 0, "r" # STDIN
>
>BTW
> fdopen $P1, 0, "<" # read STDIN
>
>>> 3. its currently only defined for PIO_OS_UNIX
>
>> Okaaay, so the plan is for this to work and I should probably code this way anyway,
>> right?
>
> You could just
> Yep a bug is here. But this bug is a BASIC compiler bug. Things that go
> into aggregates (or are stored in lex pads/global tables) are stored by
> reference. You have to clone PMCs to get independed vars:
Thanks for clearing this up. In my head I was confused between the difference in,
say,
I'm not sure whether getstd\w+ is supposed to give me a new reference or not. From
now on I'll code that portion defensively.
What I do know is that imcc -t under Win32 is crash-happy and I can't trace beyond the
first getstdin. Greatly simplified example:
.sub _main
$P0=new PerlArray
Typo!
> getstderr P3 # STDOUT
Should have been "getstdout"
Although... if left at getstderr the error also goes away. (Add that to my bullet
list.) My haven't-grokked-the-code psychic abilities tell me that "getstdout" does
something Real Bad to the stdout filehandle
16 matches
Mail list logo
