September 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] UFFI #isPointer - absolute or versus naturalPointerArity

by Eliot Miranda

Hi Ben, On Tue, Sep 27, 2016 at 8:40 AM, Ben Coman <btc(a)openinworld.com> wrote: > 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. > Yes it is. MyInt (a bad name) is a type that is a pointer to an int. So something of type MyInt is of type pointer to int. > Now in my UFFI tutorial > http://blog.openinworld.com/2016/09/pharo-libclang-ffi- > part-4-ast-walking-with-visitors-callbacks/ > 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 > This makes my brain hurt. A pointer is a pointer, whether it points to a pointer or a datum. Hence I find the "self pointerArity > self class naturalPointerArity" approach confusing. _,,,^..^,,,_ best, Eliot

Sept. 28, 2016

Re: [Pharo-dev] [Pharo-users] Tech Meeting notes

by Dimitris Chloupis

And for those that were not able to attend the voice meeting here you can find the recording so you can listen to it at your convenience https://dl.dropboxusercontent.com/u/1404140/Pharo%20Voice%20Meetings/PharoV… Have fun :) On Tue, Sep 27, 2016 at 8:23 PM stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I tried to take some notes of the discussion and report of effort made > by esteban > > > > > VM works > ======== > - migrating our source to opensmalltalk vm 80% of our source > - keybindings enhancement > - shift key pressed > - library symbols > - change our cmake maker -> plain makefiles > - port our process (running all the tests) > - new VMs will get out > - ARM VM is under dev and started to run. > - migration planned for end of week of next weeks > > - right now able to build > 32 and 64 on mac and linux. > plan with mid october. > > - for windows > - We will produce assert vm to help people to find problems. > > - Sierra support is coming. > - openssl > It will come after the end of the merge finished. > > - FFI bug about the Athens canvas. > > - FT bug is getting on the radar and esteban suspects that the bug > is in the C plugin. We plan to throw away the FT plugin. > If people want to help please have a look at thibaultRaffaillac > bindings. > > - Pharo is using different VM functionalities so sometimes we are > going > on unfrequented paths. > > - Threaded FFI will come after 64, ARM, two bugs > Probably beginning of the year. > > > Iceberg > ======== > here is the log that nicolas sent to our internal mailing-list > > ### Last week: > - Improved travis support, working on having all green tests in travis, > still 4 to go. > - Extending libgit support. > - Support for synchronizing an Iceberg repository with code that was > loaded with gitfiletree (was not working, as reported by Norbert). > - Fixed some bugs (see > https://github.com/npasserini/iceberg/milestone/7?closed=1) > > > ### This week (starting 2016-09-26): > > - Finish having all tests running on travis. > - Better management of ssh keys (which in turn is required for travis > working correctly). > - Also I would like to add some little GUI details that bother me in > daily work (such as remembering common options, highlighting outdated > repositories, or opening repositories from spotter). > > I think that this might take the whole week. After that I plan to add > basic support synchronizing against code that was loaded from any > repository. With that finished, we could release v0.3 > > After that, the plan for v0.4 is to make libgit our default backend, and > make gitfiletree dependencies optional. > - I am pretty close to have all tests running for libgit again, then we > should try to use libgit as backend for the UI. But in that process also > improve test coverage so that we minimize dependence on manual > verification of the UI. > - Remodularice in order to separate gitfiletree dependencies, so we will > be able to use Iceberg without loading ossubprocess (or gitfiletree). > - That will require also to write an independent cypress reader/writer, > because the current one inherits from gitfiletree. > > If we have all this, I think that we could have a version that could be > included in the base image, probably in the second half of october. > > >

Sept. 27, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60241 Home: https://github.com/pharo-project/pharo-core

Sept. 27, 2016

[pharo-project/pharo-core] fe10c1: 60241

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: fe10c13f590e1d96570c78bbba7a0d0f6c23f25e https://github.com/pharo-project/pharo-core/commit/fe10c13f590e1d96570c78bb… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-27 (Tue, 27 Sep 2016) Changed paths: M Collections-Strings.package/String.class/instance/converting/substrings.st M Collections-Strings.package/String.class/instance/converting/substrings_.st M Collections-Tests.package/StringTest.class/instance/testing - converting/testSubstrings.st R Collections-Tests.package/TSortTest.class/instance/as yet unclassified/testSorted.st A Collections-Tests.package/TSortTest.class/instance/tests/testSorted.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60240.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60241.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60240.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60241.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Tools.package/VersionBrowser.class/instance/instance creation/showSourceWithConverter_.st M Tool-Base.package/MethodClassifier.class/class/private/buildKeywordSuffixMapping.st M Tool-Base.package/MethodClassifier.class/class/private/buildPragmaMapping.st M Tool-Base.package/MethodClassifier.class/class/private/buildPrefixMapping.st A Tool-CriticBrowser.package/SingleCodeCriticResultList.class/instance/initialization/setTextModelForTransformationRule_.st Log Message: ----------- 60241 19121 DNU in VersionBrowser when switching from "side by side" to "source" https://pharo.fogbugz.com/f/cases/19121 19143 in Code Critique browser: DNU #setTextModelForTransformationRule: https://pharo.fogbugz.com/f/cases/19143 18914 Improve MethodClassifier classification based on selector parts https://pharo.fogbugz.com/f/cases/18914 19141 Optimize String>>#substrings: https://pharo.fogbugz.com/f/cases/19141 http://files.pharo.org/image/60/60241.zip

Sept. 27, 2016

Tech Meeting notes

by stepharo

Hi guys I tried to take some notes of the discussion and report of effort made by esteban VM works ======== - migrating our source to opensmalltalk vm 80% of our source - keybindings enhancement - shift key pressed - library symbols - change our cmake maker -> plain makefiles - port our process (running all the tests) - new VMs will get out - ARM VM is under dev and started to run. - migration planned for end of week of next weeks - right now able to build 32 and 64 on mac and linux. plan with mid october. - for windows - We will produce assert vm to help people to find problems. - Sierra support is coming. - openssl It will come after the end of the merge finished. - FFI bug about the Athens canvas. - FT bug is getting on the radar and esteban suspects that the bug is in the C plugin. We plan to throw away the FT plugin. If people want to help please have a look at thibaultRaffaillac bindings. - Pharo is using different VM functionalities so sometimes we are going on unfrequented paths. - Threaded FFI will come after 64, ARM, two bugs Probably beginning of the year. Iceberg ======== here is the log that nicolas sent to our internal mailing-list ### Last week: - Improved travis support, working on having all green tests in travis, still 4 to go. - Extending libgit support. - Support for synchronizing an Iceberg repository with code that was loaded with gitfiletree (was not working, as reported by Norbert). - Fixed some bugs (see https://github.com/npasserini/iceberg/milestone/7?closed=1) ### This week (starting 2016-09-26): - Finish having all tests running on travis. - Better management of ssh keys (which in turn is required for travis working correctly). - Also I would like to add some little GUI details that bother me in daily work (such as remembering common options, highlighting outdated repositories, or opening repositories from spotter). I think that this might take the whole week. After that I plan to add basic support synchronizing against code that was loaded from any repository. With that finished, we could release v0.3 After that, the plan for v0.4 is to make libgit our default backend, and make gitfiletree dependencies optional. - I am pretty close to have all tests running for libgit again, then we should try to use libgit as backend for the UI. But in that process also improve test coverage so that we minimize dependence on manual verification of the UI. - Remodularice in order to separate gitfiletree dependencies, so we will be able to use Iceberg without loading ossubprocess (or gitfiletree). - That will require also to write an independent cypress reader/writer, because the current one inherits from gitfiletree. If we have all this, I think that we could have a version that could be included in the base image, probably in the second half of october.

Sept. 27, 2016

Re: [Pharo-dev] [IMPORTANT] Tech meeting 27/09 16UTC - WE WILL USE DISCORD

by Esteban Lorenzano

looks like invite expired, new one: https://discord.gg/ZeJKD <https://discord.gg/ZeJKD> Esteban > On 27 Sep 2016, at 13:20, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > 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 <mailto:estebanlm@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

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