June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Question about API / Backend

by Matthieu Lacaton

I think the example of Henrik works fine if the user knows precisely what he wants to do. If I understand what Ben said, the following should also be possible : Create x subclasses of OSWindow (x being the number of backends available). For example : OSWindow subclass: OSWindowSDL OSWindow subclass: OSWindowXDL Now, at the initialization of OSWindow the corresponding subclass is stored into the currentBackend instance variable (a bit like in a strategy pattern). So either currentBackend := OSWindowSDL new or currentBackend := OSWindowXDL new. If the method called is backend-specific the implementation could be done like that : OSWindow >> #bordered: aBoolean ^ currentBackend bordered: aBoolean for: self OSWindowSDL >> #bordered: aBoolean for: target <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCall: #( int SDL_SetWindowBordered ( SDL_Window *target , SDL_bool aBoolean ) ) OSWindowXDL >> #bordered: aBoolean for: target ^ self error: 'Warning, the current backend does not provide support for #bordered, you should use another one'. And maybe provide a list of available backends providing this option. And the user just needs to call OSWindow bordered: false. The drawback here is that there is no real distinction between common and specific backend for the user. He only knows when it bugs. The advantage is that the user can use specific functions without even knowing it :D 2015-06-16 14:30 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On Tue, Jun 16, 2015 at 6:15 PM, Henrik Johansen > <henrik.s.johansen(a)veloxit.no> wrote: > > > > On 16 Jun 2015, at 9:58 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> > > wrote: > > > > Hello everybody, > > > > The question I have concerns OSWindow and its backend : SDL. However, > even > > if I'll speak about these two, i think the question is quite general and > can > > apply to every API. > > > > There are some functions that we are sure we will find in every backend > > possible (for instance the possibility to create a new window, to resize > it > > etc.) and for these ones it is totally fine to abstract the backend from > the > > user because you know that even if the backend has to change the API > will be > > usable the same way. > > > > But there are some functions that are quite specific to a certain backend > > and you cannot always find it in others. But this function is cool so it > > would be a shame not to implement it just for the sake of uniformity. > > In this case I see two options : > > > > 1) You abstract these functions exactly the same way you did for the > others > > and the user is not informed at all. In this case the risk is that if the > > backend changes it may break the API for the user because he won't be > able > > to use this function anymore.And he may feel a bit sad because he was not > > warned about it. > > > > 2) You make something to let the user know that this or that function is > > specific to this or that backend. By doing so the user knows that there > is a > > small risk that he won't be able to use this function anymore if the > backend > > changes. He has been warned. > > > > Now I prefer the second option but I wanted to ask you about that > > "something". What is the best way to warn the user ? > > > > - Should I let the name of the backend in the name of the method ? > > "SDL_MySpecificMethod" > > - Should I put all these methods in a specific package and name / comment > > that package accordingly ? > > - Some other things ? > > > > Basically my question is : what is the best way to let the user know he > is > > dealing with a specific function for a specific backend ? > > > > Thanks, > > > > Matthieu > > > > > > A recent idea I had, translated to your case, was doing this by providing > > accessors to specific backend extension classes. > > Personally, I'd prefer to use a class separate from that which implements > > the common interface, so one doesn't accidentally end up doing common > calls > > on only specific backends, here's a purely theoretical example of how > that > > may look: > > > > window := OSWindow new. > > window title: 'Test window'. > > "With SDL, we support making window unbordered" > > window SDL bordered: false. > > window openInWorld. > > But what would this code look like when later a second backend XDL > does implement #bordered: ? > > > With a few example implementations: > > OSWindow >> #SDL > > "Could cache in instvar, but that would not as modular, as you can't > > package that with the rest of the backend, with methods all you need > > is *SDL-Windows categorization" > > currentBackEnd isSDL > > ifTrue: [SDL_ExtWindow target: self] > > ifFalse: [NoopWindow target: self] > > I don't see /currentBackEnd/ is current OSWindow. I presume you are adding > it. > What class would you store in /currentBackEnd/ ? > > I guess some would have a philosophical object to "isSDL > ifTrue:ifFalse: pattern. > > NoopWindow subclass: SDL_ExtWindow. > NoopWindow subclass: XDL_ExtWindow. > > NoopWindow>>bordered: > > > > somewhere "currentBackEnd := SDL_ExtWindow new." > > > SDLExtendedWindow >> #bordered: aBoolean > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > > errorCode> > > ^ self nbCall: #( int SDL_SetWindowBordered ( SDL_Window * target , > SDL_bool > > aBoolean ) ) > > > > Haven't actually used this pattern yet, but at least to me, it yields a > > clear distinction between what is common between backends, and what will > > only work on some. > > SDL is of course a somewhat special case, at it itself is an abstraction > > over different backends, and there's little functionality there that > could > > not be part of a standard window API... > > > > Cheers, > > Henry > >

June 16, 2015

Re: [Pharo-dev] Location of SDL2 library

by Esteban Lorenzano

> On 16 Jun 2015, at 13:47, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > > Alright, thanks :) > > By the way, on a side note, when downloading the VM for windows, a libcairo-2.dll is provided but when using zeroconf on linux the cairo library is not provided with the VM. Is it intended ? > Because the VM then checks in the system but if you only have 64 bits libraries you need to install 32 bits ones. yes, this is intended. in linux you have to install cairo by your own. I suppose is because we thought it was easier for linux users (and we suppose most of them already have it in their systems). No idea if we were wrong :) Esteban > > 2015-06-16 13:12 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > Hi, > > There are some problems with the rpath we are trying to solveâ¦ in the mean time, best solution is to affect the LD_LIBRARY_PATH :( > > Esteban > >> On 16 Jun 2015, at 11:47, Matthieu Lacaton <matthieu.lacaton(a)gmail.com <mailto:matthieu.lacaton@gmail.com>> wrote: >> >> Hello, >> >> I am currently using Archlinux and I don't have the SDL2 library loaded into my system. >> Yesterday I downloaded the latest Pharo 5 vm and image thanks to the zeroconf scripts. >> >> When I tried to call "OSSDL2Driver hasPlugin" the return was "false" with the following message console : >> ioLoadModule(.../pharo-vm/libSDL2DisplayPlugin.so): >> libSDL2-2.0.so.0: cannot open shared object file: No such file or directory >> >> The library itself (libSDL2-2.0.so.0) is located in the pharo-vm folder, however it seems that the vm is looking for it somewhere else because after copying the file in /usr/lib32/ the VM was able to find it correctly. >> >> I was wondering : shouldn't the vm only rely on the SDL2 library inside pharo-vm folder ? >> >> Thanks, >> >> Matthieu > >

June 16, 2015

Re: [Pharo-dev] Question about API / Backend

by Ben Coman

On Tue, Jun 16, 2015 at 6:15 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On 16 Jun 2015, at 9:58 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> > wrote: > > Hello everybody, > > The question I have concerns OSWindow and its backend : SDL. However, even > if I'll speak about these two, i think the question is quite general and can > apply to every API. > > There are some functions that we are sure we will find in every backend > possible (for instance the possibility to create a new window, to resize it > etc.) and for these ones it is totally fine to abstract the backend from the > user because you know that even if the backend has to change the API will be > usable the same way. > > But there are some functions that are quite specific to a certain backend > and you cannot always find it in others. But this function is cool so it > would be a shame not to implement it just for the sake of uniformity. > In this case I see two options : > > 1) You abstract these functions exactly the same way you did for the others > and the user is not informed at all. In this case the risk is that if the > backend changes it may break the API for the user because he won't be able > to use this function anymore.And he may feel a bit sad because he was not > warned about it. > > 2) You make something to let the user know that this or that function is > specific to this or that backend. By doing so the user knows that there is a > small risk that he won't be able to use this function anymore if the backend > changes. He has been warned. > > Now I prefer the second option but I wanted to ask you about that > "something". What is the best way to warn the user ? > > - Should I let the name of the backend in the name of the method ? > "SDL_MySpecificMethod" > - Should I put all these methods in a specific package and name / comment > that package accordingly ? > - Some other things ? > > Basically my question is : what is the best way to let the user know he is > dealing with a specific function for a specific backend ? > > Thanks, > > Matthieu > > > A recent idea I had, translated to your case, was doing this by providing > accessors to specific backend extension classes. > Personally, I'd prefer to use a class separate from that which implements > the common interface, so one doesn't accidentally end up doing common calls > on only specific backends, here's a purely theoretical example of how that > may look: > > window := OSWindow new. > window title: 'Test window'. > "With SDL, we support making window unbordered" > window SDL bordered: false. > window openInWorld. But what would this code look like when later a second backend XDL does implement #bordered: ? > With a few example implementations: > OSWindow >> #SDL > "Could cache in instvar, but that would not as modular, as you can't > package that with the rest of the backend, with methods all you need > is *SDL-Windows categorization" > currentBackEnd isSDL > ifTrue: [SDL_ExtWindow target: self] > ifFalse: [NoopWindow target: self] I don't see /currentBackEnd/ is current OSWindow. I presume you are adding it. What class would you store in /currentBackEnd/ ? I guess some would have a philosophical object to "isSDL ifTrue:ifFalse: pattern. NoopWindow subclass: SDL_ExtWindow. NoopWindow subclass: XDL_ExtWindow. NoopWindow>>bordered: somewhere "currentBackEnd := SDL_ExtWindow new." > SDLExtendedWindow >> #bordered: aBoolean > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode> > ^ self nbCall: #( int SDL_SetWindowBordered ( SDL_Window * target , SDL_bool > aBoolean ) ) > > Haven't actually used this pattern yet, but at least to me, it yields a > clear distinction between what is common between backends, and what will > only work on some. > SDL is of course a somewhat special case, at it itself is an abstraction > over different backends, and there's little functionality there that could > not be part of a standard window API... > > Cheers, > Henry

June 16, 2015

Re: [Pharo-dev] Question about API / Backend

by Matthieu Lacaton

Thank you for your answer, as you said, this pattern makes things quite clear for the user. I like it :) SDL is of course a somewhat special case, at it itself is an abstraction > over different backends, and there's little functionality there that could > not be part of a standard window API... > Yeah, that's true. But actually SDL is not even really a GUI / Windowing API. As stated ont heir website it is "[...]designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware [...]" So I guess it's the other way arround. You can probably do things with a real window API that you cannot do with SDL. What made me think of this "issue" is a new functionnality coming with the next version of SDL2 : https://wiki.libsdl.org/SDL_SetWindowHitTest I implemented this in OSWindow and then I asked myself if all the other libraries could do the same. I mean, it is always possible to move a window without decorations by using the mouse position and calls to "set window position" or whatever. Same goes for resizing. But the SDL way is so easy and painless that I wanted to know if the exact same way was doable with other libraries. After some basic researches on GTK+ I was not really able to tell if it was possible to do so. So a new question arose : Should I really look at every possible backend to know if a functionnality is general or backend-specific ? :/ 2015-06-16 12:15 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 16 Jun 2015, at 9:58 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> > wrote: > > Hello everybody, > > The question I have concerns OSWindow and its backend : SDL. However, even > if I'll speak about these two, i think the question is quite general and > can apply to every API. > > There are some functions that we are sure we will find in every backend > possible (for instance the possibility to create a new window, to resize it > etc.) and for these ones it is totally fine to abstract the backend from > the user because you know that even if the backend has to change the API > will be usable the same way. > > But there are some functions that are quite specific to a certain backend > and you cannot always find it in others. But this function is cool so it > would be a shame not to implement it just for the sake of uniformity. > In this case I see two options : > > 1) You abstract these functions exactly the same way you did for the > others and the user is not informed at all. In this case the risk is that > if the backend changes it may break the API for the user because he won't > be able to use this function anymore.And he may feel a bit sad because he > was not warned about it. > > 2) You make *something* to let the user know that this or that function > is specific to this or that backend. By doing so the user knows that there > is a small risk that he won't be able to use this function anymore if the > backend changes. He has been warned. > > Now I prefer the second option but I wanted to ask you about that > "something". What is the best way to warn the user ? > > - Should I let the name of the backend in the name of the method ? > "SDL_MySpecificMethod" > - Should I put all these methods in a specific package and name / comment > that package accordingly ? > - Some other things ? > > Basically my question is : what is the best way to let the user know he is > dealing with a specific function for a specific backend ? > > Thanks, > > Matthieu > > > A recent idea I had, translated to your case, was doing this by providing > accessors to specific backend extension classes. > Personally, I'd prefer to use a class separate from that which implements > the common interface, so one doesn't accidentally end up doing common calls > on only specific backends, here's a purely theoretical example of how that > may look: > > window := OSWindow new. > window title: 'Test window'. > "With SDL, we support making window unbordered" > window SDL bordered: false. > window openInWorld. > > With a few example implementations: > OSWindow >> #SDL > "Could cache in instvar, but that would not as modular, as you can't > package that with the rest of the backend, with methods all you need is > *SDL-Windows categorization" > currentBackEnd isSDL > ifTrue: [SDL_ExtWindow target: self] > ifFalse: [NoopWindow target: self] > > SDLExtendedWindow >> #bordered: aBoolean > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode> > ^ self nbCall: #( int SDL_SetWindowBordered ( SDL_Window * target , > SDL_bool aBoolean ) ) > > Haven't actually used this pattern yet, but at least to me, it yields a > clear distinction between what is common between backends, and what will > only work on some. > SDL is of course a somewhat special case, at it itself is an abstraction > over different backends, and there's little functionality there that could > not be part of a standard window API... > > Cheers, > Henry >

June 16, 2015

Re: [Pharo-dev] Location of SDL2 library

by Matthieu Lacaton

Alright, thanks :) By the way, on a side note, when downloading the VM for windows, a libcairo-2.dll is provided but when using zeroconf on linux the cairo library is not provided with the VM. Is it intended ? Because the VM then checks in the system but if you only have 64 bits libraries you need to install 32 bits ones. 2015-06-16 13:12 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > There are some problems with the rpath we are trying to solveâ¦ in the mean > time, best solution is to affect the LD_LIBRARY_PATH :( > > Esteban > > On 16 Jun 2015, at 11:47, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> > wrote: > > Hello, > > I am currently using Archlinux and I don't have the SDL2 library loaded > into my system. > Yesterday I downloaded the latest Pharo 5 vm and image thanks to the > zeroconf scripts. > > When I tried to call "OSSDL2Driver hasPlugin" the return was "false" with > the following message console : > >> ioLoadModule(.../pharo-vm/libSDL2DisplayPlugin.so): >> libSDL2-2.0.so.0: cannot open shared object file: No such file or >> directory > > > The library itself (libSDL2-2.0.so.0) is located in the pharo-vm folder, > however it seems that the vm is looking for it somewhere else because after > copying the file in /usr/lib32/ the VM was able to find it correctly. > > I was wondering : shouldn't the vm only rely on the SDL2 library inside > pharo-vm folder ? > > Thanks, > > Matthieu > > >

June 16, 2015

Re: [Pharo-dev] Who changed the meaning of command-click on class names ?

by Sven Van Caekenberghe

> On 16 Jun 2015, at 13:16, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 16-06-15 12:10, Sven Van Caekenberghe wrote: >> >>> On 16 Jun 2015, at 12:05, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> On 16-06-15 10:15, Sven Van Caekenberghe wrote: >>>> In Pharo 5, the meaning of command-click (apple-click) on class names changed from 'Browse class' to 'References to class'. On selectors it still is 'Implementors'. >>> >>> Interesting. How and where exactly is that supposed to work? On Linux, that works in neither Pharo 4 nor 5. >> >> Are you sure ? > > Yep, tried all combinations, with and without shift, with and without the class name being selected, in three different images. In both Nautilus, Workspace and Playground. That is a pity, it works really nice. It is something that is available in most other IDEs. > Stephan

June 16, 2015

Re: [Pharo-dev] Who changed the meaning of command-click on class names ?

by Stephan Eggermont

On 16-06-15 12:10, Sven Van Caekenberghe wrote: > >> On 16 Jun 2015, at 12:05, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 16-06-15 10:15, Sven Van Caekenberghe wrote: >>> In Pharo 5, the meaning of command-click (apple-click) on class names changed from 'Browse class' to 'References to class'. On selectors it still is 'Implementors'. >> >> Interesting. How and where exactly is that supposed to work? On Linux, that works in neither Pharo 4 nor 5. > > Are you sure ? Yep, tried all combinations, with and without shift, with and without the class name being selected, in three different images. In both Nautilus, Workspace and Playground. Stephan

June 16, 2015

Re: [Pharo-dev] Location of SDL2 library

by Esteban Lorenzano

Hi, There are some problems with the rpath we are trying to solveâ¦ in the mean time, best solution is to affect the LD_LIBRARY_PATH :( Esteban > On 16 Jun 2015, at 11:47, Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > > Hello, > > I am currently using Archlinux and I don't have the SDL2 library loaded into my system. > Yesterday I downloaded the latest Pharo 5 vm and image thanks to the zeroconf scripts. > > When I tried to call "OSSDL2Driver hasPlugin" the return was "false" with the following message console : > ioLoadModule(.../pharo-vm/libSDL2DisplayPlugin.so): > libSDL2-2.0.so.0: cannot open shared object file: No such file or directory > > The library itself (libSDL2-2.0.so.0) is located in the pharo-vm folder, however it seems that the vm is looking for it somewhere else because after copying the file in /usr/lib32/ the VM was able to find it correctly. > > I was wondering : shouldn't the vm only rely on the SDL2 library inside pharo-vm folder ? > > Thanks, > > Matthieu

June 16, 2015

Re: [Pharo-dev] Location of SDL2 library

by Henrik Johansen

> On 16 Jun 2015, at 11:47 , Matthieu Lacaton <matthieu.lacaton(a)gmail.com> wrote: > > Hello, > > I am currently using Archlinux and I don't have the SDL2 library loaded into my system. > Yesterday I downloaded the latest Pharo 5 vm and image thanks to the zeroconf scripts. > > When I tried to call "OSSDL2Driver hasPlugin" the return was "false" with the following message console : > ioLoadModule(.../pharo-vm/libSDL2DisplayPlugin.so): > libSDL2-2.0.so.0: cannot open shared object file: No such file or directory > > The library itself (libSDL2-2.0.so.0) is located in the pharo-vm folder, however it seems that the vm is looking for it somewhere else because after copying the file in /usr/lib32/ the VM was able to find it correctly. > > I was wondering : shouldn't the vm only rely on the SDL2 library inside pharo-vm folder ? > > Thanks, > > Matthieu IIRC, you get the same error message if a library SDL2-2.0.so relies on cannot be found. So, assuming the zeroconf has dealth with setting LD_LIBRARY_PATH to include the vm directory, I'd try readelf -d, and check that all (32-bit versions of) the libraries SDL needs are available. Cheers, Henry

June 16, 2015

Re: [Pharo-dev] Who changed the meaning of command-click on class names ?

by Sven Van Caekenberghe

> On 16 Jun 2015, at 12:43, Torsten Bergmann <astares(a)gmx.de> wrote: > > Not unimportant side note: > > From what I see from Nicolai's high activity in bug tracker and here on the list > he is someone who closely watches the included changes and fixes/reviews issues. > This quickly helps making progress. > > @Nicolai: big thanks from my side! + 2**32 > Bye > T. > > Gesendet: Dienstag, 16. Juni 2015 um 10:44 Uhr > Von: "Nicolai Hess" <nicolaihess(a)web.de> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Who changed the meaning of command-click on class names ? > > > > 2015-06-16 10:15 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>:Hi, > > In Pharo 5, the meaning of command-click (apple-click) on class names changed from 'Browse class' to 'References to class'. On selectors it still is 'Implementors'. > > Why was this done ? Was this done intentionally or by accident, as a side effect of some other change ? > > By accident, please open an issue. (caused by 15575 AST syntax highlight: clean up variable resolving a bit ) > > I rely on it a lot and I think the old behaviour should be restored. > > Sven > > >

June 16, 2015