Re: [perl #22854] Incongruity in Parrot IO and/or Parrot I/O crashes on STDIN read
.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 delete the #ifdef PIO_OS_UNIX in io.ops:fdopen and see, if its working. Given Jürgen's patch to completely remove the integer file descriptors and to add the getstdin, getstdout, and getstderr I think this bug can be dropped. fdopen() isn't completely functional under Win32 (either that, or I blew the part where I expose the Unix interface) but this should take care of most fd problems in Win32. (I don't think I've *ever* seen a Windows program pass a file descriptor...) Given that, there's a possible bug in Jürgen's patch (or IMCC?). Given: .sub _main call _INIT .arg 0 call _READLINE .result $S0 print $S0 end .end .sub _INIT $P0=new PerlArray # Array of BASIC FD's getstdin $P1# traditional #0 defined $I0, $P1 unless $I0, err $P0[0]=$P1 getstdout $P1 # traditional #1, etc... $P0[1]=$P1 defined $I0, $P1 unless $I0, err store_global FDS, $P0 ret err:print Cannot get handle for STDIN end .end .sub _READLINE # string readline(int fd) saveall .param int fd find_global $P0, FDS $P1=$P0[fd] set $S0, read $S0, $P1, 255 # -- Crunch .return $S0 restoreall ret .end This produces the PASM: _main: bsr _INIT save 0 bsr _READLINE restore S0 print S0 end _INIT: new P1, 19 # .PerlArray getstdin P0 defined I0, P0 unless I0, err set P1[0], P0 getstdout P0# -- bug is here? Overwrote my P0. set P1[1], P0 store_global FDS, P1 ret err: print Cannot get handle for STDIN end _READLINE: saveall restore I0 find_global P0, FDS set P0, P0[I0] set S0, read S0, P0, 255 save S0 restoreall ret Given that I'm just taking STDIN, STDOUT, STDERR and trying to stuff them into an array, should I have to use three different registers for this in the PIR? new $P4, PerlArray getstdin $P0 getstdout $P1 getstderr $P2 $P4[0], $P0 $P4[1], $P1 $P4[2], $P2 Or should getstdin/out/err have not overwritten the Px register and given up a new one each time? Either behavior is fine, so long as we're consistant and/or documented.
Thanks for clearing up Px usage (was [perl #22854] )
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, new PerlHash which creates a brand new PerlHash and sets a Px register to that new PerlHash so I can say: $P0=new PerlHash $P1=new PerlArray $P0[foo]=$P1 $P1=new PerlArray $P0[bar]=$P2 where the PerlHash has references to two different arrays, as opposed to things like getstd(in|out|err): $P1=new PerlArray getstdin $P0 $P1[0]=$P0 getstdin $P0# Oops. $P1[1]=$P0 Where $P0 keeps getting re-used by getstdin and the same reference gets shoved into the PerlArray each time. I suppose PMC authors (or opcode authors?) should be pretty clear on whether they're re-using the same PMC or cloning up a new one.
Re: [perl #22854] Incongruity in Parrot IO and/or Parrot I/O crashes on STDIN read
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 and any later uses of it (with print?) cause segfaults.
Fw: Re: [ANNOUNCE] Parrot is feature-frozen until Wednesday
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-frozen until Wednesday It crashes rather badly in a number of spots on OS X, unfortunately. I've also noticed that we have no Win32 systems in the tinderbox. Are we building OK on Win32 anywhere? I don't have a stable/spare Win32 box to donate as tinder... but. Win32 build seems okay as of last night. One eye-catching error at the end of the build is: link -out:imcc.exe -nologo -nodefaultlib -release-machine:x86 imcparser.obj imcl exer.obj imc.obj stacks.obj symreg.obj instructions.obj cfg.obj sets.obj debug.obj optimiz er.obj pbc.obj main.obj parser_util.obj jit.obj ../../blib/lib/libparrot_s.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.l ib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib o dbccp32.lib msvcrt.lib # the chmod doesn't work here, so move imcc and make it again :-( '#' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: '#' : return code '0x1' Stop. But everything else *looks* okay. Some tests fail though. The summary is: Failed Test Status Wstat Total Fail Failed List of Failed t/op/stacks.t 2 512432 4.65% 3, 6 t/pmc/intlist.t1 256 91 11.11% 6 t/pmc/io.t 2 512 42 50.00% 3-4 t/pmc/nci.t4 1024104 40.00% 2, 6, 8, 10 t/src/manifest.t 3 768 43 75.00% 2-4 t/src/sprintf.t1 256 21 50.00% 2 10 subtests skipped. Failed 6/49 test scripts, 87.76% okay. 13/751 subtests failed, 98.27% okay. NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff' Stop. Given today's off-and-on power situation in Southeast Michigan, I have no tuits round or otherwise to dive in futher.
Re: [perl #22877] GC/Sweep errors in latest build
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. For now its just unsolved and a *bug*. I'm *sure* this is something else, and it reared its ugly head only in the last week.
Stupid Parrot Tricks
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. :)
Re: [perl #22854] Incongruity in Parrot IO and/or Parrot I/O crashes on STDIN read
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 print $S0 end err: print fdopen failed\n end .end 2. Cfdopen was disabled totally due to a wrong #ifdef 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?
Re: [perl #22706] IMCC ( Parrot) crash with -t when invoke is run
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. Pierce (via RT) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Sun, Jun-15-2003 11:06 AM Subject: [perl #22706] IMCC ( Parrot) crash with -t when invoke is run # New Ticket Created by Clinton A. Pierce # Please include the string: [perl #22706] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22706 Running imcc -t or parrot -t over an invoke instruction causes the programs to segfault. This happens under Win32. I do not have a platform independant example. .sub _win32_setup # void win32_setup(void) saveall loadlib P1, kernel32.dll dlfunc P0, P1, GetStdHandle, pi set I0, 1 set I5, -11 invoke # Will crash here. store_global kernel32, P1 store_global Win32handle, P5 restoreall ret .end
Re: Question about scoping, .local and IMCC (shorter)
The story is like this:
- the pseudo gloabal declaration of Cf 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 and _foo2 are compiled totally independent. This
implies: no usage of Cf and Cx in _foo1 do interfere, so they get
the same register - bumm.
Yuck. I was afraid of this.
If you want true variables around compilations units, please use globals
or lexicals if they are in the same lexical pad.
[1] This feature is IMHO at the boarders of imcc as the namespace
instructions is. Should the HL handle these or imcc? But if its as
confusing as your test case, I would say I'll rather not support this
inside imcc.
My vote? Rip it out completely. It's *terribly* confusing. (And sends me back to
the drawing board, at a cost of speed.)
To have a name be valid in two scopes because of a single declaration, yet have them
not related in any significant way just boggles the mind. Sort of reminiscent of a
joke intern declaration in C I saw once (IIRC):
/* This means that *every* function in here gets an
automagical auto int foo. Not the same one -- their
own. That way they don't each have to declare it. */
intern int i;
void sub1 () {
i=56; // Variable used only once
return;
}
void sub2 () {
printf(%d, i); // Danger! Use of uninitialized value!
return;
}
void sub3 () {
for(i=0; i10; i++);
}
int main(int argc, char **argv) {
sub1();
sub2();
sub3();
}
Re: Question about scoping, .local and IMCC (shorter)
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 be so big
of a deal, we should just put back the correct semantic checks for symbols.
Yes. We're agreed then. What I *thought* I had found was a way to delegate a portion
of that task downward and outward but I was wrong.
Then if a language like Perl wants a funky scope type such as local (not
to be confused with IMCC .local) then it can implement them at a higher
level.
And that's what I'm planning to do now. Fortunately I've only got two scopes at the
language level to deal with:
* a strictly lexical scope. BASIC's subs and functions; anything
not in a sub is in an implied main()
* a global scope. Anything declared with COMMON.
I got nailed trying to implement the second by being clever: push declarations
(.local) of things declared COMMON from the scope in which it's seen to an outer
encasing scope. Thus in BASIC/Perl:
# BASIC
COMMON a
sub foo ()
a=1
c=3
end sub
a=15
usedonce=0
call foo()
# Perlish equivalent
{
my $a;
sub foo {
my $c;
$a=1;
}
sub main {
my $usedonce;
$a=15;
$usedonce=0;
foo();
}
}
So when I see occurances of a, I'd look them up in the COMMON list and if they were
there, I'd simply not do the PIR declaration in the inner scope, and let the outer
declaration take care of it for me. They'd share a register and everthing would work.
Except that they don't share a register, and this doesn't work. I'll probably hack in
pads this weekend instead.
I've not been paying attention lately, but your example was the first I'd
seen using
.local outside a sub, and I don't recall writing the grammar to support
that, so I assume this was a feature Leo patched in lately.
It was there long enough to make it into P6E. *shrug* I'd only began looking at it
last month or so.
Afterthought: there aren't a lot of examples with nested .subs either. I've found two
in t/syn and they're not terribly demonstrative of their usefulness. What's
implemented there could be done without the outer .sub. *shrug*
Either option works for me:
1) We can define semantics for .local at the module (file) level, and at
the sub level, and correct the compiler so your example works
2) We generate a parse error and disallow it, but at least don't accept it
as valid code.
I trust Leo will make whichever choice for good reason, but my vote is
in for (2) because it keeps IMCC simpler.
PS: I also don't care for nested sub definitions at an intermediate language
level. They aren't real closures, so I don't see the point. Let the HL
compiler implement them.
I'm used to the concept in Macro Assemblers where I can designate registers, memory
addresses, etc... by name and those names have a particular scope. Usually this is to
a file, or to some kind of compilation unit. Thus I can mix and match (cut and paste)
bits together and either have them use the globally defined names (for special
hardware registers, etc...) or the locally defined ones.
In my mind, when I saw: 1. .local, 2. automagical register spillage in IMCC, and 3.
nested compilation units I thought I'd found Assembler Manna.
Either way: once things are decided and cast into stone, the documentation needs to be
unambiguous!
Re: Question about scoping, .local and IMCC (shorter)
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 following the example in P6E (emphasis mine): .local string hello hello=Polly want a cracker?\n print hello .sub _main hello=Hello, Polly\n print hello end .end The first line of this example, the .local directive defines a *file global variable* named hello. The main routine uses the same variable, and would give a parse error if it hadn't been defined. Polly want a cracker is never assigned to the variable and printed. This just screams bug. Aside from that, I think .local should be my mechanism to create lexically scoped names at this level anyway (they serve a different purpose than scratchpads, globals, etc...). If you're a compiler, what you probably want to do is set up a some scratchpads and put f and x in them. So the perl code: The scratchpads are a good idea, but clumsy for what I wanted to do here.
Re: ParrotIO File-Descriptors
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 macros PIO_STDIN(interpreter); PIO_STDOUT(interpreter); PIO_STDERR(interpreter); If communication with external file-descriptors is necessary then the PIO_fdopen function should be used, and the result is again a ParrotIO-object. Nice thoughts and probably the right direction. I'm a little vague on it's external interface though. What would the PMC interface look like from the PIR level? new Px, ParrotIO [... open the handle or whatever ...] set Ix, Px # Get the FD number? What about the other way around for those interfaces which require the programmer to give up the file descriptor directly, like ioctl() or fcntl()?
