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

Re: [Pharo-project] Bug or feature? XMLElement>>allElementsDo:

by Damien Cassou

On Mon, Aug 29, 2011 at 10:25 PM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr> wrote: > Should I remove this? it looks like that if you remove "aBlock value: self", aBlock will never get executed. The question is now "does the name #allElementsDo: makes sense with this behavior?" I don't think so. One way to fix it is to move "aBlock value: self" to XMLNodeWithElements>>allElementsDo: -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 30, 2011

Re: [Pharo-project] Bug or feature? XMLElement>>allElementsDo:

by Tudor Girba

Indeed, it should be named withAllElementsDo: to be consistent with Smalltalk naming, and then it would exactly what the name says :) Doru On 30 Aug 2011, at 07:51, Max Leske wrote: > â¦ and maybe it should be renamed to #withAllElementsDo: ? > > > On 30.08.2011, at 00:01, Levente Uzonyi wrote: > >> On Mon, 29 Aug 2011, Nicolas Anquetil wrote: >> >>> In XML-Parser-Nodes we have: >>> >>> XMLNodeWithElements >>> XMLDocument >>> XMLElement >>> >>> A document is composed of elements that can hold recursively other elements >>> >>> XMLNodeWithElements implements (in protocol enumerating) >>> allElementsDo: aBlock >>> "Descend depth-first visiting each element with aBlock." >>> >>> self hasElements >>> ifTrue: [self elementsDo: [:each | each allElementsDo: aBlock]] >>> >>> Looks perfectly normal to me >>> But then: >>> >>> XMLElement implements (in protocol searching !) >>> allElementsDo: aBlock >>> "See superclass version." >>> >>> aBlock value: self. >>> >>> super allElementsDo: aBlock. >>> >>> which means that >>> anXMLElement allElementsDo: [...] >>> runs first on itself and then on its elements ?!? >>> Seems counter intuitive to me. >>> >>> Should I remove this? >> >> IMHO you shouldn't, because it is enumerating the whole tree, which is exactly what I'd expect from this method. But the method should be recategorized. >> >> >> Levente >> >>> >>> nicolas >>> >>> >> > > -- www.tudorgirba.com "Live like you mean it."

Aug. 30, 2011

[Pharo-project] Pharo 1.3 release

by laurent laffont

Hi, maybe I haven't read correctly the mailing-list but I still don't know if Pharo 1.3 is released or not, cannot find any official announcement, release date .... The website is misleading, I can help on this, but need to be sure. I've also prepared a french announcement but needs to be up to date before. Cheers, Laurent Laffont

Aug. 30, 2011

Re: [Pharo-project] Bug or feature? XMLElement>>allElementsDo:

by Max Leske

â¦ and maybe it should be renamed to #withAllElementsDo: ? On 30.08.2011, at 00:01, Levente Uzonyi wrote: > On Mon, 29 Aug 2011, Nicolas Anquetil wrote: > >> In XML-Parser-Nodes we have: >> >> XMLNodeWithElements >> XMLDocument >> XMLElement >> >> A document is composed of elements that can hold recursively other elements >> >> XMLNodeWithElements implements (in protocol enumerating) >> allElementsDo: aBlock >> "Descend depth-first visiting each element with aBlock." >> >> self hasElements >> ifTrue: [self elementsDo: [:each | each allElementsDo: aBlock]] >> >> Looks perfectly normal to me >> But then: >> >> XMLElement implements (in protocol searching !) >> allElementsDo: aBlock >> "See superclass version." >> >> aBlock value: self. >> >> super allElementsDo: aBlock. >> >> which means that >> anXMLElement allElementsDo: [...] >> runs first on itself and then on its elements ?!? >> Seems counter intuitive to me. >> >> Should I remove this? > > IMHO you shouldn't, because it is enumerating the whole tree, which is exactly what I'd expect from this method. But the method should be recategorized. > > > Levente > >> >> nicolas >> >> >

Aug. 30, 2011

[Pharo-project] Got network sockets working in Android Cog

by Dimitry Golubovsky

Hi, I got network sockets to work in my Android port of CogVM with PharoCore-13137 image. I made changes to the logic of aioPoll so that it just checks on all handles once and returns if no I/O operations are ready without any looping, otherwise calls all relevant I/O handlers and returns. aioPoll is called as part of ioProcessEvents. I am able to open Monticello repos, download packages, merge, see diffs etc. Socket tests mostly succeeded, 2 failed. One for https (I did not investigate yet how to use SSL in Android NDK, so no surprise it does not work); another is NetNameResolverTest>>testLocalHostName (also failed on PC as I just checked so there is something non-related to Android). I am trying to run the "Software update" item on Pharo. It seems to progress, but very slowly (partly because Squeaksource is very slow from the US). Not sure how long it may take, but I'll try to get it to complete ;) Anyway, this is another step towards release. I have currently these plugins compiled in: BitBltSimulation "BitBltPlugin" BalloonEnginePlugin "B2DPlugin" FileCopyPlugin FilePlugin FloatArrayPlugin FloatMathPlugin JoystickTabletPlugin JPEGReaderPlugin RePlugin SecurityPlugin JPEGReadWriter2Plugin SocketPlugin MiscPrimitivePlugin DeflatePlugin "ZipPlugin" The plugin choice was mostly arbitrary, beyond those really necessary (Balloon Engine, Socket, etc.) What other plugins are worth adding and testing before I start preparing for the release? Thanks. -- Dimitry Golubovsky Anywhere on the Web

Aug. 30, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Igor Stasenko

On 30 August 2011 02:58, Douglas Brebner <squeaklists(a)fang.demon.co.uk> wrote: > On 29/08/2011 21:41, StÃ©phane Ducasse wrote: >> >> So may be you do not like Ring and this is ok. >> Now I want an abstraction so that we can build a remote browser by >> plugging simply rTalk + nautilus + ring. >> With the current state of the system this was simply impossible. >> >> I want to be able to browse senders in the past and compare them with the >> current version. Because we use >> prehistorical tools even if we could have something like torch to help us. >> >> I cannot see anymore SystemChangeNotifier (even if this was far better >> than without) >> PackageInfo, PackageOrganizer with lazy identification of packages >> so that when you do an analysis you have to ask sometimes twice to >> packageOrganiser and packageInfo. Ask cyrille the time he spent there. >> >> I want one good browser, one code model (to be used by all the tools), one >> system notifier and a good one. >> One AST. >> > > If I may make a metaphor, it sounds like rebuilding a house from the > foundations on up while you're living in it. Things are bound to get > unpleasant while it's happening, but it's still worth it in the end. :) > Yes.. I agree with Stef. Compatibility (including backward's one) is good to have when it worth it. But keeping compatibility with crap (okay, okay lets call it poorly designed software)? Why? Of course we can focus our energy somewhere else.. But then i think it will be not making Pharo, but more making things on top of it. Still there's a lot to do in Pharo. Maybe for Lukas it is unclear.. i'm not sure. But we are agree in one thing: we want to fix stuff even if its not broken , because the way it works is against laws of logic, software engineering, common sense etc.. And i can remind everyone: nobody forcing people to use latest stuff. I know that commercial applications are at least 1 year behind the current version. That's the way it works and not only for Pharo, but for most other software in the world. And there is nothing bad with it. Personally, if i would be involved in commercial project, i would just pick one version of image and stick with it to the death. Because often there's much more to care about inside a project itself (development, support etc), and you usually having deadlines.. so trying to cope up with latest and greates stuff at the same rate as it appears would be just silly and waste of energy. -- Best regards, Igor Stasenko AKA sig.

Aug. 30, 2011

Re: [Pharo-project] Squeaksource.com (was: [squeak-dev] Re: Addition to "About Pharo" dialog)

by Tobias Pape

Am 2011-08-29 um 08:18 schrieb Alexander LazareviÄ: > 2011/8/27 Bert Freudenberg <bert(a)freudenbergs.de> > The Chile mirror is up. > > Just learned about that one. Thanks! > > While it seems more stable indeed, it also gets much less traffic. I'n not sure it would handle the load of squeaksource.com as well. > > Ok, but spreading the workload on to more than one SqueakSource server by moving selected projects from squeaksource.com as an interims solution could ease the pain, no? > > So far we have not opened up source.squeak.org for personal projects. > > Hah. Typical Plan B characteristics! ;) > > That would be a good idea IMHO - you might ask what the other VM developers think of the idea on the vm-dev list. > > I will forward it to the vm-dev list. >> I think the broken SqueakSource is hurting us more than we know! > We discussed this at ESUG and so far the most promising plan is to migrate squeaksource.com to a SqueakSource3 instance running on Gemstone. Tobias should be able to tell us more. > > Is there a project page besides the actual beta repo installation? What do you mean by project page? We have an issuetracker at squeaksource3.googlecode.com and the regular sources at http://www.squeaksource.com/squeaksource3.html and http://seaside.gemstone.com/ss/squeaksource3.html Best -Tobias

Aug. 30, 2011

Re: [Pharo-project] Omnibrowser in 1.4

by Douglas Brebner

On 29/08/2011 21:41, StÃ©phane Ducasse wrote: > So may be you do not like Ring and this is ok. > Now I want an abstraction so that we can build a remote browser by plugging simply rTalk + nautilus + ring. > With the current state of the system this was simply impossible. > > I want to be able to browse senders in the past and compare them with the current version. Because we use > prehistorical tools even if we could have something like torch to help us. > > I cannot see anymore SystemChangeNotifier (even if this was far better than without) > PackageInfo, PackageOrganizer with lazy identification of packages > so that when you do an analysis you have to ask sometimes twice to packageOrganiser and packageInfo. Ask cyrille the time he spent there. > > I want one good browser, one code model (to be used by all the tools), one system notifier and a good one. > One AST. > If I may make a metaphor, it sounds like rebuilding a house from the foundations on up while you're living in it. Things are bound to get unpleasant while it's happening, but it's still worth it in the end. :)

Aug. 29, 2011

Re: [Pharo-project] Deprecation policy

by Sean P. DeNigris

Also the date formats are inconsistent e.g. '8/29/2011' vs. '29 August, 2011'. Does it matter? -- View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777671.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011

Re: [Pharo-project] Deprecation policy

by Sean P. DeNigris

Are pre-1.3 deprecated methods purposely put into protocol *deprecated13? For example: String>>asDefaultDecodedString on: 2/13/2010 in: 1.1 PluggableTextMorph>>setTextColor: on: 8/17/2010 in: 1.2 SequencableCollection>>sortBy: on: 9/4/2010 in: 1.2 SystemDictionary>>hasSpecialSelector:ifTrueSetByte: on: 3/20/2010 in: 1.1 -- View this message in context: http://forum.world.st/Deprecation-policy-tp3777647p3777660.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2011