From: Theodore W. <twi...@ya...> - 2003-02-26 22:35:37
|
From: Pepijn V. E. <pep...@lu...> - 2003-02-26 23:20:52
|
It seems to be pretty dead... As far as I can see from the gl4java site development has also more or less come to a stop (last binary is from 2001 iirc). I have the intention to make a derived library of gl4java with the following goals: - Clean up the build process - Drop pre jdk 1.3 support in favor of the cleaner JAWT interfaces - Add opengl 1.4 support If anyone feels like helping once I get this project started, it would be more than welcome :) Pepijn Van Eeckhoudt On woensdag, feb 26, 2003, at 23:36 Europe/Brussels, Theodore Witkamp wrote: > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Gl4java-development mailing list > Gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-development > |
From: Max G. <gi...@ye...> - 2003-02-27 10:58:17
|
On Thu, 27 Feb 2003, Pepijn Van Eeckhoudt wrote: > I have the intention to make a derived library of gl4java with the While continuing development of gl4java is obviously noble goal and really a must, I believe it should be done, if possible, within current gl4java project. I'm sure Sven will support this effort and arrange things accordingly. > following goals: > - Clean up the build process > - Drop pre jdk 1.3 support in favor of the cleaner JAWT interfaces Aggreed if it won't break additional goal, see below. > - Add opengl 1.4 support > If anyone feels like helping once I get this project started, it would > be more than welcome :) Count me in. I'd also suggest adding two more goals: - Adding support for free Java implementations (GCJ being most important) Regards, Max |
From: Pepijn V. E. <pep...@lu...> - 2003-02-27 11:55:04
|
Max Gilead wrote: > On Thu, 27 Feb 2003, Pepijn Van Eeckhoudt wrote: > >>I have the intention to make a derived library of gl4java with the > > While continuing development of gl4java is obviously noble goal and > really a must, I believe it should be done, if possible, within current > gl4java project. I'm sure Sven will support this effort and arrange things > accordingly. > I agree that this would be great if it is possible. My first goal of cleaning up the build stuff requires a lot of reorganizing in the code base. I realize that stuff like code style, directory structures, etc are mostly personal taste, which is why I had the idea of creating a seperate cvs repository. If can work out some plan on how to continue I would be more than happy to just continue the on the existing project... The structure i had in mind was something like this gl4java |- src | |- c | | |- windows | | |- linux | | |- mac | | |- ... | |- java |- build |- tmp In my opinion the only parts that belong in the cvs repository are those bits that are not autogenerated (or at least not the intermediate files). Autogenerated files would be dumped in some temporary directory under the build dir and cleaned up when they are no longer required. > >>following goals: >>- Clean up the build process >>- Drop pre jdk 1.3 support in favor of the cleaner JAWT interfaces > > Aggreed if it won't break additional goal, see below. > > >>- Add opengl 1.4 support >>If anyone feels like helping once I get this project started, it would >>be more than welcome :) > > Count me in. > > I'd also suggest adding two more goals: > - Adding support for free Java implementations (GCJ being most important) I don't have any experience with gcj, so I have no idea how easy it would be to support it. What other java implementations did you have in mind? Where's extra goal number two btw? ;) Do you know if Sven has any design documents of the library? Pepijn > > Regards, > Max > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Gl4java-development mailing list > Gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-development > |
From: Max G. <gi...@ye...> - 2003-02-27 12:29:52
|
On Thu, 27 Feb 2003, Pepijn Van Eeckhoudt wrote: > I agree that this would be great if it is possible. My first goal of > cleaning up the build stuff requires a lot of reorganizing in the code > base. I realize that stuff like code style, directory structures, etc > are mostly personal taste, which is why I had the idea of creating a > seperate cvs repository. Separate cvs repository is good idea for code reorganization. It sounded like you wanted to start completely separate project. > the only parts that belong in the cvs repository are those > bits that are not autogenerated (or at least not the intermediate > files). Autogenerated files would be dumped in some temporary directory > under the build dir and cleaned up when they are no longer required. Aggreed with one exception: CVS should contain files which are generated using external/nonstandard tools. Headers etc. should not be included but output from separate parsers, generators etc. should be. > I don't have any experience with gcj, so I have no idea how easy it > would be to support it. What other java implementations did you have in > mind? Kaffe, ORP for example. But compiled code would be priority IMHO. I've done some work with gcj and it's nice and all except its support for newer libraries/language features is rather incomplete. However support for it is important. > Do you know if Sven has any design documents of the library? Don't know, sorry. Regards, Max |
From: Pepijn V. E. <pep...@lu...> - 2003-02-27 13:48:51
Attachments:
build.gif
|
Max Gilead wrote: > On Thu, 27 Feb 2003, Pepijn Van Eeckhoudt wrote: > >>I agree that this would be great if it is possible. My first goal of >>cleaning up the build stuff requires a lot of reorganizing in the code >>base. I realize that stuff like code style, directory structures, etc >>are mostly personal taste, which is why I had the idea of creating a >>seperate cvs repository. > > Separate cvs repository is good idea for code reorganization. It sounded > like you wanted to start completely separate project. > Is it possible to do this within the context of sourceforge? > >>the only parts that belong in the cvs repository are those >>bits that are not autogenerated (or at least not the intermediate >>files). Autogenerated files would be dumped in some temporary directory >>under the build dir and cleaned up when they are no longer required. > > Aggreed with one exception: CVS should contain files which are generated > using external/nonstandard tools. Headers etc. should not be included but > output from separate parsers, generators etc. should be. > Just so we understand each other correctly, in the attached image the green boxes are what I would keep. The red is generated at build time or not necessary. Which parts would you keep? I hope my drawing is more or less correct... Pepijn > >>I don't have any experience with gcj, so I have no idea how easy it >>would be to support it. What other java implementations did you have in >>mind? > > Kaffe, ORP for example. But compiled code would be priority IMHO. I've > done some work with gcj and it's nice and all except its support for newer > libraries/language features is rather incomplete. However support for it > is important. > > >>Do you know if Sven has any design documents of the library? > > Don't know, sorry. > > Regards, > Max > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Gl4java-development mailing list > Gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-development > |
From: Max G. <gi...@ye...> - 2003-02-27 13:56:46
|
On Thu, 27 Feb 2003, Pepijn Van Eeckhoudt wrote: > Max Gilead wrote: > > On Thu, 27 Feb 2003, Pepijn Van Eeckhoudt wrote: > > Separate cvs repository is good idea for code reorganization. It sounded > > like you wanted to start completely separate project. > Is it possible to do this within the context of sourceforge? Correction - separated *module* inside the same repository. That can be done without problems on SF. [ Part 1.2, Image/GIF 16KB. ] [ Cannot display this part. Press "V" then "S" to save in a file. ] This is how I see images now so I'll send another mail later when I get to graphical terminal ;-) Bye, Max |
From: Theodore W. <twi...@ya...> - 2003-02-27 17:44:36
|
It seams that this list has risen from the grave :) I don't know crap about OpenGL but I have a bit of JVM & program analysis experience. On Wednesday, February 26, 2003, at 06:20 PM, Pepijn Van Eeckhoudt wrote: > It seems to be pretty dead... As far as I can see from the gl4java > site development has also more or less come to a stop (last binary is > from 2001 iirc). > I have the intention to make a derived library of gl4java with the > following goals: > - Clean up the build process > - Drop pre jdk 1.3 support in favor of the cleaner JAWT interfaces > - Add opengl 1.4 support > I Agree all of the above. > If anyone feels like helping once I get this project started, it would > be more than welcome :) I think that it should be done with in gl4java. > > Pepijn Van Eeckhoudt > > On woensdag, feb 26, 2003, at 23:36 Europe/Brussels, Theodore Witkamp > wrote: > >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Scholarships for Techies! >> Can't afford IT training? All 2003 ictp students receive scholarships. >> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. >> www.ictp.com/training/sourceforge.asp >> _______________________________________________ >> Gl4java-development mailing list >> Gl4...@li... >> https://lists.sourceforge.net/lists/listinfo/gl4java-development >> > <PGP.sig> |