- Pharo-dev - lists.pharo.org

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

by stepharo

Indeed and we should build on top of Scale (adding coral syntax). Just no time for doing it. Tx phil to port Scale and publish it. In fact the commandline handler came for Camillo as a first step for Coral. Le 2/12/14 10:36, phil(a)highoctane.be a Ã©crit : > > 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 > <mailto:luc.fabresse@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 > <mailto:phil@highoctane.be> <phil(a)highoctane.be > <mailto:phil@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 > <http://smalltalkhub.com/#%21/%7Ephilippeback/Scale> > > Enjoy, > Phil > > > >

Dec. 2, 2014

Re: [Pharo-dev] GetOpt

by phil＠highoctane.be

Well, after looking at the command line handlers in the image for the way options are handled, I was of opinion that I wanted something like getopt. So, I looked around and found that implementation of Ian that I plugged into the CommandLineArguments in my activate methods. I like the dictionary + block approach I have quite a couple commands (like --create-user -u xxx -p xxx -e xxx -n xxx -g xxx) and it was a pain to write the options parsing. So, something like this in my XXToolsCommandLineHandler activate ... self activateCreateUser ... activateCreateUser GetOpt new at: $u put: [ :opt :arg | userName := arg ]; at: $p put: [ :opt :arg | ... ]; at: $e put: [ :opt :arg | ... ]; at: $n put: [ :opt :arg | ... ]. at: $g put: [ :opt :arg | ... ]; parse: self arguments. "wrapped in some error handling" XXTools makeUserNames: userName ... No more need to dig into a number of isXXXX methods and optionAt:... I think we should make this work with more integration etc but I have other fish to fry at the moment and this works well for me. We need more doc on the CommandLineHandlers but it is a fantastic piece of Pharo! Combined with a small image, it would be a terrific tool. I am investing some time on those CLI things as I need them for servers and even if Bash is cool for some things, Pharo is better in terms of cleanliness. One factor is the time taken for loading the image. Maybe should we look into something like a pharod, a daemon that would just run scripts and a lightweight CLI tool that would pass the scripts to it. Something like: http://www.martiansoftware.com/nailgun/ I think we could steal their C client right away/ Phil On Tue, Dec 2, 2014 at 10:17 AM, stepharo <stepharo(a)free.fr> wrote: > 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] GetOpt

by Christophe Demarey

See https://en.wikipedia.org/wiki/Getopt Le 2 dÃ©c. 2014 Ã 10:17, stepharo a Ã©crit : > 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] default fonts changed in Pharo 4.0

by Santiago Bragagnolo

Great!! I am sooo happy, we are moving forward! 2014-12-02 10:41 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > 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] Pharo - [ANN] SimpleDDS v1.0 released.

by Santiago Bragagnolo

Hi Cedric, thanks. As far as i know, (im not quite versed on DDP), DDP starts with the base that you have data distributed, and that you have kind of actors or RPC arhitecture. That means that you will call methods to remote servers, and that may cause changes. That changes will be notified to subscriptors, like this you can replicate the data or do what ever you want with the changes. In the design of an application, your services interact by sending messages, and everyone can be noticed by the notifications. In DDS you send, commonly, the output of your processing, hoping someone will use it for something. No one needs to understand anything about your implementation and the system keeps working with your process or without (meanwhile is not the master, weakpoint). A cool metaphor may be that DDP is like a ford assembly line, DDS is like a powerline or network. i hope it helps you 2014-12-02 10:31 GMT+01:00 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: > 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 > > 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. > 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>: > >> 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 >>> >>> 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 >>> >>> >>> >>> >>> >> 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] 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