Re: Yadda yadda yadda some more
On Thu, May 13, 2004 at 08:02:13AM +0100, Matthew Walton wrote: : Larry Wall wrote: : : On Wed, May 12, 2004 at 11:37:44PM +0200, Juerd wrote: : : Aaron Sherman skribis 2004-05-12 17:30 (-0400): : : I like C... I like it a LOT. In fact, I'm partial to the idea that : : it should be usable anywhere : : : : I agree. It'd make even more of my pseudo code (#perlhelp and : : perlmonks.org) valid syntax :). : : Er. Why are you guys using the subjunctive? : : Straining my brain to remember what the subjunctive is (and I only ever : learned it in German anyway), does that mean that this use of yada yada : yada is already decided on and allowed? Yes, with the proviso that it only works that way where a term is expected. (As a postfix operator it's short for C..Inf.) : If so, fantastic. Glad you like it. Larry
Re: $foo.s/foo/bar/
Aaron Sherman wrote:
Is it a special type of calling convention, e.g.:
sub s (Regex $pat, Str $replace, bool ?$i) is doublequotelike returns(Str) {
Ooh, doublequotelike sounds so much 1984.
(Moreover it doesn't describe accurately the reality, which allows to
use different delimiters for the pattern and the replacement.)
Re: $foo.s/foo/bar/
On Thu, 2004-05-13 at 04:30, Rafael Garcia-Suarez wrote:
Aaron Sherman wrote:
Is it a special type of calling convention, e.g.:
sub s (Regex $pat, Str $replace, bool ?$i) is doublequotelike returns(Str) {
Ooh, doublequotelike sounds so much 1984.
(Moreover it doesn't describe accurately the reality, which allows to
use different delimiters for the pattern and the replacement.)
Hmm... I think doublequotelike would work, as long as it were a superset
of both sets of behaviors and the object that you get is neither a Regex
nor a Str, but mutable into both (a sort of pre-parsed doublequotelike
thing) and then in this case, you could optimize the conversion of both
parameters, because you know what they'll be converted into.
For example:
role doublequotelike {
has Parser::Perl6::ProtoString $.string;
# Not sure how to say conversion to Str calls this method
method as_string() returns(Str) {...}
method as_regex() returns(Regex) {...}
}
doublequotelike.string would just contain a series of tokens (e.g.
m/\s+$pattern/ yields (literal = '\s+', interpolate = '$pattern')). In
this way, you can apply your Perl 5 or Perl 6 mode by simply deriving a
new doublequotelike class.
Is there some reason not to do that that I'm missing? Why use a macro
here when that prevents you from ever using it as a method?
More to the point, even if it is a macro, would this kind of facility be
allowed for creating a method with the same syntax exposed to the user.
Performing a regex on an object seems so common an idiom that I don't
think it's healthy to make it such a special case.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Yadda yadda yadda some more
Larry Wall wrote: On Wed, May 12, 2004 at 11:37:44PM +0200, Juerd wrote: : Aaron Sherman skribis 2004-05-12 17:30 (-0400): : I like C... I like it a LOT. In fact, I'm partial to the idea that : it should be usable anywhere : : I agree. It'd make even more of my pseudo code (#perlhelp and : perlmonks.org) valid syntax :). Er. Why are you guys using the subjunctive? Straining my brain to remember what the subjunctive is (and I only ever learned it in German anyway), does that mean that this use of yada yada yada is already decided on and allowed? If so, fantastic.
State of Affairs on Cygwin
I am finally going to teach myself C, so I should be fairly quiet for a while (i.e. no more incomprehensible ramblings of a mad man). I did want to take this chance to explain some things about where Cygwin is right now. 1. config/init/hints/cygwin.pl needs to have link = 'c++', added to it. 2. There needs to be work done to config/gen/icu.pl to allow choosing of dynamic or static linking (since only the developers release of ICU allows static linking). If using a system ICU, icudatadir should not indiscriminantly be set to '' (i.e. check if --icudatadir is set first). There should also be some notes to ensure that the .dlls are in your PATH env variable and are executable. 3. Results of make fulltest testg - all pass (Ran manually as well to force -g option) testP - all pass testC - all pass testj - trans_9-12,17-18 not ok testS - all pass testb - all pass testr - all pass src_tests - all pass I have been unable to step through the trans tests to see where they differ: $ parrot trans_9.pasm ok 1 ok 2 $ parrot trans_9.pbc ok 1 ok 2 $ parrot -j trans_9.pasm ok 1 not ok 2 $ parrot -j trans_9.pbc ok 1 not ok 2 $ parrot -d -j trans_9.pasm *** Parrot VM: Setting stack top. *** *** Parrot VM: JIT core *** *** Parrot VM: Setting up ARGV array in P5. Current argc: 1 *** 0: trans_9.pasm ok 1 not ok 2 GC dump cut $ parrot -d -j trans_9.pbc *** Parrot VM: Setting stack top. *** *** Parrot VM: JIT core *** *** Parrot VM: Setting up ARGV array in P5. Current argc: 1 *** 0: trans_9.pbc Segmentation fault (core dumped) Both threading and signals are skipped. AFAIK, there should be no OS limitation for either of these being implemented if someone feels like working on it. I will continue to do a fresh checkout each day I am gainfully employed and ensure that new stuff only makes this better and not worse. Hopefully it won't take me too long to learn C though I have been using Perl now for almost 2 years and I still feel like an infant. Cheers Joshua Gatcomb a.k.a. Limbic~Region __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861
Re: P6C: Parser Weirdness
On Wed, 12 May 2004, Larry Wall wrote: In fact, I'd go so far as to say that it's almost impossible to do recursive descent when you allow for defining new operator precedence levels on the fly as Perl 6 does. : Operator precedence can be done in : a recdescent grammar straightforwardly enough. It's a bit longwinded, : but doable. Yes, of course, it *can* be done that way. The point is you don't *want* to do that part in recursive descent, I see a terminology issue looming here. Er, what is recdescent? The dragon book and Parse::RecDescent do not seem to use the same defn. According to aho/ullman A parser that uses a set of recursive procedures to recognize its input with no backtracking is called a recursive descent parser. (p 180). Parse::RecDescent does not shy away from backtracking, and in Aho/Ullman's eyes it would be a top-down parser, but not recdescent. As usual, I may have missed something. I am not sure which of the two you mean, but I feel it is the Parse::RecDescent sense because it is powerful and easier for users (and does not require recomputing the parsing table), but it is also (much?) slower. Or, of course, you may mean both. When a program uses a lot of evals then it may be worthwhile when compiling the program to calculate the parse-tables and other no-backtracking book-keeping so that the eval's happen faster at runtime. Larry --abhijit
Re: P6C: Parser Weirdness
On Thu, May 13, 2004 at 10:26:32AM -0500, Abhijit A. Mahabal wrote: : : On Wed, 12 May 2004, Larry Wall wrote: : : In fact, I'd go so far as to say that it's almost impossible to do : recursive descent when you allow for defining new operator precedence : levels on the fly as Perl 6 does. : : : Operator precedence can be done in : : a recdescent grammar straightforwardly enough. It's a bit longwinded, : : but doable. : : Yes, of course, it *can* be done that way. The point is you don't : *want* to do that part in recursive descent, : : I see a terminology issue looming here. Er, what is recdescent? The dragon : book and Parse::RecDescent do not seem to use the same defn. According to : aho/ullman A parser that uses a set of recursive procedures to recognize : its input with no backtracking is called a recursive descent parser. (p : 180). Parse::RecDescent does not shy away from backtracking, and in : Aho/Ullman's eyes it would be a top-down parser, but not recdescent. Well, I think the dragon book does violence to the language here. In plain terms, a top-down parser descends by definition, and typically uses recursion to do so, even if that recursion is emulated. Whether it also supports backtracking is somewhat orthogonal. sermon As with many CS offerings from the Modern era, the dragon book unconsciously tends to try to classify implementations into pure and impure, so one feels discouraged from using techniques like backtracking or hybrid compilers. In this Postmodern era, we tend to value whatever tickles our fancy, and it happens that computers are getting fast enough that parsing doesn't always have to be optimized to death for speed. Instead, we can occasionally optimize for other things like fun and flexibility. And that's what Perl 6 is aiming for. /sermon : As usual, I may have missed something. I am not sure which of the two you : mean, but I feel it is the Parse::RecDescent sense because it is powerful : and easier for users (and does not require recomputing the parsing table), : but it is also (much?) slower. We mean it in the more general sense. Whether a grammar can be parsed with or without backtracking depends on how you write the grammar, unless you happen to have a language with no dangling syntax. We try to avoid dangling syntax in Perl, but don't always succeed. Nevertheless, if the grammar *usually* doesn't need to backtrack, it can effectively be just about as fast as a non-backtracking grammar. Plus there are tricks you can do short of analyzing all the rules into a state diagram. For instance, the design of Perl 6 rules allows you to pass in a parameter that could supply a list of stoppers to a subrule so it knows where to stop, just as you might do in a standard recursive descent parser. : Or, of course, you may mean both. When a program uses a lot of evals then : it may be worthwhile when compiling the program to calculate the : parse-tables and other no-backtracking book-keeping so that the eval's : happen faster at runtime. Hmm, well, there's something to be said for discouraging people from using Ceval by making it slow. :-) Larry
Re: P6C: Parser Weirdness
At 9:35 AM -0700 5/13/04, Larry Wall wrote: On Thu, May 13, 2004 at 10:26:32AM -0500, Abhijit A. Mahabal wrote: : : On Wed, 12 May 2004, Larry Wall wrote: : : In fact, I'd go so far as to say that it's almost impossible to do : recursive descent when you allow for defining new operator precedence : levels on the fly as Perl 6 does. : : : Operator precedence can be done in : : a recdescent grammar straightforwardly enough. It's a bit longwinded, : : but doable. : : Yes, of course, it *can* be done that way. The point is you don't : *want* to do that part in recursive descent, : : I see a terminology issue looming here. Er, what is recdescent? The dragon : book and Parse::RecDescent do not seem to use the same defn. According to : aho/ullman A parser that uses a set of recursive procedures to recognize : its input with no backtracking is called a recursive descent parser. (p : 180). Parse::RecDescent does not shy away from backtracking, and in : Aho/Ullman's eyes it would be a top-down parser, but not recdescent. Well, I think the dragon book does violence to the language here. And personally I'd be happy to do violence to the dragon book. (Not that it's *entirely* horrible, as I occasionally need to prop doors open or shim a broken table leg temporarily...) But, anyway, snipping out the rest of this stuff... The big problem is that I don't know *how* to implement a mixed-type parser generator. I'm not big on parsers in general, so I'm mostly stuck with the literature if I need to write one from scratch. Since you've been itching to get into the internals anyway, this'd be a good place to start, y'know. :-P -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
experimental.ops
On Wednesday 12 May 2004 22:16, Leopold Toetsch wrote: We still need to consider what's an opcode and what not. We are going to blow reasonable code size soon. Yes. Thats why I've added them to experimental.ops and not to math.ops I'll add a note that it contains ops for that no decision is made whether they stay as ops or not. jens
Re: Events (I think we need a new name)
Dan Sugalski wrote: Okay, so I'm working on redoing the events document based on the critiques from folks so far. (Which have been quite helpful) I should have a second draft of the thing soon. It does, though, sound like we might want an alternate name for this stuff. While event is the right thing in some places it isn't in others (like the whole attribute/property mess) we may be well-served choosing another name. I'm open to suggestions here... Page? It's overloaded, but only in ways that should be context-disambaguatable. AFAIK it has no similar meaning in a technical sense, but does in a lay sense (it's what you get over the PA system, or on your pager). When you're the boss, you can say read this file for me, and send me a page as soon as you're done. When you're the grunt, you get paged whenever somebody wants you to do something. When you've really p... annoyed somebody, they might send you a page every 3 minutes, on the dot. You can send pages, you can receive them. Sometimes they're solicited, and you know they're comming. You can even ask for a wake-up page. Oh, and if your pager is set to vibrate, and you aren't wearing it, you need to check every so often, or you'll miss pages. -=- James Mastros
Re: P6C: Parser Weirdness
Dan Sugalski writes: And personally I'd be happy to do violence to the dragon book. (Not that it's *entirely* horrible, as I occasionally need to prop doors open or shim a broken table leg temporarily...) But, anyway, snipping out the rest of this stuff... The big problem is that I don't know *how* to implement a mixed-type parser generator. I'm not big on parsers in general, so I'm mostly stuck with the literature if I need to write one from scratch. Since you've been itching to get into the internals anyway, this'd be a good place to start, y'know. :-P I'd be happy to draft out a model and do a first run implementation in a little while. I'm definitely a parsophile. I've actually been pondering a Perl 5 alternative to P::RD that doesn't become painfully slow once things get complex enough. Pushing that in Parrot would be even better though. Luke
Re: P6C: Parser Weirdness
On Thu, 13 May 2004, Dan Sugalski wrote:
The big problem is that I don't know *how* to implement a mixed-type
parser generator. I'm not big on parsers in general, so I'm mostly
stuck with the literature if I need to write one from scratch.
I have been thinking the following about what larry said earlier. Is this
what you meant, larry?
$grammar = q{
class_defn: class block .. etc (normal top-down stuff)
...
term: { call Parse::Yapp or something }
}
What I mean by that weird pseudocode is that everything happens in a
parse-recdescent parser, except that the production of some non-terminals
calls into a bottom-up parser. That part seems trivially doable. What I
need to figure out is how the bottom-up parser can relinquish control to
the top-down parser if it hits a block or such.
A preliminary thought: A traditional bottom-up parser can take the four
actions shift, reduce, accept, and error. We will need a fifth: call the
top down parser. I have not thought through how that happens or if it can
be done at all. It is the only way that I currently see.
I think I'll try to coax Parse::Recdescent and Parse::Yapp to work
together. I have never used the latter, but the documentation seems to
suggest that it can do what Bison can. Or maybe I should write two small
parsers by hand (one recdescent and the other an operator precedence
shift/reduce) and make them be nice to each other.
--abhijit
Re: Events (I think we need a new name)
All~ I think Page already has a different meaning in computers, namely a page of memory. This one might be going to far afield for names. For what it is worth, I support event as the name. Matt James Mastros wrote: Dan Sugalski wrote: Okay, so I'm working on redoing the events document based on the critiques from folks so far. (Which have been quite helpful) I should have a second draft of the thing soon. It does, though, sound like we might want an alternate name for this stuff. While event is the right thing in some places it isn't in others (like the whole attribute/property mess) we may be well-served choosing another name. I'm open to suggestions here... Page? It's overloaded, but only in ways that should be context-disambaguatable. AFAIK it has no similar meaning in a technical sense, but does in a lay sense (it's what you get over the PA system, or on your pager). When you're the boss, you can say read this file for me, and send me a page as soon as you're done. When you're the grunt, you get paged whenever somebody wants you to do something. When you've really p... annoyed somebody, they might send you a page every 3 minutes, on the dot. You can send pages, you can receive them. Sometimes they're solicited, and you know they're comming. You can even ask for a wake-up page. Oh, and if your pager is set to vibrate, and you aren't wearing it, you need to check every so often, or you'll miss pages. -=- James Mastros
RE: Events (I think we need a new name)
Matt Fowles wrote: I think Page already has a different meaning in computers, namely a page of memory. Not to mention a web page. For what it is worth, I support event as the name. Being as I think I'm largely responsible for the sense that the name needs to be changed, I should point out that I do actually support calling these events--so long as they're modified to play nice with OS event loops. Upon reflection, that just requires a means to synchronously dispatch an event to a handler chain from a C callback. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
Re: P6C: Parser Weirdness
On Thu, May 13, 2004 at 01:01:12PM -0500, Abhijit A. Mahabal wrote:
: I have been thinking the following about what larry said earlier. Is this
: what you meant, larry?
:
: $grammar = q{
: class_defn: class block .. etc (normal top-down stuff)
: ...
: term: { call Parse::Yapp or something }
: }
Er, I've never used Parse::Yapp, so I couldn't say. I'd tend to roll
my own operator precedence parser anyway.
: What I mean by that weird pseudocode is that everything happens in a
: parse-recdescent parser, except that the production of some non-terminals
: calls into a bottom-up parser. That part seems trivially doable. What I
: need to figure out is how the bottom-up parser can relinquish control to
: the top-down parser if it hits a block or such.
The bottom up parser doesn't know that it is relinquishing control. It
has to have some kind of tokener/lexer, and that lexer recognizes that it
has a complex term that needs a subparser, calls the parser, and then
returns the subparse as a single token to the bottom-up engine.
: A preliminary thought: A traditional bottom-up parser can take the four
: actions shift, reduce, accept, and error. We will need a fifth: call the
: top down parser. I have not thought through how that happens or if it can
: be done at all. It is the only way that I currently see.
No, you still have the four basic actions. Subparsing is all hidden in
the lexer. As far as the parse is concerned, it's processing a single
token that happens to be something complicated. The only complicated
thing is making sure that all the constructs sub-parsed by the lexer
know when they should terminate. That's trivially easy for bracketed
constructs like blocks. Things get a little tricker for things like
unparenthesized list operators that have to be treated like a left
parenthesis that has no corresponding right parenthesis. Things like
semicolon will be slightly context sensitive: outside brackets, they
terminate the current statement, while inside brackets, they separate
slice terms.
And, of course, the lexer has to be sensitive to whether we're currently
expecting a term or an operator...
: I think I'll try to coax Parse::Recdescent and Parse::Yapp to work
: together. I have never used the latter, but the documentation seems to
: suggest that it can do what Bison can. Or maybe I should write two small
: parsers by hand (one recdescent and the other an operator precedence
: shift/reduce) and make them be nice to each other.
I'd take the latter approach myself, since in any event it will
probably need tweaks that are foreign to whatever tool you choose.
In particular, the fact that Perl 6 uses string comparison rather than
numeric comparison to do precedence levels is going to give almost
any standard tool a hissyfit. (We do that so that the user never has
to specify a precedence level--all levels are specified relative to
an existing operator's precedence level. And with strings, we can
fit as many new precedence levels into the interstices as the user
likes without ever running out of numeric precision.)
Larry
Re: P6C: Parser Weirdness
At 12:22 PM -0700 5/13/04, Larry Wall wrote: I'd take the latter approach myself, since in any event it will probably need tweaks that are foreign to whatever tool you choose. In particular, the fact that Perl 6 uses string comparison rather than numeric comparison to do precedence levels is going to give almost any standard tool a hissyfit. (We do that so that the user never has to specify a precedence level--all levels are specified relative to an existing operator's precedence level. And with strings, we can fit as many new precedence levels into the interstices as the user likes without ever running out of numeric precision.) I think the prudent thing to do there, since we're going to very rarely be adding new operators, is to assign the darned things real precedence numbers which get dynamically set. Add a new operator between two others and everything gets renumbered. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: P6C: Parser Weirdness
On Thu, May 13, 2004 at 03:27:43PM -0400, Dan Sugalski wrote: : I think the prudent thing to do there, since we're going to very : rarely be adding new operators, is to assign the darned things real : precedence numbers which get dynamically set. Add a new operator : between two others and everything gets renumbered. I think that's the hard way. Larry
Re: P6C: Parser Weirdness
On Thu, May 13, 2004 at 12:22:09PM -0700, Larry Wall wrote: No, you still have the four basic actions. Subparsing is all hidden in the lexer. Hence why the lexer in Perl 5 is 8000 lines long ;-) -- Wesley Crusher gets beaten up by his classmates for being a smarmy git, and consequently has a go at making some friends of his own age for a change. -- Things That Never Happen in Star Trek #18
Re: P6C: Parser Weirdness
On Thu, May 13, 2004 at 09:41:54PM +0100, Dave Mitchell wrote: : On Thu, May 13, 2004 at 12:22:09PM -0700, Larry Wall wrote: : No, you still have the four basic actions. Subparsing is all hidden in : the lexer. : : Hence why the lexer in Perl 5 is 8000 lines long ;-) Well, actually, the lexer in Perl 5 manages to be that long without ever calling back into a subparser. Everything ends up bubbling back out to the main yacc grammar, albeit highly transmogrified in the case of literal strings. How Perl 5 does two-pass string processing is one really good reason we're not doing it that way in Perl 6... :-) Larry
Re: Events (I think we need a new name)
On 12 May 2004, at 17:38, Brent 'Dax' Royal-Gordon wrote: It's Parrot telling you that something happened. Squawk? Mike
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
On May 12, 2004, at 1:26 PM, Ron Blaschke wrote: I have finally sorted out the details of the flags stuff, which I will present below. Any comments are highly appreciated. Be warned: I am going to implements this if there are no objections. ;-) - Targets shared and static are provided, to build a shared or static parrot library. - The following macros will be provided in the Makefile CFLAGS_COMMON common compiler flags LDFLAGS_COMMON common linker flags xxx_STATIC_BUILDcflags and ldflags to build static parrot We should make it clear that we are talking about building a static lib (to distinguish from what the next macro is intended for)--so how about: xxx_STATIC_LIB_BUILD or xxx_LIB_STATIC_BUILD (I'm worried that xxx_STATIC_BUILD by itself isn't clear.) xxx_STATIC_USE cflags and ldflags to use static parrot How about: xxx_STATIC_LINK PARROT_STATIC_NAME full, platform dependent name of static parrot lib How about: LIBPARROT_STATIC (That's LIB to make it clear that this is the lib and not the executable-linked-statically, and name is kind of implied.) xxx_DYNAMIC_BUILD cflags and ldflags to build shared parrot xxx_DYNAMIC_USE cflags and ldflags to use shared parrot PARROT_DYNAMIC_NAME full, platform dependent name of dynamic parrot lib As above. LDFLAGS_DYNAMIC_USE should contain -lparrot or parrot.lib, or whatever necessary, so no need to use PARROT_xxx_NAME to specify linkage USE seems odd to me, though I don't right of have an alternative which is clear. - When building / using a shared parrot the compiler macro PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC What will these be used for? Traditionally, there aren't compile-time difference when building a static v. dynamic library, I believe. Maybe this is not the case for Windows? - When building parrot the compiler macro PARROT_LIB_EXPORTS will be defined, when using parrot PARROT_LIB_IMPORTS Again, for what use? I'm not against these last 2 sets of macros--just wondering what the intended use is. - Symbols that should be exported are declared as PARROT_API some_function The include files will be grepped for them, and stored in a file xxx_api (even on platforms that don't need it). It will look something like this: Alternatively, we could just parse embed.h -- all and only symbols defined there should be exported. (I believe that's the plan.) JEff
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
Jeff Clites wrote: Alternatively, we could just parse embed.h -- all and only symbols defined there should be exported. (I believe that's the plan.) Nope. Any symbol in a file included from embed.h and outside of an #if defined(PARROT_IN_CORE) is fair game for embedders. See interpreter.h for an example of such a file. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
On Thu, 13 May 2004, Jeff Clites wrote: - When building / using a shared parrot the compiler macro PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC What will these be used for? Traditionally, there aren't compile-time difference when building a static v. dynamic library, I believe. Maybe this is not the case for Windows? if you're building a shared library, you need to compiler to produce position independent (relocatable) code, which can be enabled with compiler switches (e.g. -fPIC). -jeff
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
At 5:47 PM -0700 5/13/04, Brent 'Dax' Royal-Gordon wrote: Jeff Clites wrote: Alternatively, we could just parse embed.h -- all and only symbols defined there should be exported. (I believe that's the plan.) Nope. Any symbol in a file included from embed.h and outside of an #if defined(PARROT_IN_CORE) is fair game for embedders. See interpreter.h for an example of such a file. Well... sorta. In addition to the symbols we export for embedders, we need to export symbols that PMC classes, extensions, and opcode libraries may need. (Appropriately prefixed, of course) Anything that can be dynamically loaded needs to have its parrot symbols available. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
At 5:23 PM -0700 5/13/04, Jeff Clites wrote: [Most commentary snipped, as it's dead-on] - When building / using a shared parrot the compiler macro PARROT_LIB_DYNAMIC will be defined, for static PARROT_LIB_STATIC What will these be used for? Traditionally, there aren't compile-time difference when building a static v. dynamic library, I believe. Maybe this is not the case for Windows? Well, there's the potential for -PIC and a few other things you might want on for dynamic libraries that you wouldn't for static ones, though I expect that on most platforms there won't be a difference. Can't hurt to have them split out to start with. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
