- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Exupery VM crashed with SegFault

by Baskakov Daniel

Hi, I'm getting this error on Linux Mint 7 (Ubuntu 9.04). Calling of: UUID>>new ^(self new: 16) crashes Pharo on: UUID>>initialize self primMakeUUID. I've changed to: UUID>>new ^(self new: 17) and it stops crashing. 2009/3/30 Damien Cassou <damien.cassou(a)gmail.com>: > Hi, > > try to evaluate the following code in any Pharo image using the > Exupery Unix VM and you will get a Segmentation Fault. > > Preferences setMenuFontTo: (LogicalFont familyName: 'DejaVu Serif' > pointSize: 10). > > $ squeak -version > 3.10-3 #29 Fri Feb 27 22:09:30 GMT 2009 gcc 4.1.2 > Pharo0.1 of 16 May 2008 [latest update: #10074] > Linux localhost 2.6.24.4 #9 SMP Sat Jul 19 21:31:15 BST 2008 i686 > Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz GenuineIntel GNU/Linux > default plugin location: /usr/local/lib/squeak/3.10-3/*.so > > Segmentation fault > > 2025578964 UUID>initialize > 2025578848 Behavior>new: > 2025578756 >new > 2025578664 >setTimeStamp > 2025578480 >updateInstances > 2025560892 >setMenuFontTo: > [...] > > The code which crashes: > > UUID>>initialize > Â Â Â Â self primMakeUUID. > > UUID>>primMakeUUID > Â Â Â Â <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> > Â Â Â Â UUIDGenerator default generateBytes: self forVersion: 4. > > If I remove the call to the primitive, things works and the font is changed. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 5, 2009

[Pharo-project] [ANN] More Rewrite

by Gabriel Cotelli

Name: SLICE-MorphicInitializeRewrite-GabrielOmarCotelli.2 Author: GabrielOmarCotelli Time: 4 June 2009, 9:02:38 pm UUID: 60b72201-3d93-a74a-8473-6a74e2346452 Ancestors: SLICE-MorphicInitializeRewrite-GabrielOmarCotelli.1 Dependencies: Files-GabrielOmarCotelli.ducasse.51, Graphics-GabrielOmarCotelli.96, HostMenus-GabrielOmarCotelli.12, Morphic-GabrielOmarCotelli.315, MorphicExtras-GabrielOmarCotelli.130, Sound-GabrielOmarCotelli.ducasse.30, Tools-GabrielOmarCotelli.158 Rewriting of some class initialize related methods. If I not missed nothing... there's only 12 remaining dirty methods Please review. Gabriel

June 5, 2009

Re: [Pharo-project] SharedQueue

by Marcus Denker

On 04.06.2009, at 19:09, Gabriel Cotelli wrote: > Hi, > > anybody knows why exists SharedQueue2 ?? > > Seem to be used only in test cases... There used to be problems with SharedQueue, so Lex Spoon (I think) proposed to use a Monitor based one with tests. We added that to 3.9 at some point, with the idea of testing it. I think SharedQueue2 can be removed, there have been bugfixes included for SharedQueue in the meantime. Marcus

June 5, 2009

[Pharo-project] SharedQueue

by Gabriel Cotelli

Hi, anybody knows why exists SharedQueue2 ?? Seem to be used only in test cases... Gabriel

June 4, 2009

[Pharo-project] [ANN] RevertHTTPSocketSystemWindow

by Gabriel Cotelli

Name: SLICE-RevertHTTPSocketSystemWindow-GabrielOmarCotelli.2 Author: GabrielOmarCotelli Time: 4 June 2009, 8:02:26 pm UUID: 9c77c9bb-bfbb-dd42-90dc-d4f2a61f01e4 Ancestors: SLICE-RevertHTTPSocketSystemWindow-GabrielOmarCotelli.1 Dependencies: Morphic-GabrielOmarCotelli.314, Network-Protocols-GabrielOmarCotelli.8 Reverted conflicting methods to previous versions. Made by Yoshiki in Squeak. HTTPSocket>>logToTranscript SystemWindow>>mouseMove:

June 4, 2009

[Pharo-project] HScaleMorph and VScaleMorph in Polymorph

by Adrian Lienhard

Hi Gary, Recently, I removed the class ScaleMorph because it was not license clean and it was not used. Only now I've noticed that there are indirect subclasses in Polymorph (HScaleMorph and VScaleMorph inheriting from FixedScaleMorph). Can we remove these three classes? They are not referenced and don't have any instances. Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

June 4, 2009

[Pharo-project] [ANN] Update #10325

by Adrian Lienhard

- fix MethodDictionary>>#do: (used by OCompletion) - 863: Disable font scanning at startup - 842: License cleaning: remove SkipList - 842: License cleaning: remove topologicallySortedUsing:, sortTopologically, should:precede:, and their tests ___________________ http://www.adrian-lienhard.ch/

June 4, 2009

Re: [Pharo-project] an odd bug

by Hernan Wilkinson

yes, but not only that... I also create "complete objects" from its very first time. For example, instead of:Date new day:1; moth:1; year: 2009. I do: Date newDay: 1 moth: 1 year: 2009. That way you will never have an invalid Date 2009/6/4 Steve Wirts <stevewirts(a)gmail.com> > That's the Null Object Pattern! > > http://en.wikipedia.org/wiki/Null_Object_pattern > > > 2009/6/4 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > > I was going to suggest exactly that.As a rule, I never use nil because if >> you do it you will have to check for it somewhere... nil is the root of most >> of the problems! if not, look at all the errors I fixed in the other mail, >> most of them are because nil is being used. >> So, instead of nil, another object has to be use, and like you said in >> this case an empty collection I think will work. I'm just changing that... >> I'll send the changes today (I hope). >> >> Hernan. >> >> >> On Thu, Jun 4, 2009 at 11:32 AM, Michael Rueger <m.rueger(a)acm.org> wrote: >> >>> Sean Allen wrote: >>> >>> > Just as a bit more info. I used squeak for several months without ever >>> > seeing this error. >>> > I used pharo for 3 months without seeing this error. I've only gotten >>> > this error in the latest images >>> > with the latest vm and get it constantly. Not occassionally, I can get >>> > this to happen at least >>> > once every 120 seconds or so, sometimes more often. It would seem to be >>> > as an outsider, >>> > that something must have changed. >>> >>> it definitely sounds like it. >>> Would be good to investigate what might have changed in the call path >>> that *sets* the variable to check why it is ending up being nil. Maybe >>> it shouldn't be set or initialized to nil but to an empty collection in >>> those cases? >>> >>> Michael >>> >>> _______________________________________________ >>> 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 >

June 4, 2009

Re: [Pharo-project] [ANN][Dev-Images] June 2009 versions

by Schwab,Wilhelm K

Damien, All, I tried the web image, and I'm glad I did. I cannot in good conscience rave about the keyboard response, but it is much improved over recent versions, and the anti-aliased text is stunning. <well-intentioned-rant> OmniBrowser is too slow for its own good, at lest in my experience. I recall some mention of backward compatibility with Squeak preventing a refractoring of its handling of packages for efficiency. If that is the last word, then maybe we need to re-think our dependence on it?? Perhaps I am too distant from the details to understand what it does for us, but the several+ second delays are getting old. One reason I had trouble repackaging code was that the command to create a package is not always displayed: in fact, it is _not_ displayed precisely when (by selected item) it is needed most! Specifically, it does not appear when a "non-packaged" item is selected. Another thing that bit me is that, especially in categorizing methods as extensions, I had to re-type the desired category many times. There appears to be some learning of the categories, but it is slow to happen, and did not occur in time to save me from myself. </well-intentioned-rant> Bill

June 4, 2009

Re: [Pharo-project] an odd bug

by Steve Wirts

That's the Null Object Pattern! http://en.wikipedia.org/wiki/Null_Object_pattern 2009/6/4 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > I was going to suggest exactly that.As a rule, I never use nil because if > you do it you will have to check for it somewhere... nil is the root of most > of the problems! if not, look at all the errors I fixed in the other mail, > most of them are because nil is being used. > So, instead of nil, another object has to be use, and like you said in this > case an empty collection I think will work. I'm just changing that... I'll > send the changes today (I hope). > > Hernan. > > > On Thu, Jun 4, 2009 at 11:32 AM, Michael Rueger <m.rueger(a)acm.org> wrote: > >> Sean Allen wrote: >> >> > Just as a bit more info. I used squeak for several months without ever >> > seeing this error. >> > I used pharo for 3 months without seeing this error. I've only gotten >> > this error in the latest images >> > with the latest vm and get it constantly. Not occassionally, I can get >> > this to happen at least >> > once every 120 seconds or so, sometimes more often. It would seem to be >> > as an outsider, >> > that something must have changed. >> >> it definitely sounds like it. >> Would be good to investigate what might have changed in the call path >> that *sets* the variable to check why it is ending up being nil. Maybe >> it shouldn't be set or initialized to nil but to an empty collection in >> those cases? >> >> Michael >> >> _______________________________________________ >> 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 >

June 4, 2009