** Unknown command: 'ell'
** Unknown command: 'hois'
** Unknown command: 'hois'
** Unknown command: 'hois'
** Unknown command: 'hois'

Hi... I get a lot of these, and it causes lags and it is very annoying.  I play with JavaFibs with a Mac System Leopard

Thanks

the first one tell you can abbreviate with just the letter t

the whois ... you need to type the whole word including the W and cut off those end quotes

If it's always and only the first character that gets lost then perhaps a command "spellchecker" could fix the command just before it's sentto Fibs?

Of course the commands as sent by the program logic are correct and always the same Strings.

The truncation happens most likely in a race condition when the parser is used threaded (where one thread parsing "steals" chars from the other), or on the network layer / IP level where the race condition assembles wrong packets. As said I dunno.

The JF parser is one *bleep* of *bleep* and nothing is easy to fix in there. It is inherently single threaded and stateful but used multithreaded. This is where the problem comes in, and if you know about spurious race conditions, you know they are very hard to debug. JF has more of them, btw, that's what I called "fix the design / architecture". Which basically is a rewrite of half of the code. Can't do that for time and license reaasons.

Ty 60+ . One can make a statement even a bit more general. When JF was originally written in the early 2000s, we had Java 1.3, today we more than half of a decade and 3 major releases (plus dozens of minor releases) from that.

Technical notes

Java is a threaded language, i.e. Parallelism is at the very core of its programming model. However, Java 1.3 hardly used that and did most jobs as if there was only one thing done at a time. JF hardcoded some assumptions about that behaviour into the core design. With each new release of Java since 1.3, the engine became faster and more complex. Quite a few of the dramatic speed improvements of Java 6 over 1.3 are owed to parallelism. Just think multi core CPU, Java naturally can use them without any code change. However, JF was never really redesigned to cope with increasingly parallel execution, at best there are some cludges.

Two more threading problems are:

* The list of known users is maintained in a non-threadsafe data structure. Effects of this are random crashes (of which some are kludged around, but you can't anticipate all cases) and the infamous list of players in "unknown" state. To some degree the "hois" problem is related.
* Sound didn't play anymore with Java 5 and up as the Java engine went from a single threaded sound processing to multithreaded. That one was rather easy to fix, 1.0.10 and up adapted.

Legal notes

User management and parsing/networking are too complex for easy fixes w/r to threading. A redesign is prevented by license model, in which Peter owns all rights and is unwilling to share. Actually I have written threadsafe parser code (and better board code too), but contributing the modules to JF means I lose all intellectual property rights in them. And that's something I will not do. The other way around, JF is not compatible with the GPL, so Peter couldn't use my code without opening JF as well. That's the dilemma. Peter refuses an open JavaFIBS, and I refuse my code being locked into a proprietary client.

I have currently have access to 3 parser/network layer implementations in Java:
* RepBot uses one which is pretty good, but it is not based on the CLIP but on the TELNET protocol to FIBS. This model is sufficient for RepBot, but would become a problem for a full GUI client quickly.
* JavaFIBS, which works on CLIP but has inherent design issues and of course is proprietary code
* OpenFIBS, my own clean room implementaton. That one is used by the RoboCop bot. It has has a clean design and is based on CLIP, modeled after the RepBot approach. However, it is not released in a maintainable form and is not yet feature complete. It currently doesn't handle all non-numeric CLIP codes, but those are needed to e.g. implement match play (as compared to user management and shout/tell/kibitz, which can be done with only numeric codes).

Opinion

I'm deeply convinced that only an open source model is sustainable for FIBS clients.

I've reserved the "openfibs" domains and sourceforge project setup earlier this year. What I can offer is to publish my own code on SourceForge under GPL, so others can build on it. Basically I got 40% of a JavaFIBS clone, and given the JavaFIBS situation I see no alternative to actually write a fresh client. But until next sprting, I can't spend time on an unpaid open source project, I need to earn money to pay for my backgammon addiction at times.

I'm on FIBS for ages and saw clients come and go, none of them left a codebase to build on after the original author lost interest. This is unfortunately the case for the two most frequently used FIBS clients, 3DFibs and JavaFIBS. Consider both unmaintained for all practical purposes. I've talked with both authors, and there is no way to convince them to open the code (for reasons I can not understand, but have to respect). Or think of CocoaFIBS and Delfibs. Promising in the beginning, but no longer maintained (or in the case of Delfibs open sourced).

Thx for listening to my whining, but it definitely is frustrating to be in the "FIBS coder scene". Burper cracked over it, and so much talent is wasted year by year. Sigh.