On Wed, Dec 05, 2001 at 11:02:34AM -0500, Dan Sugalski wrote: > At 06:29 PM 12/4/2001 -0800, Steve Fink wrote: > >Q: What about incremental matching? > > A: What about it?
Is there any plan to support nonbuffered matching, as in, I have a socket connection open that I want to scan for some pattern, but the socket is never going to return an EOF. Example: NONBLOCKING_SOCKET =~ /<(.*?)>/ I read 1MB out of the socket containing "<xxxxx"... and then the socket stops producing data. I want to do a select(), or something else, and then go back to continuing the match, and I want the whole match to end up in $1. More simply, say you're just reading a huge file 8KB at a time, and you want to match <.*?> and be assured you won't miss a match because it happens to cross over an 8KB boundary. I believe there was some hot discussion on this in the perl6 RFCs. If Parrot supports coroutines, it could be hooked into that. But the RE engine might also need to say "okay, nothing before byte 13231 is going to match, so you can throw it out of memory if you want". Helps with HUGEFILE =~ /.../; Probably the answer for the FAQ is "dunno, depends on the mental health of whoever implements the final RE engine". > >Q: What degree of Unicode support is Parrot aiming for? > > A: Complete. > > >Q: What does that mean? > > A: Means that if the Unicode standard says something about it, we support > it. I know nothing about Unicode, but I thought there were levels piled upon levels of what could be done with a Unicode implementation, and nobody has ever managed to implement all of it. And aren't there choices about how to do some things? I'll shut up, because if I try to say anything like multiple code points combine to form a single whatzit, it'll end up nonsense. > >Q: Any plans for continuations? Coroutines? > > A: Maybe, and yes. (continuations are contingent on Dan understanding them, > and he doesn't. Dunno why, might be because he writes about himself in the > third person, the arrogant bastard) Er... any details on what the plans for coroutines might be? How will stack frames be handled? > >Q: Why aren't you reusing big gobs of the perl5 code? > > A: Licensing. As soon as we sort that out, we will. > > >Q: Fine. But surely some pieces could be reused? > > A: Not until the licensing's sorted out. Then it depends on whether we can. > > >Q: Oh. Why are licenses a problem? Doesn't the AL allow this sort of thing? > > A: IANAL, and I don't play one on TV, but snagging code under a licensing > scheme does sort of obligate you to follow that license. Since we don't > have one for Parrot source quite yet, I'd rather not. Hm. I need to ask that first question a different way. "Assuming the licensing problems disappear in a puff of foul-smelling smoke, what aspects of perl5 code make it a pain to reuse?" > >Q: Why do people yell at me when I send patches using // for comments? > >They're ANSI C, you know. > > A: C99, IIRC. I don't think original ANSI C accepted them, and that's all > we're requiring at the moment. ....and I would think that which exact version of ANSI C supports them is irrelevant, since the *real* target is "whatever subset of C is widely enough supported in the myriad compilers currently in use". Which probably bears some resemblance to C89 or whatever it's properly called. > >Q: What API will extension writers write to? > > A: Parrot's. More specifically, what can be relied upon for source compatibility and binary compatibility within a major version? (The currently defined PMC vtable entries for a given version?) > >Q: How will garbage collection interact with extensions? > > A: There'll be some caveats, but reasonably well. For the most part > extension writers won't have to worry much about it, and we'll document the > spots where they will. Parrot's potentially got a copying GC system, which > means that tracked buffers may move, but you'll know which calls may > allocate memory (and thus potentially cause movement). There'll be easy > access to the GC controls so you can turn GC off if you need to. > > >Q: How will finalization [or whatever the right word is] interact with > >extensions? > > A: You mean object destruction? Correctly. If you allocate a PMC within an > extension subroutine, that PMC will be considered active at least until the > end of the sub. > > >Q: What's the difference between the previous two questions? > > A: The first deals with potentially reclaiming or moving allocated memory, > the second with figuring out whether a variable is dead or not. How do DESTROY subs fit in? I think you've described this elsewhere, so this answer can just be a pointer. > >Q: In what format will Parrot files be stored? > > A: I presume you mean data files. They won't be anything special--plain > text files, or DB/DBM/[SGN]DBM, or whatever. > > If you mean parrot bytecode files, they'll be in our native format. (I meant bytecode) > >Q: Why aren't you using something like ELF as the on-disk binary format? > > A: Portability. Another topic I know little about, but what's unportable about ELF? You *can* put very platform-specific data in it, but the metadata is portable and I thought you could stuff whatever you wanted into the various sections. http://www.cs.ucdavis.edu/~haungs/paper/node17.html Perhaps the ELF tools aren't available everywhere, but will the tools for the parrot native format be significantly easier to write than ELF tools? > >Q: Who has commit privileges? Who's responsible for what? > > A: Good question. Simon and Dan, and a handful of others. Can anyone fill in the handful? Ask, maybe? I'm hoping for a breakdown by section. > >Q: How do Dan and Simon have enough time to work on this? > > A: We don't--why do you think this is taking so long? It's a serious question. I was hoping for a brief description of your day jobs. (This would be the first question people would go to when they wanted to confirm that you really are agents of evil corporations intent on destroying our life, liberty, and pursuit of lower perl golf scores.) Thanks!
