- Pharo-dev - lists.pharo.org

Re: [Pharo-project] smalltalkhub and project ownership

by Esteban Lorenzano

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

> 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] I don't agree with DummyXXX

by Henrik Sperre Johansen

On 21.11.2012 18:55, Mariano Martinez Peck wrote: > > > On Wed, Nov 21, 2012 at 4:50 PM, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > > On 21 November 2012 12:47, Fernando Olivero > <fernando.olivero(a)usi.ch <mailto:fernando.olivero@usi.ch>> wrote: > > I totally agree. Dummy does not tell me about the class. > > > > Are there just 3 uses of Dummy in the core? > > > > We should either use Null or use a specific prefix always, so > its form a > > consisten pattern. > > > > DummyUIManager -> NullUIManager > > > yes, not "Headless" please. > > > why? > > It is not a complete NULL UIManager. A NullUIManager would implement > all the API and do nothing (or implement nothing but only > #doesNotUnderstand: doing nothing or something like that) > DummyUIManger DOES stuff, but it makes sures not to end up calling > the UI (like progress bar, notifications, confirmations, etc). So, in > this particular case, HeadlessUIManager is much more accurate for me > than Null. Same can be said for DummySoundSystem, it does route the Beeper sound to a tangible place. ;) How about MinimalXXX? As in, they do the least amount of things possible to still remain useful in a limited, yet non-null manner. Cheers, Henry

Nov. 22, 2012

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

by Igor Stasenko

On 22 November 2012 12:11, Ciprian Teodorov <ciprian.teodorov(a)gmail.com> wrote: > Hi Igor, > > What is the extent to which callbacks are currently supported in NB? > > On my machine (macos10.6) they do not seem to work properly. The quick sort > test crashes the VM. > hmm. should work fine. Make sure you using updated VM. > What are the limitations of the current implementation? the limitation is multithreading. callback should be called in same thread as VM. another limitation is that callback should be called only during execution of some primitive, or to be more precise. it is only related to interrupt/event handling of VM: no callbacks allowed during interrupt/event handling. but i will get to that once will have a code to check that (like making own callback to handle events from OS) -- Best regards, Igor Stasenko.

Nov. 22, 2012

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

by Igor Stasenko

On 22 November 2012 12:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 November 2012 11:47, Stephan Eggermont <stephan(a)stack.nl> wrote: >> Hi Igor, >> >> The TxText model to me seems to mix two concerns. >> The storage of the text and manipulating it? Both cursor positioning >> and selection manipulation are view dependent, and there might >> be more than one. >> > > No. Please read my other replies to topic. > > - you have text model > - you have positions (in text) > - you have selection which is two positions > - you define operations, like insert, cut, replace which involving > text and positions in them. > - you cannot manipulate(edit) text without using positions > > where you see view dependent stuff? > It is completely orthogonal. > perhaps you talking about 'selection' which is part of TxModel state? then i agree that we may need to separate concerns here: - text storage - text selection. but you can do it even right now: | text selection | text := TxModel new. selection := TxSelection on: text. selection replaceWith: 'ABC'. selection all. selection start moveRight. selection end moveLeft. selection replaceWith: '---'. text asString 'A---C' i think we should remove 'selection' from TxModel class. And instead provide a protocol for getting a new one, i.e.: selection := text newSelection. -- Best regards, Igor Stasenko.

Nov. 22, 2012

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

by Igor Stasenko

On 22 November 2012 11:47, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hi Igor, > > The TxText model to me seems to mix two concerns. > The storage of the text and manipulating it? Both cursor positioning > and selection manipulation are view dependent, and there might > be more than one. > No. Please read my other replies to topic. - you have text model - you have positions (in text) - you have selection which is two positions - you define operations, like insert, cut, replace which involving text and positions in them. - you cannot manipulate(edit) text without using positions where you see view dependent stuff? It is completely orthogonal. > Stephan > > > -- Best regards, Igor Stasenko.

Nov. 22, 2012

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

by StÃ©phane Ducasse

Normally it worked. Stef On Nov 22, 2012, at 12:11 PM, Ciprian Teodorov wrote: > Hi Igor, > > What is the extent to which callbacks are currently supported in NB? > > On my machine (macos10.6) they do not seem to work properly. The quick sort test crashes the VM. > > What are the limitations of the current implementation? > > Thanks > Ciprian >

Nov. 22, 2012

Re: [Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost

by Igor Stasenko

On 22 November 2012 11:19, Max Leske <maxleske(a)gmail.com> wrote: > I have run into a small problem with fork(): > > pid := self primitiveRun. > pid isZero > ifTrue: [ "child code with exec" ] > ifFalse: [ "parent code" ] > > primitiveRun > <primitive: #primitiveNativeCall module: #NativeBoostPlugin> > ^ self nbCall: #( int fork() ) > > Only the parent code is ever executed, #pid is never 0. are you sure about that? if you evaluate self fork it will always answer non-zero.. because it is parent process, where you observing result. But that doesnt means that there is no child process which observes different return value. > Looking at UnixOSProcessPlugin I see that there are some special things Dave did before forking and I'm wondering if these would be necessary with NB. In the method #forkAndExecInDirectory: > 1. possible use of a sig handler > 2. special secure mode handling (what's that?) > 3. turn off the interval timer > > Any ideas? > > Cheers, > Max > > On 21.11.2012, at 08:50, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 20.11.2012, at 21:56, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >>> On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote: >>>> >>>> Providing bindings to fork/pipe kernel functions is piece of cake. >>>> But writing a wrapper around it would be a bit of work.. but still it >>>> is possible. And you should try. >>>> >>>> And yes, using fork() stuff having many treacherous pitfalls, but >>>> don't think that if you call this function from code written in C >>>> instead of NB will make it less treacherous. >>>> I think Dave can give some more input on that, because he also using >>>> fork() in OSProcess. >>> >>> In normal use, the fork() call is immediately followed by an exec(), so >>> it is not tricky at all. The only thing that was tricky to do in OSProcess >>> was forkSqueak() which forks the VM itself and then attempts to continue >>> running. But that is really an unusual use case. >>> >>> The system calls such as fork() and pipe() should work the same whether >>> you are calling from FFI or from generated C in a primitive. You can >>> find examples for many of these calls in OSProcess. In general, the >>> interface to system calls and standard C library functions is in >>> UnixOSProcessPlugin, and the associated glue to tie it into the image >>> is in UnixOSProcessAccessor. I have not looked at it closely but I >>> think that in some cases you could change the methods in UnixOSProcessAccessor >>> to make FFI calls, at least in order to get something working initially >>> (I don't know if the design of OSProcess is what you want, but it could >>> get you started). >>> >> Thanks Dave, that's good to know. >> >> Cheers, >> Max >> >>> Dave >>> >>> >> > > -- Best regards, Igor Stasenko.

Nov. 22, 2012

Re: [Pharo-project] when do we go beta?

by Goubier Thierry

Le 22/11/2012 12:10, StÃ©phane Ducasse a Ã©crit : > do you have slides of your lectures? No. I did an on the fly explanation of the implementation of that model in Smalltalk: http://compilation.gforge.inria.fr/2012_06_Rennes/talks.html#thierry (With just enough Smalltalk to let non-smalltalkers write a bit of code : 30'). I'll try to make the code and the examples available. Thierry > Stef > >>>> I've used Pharo 2.0 for teaching on Monday/Tuesday. Apart from a few bugs here and there, it worked fine (but the bugs were rather annoying to explain to Smalltalk beginners). >>> >>> 2.0 was shaky. I would have used 1.4 for newbies >> >> It worked well enough to teach process network programming with it... >> >>>> At the same time, my production development is on 1.4. >>>> >>>> So I think it could/should go beta soon. I'd be happy if I know some of the core packages won't change under me :) >>> >>> We will. I want to really stabilize now. >> >> +1 >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 22, 2012

Re: [Pharo-project] Metacello Why symbolicversion and not simply tagged version:?

by Tudor Girba

Hi Dale, I think your concerns are not consistent :): - you make a distinction between symbolic and regular versions, but you do not make a distinction between baseline and regular versions. Why not? Because it is good practice to have a proper naming that distinguishes between baseline and the regular versions without having this distinction hardcoded in the engine. And it works just fine. Of course, people can mess it up by having a version called 'baseline', but in practice it works just fine. The same could apply to symbolic versions. - you say that when people load a '1.0' symbolic version they would be confused when they in fact get '1.0.37'. I think it will be equally confusing when the symbolic version is named #'1.0'. The problem is really that the name of the symbolic version should be different. Cheers, Doru On Thu, Nov 22, 2012 at 12:36 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, November 21, 2012 2:34:36 PM > | Subject: Re: [Pharo-project] Metacello Why symbolicversion and not > simply tagged version:? > | > | > | On Nov 21, 2012, at 8:16 PM, Dale Henrichs wrote: > | > | > Doru, > | > > | > I guess because I don't agree that the following statement would be > | > true: > | > > | > there will never be a regular version named 'stable' > | > > | > I know that in git I can have a branch named 'stable' and a tag > | > named 'stable' and that causes problems ... for me. > | > > | > Besides, the set of symbolic versions is not restricted to #stable > | > and #development ... one could choose to define a symbolic version > | > called #default or #'1.0'â¦ > | > | I would not. > > I would not, at least right now... But someday, #stable may not be > sufficient it may be necessary to reason about "the #stable version of > Metacello 1.0 and the #stable version of Metacello 2.0", then #'1.0' and > #'2.0' may turn out to be useful ... > > | I would like that Metacello constraints the space. Because we should > | have less option and more structured supported scenarios. > > I'm not sure that we know the extent of the space quite yet, but for now > we have a convention where we are primarily using only the #stable symbolic > version so we've successfully avoided a proliferation of symbolic versions > which is a good thing ... > > As I do more work with git I see the linear versions become more like tags > of specific git commits with the burden of version management falling onto > git instead of Metacello. Then with platform-specific branches in the git > repository it becomes possible to use a cross branch tag (a linear version) > which may obsolete symbolic versions altogether, but it is way too early in > the learning curve with git to tell... > > | > | > I intend for there to be two namespaces the linear version > | > namespace and the symbolic version namespace to make a clear > | > distinction between the two, because they have different > | > semantics. > | > | Ok it was not clear to me that they have a different semantics. > > I think it is important that we have a language that differentiates > between a linear version '1.0' which refers to a specific set of packages > that do not change over time and a symbolic version #stable (or #'1.0') > which refers to a family of related versions the members of which may > change over time. > > | > | > One shouldn't be surprised that when version #stable of project foo > | > is loaded the current version of the project is '1.0' on one day > | > and '1.1' on the next. > | > | How this can be possible? Ok you mean because the guy changed the > | stable definition. > > Exactly ... symbolic versions were invented exactly because the > "recommended version" changes over time .... > > | > | > Or when they load #'1.0' that the current version is '1.0-beta.19'. > | > > | > This distinction is obviously not important to you and I am okay > | > with that:) > | > > | > Dale > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 22, 2012