- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Beeper

by StÃ©phane Ducasse

> Hi Stef, > > firstly I do not understand why we have SoundService at all when we > have AbstractSoundSystem. Yes me too :) > And why it is a AppRegistry. AppRegistry > associates some application, tool. It is very confusing to use it for > a sound provider. Then I do not understand why it is named > AbstractSoundSystem and not simply SoundSystem (remember > AbstractString). Yes let us clean all that :) Can you take the lead on that? We could include the sound package in the release. > > On Sat, Nov 17, 2012 at 9:33 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi pavel >> >> In fact the registration default sound system is broken and we should fix it. >> I forgot what is the problem :) >> >>> Hi, >>> >>> I would like to discuss the Beeper class a little bit. The main >>> purpose of this class is to provide Beeper beep message and use >>> SoundService with respect to current sound enabled settings or VM >>> implemented primitive for beeping. >> >> Yes this was the idea and to remove it from smalltalk. >> >>> I think that we should: >>> - move the beep function to UIManager >>> - change all calls of Beeper beep to UIManager default beep >>> - in MorphicUIManager use classic Beeper implementation >>> - move Beeper to System-Sound package >>> - in default UIManager implementation use VM beep primitive >> >> Imagine an headless system without even ui (we did that in the microscopic kernel) and the only interaction >> we got at the beginning was to do beep. After we could write a file something. >> So moving beep to UI anything worries me. > > On my system the beep primitive does nothing so I use quitPrimitive > for that ;-) > >> >>> There are two main reasons for that. You surely do not want to listen >>> beeping server with Pharo images running remote UIs and I want to make >>> Pharo Kernel independent on SoundService. >> >> I see when we load the sound package beep is not using beep primitive but the associated sound. >> May be Beep should have a kind of call back system >> by default invoke its own primitive >> and when sound system is loaded it should invoke sound system via the call back >> I thought is was like that because I do not want to link sound to kernel that for sure. >> >>> What do you think? >> >> May be we should simply fix the behavior when adding sound service. >> >> Stef >>> >>> -- Pavel >>> >> >> >

Nov. 18, 2012

Re: [Pharo-project] about sharing class binding and others

by Igor Stasenko

On 17 November 2012 09:12, Camillo Bruni <camillobruni(a)gmail.com> wrote: > This is what Pinocchio had, resolving classes was done by looking them up > in the current environment (so basically the Class name is just a code > macro). This way we could add simple class scopes without too much effort. > > I guess that would make the following code example a bit more complicated: > > > oldDictClass := Dictionary. > Dictionary := SmallDictionary. > > dict := Dictionary new. > > Dictionary := oldDictClass > > self assert: (dict isKindOf: SmallDictionary). > why complicated? and you need is to translate <global> to: self class environmentAt: #<global> and <global> := value to self class environmentAt: #<global> put: value. this is very simple to do. > > but this is a rather bad feature in my eyes ;) > globals is not good, i agree.. but if you think about them as 'anything which you need to access outside direct method scope', then you need it and it is not bad idea at all. To me, there's no much difference between global vars or class/pool vars. The main dividing line , imo is the method scope: if variable are not defined in scope of method itself (temps, arguments etc) then it should be delegated to class in order to resolve it (yes, including ivars). The class then can figure, if such name is 'visible' in its scope, as well as provide a ways to access it, by instructing encoder to inject appropriate AST nodes, i.e. 'macro-expanding accessors' to these variables. This could lead to some limitations, of course, because of late-bound semantics, you won't be able to decompile the method's bytecode and show the source code which accessing variable 'Foo', because it will decompile to message send(s). But that is IMO not a big deal. And to mitigate the overhead of late-binding, we can use literals (Foo->value) as cache: class can decide that in order to access value of variable named 'Foo', a compiler should produce following: (<Foo binding literal>) ifNil: [ <Foo binding literal> := self class environmentAt: #Foo ] like that, once cache filled, the overhead can be reduced to simple nil check. Similar approach is to just put a special 'binding' object into method's literal, and then simply send #value, or #value: message to it for accessing its value. The semantics of getting/setting the value then can be encapsulated inside of behavior of this 'binding' object(s). And this even friendlier to decompiler: you can simply check if given literal is special kind of 'binding object', and then decompile it appropriately, as well as you don't need to instruct compiler to encode complex ASTs for accessing the literal value. > On 2012-11-17, at 07:24, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > >> I love Marcus idea, classes aren't globals any more, and to access them is >> simply another message send to a receiver: the environment. ( like the >> lobby in Self ) . >> >> Fernando >> >> >> On Sat, Nov 17, 2012 at 8:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr >>> wrote: >> >>>> The alternative to the current scheme would be to not hard-code the >>> class at all in the method at compile time. >>>> >>>> Instead of looking up the class and compiling the shared literal >>> association, we could compile a message send >>>> to the current environment. >>>> >>>> self class environment at: #NameOfClass >>>> >>>> And it should be noted that this could be evaluated at Jit-compile >>> time... the same is true for ivar offsets. There >>>> is no reason why these should be visible at the image level. The image >>> could talk about names and let the runtime >>>> translator infrastucture do the lookups needed for making a static >>> version that is fast. >>> >>> Yes I would like to measure that too. >>> My benchmarks were to measure the worse case where we have to manually >>> update the methods each time the class is modified. >>> >>> >>> > > -- Best regards, Igor Stasenko.

Nov. 18, 2012

Re: [Pharo-project] Beeper

by Pavel Krivanek

Hi Stef, firstly I do not understand why we have SoundService at all when we have AbstractSoundSystem. And why it is a AppRegistry. AppRegistry associates some application, tool. It is very confusing to use it for a sound provider. Then I do not understand why it is named AbstractSoundSystem and not simply SoundSystem (remember AbstractString). On Sat, Nov 17, 2012 at 9:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi pavel > > In fact the registration default sound system is broken and we should fix it. > I forgot what is the problem :) > >> Hi, >> >> I would like to discuss the Beeper class a little bit. The main >> purpose of this class is to provide Beeper beep message and use >> SoundService with respect to current sound enabled settings or VM >> implemented primitive for beeping. > > Yes this was the idea and to remove it from smalltalk. > >> I think that we should: >> - move the beep function to UIManager >> - change all calls of Beeper beep to UIManager default beep >> - in MorphicUIManager use classic Beeper implementation >> - move Beeper to System-Sound package >> - in default UIManager implementation use VM beep primitive > > Imagine an headless system without even ui (we did that in the microscopic kernel) and the only interaction > we got at the beginning was to do beep. After we could write a file something. > So moving beep to UI anything worries me. On my system the beep primitive does nothing so I use quitPrimitive for that ;-) > >> There are two main reasons for that. You surely do not want to listen >> beeping server with Pharo images running remote UIs and I want to make >> Pharo Kernel independent on SoundService. > > I see when we load the sound package beep is not using beep primitive but the associated sound. > May be Beep should have a kind of call back system > by default invoke its own primitive > and when sound system is loaded it should invoke sound system via the call back > I thought is was like that because I do not want to link sound to kernel that for sure. > >> What do you think? > > May be we should simply fix the behavior when adding sound service. > > Stef >> >> -- Pavel >> > >

Nov. 17, 2012

Re: [Pharo-project] [update 2.0] #20405

by Pavel Krivanek

Thank you, Marcus, we reduced Undeclared in Pharo Kernel to: WorldState - UIManager->#request:regex: World - DisplayScreen->#fullscreen: - ExternalDropHandler class->#defaultImageHandler - ExternalDropHandler class->#registerStandardExternalDropHandlers MIMEType - FileSystemStore->#mimeTypesAt: SoundService - Beeper->#play - Beeper class->#beepPrimitive ZnMimeType - SmalltalkImage->#sourcesDownloadClient PragmaCollector - SystemAnnouncer class->#restoreAllNotifications ImageReadWriter - Form class->#fromBinaryStream: StrikeFont - TextStyle class->#initDefaultFontsAndStyle TestCase - ClassDescription->#correspondingForTest ZnClient - ByteTextConverter class->#parseUnicodeOrgSpec: - CombinedChar class->#loadCompositionMapping - SmalltalkImage->#sourcesDownloadClient -- Pavel On Sat, Nov 17, 2012 at 9:36 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20405 > ----- > > Issue 6978: UpdateStreamer and UpdateStreamerTest should be in own packages > http://code.google.com/p/pharo/issues/detail?id=6978 > > Issue 6977: Move LoadUpdatesCommandLineHandler close to UpdateStreamer > http://code.google.com/p/pharo/issues/detail?id=6977 > > Issue 6967: move TestRunnerCommandLineHandler into HudsonBuildTools20 > http://code.google.com/p/pharo/issues/detail?id=6967 > > Issue 6993: update Pharo Kernel generation > http://code.google.com/p/pharo/issues/detail?id=6993 > > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.481.diff > http://ss3.gemstone.com/ss/Pharo20/UpdateStreamer-Core-MarcusDenker.2.diff > http://ss3.gemstone.com/ss/Pharo20/UpdateStreamer-Tests-MarcusDenker.2.diff > http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.737.diff > http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.61.diff > http://ss3.gemstone.com/ss/Pharo20/System-Changes-MarcusDenker.191.diff > http://ss3.gemstone.com/ss/Pharo20/HudsonBuildTools20-MarcusDenker.9.diff > > -- > Marcus Denker -- http://marcusdenker.de > >

Nov. 17, 2012

[Pharo-project] [update 2.0] #20405

by Marcus Denker

20405 ----- Issue 6978: UpdateStreamer and UpdateStreamerTest should be in own packages http://code.google.com/p/pharo/issues/detail?id=6978 Issue 6977: Move LoadUpdatesCommandLineHandler close to UpdateStreamer http://code.google.com/p/pharo/issues/detail?id=6977 Issue 6967: move TestRunnerCommandLineHandler into HudsonBuildTools20 http://code.google.com/p/pharo/issues/detail?id=6967 Issue 6993: update Pharo Kernel generation http://code.google.com/p/pharo/issues/detail?id=6993 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tests-MarcusDenker.481.diff http://ss3.gemstone.com/ss/Pharo20/UpdateStreamer-Core-MarcusDenker.2.diff http://ss3.gemstone.com/ss/Pharo20/UpdateStreamer-Tests-MarcusDenker.2.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.737.diff http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.61.diff http://ss3.gemstone.com/ss/Pharo20/System-Changes-MarcusDenker.191.diff http://ss3.gemstone.com/ss/Pharo20/HudsonBuildTools20-MarcusDenker.9.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 17, 2012

Re: [Pharo-project] Beeper

by StÃ©phane Ducasse

Hi pavel In fact the registration default sound system is broken and we should fix it. I forgot what is the problem :) > Hi, > > I would like to discuss the Beeper class a little bit. The main > purpose of this class is to provide Beeper beep message and use > SoundService with respect to current sound enabled settings or VM > implemented primitive for beeping. Yes this was the idea and to remove it from smalltalk. > I think that we should: > - move the beep function to UIManager > - change all calls of Beeper beep to UIManager default beep > - in MorphicUIManager use classic Beeper implementation > - move Beeper to System-Sound package > - in default UIManager implementation use VM beep primitive Imagine an headless system without even ui (we did that in the microscopic kernel) and the only interaction we got at the beginning was to do beep. After we could write a file something. So moving beep to UI anything worries me. > There are two main reasons for that. You surely do not want to listen > beeping server with Pharo images running remote UIs and I want to make > Pharo Kernel independent on SoundService. I see when we load the sound package beep is not using beep primitive but the associated sound. May be Beep should have a kind of call back system by default invoke its own primitive and when sound system is loaded it should invoke sound system via the call back I thought is was like that because I do not want to link sound to kernel that for sure. > What do you think? May be we should simply fix the behavior when adding sound service. Stef > > -- Pavel >

Nov. 17, 2012

Re: [Pharo-project] [update 2.0] #20404

by Pavel Krivanek

On Sat, Nov 17, 2012 at 9:12 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20404 > ----- > > Issue 6994: move DisplayScreen >> #defaultCanvasClass to Morphic > http://code.google.com/p/pharo/issues/detail?id=6994 > > Issue 6993: update Pharo Kernel generation > http://code.google.com/p/pharo/issues/detail?id=6993 Marcus, I did a small additional fix. Please integrate new slice too. -- Pavel > > Issue 6991: Move #cleanUpForProduction to its own class > http://code.google.com/p/pharo/issues/detail?id=6991 > > > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.980.diff > http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.735.diff > http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1284.diff > http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.88.diff > > -- > Marcus Denker -- http://marcusdenker.de > >

Nov. 17, 2012

[Pharo-project] Beeper

by Pavel Krivanek

Hi, I would like to discuss the Beeper class a little bit. The main purpose of this class is to provide Beeper beep message and use SoundService with respect to current sound enabled settings or VM implemented primitive for beeping. I think that we should: - move the beep function to UIManager - change all calls of Beeper beep to UIManager default beep - in MorphicUIManager use classic Beeper implementation - move Beeper to System-Sound package - in default UIManager implementation use VM beep primitive There are two main reasons for that. You surely do not want to listen beeping server with Pharo images running remote UIs and I want to make Pharo Kernel independent on SoundService. What do you think? -- Pavel

Nov. 17, 2012

[Pharo-project] [update 2.0] #20404

by Marcus Denker

20404 ----- Issue 6994: move DisplayScreen >> #defaultCanvasClass to Morphic http://code.google.com/p/pharo/issues/detail?id=6994 Issue 6993: update Pharo Kernel generation http://code.google.com/p/pharo/issues/detail?id=6993 Issue 6991: Move #cleanUpForProduction to its own class http://code.google.com/p/pharo/issues/detail?id=6991 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.980.diff http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.735.diff http://ss3.gemstone.com/ss/Pharo20/Morphic-MarcusDenker.1284.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.88.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 17, 2012

Re: [Pharo-project] Undoing 403 was Re: [update 2.0] #20403

by StÃ©phane Ducasse

Thanks I'm resting after yet another little crisis. Anyway it was fun to go to bern and hack during the moose dojo. I have built a nice little tool. I'm nearly there. This tool will definitively helps the Moosers and synectiquers to freeze their configuration. Stef >> This seems to break something... >> >> I will redo it witout the #cleanUpForRelease >> >> (and another example that shows that everything not tested is broken) >> > > Ok, undo done. > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

Nov. 17, 2012