[squeak-dev] Perl is to CPAN as Squeak is to (what)?

> On Mon, Jun 30, 2008 at 7:57 AM, Colin Putney <[hidden email]> wrote:
>
>> The other big problem is that tens of thousands of tiny files is a horribly
>> inefficient way to store source code. Yes, disk is cheap. But disk IO is
>> not. I discovered this early in the development of MC2, when I implemented a
>> type of repository that stored each method in a separate file. Loading
>> OmniBrowser from that repository involved opening, reading, and closing over
>> 600 files, and was very slow. I don't remember the exact timing, but I think
>> it was like 5 to 10 minutes, and in any case it was far too slow. Avi wrote
>> a repository that stored every thing in a single indexed file, and now load
>> time is dominated by compilation.
>
> It's worth pointing out that file-based version control has advanced
> significantly since we did this work - CVS and SVN are now far from
> the state of the art.  I haven't used git much, for example, but it
> seems to be a well layered system, and it may be that we can build an
> alternative front end to its database which is image-based rather than
> working directory based.  For example, imagine comparing an image
> directly to this index file rather than to a directory full of files
> on disk:
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index
>
> And look at this description of the workflow:
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflow
>
> I personally believe that we're better off with Smalltalk-specific
> version control, but if someone *is* looking at integration with more
> mainstream tools, I would strongly suggest they start with git rather
> than SVN.
>

>
> Pavel Krivanek
> http://www.comtalk.eu/Squeak/98
>
> On Sun, Jun 29, 2008 at 4:09 AM, Yoshiki Ohshima <[hidden email]> wrote:
>
> >  - Write a compiler in another language.  That can generates the bits
> >    that are same as CompiledMethods.  For a class definition, it
> >    creates (yes) the network of pointers.
> >
> >  - The compiler sticks the class definitions, method dictionaries,
> >    subclass structure, and compiled methods into a big "int*" array.
> >    The goal is to make that something just run, so for example, the
> >    stuff managed by ClassDescription (instanceVariable names and
> >    organization) don't have to be compiled.  Stuff like the source
> >    pointer is not needed at this stage.
>
> The compiler doesn't have to be in another language.  What is
> important is that the compiler builds a Squeak image from a text file.
>  The compiler can be written in Smalltalk as long as it uses only the
> class definitions in the test file, not in the compiler's image.

>
>
> Am 29.06.2008 um 20:08 schrieb Yoshiki Ohshima:
>
> > At Sun, 29 Jun 2008 18:48:01 +0200,
> > Bert Freudenberg wrote:
> >>
> >> Am 29.06.2008 um 16:51 schrieb Randal L. Schwartz:
> >>
> >>>>>>>> "Bert" == Bert Freudenberg <[hidden email]> writes:
> >>>
> >>> Bert> No it would not. The main issue for them is that you have to
> >>> start  from what
> >>> Bert> they perceive as "binary blob" which is monkey-patched into
> >>> newer versions.
> >>>
> >>> The C compiler would fit the same definition, by that reasoning.
> >>
> >>
> >> No. You need a C compiler, true, but it builds the next C compiler
> >> from text sources only, it does not clone itself.
> >
> >  Come to think of it, we don't have to write the bootstrapper in
> > another language.  They already accept Squeak VM, so we can write the
> > Smalltalk-to-CompiledMethod compiler in Slang (even better; write it
> > in OMeta and generate Slang), and generate a modified VM that has
> > different main().  That main() reads the "source" files, compile them
> > (by using the memory management in ObjectMemory), and write the result
> > to file.  (Yes, you need a C compiler^^;)
> >
> >  Isn't it sound a bit more doable?
>
>
> A bit. But I suspect getting classes and methods assembled into an  
> image is not even half the work. We'll have to create objects, too,  
> that were manually assembled (I'm thinking of the PaintBox prototype  
> for example). Recreating a full Etoys image would still be a major  
> effort, since many parts would have to be rewritten to actually be  
> bootstrappable.

>
> On 30-Jun-08, at 11:10 AM, Igor Stasenko wrote:
>
>> This is quite interesting.
>> Really, if we could just avoid using file-based working directory and
>> make image to be a kind of 'working directory' this would simplify
>> things  a lot - no need to make file outs and synchronization is
>> always made between current methods in image and git repository.
>> Interesting, how much coding needed to connect image with git
>> repository in that way.
>
> One option would be to use FUSE (or something similar) to make the
> image appear to be a filesystem. That wouldn't be git-specific, and
> would even appease all the folks that want to edit their code with emacs.
>
> Colin
>
>

> Colin Putney wrote:
>>
>> On 30-Jun-08, at 11:10 AM, Igor Stasenko wrote:
>>
>>> This is quite interesting.
>>> Really, if we could just avoid using file-based working directory and
>>> make image to be a kind of 'working directory' this would simplify
>>> things  a lot - no need to make file outs and synchronization is
>>> always made between current methods in image and git repository.
>>> Interesting, how much coding needed to connect image with git
>>> repository in that way.
>>
>> One option would be to use FUSE (or something similar) to make the image
>> appear to be a filesystem. That wouldn't be git-specific, and would even
>> appease all the folks that want to edit their code with emacs.
>>
>> Colin
>>
>>
> It has been done
>

>
>> Keith
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

>> SqueakFS exists, and is able to make an image available to the  
>> outside
>> (file system) world. We're in the process of setting up a development
>> repository (based on SVN, mind you). In the meantime, it's available
>> from www.squeaksource.com/SqueakFS.html in the current
>> version.
>>
>> Ah good. I must have run across it at some point and forgotten  
>> about it.
>
> There is also the FTP server that I wrote together with Ian at ESUG  
> 2005.

> Can you say something more about that? A couple of weeks ago I saw a  
> demo at HPI in Potsdam where students used SVN down to the method  
> level, and it seemed to me that this approach might very well work  
> because the SVN granularity is the same as the in-image granularity.  
> It may also be interesting that this wasn't even trying to deal with  
> source files of any sort - it retained the nature of the image and  
> simply hooked it up directly with SVN. From my perspective this  
> looked like an extraordinarily interesting approach that I am  
> certain to try out as soon as it is available.
>
> Cheers,
>  - Andreas
>