June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Auto create new and initialize methods for new class?

by StÃ©phane Ducasse

On Jun 16, 2012, at 11:00 AM, Nicolas Cellier wrote: > 2012/6/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> >>> On Jun 15, 2012, at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>>> why do you need an automatic new method? >>>> Because by default >>>> new invoke initialize >>>> >>>> and it works well. >>>> >>> >>> StÃ©phane, I have been using VW Smalltalk and it creates new classes ,by default, with a #new method on the class side and a #initialize method on the instance side. >> >> yes I always hated hated so much to force teacher to kill student on metaclass altar after two weeks of smalltalk > > Another point of view: creating an instance is on class side what is the class side? :) > because > instances are created from a kind of structural template (how many > variables, etc...). You can also create an instance by cloning with > copyâ¦ I have been there. Teaching a lot during many years and there is no simple explanation: after two hours of lecture you do not want to explain metaclasses. Just because people forgot (CLOS did not do this mistake) to invoke an initialize method when creating an object. At the end I added in all my system the Behavior new>> self basicNew initialize and the students were happy and me too. > But initialize is on instance size because it modifies the private > instance variables: > one object can't directly modify another, except by kindly asking by > sending a message. > The instance is an object, the class is another, so the class kindly > ask the instance to initialize itself. > > There's no trick here and it can't be more clear. > The only trick is how a class side new inherits from instance side > Behavior new, but we don't need this to explain initialize... > > Nicolas >

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by Nicolas Cellier

2012/6/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> >> On Jun 15, 2012, at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> why do you need an automatic new method? >>> Because by default >>> Â new invoke initialize >>> >>> and it works well. >>> >> >> StÃ©phane, I have been using VW Smalltalk and it creates new classes ,by default, with a #new method on the class side and a #initialize method on the instance side. > > yes I always hated hated so much to force teacher to kill student on metaclass altar after two weeks of smalltalk Another point of view: creating an instance is on class side because instances are created from a kind of structural template (how many variables, etc...). You can also create an instance by cloning with copy... But initialize is on instance size because it modifies the private instance variables: one object can't directly modify another, except by kindly asking by sending a message. The instance is an object, the class is another, so the class kindly ask the instance to initialize itself. There's no trick here and it can't be more clear. The only trick is how a class side new inherits from instance side Behavior new, but we don't need this to explain initialize... Nicolas

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by StÃ©phane Ducasse

On Jun 16, 2012, at 12:57 AM, Schwab,Wilhelm K wrote: > But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now. Bill when do you take the time to have a look at Metacello. Why people like me are spending days on writing 45 pages of documentation to hear you saying that. This scenario is supported since months nearly since Barcelona 2010. > If we can't do that, the config browser is pretty much a dream vs. reality. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sean P. DeNigris [sean(a)clipperadams.com] > Sent: Friday, June 15, 2012 2:49 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 > > Schwab,Wilhelm K wrote >> >> My gripe is... that configs... work (very) differently over time >> > With the current evolution of Metacello, this should not be the case. Done > right, what a config loads can be 100% static and repeatable. If you load a > literal version (e.g. '1.4'), which loads literal versions of dependent > projects (which they should unless there is a reason not to, e.g. a loose > dependency like Seaside on OB), which load literal versions all the way > down, it will do the same thing today, tomorrow, and ten years from now. > > The only hill to climb now is getting the word out about Metacello > conventions/best practices. > > > Schwab,Wilhelm K wrote >> >> If pre-loading, how about FFI? >> > I think "easily loadable" is the correct state, not included by default. > > -- > View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by StÃ©phane Ducasse

On Jun 15, 2012, at 11:36 PM, phil(a)highoctane.be wrote: > Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay! > > But I like to have a view on several classes and typing HOPRÂ¨helps. > > Same when exploring the system for doing something (like > sound-synthesis for example). > > BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 > extract of yours. > > As of Pharo 1.4 Summer Release, having a somewhat cleaned up > Sound-synthesis in it would be nice. our agenda is more than full. Do not expect anything from us on this side. we have athens FFI/NativeBoost and a lot of other points to fix. > I am currently creating a little game in Smalltalk targeting the iPad > and a game without sound is not that of a game. Load the packages and try. > > For beginners and motivating people to move aboard the platform, sound > is important to have. > > KR > Philippe > > 2012/6/15 Sean P. DeNigris <sean(a)clipperadams.com>: >> >> philippeback wrote >>> >>> Have been using Nautilus and OB and albeit Nautilus is nicer looking, >>> I find my way better with OB. Especially with the top search bar and >>> categorizing into protocols. More buttons under the lists in OB but I >>> do prefer them actually. >>> >> >> Overall, I like Nautilus' workflow better, but I know what you mean about >> the buttons. Even with the visual feedback, I'm never quite sure if I'm "in" >> class-side mode, or I have to hit the button to "get" class-side mode. I was >> missing the search bar, but with spotlight, it's moot. >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Philippe Back > Dramatic Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: > phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > Belgium >

June 16, 2012

Re: [Pharo-project] Auto create new and initialize methods for new class?

by StÃ©phane Ducasse

> > > On Jun 15, 2012, at 12:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> why do you need an automatic new method? >> Because by default >> new invoke initialize >> >> and it works well. >> > > StÃ©phane, I have been using VW Smalltalk and it creates new classes ,by default, with a #new method on the class side and a #initialize method on the instance side. yes I always hated hated so much to force teacher to kill student on metaclass altar after two weeks of smalltalk

June 16, 2012

Re: [Pharo-project] flatten method is kind of broken

by StÃ©phane Ducasse

doru can you open a bug entry and provide necessary information? Package and tests? Stef On Jun 16, 2012, at 8:07 AM, Tudor Girba wrote: > Indeed. It would be great to integrate CollectionExtensions into Pharo. > > For example, we have: > #(#(1) #(2 3) #(#(4) 5) ) deepFlatten > ==> #(1 2 3 4 5) > > Cheers, > Doru > > On 15 Jun 2012, at 21:04, StÃ©phane Ducasse wrote: > >> fabrizio we should really include some of the moose extensions to pharo. >> Could you take the lead on that? >> >> Did you try gather:? >> >> Stef >> >> On Jun 15, 2012, at 10:05 AM, Fabrizio Perin wrote: >> >>> Hi, >>> I need to flatten a collection which does not contain other collections necessarily. The method flatten doesn't really work: >>> >>> #(#(1 2) #(3 4)) flatten -> #(1 2 3 4) OK >>> >>> #(#(1) #(2 3) #(#(4) 5) ) flatten -> #(1 2 3 #(4) 5) I would have expected something like #(1 2 3 4 5) >>> >>> #(1 2 3) flatten -> error >>> #(#(1) 2 3) flatten -> error >>> >>> Is this the meant behavior for flatten? Any other method I could use instead? >>> >>> Thanks, >>> Fabrizio >> >> > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > >

June 16, 2012

Re: [Pharo-project] flatten method is kind of broken

by Tudor Girba

Indeed. It would be great to integrate CollectionExtensions into Pharo. For example, we have: #(#(1) #(2 3) #(#(4) 5) ) deepFlatten ==> #(1 2 3 4 5) Cheers, Doru On 15 Jun 2012, at 21:04, StÃ©phane Ducasse wrote: > fabrizio we should really include some of the moose extensions to pharo. > Could you take the lead on that? > > Did you try gather:? > > Stef > > On Jun 15, 2012, at 10:05 AM, Fabrizio Perin wrote: > >> Hi, >> I need to flatten a collection which does not contain other collections necessarily. The method flatten doesn't really work: >> >> #(#(1 2) #(3 4)) flatten -> #(1 2 3 4) OK >> >> #(#(1) #(2 3) #(#(4) 5) ) flatten -> #(1 2 3 #(4) 5) I would have expected something like #(1 2 3 4 5) >> >> #(1 2 3) flatten -> error >> #(#(1) 2 3) flatten -> error >> >> Is this the meant behavior for flatten? Any other method I could use instead? >> >> Thanks, >> Fabrizio > > -- www.tudorgirba.com "We are all great at making mistakes."

June 16, 2012

[Pharo-project] PackageOrganizer packages vs. categories

by Sean P. DeNigris

I was expecting "PackageOrganizer default packageOfClass: FileSystemError" to return "FileSystem-Core" but it returned "FileSystem-Core-Kernel", which is not a package. It's a category, but it's packaged in "FileSystem-Core". Is this a bug? Will PackageOrganizer go away when RPackage takes over? Sean -- View this message in context: http://forum.world.st/PackageOrganizer-packages-vs-categories-tp4635069.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 16, 2012

Re: [Pharo-project] Tests Guard report for 20132

by Sean P. DeNigris

Pavel Krivanek-3 wrote > > and now bad news, as expected we have a lot of new failing tests: > FileSystem.Tests.Disk.DiskFileSystemTest.testRootIsNotAFile DiskStore>>isFile: ... aPath isRoot ifTrue: [ ^ true ]. easy fix, but which is wrong - the test or the implementation? Pavel Krivanek-3 wrote > > * SUnit.Tests.Core.TestCaseTest.testAssertEqualsActualAndExpectedOrder OMG! This one won't die!! It's so confusing, even the bug reports are unintelligible :) But it should be fixed with the slice below... Here's an issue: Issue 6069: Test guard for 20132 http://code.google.com/p/pharo/issues/detail?id=6069 And here is a slice with most of the tests passing (don't know about the linux ones). They were mostly related to FS-everywhere: Fix in inbox: SLICE-Issue-6069-Test-guard-for-20132-SeanDeNigris.1 Make the following tests pass (per http://forum.world.st/Tests-Guard-report-for-20132-td4634905.html) * CompressionTests.Archive.ZipArchiveTest.testCreateWithRelativeNames * CompressionTests.Archive.ZipArchiveTest.testFilePermissions * CompressionTests.Archive.ZipArchiveTest.testZip * Gofer.Tests.GoferApiTest.testDirectoryRepository * Gofer.Tests.GoferApiTest.testSubDirectoryRepository * SUnit.Tests.Core.TestCaseTest.testAssertEqualsActualAndExpectedOrder * Tests.Monticello.MCFileInTest.testStWriter * Tests.Monticello.MCMczInstallerTest.testInstallFromFile * Tests.Monticello.MCMczInstallerTest.testInstallFromStream * Tests.Monticello.MCMethodDefinitionTest.testCannotLoad * Tests.Monticello.MCMethodDefinitionTest.testComparison * Tests.Monticello.MCMethodDefinitionTest.testLoadAndUnload * Tests.Monticello.MCMethodDefinitionTest.testPartiallyRevertOverrideMethod * Tests.Monticello.MCMethodDefinitionTest.testRevertOldMethod * Tests.Monticello.MCMethodDefinitionTest.testRevertOverrideMethod * Tests.System.SmalltalkImageTest.testImageName Easy to fix, pending question: * FileSystem.Tests.Disk.DiskFileSystemTest.testRootIsNotAFile DiskStore>>isFile: ... aPath isRoot ifTrue: [ ^ true ]. easy fix, but which is wrong - the test or the implementation? Remaining to be fixed: * RPackage.Tests.RPackageImportFromPackageInfoTest.testImportExtensionFromParentPackageRegisterExtensionInParentPackage * SUnit.Tests.Core.SUnitTest.testDialectLocalizedException * Tests.Traits.TraitTest.testTraitsMethodClassSanity -- View this message in context: http://forum.world.st/Tests-Guard-report-for-20132-tp4634905p4635064.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 16, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by Sean P. DeNigris

If you provide the script (i.e. version(s)) that you used and the platform(s) you successfully loaded/used the project on, I will update the configs... We should have a central place to share these custom load scripts and results so that they can be mined by config maintainers. prob would crowd the Metacello list too much. maybe Dale will create a special list for it. I'll cc the Metacello list... On Jun 15, 2012, at 8:45 PM, Schwab,Wilhelm K [via Smalltalk] wrote: > Digging through my so-called memory<g>, loading both Alien and Citezen required special attention. Alien led to a broken image, and Citezen was simply tricky to load such that it would work. Both required requesting specific versions in order to work. > > > > > ________________________________________ > From: [hidden email] [[hidden email]] on behalf of Sean P. DeNigris [[hidden email]] > Sent: Friday, June 15, 2012 8:08 PM > To: [hidden email] > Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 > > Schwab,Wilhelm K wrote > > > > But if I'm building a new image *today*, I want it to do the right thing > > now (automatically for the current version), with the same incantation as > > worked months ago or months from now. > > Absolutely! Two things about that: > * Metacello has no magic. Ultimately, what you correctly suggest requires > someone to test a project on a new platform and update the config... coming > soon and desperately needed: tools to help this process... > * we're all learning how to use Metacello... even as it evolves underneath > us! > > If you experience something other than above, please post the specific > example so we can examine the configs and see what's going on... > > -- > View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… > To unsubscribe from start thinking on summer release of Pharo 1.4, click here. > NAML -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 16, 2012