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

[Pharo-project] Athens, Nativeboost and Igor's gray hair

by Esteban Lorenzano

Hi, Last week I've been sick, and because of that I've been bored. To get some fun I started to learn NativeBoos and Athens (and to stress Igor's patience on explain things :). After all, I prototyped a couple of examples that I think are fun: 1) AthensPlayground. This is a workspace prepared to fast-prototype athens animations (taking the same idea of http://www.processing.org/) You can see a video of the (for now) results here: http://youtu.be/NaR_fyk3qq4 I think it can be a good addition for people willing to do some animation work :) 2) After that, of course I was very happy, but I thought "why to stop there? now I want more!" and so, I made a quick search about physics library and after a couple of hours I made a (very primitive) Chipmunk usage framework and an even more primitive and simple "game engine like" framework, to mix both Athens and Chipmunk library. A video of the results can be found here: http://youtu.be/ZK-JlbeN09A Pretty cool, isn't? Ok, I know... is not like I invented the hot water, all of this was more or less present in morphic... but is cool to have real examples on using external libraries (also, physics are really hard to simulate, so... better to use something already existent). If you want to play with it, you can go to: http://smalltalkhub.com/#!/~estebanlm/Storm Enjoy :) Esteban

Nov. 22, 2012

Re: [Pharo-project] smalltalkhub and project ownership

by Camillo Bruni

On 2012-11-22, at 11:01, "Torsten Bergmann" <astares(a)gmx.de> wrote: >> We should keep in mind that Smalltalkhub is still under development :) >> >> And our poor Nicolas is running out of time (too many things to do) :D > > Sorry for reminding on this: I see a clear downside of all > this since smalltalk hub is currently very concentrated on > one person and his time schedule. > > I'm sure the next version of SmalltalkHub will provide > many new wanted features and it is a great system and service for Pharo. > > On the other side now two communities waiting for Nicolas to > bring something more awesome (see Amber [1]) ;) > > Yes SH is open source - but it would help if the impatient community > would be able to participate in one or the other way or follow > this new development... > > A ConfigurationOfSmalltalkHub would be a start ... ...or work on help improving git for Pharo (sorry I had to..)

Nov. 22, 2012

Re: [Pharo-project] smalltalkhub and project ownership

by Norbert Hartl

Am 22.11.2012 um 13:47 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: >> Is there an explanation why in smalltalkhub every project resides below a user? > > > because things in this universe don't get done if someone isn't leading it? :D > > the leader of any project is (a) the curator of that project and (b) the one positioned to better inspire followers > > if people likes it, people follows the project and/or the guy > > if someone doesn't like the direction, that person can fork and lead it himself in another direction > > github got it right, I'm glad smalltalkhub too > > and it's not about mimicking github (which wouldn't be bad) it's mimicking the way people want to work > > it's about natural selection applied to software projects at its best > > makes sense? partially. Don't want to extend it here! > > PD: if someone abandons a project, no big deal, it will be there hanging out while another fork might be flourishing. Also projects property should be transferrable from one user to another for the cases in which that happens orderly. > > Yep, that is my point. I didn't want to argue against anything smalltalkhub does. Regardless if you mimick github or "the way people want to work[â¢]" you need to have basic functionality. In github forks are connected so I always see where a thing comes from. By just copying stuff we will produce a mess. Someone that encounters smalltalkhub will then see 5 slightly different copies of the same thing and he couldn't estimate which one is the one to go first. So my question was if there is an idea how to solve this in smalltalkhub. No matter if it exists already or is being planned. Norbert

Nov. 22, 2012

[Pharo-project] smalltalkhub and project ownership

by Torsten Bergmann

>We should keep in mind that Smalltalkhub is still under development :) > >And our poor Nicolas is running out of time (too many things to do) :D Sorry for reminding on this: I see a clear downside of all this since smalltalk hub is currently very concentrated on one person and his time schedule. I'm sure the next version of SmalltalkHub will provide many new wanted features and it is a great system and service for Pharo. On the other side now two communities waiting for Nicolas to bring something more awesome (see Amber [1]) ;) Yes SH is open source - but it would help if the impatient community would be able to participate in one or the other way or follow this new development... A ConfigurationOfSmalltalkHub would be a start ... Bye T. [1] http://forum.world.st/A-few-days-with-Nicolas-td4638661.html

Nov. 22, 2012

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

by Igor Stasenko

On 22 November 2012 10:45, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> >>>> I would prefer a notification(s) to be in a separate layer: >>>> >>> >>> ActiveText? >> >> you suggest the name? > yes controller sucks > hehe.. yes.. i didn't thought actually what name is better.. at that point i was use random name to indicate my intent. :) -- Best regards, Igor Stasenko.

Nov. 22, 2012

Re: [Pharo-project] NativeBoost callbacks - status?

by Igor Stasenko

i will check. I didn't merged with your code, Ciprian yet.. does it crashing for NativeBoost-Core-IgorStasenko.78 or in your code? i will merge your stuff and check. -- Best regards, Igor Stasenko.

Nov. 22, 2012

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

by Igor Stasenko

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. 22, 2012

Re: [Pharo-project] smalltalkhub and project ownership

by Sebastian Sastre

we need the fork feature then very important biology is: (a) mutation (b) natural selection we already have b, forking would give us a sebastian o/ On Nov 22, 2012, at 10:51 AM, Esteban Lorenzano wrote: > yes, you're right, but Norbert point is that, right now, you cannot fork the project (and you should be able to do it) > > Esteban > > On Nov 22, 2012, at 1:47 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >>> Is there an explanation why in smalltalkhub every project resides below a user? >> >> >> because things in this universe don't get done if someone isn't leading it? :D >> >> the leader of any project is (a) the curator of that project and (b) the one positioned to better inspire followers >> >> if people likes it, people follows the project and/or the guy >> >> if someone doesn't like the direction, that person can fork and lead it himself in another direction >> >> github got it right, I'm glad smalltalkhub too >> >> and it's not about mimicking github (which wouldn't be bad) it's mimicking the way people want to work >> >> it's about natural selection applied to software projects at its best >> >> makes sense? >> >> sebastian >> >> o/ >> >> PD: if someone abandons a project, no big deal, it will be there hanging out while another fork might be flourishing. Also projects property should be transferrable from one user to another for the cases in which that happens orderly. >> >> >

Nov. 22, 2012

Re: [Pharo-project] smalltalkhub and project ownership

by Sebastian Sastre

democracy or benevolent dictatorship (works for linux) or whatever you guys want beware, 100% consensus isn't always achievable, so don't make the project pay for wanting it this is how it could be: 1. decide among you who is going to lead 2. the leader invites people to follow (starting by the inner circle) 3. ignore any noise the project moves forward, the community profits from things done and the community knows who's behind the project* sebastian o/ * BTW there is an idea for smalltalk hub that I thing don't even github got it yet: an incentive for meritocracy you only need to expose that inner circle of people. No need to be a group feature, just a top ten of people that had its push requests accepted. That ranking would be permanently answering an important social question the audience will ask itself all the time: "who's helping this guy to get this done?" On Nov 22, 2012, at 10:53 AM, Mariano Martinez Peck wrote: > And what happens where is isnt't ONE gay? say there are 3 or 4 guys in the community that manage the project? what should we do? create a user named after the project? hahaha > > On Thu, Nov 22, 2012 at 1:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yes, you're right, but Norbert point is that, right now, you cannot fork the project (and you should be able to do it) > > Esteban > > > On Nov 22, 2012, at 1:47 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >>> Is there an explanation why in smalltalkhub every project resides below a user? >> >> >> because things in this universe don't get done if someone isn't leading it? :D >> >> the leader of any project is (a) the curator of that project and (b) the one positioned to better inspire followers >> >> if people likes it, people follows the project and/or the guy >> >> if someone doesn't like the direction, that person can fork and lead it himself in another direction >> >> github got it right, I'm glad smalltalkhub too >> >> and it's not about mimicking github (which wouldn't be bad) it's mimicking the way people want to work >> >> it's about natural selection applied to software projects at its best >> >> makes sense? >> >> sebastian >> >> o/ >> >> PD: if someone abandons a project, no big deal, it will be there hanging out while another fork might be flourishing. Also projects property should be transferrable from one user to another for the cases in which that happens orderly. >> >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 22, 2012

Re: [Pharo-project] smalltalkhub and project ownership

by Benjamin

We should keep in mind that Smalltalkhub is still under development :) And our poor Nicolas is running out of time (too many things to do) :D Ben On Nov 22, 2012, at 1:55 PM, Esteban Lorenzano wrote: > team support is coming soon :) > > On Nov 22, 2012, at 1:53 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> And what happens where is isnt't ONE gay? say there are 3 or 4 guys in the community that manage the project? what should we do? create a user named after the project? hahaha >> >> On Thu, Nov 22, 2012 at 1:51 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> yes, you're right, but Norbert point is that, right now, you cannot fork the project (and you should be able to do it) >> Esteban >> >> >> On Nov 22, 2012, at 1:47 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> >>>> Is there an explanation why in smalltalkhub every project resides below a user? >>> >>> >>> because things in this universe don't get done if someone isn't leading it? :D >>> >>> the leader of any project is (a) the curator of that project and (b) the one positioned to better inspire followers >>> >>> if people likes it, people follows the project and/or the guy >>> >>> if someone doesn't like the direction, that person can fork and lead it himself in another direction >>> >>> github got it right, I'm glad smalltalkhub too >>> >>> and it's not about mimicking github (which wouldn't be bad) it's mimicking the way people want to work >>> >>> it's about natural selection applied to software projects at its best >>> >>> makes sense? >>> >>> sebastian >>> >>> o/ >>> >>> PD: if someone abandons a project, no big deal, it will be there hanging out while another fork might be flourishing. Also projects property should be transferrable from one user to another for the cases in which that happens orderly. >>> >>> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Nov. 22, 2012