Re: Is D programming friendly for beginners?
On Monday, 11 March 2024 at 12:30:10 UTC, Doigt wrote: On Monday, 4 March 2024 at 13:37:53 UTC, Fidele wrote: I want to start learning D programming language it looks interesting Depends what you mean by "beginner". If you've never programmed before and D is your first language, then the answer is a definite no. Why definitely not? https://youtu.be/V2YwTIIMEeU?si=j3cQzzN4jsUQrN9C=682 -- Bastiaan.
Re: Fluid 0.6.0 — UI library for D
On Wednesday, 31 January 2024 at 06:38:17 UTC, aberba wrote: On Thursday, 25 January 2024 at 12:33:31 UTC, cookiewitch wrote: Fluid is a library I started developing 3 years ago when I joined the D community, after failing to find a suitable library for my gamedev project. [...] Could you have a small documentation website? Could even be based on something like GitHub pages or readthedocs (https://readthedocs.io). There is this https://fluid.dpldocs.info/v0.6.1/fluid.html and https://fluid.dpldocs.info/v0.6.1/fluid.showcase.html. -- Bastiaan.
Re: Upcoming talk at FOSDEM 2024 - The D Programming Language for Modern Open Source Development
On Monday, 15 January 2024 at 00:49:25 UTC, matheus wrote: On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote: Hi D Community, My talk on how I'm using the D programming language and why I think it is an excellent language choice for open source projects will be featured at FOSDEM 2024 at the start of February 2024 in Brussels, Belgium. Look out for the official talk schedule(in the Main Track) here: https://fosdem.org/2024/schedule/events/ [...] Hi Mike are you sure the link is right, or you're on that list? - I tried "D Programming", your name (And only Surname) but I couldn't find anything. This is the link: https://fosdem.org/2024/schedule/event/fosdem-2024-2092-the-d-programming-language-for-modern-open-source-development/ -- Bastiaan.
Re: Upcoming talk at FOSDEM 2024 - The D Programming Language for Modern Open Source Development
On Monday, 15 January 2024 at 00:49:25 UTC, matheus wrote: On Sunday, 14 January 2024 at 23:16:40 UTC, Mike Shah wrote: Hi D Community, My talk on how I'm using the D programming language and why I think it is an excellent language choice for open source projects will be featured at FOSDEM 2024 at the start of February 2024 in Brussels, Belgium. [...] Look out for the official talk schedule(in the Main Track) here: https://fosdem.org/2024/schedule/events/ Hi Mike are you sure the link is right, or you're on that list? The main track in that link is still empty. Here is a link for just the main track, also empty: https://fosdem.org/2024/schedule/track/main/ You'd think the main track has been finalized by now (it is only 18 days until the start of the conference) and since all other rooms have plenty of entries already, this list being empty seems like a malfunction to me. -- Bastiaan.
Re: Beta 2.107.0
On Tuesday, 2 January 2024 at 12:49:51 UTC, Iain Buclaw wrote: http://dlang.org/changelog/2.107.0.html **@standalone** is a new attribute that can be used to mark module constructors that run after druntime has been initialized, but do not depend on any other module constructors being run before it, so it will not cause a cyclic dependency error. Nice!! --Bastiaan.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Monday, 11 December 2023 at 19:55:38 UTC, Timon Gehr wrote:
... this successfully injects alloca into the caller's scope.
```d
import core.stdc.stdlib:alloca;
import std.range:ElementType;
import core.lifetime:moveEmplace;
struct VLA(T,alias len){
T[] storage;
this(R)(R initializer,return void[]
storage=alloca(len*T.sizeof)[0..len*T.sizeof]){
this.storage=cast(T[])storage;
foreach(ref element;this.storage){
assert(!initializer.empty);
auto init=initializer.front;
moveEmplace!T(init,element);
initializer.popFront();
}
}
ref T opIndex(size_t i)return{ return storage[i]; }
T[] opSlice()return{ return storage; }
}
auto vla(alias len,R)(R initializer,void[]
storage=alloca(len*ElementType!R.sizeof)[0..len*ElementType!R.sizeof]){
return VLA!(ElementType!R,len)(initializer,storage);
}
void main(){
import std.stdio,std.string,std.conv,std.range;
int x=readln.strip.to!int;
writeln(vla!x(2.repeat(x))[]);
}
```
You guys are great!
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Sunday, 10 December 2023 at 22:59:06 UTC, Nicholas Wilson wrote: Always happy to help if you're interested in looking into using dcompute. Thank you, I'll let you know! Or you could use grep with `--output-ll` as noted by Johan https://github.com/ldc-developers/ldc/issues/4265#issuecomment-1376424944 although this will be with that `workaroundIssue1356` applied. Thanks for highlighting this, as I must have forgotten. I should be able to create a CI job that checks this as part of the release. This will give us the confidence that we need. -- Bastiaan.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Sunday, 10 December 2023 at 18:16:05 UTC, Nick Treleaven wrote: You can call `alloca` as a default argument to a function. The memory will be allocated on the caller's stack before calling the function: https://github.com/ntrel/stuff/blob/master/util.d#L113C1-L131C2 I've just tested and it seems it works as a constructor default argument too. Clever!
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Sunday, 10 December 2023 at 17:11:04 UTC, Siarhei Siamashka wrote: On Sunday, 10 December 2023 at 15:08:05 UTC, Bastiaan Veelo wrote: The compiler can check if `scope` delegates escape a function, but it only does this in `@safe` code --- and our code is long from being `@safe`. So it was a bit of a puzzle to find out which arguments needed to be `scope` and which arguments couldn't be `scope`. This reminded me of https://forum.dlang.org/thread/myiqlzkghnnyykbyk...@forum.dlang.org LDC has a special GC2Stack IR optimization pass, which is a lifesaver in many cases like this. Interesting. Are there some known blocker bugs, which prevent a safe usage of LDC in production? This one: https://github.com/ldc-developers/ldc/issues/4265 Mike has summarized it: LDC unfortunately had an issue that caused stack corruption on 32-bit Windows. They'd hit it in one case and were able to work around it, but he couldn't be sure they wouldn't hit it somewhere else. He wasn't willing to risk unreliable computations. He said that LDC could do the right thing, but his understanding from talking to Martin was that implementing it would have a large time cost. Since Win32 is going to eventually go away, he wasn't very keen on paying that cost. They'd spoken at DConf about the possibility of LDC raising compilation errors when stack corruption could occur so that they could then work around those cases, but he hadn't followed up with Martin about it. -- Bastiaan.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Sunday, 10 December 2023 at 15:31:55 UTC, Richard (Rikki) Andrew Cattermole wrote: 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. Yes, dcompute could mean another leap forward. There are so many great things to look forward to. -- Bastiaan.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On Wednesday, 6 December 2023 at 16:28:08 UTC, Mike Parker wrote: Bastiaan reported that SARC had been testing their D codebase (transpiled from Pascal---[see Bastiaan's DConf 2019 talk](https://youtu.be/HvunD0ZJqiA)). They'd found the multithreaded performance worse than the Pascal version. He said that execution time increased with more threads and that it didn't matter how many threads you throw at it. It's the latter problem he was focused on at the moment. I have an update on this issue. But first let me clarify how grave this situation is (was!) for us. There are certain tasks that we, and our customers, need to perform that involves a 20 logical core computer to crunch numbers for a week. This is painful, but it also means that a doubling of that time is completely unacceptable, let alone a 20-fold increase. It is the difference between in business and out of business. Aside from the allocation issue, there are several other properties that our array implementation needs to replicate from Extended Pascal: being able to have non-0 starting indices, having value semantics, having array limits that can be compile-time and run-time, and function arguments that must work on arrays of any limits, also for multi-dimensional arrays. So while trying to solve one aspect, care had to be taken not to break any of the other aspects. It turned out that thread contention had more than one causes, which made this an extra frustrating problem because just as we thought to have found the culprit, it did not have the effect that we expected. These were the three major reasons we were seeing large thread contention, in no particular order: 1) Missing `scope` storage class specifiers on `delegate` function arguments. This can be chalked down as a beginner error, but also one that is easy to miss. If you didn't know: without `scope` the compiler cannot be sure that the delegate is not stored in some variable that has a longer lifetime than the stack frame of the (nested) function pointed to by the delegate. Therefore, a dynamic closure is created, which means that the stack is copied to new GC-allocated memory. In the majority of our cases, delegate arguments are simple callbacks that are only stored on the stack, but a select number of delegates in the GUI are stored for longer. The compiler can check if `scope` delegates escape a function, but it only does this in `@safe` code --- and our code is long from being `@safe`. So it was a bit of a puzzle to find out which arguments needed to be `scope` and which arguments couldn't be `scope`. 2) Allocating heap memory in the array implementation, as discussed in the meeting. We followed Walter's advice and now use `alloca`. Not directly, but using string mixin's and static member functions that generate the appropriate code. 3) Stale calls to `GC.addRange` and `GC.removeRange`. These were left over from an experiment where we tried to circumvent the garbage collector. Without knowing these were still in there, we were puzzled because we even saw contention in code that was marked `@nogc`. It makes sense now, because even though `addRange` doesn't allocate, it does need the global GC lock to register the range safely. Because the stack is already scanned by default, these calls were now superfluous and could be removed. So now all cores are finally under full load, which is a magnificent sight! Speed of DMD `release-nobounds` is on par with our Pascal version, if not slightly faster. We are looking forward to being able to safely use LDC, because tests show that it has the potential to at least double the performance. A big sigh of relief from us as we have solved the biggest hurdle (hopefully!) on our way to full adoption of D. -- Bastiaan.
Re: New DUB documentation
On Friday, 24 November 2023 at 11:11:53 UTC, BoQsc wrote: Darker blending indistinct colors (dark red, dark background), way smaller fonts. I see your screenshots, but that is not what it looks like for me in Chrome on Windows. I am seeing black text on white background with red links. Pretty much like the rest of the D web ux. Is there a dark theme you have enabled? The font does look slightly smaller, though. -- Bastiaan.
Re: New DUB documentation
On Wednesday, 22 November 2023 at 21:35:34 UTC, WebFreak001 wrote: the revamped DUB documentation I started a while ago is now deployed on https://dub.pm This is very much appreciated. A job well done! -- Bastiaan.
Re: Beta 2.103.0
On Thursday, 2 March 2023 at 16:40:12 UTC, jmh530 wrote: Any reason why it doesn't match the options from DMD? See the [changelog](https://dlang.org/changelog/2.103.0.html#colors): The previous **automatic**, **on**, **off** values are still supported, but undocumented, because they are used in almost no other program like this. For consistency, with other Linux tools especially, we have implemented and switched the defaults to the widely-used **auto**, **never**, **always** values.
Re: Safer Linux Kernel Modules Using the D Programming Language
On Thursday, 5 January 2023 at 20:24:07 UTC, Alexandru Militaru wrote: Hi everyone, If you remember the "D for a @safer Linux Kernel“ talk from DConf 2019 [1], then you might want to read our paper [2] on that matter that was just published in IEEE Access Journal. [1] https://youtu.be/weRSwbZtKu0 [2] https://ieeexplore.ieee.org/document/9987502 Kudos to you for staying on the ball on this topic. I enjoyed your talk back then and this article adds credibility to this important application of the language and addresses a wider audience. Well done. Bastiaan.
Re: Beta 2.102.0
On Monday, 2 January 2023 at 12:21:43 UTC, Hipreme wrote: `pragma(lib)` seems to be broken Can you file an issue for this please, if you've not done so yet? https://dlang.org/bugstats.html -- Bastiaan.
Re: D Language Foundation October 2022 Quarterly Meeting Summary
On Wednesday, 2 November 2022 at 18:20:42 UTC, H. S. Teoh wrote: On Wed, Nov 02, 2022 at 06:11:12PM +, M. M. via Digitalmars-d-announce wrote: Thank you to Martin Nowak for all his as release manager. Happy to hear that someone like Ian took over. I'm just curious why Martin stepped down. If he doesn't mind sharing the reason. From what I've heard, Martin started his own business, which takes up all his time. Wishing you success, Martin! -- Bastiaan.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: This summary is quite a bit overdue. Sorry for the delay. Thanks for this, and for keeping all the details. Good work! — Bastiaan.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 11:04:45 UTC, Steven Schveighoffer wrote: On 8/28/22 6:37 AM, Mike Parker wrote: SARC has marked a major milestone in that their 500KLOC Extended Pascal codebase has been completely transcompiled to D This is awesome! I remember that talk, and it was very interesting. Congratulations! -Steve Thank you! The process takes several times longer than anticipated, but we are not giving up :-) Although it is an important milestone, it doesn’t mean we can now all code in D. Almost all commits still happen in Pascal. I have started transpiling every commit separately, to create a commit history in D that overlaps the Pascal history for some period. Next week we plan on using the D versions of our software internally, to expose a larger surface area to testing and scrutiny. This is arguably a bigger milestone. What we all look forward to the most is the last milestone though, where we’ll freeze the Pascal repository and switch from programming in Pascal to programming in D overnight. — Bastiaan.
Re: New WIP DUB documentation
On Thursday, 18 August 2022 at 14:00:38 UTC, Martin Tschierschke
wrote:
What about the following idea about **comments for dub.json**:
Allow the key "comment" inside the json file and alter DUB to
remove all "comment" key value pairs at the beginning of
parsing.
So the file is still valid json but comments are possible like
in dub.sdl.
```
{
"comment" : "dub.json can contain comments,too!",
"name": "myproject",
"description": "A little web service of mine.",
"authors": ["Peter Parker", "John Doe"],
"homepage": "http://myproject.example.com;,
"license": "GPL-2.0",
"dependencies": {
"vibe-d": "~>0.9.5"
}
}
```
That's already possible, as unrecognised items are ignored. This
is however not flexible enough, as comments are not so much
wanted for adding explanations but much more for commenting out
specific parts. It does work sometimes: you can for example
disable `preBuildCommands` by editing it to
`preBuildCommandsDISABLED`. I don't think you can comment out a
dependency this way, and you cannot comment out an item from an
array like
```json
{
"preBuildCommands": [
"step one",
#"step two",
"step three"
]
}
```
-- Bastiaan.
Re: New WIP DUB documentation
On Monday, 15 August 2022 at 21:32:23 UTC, WebFreak001 wrote: Hi all, I'm currently working on new revamped DUB documentation, check it out if you want, it currently contains most old documentation plus a big bunch of new documentation: https://docs.webfreak.org/ Thank you for doing this! Not sure if this would be the right place, or if it is addressed already, but I repeatedly find myself looking for the right way to use a local checkout of a package instead of the dub registry, because I keep forgetting. It would be nice to have a section like (assuming I got it right): ## Hacking on a local copy of a package If your project depends on a package in which you have found a problem, or you would like to experiment with changes to it, you can force Dub to use a local copy of the package by following these steps: 1. Fork the git repository 2. Check out a local clone at `/path/to/the_package` 3. Let Dub know about it: `dub add-local /path/to/the_package` 4. Make Dub ignore any configured release tag, so you'll see the effect of current changes: `dub add-override the_package * /path/to/the_package` Now you can go ahead and play. Once your PR has been merged and released, or you want to revert to upstream, undo your changes by 5. `dub remove-local /path/to/the_package` 6. `dub remove-override the_package *` -- Bastiaan.
Re: DConf '22 Livestream Links
On Monday, 1 August 2022 at 12:45:56 UTC, Matheus wrote: On Monday, 25 July 2022 at 13:52:51 UTC, Mike Parker wrote: For those of you who can't join us in person at DConf '22 in London next week, you can join us instead via each day's livestream link: * Day 1: https://youtu.be/V6KFtzF2Hx8 Anyway I accessed the link and I don't know if it is a youtube limit, but as far I can go back, it starts with Walter talking about Octals. Was it the first part missing or is it a limit? The first part is missing due to a late click on the “go live” button. I assume the footage is still recorded, and will be part of the edited video. — Bastiaan.
Re: [i18n] Gettext 1.0.1 released
On Tuesday, 19 July 2022 at 20:20:29 UTC, Ogi wrote: Is this tested on Windows? Yes, it is developed on Windows. Do the included tests work for you? ``` Target is a library. Skipping execution. ``` That is not right. Are you developing a library or an application? If you cannot get it to work, feel free to [open an issue](https://github.com/veelo/gettext/issues) and include your `dub.json`. -- Bastiaan.
Re: Blog post on extending attribute inference to more functions
On Sunday, 17 July 2022 at 18:33:47 UTC, AnimusPEXUS wrote: I've just coded something and come with the idea of @todo/@fixme/@issueid attributes, so compiler write messages each time it finds those. Just as a thought.. maybe It can be useful, although it's already can be done with pragma(msg, "txt").. I abuse `@deprecated` for that purpose in my own code, to remind myself of some holes that need patching. — Bastiaan.
[i18n] Gettext 1.0.1 released
Two years ago, H. S. Teoh presented a proof of concept for
[automatic extraction of gettext-style translation
strings](https://forum.dlang.org/post/mailman.2526.1585832475.31109.digitalmar...@puremagic.com). I recently combined that idea with the existing [mofile](https://code.dlang.org/packages/mofile) package for reading translation tables in GNU gettext format, and the result is a feature rich solution for the support of multiple natural languages in D applications: https://code.dlang.org/packages/gettext. Perhaps not surprisingly, it can do more than GNU gettext itself.
I'd like to thank Steven Schveighoffer and Adam Ruppe for
[valuable forum
assistance](https://forum.dlang.org/post/afkbwsdrspndwgkai...@forum.dlang.org), and SARC B.V. for sponsoring. Some extracts from the [readme](https://github.com/veelo/gettext#readme) are included below:
# Features
- Concise translation markers that can be aliased to your
preference.
- All marked strings that are seen by the compiler are extracted
automatically.
- All (current and future) [D string literal
formats](https://dlang.org/spec/lex.html#string_literals) are
supported.
- Static initializers of fields, constants, immutables, manifest
constants and anonimous enums can be marked as translatable (a D
specialty).
- Concatenations of translatable strings, untranslated strings
and single chars are supported, even in initializers.
- Arrays of translatable strings are supported, also when
statically initialized.
- Plural forms are language dependent, and play nice with format
strings.
- Multiple identical strings are translated once, unless they are
given different contexts.
- Notes to the translator can be attached to individual
translatable strings.
- Code occurrences of strings are communicated to the translator.
- Available languages are discovered and selected at run-time.
- Platfom independent, not linked with C libraries.
- Automated generation of the translation table template.
- Automated merging into existing translations (requires [GNU
`gettext` utilities](https://www.gnu.org/software/gettext/)).
- Automated generation of binary translation tables (requires
[GNU `gettext` utilities](https://www.gnu.org/software/gettext/)).
- Includes utility for listing unmarked strings in the project.
# Usage
## Marking strings
Prepend `tr!` in front of every string literal that needs to be
translated. For instance:
```d
writeln(tr!"This string is to be translated");
writeln("This string will remain untranslated.");
```
## Plural forms
Sentences that should change in plural form depending on a number
should supply both singlular and plural forms with the number
like this:
```d
// Before:
writefln("%d green bottle(s) hanging on the wall", n);
// After:
writeln(tr!("one green bottle hanging on the wall",
"%d green bottles hanging on the wall")(n));
```
Note that the format specifier (`%d`, or `%s`, etc.) is optional
in the singular form.
Many languages have not just two forms like the English language
does, and translations in those languages can supply all the
forms that the particular language requires. This is handled by
the translator, and is demonstrated in [the example
below](https://github.com/veelo/gettext#example-1).
## Custom markers
If `tr` is too verbose for you, you can change it to whatever you
want:
```d
import gettext : _ = tr;
writeln(_!"No green bottles...");
```
## Marking format strings
Translatable strings can be format strings, used with
`std.format` and `std.stdio.writefln` etc. These format strings
do support plural forms, but the argument that determines the
form must be supplied to `tr` and not to `format`. The
corresponding format specifier will not be seen by `format` as it
will have been replaced with a string by `tr`. Example:
```d
format(tr!("Welcome %s, you may make a wish",
"Welcome %s, you may make %d wishes")(n), name);
```
The format specifier that selects the form is the last specifier
in the format string (here `%d`). In many sentences, however, the
specifier that should select the form cannot be the last. In
these cases, format specifiers must be given a position argument,
where the highest position determines the form:
```d
foreach (i, where; [tr!"hand", tr!"bush"])
format(tr!("One bird in the %1$s", "%2$d birds in the
%1$s")(i + 1), where);
```
Again, the specifier with the highest position argument will
never be seen by `format`. On a side note, some translations may
need a reordering of words, so translators may need to use
position arguments in their translated format strings anyway.
Note: Specifiers with and without a position argument must not be
mixed.
## Concatenations
Translators will be able to produce the best translations if they
get to work with full sentences, like
```d
auto message = format(tr!`Could not open the file "%s" for
reading.`, file);
```
However, in support of legacy code, concatenations of strings do
Re: How do I download the Windows DMD installer?
On Sunday, 17 July 2022 at 19:58:03 UTC, LeMondaide wrote: When I try (https://dlang.org/ or https://dlang.org/download.html) I am sent here: https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2022/dmd-2.100.1.exe and get this message "AccessDeniedAccess Denied4TMZ12PKCBCER6SAQQ7FpshcuoQ3ied0qGEHZ+lSz+qD9+aJmqH24qD5pkCWrGANGD6Lk6eT5d4wAG1n3kYvhWNJsig=" I have not found an alternative download location. The download for 2.100.1 is currently broken. Find 2.100.0 from http://downloads.dlang.org/releases/2022/ for now. -- Bastiaan.
Re: cogito, cognitive complexity for D
On Tuesday, 24 May 2022 at 21:25:38 UTC, Christian Köstlin wrote: if the dmd frontend could be made available as a dub package, It already is, as sub package of https://code.dlang.org/packages/dmd — Bastiaan.
Re: Beta 2.100.0
On Friday, 22 April 2022 at 09:24:00 UTC, Martin Nowak wrote: http://dlang.org/changelog/2.100.0.html It seems the list of contributors does not include the contributions to Dub. — Bastiaan.
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 10:59:39 UTC, Mike Parker wrote: ### D ecosystem services While we were waiting for everyone to arrive, I gave an update on the status of our plans to bring all of the ecosystem services under our control. At that point, I had received information on the resource requirements of services maintained by Vladimir Panteleev (the D forums, D wiki, and more), Jan Knepper (the main dlang.org site, the newsgroup server, the D blog), and Petar Kirov (run.dlang.io and tour.dlang.io). I also had received affirmative responses from those three to my invitation to join our next server meeting. Since that time, I have also received the same from Sönke Ludwig (code.dlang.org). The dub documentation, hosted at https://dub.pm should also be in that list. Currently there is a problem updating that site, see https://github.com/dlang/dub-docs/issues/41. -- Bastiaan.
Re: D Language Foundation Monthly Meeting for February 2022
On Saturday, 5 March 2022 at 14:03:38 UTC, Mike Parker wrote: On Saturday, 5 March 2022 at 12:39:39 UTC, Bastiaan Veelo wrote: On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote: But we have no reason to move the D projects away from GitHub to GitLab. GitLab has never entered the conversation. Two reasons would be that 1) It already offers [an integration with bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html). 2) Being open source it can be installed on your own hardware, which is the main argument being made for using bugzilla. It also has integrated CI. — Bastiaan. I have no opinion on point #1, but for #2, I do not see that as a benefit. We're aiming to integrate all of our services. As I see it, the less we have to manage ourselves, the better. If we did for some reason want to migrate to GitLab, my vote would be to let them host us. But my point was, GitHub has worked well for us for years. There's no desire to move away that I'm aware of. If it ain't broke, don't fix it! Definitely. Personally I think moving the tickets to GitHub is a good idea, I just felt these points needed to be made for completeness. — Bastiaan.
Re: D Language Foundation Monthly Meeting for February 2022
On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote: But we have no reason to move the D projects away from GitHub to GitLab. GitLab has never entered the conversation. Two reasons would be that 1) It already offers [an integration with bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html). 2) Being open source it can be installed on your own hardware, which is the main argument being made for using bugzilla. It also has integrated CI. — Bastiaan.
Re: D Language Foundation Monthly Meeting for February 2022
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote: ## Monthly Meeting Just letting you know that it is posts like these that I look forward to the most, and I very much appreciate the work that goes into them. Thanks! — Bastiaan.
Re: Printed version of the Vibe.d tutorial
On Sunday, 19 December 2021 at 21:57:50 UTC, Rey Valeza wrote: Hi, The printed version of the Vibe.d tutorial 'Build web apps in Vibe.d by learning from a learner' which I uploaded earlier in February this year is now available in paperback at Amazon: https://www.amazon.com/dp/B09MYTMNKF If you find yourself printing loose pages here and there from the tutorial and wishing you had a book instead, this is the answer. Thanks! Should probably be in this list: https://wiki.dlang.org/Books — Bastiaan.
Re: D Language Foundation Quarterly Meeting Summary -- July 23, 2021
On Wednesday, 28 July 2021 at 06:37:56 UTC, Mike Parker wrote: * Joseph Rushton Wakeling representing Frequenz I know Joseph, but haven't heard of Frequenz. Can't find them on https://dlang.org/orgs-using-d.html. Is there any news to be announced? -- Bastiaan.
Re: Diva - D Language Interface for Versioned Applications
On Saturday, 10 July 2021 at 11:29:21 UTC, pineapple wrote: On Saturday, 10 July 2021 at 08:42:46 UTC, Bastiaan Veelo wrote: Could it be that you have overlooked D Version Manager? https://code.dlang.org/packages/dvm — Bastiaan. Oh, I hadn't picked up on that. That only manages DMD, though. Diva can manage DMD and LDC, as well as managing dub separately if you want it to. Personally I'll be using Diva in the future to manage my installations. Thanks for clarifying the differences. — Bastiaan.
Re: Diva - D Language Interface for Versioned Applications
On Friday, 9 July 2021 at 23:59:55 UTC, pineapple wrote: Basically, it's a version manager which currently supports DMD, LDC, and dub. It's rough, but maybe in some ways a little less rough than install.sh, at https://dlang.org/install.html https://github.com/pineapplemachine/diva Could it be that you have overlooked D Version Manager? https://code.dlang.org/packages/dvm — Bastiaan.
Dub as tool chain installer
On Friday, 18 June 2021 at 06:14:03 UTC, Martin Nowak wrote: Maybe we could recruit someone to replace the dated NSIS installer with a native msi installer. https://issues.dlang.org/show_bug.cgi?id=15375 https://en.wikipedia.org/wiki/List_of_installation_software#Windows Don't have much of a clue about Windows nowadays, maybe there are more suitable alternatives. What would be the most suitable alternative in my eyes is for dub, based on [tool chain requirements](https://dub.pm/package-format-json.html#toolchain-requirements) specified in `dub.json`, to install and select compilers. Cross platform and cross vendor. I know there are compiler version managers, but I think since dub can check versions of packages and install packages, and can check compiler versions, it is only natural that it should also be able to install compilers. Above all, it would be just so convenient. This way a compiler upgrade becomes part of your commit history. You can test (beta) compiler releases in a separate branch, resolve deprecations comfortably, have your CI run all tests, all without interfering with main development. You push the change and all team members upgrade their compilers automatically without even noticing it, and certainly without surprises. And any number of years in the future, when you pick up an old project that has been dormant, it still compiles flawlessly because dub downgrades the compiler automatically. Come to think of it, maybe there should be an additional package category that provides build tools that can be run by dub without `dub run`, such as `dfmt`, `dpp`, `pegged`, and compilers and linters. — Bastiaan.
Re: Dlang Setup Tutorials
On Thursday, 10 June 2021 at 18:11:45 UTC, Igor wrote: Hi, I made my first few video tutorials and they are about how to setup DLang development environment on Windows and Linux. Hopefully it can help new people quickly setup everything for playing around with our beautiful language :). [YouTube Intro](https://www.youtube.com/watch?v=OzASFrPzil4=PLNiswfy6ptAnw_QmqAuy-Bz02oeu4pnLL) [YouTube Windows install](https://www.youtube.com/watch?v=fuJBj_tgsR8=PLNiswfy6ptAnw_QmqAuy-Bz02oeu4pnLL=2) [YouTube Ubuntu install](https://www.youtube.com/watch?v=fJ-u29rDVXk=PLNiswfy6ptAnw_QmqAuy-Bz02oeu4pnLL=3) [YouTube Manjaro install](https://www.youtube.com/watch?v=rM6_S6Fy7aQ=PLNiswfy6ptAnw_QmqAuy-Bz02oeu4pnLL=4) [...] These are nicely done, bravo! Even I learned something new. -- Bastiaan.
Re: Release D 2.097.0
On Saturday, 5 June 2021 at 13:00:05 UTC, evilrat wrote: Windows installer is broken. I have install target path excluded from Windows Defender anti virus checks, yet after the installation it only contains .bat files, uninstaller.exe, dmd2/windows/lib64 and lib32mscoff, but no bin and sources. I am having issues as well, but I don't think the installer is at fault: I see the `C:\D\dmd2` directory get filled as the installer progresses, then files just disappear. It doesn't seem to be consistent though. After failure I tried with `dmd-2.096.1.exe` and the same thing happened, whereas it had installed fine before. I tried `dmd-2.097.0.exe` and this time the whole directory got wiped. I tried again and it installed fine. Windows 10 Pro N version 20H2 build 19042.985. I suspect MS cloud security scan. -- Bastiaan.
Re: Visual D 1.1.0 released
On Thursday, 4 March 2021 at 13:42:47 UTC, Imperatorn wrote:
On Thursday, 4 March 2021 at 13:29:11 UTC, Imperatorn wrote:
On Tuesday, 2 March 2021 at 08:58:15 UTC, Rainer Schuetze
wrote:
[...]
A few questions.
How hard would the following be:
1. Highlight code as dead or alive in static if
2. Show typeid when hovering over a variable
I have gifs showing what I mean. I'll post them when I get
back to my laptop.
https://filebin.net/19gupoeedfdjx5tx
One GIF is the behaviour in C# I would like to have in D as
well with static if, and the other is displaying typeid on
hover.
It already does this, I would say.
1. The D equivalent of your use of `#if ... #else ... #endif` is
`version() {...} else {...}`, which works in VisualD the same way
as you show. `static if` is different: the condition often
depends on the value of template parameters, so this does not
simply translate to "dead" or "alive" in every case.
2. typeid is a runtime concept (takes inheritance into account)
so this won't work in an editor outside of a debugging session.
However VisualD already shows the (static) type and scope of
variables on mouse-over, which is all you can wish for, I think.
-- Bastiaan.
Re: Visual D 1.1.0 released
On Tuesday, 2 March 2021 at 08:58:15 UTC, Rainer Schuetze wrote: You can find the update installer or a full installer bundled with latest versions of DMD and LDC here: https://rainers.github.io/visuald/visuald/StartPage.html For clarity, the converse is not true. If you use the official dmd installer (.exe) and select "Download Visual D" in it then you end up with only version 0.50 of VisualD. -- Bastiaan.
Re: Visual D 1.1.0 released
On Tuesday, 2 March 2021 at 08:58:15 UTC, Rainer Schuetze wrote: finally the results of recent months have been released. All very cool features, thank you very much!! --Bastiaan.
Re: Article: Why I use the D programming language for scripting
On Sunday, 31 January 2021 at 20:47:13 UTC, Steven Schveighoffer wrote: On 1/31/21 3:36 PM, aberba wrote: It's finally out! https://opensource.com/article/21/1/d-scripting Hm... right off I see the shebang is not the first line in the example. It has to be. Please fix, Aberba, right now the examples don't work because of this... -- Bastiaan.
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: Dear all, to compare MIR and Numpy in the HPC context, we implemented a multigrid solver in Python using Numpy and in D using Mir and perforemd some benchmarks with them. You can find our code and results here: https://github.com/typohnebild/numpy-vs-mir Nice numbers. I’m not a Python guy but I was under the impression that Numpy actually is written in C, so that when you benchmark Numpy you’re mostly benchmarking C, not Python. Therefore I had expected the Numpy performance to be much closer to D’s. An important factor I think, which I’m not sure you have discussed (didn’t look too closely), is the compiler backend that was used to compile D and Numpy. Then again, as a user one is mostly interested in the out-of-the-box performance, which this seems to be a good measure of. — Bastiaan.
Re: LDC 1.24.0-beta1
On Sunday, 18 October 2020 at 23:07:26 UTC, aberba wrote: On Sunday, 18 October 2020 at 22:47:17 UTC, Adam D. Ruppe wrote: On Sunday, 18 October 2020 at 22:40:53 UTC, aberba wrote: Not sure what to do with the .7z file without manual tinkering. You can simply unzip it and use it directly. That's the best way to use most D compilers actually, then any versions can live side by side without affecting each other. It's what I did and added to my system path...but that's if you know what you're doing. An installer just like dmd etc is what newbies are used to. I'm not suggesting that this fills the need of newbies, but there is this: https://dlang.org/install.html. --Bastiaan.
Re: Symmetry Investments and the D Language Foundation are Hiring
permanent position This is huge! Thank you Symmetry! — Bastiaan.
Re: Release D 2.093.0
On Monday, 20 July 2020 at 15:10:27 UTC, jmh530 wrote: See https://issues.dlang.org/show_bug.cgi?id=21059 Thanks, I will look into this. I posted a workaround there, which involves separate steps for downloading the script and running the script. --Bastiaan.
Re: Release D 2.093.0
On Sunday, 19 July 2020 at 19:16:29 UTC, jmh530 wrote:
I just upgraded a machine to Linux Mint 20 on a fresh install
and tried to run the install script. It fails with
main: line 178: USERPROFILE: unbound variable
This line should only be called on Windows, which I found
strange. It turns out that this is driven by
```
posix_terminal() {
# If this script is run on Windows cmd by passing it as
argument to bash.exe,
# the shell level will be 1. If it is run from a POSIX
terminal, it will be > 1.
if [ "$SHLVL" = 1 ]; then
false
else
true
fi
}
```
Running `echo $SHLVL` prints `1`
Running
```
bash
echo $SHLVL
```
prints `2`
Running `echo $SHELL` prints `/bin/bash`
The issue seems to be related to an update to Ubuntu 16:
https://askubuntu.com/questions/856532/why-is-shlvl-initially-2-in-ubuntu-16-10-but-not-earlier-versions
I don't think it is related to the Ubuntu 16.10 issue, because
the above test does not rely on SHLVL being 2 initially. If the
script is called from the terminal, and the terminal is running
bash (which it seems to do according to the output of $SHELL)
SHLVL should be at least 1 on the terminal and one higher when
the script is run (since running a script starts a new bash).
Maybe the script is run in a way that breaks this assumption? Is
it run using `call`? Is it run headless, without a terminal? Is
it not run by real bash?
There is a related conversation here, but not quite the same:
https://github.com/dlang/installer/commit/e084815001390538bbd6fe5be7c2d4d81ee681b7#commitcomment-40487617
Please open an issue on https://issues.dlang.org/enter_bug.cgi
and post a link here, if we need to drill deeper.
I can imagine that the current `posix_terminal()` is flawed if
the terminal is running a shell that is not bash, for which we
should find a solution.
--Bastiaan.
Re: Origins of the D Programming Language now published by ACM!
On Saturday, 13 June 2020 at 03:16:05 UTC, Walter Bright wrote: https://dl.acm.org/doi/abs/10.1145/3386323 Many, many thanks to Mike Parker and Andrei Alexandrescu for their endless hours spent fixing the mess I originally wrote. Thanks to COVID-19, access is free through June 30. I very much enjoyed reading this paper. Thanks! -- Bastiaan.
Re: DIP 1028 "Make @safe the Default" is dead
On Friday, 29 May 2020 at 20:36:12 UTC, Walter Bright wrote: On 5/29/2020 7:22 AM, Paul Backus wrote: This is sad news. I was excited for @safe-by-default, and had hoped that the issue with extern(C) could be solved without throwing DIP 1028 away entirely. I watched a documentary on Clive Davis (famous recording executive) the other day. He would advise his clients, like Kenny G, Barry Manilow, etc., on how they should arrange and position their songs. Kenny G (famous clarinet player) said Davis recommended he add a vocal track, as that will sell more records. KG asks are you advising, or telling me? Davis says he's advising. KG does it his own way, and the record is a hit. KG triumphantly tells Davis what do you think of that now? Davis replies if KG had followed his advice, he'd have sold even more records. I’m not sure who in this analogy is the Kenny G and who the Clive Davis, and we probably will never know for sure. Off topic, and without extending the analogy, I had never heard about Kenny G until I came across Pat Metheny’s rant about him. It’s a well reasoned critique, and it seems to me that the expertise in our community is a lot higher than Kenny G’s musical expertise. http://www.jazzoasis.com/methenyonkennyg.htm — Bastiaan
Re: Rationale for accepting DIP 1028 as is
On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote: On 5/26/2020 11:20 PM, Bruce Carneal wrote: I'm not at all concerned with legacy non-compiling code of this nature. Apparently you agree it is not an actual problem. Really? I don't know if you really missed the point being made, or you're being provocative. Both seem unlikely to me. -- Bastiaan.
Re: Rationale for accepting DIP 1028 as is
On Tuesday, 26 May 2020 at 16:31:57 UTC, Bruce Carneal wrote: Currently a machine checked @safe function calling an unannotated extern C routine will error out during compilation. This is great as the C routine was not machine checked, and generally can not be checked. Post 1028, IIUC, the compilation will go through without complaint. This seems quite clear. What am I missing? I agree that being forced to think about a trusted interface to that routine can contribute to safety. Not getting this is the price if DIP 1028 as is. Doing it the other way bears a different price. Still, it does not change the amount of code that must be vetted during an audit, either way. -- Bastiaan.
Re: Rationale for accepting DIP 1028 as is
On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote: On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote: @safe: the compiler checks The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check. Completely agree but my above says nothing about @trusted. But it matters. Even if your code is @safe, that doesn't mean it is completely safe. Your @safe code can call into somebody else's @safe code that can call @trusted code that calls @system code. If you want to guarantee that your code is safe, you'll have to find and audit the @trusted bits (as well as everything that is called from there). If extern(C) is implicitly @system, you'll have to make calls @trusted and they are subject to auditing. If extern(C) is implicitly @safe, calls are still subject to auditing. Whatever your preference, I think the compiler can be of greater help in finding the bits that require auditing than grep can, and then the difference isn't all that important anymore. Safe wrappers around C libraries are still written the same way, audited the same way, and unsafe calls into C caught the same way. I agree that making extern(!D) @system looks sound, like the way it should be. But it breaks compilation of existing code, and it is too easy to evade by slapping on an explicit @trusted or (God forbid) @safe. Or we could make extern(!D) to be anything other than @system an error, which would be really annoying. I think that what we all strive for is to reduce the strain of coding as well as to reduce the strain of auditing. -- Bastiaan.
Re: Safety audit and the overlooked emergency exit
On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote: [snipped an outline of tooling to mitigate 1028 damage] I think this would be a tool that adds real practical value and helps to reduce the cost of audits. And not the least, regarding the current discussion, it diminishes the importance of whether extern(C[++]) declarations are actually @system or @safe. Yes. Tooling is good and will be much appreciated if 1028 stands. Reducing the need for tooling is even better. @safe: the compiler checks The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check. @safe post 1028: the compiler checks, sometimes, just not in the scary parts The amount of code that requires human auditing remains the same. What matters is how to find that code, and how to maintain the validity of the audits. -- Bastiaan.
Safety audit and the overlooked emergency exit
I think there is an exit to the current impasse that has been overlooked thus far. The key question is, during a safety audit, how to find the unsafe sections of code that need to be vetted thoroughly. If DIP 1028 is kept as is, these sections can be found by `grep @trusted|extern\(C`. If DIP 1028 would be amended as many argue for, it would be `grep @trusted`. But isn't grep a rather crude tool, and wouldn't the compiler be able to create more useful reports either way? The compiler already has options for listing gc allocations (-vgc) and variables that go into thread local storage (-vtls). A new option could be implemented to list all @trusted functions and all calls into extern(C[++]) functions from within safe sections. It is the calls into extern(C[++]) functions that cannot be guaranteed to be safe, irrespective of whether the declarations are marked @trusted or @safe. So listing these calls is much more valuable than grepping for @trusted, which can be misused as "@trusted extern(...". If a C library has a proper D wrapper that defines a safe interface, only the @trusted functions in the wrapper would appear in the list, not the extern(C) calls that are made within its @trusted functions. The list could possibly be reduced by excluding functions that are never called, making it even more valuable. @trusted is not a seal of approval. It bears no signature, nor a hash of the implementation. It is simply a bridge from safe territory into unsafe territory, and is a checkpoint that cannot be skipped in any certification process. Considering this, the compiler can actually produce a hash of the implementation of trusted functions as part of this list. A certification authority can then actually use this list to maintain a table of sections, hashes and stamps. If a new release needs to renew its certification, the earlier table can be compared against the current list, and functions whose hash didn't change need not be reviewed again. Extrapolating even further, this could be the basis of a repository of approvals from various individuals and authorities representing statements like "I have looked at this function carefully and I believe it can indeed be trusted". I think this would be a tool that adds real practical value and helps to reduce the cost of audits. And not the least, regarding the current discussion, it diminishes the importance of whether extern(C[++]) declarations are actually @system or @safe. -- Bastiaan.
Re: OT: Back
On Tuesday, 12 May 2020 at 07:48:46 UTC, Dmitry Olshansky wrote: On Tuesday, 12 May 2020 at 07:21:43 UTC, Bastiaan Veelo wrote: On Tuesday, 5 May 2020 at 15:39:12 UTC, Dmitry Olshansky wrote: P.S. I'm kind of back, but very busy and my health is mostly great despite the COVID outrage out there. That's great! Glad to hear that. Bastian! Great to see you still around. How your D stuff is going at that naval company? First real application is running: a program for the numerical analysis of a ship launch at the yard. Currently testing and debugging. Pain points typically revolve around low level tricks in Pascal using arrays starting at 1 (these usually translate without problems, except where they don't)... Or passing strings to/from win32. Still committed to translate all other programs in our suite to D, busy times as usual. -- Bastiaan.
OT: Back
On Tuesday, 5 May 2020 at 15:39:12 UTC, Dmitry Olshansky wrote: P.S. I'm kind of back, but very busy and my health is mostly great despite the COVID outrage out there. That's great! Glad to hear that. -- Bastiaan.
Re: Visual D 0.52.0 released
On Monday, 23 March 2020 at 09:54:46 UTC, Rainer Schuetze wrote: Hi, a new version of Visual D, the Visual Studio extension that adds D language support to VS2008-2019, is available at https://rainers.github.io/visuald/visuald/StartPage.html [...] The full version history can be found at https://rainers.github.io/visuald/visuald/VersionHistory.html Cheers, Rainer Great news! - Bastiaan.
Re: DConf 2020 Canceled
On Tuesday, 10 March 2020 at 18:06:53 UTC, bauss wrote: On Sunday, 8 March 2020 at 03:56:35 UTC, Era Scarecrow wrote: From what i've researched, You are very misinformed about it, not sure what your sources are for your "research" but you've done your research the wrong places. Indeed. I am aware that people susceptible to conspiracy theories have a tendency to mistrust experts, but I'll post this very informative interview with one such expert nonetheless. https://www.youtube.com/watch?v=E3URhJx0NSw Michael Osterholm is an internationally recognized expert in infectious disease epidemiology. He is Regents Professor, McKnight Presidential Endowed Chair in Public Health, the director of the Center for Infectious Disease Research and Policy (CIDRAP), Distinguished Teaching Professor in the Division of Environmental Health Sciences, School of Public Health, a professor in the Technological Leadership Institute, College of Science and Engineering, and an adjunct professor in the Medical School, all at the University of Minnesota. Back on topic, cancelling DConf is a good call. --Bastiaan.
Re: code.dlang.org reliability update
On Monday, 2 March 2020 at 19:17:59 UTC, Sönke Ludwig wrote: As of yesterday, code.dlang.org now points to a more powerful dedicated server that can host the DUB registry without the danger of freezing due to excessive swapping - this is what happened on the 26th last month [1]. In addition to that, the server that previously hosted the registry is now used to run an official mirror, reachable at codemirror.dlang.org. This will be configured as a built-in fallback server starting with DMD 2.091.0/DUB 1.12.0 and, at least in theory, will lead to an uptime of virtually 100%. Excellent, thank you! Bastiaan.
Re: FeedSpot Recognizes the GtkDcoding Blog
On Friday, 7 February 2020 at 14:23:58 UTC, Andre Pany wrote: Also from me congratulations! GtkD (GTK) are a great piece of software and your tutorials are fantastic to get into it. Now the sad part. I would like to use GtkD at work but I can't. The license is really dangerous for companies (you compile lGpl source code into your application), therefore it is a complete no go from the IP department. The license is a huge blocker for GtkD commercial usage. This is just FUD, and not true. Did you read the license? [1] It explicitly states additional freedoms not present in the LGPL. You may even link statically without the license infecting your proprietary code! It seems to me it is the incompetence of your IP department that is your problem, not the GtkD license. I would like to run GTK applications in the browser (broadway html5). Due to the license issue I have to use the C api): What difference does that make, legally? AFAIK the C api license is more restrictive than GtkD’s license. I hope the authors of GtkD could change their mind in future. In what way? I’d advise your IP department to talk to Mike Wey directly. Bastiaan. [1] https://github.com/gtkd-developers/GtkD/blob/master/COPYING
Re: FeedSpot Recognizes the GtkDcoding Blog
On Tuesday, 4 February 2020 at 15:21:30 UTC, Ron Tarrant wrote: This morning I was contacted by Anuj Agarwal, the Founder of Feedspot, who told me http://GtkDcoding.com has been recognized as one of the top 100 blogs for programmers. It's currently listed as #71. Well done! Bastiaan.
Re: dud: A dub replacement
On Monday, 25 November 2019 at 18:28:55 UTC, H. S. Teoh wrote: - lack of support for build-time code generation (i.e., build a subset of files into an executable, run the executable to generate .d files, compile output .d files plus other existing .d files into final product). I am doing exactly that. It can be done through preGenerateCommands, calling either a secondary build script or nested dub project, optionally using excludedSourceFiles. The only reason it doesn’t work well is because of https://github.com/dlang/dub/issues/1474. But there are workarounds, and a poc fix. Bastiaan.
Re: D Forum Mobile Version - Beta
On Sunday, 27 October 2019 at 02:11:50 UTC, matheus wrote: Hi, I use to access this Forum mainly through the WEB version, and so far It never bothered me when reading on my PC. But on my phone (An old LG K4) with tiny screen it's not very pleasant, I use this phone when I'm on the road, I lately I gave up to read this Forum through it. So, I decided to create a "wrapper" of this Forum applying style for small screens like in my case. The result is here: http://www.mazeware.com/dforums.html Here are some diffs between both versions: https://i.imgur.com/wfmm035.png https://i.imgur.com/LzvhrdQ.png https://i.imgur.com/BM13xTw.png I'm sharing this because it may be useful for some people. Finally I'd like to know if it is possible to have this to be acessed direct in your server (Maybe in a new sub-domain), since my hosting is slow. Matheus. I’d recommend contacting Vladimir directly, like bachmeier said in https://forum.dlang.org/post/jnikxmmrmohsdszaf...@forum.dlang.org. However, I tried your version and it didn’t work well for me; I’m on an iPhone 6. I prefer the current version in the threaded mode. I don’t know how you implemented your version, but if you can make it configurable as one of the current supported view modes, I guess the chances of getting it accepted are higher. Thanks for contributing. Bastiaan.
Re: Oberon to D
On Tuesday, 15 October 2019 at 18:02:28 UTC, Mario Kröplin wrote: https://github.com/linkrope/oberon2d is a simple tool that translates source code from Oberon to D. It was intended to be thrown away after the resurrection of a single Oberon project. (So, don't expect too much.) But then, Bastiaan Veelo presented a very similar problem at DConf 2017. I'm a bit late, but I hope this could help. Thanks for sharing! Your translation module is surprisingly concise. As I read up a bit on Oberon, I learned that Nicklaus Wirth is still maintaining his compiler[1]. I wonder what he would think of D. Bastiaan. [1] https://inf.ethz.ch/personal/wirth/news.txt
Re: CodinGame adds support for 2 new programming languages
On Thursday, 26 September 2019 at 15:58:46 UTC, Andre Pany wrote: Hi, Based on the voting results (https://www.codingame.com/forum/t/poll-what-programming-language-would-you-like-codingame-to-support-next) Codingame is currently adding 2 new programming languages, Type Script and D! Thanks for your votes, they made it happen! Kind regards Andre That's great, I'm looking forward to this! Bastiaan.
Re: Chunker - Content-Defined Chunking based on Rabin Checksums
On Saturday, 21 September 2019 at 03:11:11 UTC, Vladimir Panteleev wrote: Hi, This is a D port of a Go package implementing Content-Defined Chunking: https://github.com/CyberShadow/chunker [...] - Significant refactorings and simplifications of the implementation. The original code made some sacrifices in code readability to work around limitations of the language and compiler optimization to achieve reasonable performance. - 20% faster than the Go version (LDC release build). Marvellous! Well done. [...] The original package was written by Alexander Neumann and is used in the restic backup program. Sounds like D would have been the right language for Restic. Maybe this is enough to spark Alexander’s interest in D? Cheers, Bastiaan.
Re: We’re hiring Software Engineers! (D language)
On Tuesday, 2 July 2019 at 08:56:42 UTC, Andrej Mitrovic wrote: Hi! BPF Korea is looking to increase the size of its core development team in Seoul, South Korea. Congrats! You should be on this page[1] then, would you agree? Let me know if you need help with a PR. Bastiaan. [1] https://dlang.org/orgs-using-d.html
Re: Autonomous driving company is looking for D software engineers
On Sunday, 23 June 2019 at 20:16:52 UTC, Dragos Carp wrote: Regarding about adding AID to the website, this will raise the visibility of the offer and would be great for us. Thank you! https://github.com/dlang/dlang.org/pull/2667 Bastiaan.
Re: DConf 2019 Videos
On Thursday, 13 June 2019 at 10:02:07 UTC, Ola Fosheim Grøstad wrote: In one of the talks there was suggested that ANTLR has D support, but the official ANTLR distribution does not provide that. Which talk? There may be a confusion with Bison: https://forum.dlang.org/post/fjuvegjdvcunqqvvb...@forum.dlang.org Bastiaan.
Re: DConf 2019 Videos
On Wednesday, 5 June 2019 at 02:37:57 UTC, Mike Parker wrote: The DConf 2019 playlist is available at: https://www.youtube.com/playlist?list=PLIldXzSkPUXWORGtUrnTo2ylziTHR8_Sq Walter's keynote is up now. Others will be available soon. Again, I can't predict how long until they're all up, but they're coming. I just watched Walter’s talk again and this video is very well done. Worth the wait and money well spent! Bastiaan.
Re: Beta 2.086.0
On Wednesday, 1 May 2019 at 19:33:17 UTC, Martin Nowak wrote: On Sunday, 21 April 2019 at 08:47:12 UTC, Bastiaan Veelo wrote: The $(CONSOLE) macro seems to not be able to handle `---` in its argument, which wrongly starts an example. https://github.com/dlang/dub/blob/28a0c1ee3ef7c34cf586fc32be88cf75c2912043/changelog/dub-run.dd Clever, replacing with Bastiaan.
Re: Release Candidate 2.086.0 [was: Re: Beta 2.086.0]
The list in https://dlang.org/changelog/2.086.0.html#copy_constructor is still broken by the examples inside it. Do we have a DDOC expert that knows how to solve that? Bastiaan.
Re: DDeps 1.1.1
On Saturday, 27 April 2019 at 16:16:02 UTC, lempiji wrote: Recently, I created a tool to create a module dependency graph for the D language. The tool can compare two versions and visualize the differences. I think it's useful for source reviews. Try it if you are interested. Some screenshots are included in the README. - DUB: http://code.dlang.org/packages/ddeps - GitHub: https://github.com/lempiji/ddeps Very nice! I’ll have to bookmark this. Bastiaan.
Re: Beta 2.086.0
On Saturday, 20 April 2019 at 14:16:09 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.086.0 release, ♥ to the 52 contributors. Many thanks, Martin! Presumably, contributors Boris Carvajal and BorisCarvajal are the same Boris :-) Bastiaan.
Re: Beta 2.086.0
On Saturday, 20 April 2019 at 18:00:02 UTC, Nick Sabalausky (Abscissa) wrote: The changelog has some formatting errors in the section "dub run will now automatically fetch a package if it's not found locally". The $(CONSOLE) macro seems to not be able to handle `---` in its argument, which wrongly starts an example. There is another formatting issue in the Copy Constructor section, where the nested $(OL) does not handle examples well, by which successive $(LI) appear in the top level list instead. Bastiaan.
Re: DC v1.0.0 - cross-platform D compiler install management tool
On Monday, 1 April 2019 at 17:35:38 UTC, Jacob Carlborg wrote: On 2019-04-01 12:31, Mihails wrote: Nice, I must admit I have had my mind set about DVM as something that has existed for years and wasn't quite the right thing. Had no idea you kept improving it lately. Yeah, I thought it was time to fix one or two bugs. Appreciated! Once we take D into production I plan to integrate a tool like dvm or dc into our build system for two main reasons: 1) to have reproducible historical builds, being able to check out a revision from a year or more ago and compile it without deprecation warnings or errors that we did not have back then, and including any bugs that may have been present in e.g. phobos. 2) being able to prepare the code base for a new compiler release (or brand), push it, so that thereafter all developers and CI systems start using it without further thought or administration. This is an important gear in the drivetrain that will allow us to maintain a "Please break our code!" mentality so that the language can continue to get better and better without us being left behind. So thank you. Bastiaan.
Re: Fundraising Updates: We did it!
On Tuesday, 26 March 2019 at 18:49:30 UTC, Vladimir Panteleev wrote: Thank you, Jan, and thank you to everyone who donated. And thank you, Vladimir!
Re: Darser: A LL(1) to Recursive Decent Parser/AST/Visitor Generator
On Wednesday, 20 March 2019 at 21:30:29 UTC, Cym13 wrote: On Wednesday, 20 March 2019 at 17:20:48 UTC, Robert Schadek wrote: To get graphqld up and running I needed a parser/ast/visitor. Being lazy, I created parser/ast/visitor generated for that. [...] This looks nice! I'm familiar with pegged which uses PEG grammars, could you maybe comment on the differences and possible benefits of Darser in comparison? I'm interested in that too. I suppose it doesn't support left-recursive grammars, like Pegged does?
Re: DConf 2019 Submissions and Early-Bird Discount
On Saturday, 16 March 2019 at 16:02:41 UTC, Mike Parker wrote: Essentially, if you're donating money through Flipcause, the more people who cover the processing fee the better, but it won't hurt us as bad as the PayPal fees people don't do so. But when registering for DConf, it's a big help when you cover the processing fee. Thanks for the clarification. I'm looking forward to see you again soon, and all you other great people! Bastiaan.
Re: DConf 2019 Submissions and Early-Bird Discount
On Monday, 11 March 2019 at 15:04:54 UTC, Mike Parker wrote: https://dconf.org/2019/registration.html I clicked through the Flipcause payment procedure because I know that is the preferred channel, and ticked the box for "I'd like to cover the processing fee so 100% of my contribution goes to D Language Foundation." This adds $20.29 to the bill; is that expected? Is it still cheaper than PayPall?
Re: How is your DConf proposal looking?
On Thursday, 7 March 2019 at 16:57:11 UTC, Ali Çehreli wrote: Reminder... :) http://dconf.org/2019/index.html Ali It's shaping up :-) Bastiaan.
Re: Beta 2.085.0
On Sunday, 24 February 2019 at 22:31:53 UTC, Martin Nowak wrote: On Saturday, 16 February 2019 at 15:06:51 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.085.0 release, ♥ to the 49 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.085.0.html Second beta is live now. Having an editor open during installation can be problematic. https://issues.dlang.org/show_bug.cgi?id=19707
Re: The D Programming Language has been accepted as a GSoC 2019 organization
On Tuesday, 26 February 2019 at 22:34:45 UTC, Seb wrote: Hi all, I have some very exciting news to share. The D Language Language got accepted as a Google Summer of Code organization! The official GSoC page provides a few initial pointers and details: https://summerofcode.withgoogle.com/organizations/6103365956665344 You guys give a very nice description of the language on that page. If I didn’t already use D, I would want to now! Bastiaan.
Re: DIP 1018--The Copy Constructor--Formal Review
On Sunday, 24 February 2019 at 10:46:37 UTC, Mike Parker wrote: Walter provided feedback on Razvan's implementation. When it reached a state with which he was satisfied, he gave the green light for acceptance. The DIP: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md Yay! Congrats to Razvan. Was this a roadblock towards reference counting, or am I confused?
Re: Fireside chat with Walter Bright, the creator of the D programming language
On Thursday, 14 February 2019 at 23:34:40 UTC, Ali Çehreli wrote: What specific questions would you like answered? What are the top D related activities that you spend most time on? If you had more time available, how would you wish to spend it? What would be the best next big thing to happen to D? Are there specific areas in our eco system that you think stand out as needing improvement? If so, what would be the best way to go about it? Say you had three skilled employees that you could tell what to do. What would you have them work on? Has D become the language that you envisioned it to be? Has it surpassed it, or not yet? How would you like to see it evolve? Are you happy with the D community? —Bastiaan.
Re: My Meeting C++ Keynote video is now available
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei Top notch, as usual. Nice progression from “another language” through “the other language”, “d (other) language” to finally just “D language“ :-) Bastiaan.
Re: Release D 2.084.0
On Wednesday, 2 January 2019 at 13:25:25 UTC, Martin Nowak wrote: Glad to announce D 2.084.0, ♥ to the 53 contributors. Thanks!
Re: DConf 2019: Shepherd's Pie Edition
On Monday, 24 December 2018 at 12:30:57 UTC, Vijay Nayar wrote: Looking forward to it! The caliber of people at these conferences has been exceptional every year I've gone, and many of the ideas presented have been very valuable, whether they were directly related to DLang or not. Just one small example was a 2017 talk by Bastiaan Veelo on D libraries implementing Parsing Expression Grammars, which I had never heard of at the time. But the idea ended up being very useful for greatly simplifying the interfaces of systems I was working on that year. Thank you Vijay, that’s nice to hear! Bastiaan.
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 16:57:10 UTC, Joakim wrote: On Saturday, 22 December 2018 at 16:35:27 UTC, Johannes Loher wrote: Also I don't think this is the right place for this discussion. If you feel that we indeed need to rediscuss this issue, I think it should be done in a separate thread. I'm not trying to discuss it with you or the community. I'm asking the D team [...] Then why post in the announce thread? If you don’t feel your previous thread got your message through, you know how to reach the foundation. I don’t understand how you can argue against technical conferences so much if you never attended one, much less DConf. I know the odds are slim, but I hope to meet you there someday. Bastiaan.
Re: I've just released Vasaro
On Friday, 7 December 2018 at 07:22:18 UTC, JN wrote: Looks nice. I'll give it a go when I plug my 3d printer. Make sure it prints watertight before using the vase for fresh flowers :-)
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 17:49:55 UTC, Joakim wrote: […] it's quite simple: they view a bool as an integral type with two possible values, a `bit` if you like. As such, they prefer to fit it into the existing scheme for integral types rather than special-casing booleans as Mike proposed. I can’t say I have a strong opinion on this, but possibly it would be right to have an integral “bit” type to differentiate it from the Boolean type, just like we have a “byte” type to differentiate it from “char”...
Re: Backend nearly entirely converted to D
On Thursday, 8 November 2018 at 22:21:40 UTC, welkam wrote: On Thursday, 8 November 2018 at 18:52:02 UTC, H. S. Teoh wrote: length is getting ridiculous Having better editor support is nice but by "use better editor" you meant use vim dont you? Please keep chatter on the announce forum to a minimum. Vim is not the only editor capable of limiting searches to whole words. Sublime Text and Visual Studio Code can do this too, as can probably many others.
Re: textattr library for text colors and attributes available in D
On Thursday, 8 November 2018 at 13:37:08 UTC, Shriramana Sharma wrote: https://github.com/jamadagni/textattr/ textattr is a library and command-line tool that makes adding color and attributes to beautify the terminal output of your program easier by translating human-readable specs into ANSI escape codes. The library is available for C, C++, Python and D. C++ and Python use the C code for internal processing but the D code is a separate implementation for easy inclusion of textattr.d in a D compilation command without requiring any external linking. Copyright: Shriramana Sharma, 2018 License: BSD-2-Clause Cool, must remember this in case I need it one day. Do you have plans to add it to the dub registry?
Re: LDC 1.13.0-beta1
On Friday, 2 November 2018 at 21:04:13 UTC, kinke wrote: Glad to announce the first beta for LDC 1.13: * Based on D 2.083.0. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. * Substantial debug info improvements for GDB. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0-beta1 Thanks to all contributors! You ‘re quick! Great work.
Re: Add D front-end, libphobos library, and D2 testsuite... to GCC
On Monday, 29 October 2018 at 03:43:49 UTC, Mike Parker wrote: Congratulations are in order for Iain Buclaw. His efforts have been rewarded in a big way. Last Friday, he got the greenlight to move forward with submitting his changes into GCC: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01676.html Great work, Iain! Thanks for having such a long breath. I'm aware that this is not the end of your endeavour, so I wish you good luck on the way to your remaining milestones. It must feel great to have the road opened up to those! Bastiaan.
Re: Interfacing D with C: Arrays Part 1
On Wednesday, 17 October 2018 at 15:20:08 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2018/10/17/interfacing-d-with-c-arrays-part-1/ A good read! It’s always nice to discover new content on the blog.
Re: Write for the D Blog!
On Monday, 13 August 2018 at 16:16:31 UTC, Dukc wrote: But I want to say, that the fairly recent post about SARC moving to D was great stuff to read! It had so many links and viewpoints rarely mentioned, I was not even aware about them. The naval architecht viewpoint is a refresher! That’s nice to hear, thanks a lot! Update on that project: I have moved out from the laboratory and today I successfully transpiled the second real-world Pascal module. The next one requires more thought, as it’s interface and implementation are in separate files. Morale of the story? I think that one should not be afraid to post there if he does not consider himself a "regular" programmer, because thats precisely what produces the best posts. I appreciate that morale. There's definitely no reason to be shy, and Mike is a very helpful editor!
Re: Blogpost about parallelizing Datacat with std.parallelism
On Thursday, 26 July 2018 at 12:13:01 UTC, Joakim Brännström wrote: https://github.com/joakim-brannstrom/blog/blob/master/posts/2018-07-24.md Nice! I /just/ decided this afternoon that it is time to do some profiling; thanks for the tips.
Re: Blogpost about the T.init problem
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: I've written up a short blogpost about the T.init issue. It is not very enthusiastic. https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43 Have you tried giving your invariants a valid initial value? Change string username; into string username = "noname"; -Bastiaan
