Re: D GUI Framework (responsive grid teaser)
On Monday, 22 June 2020 at 16:43:12 UTC, Robert M. Münch wrote: On 2019-05-19 21:01:33 +, Robert M. Münch said: Hi, we are currently build up our new technology stack and for this create a 2D GUI framework. Some now teaser, again might not look like a lot had happend but we move forward, slow but steady: https://www.dropbox.com/s/jjefzyneqnxr7pb/dgui_teaser-1.mp4 The framework can now handle 9-patch images for decoration of any widget parts. And here an older one I think I never posted, about text editing: https://www.dropbox.com/s/cfqy21q4s7d0zxr/Bildschirmaufnahme%202020-04-07%20um%2017.08.24.mov?dl=0 Cut & Paste, marking, cursor movement etc. is all working correctly. All text stuff (rendering and handling) is done in Unicode. What we first get to work is a way to create simple applications with input-forms, text-lists feed from a database and single line text-editing. Width of the element can be set: - by hand --- fixed - by automate --- inherited from parent --- from childs ( calculated max width ) --- generated by parent layout ( like a HBox, VBox, may be CircleLayout... ) and for each case: - check min width - check max width https://drive.google.com/file/d/1ZbeSkQD2BY06JB1R17CT17te1H9ecRnI/view?usp=sharing and childs can be aligned in container cell to: left. center, right, stretched. https://drive.google.com/file/d/1Xm4m7DLaUoPu5wzvPSalgW3i1-WkTeek/view?usp=sharing It will be good. I love beauty UI too. :) I love fast perfect UI too. And I do D Windows GUI too. :)
Re: D GUI Framework (responsive grid teaser)
On Monday, 22 June 2020 at 16:43:12 UTC, Robert M. Münch wrote: On 2019-05-19 21:01:33 +, Robert M. Münch said: [...] Some now teaser, again might not look like a lot had happend but we move forward, slow but steady: https://www.dropbox.com/s/jjefzyneqnxr7pb/dgui_teaser-1.mp4 The framework can now handle 9-patch images for decoration of any widget parts. And here an older one I think I never posted, about text editing: https://www.dropbox.com/s/cfqy21q4s7d0zxr/Bildschirmaufnahme%202020-04-07%20um%2017.08.24.mov?dl=0 Cut & Paste, marking, cursor movement etc. is all working correctly. All text stuff (rendering and handling) is done in Unicode. What we first get to work is a way to create simple applications with input-forms, text-lists feed from a database and single line text-editing. Will it be open source? Curious why its not hosted public
Re: D GUI Framework (responsive grid teaser)
On 2019-05-19 21:01:33 +, Robert M. Münch said: Hi, we are currently build up our new technology stack and for this create a 2D GUI framework. Some now teaser, again might not look like a lot had happend but we move forward, slow but steady: https://www.dropbox.com/s/jjefzyneqnxr7pb/dgui_teaser-1.mp4 The framework can now handle 9-patch images for decoration of any widget parts. And here an older one I think I never posted, about text editing: https://www.dropbox.com/s/cfqy21q4s7d0zxr/Bildschirmaufnahme%202020-04-07%20um%2017.08.24.mov?dl=0 Cut & Paste, marking, cursor movement etc. is all working correctly. All text stuff (rendering and handling) is done in Unicode. What we first get to work is a way to create simple applications with input-forms, text-lists feed from a database and single line text-editing. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: addle 0.1.0 - argument-dependent lookup for UFCS functions
On Sunday, 21 June 2020 at 00:06:12 UTC, Paul Backus wrote:
import addle;
import std.range;
// Import a type from another module
import mylib: MyStruct;
// Define range primitives for MyStruct
bool empty(MyStruct a) { return false; }
string front(MyStruct a) { return "ok"; }
void popFront(MyStruct a) {}
// MyStruct isn't considered an input range, because
// std.range can't see our UFCS methods.
static assert(isInputRange!MyStruct == false);
// ...but extending it makes those methods visible.
static assert(isInputRange!(Extended!MyStruct));
void main()
{
import std.range: take, only;
import std.algorithm: equal;
MyStruct myStruct;
// Now we can use all of the standard range algorithms
assert(
myStruct.extended
.take(3)
.equal(only("ok", "ok", "ok"))
);
}
As a demonstration of what you can do in D, I love this. Maybe
one day I'll even find a use for it. Good work!
--
Simen
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Monday, 22 June 2020 at 12:07:26 UTC, 9il wrote: On Monday, 22 June 2020 at 12:04:13 UTC, 9il wrote: So the algorithm would look like: 1. Parse hexadecimal big integer 2. Parse exponent 3. Cast big integer to `Fp` with a specific number of meaningful bits (its already implemented) 4. Add exponent to `Fp`'s exponent, and cast the result to a hardware floating point type. My bad, the hexadecimal parsing is already implemented for big integers! http://mir-algorithm.libmir.org/mir_bignum_low_level_view.html#.BigUIntView.fromHexStringImpl So only a bit left to go. Great! So, each part of the algorithm above is implemented. Maybe we need to rework fromHexStringImpl to make it return a boolean value. Good idea. It should pay back when one wants to parse a big amount of strings that are likely to contain a lot of non-integers.
Re: addle 0.1.0 - argument-dependent lookup for UFCS functions
On Sunday, 21 June 2020 at 00:06:12 UTC, Paul Backus wrote: Now available on Dub, by "popular demand"! Links: - Documentation: https://addle.dpldocs.info/addle.html - Dub: https://code.dlang.org/packages/addle - Github: https://github.com/pbackus/addle Cool. Thanks.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Monday, 22 June 2020 at 12:04:13 UTC, 9il wrote: On Monday, 22 June 2020 at 10:53:02 UTC, Dukc wrote: On Sunday, 21 June 2020 at 15:24:14 UTC, 9il wrote: Can mir_parse handle other bases than decimal? No, only the decimal basis is supported for now. Support for hexadecimal FP/integer parsing can be added though. The basic stuff for correct FP hexadecimal parsing is done: we can convert a big integer view to FP number with half-to-even rounding. So the algorithm would look like: 1. Parse hexadecimal big integer 2. Parse exponent 3. Cast big integer to `Fp` with a specific number of meaningful bits (its already implemented) 4. Add exponent to `Fp`'s exponent, and cast the result to a hardware floating point type. My bad, the hexadecimal parsing is already implemented for big integers! http://mir-algorithm.libmir.org/mir_bignum_low_level_view.html#.BigUIntView.fromHexStringImpl So, each part of the algorithm above is implemented. Maybe we need to rework fromHexStringImpl to make it return a boolean value.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Monday, 22 June 2020 at 10:53:02 UTC, Dukc wrote: On Sunday, 21 June 2020 at 15:24:14 UTC, 9il wrote: Can mir_parse handle other bases than decimal? No, only the decimal basis is supported for now. Support for hexadecimal FP/integer parsing can be added though. The basic stuff for correct FP hexadecimal parsing is done: we can convert a big integer view to FP number with half-to-even rounding. So the algorithm would look like: 1. Parse hexadecimal big integer 2. Parse exponent 3. Cast big integer to `Fp` with a specific number of meaningful bits (its already implemented) 4. Add exponent to `Fp`'s exponent, and cast the result to a hardware floating point type.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Sunday, 21 June 2020 at 15:24:14 UTC, 9il wrote: Hey everyone, So excited to finally announce we can correctly parse floating-point numbers according to IEEE round half-to-even (bankers) rule like in C/C++, Rust, and others. Finally a worthy alternative to Vladimir Panteleevs parser [1]. A few months back I went looking for a `nothrow` parser that can handle errors reliably, and I was surprised that I could find only one that was better than my simple custom-made one. Can mir_parse handle other bases than decimal? [1]https://github.com/CyberShadow/ae/blob/master/utils/text/parsefp.d
