I think you over-engineered. Crafty can be easily integrated in an iOS app with only a single character addition. In SmallChess, an engine is communicated to the user interface with dup2(). This system call allows the standard input/output be accessed by inter-thread-communication. I ported your engine with only a single change:
int main() to int main_()
Your engine works perfectly on my phone.
I had already suggested dup2(). I had thought he said that would not work?
dup2() is the standard xboard way of doing things. I suppose my question would be, if you use dup2() with a thread, are you not zapping stdin for BOTH? Certainly works that way in unix...
It is a simple method to pair up with fork()/exec() ala' xboard.
I think i initially thought dup2 was just for use with Pipes. Pipes being inter process communication and I posted against last night initially to emphasize i was not running a second process with fork. I was happy to see it fall together and from what I'm seeing i still have the game history issue though I have one project with crafty code with game history file references removed working.
adams161 wrote:I think i initially thought dup2 was just for use with Pipes. Pipes being inter process communication and I posted against last night initially to emphasize i was not running a second process with fork. I was happy to see it fall together and from what I'm seeing i still have the game history issue though I have one project with crafty code with game history file references removed working.
dup2() works for anything. IE create a TCP/IP socket, connect it to a remote machine, then dup2() it over stdin/stdout. Now any use of stdin will read from that remote machine, and any writes to stdout will go to that remote machine. This is week 1 in my network programming course, in fact.
But normally dup2() is done in a forked process, because once you dup2() over stdout, YOU have no stdout either, not just the procedures you call after the dup2() was done, but now any of YOUR writes/printfs/etc will go to wherever you dup2()'ed that descriptor. Always funny to watch students do the dup2() over stdout so that the process they exec() will send stdout wherever they wanted to redirect it to, then discover something wrong and try to print an error message and it is nowhere to be seen.
I had to think about that last night. See my sample code has all printf's going to the crafty_out.txt file. But i wanted to confirm what was there and see it in console. I printed the results of crafty_out.txt to the stderr and it showed in the xcode console which i copied and pasted into my post last night. My own c networking etc background and even c background is rather limited But i'm a programmer and i thought let's see with one foot going in front of the other what i could do and was happy to see a result.
CraftyExit still shuts down the application but i realize now i don't need to shut crafty down. Start it once when not using it let it wait. I was concerned if it never exited it would never free its memory used with malloc. From research if the program gets reset ( which happens with iphone programs the OS terminates them and you go to your program you used 3 days ago and it restarts), but if the program resets i'm reading all memory including mallocs is reclaimed. So i start it once on every initialization of my main view and accept a minimum ram over head ( i can set the hash lower ), and that should be fine. If it resets the ram is claimed and when they restart i once again let crafty define the memory it wants.
Mike, I don't think you should bother spending any time on the memory required by the engine and whether it should be freed or not. You should never quit the engine thread, which means you should never release the memory acquired by the engine. If the device gets a memory warning message, ignore it and let the OS terminate you. This is extremely rare and almost impossible, if it happens a user will just simply restart the app or the device.
Thanks Ted i think I will do that and just leave crafty running. I was debating on if to only first start it when they use it or always initialize it at start-up. I think i will always initialize it so I can design for the idea its always ready to go.
I added another message to bob just kind of wrap up that i understand what he is saying by make the changed crafty source available. not by bits and pieces but what is sort of the binary which i'm doing.
And concluded and want to state it here, that if i get crafty working and i think i can, i will personally be proud as hell to have Crafty analysis in my app. It's for analysis particularly in openings. Crafty is a 2700 rated kind of program and users wont have to worry that if they make a few moves out of book or want to know what happens that they are left in the dark. Crafty will find any tactical blunders and point it out to them. It's good for study and starts at blunder check but goes further to let you know the likely moves that any of the users deviations from openings will bring on.
I wrote my own engine pulsar and know how hard this whole process is particularly for a pioneer like Bob Hyatt who didn't have a fruit program to clone
My own thoughts is aggressive forward pruning is a plus in modern engines but none of that need concern my users and crafty is an accurate engine and extremely strong and it's got a nice clever name that hopefully will drive some interest in the App Store. But more importantly its about offering a study tool. ( no plans for play right now ). Users expect to be able to double check and we don't have to beat Carlsen and much as explain the tactical and positional implications of lines which I decided my Pulsar would not be sufficient for in regular chess(pulsar plays variants). So as an engine author i'm going to let pulsar take a back seat here and i have a certain trust in Crafty. (assuming this all works as planned and i might bite off a bit much at times but there is proof of concept here and i'm sure i'll catch up)
dup2() is the standard xboard way of doing things. I suppose my question would be, if you use dup2() with a thread, are you not zapping stdin for BOTH? Certainly works that way in unix...
You are. To hell with it. stderr still seems to work. But when i release an iPhone app i don't want stuff printing. NSLog() for example is used to print debugging info in the console. It creates a file on the iPads drive and the information is insecure. It also is a drag on drive space (however slight text data is by size) So i'm trained to want to see no printing. But if i need to debug i can use stderr.
It's a bit of opportunism that i would allow this notion of trapping the standard output to run a service But i'm letting crafty write to a file i create and on each start of the program i suspect the proper method is to trim this file back to no data so it never grows more than whatever constitutes a session and does not become a drag on users hard drive ( for the mobile device) space.
The main point was could it work. I knew straight away going into this thread from what i was trying to do that i was willing to give up the standard output for analysis.
