December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Kafka protocol

by Robert Withers

You're right of course; I made bad choice of words. It is challenging me to explain what I meant as there is something reasonable I am trying to say. I will try. We all have our own interests and projects we wish to achieve in Pharo. Often this means everyone is working on their own directions and interests and often this means working alone without a team-oriented project. People with similar interests will join efforts and plans. Other projects have been determined to align with pharo's core vision and BigTalk and discussion has yielded plans and work proceedeth collaboratively. I work on SecureSession and CryptOCaps as my own interests and I get much welcome help but they are my projects. I tr to talk about them in hopes others will use them, but it is my efforts which pay off. SecureSession is solid and usable. The realm of BigData is different. I have knowledge and experience there and I think it would be powerful for Pharo, but they aree not my main focus. If Pharo wishes to get into this space, it best be done collaboratively which requires some BigWords to coordinate. As they are not my main focus and needs collaboration, a team should form around it, whether it is in the PharoVision or not. This is where I think I misspoke, making it official. I wish I had twice the time available, to work CryptOCaps and BigData, but I do not. If nobody is interested in seeing how Pharo does with BigData there is not anything I can do nor could I offer my experienmces there to assist. My suggestions to form a BigData team around it, to coordinate and collaborate, fall short if there is no interest. I will stop encouraging this and refocus back on my work. My apologies for the distractions, Robert On 12/29/2015 07:20 AM, Dimitris Chloupis wrote: > Should be ? There is no "should be" it is what it is, if anyone wants > something more he is more than welcomed to stop writing to the mailing > list and use that time instead to sit his ass down and make the code . > The potential of Pharo is unlimited but taking advantage of it is hard > work and nothing else. BigData frameworks dont come from BigWords. > > I wanted Pharo to work with python and use python libraries . Did I > came to this mailing list to write that pharo "should be" able to use > python libraries, because python is super popular and its constantly > growing ? > > Nope ! > > I sat down my ass and worked hard to make it happen and I did > accomplish it. Still much to improve but there is no substitute to > hard work and putting the time to improve pharo. > > You wanna use Jars from Pharo , no problemo, work hard and do it. But > please dont tell me what should be in the vision of Pharo, why BigData > and not 3d graphics, why 3d graphics and not network libraries, why > network libraries and not more IDE tools, why IDE tools and not more > advanced language features, why advance language features and not a C > API , why C API and not web development frameworks ? > > In the end nothing , NOTHING , should be outside the scope of a > language that wants to call itself "turing complete" . No goal is > higher than something else. Each coders has different needs . What it > "Should be" is people that are willing to work hard to make THEIR OWN > NEEDS a reality using a tool THEY LOVE using. Its a choice. > > And a Stef so well says it > > Pharo is Yours > > On Mon, Dec 28, 2015 at 9:44 PM Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > > What I mean is that an undertaking of this scope should be in the > Vision > and on the roadman for Pharo, with a broader concerted commitment to > enterprise BigData integration. > > robert > > On 12/28/2015 02:29 PM, Robert Withers wrote: > > > > > > On 12/28/2015 12:19 PM, Frank Shearar wrote: > >> On 27 December 2015 at 16:11, Robert Withers > >> <robert.w.withers(a)gmail.com > <mailto:robert.w.withers@gmail.com>> wrote: > >>> This would be awesome in Pharo: > >>> > https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Prot…. > >>> > >>> Since we cannot yet call JARs, implementing the wire protocol > and API > >>> proxies would really be huge from an enterprise pharo > standpoint. If > >>> other > >>> folks are interested in working on this, I could help out. > >> Having a Kafka client in Pharo would indeed be awesome. But who > cares > >> about calling JARs? It's a wire protocol; write a client > against that > >> and you're done. > > > > Yes, although I would still like to load JARs, but for different > > reasons. That aside, yes implementing the wire protocol would be > > really happening. I'll help. I don't want to own it. It would > > definitely be enterprise. > > > > robert > > > > > >> > >> frank > >> > > > > -- > Robert > . .. ... ^,^ > > -- Robert . .. ... ^,^

Dec. 29, 2015

Re: [Pharo-dev] Kafka protocol

by Dimitris Chloupis

Should be ? There is no "should be" it is what it is, if anyone wants something more he is more than welcomed to stop writing to the mailing list and use that time instead to sit his ass down and make the code . The potential of Pharo is unlimited but taking advantage of it is hard work and nothing else. BigData frameworks dont come from BigWords. I wanted Pharo to work with python and use python libraries . Did I came to this mailing list to write that pharo "should be" able to use python libraries, because python is super popular and its constantly growing ? Nope ! I sat down my ass and worked hard to make it happen and I did accomplish it. Still much to improve but there is no substitute to hard work and putting the time to improve pharo. You wanna use Jars from Pharo , no problemo, work hard and do it. But please dont tell me what should be in the vision of Pharo, why BigData and not 3d graphics, why 3d graphics and not network libraries, why network libraries and not more IDE tools, why IDE tools and not more advanced language features, why advance language features and not a C API , why C API and not web development frameworks ? In the end nothing , NOTHING , should be outside the scope of a language that wants to call itself "turing complete" . No goal is higher than something else. Each coders has different needs . What it "Should be" is people that are willing to work hard to make THEIR OWN NEEDS a reality using a tool THEY LOVE using. Its a choice. And a Stef so well says it Pharo is Yours On Mon, Dec 28, 2015 at 9:44 PM Robert Withers <robert.w.withers(a)gmail.com> wrote: > What I mean is that an undertaking of this scope should be in the Vision > and on the roadman for Pharo, with a broader concerted commitment to > enterprise BigData integration. > > robert > > On 12/28/2015 02:29 PM, Robert Withers wrote: > > > > > > On 12/28/2015 12:19 PM, Frank Shearar wrote: > >> On 27 December 2015 at 16:11, Robert Withers > >> <robert.w.withers(a)gmail.com> wrote: > >>> This would be awesome in Pharo: > >>> > https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Prot… > . > >>> > >>> Since we cannot yet call JARs, implementing the wire protocol and API > >>> proxies would really be huge from an enterprise pharo standpoint. If > >>> other > >>> folks are interested in working on this, I could help out. > >> Having a Kafka client in Pharo would indeed be awesome. But who cares > >> about calling JARs? It's a wire protocol; write a client against that > >> and you're done. > > > > Yes, although I would still like to load JARs, but for different > > reasons. That aside, yes implementing the wire protocol would be > > really happening. I'll help. I don't want to own it. It would > > definitely be enterprise. > > > > robert > > > > > >> > >> frank > >> > > > > -- > Robert > . .. ... ^,^ > > >

Dec. 29, 2015

Re: [Pharo-dev] VM error in Arch Linux

by Ben Coman

On Tue, Dec 29, 2015 at 7:58 PM, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > Le 29/12/2015 04:03, Ben Coman a Ã©crit : >> There is a setting in PharoLauncher >> >> A different approach to workaround Pharo 5 alpha transition in image >> file format... >> 1. Download latest VM + Image >> http://pharo.org/download -- Development version: Pharo5 >> or, get.pharo.org ... 50+vmLatest >> >> 2. After opening image, from World Menu go Tools > Catalog Browser >> >> 3. Install Pharo Launcher >> >> 4. Start PharoLauncher from the World Menu >> >> Now I guess you will get the same in reverse, this wont open the old >> image format. It would be nice for PharoLauncher to handle multiple >> VMs, but in the meantime you may want to keep two PharoLauncher: Spur >> & pre-Spur. >> >> cheers -ben >> > > Hi Ben, > > With the development version of pharo launcher you can give a path to > the cog VM and a path to the spur VM. The launcher will know which image > need which VM. > > So with the development version of PharoLauncher you only need 1 version > to be able to launch all images. Nice. Thanks for the update Cyril. How soon will that be pushed to the Catalog Browser? Alternately, what individual packages would you recommend loading? (limited warranty accepted :) cheers -ben

Dec. 29, 2015

Re: [Pharo-dev] How to use ExternalAddress in callouts with new FFI?

by Esteban Lorenzano

> On 28 Dec 2015, at 23:11, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Mon, Dec 28, 2015 at 5:11 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > Hi Esteban, > > Previously, I was doing with NB something like this: > > pointer := NativeBoost allocate: 4. > self primitiveWhatever: pointer > > and: > > primitiveWhatever: pointer > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > > ^ self nbCall: #( int void (NBExternalAddress pointer ) ) > > > But of course that doesn't work with latest FFI. So I tried instead: > > pointer := ExternalAddress allocate: 4. > primitiveWhatever: pointer > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > > ^ self nbCall: #( int void (ExternalAddress pointer ) ) > > > It looks like if I set "void*" rather than ExternalAddress it does work. > Is this the expected path? so.. ExternalAddress *should* map to void* by it self. If it does not, there is a bug (please report :P) but yes, using void* as argument should work out of the box so should not get the error below (none of my tests caused that either, so I do not understand why it can happenâ¦ I guess something in your code I do not completely understand). in general, I recommend to use the C type (void*) instead the pharo type (ExternalAddress)â¦ the whole idea below NB was to provide an interfase where you can just copy and paste the C definition from a header fileâ¦ even if thatâs not the case all the time. Esteban > > > But then I get a ExternalAddress class #asExternalTypeOn: which is sent in FFICallout >> resolveType: > > Any idea how can I use ExternalAddress in the signature of the FFI primitive call? > What am I doing wrong? > > > > Thanks in advance, > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 29, 2015

Re: [Pharo-dev] How can I load GTDebugger in 5.0 ?

by Andrei Chis

I'm working now on a config for cleanly loading GTDebugger plus SUnit and bytecode extensions into Pharo 5. Hopefully it will be done by today or tomorrow. Cheers, Andrei On Tue, Dec 29, 2015 at 2:49 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I tried: > > Gofer it > smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'ConfigurationOfGTDebugger'; > load. > (Smalltalk at: #ConfigurationOfGTDebugger) loadBleedingEdge. > > > but that loads a hell of stuff I don't want...and conflicts and.. > > So.. how can I get simply GTDebugger with the SUnit extensions? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 29, 2015

Re: [Pharo-dev] VM error in Arch Linux

by Ferlicot D. Cyril

Le 29/12/2015 04:03, Ben Coman a Ã©crit : > There is a setting in PharoLauncher > > A different approach to workaround Pharo 5 alpha transition in image > file format... > 1. Download latest VM + Image > http://pharo.org/download -- Development version: Pharo5 > or, get.pharo.org ... 50+vmLatest > > 2. After opening image, from World Menu go Tools > Catalog Browser > > 3. Install Pharo Launcher > > 4. Start PharoLauncher from the World Menu > > Now I guess you will get the same in reverse, this wont open the old > image format. It would be nice for PharoLauncher to handle multiple > VMs, but in the meantime you may want to keep two PharoLauncher: Spur > & pre-Spur. > > cheers -ben > Hi Ben, With the development version of pharo launcher you can give a path to the cog VM and a path to the spur VM. The launcher will know which image need which VM. So with the development version of PharoLauncher you only need 1 version to be able to launch all images. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 29, 2015

Re: [Pharo-dev] Having Book section using Pillar?

by Damien Cassou

On December 27, 2015 9:59:06 PM GMT+01:00, "Ferlicot D. Cyril" <cyril.ferlicot(a)gmail.com> wrote: >there is not a Pillar syntax for that That's wrong. \part, \chapter, \section... are all handled the same way: configure headingLevelOffset to decide which number of exclamation marks corresponds to which latex command/HTML markup. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Dec. 29, 2015

Re: [Pharo-dev] VM error in Arch Linux

by Ben Coman

There is a setting in PharoLauncher A different approach to workaround Pharo 5 alpha transition in image file format... 1. Download latest VM + Image http://pharo.org/download -- Development version: Pharo5 or, get.pharo.org ... 50+vmLatest 2. After opening image, from World Menu go Tools > Catalog Browser 3. Install Pharo Launcher 4. Start PharoLauncher from the World Menu Now I guess you will get the same in reverse, this wont open the old image format. It would be nice for PharoLauncher to handle multiple VMs, but in the meantime you may want to keep two PharoLauncher: Spur & pre-Spur. cheers -ben On Sun, Dec 27, 2015 at 5:03 AM, SaÅ¡a JaniÅ¡ka <gour(a)atmarama.com> wrote: > On Uto, 2015-12-22 at 11:56 +0100, Ferlicot D. Cyril wrote: > >> Since last week a new VM is use for Pharo 5 beta. > > Beginning Pharo user here...I had the same problem on my Debian box: > > "This interpreter (vers. 6505) cannot read image file (vers. 6521)." > >> You need to download the new VM on http://files.pharo.org/vm/pharo-spu >> r32/. > > Then I downloaded the new VM image and tried to use it with latest Pharo > Launcher ('Bleeding Edge'), but now I get: > > "This interpreter (vers. 6521) cannot read image file (vers. 6505)." > > which is kind of catch-22 situation... > >> Then you need to update Pharo Launcher. > > ...and it looks that I do not have updated Pharo Launcher. > > >> For now the easiest way I think is to enable the development mode in >> PharoLauncher, go in Monticello, and load the last version of Pharo >> Launcher core. > > Tried that as well, but didn't work. > >> Later I think that a new release of Pharo Launcher will make thing >> easier. > > Let me say that the potential of Pharo Launcher is really great - it > allows (if I got it right) to have many development machines available > via different VMs, while still keeping developer's machine in sane state > which cannot be said when one does regular development with other > (mostly compiled) languages, which is "simply wonderful!". > > Now I wonder if you can provide any further hint how to resolve the > above? > > Is there a plan that in the future Pharo Launcher will become regular > part of 'normal' Pharo image? > > I know that probably there would be more luch with V4.0, but I simply > would like to try latest code eagerly anticipating the day to try 64bit > VM. > > Still, kudos to all Pharo devs for providing human development > environment in the days when things are going insane all around us. > > > Sincerely, > Gour > > -- > As a lamp in a windless place does not waver, so the transcendentalist, > whose mind is controlled, remains always steady in his meditation on the > transcendent self. > > > > >

Dec. 29, 2015

How can I load GTDebugger in 5.0 ?

by Mariano Martinez Peck

I tried: Gofer it smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTDebugger'; load. (Smalltalk at: #ConfigurationOfGTDebugger) loadBleedingEdge. but that loads a hell of stuff I don't want...and conflicts and.. So.. how can I get simply GTDebugger with the SUnit extensions? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Dec. 29, 2015

Re: [Pharo-dev] Preview of new FFI?

by Mariano Martinez Peck

On Wed, Dec 23, 2015 at 10:30 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > I guess Esteban is busy as he is with Stef in Togo. I started porting to > new FFI initial stuff and chatted with Esteban on Slack. > > When you use the latest Pharo 5 image (together with the spur VM) you > have the new FFI right inside. Athens is running already on the new FFI. > > NB is still not unloaded - but it will be unloaded soon. The idea is that > people can recover what they need afterwards. For some cases it should be > straightforward to convert. > > A short summary of my findings: > > - check the "FFI-NB" package in recent Pharo 5 images like Pharo 5 #50510 > as of today > The name is misleading - it is not the NativeBoost but the new FFI > - check the new classes in this package that are prefixed with "FFI" like > FFIExternalObject (replacement for NBExternalObject), > FFIExternalStructure > (replacement for NBExternalStructure), ... > - If you generate fields from a struct the accessors are not generated > into non-package "*generated-code-non-existing-package" but are now > generated into > method category "accessing structure variables" and will therefore be > part of your > MCZ code package > - #nbCall: and #nbCall:module: work for compatibility, I guess we should > add a deprecation > to them > - it is better to use ffiCall:, ffiCall:module: now > - there is no need to have a pragma with NativeBoostPlugin anymore, at > least it > worked for me without it just by using #ffiCall: ... > - there is a new repo: http://smalltalkhub.com/#!/~Pharo/FFI-NB since > last week, > but I guess the code in the image is more recent > > Besides the list mentioned by Torsten, these are the ones I found out: - You now need #ffiLibraryName rather than #nbLibraryNameOrHandle - The #free you should send when you manually #allocate: now clears (put all zeros) in the handle. That means, you must free AFTER having read the value (like getting the handle integer) and kept it. With NB, the #free would only free the external side but would keep the internal value in the handle. That was handy because you could free the resources in one level, pass around the pointer, and get the number later. - Previously, a FFI call to a function that answered an opaque (FFIExternalObject subclass) as return value, AND the answer was a NULL, then NB would answer nil to the FFI call rather than a FFIExternalObject subclass instance. Now, it answers a instance of the FFIExternalObject subclass, which answers true to #isNull. - Previously you could #allocate: and get a NBExternalAddress (a pointer) which could be passed around to a FFI call whose type in the FFI call signature was itself a NBExternalAddress. Right now it seems the new FFI signature must be specified with "void*" ?? > Problems I've experienced so far while trying to port my OS-Windows > project: > - FIICallout does not understand #optionAt:, no support for options like > #WinUnicode so far > - FFIExternalType sizeOf: #ulong failed > Yes, I would appreciate this too. I really need a "NBExternalType sizeOf: #ulong" so that we can easy the future transition to 64 bits. Right now I am hardcoding stuff ;) > - the spur VM for Windows does not include all latest fixes for Windows > VM, like > CTRL keys (https://pharo.fogbugz.com/f/cases/17289) > > Hope this helps a little bit until some more bugs are sorted out/a more > detailed info > for conversion is available. > > Bye > T. > > Gesendet: Mittwoch, 23. Dezember 2015 um 13:55 Uhr > Von: "Mariano Martinez Peck" <marianopeck(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Preview of new FFI? > > We are in the same boat. Even worst, I suspect I am using some parts of > ASMJIT which I guess won't be in new FFI, so I have on clue how I would > make that parts to work.... > > On Wed, Dec 23, 2015 at 9:16 AM, Pierce Ng <pierce(a)samadhiweb.com> > wrote:Hi, > > (For Esteban perhaps...) > > Is there an image/VM combo to preview the new FFI? I just made NBSQLite3 > work > with SQLcipher (for transparent database encryption) but don't want to > spend > any effort refactoring if I need to redo for the new FFI. > > Pierce > > -- > Mariano > http://marianopeck.wordpress.com[http://marianopeck.wordpress.com] > > -- Mariano http://marianopeck.wordpress.com

Dec. 28, 2015