[Haskell-cafe] Re: Getting my feet wet - small browser game
Marc A. Ziegert schrieb: software upgrades: use Read/Show classes instead of Foreign.Marshal, I'm having second thoughts here. Wouldn't Show evaluate all thunks of the data Shown? That would mean I couldn't use infinite data structures in data that goes out to disk. I don't think this would be a strong restriction for the communication between simulation and satellites, but I'm pretty sure it would be for doing backups of the simulation. Unfortunately, doing simulation backups is also the area where versioning is probably the harder problem. But I think I can work around that. I'd simply have to write a small upgrade program whenever data structures change, which unmarshalls using the old code and marshalls using the new code. Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting my feet wet - small browser game
jo: Marc A. Ziegert schrieb: software upgrades: use Read/Show classes instead of Foreign.Marshal, I'm having second thoughts here. Wouldn't Show evaluate all thunks of the data Shown? That would mean I couldn't use infinite data structures in data that goes out to disk. Btw, if you're dumping large structures to disk, using Read/Show is a bad idea :) Use NewBinary, at a minimum, or one of the other serialisation modules (possibly the one used in HAppS based on bytestrings) would be a better option. Read/Show is good for testing that the serialising code works, though. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Getting my feet wet - small browser game
Hi Btw, if you're dumping large structures to disk, using Read/Show is a bad idea :) Just as a mention how bad it is, maybe 30 times at Show and 50 times at Read. I used to use this approach, moving away from it and learning how to use Drift was a good idea. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Getting my feet wet - small browser game
Marc A. Ziegert schrieb: Comments and suggestions welcome :-) hi Joachim. i have some suggestions: apache: use fastcgi instead of hacking an own http-server. http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/doc/ http://www.cs.chalmers.se/~bringert/darcs/cgi-compat/doc/ Ah, that's excellent. The server in question will have FastCGI installed anyway (actually fcgid, so I'll see what the incompatibilities are). server: there are virtual linux servers out there, free to rent. some of them are even cheaper than the power-usage of one's old pc (at least compared to speed). if you intend to write a game for thousands of users, who play it 24/7, then it may be comfortable to rent one. (friends of me rented one.) I'm with a small webhosting company, so the server is there already :-) Of course, if the game ever attracts thousands of players and CPU and RAM usage start to affect other web presences, it should move to its own dedicated server. software upgrades: use Read/Show classes instead of Foreign.Marshal, and combine them with version counting data-structures: [code] data MyData = V1 String deriving (Show,Read) read_v1 :: MyData - String - data MyData = V1 String | V2 [String] deriving (Show,Read) read_v1 :: MyData - String read_v2 :: MyData - [String] - data MyData = V1 String | V2 [String] | V3 [(String,Int)] deriving (Show,Read) -- obsolete: read_v1 :: MyData - String read_v2 :: MyData - [String] read_v3 :: MyData - [(String,Int)] [/code] I'll try that out and let everybody know how well that worked. Thanks. i've thought about writing a browsergame in haskel, too; but atm, i have no time for (writing) games. I've known that feeling for quite a while :-) Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
