Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Wednesday, 11 July 2018 at 19:41:37 UTC, Jordi Gutiérrez Hermoso wrote: Just getting it into -betterC territory seems like a very daunting task. You do not need -betterC anymore. At least the LDC frontend will only add linking hooks for what you use, -betterC or no. No need build a stub runtime anymore or give a switch to the compiler to not use the default one. I know because I compile to JavaScript: first to LLVM bitcode, then manual link (with llvm-link), then to JavaScript using Emscripten. I only have to compile those parts of DRuntime and Phobos I use. Its unlikely I could even have a stub runtime to work, so this is the only reason I can use D in my web page to any real degree.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 10 July 2018 at 20:28:00 UTC, Seb wrote: Maybe looking at the recent DMD Backend to D conversion PRs (https://github.com/dlang/dmd/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3A%22D+Conversion%22+) helps? Here -betterC is used. Octave is so far from -betterC, though. It's very C++-heavy, with C++11 features being used since the last couple of years. It's an old codebase that started circa 1992. Just getting it into -betterC territory seems like a very daunting task.
Re: Using dub and rdmd together?
On Wednesday, 11 July 2018 at 16:43:24 UTC, Seb wrote:
I don't know of an easy way to do out of the box.
However, with dmd's new -i option, it could be as easy as:
---
dub fetch requests
cat > test.d << EOF
import std.stdio;
import requests;
void main() {
auto content = postContent("http://httpbin.org/post";,
queryParams("name", "any name", "age", 42));
writeln(content);
}
EOF
dub fetch requests
dmd -I~/.dub/packages/requests-0.8.2/requests/source -i -run
tests.d
---
However, dmd itself doesn't do any caching (though it would
work similarly with rdmd).
But, of course, this won't work for more complex dub packages.
There's `dub describe` (and a backend generator) for which they
might be used.
So this is kind of similar to what dub does already?
Would be nice if dub could cache such compiled scripts somewhere.
I mean dub already caches inside .dub folder in a dub project.
Why not also cache compiled scripts somewhere?
[std.process] get Pid class by Process ID?
Hi everyone, Is it possible to get a Pid (class) from a process id (int)?. I need to use the wait function from std.process but it asks for a Pid, and I have only the process id (integer). auto pd = new Pid(processID); // doesn't work I want to verify that the parent process is still alive, if it doesn't, this child process shall be terminated. Currently, I'm passing the parent process ID by arguments and I need a cross-OS way (if possible). Thanks in advance.
Re: Using dub and rdmd together?
On Wednesday, 11 July 2018 at 16:13:56 UTC, Matthew OConnor wrote:
Hi, I'm new to D and trying to make some command line tools
that are run with `#!/usr/bin/env rdmd`. But I would also like
to reference external packages from dub. I know I can do this
with:
#!/usr/bin/env dub
/+ dub.sdl:
name "get"
dependency "requests" version="~>0.3.2"
+/
But when I run it (with `dub get.d` on Windows), it rebuilds
every time.
Is there a way to integrate the two so that `rdmd` is used for
the builds, but `dub` is used to download the necessary
packages?
Thanks,
Matthew
I don't know of an easy way to do out of the box.
However, with dmd's new -i option, it could be as easy as:
---
dub fetch requests
cat > test.d << EOF
import std.stdio;
import requests;
void main() {
auto content = postContent("http://httpbin.org/post";,
queryParams("name", "any name", "age", 42));
writeln(content);
}
EOF
dub fetch requests
dmd -I~/.dub/packages/requests-0.8.2/requests/source -i -run
tests.d
---
However, dmd itself doesn't do any caching (though it would work
similarly with rdmd).
But, of course, this won't work for more complex dub packages.
There's `dub describe` (and a backend generator) for which they
might be used.
Using dub and rdmd together?
Hi, I'm new to D and trying to make some command line tools that are run with `#!/usr/bin/env rdmd`. But I would also like to reference external packages from dub. I know I can do this with: #!/usr/bin/env dub /+ dub.sdl: name "get" dependency "requests" version="~>0.3.2" +/ But when I run it (with `dub get.d` on Windows), it rebuilds every time. Is there a way to integrate the two so that `rdmd` is used for the builds, but `dub` is used to download the necessary packages? Thanks, Matthew
Re: Troubles creating templated inout objects
On Tuesday, 10 July 2018 at 18:01:59 UTC, Steven Schveighoffer
wrote:
You are overthinking :) inout typically is much easier than you
expect, until you need to create temporary structs or types
with inout members, then it becomes problematic.
https://run.dlang.io/is/kosYuC
I had to put in a static if, because your function doesn't work
once you get down to the array type. See the // fixme comment.
Ok, well that helped a tiny bit for the example.
I'm trying to reproduce the errors from my project. It's starting
to get out of control : D. inout is on a rampage!
https://run.dlang.io/is/5TN7XX
I guess it's the same as for immutable initialization of arrays.
I can't seem to find a proper response to this one..
import std.traits;
struct S
{
int[3] arr;
}
struct SS
{
S s;
}
interface I
{
inout(I) opIndex(size_t idx) inout;
}
class Test(T) : I
{
T member;
this(inout T mem) inout
{
this.member = mem;
}
inout(Test!T) get() inout
{
return new inout Test!(Unqual!(typeof(member)))(member);
}
inout(I) opIndex(size_t idx) inout
{
static if (is(T == struct))
{
switch (idx)
static foreach (index, t; T.tupleof)
{
case index:
return new inout
Test!(Unqual!(typeof(this.member.tupleof[index])))
(this.member.tupleof[index]);
default:
return null;
}
}
else
return null;
}
}
auto test(T)(inout T t)
{
return new inout Test!(Unqual!T)(t);
}
class TestA(T : T[])
{
Test!T[] arr;
// ERROR: Can't initialize inout variable in a
for loop...
this(inout(T[]) arr) inout
{
// 1: Nope
foreach (mem; arr)
this.arr ~= test(mem);
// 2: Nope
//Test!T[] a;
//foreach (mem; arr)
// a ~= test(mem);
import std.algorithm : map;
// 3: Nope
// this.arr = arr.map!((e) => test(e)).array;
}
}
void main()
{
auto ss = SS(S([1,2,3]));
auto t = new const Test!SS(ss);
auto ta = new const TestA!(Test!SS[])([t]);
}
Re: taskPool.reduce vs algorithm.reduce
On Wednesday, 11 July 2018 at 08:31:30 UTC, Dorian Haglund wrote:
Hi.
I'm trying to use taskPool.reduce with a delegate, for example:
import std.parallelism;
int main(string[] args)
{
int f(int a, int b)
{
if (args.length > 1)
return a+b;
else
return a-b;
}
auto res = taskPool.reduce!f([1, 2, 3]);
return 0;
}
But it fails to compile (with gdc 8.1.0, dmd v2.081)
complaining that
template instance reduce!(f) cannot use local 'f' as parameter
to non-global template reduce(functions...)
The snippet above compiles with the reduce function from
std.algorithm.
Is there a way to make the code compile with taskPool.reduce ?
(I don't want to write two functions and choosing one depending
on args.length)
Why the interface difference between std.algorithm's reduce and
taskPool.reduce ?
Best regards,
Dorian
As the error message says taskPool.reduce is a non-global
template. It's embedded in a taskPool struct. I can't say what
the reason is that a delegate cannot be used with such a
template. I'd be interested in hearing what the reason is.
(See Paul's reply).
I'm trying to trick around it, but can't get this to work...
https://run.dlang.io/is/EGbtuq
import std.parallelism;
int main(string[] args)
{
static int f(bool cond)(int a, int b)
{
static if (cond)
return a+b;
else
return a-b;
}
template getF(alias func)
{
auto getF(T)(T arg)
{
if (args.length > 1)
return func!(f!true)(arg); // line 18
else
return func!(f!false)(arg); // line 20
}
}
auto res = getF!(taskPool.reduce)([1,2,3]);
return 0;
}
onlineapp.d(18): Error: need this for reduce of type @system
int(int[] _param_0)
onlineapp.d(20): Error: need this for reduce of type @system
int(int[] _param_0)
Re: taskPool.reduce vs algorithm.reduce
On Wednesday, 11 July 2018 at 08:31:30 UTC, Dorian Haglund wrote: But it fails to compile (with gdc 8.1.0, dmd v2.081) complaining that template instance reduce!(f) cannot use local 'f' as parameter to non-global template reduce(functions...) Congratulations! You've just run into issue 5710 [1], one of D's most annoying known bugs. [1]: https://issues.dlang.org/show_bug.cgi?id=5710 The snippet above compiles with the reduce function from std.algorithm. [...] Why the interface difference between std.algorithm's reduce and taskPool.reduce ? std.algorithm.reduce is a free function, so it can accept delegates as template parameters. taskPool.reduce is a member function, so it can't.
Re: Better diagnostics for null classes dereferencing
On Wednesday, 11 July 2018 at 04:17:49 UTC, Seb wrote: https://github.com/dlang/druntime/pull/2249 Thanks!
Re: vibe.d: problematic "Non-@safe methods are deprecated in REST interfaces"
On Wednesday, 11 July 2018 01:46:10 MDT Piotr Mitana via Digitalmars-d-learn wrote: > On Tuesday, 10 July 2018 at 13:24:43 UTC, WebFreak001 wrote: > > It's supposed to make webservers safe and not crash because of > > segmentation faults, etc. > > > > If you still want to write code like you are used to and don't > > care about that in your webserver, just mark everything in the > > implementation @trusted (but @safe in the interface) and it > > will be fine. > > I understand the motivation of this and this motivation is > undoubtly correct. > > The problem is when you use the libraries, especially those > interfacing with C code. The intention of @trusted is to use it > to mark the code that *is* memory safe, but it cannot be verified > automatically by the compiler (for example required checks are > done before an array access). > > That's why there is a problem with the libraries that are *not* > safe - or at least I don't know the code and cannot verify that > they are. Well, you should be able to at least verify that your usage of the library is @safe. The internals may have problems, but if you've verified all of your code and marked it as @trusted, then the compiler can check the rest of your code, and if there _is_ a memory corruption problem, you know where to look - any @trusted code and then any libraries you're using. But if you just give up and let all of your code be @system, then you lose out on all of the benefits of the compiler verifying your code. The C binding in druntime are typically marked with @trusted so long as their API is @safe (and thus any @safety bugs in using it are inside the C implementation and not due to misuing the function), since if we don't do that, then @safe becomes pretty useless pretty fast in real world programs. At some point, you have to trust that the C functions are doing their jobs properly, but regardless of whether they are, @trusted allows you to narrow down the problem when there is a memory corruption issue while allowing most of your program to be verified by the compiler - which is the point. - Jonathan M Davis
taskPool.reduce vs algorithm.reduce
Hi.
I'm trying to use taskPool.reduce with a delegate, for example:
import std.parallelism;
int main(string[] args)
{
int f(int a, int b)
{
if (args.length > 1)
return a+b;
else
return a-b;
}
auto res = taskPool.reduce!f([1, 2, 3]);
return 0;
}
But it fails to compile (with gdc 8.1.0, dmd v2.081) complaining
that
template instance reduce!(f) cannot use local 'f' as parameter to
non-global template reduce(functions...)
The snippet above compiles with the reduce function from
std.algorithm.
Is there a way to make the code compile with taskPool.reduce ?
(I don't want to write two functions and choosing one depending
on args.length)
Why the interface difference between std.algorithm's reduce and
taskPool.reduce ?
Best regards,
Dorian
Re: vibe.d: problematic "Non-@safe methods are deprecated in REST interfaces"
On Tuesday, 10 July 2018 at 13:24:43 UTC, WebFreak001 wrote: It's supposed to make webservers safe and not crash because of segmentation faults, etc. If you still want to write code like you are used to and don't care about that in your webserver, just mark everything in the implementation @trusted (but @safe in the interface) and it will be fine. I understand the motivation of this and this motivation is undoubtly correct. The problem is when you use the libraries, especially those interfacing with C code. The intention of @trusted is to use it to mark the code that *is* memory safe, but it cannot be verified automatically by the compiler (for example required checks are done before an array access). That's why there is a problem with the libraries that are *not* safe - or at least I don't know the code and cannot verify that they are.
