[squeak-dev] unsubscribe

Yassine Khlifi

Bull, Architect of an Open World TM
Centre De Services Paris
e-mail: [hidden email]
tel  :  01-69-93-92-92 (223-9292)
site : http://www.bull.com


|---------+--------------------------------------------->
|         |           [hidden email]|
|         |           ndation.org                       |
|         |           Envoyé par :                      |
|         |           [hidden email]|
|         |           ndation.org                       |
|         |                                             |
|         |                                             |
|         |           25/03/2009 12:58                  |
|         |           Veuillez répondre à squeak-dev    |
|         |                                             |
|---------+--------------------------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |        Pour :   [hidden email]                                                                         |
  |        cc :                                                                                                                   |
  |        Objet :  Squeak-dev Digest, Vol 75, Issue 43                                                                           |
  >-------------------------------------------------------------------------------------------------------------------------------|



Send Squeak-dev mailing list submissions to
             [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit

http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev
or, via email, send a message with subject or body 'help' to
             [hidden email]

You can reach the person managing the list at
             [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Squeak-dev digest..."


Today's Topics:

   1.  WorldState deferredUIMessages queue (Chris Muller)
   2.  Re: WorldState deferredUIMessages queue (Andreas Raab)
   3.  Re: WorldState deferredUIMessages queue (Andreas Raab)
   4. Re:  [bug] xor: is this an old bug or what? (Eliot Miranda)
   5. Re:  Re: WorldState deferredUIMessages queue (Bert Freudenberg)
   6. Re:  Re: How to get a list of all plugins in VM (Andreas
      Raab) (Igor Stasenko)
   7.  Re: WorldState deferredUIMessages queue (Andreas Raab)
   8. Re:  Re: WorldState deferredUIMessages queue (Igor Stasenko)
   9. Re:  Re: OSProcess capabilities on Windows (UZONYI Levente)
  10.  Agenda for Board meeting March 26th 2009 (Andreas Raab)
  11.  Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on
      Windows] (Aran Lunzer)
  12.  Re: ProcessWrapperPlugin.dll [was: OSProcess          capabilities
on
      Windows] (Andreas Raab)
  13.  Re: [bug] xor: is this an old bug or what? (Klaus D. Witzel)
  14.  How to tell if you have a boolean when you care to know
      (Jerome Peace)
  15.  Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on
      Windows] (Aran Lunzer)
  16.  Re: ProcessWrapperPlugin.dll [was: OSProcess          capabilities
on
      Windows] (Andreas Raab)
  17.  Re: ProcessWrapperPlugin.dll [was: OSProcess capabilities on
      Windows] (Aran Lunzer)
  18. Re:  Re: ProcessWrapperPlugin.dll [was: OSProcess
      capabilities on Windows] (Simon Kirk)
  19.  Re: Newbie Questions (Keith Hodges)
  20.  Monticello compatibility (was Re: Newbie Questions)
      (Bert Freudenberg)


----------------------------------------------------------------------

Message: 1
Date: Tue, 24 Mar 2009 16:17:37 -0500
From: Chris Muller <[hidden email]>
Subject: [squeak-dev] WorldState deferredUIMessages queue
To: squeak dev <[hidden email]>
Message-ID:
             <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

(3.9 Morphic).  With Maui I occassionally get World lockups due to the
UI process waiting for the #next of the deferredUIMessages, which is
empty.

Specifically, the freeze, when it occurs, is always in
WorldState>>#runStepMethodsIn:.  There's a while loop to process
messages in the queue:

             "Dispatch deferred messages while maintaing rudimentary UI
responsiveness."
             [i < numItems and: [(Time millisecondsSince: stamp) < limit]]
                         whileTrue: [queue next value. i := i + 1].

and its hung waiting for "queue next".  But it seems like this
shouldn't be possible because, at the top of the method, "numItems" is
set to the size of the queue.

             numItems := queue size.

and so the only explanation is, somehow in processing one of the
messages, it causes another one to be removed from the queue.  This
appears to be possible if the first message calls a #doOneCycle,
leading it back through this same method..

I do have 4 or 5 #doOneCycles sprinkled around, in order to force
correct layout or screen redraws.  I'm pretty sure these are causing
the deadlock but.. when I tried taking some of them out I get the
layout/redraw problem..

Any advice is greatly appreciated.

 - Chris


------------------------------

Message: 2
Date: Tue, 24 Mar 2009 14:37:26 -0700
From: Andreas Raab <[hidden email]>
Subject: [squeak-dev] Re: WorldState deferredUIMessages queue
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Chris Muller wrote:
> (3.9 Morphic).  With Maui I occassionally get World lockups due to the
> UI process waiting for the #next of the deferredUIMessages, which is
> empty.
>
> Specifically, the freeze, when it occurs, is always in
> WorldState>>#runStepMethodsIn:.  There's a while loop to process
> messages in the queue:
>
>            "Dispatch deferred messages while maintaing rudimentary UI
responsiveness."
>            [i < numItems and: [(Time millisecondsSince: stamp) < limit]]
>                        whileTrue: [queue next value. i := i + 1].

This is plain wrong. I don't know what the rationale of the change was
but you'll have much better success if you change this to e.g.,

             queue := self class deferredUIMessages.
             [(msg := queue nextOrNil) == nil] whileFalse: [
                         msg value.
             ].

The reason why the original version is wrong is that there is absolutely
no assurance that some Morph won't call World doOneCycle which would
re-enter the above loop, pull out all of the events and leave the
original caller hanging; just as you report.

Cheers,
   - Andreas


------------------------------

Message: 3
Date: Tue, 24 Mar 2009 14:43:24 -0700
From: Andreas Raab <[hidden email]>
Subject: [squeak-dev] Re: WorldState deferredUIMessages queue
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Chris Muller wrote:
> Any advice is greatly appreciated.

Actually, here is a fun test to exercise the problem:

testDoOneCycleWorksWithDeferredQueue
             "Ensure that nested doOneCycles don't break deferred UI
messages"
             | finished |
             [
                         WorldState addDeferredUIMessage:[World
doOneCycleNow].
                         WorldState addDeferredUIMessage:["whatever"].
                         World doOneCycleNow.
                         finished := true.
             ] valueWithin: 1 second onTimeout:[finished := false].
             self assert: finished

Cheers,
   - Andreas



------------------------------

Message: 4
Date: Tue, 24 Mar 2009 15:01:45 -0700
From: Eliot Miranda <[hidden email]>
Subject: Re: [squeak-dev] [bug] xor: is this an old bug or what?
To: "Randal L. Schwartz" <[hidden email]>
Cc: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID:
             <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

On Tue, Mar 24, 2009 at 1:36 PM, Randal L. Schwartz
<[hidden email]>wrote:
e.g.
> (false
> Eliot> xor: #blah) ifTrue: ... will raise a mustBeBoolean error.
>
> What I don't like about this is that the right operand doesn't get a
chance
> to
> "boolify" itself, or define its own xor logic.  The double-dispatch
> versions
> were a lot better at that.




If you want to do that you could implement it as

False> xor: aBoolean
    ^aBoolean not not

but I'd argue that isn't necessary.  The old code didn't type check and
we've lived with it for a loooong time.

But in any case, the not is a form of double-dispatch.  It just points out
that one can use not instead of xorTrue and is more comprehensible because
"not" is familiar.



>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
> <[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside
> discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090324/fd3aecb9/attachment-0001.htm


------------------------------

Message: 5
Date: Tue, 24 Mar 2009 23:13:27 +0100
From: Bert Freudenberg <[hidden email]>
Subject: Re: [squeak-dev] Re: WorldState deferredUIMessages queue
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes


On 24.03.2009, at 22:37, Andreas Raab wrote:


FWIW, the 3.8 method looked like this:

             [queue isEmpty] whileFalse: [queue next value].

- Bert -



------------------------------

Message: 6
Date: Wed, 25 Mar 2009 00:16:04 +0200
From: Igor Stasenko <[hidden email]>
Subject: Re: [squeak-dev] Re: How to get a list of all plugins in VM
             (Andreas          Raab)
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID:
             <[hidden email]>
Content-Type: text/plain; charset=UTF-8

2009/3/24 Maarten Maartensz <[hidden email]>:
> Hello Andreas,
>
> Long time, no see but I still follow Squeak and my Squeak Help on my
site. See
>
> http://www.maartensz.org/computing/computingFrame.htm
>
> which I wrote for Squeak 3.7 is still used daily on my site by quite a
few
> visitors, so apparently it still satisfies a need.
>
> My main reason to keep following Squeak is interest (it looks a lot
better now
> than a few years ago) in HLL, Smalltalk and Morphic, but my own main
interest in
> computing and programming these days is mostly in assembly.
>
> And this caused my answering this thread, though it doesn't answer Ross
Boylan's programs
> that answer many queries, also about what is really there in Squeak.exe,
all
> laid out neatly.
>
> A great one for this (also in size and capacities) is OllyDbg, by Oleg
Yushuck;
> a small one (idem) is PEView by Wayne Radburn. Both are at various places
on the
> internet, and easily found with Google.
>
> The last one is most convenient here. The one I used  is 0.9.8.0 that
takes -
> unzipped - all of 67 Kb (it's programmed in assembly, you see, and there
is no
> image at all...) which neatly shows in its SECTION.edata (e.g. EXPORT
Address
> Table) which primitives are in the executable. Likewise, its
SECTION.idata
> displays the loaded DLLs.
>
> To find this and much more, all one needs is PEView and opening
Squeak.exe in
> it, which then lists it quite neatly. If one knows some C or Assembly
this is
> all
> quite revealing and interesting, and one item to be found thus at various
places
> is e.g. "Andreas Raab", at least in the version of Squeak.exe I inspected
this
> way.
>
> In any case... some questions about Squeak.exe can definitely be answered
quite
> easily and fastly on Windows using PEView.
>

Why use reverse engineering tools, where its more appropriate to use
reflection?



--
Best regards,
Igor Stasenko AKA sig.


------------------------------

Message: 7
Date: Tue, 24 Mar 2009 15:18:01 -0700
From: Andreas Raab <[hidden email]>
Subject: [squeak-dev] Re: WorldState deferredUIMessages queue
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Bert Freudenberg wrote:
Which is not entirely safe either since there can a contention for the
queue inbetween #isEmpty and #next. We found this when we were still
using Morphic worlds in Croquet that would execute concurrently (bad
idea ;-)

Cheers
   - Andreas


------------------------------

Message: 8
Date: Wed, 25 Mar 2009 00:21:52 +0200
From: Igor Stasenko <[hidden email]>
Subject: Re: [squeak-dev] Re: WorldState deferredUIMessages queue
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID:
             <[hidden email]>
Content-Type: text/plain; charset=UTF-8

Hmm.. what purpose of timestamp there?
Both variants (3.8 and Andreas) don't checking it.
Maybe the purspose of change were to include the timestamp checking,
but it was introduced a bug with incorrent queue handling.

2009/3/25 Andreas Raab <[hidden email]>:
> Bert Freudenberg wrote:
>>
>> On 24.03.2009, at 22:37, Andreas Raab wrote:
>>>
>>> Chris Muller wrote:
>>>>
>>>> (3.9 Morphic).  With Maui I occassionally get World lockups due to
the absolutely
>>> no assurance that some Morph won't call World doOneCycle which would
>>> re-enter the above loop, pull out all of the events and leave the
original
>>> caller hanging; just as you report.
>>
>>
>> FWIW, the 3.8 method looked like this:
>>
>>    [queue isEmpty] whileFalse: [queue next value].
>>
>
> Which is not entirely safe either since there can a contention for the
queue
> inbetween #isEmpty and #next. We found this when we were still using
Morphic
> worlds in Croquet that would execute concurrently (bad idea ;-)
>
> Cheers
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.


------------------------------

Message: 9
Date: Wed, 25 Mar 2009 00:35:25 +0100 (CET)
From: UZONYI Levente <[hidden email]>
Subject: Re: [squeak-dev] Re: OSProcess capabilities on Windows
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Hi!

> So... I tried installing it, but none of my 3.7 images (on XP or on
Vista)
> could work with the ready-built DLL.  Not even the out-of-the-box 3.7
> release.  The 3.9 release image seemed much happier: the precise example
> you gave here didn't work as I was expecting, but the basic example on
the
> SqueakSource summary page did:
>
>  ProcessWrapper new
>    useStdout;
>    startWithShellCommand: 'echo hello';
>    upToEnd
>
>  -->  'hello<cr>'
>

To make sure that the given example works as expected, you have to make
sure that cat (cat.exe) is in the vm's search path, or you have to use
the explicit path to the executable, like here:

p := ProcessWrapper new
         useStdout;
         startWithCommand: 'C:\UnxUtils\usr\local\wbin\cat.exe';
         yourself.
p writeToStdin: 'foo'.
self assert: (p next: 3) = 'foo'.
p closeStdin.

If you don't have cat.exe (because windows doesn't have it by default),
you can download the unxutils package which contains it from:
http://unxutils.sourceforge.net/

If you have cat.exe and touch.exe in the vm's search path, then you can
run the tests in the package which should all be green.

Cheers,
Levente


------------------------------

Message: 10
Date: Tue, 24 Mar 2009 19:33:18 -0700
From: Andreas Raab <[hidden email]>
Subject: [squeak-dev] Agenda for Board meeting March 26th 2009
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Folks -

The agenda for our next board meeting is available at

http://squeakboard.wordpress.com/2009/03/25/agenda-for-march-26th-2009/

If you have issues you'd like to put on the list (either for now or
later) please bring them up here or as a follow-up on the above post.

Cheers,
   - Andreas


------------------------------

Message: 11
Date: Wed, 25 Mar 2009 12:20:00 +0900 (JST)
From: "Aran Lunzer" <[hidden email]>
Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess
             capabilities on Windows]
To: [hidden email]
Message-ID:

<[hidden email]>
Content-Type: text/plain;charset=iso-2022-jp

Andreas wrote:
>Aran Lunzer wrote:
>> Looking at the source code for the DLL, I'm afraid that at the level of
my
>> non-Squeak skills it would probably take me a day to rebuild it.  Do you
>> happen to have a 3.7-specific compiled DLL?
>
>It is extremely unlikely that the problem is with the DLL. More likely
>you are switching between VMs that are not compatible with this version.
>Try running your 3.7 images with a more recent VM and see if this works
>with the DLL in question.

Back in my original message about OSProcess I mentioned that I'm working
with a 3.7 Web-browser-plugin VM that has been customised (to do various
things in support of the .NET bridge).  If I can't persuade ProcessWrapper
to work with that, I can't use it.  At least, not this year  :-)

I did a little more testing and, as you suggested, the more recent VM
helped: the out-of-the-box 3.8 release (6665), for example, couldn't load
the ProcessWrapper DLL with its standard VM (Nov 2003), but could when I
wheeled in the VM from 3.9.

So it seems that something has changed in the VMs, and that something in
the DLL only works with new ones.  But given that Balasz said that they
had used ProcessWrapper with 3.7, I wondered whether they had - or could
recompile - a version of the DLL that would be compatible with an old VM.

What has changed in the VM wrt DLL loading?  Something to do with
64/32-bit support, perhaps?


All the best -

Aran





------------------------------

Message: 12
Date: Tue, 24 Mar 2009 20:28:30 -0700
From: Andreas Raab <[hidden email]>
Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess
             capabilities on Windows]
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-2022-JP

Aran Lunzer wrote:
> So it seems that something has changed in the VMs, and that something in
> the DLL only works with new ones.  But given that Balasz said that they
> had used ProcessWrapper with 3.7, I wondered whether they had - or could
> recompile - a version of the DLL that would be compatible with an old VM.
>
> What has changed in the VM wrt DLL loading?  Something to do with
> 64/32-bit support, perhaps?

I don't recall. But you should be able to recompile the plugin for the
version you need it to work with unless it uses any of the newer
features. There are two ways to do that:

a) Grab the source for the original 3.7 build, put the plugin into the
proper place and build it against the 3.7 sources.

b) Use your current build environment and #define VM_PROXY_MINOR to be
the minimum version you can get away with (i.e., the minimum version the
plugin compiles with).

Both should work.

Cheers,
  - Andreas



------------------------------

Message: 13
Date: Wed, 25 Mar 2009 05:27:35 +0100
From: "Klaus D. Witzel" <[hidden email]>
Subject: [squeak-dev] Re: [bug] xor: is this an old bug or what?
To: [hidden email]
Message-ID: <op.urbyn9pxrf0v61@toshiba19>
Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii

On Tue, 24 Mar 2009 23:01:45 +0100, Eliot Miranda wrote:

This is, by Randal E. Bryant (who's using Shannon's expansion), equivalent

to

  ^ aBoolean ifTrue: [true] ifFalse: [false]

which the Squeak inlining compiler's magic + decompiler transforms to

  ^ aBoolean and: [true]

When implemented in one of these two forms, a comment can explain that
it's a not not implementation.

> but I'd argue that isn't necessary. The old code didn't type check and
> we've lived with it for a loooong time.

I think that Randal makes the point; especially when the result is stored
for later. The other boolean messages do implicit (by the inlining
compiler) check their argument for #isBoolean, that's what should be done
by #xor: as well.

--
"If at first, the idea is not absurd, then there is no hope for it".
Albert Einstein



------------------------------

Message: 14
Date: Tue, 24 Mar 2009 23:08:58 -0700 (PDT)
From: Jerome Peace <[hidden email]>
Subject: [squeak-dev] How to tell if you have a boolean when you care
             to know
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii



In another tread Keith Hodges wrote:

2009/3/24 Keith Hodges <keith_hodges at yahoo.co.uk>

> true xor: [ true ]  => true
>
> discuss
>
> Keith

a simple guard for a boolean can be written simply.

true xor: bar aBoolean

will throw an error when bar is not a boolean

if
Boolean>>aBoolean
^self
and all other classes agree not to implement aBoolean,

This pattern can be extended to do all sorts of dynamic type checking.

Keith: Great bug find says Puck.

Elliot: +1 for your proposed fix for #xor:

Yours in curiosity and service, --Jerome Peace

and his imaginative friend Puck, fearless bug finder and Trouble Maker.







------------------------------

Message: 15
Date: Wed, 25 Mar 2009 15:38:35 +0900 (JST)
From: "Aran Lunzer" <[hidden email]>
Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess
             capabilities on Windows]
To: [hidden email]
Message-ID:

<[hidden email]>
Content-Type: text/plain;charset=iso-2022-jp

Andreas Raab wrote:
Wow!  Approach (b) did the trick!  I only needed to increment by 1.

Sneaky but effective  :-)

Many thanks -

Aran





------------------------------

Message: 16
Date: Tue, 24 Mar 2009 23:44:58 -0700
From: Andreas Raab <[hidden email]>
Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess
             capabilities on Windows]
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-2022-JP

Aran Lunzer wrote:
>> b) Use your current build environment and #define VM_PROXY_MINOR to be
>> the minimum version you can get away with (i.e., the minimum version the
>> plugin compiles with).
>
> Wow!  Approach (b) did the trick!  I only needed to increment by 1.
>
> Sneaky but effective  :-)


Not sneaky at all. The interface is designed in such a way that you can
compile for older proxy versions if you'd like to.

Cheers,
  - Andreas


------------------------------

Message: 17
Date: Wed, 25 Mar 2009 16:34:05 +0900 (JST)
From: "Aran Lunzer" <[hidden email]>
Subject: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess
             capabilities on Windows]
To: [hidden email]
Message-ID:

<[hidden email]>
Content-Type: text/plain;charset=iso-2022-jp

Andreas Raab wrote:
Hmmm... I see what you're saying.  But I only recompiled the VM,
pretending that it has a minor-version of 6 when in fact it only includes
the changes up to 5.  That's surely sneaky, in general... though in this
case I have the source code of the newest VM and of the plugin, and a
quick look suggests no major code-breaking changes between 5 and 6.

And the test cases all run, so something must be happy.

Thanks again

Aran





------------------------------

Message: 18
Date: Wed, 25 Mar 2009 08:54:52 +0000
From: Simon Kirk <[hidden email]>
Subject: Re: [squeak-dev] Re: ProcessWrapperPlugin.dll [was: OSProcess
             capabilities on Windows]
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Hi There.

I see from this message that you're working in the .NET bridge. I did
a fair amount of work with this myself a year or two ago as a
potential means to migrate some of our legacy VB6 stuff via COM
interop so that we could use Squeak for our new software.

However, I had significant issues with load testing. When I started
hitting the system with many processes the bridge would
catastrophically fail due to limitations in the Windows TCP/IP stack:
I'm sure you're aware that Windows has a built-in limit on the number
of allowed open Sockets: I would quite easily hit this limit if I
pushed hard enough, as the architecture of the bridge didn't clean up
quickly enough for dead Squeak processes (this may really be a
limitation in Squeak rather than the bridge, but the reliance on TCP/
IP communication between the two effectively means the same thing).

I had planned to try removing the use of sockets entirely and moving
to something more scalable, but in the end the use case evaporated.

But I'd still love to know if you have progressed the bridge in a way
that means you no longer get problems like the one I have described
above. I'd also be willing to share any of the work I did in case it
might help you, if I can find it.

Regards,
Simon

On 25 Mar 2009, at 03:20, Aran Lunzer wrote:



Consider your responsibility to the environment - think before you print!

******************************************************************************************************************************************

This email is from Pinesoft Limited. Its contents are confidential to the
intended recipient(s) at the email address(es) to which it has been
addressed. It may not be disclosed to or used by anyone other than the
addressee(s), nor may it be copied in anyway. If received in error, please
contact the sender, then delete it from your system. Although this email
and attachments are believed to be free of virus, or any other defect which
might affect any computer or IT system into which they are received and
opened, it is the responsibility of the recipient to ensure that they are
virus free and no responsibility is accepted by Pinesoft for any loss or
damage arising in any way from receipt or use thereof.
*******************************************************************************************************************************************



Pinesoft Limited are registered in England, Registered number: 2914825.
Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA


------------------------------

Message: 19
Date: Wed, 25 Mar 2009 11:05:54 +0000
From: Keith Hodges <[hidden email]>
Subject: [squeak-dev] Re: Newbie Questions
To: [hidden email],
             [hidden email],            The
general-purpose Squeak
             developers list
<[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1

Cross posted because I think others may find this discussion useful:

Chris Muller wrote: You dont, but I kind of assume that you are a user too. It should be more so.

The original MC1 made no effort to make anything compatible with
anything else. It uses a simple binary storeOn: so save its binary data.
This means that if you add an instance variable to any class in MC1's
model, your packages are incompatible with past MC1's  This is what
happened, the MC in 3.9 added support for traits, and so packages saved,
with that MC are incompatible with previous MC's.

MC1.5 knows about this, and if a model class is realised with have extra
data items, that it does not have inst vars for, it pops them into a
properties dictionary. Also, MC1.5 makes an effort to only save the
minimum amounts of instVars, so if your class does not have any Traits
it saves, only the non-trait oriented inst-vars, and in doing so in
theory the packages it generates should be compatible with even the
older non 3.9 MC's.

The original MC1 was very naive about handling errors. It would simply
retry anything that raised an error. There were a number of situations
that it did not handle well, such as renaming or re-ordering of inst vars.

MC1.5 takes a much more considered approach. It attempts to actually
make the class definition compatible with both the before and after
situations, when loading methods. Obviously this is not always possible.

In theory MC1.5 should handle more of the difficult cases, than MC1.0
did. However that doesn't stop people blaming MC1.5 if a package doesnt
load, and they may find that the old MC1.0 can handle it using its old
brute force approach.

Finally MC1.6 with atomic loading is really cool, its over 3 times
faster, which for something the size of Magma is a big deal. (However
last time I tried it there was a minor bug)

thanks for asking the relevant questions.

Keith













------------------------------

Message: 20
Date: Wed, 25 Mar 2009 12:52:27 +0100
From: Bert Freudenberg <[hidden email]>
Subject: [squeak-dev] Monticello compatibility (was Re: Newbie
             Questions)
To: The general-purpose Squeak developers list
             <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

On 25.03.2009, at 12:05, Keith Hodges wrote:
> The original MC1 made no effort to make anything compatible with
> anything else. It uses a simple binary storeOn: so save its binary
> data.
> This means that if you add an instance variable to any class in MC1's
> model, your packages are incompatible with past MC1's  This is what
> happened, the MC in 3.9 added support for traits, and so packages
> saved,
> with that MC are incompatible with previous MC's.

Well, actually, in MC1 the binary snapshot was nothing than a speed
optimization. It stored the source code as text, too. If the binary
snapshot loading failed, it fell back to parsing the source. Has this
changed?

Indeed. Or annoying issues like not sorting class vars leading to
spurious conflicts.


Sounds rather nice. Wish I could spend more time playing with it. I
have a question though:

How does the Installer-based 3.11 development style go together with
Monticello packages? Wouldn't every bug fix installed per changeset
from Mantis make the packages dirty?

- Bert -




------------------------------

_______________________________________________
Squeak-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev

End of Squeak-dev Digest, Vol 75, Issue 43
******************************************