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

Re: [Pharo-project] PBE1 update to Pharo 1.4 Re: Some Newbie problems

by StÃ©phane Ducasse

On May 6, 2012, at 2:17 PM, Mariano Martinez Peck wrote: > > > On Sun, May 6, 2012 at 12:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> > > > > The new book focuses on different issues than the old book. It would be sad to let the old book languish entirely and end up with a poor first impression for newcomers, so I am willing to participate in updating it to Pharo 1.4. I am getting a lot from Pharo and this is something I can contribute. I think it fair the main developers continue with implementing and documenting the advanced features, while the community maintains the more established things. A quick scan pegs this effort at updating about 170 images, plus hopefully a minimal amount of text. How would I proceed with this? > > > > > That would be AWESOME. Really. > > > cheers -ben > > Thanks ben. > I think that the first volume of the book is on git hub so you can simply go ahead. > > https://github.com/SquareBracketAssociates/ > > May be you should register to the she mailing-list mailing-list and mention your effort. > > > Sbe-discussion(a)iam.unibe.ch, discussion for now. I do not know if the other is open > or > "sbe(a)iam.unibe.ch Example" <sbe(a)iam.unibe.ch>, > > ? > > > -- > Mariano > http://marianopeck.wordpress.com >

May 6, 2012

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by Guillermo Polito

On Sun, May 6, 2012 at 2:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > <snip> > I'm more worried about having all-platforms-specific-stuff inside image... > but we can mitigate that with fuel, and making loadable packages when > running the image... I don't know, I'm just thinking while writing, so, > this is probably stupid :) > > Just think how many times you took a development image and used it in several platforms. At least I don't. Same happened when I used Eclipse. I didn't share my eclipses between systems. Even, I had several eclipse installations with their own plugins (just like images, hehe). Probably with jenkins, metacello, and kernel/bootstrap we can generate distributions per platform (With the possibility of an all-in-one distribution for the ones who like that). Guille

May 6, 2012

[Pharo-project] Command Line Handling

by Sean P. DeNigris

I've played a lot with the new command line argument handling. Here's a few thoughts: * I think we should not allow the use of raw handler names (e.g. 'eval') and restrict ourselves to flags. For example, disallow 'eval' and stick to '-e' or '--evaluate'. The raw name introduces ambiguity in parsing the command line, especially since custom commands can be added at will that may conflict and see next item... * The current implementation chooses the single matching handler with the highest priority, but usually command line tools may have multiple non-conflicting flags * The priority concept seems premature. It adds complexity and confusion (the handler for a specific flag is not obvious because it emerges from an interaction of all the handlers). Maybe a registry would be better? A dictionary could just map flags to handlers e.g. -e -> EvalHandler, --evaluate -> EvalHandler, etc. Sean -- View this message in context: http://forum.world.st/Command-Line-Handling-tp4612779.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 6, 2012

Re: [Pharo-project] PBE1 update to Pharo 1.4 Re: Some Newbie problems

by Mariano Martinez Peck

On Sun, May 6, 2012 at 12:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > >> > > > > The new book focuses on different issues than the old book. It would be > sad to let the old book languish entirely and end up with a poor first > impression for newcomers, so I am willing to participate in updating it to > Pharo 1.4. I am getting a lot from Pharo and this is something I can > contribute. I think it fair the main developers continue with implementing > and documenting the advanced features, while the community maintains the > more established things. A quick scan pegs this effort at updating about > 170 images, plus hopefully a minimal amount of text. How would I proceed > with this? > > > That would be AWESOME. Really. > > cheers -ben > > Thanks ben. > I think that the first volume of the book is on git hub so you can simply > go ahead. > https://github.com/SquareBracketAssociates/ > May be you should register to the she mailing-list mailing-list and > mention your effort. > > Sbe-discussion(a)iam.unibe.ch, or "sbe(a)iam.unibe.ch Example" <sbe(a)iam.unibe.ch>, ? -- Mariano http://marianopeck.wordpress.com

May 6, 2012

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by Esteban Lorenzano

On May 6, 2012, at 1:16 PM, Nicolas Cellier wrote: > 2012/5/6 Esteban Lorenzano <estebanlm(a)gmail.com>: >> Hi, >> >> On May 6, 2012, at 9:45 AM, Nicolas Cellier wrote: >> >>> 2012/5/6 Igor Stasenko <siguctua(a)gmail.com>: >>>> On 5 May 2012 18:00, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>> >>>>> >>>>> On Fri, May 4, 2012 at 6:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>>> >>>>>> Hi, David, all >>>>>> >>>>>> i just want to know, if we can use FFI calls, for implementing an >>>>>> OSProcessPlugin functionality (or at least most of it). >>>>>> and if there parts which is hard to implement, i would like to know >>>>>> what and why. >>>>> >>>>> >>>>> Once we have the threaded FFI and the threaded VM then yes, because one can >>>>> block one thread in a read without blocking the entire VM. But without the >>>>> threaded VM one needs asynchronous i/o. >>>>> >>>> yes, but nobody said, that i can't use non-blocking i/o. >>>> >>>> the main advantage which i see for using FFI is being able to deal >>>> with everything at language level. >>>> so, bugs can be fixed quickly, things can be improved more easily etc etc.. >>>> and the main disadvantage is, of course, speed. >>>> >>> >>> No. >>> The main disadvantage is to expose the complexity of outside world at >>> user face, when it was once hidden under the VM carpet. >> >> And why is that a disadvantage? This is smalltalk. "Users" are developers, not ben laden... is not like we are going to do terrible things with that power. Even if we are newbies, worst thing that can happen is to make mistakes while learning... same as today :) >> > > Well, simplicity is also a goal. A system that a single person can > understand... Think Cuis. > Especially in Smalltalk there is nothing private, API are not that > easy to identify and it's so easy to use a package at the wrong > level... yeah, is a goal, but also is a goal "everyone being capable to modify their system", and that is much easy if all system lives inside image, and not hidden in a plugin. > > Also, another drawback is having to mirror all the foreign system in > your image (like you are on Mac intel and have plenty of code for > handling Linux libraries, Windows, Solaris, FreeBSD, Smartphones > etc...). > Unless you automatically load those packages at startup (and more > difficult, unload at snapshot)... well nobody (except Marcus and myself) complains against one-click packaging, and it's exactly that :) nah, seriously: yes, this is an issue and we need to think about that to have a good solution (btw, OSProcess and many other plugins are also not available for all platforms, just mac, win and linux). > >>> In the VM, complexity is handled with the "right tools" (cough...) >> >> your "cough" is right :). Right tools is what does our life easier, not what is closer to the hardware. >> >>> #include machine_specific_stuff.h driven by #ifdef >>> why_the_hell_is_it_so_complex ;) and include paths library paths >>> ldconfig etc... >>> It's of course cough-able because this complexity then spread into m4 >>> macros for configure scripts and other such niceties. >>> >>> Sure, >>> - when the VM is not able to handle outside world zoo because a lack >>> of manpower, and because the outside world changed too fast while we >>> were sleeping happy in our mickey world, >>> - or if we want more than least common denominator between several >>> underlying platforms, >>> then yes, it might be better to adopt your strategy, because we can >>> get more manpower at image level than at VM level... >> >> this is an important issue: is easier to maintain at smalltalk level than c level. And there are more willing hands to code :) >> >>> However, it's a kind of pact with the devil: we get the power at the >>> price of introducing the #ifdef hell in the image. >> >> That's simply not true... look at dbxtalk code, if you want. We could do a plugin to deal with that, but we did it with FFI. Plain smalltalk and straightforward (real problem is to compile opendbx libraries, in fact... and I would love to replace them with smalltalk code, but those are just dreams) >> > > Exactly, it may remain a dream... > It's not true in this specific case because opendbx took all the > burden of ubiquity... That's why it is so complex to compile ;) in fact, opendbx just provides a common api to different backends... and that's perfectly doable in smalltalk (also it should be much easier than doing it in C) > >>> Sure, with a good object model, we might think that it will be easier >>> to handle such complexity. >> >> +1 >> >>> But then we're just ignoring the efforts of hordes of programmers >>> maintaining this shit, and redo all in image. >> >> horde of programmers (me, for instance) will be most than pleased to be ignored in this case :) >> > > It's not the problem of ignoring, it's more the problem of under > estimating the required work... problem is that if you have "right tool" (and I think Pharo is), complexity is automatically reduced :) > >>> I'm not sure that it will be sustainable... >>> Unless of course we focus on a single platform. >> >> right now OSProcess is also a hell... if Dave chooses to do something else, we are in problems. I prefer a hell in smalltalk than a paradise in C (and of course, vm is not a paradise :) >> >>> Your work is very important, because at least, it will enable powerful >>> single platform extensions. >>> But as you see, I just wonder how it would help us to continue >>> providing ubiquity... >> >> Same as today, but in a better way :) >> >> Lot of plugins don't need to be in VM side if we have a powerful FFI, with callbacks and threads. >> I think (as a smalltalk programmer and as a vm programmer) that if we can move to image side those plugins, we can focus in the real complexity of the vm, and after all do better things. >> > > There's something that always amazed me: plugins are supposed to be > pluggable and while I understand why they depend on some Kernel-VM > services, i don't really see why the contrary has to be true. Is it a > packaging problem? A distribution problem? Is because they are not plugins at all, because without them image don't start (think on FilePlugin, for instance... since image need it to load changes and sources, you can't drop it âunless we put sources inside image), but well... there are more. I think is a design problem (and by the way, a design problem we can solve by having plugins inside image :P) > > I'm all for a better and more powerfull FFI (without threading we > can't have efficient asynchronous IO implemented at image level, just > a poor man polling one indeed...) > But I continue to think there is a price. Is the unix style select() > ubiquitous or should I use WaitForMultipleObject() on Windows? Are > specification of read/write streams implementation machine independant > (bsd/sysv/others...) - AFAIR the selection is implemented with > macros... are the fcntl call to set non blocking portable ? Every benefit has its drawbacks... and we need to take steps to mitigate them... but I just don't think in this case we can list "overcomplexity" as a drawback, I think is quite the opposite: it will reduce accidental complexity (essential complexity will always be there: in a plugin or in Pharo). I'm more worried about having all-platforms-specific-stuff inside image... but we can mitigate that with fuel, and making loadable packages when running the image... I don't know, I'm just thinking while writing, so, this is probably stupid :) Esteban > > Nicolas > >> >>> >>> Nicolas >>> >>>>>> >>>>>> If you want to ask, why one would want to do this.. the answer is simple: >>>>>> we stated previously, that we want to reduce the VM complexity by >>>>>> implementing things at language side, when it possible, >>>>>> leaving only key parts to VM. >>>>>> This is the main reason why i consider implementing OSProcess using >>>>>> purely FFI, not because of quality of OSProcessPlugin >>>>>> implementation etc. >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> best, >>>>> Eliot >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >> >> >

May 6, 2012

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by Nicolas Cellier

2012/5/6 Esteban Lorenzano <estebanlm(a)gmail.com>: > Hi, > > On May 6, 2012, at 9:45 AM, Nicolas Cellier wrote: > >> 2012/5/6 Igor Stasenko <siguctua(a)gmail.com>: >>> On 5 May 2012 18:00, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> >>>> On Fri, May 4, 2012 at 6:23 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>> Hi, David, all >>>>> >>>>> i just want to know, if we can use FFI calls, for implementing an >>>>> OSProcessPlugin functionality (or at least most of it). >>>>> and if there parts which is hard to implement, i would like to know >>>>> what and why. >>>> >>>> >>>> Once we have the threaded FFI and the threaded VM then yes, because one can >>>> block one thread in a read without blocking the entire VM. Â But without the >>>> threaded VM one needs asynchronous i/o. >>>> >>> yes, but nobody said, that i can't use non-blocking i/o. >>> >>> the main advantage which i see for using FFI is being able to deal >>> with everything at language level. >>> so, bugs can be fixed quickly, things can be improved more easily etc etc.. >>> and the main disadvantage is, of course, speed. >>> >> >> No. >> The main disadvantage is to expose the complexity of outside world at >> user face, when it was once hidden under the VM carpet. > > And why is that a disadvantage? This is smalltalk. "Users" are developers, not ben laden... is not like we are going to do terrible things with that power. Even if we are newbies, worst thing that can happen is to make mistakes while learning... same as today :) > Well, simplicity is also a goal. A system that a single person can understand... Think Cuis. Especially in Smalltalk there is nothing private, API are not that easy to identify and it's so easy to use a package at the wrong level... Also, another drawback is having to mirror all the foreign system in your image (like you are on Mac intel and have plenty of code for handling Linux libraries, Windows, Solaris, FreeBSD, Smartphones etc...). Unless you automatically load those packages at startup (and more difficult, unload at snapshot)... >> In the VM, complexity is handled with the "right tools" (cough...) > > your "cough" is right :). Right tools is what does our life easier, not what is closer to the hardware. > >> #include machine_specific_stuff.h driven by #ifdef >> why_the_hell_is_it_so_complex ;) and include paths library paths >> ldconfig etc... >> It's of course cough-able because this complexity then spread into m4 >> macros for configure scripts and other such niceties. >> >> Sure, >> - when the VM is not able to handle outside world zoo because a lack >> of manpower, and because the outside world changed too fast while we >> were sleeping happy in our mickey world, >> - or if we want more than least common denominator between several >> underlying platforms, >> then yes, it might be better to adopt your strategy, because we can >> get more manpower at image level than at VM level... > > this is an important issue: is easier to maintain at smalltalk level than c level. And there are more willing hands to code :) > >> However, it's a kind of pact with the devil: we get the power at the >> price of introducing the #ifdef hell in the image. > > That's simply not true... look at dbxtalk code, if you want. We could do a plugin to deal with that, but we did it with FFI. Plain smalltalk and straightforward (real problem is to compile opendbx libraries, in fact... and I would love to replace them with smalltalk code, but those are just dreams) > Exactly, it may remain a dream... It's not true in this specific case because opendbx took all the burden of ubiquity... That's why it is so complex to compile ;) >> Sure, with a good object model, we might think that it will be easier >> to handle such complexity. > > +1 > >> But then we're just ignoring the efforts of hordes of programmers >> maintaining this shit, and redo all in image. > > horde of programmers (me, for instance) will be most than pleased to be ignored in this case :) > It's not the problem of ignoring, it's more the problem of under estimating the required work... >> I'm not sure that it will be sustainable... >> Unless of course we focus on a single platform. > > right now OSProcess is also a hell... if Dave chooses to do something else, we are in problems. I prefer a hell in smalltalk than a paradise in C (and of course, vm is not a paradise :) > >> Your work is very important, because at least, it will enable powerful >> single platform extensions. >> But as you see, I just wonder how it would help us to continue >> providing ubiquity... > > Same as today, but in a better way :) > > Lot of plugins don't need to be in VM side if we have a powerful FFI, with callbacks and threads. > I think (as a smalltalk programmer and as a vm programmer) that if we can move to image side those plugins, we can focus in the real complexity of the vm, and after all do better things. > There's something that always amazed me: plugins are supposed to be pluggable and while I understand why they depend on some Kernel-VM services, i don't really see why the contrary has to be true. Is it a packaging problem? A distribution problem? I'm all for a better and more powerfull FFI (without threading we can't have efficient asynchronous IO implemented at image level, just a poor man polling one indeed...) But I continue to think there is a price. Is the unix style select() ubiquitous or should I use WaitForMultipleObject() on Windows? Are specification of read/write streams implementation machine independant (bsd/sysv/others...) - AFAIR the selection is implemented with macros... are the fcntl call to set non blocking portable ? Nicolas > >> >> Nicolas >> >>>>> >>>>> If you want to ask, why one would want to do this.. the answer is simple: >>>>> we stated previously, that we want to reduce the VM complexity by >>>>> implementing things at language side, when it possible, >>>>> leaving only key parts to VM. >>>>> This is the main reason why i consider implementing OSProcess using >>>>> purely FFI, not because of quality of OSProcessPlugin >>>>> implementation etc. >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > >

May 6, 2012

Re: [Pharo-project] Some Newbie problems

by StÃ©phane Ducasse

I hope to get some time to migrate the pbe web site under the same umbrella that the pbe2 during a meeting :) Now it would be good to host this image on the pharobooks project and that we get a link on the pbe page. Stef > Peredur wrote >> >> I'm trying to work my way through the Pharo by example book on my Ubuntu >> 12.04 LTS box. >> > > This comes up every so often, so here's a one-click image adapted from the > Pharo 1.4 one click, but with the Jenkins Stack VMs, briefly tested on > Debian and OS X... > > I will host it temporarily at: > http://seandenigris.com/files/PBE-1.0-one-click.zip > > Maybe someone will test in on Windows... and maybe someone will add it to > the PBE site instead of the plain image so our new users will not suffer so > much :) > > HTH, > Sean > > -- > View this message in context: http://forum.world.st/Some-Newbie-problems-tp4611608p4611923.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 6, 2012

Re: [Pharo-project] RPackage and Monticello are dependent on each other

by StÃ©phane Ducasse

> > we have small dependency problem. The RPackage is currently dependent on Monticello and Monticello is dependent on RPackage. This makes them unable to load them to Pharo Kernel. I think that this is just a problem that we should fix once we get rid of packageInfo and friends. > I suppose this will fix the worst: > MCPackage organization renameCategory: '*RPackage-Core' toBe: '*RPackage-SystemIntegration'. I do not get that one. Can you explain the root of the cycle? > I will open an issue. > > Cheers, > -- Pavel

May 6, 2012

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?

by StÃ©phane Ducasse

Hi nicolas >>>> It's of course cough-able because this complexity then spread into m4 > macros for configure scripts and other such niceties. > > Sure, > - when the VM is not able to handle outside world zoo because a lack > of manpower, and because the outside world changed too fast while we > were sleeping happy in our mickey world, I like the image :) > - or if we want more than least common denominator between several > underlying platforms, > then yes, it might be better to adopt your strategy, because we can > get more manpower at image level than at VM level... > > However, it's a kind of pact with the devil: we get the power at the > price of introducing the #ifdef hell in the image. > Sure, with a good object model, we might think that it will be easier > to handle such complexity. > But then we're just ignoring the efforts of hordes of programmers > maintaining this shit, and redo all in image. > I'm not sure that it will be sustainable... > Unless of course we focus on a single platform. No necessarily, we have object, encapsulation so we should be able to manage modularity the ifdef plague. After all this is all the idea behind "Transform type check to polymorphism" :) > > Your work is very important, because at least, it will enable powerful > single platform extensions. > But as you see, I just wonder how it would help us to continue > providing ubiquity...

May 6, 2012

Re: [Pharo-project] PBE1 update to Pharo 1.4 Re: Some Newbie problems

by StÃ©phane Ducasse

>> > > The new book focuses on different issues than the old book. It would be sad to let the old book languish entirely and end up with a poor first impression for newcomers, so I am willing to participate in updating it to Pharo 1.4. I am getting a lot from Pharo and this is something I can contribute. I think it fair the main developers continue with implementing and documenting the advanced features, while the community maintains the more established things. A quick scan pegs this effort at updating about 170 images, plus hopefully a minimal amount of text. How would I proceed with this? > > cheers -ben Thanks ben. I think that the first volume of the book is on git hub so you can simply go ahead. May be you should register to the she mailing-list mailing-list and mention your effort. Stef

May 6, 2012