Conversions from `Decimal` to `Integer` and `Float`. #9462

GregoryTravis · 2024-03-18T19:09:01Z

Pull Request Description

Adds .to_integer and .to_float, as well as from conversions.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

The documentation has been updated, if necessary.
Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:
- Unit tests have been written where possible.
- If GUI codebase was changed, the GUI was tested when built using ./run ide build.

GregoryTravis · 2024-03-18T19:14:12Z

test/Base_Tests/src/Data/Decimal_Spec.enso

+            huge_a_int = Integer.from huge_a
+
+            (huge_a_int == huge_a) . should_be_true # succeeds
+            (huge_a == huge_a_int) . should_be_true # fails


@JaroslavTulach I suspect that I am improperly returning a value from .to_integer here, resulting in this failure.

huge_a_int shall be converted to Decimal and the decimal comparator shall be invoked to compute hash and compare. If that's not happening, only debugger can tell us what's going on.

The code to reproduce the problem is

from Standard.Base import all main = huge_a = Decimal.new "3.4E320" huge_a_int = Integer.from huge_a (huge_a == huge_a_int)

The selected specialization is EqualsSimpleNode.equalsDifferent. It is true that the "primitiveness" of both values is different:

JavaObject[340000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (java.math.BigInteger)] isPrimitive(other, interop) true isPrimitive(self, interop) false self Value JavaObject[3.4E+320 (java.math.BigDecimal)]

but there is a conversion between one and another - e.g. we should be continuing to EqualsNode.findConversions. Which we do, but then the conversion between the values fails.

I believe it is because InvokeConversionNode is using TypesLibrary, while we should TypeOfNode, I think (right now)!

This is a possible fix:

diff --git engine/runtime/src/main/java/org/enso/interpreter/node/callable/IndirectInvokeConversionNode.java engine/runtime/src/main/java/org/enso/interpreter/node/callable/IndirectInvokeConversionNode.java index 6e03c9c10f..5afb6a0055 100644 --- engine/runtime/src/main/java/org/enso/interpreter/node/callable/IndirectInvokeConversionNode.java +++ engine/runtime/src/main/java/org/enso/interpreter/node/callable/IndirectInvokeConversionNode.java @@ -11,14 +11,15 @@ import org.enso.interpreter.node.BaseNode; import org.enso.interpreter.node.callable.dispatch.IndirectInvokeFunctionNode; import org.enso.interpreter.node.callable.resolver.ConversionResolverNode; import org.enso.interpreter.node.callable.resolver.HostMethodCallNode; +import org.enso.interpreter.node.expression.builtin.meta.TypeOfNode; import org.enso.interpreter.runtime.EnsoContext; import org.enso.interpreter.runtime.callable.UnresolvedConversion; import org.enso.interpreter.runtime.callable.argument.CallArgumentInfo; import org.enso.interpreter.runtime.callable.function.Function; import org.enso.interpreter.runtime.data.ArrayRope; +import org.enso.interpreter.runtime.data.Type; import org.enso.interpreter.runtime.data.text.Text; import org.enso.interpreter.runtime.error.*; -import org.enso.interpreter.runtime.library.dispatch.TypesLibrary; @GenerateUncached @ReportPolymorphism @@ -45,7 +46,11 @@ abstract class IndirectInvokeConversionNode extends Node { BaseNode.TailStatus isTail, int thatArgumentPosition); - @Specialization(guards = {"typesLib.hasType(that)", "!typesLib.hasSpecialDispatch(that)"}) + static boolean hasType(TypeOfNode typesLib, Object value) { + return typesLib.execute(value) instanceof Type; + } + + @Specialization(guards = {"hasType(typesLib, that)"}) Object doConvertFrom( MaterializedFrame frame, Object state, @@ -58,13 +63,16 @@ abstract class IndirectInvokeConversionNode extends Node { InvokeCallableNode.ArgumentsExecutionMode argumentsExecutionMode, BaseNode.TailStatus isTail, int thatArgumentPosition, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary typesLib, + @Shared("typesLib") @Cached TypeOfNode typesLib, @Shared("conversionResolverNode") @Cached ConversionResolverNode conversionResolverNode, @Shared("indirectInvokeFunctionNode") @Cached IndirectInvokeFunctionNode indirectInvokeFunctionNode) { Function function = conversionResolverNode.expectNonNull( - that, InvokeConversionNode.extractType(this, self), typesLib.getType(that), conversion); + that, + InvokeConversionNode.extractType(this, self), + (Type) typesLib.execute(that), + conversion); return indirectInvokeFunctionNode.execute( function, frame, @@ -201,12 +209,7 @@ abstract class IndirectInvokeConversionNode extends Node { } } - @Specialization( - guards = { - "!methods.hasType(that)", - "!interop.isString(that)", - "!methods.hasSpecialDispatch(that)" - }) + @Specialization(guards = {"hasType(methods, that)", "!interop.isString(that)"}) Object doFallback( MaterializedFrame frame, Object state, @@ -219,7 +222,7 @@ abstract class IndirectInvokeConversionNode extends Node { InvokeCallableNode.ArgumentsExecutionMode argumentsExecutionMode, BaseNode.TailStatus isTail, int thatArgumentPosition, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary methods, + @Shared("typesLib") @Cached TypeOfNode methods, @Shared("interop") @CachedLibrary(limit = "10") InteropLibrary interop) { throw new PanicException( EnsoContext.get(this).getBuiltins().error().makeNoSuchConversion(self, that, conversion), diff --git engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeConversionNode.java engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeConversionNode.java index 6efd572037..16ca5a626c 100644 --- engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeConversionNode.java +++ engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeConversionNode.java @@ -15,6 +15,7 @@ import java.util.concurrent.locks.Lock; import org.enso.interpreter.node.BaseNode; import org.enso.interpreter.node.callable.dispatch.InvokeFunctionNode; import org.enso.interpreter.node.callable.resolver.ConversionResolverNode; +import org.enso.interpreter.node.expression.builtin.meta.TypeOfNode; import org.enso.interpreter.runtime.EnsoContext; import org.enso.interpreter.runtime.callable.UnresolvedConversion; import org.enso.interpreter.runtime.callable.argument.CallArgumentInfo; @@ -29,7 +30,6 @@ import org.enso.interpreter.runtime.error.PanicException; import org.enso.interpreter.runtime.error.PanicSentinel; import org.enso.interpreter.runtime.error.Warning; import org.enso.interpreter.runtime.error.WithWarnings; -import org.enso.interpreter.runtime.library.dispatch.TypesLibrary; import org.enso.interpreter.runtime.state.State; public abstract class InvokeConversionNode extends BaseNode { @@ -99,7 +99,11 @@ public abstract class InvokeConversionNode extends BaseNode { return extractType(this, self); } - @Specialization(guards = {"dispatch.hasType(that)", "!dispatch.hasSpecialDispatch(that)"}) + static boolean hasType(TypeOfNode typesLib, Object value) { + return typesLib.execute(value) instanceof Type; + } + + @Specialization(guards = {"hasType(dispatch, that)"}) Object doConvertFrom( VirtualFrame frame, State state, @@ -107,9 +111,9 @@ public abstract class InvokeConversionNode extends BaseNode { Object self, Object that, Object[] arguments, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary dispatch, + @Shared("typesLib") @Cached TypeOfNode dispatch, @Shared("conversionResolverNode") @Cached ConversionResolverNode resolveNode) { - var thatType = dispatch.getType(that); + var thatType = (Type) dispatch.execute(that); if (thatType == self) { return that; } else { @@ -127,7 +131,7 @@ public abstract class InvokeConversionNode extends BaseNode { Object self, DataflowError that, Object[] arguments, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary dispatch, + @Shared("typesLib") @Cached TypeOfNode dispatch, @Shared("conversionResolverNode") @Cached ConversionResolverNode conversionResolverNode) { Function function = conversionResolverNode.execute( @@ -234,8 +238,7 @@ public abstract class InvokeConversionNode extends BaseNode { @Specialization( guards = { - "!typesLib.hasType(that)", - "!typesLib.hasSpecialDispatch(that)", + "!hasType(typesLib, that)", "!interop.isTime(that)", "interop.isDate(that)", }) @@ -247,7 +250,7 @@ public abstract class InvokeConversionNode extends BaseNode { Object that, Object[] arguments, @Shared("interop") @CachedLibrary(limit = "10") InteropLibrary interop, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary typesLib, + @Shared("typesLib") @Cached TypeOfNode typesLib, @Shared("conversionResolverNode") @Cached ConversionResolverNode conversionResolverNode) { Function function = conversionResolverNode.expectNonNull( @@ -257,8 +260,7 @@ public abstract class InvokeConversionNode extends BaseNode { @Specialization( guards = { - "!typesLib.hasType(that)", - "!typesLib.hasSpecialDispatch(that)", + "!hasType(typesLib, that)", "interop.isTime(that)", "!interop.isDate(that)", }) @@ -270,7 +272,7 @@ public abstract class InvokeConversionNode extends BaseNode { Object that, Object[] arguments, @Shared("interop") @CachedLibrary(limit = "10") InteropLibrary interop, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary typesLib, + @Shared("typesLib") @Cached TypeOfNode typesLib, @Shared("conversionResolverNode") @Cached ConversionResolverNode conversionResolverNode) { Function function = conversionResolverNode.expectNonNull( @@ -280,8 +282,7 @@ public abstract class InvokeConversionNode extends BaseNode { @Specialization( guards = { - "!typesLib.hasType(that)", - "!typesLib.hasSpecialDispatch(that)", + "!hasType(typesLib, that)", "interop.isTime(that)", "interop.isDate(that)", }) @@ -293,7 +294,7 @@ public abstract class InvokeConversionNode extends BaseNode { Object that, Object[] arguments, @Shared("interop") @CachedLibrary(limit = "10") InteropLibrary interop, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary typesLib, + @Shared("typesLib") @Cached TypeOfNode typesLib, @Shared("conversionResolverNode") @Cached ConversionResolverNode conversionResolverNode) { Function function = conversionResolverNode.expectNonNull( @@ -303,8 +304,7 @@ public abstract class InvokeConversionNode extends BaseNode { @Specialization( guards = { - "!typesLib.hasType(that)", - "!typesLib.hasSpecialDispatch(that)", + "!hasType(typesLib, that)", "interop.isDuration(that)", }) Object doConvertDuration( @@ -315,7 +315,7 @@ public abstract class InvokeConversionNode extends BaseNode { Object that, Object[] arguments, @Shared("interop") @CachedLibrary(limit = "10") InteropLibrary interop, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary typesLib, + @Shared("typesLib") @Cached TypeOfNode typesLib, @Shared("conversionResolverNode") @Cached ConversionResolverNode conversionResolverNode) { Function function = conversionResolverNode.expectNonNull( @@ -325,8 +325,7 @@ public abstract class InvokeConversionNode extends BaseNode { @Specialization( guards = { - "!typesLib.hasType(thatMap)", - "!typesLib.hasSpecialDispatch(thatMap)", + "!hasType(typesLib, thatMap)", "interop.hasHashEntries(thatMap)", }) Object doConvertMap( @@ -337,7 +336,7 @@ public abstract class InvokeConversionNode extends BaseNode { Object thatMap, Object[] arguments, @Shared("interop") @CachedLibrary(limit = "10") InteropLibrary interop, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary typesLib, + @Shared("typesLib") @Cached TypeOfNode typesLib, @Shared("conversionResolverNode") @Cached ConversionResolverNode conversionResolverNode) { Function function = conversionResolverNode.expectNonNull( @@ -345,12 +344,7 @@ public abstract class InvokeConversionNode extends BaseNode { return invokeFunctionNode.execute(function, frame, state, arguments); } - @Specialization( - guards = { - "!methods.hasType(that)", - "!interop.isString(that)", - "!methods.hasSpecialDispatch(that)" - }) + @Specialization(guards = {"!hasType(methods, that)", "!interop.isString(that)"}) Object doFallback( VirtualFrame frame, State state, @@ -358,7 +352,7 @@ public abstract class InvokeConversionNode extends BaseNode { Object self, Object that, Object[] arguments, - @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary methods, + @Shared("typesLib") @Cached TypeOfNode methods, @Shared("interop") @CachedLibrary(limit = "10") InteropLibrary interop, @Shared("conversionResolverNode") @Cached ConversionResolverNode conversionResolverNode) { var ctx = EnsoContext.get(this);

e.g. the problem is truly in inconsistency of TypeOfNode and TypesLibrary - the differences may have wide implications. The real fix should:

either remove TypesLibrary public methods and use TypeOfNode everywhere

or move TypeOfNode behavior to default implementation of TypesLibrary and remove direct usages of TypeOfNode

Trying the alternative approach of moving TypeOfNode behavior to TypesLibrary here - not yet fully working, but also not fully broken.

Trying the alternative approach of moving TypeOfNode behavior to TypesLibrary here - not yet fully working, but also not fully broken.

@JaroslavTulach Why not the other way around? That is, make the TypeOfNode the default way to fetch the type. I thought that using nodes is more light-weight than using libraries.

@JaroslavTulach This patch does fix the failing test case.

Bug for this: #9547

radeusgd · 2024-03-19T10:10:05Z

distribution/lib/Standard/Base/0.0.0-dev/src/Data/Decimal.enso

+       > Example
+         Convert `Decimal` 2345 to an `Integer`.
+             d = Decimal.new "2345"
+             d.to_integer
+             # => 2345


I'd like us to have an example that shows some more interesting case, e.g. 2345.6 to see what happens with the decimal part? Is it truncated, rounded? Is it only possible to convert if decimal part is .0 and it fails otherwise?

Done. (It succeeds either way.)

radeusgd · 2024-03-19T10:11:40Z

distribution/lib/Standard/Base/0.0.0-dev/src/Data/Decimal.enso

+    ## GROUP CONVERSIONS
+       Convert this to a `Float`.
+
+       > Example
+         Convert `Decimal` 23.45 to a `Float`.
+
+             d = Decimal.new "23.45"
+             d.to_float
+             # => 23.45
+    to_float : Integer
+    to_float self = self.big_decimal.doubleValue


IMO it would be good to say what happens if the Decimal value is too large (IIRC it gets converted to Infinity, right?) - this is not clear and we should clearly state it. Also IMHO in such cases we should be attaching a warning (ideally I'd fail but I know that'd be too annyoing, IMO warning may be a decent compromise between usability and correctness).

I know it's rather obvious, but still I'd add a note that the conversion is not precise (because Float is not precise).

Done -- attached a warning for both. If we are going to always attach a warning for from_float, it makes sense to do the same for to_float, since it's even more likely that there will be a loss of precision in the case of to_float.

radeusgd · 2024-03-19T23:06:46Z

distribution/lib/Standard/Base/0.0.0-dev/src/Data/Decimal.enso

-         Convert `Decimal` 2345 to an `Integer`.
-             d = Decimal.new "2345"
+         Convert `Decimal` 2345.6 to an `Integer`.
+             d = Decimal.new "2345.6"


So the behaviour is truncate? IMO it would be good to specify this clearly in the description. The example is good, but it may mean truncate as well as floor, for example.

Documented and added test.

JaroslavTulach

Please make sure the tests are executed on CI.

JaroslavTulach · 2024-03-20T08:24:48Z

distribution/lib/Standard/Base/0.0.0-dev/src/Data/Decimal.enso

@@ -582,3 +630,9 @@ Decimal.from (that : Text) = Decimal.parse that

 ## PRIVATE
 Decimal.from (that : Number) = Decimal.new that
+
+## PRIVATE


Why are these conversions marked as ## PRIVATE? I believe suggestion database doesn't contain from conversion methods, so the IDE shouldn't display these methods in the component browser anyway.

JaroslavTulach · 2024-03-20T08:35:32Z

test/Base_Tests/src/Data/Decimal_Spec.enso

+            (huge_a_float == huge_a) . should_be_true
+            (huge_a == huge_a_float) . should_be_true
+
+        group_builder.specify "Decimal.to_integer should compare correctly with the original Decimal" pending="Decimal.to_integer comparison" <|


I cannot run this test as:

enso$ ./built-distribution/enso-engine-*/enso-*/bin/enso --run test/Base_Tests/ "Decimal.to_integer"

probably because Decimal_Spec isn't listed in Main.enso. Is it even executed on the CI? I don't see Decimal.to_integer anywhere in the log output!

It is listed in

enso/test/Base_Tests/src/Main.enso

Line 174 in a2fc570

Decimal_Spec.add_specs suite_builder

so it is included in all the tests. But it is still marked as pending

Akirathan · 2024-03-25T10:54:32Z

engine/runtime/src/main/java/org/enso/interpreter/node/expression/builtin/meta/EqualsNode.java

@@ -176,14 +176,22 @@ private static boolean findConversionImpl(
          UnresolvedConversion.build(selfScope).resolveFor(ctx, comparableType, thatType);


[Question not related to the current PR] Why is this conversion built with selfScope and not thatScope? We are looking for a conversion from thatType to Comparable type in selfScope, but shouldn't we be looking for this conversion in a different scope? Is is possible that this is some leftover? @JaroslavTulach

JaroslavTulach · 2024-03-29T03:45:37Z

distribution/lib/Standard/Base/0.0.0-dev/src/Data/Decimal.enso

+             d.to_float
+             # => 23.45
+    to_float : Integer
+    to_float self =


Why there is dec.to_float when there also is a conversion and one can write dec.to Float?

I think the idea was that currently there are no good completions for .to conversions - the IDE will not easily tell you which conversions are available and which ones are not. Having the explicit ones allows it to show up in the Component Browser.

JaroslavTulach · 2024-03-29T06:52:28Z

@GregoryTravis I've just added my fix of #9547 inquiry here as de1228c. Should my fix cause any problems, feel free to remove the commit from this PR. I am sorry, if my fix causes issues, but this branch has the best reproducer and it is easier for me to fix the issue here than create my own reproducer elsewhere or wait while this PR gets merged.

radeusgd · 2024-03-29T09:20:08Z

engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeConversionNode.java

@@ -247,7 +250,7 @@ Object doConvertDate(
      Object that,
      Object[] arguments,
      @Shared("interop") @CachedLibrary(limit = "10") InteropLibrary interop,
-      @Shared("typesLib") @CachedLibrary(limit = "10") TypesLibrary typesLib,
+      @Shared("typesLib") @Cached TypeOfNode typesLib,


Suggested change

@Shared("typesLib") @Cached TypeOfNode typesLib,

@Shared("typesLib") @Cached TypeOfNode typeOfNode,

@JaroslavTulach The type has changed but the name remains as before - shouldn't it be updated?

IMO having names that are inconsistent with what the value is, is likely to introduce confusion.

Names of local variables don't have any effect on the execution. Your suggestion cannot be applied on its own - it would make the code uncompilable.

Names of local variables don't have any effect on the execution.

I know! I'm only complaining about code style. I find such small practices really greatly influencing how easy it is for me to understand the code. The variable name tells something. Sometimes it doesn't say much useful information than the type. But in cases like here, when there's inconsistency - I instantly start to think why the name is the way it is. In the diff I know - for historical reasons, because during refactor the variable names were not updated. But if I will come looking at this code later, without all the historical context - I will get confused and will be wondering what does this unusual name mean - why this instance is a Lib if its type suggests it's a Node - what is happening here? And I will lose time unproductively wondering what has happened here.

I know I'm saying as if this is a big thing. But for me it is. Of course a single variable name is not going to cause harm, but if there's a lot of such situations throughout the codebase, I start wasting more and more time trying to understand what the author meant, and processing the codebase when trying to extend it or fix something takes significantly longer when such things add up.

I guess you are familiar with this part of the codebase, so these things are obvious to you. But if I'm less familiar with it, even such minor details do affect how hard it is to understand pieces of the code. Do you really never experience e.g. bad naming causing confusion and causing you to take more time to understand the codebase?

I once heard a wise saying that code is read more times than it is written - so IMO taking a little bit of extra effort in making it easy to understand greatly pays off in the long term.

I really don't want to be complaining all the time about this, I hope the tone of my complaint above is not too offensive. I just really wanted to share how very frustrated I get when I have a hard time understanding parts of the codebase littered with cryptic variable names or little documentation.

Your suggestion cannot be applied on its own - it would make the code uncompilable.

Sorry, I used suggestion to show how the rename can be applied, but I know we need to update other occurrences. I felt it's enough to suggest what rename is needed, not the whole patch. I may try adding better suggestions next time, but it's not trivial to find all usages in the GitHub review, whereas with any IDE such rename is usually much easier.

@JaroslavTulach this fix worked, thank you very much.
@radeusgd I'll do the renaming.

radeusgd · 2024-03-29T17:10:41Z

distribution/lib/Standard/Base/0.0.0-dev/src/Errors/Common.enso

+    to_display_text : Text
+    to_display_text self =
+        "Value out of range: "+self.value.to_text


IMHO it would be good to indicate what range we exceed, e.g.
Value out of representable Float range: ... in this case.
Do you think we can add this to the error info?

Done in #9586.

radeusgd · 2024-03-29T17:12:01Z

test/Base_Tests/src/Data/Decimal_Spec.enso

+            Problems.expect_only_warning Out_Of_Range f
+            f2 = (-huge_a).to_float
+            f2.should_equal Number.negative_infinity
+            Problems.expect_only_warning Out_Of_Range f2


please test the to_display_text of the warning.

We often used to have typos inside of to_display_text, especially after refacors. If it's not unit tested, we only learn about it when the warning/error comes up in the GUI and is scrambled. Better to have tests for this since we don't have much static analysis capabilities.

Done in #9586.

radeusgd

Looks good, just 2 small comments

JaroslavTulach · 2024-03-30T05:37:37Z

There is an AssertionError failure caused by my TypeOfNode changes.

The issue is deeper. My changes just discovered an error in EnsoFile bultin. There should be no String objects floating thru the Enso interpreter, just Text wrappers around them. The EnsoFile case fixed in 0e4f631

GregoryTravis added 6 commits March 18, 2024 15:04

wip

d76d854

wip

b31874c

Remove unnecessary conversion

2ee2855

changelog

07882c9

also integer

8eda944

cleanup

a8147ed

GregoryTravis commented Mar 18, 2024

View reviewed changes

GregoryTravis marked this pull request as ready for review March 18, 2024 19:14

GregoryTravis requested review from jdunkerley, radeusgd and AdRiley as code owners March 18, 2024 19:14

GregoryTravis requested a review from JaroslavTulach March 18, 2024 19:14

radeusgd reviewed Mar 19, 2024

View reviewed changes

GregoryTravis added 3 commits March 19, 2024 12:49

to_float inf

92925c6

review

d87de7c

Merge branch 'develop' into wip/gmt/8982-conversion-int-float

7c3e7bf

radeusgd reviewed Mar 19, 2024

View reviewed changes

JaroslavTulach requested changes Mar 20, 2024

View reviewed changes

enso-bot bot mentioned this pull request Mar 21, 2024

Conversion of UnresolvedConstructor to real constructor isn't instrumented #9381

Closed

Using multiple simple if conditions

2d42561

GregoryTravis requested review from 4e6, hubertp and Akirathan as code owners March 21, 2024 06:09

GregoryTravis added 2 commits March 21, 2024 13:16

merge

0158728

review

a2fc570

JaroslavTulach approved these changes Mar 22, 2024

View reviewed changes

Akirathan reviewed Mar 25, 2024

View reviewed changes

GregoryTravis added 2 commits March 25, 2024 15:59

Merge branch 'develop' into wip/gmt/8982-conversion-int-float

56d38a1

logging in conversions

e13340d

GregoryTravis added 3 commits March 26, 2024 11:01

merge

286a298

cleanup

381f4d7

revert

1a46e4f

GregoryTravis mentioned this pull request Mar 26, 2024

Use TypeOfNode instead of TypesLibrary in InvokeConversionNode #9547

Closed

GregoryTravis added 3 commits March 26, 2024 11:09

pending test

01aa547

truncation

4fd1bde

merge

3197711

AdRiley approved these changes Mar 28, 2024

View reviewed changes

GregoryTravis requested a review from radeusgd March 28, 2024 19:47

JaroslavTulach approved these changes Mar 29, 2024

View reviewed changes

radeusgd reviewed Mar 29, 2024

View reviewed changes

Use TypeOfNode instead of TypesLibrary in InvokeConversionNode

de1228c

JaroslavTulach force-pushed the wip/gmt/8982-conversion-int-float branch from 8e4a259 to de1228c Compare March 29, 2024 13:19

GregoryTravis added 3 commits March 29, 2024 10:56

merge

d12fad8

combine cases

2942bc7

rename typesLib

d3b135d

GregoryTravis requested a review from radeusgd March 29, 2024 15:32

radeusgd reviewed Mar 29, 2024

View reviewed changes

radeusgd approved these changes Mar 29, 2024

View reviewed changes

enso-bot bot mentioned this pull request Mar 29, 2024

Make sure import and FQN behave the same #9539

Merged

4 tasks

String is not Enso type, return Text

0e4f631

JaroslavTulach mentioned this pull request Mar 30, 2024

Don't let the non-Enso types float around the Enso interpreter! #9584

Merged

2 tasks

GregoryTravis merged commit ff562cb into develop Mar 30, 2024
41 checks passed

GregoryTravis deleted the wip/gmt/8982-conversion-int-float branch March 30, 2024 14:42

GregoryTravis mentioned this pull request Apr 1, 2024

Add range info to Out_Of_Range error #9586

Merged

5 tasks

		@@ -176,14 +176,22 @@ private static boolean findConversionImpl(
		UnresolvedConversion.build(selfScope).resolveFor(ctx, comparableType, thatType);

	@Shared("typesLib") @Cached TypeOfNode typesLib,
	@Shared("typesLib") @Cached TypeOfNode typeOfNode,

Conversions from Decimal to Integer and Float. #9462

Conversions from Decimal to Integer and Float. #9462

Conversation

GregoryTravis commented Mar 18, 2024 • edited Loading

Pull Request Description

Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JaroslavTulach Mar 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

radeusgd Mar 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JaroslavTulach left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JaroslavTulach commented Mar 29, 2024 • edited Loading

Choose a reason for hiding this comment

JaroslavTulach Mar 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

radeusgd left a comment

Choose a reason for hiding this comment

JaroslavTulach commented Mar 30, 2024 • edited Loading

Conversions from `Decimal` to `Integer` and `Float`. #9462

Conversions from `Decimal` to `Integer` and `Float`. #9462

GregoryTravis commented Mar 18, 2024 •

edited

Loading

JaroslavTulach Mar 21, 2024 •

edited

Loading

radeusgd Mar 19, 2024 •

edited

Loading

JaroslavTulach commented Mar 29, 2024 •

edited

Loading

JaroslavTulach Mar 29, 2024 •

edited

Loading

JaroslavTulach commented Mar 30, 2024 •

edited

Loading