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

[Pharo-project] Underscore assignments

by Torsten Bergmann

+1 -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Nov. 4, 2009

Re: [Pharo-project] RC1 image build failure

by Nicolas Cellier

2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > If I have the order wrong, then I submit we have yet another bug: the text spilled onto my display reads in part: "Original error: MessageNotUnderstood: SharedQueue2>>flushAllSuchThat:." > > You might be correct in flagging #findElementOrNil:, but the text suggests to me that this is a knock on effect to the SharedQueue2 deficiency. Â Further supporting evidence includes that #findElementOrNil: works in the image, and SharedQueue2 is indeed missing methods relative to its task. This message is misleading indeed. > > Either way, how do we fix this? > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier > Sent: Tuesday, November 03, 2009 8:17 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] RC1 image build failure > > 2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Nicolas, >> >> I doubt the images are corrupt, unless the download is somehow damaged. Â #findElementOrNil: works; the problem is more likely that the missing protocol in SharedSet2 lead to an unrecoverable meltdown. Â My question is how it worked as long as it did??? >> >> Bill >> > > I don't think you get the order right. > Follow the sender chain: > > flushAllSuchThat: < flushNonKbdEvents < nextKeyboardEvent < keyboard < 4 senders > - onPrimitiveError: (your case) > - request: used by above message > - flushKeyboard 3 senders, does not fail because 99% of time there is no event to flush > - tempCommand: < disabledCommandActions this one does not seem used > > If you look at your stack trace, you'll see at:ifAbsent: fails first > (doesNotUnderstand: #findElementOrNil:) > > Then onPrimitiveError: is triggered and cause a flushAllSuchThat: > which is not understood... > > That is rare, and that is why it was not encountered before. > > Thus I see 2 bugs: > - one rare bug in SharedQueue2 in Pharo-core > - (Smalltalk doesNotUnderstand: #findElementOrNil:) in your image to be explained first > > Nicolas > >> >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Nicolas Cellier >> Sent: Tuesday, November 03, 2009 7:28 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] RC1 image build failure >> >> 2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >>> Hello all, >>> >>> Whatever is happening, it keeps happening, and on two different machines, but both Ubuntu 9.10, FWIW. Â Attached is a shot of the whatever-it's-called window; the promised emergency evaluator does not appear (not that I would know what to do with it<g>). Â Comparing SharedQueue with SharedQueue2 might be interesting; with luck, there will simply be a missing method?? >>> >>> Bill >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> 1) Yeah, SharedQueue2 does not share same public protocol and that sounds like a bug... >> >> (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e >> | (SharedQueue organization categoryOfElement: e) beginsWith: >> 'private']. >> -> an IdentitySet(#flushAllSuchThat: #nextOrNilSuchThat: #flush) >> >> We might also wanter to filter out unsent ones: >> (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e >> | ((SharedQueue organization categoryOfElement: e) beginsWith: >> 'private') or: [(SystemNavigation default allCallsOn: e) isEmpty]] >> >> >> 2) I find it strange your Smalltalk doesNotUnderstand: #findElementOrNil: >> >> Did you load some changes related to FasterSets or is your image damned corrupted ? >> Try (Smalltalk findElementOrNil: #Object) and tell us the result. >> >> Nicolas >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 4, 2009

Re: [Pharo-project] Underscore assignments

by Peter Hugosson-Miller

+1 -- Cheers, Peter On Wed, Nov 4, 2009 at 9:25 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > I wonder if we should throw a deprecated message in Pharo 1.0 when > somebody tries to compile a method with an underscore assignment? I > would like to make it possible to use underscore characters in > selectors and identifiers in Pharo 1.1. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 4, 2009

[Pharo-project] Underscore assignments

by Lukas Renggli

I wonder if we should throw a deprecated message in Pharo 1.0 when somebody tries to compile a method with an underscore assignment? I would like to make it possible to use underscore characters in selectors and identifiers in Pharo 1.1. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 4, 2009

[Pharo-project] Very simple package save/load tool

by Schwab,Wilhelm K

Hello all, Attached is something that you might find helpful, and it's worth almost everything it cost you. The class comment briefly describes what it is supposed to do. Better ideas will be cheerfully stolen. For now, this seems to be helping me to find methods that I failed to package, avoids the "click several times per package" save process for MC (for which thanks, but it **is** tedious to use), should put an end to forgetting to save packages, and tries to automate loading code into a new image. On the latter, the thinking is that annoying messages are least annoying when presented early; it tries to grumble about silly stuff sooner rather than later; some of the checks might be excessive and other might be inadequate. Read the code before deciding whether you want to use it. Bill CONFIGURE ========= Configure it using #homeGrownPackageNames and #me to tell it which packages are intended to hold your work, and how to identify you from the (misnomer!!!) #timeStamp aspects of the compiled methods you produce. SAVE YOUR WORK ============== Use #suspectMethodsReport to produce a listing of class>>selector names that might be in danger of being orphaned in your current image. Use #homeGrownPackgesSaveWithMessage: to save all of the identified home grown packages in the next version and with the common text message. BUILD A NEW IMAGE ================= Load GatorLoader into a new image. It wants underscore_madness.cs, and loads SIXX and other packages of interest to me; you can edit as needed to remove what you do not want to load. Put your packages in the cache directory for the new image. Yes, it is fussy about these things, but the idea is to find errors early rather than being stopped after a long wait. Likewise, if you do not like what #setPreferences does, edit it.

Nov. 4, 2009

Re: [Pharo-project] RC1 image build failure

by Schwab,Wilhelm K

Nicolas, If I have the order wrong, then I submit we have yet another bug: the text spilled onto my display reads in part: "Original error: MessageNotUnderstood: SharedQueue2>>flushAllSuchThat:." You might be correct in flagging #findElementOrNil:, but the text suggests to me that this is a knock on effect to the SharedQueue2 deficiency. Further supporting evidence includes that #findElementOrNil: works in the image, and SharedQueue2 is indeed missing methods relative to its task. Either way, how do we fix this? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Tuesday, November 03, 2009 8:17 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] RC1 image build failure 2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > I doubt the images are corrupt, unless the download is somehow damaged. Â #findElementOrNil: works; the problem is more likely that the missing protocol in SharedSet2 lead to an unrecoverable meltdown. Â My question is how it worked as long as it did??? > > Bill > I don't think you get the order right. Follow the sender chain: flushAllSuchThat: < flushNonKbdEvents < nextKeyboardEvent < keyboard < 4 senders - onPrimitiveError: (your case) - request: used by above message - flushKeyboard 3 senders, does not fail because 99% of time there is no event to flush - tempCommand: < disabledCommandActions this one does not seem used If you look at your stack trace, you'll see at:ifAbsent: fails first (doesNotUnderstand: #findElementOrNil:) Then onPrimitiveError: is triggered and cause a flushAllSuchThat: which is not understood... That is rare, and that is why it was not encountered before. Thus I see 2 bugs: - one rare bug in SharedQueue2 in Pharo-core - (Smalltalk doesNotUnderstand: #findElementOrNil:) in your image to be explained first Nicolas > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Nicolas Cellier > Sent: Tuesday, November 03, 2009 7:28 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] RC1 image build failure > > 2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Hello all, >> >> Whatever is happening, it keeps happening, and on two different machines, but both Ubuntu 9.10, FWIW. Â Attached is a shot of the whatever-it's-called window; the promised emergency evaluator does not appear (not that I would know what to do with it<g>). Â Comparing SharedQueue with SharedQueue2 might be interesting; with luck, there will simply be a missing method?? >> >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > 1) Yeah, SharedQueue2 does not share same public protocol and that sounds like a bug... > > (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e > | (SharedQueue organization categoryOfElement: e) beginsWith: > 'private']. > -> an IdentitySet(#flushAllSuchThat: #nextOrNilSuchThat: #flush) > > We might also wanter to filter out unsent ones: > (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e > | ((SharedQueue organization categoryOfElement: e) beginsWith: > 'private') or: [(SystemNavigation default allCallsOn: e) isEmpty]] > > > 2) I find it strange your Smalltalk doesNotUnderstand: #findElementOrNil: > > Did you load some changes related to FasterSets or is your image damned corrupted ? > Try (Smalltalk findElementOrNil: #Object) and tell us the result. > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 4, 2009

Re: [Pharo-project] RC1 image build failure

by Nicolas Cellier

2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > I doubt the images are corrupt, unless the download is somehow damaged. Â #findElementOrNil: works; the problem is more likely that the missing protocol in SharedSet2 lead to an unrecoverable meltdown. Â My question is how it worked as long as it did??? > > Bill > I don't think you get the order right. Follow the sender chain: flushAllSuchThat: < flushNonKbdEvents < nextKeyboardEvent < keyboard < 4 senders - onPrimitiveError: (your case) - request: used by above message - flushKeyboard 3 senders, does not fail because 99% of time there is no event to flush - tempCommand: < disabledCommandActions this one does not seem used If you look at your stack trace, you'll see at:ifAbsent: fails first (doesNotUnderstand: #findElementOrNil:) Then onPrimitiveError: is triggered and cause a flushAllSuchThat: which is not understood... That is rare, and that is why it was not encountered before. Thus I see 2 bugs: - one rare bug in SharedQueue2 in Pharo-core - (Smalltalk doesNotUnderstand: #findElementOrNil:) in your image to be explained first Nicolas > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier > Sent: Tuesday, November 03, 2009 7:28 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] RC1 image build failure > > 2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Hello all, >> >> Whatever is happening, it keeps happening, and on two different machines, but both Ubuntu 9.10, FWIW. Â Attached is a shot of the whatever-it's-called window; the promised emergency evaluator does not appear (not that I would know what to do with it<g>). Â Comparing SharedQueue with SharedQueue2 might be interesting; with luck, there will simply be a missing method?? >> >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > 1) Yeah, SharedQueue2 does not share same public protocol and that sounds like a bug... > > (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e > | (SharedQueue organization categoryOfElement: e) beginsWith: > 'private']. > -> an IdentitySet(#flushAllSuchThat: #nextOrNilSuchThat: #flush) > > We might also wanter to filter out unsent ones: > (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e > | ((SharedQueue organization categoryOfElement: e) beginsWith: > 'private') or: [(SystemNavigation default allCallsOn: e) isEmpty]] > > > 2) I find it strange your Smalltalk doesNotUnderstand: #findElementOrNil: > > Did you load some changes related to FasterSets or is your image damned corrupted ? > Try (Smalltalk findElementOrNil: #Object) and tell us the result. > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 4, 2009

Re: [Pharo-project] JPEG plugin.

by John M McIntosh

On 2009-11-03, at 1:01 PM, Andreas Raab wrote: > John M McIntosh wrote: >> I'm looking at the JPEG plugin and wondering? >> (a) Should I convert that to using the os-x platforms JPEG >> implementation, versus our usage of the source from the >> "Independent JPEG Group's software"? > > Seems like a bad trade unless you want to severely rewrite the > plugin interface (making it effectively a new plugin). The current > interface is tied specifically to the IJGs implementation with > internal structures and functions being exposed fairly directly. Yes, however in working with Sophie we noticed *most* interfacing is done via ImageReadWriter which supports a generic interface for creating or reading files or streams. The choice of which class to use is based on iterating over the subclasses and asking who can do the work, it never appeared that people messed about with the JPEG read/write class other than asking for magic decoding/encoding. For Sophie we choose to override this and provided an interface that worked with Apple's quicktime for os-x and Windows to read *lots* of graphics formats and provide us with a resulting form. No doubt I could do the same given if os-x and some flavour of the VM then do a different call path. > >> (b) Should we consider upgrading the VMs from version "6b 27- >> Mar-1998" to the more current "release 7 of 27-Jun-2009" since we >> store the source in the VM SVN tree at the moment. > > That sounds like a good idea. > >> I've not looked but >> (a) Apple might have a private implementation that could be faster >> since it would likely use hardware vector services. > > Almost certainly. Intel's performance prims can make JPEG stuff > quite a bit faster already. > >> (b) Relying on the system libraries for conversion means fixes for >> security issues get prompt attention, versus our non-attention now. > > I'm not sure about this. The IJGs code has been quite robust and to > my knowledge no exploits have ever been published. OTOH, Microsofts > implementation seems to have been sucessfully attacked in the past, > so it's a bit questionable whether using the OS vendors > implementation would necessarily be more secure than the IJGs version. > > Cheers, > - Andreas -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 4, 2009

Re: [Pharo-project] RC1 image build failure

by Schwab,Wilhelm K

Nicolas, I doubt the images are corrupt, unless the download is somehow damaged. #findElementOrNil: works; the problem is more likely that the missing protocol in SharedSet2 lead to an unrecoverable meltdown. My question is how it worked as long as it did??? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Tuesday, November 03, 2009 7:28 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] RC1 image build failure 2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > Whatever is happening, it keeps happening, and on two different machines, but both Ubuntu 9.10, FWIW. Â Attached is a shot of the whatever-it's-called window; the promised emergency evaluator does not appear (not that I would know what to do with it<g>). Â Comparing SharedQueue with SharedQueue2 might be interesting; with luck, there will simply be a missing method?? > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > 1) Yeah, SharedQueue2 does not share same public protocol and that sounds like a bug... (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e | (SharedQueue organization categoryOfElement: e) beginsWith: 'private']. -> an IdentitySet(#flushAllSuchThat: #nextOrNilSuchThat: #flush) We might also wanter to filter out unsent ones: (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e | ((SharedQueue organization categoryOfElement: e) beginsWith: 'private') or: [(SystemNavigation default allCallsOn: e) isEmpty]] 2) I find it strange your Smalltalk doesNotUnderstand: #findElementOrNil: Did you load some changes related to FasterSets or is your image damned corrupted ? Try (Smalltalk findElementOrNil: #Object) and tell us the result. Nicolas _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 4, 2009

Re: [Pharo-project] RC1 image build failure

by Nicolas Cellier

2009/11/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > Whatever is happening, it keeps happening, and on two different machines, but both Ubuntu 9.10, FWIW. Â Attached is a shot of the whatever-it's-called window; the promised emergency evaluator does not appear (not that I would know what to do with it<g>). Â Comparing SharedQueue with SharedQueue2 might be interesting; with luck, there will simply be a missing method?? > > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > 1) Yeah, SharedQueue2 does not share same public protocol and that sounds like a bug... (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e | (SharedQueue organization categoryOfElement: e) beginsWith: 'private']. -> an IdentitySet(#flushAllSuchThat: #nextOrNilSuchThat: #flush) We might also wanter to filter out unsent ones: (SharedQueue selectors difference: SharedQueue2 selectors) reject: [:e | ((SharedQueue organization categoryOfElement: e) beginsWith: 'private') or: [(SystemNavigation default allCallsOn: e) isEmpty]] 2) I find it strange your Smalltalk doesNotUnderstand: #findElementOrNil: Did you load some changes related to FasterSets or is your image damned corrupted ? Try (Smalltalk findElementOrNil: #Object) and tell us the result. Nicolas

Nov. 4, 2009