- Pharo-dev - lists.pharo.org

[Pharo-project] Some important news

by StÃ©phane Ducasse

Hi guys some important news today, we decided that we will set up a pharo association so that we can promote pharo. We would like to be able to collect money and create bounties to improve pharo. Stef

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Chris Muller

Considerations about improving headless support need to not only be about what to do with error output. When "running headless," the user is taking on a different kind of interaction with the system; it is now an industrial interface instead of the GUI, but it *is* a user-interface nonetheless. Therefore interacting with the system this way should address *input* as well as output. The input in the industrial environment consists of the name of a Smalltalk script + command-line arguments to that script. > this is next step.. > > I think this could be set by preference system > on error: > Â - print error to log and quit > Â - print error to log and do save & quit > Â - print error to log and do save new version & quit It's important to allow the same image to be used by multiple scripts, some of which might want to exit without saving, some which want to save under a new name. "How-to-quit" should be specific to each input script, not a global preference in the image. Regards, Chris

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by Igor Stasenko

On 21 January 2011 18:48, Dale Henrichs <dhenrich(a)vmware.com> wrote: > On 01/21/2011 08:11 AM, Miguel CobÃ¡ wrote: >> >> El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribiÃ³: >> >>> Okay, i found the solution. Use Installer ! >>> >>> Installer monticello http: 'http://www.squeaksource.com'; >>> Â Â Â project: 'VMMaker'; >>> Â Â Â install: 'CMakeVMMaker' >>> >>> >>> works well for me and loads correct *latest* version. >> >> That isn't a solution and open again a gratuitous discussion about gofer >> vs installer. >> >> The point is, in a distributed SCM system, like Monticello is, there >> isn't a latest version. At least not by the traditional (suversion for >> example) way of knowing the monotone numeric integer version number. As >> Lukas said, the only way to know something is latest is to compare >> timestamps, but not version numbers or commits id. They aren't not >> intended to be ordered respect to time. >> >> Cheers >> > > It seems to me that that isn't quite the issue ... for Metacello I had to > change the sort algorithm that Gofer used to more closely match the > algorithm used by the Monticello GUI when it sorts packages ... to minimize > the surprise for developers who are used to the Monticello GUI sorting > order... I also had to change the branch naming scheme that was used by > Gofer, because it caused problems when package names inadvertently looked > like a branch to Gofer when it wasn't...Since there has never been an > enforced naming convention in Monticello, there are a whole lot of > incompatible naming schemes being used... > > BTW, I made these changes so that they only applied to Metacello's use of > Gofer ... > good to know > Dale > > -- Best regards, Igor Stasenko AKA sig.

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Eliot Miranda

On Fri, Jan 21, 2011 at 10:19 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 January 2011 19:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 21 January 2011 11:28, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > >> > > >> > On 21 Jan 2011, at 11:19, Igor Stasenko wrote: > >> > > >> >>> What is interesting (and we might make that an option) is that the > 'no > >> >>> display' error results in the image being saved 'headfull' so that > you can > >> >>> start it up using a display to debug it (suspended > process/debugger). > >> >> > >> >> That could be done.. but not as userful as simply report an error. > >> >> Usually we (developers) knowing what we want to do, > >> >> and what i don't want to see in my headless image is any attempts to > >> >> access display/ui. > >> > > >> > Yeah, that's why I said it would better be an option. The first thing > to > >> > do is simply report the error (and quit, or maybe that should be an > option > >> > too). But many people playing with headless images (myself included) > have > >> > had blocking/locked up images: having a log would be great, but adding > this > >> > option to debug the cause further would be great. > >> > > >> > >> this is next step.. > >> > >> I think this could be set by preference system > >> on error: > >> - print error to log and quit > >> - print error to log and do save & quit > >> - print error to log and do save new version & quit > >> > >> In future , by adding support from VM side we could also have: > >> - switch to interactive(headfull) mode, by creating an OS window > >> opening debugger , showing dialog(s) etc etc > > > > The VW headful/headless switch requires _no_ additional VM support at > all. > > All one needs is stdio support (which we have) and everything else can > be > > done in Smalltalk. > > > > err.. no additional support? you mean it already in there? > - how to tell VM to close everything at runtime and become headless > There's an openDisplay primitive that is used ever time the system comes up headless. IFAIA one never goes directly headless from a headful state. Instead one saves headless and resumes the snapshot headless. "Saving headless" means doing a snapshot that sets a variable such that when the saved image resumes it doesn't do an openDisplay. What one does do is dynamically become headful, and to do that one just uses the openDisplay primitive. (FYI openDisplay is primitive #960). - how to tell VM to create a new window(s) and turn from headless to > headful mode? > Use openDisplay. > > there should be something from VM side, otherwise how else? > unless, of course, image are in total control of host window > creation/deletion, then of course it could > decide what to do by own. > > >> > >> > Sven > >> > > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Jan. 21, 2011

Re: [Pharo-project] Adding settings to an existing group

by StÃ©phane Ducasse

On Jan 21, 2011, at 5:33 PM, Alain Plantec wrote: > ----------------- > quickStartSoundSettingOn: aBuilder > <systemsettings> > (aBuilder setting: #soundQuickStart) > parent: #soundEnabled; > label: 'Play sounds immediately if possible' translated; > target: SoundPlayer > -------------- > > should do it if you have > SoundPlayer class>>soundQuickStart > SoundPlayer class>>soundQuickStart: aBoolean > > btw: > why this setting ? > If sound is enabled, why would I set this setting to false ? > I guess one always want the sound to start as quick as possible. :) No on some platform is was simply crashing the vm. > > Cheers > Alain > > > > > Le 21/01/2011 16:06, Henrik Sperre Johansen a Ã©crit : >> Sorry I haven't really had time to learn the settings framework yet, >> does anyone know how to do this? >> >> Updating the Sound package, I'd like to add a few to the existing >> category Appearance -> sound (strange place for it, btw...) in a package >> one can load from the repository. >> >> I tried code like: >> >> quickStartSoundSettingOn: aBuilder >> <systemsettings> >> (aBuilder group: #appearance) with: [ >> (aBuilder setting: #soundEnabled) with: [ >> (aBuilder setting: #soundQuickStart) >> label: 'Play sounds immediately if possible'; >> target: SoundPlayer; >> targetSelector: #soundQuickStart]] >> >> but that's apparently far off the mark... >> >> Cheers, >> Henry >> >> > >

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Igor Stasenko

On 21 January 2011 19:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 21 January 2011 11:28, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> > >> > On 21 Jan 2011, at 11:19, Igor Stasenko wrote: >> > >> >>> What is interesting (and we might make that an option) is that the 'no >> >>> display' error results in the image being saved 'headfull' so that you can >> >>> start it up using a display to debug it (suspended process/debugger). >> >> >> >> That could be done.. but not as userful as simply report an error. >> >> Usually we (developers) knowing what we want to do, >> >> and what i don't want to see in my headless image is any attempts to >> >> access display/ui. >> > >> > Yeah, that's why I said it would better be an option. The first thing to >> > do is simply report the error (and quit, or maybe that should be an option >> > too). But many people playing with headless images (myself included) have >> > had blocking/locked up images: having a log would be great, but adding this >> > option to debug the cause further would be great. >> > >> >> this is next step.. >> >> I think this could be set by preference system >> on error: >> Â - print error to log and quit >> Â - print error to log and do save & quit >> Â - print error to log and do save new version & quit >> >> In future , by adding support from VM side we could also have: >> Â - switch to interactive(headfull) mode, by creating an OS window >> opening debugger , showing dialog(s) etc etc > > The VW headful/headless switch requires _no_ additional VM support at all. > Â All one needs is stdio support (which we have) and everything else can be > done in Smalltalk. > err.. no additional support? you mean it already in there? - how to tell VM to close everything at runtime and become headless - how to tell VM to create a new window(s) and turn from headless to headful mode? there should be something from VM side, otherwise how else? unless, of course, image are in total control of host window creation/deletion, then of course it could decide what to do by own. >> >> > Sven >> > >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig.

Jan. 21, 2011

Re: [Pharo-project] New chapter on OpenGL in Pharo

by StÃ©phane Ducasse

On Jan 21, 2011, at 6:14 AM, Javier PimÃ¡s wrote: > Hi! I just gathered many of my previous experiences trying to use opengl and uploaded it to the pharo book. It would be nice if someone could check the info, try to add more and mainly test the tips to see if they are working. Thanks!!! Documenting is important so that we all learn. > With FFI OpenGL I'm getting an error while compiling a test method in Pharo 1.2 and some problems with underscore assignments and deprecations, we should fix them but I don't think I have access to that repo. Also, loading it involves many steps, having a ConfigurationOfFFIOpenGL would be awsome. > > Please add anything you consider useful. > > Regards, > Javier. > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Eliot Miranda

On Fri, Jan 21, 2011 at 2:34 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 21 January 2011 11:28, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > > > On 21 Jan 2011, at 11:19, Igor Stasenko wrote: > > > >>> What is interesting (and we might make that an option) is that the 'no > display' error results in the image being saved 'headfull' so that you can > start it up using a display to debug it (suspended process/debugger). > >> > >> That could be done.. but not as userful as simply report an error. > >> Usually we (developers) knowing what we want to do, > >> and what i don't want to see in my headless image is any attempts to > >> access display/ui. > > > > Yeah, that's why I said it would better be an option. The first thing to > do is simply report the error (and quit, or maybe that should be an option > too). But many people playing with headless images (myself included) have > had blocking/locked up images: having a log would be great, but adding this > option to debug the cause further would be great. > > > > this is next step.. > > I think this could be set by preference system > on error: > - print error to log and quit > - print error to log and do save & quit > - print error to log and do save new version & quit > > In future , by adding support from VM side we could also have: > - switch to interactive(headfull) mode, by creating an OS window > opening debugger , showing dialog(s) etc etc > The VW headful/headless switch requires _no_ additional VM support at all. All one needs is stdio support (which we have) and everything else can be done in Smalltalk. > > > > Sven > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Jan. 21, 2011

Re: [Pharo-project] PharoSound

by Hilaire Fernandes

Yes, I fell they were a dublication problem. Does the PharoSound code come with the latest fixes in sound package at http://www.squeaksource.com/PharoNonCorePackages ? Hilaire Le 21/01/2011 18:16, Henrik Sperre Johansen a Ã©crit : > Hi Mariano & all! > > About the changes in 3489 and 3566 earlier today, I think there were > some misunderstandings. > > The changes I made in 3566 is to PharoCore, and are intended to work > with the Sound package in http://www.squeaksource.com/PharoSound. > It moves the settings stored in SoundSettings to SoundService + > ThemeSounds, which are more localized places for them. > This makes sense by itself, but also because that's where they (well, > only soundEnabled) are likely to be found if refactored to use > preference pragmas in Squeak. > > Because the package in PharoSound has the Squeak trunk Sound package as > ancestor as well, it's easy to synch up changes from it. (AFAIK the one > in NonCorePackages does not). > I feel this is important, since Sound does not really receive a lot of > attention in Pharo, and efforts in Squeak should be as easy to integrate > as possible. > > Thus, I'd really appreciate it if the ConfigurationOfSound could be > changed to use this repository as the primary source. > > Cheers, > Henry > > -- Education 0.2 -- http://blog.ofset.org/hilaire

Jan. 21, 2011

Re: [Pharo-project] Gofer issue

by Dale Henrichs

On 01/21/2011 08:11 AM, Miguel CobÃ¡ wrote: > El vie, 21-01-2011 a las 11:05 +0100, Igor Stasenko escribiÃ³: > >> Okay, i found the solution. Use Installer ! >> >> Installer monticello http: 'http://www.squeaksource.com'; >> project: 'VMMaker'; >> install: 'CMakeVMMaker' >> >> >> works well for me and loads correct *latest* version. > > That isn't a solution and open again a gratuitous discussion about gofer > vs installer. > > The point is, in a distributed SCM system, like Monticello is, there > isn't a latest version. At least not by the traditional (suversion for > example) way of knowing the monotone numeric integer version number. As > Lukas said, the only way to know something is latest is to compare > timestamps, but not version numbers or commits id. They aren't not > intended to be ordered respect to time. > > Cheers > It seems to me that that isn't quite the issue ... for Metacello I had to change the sort algorithm that Gofer used to more closely match the algorithm used by the Monticello GUI when it sorts packages ... to minimize the surprise for developers who are used to the Monticello GUI sorting order... I also had to change the branch naming scheme that was used by Gofer, because it caused problems when package names inadvertently looked like a branch to Gofer when it wasn't...Since there has never been an enforced naming convention in Monticello, there are a whole lot of incompatible naming schemes being used... BTW, I made these changes so that they only applied to Metacello's use of Gofer ... Dale

Jan. 21, 2011