- Pharo-dev - lists.pharo.org

[Pharo-project] Loading dependencies

by roberto.minelli＠usi.ch

Hi, At the moment I'm creating an analysis tool for Git repositories. I'm versioning my source code on Smalltalkhub, so that I can easily load my code in a fresh image, when needed. My project depends on several external packages such as the Filesystem-Git, Fuel, and the last version of Filesystem. I was wondering if it's possible to add such dependencies programmatically so that once I load my project from Monticello dependencies are added as well. I heard that Metacello is probably suitable to handle dependencies, but it would be glad to hear an opinion from you. Thanks in advance, Roberto

Nov. 21, 2012

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

by Igor Stasenko

On 21 November 2012 04:53, Max Leske <maxleske(a)gmail.com> wrote: > > On 21.11.2012, at 08:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Ah, ok , so its even better than i thought. >> Indeed , if purpose of Limbo is to provide an interface to exec(ve) >> system functions, >> then there's no need to care a lot about VM state after fork() call.. >> >> Also, Max, did you considered of using system() call? It is much easier.. >> The downside that it doesn't allows you to control input/output >> channels of running child process, of course. > > Initially I thought of system() but I wanted feed the stdout and stderr streams back into the image. > right. Having a way to communicate with child process is a must. >> >> Anyways, your project can give a definitive answer to a question, >> which i asked some time ago: >> - can OSProcess functionality be implemented via FFI or not.. > > I'll try to answer that :) Good. You can count on my help :) > >> >> On 20 November 2012 17: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). >>> >>> Dave >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Nov. 21, 2012

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

by Max Leske

On 21.11.2012, at 08:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > Ah, ok , so its even better than i thought. > Indeed , if purpose of Limbo is to provide an interface to exec(ve) > system functions, > then there's no need to care a lot about VM state after fork() call.. > > Also, Max, did you considered of using system() call? It is much easier.. > The downside that it doesn't allows you to control input/output > channels of running child process, of course. Initially I thought of system() but I wanted feed the stdout and stderr streams back into the image. > > Anyways, your project can give a definitive answer to a question, > which i asked some time ago: > - can OSProcess functionality be implemented via FFI or not.. I'll try to answer that :) > > On 20 November 2012 17: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). >> >> Dave >> > > > > -- > Best regards, > Igor Stasenko. >

Nov. 21, 2012

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

by Max Leske

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 > >

Nov. 21, 2012

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

by Igor Stasenko

Ah, ok , so its even better than i thought. Indeed , if purpose of Limbo is to provide an interface to exec(ve) system functions, then there's no need to care a lot about VM state after fork() call.. Also, Max, did you considered of using system() call? It is much easier.. The downside that it doesn't allows you to control input/output channels of running child process, of course. Anyways, your project can give a definitive answer to a question, which i asked some time ago: - can OSProcess functionality be implemented via FFI or not.. On 20 November 2012 17: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). > > Dave > -- Best regards, Igor Stasenko.

Nov. 21, 2012

Re: [Pharo-project] Package-pane (or 6-paned) browser for Pharo?

by Stephen Travis Pope

The 6-paned browser exists for VisualWorks and is included in Squeak, but neither version will file in to pharo. Here's the Squeak version: stp -- Stephen Travis Pope Santa Barbara, California, USA http://HeavenEverywhere.com - On Nov 20, 2012, at 12:58 PM, Geert Claes wrote: > Hi Stephen, Personally I struggle with creating a UI in Pharo/Squeak and > there are plenty of experts on this forum but from a UX pov I do like the > idea of a 2 (or multi) level category panel to make the first panel more > manageable. > > It would also be nice to have the "...Tests" category nicely with the > category it is testing. Although I reckon the way to clarify would be to > have less complexity and panels rather than have more panels. Even the > protocol panel could easilly be some dropdown box above the methods panel. > I also find that the Instance/?/Class buttons should be some sort of tab or > toggle above the last panel rather than buttons under the class panel :) > > Is the code for the 6 pane browser still available somewhere? > > > > -- > View this message in context: http://forum.world.st/Package-pane-or-6-paned-browser-for-Pharo-tp4655495p4… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Nov. 21, 2012

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

by Sebastian Sastre

"The font is then responsible for providing the drawing commands and metrics for the particular glyph when it's drawn." sounds like Cocoa delegates rendering to the font. On Nov 20, 2012, at 10:09 PM, Camillo Bruni wrote: > > On 2012-11-20, at 17:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello. >> >> Can you add me as project contributor. I try to upload version with >> detailed comment from my first mail but can't. >> >> 2012/11/18 Camillo Bruni <camillobruni(a)gmail.com> >> >>> I don't think the basic model should know about the visual lines. We >>> discussed >>> that for a while, but in the end that's purely a view on the basic model. >>> >> >> If such behaviour will be at view simple Cursor>>moveUp/moveDown will never >> work right from user perspective. So why you need cursor at text model >> which will never reflect state of visual cursor at screen? > > it depends, I think the model should not take the view into account. > First we implement the cursor movement as simple as possible, and that is > for now on the model-base. > > If it will work properly or not depends on the view implementation. > >> To me text model should completly represent what user see at text view. >> Otherwise why you call it model? Otherwise it is just raw data like Text in >> current TextMorph > > Model IS the raw base model, the view is what you see, that are definitely > two different things. > For instance where would you deal with hyphenation? dynamic layouts? > > I don't think they belong in the model and I think we should stick to > existing implementation schemes (M VC) and existing implementations > like Cocoa... > >

Nov. 21, 2012

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

by Camillo Bruni

On 2012-11-20, at 17:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > Can you add me as project contributor. I try to upload version with > detailed comment from my first mail but can't. > > 2012/11/18 Camillo Bruni <camillobruni(a)gmail.com> > >> I don't think the basic model should know about the visual lines. We >> discussed >> that for a while, but in the end that's purely a view on the basic model. >> > > If such behaviour will be at view simple Cursor>>moveUp/moveDown will never > work right from user perspective. So why you need cursor at text model > which will never reflect state of visual cursor at screen? it depends, I think the model should not take the view into account. First we implement the cursor movement as simple as possible, and that is for now on the model-base. If it will work properly or not depends on the view implementation. > To me text model should completly represent what user see at text view. > Otherwise why you call it model? Otherwise it is just raw data like Text in > current TextMorph Model IS the raw base model, the view is what you see, that are definitely two different things. For instance where would you deal with hyphenation? dynamic layouts? I don't think they belong in the model and I think we should stick to existing implementation schemes (M VC) and existing implementations like Cocoa...

Nov. 21, 2012

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

by Camillo Bruni

Summary ------- TxText is work in progress On 2012-11-20, at 20:35, Stephan Eggermont <STEPHAN(a)STACK.NL> wrote: > Hi, > > I've taken a look at the TxText text model, and it seems rather limited. also do not forget that it's like pre-pre-alpha and not in use yet > I'm a bit confused about the expectations for this code: is this supposed to be just > for editing smalltalk methods? that's the first goal, but definitely not limited to that. > The current Text system looks to me more like a limited > implementation of the OpenStep/GNUStep/Cocoa text system. That separates concerns > and allows high quality layouts. exactly! we want to get rid of the shitty model we currently have in Pharo. With the current model we will never be able to implement a state-of-the-art text editor that supports decent sourcecode/ast interaction! > David Chisnall seems to know something about those systems > http://www.informit.com/articles/article.aspx?p=1602820 yup cocoa is more or less our vision for this, but you gotta start small. NOTE: Pharo does not even have a basic text model that works. - I cannot use the current text model to build anything but a Morphic UI - you add the Editors and you got a big bunch of interacting classes with no clear separation.

Nov. 20, 2012

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

by Stephan Eggermont

Hi, I've taken a look at the TxText text model, and it seems rather limited. I'm a bit confused about the expectations for this code: is this supposed to be just for editing smalltalk methods? The current Text system looks to me more like a limited implementation of the OpenStep/GNUStep/Cocoa text system. That separates concerns and allows high quality layouts. David Chisnall seems to know something about those systems http://www.informit.com/articles/article.aspx?p=1602820 Cheers, Stephan

Nov. 20, 2012