need help with naming/renaming my DocSet package before it goes toCPAN
[I've tried to ask around, but had almost no feedback, this is my last station before i submit the module to CPAN] Those of you who are involved with mod_perl probably know that I've been working on developing a documentation framework for perl.apache.org, which I've called DocSet, since it uses the concept of stacked docsets, each consisting of other docsets, chapters and external links. Currently it supports HTML and POD as the source formats (a mix of source formats can be used) and can (and should) be extended to support XML, Text, etc. It generates PS, PDF and HTML output and can be extended to generate other formats as well. Currently it uses Template Toolkit for rendering, but again, flexible enough to be used with any other templating system. You can see what you can get using it at: http://perl.apache.org/release/index.html (btw, this is the new perl.apache.org that will be released as soon as we finish polishing the cross-browser/platform rendering issues) If you want to look at the sources of the site and see how it's done, please read: http://perl.apache.org/release/download/docs.html This package is currently only available from: http://www.apache.org/~stas/DocSet-0.13.tar.gz Now back to the topic of this post. What is the namespace it should go to on CPAN? I cannot find any existing suitable namespace to put it in. I'd be glad to just keep it as DocSet:: but is there a concern that this hijacks the whole namespace, similar to what Template Toolkit happened to do to the Template:: namespace. Rememeber that this is an extensible framework and not a package with general purpose modules, so it won't fit into any POD::, HTML::, etc namespaces. Should we create a new hierarchy for apps? App::, Bin::? Thanks for your ideas! If you don't have any I'm quite happy with keeping the DocSet name. I'm planning on releasing this package on CPAN as soon as the new modperl site is released. This is because I'm going to use the modperl site as the demo/test suite for this package. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: need help with naming/renaming my DocSet package before it goesto CPAN
Tim Bunce wrote: > On Tue, Jun 25, 2002 at 10:43:37PM +0800, Stas Bekman wrote: > >>Rememeber that this is an extensible framework and not a package with >>general purpose modules, so it won't fit into any POD::, HTML::, etc >>namespaces. Should we create a new hierarchy for apps? App::, Bin::? >> >>Thanks for your ideas! If you don't have any I'm quite happy with >>keeping the DocSet name. > > > The general convention is that "frameworks" are _encouraged_ to have a > catchy non-generic "brand name" for the top-level name. I haven't thought of this idea. I was trying to match the name to the functionality :) > DocSet seems fine to me, assuming it doesn't clash with some other > concept "out there" that someone may want perl modules for later. > A quick google search turned up these: > >http://happydoc.sourceforge.net/HappyDoc-r2_0_1/happydoclib/happydocset_DocSet.py.html > http://cic.cstb.fr/ilc/DOCSET/docset.htm That's true. Again I haven't thought of the outside world, was looking at CPAN only. Thanks for the comments. > but I'd say you can grab the DocSet name now. Cool, so if I don't come up with some cool brand name, be it DocSet. Thanks Tim! __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Module submission Debug::SIGSEGVTrace
Tim Bunce wrote: > On Fri, Aug 02, 2002 at 05:13:00AM +0200, Perl Authors Upload Server wrote: > >>The following module was proposed for inclusion in the Module List: >> >> modid: Debug::SIGSEGVTrace >> DSLIP: adhOa >> description: Extract A Backtrace on SegFault >> userid: STAS (Stas Bekman) >> chapterid:3 (Development_Support) >> communities: >>[EMAIL PROTECTED] >> >> similar: >>Devel::CoreStack >> >> rationale: >> >>This module attempts to automatically extract a backtrace when a >>segfault happens, rather then letting the core file be dumped. > > > Cool. > > I think the name shouldn't contain SEGV since that's just one of the > causes of a core. Another fairly common one is a Bus Error. What signals result in the core dump? BUS SEGV PIPE ABRT? any others? Currently the module traps only SIGSEGV, hence the name. Can you really fork and fire up gdb on SIGBUS and other SIGs? > How about Debug::CoreStackTrace? The point of this module is that there is no core involved here ;) But I guess it's fine, assuming that the module gets extended to other signals as well. The module also includes Debug::SIGSEGVFault which dereferences a NULL pointer and causes SIGSEGV. how should it be renamed then? Debug::CoreDump? I guess I could release it separately. I bundled it up because it's needed to test Debug::SIGSEGVTrace. What do you think? BTW, meanwhile I put it on CPAN here: http://search.cpan.org/search?mode=module&query=SIGSEGVTrace > Have you looked at the sigtrap module? Your work may be a natutral > extension to that. It cannot be used, because the sighandler must be assigned on the C level. If you do it on the perl level, under 5.8.0 it won't work because of the way the signals handling is delayed in 5.8.0. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Module submission Debug::SIGSEGVTrace
Tim Bunce wrote: > On Fri, Aug 02, 2002 at 07:31:53PM +0800, Stas Bekman wrote: > >>>I think the name shouldn't contain SEGV since that's just one of the >>>causes of a core. Another fairly common one is a Bus Error. >> >>What signals result in the core dump? BUS SEGV PIPE ABRT? any others? > > > On FreeBSD: > $ man 2 sigaction | grep core > SIG_DFL. The defaults are process termination, possibly with core dump; > SIGQUIT create core image quit program > SIGILL create core image illegal instruction > SIGTRAP create core image trace trap > SIGABRT create core image abort(3) call (formerly SIGIOT) > SIGEMT create core image emulate instruction executed > SIGFPE create core image floating-point exception > SIGBUS create core image bus error > SIGSEGV create core image segmentation violation > SIGSYS create core image non-existent system call invoked Looks like we enter the crossplatform issues here. Linux doesn't have EMT signal. I guess I'll go with the rest of the signals and polish the module on the go as people use it and send patches in. I've tested all these manually, since the same manpage on linux doesn't include that info. >>>How about Debug::CoreStackTrace? >> >>The point of this module is that there is no core involved here ;) > > > Debug::NoCoreStackTrace :) > > >>But I guess it's fine, assuming that the module gets extended to other >>signals as well. > > > How about Debug::OnFaultTrace, or Debug::AutoFaultTrace? I think this name describes the best its functionality: Debug::FaultAutoBackTrace But long names are painful, any preferrable shortcuts? Debug::FaultAutoBT Debug::FaultABT Debug::FABT >>The module also includes Debug::SIGSEGVFault which dereferences a NULL >>pointer and causes SIGSEGV. how should it be renamed then? >>Debug::CoreDump? I guess I could release it separately. I bundled it up >>because it's needed to test Debug::SIGSEGVTrace. What do you think? > > > You can probably drop it. The dump() builtin also triggers a core dump: > $ perldoc -f dump | grep core > This causes an immediate core dump. [...] Yes, yes, I didn't want to use dump() because it doesn't give you a useful backtrace. My module calls a few functions before it segfaults: #0 0x4039f781 in crash_now_for_real ( suicide_message=0x403a0120 "Cannot stand this life anymore") at SIGSEGVFault.xs:9 #1 0x4039f7a3 in crash_now ( suicide_message=0x403a0120 "Cannot stand this life anymore", attempt_num=42) at SIGSEGVFault.xs:16 #2 0x4039f824 in XS_Debug__SIGSEGVFault_segv (cv=0x84ecda0) at SIGSEGVFault.xs:25 I use it in the documentation to explain what is a backtrace, how you can figure out where the problem is. dump()'s bt on C-level is too short to be useful in teaching. I guess I'll call it then Debug::DoSegFault. Thanks Tim! __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Module submission Debug::SIGSEGVTrace
Tim Bunce wrote: > On Sat, Aug 03, 2002 at 09:15:21AM +0800, Stas Bekman wrote: > >>Tim Bunce wrote: >> >>>How about Debug::OnFaultTrace, or Debug::AutoFaultTrace? >> >>I think this name describes the best its functionality: >>Debug::FaultAutoBackTrace > > > Okay. > > >>But long names are painful, any preferrable shortcuts? >> >>Debug::FaultAutoBT >>Debug::FaultABT >>Debug::FABT > > > I think short names can be a false economy. But Debug::FaultAutoBT > is okay with me (with a suitable description entry). Agreed, here is the entry that I'm going to use: Debug::FaultAutoBT - Automatic Backtrace Extractor on SIGSEGV, SIGBUS, etc Is there anything else I should do to register this namespace? Thank you, Tim __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
The Env::C namespace
Hi, Should Env::C be a good name for a Perl glue to getenv(3), setenv(3) and unsetenv(3)? Thanks! Here is the whole manpage: NAME Env::C - Get/Set/Unset Environment Variables on the C level SYNOPSIS use Env::C; my $key = "USER"; $val = Env::C::getenv($key) || ''; Env::C::setenv($key, "foobar", [$override]); $new_val = Env::C::getenv($key) || ''; Env::C::unsetenv($key); my $ar_env = Env::C::getallenv(); print join "\n", @$ar_env; DESCRIPTION This module provides a Perl API for getenv(3), setenv(3) and unsetenv(3). It also can return all the "environ" variables. Sometimes Perl invokes modules with underlaying C APIs which rely on certain environment variables to be set, if these variables are set in Perl and the glue code doesn't worry to set them on the C level, these variables might not be seen by the C level. This module shows what really the C level sees. FUNCTIONS * getenv() $val = Env::C::getenv($key); Returns the value of the environment variable matching the key or "undef". * setenv() Env::C::setenv($key, $value, [$override]); The setenv() function adds the variable "$key" to the environment with the value "$value", if "$key" does not already exist. If "$key" does exist in the environment, then its value is changed to "$value" if "$overwrite" is non-zero; if "$overwrite" is zero or is not passed, then the value of "$key" is not changed. * unsetenv() Env::C::unsetenv($key); The unsetenv() function deletes the variable "$key" from the environment. * getallenv() my $ar_env = Env::C::getallenv(); print join "\n", @$ar_env; The getallenv() function returns an array reference which includes all the all the environment variables. EXPORT None. AUTHOR Stas Bekman <[EMAIL PROTECTED]> SEE ALSO the perl manpage. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: The Env::C namespace
Arthur Bergman wrote: > > On torsdag, augusti 22, 2002, at 05:40 , Stas Bekman wrote: > >> >> Sometimes Perl invokes modules with underlaying C APIs which rely on >> certain environment variables to be set, if these variables are >> set in >> Perl and the glue code doesn't worry to set them on the C level, >> these >> variables might not be seen by the C level. This module shows what >> really the C level sees. >> >> > > Shouldn't the gluecode really do this? Do what? Set env vars? Of course it should... if it's safe. But as you can see from the recent mod_perl thread about Oracle DBD not working with mod_perl 2.0 when %ENV was set in the registry script, since %ENV isn't tied to environ, because it's not thread safe. I wrote this module to debug the case, since I don't have Oracle to test with. This module was only needed for getenv() and dumpenv() so those who don't know C can at least debug things. But I've generalized it and added setenv() and unsetenv() while I was at it. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: The Env::C namespace
Arthur Bergman wrote:
>
> On torsdag, augusti 22, 2002, at 10:12 , Stas Bekman wrote:
>
>>
>> Do what? Set env vars? Of course it should... if it's safe. But as you
>> can see from the recent mod_perl thread about Oracle DBD not working
>> with mod_perl 2.0 when %ENV was set in the registry script, since %ENV
>> isn't tied to environ, because it's not thread safe. I wrote this
>> module to debug the case, since I don't have Oracle to test with.
>>
>> This module was only needed for getenv() and dumpenv() so those who
>> don't know C can at least debug things. But I've generalized it and
>> added setenv() and unsetenv() while I was at it.
>>
>>
>
> %ENV{} should be identicial between all threads, anything else is surely
> a bug!
Certainly. But this is a different issue.
What I was saying is that %ENV doesn't have to be the same as environ.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Module submission DocSet
Hi, anybody knows why there was no followup on this submission? Thanks! Perl Authors Upload Server wrote: > The following module was proposed for inclusion in the Module List: > > modid: DocSet > DSLIP: bmpOp > description: Documentation Projects Builder > userid: STAS (Stas Bekman) > chapterid: 23 (Miscellaneous_Modules) > communities: > [EMAIL PROTECTED] > http:[EMAIL PROTECTED]/msg12306.html > > similar: > unknown > > rationale: > > This package builds a docset from sources in different formats. The > generated documents can be all nicely interlinked and to have the > same look and feel. > > Currently it knows to handle input formats: > > * POD * HTML > > and knows to generate: > > * HTML * PS * PDF > > enteredby: STAS (Stas Bekman) > enteredon: Mon Aug 19 07:04:06 2002 GMT > > The resulting entry would be: > > DocSetbmpOp Documentation Projects Builder STAS > > > Thanks for registering, > The Pause Team > > PS: The following links are only valid for module list maintainers: > > Registration form with editing capabilities: > >https://pause.perl.org/pause/authenquery?ACTION=add_mod&USERID=ee10_0d180b53737c382b&SUBMIT_pause99_add_mod_preview=1 > Immediate (one click) registration: > >https://pause.perl.org/pause/authenquery?ACTION=add_mod&USERID=ee10_0d180b53737c382b&SUBMIT_pause99_add_mod_insertit=1 -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
pause: env::c
Hi, Michael Schout / MSCHOUT wants to take over the ownership of Env::C. I used to be the owner and then passed it to someone else, but somehow that someone else dropped the ownership w/o re-assigning it to anybody else, so the module as an orphan now, and I'm listed as the co-maint, but I can't change permissions. So can you please set Michael as the owner? Thank you. -- ____ Stas Bekman http://stasosphere.com http://stason.orghttp://chestofbooks.com http://vitalitylink.com http://healingcloud.com
