On 9 January 2013 20:54, Chris Muller asqueaker@gmail.com wrote:
The best way is to test it is on your own machine. Do you have access to the server?
In /home/squeakmap is the server image -- Squeak3.8-6665-sm.image. Grab it and the changes as well as "start.st" boots the server in the same directory (note a classic VM is required). Running it on your localhost so can actually step through debugger in the server to make sure the change works.
This is how I did the 2011 enhancements for the Release Editor and CSP improvements.
Doing this will also bring to light how badly we really need to improve or replace SqueakMap's implementation, particularly on the server side. :( The domain model itself is actually pretty nice, but the machinery needs improvement.
I poked around a fair bit and can't figure out how anything actually gets done. What would be really great is something somewhere saying "these are the routes we accept, that define the API as HTTP sees it" and that delegates implementation thereof to other objects. Kind've what one would see in a Sinatra app, I guess: https://github.com/lshift/rabbitmq-service-sinatra-sample/blob/master/rabbit...
But fair enough, Sinatra wasn't around when SqueakMap was born.
(While it'd be _nice_ to have SM vN+1 written in Smalltalk, if someone knocked up a Sinatra/whatever app that ran on Heroku, I wouldn't complain. Not a bit. Well, given the rash of JSON vulnerabilities plaguing Ruby at the moment, maybe not Sinatra.)
frank