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

[Pharo-project] Issue 3565 in pharo: Undeclared ref in 1.1.1

by pharo＠googlecode.com

Status: Fixed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.1.1 New issue 3565 by marcus.d...(a)gmail.com: Undeclared ref in 1.1.1 http://code.google.com/p/pharo/issues/detail?id=3565 Fix attached... Attachments: UndeclaredFix.1.cs 5.2 KB

Jan. 21, 2011

Re: [Pharo-project] Issue 3465 in pharo: Hundson OneClick: Does not show Mac menues

by pharo＠googlecode.com

Updates: Cc: eliot.miranda marianopeck Comment #2 on issue 3465 by Torsten....(a)astares.de: Hundson OneClick: Does not show Mac menues http://code.google.com/p/pharo/issues/detail?id=3465 Setting Eliot on CC for this issue. Maybe the mac menu support code is only in the standard VM and not yet integrated into Cog VM. Mariano: You should note the exact image (download location) here so Eliot can reproduce it.

Jan. 21, 2011

Re: [Pharo-project] Issue 3542 in pharo: Add SmalltalkImage>>#gcBiasToGrow: and friends to core

by pharo＠googlecode.com

Comment #18 on issue 3542 by Torsten....(a)astares.de: Add SmalltalkImage>>#gcBiasToGrow: and friends to core http://code.google.com/p/pharo/issues/detail?id=3542 Mariano: ImageForDevelopers is used in the build for the upcoming Pharo 1.2, isnt it? Phillipe: is #loadLatestVersion of Seaside 3.0 working/compatible with the upcoming Pharo 1.2 already?

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Igor Stasenko

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 > Sven > -- Best regards, Igor Stasenko AKA sig.

Jan. 21, 2011

Re: [Pharo-project] Issue 3520 in pharo: Workspaces do not recognize previously evaluated temps

by pharo＠googlecode.com

Updates: Status: Closed Comment #9 on issue 3520 by marcus.d...(a)gmail.com: Workspaces do not recognize previously evaluated temps http://code.google.com/p/pharo/issues/detail?id=3520 13007

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Sven Van Caekenberghe

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

Jan. 21, 2011

Re: [Pharo-project] Issue 3419 in pharo: TraitCompositionTest>>testProvidedMethodBindingsWithConflicts is failing

by pharo＠googlecode.com

Updates: Status: Accepted Comment #7 on issue 3419 by marcus.d...(a)gmail.com: TraitCompositionTest>>testProvidedMethodBindingsWithConflicts is failing http://code.google.com/p/pharo/issues/detail?id=3419 (No comment was entered for this change.)

Jan. 21, 2011

Re: [Pharo-project] Issue 3520 in pharo: Workspaces do not recognize previously evaluated temps

by pharo＠googlecode.com

Comment #8 on issue 3520 by marcus.d...(a)gmail.com: Workspaces do not recognize previously evaluated temps http://code.google.com/p/pharo/issues/detail?id=3520 12316 TODO: 1.3

Jan. 21, 2011

Re: [Pharo-project] Issue 3419 in pharo: TraitCompositionTest>>testProvidedMethodBindingsWithConflicts is failing

by pharo＠googlecode.com

Updates: Status: Closed Labels: -Milestone-1.2 Comment #6 on issue 3419 by marcus.d...(a)gmail.com: TraitCompositionTest>>testProvidedMethodBindingsWithConflicts is failing http://code.google.com/p/pharo/issues/detail?id=3419 Workaround 12316. Not to be appled to 1.3

Jan. 21, 2011

Re: [Pharo-project] Instruments for headless images

by Igor Stasenko

On 21 January 2011 11:04, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Igor, > > Headless support is an important feature. > It should be something simple so that it can be used in many ways. > I would suggest to read chapter 20 of the VW Application Developers Guide (it is only 10 pages). > > They basically have the option to toggle between headless and headfull. > This is not detected automatically, but a global switch (with a test method). > > In headless mode all display access results in an error. yes. > In headless mode all Transcript output (can/is) also sent to a file (stdout would be another option). > yes > 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. > Saving a headless image headfull can also be done programmatically. > > I don't think more than that is needed. There are many options to interact with headless images, forcing one on people would not be good, the same goes for command line parsing, preferences, startup files, ... These other options could become separate projects. > well, again, when people running image(s) in headless mode, they are know what they doing, and i think their default expectation is that image(s) should be aware that it runs headless and do not try to invoke anything which requires user interaction (like yes/no dialog) , because this does not makes any sense. > I would be an interested user and if I can will try to help. > > Regards, > > Sven > -- Best regards, Igor Stasenko AKA sig.

Jan. 21, 2011