Yikes! That makes me feel rather coddled when it comes to building GUIs in Delphi, where the updating issue is handled relatively painlessly by calling Application.Processmessages.
Let's write a Chess GUI from scratch in Java
Sort:
Before Java I was doing GUI in Perl Tk. In Perl Tk there is an explicit update function for widgets which you can call directly. As far as you use the GUIs 'after' and 'repeat' timers this works fine. But also in Perl Tk if you start updating elements from within a thread the app will crash sooner rather than later. This latter behaviour is very similar to Java, you start getting strange error messages, the screen vibrates and the whole thing collapses. It would be really cool to program in a language where these are none issues, I know nothing about Delphi. May be I'm too heavily invested now in Java to abandon it for this single issue, but who knows.
I have never experienced a crash in Delphi caused by 'concurrent' (i.e. interleaved) GUI activity, apart from obvious cases such as when objects were freed prematurely leaving dangling pointers. Maybe I was lucky, but it does seem pretty robust.
I believe at least one chess GUI has been written in Delphi (Arena?). If you stick with Java and manage to solve this problem you will certainly have achieved something major.
The runLater block solution is the official Java solution to the problem, so I have zero new achievement here.
Just putting the little additional pieces together so that they work as expected takes some googling.
Like this modal dialog thing: when I was looking for a solution to disable UI elements alltogether I bumped into insane solutions like I should put an invisible layer above the whole application and consume the events of this layer...
My final solution is clean because the only thing I have to check that the user is indeed unable to close the modal window. If this is granted, all other things are guaranteed by the definition of modality, the app even makes a noise when the user tries to touch a forbidden UI control, so I'm sure this is the right way to go.
I have looked into Delphi, or to be more precise, the open source version of Delphi, Lazarus.
Strictly speaking Delphi is not a language. The language is ( a dialect of ) Object Pascal and Delphi is a RAD ( Rapid Application Development ) environment based on this language.
The open source version of Delphi, called Lazarus, is similary a RAD, based on Free Pascal ( also object oriented ). Both the langauge used by Lazarus and its RAD environment itself is highly compatible with that of Delphi.
I cannot speak for Delphi itself, in the following I limit my investigation to Lazarus, which is publicly available, however due to the similarities and high level of compatibility my conclusions should in large part apply to Delphi as well.
I have found a document which deals with exactly the same issues that I raised in connection with Java, the issue of long operations in a GUI application ( http://wiki.freepascal.org/Multithreaded_Application_Tutorial ).
What is different in Lazarus, is that you can indeed repeteadly call Application.ProcessMessages during a long operation and this will indeed update GUI elements and this update will be visible to the user.
However this operation still has to be on the main application thread.
You are not allowed to do the same thing from a thread running parallel to the main application thread:
Instead you have to call a method called 'Synchronize' to which you pass a chunk of code ( 'MyMethod' ) which latter does the updating on the main application thread. This is the exact equivalent of Java's runLater block. ( Edit: with the exception that Java's runLater method is not blocking, it does not wait for the block to be executed. )
The quoted document discourages using threads, but it admits that there are cases in which they are unavoidable:
In chess programming you cannot avoid running external programs ( engines ) as processes, writing to their standard input and reading from their standard output. When you read from the standard output of a process, this operation is blocking. So the only choice is to do the reading in a separate thread so that it does not block the main application thread. When the engine sends analysis data, the engine output reading thread wakes up and it has to be able to update GUI elements to communicate the engine analysis results to the user and this can only be done in a way which makes the main application thread do the updating when it sees fit to do so. ( Edit: There is a workaround if you use a timer on the main application thread, which at regular intervals looks at the engine output, and updates the GUI elements if necessary. It is true that in a GUI which allows timers on the main thread and direct updating of GUI elements, you can avoid updating GUI elements from threads. Still you cannot avoid threads alltogether. )
While GUI updating from threads is also an issue in Lazarus, this whole problem annoying as it is, is only a fraction of the problems you have to face when writing a chess GUI.
Still Lazarus is an interesting alternative because it produces a native executable, so in theory it can be faster than a program running on a Java virtual machine. It is supposed to follow the 'Write Once Compile Anywhere' modell ( as opposed to Java's WORA - Write Once Run Anywhere ), so in theory you don't have to write different code for different platforms. Also it has a GUI component library and resource editor.
Interesting!
Yes, I tend to use timers in preference to threads wherever possible because of their simplicity.
And yes, I love the simplicity of being able to distribute a single native executable (which may of course have DLLs and other resources included).
It would be interesting to know how Arena (written in Delphi) is designed and what is its threading model.
The actual programming I do is rather down to earth. I want do get something working by practically any means I can put my hands on. I never think in terms of theoretical categories like time and space complexity nor do I try to optimize things which work by brute force.
However I came across a problem set for programming competitions. I became curious whether my experience in brute force programming is any help in solving more disciplined problems.
Here is one:
-----------------
You are given a read only array of integers of size N, which in random order contains the integers from 1 to N, with the exception that one integer ( A ) is missing and an other one ( B ) appears twice.
Your job is to find the duplicated element B in O(N) time and O(1) space.
-----------------
Now, O(N) time means that the time required to solve the problem should be a linear function of N. O(1) space means that the amount of memory used to solve the problem should be constant, not depending on N. The array being read only means that you are not allowed to use the memory space of the input array for your processing.
-----------------
The brute force solution is of course to run an I loop from 0 to N-2 ( arrays in most languages are indexed from 0 ) take the I-th element and run an other loop J from I+1 to N-1 and compare the J-th element to the I-th element. If they match, you are done. This solution requires constant space but is of time complexity O(N^2).
If I had to solve this I would probably use a hash. I would run an I loop for the whole array and add a hash value with the key being the I-th integer. Before adding a key I would test whether the hash already has this key. If it does, then the I-th integer is the duplicate. This latter solution runs in O(N) time, however it needs O(N) space also, because the hash needs space on the order of the total number of integers.
So neither the unelegant brute force and the somewhat more elegant brute force solution works as a theoretical solution.
-----------------
Nevertheless I think I can solve this problem in O(N) time and and O(1) space also. The solution is left to the reader as a puzzle.
In WinBoard I experienced the same problems, when I wanted to update the game count in the title bar during processing of a PGN file with many thousands of games. Like you I was late to realize the problem, as, strangely, it did not always occur. Most of the time it actually started counting in the title bar, but then it suddenly stopped doing that until after the whole file was loaded. You could trigger the freeze by moving the mouse inside the window.
The solution I used was to invoke the event dispatcher explicitly in time-consuming loops. Normally the main program of a GUI application ends (after initializing stuff) in an event loop, which reads something like
while(TRUE) { e = GetEvent(); ProcessEvent(e); }
I just added a general routine
DoEvents() { while(EventPending) { e = GetEvent(); ProcessEvent(e); } }
Unlike the main event loop this loop does terminate when the event queue gets empty, and it will never block (in GetEvent) to wait for an event.
An easy method for disabling the UI during such loops is to let all mouse and keyboard events be 'grabbed' by a widget that would ignore them (e.g. some label). XBoard uses this method. This is basically what a modal dialog also does (the grabbing), except that now you don't pop up a dialog (which actually does something with the grabbed events, so that it can be closed to terminate the grab). By instating the grab through the low-level API there is nothing the user can do to terminate it, and after the loop finishes you terminate the grab.
Note that most widget sets allow you to associate events with arbitrary input channels. So there isn't any real need to start separate threads to handle the input from the engine pipes by blocking input calls. You can just associate the input channels with an event, and provide a handler for it. WinBoard and XBoard use this method. One advantage is that events are processed strictly in order, so that you don't have to worry about thread synchronization. With separate threads it could happen that handling of one event interrupts handling of another (e.g. if you play two engines against each other, and both produce output simultaneously). And if they both want to update the display as a result of this, things might be messed up badly.
"And if they both want to update the display as a result of this, things might be messed up badly."
No, in Java this is taken care of. The runLater blocks are put in a thread safe queue, so exactly one is executed at a time, there is guarantee for this. I actually run three engines concurrently in my GUI and everything is fine. I don't know whether JavaFX allows binding events to blocking IO reads.
As far as Winboard is concerned, as a matter of fact I have written an atomic engine for Winboard. Poor little engine is very stupid ( it finds 7 ply mates in 5 minutes which takes Atomkraft 3 seconds ). My greatest result with it that it once drew Pulsar with white. The engine is written in C++ ( compiles on both Visual Stduio and GCC ) however it uses only elementary techniques. I had to realize that without mastering bitboard technology I cannot write a meaningful engine, so I switched back to GUI programming.
Not that it proves anyhting about my threads not making trouble, but here is a screenshot of my GUI with 3 engines analyzing at the same time, all suggesting different moves:
If you have the engine input threads do nothing but queue the input message as an event, and do the actual processing in the event handler, then indeed there should be no problem, as this serializes them again. You are then basically simulating the system where the arrival of input triggers the events directly. Anything you do in the primary input loop would have to be made threat safe, however.
I still want to produce a version of Win/XBoard without GUI, (called NoBoard) that can be used for engine testing, and I would have to use threats n the way you describe to replace the widget set's event loop.
watcha wrote:
I had to realize that without mastering bitboard technology I cannot write a meaningful engine, so I switched back to GUI programming.
That is so not true! Bitboards in fact hardly help. If you write very, very fast code, they might add 30 Elo on 64-bit hardware compared to well-written mailbox, and on 32-bit hardware they would actually be inferior. The remaining 2000 Elo (compared to a stupid fixed-depth searcher with only material eval) will have to come from judicious pruning, accurate evaluation terms and good tuning. Not from raw speed (nps).
In fact advanced mailbox techniques can even beat bitboards in terms of speed on 64-bit hardware.
Pulsar is in general a pretty weak engine. I don't specifically know this for Atomic, but in variants that it has in common with Fairy-Max, (which is only normal Chess and Shatranj), the latter trashes Pulsar convincingly, and Fairy-Max' AI is just a 150-line code that only does the most basic of the basic. You should be able to do at least 1000 Elo better than Pulsar without using any fancy techniques.
My engine on the move generation level is at least an order of magnitude slower than Stockfish/Atomkraft. The best it can do is 150 kNodes/sec, so I thought my problems stem from speed.
I did not even touch pruning since I have zero understanding of advanced pruning techniques.
I only understand the basic alphabeta pruning ( which is guaranteed to produce the same best move as minimax ) and I used this elementary technique in my engine.
One order of magnitude in speed is just ~220 Elo. Stockfish on a single core slowed down one order of magnitude would still be over 3000 Elo. Pulsar is probably only 1800 Elo. So even at 150 knps the sky is the limit.
Btw, very plain mailbox code already should be able to reach 1M nps,on a modern CPU. Fairy-Max does about 1M nps on my i7. So it is more a matter of writing efficient code than a matter of used techniques.
Pruning in top engines is actually not so advanced at all. It is actually more depth reduction than pruning, and basically it amounts to sorting the moves by some heuristically derived likelihood that they would be good moves, and then reduce the depth at which you search them more and more as you advance through the list. (E.g. the first 3 moves at the nominal depth, the next 3 one ply less, the next 5 two ply less, etc.)
DrSpudnik wrote:
And when we're done, we can crawl through hell over broken bottles...
Making sure we call DoEvents() regularly so that hell's UI doesn't freeze over.
Hello Watcha,
I downloaded your code and when I run the jar file, I do not see the chess piece images. Can you help me.
Regards,
Jyothi
JyothiGudavalli wrote:
Hello Watcha,
I downloaded your code and when I run the jar file, I do not see the chess piece images. Can you help me.
Regards,
Jyothi
Which program did you download? Because I already have 3 versions up on the net.
Have you updated to the latest Java version ( I mean the JRE, Java Runtime Environment)?
On what platform are using the code? ( Windows, Linux, etc. )
Show me a screenshot of how it looks.
Long and/or background operations in JavaFX
In GUI programming the problem of long and/or background operations is a substantial one.
Suppose you press a button and the event handler calls a function which takes long to finish. Of course the user is impatient and wants feedback as to the status of this process. A beginner GUI programmer naively thinks ( as I did in the beginning ) that if you update GUI elements during this long operation the user will receive feedback.
This is not the case.
When you update a GUI element, only the internal state of this element will be updated immediately, the actual presentation of the GUI element on the screen will be updated only when this whole long operation has finished (according to the state last set by the long operation ).
So if you run a for loop from i = 1 to 10, in every cycle update the text of a label saying "Doing cycle "+i and then sleep a second, what the user will see is not the text of the label changing once in every second ten times, rather they will see nothing happening for 10 seconds and then all of a sudden the label will change to "Doing cycle 10".
The legitimate solution of this is to run the long operation in a separate thread and update the GUI elements in so called runLater blocks ( these are pieces of code put to a queue, which queue the platform will execute sequentially, polling its elements and running the code in them when it sees fit and update the GUI elements after the respective piece of code has been run ).
However this immediately introduces an other problem. If the operation runs in a separate thread, the user can now freely interact with other UI controls, which may interfere with this long operation in an adverse or unexpected way.
The solution to this problem is less straightforward. You can mess around with event handlers and try to consume events before they get to the handlers of UI controls, but this whole thing is to messy. I don't like this.
My solution is a clean one: open a modal dialog box ( informing the user that this operation is under way and presenting an option to cancel the operation ). The modal dialog by its definition disables all UI controls of non modal stages, so you are safe while this dialog is open.
The only problem with this is the user can close this dialog by clicking on this litte X in the corner and regain access to the UI controls. Here you cannot avoid messing with event handlers: you have to consume the close request event, but you do this only once and a clear way. It took me long to find the ultimate solution, but here it is and it works ( this is an example applied to the primaryStage, but it works with ordinary stages too ):
Still there is a problem with user updates, namely that you have to setup an updating mechanism for every long operation separately.
I got enough of this and came up with a Log class that captures all logging functions of the application, including the log of long operations.
It runs in the background during the entire run. You can put in log items in a thread safe queue which has a somewhat frightening name 'ConcurrentLinkedQueue'. There is a thread running in the log object that in a loop takes all the log items put to the queue since last time it looked, presents them to the user, sleeps for a while, then starts all over again. All the updating is of course done in a runLater block.
This way all the user notifications can be put to a separate tab which will be up during the whole applicaiton. When a long operation starts, it can activate this tab and put its log to the log object which will update the tab regularly.
By now I feal that I have this whole problem firmly under my control. It took a long time to pick up all the necessary elements one by one an put them together in a coherent framework that actually works.
The real motivation to finally do away with this problem was the book building function.
If you build a book from thousands of games, this may take a long time, even in the order of hours. You can't just sit there for half an hour staring at a button in a pushed state and not knowing how the book building operation is going, whether the application has crashed, without the opporunity to shut down the whole thing safely.