Hi folks!
Ok, so I am meddling with SM in trunk etc. SMBase is updated in trunk, and so is SMLoader. SMBase had several issues in trunk, one is more interesting than others: I have tried to maintain SM outside of the image earlier - but since the code sits in the image I understand that people start hacking on it. :) The effect is that there have been some changes to SMBase in trunk that only work in *later images*. For example, changing ifNotNilDo: to ifNotNil:. That does NOT work in Squeak 3.8 for example. So now I have backed out a few of these fixes so that the code still works in 3.8. For the moment - since I don't want to "disturb" the trunk way of things too much - just keep in mind that if you fix stuff in SMBase, the code is CURRENTLY meant to work in 3.8 and higher! I am just about now upgrading the server image - it still runs 3.8 (I just don't have the time to do a full upgrade there), but uses the same SMBase code as trunk has. Finally, for SMLoader there are TONS of fixes now available on trunk. I don't know exactly why this stuff didn't get into the trunk image earlier - it is work done years back! Anyway, my advice for 4.1: - Upgrade SMBase to the latest I committed to trunk. Otherwise it will fail when trying to talk to the server! - Hold the SMLoader upgrade. It is larger and there are THREE slightly different SMLoader classes in that snapshot... More on that in another thread. regards, Göran |
On 4/11/2010 3:27 PM, Göran Krampe wrote:
> Finally, for SMLoader there are TONS of fixes now available on trunk. I > don't know exactly why this stuff didn't get into the trunk image > earlier - it is work done years back! Anyway, my advice for 4.1: > > - Upgrade SMBase to the latest I committed to trunk. Otherwise it will > fail when trying to talk to the server! > > - Hold the SMLoader upgrade. It is larger and there are THREE slightly > different SMLoader classes in that snapshot... More on that in another > thread. Sounds good to me. And of course a big thanks for these updates. Cheers, - Andreas |
In reply to this post by Göran Krampe
On 12.04.2010, at 00:27, Göran Krampe wrote:
> > I have tried to maintain SM outside of the image earlier - but since the code sits in the image I understand that people start hacking on it. :) The effect is that there have been some changes to SMBase in trunk that only work in *later images*. For example, changing ifNotNilDo: to ifNotNil:. That does NOT work in Squeak 3.8 for example. > > So now I have backed out a few of these fixes so that the code still works in 3.8. For the moment - since I don't want to "disturb" the trunk way of things too much - just keep in mind that if you fix stuff in SMBase, the code is CURRENTLY meant to work in 3.8 and higher! I ran into exactly the same problem this weekend. Wanted to work on packetizing the Etoys image, using Karl's script as a start. But I got stuck when filing in recent Monticello versions gave a *syntax* error because ifNotNilDo: was replaced by ifNotNil:. I agree with you that some packages should be kept compatible with older image versions. In particular those packages that are necessary to upgrade older code bases. Does anyone have a snippet to find in a package all ifNotNil: sends that have a 1-argument block? - Bert - |
Bert Freudenberg wrote:
> I ran into exactly the same problem this weekend. Another one was #fileNamed:do: (or perhaps #newFileNamed:do:) IIRC. regards, Göran |
On 12.04.2010, at 13:53, Göran Krampe wrote:
> > Bert Freudenberg wrote: >> I ran into exactly the same problem this weekend. > > Another one was #fileNamed:do: (or perhaps #newFileNamed:do:) IIRC. But that's easier dealt with since it is not a syntax error. Monticello had another syntax error: method annotations (a preference declaration). Hmm, seems futile at this point. Guess I'll have to apply Eliot's changes first. - Bert - |
In reply to this post by Bert Freudenberg
On Mon, 12 Apr 2010, Bert Freudenberg wrote:
> On 12.04.2010, at 00:27, Göran Krampe wrote: >> >> I have tried to maintain SM outside of the image earlier - but since the code sits in the image I understand that people start hacking on it. :) The effect is that there have been some changes to SMBase in trunk that only work in *later images*. For example, changing ifNotNilDo: to ifNotNil:. That does NOT work in Squeak 3.8 for example. >> >> So now I have backed out a few of these fixes so that the code still works in 3.8. For the moment - since I don't want to "disturb" the trunk way of things too much - just keep in mind that if you fix stuff in SMBase, the code is CURRENTLY meant to work in 3.8 and higher! > > I ran into exactly the same problem this weekend. Wanted to work on packetizing the Etoys image, using Karl's script as a start. But I got stuck when filing in recent Monticello versions gave a *syntax* error because ifNotNilDo: was replaced by ifNotNil:. > > I agree with you that some packages should be kept compatible with older image versions. In particular those packages that are necessary to upgrade older code bases. > > Does anyone have a snippet to find in a package all ifNotNil: sends that have a 1-argument block? | methods | methods := (PackageInfo named: 'EToys') methods collect: #compiledMethod as: IdentitySet. SystemNavigation default browseAllSelect: [ :method | (methods includes: method) and: [ (method getSource asString reject: #isSeparator) includesSubString: 'ifNotNil:[:' ] ]. Comments may be a problem with this approach, but that's pretty unlikely to happen. Levente > > - Bert - > > > |
Hi,
Am 2010-04-12 um 18:26 schrieb Levente Uzonyi: > (method getSource asString reject: #isSeparator) includesSubString: 'ifNotNil:[:' ] ]. Given _I_ would have written Code there, you wouldn't find any of it with this line, as I would have used 'ifNotNil: [:'. some other would have used 'ifNotNil:[ :' and even other 'ifNotNil: [ :'. anyhow, what about bytecode inspection? *duck&hide* ;) So Long, -Tobias |
On Mon, 12 Apr 2010, Tobias Pape wrote:
> Hi, > > Am 2010-04-12 um 18:26 schrieb Levente Uzonyi: > >> (method getSource asString reject: #isSeparator) includesSubString: 'ifNotNil:[:' ] ]. > > Given _I_ would have written Code there, > you wouldn't find any of it with this line, > as I would have used 'ifNotNil: [:'. > some other would have used 'ifNotNil:[ :' > and even other 'ifNotNil: [ :'. The separators are rejected, so all variations you mentioned will be found. > anyhow, what about bytecode inspection? *duck&hide* ;) That could work too, but that's probably a lot more complicated. Levente > > So Long, > -Tobias > > > |
In reply to this post by Bert Freudenberg
Hi Bert,
On Mon, Apr 12, 2010 at 2:18 AM, Bert Freudenberg <[hidden email]> wrote: On 12.04.2010, at 00:27, Göran Krampe wrote: Why not upgrade the compiler with Vassili's ifNotNil: enhancement? I believe versions of his changes go back to 3.8. He has a change set for 3.8 or thereabouts on his web site. All systems with my closure compiler support ifNotNil: with an argument. So there are lots of sources for the enhancement. I could get this done for you tomorrow night if you're leery of doing it yourself.
best Eliot
|
On 12.04.2010, at 20:47, Eliot Miranda wrote: Hi Bert, That would be wonderful, thanks! :) - Bert -
|
On 13.04.2010, at 02:29, Bert Freudenberg wrote:
No need to anymore, did it myself. Vassili's changeset from 3.9 worked. - Bert - |
Free forum by Nabble | Edit this page |