[Pharo-project] NB Capabilities
I am developing an application which needs to access a proprietary business API to access data from their servers. Currently because I don't know how to do that from within Pharo, I have been using Python/COM. But that API is deprecated and expires soon. Now I have to move to an app which accesses via either a C/C++ app which accesses a DLL, a .NET library or a Java jar. There are a number of objects that have to be created from the dll/jar, and a number of interfaces which have to be implemented from the dll/jar. Presently I am studying Clojure in order to work from the Java side. I do not know Clojure or Java. If I could learn sufficient C and do this with NB in Pharo, that would be very nice. I have never done anything like what NB does, so I do not know what all it does or can do. Can Pharo implement the interfaces provided in the DLL in the Smalltalk side? Or would the interfaces have to be implemented on the C side and then Pharo access the objects? Any advise greatly appreciated. Thanks. Jimmie
On 11/8/2012 7:50 PM, Jimmie Houchin wrote:
I am developing an application which needs to access a proprietary business API to access data from their servers.
Currently because I don't know how to do that from within Pharo, I have been using Python/COM. But that API is deprecated and expires soon. Now I have to move to an app which accesses via either a C/C++ app which accesses a DLL, a .NET library or a Java jar.
There are a number of objects that have to be created from the dll/jar, and a number of interfaces which have to be implemented from the dll/jar. Presently I am studying Clojure in order to work from the Java side. I do not know Clojure or Java. If I could learn sufficient C and do this with NB in Pharo, that would be very nice.
I have never done anything like what NB does, so I do not know what all it does or can do.
Can Pharo implement the interfaces provided in the DLL in the Smalltalk side? Or would the interfaces have to be implemented on the C side and then Pharo access the objects?
Any advise greatly appreciated.
Thanks.
Jimmie On a second look at the API's documentation, the DLL is C++ not C. I don't know, but that might have been evident by the requirement of implementing interfaces.
I thought I would provide that information, just in case in has a big bearing NB/Pharo's ability and on my learning curve. Jimmie
On 8 November 2012 23:25, Jimmie Houchin <jlhouchin@gmail.com> wrote:
On a second look at the API's documentation, the DLL is C++ not C. I don't know, but that might have been evident by the requirement of implementing interfaces.
well, with C++ it is a bit worse than C: because C++ compilers use name mangling for the function names. Means that, if you will look for exported function 'abc()', you will probably find it under different name, like abc@nby_xrt apart from that, once you figure the exact correct name, you can go and call that function. Things is a bit different if the exported function is a member of class. So, what i can say.. you can try and see if it rolls (or rocks).. and if it not, then the best option would be to implement own wrapper library (but this time in C). And then use that library from pharo.
I thought I would provide that information, just in case in has a big bearing NB/Pharo's ability and on my learning curve.
Jimmie
-- Best regards, Igor Stasenko.
The COM API is deprecated and no longer supported. Only the C++ API is what is available for use from Pharo. On 11/8/2012 11:31 PM, Igor Stasenko wrote:
On 8 November 2012 23:25, Jimmie Houchin <jlhouchin@gmail.com> wrote:
On a second look at the API's documentation, the DLL is C++ not C. I don't know, but that might have been evident by the requirement of implementing interfaces. well, with C++ it is a bit worse than C: because C++ compilers use name mangling for the function names. Means that, if you will look for exported function 'abc()', you will probably find it under different name, like abc@nby_xrt
How does one go about discovering these names?
apart from that, once you figure the exact correct name, you can go and call that function.
Things is a bit different if the exported function is a member of class.
So, what i can say.. you can try and see if it rolls (or rocks).. and if it not, then the best option would be to implement own wrapper library (but this time in C). And then use that library from pharo.
Ok, then this is the tricky part because I have a lot of C++ classes which are interfaces to be implemented and instances of those classes to be passed into other instances of other classes in the DLL. An example from the documentation. ''' An instance of the class implementing |IO2GSessionStatus| interface must be subscribed to the session object before calling IO2GSession <IO2GSession.html>::login <IO2GSession.login.html> method. It is accomplished by calling |IO2GSession| <IO2GSession.html>::|subscribeSessionStatus| <IO2GSession.subscribeSessionStatus.html> method. For example, ... ''' As it stands my options are to learn Clojure (which I am already in progress of doing) in order to access the API via Java. Or to learn C/C++ and NB to access the API from Pharo. I like Pharo, but I am not sure at this point, if that is the easiest or best option. I am concerned about learning just enough C++ to shoot myself in the foot. I am also concerned that the C/C++ route will take much more significant learning than Clojure. Going with Clojure does not automatically rule out Pharo. Depending on how much I like or don't like dealing with Clojure/Java and whether or not I would want to implement the rest of my application there. I could also choose to use it to serve the API via http/websockets to a Pharo application. Thanks for your help. Jimmie
On 9 November 2012 12:19, Jimmie Houchin <jlhouchin@gmail.com> wrote:
The COM API is deprecated and no longer supported. Only the C++ API is what is available for use from Pharo.
On 11/8/2012 11:31 PM, Igor Stasenko wrote:
On 8 November 2012 23:25, Jimmie Houchin <jlhouchin@gmail.com> wrote:
On a second look at the API's documentation, the DLL is C++ not C. I don't know, but that might have been evident by the requirement of implementing interfaces.
well, with C++ it is a bit worse than C: because C++ compilers use name mangling for the function names. Means that, if you will look for exported function 'abc()', you will probably find it under different name, like abc@nby_xrt
How does one go about discovering these names?
This is best what i found, read to end: https://www.ruby-forum.com/topic/173158
apart from that, once you figure the exact correct name, you can go and call that function.
Things is a bit different if the exported function is a member of class.
So, what i can say.. you can try and see if it rolls (or rocks).. and if it not, then the best option would be to implement own wrapper library (but this time in C). And then use that library from pharo.
Ok, then this is the tricky part because I have a lot of C++ classes which are interfaces to be implemented and instances of those classes to be passed into other instances of other classes in the DLL.
An example from the documentation. ''' An instance of the class implementing IO2GSessionStatus interface must be subscribed to the session object before calling IO2GSession::login method. It is accomplished by calling IO2GSession::subscribeSessionStatus method. For example, ... '''
As it stands my options are to learn Clojure (which I am already in progress of doing) in order to access the API via Java. Or to learn C/C++ and NB to access the API from Pharo.
googling didn't gave me any examples how Clojure deals with C++... have a link? i suspect it is like others, generating wrapper C code to call C++ code.
I like Pharo, but I am not sure at this point, if that is the easiest or best option. I am concerned about learning just enough C++ to shoot myself in the foot. I am also concerned that the C/C++ route will take much more significant learning than Clojure.
Going with Clojure does not automatically rule out Pharo. Depending on how much I like or don't like dealing with Clojure/Java and whether or not I would want to implement the rest of my application there. I could also choose to use it to serve the API via http/websockets to a Pharo application.
Thanks for your help.
Jimmie
-- Best regards, Igor Stasenko.
On 11/9/2012 7:22 PM, Igor Stasenko wrote:
On 9 November 2012 12:19, Jimmie Houchin <jlhouchin@gmail.com> wrote:
The COM API is deprecated and no longer supported. Only the C++ API is what is available for use from Pharo.
On 11/8/2012 11:31 PM, Igor Stasenko wrote:
On 8 November 2012 23:25, Jimmie Houchin <jlhouchin@gmail.com> wrote:
On a second look at the API's documentation, the DLL is C++ not C. I don't know, but that might have been evident by the requirement of implementing interfaces.
well, with C++ it is a bit worse than C: because C++ compilers use name mangling for the function names. Means that, if you will look for exported function 'abc()', you will probably find it under different name, like abc@nby_xrt
How does one go about discovering these names?
This is best what i found, read to end:
https://www.ruby-forum.com/topic/173158
apart from that, once you figure the exact correct name, you can go and call that function.
Things is a bit different if the exported function is a member of class.
So, what i can say.. you can try and see if it rolls (or rocks).. and if it not, then the best option would be to implement own wrapper library (but this time in C). And then use that library from pharo.
Ok, then this is the tricky part because I have a lot of C++ classes which are interfaces to be implemented and instances of those classes to be passed into other instances of other classes in the DLL.
An example from the documentation. ''' An instance of the class implementing IO2GSessionStatus interface must be subscribed to the session object before calling IO2GSession::login method. It is accomplished by calling IO2GSession::subscribeSessionStatus method. For example, ... '''
As it stands my options are to learn Clojure (which I am already in progress of doing) in order to access the API via Java. Or to learn C/C++ and NB to access the API from Pharo.
googling didn't gave me any examples how Clojure deals with C++... have a link? i suspect it is like others, generating wrapper C code to call C++ code.
Clojure does not access the C++ code. It would access the Java library in its .jar file. It has native access. The API is offered in three forms, Java, .NET and C++. Jimmie
Jimmie did you look at JavaConnect? This is on our roadmap for Moose in December January. So that we can connect better to Java. Stef On Nov 10, 2012, at 3:40 AM, Jimmie Houchin wrote:
On 11/9/2012 7:22 PM, Igor Stasenko wrote:
On 9 November 2012 12:19, Jimmie Houchin <jlhouchin@gmail.com> wrote:
The COM API is deprecated and no longer supported. Only the C++ API is what is available for use from Pharo.
On 11/8/2012 11:31 PM, Igor Stasenko wrote:
On 8 November 2012 23:25, Jimmie Houchin <jlhouchin@gmail.com> wrote:
On a second look at the API's documentation, the DLL is C++ not C. I don't know, but that might have been evident by the requirement of implementing interfaces.
well, with C++ it is a bit worse than C: because C++ compilers use name mangling for the function names. Means that, if you will look for exported function 'abc()', you will probably find it under different name, like abc@nby_xrt
How does one go about discovering these names?
This is best what i found, read to end:
https://www.ruby-forum.com/topic/173158
apart from that, once you figure the exact correct name, you can go and call that function.
Things is a bit different if the exported function is a member of class.
So, what i can say.. you can try and see if it rolls (or rocks).. and if it not, then the best option would be to implement own wrapper library (but this time in C). And then use that library from pharo.
Ok, then this is the tricky part because I have a lot of C++ classes which are interfaces to be implemented and instances of those classes to be passed into other instances of other classes in the DLL.
An example from the documentation. ''' An instance of the class implementing IO2GSessionStatus interface must be subscribed to the session object before calling IO2GSession::login method. It is accomplished by calling IO2GSession::subscribeSessionStatus method. For example, ... '''
As it stands my options are to learn Clojure (which I am already in progress of doing) in order to access the API via Java. Or to learn C/C++ and NB to access the API from Pharo.
googling didn't gave me any examples how Clojure deals with C++... have a link? i suspect it is like others, generating wrapper C code to call C++ code.
Clojure does not access the C++ code. It would access the Java library in its .jar file. It has native access. The API is offered in three forms, Java, .NET and C++.
Jimmie
It is too much imo.. Clojure->java -> c++ i would just write C++ code On 10 November 2012 05:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Jimmie
did you look at JavaConnect? This is on our roadmap for Moose in December January. So that we can connect better to Java.
Stef
On Nov 10, 2012, at 3:40 AM, Jimmie Houchin wrote:
On 11/9/2012 7:22 PM, Igor Stasenko wrote:
On 9 November 2012 12:19, Jimmie Houchin <jlhouchin@gmail.com> wrote:
The COM API is deprecated and no longer supported. Only the C++ API is what is available for use from Pharo.
On 11/8/2012 11:31 PM, Igor Stasenko wrote:
On 8 November 2012 23:25, Jimmie Houchin <jlhouchin@gmail.com> wrote:
On a second look at the API's documentation, the DLL is C++ not C. I don't know, but that might have been evident by the requirement of implementing interfaces.
well, with C++ it is a bit worse than C: because C++ compilers use name mangling for the function names. Means that, if you will look for exported function 'abc()', you will probably find it under different name, like abc@nby_xrt
How does one go about discovering these names?
This is best what i found, read to end:
https://www.ruby-forum.com/topic/173158
apart from that, once you figure the exact correct name, you can go and call that function.
Things is a bit different if the exported function is a member of class.
So, what i can say.. you can try and see if it rolls (or rocks).. and if it not, then the best option would be to implement own wrapper library (but this time in C). And then use that library from pharo.
Ok, then this is the tricky part because I have a lot of C++ classes which are interfaces to be implemented and instances of those classes to be passed into other instances of other classes in the DLL.
An example from the documentation. ''' An instance of the class implementing IO2GSessionStatus interface must be subscribed to the session object before calling IO2GSession::login method. It is accomplished by calling IO2GSession::subscribeSessionStatus method. For example, ... '''
As it stands my options are to learn Clojure (which I am already in progress of doing) in order to access the API via Java. Or to learn C/C++ and NB to access the API from Pharo.
googling didn't gave me any examples how Clojure deals with C++... have a link? i suspect it is like others, generating wrapper C code to call C++ code.
Clojure does not access the C++ code. It would access the Java library in its .jar file. It has native access. The API is offered in three forms, Java, .NET and C++.
Jimmie
-- Best regards, Igor Stasenko.
It is too much imo.. Clojure->java -> c++
i would just write C++ code
I was not talking about calling clojure code but if the library is exposed in java. Stef
On 10 November 2012 05:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Jimmie
did you look at JavaConnect? This is on our roadmap for Moose in December January. So that we can connect better to Java.
Stef
On Nov 10, 2012, at 3:40 AM, Jimmie Houchin wrote:
On 11/9/2012 7:22 PM, Igor Stasenko wrote:
On 9 November 2012 12:19, Jimmie Houchin <jlhouchin@gmail.com> wrote:
The COM API is deprecated and no longer supported. Only the C++ API is what is available for use from Pharo.
On 11/8/2012 11:31 PM, Igor Stasenko wrote:
On 8 November 2012 23:25, Jimmie Houchin <jlhouchin@gmail.com> wrote:
On a second look at the API's documentation, the DLL is C++ not C. I don't know, but that might have been evident by the requirement of implementing interfaces.
well, with C++ it is a bit worse than C: because C++ compilers use name mangling for the function names. Means that, if you will look for exported function 'abc()', you will probably find it under different name, like abc@nby_xrt
How does one go about discovering these names?
This is best what i found, read to end:
https://www.ruby-forum.com/topic/173158
apart from that, once you figure the exact correct name, you can go and call that function.
Things is a bit different if the exported function is a member of class.
So, what i can say.. you can try and see if it rolls (or rocks).. and if it not, then the best option would be to implement own wrapper library (but this time in C). And then use that library from pharo.
Ok, then this is the tricky part because I have a lot of C++ classes which are interfaces to be implemented and instances of those classes to be passed into other instances of other classes in the DLL.
An example from the documentation. ''' An instance of the class implementing IO2GSessionStatus interface must be subscribed to the session object before calling IO2GSession::login method. It is accomplished by calling IO2GSession::subscribeSessionStatus method. For example, ... '''
As it stands my options are to learn Clojure (which I am already in progress of doing) in order to access the API via Java. Or to learn C/C++ and NB to access the API from Pharo.
googling didn't gave me any examples how Clojure deals with C++... have a link? i suspect it is like others, generating wrapper C code to call C++ code.
Clojure does not access the C++ code. It would access the Java library in its .jar file. It has native access. The API is offered in three forms, Java, .NET and C++.
Jimmie
-- Best regards, Igor Stasenko.
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-subscrib... 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
On 10 November 2012 21:42, Jimmie Houchin <jlhouchin@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.
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. frank
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-subscrib... 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
On 10 November 2012 19:05, Frank Shearar <frank.shearar@gmail.com> wrote:
On 10 November 2012 21:42, Jimmie Houchin <jlhouchin@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.
Hello Frank, On 11/10/2012 4:05 PM, Frank Shearar wrote:
On 10 November 2012 21:42, Jimmie Houchin <jlhouchin@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
On 10 November 2012 23:33, Jimmie Houchin <jlhouchin@gmail.com> wrote:
Hello Frank,
On 11/10/2012 4:05 PM, Frank Shearar wrote:
On 10 November 2012 21:42, Jimmie Houchin <jlhouchin@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
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.
I am going to disagree there with you. Especially if one comes from the family of C like language , he is going to find Clojure an alien planet at best. Now count into that as a non popular language the amount of books/tutorials/articles on it will be highly limited. Me learning Clojure has been far from smooth and easy and definetly not even remotely close as easy as learning Java and of course light year away as easy as learning python. Also I had the advantage of already studying briefly common lisp still I found learning Clojure much more challenging than I expected mainly because even though it pays tribute on its lisp heritage its a language by itself. I do agree though that is a very promising language for JVM and its certainly a must learn if you target the Java Machine , so recommending clojure is by no means a bad advice. However if one come to either lisp or smalltalk , he must be prepared for severing lacking not so well written and noob friendly documentation and mostly a complete lack of choices in that field. Saying that I like Clojure , I love common lisp and I adore smalltalk . I agree with you that functional programming at least in theory seems extremely tempting way to code.
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@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-subscrib... 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.
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@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-subscrib... 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
On 10 November 2012 19:34, Jimmie Houchin <jlhouchin@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@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-subscrib... 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.
Thanks Igor. I will have to explore this option when I get time. It seems a lot to learn. I have downloaded the videos and slides. I also downloaded Bruce Eckel's "Thinking in C++" books. And also thanks Stéphane for the reference the Greenberg pdf. Jimmie On 11/10/2012 5:35 PM, Igor Stasenko wrote:
On 10 November 2012 19:34, Jimmie Houchin <jlhouchin@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@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-subscrib... 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
On Nov 10, 2012, at 11:34 PM, Jimmie Houchin 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?
yes have a look at the chapter of the newBlueBook on my web site. It explains how to write a plugin (starting with an example returning 7) that you can then call from Pharo. http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/greenberg.pdf One day we should revisit it.
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@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-subscrib... 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
On 11/10/2012 2:30 AM, Stéphane Ducasse wrote:
Jimmie
did you look at JavaConnect? This is on our roadmap for Moose in December January. So that we can connect better to Java.
Stef
No I did not look at JavaConnect? I was not familiar with it. This looks like it would be awesome. The business world has lots of proprietary APIs available in Java. If we could open Pharo up to the Java world, that would be tremendous. From what I read, it appears that it has no problem handling Java interfaces. It appears that I could easily subclass a Java interface and implement the required methods and satisfy Java when passing the objects back to Java. This would be fantastic. I guess that there is potential of having something to play with by end of December, sometime January? No obligations, or promises of course. I haven't played with Moose yet. But I do look forward to it in the future. It looks like it could be a great tool for technical analysis of financial markets. Thanks for letting me know about this. I'll put Clojure on the shelf and shuffle the order in which I am implementing my application so that I can potentially use JavaConnect when available. Jimmie
On Nov 10, 2012, at 8:31 PM, Jimmie Houchin wrote:
On 11/10/2012 2:30 AM, Stéphane Ducasse wrote:
Jimmie
did you look at JavaConnect? This is on our roadmap for Moose in December January. So that we can connect better to Java.
Stef
No I did not look at JavaConnect? I was not familiar with it.
This looks like it would be awesome. The business world has lots of proprietary APIs available in Java. If we could open Pharo up to the Java world, that would be tremendous.
We need that for Moose too. Johan told me that this is working but need some ironing. There is also JNIPort
From what I read, it appears that it has no problem handling Java interfaces. It appears that I could easily subclass a Java interface and implement the required methods and satisfy Java when passing the objects back to Java.
This would be fantastic.
It was fully working on VisualWorks and we will work on it because this is important for us but not before december.
I guess that there is potential of having something to play with by end of December, sometime January? No obligations, or promises of course.
I haven't played with Moose yet. But I do look forward to it in the future. It looks like it could be a great tool for technical analysis of financial markets.
Thanks for letting me know about this. I'll put Clojure on the shelf and shuffle the order in which I am implementing my application so that I can potentially use JavaConnect when available.
Check also JNIport because this is a port of a way to connect with Java from dolphin. In fact johan and joachim worked in parallel :).
Jimmie
On 8 November 2012 22:50, Jimmie Houchin <jlhouchin@gmail.com> wrote:
I am developing an application which needs to access a proprietary business API to access data from their servers.
Currently because I don't know how to do that from within Pharo, I have been using Python/COM. But that API is deprecated and expires soon. Now I have to move to an app which accesses via either a C/C++ app which accesses a DLL, a .NET library or a Java jar.
There are a number of objects that have to be created from the dll/jar, and a number of interfaces which have to be implemented from the dll/jar. Presently I am studying Clojure in order to work from the Java side. I do not know Clojure or Java. If I could learn sufficient C and do this with NB in Pharo, that would be very nice.
I have never done anything like what NB does, so I do not know what all it does or can do.
It can do anything you can do :)
Can Pharo implement the interfaces provided in the DLL in the Smalltalk side?
Pharo can't , you can :) But if you talk about COM interfaces, then yes. It is doable. The only problem is, that it is not done by anyone.
Or would the interfaces have to be implemented on the C side and then Pharo access the objects?
AFAIK, COM is fairly simple. You need to do a lill parsing deciphering IDL interface, and frankly i don't remember all the details. But at the end, it is just a bunch of C calls. With NativeBoost you can do calls to C .. so it is doable. Again, Dolphin Smalltalk can use COM , so if it can be done there, i don't see why it is impossible to do the same in Pharo.
Any advise greatly appreciated.
Thanks.
Jimmie
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
AFAIK, COM is fairly simple. You need to do a lill parsing deciphering IDL interface, and frankly i don't remember all the details. But at the end, it is just a bunch of C calls. With NativeBoost you can do calls to C .. so it is doable.
Again, Dolphin Smalltalk can use COM , so if it can be done there, i don't see why it is impossible to do the same in Pharo.
well, Dolphin COM interface was written by two very bright chaps with intimate knowledge of their VM and system, good knowledge of windows and COM, over a rather long period. So I would say: - Doable: absolutely yes, - Feasible for someone who does not have solid experience in FFI and just needs to connect to this library so that he can do his real job: probably no. ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/NB-Capabilities-tp4654570p4654615.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (6)
-
dimitris chloupis -
drush66 -
Frank Shearar -
Igor Stasenko -
Jimmie Houchin -
Stéphane Ducasse