November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Morph on focus lost

by Sebastian Sastre

okay, for the record: 1. announcements are exclusive to instances and don't bubble through morph parents/owners* and 2. it works Pharo 2.0 only but I'm okay with that (I've ported the app from 1.4 in ~20min) thanks! sebastian o/ PD: BTW, that thing about making all morphs having its own announcer in the extension, great move! * sounds like it works like that as a feature, I just say it because I found most of the times is convenient that events "bubble" in any case adding bubble to morphs is as simple as: announce: anAnnouncement "Announces anAnnouncement from this morph and, if anAnnouncement is still bubbling, tell its parent to do the same" | aParent | self announcer announce: anAnnouncement. anAnnouncement isBubbling ifTrue:[ aParent := self getBubblingParent. aParent ifNotNil:[ aParent announce: anAnnouncement ]] On Nov 25, 2012, at 5:43 PM, Benjamin wrote: > morphToSpy announcer weak > on: MorphLostFocus send: #spyingMethod to: #spyingReceiver > > :) > > > Ben > On Nov 25, 2012, at 8:35 PM, Sebastian Sastre wrote: > >> Hi guys, >> >> quick question, >> >> what's the equivalent event of blur on morphs? >> >> What event you need to observe in a morph if you need to react to the focus lost in that morph? >> >> sebastian >> >> o/ >> >> >> >> >> >

Nov. 25, 2012

Re: [Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API

by StÃ©phane Ducasse

Igor your proposal looks nice. Stef On Nov 22, 2012, at 2:47 PM, Igor Stasenko wrote: > Hi, > > i am thinking about redesign of FFI top-level api, because it not very good. > > First thing is that NBFFICallout referenced in too many places (187 in > my image). > So, from one side, we should encourage using a convenience syntax, using > > self nbCall: .. > instead of > NBFFICallout ... > > but there's one more thing: > - a code generator has many different ways of use, and i actually > going to add another one, > but i see that it will explode the protocol(s) without make it > convenient to use. > > Imagine that you want to generate a callout to function, which address > cannot be obtained directly from external library. > This is actually a real issue, which Esteban met when implementing > bindings to Chipmunk library: > - some functions are not exposed directly by dynamic library, but indirectly: > the symbol(s) which library exports is not direct pointer(s) to > functions but instead > a pointers to variable, where the function pointer is stored. > So, in order to get function pointer , one needs first to get a > pointer to symbol, and then read the pointer value at that address. > > So, i thought that i would simply add new protocol to NBFFICallout: > > call: anonFunctionSignature convention: callConvention > functionAddress: aFunctionAddressBlock > > Then, one could use it like: > > myMethod > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > > > ^ NBFFICallout > call: #( int () ) > convention: #cdecl functionAddress: [ self > getPointerTo: 'functionname' ] > > but it is too elaborate.. > you can imagine that if one would like to implement a more convenient > form, he could just do: > > myMethod > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > > > ^ self indirectCall: #( int () ) name: 'functionname' > > or even: > > myMethod > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > > > ^ self indirectCall: #( int functionname () ) > > now the problem is that you cannot wrap the NBFFICallout method in > order to implement convenience method, because of use of thisContext. > > I also concerned about exploding NBFFICallout public API.. which imo > doesn't makes much sense, because we should encourage the use of > convenience methods. > > So, i looking for improving public API: > > - First thing is getting rid of direct references to NBFFICallout.. > - second thing is avoid tying public API with thisContext (so you can > create own convenience methods without much hassle). > > So, lets imagine what and how we can do it: > > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ NBFFICallout cdecl: #( int foo() ) module: 'bar' > > 1. getting rid of global: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout cdecl: #( int foo() ) module: 'bar' > > 2. separating the call convention from signature: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout cdecl call: #( int foo() ) module: 'bar' > > 3. as a bonus, since cdecl is most used, we can assume it is default: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout call: #( int foo() ) module: 'bar' > > 4. avoid hardcoding module: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout call: #( int foo() ) module: self module > > 5. pass code generation options as a separate message, instead of > additional keyword: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self nbCallout > options: #( +optFoo - optBar); > call: #( int foo() ) module: self module > > 6. finally users would want to do it in most convenient way: > > foo > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > > ^ self call: #( int foo() ) > > Which means that #call: is convenience method which they implement by > themselves. > Here how i think it should look like: > > call: fnSpec > > ^ (self nbCalloutIn: thisContext sender) > cdecl; > options: #(+optFoo - optBar); > call: fnSpec module: self module. > > If you look at current implementation of Object>>nbCall: > > nbCall: fnSpec > " you can override this method if you need to" > > | sender | > sender := thisContext sender. > > ^ NBFFICallout > handleFailureIn: sender > nativeCode: [ :gen | > gen > sender: sender; > callType: self nbCallingConvention; > generateCall: fnSpec module: self nbLibraryNameOrHandle] > > it is almost the same, except from cryptic use of blocks, and private > internal NBFFICallout methods which doing the job. > > So, basicly, i want to get rid of NBFFICallout class >> > [cdecl/stdcall]: module: [options:] > [cdecl/stdcall]: emitCall: [options:] > > and replace them with #call:module: and #call: emit: > and also add new one: > #call:address: > > which can be used for passing a function pointer directly. > > And any future extensions to public API will be a single method. Not > 2,3 or more, like today.. > > > -- > Best regards, > Igor Stasenko. >

Nov. 25, 2012

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by Igor Stasenko

On 25 November 2012 21:27, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Yes. you are right. It was bad password. > I not think about it because when I load code from smalltalkhub system was > ask me for password. But It was not check it correctness. > > I uploaded version with class comment and refactored tests. Good.! THanks a lot. > > 2012/11/25 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >> >> When i got a 400 Bad request it's because of wrong password. >> >> >> Ben >> >> On Nov 25, 2012, at 8:05 PM, StÃ©phane Ducasse wrote: >> >> > are you sure that you are using your account? >> > Because it happened to me too. >> > >> > Stef >> > >> > On Nov 25, 2012, at 3:08 PM, Denis Kudriashov wrote: >> > >> >> 2012/11/22 Igor Stasenko <siguctua(a)gmail.com> >> >>>> Hello. >> >>>> >> >>>> Can you add me as project contributor. I try to upload version with >> >>>> detailed comment from my first mail but can't. >> >>> >> >>> >> >>> My smalltalkhub nickname "dionisiy" >> >> >> >> done >> >> >> >> I try to commit version (with comment) but 400 bad request error >> >> raised. >> >> But I see myself as contributor at smalltalkhub project page. >> >> Any ideas? >> >> >> >> >> > >> > >> >> > -- Best regards, Igor Stasenko.

Nov. 25, 2012

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by Denis Kudriashov

Yes. you are right. It was bad password. I not think about it because when I load code from smalltalkhub system was ask me for password. But It was not check it correctness. I uploaded version with class comment and refactored tests. 2012/11/25 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > When i got a 400 Bad request it's because of wrong password. > > > Ben > > On Nov 25, 2012, at 8:05 PM, StÃ©phane Ducasse wrote: > > > are you sure that you are using your account? > > Because it happened to me too. > > > > Stef > > > > On Nov 25, 2012, at 3:08 PM, Denis Kudriashov wrote: > > > >> 2012/11/22 Igor Stasenko <siguctua(a)gmail.com> > >>>> Hello. > >>>> > >>>> Can you add me as project contributor. I try to upload version with > >>>> detailed comment from my first mail but can't. > >>> > >>> > >>> My smalltalkhub nickname "dionisiy" > >> > >> done > >> > >> I try to commit version (with comment) but 400 bad request error raised. > >> But I see myself as contributor at smalltalkhub project page. > >> Any ideas? > >> > >> > > > > > > >

Nov. 25, 2012

Re: [Pharo-project] ProfStef on steroids (was: Athens OpenGL backend - what does it mean?)

by dimitris chloupis

Well at this moment all I can tell you is that I named the tool as "Prometheas" its part of the "Proteas" realm of Ephestos . The Proteas realm of Ephestos is dealing with code and in this case documentation. What I am doing at the moment is trying to hack workspace into making more capable , if that is correct term because in the end is a morph and morphs are pretty flexible stuff already, to embed documentation similar to the interactive ProfStef Tutorial. So most likely I will offer a new Workspace that will be able to display more neatly interactive tutorials and allow the user of course to manipulate the code of those tutorials for his little experiments. There are some vague ideas but at the moment I am just exploring the Workspace class and trying to see how I can modify it to suit my needs. All my Ephestos code is commited in squeaksource3 , here to be exact , but at the moment there is nothing to show I hope there is going to be in the not so distant future -> ss3.gemstone.com/ss/Ephestos ________________________________ From: Sebastian Nozzi <sebnozzi(a)gmail.com> To: dimitris chloupis <thekilon(a)yahoo.co.uk> Cc: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, 25 November 2012, 20:47 Subject: ProfStef on steroids (was: Athens OpenGL backend - what does it mean?) Interesting... can you share some details about it already? Or is it too soon...? When I read your past discussion about the help-system not being able to show "figures" (I think Igor pointed it out) I thought: "wait a second, why is it not possible to "embed" Morphs into the text?". I thought I had seen something like that in the past before... (in Squeak). 2012/11/25 dimitris chloupis <thekilon(a)yahoo.co.uk>: > As a first part I am in the process of creating a tutorial generator which > will be ProfStef on steroids for at first offering tutorial for Athens and > later used for any kind of Pharo tutorial.

Nov. 25, 2012

Re: [Pharo-project] Athens OpenGL backend - what does it mean?

by dimitris chloupis

Ephestos as a project is not new . It started as blender addon details can be found here -->Â http://blenderartists.org/forum/showthread.php?250375-A-Visual-Programming-… Because the thread is kinda huge to sum it up what I and another blender developer did was to take morphic for python ( http://www.chirp.scratchr.org/blog/?p=30 ) which was written for python 2 and pygame and port it to python 3 , bgl (its a thin wrapper for opengl 1 blender library ) and as a blender addon. 240 commits later we had a morphic interface for blender written in python and ported to bgl so it could run from inside the blender window. Suprisingly we did not have so much problem with out own bugs but bgl proven too slow , buggy and unreliable so I had to abandon because I could only solve that problem with hacking blender source which is written in C and is almost not commented at all. Lets say here I am no big fan of C language of Blender source.Â Here you can find if you are interested the final blender python code ---> https://github.com/kilon/EphestosOld >From there on I was just searching for a home for Ephestos. I has quite reluctant to join pharo because of the lack of developers and because I am not that familiar with smalltalk as much I am with python. To be frank I am not that motivated to join a language that is has a very small community because of bug fixes and library support. I actually even looked into common lisp and emacs very recently as well since I really like lisp as a language and I prefer from smalltalk. But it has become obvious to me that what I am trying to do for Ephestos is synonymous to what smalltalk is trying to do, to offer a live visual environment that makes code , fun , flexible and efficient. So I decided to take the deep dive into pharo. Smalltalk may not be super popular as python but porting all smalltalk stuff or even just little to python is just insane amount of work so I think I made the sensible choice to port my project to Pharo because it was already based on pharo libraries anyway. Saying that I am still interested in offering some Blender support for Ephestos and thus making pharo able to quickly communicate with blender probably via a socket bridge. I got all these crazy ideas but I am willing to take them a step at a time , so that is why I talked about "decades". ________________________________ From: Sebastian Nozzi <sebnozzi(a)gmail.com> To: dimitris chloupis <thekilon(a)yahoo.co.uk> Cc: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, 25 November 2012, 20:43 Subject: Re: [Pharo-project] Athens OpenGL backend - what does it mean? Wow!!! You have no idea how incredible I found to be reading something like this: "I am willing to invest years and if all goes well even decades of efforts since its an area that I love to code for". It definitely made my day! :-) Especially the last part, that you really *love* to code in this area (something I cannot but admire). I always found the Squeak/Pharo environment so cool to code in, the "aliveness" of the image, but also had the feeling that the graphics system was a little outdated. Unfortunately being unable to do something about it, first because I have no expertise in the area, and second, because... well... I guess I'm lazy and not patient/talented enough for graphics programming ;-). It is therefor great that Igor and now you showed up, able to improve in this area, and also willing :-) To sum it up: I always thought that open-source Smalltalk should *look* as great from the "outside" as it is cool on the "inside" (the semantics). It simply deserves no less. So I am really grateful for any effort put in this. Pharo already looks great, much has been archived, and I can't wait to see what you guys will come up with next... Best regards, Sebastian 2012/11/25 dimitris chloupis <thekilon(a)yahoo.co.uk>: > "eye candy" wise this is exactly the focus of my Ephestos project , Morpheas > section. A custom gui , gui designers for easy creating of GUIs by the user > and additional moprh widget with customized look including eye candy. > > I can't make any promises, as I have no clue what kind of obstacles and > technical limitations I am going to find in the process but I can tell you I > am willing to invest years and if all goes well even decades of efforts > since its an area that I love to code for. > > As a first part I am in the process of creating a tutorial generator which > will be ProfStef on steroids for at first offering tutorial for Athens and > later used for any kind of Pharo tutorial. > > I am also interested in helping Athens porting to OpenGL and generally using > NBOpenGL as the next step for Morphic. Excitting stuff the only thing it > worries me is the type of technical blocks / obstacles I may come across but > trying is certainly well worths it. > > > ________________________________ > From: Sebastian Nozzi <sebnozzi(a)gmail.com> > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, 24 November 2012, 17:06 > Subject: [Pharo-project] Athens OpenGL backend - what does it mean? > > Hello Pharo Devs, > > I am really excited about the direction Pharo is taking regarding many > areas - one of them being the graphics. I played with Athens a bit and > it's cool to see anti-aliased vectror graphics coming to Pharo. > > I keep reading about a possible OpenGL back-end in the future... what > would this mean exactly? > > For years I have been "dreaming" about graphic-accelerated "eye-candy" > effects inside of the Smalltalk environment. Like compiz-fusion > effects in Linux, or Quartz-Extreme powerded in OS-X (ExposÃ©, etc.). > > Would this be possible with such a back-end? Or am I misinterpreting > things? I'm not a graphic-dev expert. > > Best regards, > > Sebastian > > >

Nov. 25, 2012

Re: [Pharo-project] Morph on focus lost

by StÃ©phane Ducasse

thanks Master :) On Nov 25, 2012, at 8:49 PM, Benjamin wrote: > Nop, > > because the focus stay even when the mouse leave the bounds of the morph :) > > Ben > > On Nov 25, 2012, at 8:46 PM, StÃ©phane Ducasse wrote: > >> may be >> >> mouseLeave: evt >> "Handle a mouseLeave event, meaning the mouse just left my bounds with no button pressed. The default response is to let my eventHandler, if any, handle it." >> >> >> Stef >> >> On Nov 25, 2012, at 8:35 PM, Sebastian Sastre wrote: >> >>> Hi guys, >>> >>> quick question, >>> >>> what's the equivalent event of blur on morphs? >>> >>> What event you need to observe in a morph if you need to react to the focus lost in that morph? >>> >>> sebastian >>> >>> o/ >>> >>> >>> >>> >>> >> >> > >

Nov. 25, 2012

Re: [Pharo-project] Morph on focus lost

by Benjamin

Nop, because the focus stay even when the mouse leave the bounds of the morph :) Ben On Nov 25, 2012, at 8:46 PM, StÃ©phane Ducasse wrote: > may be > > mouseLeave: evt > "Handle a mouseLeave event, meaning the mouse just left my bounds with no button pressed. The default response is to let my eventHandler, if any, handle it." > > > Stef > > On Nov 25, 2012, at 8:35 PM, Sebastian Sastre wrote: > >> Hi guys, >> >> quick question, >> >> what's the equivalent event of blur on morphs? >> >> What event you need to observe in a morph if you need to react to the focus lost in that morph? >> >> sebastian >> >> o/ >> >> >> >> >> > >

Nov. 25, 2012

Re: [Pharo-project] Morph on focus lost

by StÃ©phane Ducasse

may be mouseLeave: evt "Handle a mouseLeave event, meaning the mouse just left my bounds with no button pressed. The default response is to let my eventHandler, if any, handle it." Stef On Nov 25, 2012, at 8:35 PM, Sebastian Sastre wrote: > Hi guys, > > quick question, > > what's the equivalent event of blur on morphs? > > What event you need to observe in a morph if you need to react to the focus lost in that morph? > > sebastian > > o/ > > > > >

Nov. 25, 2012

Re: [Pharo-project] Morph on focus lost

by Benjamin

morphToSpy announcer weak on: MorphLostFocus send: #spyingMethod to: #spyingReceiver :) Ben On Nov 25, 2012, at 8:35 PM, Sebastian Sastre wrote: > Hi guys, > > quick question, > > what's the equivalent event of blur on morphs? > > What event you need to observe in a morph if you need to react to the focus lost in that morph? > > sebastian > > o/ > > > > >

Nov. 25, 2012