- Pharo-dev - lists.pharo.org

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Ciprian Teodorov

Hi, On Wed, Jan 23, 2013 at 10:06 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi: > > On 23 Jan 2013, at 18:51, Ciprian Teodorov wrote: > > > The libs should be 32 bits... but it seems it is not this the issue... > > I have compiled clang+llvm from sources using the source distribution > at: http://www.llvm.org/releases/ > > > > then I have built the whole llvm distribution (using the getting started > guide): > > ../src/configure --prefix=<path-to-install-dir> --enable-optimized > --enable-jit --target=i686-apple-darwin10 > > I don't know what the issue is, but building it myself was indeed the > solution. > > cool... > So, for everyone who likes to use it: (from memory) > > wget http://www.llvm.org/releases/3.1/llvm-3.1.src.tar.gz > wget http://www.llvm.org/releases/3.1/clang-3.1.src.tar.gz > > tar xvf llvm-3.1.src.tar.gz > tar xvf clang-3.1.src.tar.gz > > mv clang-3.1.src llvm-3.1.src/tools/clang > > cd llvm-3.1.src > mkdir build > cd build > ../configure --enable-optimized --enable-jit --target=i686-apple-darwin10 > make -j2 # or -j or -j8 or so, compiling takes quite a while... > > thank you for putting it all down > > If everything compiles well, you'll have a compatible > `llvm-3.1.src/build/Release+Asserts/lib/libclang.dylib` > > Now I am running in some bugs, I think. > I get a change browser which tells me that it is going to create a class > with stuff. > But then I get a RBAddMethodChange, which doesn't have a `changeClass`. > The reason is that the class is not actually created before the method is > supposed to be added, I think. > > If I manually create the class, it seems to work properly. > > This is a problem with Pharo 2.0 ChangesBrowser which does not keep the items Ordered. My quick fix is to change the underlying structure used by PickListModel. In PickListModel>>initialize replace: *pickedItemsHolder := Set new asValueHolder.* by: *pickedItemsHolder := **OrderedCollection new asValueHolder.* and it will work. Beside that cosmetic problem: > How is the generator supposed to work exactly, does it also load > indirectly referenced header classes? > Doesn't seem to do that. > No it doesn't... at least not for now. The C to AST conversion supports that, however I've run into some problems with system includes, which use "bizzare" constructs. Besides in my opinion, recursivelly visiting all includes is not a good idea since It my pull lots of definitions that are not necessary. But if you really want it, you can do it by changing CLForeignLibInterfaceGenerator>>wrapperForHeader: aHeaderSpec to send the #everything message to the CLHeaderParser. Such as: CLForeignLibInterfaceGenerator>>wrapperForHeader: aHeaderSpec headerAST := (CLHeaderParser builder: CLNodeBuilder new) headerFile: aHeaderSpec fileName; compilationOptions: aHeaderSpec compilationOptions; everything ; parseHeader. But then will really get everything, getc, time, lchmod ??? you know everything... The example I am experimenting with is: > https://github.com/libgit2/libgit2/blob/development/include/git2.h which > includes all the required stuff. > > Well, if I add all the headers manually to the generation, I run into the > trouble of the non-existing classes again. > So in my opinion the nicest way to do it is just create a list of the headers we really want, and use that such in my LLVM example Happy hacking, Ciprian > > Will try to work around that. > > Thanks so far > Stefan > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Jan. 23, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Stefan Marr

Hi Ciprian: On 23 Jan 2013, at 22:06, Stefan Marr wrote: > Well, if I add all the headers manually to the generation, I run into the trouble of the non-existing classes again. After working around the order issue, I am still running into more issues. Some of the classes for which methods are generated are completely missing in the list of generated classes, and other changes in the list result in colliding renames of callback classes. I will try to generate the bindings step by step, seeing what I actually need. But if you would have a chance to look into these problems, that would be great. Below I added the methods I used to generate the bindings. Thanks a lot Stefan !CLForeign2NBGenerator class methodsFor: 'libgit2' stamp: 'StefanMarr 1/23/2013 22:04'! libgit2Headers ^ {'git2.h'. 'git2/version.h'. 'git2/common.h'. 'git2/threads.h'. 'git2/errors.h'. 'git2/types.h'. 'git2/oid.h'. 'git2/signature.h'. 'git2/odb.h'. 'git2/repository.h'. 'git2/revwalk.h'. 'git2/merge.h'. 'git2/graph.h'. 'git2/refs.h'. 'git2/reflog.h'. 'git2/revparse.h'. 'git2/object.h'. 'git2/blob.h'. 'git2/commit.h'. 'git2/tag.h'. 'git2/tree.h'. 'git2/diff.h'. 'git2/index.h'. 'git2/config.h'. 'git2/transport.h'. 'git2/remote.h'. 'git2/clone.h'. 'git2/checkout.h'. 'git2/push.h'. 'git2/attr.h'. 'git2/ignore.h'. 'git2/branch.h'. 'git2/refspec.h'. 'git2/net.h'. 'git2/status.h'. 'git2/indexer.h'. 'git2/submodule.h'. 'git2/notes.h'. 'git2/reset.h'. 'git2/message.h'. 'git2/pack.h'. 'git2/stash.h'.}! ! !CLForeign2NBGenerator class methodsFor: 'libgit2' stamp: 'StefanMarr 1/3/2013 19:41'! libgit2Mapping | path includeDir options builder hFiles | path := self libgit2Path. includeDir := path / 'include'. options := {('-I' , (path / 'include') fullName). '-D__STDC_CONSTANT_MACROS'. '-D__STDC_LIMIT_MACROS'}. hFiles := self libgit2Headers. builder := (CLForeign2NBGenerator for: #LibGit2) platform: NativeBoostConstants mac32PlatformId libPath: (path / 'build/libgit2.dylib') fullName; compilationOptions: options; includeDir: includeDir; addHeaderFiles: hFiles; classPrefix: 'LG2'; ffiSelectorBlock: [ :selector | (selector beginsWith: 'git_') ifTrue: [ (selector copyFrom: 4 to: selector size) withFirstCharacterDownshifted ] ifFalse: [ selector withFirstCharacterDownshifted ] ]; ignoreUnsupported; generate; openChanges! ! !CLForeign2NBGenerator class methodsFor: 'libgit2' stamp: 'StefanMarr 1/23/2013 15:06'! libgit2Path ^ FileReference / 'Users/smarr/tmp/libgit/libgit2'! ! -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 23, 2013

Re: [Pharo-project] ChangesBrowser is too naive Was: TalkFFI: automatic FFI generation for Pharo

by Stefan Marr

On 23 Jan 2013, at 23:06, StÃ©phane Ducasse wrote: > Do you have a case that we can reproduce and so we fix it? > One of the problems I fixed yesterday was that the RecentChangeList did not get notification anymore. The following example shows two problems with the current PickListModel: | instance | instance := PickListModel new. instance openWithSpec. instance items: {4. 2. 55. 4. 4. }. ^ instance First, all 4s are the same item, and cannot be selected independently. A bug, I would say. Second, the Set does not preserve the order, so `instance pickedItems` does not have the natural order. The problem is that PickListModel >> #initialize initializes the field 'pickedItemsHolder' with a Set. This set is never exposed and not customizable directly. So well, I would say a Set is an unfortunate choice for a list widget. Lists have a natural order, and it is not obvious to me why that order should not be preserved. I might miss here other tradeoffs of course, but replacing the Set by a OrderedCollection solves my current problem. It does not solve the issue with multiple entries however. Best regards Stefan > > Stef > > On Jan 23, 2013, at 6:35 PM, Stefan Marr wrote: > >> Hi: >> >> On 23 Jan 2013, at 22:06, Stefan Marr wrote: >> >>> I get a change browser which tells me that it is going to create a class with stuff. >>> But then I get a RBAddMethodChange, which doesn't have a `changeClass`. >>> The reason is that the class is not actually created before the method is supposed to be added, I think. >> >> So, I am on a recent Pharo 2.0 image and experience problems with the ChangesBrowser. >> >> Namely, changes are represented as an unordered set, which leads to problems. >> Most notably, methods are added to non-existing classes before they are created. >> >> You probably want to use an order-preserving data structure. >> >> A quick hack, I used is just a work around: >> >> ChangesBrowser >> #accept >> | changes | >> self okToChange ifFalse: [ ^self ]. >> >> changes := self pickedChanges sorted: [:a :b | (a isKindOf: RBAddClassChange) and: [(b isKindOf: RBAddClassChange) not]]. >> >> changes do: [:change | RBRefactoryChangeManager instance performChange: change ]. >> window delete >> >> >> Best regards >> Stefan >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 23, 2013

Re: [Pharo-project] ChangesBrowser is too naive Was: TalkFFI: automatic FFI generation for Pharo

by StÃ©phane Ducasse

Do you have a case that we can reproduce and so we fix it? One of the problems I fixed yesterday was that the RecentChangeList did not get notification anymore. Stef On Jan 23, 2013, at 6:35 PM, Stefan Marr wrote: > Hi: > > On 23 Jan 2013, at 22:06, Stefan Marr wrote: > >> I get a change browser which tells me that it is going to create a class with stuff. >> But then I get a RBAddMethodChange, which doesn't have a `changeClass`. >> The reason is that the class is not actually created before the method is supposed to be added, I think. > > So, I am on a recent Pharo 2.0 image and experience problems with the ChangesBrowser. > > Namely, changes are represented as an unordered set, which leads to problems. > Most notably, methods are added to non-existing classes before they are created. > > You probably want to use an order-preserving data structure. > > A quick hack, I used is just a work around: > > ChangesBrowser >> #accept > | changes | > self okToChange ifFalse: [ ^self ]. > > changes := self pickedChanges sorted: [:a :b | (a isKindOf: RBAddClassChange) and: [(b isKindOf: RBAddClassChange) not]]. > > changes do: [:change | RBRefactoryChangeManager instance performChange: change ]. > window delete > > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

Jan. 23, 2013

[Pharo-project] ChangesBrowser is too naive Was: TalkFFI: automatic FFI generation for Pharo

by Stefan Marr

Hi: On 23 Jan 2013, at 22:06, Stefan Marr wrote: > I get a change browser which tells me that it is going to create a class with stuff. > But then I get a RBAddMethodChange, which doesn't have a `changeClass`. > The reason is that the class is not actually created before the method is supposed to be added, I think. So, I am on a recent Pharo 2.0 image and experience problems with the ChangesBrowser. Namely, changes are represented as an unordered set, which leads to problems. Most notably, methods are added to non-existing classes before they are created. You probably want to use an order-preserving data structure. A quick hack, I used is just a work around: ChangesBrowser >> #accept | changes | self okToChange ifFalse: [ ^self ]. changes := self pickedChanges sorted: [:a :b | (a isKindOf: RBAddClassChange) and: [(b isKindOf: RBAddClassChange) not]]. changes do: [:change | RBRefactoryChangeManager instance performChange: change ]. window delete Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 23, 2013

Re: [Pharo-project] TalkFFI: automatic FFI generation for Pharo

by Stefan Marr

Hi: On 23 Jan 2013, at 18:51, Ciprian Teodorov wrote: > The libs should be 32 bits... but it seems it is not this the issue... > I have compiled clang+llvm from sources using the source distribution at: http://www.llvm.org/releases/ > > then I have built the whole llvm distribution (using the getting started guide): > ../src/configure --prefix=<path-to-install-dir> --enable-optimized --enable-jit --target=i686-apple-darwin10 I don't know what the issue is, but building it myself was indeed the solution. So, for everyone who likes to use it: (from memory) wget http://www.llvm.org/releases/3.1/llvm-3.1.src.tar.gz wget http://www.llvm.org/releases/3.1/clang-3.1.src.tar.gz tar xvf llvm-3.1.src.tar.gz tar xvf clang-3.1.src.tar.gz mv clang-3.1.src llvm-3.1.src/tools/clang cd llvm-3.1.src mkdir build cd build ../configure --enable-optimized --enable-jit --target=i686-apple-darwin10 make -j2 # or -j or -j8 or so, compiling takes quite a while... If everything compiles well, you'll have a compatible `llvm-3.1.src/build/Release+Asserts/lib/libclang.dylib` Now I am running in some bugs, I think. I get a change browser which tells me that it is going to create a class with stuff. But then I get a RBAddMethodChange, which doesn't have a `changeClass`. The reason is that the class is not actually created before the method is supposed to be added, I think. If I manually create the class, it seems to work properly. Beside that cosmetic problem: How is the generator supposed to work exactly, does it also load indirectly referenced header classes? Doesn't seem to do that. The example I am experimenting with is: https://github.com/libgit2/libgit2/blob/development/include/git2.h which includes all the required stuff. Well, if I add all the headers manually to the generation, I run into the trouble of the non-existing classes again. Will try to work around that. Thanks so far Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 23, 2013

Re: [Pharo-project] SmallLint applied on Pharo: Continued

by StÃ©phane Ducasse

We want that everybody runs smallLint on their code :) I downloaded your code and I will have a look. I should published my changes but I want to fix first the PharoTaskForces repo problem. We are going there and it will be a massive attack :) http://www.youtube.com/watch?v=u7K72X4eo_s&list=AL94UKMTqg-9Aoc-c5isxIXHiEW… cool music Stef On Jan 23, 2013, at 11:48 AM, Hernan Wilkinson wrote: > Hi Stef, > it is great to see that you are using SmallLint to check for errors in Pharo. I the development process we had in a project I participated, we had a step where you had to run SmallLint and you could not commit code with smallLint errors and for some packages with possible errors. > Becuase SmallLint generates a quite a lot false positives, we developed at that time (it was around 2004) something we called "ExpectedSmallLintErrors" that we use to document those false positives and therefore be able to commit the changes (the documentation was smalltalk code of course that included a reason and an author). The interesting thing about this kind of doc. was that if the false positive went away you had to remove the related "expected error", so it worked both ways. > We solved the problems you mentioned about subclass responsibility and others similars, all with VisualAge > It was really cool and it help us to catch and prevent a lot of errors. We ported it to Pharo (or Squeak at that time) a long time ago, but I cannot find the project on SqueakSource... I remember that Lukas had implemented something similar using pragmas but it lacked some features that we supported that I don't remember now :-) > > Anyway, I'm really happy to see that the Pharo team is using SmallLint and I think you should put it as a step in the development process, and I also recommend to you to have some "interesting" way of documenting false positive because if not you will end up not using it... at least that was my experience. > > Bye, > Hernan. > > > On Tue, Jan 22, 2013 at 8:59 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Well. I've written the tag support, so let's make it simple, MIT. > > I may export a changeset with that code for you, if you like. > > Else I will just go over them and it will help me to understand. I think that this is not difficult. > > > For rules written by CG I'm not sure. You should check with him. > > But I think it won't be a problem given that you preserve all > > the signatures and #documentation and #version_XXX methods > > (we use them to track changes in the source). > > > > However, what I planned (and run out of time :-) is to make > > tag a first class object with name (symbol) description etc > > and have class methods to create them. Then one may define and > > describe meaning of the tag in an extension method. > > Also, the selection/rejection logic could dispatch back on > > the tag instance so you may then create fancy dynamic tags > > (like #portability that automatically includes everything tagged > > as #pharo #squeak #stx #va, for instance or whatever. > > > > I might hack it later this week, if you would include it into > > your version (otherwise I've more important things to do :-) > > I imagine well. > Let us keep it simple. Simple tags with a little class comments are good enough :) > > > > > Cheers > > > > On 22/01/13 19:32, StÃ©phane Ducasse wrote: > >> Jan > >> what is the license of your tags and other code? > >> > >> Stef > >> > >> On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote: > >> > >>> On 22/01/13 18:22, StÃ©phane Ducasse wrote: > >>>> Hi > >>>> > >>>> I'm running the rule RBSubclassResponsibilityNotDefinedRule that > >>>> > >>>> Checks that all subclassResponsibility methods are defined in all leaf classes. > >>>> > >>>> Now the results display the sender of ^ subclassResponsibility but I have to manually find the > >>>> problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method. > >>>> > >>>> But this would be much better. Jan did you do that in your version? > >>> > >>> Good point. Yes, since now we do that :-) > >>> > >>> Jan > >>> > >>>> > >>>> Stef > >>>> > >>> > >>> > >> > >> > >> > > > > > > > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Jan. 23, 2013

Re: [Pharo-project] about Loom profiler

by StÃ©phane Ducasse

On Jan 23, 2013, at 10:54 AM, Alexandre Bergel wrote: > Hi! > > Sorry for the late reply. > >> how Loom compares with the fixes that andreas added to the default profiler. > > I am not sure about Andreas' fixes. this is why it would be nice that you know because you should be the profiler expert :) > Loom tells you for each thread running in the VM the amount of CPU it consumes. > Some screenshots should be self explaining: > http://objectprofile.com/loom-screenshots.html > >> I do not know if the code is in squeak because this code was licensed under GPL. > > Loom is MIT. > >> But I would like to know if your profiler takes into account the problems solved by andreas. > > Any ref about this? look into the list it was mentioned. > >> I did not see an announce of Loom (by the way Loom is the name of large oo memory developed by the original smalltalk team >> a while ago). >> >> http://objectprofile.com/loom-download.html >> >> I'm know that some people got problem with our profiler and I would like to see how we >> can improve it. > > We haven't announced Loom because the Pharo version is not yet ready. Although usable, it has a very poor graphical user interface. > The first goal is to have Loom replace the standard process browser. > > Cheers, > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Jan. 23, 2013

Re: [Pharo-project] DocTest

by StÃ©phane Ducasse

Doru I will try to have a look later today but busyâ¦. Stef On Jan 23, 2013, at 8:38 AM, Tudor Girba wrote: > We are releasing Moose as soon as we figure out how to load RPackage from PharoTaskForces squeak source repository (see my previous mail), and afterwards we move to 2.0. > > Cheers, > Doru > > > > On Wednesday, January 23, 2013, Sven Van Caekenberghe wrote: > > On 23 Jan 2013, at 11:34, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > FYI, we are already using Phexample in Moose since several years, and it just works out of the box next to Sunit. > > That is good to know. > Moose is a really important project for Pharo. > It feels good to know that such a big code base is pushing forward like that. > > BTW, is work already being done bring Moose to Pharo 2.0 ? > > > Doru > > > > On Wednesday, January 23, 2013, Sven Van Caekenberghe wrote: > > Yes we #should ;-) > > > > It is beautiful. > > > > On 23 Jan 2013, at 11:04, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > > check the project page for all examples and explanations: > > > > > > http://smalltalkthoughts.blogspot.ch/2009/11/phexample-because-examples-exp… > > > http://www.iam.unibe.ch/~akuhn/blog/2009/shoulda-use-this-in-pharo > > > > > > to me this feels more like Smalltalk and less like Java ;) > > > > > > On 2013-01-23, at 08:47, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > >> Who should assert then? > > >> From a certain POV, it does not seem that awfully unlogical to > > >> delegate this responsability to a TestCase. > > >> A TestCase is here to assert some rule. > > >> > > >> Nicolas > > >> > > >> 2013/1/23 Camillo Bruni <camillobruni(a)gmail.com>: > > >>> for that we already have a fully working Phexample: > > >>> > > >>> http://www.squeaksource.com/phexample.html > > >>> > > >>> which I will push in 3.0, cause I never really liked #assert: and friends being > > >>> sent to self. Furthermore we could finally build up decent messages! > > >>> > > >>> On 2013-01-22, at 18:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > >>> > > >>>> it would be nice to introduce the same syntax than Sunit > > >>>> > > >>>> exp assert: exp2 > > >>>> > > >>>> [ exp ] shouldraise: > > >>>> > > >>>> Stef > > >>>> > > >>>> > > >>>> On Jan 21, 2013, at 4:41 AM, Benjamin wrote: > > >>>> > > >>>>> Hi guys, > > >>>>> > > >>>>> I am attending a python lecture and discovered DocTest[1], and I was wondering if such a tool exists for Pharo ? :) > > >>>>> > > >>>>> > > >>>>> Ben > > >>>>> > > >>>>> [1]http://docs.python.org/2/library/doctest.html > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > >>> > > >> > > > > > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Jan. 23, 2013

Re: [Pharo-project] [ANN] Headless support for Cog Cocoa VM

by StÃ©phane Ducasse

> You don't know the power of the dark sideâ¦ No Lukriano I'm not your father

Jan. 23, 2013