- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

by Marcus Denker

> On 21 Feb 2015, at 21:11, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Today I experimented a little with the new Slots feature of Pharo 4.0. As an example I implemented support for associations/relationships. > Very nice! Can I add this to Pharo4 as an example? My idea is that at first we add these things as examples, and then later take the examples and distill a library of generally useful slots. Marcus

Feb. 23, 2015

Re: [Pharo-dev] Athens/Morphic

by Nicolai Hess

Load the new configuration of athens (2.9) Open an AthensWorld: AthensWrapWorldMorph new openInWorld Drag and drop some morphs on this athens world. (Nautilus /Old Workspace should fully work/ GT Inspector and Playground not) 2015-02-23 9:51 GMT+01:00 stepharo <stepharo(a)free.fr>: > how can I play with that? > > even if I should not. > > Le 20/2/15 08:54, Marcus Denker a Ã©crit : > > Very nice! Works here (on Mac). > > I will integrate as soon as the CI is up againâ¦ > > Marcus > > On 19 Feb 2015, at 12:44, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Most of this (without the test class (AthensTestDisplay)) is now ready > for > integration. > > A lot of changes for making Mophic and Text(Morphs) work on Athens > (For testing purpose there is also the AthensWrapWorldMorph included). > > The Canvas wrapper (AthensCanvasWrapper) is not yet included and therefore > all Morphs that do not explicit have a proper drawOnAthensCanvas method > arent't drawn (or just like rectangles). > > Should work with any image >= 40490 > Just load the latest ConfigurationOfAthens from pharo 40 inbox and > load > ConfigurationOfAthens loadVersion:'2.9' > > If this is working (or not:) ) please leave a note on fogbugz: > "14954 load new configuration 2.9 (more morphic support)" > > > nicolai > > > 2015-01-31 11:54 GMT+01:00 Alain Plantec <alain.plantec(a)yahoo.com>: > >> >> >> Yes the HandMorph is handled like any other Morph, it draws itself >> and >> after that it draws all its submorphs. (And actually it does not use >> any caching, and it is still quite fast) >> >> >> the same in Bloc, no caching and it works just fine :) >> >> But yes, it needs a special drawOnAthens method. >> >> >>> Do you plane to make a package for it ? >>> I would like to integrate it in Bloc. >>> >> >> What would like to integrate? >> >> In fact I do not see any change when in Bloc. >> So I guess I will have to adapt Bloc to your changes. >> >> I will upload the changes in Athens-Morphic package to >> the Athens repository. >> >> >> cool. >> >> thanks >> >> Alain >> > > > >

Feb. 23, 2015

Re: [Pharo-dev] Athens/Morphic

by Marcus Denker

> On 23 Feb 2015, at 09:51, stepharo <stepharo(a)free.fr> wrote: > > how can I play with that? > > even if I should not. > I loaded Athens and then did AthensWrapWorldMorph new openInWorld I think. > Le 20/2/15 08:54, Marcus Denker a Ã©crit : >> Very nice! Works here (on Mac). >> >> I will integrate as soon as the CI is up againâ¦ >> >> >> Marcus >> >>> On 19 Feb 2015, at 12:44, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>> >>> Most of this (without the test class (AthensTestDisplay)) is now ready for >>> integration. >>> >>> A lot of changes for making Mophic and Text(Morphs) work on Athens >>> (For testing purpose there is also the AthensWrapWorldMorph included). >>> >>> The Canvas wrapper (AthensCanvasWrapper) is not yet included and therefore >>> all Morphs that do not explicit have a proper drawOnAthensCanvas method arent't drawn (or just like rectangles). >>> >>> Should work with any image >= 40490 >>> Just load the latest ConfigurationOfAthens from pharo 40 inbox and >>> load >>> ConfigurationOfAthens loadVersion:'2.9' >>> >>> If this is working (or not:) ) please leave a note on fogbugz: >>> "14954 load new configuration 2.9 (more morphic support)" >>> >>> >>> nicolai >>> >>> >>> 2015-01-31 11:54 GMT+01:00 Alain Plantec <alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com>>: >>> >>>> >>>> Yes the HandMorph is handled like any other Morph, it draws itself and >>>> after that it draws all its submorphs. (And actually it does not use any caching, and it is still quite fast) >>> >>> the same in Bloc, no caching and it works just fine :) >>> >>>> But yes, it needs a special drawOnAthens method. >>>> >>>> Do you plane to make a package for it ? >>>> I would like to integrate it in Bloc. >>>> >>>> What would like to integrate? >>> >>> In fact I do not see any change when in Bloc. >>> So I guess I will have to adapt Bloc to your changes. >>> >>>> I will upload the changes in Athens-Morphic package to >>>> the Athens repository. >>> >>> cool. >>> >>> thanks >>> >>> Alain >>> >> >

Feb. 23, 2015

Re: [Pharo-dev] Athens/Morphic

by stepharo

how can I play with that? even if I should not. Le 20/2/15 08:54, Marcus Denker a Ã©crit : > Very nice! Works here (on Mac). > > I will integrate as soon as the CI is up againâ¦ > > Marcus > >> On 19 Feb 2015, at 12:44, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>> wrote: >> >> Most of this (without the test class (AthensTestDisplay)) is now >> ready for >> integration. >> >> A lot of changes for making Mophic and Text(Morphs) work on Athens >> (For testing purpose there is also the AthensWrapWorldMorph included). >> >> The Canvas wrapper (AthensCanvasWrapper) is not yet included and >> therefore >> all Morphs that do not explicit have a proper drawOnAthensCanvas >> method arent't drawn (or just like rectangles). >> >> Should work with any image >= 40490 >> Just load the latest ConfigurationOfAthens from pharo 40 inbox and >> load >> ConfigurationOfAthens loadVersion:'2.9' >> >> If this is working (or not:) ) please leave a note on fogbugz: >> "14954 load new configuration 2.9 (more morphic support)" >> >> >> nicolai >> >> >> 2015-01-31 11:54 GMT+01:00 Alain Plantec <alain.plantec(a)yahoo.com >> <mailto:alain.plantec@yahoo.com>>: >> >> >>> >>> Yes the HandMorph is handled like any other Morph, it draws >>> itself and >>> after that it draws all its submorphs. (And actually it does not >>> use any caching, and it is still quite fast) >> >> the same in Bloc, no caching and it works just fine :) >> >>> But yes, it needs a special drawOnAthens method. >>> >>> Do you plane to make a package for it ? >>> I would like to integrate it in Bloc. >>> >>> >>> What would like to integrate? >> In fact I do not see any change when in Bloc. >> So I guess I will have to adapt Bloc to your changes. >> >>> I will upload the changes in Athens-Morphic package to >>> the Athens repository. >> >> cool. >> >> thanks >> >> Alain >> >> >

Feb. 23, 2015

Re: [Pharo-dev] GTInspector custom presentations discoverability idea

by stepharo

fixed! Le 22/2/15 15:50, Ben Coman a Ã©crit : > On the pharo.org <http://pharo.org> home page, maybe "moldable tools" > should be added under the "Feel a live environment" heading. btw, I > notice there that "developping" has too many 'p's. >

Feb. 23, 2015

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

by Tudor Girba

Unfortunately, you cannot release with one click multiple deeply nested configurations. We will have to solve this problem soon :) Cheers, Doru On Sun, Feb 22, 2015 at 8:33 PM, stepharo <stepharo(a)free.fr> wrote: > Doru with versioner you can release in a click... > > Le 8/2/15 13:01, Tudor Girba a Ã©crit : > > Hi Nicolai, > > > > On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> 14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools >> #development >> "From this version onwards the development version should be integrated." >> >> Is this a good idea? Does the #development version always include *all* >> the latest >> changes, because after Andrei opened >> 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools >> (which got integrated in 40475) >> I uploaded some changes for issue >> 14608 <https://pharo.fogbugz.com/default.asp?14608> >> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to >> Spotter methods >> I set the status to "Fix Review needed", >> > but my changes are integrated in 40475 too! >> > > I think that in the current situation, it is actually a good idea. And > yes, the integration does include all latest versions of GT-related > packages. > > Before changing to development, we required a stable release for the > integration. That implied: > 1. creating a stable release and > 2. integrating it in the Pharo through a separate issue. > > Yet, in GT we all work on the very latest version, and creating a > "stable" release is somewhat artificial given the speed at which things are > changing now. Creating the "stable" version also led to delays between a > fix in GT and an integration in Pharo (sometimes measured in weeks). So, in > the case of GT requiring the stable release did not provide any added > value, but it has the negative consequence of delays. > > I am not satisfied with the way external packages are handled. >> 1. if there is not one slice/changeset per issue, it is even less >> likely someone will >> review the changes. >> 2. you don't know who works when on a issue. They are solved in a bulk. >> 3. a new configuration might not only includes bugfixes but new >> features as well. >> 4. often we have unbound globals / undeclared references or other test >> failures. >> >> Can we use the build server for those external projects (like >> GToolkitCore, Athens, TxText), >> and that if a project makes a new configuration, it uses the same >> issue validator for loading and testing that configuration? >> > > We already have a GToollkitCore job, but it only runs the GT tests. > Perhaps this is not enough? > https://ci.inria.fr/moose/job/gtoolkitcore/ > > But, could the Monkey not be able to run all tests before an integration > of the development version? > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 22, 2015

Re: [Pharo-dev] development workflow for GTools (GToolkitCore)

by stepharo

Doru with versioner you can release in a click... Le 8/2/15 13:01, Tudor Girba a Ã©crit : > Hi Nicolai, > > > > On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > 14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate > GTools #development > "From this version onwards the development version should be > integrated." > > Is this a good idea? Does the #development version always include > *all* the latest > changes, because after Andrei opened > 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate > GTools (which got integrated in 40475) > I uploaded some changes for issue > 14608 <https://pharo.fogbugz.com/default.asp?14608> > ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to > Spotter methods > I set the status to "Fix Review needed", > > but my changes are integrated in 40475 too! > > > I think that in the current situation, it is actually a good idea. And > yes, the integration does include all latest versions of GT-related > packages. > > Before changing to development, we required a stable release for the > integration. That implied: > 1. creating a stable release and > 2. integrating it in the Pharo through a separate issue. > > Yet, in GT we all work on the very latest version, and creating a > "stable" release is somewhat artificial given the speed at which > things are changing now. Creating the "stable" version also led to > delays between a fix in GT and an integration in Pharo (sometimes > measured in weeks). So, in the case of GT requiring the stable release > did not provide any added value, but it has the negative consequence > of delays. > > I am not satisfied with the way external packages are handled. > 1. if there is not one slice/changeset per issue, it is even less > likely someone will > review the changes. > 2. you don't know who works when on a issue. They are solved in a > bulk. > 3. a new configuration might not only includes bugfixes but new > features as well. > 4. often we have unbound globals / undeclared references or other > test failures. > > Can we use the build server for those external projects (like > GToolkitCore, Athens, TxText), > and that if a project makes a new configuration, it uses the same > issue validator for loading and testing that configuration? > > > We already have a GToollkitCore job, but it only runs the GT tests. > Perhaps this is not enough? > https://ci.inria.fr/moose/job/gtoolkitcore/ > > But, could the Monkey not be able to run all tests before an > integration of the development version? > > Cheers, > Doru > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Feb. 22, 2015

Re: [Pharo-dev] [NativeBoost] Calling a function in a struct

by Max Leske

Yay, got it! Itâs actually really straight forward if you know the stuffâ¦ The magic is in NBFFICalloutAPI. This class provides the method #function:address:. So if I let NB create an external object (subclass of NBExternalObject) for the struct field that provides the function, the address of the function is in the handle variable and I can define a method on that external object like so: writepack: writepack buffer: buffer length: length progress: progress <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCallout function: #(NBInt32 (LG2GitOdbWritepackS * writepack, const void * buffer, NBInt32 length, LG2GitTransferProgressS * progress)) address: [ handle ] This even installs native code, so call generation only happens on the first pass (Iâll have to see if NB is smart enough here to take changes in the handle into account). >> On 22 Feb 2015, at 01:19, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> 2015-02-22 0:06 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: >> Hi. >> >> I have a situation with libgit2 where the function I need to call is a field in a struct (the field gets populated with different functions with the same signature depending on certain conditions). >> >> Iâm facing two problems now: >> 1. how do I define a function as the field type of an NBExternalStructure? >> >> Athens creates a structure with callbacks as a surface plugin for the bitblter (SQSurfaceDispatch). >> But this is a structur with functions (generated with NB) that are called "from the outside" >> >> 2. how can I call the function? >> >> I don't know of any example in the image, where we are calling a function defined in a struct. >> Maybe you can extend NBFFICallout to generate a call from a function spec + function address >> >> NBFFICallout>>#generateCall:module: does this, it generates a call from a function spec and and >> address loockuped in a module, maybe you can do something similiar, but use the function address from >> the structure isntead of calling nbGetSymbolAddress:module: > > Iâll give that a try, thanks. > >> >> >> >> Iâve tried using callbacks as field types. That works as far as I can access the functions by pointer. But how would I then call that function? >> Iâve looked at NBNativeFunction and NBNativeFunctionGen but I canât see how I should use either of those to make a plain call. >> >> Hereâs a more precise description of my problem: >> >> writepack := LG2GitOdbWritepackS new. >> â¦ âinitialize the struct externallyâ >> >> ânow call the function âcommitâ and pass the arguments (this is how I imagine it could workâ¦)" >> writepack commit >> value: writepack >> value: anotherStruct. >> >> >> Needed struct fields: >> >> backend: git_odb_backend * >> append: int (*)(git_odb_writepack *, const void *, size_t, git_transfer_progress *) >> commit: int (*)(git_odb_writepack *, git_transfer_progress *) >> free: void (*)(git_odb_writepack *) >> >> >> For what is this needed? Do you want to write your own git backend? > > No. I need to implement packing of loose objects to save space. libgit2 only does this for network transport. For this I need to work with the pack backend directly and the backend provides the function I need to call for finishing the write in the âcommitâ field of the struct. Of course, I know which function that will be since Iâm working with one particular backend. But if I wanted to support multiple backends in the future it would be better to call the provided function instead of explicitly naming it. > >> >> I find this strange. I only know of two use cases for function pointers in a structs. >> 1. to define the callbacks (like athens does it for the SQSurfaceDispatch). But we only define the functions and don't call them. >> 2. a library defines a public api and delegates the implementation to different backends, but structure and backend functions >> are hidden. Users of the library don't call them. > > Exactly. Iâm dipping deeper here than one usually needs to. > > Thanks Nicolai. > >> >> >> >> >> >> My current (ad hoc) struct fields: >> >> fieldsDesc >> ^#( >> LG2GitOdbO backend; >> LG2WritePackAppendCb append; >> LG2WritePackCommitCb commit; >> LG2WritePackFreeCb free; >> ) >> >> >> Iâd even be happy if I have to implement a method on LG2GitOdbWritepackS for every function call (e.g. âwritepack commit: arg1 and: arg2â) but how would I make the call? >> >> Any ideas? >> Max >> >

Feb. 22, 2015

GTInspector custom presentations discoverability idea

by Ben Coman

Just watching the PharoDAYS 2015: GT Tools video [1] and I had an idea how to make the discoverability better for how to create your own presentations. Around 6:19, the class "ABAddressBook" is clicked, and before a method is clicked, the bottom pane is empty. That could be filled with a template for a custom presentation, similar templates in the System Browser when a package is selected but no class selected, or a protocol is selected but no method. [1] https://www.youtube.com/watch?v=Nmcou_5um2s btw, At the end I felt like clapping with the audience. This sort of overview it what has been missing from my understanding the overall aim/architecture of GT Tools (perhaps I missed something previous of humane-assessment site.) GTChatter looks promising, but obviously early days. It feels like there is more potential than was demonstrated. Now the moldability demonstrated by the GTInspector and GTSpotter seem so close to what others like LightTable are calling live programming, that I think we would even hold these up under that banner. If the first two (since they are in the image) were split out from the video [1] I think this would be suitable quality to incorporate into marketing the Pharo 4 release. On the pharo.org home page, maybe "moldable tools" should be added under the "Feel a live environment" heading. btw, I notice there that "developping" has too many 'p's. cheers -ben

Feb. 22, 2015

Re: [Pharo-dev] [NativeBoost] Calling a function in a struct

by Max Leske

> On 22 Feb 2015, at 01:19, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2015-02-22 0:06 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > Hi. > > I have a situation with libgit2 where the function I need to call is a field in a struct (the field gets populated with different functions with the same signature depending on certain conditions). > > Iâm facing two problems now: > 1. how do I define a function as the field type of an NBExternalStructure? > > Athens creates a structure with callbacks as a surface plugin for the bitblter (SQSurfaceDispatch). > But this is a structur with functions (generated with NB) that are called "from the outside" > > 2. how can I call the function? > > I don't know of any example in the image, where we are calling a function defined in a struct. > Maybe you can extend NBFFICallout to generate a call from a function spec + function address > > NBFFICallout>>#generateCall:module: does this, it generates a call from a function spec and and > address loockuped in a module, maybe you can do something similiar, but use the function address from > the structure isntead of calling nbGetSymbolAddress:module: Iâll give that a try, thanks. > > > > Iâve tried using callbacks as field types. That works as far as I can access the functions by pointer. But how would I then call that function? > Iâve looked at NBNativeFunction and NBNativeFunctionGen but I canât see how I should use either of those to make a plain call. > > Hereâs a more precise description of my problem: > > writepack := LG2GitOdbWritepackS new. > â¦ âinitialize the struct externallyâ > > ânow call the function âcommitâ and pass the arguments (this is how I imagine it could workâ¦)" > writepack commit > value: writepack > value: anotherStruct. > > > Needed struct fields: > > backend: git_odb_backend * > append: int (*)(git_odb_writepack *, const void *, size_t, git_transfer_progress *) > commit: int (*)(git_odb_writepack *, git_transfer_progress *) > free: void (*)(git_odb_writepack *) > > > For what is this needed? Do you want to write your own git backend? No. I need to implement packing of loose objects to save space. libgit2 only does this for network transport. For this I need to work with the pack backend directly and the backend provides the function I need to call for finishing the write in the âcommitâ field of the struct. Of course, I know which function that will be since Iâm working with one particular backend. But if I wanted to support multiple backends in the future it would be better to call the provided function instead of explicitly naming it. > > I find this strange. I only know of two use cases for function pointers in a structs. > 1. to define the callbacks (like athens does it for the SQSurfaceDispatch). But we only define the functions and don't call them. > 2. a library defines a public api and delegates the implementation to different backends, but structure and backend functions > are hidden. Users of the library don't call them. Exactly. Iâm dipping deeper here than one usually needs to. Thanks Nicolai. > > > > > > My current (ad hoc) struct fields: > > fieldsDesc > ^#( > LG2GitOdbO backend; > LG2WritePackAppendCb append; > LG2WritePackCommitCb commit; > LG2WritePackFreeCb free; > ) > > > Iâd even be happy if I have to implement a method on LG2GitOdbWritepackS for every function call (e.g. âwritepack commit: arg1 and: arg2â) but how would I make the call? > > Any ideas? > Max >

Feb. 22, 2015