June 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SketchMorph has no methods

by Tudor Girba

Apparently it was intentionally because the previous thing was full of crap (this was a quote :)). Doru On 11 Jun 2010, at 17:35, Tudor Girba wrote: > Hi, > > In Pharo 1.1, SketchMorph has no methods. Does anyone know why? Were > they removed intentionally or by mistake? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every successful trip needs a suitable vehicle." > > > > -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

June 11, 2010

[Pharo-project] SketchMorph has no methods

by Tudor Girba

Hi, In Pharo 1.1, SketchMorph has no methods. Does anyone know why? Were they removed intentionally or by mistake? Cheers, Doru -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

June 11, 2010

Re: [Pharo-project] [update 1.1] #11392

by Schwab,Wilhelm K

I was afraid of that. So how does text fail and presumably other forms are ok? Perhaps when I learn how to print on Linux, I won't care, but for now, Squeak/Pharo's graphics appear to be poorly designed from a device-independence perspective. Text handling is further weak in that it works on characters, not strings, and therefore cannot begin to cope with kerning. Can anti-aliasing be correct if it does not account for rotation relative to the display medium? Given Squeak's claimed focus on multimedia, it is surprisingly weak on such things. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Johansen [henrik.s.johansen(a)veloxit.no] Sent: Friday, June 11, 2010 10:36 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [update 1.1] #11392 On Jun 11, 2010, at 4:22 43PM, Schwab,Wilhelm K wrote: > Rotating text?? What is the correct way to do that? I have found ways to rotate forms, but not text. What am I missing? You can rotate any morph. What's really happening is the morph (in this case a TextMorph) is displayed on a form, which is then rotated. Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 11, 2010

Re: [Pharo-project] seaside.gemstone.com down - unable to build 1.1-dev

by James Foster

Here is the response I got from IT: "Web cluster fail. We're back up and running on a couple machines; it should be fine now." James On Jun 11, 2010, at 7:05 AM, James Foster wrote: > I'm investigating this with GemStone's IT people. I'll give an update as soon as I have something. > > James Foster > VMware (formerly GemStone Systems)

June 11, 2010

Re: [Pharo-project] GUI Polymorph

by Schwab,Wilhelm K

Gary, That's great to know! There are natural questions, such as whether the rectangle is in screen or morph-relative coordinates (I fear the former), and how to get the same information when rendering (to allow non-visible objects to be skipped), but I'm guessing those answers will flow from browsing beginning with #invalidRect:. At the last steps of this journey, I'm going to need every clock cycle I can get :( Thanks! Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Gary Chambers [gazzaguru2(a)btinternet.com] Sent: Friday, June 11, 2010 10:47 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] GUI Polymorph Take a look at Morph>>invalidRect: as opposed to #changed for more optimal screen updates if required ;-) Nice job on the tutorial Hilaire btw. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, June 11, 2010 2:59 PM Subject: Re: [Pharo-project] GUI Polymorph Hilaire, I will indeed consider it, but it will take me time to get to your level of understanding of Polymorph. My priorities are networking, serial communications, printing (which I am dreading) and then finally GUI construction. The last two are backwards, but the GUI does me no good if I can't print on Linux. Somewhere in there I hope to pull a big thorn out of my foot by moving various machines to Linux. With a working GUI+printing, the rest of the boxes go to Linux, and the drinks are on me :) Understood about your objectives, but I think they SHOULD include teaching efficient updates. When MS did this correctly, they did the simplest thing that would work, and then separately modified it for efficiency. Smalltalk is not the fastest language in existence, Pharo is not the fastest among its peers, and even if it were, we should be doing things better and more efficiently than the rest of the world. It is nuts that we need 2GB of RAM to boot an OS and read email; while that sloppiness arguably begins in Redmond, it can be attenuated here. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Hilaire Fernandes [hilaire.fernandes(a)gmail.com] Sent: Friday, June 11, 2010 9:46 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] GUI Polymorph Schwab,Wilhelm K a Ã©crit : > Hilaire, > > It was interesting to watch MS' position on GUI examples change over time. > Visual C++ started out teaching how to create efficient software. Then > one day those examples were gone and all they could talk about was "smooth > scrolling" which turned out to be a way to make the machine do the > inefficient thing four times instead of once. > > The idea of altering the model, finding out what is invalidated, marking > that as closely as can be done within bounds of common sense (or until > diminishing returns), and then drawing just the changed parts is > non-intuitive and VERY important. You have done a wonderful job so far, > but optimization deserves attention. Please fell free to search and to document it. As I wrote in my previous email, my objective writing this documentation was not how to efficiently implement a paint canvas. Hilaire _______________________________________________ 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 11, 2010

Re: [Pharo-project] OpenDBX for dbase files

by Facundo Vozzi

Carla, I'll try it. Thanks, Facu On Fri, Jun 11, 2010 at 10:49 AM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > I used xbase for reading dbf. That should work. > But I don't have idea if xbase could be integrated to squeakDBX. > > Cheers! > Carla > On Friday, June 11, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > 2010/6/11 Facundo Vozzi <facundov79(a)gmail.com> > > > > > > Hi at all,can I used openDBX for read dbase (.dbf) files or I need try > with xbase ? > > > > Hi Facundo. Sounds Spanish name (or even Argentinian!!! ;) ) > > > > I don't know if it is possible. I even don't know that dbase is (I had to > googled it) > > > > what is xbase also? > > > > I cc'ed openDBX mailing list and maybe Norbert can help you. > > > > Cheers > > > > Mariano > > > > > > > > regards,Facu > > > > > > _______________________________________________ > > 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 > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542-9999 x108 fvozzi(a)infoil.com.ar

June 11, 2010

Re: [Pharo-project] OpenDBX for dbase files

by Facundo Vozzi

Hi Mariano, yes, Facundo sounds Criollo name (I'm Argentinian). xBase is just I need, I think. I'll try to install on Pharo 1.0. You can see it on http://map.squeak.org/package/ae10a69f-6e8e-49f9-a085-086f31311743. I'm using magma for my model objects but i need interect with dbase files [*] of other databases (ANSES, AFIP, BCRA, voter list, etc). Thanks for answer, Facundo [*] I used dbase III when i was a Clipper 5 programmer....yes yes, I'm more older than you , i Think <http://map.squeak.org/package/ae10a69f-6e8e-49f9-a085-086f31311743> 2010/6/11 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/6/11 Facundo Vozzi <facundov79(a)gmail.com> > > Hi at all, >> can I used openDBX for read dbase (.dbf) files or I need try with xbase ? >> >> > Hi Facundo. Sounds Spanish name (or even Argentinian!!! ;) ) > > I don't know if it is possible. I even don't know that dbase is (I had to > googled it) > > what is xbase also? > > I cc'ed openDBX mailing list and maybe Norbert can help you. > > Cheers > > Mariano > > > regards, >> Facu >> >> >> _______________________________________________ >> 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 > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542-9999 x108 fvozzi(a)infoil.com.ar

June 11, 2010

Re: [Pharo-project] [update 1.1] #11390

by Johan Brichau

Hi Levente, You are right. This is a mistake. We should better adapt client projects. We will remove it again. On 11 Jun 2010, at 16:40, Levente Uzonyi wrote: > On Fri, 11 Jun 2010, Marcus Denker wrote: > >> First update from the Brussels Sprint >> >> 11390 >> ----- >> >> Issue 2516: UTF16TextConverter broken in Pharo 1.1? >> Issue 2530: Morph duplicate failing >> Issue 2469: Debugger simulation problems >> Issue 2532: HashedCollection>>like: is missing > > According to the method comment, #like: was not ment to be sent to dictionaries: > > "Answer an object in the receiver that is equal to anObject, > nil if no such object is found. Relies heavily on hash properties" > > What should happen when #like: is sent to a dictionary: > According to the comment the method should return an object in the receiver or nil. If it's not nil then that should be an association (or any object in case of MethodDictionary, but most likely a CompiledMethod). > The comment also says that the argument of the method has to be equal to the returned object. This means that the argument has the be an association if the dictionary is not a MethodDictionary. > > What's actually happening: > d := Dictionary new > at: #foo put: 1; > at: #bar put: 2; > yourself. > d like: #foo -> 1. "===> nil" "Oops" > d like: #foo. "===> #foo->1" "Oops" > d associationAt: #foo ifAbsent: nil. "===> #foo->1" > > Now with MethodDictionary: > d := Object methodDict. > d like: #yourself. "===> (Object>>#yourself ""a CompiledMethod(489160704)"")" "Oops" > d like: Object >> #yourself. "===> nil" "Oops" > d associationAt: #yourself. "(Object>>#yourself ""a CompiledMethod(489160704)"")" "Oops, it's a bug." > > So I think: > - MethodDictionary >> #associationAt:ifAbsent: should be fixed > - GOODS and Glorp implementations should use #associationAt:ifAbsent: instead of #like: > - Dictionaries shouldn't understand #like: > > > Levente > >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> 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 ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

June 11, 2010

Re: [Pharo-project] GUI Polymorph

by Gary Chambers

Take a look at Morph>>invalidRect: as opposed to #changed for more optimal screen updates if required ;-) Nice job on the tutorial Hilaire btw. Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, June 11, 2010 2:59 PM Subject: Re: [Pharo-project] GUI Polymorph Hilaire, I will indeed consider it, but it will take me time to get to your level of understanding of Polymorph. My priorities are networking, serial communications, printing (which I am dreading) and then finally GUI construction. The last two are backwards, but the GUI does me no good if I can't print on Linux. Somewhere in there I hope to pull a big thorn out of my foot by moving various machines to Linux. With a working GUI+printing, the rest of the boxes go to Linux, and the drinks are on me :) Understood about your objectives, but I think they SHOULD include teaching efficient updates. When MS did this correctly, they did the simplest thing that would work, and then separately modified it for efficiency. Smalltalk is not the fastest language in existence, Pharo is not the fastest among its peers, and even if it were, we should be doing things better and more efficiently than the rest of the world. It is nuts that we need 2GB of RAM to boot an OS and read email; while that sloppiness arguably begins in Redmond, it can be attenuated here. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Hilaire Fernandes [hilaire.fernandes(a)gmail.com] Sent: Friday, June 11, 2010 9:46 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] GUI Polymorph Schwab,Wilhelm K a Ã©crit : > Hilaire, > > It was interesting to watch MS' position on GUI examples change over time. > Visual C++ started out teaching how to create efficient software. Then > one day those examples were gone and all they could talk about was "smooth > scrolling" which turned out to be a way to make the machine do the > inefficient thing four times instead of once. > > The idea of altering the model, finding out what is invalidated, marking > that as closely as can be done within bounds of common sense (or until > diminishing returns), and then drawing just the changed parts is > non-intuitive and VERY important. You have done a wonderful job so far, > but optimization deserves attention. Please fell free to search and to document it. As I wrote in my previous email, my objective writing this documentation was not how to efficiently implement a paint canvas. Hilaire _______________________________________________ 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 11, 2010

Re: [Pharo-project] [update 1.1] #11390

by Levente Uzonyi

On Fri, 11 Jun 2010, Marcus Denker wrote: > First update from the Brussels Sprint > > 11390 > ----- > > Issue 2516: UTF16TextConverter broken in Pharo 1.1? > Issue 2530: Morph duplicate failing > Issue 2469: Debugger simulation problems > Issue 2532: HashedCollection>>like: is missing According to the method comment, #like: was not ment to be sent to dictionaries: "Answer an object in the receiver that is equal to anObject, nil if no such object is found. Relies heavily on hash properties" What should happen when #like: is sent to a dictionary: According to the comment the method should return an object in the receiver or nil. If it's not nil then that should be an association (or any object in case of MethodDictionary, but most likely a CompiledMethod). The comment also says that the argument of the method has to be equal to the returned object. This means that the argument has the be an association if the dictionary is not a MethodDictionary. What's actually happening: d := Dictionary new at: #foo put: 1; at: #bar put: 2; yourself. d like: #foo -> 1. "===> nil" "Oops" d like: #foo. "===> #foo->1" "Oops" d associationAt: #foo ifAbsent: nil. "===> #foo->1" Now with MethodDictionary: d := Object methodDict. d like: #yourself. "===> (Object>>#yourself ""a CompiledMethod(489160704)"")" "Oops" d like: Object >> #yourself. "===> nil" "Oops" d associationAt: #yourself. "(Object>>#yourself ""a CompiledMethod(489160704)"")" "Oops, it's a bug." So I think: - MethodDictionary >> #associationAt:ifAbsent: should be fixed - GOODS and Glorp implementations should use #associationAt:ifAbsent: instead of #like: - Dictionaries shouldn't understand #like: Levente > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 11, 2010