[Pharo-project] Bug in WAMemoryItemsizeOfObject
Hi guys, I haven't checked if this bug exists already, so please ignore this if it's been reported before. Bug in WAMemoryItem: sizeOfObject: anObject | headerSize instanceSize variableSize | headerSize := anObject class indexIfCompact 0 ifTrue: [ 4 ] ifFalse: [ 8 ]. instanceSize := anObject class instSize. variableSize := anObject class isBytes ifTrue: [ anObject basicSize ] ifFalse: [ anObject class isWords ifTrue: [ Smalltalk wordSize * anObject basicSize ] ifFalse: [ Smalltalk wordSize * anObject basicSize // 2 ] ]. ^ headerSize + instanceSize + variableSize In this snippet, the units that are added together in the last line are of different units. instanceSize is in unit number of machine words, whereas variableSize and headerSize are in unit bytes. The method is fixed here: sizeOfObject: anObject | headerSize instanceSize variableSize | headerSize := anObject class indexIfCompact 0 ifTrue: [ 4 ] ifFalse: [ 8 ]. instanceSize := anObject class instSize * Smalltalk wordSize. variableSize := anObject class isBytes ifTrue: [ anObject basicSize ] ifFalse: [ anObject class isWords ifTrue: [ Smalltalk wordSize * anObject basicSize ] ifFalse: [ Smalltalk wordSize * anObject basicSize // 2 ] ]. ^ headerSize + instanceSize + variableSize Example: |m| dict := Dictionary new. m := WAMemory new. dict traverseWithMemory: m seen: IdentitySet new. m totalSize This will incorrectly spit out 10, but should return 16, on a 32 bit VM. Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
[Pharo-project] How can I find all objects that reference myObject?
Hi, How can I find all objects that reference myObject? http://stackoverflow.com/questions/8164418/how-can-i-find-all-objects-that-reference-myobject Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
[Pharo-project] Symbolvalue:
Hi, Symbol responds to #value:, but not to #value:value:. At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows: value: anObject value: anotherObject ^ anObject perform: self with: anotherObject Of course, it should also respond to #value:value:value: and #value:value:value:value: Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
Re: [Pharo-project] Symbolvalue:
I think it's important to have a consistent answer to the question: Can you treat symbols as blocks?. Niko On Tue, Aug 30, 2011 at 2:30 PM, Tudor Girba tu...@tudorgirba.com wrote: I proposed this some one or two years ago. I got shut down, but I still find it a good idea. And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input. From this point of view, they have similar responsibilities and we should be able to treat them the same. Cheers, Doru On 30 Aug 2011, at 14:12, niko.schw...@googlemail.com wrote: Hi, Symbol responds to #value:, but not to #value:value:. At some point, Symbol and Block were decided to have the invocation protocol in common. I find this great. Therefore, I think, Symbol should also respond to #value:value:, as follows: value: anObject value: anotherObject ^ anObject perform: self with: anotherObject Of course, it should also respond to #value:value:value: and #value:value:value:value: Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354 -- www.tudorgirba.com Speaking louder won't make the point worthier. -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
Re: [Pharo-project] Symbolvalue:
On Tue, Aug 30, 2011 at 3:59 PM, Sven Van Caekenberghe s...@beta9.be wrote: #+ value: 1 value: 2 1 perform: #+ with: 2 Note that the last two expressions are equally short/concise, the second being clearer. That is not a comparison worth making. The fair comparison is: [:a :b | a + b] vs #+ Now, I'd say, the second is clearer. With it, Pharo gains support for Tacit programming [1]. Niko [1] http://en.wikipedia.org/wiki/Tacit_programming -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
Re: [Pharo-project] Symbolvalue:
persons inject: OrderedCollection new into: [:col :p | col copyWith: p] persons inject: OrderedCollection new into: #copyWith: Or this one: #(3 2 1) asSortedCollection: [:a :b | a = b] #(3 2 1) asSortedCollection: #=
Re: [Pharo-project] Symbolvalue:
You just inspired me to a block post on point-free programming :)
http://smalltalkthoughts.blogspot.com/2011/08/point-free-programming-in-smalltalk.html
Niko
On 30.08.2011, at 16:57, HwaJong Oh wrote:
I have similar definitions from symbol to block for SortedCollection like;
#('3' '20' '100') asSortedCollection: #size ascendingSortBlock. #('3' '20'
'100')
#size ascendingSortBlock evaluates to be [:a :b| (a perform: #size) = (b
perform:#size) ]
#('3' '20' '100') asSortedCollection: #size descendingSortBlock. #('100'
'20' '3')
Similarly, following can be done
#('3' '20' '100') asSortedCollection: #first ascendingSortBlock.
#('3' '20' '100') asSortedCollection: #first descendingSortBlock.
--
View this message in context:
http://forum.world.st/Symbol-value-tp3778525p3778943.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
--
http://scg.unibe.ch/staff/Schwarz
twitter.com/nes1983
Tel: +41786126354
Re: [Pharo-project] Symbolvalue:
It's a question of consistency. Why support value:, but not value:value:? Niko On Tue, Aug 30, 2011 at 7:45 PM, Igor Stasenko siguc...@gmail.com wrote: On 30 August 2011 18:02, Douglas Brebner squeakli...@fang.demon.co.uk wrote: On 30/08/2011 13:30, Tudor Girba wrote: I proposed this some one or two years ago. I got shut down, but I still find it a good idea. And I even have a semantic reason: - A Block represents a piece of functionality that can be evaluated with some input - A Symbol often represents a selector which in turns represents a piece of functionality that can be evaluated with some input. I seem to recall there was discussion some time ago about splitting Selector functionality from Symbol. After all, there's no real reason that a selector has to be a Symbol. Selector is just a role to identify a method in method's dictionary. It can be any object: if you look how VM does a lookup there's nothing which limits a selectors to be the instances of Symbol (perhaps the only thing is printing a stack trace ;). What i mean that any object may be a selector: MyClass methodDict at: 1 put: someMethod. MyClass new perform: 1 should work. So, i don't see what you can gain by splitting functionality of Selector from Symbol. Then you should put all selector-related protocol to Object class. And this even worse idea :) Also, some of the examples in this thread seem to be about terseness for terseness sake. Yeah. I have same impression. But its cool :) -- Best regards, Igor Stasenko AKA sig. -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
Re: [Pharo-project] Phexample integrated with Autotest and OB (was ConfigurationOfPhexample (was #assert:equals: feels backwards))
Hi Sean! Phexample doesn't duplicate the logic of what is a change method, it changes it. The rational is to allow the user to choose a speaking test name, that accurately describes the test: shouldNicelyHandleNotifications And the like. Is this really in conflict with OB? Niko On 24.06.2011, at 21:01, Sean P. DeNigris wrote: You can now have Phexample playing nicely with OB and Autotest... * Autotest - I uploaded a new package (Autotest-Core-SeanDeNigris.5) that will pick up Phexample and any other framework that defines tests differently (it uses the class's #allTestSelectors method). * OB - I uploaded a slice to the Pharo inbox that does the same for OB (SLICE-Issue-4449-Feature-OB-can-handle-arbitrarily-defined-test-selectors-SeanDeNigris.1). All it took was removing some duplication in the system - TestCase, Autotest, and OB were all repeating the what is a test method logic. HTH, Sean -- View this message in context: http://forum.world.st/Phexample-integrated-with-Autotest-and-OB-was-ConfigurationOfPhexample-was-assert-equals-feels-backw-tp3623325p3623325.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41786126354
Re: [Pharo-project] posting etiquette - please post new text at the *top* of your email
I remember that alright. On some Usenet groups you'd get stoned to death if you were to fullquote at the bottom. Postings like that we'd call TOFU in Germanglish: (Text oben, Fullquote unten), and it was a major offense to submit TOFU. And the holy scripture was RFC 1855 (http://tools.ietf.org/html/rfc1855), Content of a follow-up post should exceed quoted content. Today, just about everybody you commonly meet writes TOFU, unless they've had a usenet history. And keep in mind that quoting according to RFC 1855 is more than just changing order: you carefully select the lines you wish to quote (never more than 4 lines at ones, never quote greetings), you begin your email with a greeting above the quote section, and so forth. I think RFC1855-style messages still look beautiful, and they have their place. But if you're too lazy to follow the gist of it, that's alright with me, but then put your content at the top, so I don't have to scroll down to Walhalla. Niko On Wed, Oct 27, 2010 at 7:29 PM, Ramon Leon ramon.l...@allresnet.com wrote: On 10/27/2010 7:16 AM, Douglas Brebner wrote: Or even better, cut out the irrelevant quoted text :) Yes please, as top posting is *not* good etiquette, but that's an old flame war. -- Ramon Leon http://onsmalltalk.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 078 612 6354
Re: [Pharo-project] posting etiquette - please post new text at the *top* of your email
Markus, try to change the first line of the footer, which currently is ___ to -- \n Yes, including the space before the linebreak. Many email clients to this date will not quote what comes after this so-called sig separator. AAMOF, I advise everybody to prefix his signature with it. Niko On Thu, Oct 28, 2010 at 9:30 AM, Marcus Denker marcus.den...@inria.fr wrote: On Oct 27, 2010, at 9:12 PM, Martin McClure wrote: Quoting the part of the email to which we are replying allows us to make the reply shorter, and the email is much easier to understand, saving readers time. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project To help a little, I configured the list to not have the footer anymore. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 078 612 6354
Re: [Pharo-project] About Adding/modifying in SUnit or not?
I completely agree. If we take charge of SUnit, it ought to stay backwards compatible. The new things we can put into extensions. On Mon, Oct 25, 2010 at 4:07 PM, Lukas Renggli reng...@gmail.com wrote: I am all in for improving SUnit, but there must be some compatibility mode that makes it easy not only to run, but also to write tests on the official SUnit. This is crucial for projects like Seaside, Magritte, Pier, PetitParser, ... that are supposed to work on various other Smalltalk platforms. Lukas On 25 October 2010 15:51, Niko Schwarz niko.schw...@googlemail.com wrote: Yea, well, it depends on whether we want to be compatible with camp smalltalk's SUnit, as maintained by Niall Ross: http://sunit.sourceforge.net/devel.htm. Pharo already is using extensions, such as the possibility to mark tests as expected failures at all (that is impossible in standard SUnit). My humble opinion is that we must control our testing environment, and we already have an excellent cleanup of SUnit, namely akuhn/SUnit, http://www.squeaksource.com/akuhn.html. And we have progress in the form of Phexample, which builds ontop of SUnit. http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-expand-on.html . I'd be more than happy if Pharo took a new SUnit as its standard testing framework, and I'd even be thrilled if enough people found Phexample useful enough, so that it could become standard over time. Niko 2010/10/25 Luc Fabresse luc.fabre...@gmail.com: Hi all, I am working on pushing environments in SystemNavigation. SystemNavigationTest previously used ClassFactoryForTestCase from SUnit for generating classes. Now I need an environment-aware ClassFactoryForTestCase. Should I directly modify ClassFactoryForTestCase since a class generator should now be environment aware? Should I subclass ClassFactoryForTestCase and put it in SUnit? Should I never changed SUnit and put it elsewhere? ;-) #Luc ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] akuhn/SUnit: run faster tests first step through tests
Couldn't Adrian be the maintainer? I could step in, too. I don't really know what you have in mind for a testing framework. We have our own independent and fully compatible fork of SUnit: akuhn/SUnit, which is quite a strong code basis. And on top of that we have Phexample, which has its own name, some extra features and gives a clear point where Pharo is different from the rest. Just a suggestion: Let Adrian maintain akuhn/SUnit, perhaps minus the should syntax that you don't like (as in: #(a b c) size should = 3), and make akuhn/SUnit part of Pharo core. The new features (having tests depend on one another, should syntax) go into Phexample, and I could maintain that. Cheers, Niko On Sun, Oct 24, 2010 at 8:37 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Lack of maintainers, too many unwanted features, lack of explanation, large changes... And this is not that several persons did not look at the code. It got more than the average. Now I'm thinking that with discussion and care we should really get another testing framework with the same API that SUnit because if we want that PharoSunit is the same as Sunit then we are doomed to be backward compatible and no real improvements. Stef On Oct 23, 2010, at 10:58 PM, Adrian Kuhn wrote: Sad to hear that. Technical difficulties, or just lack of customers? ^^ --AA On Oct 23, 2010, at 08:05 , Stéphane Ducasse wrote: It was too difficult to integrate. Stef On Oct 23, 2010, at 2:01 PM, Niko Schwarz wrote: What's the status of akuhn/SUnit? I couldn't find his code in 1.2 core. Niko On Wed, Feb 3, 2010 at 1:13 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: this loads well in the latest 1,1 core :) so now we should really have a look and these cool changes Stef On Jan 6, 2010, at 2:38 PM, Adrian Kuhn wrote: SystemChangeNotifier uniqueInstance noMoreNotificationsFor: TestCase. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About Adding/modifying in SUnit or not?
Yea, well, it depends on whether we want to be compatible with camp smalltalk's SUnit, as maintained by Niall Ross: http://sunit.sourceforge.net/devel.htm. Pharo already is using extensions, such as the possibility to mark tests as expected failures at all (that is impossible in standard SUnit). My humble opinion is that we must control our testing environment, and we already have an excellent cleanup of SUnit, namely akuhn/SUnit, http://www.squeaksource.com/akuhn.html. And we have progress in the form of Phexample, which builds ontop of SUnit. http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-expand-on.html . I'd be more than happy if Pharo took a new SUnit as its standard testing framework, and I'd even be thrilled if enough people found Phexample useful enough, so that it could become standard over time. Niko 2010/10/25 Luc Fabresse luc.fabre...@gmail.com: Hi all, I am working on pushing environments in SystemNavigation. SystemNavigationTest previously used ClassFactoryForTestCase from SUnit for generating classes. Now I need an environment-aware ClassFactoryForTestCase. Should I directly modify ClassFactoryForTestCase since a class generator should now be environment aware? Should I subclass ClassFactoryForTestCase and put it in SUnit? Should I never changed SUnit and put it elsewhere? ;-) #Luc ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] akuhn/SUnit: run faster tests first step through tests
What's the status of akuhn/SUnit? I couldn't find his code in 1.2 core. Niko On Wed, Feb 3, 2010 at 1:13 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: this loads well in the latest 1,1 core :) so now we should really have a look and these cool changes Stef On Jan 6, 2010, at 2:38 PM, Adrian Kuhn wrote: SystemChangeNotifier uniqueInstance noMoreNotificationsFor: TestCase. Gofer it disablePackageCache; squeaksource: 'akuhn'; package: 'SUnit'; package: 'SUnitGUI'; load. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ExpectedFailures in SUnit
I created an issue and submitted a fix: http://code.google.com/p/pharo/issues/detail?id=3143 Niko On Wed, Oct 20, 2010 at 3:48 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: +1 the problem is that we should sync with nial for SUNit but since brest I do not know what really make progress. I still want to know the status of a test. what is red or not when it was packaged and shipped or is is my system the problem Stef On Oct 20, 2010, at 1:41 PM, Mariano Martinez Peck wrote: On Wed, Oct 20, 2010 at 12:15 PM, Niko Schwarz niko.schw...@googlemail.com wrote: Hi, Currently, to mark a test as an expected failure, `expectedFailures` should be overwritten (http://stackoverflow.com/questions/3976596/how-to-mark-expected-failures-in-sunit). That's a bit tricky to figure out, so I added a comment to the method: SUnit-NikoSchwarz.114. However, I think it's still a usability bug: marking something as an expectedFailure isn't visible inside the test. I think expectedFailures should look through the pragmas of its tests and return an array of all method names that contain the pragma expectedFailure. Yes, that's better. But in addition, sometimes we need conditions. For example: Smalltalk listPlugins contains: 'blahhh' ifFalse[ expectedFailures add: 'testBlah' ] or whatever condition. Can you do that with pragmas? the other problem is that we don't have expectedErrors as well. This is bad and confusing. cheers mariano Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] ExpectedFailures in SUnit
Hi, Currently, to mark a test as an expected failure, `expectedFailures` should be overwritten (http://stackoverflow.com/questions/3976596/how-to-mark-expected-failures-in-sunit). That's a bit tricky to figure out, so I added a comment to the method: SUnit-NikoSchwarz.114. However, I think it's still a usability bug: marking something as an expectedFailure isn't visible inside the test. I think expectedFailures should look through the pragmas of its tests and return an array of all method names that contain the pragma expectedFailure. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] RefactoringcheckPreconditions behaves funny about the errorBlock
Hi, The RB refactorings do some obscure dance around an errorBlock, which is always nil, as far as I can see. As I was trying to supply a non-nil error block, I was astonished to find out that even if it isn't nil, it won't be executed. Here's the relevant snippets: checkPreconditions | conditions block | conditions := self preconditions. conditions check ifFalse: [block := conditions errorBlock. block notNil ifTrue: [self refactoringError: conditions errorString with: block] ifFalse: [self refactoringError: conditions errorString]] refactoringError: aString with: aBlock ^ RefactoringError signal: aString with: aBlock I can't imagine how that could help anyone. I suggest either removing the errorBlock, or turning it into a good old instance variable, and running it in case of an error. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] RefactoringcheckPreconditions behaves funny about the errorBlock
Ok, help me out, how is that block ever invoked? The above code snippet just appends the block as a parameter to an exception, which looks just funny. Niko On Mon, Oct 4, 2010 at 3:44 PM, Lukas Renggli reng...@gmail.com wrote: See for senders of #errorBlock:, e.g. PushDownInstanceVariableRefactoring, RemoveClassRefactoring or RemoveInstanceRefactoring. On 4 October 2010 15:40, Lukas Renggli reng...@gmail.com wrote: This is used to validate the preconditions of refactorings and inform the user about any mismatches. It should better not be removed. Lukas On 4 October 2010 15:36, Niko Schwarz niko.schw...@googlemail.com wrote: Hi, The RB refactorings do some obscure dance around an errorBlock, which is always nil, as far as I can see. As I was trying to supply a non-nil error block, I was astonished to find out that even if it isn't nil, it won't be executed. Here's the relevant snippets: checkPreconditions | conditions block | conditions := self preconditions. conditions check ifFalse: [block := conditions errorBlock. block notNil ifTrue: [self refactoringError: conditions errorString with: block] ifFalse: [self refactoringError: conditions errorString]] refactoringError: aString with: aBlock ^ RefactoringError signal: aString with: aBlock I can't imagine how that could help anyone. I suggest either removing the errorBlock, or turning it into a good old instance variable, and running it in case of an error. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] RefactoringcheckPreconditions behaves funny about the errorBlock
Ok, let's summarize: If an error occurs, the handler block is not evaluated, but attached to a new exception, that exception is raised. Then, the caller catches that exception, retrieves the handler block, does some more ballyhoo, and then runs the handler block. And you get invited to this construction by these methods in RBAbstractCondition: errorBlock ^self errorBlockFor: false errorBlockFor: aBoolean ^nil We can clean it up on the next sprint, if you want :) Niko On Mon, Oct 4, 2010 at 4:14 PM, Lukas Renggli reng...@gmail.com wrote: The tool that triggers the refactoring, e.g. ORCommand#handleError: Ok, the code is quite ugly, but this is how the original refactoring browser implemented it. On 4 October 2010 16:06, Niko Schwarz niko.schw...@googlemail.com wrote: Ok, help me out, how is that block ever invoked? The above code snippet just appends the block as a parameter to an exception, which looks just funny. Niko On Mon, Oct 4, 2010 at 3:44 PM, Lukas Renggli reng...@gmail.com wrote: See for senders of #errorBlock:, e.g. PushDownInstanceVariableRefactoring, RemoveClassRefactoring or RemoveInstanceRefactoring. On 4 October 2010 15:40, Lukas Renggli reng...@gmail.com wrote: This is used to validate the preconditions of refactorings and inform the user about any mismatches. It should better not be removed. Lukas On 4 October 2010 15:36, Niko Schwarz niko.schw...@googlemail.com wrote: Hi, The RB refactorings do some obscure dance around an errorBlock, which is always nil, as far as I can see. As I was trying to supply a non-nil error block, I was astonished to find out that even if it isn't nil, it won't be executed. Here's the relevant snippets: checkPreconditions | conditions block | conditions := self preconditions. conditions check ifFalse: [block := conditions errorBlock. block notNil ifTrue: [self refactoringError: conditions errorString with: block] ifFalse: [self refactoringError: conditions errorString]] refactoringError: aString with: aBlock ^ RefactoringError signal: aString with: aBlock I can't imagine how that could help anyone. I suggest either removing the errorBlock, or turning it into a good old instance variable, and running it in case of an error. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ('a' == 'a') == true ?
Perhaps interestingly, in the original Self paper promoting mirrors, it was argued that one of the lessons learned of using mirrors in self was that '==' is really a reflective property, that should be accessible only through mirrors. That is because, whether or not two pointers are equal is really a question on the VM level, and not on your business level. Niko On Mon, Sep 27, 2010 at 10:32 AM, Johan Brichau jo...@inceptive.be wrote: I convinced the teacher who will be taking over my Smalltalk courses at UCLouvain (starting this week) to use Pharo :-) One of the introductory exercises in these courses shows the difference between '==' and '='. However, in Pharo (Squeak) the following goes wrong imho: 'a' == 'a' - true $a asString == $a asString - false It seems that when you evaluate the expression, the (semantically identical) strings are represented as the same literal in the compiled block. For example, try to evaluate the following code by evaluating each statement in a separate doit. Then do it again as a single block... |a b| a := 'a'. b := 'a'. a == b inspect Do I make it an issue? Is there already an issue? (did not find one) Am I wrong? Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ('a' == 'a') == true ?
But that's the point, there should be no business semantics to '=='. Only reflective semantics. The reflective semantics are ok. Niko On Mon, Sep 27, 2010 at 11:51 AM, Johan Brichau jo...@inceptive.be wrote: On 27 Sep 2010, at 11:28, Igor Stasenko wrote: On 27 September 2010 11:54, Johan Brichau jo...@inceptive.be wrote: On 27 Sep 2010, at 10:38, Lukas Renggli wrote: Am I wrong? Yes, almost always one should probably use #= instead of #==. I will add that to the exercise :-) The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) I think you can avoid using 'equal' word when describing a #== comparison. It can be explained as 'test whether comparands are same object or not' while #= is test whether two objects equal or not. Yes, this is exactly what the exercise is doing. I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: a := #foobar. b := #foobar. a == b. a := 'foobar'. b := 'foobar'. a == b The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) cheers Johan ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Load OB in Pharo 1.2
Has this been resolved? I still get an error saying that PluggableButtonMorphPlus and OBPluggableButtonMorphPlus define homonymous instance variables. Niko On Wed, Aug 18, 2010 at 9:04 AM, Marcus Denker marcus.den...@inria.fr wrote: On Aug 17, 2010, at 11:16 PM, Lukas Renggli wrote: Or you would keep the empty but deprecated class PluggableButtonMorphPlus in the image and make everybody happy :-) Yes, let's do that... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Instance variable pull up broken
Here's a funny way to crash your image. Works in: Pharo-1.1-11367-Beta Latest update: #11367 Make a class named AbstractBla, with two subclasses: SubA, SubB. Then, add to both SubA and SubB the identically named instance variable: instVar. Now, use the pull up refactoring in OmniBrowser on SubA to pull up instVar into the superclass. As you correctly guess, that breaks SubB, because now both its superclass and SubB have an instance variable named instVar. But, instead of refusing to refactor, OmniBrowser dutifully refactors and takes the image with it. I hope that was understandable. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Instance variable pull up broken
Hmm, I can't reproduce it in a fresh image, either. Sorry for the noise. Niko On Sat, Aug 7, 2010 at 10:39 PM, Lukas Renggli reng...@gmail.com wrote: I cannot reproduce. If you look at the code you should see that what you describe should not happen: transform class allSubclasses do: [:each | (each directlyDefinesInstanceVariable: variableName) ifTrue: [each removeInstanceVariable: variableName]]. class addInstanceVariable: variableName Maybe your class hierarchy is broken? Lukas On 7 August 2010 22:18, Niko Schwarz niko.schw...@googlemail.com wrote: Here's a funny way to crash your image. Works in: Pharo-1.1-11367-Beta Latest update: #11367 Make a class named AbstractBla, with two subclasses: SubA, SubB. Then, add to both SubA and SubB the identically named instance variable: instVar. Now, use the pull up refactoring in OmniBrowser on SubA to pull up instVar into the superclass. As you correctly guess, that breaks SubB, because now both its superclass and SubB have an instance variable named instVar. But, instead of refusing to refactor, OmniBrowser dutifully refactors and takes the image with it. I hope that was understandable. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ReadWriteStream contents fails
I got confused about this because of what printString shows. At least printString could show what is intended to be in the stream, not more. Niko 2010/6/11 Henrik Sperre Johansen henrik.s.johan...@veloxit.no: On 05.06.2010 15:30, Niko Schwarz wrote: Hi list, http://code.google.com/p/pharo/issues/detail?id=2508can=4colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty The following mini unit test fails: readWriteStreamShouldHonorStartIndex self assert: ( (ReadWriteStream on: 'hallo' from: 3 to: 4) contents = 'll') Instead, contents returns 'hall' Pharo image:core Pharo core version: PharoCore1.1ALPHA, Latest update: #11383 Virtual machine used: pharo-vm-osx Steps to reproduce: 1. Subclass TestCase and add the above method 2. run the test Cheers, Niko Well, this is more an issue with contents, which returns the entire collection up to readLimit. (or position if it's a WriteStream) From the ANSI standard: content returns a collection that contains the receiver's _past_ and future sequence values, in order. The method which behaves as you expect, is called upToEnd. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Question about String
Depends on who you ask. Your standard Windows developer will say it's
4, your standard Unix believer will say it's 3 (because in Unix text
files always end in a newline. And String cr is used roughly like Unix
\n, although it's another character.)
Niko
2010/6/9 Fabrizio Perin fabrizio.pe...@gmail.com:
Hi,
evaluating the following code:
('Fred', String cr , 'the' , String cr , 'Bear') lineCount
('Fred', String cr , 'the' , String cr , 'Bear', String cr) lineCount
I got the same answer that is 3 but the second string doesn't have 4 lines?
Regards,
Fabrizio
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
http://scg.unibe.ch/staff/Schwarz
twitter.com/nes1983
Tel: +41 076 235 8683
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Three current versions: 1.0, 1.1, 1.2
On Wed, Jun 9, 2010 at 9:29 AM, Adrian Lienhard a...@netstyle.ch wrote: Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now. I think http://code.google.com/p/pharo/issues/detail?id=2469 should be integrated before 1.1. I remember how much of a pain the simulator behavior was when messing with SUnit. Toon's patch might be the foundation for cleaner SUnit code. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Three current versions: 1.0, 1.1, 1.2
I hear that we're working on 1.2 now. But pharo-project.org still hands out 1.0 versions to everyone who asks. So we'll get plenty of bug reports for 1.0. I think we should switch over to 1.1 on the home page soon. Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [BUG] VM crash during debbuging some code by Through button with Transcriptshow: in deepest inner methods
We've further improved on the issue in http://code.google.com/p/pharo/issues/detail?id=2469. It's committed to the inbox, now. Niko On Tue, May 25, 2010 at 10:34 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: thanks a lot denis for checking that. I should say thatI'm quite busy right now. :) Stef On May 25, 2010, at 7:05 PM, Denis Kudriashov wrote: Ok, Eliot send some fix for code simulation in squeak list. With it decompilation work good and my tests does not crach VM. But some of tests failed (they like infinit loop) I attach Eliot fix. 2010/5/24 Stéphane Ducasse stephane.duca...@inria.fr http://code.google.com/p/pharo/issues/detail?id=2469 Stef On May 23, 2010, at 4:18 PM, Denis Kudriashov wrote: I found more bad cases with code simulation. And I think any manipulations with context (errors signals, simaphore, ...) not work in simulation mode. Transcript printing failed because of simaphore accessing (for thread safety) I create CodeSimulationTests (see attachement) with some tests which not work and which crash VM. Maybe this tests not correct. But I hope it helps to indicate and solve issues 2010/5/23 Stéphane Ducasse stephane.duca...@inria.fr Thanks! Stef On May 23, 2010, at 11:13 AM, Denis Kudriashov wrote: And If you replace Transcript code with self halt. You will see that debugging with through button does not work. Code simulation failure raised (but without VM crash) 2010/5/23 Denis Kudriashov dionisi...@gmail.com I has Pharo1.0 one click, Windows 7. I attach class ClassWithTranscriptPrinting. see class side method #debug 2010/5/23 Stéphane Ducasse stephane.duca...@inria.fr Hi denis can you report clearly your bug - image - vm - os - scenario I could not compile Transcriptshow:'something' so I do not know how you did it. On May 23, 2010, at 10:11 AM, Denis Kudriashov wrote: Hello Just insert Transcriptshow:'something' at any method begin. Now debug sender of your method by debugger Through button. If no Transcript opened VM will crash! ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project CodeSimulationTests.st___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ContextPart-tryNamedPrimitiveInforwithArgs.st___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Three current versions: 1.0, 1.1, 1.2
Of course not. Just switch the default download (the big one, all over the site) site to 1.1. I just suggest to switch from 1.0 to 1.1 as stable at the same time that we switch from 1.1 to 1.2 for development. Then we never have 3 current versions at once. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Auto-Completion in the debugger
Hi, Why is the auto-completion in the dev images so stupid in the debugger? Why is it wildly guessing around in a debugger, where the type of all variables is well known? I'm using a 1.1 beta image (non-core): http://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05.1.zip. Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Auto-Completion in the debugger
2010/6/8 Mariano Martinez Peck marianop...@gmail.com: Maybe you should be more polite in order to receive better feedback. I'll work on it. I wasn't sure if the feature's missing or whether I'd done something wrong. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Auto-Completion in the debugger
Hmm, not right now, but I'll add it to my someday/maybe list :) Thanks for the offer! Cheers, Niko On Tue, Jun 8, 2010 at 5:44 PM, Romain Robbes romain.rob...@gmail.com wrote: I'll work on it. I wasn't sure if the feature's missing or whether I'd done something wrong. Hi Niko, Indeed, the feature is missing. If you want to work on it, I can provide you write access to the repository. Cheers, Romain Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 -- Romain Robbes http://romain.robb.es rrob...@dcc.uchile.cl -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Auto-Completion in the debugger
Done: http://code.google.com/p/pharo/issues/detail?id=2524 2010/6/8 Mariano Martinez Peck marianop...@gmail.com: On Tue, Jun 8, 2010 at 5:50 PM, Niko Schwarz niko.schw...@googlemail.com wrote: Hmm, not right now, but I'll add it to my someday/maybe list :) You can also add it to the someday/maybe Pharo issue trackerso that maybe other can do it. That way we don't forget about it. Thanks for the offer! Cheers, Niko On Tue, Jun 8, 2010 at 5:44 PM, Romain Robbes romain.rob...@gmail.com wrote: I'll work on it. I wasn't sure if the feature's missing or whether I'd done something wrong. Hi Niko, Indeed, the feature is missing. If you want to work on it, I can provide you write access to the repository. Cheers, Romain Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 -- Romain Robbes http://romain.robb.es rrob...@dcc.uchile.cl -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About TDD and Pharo
I think the rationale must be: during TDD it's ok to ask the developer questions that he can answer right away. Thus, it's ok that the create button asks for the class: you know instantly what to answer. But asking for the method category is a major pain. I don't know about y'all, but I never quite know upfront how I'll structure my categories. That emerges much later in the process. In short: remove the asking for the method category. Just put it in 'not yet categorized', and have me figure it out later. Cheers, Niko 2010/6/2 Germán Leiva leivager...@gmail.com: I'm thinking out load here ... In the debugger when a DNU is raised, for speeding up the programming in TDD mode: The create button must add the method in the class of the receiver, the possibility to choose a superclass of the receiver must be optional (I don't like the recurrent asking...) in other button for example or having different shortcuts from the keyboard If I send a message that I already know that will be a getter, some option like Create getter could automagically create the method and the instance variable. When we a accept a method for the first time the pop-ups saying Unkown selector please confirm, select or cancel are really annoying and decrease coding speed Same for the category pop-ups In the creation of a new class through define new class it will be helpful to remember the last class category used Some ToDo list supported from the environment and some facility for the creation of test. All of the above maybe just make sense in TDD mode or not =P Cheers 2010/6/2 Alexandre Bergel alexandre.ber...@inria.fr The problems that I would like to see Pharo address are: - redundancies in unit tests - coverage of tests - classification of low and high levels of tests (implementation tests vs user stories) What are the tools to identify and solve this issues ? Research is needed :-) Alexandre On 2 Jun 2010, at 15:30, Stéphane Ducasse wrote: Hi all Imagine that we would like to sell pharo (+ seaside) as THE agile platform for doing TDD. What would be the changes that we could do support it. I know that hernan did a package for that but not I would like to have a new list of items to support it. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Germán Leiva leivager...@gmail.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] A more concise array access (using negative indices)
Hi guys, Am I the only one who finds the ruby protocol for accessing collections richer at times? In Smalltalk, if ary is an array, how do I get ary without its last element? In Ruby, it's dead easy: ary[0..-2]. I can do that by heart after not having done any serious Ruby in a long time. In Smalltalk, I have to search through a long list of method names, because there are just so many possible names for the method. The point is: would it be totally out of reach to try and get a more concise and unified way to access sequenceable collections? I know I'm sort of asking for the slaughter of a holy cow: Smalltalk only has telling and easy message names all over. Or wait, does it? There's of course Class #methodName. And 2 @ 3 for points. Just to put something on the table, how about: (ary at: 1, -2) Or, without braces, if you don't mind the reversal: 1,-2 @ ary Or, consistent with current naming conventions: (ary from: 1 to: -2) Just my 2 cents, what do you think? Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A more concise array access (using negative indices)
On Mon, Jun 7, 2010 at 3:23 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
yes this one looks good.
but
copyFrom: 1 to: does not convey that you should pass the second
argument starting reverse.
Well, in ruby it's a general convention that negative indices start
counting from the right. A reasonable implementation would change all
sequenceable collections such that they accept negative indices.
In Phexample syntax:
((1 to: 5) at: -2) should = 4.
The alternative is to always have two accessors, then of course non-negative:
(1 to: 5) atFromEnd: 2) should = 4.
and:
('hello' from: 2 toFromEnd: 2) should = 'ell'
I clearly prefer the negative indices. Things you do all the time can
be much shorter than things you don't do so often. Huffman-encode your
programming :)
Cheers,
Niko
--
http://scg.unibe.ch/staff/Schwarz
twitter.com/nes1983
Tel: +41 076 235 8683
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [JOB] We are Looking for a Pharo Engineer
Is there a website with this text that I can link to? Niko On Mon, Jun 7, 2010 at 3:48 PM, Marcus Denker marcus.den...@inria.fr wrote: Hello, INRIA RMOD is looking for a full-time engineer for helping with Pharo development. As researchers, we need a really great system to explore new ideas with. The job of the engineer is to help us by improving the infrastructure we use for our work. What this of course means is that it's kind of a cool job: work in a research lab, but no paper writing, no teaching, no administration. In addition: - live in France (one hour from Paris, 1h20 from London, 35 min from Brussels) - try a lot of good beers (our office is just 10km from the border to Belgium) - french food - code all the day in Smalltalk and a bit of C Apparently from what the DHR services told us, the salary will depend on years of expertise and diplomas. We can think that 2700 Euros (before final taxes) should be a good working number for a candidate of the experience we are looking for. In France the employer pays already social security and pension. So the salary already includes lots (and lots) of deductions compared to e.g. a german brutto salary. Lille is an active city but not expensive (lot of students...), centrally located with good connections by train to everywhere (including CDG and Brussels airports). The job will to continue making Pharo better - better tools - better network support - better compiler infrastructure - improve the VM - help with day-to-day bug fixing and constant improvement Therefore we are looking for a candidate with some years of Smalltalk (possible Pharo/Squeak) background. Duration: 30 months Starting date: October 2010 Location: Lille (no remote job possible) Official Job Description and Application via: http://bit.ly/dyhdba Deadline: 15 July 2010 More about INRIA Lille: http://www.inria.fr/lille/ INRIA in General: http://www.inria.fr Engineers at INRIA: http://www.inria.fr/travailler/metiers/accompagnement/dev_applications.en.html Lille: http://en.wikipedia.org/wiki/Lille http://www.mairie-lille.fr/en http://wikitravel.org/en/Lille Do not hesitate to contact us for more information. Stef/Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About TDD and Pharo
Right, only that I'm unhappy with the naming. I'd never have guessed that cancel does what I want. So far, I've always chosen a random junk category and fixed it up later. A button Cancel I'd expect to cancel the creation altogether. Niko 2010/6/7 Hernan Wilkinson hernan.wilkin...@gmail.com: it is true, I almost all the time cancel that dialog to put the method as not yet categorized... but sometimes I select the category... I think that pressing ESC or cancel is not that bad in this case and I would keep this dialog. On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz niko.schw...@googlemail.com wrote: I think the rationale must be: during TDD it's ok to ask the developer questions that he can answer right away. Thus, it's ok that the create button asks for the class: you know instantly what to answer. But asking for the method category is a major pain. I don't know about y'all, but I never quite know upfront how I'll structure my categories. That emerges much later in the process. In short: remove the asking for the method category. Just put it in 'not yet categorized', and have me figure it out later. Cheers, Niko 2010/6/2 Germán Leiva leivager...@gmail.com: I'm thinking out load here ... In the debugger when a DNU is raised, for speeding up the programming in TDD mode: The create button must add the method in the class of the receiver, the possibility to choose a superclass of the receiver must be optional (I don't like the recurrent asking...) in other button for example or having different shortcuts from the keyboard If I send a message that I already know that will be a getter, some option like Create getter could automagically create the method and the instance variable. When we a accept a method for the first time the pop-ups saying Unkown selector please confirm, select or cancel are really annoying and decrease coding speed Same for the category pop-ups In the creation of a new class through define new class it will be helpful to remember the last class category used Some ToDo list supported from the environment and some facility for the creation of test. All of the above maybe just make sense in TDD mode or not =P Cheers 2010/6/2 Alexandre Bergel alexandre.ber...@inria.fr The problems that I would like to see Pharo address are: - redundancies in unit tests - coverage of tests - classification of low and high levels of tests (implementation tests vs user stories) What are the tools to identify and solve this issues ? Research is needed :-) Alexandre On 2 Jun 2010, at 15:30, Stéphane Ducasse wrote: Hi all Imagine that we would like to sell pharo (+ seaside) as THE agile platform for doing TDD. What would be the changes that we could do support it. I know that hernan did a package for that but not I would like to have a new list of items to support it. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Germán Leiva leivager...@gmail.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A more concise array access (using negative indices)
Well, I'm just arguing that in Ruby, the simple convention that
negative indices start from left to right map to a zoo of different
methods in Smalltalk.
You didn't comment on:
('hello' from: 2 toFromEnd: 2) should = 'ell'
Would that find your blessing?
niko
On Mon, Jun 7, 2010 at 6:59 PM, Ramon Leon ramon.l...@allresnet.com wrote:
On 6/7/2010 5:03 AM, Lukas Renggli wrote:
Am I the only one who finds the ruby protocol for accessing
collections richer at times? In Smalltalk, if ary is an array, how do
I get ary without its last element?
anArray allButLast
Or for other amounts, allButLast: x
There's also allButFirst and allButFirst: x. A look at the protocol of
SequenceableCollection would have revealed this in seconds.
--
Ramon Leon
http://onsmalltalk.com
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
http://scg.unibe.ch/staff/Schwarz
twitter.com/nes1983
Tel: +41 076 235 8683
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A more concise array access (using negative indices)
That would be precisely what ruby does. It's ary at: (1 to: 3) vs. ary from: 1 to: 3. Right there, the second one looks more useful. But, the first thing leads to beautiful code in Matlab and Mathematica when dealing with vectors and matrices. So it may well be worth it. Cheers, Niko On Mon, Jun 7, 2010 at 9:30 PM, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Niko Schwarz a écrit : Just to put something on the table, how about: (ary at: 1, -2) Or #at: could accept an interval as argument ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About TDD and Pharo
Why not offer not yet categorized as the first option as a category to choose from? Niko 2010/6/7 Gabriel Brunstein gab...@gmail.com: maybe the right name would be something like don´t categorize ;) On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz niko.schw...@googlemail.com wrote: Right, only that I'm unhappy with the naming. I'd never have guessed that cancel does what I want. So far, I've always chosen a random junk category and fixed it up later. A button Cancel I'd expect to cancel the creation altogether. Niko 2010/6/7 Hernan Wilkinson hernan.wilkin...@gmail.com: it is true, I almost all the time cancel that dialog to put the method as not yet categorized... but sometimes I select the category... I think that pressing ESC or cancel is not that bad in this case and I would keep this dialog. On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz niko.schw...@googlemail.com wrote: I think the rationale must be: during TDD it's ok to ask the developer questions that he can answer right away. Thus, it's ok that the create button asks for the class: you know instantly what to answer. But asking for the method category is a major pain. I don't know about y'all, but I never quite know upfront how I'll structure my categories. That emerges much later in the process. In short: remove the asking for the method category. Just put it in 'not yet categorized', and have me figure it out later. Cheers, Niko 2010/6/2 Germán Leiva leivager...@gmail.com: I'm thinking out load here ... In the debugger when a DNU is raised, for speeding up the programming in TDD mode: The create button must add the method in the class of the receiver, the possibility to choose a superclass of the receiver must be optional (I don't like the recurrent asking...) in other button for example or having different shortcuts from the keyboard If I send a message that I already know that will be a getter, some option like Create getter could automagically create the method and the instance variable. When we a accept a method for the first time the pop-ups saying Unkown selector please confirm, select or cancel are really annoying and decrease coding speed Same for the category pop-ups In the creation of a new class through define new class it will be helpful to remember the last class category used Some ToDo list supported from the environment and some facility for the creation of test. All of the above maybe just make sense in TDD mode or not =P Cheers 2010/6/2 Alexandre Bergel alexandre.ber...@inria.fr The problems that I would like to see Pharo address are: - redundancies in unit tests - coverage of tests - classification of low and high levels of tests (implementation tests vs user stories) What are the tools to identify and solve this issues ? Research is needed :-) Alexandre On 2 Jun 2010, at 15:30, Stéphane Ducasse wrote: Hi all Imagine that we would like to sell pharo (+ seaside) as THE agile platform for doing TDD. What would be the changes that we could do support it. I know that hernan did a package for that but not I would like to have a new list of items to support it. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Germán Leiva leivager...@gmail.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com
Re: [Pharo-project] A more concise array access (using negative indices)
On Mon, Jun 7, 2010 at 10:29 PM, Ramon Leon ramon.l...@allresnet.com wrote:
Ruby
seems to have a style where you can send just about anything to a method and
it tries to figure out what to do based on the type of the arg, they like
magic and the smaller API; Smalltalk tends to just have a dozen different
but similarly named methods that let you accomplish the same thing.
I like that analysis.
so yes I like...
('hello' from: 2 toFromEnd: 2) should = 'ell'
:)
I really don't want to learn 10 different ways to use #at:, I'd rather see
10 similarly named methods each doing it one way that look like they're all
variations of a theme.
That's a valid stand point to take. I guess, at some point you just
need to choose what your use cases are / what your audience is.
You can get all the positions of c that differ from a, in Matlab:
c(a!=c).
In smalltalk, this could be something like:
c at: (a differencesVectorWith: c).
Cheers,
Niko
--
http://scg.unibe.ch/staff/Schwarz
twitter.com/nes1983
Tel: +41 076 235 8683
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About TDD and Pharo
I listed this behavior as http://code.google.com/p/pharo/issues/detail?id=2522 Cheers, Niko On Mon, Jun 7, 2010 at 10:04 PM, Niko Schwarz niko.schw...@googlemail.com wrote: Why not offer not yet categorized as the first option as a category to choose from? Niko 2010/6/7 Gabriel Brunstein gab...@gmail.com: maybe the right name would be something like don´t categorize ;) On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz niko.schw...@googlemail.com wrote: Right, only that I'm unhappy with the naming. I'd never have guessed that cancel does what I want. So far, I've always chosen a random junk category and fixed it up later. A button Cancel I'd expect to cancel the creation altogether. Niko 2010/6/7 Hernan Wilkinson hernan.wilkin...@gmail.com: it is true, I almost all the time cancel that dialog to put the method as not yet categorized... but sometimes I select the category... I think that pressing ESC or cancel is not that bad in this case and I would keep this dialog. On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz niko.schw...@googlemail.com wrote: I think the rationale must be: during TDD it's ok to ask the developer questions that he can answer right away. Thus, it's ok that the create button asks for the class: you know instantly what to answer. But asking for the method category is a major pain. I don't know about y'all, but I never quite know upfront how I'll structure my categories. That emerges much later in the process. In short: remove the asking for the method category. Just put it in 'not yet categorized', and have me figure it out later. Cheers, Niko 2010/6/2 Germán Leiva leivager...@gmail.com: I'm thinking out load here ... In the debugger when a DNU is raised, for speeding up the programming in TDD mode: The create button must add the method in the class of the receiver, the possibility to choose a superclass of the receiver must be optional (I don't like the recurrent asking...) in other button for example or having different shortcuts from the keyboard If I send a message that I already know that will be a getter, some option like Create getter could automagically create the method and the instance variable. When we a accept a method for the first time the pop-ups saying Unkown selector please confirm, select or cancel are really annoying and decrease coding speed Same for the category pop-ups In the creation of a new class through define new class it will be helpful to remember the last class category used Some ToDo list supported from the environment and some facility for the creation of test. All of the above maybe just make sense in TDD mode or not =P Cheers 2010/6/2 Alexandre Bergel alexandre.ber...@inria.fr The problems that I would like to see Pharo address are: - redundancies in unit tests - coverage of tests - classification of low and high levels of tests (implementation tests vs user stories) What are the tools to identify and solve this issues ? Research is needed :-) Alexandre On 2 Jun 2010, at 15:30, Stéphane Ducasse wrote: Hi all Imagine that we would like to sell pharo (+ seaside) as THE agile platform for doing TDD. What would be the changes that we could do support it. I know that hernan did a package for that but not I would like to have a new list of items to support it. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Germán Leiva leivager...@gmail.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo
[Pharo-project] ReadWriteStream contents fails
Hi list, http://code.google.com/p/pharo/issues/detail?id=2508can=4colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty The following mini unit test fails: readWriteStreamShouldHonorStartIndex self assert: ( (ReadWriteStream on: 'hallo' from: 3 to: 4) contents = 'll') Instead, contents returns 'hall' Pharo image:core Pharo core version: PharoCore1.1ALPHA, Latest update: #11383 Virtual machine used: pharo-vm-osx Steps to reproduce: 1. Subclass TestCase and add the above method 2. run the test Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] haltIfShiftPressed
Hi list, http://code.google.com/p/pharo/issues/detail?id=2510can=4colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty I suggest the following snippet in object to ease debugging: ObjecthaltIfShiftPressed self haltIf: [Sensor shiftPressed] Pharo image: core Pharo core version: #11383 Virtual machine used: pharo-vm-osx -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] haltIfShiftPressed
Seriously, I think the method should be called h. Just that. Nobody's going to type a method name as long as haltIfShiftPressed for debugging. Debugging is not about readability. Cheers, Niko On Sat, Jun 5, 2010 at 3:31 PM, Niko Schwarz niko.schw...@googlemail.com wrote: Hi list, http://code.google.com/p/pharo/issues/detail?id=2510can=4colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty I suggest the following snippet in object to ease debugging: ObjecthaltIfShiftPressed self haltIf: [Sensor shiftPressed] Pharo image: core Pharo core version: #11383 Virtual machine used: pharo-vm-osx -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] CompiledMethod asString is a text
Hi, I just bumped into this. Probably this is intended somehow, but it does seem weird enough to ask … (Object #hash) asString class returns 'Text'. Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] PluggableSet and KeyedSet serve the same purpose
Hi list, the purpose of PluggableSet and KeyedSet is the same: they're both sets where the equivalence relation is overwritten by a block. One of the two should be removed. What do you think? Cheers, Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] New pharo images
The alpha image runs into a deprecation warning, caused by Preferences classannotationPanes, called by OBSystemBrowser class(OBCodeBrowser class)annotationPanel as soon as you open a browser. Cheers, Niko On Mon, Dec 7, 2009 at 10:08 AM, Damien Cassou damien.cas...@gmail.com wrote: Based on 1.0 rc1 and 1.1 alpha: http://pharo-project.org/pharo-download -- Damien Cassou http://damiencassou.seasidehosting.st Lambdas are relegated to relative obscurity until Java makes them popular by not having them. James Iry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] pharo and db support
Ah, great :). On Sun, Nov 29, 2009 at 3:37 PM, Johan Brichau johan.bric...@uclouvain.be wrote: In our experience, Magma took around 250ms, regardless if the query had a large or small set of results. Using GOODS, our application appears to run as fast as if the object collections were kept in-image only (response times of 10ms for our queries). Maybe it will run slower for very large object collections but since we will not run into that problem, it's not an issue in our case. There's some differences regarding transactions support which we had to cope with, but it all seems to run just fine right now. and thanks for having suggested it! ;-) On 29 Nov 2009, at 13:26, Niko Schwarz wrote: Glad to hear it :). Is it really faster than Magma in your experience? Cheers, Niko On Sun, Nov 29, 2009 at 11:11 AM, Johan Brichau johan.bric...@uclouvain.be wrote: We are using GOODS for a while now and it runs pretty well. I have added it to the wikipage. On 26 Nov 2009, at 17:39, Tudor Girba wrote: Hi, I would like to collect a list of the solutions to link Pharo with existing databases. I am interested in both relational and in object databases. Is there a list somewhere? If not and if you know/use/develop/ such a solution, it would be great if we could put it together by collecting some data about these: - Pharo project and version - Supported database vendor and version - Maturity: prototype/production ready/ - Projects that use this one - Current development status and maintenance support (if any) - Website - Others Cheers, Doru -- www.tudorgirba.com If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Johan Brichau johan.bric...@uclouvain.be ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Johan Brichau johan.bric...@uclouvain.be ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Where to put removed stuff?
On Stackoverflow someone asked what to do with good code which isn't needed anymore. This was the answer: blockquoteAs an answer, please consider this short story: The dead code Collector: Bring out yer dead code. Man with dead code : Here's one. The dead code Collector: That'll be ninepence. The dead code: I'm not dead code. The dead code Collector: What? Man with dead code : Nothing. There's your ninepence. The dead code: I'm not dead code. The dead code Collector: 'Ere, he says he's not dead code. Man with dead code : Yes he is. The dead code: I'm not. The dead code Collector: He isn't. Man with dead code : Well, he will be soon, he's very ill. The dead code: I'm getting better. Man with dead code : No you're not, you'll be stone dead code in a moment. The dead code Collector: Well, I can't take him like that. It's against regulations. The dead code: I don't want to go on the cart. Man with dead code : Oh, don't be such a baby. The dead code Collector: I can't take him. The dead code: I feel fine. Man with dead code : Oh, do me a favor. The dead code Collector: I can't. Man with dead code : Well, can you hang around for a couple of minutes? He won't be long. The dead code Collector: I promised I'd be at the Robinsons'. They've lost nine today. Man with dead code : Well, when's your next round? The dead code Collector: Thursday. The dead code: I think I'll go for a walk. Man with dead code : You're not fooling anyone, you know. Isn't there anything you could do? The dead code: I feel happy. I feel happy. [the dead code Collector glances up and down the street furtively, then silences the dead code with his a whack of his Ctrl-X] Man with dead code : Ah, thank you very much.--BraveSirFoobar/blockquote. (The Thread on Stackoverflow: http://stackoverflow.com/questions/352234/what-to-do-with-unused-useful-code) cheers, Niko 2009/11/29 Simon Denier simon.den...@inria.fr: Hi there I think this has been discussed before, but I cant tell if there is an official rule for that (maybe it could be added to the wiki). So let's say I have a patch which removes the Collection arithmetic protocols (332). Now this protocol is still quite nice and we can offer it as an extension package for those who need it. Where should I put this Collection-Arithmetic package? In its own squeaksource project? Or is there a project for extra packages for Pharo? -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] pharo and db support
Glad to hear it :). Is it really faster than Magma in your experience? Cheers, Niko On Sun, Nov 29, 2009 at 11:11 AM, Johan Brichau johan.bric...@uclouvain.be wrote: We are using GOODS for a while now and it runs pretty well. I have added it to the wikipage. On 26 Nov 2009, at 17:39, Tudor Girba wrote: Hi, I would like to collect a list of the solutions to link Pharo with existing databases. I am interested in both relational and in object databases. Is there a list somewhere? If not and if you know/use/develop/ such a solution, it would be great if we could put it together by collecting some data about these: - Pharo project and version - Supported database vendor and version - Maturity: prototype/production ready/ - Projects that use this one - Current development status and maintenance support (if any) - Website - Others Cheers, Doru -- www.tudorgirba.com If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Johan Brichau johan.bric...@uclouvain.be ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] why we should kill project
Tee hee, cool beans guys :)
Niko
On Tue, Nov 10, 2009 at 6:32 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
It is a pearl!
may be a joke for geek but I love it.
STef
((Project class parseTreeFor: #mostRecent:onServer:) allChildren
reject: [ :each | each isVariable ])
asBag sortedCounts
first: 20
5x RBLiteralValueNode(-1)
3x RBMessageNode(Array with: goodName
with: max)
3x RBMessageNode(max = -1)
3x RBAssignmentNode(goodName := rawList at: ind)
3x RBSequenceNode(^ Array with: goodName
with: max)
3x RBReturnNode(^ nothingFound)
3x RBMessageNode(max = -1 ifFalse:
[ ^ Array with: goodName
with: max ])
3x RBBlockNode([ ^ Array with: goodName
with: max ])
3x RBMessageNode(rawList at: ind)
3x RBReturnNode(^ Array with: goodName
with: max)
2x RBBlockNode([ num := (Project parseProjectFileName: aName) second.
num max ifTrue:
[ max := num.
goodName := rawList at: ind ] ])
2x RBMessageNode((Project parseProjectFileName: aName) second)
2x RBAssignmentNode(num := (Project parseProjectFileName: aName) second)
2x RBAssignmentNode(max := num)
2x RBBlockNode([ max := num.
goodName := rawList at: ind ])
2x RBMessageNode((Project parseProjectFileName: aName))
2x RBSequenceNode(max := num.
goodName := rawList at: ind)
2x RBMessageNode(num max ifTrue:
[ max := num.
goodName := rawList at: ind ])
2x RBMessageNode(num max)
2x RBLiteralValueNode(' ')
...
2009/11/10 Stéphane Ducasse stephane.duca...@inria.fr:
if you want to have fun try to identify the number of times certain parts
are duplicated inside the same method.
Stef
mostRecent: projName onServer: aServerDirectory
Find the exact fileName of the most recent version of project with
the stem name of projName. Names are of the form 'projName|mm.pr' where mm
is a mime-encoded integer version number.
File names may or may not be HTTP escaped, %20 on the server.
| stem list max goodName triple num stem1 stem2 rawList nothingFound
unEscName |
self flag: #bob. do we want to handle unversioned projects
as well?
nothingFound := { nil. -1 }.
aServerDirectory ifNil: [ ^ nothingFound ].
23 sept 2000 - some old projects have periods in name so be more
careful
unEscName := projName unescapePercents.
triple := Project parseProjectFileName: unEscName.
stem := triple first.
rawList := aServerDirectory fileNames.
rawList isString ifTrue:
[ self inform: 'server is unavailable'.
^ nothingFound ].
list := rawList collect: [ :nnn | nnn unescapePercents ].
max := -1.
goodName := nil.
list withIndexDo:
[ :aName :ind |
(aName beginsWith: stem) ifTrue:
[ num := (Project parseProjectFileName: aName)
second.
num max ifTrue:
[ max := num.
goodName := rawList at: ind ] ] ].
max = -1 ifFalse:
[ ^ Array
with: goodName
with: max ].
try with underbar for spaces on server
(stem includes: $ ) ifTrue:
[ stem1 := stem
copyReplaceAll: ' '
with: '_'.
list withIndexDo:
[ :aName :ind |
(aName beginsWith: stem1) ifTrue:
[ num := (Project parseProjectFileName:
aName) second.
num max ifTrue:
[ max := num.
goodName := rawList at: ind ] ] ] ].
max = -1 ifFalse:
[ ^ Array
with: goodName
with: max ].
try without the marker |
stem1 := stem allButLast , '.pr'.
stem2 := stem1
copyReplaceAll: ' '
with: '_'. and with spaces replaced
list withIndexDo:
[ :aName :ind |
(aName beginsWith: stem1) | (aName beginsWith: stem2) ifTrue:
[ (triple := aName findTokens: '.') size = 2 ifTrue:
[ max := 0.
goodName := rawList at: ind ] ] ]. no
other versions
max = -1 ifFalse:
[ ^ Array
with: goodName
with: max ].
^ nothingFound no matches
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Lukas Renggli
http://www.lukas-renggli.ch
___
[Pharo-project] Compiler compile:
Hi list, consider this code: c := Compiler compile: 'meth bla ^ 2'. Here, c will be set to the symbol #meth. And Compiler will be added a new method meth. This is of course counter-intuitive, but it's kind of wired into the system. Behaviorcompile: does certainly more than compile. It compiles the code and adds it to itself, then returns the methodName as a symbol. Without mirrors, it's hard to do it right, though. Also, there's an easy method to add a method to a class, but no easy method to get a CompiledMethod object. I don't want to strongly advocate for my change, I just want to offer it. Here's what I did in my system: I changed Compilercompile: to do the following: class side: compile: aString onClass: aClass ^ self new compiledMethodFor: aString onClass: aClass instance side: compiledMethodFor: textOrStream onClass: aClass | methodNode method | class := aClass. self from: textOrStream class: class context: nil notifying: nil. methodNode := self translate: sourceStream noPattern: false ifFail: [^self error: 'Compilation failed']. method := methodNode generate: #(0 0 0 0). self interactive ifTrue: [method := method copyWithTempsFromMethodNode: methodNode]. ^method This has its own problem, like: compile: suddenly has different semantics on Compiler than anywhere else. Best might be renaming Behaviorcompile: to something more intuitive. Like #compileFromAndAdd:. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiler compile:
Well, I can rename the compile: method and post to PharoInbox, if anyone is interested. Niko On Tue, Nov 3, 2009 at 5:19 PM, Gary Chambers gazzagu...@btinternet.com wrote: +1 too. Fewer side-effects and/or more side-effect free refactoring is better. Regards, Gary - Original Message - From: Igor Stasenko siguc...@gmail.com To: Pharo-project@lists.gforge.inria.fr Sent: Tuesday, November 03, 2009 3:56 PM Subject: Re: [Pharo-project] Compiler compile: +1 Niko. There should be an easy interface for compiling the source code without installing the result into system. And of course, compiler should answer an instance of compiled method 2009/11/3 Niko Schwarz niko.schw...@googlemail.com: Hi list, consider this code: c := Compiler compile: 'meth bla ^ 2'. Try using c:= Compiler new compiledMethodFor: ... The class-side #compile:... method , is method which serves for directly compiling installing the method into receiver. In the above case - into Compiler class, but you can also do that for any other class: MyClass compile: Here, c will be set to the symbol #meth. And Compiler will be added a new method meth. This is of course counter-intuitive, but it's kind of wired into the system. Behaviorcompile: does certainly more than compile. It compiles the code and adds it to itself, then returns the methodName as a symbol. Without mirrors, it's hard to do it right, though. Also, there's an easy method to add a method to a class, but no easy method to get a CompiledMethod object. I don't want to strongly advocate for my change, I just want to offer it. Here's what I did in my system: I changed Compilercompile: to do the following: class side: compile: aString onClass: aClass ^ self new compiledMethodFor: aString onClass: aClass instance side: compiledMethodFor: textOrStream onClass: aClass | methodNode method | class := aClass. self from: textOrStream class: class context: nil notifying: nil. methodNode := self translate: sourceStream noPattern: false ifFail: [^self error: 'Compilation failed']. method := methodNode generate: #(0 0 0 0). self interactive ifTrue: [method := method copyWithTempsFromMethodNode: methodNode]. ^method This has its own problem, like: compile: suddenly has different semantics on Compiler than anywhere else. Best might be renaming Behaviorcompile: to something more intuitive. Like #compileFromAndAdd:. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] displayWorldAsTwoTone
Hi list, sending displayWorldAsTwoTone to the global PasteUpMorph does not turn my screen black and white. That is because WorldState does not respond to #displayWorldAsTwoTone, as PasteUpMorphdisplayWorldAsTwoTone expects. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] How to make Pharo produce random garbage bytes
Hi list, I learned something fun today from a friend, how to make Pharo produce random garbage! Make a class AC which is defined as: Object subclass: #AC instanceVariableNames: 'a' classVariableNames: '' poolDictionaries: '' category: 'OB-Standard-Browsers' Then you make a second class AB defined as: Object variableByteSubclass: #AB instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'OB-Standard-Browsers' Then you make accessors for 'a' in AC Now execute: AB superclass: AC And then you do AB new a which gives you back random data. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] NewCompiler for pharo?
Hi Stef, On Sun, Oct 25, 2009 at 10:37 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: - is there a way to get something compiled in between? Two of us use the ThothCompiler in the mean time, which supports all the source code transformations of the NewCompiler, because it features the same AST: - http://smalltalkthoughts.blogspot.com/2009/09/introducing-thothcompiler.html If I understand it correctly, NewCompiler sort of works, but is being cleaned up. I'm sure Lukas and Jorge can correct me here. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10492 (1.0rc1)
Well, what do you propose? Deprecating asNumber calls altogether?
Cheers,
Niko
On Sat, Oct 24, 2009 at 10:32 AM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
Yes a good deprecation is needed.
Stef
On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote:
Sounds ok. At the same time as integrating the change, all senders of
asNumber in the image need to be checked and adapted to the new
semantics if necessary. IIRC MC was not properly working after the
change. Also, users and maintainers of external packages should be
made aware of the change since it may break their code.
Adrian
On Oct 24, 2009, at 10:46 , Stéphane Ducasse wrote:
Thanks niko
So does everybody agree with
asNumber raising an error
and
squeezeOutNumber
I like the proposal.
Stef
On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote:
Hi all, I made a follow-up patch like discussed on the workshop. Now
porting becomes as easy as changing asNumber to
squeezeOutNumber.
Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2
This slice adds squeezeNumberOutOfString: to Number, as discussed in
the Pharo workshop. On the way, it
fixes an issue in SqNumberParser, where it would return itself
rather
than the result of the failblack, when
parsing fails.
Also, a test is added to test and document the new squeezing number
out of strings behavior.
Example usage:
self assert: '123blabla' squeezeOutNumber equals: 123.
self assert: 'blabla123' squeezeOutNumber equals: 123.
self assert: 'blabla12blabla' squeezeOutNumber equals: 12.
self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs 0.0001.
self assert: '.1' squeezeOutNumber 0.
Cheers,
Niko
On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard a...@netstyle.ch
wrote:
10492 (this is the stream of the branch 1.0rc1)
-
- Issue 1320: [squeak trunk] Sort the conflicts. This is required
when
merging a distant version, like Pharo for example...
- Issue 1338: HostWindowTeststestOne is failing in Windows
- Issue 1345: Revert Number classreadFrom: (was integrated with
issue 1258)
___
http://www.adrian-lienhard.ch/
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] OCompletion in the rc1 dev image
Hi list, in the most recent dev image (9.10.5), OCompletion is broken for me. I lost my reproducible test case, but the gist was that sometimes when OCompletion had no idea which type a temporal variable would be, you were unable to insert code behind that variable, because if you tried, a debugger would show up. The problem appears to be DebuggerguessTypeForName:. debuggerMap can be nil and if it is, the method fails. I changed the method to the following, and then the strange errors that occur on my image disappear: guessTypeForName: aString | index object | index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: self selectedContext) indexOf: aString ifAbsent: []]. object := index ifNil: [index := self receiver class allInstVarNames indexOf: aString ifAbsent: []. index ifNil: [^ nil]. self receiver instVarAt: index] ifNotNil: [self selectedContext tempAt: index]. ^ object class Essentially, I leave index at nil, if debugerMap is nil. I don't know enough about OCompletion to tell whether this is a fix, or makes things worse somehow. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10492 (1.0rc1)
Well, by doing that you will confuse users that only relied on the
consensual functionality of asNumber.
It's difficult both ways, and because of that, I'd suggest going the
lazy way and not helping the users other than by adding a comment to
#asNumber which explains the evolution of the message and points to
#squeezeOutNumber. I know that the users would appreciate help in the
migration, but I don't see a non-obtrusive way to do so.
Cheers,
Niko
On Tue, Oct 27, 2009 at 2:59 PM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
Not really
we could do the following
- check all the users of asNumber and let them as asNUmber or
squeezeOutNumber
- then put a deprecation during the alpha phase that state that they
should pay attention
- when we are in rc 1.1 we remove the deprecation
- create a package which would override it with a deprecation.
stef
On Oct 27, 2009, at 2:38 PM, Niko Schwarz wrote:
Well, what do you propose? Deprecating asNumber calls altogether?
Cheers,
Niko
On Sat, Oct 24, 2009 at 10:32 AM, Stéphane Ducasse
stephane.duca...@inria.fr wrote:
Yes a good deprecation is needed.
Stef
On Oct 24, 2009, at 11:13 AM, Adrian Lienhard wrote:
Sounds ok. At the same time as integrating the change, all senders
of
asNumber in the image need to be checked and adapted to the new
semantics if necessary. IIRC MC was not properly working after the
change. Also, users and maintainers of external packages should be
made aware of the change since it may break their code.
Adrian
On Oct 24, 2009, at 10:46 , Stéphane Ducasse wrote:
Thanks niko
So does everybody agree with
asNumber raising an error
and
squeezeOutNumber
I like the proposal.
Stef
On Oct 24, 2009, at 10:30 AM, Niko Schwarz wrote:
Hi all, I made a follow-up patch like discussed on the workshop.
Now
porting becomes as easy as changing asNumber to
squeezeOutNumber.
Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2
This slice adds squeezeNumberOutOfString: to Number, as
discussed in
the Pharo workshop. On the way, it
fixes an issue in SqNumberParser, where it would return itself
rather
than the result of the failblack, when
parsing fails.
Also, a test is added to test and document the new squeezing
number
out of strings behavior.
Example usage:
self assert: '123blabla' squeezeOutNumber equals: 123.
self assert: 'blabla123' squeezeOutNumber equals: 123.
self assert: 'blabla12blabla' squeezeOutNumber equals: 12.
self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs 0.0001.
self assert: '.1' squeezeOutNumber 0.
Cheers,
Niko
On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard a...@netstyle.ch
wrote:
10492 (this is the stream of the branch 1.0rc1)
-
- Issue 1320: [squeak trunk] Sort the conflicts. This is
required
when
merging a distant version, like Pharo for example...
- Issue 1338: HostWindowTeststestOne is failing in Windows
- Issue 1345: Revert Number classreadFrom: (was integrated
with
issue 1258)
___
http://www.adrian-lienhard.ch/
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] OCompletion in the rc1 dev image
My image is indeed still on version damiencassou.33. I marked the bug as 1.0 in the bugtracker (http://code.google.com/p/pharo/issues/detail?id=1351) hoping that it will be integrated in the next 1.0 dev image, as the image is hardly usable without the fix. Cheers, Niko On Tue, Oct 27, 2009 at 3:18 PM, Romain Robbes romain.rob...@lu.unisi.ch wrote: Niko, What is the version of OCompletion in the image? I thought the fix in Ocompletion-RomainRobbes.36.mcz solved that issue. If you are indeed using that version, I'll have a look at your fix. Otherwise, it is just a matter of time before the latest version of OCompletion is used instead of the older one. Cheers, Romain On Oct 27, 2009, at 3:07 PM, Niko Schwarz wrote: Hi list, in the most recent dev image (9.10.5), OCompletion is broken for me. I lost my reproducible test case, but the gist was that sometimes when OCompletion had no idea which type a temporal variable would be, you were unable to insert code behind that variable, because if you tried, a debugger would show up. The problem appears to be DebuggerguessTypeForName:. debuggerMap can be nil and if it is, the method fails. I changed the method to the following, and then the strange errors that occur on my image disappear: guessTypeForName: aString | index object | index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: self selectedContext) indexOf: aString ifAbsent: []]. object := index ifNil: [index := self receiver class allInstVarNames indexOf: aString ifAbsent: []. index ifNil: [^ nil]. self receiver instVarAt: index] ifNotNil: [self selectedContext tempAt: index]. ^ object class Essentially, I leave index at nil, if debugerMap is nil. I don't know enough about OCompletion to tell whether this is a fix, or makes things worse somehow. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://www.inf.unisi.ch/phd/robbes ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] OCompletion in the rc1 dev image
By the way, what is the proper way to propose changes to the dev image script? On Tue, Oct 27, 2009 at 3:57 PM, Niko Schwarz niko.schw...@googlemail.com wrote: My image is indeed still on version damiencassou.33. I marked the bug as 1.0 in the bugtracker (http://code.google.com/p/pharo/issues/detail?id=1351) hoping that it will be integrated in the next 1.0 dev image, as the image is hardly usable without the fix. Cheers, Niko On Tue, Oct 27, 2009 at 3:18 PM, Romain Robbes romain.rob...@lu.unisi.ch wrote: Niko, What is the version of OCompletion in the image? I thought the fix in Ocompletion-RomainRobbes.36.mcz solved that issue. If you are indeed using that version, I'll have a look at your fix. Otherwise, it is just a matter of time before the latest version of OCompletion is used instead of the older one. Cheers, Romain On Oct 27, 2009, at 3:07 PM, Niko Schwarz wrote: Hi list, in the most recent dev image (9.10.5), OCompletion is broken for me. I lost my reproducible test case, but the gist was that sometimes when OCompletion had no idea which type a temporal variable would be, you were unable to insert code behind that variable, because if you tried, a debugger would show up. The problem appears to be DebuggerguessTypeForName:. debuggerMap can be nil and if it is, the method fails. I changed the method to the following, and then the strange errors that occur on my image disappear: guessTypeForName: aString | index object | index := debuggerMap ifNotNil: [(debuggerMap tempNamesForContext: self selectedContext) indexOf: aString ifAbsent: []]. object := index ifNil: [index := self receiver class allInstVarNames indexOf: aString ifAbsent: []. index ifNil: [^ nil]. self receiver instVarAt: index] ifNotNil: [self selectedContext tempAt: index]. ^ object class Essentially, I leave index at nil, if debugerMap is nil. I don't know enough about OCompletion to tell whether this is a fix, or makes things worse somehow. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Romain Robbes http://www.inf.unisi.ch/phd/robbes ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update] #10492 (1.0rc1)
Hi all, I made a follow-up patch like discussed on the workshop. Now
porting becomes as easy as changing asNumber to squeezeOutNumber.
Name: SLICE-issue-1258-squeezeOutNumber-NikoSchwarz.2
This slice adds squeezeNumberOutOfString: to Number, as discussed in
the Pharo workshop. On the way, it
fixes an issue in SqNumberParser, where it would return itself rather
than the result of the failblack, when
parsing fails.
Also, a test is added to test and document the new squeezing number
out of strings behavior.
Example usage:
self assert: '123blabla' squeezeOutNumber equals: 123.
self assert: 'blabla123' squeezeOutNumber equals: 123.
self assert: 'blabla12blabla' squeezeOutNumber equals: 12.
self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs 0.0001.
self assert: '.1' squeezeOutNumber 0.
Cheers,
Niko
On Tue, Oct 20, 2009 at 2:14 PM, Adrian Lienhard a...@netstyle.ch wrote:
10492 (this is the stream of the branch 1.0rc1)
-
- Issue 1320: [squeak trunk] Sort the conflicts. This is required when
merging a distant version, like Pharo for example...
- Issue 1338: HostWindowTeststestOne is failing in Windows
- Issue 1345: Revert Number classreadFrom: (was integrated with
issue 1258)
___
http://www.adrian-lienhard.ch/
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Stack re-implemented
Hi list, issue 1336 proposes re-implementing Stack using the new LinkedList which can take arbitrary objects. I committed the code and it was really straightforward to do. Now stack is implemented in 3 one-line methods, removing about 10 methods, and removing one class (StackLink). Please see http://code.google.com/p/pharo/issues/detail?id=1336 or SLICE-issue-1336-StackReimplemented-NikoSchwarz.2. in the inbox. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] feedback about the new inspector
Hi Johan, On 21.10.2009, at 18:39, Johan Brichau wrote: I also understood from Niko on monday that he is working on an alternative inspector that very much ressembles the one from Visualworks. Yes, with Toon Verwaest, it should get ready on the weekend. :) Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Clean up the #sort: and sortBy: mess.
Hi list, this is a copy of a proposal that I dumped into the bugtracker as http://code.google.com/p/pharo/issues/detail?id=1346. An OrderedCollection returns a copy on #sortBy:, while an ArrayedCollection returns a changed self on #sort:. ArrayedCollection does understand #sortBy:, while OrderedCollection does not understand #sort:. In VW and Squeak, OrderedCollection understands sort:, and it sorts inline. I'd like to propose two things (1) Add sort: to OrderedCollection, LinkedList and Heap (all of them understand at: put: since this weekend. and then (2) remove sortBy: I understand that point 2 might be controversial. I'd like to argue for it as follows: the naming sort vs. sortBy: is more than misleading, they appear to be synonyms, but they really do different things. The principle of the least surprise tells me that we should not have such behavior in the system. I'd like to argue that we want to erase the possible source of confusion, that is change sortBy: such that it either does the same as sort: or goes away. I'd like to leave #sort: the way it is because at any rate, we need to have an in-place sort, so why not keep the sort that sorts in- place. I'd argue it should go away, such that code that currently calls sortBy: does not call a method with changed semantics, which is difficult to debug. A DNU is easy to debug: you just change it to the now appropriate call. For me the most reasonable options are these: - rename #sortBy: to #copySortedBy: - remove #sortBy: Out of these, I'd vote for removing, since #copySortedBy: is not really shorter than 'copy sort:'. Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Immutable strings
Hello list! I would like to propose the compiler spit out immutable strings as string literals. I'd like to do this by making a subclass of classical strings which throws error messages when it is attempted to change the string. The beginning of this discussion happened in the bug tracker, please see http://code.google.com/p/pharo/issues/detail?id=1332. I completely agree with Toon: String literals should be immutable. This can be done with almost no speed impact and would only break code that quite honestly deserves to break. My 2 cents. Regards, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Pharo Core 1.0rc1
That was me, it comes from Squeak trunk. I didn't test it, because it looked so harmless and works in Squeak … I'm sorry. It should be sortBy: rather than sort: niko On Mon, Oct 19, 2009 at 7:06 PM, Michael Roberts m...@mjr104.co.uk wrote: MCMergeBrowsermerger: conflicts := aMerger conflicts sort: [:a :b | a operation = b operation]. OrderedCollection dnu sort: introduced I guess http://code.google.com/p/pharo/issues/detail?id=1320 how was this change tested? thanks, Mike On Mon, Oct 19, 2009 at 4:25 PM, Marcus Denker den...@acm.org wrote: http://gforge.inria.fr/frs/download.php/24363/PharoCore-1.0-10491rc1.zip The zip contains a new sources file. Marcus ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Pharo Core 1.0rc1
I clicked around for some time now but I can't trigger that method to test it properly this time. It isn't called on conflicts, it isn't called on merges. What do you need to do to get that method executed artificially? Niko On Mon, Oct 19, 2009 at 8:48 PM, Niko Schwarz niko.schw...@googlemail.com wrote: That was me, it comes from Squeak trunk. I didn't test it, because it looked so harmless and works in Squeak … I'm sorry. It should be sortBy: rather than sort: niko On Mon, Oct 19, 2009 at 7:06 PM, Michael Roberts m...@mjr104.co.uk wrote: MCMergeBrowsermerger: conflicts := aMerger conflicts sort: [:a :b | a operation = b operation]. OrderedCollection dnu sort: introduced I guess http://code.google.com/p/pharo/issues/detail?id=1320 how was this change tested? thanks, Mike On Mon, Oct 19, 2009 at 4:25 PM, Marcus Denker den...@acm.org wrote: http://gforge.inria.fr/frs/download.php/24363/PharoCore-1.0-10491rc1.zip The zip contains a new sources file. Marcus ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Pharo Core 1.0rc1
Then, why was sort: yanked from OrderedCollection? I'm confused. On Mon, Oct 19, 2009 at 9:17 PM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: Implementation details: #sortBy: is not exactly #sort: #sort: does a fast inplace sort, when #sortBy: performs useless copy operations... Nicolas 2009/10/19 Niko Schwarz niko.schw...@googlemail.com: That was me, it comes from Squeak trunk. I didn't test it, because it looked so harmless and works in Squeak … I'm sorry. It should be sortBy: rather than sort: niko On Mon, Oct 19, 2009 at 7:06 PM, Michael Roberts m...@mjr104.co.uk wrote: MCMergeBrowsermerger: conflicts := aMerger conflicts sort: [:a :b | a operation = b operation]. OrderedCollection dnu sort: introduced I guess http://code.google.com/p/pharo/issues/detail?id=1320 how was this change tested? thanks, Mike On Mon, Oct 19, 2009 at 4:25 PM, Marcus Denker den...@acm.org wrote: http://gforge.inria.fr/frs/download.php/24363/PharoCore-1.0-10491rc1.zip The zip contains a new sources file. Marcus ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fix for issue 1258
In Pharo, '.1' = 0 evaluates to true. In the bug tracker, it was proposed to change this to an error being raised, which I implemented: http://code.google.com/p/pharo/issues/detail?id=1258 Cheers, Niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] TabGroupMorph does not show the labels of the tabs
Consider this code: w := SystemWindow labelled: 'LatestInspector'. t := TabGroupMorph new addPage: (RectangleMorph new color: Color green ) label: 'Instance' ; addPage: (RectangleMorph new color: Color red) label: 'Methods' . w openInWorld w addMorph: t fullFrame: (LayoutFrame fractions: (0...@0 corner: 1...@1) offsets: (0...@30 corner: 0...@0)) w openInWorld . The tab will not have the labels in the right place. This only happens if (1) you actually set colors to the RectangleMorphs (2) The TabGroupMorph is embedded in another morph (SystemWindow (3) There are at least two tabs (for 1 tab, it works great). I suspect the code triggered by color: to be guilty. It triggers a change to the morph, which then triggers relabelling, presumably. I filed this as bug http://code.google.com/p/pharo/issues/detail?id=1316. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Follow us on twitter!
You can follow our progress on twitter! Just open this page: http://twitter.com/#search?q=%23pharolille We're using the twitter tag #Pharolille niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Follow us on twitter!
Just for context, I'm referring to the Pharo Sprint in Lille, taking place today. We're already 12 sprinters. On Sat, Oct 17, 2009 at 1:20 PM, Niko Schwarz niko.schw...@googlemail.com wrote: You can follow our progress on twitter! Just open this page: http://twitter.com/#search?q=%23pharolille We're using the twitter tag #Pharolille niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] _ into := changes based on RB
Shouldn't my incredible ThothCompiler allow that? http://smalltalkthoughts.blogspot.com/2009/09/introducing-thothcompiler.html niko On Sat, Oct 17, 2009 at 1:31 PM, Lukas Renggli reng...@gmail.com wrote: -=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=- rule := RBUnderscoreAssignmentRule new. SmalllintChecker runRule: rule onEnvironment: BrowserEnvironment new. rule open -=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=- The second expression takes a few minutes, because it parses the complete image. Note, that the resulting browser won't show a diff of the changes, because it pretty prints the AST using ':=' in both cases. Apply the changes and use the Monticello changes to see the real difference. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] _ into := changes based on RB
That's because you're using the latest Pharo. YOU changed the old AST, and removed a method called null that I'm calling. I'll update ThothCompiler tonight. cheers, niko On Sat, Oct 17, 2009 at 3:38 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: I get a DNU rule does not know open. On Oct 17, 2009, at 1:31 PM, Lukas Renggli wrote: -=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=- rule := RBUnderscoreAssignmentRule new. SmalllintChecker runRule: rule onEnvironment: BrowserEnvironment new. rule open -=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=- The second expression takes a few minutes, because it parses the complete image. Note, that the resulting browser won't show a diff of the changes, because it pretty prints the AST using ':=' in both cases. Apply the changes and use the Monticello changes to see the real difference. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Suggest a change to PluggableListMorph
Hello! Typing a burst into a pluggable list morph results in a behaviour quite remote from e.g. Finder. E.g. typing the same key twice will go to the next match. I suggest changing the behaviour to make it resemble the behaviour that a user may anticipate more closely. I submitted a fix for the situation as Polymorph-Widgets-nes.79 into the Pharo inbox just now. see http://code.google.com/p/pharo/issues/detail?id=926. Cheers, niko ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
