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

Re: [Pharo-project] Issue 3420 in pharo: ReleaseTest>>#testUndeclared is failing

by pharo＠googlecode.com

Comment #1 on issue 3420 by guillermopolito: ReleaseTest>>#testUndeclared is failing http://code.google.com/p/pharo/issues/detail?id=3420 Marcus, what is the hudson build code you are talking about? :)

Jan. 9, 2011

Re: [Pharo-project] Issue 3514 in pharo: Failing Test: NewTextMorphTests.testAcceptContents

by pharo＠googlecode.com

Comment #1 on issue 3514 by guillermopolito: Failing Test: NewTextMorphTests.testAcceptContents http://code.google.com/p/pharo/issues/detail?id=3514 This is because TextEditor>>accept does: accept "Save the current text of the text being edited as the current acceptable version for purposes of canceling. Allow my morph to take appropriate action" morph enableTextChange ifTrue: [morph acceptContents] and morph (a NewTextMorph) dnu #enableTextChange. Does NewTextMorph has the capability of beign enabled or disabled? Shoud it do only morph acceptContents ?

Jan. 9, 2011

Re: [Pharo-project] About preloaded packages

by Tudor Girba

+1 Doru On 8 Jan 2011, at 17:02, StÃ©phane Ducasse wrote: > > On Jan 8, 2011, at 4:42 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> I'm not sure I follow. I think we agree that loading all configurations and running tests is good. > > I meant that the configurations do not have to be loaded in the image. > >> I understand why the web image went away when it took somebody's time time build it, but the Hudson server can do that work now. It seems reasonable to leave a range of targets that might be of value to people. > > yes now somebody should maintain the configuration and fix conflict. > >> There could be a few likely useful targets (minimal, dev, web) and then one with absolutely everything that is mostly for testing. But if somebody wants to use that, why not leave it on the server so they can get it? > > because who maintains if there is a bug due to a conflict. > Building the seaside image took lukas time and effort. I'm learned that things do not magically work. > So if somebody stands up and say ok I'm responsible for the imageXZK why not and we can set up hudson to build it. > Now we (the core minimal team) should spend time on getting the infrastructure right on tracks because this is an enabler of the future. > >> >> 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, January 08, 2011 10:30 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] About preloaded packages >> >>> It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems. >> >> Not loaded :) >> Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server. >> > > -- www.tudorgirba.com "Obvious things are difficult to teach."

Jan. 8, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by Nicolas Cellier

2011/1/8 Stephan Eggermont <stephan(a)stack.nl>: > Nicolas wrote: >>Then group the selectors (first, first: etc..), explain that they are >>extensions, and don't need a copy prefix, because anyway most messages >>will do a copy. > > You are aware first doesn't copy, do you? The explanation should be > that you always have to take a look at the implementation to see if it copies > or not (or sometimes), and explain when it doesn't matter (small integers, characters). > > Stephan > > You mean something like: | collec | collec := #('foo' 'bar'). shallowCopy := collec copy. self assert: collec first == shallowCopy first Well, yes those copies are shallow, but what's the difference between copy, copyFrom:to: first, first: etc... with this respect ? Nicolas

Jan. 8, 2011

[Pharo-project] cog 2343 fails smoke test on linux

by Matthew Fulmer

On Fri, Jan 07, 2011 at 06:15:52PM -0800, Eliot Miranda wrote: > Hi All, > > find new VMs in > VM.r2342/<http://www.mirandabanda.org/files/Cog/VM/VM.r2342/> > (SimpleStackBasedCogit) > and VM.r2343/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2343/> ( > StackToRegisterMappingCogit). 2343 seems fine but I appear to have > introduced a regression into 2342. The 2343 VMs fix both of the bugs > mentioned by Matthew and Yoshiki: > > As usual I'm very grateful for you pounding on these (ok, at least the 2343 > VM :) ). Erm, at least on my ubuntu linux box, 2343 won't even launch the trunk image without segfaulting on startup: http://ftp.squeak.org/4.2/Squeak4.2-10856-beta.zip --------------------------------------------------- ./cog.r2343/bin/i686-pc-linux-gnu/squeak Squeak4.2-10856-beta.image Segmentation fault Smalltalk stack dump: 0xbfe28ba0 M IdentityDictionary>scanFor: 2009736128: a(n) IdentityDictionary 0xbfe28bc8 M IdentityDictionary(Dictionary)>at:ifAbsent: 2009736128: a(n) IdentityDictionary 0xbfe28bf0 I Preferences class>preferenceAt:ifAbsent: 2010414284: a(n) Preferences class 0xbfe28c18 I Preferences class>valueOfPreference:ifAbsent: 2010414284: a(n) Preferences class 0xbfe28c40 I Preferences class>valueOfFlag:ifAbsent: 2010414284: a(n) Preferences class 0xbfe28c68 I Preferences class>swapMouseButtons 2010414284: a(n) Preferences class 0xbfe28c88 I InputSensor class>installMouseDecodeTable 2010135976: a(n) InputSensor class 0xbfe28ca8 I InputSensor class>startUp 2010135976: a(n) InputSensor class 0xbfe28cc0 M InputSensor class(Behavior)>startUp: 2010135976: a(n) InputSensor class 0xbfe28cec M [] in SmalltalkImage>send:toClassesNamedIn:with: 2011753028: a(n) SmalltalkImage 0xbfe28d14 I OrderedCollection>do: 2011782444: a(n) OrderedCollection 0xbfe28d3c I SmalltalkImage>send:toClassesNamedIn:with: 2011753028: a(n) SmalltalkImage 0xbfe28d68 I SmalltalkImage>processStartUpList: 2011753028: a(n) SmalltalkImage 0xbfe28d94 I SmalltalkImage>snapshot:andQuit:embedded: 2011753028: a(n) SmalltalkImage 2019217856 s SmalltalkImage>snapshot:andQuit: 2019217524 s SmalltalkImage>saveImageInFileNamed: 2019217432 s SmalltalkImage>saveAs: 2019193036 s SmalltalkImage>saveAs 2019192920 s TheWorldMenu>doMenuItem:with: 2019192828 s [] in MenuItemMorph>invokeWithEvent: 2019192712 s BlockClosure>ensure: 2019192620 s CursorWithMask(Cursor)>showWhile: 2019192528 s MenuItemMorph>invokeWithEvent: 2019192436 s MenuMorph 2019192344 s [] in MenuMorph>keyStroke: 2019192252 s [] in Array(Collection)>detect:ifNone: 2019192088 s Array(SequenceableCollection)>do: 2019191996 s Array(Collection)>detect:ifNone: 2019191864 s MenuMorph>keyStroke: 2019191772 s MenuMorph(Morph)>handleKeystroke: 2019191680 s KeyboardEvent>sentTo: 2019191588 s MenuMorph(Morph)>handleEvent: 2019191496 s MorphicEventDispatcher>dispatchDefault:with: 2019191388 s MorphicEventDispatcher>dispatchEvent:with: 2019191256 s MenuMorph(Morph)>processEvent:using: 2019191164 s MenuMorph(Morph)>processEvent: 2019191072 s MenuMorph>handleFocusEvent: 2019190980 s [] in HandMorph>sendFocusEvent:to:clear: 2019190888 s [] in PasteUpMorph>becomeActiveDuring: 2019190708 s BlockClosure>on:do: 2019190588 s PasteUpMorph>becomeActiveDuring: 2019190496 s HandMorph>sendFocusEvent:to:clear: 2019190404 s HandMorph>sendEvent:focus:clear: 2019190272 s HandMorph>sendKeyboardEvent: 2019190180 s HandMorph>handleEvent: 2019190016 s HandMorph>processEvents 2019189900 s [] in WorldState>doOneCycleNowFor: 2019189808 s Array(SequenceableCollection)>do: 2019189708 s WorldState>handsDo: 2019189616 s WorldState>doOneCycleNowFor: 2019189524 s WorldState>doOneCycleFor: 2019189432 s PasteUpMorph>doOneCycle 2013075760 s [] in Project class>? 2013075628 s [] in BlockClosure>newProcess Most recent primitives basicNew size at: basicNew: decompress:fromByteArray:at: beCursorWithMask: vmParameterAt:put: vmParameterAt:put: ensure: valueNoContextSwitch wait specialObjectsArray new: at:put: signal basicNew new: at: identityHash stringHash:initialHash: perform:with: millisecondClockValue signal identityHash stringHash:initialHash: size \\ at: at: perform:with: actualScreenSize species species supportsDisplayDepth: basicNew: basicNew beDisplay stringHash:initialHash: size \\ size \\ = perform:with: beCursorWithMask: stringHash:initialHash: = perform:with: zsh: abort ./cog.r2343/bin/i686-pc-linux-gnu/squeak Squeak4.2-10856-beta.image -- Matthew Fulmer (a.k.a. Tapple)

Jan. 8, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by Stephan Eggermont

Nicolas wrote: >Then group the selectors (first, first: etc..), explain that they are >extensions, and don't need a copy prefix, because anyway most messages >will do a copy. You are aware first doesn't copy, do you? The explanation should be that you always have to take a look at the implementation to see if it copies or not (or sometimes), and explain when it doesn't matter (small integers, characters). Stephan

Jan. 8, 2011

Re: [Pharo-project] TODO 1.2

by Mariano Martinez Peck

Thanks Marcus for the summary. We need people to help on this! mariano On Fri, Jan 7, 2011 at 3:04 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 1) Core: > > - Failing Tests: 8 > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastCompleted… > - Open Bug Tracker entries: 15 > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2 > > > 2) Full: > - Failing tests: 8 + 11 > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastCompletedBuild/t… > - Open Bug Tracker entries: 13 > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Jan. 8, 2011

Re: [Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?

by Igor Stasenko

On 7 January 2011 20:07, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > I was in meeting all day, hence the late reply. > > On 07 Jan 2011, at 14:08, StÃ©phane Ducasse wrote: > >> Sven >> >> two questions: >> Â Â Â - if we want to use zn for pharo to replace HTTPSocket, don't you think that Zinc-HTTP-Client-Server should be split into pieces. > > I don't think that would make a lot of sense: HTTP is a client-server protocol, the client and server sides have a lot in common; a split in three pieces would be possible but each piece would be rather small. Having the necessary pieces for a simple HTTP server present will lower the bar for others, so that makes sense too. (For example, the Seaside adaptor is really very little code, no more need for Kom unless you really want it). > >> Â Â Â - do you think that some parts of zinc could be reused to implement other protocols such as POP, SMTP, IMAP? > > Maybe, finding shared code can only be done by doing both implementations I'm afraid ;-) > > Another, related point is the following: maybe you noticed browsing the code that I have a number of classes in Zn that redo some standard functionality (ZnMimeType, ZnUrl, ZnCharacterEncoder, and some of the code in the utils classes), a bit like Seaside does. The reason is that the existing classes were broken beyond repair (IMHO), or that I was not confortable extending them. Now, if the existing classes could be improved/replaced, it would make sense to replace the Zn variant with a good system wide one. This is a search for the best solution. > well it would be good to have these classes fixed, and make zinc using them. because these ones are needed thoughout entire system, and certainty, for things like mime-type , there could be code which can handle certain type(s), but know nothing about Zinc. > Sven > -- Best regards, Igor Stasenko AKA sig.

Jan. 8, 2011

Re: [Pharo-project] Basic rules of life in this team!

by StÃ©phane Ducasse

sorry this mail was for our team at lille. Stef On Jan 8, 2011, at 5:13 PM, StÃ©phane Ducasse wrote: > May be this is time to resend this email... sadly. > > >> Hi guys >> >> apparently gwenael is reading this mailing-list and you too, so could you tell >> him that I would appreciate that he replies (not only by email but this is a first step but) by actions >> to my mails, if they are of any values of course. Sorry but I'm mad that I have to write this kind of mail. >> >> Just a point for everybody: >> My door is **always** open and you can drop by and say hello I'm here and I'm doing that >> when you are back from holidays or when you want. >> Saying hello is the first level of communication. >> >> Second I'm *really* busy BUT YOU are always *more* important that my business so >> you can always interrupt me. >> >> Third, since you do not really know what is to work on several (too many) things at the same >> time, focus on your PhD AND push information to me since I'm constantly rescheduling my >> tasks list. Pulling information KILLS me and I do not like that. >> >> Fourth, realize that you are payed more than people at EMD for example mariano. >> >> Again again again no communication hurts me and I do not like that. > >> I hate that you do not communicate with me since it makes me losing more time!!!!! >> Now again don't get me really mad because I'm a butcher in such case. If this is you or me, this will be you. >> >> Sad but it seems that I already said that, so may be this is the occasion to learn. >> Now I'm sure that if you do not learn life will make it and it will be a pain one day or another. >> >> Stef > >

Jan. 8, 2011

Re: [Pharo-project] [squeak-dev] Announcements in core images?

by StÃ©phane Ducasse

On Jan 8, 2011, at 5:16 PM, Mariano Martinez Peck wrote: > > > 2011/1/7 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Hi both Squeakers and Pharoers, > > What is a status of Announcements package as part of core images? Are > they already there and, are they compatible, and if not, what are the > differences? > > Hi Janko. I don't know anything about announcments, but I can tell you they are integrated in pharo core, and its tests are green. > I don't know if they are being used by the core itself but I think there are external packages that use them. They start and we will migrate to them. > > > > Announcements are namely very important and elegant way of event > notifications based on publish/subscribe pattern. And they are portable, > which is very important for us, doing cross platform frameworks like > Aida, Seaside, etc. > > Therefore I'd really like to see Announcements included in all > Smalltalks by default and at least on API level as same as possible. > > Best regards > Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > >

Jan. 8, 2011