May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Serial port support on Pharo (2 or 3)

by Esteban Lorenzano

On 14 May 2014, at 10:40, phil(a)highoctane.be wrote: > On Wed, May 14, 2014 at 10:15 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi all, > > has anybody success using serial ports with Pharo on Mac or Linux? We're having reports of lack of success, including lack of success in recompiling a Pharo VM with a correct serial port access (a few months ago), where the same approach was sucessfull with a squeak VM. > > I see that the current out of the box build gives: > > buildUnix32 > CogNativeBoostPlugin setTargetPlatform: #Linux32PlatformId. > > PharoUnixConfig new > "generateForDebug;" > addExternalPlugins: #( FT2Plugin SqueakSSLPlugin ); > addInternalPlugins: #( UnixOSProcessPlugin ); > addThirdpartyLibraries: #( > 'libssh2' > 'libgit2' ); > generateSources; > generate. > > So, there is no SerialPlugin in there for sure. this is wrong. serial plugin is included as part of the standard default plugins, thatâs why it is not seen there. cheers, Esteban > > platforms/unix/plugins/SerialPlugin has the unix specific code with the primitives implementation. > > It looks like the code uses those to access the serial ports. > > #ifdef BUILD_FOR_OSX > static const char *serialPortBaseNameDefault = "/dev/ttys%d"; > #else > static const char *serialPortBaseNameDefault = "/dev/ttyS%d"; > #endif > > and the SerialPlugin code inside the image looks okay. > > Changing the buildUnix32 into: > > buildUnix32 > CogNativeBoostPlugin setTargetPlatform: #Linux32PlatformId. > > PharoUnixConfig new > "generateForDebug;" > addExternalPlugins: #( FT2Plugin SqueakSSLPlugin ); > addInternalPlugins: #( UnixOSProcessPlugin SerialPlugin ); > addThirdpartyLibraries: #( > 'libssh2' > 'libgit2' ); > generateSources; > generate. > > generates all without an issue. > > Now, I am going to compile this on CentOS and get back to you. > > Phil > > > > > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

May 14, 2014

Re: [Pharo-dev] I love the Pharo 3 Dark Theme

by phil＠highoctane.be

On Wed, May 14, 2014 at 10:39 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > Hi, > > I have been using the new Pharo 3 Dark Theme since it was announced on May > 1st. In my specific case, I am using the FreeType fonts Open Sans Regular > 11 and Source Code Pro Regular 11 on a MacBookAir, both on the 13 inch > 1440x900 built in screen and on a 23 inch 1920x1024 external monitor. > > Every day there is a moment that I think: this looks so nice, this is so > pleasant to use. Really Esteban, I don't know how you did it, but the color > palette is really well chosen, plain beautiful. Let's make this either a > permanent part of Pharo or an easy to load extension, real soon. > Same feel here. Now, I am using the DawnTheme from Sebastian who made a warmer version (SublimeText like) and put in some changes of mine. Yeah, this has changed the whole experience for the best. Laptop and big screen are both supernice to work with. > > Thank you ! > +1000! (that's a factorial) Phil > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > >

May 14, 2014

Re: [Pharo-dev] Serial port support on Pharo (2 or 3)

by Esteban Lorenzano

serial port should be working. at least in vmLatest. cheers, Esteban On 14 May 2014, at 10:15, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi all, > > has anybody success using serial ports with Pharo on Mac or Linux? We're having reports of lack of success, including lack of success in recompiling a Pharo VM with a correct serial port access (a few months ago), where the same approach was sucessfull with a squeak VM. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

May 14, 2014

Re: [Pharo-dev] Serial port support on Pharo (2 or 3)

by phil＠highoctane.be

On Wed, May 14, 2014 at 10:15 AM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > Hi all, > > has anybody success using serial ports with Pharo on Mac or Linux? We're > having reports of lack of success, including lack of success in recompiling > a Pharo VM with a correct serial port access (a few months ago), where the > same approach was sucessfull with a squeak VM. I see that the current out of the box build gives: buildUnix32 CogNativeBoostPlugin setTargetPlatform: #Linux32PlatformId. PharoUnixConfig new "generateForDebug;" addExternalPlugins: #( FT2Plugin SqueakSSLPlugin ); addInternalPlugins: #( UnixOSProcessPlugin ); addThirdpartyLibraries: #( 'libssh2' 'libgit2' ); generateSources; generate. So, there is no SerialPlugin in there for sure. platforms/unix/plugins/SerialPlugin has the unix specific code with the primitives implementation. It looks like the code uses those to access the serial ports. #ifdef BUILD_FOR_OSX static const char *serialPortBaseNameDefault = "/dev/ttys%d"; #else static const char *serialPortBaseNameDefault = "/dev/ttyS%d"; #endif and the SerialPlugin code inside the image looks okay. Changing the buildUnix32 into: buildUnix32 CogNativeBoostPlugin setTargetPlatform: #Linux32PlatformId. PharoUnixConfig new "generateForDebug;" addExternalPlugins: #( FT2Plugin SqueakSSLPlugin ); addInternalPlugins: #( UnixOSProcessPlugin SerialPlugin ); addThirdpartyLibraries: #( 'libssh2' 'libgit2' ); generateSources; generate. generates all without an issue. Now, I am going to compile this on CentOS and get back to you. Phil > > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

May 14, 2014

I love the Pharo 3 Dark Theme

by Sven Van Caekenberghe

Hi, I have been using the new Pharo 3 Dark Theme since it was announced on May 1st. In my specific case, I am using the FreeType fonts Open Sans Regular 11 and Source Code Pro Regular 11 on a MacBookAir, both on the 13 inch 1440x900 built in screen and on a 23 inch 1920x1024 external monitor. Every day there is a moment that I think: this looks so nice, this is so pleasant to use. Really Esteban, I don't know how you did it, but the color palette is really well chosen, plain beautiful. Let's make this either a permanent part of Pharo or an easy to load extension, real soon. Thank you ! Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

May 14, 2014

Serial port support on Pharo (2 or 3)

by Goubier Thierry

Hi all, has anybody success using serial ports with Pharo on Mac or Linux? We're having reports of lack of success, including lack of success in recompiling a Pharo VM with a correct serial port access (a few months ago), where the same approach was sucessfull with a squeak VM. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 14, 2014

Re: [Pharo-dev] a Pharo talk from a ruby conference

by phil＠highoctane.be

There is the liveliness aspect. Today we get this with React for example on the web. That's also what Morphic provides (albeit the internals may be better, it is still great at the core) with the stepping methods. I wouldn't go down the Agile road as this is looking more and more like a religion and not driven by pragmatic considerations. For me, Pharo provides the shortest path between ideas and manifestations of those ideas. What makes Pharo nice is that people are taking charge and pushing forward. The willingness to make things move forward, the relentless progress (look at a 1.3 for example vs a 3.0), tools that are emerging, integration with mainstream systems are all aspects that make Pharo great. No such thing in Squeak these days. Of course there are rough edges. Maybe this Pharo thing is the pioneer's best friend. It pushes on the most important motivational source in people: the desire to use it. That's the #1 consideration for me: I do want to use Pharo, no matter the quirks. It is like a drug. Phil On Wed, May 14, 2014 at 7:47 AM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > Morning, > > Livecoding is nice. I also like the idea of using the adjective "Agile" > as it conveys coolness in the today developers mind: "Pharo, an agile > programming environment and language for agile developers." > > Hilaire > > Le 13/05/2014 17:45, Craig Latta a Ã©crit : > > Let's put more energy into a concise and intriguing description. I > > think the primary concepts are programming, dynamism and messaging. The > > word "livecoding" seems to resonate these days. If we're going to repeat > > a word twenty times, I would choose that one. :) It has a nice ring > > -- > Dr. Geo http://drgeo.eu > > >

May 14, 2014

Re: [Pharo-dev] a Pharo talk from a ruby conference

by Hilaire Fernandes

Morning, Livecoding is nice. I also like the idea of using the adjective "Agile" as it conveys coolness in the today developers mind: "Pharo, an agile programming environment and language for agile developers." Hilaire Le 13/05/2014 17:45, Craig Latta a Ã©crit : > Let's put more energy into a concise and intriguing description. I > think the primary concepts are programming, dynamism and messaging. The > word "livecoding" seems to resonate these days. If we're going to repeat > a word twenty times, I would choose that one. :) It has a nice ring -- Dr. Geo http://drgeo.eu

May 14, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Carlo

On 13 May 2014, at 3:47 PM, David Astels <dastels(a)icloud.com> wrote: > Well, an issue of good OO design or not. Returning a mutable collection breaks encapsulation. My initial question is whether the collection is simply a detail of the implementation or part of the external interface you want to expose. If the former, hide the collection and expose operations that provide whatâs truly needed. If the latter, then you might need immutable collections. Agree 100% with Davidâs comment, itâs an issue of good OO design and there are valid cases to return immutable collections. I think most developers return internal collections, breaking encapsulation, but get away with it 99% of the time and only occasionally get burnt with a nasty bug or a deep mess. Cheers Carlo

May 13, 2014

Re: [Pharo-dev] Immutable collections and encapsulation

by Carlo

Hi The advantage is that there is a standard library for implementing efficient unmodifiable âread-onlyâ collections. Just because the Java âcrowdâ have it doesnât mean they misuse it (or that they do not understand OO); there are the odd occasions when it is useful to tighten down your interfaces and by creating a âread-onlyâ view e.g. you want to return a list of errors while ensuring that none of your clients modify (add or remove) the underlying list. This can be (efficiently) achieved in Java by wrapping your collection in an unmodifiable list as access âreads-throughâ to the wrapped collection. My understanding is that the common idiom for Smalltalk code is to rather perform a copy of the collection (as was suggested by others), this could be very inefficient but needs to be weighed in versus introducing an unmodifiable collection that breaks the Liskov substitution principle and could potentially have confusing concurrency issues (e.g. unmodifiable collection is âread-throughâ which means that underlying data structure can be modified which will affect the unmodifiable collection. On the other hand having a good implementation of persistent data structures in Smalltalk would be interesting to play withâ¦ My 2c Cheers Carlo Still, after stating all of the above, I have used Javaâs unmodifiable collections to prevent clients modifying results, especially when I know there is a chain of clients that may process this collection and perhaps modify the collection. On 13 May 2014, at 7:55 PM, Sergi Reyner <sergi.reyner(a)gmail.com> wrote: 2014-05-13 14:28 GMT+01:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: I wouldn't restrict having the option of direct manipulation of the collection, but it is a nice thing to have covered by some LINT rules. :) ThatÂ´s what I meant, in a convoluted way, with "they are crazy". For me, Java is about restrictions on restrictions on restrictions, which in the end donÂ´t feel like giving me any advantage. In this case, if I want to modify the returned collection it should be my business. I may have a reason to do so. Then again, Java is not a dynamic language and so on... :) Cheers, Sergi

May 13, 2014