- Pharo-dev - lists.pharo.org

Accept in Debugger Meltdown in Pharo 5.0

by Sean P. DeNigris

<http://forum.world.st/file/n4908072/Screenshot_2016-07-26_13.png> Mac spinning beachball of death followed after about a minute by "... quit unexpectedly". Bugforeveryoneorjustme? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Accept-in-Debugger-Meltdown-in-Pharo-5-0-tp4908072.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 26, 2016

http://source.squeakfoundation.org down

by Dale Henrichs

It's not just me: http://downforeveryoneorjustme.com/source.squeakfoundation.org I'm getting a '502 Bad Gateway' error ... I seems to have broken in the last hour or so ... It also appears that the squeak mailing list is down --- which is why I've sent the mail here --- The FFI code is hosted on http://source.squeakfoundation.org so this will likely impact others as well ... Dale

July 26, 2016

magritte extras

by Sean Glazier

I am looking at creating a tool that works like the magritte example. It uses Magritte-XMLBinding. I ran the tests and had a small number of failures in Magritte-Tests-XMLBinding. The example class MADescriptionEditor is in the examples tag of the Magritte-Seaside package. It came from Repository: http://smalltalkhub.com/mc/Magritte/Magritte3/main/ and the XML binding for the examples comes from Repository: http://smalltalkhub.com/mc/Magritte/Magritte3Addons/main/ So if someone has these working and playing together that would be great. If it is outdated and we are to use something else I would like to know what the preferred way is so I can build the example building the descriptions using I guess json. Many thanks :-) Kind Regards, Sean Glazier

July 26, 2016

Re: [Pharo-dev] Why nil needs class hierarchy protocol?

by Eliot Miranda

> On Jul 26, 2016, at 8:56 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-07-26 15:33 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> Look at UndefinedObject instance side methods. You will see class hierarchy protocol. For example nil understands #subclasses message: >>> >>> nil subclasses "==> {ProtoObject}" > > It is true only for ProtoObject. If you will create another class with nil superclass, you will not see it here Bullseye.

July 26, 2016

Re: [Pharo-dev] Why nil needs class hierarchy protocol?

by Denis Kudriashov

2016-07-26 16:09 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Sorry to sound harsh but that's no sense. ProtoObject doesn't have a > superclass. This is indicated by ProtoObject superclass answering nil, > where nil is the object that represents being undefined. > > It is (as Denis points out) a bug, showing some confusion, to try and > program around this one case by adding class protocol to the undefined > object. A horrible hack. > I think so too :)

July 26, 2016

Re: [Pharo-dev] Why nil needs class hierarchy protocol?

by Denis Kudriashov

2016-07-26 15:33 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > Look at UndefinedObject instance side methods. You will see class >> hierarchy protocol. For example nil understands #subclasses message: >> >> nil subclasses "==> {ProtoObject}" >> >> It is true only for ProtoObject. If you will create another class with nil superclass, you will not see it here

July 26, 2016

Doubled setting for now showing catalog projects in Spotter

by Torsten Bergmann

Hi, I today wondered as in latest image it was not possible to download projects from Spotter anymore. The setting for downloading projects from Catalog was enabled. In latest Pharo 6 there is a new (second and redundant) setting to exclude catalog projects from Spotter (now provided by the GT tools). Also it is not implemented very nice: - it uses reflection and is therefore hard to find (implemented in #catalogSettingsOn:) - it shows ugly symbols in the settings browser without any description - while the method is called #catalogSettingsOn: the way it is implemented it allows to disable ANY GT Spotter extension in the settings browser as it uses "GTSpotter spotterExtendingMethods". Not very intention revealing. To me this really looks like a BIG AND QUICK HACK and a solution to a problem that was already solved before. Please remove it/roll back this unnecessary addition. Side note: ========== There ALREADY WAS A SETTING FOR THAT (since Pharo 5 or 4) to not query the catalog (because a few people lamented before that it slows down when connected with low bandwidth network). It is implemented in CatalogSettings and you can find it in the settings browser under "Tools" -> "Catalog" -> "Display catalog projects in Spotter" and is used in the spotter extension #spotterCatalogProjectsFor: Second side note: ================= If the intention was to generally provide an ability to disable any spotter extension (via reflection) then use #spotterExtensionSettingsOn: instead of the name #catalogSettingsOn: and set the default to true for the catalog extension. If you want to disable projects showing up by default in spotter via network connection than use the one that was already there and set it to false by default. (which I would not do as network should be fast enough these days for catalog in most places also catalog is already cached and the call implemented asynchronously, so Spotter opens right away). Thanks Torsten

July 26, 2016

Re: [Pharo-dev] Why nil needs class hierarchy protocol?

by Peter UhnÃ¡k

Well the class definition of ProtoObject is ProtoObject subclass: #ProtoObject slots: { } classVariables: { } category: 'Kernel-Objects'. ProtoObject superclass: nil So I guess by setting the superclass to nil, it was added as a child, since UndefinedObject is still just an object :) On Tue, Jul 26, 2016 at 4:09 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Nicolai, > > On Jul 26, 2016, at 6:33 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-07-26 15:08 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> Hi. >> >> Look at UndefinedObject instance side methods. You will see class >> hierarchy protocol. For example nil understands #subclasses message: >> >> nil subclasses "==> {ProtoObject}" >> >> > ProtoObjects superclass is nil, so maybe it just should behave the same > way for all other objects. > > ByteString superclass subclasses includes: ByteString. "true" > > ProtoObject superclass subclasses includes: ProtoObject. "true" > > > Sorry to sound harsh but that's no sense. ProtoObject doesn't have a > superclass. This is indicated by ProtoObject superclass answering nil, > where nil is the object that represents being undefined. > > It is (as Denis points out) a bug, showing some confusion, to try and > program around this one case by adding class protocol to the undefined > object. A horrible hack. > > Denis, you're right; that behaviour should be deleted. > > > >> >> It implemented like this: >> >> UndefinedObject >>subclassesDo: aBlock >> "Evaluate aBlock with all subclasses of nil. Others are not direct >> subclasses of Class." >> >> ^ Class subclassesDo: [:cl | >> cl isMeta ifTrue: [aBlock value: cl soleInstance]]. >> >> >> >> So my question is: why it needs to be like that? And does it really >> needed? >> >> I removed all this methods and not saw any problem. >> > >

July 26, 2016

Re: [Pharo-dev] Why nil needs class hierarchy protocol?

by Eliot Miranda

Hi Nicolai, > On Jul 26, 2016, at 6:33 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-07-26 15:08 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> Hi. >> >> Look at UndefinedObject instance side methods. You will see class hierarchy protocol. For example nil understands #subclasses message: >> >> nil subclasses "==> {ProtoObject}" > > ProtoObjects superclass is nil, so maybe it just should behave the same way for all other objects. > > ByteString superclass subclasses includes: ByteString. "true" > > ProtoObject superclass subclasses includes: ProtoObject. "true" Sorry to sound harsh but that's no sense. ProtoObject doesn't have a superclass. This is indicated by ProtoObject superclass answering nil, where nil is the object that represents being undefined. It is (as Denis points out) a bug, showing some confusion, to try and program around this one case by adding class protocol to the undefined object. A horrible hack. Denis, you're right; that behaviour should be deleted. > >> >> It implemented like this: >> >> UndefinedObject >>subclassesDo: aBlock >> "Evaluate aBlock with all subclasses of nil. Others are not direct subclasses of Class." >> >> ^ Class subclassesDo: [:cl | >> cl isMeta ifTrue: [aBlock value: cl soleInstance]]. >> >> >> So my question is: why it needs to be like that? And does it really needed? >> >> I removed all this methods and not saw any problem. >

July 26, 2016

Re: [Pharo-dev] Nautilus... switching from hierarchy to package

by Nicolai Hess

2016-07-25 20:51 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi > > I would like to know what you think. > > I found annoying that when I'm browsing an hierarchy I cannot switch to > the package view > > when I click on a class outside of the current package. > +1 It already worked like that - once. But that does not work always (I don't remember, something with updating the view when class or packages changed). It was easier to just remove the behavior instead of fixing the code. > > > Stef > > >

July 26, 2016