- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Method expressed as symbol, used as argument

by Helene Bilbo

DougEdmunds wrote: > > It was pointed out that given an instance method > MyClass >> doSomething > that > MyClass do: [:each | each doSomething]. > can be expressed as > MyClass do: #doSomething. > > Can someone suggest something to read that explains the usage of # > here (#doSomething), the relation of methods to symbols, etc. > Message selectors (in your example âdoSomethingâ) are represented by Symbols. You might use it to parameterize the behavior of an object. For example you can pass a message selector to a PluggableButtonMorph to tell it, which message to perform, when the button is pressed. -- View this message in context: http://forum.world.st/Method-expressed-as-symbol-used-as-argument-tp3388864… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 19, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by StÃ©phane Ducasse

BTW lukas I'm not angry at you :). I will look at your point and see how we can fix them. I just need this behavior. I have been fixing SystemNavigation (which should be also rewritten or replace), next the compiler should be parametrized and also the test runner logic and probably MC and at the end we will have a system that can do what I need. Stef On Mar 18, 2011, at 10:09 PM, Lukas Renggli wrote: >>> The only refactoring that would make sense is to extract all >>> senders of 'Smalltalk globals' to a separate method so that subclasses >>> could override it. >> >> Why? >> Frankly you have so absolute statements. >> This is good to feel like idiots: "the only refactoring that makes sense" >> >> We are making ****ALL**** the tools environment aware: SystemNavigation, Compiler, >> TestRunner.... so why browserEnvironment would escape to the rule? >> We need that to be able to browse, compile other code than currently installed and >> we will do it. >> >> Why having a state is a problem? Sorry but we will use this version and we will probably introduce it in core. >> Because we want to have all the tool chain been able to work on a given environment. > > You clearly break the following methods and potentially all 55 > references to BrowserEnvironment: > > - BrowserEnvironment>>#copyEmpty > - BrowserEnvironment>>#& > - BrowserEnvironment>>#I > - BrowserEnvironment>>#not > - BrowserEnvironment>>#isSystem > - ClassEnvironment>>#classesDo: > - SelectorEnvironment>>#classesDo: > > Not sure how you are going to meaningfully fix these when > BrowserEnvironment can point to different environments? > > I can only repeat myself: BrowserEnvironment encapsulates the complete > system (world). All that you can potentially see within a given image > at a given time. If you have Pharo 1.2 and Pharo 1.3 in your image > then BrowserEnvironment would enumerate Object from Pharo 1.2 and > Object from Pharo 1.3. > >> Now if you do not like our changes we will fork. This is sad because we tried to make sure that >> RB could work on them but there is no problem we can fork also RB. Just let us know. > > I don't know why you get angry? I am just telling you how John Brant > and Don Roberts implemented the system. Just fundamentally changing > core classes of a framework without understanding the implications > doesn't help. If you don't believe me ask John or compare the code > with the one in VisualWorks where you could actually have different > system versions at the same time in the image. > > So again: If you want a view onto your namespace create a > BrowserEnvironmentWrapper subclass that holds a reference to your > namespace like PackageEnvironment with its package. That is how it is > ment to be done. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

March 19, 2011

Re: [Pharo-project] Refactoring Browser Enhancements

by StÃ©phane Ducasse

On Mar 18, 2011, at 10:09 PM, Lukas Renggli wrote: >>> The only refactoring that would make sense is to extract all >>> senders of 'Smalltalk globals' to a separate method so that subclasses >>> could override it. >> >> Why? >> Frankly you have so absolute statements. >> This is good to feel like idiots: "the only refactoring that makes sense" >> >> We are making ****ALL**** the tools environment aware: SystemNavigation, Compiler, >> TestRunner.... so why browserEnvironment would escape to the rule? >> We need that to be able to browse, compile other code than currently installed and >> we will do it. >> >> Why having a state is a problem? Sorry but we will use this version and we will probably introduce it in core. >> Because we want to have all the tool chain been able to work on a given environment. > > You clearly break the following methods and potentially all 55 > references to BrowserEnvironment: > > - BrowserEnvironment>>#copyEmpty > - BrowserEnvironment>>#& > - BrowserEnvironment>>#I > - BrowserEnvironment>>#not > - BrowserEnvironment>>#isSystem > - ClassEnvironment>>#classesDo: > - SelectorEnvironment>>#classesDo: We will fix them. We forgot to look at BrowserEnvironement references. > Not sure how you are going to meaningfully fix these when > BrowserEnvironment can point to different environments? > > I can only repeat myself: BrowserEnvironment encapsulates the complete > system (world). All that you can potentially see within a given image > at a given time. If you have Pharo 1.2 and Pharo 1.3 in your image > then BrowserEnvironment would enumerate Object from Pharo 1.2 and > Object from Pharo 1.3. No it should not. And how about browsing remote images? This is exactly the same that SystemNavigation. Now systemNavigation works on an systemDictionary instance and of course if you work on two different ones you get something silly but else you can pass an systemDictionary instance and contextualize your queries. >> Now if you do not like our changes we will fork. This is sad because we tried to make sure that >> RB could work on them but there is no problem we can fork also RB. Just let us know. > > I don't know why you get angry? I am just telling you how John Brant > and Don Roberts implemented the system. Because you do not realize that your mails are often aggressive. Probably you are right in 80% of the case but consider that your mails can be perceived as aggressive. Trust lukas this is the way they can be read. I know you so I often succeed to take them easy but pay attention. > Just fundamentally changing > core classes of a framework without understanding the implications > doesn't help. If you don't believe me ask John or compare the code > with the one in VisualWorks where you could actually have different > system versions at the same time in the image. > > So again: If you want a view onto your namespace create a > BrowserEnvironmentWrapper subclass that holds a reference to your > namespace like PackageEnvironment with its package. That is how it is > ment to be done. I know. I understand the design of this code. Now it does not work with the scenario I have. I want to have an environment parametrized IDE which can work on different versions of the same system (pharo for example). I want to browse a remote environment that is given to me via proxy. I want to have the possibility to browser Hazelkernel separatedly from the rest and all these classes should not be in the same system dictionary instances. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

March 19, 2011

Re: [Pharo-project] Method expressed as symbol, used as argument

by Benoit St-Jean

You probably talk about something like : Assuming an instance method called #doSomething the following are identical: myInstance doSomething myInstance perform: #doSomething ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: DougEdmunds <dougedmunds(a)gmail.com> To: pharo-project(a)lists.gforge.inria.fr Sent: Fri, March 18, 2011 9:40:43 PM Subject: [Pharo-project] Method expressed as symbol, used as argument It was pointed out that given an instance method MyClass >> doSomething that MyClass do: [:each | each doSomething]. can be expressed as MyClass do: #doSomething. Can someone suggest something to read that explains the usage of # here (#doSomething), the relation of methods to symbols, etc. Trying to wrap my head around it. Thanks. -dae -- View this message in context: http://forum.world.st/Method-expressed-as-symbol-used-as-argument-tp3388864… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 19, 2011

[Pharo-project] Method expressed as symbol, used as argument

by DougEdmunds

It was pointed out that given an instance method MyClass >> doSomething that MyClass do: [:each | each doSomething]. can be expressed as MyClass do: #doSomething. Can someone suggest something to read that explains the usage of # here (#doSomething), the relation of methods to symbols, etc. Trying to wrap my head around it. Thanks. -dae -- View this message in context: http://forum.world.st/Method-expressed-as-symbol-used-as-argument-tp3388864… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 19, 2011

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

by Alexandre Bergel

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