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

Re: [Pharo-project] NB Capabilities

by Igor Stasenko

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

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. > 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-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] Read-only error on Jenkins again

by Camillo Bruni

if you have time enough try the new infrastructure. I think the old server is slowly dying, so I wouldn't trust it too much. On 2012-11-10, at 20:52, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > There is a read-only file system error on Jenkins again. > > Cheers, > -- Pavel >

Nov. 10, 2012

Re: [Pharo-project] NB Capabilities

by Jimmie Houchin

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] Writing 16 times 1mb to a WriteStream takes 1s. Normal?

by Igor Stasenko

On 10 November 2012 18:33, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Speed factor is 8x. > If you have no idea of required buffer size, you could try to modify > growth strategy in your own subclass. > The amount of extra free bytes allocated is currently 10 + (oldSize // > 4 max: 20). > See WriteStream>>#growTo: and its sender #nextPutAll:. > yeah , i think for large buffers it much better to use factor x2 growth newsize = oldsize *2 > Nicolas > > 2012/11/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> 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 >>> >> >> > -- Best regards, Igor Stasenko.

Nov. 10, 2012

Re: [Pharo-project] NativeBoost Win32 Examples

by Igor Stasenko

Cool, thanks a lot, Torsten! On 10 November 2012 18:20, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Igor, > > thanks for adding me to the NativeBoost repo. I uploaded some > basic samples for Win32 and adopted the config. > > In Pharo 2.0 one can load latest stable right from the world menu > "Tools" -> ConfigurationBrowser" -> "NativeBoost" > > > Here are some samples people can now play with: > > 1. Set the pharo window title > > NBWin32Window getFocus setWindowText: 'Set Pharo window title' > > 2. Access environment variables: > > NBWin32Shell getComputerName > NBWin32Shell getUserName > NBWin32Shell getWindowsDirectory > NBWin32Shell getNumberOfProcessors > ... > > 3. Access to control panel applets > > NBWin32Shell showODBCSettings > NBWin32Shell showControlPanel > ... > > 4. Open web pages, files, documents, ... > > NBWin32Shell shellBrowse: 'http://www.pharo-project.org' > NBWin32Shell shellExplore: 'c:\' > NBWin32Shell shellOpen: 'c:\pharo.pdf' > ... > > 5. Lock workstation > > NBWin32Shell lockWorkstation > > 6. Sends a string to the debugger for display: > > NBWin32Shell outputDebugString: 'Trace me' > > These outputs can be viewed with dbmon.exe from Microsoft > or DebugView > http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx > > Have fun! > > Bye > Torsten -- Best regards, Igor Stasenko.

Nov. 10, 2012

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

by Nicolas Cellier

Speed factor is 8x. If you have no idea of required buffer size, you could try to modify growth strategy in your own subclass. The amount of extra free bytes allocated is currently 10 + (oldSize // 4 max: 20). See WriteStream>>#growTo: and its sender #nextPutAll:. Nicolas 2012/11/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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] Read-only error on Jenkins again

by Marcus Denker

On Nov 10, 2012, at 4:52 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > There is a read-only file system error on Jenkins again. > I will ping support, but that will only lead to a reaction Monday. We should start to migrate the the new setup. Marcus -- Marcus Denker -- http://marcusdenker.de

Nov. 10, 2012

[Pharo-project] NativeBoost Win32 Examples

by Torsten Bergmann

Hi Igor, thanks for adding me to the NativeBoost repo. I uploaded some basic samples for Win32 and adopted the config. In Pharo 2.0 one can load latest stable right from the world menu "Tools" -> ConfigurationBrowser" -> "NativeBoost" Here are some samples people can now play with: 1. Set the pharo window title NBWin32Window getFocus setWindowText: 'Set Pharo window title' 2. Access environment variables: NBWin32Shell getComputerName NBWin32Shell getUserName NBWin32Shell getWindowsDirectory NBWin32Shell getNumberOfProcessors ... 3. Access to control panel applets NBWin32Shell showODBCSettings NBWin32Shell showControlPanel ... 4. Open web pages, files, documents, ... NBWin32Shell shellBrowse: 'http://www.pharo-project.org' NBWin32Shell shellExplore: 'c:\' NBWin32Shell shellOpen: 'c:\pharo.pdf' ... 5. Lock workstation NBWin32Shell lockWorkstation 6. Sends a string to the debugger for display: NBWin32Shell outputDebugString: 'Trace me' These outputs can be viewed with dbmon.exe from Microsoft or DebugView http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx Have fun! Bye Torsten

Nov. 10, 2012

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

by Sven Van Caekenberghe

On 10 Nov 2012, at 21:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> 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. I vote for Markdown, it is more like a defacto standard. And you can convert Markdown into anything, there exit tons of tools for it. Remember that I sent you my Zinc & Zodiac docs converted to Latex ? Were they no good ? -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Nov. 10, 2012