- Pharo-dev - lists.pharo.org

Re: [Pharo-project] some patterns I would like to **kill**

by Schwab,Wilhelm K

Hey, I want some credit here - for coming to Squeak's possible defense :) All I am saying is that there is a possible space/speed tradeoff with a twist. There was a fair amount written about these decisions, which is why I know anything at all about them. Adding an instance variable for a rarely used sub-morph of a widely-instantiated morph might be an opportunity to fail to learn from history. Most likely, the patterns Stef has noticed are simply mis-uses of sparse storage. The best way to proceed would be to find an example of it that has many instances in the image, profile, fix, and profile again to see if the fix hurts performance (or perhaps helps it). The usual caveats about benchmarking being really hard to do well apply, of course. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Saturday, October 23, 2010 11:00 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] some patterns I would like to **kill** On 23 October 2010 17:13, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Stef, > > Of course. But in terms of avoiding unintended consequences, just consider the points I raised. Some of the avoidance of instance variables (extensions, etc.) might have been a good idea with the gc at the time but is now an ugly hack, or that sparse storage tricks were over-used. > Well, one way or another you have to tame the complexity somehow. Be it extra instvar, or putting it into extensions doesn't changes the model's concept: you need a reference to some object which is responsible for some specific stuff. > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, October 23, 2010 7:33 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] some patterns I would like to **kill** > > I think that if you have a container that contains morphs probably findA and other queries are useful. > Now for a button that is also at the same place a field is the best. > > Stef > > > On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> #respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak. >> >> Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read. >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] >> Sent: Thursday, October 21, 2010 4:47 PM >> To: Pharo Development >> Subject: [Pharo-project] some patterns I would like to **kill** >> >> Hi >> >> I was reading Pluggable and friends >> I identified some patterns. >> >> >> The respondsTo plague >> Examples: >> >> color := self fillStyle asColor. >> (self labelMorph respondsTo: #enabled:) >> ifTrue: [self labelMorph enabled: self enabled]. >> (self labelMorph respondsTo: #interactionState:) >> ifTrue: [self labelMorph interactionState: self interactionState] >> >> (self labelMorph respondsTo: #enabled:) ifTrue: [ >> self labelMorph enabled: aBoolean]. >> >> (self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]]) >> >> >> by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed. >> >> >> Using submorphs to avoid one single inst var makes code quite ugly to read: >> >> >> labelMorph >> "Answer the actual label morph." >> >> self hasSubmorphs ifFalse: [^nil]. >> self firstSubmorph hasSubmorphs ifFalse: [^nil]. >> ^self firstSubmorph firstSubmorph >> >> >> >> >> >> _______________________________________________ >> 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 > -- 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

Oct. 23, 2010

Re: [Pharo-project] Object>>at:modify:???

by Philippe Marschall

On 23.10.2010 14:23, Philippe Marschall wrote: > On 22.10.2010 23:04, Hernan Wilkinson wrote: >> In a 1.1 image I have, the class HttpRequest is using that message... > > At least we should move it to Dictionary. But I think we can easily fix Kom. It's gone in KomHttpServer-pmm.60 Cheers Philippe

Oct. 23, 2010

Re: [Pharo-project] [Metacello] Re: problem with metacello in 1.2

by Tudor Girba

Several people had the same problem today: Fabrizio and Jorge in Bern, and Jannik in Lille. And they had it with different versions of Pharo 1.2. Cheers, Doru On 23 Oct 2010, at 19:05, Mariano Martinez Peck wrote: > > > On Sat, Oct 23, 2010 at 7:05 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Wierd...now I have the same problem :( > > > On Sat, Oct 23, 2010 at 6:06 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > I think you were having a problem with the internet connection. Here it is fine. > Try again ;) > > 2010/10/23 Fabrizio Perin <fabrizio.perin(a)gmail.com> > Hi all, > i was trying to make Moose loadable into a 1.2 i did try to run the configuration of Moose and i got an error at the very beginning caused by the configuration of metacello. Am i missing something or it actually should work? I did expect to have problem but not with the configuration of metacello. > > I'm using a > > Pharo image 12203 on a Squeak4.2.5beta1U VM > > To reproduce the error just open the image and execute in a workspace: > > Gofer new > squeaksource: 'Moose'; > package: 'ConfigurationOfMoose'; > load. > (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault > > Attached the log. > > Thanks, > Fabrizio > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- www.tudorgirba.com "One cannot do more than one can do."

Oct. 23, 2010

Re: [Pharo-project] Pavel can you check :)

by Pavel Krivanek

Hi, fix attached to the issue. Unknown classes are initialized at the end by alphabetical order. Cheers, -- Pavel On Sat, Oct 23, 2010 at 12:39 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > When I clicked on a package, it got downloaded to the package cache using the writeDefinitions: method > > writeDefinitions: aCollection > Â Â Â Â "initStream is an ugly hack until we have proper init defs" > > Â Â Â Â initializers := Dictionary new. > > Â Â Â Â (MCDependencySorter sortItems: aCollection) > Â Â Â Â Â Â Â Â do: [:ea | ea accept: self] > Â Â Â Â Â Â Â Â displayingProgress: 'Writing definitions...'. > > Â Â Â Â (Class superclassOrder: (initializers Â keys collect: [:each | Smalltalk classOrTraitNamed: each])) do: [:class | > Â Â Â Â Â Â Â Â stream nextPutAll: (initializers at: class name) contents ]. > > > Now it is bugging because initializers keys could contain a class that is not in the image and then put nil in the set > The previous version of the method was: > > writeDefinitions: aCollection > Â Â Â Â "initStream is an ugly hack until we have proper init defs" > Â Â Â Â initStream := String new writeStream. > > Â Â Â Â (MCDependencySorter sortItems: aCollection) > Â Â Â Â Â Â Â Â do: [:ea | ea accept: self] > Â Â Â Â Â Â Â Â displayingProgress: 'Writing definitions...'. > > Â Â Â Â stream nextPutAll: initStream contents. > > > - The previous version did not save initializers or may be different > > - Now the changes does not take into account classes that are not in the image. > And this one should still be saved > > > > > > > > > > On Oct 23, 2010, at 12:22 PM, StÃ©phane Ducasse wrote: > >> Apparently when we browse >> Compiler-eem.155 from the squeak trunk (ScriptLoader new addExtraRepositories) >> >> we get a problem because there is a nil in the set. >> >> Can you have a look? >> >> Stef >> _______________________________________________ >> 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 >

Oct. 23, 2010

[Pharo-project] "suggest" for the sprint

by Mariano Martinez Peck

I also agree with Marcus idea: 'lets integrate much make us be more productive and progress faster'. I would love to have the Benjamin work. - Remove "Messages Names" and "Method FInder" and put his new tool. - Put his new changes browser. I would be really really nice to have this, even if it is not perfect yet. People may start to use it, report issues and give feedback. Thanks Mariano

Oct. 23, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

On Fri, Oct 15, 2010 at 6:40 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > > On 15 oct. 2010, at 17:31, Mariano Martinez Peck wrote: > > > They've changed a lot from 1.0. For example, self, super, etc, are not in > "orange" or that color of 1.0. > > Instances variables, are blue (instead of black), the same as > parameters,etc... > > > > is there a way to recover the original colors? do we wanted this change > or it is accidental ? > > > > I think the colors in 1.0 were inherited from the dev images build by > Damien Cassou. In 1.1, the colors comes from the settings of Lukas, who > maintains Shout? Am I wrong? > > I liked the colors in 1.0, but now I am accustomed to the current theme, > which is very keen to the eye, except for two things that I change: > - distinguish instance vars/class vars from other variables: I use a > brownish color for that, as I want to see at once methods accessing the > state of the object > - distinguish class references: I use bold black as in the previous style, > as I want to quickly catch hard dependencies in the code > > EXACTLY!!! this is exacrtly the same that bothers me. > To customize colors, two solutions: > 1) hack SHTextStylerST80>>defaultStyleTable > did you do this? can you share? > 2) load latest Shout and use Settings (then you should be able to save/load > your style), since there is now a Settings interface > > The problem is that I have my own style also....and when you save an style I think you save it completly...I guess you cannot merge, so I will loose my own changes. Anyway, can you export and share the style so that I can take a look? Thanks! Mariano > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

Re: [Pharo-project] what happened with Shout colors in Pharo 1.1?

by Mariano Martinez Peck

On Fri, Oct 15, 2010 at 9:21 PM, Ramon Leon <ramon.leon(a)allresnet.com>wrote: > On 10/15/2010 9:40 AM, Simon Denier wrote: > >> >> On 15 oct. 2010, at 17:31, Mariano Martinez Peck wrote: >> >> They've changed a lot from 1.0. For example, self, super, etc, are not in >>> "orange" or that color of 1.0. >>> Instances variables, are blue (instead of black), the same as >>> parameters,etc... >>> >>> is there a way to recover the original colors? do we wanted this change >>> or it is accidental ? >>> >> >> I think the colors in 1.0 were inherited from the dev images build by >> Damien Cassou. In 1.1, the colors comes from the settings of Lukas, who >> maintains Shout? Am I wrong? >> > > I preferred the old colors as well and switched them back. The new ones > are just too weak, not enough color, not enough bold, can't tell things > apart. > Exactly. Can you or Simon provide a script to set back the original colors?? So that we can apply this for next PharoDev images? (or at least for my own images) Thanks Mariano > > -- > Ramon Leon > http://onsmalltalk.com > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

Re: [Pharo-project] Loading FFI into Pharo?

by David T. Lewis

On Fri, Oct 22, 2010 at 10:40:50AM +0200, Mariano Martinez Peck wrote: > On Fri, Oct 22, 2010 at 10:33 AM, Friedrich Dominicus < > frido(a)q-software-solutions.de> wrote: > > > Mariano Martinez Peck <marianopeck(a)gmail.com> writes: > > > > > On Fri, Oct 22, 2010 at 10:05 AM, Friedrich Dominicus < > > > frido(a)q-software-solutions.de> wrote: > > > > > > Friedrich Dominicus <frido(a)q-software-solutions.de> writes: > > > > > > > "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> writes: > > > > > > > >> I haven't had much trouble with it. You can look in the inbox for > > > >> Migrate (for how I load it) and the DolphinCompatibility package > > for > > > >> things that I have added to the ODBC support. > > > > Are there any usage examples for ODBC and Pharo or is it go out and > > find > > > > out yourself? And another maybe stupid question has anyone used it > > for > > > > accessing .mdb databases from MS-Access? > > > Ok i'm probabla currently a bit confused. AFAIKT the Pharo I've > > running > > > here is 32-bit. My machine however is a 64-bit System, so to use the > > > unixodbc I probably would need the 32-bit version of the unixodbc > > > driver. Is that correct? > > > > > > > > > Yes. Exactly. To compile ODBC you may want to try something like we did > > in > > > SqueakDBX: > > > > > > http://www.squeakdbx.org/SqueakDBX%20in%2064%20bits > > Thanks my confusion has not last that long. I just was puzzling why isql > > does connect but Pharo won't. Sure the reason is clear, but it has > > catched me. Fine, I'm trying to get unixodbc compiled an installed on my > > 64 bit box. I just wonder has anyone build a 64-bit Pharo? > > > > More or less. Because you need: a 64 bits VM, and a 64 bits image as much as > I understand. > In addition, there are certain bugs in FFI about using it in 64 bits. > Details here: http://bugs.squeak.org/view.php?id=7237 FFI can be made to work on 64-bits but it is difficult and complicated, so if you are just trying to get ODBC working you should stick with 32 bit binaries. Dave

Oct. 23, 2010

Re: [Pharo-project] problem with metacello in 1.2

by Mariano Martinez Peck

On Sat, Oct 23, 2010 at 7:05 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Wierd...now I have the same problem :( > > > On Sat, Oct 23, 2010 at 6:06 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> I think you were having a problem with the internet connection. Here it is >> fine. >> Try again ;) >> >> 2010/10/23 Fabrizio Perin <fabrizio.perin(a)gmail.com> >> >>> Hi all, >>> i was trying to make Moose loadable into a 1.2 i did try to run the >>> configuration of Moose and i got an error at the very beginning caused by >>> the configuration of metacello. Am i missing something or it actually should >>> work? I did expect to have problem but not with the configuration of >>> metacello. >>> >>> I'm using a >>> >>> Pharo image 12203 on a Squeak4.2.5beta1U VM >>> >>> To reproduce the error just open the image and execute in a workspace: >>> >>> Gofer new >>> squeaksource: 'Moose'; >>> package: 'ConfigurationOfMoose'; >>> load. >>> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault >>> >>> Attached the log. >>> >>> Thanks, >>> Fabrizio >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >

Oct. 23, 2010

Re: [Pharo-project] problem with metacello in 1.2

by Mariano Martinez Peck

Wierd...now I have the same problem :( On Sat, Oct 23, 2010 at 6:06 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I think you were having a problem with the internet connection. Here it is > fine. > Try again ;) > > 2010/10/23 Fabrizio Perin <fabrizio.perin(a)gmail.com> > >> Hi all, >> i was trying to make Moose loadable into a 1.2 i did try to run the >> configuration of Moose and i got an error at the very beginning caused by >> the configuration of metacello. Am i missing something or it actually should >> work? I did expect to have problem but not with the configuration of >> metacello. >> >> I'm using a >> >> Pharo image 12203 on a Squeak4.2.5beta1U VM >> >> To reproduce the error just open the image and execute in a workspace: >> >> Gofer new >> squeaksource: 'Moose'; >> package: 'ConfigurationOfMoose'; >> load. >> (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault >> >> Attached the log. >> >> Thanks, >> Fabrizio >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Oct. 23, 2010