Hi guys, you can use a small script to extract the latest "global" revision number; for SVN, use svn info: svn info | grep "Revision:" Revision: 841 $ svn info | grep "Revision:" Revision: 841 For git, you can use the following:
$ git rev-parse --short HEAD 97d20f5 Cheers, Christian Lane Schwartz <[email protected]> hat am 29. September 2011 um 16:14 geschrieben: > Christian, > > You're correct, using the $Revision$ tag is the comment way to handle > this in svn. > > The problem is that this will embed the latest version number where > that particular file changed. > > What we want here is the latest revision where any file changed. > > Cheers, > Lane > > > On Thu, Sep 29, 2011 at 10:11 AM, Christian Hardmeier <[email protected]> wrote: > > I believe a common way to achieve this in svn is to put a $Revision$ tag > > somewhere in the file and set the keywords property on the file so svn > > modifies the tag appropriately: > > http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html > > > > Git doesn't seem to do that. This page has a discussion about embedding > > revision IDs in Latex documents which should mutatis mutandis work for C++, > > too: > > http://thorehusfeldt.net/2011/05/13/including-git-revision-identifiers-in-latex/ > > > > I've never tried this, though. > > > > /Christian > > > > On 29.09.2011, at 15:55, Lane Schwartz wrote: > > > >> This info is available for svn by calling svnversion. One way to embed > >> this would be as follows: > >> > >> In the Makefile, add a line like this: > >> > >> export SVN_VERSION:=$(shell svnversion) > >> > >> That will set an environment variable with the svn version number. You > >> should be able to then use this in some sort of ifdef or macro to get > >> it embedded into the appropriate binary. > >> > >> > >> You can get similar info from git by using the following: > >> > >> git show-branch --sha1-name > >> > >> > >> Cheers, > >> Lane > >> > >> > >> On Thu, Sep 29, 2011 at 9:02 AM, Lane Schwartz <[email protected]> wrote: > >>> I know there's a way to put in the svn revision number. Not sure about > >>> git. > >>> > >>> On Thu, Sep 29, 2011 at 8:05 AM, Hieu Hoang <[email protected]> wrote: > >>>> it seems like squishing everything into a bin directory is a good idea > >>>> for people who want to set their PATH variable to it. > >>>> > >>>> it would be useful to do > >>>> moses --version > >>>> train-model.perl --version > >>>> and see when or which svn/git version it was built on. Didn't think it > >>>> was possible but you might know better > >>>> > >>>> On 28/09/2011 16:55, Barry Haddow wrote: > >>>>> Hi > >>>>> > >>>>> So it looks like a date-stamped release folder is not popular. It would > >>>>> be > >>>>> possible to have a version stamp inserted into the binaries and scripts > >>>>> and > >>>>> have this read by ems - would this be useful? > >>>>> > >>>>> And would a 'make install' be of any use? It would mean that anyone who > >>>>> wanted > >>>>> a date-stamped release could make one with --prefix, and would help > >>>>> users to > >>>>> separate files needed at runtime from those needed at build time. > >>>>> > >>>>> If we do have a 'make install', should the scripts be squished into the > >>>>> bin > >>>>> directory, or have their directory structure preserved? If we go for > >>>>> the > >>>>> latter, then there would be the option of running them from a source > >>>>> directory > >>>>> too. > >>>>> > >>>>> cheers - Barry > >>>>> > >>>>> > >>>>> > >>>>> On Tuesday 27 September 2011 23:53:29 Raphael Payen wrote: > >>>>>> I like your idea of a VERSION.txt file. Maybe containing also the > >>>>>> configure line. > >>>>>> > >>>>>> By the way, there is already a make install which is configurable with > >>>>>> "configure --prefix=..." ; I dont understand if you want more than > >>>>>> this. > >>>>>> > >>>>>> Raphael > >>>>>> > >>>>>> 2011/9/27 Lane Schwartz<[email protected]>: > >>>>>>> I would like to see a true make install option. I don't care what the > >>>>>>> default location is, as long as it's configurable. > >>>>>>> > >>>>>>> At the least, I would prefer to see the binaries (and preferably > >>>>>>> scripts, too) installed to a bin directory within the moses dir > >>>>>>> instead of being spread throughout the source directories. > >>>>>>> > >>>>>>> I agree that it can be useful to know what version you're running on. > >>>>>>> But I don't think time stamped directories are the way to do it. I > >>>>>>> would propose that make install creates a VERSION.txt file that lists > >>>>>>> the svn version number, or some other version number. > >>>>>>> > >>>>>>> Lane > >>>>>>> > >>>>>>> On Tue, Sep 27, 2011 at 6:07 AM, Hieu Hoang<[email protected]> > >>>>>>> wrote: > >>>>>>>> I'd go with Ondrej and avoid any release procedure and run > >>>>>>>> everything > >>>>>>>> in-situ. We can debug and commit scripts easier. > >>>>>>>> > >>>>>>>> Or have a very simple release that moves all executables and scripts > >>>>>>>> into a bin directory. If the user wants to move/rename, it's their > >>>>>>>> choice > >>>>>>>> > >>>>>>>> On 27 September 2011 16:30, Barry Haddow<[email protected]> > >>>>>>>> wrote: > >>>>>>>>> Hi > >>>>>>>>> > >>>>>>>>> I think it's useful to have a date-stamped release directory, so > >>>>>>>>> that > >>>>>>>>> you can > >>>>>>>>> work on the code and have experiments running, but keep tracking of > >>>>>>>>> which version was used in which experiment. Many people at > >>>>>>>>> Edinburgh > >>>>>>>>> make a copy of > >>>>>>>>> the moses binary with the svn version number as suffix on the name. > >>>>>>>>> > >>>>>>>>> How about having a 'make install, which by default installs to a > >>>>>>>>> date-stamped > >>>>>>>>> directory, with the standard bin, lib etc. pattern, with all the > >>>>>>>>> scripts under > >>>>>>>>> bin? How big a change would that be? > >>>>>>>>> > >>>>>>>>> cheers - Barry > >>>>>>>>> > >>>>>>>>> On Friday 23 September 2011 08:46:06 Ondrej Bojar wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> mert-moses-new.pl is outdated, isn't it? There should be only > >>>>>>>>>> mert-moses.pl these days. > >>>>>>>>>> > >>>>>>>>>> The 'scripts releasing' is of mine and dates back to JHU workshop > >>>>>>>>>> in > >>>>>>>>>> 2006. Back then, we were hacking the scripts and running > >>>>>>>>>> experiments > >>>>>>>>>> at the same time, so we needed some track of what version of > >>>>>>>>>> scripts > >>>>>>>>>> was used for that particular failing experiment. > >>>>>>>>>> > >>>>>>>>>> As soon as anyone has some spare time I'd suggest: > >>>>>>>>>> > >>>>>>>>>> - delete the 'releasing' code in the Makefile > >>>>>>>>>> - make sure the main make compiles everything: all moseses, all > >>>>>>>>>> auxiliary binaries in scripts etc. > >>>>>>>>>> - I'd avoid implementing 'make install', because all the tools in > >>>>>>>>>> scripts know where their frieds are sitting in terms of relative > >>>>>>>>>> paths. The install would need to preserve the complicated > >>>>>>>>>> structure > >>>>>>>>>> anyway so there's not much point in having the install as 'cp -r' > >>>>>>>>>> does the same job. > >>>>>>>>>> > >>>>>>>>>> Cheers, O. > >>>>>>>>>> > >>>>>>>>>> On 09/23/2011 09:20 AM, Hieu Hoang wrote: > >>>>>>>>>>> agreed, we were having an offlist moan about the same thing. The > >>>>>>>>>>> separation between decoding& training, and release date-stamp > >>>>>>>>>>> thingy is > >>>>>>>>>>> historical and quite silly. > >>>>>>>>>>> > >>>>>>>>>>> The directories& release procedure has to be rationalised. > >>>>>>>>>>> > >>>>>>>>>>> Someone will do it eventually... > >>>>>>>>>>> > >>>>>>>>>>> On 23 September 2011 14:04, Joerg > >>>>>>>>> Tiedemann<[email protected]>wrote: > >>>>>>>>>>>> By the way, what is the use of a date-stamped directory anyway? > >>>>>>>>>>>> I find if rather disturbing that all the binaries and scripts > >>>>>>>>>>>> are > >>>>>>>>>>>> distributed all over the place. > >>>>>>>>>>>> moses-cmd/src > >>>>>>>>>>>> moses-chart-cmd/src > >>>>>>>>>>>> misc > >>>>>>>>>>>> scripts > >>>>>>>>>>>> released scripts in a date-stamped directory of your choice > >>>>>>>>>>>> ... > >>>>>>>>>>>> > >>>>>>>>>>>> J�rg > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Sep 22, 2011 at 4:34 PM, Barry Haddow > >>>>>>>>>>>> > >>>>>>>>>>>> <[email protected]> wrote: > >>>>>>>>>>>>> Hi Hieu et al > >>>>>>>>>>>>> > >>>>>>>>>>>>> I replied to the OP on this, but forgot to CC it to the list. > >>>>>>>>>>>>> > >>>>>>>>>>>>> There was a change in mert some time in the summer (from > >>>>>>>>>>>>> Prague) > >>>>>>>>>>>>> meaning > >>>>>>>>>>>> that > >>>>>>>>>>>> > >>>>>>>>>>>>> if you run an old mert-moses.perl with a new mert binary, you > >>>>>>>>>>>>> get > >>>>>>>>>>>>> an > >>>>>>>>>>>> error > >>>>>>>>>>>> > >>>>>>>>>>>>> with exit code 3. I suspect this is the problem here since the > >>>>>>>>>>>> scripts-rootdir > >>>>>>>>>>>> > >>>>>>>>>>>>> suggests the scripts are from March. Checking mert.log would > >>>>>>>>>>>>> confirm the diagnosis. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The solution is to rerun 'make release' in the scripts > >>>>>>>>>>>>> directory, > >>>>>>>>>>>>> and > >>>>>>>>>>>>> use > >>>>>>>>>>>> the > >>>>>>>>>>>> > >>>>>>>>>>>>> new scripts-rootdir. > >>>>>>>>>>>>> > >>>>>>>>>>>>> As an aside, I should say that I'm not keen on our two-level > >>>>>>>>>>>>> make > >>>>>>>>>>>>> setup, > >>>>>>>>>>>> and > >>>>>>>>>>>> > >>>>>>>>>>>>> would like to find something simpler. Probably a one level > >>>>>>>>>>>>> make, > >>>>>>>>>>>>> with a > >>>>>>>>>>>>> conventional 'make install', but with the default being to > >>>>>>>>>>>>> install in a > >>>>>>>>>>>> date > >>>>>>>>>>>> > >>>>>>>>>>>>> stamped directory. > >>>>>>>>>>>>> > >>>>>>>>>>>>> cheers - Barry > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thursday 22 Sep 2011 14:59:26 Hieu Hoang wrote: > >>>>>>>>>>>>>> i'm afraid i don't know what the problem is. The n-best-list > >>>>>>>>>>>>>> and > >>>>>>>>>>>>>> ini > >>>>>>>>>>>>>> files look ok. I'm running mert and moses-chart that was > >>>>>>>>>>>>>> checked > >>>>>>>>>>>>>> out > >>>>>>>>>>>>>> on the 13th September and ran ok. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> i'm not familiar with the mert code so i can't tell you if the > >>>>>>>>>>>>>> changes > >>>>>>>>>>>>>> you made are good. However, you're welcome to post the changes > >>>>>>>>>>>>>> to the > >>>>>>>>>>>>>> mailing list and someone might be know better than i do. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 22/09/2011 15:34, Prasanth K wrote: > >>>>>>>>>>>>>>> Hi Hieu, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I am attaching the following files: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> multi-threads_tune-run1.100best.out - first 1000 lines from > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>> multi-threaded decoder > >>>>>>>>>>>>>>> single-threads_tune-run1.100best.out - the same from the > >>>>>>>>>>>>>>> single-threaded decoder > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> multi-threads_tune-run1.moses.ini - the ini file used at the > >>>>>>>>>>>>>>> beginning of the tuning when using threads > >>>>>>>>>>>>>>> single-threads_tune-run1.moses.ini - the ini file used at the > >>>>>>>>>>>>>>> beginning of the tuning when threads were not used > >>>>>>>>>>>>>>> single-threads_tune-run2.moses.ini - the ini file used at the > >>>>>>>>>>>>>>> beginning of the second iteration when threads were not used > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - Prasanth > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Thu, Sep 22, 2011 at 10:19 AM, Hieu > >>>>>>>>>>>>>>> Hoang<[email protected]<mailto:[email protected]>> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> can you send me your ini file, and a few lines of the > >>>>>>>>>>>>>>> n-best list. For accuracy, send them as attachements, not > >>>>>>>>>>>>>>> cut& > >>>>>>>>>>>>>>> paste into > >>>>>>>>>>>>>>> the email. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'll try& see what the problem is > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 22 September 2011 14:57, Prasanth > >>>>>>>>>>>>>>> K<[email protected] > >>>>>>>>>>>>>>> <mailto:[email protected]>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I am facing the same error that Cyrine Nasri > >>>>>>>>>>>>>>> mentioned > >>>>>>>>>>>>>>> in this thread. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I will try and give more information that what has > >>>>>>>>>>>>>>> already > >>>>>>>>>>>>>>> been mentioned. > >>>>>>>>>>>>>>> 1. I was using a single-threaded version of moses > >>>>>>>>>>>>>>> until earlier and was having no problem with the experiments > >>>>>>>>>>>>>>> using > >>>>>>>>>>>> EMS. > >>>>>>>>>>>> > >>>>>>>>>>>>>>> 2. I recently shifted to a multi-threaded version, > >>>>>>>>>>>>>>> and tried the same experiment again with EMS. > >>>>>>>>>>>>>>> This time, the tuning process crashes after a > >>>>>>>>>>>>>>> single > >>>>>>>>>>>>>>> iteration with exactly the same error as mentioned below. > >>>>>>>>>>>>>>> 3. I have used 10 threads for decoding in the > >>>>>>>>>>>>>>> tuning > >>>>>>>>>>>>>>> process, and am using a server with 32Gb ram for running the > >>>>>>>>>>>>>>> experiments. (Might not be related, but just thought I should > >>>>>>>>>>>>>>> mention!) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I am not sure if Cyrine's problem was with the > >>>>>>>>>>>>>>> multi-threaded version as well, but could some one point out > >>>>>>>>>>>>>>> as > >>>>>>>>>>>>>>> to what might be wrong in this picture ? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - Prasanth > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Wed, Jul 27, 2011 at 5:59 PM, Cyrine NASRI > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> <[email protected]<mailto:[email protected]>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> Hello, > >>>>>>>>>>>>>>> I 'm trying to launch the mert using this > >>>>>>>>>>>>>>> command: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> ./mert-moses-new.pl<http://mert-moses-new.pl> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> /users/parole/cnasri/moses_work/corpus/source2TOK > >>>>>>>>>>>>>>> /users/parole/cnasri/moses_work/corpus/ref2TOK > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> /users/parole/cnasri/moses_work/moses/moses-cmd/src/moses > >>>>>>>>>>>> /users/parole/cnasri/moses_work/moses-scripts/scripts-20110727-154 > >>>>>>>>>>>> 3/trai n > >>>>>>>>>>>> > >>>>>>>>>>>>>>> ing/moses.ini --working-dir > >>>>>>>>>>>>>>> /users/parole/cnasri/moses_work/tuning/ > >>>>>>>>>>>>>>> --mertdir /users/parole/cnasri/moses_work/moses/mert > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> But there is only one iteration, after it stops > >>>>>>>>>>>>>>> and > >>>>>>>>>>>> itshow: > >>>>>>>>>>>>>>> Peeking at the beginning of nbestlist to get > >>>>>>>>>>>>>>> order > >>>>>>>>>>>>>>> of scores: run1.best100.out > >>>>>>>>>>>>>>> The decoder returns the scores in this order: d > >>>>>>>>>>>>>>> lm > >>>>>>>>>>>>>>> w tm > >>>>>>>>>>>>>>> tm > >>>>>>>>>>>> tm > >>>>>>>>>>>> > >>>>>>>>>>>>>>> Executing: gzip -f run1.best100.out > >>>>>>>>>>>>>>> Scoring the nbestlist. > >>>>>>>>>>>>>>> Executing: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> /users/parole/cnasri/moses_work/moses/mert/extractor > >>>>>>>>>>>>>>> --scconfig case:true --scfile run1.scores.dat --ffile > >>>>>>>>>>>>>>> run1.features.dat -r > >>>>>>>>>>>>>>> /users/parole/cnasri/moses_work/corpus/ref2TOK > >>>>>>>>>>>>>>> -n > >>>>>>>>>>>>>>> run1.best100.out.gz> extract.out 2> > >>>>>>>>>>>>>>> extract.err > >>>>>>>>>>>>>>> Executing: \cp -f init.opt run1.init.opt > >>>>>>>>>>>>>>> Executing: > >>>>>>>>>>>>>>> /users/parole/cnasri/moses_work/moses/mert/mert -d 6 > >>>>>>>>>>>>>>> --scconfig case:true -n 20 --ffile run1.features.dat > >>>>>>>>>>>>>>> --scfile > >>>>>>>>>>>>>>> run1.scores.dat --ifile run1.init.opt 2> mert.log Exit > >>>>>>>>>>>>>>> code: 3 > >>>>>>>>>>>>>>> Failed to run mert at ./mert-moses-new.pl > >>>>>>>>>>>>>>> <http://mert-moses-new.pl> line 752. > >>>>>>>>>>>>>>> and in the mert log : > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Seeding random numbers with system clock > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> :Too few minimum weights. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> error could not initialize start point with > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I have not idea how i resolve this problem. > >>>>>>>>>>>>>>> Any idea please? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thank you > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>> Moses-support mailing list > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> [email protected]<mailto:[email protected]> > >>>>>>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> --- J.B.S. Haldane > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>>> Moses-support mailing list > >>>>>>>>>>>>>>> [email protected]<mailto:[email protected]> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> --- J.B.S. Haldane > >>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>> Moses-support mailing list > >>>>>>>>>>>>> [email protected] > >>>>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>>>>>>>>>>> -- > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> ****************************************************************** > >>>>>>>>>>>> ****** ********** J�rg Tiedemann > >>>>>>>>>>>> [email protected] > >>>>>>>>>>>> Dep. of Linguistics and Philology > >>>>>>>>>>>> http://stp.lingfil.uu.se/~joerg/ > >>>>>>>>>>>> Uppsala University tel: +46 > >>>>>>>>>>>> (0)18 - > >>>>>>>>>>>> 471 1412 > >>>>>>>>>>>> Box 635, SE-751 26 Uppsala/SWEDEN fax: +46 (0)18 - 471 1094 > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Moses-support mailing list > >>>>>>>>>>> [email protected] > >>>>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>>>>>>>> -- > >>>>>>>>> The University of Edinburgh is a charitable body, registered in > >>>>>>>>> Scotland, with registration number SC005336. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Moses-support mailing list > >>>>>>>>> [email protected] > >>>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>>>>>>> _______________________________________________ > >>>>>>>> Moses-support mailing list > >>>>>>>> [email protected] > >>>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>>>>>> -- > >>>>>>> When a place gets crowded enough to require ID's, social collapse is > >>>>>>> not > >>>>>>> far away. It is time to go elsewhere. The best thing about space > >>>>>>> travel > >>>>>>> is that it made it possible to go elsewhere. > >>>>>>> -- R.A. Heinlein, "Time Enough For Love" > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Moses-support mailing list > >>>>>>> [email protected] > >>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>>>>> _______________________________________________ > >>>>>> Moses-support mailing list > >>>>>> [email protected] > >>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>>>>> > >>>>> > >>>>> -- > >>>>> Barry Haddow > >>>>> University of Edinburgh > >>>>> +44 (0) 131 651 3173 > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Moses-support mailing list > >>>> [email protected] > >>>> http://mailman.mit.edu/mailman/listinfo/moses-support > >>>> > >>> > >>> > >>> > >>> -- > >>> When a place gets crowded enough to require ID's, social collapse is not > >>> far away. It is time to go elsewhere. The best thing about space travel > >>> is that it made it possible to go elsewhere. > >>> -- R.A. Heinlein, "Time Enough For Love" > >>> > >> > >> > >> > >> -- > >> When a place gets crowded enough to require ID's, social collapse is not > >> far away. It is time to go elsewhere. The best thing about space travel > >> is that it made it possible to go elsewhere. > >> -- R.A. Heinlein, "Time Enough For Love" > >> > >> _______________________________________________ > >> Moses-support mailing list > >> [email protected] > >> http://mailman.mit.edu/mailman/listinfo/moses-support > > > > > > > > -- > When a place gets crowded enough to require ID's, social collapse is not > far away. It is time to go elsewhere. The best thing about space travel > is that it made it possible to go elsewhere. > -- R.A. Heinlein, "Time Enough For Love" > > _______________________________________________ > Moses-support mailing list > [email protected] > http://mailman.mit.edu/mailman/listinfo/moses-support -- Dipl.-Inf. Christian Federmann, Researcher, Language Technology Lab Office +1.09 -- Phone +49-681/857-75-5353, Fax +49-681/857-75-5338 DFKI GmbH, Campus D3 2, Stuhlsatzenhausweg 3, 66123 Saarbruecken http://www.dfki.de/~cfedermann ------------------------------------------------------------------- Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 ------------------------------------------------------------------- _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
