Branch: refs/heads/4.0
Home: https://github.com/pharo-project/pharo-core
Commit: 3af8b8b3f8f6c59bfdf452bdb2b6bd8526120f26
https://github.com/pharo-project/pharo-core/commit/3af8b8b3f8f6c59bfdf452bdb2b6bd8526120f26
Author: Jenkins Build Server
Date: 2014-07-11 (Fri, 11 Jul 2014
Branch: refs/tags/40081
Home: https://github.com/pharo-project/pharo-core
Thanks Marcus I will continue to work on Polymorph reorganization
On 11/7/14 10:02, GitHub wrote:
Branch: refs/heads/4.0
Home: https://github.com/pharo-project/pharo-core
Commit: 3af8b8b3f8f6c59bfdf452bdb2b6bd8526120f26
https://github.com/pharo-project/pharo-core/commit/3a
Hi guys
I would like to experiment with template for a small web project I have
(my web page) and
I would like to try mustache. Is there any tutorial? doc?
I know that "jose maria aguerra" wrote a tutorial but I cannot find it
anymore.
Stef
I would like to see if there is an XHTML outputer that takes it into
account.
I will check pillar.
Stef
On 11/7/14 10:43, stepharo wrote:
Hi guys
I would like to experiment with template for a small web project I
have (my web page) and
I would like to try mustache. Is there any tutorial? do
On 19 Jun 2014, at 11:04, Marcus Denker wrote:
>
> On 19 Jun 2014, at 10:40, Torsten Bergmann wrote:
>
>> On the http://files.pharo.org page the picture
>> is missing (it references http://www.pharo-project.org/images/pharo.png)
>> and I think this is gone due to the website redesign.
>
> Ye
Am 11.07.2014 um 10:43 schrieb stepharo :
> Hi guys
>
> I would like to experiment with template for a small web project I have (my
> web page) and
> I would like to try mustache. Is there any tutorial? doc?
> I know that "jose maria aguerra" wrote a tutorial but I cannot find it
> anymore.
h
Le 10/07/2014 18:59, Damien Pollet a écrit :
as far as I am concerned (I'm certainly not up-to-date on recent enhancements)…
- filetree is a pain because of the double-commit workflow (MC with
dummy message to serialize, then git)
- gitfiletree is a pain because it insists on using a file brow
Hello.
I found interesting thing:
Why it is like this?
Best regards,
Natalia
:)
in Smalltalk, the division of two integers is a fraction, not a float.
i.e. 1/5 is 1/5.
Thierry
Le 11/07/2014 15:53, Natalia Tymchuk a écrit :
Hello.
I found interesting thing:
Why it is like this?
Best regards,
Natalia
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systè
Usually comparing against floats is not as deterministic as you would
expect. And in other dialects you use #equals: instead of #=
But in Pharo there is no #equals: and instead there is a #closeTo:,
but #closeTo: has an arbitrary decimal precision, more than enough for
commong arithmetic.
Regards
why not round it before comparing it ? looks like an easy enough problem to
fix . I would expect that to be equal.
On Fri, Jul 11, 2014 at 5:18 PM, Yuriy Tymchuk wrote:
> That’s why mathematics and programming are two different things…
>
>
> On 11 Jul 2014, at 16:08, Esteban A. Maringolo
> wro
That’s why mathematics and programming are two different things…
On 11 Jul 2014, at 16:08, Esteban A. Maringolo wrote:
> Usually comparing against floats is not as deterministic as you would
> expect. And in other dialects you use #equals: instead of #=
>
> But in Pharo there is no #equals: an
On 11 Jul 2014, at 16:22, kilon alios wrote:
> why not round it before comparing it ? looks like an easy enough problem to
> fix . I would expect that to be equal.
because it wouldn’t be correct :)
>
>
> On Fri, Jul 11, 2014 at 5:18 PM, Yuriy Tymchuk wrote:
> That’s why mathematics and prog
On 11 Jul 2014, at 16:30, Esteban Lorenzano wrote:
> On 11 Jul 2014, at 16:22, kilon alios wrote:
>
>> why not round it before comparing it ? looks like an easy enough problem to
>> fix . I would expect that to be equal.
>
> because it wouldn’t be correct :)
But then why 4/2 = 2?
>
>>
>>
Am 11.07.2014 um 16:33 schrieb Yuriy Tymchuk :
>
> On 11 Jul 2014, at 16:30, Esteban Lorenzano wrote:
>
>> On 11 Jul 2014, at 16:22, kilon alios wrote:
>>
>>> why not round it before comparing it ? looks like an easy enough problem to
>>> fix . I would expect that to be equal.
>>
>> becaus
I would put it this way:
- If you writing code, which requires comparing two floating-point values
for equality, then you do something wrong.
--
Best regards,
Igor Stasenko.
But why
185/10 = 18.5 -> true?
On Jul 11, 2014, at 4:40 PM, Norbert Hartl wrote:
>
> Am 11.07.2014 um 16:33 schrieb Yuriy Tymchuk :
>
>>
>> On 11 Jul 2014, at 16:30, Esteban Lorenzano wrote:
>>
>>> On 11 Jul 2014, at 16:22, kilon alios wrote:
>>>
why not round it before comparing it
On 11 juil. 2014, at 17:01, Igor Stasenko wrote:
> I would put it this way:
> - If you writing code, which requires comparing two floating-point values for
> equality, then you do something wrong.
:D
Rule of thumb: don't use floats ;)
>
> --
> Best regards,
> Igor Stasenko.
2014-07-11 12:02 GMT-03:00 Natalia Tymchuk :
> But why
> 185/10 = 18.5 -> true?
It is not deterministic. That's why you can't rely on such comparisons.
Regards!
Hi Natalia,
The major problem comes from float memory representation.
You can read the beginning of chapter "Fun with Floats" of Deep into Pharo
that gives examples of why comparing floats is dangerous.
http://rmod.lille.inria.fr/deepIntoPharo/
#Luc
2014-07-11 17:02 GMT+02:00 Natalia Tymchuk :
On 11 juil. 2014, at 17:02, Natalia Tymchuk
wrote:
> But why
> 185/10 = 18.5 -> true?
Because 18.5 has an exact float representation, while 0.2 hasn't.
Couldn't we use #asApproximateFraction instead of #asTrueFraction in
Float>>adaptToFraction:andCompare: ?
0.2 asApproximateFraction ==> (1
Thanks all of you.
Best regards,
Natalia
On Jul 11, 2014, at 5:14 PM, Camille Teruel wrote:
>
> On 11 juil. 2014, at 17:02, Natalia Tymchuk
> wrote:
>
>> But why
>> 185/10 = 18.5 -> true?
>
> Because 18.5 has an exact float representation, while 0.2 hasn't.
>
> Couldn't we use #asApproxim
2014-07-11 17:14 GMT+02:00 Camille Teruel :
>
> On 11 juil. 2014, at 17:02, Natalia Tymchuk
> wrote:
>
> But why
> 185/10 = 18.5 -> true?
>
>
> Because 18.5 has an exact float representation, while 0.2 hasn't.
>
> Couldn't we use #asApproximateFraction instead of #asTrueFraction in
> Float>>adapt
Hi all
I'm going over PluggableListMorph extension to see if we can absorb a
bit the extension.
PluggableListMorph>>setListFont
"set the font for the list"
StandardFonts chooseFontWithTitle: 'Choose the font for this list'
translated for: self setSelector: #font: getSelector: #font
This is not that we do not care. This is that we are busy. If you want
to make some step in that direction
try to OSWindow bug tracker issue and see if it is working for you.
Because probably that the solution will be using OSWindow
Stef
Dear Pharo developers,
can we deal somehow with this is
I suggest you to read the Small number chapter of the Deep into Pharo.
Stef
On 11/7/14 15:53, Natalia Tymchuk wrote:
Hello.
I found interesting thing:
Why it is like this?
Best regards,
Natalia
Hello,
It will be really helpful if someone can comment on that, as I am not able to
proceed.
Thanks,
Harshit
From: Pharo-dev [pharo-dev-boun...@lists.pharo.org] on behalf of harshit
[hdoka...@illinois.edu]
Sent: Thursday, July 10, 2014 7:37 PM
To: pharo
It complied on Lion with thr config above.
Now if you could do a build with -g and look at why you segfault with gdb
we could tell more.
Phil
On Friday, July 11, 2014, Dokania, Harshit wrote:
> Hello,
>
> It will be really helpful if someone can comment on that, as I am not able
> to proceed.
Thanks for your reply.
I was not sure where to use "-g" option, I tried using ./odbxtest -g -b mysql
-h localhost -p 3306 -d sodbxtest -u sodbxtest -w sodbxtest.
But that didn't work.
Harshit
From: Pharo-dev [pharo-dev-boun...@lists.pharo.org] on behalf
Le 11 juil. 2014 10:50, "stepharo" a écrit :
>
> I would like to see if there is an XHTML outputer that takes it into
account.
> I will check pillar.
Pillar uses mustache
I don't think it makes sense to compare floating point numbers to other
types of numbers with #=... there's a world of approximations and other
factors hiding behind #=, and the occasional true answer confuses more
than it helps. On top of that, then you get x = y => x hash = y hash,
and so th
2014-07-12 0:40 GMT+02:00 Andres Valloud
:
> I don't think it makes sense to compare floating point numbers to other
> types of numbers with #=... there's a world of approximations and other
> factors hiding behind #=, and the occasional true answer confuses more than
> it helps. On top of that,
I don't think it makes sense to compare floating point numbers to
other types of numbers with #=... there's a world of approximations
and other factors hiding behind #=, and the occasional true answer
confuses more than it helps. On top of that, then you get x = y =>
x hash =
2014-07-12 1:29 GMT+02:00 Andres Valloud
:
> I don't think it makes sense to compare floating point numbers to
>> other types of numbers with #=... there's a world of approximations
>> and other factors hiding behind #=, and the occasional true answer
>> confuses more than it help
In short, my point is that if one is going to "optimize" using floating
point, then be thorough. If everything is a float, then conversion
isn't a problem, comparison isn't a problem, etc. Starting from a more
consistent place makes painful contortions unnecessary.
On 7/11/14 17:19 , Nicolas
2014-07-12 2:26 GMT+02:00 Andres Valloud
:
> In short, my point is that if one is going to "optimize" using floating
> point, then be thorough. If everything is a float, then conversion isn't a
> problem, comparison isn't a problem, etc. Starting from a more consistent
> place makes painful con
37 matches
Mail list logo
