January 2011 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Updates: Status: Closed Comment #5 on issue 3501 by stephane...(a)gmail.com: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 (No comment was entered for this change.)

Jan. 21, 2011

[Pharo-project] [update 1.3] #13013

by StÃ©phane Ducasse

13013 ----- - Categorization of deprecated methods.

Jan. 21, 2011

[Pharo-project] Issue 3569 in pharo: Error logging cleanup

by pharo＠googlecode.com

Status: Started Owner: siguc...(a)gmail.com New issue 3569 by siguc...(a)gmail.com: Error logging cleanup http://code.google.com/p/pharo/issues/detail?id=3569 Not best, but little better than before. - remove repetitive use of 'PharoDebug.log' all over the places. Now Debugger have #logFileName and keeps name in class var (should expose it in settings later). - deprecated #logError:inContext:to: , one should use #logError:inContext: instead. Attachments: DebuggerLog.3.cs 12.1 KB

Jan. 21, 2011

[Pharo-project] PharoSound

by Henrik Sperre Johansen

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

Jan. 21, 2011

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

by Henrik Sperre Johansen

On 21.01.2011 17:33, 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 > Yeah, I found parent: after awhile :D Must have added it to instance side, and that's why it didn't show up in the settings browser... *blush* > 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. > > Cheers > Alain Eeeeh, well... I'm not too familiar with the sound package, but it ends up calling a primitive instead of scheduling the sound. There's code there to schedule instead if the primitive fails, so my guess is it caused crashes some time in the past and a manual method was needed to disable it. I'll could update the comment to "Turn this off if your VM crashes when playing sound", but I have no idea if that's actually the intended case. :) Cheers, Henry

Jan. 21, 2011