Re: RFC: ideas about Tk and logging facility
On Mon, 7 Feb 2000, Nick Ing-Simmons wrote:
> Can you give an outline of what Log::Dispatch does?
I'll summarize since I'm the author.
Log::Dispatch has two parts. The first is the dispatch object, which
takes messages and levels (i.e. error, criticial, warning) and passes them
to all of its internally held logging objects (which are all subclasses of
Log::Dispatch::Output. These include Log::Dispatch::File,
Log::Dispatch::Screen (really STDOUT or STDERR), etc.). The idea here is
that you create a dispatcher and any number of logging objects and then
you pass the messages to the dispatcher, meaning there is a single point
of entry for logging to multiple places (each of the logging objects
chooses whether or not to act upon the information based on the log
level).
What Dominique is proposing is a new subclass of Log::Dispatch::Output
that displays messages in a text box. Since she would like it to be part
of the Tk::* hierarchy, that creates some interesting namespace issues.
Really, it is part of the Log::Dispatch suite, so perhaps the name should
be Log::Dispatch::TkWindow or something like that. As I think about it, I
can't see it possibly being included in the Tk core suite unless you were
also willing to include the full Log::Dispatch suite as well (which
doesn't make sense). I, however, would be happy to add this to the
Log::Dispatch suite, depedent on the name chosen. To me, this is really
an addition to Log::Dispatch that happens to use Tk, as opposed to the
other way around ("if you have a (Log::Dispatch shaped?) hammer,
everything looks like a nail").
> I could imagine that it might be worth calling it Tk::Log::Dispatch
> or perhaps Tk::LogDispatch::Output it depends if the Log:: level is
> useful for anything.
Hmm, Tk::Log::Dispatch is definitely not right as it implies some sort of
Tk based dispatcher (the dispatch object is Log::Dispatch).
Tk::LogDispatch::Output is also not really appropriate. As you can see
from my naming convention, Log::Dispatch::Output is an 'invisible' parent
class, in that you don't see ::Output in its children. I don't want to
start changing that now. Really, it seems best to me that this be named
Log::Dispatch::TkSomethingOrOther. This fits in with other ::Output
subclasses like Log::Dispatch::File, etc.
Dominique, if you agree to this we can privately discuss adding this to
the next release of Log::Dispatch. If we do this, Nick, you may want some
input as to what TkSomethingOrOther ends up being (or should that
discussion occur with the whole ptk list?). I don't have too much
experience with Tk so whatever you all decide will work for me.
-Dave
/*==
www.urth.org
We await the New Sun
==*/
Re: RFC: ideas about Tk and logging facility
One other thing that would probably be worth knowing about Log::Dispatch is that it only works with perl 5.005 or greater (it uses pseudo-hashes and compile time object typing). This may or may not be relevant but since this is somewhat unusual for CPAN modules I thought people should know this. It tends to make including it in other distributions (like Tk or whatever) undesirable, I suppose. Sorry for the double post. -Dave /*== www.urth.org We await the New Sun ==*/
Better late than never
I'd like to officially register the following two modules: Thesaurus DSLI - RdpO Create associations between related things Thesaurus::File DSLI - RdpO Persitence via CSV files Thesaurus::DBM DSLI - RdpO Persistence via DBM files Thesaurus::DBI DSLI - idpO Persistence in a database via DBI DSLI for all of these is MdpO (I say mature because other people are using this and developing their own subclasses so what the heck). Log::Dispatch Log messages to multiple outputs Log::Dispatch::Output Base class for output objects Log::Dispatch::File Log output to file Log::Dispatch::Handle Log output to any IO::Handle Log::Dispatch::Screen Log output to STDOUT or STDERR Log::Dispatch::Syslog Log output to system log via syslog Log::Dispatch::Email Base class for logging to email Log::Dispatch::Email::MIMELite Send email via MIME::Lite module Log::Dispatch::Email::MailSend send email via Mail::Send module Log::Dispatch::Email::MailSendmail send email via Mail::Sendmail module I don't know if I can claim the new top level space of Thesaurus (and can live without it if you think my module isn't appropriate for that space) but I think I have a reasonable claim to Log::Dispatch. I'm expecting someone else (Dominique Dumont) to be putting out a Log::Dispatch::Tk suite soon, which has my permission (if such a thing is needed) to be put in this namespace, should it be given to me. I know she's talked to Nick Ing-Simmons about this as well and I think he's ok with this too. Thanks, -Dave
two new ones
I'll be uploading two new modules to CPAN that I'd like to register if possible (CPAN id DROLSKY). 1. StackTrace - This provides a stacktrace object very similar to what you get from confess or cluck but you don't have to actually issue a warning. Plus you can step through the stack and examine the information in it (it has all the info caller() provides for each stack level). This is primarily used by the next module I'm uploading but has the potential to be useful on its own, particularly if you just want to pass around the stack for some reason. 2. Class::Exceptions (also includes the class BaseException internally but I don't want to register that). This module lets you 'declare' a hierarchical set of exception objects (with any root, not just BaseException) at compile time via the 'use' command. It does not implement any sort of try/catch syntax as this is already covered elsewhere and I don't like it anyway dammit. It could probably be used with G. Barr's Error module if you want that stuff. I emailed way back when about these modules but the exception module had a different name (Exception) and didn't hear back. I don't feel comfortable trying to claim that namespace anyway and this one seems a lot more reasonable. With the StackTrace namespace, I think that even though its top level this implementation is fairly reasonable as _the_ implementation. OTOH, I could always change it later if you want. both DLSI's are RdpO Thanks, -dave /*== www.urth.org We await the New Sun ==*/
Request for info on how modules@perl.org works
This has been bugging me for a while. Basically, [EMAIL PROTECTED] seems like sort of a black box. I send messages it to it and it seems that they go to some list of people (Andreas, G. Barr, J. Pritikin, K. Starsinic, ???) and then sometimes I get a response and sometimes not. Note, this has nothing to do with the messages I sent earlier today (I'm not _that_ impatient). Rather, this has to do with messages I sent way long ago about the Exception & StackTrace namespaces. I see this sentence, "Generally a lack of response can be taken as acceptance of the module name being proposed," on the 04pause page but I really doubt that's what happened in regards to my earlier request. Heck, I wouldn't give myself the Exception namespace so I wouldn't expect anybody reading this to do so either! Anyway, what I think would be most useful would be some info on CPAN (perhaps on the 04pause page) listing the following: 1. Who reads this list (I know anyone can read the archives but who gets it mailed to them)? 2. What do those people's responsibilities consist of (particularly of interest if different people do different things)? 3. What to do if we get no response (give up, resend the message with more information, start our own parallel CPAN where we control all the namespaces. Hmm, MyCPAN! ;) )? Yes, I know everyone who reads this list is busy but then maybe you just need to get some more help. I am not the first to grumble about this list and frankly I think it sometimes is a bit of an impediment to getting more involved in contributing back to the Perl community, which is why we all want to put stuff on CPAN anyway (that and the glory of it all, I suppose). And finally, would it be possible to enable read-only subscriptions to the list? I'd like to follow the traffic as from time to time queries similar to mine come up (exceptions, to name one) and I'd like to discuss these with the authors. For example, maybe everyone interested in exceptions could form a mailing list, get some standards together and come back with a better proposal for a CPAN namespace. However, regularly fishing through the archives is a terribly inefficient use of my time and generally I don't see stuff til way too late. Deleting a bunch of messages is much easier. Thanks, -dave P.S. If this message generates no reponse at all I'll just have to cry ;) /*== www.urth.org We await the New Sun ==*/
Re: Request for info on how modules@perl.org works
On Mon, 26 Jun 2000, Kurt D. Starsinic wrote: > [EMAIL PROTECTED] is a council of wise elders who give advice on > module naming, when they feel that their wisdom is applicable. A more > accurate version of the above quote might be: > > `Generally, a lack of response can be taken as an indication > that there is nothing blatantly stupid about your proposal.' Well, maybe what I'd prefer is a positive response saying, "Yes, you can have namespace Foo." I know there is a reluctance to give out top level namespaces (for very good reasons). When I send a message discussing two of them at once (Exception & StackTrace) and I get no response, I don't really interpret that as a go-ahead to just upload and then expect to get listed on the modules list (which is important to me as I want the things I upload to be visible or otherwise why bother uploading). > Some of us appreciate some imagined level of privacy. What benefit > will you achieve from knowing each member's name and email address? Actually I wasn't suggesting email addresses, just names. Seeing as how I know something about a lot of the people from the list from seeing their involvement in other fora (p5p, other perl lists, etc.) I'm just curious who they are. And keeping it unavailable seems to serve little purpose. I could figure it out by browsing a few months worth of archives but again, why should I have to bother? Yes, I know you'll refer me to your block below. > > 2. What do those people's responsibilities consist of (particularly of > > interest if different people do different things)? > > Their responsibility is to listen when they have time, and to consider > the future of CPAN before they speak. I was more curious if any effort had been made to divide the responsibilities at all in terms of giving certain people responsibility for certain pieces of the overall namespace. > There is very little law on PAUSE. To quote 04pause.html, `Please, talk > to [EMAIL PROTECTED] before you decide upon the namespace'. Note the use of > `please' and the absence of `must'. Certain top-level namespaces (e.g., > Sun::, DBI::) are controlled by force of law, and are documented as such. > Otherwise, you are simply requested to play nicely with others. Yes, but I want to get listed in the main list, as I said before, so I can actually get my code out there. Therefore I need the cooperation of this list. > I certainly want to support your efforts and the efforts of others to > contribute to CPAN, but I don't see how you've been kept from contributing. > I find CPAN (specifically PAUSE) to be unbelievably open, and fairly well > documented. Your legitimate complaints seem to be based in not finding, > reading, understanding, and/or trusting the documentation. Do you think > there's a documentation problem, an access problem, or another sort of > problem? I think its a documentation problem then. Specifically, I think there needs to be a significantly better mechanism for registering namespaces (top-level or otherwise). Maybe a registration list that we could check after sending messages to this list. For example, I consider myself to own the Log::Dispatch::* namespace but do I really own this? By own I mean I should have final say over whether a Log::Dispatch::Foo module can be individually listed on the modules page. Basically what I want is this sequence or something similar: - I send a request for namespace Foo::Bar to [EMAIL PROTECTED] - Maybe I get a response saying 'No, you dunderhead, you can't have it. But how about Foo::Bar::Baz?' to which I either reply 'No, I really want it and here's why?' or 'Ok'. If we don't agree I eventually get a response saying 'Give up, sucka. You'll never get it.' - ... Or I get a response saying 'It's yours. Upload to your heart's content.' - ... Or I get no response but I check the 'Namespace owner page' and see my name listed next to Foo::Bar. That doesn't seem too much to ask and would address all my frustrations. Basically, the 'lack of response is assent' really isn't good enough because: 1. Nobody really notices that sentence. 2. Nobody really takes it seriously. 3. They shouldn't take it seriously because it really isn't true! > I am happy to be outspoken and say that I don't want to make > things _too_ easy. There's a certain level of commitment that's required > to participate effectively in CPAN, and I think that's a good thing, because > what we need most is committed and well-informed participants. Uh, what's the point? You want the process to be annoying for what purpose? So I can show you how 'tough' I am by reading the archives? What do you lose by providing a read-only feed to people? > That being said, [EMAIL PROTECTED] isn't a discussion forum; it is > requested that the substantial discussion take place elsewhere first. Maybe what's really needed is a [EMAIL PROTECTED] (or @elsewhere) list. Newgroups just don't seem
Re: two new ones
On 27 Jun 2000, Andreas J. Koenig wrote: > > 1. StackTrace - This provides a stacktrace object very similar to what you > > Good idea. What about Devel::StackTrace. It will be used to develop > code, not in other situations, so Devel:: seems appropriate. Hmm, I'm not sure I like Devel:: all that much (though I can live with it) because it conceivably has more use then just development. For example, maybe you always want to log traces on errors no matter in production or not. On the other hand, the introspection-ish nature (that's a word, right?) does lend it towards the Devel:: hierarchy. > Last week I suggested to Matt Sergeant for his Exception module: > > Maybe call it Exception::Simple, then we can recommend future > implementors of Exception modules to collect their alternatives in > the Exception:: namespace. I saw that (after I emailed you). See what I mean about a read-only feed being useful (ref to other message from today) ;) > How would you like Exception::Class and Exception::Class::Base? I'd > avoid using unregistered root namespaces internally--after all > namespace clashes could happen there and will probably be hard to > diagnose. That's a good point. I can live with those namespaces. I kind of like Class::Exceptions though because the module is all about declaring exceptions (which is really about magically creating exception classes). The reason I chose BaseException is that I kind of like the Java standard of FooBarException style names rather than Exception::Foo::Bar. It just seems more descriptive and you get the important info first (error type, followed by subtype(s) followed the generic fact that its an exception). OTOH, its not very perlish. Back to Class::Exceptions. If I wanted to use this and rename the internal class BaseException to Class::Exceptions::Base then that name sucks hard. The other possibility is Exception::Declare (except it really should be Exceptions::Declare). Ugh, this is making my brain hurt. > It isn't unlikely that if there will ever be "official" Perl > exceptions, then they will be in the Exception namespace. For that > reason I'd like to reserve that. But gathering the candidates in one > or a few common directory/ies seems sensible to me. I agree that this makes sense. Ok, in light of the greater good of getting all this stuff in the same place I'll go with Devel::StackTrace Exception::Class Exception::Class::Base I can always use whatever names I want for the magically declared ones. I'll delete the stuff I uploaded earlier today (in the other namespaces I originally mentioned) and send new ones in the right namespace. BTW, can you guys get rid of Pete Seibel's way way defunct Exceptions.pm? It doesn't work at all with recent Class::MethodMaker releases and its kind of distracting, espcially since Error.pm does what Exceptions.pm used to. And also BTW, shouldn't Error.pm become Exception::TryCatch or something like that? Because of the name it took me about a bazillion years or so (+/- 1) to find out it existed. Of course, it includes something called Error::Simple which should probably be Exception::Simple but Matt already has that. Anyway, all this is to say that it would be nice to have some general cleanup of the Exception related modules so that we could present all the possibilities and also work on making them work together (my declaration code could easily work with Error, for example, and it might be nice to have them cross-reference each other). -dave /*== www.urth.org We await the New Sun ==*/
Re: two new ones
On Tue, 27 Jun 2000, Graham Barr wrote: > That is an understatement, but all the people involved have different > ideas/needs etc.. Maybe we need a discussion forum for this work. I favor a subscriber-post-only mailing list myself and I think it would be fairly low traffic. Basically, just invite whoever's written exception code, either as a base CPAN module (you, me, Pete Seibel?, Matt Sargent, that guy who uploaded something called Exception.pm, Pete Jordan who's working on this for the core). > I have no problem with renaming Error and using some standard base classes. > But if it is to be renamed I feel it should stay at the top level. ie If it's > classes are Exception::* then the try/catch etc. should be in Exception.pm, > or atleast avaliable via > > use Exception qw(try catch); I strongly disagree. As try/catch is not built into Perl I really don't feel that it should be considered the core of any exception model that gets built. But that's why we need a discussion forum. There are people who are interested in these things but we don't really talk to each other. > PS: For those who were there and remember, last year's p5p meeting at the conf. > I was (assigned ?) the task of getting error/exception objects into the perl > core. Part of this was to define a base class structure etc.. See my above mention of a mailing list. I know Pete Jordan is working on this (making it available from XS and such) so it would be nice if the 10-20 people who've gotten seriously interested in this could talk about it. -dave /*== www.urth.org We await the New Sun ==*/
Re: Request for info on how modules@perl.org works
On 27 Jun 2000, Andreas J. Koenig wrote: > Disclaimer: please note, English is not my mother tongue. If in doubt > about my words, please give me a chance to clarify before you shoot. I think you're pretty clear. > That's impossible due to a lack of resources. We are not a funded > institution. Then get more people involved is all I can suggest. > Tk, Apache, and XML have their own module lists that are maintained > separately and discussed on the respective mailing lists. I'm aware of the latter two at least (I don't do any Tk stuff really). > Yes and no. Yes, it would be nice if this list would be available with > good advice on a 24/7 basis. No, you do not really need us, you really > need cooperation with fellow hackers and you need to get an approved > status in the long run (not immediately). I guess I need to get on that module-authors list (any pointers towards a signup. web searches are proving fruitless. and off-topic: where is that damn advocacy list?). I've tried discussing some of these issues on c.l.p.mod but the newsgroup (and all of them in general) is so cluttered with noise and the vast majority of readers are newbies with CGI questions that it seemed fairly useless. > You are not going to go to the small claims court with us, are you? Hehe, no, that doesn't seem to be very sensible. > Informally we deal with it such that you do not own the namespace and > do not have the final say. We'll seek your advice on everything > related to "your" namespace, but other interests may need to be > balanced against yours and we will try to never be rude and always be > Salomonic. Sometimes this doesn't work out and then we do not sleep > well (or not at all), but more often it workes somehow, magically. That's certainly fine. I guess I'd just want to know if someone wanted to upload a bunch of stuff into a namespace I know. The only time that someone has wanted to this so far she contacted me first and we discussed it before it went to this list, which is obviously the best way to handle things. > See above. I really think you need to actively recruit some more help then. > > 1. Nobody really notices that sentence. > > Are you sure? Ok, I'm exaggerating for dramatic effect! > You're right:-) Yes, we could add something like, "but don't take our > words seriously because they really aren't true!", but wouldn't people > be upset then? There's no way out. We are an institution and we are > not an institution at the same time. If you know what I mean. I think you (plural) have to work towards becoming a little more institutionalesque. > You have write access to the list. If we add the comfortable > read-per-mail access, we have nothing but an ordinary mailing list. > But we want a place to *work*. This is publically accessible, as to > make our decision making process visible to the community. But if we > start using it as an ordinary mailinglist, we will have to go > elsewhere to get our work done. Hmm, I'm still not convinced. Ok, there's this modules-discuss list. Maybe some filtered version of what goes to [EMAIL PROTECTED] should go there? I need to subscribe to this modules-authors list somehow I guess. > "Me too" (no sarcasm). I'd really like to see things progress. Your > thoughts are very welcome. Well, like I've said twice so far. I think the real problem is lack of tuits. Solution: get more people to help. We've already got great infrastructure with CPAN so I think its just a matter of available free time. thanks, -dave /*== www.urth.org We await the New Sun ==*/
Re: two new ones
On Tue, 27 Jun 2000, Graham Barr wrote:
> If you are to discuss anything it should be open. Why have subscriber-post-only ?
Because if you don't care enough to subscribe then you shouldn't be able
to post. That's just my general mailing list philosophy (and it helps
prevent some random spam I think).
> > I strongly disagree. As try/catch is not built into Perl
>
> Yet. Last year there was the intent to have it so that it would look like
> it was built in. Pushing the API levels down does not give that impression.
Ugh. But that's only IMHO. I really think the try/catch stuff is
superfluous given eval {}/$@->isa. All that's missing is finally I
suppose but that's not hard to do either.
eval { MayCauseException(); };
my $e = $@;
finally_do_something();
if ($e->isa('Foo')) { ... }
The rest is syntactic sugar. Some people may want it, some may not.
> While I welcome discussion, I would just like to restate that there has been a *lot*
> of discussion on this in the past. But there are too many people who are passionate
> about the exception handling in some other language and want perl to mimic it.
> The result is that you never get a concensus, at least we never have in the
> past.
Ok, but I'm not sure see I see a better way for you to organize this
besides total dictatorial mandate, in which case I might as well give up
and go home. I honestly don't think its fair for you to say that your
implementation should be the top-level without some discussion (although
maybe this discussion already happened and I'm just a latecomer?). A
mailing list seems well suited to this. [EMAIL PROTECTED] is extremely not
suited for this, seeing as how very few people who aren't the core
[EMAIL PROTECTED] people will ever see our discussion.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: two new ones
On 27 Jun 2000, Andreas J. Koenig wrote: > > Devel::StackTrace > > Exception::Class > > Exception::Class::Base > > OK, noted. Will add it to the module list later today. I just noted that Devel::StackTrace has something it uses internally called StackTraceFrame (as the trace is really a set of frame objects that you can step through in either direction). I'm renaming that to Devel::StackTraceFrame. Does that seem acceptable? > Indeed, what's needed is better visibility of the existing solutions. > Please cross reference heavily. I'll add a prominent section about try/catch and where to find it to Exception::Class. Hopefully that'll help. -dave /*== www.urth.org We await the New Sun ==*/
