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

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

by Janko MivÅ¡ek

On 20. 04. 2011 23:26, Dale Henrichs wrote: >> 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 .... 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! Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

April 20, 2011

Re: [Pharo-project] input for pending items to integrate

by StÃ©phane Ducasse

Ok I got the message :) Stef > Hi Stef, > > RPackage and Announcements would be on the top of my preferences :) > > Cheers, > Doru > > On 20 Apr 2011, at 13:01, StÃ©phane Ducasse wrote: > >> Hi guys >> >> Take three minutes and reply to this mail. I would like to get a list of pending fixes I should focus on to help you. >> Because I can take the tagged items but this is a bit like ok that one >> but I want to make sure that I'm spending time to making you making progress. >> So just tell me. >> >> I will try to integrate some fixes regularly now. >> My own list is >> Transcript :) >> Zinc >> and fixxxxing RPackage :( >> Stef > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > >

April 20, 2011

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

by Dale Henrichs

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

April 20, 2011

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

by Casey Ransberger

Inline and abridged. On Apr 20, 2011, at 2:00 PM, GermÃ¡n Arduino <garduino(a)gmail.com> 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:) > > A thing I not understand is why we need to go "file-based" if we are > already object based (several steps ahead)? There are a number of reasons. One is better interop with existing tools: many professionals will be parted from their tools only in death, and this is a barrier to using Smalltalk at work outside of niches where it was adopted early on. I would like a job with my Smalltalk, please and thank you:) > 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! Well, we could do that. Git can version blobs. It just can't diff or merge them. And if you would also (as many professionals do) like to keep using your preferred text editor, you're out of luck. The Git (read: Linux kernel) model depends on merging code from the wild successively up through more and more trusted repositories until it makes it to Linus and the kernel. You can't do that unless you can merge changes from downstream seamlessly. So ultimately we would need a textual representation for code that plays better with the merge logic in popular SCM tools (e.g. the ordering in changesets is semantic, which doesn't work well when you merge, so load order and doits would have to be captured as metadata or specified explicitly in a manifest.) Does this help to describe the landscape a bit? > GermÃ¡n. >

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>: > > 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.

April 20, 2011

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

by GermÃ¡n Arduino

2011/4/20 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > 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. > I full agree, as like to say a well know Smalltalker here, Smalltalk is an objects environment who has a language (between other things).

April 20, 2011

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

by Norbert Hartl

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 20, 2011

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

by Marcus Denker

On Apr 20, 2011, at 9:04 PM, Casey Ransberger wrote: > > What happened with me was I saw Andreas look at what you guys had done with Pharo in terms of tools and process and propose we do it too. I thought it was a good idea. My ideal world, frankly, is somewhere between Cuis and Pharo, but with better multimedia support. In particular I like the smallness of Cuis, as well as the unparalleled Morphic performance. > > It's my dream that someday soon, when we understand the image a little better, (really excited about the efforts from the Pharo community in this regard!) we will be able to arrive on a kernel even smaller than Cuis that everyone can agree upon, and then different sets of goals could become more like "distributions" than like "forks." So Core 1.3, after "cleanUpForProduction" and then one additional step of opening the changesorter, closing it and saving (need to check what tha problem is) is now 6.4 MB 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

Below. On Apr 20, 2011, at 11:09 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 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. Understood and agreed. Pharo was an uprising against the disorganized sloth and conflicting goals in the Squeak community. I jumped all over the Pharo image when I fist discovered it. What happened with me was I saw Andreas look at what you guys had done with Pharo in terms of tools and process and propose we do it too. I thought it was a good idea. My ideal world, frankly, is somewhere between Cuis and Pharo, but with better multimedia support. In particular I like the smallness of Cuis, as well as the unparalleled Morphic performance. It's my dream that someday soon, when we understand the image a little better, (really excited about the efforts from the Pharo community in this regard!) we will be able to arrive on a kernel even smaller than Cuis that everyone can agree upon, and then different sets of goals could become more like "distributions" than like "forks." I'm strongly averse to buying into one community and rejecting the other. At the end of the day, we're all Smalltalkers and we're all using the same VM. That said, most of my time has gone into Squeak, because some of the stuff I use was unceremoniously ripped out of Pharo (and for understandable reasons, I'm not complaining.) I love Pharo: you gentlemen led the charge. I think it's fantastic that you wouldn't settle for less than awesome, and you pretty much lit a fire up under our asses! We needed it. That's my two cents, to beat a long-dead horse:) Hey, BTW, I asked Stephane about who from the Pharo community might want to speak, either in person or remotely, at the Seattle Smalltalk Users Group, which I started last week, and he suggested you. I use a lot of Squeak and Cuis, but mostly have only used Pharo for Seaside; that said I *really* want to present a fair and balanced view of the world. I have at least one member now who prefers Pharo that I know of. What do you think? Interesting projects you'd like to talk about? Thanks very much for your thoughtful reply, and thanks so much for leading the charge. I was new to Smalltalk when you guys started it up, and I might not have stuck around if you hadn't. 'Till all are one! > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

April 20, 2011

[Pharo-project] [update 1.3] #13167

by Marcus Denker

13167 ----- Issue 4019: It should be possible to call CodeLoader>>initialize multiple times Issue 4033: clean up startup/shutdownlist adding, add before -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 20, 2011