April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Seaside] Re: SqueakSource 3

by Dale Henrichs

On Apr 20, 2011, at 8:01 AM, Tobias Pape wrote: > > Am 2011-04-20 um 16:32 schrieb Dale Henrichs: > >> >> On Apr 20, 2011, at 6:27 AM, Tobias Pape wrote: >> >>> >>> To Dale or whoever is capable of this: >>> >>> How shall I specify 'I want a working Seaside of version X' >>> in my metacello Config? >>> >>> Aparently, doing >>> >>> spec >>> package: 'SqueakSource-Core' with: [ >>> spec requires: #( "â¦" 'Seaside Extras' "â¦" )]; >>> project: 'Seaside Extras' with: [ >>> spec >>> className: 'ConfigurationOfSeaside30'; >>> loads: #('Seaside-Email' 'RSS-Core'); >>> file: 'ConfigurationOfSeaside30'; >>> versionString: '3.0.4'; >>> repository: 'http://www.squeaksource.com/MetacelloRepository']; >>> >>> does not suffice. >> >> >> When you "does not suffice", what is it that is not sufficient and what is your goal? > > When I use the config as above, > And I just use the Config to Install SqueakSource into > a seaside-less image, I get a âstubâ seaside with no adaptors, > not ready to serverâ¦ Ah yes, you have to choose the adaptor you want to use ... I think I talk about this in my other email... Dale

April 20, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Miguel CobÃ¡

I want to comment. As already Camillo said, git has nothing intrinsic with files. It only stores bytestrings and the commit id is the sha1 of that bytestring. When comparing a version with other it just compares the content of the object (bytestring). This is marvelous explained here with ruby and the unix command line: http://progit.org/book/ch9-2.html So the ideal would be that the SCM of Smalltalk it just used blobs to store method source code (because as beatiful that the image is all objects and turtles all the way down, at the end of the day when we program and write classes and methos we are writing text, just text, that the image behind the scene transform in live objects). In an example: I modify my package that is stored in git somehow. I modify 3 class and 15 methods from those three classes so my package is dirty. Now I want to commit my changes, so my hypothetical git-enabled-SCM visit each modified class and stores the string representation of each method (and class) modified (or just parses the changes file and convert each chunk in a blog) in a git blob. See, it just takes each source code string I entered into the image and convert it to blob. Then creates a tree git object grouping all those commits and finally creates a commit git object with the metadata and the pointer to the ancestry as required. All of this is stored locally in my local git repository. Finally a push will well, push, the changes to github for all to use. When I want to update my image with the new version of Seaside for example (that supposedly is already on github) I just pull the objects that aren't in my local repository and then merge them with my local changes if any. Then my git-enabled-SCM will just load the git objects (commit, tree and blob) in the image and on the fly extract the bytstring and applies the changes to the image (merging as needed so that the image is the live object representation of the git objects that we are loading). Of course the devil is in the details but I can't see the impossibility (other than the man-hours, time and money resources required) of using git (and something like github) for Pharo and Squeak. Cheers El miÃ©, 20-04-2011 a las 09:01 -0700, Dale Henrichs escribiÃ³: > Smalltalk is not file-based. For better or for worse. > > The fundamental problem with Smalltalk is that it is image-based. > > Removing a method from a file is not sufficient to remove the method from the image. > > Change sets were invented to provide a file-based solution to the "how do I remove a method from the image" problem. > > A filein (the one used to initialize your image) plus a series of change sets applied in the right order is the file-based methodology for managing an image. > > Change sets are integral to Smalltalk. > > Name another language that uses change sets ... > > I cannot distribute a fresh set of source files to _upgrade_ an already installed application. I have to supply change sets and those change sets have to specific to the version that is installed in the image ... > > Remember the problem is "how do I remove a method from the image". > > The image is a data base, not an executable program, when you load code you also migrate/modify the objects in your "data base". > > Name another language that does this.... > > Monticello was invented along the way ... I cannot speak to the original motivation, but I can say that with Monticello I _can_ distribute a fresh set of source files to _upgrade_ an already installed application. > > Monticello does this by having a meta model that describes the complete application. The meta model is not a "source file" it is a serialized object graph. > > Monticello dynamically creates a change set by comparing the meta model of the loaded application with the meta model of the incoming "source code". > > Name another language that does this.... > > So the meat and potatoes of a Monticello mcz file is a binary chunk of data.... > > What does git do with binary data? What do humans do with binary data? > > You need a tool that takes the binary data and makes it readable for the poor developers who cannot unzip and deserialize a binary stream of bits on sight. > > Enter SqueakSource and SmalltalkHub.... > > This is where we are today. > > Can Smalltalk development be based on files....certainly everyone was doing file-based development in 1985, but the Smalltalk environments of the day migrated away from files ... > > In 1985 I was writing tools to store files and change sets in RCS ... the original ChangeSorter was based on my work back then... > > In 1993 I was working on tools that stored Smalltalk source meta data using PKZIP ... > > ENVY stores source meta data into a custom data base.... > > Store stores source meta data in an RDB... > > In 2011 I am working on tools that store Smalltalk source meta data using zip ... > > Smalltalk is image-base and the "standard" development tools just don't fit ... for better or for worse ... > > Sooooo, we can complain that we are not using git, but there are very good reasons for not using git ... today. > > Just because 20 years of evolution has moved Smalltalk away from using files in the traditional manner, doesn't mean that it won't evolve back to using files, but until the evolution happens, we need tools like SqueakSource3 and SmalltalkHub to support the _current_ model. > > Dale -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 20, 2011

Re: [Pharo-project] SqueakSource 3

by Dale Henrichs

On Apr 20, 2011, at 7:18 AM, Tobias Pape wrote: > > Am 2011-04-20 um 15:33 schrieb GermÃ¡n Arduino: > >> 2011/4/20 Tobias Pape <Das.Linux(a)gmx.de>: >>> >>> >>> oO the Seaside3-dependency should be there. >>> But it is a basic dependency not dictating any adaptor. >>> >>> To Dale or whoever is capable of this: >>> >>> How shall I specify 'I want a working Seaside of version X' >>> in my metacello Config? >>> >>> Aparently, doing >>> >>> spec >>> package: 'SqueakSource-Core' with: [ >>> spec requires: #( "â¦" 'Seaside Extras' "â¦" )]; >>> project: 'Seaside Extras' with: [ >>> spec >>> className: 'ConfigurationOfSeaside30'; >>> loads: #('Seaside-Email' 'RSS-Core'); >>> file: 'ConfigurationOfSeaside30'; >>> versionString: '3.0.4'; >>> repository: 'http://www.squeaksource.com/MetacelloRepository']; >>> >>> does not suffice. >>> >>> >> >> Yes, a dependency is missing. Why not load the complete Seaside? >> > > I don't understand. > > As an âapplication developerâ I cannot tell the one who will > install that what installtion configuration of seaside to use. > Eg, I cannot say 'use this adaptor' because I do not have > this dependency. > Is there a 'default group' for Seaside that brings me 'Seaside-Email', > but a runnable Seaside installation, too? To answer your second question first. The 'default' for Seaside is to load everything, so all of the pieces covered in tutorials, etc. will be present. If you want to customize the Seaside load, then you must pick and choose amongst the things that you need for your particular application and that depends upon what you are trying to do, like which adaptor do you want to use and whether or not you want the development environment loaded or not ... I'm not sure how to answer the first question ... as the developer of SqueakSource3 you can't know how the application will be deployed, so you can't know which adaptors are needed ...you don't even know whether SqueakSource3 will be deployed on Pharo or GemStone or which persistence model might be used like Magma or file-based or image-based... It would be nice if we had a "standard deployment model" where decisions like this could be specified, along with other deployment time artifacts/configurations like, the name of the site, png file to use for banner, etc. It seems that some code loading is involved in addition to executing custom doits... I think that the deployment issue encompasses more than just Seaside... If we had a standard way of specifying deployment artifacts, it would be much easier to imagine being able to deploy SqueakSource3 or SmalltalkHub into the cloud... Dale Dale

April 20, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Nicolas Petton

Le mercredi 20 avril 2011 Ã 13:47 -0300, GermÃ¡n Arduino a Ã©crit : > 2011/4/20 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > > Even if SmalltalkHub looks like GitHub, its still based on Monticello. > > Another aspect also important in github and similar tools is social coding. > > This is very easy to follow your favorite developpers and to > > participate by cloning his/her repository. > > > > Regards > > > > SmalltalkHub is Squeak, Pharo, GNU ST? It hosts MC repositories & projects. So not GNU Smalltalk for now :) > > It will be open source? Sure, it will be released under MIT. > > There are several persistence options? Currently it uses Sandstone, so a it's file based serialization. The demo uses Sandstone + GOODS. Cheers, Nico -- Nicolas Petton http://www.nicolas-petton.fr

April 20, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Miguel CobÃ¡

El miÃ©, 20-04-2011 a las 18:51 +0200, Camillo Bruni escribiÃ³: > Objection! ;) > > Using git has nothing to do with a file based system. The approach would be to use git as a storage backend for monticello. Git just stores 3 types of objects: commit, tree, blob. > There are no files involved!! So this would be perfectly compatible with and image based system such as smalltalk. > > see: http://book.git-scm.com/1_the_git_object_model.html > > > personal rant from here on >>> > > However I see that smalltalkers tend to ignore the fact that there are other tools not written in smalltalk which are widely used and they actually work! For instance monticello. Although the model works perfectly fine, the UI is just plain crap, it does not provide a nice workflow nor is it readable... Git on the other hand might be too complex, but it lets do more stuff on the command line, in an easier fashion than the mc tool. > > Smalltalkers tend to reinvent the wheel, which is sometimes nice, if its well designed and actually works, but many times its rather a waste of time, than just relying on existing working infrastructure that people outside smalltalk build. > > What I see in Pharo is a good move towards making these tools work again, most of them are just old and ignore common UI principles. > > > And Smalltalk is not the holy grail, its just yet another programming language, which has nice syntax ;). +10 > > > On 2011-04-20, at 18:10, Serge Stinckwich wrote: > > Even if SmalltalkHub looks like GitHub, its still based on Monticello. > > Another aspect also important in github and similar tools is social coding. > > This is very easy to follow your favorite developpers and to > > participate by cloning his/her repository. > > > > Regards > > > > On Wed, Apr 20, 2011 at 11:01 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > >> Smalltalk is not file-based. For better or for worse. > >> > >> The fundamental problem with Smalltalk is that it is image-based. > >> > >> Removing a method from a file is not sufficient to remove the method from the image. > >> > >> Change sets were invented to provide a file-based solution to the "how do I remove a method from the image" problem. > >> > >> A filein (the one used to initialize your image) plus a series of change sets applied in the right order is the file-based methodology for managing an image. > >> > >> Change sets are integral to Smalltalk. > >> > >> Name another language that uses change sets ... > >> > >> I cannot distribute a fresh set of source files to _upgrade_ an already installed application. I have to supply change sets and those change sets have to specific to the version that is installed in the image ... > >> > >> Remember the problem is "how do I remove a method from the image". > >> > >> The image is a data base, not an executable program, when you load code you also migrate/modify the objects in your "data base". > >> > >> Name another language that does this.... > >> > >> Monticello was invented along the way ... I cannot speak to the original motivation, but I can say that with Monticello I _can_ distribute a fresh set of source files to _upgrade_ an already installed application. > >> > >> Monticello does this by having a meta model that describes the complete application. The meta model is not a "source file" it is a serialized object graph. > >> > >> Monticello dynamically creates a change set by comparing the meta model of the loaded application with the meta model of the incoming "source code". > >> > >> Name another language that does this.... > >> > >> So the meat and potatoes of a Monticello mcz file is a binary chunk of data.... > >> > >> What does git do with binary data? What do humans do with binary data? > >> > >> You need a tool that takes the binary data and makes it readable for the poor developers who cannot unzip and deserialize a binary stream of bits on sight. > >> > >> Enter SqueakSource and SmalltalkHub.... > >> > >> This is where we are today. > >> > >> Can Smalltalk development be based on files....certainly everyone was doing file-based development in 1985, but the Smalltalk environments of the day migrated away from files ... > >> > >> In 1985 I was writing tools to store files and change sets in RCS ... the original ChangeSorter was based on my work back then... > >> > >> In 1993 I was working on tools that stored Smalltalk source meta data using PKZIP ... > >> > >> ENVY stores source meta data into a custom data base.... > >> > >> Store stores source meta data in an RDB... > >> > >> In 2011 I am working on tools that store Smalltalk source meta data using zip ... > >> > >> Smalltalk is image-base and the "standard" development tools just don't fit ... for better or for worse ... > >> > >> Sooooo, we can complain that we are not using git, but there are very good reasons for not using git ... today. > >> > >> Just because 20 years of evolution has moved Smalltalk away from using files in the traditional manner, doesn't mean that it won't evolve back to using files, but until the evolution happens, we need tools like SqueakSource3 and SmalltalkHub to support the _current_ model. > >> > >> Dale > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 20, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Camillo Bruni

Objection! ;) Using git has nothing to do with a file based system. The approach would be to use git as a storage backend for monticello. Git just stores 3 types of objects: commit, tree, blob. There are no files involved!! So this would be perfectly compatible with and image based system such as smalltalk. see: http://book.git-scm.com/1_the_git_object_model.html personal rant from here on >>> However I see that smalltalkers tend to ignore the fact that there are other tools not written in smalltalk which are widely used and they actually work! For instance monticello. Although the model works perfectly fine, the UI is just plain crap, it does not provide a nice workflow nor is it readable... Git on the other hand might be too complex, but it lets do more stuff on the command line, in an easier fashion than the mc tool. Smalltalkers tend to reinvent the wheel, which is sometimes nice, if its well designed and actually works, but many times its rather a waste of time, than just relying on existing working infrastructure that people outside smalltalk build. What I see in Pharo is a good move towards making these tools work again, most of them are just old and ignore common UI principles. And Smalltalk is not the holy grail, its just yet another programming language, which has nice syntax ;). On 2011-04-20, at 18:10, Serge Stinckwich wrote: > Even if SmalltalkHub looks like GitHub, its still based on Monticello. > Another aspect also important in github and similar tools is social coding. > This is very easy to follow your favorite developpers and to > participate by cloning his/her repository. > > Regards > > On Wed, Apr 20, 2011 at 11:01 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> Smalltalk is not file-based. For better or for worse. >> >> The fundamental problem with Smalltalk is that it is image-based. >> >> Removing a method from a file is not sufficient to remove the method from the image. >> >> Change sets were invented to provide a file-based solution to the "how do I remove a method from the image" problem. >> >> A filein (the one used to initialize your image) plus a series of change sets applied in the right order is the file-based methodology for managing an image. >> >> Change sets are integral to Smalltalk. >> >> Name another language that uses change sets ... >> >> I cannot distribute a fresh set of source files to _upgrade_ an already installed application. I have to supply change sets and those change sets have to specific to the version that is installed in the image ... >> >> Remember the problem is "how do I remove a method from the image". >> >> The image is a data base, not an executable program, when you load code you also migrate/modify the objects in your "data base". >> >> Name another language that does this.... >> >> Monticello was invented along the way ... I cannot speak to the original motivation, but I can say that with Monticello I _can_ distribute a fresh set of source files to _upgrade_ an already installed application. >> >> Monticello does this by having a meta model that describes the complete application. The meta model is not a "source file" it is a serialized object graph. >> >> Monticello dynamically creates a change set by comparing the meta model of the loaded application with the meta model of the incoming "source code". >> >> Name another language that does this.... >> >> So the meat and potatoes of a Monticello mcz file is a binary chunk of data.... >> >> What does git do with binary data? What do humans do with binary data? >> >> You need a tool that takes the binary data and makes it readable for the poor developers who cannot unzip and deserialize a binary stream of bits on sight. >> >> Enter SqueakSource and SmalltalkHub.... >> >> This is where we are today. >> >> Can Smalltalk development be based on files....certainly everyone was doing file-based development in 1985, but the Smalltalk environments of the day migrated away from files ... >> >> In 1985 I was writing tools to store files and change sets in RCS ... the original ChangeSorter was based on my work back then... >> >> In 1993 I was working on tools that stored Smalltalk source meta data using PKZIP ... >> >> ENVY stores source meta data into a custom data base.... >> >> Store stores source meta data in an RDB... >> >> In 2011 I am working on tools that store Smalltalk source meta data using zip ... >> >> Smalltalk is image-base and the "standard" development tools just don't fit ... for better or for worse ... >> >> Sooooo, we can complain that we are not using git, but there are very good reasons for not using git ... today. >> >> Just because 20 years of evolution has moved Smalltalk away from using files in the traditional manner, doesn't mean that it won't evolve back to using files, but until the evolution happens, we need tools like SqueakSource3 and SmalltalkHub to support the _current_ model. >> >> Dale

April 20, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by GermÃ¡n Arduino

2011/4/20 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > Even if SmalltalkHub looks like GitHub, its still based on Monticello. > Another aspect also important in github and similar tools is social coding. > This is very easy to follow your favorite developpers and to > participate by cloning his/her repository. > > Regards > SmalltalkHub is Squeak, Pharo, GNU ST? It will be open source? There are several persistence options? Thanks.

April 20, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by GermÃ¡n Arduino

2011/4/20 Dale Henrichs <dhenrich(a)vmware.com>: > Smalltalk is not file-based. For better or for worse. > > The fundamental problem with Smalltalk is that it is image-based. > > Removing a method from a file is not sufficient to remove the method from the image. > > Change sets were invented to provide a file-based solution to the "how do I remove a method from the image" problem. > > A filein (the one used to initialize your image) plus a series of change sets applied in the right order is the file-based methodology for managing an image. > > Change sets are integral to Smalltalk. > > Name another language that uses change sets ... > > I cannot distribute a fresh set of source files to _upgrade_ an already installed application. I have to supply change sets and those change sets have to specific to the version that is installed in the image ... > > Remember the problem is "how do I remove a method from the image". > > The image is a data base, not an executable program, when you load code you also migrate/modify the objects in your "data base". > > Name another language that does this.... > > Monticello was invented along the way ... I cannot speak to the original motivation, but I can say that with Monticello I _can_ distribute a fresh set of source files to _upgrade_ an already installed application. > > Monticello does this by having a meta model that describes the complete application. The meta model is not a "source file" it is a serialized object graph. > > Monticello dynamically creates a change set by comparing the meta model of the loaded application with the meta model of the incoming "source code". > > Name another language that does this.... > > So the meat and potatoes of a Monticello mcz file is a binary chunk of data.... > > What does git do with binary data? What do humans do with binary data? > > You need a tool that takes the binary data and makes it readable for the poor developers who cannot unzip and deserialize a binary stream of bits on sight. > > Enter SqueakSource and SmalltalkHub.... > > This is where we are today. > > Can Smalltalk development be based on files....certainly everyone was doing file-based development in 1985, but the Smalltalk environments of the day migrated away from files ... > > In 1985 I was writing tools to store files and change sets in RCS ... the original ChangeSorter was based on my work back then... > > In 1993 I was working on tools that stored Smalltalk source meta data using PKZIP ... > > ENVY stores source meta data into a custom data base.... > > Store stores source meta data in an RDB... > > In 2011 I am working on tools that store Smalltalk source meta data using zip ... > > Smalltalk is image-base and the "standard" development tools just don't fit ... for better or for worse ... > > Sooooo, we can complain that we are not using git, but there are very good reasons for not using git ... today. > > Just because 20 years of evolution has moved Smalltalk away from using files in the traditional manner, doesn't mean that it won't evolve back to using files, but until the evolution happens, we need tools like SqueakSource3 and SmalltalkHub to support the _current_ model. > > Dale > Very very interesting summary Dale, Thanks by share. Indeed a lot of things to consider and think about. May be as a Smalltalker (and not using nor knowing Git) I assumed some wrong things. GermÃ¡n.

April 20, 2011

Re: [Pharo-project] SqueakSource 3

by GermÃ¡n Arduino

2011/4/20 Tobias Pape <Das.Linux(a)gmx.de>: > > Am 2011-04-20 um 15:33 schrieb GermÃ¡n Arduino: > >> 2011/4/20 Tobias Pape <Das.Linux(a)gmx.de>: >>> >>> >>> oO the Seaside3-dependency should be there. >>> But it is a basic dependency not dictating any adaptor. >>> >>> To Dale or whoever is capable of this: >>> >>> Â Â Â Â How shall I specify 'I want a working Seaside of version X' >>> Â Â Â Â in my metacello Config? >>> >>> Â Â Â Â Aparently, doing >>> >>> Â Â Â Â spec >>> Â Â Â Â Â package: 'SqueakSource-Core' with: [ >>> Â Â Â Â Â Â spec requires: #( "â¦" 'Seaside Extras' "â¦" )]; >>> Â Â Â Â Â project: 'Seaside Extras' with: [ >>> Â Â Â Â Â Â spec >>> Â Â Â Â Â Â Â className: 'ConfigurationOfSeaside30'; >>> Â Â Â Â Â Â Â loads: #('Seaside-Email' 'RSS-Core'); >>> Â Â Â Â Â Â Â file: 'ConfigurationOfSeaside30'; >>> Â Â Â Â Â Â Â versionString: '3.0.4'; >>> Â Â Â Â Â Â Â repository: 'http://www.squeaksource.com/MetacelloRepository']; >>> >>> Â Â Â Â does not suffice. >>> >>> >> >> Yes, a dependency is missing. Why not load the complete Seaside? >> > > I don't understand. > > As an âapplication developerâ I cannot tell the one who will > install that what installtion configuration of seaside to use. > Eg, I cannot say 'use this adaptor' because I do not have > this dependency. > Â Is there a 'default group' for Seaside that brings me 'Seaside-Email', > but a runnable Seaside installation, too? > > So Long, > Â Â Â Â -Tobias > > > > Yes, I understand your point. Only commenting that to try it, I would install the complete Seaside to avoid the empty stub you commented in the latest mail.

April 20, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Serge Stinckwich

Even if SmalltalkHub looks like GitHub, its still based on Monticello. Another aspect also important in github and similar tools is social coding. This is very easy to follow your favorite developpers and to participate by cloning his/her repository. Regards On Wed, Apr 20, 2011 at 11:01 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Smalltalk is not file-based. For better or for worse. > > The fundamental problem with Smalltalk is that it is image-based. > > Removing a method from a file is not sufficient to remove the method from the image. > > Change sets were invented to provide a file-based solution to the "how do I remove a method from the image" problem. > > A filein (the one used to initialize your image) plus a series of change sets applied in the right order is the file-based methodology for managing an image. > > Change sets are integral to Smalltalk. > > Name another language that uses change sets ... > > I cannot distribute a fresh set of source files to _upgrade_ an already installed application. I have to supply change sets and those change sets have to specific to the version that is installed in the image ... > > Remember the problem is "how do I remove a method from the image". > > The image is a data base, not an executable program, when you load code you also migrate/modify the objects in your "data base". > > Name another language that does this.... > > Monticello was invented along the way ... I cannot speak to the original motivation, but I can say that with Monticello I _can_ distribute a fresh set of source files to _upgrade_ an already installed application. > > Monticello does this by having a meta model that describes the complete application. The meta model is not a "source file" it is a serialized object graph. > > Monticello dynamically creates a change set by comparing the meta model of the loaded application with the meta model of the incoming "source code". > > Name another language that does this.... > > So the meat and potatoes of a Monticello mcz file is a binary chunk of data.... > > What does git do with binary data? What do humans do with binary data? > > You need a tool that takes the binary data and makes it readable for the poor developers who cannot unzip and deserialize a binary stream of bits on sight. > > Enter SqueakSource and SmalltalkHub.... > > This is where we are today. > > Can Smalltalk development be based on files....certainly everyone was doing file-based development in 1985, but the Smalltalk environments of the day migrated away from files ... > > In 1985 I was writing tools to store files and change sets in RCS ... the original ChangeSorter was based on my work back then... > > In 1993 I was working on tools that stored Smalltalk source meta data using PKZIP ... > > ENVY stores source meta data into a custom data base.... > > Store stores source meta data in an RDB... > > In 2011 I am working on tools that store Smalltalk source meta data using zip ... > > Smalltalk is image-base and the "standard" development tools just don't fit ... for better or for worse ... > > Sooooo, we can complain that we are not using git, but there are very good reasons for not using git ... today. > > Just because 20 years of evolution has moved Smalltalk away from using files in the traditional manner, doesn't mean that it won't evolve back to using files, but until the evolution happens, we need tools like SqueakSource3 and SmalltalkHub to support the _current_ model. > > Dale > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 20, 2011