Because your exponent is not between: Float emin and: Float emax ?
In other words it is too large and not representable in a
https://en.wikipedia.org/wiki/IEEE_754 double.
> On 19 Dec 2019, at 16:02, Nicolas Anquetil wrote:
>
>
> In pharo 7, inspecting: 1.0e
>
> gives: "Reading a number
In pharo 7, inspecting: 1.0e
gives: "Reading a number failed -> "
it works for: 1.0e333 (only three "3")
is that the expected behaviour ?
nicolas
--
Nicolas Anquetil
RMod team -- Inria Lille
There is a new Pharo build available!
The status of the build #1083 was: SUCCESS.
The Pull Request #5395 was integrated: "Enhance monticello snapshot class
lookup"
Pull request url: https://github.com/pharo-project/pharo/pull/5395
Issue Url:
Hi Alistair
чт, 19 дек. 2019 г. в 07:19, Alistair Grant :
> On Wed, 18 Dec 2019 at 21:45, Denis Kudriashov
> wrote:
> >
> > Following script demonstrates the difference in the error processing
> logic when there is an outer handler:
> >
> > [
> >
> > [MyTestError signal ] on: UnhandledError do:
I would expect that both would result in +Inf.
A IEEE-754 'double' overflows around 2e308.
Surely both cases should behave the same way..??
-t
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
The solution to problem is to resignal UnhandledError instead of simple
signalling. Resignal uses original signalContext as a starting point for
handlers lookup:
UnhandledError>>signalForException: anError
^anError resignalAs: (self new
exception: anError;
yourself)
I played with some of
чт, 19 дек. 2019 г. в 21:43, Denis Kudriashov :
> I checked Squeak. All my examples work consistently there: UnhandledError
> handler is always triggered.
> Even more: signalling new error from the handler block passes it from the
> original signallerContext:
>
> [
>>
>> [ 1/0 ] on: MyTestError
Or in other words why Halt and Warning open debugger directly instead of
using UnhandledError signalling?
In Squeak it's all going though UnhandledError.
Le 2019-12-19 19:54, Denis Kudriashov a écrit :
> Or in other words why Halt and Warning open debugger directly instead of
> using UnhandledError signalling?
>
> In Squeak it's all going though UnhandledError.
Hi Denis,
Thomas Dupriez made a nice documentation from existing materials about
I checked Squeak. All my examples work consistently there: UnhandledError
handler is always triggered.
Even more: signalling new error from the handler block passes it from the
original signallerContext:
[
>
> [ 1/0 ] on: MyTestError do: [ :e | self halt ]
>
> ] on: ZeroDivide do: [ :z |
I will collect here other issues if I will find them.
Looking in Context methods which I mentioned here I found that debugger is
broken for stepping through warnings. And it means that debugging
deprecated methods can hang debugger.
I will create another thread on this issue because it has more
Hi Denis,
Thanks very much for the clarification in your previous email (which I
haven't quoted here), I did indeed misunderstand the point you were
making.
On Thu, 19 Dec 2019 at 19:40, Denis Kudriashov wrote:
>
> The solution to problem is to resignal UnhandledError instead of simple
>
There is a new Pharo build available!
The status of the build #1082 was: SUCCESS.
The Pull Request #5393 was integrated: "CleanupASTCache"
Pull request url: https://github.com/pharo-project/pharo/pull/5393
Issue Url: https://github.com/pharo-project/pharo/issues/CleanupASTCache
Build Url:
чт, 19 дек. 2019 г. в 00:42, Denis Kudriashov :
> I think this problem could lead to debugger issues with stepOver and
> stepThrough. For example:
>
> Context>>#stepToHome:
> ...
> context := aContext insertSender: (Context
> contextOn: UnhandledError do: [:ex | ... ])
>
> It
Hi Alistair.
чт, 19 дек. 2019 г. в 07:10, Alistair Grant :
> I think the difference here is that in the playground 'self' is nil,
> while in the browser 'self' is the class being inspected.
> UndefinedObject>>handleSignal: tells the exception to execute its
> #defaultAction, which is to signal
Hi,
I will give a techtalk today around the work with Spec2 and GTK.
But because of personal reasons, I cannot give the talk 17-18h EU, instead, it
will be one our earlier.
So, this is the appointment:
Pharo TechTalk
19 Dec 2019
4:00 PM - 5:00 PM (UTC+01:00)
A regular chat about Pharo.
16 matches
Mail list logo
