- Pharo-dev - lists.pharo.org

[Pharo 9.0] Build #308: Add tests for Athens Cairo SVG and PDF creation + some renames in examples
by ci-pharo-ci-jenkins2＠inria.fr May 22, 2020

May 22, 2020

There is a new Pharo build available! The status of the build #308 was: FAILURE. The Pull Request #6384 was integrated: "Add tests for Athens Cairo SVG and PDF creation + some renames in examples" Pull request url: https://github.com/pharo-project/pharo/pull/6384 Issue Url: https://github.com/pharo-project/pharo/issues/6382 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?
by Esteban Lorenzano May 22, 2020

May 22, 2020

> On 22 May 2020, at 15:07, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > > > On Fri, 22 May 2020 at 15:25, Esteban Lorenzano <estebanlm(a)netc.eu <mailto:estebanlm@netc.eu>> wrote: >> On 22 May 2020, at 04:24, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >> >> Esteban Lorenzano wrote >>> The class comments are not clear? >> >> Maybe it's me ;-) > > > No. I struggled with this also, and still don't have it fully grasped. I could follow Eteban's advice in a particular case I asked about, but still feel hard to reason about next time. > http://forum.world.st/typedef-pointerArity-for-FFIOpaqueObjects-td4914975.h… <http://forum.world.st/typedef-pointerArity-for-FFIOpaqueObjects-td4914975.h…> > http://forum.world.st/UFFI-isPointer-absolute-or-versus-naturalPointerArity… <http://forum.world.st/UFFI-isPointer-absolute-or-versus-naturalPointerArity…> > >> >> >> Esteban Lorenzano wrote >>> Opaque object = https://en.wikipedia.org/wiki/Opaque_data_type <https://en.wikipedia.org/wiki/Opaque_data_type> >>> <https://en.wikipedia.org/wiki/Opaque_data_type&gt <https://en.wikipedia.org/wiki/Opaque_data_type&gt>; >>> External object = a pointer to something. >> >> For example, why is ObjCClass a subclass of FFIExternalObject instead of >> FFIOpaqueObject when the docs say that a "Class [is] An opaque type that >> represents an Objective-C class"? Also, is the distinction just conceptual? >> I don't see what either class "buys" you in behavior since they are siblings >> that both pretty much have no methods. > > > This is because ObjCClass = SomeOpaqueStructurePointer (is already a pointer), same as ObjCSelector and ObjCMethod. > Difference is subtle, because is just a different way of representing the same. > > The easiest way I have to explain is: > > As a prelude to my next comment, how does "External" distinguish between the two case? > Aren't both cases dealing with external C data? > > You use an OpaqueObject when you will refer to "the opaque type" in calls as: someFunction(opaqueobject *someArg). > You use an ExternalObject when you will refer to "the opaque type" in calls as: someFunction(externalobject someArg). > > That makes the distinction really clear. So if now IIUC, both cases deal with "opaque types" > with the *only* difference between the two being the arity? > Then I propose the following naming would be more intention revealing... > > OpaqueObject when you will refer to "the opaque type" in calls as: someFunction(opaqueobject *someArg). > OpaquePointer when you will refer to "the opaque type" in calls as: someFunction(opaquepointer someArg). > > > And to test my new understanding, the matching typdefs and FFI calls would be... > > OPAQUE OBJECT > - typedef MyOpaqueType opaqueobject. > - int someFunction(opaqueobject *someArg) > > - FFIOpaqueObject subclass: #MyOpaqueType. > - self ffiCall: #(int someFunction( MyOpaqueType *ot ) ). > - opaque type has arity 0, so FFI needs to take a pointer to it > > OPAQUE POINTER > - typedef MyOpaqueObject *opaquepointer. > - int someFunction(opaquepointer someArg) > > - FFIOpaquePointer subclass: # MyOpaqueType. > - self ffiCall: #(int someFunction( MyOpaqueType ot ) ). > - opaque type has arity of 1, so FFI uses it directly > > The latter FFI call is without the *â¦ because FFIOpaquePointer is already a pointer. > In practice, both FFI calls are identical, and you use the one that matches the C header definitions. > > > ...or maybe I still don't get it. No, you got it :) Part of the confusion is the horribly bad name that FFIExternalObject has :/ Other part is my inability to explain it ;) But yes, this is all as you say. If someone wants to do a PR changing the names and maybe enhancing my commentsâ¦ it would be nice :D Esteban > > cheers -ben

2 2

Re: [Pharo-dev] uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?
by Esteban Lorenzano May 22, 2020

May 22, 2020

Hi, The class comments are not clear? Opaque object = https://en.wikipedia.org/wiki/Opaque_data_type <https://en.wikipedia.org/wiki/Opaque_data_type> External object = a pointer to something. > On 21 May 2020, at 21:53, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > I'm working on improving the documentation. I'd like examples of situations > when you'd use one or the other and why... > > Also, the FFIOpaqueObject class comment could be fleshed out a bit. Check > out this excerpt: > "this means we always access them through a reference. > Now, we could declare the pointer to the structures, but > then our declarations wouldn't be as close to C as we want." > > What would be an example of "declar[ing] the pointer to the structures" and > the resulting declarations that "wouldn't be as close to C as we want"? There are plenty of cases in C where you do: struct MyStruct *s; Buy tou cannot do (or you cannot use): struct MyStruct s; This is like that because most modern frameworks use the opaque type as a place to keep state, but to interact with them you use functions. e.g: MyOpaqueType *ot = newOpaqueType(); opaque_type_someFunction(ot, âa parameterâ); Then an opaque object would be: FFIOpaqueObject subclass: #MyOpaqueType. And you can do an ffi call like this: self ffiCall: #(void opaque_type_someFunction(MyOpaqueType *ot, char *aString)). Note the declaration of "MyOpaqueType *otâ This is how C declaration looks. We can say that an opaque type is a pointer type with arity 0. Now, an FFIExternalObject (which should be called FFIExternalPointer), has already an arity of 1. Which means, if you declare: FFIExternalObject subclass: #MyOpaqueTypePtr. The same ffiCall you did before would be: self ffiCall: #(void opaque_type_someFunction(MyOpaqueTypePtr ot, char *aString)). Note the declaration without the *â¦ this is because FFIExternalObject is already a pointer. Of course, you can write the function call both ways and it works identicallyâ¦ but the first one is closer to what you do in C regularly. Esteban > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>

2 1

uFFI: What is the difference between FFIExternalObject and FFIOpaqueObject?
by Sean P. DeNigris May 21, 2020

May 21, 2020

I'm working on improving the documentation. I'd like examples of situations when you'd use one or the other and why... Also, the FFIOpaqueObject class comment could be fleshed out a bit. Check out this excerpt: "this means we always access them through a reference. Now, we could declare the pointer to the structures, but then our declarations wouldn't be as close to C as we want." What would be an example of "declar[ing] the pointer to the structures" and the resulting declarations that "wouldn't be as close to C as we want"? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

1 0

[ANN] Scheduler moved to GitHub pharo-contributions/Scheduler
by Torsten Bergmann May 21, 2020

May 21, 2020

Hi; "Scheduler" ws migrated from SmalltalkHub to GitHub - it is an easy-to-use task scheduler that can run arbitrary blocks. See attached image for a quick example. A few things have been cleaned as well: - separate tests into own package - class comments - categorize classes and methods - fix lint problems - follow SUnit best practices (super tearDown, super setUp) - removed unnecessary "super new initialize" call on class side - add a Travis CI job - ... https://github.com/pharo-contributions/Scheduler It is usable and working in recent Pharo versions Enjoy! Bye T.

1 0

[Pharo 9.0] Build #307: Load Iceberg 1.8.0
by ci-pharo-ci-jenkins2＠inria.fr May 20, 2020

May 20, 2020

There is a new Pharo build available! The status of the build #307 was: FAILURE. The Pull Request #6381 was integrated: "Load Iceberg 1.8.0" Pull request url: https://github.com/pharo-project/pharo/pull/6381 Issue Url: https://github.com/pharo-project/pharo/issues/iceberg180 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #306: SimplifyOCASTTranslater-by-tempVarNamesWithoutArguments
by ci-pharo-ci-jenkins2＠inria.fr May 20, 2020

May 20, 2020

There is a new Pharo build available! The status of the build #306 was: FAILURE. The Pull Request #6336 was integrated: "SimplifyOCASTTranslater-by-tempVarNamesWithoutArguments" Pull request url: https://github.com/pharo-project/pharo/pull/6336 Issue Url: https://github.com/pharo-project/pharo/issues/SimplifyOCASTTranslater Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #305: fix-profiling-menu-entries
by ci-pharo-ci-jenkins2＠inria.fr May 20, 2020

May 20, 2020

There is a new Pharo build available! The status of the build #305 was: SUCCESS. The Pull Request #6380 was integrated: "fix-profiling-menu-entries" Pull request url: https://github.com/pharo-project/pharo/pull/6380 Issue Url: https://github.com/pharo-project/pharo/issues/fix Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #304: merge-spec2-0-6
by ci-pharo-ci-jenkins2＠inria.fr May 20, 2020

May 20, 2020

There is a new Pharo build available! The status of the build #304 was: FAILURE. The Pull Request #6324 was integrated: "merge-spec2-0-6" Pull request url: https://github.com/pharo-project/pharo/pull/6324 Issue Url: https://github.com/pharo-project/pharo/issues/merge Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 9.0] Build #303: Fix Cairo bindings for PDF and SVG generation
by ci-pharo-ci-jenkins2＠inria.fr May 20, 2020

May 20, 2020

There is a new Pharo build available! The status of the build #303 was: FAILURE. The Pull Request #6376 was integrated: "Fix Cairo bindings for PDF and SVG generation" Pull request url: https://github.com/pharo-project/pharo/pull/6376 Issue Url: https://github.com/pharo-project/pharo/issues/6374 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0