Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
Dan Sugalski wrote: 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? Hi, I have little expertise in building libraries on many platforms. But aren't these issues all addressed by GNU's 'libtool'. Is there a licensing reason for not using that? CU, Bernhard -- ** Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Addition to compiler_faq.pod
patch attached. gist: how do i manage a simple case of lexical pads? cfaq.diff Description: Binary data -sterling
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
On Wed, 12 May 2004, 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. ;-) You might want to review the patch I submitted about a year and a half ago -- it's # 18319, and it included some (but certainly not all) of your good ideas. In particular, I was careful to distinguish among three separate functions: Compiler: Used to turn .c files into .o files. Linker:Used to combine .o files (and libraries) into an executable. Shared Library Builder: Tool to turn .o files into a shared library. I called it by the Configure variable 'ld', but better names are certainly welcome. Each one of these tools needs its own set of flags. I gather parrot's now trying to include stuff compiled with C++, so you'll also need a macro for that. Furhter, if parrot's going to include stuff compiled with C++, the Linker will have to be a command that correctly handles C and C++. On Unix systems, that's probably just the C++ compiler. I don't know what it is on Windows or VMS. Regarding C++ flags, I'd hope that the C++ compiler would accept the same flags as the C compiler, but you ought to allow for the possibility of setting extra c++ -specific flags, so you'll need a macro for that too. - 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 xxx_STATIC_USE cflags and ldflags to use static parrot PARROT_STATIC_NAME full, platform dependent name of static parrot lib 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 The name of the parrot library should blend into the current system (and might even be different for debug builds, eg libparrot_g.so (is that correct?) or parrotd.lib). For perl5, the direction we went with this issue was to embed the different build information into the directory, rather than into the library name. That way, you don't have to change all the command lines that might link to parrot from -lparrot to -lparrot_g or -lparrot_64 or -lparrot_mt or -lparrot_longdouble or -lparrot_whatever. Keeping multiple versions of a parrot shared library on a system at the same time is tricky, and needs to be very carefully thought out. -- Andy Dougherty [EMAIL PROTECTED]
Re: Events (I think we need a new name)
On Wed, May 12, 2004 at 06:15:54PM +0200, K Stol wrote: | 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... | | The system sends a 'message' to the user program, telling it has | finished (for example) Disk I/O. The aged Windows API does things as 'message queues'. Windows keeps a message queue for every running application. An application calls GetMessage to retrieve each message. As I recall, each message is a triple: a message-code, a word-parameter, and a long-parameter which is often a pointer when the simple word-parameter is not sufficient. An application then can choose to pass-up on the message, leading to a default implementation by calling DispatchMessage. It can also PostMessage to add a message to a particular application/thread's event queue. SendMessage is the blocking version of PostMessage. Anyway, if this is close to what you mean by 'event', then I'd consider calling it a 'message' and lifting as must of the Windows message-queue design pattern as seems appropriate. Clark
Re: Event design sketch
On Tue, May 11, 2004 at 02:06:51PM -0400, Dan Sugalski wrote: At 1:10 PM -0400 5/11/04, Uri Guttman wrote: i don't think there is a need for all those variants. why would alarm need any special opcode when it is just a timer with a delay of abs_time - NOW? let the coder handle that and lose the extra op codes. I didn't see any reason to not do absolute times as well as deltas. It's no big deal either way. You may need the distinction later. POE's mailing list has a thread with a periodicity of about six months: What happens when daylight-saving time comes or goes? The answer: All your short-term timers fire at once if the clock moves ahead, or everything stalls for an hour (or so) when it moves back. So far the best solution requires a distinction between absolute and relative timers: Adjust the relative timers to compensate for the shift, but leave the absolute ones alone. Relative timers tend to be used for things like timeouts and periodic polling. You don't want all your TCP connections to suddenly time out when the clock jumps ahead, and you don't want your log tailers to pause an hour when it skips back. However, you usually do want your absolute-timed jobs to run when the wall clock says they should be. Something to keep in mind. -- Rocco Caputo - http://poe.perl.org/
RE: Events (I think we need a new name)
How about: tocsin toc.sin( P ) Pronunciation Key (tksn) n. An alarm sounded on a bell. A bell used to sound an alarm. A warning; an omen. -Original Message- From: Gordon Henriksen [mailto:[EMAIL PROTECTED] Sent: Thursday, May 13, 2004 2:52 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: 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] The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
RE: Events (I think we need a new name)
It seems the name 'event' is not as bad. So, maybe 'Pevent', stands for 'parrot event'? One advantage... it'd be easy searchable. I recall a pain whenever I searched for 'thread', or 'Icon'. Regards, Waldemar -Original Message- From: Dan Sugalski [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 12, 2004 6:08 PM To: [EMAIL PROTECTED] Subject: Events (I think we need a new name) 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... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Events (I think we need a new name) - Parcel?
I LOVE IT: PARrot Container for Event Lobbing!!! -Original Message- From: Andy Wardley [mailto:[EMAIL PROTECTED] Sent: Friday, May 14, 2004 7:36 AM To: Butler, Gerald Cc: 'Gordon Henriksen'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: Re: Events (I think we need a new name) - Parcel? Butler, Gerald wrote: How about: tocsin [...thinking out loud...] I'm not sure it's a good idea to use an obscure word, even if it is appropriate to the usage. It should be a word that the average user would recognise, and hopefully be able to intuit some sense of what it does. How about Parcel? Like Packet and Message it provides a sense of what it is doing. The metaphor extends to sending and receiving parcels, wrapping and unwrapping them, and so on. On a more trivial note, the first three letters make it a prime candidate for a corny acronym: PARrot Communication Event Layer PARrot Container for Event Lobbing PARrot Commissioner for Event Liaison A The information contained in this e-mail message is privileged and/or confidential and is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by telephone (330-668-5000), and destroy the original message. Thank you.
Re: Events (I think we need a new name) - Parcel?
Butler, Gerald wrote: How about: tocsin [...thinking out loud...] I'm not sure it's a good idea to use an obscure word, even if it is appropriate to the usage. It should be a word that the average user would recognise, and hopefully be able to intuit some sense of what it does. How about Parcel? Like Packet and Message it provides a sense of what it is doing. The metaphor extends to sending and receiving parcels, wrapping and unwrapping them, and so on. On a more trivial note, the first three letters make it a prime candidate for a corny acronym: PARrot Communication Event Layer PARrot Container for Event Lobbing PARrot Commissioner for Event Liaison A
RE: Events (I think we need a new name)
On Fri, 2004-05-14 at 06:27, Rachwal Waldemar-AWR001 wrote: It seems the name 'event' is not as bad. So, maybe 'Pevent', stands for 'parrot event'? One advantage... it'd be easy searchable. I recall a pain whenever I searched for 'thread', or 'Icon'. If you're talking about search engines, then of course parrot event works just fine. If you're talking about searching your code, then that's another matter. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Addition to compiler_faq.pod
At 8:58 AM -0400 5/13/04, Sterling Hughes wrote: patch attached. gist: how do i manage a simple case of lexical pads? Applied. Now to get the darned things answered... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
CALL__BUILD
Hi,
whats the plan WRT to CALL__BUILD?
I've written a patch that makes it the default, but does a fallback to
__init if no BUILD property is set. If the __init method does not exists,
no exception is thrown (like before), whereas now an exception is thrown if
you specify a BUILD property and the specified method does not exists.
A special case is if you set BUILD to an empty string, then no constructor is
called for the class, not even __init if it exists.
All tests are passing, plus two new tests for the new functionality (exception
if constructor not found and constructor disabling)
Should I apply it?
jens
Index: src/objects.c
===
RCS file: /cvs/public/parrot/src/objects.c,v
retrieving revision 1.90
diff -u -w -r1.90 objects.c
--- src/objects.c 27 Apr 2004 12:00:43 - 1.90
+++ src/objects.c 14 May 2004 15:09:34 -
@@ -482,6 +482,7 @@
void * __ptr;
} __ptr_u;
STRING *meth;
+*meth_str = NULL;
#if 0
prop = VTABLE_getprop(interpreter, class, prop_str);
if (!VTABLE_defined(interpreter, prop))
@@ -509,6 +510,7 @@
PMC *classsearch_array = get_attrib_num(class_data, PCD_ALL_PARENTS);
PMC *parent_class;
INTVAL i, nparents;
+#if 0
int free_it;
static void *what = (void*)-1;
/*
@@ -527,6 +529,7 @@
Parrot_base_vtables[enum_class_delegate]-init(interpreter, object);
}
else {
+#endif
/*
* 1) if class has a CONSTRUCT property run it on the object
*no redispatch
@@ -538,6 +541,7 @@
STRING *meth_str;
PMC *meth = get_init_meth(interpreter, class,
CONST_STRING(interpreter, CONSTRUCT), meth_str);
+ int default_meth;
if (meth) {
if (init)
Parrot_run_meth_fromc_args_save(interpreter, meth,
@@ -556,6 +560,16 @@
classsearch_array, i);
meth = get_init_meth(interpreter, parent_class,
CONST_STRING(interpreter, BUILD), meth_str);
+ /* no method found and no BUILD property set? */
+ if (!meth meth_str == NULL) {
+ /* use __init as fallback constructor method, if it exists */
+ meth_str = string_from_cstring(interpreter, __init, 6);
+ meth = Parrot_find_method_with_cache(interpreter,
+ parent_class, meth_str);
+ default_meth = 1;
+ }
+ else
+ default_meth = 0;
if (meth) {
if (init)
Parrot_run_meth_fromc_args_save(interpreter, meth,
@@ -564,9 +578,23 @@
Parrot_run_meth_fromc_save(interpreter, meth,
object, meth_str);
}
+ else if (meth_str != NULL
+ string_length(interpreter, meth_str) != 0 !default_meth) {
+ real_exception(interpreter, NULL, METH_NOT_FOUND,
+ Method '%Ss' not found, meth_str);
+ }
}
meth = get_init_meth(interpreter, class,
CONST_STRING(interpreter, BUILD), meth_str);
+ /* no method found and no BUILD property set? */
+ if (!meth meth_str == NULL) {
+ /* use __init as fallback constructor method, if it exists */
+ meth_str = string_from_cstring(interpreter, __init, 6);
+ meth = Parrot_find_method_with_cache(interpreter, class, meth_str);
+ default_meth = 1;
+ }
+ else
+ default_meth = 0;
if (meth) {
if (init)
Parrot_run_meth_fromc_args_save(interpreter, meth,
@@ -575,7 +603,14 @@
Parrot_run_meth_fromc_save(interpreter, meth,
object, meth_str);
}
+ else if (meth_str != NULL string_length(interpreter, meth_str) != 0
+ !default_meth) {
+ real_exception(interpreter, NULL, METH_NOT_FOUND,
+ Method '%Ss' not found, meth_str);
}
+#if 0
+}
+#endif
}
/*
Index: t/pmc/object-meths.t
===
RCS file: /cvs/public/parrot/t/pmc/object-meths.t,v
retrieving revision 1.17
diff -u -w -r1.17 object-meths.t
--- t/pmc/object-meths.t 10 Apr 2004 12:50:23 - 1.17
+++ t/pmc/object-meths.t 14 May 2004 15:09:35 -
@@ -16,7 +16,7 @@
=cut
-use Parrot::Test tests = 19;
+use Parrot::Test tests = 21;
use Test::More;
output_like('CODE', 'OUTPUT', callmethod - unknown method);
@@ -136,6 +136,52 @@
ok 2
OUTPUT
+output_is('CODE', 'OUTPUT', disabling the constructor);
+newclass P1, Foo
+new P0, .PerlString
+setprop P1, BUILD, P0
+find_type I1, Foo
+new P3, I1
+print ok 1\n
+end
+.namespace [Foo]
+.pcc_sub __init:
+print nok ok!\n
+invoke P1
+CODE
+ok 1
+OUTPUT
+
+output_is('CODE', 'OUTPUT', specified constructor method does not exist);
+newclass P1, Foo
+new P0, .PerlString
+set P0, bar
+setprop P1, BUILD, P0
+
+newsub P20, .Exception_Handler, _handler
+set_eh P20
+
+find_type I1, Foo
+new P3, I1
+print not ok 1\n
+end
+
+_handler:
Re: MMD stuff
On May 14, 2004, at 9:04 AM, Dan Sugalski wrote: Today's project is to get all the MMD things actually using MMD. I've put in the first wave of changes (well, OK, second if you consider Leo's BXOR test as the first) and should get the rest of the stuff in today. This part's a bit hackish but, well, there you go. It does break some of the object tests, since they don't yet participate in MMD the way they ought, but that should happen later on. It would be great to have a quick paragraph-or-two about the design/API/goals. I know what MMD is in general, but I got lost in figuring out whether this MMD is supposed to be the back-end for Perl6's multi's (I think it isn't), how it relates to PMCs and their VTABLE's, the high-level view of how it's implemented, why it's faster (than what?), what types we are dispatching on (I v. N v. S v. P, or PMC types, or Object types), how type fallbacking is done, what you have to put in a .pmc file (?) to create an MMD entry, etc. Maybe that would be more than a paragraph, but a quick paragraph would let me ask better questions. (And I saw docs/mmd.pod, but I'm looking for a higher-level overview.) Thanks, JEff
Re: MMD stuff
At 10:48 AM -0700 5/14/04, Jeff Clites wrote: On May 14, 2004, at 9:04 AM, Dan Sugalski wrote: Today's project is to get all the MMD things actually using MMD. I've put in the first wave of changes (well, OK, second if you consider Leo's BXOR test as the first) and should get the rest of the stuff in today. This part's a bit hackish but, well, there you go. It does break some of the object tests, since they don't yet participate in MMD the way they ought, but that should happen later on. It would be great to have a quick paragraph-or-two about the design/API/goals. I know what MMD is in general, but I got lost in figuring out whether this MMD is supposed to be the back-end for Perl6's multi's (I think it isn't), how it relates to PMCs and their VTABLE's, the high-level view of how it's implemented, why it's faster (than what?), what types we are dispatching on (I v. N v. S v. P, or PMC types, or Object types), how type fallbacking is done, what you have to put in a .pmc file (?) to create an MMD entry, etc. Good point. I should write up something more formal, but for the moment... This MMD stuff is only for the functions in the PMC vtable that take a PMC and a second parameter (right now only a PMC, but when we're done it'll work for any right-hand type). The goal here is to ultimately rip out all these functions from the vtable and leave them in the MMD subsystem where they really belong. Ultimately it'll be faster since nearly all the PMC classes parrot will run with will have their vtable methods call the MMD system *anyway*, so we cut out that level of indirection. PMC writing shouldn't change--the pmc preprocessor will pull out the code from it and treat any defined vtable methods that are now MMD as the default for that PMC class. At the moment there's no hierarchy and distance searching for filling in the MMD table--either there's a dead-on correct entry or there isn't. That needs fixing, though there's still the issue of deciding what the class hierarchy is, but we'll get there in a bit. -- 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)
On Thu, 13 May 2004 10:00:53 -0400 (EDT), Andrew Dougherty wrote: You might want to review the patch I submitted about a year and a half ago -- it's # 18319, and it included some (but certainly not all) of your good ideas. Thanks, I'll do that. I gather parrot's now trying to include stuff compiled with C++, so you'll also need a macro for that. Furhter, if parrot's going to include stuff compiled with C++, the Linker will have to be a command that correctly handles C and C++. On Unix systems, that's probably just the C++ compiler. I don't know what it is on Windows or VMS. IMHO, we are currently talking C only, so that shouldn't be a problem. I hope anybody tells me if I'm wrong. Still, I am curious. Why would the linker need to know about C or C++? (just didn't manage to take a grip on that thought) The name of the parrot library should blend into the current system (and might even be different for debug builds, eg libparrot_g.so (is that correct?) or parrotd.lib). For perl5, the direction we went with this issue was to embed the different build information into the directory, rather than into the library name. That way, you don't have to change all the command lines [...] Good enough for me. I'd say we stick with the regular names.
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
On Thu, 13 May 2004 17:23:18 -0700, Jeff Clites wrote: 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_LIB_STATIC_BUILD is fine with me. xxx_STATIC_USE cflags and ldflags to use static parrot How about: xxx_STATIC_LINK I was more thinking along the line of building the library (..._BUILD) and using the library (..._USE). PARROT_STATIC_NAME full, platform dependent name of static parrot lib How about: LIBPARROT_STATIC Agreed. - 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? Dan has already read my thoughts on that, and posted them. - 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. It's used to let the compiler know that the mentioned symbols are exported/imported. The two macros will probably only be used to get the PARROT_API macro, for those platforms that use it, right. Eg, Microsoft uses __declspec(dllimport) void someFunction() to let the compiler know that someFunction should be imported from a DLL. Maybe other compilers have a similar kludge. So, here's the new complete list of things. Hope you like it. Makefile CFLAGS_COMMON common compiler flags LDFLAGS_COMMONcommon linker flags CFLAGS_LIB_STATIC_BUILD cflags to build static parrot LDFLAGS_LIB_STATIC_BUILD lflags to build static parrot CFLAGS_LIB_STATIC_USE cflags to use static parrot LDFLAGS_LIB_STATIC_USElflags to use static parrot LIBPARROT_STATIC full, platform dependent name of static parrot lib CFLAGS_LIB_DYNAMIC_BUILD cflags to build dynamic parrot LDFLAGS_LIB_DYNAMIC_BUILD lflags to build dynamic parrot CFLAGS_LIB_DYNAMIC_USEcflags to use dynamic parrot LDFLAGS_LIB_DYNAMIC_USE lflags to use dynamic parrot LIBPARROT_DYNAMIC full, platform dependent name of dynamic parrot lib C PARROT_LIB_STATIC compiling for static parrot PARROT_LIB_DYNAMICcompiling for dynamic parrot PARROT_LIB_EXPORTSexport parrot symbols (compiling parrot lib) PARROT_LIB_IMPORT import parrot symbols (using parrot lib) PARROT_APIdeclare as API Ron
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
On Fri, 14 May 2004 09:11:32 +0200, Bernhard Schmalhofer wrote: I have little expertise in building libraries on many platforms. But aren't these issues all addressed by GNU's 'libtool'. Is there a licensing reason for not using that? autoconf, automake and libtool address the issues we are facing, but focus on UNIXisch operating systems. IIRC, these tools create a bunch of shell scripts, glued together by m4. I'd rather stick to something that scares me a little less. Ron
Re: PARROT_API, compiler and linker flags (was TODO: Linker magic step for configure)
Friday, May 14, 2004, 11:48:00 PM, Andy Dougherty wrote: IMHO, we are currently talking C only, so that shouldn't be a problem. I hope anybody tells me if I'm wrong. Still, I am curious. Why would the linker need to know about C or C++? I thought ICU contained some C++ files. As to why we care, you might need different libraries for c versus c++. For example, the Solaris c++ man page has this note: By default, the CC driver passes the following -l options to ld: -lC -lC_mtstubs -lm -lw -lcx -lc There are likely other issues too, but that's the first one that comes to mind. Of course, to build ICU the flags would be necessary, but we're not building it directly - we are asking it to build itself, and then we just link to the resulting library, which shouldn't need anything special. Am I getting things wrong here? Ron
