|
From: Laszlo G. <gu...@la...> - 2001-11-28 00:45:36
|
Hi Again, Sending off my previous mail, I realized that I might as well give you some hints on what I was spending my spare time over here (w.r.t. Repast, that is). And as I've just recently put something like this together, below I will be unscrupulously doctoring that text to keep you all informed. Gulya >1) I have completed the 'methodology' of the 'appletization' of > Repast models. It is a bit slow, but works -- and if you have > a good (and well-configured) browser, it could be expected to > cache the files. > The bad news, however, is that it does not seem to work on the Mac, > or at least, I could not find out what browser you would need for that. > (I.e. it would require some more reading.) > > In general, what is missing is a complete README & HOWTO > on this, but that should come soon -- although it has a very low > priority now. > >2) As the files required for the applet are quite large, I've explored > several ways to make them slim. None of them is completed, > however. > > a) The use of Sun's WebStart tool (JNLP API), instead of Applets. > This is a very promising area: the JNLP API is basically a new > approach to the programs-from-the-web idea, a competitor to > applets, but supported by Sun, too. The idea is that you install > a specific program on your computer (WebStart), which takes > over the handling of the program from your browser. WebStart > _does_ cache programs and what's more, is capable of > automatically > updating them, if they've changed on the web. > > Problem: I could not find any reference on WebStart working on > the Mac (although, it should as it's written in Java). > > Actually, I don't have a running version of any Repast model for > NT or unix either, as I did not have time to explore this > path any > further. > > It has zero priority now. > > b) Automatic 'repackaging' of the repast jar's, in order to > include only > the files that are actually used. I've played around with > several > free tools, and developed some testing code on my own, too. > None of these seems to work right away, although they have > different problems. The bottom line, however, is that it is not > quite as easy to do this as it may seem, as a lot of repast's > functionality is activated 'on-demand', i.e. if the user > presses a > button, etc. > > Moreover, it turns out that Repast itself (i.e., the > repast.jar) is NOT > overwhelmingly big at all. What makes the downloading time too > much > is the additional .jar's coming with Repast. And repackaging > those is > even trickier. The final obstacle that stopped me was that some > of them is actually digitally signed -- what is basically to > prevent others > (thus us) from tampering with the package. > > I haven't worked on this for a couple of weeks now, and it has > zero priority. > >3) I've been mostly working on the hexagonal space (sub)library. >I have the following (main) classes implemented: > > - Object2DHexaGrid > - Object2DHexaTorus > - Object2DHexaDisplay > - Value2DHexaDisplay > - Diffuse2DHexa > > for testing purposes: > > - Hexabugs -- a hexagonal version of heatbugs > - a hexagonal version of Schelling's Segregation model > - SpaceTest -- a simple model to test spaces, displays, and more > importantly, probes. It is also a good experiment as a framework > that includes all possible spaces (except networks) and allows the > user to dynamically select the appropriate one. > >Remaining tasks: > > - Multi2DHexaGrid > - Multi2DHexaTorus > - Ordered2DHexaGrid > - Ordered2DHexaTorus > - Multi2DHexDisplay > - NetworkHexaGridDisplay > > for testing purposes: > > - updating SpaceTest to include the multiple occupation spaces. > - finalizing and completing the sporadic jUnit tests I have now. |