- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1360: 22625-FileReferencenextVersion-gets-stuck-at-11
by ci-pharo-ci-jenkins2＠inria.fr Nov. 5, 2018

Nov. 5, 2018

There is a new Pharo build available! The status of the build #1360 was: SUCCESS. The Pull Request #1950 was integrated: "22625-FileReferencenextVersion-gets-stuck-at-11" Pull request url: https://github.com/pharo-project/pharo/pull/1950 Issue Url: https://pharo.fogbugz.com/f/cases/22625 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #1359: 22614-Integrate-Calypso-v0120
by ci-pharo-ci-jenkins2＠inria.fr Nov. 5, 2018

Nov. 5, 2018

There is a new Pharo build available! The status of the build #1359 was: SUCCESS. The Pull Request #1943 was integrated: "22614-Integrate-Calypso-v0120" Pull request url: https://github.com/pharo-project/pharo/pull/1943 Issue Url: https://pharo.fogbugz.com/f/cases/22614 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Esteban's ChangeLog week of 29 October 2018
by estebanlm＠gmail.com Nov. 5, 2018

Nov. 5, 2018

Hello! This is my weekly ChangeLog, from 29 October 2018 to 4 November 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=29/10/2018&to=4/11/2018 ChangeLog ========= 29 October 2018: ---------------- * I made a PR to update [Calypso in Pharo 7 to version 0.12.0](https://github.com/pharo-project/pharo/pull/1943). While this should be very easy, in case of Calypso it is a but harder because of its dependency graph, that looks a bit like this : Calypso ClassAnnotation Commander ClassAnnotation SystemCommands Commander ClassAnnotationAnyway, in the medium term, I want to create a tool to do "chained-releases", which is not so easy because we need to modify baselines and do commits, pushs and tags. But it will be possible to do :) cheers! Esteban

1 0

FFI interfacing to thin C layers over C++ libraries [was Re: [squeak-dev] Squeak and Tesseract]
by Ben Coman Nov. 4, 2018

Nov. 4, 2018

While I've done a lot of C programming that is useful for FFI interfacing, I've not done much C++. So just sharing something new I learnt today to help with FFI interfacing to combined C/C++ libraries. I thought maybe others in the same boat could be interested in this. [Original question asked in squeak-dev, cross-posting to pharo-dev] On Fri, 2 Nov 2018 at 21:06, Ben Coman <btc(a)openinworld.com> wrote: > > On Fri, 2 Nov 2018 at 18:44, Edwin Ancaer <eancaer(a)gmail.com> wrote: > >> As I'm looking at a way to automate the search of documents in my humble >> administration, I read some articles about OCR. I came along an article >> about using Python with Tesseract, to transform an scan of a document into >> text, that is searchable. >> >> My question now is if I can do something similar with Squeak. To my >> inexperienced eye, it seems like I should use FFI to call the functions in >> the Tesseract API, but this API is in C++, and I don't know if it is >> possible to use FFI to call C++ functions? >> > > You are right C++ is difficult because of the name mangling of function > symbols, > but good fortune I notice Tesseract has C bindings... > https://github.com/tesseract-ocr/tesseract#for-developers > https://github.com/tesseract-ocr/tesseract/blob/master/src/api/capi.h > so it looks like you are in the clear. > Browsing a deeper I got quite confused for a while. I could see a typedef definition for TessResultRenderer here... https://github.com/tesseract-ocr/tesseract/blob/master/src/api/capi.h#L83 "typedef struct TessResultRenderer TessResultRenderer" which I understood to must refer to *existing* struct, but I couldn't find the definition of that struct anywhere. In particular... $ git clone git@github.com:tesseract-ocr/tesseract.git $ cd tesseract $ find . -type f -name "*h" -exec grep -Hn TessResultRenderer {} \; but didn't find any struct definitions. I could only find TessResultRenderer as a class definition... https://github.com/tesseract-ocr/tesseract/blob/master/src/api/renderer.h#L… and the only thing that I guessed could possibly make sense was that C++ classes and structs could be used interchangeably. My google-fu failed to find anything useful, so an experiment... $ vi test.cpp #include <stdio.h> class SomeClass { public: int a; int b; }; typedef struct SomeClass SomeTypeDef; int main() { SomeTypeDef x; x.a = 5; x.b = 7; printf("Answer is %d\n", x.a + x.b); } $ gcc test.cpp $ ./a.out Answer is 12 Now I noticed that the TessResultRenderer member variables were private... https://github.com/tesseract-ocr/tesseract/blob/master/src/api/renderer.h#L… and curious about that I changed my test example from public to private which somewhat expectedly produced compile errors. So those TessResultRenderer member variables must only be accessed from a member function, but how is that C++ member function called from C to operate on a particular object? An example is TessResultRendererInsert... C Declaration: https://github.com/tesseract-ocr/tesseract/blob/c375f4fbf73b8f761b2e65e0e3a… C Definition: https://github.com/tesseract-ocr/tesseract/blob/c375f4fbf73b8f761b2e65e0e3a… C++ Declaration: https://github.com/tesseract-ocr/tesseract/blob/master/src/api/renderer.h#L… C++ Definition: https://github.com/tesseract-ocr/tesseract/blob/master/src/api/renderer.cpp… So in the C Defintion "the C++ member-function insert() as being called via a function pointer in the struct." (is that a reasonable way to describe it?) In this case, because of the private member variables, our FFI would treat TessResultRenderer as an opaque object, which simplifies things. I would guess in-Image direct access to the member variables from would need to account for the offset due to variables holding the function pointer to the member functions. cheers -ben P.S. for Tesseract FFI it might be good to start with reproducing this example... https://github.com/tesseract-ocr/tesseract/wiki/APIExample#example-using-th…

1 0

Where to discuss strategies and tools for a comeback of Smalltalk using Scratch as entrance
by Bernhard HÃ¶fner Nov. 2, 2018

Nov. 2, 2018

> Hello Group. I like to discuss about the subject and have also some ideas. But I want to ask first for the proper list within the forum. I heard that there is a discussion ongoing and want to participate. > > I will send this question to Squeak and Pharo usegroup and to the Phratch-developer. I assume that there is a common discussion about the subject. Hopefully there is no need to open on each platform an individual thread. > > Regards, Bernhard

2 2

FFI test Smalltalk code
by Eliot Miranda Nov. 2, 2018

Nov. 2, 2018

Hi All, I'm looking at a bug with the Win64 FFI when there are more than four arguments. The test functions are in platforms/Cross/plugins/SqueakFFIPrims/sqFFITestFuncs.c and the SUnit code is in FFI-Tests, e.g. on http://source.squeak.org/FFI. But whereas sqFFITestFuncs.c already contains functions such as ffiTestInts8, ffiTestFloats7, ffiTestFloats13, there are no test for these in FFI-Tests. Can anyone point me to such tests, and/or commit them to FFI-Tests on http://source.squeak.org/FFI? AdvThanksance _,,,^..^,,,_ best, Eliot

1 0

Source/changes file suffixes constants
by Sven Van Caekenberghe Nov. 1, 2018

Nov. 1, 2018

Hi, Current FileStream holds (in the protocol 'file reader services') some constants regarding source/changes file suffixes. Where should we move these to (as FileStream is deprecated) ? There is a class SourceFile, there is PharoFilesOpener, neither seems to fit that well. Suggestions ? Sven

2 2

ClyMethodGroup>>#fileOut dead code ?
by Sven Van Caekenberghe Nov. 1, 2018

Nov. 1, 2018

Hi, ClyMethodGroup>>#fileOut seems like dead code (it sends #trailer to a WriteStream which DNUs). It also uses the deprecated FileStream. Can it be removed ? Sven

3 2

glamorous toolkit alpha.2
by Tudor Girba Oct. 31, 2018

Oct. 31, 2018

Hi, Glamorous Toolkit has evolved quite a bit over the past months, and we now would like to announce that we reached alpha.2 version. It runs on top of Pharo 7: feenk.com/gt There quite a number of new things. Some highlights are: - We added extensive documentation for GT, Bloc and Brick. By running "GtWorld openTourâ you essentially transform the image into an elaborate wiki. - We worked on Coder, a new set of tools that are dedicated for affecting code. For example, in the picture below we see an editor on embedded examples that can be edited and run independently. And this one shows how we can visualize and edit the result of querying. Just a note: To make Coder work the way we want, we extended Brick with several widgets, and enhanced significantly the linear and grid layouts. - We added the first version of xdoc in order to serialize the Playground every time you evaluate something. As always, we are looking forward to your feedback. Have fun, The feenk team -- www.feenk.com -- www.feenk.com "Every thing should have the right to be different."

1 0

About #zipped / #unzipped
by Sven Van Caekenberghe Oct. 31, 2018

Oct. 31, 2018

Hi, Given https://pharo.fogbugz.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSys… [where we need more help !!] I found String>>#zipped to be one of the users of the deprecated RWBinaryOrTextStream. Although this usage is easy enough to fix, I think the current #zipped / #unzipped on String is broken. (note also that there are no real users of these methods) Right now it seems cool that the following is an identity. 'foobar' zipped unzipped. However, the result of zipping something is actual something binary (a collection of opaque bytes). Thinking of it, the input is actually also bytes, not unencoded characters. Of course, the current methods are broken, as can be seen from a more complex (wide) string. 'Ã©lÃ¨ves FranÃ§aises @ 10 â¬' zipped unzipped. >>> <something very weird> The error results from some implicit/wrong character encoding being used. The right way to do this is to explicitly encode/decode the string. (GZipReadStream on: (ByteArray streamContents: [ :out | (GZipWriteStream on: out) nextPutAll: 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded; close ])) upToEnd utf8Decoded. >From this it would follow that #zipped / #unzipped would make more sense on ByteArray. So that the above identity would become. 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded zipped unzipped utf8Decoded. This change of signature would be comparable to what we recently did with #base64Encoded / #base64Decoded What do you think ? Sven

3 3