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

Re: [Pharo-project] SqueakSource AND SmalltalkHub down ;)

by Serge Stinckwich

Maybe, you should put a nice page when the server is down. On Wed, Apr 20, 2011 at 4:43 PM, Nicolas Petton <petton.nicolas(a)gmail.com> wrote: > Le mercredi 20 avril 2011 Ã 11:30 +0200, Torsten Bergmann a Ã©crit : >> >SqueakSource AND SmalltalkHub down >> >> Yes, it looks like SmalltalkHub replaces all features >> of squeaksource and mimicks also the down behavior ;) > Hehe :-) > I shutdown the demo of SmalltalkHub because of some issues we got, > especially a (stupid) security hole. > > I'll let you know when it will be back online. > > Cheers, > Nicolas > >> >> >Btw: anyone eager to try out >> >SqueakSource3 ? >> >It is available as and alpha Metacello Config. >> >> Does it work with Pharo 1.2 already? Could you post >> a script for people to load and try? >> >> Thx >> T. > > -- > Nicolas Petton > http://www.nicolas-petton.fr > > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

April 21, 2011

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

by Casey Ransberger

More recently, he said "Smalltalk: Welcome to the Balkans." On Apr 20, 2011, at 7:01 PM, Reg Krock <rkrock3(a)yahoo.ca> wrote: > I think it was Kent Beck who ended his email with: "Source code in files? How 1970ish" > > Reg > > On 2011-04-20, at 4:17 PM, Norbert Hartl wrote: > >> Amen! >> >> Norbert >> >> Am 20.04.2011 um 18:01 schrieb Dale Henrichs: >> >>> 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 21, 2011

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

by Reg Krock

I think it was Kent Beck who ended his email with: "Source code in files? How 1970ish" Reg On 2011-04-20, at 4:17 PM, Norbert Hartl wrote: > Amen! > > Norbert > > Am 20.04.2011 um 18:01 schrieb Dale Henrichs: > >> 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 21, 2011

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

by GermÃ¡n Arduino

2011/4/20 Janko MivÅ¡ek <janko.mivsek(a)eranova.si>: > Next thing, let we rather start integrating different Smalltalk code on > all our dialects first and using SmalltalkHub for socializing in > Smalltalk community as a whole. First, and before socializing with > others! Here SmalltalkHub again promise a lot and we can actually > achieve a goal of *one*, only one entry point to *all* Smalltalk code, > in *all* dialects! > This is an interesting point also. Would be nice to have some sort of common things between all the smalltalks.

April 20, 2011

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

by GermÃ¡n Arduino

I would had responded to Casey, Dale and more, but selected this mail to write my response! 2011/4/20 Scott Gibson <wsgibson(a)windstream.net>: > I have been using a DVCS since at least 2005 and live by it for Perl (as well as other things) development. Â It is frustrating for me to use anything else. Â Because I have to jump between tasks, and because I am so scatter brained, I need it in order to simply keep track of all my projects and the changes that I have made. Â A DVCS fits to my workflow no matter how I need to do my work. > > However, though I am very new to Smalltalk and while I am used to the tools that I have been using for years I still do not feel compelled to use a DVCS that I am so used to. Â Monticello could use some improvements perhaps, but I currently do not see a compelling reason to change it for something else. Â I appreciate what an object system has to offer instead of just flat files. Â Things are radically different for me now. Â Instead of dealing with a combination of a RDBMS, Perl applications, and shell scripts I have a complete system with more than just a language (thanks Eliot for the clarity). Â All the time I am used to using UNIX commands, SQL commands, editor features just to do my work. Â With Smalltalk I have all of that with a consistent language that reduces all of the ways I need to consider to slice and dice the things I am looking to accomplish. Â And all of this in just an image file! > A big big big agreement with you. And is of a great value that a new smalltalker (as you are telling about yourself) put the finger on this topic: the image! The image is the environment (the ecosystem as one of my teachers says) were the objects live. To me, a Smalltalk without image is not a Smalltalk and really never will like a no-image Smalltalk because is not Smalltalk, may be is other thing, but not Smalltalk. Then I'm totally against the flat-files if their use means loss the image. Smalltalk is about objects, and objects live in the image as the fishes live in the tank. No tank, no water, then only dead fishes, not alive fishes. To not mention the other relationships in a live ecosystem. GermÃ¡n.

April 20, 2011

Re: [Pharo-project] [Pharo-users] [COTDC] 52 - PCXReadWriter

by Guillermo Polito

I am an Image ReadWriter supposed to be in charge of PCX file encoding and decoding. Actually, as my instances does not implement understandsImageFormat, they use the default ^false implementation and I cannot be used. I don't have uses in the image also :). But in case I am fixed, the code to open a morph with a pcx image is: PCXReadWriter formFromFileNamed: 'anImage.pcx'. ;) Guille On Wed, Apr 20, 2011 at 3:17 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > 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] Smalltalk, git, files, the universe and everything...okay not everything:)

by Miguel CobÃ¡

El miÃ©, 20-04-2011 a las 18:17 -0400, Scott Gibson escribiÃ³: > I have been using a DVCS since at least 2005 and live by it for Perl (as well as other things) development. It is frustrating for me to use anything else. Because I have to jump between tasks, and because I am so scatter brained, I need it in order to simply keep track of all my projects and the changes that I have made. A DVCS fits to my workflow no matter how I need to do my work. > > However, though I am very new to Smalltalk and while I am used to the tools that I have been using for years I still do not feel compelled to use a DVCS that I am so used to. Monticello could use some improvements perhaps, but I currently do not see a compelling reason to change it for something else. I appreciate what an object system has to offer instead of just flat files. Things are radically different for me now. Instead of dealing with a combination of a RDBMS, Perl applications, and shell scripts I have a complete system with more than just a language (thanks Eliot for the clarity). All the time I am used to using UNIX commands, SQL commands, editor features just to do my work. With Smalltalk I have all of that with a consistent language that reduces all of the ways I need to consider to slice and dice the things I am looking to accomplish. And all of this in just an image file! > > I do still struggle hard with Smalltalk (it is so new and so radically different for me - yet the code is so much cleaner and easier when done right) but I still do not see a compelling reason to use Git for my development. > > I know this discussion tends to come up ever so often. What am I missing? Is it perhaps because I am coming from the outside in? If you use Git what benefit would you have by using binary files? Or if you were to use some sort of text file, what benefit would you have by removing them from the system in which they exist? A couple of things, - Squeak/Pharo already use files, that is a fact and is unavoidable (changes files, image files, sources files, etc) so the thing is not if using or not files. They are used and they have killed anyone by themselves. - The point is not use files to store the source code but integrate Squeak/Pharo with infrastructure that building on the capabilities given by git to the developers (mainly cheap and fast branching) added a social ingredient that is revolutioning the way that projects are being developed in the open source world. That is what github is doing. Has nothing to do with if git versioning files or blobs or objects. It is that enables people to show, publish, fork, contribute back and advertise its open source project in a way that is visible to a lot more people that ever before. Cheers -- 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 Miguel CobÃ¡

I don't think that the issue is the file-ness of the subject, but the easiness that other opensource projects enjoy in part because of their tool, even if they aren't as pure in their object-ness as the ones Smalltalk have. As someone said, the UI of Monticello is very, umm, unintiuitive, has bad support for branching, avoiding some effect that the git users (and in particular github has contributed to popularize) that nobody has to ask for permission for modifying some project and then contributing back the changes to the main project. This is notorious difficult with MC/Squeaksource combo when the repo is only read, when the maintainer has to do a not minor effort to track contributions and integrating them back. And of course, the visibility that those tools have is no even in the reach of squeaksource (with those ugly urls that include session data that from time to time appears in mails refering to projects in squeaksource). In that respect git/github no matter if file-based or not are the clear example to emule and even to use for smalltalk open source projects. Cheers El miÃ©, 20-04-2011 a las 18:00 -0300, GermÃ¡n Arduino escribiÃ³: > 2011/4/20 Dale Henrichs <dhenrich(a)vmware.com>: > > > > 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:) > > > > A thing I not understand is why we need to go "file-based" if we are > already object based (several steps ahead)? > > > > > Until then, long live SqueakSource3 and SmalltalkHub:) > > > > Sure! But, (I'm only asking) we couldn't using Git with objects? It's > only curiosity, not that I would like Git, eheh, I knew Github only > today! > > GermÃ¡n. > -- 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 Sven Van Caekenberghe

On 21 Apr 2011, at 00:09, Janko MivÅ¡ek wrote: > Here is the point - familiarity! And we don't need to adopt GitHub > completely for that, just visual familiarity of SmalltalkHub will help > us to come closer to GitHub communities, that's I'm pretty sure. > > So, let we stop thinking about "file-based" integration with GitHub, let > we talk about social aspects (as familiarity also is) and as Sebastian > is trying to tell us. As you seen on SmalltalkHub, we will actually got > quite some "social" infrastructure now, which is very similar to GitHub. > Nico as GNU Smalltalker is namely a daily user of GitHub (where Iliad > and Jtalk resides), so he has quite some experience of social aspects > there. > > Next thing, let we rather start integrating different Smalltalk code on > all our dialects first and using SmalltalkHub for socializing in > Smalltalk community as a whole. First, and before socializing with > others! Here SmalltalkHub again promise a lot and we can actually > achieve a goal of *one*, only one entry point to *all* Smalltalk code, > in *all* dialects! +1

April 20, 2011

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

by Scott Gibson

I have been using a DVCS since at least 2005 and live by it for Perl (as well as other things) development. It is frustrating for me to use anything else. Because I have to jump between tasks, and because I am so scatter brained, I need it in order to simply keep track of all my projects and the changes that I have made. A DVCS fits to my workflow no matter how I need to do my work. However, though I am very new to Smalltalk and while I am used to the tools that I have been using for years I still do not feel compelled to use a DVCS that I am so used to. Monticello could use some improvements perhaps, but I currently do not see a compelling reason to change it for something else. I appreciate what an object system has to offer instead of just flat files. Things are radically different for me now. Instead of dealing with a combination of a RDBMS, Perl applications, and shell scripts I have a complete system with more than just a language (thanks Eliot for the clarity). All the time I am used to using UNIX commands, SQL commands, editor features just to do my work. With Smalltalk I have all of that with a consistent language that reduces all of the ways I need to consider to slice and dice the things I am looking to accomplish. And all of this in just an image file! I do still struggle hard with Smalltalk (it is so new and so radically different for me - yet the code is so much cleaner and easier when done right) but I still do not see a compelling reason to use Git for my development. I know this discussion tends to come up ever so often. What am I missing? Is it perhaps because I am coming from the outside in? If you use Git what benefit would you have by using binary files? Or if you were to use some sort of text file, what benefit would you have by removing them from the system in which they exist? Thanks! Scott Gibson On Apr 20, 2011, at 5:26 PM, Dale Henrichs wrote: > > On Apr 20, 2011, at 2:00 PM, GermÃ¡n Arduino wrote: > >> 2011/4/20 Dale Henrichs <dhenrich(a)vmware.com>: >>> >>> 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:) >>> >> >> A thing I not understand is why we need to go "file-based" if we are >> already object based (several steps ahead)? > > The folks that would like to see Smalltalk be more file-based have very good points ... Smalltalk would be more accessible to other developers, it would be easier for folks to learn Smalltalk if they didn't have to learn new tools along with a new language, etc.... > > So it would be really nice if we could keep our object orientation while providing a development environment that was familiar to developers from other languages .... > > we'd have our cake and eat it too:) > >> >> >> >>> Until then, long live SqueakSource3 and SmalltalkHub:) >>> >> >> Sure! But, (I'm only asking) we couldn't using Git with objects? It's >> only curiosity, not that I would like Git, eheh, I knew Github only >> today! > > At the moment I don't think that a transition to to Git would be transparent ... If it were that easy, I would think that it would be done by now:). > > I'd love to be wrong:) > > Dale -- Scott Gibson wsgibson(a)windstream.net

April 20, 2011