Re: DLF September 2023 Planning Update

[max haughton via Digitalmars-d-announce]

On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven 
Schveighoffer wrote:

On Tuesday, 14 November 2023 at 16:07:26 UTC, Mike Parker wrote:

[...]


What do we want the first experience with D to be like?

A person trying out D, who writes a one-file simple application 
using phobos *does not care* that a lib abandoned in 2018 still 
compiles. So why should they be the ones paying the penalty?


I get that we want to stop breaking builds. But the answer 
there is simple -- provide a way to do it by attributing the 
files, or by telling the compiler "these files are edition X" 
or whatever. And once you attribute it, it never breaks again. 
Sounds like a reasonable cost to me for those who want 
long-lasting code!


There are other options here. Like use the filesystem to 
identify the edition either via config or filenames.



[...]


That's not any better. If you have to opt-in to the language as 
it exists, people are going to quit immediately. I'm not joking 
about this. Imagine spending 2 hours trying to figure out why 
your app that is trying out some new feature doesn't compile, 
only to find out after posting online that it was looking at 
some ancient version of phobos.


-Steve


Ergonomically it potentially doesn't have to be quite so binary 
e.g. a C++ compiler will tell you to opt-in to a new language 
version rather than just erroring.


But, if you have the logic to do that, you can also infer an 
*older* edition to keep the abandonware working even though by 
default you get the most recent one.

Re: DLF September 2023 Monthly Meeting Summary

[max haughton via Digitalmars-d-announce]

On Sunday, 12 November 2023 at 19:50:02 UTC, Mike Parker wrote:
Well. For the first time in all my years of using these forums, 
I've managed to post something that exceeds the byte limit. 
You'll find the September 2023 Monthly Meeting Summary at the 
following link:


https://gist.github.com/mdparker/f28c9ae64f096cd06db6b987318cc581


Two notes:

- Making the build bit of build.d simpler would be nice although 
reading the source code will reveal that it doesn't just build 
the compiler.


- I think Martin is wrong about not upstreaming stuff from LDC 
into DMD. Nothing good will come of them diverging (which they 
already have).


The UX of having multiple compilers is already terrible — 
conservatively let's estimate that "oh you need to download LDC 
if you want a compiler with an optimizer that works to a modern 
standard" halves the number of people bothering to try D.


Every little detail that you have to think about other than 
actually writing code hurts D both in terms of adoption and 
massive fragmentation of the projects people have to contribute 
to.



Standardising proper hooks such that LDC doesn't have to use a 
fork of the frontend (it's not really dmd-as-a-library in any 
sense that would be tolerated for a smaller project) is also 
important dogfooding for the frontend as a codebase.

Re: D Language Foundation August 2023 Monthly Meeting Summary

[max haughton via Digitalmars-d-announce]

On Tuesday, 22 August 2023 at 12:59:12 UTC, Mike Parker wrote:


### Robert
Robert said he was happy. Dennis asked if the compiler was fast 
enough (as regular readers of these summaries may know, Robert 
often says the compiler is too slow). Robert said it's still 
slow. He just wanted to see LSP support in the compiler and 
take all the good things.


Walter noted he'd been working on improving compilation speeds. 
He'd realized that the compiler was being compiled with 
exceptions, so he'd been working on making it compile without 
exceptions to see what effect that had on speed. It might be a 
small difference, but every little difference helps.


Follow the memory. I don't think the exceptions will make any 
difference at all. The compiler allocates soo much 
unnecessary memory and lays out what it does use very badly. 
This, and doing less work, is to way to make an algorithm whose 
complexity you can't change faster. I have recently started using 
a tool called bytehound which can show you some nice metrics from 
allocations via LD_PRELOAD-ing a magic .so rather than emulation 
or recompilation, we should generate (I will do this during dconf 
perhaps) reports at CI time to find hotspots where possible.


Using some kind of copy-on-write would be interesting because the 
compiler preemptively allocates a lot during semantic analysis.


Also please check that using the new -nothrow doesn't break the 
ICE error messages and so on when its enabled for the compiler.


Adam said his library compiled in half a second. Robert said 
that was still too slow. His work project didn't compile in 
half a second. He said his goal was that by the time of the 
key-up event after pressing 'Enter' on Ninja or whatever build 
tool/compiler he's using, it should have already restarted the 
application. Átila agreed that half a second was too long.


Adam brought up D1. An old game he wrote back in 2007 compiles 
and links in 10 milliseconds. If you looked at a big chunk of 
the difference between D1 and D2, `object.d` back then was 
around 600 lines. Now it was much bigger, and that adds up. 
Walter said that he was a bit upset with the state of 
`object.d`. It was supposed to be a minimal thing and had 
turned into a kind of garbage dump somewhere along the way.


A lot of this time is actually just linking druntime (approx 2/3 
of the ~.3s on my machine), for the record, rather than literally 
object.d being compiled.



### Steve
Steve said that Dennis had been doing a fantastic job with his 
PR on the compiler part of static associative array 
initialization. Steve thought it was about ready to go if 
someone could push the button. He didn't want to be the one to 
push it, because he didn't know the compiler code very well and 
couldn't vouch for its correctness. ([The PR is still 
open](https://github.com/dlang/dmd/pull/15468) as I write.)


### Dennis
Dennis said he'd been working on that AA PR, but had nothing 
else to report. He still had some other things to pursue, like 
looking at pattern support for the deprecation (-d/-de/-dw) and 
obsolete warning (-wo) switches, as well as the `standalone` 
attribute or pragma for static constructors.


([In our July 
monthly](https://forum.dlang.org/thread/amsduzcnbgvptaxjt...@forum.dlang.org), Adam proposed a means to annotate static constructors that could make them independent of cycle detection. [In a subsequent planning session](https://forum.dlang.org/thread/vccxtwaaxqxxjojgx...@forum.dlang.org), we agreed to implement it. Since the August meeting, [Dennis has submitted a PR](https://github.com/dlang/dmd/pull/15537) for the `@standalone` attribute, but in the PR discussion thread, Walter thinks it should be a pragma.)


### Martin
Martin said the bump to version 2.104 of the frontend went well 
on the LDC side and was quite painless.


Next, he had an interesting side note inspired by [a forum post 
he'd 
seen](https://forum.dlang.org/thread/ofbvqasfvxylbxxpw...@forum.dlang.org) about getting LDC to work on a 8-bit AVR platform. He'd looked into it and found it an interesting question in terms of whether and how we want to support architectures with pointer sizes less than 32 bits. Currently, the frontend has a hard-coded limit: `size_t` and `ptrdiff_t` are either 32 or 64 bits, nothing lower than that. It's a frontend check, and the definitions in DRuntime directly depend on the compiler's internal type because they use the `typeof` expression.


He had tried to make the frontend accept 16-bit and 8-bit 
`size_t` and `ptrdiff_t`, but doing that bumps up against the 
integer promotion rules. The promotion rules can work in some 
specific cases when using a smaller `int`, but when you have 
something like the length of a slice and do a little plus one 
or minus one, that's a problem. You need to cast it. So either 
we need to change dealing with the promotion rules in this 
regard, try to mimic C++ in this regard, or hopefully do 
something better. He said 

Re: D Language Foundation April 2023 Monthly Meeting Summary

[max haughton via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 12:47:59 UTC, Mike Parker wrote:


__CI failures__

Dennis started by saying that the CI was randomly failing 
again. He didn't have a Mac, so he'd been unable to chase down 
the problem. Random CI failures are a recurring problem. There 
are so many checks, and he doesn't know who created them or who 
knows exactly what the checks are doing. He wishes the tests 
had someone responsible for them who he could turn to when they 
fail.


Walter asked who had previously been in charge of the tests. 
Razvan said he didn't recall if one person was ever in charge 
of them. At some point, someone decided it was a good idea to 
have a particular test and it got added to the pipeline.


Dennis asked if we should only keep tests that have a 
maintainer. Martin and Mathias quickly rejected that. Martin 
said the tests are good. CI failures are usually caused by CI 
image bumps or a PR. CI image changes are a PITA for LDC's 
tests, and PR-related failures may not be easy to resolve, but 
failures are hardly ever the fault of a test. And there's never 
been any specific person responsible for any of DMD's CI 
systems. They just grew organically. Then someone who knew the 
details moved on and no one else knows them... it's a constant 
maintenance burden, but it's worth the effort.


There was a bit more discussion about the maintenance burden, 
after which I noted that this is the story of our ecosystem. 
We're responsible now for things none of us set up, and we need 
to get a handle on it all. Dennis agreed and added that the CI 
is in a special position. When one of them is outdated, it 
doesn't just sit there out of the way, it becomes an annoyance 
to development.


(NOTE: This is one of the many aspects of our ecosystem that 
we'll be working to improve [under our new 
workflow](https://forum.dlang.org/thread/avvmlvjmvdniwwxem...@forum.dlang.org).)




Some thoughts on testing:

1. This (MacOS) failure has been fixed (by me). It apparently 
also occurred with some other LibCs out there prior to that too. 
In future these kinds of failures must be prioritized a little 
more aggressively, this didn't just mean "Oh well, we'll ignore 
that pipeline for a while", it meant that Phobos effectively 
didn't work on MacOS (Oops).


2. At a bigger scale: We probably have too many CI pipelines. The 
main ones that I have
in mind that really could go are the OMF pipelines --- In OMF we 
have some ancient baggage which we don't need and shouldn't want 
to support anymore: [Microsoft barely mention OMF 
anymore](https://learn.microsoft.com/en-us/search/?terms=OMF=C%2B%2B), its not the default from dmd on 32bit windows anymore, and having it in the testsuite ties us to the
Digital Mars ecosystem for likely zero benefit (Would you, 
reader, use Digital Mars if you were building C code on Windows 
today?)


3. The testing process could also use some love in terms of 
exactly how they're setup. Does everything that should/could use 
the host compiler use that compiler? Although I think its partly 
his own doing in not exerting much control over the compiler 
codebase other than when others try to organize it, Walter is 
right that the test suite should ideally be segmented into tests 
ordered by some measure of the number of features they depend 
upon.


4. We should have either digger or something like digger (likely 
a shell script, shooting from the hip I think digger is a very 
good idea but too complicated, myself and others have all had it 
not work in mysterious ways) being checked on every PR to make 
sure its easy to reproduce.


5. Automatic bisect? When github issues are done this could be an 
interesting use of richer integration with the concept of an 
issue to make developers productive. When a bug report is filed 
it, finding the commit that caused the issue can and should be 
done by a bot.

Re: Beta 2.104.0

[max haughton via Digitalmars-d-announce]

On Wednesday, 10 May 2023 at 12:34:00 UTC, Steven Schveighoffer 
wrote:


This reminds me of an LDC bug fixed recently. I bet DMD suffers 
from a similar problem: 
https://github.com/ldc-developers/ldc/issues/3864


-Steve


`MACOSX_DEPLOYMENT_TARGET` fixed it for me recently when I was 
getting the "not aligned" problems with rosetta dmd on macos.

Re: DParserGen 0.1.0

[max haughton via Digitalmars-d-announce]

On Sunday, 7 May 2023 at 15:16:50 UTC, Tim wrote:
I am releasing DParserGen 0.1.0, which is a parser and lexer 
generator

for D. It supports LALR and GLR parsers.

The examples include grammars for D and C++. The D grammar uses 
LALR,
but also needs extensions like backtracking. For C++ a GLR 
parser is

used, so ambiguities result in special parse trees.

For more details see the repository:
https://github.com/tim-dlang/dparsergen

It can be used with dub:
https://code.dlang.org/packages/dparsergen


Which parts of the D grammar require backtracking?

Re: A New Era for the D Community

[max haughton via Digitalmars-d-announce]

On Wednesday, 3 May 2023 at 23:17:28 UTC, MissPiggy wrote:

On Wednesday, 3 May 2023 at 11:13:34 UTC, Mike Parker wrote:


Our enthusiasm is high, and we're ready to get going. I think 
you'll like where we're headed.


IVY may increase the probability of a particular outcome, but 
it cannot predict a particular outcome.



OK?
You simply cannot ever know the position and velocity of every 
atom in the universe.


Luckily some very clever physicists have worked out that this 
task is a fools errand and instead one *can* model the 
interesting large scale dynamics of the system extremely well 
(until you can't, but still).


You're going to hear more about IVY as time goes by, and 
eventually,
we're going to start employing it more broadly in the 
community.


Whether you can in fact 'deploy' IVY into the 'broader 
community'... well..that remains to be seen.


It's more likely, I think, that D's 'future' will be 
increasingly determined by the priorities of a select group of 
corporations, rather than any psychological/behavioural science.


Ignoring that this statement doesn't make any sense (IVY is but a 
tool):


Let's not bother then eh — I'm sure Mike, who is the main liaison 
between these groups, hasn't put any thought into this.

Re: D Language Foundation April 2023 Quarterly Meeting Summary

[max haughton via Digitalmars-d-announce]

On Friday, 28 April 2023 at 14:29:47 UTC, Mike Parker wrote:
The D Language Foundation's second quarterly meeting for 2023 
took place on April 7 at 14:00 UTC. It lasted just over an 
hour. This was the first "standalone" quarterly meeting, where 
the foundation's monthly discussion was split into a separate 
meeting the following week.


[...]



Two notes:

1. The conversation about formatters is not quite on the money 
wrt internals, sdfmt doesn't work as written. I will write 
something explaining the two both architecturally (politically 
really for the purposes of this debate) and also which I think is 
better.


2. -ftime-trace has been around for a while now. It's very good.
dmd will have it at some point (PRs already there for a good 
chunk of it's implementation). I will have time to pick it up 
again in June.

Re: DIP1044---"Enum Type Inference"---Formal Assessment

[max haughton via Digitalmars-d-announce]

On Wednesday, 26 April 2023 at 13:08:22 UTC, Jacob Shtokolov 
wrote:

On Wednesday, 26 April 2023 at 12:50:32 UTC, bachmeier wrote:
Many other solutions were provided as well, including but not 
limited to


- Using shorter names
- Using alias
- Using an IDE with autocomplete
- Using copy and paste


While aliases and shorter names are always good options, 
autocomplete and copy/paste really aren't as the end user of 
the code is either yourself or another developer, so reading 
the mess produced with copy/paste makes life much more 
miserable :)


I wish the `with()` operator would also be an expression, so 
you could do something like:


```d
auto f = with(Flags) A | B | C |D;
```

But that breaks backwards compatibility ¯\_(ツ)_/¯


https://github.com/dlang/dmd/pull/13776

Re: DIP1044---"Enum Type Inference"---Formal Assessment

[max haughton via Digitalmars-d-announce]

On Wednesday, 26 April 2023 at 01:26:03 UTC, Walter Bright wrote:

On 4/25/2023 4:12 PM, max haughton wrote:
I have never been in favour of D having bitfields. This isn't 
worth breaking stuff for.


D bitfields didn't break anything. Also, it exposed an 
overlooked bug in the ImportC bitfields.


I forgot to add a  paragraph ("this" was meant to refer to the 
enum changes), but any change to the grammar can break formatters 
and autocomplete engines and so on - good formatters shouldn't 
use an AST so bitfields in particular might have been OK but the 
point stands in general.


At the moment ldc currently doesn't have bitfields so D basically 
doesn't have them as a serious feature.

Re: DIP1044---"Enum Type Inference"---Formal Assessment

[max haughton via Digitalmars-d-announce]

On Tuesday, 25 April 2023 at 22:39:35 UTC, ryuukk_ wrote:

On Tuesday, 25 April 2023 at 20:59:23 UTC, max haughton wrote:

On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:

On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote:

[...]


Why you guys focus on "switch"


Because that's the example given by Mike...

Who doesn't love writing other than Walter Bright:

[...]


Who are you saying said it's too hard to implement? Also 
consider that *any* change breaks all the tooling.



It's in the 2nd paragraph

But not my paragraph?



Oh, now you care about the tooling? I was the only one who 
raised awareness about the new features landing but tooling was 
ignored all while i was getting ignored (importC // dub) 
(bitfields // dcd), how funny


I have never been in favour of D having bitfields. This isn't 
worth breaking stuff for.


You also aren't the only one...


ImportC will save everything, i now understand


You're either writing past me or ascribing ideas to me that I 
haven't said.


It may be of note that I don't work for DLF anymore

Re: DIP1044---"Enum Type Inference"---Formal Assessment

[max haughton via Digitalmars-d-announce]

On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:

On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote:

[...]


Why you guys focus on "switch"


Because that's the example given by Mike...

Who doesn't love writing other than Walter Bright:

[...]


Who are you saying said it's too hard to implement? Also consider 
that *any* change breaks all the tooling.

Re: DIP1044---"Enum Type Inference"---Formal Assessment

[max haughton via Digitalmars-d-announce]

On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:

Firstly I think this is the correct decision, certainly for now, 
probably forever.


Regarding enums in switch statements, Walter suggested we could 
shorten the `with final switch` syntax such that the `with` is 
implicitly applied to the type of the switch variable:


```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```

Alternatively, we could make the `with` implicit for case 
statements, but that would break existing code.


What we have at the moment with `with` is, I think perfectly fine.
The `switch(...) with(...)` pattern is used rather a lot in the 
SDC codebase

for example and I think it's very readable.

On the topic of `with` I do think, and have even implemented ;), 
with expressions do need to happen eventually. The with statement 
is a little heavy handed for places where these kinds of 
shorthands are needed locally.

Re: Objective-C D metal binding

[max haughton via Digitalmars-d-announce]

On Saturday, 11 March 2023 at 13:08:49 UTC, Steven Schveighoffer 
wrote:

On 3/10/23 4:10 PM, ryuukk_ wrote:

On Friday, 10 March 2023 at 20:53:23 UTC, Hipreme wrote:
Hello guys. I have been working for some time into binding 
Metal to D.
This has been quite an interesting journey and today I've 
reached a point where it is usable.
It is far from complete, but I included a lot of comments 
from Apple's documentation, and also have tested and got an 
entire Metal hello world working in D.


The API I worked on is really nice, I manually put the 
opIndex, opIndexAssign, wrapped Objective C Runtime Arrays to 
a strongly typed array in D. The main point into this binding 
is getting Metal to run on Hipreme Engine, so, I don't plan 
into supporting what I don't use. That said, I still welcome 
any contribution to make this a standard way to program using 
Apple's Metal.


I'll put an example folder the moment I get a dub fix for 
macOS.


![Metal MacOS D Hello 
World](https://user-images.githubusercontent.com/10136262/224425800-e417414e-b6be-4e92-93b4-9087b1b281a2.png)


https://code.dlang.org/packages/d-metal-binding


Congrats!

But metal obj-c? do you mean DMD support only? so no Apple 
Silicon (intel only)?


I don't think Intel stuff on mac ecosystem will be a thing for 
too long, PPC era already vanished from history


There is the official C++ headers that you can use to make 
things easier


https://developer.apple.com/metal/cpp/


From that page:

 No measurable overhead compared to calling Metal 
Objective-C headers, due to inlining of C++ function calls.


D will not inline C++ function calls. So there will be overhead.


If you are able to use LTO then they'll be inlined. This may be 
slightly easier said that done for some build targets because 
apple's "clang" is actually a closed source fork so it's not 
impossible that there is LLVM incompatibility in there somewhere.


In the absence of evidence suggesting otherwise, the overhead of 
an additional function call is probably quite small relative to 
the metal part of the function call (especially if that Metal 
call ends up waiting on the GPU for something).


I'm now curious if there are I$ optimizations specifically for 
chasing function calls like this.

Re: SLF4D - A proposal for a common logging interface for Dub projects

[max haughton via Digitalmars-d-announce]

On Saturday, 25 February 2023 at 07:52:09 UTC, Andrew wrote:

[...]


On the contrary I would argue that it's much easier (not 
necessarily better) to provide extensibility using classes. 
Nobody ever got fired for writing a class, as the saying goes.

Re: Release D 2.101.0

[Max Haughton via Digitalmars-d-announce]

On Tuesday, 27 December 2022 at 17:59:11 UTC, Les De Ridder wrote:

On Wednesday, 16 November 2022 at 01:13:29 UTC, torhu wrote:
On Tuesday, 15 November 2022 at 20:54:03 UTC, Iain Buclaw 
wrote:

Glad to announce D 2.101.0, ♥ to the 63 contributors.


For some reason my project build fails with this version, but 
only the x86 release build. Only tried it on Windows.


This is the error, I'll post a bug report if I can narrow it 
down more:
Error C:\prog\dmd\windows\bin\dmd.exe failed with exit code 
-1073741795.


This seems to still be broken in 2.101.1 and is breaking my CI:
.


I'm happy to do some debugging if you can get us a reduced test 
case. If you need help getting a reduction do ask (e.g. for help 
with dustmite)

Re: Release D 2.101.0

[max haughton via Digitalmars-d-announce]

On Saturday, 3 December 2022 at 19:17:59 UTC, zoujiaqing wrote:

Thank you!!!

When will it support Apple M1 processors?

My macbook has been unable to use D for months.

LDC (and maybe even GCC) both work

Re: D demangler for C++

[max haughton via Digitalmars-d-announce]

On Monday, 28 November 2022 at 16:16:43 UTC, Witold Baryluk wrote:

On Monday, 28 November 2022 at 12:48:15 UTC, max haughton wrote:

[...]


`libiberty` has way more things than just D demangler. And some 
projects might not be comfortable with its licensing. And 
libiberty uses autoconf / automake, which is just gross for 
most people.


The idea is to have something simpler, portable (zero conf), 
just for this task, so it is as easy as possible to integrate 
and have flexible licensing.


Many of the tools do not use libiberty, but just call 
`abi::__cxa_demangle` for example. Take a look for for a 
heaptrack tool: 
https://github.com/KDE/heaptrack/blob/master/src/interpret/heaptrack_interpret.cpp#L40-L56


You are free to use `libiberty` if you want.

My demangler is just another option.


This demangler I think is already available under a different 
licence inside LLVM (I think). My point was mainly to make sure 
you knew it existed.

Re: D demangler for C++

[max haughton via Digitalmars-d-announce]

On Sunday, 27 November 2022 at 23:12:35 UTC, Witold Baryluk wrote:

https://github.com/baryluk/d-demangle-cpp

D programming language (dlang) symbol name demangler for C++

[...]


Wouldn't some of those tools already have one via libiberty?

https://github.com/gcc-mirror/gcc/blob/master/libiberty/d-demangle.c

Re: Giving up

[max haughton via Digitalmars-d-announce]

On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote:

Hi,

Sincerely I am tired to maintain my library with every change 
made by D compiler. Mostly regressions. Bug reports are ignored 
or challenged, I don't have time to argue.


[...]


This is not the correct syntax for real literals. We can improve 
the error message but this is not new behaviour.

Druntime merged into dmd repo

[max haughton via Digitalmars-d-announce]

Say thank you to Iain, Mathias, Vladimir, and Martin.

This will make D better. More details to come.

D Game dev on the hackernews frontpage

[max haughton via Digitalmars-d-announce]

https://news.ycombinator.com/item?id=31725028

Re: D Language Foundation May 2022 Monthly Meeting Summary

[max haughton via Digitalmars-d-announce]

On Monday, 6 June 2022 at 08:44:32 UTC, Mike Parker wrote:
The monthly meeting for May 2022, took place on May 6th at 
14:00 UTC. The meeting lasted a little under an hour. The 
following people attended:


[...]


Note that Razvan's PR fixes the issue with synchronized by 
turning the check off rather than fixing the assumption inside 
the compiler. It still breaks LDC atomics for example.

Re: LDC 1.30.0-beta1

[max haughton via Digitalmars-d-announce]

On Sunday, 22 May 2022 at 15:34:03 UTC, zoujiaqing wrote:

On Monday, 16 May 2022 at 18:31:47 UTC, kinke wrote:

[...]


LDC is too powerful!

Waiting arm64 version on apple M1 ;)


It's there in the list and also available via brew.

Re: GCC 12.1 Released (D v2.100-rc.1)

[max haughton via Digitalmars-d-announce]

On Saturday, 7 May 2022 at 20:14:51 UTC, Witold Baryluk wrote:

On Friday, 6 May 2022 at 11:57:47 UTC, Iain Buclaw wrote:

Hi,

I am proud to announce another major GCC release, 12.1.



Thank you so much Ian on your hard and dedicated work on GDC. 
It is my goto default compiler for D on Debian Linux. (I use 
ldc and sometimes dmd sporadically, but only for testing 
compatibility).


Glad to have newer GCC backend, frontend up to date with DMD, 
all the Phobos work, and various architectures supports landing!


Update the compilers on the GDC compiler explorer site to 
version 12, and other continued maintenance on the testing 
infrastructure, the costs of which are now covered by the kind 
sponsors of GDC. If you are interested in helping support the 
on-going development of GDC, you can do so by making a 
donation to the D Language Foundation.


Good you mentioned that! I was not aware of the sponsorship 
program, and now that I know, I gladly will chip in (well, just 
did it moments ago). For testing infrastructure, I would 
suggest tracking compilation speed and memory usage and output 
binary size of GDC on amd64 and aarch64 at least (to detect 
compiler getting slower, or due to growth of Phobos / 
druntime), and having a public website showing this data. 
Something like this maybe https://fast.vlang.io/



Cheers.


I'm planning on getting something like this set up for the 
frontend but its not the easiest thing to do on cheap cloud 
instances.


Hypothetically we could use something like callgrind to measure 
raw instruction counts but this becomes more and more synthetic 
the more data you collect.

Re: GCC 12.1 Released (D v2.100-rc.1)

[max haughton via Digitalmars-d-announce]

On Friday, 6 May 2022 at 13:27:40 UTC, Steven Schveighoffer wrote:

On 5/6/22 7:57 AM, Iain Buclaw wrote:

[...]


Amazing, congrats! I'll have to try out gdc now that it might 
be able to build my stuff ;)


-Steve


https://github.com/Homebrew/homebrew-core/blob/31e2ed54e34225db270b13228036009d427e8056/Formula/gcc.rb#L79

Re: GCC 12.1 Released (D v2.100-rc.1)

[max haughton via Digitalmars-d-announce]

On Friday, 6 May 2022 at 13:27:40 UTC, Steven Schveighoffer wrote:

On 5/6/22 7:57 AM, Iain Buclaw wrote:

[...]


Amazing, congrats! I'll have to try out gdc now that it might 
be able to build my stuff ;)


-Steve


The brew version of GCC has D disabled for non-x86 targets. It 
might just be a flip of a switch to enable but could he a wild 
west in terms of some library features (if the latter I still 
vote for trying to enable it as long as hello world works)

Re: DConf 2022 in London?

[max haughton via Digitalmars-d-announce]

On Tuesday, 15 February 2022 at 12:22:05 UTC, Mike Parker wrote:
Yes! Thanks to Symmetry Investments, DConf 2022 is happening in 
London Aug 1-4. I'll have the web site up soon (waiting to make 
sure there's no issue with our logo), but I wanted to get the 
news out ASAP since I have permission now to announce it.


[...]


Bit too far north for me

(See you all there).

Re: Beta 2.099.0

[max haughton via Digitalmars-d-announce]

On Wednesday, 16 February 2022 at 05:53:25 UTC, forkit wrote:
On Wednesday, 16 February 2022 at 04:14:01 UTC, max haughton 
wrote:

On Wednesday, 16 February 2022 at 01:38:08 UTC, forkit wrote:
On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak 
wrote:




I was so hoping I could now begin using -betterC on Windows...

but no .. :-(

i.e. stdout, stdin, stderr ...still cannot link...


Can you not define them yourself in the meantime?


err.. howdy doody dat?


You have the source code to druntime, can't you just copy the 
definitions you want

Re: Beta 2.099.0

[max haughton via Digitalmars-d-announce]

On Wednesday, 16 February 2022 at 01:38:08 UTC, forkit wrote:
On Tuesday, 15 February 2022 at 13:06:47 UTC, Martin Nowak 
wrote:




I was so hoping I could now begin using -betterC on Windows...

but no .. :-(

i.e. stdout, stdin, stderr ...still cannot link...


Can you not define them yourself in the meantime?

Re: From the D Blog: The Binary Language of Moisture Vaporators

[max haughton via Digitalmars-d-announce]

On Monday, 24 January 2022 at 22:59:18 UTC, Adam Ruppe wrote:

On Monday, 24 January 2022 at 22:45:14 UTC, Ali Çehreli wrote:
I am not aware of any association between "alpha" and "man" 
because I hear both "alpha male" and "alpha female" in e.g. 
nature documentaries.


It isn't really accurate in nature either and when used with 
people it tends to be exaggerated to the point of being totally 
absurd.


https://davemech.org/wolf-news-and-information/

Re: On the D Blog: Using the GCC Static Analyzer on the D Programming Language

[max haughton via Digitalmars-d-announce]

On Friday, 14 January 2022 at 20:25:22 UTC, Dukc wrote:

On Friday, 14 January 2022 at 13:37:11 UTC, Mike Parker wrote:

The Blog:
https://dlang.org/blog/2022/01/14/using-the-gcc-static-analyzer-on-the-d-programming-language/

Reddit:
https://www.reddit.com/r/programming/comments/s3sh9p/using_the_gcc_static_analyzer_on_the_d/


Wow, it looks like the analyzer is easy to use! If bloated in 
it's error messages.


Better bloated than bad IMO. You'll notice that the GCC 
__backend__ can literally do a nicer error message than the D 
frontend. We should really have these for DIP1000, but the 
analysis just kind of happens as the compiler sees the code so 
doing these top-down views is quite hard.

Re: DMD now incorporates a disassembler

[max haughton via Digitalmars-d-announce]

On Friday, 7 January 2022 at 23:14:54 UTC, Dukc wrote:

On Friday, 7 January 2022 at 21:41:55 UTC, Walter Bright wrote:

Compile with -vasm to see it! Enjoy!

For the file test.d:

  int demo(int x)
  {
return x * x;
  }

Compiling with:

  dmd test.d -c -vasm

prints:

  _D4test4demoFiZi:
  :   89 F8   mov EAX,EDI
  0002:   0F AF C0imulEAX,EAX
  0005:   C3  ret


https://github.com/dlang/dmd/pull/13447


Wow, very useful! This feature surely lowers the bar to check 
the disassembly when optimising. Thanks!


I'm slightly disappointed it does not output the asm inlined to 
D code but that's just my daydreaming with no practical reasons 
to back it up.


https://stackoverflow.com/questions/2511018/how-does-objdump-manage-to-display-source-code-with-the-s-option

Enjoy

Re: DMD now incorporates a disassembler

[max haughton via Digitalmars-d-announce]

On Sunday, 9 January 2022 at 02:58:43 UTC, Walter Bright wrote:


I've never seen one. What's the switch for gcc to do the same 
thing?




For GCC/Clang you'd want -S (and then -masm=intel to make the 
output ~~beautiful to nobody but the blind~~ readable). This 
dumps the output to a file, which isn't exactly the same as what 
-vasm does, but I have already begun piping the -vasm output to a 
file since (say) hello world yields a thousand lines of output 
which is much easier to consume in a text editor.


To do it with ldc the flag is `--output-s`. I have opened a PR to 
make the ldc dmd-compatibility wrapper (`ldmd2`) mimic -vasm


Intel (and to a lesser extent Clang) actually annotate the 
generated text with annotations intended to be read by the humans.


e.g.

Intel C++ (which is in the process of being replaced with Clang 
relabeled as Intel C++) prints it's (hopeless unless you are 
using PGO, but still) estimates of the branch probabilities.

```

test  al, al#5.8
je..B1.4# Prob 22%  #5.8
# LOE rbx rbp r12 r13 r14 r15
# Execution count [7.80e-01]
```

You can also ask the compiler to generate an optimization report 
inline with the assembly code. This *is* useful when tuning since 
you can tell what the compiler is or isn't getting right (e.g. 
find which roads to force the loop unrolling down). The Intel 
Compiler also has a reputation for having an arsenal of dirty 
tricks to make your code "faster" which it will deploy on the 
hope that you (say) don't notice that your floating point numbers 
are now less precise.


`-qopt-report-phase=vec` yields:
```
# optimization report
# LOOP WITH UNSIGNED INDUCTION VARIABLE
# LOOP WAS VECTORIZED
# REMAINDER LOOP FOR VECTORIZATION
# MASKED VECTORIZATION
# VECTORIZATION HAS UNALIGNED MEMORY REFERENCES
# VECTORIZATION SPEEDUP COEFFECIENT 3.554688
# VECTOR TRIP COUNT IS ESTIMATED CONSTANT
# VECTOR LENGTH 16
# NORMALIZED VECTORIZATION OVERHEAD 0.687500
# MAIN VECTOR TYPE: 32-bits integer
vpcmpuq   k1, zmm16, zmm18, 6   #5.5
vpcmpuq   k0, zmm16, zmm17, 6   #5.5
vpaddqzmm18, zmm18, zmm19   #5.5
vpaddqzmm17, zmm17, zmm19   #5.5
kunpckbw  k2, k0, k1#5.5
vmovdqu32 zmm20{k2}{z}, ZMMWORD PTR [rcx+r8*4]  #7.9
vpxordzmm21{k2}{z}, zmm20, ZMMWORD PTR [rax+r8*4]   #7.9
vmovdqu32 ZMMWORD PTR [rcx+r8*4]{k2}, zmm21 #7.9
add   r8, 16#5.5
cmp   r8, rdx   #5.5
jb..B1.15   # Prob 82%  #5.5
```

People don't seem to care about SPEC numbers too much anymore, 
but the Intel Compilers still have many features for gaming 
standard test scores.


http://www.spec.org/cpu2006/results/res2007q3/cpu2006-20070821-01880.html If 
you looked at this, you'd think that Intel just managed a huge increase on 
`libquantum` which we can all use on our own code, but it turns out they worked 
out they can just tell the compiler to automagically parallelize the code, but 
still only have 1 nominal process.

https://stackoverflow.com/questions/61016358/why-can-gcc-only-do-loop-interchange-optimization-when-the-int-size-is-a-compile
 for more overfitting.

Compilers that take a detour through an assembler to generate 
code are inherently slower.


Certainly, although in my experience not by much. Time spent in 
the assembler in dominated by time spent in the linker, and just 
about everywhere else in the compiler (especially when you turn 
optimizations on). Hello World is about 4ms in the assembler on 
my machine.


GCC and Clang have very different architectures in this regard 
but end up being pretty similar in terms of compile times. The 
linker an exception to that rule of thumb, however, in that the 
LLVM linker is much faster than any current GNU offering.


It doesn't have a distinct IR like LLVM does but the final 
stage of the RTL is basically a 1:1 representation of the 
instruction set:


That looks like intermediate code, not assembler.


It is the (final) intermediate code, but it's barely intermediate 
at this stage i.e. these are effectively just the target 
instructions printed with LISP syntax.


It's, helpfully, quite obfuscated unfortunately: Some of that is 
technical baggage, some of it is due to the way that GCC was 
explicitly directed to be difficult to consume).


I'm __not__ suggesting any normal programmer should use, just 
showing what GCC does since I mentioned LLVM.




Anyway, I've been playing with -vasm and I think it seems pretty 
good so far. There are some formatting issues which shouldn't be 
hard to fix at all (this is why we asked for some basic tests of 
the shape of the 

Re: DMD now incorporates a disassembler

[max haughton via Digitalmars-d-announce]

On Saturday, 8 January 2022 at 18:47:11 UTC, Vladimir Marchevsky 
wrote:

On Friday, 7 January 2022 at 21:41:55 UTC, Walter Bright wrote:

Compile with -vasm to see it! Enjoy!


Any practical reason to put disassembler into compiler instead 
of making it a separate tool?  Any ETA for renaming it into DMD 
Burning ROM? :)


Most other compilers have been able to do this for years. The 
only difference is that the way the dmd backend is designed 
basically means that it never knows the instructions in a given 
basic block until they are actually emitted, so it has to 
disassemble it's own output rather than printing it's internal 
representation with (say) Intel assembly syntax.


See https://llvm.org/doxygen/classllvm_1_1MachineInstr.html from 
LLVM


GCC actually *only* uses an assembler to build object files. It 
doesn't have a distinct IR like LLVM does but the final stage of 
the RTL is basically a 1:1 representation of the instruction set:


```d
void phoneHome(size_t);
auto getLen(int[] arr)
{
phoneHome(arr.length);
return arr.length;
}
```
ends up as
```
;; Function getLen (_D7example6getLenFAiZm, funcdef_no=0, 
decl_uid=1395, cgraph_uid=2, symbol_order=1)


(note 1 0 37 NOTE_INSN_DELETED)
(note 37 1 8 (var_location arr (parallel [
(expr_list:REG_DEP_TRUE (reg:DI 5 di [ arr ])
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:DI 4 si [ arr+8 ])
(const_int 8 [0x8]))
])) NOTE_INSN_VAR_LOCATION)
(note 8 37 7 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 7 8 26 2 NOTE_INSN_FUNCTION_BEG)
(insn/f:TI 26 7 27 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 
 S8 A8])

(reg:DI 3 bx)) "/app/example.d":2:6 54 {*pushdi2_rex64}
 (expr_list:REG_DEAD (reg:DI 3 bx)
(nil)))
(note 27 26 2 2 NOTE_INSN_PROLOGUE_END)
(insn 2 27 38 2 (set (reg:DI 3 bx [orig:85 arr ] [85])
(reg:DI 5 di [92])) "/app/example.d":2:6 80 
{*movdi_internal}

 (nil))
(note 38 2 13 2 (var_location arr (reg:TI 3 bx [orig:85 arr ] 
[85])) NOTE_INSN_VAR_LOCATION)
(call_insn:TI 13 38 39 2 (call (mem:QI (symbol_ref:DI 
("_D7example9phoneHomeFmZv") [flags 0x41]  0x7f491d317600 phoneHome>) [0 phoneHome S1 A8])

(const_int 0 [0])) "/app/example.d":4:14 886 {*call}
 (expr_list:REG_CALL_ARG_LOCATION (nil)
(expr_list:REG_DEAD (reg:DI 5 di)
(expr_list:REG_CALL_DECL (symbol_ref:DI 
("_D7example9phoneHomeFmZv") [flags 0x41]  0x7f491d317600 phoneHome>)

(nil
(expr_list:DI (use (reg:DI 5 di))
(nil)))
(note/c 39 13 17 2 (var_location arr (nil)) 
NOTE_INSN_VAR_LOCATION)

(insn 17 39 36 2 (set (reg/i:DI 0 ax)
(reg:DI 3 bx [orig:85 arr ] [85])) "/app/example.d":6:1 
80 {*movdi_internal}

 (expr_list:REG_DEAD (reg:DI 3 bx [orig:85 arr ] [85])
(nil)))
(note 36 17 29 2 NOTE_INSN_EPILOGUE_BEG)
(insn/f 29 36 40 2 (set (reg:DI 3 bx)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0  S8 A8])) 
"/app/example.d":6:1 62 {*popdi1}

 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])))
(nil)))
(note 40 29 18 2 (var_location arr (nil) [uninit]) 
NOTE_INSN_VAR_LOCATION)

(insn 18 40 30 2 (use (reg/i:DI 0 ax)) "/app/example.d":6:1 -1
 (nil))
(jump_insn:TI 30 18 33 2 (simple_return) "/app/example.d":6:1 910 
{simple_return_internal}

 (nil)
 -> simple_return)
(barrier 33 30 25)
(note 25 33 0 NOTE_INSN_DELETED)
```
just prior to spitting it out for the assembler to process.

Re: DMD now incorporates a disassembler

[max haughton via Digitalmars-d-announce]

On Saturday, 8 January 2022 at 18:08:27 UTC, Steven Schveighoffer 
wrote:

On 1/8/22 12:23 PM, jmh530 wrote:

On Friday, 7 January 2022 at 21:41:55 UTC, Walter Bright wrote:

Compile with -vasm to see it! Enjoy!

[snip]


Would make a nice project for someone to integrate this into 
run.dlang.org


Isn't there already an ASM button?

-Steve


Yup.

Re: Time to setup D's wallet

[max haughton via Digitalmars-d-announce]

On Tuesday, 9 November 2021 at 17:29:37 UTC, Rumbu wrote:

Nim received a nice donation :)

https://nim-lang.org/blog/2021/10/25/nim-receives-100k-usd-bitcoin.html

You never know when it happens.


Any one wanting to donate to the D Programming Language can do so 
via the links provided on dlang.org - as far as I'm aware 
OpenCollective supports donations via Cryptocurrency.

Re: Beta 2.098.0

[max haughton via Digitalmars-d-announce]

On Wednesday, 20 October 2021 at 01:48:24 UTC, Walter Bright 
wrote:

On 10/19/2021 6:35 AM, Timon Gehr wrote:
I think @live is a dead end and any further work on it is 
probably wasted unless the code is reusable for some other 
feature. Ownership is a property of values, not of functions 
operating on those values. In particular, prioritizing ImportC 
over @live is the right call. ImportC is high-impact and 
Walter has a lot of relevant expertise.


Timon and I famously disagree over the concept behind @live.

Nevertheless, we do agree that ImportC is more important.

Iain and I have decided that changing the build process so that 
Phobos' zlib code is built with dmd rather than gcc is going to 
be our goalpost for declaring ImportC ready to use.


Why is compiling zlib a goalpost for *Import*C? Hopefully that 
doesn't make it "finished, because that goalpost has almost  no 
effect on the issues actually plaguing C interop at the moment - 
i.e. the preprocessor.

Re: Beta 2.098.0

[max haughton via Digitalmars-d-announce]

On Sunday, 17 October 2021 at 17:55:05 UTC, Adam D Ruppe wrote:
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?


I think this is actually an issue with process rather than 
technology.


The ideal way to do bindings, in my opinion, is to rigorous lock 
in to / check-in a certain header file, then generate the 
bindings at build time. ImportC might make that less of a hassle 
but fundamentally I think the abstraction wrong at the moment.

Re: DMD Frontend working in WebAssembly

[max haughton via Digitalmars-d-announce]

On Friday, 15 October 2021 at 21:58:29 UTC, Paul Backus wrote:

On Friday, 15 October 2021 at 15:19:26 UTC, Imperatorn wrote:


Btw, why is dmd a memory hog?


Because it doesn't free memory. It just allocates, and relies 
on the OS to clean up at process exit.


See https://www.digitalmars.com/articles/b87.html


lowmem actually isn't much better sometimes. There are issues 
with references being held and confusing the GC, also.


You can see this, if you use either massif or enable the GC. The 
peak heap collapses but at not much expense in runtime. Sometimes 
however, the GC makes no difference - I noticed this when 
benchmarking AliasAssign, you'd expect the old assigned-to memory 
to be freed but this doesn't seem to be the case empirically.

Re: Beta 2.098.0

[max haughton via Digitalmars-d-announce]

On Monday, 11 October 2021 at 01:08:30 UTC, Paul Backus wrote:

On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote:

On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote:


Meanwhile @live is in the language, and it's half-baked. Then 
there's preview switches that will linger on into perpetuity; 
DIPs' implementations that haven't been finished.


And Walter has prioritized this issue over those. No matter 
what he works on, people will moan that he isn’t working on 
something else. Maybe we should clone him.


Perhaps worth asking why Walter, specifically, is required to 
work on @live in order for it to make progress. Is it just 
because no one else is willing to step up to the plate, or is 
he the only person qualified/capable enough?


FWIW The code isn't great. Maybe I'll have another crack at it 
some day but it wasn't very well structured compared to similar 
efforts I have seen (e.g. 
https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10 's implementation)

Re: DConf Online 2021 Schedule Published

[max haughton via Digitalmars-d-announce]

On Saturday, 9 October 2021 at 01:30:17 UTC, Mike Parker wrote:

On Friday, 8 October 2021 at 17:16:36 UTC, ezneh wrote:



I saw an issue in the text on the page on Stefan's talk 
description:

"But is their a better way?" -> there


Fixed.



Also, what about having a reference to the DConf on dlang.org 
front page?


Max submitted a PR for that.

Thanks!


Now live

Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)

[max haughton via Digitalmars-d-announce]

On Saturday, 2 October 2021 at 08:48:10 UTC, Konstantin wrote:

On Friday, 1 October 2021 at 23:53:46 UTC, max haughton wrote:

On Friday, 1 October 2021 at 21:48:23 UTC, Konstantin wrote:

On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote:

Attendees:

Andrei Alexandrescu
Walter Bright
Iain Buclaw
Ali Çehreli
Max Haughton
Martin Kinkelin
Mathias Lang
Razvan Nitu
Mike Parker

[...]


Offtopic:
Are there any plans to publish the roadmap for the language 
and stdlib development on wiki or elsewhere?


Mike is editing it at the moment. It will probably go into the 
foundation Ddoc sources (Not a huge of the wiki since it's not 
tracked in git)


Thank you, Max! Do I understand correctly, that roadmap section 
will be available at https://dlang.org/foundation/index.html


Most likely, but we will get it on the home page as well so it 
can't be missed.

Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)

[max haughton via Digitalmars-d-announce]

On Friday, 1 October 2021 at 21:48:23 UTC, Konstantin wrote:

On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote:

Attendees:

Andrei Alexandrescu
Walter Bright
Iain Buclaw
Ali Çehreli
Max Haughton
Martin Kinkelin
Mathias Lang
Razvan Nitu
Mike Parker

[...]


Offtopic:
Are there any plans to publish the roadmap for the language and 
stdlib development on wiki or elsewhere?


Mike is editing it at the moment. It will probably go into the 
foundation Ddoc sources (Not a huge of the wiki since it's not 
tracked in git)

Re: Destroy All Memory Corruption

[Max Haughton via Digitalmars-d-announce]

On Thursday, 22 April 2021 at 16:15:14 UTC, Ali Çehreli wrote:

On 4/22/21 8:35 AM, angel wrote:

> MS Teams works fine on Linux.

I failed after spending 35 minutes for that. I ended up 
creating at least two accounts (even though I already had a 
Skype account, which sounded to be sufficient). Many special 
codes sent to my phone and email. The whole thing is badly 
designed and felt buggy.


In the end, contrary to how the download started for "my 
platform" (Linux Mint) it said at some point that MS Teams was 
not available for my platform. (There is an MS Teams program on 
my system which starts fine but thinks I am not signed in. (?)) 
So I decided to use it in the browser, which turned out not 
working with Firefox. Luckily I had Chrome and it worked.


> And I'm actually not sure you would need an MS account

It requires one. I could not find a way through their flow to 
use my existing Skype account.


Ali


Teams is indeed pretty bad. It should be an embarrassment for 
Microsoft (they know this, see the recent M+A news) and similar 
that discord - the app aimed really only at gamers - actually 
works and their serious business tools don't.

Re: Beerconf April 2021

[Max Haughton via Digitalmars-d-announce]

On Sunday, 11 April 2021 at 12:49:00 UTC, Steven Schveighoffer 
wrote:

# Beerconf!

In celebration of tax day being [moved to 
May](https://www.irs.gov/newsroom/tax-day-for-individuals-extended-to-may-17-treasury-irs-extend-filing-and-payment-deadline), we are going to instead honor D and beer (and any other beverage or topic you'd like to honor). But instead of doing it on the original tax day, April 15th, we will do it on April 24-25. Because, *reasons*.


[...]


Looking forward to it. I've even got a camera now

Re: D compiler daily downloads at an all-time high

[Max Haughton via Digitalmars-d-announce]

On Saturday, 20 March 2021 at 23:59:13 UTC, Imperatorn wrote:

https://forum.dlang.org/post/p60s23$7t4$1...@digitalmars.com

On Wednesday, 14 February 2018 at 08:29:55 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 02/13/2018 01:15 PM, Dmitry Olshansky wrote:
On Monday, 12 February 2018 at 15:20:29 UTC, Martin 
Tschierschke wrote:

[...]


When I see spikes like that out of nowhere that it’s usually 
some automation kicking in. Could it be a new CI that we 
didn’t account for yet?


Secretly hope it’s a fresh wave of D users though ;)


A totally botched DoS attempt? ;) I'll assume no ;)


Anyone got updated numbers?


I have the raw data, I'll make some plots when I have a reliable 
script going

Re: Release D 2.096.0

[Max Haughton via Digitalmars-d-announce]

On Sunday, 14 March 2021 at 18:25:51 UTC, starcanopy wrote:

On Sunday, 14 March 2021 at 05:31:27 UTC, Max Haughton wrote:

On Sunday, 14 March 2021 at 03:25:28 UTC, starcanopy wrote:

[...]


Correct. To be completely honest it shouldn't have ever been 
merged since there was no approval from WalTila and they steer 
the language.


Given your status as a member of the Foundation, is there a 
plan/track of sorts to convert such a DIP-less -preview feature 
to a full-fledged one? I know it's a lot of work to write an 
improvement proposal, and deliberation with the community is a 
seemingly tiring (but necessary) ordeal, but 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'm not sure. I will bring it up at the next foundation meeting.

Re: Release D 2.096.0

[Max Haughton via Digitalmars-d-announce]

On Sunday, 14 March 2021 at 03:25:28 UTC, starcanopy wrote:

On Saturday, 13 March 2021 at 21:33:20 UTC, Meta wrote:

On Saturday, 13 March 2021 at 21:15:40 UTC, Martin Nowak wrote:

[...]


Allow shortened function implementations for 
single-expresssion functions.
-preview=shortenedMethods is added. This allows functions to 
be written in a similar form to lambda functions:


// these 2 are equivalent
int foo() { return 1; }
int foo() => 1;
The syntax allows the form => expr to replace the function 
body { return expr; }


Amazing! I had no idea this got in. I love the syntax.


It's pretty neat, but a DIP has to be drafted and approved for 
it to be enabled by default, right? (Unless I missed it.)


Correct. To be completely honest it shouldn't have ever been 
merged since there was no approval from WalTila and they steer 
the language.

Re: Windows Bindings v1.1

[Max Haughton via Digitalmars-d-announce]

On Saturday, 20 February 2021 at 14:03:18 UTC, Rumbu wrote:



- updated to Windows SDK 10.19041.5
- wchar* constants with GUID patterns translated as GUID 
structures

- improved documentation
- strongly typed handles
- auto disposed handles
- new attributes (currently ignored): RetVal, 
NullNullTerminated, NotNullTerminated

- published as dub package

https://github.com/rumbu13/windows-d


Nice - email finally sent by the way.

Re: Windows Bindings v1.0

[Max Haughton via Digitalmars-d-announce]

On Tuesday, 16 February 2021 at 08:45:19 UTC, Rumbu wrote:
The D Windows SDK projection reached first version. Generated 
bindings were compiled succesfully.


https://github.com/rumbu13/windows-d

Destroy!


Hi, I'll be getting in touch about featuring this on the D blog 
soon - would you prefer to be contacted anywhere other than your 
git email?

Re: Beerconf February 2021

[Max Haughton via Digitalmars-d-announce]

On Monday, 15 February 2021 at 00:18:46 UTC, superbomba wrote:

On Sunday, 14 February 2021 at 23:30:56 UTC, Paul Backus wrote:

[...]


The problem isn't that despite that I gave examples of video 
streaming sites, I could say the same for other online 
meetings, like: Google's Hangout, Join.me and many others that 
I can access without problem.


[...]


You should keep your browser updated. Firefox version 52 is so 
old it won't have any spectre or meltdown mitigations and 
countless other security bugs.

Re: Beerconf February 2021

[Max Haughton via Digitalmars-d-announce]

On Sunday, 14 February 2021 at 00:54:41 UTC, superbomba wrote:
On Saturday, 13 February 2021 at 20:48:53 UTC, Steven 
Schveighoffer wrote:

...


Is it possible to rebroadcast live with YT for those who can't 
access the original site or app?


superbomba.


With Jitsi you don't need voice or video if you just want to 
listen.

Re: Please Congratulate My New Assistant

[Max Haughton via Digitalmars-d-announce]

On Sunday, 24 January 2021 at 13:49:20 UTC, Timon Gehr wrote:

On 24.01.21 14:00, Max Haughton wrote:

[...]


I can get behind this. You closed one of my issues that was 
fixed this way, but I don't usually report INVALID issues, this 
is why there is a WORKSFORME category.


[...]


I was wrong on the enhancement requests, and the WORKSFORME one 
shouldn't have been marked invalid but I think I misclicked.

Re: Please Congratulate My New Assistant

[Max Haughton via Digitalmars-d-announce]

On Sunday, 24 January 2021 at 12:36:16 UTC, Timon Gehr wrote:

On 18.01.21 10:21, Mike Parker wrote:
Thanks once more to Symmetry Investments, we have a new paid 
staffer in the D Language Foundation family.


Though I call him my "assistant", I can already see he will be 
more than that. He'll be taking some things off my shoulders, 
sure, but he also has ideas of his own to bring into the mix. 
Adding him to the team is certain to be a boon for the D 
community.


So, a word of warning to those of you who haven't heard from 
me in a while pestering you for blog posts: get used to the 
name "Max Haughton".


And congratulate him while you're at it!


Congratulations. However, Max seems to be just closing all 
enhancement requests on bugzilla as invalid. This is the 
behavior of a vandal. Please stop. Any policy that requires 
this is ill-advised. Issues are valuable and binning them like 
this is disrespectful to the time of the reporters.


I was going through trying to close things that are either not 
bugs anymore because they haven't been touched from 2010 and 
they've been fixed by entropy, or language changes which will 
never be looked at again because they aren't DIPs. They're still 
in public record but fundamentally they're just not useful 
anymore - I was literally just going through bugs FILO and trying 
to either reproduce or at least characterise whether they even 
can be acted on by the foundation.


It's entirely possible I was overzealous and if I was, obviously 
reopen them but ultimately the enhancements have to go through a 
DIP because it's not 2012 anymore.


I also updated Stephen S's shared-delegate race condition bug to 
have a test case that actually compiles, and that's from 2010 - 
theadsan catches it now although it doesn't work with @safe 
either so I'm not sure whether we should be embarrassed or not.

Re: Please Congratulate My New Assistant

[Max Haughton via Digitalmars-d-announce]

On Thursday, 21 January 2021 at 10:53:47 UTC, Walter Bright wrote:


Welcome Max and congratulations!


Thanks everyone

Re: styx, a programming languange written in D, is on the bootstrap path

[Max Haughton via Digitalmars-d-announce]

On Friday, 15 January 2021 at 19:18:09 UTC, Basile B. wrote:
On Friday, 15 January 2021 at 09:54:59 UTC, Ola Fosheim Grøstad 
wrote:

[...]


self-hosting is not started yet, maybe next month, classes are 
still to be implemented.
I plan to use dparse for the most part, not only to convert but 
also to detect non bootstrapable code or missing features. 
Then, feature freeze, convert, catch and fix bugs as they will 
appear when feading the compiler with real food.


[...]


Thoughts on libfirm? I am thinking about writing an online book 
about compiler backends so I'm curious what it's like to work 
with.

Re: Please Congratulate My New Assistant

[Max Haughton via Digitalmars-d-announce]

On Monday, 18 January 2021 at 22:33:43 UTC, IGotD- wrote:

On Monday, 18 January 2021 at 09:21:45 UTC, Mike Parker wrote:
Thanks once more to Symmetry Investments, we have a new paid 
staffer in the D Language Foundation family.


Though I call him my "assistant", I can already see he will be 
more than that. He'll be taking some things off my shoulders, 
sure, but he also has ideas of his own to bring into the mix. 
Adding him to the team is certain to be a boon for the D 
community.


So, a word of warning to those of you who haven't heard from 
me in a while pestering you for blog posts: get used to the 
name "Max Haughton".


And congratulate him while you're at it!


What is the tasks of this new "assistant"?


It's looking like the things I'll be doing can be split under two 
major categories - the first is "just" generally doing whatever 
Mike needs doing (He's a busy man), and some more autonomous 
things like scouting for the blog. The second category is a bit 
looser, as there are some things I'd like to do that come under 
the community relations remit that aren't as structured - e.g. I 
am very interested in getting a proper working group together to 
try and iterate through designs properly rather than incremental 
DIPs.

Re: Please Congratulate My New Assistant

[Max Haughton via Digitalmars-d-announce]

On Monday, 18 January 2021 at 09:32:06 UTC, Imperatorn wrote:

On Monday, 18 January 2021 at 09:21:45 UTC, Mike Parker wrote:
Thanks once more to Symmetry Investments, we have a new paid 
staffer in the D Language Foundation family.


Though I call him my "assistant", I can already see he will be 
more than that. He'll be taking some things off my shoulders, 
sure, but he also has ideas of his own to bring into the mix. 
Adding him to the team is certain to be a boon for the D 
community.


So, a word of warning to those of you who haven't heard from 
me in a while pestering you for blog posts: get used to the 
name "Max Haughton".


And congratulate him while you're at it!


Welcome aboard Max! Let's make 2021 the year when D shines :)

(Also, general question:
Will the PR guys and Max be on Discord or Slack or will it be 
too much for them?)


Anyway, welcome 


I am on slack under my real name (IIRC) and I can found on the 
discord under the name "mhh__"


Feel free to ping me on either although there may be some latency 
because the notifications are completely broken on my phone.

Re: Truly algebraic Variant and Nullable

[Max Haughton via Digitalmars-d-announce]

On Sunday, 20 December 2020 at 12:32:35 UTC, Petar Kirov 
[ZombineDev] wrote:

On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote:

[...]


I have been using SumType [1] for a while in some of my 
projects and I'm quite happy with it. The author has been very 
responsive to feedback and the quality bar of his work is 
definitely higher than that of many other D libraries (e.g. 
support for @safe/pure/@nogc/nothrow, immutable, betterC and 
DIP1000, etc.).


[...]


I'm increasingly thinking these should be a language feature, it 
just seems right.

Re: Chimpfella - new library to do benchmarking with ranges (even with templates!)

[Max Haughton via Digitalmars-d-announce]

On Saturday, 19 December 2020 at 09:39:49 UTC, Виталий Фадеев 
wrote:
On Saturday, 19 December 2020 at 08:30:09 UTC, Виталий Фадеев 
wrote:
On Saturday, 19 December 2020 at 05:08:56 UTC, Max Haughton 
wrote:

https://code.dlang.org/packages/chimpfella

Haven't finished documenting it yet.

[...]


...
@wrapper
function()
...

I like it!


and I want some like this for memory:
  save process memory
  call func()
  print memory delta


Memory is a bit harder but I will add it.

Chimpfella - new library to do benchmarking with ranges (even with templates!)

[Max Haughton via Digitalmars-d-announce]

https://code.dlang.org/packages/chimpfella

Haven't finished documenting it yet.

This uses enormous amounts of static this and that and templates, 
so expect vague error messages (I have tried to catch obvious 
errors early using static asserts but they aren't magic).


This will soon support Linux's perf_event so you will be able to 
measure cache misses (and all the other thousands of pmc's intel 
expose), use LBR msrs etc.


Quick code sample:

If for some reason you wanted to measure how many CPUID's it 
takes to make your cpu literally useless, you'd write this code 
(the ctfeRepeater helper function is because dmd doesn't like map 
at compile time)


static string ctfeRepeater(int n)
{
return "cpuid;".repeat(n).join();
}

enum cpuidRange = iota(1, 10).map!(ctfeRepeater).array;
@TemplateBenchmark!(0, cpuidRange)
@FunctionBenchmark!("Measure", iota(1, 10), (_) => [1, 2, 3, 
4])(meas)

static int sum(string asmLine)(inout int[] input)
{
//This is quite fun because ldc will sometimes get rid of the 
entire function body and just loop over the asm's

int tmp;
foreach (i; input)
{
mixin("asm { ", asmLine, ";}");
}
return tmp;
}

Re: MIR vs. Numpy

[Max Haughton via Digitalmars-d-announce]

On Wednesday, 18 November 2020 at 15:20:19 UTC, 9il wrote:

On Wednesday, 18 November 2020 at 13:14:37 UTC, jmh530 wrote:
On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt 
wrote:


It also looks like you are compiling on ldc with -mcpu=native 
--boundscheck=off. Why not -O as well?


-O is added by DUB


Just -O? LDC is quite impressive with lto and 
cross-module-inlining turned on

Re: Five Projects Selected for SAOC 2019

[Max Haughton via Digitalmars-d-announce]

On Wednesday, 4 September 2019 at 23:56:07 UTC, Laeeth Isharc 
wrote:

On Tuesday, 27 August 2019 at 17:32:30 UTC, Max Haughton wrote:
On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev 
wrote:

[...]


I was aware of the site when i wrote the proposal, but the 
idea is to create the infrastructure to add more measurements 
too, e.g. profiling the compiler or testing it under limited 
memory (I found out how much memory my CTFE thing was using 
the other day!). Assuming I can get it to work I'd also like 
to throw the Linux perf system in there too,


Take a look at BPF.  Might be some work to wrap and if I recall 
right some of the C headers are a bit gnarly.  But it's pretty 
powerful.


https://github.com/brendangregg/bpf-docs


I'll look into it, thank you. Seems like a big rabbit hole to go 
down but the project is far from set in stone.

Re: Five Projects Selected for SAOC 2019

[Max Haughton via Digitalmars-d-announce]

On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev 
wrote:

On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote:
The Symmetry Autumn of Code 2019 application selection process 
has come to an end. This year, we've got five projects instead 
of three. Congratulations to everyone who was selected! You 
can read about them and their projects over at the D Blog:


https://dlang.org/blog/2019/08/25/saoc-2019-projects-and-participants/


Sorry, I haven't been following. Don't we already have an 
implementation of the "Create a CI or other infrastructure for 
measuring D’s progress and performance" project? I just haven't 
been maintaining it because there hasn't been a lot of interest 
in it while it was being maintained.


Here's the original blog post:

https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/

I'll give it a kick and get it back online if there is 
interest. Seems wasteful to reimplement it from scratch, though.


I was aware of the site when i wrote the proposal, but the idea 
is to create the infrastructure to add more measurements too, 
e.g. profiling the compiler or testing it under limited memory (I 
found out how much memory my CTFE thing was using the other 
day!). Assuming I can get it to work I'd also like to throw the 
Linux perf system in there too, but


As mentioned in the summary, this will extend to runtime 
performance too but that obviously raises the question of how to 
ensure consistent performance of the testing machine (or give a 
relative figure).

Re: Five Projects Selected for SAOC 2019

[Max Haughton via Digitalmars-d-announce]

On Tuesday, 27 August 2019 at 14:42:28 UTC, Vladimir Panteleev 
wrote:
On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev 
wrote:

On Sunday, 25 August 2019 at 13:38:24 UTC, Mike Parker wrote:
The Symmetry Autumn of Code 2019 application selection 
process has come to an end. This year, we've got five 
projects instead of three. Congratulations to everyone who 
was selected! You can read about them and their projects over 
at the D Blog:


https://dlang.org/blog/2019/08/25/saoc-2019-projects-and-participants/


Sorry, I haven't been following. Don't we already have an 
implementation of the "Create a CI or other infrastructure for 
measuring D’s progress and performance" project? I just 
haven't been maintaining it because there hasn't been a lot of 
interest in it while it was being maintained.


Max, if you're still excited about this project, please ping me 
on IRC or Slack. Would love to brainstorm with you and hear 
your ideas.


Vladimir, I would love to (and I need to acquire a mentor, so if 
you're not busy... ;) ) but I am struggling to even load the 
forum (I'm on holiday) but I'll be back to civilisation within a 
day or two.



To anyone else reading: If the gods allow it, I'm *trying* to 
answer questions about my proposal but my internet connection is 
genuinely shit ATM

Re: Release D 2.087.1

[Max Haughton via Digitalmars-d-announce]

On Monday, 5 August 2019 at 21:16:44 UTC, Martin Nowak wrote:

Glad to announce D 2.087.1, ♥ to the 24 contributors.

http://dlang.org/download.html

This point release fixes a few issues over 2.087.1, see the 
changelog for more details.


http://dlang.org/changelog/2.087.1.html

-Martin


I don't know whether it's already in or not, but this has the new 
template constraint messages (which are actually readable!)

Re: Ownership and Borrowing in D

[Max Haughton via Digitalmars-d-announce]

On Sunday, 21 July 2019 at 20:20:10 UTC, Per Nordlöw wrote:

On Saturday, 20 July 2019 at 21:56:50 UTC, Walter Bright wrote:


We're likely going to add a move constructor, too.


And deprecate opPostMove?


Seems likely, especially given that DIP1014 hasn't been 
implemented in the language or made it into the spec yet.

Re: D on Tiobe Index

[Max Haughton via Digitalmars-d-announce]

On Thursday, 31 August 2017 at 16:37:35 UTC, SrMordred wrote:

What happened in 2009?


Probably other languages improving rather than D usage declining. 
2009 is (approximately) the year that javascript began it's rise 
up the index (Node.js was released in 2009).