July 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] About Morph cleaning and new infrastructure

by StÃ©phane Ducasse

We can't be all that wrong :) Stef >> Now we should learn from squeak and make sure that we have an >> infrastructure >> that allows one to plug difference UI frameworks (no "Smalltalk >> isMorphic" >> in the future). >> In addition we want to make sure: >> - that we can plug different UIFrameworks (Miro, Morphic30, >> YSqueak >> or something else) > > It seems to me this is part of what Newspeak is doing already.

July 3, 2008

Re: [Pharo-project] About Morph cleaning and new infrastructure

by Damien Cassou

On Thu, Jul 3, 2008 at 7:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Now we should learn from squeak and make sure that we have an infrastructure > that allows one to plug difference UI frameworks (no "Smalltalk isMorphic" > in the future). > In addition we want to make sure: > - that we can plug different UIFrameworks (Miro, Morphic30, YSqueak > or something else) It seems to me this is part of what Newspeak is doing already. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

July 3, 2008

[Pharo-project] Re: Pharo Smalltalk

by StÃ©phane Ducasse

>>> Couldn't you do this on Squeak? >> > > So, couldn't you continue on Squeak? Because - 1 we need freedom. We do not want to maintain: etoy, nebraska, alice and the like. We do not want to have other people putting stress and their dreams on us. We did that for 3.9 and people pissed on us (random refactorers...) complained that we pushed traits in Squeak..... read the archives of the mailing-list everything is there. - 2 people said that we did not have a process, that social engineering was the solution (which is true when you apply it). - 3 we proposed a 3.10 roadmap and people complained. - 4 we proposed our help to 3.10 but it was declined. - 6 after the sad adventure of 3.10 and the lack of reaction of people we decided that we did our best. in 3.9 we harvested 625 bugs fixed but apparently this was not valuable. We think that 3.9 was a positive experience even if marcus got sick and burnt out. - 7 The squeak model is flawed. We do not want a model were consumers can put exigences on producers. Even if good customers are important and this is why we want to have Aida/Seaside and a lot of cool projects to run on pharo. - 8 I'm sick of opening squeak and having to turn my eyes from problems. After a certain point we should learn and take decision even if they are not easy. > I can't understand why you forked the project instead of improving it. Because we do not want to have complain all the times. We want to be able to invent the future, rethink design decision, apply good practices but not maintain the cool but old features and experiments of others. Sorry but we did that and now this is over. We are also sorry but we do not believe in big bang changes and we waited too much after spoon. So may be we are wrong, probably but again we had to do something for ourselves. >> I do not know. >> FunSqueak ;D > > So you quit Squeak... Not really. We will work on a new Volume Two and we did not renamed yet our book Pharo by Example :) May be pharo will be a cool squeak distribution or something else. For now our focus is getting things done. > I still can't see a valid reason for this fork. There are plenty of them but may be you are not in the right places to understand them. Here is an extra one. I have no choice this is pharo or ruby and I'm not joking. I was terribly sad when I see people willing to go back to 3.8! We spent a lot of energy to make sure that the forks could reunite but now this is over. We tried to really make a better Squeak and got sick, burnt and more. So now if I do not want to destroy the little flame we have for Smalltalk we **must** do pharo, because this is like new dry wood that you put on the fire place. It brings exciting future. Stef

July 3, 2008

Re: [Pharo-project] About Morph cleaning and new infrastructure

by StÃ©phane Ducasse

Hi adrian > Hi Stef, > > This is exciting news. > > I think the VM sleeping feature is important because this is > something we do but by suspending/resuming the VM process from the > outside (else with hundreds of images the idle CPU usage kills > ressources). So this is something that also Seaside servers will > profit from. We know :) This is also why ESUG is supporting this work :) > Those changes will require work on the VM and in the image, I > suspect. Will this be shared with Squeak? Yes. This is the idea! We do not want to hear that ESUG is only taking care of Pharo. So some idiots say that in the future smashed them. I start to be fed up by idiots :). Then we will merge the fixes in Pharo. And people may want to do the same for they own fork. Stef

July 3, 2008

Re: [Pharo-project] About a file abstraction layer

by StÃ©phane Ducasse

I do not know. I have the impression this is at another level. What URI provides is a common abstraction for ftp, local files,.... But mike will comment on that (I'm ill at hilaire's place right now and they have a social event dinner :)). On Jul 3, 2008, at 8:37 PM, Damien Cassou wrote: > What about Rio? > > On Thu, Jul 3, 2008 at 8:00 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> With mike we also discussed about URI and the way sophie people >> used to >> abstract away >> from the file system. >> The idea (may be I'm summarizing a bit wrong), is to use URI >> consistently >> even to access local file. >> >> He told me that with this practice they got away from platform >> dependent >> code in Sophie. >> >> Mike also rewrote and clean a large part of the network-package. >> We got some trouble to load it in pharo since this was not made to >> be loaded >> in pharo. >> >> Mike will work on a loadable version. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 3, 2008

[Pharo-project] Re: Pharo Smalltalk

by StÃ©phane Ducasse

> Couldn't you do this on Squeak? but we are doing that starting with squeak 3.9 :) > How much Pharo will differ from Squeak? We do not know but it will. > Do you intend to rebase with a new VM or do you intend to just > improve Smalltalk code? For the moment we do not have the expertise to change the VM and we will reuse the one of Squeak. There will be also a MIT VM with a JIT so :) And also Squeak VM running on ipod :) > What about license issues? I've seen Pharo is MIT. Yes all the code of pharo will be MIT. We will only include MIT code and all the commiters have to sign the agreement. > I've seen many developers and a busy mailing list, I expect more improvements to come when the people interested by software development will join. For the moment we are in warm up mode. > what will be the future of Squeak? I do not know. FunSqueak ;D >> Well what I will have in mind depends on what you reply to the >> above questions :P > > Thanks for your reply.

July 3, 2008

Re: [Pharo-project] About Morph cleaning and new infrastructure

by Adrian Lienhard

Hi Stef, This is exciting news. I think the VM sleeping feature is important because this is something we do but by suspending/resuming the VM process from the outside (else with hundreds of images the idle CPU usage kills ressources). So this is something that also Seaside servers will profit from. Those changes will require work on the VM and in the image, I suspect. Will this be shared with Squeak? Cheers, Adrian On Jul 3, 2008, at 19:51 , StÃ©phane Ducasse wrote: > Hi guys > > Here is the summary of the discussion we got with mike today. > > In the context of the ESUG sponsored effort mike and john will work > on making the > - VM sleeping correctly, > - using a semaphore do avoid event polling and all the rest related > to that. > - fixing the event handling. > > Now the point is that mike will not change Morph, just clean what is > needed so that > the event system and the polling gets cleaned. The idea is that > Morph cannot be cleaned. > > In parallel mike has been working on ySqueak and in this context he > worked on > a new morphic model. > > Now we should learn from squeak and make sure that we have an > infrastructure > that allows one to plug difference UI frameworks (no "Smalltalk > isMorphic" in the future). > In addition we want to make sure: > - that we can plug different UIFrameworks (Miro, Morphic30, YSqueak > or something else) > - kernel class do not depend on UI. > > So mike based on his sophie experience designed a new event model > based on Announcement > which support well multiple input devices, different platform key, > different windowing bindings for > future native support. > > So the idea is the following: > - let make Morphic smaller and cleaner but acknowledge that Morphic > is not the long term future. > - mike will produce a new event model, that the other UI frameworks > could use and extend. He will ask fro feedback. > - Agree that we use announcement as an infrastructural foundation. > - make sure (with your help and feedback) that we can plug another > UI framework (in particular in the event loop handler > should support a registration mechanism. > - It would be nice to see how miro can use the new event model and > be plug in pharo > as well as the ySqueak new model. > > I would like to lower the frustration of people. The point is not to > chose a framework against another one > but to make sure that we can load and plug different frameworks. > > So please comment. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 3, 2008

Re: [Pharo-project] About a file abstraction layer

by Damien Cassou

What about Rio? On Thu, Jul 3, 2008 at 8:00 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > With mike we also discussed about URI and the way sophie people used to > abstract away > from the file system. > The idea (may be I'm summarizing a bit wrong), is to use URI consistently > even to access local file. > > He told me that with this practice they got away from platform dependent > code in Sophie. > > Mike also rewrote and clean a large part of the network-package. > We got some trouble to load it in pharo since this was not made to be loaded > in pharo. > > Mike will work on a loadable version. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

July 3, 2008

[Pharo-project] Re: Pharo Smalltalk

by StÃ©phane Ducasse

Hi bruno > I've head about your new project Pharo. Good :) > I'm the author of Smalltalk YX (Syx) http://syx.googlecode.com. I had a look a while back. > Another developer recently developed a VM inspired to Syx and now > we're going to merge the projects, since we have the same vision. Excellent! Join forces :) > This is the post in the mailing list: http://groups.google.com/group/syx-discuss/browse_thread/thread/55507afadab… > > I'd like to know the main purposes of your new implementation, Produce a good Smalltalk with nice, well documented and libraries so that people can develop cool projects and others can learn from the system. We want to remove cruft from the system. > are you interested in a possible collaboration? yes! Tell us what you have in mind. > I haven't seen any source code yet. I think our two projects have > many things in common. The code is available on the ugly pharo web page http://pharo.gforge.inria.fr/ Stef > > > Let me know please. > Best regards, > > - -- > http://syx.googlecode.com - Smalltalk YX > http://lethalman.blogspot.com - Thoughts about computer technologies > http://www.ammazzatecitutti.org - Ammazzateci tutti > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIbXq1w9Qj+8Kak3ERAmZBAJ4ng2GLUD+rVuuhu2kAFjeKozyW5QCeO+WG > /tnA/LYuTonX9bzJDZBu5bs= > =og7s > -----END PGP SIGNATURE-----

July 3, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

I was wondering what is the amount of work to add traits support. The problem is that I do not have a big picture about all the palyer: classDecorator, classEditor.... It does not look complex but I'm ill so comment and a class diagram would help. Stef Why there is no common superclass? Behavior subclass: #MetaclassEditor instanceVariableNames: 'editor superEditor instVarNames methods organization traitComposition' classVariableNames: '' poolDictionaries: '' category: 'SystemEditor-Editors' Object subclass: #ClassEditor instanceVariableNames: 'subject product system superEditor name type instVarNames classVarNames sharedPools methods category organization properties decorators' classVariableNames: 'ReservedNames' poolDictionaries: '' category: 'SystemEditor-Editors' initialize migrators := OrderedCollection new. super initialize would not hurt edPrepareMigration: txn for: aClassEditor txn addMigrator: (ObjectMigrator origin: self subject destination: (self buildFor: aClassEditor)). (additions isEmpty and: [removals isEmpty]) ifFalse: [aClassEditor organization]. tnx? and a comment? at: aSymbol ifAbsent: absentBlock (removals includes: aSymbol) ifTrue: [^ absentBlock value]. additions at: aSymbol ifPresent: [:editor | ^ editor]. self subject at: aSymbol ifPresent: [:aCompiledMethod | ^ self add: (MethodEditor source: (classEditor subject sourceCodeAt: aSymbol) classified: (classEditor organization subject categoryOfElement: aSymbol) stamp: aCompiledMethod timeStamp notifying: nil logging: true )]. ^ absentBlock value may be a better formatting would help setSubject: aClass system: aSystemEditor subject := aClass. system := aSystemEditor. subject ifNil: [superEditor := aSystemEditor at: #Object. name := #Annonymous. type := #normal. instVarNames := Array new. classVarNames := Array new. sharedPools := Array new. methods := MethodDictionaryEditor for: self. self class edInitializeForNewClass]. decorators := ClassDecorator decoratorsFor: self. I was wondering when a class would be nil. So the logic should be mentioned somewhere. subclass: aSymbol instanceVariableNames: instString classVariableNames: classString poolDictionaries: poolString category: categoryString ^ ((system at: aSymbol ifAbsent: [ ClassEditor on: nil for: system]) edName: aSymbol superclassEditor: self type: #normal instVarString: instString classVarString: classString poolImports: poolString category: categoryString) edRegisterEditor

July 3, 2008