- Pharo-dev - lists.pharo.org

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

Re: FileException only when opening image in certain way...

by Davide Varvello

Moreover, on Pharo4 it's working. Davide Dale Henrichs-3 wrote > Mariano, > > I think your problem might have something to do with how the PWD env var > is managed in OSX ... Check the value of the 'PWD' in your different > examples and see if that sheds any light ... > > Dale > > On 7/26/16 5:49 AM, Mariano Martinez Peck wrote: >> >> >> On Tue, Jul 26, 2016 at 9:48 AM, Mariano Martinez Peck >> < > marianopeck@ > <mailto: > marianopeck@ > >> wrote: >> >> Hi guys, >> >> Davide Varvello reported me an issue with Fuel, failing to do: >> >> FLSerializer serialize: 'whatever' toFileNamed: 'demo.fuel'. >> >> Such a thing would bring an error like this: >> >> File>>openForWrite: >> File>>openForWrite >> File>>writeStream >> File>>writeStreamDo: >> FLPharo5Platform>>fileNamed:writeStreamDo: >> FLSerializer>>serialize:toFileNamed: >> FLSerializer class>>serialize:toFileNamed: >> >> The code is: >> >> FLPharo5Platform >> fileNamed: aFilename writeStreamDo: aBlock >> ^ ((Smalltalk at: #File) named: aFilename) writeStreamDo: [ :stream | >> stream binary. >> aBlock value: stream ] >> >> >> Now..I have tried to reproduce it but it happens only depending on >> how the vm/image was started!!! And I only tested on OSX. >> >> Download the oneclick from here: >> http://files.pharo.org/platform/Pharo5.0-mac.zip and see my results: >> >> 1) Executing VM from command line and passing the image as >> argument: WORKS. >> 2) Double clicking on the internal Pharo binary (which auto-starts >> the image): WORKS >> 3) Double clicking the internal Pharo image and then "Open With" >> and I select the Pharo VM: DOES NOT WORK. >> 4) Double clicking the Pharo one click: DOES NOT WORK. >> >> >> I forgot to said... if you create the file in advance, with something >> like: >> >> FileStream forceNewFileNamed: 'demo.fuel' do: [ :aStream | >> FLSerializer serialize: 'whatever' on: aStream binary ] >> >> It does work in all cases. >> >> Has anyone experienced something like this? Looks like different >> file / directory permissions when starting in different ways? >> >> Thanks in advance, >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com -- View this message in context: http://forum.world.st/FileException-only-when-opening-image-in-certain-way-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

July 26, 2016

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

by Nicolai Hess

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" > > 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] FileException only when opening image in certain way...

by Dale Henrichs

Mariano, I think your problem might have something to do with how the PWD env var is managed in OSX ... Check the value of the 'PWD' in your different examples and see if that sheds any light ... Dale On 7/26/16 5:49 AM, Mariano Martinez Peck wrote: > > > On Tue, Jul 26, 2016 at 9:48 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > Hi guys, > > Davide Varvello reported me an issue with Fuel, failing to do: > > FLSerializer serialize: 'whatever' toFileNamed: 'demo.fuel'. > > Such a thing would bring an error like this: > > File>>openForWrite: > File>>openForWrite > File>>writeStream > File>>writeStreamDo: > FLPharo5Platform>>fileNamed:writeStreamDo: > FLSerializer>>serialize:toFileNamed: > FLSerializer class>>serialize:toFileNamed: > > The code is: > > FLPharo5Platform >> fileNamed: aFilename writeStreamDo: aBlock > ^ ((Smalltalk at: #File) named: aFilename) writeStreamDo: [ :stream | > stream binary. > aBlock value: stream ] > > > Now..I have tried to reproduce it but it happens only depending on > how the vm/image was started!!! And I only tested on OSX. > > Download the oneclick from here: > http://files.pharo.org/platform/Pharo5.0-mac.zip and see my results: > > 1) Executing VM from command line and passing the image as > argument: WORKS. > 2) Double clicking on the internal Pharo binary (which auto-starts > the image): WORKS > 3) Double clicking the internal Pharo image and then "Open With" > and I select the Pharo VM: DOES NOT WORK. > 4) Double clicking the Pharo one click: DOES NOT WORK. > > > I forgot to said... if you create the file in advance, with something > like: > > FileStream forceNewFileNamed: 'demo.fuel' do: [ :aStream | > FLSerializer serialize: 'whatever' on: aStream binary ] > > It does work in all cases. > > Has anyone experienced something like this? Looks like different > file / directory permissions when starting in different ways? > > Thanks in advance, > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

July 26, 2016

Why nil needs class hierarchy protocol?

by Denis Kudriashov

Hi. Look at UndefinedObject instance side methods. You will see class hierarchy protocol. For example nil understands #subclasses message: nil subclasses "==> {ProtoObject}" 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] FileException only when opening image in certain way...

by Mariano Martinez Peck

On Tue, Jul 26, 2016 at 9:48 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys, > > Davide Varvello reported me an issue with Fuel, failing to do: > > FLSerializer serialize: 'whatever' toFileNamed: 'demo.fuel'. > > Such a thing would bring an error like this: > > File>>openForWrite: > File>>openForWrite > File>>writeStream > File>>writeStreamDo: > FLPharo5Platform>>fileNamed:writeStreamDo: > FLSerializer>>serialize:toFileNamed: > FLSerializer class>>serialize:toFileNamed: > > The code is: > > FLPharo5Platform >> fileNamed: aFilename writeStreamDo: aBlock > ^ ((Smalltalk at: #File) named: aFilename) writeStreamDo: [ :stream | > stream binary. > aBlock value: stream ] > > > Now..I have tried to reproduce it but it happens only depending on how the > vm/image was started!!! And I only tested on OSX. > > Download the oneclick from here: > http://files.pharo.org/platform/Pharo5.0-mac.zip and see my results: > > 1) Executing VM from command line and passing the image as argument: WORKS. > 2) Double clicking on the internal Pharo binary (which auto-starts the > image): WORKS > 3) Double clicking the internal Pharo image and then "Open With" and I > select the Pharo VM: DOES NOT WORK. > 4) Double clicking the Pharo one click: DOES NOT WORK. > > I forgot to said... if you create the file in advance, with something like: FileStream forceNewFileNamed: 'demo.fuel' do: [ :aStream | FLSerializer serialize: 'whatever' on: aStream binary ] It does work in all cases. > Has anyone experienced something like this? Looks like different file / > directory permissions when starting in different ways? > > Thanks in advance, > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

July 26, 2016

FileException only when opening image in certain way...

by Mariano Martinez Peck

Hi guys, Davide Varvello reported me an issue with Fuel, failing to do: FLSerializer serialize: 'whatever' toFileNamed: 'demo.fuel'. Such a thing would bring an error like this: File>>openForWrite: File>>openForWrite File>>writeStream File>>writeStreamDo: FLPharo5Platform>>fileNamed:writeStreamDo: FLSerializer>>serialize:toFileNamed: FLSerializer class>>serialize:toFileNamed: The code is: FLPharo5Platform >> fileNamed: aFilename writeStreamDo: aBlock ^ ((Smalltalk at: #File) named: aFilename) writeStreamDo: [ :stream | stream binary. aBlock value: stream ] Now..I have tried to reproduce it but it happens only depending on how the vm/image was started!!! And I only tested on OSX. Download the oneclick from here: http://files.pharo.org/platform/Pharo5.0-mac.zip and see my results: 1) Executing VM from command line and passing the image as argument: WORKS. 2) Double clicking on the internal Pharo binary (which auto-starts the image): WORKS 3) Double clicking the internal Pharo image and then "Open With" and I select the Pharo VM: DOES NOT WORK. 4) Double clicking the Pharo one click: DOES NOT WORK. Has anyone experienced something like this? Looks like different file / directory permissions when starting in different ways? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

July 26, 2016

[pharo-project/pharo-core] 155ec4: 60155

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 155ec47963583298074f33a1abb53bfdda59e734 https://github.com/pharo-project/pharo-core/commit/155ec47963583298074f33a1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-07-26 (Tue, 26 Jul 2016) Changed paths: M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic versions/stable_.st A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F22%5F2_.st M Kernel.package/Margin.class/instance/printing/printOn_.st M Morphic-Widgets-Pluggable.package/PluggableTextMorph.class/instance/actions/acceptBasic.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60154.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60155.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60154.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60155.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Core.package/RadioButtonGroupModel.class/README.md A Spec-Core.package/RadioButtonGroupModel.class/class/example/example.st A Spec-Core.package/RadioButtonGroupModel.class/class/specs/defaultSpec.st A Spec-Core.package/RadioButtonGroupModel.class/definition.st A Spec-Core.package/RadioButtonGroupModel.class/instance/accessing/buttons.st A Spec-Core.package/RadioButtonGroupModel.class/instance/accessing/createWidgets.st A Spec-Core.package/RadioButtonGroupModel.class/instance/accessing/currentActivated.st A Spec-Core.package/RadioButtonGroupModel.class/instance/accessing/currentActivated_.st A Spec-Core.package/RadioButtonGroupModel.class/instance/accessing/rebuildWidget.st A Spec-Core.package/RadioButtonGroupModel.class/instance/initialization/initialize.st A Spec-Core.package/RadioButtonGroupModel.class/instance/initialization/initializePresenter.st A Spec-Core.package/RadioButtonGroupModel.class/instance/protocol-events/whenCanDeselectByClickChanged_.st A Spec-Core.package/RadioButtonGroupModel.class/instance/protocol-events/whenCurrentActivatedChanged_.st A Spec-Core.package/RadioButtonGroupModel.class/instance/protocol/addRadioButton_.st A Spec-Core.package/RadioButtonGroupModel.class/instance/protocol/canDeselectByClick.st A Spec-Core.package/RadioButtonGroupModel.class/instance/protocol/canDeselectByClick_.st A Spec-Core.package/RadioButtonGroupModel.class/instance/protocol/defaultOnce_.st A Spec-Core.package/RadioButtonGroupModel.class/instance/protocol/default_.st A Spec-Core.package/RadioButtonGroupModel.class/instance/protocol/linkRadioButton_.st A Spec-Core.package/RadioButtonGroupModel.class/instance/specs/dynamicLayout.st A Spec-Tests.package/RadioButtonGroupModelTest.class/README.md A Spec-Tests.package/RadioButtonGroupModelTest.class/definition.st A Spec-Tests.package/RadioButtonGroupModelTest.class/instance/running/setUp.st A Spec-Tests.package/RadioButtonGroupModelTest.class/instance/running/tearDown.st A Spec-Tests.package/RadioButtonGroupModelTest.class/instance/tests/testAddRadioButton.st A Spec-Tests.package/RadioButtonGroupModelTest.class/instance/tests/testAddingFocusOrder.st A Spec-Tests.package/RadioButtonGroupModelTest.class/instance/tests/testCurrentActivated.st A Spec-Tests.package/RadioButtonGroupModelTest.class/instance/tests/testDefault.st A Spec-Tests.package/RadioButtonGroupModelTest.class/instance/tests/testLinkRadioButton.st A Spec-Tests.package/RadioButtonGroupModelTest.class/instance/tests/testOpenAndClose.st A Spec-Tests.package/RadioButtonGroupModelTest.class/instance/tests/testRebuildWidget.st M Spec-Tests.package/TabManagerModelTest.class/instance/tabs creation/redMorphTab.st M Spec-Tests.package/TabModelTest.class/instance/instance creation/redMorphTab.st M UnifiedFFI-Tests.package/FFIExternalStructureTests.class/instance/tests/testExternalStructWithArray.st M UnifiedFFI-Tests.package/FFIExternalStructureTests.class/instance/tests/testNestedStructureWithArray.st M UnifiedFFI-Tests.package/FFIExternalStructureTests.class/instance/tests/testStructWithArray.st Log Message: ----------- 60155 18734 Two tests failing in FFIExternalStructureTests https://pharo.fogbugz.com/f/cases/18734 18807 Improve Margin>>#printOn: https://pharo.fogbugz.com/f/cases/18807 18741 add RadioButtonGroupModel https://pharo.fogbugz.com/f/cases/18741 18775 Fix a typo https://pharo.fogbugz.com/f/cases/18775 http://files.pharo.org/image/60/60155.zip

July 26, 2016