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

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

by 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] [Seaside] Re: [squeak-dev] Re: SqueakSource AND SmalltalkHub down ; )

by Tobias Pape

Am 2011-04-20 um 13:04 schrieb GermÃ¡n Arduino: > 2011/4/20 Tobias Pape <Das.Linux(a)gmx.de>: >> >> Am 2011-04-20 um 12:32 schrieb GermÃ¡n Arduino: >> >>> Hi Tobias: >>> >>> Sorry if I'm asking something already explained, but what are the new >>> features of Squeaksource3? >>> >>> I'm interested in try being that I was thinking in provide it with >>> some sort of data replication (only ideas >>> at the moment). >> >> >> I have not implemented replication yet, but it is >> high on my list. >> >> There are no _really_ distinct features >> but in contrast to the oriiginal SqueakSource and >> SqueakSource 2, >> â¢ runs on Seaside3.0 and Magritte 2 >> â¢ is highly aimed to run on GemStone >> â¢ includes a basic Issue tracking implemented by Dale Henrichs >> >> I integrated the features that were âlurking aroundâ , >> eg, in the source.squeak.org instance. So the recently added >> direct access to diffs between versions as either .diff or .cs >> is available in SqueakSource3, too. >> >> My highest aim was to improve extensibility, to allow drop-ins >> to extend squeaksource or to have a minimal one. >> For example, you can load the mare minimum of SqueakSource without >> even the ability to store versions to disk >> or have a full-featured SqueakSource that >> also includes Statistics, IssueTracking and (email) notification. >> >> I hope that helps imagine the SqueakSource3 :) >> >> So Long, >> -Tobias_______________________________________________ > > > Thanks for the comments TobÃas. I've a good idea now and definitely I > will give it a try. > > About the replication feature, do you have some ideas in mind? > > I was thinking in different possibilities: > > 1. Develop a feature in the same squeaksource that does this. > 2. Use some sort of replicated file system (as XtreemFS: > http://www.xtreemfs.org/) It will require to install it on XtreemOS > (http://www.xtreemos.eu/) > 3. Use some nosql horizontally scalable DB (as Riak / Cassandra) > 4. Use Magma/Gemstone Gemstone already is my main target. However, I think the synchronization of the Monticello versions stored is less a problem than synchronization of the user data. I think a a replicated file system won't help there. > > But, I repeat, just ideas until now. I was thinking in this feature to > my own use, because I need a reliable store of my source code on my > company. I think of a SqueakSource/GemStone appliance :) So Long, -Tobias

April 20, 2011

Re: [Pharo-project] SqueakSource 3

by Tobias Pape

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â¦ So Long, -Tobias

April 20, 2011

Re: [Pharo-project] SqueakSource 3

by 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? Dale

April 20, 2011

Re: [Pharo-project] SqueakSource 3

by Tobias Pape

Am 2011-04-20 um 15:49 schrieb Torsten Bergmann: >> How shall I specify 'I want a working Seaside of version X' >> in my metacello Config? > > Have a look at ConfigurationOfExternalWebbrowser in > squeaksource/MetacelloRepository for an example. > > This one requires the FFI project. > > You add the project in the baseline > > > spec > project: 'FFI' with: [ > spec > className: 'ConfigurationOfFFI'; > file: 'ConfigurationOfFFI'; > repository: 'http://www.squeaksource.com/MetacelloRepository']. > > and set the version in your version method: > > spec > project: 'FFI' with: '1.3'. There is not much difference to the spec I used but a) I put the version into the project spec in the basline b) I put the groups to load into the project spec, too. Shall I omit the groups spec? So Long, -Tobias

April 20, 2011

Re: [Pharo-project] SqueakSource 3

by Tobias Pape

Am 2011-04-20 um 15:44 schrieb GermÃ¡n Arduino: > 2011/4/20 Tobias Pape <Das.Linux(a)gmx.de>: >> >> Am 2011-04-20 um 14:19 schrieb Torsten Bergmann: >> >>> Hi Tobias, >>> >>> looks like it is basically working. I used a clean Pharo 1.2.1, then loaded Seaside >>> >>> Gofer new >>> squeaksource: 'MetacelloRepository'; >>> package: 'ConfigurationOfSeaside30'; >>> load. >>> >>> ((Smalltalk at: #ConfigurationOfSeaside30) project latestVersion) load. >>> >>> >>> then loaded you script: >>> >>> >>> Gofer new >>> squeaksource: 'MetacelloRepository'; >>> package: 'ConfigurationOfSqueakSource'; >>> load. >>> ((Smalltalk at: #ConfigurationOfSqueakSource) project version: #development) load. >>> >>> After that I started Seaside using the seaside control panel >>> and went to http://localhost:9094/installSS >>> >>> I got two errors, but after proceeding I was able to run >>> an instance of SS3. Cool. >> >> I would be certainly interested in the errors. > > In a Squeak 4.2 image with seaside preloaded, trying to install > SqueakSource3, the first error coming is: > MessageNotUnderstood: MethodContext>>tempScopedNames (seems to be in > WAPharoWalkback). Ah, that oneâ¦, -.-' One of the differences between Squeak and Pharo. The method is called tempNames in Squeak and was in earlier Pharos. Now the Pharo one changed and is used henceforth in WAPharoWalkback. That is a Seasdie problem, after all. Possible solutions: 1) hack the imaged and add MethodContext>>tempScopedNames to return self tempNames 2) persuade the Squeak community to rename tempNames to tempScopedNames (just kidding) 3) persuade the Pharo community to re-rename tempScopedNames to tempNames (well, just kidding, too) 4) persuade the Seaside-developers to a) Create a WASqueakWalkback that is like the WAPharoWalkback but uses the indicated message or b) make the tempScopedNames-message âgreasyâ, ie, marked as platform-dependent. BTW: when a Walkback is popping up, there must be a root cause, would you like to seek for that? So Long, -Tobias

April 20, 2011

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

by Marcus Denker

On Wed, Apr 20, 2011 at 1:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> 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. > It would be nice to have more people looking at reducing the number of bugs in the tracker. http://code.google.com/p/pharo/issues/list 435 to go... -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

April 20, 2011

Re: [Pharo-project] SqueakSource 3

by Tobias Pape

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

April 20, 2011

[Pharo-project] SqueakSource 3

by Torsten Bergmann

>How shall I specify 'I want a working Seaside of version X' >in my metacello Config? Have a look at ConfigurationOfExternalWebbrowser in squeaksource/MetacelloRepository for an example. This one requires the FFI project. You add the project in the baseline spec project: 'FFI' with: [ spec className: 'ConfigurationOfFFI'; file: 'ConfigurationOfFFI'; repository: 'http://www.squeaksource.com/MetacelloRepository']. and set the version in your version method: spec project: 'FFI' with: '1.3'. Bye T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

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 14:19 schrieb Torsten Bergmann: > >> Hi Tobias, >> >> looks like it is basically working. I used a clean Pharo 1.2.1, then loaded Seaside >> >> Gofer new >> Â Â Â Â Â Â Â squeaksource: 'MetacelloRepository'; >> Â Â Â Â Â Â Â package: 'ConfigurationOfSeaside30'; >> Â Â Â load. >> >> Â Â Â ((Smalltalk at: #ConfigurationOfSeaside30) project latestVersion) load. >> >> >> then loaded you script: >> >> >> Gofer new >> Â Â Â squeaksource: 'MetacelloRepository'; >> Â Â Â package: 'ConfigurationOfSqueakSource'; >> Â Â Â load. >> ((Smalltalk at: #ConfigurationOfSqueakSource) project version: #development) load. >> >> After that I started Seaside using the seaside control panel >> and went to http://localhost:9094/installSS >> >> I got two errors, but after proceeding I was able to run >> an instance of SS3. Cool. > > I would be certainly interested in the errors. In a Squeak 4.2 image with seaside preloaded, trying to install SqueakSource3, the first error coming is: MessageNotUnderstood: MethodContext>>tempScopedNames (seems to be in WAPharoWalkback).

April 20, 2011