- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] smalltalkhub and project ownership

by Esteban Lorenzano

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

Re: [Pharo-project] smalltalkhub and project ownership

by Mariano Martinez Peck

On Thu, 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 > > > sorry, s/gay/guy (mixing english writing with spanish pronunciation) > 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 <https://about.me/sebastianconcept> >> >> 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 > > -- Mariano http://marianopeck.wordpress.com

Nov. 22, 2012

Re: [Pharo-project] smalltalkhub and project ownership

by Mariano Martinez Peck

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 <https://about.me/sebastianconcept> > > 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