Thread: [Gl4java-development] is this list alive?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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
>

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

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
> 

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

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
> 

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

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>