Reply
 
LinkBack Thread Tools Display Modes
  #1   Report Post  
Old December 18th 04, 04:17 PM
 
Posts: n/a
Default SCID - has Shane stopped developing lately - I am behind the times here

SCID doesn't seem to have news beyond April 2004 when it was
mentioned the reason for a short absence at *that* time ...

any info appreciated, I hopr it is just that I was looking at an old
cached page or something as I liked it.

Keith

  #2   Report Post  
Old December 19th 04, 03:48 AM
Jester6
 
Posts: n/a
Default

I think he was abducted by aliens.
wrote in message
...
SCID doesn't seem to have news beyond April 2004 when it was
mentioned the reason for a short absence at *that* time ...

any info appreciated, I hopr it is just that I was looking at an old
cached page or something as I liked it.

Keith



  #3   Report Post  
Old December 19th 04, 11:55 AM
David Richerby
 
Posts: n/a
Default

In article ,
Andreas P. Hofmann wrote:
http://scid.skjoldebrand.org/index.php?id=90&type=1


``Database engine will reuse original Scid code and GUI will be written in
Java.''

Noooooo! You are in a twisty maze of dependencies, all alike.


Dave.

--
David Richerby Radioactive Incredible Watch (TM):
www.chiark.greenend.org.uk/~davidr/ it's like a precision chronometer but
it'll blow your mind and make you glow
in the dark!
  #4   Report Post  
Old December 19th 04, 12:36 PM
Ari Makela
 
Posts: n/a
Default

On 2004-12-19, David Richerby wrote:
In article ,
Andreas P. Hofmann wrote:
http://scid.skjoldebrand.org/index.php?id=90&type=1


``Database engine will reuse original Scid code and GUI will be written in
Java.''

Noooooo! You are in a twisty maze of dependencies, all alike.


What's complicated in this? SCID is now written with C++ and the GUI is
written Tcl/Tk. Now the Tcl/Tk part is replaced with java. The things
can be kept simple if a extension of xboard or UCI protocols are used.
No complicated and fragile things like JNI. Threads must be treated
carefully, of course.

The idea of dividing SCID to a libraries and GUI is a very good one
because it enables third party developers to develop utilities.

Myself, I'm going to email the developers and ask them if they had any
use for my java chess code (opening classification, JComponent for a
chess board, a plugin architecture).

--
Ari Makela no escaping it -
I must step on fallen leaves
http://arska.org/hauva/ to take this path (Suzuki Majoko)

  #5   Report Post  
Old December 19th 04, 01:52 PM
[email protected]
 
Posts: n/a
Default

On Sun, 19 Dec 2004 09:16:25 +0000, IglooLegend
wrote:


Wrote:
SCID doesn't seem to have news beyond April 2004 when it was
mentioned the reason for a short absence at *that* time ...

any info appreciated, I hopr it is just that I was looking at an old
cached page or something as I liked it.

Keith


Here is a link to the unofficial Scid site:

http://scid.skjoldebrand.org/


ta chaps - much appreciated

keith



  #6   Report Post  
Old December 19th 04, 02:31 PM
David Richerby
 
Posts: n/a
Default

Ari Makela wrote:
David Richerby wrote:
http://scid.skjoldebrand.org/index.php?id=90&type=1

``Database engine will reuse original Scid code and GUI will be written
in Java.''

Noooooo! You are in a twisty maze of dependencies, all alike.


What's complicated in this? SCID is now written with C++ and the GUI is
written Tcl/Tk. Now the Tcl/Tk part is replaced with java.


To be honest, it's probably no worse requiring Java than Tcl/Tk. I'd be
more tempted by something like GTK.

The main problems with Java that I can see a

i) Any kind of a fancy GUI in Java runs like a drain unless you have a
very nice CPU or a very nice JVM (of which there aren't many).

ii) Java's IPC is pretty horrid. The only way I can see of talking to a
separate database app is by sending data down a socket. That'll then
need parsing and doing that in Java brings us back to the drainage
problem.


The idea of dividing SCID to a libraries and GUI is a very good one
because it enables third party developers to develop utilities.


Certainly.


Dave.

--
David Richerby Swiss Mouldy Hat (TM): it's like a hat
www.chiark.greenend.org.uk/~davidr/ but it's starting to grow mushrooms
and made in Switzerland!
  #7   Report Post  
Old December 19th 04, 03:29 PM
Ari Makela
 
Posts: n/a
Default

On 2004-12-19, David Richerby wrote:

To be honest, it's probably no worse requiring Java than Tcl/Tk. I'd be
more tempted by something like GTK.


Yes, I'd probably select Python GTK+ or Python Qt. Both are portable and
Java is IMO overly complicated for writing this kind of GUI. I don't
know how well those toolkits work on Windows.

The main problems with Java that I can see a

i) Any kind of a fancy GUI in Java runs like a drain unless you have a
very nice CPU or a very nice JVM (of which there aren't many).


Swing is indeed memory intensive and it's easy to make sluggish GUI's
even for powerful computers. SwingUtilities.invokeLater(Runnable) helps
a lot. At least on my computers (1 GB RAM, PIII 850 MHz and 512 MB RAM,
dual AMD Duron 1200 MHz) my own program runs well enough.

ii) Java's IPC is pretty horrid. The only way I can see of talking to a
separate database app is by sending data down a socket. That'll then
need parsing and doing that in Java brings us back to the drainage
problem.


I've never done this but wouldn't it be possible just to open two
streams for the input and output?

The idea of dividing SCID to a libraries and GUI is a very good one
because it enables third party developers to develop utilities.


Certainly.


And it makes it possible to write a different GUI by those who do not
like the Java solution.

--
Ari Makela no escaping it -
I must step on fallen leaves
http://arska.org/hauva/ to take this path (Suzuki Majoko)

  #8   Report Post  
Old December 19th 04, 04:01 PM
David Richerby
 
Posts: n/a
Default

Ari Makela wrote:
David Richerby wrote:
To be honest, it's probably no worse requiring Java than Tcl/Tk. I'd
be more tempted by something like GTK.


Yes, I'd probably select Python GTK+ or Python Qt. Both are portable
and Java is IMO overly complicated for writing this kind of GUI. I don't
know how well those toolkits work on Windows.


There's a Windows port of GTK and, as you say, Java is something of a
sledgehammer, here.


ii) Java's IPC is pretty horrid. The only way I can see of talking to
a separate database app is by sending data down a socket. That'll
then need parsing and doing that in Java brings us back to the
drainage problem.


I've never done this but wouldn't it be possible just to open two
streams for the input and output?


The database program could execute the GUI with stdin/out set up for this
but this is clearly the wrong way round -- you'd have to modify the data-
base for each new front end. I'm not sure if Java has enough process-
control gubbins to start up another process with specified stdin/out
streams. But you still get the parser suckage.


The idea of dividing SCID to a libraries and GUI is a very good one
because it enables third party developers to develop utilities.


Certainly.


And it makes it possible to write a different GUI by those who do not
like the Java solution.


:-)


Dave.

--
David Richerby Revolting Car (TM): it's like a
www.chiark.greenend.org.uk/~davidr/ high-performance luxury car but it'll
turn your stomach!
  #9   Report Post  
Old December 19th 04, 05:19 PM
Peter Schäfer
 
Posts: n/a
Default

David Richerby wrote:

i) Any kind of a fancy GUI in Java runs like a drain unless you have a
very nice CPU or a very nice JVM (of which there aren't many).


a moderate PC (let's say a P3 with 256 MB) should be sufficient.

Swing's bad reputation came from early versions (which used to be really
slow). Also, many programmers didn't understand the threading model
(because it was sparsely documented).


ii) Java's IPC is pretty horrid. The only way I can see of talking to a
separate database app is by sending data down a socket. That'll then
need parsing and doing that in Java brings us back to the drainage
problem.


I guess they want to write their library in C and embed it into Java
with JNI - no separate process involved.

Setting up client/server processes is also possible if you can build
upon an existing infrastructure. I have done this with MySQL and their
JDBC interface.

See: http://jose-chess.sourceforge.net

-- Peter
  #10   Report Post  
Old December 19th 04, 05:32 PM
Ari Makela
 
Posts: n/a
Default

On 2004-12-19, David Richerby wrote:

The database program could execute the GUI with stdin/out set up for this
but this is clearly the wrong way round -- you'd have to modify the data-
base for each new front end.


Clearly? I don't think so. Many good programs work that way.

I'm not sure if Java has enough process-
control gubbins to start up another process with specified stdin/out
streams. But you still get the parser suckage.


In this kind of program the user is the bottle neck. I don't believe
without trying that parsing would be a problem.

--
Ari Makela no escaping it -
I must step on fallen leaves
http://arska.org/hauva/ to take this path (Suzuki Majoko)

Reply
Thread Tools
Display Modes

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
SCID (and SCID Daily) Antonio R. rec.games.chess.computer (Computer Chess) 4 March 14th 04 11:11 PM
Thinking times in Grandmaster tournaments [email protected] rec.games.chess.politics (Chess Politics) 2 December 30th 03 06:29 AM


All times are GMT +1. The time now is 03:21 AM.

Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright ©2004-2018 ChessBanter.
The comments are property of their posters.
 

About Us

"It's about Chess"

 

Copyright © 2017