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

Re: [Pharo-project] assert:includes

by Daniel P Zepeda

Yes, I had the same problem. I asked him and he was actually talking about "sUnit Improved". I don't know what I should do at this point beyond just fixing the tests to run without this method. What are the plans for the sUnit that is in Pharo right now? Would it be helpful to add that method? I guess what I'm asking is there something I can do to be helpful in this regard? Thanks! DZ On Aug 18, 2009, at 1:16 PM, StÃ©phane Ducasse wrote: > We do not know what is SUnit Enhanced (may be keith improvement of > SUnit) > > Stef > > On Aug 17, 2009, at 11:06 PM, Daniel P Zepeda wrote: > >> I sent this to Mr. Leon, and this was his reply: >> >> You're not running the latest sUnit. Find and load sUnit Enhanced >> which has a better UI and includes these methods. >> >> Bleh, >> >> DZ >> On Aug 17, 2009, at 3:45 PM, Daniel P Zepeda wrote: >> >>> Oh, so you guys are saying that this was a convenience selector that >>> was added in the image I was using which was never in Pharo. I >>> hadn't >>> thought about that, I thought it had something to do with >>> differences >>> in argument precedence, which seems to be a more basic issue between >>> Pharo and Squeak. Since I totally went with Pharo, I removed all of >>> the Squeak images I had, so I don't know if that convenience >>> selector >>> was in the image I was using or not. >>> >>> If it was a convenience selector, I'm glad it was removed, I >>> wouldn't >>> have expected that behavior. I guess I should just make a change set >>> and send it to Mr. Leon to do with what he wants to, as I said the >>> workaround is trivial. >>> >>> DZ >>> On Aug 17, 2009, at 11:45 AM, Adrian Lienhard wrote: >>> >>>> I quickly checked in Squeak 3.9 and 3.10 but they do not have that >>>> method either. So chances are high that this method never was in >>>> Pharo. Maybe it was added by some other package as an extension. >>>> >>>> Cheers, >>>> Adrian >>>> >>>> On Aug 17, 2009, at 18:32 , Henrik Sperre Johansen wrote: >>>> >>>>> I can't remember this change specifically, but to me it seems >>>>> like a >>>>> method was removed from Pharo that just added slight syntactic >>>>> sugar. >>>>> I'd reckon the reasoning was that it was not in some "standard" >>>>> SUnit, >>>>> and thus keeping it lead to worse portability to Smalltalks other >>>>> that >>>>> Squeak. (For example, it does not exist in VisualWorks) >>>>> A case could be made that the method should have been deprecated >>>>> rather >>>>> than removed, but done is done, and all that :) >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> On 17.08.2009 18:17, Daniel P Zepeda wrote: >>>>>> Greetings, >>>>>> >>>>>> I've run across this in my own tests that ran fine in Squeak, but >>>>>> failed in Pharo. I thought it was just me being a dummy, but >>>>>> when I >>>>>> imported SandstoneDb and ran the tests, the exact same thing >>>>>> happens. >>>>>> It is a simple fix, but being fairly new at this, I'd like to >>>>>> know >>>>>> why >>>>>> this is, and if I should have to do this or not. >>>>>> >>>>>> So, for easy reference, I loaded the latest SandstoneDb (rjl.117) >>>>>> into >>>>>> my image (pharo1.0beta-10401web09.07.5) and ran the tests, >>>>>> several >>>>>> of >>>>>> which failed with a doesNotUnderstand: #assert:includes: >>>>>> >>>>>> Here is the test: >>>>>> >>>>>> testCollectionSerialization >>>>>> kid save. >>>>>> mom children: (OrderedCollection with: kid). >>>>>> mom save. >>>>>> self flushAndReload . >>>>>> self >>>>>> assert: mom refreshed children >>>>>> includes: kid refreshed >>>>>> >>>>>> if I simply put parens around the argument to assert: like this: >>>>>> >>>>>> assert: (mom refreshed children >>>>>> includes: kid refreshed) >>>>>> >>>>>> it passes. In all cases of failing tests with SandstoneDb, that >>>>>> is >>>>>> the >>>>>> case. Any insight here? >>>>>> >>>>>> Thanks! >>>>>> DZ >>>>>> >>> >>> _______________________________________________ >>> 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

Aug. 18, 2009

[Pharo-project] Fwd: REPOST: Complex Solution Outline

by StÃ©phane Ducasse

Begin forwarded message: > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > Date: August 18, 2009 2:09:15 AM CEDT > To: "Ken.Dickey" <Ken.Dickey(a)whidbey.com> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: RE: REPOST: Complex Solution Outline > > Ken, > > Please put this on the wiki; we try to keep the process > transparent. As should be no surprise by now, I question the value > of $< for complex numbers - I just don't see the point of defining > one that works so infrequently as this, and I see reasons not to > offer one at all. People knowing their way around floating point > math and applications of complex variables will know what to do for > any given comparison based on physical motivations. > > Removing things and making packages seems (Stef?) to be a general > approach to cleaning, so I doubt there will be resistance to that > idea. > > I think the extended complex solution is risky. That is not to say > you should not write it and use it, but it should be separate and > clearly marked with caveats; I can speak only for myself (and > probably for Sig), but I would *not* want it in my image. Much of > what you have expressed as concerns about the current implementation > involves yet another dimension, which is treating the few "nice" > numbers that exist without roundoff error; it would be an exact and/ > or symbolic package. I think it would yield very little benefit > from a LOT of work, but you seem to care about it, so it should > probably be described. Even if it never gets built, giving it a > name would help sort out the various feature demands. > > Finally, there is a lot that should be added to this. There should > be a GSL or similar FFI or plugin and wrappers to bring the > elementary and special functions into Pharo. That is actually > bigger than just complex numbers, so it probably deserves its own > wiki page and plan. > > Bill > > > > -----Original Message----- > From: Ken.Dickey [mailto:Ken.Dickey@whidbey.com] > Sent: Monday, August 17, 2009 6:14 PM > To: Schwab,Wilhelm K > Subject: REPOST: Complex Solution Outline > > Bill, > > Feedback appreciated. > > Thanks, > -KenD > VVV==============unComplex.txt================VVV > INTRODUCTION > > The current Complex class is not carrying its weight in the Pharo- > Core image. > It appears to be little used and has some serious integration > problems with the numeric classes. > > This proposal has three parts, removeComplex, basicComplex, and > extendedComplex. > > The removeComplex package removes the Complex class and associated > code from the current (beta1) image. > > The basicComplex package adds Complex back with some additional > changes to fix some of the integration problems, but leaves out some > mathematical properties to assure backward compatability. > > The extendedComplex package makes the Complex number implemantation > more complete mathematicaly at the expense of backward code > compatability and may break some software. Caveat programmer. > > Note that there is no attempt to change oddities of Smalltalk syntax. > E.g. > (3 + 1/2i) --> (0 - 2i) NOT (3 + (1/2)i) > > > > PROBLEMS > > In mathematics, type Complex is a superset of type Real, but in > Pharo the class Complex is unrelated to subclasses of Number. This > causes some common expectations to be disappointed. In particular, > the following patterns break > down: > > [1] If (A=a) and (B=b) and (A<B) then (a<b) [2] A squared sqrt = A > [3] A isNumber => (A class) isKindOf: Number > > [1] | A a B b } > A := 0. > a := A + 0i. > B := 1. > b := B asComplex. > A = a. "true" > B = b. "true" > A < B. "true" > a < b. "ERROR" > > [2] 1i squared. "-1 + 0i" > 1i squared sqrt. "ERROR" > 1i squared real sqrt. "ERROR" > > [3] (1.2 + (1/2)i) isNumber. "true" > (1.2 + (1/2)i) class isKindOf: Number. "false" > > In particular, isNumber is used in a number of low-level methods > which would not deal well with complex numbers. > > E.g. FloatArray>> > *= anObject > ^anObject isNumber > ifTrue:[self primMulScalar: anObject asFloat] > ifFalse:[self primMulArray: anObject] > > > SOLUTIONS > > > [A] removeComplex > > Removing the Complex code gives more traditional Smalltalk > expectations. In particular this conservative approach yields the > best code backward compatability because Complex is a relatively > recent addition to Squeak and was not present in many older > Smalltalk implementations. In particular, problems [1][2][3] cannot > arise. > > > [B] basicComplex > > [1] Can be fixed by adding a "formal" method to Complex with > selector #< which only compares real numbers (those whose imaginary > component is zero). > > [2] Will remain unaddressed for backward compatability. > > [3] I propose to remove the isNumber method from Complex and add > isNumberOrComplex to both Number, Object, and Complex. [Better > solutions anyone? Better name (isNumeric)?] This avoids changing a > lot of baseline code. > > > [C] extendedComplex > > [2] The sqrt and ln methods will extended to return complex results > for negative numbers. > > Other changes may be cased by adding guard code for users of methods > which did not formerly return complex results. > > > > -KenD [Ken dot Dickey at Whidbey dot Com] > ^^^==============unComplex.txt===============^^^

Aug. 18, 2009

[Pharo-project] Slime and '#fixCallbackTemps possibly missing'

by Stan Shepherd

Hi, one of the Slime error checks throws the warning '#fixCallbackTemps possibly missing'. Am I right in thinking I can ignore this in the Seaside one click image? Thanks ...Stan -- View this message in context: http://n2.nabble.com/Slime-and-%27-fixCallbackTemps-possibly-missing%27-tp3… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 18, 2009

[Pharo-project] Fwd: OverlyComplex

by StÃ©phane Ducasse

Begin forwarded message: > From: "Ken.Dickey" <Ken.Dickey(a)whidbey.com> > Date: August 18, 2009 8:36:53 PM CEDT > To: pharo-project-owner(a)lists.gforge.inria.fr > Subject: OverlyComplex > > Greetings, > > I have done a brief write up of Complex issues that most concern me > and opened > ISSUE 1072: OverlyComplex. > > http://code.google.com/p/pharo/issues/detail?id=1072 > > > Note that there are to be three proposals: > removeComplex [Issue OverlyComplex] > basicComplex > extendedComplex > > SLICE-remove-Complex, the first of the three changesets, has been > added to > PharoInbox as per > http://code.google.com/p/pharo/wiki/HowToContribute > > I logged on to Pharo's Google Wiki but fail to see how to add a > topic/page. > Can some kind soul help me out? > > Again, I am new to your processes, so any help/suggestions/info are > welcomed. > > Thanks much, > -KenD >

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by StÃ©phane Ducasse

Hi todd this is cool that you work on that. I imagine that it will not be an easy task. One of the goal of pharo and effort of mike was to make sure that we get a better event system so that we can plug together different UI. Now about PasteUpMorph cleaning I do not know. What is clear to me is that a registeration for menu is missing. Keep pushing. I guess that this is the kind of work that is not fixed in a couple of days. On Aug 18, 2009, at 3:27 AM, Eagle Offshore wrote: > Thanks so much for sharing on this. > > There seems to be a few caches of stuff stashed in various places. > None of it is exactly complete. I've taken the bulk of it from the http://source.impara.de/HostWindows > and a bit from your experimental directory and looked at the plugins > code in the VM tree and then just started trying to fix problems > with event delivery. I'd like to pull it all together and make it > coherent on Windows, OS X and Unix. > > Its really great that Pharo has integrated the HostMenus stuff - I > think it would be cool to do HostWindows too. Once you eliminate > having to emulate the look of the windows - most widget sets look > pretty similar and I think morphic widgets inside of real windows > would keep things from looking too weird while preserving the > benefits of having our widgets in Smalltalk. > > Given Pharo's "take no prisoners" attitude, I think getting host > windows working would allow a lot of really ugly code in > PasteUpMorph and HandMorph to just go away. Event delivery in > Morphic is just totally incomprehensible and I'm finding it is > broken when a second window is introduced as the mouse coordinates > seem to be delivered window relative. Its also really hard to work > on because I keep junking images by making changes that wreck the UI. > > -Todd Blanchard > > > On Aug 17, 2009, at 6:02 PM, John M McIntosh wrote: > >> Well let me comment >> >> For years the squeak community complained about the fact there was >> just one window and morphic, and no way >> to offer native widgets or have more than one window. >> >> The folks providing funding for Sophie complained about this same >> fact >> too. >> >> So years ago, Tim and I spent a summer working out how to provide the >> multiple window support for Squeak >> aka Areithfa Ffenestri http://wiki.squeak.org/squeak/3862 >> >> It's quite simple, the HostWindowProxy proxy lets you manipulate the >> window and draw to it. >> The VM was changed so that Events *should* tag UI events with a >> window >> index number. >> EventSensor then brings up the events and hands them to who ever is >> interested. >> >> It's all fully explained on the web page. >> >> We built it on the macintosh first, with *pending* support for the >> other platforms. I'm sure Bert did a Linux variation. >> mmm I'm sure windowIndex 0 refers to the main squeak window btw. >> >> The original source code without complexity should sit in the >> ftp.smalltalkconsulting.com/experimental/Ffenestri/ >> changes sets >> Ffenestri-b-1 thru b-4 >> >> You should be able to load it into a Squeak image from Jan 2007, >> infact I rebuilt the change sets and tested them in a January 2007 >> image >> for a pending Squeak release let's see, oh yes the email for that is >> attached at the end. >> >> We alter event sensor, as you know that was all changed in Pharo >> It also alters Moprhic a bit so it understands windowIndex logic. >> >> Now about implementation, part of the problem is where does the >> events >> go and where does the drawing go. >> Lots of this is done in globals with no reference to the windowIndex. >> >> We had two implementations >> (a) We alter Project, when you enter project it then set the Display, >> so we could make a Project Window and drawing and mouse events would >> go to it, I'm not sure >> about todays version of Morphic but in the past you could have >> multiple Projects open, but only one would be active, then others >> would be *stopped* >> >> (b) We altered Tweak, Tweak at the time being the future vision of >> Morphic and UI on Squeak. Tweak actually built an environment and >> stuck the UI input queue and display information in an instance >> variable associated with the Tweak world. So it was *trivial* to >> hook >> up the host window proxy display logic and dispatch the events to the >> proper Tweak world. >> >> (c) I lie, I believe Michael Rueger built a subset of morphic (or >> something) that is Ffenestri aware, but I don't think it was ever >> published. >> >> Out of this, there was a dull thud as the folks wanting multiple host >> windows just failed to produce code using it. >> The powers that be that directed Sophie decided in fact one window >> was >> enough, so we never implemented things with multiple windows. >> The version of Tweak we were using in Sophie was grave-yarded. >> >> >> Maybe you could send me the details of your trail of MC loading since >> I don't recall an Process or Delay overrides. We had lots of that in >> Sophie via changes from Tweak/Qwaq to fix evil semaphore and process >> bugs plus Tweak did process priority escalation to solve event >> ordering/semaphore issues. >> >> On 17-Aug-09, at 3:05 PM, Eagle Offshore wrote: >> >>> Well, I may have spoken too soon. Digging into the platform >>> specific >>> window proxies - I see proxies for MacOS 9, OS X, Win32, and >>> Acorn???, >>> but nothing for linux. OTOH, I find source code for a HostWindows >>> plugin in the Unix VM source tree. >>> >>> Anybody with more knowledge of why we have a plugin without a proxy? >>> >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> >> The 3.10 team asked me to build a change set for Ffenestri (multiple >> host window support), and Mac Host Menus for 3.10. >> The last change set was build for Tweak in 2004. >> >> I've updated my ftp site and my idisk in the Ffenestri folder found >> in >> the experimental directory with a number of new >> change sets that let you load the Ffenestri logic into a 3.10 image, >> likely also into a 3.9 image. Testing shows that this re-released >> code >> works with Mac PowerPC and MacIntel. I did uncover a byte order >> problem on macintel btw. >> >> For the additional Macintosh Host menu support, used by Sophie, and >> by >> Scratch I've also pushed out a set of change sets >> to allow one to load that logic into a 3.10 image, likely also into a >> 3.9 image too. Testing shows that this re-released code works with >> Mac >> PowerPC and MacIntel. >> >> I did NOT revisit the Tweak support, there seems to be a LACK of >> interest. Anyone who wants to explore that should email me and I'll >> point out the methods of interest they can rework for Tweak. Of >> course for Tweak you can open a tweak project in a host window and >> expect everything to work since the display and event queue are >> instance variables, not globals like in Morphic. >> >> >> -------------------------- >> Well I note the HostMenu support *is* in Pharo now, so you need to >> very careful what the HostMenus-Events.1.cs does >> -------------------------- >> >> >> Ffenestri-b-1-HostWindowPlugin.2.cs >> This is the plugin for host windows >> >> Ffenestri-b-2-WindowProxies.3.cs >> Setup window proxis >> >> Ffenestri-b-3-MultiHostWindows-Sunits.1.cs >> SUnits to test multiple window support, works on mac powerpc and >> macIntel >> Check with Impara about windows changes to enable support on Windows. >> >> Ffenestri-b-3-MultiHostWindows.1.cs >> Add base support for Multiple windows. >> >> Ffenestri-b-4-Events-Morphic.1.cs >> Adds multiple window support for base Morphic, see Sunits for usage. >> >> HostMenus-Base.2.cs >> Add base support for Mac Host Windows. >> >> HostMenus-Events.1.cs >> Add interface to EventSensor for mac host menus, assumes Ffenestri- >> b-3- >> MultiHostWindows.1.cs is loaded. >> >> HostMenus-Mac-SUnits.1.cs >> SUnit to test mac host menu support, works on mac powerpc and >> macIntel. >> >> HostMenus-Mac-MacPlugin.1.cs >> This is the plugin that provides the menu support for os-9/os-x >> >> >> >> >> >> >> _______________________________________________ >> 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

Aug. 18, 2009

Re: [Pharo-project] ORM for Pharo -- Â½ OFF

by Andreas Wacknitz

Am 18.08.2009 um 17:23 schrieb Mariano Martinez Peck: > > > On Tue, Aug 18, 2009 at 10:37 AM, Esteban A. Maringolo <emaringolo(a)gmail.com > > wrote: > > This is not the case of Pharo. As you may know, most of the ESUG > people are under the Pharo project. > ESUG has selected SqueakDBX as a SummerTalk project and has > sponsored us, not only in 2008 but again this year. > See: http://www.esug.org/Promotion/SummerTalk This page says "Welcome to SummerTalk 2008." Shouldn't it be 2009? Andreas

Aug. 18, 2009

Re: [Pharo-project] Native Windows

by Eagle Offshore

What is the "canonical" window class in Pharo? I see SystemWindow has been subclassed and there's a separate builder for the other window that is otherwise a copy of the default builder. Where was that going? On Aug 18, 2009, at 10:01 AM, Gary Chambers wrote: > I'll keep checking ,but, let me know when the basics are in and I'll > provide > support in Polymorph. > > Regards, Gary > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, August 18, 2009 4:11 PM > Subject: Re: [Pharo-project] Native Windows > > >> 2009/8/18 Eagle Offshore <eagleoffshore(a)mac.com>: >>> I'm curious why you did a new plugin. Does the existing one not work >>> on windows? >>> >> it works , but it duplicating a functionality which also present in >> core platform files: >> - creating a window >> - processing events >> >> so, the idea is to merge & unify all these bits into a single plugin >> and also, make an extended API for >> managing host windows. >> >>> I got the following from Bert on the state of the unix plugin: >>> >>> "The plugin functions are still stubbed out, so you cannot actually >>> open a second window, yet. But at least the hairy part of the work >>> is >>> done - I implemented the dispatching between the HostWindow plugin >>> to >>> the various display modules. This is more complex than on the other >>> platforms, because the unix VM so far supports X11, Quartz, >>> FrameBuffer, and Null display devices. But I did that part, now >>> someone can simply implement e.g. the X11 functions to have it >>> working >>> in Linux. The only function I actually implemented was changing the >>> title of the main Squeak window (window index 1). >>> " >>> >>> -Todd Blanchard >>> >>> On Aug 18, 2009, at 6:03 AM, Igor Stasenko wrote: >>> >>>> 2009/8/18 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >>>>> Before you run too far down the let's change Morphic path you >>>>> should >>>>> check with Igor I'm sure he was off a year back trying to hack >>>>> Ffenestri into Morphic. >>>>> >>>> yes, yes i have an initial implementation of new hostwindows plugin >>>> which moves/separates the windowing stuff from core VM >>>> functionality. >>>> >>>> It then would be possible to build a VM which having no windowing >>>> support at all, and works as a console application. >>>> >>>> The problem with it, that i never did any windowing & event >>>> handling >>>> on X windows or MacOS, >>>> so its not so easy. I'm only hoping that my design fits well with >>>> other platforms, not only win32. >>>> >>>> I can publish the bits i'm done. Just say. >>>> I am swamped by another projects , so i don't know when i could >>>> find a >>>> time to finish it. :( >>>> >>>>> Tim and I gave that thought up when we considered there was 400 >>>>> or so >>>>> references to EventSenor & Display many of which had no concept of >>>>> window ownership in mind. >>>> >>>> Yes, this is a bit of pain. >>>> My thought about it, is to keep sensor global, but >>>> replace all refs to Display to 'self display' message send. >>>> There are only a few methods which assigning new value to Display , >>>> which should be addressed separately. >>>> >>>> >>>>> >>>>> >>>>> On 17-Aug-09, at 6:27 PM, Eagle Offshore wrote: >>>>> >>>>>> Thanks so much for sharing on this. >>>>>> >>>>>> There seems to be a few caches of stuff stashed in various >>>>>> places. >>>>>> None of it is exactly complete. I've taken the bulk of it from >>>>>> the http://source.impara.de/HostWindows >>>>>> and a bit from your experimental directory and looked at the >>>>>> plugins >>>>>> code in the VM tree and then just started trying to fix problems >>>>>> with event delivery. I'd like to pull it all together and make it >>>>>> coherent on Windows, OS X and Unix. >>>>>> >>>>>> Its really great that Pharo has integrated the HostMenus stuff >>>>>> - I >>>>>> think it would be cool to do HostWindows too. Once you eliminate >>>>>> having to emulate the look of the windows - most widget sets look >>>>>> pretty similar and I think morphic widgets inside of real windows >>>>>> would keep things from looking too weird while preserving the >>>>>> benefits of having our widgets in Smalltalk. >>>>>> >>>>>> Given Pharo's "take no prisoners" attitude, I think getting host >>>>>> windows working would allow a lot of really ugly code in >>>>>> PasteUpMorph and HandMorph to just go away. Event delivery in >>>>>> Morphic is just totally incomprehensible and I'm finding it is >>>>>> broken when a second window is introduced as the mouse >>>>>> coordinates >>>>>> seem to be delivered window relative. Its also really hard to >>>>>> work >>>>>> on because I keep junking images by making changes that wreck the >>>>>> UI. >>>>>> >>>>>> -Todd Blanchard >>>>>> >>>>> >>>>> -- >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> ================================================================== >>>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >>>>> squeaker68882 >>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> = >>>>> ================================================================== >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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

Aug. 18, 2009

Re: [Pharo-project] Preference browser does not load from disk

by StÃ©phane Ducasse

Normally the preference browser will be deprecated when we move to the new preferences. I will check the status with alain when he is back from holidays and people could help udring the pharo sprint at ESUG. stef On Aug 18, 2009, at 2:44 AM, csrabak(a)bol.com.br wrote: > In Windows XP SP3, when you save from an image your preferences, it > is possible to see a "my.prefs" file (FWIW about 60 kbytes). > > Then I attempted in the recently anounced PharoCore-1.0-10414-BETA > image to load the preferences from the disk and I got an > "Information" dialog saying: 'there was an error restoring the > preferences'. > > Can anybody check if this is reproducible? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 18, 2009

Re: [Pharo-project] Question about MD5

by StÃ©phane Ducasse

I will :) Stef On Aug 17, 2009, at 9:53 PM, Mariano Martinez Peck wrote: > Stef: you can integrate it when you want: > > Name: Collections-Arrayed-MarianoMartinezPeck.19 > Author: MarianoMartinezPeck > Time: 17 August 2009, 4:45:44 pm > UUID: 0622a079-d239-4a4c-a78a-3f72fabea85b > Ancestors: Collections-Arrayed-stephane_ducasse.18 > > Fix to bug: http://code.google.com/p/pharo/issues/detail?id=1067 > I implemented ByteArray>>hex > > > > Cheers, > > Mariano > > > > On Mon, Aug 17, 2009 at 3:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > > >> 1) commit the hole package to PharoInbox repo > > or read the wiki since everything is explained. > How to contribute > http://code.google.com/p/pharo/wiki/HowToContribute > > _______________________________________________ > 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

Aug. 18, 2009

Re: [Pharo-project] assert:includes

by StÃ©phane Ducasse

We do not know what is SUnit Enhanced (may be keith improvement of SUnit) Stef On Aug 17, 2009, at 11:06 PM, Daniel P Zepeda wrote: > I sent this to Mr. Leon, and this was his reply: > > You're not running the latest sUnit. Find and load sUnit Enhanced > which has a better UI and includes these methods. > > Bleh, > > DZ > On Aug 17, 2009, at 3:45 PM, Daniel P Zepeda wrote: > >> Oh, so you guys are saying that this was a convenience selector that >> was added in the image I was using which was never in Pharo. I hadn't >> thought about that, I thought it had something to do with differences >> in argument precedence, which seems to be a more basic issue between >> Pharo and Squeak. Since I totally went with Pharo, I removed all of >> the Squeak images I had, so I don't know if that convenience selector >> was in the image I was using or not. >> >> If it was a convenience selector, I'm glad it was removed, I wouldn't >> have expected that behavior. I guess I should just make a change set >> and send it to Mr. Leon to do with what he wants to, as I said the >> workaround is trivial. >> >> DZ >> On Aug 17, 2009, at 11:45 AM, Adrian Lienhard wrote: >> >>> I quickly checked in Squeak 3.9 and 3.10 but they do not have that >>> method either. So chances are high that this method never was in >>> Pharo. Maybe it was added by some other package as an extension. >>> >>> Cheers, >>> Adrian >>> >>> On Aug 17, 2009, at 18:32 , Henrik Sperre Johansen wrote: >>> >>>> I can't remember this change specifically, but to me it seems >>>> like a >>>> method was removed from Pharo that just added slight syntactic >>>> sugar. >>>> I'd reckon the reasoning was that it was not in some "standard" >>>> SUnit, >>>> and thus keeping it lead to worse portability to Smalltalks other >>>> that >>>> Squeak. (For example, it does not exist in VisualWorks) >>>> A case could be made that the method should have been deprecated >>>> rather >>>> than removed, but done is done, and all that :) >>>> >>>> Cheers, >>>> Henry >>>> >>>> On 17.08.2009 18:17, Daniel P Zepeda wrote: >>>>> Greetings, >>>>> >>>>> I've run across this in my own tests that ran fine in Squeak, but >>>>> failed in Pharo. I thought it was just me being a dummy, but >>>>> when I >>>>> imported SandstoneDb and ran the tests, the exact same thing >>>>> happens. >>>>> It is a simple fix, but being fairly new at this, I'd like to know >>>>> why >>>>> this is, and if I should have to do this or not. >>>>> >>>>> So, for easy reference, I loaded the latest SandstoneDb (rjl.117) >>>>> into >>>>> my image (pharo1.0beta-10401web09.07.5) and ran the tests, several >>>>> of >>>>> which failed with a doesNotUnderstand: #assert:includes: >>>>> >>>>> Here is the test: >>>>> >>>>> testCollectionSerialization >>>>> kid save. >>>>> mom children: (OrderedCollection with: kid). >>>>> mom save. >>>>> self flushAndReload . >>>>> self >>>>> assert: mom refreshed children >>>>> includes: kid refreshed >>>>> >>>>> if I simply put parens around the argument to assert: like this: >>>>> >>>>> assert: (mom refreshed children >>>>> includes: kid refreshed) >>>>> >>>>> it passes. In all cases of failing tests with SandstoneDb, that is >>>>> the >>>>> case. Any insight here? >>>>> >>>>> Thanks! >>>>> DZ >>>>> >> >> _______________________________________________ >> 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

Aug. 18, 2009