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

Re: [Pharo-project] [call for help] Bugtracker

by Marcus Denker

On Mar 18, 2011, at 11:21 PM, Mariano Martinez Peck wrote: > > > Marcus, once I wrote this: http://www.pharo-project.org/community/issue-tracking > > but it seems people go directly to google code :( > It's not a problem to go directly and add a report... but it would be nice if people would care more about the bug issues they reported. If it's important enough to report, then it should be important enough to check the status once in a while... or just decided that indeed, it was not important. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 19, 2011

[Pharo-project] Equality and hash made easy

by Noury Bouraqadi

Hi, I proposed in early february an enhancement to avoid having redefine hash and = together and I would like to see it integrated in 1.3. My idea is that the implicit link between these two methods should be supported by the system. A first solution is proposed on the issue tracker http://code.google.com/p/pharo/issues/detail?id=3657 To make instances of some class comparable, simply make the class use the TEquality trait. TEquality relies on message valuesToCompareForEquality sent to objects for both = and hash. The default implmentation of this message is provided by Object. Override ONLY valuesToCompareForEquality method for custom equality check. Noury http://car.mines-douai.fr/noury -- -6th National Conference on âControl Architecture of Robotsâ 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France

March 19, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by StÃ©phane Ducasse

Hi benjamin I published a new package (to revert the dependencies) in DirtyExperiments and a fixed the points raised by lukas. I added also some comments. I should fix testEnvironmentWrapper | printString wrapper | printString := BrowserEnvironment new referencesTo: #printString. wrapper := BrowserEnvironmentWrapper onEnvironment: printString. self assert: wrapper numberSelectors = printString numberSelectors. self assert: wrapper numberClasses = printString numberClasses. self assert: wrapper environment == printString Stef On Mar 18, 2011, at 6:39 PM, Benjamin wrote: > Hi lukas > > with Stef we refactored the Browser environment: > - now it can be parametrized by a system dictionary > - we also move selectionIn* to the AST-Core so that Environment can be loaded independently. > > Could you integrate the packages in rb? > There are > AST-Core > Refactoring-Critics > Refactoring-Environment > Refactoring-Test-Envrionment > > In DirtyExperiments on SqueakSource > > > Ben > > PS: All the test are green ;) > > > > >

March 19, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

So I will check to see what can be done but it looks painful. Stef >> Is this a conscious decision to have an unique package per each >> category name, or just a technical limitation? > > RPAckage has nothing to do with category matching: a package is a list of classes and methods. > > Now the problem is simply the following: > > you have a MC package FOO > it contains FOO-Cat1 > > you load it: ok the loader could create > RPAckage Foo > and put FOO classes and Foo-Cat Classes in it > > Now you create a new category > FOO-z what should I do > add it to FOO > create a package Foo-z > > We would like to get rid of the naming convention and matching on categories now we could have tags > but tags should orthogonal to packages. > > >> I'd prefer to have a package which can allow an arbitrary category >> names in future. It may be that tools like browser are not prepared >> for that.. >> but not an internal information of package. To my thinking , classes >> which belong to package could have any category names.. >> Names should not mean anything.. it is just for humans. >> >>> >>> Now my time is short so I will >>> - probably not implement tags >>> - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange >>> code. >>> - check the MC dependency on method category conventions, because some logic is not defined in the right place >>> like overrides in the MC tools and not in the PackageInfo >>> - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to >>> associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames >>> and change the packages accordingly). >>> - we should not rely on most-specific-category kind of pattern matching. >>> >> >> As i suggested, we should not rely on category naming in new packages at all. >> I think we could create an importer which using a legacy logic of >> making classes belong to some package based on their category name. > > Yes but this is a pain. :) > > >> In future that should be removed. >> >>> So if you have suggestion please talk now. >>> >>> >>> Stef >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > >

March 19, 2011

Re: [Pharo-project] Run a Pharo world on WebBrowser.

by Marcus Denker

On Mar 18, 2011, at 11:38 PM, nullPointer wrote: > I thinking do an application for run in desktop, browser and mobile devices. > I want know if is REALLY possible run Pharo in a web browser, like a > flash/java applet/silverlight application, without problems. Somebody has > proved that? How is difficult for the user install the mechanism in browser > for run the Pharo image? In the past, the way etoys was used was that you install the VM with a standard image as a plugin for the browser. Then .pr (Projects) where loaded just like much more interactive web pages. There where multiple problems with that a) It's a lot of work to keep the vm plugin working for real. A lot of time was invested from the side of the etoy team on that. b) Even though it's just "please install the plugin", people just don't do it. (partly because they are not allowed to, e.g. in a school setting) c) Projects... are problematic. Far too low level. Changes on the image lead to big problems if you want to be able to load old projects (as they are just a dumb of parts of the image... this will be especially fun as soon as you start to change real things in the system.) No idea what the latest state is.. but projects like Scratch decided it's easier to do a java (or flash?) based player app for the Scratch projects instead. There are two interesting developments: -> JavaScript. Millions are invested in JS VM technology. So one can start to do real smalltaks in JS. (Personally, I think having your own real VM, not one implemented ontop of another VM is preferable, though. Especially if you plan to do real strange things in the futuer as opposed to just wanting a smalltalk system in the browser.) -> Google Native Client. That one is very impressive. But it's unclear what googles plans are. We now they have no fear of promoting something and yet then kill it after people start to use it for real... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 19, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

> > Is this a conscious decision to have an unique package per each > category name, or just a technical limitation? RPAckage has nothing to do with category matching: a package is a list of classes and methods. Now the problem is simply the following: you have a MC package FOO it contains FOO-Cat1 you load it: ok the loader could create RPAckage Foo and put FOO classes and Foo-Cat Classes in it Now you create a new category FOO-z what should I do add it to FOO create a package Foo-z We would like to get rid of the naming convention and matching on categories now we could have tags but tags should orthogonal to packages. > I'd prefer to have a package which can allow an arbitrary category > names in future. It may be that tools like browser are not prepared > for that.. > but not an internal information of package. To my thinking , classes > which belong to package could have any category names.. > Names should not mean anything.. it is just for humans. > >> >> Now my time is short so I will >> - probably not implement tags >> - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange >> code. >> - check the MC dependency on method category conventions, because some logic is not defined in the right place >> like overrides in the MC tools and not in the PackageInfo >> - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to >> associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames >> and change the packages accordingly). >> - we should not rely on most-specific-category kind of pattern matching. >> > > As i suggested, we should not rely on category naming in new packages at all. > I think we could create an importer which using a legacy logic of > making classes belong to some package based on their category name. Yes but this is a pain. :) > In future that should be removed. > >> So if you have suggestion please talk now. >> >> >> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

March 19, 2011

Re: [Pharo-project] need your attention: Package

by Marcus Denker

On Mar 19, 2011, at 1:45 AM, Igor Stasenko wrote: >> > > Is this a conscious decision to have an unique package per each > category name, or just a technical limitation? > > I'd prefer to have a package which can allow an arbitrary category > names in future. I would say that In the future, the idea is to not have categories at all. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 19, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

On Mar 19, 2011, at 2:31 AM, Alexandre Bergel wrote: > I understand that the best way to prepare an application for RPackage is to make sure we have turned each category as a package. Is there something else? Class extension maybe a problem you said. Not really. I'm looking now at package creation because may be I could create a package Foo (if MC says if even if category are Foo-bla) now the problem is that if somebody creates a package Foo-z then I would like to avoid to have to check all the packages names and do string matching on their category. Stef > Alexandre > > > Le 18 mars 2011 Ã 16:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > >> Hi guys >> >> we need to think about package: >> >> right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). >> We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement >> instead. >> RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. >> >> Now one of the problem I see is that we may not have a smooth transition because: >> - Rpackage does not rely on category tagging matching. >> - It is simpler to have a mapping from current categories to packages >> - Now it means that we could load a package in the system and it would be turned into several RPackages >> so this means that configuration would have to be adapted. >> >> - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. >> and to have tags to only represent categories. >> >> Now my time is short so I will >> - probably not implement tags >> - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange >> code. >> - check the MC dependency on method category conventions, because some logic is not defined in the right place >> like overrides in the MC tools and not in the PackageInfo >> - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to >> associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames >> and change the packages accordingly). >> - we should not rely on most-specific-category kind of pattern matching. >> >> So if you have suggestion please talk now. >> >> >> Stef >

March 19, 2011

Re: [Pharo-project] Run a Pharo world on WebBrowser.

by StÃ©phane Ducasse

NullPointer, in the past squeak could run in webbrowser there were plugin (VM working as a flash plugin that add to be installed in a webbrowser client), the problem is that is was a hell to make work (not because of squeak vm but because of the specific windows and other OSes idiosyncrasies. So it was not maintained. May be squeak still supports that. I do not know. Now it does not mean that we could not have that but time and people are not infinite in this world. Now we are not microsoft and unfortunately cannot spend hundreds of engineers on one point (else we would have it). So concretely if you want to do that look at seaside. Now I do not believe that the exact same widgets and application can run on desktop and mobile just because of screen space. Stef On Mar 18, 2011, at 11:59 PM, Sean P. DeNigris wrote: > I would look at Lively Kernel, and maybe email Dan Ingalls. I think he said > that he was toying with a Lively Kernel using Smalltalk instead of JS and > may even have some code. At the least, it is a great example/proof that you > can have a Morphic world in a browser. > > HTH, > Sean > > -- > View this message in context: http://forum.world.st/Run-a-Pharo-world-on-WebBrowser-tp3388632p3388666.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

March 19, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by StÃ©phane Ducasse

Let us be more productive :) A BrowserEnvironment has an environment input= a systemDictionary (may be we should call it origin) a selectedEnviroment = a composite based on the BrowserEnvironment hierarchy The precondition is that it does not make sense to mix apple and orange so selectedEnvironment inside a composite to be meaningfull should sahre the same origin. Now it does not mean that we cannot have different composite over the same origin (ie we have multiple queries over Smalltalk globals) or that we cannot have different and separate composite working on different origin (ie I have a selection on Pharo1.2 and one on Pharo1.3 or a remote one). On Mar 18, 2011, at 10:09 PM, Lukas Renggli wrote: > - BrowserEnvironment>>#copyEmpty copyEmpty ^ self class new on: SystemDictionary new; yourself. > - BrowserEnvironment>>#& & anEnvironment "If we or anEnvironment includes everything, then just include the other environment (optimization)" self isSystem ifTrue: [^anEnvironment]. anEnvironment isSystem ifTrue: [^self]. ^AndEnvironment onEnvironment: self and: anEnvironment does not change > - BrowserEnvironment>>#I | anEnvironment "If we or anEnvironment includes everything, then return it instead of creating an or that will include everything." self isSystem ifTrue: [^self]. anEnvironment isSystem ifTrue: [^anEnvironment]. ^ OrEnvironment onEnvironment: self or: anEnvironment > - BrowserEnvironment>>#not not self isSystem ifTrue: [^SelectorEnvironment new]. ^NotEnvironment onEnvironment: self > - BrowserEnvironment>>#isSystem isSystem ^true No problem (this could be renamed isOriginalInput but we keep it for compatibiity > - ClassEnvironment>>#classesDo: classesDo: aBlock classes do: [ :each | | class | class := Smalltalk globals at: each ifAbsent: [ nil ]. (class notNil and: [ environment includesClass: class ]) ifTrue: [ aBlock value: class ] ]. metaClasses do: [ :each | | class | class := Smalltalk globals at: each ifAbsent: [ nil ]. (class notNil and: [ environment includesClass: class class ]) ifTrue: [ aBlock value: class class ] ] We already fixed it. classesDo: aBlock classes do: [ :each | | class | class := self environment at: each ifAbsent: [ nil ]. (class notNil and: [ selectedEnvironment includesClass: class ]) ifTrue: [ aBlock value: class ] ]. metaClasses do: [ :each | | class | class := self environment at: each ifAbsent: [ nil ]. (class notNil and: [ selectedEnvironment includesClass: class class ]) ifTrue: [ aBlock value: class class ] ] > - SelectorEnvironment>>#classesDo: classesDo: aBlock classSelectors keysDo: [ :each | | class | class := Smalltalk globals at: each ifAbsent: [ nil ]. (class notNil and: [ environment includesClass: class ]) ifTrue: [ aBlock value: class ] ]. metaClassSelectors keysDo: [ :each | | class | class := Smalltalk globals at: each ifAbsent: [ nil ]. (class notNil and: [ environment includesClass: class class ]) ifTrue: [ aBlock value: class class ] ] again we already fixed it. classesDo: aBlock classes do: [ :each | | class | class := self environment at: each ifAbsent: [ nil ]. (class notNil and: [ selectedEnvironment includesClass: class ]) ifTrue: [ aBlock value: class ] ]. metaClasses do: [ :each | | class | class := self environment at: each ifAbsent: [ nil ]. (class notNil and: [ selectedEnvironment includesClass: class class ]) ifTrue: [ aBlock value: class class ] ] So does it make sense? I think so. We just have a common input for a given composite. Stef

March 19, 2011