Re: Beerconf July

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Time for that link once again!

https://meet.jit.si/Dlang2024JulyBeerConf

Re: Beerconf June

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

It's that time of year once again, Matariki!

So you know what that means, it is time to grab ya Kumara and put down a 
Hāngī for a feast.


Oh and there is this other event going on this weekend called BeerConf, 
so just in case anyone is interested in that here is the link.


https://meet.jit.si/Dlang2024JuneBeerConf

Re: DConf '24 Schedule & BeerConf News

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Very awesome lineup this year!

Re: Beerconf May

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Its time for another link!

https://meet.jit.si/Dlang2024MayBeerConf

Oh and don't forget to update your Intellij D plugin, and have your 
Intellij instance at 2024.1.2 there some nice improvements and bug fixes 
in both!

Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 16/05/2024 11:43 PM, Dennis wrote:
just in case I've worked on an issue, how do I communicate with the 
community/mentors about it? Is there a discord/slack community I can join?


On the main website under Community there is an invite link to the 
community Discord.


Many people are there including Mike Parker and Razvan.

Re: D Language Foundation January 2024 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Wow I see I was mentioned at a lot at this meeting!

In saying that I do have some points to add about Item 2 data structures.

Data structures come in one of two forms generally: owning and non-owning.

### Non-owning

Non-owning is the simplest, its an index.
It doesn't own any memory that isn't internal.

Takes in a single memory allocator for its internal state.

For its memory safety you are pretty limited to concerns surrounding 
read-only-ness of its internal state. Which only exist because the GC 
allocator might be in use.


You pass a value in, you get a value out. No references.

### Owning

Owning data structures come with two subsets which may be mixed to form 
a third combined subset.


 Cleans up

Takes in two memory allocators, one for its internal state, one for its 
deallocation of values.


Will deallocate any memory given to it, which also means that once 
memory is placed into it, it now owns it and is responsible for its cleanup.


As for memory safety you have only one (as long as you don't use 
references out).


Owner escape analysis, this is a DIP Walter has required for me to work 
on before reference counting. So its going in anyway.


 References out

I'll assume here that it does not clean up any memory passed in, that 
you handle this manually, that the data structure is merely an index.


In almost all ways its similar to non-owning, one memory allocator, 
still has the memory safety concerns of the owner.


An you also have to worry about borrows typically from a struct 
acting as a reference. Which once again is resolved with owner escape 
analysis (noticing a trend yet?).




What this tells us is that non-owning data structures can go in pretty 
much immediately, although there will need to be some remedial work once 
we get reference counting and with that a solution to read only memory.


But of course because Walter wants owner escape analysis first, it 
doesn't matter, both owning and non-owning will need to go together.


Note: concurrent data structures will need the read only memory solution 
due to the locks (notice a trend yet?) as well.


We'll likely want to use long names to differentiate all these behaviors 
unfortunately. As it could be quite desirable to have all the different 
variations.

Re: Beta 2.109.0

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 11/05/2024 4:00 AM, Iain Buclaw wrote:

Fix your gitconfig then. :-)


Oh dangit, I hadn't noticed that it changed on me.

It was set correctly a few months ago! Ug.

Wonder why it changed after it was set correctly.

Re: Beta 2.109.0

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 10/05/2024 9:14 PM, Iain Buclaw wrote:
Glad to announce the first beta for the 2.109.0 release, ♥ to the 41 
contributors.


This release comes with 14 major changes and 22 fixed Bugzilla issues, 
including:


- In the language, the special function `__ctfeWrite` has been to write 
messages from CTFE.

- Introspection capabilities have been added to Bit-fields.
- In the compiler, missing symbol errors from the linker are now 
formatted to be more readable.


http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.109.0.html

As usual please report any bugs at
https://issues.dlang.org

-Iain
on behalf of the Dlang Core Team


Looks like my name needs cleaning up! Its there four times.

We should also probably remove:

"DigitalMars sppn does not support anything newer than C99. It is known 
to be limited and using any Unicode character not in those ranges will 
result in an error."


Since OMF is gone :D

Re: Beerconf April

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Come one, come all, its Jitsi time once again!

The DIP queue is open, first DIP is in the review pipeline, so let's 
discuss some fantastical ideas with our brews in hand!


https://meet.jit.si/Dlang2024AprilBeerConf

Re: photon v0.7.0 with Windows support(!)

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 25/04/2024 5:41 AM, Dmitry Olshansky wrote:

On Wednesday, 24 April 2024 at 14:40:40 UTC, Steven Schveighoffer wrote:

On Tuesday, 23 April 2024 at 19:05:48 UTC, Dmitry Olshansky wrote:

On Tuesday, 23 April 2024 at 17:15:13 UTC, Sönke Ludwig wrote:
I guess that the Darwin support will be restricted to freely 
distributed macOS applications, as calling `__syscall` surely is a 
private API that cannot be used in any AppStore application, right?


You tell me;)
API looks just like any other libc function.


I can tell you right off that this will not be allowed in approved 
apps. Not just for the `__syscall`, but for overriding the normal 
system calls of all libraries. I can't imagine Apple will be OK with 
that.


How would they know? The whole thing happens at the link time.

—
Dmitry Olshansky
CEO @ Glowlabs
https://olshansky.me


Two ways:

Look at externs for your binaries, if any symbol is black listed, it 
won't be allowed (such as ``__syscall``).


Decompile, if you see certain instructions, don't allow it.

I can't find it, but we did have something in druntime that was failing 
due to private API usage in the past (and hence couldn't publish D 
applications).

Re: LDC 1.38.0-beta1

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 20/04/2024 12:41 PM, kinke wrote:
Android: Switch to native ELF TLS, supported since API level 29 (Android 
v10), dropping our former custom TLS emulation (requiring a modified 
LLVM and a legacy ld.bfd linker). The prebuilt packages themselves 
require Android v10+ (armv7a) / v11+ (aarch64) too, and are built with 
NDK r26d. Shared druntime and Phobos libraries are now available 
(|-link-defaultlib-shared|), as on regular Linux.


I shared that on Discord.

This is something I've been looking forward to for a long time!

Thanks

Today has sure been a good day.

Re: photon v0.6.0 with MacOS support

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 13/04/2024 4:57 AM, Dmitry Olshansky wrote:

Next on schedule is Windows support.


I see that you left the hard one for last.

Good luck! Happy book buying.

Re: Beerconf March (dconf online)

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 22/03/2024 5:36 AM, Ethan wrote:
On Monday, 18 March 2024 at 22:15:49 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
Perhaps we can do the usual end of month time as well, I'll give you a 
ping if I can do it.


At this rate I could very well be on a plane again, to more southern 
destinations this time.


Naturally, naturally.

Let me know when things calm down for you!

Re: Beerconf March (dconf online)

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 19/03/2024 10:46 AM, Ethan wrote:

On Saturday, 9 March 2024 at 13:34:50 UTC, Steven Schveighoffer wrote:

# BEERCONF!


And here I was getting on the newsgroups to see if BeerConf was coming 
up sometime soon. I was on planes last weekend anyway so it would have 
been quite impractical to jump on.


Perhaps we can do the usual end of month time as well, I'll give you a 
ping if I can do it.


Depends upon how the week leading up to it for me goes (may not go well).

Re: Beerconf March (dconf online)

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Linkity link for BeerConf: https://meet.jit.si/Dlang2024MarchBeerConf

And starting in under 3 hours DConf Online: 
https://www.youtube.com/watch?v=8GV_TuYk3lk

Re: Beerconf March (dconf online)

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Heads up to all, its DConf Online 2024 in 7 hours!

I'll put up a link for BeerConf in around 5 hours, get ready with ya brews!

Re: The New DIP Process

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Excellent.

I haven't heard anything about my export DIP, the last that was said 
from Mike is that Walter might want to review it external to the DIP 
process. Unfortunately no feedback beyond that so unless I'm told 
otherwise, its DIP TIME!


As it has already had a lot of back and forth from Walter and me with 
the help of Adam Wilson (very much appreciated!), it's ready for a 
development forum post.


So Mike, once the forum is up, am I in the clear to start at development?

https://gist.github.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e

Re: Beerconf February 2024

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Oh hey, its a linkity link time!

https://meet.jit.si/Dlang2024FebruaryBeerConf

Re: DMD Compiler as a Library: A Call to Arms

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

In response to this, I thought well this is annoying work, why can't we 
automate it?


So I did automate a little bit of it exploratory work.

I used dustmite to minify the TODO modules to know what is required to 
make the parser compile.


The scripts I used are all here, along with a utility program.

Note: if you are doing this work, make sure to copy dmd's source into 
imports and then delete the modules that you want to have minified from 
it. But it is best to do them one at a time.


https://gist.github.com/rikkimax/c9a65e82b9cbec60bbd93c5a0d14e827

Re: Crow programming language

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 16/02/2024 4:21 PM, andy wrote:
On Friday, 16 February 2024 at 01:26:42 UTC, Richard (Rikki) Andrew 
Cattermole wrote:


You can use const instead which doesn't have any such guarantees and 
it'll work with a pure function :)


It still seems to be considered mutable?

     pure void main() {
     // a.d(2): Error: `pure` function `D main` cannot access 
mutable static data `strings`

     auto mut = cast(string[]) strings;
     mut ~= "foo";
     }

     const string[] strings;



That would be stored in TLS, add static to get it out.

Re: Crow programming language

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 16/02/2024 12:46 PM, andy wrote:

If you make global variables |immutable|, you can access them in
|pure| functions.

Is it as simple as that? I'd have to cast away the |immutable| when 
adding a new interned string though. Is that still the correct way to do it?


No.

It was never correct.

Immutable is a very strong guarantee that the memory will never change.

The compiler in such a case is free to put it into read only memory and 
as a result crash if you tried to write to it.


You can use const instead which doesn't have any such guarantees and 
it'll work with a pure function :)

Re: Release D 2.107.0

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Doesn't look like any of Dennis's work on improving the Unicode tables 
for Phobos has made it in this release.


Bit of a shame, they are a lot faster now!

But good stuff in this release anyway!

Re: Symmetry Autumn of Code 2023 Result

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Very good work to all involved!

Re: Google Summer of Code 2024

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Very good work to all!

Re: Beerconf January 2024

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Reminder Chibisi's talk on https://github.com/chibisi/saucer is in an hour!

The purpose of the saucer project is to create bidirectional interop 
between R, the statistics programming language and D. The aim is that in 
time, it will have easily accessible capabilities similar to libraries 
like Rcpp in terms of its features and capability, but with the added 
advantage that the D programming language is used with R, and can bring 
it’s expressive power and other capabilities to build analytical 
software that can be made available in R as well as D being able to 
access R’s rich API. A live demonstration of the library in use will be 
included by way of an example.

Re: Beerconf January 2024

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Don't be down now that 2023 has come to an end, for BeerConf has begun 
for 2024!


https://meet.jit.si/Dlang2024JanuaryBeerConf

Re: Happy New Year!

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 03/01/2024 2:25 PM, Walter Bright wrote:
Along with my best wishes for a happy and prosperous 2024 to all the DLF 
community members, and their families and friends.


And to you too Walter!

Let's make 2024 the best year yet.

Create some excitement from some changes for things that have been 
holding us all back.

Re: D Language Foundation October Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 01/01/2024 12:12 AM, Mike Parker wrote:
Next, he said he'd discovered that a one-line file with |import 
std.file| takes 200ms to compile, and that was nuts. He needed to figure 
out at some point exactly what the problem was. It was just semantic 
analysis just from the import. He wasn't even generating the object 
file. On the same machine, he also tried a C++ compile with just 
|#include | and that took 400ms. He said that twice as fast as 
C++ was nowhere good enough. Walter agreed.


It's 2024, so lets hunt down what the problem is with ``std.file``.

On my machine compiling it using ldc2 1.35.0, it took ~500ms (frontend 
only).


That is quite a long time.

So lets go hunting!

I've found a bunch of cost associated with ``std.uni``, specifically 
from ``std.windows.charset``.


Which imports ``std.uni`` via ``std.string``, and ends up imports the 
unicode tables which take 117ms to sema2 (no surprises there).


Why does it import ``std.string``? To call toStringz. What did I replace 
it with in my test code? ``return cast(typeof(return))(s ~ "\0").ptr;``.


Bye bye 117ms.


Next up ``std.datetime.timezone`` 40ms of that is from ``std.string``, 
but alas that actually is needed.


Now on to sema2 for ``std.datetime.systime``, again into 
``std.datetime.timezone``, nothing we can do there as above. For all 
111ms of it.



All and all, I can't find anything to really prune for this. There won't 
be any easy wins here.


The Unicode tables would need to be completely redone to improve it and 
if done may only decrease the sema2 from ~100ms.

Re: Beerconf December 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Grab your warm Dr. Pepper, or your frozen desert if you are in the 
southern hemisphere and come on down to BeerConf!


https://meet.jit.si/Dlang2023DecemberBeerConf

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

That is awesome to hear!

If the move towards ldc has the potential to half your run time, that is 
quite a significant improvement for your customers.


It will be interesting to hear how dcompute will fare in your situation, 
due to it being D code it should be an incremental improvement once 
you're ready to move to D fully.


Based upon the estimates here already, it seems like acquiring an LDC 
developer in house might be well worth it.

Re: Beerconf November

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Time for a link!

https://meet.jit.si/Dlang2023NovemberBeerConf

Don't forget to vote!

Re: DLF September 2023 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Agreed, getting good locking support is critical for safe memory 
handling at the process level.


Shared as we know it today, is just a distraction from this goal.

Re: DLF September 2023 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Part of the problem with shared is that it is completely inverse of what 
it should be.


It fundamentally does not annotate memory with anything extra that is 
useful.


At the CPU level there are no guarantees that memory is mapped only to 
one thread, nor at the language level.


Therefore all memory is shared between threads.

As long as people have this inverted mindset in place and instead of 
wanting to prove its thread owned shared is going to be a problem for us.


Remove shared, add atomic storage class. Figure out thread owned/shared 
memory some other day.

Re: Good News: Almost all druntime supported on arsd webassembly

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 09/11/2023 2:42 AM, Hipreme wrote:
If the runtime is not revived, there is no point in having a GC at all, 
and it is impossible to use the GC without the runtime, but runtime 
without the GC, it is possible :)


That's not true.

You wouldn't need anything in druntime to make the wasm GC work. 
Everything would be done in the glue layer of the compiler and would be 
specific to that target.


The druntime bits for GC or TypeInfo wouldn't be used.

Re: Good News: Almost all druntime supported on arsd webassembly

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 06/11/2023 5:18 AM, Sebastiaan Koppe wrote:
I am not sure what a possible path to support should look like, aside 
from writing a complete fresh backend.


I don't think it would be a whole new backend. The output is the LLVM IR 
essentially, so its just the glue code that would need to be implemented.


However after that has occurred, who knows how much you'd get working 
other than structs newing.

Re: First Beta 2.106.0

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Anything that requires the AA from CTFE to cross into runtime should now 
work. If it doesn't that is a bug.

Re: Beerconf October 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Forget the divisiveness and say hello to comradery!

https://meet.jit.si/Dlang2023OctoberBeerConf

Re: From the D Blog: Crafting Self-Evident Code in D

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 04/10/2023 8:03 AM, Walter Bright wrote:

On 10/3/2023 12:36 AM, Max Samukha wrote:
'No hire' for language designers who design sum types to be implicitly 
enumerated and convertible to integers and booleans?


There's a reason my salary from the D Foundation is $0.


As long as its the tag value implicitly converting, I would suggest that 
is fine and is how I'd do it.


There is the special case of None being reserved for 0 that you have to 
be aware of (if it isn't in set, you are always > 0).

Re: Beerconf September 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Link timee! https://meet.jit.si/Dlang2023SeptemberBeerConf

Heads up, Jitsi has started to require a moderator to be present, I have 
no additional information apart from what it asked me when I joined.


So we may need someone else to step up during it to become one by 
logging in, we'll see what the changes entail.

Re: SerpentOS departs from Dlang

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

The announcement post from Ikey included as its only explicit mention of 
something bad about D itself that DIP1000 was incomplete.


My mention of reference counting as a way to allow for a complete story 
for DIP1000 matched this goal that also matched what other people wanted 
here.


Not everyone has the same priorities, especially when it comes to 
comparing a minor feature that is almost in the language already, to a 
major feature that will take years to complete.


Lets be clear on something, I want sum types. I need sum types for value 
type exceptions which are waiting on only sum types. I do not believe 
that Walter's DIP is complete enough to be a "good" design to further 
this goal.


Disparaging me because I placed a higher priority on something critical 
to my 110k+ LOC code base performance wise, does not aid in your goal of 
the addition of a major feature which pretty much everyone wants at some 
level.

Re: SerpentOS departs from Dlang

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 17/09/2023 11:46 AM, Adam Wilson wrote:
Kidding aside. If you do this, you might as well turn them on 
everywhere. After that it's a easy stroll to a non-blocking moving GC, 
which would end most complaints about the GC (nobody complains about the 
.NET GC anymore).


The scope of each doesn't match up, and you'd still need the RC specific 
write barriers.


So when I say write barrier what I mean is:

```d
class MyRoot : void {
void opRCWriteBarrier(size_t fieldOffset, void* pointer) {
myCyclicDetector.set(cast(void*)this, fieldOffset, pointer);
}

void opRCSub() {
if (atomicOp!"-="(this.refCount, 1) > 0)
myCyclicDetector.collect(cast(void*)this);
}
}

class Child : MyRoot {
Array!int array;

void func() {
array = new Array!int();
// this.opRCWriteBarrier(array.offsetof, cast(void*)array);
}
}
```

Only needs to support classes + structs (I think), so its surface area 
is pretty small.


Oh and Walter has approved anyone to experiment with write barriers ages 
ago, although nobody has.

Re: SerpentOS departs from Dlang

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 17/09/2023 12:25 AM, sighoya wrote:
On Saturday, 16 September 2023 at 10:22:31 UTC, Richard (Rikki) Andrew 
Cattermole

wrote:


The approach that I think will work well for us is to support 
reference counting on structs & classes, and make them not adhere to 
DIP1000.


Does that mean you are against dip1000 or do you want both?


Basically DIP1000 handles the final leg of lifetime management, rather 
than managing the actual ownership of memory. It comes into play after 
you borrow from a container.


I will be doing the DIP for RC due to its cost of it and the fact that 
modern backends do understand it and can make it cheaper.


Will it be automated reference counting with a special type of GC doing 
the job or a local RC container?


Its basically what we do now with copy constructors + destructors, but 
inside dedicated methods.


Although I do want a write barrier on each struct/class, to allow for 
cyclic handling especially for classes.

Re: SerpentOS departs from Dlang

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 16/09/2023 9:02 PM, Adam Wilson wrote:
I know there are ref-counted languages so theoretically it should be 
workable, but the in a language as complex as D there may be dragons on 
the edges.


The approach that I think will work well for us is to support reference 
counting on structs & classes, and make them not adhere to DIP1000.


Then you borrow memory from them, and DIP1000 takes over.

This minimizes the surface area of the language that needs to understand 
reference counting and life time handling. So our one dimensional 
approach with DIP1000, will absolutely shine.


I will be doing the DIP for RC due to its cost of it and the fact that 
modern backends do understand it and can make it cheaper.

Re: Beerconf August 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Linkity link time!

Sadly no one has volunteered for a presentation this time, but it won't 
be long till we get to watch a whole pile!


https://meet.jit.si/Dlang2023AugustBeerConf

Re: Beerconf July 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Its the time again, time for the link!

https://meet.jit.si/Dlang2023JulyBeerConf

Re: Evolving the D Language

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

A big problem with compiler switches is that they have to apply to 
everything in a build, or things won't line up. You can't pick and 
choose which module it applies to, even if you could, its going to lead 
to people having a very bad day.


This is another reason why strict by default is the right choice.

If you become strict instead you break peoples code. But if you allow 
obsolete you do not (it could appear anywhere in a build graph).


Either way, I don't think this is 100% there yet.

Re: Evolving the D Language

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

I suspect that we kinda have it a little backwards.

Keep it strict by default, but allow more code to pass if desired.

This is how a build manager like dub should operate.

Part of the goal here is to make sure people don't go round using 
undesirable features by accident.


Also we should probably have the ability to turn on only a subset of the 
features based upon version. That way you can only accidentally add 
behavior that you already know about and not have infinite possibilities 
going forward.




And for the record I still want hex strings to come back. They were 
incredibly useful with no good alternatives when we talk about large 
tables of data being described.

Re: On Mir parts migration to DRuntime

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

They are already on dub.

https://code.dlang.org/search?q=mir

The stated goal appears to be to get them into Phobos to minimize chance 
of death.


But yeah the conditions being requested are too restrictive to consider 
as-is.

Re: Beerconf June 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Linkity link link https://meet.jit.si/Dlang2023JuneBeerConf

Re: D Language Foundation Monthly Meeting Summary for May 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

If you feel up to doing a practice talk, you're welcome to join us on 
BeerConf!

Re: Beerconf May 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Heres Jitsi!

https://meet.jit.si/Dlang2023MayBeerConf

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 15/05/2023 11:53 AM, max haughton wrote:
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?)


This bit from Walter says it all I think:

> Walter said he had given up on maintaining DMC. The DMD backend had 
already diverged, and he saw no further point in maintaining DMC.


Time for OMF stuff to become optional in CI.

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 15/05/2023 12:47 AM, Mike Parker wrote:
Átila said he'd been thinking about copying Herb Sutter's idea for 
zero-overhead C++ exceptions. He said the basic idea is that you get rid 
of exceptions while keeping the syntax. (Here's a link to the PDF 
).


Design work is already done.

https://github.com/rikkimax/DIPs/blob/value_type_exceptions/DIPs/DIP1xxx-RC.md

I kinda think sumtypes should go first so we can do catch all.

Re: A New Era for the D Community

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Very interesting.

I just want to say, I'm having repeated unrelated CI failures for: 
https://github.com/dlang/phobos/pull/8699


Yesterday I finally said right stuff this I don't have the energy to 
fight the CI on this anymore and asked Razvan to kinda take over as the 
changes on my end are fundamentally done.


This may not seem very important, but to Symmetry, without Razvan I'd 
honestly just close that PR and leave 500ms reduction in compile times 
when you import std.regex on the table. Having this extra support in the 
community who can tackle this sort of issues is both highly appreciated 
and highly motivational for unblocking people in the future.


Much appreciation all round, long may it continue!

Re: Walter on Twitter

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 18/04/2023 3:02 PM, Walter Bright wrote:

On 4/15/2023 6:49 AM, Monkyyy wrote:
By all means fund and promote *live coding* or teaching videos if you 
want to outreach, but shitposting on twitter wont do anything of value


Mike has also suggested I do some live coding videos.


You're always welcome to do some live streaming on Discord :)

Those video channels don't get used enough, and I haven't figured out a 
way to encourage their usage so it would be a help!

Re: D Language Foundation March 2023 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Finally, he asked what everyone thought about including Phobos in the 
dmd/druntime mono repository. He said he'd seen no good reason not to 
[in the forum thread he'd 
started](https://forum.dlang.org/thread/kdgcznersjetunkvo...@forum.dlang.org). Iain said that from his perspective, DRuntime and Phobos are the same thing anyway. Mathias voiced support for it. Robert said that if it happened, the first thing he'd do is replace some instances of `filter` with the Phobos version, as he thinks we should be using Phobos in DMD anyway. (Note that no final decision was made here.)


When I type dmd into my browsers search bar this is what it suggests:

dmd/druntime at master · dlang/dmd · GitHub

Not very compiler related now is it ;)


__Template lowerings in CTFE__

One problem he'd discovered was that the semantic routines take several 
constructs and lower them to templates. They do that even when running 
in CTFE. Those templates can generate a lot of bloat. In CTFE, it should 
not do the lowering. CTFE finds it much easier to interpret the 
higher-level code. Upon investigation, he found that CTFE reverses some 
of the lowerings so that it can interpret them. If you're doing certain 
things in CTFE like array concatenation, you're suffering from a lot of 
invisible template bloat. That needs to be fixed. He was about halfway 
through it. He was looking at all the lowerings and rewriting them so 
that the lowering isn't done in CTFE. He hopes that this is another step 
in reducing the problems with memory consumption and slow CTFE speeds. 
He also hoped to be able to remove the "lowering unwinding" that goes on 
in the interpreter.


Iain noted that in [the PR rewriting the  `_d_newclass` runtime hook to 
a 
template](https://forum.dlang.org/post/fmzqqpzrzhoheylue...@forum.dlang.org), he'd noticed the same thing Walter had just described. He got the author to change things such that rather than doing this lowering->unlowering->relowering thing, the rewrite is put into a field called `lowering`, leaving the original node intact. When you go through CTFE, you just work on that node specifically. Then once you're in codegen, you hit that node and go into the `lowering` field. Walter said that wasn't done with the other rewrites, but Teodor Dutu and Razvan plan to go back and change them (here's [an example of work done toward that end](https://github.com/dlang/dmd/pull/14985)). Walter said this will also be a big win for allowing more expansive use of CTFE in BetterC.


Good to see my priority two for the year is getting some work done 
towards it by happenstance.


Now, if only we could get a compiler adjacent library to contain the 
hooks so nobody writing custom runtimes has to write them moving 
forward... That and getting them all in the same place has other 
benefits like faster compiles!

Re: Beerconf March 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Link for all our voices to be heard!

https://meet.jit.si/Dlang2023MarchBeerConf

-- Today shall be a good day, may your voices be loud and your brews be 
cold.

Re: DConf '23 August 29th - September 1 --- Early-Bird Registration is Open!

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 25/03/2023 10:57 PM, Ikey Doherty wrote:
I'd absolutely love to go but I need to check with work, as I have a 
commitment in Canada in August. Hopefully by then I'll have enough for 
tickets ^^


Do a talk and get tickets/hotel paid for :)

Re: D Language Foundation January 2023 Quarterly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

I just want to make this point about -betterC.

As a switch it should just be switching other things off. As a result 
its just a marketing name of D without the language extensions that 
depend on druntime.


It isn't that way in practice, but it should be.

However I think there is a pathway forward here.

My number 2 priority for me this year is to see compiler hooks resolved. 
They should ALL look like this (more or less):


```d
void hook(T)(T thing) {
version(Feature) {

} else
static assert(0, "feature not had, can't do Y");
}
```

Lowering should be the last step but only for functions that need to be 
codegen'd.


This allows significant simplification in the compiler, and allows for 
features to work at CT that won't go into the binary.


There is a lot to this strategy that I am not saying here as it isn't 
relevant to -betterC. There is some very real possibility here to making 
our lives better I think.

Re: Beerconf February 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Reminder Garrett's talk is in 2 hours!

Re: Beerconf February 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Linkity link link time!

https://meet.jit.si/Dlang2023FebruaryBeerConf

I'll do another announcement closer to Garrett's talk. Currently it is 
in about 6 hours time.

Re: 2023: Focusing on stability, GitHub Sponsors, and Frozen DIPs

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 21/02/2023 1:38 AM, Mike Parker wrote:

### Focusing on stability
As a result of a discussion that took place during our January meeting 
(summary coming this week!), Walter and Átila have decided to shift 
gears a bit. For the next year, they want to emphasize stability and 
robustness.


Generally, that means giving priority to issues deemed fundamental, such 
as features that aren't working as advertised, or long-standing bugs 
that detract from the user experience. As a start, Walter has lately 
been working on circular reference bugs, issues with features like 
`export` and `.di` generation, etc.


Over the coming months, I expect we'll start looking beyond one-off 
issues from Bugzilla to see how we can tackle more complex problems, 
like reducing compile times, solving template emission bugs, etc.


I'm currently working on a DIP to redesign export to allow for symbols 
to work correctly wrt. DLL's (the work currently will only get it to be 
usable, not 100%).


Its going to be a pretty dry and unexciting DIP, if you don't use shared 
libraries you will probably not notice anything.


I am excited for it though. Will have to table it for after DIP process 
work is done tho!


I expect the freeze to last a few months. I'll be more concrete about 
dates when I can.


That may be a bit long for the above work, but I'm sure we'll make 
something work, even if its just a test run of the new system :)




This year has got a good chance to be really exciting! Just missing work 
on compiler hooks, tuples, sum types and value type exceptions (which of 
course I didn't PR into the DIP queue and is basically done lol).

Re: Hipreme Engine is fully ported to WebAssembly

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 06/02/2023 12:36 AM, Hipreme wrote:
Exactly because Sebastian did that and that never got upstreamed that I 
didn't work on it.


It never got upstreamed because it was never attempted.

I checked, no PR's for druntime.

Re: SAOC 2022 Result

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Very good work, hooks & dmd-as-a-library work has been of particular 
interest of me to see done.


I've also been monitoring the progress in the PR's of QUIC!

So very well done everyone!

Re: Release D 2.102.0

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 03/02/2023 6:22 AM, Ali Çehreli wrote:
but it doesn't help because the array fullCaseTable in there seems to be 
about equivalence (e.g. of ß and ss). I think we need a "mostly correct" 
collation for latin based characters.


Yeah collation is a very different beast than comparison, we can 
absolutely have a correct implementation its just somebody has to do it.


What we have is correct (although incomplete and on my todo list to 
improve), but it isn't collation and won't be as its a different 
algorithm and tables.


I.e. we are missing https://www.unicode.org/Public/UCA/15.0.0/allkeys.txt

https://issues.dlang.org/show_bug.cgi?id=10566

Re: Release D 2.102.0

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Awesome!

Remember if you need any help with any of the Unicode changes, please 
let me know!

Re: WildCAD - a simple 2D drawing application

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

I've gone ahead and pinged Jan on this. They didn't receive much 
feedback when first announced :)


Part of the problem is dub in general didn't receive much work done on 
it for the better part of 10 years. It has speed up within the last 
couple of years :) The registry and with that docs hasn't had that 
attention put towards it yet though.


I'm horrible at writing documentation, so I'm not much help here sadly.

Re: WildCAD - a simple 2D drawing application

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Like this? https://docs.webfreak.org/getting-started/first-steps/

Re: WildCAD - a simple 2D drawing application

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 31/01/2023 9:39 AM, bachmeier wrote:

On Monday, 30 January 2023 at 04:40:48 UTC, Siarhei Siamashka wrote:

On Monday, 30 January 2023 at 02:44:50 UTC, bachmeier wrote:
if you put your code in directories that match the modules you want 
to import,
there's no need for Dub and the corresponding poorly documented 
configuration.


What is poorly documented? Can you suggest some documentation 
improvements?


That ship has sailed. I've given up on Dub because those who promote it 
aren't interested in criticism. I'll just link to [this 
page](https://dub.pm/package-format-json) and if anyone thinks that's 
acceptable documentation for someone new to the language, there's no 
point having a conversation about it.


It isn't. WebFreak has an on-going project to replace it.

https://forum.dlang.org/post/ojoiwbcftqsxbsviv...@forum.dlang.org

https://docs.webfreak.org/

Re: WildCAD - a simple 2D drawing application

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

dub isn't the issue, people who fight it like this, fight the D 
compilers and end up having issues.


You're fundamentally doing something that D compilers are not designed 
to handle. The problem is with -I flag. Being able to set a directory to 
look modules up in.


Problem is it needs to match the packages to directories.

I.e.

wildwidgets/lib/source/wcw/clipboard.d

Not:

wildwidgets/lib/source/clipboard.d

Also note: you should not use symlinks with VCS, there are 
cross-platform problems with it.

Re: Beerconf January 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

To one and all! Its time for the linkity link.

https://meet.jit.si/Dlang2023JanuaryBeerConf

May you have an exciting year, without floods of problems!

Re: second edition of Build Web Apps in Vibe.d by learning from a learner

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 25/01/2023 3:14 AM, ryuukk_ wrote:
PDF is not a good choice for that kind of tutorial, there is no 
navigation, so once has to scroll to get to the vided stuff


It would be ok, but there is no Table of Contents which removes that 
possibility.

Re: D Language Foundation Monthly Meeting Summary for December 2022

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

A very big problem we have right now is that we are on pretty shaky 
foundations with how symbols are represented at the binary image level 
due to DLL's not be fully implemented in dmd.


Any work for things like incremental compilation must be done with the 
knowledge that the foundations right now are just not there to do this 
reliably cross platform.


I.e. is incredibly easy to run into: 
https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4217?view=msvc-170


I believe we are going to have to modify export (and with that removing 
it as a visibility modifier) quite significantly.


In the C/C++ world you can use macros and compiler level defines to swap 
out DllImport and DllExport, or remove it all together. We can't do 
that. Which means we are going to need to make export a whole lot 
smarter if we don't want to run into these issues on Windows.

Re: Breaking news: std.uni changes!

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 04/01/2023 2:58 AM, Adam D Ruppe wrote:
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.


Ideally. We still need an implementation for CTFE though. Its just a lot 
of work to shoehorn it in now.

Re: Breaking news: std.uni changes!

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 04/01/2023 2:51 AM, Dukc wrote:
On Tuesday, 3 January 2023 at 04:13:53 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

On 03/01/2023 10:24 AM, Dukc wrote:
Other things coming to mind: Bidirectional grapheme iteration, Word 
break and line break algorithms, lazy normalisation. Indeed, lots of 
improvement potential.


I've done word break, "lazy" normalization (so can stop at any point), 
and lazy case insensitive comparison with normalization.


Can't wait to see them in master!



But: Bidirectional grapheme iteration makes my eye twitch lol.


I did write a reverse grapheme iterator for Symmetry. It isn't fit for 
Phobos as-is since it only accepts UTF-8 strings (not other ranges) and 
is modeled after the Phobos grapheme walker, not the 15.0 standard. But 
I could ask for permission to give it to you if it'd help.


I probably won't be adding any new features to std.uni. Only finishing 
off the things that annoy me and reviewing other peoples work.


I've got enough on my plate just building my own "standard library" 
https://github.com/Project-Sidero/basic_memory :)

Re: Breaking news: std.uni changes!

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 03/01/2023 6:13 PM, H. S. Teoh wrote:

Is there a way to make these tables pay-as-you-go? As in, if you never
call a function that depends on a table, it would not be pulled into the
binary?


This should already be the case. I saw some stuff involving Rainer 10 
years ago who helped improve it along these lines.


The main concern would be shared libraries, which Phobos should be able 
to be distributed as on all platforms by all compilers.

Re: Breaking news: std.uni changes!

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 03/01/2023 10:24 AM, Dukc wrote:
Other things coming to mind: Bidirectional grapheme iteration, Word 
break and line break algorithms, lazy normalisation. Indeed, lots of 
improvement potential.


I've done word break, "lazy" normalization (so can stop at any point), 
and lazy case insensitive comparison with normalization.


But: Bidirectional grapheme iteration makes my eye twitch lol.

My main concern for adding new features is increasing the size of Phobos 
binary for the tables. Most people don't need a lot of these optional 
algorithms, but they do need things like casing to work correctly (which 
makes increased size worth it).

Re: DConf Online '22 Addendum: D-based Next Generation Hardware Description Language

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

I'm copying my explanation for why the dynamic library wasn't built from 
my comment on YouTube here for any future reader and hopefully for the 
presenter too:




The reason you didn't get the dynamic library is that it is in a 
different configuration than the one you built. You didn't need to 
modify the sourceLibrary configuration.


I.e.
$ dub build --config=vlangdynamiclib

Or

$ dub build --config=vlangstaticlib

The first configuration is the default, which happens to be 
vlangsourcelib. Hence the error.

Re: Beta 2.102.0

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

I'm not surprised.

I don't see any ``"libs": ["Xaudio2"]`` in audio or root dub files.

Re: Breaking news: std.uni changes!

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 28/12/2022 12:13 AM, Dukc wrote:
This is a big service for us at Symmetry. Getting Unicode support up to 
date was needed, we would have had to switch libraries at some point or 
update it ourselves. But now, nothing to do except perhaps dealing with 
a bit of breakage. Thank you!


I had no idea that this was becoming an issue for you guys. It wasn't in 
any of the meeting notes and I haven't seen it brought up anywhere. So 
if there is anything more like this, please talk about it!


I see it's not quite Unicode 15 though. `graphemeStride` does not take 
Emoji sequences and prepend characters into account. I'm going to 
contribute a bit now since it's holiday, and this is a good task for me. 
PR coming soon unless I run into issues!


Yeah, there will be tons of small stuff currently missed out due to such 
a big jump and of course ping me @rikkimax, when you have something to 
review.


Loads of other work available such as culling all the version specific 
information out of the docs :)