I've committed a fix to build.xml - it's just that as new versions of eclipse come out they archive the old ones, and the URL becomes invalid.
I haven't had a chance to test lapSqueeze, so no guarantees I've completely rewritten the code that locates resources (images, audio, script files) in the hope of being able to build self-contained jar files that contain scripts, images etc. I might not quite have put everything back the way it was, but the up-side is that the new resource location code is easily extensible and I can fix problems pdq.
I might have more time to work on this from now on, so report problems and I'll try to get it stable.
solipsist wrote:I've committed a fix to build.xml - it's just that as new versions of eclipse come out they archive the old ones, and the URL becomes invalid.
Thanks, I tried the new sources. The good news is that the svn checkout works fine, then I edited build.xml to change the os to macosx and add a path to Javacc. The ant download then worked. Then the build worked.
So far, so good, but... it looks like there's a runtime issue with 32 vs 64 bit SWT libraries:
$ java -XstartOnFirstThread -jar dist/macosx-x86_64/pcm3.jar2012-06-08 22:08:47.875 java[43674:a07] [Java CocoaComponent compatibility mode]: Enabled2012-06-08 22:08:47.876 java[43674:a07] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.100000Exception in thread "main" java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source) at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source) at org.eclipse.swt.internal.C.<clinit>(Unknown Source) at org.eclipse.swt.widgets.Display.<clinit>(Unknown Source) at pcm.gui.swt.Global.<clinit>(Global.java:19) at pcm.UI.guiFactory(UI.java:56) at pcm.UI.create(UI.java:77) at pcm.PCM.main(PCM.java:29)
solipsist wrote:Try now - I never knew OSX/Intel came in 32-bit.
It doesn't -- 64 bit only. Looks like the error message was because something was trying to load a 32-bit library and couldn't.
I checked out the latest sources, build 826.
I altered the build.xml file so the os property was macosx, and to add a path to JavaCC
in the javacc element.
ant download worked properly, apparently downloading the appropriate libraries.
ant then succeeded in making a build.
Then I tried to launch thusly: java -XstartOnFirstThread -jar dist/macosx-x86_64/pcm3.jar ... and ... it worked?!
I tried to launch lapSqueeze, but it bombed out with an exception initializing the permanent store. Fair enough; no reason it should load a 4 year old saved game, though it would have been impressive to have done so! It would also be nice if pcm3 failed safely, i.e., let the script bomb as it wishes, but stay in a state able to launch a different script.
So I deleted the ancient save files, and tried again. There was a path problem, finding its way to the pictures associated with lapSqueeze. It was looking for a directory /pics/hostess/... rather than relative to the script. So it looks like pathnames are being interpreted as absolute, rather than as relative to the script file?
Choosing File/Show Properties terminates the application, with no diagnostic.
and ant picks these values up as defaults. (Coming soon to the README)
The rest is kind of what I'd feared. I rewrote the whole resource location subsystem, and haven't quite put it back the way it was. Hopefully soon - watch this space.
Thanks for the pointer. I'm obviously not an ant guy; more of an Apache buildr guy these days. (Oh, stop looking at me like that. I used to be an Apache maven guy, so I'm getting better, right? )
solipsist wrote:The rest is kind of what I'd feared. I rewrote the whole resource location subsystem, and haven't quite put it back the way it was. Hopefully soon - watch this space.
Excellent. It would be nice to navigate to resources relative to the script file, for example. Independent of what the current working directory is at the time of launch, which is what seems to be the case now? Or some other navigation paradigm of your choice.
Mmmm ... buildr looks cool. Writing a buildfile now :)
It would be nice to navigate to resources relative to the script file, for example.
The idea now is that Resources is the one-stop shop for accessing resources, via the method Resources.locate(context,name,type), which returns a URL.
This then uses a Strategy pattern to locate resources.
Right now the top-level Strategy object is a ChainStrategy, which invokes a list of strategies in sequence, returning the first answer received. These include classloader-relative strategies, filesystem-relative strategies and (now) script-relative strategies.
solipsist wrote:Mmmm ... buildr looks cool. Writing a buildfile now :)
Uh oh... didn't mean to proselyte! :)
solipsist wrote:The idea now is that Resources is the one-stop shop for accessing resources, via the method Resources.locate(context,name,type), which returns a URL.
This then uses a Strategy pattern to locate resources.
Right now the top-level Strategy object is a ChainStrategy, which invokes a list of strategies in sequence, returning the first answer received. These include classloader-relative strategies, filesystem-relative strategies and (now) script-relative strategies.
Oh, you're going to be systematic about finding resources, actually thinking it through in advance? How novel! More programmers should do this... :)
Methinks script-relative is the most useful for when one wants to package up resources with scripts.
I've completely rewritten the code that locates resources (images, audio, script files) in the hope of being able to build self-contained jar files that contain scripts, images etc. I might not quite have put everything back the way it was, but the up-side is that the new resource location code is easily extensible and I can fix problems pdq. 
)