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

Re: [Pharo-dev] Pharo - [ANN] SimpleDDS v1.0 released.

by S Krish

Nice work.. ! DDS = Corba repackaged. Hopefully for the better... need to dig in to see how easy it is now. On Tue, Dec 2, 2014 at 3:41 AM, Santiago Bragagnolo < santiagobragagnolo(a)gmail.com> wrote: > Hi guys, i am just releasing SimpleDDS. > > In order to connect into ROS world i had to implement a DDS support > (Publisher/subscriber). > > For achieving this i did MetaDDS, a library that defines basic objects, > announcements, event related mechanisms and data encoding formats, and on > top of it SimpleDDS, which is ROS based. > > SimpleDDS Has a package of examples highly commented for learning how to > use it. > > The comments are also in the Github wiki, as wiki pages: > > https://github.com/sbragagnolo/SimpleDDS/wiki > > Gofer it smalltalkhubUser: 'sbragagnolo' project: 'SimpleDDS'; > configuration; loadVersion: #stable > > > > Here some links about > > http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern > > http://en.wikipedia.org/wiki/Data_Distribution_Service > > > Thats it. Enjoy. > > Santiago > > > > >

Dec. 2, 2014

Re: [Pharo-dev] default fonts changed in Pharo 4.0

by Yuriy Tymchuk

Cool > On 02 Dec 2014, at 09:48, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > We changed the default fonts in Pharo for the ones that are used normally in Moose. > They are: Source Sans Pro and Source Code Pro. > We needed to do it for several reasons: > > 1) TxText (the new text model) is cairo based, and cairo just can work with real fonts, so we need them as default (now we will be able to integrate TxText and start the replace of old editors) > 2) Current fonts takes too much space and do not scales fine (at least that Iâve been told) > > So, well, thatâ¦ you will see âsomething differentâ when you download latest image version :) > > cheers, > Esteban > >

Dec. 2, 2014

Re: [Pharo-dev] Scale in 3.0 (kind of ANN)

by phil＠highoctane.be

Looks like dead and superseded by the .st handler. But this is not coral with classdefs etc. Phil Le 2 dÃ©c. 2014 09:49, "Luc Fabresse" <luc.fabresse(a)gmail.com> a Ã©crit : > > Nice but I would like to know the exact status of Coral because it would > be bad to restart from scratch. > > #Luc > > 2014-12-02 8:38 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> I've put Guille's Scale thing ( >> http://guillep.github.io/blog/2014/01/23/replacing-bash-with-pharo/) >> into Pharo 3.0 >> >> Details on how to use here: >> >> http://smalltalkhub.com/#!/~philippeback/Scale >> >> Enjoy, >> Phil >> >> >> >> >

Dec. 2, 2014

Re: [Pharo-dev] [Vm-dev] Re: NativeBoost

by Torsten Bergmann

Hi Eliot, Â first: my post and the three given points were not intended to bash your work or what others have done. I know about the hard work on your and others side to improve the situation. I do not doubt that FFI or Alien is stable or used in (Squeak) commercial applications. Note that my post was written on the pharo-dev list so within the context of Pharo. Not Squeak or others. So I can only tell from the point of view of someone who is from time to time in need in accessing/interfacing with "the outside world". Â Let me explain where I got my impressions from: after the last work on FFI package in 2011 by you, Andreas (R.I.P.) and Matthew for Squeak I commited some changes in 2012 to get FFI running in Pharo again. After that there was no activity on the project, at least not in its repo. StillÂ there was and is a config to load FFI into Pharo 3.0. This is accessible from config browser and so far I have onlyÂ seen that ODBC package is using it. To my knowledge there is no config for Alien in the config browser. So while Alien may work in Squeak there is noÂ out of the box experience in Pharo so far.Â It was hard to find a VM/image/plugin combination. Others like Joachim Geidel with JNIPort had similar problems (see [1]) and switched over to Native Boost. So "not maintained very well" is IMHO true within the Pharo context until this situation is improved here and I would welcome any effort on this. >From "end user experience" NB is currently more accessible (as it was integrated) and documented also in books so I guess that is the reason that it was and is used more. Some Pharo projects switched over to NB or initially started with it: there is a NB version of DBXTalk, Athens,Â NBSQLite3, WHTML2PDF, NBOpenGL,Â LibGit,Â ... to name just a few. Also if I remember there was the plan to have NB working also on other architectures: beside the regular AsmJit-x86 there is also an AsmJit-ARM package. I guess that mostly the reason for not driving this forward is the same as on the FFI/Alien side: the lack of time and resources. I did not know that FFI was now really revived from your side as part of your Spur efforts. I did not know about ConfigurationOfOldAlien. I also did not know about the unification layer/Uniform Foreign Function Interface (UFFI) project in detail. A portable common FFI layer would be more than welcomed. I'm sure we are all interested in improving the situation, cant tell anything about synchronization/unfication efforts or barriers on each side as I'm only get my impressions from reading on the mailing list. I hope participating people will resynchronize so we can move forward. I now learned that there is some activity again - which is good! Thanks T. Â [1]Â http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2014-March/011… Â Gesendet:Â Mittwoch, 26. November 2014 um 23:48 Uhr Von:Â "Eliot Miranda" <eliot.miranda(a)gmail.com> An:Â "Squeak Virtual Machine Development Discussion" <vm-dev(a)lists.squeakfoundation.org> Cc:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] [Vm-dev] Re: NativeBoost Hi Esteban, Â On Tue, Nov 25, 2014 at 11:30 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote:Â Â On 25 Nov 2014, at 20:27, Markus Fritsche <mfritsche@reauktion.de[mfritsche@reauktion.de]> wrote:Â Â On Tue, Nov 25, 2014 at 5:06 AM, Torsten BergmannÂ <astares@gmx.de[astares@gmx.de]>Â wrote:Please enlighten me as well. I also do not yet understand the idea of this unification layer. Â "Unification layer" is just a name.Â IMO Ronie is doing something much more useful.Â He is architecting the marshalling layer of the FFI so that it canÂ - be portable - work in both the Cog JIT and the Interpreter This is effectively an abstract instruction set for executing low-level machine intsructions.Â It can be used for FFI call-out marshalling, but it can also be used for low-level code generation, and we are using it in Sista.Â COnsequently Ronie's "Low code" as it is properly called can be an integral component to both a high-quality FFI and a fast VM. Â For me this is a useful substrate for an FFI that can be high quality.Â But note that it is only one component.Â The other components are - an image-level ABI compiler whose job it is to generate the correct marshalling code for different platforms.Â The FFI for processors such as IA64/x86-64 is complex, and a compiler is the only performant way to generate correct marshalling code - callback machinery.Â I have already designed and implemented this in the context of Alien.Â The architecture is portable; it can function correctly on x86-64 and ARM, not just x86. Â So far we have Â 1. FFIÂ Â -> not maintained very well, no callbacks Â This is simply false.Â The FFI was in active use at Qwaq where Cog was first implemented.Â I have continued to maintain and enhance it, reimplementing it so that it is a pure Smalltalk plugin with no assembler support code, so that it is reentrant.Â Recently Doug McPherson has implemented the ARM version alongside my original x86 version. Â yep, Iâm aware and I was trying to have time to bring those changes into Pharo. Hopefully soon. Â Â Â Â 2. Alien -> should provide the callbacks, hard to find a predefined package/VM combination Â Every Cog VM supports Alien callbacks.Â The Alien packageÂ Alien-eem.24 atÂ http://www.squeaksource.com/Alien[http://www.squeaksource.com/Alien]Â "jsut works", at least in Squeak.Â Try it. Â Â it works.Â We have ConfigurationOfOldAlien that loads all required (Is a bad name I choose because there was your sources and a fork from Luc and there were not in sync, so I took your sources and made a Configuration for them :P)Â Â Â 3. NativeBoost was supposed to be the better one, was based on AsmJit and replace 1. and 2. Â I disagree.Â NativeBoost has not been designed with portability in mind, nor has it been designed with interpretive VMs in mind.Â Further Igor made no attempt to work with me in providing the support he needs from Cog to integrate NativeBoost when I visited Rmod early this year. Â Â According to my knowledge it was the goal to continue with NB, integrate it (which is done) and move it forward as the single solution for external calls and callbacks. So why do we need another layer (and mixed approach with still old FFI) instead of working on bringing NB to the other platforms as well and work on a good NativeBoost. Wasn't there already work for AsmJit for ARM? Â We have a functional FFI at the moment, FFI + Alien for callbacks.Â This is in industrial use, both at Terf (nee Qwaq) and Cadence.Â We have NativeBoost that does not work on ARM.Â We have Ronie's work on low code that fits both with a well-architected FFI and with Sista. Â I am frustrated that there is no coherence in our work here.Â I have a clear understanding of what architecture can work, a clear vision, and yet other than Ronie, all I see is FUD ("Alien doesn't work", "FFI doesn't work", "Alien callbacks don't work"; all false).Â I wish this wasn't the case.Â I do not have time right now to work on all of Spur, Spur 64, Sista and find time to architect the FFI.Â But I know how this stuff works (I've implemented what works now) and as the leads VM architect isn't it right that the community try and work with me rather than without me? Â Honestly, Iâm quite frustrated too.Â And I cannot agree with you more.Â Â thanks, Esteban.Â I find this extremely reassuring. Â But hopefully we will start to work on this problem and remove all discordances soon (I know in all other VM aspects we already did it and now we work aligned, so we can do this for FFI tooâ¦ in fact last month I wanted to work on it but then other work became more urgent).Â Â Esteban Â Â Thx T. > Gesendet: Dienstag, 25. November 2014 um 10:01 Uhr > Von: "Markus Fritsche" <mfritsche@reauktion.de[mfritsche@reauktion.de]> > An: "Pharo Development List" <pharo-dev@lists.pharo.org[pharo-dev@lists.pharo.org]> > Betreff: Re: [Pharo-dev] NativeBoost > > On 2014-11-24 23:34, Esteban Lorenzano wrote: > > > now, since the most common use of NB is for FFI, and NB is not present > > in all platforms, we are working (Ronie, in this case) in a âunified > > FFIâ, which will provide a common abstraction layer for several FFI > > frameworks (NB, OldFFI, Alienâ¦). With that, we can choose which one > > of the frameworks we use depending on the situation (but ideally, we > > will maintain just one, the one that fits better in Pharo). > > I feel that providing a common abstraction layer on top of the various > approaches to interface to C/ C++ libraries won't be useful and should > be considered a waste of resources. From what I understood from the > documentation, NativeBoost seems to be the most complete interface > technology yet. I would rather (as in: If I was capable) try to get > NativeBoost into Squeak and add the functionality missing that still > justifies the existence of FFI and Alien than creating an abstraction > layer that can't cope with the differences in the tools (which was the > reason for their first creation despite the available ones). > > I tried to play around with FFI and creating plugins in Squeak and > failed (I didn't try very hard though). NativeBoost was the first thing > I was able to wrap a DLL myself and understand how to do it. The only > thing that I wasn't able to wrap my mind around was finalization, but > that is also due to the fact that I couldn't find understandable (read: > understandable to me) documentation about the underlying concept in > Pharo. > > (OT: Finalization and concurrency probably is more about the concept > rather than the implementation in Pharo?) > > This is a piece of opinion. We all know, that unfortunately, one doesn't > have to have knowledge to have an opinion, so if my opinion is wrong due > to lack of knowledge, please ignore it. > > Best regards, >Â Â Markus > > > Â Â Â --Â best, EliotÂ Â -- best, Eliot

Dec. 2, 2014

Re: [Pharo-dev] Pharo - [ANN] SimpleDDS v1.0 released.

by CÃ©drick BÃ©ler

This is excellent :) I just wonder how it compare to DDP (Data Distribution Protocol) wich seems https://meteorhacks.com/introduction-to-ddp.html http://en.wikipedia.org/wiki/Distributed_Data_Protocol ruby client: https://github.com/tmeasday/ruby-ddp-client <https://github.com/tmeasday/ruby-ddp-client> Thans by the way, Iâll try Simple DDS. Cheers, CÃ©drick > Le 2 dÃ©c. 2014 Ã 09:16, Luc Fabresse <luc.fabresse(a)gmail.com> a Ã©crit : > > > This is great. > Fo info, DDS is a standardized MOM middleware heavily used in industrial apps with multiple concrete implementations such as http://www.prismtech.com/opensplice <http://www.prismtech.com/opensplice>. > And one of these implementations will be the next backend of ROS and therefore needed in PhaROS. > Thx Santiago! > > #Luc > > 2014-12-02 0:44 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: > Santiago Bragagnolo wrote: > Hi guys, i am just releasing SimpleDDS. > In order to connect into ROS world i had to implement a DDS support (Publisher/subscriber). > For achieving this i did MetaDDS, a library that defines basic objects, announcements, event related mechanisms and data encoding formats, and on top of it SimpleDDS, which is ROS based. > > SimpleDDS Has a package of examples highly commented for learning how to use it. > The comments are also in the Github wiki, as wiki pages: > > https://github.com/sbragagnolo/SimpleDDS/wiki <https://github.com/sbragagnolo/SimpleDDS/wiki> > > Gofer it smalltalkhubUser: 'sbragagnolo' project: 'SimpleDDS'; configuration; loadVersion: #stable > > > Here some links about > http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern <http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern> > > http://en.wikipedia.org/wiki/Data_Distribution_Service <http://en.wikipedia.org/wiki/Data_Distribution_Service> > > > Thats it. Enjoy. > > Santiago > > > > > > I haven't heard of DDS, but this seems really significant! > > From wikipedia... "DDS addresses the needs of applications like financial trading, air-traffic control, smart grid management, and other Big data applications. The standard is used in applications such as smartphone operating systems,[1] transportation systems and vehicles,[2] software-defined radio, and by healthcare providers." > > This could be a nice lead into these application domains. > > If this got to a sufficient level of features, maybe Santiago could even be sponsored to attend an interoperability meeting? "DDS vendors participated in _Interoperability demonstrations_ at the Object Management Group (OMG) Spring Technical Meeting.[7] During the demo, each vendor publishes and subscribes to each other's topics using a test suite called the Shapes Demo." Such might be a good place to network and demo general use of Pharo. > > cheers -ben > >

Dec. 2, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by kilon alios

"I prefer the Smalltalk environment." so do I "Sorry, if that would be true then Java or C# would be of extraordinary quality. Smalltalk has been there for more than 30 years and will probably another 30 years. Hypes come and go. Quantity for me seems more like the opposite of quality." True ? Smalltalk cannot even begin to compete with the tools and library support of these two behemoths programming languages. That does not mean Java is not ugly or that some of the complain people have with it are not valid and justified complains but still does not change the fact that because of the size of the community it has produced a lot more top quality libraries and tools than any programming language. The "quantity brings quality" is not just a computer world rule its pretty much the fabric of our cosmos that through failures and bad designs more elegant and beautiful , sophisticate designs emerge. Its something that has been happening for billions of years and I doubt will change any time soon. "Why shouldn't they be able to die? products that can be used by everybody. Alas for your work needs their operating systems get worse with every release. Windows XP and Snow Leopard are being seen as the best versions by some... Nothing lasts forever so you can be sure that Windows and Mac OSX will die some day." Win XP is the crappiest OS I ever used win 7 dances around it , its still old crappy windows but way way better. Yosemite has its share of issues but for me so far with the excepetion of problematic CUDAS drivers, had no issues at all with it. I use also UBUNTU 14.04 it offers better support for my system and works like a charm. I seriously dont see this "OS get worse thing". Will one day those OS die ? sure but I doubt I will be alive so there is no reason for me to worry about it. "That's also possible in capitalism: you can ask very high prices so most people and companies cannot (or will not) be able to affort it" I am not going to debate capitalism and its problems, of course I agree that huge companies care only about making money and not for the well being of the consumers. This is why I am here , this is why I support open source and this is why I support Pharo but I cant just turn zealot and refuse the usefulness and expertise of much commercial software out there. All I said is that if there is demand there is going to be supply. Everybody wants to make money and this is why when and if a software dies it gets replaced by something else often better alternative. "For me Smalltalk is a system and not a simple language with some arbitrary tools that can be replaced easily." Its not as hard as you may think to kinda emulate Smalltalk with other programming languages. Actually Pharo has some fierce competition out there as languages are more and more interested into live coding and creating an enviroment for the developer. Smalltalk still has the edge on this because it had an early start but if the example of Swift is any indication its definetly a lesson that languages have not any issue catching up with the Smalltalk world. The question is not if but when other languages come side by side with the abilities of Pharo how you keep pharo developers with pharo ? I think the only answer is by making sure Pharo remains fresh , modern and in sync with modern technology. Git is just a small part of the equation. On the other hand you need also , what Pharo already does to a great extend, innovation to bring new more developers. So I think the right balance is "give something new but also allow me to use my old familiar tools". I am very glad that people behind Pharo realise and materialse this balance. On Mon, Dec 1, 2014 at 9:46 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> My comment was not about discussing the pros and cons of closed versus >> open source software. My concerns are more about reliability. >> For me it's totally Ok to use git for versioning IF the tools are there. >> Squak and Pharo have decent versioning systems that suit their internal >> needs. There is room for improvements, that's for sure. >> For me Smalltalk is a system and not a simple language with some >> arbitrary tools that can be replaced easily. >> >> > The problem is whether the tools you choose for "commoditized" tasks (e.g. > SCM) limit the amount of manpower that could contribute to your open > source project. > > Forks and pull-requests are the way most open source projects fix bugs and > integrates enhancements. You can't do branching with current tooling (read: > Monticello) without suffering proportional to its complexity. > > No one said tools can be replaced easily, and that's the reason we still > use Monticello, some of us backed by old mcz files, others already using > some git behind it. > > Regards, > > > >

Dec. 2, 2014

Re: [Pharo-dev] Fwd: [squeak-dev] IdentitySet>>collect:

by stepharo

What is the old behavior? In addition it would be good to have tests for such core library. Stef Le 1/12/14 11:44, Sven Van Caekenberghe a Ã©crit : > > >> Begin forwarded message: >> >> *From: *Bert Freudenberg <bert(a)freudenbergs.de >> <mailto:bert@freudenbergs.de>> >> *Subject: **Re: [squeak-dev] IdentitySet>>collect:* >> *Date: *1 Dec 2014 11:35:00 CET >> *To: *The general-purpose Squeak developers list >> <squeak-dev(a)lists.squeakfoundation.org >> <mailto:squeak-dev@lists.squeakfoundation.org>> >> *Reply-To: *The general-purpose Squeak developers list >> <squeak-dev(a)lists.squeakfoundation.org >> <mailto:squeak-dev@lists.squeakfoundation.org>> >> >> On 01.12.2014, at 07:35, Colin Putney <colin(a)wiresong.com >> <mailto:colin@wiresong.com>> wrote: >>> >>> On Sun, Nov 30, 2014 at 6:20 AM, Bert Freudenberg >>> <bert(a)freudenbergs.de <mailto:bert@freudenbergs.de>> wrote: >>> >>> How would you define âtypeâ here? Same class? >>> >>> >>> Yes, same class. It might be reasonable to answer instances of >>> analogous classes for weak collections, and expect the caller to use >>> #collect:as: if they want to retain weakness. >>> >>> Colin >> >> Thatâs certainly simple: >> >> âcollect: returns a collection of the same class as the receiver, >> except for weak collections, which answer non-weak equivalents. To >> return a collection of a different class, use collect:as:" >> >> - Bert - > > The above definition makes perfect sense to me. The default should be > simple and predictable, the more complex and special cases can be > handled by a more convoluted API. > > And we should change callers that depend on the old behaviour. > > Sven > > >

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by stepharo

Can you just tell me a bit more :) Le 2/12/14 08:45, phil(a)highoctane.be a Ã©crit : > I have made Ian Piumarta's GST GetOpt work in Pharo 3.0 > > See: > > http://www.smalltalkhub.com/#!/~philippeback/GetOpt > <http://www.smalltalkhub.com/#%21/%7Ephilippeback/GetOpt> > > Nice tool even if we have some other support in CommandLineHandlers. > But for a quick parameters setting in your own CommandLineHandler, it > is fast to use and easy to debug. > > Phil > > >

Dec. 2, 2014

Re: [Pharo-dev] Scale in 3.0 (kind of ANN)

by Luc Fabresse

Nice but I would like to know the exact status of Coral because it would be bad to restart from scratch. #Luc 2014-12-02 8:38 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > I've put Guille's Scale thing ( > http://guillep.github.io/blog/2014/01/23/replacing-bash-with-pharo/) into > Pharo 3.0 > > Details on how to use here: > > http://smalltalkhub.com/#!/~philippeback/Scale > > Enjoy, > Phil > > > >

Dec. 2, 2014

default fonts changed in Pharo 4.0

by Esteban Lorenzano

Hi, We changed the default fonts in Pharo for the ones that are used normally in Moose. They are: Source Sans Pro and Source Code Pro. We needed to do it for several reasons: 1) TxText (the new text model) is cairo based, and cairo just can work with real fonts, so we need them as default (now we will be able to integrate TxText and start the replace of old editors) 2) Current fonts takes too much space and do not scales fine (at least that Iâve been told) So, well, thatâ¦ you will see âsomething differentâ when you download latest image version :) cheers, Esteban

Dec. 2, 2014