But there is a second error: the mustBeBooleanInMagic: normally should work.
(the VM executes the optimised construct — raised an exception — we
recompile
the expression with no optimisation - execute.
There is tiny bug there (it should be #methodNode).
I will commit a fix for that…
Kind of because we got
or:
Boolean * block - Object
and now we have
Object * Object - Object
I already discussed by emails too mcuh this point with marcus.
Since we do not have even the start of a process to document the design
rationale behind
such decisions I will not discuss it.
Yes
Le 1/5/15 11:52, Marcus Denker a écrit :
On 01 May 2015, at 11:49, Marcus Denker marcus.den...@inria.fr
mailto:marcus.den...@inria.fr wrote:
On 01 May 2015, at 11:46, stepharo steph...@free.fr
mailto:steph...@free.fr wrote:
We should at least have a rules stating pay attentino you
On 01 May 2015, at 11:49, Marcus Denker marcus.den...@inria.fr wrote:
On 01 May 2015, at 11:46, stepharo steph...@free.fr wrote:
We should at least have a rules stating pay attentino you use an optimised
selector. Im not sure what should be form of the warning but we should make
https://pharo.fogbugz.com/default.asp?15459
On 01 May 2015, at 10:10, stepharo steph...@free.fr wrote:
Clement
thanks for the information. I thought about that.
From a language perspective what you describe is plain bad. Implementation
should not creep in the language semantics.
Yes, this is why we implemented the
On 30 Apr 2015, at 22:57, Marcus Denker marcus.den...@inria.fr wrote:
On 30 Apr 2015, at 21:47, stepharo steph...@free.fr wrote:
In nautilus I get an error MNU: RBBlockNodemethod
When I select several groups and select merge
mergeGroups: aCollection
aCollection
We should at least have a rules stating pay attentino you use an
optimised selector. Im not sure what should be form of the warning but
we should make progress
I see two cases
- the dev uses a non optimized version and the warning tell him
that it would be better to use the optimised
Clement
thanks for the information. I thought about that.
From a language perspective what you describe is plain bad.
Implementation should not creep in the language semantics. As a normal
developer I do not want to know how I can redefine special optimized
selectors.
either the compiler
Thanks.
Le 30/4/15 22:57, Marcus Denker a écrit :
On 30 Apr 2015, at 21:47, stepharo steph...@free.fr wrote:
In nautilus I get an error MNU: RBBlockNodemethod
When I select several groups and select merge
mergeGroups: aCollection
aCollection
ifNotEmpty: [:groups || group |
Marcus we should add a rule for the or: [b]
Stef
Le 30/4/15 22:57, Marcus Denker a écrit :
On 30 Apr 2015, at 21:47, stepharo steph...@free.fr wrote:
In nautilus I get an error MNU: RBBlockNodemethod
When I select several groups and select merge
mergeGroups: aCollection
aCollection
On 01 May 2015, at 10:08, stepharo steph...@free.fr wrote:
Marcus we who
uld add a rule for the or: [b]
Not possible as it is correct if the receiver is a boolean.
Marcus
On 01 May 2015, at 10:17, Marcus Denker marcus.den...@inria.fr wrote:
On 01 May 2015, at 10:10, stepharo steph...@free.fr wrote:
Clement
thanks for the information. I thought about that.
From a language perspective what you describe is plain bad. Implementation
should not creep
On 01 May 2015, at 11:46, stepharo steph...@free.fr wrote:
We should at least have a rules stating pay attentino you use an optimised
selector. Im not sure what should be form of the warning but we should make
progress
why?
I see two cases
- the dev uses a non optimized version
On 01 May 2015, at 11:48, stepharo steph...@free.fr wrote:
To make the whole thing easier to understand we need to distinguish the two
bugs.
1) or: is somehow special. No, it is not. We fixed that, but the fix was
broken.
See my other mail.
I would add two different kind of
To make the whole thing easier to understand we need to distinguish the two
bugs.
1) or: is somehow special. No, it is not. We fixed that, but the fix was broken.
See my other mail.
I would add two different kind of rules to help people and slow the use
of redefinition of special
Well, we need to have that discussion then, since we can't roll back: the
slots are already there, and I guess that with the Meta links, we will have
to do something about it.
So, what would it take to improve the debugger?
Since you can add meta links to any ast node the best approach
Le 01/05/2015 13:43, Clément Bera a écrit :
2015-05-01 11:58 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com
mailto:thierry.goub...@gmail.com:
Le 01/05/2015 11:50, Marcus Denker a écrit :
On 01 May 2015, at 11:48, stepharo steph...@free.fr
2015-05-01 11:58 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com:
Le 01/05/2015 11:50, Marcus Denker a écrit :
On 01 May 2015, at 11:48, stepharo steph...@free.fr wrote:
To make the whole thing easier to understand we need to distinguish the
two bugs.
1) or: is somehow special.
2015-05-01 13:59 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com:
Le 01/05/2015 13:43, Clément Bera a écrit :
2015-05-01 11:58 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com
mailto:thierry.goub...@gmail.com:
Le 01/05/2015 11:50, Marcus Denker a écrit :
On 01
You cannot easily redefine these selectors:
#(#caseOf: #to:do: #ifNotNil: #ifNil:ifNotNil: #whileTrue: #ifNotNil:ifNil:
#ifFalse: #timesRepeat: #whileTrue #caseOf:otherwise: #whileFalse: #ifNil:
#to:by:do: #ifTrue: #ifFalse:ifTrue: #or: #whileFalse #ifTrue:ifFalse:
#and:)
You can redefine those
On Fri, May 1, 2015 at 4:31 AM, Clément Bera bera.clem...@gmail.com wrote:
You cannot easily redefine these selectors:
#(#caseOf: #to:do: #ifNotNil: #ifNil:ifNotNil: #whileTrue:
#ifNotNil:ifNil: #ifFalse: #timesRepeat: #whileTrue #caseOf:otherwise:
#whileFalse: #ifNil: #to:by:do: #ifTrue:
22 matches
Mail list logo
