December 2013 - Pharo-dev - lists.pharo.org

Athens: testing whether a point is within a path?

by Alexandre Bergel

Hi! I have seen that AthensPolygonTester may do the job somehow. How can I test whether a point is included in a path? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 14, 2013

Re: [Pharo-dev] Another thought about globals

by kilon alios

Yes thats exactly what I meant with my reply. I was not so sure though about the exact role of globals in pharo and how many problems their removal would cause internally. Î£ÏÎ¹Ï 14 ÎÎµÎº 2013 9:39 Î¼.Î¼., Î¿ ÏÏÎ®ÏÏÎ·Ï "Craig Latta" <craig(a)netjam.org> ÎÎ³ÏÎ±ÏÎµ: > > Hi Norbert-- > > > Class names are globals. A class is registered in a global namespace > > by its name. Names need to be looked up. How should it work in > > another way? > > Get rid of globals. Make the root classes elements of the special > objects array (Object already is), and look up classes through that. > Make everything else that used to be a global (like Transcript) the > responsibility of some class, and use them by sending messages. This > also makes the modularization straightforward. > > There's no need for a system dictionary. It was a profound and > long-lived mistake. > > > -C > > -- > Craig Latta > www.netjam.org/resume > +1 510 984 8117 > (Skype rings this until 31 January 2014) > > >

Dec. 14, 2013

Re: [Pharo-dev] [ANN] traversal-enabled objects with DeepTraverser

by StÃ©phane Ducasse

Mariano If I would invest in fuel to me the most important aspect is support for evolution of course it is difficult but I always think that if I would sotre code with fuel then in 15 years from now I would love to be able to look at it or I would store an textual representation together with the binary format. Stef On Dec 14, 2013, at 3:44 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Wed, Dec 11, 2013 at 12:21 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I put together a little implementation for traversals. It is inspired by an original implementation from Mariano. > > Wow... my memory is sooo bad I don't remember ;) > > > Using DeepTraverser, you can traverse arbitrary graphs by describing the traversal and by specifying the actions you want to perform on the nodes and relations. > > > Once (or even more times) we thought with Martin 2 things: > > 1) Reify the traversal in Fuel so that we could plug a different one. > 2) Use Fuel only for traversing and allowing user a hook to plug the what to do with each node. > 3) Use the same traversal of 2) for deepCopying > 4) Use the same traversal of 2) to get an approximate memory consumption of the transitive closure of an object > > But as always happened we run out of time. > > Anyway...I think this is a nice area to explore. There are many uses for a nice traverser. > > Also, did you see we wrote a Rossal extension to print the fuel traversal? > http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.9/Documentation/… > > > The code is available in the Moose image as part of the MooseAlgos subproject, but can also be loaded separately in a Pharo image via: > > Gofer new > url: 'http://www.smalltalkhub.com/mc/Moose/DeepTraverser/main'; > package: âConfigurationOfDeepTraverserâ; > load. > (Smalltalk globals at: #ConfigurationOfDeepTraverser) loadDevelopment. > > > Just to give you an idea, here are some representative examples: > > Number > deep: #subclasses > do: [:each | Transcript show: each; cr]. > > Number deepCollect: #subclasses. > > Number > deep: #subclasses > collect: #name. > > Number > deep: #subclasses > do: [:each | Transcript show: each; cr] > relationDo: [ :from :to | Transcript show: from; show: ' <-- '; show: to; cr ]. > > > > More details about the usages and a little description of the implementation can be found here: > http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects/ > > > Cheers, > Doru > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > -- > Mariano > http://marianopeck.wordpress.com

Dec. 14, 2013

Re: [Pharo-dev] Another thought about globals

by Craig Latta

Hi Norbert-- > Class names are globals. A class is registered in a global namespace > by its name. Names need to be looked up. How should it work in > another way? Get rid of globals. Make the root classes elements of the special objects array (Object already is), and look up classes through that. Make everything else that used to be a global (like Transcript) the responsibility of some class, and use them by sending messages. This also makes the modularization straightforward. There's no need for a system dictionary. It was a profound and long-lived mistake. -C -- Craig Latta www.netjam.org/resume +1 510 984 8117 (Skype rings this until 31 January 2014)

Dec. 14, 2013

Re: [Pharo-dev] NB FFI problem (calling an universal library)

by Esteban Lorenzano

On Dec 14, 2013, at 7:27 PM, Max Leske <maxleske(a)gmail.com> wrote: Did you check that the library has benn compiled with a C compiler? C++ name mangling doesnât work with NB. but name is been resolved :( Another thing you can do is to attach gdb to the image and break on the gtk_init call. That way you can see at what stage approximately the error occurs. yeah... I expect to avoid that, unless I have no other choice :) Esteban On 14.12.2013, at 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: Hi, I'm trying to create some stuff with Gtk3, and because of it I have a call to gtk_init using NB-FFI. The call is like this: gtkInitArgC: argc argV: argv <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> ^ self nbCall: #( void gtk_init ( int *argc, char ***argv ) ) and well, I have a GtkLibrary copied from CairoLibraryLoader who loads the library. system is 64bits, but Gtk3 libraries are "universal" compiled (it has both formats, i386 and x86_64 inside). GtkLibrary loadGtkLibrary actually loads the library (it answers a pointer to it) and in fact, following the stack track NB is resolving correctly gtk_init symbol... Now, the problem is that a call to self gtkInitArgC: 0 argV: 0. fails... with this stack trace: NBFFICallout class>>signalError: NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: NBFFICalloutAPI>>function:module: GtkApplication(Object)>>nbCall: GtkApplication>>gtkInitArgC:argV: NBFFICallout class(NBNativeCodeGen class)>>retrySend: GtkApplication>>gtkInit GtkApplication>>initialize GtkApplication class(Behavior)>>new MarsApplication>>platformApplication MarsApplication>>stop MarsApplication>>start UndefinedObject>>DoIt OpalCompiler>>evaluate SmalltalkEditor>>evaluateSelectionAndDo: SmalltalkEditor>>evaluateSelection PluggableTextMorph>>doIt in Block: [ textMorph editor evaluateSelection ] PluggableTextMorph>>handleEdit: in Block: [ result := editBlock value ] TextMorphForEditView(TextMorph)>>handleEdit: PluggableTextMorph>>handleEdit: PluggableTextMorph>>doIt SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [ :morph | morph doIt ] BlockClosure>>cull: BlockClosure>>cull:cull: BlockClosure>>cull:cull:cull: KMCategoryBinding>>completeMatch:buffer: KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [ :l | l completeMatch: self buffer: aBuffer ] Array(SequenceableCollection)>>do: KMKeymap>>notifyCompleteMatchTo:buffer: KMKeymap>>onMatchWith:notify:andDo: and #signalError: argument (errorCode) is nil. any idea? thanks, Esteban

Dec. 14, 2013

Re: [Pharo-dev] NB FFI problem (calling an universal library)

by Esteban Lorenzano

On Dec 14, 2013, at 7:27 PM, Max Leske <maxleske(a)gmail.com> wrote: > Did you check that the library has benn compiled with a C compiler? C++ name mangling doesnât work with NB. but name is been resolved :( > Another thing you can do is to attach gdb to the image and break on the gtk_init call. That way you can see at what stage approximately the error occurs. yeah... I expect to avoid that, unless I have no other choice :) cheers, Esteban > > > > On 14.12.2013, at 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> I'm trying to create some stuff with Gtk3, and because of it I have a call to gtk_init using NB-FFI. The call is like this: >> >> gtkInitArgC: argc argV: argv >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> >> ^ self nbCall: #( void gtk_init ( int *argc, char ***argv ) ) >> >> >> and well, I have a GtkLibrary copied from CairoLibraryLoader who loads the library. >> >> system is 64bits, but Gtk3 libraries are "universal" compiled (it has both formats, i386 and x86_64 inside). >> >> GtkLibrary loadGtkLibrary actually loads the library (it answers a pointer to it) and in fact, following the stack track NB is resolving correctly gtk_init symbol... >> >> Now, the problem is that a call to >> >> self gtkInitArgC: 0 argV: 0. >> >> fails... with this stack trace: >> >> NBFFICallout class>>signalError: >> NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: >> NBFFICalloutAPI>>function:module: >> GtkApplication(Object)>>nbCall: >> GtkApplication>>gtkInitArgC:argV: >> NBFFICallout class(NBNativeCodeGen class)>>retrySend: >> GtkApplication>>gtkInit >> GtkApplication>>initialize >> GtkApplication class(Behavior)>>new >> MarsApplication>>platformApplication >> MarsApplication>>stop >> MarsApplication>>start >> UndefinedObject>>DoIt >> OpalCompiler>>evaluate >> SmalltalkEditor>>evaluateSelectionAndDo: >> SmalltalkEditor>>evaluateSelection >> PluggableTextMorph>>doIt in Block: [ textMorph editor evaluateSelection ] >> PluggableTextMorph>>handleEdit: in Block: [ result := editBlock value ] >> TextMorphForEditView(TextMorph)>>handleEdit: >> PluggableTextMorph>>handleEdit: >> PluggableTextMorph>>doIt >> SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [ :morph | morph doIt ] >> BlockClosure>>cull: >> BlockClosure>>cull:cull: >> BlockClosure>>cull:cull:cull: >> KMCategoryBinding>>completeMatch:buffer: >> KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [ :l | l completeMatch: self buffer: aBuffer ] >> Array(SequenceableCollection)>>do: >> KMKeymap>>notifyCompleteMatchTo:buffer: >> KMKeymap>>onMatchWith:notify:andDo: >> >> and #signalError: argument (errorCode) is nil. >> >> any idea? >> >> thanks, >> Esteban > >

Dec. 14, 2013

Re: [Pharo-dev] Another thought about globals

by phil＠highoctane.be

Would be nice to have a view on them like in VW. On Saturday, December 14, 2013, Marcus Denker wrote: > > On 14 Dec 2013, at 16:15, Norbert Hartl <norbert(a)hartl.name<javascript:_e({}, 'cvml', 'norbert(a)hartl.name');>> > wrote: > > > Am 14.12.2013 um 15:58 schrieb kilon alios <kilon.alios(a)gmail.com<javascript:_e({}, 'cvml', 'kilon.alios(a)gmail.com');> > >: > > yes sorry i meant global variables , the ones you define in workspace like > a := 1. > > Those arenât globals. Everything you do in the workspace is compiled as > method (UndefinedObect>>#DoIt) and executed. There are only a handful of > global values and there is the smalltalk dictionary where names can be > looked up. > > They live in the âbindingsâ ivar of Workspace. > > When you compile code with the ârequestorâ not nil, it will put > a OCRequestorScope into the scope chain. > This means that when Opal Semantic analysis asks the scope for the > definition of a name, it will call > #lookupVar: on that scope, which is then doing: > > (requestor bindingOf: name asSymbol) ifNotNil: [:assoc | > ^ OCLiteralVariable new assoc: assoc; scope: self; yourself]. > ^ super lookupVar: name. > > Which means that variables in the Workspace are compiled as literal > variables (like globals), > but the binding comes from a dictionary that is in the ivar âbindingsâ of > the Workspace. > > Marcus > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Dec. 14, 2013

Re: [Pharo-dev] NB FFI problem (calling an universal library)

by Max Leske

Did you check that the library has benn compiled with a C compiler? C++ name mangling doesnât work with NB. Another thing you can do is to attach gdb to the image and break on the gtk_init call. That way you can see at what stage approximately the error occurs. On 14.12.2013, at 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I'm trying to create some stuff with Gtk3, and because of it I have a call to gtk_init using NB-FFI. The call is like this: > > gtkInitArgC: argc argV: argv > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode> > ^ self nbCall: #( void gtk_init ( int *argc, char ***argv ) ) > > > and well, I have a GtkLibrary copied from CairoLibraryLoader who loads the library. > > system is 64bits, but Gtk3 libraries are "universal" compiled (it has both formats, i386 and x86_64 inside). > > GtkLibrary loadGtkLibrary actually loads the library (it answers a pointer to it) and in fact, following the stack track NB is resolving correctly gtk_init symbol... > > Now, the problem is that a call to > > self gtkInitArgC: 0 argV: 0. > > fails... with this stack trace: > > NBFFICallout class>>signalError: > NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: > NBFFICalloutAPI>>function:module: > GtkApplication(Object)>>nbCall: > GtkApplication>>gtkInitArgC:argV: > NBFFICallout class(NBNativeCodeGen class)>>retrySend: > GtkApplication>>gtkInit > GtkApplication>>initialize > GtkApplication class(Behavior)>>new > MarsApplication>>platformApplication > MarsApplication>>stop > MarsApplication>>start > UndefinedObject>>DoIt > OpalCompiler>>evaluate > SmalltalkEditor>>evaluateSelectionAndDo: > SmalltalkEditor>>evaluateSelection > PluggableTextMorph>>doIt in Block: [ textMorph editor evaluateSelection ] > PluggableTextMorph>>handleEdit: in Block: [ result := editBlock value ] > TextMorphForEditView(TextMorph)>>handleEdit: > PluggableTextMorph>>handleEdit: > PluggableTextMorph>>doIt > SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [ :morph | morph doIt ] > BlockClosure>>cull: > BlockClosure>>cull:cull: > BlockClosure>>cull:cull:cull: > KMCategoryBinding>>completeMatch:buffer: > KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [ :l | l completeMatch: self buffer: aBuffer ] > Array(SequenceableCollection)>>do: > KMKeymap>>notifyCompleteMatchTo:buffer: > KMKeymap>>onMatchWith:notify:andDo: > > and #signalError: argument (errorCode) is nil. > > any idea? > > thanks, > Esteban

Dec. 14, 2013

Re: [Pharo-dev] Cleaning a surface/canvas in Athens

by StÃ©phane Ducasse

On Dec 14, 2013, at 11:59 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Just wondering. Isnât a bit strange to have to do this in order to clean a surface: > > -=-=-=-= > surface drawDuring: [:cs | > surface clear. > â¦ > ] > -=-=-=-= > > Shouldnât it be is cs a canvas? I thikn that you misunderstand what is the canvas versus the surface the surface is the physical memory medium and the canvas is a way to write on it. > -=-=-=-= > surface drawDuring: [:cs | > cs clear. > â¦ > ] > -=-=-=-= > instead? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Dec. 14, 2013

Re: [Pharo-dev] About Athens and Cairo

by StÃ©phane Ducasse

For the moment athens use the form buffer so there is a copy that igor would like to kill. Now igor got killed by the textEditor. I hope that he will come back in good shape. The best things to improve the situation is that people with interest like you really invest to understand the underlying library and approach because you cannot thing that they will be able somebody below knowing everything and answering. On Dec 14, 2013, at 9:58 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I have some random questions about the Cairo binding supported by Athens. > > - the rendering is done by the graphic card isnât it? > > - Once rendered, is the produced bitmap copied by the CPU in Pharo? kind of. Yes there is a copy in the FormBuffer. > With Roassal3d, we are facing a problem of performance because there is an unnecessary copy between the graphic card and the Form displayed by Pharo. I guess we have the same problem with Cairo. Yes Now if people would help Igor could focus on fixing that. Now without textEditor = no Athens. > - Is there an example of clipping in Cairo? I thikn that cairo already handle it. > > - Any idea how efficient the clipping is? I mean, will I gain a lot by not displaying elements located outside the visual part or should I leave the clipping do the job? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Dec. 14, 2013