wanted again to point out with this post, that the Debugger/Compiler hangs on Debugging application AFTER he successfully b4, gave an assertException, on : “0<=value<=100” but when you compile again, he hangs for some reason. see the attached image.
KG = public record //Thats the record I played around with:
private
fValue: Double;
constructor(aValue: Double); inline;
begin
fValue := aValue;
{$IFDEF DEBUG}
if aValue < 0 then raise new ArgumentException('Invalid value!');
{$ENDIF}
end;
public
operator Implicit(aVal: Double): KG;
require
0 ≤ aVal ≤ 100;
begin
//var kg: KG := 90.0;
result.fValue := aVal;
end;
method ToString: String; override;
begin
exit fValue.ToString +' kg';
end;
public invariants
0 ≤ fValue ≤ 100;
end;
He stays 4ever in that yellow window of WaterIDE
EDIT: I really belive it has smth to do with when an AssertException occurs, since Before this hang issue, water also denied compilation b4 (sadly I cannot give clear steps to repro this, since it happens somehow randomly timed, when I play around with Invariants in that record) and said: "Access to the EXEPATH denied"
sure marc. the only thing tho is, i need to really strip the island.shared from it (to my knowledge, it shoouuuldnt has smth to do with it,… hopefully…)
As i mentioned tho, sadly I really cannot say exactly when it occurs, but it must be around the invariants/require stuff, would be good if u can just force cpl of assertexceptions and compile again multiple times and see if it occurs, if not, forget it then. Would you actually be able/willing to do some PC-transfer via Discord for instance (like screen sharing live) so i could easily demonstrate it when it occurs, ssince, yea… for now it happens to me somewhat randomly.
PS: the discord stuff ofc only if you are never able to repro this, so I could easily share the scree nwith you and make u see it , If i can repro it at sometime
and the moment that happens, you cannot compile anymore! the only thing you can do is: Close the WaterIDE and restart.
PS: I restarted, compiler with the uncommented and commented variant of the above line of code and now all fine, with both versions:… really strange. What am I doing wrong?
Investigating. unfortunately, turns out I need to wait for a new build will an (unrelated) fix fore Windows/Arm before I can test this, so that means either 2h form now or (more likely, looking at the clock, tomorrow).
FTR, your test case again didn’t compile; I had to remove your Island.Windows project ref and the references to TNumeric again. Can I assume that the hang should repro without that code?
As a side question what exactly is you’re plan here with TNumeric, and why are you adding it to a custom build of Island RTL, rather than in your one code?
The Idea behind this is, that it is supposed to find its ways into the IslandRTL itself, since it defines the Basetype for every Number, so you can cast so to speak: anonymously any Basetype which represents a Numeric value, my TNumeric can ensure then that it really represents a Numeric Value, so all of these
Boolean (can be only used by (<>; =) operators)
Int8
Int16
Int32
Int64
UInt8
UInt32
UInt64
Single
Double
Char (ofc if it can ensure it represents a numeric value)
String (ofc if it can ensure it represents a numeric value)
Except Boolean, all the above types (Char/String => aswell, but ONLY if its a number) you can use all Logical and Arithmetics Operator on those variables of that type.
This very useful for generic computation who sometimes need a pure restriction of a specific Type being only a Number and nothing else (I have had discussions with some ppl from Discord over this cpl of months ago) soyou can use it as generic constraint (even in IslandRTL itself there are alot of cast between Object and those basetypes and I saw optimization potential in those where I could change Object with TNumeric, granted not something rocket-science like but still, can be an overall decent improvement
And interallly, I cast the type of the TNumeric value into the proper type , so if u pass in, (as arguments to a method who takes those types) 100 + 221, it will see that both types fit in “Int8” and use those as 2 operands of Int8(value) and the result will be casted back to TNumeric, so wahtever the result is, it will be the proper datatype behind it. and not use more memory than needed.
I tested it with so far 3 basic types and it works wonders and as I said, it takes the best possible basetype for it, so if the value fits in a byte, it takes byte, if it is negative, it automatically takes Int8.
and also used it as a generic parameter. Note that Carlo had something like INumber already for all Basetypes but interfaces for such types are really a perfomance killer when used abit more than 1 time. So I wanted to change that and did so far successfully.
so u easily can do this:
method Computation(const a, b: TNumeric);
begin
result := a + b; //works fine.
end;
var result := Computation(100, 0.34); //prints : 100,34;
This is way more lightweifght than constantly boxing types from Object(class) to these types which I saw quiet frequently in the IslandRTL.
this seems expected, as you assign 101 and the implicit cast operator requires the value to be ≤ 100.
if I change the code to pass 100, the program runs w/o any exceptions, and prints:
~> Process ConsoleApplication4 started.
20
False
False
<gt9_@sTuple`2u8s 000000-471658912>
<gt9_@sTuple`2u8s 000000-471659168>
~> Process ConsoleApplication4 terminated with exit code 0. Ran for 0.468
so no Stack Overflow, and no Debugger hang… what am I missing?
Marc, thx for testing this first of all with what you can.
And secondly, I really cannot provide you more, as I said I hardcore played around with these invariants, and assertexceptions, do you dont get any hang/freeze or the like when forcing multiple assertexepctions could you test this once and for all, so we can for now see that only my wood pc maybe is an issue with that, idk.
Just compile like 6 times with the number 101 to force this exception and watch closely if the debugger/water IDe window stays yellow and whether you can close/shut down the idea by doing “Stop Debug”
I have a hard time believing that this project Stack-Overflows for you, when it doesn’t for me. Whether I compile it once of 6 times should not make a difference for the programs behavior…
Im not trying to mock you mate, I have sent you the screenshots, that the debugger stood yellow (when water compiler/debugs) and atsomepoint I even got the “access denied to the exepath” everytime from then I tried tto compile, and yes sometimes there is this phenomen where you can force such issues by tryharding and forcing billions of compile steps, depends ofc. but I have for sure other things to do than to mock you with such…
all I’m saying, mate, is that I cannot reproduce the debugger issue you describe, with there project toys sent. There’s no Stack Overflow happening in your app, as far as I can see.
All fine then, we leave it for now. I mentioned multiple times that sadly there is no clear step to repro this, I wanted to make this clear that I unfortunately cannot repro this in algorithmic steps to easily see this on ur sided, thats why I wanted to semi direct you to the “Invariants/AssertionStuff” to maaayyybe see that what I have encountered and try some wild combos out of compiling multiple times forcing crashes hence multiple times and see if it starts showing that behaviour, but if you did this, and you cannot see it, it may just be my wood like computer.
Well this is closed for now as I am not able to repro this anymore with build: .2591, be it with custom-test exception I raise in different scenarios or normal-usecase exception ( when you broke smth ) so nice
