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: 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: 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: 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: 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: 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: 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).
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: 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: 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: 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: 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: 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: 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: 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: text based file formats
On Tuesday, 20 December 2022 at 00:16:57 UTC, Walter Bright wrote: LOL, learn something every day! I've even written my own, but it isn't very good. Yeah, I wrote a csv module too back in... I think 2010, before Phobos had one. It is about 90 lines, still works. Nothing special but I actually kinda like it. https://github.com/adamdruppe/arsd/blob/master/csv.d
Why am I writing a THIRD text component class?!?
Take the bait. Click the link. The answer may surprise you. (ok let's be real, it probably won't surprise you, but you might enjoy the read anyway. then tell me if you guessed the reason correctly or not!!) http://dpldocs.info/this-week-in-d/Blog.Posted_2022_12_19.html
Re: text based file formats
On Monday, 19 December 2022 at 09:55:47 UTC, Walter Bright wrote: Curious why CSV isn't in the list. Maybe std.csv is already good enough?
Re: text based file formats
On Sunday, 18 December 2022 at 15:56:38 UTC, Robert Schadek wrote: * xml, there is some code already, the old std.experimental.xml code my dom.d doesn't do the sax parser part but has its own advantages over the other things (including being continually maintained for over a decade, unlike the phobos things)
Re: D + Qt + QtDesigner
On Thursday, 24 November 2022 at 07:14:40 UTC, Barbara wrote: As one of the lead developers of CopperSpice I can assure you writing an effective, cross platform, thread aware, GUI library is indeed very complicated and time consuming. Yeah, I've been working on it on-and-off for over ten years now. OpenGL is not the only requirement for a GUI and actually not the hardest part. OpenGL is not a requirement for a gui at all, in fact. Drawing stuff is the most trivial part (it always amuses me when people say they have "gui libraries" and it is just a few basic drawing functions). My gui lib allows opengl embedding, probably similar to your copperspice, but it also works without it. Bigger jobs though are the text (which is huge) and all the interactions people expect like drag and drop and just right scrolling and a whole range of things small and big.
Re: D + Qt + QtDesigner
On Monday, 21 November 2022 at 01:38:12 UTC, thebluepandabear wrote: how about we work on our own UI library for D language in opengl or something? been there done that http://arsd-official.dpldocs.info/arsd.minigui.html
Re: blog post about how you can make your gc code faster
On Wednesday, 9 November 2022 at 11:55:28 UTC, Guillaume Piolat wrote: I've been avoiding void[] for this reason (I mean, void[] _could_ contain pointers), but I think I'm cargo-culting this? Yeah, it actually doesn't really matter. It is the allocation type that sets the flag. So If I do: ubyte[] arr = new ubyte[100_000_000]; Since you `new ubyte`, it set NO_SCAN at the allocation. That's attached to the memory block now. void[] arr2 = cast(void[]) arr; // will this still avoid scanning? Meaning this will not scan the block. Where you get in trouble with void is if it was allocated that way to begin with. Then it will be scanned... but I'm pretty sure `new void[]` doesn't work anyway. Other potential trouble with this would be if you allocate as ubyte, then cast to a pointer type and store something in there. That might be freed prematurely since the block flags is set at allocation time, and not changed when you cast the slice. Even the precise collector doesn't really care since the type in a struct being ubyte[] or void[] are both themselves a pointer - the pointer to the array - so it'd count. But the array itself is stored elsewhere so the GC will look that up in its separate metadata. So you are OK using void[] here to hold things wrt gc scans. Just make sure it is allocated as a concrete type.
blog post about how you can make your gc code faster
Putting aside new GC implementation tweaks like I discussed last week, and not just switching to other functions, this week I wanted to lecture a bit about how you can reduce your GC pause times in stock D today: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_11_07.html
Re: parserino 0.2.0
On Saturday, 22 October 2022 at 21:58:54 UTC, Enjoys Math wrote: Nice! So it's D's answer to Python's BeautifulSoup. D has had a html tag soup parser since 2009 in my dom.d. The parserino might be more html5 compliant specifically though, as mine was written before html5 was a thing. It's been updated with it but still an independent parser (capable of reading in-the-wild html as well as things like xml and even php tags) instead of following their specific algorithm.
Re: Introducing alid
On Wednesday, 14 September 2022 at 08:44:48 UTC, Ali Çehreli wrote: Considering I may want to let the users import the entire package as well with dub is poorly designed and doesn't cooperate well with D features. There's no good solution - hence the hundreds of lines long dub.json trying to hack it in. Like you could have the top-level package depend on all of its own subpackages and then if you depend on it, you can import alid. Lots of spam for something that just works out of the box with stock dmd!
arsd 10.9 tagged
release notes on my blog: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_22.html known as arsd-official on dub, the library is a set of about 80 generally independent modules that you can pick and choose functionality from without onerous compile time nor run time dependencies, covering a broad array of use cases such as: * terminal.d for interactive text applications (comparable to ncurses and getline libraries), * simpledisplay, simpleaudio, and joystick for graphical applications (comparable to SDL libraries) * cgi.d, database.d, and many more for web server applications * dom.d for xml+html processing * minigui.d for desktop gui applications * image.d, archive, png, midi, ogg, and more for common file format work * nanovega and svg for 2d vector graphics * script.d and jsvar.d for an embeddable scripting language * http and websocket clients * jni.d and com.d for interfacing with outside languages * and other random things
Re: my d blog has idea of effect system to replace @nogc etc
On Tuesday, 16 August 2022 at 14:57:04 UTC, Guillaume Piolat wrote: I know it isn't really related, but currently on DUB there is 4 different @nogc nothrow string library, -betterC or not, friendly licence or not, with various tradeoffs, and I'm about to add another one. Yeah. I think some of that is going to happen regardless just because a lot of us have the not-invented-here syndrome, and some of the tradeoffs are rooted in legitimate concerns. When they have legitimate concerns, whether you have an effect annotation or not doesn't really matter (though the static checks are not always the best way to do it; a dynamic runtime check or a test suite might be just as good or even more appropriate). The lib might not be formally documented as unsuitable for you, but if it does something you can't allow, you're gonna be forced to find an alternative. So I think multiple libraries for different requirements is always going to happen, and is actually a good thing. And having this documented and/or tested (again, whether static checks or runtime checks) can also be a good thing. Sometimes at least. Though with D I think we're more duplicating because of just NIH or other sillier reasons than due to actual hard requirements in use. But still some of them are and even if we all worked together perfectly, we'd still want some separate libs that choose different trade offs.
Re: my d blog has idea of effect system to replace @nogc etc
On Monday, 15 August 2022 at 16:16:35 UTC, Sönke Ludwig wrote: The most prominent example would be something like vibe.d's `@blocking`, which currently just acts as documentation, but would be really useful if something like `@nonblocking` could actually be enforced at compile time - currently there is just a runtime solution for that. Aye, async in general has a lot of uses of this kind of thing. In addition to just not hogging the worker thread, being responsive to a cancellation request is a nice thing. Speaking of blocking, one of the effects I'd envision is something like "loops". Something blocking on a loop can more harmful to the event-driven i/o model than other blocks - at least other blocking calls can be interrupted by signals or something. On the one hand, you might think of it as madness to say `denies_effect!loops`. How will you get any work done? But there's two interesting bits: 1) you might be able to define it with higher order functions and 2) D's `foreach` loop is special. See, a foreach loop can just by syntax sugar over an opApply function call and we could say one of those loops instead just has the effects of opApply (which would necessarily add the effects of the user-provided delegate, of course). So you could imagine an opApply that uses the hidden effects escape to implement a loop, but inserts its own periodic `if(yield() == CANCEL) return;` logic, providing both regular returns to the scheduler event loop and opportunities to cancel the task. Indeed, the work chunks may even be auto-parallelized in the process too. Of course, users could also use the trusted hidden effect, but the act of doing so at least reminds them that they ought to be careful.
my d blog has idea of effect system to replace @nogc etc
In my blog this week, I described an idea I've had percolating in my brain for a bit about a user-defined effect system that could potentially move nogc, safe, pure, etc to library aliases - which would let you combine them as a fun bonus - among other things: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_15.html Like with other inferred attributes, the argument-dependent and virtual function caveats had to be mentioned, but since I talked about them in other posts not too long ago I didn't want to go over it all again. Next week, I'll probably write up release notes on arsd 10.9, which is overdue now but has a few new features (including ico file support, more http timeout control, a couple more hidpi linux fixes, a windows input gui fix, data uri transparent support, terminal cursor save/restore, and others) I'll tag once I finish regression testing. I doubt I'll announce that here since it is p routine but maybe, we'll see how spammy I feel once it is posted.
Exception2 described in blog post
```
import exception2;
void main() {
int a;
try {
// string error type instead of namespaced D type
// can still attach information though
throw Exception2!"foo bar"(a);
} catch(Exception2!"foo bar") { // caught by string
// printing it here would show the value of `a`
}
}
```
Read more at the link:
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_08_01.html
Re: Blog post on extending attribute inference to more functions
On Wednesday, 13 July 2022 at 21:42:20 UTC, bachmeier wrote: It would be nice if you'd spam our subreddit. I don't like reddit. It is hard to use. Of course if someone else wanted to post, you can. I might see it and comment but no promises since the UI is just really hard to keep up on and most reddit comments are low quality.
Blog post on extending attribute inference to more functions
A lot of people ask for more inferred attributes - safe, nogc, etc. I have some thoughts. Inferred Attributes Run-time dispatch Function documentation Compatibility contracts Attributes dependent on arguments ABI and .di file compatibility Compile speeds Conclusion Read the details on my website here: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_07_11.html I try to post something there once a week btw, but work+child can make that difficult to find time. So they are often a little late and many weeks I only post the auto-generated summary. But if you want to look down the index, you can find a lot of things I've talked about. I very rarely announce them here since I don't want to spam too much. So while you might only hear from me here a couple times a year, I am probably actually writing something on the website once or twice a month.
Re: D Community Conversations: Walter Bright on the Origins of D Part 1
On Monday, 11 July 2022 at 13:37:10 UTC, Mike Parker wrote: The primary motivation is to trim the length of the video down. I think that's important for YouTube videos. This has changed a lot over recent years - the youtube algorithm now rewards longer length videos. It is the rise of the podcast! The average youtube show I watch now is over 90 minutes long and these are pretty popular so it isn't just me. (Of course, I listen to them at 2x speed...) Though, I don't expect there'd be much of a difference either way between 55 and 60 minutes anyway... it'd depend more on how it sounds and flows to see if it worth your time I guess. I do think it turned out ok as it is btw.
Re: The D Programming Language Vision Document
On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote: I have just finished implementing string normalization which is based around UTF-32. There's a difference between utf-32 and unicode code points. It is required for string equivalent comparisons (which is what you should be doing in a LOT more cases! Anything user provided when compared should be normalized first. Which you can do on any translation format.
Re: D Language Foundation June 2022 Monthly Meeting Summary
On Saturday, 25 June 2022 at 01:11:26 UTC, Mike Parker wrote: we took a vote on it and rejected it Who are "we"? Where's the roll call?
Re: Release: serverino - please destroy it.
On Monday, 9 May 2022 at 20:37:50 UTC, Andrea Fontana wrote: The same goes for cgi/fastcgi/scgi and so on. Well, cgi does one process per request, so there is no worker pool (it is the original "serverless" lol). fastcgi is interesting because the Apache module for it will actually start and stop worker processes as-needed. I don't think the the nginx impl does that though. But the nicest thing about all these application models is if you write it in the right way, you can swap out the approach, either transparently adding the i/o event waits or just adding additional servers without touching the application code. That's a lot harder to do when you expect shared state etc. like other things encourage.
Re: Beerconf April 2022
On Friday, 29 April 2022 at 17:07:27 UTC, rikki cattermole wrote: Password: `dub4life` I see you are gatekeeping to keep a certain clique out!
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 12:23:54 UTC, rikki cattermole wrote: +1 infer everything! Well, you *can't* infer everything, but private things I do think you can get away with since they're not allowed to be virtual. Inferring more on non-virtual things is a maybe, you still have to think about the abi mismatches there but that might work.
Re: argparse version 0.7.0 - a CLI parsing library
On Friday, 18 March 2022 at 18:21:46 UTC, Anonymouse wrote: One drawback is documentation; adrdox does *not* like these kinds of UDAs. It is on my list to run big UDAs through the auto-formatter at some point pretty soon to help with this. I just have a big work project I'm wrapping up first.
Re: trash-d version 15
On Tuesday, 8 March 2022 at 16:19:13 UTC, rushsteve1 wrote: According to [the module documentation](https://dlang.org/spec/module.html) you can omit the `module x;` and it will implicitly be the file name. This is pretty flaky, I'd strongly recommend that for any module ever imported, use the explicit module definition, and use at last two names: `module mystuff.bar;` instead of `module bar;`, so there's lesser odds of a conflict with other libs out there (remember, the module namespace is superglobal across the whole end-user project, not just your own repo.)
Re: On the D Blog: A Gas Dynamics Toolkit in D
On Wednesday, 2 February 2022 at 16:32:26 UTC, H. S. Teoh wrote: Interesting that the author(s) found D error messages better than C++, in spite of frequent complaints about error messages here in the forums. :-P No incompatibility there: "better than C++" is a very low bar.
Re: The DIID series (Do It In D)
On Wednesday, 26 January 2022 at 15:53:44 UTC, Ola Fosheim Grøstad wrote: Is this list out of date? https://github.com/dlang-community/awesome-d You can tell it is very incomplete since it doesn't list arsd in every category. :P Well, I don't have a dedicated containers module. When I need one, I just make it inline. I'm considering adding one for version 12 though, which would come out in June 2023. We'll see.
Re: D Language Quarterly Meeting Summary for January 2021
On Sunday, 23 January 2022 at 04:12:30 UTC, H. S. Teoh wrote: On Sun, Jan 23, 2022 at 03:24:04AM +, Paul Backus via Digitalmars-d-announce wrote: [...] The way I envision it, `std` would be the "rolling release" namespace that allows breaking changes, and if you wanted stability, you'd have to explicitly depend on `std.vN`. What we currently call `std` would be renamed to `std.v1`. +1, this idea would work. I'm not so sure. Isn't the whole point of the versioning thing so you can use old things that haven't kept up with the latest? When it was written, sure, they used import std because that's easy and of course they want the latest stuff. Then a year later, the latest has moved on and now it is broken.
Re: Why I Like D
On Wednesday, 12 January 2022 at 15:25:37 UTC, H. S. Teoh wrote: However it turns out that unless you are writing a computer game, a high frequency trading system, a web server Most computer games and web servers use GC too. idk about hf trading.
Re: DConf Online 2021 Links
On Monday, 22 November 2021 at 18:26:33 UTC, Matheus wrote: I don't know the meaning of GFW prolly great firewall
Re: Beta 2.098.0
On Sunday, 17 October 2021 at 17:09:40 UTC, Guillaume Piolat wrote: Doing it by hand, until now, has been the preffered way to translate C and C++ headers. Why did dstep fail for them? How would importC help the bindBC project?
Re: Surprise - New Post on the GtkD Coding Blog
On Thursday, 9 September 2021 at 08:52:34 UTC, Dukc wrote: I thought that the Wayland architecture is in some way fundamentally better than X architecture That's what the wayland propagandists like to say (now... earlier they'd play up the similarities to make the "rewrite it" pill easier to swallow), but it isn't really true. Wayland's graphics system is a subset of X's - it takes the direct rendering component and leaves the others out - then combines the X compositor, X window manager, and X server into one component, when they then call the wayland compositor. But it is important to realize that direct rendering clients on X - which has been around since before Wayland was born - already work essentially the same way. The client gets a gpu buffer and does opengl rendering to it. Then they signal the display manager - whether X server or Wayland compositor - to show the buffer on screen and they do it when the time is right (e.g. vblank syncing). X does support other models too, but this is a good thing because it allows backward compatibility, better network efficiency, and simpler applications to just do simpler things too. Removing features people actually use in the real world is rarely that beneficial. So what is the major difference for graphics architecture? In X, the compositor is an entirely optional component. In Wayland, it is integrated into the display manager. That's the only real difference. What is a compositor? It is responsible for taking the images from each individual application and layering them on top of each other if you want additional scaling, transformation (like rotation), or transparency in between windows. Inside an individual window, you have all those things regardless of compositor. Traditional X servers can layer images without transparency or external scaling without any trouble at all. It only comes in when you want those fancier graphics things to happen without cooperation between windows. If you're thinking "that's not actually all that useful anyway", yeah me too. I've never used a compositor on my own system at all. Wayland claims that integrating this optional component provides a performance benefit by avoiding the cost of the additional context switch and synchronization. There's one place where that's legitimately true: exposing a window on a remote network connection. With core X, the server sends an expose event, then the client sends back a blit command from its buffer, or the drawing commands if it doesn't have one. Due to network latency, this can results in some visual lag and some flash as the server paints over a simple background color, then the client paints over it again. Wayland, of course, sees zero change here because it has zero support for this operation. Its network support - to the extent that there is any at all - is more like VNC screen share than X's remote commands. Anyway, even locally, that context switch thing is technically true but also almost certainly irrelevant since that cost is insignificant next to the time spent waiting for the vsync anyway if you use the direct rendering facility. It has a little more truth when comparing non-direct-rendering clients, but again Wayland sees zero benefit here because it simply has zero support for these use cases at all. Those programs just plain don't work. They must be rewritten to target Wayland which means they'd be forced to switch to a direct render system. But if you're rewriting the application anyway, you could just port the X application to the direct render infrastructure too. Anyway, just for background, since a compositor works with these older style applications a bit differently - those clients are not written with the extension apis in mind and assume they are going directly to the screen (well actually there's non-DRI clients that sync to double buffers too, you can render to pixmaps in the traditional api and blit it over (all core X functionality there) with a sync trigger which was provided as an extension in 1991, or you can use the XRender extension which provides an explicit double buffer function, which was provided as an extension in 2000) - the compositor intercepts the final draw to screen and redirects it to another buffer, then does the alpha blend etc on that before getting to the actual screen. It may need to guess which draws to screen are supposed to be immediate and which are already buffered and synced by the application which can introduce a bit of additional lag; it might vsync twice, for example. This is rare in practice, but when the implementation gets it wrong, you do get either a missed frame or mid-frame screen tear. But like that's an older API being used on a buggy implementation. Again, if your fix is to rewrite the application anyway, you can just use the different api and/or fix the bug in your existing implementation. There's no real world benefit.
Re: Surprise - New Post on the GtkD Coding Blog
On Tuesday, 7 September 2021 at 12:29:14 UTC, Dukc wrote: On Friday, 3 September 2021 at 18:52:13 UTC, Adam D Ruppe wrote: (i loathe and despise wayland but ill try not to rant) Have you written more about this on your blog? I have not (well not directly anyway, wayland flamewars is one of the things that directly inspired this post: http://dpldocs.info/this-week-in-d/Blog.Posted_2021_03_08.html#adam's-rant ). The short version is the wayland devs were hyperfocused on one use case and missed the big picture. This led them to wrongly believe that the majority of X is completely useless legacy bloat, so instead of patching up the one use case, they threw it all out. ...then they have spent 13 years slowly reinventing it doing extension after extension and revision after revision after revision, and still haven't actually even reliably fixed the one issue they complained about... while X actually did patch it up if you opt into it (via the dri2 and sync extensions) and it does a pretty good job. They also bring up spurious security complaints - which have been around since the 90's btw but never materialized into a real problem - which are also patched via X extensions or nested servers. It could certainly be better but a version 1.1 or 2.0 of the security extension could realistically fix that up, no need to throw everything out. (Notice how Microsoft made similar changes in Windows without a significant breakage of backward and interoperation compatibility.) So they broke everything for no benefit. Again. It is just like the broken audio stuff. And then it really annoys me that the wayland proponents are rarely well educated on X, saying things that are just untrue. So that ups the flamewars to 11.
Re: Surprise - New Post on the GtkD Coding Blog
On Friday, 3 September 2021 at 15:47:41 UTC, Ron Tarrant wrote: https://gtkdcoding.com/2021/09/03/0112-gtk-gio-application-barebones.html "GTK team dropped window position handling" im p sure the wayland system either doesn't support it or STRONGLY discourages it if it was added in an extension. so if it isn't gtk's own ideology, it is now the lowest common denominator on linux. (i loathe and despise wayland but ill try not to rant)
Re: SAOC 2021 Projects Summarized
On Monday, 30 August 2021 at 16:03:29 UTC, Guillaume Piolat wrote:
Hyped by ProtoObject, this is our hope for a nothrow @nogc
.destroy eventually!
This fails today only because of the rt_finalize hook working
through void*. If you cut that out...
---
class Foo {
~this() @nogc nothrow {}
}
void main() @nogc nothrow {
scope auto foo = new Foo();
foo.__xdtor();
}
---
this works today.
.destroy does this if it is an extern(C++) class, but not for a D
class. It isn't limited by Object though. I think the templated
druntime hooks might make more of a difference here than
protoobject.
Re: LDC 1.27.0-beta3
On Thursday, 15 July 2021 at 02:54:14 UTC, rikki cattermole wrote: If yes, it might be worth it to get rid of export as a keyword out right in a DIP (as it introduces the possibility of linker errors that would otherwise not need to exist). No, that's a bad idea.
Re: DIP 1036--String Interpolation Tuple Literals--Has Been Withdrawn
On Thursday, 27 May 2021 at 20:42:11 UTC, M.M. wrote: I assume that you, Adam and Steven, hold the new (YAI)DIP in high regards. Is that right? Yeah, there's a few small tweaks I'd make (I opened an issue on the repo with them), but I'm pretty happy with it and simplifying the goals like it does helps a lot.
Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android
On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote: Hmm, things gotta have a license, why not GPL would CC0 be better? is attribution and sharing code so weird ? GPL is a perfectly fine license. If people don't want to use it because of that, their loss, not your problem.
Re: Release D 2.096.0
On Sunday, 14 March 2021 at 18:25:51 UTC, starcanopy wrote:
int foo() { return 1; }
int foo() => 1;
I'm concerned that this feature will be in purgatory if its
author becomes busy or forgets about it. (Barring another
individual assuming proprietorship.)
I wrote the implementation for that and I've made it clear that I
have zero interest in going through the DIP process; I'm done
with it as is. Someone else will have to do whatever else they
decide to do.
Re: Beerconf February 2021
On Friday, 26 February 2021 at 18:06:45 UTC, Ali Çehreli wrote: Whose tomorrow? :) For some reason I need exact times for this. Is it all weekend hours anywhere on the world or specific UTC times? The way it works is usually one person gets on at some random point typically around the European morning - they'll message when it is up - then it just stays on until Sunday evening in the US east. People come and go as they please over that whole ~40ish hour period.
Re: I learned something new in D this week! (anonymous class rundown)
On Friday, 19 February 2021 at 17:41:51 UTC, Patrick Schluter wrote: DWT users knew about anonymous classes as they are used a lot there. Of course as SWT is a Java based library, D had to had the features to ease the porting. Aye, my understanding is actually they were added to do specifically at the request of the DWT porters. Did you know about the constructor args though? That's what was new to me, I always thought you had to do a zero-arg constructor in the anonymous class (which works 99% of the time anyway.)
Re: I learned something new in D this week! (anonymous class rundown)
On Thursday, 18 February 2021 at 22:37:06 UTC, superbomba wrote: Once I start reading, I can't stop! :) Better be careful, there's about 250 entries now so you could waste away trying to read it all! (About 145 in twid's first iteration and now about 115 in the second iteration. Of course most of them are probably pretty boring, but like skimming the old iteration's tip of the week index here http://arsdnet.net/this-week-in-d/totw-index.html might be educational too. I need to index out the old interviews and such too, my stuff is easy enough if you keep up with it but it has poor searchability/skim ease looking back on it.)
Re: I learned something new in D this week! (anonymous class rundown)
On Thursday, 18 February 2021 at 16:54:31 UTC, Ritter wrote: Somebody from russian D's Telegram channel translates your article into Russian. Maybe, it can be usefull Nice!
Re: I learned something new in D this week! (anonymous class rundown)
On Thursday, 18 February 2021 at 07:28:27 UTC, Ferhat Kurtulmuş wrote: I came across anonymous classes by reading your minigui codes, such as [1] some time ago. I did not read anything about them except your sources. Good reading, thanks. Yeah, I sometimes see them on lists of features to be cut from D since they aren't well known, but I'd miss them if they were gone. It isn't terribly important but I find them pretty convenient.
I learned something new in D this week! (anonymous class rundown)
Many of you know I've been around D for a long time now and picked up a lot of random tricks over the years, so it isn't every day I learn about a new old feature in the language's basic syntax. Would you like to know more? http://dpldocs.info/this-week-in-d/Blog.Posted_2021_02_15.html I also showed how you can use anonymous classes in betterC without any crazy hacks btw! Lately most my blog posts have just been quick updates on what features are coming in my libraries, but I still write these more general-knowledge kind of tips from time to time. (and sometimes the lib entries can be generally educational too like my little attempt at demystifying fibers a couple months ago: http://dpldocs.info/experimental-docs/arsd.fibersocket.html#conceptual-overview )
Re: Beerconf January 2021
On Saturday, 16 January 2021 at 16:28:34 UTC, Imperatorn wrote: Do you guys usually have some agenda or is it just drink n talk about D? The only agenda is MILKCONF or beerconf for people who aren't me People can gab about whatever comes to mind.
Re: I'm creating a game purely written in D with the arsd library
On Saturday, 2 January 2021 at 05:43:48 UTC, James Blachly wrote: Still, why not source code on Github? Is this really any different? Do you actually audit the source? simpledisplay is 17,000 lines. How much of that code is pure evil? Part of my twisted desire to burn the entire universe into atoms then recreate the world in my own image? spoilers: all of it :P
Re: Our community seems to have grown, so many people are joining the Facebook group
On Tuesday, 29 December 2020 at 15:06:07 UTC, Ola Fosheim Grøstad wrote: hostile ad hominem tone [...] deliberate attempt to fracture. tu quoque. Let's not assume any motives here. I wouldn't call it "official" either (and indeed, the title on facebook doesn't include that word) but no benefit calling it nefarious.
Re: Httparsed - fast native dlang HTTP 1.x message header parser
On Tuesday, 15 December 2020 at 10:04:42 UTC, tchaloupka wrote: But if these benchmarks helps Adam to make some incremental improvements it's a plus and many of that can be pretty low hanging fruit. Yeah, I think the biggest benefit to changing this around is to just avoid creating unnecessary garbage. On the individual item, it doesn't really matter, but it can build up to a totally wasted collection cycle as time goes on. Just on the other hand, in any non-trivial real world application there's likely to be some garbage generated anyway and this will disappear into the noise. Though in the hello world benches it could bring the "max" column down since I'm p sure that is caused by a GC cycle and hello world can potentially avoid having even one :P That means that with a performant parser, arsd could go up to around 27548 RPS -> not much of a difference that would be worth the hassle.. Yeah, that one is basically entirely the result of the thread work queue. If everything else was perfect, the thread stuff would still dominate. (My evidence for this is the hybrid and process dispatchers doing pretty consistently better. The thread one though is simple and cross-platform which is nice - like without it, that Mac version probably wouldn't have worked at all since I've written no mac-specific code in this module.)
Re: Httparsed - fast native dlang HTTP 1.x message header parser
On Tuesday, 15 December 2020 at 00:32:42 UTC, H. S. Teoh wrote: It may not be the fastest web module in the D world It actually does quite well, see: https://github.com/tchaloupka/httpbench (from the same OP here :) ) The header parser is nothing special, but since header parsing is a small part of the overall problem, it is good enough. Though I have been tempted to optimize it a bit more since in a hello world benchmark even a small thing like header parsing can be noticeable. The fact that it does some totally unnecessary GC allocations can perhaps add up too. (If I was doing all this again from scratch I'd actually be tempted to do a zero-copy, all lazy version. Read from the socket directly into the request-local buffer, then slice into it while parsing, then do decoding on-demand in that same buffer - url encoding always takes more space than the decoded version - and the result should be basically the fastest thing you can get. And if something comes in above typical size, then it can go back to the normal reallocated buffer and still win big on the average request. The problem with doing that now would be maintaining compatibility with my existing API.) (But of course, if Adam improves cgi.d to be competitive with vibe.d My biggest deficit compared to vibe is prolly documentation. Especially of my advanced features which are practically hidden.
Re: Httparsed - fast native dlang HTTP 1.x message header parser
On Monday, 14 December 2020 at 21:59:02 UTC, tchaloupka wrote: * arsd's cgi.d - I haven't expected it to be so much slower than vibe-d parser, it's almost 3 times slower, but on the other hand it's super simple idiomatic D (again doesn't check or allow what RFC says it should and many tests will fail) yeah, I think I actually wrote that about eight years ago and then never revisited it actually git blame says "committed on Mar 24, 2012" so almost nine! And indeed, that git blame shows the bulk of it is still the initial commit, though a few `toLower`s got changed to `asLowerCase` a few years ago... so it used to be even worse! lol But wanna see something that will make you cry? https://github.com/adamdruppe/arsd/blob/master/http2.d#L1232 I have another http header parser!!! That's for my client, and as you can see, it is... not great. The case-insensitivity for example is a mega hack and I actually need to fix that eventually. At least there's some support for line continuations there. I don't remember if I ever actually tested that though, it seems most clients and servers don't do that anyway.
Four new entries in my D blog including cross-package doc search release
I aim to write a weekly blog about D, often just summarizing some recent changes to my libraries or sometimes a random rant (at times very loosely related), but I don't always keep up. Usually when I miss a couple weeks, I just post the auto-generated forum index and move on. But in November, I missed all the weeks because I had a bunch of stuff I *wanted* to write about, but didn't have time to type it all up. Well, I finally caught up with writing and will post here: simpleaudio now has playOgg, Mp3, Wav with resampling and can access multiple soundcards on Linux, adrdox gets ddoc on function params. http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_09.html New selective mouse input in terminal stack, Xft used in simpledisplay to improve TrueType font support http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_16.html I did a dconf livestream! Would you like to know more? http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_23.html dpldocs.info cross-package search finally released! and more terminal getline enhancements http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_30.html That last link is something hopefully useful to many of you: my dpldocs.info search engine now dives a bit deeper into the dub ecosystem. And that index will continue to grow as time goes on. If you like any of my D code or tips and tricks, you should refresh my blog homepage periodically: http://dpldocs.info/this-week-in-d/Blog.html every few weeks is a good frequency. Takes me hours to write but I try to summarize and organize so you can skim in seconds, read the interesting parts in minutes. There's also an rss feed you can set your program to automatically check every once and a while if you like. No need to check more than once a week, that's my maximum frequency. I aim for monday but often don't actually do it until later.
Re: LDC 1.24.0-beta1
On Monday, 19 October 2020 at 14:20:02 UTC, Paul Backus wrote: Are we looking at the same instructions? ah i mixed it up with https://dlang.org/dmd-linux.html#installation in my brain without clicking the link :( sorry my bad those are ok.
Re: LDC 1.24.0-beta1
On Monday, 19 October 2020 at 13:43:14 UTC, Bastiaan Veelo wrote: I'm not suggesting that this fills the need of newbies, but there is this: https://dlang.org/install.html. Nobody should ever follow those terrible instructions, they leave you so fragile in the event of future updates, takes superuser install access, and just generally scatters crap. If anything that page should be marked like "FOR PACKAGE MAINTAINERS ONLY" (even then I wouldn't do it that way but at least that's a kinda valid use case) since no end user should ever mess with that. Just unzip it in place. Maybe add it to your PATH if that's your thing. But don't go scattering files, you'll regret it when it comes update time.
Re: LDC 1.24.0-beta1
On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: Not sure what to do with the .7z file without manual tinkering. You can simply unzip it and use it directly. That's the best way to use most D compilers actually, then any versions can live side by side without affecting each other.
Re: HTTP frameworks benchmark focused on D libraries
On Sunday, 27 September 2020 at 10:08:24 UTC, tchaloupka wrote: * new RAW tests in C to utilize epoll and io_uring (using liburing) event loops - so we have some ground base we can compare against I fixed some buffering issues in cgi.d and, if you have the right concurrency level that happens to align with the number of worker processes... I'm getting incredible results. 65k rps. It *might* just beat the raw there. The kernel does a really good job. Of course, it still will make other connections wait forever... but my new event loop in threads mode is now also giving me a pretty solid 26k rps on random concurrency levels with the buffering fix. I just need to finish testing this to get some confidence before I push live but here it is on a github branch if you're curious to look: https://github.com/adamdruppe/arsd/blob/cgi_preview/cgi.d Compile with `-version=embedded_httpd_threads -version=cgi_use_fiber` to opt into the new event loop. But the buffering improvements should register in all usage modes.
Re: HTTP frameworks benchmark focused on D libraries
I fixed my event loop last night so I'll prolly release that at some point after a lil more testing, it fixes my keep-alive numbers... but harms the others so I wanna see if I can maintain those too.
Re: beerconf September!
On Saturday, 26 September 2020 at 18:44:06 UTC, Andrei Alexandrescu wrote: What time is it and what's the chat link? A bunch of us coming and going at all hours, decent group on now. https://meet.jit.si/Dlang2020SeptemberBeerConf password: -preview=in
Re: HTTP frameworks benchmark focused on D libraries
With my lib, the -version=embedded_httpd_threads build should give more consistent results in tests like this. The process pool it uses by default in a dub build is more crash resilient, but does have a habit of dropping excessive concurrent connections. This forces them to retry which slaughters benchmarks like this. It will have like 5 ms 99th percentile (2x faster than the same test with the threads version btw), but then that final 1% of responses can take several seconds complete (indeed with 256 concurrent on my box it takes a whopping 30 seconds!). Even with only like 40 concurrent, there's a final 1% spike there, but it is more like 10ms so it isn't so noticeable, but with hundreds it grows fast. That's probably what you're seeing here. The thread build accepts more smoothly and thus evens it out giving a nicer benchmark number... but it actually performs worse on average in real world deployments in my experience and is not as resilient to buggy code segfaulting (with processes, the individual handler respawns and resets that individual connection with no other requests affected. with threads, the whole server must respawn which also often slips by unnoticed but is more likely to disrupt unrelated users). There is a potential "fix" for the process handler to complete these benchmarks more smoothly too, but it comes at a cost: even in the long retry cases, at least the client has some feedback. It knows its connection is not accepted and can respond appropriately. At a minimum, they won't be shoveling data at you yet. The "fix" though breaks this - you accept ALL the connections, even if you are too busy to actually process them. This leads to more inbound data potentially worsening the existing congestion and leaving users more likely to just hang. At least the unaccepted connection is specified (by TCP) to retry later automatically, but if it is accepted, acknowledged, yet unprocessed, it is unclear what to do. Odds are the user will just be left hanging until the browser decides to timeout and display its error which can actually take longer than the TCP retry window. My threads version does it this way anyway though. So it'd probably look better on the benchmark. But BTW stuff like this is why I don't put too much stock in benchmarks. Even if you aren't "cheating" like checking length instead of path and other tricks like that (which btw I think are totally legitimate in some cases, I said recently I see it as a *strength* when you can do that), it still leaves some nuance on the ground. Is it crash resilient? Debuggable when it crashes? Is it compatible with third-party libraries or force you to choose from ones that share your particular event loop at risk of blocking the whole server when you disobey? Does it *actually* provide the scalability it claims to under real world conditions, or did it optimize to the controlled conditions of benchmarks at the expense of dynamic adaptation to reality? Harder to measure those.
Re: D mentionned in the ARTIBA webzine for an article on Silq
On Tuesday, 8 September 2020 at 08:33:35 UTC, aberba wrote: Now I really want to sew your D web workflow and stack in use at DConf Online. Don't say no!! Yeah, I did tell the dconf people I'd do a livestream thing if they need me, but I was thinking about making an Asteroids clone or something then porting it to webassembly like I did with tetris so I could talk about the library etc too. But a web site is tempting as well, just not sure I could actually do something useful with it in under 90 mins. I can surely slap something together and talk about the code but I prefer having a real goal and those often take me a longer time. Later today though I will post a blog about the source code to this new thing. There's actually not much to it, it just looks a bit longer than it is because I did a lot of copy/paste lol
Re: D mentionned in the ARTIBA webzine for an article on Silq
On Wednesday, 2 September 2020 at 13:31:25 UTC, Adam D. Ruppe wrote: I could write that in a few hours. I went ahead and did it: https://dwidder.arsdnet.net/ might move later but eh the basics work i think.
Re: DConf Online 2020 Submission Deadline Extended
On Monday, 31 August 2020 at 08:36:09 UTC, Mike Parker wrote: So send me your <= 5-minute videos describing your talks, folks! There's basically zero chance of me doing this part specifically. But on the other hand, between my self-loathing and procrastination, I probably won't record a talk video either so maybe it is an accurate filter. One of the "we'll do it live!" options are a bit more appealing but I still don't even know what I'd talk about anyway. Like I could probably code a website or something but idk, I've been meaning to do that for the written blog as well and haven't gotten around to it and with the baby only like a week or two away now, no promises I will by November at all.
Re: D mentionned in the ARTIBA webzine for an article on Silq
On Wednesday, 2 September 2020 at 18:42:25 UTC, starcanopy wrote: But if you do create an ad-hoc service, I'd very much use it if you didn't necessitate registration with an email. So I think some kind of user account is useful and I figure I'll require them... but it will be just a random username+password rather than a required email or whatever. Simply set your browser to auto fill and it should be pretty painless... would that be good enough for you?
Re: D mentionned in the ARTIBA webzine for an article on Silq
On Friday, 4 September 2020 at 17:47:39 UTC, James Lu wrote: And there's a Facebook? Seriously? A random user set it up and tries to push it but there's not much activity. And Slack? That's more used by like dconf coordinators. The places new people come on for chat is just the irc and the discord.
Re: D mentionned in the ARTIBA webzine for an article on Silq
On Wednesday, 2 September 2020 at 07:38:01 UTC, JN wrote: One thing I always feel this forum is missing is a section for work in progress projects, even if they never end up anywhere. Yeah, I often want a place to just gab. I kinda do in my blog, but that's more often something that is more finished since I feel like a blog post needs to have some more length to it: http://dpldocs.info/this-week-in-d/Blog.html I tweet from time to time but it is hard to fit code examples in there, like this one last night https://twitter.com/adamdruppe/status/1300914727627960320 yeah that took some trimming. of course if you are on the #d IRC channel you can often find me basically talking to myself as I think out loud about whatever code I'm doing at the moment... lol But what I think would be really cool though is like an internal twitter... no size limit but also a culture that there's no expectation for length and quality. Just casual "think out loud" or in-progress project updates that can split into chat. I could write that in a few hours. then blog about it omg. but the hard part isn't technical, it is just getting people to actually use it. I always reference the old dsource forums - http://dsource.org/forums/ phpbb :) :) :)
Re: tetris in D in webassembly
On Tuesday, 11 August 2020 at 04:10:10 UTC, starcanopy wrote: This is really cool. This idea, especially, titillates me: That's actually easy enough to do I just went ahead and made it. so behold: http://webassembly.arsdnet.net/ and the source is pushed up to github, with just a little bit of effort you can prolly run it at home. I don't have write access publicly to my server here to play with... but I might even add a little form for that so you can goof around with this dead-simple by copy/pasting some source code into the browser form. But still with this I can add more demos easily and you can see the source in the browser so it is something to play with.
Re: tetris in D in webassembly
On Tuesday, 11 August 2020 at 13:22:02 UTC, jmh530 wrote: The blog post says it is space bar. Tripped me up too. Yeah, I learned yesterday that there's a whole other PC tetris world I had no clue about. I only ever played the Nintendo/ELORG version on the NES. On that, dpad is left, down, speed, and then the A button is rotate. So for my clone I based it on that, arrows move, space bar, on the opposite side of the controller, does the rotation. The specifics of piece movement etc. are kinda based on that NES game too and the newer PC games have all kinds of other rules that I just never knew. But oh well, the game was at first something to just kill time on a boring flight, so I wrote it from memory on my laptop. Then it posted as a simpledisplay.d demo basically. And now I used it for webassembly because I thought it was super cool to have the very same source code we used on desktop last week in the browser this week (even though like I said there, I cut a LOT of corners to finish it in my limited time). Now I kinda want to expand the library a bit more. It occurs to me if I did draw text too and a little bit more input events, then my terminal emulator could run in the browser. Then my terminal client code can go there since it can embed the emulator. And a little more work, minigui.d's custom widgets can too... It wouldn't be a good experience tbh but it might be cool online demos of future programs and can also load up some of these little games etc on mobile too though the browser.
Re: tetris in D in webassembly
On Monday, 10 August 2020 at 21:30:53 UTC, matheus wrote: By the way you should post on reddit (/r/programming) if you haven't already. I don't really do reddit. I sometimes troll in the comments but it isn't a site I care for. That said if you or someone else wanted to and post the link, I'll answer questions that come up there.
Re: tetris in D in webassembly
On Monday, 10 August 2020 at 16:24:02 UTC, Steven Schveighoffer wrote: Bug report: the score doesn't increase for me when I complete a line ;) The reason for that is actually explained in the article; has to do with webassembly not blocking on eventLoop and the program was written with the assumption that it would.
tetris in D in webassembly
http://webassembly.arsdnet.net/ tetris.d source here: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_03.html#tetris-in-d web assembly source and explanation here: http://dpldocs.info/this-week-in-d/Blog.Posted_2020_08_10.html Short version: BARE MINIMUM druntime port to webassembly together with a bare minimum source port of simpledisplay.d to it as well made that little game playable. In theory we could make a lot more work by building up one function at a time. In practice I gotta get back to real work so don't hold your breath :)
