The reason that ifNil: is not found is that it is inlined. If you view
the bytecode representation of an ifNil: send, you see that this
message is never sent. The search looks for symbols in the literal
frame of compiled methods and hence does not find this special case.
Cheers,
Adrian
On
Retested the FFI stuff.. All tests are green and my ODBC stuff works again!
Thanks to all!
Un gros merci à tous!
-
Benoit St-Jean
Yahoo! Messenger: bstjean
Blog: lamneth.wordpress.com
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)
___
2009/7/7 Cameron Sanders
> On Jul 7, 2009, at 7:39 PM, Mariano Martinez Peck wrote (below my original
> text):
>
> can you give us a concrete example?
>
> In my opinion, if you have a symbol with that text, it must be found by
> "senders of it". In VAST it is like that.
> So, if you have #ifNil:
In the end, perhaps the issue is:
* When users see 1.3, they think decimal floating point.
* When programmers see 1.3, they should think binary floating point, but
would like to assume decimal floating point.
At the end of the day, insisting on seeing 1.3 as decimal floating point
runs contrar
2009/7/8 Hernan Wilkinson :
> ok, let me start again.
> 1) I created the issue because 13/10 = 1.3 works different in the new pharo
> image that in vw, va, dolphin, squeak and the previous pharo version, so I
> thought it was a bug
> 2) I understand that comparing floats is not good and I also unde
I like Groovy:
1.3 == 13/10 -> true
1.3*1.3 == 169/100 -> true
0.1 == 1/10 -> true
9.731e20 < 9.730e20 -> false
0.5 == 1/2 -> true
2009/7/7 Hernan Wilkinson
> ok, let me start again.1) I created the issue because 13/10 = 1.3 works
> different in the new pharo image that in vw, va, dolph
On Jul 7, 2009, at 7:39 PM, Mariano Martinez Peck wrote (below my
original text):
can you give us a concrete example?
In my opinion, if you have a symbol with that text, it must be found
by "senders of it". In VAST it is like that.
So, if you have #ifNil: for me it is correct to be found.
ok, let me start again.1) I created the issue because 13/10 = 1.3 works
different in the new pharo image that in vw, va, dolphin, squeak and the
previous pharo version, so I thought it was a bug
2) I understand that comparing floats is not good and I also understand the
representation problems of f
On 7-Jul-09, at 4:09 PM, John M McIntosh wrote:
> self should: [self storedEntry = 0.1].
>
> because
> (1/10) = 0.1 => false
I should note the test is slightly wrong because storedEntry is a
fraction and I should be testing for 1/10
and somewhere in the 100 or so other tests I'm check f
On 7-Jul-09, at 6:40 PM, Nicolas Cellier wrote:
> I'm waiting the answer why 1.3*1.3 is different from 169/100. When
> you'll have discovered this, we'll talk about 13/10 = 1.3 on more
> serious bases.
>
> Nicolas
Well for Fraction I do (1.3*1.3 ) asApproximateFraction (169/100)
because people
On Tue, Jul 7, 2009 at 10:04 PM, Andreas Raab wrote:
> Mariano Martinez Peck wrote:
>
>> Andreas: can you see new comments here:
>> http://code.google.com/p/pharo/issues/detail?id=908
>>
>> What do you think?
>>
>
> Close, but not quite right ;-) The problem with your theory is that
> Smalltalk r
Nicolas Cellier wrote:
> Ignacio, not sure your bank handle money with inexact floating point
> arithmetic...
>
Note that it depends on the application... if pricing is inexact, then
being off by $0.01 is fine.
The big issue is the confusion between "1.3" as a floating point value,
and "1.3
>> On a more positive note, according to our current plans, VW 7.7 will
>> provide vastly improved IEEE arithmetic including proper support for INF
>> and NaN.
>>
>> Andres.
>>
>>
>
> That's good news.
> Concerning NaN and Inf, I wonder if really a great idea. This
> introduces all sort of co
Ignacio, not sure your bank handle money with inexact floating point
arithmetic...
ScaledDecimal are made for that.
When they want to "round" your account, they have more efficient rules
(like the one named 'Frais Bancaires' in France).
Such rules are more predictable and rarely with fractions but
2009/7/8 Andres Valloud :
>
>> Il y a même une infinité de Fractions r telles que
>> f-0.5*ulp < r < f+0.5ulp
>>
>>
>
> Yes... find two with small integer numerators and denominators... bonus
> points if you find fractions with small smallIntegers, too.
>
>> Anyway, Andres, tell me what how you can
In school teachers told me that 13/10 = 1.3, applications that handle money
believe the same (at least the ones that i worked on) and then we have to
use some other implementation of numbers because the 3d guys (i also coded
some 3d stuff in C) and the speed guys want the default numbers to be fast
The VW tests use something along the lines of
self assert: aResult isWithin: anInteger ulpsFrom: anExpectedValue
Igor Stasenko wrote:
> As a compromise,
> i propose adding:
>
> Float>>isAlmostZero
> ^ self abs < Epsilon
>
>
> And write tests like:
>
> (13/10) = 1.3
>
> in form:
>
> ((13/10) - 1
> Il y a même une infinité de Fractions r telles que
> f-0.5*ulp < r < f+0.5ulp
>
>
Yes... find two with small integer numerators and denominators... bonus
points if you find fractions with small smallIntegers, too.
> Anyway, Andres, tell me what how you can bear this VW behaviour I
> expose
2009/7/8 Igor Stasenko :
> As a compromise,
> i propose adding:
>
> Float>>isAlmostZero
> ^ self abs < Epsilon
>
>
> And write tests like:
>
> (13/10) = 1.3
>
> in form:
>
> ((13/10) - 1.3) isAlmostZero
>
Yes, there is already #closeTo: with an arbitrary tolerance (absolute
or relative, depending
As a compromise,
i propose adding:
Float>>isAlmostZero
^ self abs < Epsilon
And write tests like:
(13/10) = 1.3
in form:
((13/10) - 1.3) isAlmostZero
--
Best regards,
Igor Stasenko AKA sig.
___
Pharo-project mailing list
Pharo-project@lists.gfo
2009/7/8 Michael van der Gulik :
>
>
> 2009/7/8 Hernan Wilkinson
>>
>> I added this new issue that happens on the latest image.
>> I'm posting it here because I think it is an important bug because it
>> affects the number model.
>> The problem is related with all fractions who's denominator is no
2009/7/8 Nicolas Cellier :
> 2009/7/7 John M McIntosh :
>> Let me step back and say, ok you are possibly breaking existing code,
>> and causing all sorts of confusion for an
>> optimization change? So where is the justification from the
>> optimization viewpoint? Does it make browser
>> windows op
On Tue, Jul 7, 2009 at 6:32 PM, Cameron Sanders wrote:
> Having made some bozo statements lately, I am hesitant to even inquire
> (because I am probably doing something dumb), but...
>
> I noted an error in my code that read xxx isNumber ifNil: [...] and
> figured that when I imported in from Vis
2009/7/8 Hernan Wilkinson
> I added this new issue that happens on the latest image.
> I'm posting it here because I think it is an important bug because it
> affects the number model.
> The problem is related with all fractions who's denominator is not power of
> two. (130/100 = 1.3 or 1/5 = 0.2
2009/7/8 Nicolas Cellier :
> Your cents are valuable!
>
Thanks.
Then 1 more cent:
No doubt , this will require deep refactoring/rethinking the Compiler
& requestor roles.
But it would help greatly in cleaning the Compiler/Parser code from
things which related to handle uncertainties, like
non-exis
On 7-Jul-09, at 2:46 PM, Nicolas Cellier wrote:
> I repeat here my arguments:
> Anyone depending on (13/10) = 1.3 is plain wrong...
Historically and as far as I can tell in all other versions of
smalltalk (13/10) = 1.3 why be different?
If you *want* exact then I suggest you have (13/10)
a
2009/7/8 Andres Valloud :
> The answer is true on 7.6, and I don't think anything changed that for
> 7.7. Historical background aside, I think it's wrong anyway... in the
> hash book, exercise 7.20 asks to find two different fractions that are
> equal to the same float. In other words, if f is a
Your cents are valuable!
2009/7/8 Igor Stasenko :
> My 2 cents:
>
> compiler should always work together with requestor:
>
> Compiler compile: some thing requestor: aRequestor.
>
> Then it could always ask, aRequestor if its interactive, or not,
> but i think, Compiler could live just well without
Ok, now you can close http://code.google.com/p/pharo/issues/detail?id=908
in 10372
On Tue, Jul 7, 2009 at 6:26 PM, Stéphane Ducasse
wrote:
>
> On Jul 7, 2009, at 11:20 PM, Mariano Martinez Peck wrote:
>
> > Stef: Yes, it works. But, I have some questions:
> >
> > 1) Is it ok to have
> >
> > sel
My 2 cents:
compiler should always work together with requestor:
Compiler compile: some thing requestor: aRequestor.
Then it could always ask, aRequestor if its interactive, or not,
but i think, Compiler could live just well without such knowledge at
all - each time it needs some extra data - it
that's issue 941 (not 942)
sorry
On 08 Jul 2009, at 00:46, Johan Brichau wrote:
> Hi,
>
> Adding (new) class methods fails in latest image.
> I described the problem and proposed a fix attached to issue 942
>
>
> Johan Brichau
> johan.bric...@uclouvain.be
>
>
>
>
>
>
Hi,
Adding (new) class methods fails in latest image.
I described the problem and proposed a fix attached to issue 942
Johan Brichau
johan.bric...@uclouvain.be
___
Pharo-project mailing list
Pharo-project@lists.gforge.i
On the other hand, asRational and asFraction are quite synonym to me.
asFraction might as well be implementation dependent...
And asRational can be interpreted this way only for historical reasons (st80).
I want either a short approximated fraction like (13/10), or an exact fraction.
Nicolas
2009
2009/7/7 Stéphane Ducasse :
>
> On Jul 7, 2009, at 11:21 PM, Hernan Wilkinson wrote:
>
>> ok, but can you be sure that your objects are not handling floats?
>> maybe the same code handles floats when you want speed and fractions
>> when you want precision, I remember we did that once but I don't
>>
2009/7/7 Hernan Wilkinson :
> ok, but can you be sure that your objects are not handling floats? maybe the
> same code handles floats when you want speed and fractions when you want
> precision, I remember we did that once but I don't remember if we had to
> compare the numbers...
> I understand yo
On the other hand, VW already has asRational, and it doesn't do what
asFraction does. To some extent, I think #asExactFraction and selectors
like that are misleading. Why would anyone want #asImpreciseFraction,
or #asRationalMoreOrLess...
Nicolas Cellier wrote:
> Hi Andres,
> That's great to
The answer is true on 7.6, and I don't think anything changed that for
7.7. Historical background aside, I think it's wrong anyway... in the
hash book, exercise 7.20 asks to find two different fractions that are
equal to the same float. In other words, if f is a float, and r1 and r2
are fract
No you understand certainly, I wasn't clear. If we provide a nice api
for comparing things are equal it would be a shame to not provide the
convenience for doubles. Newcomers to the environment would not
necessarily understand the pitfalls of testing equality on doubles.
Thus providing convenience
On Mon, 2009-07-06 at 17:38 -0400, Cameron Sanders wrote:
> What are the best places (documentation sources) to get started
> exploring and learning the VM code (the generated C) and Exupery?
>
> I am running on an iMac and would be willing to try to get Exupery
> working on it.
This conversa
2009/7/7 John M McIntosh :
> Let me step back and say, ok you are possibly breaking existing code,
> and causing all sorts of confusion for an
> optimization change? So where is the justification from the
> optimization viewpoint? Does it make browser
> windows open in 1/2 the time?
>
> If it take
10372
ScriptLoader loadFFI should work please check
better comment on ScriptLoader
http://code.google.com/p/pharo/issues/detail?id=637 cleans out
Undeclared
10373
Issue 943: fix polymorph cursor
Polymorph
Fix for colouring of submenu markers.
Having made some bozo statements lately, I am hesitant to even inquire
(because I am probably doing something dumb), but...
I noted an error in my code that read xxx isNumber ifNil: [...] and
figured that when I imported in from VisualWorks, I must have "fixed"
things too hastily. Wondering
Hi Andres,
That's great to see this addition, but it would have been even greater
to call this method #asExactFraction or #asTrueFraction to get some
minimal core API with other dialects...
Anyway, you see the kind of arguments you'll have to provide if you
ever want to follow the path you once pr
On Jul 7, 2009, at 11:21 PM, Hernan Wilkinson wrote:
> ok, but can you be sure that your objects are not handling floats?
> maybe the same code handles floats when you want speed and fractions
> when you want precision, I remember we did that once but I don't
> remember if we had to compare
On Jul 7, 2009, at 11:20 PM, Mariano Martinez Peck wrote:
> Stef: Yes, it works. But, I have some questions:
>
> 1) Is it ok to have
>
> self new installer monticello http:
> 'source.squeakfoundation.org'; ???
>
> or it is just temp ? In addition, why was #squeakfundation removed ?
> this
Hi John,
There is some misunderstanding here.
It just happens that I proposed an optimized implementation, but
optimizing was not my goal.
My goal was to be able to compare number exactly, that's all.
See http://bugs.squeak.org/view.php?id=3374 for funny examples of what
happens when comparison is
so andres what will be the value of
>> (13/10) = 1.3
in VW7.7
On Jul 7, 2009, at 11:18 PM, Andres Valloud wrote:
> VisualWorks introduced LimitedPrecisionReal>>asFraction. That message
> returns the actual floating point value represented by the
> receiver. Of
> course, I messed up and forgot
ok, but can you be sure that your objects are not handling floats? maybe the
same code handles floats when you want speed and fractions when you want
precision, I remember we did that once but I don't remember if we had to
compare the numbers...
I understand your point and I agree with you that err
Stef: Yes, it works. But, I have some questions:
1) Is it ok to have
self new installer monticello http: 'source.squeakfoundation.org'; ???
or it is just temp ? In addition, why was #squeakfundation removed ? this is
because now all is here: source.squeakfoundation.org??? If so, we can
cre
VisualWorks introduced LimitedPrecisionReal>>asFraction. That message
returns the actual floating point value represented by the receiver. Of
course, I messed up and forgot * self sign... but that's the idea (and
it's fixed for 7.7). So, in reality, you should compare
13/10 = 1.3 asFraction
Hernan, floating point values are fractions of the form
+/- m * 2^k
for positive integers m of up to a certain number of bits. Your example
requires
13/10 = m * 2^k
which is not possible. In slow motion...
2^k = 13/10m
To get rid of 13, m must be 13*n...
2^k = 1/10n
Now, 1/10 = 1/5 * 1/2
2009/7/7 Ignacio Vivona :
> The float problem is an implementation problem that i really dont care, i
> only want fast float operations when doing heavy calculation or 3D or
> something like that ... 1.3 should gimme an object modeling a real number
>
OK concerning fast, that's not the main talent
Let me step back and say, ok you are possibly breaking existing code,
and causing all sorts of confusion for an
optimization change? So where is the justification from the
optimization viewpoint? Does it make browser
windows open in 1/2 the time?
If it takes more time milliseconds? to produce
Mariano
I just published in Pharo a new ScriptLoader which I hope fix the
problem.
Could you check it?
Stef
On Jul 5, 2009, at 9:05 PM, Mariano Martinez Peck wrote:
> Andreas: can you see new comments here:
> http://code.google.com/p/pharo/issues/detail?id=908
>
> What do you think?
>
> Than
The float problem is an implementation problem that i really dont care, i
only want fast float operations when doing heavy calculation or 3D or
something like that ... 1.3 should gimme an object modeling a real number
On Tue, Jul 7, 2009 at 5:26 PM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail
I will look at Testing when I have time and see how we can merge our
extension.
Some people know on this list that my life was extremely frantic
(having one hour to relax over the week-end,
or fixing my house until 11'oclock after my daily work for example).
Stef
>> Pharo continues with a not
>>> should not this method use InputSensor?
>
> Sensor is a global pointing to the current sensor instance.
>
> Michael
> P.S. We should remove the old Sensor classes to avoid confusion.
what is the "old sensor class" ?
so we have Sensor -> to InputSensor default or InputEventSensor?
__
2009/7/7 Ignacio Vivona :
> Why not the opposite? The default behavior is 13/10 = 1.3 yields true and
> the new behavior (13/10) asFloat = 1.3 equals false.
> This kind of behavior is a real pain in languages like java, i are you
> bringing this to the smalltalk world?
>
Hi Ignacio.
If you'd provi
IMO no one should rely on (13/10) = 1.3, not even on (13/10) asFloat = 1.3.
Once you introduced a Float, you'd better forget about exact equality.
Do you expect 1.3*1.3 ~= 1.69 ?
I think it's better like this, because you learn to not overtrust
Float equality.
You learn quicker that you should not
Why not the opposite? The default behavior is 13/10 = 1.3 yields true and
the new behavior (13/10) asFloat = 1.3 equals false.
This kind of behavior is a real pain in languages like java, i are you
bringing this to the smalltalk world?
2009/7/7 Hernan Wilkinson
> Hi Nicolas,
> thank you for you
Hi Nicolas,
thank you for your answer. I'm aware of the float representation problems.
But this new behavior sounds more confusing, at least to me... I mean, 1.3
is not a number with representation problems so why do we have to make this
difference? I understand you are trying to avoid the problem
Janko Mivšek wrote:
> Sorry Keith, but I must say this:
>
> The obvious reason Pharoers reject your contributions are not
> contributions as such but your attitude as the contributor. And I'd do
> the same, reject them, because they are dangerous. Because they bring
> you and your attitude with the
Hi Pavel
> Hi,
>
> every UIManager may have its own preference about this behaviour
> (for example the dummy ui manager has no user input). It is cleaner
> solution than to set interactivity for every Compiler instance or
> for the Compiler class.
In fact I have the impression that this is
Sorry Keith, but I must say this:
The obvious reason Pharoers reject your contributions are not
contributions as such but your attitude as the contributor. And I'd do
the same, reject them, because they are dangerous. Because they bring
you and your attitude with them.
Please think that way a bit
Oh, just something I forgot to mention:
ScaledDecimal should behave the way you expect.
1.3s1 = (13/10).
-> true.
1.3s2*1.3s2 = 1.69s2.
-> true
1.3 * 1.3 = 1.69.
-> false
Nicolas
2009/7/7 Nicolas Cellier :
> Hi Hernan,
> This is the new Behavior of Float comparison and it is desired.
>
> 1) 1.
Reinout Heeck wrote:
>> Pharo continues with a not invented here policy, and has made no
>> attempt
>> to review the code based for projects that could be mutually
>> maintained.
>>
>
> I think it is a misanalysis to label that NIH, there are quite
> different factors contributing to the
>
> Pharo continues with a not invented here policy, and has made no attempt
> to review the code based for projects that could be mutually maintained.
> This is a problem, and I shall continue to point it out until it is
> resolved. It's a mindset issue.
>
>
I would like to make my point in a d
Hi Hernan,
This is the new Behavior of Float comparison and it is desired.
1) 1.3 is represented in machine as
(1.3 significandAsInteger printStringRadix: 2) , '.0e' , (1.3 exponent
- Float precision + 1) printString.
-> '2r10100110011001100110011001100110011001100110011001101.0e-52'
Or if you pr
>
> Pharo continues with a not invented here policy, and has made no
> attempt
> to review the code based for projects that could be mutually
> maintained.
I think it is a misanalysis to label that NIH, there are quite
different factors contributing to the lack of pushing contributions
ups
Hi,
every UIManager may have its own preference about this behaviour (for
example the dummy ui manager has no user input). It is cleaner solution than
to set interactivity for every Compiler instance or for the Compiler class.
Cheers,
-- Pavel
On Tue, Jul 7, 2009 at 7:22 PM, Stéphane Ducasse
wr
Miguel Cobá wrote:
> Hey Keith,
>
> please stop this whole fighting attitude.
> In squeak-dev you're fighting vs Andreas, here you're trying to do the
> same with Stephane.
>
When someone points out a problem or an issue, it doesnt make them the
problem. Leveling that attitude is actually abusiv
You are not relating to a licence you are relating to people.
A recent review of my contributions to date, indicates that the
contribution back rate is less than 1%, why does OSS exist again?
Keith
___
Pharo-project mailing list
Pharo-project@lists.g
I added this new issue that happens on the latest image.
I'm posting it here because I think it is an important bug because it
affects the number model.
The problem is related with all fractions who's denominator is not power of
two. (130/100 = 1.3 or 1/5 = 0.2, etc)
(See
Float>>adaptToFraction: r
Hi Mike,
I don't understand. assert:equals: should only be used for exact
equality tests, not for comparing doubles.
Doubles should never go through this method.
Existing tests won't know about assert:equals:
Did I misunderstand you?
- on
On 7 Jul 2009, at 19:24, Michael Roberts wrote:
>
On Tue, Jul 7, 2009 at 12:32 PM, Michael Roberts wrote:
> Guys would it not be cool for each week we pick a different language
> for the pharo list? I would really like to brush up on my
> Frenchand we are very diverse in our group. I think this would
> have two benefits. 1) we would talk less
Guys would it not be cool for each week we pick a different language
for the pharo list? I would really like to brush up on my
Frenchand we are very diverse in our group. I think this would
have two benefits. 1) we would talk less and write more code 2) we
would permanently have our tounge inse
OK, done.
- on
On 7 Jul 2009, at 19:11, Stéphane Ducasse wrote:
> Yes!
> May be one day we will arrive to use packages published in other
> places but right now
> critical elements should be in one project.
> Oscar if you see other good addition please push them too.
>
> Stef
>
> PS: I do not
2009/7/7 Stéphane Ducasse :
> pavel I was wondering why you want to have interactiveParserFor: in
> UIManager and not in Compiler?
>
> May be I missed something but I'm ready to learn.
>
> Stef
>
>
Apparently, UIManager provides a hook to force interactive or non
interactive parser to be used whil
If you are adding this it would be good to either add or review
existing implementation that checks the comparison is within a
tolerance. This would be for asserting double values are close but not
necessarily exact. I would rather we didn't get double comparison
going through this method you descr
Stéphane Ducasse wrote:
>>
>> should not this method use InputSensor?
Sensor is a global pointing to the current sensor instance.
Michael
P.S. We should remove the old Sensor classes to avoid confusion.
>>
>> primitiveError: aString
>> "This method is called when the error handling results
pavel I was wondering why you want to have interactiveParserFor: in
UIManager and not in Compiler?
May be I missed something but I'm ready to learn.
Stef
On Jul 7, 2009, at 7:18 PM, Stéphane Ducasse wrote:
>
> From: Pavel Krivanek
> Date: July 6, 2009 2:26:56 PM CEDT
> To: stephane ducass
From: Pavel Krivanek
Date: July 6, 2009 2:26:56 PM CEDT
To: stephane ducasse
Subject: issue 348
Hi Stef,
I updated the issue http://code.google.com/p/pharo/issues/detail?id=348
Cheers,
-- Pavel
___
Pharo-project mailing list
Pharo-project@lists
>
>
> should not this method use InputSensor?
>
> primitiveError: aString
> "This method is called when the error handling results in a
> recursion in
> calling on error: or halt or halt:."
>
> | context |
> (String
> streamContents:
> [
Yes!
May be one day we will arrive to use packages published in other
places but right now
critical elements should be in one project.
Oscar if you see other good addition please push them too.
Stef
PS: I do not why I can open MC repositories but I cannot publish there.
On Jul 7, 2009, at 6:5
Apparently http://squeaksource.com/Testing/ already contains such a
method, but sticks to the java convention. Regardless of which is
better, it would be a bad idea to introduce an identically named
method which reverse the argument order, so I suggest we stick to the
implementation in the
> OK, have posted issue 939 and will post the change shortly ...
>
> http://code.google.com/p/pharo/issues/detail?id=939
>
> TestCase>>assert: actual equals: expected
> actual = expected ifFalse: [self signalFailure: 'Assertion failed.
> Expected: ' , expected printString
> , '; got: ' , actu
On Tue, Jul 7, 2009 at 11:28 AM, Keith Hodges wrote:
> Keith Hodges wrote:
>>> so I'm laughing when people suggest that we are predators.
>>>
>>>
>> I am still counting your contributions back to the packages which you
>> are using, which are public domain, and have public repositories...
>>
>> ans
Hey Keith,
please stop this whole fighting attitude.
In squeak-dev you're fighting vs Andreas, here you're trying to do the
same with Stephane.
Maybe you don't give a book the same value that source code, but
Squeak by example it is
as valuable or maybe more than code than others (including you an
OK, have posted issue 939 and will post the change shortly ...
http://code.google.com/p/pharo/issues/detail?id=939
TestCase>>assert: actual equals: expected
actual = expected ifFalse: [self signalFailure: 'Assertion failed.
Expected: ' , expected printString
, '; got: ' , actual printS
Hi
I wanted to integrate some fixes but apparently the network here does
not let me use MC...
so probably later tonight.
Stef
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pha
Chers amis, désolé pour l'anglais mais comme je voulais que tous les principaux
intéressés comprennent mon point de vue, j'ai choisi l'anglais!
Okay guys, let's put things in perspective here...
Pharo isn't at war with Squeak and vice-versa... Just like any kid, it just
wants to "live it's own
Note that we have 21 nominations for the Awards, which is the new
record! :-)
On 7 juil. 09, at 18:10, Noury Bouraqadi wrote:
> Dear Smalltalkers,
>
> The dead-line for ESUG 2009 early registration is 13th of july.
> So, hurry up and to join the 75 people that had already registered.
> We have
Keith Hodges wrote:
>> so I'm laughing when people suggest that we are predators.
>>
>>
> I am still counting your contributions back to the packages which you
> are using, which are public domain, and have public repositories...
>
> answer zero
>
>
Its not even a technical issue, you ha
> so I'm laughing when people suggest that we are predators.
>
I am still counting your contributions back to the packages which you
are using, which are public domain, and have public repositories...
answer zero
Keith
___
Pharo-project mailing li
Stéphane Ducasse wrote:
> Hi guys
>
> After all the mails in Squeak-dev and all these nice words or explicit
> suggestions about us been assholes, destructors...
> whatever :) I would like to share with you my mindset to you.
>
Might I please request that you read english, no such explicit sta
Dear Smalltalkers,
The dead-line for ESUG 2009 early registration is 13th of july.
So, hurry up and to join the 75 people that had already registered.
We have a great program with many interesting talks.
See the list http://www.esug.org/Conferences/2009/Current+List+of+Talks
The demos are promisi
Hi guys
After all the mails in Squeak-dev and all these nice words or explicit
suggestions about us been assholes, destructors...
whatever :) I would like to share with you my mindset to you.
We do not want a war, nor world domination. :)
We are doing pharo because Smalltalk deserves a good and
Hi Torsten,
please open an issue and attach Romain Robbes to it.
Thank you
On Tue, Jul 7, 2009 at 3:36 PM, Torsten Bergmann wrote:
> Hi there,
>
> try the following in the new pharo-dev:
>
> - create a package in OBBrowser
> - create a class "Foo" and add a class variable "Bar" to it
> - start t
On Jul 7, 2009, at 4:02 PM, François Tanguy wrote:
> Great !
> Did you receive my fax last week for the licence agreement ?
I'm travelling (too much)
so I do not know.
But thanks in advance :)
Stef
>
> Francois
>
> On Tue, Jul 7, 2009 at 3:51 PM, Stéphane Ducasse > wrote:
> Yes!
> You can pub
please go ahead.
I thought we got assert:equals:
Somebody should also have a look at SUnitExtensions one of these days.
On Jul 7, 2009, at 3:58 PM, Oscar Nierstrasz wrote:
>
> Hi Folks,
>
> I seem to recall that we added TestCase>>assert:eauals: to SUnit, but
> now I cannot find it.
>
> It woul
1 - 100 of 116 matches
Mail list logo
