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

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

by Dale Henrichs

Casey and Miguel, I agree that there are alternative approaches to SCMs that could give us Smaltalkers what we already have in Monticello .... with the added benefit that we could play nicely with the traditional tools, but keep in mind that we are making the problem harder for ourselves:) It's like the ORM problem in reverse ... it's just as hard to map the "object graph editor" paradiigm used by Smalltalk onto the traditional file-based systems as it is to map arbitrary object graphs into an RDB ... there is an impedance mismatch. It is the impedance mismatch that has kept Smalltalkers from expending the extra effort to make tools that play well in an image-based environment WHILE playing well in the file-based world. It's just an added dimension of complexity ... not to mention the cost of converting existing development processes, tools, artifacts to the new system...it took Monticello nearly a decade to become commonly used:) I think that this is a problem that does need to be solved (along with others:) so I'm not claiming that "all is lost, we'll never be file-based" I just think it is a tough problem that would have been solved by now, if it was easy:) Until then, long live SqueakSource3 and SmalltalkHub:) Dale On Apr 20, 2011, at 11:02 AM, Casey Ransberger wrote: > I think MC is working out really well for Squeak: development has been unstuck ever since we started using the workflow from Pharo;) > > I really enjoyed reading the historical info in your post. I hope it's okay to throw out a couple of counter arguments, just for fun. > > In particular, files don't work for us because: > > - the change sets are ugly and no one would want to work with them directly unless they had to. > + solution: make the file out format human-friendly by getting the ordering, doits, and other metadata out to a metadata file. > > - the image has no way to detect that you've changed something in a file. > + solution: make the image check timestamps, or implement a push of some sort that notifies the image that you've changed a method or class def. If the image isn't running, it can just pick up the all of the changes and use timestamps to suss out the ordering. > > Most (all?) SCM tools can *easily* be queried to see which files have changed since the last commit. Post commit hooks can integrate the changes into a running image. > > I agree that the problems with living in file-land won't go away by themselves. What I worry about, though, is that we're creating the "Smalltalk doesn't play well with others" myth, which keeps lots of perfectly interesting people away from our community, by refusing to use anything that isn't written in Smalltalk. > > One thing I've thought of trying is actually mapping each method and class def to a hierarchical file structure that mirrors the system organization. This way, the image can just dump the source of all changed methods and defs to the disk and check the result into the SCM. This has the advantage of "everything in its place" that we like so much about the way the system keeps it's code in a database. > > It isn't an RDBMS: it's tree shaped, not table shaped. The metaphor really isn't that different from an hierarchical file system, if you really think about it. The only thing I see missing is a file out format that takes this stuff into account, and a way to detect changes. It seems like both of these things, while non-trivial, are sort of almost-trivial:) The hard part would be rejiggering all of the tools (as usual,) I think. > > It seems like the problem here is really analogous to the discussions that have happened around namespaces. The actual problems are a) some people don't want namespaces, and b) we can argue for days about what color the bike shed should be without ever arriving upon a shed that you can keep a bike in. > > There are already implementations of this stuff... Both namespaces and Git integration. There's a Git-like system that stores Smalltalk objects in files. There's another that actually integrates with Git. > > To be clear, I want to repeat that I agree: this stuff won't integrate itself! And MC is working well enough for now (even though most people sort of hate it, or at least the vocal ones.) > > On Apr 20, 2011, at 9:01 AM, 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

[Pharo-project] [update 1.3] #13166

by Marcus Denker

13166 ----- Issue 4063: SelectorExceptionSubclassResponsibilityPrimitiveFailedShouldBeImplementedShouldNotImplement Issue 2841: Heap equality should be transitive -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 20, 2011

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

by Alexandre Bergel

> > 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 Even if metacello solves a different problem than Monticello, metacelloBrowser should reach a stage where the ui is intuitive and cover the workflows that are commonly used. We are not there yet, but we are working on it. Alexandre > > 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 Eliot Miranda

On Wed, Apr 20, 2011 at 9:51 AM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > 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 ;). > You're joking right? Smalltalk is not a programming language, it is an object system, including a programming language, a library, tools etc. Please, let's not completely misunderstand what Smalltalk is in this community. > > > 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

[Pharo-project] [COTDC] 52 - PCXReadWriter

by laurent laffont

Today: PCXReadWriter Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

April 20, 2011

Re: [Pharo-project] [COTDC] 51 - TestCaseAnnouncement

by laurent laffont

On Tue, Apr 19, 2011 at 9:44 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 19 Apr 2011, at 22:38, Alexandre Bergel wrote: > > > I should be able to easily answer this one :) > > Your's is better, Alexandre! > I take Alex comments and thanks Sven. Laurent. > > Sven > > >

April 20, 2011

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

by Dale Henrichs

Camillo, I understand that folks don't understand why Smalltalkers "don't just start using files like everyone else". I have tried to explain ... it is not arrogance nor ignorance. The image is the difference ... The image makes it possible for developers to debug and explore the "live object model" in the image ... it is what makes me productive ... I don't care about the syntax either... As a Smalltalker I need to _make changes to the source code in a live image_ and when I make those changes I need to be able to manage the changes I make in some sort of source code management system... that's why change sets were invented and you can read the rest of the story below... Smalltalkers don't use the traditional tools, because the traditional tools aren't designed to work with Smalltalk images ... it's not arrogance ... the Smaltalk tools operate on the image not a set of files ... It's a different paradigm, so Smalltalkers aren't reinventing the wheel, they are building a wheel that rolls in the image... Dale On Apr 20, 2011, at 9:51 AM, Camillo Bruni wrote: > 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 Marcus Denker

On Apr 20, 2011, at 8:02 PM, Casey Ransberger wrote: > I think MC is working out really well for Squeak: development has been unstuck ever since we started using the workflow from Pharo;) > And when we started to do that in 3.9, we got critized to death... it's not the process that unstuck Squeak. The fact is: Squeak moves because Pharo marches in front. Pharo unstuck Squeak. I *tried* with all my energy to move Squeak and I could not. It was impossible. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 20, 2011

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

by Casey Ransberger

I think MC is working out really well for Squeak: development has been unstuck ever since we started using the workflow from Pharo;) I really enjoyed reading the historical info in your post. I hope it's okay to throw out a couple of counter arguments, just for fun. In particular, files don't work for us because: - the change sets are ugly and no one would want to work with them directly unless they had to. + solution: make the file out format human-friendly by getting the ordering, doits, and other metadata out to a metadata file. - the image has no way to detect that you've changed something in a file. + solution: make the image check timestamps, or implement a push of some sort that notifies the image that you've changed a method or class def. If the image isn't running, it can just pick up the all of the changes and use timestamps to suss out the ordering. Most (all?) SCM tools can *easily* be queried to see which files have changed since the last commit. Post commit hooks can integrate the changes into a running image. I agree that the problems with living in file-land won't go away by themselves. What I worry about, though, is that we're creating the "Smalltalk doesn't play well with others" myth, which keeps lots of perfectly interesting people away from our community, by refusing to use anything that isn't written in Smalltalk. One thing I've thought of trying is actually mapping each method and class def to a hierarchical file structure that mirrors the system organization. This way, the image can just dump the source of all changed methods and defs to the disk and check the result into the SCM. This has the advantage of "everything in its place" that we like so much about the way the system keeps it's code in a database. It isn't an RDBMS: it's tree shaped, not table shaped. The metaphor really isn't that different from an hierarchical file system, if you really think about it. The only thing I see missing is a file out format that takes this stuff into account, and a way to detect changes. It seems like both of these things, while non-trivial, are sort of almost-trivial:) The hard part would be rejiggering all of the tools (as usual,) I think. It seems like the problem here is really analogous to the discussions that have happened around namespaces. The actual problems are a) some people don't want namespaces, and b) we can argue for days about what color the bike shed should be without ever arriving upon a shed that you can keep a bike in. There are already implementations of this stuff... Both namespaces and Git integration. There's a Git-like system that stores Smalltalk objects in files. There's another that actually integrates with Git. To be clear, I want to repeat that I agree: this stuff won't integrate itself! And MC is working well enough for now (even though most people sort of hate it, or at least the vocal ones.) On Apr 20, 2011, at 9:01 AM, 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

Thanks by the comments Nico. 2011/4/20 Nicolas Petton <petton.nicolas(a)gmail.com>: > 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