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

Re: [Pharo-users] "Building-With versus Building-on"

by Dimitris Chloupis

It's a mentality issue, modern programming languages provide the material necessary to create innovative environments but their communities just simply does not care. A language designer may introduce a feature in a language that is super useful. Still people may not use it. And let's face it even with Pharo nothing beats a personalized environment, of course personalisation is a lot of work. Hence why people avoid it. Essentially boiling down to cooking your own food instead of getting it from a shop. When you begin to learn how to cook , its kinda sucks, but the more you cook the better it tastes. Of course it takes time to get there and hence why so few people cook. Eclispe , which I will disagree with your that is not the worst IDE, started as a smalltalk IDE and then it got Eclipsed. I am sure those people had a "build on" environment , still it got messy. We can blame porting to Java, but can we really blame Java for the mess that is called "Eclipse".... ehhhh.... nope. I once saw a youtube video about a musician using windows sounds (the standard sounds we all know of) to make a very nice music piece. He did all that using multiple instances of windows media player. Just pause reading think about this for a minute. That's the real essence of creativity Use something very limited and come up with something amazing. The software industry is not about creativity for the most part. On the other hand I that work with 3d its amazing how fast super cool new technologies pop around like mushrooms. Every year we have massive improvements in libraries and tools. But the coding for 3d graphics is all about creativity , artists are not very forgiving for ugly GUI, limited features and innovation stagnation. Artists want to be inspired by the tools they use. But then that's the creativity realm. Creativity pays the bills in this case, lack of it , game is not fun, rendering or animation is not fun, you can lose millions. Of course in the creativity realm , there is too much innovation and unless you keep up you are kicked out the door, yesterday. Which brings down to the problem of complexity and how you deal with it. And I don't mean about bad complexity , aka web dev, I am talking about good complexity. Features you cannot ignore because other will use before you and you are left behind etc. On Thu, Oct 12, 2017 at 7:13 PM Peter Fisk <peter.fisk(a)gmail.com> wrote: > Thanks for posting this. > > It is one of the best descriptions of the state of the software industry > that I have seen. > > > On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > >> https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71 >> >> >> This is an article not *specifically* about Pharo, rather on the state of the industry >> in general and how it got that way, but positing Pharo as a way to learn >> building-*on* rather than building-*with*, where in the latter case on >> every project you start at essentially the same place. >> >> >> As a result it does put in front of people a fair amount of info on >> Pharo, and challenges them to try it. >> >> >> cheers >> >> Andrew Glynn >> >> >

Oct. 12, 2017

Re: [Pharo-users] "Building-With versus Building-on"

by Peter Fisk

Thanks for posting this. It is one of the best descriptions of the state of the software industry that I have seen. On Thu, Oct 12, 2017 at 11:50 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034c71 > > > This is an article not *specifically* about Pharo, rather on the state of the industry > in general and how it got that way, but positing Pharo as a way to learn > building-*on* rather than building-*with*, where in the latter case on > every project you start at essentially the same place. > > > As a result it does put in front of people a fair amount of info on Pharo, > and challenges them to try it. > > > cheers > > Andrew Glynn > >

Oct. 12, 2017

"Building-With versus Building-on"

by Andrew Glynn

https://medium.com/@dasein42/building-with-versus-building-on-c51aa3034 c71 This is an article not specifically about Pharo, rather on the state of the industry in general and how it got that way, but positing Pharo as a way to learn building-on rather than building-with, where in the latter case on every project you start at essentially the same place.Â Â As a result it does put in front of people a fair amount of info on Pharo, and challenges them to try it. cheersAndrew Glynn

Oct. 12, 2017

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

by Brad

Plus, namespaces are difficult to implement. It could tear your class library to pieces Brad Selfridge 913-269-2385 > On Oct 12, 2017, at 9:10 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > For me there is also question 3) How closely they are related to the bootstrap project > > namespaces afterall is all about modularity which is the goal of bootstrap as well . no ? > So maybe we should not view them as a separate project and more as boostrap v2 , after v1 is released of course > Proably Pharo 9 or 10 should be a good period to focus on them. Bootstrap will have matured and stabilize and then we can go the extra step of namespaces. > > Also in Delphi , besides namespaces which is purely a language construct we had "Components" , think of them as namespaces but meant to work convenient in a IDE enviroment. I really like it as an idea and Delphi based its whole library on components. Again pure objects of course, with some metadata for the IDE to use, like category, dependencies etc > > So if namespaces is the bridge between bootstrap and the language , Components can be the bridge between bootsrap and the IDE , because their role was to assembly libraries together via drag and drop and make code like legos. So it can be Components containing namespaces, namespaces containing objects. > > Thats one idea that worked well enough in practice to make Borland very profitable. It applied it both in Delphin and C++ Builder products. The library was called VCL (Visual Component Library) and still exists today after decades of use. > > Metacello also can come to this game on the basis that nowdays everything is online , Components could abstract git and other version controls and offer a convenient drag and drop from the github directly to the comforts of you image with no extra tool needed like Iceberg. > > You can then use Iceberg to commit back to the repo. > > It can really come together quite nicely if Components function as in Delphi, a common protocol for object to communicate for IDE convenience, without braking the existing legacy code in Pharo. > > Well thats just an idea, based on my personal experience. > >> On Thu, Oct 12, 2017 at 3:53 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> 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

Zinc release?

by Herby VojÄÃk

There are a few fixes out there for Zinc, not to mention convenience like ZnEntity class >> json:. Don't you consider releasing the new version (as I tried to update it by hand, it is not that easy, it has more components, to load HTTP I had to update Character-Encoding as well, so probably better if bumped as a group)? Herby

Oct. 12, 2017

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

by Julien

> > > > For example, one could get data from a PS3 controller, a mouse, a keyboard, an Arduino device, etcâ¦ > > And did you use it for these kind of devices? Or anything else? > There is an example with an HID mouse on the wiki https://github.com/tamerescrl/libusb-pharo/wiki/Get-and-parse-HID-reports <https://github.com/tamerescrl/libusb-pharo/wiki/Get-and-parse-HID-reports> I managed to get data from a PS3 controller but I can not find my code anymore, I think I lost it. It was not that hard to do, I may re-do it one day and write a small tutorial. The only problem with PS3 controller is that the HID descriptor is hidden (you have to get it from the internet, it is not stored in the device). Julien

Oct. 12, 2017

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

by Denis Kudriashov

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. > Cool project. > > For example, one could get data from a PS3 controller, a mouse, a > keyboard, an Arduino device, etcâ¦ > And did you use it for these kind of devices? Or anything else? > > 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] Behold Pharo: The Modern Smalltalk

by Dimitris Chloupis

For me there is also question 3) How closely they are related to the bootstrap project namespaces afterall is all about modularity which is the goal of bootstrap as well . no ? So maybe we should not view them as a separate project and more as boostrap v2 , after v1 is released of course Proably Pharo 9 or 10 should be a good period to focus on them. Bootstrap will have matured and stabilize and then we can go the extra step of namespaces. Also in Delphi , besides namespaces which is purely a language construct we had "Components" , think of them as namespaces but meant to work convenient in a IDE enviroment. I really like it as an idea and Delphi based its whole library on components. Again pure objects of course, with some metadata for the IDE to use, like category, dependencies etc So if namespaces is the bridge between bootstrap and the language , Components can be the bridge between bootsrap and the IDE , because their role was to assembly libraries together via drag and drop and make code like legos. So it can be Components containing namespaces, namespaces containing objects. Thats one idea that worked well enough in practice to make Borland very profitable. It applied it both in Delphin and C++ Builder products. The library was called VCL (Visual Component Library) and still exists today after decades of use. Metacello also can come to this game on the basis that nowdays everything is online , Components could abstract git and other version controls and offer a convenient drag and drop from the github directly to the comforts of you image with no extra tool needed like Iceberg. You can then use Iceberg to commit back to the repo. It can really come together quite nicely if Components function as in Delphi, a common protocol for object to communicate for IDE convenience, without braking the existing legacy code in Pharo. Well thats just an idea, based on my personal experience. On Thu, Oct 12, 2017 at 3:53 PM Sean P. DeNigris <sean(a)clipperadams.com> wrote: > 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 Thierry Goubier

2017-10-12 15:05 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Thu, Oct 12, 2017 at 2:49 PM, Julien <julien.delplanque(a)inria.fr> > wrote: > >> 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? >> > > It should not, besides the library's location. > > That was the first hurdle. Easily solved. > And, if you find a case where the binding does not work on 64 bits it is > either: > - a UFFI bug in the type mappings (e.g., a wrong mapping between a type > name and the correct 32/64 bit size and marshalling) > - or a bug in the bindings using the wrong types (e.g., using long > instead of void*) > And the first FFI call fails (the lib init). Thierry > > >> >> 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>: >> >>> 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 <+33%206%2052%2070%2066%2013> >

Oct. 12, 2017

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

by Guillermo Polito

On Thu, Oct 12, 2017 at 2:49 PM, Julien <julien.delplanque(a)inria.fr> wrote: > 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? > It should not, besides the library's location. And, if you find a case where the binding does not work on 64 bits it is either: - a UFFI bug in the type mappings (e.g., a wrong mapping between a type name and the correct 32/64 bit size and marshalling) - or a bug in the bindings using the wrong types (e.g., using long instead of void*) > > 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>: > >> 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