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

Re: [Pharo-project] Issue 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class

by Igor Stasenko

On 11 January 2011 09:14, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > but igor for example in the case of soul, it means that you should load the SoulCompiler which is > normal if you want to use soul compiled methods. > Now having a reference to a class makes static warning easier than just an object. > >From that perspective it doesn't makes any difference: referencing a missing class in #compilerClass, or in #newCompiler would lead to same error/warning. What makes these approaches different is where you controlling the creation and initialization of compiler instance. > Stef > > On Jan 11, 2011, at 12:55 AM, Igor Stasenko wrote: > >> On 10 January 2011 20:52, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> Parser is not hardcoded (except in tests), but parserClass is >>> sometimes sent to the wrong class.. >>> Example is Text>>makeSelectorBold (sent from Debugger) >>> It should be replaced with makeSelectorBoldIn: >>> >>> Also notice that source code files cannot be analyzed if they contain >>> classes absent from current system that define their own parserClass. >>> That is a problem for change lists, and possibly for MC (it would be >>> interesting to try). >>> >> >> I think that there could be a solution to that. >> We could require that certain methods like #newParser, #newCompiler >> should be written in smalltalk. >> Then code import tools could rely on that and compile these methods >> first, and then could use them to compile the rest of class'es source >> code. >> >> >>> Nicolas >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 11, 2011

Re: [Pharo-project] Issue 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class

by StÃ©phane Ducasse

but igor for example in the case of soul, it means that you should load the SoulCompiler which is normal if you want to use soul compiled methods. Now having a reference to a class makes static warning easier than just an object. Stef On Jan 11, 2011, at 12:55 AM, Igor Stasenko wrote: > On 10 January 2011 20:52, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> Parser is not hardcoded (except in tests), but parserClass is >> sometimes sent to the wrong class.. >> Example is Text>>makeSelectorBold (sent from Debugger) >> It should be replaced with makeSelectorBoldIn: >> >> Also notice that source code files cannot be analyzed if they contain >> classes absent from current system that define their own parserClass. >> That is a problem for change lists, and possibly for MC (it would be >> interesting to try). >> > > I think that there could be a solution to that. > We could require that certain methods like #newParser, #newCompiler > should be written in smalltalk. > Then code import tools could rely on that and compile these methods > first, and then could use them to compile the rest of class'es source > code. > > >> Nicolas >> > > > -- > Best regards, > Igor Stasenko AKA sig. >

Jan. 11, 2011

Re: [Pharo-project] [squeak-dev] Re: new Cog VMs

by Igor Stasenko

On 11 January 2011 04:42, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, Â Hi All, > > On Sun, Jan 2, 2011 at 4:11 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 3 January 2011 00:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > Hi Martin, Hi All, >> > Â Â Â so find new VMs inÂ VM.r2341/. Â The linux crashes (certainly the one >> > you >> > suffered from Martin) seem to be caused by an optimization bug (but they >> > could be caused by bad code generation, creating something that assumes >> > ordering constraints which C doesn't guarantee). Â I suspect the former >> > because I don't see the crash when running exactly the same VM and image >> > from a different directory; provoking the crash requires a particular >> > path >> > (go figure; I haven't pinned this down yet). >> > So my "fix" is preventing a complex function being inlined into the main >> > interpreter loop, removing the sources of some warnings, and lowering >> > the >> > optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my >> > build >> > environment, CentOS Linux 5.3, uses gcc 4.1.2). Â I'm not proud of this >> > "fix". Â I've violated the Deutsch criterion by not diagnosing the cause >> > of >> > the bug so I can't stand behind this fix; it's a hack that appears to >> > work >> > and may have merely pushed the real bug further underground. Â Alas I >> > don't >> > have time to do a better job. Hopefully it'll get those of you on linux >> > going again. >> >> Eliot, if you remember, i also had crash issues on linux, and pinned down >> it to >> removing optimization from <something>heartbeat.c while keeping >> gcc3x-cointerp.c to use >> Â same optimization flags as for rest of files. > > Indeed, quite right. Â I happened to add a flag to turn off the heartbeat so > I could debug the crash Matthew was seeing in starting up > Squeak4.2-10856-beta.image (since single-stepping through machine code > always gets interrupted by the heartbeat, it being an interval timer) and lo > and behold the bug went away. Â This is very worrying because it appears to > imply that there's a serious bug in the linux kernel/gcc since delivering a > software interrupt shouldn't corrupt registers, but it clearly does. Â I'll > try and pass it by someone who's an expert in this area. > Anyway, now find a new linux VM inÂ VM.r2346/Â that seems fine with the > interpreter and the cogit compiled at -02 but the heartbeat compiled at -O2. > Â Running this VM on CentOS 5.3 under Parallels I get > Â Â Â 2839 run, 2796 passes, 7 expected failures, 24 failures, 11 errors, 0 > unexpected passes > for the full test suite inÂ Squeak4.2-10856-beta.image. > So have at it. Great! Nice to see that we can deal with elusive bugs :) > best > Eliot >> >> I will start coding cmake config for Cog during next week and will be >> able to check my previous >> observations again. >> >> > best >> > Eliot >> > On Sat, Jan 1, 2011 at 11:16 PM, <mkobetic(a)gmail.com> wrote: >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig.

Jan. 11, 2011

Re: [Pharo-project] Origins [poll]

by StÃ©phane Ducasse

Jan. 11, 2011

Re: [Pharo-project] [squeak-dev] Re: new Cog VMs

by Andres Valloud

> Indeed, quite right. I happened to add a flag to turn off the heartbeat > so I could debug the crash Matthew was seeing in starting up > Squeak4.2-10856-beta.image (since single-stepping through machine code > always gets interrupted by the heartbeat, it being an interval timer) > and lo and behold the bug went away. This is very worrying because it > appears to imply that there's a serious bug in the linux kernel/gcc > since delivering a software interrupt shouldn't corrupt registers, but > it clearly does. I'll try and pass it by someone who's an expert in > this area. Or the signal handler functions do not comply with the relevant specifications, e.g.: signal handlers that do not preserve the value of errno, signal handlers that use a function not in the list of approved safe functions you can call from a signal handler as per the Single Unix Specification, etc... Andres.

Jan. 11, 2011

[Pharo-project] Comment all classes

by laurent laffont

http://geekandpoke.typepad.com/geekandpoke/2010/12/coders-new-years-resolut… (Sorry, you can bash me - sad joke) Laurent Laffont

Jan. 11, 2011

[Pharo-project] Issue 3529 in pharo: TextMorph>>releaseCachedState creates a paragraph which causes a "Subscript out of bounds" in an internal RunArray

by pharo＠googlecode.com

Status: Accepted Owner: hernan.m...(a)gmail.com Labels: Type-ReportDefect New issue 3529 by hernan.m...(a)gmail.com: TextMorph>>releaseCachedState creates a paragraph which causes a "Subscript out of bounds" in an internal RunArray http://code.google.com/p/pharo/issues/detail?id=3529 Pharo image: Pharo1.1rc3 Pharo core version: Latest update: #11406 Virtual machine used: Pharo 4.0.2 Steps to reproduce: 1. ScriptLoader new cleanUpForRelease. or 2. Specifically SystemNavigation default allObjectsDo: [ :each | (each respondsTo: #releaseCachedState) ifTrue: [ each releaseCachedState ] ]. Sometimes creating a new paragraph while releasing caches causes an Error (subscript is out of bounds) in the RunArray of the text attributes of the TextComposer in the MultiNewParagraph which is contained. Attached Error log. The method TextMorph>>paragraph says "Paragraph instantiation is lazy -- it will be created only when needed", then why the (undocumented) TextMorph>>releaseCachedState creates a new paragraph anyway? If creating paragraph is not needed you may apply the proposed fix. Attachments: releaseParagraphBug.log 29.9 KB TextMorph-releaseCachedState.st 234 bytes

Jan. 11, 2011

Re: [Pharo-project] [squeak-dev] Re: new Cog VMs

by Eliot Miranda

Hi Igor, Hi All, On Sun, Jan 2, 2011 at 4:11 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 3 January 2011 00:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Martin, Hi All, > > so find new VMs in VM.r2341/. The linux crashes (certainly the one > you > > suffered from Martin) seem to be caused by an optimization bug (but they > > could be caused by bad code generation, creating something that assumes > > ordering constraints which C doesn't guarantee). I suspect the former > > because I don't see the crash when running exactly the same VM and image > > from a different directory; provoking the crash requires a particular > path > > (go figure; I haven't pinned this down yet). > > So my "fix" is preventing a complex function being inlined into the main > > interpreter loop, removing the sources of some warnings, and lowering the > > optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my build > > environment, CentOS Linux 5.3, uses gcc 4.1.2). I'm not proud of this > > "fix". I've violated the Deutsch criterion by not diagnosing the cause > of > > the bug so I can't stand behind this fix; it's a hack that appears to > work > > and may have merely pushed the real bug further underground. Alas I > don't > > have time to do a better job. Hopefully it'll get those of you on linux > > going again. > > Eliot, if you remember, i also had crash issues on linux, and pinned down > it to > removing optimization from <something>heartbeat.c while keeping > gcc3x-cointerp.c to use > same optimization flags as for rest of files. > Indeed, quite right. I happened to add a flag to turn off the heartbeat so I could debug the crash Matthew was seeing in starting up Squeak4.2-10856-beta.image (since single-stepping through machine code always gets interrupted by the heartbeat, it being an interval timer) and lo and behold the bug went away. This is very worrying because it appears to imply that there's a serious bug in the linux kernel/gcc since delivering a software interrupt shouldn't corrupt registers, but it clearly does. I'll try and pass it by someone who's an expert in this area. Anyway, now find a new linux VM in VM.r2346/<http://www.mirandabanda.org/files/Cog/VM/VM.r2346/> that seems fine with the interpreter and the cogit compiled at -02 but the heartbeat compiled at -O2. Running this VM on CentOS 5.3 under Parallels I get 2839 run, 2796 passes, 7 expected failures, 24 failures, 11 errors, 0 unexpected passes for the full test suite in Squeak4.2-10856-beta.image. So have at it. best Eliot > I will start coding cmake config for Cog during next week and will be > able to check my previous > observations again. > > > best > > Eliot > > On Sat, Jan 1, 2011 at 11:16 PM, <mkobetic(a)gmail.com> wrote: > > -- > Best regards, > Igor Stasenko AKA sig. > >

Jan. 11, 2011

[Pharo-project] Pharo/Seaside UI testing

by Tony Fleig

I have to say, I am loving the Pharo/Seaside development environment. Manually testing TFLogin (a basic login and user account management package for Seaside) using Firefox was taking longer and longer as added features multiplied the number of cases to be tested. I had unit tests for the underlying pieces; testing the callbacks on the rendered pages was where most of my time was being spent. Yesterday I loaded WebClient and Soup from Squeaksource and together they made it possible for me to script tests of the TFLogin Web UI without needing a browser. This even includes verifying confirmation email callbacks. I've constructed web apps in other environments (e.g. LAMP, ASP) and never had this level of automated testing. Its surely not impossible in other development environments, but somehow it never happened. I've been thinking about why in the Pharo/Seaside environment this seemed so natural and I've come up with these reasons: 1. It required no extra infrastructure or products to set up the test environment. Seaside's server, the WebClient clients, Soup, and the TFLogin test app are all present in the Pharo image. 2. No shell scripts or Perl or Python code was necessary. 3. The tests cases are integrated into the development environment, and are not in another tool or language. Regards, TF

Jan. 11, 2011

Re: [Pharo-project] Issue 3525 in pharo: Compiler>>parserClass is broken and does not querying the class for providing the parser class

by pharo＠googlecode.com

Updates: Status: Fixed Comment #5 on issue 3525 by siguctua: Compiler>>parserClass is broken and does not querying the class for providing the parser class http://code.google.com/p/pharo/issues/detail?id=3525 Here the fix. Test are green afterwards. AFAIK, this bug+fix applicable to Squeak as well. Attachments: CompilerParser-class-fix.1.cs 408 bytes

Jan. 11, 2011