Re: Alternative to Interfaces
On Saturday, 19 January 2019 at 09:24:21 UTC, Kagamin wrote: On Friday, 18 January 2019 at 18:48:46 UTC, Jonathan M Davis wrote: Yes, but some D features will use the GC They would like to allocate, but they don't know nor care where it's allocated from, if the developer uses custom memory management, he will know how it's allocated and will be able to manage it. Is it possible to get the raw context pointer from a given delegate? If not, how to deallocate the context without garbage collection?
Re: D vs perl6
On Thursday, 22 November 2018 at 09:03:19 UTC, Gary Willoughby wrote: On Monday, 19 November 2018 at 06:46:55 UTC, dangbinghoo wrote: So, can you experts give a more comprehensive compare with perl6 and D? Sure! 1). You can actually read and understand D code. Also, D can be parsed. See: Perl Cannot Be Parsed: A Formal Proof ( https://www.perlmonks.org/?node_id=663393 )
Re: testing for deprecation
On Thursday, 1 September 2016 at 11:11:15 UTC, Cauterite wrote: How does one test whether a symbol is deprecated? I would have expected something like: __traits(isDeprecated, foo). Such a trait makes it possible to write code that will break, just because something has been marked as deprecated. Doesn't it break the purpose of deprecation?
Re: Tools to help me find memory leaks?
I always use "valgrind --tool=massif" + "massif-visualizer". Gives me a nice timeline allowing to find quickly who the big memory consumers (allocation sites) are.
Re: D doesn't read the first character of a file (reads everything but the first chararacter) with either read() or readText()
On Tuesday, 18 July 2017 at 02:21:59 UTC, Enjoys Math wrote:
DMD32 D Compiler v2.074.1
import std.file;
void main() {
string bigInput = readText("input.txt");
}
The file is 7 MB of ascii text, don't know if that matters...
Should I upgrade versions?
Could you please share the first 32-bytes (in hex) of your file?
Like:
$ hexdump -C input.txt
Re: Is it possible to generate a pool of random D or D inline assembler programs, run them safely?
On Tuesday, 18 July 2017 at 17:35:17 UTC, Enjoys Math wrote: Without them crashing the app running them? Say by wrapping with try / catch? and, most probably a timeout, as you're certainly going to run into infinite loops. Reason is so I don't have to make my own VM. Why not reuse an existing one? Some of them are very simple: https://github.com/munificent/wren It will be a lot easier than trying to generate random *compilable* D programs ; and will avoid requiring a compilation step in your mutation loop (I know the D compiler is fast, but still :-) ).
Re: Alias template parameter to a private function
On Thursday, 29 June 2017 at 20:21:13 UTC, Ali Çehreli wrote: A workaround is to use a lambda: filter!(a => isValid(a))(array) Thanks! Nice trick, this is definitely going into my company's codebase :-) Such limitations are pretty annoying. There were a number of similar issues in recent dmd releases. Please file a bug if it's not already there: Thanks, will do!
Re: Alias template parameter to a private function
up please!
Accessing function frame from struct
Hi guys,
here's my full code below.
My problem is that last "auto Y = X" assignment, that the
compiler won't accept:
yo.globalFunction.DirectStruct.IndirectStruct.indirectMemberFunc
cannot access frame of function yo.globalFunction
I was expecting X to be accessible from here.
Suprisingly, if I replace all "struct" with "class", the last
assignment is accepted by the compiler.
Could someone please tell me why the scoping asymmetry between
structs and classes?
void globalFunction()
{
auto X = 0;
struct DirectStruct
{
void directMemberFunc()
{
auto Y = X; // OK, X is accessible
struct HybridStruct
{
void hybridFunc()
{
auto Y = X; // OK, X is accessible
}
}
}
struct IndirectStruct
{
void indirectMemberFunc()
{
auto Y = X; // Error: can't access frame of globalFunc
}
}
}
}
Alias template parameter to a private function
Hi,
I'm trying to call std.algorithm.iteration.filter with a private
function as a predicate.
Here's a reduced example code:
// yo.d
import std.algorithm;
void moduleEntryPoint()
{
privateFunction1();
privateFunction2();
}
private:
void privateFunction1()
{
auto array = [0, 1, 2, 3, 4, 5];
auto result = filter!isValid(array); // error: 'isValid' is
private
}
void privateFunction2()
{
auto array = [0, 1, 2, 3, 4, 5];
auto result = filter!isValid(array); // error: 'isValid' is
private
}
bool isValid(int i)
{
return i % 2 == 0;
}
Here's the compiler output:
/usr/include/dmd/phobos/std/algorithm/iteration.d(1132): Error:
function yo.isValid is not accessible from module iteration
yo.d(14): Error: template instance
std.algorithm.iteration.filter!(isValid).filter!(int[]) error
instantiating
This seems like the compiler, when instanciating the calls to
'filter', is resolving 'isValid' from std.algorithm.iteration
scope (however, this isn't actually the case, see below).
I was expecting this identifier to be resolved from yo.d, where
we have access to the private functions.
Surprisingly, the following works:
void privateFunction2()
{
static bool isValid(int i)
{
return i % 2 == 0;
}
auto array = [0, 1, 2, 3, 4, 5];
auto result = filter!isValid(array); // error: 'isValid' is
private
}
This makes the instanciation of 'filter' "see" 'isValid',
however, now, the other privateFunctions can't use it.
Am I missing something here?
Thanks!
Re: GDC generate wrong .exe ("not a valid win32 application")
On Thursday, 22 June 2017 at 05:57:59 UTC, bauss wrote: On Wednesday, 21 June 2017 at 15:55:27 UTC, David Nadlinger wrote: On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer wrote: Fresh install of GDC. (tried with 32x ad 32_64x) Where did you get the GDC executable from? The GDC project doesn't currently offer any official builds that target Windows; the 6.3.0 builds from https://gdcproject.org/downloads in fact generate Linux binaries. — David I see Windows distributions below the Linux ones. They run on Windows, and produce binaries that run on GNU/Linux.
Re: GDC options
On Wednesday, 22 March 2017 at 13:42:21 UTC, Matthias Klumpp wrote: This is why most of my work in Meson to get D supported is adding weird hacks to translate compiler flags between GNU <-> non-GNU <-> DMD. It sucks quite badly, and every now and then I hit a weird corner case where things break. For example: https://github.com/mesonbuild/meson/commit/d9cabe9f0ca6fb06808c1d5cf5206a7c5158517e One day, we'll have to decide if we should align build systems on compilers, or the other way around. In the meantime, could everyone please align on clang and gcc ? :-)
Re: htod for linux
On Friday, 21 April 2017 at 11:40:45 UTC, Mike Parker wrote: On Friday, 21 April 2017 at 10:54:26 UTC, سليمان السهمي (Soulaïman Sahmi) wrote: Is there an htod for linux or an equivalent that works with Cpp, there is dstep but it does not support Cpp. From the very bottom of the htod doc page [1]: "No Linux version." https://dlang.org/htod.html However, I wouldn't be surprised to get good results on wine.
Re: GDC options
On Monday, 13 March 2017 at 11:06:53 UTC, Russel Winder wrote: It is a shame that dmd and ldc do not just use the standard GCC option set. Totally agreed. Moreover, funny stuff like "dmd -of" (instead of standard "-o ") breaks automatic Msys path conversion hack (the code translates Unix paths from the command line to Windows paths before the invocation of a non-msys program), which makes it impossible to use dmd under Msys without wrapping it first. pkg-config also is a real pain to use with dmd (the pkg-config's output needs to be post-processed so it has the form "-L-lstuff" instead of "-lstuff"). This is an issue, because it makes it very hard to use write portable makefiles for programs containing D code. Too bad, because the D code is actually platform-independent, and there's been a lot of work in Phobos to make it easy to write such code. D was designed to be binary compatible with the C ABI ; however, having a compiler whose command-line behaves so different from gcc makes it harder to actually work with existing C libs. This is actually the main reason why I almost exclusively use gdc: to have one Makefile, for all platforms, allowing native and cross-compilation with no platform-specific special cases.
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 21:52:22 UTC, Jonathan M Davis wrote: On Wednesday, December 07, 2016 15:17:21 Picaud Vincent via Digitalmars-d- learn wrote: That being said, if someone wants to make their life harder by insisting on using D without even druntime, then that's their choice. I think that it's an unnecessarily extreme approach even for really performance-centric code, but they're free to do what they want. It's not only a performance issue. Sometimes, your target platform simply doesn't have the runtime nor Phobos: Emscripten (asmjs), kernel mode code or bare metal embedded stuff. I'm using D without druntime for my D-to-asmjs project. Avoid druntime certainly makes my life harder, but it makes the whole project possible.
Re: strange -fPIC compilation error
Hello, From GCC 6.2, -fpie is becoming the default setting at compile and at link time. As dmd uses GCC to link, now the code needs to be compiled with a special option. Which means you need, at the moment, to add the following options to your dmd.conf: -defaultlib=libphobos2.so -fPIC (the change from GCC is related to security and address space randomization).
Re: Transform/Compile to C/CPP as a target
On Monday, 25 July 2016 at 07:53:17 UTC, Stefan Koch wrote: On Saturday, 23 July 2016 at 12:27:24 UTC, ParticlePeter wrote: Is there any kind of project or workflow that converts D (subset) to C/CPP ? The short answer is no, not for any recent version of D. The long answer is it's kind of possible, but the resulting C code is not human-readable. I just managed today to achieve some transformation to C with the below script: # compile the D modules to llvm bitcode $ ldc2 hello.d -c -output-ll -ofhello.ll $ ldc2 lib.d -c -output-ll -oflib.ll # merge them into one LLVM bitcode module $ llvm-link-3.8 hello.ll lib.ll -o full.bc $ llvm-dis-3.8 full.bc -o=full.ll # convert bitcode to C $ llvm-cbe full.ll # patch the generated C, so it's compilable $ sed -i "s/.*APInt.*//" full.cbe.c $ sed -i "s/^uint32_t main(uint32_t llvm_cbe_argc_arg, uint8_t\*\* llvm_cbe_argv_arg)/int main(int llvm_cbe_argc_arg, char** llvm_cbe_argv_arg)/" full.cbe.c $ sed -i "s/^uint32_t main(uint32_t, uint8_t\*\*)/int main(int, char**)/" full.cbe.c # compile the C program and run it. $ gcc -w full.cbe.c -o full.exe -lphobos2 $ ./full.exe Hello, world: 46 I only tried this with a very minimalistic subset of D at the moment. Most of the magic occurs in the "llvm-cbe" program, which is a "resurrected LLVM C backend" ( https://github.com/JuliaComputing/llvm-cbe ).
Re: inout, delegates, and visitor functions.
Hi ponce,
Thanks for your suggestion.
I think I may have found the beginning of a solution:
class E
{
import std.traits;
void apply(this F, U)(void delegate(U e) f)
if(is(Unqual!U == E))
{
f(this);
}
int val;
}
int main()
{
void setToZero(E e)
{
e.val = 0;
}
void printValue(const E e)
{
import std.stdio;
writefln("Value: %s", e.val);
}
E obj;
obj.apply();
obj.apply();
const(E) objConst;
//objConst.apply();
objConst.apply();
return 0;
}
Basically, I avoid the 'const'/'inout' attribute of the 'apply'
function by using a 'this F' template argument.
Then, I need a second template argument 'U', otherwise, I can't
call 'printValue' on a non-const E instance.
inout, delegates, and visitor functions.
Hi all,
I'm trying to get the following code to work.
(This code is a simplified version of some algebraic type).
Is it possible to only declare one version of the 'apply'
function?
Or should I declare the const version and the non-const version?
I tried using "inout", but I got the following error:
test.d(28): Error: inout method test.E.apply is not callable
using a mutable object
class E
{
void apply(void delegate(inout(E) e) f) inout
{
f(this);
}
int val;
}
void m()
{
void setToZero(E e)
{
e.val = 0;
}
void printValue(const E e)
{
import std.stdio;
writefln("Value: %s", e.val);
}
E obj;
obj.apply();
obj.apply();
}
Thanks!
Re: D : dmd vs gdc : which one to choose?
On Thursday, 19 February 2015 at 08:46:11 UTC, Mayuresh Kathe wrote: Should I choose DMD or go with GDC? I work with projects whose code is half written in C, half written in D. I use GNU make to build them. I found out that using GDC was a much better choice for several reasons: - project portability 1: under Windows, dmd generates OMF object files that can't be linked by the gcc linker, while gdc generates COFF objet files. Which means: - I can use the same Makefile regardless of the target OS. - I can link mingw-compiled C code with D code. - I avoid the struggle of finding OMF versions of SDL.lib, advapi32.lib, etc. - project portability 2: stupid detail, but the weird dmd way of specifying the output file in the command line ( dmd -ofmyfile.o ) defeats the heuristics of MSYS2 path conversion. That's a dealbreaker for me. - when I'm running Debian/Ubuntu, the simple ability to natively run apt-get install gdc to install/upgrade is very practical. As dmd's compilation speed is blazingly fast, it remains a cool way of writing automation scripts (#!/bin/usr/env rdmd), much better, in my opinion, than Bash, or even Python.
