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

Re: [Pharo-project] Loading dependencies

by Alexandre Bergel

<BoldMode>Once cannot write a well defined configuration without an adequate tool. Versionner (http://ss3.gemstone.com/ss/Versionner.html) is so far the best option to make sure your configuration actually works.</BoldMode> Cheers, Alexandre On Nov 21, 2012, at 5:57 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Nov 21, 2012 at 9:37 AM, Max Leske <maxleske(a)gmail.com> wrote: > Metacello is probably the way to go. It's a bit of a pain until you have it set up but then it's pretty easy to use, especially for development since you'll simply always load the latest versions (AKA "bleeding edge" or "development"). > Take a look at the ProfStef tutorial (not sure how up to date it is but it helped me a lot to get started with Metacello). > > > Yes, Metacello. And we also wrote a PharoByExample chapter: http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf > > Cheers, > Max > > On 21.11.2012, at 09:30, roberto.minelli(a)usi.ch wrote: > > > 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 > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 21, 2012

Re: [Pharo-project] Loading dependencies

by Mariano Martinez Peck

On Wed, Nov 21, 2012 at 9:37 AM, Max Leske <maxleske(a)gmail.com> wrote: > Metacello is probably the way to go. It's a bit of a pain until you have > it set up but then it's pretty easy to use, especially for development > since you'll simply always load the latest versions (AKA "bleeding edge" or > "development"). > Take a look at the ProfStef tutorial (not sure how up to date it is but it > helped me a lot to get started with Metacello). > > Yes, Metacello. And we also wrote a PharoByExample chapter: http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf > Cheers, > Max > > On 21.11.2012, at 09:30, roberto.minelli(a)usi.ch wrote: > > > 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 > > > > > > > -- Mariano http://marianopeck.wordpress.com

Nov. 21, 2012

Re: [Pharo-project] Loading dependencies

by Max Leske

Metacello is probably the way to go. It's a bit of a pain until you have it set up but then it's pretty easy to use, especially for development since you'll simply always load the latest versions (AKA "bleeding edge" or "development"). Take a look at the ProfStef tutorial (not sure how up to date it is but it helped me a lot to get started with Metacello). Cheers, Max On 21.11.2012, at 09:30, roberto.minelli(a)usi.ch wrote: > 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

[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