Re: Deriving a struct from another one via template: Easy way to propagate UDAs?
On Saturday, 16 March 2024 at 20:34:57 UTC, Inkrementator wrote: Nice. Btw I vaguely remember you also wrote about how and why to reduce the usage string mixins, with some real example of alternative techniques you used go to the main page: http://dpldocs.info/this-week-in-d/Blog.html and use ctrl+f and hope i said it in the summary lol but the two that pop up there are: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_12_26.html#more-mixin-techniques and https://forum.dlang.org/post/fbcltjuysmjrxmebe...@forum.dlang.org The general rule is to try to use the local name inside the string instead of concatenating its result, and remember the built in compiler-tuple - which is what __traits(getAttributes) and the parameters reflection and other things - can be used directly in a lot of places, you can very often substitute one of those for a value and it will put it in for you. I encourage you to experiment with plugging these things directly in at the use site and seeing what happens before falling back to strings. fyi don't really follow this forum anymore, you got a bit lucky that i popped in for the dconf online link, so i might not see any further replies to this.
Re: Deriving a struct from another one via template: Easy way to propagate UDAs?
On Thursday, 14 March 2024 at 23:19:37 UTC, Inkrementator wrote:
* Is UDA propagation possible without string mixins?
@(__traits(getAttributes, thingYouWantToForward))
void yourNewThing() {}
* Are template mixins vulnerable to name collisions?
http://dpldocs.info/this-week-in-d/Blog.Posted_2020_01_20.html#understanding-mixin-templates
Re: Non-blocking keyboard input
On Wednesday, 27 December 2023 at 05:07:04 UTC, Joe wrote: ??? Surely there there is a one liner library solution for this? It is not one line because it needs a bit of setup (and teardown, but the objects' destructors do that for you) but it is close: http://arsd-official.dpldocs.info/arsd.terminal.html#single-key `input.getch` waits for a single line, but you can use `if(input.kbhit())` to see if it would block before calling it. This shouldn't be hard... yet it is. Better be careful, the mods are out in force deleting posts this week that tell the hard truth. But yeah, the stdlib in D has very little activity: https://github.com/dlang/phobos/graphs/contributors? So you can't expect much from it. My arsd libs provide a broad set of functionality missing from it: stuff like this terminal/console stuff, window creation, basic guis, web servers, etc. If you want to try them, you can use it from the dub system, but I recommend just `git clone https://github.com/adamdruppe/arsd.git` in your working directory then import what you want and use `dmd -i` to automatically include them in the build.
Re: Browsers in D
On Thursday, 21 December 2023 at 11:55:50 UTC, aberba wrote: I have this idea of building a web view based desktop app with a webserver and db backend for CRUD functionality. This looks like a great option. Yeah, it is a solid choice with a long history. Did you know the Unix Printing System used to (I don't think it still does but im not sure) work this way? Some 15 years ago, it'd start up a local web server and you'd work with it through the browser. I do kinda wish that the common browsers supported connecting through a local unix socket, so you wouldn't have to allocate a port... but you don't really have to allocate a port anyway - you can let the OS give you a random available one then you see what it assigned you and pop open the browser. So it still works. Another interesting thing available nowadays is some programs will run a webview ui but also open a websocket server, allowing other websites to interact with it. With a websocket server, any random internet page is allowed to try to connect to it - yes, normal javascript is allowed to try to connect a websocket to localhost - and your server checks the `origin` header to see if it is a website you want to talk to. The Discord desktop client uses this, for example, to let their official sites detect the local client and ask if you want to "open link in app" (which i kinda hate lol but it does) and also to communicate some special features to it, like a discord website can show who is currently speaking in the voice to display on your web streams. (I know this cuz i hooked into it to make my own thing lol). But it is still a potential way to combine all these options for your users.
Re: Browsers in D
On Wednesday, 20 December 2023 at 09:29:36 UTC, Paolo Invernizzi wrote: When I was the CTO of my previous company, we embedded Gecko into a custom C++ GUI framework, to allow ALS people browse the web using gazes as an input method: it was a real pain ... Wow, yeah, I know it must be possible, but I couldn't even figure out how to get started. Like I said, pity Mozilla didn't recognize this use case, I think they could have really done something with it. Microsoft and WebKit (both from its KDE days and now with Apple in charge of it) have both really done a nice job making their things easy to adapt.
Re: Browsers in D
On Wednesday, 20 December 2023 at 06:29:30 UTC, Hors wrote: Rust is better choice than D if you have to run code from untrusted resources (html, javascript, webassembly...) it's safer, plus faster. That's not how it actually works in any of the browsers though. The code that implements those things is pretty universally C++, and the sandbox is provided through operating system resources instead of language features. In the blog example program, you saw that there must be a `Wv2App` (or `CefApp`) declared in main before doing anything else. That object might appear to do nothing, but it actually encapsulates a key part of the security sandboxing of the newer browser: that's responsible for spawning the worker processes for different jobs on different domains. This is also why there's so much message passing in the implementations - they can't see each other's memory directly!
Re: Browsers in D
On Tuesday, 19 December 2023 at 23:40:48 UTC, Antonio wrote: It was not the first neither the last problem that a new version of chrome caused to our company Oh, I'm old enough to remember the Chrome auto-update that broke standard HTML links! It was such a pain supporting it in the first few years, while IE and Firefox were both working pretty well at the time. But, like I just said in the other post, Firefox has near-zero support for being embedded in other applications. If you know of a way that we could reasonably use from D, let me know, but the only time I've seen an embedded Gecko is actually in the Wine project... and this had no other way to access it that I could find. I remember when reported a bug about canvas/images memory leak (Our software processed hundred of images directly on web)... we find the solution to assigning 0 to width/height... but the chromium bug remained YEARS until it was solved. Mozilla has closed *dozens* of bugs that affect me directly as WONTFIX, including fairly simple to fix regressions. That's why I can't use it anymore. Adam, I really heated Chrome... and I simply don't tolerate each new browser based on chromium. If you wanna work on my other engine to bring it up to spec, feel free lol, but the screenshots speak to the functionality gap...
Re: SIGSEGV (Segmentation Fault) upon setting character in char array (object member var)
On Tuesday, 19 December 2023 at 13:10:40 UTC, John Kiro wrote:
class Test {
static enum MAX = 10;
uint index = 0;
auto intArray = new int[MAX];
auto charArray = new char[MAX];
This is run at compile time, and the compiler treats any char
array at compile time as an immutable string literal when it
crosses the barrier into run time. Moreover, this would be a
static instance of the initial array; the default reference is
shared across all objects created (so if you modify intArray then
`new` another object, you'll see the modified intArray!).
You almost never want to assign arrays or objects at compile time
like this in a class definition; use constructors instead.
I think the `new char[]` thing being immutable in runtime is a
compiler bug, it makes it immutable but it is still typed as
mutable in the type system. but this whole static init thing is
probably not what you want anyway.
Re: Operator "+=" overloading for class?
On Sunday, 17 December 2023 at 04:13:20 UTC, Ki Rill wrote:
auto opOpAssign(string op)(in ElementType rhs)
{
mixin("return this" ~ op ~ "rhs;");
}
```
check what `op` is. pretty sure it is "+" not "+=" so your
element isnt' saved anywhere. also a bit iffy there isn't a
member here to work on
Re: Is it possible to set/override the name of the source file when piping it into DMD via stdin?
On Wednesday, 13 December 2023 at 19:37:09 UTC, Siarhei Siamashka wrote: Now I'm curious. Is it possible to somehow communicate the real source file name to `dmd`, so that it shows up in the error log instead of "__stdin.d"? the sequence `#line "filename.d" 1` at the top of the thing might do what you need. https://dlang.org/spec/lex.html#special-token-sequence might also suggest putting a `module` declaration in the file.
Re: question
On Wednesday, 13 December 2023 at 12:49:14 UTC, fred wrote:
a bug ?
It helps if you explain what you're talking about so we don't
have to guess.
I tried the code on my computer and it worked fine. But then
figuring, you must be saying something doesn't work right, I
tried it on another compiler and saw it endlessly loop.
So it ended using my dmd 2.098, looped on my dmd 2.105 but
this is actually just coincidence. Consider this:
---
void s2()
{
shared(bool) isDone = false;
spawn(, );
Thread.sleep(400.msecs);
w("done");
isDone = true;
}
---
The variable `isDone` is temporary; as a local variable, it
ceases to exist when s2 returns. So when w2 tries to check if it
is done or not, it takes a bit of luck for the memory to still be
the same value as it was; it has likely been recycled or
otherwise cleared by then.
You need to keep the variable alive until *both* threads are done
with it, either by doing some fancy synchronization between the
threads or just letting the garbage collector manage the shared
variable:
```
void s2()
{
// let the GC do it
shared(bool)* isDone = new shared bool;
spawn(, isDone);
Thread.sleep(400.msecs);
w("done");
*isDone = true;
}
```
Re: union default initialization values
On Tuesday, 5 December 2023 at 19:24:51 UTC, confuzzled wrote:
Given the following union
union F
{
double x;
struct {
ulong lo;
ulong hi;
}
}
The default value of this would be `double.init`, since the first
member of the union is a `double`, which is a kind of NaN. This
is non-zero.
You can use `double x = 0;` to specify you want it to be zero
initialized.
fp.x.writefln!"%20.98f"; // Also, why is precision
completely lost after 16 digits (18 if I change the type of x
to real)?
idk about this.
Re: struct initializer
On Friday, 1 December 2023 at 13:02:06 UTC, Dom DiSc wrote: Either allow it for all initializations, or get rid of it, like DIP 1031 suggested. I thought the decision actually was made to just get rid of it.
Re: 'typeof' question
On Tuesday, 28 November 2023 at 18:41:49 UTC, DLearner wrote:
A* A_Ptr;
struct B {
int BFld2;
typeof(A_Ptr)[0..($-1)] ASUB; // Idea is ASUB of type A,
from A_Ptr of type A*.
I think what you really want is
typeof(*A_Ptr) ASUB;
the typeof thing returns the type you'd get from the code inside
Re: Why this compiles?
On Sunday, 26 November 2023 at 21:45:21 UTC, Antonio wrote: In this example, ```a``` and ```b``` vars are not of the same type and don't implement the same interface. **why ```assert(a==b)``` compiles?** They're both subclasses of Object and inherit a generic opEquals from that base.
Re: mixin under -betterC
On Thursday, 23 November 2023 at 16:33:52 UTC, DLearner wrote:
string mxnTest(string strVar1, string strVar2) {
return `(int Var1, int Var2) {
if (Var1 > Var2) {
return true;
} else {
return false;
}
}(` ~ strVar1 ~ `,` ~ strVar2 ~ `)`;
}
```
This function exists at runtime. Another module could, in theory,
import it and call it. A shared library could, in theory, export
it. You used it at compile time, but the function is available
for other users too.
betterC doesn't know the difference between theory and practice.
Re: DLF September 2023 Planning Update
On Tuesday, 21 November 2023 at 13:13:06 UTC, Guillaume Piolat wrote: I'd argue people come to languages because of arguably alive libraries, and dead libraries less so. Yeah, I think this is solving the wrong problem, but even if we decide to do it anyway it is very important not to hurt alive libs in the name of saving dead libs. If we increase the cost of new and ongoing things, it will lead to more dead things in the future and this would obviously be a bad long term result, even if it looks good in the short term. When alias this breaks the important thing is in my not-so-informed opinion "why DlangUI has few maintenance energy" not "how can we make it still build". Well, part of this too is there needs to be a migration path to achieve the same (or better) job that you can get it. When the cost is small, and ideally if it maintains some compatibility for users with old compilers too, it takes less maintenance energy.
Re: DLF September 2023 Planning Update
On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah wrote: I just want to echo Steve's sentiment, that it should be easy for new (and old) D users to start up a project without worrying about editions. Actually, this brings another question to mind: what about old users who keep up with the language? Do they need to edit dozens or hundreds of files on each and every language update? (Of course, making a script do this for you wouldn't be especially difficult, but I don't trust scripts to edit my code soo lol and besides, what about things like ddoc examples, will it edit them too?) I actually rarely need to edit my code in response to new dmd versions now, and they remain compatible across users with old and new compilers alike. Would be a pity to throw that off.
Re: under gdb: received signal SIG34, Real-time event 34.; received signal SIG35, Real-time event 35
On Tuesday, 14 November 2023 at 21:31:39 UTC, mw wrote: handle SIGUSR1 noprint handle SIGUSR2 noprint These are what the GC used to use to stop/start threads. received signal SIG34, Real-time event 34. received signal SIG35, Real-time event 35. And this is what it uses now. druntime just replaced usr1/2 with rt34/35 to lessen the likelyhood of conflicts with other libraries.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven Schveighoffer wrote: That's not any better. If you have to opt-in to the language as it exists, people are going to quit immediately. Counterpoint: javascript's "use strict". On the gripping hand though, I basically never use that and most people prolly don't either. But it is a major language example we ought to consider. * * * But for existing libraries, I actually have a potential solution for that: made dub look at the version tag date. So, suppose dub determines it wants to use abandoned-library version 1.4. It knows version 1.4 was tagged on December 25, 2016. This could automatically go ahead and add `-edition=abandoned.library=2.092` to the build command for that lib. Notice that build command used a package specifier, if an edition is specified on the command line, it *MUST* be scoped to a specific module (or D package, just like how `-i` works) so when it is imported, the compiler can attach the edition tag there without affecting other things in the build. It would basically work like you pass `-edition=abandoned.library=2.092` on the cmd line and the compiler acts exactly the same as if you wrote `@edition(2.092)` when it sees `module abandoned library`. On the other hand, suppose dub sees a new tag, version 2.0, created in 2024. This will be edition 2.107 since it has a date range to version map. We'd have to work out the exact details, but just since dub knows the tag date it can make a pretty good automatic guess as to the proper version.
Re: D: How do I pipe (|) through three programs using std.process?
On Sunday, 12 November 2023 at 13:39:25 UTC, BoQsc wrote: However the question of why `spawnProcess(["find", "string to find"]` is not working and produces error is still unresolved. spawnProcess always encodes its arguments in a very specific way and the receiving programs are not always compatible with that thing. A Windows process does not take an array of args, but rather a single string command line. spawnProcess tries to turn the unix-style array into a single string that can then be turned back into arguments by the receiving program. But it makes a lot of assumptions in how that happens that just don't always match reality.
Re: why remove octal literal support?
On Friday, 3 November 2023 at 15:07:41 UTC, d007 wrote: dlang is know for compile speed, but in reality d project compile slow because so much ctfe and tempalte. Some ctfe and templates are slow. Usually larger functions or array/string append loops end up being to blame. Octal literals don't really matter either way because they're so small.
Re: Keyword "package" prevents from importing a package module "package.d"
On Friday, 3 November 2023 at 00:19:48 UTC, Andrey Zherikov wrote: Is there any guide how one can refactor single-module package into multi-module package with distinction between public and private modules? Call the modules literally anything else and it works better. So say you have module foo.bar. You could keep that and put your multiple modules in a different thing like foo.bar_parts.part and foo.bar_parts.part2. This maintains compatibility on the user side; if they were previously using foo.bar, things keep working for them. Or, you could keep everything under foo.bar, but add a foo.bar.all that provides the old api. Users would have to adjust their imports to say `import foo.bar.all;` instead. This has more potential for transition breakage, but it keeps the new modules under the old namespace. I recommend option 1: having the new foo.bar_parts where the implementation actually goes. (Or you could call it whatever you want.) This avoids the whole package.d thing while still letting you and your user arrange modules how you like. You might also have a thing like `foo.bar_implementation` which is not intended for public use.
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 19:30:58 UTC, Jonathan M Davis wrote: The entire reason that it was added to the language was to be able to split up existing modules without breaking code. And it does that well. No, it doesn't do that well at all. In fact, it does that so extremely poorly that (as you might recall) there were a very large number of support requests shortly after Phobos started using it about broken builds, since it would keep the old file and the new file when you updated and this stupid, idiotic design can't handle that situation. This only subsided because enough time has passed that nobody tries using it to break up existing modules anymore. It is just a *terrible* design that never should have passed review. It is randomly inconsistent with the rest of the language and this manifests as several bugs. (including but not limited to: https://issues.dlang.org/show_bug.cgi?id=14687 doesn't work with .di https://issues.dlang.org/show_bug.cgi?id=17699 breaks if you try to use it for its intended purpose https://issues.dlang.org/show_bug.cgi?id=20563 error messages hit random problems all-at-once vs separate compilation of package leads to inconsistent reflection results im sure the list went on if i spent a few more minutes looking for my archives) package.d is indeed completely unnecessary for creating a module that publicly imports other modules in order to be able to import a single module and get several modules. Yeah, it is a terrible feature that is poorly designed, hackily implemented, and serves no legitimate use case.
Re: Keyword "package" prevents from importing a package module "package.d"
On Thursday, 2 November 2023 at 12:52:35 UTC, BoQsc wrote: Therefore the need to import `package.d` is needed and I can't see a solution, which means tbh package.d should never be used. It is a poorly designed, buggy misfeature of the language with plenty of better working alternatives (it is no different than making a `module yourthing.all;` people can import execpt with more limitations and bugs.)
Re: GUI text input dialog with few lines
On Monday, 23 October 2023 at 16:50:08 UTC, Felipe Lema wrote: Hey, I know this is stretching it out, but ... how can I do "Ctrl-v" to paste the clipboard content? Ah, sorry, I missed this - I don't follow this forum daily (it was pure coincidence your first message came in when I happened to be looking at it, feel free to CC my destructiona...@gmail.com email if you need a quicker answer). For text input, ctrl+v should just work automatically, it is handled by the widget itself. Can you check the version you have? On linux my thing was annoyingly buggy (like it'd usually work but not always) until i think version 11.1. If we had to though you can add a addEventListener key press thing but it should just work...
Re: GUI text input dialog with few lines
On Friday, 20 October 2023 at 20:43:21 UTC, Felipe Lema wrote:
I don't mind using any or other GUI framework, but I do aim to
have a windows-exe-with-as-few-dlls-as-possible
My minigui.d can do this fairly easily:
```
import arsd.minigui;
void main() {
// need to define the data you want in a struct,
// it requires a struct even if you only want one item
struct Data {
string code;
}
// then do the dialog function with the struct and it
// auto-creates a dialog for all the parts of the struct
// and calls the function you provide when the user hits
OK
dialog((Data received) {
// you got the number here
messageBox("You gave me " ~ received.code);
// note that if they hit cancel, this function is
NOT
// called, the dialog is just closed without
running
// this code.
});
// need to run the event loop explicitly, this will
return when
// all windows are closed
EventLoop.get.run();
}
```
If you use dub you can add it as dependency:
https://code.dlang.org/packages/arsd-official%3Aminigui
arsd-official:minigui
If you don't use dub, it needs about 6 files out of the repo, but
i suggest you clone the whole thing then use dmd -i.
But anyway, on Windows it uses the native text box so there's no
dlls needed. On Linux, it uses my full custom stuff so no libs
required there either.
Re: use dmd for bare metal i386
On Friday, 13 October 2023 at 22:14:36 UTC, Dmitry Ponyatov wrote: Is dmd able to be forced not include some unneeded information into target object files to make bare metal 32-bit code? Need some samples and build scripts to do it. Make an empty file called object.d in your build directory then compile with dmd and it won't emit much of anything in there. I've run dmd programs on bare metal x86 many times in the past (but not recently, i have so many other things to do) including for one section of my "D Cookbook" almost ten years ago now (it is easier now than it used to be, back then you had to have something in object.d, now an empty one is mostly permitted)
Re: Straight Forward Arrays
On Sunday, 1 October 2023 at 09:01:53 UTC, dhs wrote: When D creates a dynamic array, it returns a slice. Functions that add or remove elements begin by asking the memory manager for the dynamic array that the slice belongs to. Only then can they go on and add elements. Why is this a problem? It is convenient and usually works fine. I use the built in arrays very very often for a lot of things.
Re: reggae v0.10.0 - The meta build system just got better
On Friday, 15 September 2023 at 20:22:50 UTC, Atila Neves wrote:
An argument could be made that it could/should install the
dependencies such that only one `-I` flag is needed.
Indeed, this would be god tier.
~190k SLOC (not counting the many dub dependencies) killed dmd
on a system with 64GB RAM + 64GB swap after over a minute. Even
if it worked, it'd be much, much slower.
What you do with the lines of code is *far* more important than
how many there are.
The arsd library has about 219,000 lines of text if you delete
the Windows-only and obsolete modules (doing so just so I can
actually dmd *.d here on my Linux box). This includes comments
and such; dscanner --sloc reports about 98,000.
$ wc *.d
218983 870208 7134770 total
$ dscanner --sloc *.d
total: 98645
Let's compile it all:
$ /usr/bin/time dmd *.d -L-L/usr/local/pgsql/lib -unittest
-L-lX11
5.35user 0.72system 0:06.08elapsed 99%CPU (0avgtext+0avgdata
1852460maxresident)k
0inputs+70464outputs (0major+536358minor)pagefaults 0swaps
That's a little bit slow, over 5 seconds. About 1.3 of those
seconds are spent in the linker, the other 4 remain with dmd -c.
Similarly, that's almost 2 GB of RAM it used, more than it
probably should, but it worked fine.
My computer btw is a budget model circa 2016. Nothing
extraordinary about its hardware.
But notice it isn't actually running out of RAM or melting the
CPU over a period of minutes, despite being about six figures
lines of code but any measure.
On the other hand, compile:
enum a = () {
string s;
foreach(i; 0 .. 20_000_000_000)
s ~= 'a';
return s;
}();
Don't actually do it, but you can imagine what will happen. 6
lines that can spin your cpu and explode your memory. Indeed,
even just importing this module, even if the build system tried
not to compile it again, will cause the same problem.
The arsd libs are written - for the most part, there's some
exceptions - with compile speed in mind. If I see my build slow
down, I investigate why. Most problems like this can be fixed!
In fact, let's take that snippet and talk about it. I had to
remove *several* zeroes to make it even work without freezing up
my computer, but with a 100,000 item loop, it just barely worked.
Even 200,000 made it OOM.
But ok, a 100,000 item append:
0.53user 1.52system 0:02.17elapsed 95%CPU (0avgtext+0avgdata
4912656maxresident)k
About 5 GB of RAM devoured by these few lines, taking 2 seconds
to run. What are some ways we can fix this? The ~= operator is
actually *awful* at CTFE, its behavior is quadratic (...or worse,
i didn't confirm this today, but it is obviously bad). So you can
fix this pretty easily:
enum string a = () {
// preallocate the buffer instead of append
char[] s = new char[](10);
foreach(ref ch; s)
ch = 'a';
return s;
}();
0.17user 0.03system 0:00.21elapsed 98%CPU (0avgtext+0avgdata
45748maxresident)k 16inputs+1408outputs
(0major+21995minor)pagefaults 0swaps
Over 10x faster to compile, 1/100th of the RAM, ram result. Real
world code is frequently doing more than this example and
rewriting it to work like this might take some real effort
but the results are worth it.
And btw try this: import this module and check your time/memory
stats. Even if it isn't compiled, since ctfe is run when the
module is even just imported, you gain *nothing* by separate
compilation!
...but there are times when you can gain a LOT by separate
compilation in situations like this, if you can move the ctfe to
be some private thing not exposed in the interface. This requires
some work by the lib author too though in most cases. An example
where you can gain a lot is when something does a lot of internal
code generation but exposes a small interface, for example a
scripting language wrapper (though script wrappers can also be
made to compile reasonably efficiently if you use things like
preallocation of buffers, keep your generated functions short
(again, the codegen has quadratic behavior, so many small
functions work better than a big one, and if you factor the code
well, you can minimize the amount of generated code and call back
to generic things, e.g. type erasure), collapse template
instances, and keep ctfe things ctfe only with a variety of
techniques, so they are not codegened unless they are actually
necessary).
My arsd.script and arsd.cgi can wrap large numbers of functions
and classes reasonably well, but that's why programs using them
tend to be multi-second builds just note that's programs
using them. Separate compiling the libraries doesn't help. You'd
have to structure the code to keep those codegen parts internal
to a package with a minimal interface, then separate compiling
those internal components might win.
But this is a fairly niche case. Yes, I know there's one major
commercial D user who do exactly this. But that's the exception,
not the rule.
Re: reggae v0.10.0 - The meta build system just got better
On Tuesday, 12 September 2023 at 13:12:29 UTC, Atila Neves wrote: It does mean adding `-I` flags to every dependency though, so there's that. Not if you install them properly. And for larger codebases `dmd -i` can't and won't work. Define "larger".
Re: reggae v0.10.0 - The meta build system just got better
I tried reggae today. It did not go well. http://dpldocs.info/this-week-in-d/Blog.Posted_2023_09_11.html#reggae-editorial
Re: Is this a ctfe bugs ? ref scope const(ubyte)[32]
On Wednesday, 6 September 2023 at 12:04:40 UTC, d007 wrote: extern(C) int test(ref scope const(ubyte)[32] b); extern(C) int test(ref scope const(ubyte[32]) b); These are the same thing since the ref cannot be rebound anyway; a static array just is its contents.
Re: parallel threads stalls until all thread batches are finished.
On Wednesday, 23 August 2023 at 13:03:36 UTC, Joe wrote: to download files from the internet. Are they particularly big files? You might consider using one of the other libs that does it all in one thread. (i ask about size cuz mine ive never tested doing big files at once, i usually use it for smaller things, but i think it can do it) The reason why this causes me problems is that the downloaded files, which are cashed to a temporary file, stick around and do not free up space(think of it just as using memory) and this can cause some problems some of the time. this is why im a lil worried about my thing, like do they have to be temporary files or can it be memory that is recycled?
Re: D Language Foundation August 2023 Monthly Meeting Summary
On Tuesday, 22 August 2023 at 21:36:49 UTC, An Pham wrote: 1. DMD does not have consistent way of defining system attribute which can cause conflict with user attribute (DMD system attribute should start with underscore character, "_") Not true, these attributes follow module namespacing rules. This is how ldc and gdc do all their special extensions too. 2. If old DMD version can not handle new pragma identifier, it is because the list is hardcoded. Should have/add ignore pragma identifier list defined in sc.ini so that it can be updated at will without rebuild Even if you changed this, it wouldn't matter, since the change wouldn't be present in the old compilers you want to support! 3. DMD has attribute soup problem because it does not have negate setting. This is true but doesn't apply here.
Re: How to create an .exe without execute the terminal in Windows?
On Saturday, 12 August 2023 at 23:13:39 UTC, thePengüin wrote:
I would know how to make some this but in Dlang:
best way is to use the linker switch.
On Win32, you can pass -L/subsystem:windows if you don't want a
console to be automatically allocated.
Please note when compiling on Win64, you need to explicitly list
-Lgdi32.lib -Luser32.lib on the build command. If you want the
Windows subsystem too, use -L/subsystem:windows
-L/entry:mainCRTStartup.
If using ldc instead of dmd, use -L/entry:wmainCRTStartup instead
of mainCRTStartup; note the "w".
import core.sys.windows.windows;
void hideConsoleWindow() {
ShowWindow(GetConsoleWindow(),SW_HIDE);
}
```
woudl also work.
Re: pragma lib doesn't support static libraries?
On Sunday, 30 July 2023 at 05:53:55 UTC, Mike Parker wrote: And I'm unaware of any mechanism for embedding static library names in an object file for a linker to read later. There is a mechanism on Windows, so it tends to work there, but yeah no luck on the other platforms.
Re: Unicode in strings
On Thursday, 27 July 2023 at 22:15:47 UTC, Cecil Ward wrote: How do I get a wstring or dstring with a code point of 0xA0 in it ? note that you don't need wstring and dstring to express all unicode strings.
Re: array index out of bound may not throw exception?
On Friday, 21 July 2023 at 21:27:45 UTC, mw wrote: However, I just debugged a case, where out of bound array index didn't throw exception, and just hang the thread Uncaught exceptions in a thread terminate that thread and are reported when you call the `join` method of the thread. I think you can still get a debugger to break on them but im not entirely sure, it is a different switch than in the main thread i think. But you might want to do your own try/catch block around a thread to report it differently if you have a better way for your application.
Re: Redirecting standard streams in Windows
On Tuesday, 18 July 2023 at 23:52:06 UTC, Alexander Zhirov wrote: PS C:\dlang\test> cat .\stderr.txt How does the cat program know what the encoding of the file is? Try opening it in notepad or something and specifying the encoding. I betcha it is perfectly fine.
Re: Redirecting standard streams in Windows
On Tuesday, 18 July 2023 at 21:31:54 UTC, Alexander Zhirov wrote: HANDLE h_stdout = GetStdHandle(STD_OUTPUT_HANDLE); WriteConsoleW(h_stderr, str.ptr, cast(DWORD)str.length, NULL, NULL); If you checked the return value of this call, you'd find it fails since WriteConsole only works if the output is, in fact, a console. You need to use WriteFile when it is redirected, which you can detect with GetFileType to see if it is a character device or not.
Re: Inlined functions and their original bodies - bloat
On Sunday, 9 July 2023 at 18:05:48 UTC, Cecil Ward wrote: This is with full -O3 optimisation try -fvisibility=hidden -release sux btw
Re: Reading an environment variable value
On Thursday, 29 June 2023 at 18:47:48 UTC, Josh Holtrop wrote: $ ldc2 -of environment environment.d Since you named the file `environment.d` and didn't use an explicit `module name.thing;` declaration, the compiler assumes it should match the filename. So it injects an implicit `module environment;` to the top of the file. Now when you mention `environment`, it uses *that* name instead of the imported name, so it thinks you are trying to pass it the module called environment instead of the object. If you add `module yourapp.environment;` or something to the top it'd fix it (unless you tried to use something called `yourapp`, then the name might conflict again!) or rename the file.
Re: pragma msg field name?
On Tuesday, 27 June 2023 at 22:20:22 UTC, Chris Katko wrote:
pragma(msg, t.stringof); // does not see any new fields!
D's declarations are all order-independent, in theory those
foreaches are done simultaneously, so it is kinda a race
condition.
In practice, the compiler does them in two passes but both based
on the same initial state.
Adding stuff and then reflecting over the stuff you add must be
done as explicit steps on the outside, like you can make a
`struct step1 {}` then `alias step2 = transform!step1;` then
`alias step3 = transform_again!step2;` or something.
Re: pragma msg field name?
On Tuesday, 27 June 2023 at 04:25:13 UTC, Chris Katko wrote: How do I get just the field name? __traits(identifier, field) And why does it think this is a run-time value? It is the same as if you wrote `Class.field`
Re: Beerconf June 2023
On Saturday, 24 June 2023 at 22:52:01 UTC, Chris Katko wrote: Will there be a YouTube/whatever mirror of the conference afterward? most the weekend is just a handful of random people coming and going at random times and talking about random stuff more of just like a online hang out than anything formal.
Re: Mixin and compile-time functions for code generation
On Saturday, 24 June 2023 at 17:31:31 UTC, Cecil Ward wrote: Can I get mixin whatever to do this for me? Mixin with a function that runs at compile-time and creates the required source ? have you tried it?
Re: Union with bits ?
On Wednesday, 14 June 2023 at 08:51:19 UTC, Rene Zwanenburg wrote: You can do something like this if you don't mind compiling with -preview=bitfields: That doesn't do what you think it does. There's no guarantee the bits will actually line up with the status byte. The best way to do what the OP wants is to add property getters and setters to the struct with the ubyte that masks the member.
Re: How get struct value by member name string ?
On Monday, 29 May 2023 at 09:35:11 UTC, John Xu wrote: Error: variable `column` cannot be read at compile time you should generally getMember on a variable T t; __traits(getMember, t, "name") like that, that's as if you wrote t.name
Re: Complicated @property access only works when I write an extra parenthesis "()"
On Friday, 26 May 2023 at 21:00:20 UTC, realhet wrote: Only the extra () let it compile successfuly. No way to fix it. If the function takes an extra argument you can kinda trick it but for zero arg function pointer return from a property it is just plain broken and has been the whole time. Don't expect it to ever be fixed.
Re: Given an object, how to call an alias to a member function on it?
On Tuesday, 2 May 2023 at 13:57:23 UTC, Steven Schveighoffer wrote: Isn't that what `__traits(child)` is for? https://dlang.org/spec/traits.html#child Yes, __traits(child, object, method_alias)(args) is the way to do it.
Re: std.socket tutorials? examples?
On Sunday, 30 April 2023 at 22:10:31 UTC, Cecil Ward wrote: How do we wait for an ‘or’ of multiple asynchronous events in this kind of code? You can set a timeout value for Socket.select, but Phobos isn't going to help you with anything other than sockets and timeouts (despite the fact the underlying operating systems can, in fact, do it). There's a few other libs that can help with this, including one I'm aiming to release some time in May, or vibe.d has its own ways of doing it, among others. You can also import core.sys.stuff and call the OS functions without a middle man. But the D stdlib is quite underpowered when it comes to these things. Socket.select is ok but just the basics.
Re: A Programmer's Dilema: juggling with C, BetterC, D, Macros and Cross Compiling, etc.
On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote: * Use D for everything, no C compatibility. This is a false dilemma: D has full C compatibility.
Re: std.socket tutorials? examples?
On Saturday, 29 April 2023 at 10:56:46 UTC, Jan Allersma wrote: auto clientResult = Socket.select(clientSet, null, null); There's probably nothing in clientSet, so it is waiting for nothing you almost always want to have just one call to select in the program, not two, the whole point is to combine checks. I wrote a thing you might want to read too: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_11_11.html#sockets-tutorial
Re: arsd 11 progress report - scheduled for release in May
On Friday, 21 April 2023 at 02:34:10 UTC, Chris Piker wrote:
A cursory reading of the cgi module indicates that arsd provide
some of the same functionality of vibe.d, but uses
multi-processes or multi-threads instead of fibers. Is that
true?
It actually does a lot more than that, including a fiber impl too
(the -version=embedded_httpd_hybrid)
Also, how do you keep DB requests from getting munged together
on the same DB connection socket when using arsd.cgi with
arsd.database?
You don't use the same db connection socket. You have a separate
one per worker.
The way I usually do it is:
---
Database getDb() {
static Database db;
if(db is null)
db = new WhicheverImpl(args);
return db;
}
---
So you get a thread-local cache, recreated whenever needed. This
works reliably in all current modes. (I might be adding a new
mode in version 11 that works differently, but I'll add a new
helper function for that if I do).
In general what would you say are the advantages of using
arsd.cgi over vibe.d (other then simplicity of course).
Almost everything. It is much simpler to use, has more library
compatibility, better performance (both compiles faster and
serves faster), more stability (both fewer bugs and more long
term api support), more features though there's a few places
vibe might have something I don't (like there's a redis lib on
their end, tho odds are you can use their lib in my system lol),
I have most things they have and some things they don't (like my
html form generators).
Re: DlangUI Layout Justification
On Friday, 7 April 2023 at 15:52:02 UTC, Ali Çehreli wrote: I don't know how relevant it is but there is also Hipreme Engine that supports Android: I think the question is if you are doing games vs doing other applications. There's some overlap between game and gui, but not actually that much. Both draw things to the screen and accept user input... but even these two things they tend to do quite differently. Guis tend to favor responsiveness. I know, there's people saying "games have to be even more responsive!" but let me finish: games tend to favor *predictability*. (Some exceptions of course.) A gui will want to respond to input as soon as it can. If I can press a key and see a response on screen in one millisecond, great! Or, on the other hand, if it takes 200 ms... not so great, but I can maybe still live with it. A game will want to respond to input *on a strict schedule*. Responding too fast might break its rules - the world physics aren't infinitely precise and are designed with certain limits in mind. It might also give an unfair advantage to some players over others. Responding too slowly means players will miss their jumps and other frustrating feelings of lack of control. But notice that if something is *predictably* slow, players will get used to it - a lot of things deliberately have some delay according to the rules of the game. Something is only ever "too slow" if it is inconsistently slow. Thus it is common for games to poll input on a timer, whereas guis wait for input on events. Both games and guis draw, but games tend to draw many active things at once, showing a game world that is changing with the passage of time, and guis tend to draw one difference at a time, in response to either a user input or some request finishing. Sure, some guis will do large animations that are similar to how a game works, but these are exceptional circumstances; most the time, a game is drawing to keep the screen in sync with the state of the game world and most the time a gui is idle, waiting for something to happen. That's just the differences in functionality where they overlap. Other things are very different. Games often (but not always) value predictable latency audio, to maintain its a/v sync. Guis, being idle more often than not, can typically defer opening an audio device until they need it, then close it as soon as that effect is done. Most games contain themselves to one large, multi-role window. Guis often use several, with varying roles including temporary single-purpose windows (e.g. popup menus and toolips). Guis need to implement a variety of input patterns that games rarely care about - interprocess drag and drop, copy and paste, ui automation and accessibility apis; guis are more often part of a bigger cooperative whole than just on their own. Games just want to take whatever global input they get into their own self-contained game world, and games are more likely to care about joysticks and gamepads than guis. One library can help with both games and guis but it is unlikely to be a complete solution for either, certainly not both.
Re: Why are globals set to tls by default? and why is fast code ugly by default?
On Saturday, 1 April 2023 at 13:11:46 UTC, Guillaume Piolat wrote: TLS could be explicit and we wouldn't need a -vtls flag. Yeah, I think what we should do is make each thing be explicitly marked. When I want tls, I tend to comment that it was intentional anyway to make it clear I didn't just forget to put a shared note on the static.
arsd 11 progress report - scheduled for release in May
I haven't written much in the blog lately but I tried to catch up a little this week with a progress report of the code I intend to release in a couple more months. http://dpldocs.info/this-week-in-d/Blog.Posted_2023_03_20.html
Re: Read a text file at once for regex searching
On Monday, 20 March 2023 at 17:42:17 UTC, Paul wrote:
Do we have some such function in our std library?
Try
static import std.file;
string s = std.file.readText("filename.txt");
http://phobos.dpldocs.info/std.file.readText.html
Re: Code organization, dub, etc.
On Monday, 13 March 2023 at 13:20:21 UTC, Joe wrote: Yeah, it seems like it's *only* for libraries (and a few single-exe utilities). Looking at code.dlang.org, under "Stand-alone applications/Server software", the top rated item is "handy-httpd" which according to its dub.json builds a library! I'm not particularly interested in defending dub - i consider it a useless piece of crap that I only suffer through cuz some users demanded it - but you can use the subpackage thing to build multiple executables. My thing here does it: https://code.dlang.org/packages/adr-terminalemulator relevant config code here: https://github.com/adamdruppe/terminal-emulator/blob/master/dub.json#L31 So the mactabs exe and the attach exe and so on are all a bit different programs you can run from the code.
Re: 'auto' keyword
On Sunday, 12 March 2023 at 13:07:58 UTC, DLearner wrote: Is it correct that this _single_ keyword is used to indicate _two_ quite different things: No, it only actually does #2 in your thing. The type is optional meaning *any* storage class will work for type inference. `auto` is not special in variable declarations. (it can be special in other contexts though). auto A = 5; static A = 5; const A = 5; all the same.
Re: Desiring bool any_key_pressed()
On Friday, 3 March 2023 at 03:38:56 UTC, Daren Scot Wilson wrote: Here is a very simple version of the program I'm working on. Is there a way to write is_any_key_pressed() that doesn't block, doesn't require the Enter key, and doesn't require dragging in any complex libraries or dealing with low-level stuff like ioctl()? You have to do something since the normal behavior is the operating system holds on to the input until the user presses enter. You must tell it not to do that somehow. My terminal.d lib at least stands alone (for now, the next version will probably require two files instead of just one) and has things for this: http://arsd-official.dpldocs.info/arsd.terminal.html#single-key It is `input.kbhit()` just to test without getting the thing. Though... testing for input like this is a kinda iffy thing to do too, you might be able to adjust the program to be more event driven. Anyway, it is the "RealTimeConsoleInput" object in the library that tells the OS to stop buffering and send things directly. Its code isn't too complex - calls to tcgetattr and tcsetattr and similar for Windows - but still.
Re: Can't load FreeImage.dll with Windows
On Friday, 3 March 2023 at 19:07:14 UTC, WhatMeWorry wrote: loadFreeImage(`c:\Users\Admin\Downloads\FreeImage3180Win32Win64\FreeImage\Dist\x64\FreeImage.dll`); is your application build 64 bit too?
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Wednesday, 1 March 2023 at 13:01:03 UTC, Guillaume Piolat wrote: I think this has been the direction for years: ProtoObject, Object.factory, etc. These things don't really help with it unfortunately, but yes, this is the best goal.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 14:18:04 UTC, M.M. wrote: In the recent post by Mike Parker, betterC is used as a great alternative to C for writing bare-metal RISC-V application: Real D can do this too. betterC needs to die, it is just arbitrary special cases that add tech debt to the compiler and distract from D's real capabilities.
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote: with `betterC` you can target into new platform without much work, and easy to deal with dynamic library, generate much fast and smaller binary. you can do this without betterC too. often easier. And it could be even easier with a little bit of work that benefits everybody.
Re: How to get only the field name from an alias?
On Tuesday, 21 February 2023 at 02:41:34 UTC, Elfstone wrote: apparently F.stringof You almost never want to use .stringof, instead try __traits(identifier, F) and see what it gives you. Alternatively, loop over __traits(allMembers) which gives you the member names and pass that down. You can pull all the info out of allMembers with getMember and then other things to filter it out.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Saturday, 18 February 2023 at 21:23:24 UTC, ProtectAndHide wrote: The more I look at D, the more I like C++. cya
Re: Want a module to import from a sister directork; How?
On Tuesday, 14 February 2023 at 21:23:26 UTC, ryuukk_ wrote: module name must correspond to its path this is not true.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 13:00:04 UTC, thebluepandabear wrote: For my school I am commissioned to create many types of software. I tried to have a look at some of the gui kits in D but there was no tutorial for how to use them and they seemed as if they are lacking features in comparison to Qt/JavaFX. So your objection is one of newbie documentation. That's fair. Qt I always thought had nice docs, they're hard to beat. I've been slowly adding more to my stuff but it is a slow process. idk about features though, you saying "seemed" means you probably don't even actually know what they have so that's not as actionable.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Thursday, 9 February 2023 at 12:31:03 UTC, thebluepandabear wrote: I am actually taking a computer science class and I need to create desktop apps to pass and get through school. This is pretty easy in D. Like what specific kind of desktop app?
Re: betterC DLL in Windows
On Saturday, 4 February 2023 at 18:40:51 UTC, Tamas wrote: I do take your word for it, but now I have to re-evaluate my expectations towards D and perhaps use it for another project. I've got most of my project working in C already, but I was hoping to add some safety and better readability/managability by using some of the convenient features D offers over C. This is achieved without the betterC switch, and severely limited with it. Also, your words give me the impression that I cannot trust the documentation; which isn't a great start into the learning process. There's a lot of things described in the documentation that don't actually work. D can be an *extremely* productive language if you know which parts to focus on, but most the newer hyped features just don't deliver. The table of contents on the left side of the site is in roughly chronological order. The things near the top are pretty reliable, with a few exceptions (which are generally called out in the documentation if you read it carefully, like how the "static initialization of associative arrays" is "not yet implemented", or misuse of shared is "is not an error yet by default"). The things near the bottom are not reliable. The C++ interface works in some cases but you aren't likely to get far using it in any real world project; the C++ stdlib bindings are extremely minimal and Windows-only. The Objective-C interface works beautifully on dmd which cannot target the new Apple devices. ldc can generate code for those arm chips, but the Objective-C interface is not implemented on ldc. The portability guide and named character entities are pretty much ok. The memory safety `@safe` stuff only actually works if you 1) opt into it in the functions and 2) opt into it on command line params. This is mentioned in the docs as a small note near the bottom. The design of @safe also allows several things that can escape it on certain systems. The ABI page is ok, but there are several bugs in the debug info output. I find it good enough but it can be annoying. The vector extensions work on dmd if you can piece together the magic but the other compilers do it differently. The betterC page has several falsehoods on it, including the misinformation that you need to use it to link into C applications. This is just 100% nonsense. It also claims nearly the full language remains available, but this is also simply false. Some of the things listed there can be made to work with a bunch of code, but many things just plain don't work, even if you add the small amounts of code necessary to enable them. For example, interfaces don't work, even if you implement your own dynamic cast function. It just doesn't let them link. It claims constructors and destructors work, which is true, unless they're `static`, in which case you get random errors. Delegates and lambdas work if you manage captured variables in your own functors, but otherwise are simply disabled, even if you had your own backing system. Even module imports can fail because betterC disables outputting the module data info, even if it would otherwise be required by language rules, despite it not using the druntime. Then importC only works for toy examples. Using two separate headers or modules will result in spurious compile errors (and bugs detailing how to address this have been closed WONTFIX), and there's several kinds of C apis it just doesn't support. And finally, the @live functions also only work in toy examples and the design is fundamentally limited to only direct function calls, no struct aggregation is supported at all. It is a complete dead end. On the other hand, if you avoid most the compiler switches and stick to the more solid features - "Interfacing to C" and above on the list, for the most part - you'll find D is a very capable conservative language.
Re: betterC DLL in Windows
On Saturday, 4 February 2023 at 19:49:41 UTC, bachmeier wrote: I'm not sure what Adam's getting at when he says "hopelessly broken" but it's basically a subset of D. You're almost guaranteed to hit some wall with it and have no solution. Some of these are bugs but some of them are by design; betterC is a set of arbitrary restrictions without much consistent reasoning behind them. For example, with dlls, you still have to deal with all the potential problems of C library version mismatches, but if you use any module that touches a D feature it is likely to compile but then fail to link when someone uses it! All pain, no gain.
Re: betterC DLL in Windows
On Saturday, 4 February 2023 at 18:11:05 UTC, Tamas wrote: Well, as I'm new to D this isn't something I have insight into. Then you'd probably be better off taking my word for it (or even trusting your own limited experience where things worked until you added the switch) and just not using -betterC switch. It is hopelessly broken, but thankfully, it also brings zero benefit, so simply not using it is a viable path forward. I mostly need interop with C libraries and D would only serve as a glue, so I don't really need several features like GC etc. Just don't call those functions and they won't hurt you, aside from adding ~200 KB of size to the dll. On the other hand, the -betterC switch is hurting you - as evidenced by your own attempt working until you added it. Perhaps, but this doesn't help me much. It is a very easy solution to your problem. It is up to you if you want to take it and continue on in productivity or keep suffering for no benefit (and you'll find more trouble the further you go using the broken, barely supported switch).
Re: betterC DLL in Windows
On Saturday, 4 February 2023 at 16:45:31 UTC, Tamas wrote: and they compile without `-betterC`, but fail with link errors when using the switch. then don't use the switch lol -betterC is barely supported and completely useless so better to just not use it. export extern (C) void main() mixin SimpleDllMain; No need to ever mix two mains together, the DllMain is the required one. error LNK2019: unresolved external symbol _D4core3sys7windows3dll18dll_process_attachFPvbZb referenced in function DllMain This is just betterC breaking the code.
Re: WildCAD - a simple 2D drawing application
On Friday, 3 February 2023 at 08:30:55 UTC, Johann Lermer wrote: That at least should be fixed now. Confirmed, works here now! BTW I did `time make -j6` this time and it said 10 seconds, so still think the dmd -i approach better but if your incremental builds are smaller it might be better, I did git pull so of course that meant a lot of things were changed anyway.
Re: Which TOML package, or SDLang?
On Monday, 30 January 2023 at 15:37:56 UTC, Guillaume Piolat wrote: Why not XML? :) It has comments, you can use backslashes too. no kidding, xml is an underrated format.
Re: WildCAD - a simple 2D drawing application
On Monday, 30 January 2023 at 13:51:14 UTC, Johann Lermer wrote: Where exactly does this happen to you and what window manager do you use? I use old Blackbox. But it happens always, you click the window and it pops up as if the window is at (0, 0) instead of where it actually is. Probably due to the configure notify message not including location data (which window managers don't have to send)
Re: WildCAD - a simple 2D drawing application
On Sunday, 29 January 2023 at 17:14:40 UTC, Johann Lermer wrote: right - but isn't one of make's features, that it compiles code only when the source changes? When you just compile the whole thing at once, I would expect that you get longer times than when you change just one source file and compile just that. When your whole rebuild is fast enough, it doesn't really matter anymore. Well, that's the theory. It seems, that in the meantime everything depends on everything and so even small changes in the code lead to a recompiling of quite a few files and now every time even a small change takes even longer to recompile than your approach. Yeah, for an incremental rebuild to work well, you need to have pretty strict dependency discipline so chances actually can be isolated, and in D as well, you need to make sure your modules don't do much work just by being imported (just being referenced can trigger some compile time functions, for example, and if you compile things separately that depend on this, it gets done multiple times instead of just once like in the all-at-once build). This can be done, but it takes attention and often just isn't worth the hassle compared to the simple build, especially when the simple build does a decent job out of the box. Maybe it's just better to remove the whole make stuff - but it seemed to be a good idea at the time... I often make makefiles just cuz im used to typing `make`... but the contents are often: all: dmd -i main.d and i let the compiler do its thing.
Re: WildCAD - a simple 2D drawing application
On Sunday, 29 January 2023 at 13:55:41 UTC, Richard (Rikki) Andrew Cattermole wrote: dub isn't the issue, people who fight it like this, fight the D compilers and end up having issues. dub fights D compilers. This is why it forces me to write 600 lines of ugly configuration file for something that just works in dmd. That said, the directory layout here is indeed not optimal, and the makefile build takes *forever* which is disturbing. This program should probably build in < 3 seconds, not the... minute or two it took running make here. Proof: $ time dmd -i wildcad.d -I../../widgets/lib/source/ -I../../widgets/include -version=X11 -L-lX11 -L-lcups -L-lfontconfig -L-lcairo real0m2.703s Fully operational executable created in under 3 seconds.
Re: WildCAD - a simple 2D drawing application
I briefly played around with it, not bad at all. I did see the
menus popped up in the wrong place though, something to note is
that ConfigureNotify is a bit complicated in how it works. Let me
copy/paste a comment from my simpledisplay.d:
/+
The ICCCM says window managers must send a synthetic
event when the window
is moved but NOT when it is resized. In the resize case,
an event is sent
with position (0, 0) which can be wrong and break the dpi
calculations.
So we only consider the synthetic events from the WM and
otherwise
need to wait for some other event to get the position
which... sucks.
+/
if(event.send_event) {
win.screenPositionKnown = true;
win.screenPositionX = event.x;
win.screenPositionY = event.y;
}
You can also request the window position with
XTranslateCoordinates:
int x, y;
Window dummyw;
XTranslateCoordinates(dpy, window.nativeHandle, RootWindow(dpy,
DefaultScreen(dpy)), x, y, , , );
Which is what I do when it is time to pop up a menu.
Your thing works ok when maximized tho, it is kinda nice how you
got the rest working.
But as a fellow DIY widgetset author it is always fun to compare
and contrast :)
And since some of these X things are a bit obscure it helps to
steal tips from each other lol
Re: Qonquest 2 - A simple strategy game written in D
It is my fault for resizing, i used width,height instead of width_,height_ so it used the pre-scaled things. https://github.com/adamdruppe/arsd/commit/0019a7c6fb18453125b75aec465be7e5dce6f598 I think this also broke the mouse thing since it didn't adjust for the title bar indeed and then the view and click scaling didn't agree. sorry yeah definitely my bad and I'm in the middle of a bunch of other changes and not really ready to tag a bug fix but if you wanted to pull the files into your source dir instead of using a dub dependency you can skip ahead without waiting for the tag. Or I'll see what I can do to clean up my branch and cherry pick this fix later in the week...
Re: Qonquest 2 - A simple strategy game written in D
On Thursday, 26 January 2023 at 00:16:09 UTC, Hipreme wrote: The only button that works is the one that makes you lose. The function that dispatches click events to the in-game windows has a bug in its y coordinate. Click about a title bar width below a button and it will trigger. I suspect this is because the mode is set to `automaticallyResizeIfPossible` which emulates click positions but it works on my test programs. Perhaps due to the opengl viewport, possible it is my bug but I don't think so... at least not this one It might also be my bug in not adding/subtracting the title bar from the requested size tho. - The game does not like resizing the window ( I wasn't able to click anything after resizing and in my screen I can barely read it) On my computer it is truncated which isn't what is supposed to happen (automatically resize if possible should scale it). So there's something going on here and it might be my bug it is hard to tell.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
There should be a tool for auto-generating JS wrappers, perhaps
even HTML snippets, so that a user literally can just write:
import std; // OK, maybe import std.wasm or something
void main() { writeln("Hello, world!");
and get a webpage that prints that message in a browser window
without writing a single line of JS or HTML.
http://webassembly.arsdnet.net/
Paste in
import std.stdio;
void main() { writeln("hello world"); }
to the box on that page
and get
http://webassembly.arsdnet.net/usertemp
Webassembly is a trash target but like been there done that.
Of course there are some caveats in what works, there have been
come contributions coming in from hipreme recently to extend it a
lil.
Re: Non-ugly ways to implement a 'static' class or namespace?
On Monday, 23 January 2023 at 00:21:12 UTC, thebluepandabear wrote: there's nothing in the language currently that would 'force' the user Why do you hate freedom?
Re: How to write a library
On Saturday, 21 January 2023 at 22:53:19 UTC, Matt wrote: but what is the D equivalent to header files, and what do I have to do to prepare and use my library in another project? The most common and easiest thing in D is to just distribute the source files, the compiler can pull whatever it needs out of there. I almost never even build libraries separately, instead letting the compiler include them as-needed in the build.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
As far as he understood, the only time `@property` has an
effect is when you take the address of a function it annotates.
It is when you do typeof(thing.prop), not
Walter said that `__traits` is meant to be ugly.
We should revisit this decision. I don't think it ever made
sense, and especially now with the benefit of hindsight it looks
like a clear unforced error.
Robert said that doesn't solve his problem with compile times.
He has a project that doesn't use much of Phobos, but compile
times still suffer. The compiler is slow.
I'd like to know more about this project
He had previously dug into `hasUDA` and it was scary how many
recursive expansions he found.
We should also revisit the abstractions here. The more I use
these the more I've been landing on something like what Steve
described in the dconf online. It is faster to compile, more
flexible with runtime reuse, and just generally easier to
document and use.
Then we can just let hasUDA and friends die.
That goes to the idea of caching or pre-compiling the template
so that
Please note that the compiler does cache templates right now, and
it takes gigs of memory. A lot of work would have to be done to
make this good since work not done is still better than work
unnecessarily done... and if it is cached too aggressively you
just run out of memory.
If the end result is simple, we ought to be able to discard
intermediate results, but the current implementation doesn't even
allow this!
We don't have [...] `std.html` [...] We just need someone to
write them.
Yes, if only some did that 13 years ago and has been continuously
maintaining it ever since. If only ~someone~ wrote that.
Something was causing the struct configuration to take over 10
minutes to compile.
If you did any string replacements that'd slaughter your
performance, the ctfe engine is *extremely* bad at this.
In my arsd.jni, I had a string like:
enum code = q{
PRETEND_MACRO void foo() { implementation; }
};
mixin(code.replace("PRETEND_MACRO", ""));
mixin(code.replace("PRETEND_MACRO", "static"));
Those two simple lines added 30 seconds to the compile time! Just
copy/pasting it and replacing the pretend macro ahead of time cut
95% of the build time off. It was astonishing.
You can optimize some of these with mutable buffers, avoid the
concat operator in ctfe even if it means two passes through the
data. This helps a lot.
But also just using template mixins tends to work well when you
know the proper techniques.
Re: Is there a way to get a template’s parameters and constraints?
On Friday, 20 January 2023 at 17:15:31 UTC, Quirin Schroll wrote: Is there a trait (or a combination of traits) that gives me the constraints of a template? No, reflection over templates is very limited.
Re: D Static Array
On Sunday, 15 January 2023 at 14:23:59 UTC, Salih Dincer wrote: int[0] arr = 40; // ? The = 40 means fill all array entries with the number 40. The [0] means there are no array elements. So it filled all the 0 elements with the number 40. If it was like int[3] arr = 40, then arr[0], arr[1], and arr[2] would all be 40. In C99 and later C standards, an array size can be defined as 0 and it can include a feature called flexible array member (FAM) which is an array member without specifying its size This is not supported in D.
Re: Mixin helper help
On Saturday, 14 January 2023 at 18:57:21 UTC, John Chapman wrote: I wanted to remove the double braces in my static foreach (needed as I declared some aliases inside but since it creates a scope those new variables can't be referred to outside of it). Inside a function, you can often just use plain foreach instead of static foreach and simplify things. But it depends on the whole context. Where the helper thing helps a lot is outside functions, where normal foreach and double brace are both prohibited.
Re: Failed to archive JPEG (ArchiveMember): Invalid UTF-8 sequence (at index 1)
On Saturday, 14 January 2023 at 01:08:25 UTC, Ki Rill wrote: a JPEG image. member.expandedData(file.readText().dup().representation()); A jpeg image is not a text file. Read it with `std.file.read()` instead of `readText`. Then you can get rid of those useless dup.representation calls too.
Re: D Language Foundation Monthly Meeting Summary for November 2022
On Thursday, 12 January 2023 at 11:47:26 UTC, Mike Parker wrote: Andrei asked Razvan about the status of [the ProtoObject DIP](https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1042.md). Razvan said that Adam Ruppe had raised some valid complaints in the DIP's pull request thread, and those were reinforced in the community review. [...] Andrei thinks it's worth making an effort to resolve any issues the proposal has. What I'd recommend doing is migrating the existing Object to match the desired capabilities. The biggest complaint people have that has no real solution in the existing language is the unconditional presence of the monitor field. I actually think you could infer this without too much of a breaking change; the presence of a `synchronized(this)` in the same module as the class definition could infer its necessity and add it to the type (this would also cover `synchronized` classes and methods, of course), but in other modules you couldn't be so sure (since they can be compiled separately). This would break anyone who uses synchronized(random_object) (which includes me btw) but the migration would be so simple (change the type) and it'd retain compatibility with old compilers so I think it'd be a minimum amount of pain. Other option is to just remove it and require everyone to use an explicit Mutex field, which also has a number of advantages, but is more invasive and means removing synchronized classes and methods as language features entirely. Among other complaints in that dip were opEquals, which is already fixed (and tbh could just be removed but i think it is fairly harmless to keep), factory which is slated for removal already, opCmp (which currently throws if you call it! so it isn't used by anything and could be simply removed), and opHash which recently was subjected to a random breaking change anyway (and a bad one that didn't achieve anything, but it shows that breakage is obviously on the table), so everything else already is being addressed in Object itself.
Re: enum functions
On Sunday, 8 January 2023 at 18:42:58 UTC, Salih Dincer wrote: I'm wondering 2 things; firstly, does having an enum mean there is no auto-return? Or could it be CTFE? It means nothing. The keyword tells the parser a function is about to begin, which triggers return type inference (exactly the same as `auto`), but otherwise it is completely ignored.
Re: Good News: Almost all druntime supported on arsd webassembly
On Friday, 6 January 2023 at 22:14:23 UTC, Ferhat Kurtulmuş wrote: One question. Does GC work with Adam's druntime for wasm? I haven't actually written one yet, so it leaks if you don't pay attention yourself. But I have a plan that should work: you do the setTimeout(collect, 0) so it runs when the event loop is idle. Then the wasm stack is empty so you can scan pure memory. IMHO, D's GC need a second thread This isn't true, it never needs a second thread, even on normal desktop. The problem with GC on wasm is the webasm stack is opaque. You can have the compiler output a shadow stack or my plan of scanning when it is empty. Either should work but I haven't had time to implement anything.
Re: Good News: Almost all druntime supported on arsd webassembly
On Friday, 6 January 2023 at 22:13:15 UTC, H. S. Teoh wrote: The big question I have right now is, what's the status of interfacing with web APIs such as WebGL? This part is really easy, you can call it from D with the opDispatch or pass it through as eval strings.
Re: Error "Outer Function Context is Needed" when class declared in unittest
On Thursday, 5 January 2023 at 16:38:49 UTC, Vijay Nayar wrote: Does that class inherit the scope of the function it is inside, similar to how an inner class does with an outer class? yup. They can see the local variables from the function.
Re: Error "Outer Function Context is Needed" when class declared in unittest
On Thursday, 5 January 2023 at 13:27:23 UTC, Vijay Nayar wrote: Why is this error only found when declaring a class in the unittest? A unittest is just a special function, it can run code and have local variables. classes and structs declared inside it have access to those local contexts, which it calls the outer function context. Make the outer class `static` too to lift it out of this and your error should go away.
Re: Breaking news: std.uni changes!
On Tuesday, 3 January 2023 at 05:23:55 UTC, Richard (Rikki) Andrew Cattermole wrote: The main concern would be shared libraries, which Phobos should be able to be distributed as on all platforms by all compilers. I said this on the discord chat but you should really just dynamic load the system icu if it is available.
Re: Vibe.d MongoDB database connection
On Monday, 26 December 2022 at 21:32:51 UTC, eXodiquas wrote: I looked a bit closer into the problem and I found an issue in the vibe.d repository that states that the current version of vibe.d is not compatible with MongoDB version >= 5.1 the mongo driver in the standalone package shares some code with vibe's but handled this 5.1 thing a bit differently and *might* work idk i haven't tested on one that new https://code.dlang.org/packages/mongo-standalone
Re: [Win32 API] MessageBox Example without MSVCR120.dll dependency
On Sunday, 25 December 2022 at 18:30:12 UTC, BoQsc wrote: This is a working Hello World example without dependency on Microsoft C Runtime Library you might also consider using `-m32omf` switch to dmd which will make it bundle the old digital mars c lib. this is generally worse but since it is bundled it can be convenient.
