Hi Shlomi On Sat, 2011-03-19 at 08:33 +0200, Shlomi Fish wrote: > Hi Ron (and all), > > thanks for your willingness to contribute to Graph-Easy. I'm CCing this > message to the module-authors mailing list and to Tels, who is the originator > of http://search.cpan.org/dist/Graph-Easy/ . Everybody, Ron has commented on > my blog. > > On Monday 14 Mar 2011 23:32:20 LiveJournal Comment wrote: > > Somebody replied to a LiveJournal post > > (http://community.livejournal.com/shlomif_tech/57021.html) in which Shlomi > > [SNIPPED] > > > Their reply was: > > > > Subject: The future of Graph::Easy > > > > Hi Shlomi > > > > I hear your plea for a co-maint for Graph::Easy. Before volunteering I'd > > like to discuss a few issues. > > OK. > > > > > I didn't see a mailing list for the module, so perhaps reply to my email > > address, which is at the bottom of my home page http://savage.net.au > > unless you think a better forum is available. > > There isn't a mailing list for Graph-Easy AFAIK. I did find your E-mail at > http://savage.net.au/ , but it was using this markup: > > <img src="/assets/images/local/email-address.png" alt="Email address" />
I confess it's meant to be non-clickable in order to be robot-hostile. > This is an accessibility and usability problem. See what I've written about > it > here: > > * http://www.shlomifish.org/meta/FAQ/#obscure_email_addr > > * http://discuss.joelonsoftware.com/default.asp?joel.3.717364.8 > > > > > o I only used Graph::Easy for the first time last week. > > > > o I have the time and ability to work on it, but the implementation > > intimidates me too, after reading a lot of the code :-(. > > > > o I don't have a background in graphing. > > > > o I do have a lot of modules on CPAN. > > > > o The pure-Perl tag is very appealing for sure, but if there's a better > > tool out there, let's adopt it. My philosophy is that my OS is Debian > > (not pure-Perl), and my favourite db is Postgres (likewise), etc, so > > pure-Perl does not blind me to alternatives. > > Well, perl 5 has a lot of code written in C so it's not pure-Perl either. > Still, unless there is a very big performance problem that people need, I > think we can keep it as Perl. OK. Just fishing for ideas. > > > > Issues: > > > > o Should the current parser be maintained? Reluctance is a problem. > > > > I don't have a problem with it being rewritten. It's up to the maintainer. I > haven't inspected the parser too much. OK. > > o Should the current parser be re-written? My time and skills are not a > > problem, but reluctance is. Especially if a better tool is available. > > > > I'm not aware of any. Right. That's the sort of feedback I'm after, even if the answer is Don't know. > > o Should we switch to Parse::RecDescent? I can't tell. > > > > Well, I had a bad experience with Parse::RecDescent, and, as most Damianware, > it tends to have an amazing functionality but be overly smart and > complicated, > and tends to accumulate many bugs that are not dealt with. Agreed! I didn't want to start off with negative comments. I'm curious though if this had been considered and stalled due to lack of tuits, or rejected. > There are other parser generators available on CPAN. Recently I became > interested in http://search.cpan.org/dist/Parser-MGC/ , but it's too bad the > main POD contains too few meaningful examples. I first saw it a couple of days ago. I suppose http://search.cpan.org/dist/Marpa/ is another possibility. > > o Should we switch to a non-Perl package? I don't have the breadth of > > knowledge to tell. > > Non-Perl package? Why do you want to include XS (or whatever) code there? To outsource the maintenance :-). And... > > > > o I understand switching would possibly mean abandoning various things > > such as specific output formats or some layout control. > > Why? As per the last point. If a pre-existing, well-supported tool was available, even with differing input syntax, I'd at least like to look into such a choice. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622
