November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Opening a serial Port with Pharo on Linux

by Luc Fabresse

2012/11/11 Friedrich Dominicus <frido(a)q-software-solutions.de> > Luc Fabresse <luc.fabresse(a)gmail.com> writes: > > > > > Did you tried: > > > > sPort := SerialPort new. > > sPort close. > > sPort openPort: '/dev/ttyS0'. > No, but now I did and with a symbolic link > from /dev/ttyUSB0 to /dev/ttyS0 I get this thing opened? > I do not understand why you need a symlink. > > Well I can not see why this should be "expected". > Because you said previously that: "If I'm trying the other approach (making a symbolc link to /dev/ttyS0 I can open the port and get my informations back." So I understood that your device is accessible through /dev/ttyS0. And why not trying to access it directly? Perhaps I did not get what you meant. Cheers, Luc > > Regards > Friedrich > >

Nov. 11, 2012

Re: [Pharo-project] NB Capabilities

by Frank Shearar

On 10 November 2012 23:33, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Hello Frank, > > > On 11/10/2012 4:05 PM, Frank Shearar wrote: >> >> On 10 November 2012 21:42, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >>> >>> On 11/10/2012 11:03 AM, Igor Stasenko wrote: >>>> >>>> It is too much imo.. >>>> Clojure->java -> c++ >>>> >>>> i would just write C++ code >>> >>> The API is either Java or C++ or .NET. >>> I agree that no sane person would go Clojure->Java->C++ :) >> >> Why? It's all just bytecodes on a JVM. And Clojure is a _much_ nicer >> language than Java. > > > What I was referencing is that no one would want to use Clojure to interface > with Java in order to access code in a C++ DLL. I agree that Clojure is > nicer than Java. > >>> Clojure would provide the option of interfacing natively the Java API, >>> without having to write Java. But then I am left developing in Clojure, >>> unless I decide to serve to Pharo via http/websockets. >> >> But you'd still need to write something here, to expose the API via >> HTTP, so you can't escape the net completely. > > Yes, I understand. Not trying to avoid the net. What I was stating is that I > would either write my entire application in Clojure, or I would write the > part which accesses FXCM's API and serve it to Pharo via http/websockets. > Currently I have a Python/COM setup which serves my Pharo app via http. > >>> As I do not currently know Java or Clojure or C++, it currently seemed >>> like >>> learning Clojure as the optimal path of least resistance. >>> >>> That is with a belief that I could learn Clojure better, easier, faster >>> than >>> C++, or at least a sufficient subset of C++ to work with NB. >> >> I think going the Clojure route makes more sense, but I am strongly >> biased towards functional programming languages. It is a simpler >> language to learn than Java, yet one that provides much richer >> libraries. You won't, for instance, have to write a for loop to >> iterate over a collection. Just read "reduce" and think "inject: >> into:" and you're halfway there. >> >> frank > > I like Clojure, but I really, really like Smalltalk/Pharo. I also have > significant time and code in Pharo which would have be rewritten in Clojure > should I choose a Clojure route. So currently I really favor solutions which > keep me in Pharo. I do like Clojure as the best non-Pharo solution. Of course! I meant that if you had to write in another language, Clojure seems much more attractive than either Java or C++. frank > Jimmie >

Nov. 11, 2012

Re: [Pharo-project] Opening a serial Port with Pharo on Linux

by Friedrich Dominicus

Luc Fabresse <luc.fabresse(a)gmail.com> writes: > > Did you tried: > > sPort := SerialPort new. > sPort close. > sPort openPort: '/dev/ttyS0'. No, but now I did and with a symbolic link from /dev/ttyUSB0 to /dev/ttyS0 I get this thing opened? Well I can not see why this should be "expected". Regards Friedrich

Nov. 11, 2012

Re: [Pharo-project] unpacking cairo.tgz fails during VM build

by Igor Stasenko

On 8 November 2012 11:42, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> Is this a known issue, or my "tar" install is wrong? >> >> yes it is known.. >> i had to install 7z support for tar. >> this is because MacOS is number of years behind the most recent release of tar, >> which supports 7z compressing by default :) > > so that has to be installed on OSX or not? > If we should update the HOWTOBUILD accordingly? > what i did is installed new tar from ports. i don't know why cairo people decided that switching to 7z compression for their sources is right time. (if you look at releases, they did this recently) >> And with your config, i am not sure that default MacOS installation >> having unxz utility installed. >> If yes, then , of course it makes sense to change config to what is >> proposed by you. >> And if not, then it is better to leave a note in class & methods >> comments to indicate that people should >> install more recent tar utility. > -- Best regards, Igor Stasenko.

Nov. 11, 2012

Re: [Pharo-project] What did you guys do to startup-time ?

by Igor Stasenko

On 8 November 2012 12:00, <Miloslav.Raus(a)cuzk.cz> wrote: > Who snuffed the poor guy ? I donât know what magic (yea, i know, not just > one magic, bunch of magix really ;-) you did but ... I downloaded Pharo 2.0 > to give it a whirl (I love smalltalk and keep playing with it / write an app > in it every once in a while), unzipped it, doble clicked the binary and the > window jumped me so fast i nearly fell of my chair (a positive WTF moment > ;-). > hmm.. i never observed anything other than that before. > > > And not just old Mr. Startup Time, you killed Lady Delay too. I remember > squeak / older pharo versions feeling a bit sluggish (a slight delay between > clicking and the menu popping up / whatever), but now it is blazing fast. > recently we found one very bad issue with rectangle(s), causing reporting wrong damage on screen (means forcing redraw of unnecessary areas on screen).. so there's a lot to do.. > > > Just saying âGreat workâ would be an understatement / denigration. > > > > * rausm deeply bows in silent awe -- Best regards, Igor Stasenko.

Nov. 11, 2012

Re: [Pharo-project] TimeProfiler and primitives

by Igor Stasenko

On 10 November 2012 13:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Nov 10, 2012, at 1:01 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> >> On Sat, Nov 10, 2012 at 3:46 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: >> Do you have the same issue if you use the Qwaq profiler here: >> >> Www.squeaksource.com/SystemProfilerPharo.html >> >> >> That was what I was looking for!!! >> Indeed, much better results :) Thanks Paul. >> Now I wonder, can we merge the changes from this SystemProfiler into the standard TimeProfiler? >> I would love to have only (correcy) onw. >> Maybe you can help with this task? ;) >> > > Make sure to check the license first.. everything Qwaq is GPL, which is quite a strange > license in the context of Smalltalk... > means copy-pasting the code will make you illegal. > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > -- Best regards, Igor Stasenko.

Nov. 11, 2012

Re: [Pharo-project] NB Capabilities

by Igor Stasenko

On 10 November 2012 19:34, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > I am considering C++. I know that it is the favorite among quants. I also > know it would open up a world of libraries and code. > http://en.wikipedia.org/wiki/Quantitative_analyst > > When you say make a VM plugin are talking about not using NB? > I am not quite sure what you are talking about doing. I would like to > understand better. the VM plugin is a module written in C, which provides own set of primitives, which you can use in a language. There's a lot of plugins for VM existing. I think you can find some sources if you google for 'squeak plugin', also i did some slides for smalltalk summer school (http://rmod.lille.inria.fr/web/pier/blog/2011-01-23) you can find videos and slides here: http://rmod.lille.inria.fr/web/pier/blog/2011-10-18 > Regarding the wrapper, is that a wrapper around the DLL? not necessary DLL, but in most cases, yes. > Any education on how to do what you are talking about would be greatly > appreciated. Enough to get me going in the right direction with links or > something. > > I have not read the documentation regarding writing a C++ app yet, as I do > not know C++. > > I'll have to see what I need to do to learn C++. :) > > I agree that this would be the most efficient way with regards to the > application. If it is within reason educationally close in time spent to > Clojure time educationally, I would definitely consider this direction. I > realize anything like this is just a guess and estimate as to my ability to > learn either Clojure or C++. > > Thanks for the encouragement and education. > > Jimmie > > > On 11/10/2012 4:12 PM, Igor Stasenko wrote: >> >> Hi, Jimmie >> i took a brief look at the library and interfaces it provides. >> To my opinion, if i would need to use it, i'd rather make a VM plugin for >> it. >> First, since its C++, and you need to write wrapper, making wrapper as >> a VM plugin >> is better than just another C library which you need to link via FFI. >> >> Connecting to java: yes its possible, but then it means that you will >> have a java runtime >> in your process, which is much heavyweight.. >> Just want to say, that if efficiency is issue, i would go for VM plugin. >> >> But since you are not me, the price of learning C++/Java may be too >> high, and i understand why >> you looking for alternatives. But in your place i would advise you to >> learn C++ basics. It will open a door >> to other languages of C family (because of similar syntax & rules). >> You may/will need it one day anyways :) >> >> On 10 November 2012 18:42, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >>> >>> On 11/10/2012 11:03 AM, Igor Stasenko wrote: >>>> >>>> It is too much imo.. >>>> Clojure->java -> c++ >>>> >>>> i would just write C++ code >>> >>> >>> The API is either Java or C++ or .NET. >>> I agree that no sane person would go Clojure->Java->C++ :) >>> >>> Clojure would provide the option of interfacing natively the Java API, >>> without having to write Java. But then I am left developing in Clojure, >>> unless I decide to serve to Pharo via http/websockets. >>> >>> As I do not currently know Java or Clojure or C++, it currently seemed >>> like >>> learning Clojure as the optimal path of least resistance. >>> >>> That is with a belief that I could learn Clojure better, easier, faster >>> than >>> C++, or at least a sufficient subset of C++ to work with NB. >>> >>> If I could learn a subset of C++ sufficient to interface NB/Pharo with >>> ForexConnect, then I would be happy to do so. >>> >>> http://forexforums.dailyfx.com/forexconnect/392705-forexconnect-api-subscri… >>> Especially if I had a roadmap to help provide me with said proficiency >>> and >>> that I could do so in equal or less time than spending with Clojure. >>> It is a pragmatic decision. Long term I want to spend my time in Pharo >>> and >>> not in Clojure or C++, which is why I am attempting what at the moment >>> requires the least effort or at least by best guess appears to be so. >>> >>> I have found nothing that I can program and interactively explore and >>> experiment with better that Smalltalk/Pharo. It is most definitely my >>> preference to do so. And I so greatly appreciate all of the efforts being >>> made to make it an option more of the time. >>> >>> JavaConnect that StÃ©phane mentioned looks very interesting. >>> >>> I really appreciate your input into this. I can gauge the effort to learn >>> Clojure and I find it reasonable. C++ seems from the outside to be more >>> daunting. I could be wrong. Let me know if you have a different opinion. >>> >>> Thanks. >>> >>> Jimmie >>> >> >> > > -- Best regards, Igor Stasenko.

Nov. 10, 2012

Re: [Pharo-project] NB Capabilities

by Jimmie Houchin

Hello Frank, On 11/10/2012 4:05 PM, Frank Shearar wrote: > On 10 November 2012 21:42, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> On 11/10/2012 11:03 AM, Igor Stasenko wrote: >>> It is too much imo.. >>> Clojure->java -> c++ >>> >>> i would just write C++ code >> The API is either Java or C++ or .NET. >> I agree that no sane person would go Clojure->Java->C++ :) > Why? It's all just bytecodes on a JVM. And Clojure is a _much_ nicer > language than Java. What I was referencing is that no one would want to use Clojure to interface with Java in order to access code in a C++ DLL. I agree that Clojure is nicer than Java. >> Clojure would provide the option of interfacing natively the Java API, >> without having to write Java. But then I am left developing in Clojure, >> unless I decide to serve to Pharo via http/websockets. > But you'd still need to write something here, to expose the API via > HTTP, so you can't escape the net completely. Yes, I understand. Not trying to avoid the net. What I was stating is that I would either write my entire application in Clojure, or I would write the part which accesses FXCM's API and serve it to Pharo via http/websockets. Currently I have a Python/COM setup which serves my Pharo app via http. >> As I do not currently know Java or Clojure or C++, it currently seemed like >> learning Clojure as the optimal path of least resistance. >> >> That is with a belief that I could learn Clojure better, easier, faster than >> C++, or at least a sufficient subset of C++ to work with NB. > I think going the Clojure route makes more sense, but I am strongly > biased towards functional programming languages. It is a simpler > language to learn than Java, yet one that provides much richer > libraries. You won't, for instance, have to write a for loop to > iterate over a collection. Just read "reduce" and think "inject: > into:" and you're halfway there. > > frank I like Clojure, but I really, really like Smalltalk/Pharo. I also have significant time and code in Pharo which would have be rewritten in Clojure should I choose a Clojure route. So currently I really favor solutions which keep me in Pharo. I do like Clojure as the best non-Pharo solution. Jimmie

Nov. 10, 2012

Re: [Pharo-project] NB Capabilities

by Jimmie Houchin

I am considering C++. I know that it is the favorite among quants. I also know it would open up a world of libraries and code. http://en.wikipedia.org/wiki/Quantitative_analyst When you say make a VM plugin are talking about not using NB? I am not quite sure what you are talking about doing. I would like to understand better. Regarding the wrapper, is that a wrapper around the DLL? Any education on how to do what you are talking about would be greatly appreciated. Enough to get me going in the right direction with links or something. I have not read the documentation regarding writing a C++ app yet, as I do not know C++. I'll have to see what I need to do to learn C++. :) I agree that this would be the most efficient way with regards to the application. If it is within reason educationally close in time spent to Clojure time educationally, I would definitely consider this direction. I realize anything like this is just a guess and estimate as to my ability to learn either Clojure or C++. Thanks for the encouragement and education. Jimmie On 11/10/2012 4:12 PM, Igor Stasenko wrote: > Hi, Jimmie > i took a brief look at the library and interfaces it provides. > To my opinion, if i would need to use it, i'd rather make a VM plugin for it. > First, since its C++, and you need to write wrapper, making wrapper as > a VM plugin > is better than just another C library which you need to link via FFI. > > Connecting to java: yes its possible, but then it means that you will > have a java runtime > in your process, which is much heavyweight.. > Just want to say, that if efficiency is issue, i would go for VM plugin. > > But since you are not me, the price of learning C++/Java may be too > high, and i understand why > you looking for alternatives. But in your place i would advise you to > learn C++ basics. It will open a door > to other languages of C family (because of similar syntax & rules). > You may/will need it one day anyways :) > > On 10 November 2012 18:42, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> On 11/10/2012 11:03 AM, Igor Stasenko wrote: >>> It is too much imo.. >>> Clojure->java -> c++ >>> >>> i would just write C++ code >> >> The API is either Java or C++ or .NET. >> I agree that no sane person would go Clojure->Java->C++ :) >> >> Clojure would provide the option of interfacing natively the Java API, >> without having to write Java. But then I am left developing in Clojure, >> unless I decide to serve to Pharo via http/websockets. >> >> As I do not currently know Java or Clojure or C++, it currently seemed like >> learning Clojure as the optimal path of least resistance. >> >> That is with a belief that I could learn Clojure better, easier, faster than >> C++, or at least a sufficient subset of C++ to work with NB. >> >> If I could learn a subset of C++ sufficient to interface NB/Pharo with >> ForexConnect, then I would be happy to do so. >> http://forexforums.dailyfx.com/forexconnect/392705-forexconnect-api-subscri… >> Especially if I had a roadmap to help provide me with said proficiency and >> that I could do so in equal or less time than spending with Clojure. >> It is a pragmatic decision. Long term I want to spend my time in Pharo and >> not in Clojure or C++, which is why I am attempting what at the moment >> requires the least effort or at least by best guess appears to be so. >> >> I have found nothing that I can program and interactively explore and >> experiment with better that Smalltalk/Pharo. It is most definitely my >> preference to do so. And I so greatly appreciate all of the efforts being >> made to make it an option more of the time. >> >> JavaConnect that StÃ©phane mentioned looks very interesting. >> >> I really appreciate your input into this. I can gauge the effort to learn >> Clojure and I find it reasonable. C++ seems from the outside to be more >> daunting. I could be wrong. Let me know if you have a different opinion. >> >> Thanks. >> >> Jimmie >> > >

Nov. 10, 2012

Re: [Pharo-project] NB Capabilities

by Igor Stasenko

On 10 November 2012 19:05, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 10 November 2012 21:42, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >> On 11/10/2012 11:03 AM, Igor Stasenko wrote: >>> >>> It is too much imo.. >>> Clojure->java -> c++ >>> >>> i would just write C++ code >> >> >> The API is either Java or C++ or .NET. >> I agree that no sane person would go Clojure->Java->C++ :) > > Why? It's all just bytecodes on a JVM. And Clojure is a _much_ nicer > language than Java. > i don't know the details of Clojure implementation. but i know that the longer the tool chain , the more problems you may have, because every link adds own complexity into soup. >> Clojure would provide the option of interfacing natively the Java API, >> without having to write Java. But then I am left developing in Clojure, >> unless I decide to serve to Pharo via http/websockets. > > But you'd still need to write something here, to expose the API via > HTTP, so you can't escape the net completely. > >> As I do not currently know Java or Clojure or C++, it currently seemed like >> learning Clojure as the optimal path of least resistance. >> >> That is with a belief that I could learn Clojure better, easier, faster than >> C++, or at least a sufficient subset of C++ to work with NB. > > I think going the Clojure route makes more sense, but I am strongly > biased towards functional programming languages. It is a simpler > language to learn than Java, yet one that provides much richer > libraries. You won't, for instance, have to write a for loop to > iterate over a collection. Just read "reduce" and think "inject: > into:" and you're halfway there. > yeah.. i do not know anything about closure, to say anything for/against it, except one which i said in previous mail. > frank > -- Best regards, Igor Stasenko.

Nov. 10, 2012