- Pharo-dev - lists.pharo.org

UFFI #isPointer - absolute or versus naturalPointerArity

by Ben Coman

First, my C is a bit rusty so a question about semantics... int * a; typedef int * MyInt; MyInt b; So obviously the type of 'a' is a pointer, but is the type of 'b' a pointer? My intuition is that its not, since the pointer is wrapped inside the type. Now in my UFFI tutorial http://blog.openinworld.com/2016/09/pharo-libclang-ffi-part-4-ast-walking-w… I have a callback that I've modified here adding the #inspect... acceptCallbackFn := FFICallback signature: #( CXChildVisitResult ( CXCursor cursor, CXCursor parent, CXClientData client_data)) block: [ :cursor :parent :clientData | client_data inspect. visitResult add: cursor kind item. aCXChildVisitResult value "@1" ]. This can be invoked by running #testVisitChildrenCallbackBreak and an inspector opens on an ExternalAddress instead of the expected CXClientData. FFIExternalObject subclass: #CXClientData instanceVariableNames: '' classVariableNames: '' package: 'Libclang' where the FFIExternalObject says... "A typical usage of me is to create a subclass, and then use that subclass name directly in function signatures ... By putting FFIExternalObject subclass ... as a return type into the function signature, we are telling the code generator to ***automatically*** convert the return value into an instance of a given class and initialize its handle to the value returned by the function." This decision to return ExternalAddress instead of CXClientData occurs here... FFIExternalObjectType(FFIExternalType)>>handle: aHandle at: index self isPointer ifTrue: [ ^ aHandle pointerAt: index ]. ^ self basicHandle: aHandle at: index since... FFIExternalType>>isPointer ^ self pointerArity > 0 and... FFIExternalObjectType(FFIExternalReferenceType)>>naturalPointerArity ^ 1 So this naturalPointerArity=1 represents the situation presented with the C code at the top. So should #isPointer consider only the absolute pointerArity, or should is be... FFIExternalType>>isPointer ^ self pointerArity > self class naturalPointerArity Indeed, if I do that, plus these two additions copied from FFIExternalStructure... FFIExternalReferenceType>>basicHandle: aHandle at: index ^ self objectClass fromHandle: aHandle. FFIExternalReference>>fromHandle: aHandle ^self basicNew setHandle: aHandle Now running #testVisitChildrenCallbackBreak opens an inspector opens on a CXClientData as expected. And all UFFI tests continue to run fine. One thing I found strange though was... FFIExternalStructureType>>naturalPointerArity ^ 1 I would have thought a struct's natural pointer arity was 0 ? wdyt? cheers -ben

Sept. 27, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] edd9f3: 60220

by stepharo

> For those found of annotations I suggest > #<pleaseDontFormatMe> > or since it's destinated to IDE/Tool Good idea. I will keep it in mind. Stef

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by Max Leske

> On 27 Sep 2016, at 13:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 27 Sep 2016, at 13:41, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> >> >> On Tue, Sep 27, 2016 at 11:43 AM, Max Leske <maxleske(a)gmail.com> wrote: >> Hi Sven, >> >> An experimental build of the VM works again on Sierra (Iâve tested this one: https://bintray.com/estebanlm/pharo-vm/build/201609201407#files) The problem was with the bundle code and a change from Appleâs side to Cocoa. The new VM is a Spur VM of course. If you need a Cog VM, you can try a Squeak VM (e.g. 'Croquet Closure Cog VM [CoInterpreterPrimitives VMMaker.oscog-eem.1095] Squeak Cog 4.0.3282â) or run the current PharoVM in a virtual machine on Linux (as Iâve done). >> >> Concerning Fuel: the versioning problem is a known and big issue I have to admit. Which Fuel versions does your problem concern? There were some big changes for Fuel from Pharo 4 to 5, e.g. MethodContext was renamed to Context. Depending on the objects you store however, you may be able to load the file simply by removing the version check in Fuel, as most things should be identical. >> >> >> From Pharo 5 to Pharo 6, likely there will be the change from BlockClosure to FullBlockClosure that will have some impact... We'll keep for Pharo 6 the BlockClosure support for migration purpose then. > > The problem is not so much that if there is a change there is an incompatibility, that would be understandable. [ And then supporting some backward compatibility is good ] > > The problem is that FUEL moves forward in version number, and it refuses to load unless the versions match, even if all you do is, say, safe a collection of strings. It should only fail when it really encounters something that changed. I understand that. But as I wrote, try disabling the version check. > >> Cheers, >> Max >> >> >>> On 27 Sep 2016, at 11:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>>> On 27 Sep 2016, at 11:21, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> Sven, >>>> >>>>> Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>>>> >>>>> PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor. >>>> >>>> it is like that from the beginning. I guess there was the fear keeping everything compatible would be a huge amount of work. But it is indeed an annoying thing. The usual way to deal with it is open pharo4 and materialize the fuel file then upgrade fuel to the version pharo5 uses and save again. >>>> >>>> Norbert >>> >>> Yeah, but this is silly: it goes against the principle of a persistence format: to save data for future use. [ I knew this already, I never agreed with this principle ]. >>> >>> Like I described in the email, after upgrading, we were unable to run the old image - catch 22.

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by Sven Van Caekenberghe

> On 27 Sep 2016, at 12:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> On 27 Sep 2016, at 11:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> Can someone who really knows/understand please describe where to find the necessary Pharo VM's to run on the newly released macOS Sierra (10.12) ? > > Iâm in the process of producing compatible VMs. > Today or tomorrow they will be ready. OK, looking forward to it, we will certainly test.

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by Sven Van Caekenberghe

> On 27 Sep 2016, at 13:41, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > On Tue, Sep 27, 2016 at 11:43 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi Sven, > > An experimental build of the VM works again on Sierra (Iâve tested this one: https://bintray.com/estebanlm/pharo-vm/build/201609201407#files) The problem was with the bundle code and a change from Appleâs side to Cocoa. The new VM is a Spur VM of course. If you need a Cog VM, you can try a Squeak VM (e.g. 'Croquet Closure Cog VM [CoInterpreterPrimitives VMMaker.oscog-eem.1095] Squeak Cog 4.0.3282â) or run the current PharoVM in a virtual machine on Linux (as Iâve done). > > Concerning Fuel: the versioning problem is a known and big issue I have to admit. Which Fuel versions does your problem concern? There were some big changes for Fuel from Pharo 4 to 5, e.g. MethodContext was renamed to Context. Depending on the objects you store however, you may be able to load the file simply by removing the version check in Fuel, as most things should be identical. > > > From Pharo 5 to Pharo 6, likely there will be the change from BlockClosure to FullBlockClosure that will have some impact... We'll keep for Pharo 6 the BlockClosure support for migration purpose then. The problem is not so much that if there is a change there is an incompatibility, that would be understandable. [ And then supporting some backward compatibility is good ] The problem is that FUEL moves forward in version number, and it refuses to load unless the versions match, even if all you do is, say, safe a collection of strings. It should only fail when it really encounters something that changed. > Cheers, > Max > > >> On 27 Sep 2016, at 11:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 27 Sep 2016, at 11:21, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Sven, >>> >>>> Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> >>>> PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor. >>> >>> it is like that from the beginning. I guess there was the fear keeping everything compatible would be a huge amount of work. But it is indeed an annoying thing. The usual way to deal with it is open pharo4 and materialize the fuel file then upgrade fuel to the version pharo5 uses and save again. >>> >>> Norbert >> >> Yeah, but this is silly: it goes against the principle of a persistence format: to save data for future use. [ I knew this already, I never agreed with this principle ]. >> >> Like I described in the email, after upgrading, we were unable to run the old image - catch 22.

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by ClÃ©ment Bera

On Tue, Sep 27, 2016 at 11:43 AM, Max Leske <maxleske(a)gmail.com> wrote: > Hi Sven, > > An experimental build of the VM works again on Sierra (Iâve tested this > one: https://bintray.com/estebanlm/pharo-vm/build/201609201407#files) > The problem was with the bundle code and a change from Appleâs side to > Cocoa. The new VM is a Spur VM of course. If you need a Cog VM, you can try > a Squeak VM (e.g. 'Croquet Closure Cog VM [CoInterpreterPrimitives > VMMaker.oscog-eem.1095] Squeak Cog 4.0.3282â) or run the current PharoVM in > a virtual machine on Linux (as Iâve done). > > Concerning Fuel: the versioning problem is a known and big issue I have to > admit. Which Fuel versions does your problem concern? There were some big > changes for Fuel from Pharo 4 to 5, e.g. MethodContext was renamed to > Context. Depending on the objects you store however, you may be able to > load the file simply by removing the version check in Fuel, as most things > should be identical. > > >From Pharo 5 to Pharo 6, likely there will be the change from BlockClosure to FullBlockClosure that will have some impact... We'll keep for Pharo 6 the BlockClosure support for migration purpose then. > Cheers, > Max > > > On 27 Sep 2016, at 11:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 27 Sep 2016, at 11:21, Norbert Hartl <norbert(a)hartl.name> wrote: > > Sven, > > Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > PS2: Another really annoying problem is the following: he saved all his > (really important) scripts using Script Manager as a FUEL. Moving between > 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really > not cool, why would a newer FUEL not be able to read older FUEL. He ended > up copying string data by opening the binary FUEL file in a text editor. > > > it is like that from the beginning. I guess there was the fear keeping > everything compatible would be a huge amount of work. But it is indeed an > annoying thing. The usual way to deal with it is open pharo4 and > materialize the fuel file then upgrade fuel to the version pharo5 uses and > save again. > > Norbert > > > Yeah, but this is silly: it goes against the principle of a persistence > format: to save data for future use. [ I knew this already, I never agreed > with this principle ]. > > Like I described in the email, after upgrading, we were unable to run the > old image - catch 22. > > > > >

Sept. 27, 2016

[IMPORTANT] Tech meeting 27/09 16UTC - WE WILL USE DISCORD

by Esteban Lorenzano

Hi, Since I failed to configure the thing correctly (and then streaming breaks after some minutes), we will handle the meeting using discord. This has the advantage that we can all talk, so my idea of having a conversation will work better (ideal world would be to mix both, but for now, this has to work). Here the discord link: https://discord.gg/RRfqj <https://discord.gg/RRfqj> cheers, Esteban > On 26 Sep 2016, at 16:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Ah yes, I forget the âsmall detailâ of linking my channel :) > > https://www.livecoding.tv/estebanlm/ <https://www.livecoding.tv/estebanlm/> > > (I never tried, so this can fail ;) > > cheers, > Esteban > >> On 26 Sep 2016, at 16:40, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> Hello, >> >> I will handle the first tech meeting tomorrow, as preview. >> After several considerations, I will be trying âlivecoding.tvâ (no idea if this is worst or better than twitchâ¦ and Iâm not very happy with the fact that this is a âtv formatâ and not a âconversation formatâ, but well, weâll see how it goes, maybe weâll need to review this later). >> >> Subject of meeting tomorrow is a general overview about current work on PharoVM, so prepare your questions, and see you there! >> >> cheers, >> Esteban >

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by Esteban Lorenzano

> On 27 Sep 2016, at 11:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Can someone who really knows/understand please describe where to find the necessary Pharo VM's to run on the newly released macOS Sierra (10.12) ? Iâm in the process of producing compatible VMs. Today or tomorrow they will be ready. Esteban ps: in the mean time, you can use this one: cog_macos32x86_pharo.cog.spur_201609231453.tar.gz <https://bintray.com/estebanlm/pharo-vm/download_file?file_path=cog_macos32x…> (is not yet 100% compatible with Pharo but is working fineâ¦ just command line â-â vs. â--" is not compatible and some othersâ¦) > > In particular it seems old VM's just stop working and recent VM's that do work either have issues or cannot run older (3.0, 4.0) images. > > Thanks, > > Sven > > PS: I have not yet upgraded, but one of my colleagues did and he got stuck: even after we found a VM that worked, it could only run 5.0 images, not his production 4.0 images. Needless to say, this is not good. > > PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor.

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by stepharo

>>> Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor. >> it is like that from the beginning. I guess there was the fear keeping everything compatible would be a huge amount of work. But it is indeed an annoying thing. The usual way to deal with it is open pharo4 and materialize the fuel file then upgrade fuel to the version pharo5 uses and save again. >> >> Norbert > Yeah, but this is silly: it goes against the principle of a persistence format: to save data for future use. [ I knew this already, I never agreed with this principle ]. Me too - believe but my scenario was not really heard. I think that it would be good to have some strategies to represent different objects representation but fuel will be slower. Mariano was fighting against speed and speed and speed. and he did it well. > Like I described in the email, after upgrading, we were unable to run the old image - catch 22.

Sept. 27, 2016

Re: [Pharo-dev] macOS Sierra support

by Max Leske

Hi Sven, An experimental build of the VM works again on Sierra (Iâve tested this one: https://bintray.com/estebanlm/pharo-vm/build/201609201407#files <https://bintray.com/estebanlm/pharo-vm/build/201609201407#files>). The problem was with the bundle code and a change from Appleâs side to Cocoa. The new VM is a Spur VM of course. If you need a Cog VM, you can try a Squeak VM (e.g. 'Croquet Closure Cog VM [CoInterpreterPrimitives VMMaker.oscog-eem.1095] Squeak Cog 4.0.3282â) or run the current PharoVM in a virtual machine on Linux (as Iâve done). Concerning Fuel: the versioning problem is a known and big issue I have to admit. Which Fuel versions does your problem concern? There were some big changes for Fuel from Pharo 4 to 5, e.g. MethodContext was renamed to Context. Depending on the objects you store however, you may be able to load the file simply by removing the version check in Fuel, as most things should be identical. Cheers, Max > On 27 Sep 2016, at 11:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 27 Sep 2016, at 11:21, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Sven, >> >>> Am 27.09.2016 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> PS2: Another really annoying problem is the following: he saved all his (really important) scripts using Script Manager as a FUEL. Moving between 4.0 and 5.0 FUEL stops working (version incompatibility) - this is really not cool, why would a newer FUEL not be able to read older FUEL. He ended up copying string data by opening the binary FUEL file in a text editor. >> >> it is like that from the beginning. I guess there was the fear keeping everything compatible would be a huge amount of work. But it is indeed an annoying thing. The usual way to deal with it is open pharo4 and materialize the fuel file then upgrade fuel to the version pharo5 uses and save again. >> >> Norbert > > Yeah, but this is silly: it goes against the principle of a persistence format: to save data for future use. [ I knew this already, I never agreed with this principle ]. > > Like I described in the email, after upgrading, we were unable to run the old image - catch 22. > > >

Sept. 27, 2016