New SqueakMap on the air... and we got problems Houston!

Andreas Raab andreas.raab at gmx.de
Tue Apr 4 21:07:59 UTC 2006


goran at krampe.se wrote:
>> How about some sort of well-formed output, like (dare I use the word?) 
>> XML?
> 
> Hehe, well, I did consider that (a year or two back) but avoided it
> because I didn't want to take on the "luggage" that serialization code
> is (to be maintained for shape changes etc when the model evolves). Back
> in the beginning of SM I used Smalltalk as format and it was cumbersome
> to maintain it - but of course, then I also used an incremental model
> which made it even more complex.

Interesting arguments. In my experience, maintaining shape changes with 
image segments gets very hard very quickly. Utilizing well-defined 
external formats has (again, in my experience) proven to be much more 
robust when it comes to changes. Updating incrementally is certainly 
something that's a bit non-trivial, but if you look at the data records 
generated I think it'd be straightforward to merge them incrementally 
(discounting deletions but there are ways to deal with that, too).

>> I've attached a quick hack (well, okay it's been about an hour of 
>> work ;-)
> 
> Don't you have better things to do? Like getting Crocodile out the door?
> ;) I can't help wondering why you ended up coding on this? Just curious.
> :)

Oh, I just needed an hour of clean, mindless fun to relax from some of 
the harder things I'm working on ;-) Usually I play a game of mine 
sweeper but writing some XML exporter code works just as well. And 
besides, I *do* think this is an important issue and I don't think SM 
should be 3.8+ only for a reason as simple to solve as this.

> Mmmm, let me say that I would like to hear more views on this issue
> before deciding for the future. As I said XML has been on my radar but
> my main idea had actually been to use SmartRefStreams and not just a
> single one but instead "split" the model into accounts and enable them
> to be stored on multiple servers (along the lines previously discussed
> enabling personal, department, company and global wide maps etc).
> 
> But on the other hand - SmartRefStream and friends is probably just as
> sensitive to these things as ImageSegment is. So...

SmartRefStream is less sensitive to shape changes than image segments 
but it would be affected by the Byte vs. WideString problem in the same 
way (I think; with some retrofitting of the earlier Squeak versions you 
also may be able to change it to read ByteString and do something 
sensible about WideString but that seems a harder problem than just 
using a well-defined format).

>> PPS. If you're interested in a solution like this I should be able to 
>> spend another hour or two on the read back side as well.
> 
> Let us see what others say in the community but yes, after typing this
> email I am probably leaning towards this route - even though it "hurts"
> going back to coding these things - Magma or ImageSegments etc are so
> darn nice (when they work). ;)

Sure. And I have no problem at all throwing that solution away. But I 
thought it'd be interesting to see what the speed/space tradeoffs are 
since the classic discussion goes along the lines of "oh, but it's so 
large and so slow" and I wanted to be able to see if that's true (it is 
not - with the three most obvious optimization applied space goes down 
to 600k and speed to 3secs and that is roughly on par with the current 
format).

Cheers,
   - Andreas




More information about the Squeak-dev mailing list