Squeak SmallWiki

[Charles A. Monteiro]

I don't remember if Squeak has something like VW's BOSS, I am sure that  
there must exist some sort of  object serializer. I built very quickly a  
StorageManager (VW SmallWiki obviously) based on Boss and it works like a  
charm. A test on essentially the default root structure shows that it is  
10x smaller than a SIXX based storage and the entire time to snapshot  
which includes maintaining a FIFO type versioning for the last 10  
snapshots takes about 300 ms. Of course this does not address what seems  
to be a threading issue but I personally get nervous about snapshoting  
live images , sometimes things can get funky.

-Charles

On Thu, 12 Aug 2004 12:45:30 -0700, Nevin Pratt <nevin at bountifulbaby.com>  
wrote:

> Yes, you can evaluate 'server storage snapshot' from a workspace without
> it hanging the image.
>
> The actual image save accomplished by the SWImageStorage storage manager
> is just
>
>    Smalltalk saveImageInFileNamed: (Smalltalk fullNameForImageNamed:
> newName).
>
> For this not to work suggests some kind of issue with the fact that it
> is issued from within a thread (the storage manager runs in its own
> green thread).  Which, of course, in turn could be a Semaphore issue--
> who knows.
>
> In any case, SmallWiki on Squeak is not ready for production, and won't
> be until there is a reliable storage manager.
>
> Nevin
>
>
>
> Maurice Rabb wrote:
>
>> Hi Nevin,
>>
>> From what I remember, I had the same problem that you describe.
>> However, I noticed that if I directly commanded (from a workspace) a
>> SWImageStorage to save, everything worked fine.
>>
>> I think I deduced that what was hosing the images was a bad Semaphore.
>> I never have time to dig around and track down the exact source the
>> error.
>>
>> Maurice
>>
>> Maurice Rabb
>> 773-281-6003
>> mr at MauriceRabb.com
>>
>>
>> On Aug 10, 2004, at 9:13 PM, Nevin Pratt wrote:
>>
>>     OK, I had time to look at this again.
>>
>>     There is only one storage process-- the SWImageStorage
>>
>>     It looks like SWImageStorage does not attempt an image save unless
>>     it detects that the swiki changed.  But, if it attempts to save
>>     the image, the image is hosed, and the resulting image is also  
>> hosed.
>>
>>     The problem is definitely still there.
>>
>>     Nevin
>>
>>
>>
>>
>>     chris at chrisburkert.de wrote:
>>
>>     Hi Nevin,
>>
>>
>>     I "upgraded" yesterday. The problem is still there. The image hung
>>     over the evening.
>>
>>     could you please take a look in you process browser and make sure
>>     that
>>     there is only one storage process?!? The best is to kill all and
>>     create a
>>     new one.
>>
>>
>>     I'm using Squeak 3.6 final, on FreeBSD. The latest version of
>>     SmallWiki
>>     on SqueakMap is 0.9.23-- this actually seems to be a "backrev"
>>     from the
>>     one I started with last fall:
>>
>>     (on the "new" image) SWSmallWiki versionString --> 'SmallWiki  
>> 0.9.23'
>>     (on the "old" image) SWSmallWiki versionString --> 'SmallWiki 1.0'
>>
>>     I changed this version string which came from the VW version,
>>     because it
>>     was not the correct string. You the versioning numbers from SM.
>>     Currently
>>     it should be 0.9.23-6 for the kernel which means it is revision 6 of
>>     0.9.23.
>>
>>
>>     For what its worth, when the install asks if I want the Star
>>     Browser, or
>>     any of the other extras, I say "no".
>>
>>     You don't have to load these packages. So "no" and "yes" are
>>     correct answers.
>>
>>     Chris Burkert
>>
>>     PS: I'm away for 2 weeks so please don't expect answers for this
>>     time. I'm
>>     cycling from the ore mountains in saxony to wallis in switzerland  
>> and
>>     back. Till then ...
>>
>>
>>
>>
>>
>>     --
>>     Nevin Pratt
>>
>>     Bountiful Baby
>>     http://www.bountifulbaby.com
>>     The Most Complete Reborn Supply Store On The Web!
>>
>>     (801) 992-3137
>>
>>
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/