Re: LDC 1.32.0-beta1

2023-02-27 Thread newbie via Digitalmars-d-announce

On Monday, 27 February 2023 at 23:45:18 UTC, kinke wrote:

Glad to announce the first beta for LDC 1.32. Major changes:

* Based on D 2.102.1+.
* LLVM for prebuilt packages bumped to v15.0.7.
* Linker-level dead code elimination is enabled by default for 
Apple, wasm and *all* ELF targets too now.
* Vector comparisons (==, !=, <, <=, >, >=) now yield a vector 
mask. Identity comparisons (`is`, `!is`) still yield a scalar 
`bool`.

* `-mabi` support for RISC-V targets. Thanks @zyedidia!

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.32.0-beta1


Please help test, and thanks to all contributors & sponsors!


find one error for musl + aarch64:

```sh
/ldc2/bin/../import/core/sys/posix/sys/stat.d(1659): Error: alias 
`core.sys.posix.sys.stat.__mode_t` conflicts with alias 
`core.sys.posix.sys.stat.__mode_t` at 
/ldc2/bin/../import/core/sys/posix/sys/stat.d(662)

```


Re: LDC 1.32.0-beta1

2023-02-27 Thread newbie via Digitalmars-d-announce

On Monday, 27 February 2023 at 23:45:18 UTC, kinke wrote:

Glad to announce the first beta for LDC 1.32. Major changes:

* Based on D 2.102.1+.
* LLVM for prebuilt packages bumped to v15.0.7.
* Linker-level dead code elimination is enabled by default for 
Apple, wasm and *all* ELF targets too now.
* Vector comparisons (==, !=, <, <=, >, >=) now yield a vector 
mask. Identity comparisons (`is`, `!is`) still yield a scalar 
`bool`.

* `-mabi` support for RISC-V targets. Thanks @zyedidia!

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.32.0-beta1


Please help test, and thanks to all contributors & sponsors!


Thanks for the great work, after upgraded without problem yet.


LDC 1.32.0-beta1

2023-02-27 Thread kinke via Digitalmars-d-announce

Glad to announce the first beta for LDC 1.32. Major changes:

* Based on D 2.102.1+.
* LLVM for prebuilt packages bumped to v15.0.7.
* Linker-level dead code elimination is enabled by default for 
Apple, wasm and *all* ELF targets too now.
* Vector comparisons (==, !=, <, <=, >, >=) now yield a vector 
mask. Identity comparisons (`is`, `!is`) still yield a scalar 
`bool`.

* `-mabi` support for RISC-V targets. Thanks @zyedidia!

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.32.0-beta1


Please help test, and thanks to all contributors & sponsors!


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread Mike Parker via Digitalmars-d-announce

On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote:



betterC is much more important for some user, please don't 
phase out `-betterC`.




BetterC isn’t going anywhere. Too many people use it.


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread bachmeier via Digitalmars-d-announce

On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote:

On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote:

On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

Razvan [submitted a PR deprecating `alias this` in 
classes](https://github.com/dlang/dmd/pull/14812) the next 
day. Amaury [initiated a forum 
discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later.


Is there a replacement?


Yes. And there always was: In classes this was only an 
additional way to do, what should better be done with 
inheritance.


That is not my understanding from the linked thread. For 
instance, someone said it can be used as a substitute for 
multiple inheritance. It seems that anyone using it that way 
would be losing working code for no reason due to this 
deprecation.


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread jmh530 via Digitalmars-d-announce

On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote:

On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote:

On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

Razvan [submitted a PR deprecating `alias this` in 
classes](https://github.com/dlang/dmd/pull/14812) the next 
day. Amaury [initiated a forum 
discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later.


Is there a replacement?


Yes. And there always was: In classes this was only an 
additional way to do, what should better be done with 
inheritance.


Generally speaking, I agree, but it does add a little bit of 
mental overhead for a user if they want to change from struct to 
class. Hopefully the error message of a class alias this points 
users in the direction of inheriting instead.


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread Dom Disc via Digitalmars-d-announce

On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote:

On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

Razvan [submitted a PR deprecating `alias this` in 
classes](https://github.com/dlang/dmd/pull/14812) the next 
day. Amaury [initiated a forum 
discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later.


Is there a replacement?


Yes. And there always was: In classes this was only an additional 
way to do, what should better be done with inheritance.


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread M.M. via Digitalmars-d-announce

On Monday, 27 February 2023 at 14:25:29 UTC, Adam D Ruppe wrote:

On Monday, 27 February 2023 at 14:18:04 UTC, M.M. wrote:
In the recent post by Mike Parker, betterC is used as a great 
alternative to C for writing bare-metal RISC-V application:


Real D can do this too.


Oh, that's a bit new information to me. But yes, I do not use 
betterC and I am not dlang-savvy, so happy to hear standard dlang 
can do as well.


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread ryuukk_ via Digitalmars-d-announce

On Monday, 27 February 2023 at 14:24:38 UTC, Adam D Ruppe wrote:

On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote:
with `betterC` you can target into new platform without much 
work, and easy to deal with dynamic library,  generate much 
fast and smaller binary.


you can do this without betterC too. often easier. And it could 
be even easier with a little bit of work that benefits 
everybody.


The custom runtime route is a mistake to expect from users, why 
should i manage all of this, it should just work, well you are 
forced because of X, Y, Z are not yet ported! so you cherry pick 
on a code basis, rather than on a feature basis


You'll also have to keep track of the compiler developments in 
case runtime hooks get changed, also if you are not careful about 
your implementation you have silent bugs (i had one with switch 
errors that was hard to track down, i had to copy/paste code from 
your repo)


With C/C++ and even Rust/Zig/Go(tinygo), you don't have that kind 
of problems


The bare is set by other languages already, -betterC is helping 
staying on buisness for that kind of purpose




Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread bachmeier via Digitalmars-d-announce

On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

Razvan [submitted a PR deprecating `alias this` in 
classes](https://github.com/dlang/dmd/pull/14812) the next day. 
Amaury [initiated a forum 
discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later.


Is there a replacement? If not, why is this even being discussed? 
I'm all for breaking changes if there's a benefit and an easy 
path to maintain the existing functionality. This fails on both 
counts. If you want to enforce that it's not used, add a flag, 
but don't take it away just for the sake of taking it away.


Martin suggested a fourth option: phase out `-betterC` because 
it's a "pile of hacks". Dennis considered that but thought 
BetterC users would not be happy when it gets deprecated 
without a suitable replacement.


If you don't like BetterC, don't use BetterC. It *already* 
requires a flag.


More generally, deprecation decisions like this shouldn't be made 
by a small group of people that write a tiny percentage of the D 
code running in the real world. That same process gave us a safe 
by default proposal that would have made it impossible to 
interoperate with C code.


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread Adam D Ruppe via Digitalmars-d-announce

On Monday, 27 February 2023 at 14:18:04 UTC, M.M. wrote:
In the recent post by Mike Parker, betterC is used as a great 
alternative to C for writing bare-metal RISC-V application:


Real D can do this too.

betterC needs to die, it is just arbitrary special cases that add 
tech debt to the compiler and distract from D's real capabilities.


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread Adam D Ruppe via Digitalmars-d-announce

On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote:
with `betterC` you can target into new platform without much 
work, and easy to deal with dynamic library,  generate much 
fast and smaller binary.


you can do this without betterC too. often easier. And it could 
be even easier with a little bit of work that benefits everybody.


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread ryuukk_ via Digitalmars-d-announce
I use -betterC because i can focus on the language and build upon 
it, i don't have to deal with the slowness of phobos and more 
importantly, i don't have to wait for phobos or druntime to be 
ported to WASM in order to be able to target to WASM, i target 
WASM today


It also makes me confident that none of my game code will 
accidentally call the GC, as i banned the use of the GC for this 
particular project (game)


I can focus on what i love about C with the greatness of D (the 
language)


My project fully recompile (clean build, game+engine) in just 
1.2s, thanks Walter!


The only complain i have about betterC, and D in general are the 
error messages, sometimes just having new lines with proper 
spacing makes errors easier to read, i made a comment in one 
PR(related to improving betterC error message) that it was 
helpful and very much welcome, so looks like things are going to 
improve



Walter decided to put the Sum Types proposal aside for now


That's super sad to hear.. i was eagerly hoping tagged union 
would come sooner rather than later.. it's one feature that 
enables writing useful with less noise


I want to replace that kind of ugly code that i have, notice how 
easy it is to have bugs if you are not careful what field you 
use, not safe!: (no, template is not the solution)


```D
enum EventType: ubyte
{
QUIT,

GFX_RESIZE,

INPUT_KEY_DOWN,
INPUT_KEY_UP,
INPUT_KEY_TYPED,
INPUT_TOUCH_DOWN,
INPUT_TOUCH_UP,
INPUT_TOUCH_DRAGGED,
INPUT_MOUSE_MOVED,
INPUT_SCROLLED,
}

struct Event
{
long time;
bool consumed;

EventType type;
union
{
// GFX
Resize resize;

// INPUT
KeyDown key_down;
KeyUp key_up;
KeyTyped key_typed;
TouchDown touch_down;
TouchUp touch_up;
TouchDragged touch_dragged;
TouchMoved touch_moved;
Scrolled scrolled;
}
}


(..)


// update key state
foreach(Event* e; engine.queue)
{
if (e.consumed) continue;

switch (e.type) with (EventType)
{
case INPUT_KEY_DOWN:
switch(e.key_down.key)
{
(..)
}
break;
case INPUT_KEY_UP:
switch(e.key_up.key)
{
(..)
}
break;

case INPUT_TOUCH_DOWN:
if (e.touch_down.button == 1)
(..)
break;
case INPUT_TOUCH_UP:
if (e.touch_up.button == 1)
(..)
break;

default:break;
}
}


```

I think expecting users to ask for new features shouldn't be seen 
as something bad


It's great to have people discuss language improvement, it gives 
the ability to talk about and remind people about existing 
features, and potentially their issues



And what a better opportunity than to remind ones who think bugs 
in weird and cryptic corner cases, is what turn off people


What turn me off from D is that kind of issues: 
https://github.com/dlang/dub/issues/2600


When you start to import things from the std and it makes your 
compile time go from 5seconds (already an eternity) to 10 
seconds, and people think "it's not a problem"


tagged union would help reduce the code complexity, template 
usage and bugs by a significant amount of time, as well as 
improving error messages 
https://forum.dlang.org/thread/zsxipgibubqgnwwwx...@forum.dlang.org


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread M.M. via Digitalmars-d-announce

On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:

...
### Dennis
Dennis asked about the future direction of `-betterC`...

... He then listed three possible approaches:
* Explicitly annotate code as CTFE-only with new syntax: 
`pragma(ctfe)`, `if (ctfe)` etc. Walter noted that the syntax 
is an extra `()`.
* Implicitly make functions using DRuntime features as 
CTFE-only. This might be surprising and unintuitive
* Generate run-time errors instead of compile-time errors. This 
makes errors easier to slip by.


Martin suggested a fourth option: phase out `-betterC` because 
it's a "pile of hacks"...


As a final question, Dennis asked what the "official" intended 
use for BetterC was in the first place: just a C migration tool 
or also something for new D code. I said `-betterC` shouldn't 
be used for writing new code. Walter said it can be used for 
whatever calls for it, be it integrating with C, targeting 
embedded systems, or any scenario where you don't want to link 
DRuntime.

...


In the recent post by Mike Parker, betterC is used as a great 
alternative to C for writing bare-metal RISC-V application:


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


Re: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread 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: D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread newbie via Digitalmars-d-announce

On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote:
The January meeting took place on January 13th at 14:00 UTC. It 
was a quarterly meeting, which means we invited representatives 
from companies using D in production. We normally would have 
scheduled it on the first Friday of the month, but delayed it a 
bit to allow everyone time to return and/or recover from the 
holiday period. The meeting lasted around 2.5 hours.


[...]



betterC is much more important for some user, please don't phase 
out `-betterC`.


with `betterC` you can target into new platform without much 
work, and easy to deal with dynamic library,  generate much fast 
and smaller binary.





D Language Foundation February 2023 Monthly Meeting

2023-02-27 Thread Mike Parker via Digitalmars-d-announce
The February meeting took place on February 3rd, 2023, at 15:00 
UTC. The following people attended:


* Walter Bright
* Iain Buclaw
* Ali Çehreli
* Martin Kinkelin
* Dennis Korpel
* Mathias Lang
* Átila Neves
* Razvan Nitu
* Mike Parker
* Robert Schadek

The meeting lasted just under 50 minutes. We don't normally 
constrain the duration of our meetings, but this time we had to 
keep it under an hour because we had another one scheduled at 
16:00 UTC. We've been having weekly meetings every Friday since 
late January. I'll be able to talk about those at some point, but 
not just yet.


## The summary

### Me
I opened the meeting by letting everyone know that Ikey Doherty 
of the SerpentOS project was scheduled to join us for our next 
meeting. We'll still be having our weekly meetings in March, so 
to make sure Ikey has enough time to address us, we should start 
our March meeting at 14:30.


Later, I talked about videos. The DConf Online 2020 & 2021 videos 
I've rendered have all used the H.264 encoding, as that's what my 
editor supported at the time. I have a different editor now, but 
I still rendered the DConf Online '22 videos in the same 
encoding. I believe videos from the last three DConf editions are 
also encoded in H.264, and I don't know yet about the older ones.


Now that we're storing our videos on Backblaze, I've begun 
rerendering them as H.265 to cut down the file sizes. Our monthly 
Backblaze bill for storing all the videos and the compiler 
downloads archive is less than $3.00, so it's not like we're 
paying a lot. But every penny saved counts.


### Mathias
Mathias had recently been using D for scripting a web interface. 
He's missing the ease of use of having a lot of things in the 
standard library. We have an okay JSON package. That makes a 
world of difference, but if you have to do something with, e.g., 
YAML, you have to take the extra step of searching for a library. 
He thinks we should discuss bringing more things into the 
standard library.


Robert agreed. Specifically, regarding text file formats, he 
thinks we should have a package that supports multiple formats 
with a somewhat standardized API. YAML, SDLang, XML, and JSON 5 
would be a good start.


### Razvan
Razvan informed us that the deadline for GSoC applications was 
coming up. He still needed a list of potential projects and 
potential mentors. [Our projects 
repository](https://github.com/dlang/projects) contains several 
ideas, but not all of them are suitable for GSoC. He suggested 
selecting four or five for the application. In 2021, we submitted 
a link to the project ideas repository. He felt that might have 
harmed our prospects, and thinks they were expecting a distilled 
page of more organized project ideas. He wanted to make sure 
Walter and Átila are okay with whatever projects we add to that 
list.


Robert suggested an email discussion to settle on projects. He 
proposed the text format package as a potential project, and 
Átila gave this thumbs up. The final list of projects Razvan 
submitted is at https://github.com/dlang/projects/pulls. 
Ultimately, our application was rejected.


### Dennis
Dennis reported on his pull request adding named arguments for 
functions. Walter hadn't yet responded to a ping, so Dennis asked 
if he could look at it. Walter subsequently did so, Dennis 
addressed his feedback, and [the PR was 
merged](https://github.com/dlang/dmd/pull/14575).


### Robert
Robert had nothing to report other than his usual complaint that 
the compiler is too slow.


Walter asked if he was using `fullyQualifiedName`. Robert said 
yes, but that's not the problem. It's templates in general. It's 
not that template usage in Phobos is the problem, it's that the 
compiler is too slow in compiling them. Walter noted 
`fullyQualifiedName` triggered a chain of instantiations. [He had 
a PR to replace it](https://github.com/dlang/dmd/pull/14711) with 
a new `__traits`. He suggested Robert see how that impacted his 
compile times. Robert said he had looked at the instantiations in 
his compiles and expected he wouldn't even notice it. That said, 
he thinks `__traits` and `std.traits` are critical for 
metaprogramming and he thinks the PR is a good idea.


Walter doesn't think there's one single solution to speeding up 
template processing. He's implemented several optimizations in 
the past that have sped up things like, e.g., the `AliasSequence` 
template, and he's always looking for other opportunities to 
enhance template processing performance. Robert noted how we had 
discussed the topic [in our December 
meeting](https://forum.dlang.org/thread/uhcopuxrlabibmgrb...@forum.dlang.org). He thinks the main issue is separate compilation units. He emphasized that compiling source should no longer be seen as batch processing. It's an interactive game today.


Other than that, he says D is still the best language.

Razvan asked him about the status of the Bugzilla->GitHub 
migration. Robert said he still 

D Language Foundation January 2023 Quarterly Meeting Summary

2023-02-27 Thread Mike Parker via Digitalmars-d-announce
The January meeting took place on January 13th at 14:00 UTC. It 
was a quarterly meeting, which means we invited representatives 
from companies using D in production. We normally would have 
scheduled it on the first Friday of the month, but delayed it a 
bit to allow everyone time to return and/or recover from the 
holiday period. The meeting lasted around 2.5 hours.


Unfortunately, I overlooked that audio output was disabled on OBS 
Studio when I recorded the meeting. I can hear myself, but no one 
else. All the good stuff was said by everyone else. I enlisted 
the help of some of the other attendees in recalling what we 
discussed. So what follows is a very light summary of a rather 
long meeting, cobbled together from the memories of a few 
different people several days after. I did not get input from 
everyone who attended the meeting, so I welcome any of them to 
fill in any additional gaps they may remember.


The following people attended (those with DLF next to their names 
are either D Language Foundation board members, paid employees, 
or affiliated volunteers):


* Walter Bright (DLF)
* Iain Buclaw (GDC/DLF)
* Ali Çehreli (DLF/Mercedes Benz R & D North America)
* John Colvin (Symmetry)
* Martin Kinkelin (DLF/LDC)
* Dennis Korpel (DLF)
* Mario Kröplin (Funkwerk)
* Max Haughton (DLF/Symmetry)
* Mathias Lang (DLF/Symmetry)
* Razvan Nitu (DLF)
* Mike Parker (DLF)
* Robert Schadek (DLF/Symmetry)
* Amaury Séchet (Symmetry)
* Robert Toth (Ucora)
* Bastiaan Veelo (SARC)

## The summary

### Mathias, Martin, Robert T., Iain, Max, and Ali
Robert said he was there to listen this time, but he did 
contribute throughout. Martin had not had any time since the last 
meeting to prepare the next LDC release. Iain, Max, Mathias, and 
Ali simply had nothing to report. I joked with Mathias that I was 
glad I was recording it (he usually has more than one thing to 
report, and often brings up something else at the end when I ask 
if anyone has anything else). Next time, I should knock on wood.


### Robert S.
Robert gave an update on the Bugzilla-GitHub migration. He 
provided some details about its current state and hoped it would 
be ready to use by the end of the month. I asked if, when the 
time comes, I should just let it run on a VPN rather than my PC. 
He said that because of the GitHub API's rate limit, it shouldn't 
hurt to let it run on my PC. There were then some questions about 
details, e.g., should the script include only Bugzilla numbers in 
the migrated issues or link to the original, and I mentioned we 
should get in touch with Brad Roberts to set the Bugzilla into 
read-only mode. (This came up again in our February meeting three 
weeks later.)


Robert had already migrated the tools repository issues, so if 
anyone wants to see what that looks like they can now. [All of 
the issues from the author 
`dlang-bugzilla-migration`](https://github.com/dlang/tools/issues?q=is%3Aissue+is%3Aopen+author%3Adlang-bugzilla-migration+sort%3Aupdated-desc) were migrated from Bugzilla.


### Bastiaan
Bastiaan had encountered an issue on his project at work related 
to the DMD installer on Windows. The installer has the option to 
add the compiler's path to the `PATH` environment variable, but 
checking it causes it to add the path to the 32-bit compiler even 
on 64-bit systems. This came to their attention when DMD suddenly 
started running out of memory when compiling their code base but 
was only using 4GB. [He filed an 
issue](https://issues.dlang.org/show_bug.cgi?id=23623) and 
[submitted a fix](https://github.com/dlang/installer/pull/555). 
Now, the installer with 2.102.0 will set properly the path to the 
64-bit compiler on 64-bit systems.


He also brought up a nearly year-old regression with dub related 
to `$PACKAGE_DIR` and the `sourceLibrary` package type. This was 
initially an annoyance for them but has become a blocker 
preventing them from upgrading the compiler since 2.100.0.S Jan 
Jurzita did some work on it last year, but it's still open as I 
write this summary. I've pinged Mathias and Jan to see if they 
can get it resolved.


### John and Amaury
In the summary of our December meeting, you can read [Robert 
Schadek's report](https://github.com/dlang/installer/pull/555) of 
a Symmetry programmer who moved from D to C# for an internal 
project, as well as some of Robert's own frustrations. John came 
to us in this meeting to expand on that and asked Amaury along to 
provide his perspective.


This was a very long, very heavy discussion. Even if I did have 
the audio, there's no way I could reasonably cover in detail 
everything that we discussed. You can get the main thrust of the 
topic from [a forum post John wrote 
up](https://forum.dlang.org/post/xamclovgxzzrjznte...@forum.dlang.org) at the beginning of last December in response to Walter's request for feedback on a Sum Types proposal. Essentially, he's concerned that we keep moving on with new features while there are fundamental problems 

Re: Google Summer of Code -- We didn't make it

2023-02-27 Thread M.M. via Digitalmars-d-announce

On Monday, 27 February 2023 at 00:11:49 UTC, Mike Parker wrote:
Unfortunately, our application to Google Summer of Code was not 
accepted this year.




Yeah, that's unfortunate. I think that Google Summer of Code 
would be an important showcase  to the outside world. Hopefully 
dlang can make it next year.


Re: Beerconf February 2023

2023-02-27 Thread Sergey via Digitalmars-d-announce

On Sunday, 26 February 2023 at 17:16:48 UTC, Dan wrote:
On Saturday, 11 February 2023 at 16:05:39 UTC, Steven 
Schveighoffer wrote:

# BEERCONF!


Thanks everyone for presenting talks and demos!