On 3 May 2013 11:57, [email protected] <[email protected]> wrote: >> [Sorry, I've only noticed now that the email didn't send!] >> > > No problem. > > I got some work for this summer, so I don't think I can give GSoC ~30h/week. > Won't apply this year. If (as expected) I get some free time late June, I'll > do the configuration file generation improvements. >
That's a pity, but best of luck with the job! >> That seems wrong. There should be no reason for this to happen. The >> maximum that I would expect from a dixtools-based tool to do this >> would be a few seconds. Perhaps you should investigate that? > > > It does not use dixtools, but some bash + xslt. Of course, it should not > take more than a couple of minutes. > Yeah, I took a (brief!) look at the scripts. I have seen something like this kind of slowdown before, (with EXSLT and xsltproc, IIRC), but nothing struck me as familiar. >> >> > As for uploading, I think nothing can be done. >> >> There are plenty of options. At the most basic, all of our >> interactions with SVN are via HTTP. At the very least, you can provide >> a configuration option to specify the address of the package in SVN, >> then download the files directly from there. With a little more >> effort, there are functions for SVN >> (http://php.net/manual/en/ref.svn.php) so at the very least, you can >> provide the revision number of the dictionaries that have been >> modified. Yet more complicated would be to use git as a backing store >> (e.g., using http://gitorious.org/git-php), and create a branch >> whenever someone edits the dictionaries. Language pair maintainers who >> are able to use git could pull directly, or git's machinery could be >> used to export patch sets. It would even give the option of allowing >> logged in users to pick up where they left off. > > > As is, you can choose to upload the dictionaries and configuration files > from an url, like the ones sourceforge provides for direct download. > Yes, you can pull the individual files straight from SVN. > Interacting directly with repositories seems a good idea, but it requires a > major rework: the tool would need to know how to test the dictionaries > before uploading to the repository. Nowadays, it does not even need Apertium > to work. > I don't think you'd need to trouble yourself with doing more than validating (the XML of) the dictionaries (which is just a DTD-based validation). It'd be nice, sure, to check if they also compile, but as long as the XML is more or less valid, it should be ok. > Another option is downloading the tool and setting it locally. Simpledix > only needs a web server, xsltproc and BaseX, all of them easily installed > (they are part of the official debian repositories). > > As for keeping the progress of the users, if you don't close your session, > you can save the url (that has your id as a get parameter), and keep working > later. But as the tool lacks proper session management, anybody can use that > id, and close your session (erasing your progress), so is not advised to > work that way. > I was just mentioning that as a positive side-effect -- it doesn't overly interest me. I'm far more interested in making it as easy as possible for potential contributors to contribute, and to merge those contributions. Really, I have github's pull requests in mind as the ideal: there's an open source clone called GitLab (http://gitlab.org) and they seem to have this model, so it might not be too hard to port to PHP. -- <Sefam> Are any of the mentors around? <jimregan> yes, they're the ones trolling you ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
