I downloaded grok 0.5.3 and ran into the following problems:
1) The gnu.getopt package is missing all of the Messages files (the different language packs it needs). The .jar file that comes with the grok package does not have any of these, and also seems to be missing quite a few other classes. Downloading a new copy of gnu.getopt fixed this.
2) There are a bunch of classes (PipeClient, English*ME, Pipeline, etc.) that all require the cern.colt.map.OpenIntDoubleHashMap but I can't find it (not even on the Internet). Any idea where I can get that? Any idea what version you use?
It seems like this project has a general CLASSPATH polution problem. The classic symptoms are typically that developers have no problems running examples and writing code, but when they distribute their work, they forget .jar files that others need or give out the wrong versions. This is a problem with CLASSPATHs because you can accidentally have multiple versions of the same library in the CLASSPATH, and use one but think you're using another.
A suggestion I would make is to have a "clean release" test account. The account has NOTHING in it. No java, no jar files, nothing. What you do is make sure the release account is completely cleaned out (so you simulate a user with nothing), and then you try to get your stock distributions to run without modification. The key is that you make sure that the account is completely cleaned out everytime, thus simulating what newbies will start with.
By doing this, you'll ensure that you always distribute the correct versions and numbers of jar files. It also provides a sanity check for you install/use process.
Anyway, I'll get off my soap box now. I'm very interested in using Grok and OpenNLP in some of my research, but I just need some assistance.
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, you've identified some problems which I am sorting out at the moment. We actually didn't even distribute any jars before, and the learning curve to start developing with Grok was quite painful indeed. Over the past several weeks I reorganized the Grok infrastructure for the build process, and now I'm working on sorting out some of the issues which are popping up, such as those you've mentioned above. I was away of the cern.colt issue, but not about getopt, so I'll sort that out soon.
Thanks for the suggestion of using a dummy account. We did that at one point in ages past, but I've been so busy lately that I've been selfishly worrying about getting Grok to do what I want it to do.... in the meantime, you can download the latest version of Maxent (1.2.2 ) from maxent.sf.net, which contains the cern.colt classes within. You'll want to download the maxent-exe-1.2.2.jar file from the "Maxent Executable (Standalone)" package.
Could I interest you in a job as release manager / sanity checker??
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I'd be interested in the job. I'll have to take a look at my schedule, as I'm coming up on crunch time in my grad program soon. I'll get back to you on this thread about it.
I'm assuming that you'd want:
1) Build environment development (build process, install process, etc.)
2) Testing development (running test suites, checking for accurate builds, general debugging)
3) Release schedules and target milestone management
Let me know if you can think of any more duties, or if you don't need some of the above mentioned ones. Once I have a clear idea of what is entailed, I can let you know what kind of time I can commit.
I'm pretty sure I can do it, but I want to make sure I have the proper amount of time to devote.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that any efforts made in this direction would be excellent, and the list of responsibilities you've laid out is spot on. I also want to start getting some sample programs available in the source distribution, and this could dovetail nicely with the test suite side of things.
I myself don't have that much experience in release management (been learning a lot lately), and I would really appreciate having someone else taking charge of this aspect. The order of priority for me is:
* Build environment development* Release schedules and target milestone management
* Testing development
Gann used to take care of creating test suites, but those have fallen by the wayside as I haven't kept them up and Gann has been mostly busy with his work. I would love to have test suites again, so if you would find yourself having time to take that on it would be great.
I understand your concerns about time --- I'm planning to finish my PhD in May 2002 and am starting up a company... anyway, you could start with the build process management and if your time permits, you could expand that to release schedules and then perhaps testing. Don't feel that you have to bite the whole thing off in one go. So, if you want to have a go at it, let me know and I'll put you on as a developer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey,
I downloaded grok 0.5.3 and ran into the following problems:
1) The gnu.getopt package is missing all of the Messages files (the different language packs it needs). The .jar file that comes with the grok package does not have any of these, and also seems to be missing quite a few other classes. Downloading a new copy of gnu.getopt fixed this.
2) There are a bunch of classes (PipeClient, English*ME, Pipeline, etc.) that all require the cern.colt.map.OpenIntDoubleHashMap but I can't find it (not even on the Internet). Any idea where I can get that? Any idea what version you use?
It seems like this project has a general CLASSPATH polution problem. The classic symptoms are typically that developers have no problems running examples and writing code, but when they distribute their work, they forget .jar files that others need or give out the wrong versions. This is a problem with CLASSPATHs because you can accidentally have multiple versions of the same library in the CLASSPATH, and use one but think you're using another.
A suggestion I would make is to have a "clean release" test account. The account has NOTHING in it. No java, no jar files, nothing. What you do is make sure the release account is completely cleaned out (so you simulate a user with nothing), and then you try to get your stock distributions to run without modification. The key is that you make sure that the account is completely cleaned out everytime, thus simulating what newbies will start with.
By doing this, you'll ensure that you always distribute the correct versions and numbers of jar files. It also provides a sanity check for you install/use process.
Anyway, I'll get off my soap box now. I'm very interested in using Grok and OpenNLP in some of my research, but I just need some assistance.
Thanks.
Yes, you've identified some problems which I am sorting out at the moment. We actually didn't even distribute any jars before, and the learning curve to start developing with Grok was quite painful indeed. Over the past several weeks I reorganized the Grok infrastructure for the build process, and now I'm working on sorting out some of the issues which are popping up, such as those you've mentioned above. I was away of the cern.colt issue, but not about getopt, so I'll sort that out soon.
Thanks for the suggestion of using a dummy account. We did that at one point in ages past, but I've been so busy lately that I've been selfishly worrying about getting Grok to do what I want it to do.... in the meantime, you can download the latest version of Maxent (1.2.2 ) from maxent.sf.net, which contains the cern.colt classes within. You'll want to download the maxent-exe-1.2.2.jar file from the "Maxent Executable (Standalone)" package.
Could I interest you in a job as release manager / sanity checker??
Well, I'd be interested in the job. I'll have to take a look at my schedule, as I'm coming up on crunch time in my grad program soon. I'll get back to you on this thread about it.
I'm assuming that you'd want:
1) Build environment development (build process, install process, etc.)
2) Testing development (running test suites, checking for accurate builds, general debugging)
3) Release schedules and target milestone management
Let me know if you can think of any more duties, or if you don't need some of the above mentioned ones. Once I have a clear idea of what is entailed, I can let you know what kind of time I can commit.
I'm pretty sure I can do it, but I want to make sure I have the proper amount of time to devote.
I think that any efforts made in this direction would be excellent, and the list of responsibilities you've laid out is spot on. I also want to start getting some sample programs available in the source distribution, and this could dovetail nicely with the test suite side of things.
I myself don't have that much experience in release management (been learning a lot lately), and I would really appreciate having someone else taking charge of this aspect. The order of priority for me is:
* Build environment development* Release schedules and target milestone management
* Testing development
Gann used to take care of creating test suites, but those have fallen by the wayside as I haven't kept them up and Gann has been mostly busy with his work. I would love to have test suites again, so if you would find yourself having time to take that on it would be great.
I understand your concerns about time --- I'm planning to finish my PhD in May 2002 and am starting up a company... anyway, you could start with the build process management and if your time permits, you could expand that to release schedules and then perhaps testing. Don't feel that you have to bite the whole thing off in one go. So, if you want to have a go at it, let me know and I'll put you on as a developer.