First things first

[quickfur]

Not 100% sure about this fork yet, but hoping this drastic action might lead to some positive change. So here goes: what are the first things that needs to be done for this thing to get off the ground?

1. Fix the CI scripts so that release builds work (from Adam).
2. ...?

[adamdruppe]

Oh good, this does email me. But yeah, need to get a process for people to use the language easily. Building releases from CI is probably the easiest way, but open to better ideas too.

Then, wanna get the library distribution done too, I have a list of old, rejected or stagnated PRs from upstream I wanna get right in and start testing, and I wanna write a new driver program to simplify tasks for the users - an updater driver, etc.

But once there's downloads available from github, writing a program to download updates from it is relatively straightforward, then merging PRs not too hard (however I don't know how the LDC process works - presumably, you apply the path to both repos... I wouldn't mind just merging the repos, but also want to keep it easy to pull from the other dlang organization if they do something that looks great), etc.

[andrey-zherikov]

Are github actions included in CI?

[quickfur]

Hmm, I just realized that it's still using the LDC team's phobos fork, which is based on upstream. Should we fork that phobos too, and point .gitmodules to the fork instead?

[adamdruppe]

oh yeah i did fork the phobos but didn't update the git submodule (i kinda hate git submodules). the sync with upstream script also needs ot use teh dmd fork

[quickfur]

argh i'm running into this github bogonity where it doesn't let you create two forks with the same upstream repo. I already have a fork of upstream phobos and now it refuses to let me create a separate fork of the forked phobos, even though it's possible to name the fork something other than phobos. Googling revealed that I need to create an Org for this... this is so silly.

[andrey-zherikov]

Is it possible that someone else forks a repo and then transfers it to you?

[quickfur]

Don't know, didn't try. This is a lot easier in git itself, don't understand why github imposed this artificial restriction.

[quickfur]

Are the CI actions working yet? We could close this if so.

[quickfur]

Well the goal was to make it an actual database, like maybe a sqlite3 lib, that you can actually install and use for real. Not just a toy example. Well maybe with only limited functionality for starters, but enough to actually write an app with. I think that will be much more convincing than a bunch of toy examples.

[adamdruppe]

That is a real database, you can use it with mysql, postgres, and sqlite. It is a thin wrapper for the arsd database lib.

[quickfur]

Oh cool. I'm tempted to post this on the upstream forum just to prove the point that the string interpolation tuple feature is extremely useful...

[adamdruppe]

I'd rather just focus on moving the language forward. When Walter and friends are ready to join us, we'll have seats saved at the table for them. But we're not gonna wait for them anymore.

[quickfur]

Given Walter's track record, I'm highly skeptical if he will ever join us. I hope he does, as that would be the best option for everyone, but I'm not holding my breath for it.

[trikko]

Is the released opend x.yy compiled with opend x.yy or with opend x.yy-1?

[adamdruppe]

idk i doubt it would matter much, the compiler code needs to be a bit conservative and not use bleeding edge features anyway.

[trikko]

But it can take advantage of new bug fixes and improvement on code generation (and, of course, it's a good way to test the new version itself).

Let's say the version 0.1000 improve code generation for loops by 2x with a magic optimization. If you compile opend 0.1000 with opend 0.999 it is still slow (but generate optimized code), and you have to wait for 0.1001. Compile 0.1000 with 0.1000 and you have all the optimizations available!

[adamdruppe]

yeah maybe but in most cases i just think it will double the time of the build for no benefit