Hi,
We recently stumbled onto this and use WAMimeType because we have
WAFile instances (from Seaside-Core).
It appears as if there is a lot of overlap with ZnMimeType.
It would have been better for us to use ZnMimeType because we had to
map the mime type in a similar way that ZnMimeType >>
forFi
We have a .gitignore file that contains:
version
methodProperties.json
So, we don't bother.
The side effects of this are:
Without methodProperties.json, you have the default author and
meaningless timestamp.
Without the version file, loading does not work properly. So we have a
script that genera
> We miss a functionality in Pharo to easily run (a shorcut) a set of selected
> tests (ex: your project tests). This way, you can have a quick feedback on
> your updates.
> As it is not so easy, I often fallback to run tests from Nautilus (a test
> class or sometimes only a test method).
This
n-handling-when-running-tests-in-Nautilus
Is this the right place?
>
> Regards,
> Christophe.
>
> Le 21 avr. 2015 à 15:34, Otto Behrens a écrit :
>
>> I realised I may have posted this on the wrong list. Is there anyone
>> that can help with this one please?
>>
I realised I may have posted this on the wrong list. Is there anyone
that can help with this one please?
-- Forwarded message --
From: Otto Behrens
Date: Sun, Apr 19, 2015 at 10:08 AM
Subject: exception handling problem when running tests in Nautilus
To: pharo-us
Thanks a lot. Phew, that was difficult. :-)
On Thu, Dec 4, 2014 at 12:55 PM, Marcus Denker wrote:
>
>> On 04 Dec 2014, at 10:41, Otto Behrens wrote:
>>
>> Hi,
>>
>> We just upgraded to Pharo 3 (after using pharo 1.4 for a looong time).
>> I'm a bi
Hi,
We just upgraded to Pharo 3 (after using pharo 1.4 for a looong time).
I'm a bit new to some things, so pardon my ignorance.
We're so used to auto formatting the code, it drives us nuts not to have it.
I eventually figured out that the Pharo30 inbox is here:
http://smalltalkhub.com/mc/Pharo/
Why do we need one method that takes either a block or symbol?
> SequenceableCollection>>sortedAs: aSortBlockOrSymbol
Perhaps sort: can take a block and sortedAs: a symbol?
> MyNullClass>>#ifNil: nilBlock ifNotNil: notNilBlock
> nilBlock value.
>
> Any ideas?
I've got a slightly different understanding of the null object
pattern, perhaps. I would use it this way:
MyClass is an abstract class that defines an interface that users
would expect, with a subcl
> I don't really understand why. How would you distinguish between which
> (kinds of) core objects and which not? Will you not end up with a
> displayString on Object again?
>
>
> You will not know all the 'why's in advance. The concrete answer is in the
> next developer's creativity.
>
> What you
>> I need for example a string representation of objects generally to
>> display in anchors in our seaside application. We have a class
>> DomainObject from which most of our classes inherit, so this is
>> probably the place to add a 'displayString' for something like this.
>
> Not necessarily doma
Thank you everyone for your comments.
I agree with Martin's comments and Stef's most recent one. Some of the
messages may not have reached the other lists as this was actually
posted to glass and pharo.
Is this the right conclusion of what we're going to do now?
- On Pharo and GemStone, we will
> #printString is used for debugging, that's why the default
> implementation shows the class name. It's implemented using #printOn:
Makes sense. So unless there's a nice symbol that one can add to show
what it is (eg #foo printString = '#foo'), implementors of printOn:
should call super printOn:,
> 'Conversion' implies using the resulting String in some further
> computation. 'Printing' usually implies displaying something to the
> user (and nothing more), or serialising to a file/network.
What kinds of computation are you thinking of regarding a string? I
think I understand what you're sa
> #printString and #printOn: protocol should be used for printing and #asString
> for conversion. This implies that #asString should not depend on #print
> protocol.
Ah, I used it the other way around: printOn depends on asString. I saw
'conversion' as the lower level.
Why do you distinguish he
Hi,
I've run into one of my favorite problems in Smalltalk and decided to
try the list. Please don't shoot me on this one; perhaps you've run
into it yourself. If there are discussions that I should read, please
send me some info.
My first assumption is that the difference between printString and
It feels to me as if this code wants to be on the temp. So perhaps,
> | temp |
> temp := .
> temp
> ifTrue: [ temp ]
> ifFalse: [ temp ].
can become
doSomething
and on Temp:
doSomething
self
ifTrue: [ self ]
ifFalse: [ self ]
It often works out nicer if you move th
+1
On Tuesday, 14 May 2013, stephane ducasse wrote:
> why do we want to introduce a bad slow type system on certain single place?
> Why a UI element would have to check that a given instance can do something
> while we never ever do it in any other places.
>
> if we have a button and its label sh
+1
On Tuesday, 14 May 2013, stephane ducasse wrote:
> why do we want to introduce a bad slow type system on certain single place?
> Why a UI element would have to check that a given instance can do something
> while we never ever do it in any other places.
>
> if we have a button and its label sh
19 matches
Mail list logo
