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: Blog post about printing associative arrays from GDB
Thanks for spitting through the GDB manual so I don't have to!
I would've guessed something like this was possible with GDB, but
never bothered until now.
On Wednesday, 23 October 2019 at 20:52:55 UTC, Johannes Riecken
wrote:
is there a Phobos function to automatically print expected and
actual values for failed assertions? In our company we use
ocean's test!("==").
Not a phobos function, a compiler switch. In recent LDC and DMD,
you can use -checkaction=context and an attempt is made to print
the actual values involved in the assertion. It is still young so
you might still encounter bugs or limitations, but it does the
job really well for most asserts.
Re: Blog post about printing associative arrays from GDB
Hi, Now wouldn’t it be even more useful if we knew why the unit test failed? Apparently D doesn’t print that information automatically on assertion failure, supposedly for performance reasons. Off-topic, but recent frontends feature a `--checkaction=context` switch, which for your example yields something like: onlineapp.d(5): [unittest] [3: 30, 2: 20, 1: 10] != [1: 10] 1/1 unittests FAILED https://run.dlang.io/is/XZy5PN
Blog post about printing associative arrays from GDB
I've written a blog post about printing custom data structures
from GDB using dlopen that I hope some of you find interesting
and I'd also be happy to discuss it:
https://medium.com/dunnhumby-data-science-engineering/how-to-simplify-debugging-unit-tests-in-d-a2b52c5c1fa
Please let me know if there are any better ways to print data
structures like associative arrays from GDB, maybe by using
functions from the runtime library. Another exciting idea would
be to automate the pretty printing, maybe also by looking how the
pretty-printers for C++ in GDB 7+ are defined. I sadly haven't
read much D code from outside our company; is there a Phobos
function to automatically print expected and actual values for
failed assertions? In our company we use ocean's test!("==").
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 15:31:24 UTC, Exil wrote: D isn't a systems programming language "“But D has a GC!”, I hear you exclaim. Yes, but it’s also a systems programming language with value types and pointers, meaning that today, D isn’t memory safe. DIP1000 was a step in the right direction, but we have to be memory safe unless programmers opt-out via a “I know what I’m doing” @trusted block or function. This includes transitioning to @safe by default." https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/ -Alex
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 04:53:55 UTC, Mike Parker wrote: On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote: it's a bad idea. Why have two community reviews? Those are made with the assumption that the DIP will actually change between the reviews. No, that's not the assumption. You're conflating Community Review with Final Review. There can be multiple rounds of the former as required and only one of the latter. In a perfect scenario, no revisions are required between CR and FR. The purpose of the Final Review is to provide one final opportunity to catch any major issues that might have been missed during the CR round(s) and to allow anyone who missed the CR round(s) a final opportunity to have their say. Revisions are expected after a CR round, but not after the FR. As the documentation explains: https://github.com/dlang/DIPs/blob/master/docs/process-reviews.md Why even have a final review then? Shouldn't the community review only end if there are no more changes to be made? If changes are made after the Final Review, then those changes won't get to be reviewed. If the author doesn't take any criticism of their work and decides their DIP is a shiny pile of words that doesn't needy any more polishing, why have the community review the same thing again? If that is how it is intended to be then it is a flawed system at that.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 04:49:52 UTC, Mike Parker wrote: On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote: Should create a DIPW process then, duck the foundation and any formalities. Which stands for DIPWalter, which simply consists of a single step where a single topic tries to convince Walter it's a bad idea. Why have two community reviews? Those are made with the assumption that the DIP will actually change between the reviews. What's the point of a "formal review" when there's just Walter talking to himself (rip Andrei). Why waste everyone's time on formalities when they obviously are irrelevant? The formal assessment isn't Walter by himself. Atila took Andrei's place in that role. There is no automatic approval. Had Atila objected to the DIP, Walter would have had to either convince him to come around to his point of view or revise the DIP to meet Atila's concerns. I'd love to see the transcript of that. What was included in the DIP was rather short (a single sentence) compared to other DIPs.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 15:10:23 UTC, 12345swordy wrote: On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote: Not to mention the problem is actually solved just by using the GC. The d language is marked as a system programming language. The GC is not going to cut it to a lot of people.(Did you forget the whole betterC flag?) -Alex A flag that was only added recently (relative to the lifespan of D)? D isn't a systems programming language, there's entire threads dedicated to the topic. You can call it whatever you want, but if that's what it wasn't to identify as, it's bottom of the barrel in terms of system programming languages.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Wednesday, 23 October 2019 at 04:20:19 UTC, Exil wrote: Not to mention the problem is actually solved just by using the GC. The d language is marked as a system programming language. The GC is not going to cut it to a lot of people.(Did you forget the whole betterC flag?) -Alex
Re: Oberon to D
very sweet! Blog Post please
Re: Prepping for Patreon...
On Monday, 21 October 2019 at 08:06:49 UTC, aberba wrote: On Thursday, 17 October 2019 at 21:25:20 UTC, Ron Tarrant wrote: On Thursday, 17 October 2019 at 19:46:12 UTC, Guillaume Piolat wrote: Make a PR to https://p0nce.github.io/d-idioms/#Contributing-back-with-money and add yourself in the Patreon list (please _read_ the readme.md before contributing) Thanks for the tip, Guillaume. I think your content is valuable and has potential for attractive more people. Thanks, Aberba. Is it okay if I quote you?
