Re: [gnugo-devel] GnuGo 3.2 port option

[Evan Berggren Daniel]

> > Could you explain a bit how having GNU Go listen
> > to a port will help with WinCE?
>
> In WinCE, all printf info are lost. In fact, all std
> io info are lost. It goes to nowhere as WinCE is a
> complete Windows environment. As small device becomes
> more and more popular, it is quite convenient to be
> able to play Go against one of the finest Go program
> while waiting in the airport.

Forgive me if I'm horribly ignorant, but could one use something like a
named pipe for this?  Nothing against ports, just wondering.

> > Of course you can reimplement the pattern matcher as
> > a non-default option if this is what you need to do
> > to get it to run on a small machine, or even fork
> > the
> > program but I doubt if we are interested in changing
> > the default pattern matcher to a different scheme if
> > it turns out to be slower.
>
> Forking the program is obviously a waste of resources.
> I am not asking for a change right now in pattern
> matching, just HOPING that both speed, flexibility and
> extensibility can be achieved without using too much
> resource (maybe by utilizing a small and fast
> database?).

My understanding is that the DFA mechanism used is significantly faster
and probably smaller if well implemented than just about anything else.
The basic problem is that there are a *lot* of patterns, and they simply
take a lot of space.  The best option is probably careful pruning of the
database.  Then again, I'm not terribly familiar with it.

Oh, if people think it would be feasible I might take a stab at
hand-assembling the DFA.  I'd have to take a look at the code and find
docs for the relevant architectures, but it shouldn't be too hard.
Whether I can beat gcc is an open question.  How much would a speed
improvement help, anyway?

Thanks

Evan Daniel