upstream-devel Mailing List for Upstream Log Transfer System (Page 5)
Status: Alpha
Brought to you by:
mweerasinghe
Menu
▾
▴
upstream-devel — Upstream Developer List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(11) |
Oct
(29) |
Nov
(27) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(5) |
Feb
(11) |
Mar
(9) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ryan Z. <rze...@co...> - 2006-10-04 20:22:59
|
Dear folks, As I work on the current status of the multiple module loaders, my two goals have been to increase fault tolerance in the loader and to share as much code as possible between the loaders themselves. That means, that fundamentally, the execute statement for a log loader module should take a different number of arguments than a module for a submission. So, I ask you this, should both execute() statements take exactly 1 argument, or should they instead take a different number that will be validated by each subordinate module loader. It is largely a cosmetic difference as instead of executing module.execute(email, support, log) one could instead call something simple like module.execute( (email, support, log) ) and then inside of the module do something like email, support, log = execute_parameter I leave this up to the sensibilities of others, since my personal preference doesn't really matter since I am not the one writting most of these modules. Furthermore, I also wanted to get a feeling for the current specification for SubmitModuleResult objects. Currently the parameter order is bool_ispaste, bool_success, result_url=None, result_xml=None It has occured to me, that result_url and result_xml are out of order, since if we are not using a pastebin, then result_url will always be None or invalid, while result_xml will probably have content. This forces the module writter to do something like return SubmitModuleResult(False, True, None, returned_content) which is somewhat strange looking, especially since with default arguments and a reordering of parameters, that could be reduced to SubmitModuleResult(False, True, returned_content) Just some thoughs, and wondering what ya'll think about it. Ryan |
|
From: Mahangu W. <ma...@gm...> - 2006-10-04 12:30:39
|
That's fine, Joel. Thanks for the heads up. On 10/2/06, Joel Pan <toa...@ke...> wrote: > I probably won't be at this week's dev meeting as I'm still in Pacific > time now and it's during office hours for me. Next week onwards, when > I'm back in Singapore time and it's Tuesday morning 7.30am... well > that's a totally different story and I'll see what happens. > > -ketsugi > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Upstream-devel mailing list > Ups...@li... > https://lists.sourceforge.net/lists/listinfo/upstream-devel > |
|
From: Joel P. <toa...@ke...> - 2006-10-02 02:55:14
|
I probably won't be at this week's dev meeting as I'm still in Pacific time now and it's during office hours for me. Next week onwards, when I'm back in Singapore time and it's Tuesday morning 7.30am... well that's a totally different story and I'll see what happens. -ketsugi |
|
From: Ryan Z. <rze...@co...> - 2006-09-27 01:36:55
|
I've attached a pdf file containing the specification I think would be useful for how our module loading/etc should work. <disclaimer> I've never written any kind of feature specification before, so I just wrote it in a free form format that I thought made sense. As such, I apologize if I was completely off the ball </disclaimer> That being said, feel free to comment on it, or suggest ways in which it could be more specific, or better, or improved upon. Once we agree on this, I will be willing to try and implement the things described. Regard, Ryan |
|
From: Mahangu W. <ma...@gm...> - 2006-09-26 09:49:21
|
Hi All, Spent the afternoon adding output module functionality to Upstream-base. So now (hopefully), those of you who are interested will be able to look at the spec and write your own pastebin modules. If anyone is looking for a quick project, a paste.ubuntu-nl.org plugin will be pretty sweet. Also, any tweaks to the modules code will be great - I'm not the most methodical of programmers. ;-) Anyway Ryan, hopefully set_modules_dir() and read_module() will be pretty straightforward for you to hook in to Canoe. I've setup some basic error catching, but neither of the two raise exceptions yet. I'll look in to this over the next few days. In any case, things look good. Now that -base is almost done (we just need those ubuntu paste plugins), I think we can safely concentrate our efforts on Kanoe. Anyway, good job people, and let's keep going. - Mahangu |
|
From: Mahangu W. <ma...@gm...> - 2006-09-25 02:36:48
|
As Ryan has said, I think our primary concern with Upstream is portability. We want it to be as small and lightweight as possible. GtkAssistant might be worth looking in to, as long as the deps dont bloat up because of it. In reality though, we want Upstream to be able to run anywhere there is a python base installation. In writing code, please coordinate with Ryan, and send .diff s direct to this list. I'll work on getting you svn commit access within the next few days. On 9/25/06, Ryan Zeigler <rze...@co...> wrote: > I don't see any problem with the GtkAssistant, I honestly didn't take > the time to look at the new stuff that is in 2.10. As for > GnomeVFSAsync, I am hesitant to use that, especially since our thread > class is so tiny as it is, and to use a GnomeVFS call we effectively > would make any KDE frontend depend on a core component of gnome. This > is also an issue on mac os x, where I'm not sure that gnomevfs will even > run. > > Ryan > > On Sun, 2006-09-24 at 15:01 +0100, Vassilis Pandis wrote: > > Hi, > > > > I'm neutrinomass from IRC. lastnode offered to take some free time off = my hands and redirected me > > to this list :-) I am interested in contributing. I can do C/GTK+ but I= 'm learning python as well > > so maybe I can help out. Any pointers as to what is left to be done wou= ld be nice. > > > > In the meantime, I did a checkout and took at look at the GTK+ frontend= : > > > > 1. Maybe use GtkAssistant as a wizard > > (http://developer.gnome.org/doc/API/2.0/gtk/gtk-migrating-GtkAssistant.= html ) > > > > 2. If GtkAssistant is not used, maybe use libglade? It makes code much = simpler and also makes UI > > changes trivial > > > > 3. Instead of threads (RadiantFire ;) ) what about GnomeVFSAsync functi= ons? > > > > > > I'm not trying to enforce anything, just dropping ideas on the table. F= eel free to ignore them. > > The idea looks very good and hopefully will make support much easier :-= ) > > > > > > > > > > > > ___________________________________________________________ > > All New Yahoo! Mail =96 Tired of Vi@gr@! come-ons? Let our SpamGuard pr= otect you. http://uk.docs.yahoo.com/nowyoucan.html > > > > -----------------------------------------------------------------------= -- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share= your > > opinions on IT & business topics through brief surveys -- and earn cash > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID= =3DDEVDEV > > _______________________________________________ > > Upstream-devel mailing list > > Ups...@li... > > https://lists.sourceforge.net/lists/listinfo/upstream-devel > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Upstream-devel mailing list > Ups...@li... > https://lists.sourceforge.net/lists/listinfo/upstream-devel > |
|
From: Ryan Z. <rze...@co...> - 2006-09-24 21:41:08
|
I don't see any problem with the GtkAssistant, I honestly didn't take the time to look at the new stuff that is in 2.10. As for GnomeVFSAsync, I am hesitant to use that, especially since our thread class is so tiny as it is, and to use a GnomeVFS call we effectively would make any KDE frontend depend on a core component of gnome. This is also an issue on mac os x, where I'm not sure that gnomevfs will even run. Ryan On Sun, 2006-09-24 at 15:01 +0100, Vassilis Pandis wrote: > Hi, > > I'm neutrinomass from IRC. lastnode offered to take some free time off my hands and redirected me > to this list :-) I am interested in contributing. I can do C/GTK+ but I'm learning python as well > so maybe I can help out. Any pointers as to what is left to be done would be nice. > > In the meantime, I did a checkout and took at look at the GTK+ frontend: > > 1. Maybe use GtkAssistant as a wizard > (http://developer.gnome.org/doc/API/2.0/gtk/gtk-migrating-GtkAssistant.html ) > > 2. If GtkAssistant is not used, maybe use libglade? It makes code much simpler and also makes UI > changes trivial > > 3. Instead of threads (RadiantFire ;) ) what about GnomeVFSAsync functions? > > > I'm not trying to enforce anything, just dropping ideas on the table. Feel free to ignore them. > The idea looks very good and hopefully will make support much easier :-) > > > > > > ___________________________________________________________ > All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Upstream-devel mailing list > Ups...@li... > https://lists.sourceforge.net/lists/listinfo/upstream-devel |
|
From: Mahangu W. <ma...@gm...> - 2006-09-24 14:55:21
|
Hello All, If you read the logs from the Sept 22nd meeting with imbrandon, you'll notice that we have till November 5th to produce a working Alpha. I think we're already well on our way there, so no worries really. However, I thought it'd be good to map out a timeline for ourselves. Since we need to have a semi-stable app by the 5th of November, I'm suggesting this schedule. Please feel free to append any changes. 6th October - canoe feature freeze 13th October - upstream-base feature freeze 21st October - kanoe feature freeze 28th October - testing is over 29th October - package and release on sf.net - Mahangu |
|
From: Mahangu W. <ma...@gm...> - 2006-09-24 14:46:20
|
Welcome aboard Vassilis! I'm sure Ryan will appreciate your help with the gtk client. There are also some things that need to get done in upstream-base as well, but let's keep this thread for gtk related discussions. :-) Knock yourselves out, gentlemen. On 9/24/06, Vassilis Pandis <pa...@ya...> wrote: > Hi, > > I'm neutrinomass from IRC. lastnode offered to take some free time off my= hands and redirected me > to this list :-) I am interested in contributing. I can do C/GTK+ but I'm= learning python as well > so maybe I can help out. Any pointers as to what is left to be done would= be nice. > > In the meantime, I did a checkout and took at look at the GTK+ frontend: > > 1. Maybe use GtkAssistant as a wizard > (http://developer.gnome.org/doc/API/2.0/gtk/gtk-migrating-GtkAssistant.ht= ml ) > > 2. If GtkAssistant is not used, maybe use libglade? It makes code much si= mpler and also makes UI > changes trivial > > 3. Instead of threads (RadiantFire ;) ) what about GnomeVFSAsync function= s? > > > I'm not trying to enforce anything, just dropping ideas on the table. Fee= l free to ignore them. > The idea looks very good and hopefully will make support much easier :-) > > > > > > ___________________________________________________________ > All New Yahoo! Mail =96 Tired of Vi@gr@! come-ons? Let our SpamGuard prot= ect you. http://uk.docs.yahoo.com/nowyoucan.html > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Upstream-devel mailing list > Ups...@li... > https://lists.sourceforge.net/lists/listinfo/upstream-devel > |
|
From: Vassilis P. <pa...@ya...> - 2006-09-24 14:01:20
|
Hi, I'm neutrinomass from IRC. lastnode offered to take some free time off my hands and redirected me to this list :-) I am interested in contributing. I can do C/GTK+ but I'm learning python as well so maybe I can help out. Any pointers as to what is left to be done would be nice. In the meantime, I did a checkout and took at look at the GTK+ frontend: 1. Maybe use GtkAssistant as a wizard (http://developer.gnome.org/doc/API/2.0/gtk/gtk-migrating-GtkAssistant.html ) 2. If GtkAssistant is not used, maybe use libglade? It makes code much simpler and also makes UI changes trivial 3. Instead of threads (RadiantFire ;) ) what about GnomeVFSAsync functions? I'm not trying to enforce anything, just dropping ideas on the table. Feel free to ignore them. The idea looks very good and hopefully will make support much easier :-) ___________________________________________________________ All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html |
|
From: Mahangu W. <ma...@gm...> - 2006-09-24 09:54:03
|
Fyi, when we get to creating our debs. http://www.debian.org/doc/packaging-manuals/python-policy/ |
|
From: Mahangu W. <ma...@gm...> - 2006-09-22 01:57:58
|
Hello All, If you read the logs from the Sept 22nd meeting with imbrandon, you'll notice that we have till November 5th to produce a working Alpha. I think we're already well on our way there, so no worries really. However, I thought it'd be good to map out a timeline for ourselves. The areas we have chosen to focus on are as follows - Ryan - Canoe niceties, and cleaning up etc. Joel - Modularizing upstream-base. Mahangu - Minor upstream-base code brush ups, possible Kanoe development. Again, I think Ryan will be done with Canoe pretty early (since he's already finished with much of it anyway), and if he's free thereafter, should be able to help with Kanoe, hopefully. I'll get started with python-qt, but I have my semester finals throughout October, so am not sure how much time I'll be able to put in to it. So, since we need to have a semi-stable app by the 5th of November, I'm suggesting this timeline. Please feel free to append any changes. 6th October - canoe feature freeze 13th October - upstream-base feature freeze 21st October - kanoe feature freeze 28th October - testing is over 29th October - package and release on sf.net I have no idea if this is doable or not. I know Joel is abroad for work during this time, and that Ryan has classes too, but I'm pushing back the Kanoe feature freeze because er, we still don't have a single line of code. Anyway, let's hear what you guys have to say. - Mahangu |
|
From: Mahangu W. <ma...@gm...> - 2006-09-22 01:43:08
|
Timestamps in SGT (GMT+8) [Fri Sep 22 2006] [00:09:52] <imbrandon> ok back, meeting isnt done but i can dfinish it after bit, wasup guys ? [Fri Sep 22 2006] [00:10:40] <lastnode> imbrandon, we got ourselves a sf account - http://sourceforge.net/projects/upstream/ [Fri Sep 22 2006] [00:10:58] <lastnode> and RadiantFire here wrote canoe in python (it was originally written in C). [Fri Sep 22 2006] [00:11:07] <imbrandon> ;) [Fri Sep 22 2006] [00:11:19] <lastnode> upstream now reads its options from a .conf file, and so adding / deleting logs and situations is easy peasy [Fri Sep 22 2006] [00:11:39] <RadiantFire> what would be fun is if I could add buttons in the dialog on the fly based on what is in the conf file [Fri Sep 22 2006] [00:11:45] <RadiantFire> I will investigate that in the future [Fri Sep 22 2006] [00:11:58] <imbrandon> RadiantFire: that should be doable [Fri Sep 22 2006] [00:12:01] <imbrandon> yea [Fri Sep 22 2006] [00:12:07] <lastnode> ketsugi killed my icky curl code and used pycurl for it instead. so now everything (except the way we cat logs) is via a python built in. [Fri Sep 22 2006] [00:12:41] <lastnode> we'd just like to talk a little about where we're going, and the reality (if there is one) of this getting in to ubuntu some day. and any thoughts / suggestions would be more than welcome, of course. [Fri Sep 22 2006] [00:13:13] <imbrandon> sure [Fri Sep 22 2006] [00:13:39] <imbrandon> pythin has some nice text file functions too [Fri Sep 22 2006] [00:14:06] <RadiantFire> p.s. instead of using ugly dmesg reading, we couuld read kern.log instead [Fri Sep 22 2006] [00:14:08] <RadiantFire> i think they are identical [Fri Sep 22 2006] [00:14:09] <imbrandon> python , sorry for my slowness today , we're really busy with the beta release and dev summit and tons of other stuff ;) [Fri Sep 22 2006] [00:14:11] <RadiantFire> ok, I'm really leaving onw [Fri Sep 22 2006] [00:14:27] <lastnode> imbrandon, not a problem. we appreciate your time here. [Fri Sep 22 2006] [00:14:27] <imbrandon> RadiantFire: yea they are identical [Fri Sep 22 2006] [00:14:34] <lastnode> RadiantFire, sure mate, see you tomorrow. [Fri Sep 22 2006] [00:15:14] <imbrandon> i'll try to keep this on my autojoin , but you all feel free to ask me stuff anytime, lastnode i see you ping me once in a while but we /just/ seem to miss each other ;) [Fri Sep 22 2006] [00:15:30] <lastnode> yeah :-) [Fri Sep 22 2006] [00:15:35] <imbrandon> so hows it looking so far? [Fri Sep 22 2006] [00:15:55] <lastnode> well we're planning an alphaish release around the end of october [Fri Sep 22 2006] [00:15:56] <imbrandon> is the backend and the gtk/qt stuff seperated ? just curious [Fri Sep 22 2006] [00:16:08] <ketsugi> lastnode has a nasty habit of pinging people and then getting disconnected >_> [Fri Sep 22 2006] [00:16:11] <lastnode> imbrandon, yes, if you check the repos you'll see upstream-base and canoe [Fri Sep 22 2006] [00:16:16] <lastnode> canoe being the frontend [Fri Sep 22 2006] [00:16:26] * lastnode sends ketsugi upstream [Fri Sep 22 2006] [00:16:26] <imbrandon> lastnode: nice , just in time to get it really rocking by december and running in edgy+1 from the begning [Fri Sep 22 2006] [00:16:54] <ketsugi> imbrandon, is there an "official" Ubuntu pastebin or something that we can use to post logs? [Fri Sep 22 2006] [00:16:59] <imbrandon> canoe gtk only ? or is there a canoe-gtk and canoe-qt ? [Fri Sep 22 2006] [00:17:17] <ketsugi> imbrandon: hopefully at some point there'll be Canoe and Kanoe [Fri Sep 22 2006] [00:17:19] <lastnode> imbrandon, canoe-qt has to be written, but RadiantFire says that many of his classes can be reused [Fri Sep 22 2006] [00:17:31] <imbrandon> ketsugi: i can get the logbot in here ( and other ubuntu bots too ) is you want [Fri Sep 22 2006] [00:17:39] <imbrandon> lastnode: nice [Fri Sep 22 2006] [00:17:42] <lastnode> imbrandon, that would be great, thanks. [Fri Sep 22 2006] [00:17:53] <imbrandon> s/is/if [Fri Sep 22 2006] [00:17:56] <ketsugi> Yeah, I don't want us to keep spamming the lisp paste-bin ;/ [Fri Sep 22 2006] [00:18:06] <imbrandon> heh [Fri Sep 22 2006] [00:18:19] <lastnode> imbrandon, is it ok to use the pastebot for testing though? [Fri Sep 22 2006] [00:18:28] <imbrandon> most of the time as far as pastebins we just use paste.ubuntu-nl.org [Fri Sep 22 2006] [00:18:43] <imbrandon> or pastebin.ca [Fri Sep 22 2006] [00:18:48] <lastnode> right [Fri Sep 22 2006] [00:19:03] <imbrandon> but for channel logs there is a ubuntu logbot [Fri Sep 22 2006] [00:19:23] <imbrandon> and ofcource ubugtu and ubotu [Fri Sep 22 2006] [00:19:25] <lastnode> imbrandon, we're thinking of having a /modules/ dir, and having different config files for each pastebin/site. so then devs can just write a .conf and dump it in, and it will appear in options [Fri Sep 22 2006] [00:19:54] <lastnode> (well that's the plan) [Fri Sep 22 2006] [00:20:02] <imbrandon> lastnode: soudsn great, thats what apache2 does with sites-avaible and sites-enabled [Fri Sep 22 2006] [00:20:02] * lastnode looks nervously at ketsugi :P [Fri Sep 22 2006] [00:20:14] <ketsugi> should be doable [Fri Sep 22 2006] [00:20:19] <lastnode> imbrandon, yeah, that was one of the inspirations :-) [Fri Sep 22 2006] [00:20:31] <lastnode> (i think - who suggested that? was it I? :s) [Fri Sep 22 2006] [00:20:54] <ketsugi> not me! [Fri Sep 22 2006] [00:21:00] <lastnode> so anyway, just to clarify those things. we'll let you get back, imbrandon. but as far as we're concerned, this has to be polished and ready by end of november? [Fri Sep 22 2006] [00:21:39] <imbrandon> polished no, but someinthg alphaish would be nice by nov 05 so i can show it off a bit at the dev summit ;) [Fri Sep 22 2006] [00:22:13] <lastnode> right, that would rock. november 5th it is then. [Fri Sep 22 2006] [00:22:21] * lastnode has gotta do some reading on py-gt [Fri Sep 22 2006] [00:22:23] <lastnode> *qt [Fri Sep 22 2006] [00:22:39] <imbrandon> ;) [Fri Sep 22 2006] [00:22:59] <imbrandon> ok fella's i'm gonna get back to the ubuntu-meeting , feel free to poke me anytime [Fri Sep 22 2006] [00:22:59] <lastnode> sweet, imbrandon, thanks again for your time, and feel free to idle in here. :-) the bots would be great too. [Fri Sep 22 2006] [00:23:07] <lastnode> thanks again! [Fri Sep 22 2006] [00:23:10] <imbrandon> np (Thanks Ketsugi). |
|
From: Ryan Z. <zei...@gm...> - 2006-09-19 22:07:24
|
I seem to have come across my first little snag when attemping to code
up a pygtk frontend. The
import functions
crashes with the following output
Traceback (most recent call last):
File "./canoe.py", line 25, in ?
import functions
File "/home/ryan/Projects/upstream/upstream-base/functions.py", line
23, in ?
config.readfp(open('conf/main.conf'))
IOError: [Errno 2] No such file or directory: 'conf/main.conf'
Obviously the problem with this lies in the fact that the config file is
hardcoded. If the functions module is imported from anywhere other than
the location it is already located, the system crashes. If someone
could remove all of the hardcoding and instead provide hooks such as
set_conf_dir(dir_path)
this problem would be alleviated. We could furthermore raise an
exception if any functions are implemented without the configuration
paths being set, thus preventing undefined behavior.
Regards,
Ryan
|
|
From: Mahangu W. <ma...@gm...> - 2006-08-30 13:13:33
|
Cool. Joel rewrote upstream-base to use the pycurl, so any feedback on how Canoe likes that will be much appreciated. I'll get him added to this list as well. Btw, all archives will be public someday, just so you know. :p On 8/30/06, Ryan Zeigler <rze...@co...> wrote: > Seems to be working. I'm set up here at school so I will be able to be > useful again hopefully. And ironically, my Artificial Intelligence > class this semester will be using Python. > Ryan > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Upstream-devel mailing list > Ups...@li... > https://lists.sourceforge.net/lists/listinfo/upstream-devel > |
|
From: Ryan Z. <rze...@co...> - 2006-08-30 12:52:44
|
Seems to be working. I'm set up here at school so I will be able to be useful again hopefully. And ironically, my Artificial Intelligence class this semester will be using Python. Ryan |
|
From: Mahangu W. <ma...@gm...> - 2006-08-30 09:58:42
|
Hi Ryan, Let me know if you get this. I think I got everything setup alright. - Mahangu |
|
From: Ryan Z. <zei...@di...> - 2006-08-28 15:17:41
|
I figured I would test this list and see if it works, since I haven't actually gotten anything off it. Ryan |