November 2018 - Pharo-users

Problems with NeoCSV Package

by William L. Cleveland

I need to manually tag a large number of sentences choosing between a small, fixed number of short strings as tags for each sentence. I would like to do this with a Pharo GUI that displays sentences one at a time and permit choice of tags using radio buttons. The results need to be saved as a CSV file on the hard drive for further manipulations with python. As a first step, I used Excel to create a test CSV file with two sentences that was saved on the disk drive in the Pharo working directory. I have subsequently tried to import the sentences into Pharo 6.1 32 bit stable. This was done as follows. |workingDir reader result| workingDir := FileSystem disk workingDirectory. myFileName := 'MoonCSV.csv'. stream := workingDir/myFileName readStreamDo: [ :stream | stream contents]. reader := (NeoCSVReader new) separator: Character cr. The separator was changed from a comma to a cr because the inspector showed a cr, not a comma separating the two imported sentences. result := (reader on: stream). result upToEnd. This failed with the following error: Instance of ByteString doesnât understand #atEnd. I donât see how to proceed further. Also I am not clear on the best way to export the sentence and tags to the disk drive.. Any help would be appreciated. Lou Cleveland

Nov. 26, 2018

Problems with Firmata & Arduino UNO Clone

by William L. Cleveland

I have been unsuccessful in using an Arduino board with Pharo 6.1(32bit) and the Firmata package. The board is an Arduino Uno clone (ELEGOO UNO R3). The board appears to work fine with the Arduino IDE, which was tested with the BLINK program. The Standard Firmata Library appears to have been successfully uploaded to the board using the Arduino IDE. COM ports have been closed using SerialPort allInstancesDo: [:port|port close]. On Windows 10, SerialPort inspect shows that ports are closed. However, firmata := Firmata onPort: âCOM3â baudRate: 576000 failed due to failure to open COM3. The serial port name was obtained from the Arduino IDE Tools menu. The board choice was âArduino Unoâ. In MacOS 10.11.6, the same code generated a Cannot open comport message. Independently of Firmata, the following line of code SerialPort allInstancesDo: [:port| port close] generated the following error message: âInstance of BlockClosure did not understand #SerialPort. The same code worked fine in Windows. I am wondering if the SerialPort code in Pharo6.1 is sufficiently robust for a nonexpert programmer like myself, who only occasionally writes code for his own use. Previously, I wrote an application for a robotics project in 2008 using VisualWorks and the DLL&CConnect tool, which was quite successful. No more coding until just recently, when I started using Python. Would like to go back to Smalltalk if it is sufficiently robust. Any help would be appreciated. Lou Cleveland

Nov. 26, 2018

Re: [Pharo-users] Playing with Pharo 7

by Cyril Ferlicot D.

Le 26/11/2018 Ã 16:57, Konrad Hinsen a Ã©critÂ : > > Thanks for the pointer! Unfortunately all the documentation there > assumes way more familiarity with Smalltalk than I have. And even a lot > of familiarity with Metacello itself, as the documentation only explains > the latest functionality. > > The good news is that it refers to "Deep into Pharo", so I will download > that book and see if answers my questions. > > Konrad. > Hello, There is also a recent guide here: https://github.com/pharo-tips-and-tricks/pharo-tips-and-tricks/blob/master/… I don't know if it is more beginner friendly. Feedback is welcome. -- Cyril Ferlicot https://ferlicot.fr

Nov. 26, 2018

Re: [Pharo-users] question about FFI

by Esteban Lorenzano

> On 26 Nov 2018, at 11:14, Henrik Sperre Johansen via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> > Subject: Re: question about FFI > Date: 26 November 2018 at 11:14:26 CET > To: pharo-users(a)lists.pharo.org > > > Yuriy Babah wrote >> in Playground i'm doing: > * >> #(2 3) doWithIndex: [:each :i | xm at: i put: each]. >> #(3 4) doWithIndex: [:each :i | ym at: i put: each]. > * >> >> whot i'm doing wrong? > > So, you're putting 2 at index 2 of xm, and then writing 3 past end of array, > and in ym you're putting 3 and 4 at offsets past the end of array? > > It's a wonder your image didn't crash, rather than return interpolation of > the uninitialized valuesâ¦ He is not doing that. He is using #doWithIndex: So he is passing 2 at index 1 and 3 at index 2, then 3 at index 1 and 4 at index 2. Esteban > > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > >

Nov. 26, 2018

Re: [Pharo-users] Playing with Pharo 7

by Konrad Hinsen

Am 25.11.18 um 22:35 schrieb Paul DeBruicker: > For #1: > > Set up a Metacello Baseline for your project and then you can automatically > load your packages and settings into as many images as you like. > > https://github.com/Metacello/metacello Thanks for the pointer! Unfortunately all the documentation there assumes way more familiarity with Smalltalk than I have. And even a lot of familiarity with Metacello itself, as the documentation only explains the latest functionality. The good news is that it refers to "Deep into Pharo", so I will download that book and see if answers my questions. Konrad.

Nov. 26, 2018

Re: [Pharo-users] Tracking method in and out with MetaLinks

by Marcus Denker

> On 23 Nov 2018, at 15:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 23 Nov 2018, at 14:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >>> On 23 Nov 2018, at 13:40, Manuel Leuenberger <leuenberger(a)inf.unibe.ch> wrote: >>> >>> Hi, >>> >>> I stumbled upon another MetaLink scenario that I am unsure how to implement. I want to track method invocations, with receiver, arguments, selector, and return value (maybe even signaled exception). I can track the method input with a MetaLink installed on an RBMethodNode like this: >>> >>> MetaLink new >>> metaObject: [ :c | Transcript show: c receiver; show: c method selector; show: c arguments; cr ]; >>> selector: #value:; >>> arguments: #(context). >>> >>> and for returns with a MetaLink on RBReturnNodes like this: >>> >>> MetaLink new >>> metaObject: [ :v | Transcript show: v; cr ]; >>> selector: #value:; >>> arguments: #(value) >>> >>> The problem is though, that not all methods have explicit returns, and some mix explicit returns and self returns. I tried installed an #after MetaLink on a RBMethodNode, but this fails in many cases. Is there any way that I can instrument a method and track receiver, selector, arguments, and returned value (even if self) at the same time? >>> >> >> I am working now on making the #after work so that one can get with #value the return of the methodâ¦ >> >> I now have a version where it works for Message Sends correctly *and* were #after on Method works better (the compilation errors should be fixed). >> >> But #value for #after on Method needs some more workâ¦ soon! >> #value for methods should now work with this PR loaded: https://github.com/pharo-project/pharo/pull/2012 <https://github.com/pharo-project/pharo/pull/2012> This is implemented by compiling a wrapped method for #after (just as we do for primitives). Marcus

Nov. 26, 2018

Re: [Pharo-users] question about FFI

by Yuriy Babah

> FFIExamples > interpolationFunc_xm: xm getHandle > ym: ym getHandle > size: 2 > x: 2.5 . > cool! it worked !! Thank Esteban Lorenzano and everyone else )

Nov. 26, 2018

Re: [Pharo-users] question about FFI

by Esteban Lorenzano

Hi, > On 26 Nov 2018, at 09:28, Yuriy Babah <babah.yuriy06(a)gmail.com> wrote: > > Hi ! > > I'm trying to call a very simple function from C ++ lib, writed for the test. > function with prototype: > > extern "C" float interpolationFunc(float* xm, float* ym, int size, float x). > > In Pharo7 wrote: > FFIExamples class >> interpolationFunc_xm: xM ym: yM size: size x: x > ^ self ffiCall: #(float interpolationFunc #(float * xM , float * yM , int size , float x)) module: 'libinterpolationLib.so' > > in Playground i'm doing: > xm := FFIExternalArray externalNewType: 'float' size: 2. > ym := xm clone. > #(2 3) doWithIndex: [:each :i | xm at: i put: each]. > #(3 4) doWithIndex: [:each :i | ym at: i put: each]. > FFIExamples interpolationFunc_xm: xm pointer ym: ym pointer size: 2 x: 2.5 . This is incorrect. âxmâ and âymâ are already pointers (references) When you pass "xm pointerâ you are actually passing a pointer to a pointer (a float** in this case) This looks better: FFIExamples interpolationFunc_xm: xm getHandle ym: ym getHandle size: 2 x: 2.5 . Still, you need to do something with those arrays after using them, since you are creating them with externalNewType:â¦ (which mean it allocates the memory space). You will need to send #free to them. Other solution would be to not use #externalNewType:size: but plain #newType:size: Cheers, Esteban > > last expression returninÐ¿ me 0.0, but right is 3.5. > > I'm dit the same in Python3 ctypes, and there work's fine. > > In UnifiedFFI booklet is absent chapter "Arrays", anybody may help with whot i'm doing wrong?

Nov. 26, 2018

Re: question about FFI

by Henrik Sperre Johansen

Nevermind me, hadn't had my coffee yet, for some reason I didn't see it was doWithIndex: you were using :/ Still a bit scary that FFIExternalArray at:put: doesn't perform bounds checks... Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 26, 2018

Re: question about FFI

by Henrik Sperre Johansen

Yuriy Babah wrote > in Playground i'm doing: * > #(2 3) doWithIndex: [:each :i | xm at: i put: each]. > #(3 4) doWithIndex: [:each :i | ym at: i put: each]. * > > whot i'm doing wrong? So, you're putting 2 at index 2 of xm, and then writing 3 past end of array, and in ym you're putting 3 and 4 at offsets past the end of array? It's a wonder your image didn't crash, rather than return interpolation of the uninitialized values... Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 26, 2018