October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Sean P. DeNigris

horrido wrote > Having separate namespaces would be really good. > VisualWorks has them. Why not Pharo? I can't remember ever hearing disagreement on this subject. It seems the only questions have been: 1) how to do them *right*, and 2) where they fall on the endless prioritized todo list ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 12, 2017

Re: [Pharo-users] [ANN] Libusb binding + HID support for Pharo

by Julien

Normally, it should be possible. Libusb can be compiled for 64bits architectures. I donât know if it changes something in the UFFI binding side? Julien > Le 12 oct. 2017 Ã 14:41, Thierry Goubier <thierry.goubier(a)gmail.com> a Ã©crit : > > Very cool. Would that be doable to adapt for a 64bits version? > > Thierry > > 2017-10-12 13:29 GMT+02:00 Julien <julien.delplanque(a)inria.fr <mailto:julien.delplanque@inria.fr>>: > Hello, > > A bit late, there is a Libusb [1] binding (using UFFI) and support for the Human Interface Device [2] (that uses the binding but is written in pure Smalltalk) for Pharo. > > Everything is on the github repository [3]. Â« Install Â» and Â« Quick start Â» sections give you all you need to start using the project. > > One could also have a look at the wiki [4]. > > It works on Linux but hasnât been tested on Mac OS nor Windows (it should work since libusb library works on these platforms). > > Do not forget to install the 32 bits versions of libusb on your computer. > > The purpose of this library is to provide the ability to use USB devices directly from Pharo. > > For example, one could get data from a PS3 controller, a mouse, a keyboard, an Arduino device, etcâ¦ > > Cheers, > > Julien > > PS: I realised this project during an internship in TaMÃ¨re SCRL company [5]. Thanks to them! > > Links: > [1]: http://libusb.info <http://libusb.info/> > [2]: https://en.wikipedia.org/wiki/Human_interface_device <https://en.wikipedia.org/wiki/Human_interface_device> > [3]: https://github.com/tamerescrl/libusb-pharo <https://github.com/tamerescrl/libusb-pharo> > [4]: https://github.com/tamerescrl/libusb-pharo/wiki <https://github.com/tamerescrl/libusb-pharo/wiki> > [5]: http://tamere.eu <http://tamere.eu/>

Oct. 12, 2017

Re: [Pharo-users] [ANN] Libusb binding + HID support for Pharo

by Julien

Youâre welcome! :-) > Le 12 oct. 2017 Ã 14:36, Guillermo Polito <guillermopolito(a)gmail.com> a Ã©crit : > > Nice!!! Thanks for sharing :) > > On Thu, Oct 12, 2017 at 1:29 PM, Julien <julien.delplanque(a)inria.fr <mailto:julien.delplanque@inria.fr>> wrote: > Hello, > > A bit late, there is a Libusb [1] binding (using UFFI) and support for the Human Interface Device [2] (that uses the binding but is written in pure Smalltalk) for Pharo. > > Everything is on the github repository [3]. Â« Install Â» and Â« Quick start Â» sections give you all you need to start using the project. > > One could also have a look at the wiki [4]. > > It works on Linux but hasnât been tested on Mac OS nor Windows (it should work since libusb library works on these platforms). > > Do not forget to install the 32 bits versions of libusb on your computer. > > The purpose of this library is to provide the ability to use USB devices directly from Pharo. > > For example, one could get data from a PS3 controller, a mouse, a keyboard, an Arduino device, etcâ¦ > > Cheers, > > Julien > > PS: I realised this project during an internship in TaMÃ¨re SCRL company [5]. Thanks to them! > > Links: > [1]: http://libusb.info <http://libusb.info/> > [2]: https://en.wikipedia.org/wiki/Human_interface_device <https://en.wikipedia.org/wiki/Human_interface_device> > [3]: https://github.com/tamerescrl/libusb-pharo <https://github.com/tamerescrl/libusb-pharo> > [4]: https://github.com/tamerescrl/libusb-pharo/wiki <https://github.com/tamerescrl/libusb-pharo/wiki> > [5]: http://tamere.eu <http://tamere.eu/> > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Oct. 12, 2017

Re: [Pharo-users] [ANN] Libusb binding + HID support for Pharo

by Thierry Goubier

Very cool. Would that be doable to adapt for a 64bits version? Thierry 2017-10-12 13:29 GMT+02:00 Julien <julien.delplanque(a)inria.fr>: > Hello, > > A bit late, there is a Libusb [1] binding (using UFFI) and support for the > Human Interface Device [2] (that uses the binding but is written in pure > Smalltalk) for Pharo. > > Everything is on the github repository [3]. Â« Install Â» and Â« Quick > start Â» sections give you all you need to start using the project. > > One could also have a look at the wiki [4]. > > It works on Linux but hasnât been tested on Mac OS nor Windows (it should > work since libusb library works on these platforms). > > Do not forget to install the 32 bits versions of libusb on your computer. > > The purpose of this library is to provide the ability to use USB devices > directly from Pharo. > > For example, one could get data from a PS3 controller, a mouse, a > keyboard, an Arduino device, etcâ¦ > > Cheers, > > Julien > > PS: I realised this project during an internship in TaMÃ¨re SCRL company > [5]. Thanks to them! > > Links: > [1]: http://libusb.info > [2]: https://en.wikipedia.org/wiki/Human_interface_device > [3]: https://github.com/tamerescrl/libusb-pharo > [4]: https://github.com/tamerescrl/libusb-pharo/wiki > [5]: http://tamere.eu >

Oct. 12, 2017

Re: [Pharo-users] [ANN] Libusb binding + HID support for Pharo

by Guillermo Polito

Nice!!! Thanks for sharing :) On Thu, Oct 12, 2017 at 1:29 PM, Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > A bit late, there is a Libusb [1] binding (using UFFI) and support for the > Human Interface Device [2] (that uses the binding but is written in pure > Smalltalk) for Pharo. > > Everything is on the github repository [3]. Â« Install Â» and Â« Quick > start Â» sections give you all you need to start using the project. > > One could also have a look at the wiki [4]. > > It works on Linux but hasnât been tested on Mac OS nor Windows (it should > work since libusb library works on these platforms). > > Do not forget to install the 32 bits versions of libusb on your computer. > > The purpose of this library is to provide the ability to use USB devices > directly from Pharo. > > For example, one could get data from a PS3 controller, a mouse, a > keyboard, an Arduino device, etcâ¦ > > Cheers, > > Julien > > PS: I realised this project during an internship in TaMÃ¨re SCRL company > [5]. Thanks to them! > > Links: > [1]: http://libusb.info > [2]: https://en.wikipedia.org/wiki/Human_interface_device > [3]: https://github.com/tamerescrl/libusb-pharo > [4]: https://github.com/tamerescrl/libusb-pharo/wiki > [5]: http://tamere.eu > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 12, 2017

[ANN] Libusb binding + HID support for Pharo

by Julien

Hello, A bit late, there is a Libusb [1] binding (using UFFI) and support for the Human Interface Device [2] (that uses the binding but is written in pure Smalltalk) for Pharo. Everything is on the github repository [3]. Â« Install Â» and Â« Quick start Â» sections give you all you need to start using the project. One could also have a look at the wiki [4]. It works on Linux but hasnât been tested on Mac OS nor Windows (it should work since libusb library works on these platforms). Do not forget to install the 32 bits versions of libusb on your computer. The purpose of this library is to provide the ability to use USB devices directly from Pharo. For example, one could get data from a PS3 controller, a mouse, a keyboard, an Arduino device, etcâ¦ Cheers, Julien PS: I realised this project during an internship in TaMÃ¨re SCRL company [5]. Thanks to them! Links: [1]: http://libusb.info <http://libusb.info/> [2]: https://en.wikipedia.org/wiki/Human_interface_device <https://en.wikipedia.org/wiki/Human_interface_device> [3]: https://github.com/tamerescrl/libusb-pharo <https://github.com/tamerescrl/libusb-pharo> [4]: https://github.com/tamerescrl/libusb-pharo/wiki <https://github.com/tamerescrl/libusb-pharo/wiki> [5]: http://tamere.eu <http://tamere.eu/>

Oct. 12, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by horrido

I'll second that. Having separate namespaces would be really good. VisualWorks has them. Why not Pharo? kilon.alios wrote > The one things I trully miss, even know that I am "experieced" Pharo > coder, > depending on your standards, is python namespaces > > I dont care about the dot syntax but containers of containers at language > level that will make me avoid giving weird names to my Pharo classes to > avoid potential collisions is a must have for me. It would also make the > System Browser experience much smoother not only for beginners but also > experts in Pharo. > > Also again under the threat of being thrown tomoatoes (probably justified) > I would not mind a more modular approach to image format, for example > having mutlipe files instead one monolithic. Not as a mandatory thing just > something optional, the ability to break an image to pieces , send those > pieces around so people do not have to close their image to open yours. > Fuel covers this case nicely but again it could become a bit more "out of > the box" and more automatic. . > > On Thu, Oct 12, 2017 at 11:22 AM stephan < > stephan@ > > wrote: > >> On 12-10-17 08:30, Markus Stumptner wrote: >> > Just to lead this back to the original question. What you say is >> > undoubtedly true. It is not, however, necessarily something that a >> > beginner will understand or be able to share in. >> >> That is a very important point. It also explains a lot of why we are >> missing certain things that developers coming from other environments >> take for granted: they simply provide less value to experienced >> smalltalkers. And that is indeed a barrier to entry. >> >> I remember sharply my first looking at squeak, and just not >> understanding how I could create a new class or method in a browser. >> Another was that I have been programming in seaside for a year without >> using senders and implementers. Pair programming for an hour with >> Philippe Marschall showed me so much invisible/hidden functionality. >> >> Other (mainstream) environments don't provide the immediate feedback of >> navigating, inspecting and manipulating the whole environment, and >> therefore newcomers have no appropriate expectations (internal model), >> and are clueless on what they are able to do in Pharo. Combined with the >> lack of systematic visual clues and the high density of the class >> library that makes it not easy to learn. >> >> Stephan >> >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Oct. 12, 2017

Re: [Pharo-users] Custom URI scheme for Pharo

by Dimitris Chloupis

I cant argue with that , dealing with C can be quite âan interestingâ experience :D itâs better and probably healthier when it happens at small dosages. On Thu, 12 Oct 2017 at 11:56, Manuel Leuenberger <leuenberger(a)inf.unibe.ch> wrote: > Yes, that was my thread. Thanks for the hint with overlaying a transparent > OS window and controlling it from within Pharo. The overlay solution is not > a priority for me, as it would require me to dive deeper into the macOS > world. I rather live in the Pharo world, for now. :) > > On 12 Oct 2017, at 10:26, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Probably it was your thread but as I said you can make a "hack" and > overlay a system GUI over Pharo GUI This way you can view the PDF, "inside" > Pharo. I think it is even possile to get the handle of the Pharo window > and directly affect it to embed a PDF viewer. > > The second solution is better because you want have to wory about Pharo > window resizing as the PDF will be trully embeded inisde the Pharo window > instead of overlayed. > > I am willing to bet you can avoid the multiple windows anooyance in some > way on another without making your head explode. Unless its not a priority > for you. > > Looks great, well done mate. Keep the creative juices flowing ;) > > On Thu, Oct 12, 2017 at 2:02 AM Manuel Leuenberger < > leuenberger(a)inf.unibe.ch> wrote: > >> Sounds like a nice setup you got there :). >> >> I want to integrate documents displayed in the system viewer, as they >> cannot be displayed within Pharo (Web, PDF, â¦). So hyperlinking is the only >> way I see to get something close. I created a little demo where I injected >> hyperlinks in a PDF like âpharo://click?whatever=youwant'. When you >> click them, a little Objective-C app catches the OS event and forwards it >> to an HTTP server running in Pharo. So I can do things like this: >> >> https://youtu.be/CR_scZSDf3s >> >> On 11 Oct 2017, at 00:24, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >> I think I remember this disussed before. >> By talking with Pharo I assume here about another program talking to >> Pharo ? Possible not wrriten in Pharo ? >> >> If thats the case then you can use whatever IPC works better for your >> needs. If the communication will be remotely I recommend sockets, for fast >> local communication I recommend shared memory. They are both very mature >> technologies , very reliable and cross platform. >> >> Now on the URI protocol, I think that will depend what you want to >> achieve. Any string will be easy to parse with Pharo's regex and trigger >> the approriate methods. Pharo also have Annoucements, think of it as an >> event system that awaits to be triggered by an event, usually a Pharo event >> but I see no reason why it cant listen to external events either. >> >> I do not think you will need a middle application , a servel client >> relation shipe should be more than enough. >> >> With my Atlas bridge which is a Pharo library that allows you to use >> Python libraries I did a neat trick with Pharo that it already communicated >> with Python via sockets, sending python commands but also Python could >> communicate back errors , then Pharo would trigger the debugger, display >> the python error inside the Pharo debugger and the debugger would pop up on >> the exact pharo command that send the faulty python code. You could then >> change the pharo command on the spot and it was resent and python continued >> like the error never happened to retain the all important live coding >> workflow. >> >> I created a tiny protocol to difirentia incoming messages talking about >> errors from the ones returning python varriable values. Something stupid >> like "pythonError: blah blah" but it got the job done >> >> >> >> On Tue, Oct 10, 2017 at 10:07 PM Manuel Leuenberger < >> leuenberger(a)inf.unibe.ch> wrote: >> >>> Hi, >>> >>> Is there any support from the VM/Application package to add custom URI >>> schemes to listen to from within Pharo? I would like to have a hyperlink >>> like âpharo://send?data=fancypantsâ in an arbitrary document that, when >>> clicked, switches to Pharo and calls a hook I can register. Could someone >>> give me a hint how to achieve that, or do I have to build a little bridge >>> application that handles the scheme registration and talks with Pharo >>> through another channel? Currently, I only need this for OS X. >>> >>> Cheers, >>> Manuel >>> >>> >> >> >

Oct. 12, 2017

Re: [Pharo-users] Custom URI scheme for Pharo

by Manuel Leuenberger

Yes, that was my thread. Thanks for the hint with overlaying a transparent OS window and controlling it from within Pharo. The overlay solution is not a priority for me, as it would require me to dive deeper into the macOS world. I rather live in the Pharo world, for now. :) > On 12 Oct 2017, at 10:26, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Probably it was your thread but as I said you can make a "hack" and overlay a system GUI over Pharo GUI This way you can view the PDF, "inside" Pharo. I think it is even possile to get the handle of the Pharo window and directly affect it to embed a PDF viewer. > > The second solution is better because you want have to wory about Pharo window resizing as the PDF will be trully embeded inisde the Pharo window instead of overlayed. > > I am willing to bet you can avoid the multiple windows anooyance in some way on another without making your head explode. Unless its not a priority for you. > > Looks great, well done mate. Keep the creative juices flowing ;) > > On Thu, Oct 12, 2017 at 2:02 AM Manuel Leuenberger <leuenberger(a)inf.unibe.ch <mailto:leuenberger@inf.unibe.ch>> wrote: > Sounds like a nice setup you got there :). > > I want to integrate documents displayed in the system viewer, as they cannot be displayed within Pharo (Web, PDF, â¦). So hyperlinking is the only way I see to get something close. I created a little demo where I injected hyperlinks in a PDF like âpharo://click?whatever=youwant' <>. When you click them, a little Objective-C app catches the OS event and forwards it to an HTTP server running in Pharo. So I can do things like this: > > https://youtu.be/CR_scZSDf3s <https://youtu.be/CR_scZSDf3s> > >> On 11 Oct 2017, at 00:24, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> >> I think I remember this disussed before. >> By talking with Pharo I assume here about another program talking to Pharo ? Possible not wrriten in Pharo ? >> >> If thats the case then you can use whatever IPC works better for your needs. If the communication will be remotely I recommend sockets, for fast local communication I recommend shared memory. They are both very mature technologies , very reliable and cross platform. >> >> Now on the URI protocol, I think that will depend what you want to achieve. Any string will be easy to parse with Pharo's regex and trigger the approriate methods. Pharo also have Annoucements, think of it as an event system that awaits to be triggered by an event, usually a Pharo event but I see no reason why it cant listen to external events either. >> >> I do not think you will need a middle application , a servel client relation shipe should be more than enough. >> >> With my Atlas bridge which is a Pharo library that allows you to use Python libraries I did a neat trick with Pharo that it already communicated with Python via sockets, sending python commands but also Python could communicate back errors , then Pharo would trigger the debugger, display the python error inside the Pharo debugger and the debugger would pop up on the exact pharo command that send the faulty python code. You could then change the pharo command on the spot and it was resent and python continued like the error never happened to retain the all important live coding workflow. >> >> I created a tiny protocol to difirentia incoming messages talking about errors from the ones returning python varriable values. Something stupid like "pythonError: blah blah" but it got the job done >> >> >> >> On Tue, Oct 10, 2017 at 10:07 PM Manuel Leuenberger <leuenberger(a)inf.unibe.ch <mailto:leuenberger@inf.unibe.ch>> wrote: >> Hi, >> >> Is there any support from the VM/Application package to add custom URI schemes to listen to from within Pharo? I would like to have a hyperlink like âpharo://send?data=fancypantsâ <> in an arbitrary document that, when clicked, switches to Pharo and calls a hook I can register. Could someone give me a hint how to achieve that, or do I have to build a little bridge application that handles the scheme registration and talks with Pharo through another channel? Currently, I only need this for OS X. >> >> Cheers, >> Manuel >> >

Oct. 12, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Dimitris Chloupis

The one things I trully miss, even know that I am "experieced" Pharo coder, depending on your standards, is python namespaces I dont care about the dot syntax but containers of containers at language level that will make me avoid giving weird names to my Pharo classes to avoid potential collisions is a must have for me. It would also make the System Browser experience much smoother not only for beginners but also experts in Pharo. Also again under the threat of being thrown tomoatoes (probably justified) I would not mind a more modular approach to image format, for example having mutlipe files instead one monolithic. Not as a mandatory thing just something optional, the ability to break an image to pieces , send those pieces around so people do not have to close their image to open yours. Fuel covers this case nicely but again it could become a bit more "out of the box" and more automatic. . On Thu, Oct 12, 2017 at 11:22 AM stephan <stephan(a)stack.nl> wrote: > On 12-10-17 08:30, Markus Stumptner wrote: > > Just to lead this back to the original question. What you say is > > undoubtedly true. It is not, however, necessarily something that a > > beginner will understand or be able to share in. > > That is a very important point. It also explains a lot of why we are > missing certain things that developers coming from other environments > take for granted: they simply provide less value to experienced > smalltalkers. And that is indeed a barrier to entry. > > I remember sharply my first looking at squeak, and just not > understanding how I could create a new class or method in a browser. > Another was that I have been programming in seaside for a year without > using senders and implementers. Pair programming for an hour with > Philippe Marschall showed me so much invisible/hidden functionality. > > Other (mainstream) environments don't provide the immediate feedback of > navigating, inspecting and manipulating the whole environment, and > therefore newcomers have no appropriate expectations (internal model), > and are clueless on what they are able to do in Pharo. Combined with the > lack of systematic visual clues and the high density of the class > library that makes it not easy to learn. > > Stephan > > >

Oct. 12, 2017