April 2011 - Pharo-users - lists.pharo.org

Re: [Pharo-users] mouse buttons in Linux, deleting certain morphs

by Mariano Martinez Peck

In Settings -> System -> Keyboard -> Control and Alt keys there are a couple of options, included "swapped". Maybe something there helps ? Cheers Mariano On Wed, Apr 13, 2011 at 7:36 PM, Sven Crouse <sven(a)boatverk.com> wrote: > Hi list. On a Linux host with default mouse mappings in X ( "Button > Left"=1, "Button Middle"=2, "Button Right"=3 ) is there a setting to > enable the Right Button as blue button without requiring the control > key ? > > Regardless, I'm unable to delete certain morphs ( e.g. RectangleMorph, > EllipseMorph ) in the World using the CTRL right-mouse button. To > reproduce create a RectangleMorph in the World and try to delete > interactively. > > Sven > > > -- Mariano http://marianopeck.wordpress.com

April 13, 2011

mouse buttons in Linux, deleting certain morphs

by Sven Crouse

Hi list. On a Linux host with default mouse mappings in X ( "Button Left"=1, "Button Middle"=2, "Button Right"=3 ) is there a setting to enable the Right Button as blue button without requiring the control key ? Regardless, I'm unable to delete certain morphs ( e.g. RectangleMorph, EllipseMorph ) in the World using the CTRL right-mouse button. To reproduce create a RectangleMorph in the World and try to delete interactively. Sven

April 13, 2011

Re: [Pharo-users] TestCase question

by Sven Van Caekenberghe

On 13 Apr 2011, at 10:00, Marcus Denker wrote: > I like this method: > > mystery > 'mystery' isString ifTrue: ['mystery' become: {0}]. > 'mystery' at: 1 put: 'mystery' first + 1. > ^ 'mystery' first. And you were trying to help newcomers or scare them off ? ;-) This is actually a problem in many languages. It is always better to not touch literals (constants is a dangerour word here).

April 13, 2011

Re: [Pharo-users] TestCase question

by Marcus Denker

On Apr 13, 2011, at 5:31 AM, Pat Maddox wrote: > On Apr 12, 2011, at 3:24 PM, Simon Denier wrote: > >> >> On 12 avr. 2011, at 23:47, Werner Kassens wrote: >> >>> hi, >>> i have a testsuite that is a subclass of TestCase with this method: >>> >>> testStupid >>> |a| >>> a :=#(1). >>> self assert: a first isNumber . >>> a :=a at:1 put: nil. >>> >>> if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? >> >> >> Interesting, I would never have guessed the test would be broken at first sight. So maybe some people enlightened in the ways of the compiler can provide a better explanation than me. Here is my guess: >> >> #(1) is a special construct which creates a compile-time array. The compile-time makes the trick: in short the array is more or less encoded directly into the bytecodes of the method as a constant. >> But modifying the array with #at:put: directly modifies the bytecodes in the compiled method itself. So you create a side-effect directly into your method. >> >> Am I the only one to find this a bit dangerous and not intuitive? Is it a well-known behavior? > > I would never have guessed that in a million years. > I like this method: mystery 'mystery' isString ifTrue: ['mystery' become: {0}]. 'mystery' at: 1 put: 'mystery' first + 1. ^ 'mystery' first. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 13, 2011

Re: [Pharo-users] TestCase question

by StÃ©phane Ducasse

> >> hi, >> i have a testsuite that is a subclass of TestCase with this method: >> >> testStupid >> |a| >> a :=#(1). >> self assert: a first isNumber . >> a :=a at:1 put: nil. >> >> if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? > > > Interesting, I would never have guessed the test would be broken at first sight. So maybe some people enlightened in the ways of the compiler can provide a better explanation than me. Here is my guess: > > #(1) is a special construct which creates a compile-time array. The compile-time makes the trick: in short the array is more or less encoded directly into the bytecodes of the method as a constant. > But modifying the array with #at:put: directly modifies the bytecodes in the compiled method itself. So you create a side-effect directly into your method. > > Am I the only one to find this a bit dangerous and not intuitive? Is it a well-known behavior? It is clearly ugly. Here what you see is a modification of the literal object that is stored in the compiled method literal frame. This is a well know limit of Smalltalk implementation. Having immutable literal objects may solve this problem. You get the same if you modify a string since this is a container of characters. This is like the optimization of similar literal strings that breaks the fact that 'foo' == 'foo' return false. normally yes this is false but when on the same method you get the same literal. Stef

April 13, 2011

Re: [Pharo-users] TestCase question

by StÃ©phane Ducasse

>>> >> >> >> Interesting, I would never have guessed the test would be broken at first sight. So maybe some people enlightened in the ways of the compiler can provide a better explanation than me. Here is my guess: >> >> #(1) is a special construct which creates a compile-time array. The compile-time makes the trick: in short the array is more or less encoded directly into the bytecodes of the method as a constant. >> But modifying the array with #at:put: directly modifies the bytecodes in the compiled method itself. So you create a side-effect directly into your method. >> >> Am I the only one to find this a bit dangerous and not intuitive? Is it a well-known behavior? > > I would never have guessed that in a million years. welcome to the time traveling machine it is a bit ugly and nobody should rely on such bad behavior. Consider that it should not exist. Stef

April 13, 2011

Re: [Pharo-users] TestCase question

by Pat Maddox

On Apr 12, 2011, at 3:24 PM, Simon Denier wrote: > > On 12 avr. 2011, at 23:47, Werner Kassens wrote: > >> hi, >> i have a testsuite that is a subclass of TestCase with this method: >> >> testStupid >> |a| >> a :=#(1). >> self assert: a first isNumber . >> a :=a at:1 put: nil. >> >> if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? > > > Interesting, I would never have guessed the test would be broken at first sight. So maybe some people enlightened in the ways of the compiler can provide a better explanation than me. Here is my guess: > > #(1) is a special construct which creates a compile-time array. The compile-time makes the trick: in short the array is more or less encoded directly into the bytecodes of the method as a constant. > But modifying the array with #at:put: directly modifies the bytecodes in the compiled method itself. So you create a side-effect directly into your method. > > Am I the only one to find this a bit dangerous and not intuitive? Is it a well-known behavior? I would never have guessed that in a million years. Pat

April 13, 2011

Re: [Pharo-users] TestCase question

by Werner Kassens

ah, got it! thanks werner

April 12, 2011

Re: [Pharo-users] TestCase question

by Simon Denier

On 12 avr. 2011, at 23:47, Werner Kassens wrote: > hi, > i have a testsuite that is a subclass of TestCase with this method: > > testStupid > |a| > a :=#(1). > self assert: a first isNumber . > a :=a at:1 put: nil. > > if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? Interesting, I would never have guessed the test would be broken at first sight. So maybe some people enlightened in the ways of the compiler can provide a better explanation than me. Here is my guess: #(1) is a special construct which creates a compile-time array. The compile-time makes the trick: in short the array is more or less encoded directly into the bytecodes of the method as a constant. But modifying the array with #at:put: directly modifies the bytecodes in the compiled method itself. So you create a side-effect directly into your method. Am I the only one to find this a bit dangerous and not intuitive? Is it a well-known behavior? A correct way to fix that would be to use a dynamic array {1} or define a setUp method which would initialize the array before each run. -- Simon Denier

April 12, 2011

Re: [Pharo-users] TestCase question

by Sven Van Caekenberghe

Hi Werner, On 12 Apr 2011, at 23:47, Werner Kassens wrote: > hi, > i have a testsuite that is a subclass of TestCase with this method: > > testStupid > |a| > a :=#(1). > self assert: a first isNumber . > a :=a at:1 put: nil. > > if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? > > werner You are destructively modifying a constant, the literal array #(1), of which there is one instance attached to #testStupid'd compiled method. Sven

April 12, 2011

TestCase question

by Werner Kassens

hi, i have a testsuite that is a subclass of TestCase with this method: testStupid |a| a :=#(1). self assert: a first isNumber . a :=a at:1 put: nil. if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? werner

April 12, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by StÃ©phane Ducasse

> > Ah I thought that all code pushed to PharoInbox was already MIT by default. yes it is but we are paranoid and serious about it :) > Anyway I think I found the license agreement. Is this one still up-to-date? > <http://pharo.gforge.inria.fr/licenseDocuments/PharoSoftwareDistributionAgreement.pdf> > > And is the fax number listed there i.e. 00 33 3 59 57 78 5 still the right > one? you are missing a digit Fax 33 3 59 57 78 50 > I will fax it over today. > > Thanks! > > -- > Nick > > > -- > View this message in context: http://forum.world.st/Code-Navigation-Navigation-History-in-System-Browser-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > ------------------------ Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) INRIA - USTL - CNRS UMR 8022 stephane.ducasse(a)inria.fr http://stephane.ducasse.free.fr http://rmod.lille.inria.fr/ **NEW ***Tel 00 33 (0)3 20 43 42 56 - Fax 33 3 59 57 78 50 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France.

April 12, 2011

Re: [Pharo-users] [Seaside] [ANN] Seaside Tutorial Ready for 3.0

by Mariano Martinez Peck

This was the first tutorial I read and it was really nice. Thanks a lot for this. Mariano ---------- Forwarded message ---------- From: Michael Perscheid <michaelperscheid(a)googlemail.com> Date: Tue, Apr 12, 2011 at 3:21 PM Subject: [Seaside] [ANN] Seaside Tutorial Ready for 3.0 To: seaside(a)lists.squeakfoundation.org Hi all, I would like to announce that we have updated the Seaside tutorial of the Software Architecture Group ( http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial) Now it can be applied with the current Seaside 3.0 version without any problems. Besides a revision of all chapters, we have especially changed the persistence chapter and added new sections about SandstoneDB, PostgreSQL, and GemStone. Most of the update was done by Lauritz Thamsen and Tobias Pape. Thank you very much. If you have any feedback, please let us know. Best regards, Michael Perscheid _______________________________________________ seaside mailing list seaside(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- Mariano http://marianopeck.wordpress.com

April 12, 2011

Updated O2 for Pharo 1.2 [WAS] Re: Code Navigation: Navigation History in System Browser?

by Mariano Martinez Peck

> > Agreed. I've invested just a few hours already so I decided to just finish > it > up. I've made the proposed fix available at > http://code.google.com/p/pharo/issues/detail?id=3992. Perhaps some other > people > might find it useful. Perhaps not, but that's OK too. :-) > > Sure. > -- > Nick > > -- > View this message in context: > http://forum.world.st/Code-Navigation-Navigation-History-in-System-Browser-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

April 12, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by Nick Chen

StÃ©phane Ducasse wrote: > > excellent! > > Nick did you sign the license agreement. > > Stef > Ah I thought that all code pushed to PharoInbox was already MIT by default. Anyway I think I found the license agreement. Is this one still up-to-date? <http://pharo.gforge.inria.fr/licenseDocuments/PharoSoftwareDistributionAgreement.pdf> And is the fax number listed there i.e. 00 33 3 59 57 78 5 still the right one? I will fax it over today. Thanks! -- Nick -- View this message in context: http://forum.world.st/Code-Navigation-Navigation-History-in-System-Browser-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 12, 2011

Re: [Pharo-users] Help with TreeListMorph

by Adrien BARREAU

I'll take a look. Thanks ;) Adrien. From: benjamin.vanryseghem.pharo(a)gmail.com Date: Tue, 12 Apr 2011 13:12:06 +0200 To: pharo-users(a)lists.gforge.inria.fr Subject: Re: [Pharo-users] Help with TreeListMorph I think you should take a look at expand:to: and siblings in SimpleHierarchicalList ( the TreeListMorph's superclass) I think it's around :) Ben On Apr 11, 2011, at 10:03 PM, Adrien BARREAU wrote:Hi, I'm taking a look at the FileDialogWindow: FileDialogWindow new open. On the left, there is a tree. With the halo, I know it is a TreeListMorph. Here is my question: How can I know what is happening when I click on one of the little arrows which are just on the left of a directory name? With my changes, the subtree is very slow to be displayed and I don't understand what is called. Adrien.

April 12, 2011

Re: [Pharo-users] Help with TreeListMorph

by Benjamin

I think you should take a look at expand:to: and siblings in SimpleHierarchicalList ( the TreeListMorph's superclass) I think it's around :) Ben On Apr 11, 2011, at 10:03 PM, Adrien BARREAU wrote: > Hi, > > I'm taking a look at the FileDialogWindow: > FileDialogWindow new open. > > On the left, there is a tree. With the halo, I know it is a TreeListMorph. > Here is my question: > > How can I know what is happening when I click on one of the little arrows which are just on the left of a directory name? With my changes, the subtree is very slow to be displayed and I don't understand what is called. > > Adrien.

April 12, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by StÃ©phane Ducasse

excellent! Nick did you sign the license agreement. Stef On Apr 12, 2011, at 7:44 AM, Nick Chen wrote: > > StÃ©phane Ducasse wrote: >> >>>> >>> Thanks Stef and Ben. I did get it to work with the latest Pharo-1.3 core. >>> It >>> has >>> a clean interface that I look forward to using it when it becomes >>> official. >>> >>> I am not familiar enough with the Pharo Core -> Pharo Dev process so I >>> was >>> not able to get the Mercury Panel (if it works in Nautilus), the >>> refactoring >>> tools and navigation history to work. >> >> it does not. >> Ben will add refactoring support soon (matter of menus), navigation and >> search. >> > > OK. I'll keep an eye on Nautilus. It is always nice to see changes being > made to > the browser to make it more the UI more functional and up-to-date. > > > >>> Actually, the project that I'm currently on also makes uses of some of >>> the >>> underlying components in Pharo-1.2 like Morphs and Editors so I can't >>> really >>> use the bleeding edge in Pharo-1.3. But I would like to use it soon. So >>> some >>> questions for you as core developers: >>> >>> 1) Do you have a API for Pharo-1.2? I know that you can do WorldMenu > >>> Help >>> and browse to Pharo > API Reference but there is nothing official there >>> stating that those are the "official" APIs. >> >> not that I know :) >> >>> 2) When do you expect to have an API freeze for Pharo-1.3? That way I can >>> start porting what we to make sure that it works. >> >> 1.3 is stable, really stable. >> > > I'll post on the mailing list if I have specific questions about the > components > that I'm using. > > > >>> Anyway back to O2. I'm in the process of getting the O2 packages to work. >>> I've >>> gotten them to load for the most part and from my own use they seem to >>> work. >>> I'll try to make the remaining failing/error tests pass and then post my >>> initial changes. I already know that some things don't work like >>> undo/redo but I (or >>> someone else) can fix those later. >> >> I would not invest on O2. This is the past and it bends too much OB so >> have a >> look at nautilus the groups are working much better. >> >> Stef >> >> > > Agreed. I've invested just a few hours already so I decided to just finish > it > up. I've made the proposed fix available at > http://code.google.com/p/pharo/issues/detail?id=3992. Perhaps some other > people > might find it useful. Perhaps not, but that's OK too. :-) > > -- > Nick > > -- > View this message in context: http://forum.world.st/Code-Navigation-Navigation-History-in-System-Browser-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

April 12, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by StÃ©phane Ducasse

On Apr 11, 2011, at 10:58 PM, Marcus Denker wrote: > > On Apr 11, 2011, at 10:49 PM, StÃ©phane Ducasse wrote: > >> >>> >>>>> 2) When do you expect to have an API freeze for Pharo-1.3? That way I can >>>>> start porting what we to make sure that it works. >>>> >>>> 1.3 is stable, really stable. >>> >>> >>> Quick question, what are the major changes planned for 1.3 and what is the (dreamed of/ideal/...) release plan? The website does not say anything ... >> >> we were planning for >> - FileSystem but not sure it will be there may be loaded but not integrated >> - Rpackage but I need to take some time to concentrate for real >> - new browser but it depends on RPackage >> - Opal but there are still missing parts. > > So I wonder if we don't do a quick 1.3 release with out Rpackage and Opal. Form my side Opal definitly should not be in the critical path of the > 1.3 release, if we talk about a quick release soon. yes this was my impression too. > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > >

April 12, 2011

Re: [Pharo-users] [Pharo-project] Metacello chapter

by StÃ©phane Ducasse

If you have english mistake please send them. On Apr 11, 2011, at 11:00 PM, Pat Maddox wrote: > On Apr 6, 2011, at 5:49 AM, Davorin Rusevljan wrote: > >>> On Wed, Apr 6, 2011 at 9:58 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>>> >>>> Hi guys >>>> >>>> here is a new version of the metacello chapter. >>>> So we wrote it, rewrote it, rerewrote it. >>>> Now if this is of interest for you you can read it. >>>> >>>> But if you don't it means that I'm losing my time and I should stop >>>> writing and like >>>> that you can cry that there is no doc about Pharo. >> >> Stef thanks! It has cleared quite a few things in my head. > > Same here. The "Development Cycle Walk Through" section is particularly helpful. I haven't typed the code in, but reading through it I feel ready to tackle a Metacello config on my projects. Thank you for documenting this important tool. > > Pat

April 12, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by Nick Chen

StÃ©phane Ducasse wrote: > >>> >> Thanks Stef and Ben. I did get it to work with the latest Pharo-1.3 core. >> It >> has >> a clean interface that I look forward to using it when it becomes >> official. >> >> I am not familiar enough with the Pharo Core -> Pharo Dev process so I >> was >> not able to get the Mercury Panel (if it works in Nautilus), the >> refactoring >> tools and navigation history to work. > > it does not. > Ben will add refactoring support soon (matter of menus), navigation and > search. > OK. I'll keep an eye on Nautilus. It is always nice to see changes being made to the browser to make it more the UI more functional and up-to-date. >> Actually, the project that I'm currently on also makes uses of some of >> the >> underlying components in Pharo-1.2 like Morphs and Editors so I can't >> really >> use the bleeding edge in Pharo-1.3. But I would like to use it soon. So >> some >> questions for you as core developers: >> >> 1) Do you have a API for Pharo-1.2? I know that you can do WorldMenu > >> Help >> and browse to Pharo > API Reference but there is nothing official there >> stating that those are the "official" APIs. > > not that I know :) > >> 2) When do you expect to have an API freeze for Pharo-1.3? That way I can >> start porting what we to make sure that it works. > > 1.3 is stable, really stable. > I'll post on the mailing list if I have specific questions about the components that I'm using. >> Anyway back to O2. I'm in the process of getting the O2 packages to work. >> I've >> gotten them to load for the most part and from my own use they seem to >> work. >> I'll try to make the remaining failing/error tests pass and then post my >> initial changes. I already know that some things don't work like >> undo/redo but I (or >> someone else) can fix those later. > > I would not invest on O2. This is the past and it bends too much OB so > have a > look at nautilus the groups are working much better. > > Stef > > Agreed. I've invested just a few hours already so I decided to just finish it up. I've made the proposed fix available at http://code.google.com/p/pharo/issues/detail?id=3992. Perhaps some other people might find it useful. Perhaps not, but that's OK too. :-) -- Nick -- View this message in context: http://forum.world.st/Code-Navigation-Navigation-History-in-System-Browser-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 12, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by Johan Fabry

On 11 Apr 2011, at 15:57, StÃ©phane Ducasse wrote: >> 2) When do you expect to have an API freeze for Pharo-1.3? That way I can >> start porting what we to make sure that it works. > > 1.3 is stable, really stable. Quick question, what are the major changes planned for 1.3 and what is the (dreamed of/ideal/...) release plan? The website does not say anything ... -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

April 11, 2011

Re: [Pharo-users] [Pharo-project] Metacello chapter

by Pat Maddox

On Apr 6, 2011, at 5:49 AM, Davorin Rusevljan wrote: >> On Wed, Apr 6, 2011 at 9:58 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >>> >>> Hi guys >>> >>> here is a new version of the metacello chapter. >>> So we wrote it, rewrote it, rerewrote it. >>> Now if this is of interest for you you can read it. >>> >>> But if you don't it means that I'm losing my time and I should stop >>> writing and like >>> that you can cry that there is no doc about Pharo. > > Stef thanks! It has cleared quite a few things in my head. Same here. The "Development Cycle Walk Through" section is particularly helpful. I haven't typed the code in, but reading through it I feel ready to tackle a Metacello config on my projects. Thank you for documenting this important tool. Pat

April 11, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by Marcus Denker

On Apr 11, 2011, at 10:49 PM, StÃ©phane Ducasse wrote: > >> >>>> 2) When do you expect to have an API freeze for Pharo-1.3? That way I can >>>> start porting what we to make sure that it works. >>> >>> 1.3 is stable, really stable. >> >> >> Quick question, what are the major changes planned for 1.3 and what is the (dreamed of/ideal/...) release plan? The website does not say anything ... > > we were planning for > - FileSystem but not sure it will be there may be loaded but not integrated > - Rpackage but I need to take some time to concentrate for real > - new browser but it depends on RPackage > - Opal but there are still missing parts. So I wonder if we don't do a quick 1.3 release with out Rpackage and Opal. Form my side Opal definitly should not be in the critical path of the 1.3 release, if we talk about a quick release soon. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 11, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by StÃ©phane Ducasse

> >>> 2) When do you expect to have an API freeze for Pharo-1.3? That way I can >>> start porting what we to make sure that it works. >> >> 1.3 is stable, really stable. > > > Quick question, what are the major changes planned for 1.3 and what is the (dreamed of/ideal/...) release plan? The website does not say anything ... we were planning for - FileSystem but not sure it will be there may be loaded but not integrated - Rpackage but I need to take some time to concentrate for real - new browser but it depends on RPackage - Opal but there are still missing parts. - better announcements. Lot of little but important fixes Stef

April 11, 2011