Summer is coming up, and so is the Google Summer of Code. We did well last year, but one thing I think we can improve is to have more project proposals. I particularly like the long list the FreeBSD project has managed to build.
So, I'd like your project ideas. What can be achieved in a few weeks of hacking that would be beneficial to your modules/projects/CPAN/life?
Re:PDL
acme on 2006-04-17T11:27:48
As far as I know, PDL development is pretty slow thesedays and I'm not sure that there is any Perl6/Pugs work in that area yet. Are there useful numerical/statistical C libraries that people are using instead?Re:PDL
hezekiah on 2006-04-17T17:13:44
The GNU Science Library may be worth looking at if you are thinking along the lines of a Perl wrapper. A few GSL pieces are used in PDL, but only a very limited subset. It would be nice to have a proper GSL binding for Perl - I don't know that there are any other bindings with the same functional coverage that this would provide.
What can be achieved in a few weeks of hacking
I'd say eight weeks of hacking, for an average student.
And yes, eight weeks of full time hacking. Given that Google are (generously) paying at a rate equivalent to $27,000 per year, my non-humble opinion is that any student not giving their full time attention is slacking. How many other student summer jobs pay $14/hour?
correction, "few weeks" is really 12 weeks
nicholas on 2006-04-18T16:45:38
Actually, turns out I'm about a year out of date. SoC runs for 3 months this year, so that's more like twelve weeks
I really don't feel that the suggestions are sufficiently epic in scale. I believe we need to think bigger, such as:
- Integrate PPI into Eclipse to provide full Perl refactoring support
- (I've never used or needed to use Eclipse, but I assume that this is plausible and useful from perusing their documentation. See also Perl Needs Better Tools)
- Check and when possible close every open Perl bug
- There are 1500 open core perl bugs in RT. It would be good to check every bug to see whether it's been responded to, whether it's still a bug, and if so write a test case. Three months means 20 minutes on average per bug, so completing this task is feasible. So it's of the correct scale of epicness for SoC, although in fairness I don't think that this is a good proposal, as there's not enough coding in it, and any one person trying to do this would go insane
- Migrate core perl from perforce to subversion
- This isn't a trivial task to get right. Tools exist, but they aren't good enough to migrate the nearly 30000 changes racked up in the past 9 years. In particular, they fail to preserve the existing complex branching history, which we need to preserve for code auditing purposes. So this task would involve improving the existing migration tools, or writing more powerful new ones, rather than a simple sysadmin fire-it-off task.
What could existing Perl projects such as DateTime, Module::Build or bioperl achieve with a 3 months of full time work?
Re:Wiki::Tiny
Louis_Wu on 2006-04-17T20:11:11
- One file.
- Downloadable.
- Wiki-like MicroContent chunks.
- StuddlyCaps linking/titling of content chunks.
- Everything is in that one web page on your USB stick drive.
All made possible throught the magic of Javascript, HTML, and CSS.
I'm using a TiddlyWiki to track lots of little parts of a project, and d-cubed to do GTD at work. (Google Group version update release)
Re:Wiki::Tiny
Aristotle on 2006-04-17T21:20:59
That would hardly take 8 weeks of full-time hacking. It could be done in about three days of full-time hacking. Make that a week if you want a large array of bells and whistles, maybe.
I mean, I built a wiki into the web app for my contract job by accident when I needed to make snippets of my templates user-editable. 20 minutes, one (name, content) table, 10 lines of straightforward code, 3 trivial queries in the DB layer and 10 sparse lines of template later I had something that took a life of its own as a wiki within three days of going live. It acquired some more work since, after we decided to officially repurpose it, but all told, I invested maybe 4 hours so far and what I have is decidely enough to pass as a solid wiki.
Re:Wiki::Tiny
Alias on 2006-04-18T05:07:31
And it had history? Or did you implement a scratchpad?
Administrative code? User authentication? Template editing, image support?
One of the features of wikis is you can write on in 5 minutes, or you can have people working full time for years (MediaWiki).
And everything in between.
And 8 weeks worth of features, in a one file wiki, would be nice.
But I'll look at the one suggested above instead.Re:Wiki::Tiny
Aristotle on 2006-04-18T06:15:50
Didn’t have history at first, but does now. That was one of the new features. Took an hour or so.
User authentication was provided by the part of the app that was already in place, but that too is quite simple; it only takes appreciable time if you want finegrained permissions.
Not sure what template editing refers to.
I don’t have image support at the time being. Upload management would indeed be somewhat time-consuming to implement. (In my case though the work is already done in another part of the app, so that too won’t take much effort to add.)
I don’t know if MediaWiki is a good example. I find its feature set bloated and oddly shaped. Also, it was evolved by the needs one particular installation, and some features have been reimplemented multiple times, yet all iterations must be kept around because they can’t break any existing articles. In other words, MediaWiki has a rather unique set of design constraints, and in my opinion therefore counts as atypical.
I dunno, 8 weeks of features just sounds like way more stuff than the “wiki threshold,” ie. the feature set where doing the most obvious thing leads you to the relevant feature which is instantly useful without having to learn it.
Shrug. It doesn’t really matter anyway, it’s the Googlers’ call.
I’m just thinking that framing it as an 8-week-project makes it look so grandiose that it might not be tackled by whoever shares the itch and might otherwise have sufficient spare tuits.
I dunno if you’ve tried writing a wiki; I knew they’re quite trivial, but I was still shocked to experience first hand just how little props them up. That’s really all I was trying to relay here.
Re:Wiki::Tiny
Qiang on 2006-04-18T03:27:15
oddmuse http://www.oddmuse.org/
It's one Perl file and content saved in files. a file based wiki is as good as a sqlite supported one.
Re:CPAN Subversion
Alias on 2006-04-17T18:09:31
Install WHAT direct from WHICH subversion exactly?
I mean, I just wrote a script for my current client which does that for the dozen non-CPAN (and a few CPAN) dists that need to be installed to set up a particular system.
Takes a list of tarball names, pulls them from the/releases/ dir in subversion, perl Makefile.PL, make, make test, make install, setting PREFIX and PERL5LIB etc.
It's maybe 100 lines and took 2 hours.
While it might be nice to have a generalised form, I'm not sure it's makes for an 8 week project.
Re:CPAN Subversion
Aristotle on 2006-04-17T21:23:07
SVN4CPAN? It’s abandoned, but the bits are there for the taking.
That would indeed be very worthwhile.
Re:CPAN Subversion
Eric Wilhelm on 2006-04-30T19:15:24
Not really abandoned, just not economically feasible for an out-of-work plumber such as myself to spend lots of time on it while watching the account balance drift toward homelessness.
I'll mentor any part of it for SoC. Watch this link for updates.
