Re: apr_ function prefixes
Jeff Trawick <[EMAIL PROTECTED]> writes: > Garrett Rooney <[EMAIL PROTECTED]> writes: > > > on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put > > and apr_os_thread_put. i assume that's wrong, since i can't for the > > life of me figure out what pupt would mean ;-) > > good for you > > if sleeping child cooperates I'll fix it up Real Soon Now... well, all I got was cvs not-up-to-date messages :) mailing list delays are no fun... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: apr_ function prefixes
On Thu, Feb 08, 2001 at 02:44:08PM -0800, [EMAIL PROTECTED] wrote: > > > On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote: > > > > > >> It looks like Greg has taken care of Subversion, but did anyone else see > > >> Doug's commit message go by or did my mailer drop it on the floor? > > > > > > i committed at the top-level and it mailed the diff for everything to > > > [EMAIL PROTECTED] > > > > Urgh. Guess it's time for me to subscribe to a new list. > > > > :) > > I'm trying to figure out how to make CVS send mail to the right > repository, even if the commit is from a higher directory. Tough problem. And you better know your Perl :-) Do you intend to create multiple messages, or just send the same one to (all) mailing lists? Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
> > On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote: > > > >> It looks like Greg has taken care of Subversion, but did anyone else see > >> Doug's commit message go by or did my mailer drop it on the floor? > > > > i committed at the top-level and it mailed the diff for everything to > > [EMAIL PROTECTED] > > Urgh. Guess it's time for me to subscribe to a new list. > > :) I'm trying to figure out how to make CVS send mail to the right repository, even if the commit is from a higher directory. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: apr_ function prefixes
On Thu, Feb 08, 2001 at 09:10:48AM -0600, B. W. Fitzpatrick wrote: > On Thursday, February 8, 2001, at 12:59 AM, Doug MacEachern wrote: >... > > sure: > > http://apr.apache.org/~dougm/apr_rename.pl > > > > quick-n-dirty, but seems to work ok. > > It looks like Greg has taken care of Subversion, but did anyone else see > Doug's commit message go by or did my mailer drop it on the floor? I deleted the thing (it was over 800k). I'm not sure which mail list it was sent to, but it probably went to the httpd-2.0-cvs mailing list rather than APR's list. The other alternative (which I'd doubt) is that your mail system rejected it due to size. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
Garrett Rooney <[EMAIL PROTECTED]> writes: > on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put > and apr_os_thread_put. i assume that's wrong, since i can't for the > life of me figure out what pupt would mean ;-) good for you if sleeping child cooperates I'll fix it up Real Soon Now... $ grep pupt `find . -name '*.h'` ./srclib/apr/include/apr_portable.h: * @deffunc apr_status_t apr_os_exp_time_pupt(apr_exploded_time_t *aprtime, apr_os_exp_time_t **ostime, apr_pool_t *cont) ./srclib/apr/include/apr_portable.h:APR_DECLARE(apr_status_t) apr_os_exp_time_pupt(apr_exploded_time_t *aprtime, ./srclib/apr/include/apr_portable.h: * @deffunc apr_status_t apr_os_thread_pupt(apr_thread_t **thd, apr_os_thread_t *thethd, ./srclib/apr/include/apr_portable.h:APR_DECLARE(apr_status_t) apr_os_thread_pupt(apr_thread_t **thd, $ grep pupt `find . -name '*.c'` ./server/exports.c:const void *ap_hack_apr_os_exp_time_pupt = (const void *)apr_os_exp_time_pupt; ./server/exports.c:const void *ap_hack_apr_os_thread_pupt = (const void *)apr_os_thread_pupt; ./srclib/apr/threadproc/beos/thread.c:apr_status_t apr_os_thread_pupt(apr_thread_t **thd, apr_os_thread_t *thethd, ./srclib/apr/threadproc/unix/thread.c:apr_status_t apr_os_thread_pupt(apr_thread_t **thd, apr_os_thread_t *thethd, ./srclib/apr/threadproc/win32/thread.c:APR_DECLARE(apr_status_t) apr_os_thread_pupt(apr_thread_t **thd, ./srclib/apr/time/unix/time.c:apr_status_t apr_os_exp_time_pupt(apr_exploded_time_t *aprtime, ./srclib/apr/time/win32/time.c:APR_DECLARE(apr_status_t) apr_os_exp_time_pupt(apr_exploded_time_t *aprtime, -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: apr_ function prefixes
On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote: > Urgh. Guess it's time for me to subscribe to a new list. i probably should have done two commits, the apr tree then httpd-2.0
Re: apr_ function prefixes
On Thursday, February 8, 2001, at 10:36 AM, Doug MacEachern wrote: On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote: It looks like Greg has taken care of Subversion, but did anyone else see Doug's commit message go by or did my mailer drop it on the floor? i committed at the top-level and it mailed the diff for everything to [EMAIL PROTECTED] Urgh. Guess it's time for me to subscribe to a new list. :) -Fitz
Re: apr_ function prefixes
On Thu, 8 Feb 2001, B. W. Fitzpatrick wrote: > It looks like Greg has taken care of Subversion, but did anyone else see > Doug's commit message go by or did my mailer drop it on the floor? i committed at the top-level and it mailed the diff for everything to [EMAIL PROTECTED]
Re: apr_ function prefixes
On Thu, 8 Feb 2001, Garrett Rooney wrote: > on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put > and apr_os_thread_put. i assume that's wrong, since i can't for the > life of me figure out what pupt would mean ;-) whoops! you're right, i'll fix that and pupt the changes back in cvs.
Re: apr_ function prefixes
On Thursday, February 8, 2001, at 12:59 AM, Doug MacEachern wrote: On Wed, 7 Feb 2001, B. W. Fitzpatrick wrote: +1. Wow that looks great. A toast to consistency! i'll drink to that :) Is there any way you could forward along the conversion script that you used (Or is that the one you sent last week)? This is going to break Subversion a bit, and maybe I (or Greg) can get those changes in and committed first thing in the morning. sure: http://apr.apache.org/~dougm/apr_rename.pl quick-n-dirty, but seems to work ok. It looks like Greg has taken care of Subversion, but did anyone else see Doug's commit message go by or did my mailer drop it on the floor? -Fitz
Re: apr_ function prefixes
On Wed, Feb 07, 2001 at 10:59:47PM -0800, Doug MacEachern wrote: > On Wed, 7 Feb 2001, B. W. Fitzpatrick wrote: > > > +1. Wow that looks great. A toast to consistency! > > i'll drink to that :) > > > Is there any way you could forward along the conversion script that you > > used (Or is that the one you sent last week)? This is going to break > > Subversion a bit, and maybe I (or Greg) can get those changes in and > > committed first thing in the morning. > > sure: > http://apr.apache.org/~dougm/apr_rename.pl i'm not entirely sure, since i'm not too familiar with apr, and i don't have the time to go through and check right now, but your script looks like it has a few typos. on lines 278 and 283 you replace put with pupt for apr_os_exp_time_put and apr_os_thread_put. i assume that's wrong, since i can't for the life of me figure out what pupt would mean ;-) -garrett -- garrett rooney my pid is inigo montoya. [EMAIL PROTECTED] you kill -9 my parent process. http://electricjellyfish.net/prepare to vi.
Re: apr_ function prefixes
On Wed, 7 Feb 2001, B. W. Fitzpatrick wrote: > +1. Wow that looks great. A toast to consistency! i'll drink to that :) > Is there any way you could forward along the conversion script that you > used (Or is that the one you sent last week)? This is going to break > Subversion a bit, and maybe I (or Greg) can get those changes in and > committed first thing in the morning. sure: http://apr.apache.org/~dougm/apr_rename.pl quick-n-dirty, but seems to work ok.
Re: apr_ function prefixes
On Wed, 7 Feb 2001, Doug MacEachern wrote: > to see the files that will change and the line number/name change: > http://perl.apache.org/~dougm/apr_rename.txt +1. Wow that looks great. A toast to consistency! Is there any way you could forward along the conversion script that you used (Or is that the one you sent last week)? This is going to break Subversion a bit, and maybe I (or Greg) can get those changes in and committed first thing in the morning. -Fitz
Re: apr_ function prefixes
to see the files that will change and the line number/name change: http://perl.apache.org/~dougm/apr_rename.txt feel free to shout if anything looks wrong, i won't commit for a few hours.
Re: apr_ function prefixes
On Tue, 6 Feb 2001, Roy T. Fielding wrote: > +1 a.s.a.p. ok, i'm planning todo it later this evening.
Re: apr_ function prefixes
On Wed, Feb 07, 2001 at 06:50:09AM -0500, Kevin Pilch-Bisson wrote: > On Tue, Feb 06, 2001 at 03:05:30PM -0800, Greg Stein wrote: > > On Tue, Feb 06, 2001 at 09:38:16AM -0500, Kevin Pilch-Bisson wrote: > > >... > > > +1 for this, but only if it is done soon. As Ryan said recently, APR is > > > approaching the Beta stage, so API's shouldn't change much. However, I > > > think this is a useful change. > > > > A little process comment here: Ryan is a single voice out of all of us here. > > I want to see a "beta" also, but just because Ryan or I say so doesn't make > > it true. > > > > Basically, we release it as a beta when we (the group) think it is a beta. > > > My apologies if I stepped on any toes. I didn't mean to say that Ryan > had the final say or anything like that. I was just referring to the > fact that Ryan recently suggested not changing API's much, because APR > was approaching Beta. All I meant to say was that I thought this change > was important, even though it _DOES_ in fact change those API's, but > that it should be done soon if it is done, because the API should be > stable once APR is `Beta'd. > > If you interpreted it differently, please rest assured that this was all > I meant to imply. Hehe... have no fear of my toes. Around mailing lists, I wear asbestos pajamas and steel-toed boots. :-) It is only what I said: a "comment". You did say you were lurking for a while and relatively new, so I simply filled in a bit of info on how the process works. No big whoop. I think we'll be changing APIs until we release. After that, then it will be trickier. Trying to freeze APIs at any point before a release just means that you release with sucky APIs. Fix them first, then release. After you release, you have to deal with the crap you built, but that is a different story for a different time :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
On Tue, Feb 06, 2001 at 03:05:30PM -0800, Greg Stein wrote: > On Tue, Feb 06, 2001 at 09:38:16AM -0500, Kevin Pilch-Bisson wrote: > >... > > +1 for this, but only if it is done soon. As Ryan said recently, APR is > > approaching the Beta stage, so API's shouldn't change much. However, I > > think this is a useful change. > > A little process comment here: Ryan is a single voice out of all of us here. > I want to see a "beta" also, but just because Ryan or I say so doesn't make > it true. > > Basically, we release it as a beta when we (the group) think it is a beta. > My apologies if I stepped on any toes. I didn't mean to say that Ryan had the final say or anything like that. I was just referring to the fact that Ryan recently suggested not changing API's much, because APR was approaching Beta. All I meant to say was that I thought this change was important, even though it _DOES_ in fact change those API's, but that it should be done soon if it is done, because the API should be stable once APR is `Beta'd. If you interpreted it differently, please rest assured that this was all I meant to imply. -- > Kevin Pilch-Bisson [EMAIL PROTECTED] http://www.pilch-bisson.net PGP Public Key At http://pgp.pilch-bisson.net pgptqEvaU4ZLR.pgp Description: PGP signature
Re: apr_ function prefixes
+1 a.s.a.p. Roy
Re: apr_ function prefixes
On Tue, Feb 06, 2001 at 09:38:16AM -0500, Kevin Pilch-Bisson wrote: >... > +1 for this, but only if it is done soon. As Ryan said recently, APR is > approaching the Beta stage, so API's shouldn't change much. However, I > think this is a useful change. A little process comment here: Ryan is a single voice out of all of us here. I want to see a "beta" also, but just because Ryan or I say so doesn't make it true. Basically, we release it as a beta when we (the group) think it is a beta. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: apr_ function prefixes
> > there's a number of places where apr (and httpd) is not consistent with > > prefixes or doesn't use one at all (beyond apr_ or ap_). > > personally, i like to see functions named with the prefix of the base type > > (struct) they operate on if possible. for example, apr_xlate_t related > > functions all have an apr_xlate_ prefix, this is goodness. for certain > > types, many, but not all related functions use a consistent prefix > > (e.g. apr_table_t), for some there is no prefix at all. > > i know this might be considered "late in the game", but in reality apr is > > very young software. consistent/meaningful naming should start now, > > rather than 2 years down the road when i suspect it'll be in pretty > > widespread use. below are some suggestions, i think i still have a > > rename script handy if there's consensus to move forward on some or all. > > > > > Although I haven't been much of a contributor to APR, I have been > working with the Subversion group a little bit, so I lurk around here, > since this stuff affects subversion too. I would have to say that I am > +1 for this, but only if it is done soon. As Ryan said recently, APR is > approaching the Beta stage, so API's shouldn't change much. However, I > think this is a useful change. I hate to be left out of giving a +1, so.. -1 oh wait, I meant +1. :-) :-) Please doug, do this soon. The only thing I would ask is exactly what Will said, just put this stuff in the compat header file too. Thanks a lot, Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: apr_ function prefixes
On Mon, Feb 05, 2001 at 09:21:55PM -0800, Doug MacEachern wrote: > there's a number of places where apr (and httpd) is not consistent with > prefixes or doesn't use one at all (beyond apr_ or ap_). > personally, i like to see functions named with the prefix of the base type > (struct) they operate on if possible. for example, apr_xlate_t related > functions all have an apr_xlate_ prefix, this is goodness. for certain > types, many, but not all related functions use a consistent prefix > (e.g. apr_table_t), for some there is no prefix at all. > i know this might be considered "late in the game", but in reality apr is > very young software. consistent/meaningful naming should start now, > rather than 2 years down the road when i suspect it'll be in pretty > widespread use. below are some suggestions, i think i still have a > rename script handy if there's consensus to move forward on some or all. > Although I haven't been much of a contributor to APR, I have been working with the Subversion group a little bit, so I lurk around here, since this stuff affects subversion too. I would have to say that I am +1 for this, but only if it is done soon. As Ryan said recently, APR is approaching the Beta stage, so API's shouldn't change much. However, I think this is a useful change. -- > Kevin Pilch-Bisson [EMAIL PROTECTED] http://www.pilch-bisson.net PGP Public Key At http://pgp.pilch-bisson.net pgpzCYvtYe3Rx.pgp Description: PGP signature
Re: apr_ function prefixes
+1 ... we need these changes, only we have attacked this as time has permitted. My only comment, take this group: > apr_get_shm_nameapr_shm_name_get > apr_set_shm_nameapr_shm_name_set > apr_open_shmem apr_shm_open I'd personally like to see apr_shm_get/set_name (and agree with you on apr_shm_open) but I'd much prefer the apr_shm prefix on all shm fn's, etc. Renaming today is fine [although I haven't finished the jobs I signed up for, yet] since we have apr_compat.h (or apu_compat.h for apr-util symbols), and that should help avoid breaking existing consumers, or get them working again quickly. APR has just sort of grown, and since we have a bunch of folks moving stuff into apr, we have done is several different ways. Any patches to clean this up would be quite appropriate. Bill - Original Message - From: "Doug MacEachern" <[EMAIL PROTECTED]> To: Sent: Monday, February 05, 2001 9:21 PM Subject: apr_ function prefixes > there's a number of places where apr (and httpd) is not consistent with > prefixes or doesn't use one at all (beyond apr_ or ap_). > personally, i like to see functions named with the prefix of the base type > (struct) they operate on if possible. for example, apr_xlate_t related > functions all have an apr_xlate_ prefix, this is goodness. for certain > types, many, but not all related functions use a consistent prefix > (e.g. apr_table_t), for some there is no prefix at all. > i know this might be considered "late in the game", but in reality apr is > very young software. consistent/meaningful naming should start now, > rather than 2 years down the road when i suspect it'll be in pretty > widespread use. below are some suggestions, i think i still have a > rename script handy if there's consensus to move forward on some or all. > > apr_pollfd_t: > apr_add_poll_socket apr_poll_socket_add > apr_clear_poll_sockets apr_poll_socket_clear > apr_get_polldataapr_poll_data_get > apr_get_revents apr_poll_revents_get > apr_mask_poll_socketapr_poll_socket_mask > apr_remove_poll_socket apr_poll_socket_remove > apr_set_polldataapr_poll_data_set > apr_setup_poll apr_poll_setup > > apr_time_t: > apr_now apr_time_now > > apr_array_header_t: > apr_append_arrays apr_array_append > apr_copy_array apr_array_copy > apr_copy_array_hdr apr_array_copy_hdr > apr_make_array apr_array_make > apr_push_array apr_array_push > > apr_socket_t: > apr_close_socketapr_socket_close > apr_create_socket apr_socket_create > apr_get_sockaddrapr_socket_addr_get > apr_get_socketdata apr_socket_data_get > apr_set_socketdata apr_socket_data_set > > apr_sockaddr_t: > apr_getaddrinfo apr_sockaddr_info_get > apr_get_ipaddr apr_sockaddr_ip_get > apr_set_ipaddr apr_sockaddr_ip_set > apr_set_portapr_sockaddr_port_set > apr_get_portapr_sockaddr_port_get > > apr_pool_t: > apr_create_pool apr_pool_create > apr_destroy_poolapr_pool_destroy > apr_get_userdataapr_pool_userdata_get > apr_set_userdataapr_pool_userdata_set > apr_kill_cleanupapr_pool_cleanup_kill > apr_run_cleanup apr_pool_cleanup_run > apr_null_cleanupapr_cleanup_null > apr_register_cleanupapr_cleanup_register > apr_make_sub_pool apr_pool_sub_make > apr_note_subprocess apr_pool_note_subprocess > > apr_lock_t: > apr_child_init_lock apr_lock_child_init > apr_create_lock apr_lock_create > apr_destroy_lockapr_lock_destroy > apr_get_lockdataapr_lock_data_get > apr_set_lockdataapr_lock_data_set > apr_lockapr_lock_aquire > apr_unlock apr_lock_release > > apr_table_: > apr_clear_table apr_table_clear > apr_copy_table apr_table_copy > apr_make_table apr_table_make > apr_overlap_tables apr_table_overlap > apr_overlay_tables apr_table_overlay > > apr_file_t: > apr_openapr_file_open > apr_close apr_file_close > apr_create_namedpipeapr_file_namedpipe_create > apr_create_pipe apr_file_pipe_create > apr_dupfile apr_file_dup > apr_flush apr_file_flush > apr_eof apr_file_eof > apr_ferror apr_file_error > apr_fgets apr_file_gets >
apr_ function prefixes
there's a number of places where apr (and httpd) is not consistent with prefixes or doesn't use one at all (beyond apr_ or ap_). personally, i like to see functions named with the prefix of the base type (struct) they operate on if possible. for example, apr_xlate_t related functions all have an apr_xlate_ prefix, this is goodness. for certain types, many, but not all related functions use a consistent prefix (e.g. apr_table_t), for some there is no prefix at all. i know this might be considered "late in the game", but in reality apr is very young software. consistent/meaningful naming should start now, rather than 2 years down the road when i suspect it'll be in pretty widespread use. below are some suggestions, i think i still have a rename script handy if there's consensus to move forward on some or all. apr_pollfd_t: apr_add_poll_socket apr_poll_socket_add apr_clear_poll_sockets apr_poll_socket_clear apr_get_polldataapr_poll_data_get apr_get_revents apr_poll_revents_get apr_mask_poll_socketapr_poll_socket_mask apr_remove_poll_socket apr_poll_socket_remove apr_set_polldataapr_poll_data_set apr_setup_poll apr_poll_setup apr_time_t: apr_now apr_time_now apr_array_header_t: apr_append_arrays apr_array_append apr_copy_array apr_array_copy apr_copy_array_hdr apr_array_copy_hdr apr_make_array apr_array_make apr_push_array apr_array_push apr_socket_t: apr_close_socketapr_socket_close apr_create_socket apr_socket_create apr_get_sockaddrapr_socket_addr_get apr_get_socketdata apr_socket_data_get apr_set_socketdata apr_socket_data_set apr_sockaddr_t: apr_getaddrinfo apr_sockaddr_info_get apr_get_ipaddr apr_sockaddr_ip_get apr_set_ipaddr apr_sockaddr_ip_set apr_set_portapr_sockaddr_port_set apr_get_portapr_sockaddr_port_get apr_pool_t: apr_create_pool apr_pool_create apr_destroy_poolapr_pool_destroy apr_get_userdataapr_pool_userdata_get apr_set_userdataapr_pool_userdata_set apr_kill_cleanupapr_pool_cleanup_kill apr_run_cleanup apr_pool_cleanup_run apr_null_cleanupapr_cleanup_null apr_register_cleanupapr_cleanup_register apr_make_sub_pool apr_pool_sub_make apr_note_subprocess apr_pool_note_subprocess apr_lock_t: apr_child_init_lock apr_lock_child_init apr_create_lock apr_lock_create apr_destroy_lockapr_lock_destroy apr_get_lockdataapr_lock_data_get apr_set_lockdataapr_lock_data_set apr_lockapr_lock_aquire apr_unlock apr_lock_release apr_table_: apr_clear_table apr_table_clear apr_copy_table apr_table_copy apr_make_table apr_table_make apr_overlap_tables apr_table_overlap apr_overlay_tables apr_table_overlay apr_file_t: apr_openapr_file_open apr_close apr_file_close apr_create_namedpipeapr_file_namedpipe_create apr_create_pipe apr_file_pipe_create apr_dupfile apr_file_dup apr_flush apr_file_flush apr_eof apr_file_eof apr_ferror apr_file_error apr_fgets apr_file_gets apr_fprintf apr_file_printf apr_full_read apr_file_read_file apr_full_write apr_file_write_full apr_getcapr_file_getc apr_ungetc apr_file_ungetc apr_putcapr_file_putc apr_putsapr_file_puts apr_readapr_file_read apr_write apr_file_write apr_writev apr_file_writev apr_seekapr_file_seek apr_get_filedataapr_file_data_get apr_getfileinfo apr_file_info_get apr_get_filenameapr_file_name_get apr_get_file_pool apr_file_pool_get apr_get_pipe_timeoutapr_file_pipe_timeout_get apr_set_pipe_timeoutapr_file_pipe_timeout_set apr_lock_file apr_file_lock apr_unlock_file apr_file_unlock apr_open_stderr apr_file_open_stderr apr_open_stdout apr_file_open_stderr apr_remove_file apr_file_remove apr_rename_file apr_file_rename apr_set_filedataapr_file_data_set apr_setfilepermsapr_file_perms_set apr_procattr_t: apr_createprocattr_init apr_procattr_create apr_setprocattr_childerrapr_procattr_child_err_set apr_setprocattr_childin apr_procattr_child_in_set apr_setprocattr_childoutapr_procattr_child_out_set apr_setprocattr_cmdtype apr_procattr_cmdtype_set apr_setprocattr_detach apr_procattr_detach_set apr_setprocattr_dir
