Page 3 of 3
Re: PCMistress 3 redux (for developers)
Posted: Thu Jun 07, 2012 10:39 am
by solipsist
Sorry to take so long - I missed this report.
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.
cheers
Re: PCMistress 3 redux (for developers)
Posted: Sat Jun 09, 2012 2:14 am
by froodly2005
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:
Code: Select all
$ 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)
Re: PCMistress 3 redux (for developers)
Posted: Mon Jun 11, 2012 9:53 am
by solipsist
Try now - I never knew OSX/Intel came in 32-bit.
Re: PCMistress 3 redux (for developers)
Posted: Sat Jun 23, 2012 5:39 pm
by froodly2005
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.
Re: PCMistress 3 redux (for developers)
Posted: Tue Jun 26, 2012 9:18 am
by solipsist
froodly2005 wrote:I altered the build.xml file so the os property was macosx, and to add a path to JavaCC
in the javacc element.
The intention is that you do
Code: Select all
ant -Dos=macosx -Djavacc=/usr/bin/javacc dist
rather than hack the build.xml.
The other convention (not sure if I've implemented it) is to create a file in your current directory called ".ant.properties" with
Code: Select all
os=macosxjavacc=/usr/bin/javacc dist
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.
Re: PCMistress 3 redux (for developers)
Posted: Wed Jun 27, 2012 12:54 am
by froodly2005
solipsist wrote:The intention is that you do
Code: Select all
ant -Dos=macosx -Djavacc=/usr/bin/javacc dist
rather than hack the build.xml.
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.
Re: PCMistress 3 redux (for developers)
Posted: Wed Aug 08, 2012 10:08 am
by solipsist
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.
Re: PCMistress 3 redux (for developers)
Posted: Wed Aug 08, 2012 4:15 pm
by froodly2005
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.