13 Aug
2004
13 Aug
'04
5:40 p.m.
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(a)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:
--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
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(a)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(a)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