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

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 1 regressions found. Zinc.Tests.ZnClientTests.testGetLargeWideStringHTML

Aug. 28, 2013

Re: [Pharo-dev] Debugger recursion

by jan.struz

Hi all, I have a solution for the recursion in Pharo 2.0. (For those subclassing ProtoObject, of course :-) ) If the subclass of ProtoObject implements #class, then the Debugger is happy (will open a debugger). #class is the first message sent by Debugger, to continue with full debugger & deeper inspecting the instance, one have to implement the rest - #isMemberOf: #isKindOf: #inspectorClass #printStringLimitedTo: #longPrintOn:limitedTo:indent: #defaultLabelForInspector #longPrintStringLimitedTo: (minimal set) All of these messages pops up in debugger as MNU, and I am able to debug it. (I hope this will be useful for someone...) In the latest Pharo 3.0 (30351), implementing the first message (here it is #printStringLimitedTo:) is not enough, I have to implement another methods (ex. #inspector) and in addition #basicSize and #-> (in short, all of them, needed by debugger). Without that, I am not able to debug it. The good thing in Pharo3 is, that the image is responding, and I can see what is happening in ProcessBrowser and so, without interrupting. Mariano, the Ghost proxies are really great, only I think the logging should be optional and turned off by default. So it could be referenced by another project and ready to use. It's interesting to see the (no)difference between the debuggingMessages in Ghost, and these needed for ProtoObject subclass... :-) Igor, you are right, the possibility to break something is not a bug, indeed :-) I know. ----- Save The World! -- View this message in context: http://forum.world.st/Debugger-recursion-tp4704703p4705487.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2013

[update 3.0] #30354

by Marcus Denker

30354 ----- 11478 Critics Browser cannot run anymore https://pharo.fogbugz.com/f/cases/11478 11489 fix for #subclassDefinerClass https://pharo.fogbugz.com/f/cases/11489 11486 add method parse: to Compiler and OpalCompiler https://pharo.fogbugz.com/f/cases/11486 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1225.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/OpalCompiler-Core-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Manifest-CriticBrowser-Marcus… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Compiler-MarcusDenker.518.diff

Aug. 28, 2013

Re: [Pharo-dev] Can we stop these "[regression reporter]regression occurred" messages?

by Sven Van Caekenberghe

On 28 Aug 2013, at 15:46, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Which is more important than many useless discussions I have seen on this mailinglist. ;-)

Aug. 28, 2013

Re: [Pharo-dev] Recent VM for Pharo 2 on Ubuntu 8.04

by Sven Van Caekenberghe

On 28 Aug 2013, at 15:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Indeed I do not see how we could provide support that oracle does not. > We should be realistic. I know our resources are limited, but some arguments in this discussion are just wrong. It might at the moment not be possible to run the latest JVM on Ubuntu 8.04, but it is still possible to run Java on such older systems, many VM's that came after the inception date of 8.04. For example. we run java 7 (2011) on ubuntu 8.04 (2008) On the other hand, Pharo 2.0 was released with support for 8.04 AFAIK and now, after minor updates, it no longer works. That is completely different, IMHO. And AFAICT newer images require newer, pharo specific VM's, so using the older release VM's doesn't seem to work. But unless someone says, 'here take this vm', I don't require support, I will work around it, it is just frustrating. >>>> for older systems, you are by your own. Is like that, yes. >>>> >>>> We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old. >>>> >>>> Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html >>>> (latest is 10.04... which we support, or intent to at least) >>>> Also... we are not oracle, we have more limited resources. >>>> >>>> So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions. >>>> >>> >>> This is not the only instance of the problem. >>> If I'm not much mistaken, same problem has been recently reported for Debian 7 >>> (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system. >> >> in that moment answer was: compile it yourself until we provide a working version (which we now provide). >> Ubuntu 8 is another problem :( >> but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :( >> >> >>> >>> To make me clear, I have no problem if you say "Sorry, we don't support >>> anything older than 12 months. Or 3 years. Or ...". I just don't think >>> that asking people to recompile whenever there is glibc dependency problem is "real solution". >>> >>> I'm very sorry for starting this pointless discussion. >>> >>>> >>>>> >>>>>> we can offer support (but should be pretty straight forward, specially in linux systems). >>>>>> >>>>>> I disagree with the solution proposed in (2), the cost of maintaining such approach would be exponential. >>>>> >>>>> No, not really. There aren't many of those (at least, weren't in my case) and I found out that sometimes I could do better (faster) job :-) >>>> >>>> you are invited to provide your working version, it would be cool for everybody :) >>>> >>> >>> Unfortunately, I've done it for a different VM :-) >>> >>> >>> Best, Jan >>> >> >> > >

Aug. 28, 2013

Re: [Pharo-dev] Can we stop these "[regression reporter]regression occurred" messages?

by Camillo Bruni

Dude, this is Continuous Integration, You are not interested if something doesn't work in Pharo? Because if you get one of these mails it means something has been broken! Which is more important than many useless discussions I have seen on this mailinglist. On 2013-08-28, at 15:36, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > Noticed a large number of regression reporter messages filling up the mailing > list, surely there is a better way than to spam the mailing list no?

Aug. 28, 2013

Re: [Pharo-dev] Recent VM for Pharo 2 on Ubuntu 8.04

by Marcus Denker

On Aug 28, 2013, at 3:36 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Indeed I do not see how we could provide support that oracle does not. > We should be realistic. > This quote is related to FireFox and Apple, but it's the same idea: âApple releases new versions of its operating systems relatively quickly, and each new version contains significant changes that we must adapt to,â Aas said. âThis requires resources, and with limited resources this sometimes means we have to make tough decisions about where to invest.â http://www.macworld.com/article/1168241/mozilla_sets_end_of_firefox_for_os_… Mozilla had "limited" resources (revenue, but revenue is resource in software) of over 163 million USD in 2011â¦ Marcus

Aug. 28, 2013

Re: [Pharo-dev] a weak on:do:/when:do:

by StÃ©phane Ducasse

The mail was more that I would prefer to have less block inside block and cull: On Aug 28, 2013, at 1:14 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > That is what I knew, too. I asked because the mail seemed to suggest that it would work :). > > Doru > > > On Wed, Aug 28, 2013 at 12:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > no, it is not. > that will keep the registry forever because it acts over a block (no ephemerons, remember) > > Esteban > > On Aug 28, 2013, at 11:56 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Does this work? >> >> Doru >> >> >> On Wed, Aug 28, 2013 at 11:54 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> whenListChanged: aBlock >> "Specify a block to value after the contents of the list has changed" >> >> "Basically when you set a new list of items" >> >> <api: #event> >> | block | >> block := [ :announcement :ann | >> aBlock >> cull: announcement newContents >> cull: announcement oldContents >> cull: announcement >> cull: ann ]. >> listAnnouncer weak >> when: ValueChanged >> do: block >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 28, 2013

Can we stop these "[regression reporter]regression occurred" messages?

by Geert Claes

Noticed a large number of regression reporter messages filling up the mailing list, surely there is a better way than to spam the mailing list no? -- View this message in context: http://forum.world.st/Can-we-stop-these-regression-reporter-regression-occu… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 28, 2013

Re: [Pharo-dev] Recent VM for Pharo 2 on Ubuntu 8.04

by StÃ©phane Ducasse

Indeed I do not see how we could provide support that oracle does not. We should be realistic. >>> for older systems, you are by your own. Is like that, yes. >>> >>> We cannot maintain all VM for all possible configurations. Nobody can do that, not even canonical, less us. Ubuntu 8.04 is just too old. >>> >>> Even JVM is not supported on Ubuntu 8.04: http://www.oracle.com/technetwork/java/javase/config-417990.html >>> (latest is 10.04... which we support, or intent to at least) >>> Also... we are not oracle, we have more limited resources. >>> >>> So , is not a workaround. Is the only reasonable solution: every software provider in earth supports a limited amount of system configurations, usually from some years ago, we provide at least the sources, instructions and support in the form of help/answering questions. >>> >> >> This is not the only instance of the problem. >> If I'm not much mistaken, same problem has been recently reported for Debian 7 >> (Laszlo Zsolt KIss, 08/08/13 10:43). As Andres pointed out (08/08/13 14:40), it's libc is 17 months old. The proposed "solution" was the same - recompile on target system. > > in that moment answer was: compile it yourself until we provide a working version (which we now provide). > Ubuntu 8 is another problem :( > but do not get me wrong... is not that I do not would want to help... is just that I need to be realistic about what I can and what I don't :( > > >> >> To make me clear, I have no problem if you say "Sorry, we don't support >> anything older than 12 months. Or 3 years. Or ...". I just don't think >> that asking people to recompile whenever there is glibc dependency problem is "real solution". >> >> I'm very sorry for starting this pointless discussion. >> >>> >>>> >>>>> we can offer support (but should be pretty straight forward, specially in linux systems). >>>>> >>>>> I disagree with the solution proposed in (2), the cost of maintaining such approach would be exponential. >>>> >>>> No, not really. There aren't many of those (at least, weren't in my case) and I found out that sometimes I could do better (faster) job :-) >>> >>> you are invited to provide your working version, it would be cool for everybody :) >>> >> >> Unfortunately, I've done it for a different VM :-) >> >> >> Best, Jan >> > >

Aug. 28, 2013