The cloud offer with the price you cited is similar to running pharo on you own virtual linux machine. The ephemeric cloud is different: it uses pharo images themselves as containers and provides a simple Rest API to start them up.
Cost is $10 for up to 20 running images, the free account gives you already one to play.
The difference is that the ephemeric image is never saved, gets automatically killed after 30 minutes (and restarted when needed).
Just to clarify the "gets automatically killed after 30 minutes (and restarted when needed)" that's 30 minutes of inactivity, and gets restarted when a new request comes in.
> First, an Ephemeric application is "paused" after 30 minutes of inactivity. It means that the Pharo Image is stopped and all the associated resources are removed from the memory. Ephemeric Cloud is designed specially for web solutions hence by "inactivity" it is meant no HTTP requests sent to the Ephemeric. The system automatically starts the Epehemric application upon the next request so for the user it looks like it was never off.
How fast is the restart after it gets killed? I am thinking of brochure sites using SandstoneDB. What is the best way to save data to be loaded into SandstoneDB - class-side methods perhaps?
The restart is like 5 seconds or so. Of course, it depends on Image. Please keep in mind that Ephemeric instances are not able to save data to a local disk, so there will be restrictions on using SandstoneDb.
To store data you may run Mongo DB and configure a secure channel from the ephemeric or just use Pharo appliance at Pharocloud - with disk, no restarts and without other ephemeric restrictions so you will be able to use SandstoneDb on a full scale.
If you are interested in helping with the Editor and improving text support in general... the first step is to help with the new text model. If you are interested, contact us. It would be nice to have that ready for Pharo4 :-)
I was under the impression that the new editor is already in Pharo 3? I don't remember all the details, but I think I at one point saw some rich editing classes while browsing packages in my image. It implemented line-numbers and other niceties. But it may have been something I installed from squeaksource. Anyway, I only recently started playing with Pharo 3, and noticed many improvements to editor, but didn't have the time to investigate so I just assumed it's already done.
I would really like to contribute somehow to Pharo development, it's absolutely fantastic piece of software. I went through tickets on official bug-tracker, but there are many of them and it's hard to tell which are important and which are being worked on. (BTW: Komitter is a very nice idea!) I didn't write to the mailing list, because I don't have (especially lately) enough time to do anything substantial; I just wanted to get some simple regression (for example) which I could fix in a couple of minutes/half an hour. The section of bug tracker with tickets like this would be a great help. Otherwise I'll certainly try to get involved more once I have a bit more free time :)
We are working on bootstrapping Pharo from source. Have a look here: https://github.com/guillep/PharoKernel But it's tricky and I guess it will take until Pharo4 or Pharo5 until this is in the main release
1) No. The object-as-sources ("storeString") is very slow an has many negative effects. E.g. the result is a large string, you need the compiler for de-serialization... all in all, if you look at current Smalltalks, this feature is not used too much.
Saving the whole state of the world to an image is not implemented by using #storeString. Instead it saves the whole heap of the vm to a file. Very fast, but of course this means that the resulting file is specific for 32bit vs. 64bit, endianess... and, very important, object layout (Object Headers are saved as they are in memory). So it is not really serialisation in the classic meaning of the word.
2) Implementing storeString like in Smalltalk needs some reflective features, e.g. enumerating instance variables, setting instance variables after creating new objects when recreating. And the compiler needs to be part of the language, as the string is one huge Smalltalk expression.
3) For image snapshotting serialization is not really the correct term.
The memory is just written from RAM to Disk. For #storeString, yes, this is serialization.
1) normal pharo cloud 2) ephemeric
The cloud offer with the price you cited is similar to running pharo on you own virtual linux machine. The ephemeric cloud is different: it uses pharo images themselves as containers and provides a simple Rest API to start them up.
Cost is $10 for up to 20 running images, the free account gives you already one to play.
The difference is that the ephemeric image is never saved, gets automatically killed after 30 minutes (and restarted when needed).