Add interface for building an iOS app

[horaceho]

No description provided.

[db3108]

On 22/05/2015 11:58, Horace Ho wrote:

---

    You can view, comment on, or merge this pull request online at:

#6

Hi Horace,

Thank you for your interest in using and developing michi.

I have a few concerns about the modifications you propose in this pull
request. These concerns certainly come partly from the fact that I do
not understand what you want to do. Maybe it would be a good idea if you
give me some general indications ...

I do not know what you know in Computer Go. So, please accept my best
apologizes if you already know very well all what follows (apologizes
also if I misunderstood your code).

Do you intend to provide a GUI in IOS for michi-c ? For playing games
and/or for modifying the internal parameters ? running it on Iphone
and/or Ipad ?
If yes, is it that the gogui GUI is not available for IOS or that it is
not well integrated with IOS ?

Depending on your answers to the previous questions, I may understand
better the purpose of the application you develop. (I must mention that
I know nothing about IOS development)

To explain (if this is necessary) why I feel I need to understand, I
will just take one example of the "problem" that I see ... As far as I
understand, you use the undo_move() function of michi-c in your
application. But this function is too limited to be provided in the user
interface (see the warning in the header comment of the function). In
addition, while adding the blocks and liberties tracking in the fast
board implementation I had to remove this function for the release to
come on michi-c2.

But this is not a problem as this kind of function is already provided
by gogui (as well as handicap stones handling, reading/saving sgf files,
etc.). The use of gogui avoid to integrate these functions in the gtp
engine, at least in the beginning, and to concentrate on the most
fundamental aspects of the engine (without gogui, implementing
undo_move() will take some time if we want to make it correctly --i.e.
with no reduction of the speed of the playouts--).

The gogui interface also permits the user to change parameters setting
of the engine through the GUI. If you do not see what I mean, you can
try to run fuego with gogui to see this in action (open the menu
"Tools/Analyze commands" after attaching fuego through the
"Program/Attach" menu.).

Too summarize, my objectives are to provide a simple gtp engine that is
able to play using the gogui interface or on KGS and CGOS servers. As my
spare time is limited, I want to avoid developing functions that are
already available elsewhere. According to these objectives, my
priorities are :

• accelerate (reasonably) the current code,
• implement gtp command for board size change,
• add timing and cleanup kgs gtp commands,
• add gtp commands to modify the parameters controlling the engine,
• improve the quality of play (open ended objective ...)

The second concern is that, as I mentioned in a previous mail, I would
like to keep the michi-c code as small and as simple as possible (for
beginners).
So, could you please in the future avoid to submit pull request in the
michi-c project (go instead to michi-c2) ? (Except, of course, if the
modifications provide simplifications or corrections to the current code
of michi-c.)

I apologize for the length of this mail. My excuse is that I feel we
both need to make our objectives very clear if we want to collaborate
and avoid as much as possible to waste our time.

Best,
Denis

[horaceho]

Dear Denis,

Yes, I am trying to build a GUI for michi-c, running on iPhone and iPad.

Since iOS does not support multiple processes running at the same time, I need to link the michi-c engine directly with the iOS GUI code. That's why:

• main() is separated into another main.c file which can be excluded from linking with the main iOS program

  To preserve both the GTP and iOS interfaces:

• a GTP version can be built by your existing Makefile

• an iOS version links with michi-ios.c and michi-ios.h

  Since I do not want to downgrade of the performance of michi when building the iOS version, any code changes for UI feature (i.e., not related to the engine) will not go into michi.c source. For example, you can see the iOS code allows one undo, only when the previous move (or pass) is valid. It's a wrapper to make the life of UI programmer easier.

  Yes, I will submit pull-request to michi-c2 in the future. Please feel free to ignore the current pull request. It's just an interface for anyone which may be interested to port michi-c to iOS.

Best regards
horace

[db3108]

Dear Horace,

Thank you for your explanations. I didn't know about multitasking and IOS.
I see now that you have a clear vision of your objectives (+ share of
work) and I think that there are fully compatible with mines.
I will not be able to work on michi during the next week-end. So,
tomorrow evening (UTC time), I will put a temporary but functional
version on michi-c2 in order you can see the new internal interfaces.
This is temporary because the optimization is not finished even if the
blocks and liberties tracking is. The internal interfaces that I can
provide and that could be useful for you should be stable now, I hope.
PS. Do you intend to keep the MIT license for your IOS app ?

Best,
Denis

[horaceho]

Dear Denis,

Thanks for update about michi-c2.

Yes, I will keep the iOS code in MIT license. I plan to release the iOS app as a separate project once it's more functional and will include michi-c2 as a git submodule.

Thanks
horace

[db3108]

Hi Horace, The michi-c2 project has been updated with the temporary release for you to be able to see the new internal interfaces induced by blocks and liberties incremental update (see ChangeLog). Results in term of speed are not yet completely satisfactory but there is room for improvements. Enjoy, if you have time. Denis

[horaceho]

Hi Denis,

Thank you! I've also uploaded the iOS app Mingo on GitHub.

Thanks
horace