Re: Is there a formula for overflow?
On Wednesday, 30 November 2022 at 03:07:44 UTC, thebluepandabear wrote: I am curious as to what formula the D compiler uses for calculating 'overflowed' values, if such thing exists? :) Regards, thebluepandabear **Source:** http://ddili.org/ders/d.en/cast.html?#ix_cast.arithmetic%20conversion 1. If one of the values is real, then the other value is converted to **real** 2. Else, if one of the values is **double**, then the other value is converted to **double** 3. Else, if one of the values is **float**, then the other value is converted to **float** 4. Else, first integer promotions are applied according to the table above, and then the following rules are followed: **A.** If both types are the same, then no more steps needed **B.** If both types are signed or both types are unsigned, then the narrower value is converted to the wider type **C.** If the signed type is wider than the unsigned type, then the unsigned value is converted to the signed type **D.** Otherwise the signed type is converted to the unsigned type SDB@79
Re: Is there a formula for overflow?
On Wednesday, 30 November 2022 at 03:19:49 UTC, Basile B. wrote: writeln((30LU + 30LU) % uint.max); It's actually writeln((30LU + 30LU) % (uint.max.to!ulong + 1)); or writeln((30LU + 30LU) & uint.max);
Re: Is there a formula for overflow?
On Wednesday, 30 November 2022 at 03:19:49 UTC, Basile B. wrote: [...] It's always a wraparound (think modulo) but your examples with negative number can be explained because there are hidden unsigned to signed implicit convertions. That the only special things D does. forgot to say, you can use the dmd flag -vcg-ast to see the hidden rewrites
Re: Is there a formula for overflow?
On Wednesday, 30 November 2022 at 03:07:44 UTC, thebluepandabear
wrote:
I am reading through Ali's book about D, and he gives the
following examples for an overflow:
```D
import std.stdio;
void main() {
// 3 billion each
uint number_1 = 30;
uint number_2 = 30;
}
writeln("maximum value of uint: ", uint.max);
writeln("
number_1: ", number_1);
writeln("
number_2: ", number_2);
writeln("
sum: ", number_1 + number_2);
writeln("OVERFLOW! The result is not 6 billion!");
```
writeln((30LU + 30LU) % uint.max);
The result overflows and is 1705032704.
Also for the second example, it overflows and comes up with the
value of 4294967286:
```D
void main() {
uint number_1 = 10;
uint number_2 = 20;
writeln("PROBLEM! uint cannot have negative values:");
writeln(number_1 - number_2);
writeln(number_2 - number_1);
}
```
Also a fun one, the following produces 4294967295:
```D
uint number = 1;
writeln("negation: ", -number);
```
writeln( cast(uint) -(cast(int)1) );
But the book doesn't talk about why the D compiler came up with
these results (and it also goes for division/multiplication)
for the overflow (or maybe it did further down ?), as in it
didn't talk about the formula it used for calculating this
value.
I am curious as to what formula the D compiler uses for
calculating 'overflowed' values, if such thing exists? :)
Regards,
thebluepandabear
It's always a wraparound (think modulo) but your examples with
negative number can be explained because there are hidden
unsigned to signed implicit convertions.
That the only special things D does.
Is there a formula for overflow?
I am reading through Ali's book about D, and he gives the
following examples for an overflow:
```D
import std.stdio;
void main() {
// 3 billion each
uint number_1 = 30;
uint number_2 = 30;
}
writeln("maximum value of uint: ", uint.max);
writeln("
number_1: ", number_1);
writeln("
number_2: ", number_2);
writeln("
sum: ", number_1 + number_2);
writeln("OVERFLOW! The result is not 6 billion!");
```
The result overflows and is 1705032704.
Also for the second example, it overflows and comes up with the
value of 4294967286:
```D
void main() {
uint number_1 = 10;
uint number_2 = 20;
writeln("PROBLEM! uint cannot have negative values:");
writeln(number_1 - number_2);
writeln(number_2 - number_1);
}
```
Also a fun one, the following produces 4294967295:
```D
uint number = 1;
writeln("negation: ", -number);
```
But the book doesn't talk about why the D compiler came up with
these results (and it also goes for division/multiplication) for
the overflow (or maybe it did further down ?), as in it didn't
talk about the formula it used for calculating this value.
I am curious as to what formula the D compiler uses for
calculating 'overflowed' values, if such thing exists? :)
Regards,
thebluepandabear
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote:
To me, it appears that there are really two (_entirely
separate_) concepts:
A. Supporting the useful concept of variable length (but
otherwise entirely conventional) arrays;
B. Supporting a language feature that acts as a window to an
array, through which that array can be manipulated.
And currently these two concepts are combined.
Suggestion: it would be clearer if the two concepts were
separated:
1. Convert 'int[] VarArr;' so it produces a straightforward
_value-type_ variable array, called 'VarArr';
2. Implement a new concept 'int slice Window;' to produce an
object of type 'int slice', called 'Window'.
'Window' is a 'slice' into an int array, not an array itself
or even a variable.
Opinions?
I have implemented that in
[styx](https://gitlab.com/styx-lang/styx).
1. You have the type for dynamic arrays, called TypeRcArray,
syntax is `Type[+]`
2. You have the type for slices (what you describe as a window),
syntax is `Type[]`
but it is mostly obtained using expressions, e.g `mySlice =
myRcArray[lo .. hi]` or
`myStaticArray[lo .. hi]` or `myPointer[lo .. hi]`.
This sounded like a good idea but it [has appeared very
quickly](https://styx-lang.gitlab.io/styx/type.html#noteonlifetime) that slices are not so useful, especially when management is based on reference counting because then slices requires a form of management too. Here is why:
Main caracteristics of a slice are
- they cannot modify the identity of their sources. The identity
of the source is what makes the integrity of a dynamic array,
what makes their references countable. So it is the content
pointer and the length. In consequence you cannot change the
length of the source, you can only reduce the view. You can
change the elements in the view.
- the length and the pointer are cached as a value on the stack
while for a dynamic array this is stored before that data, on the
heap.
Problems start happening when you escape a slice
```d
struct S
{
var s32[] memberSlice;
}
function f(var S s): auto
{
var s32[+] a = (new s32[+])(2);
// problem 1 : `s` lifetime > `a` lifetime
s = (a[]).tupleof; // note: tuples are used in pace of
struct literals
// problem 2
return a[1 .. $]; // a is automatically decref'd on return
// so the caller pulls a dead heap block.
}
```
Essentially slices are only useful to be consumed locally,
typically
```d
while mySlice.length do
{
slice = slice[1..$];
}
```
And that's it. So at first glance slices are some cool,
simplified, functionally stripped down arrays but they introduce
new problems, at least when management of dynamic arrays is based
on reference counting. Those new problems can only be solved
using lifetime analysis (so a compile-time check... still better
than runtime ref counting however).
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote: To me, it appears that there are really two (_entirely separate_) concepts: A. Supporting the useful concept of variable length (but otherwise entirely conventional) arrays; B. Supporting a language feature that acts as a window to an array, through which that array can be manipulated. And currently these two concepts are combined. Yes, this is correct. Suggestion: it would be clearer if the two concepts were separated: 1. Convert 'int[] VarArr;' so it produces a straightforward _value-type_ variable array, called 'VarArr'; 2. Implement a new concept 'int slice Window;' to produce an object of type 'int slice', called 'Window'. 'Window' is a 'slice' into an int array, not an array itself or even a variable. Opinions? IMO you have it the wrong way around. The built in `T[]` type should remain the way it is and be used if you want a slice (i.e., a "window"). If you want a dynamic array with value semantics, you should use a library-defined container type (e.g., `struct DynamicArray`). Also, to avoid confusion, we should probably go through the language spec and documentation and change it to say "slice" instead of "dynamic array" whenever it refers to a `T[]`.
Re: How do I _really_ implement opApply?
On Wednesday, 30 November 2022 at 01:17:14 UTC, zjh wrote: Should there be an `intermediate layer` to simplify such function calls? There should be a `placeholder` similar to `inout` that can absorb all `attributes` of the parameter.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Wednesday, 30 November 2022 at 01:53:10 UTC, Siarhei Siamashka
wrote:
Rust also appears to be picky about the order of operations:
```Rust
fn main() {
let mut a = [1, 2, 3, 4, 5];
let c = a;
let b = a;
b[1] = 99;
println!("{:?}", b); // [1, 99, 3, 4, 5]
println!("{:?}", a); // [1, 99, 3, 4, 5]
println!("{:?}", c); // [1, 2, 3, 4, 5]
}
```
This seems unsurprising to me, `b` is a slice. The same in D:
```d
import std.array, std.stdio;
void main()
{
version (dynamic)
{
auto a = [1, 2, 3, 4, 5];
auto c = a.dup;
auto b = a;
}
else
{
auto a = [1, 2, 3, 4, 5].staticArray;
auto c = a;
auto b = a[];
}
b[1] = 99;
writeln(b); // [1, 99, 3, 4, 5]
writeln(a); // [1, 99, 3, 4, 5]
writeln(c); // [1, 2, 3, 4, 5]
}
```
I agree the syntax is inconsistent.
It is too late to change it in D, nor is it often useful in
practice.
If this is really desired, then the D compiler can probably
introduce a more verbose syntax for shallow array copies and
start spitting out warnings about simple assignments like
`"auto b = a;"`. A few years later the old syntax can be
dropped.
I only meant that variable-sized value types are not often useful
in practice.
But way too many languages behave in the same way as D right
now. I personally don't see any problem.
Slices are such a fundamental feature of D that it is unrealistic
to think about changing syntax there. It would effectively be a
new language, because almost no programs from before the change
would compile after the change.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Wednesday, 30 November 2022 at 00:40:57 UTC, Vladimir
Panteleev wrote:
On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote:
Suggestion: it would be clearer if the two concepts were
separated:
1. Convert 'int[] VarArr;' so it produces a straightforward
_value-type_ variable array, called 'VarArr';
2. Implement a new concept 'int slice Window;' to produce an
object of type 'int slice', called 'Window'.
'Window' is a 'slice' into an int array, not an array
itself or even a variable.
Opinions?
Yes, that's what Rust does. It has first-class variable-size
value types, D doesn't have such a feature.
I'm not really familiar with Rust, but it also seems to have the
concept of either making a full copy or creating a slice with a
view into the existing array. Just the default assignment via
`"let c = a;"` creates a copy. While creating a slice needs a
more elaborate explicit syntax. Rust also appears to be picky
about the order of operations:
```Rust
fn main() {
let mut a = [1, 2, 3, 4, 5];
let c = a;
let b = a;
b[1] = 99;
println!("{:?}", b); // [1, 99, 3, 4, 5]
println!("{:?}", a); // [1, 99, 3, 4, 5]
println!("{:?}", c); // [1, 2, 3, 4, 5]
}
```
It is too late to change it in D, nor is it often useful in
practice.
If this is really desired, then the D compiler can probably
introduce a more verbose syntax for shallow array copies and
start spitting out warnings about simple assignments like `"auto
b = a;"`. A few years later the old syntax can be dropped.
```D
import std;
void main() {
auto a = [1, 2, 3, 4, 5];
auto b = a.slice; // Not supported right now, but maybe is more
readable?
auto c = a.dup;
a[1] = 99;
writeln(a); // [1, 99, 3, 4, 5]
writeln(b); // [1, 99, 3, 4, 5]
writeln(c); // [1, 2, 3, 4, 5]
}
```
But way too many languages behave in the same way as D right now.
I personally don't see any problem.
Re: How do I _really_ implement opApply?
On Wednesday, 30 November 2022 at 01:30:03 UTC, Steven Schveighoffer wrote: On 11/29/22 7:50 PM, WebFreak001 wrote: (note: I don't want to use a template, this way of writing it has the advantage that the compiler checks all different code paths for errors, so the errors aren't delayed until someone actually tries to iterate over my data structure) 1. use the template 2. use a unittest to prove they all compile. +1. I use this pattern often: https://github.com/CyberShadow/ae/blob/86b016fd258ebc26f0da3239a6332c4ebecd3215/utils/graphics/libpng.d#L716-L721 https://github.com/CyberShadow/ae/blob/86b016fd258ebc26f0da3239a6332c4ebecd3215/utils/math/combinatorics.d#L220-L222
Re: How do I _really_ implement opApply?
On 11/29/22 7:50 PM, WebFreak001 wrote: (note: I don't want to use a template, this way of writing it has the advantage that the compiler checks all different code paths for errors, so the errors aren't delayed until someone actually tries to iterate over my data structure) 1. use the template 2. use a unittest to prove they all compile. -Steve
Re: How do I _really_ implement opApply?
On Wednesday, 30 November 2022 at 00:50:46 UTC, WebFreak001 wrote: ... Should there be an `intermediate layer` to simplify such function calls?
Re: dirEntries removes entire branches of empty directories
On Thursday, 10 November 2022 at 21:27:28 UTC, Ali Çehreli wrote: However, ftw performs about twice as fast as dirEntries Yes, `dirEntries` isn't as fast as it could be. Here is a directory iterator which tries to strictly not do more work than what it must: https://github.com/CyberShadow/ae/blob/86b016fd258ebc26f0da3239a6332c4ebecd3215/sys/file.d#L178
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Tuesday, 29 November 2022 at 23:25:46 UTC, DLearner wrote:
Many languages also have variable length arrays, I suggest D's
'dynamic array' _does not_ operate as expected.
I'm not suggesting that the result contradicts D's definition
of 'dynamic array', nor it's implementation, just that 'dynamic
array' is not a reasonable description for a construct that
behaves like VarArr2[3] becoming 40.
Which programming languages set your expectations this way? Many
programming languages have the concept of "deep" vs. "shallow"
copy. D is a part of a big crowd:
D:
```D
import std;
void main()
{
auto a = [1, 2, 3, 4, 5];
auto b = a;
auto c = a.dup;
a[1] = 99;
writeln(a); // [1, 99, 3, 4, 5]
writeln(b); // [1, 99, 3, 4, 5]
writeln(c); // [1, 2, 3, 4, 5]
}
```
Python:
```Python
a = [1, 2, 3, 4, 5]
b = a
c = a.copy()
a[1] = 99
print(a) # [1, 99, 3, 4, 5]
print(b) # [1, 99, 3, 4, 5]
print(c) # [1, 2, 3, 4, 5]
```
Ruby/Crystal:
```Ruby
a = [1, 2, 3, 4, 5]
b = a
c = a.dup
a[1] = 99
pp a # [1, 99, 3, 4, 5]
pp b # [1, 99, 3, 4, 5]
pp c # [1, 2, 3, 4, 5]
```
Kotlin:
```Kotlin
fun main() {
var a = intArrayOf(1, 2, 3, 4, 5)
var b = a
var c = a.copyOf()
a[1] = 99
println(a.contentToString()) // [1, 99, 3, 4, 5]
println(b.contentToString()) // [1, 99, 3, 4, 5]
println(c.contentToString()) // [1, 2, 3, 4, 5]
}
```
I could list even more languages.
Re: How do I _really_ implement opApply?
note: all of these functions are prefixed with `scope:`
How do I _really_ implement opApply?
it seems now when trying to cover scope semantics, @safe/@system
and pure it already becomes quite unmanagable to implement
opApply properly.
Right now this is my solution:
```d
private static enum opApplyImpl = q{
int result;
foreach (string key, ref value; this.table) {
result = dg(key, value);
if (result) {
break;
}
}
return result;
};
public int opApply(scope int delegate(string, ref
TOMLValue) @safe dg) @safe {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref const
TOMLValue) @safe dg) @safe {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref
TOMLValue) @safe dg) @safe {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref const
TOMLValue) @safe dg) @safe {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref const
TOMLValue) @safe dg) @safe const{
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref const
TOMLValue) @safe dg) @safe const{
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref
TOMLValue) @safe pure dg) @safe pure {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref const
TOMLValue) @safe pure dg) @safe pure {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref
TOMLValue) @safe pure dg) @safe pure {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref const
TOMLValue) @safe pure dg) @safe pure {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref const
TOMLValue) @safe pure dg) @safe pure const {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref const
TOMLValue) @safe pure dg) @safe pure const {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref
TOMLValue) @system dg) @system{
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref const
TOMLValue) @system dg) @system{
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref
TOMLValue) @system dg) @system{
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref const
TOMLValue) @system dg) @system{
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref const
TOMLValue) @system dg) @system const {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref const
TOMLValue) @system dg) @system const {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref
TOMLValue) @system pure dg) @system pure {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref const
TOMLValue) @system pure dg) @system pure {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref
TOMLValue) @system pure dg) @system pure {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref const
TOMLValue) @system pure dg) @system pure {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, ref const
TOMLValue) @system pure dg) @system pure const {
mixin(opApplyImpl); }
public int opApply(scope int delegate(string, scope ref const
TOMLValue) @system pure dg) @system pure const {
mixin(opApplyImpl); }
```
Surely there is a better way to do this?!
Better formatted:
(note: I don't want to use a template, this way of writing it has
the advantage that the compiler checks all different code paths
for errors, so the errors aren't delayed until someone actually
tries to iterate over my data structure)
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Wednesday, 30 November 2022 at 00:40:57 UTC, Vladimir Panteleev wrote: On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote: Suggestion: it would be clearer if the two concepts were separated: 1. Convert 'int[] VarArr;' so it produces a straightforward _value-type_ variable array, called 'VarArr'; 2. Implement a new concept 'int slice Window;' to produce an object of type 'int slice', called 'Window'. 'Window' is a 'slice' into an int array, not an array itself or even a variable. Opinions? Yes, that's what Rust does. It has first-class variable-size value types, D doesn't have such a feature. Cool page explaining this in The Rustonomicon: https://doc.rust-lang.org/nomicon/exotic-sizes.html
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote: Suggestion: it would be clearer if the two concepts were separated: 1. Convert 'int[] VarArr;' so it produces a straightforward _value-type_ variable array, called 'VarArr'; 2. Implement a new concept 'int slice Window;' to produce an object of type 'int slice', called 'Window'. 'Window' is a 'slice' into an int array, not an array itself or even a variable. Opinions? Yes, that's what Rust does. It has first-class variable-size value types, D doesn't have such a feature. It is too late to change it in D, nor is it often useful in practice.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Tuesday, 29 November 2022 at 23:25:46 UTC, DLearner wrote: On Tuesday, 29 November 2022 at 19:06:20 UTC, rikki cattermole wrote: [...] Please see the following example: ... I think this was discussed before a few weeks ago here (But I don't remember the thread), and this is a design choice, for example this: VarArr2 = VarArr1; VarArr2 is just pointing to the same address of VarArr1 as you can see by: writeln(VarArr1.ptr); writeln(VarArr2.ptr); To do what you want, you need to use "dup": VarArr2 = VarArr1.dup; Now it will work as you expect. I think this is confusing but in the end it's a design choice, instead of copy just point, and if you need to copy, you need to it explicitly. Matheus.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
On Tuesday, 29 November 2022 at 19:06:20 UTC, rikki cattermole
wrote:
[...]
Please see the following example:
```
void main() {
import std.stdio;
int[] VarArr1, VarArr2;
VarArr1.length = 6;
VarArr1[5] = 10;
VarArr1[4] = 9;
VarArr1[3] = 8;
VarArr1[2] = 7;
VarArr1[1] = 6;
VarArr1[0] = 5;
VarArr2 = VarArr1;
writeln("VarArr1 = ", VarArr1);
writeln("VarArr2 = ", VarArr2);
VarArr1[3] = 40;
writeln("VarArr1 = ", VarArr1);
writeln("VarArr2 = ", VarArr2);
return;
}
```
And it's result:
```
VarArr1 = [5, 6, 7, 8, 9, 10]
VarArr2 = [5, 6, 7, 8, 9, 10]
VarArr1 = [5, 6, 7, 40, 9, 10]
VarArr2 = [5, 6, 7, 40, 9, 10]
```
Many languages have fixed-length arrays, D's such construct works
as someone approaching the language would expect.
Many languages also have variable length arrays, I suggest D's
'dynamic array' _does not_ operate as expected.
I'm not suggesting that the result contradicts D's definition of
'dynamic array', nor it's implementation, just that 'dynamic
array' is not a reasonable description for a construct that
behaves like VarArr2[3] becoming 40.
Re: __traits isCopyable vs isPOD
On Tuesday, 29 November 2022 at 00:50:54 UTC, Paul Backus wrote: If your goal is to avoid calling the copy constructor (and, I assume, to avoid unnecessary instantiations of `move`), then yeah, `isPOD` is the one you want. Thanks.
Re: Thinking about the difference between fixed and 'dynamic' arrays.
Okay you have misunderstand a lot here. We have two types of arrays: - Static, fixed sized stored on stack. - Dynamic, variable sized, stored on the heap. However dynamic arrays are not actually a distinct type in the type system, its a language extension to use runtime hooks using the GC. What dynamic arrays are in the language is just slices. A slice is a length + pointer pair. This is where almost all of the syntax for dynamic arrays come from. ```d int[] slice; ``` That is a slice. ```d slice ~= 32; ``` Now it is a dynamic array as it was allocated via the GC. ```d int[4] staticArray; slice = staticArray[]; ``` The slice is now able to modify the staticArray!
Thinking about the difference between fixed and 'dynamic' arrays.
To me, it appears that there are really two (_entirely separate_) concepts: A. Supporting the useful concept of variable length (but otherwise entirely conventional) arrays; B. Supporting a language feature that acts as a window to an array, through which that array can be manipulated. And currently these two concepts are combined. Suggestion: it would be clearer if the two concepts were separated: 1. Convert 'int[] VarArr;' so it produces a straightforward _value-type_ variable array, called 'VarArr'; 2. Implement a new concept 'int slice Window;' to produce an object of type 'int slice', called 'Window'. 'Window' is a 'slice' into an int array, not an array itself or even a variable. Opinions?
Re: Running GtkD programs on macOS
On Tuesday, 29 November 2022 at 07:17:09 UTC, Joel wrote: On Saturday, 30 November 2019 at 00:17:51 UTC, Mike Wey wrote: On 29-11-2019 04:40, Joel wrote: Oh, I used 'brew install gtk+3', and the test program worked, but (see below) I don't know about all that installing - is that alright? They all look like GTK+ dependencies so that would be alright/ Update: Three years to the day (from when I posted on here about it), since upgrading to macOS Ventura I've found my GTK+ programs work again! Yay. It never stopped working on my Windows computer. The DLangui hasn't been working on Windows though. There is progress on dlangui nowadays though
Re: Running GtkD programs on macOS
On Tuesday, 29 November 2022 at 07:17:09 UTC, Joel wrote: On Saturday, 30 November 2019 at 00:17:51 UTC, Mike Wey wrote: On 29-11-2019 04:40, Joel wrote: Oh, I used 'brew install gtk+3', and the test program worked, but (see below) I don't know about all that installing - is that alright? They all look like GTK+ dependencies so that would be alright/ Update: Three years to the day (from when I posted on here about it), since upgrading to macOS Ventura I've found my GTK+ programs work again! Yay. It never stopped working on my Windows computer. The DLangui hasn't been working on Windows though. Ops, 29 11 2019 is the day I posted about trying to use GtkD on macOS (not when I found that the window wouldn't show). It doesn't work my laptop display, just the lower resolution external screen.
