For fun, and executable lame joke
Here's the short version
`["hip", "hip"]` the hip hip array (or hooray as suits the lame
joke).
Here's some executable code
```d
void array(string[] a) {
import std.stdio : writeln;
foreach(t; a) writeln(t);
}
void main() { D(); }
void
D() { ["hip", "hip"].array; }
```
Is there a way to make that less codey, more jokey, *but still
compile and execute the hip hip array*?
Have good,
Blue
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Any comments are welcomed, even any comments regarding anyone experience with GUI development within D, no matter whether the answer would be relevant to my specific question seeking a choice or not. Along that tack, and as an informational tidbit, if you (any one, not just to someone) ever find yourself with a desperate need for a gui, but lack development tooling, there is always the messaging interface to GTK, GTK-Server, by Peter van Eerten, author of BaCon. gtk-server is GTK by proxy. Send messages, get GUIs. Not fast, but readily available to hundreds of programming languages. https://gtk-server.org/intro.html And for anyone interested in how some geniuses create programming environments, BaCon is a BASIC to C converter. Ships as a shell script, that reads itself to self-host a C codegen pass, to produce a native compiled bacon compiler. Self hosted as a shell script. *That alone should warrant a trophy.* And Peter has coded the shell script so that it can actually run as the converter compiler for BASIC, or convert itself to C to native bacon. http://basic-converter.org/ worthy of a read. Have good, make well, Blue
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 12:27:34 UTC, Siemargl wrote: On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I know this is a question lacking a straightforward answer. Requirements: - desktop only: forget about support for mobile tablets whatever You forget semi-official DWT https://forum.dlang.org/group/dwt don't sell it official, even semi-*. it had very bad platform support, dub support and ...
Re: Naming issue importing different function overloads
On Sunday, 30 May 2021 at 18:42:34 UTC, data pulverizer wrote:
I wonder if it is a purposeful design
It is by design: https://dlang.org/articles/hijack.html
Basically the idea behind it is to make sure that a change in a
lib you import doesn't change your existing code without you
realizing it.
You can merge them at the import site by doing
import funs;
doubme myfun(...) {}
alias myfun = funs.myfun; // this line merges them
You can also use a selective import to merge them:
import funs : myfun;
double myfun(...) {}
now both myfuns work.
this works because the `import x : y;` is actually shorthand for
a local alias.
Naming issue importing different function overloads
Hi,
There's issue in importing functions I came across some time ago
that I wonder if it is a purposeful design or if it is something
that will be changed in the future.
Say I have module like this:
```d
module funs;
double myfun(double x)
{
return x*x;
}
```
and I call `myfun` in a function in another module:
```d
module call;
import funs;
double myfun(double y, double x)
{
return myfun(x)/y;
}
void main()
{
import std.stdio: writeln;
writeln("Demo myfun(2, 3): ", myfun(2, 3));
}
```
If I attempt to compile this I shall get the error:
```
$ dmd call.d funs.d
call.d(8): Error: function call.myfun(double y, double x) is not
callable using argument types (double)
call.d(8):missing argument for parameter #2: double x
```
Even though the function signatures are different I have to call
`myfun` with `funs.myfun(...)` in the `call.d` module. I
understand sometimes it's is good practice to do this, but
shouldn't I expect the D compiler to be "clever enough" to ignore
correct use but detect when function signatures clash and
throwing an error with an appropriate message when they do,
rather than a cryptic message telling me that the function
signature is wrong?
In the current situation, you can import `funs.d` and call
`myfun` with no issue until you decide to overload it in that
module, when you suddenly get errors. If you are not aware of
this issue and you are writing a large and highly detailed
module, it's an error that seems to come out of nowhere, the
module has suddenly lost visibility of the imported function.
I guess an alternative is to use `mixin(import("funs.d"));` but
you then lose the functionality of the formal `import` statement.
Thank you
Offtopic: A tune for vibers, maybe
21 Pilots, Outside https://www.youtube.com/watch?v=m2w6GkV3U6Q On note, "Kids'll try to take my vibes. Or am I on the outside?" Outro: "Little did they know, they can't touch me. I'm VIBIN', VIBIN'." Have good, make well, Blue
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 07:20:17 UTC, zjh wrote: On maybe try Gacui.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote: Yes, I know this is a question lacking a straightforward answer. Requirements: - desktop only: forget about support for mobile tablets whatever You forget semi-official DWT https://forum.dlang.org/group/dwt
Re: Is there a nicer way to get the first element or typeof(element).init from a range?
On Sunday, 30 May 2021 at 12:16:19 UTC, realhet wrote: presets.keys.sort.take(1).get(0); <- Oups: after fixing an error and making it compile the solution is even uglier: presets.keys.sort.take(1).array.get(0);
Is there a nicer way to get the first element or typeof(element).init from a range?
Hello,
This is my current solution but there must be a better way to do
it in D
T get(T)(T[] arr, size_t idx, T def = T.init){
return idx
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 12:09:22 UTC, cc wrote: This is overkill for any reasonable application, but I've always wanted to design a whole UI framework in OpenGL, just for the novelty of it. I always end up having to reinvent the wheel for UI elements in my projects anyway. https://streamable.com/2uvt4h There are many GUIS for OpenGL, but OpenGL is no longer supported on Macs AFAIK. I suggest using Skia instead: https://skia.org/ IIRC it is used in Chromium and Flutter.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
This is overkill for any reasonable application, but I've always wanted to design a whole UI framework in OpenGL, just for the novelty of it. I always end up having to reinvent the wheel for UI elements in my projects anyway. https://streamable.com/2uvt4h
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote: On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote: I would like to recommend DlangUI [1], but we have tried now for months to get in contact with the owner of it (to take over development) and are getting no reponse. 1. https://github.com/buggins/dlangui Of the 107 forks of dlangui last seen on github, do you know if any contain more recent changes/features than the buggins original repo? If there's a quick way to check without paging through all of them I'm curious to know how it would be done. I'm using D for efficient server-side processes only, since at work we're heavily invested in Java for our end-user GUIs, but I'm curious about the state of D GUI toolkits nonetheless. I'm 100% positive you can do good ui using D, but, I'm not sure what I'd choose because of the fragmentation.
Re: How long does the context of a delegate exist?
On Sunday, 30 May 2021 at 09:39:28 UTC, cc wrote: Is there any way to enforce at compile time that we're not accidentally allocating when creating a delegate, other than being carefully aware of what variables are referenced inside the body? Use `function` instead of `delegate`. Then it doesn't have a context pointer at all.
Re: How long does the context of a delegate exist?
On Sunday, 30 May 2021 at 09:39:28 UTC, cc wrote:
Is there any way to enforce at compile time that we're not
accidentally allocating when creating a delegate, other than
being carefully aware of what variables are referenced inside
the body? Something like:
```d
auto dg = delegate {...}
assert(dg.ptr is null, "Oops, we unintentionally allocated on
GC here, check delegate body!"); // can't static assert
```
`@nogc`. Or check the output of `dmd -vgc` if you want something
less strict.
Re: How long does the context of a delegate exist?
On Thursday, 27 May 2021 at 20:46:22 UTC, Adam D. Ruppe wrote:
On Thursday, 27 May 2021 at 20:44:21 UTC, frame wrote:
Did you mean to add the delegate as GC root or the data?
The delegate.ptr property.
Is there any way to enforce at compile time that we're not
accidentally allocating when creating a delegate, other than
being carefully aware of what variables are referenced inside the
body? Something like:
```d
auto dg = delegate {...}
assert(dg.ptr is null, "Oops, we unintentionally allocated on GC
here, check delegate body!"); // can't static assert
```
Re: ChromeOS and DLang
On Thursday, 27 May 2021 at 19:39:15 UTC, Ozan Sueel wrote: Hi I think about writing apps vor ChromeOS, but before running in a death end, I ask by myself, is D a good choice for this approach? I gather it is exactly the same situation as for Android, or? https://developer.android.com/topic/arc So it should be possible, for a hobby project. A good choice would obviously be a platform that has full Android support.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote: On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote: I would like to recommend DlangUI [1], but we have tried now for months to get in contact with the owner of it (to take over development) and are getting no reponse. 1. https://github.com/buggins/dlangui Of the 107 forks of dlangui last seen on github, do you know if any contain more recent changes/features than the buggins original repo? If there's a quick way to check without paging through all of them I'm curious to know how it would be done. I'm using D for efficient server-side processes only, since at work we're heavily invested in Java for our end-user GUIs, but I'm curious about the state of D GUI toolkits nonetheless. "Insights -> Network" will show branching overview where you can clearly observe what changes were made on each fork https://github.com/buggins/dlangui/network DlangUI is somewhat primitive but I like it that way, one can quickly hack up pretty much any widget (including graphics) without too much hassle, just subclass suitable widget for the base, override few methods and start hacking. Of course I would like it to be real MVVM with view/data separation, visual/logical hierarchy separation, data bindings, UI automation and stuff. Maybe I'll fork it one day to make it that way, but at this moment I already have too much stuff to do.
Re: wanting to try a GUI toolkit: needing some advice on which one to choose
On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote: I would like to recommend DlangUI [1], but we have tried now for months to get in contact with the owner of it (to take over development) and are getting no reponse. 1. https://github.com/buggins/dlangui Of the 107 forks of dlangui last seen on github, do you know if any contain more recent changes/features than the buggins original repo? If there's a quick way to check without paging through all of them I'm curious to know how it would be done. I'm using D for efficient server-side processes only, since at work we're heavily invested in Java for our end-user GUIs, but I'm curious about the state of D GUI toolkits nonetheless.
