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

Re: [Pharo-project] [ANN] Pharo Online Help 1.0

by StÃ©phane Ducasse

> As you may know I wrote the current "Pharo help" implementation which > you can access from the Help menu or via Yes and I still would like to convince people to write special Unitests tagged <public: #topic number: 3> to populate the help. > There is also no central "docu" point for someone who just downloaded > Pharo and want a "Quick start". Also I dislike that we are limited with > the in-image presentation style (text only) and that content is not > visible to Google, Bing, etc. Yes me too. This is why I want to write the next chapter of the book Deep into Pharo in a Pier syntax stored on SVN/Git but be able to generate html + latex (we did that for Seaside book) so it should be easy (just need time). > Packaging Seaside with the default Pharo image to serve help content > would be overkill - but there is always a leaner way. > Since Pharo 2.0 we have Zinc HTTP components within the image > (thanks Sven!) and I played a little bit with it. It is really easy > to setup/startup a webserver from Smalltalk now. :) > So I wrote a basic "HelpServer" and wrapped the nice "twitter bootstrap" > library. Code may be ugly and require some refactoring ... but it is > currently more a prove of concept. > > Attached is a screenshot of the result running in a web browser. Sweet. > What is it: the idea is that we server the documentation from within the > image but use the local webbrowser to display it. Since we soon integrate NativeBoost in Pharo 2.0 it is also easy to open the browser as soon as "Help" is requested from a menu. > > Serving for the web would also mean we could easily setup an image > online that displays the docu online for indexing by search engines etc. Yes :) > Where is the code: > > Next steps: > =========== > > 1. Lets discuss how we want to fill the "API help" section. I know that > there once was a project that generated static API help > (http://magaloma.seasidehosting.st) but we can now directly serve > from the live image. > > My current implementation allows to navigate from classes to > subclasses and superclasses - just to give you an idea. Maybe we > want to display only class comments or provide a real Smalltalk > browser within the webbrowser (similar to http://www.Amber-lang.net) > > 2. The section "Intro" is only a mock. I would like to see that people > can find short "Quick start" like tutorials here to start with > basic things like Smalltalk, Metacello, ... > > Maybe we can integrate a live and running ProfStef similar to > http://amber-lang.net/learn.html that is adopted to Pharo. But amber is not pharo and it has the limit of Javascript I would not do that. > > 3. Lets discuss how we want to describe the content "in-image" > for "serving on the web". Maybe with a "Markup to HTML translator" > - or a "WikiStyle to HTML" like help I want to use the pier syntax because I know that I can generate the correct latex with it for the books, and of course any kind of html and other formats. > My wish to Santa would be that Pharo 2.0 comes with a better and > nicer out-of-the-box documentation. For each package/project we should > have a common way to define/load/browse docu and tutorials so people > can just load and quick start without much hazzle. :) > The code repo is open for read and write - I would appreciate > comments, code contributions, help/tutorial content and ideas. > > Thanks > Torsten > <onlinehelp.png>

Nov. 10, 2012

[Pharo-project] Read-only error on Jenkins again

by Pavel Krivanek

Hi, There is a read-only file system error on Jenkins again. Cheers, -- Pavel

Nov. 10, 2012

Re: [Pharo-project] NB Capabilities

by StÃ©phane Ducasse

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 > > >

Nov. 10, 2012

Re: [Pharo-project] Writing 16 times 1mb to a WriteStream takes 1s. Normal?

by StÃ©phane Ducasse

But mariano two questions: - did it change something? - don't you have an idea of the chunk you will use for the increment? Stef On Nov 10, 2012, at 8:22 PM, Mariano Martinez Peck wrote: > > > On Sat, Nov 10, 2012 at 8:18 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Maybe pre-allocate the right size: > > ByteArray new: byteArray size * 16 streamContents: ... > > > Well, actually we are trying to do a streaming API for a compressor. So, 1) I don't exactly know the number "16" before hand and 2) doing that is exactly what we are trying to avoid (compress/decompress all together). Instead, we are doing some kind of streaming, compressing in blocks of say 1MB. But I was completely surprised when I saw the results.... > So there is nothing easy to improve? > > Nicolas > > 2012/11/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi guys: > > > > |byteArray| > > byteArray := (ByteArray new: 1024*1024). > > [ > > ByteArray streamContents: [:s | > > 16 timesRepeat: [ > > s nextPutAll:byteArray > > ] > > ] > > ] timeToRun > > > > Gives me around 1 second. Isn't that too much? or is it normal/expected? > > Anything I could improve? > > > > Thanks, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 10, 2012

Re: [Pharo-project] NB Capabilities

by Jimmie Houchin

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

Nov. 10, 2012

Re: [Pharo-project] Writing 16 times 1mb to a WriteStream takes 1s. Normal?

by Mariano Martinez Peck

On Sat, Nov 10, 2012 at 8:18 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Maybe pre-allocate the right size: > > ByteArray new: byteArray size * 16 streamContents: ... > > Well, actually we are trying to do a streaming API for a compressor. So, 1) I don't exactly know the number "16" before hand and 2) doing that is exactly what we are trying to avoid (compress/decompress all together). Instead, we are doing some kind of streaming, compressing in blocks of say 1MB. But I was completely surprised when I saw the results.... So there is nothing easy to improve? Nicolas > > 2012/11/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi guys: > > > > |byteArray| > > byteArray := (ByteArray new: 1024*1024). > > [ > > ByteArray streamContents: [:s | > > 16 timesRepeat: [ > > s nextPutAll:byteArray > > ] > > ] > > ] timeToRun > > > > Gives me around 1 second. Isn't that too much? or is it normal/expected? > > Anything I could improve? > > > > Thanks, > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- Mariano http://marianopeck.wordpress.com

Nov. 10, 2012

Re: [Pharo-project] Writing 16 times 1mb to a WriteStream takes 1s. Normal?

by Nicolas Cellier

Maybe pre-allocate the right size: ByteArray new: byteArray size * 16 streamContents: ... Nicolas 2012/11/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi guys: > > |byteArray| > byteArray := (ByteArray new: 1024*1024). > [ > ByteArray streamContents: [:s | > 16 timesRepeat: [ > s nextPutAll:byteArray > ] > ] > ] timeToRun > > Gives me around 1 second. Isn't that too much? or is it normal/expected? > Anything I could improve? > > Thanks, > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 10, 2012

[Pharo-project] Writing 16 times 1mb to a WriteStream takes 1s. Normal?

by Mariano Martinez Peck

Hi guys: |byteArray| byteArray := (ByteArray new: 1024*1024). [ ByteArray streamContents: [:s | 16 timesRepeat: [ s nextPutAll:byteArray ] ] ] timeToRun Gives me around 1 second. Isn't that too much? or is it normal/expected? Anything I could improve? Thanks, -- Mariano http://marianopeck.wordpress.com

Nov. 10, 2012

Re: [Pharo-project] NB Capabilities

by StÃ©phane Ducasse

> 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(a)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(a)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(a)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. >

Nov. 10, 2012

Re: [Pharo-project] NB Capabilities

by Igor Stasenko

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(a)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(a)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(a)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.

Nov. 10, 2012