At 11:40 AM 12/5/2001 -0800, Steve Fink wrote: >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. > >Probably the answer for the FAQ is "dunno, depends on the mental >health of whoever implements the final RE engine".
That's probably it. Matching like this will either require a potentially very large lookbehind buffer or put some serious restrictions on what can > > >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? Ah. We'll implement the full character set, named character sets, default sorting order & comparisons, utf-8, utf-16, and utf-32. Named characters will probably be available, but in a separate module not loaded by default. >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. The big question is "Will it be wrong?" Talking Unicode tends to degenerate into 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? No details at the moment. We'll probably have some sort of forked stack frame system or something. I'm not sure yet. > > >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?" Some of it won't be a pain, and we'll use it where we can. (Some of the MULTIPLICITY/PERLOBJ/threading stuff needs hacking out, but...) The bits that are dependent on the interpreter setup in perl 5 won't work, of course, but lots of, say, util.c or <insert platform here>.c will. > > >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. That's a better answer. > > >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?) I need to define this better. For programs using the embedding API (which will be small and simple) binary and source compatibility's guaranteed forever. Period. For 'plain' extensions (i.e. things that do *not* define low-level vtable entries or new ops or anything) there will be both source and binary compatibility for as long as we can manage. Hopefully forever, but breakage will be very rare. For things that access low-level things, like opcode functions and directly go at the vtable entries, we may break every point release and make no guarantees. But we'll try very hard not to. Note that the last does *not* affect extensions that define vtable-ish subs at the perl level. (Having a DESTROY sub for a class means that variables in the class will have a valid cleanup function in their vtable. The former's guaranteed to work until Larry changes the language, the latter's the direct vtable function bit that might change) >How do DESTROY subs fit in? I think you've described this elsewhere, >so this answer can just be a pointer. When a variable is noted to be dead, its DESTROY sub will be called if it has one. This might be immediately for variables that never get referenced outside their lexical scope, or when the dead object sweep finds them. > > >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? The ELF tools aren't available everywhere, and if we're going to have to write our own, we might as well make the format convenient for us. > > >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. I'll dig out the info. There are a few folks, but I've not been keeping track as it's mainly Simon's realm as Keeper Of The Source. > > >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.) Ah. I work for Northern Light Technologies (http://www.northernlight.com), one of the search engines. I work on the back end doing, well, Stuff. Perl, C, SQL, some C++, XS writing--you name it. Things run on VMS (our database servers are all running on VMS boxen), Solaris, or Win2K. (My laptop's a Win2K machine) I am not, for the record, an agent of an evil corporation intent on destroying life, liberty, or the pursuit of low perl golf scores. (I make no promises past htat) <ObPlug> We have both web pages we crawl (350M last count) and around 32M non-web docs from newspapers, magazines, news wires, and journals. We do full boolean searches--and, or, not, grouping--with relevancy ranking a touch better than google. We've got an e-mail alert system that lets you store complex searches and we send you e-mail when new docs that match the searches go into the DB. We've a very nice subject classification and heirarchy we auto-class docs into to help narrow searches. We've also got a staff of librarians that comb through the mass of docs and put together "special editions" on particular subjects like, say, http://special.northernlight.com/xml/ on XML, or http://special.northernlight.com/linux/ on linux. </ObPlug> Simon, IIRC, works on the administrative side of Cambridge University's IT department, but he'd have to fill the details (and probably proper university) in himself. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
