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

Re: [Pharo-project] Alternative implementation for Cursor>>show:

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=1814 > I don't know what you are talking about. > > > > Yes, this seems reasonable, as we should delete all references to Cursor. > > > > Do you agree with this ? If true we need to create an issue and commit :) > > > > Cheers > > > > Mariano > > > > On Sat, Jan 23, 2010 at 12:28 PM, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > > Hi, i think this send to Sensor could be avoided by replacing the Cursor>>show: method with > > > > Cursor>>show > > self class currentCursor: self. > > > > > > > > > > Instead of a: > > > > Cursor>>show > > "Make the hardware's mouse cursor look like the receiver" > > > > Sensor currentCursor: self > > > > > > InputSensor>>currentCursor: newCursor > > "The current cursor is maintained in class Cursor." > > > > Cursor currentCursor: newCursor. > > _______________________________________________ > > 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

Feb. 9, 2010

Re: [Pharo-project] [Pharo-users] Pharo screencasts - how to

by GermÃ¡n Arduino

2010/2/8 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Mon, Feb 8, 2010 at 10:20 PM, laurent laffont <laurent.laffont(a)gmail.com> > wrote: >> >> Hi, >> I want to share how I record screencasts for Pharocasts >> http://pharocasts.blogspot.com/ in case someone wants to participate. Now >> there's 11 screencasts. The difficult part is to have> a good idea / >> scenario for a screencast. Comments and ideas are welcome. >> > > Thanks for this notes!! > Thanks also for my part!! Very useful! ================================================= GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com =================================================

Feb. 9, 2010

Re: [Pharo-project] broken polymorph example in 1.1?

by StÃ©phane Ducasse

thanks for spotting that. Doing is more difficult than doing nothing :( Stef On Feb 9, 2010, at 9:40 AM, Henrik Johansen wrote: > I couldn't help noticing there are also a few Undefined entries > resulting from the Squeak-ToolBuilder merge, should also be looked into :) > > Cheers, > Henry > > Den 09.02.2010 08:22, skrev StÃ©phane Ducasse: >> Really may be one of my mistakes. >> >> stef >> >> On Feb 8, 2010, at 12:30 PM, Gary Chambers wrote: >> >> >>> Looks like PluggableDialogWindow has had its superclass changed (was >>> DialogWindow)... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Hilaire Fernandes" <hilaire(a)ofset.org> >>> To: <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Saturday, February 06, 2010 5:04 PM >>> Subject: [Pharo-project] broken polymorph example in 1.1? >>> >>> >>> >>>> Is it me or examples of the Polymorph usage are broken? >>>> >>>> For example exampleOtherControls break >>>> >>>> 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 >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 9, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Lukas Renggli

>>> Â It has only one sender. >> >> Yes, in the core ;)Â Â But the problem is that Seaside (I think only 2.8.4 >> as 3.0 seems to fixed that) or KomHttpServer are still using it. Seaside 2.7 uses #fixTemps. Seaside 2.8 and 3.0 should use #fixCallbackTemps, which is a Seaside specific implementation of #fixTemps. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 9, 2010

Re: [Pharo-project] something in 1.1 broke ImageSegment

by Levente Uzonyi

On Tue, 9 Feb 2010, Henrik Johansen wrote: > > > Den 09.02.2010 06:14, skrev Levente Uzonyi: >> On Mon, 8 Feb 2010, Henrik Sperre Johansen wrote: >> >> >>> I believe its due to stream positioning when crossing buffer boundries in >>> basicChunk, I have to debug a bit further for a solution though, sorry... >>> >> It seems to be an easy one, though I didn't try the fix, just reviewed >> the code. So the cause of the issue is in MultiByteFileStream >> >> #basicChunk, which doesn't care about readLimit. When readLimit is less >> than "collection size", the end of the returned chunk may be the end of a >> previous chunk. >> > Thanks Levente, in my original-author-blindness, I couldn't see past > that position was apparently set wrong compared to the original > approach. When you say it like that, it's obvious :) >> This method has at least two other flaws (These probably won't hurt >> anyone in the near future, though both can be avoided): >> 1. if read buffering is disabled it will raise an error >> > Yes, this should be fixed. I assume a collection ifNil: [^nil] is enough? Yes. >> 2. it assumes that the encoding of the stream is ascii compatible >> >> > Yes, that was a tradeoff. (Which I hoped was a clear implication from > the method comment) > Only Converter with this characteristic currently existing (afaict) is > QuotedPrintable, I doubt that or another format will ever be used for > storage of code. This method fails if the encoding is utf16 (which is unlikely), since ! is encoded as 00 21 (in hex) so !! will be 00 21 00 21. #basicChunk will recognize these as two chunk endings instead of an escaped chunk terminator. > The method you wrote in Squeak doesn't have this limitiation, on the > other hand that does little for encodings other than utf8 (which, of > course, could be successfully argued to be the important case). Currently two encodings are used for fileIn/Out: utf8 and macroman, these are both ascii compatible. Macroman is only supported for reading, writing is always done as utf8. Other encodings' performance can be easily enhanced in Squeak if necessary (but that's very unlikely). > This way, you also avoid a Stream creation/String copy in the common This could be added to Squeak, but I found that it doesn't make much (measureable) difference. Levente > case, as well as not let encodings in addition to streams contain > special logic to read in code chunks. >> Levente >> >> > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 9, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Eliot Miranda

2010/2/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/2/9 Luc Fabresse <luc.fabresse(a)gmail.com> > > Hi all, >> >> I wonder why BlockContext>>fixTemps is still in PharoCore. >> I guess that it should be removed, isn't it? >> > > I would like to remove them. > > >> It has only one sender. >> > > Yes, in the core ;) But the problem is that Seaside (I think only 2.8.4 > as 3.0 seems to fixed that) or KomHttpServer are still using it. > > Of course, we can just remove it and assume that those external packages > should be fixed to run on Pharo. Squeak trunk also has closures...so.. > > >> Morever, should the BlockContext class be removed too? >> > > I would like, too. The only problem is the "compatibility". What maybe can > be done is to remove the class but do something like > > Smalltalk at: #BlockContext put: #BlockClosure > I think this is a really bad idea. Imagine loading something that adds functionality to BlockContext that simply makes no sense in BlockClosure or breaks when compiled on BlockClosure. Best live with the differences and upgrade than introduce a horrible hack that pretends to do backwards-compatibility but actually confuses the hell out of people. HTH > > But I have no idea the impact of this.... > which is one really good reason /not/ to do it :) best Eliot > > >> >> Depending on answers, I will write a bug report. >> >> Luc >> >> _______________________________________________ >> 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 >

Feb. 9, 2010

[Pharo-project] Diff tools

by GARY CHAMBERS

New version on SqueakSource Polymorph-Tools-Diff-gvc.20. Descriptions added and small bug fix for merge tool (selecting next conflict now ignores "resolved" conflicts). Merge and select incoming for each conflict to load. Regards, Gary

Feb. 9, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Mariano Martinez Peck

mmmm I found this old issue: http://code.google.com/p/pharo/issues/detail?id=1058 On Tue, Feb 9, 2010 at 2:03 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > 2010/2/9 Luc Fabresse <luc.fabresse(a)gmail.com> > > Hi all, >> >> I wonder why BlockContext>>fixTemps is still in PharoCore. >> I guess that it should be removed, isn't it? >> > > I would like to remove them. > > >> It has only one sender. >> > > Yes, in the core ;) But the problem is that Seaside (I think only 2.8.4 > as 3.0 seems to fixed that) or KomHttpServer are still using it. > > Of course, we can just remove it and assume that those external packages > should be fixed to run on Pharo. Squeak trunk also has closures...so.. > > >> Morever, should the BlockContext class be removed too? >> > > I would like, too. The only problem is the "compatibility". What maybe can > be done is to remove the class but do something like > > Smalltalk at: #BlockContext put: #BlockClosure > > But I have no idea the impact of this.... > > >> >> Depending on answers, I will write a bug report. >> >> Luc >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Feb. 9, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Mariano Martinez Peck

2010/2/9 Luc Fabresse <luc.fabresse(a)gmail.com> > Hi all, > > I wonder why BlockContext>>fixTemps is still in PharoCore. > I guess that it should be removed, isn't it? > I would like to remove them. > It has only one sender. > Yes, in the core ;) But the problem is that Seaside (I think only 2.8.4 as 3.0 seems to fixed that) or KomHttpServer are still using it. Of course, we can just remove it and assume that those external packages should be fixed to run on Pharo. Squeak trunk also has closures...so.. > Morever, should the BlockContext class be removed too? > I would like, too. The only problem is the "compatibility". What maybe can be done is to remove the class but do something like Smalltalk at: #BlockContext put: #BlockClosure But I have no idea the impact of this.... > > Depending on answers, I will write a bug report. > > Luc > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 9, 2010

Re: [Pharo-project] fixTemps and BlockContext question

by Adrian Lienhard

True, that is not needed anymore. The normal procedure is to first deprecate the method and later remove it. There are certainly many clients (e.g., from Seaside apps) that send the message and first need to be adapted. So, yes, please create a report and post a patch. Thanks, Adrian On Feb 9, 2010, at 13:54 , Luc Fabresse wrote: > Hi all, > > I wonder why BlockContext>>fixTemps is still in PharoCore. > I guess that it should be removed, isn't it? > It has only one sender. > > Morever, should the BlockContext class be removed too? > > Depending on answers, I will write a bug report. > > Luc > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 9, 2010