On Thu, 18 Oct 2001, Torge Husfeldt wrote: > Hi Bert, Hi G.J., > > Thanks Bert, that you jumped in... > The "Fix" I posted was really only ment as a workaround and I should > have mentioned that it was likely to youse problems with existing code > in the image. > We need to remember that standard swikis are deployed without .changes > file and with the preference #warnIfNoChangesFile turned _off_ but the > CMs all still carry their source pointers with them. So if you try to > file out one of them it is quite natural that you stumble into problems.
Really? I had hoped Jochen would at least use the "abandonSources" procedure when deploying the swiki. That should get rid of source pointers and leave all in a usable way. (I usually skip the organisation zapping part, though: makes browsing much more fun). > As Bert mentioned this will only work for the code _newly_ added/changed > (by hand or by fileIn) _after_ the changes file was installed. If you > want to achieve overall better results with browsing/fileOut you should > really get the BigTime.changes that belongs to the BigTime.image > originally. There seems to be another way if you execute in your image > _before_ you create the .changes file: > Smalltalk lastQuitLogPosition > Then on creating the .changes file you pad it with the number obtained > of a appropriate character. What means appropriate in this circumstance > I don't know and I would have to poke into it a bit and would only do so > if somebody badly needed this functionality ($ $! or Charcacter value:0 > are my best guesses so far). Sounds pretty hackish to me ;-) > Regards, > Torge > > P.S.: Wouldn't it be nice if there was a way to tell squeak that it > keeps all new changes even if there is no changes file? Maybe even > source code pointer that could point to (more or less) arbitrary files - > for fileIns that is. I'd rather keep them in the image - otherwise you'll get a lot of dangling pointers to a lot of changesets. But it sounds like a good idea. -- Bert > Bert Freudenberg wrote: > > > > On Tue, 16 Oct 2001 [EMAIL PROTECTED] wrote: > > > > > OK I did make an empty file bigTime.changes > > > > If your image is named bigTime.image that is correct. > > > > > Then I did try to file out current change set > > > > Why? You should try to file in the fix again. That copies the source code > > >from the fix file into your changes file so when you browse that > > method again it will still have the formatting and comments. OTOH, nothing > > is wrong with looking at decompiled code as long as you just want to use > > that code. > > > > OTTH, if you really want to dig into the ComSwiki sources, you should > > order the *real* image/changes file from Jochen. Or is that already > > available for d/l somewhere? > > > > > I got an error window messages not undestood: runs > > > (it ends up after 20 walkbalk lines somewhere in the menuItemMorph with > > > BlockContext>ensure: > > > > That seems to be a bug with filing out decompiled code (which you should > > not do anyway, but which is still a bug). > > > > -- Bert >
