- Pharo-dev - lists.pharo.org

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

by Esteban Lorenzano

just because I have vocation of service :) enjoy, Esteban On Aug 28, 2013, at 3:50 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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

[update 3.0] #30356

by Marcus Denker

30356 ----- 11493 Support negative lookahead in Regex https://pharo.fogbugz.com/f/cases/11493 11491 unsubscribe from editor in NECController https://pharo.fogbugz.com/f/cases/11491 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Regex-Tests-Core-MarcusDenker… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Regex-Core-MarcusDenker.30.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/NECompletion-MarcusDenker.131…

Aug. 28, 2013

Error with MC configurations

by Yuriy Tymchuk

Hi everyone. I was working with a configuration for one of my projects and ended up with an error 'New categories must match old ones' while loading my configuration. More info here: http://stackoverflow.com/questions/18486091/systemorganizer-new-categories-… I'll be very thankful for guidance. Cheers! Uko

Aug. 28, 2013

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

by Igor Stasenko

there is something sick in this code.. using block to transform evaluation of another block :( On 28 August 2013 15:40, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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" > > > -- Best regards, Igor Stasenko.

Aug. 28, 2013

[update 3.0] #30355

by Marcus Denker

30355 ----- 11484 Strong pointer explorer showing weak references https://pharo.fogbugz.com/f/cases/11484 11490 Failing tests in RBPushDownInstanceVariables https://pharo.fogbugz.com/f/cases/11490 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1226.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Tests-Core-Marcus…

Aug. 28, 2013

Re: [Pharo-dev] Debugger recursion

by Mariano Martinez Peck

On Wed, Aug 28, 2013 at 11:18 AM, jan.struz <public+pharo(a)struz.cz> wrote: > 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. > Indeed. I thought it was disabled by default. > It's interesting to see the (no)difference between the debuggingMessages in > Ghost, and these needed for ProtoObject subclass... :-) > > It seems you were not the first fighting with that :) Maybe it's time to document all this by having integrated in the image a DebuggeableProtoObject? Subclass of ProtoObject and implementing the needed methods? Those that could be implemented, can be implemented and those that would depend on the usage, could be implemented as "self subclassResponsability". But what is important is that such a class will document the needed methods in order to proper debug/inspect subclasses of ProtoObject. Cheers, > 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. > > -- Mariano http://marianopeck.wordpress.com

Aug. 28, 2013

Update

by Fernando Olivero

Hi Sven, please update my contributor profile. PharoContributor new name: 'Fernando Olivero'; email: 'fernando.olivero.mail(a)gmail.com'; website: 'http://fernandoolivero.wordpress.com'; description: 'Software Developer and Research Scientist'; yourself

Aug. 28, 2013

[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