New source code subsystem

Pavel Krivanek squeak1 at continentalbrno.cz
Thu Jul 27 11:15:11 UTC 2006


I have to draw the attention to the next one perspective. If we want
to have future versions of Squeak based on some small UI-less minimal
image, we will have got quite small sources file, big changes and we
will lose history information (we will have versions of individual
packages).
The question is if we want to have compression in the kernel image (to
support the compressed sources).

-- Pavel

On 7/27/06, Marcus Denker <denker at iam.unibe.ch> wrote:
>
> On 27.07.2006, at 09:39, Klaus D. Witzel wrote:
>
> > Nicolas
> >
> > thank you for taking the time for a response.
> >
> > On Wed, 26 Jul 2006 20:55:44 +0200, you wrote:
> >
> >> Klaus, i would say this is another source version control system.
> >
> > I did not have version *control* in mind but yes, scs could be used
> > for such ancient concepts (used them for > 30 years, quite an
> > experience).
> >
> > No, I was lead by the aim for more collaborative features (hmm,
> > since there are none in Squeak, should I say for *at least* one or
> > two collaborative features).
> >
>
> What I would suggest: Do not plan to save the world, at least not at
> first. If you now set out to build "the solution" we won't have for a
> looong
> time, most likely never.
>
> What we need first is
>
>   - source offset in a property, not at the end of the bytecode. Use
> an Integer , so we get indefinite size of .source and .changens --
>     One Problem Solved.
> - Fix dan's source compression. This can work on the .changes, too,
> giving smaller releases or full development deployment
>    for embedded systems (dan it for the weather station) or web servers.
>
> With that, we have solved those problems that started the
> discussion... quite a step in the right direction.
>
> After that, I personally would continue by cleaning up the sources/
> changes handling and fileOut mechanism, thus then enabeling
> experiments to make something really better. But this "real better"
> thing is the last step, not the first.
>
> 1) fix the real problem
> 2) clean up / refactor / generalise
> 3) now invent the future...
>
>      Marcus
>
>
>
>
>
>



More information about the Squeak-dev mailing list