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

Grease conflicts #packages with RPackage

by Mariano Martinez Peck

Hi guys, I was trying to build a new image with latest Pharo 2.0 with all the frameworks I use. While installing, I get a dnu in: packageFromOrganizer: anRPackageOrganizer "This method returns the package this method belongs to. It takes into account classes and traits. If the method is in no package, returns nil by now" self flag: 'TODO: use anRPackageOrganizer, or better delegate to anRPackageOrganizer'. ^self origin packages detect: [ :each | (each includesSelector: self selector ofClassName: self origin theNonMetaClass originalName) or: [ each includesSelector: self selector ofMetaclassName: self origin theNonMetaClass originalName]] ifNone: [ nil ] because "each" (which was GRPackage) dnu #includesSelector:ofClassName: Problem is that "self origin" answers GRPackage. And GRPackage DOES implement a CLASS side method #packages that answers instances of GRPackage.....not RPackage... So...which one do we prefix? GRPackage class #packages to #greasePackages? BTW, there are yet more class side implementations of #packages, which are basically subclasses for the HelpSystem (CustomHelp). So we have for example SUnitAPIDocumentation, RegexAPIDocumentation, ProfStefAPIHelp, HelpAPIDocumentation, AnnouncementsAPIDocumentation. Guess we should update the HelpSystem as well? Let me know and I open issues/submit fixes. Cheers, -- Mariano http://marianopeck.wordpress.com

Aug. 28, 2013

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

by Esteban Lorenzano

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) yes, is possible that it runs. But basically what they say is that if it doesn't, you are by your own, they will not provide support (and I was talking about support). And they are oracle, that's my point: they dropped support for ubuntu 8 a couple of years ago... > 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. well... yes and no... pharo3 will require pharo3vm, but pharo2 can be run with VMs from more than a year (the real problem here was the annoying SmallInteger bug, and probably some other minor VM problems) > > 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] Compilation code in grease not compatible with Pharo 3.0

by Damien Cassou

On Wed, Aug 28, 2013 at 9:56 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > thank you Marcus. Now, this does not work because #printCategoryChunk:on: > does not exist anymore: > we found the solution, thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Aug. 28, 2013

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